Gentle ping :) On Mon, Nov 9, 2020 at 11:00 AM Bohan Li <boha...@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 <boha...@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 <jee...@gmail.com> wrote: >> >>> On Fri, Nov 6, 2020 at 11:46 AM Steven Liu <l...@chinaffmpeg.org> wrote: >>> > >>> > >>> > >>> > > 2020年11月6日 下午4:42，Bohan Li <boha...@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@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> >> _______________________________________________ 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".
