These functions encode a slice of alpha (1 to 8 macroblocks) which are expected to be encoded as a repeated sequence of "[diff][run-1]", where diff is the running difference of the alpha value and run is how many times that value is expected to be duplicated (within the limit of a grand total of 2048 unpacked samples, corresponding to a slice of 8 MB). Even when run==0 (the run variable semantic is actually "run minus 1"), there is always a diff previously encoded that needs a counter of at least 1. This means we need to call put_alpha_run() unconditionally at the end of the bitstream to account for the last running diff. This commit fixes glitchy playbacks on QuickTime with M2 and M3 hardware (but not M1 for some mysterious reason) with files generated with commands such as: ffmpeg -f lavfi -i testsrc2=d=5:s=912x320,chromakey -c:v prores_aw -profile:v 4 -y aw.mov ffmpeg -f lavfi -i testsrc2=d=5:s=912x320,chromakey -c:v prores_ks -profile:v 4444 -y ks.mov The glitch expresses itself deterministically as blinking black rectangles on random frames (for example on frame 21, 54, 71, 79, ...). Even with the proresdec from FFmpeg, overreads actually happens while reading the run-minus-1 value (around val = get_bits(gb, 4) in unpack_alpha()). This doesn't seem to cause any particular issue because it simply overreads into the next slice, and because the decoder is resilient, but it's still a problem. The investigation leading to this fix was made possible because of paid work for Jitter (https://jitter.video). Fixes ticket #10255.release/7.0
parent
2142141a16
commit
9109273e3b
2 changed files with 2 additions and 4 deletions
Loading…
Reference in new issue