[FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option

[Carl Eugen Hoyos]

2019-02-09 7:49 GMT+01:00, Gyan <ffmpeg at gyani.pro>:
>
>
> On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:
>> 2019-02-08 6:08 GMT+01:00, Gyan <ffmpeg at gyani.pro>:
>>>
>>> On 08-02-2019 03:31 AM, Carl Eugen Hoyos wrote:
>>>> .
>>>> No strong opinion here, I hadn't realized that -crf 0 only works with
>>>> newer versions.
>>>>
>>>> Can you explain why crf alone has no effect and needs -b:v 0?
>>>> Isn't this a bug both with libvpx and libaom?
>>>>
>>> With crf present but VBV params absent, VPX operates using a constrained
>>> Q RC mode , where the target bitrate acts as a ceiling. Since acvodec
>>> has a non-zero default -b of 200 kbps, this produces undesirable
>>> effects. If set to 0, VPX switches to constant quality.
>> Yes.
>> This looks like a bug to me.
>
> If there's a bug, it's in libav, in that, we can't signal when a value
> is assigned by the user or via user-initiated logic, versus being
> assigned as a default fallback. So it's a design conflict, and the
> workaround has been long documented.
>
> Maybe just before the next major bump, a new field should be
> introduced in AVOptions which registers if the field was
> populated at the behest of the user.

We could set the default for "b" to "0" without a major bump.

Is it expected that constant crf with vp8 leads to broken output?

>>> I do see this block though,
>>>
>>>       if (avctx->codec_id == AV_CODEC_ID_VP9 && ctx->lossless == 1) {
>>>           enccfg.rc_min_quantizer =
>>>           enccfg.rc_max_quantizer = 0;
>>>       } else {
>>>           if (avctx->qmin >= 0)
>>>               enccfg.rc_min_quantizer = avctx->qmin;
>>>           if (avctx->qmax >= 0)
>>>               enccfg.rc_max_quantizer = avctx->qmax;
>>>       }
>>>
>>>
>>> Looks like the quantizer range is disabled only by using the deprecated
>>> option, or has this changed?
>> Is your question "Isn't 'lossless 1' necessary for lossless encoding"?
>
> Yes. A quick glance at vpx HEAD indicates it is, although
> -qmin & -qmax 0 should also work.

Given that it works for most frames, I wonder what the technical
background is...

>>> Also, with libvpx v1.7.0-1758, I get different results for -crf 0 -b:v
>>> 0  vs only -lossless 1, with the latter producing a slightly larger
>>> file, and its result showing a slightly larger SSIM score. Although
>>> neither produces a SSIM of 1, like libx264. Not truly lossless?
>> Please provide your input sample.
>
> I can reproduce the difference in result with
> fate-suite/h264-conformance/src19td.IBP.264

Yes, this returns a few non-lossless frames.

Is the encoder meant to be used for actual encoding?
Or does -crf 0 have several meanings depending on specific options
and vp8 is just bad?

Carl Eugen