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

[Gyan]

On 09-02-2019 04:45 PM, Carl Eugen Hoyos wrote:
> 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.
Do you mean just the defaults in the vpx wrapper? Ok.  Changing the lib 
default will affect encoders which make use the bitrate value, like mjpeg.

> Is it expected that constant crf with vp8 leads to broken output?
Not broken, simply unexpected for those used to  how x264/5 handle it in 
ffmpeg.

>>>> 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.
>
>>>> 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?
>
We're talking about VP9. VP8 has no lossless mode. Yes, this is a 
production encoder - Youtube uses it to generate VP9 streams for 
uploaded videos.

Like I mentioned earlier, CRF +  bitrate triggers constrained quality. 
If the rate ceiling is high enough, the result is equivalent to 
unclamped CRF, which is what the wrapper does when avctx bitrate is 0, 
set its own bitrate target to 1 Gbps.

In any case, -lossless shouldn't be deprecated unless the workaround 
produces identical results.

Gyan