[x264-devel] Corrupted slices

[Jan Brothánek]

Hi,

After testing I confirm the output doesn't contain corrupted slices. But
VBV overflow is present quite often. Is that considered a bug, or is it
just a risk of the slice mode which needs to be accepted? My TS muxer is
strict for VBV requirements in low latency mode. I use slices to achieve
the lowest latency but if VBV compliance isn't guaranteed in slice mode,
that won't be an option.

If you'd like to reproduce the VBV overflows, I've concatenated some pieces
of my testing video here:
https://drive.google.com/file/d/1Fgak--50bRcQrJUDDe8Jw8BkbvLY-Yzo/view?usp=sharing

and I reproduce using this command (--tff for even more VBV overflows, but
it's present using progressive too):

x264 --tff --bitrate 8000 --vbv-bufsize 1600 --vbv-maxrate 8000
--output-depth 10 --profile high422 --output-csp i422 --preset ultrafast
--tune zerolatency --slices 16 --threads 16 -I 120 -b 0 -o output.mp4
input.cat.mp4

I see 5 warnings about "VBV underflow" and even more cases if I compute the
buffer fullness manually based on the codestream sizes (return values of
x264_encoder_encode()) which I dumped. One of the frames was even 233767B
which itself won't fit to the VBV buffer.

Best,
Jan

čt 12. 10. 2023 v 8:38 odesílatel Jan Brothánek <
jan.brothanek at comprimato.com> napsal:

> Hi,
>
> Thanks for the quick fix! I'll try it today or tomorrow.
>
> The VBV overflow was actually the first thing I noticed when TS muxer
> complained the bitrate is overshot so it cannot output the stream in
> real-time given the bitrate. Then, looking into it, I found the grey
> slices.
>
> I thought the VBV overflow happens as a consequence of the corrupted
> slices but I see it's probably the other way round - as it was happening on
> simple scenes, it could be the VBV overshoot (not sure for what reason)
> followed by RC aggressiveness (trying to balance it) which causes the most
> simple slices to cut out everything from the codestream, as there already
> was not much.
>
> I'll know more after testing and I'll try to capture a problematic input
> if I find any.
>
> Thanks so far,
> Jan
>
> Dne čt 12. 10. 2023 0:07 uživatel BugMaster <BugMaster at narod.ru> napsal:
>
>> On Wed, 11 Oct 2023 13:48:47 +0200, Jan Brothánek wrote:
>> > Hi,
>>
>> > I ran into a bug occasionally causing output frames with gray stripes
>> (see
>> > screenshot and output.mp4 in links below), using slices. Reproducible
>> with
>> > these parameters (originally found using API) and input.mp4 (link
>> below):
>>
>> > x264 --bitrate 8000 --vbv-bufsize 1600 --vbv-maxrate 8000
>> --output-depth 10
>> > --profile high422 --output-csp i422 --preset ultrafast --tune
>> zerolatency
>> > --threads 16 --slices 16 -I 120 -b 0 -o output.mp4 input.mp4
>>
>> > Tested with 5a9dfdd (latest master), 5db6aa6 (from Ubuntu repo), aaa9aa8
>> > (from Centos7 repo), and 90a61ec. The bug seems to be non-deterministic
>> but
>> > demonstrates similarly on similar frames - a complex scene followed by a
>> > simple scene that fades to white or black. It looks like the
>> probability of
>> > corruption increases with the number of threads (that's why I used 16)
>> and
>> > the VBV size limitation.
>>
>> > screenshot of input frame:
>> >
>> https://drive.google.com/file/d/1ZiVU5BrKYY_pWr-VzstnOl3AbcW96PhE/view?usp=drive_link
>> > screenshot of output frame:
>> >
>> https://drive.google.com/file/d/1MhxC8GaKOfnCL11nPt2jsTVbX6kigVq_/view?usp=drive_link
>>
>> > input.mp4:
>> >
>> https://drive.google.com/file/d/1e8abTsbs8R-CxNNLDKy1jAfR66-guQMt/view?usp=drive_link
>> > output.mp4:
>> >
>> https://drive.google.com/file/d/1YzcjVGkmzsHvGTXiOh1rVCXGTKw5kIVW/view?usp=drive_link
>>
>> > Best,
>> > Jan
>>
>> Hi.
>>
>> Quick fix:
>>
>> https://code.videolan.org/BugMaster/x264/-/commit/324317619c109345759116aba06debb4d00b4c36
>>
>> I'm not sure that this is a completely correct patch and that it won't
>> cause VBV overflow, but in your case it should work. So if you have
>> other streams with a similar problem, you can check it on them. And
>> check that VBV overflow does not occur anywhere.
>>
>> _______________________________________________
>> x264-devel mailing list
>> x264-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x264-devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20231016/7700aa5b/attachment.htm>