Hi,

On Fri, Aug 26, 2016 at 2:40 PM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> On Fri, Aug 26, 2016 at 12:59 AM, Ronald S. Bultje <rsbul...@gmail.com>
> wrote:
> > Hi Vittorio,
> >
> > On Thu, Aug 25, 2016 at 7:14 PM, Vittorio Giovara
> > <vittorio.giov...@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.giov...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to