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

Submitted by Carl Eugen Hoyos on Feb. 7, 2019, 7:53 p.m.

Details

Message ID CAB0OVGqEUm7hwjHUy2k++FgXe3w0WZix4qBJ=uNg3dpsd7J33A@mail.gmail.com
State New
Headers show

Commit Message

Carl Eugen Hoyos Feb. 7, 2019, 7:53 p.m.
Hi!

Lossless libvpx encoding is possible with "-crf 0".

Please comment, Carl Eugen

Comments

James Almer Feb. 7, 2019, 7:57 p.m.
On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote:
> Hi!
> 
> Lossless libvpx encoding is possible with "-crf 0".

Does that work with all supported versions, or was it a recent change?

> 
> Please comment, Carl Eugen
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Carl Eugen Hoyos Feb. 7, 2019, 8:08 p.m.
2019-02-07 20:57 GMT+01:00, James Almer <jamrial@gmail.com>:
> On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Lossless libvpx encoding is possible with "-crf 0".
>
> Does that work with all supported versions, or was it a recent change?

No, it needs a newer version than 1.4.0

Sorry, Carl Eugen
James Almer Feb. 7, 2019, 8:21 p.m.
On 2/7/2019 5:08 PM, Carl Eugen Hoyos wrote:
> 2019-02-07 20:57 GMT+01:00, James Almer <jamrial@gmail.com>:
>> On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Lossless libvpx encoding is possible with "-crf 0".
>>
>> Does that work with all supported versions, or was it a recent change?
> 
> No, it needs a newer version than 1.4.0
> 
> Sorry, Carl Eugen

What's the first version where this works? We could bump the minimum
required version. It would also let us remove a considerable amount of
ifdeffery.

Debian Oldstable has a libvpx 1.6.1 package in the official backports
repository, and Ubuntu Xenial (oldest LTS) ships with 1.5.0. And if it
was added after those, an argument could also be made that if you're
compiling latest ffmpeg you can also compile its popular dependencies.
Not to mention libvpx is a library that's best to have as up to date as
possible.
Carl Eugen Hoyos Feb. 7, 2019, 10:01 p.m.
2019-02-07 21:21 GMT+01:00, James Almer <jamrial@gmail.com>:
> On 2/7/2019 5:08 PM, Carl Eugen Hoyos wrote:
>> 2019-02-07 20:57 GMT+01:00, James Almer <jamrial@gmail.com>:
>>> On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote:
>>>> Hi!
>>>>
>>>> Lossless libvpx encoding is possible with "-crf 0".
>>>
>>> Does that work with all supported versions, or was it a recent change?
>>
>> No, it needs a newer version than 1.4.0
>>
>> Sorry, Carl Eugen
>
> What's the first version where this works?

It works with 1.6.0 but not with 1.5.0.

> We could bump the minimum required version. It would
> also let us remove a considerable amount of ifdeffery.
>
> Debian Oldstable has a libvpx 1.6.1 package in the official backports
> repository, and Ubuntu Xenial (oldest LTS) ships with 1.5.0. And if it
> was added after those, an argument could also be made that if you're
> compiling latest ffmpeg you can also compile its popular dependencies.
> Not to mention libvpx is a library that's best to have as up to date as
> possible.

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?

Carl Eugen
Dominik 'Rathann' Mierzejewski Feb. 7, 2019, 10:15 p.m.
On Thursday, 07 February 2019 at 21:21, James Almer wrote:
> On 2/7/2019 5:08 PM, Carl Eugen Hoyos wrote:
> > 2019-02-07 20:57 GMT+01:00, James Almer <jamrial@gmail.com>:
> >> On 2/7/2019 4:53 PM, Carl Eugen Hoyos wrote:
> >>> Hi!
> >>>
> >>> Lossless libvpx encoding is possible with "-crf 0".
> >>
> >> Does that work with all supported versions, or was it a recent change?
> > 
> > No, it needs a newer version than 1.4.0
> > 
> > Sorry, Carl Eugen
> 
> What's the first version where this works? We could bump the minimum
> required version. It would also let us remove a considerable amount of
> ifdeffery.
> 
> Debian Oldstable has a libvpx 1.6.1 package in the official backports
> repository, and Ubuntu Xenial (oldest LTS) ships with 1.5.0. And if it
> was added after those, an argument could also be made that if you're
> compiling latest ffmpeg you can also compile its popular dependencies.
> Not to mention libvpx is a library that's best to have as up to date as
> possible.

FWIW, RHEL6 and RHEL7 (and derivatives) have libvpx-1.3.0.

Fedora has 1.7.0 and will likely upgrade to the just released 1.8.0.

Regards,
Gyan Feb. 8, 2019, 5:08 a.m.
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.

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?

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?

Gyan
Carl Eugen Hoyos Feb. 8, 2019, 8:56 p.m.
2019-02-08 6:08 GMT+01:00, Gyan <ffmpeg@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.

> 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"?

> 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.

Carl Eugen
Gyan Feb. 9, 2019, 6:49 a.m.
On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:
> 2019-02-08 6:08 GMT+01:00, Gyan <ffmpeg@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.

