Lynne,
On Wed, Mar 16, 2022 at 5:39 AM Lynne <d...@lynne.ee> wrote:
>
> 16 Mar 2022, 13:07 by danilchap-at-google....@ffmpeg.org:
>
> > ---
> > libavcodec/libvpxenc.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> > index 8f94ba15dc..45baeed435 100644
> > --- a/libavcodec/libvpxenc.c
> > +++ b/libavcodec/libvpxenc.c
> > @@ -1658,6 +1658,13 @@ static int vpx_encode(AVCodecContext *avctx,
> > AVPacket *pkt,
> > flags |= strtoul(en->value, NULL, 10);
> > }
> >
> > + en = av_dict_get(frame->metadata, "max-quantizer", NULL, 0);
> > + if (en) {
> > + struct vpx_codec_enc_cfg cfg = *enccfg;
> > + cfg.rc_max_quantizer = strtoul(en->value, NULL, 10);
> > + vpx_codec_enc_config_set(&ctx->encoder, &cfg);
> > + }
> >
>
> I was going to NAK the earlier patch, but forgot.
> Please think of a better way than stuffing random data in
> inappropriate fields, and fix the earlier patch that was mistakenly
> merged to not do that.
I agree this isn't great. Would you suggest updating the qmax setting
and checking it / all options on a per-frame basis or is there a
better way to reconfigure the codec on the fly?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
