[x264-devel] Corrupted slices

[Jan Brothánek]

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/20231012/9fb98030/attachment.htm>