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

[Kieran O Leary]

On Sat, 9 Feb 2019, 06:49 Gyan <ffmpeg at gyani.pro wrote:

>
>
> 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.
> >> 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
>
> although the `-lossless 1` encoding does return as lossless in SSIM.
>

What ssim command did you use, and why use this over a hash muxer like
framehash? I'm always on the lookout for losslessness verification methods.

Best,

Kieran