[FFmpeg-devel] [PATCH v2 2/3] libavcodec: add a new AV_CODEC_EXPORT_DATA_FILM_GRAIN flag and option

[Lynne]

Nov 26, 2020, 16:21 by jamrial at gmail.com:

> On 11/17/2020 8:15 AM, Lynne wrote:
>
>> Nov 17, 2020, 10:58 by anton at khirnov.net:
>>
>>> Quoting Lynne (2020-11-17 00:21:43)
>>>
>>>> Nov 16, 2020, 15:56 by ffmpeg at haasn.xyz:
>>>>
>>>>> In terms of an API user needing this functionality, the way I see it
>>>>> working is that presence of the side-data will imply that it still needs
>>>>> to be applied, with the side data being removed the moment grain
>>>>> actually is applied. So that means that decoders applying film grain
>>>>> must never export this side data, and decoders not applying film grain
>>>>> must always export this side data.
>>>>>
>>>>> A decoder both applying grain and exporting the side data is
>>>>> nonsensical, and would only result in double-grain-application. In terms
>>>>> of the capability checking, I don't need you to tell me whether or not
>>>>> the decoder can apply/export side data or not, rather, I need to tell
>>>>> *you* whether or not I can apply film grain myself. This is what I
>>>>> understand AV_CODEC_EXPORT_DATA_FILM_GRAIN to be. Whether or not it's
>>>>> actually exported when that flag is present is irrelevant to me, all I'm
>>>>> trying to do is signaling that I'd prefer film grain to be exported
>>>>> rather than applied.
>>>>>
>>>>
>>>> Yup, that's my idea of how this should work as well.
>>>> Maybe even analyzers should want to skip applying film grain in a majority
>>>> of cases or apply it independently. So I still think of having an export
>>>> flag control the decoder behavior is acceptable in this case.
>>>>
>>>
>>> It's not about majority vs. minority, the question is
>>> "is there EVER a valid reason to apply AND export?"
>>> If the answer is yes, then there needs to be a way to do that. The flag
>>> you're proposing explicitly says you can do either one or the other, but
>>> never both.
>>>
>>
>> That's a kinda black and white view. We have both APIs that don't allow very
>> common cases to be handled and are creating us problems and we have APIs
>> which allow for completely unreasonable things to happen and are creating
>> us problems as well.
>> I don't think there's a reasonable non-contrived case in which you'd want to
>> both export and apply film grain. But I also didn't think there's a reasonable
>> case to ever need to chain demuxers and decoders.
>>
>
> Just to check, The existence of this flag as it was defined implies there should not be an "apply grain" avoption in decoders that can export such params as side data, to avoid conflicts, right? The flag alone is meant to control if film grain is applied, or exported.
>
> Now, what about decoders that can't export film grain params as side data? Take for example QSV, which may not allow it. Should such decoders offer an avoption to apply film grain or not? For those, the export flag can't be used to disable applying film grain because it can't also fulfill the "export" part of its purpose.
>

I think if the decoder doesn't support exporting it, it should apply it under all circumstances,
as otherwise correct presentation would be affected.
I think this is a pretty fringe problem right now as it only affects decoders independent of
av1dec, and given its meant to be applied during presentation time, I think those decoders
should implement support for exporting it while its not too late rather than having debugging
options for disabling it, which aren't really useful outside of debugging.