[x264-devel] [PATCH] Added support for CABAC zero bytes insertion

[Kyle Swanson]

Hi,

On Wed, Apr 17, 2019 at 2:16 PM Loren Merritt <lorenm at u.washington.edu> wrote:
> I can sorta explain why it exists in the standard, and why I always
> ignored that clause of the standard.
>
> A Level is a bundle of "if you want to decode worst-case examples of
> streams with this Level, your decoder had better have resources XYZ". One
> of the resources that is needed, is the throughput of the cabac decoder.
>
> For some reason I never saw explained, the standard didn't include cabac
> directly as a Level parameter, instead it uses bitrate and resolution as a
> proxy. Which is usually fine; bitrate is a pretty good proxy for number of
> cabac decisions.
>
> But for some unusual streams, that get an unusually large amount of
> compression benefit from cabac, then that assumed relation can fail. (I
> don't know off-hand how rare this is.) And if such a condition is combined
> with large absolute bitrate, then the decoder can be left processing
> slightly more cabac decisions than its Level promised it to be capable of.
>
> The standard's perverse solution for this edge case is: Tell the encoder
> to stop compressing so well, so that the padded bitrate resumes being a
> good proxy for the number of cabac decisions. And it doesn't tell you to
> just virtually pad it for the purpose of checking Level compliance, it
> tells you to actually make the actual compression worse.
>
> All of that could have been an off-by-default option for pedantic
> standard-correctness that someone could enable if they ever found a
> use-case where it matters. But implementing it requires an extra
> instruction in the cabac inner loop, that you don't get to skip just
> because you turn off the padding. Which is only a tiny speed cost, but is
> a cost I decided not to pay for a feature whose "benefit" is "occasionally
> make the compression worse".

Netflix is aware of a handful of hardware decoders that seemingly
break on bitstreams without this padding. I've pulled this patch and
we will do some testing with it.

Thanks,
Kyle