Thanks for reporting your issue. Please make sure these boxes are checked before submitting your issue - thank you!

- [X] I looked for a similar issue and couldn't find any.
- [X] I tried with the latest version of GPAC. Installers available at https://gpac.io/downloads/gpac-nightly-builds/
- [X] I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). I can share files anonymously with this dropbox: https://www.mediafire.com/filedrop/filedrop_hosted.php?drop=eec9e058a9486fe4e99c33021481d9e1826ca9dbc242a6cfaab0fe95da5e5d95

Detailed guidelines: https://gpac.io/bug-reporting/

Running uncvg with block does not produce the expected padding bits.

In my testing with:
`uncvg:sq=1:vsize=30x20:tiles=1x1:c=R8,G8,B8:sampling=none:interleave=pix:block_size=4:pixel_size=0:row_align=0:tile_align=0:fps=0`

I see the resulting file contains:

```
0000500 83 84 00 00 07 38 6d 64 61 74 ff 00 00 ff 00 00  >.....8mdat......<
0000520 ff 00 00 ff 00 00 00 80 00 00 80 00 00 80 00 00  >................<
0000540 80 00 00 00 ff 00 00 ff 00 00 ff 00 00 ff ff ff  >................<
```

Those `0xff` after the start of `mdat` correspond to red values, and they occur every three bytes. Comparing that to Figure 12 (or Figure 13 for the storage view) in the FDIS, I would expect every four bytes.

Possibly related: When I view the resulting file in `gpac -gui`, I see corruption on the right pixels:

![image](https://github.com/gpac/gpac/assets/174642/04ee5841-ee84-4273-8b24-6ffea9c5a466)

The effect is more visible if using tiles, as in:
`uncvg:sq=1:vsize=30x20:tiles=2x4:c=R8,G8,B8:sampling=none:interleave=pix:block_size=4:pixel_size=0:row_align=0:tile_align=0:fps=0`

where the first tile looks OK, but then its corrupted:

![image](https://github.com/gpac/gpac/assets/174642/8e532233-f125-44c1-8101-ee508623f796)

I don't see that visual corruption with `block_size=0`.
uncvg: block size appears to be ignored for pixel data
This is a GitHub Issue
repo:gpac
owner:gpac
Title : uncvg: block size appears to be ignored for pixel data
Issue date:

--- start body ---
Thanks for reporting your issue. Please make sure these boxes are checked before submitting your issue - thank you!

- [X] I looked for a similar issue and couldn't find any.
- [X] I tried with the latest version of GPAC. Installers available at https://gpac.io/downloads/gpac-nightly-builds/
- [X] I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). I can share files anonymously with this dropbox: https://www.mediafire.com/filedrop/filedrop_hosted.php?drop=eec9e058a9486fe4e99c33021481d9e1826ca9dbc242a6cfaab0fe95da5e5d95

Detailed guidelines: https://gpac.io/bug-reporting/

Running uncvg with block does not produce the expected padding bits.

In my testing with:
`uncvg:sq=1:vsize=30x20:tiles=1x1:c=R8,G8,B8:sampling=none:interleave=pix:block_size=4:pixel_size=0:row_align=0:tile_align=0:fps=0`

I see the resulting file contains:

```
0000500 83 84 00 00 07 38 6d 64 61 74 ff 00 00 ff 00 00  >.....8mdat......<
0000520 ff 00 00 ff 00 00 00 80 00 00 80 00 00 80 00 00  >................<
0000540 80 00 00 00 ff 00 00 ff 00 00 ff 00 00 ff ff ff  >................<
```

Those `0xff` after the start of `mdat` correspond to red values, and they occur every three bytes. Comparing that to Figure 12 (or Figure 13 for the storage view) in the FDIS, I would expect every four bytes.

Possibly related: When I view the resulting file in `gpac -gui`, I see corruption on the right pixels:

![image](https://github.com/gpac/gpac/assets/174642/04ee5841-ee84-4273-8b24-6ffea9c5a466)

The effect is more visible if using tiles, as in:
`uncvg:sq=1:vsize=30x20:tiles=2x4:c=R8,G8,B8:sampling=none:interleave=pix:block_size=4:pixel_size=0:row_align=0:tile_align=0:fps=0`

where the first tile looks OK, but then its corrupted:

![image](https://github.com/gpac/gpac/assets/174642/8e532233-f125-44c1-8101-ee508623f796)

I don't see that visual corruption with `block_size=0`.
--- end body ---
