On Fri, Aug 26, 2016 at 5:16 PM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > 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
All right, I'll add it, thanks for review. -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
