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

[Bohan Li]

Gentle ping :)

On Mon, Nov 9, 2020 at 11:00 AM Bohan Li <bohanli at google.com> wrote:

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