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

[Bohan Li]

I have added a feature request in the libaom issue tracker for the key &
value api, although it may take some time for the api to land. Meanwhile I
still suggest that we apply this patch to ffmpeg since as mentioned this
option can be quite important for subjective quality control.
Please let me know if there are any concerns.

Thanks!
Bohan

On Fri, Nov 6, 2020 at 9:31 AM Bohan Li <bohanli at google.com> wrote:

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