[FFmpeg-devel] [PATCH] Add enable_keyframe_filtering option for libaom-av1 encoder.

Bohan Li bohanli at google.com
Fri Nov 6 19:31:05 EET 2020


Thanks a lot for the comment, Jan and Steven! Yes I very much agree that
the number of options is quite large and this is not a great path to go
for. But for the moment I still suggest that we apply this patch, while
proposing to libaom for a key & value api.

This option gives users the option to control the keyframe filtering
method, which is quite essential to both objective and subjective quality.
When turned on (default) the objective quality/compression efficiency is
greatly improved, but at the cost of potential subjective quality loss at
keyframes (because they are filtered and can appear blurry). Therefore
users who do not want to have such artifacts may want to disable the
option. This is actually a long-standing trade-off that libaom users have
to (sometimes painfully) choose, and they cannot do so with ffmpeg right
now. Also recently a new experimental option (=2) was added to libaom in
order to mitigate the subjective loss. It would be nice to expose this
option for people to be able to test it using ffmpeg with various decoders
too. I've observed a few related discussions in the AV1 community (e.g. the
reddit thread on the experimental option:
https://www.reddit.com/r/AV1/comments/ic7ktu/aom_fixed_its_filtered_reference_frame_issues/
).

That said, I do understand the rationale and the reason why people might be
opposed to adding another option, though I still suggest that we add the
option for now, and when the API is available, we can make decisions and
deprecate certain ones that are not necessary. Please let me know your
thoughts on this, meanwhile I'll file a feature request to the aomedia bug
tracker for the API.

Thank you again for the comments!
Best,
Bohan

On Fri, Nov 6, 2020 at 3:16 AM Jan Ekström <jeebjp at gmail.com> wrote:

> On Fri, Nov 6, 2020 at 11:46 AM Steven Liu <lq at chinaffmpeg.org> wrote:
> >
> >
> >
> > > 2020年11月6日 下午4:42,Bohan Li <bohanli at google.com> 写道:
> > >
> > > Thanks for the reply, Steven!
> > >
> > > Regarding JEEB’s comment, the suggestion was to add an api to the
> *libaom* library, not to ffmpeg. I do agree with the rationale, but when
> such an api would be available for ffmpeg to use is quite uncertain. In the
> meanwhile, I believe it is reasonable to add in this patch to expose the
> option to the users. I don’t think this is a “middle version”, since as
> mentioned, this option could be quite useful in certain scenarios and IMHO
> should be added in.
> > What about use av1_param arguments? As x264opts, x265opts?
>
> The problem with this is that libaom as far as I can tell doesn't have
> an API like that. Thus each and every API user that needs to have
> options defined as strings will have to *duplicate* those mappings
> (which already are defined in the aomenc command line application, but
> not exposed through the API).
>
> This has been the butt of jokes and reason for lamentations on IRC for
> quite a while, but unfortunately nobody actually seems to have voiced
> an opinion on this on the mailing list until now?
>
> Thus there generally speaking are only two ways forward for this:
> 1. This is really spammy and unfortunate (and getting these removed
> will be a PITA after we actually do get a key & value based API), but
> we take the additional option in.
> 2. This is apparently a low usage option and the amount of AVOptions
> in this encoder is getting higher and higher, thus we deny the patch
> until a key, value based API is provided.
>
> Personally I lean somewhat towards 2, but if the option is
> needed/useful (use cases can be provided), then begrudgingly I could
> go for 1.
>
> So far the lack of comments has mostly been regarding people not
> having high enough stakes/care regarding this module, methinks?
>
> Jan
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-devel mailing list