[FFmpeg-devel] [PATCH 3/3] vf_colorspace: Allow overriding input color properties

[Vittorio Giovara]

On Fri, Aug 26, 2016 at 5:16 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi,
>
> On Fri, Aug 26, 2016 at 2:40 PM, Vittorio Giovara
> <vittorio.giovara at gmail.com> wrote:
>>
>> On Fri, Aug 26, 2016 at 12:59 AM, Ronald S. Bultje <rsbultje at gmail.com>
>> wrote:
>> > Hi Vittorio,
>> >
>> > On Thu, Aug 25, 2016 at 7:14 PM, Vittorio Giovara
>> > <vittorio.giovara at gmail.com> wrote:
>> >>
>> >> The filter needs input frames with color properties filled out by
>> >> the decoder. Since this is not always possible, add input options to
>> >> the filter so that user may override color space, color primaries,
>> >> transfer characteristics, and color range.
>> >>
>> >> Signed-off-by: Vittorio Giovara <vittorio.giovara at gmail.com>
>> >> ---
>> >> Please keep me in CC.
>> >> Vittorio
>> >
>> > [..]
>> >
>> > Do you think it makes sense to have a "iall" property, similar to "all"?
>> > iprm/irange/itr/iprimeries would take precedence over iall, but iall
>> > could
>> > be used to set all 4 at once in the (common) case where they are
>> > consistent.
>>
>> Hi Ronald,
>> I had thought of that, but I am not sure.
>>
>> In order to "guess" the input parameters one would need to rely on
>> either an external analyzer, which is going to report properties one
>> by one, or determine them via various heuristics: this latter case
>> might not be very precise, so one could decide to avoid performing
>> conversion altogether, or only perform it if some of the color
>> properties are already present (so that you'd only need to override
>> one or two).
>>
>> Also I found that it's hard to identify a common consistent format:
>> for example, my files are often tagged with a mixture of bt470bg,
>> bt470m or smpte formats, and none follow a sensible pattern (with the
>> exception of bt709). So overall I'd say this `iall` option is not
>> really need, but if open to other opinions too.
>
>
> "iall" indeed is not perfect, which is why the per-type properties exist
> also. But it works reliably for bt709, smpte170/240 and bt2020, afaik.
>
> What I mused on this subject earlier is that the "iall", like "all", would
> likely be not very useful for professional (prod) applications, but it would
> make "quick hack" uses of the filter relatively easy. It saves me typing a
> whole bunch of characters for something quick I'm testing, and as such it
> saves valuable developer time. For prod versions, of course you'd want to be
> as specific as possible and you likely wouldn't use it.
>
> Ronald

All right, I'll add it, thanks for review.
-- 
Vittorio