2019-02-10 5:44 GMT+01:00, Gyan <ffm...@gyani.pro>:
>
>
> On 09-02-2019 04:45 PM, Carl Eugen Hoyos wrote:
>> 2019-02-09 7:49 GMT+01:00, Gyan <ffm...@gyani.pro>:
>>>
>>> On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:
>>>> 2019-02-08 6:08 GMT+01:00, Gyan <ffm...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
