[x264-devel] Corrupted slices

[BugMaster]

On Mon, 16 Oct 2023 18:25:41 +0200, Jan Brothánek wrote:
> 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

Hi.

Try with this patch: https://code.videolan.org/BugMaster/x264/-/commit/8409bcbf3a326ee0950011f0560ce69e900a017d

This is probably the maximum that I can do without radically changing
the predictors, which sometimes go crazy when there is a practically
unchanged frame in the stream for a long time, and then there is a
sudden movement.

At least I hope that with this patch you won't have VBV underflows.
And in the 2-pass mode there will also be no corrupted slices.