Uncommon "invalid block label"

[cnlohr]

When using your encoder in 2-color mode, I have found a specific set of images that produce output that ffmpeg, firefox, and google chrome will cause the video to terminate after 498 frames, instead of the 6,000 frames that are encoded in this video.

Interestingly, tools like xviewer, or eom (eye of mate) both parse the stream fine.

FFMPEG Output with -loglevel trace

Please note the output frames are not printed in-line with the GIF frame decoding because of buffering.

[libx264 @ 0x55dc4bd01880] frame= 446 QP=12.00 NAL=2 Slice:P Poc:168 I:2    P:0    SKIP:46   size=27 bytes
[gif @ 0x55dc4bcfae80] code=21 '!'
[gif @ 0x55dc4bcfae80] code=2c ','
[libx264 @ 0x55dc4bd01880] frame= 447 QP=15.00 NAL=2 Slice:B Poc:164 I:0    P:2    SKIP:46   size=18 bytes
[gif @ 0x55dc4bcfae80] code=21 '!'
[gif @ 0x55dc4bcfae80] code=2c ','
[libx264 @ 0x55dc4bd01880] frame= 448 QP=16.00 NAL=0 Slice:B Poc:162 I:0    P:2    SKIP:46   size=16 bytes
[gif @ 0x55dc4bcfae80] code=21 '!'
[gif @ 0x55dc4bcfae80] code=2c ','
[libx264 @ 0x55dc4bd01880] frame= 449 QP=16.00 NAL=0 Slice:B Poc:166 I:0    P:0    SKIP:48   size=12 bytes
[gif @ 0x55dc4bcfae80] code=21 '!'
[gif @ 0x55dc4bcfae80] code=2c ','
[gif @ 0x55dc4bcf1500] invalid block label <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
[libx264 @ 0x55dc4bd01880] frame= 450 QP=13.00 NAL=2 Slice:P Poc:176 I:1    P:0    SKIP:47   size=24 bytes
[gif @ 0x55dc4bcfae80] code=21 '!'
[gif @ 0x55dc4bcfae80] code=2c ','
[libx264 @ 0x55dc4bd01880] frame= 451 QP=15.00 NAL=2 Slice:B Poc:172 I:0    P:1    SKIP:47   size=16 bytes
EOF in input file 0
Terminating demuxer thread 0
[out_0_0 @ 0x55dc4bd18200] EOF on sink link out_0_0:default.
No more output streams to write to, finishing.

I also tried another instance, where I set delay to 0, and it failed after 207 frames, with the same error.

[libx264 @ 0x63405b3bc8c0] frame= 158 QP=25.25 NAL=2 Slice:P Poc:316 I:1    P:5    SKIP:42   size=64 bytes
[gif @ 0x63405b3b5ec0] code=2c ','
[gif @ 0x63405b3ac500] invalid block label
[libx264 @ 0x63405b3bc8c0] frame= 159 QP=20.08 NAL=2 Slice:P Poc:318 I:2    P:1    SKIP:45   size=49 bytes
[gif @ 0x63405b3b5ec0] code=2c ','
[libx264 @ 0x63405b3bc8c0] frame= 160 QP=23.35 NAL=2 Slice:P Poc:326 I:8    P:10   SKIP:30   size=174 bytes
EOF in input file 0
Terminating demuxer thread 0

My general usage is as follows:

        uint8_t palette[6] = { 0, 0, 0, 255, 255, 255 };
        gifout = ge_new_gif( argv[3], video_w*2, video_h*2, palette, 2, 0 );
...
in a for loop....
...
            ge_add_frame(gifout, 0);
...
and finally
...

        ge_close_gif( gifout );

I will continue to investigate.

[cnlohr]

• I seem to be able to make this issue happen with 2, and 3 colors, but the issue does not seem to happen with >3.
• I can get completely invalid output with 9 colors. see below:

FFMPEG fails very early on and reports the following:

[gif @ 0x5e118417e500] Opening 'video-64x48x8.gif' for reading
[file @ 0x5e118417eb40] Setting default whitelist 'file,crypto,data'
[gif @ 0x5e118417e500] Before avformat_find_stream_info() pos: 0 bytes read:32768 seeks:0 nb_streams:1
[gif @ 0x5e118417e500] invalid block label
[gif @ 0x5e118417e500] stream 0: start_time: 0 duration: 0
[gif @ 0x5e118417e500] format: start_time: 0 duration: NOPTS (estimate from stream) bitrate=0 kb/s
[gif @ 0x5e118417e500] After avformat_find_stream_info() pos: 1831802 bytes read:1831802 seeks:0 frames:0
Input #0, gif, from 'video-64x48x8.gif':
  Duration: N/A, start: 0.000000, bitrate: N/A
  Stream #0:0, 0, 1/100: Video: gif, 1 reference frame, bgra, 128x96, 0/1, 100 tbr, 100 tbn

[cnlohr]

video-64x48x8.gif.zip The image did not seem to attach, I decided to zip it.

[cnlohr]

TIL "depth" is bit depth, not colors.

[cnlohr]

Ah, that still doesn't fix it for lower bit depths, for instance, "1" still produces an error, after 207 frames.

[gif @ 0x5db76e953ec0] code=21 '!'
[gif @ 0x5db76e953ec0] code=2c ','
[libx264 @ 0x5db76e95a8c0] frame= 156 QP=16.00 NAL=0 Slice:B Poc:308 I:0    P:11   SKIP:37   size=24 bytes
[gif @ 0x5db76e953ec0] code=21 '!'
[gif @ 0x5db76e953ec0] code=2c ','
[libx264 @ 0x5db76e95a8c0] frame= 157 QP=16.00 NAL=0 Slice:B Poc:312 I:0    P:9    SKIP:39   size=23 bytes
[gif @ 0x5db76e953ec0] code=21 '!'
[gif @ 0x5db76e953ec0] code=2c ','
[libx264 @ 0x5db76e95a8c0] frame= 158 QP=31.25 NAL=2 Slice:P Poc:316 I:1    P:5    SKIP:42   size=61 bytes
[gif @ 0x5db76e953ec0] code=21 '!'
[gif @ 0x5db76e953ec0] code=2c ','
[gif @ 0x5db76e94a500] invalid block label
[libx264 @ 0x5db76e95a8c0] frame= 159 QP=25.08 NAL=2 Slice:P Poc:318 I:2    P:1    SKIP:45   size=45 bytes
[gif @ 0x5db76e953ec0] code=21 '!'
[gif @ 0x5db76e953ec0] code=2c ','

Blehhh

[cnlohr]

I got a little further. It looks like if there is a block that has exactly 255? data bits, it emits a second 00 when it should not before the next block.

[cnlohr]

I somehow am not building against the current master? I think this has been fixed.