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

Ronald S. Bultje rsbultje at gmail.com
Sat Aug 27 00:16:53 EEST 2016


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


More information about the ffmpeg-devel mailing list