Gyan
Carl Eugen Hoyos Feb. 9, 2019, 11:15 a.m.
2019-02-09 7:49 GMT+01:00, Gyan <ffmpeg@gyani.pro>:
>
>
> On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:
>> 2019-02-08 6:08 GMT+01:00, Gyan <ffmpeg@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
Gyan Feb. 10, 2019, 4:44 a.m.
On 09-02-2019 04:45 PM, Carl Eugen Hoyos wrote:
> 2019-02-09 7:49 GMT+01:00, Gyan <ffmpeg@gyani.pro>:
>>
>> On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:
>>> 2019-02-08 6:08 GMT+01:00, Gyan <ffmpeg@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
Kieran O Leary Feb. 10, 2019, 12:06 p.m.
On Sat, 9 Feb 2019, 06:49 Gyan <ffmpeg@gyani.pro wrote:

>
>
> On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:
> > 2019-02-08 6:08 GMT+01:00, Gyan <ffmpeg@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
Gyan Feb. 10, 2019, 6:27 p.m.
On 10-02-2019 05:36 PM, Kieran O Leary wrote:
>
> 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.

The barebones command:

     ffmpeg -i main -i ref -lavfi ssim -f null -

framehash will be sensitive to data layout, so that comparing the same 
payload in planar vs packed format will yield different values. As the 
SSIM filter only works with planar formats, avfilter will take care of 
conversion, if needed, of both inputs.

Other than that, SSIM will present a rough measure of the shortfall if 
the transcode isn't lossless. A framehash is either a match or not.

Gyan
Carl Eugen Hoyos Feb. 10, 2019, 6:59 p.m.
2019-02-10 5:44 GMT+01:00, Gyan <ffmpeg@gyani.pro>:
>
>
> On 09-02-2019 04:45 PM, Carl Eugen Hoyos wrote:
>> 2019-02-09 7:49 GMT+01:00, Gyan <ffmpeg@gyani.pro>:
>>>
>>> On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:
>>>> 2019-02-08 6:08 GMT+01:00, Gyan <ffmpeg@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?

Yes.

> 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 tested -crf with "b:v 0" and the vp8 output (current FFmpeg git head,
a libvpx release) was broken: Every 100th or so frame looked ugly
and very different from the surrounding frames (no scene change).

I will try to reproduce again.

>>>>> 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?

This should be vp9 (or libvpx assuming the above)

> 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.

So the problem is that with b:v 0 you currently get a completely unexpected
output depending on the resolution of the video? (And if you did use another
value for crf than 0, you won't even have a possibility to find out.)
Wow...

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

My question here is why crf 0 does not produce lossless encodings
(with "b:v 0"). Is this expected for some reason?
(But I get the point now after reading above sentence again.)

Carl Eugen
Carl Eugen Hoyos Feb. 10, 2019, 7:02 p.m.
2019-02-10 13:06 GMT+01:00, Kieran O Leary <kieran.o.leary@gmail.com>:
> On Sat, 9 Feb 2019, 06:49 Gyan <ffmpeg@gyani.pro wrote:

>> 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.

If you trust FFmpeg (this thread gives several indications why you shouldn't)
the output format crc is simpler to type, easier to interpret and - in theory -
safer than ssim.

Carl Eugen
James Zern Feb. 11, 2019, 8:45 p.m.
On Sat, Feb 9, 2019 at 3:15 AM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>
> 2019-02-09 7:49 GMT+01:00, Gyan <ffmpeg@gyani.pro>:
> >
> >
> > On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:
> >> 2019-02-08 6:08 GMT+01:00, Gyan <ffmpeg@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...
>

I believe the option was added as a convenience in vp9. The parameter
here matches what vpxenc uses, but min/max-q=0 is equivalent.

Patch hide | download patch | download mbox

From 76e8df1da3470a1232f6128b37a681926d4cab92 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Date: Thu, 7 Feb 2019 20:39:12 +0100
Subject: [PATCH] lavc/libvpxenc: Deprecate lossless, there is -crf 0.

---
 doc/encoders.texi      |    2 +-
 libavcodec/libvpxenc.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index e86ae69..9efa015 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1802,7 +1802,7 @@  Template defining the membership of frames to temporal layers.
 @item VP9-specific options
 @table @option
 @item lossless
-Enable lossless mode.
+Deprecated, set the @option{crf} option to 0.
 @item tile-columns
 Set number of tile columns to use. Note this is given as
 @code{log2(tile_columns)}. For example, 8 tile columns would be requested by
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index c823b8a..2ed8a70 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1219,7 +1219,7 @@  static const AVOption vp9_options[] = {
     { "auto-alt-ref",    "Enable use of alternate reference "
                          "frames (2-pass only)",                        OFFSET(auto_alt_ref),    AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
     { "cpu-used",        "Quality/Speed ratio modifier",                OFFSET(cpu_used),        AV_OPT_TYPE_INT, {.i64 = 1},  -8, 8, VE},
-    { "lossless",        "Lossless mode",                               OFFSET(lossless),        AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE},
+    { "lossless",        "Deprecated, use -crf 0",                      OFFSET(lossless),        AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE},
     { "tile-columns",    "Number of tile columns to use, log2",         OFFSET(tile_columns),    AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
     { "tile-rows",       "Number of tile rows to use, log2",            OFFSET(tile_rows),       AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, VE},
     { "frame-parallel",  "Enable frame parallel decodability features", OFFSET(frame_parallel),  AV_OPT_TYPE_BOOL,{.i64 = -1}, -1, 1, VE},
-- 
1.7.10.4