| Message ID | CAB0OVGqEUm7hwjHUy2k++FgXe3w0WZix4qBJ=uNg3dpsd7J33A@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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 >
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
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.
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
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,
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
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
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
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
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
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
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
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
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
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.
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