Nov 26, 2020, 16:21 by jamr...@gmail.com: > On 11/17/2020 8:15 AM, Lynne wrote: > >> Nov 17, 2020, 10:58 by an...@khirnov.net: >> >>> Quoting Lynne (2020-11-17 00:21:43) >>> >>>> Nov 16, 2020, 15:56 by ffm...@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. _______________________________________________ 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".
