<div dir="ltr"><div>Hi,</div><div><br></div><div>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.<br></div><div><br></div><div>If you'd like to reproduce the VBV overflows, I've concatenated some pieces of my testing video here:</div><div><a href="https://drive.google.com/file/d/1Fgak--50bRcQrJUDDe8Jw8BkbvLY-Yzo/view?usp=sharing">https://drive.google.com/file/d/1Fgak--50bRcQrJUDDe8Jw8BkbvLY-Yzo/view?usp=sharing</a></div><div><br></div><div>and I reproduce using this command (--tff for even more VBV overflows, but it's present using progressive too):</div><div><br></div><div>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</div><div><br></div><div>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.</div><div><br></div><div>Best,</div><div>Jan<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">čt 12. 10. 2023 v 8:38 odesílatel Jan Brothánek <<a href="mailto:jan.brothanek@comprimato.com" target="_blank">jan.brothanek@comprimato.com</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="auto"><div dir="auto">Hi,<div dir="auto"><br></div><div dir="auto">Thanks for the quick fix! I'll try it today or tomorrow. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div>I'll know more after testing and I'll try to capture a problematic input if I find any.<br></div><div dir="auto"><br></div><div>Thanks so far,<br></div><div>Jan<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Dne čt 12. 10. 2023 0:07 uživatel BugMaster <<a href="mailto:BugMaster@narod.ru" rel="noreferrer" target="_blank">BugMaster@narod.ru</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 11 Oct 2023 13:48:47 +0200, Jan Brothánek wrote:<br>
> Hi,<br>
<br>
> I ran into a bug occasionally causing output frames with gray stripes (see<br>
> screenshot and output.mp4 in links below), using slices. Reproducible with<br>
> these parameters (originally found using API) and input.mp4 (link below):<br>
<br>
> x264 --bitrate 8000 --vbv-bufsize 1600 --vbv-maxrate 8000 --output-depth 10<br>
> --profile high422 --output-csp i422 --preset ultrafast --tune zerolatency<br>
> --threads 16 --slices 16 -I 120 -b 0 -o output.mp4 input.mp4<br>
<br>
> Tested with 5a9dfdd (latest master), 5db6aa6 (from Ubuntu repo), aaa9aa8<br>
> (from Centos7 repo), and 90a61ec. The bug seems to be non-deterministic but<br>
> demonstrates similarly on similar frames - a complex scene followed by a<br>
> simple scene that fades to white or black. It looks like the probability of<br>
> corruption increases with the number of threads (that's why I used 16) and<br>
> the VBV size limitation.<br>
<br>
> screenshot of input frame:<br>
> <a href="https://drive.google.com/file/d/1ZiVU5BrKYY_pWr-VzstnOl3AbcW96PhE/view?usp=drive_link" rel="noreferrer noreferrer noreferrer" target="_blank">https://drive.google.com/file/d/1ZiVU5BrKYY_pWr-VzstnOl3AbcW96PhE/view?usp=drive_link</a><br>
> screenshot of output frame:<br>
> <a href="https://drive.google.com/file/d/1MhxC8GaKOfnCL11nPt2jsTVbX6kigVq_/view?usp=drive_link" rel="noreferrer noreferrer noreferrer" target="_blank">https://drive.google.com/file/d/1MhxC8GaKOfnCL11nPt2jsTVbX6kigVq_/view?usp=drive_link</a><br>
<br>
> input.mp4:<br>
> <a href="https://drive.google.com/file/d/1e8abTsbs8R-CxNNLDKy1jAfR66-guQMt/view?usp=drive_link" rel="noreferrer noreferrer noreferrer" target="_blank">https://drive.google.com/file/d/1e8abTsbs8R-CxNNLDKy1jAfR66-guQMt/view?usp=drive_link</a><br>
> output.mp4:<br>
> <a href="https://drive.google.com/file/d/1YzcjVGkmzsHvGTXiOh1rVCXGTKw5kIVW/view?usp=drive_link" rel="noreferrer noreferrer noreferrer" target="_blank">https://drive.google.com/file/d/1YzcjVGkmzsHvGTXiOh1rVCXGTKw5kIVW/view?usp=drive_link</a><br>
<br>
> Best,<br>
> Jan<br>
<br>
Hi.<br>
<br>
Quick fix:<br>
<a href="https://code.videolan.org/BugMaster/x264/-/commit/324317619c109345759116aba06debb4d00b4c36" rel="noreferrer noreferrer noreferrer" target="_blank">https://code.videolan.org/BugMaster/x264/-/commit/324317619c109345759116aba06debb4d00b4c36</a><br>
<br>
I'm not sure that this is a completely correct patch and that it won't<br>
cause VBV overflow, but in your case it should work. So if you have<br>
other streams with a similar problem, you can check it on them. And<br>
check that VBV overflow does not occur anywhere.<br>
<br>
_______________________________________________<br>
x264-devel mailing list<br>
<a href="mailto:x264-devel@videolan.org" rel="noreferrer noreferrer" target="_blank">x264-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x264-devel" rel="noreferrer noreferrer noreferrer" target="_blank">https://mailman.videolan.org/listinfo/x264-devel</a><br>
</blockquote></div></div>
</div>
</blockquote></div></div>