uncvg: block size appears to be ignored for pixel data

[bradh]

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

• I looked for a similar issue and couldn't find any.
• I tried with the latest version of GPAC. Installers available at https://gpac.io/downloads/gpac-nightly-builds/
• 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:

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:

I don't see that visual corruption with block_size=0.