| Message ID | 20160825231459.15314-3-vittorio.giovara@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
Hi Vittorio, On Thu, Aug 25, 2016 at 7:14 PM, Vittorio Giovara < vittorio.giovara@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@gmail.com> > --- > Please keep me in CC. > Vittorio > [..] > @@ -1014,6 +1022,9 @@ static const AVOption colorspace_options[] = { > { "space", "Output colorspace", > OFFSET(user_csp), AV_OPT_TYPE_INT, { .i64 = AVCOL_SPC_UNSPECIFIED > }, > AVCOL_PRI_RESERVED0, AVCOL_PRI_NB - 1, FLAGS, "csp" }, > + { "ispace", "Input colorspace", > + OFFSET(user_icsp), AV_OPT_TYPE_INT, { .i64 = AVCOL_SPC_UNSPECIFIED > }, > + AVCOL_PRI_RESERVED0, AVCOL_PRI_NB - 1, FLAGS, "csp" }, > ENUM("bt709", AVCOL_SPC_BT709, "csp"), > ENUM("fcc", AVCOL_SPC_FCC, "csp"), > ENUM("bt470bg", AVCOL_SPC_BT470BG, "csp"), > @@ -1024,12 +1035,18 @@ static const AVOption colorspace_options[] = { > { "range", "Output color range", > OFFSET(user_rng), AV_OPT_TYPE_INT, { .i64 = > AVCOL_RANGE_UNSPECIFIED }, > AVCOL_RANGE_UNSPECIFIED, AVCOL_RANGE_NB - 1, FLAGS, "rng" }, > + { "irange", "Input color range", > + OFFSET(user_irng), AV_OPT_TYPE_INT, { .i64 = > AVCOL_RANGE_UNSPECIFIED }, > + AVCOL_RANGE_UNSPECIFIED, AVCOL_RANGE_NB - 1, FLAGS, "rng" }, > ENUM("mpeg", AVCOL_RANGE_MPEG, "rng"), > ENUM("jpeg", AVCOL_RANGE_JPEG, "rng"), > > { "primaries", "Output color primaries", > OFFSET(user_prm), AV_OPT_TYPE_INT, { .i64 = AVCOL_PRI_UNSPECIFIED > }, > AVCOL_PRI_RESERVED0, AVCOL_PRI_NB - 1, FLAGS, "prm" }, > + { "iprimaries", "Input color primaries", > + OFFSET(user_iprm), AV_OPT_TYPE_INT, { .i64 = AVCOL_PRI_UNSPECIFIED > }, > + AVCOL_PRI_RESERVED0, AVCOL_PRI_NB - 1, FLAGS, "prm" }, > ENUM("bt709", AVCOL_PRI_BT709, "prm"), > ENUM("bt470m", AVCOL_PRI_BT470M, "prm"), > ENUM("bt470bg", AVCOL_PRI_BT470BG, "prm"), > @@ -1040,6 +1057,9 @@ static const AVOption colorspace_options[] = { > { "trc", "Output transfer characteristics", > OFFSET(user_trc), AV_OPT_TYPE_INT, { .i64 = AVCOL_TRC_UNSPECIFIED > }, > AVCOL_TRC_RESERVED0, AVCOL_TRC_NB - 1, FLAGS, "trc" }, > + { "itrc", "Input transfer characteristics", > + OFFSET(user_itrc), AV_OPT_TYPE_INT, { .i64 = AVCOL_TRC_UNSPECIFIED > }, > + AVCOL_TRC_RESERVED0, AVCOL_TRC_NB - 1, FLAGS, "trc" }, > ENUM("bt709", AVCOL_TRC_BT709, "trc"), > ENUM("gamma22", AVCOL_TRC_GAMMA22, "trc"), > ENUM("gamma28", AVCOL_TRC_GAMMA28, "trc"), 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. Ronald
On 8/26/16, Vittorio Giovara <vittorio.giovara@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@gmail.com> > --- > Please keep me in CC. > Vittorio > > libavfilter/vf_colorspace.c | 28 ++++++++++++++++++++++++---- > 1 file changed, 24 insertions(+), 4 deletions(-) Generally, new options should be added after old ones.
On Fri, Aug 26, 2016 at 12:59 AM, Ronald S. Bultje <rsbultje@gmail.com> wrote: > Hi Vittorio, > > On Thu, Aug 25, 2016 at 7:14 PM, Vittorio Giovara > <vittorio.giovara@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@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.
On Fri, Aug 26, 2016 at 3:52 AM, Paul B Mahol <onemda@gmail.com> wrote: > On 8/26/16, Vittorio Giovara <vittorio.giovara@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@gmail.com> >> --- >> Please keep me in CC. >> Vittorio >> >> libavfilter/vf_colorspace.c | 28 ++++++++++++++++++++++++---- >> 1 file changed, 24 insertions(+), 4 deletions(-) > > Generally, new options should be added after old ones. I added closer to the original options because they share exactly the same input values, and seemed to logically belong there: in case an option is added to or removed from the group, the developer can immediately notice that the change is going to affect both options.
On Fri, Aug 26, 2016 at 02:43:35PM -0400, Vittorio Giovara wrote: > On Fri, Aug 26, 2016 at 3:52 AM, Paul B Mahol <onemda@gmail.com> wrote: > > On 8/26/16, Vittorio Giovara <vittorio.giovara@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@gmail.com> > >> --- > >> Please keep me in CC. > >> Vittorio > >> > >> libavfilter/vf_colorspace.c | 28 ++++++++++++++++++++++++---- > >> 1 file changed, 24 insertions(+), 4 deletions(-) > > > > Generally, new options should be added after old ones. > > I added closer to the original options because they share exactly the > same input values, and seemed to logically belong there: in case an > option is added to or removed from the group, the developer can > immediately notice that the change is going to affect both options. The problem with not adding them at the end is that it breaks user interface: order matters when your specifying successive options without explicit keys. You don't want to break user scripts randomly. Regards,
On Fri, Aug 26, 2016 at 08:58:57PM +0200, Clément Bœsch wrote: > On Fri, Aug 26, 2016 at 02:43:35PM -0400, Vittorio Giovara wrote: > > On Fri, Aug 26, 2016 at 3:52 AM, Paul B Mahol <onemda@gmail.com> wrote: > > > On 8/26/16, Vittorio Giovara <vittorio.giovara@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@gmail.com> > > >> --- > > >> Please keep me in CC. > > >> Vittorio > > >> > > >> libavfilter/vf_colorspace.c | 28 ++++++++++++++++++++++++---- > > >> 1 file changed, 24 insertions(+), 4 deletions(-) > > > > > > Generally, new options should be added after old ones. > > > > I added closer to the original options because they share exactly the > > same input values, and seemed to logically belong there: in case an > > option is added to or removed from the group, the developer can > > immediately notice that the change is going to affect both options. > > The problem with not adding them at the end is that it breaks user > interface: order matters when your specifying successive options without you're* sorry for any triggering it caused.
Hi, On Fri, Aug 26, 2016 at 2:40 PM, Vittorio Giovara < vittorio.giovara@gmail.com> wrote: > On Fri, Aug 26, 2016 at 12:59 AM, Ronald S. Bultje <rsbultje@gmail.com> > wrote: > > Hi Vittorio, > > > > On Thu, Aug 25, 2016 at 7:14 PM, Vittorio Giovara > > <vittorio.giovara@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@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
On Fri, Aug 26, 2016 at 5:16 PM, Ronald S. Bultje <rsbultje@gmail.com> wrote: > Hi, > > On Fri, Aug 26, 2016 at 2:40 PM, Vittorio Giovara > <vittorio.giovara@gmail.com> wrote: >> >> On Fri, Aug 26, 2016 at 12:59 AM, Ronald S. Bultje <rsbultje@gmail.com> >> wrote: >> > Hi Vittorio, >> > >> > On Thu, Aug 25, 2016 at 7:14 PM, Vittorio Giovara >> > <vittorio.giovara@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@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.
On Tue, Aug 30, 2016 at 4:13 AM, Paul B Mahol <onemda@gmail.com> wrote: > > > On Mon, Aug 29, 2016 at 5:53 PM, Ronald S. Bultje <rsbultje@gmail.com> > wrote: >> >> Hi, >> >> On Mon, Aug 29, 2016 at 11:23 AM, Vittorio Giovara < >> vittorio.giovara@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, as well as a generic option >> > to set all properties at once. >> > >> > Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com> >> > --- >> > * added iall option >> > * updated filter documentation >> > >> > Please CC. >> > Vittorio >> > >> > doc/filters.texi | 20 ++++++++++++++++++++ >> > libavfilter/vf_colorspace.c | 39 >> > ++++++++++++++++++++++++++++++++++----- >> > 2 files changed, 54 insertions(+), 5 deletions(-) >> >> >> lgtm. >> >> (I wonder if the error message - if the input AVFrame has no >> trc/rng/csp/prm - should be changed to reflect that you can override them >> using the added properties? This isn't a big deal but maybe someone feels >> that's important.) > > > Still breaks backward compatibility. I fail to see how, can you provide more details?
On Tuesday, August 30, 2016, Vittorio Giovara <vittorio.giovara@gmail.com> wrote: > On Tue, Aug 30, 2016 at 4:13 AM, Paul B Mahol <onemda@gmail.com > <javascript:;>> wrote: > > > > > > On Mon, Aug 29, 2016 at 5:53 PM, Ronald S. Bultje <rsbultje@gmail.com > <javascript:;>> > > wrote: > >> > >> Hi, > >> > >> On Mon, Aug 29, 2016 at 11:23 AM, Vittorio Giovara < > >> vittorio.giovara@gmail.com <javascript:;>> 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, as well as a generic option > >> > to set all properties at once. > >> > > >> > Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com > <javascript:;>> > >> > --- > >> > * added iall option > >> > * updated filter documentation > >> > > >> > Please CC. > >> > Vittorio > >> > > >> > doc/filters.texi | 20 ++++++++++++++++++++ > >> > libavfilter/vf_colorspace.c | 39 > >> > ++++++++++++++++++++++++++++++++++----- > >> > 2 files changed, 54 insertions(+), 5 deletions(-) > >> > >> > >> lgtm. > >> > >> (I wonder if the error message - if the input AVFrame has no > >> trc/rng/csp/prm - should be changed to reflect that you can override > them > >> using the added properties? This isn't a big deal but maybe someone > feels > >> that's important.) > > > > > > Still breaks backward compatibility. > > I fail to see how, can you provide more details? when doing options without typing option name, but just values, like: val0:val1:...
On Tue, Aug 30, 2016 at 10:54 AM, Paul B Mahol <onemda@gmail.com> wrote: > > > On Tuesday, August 30, 2016, Vittorio Giovara <vittorio.giovara@gmail.com> > wrote: >> >> On Tue, Aug 30, 2016 at 4:13 AM, Paul B Mahol <onemda@gmail.com> wrote: >> > >> > >> > On Mon, Aug 29, 2016 at 5:53 PM, Ronald S. Bultje <rsbultje@gmail.com> >> > wrote: >> >> >> >> Hi, >> >> >> >> On Mon, Aug 29, 2016 at 11:23 AM, Vittorio Giovara < >> >> vittorio.giovara@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, as well as a generic >> >> > option >> >> > to set all properties at once. >> >> > >> >> > Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com> >> >> > --- >> >> > * added iall option >> >> > * updated filter documentation >> >> > >> >> > Please CC. >> >> > Vittorio >> >> > >> >> > doc/filters.texi | 20 ++++++++++++++++++++ >> >> > libavfilter/vf_colorspace.c | 39 >> >> > ++++++++++++++++++++++++++++++++++----- >> >> > 2 files changed, 54 insertions(+), 5 deletions(-) >> >> >> >> >> >> lgtm. >> >> >> >> (I wonder if the error message - if the input AVFrame has no >> >> trc/rng/csp/prm - should be changed to reflect that you can override >> >> them >> >> using the added properties? This isn't a big deal but maybe someone >> >> feels >> >> that's important.) >> > >> > >> > Still breaks backward compatibility. >> >> I fail to see how, can you provide more details? > > > > when doing options without typing option name, but just values, like: > val0:val1:... Oh I see, thanks. Isn't that syntax a little too fragile for this kind of filter? Or, from another perspective, is the filter old enough that backward compatibility should matter?
Hi, On Tue, Aug 30, 2016 at 10:00 AM, Vittorio Giovara < vittorio.giovara@gmail.com> wrote: > On Tue, Aug 30, 2016 at 4:13 AM, Paul B Mahol <onemda@gmail.com> wrote: > > > > > > On Mon, Aug 29, 2016 at 5:53 PM, Ronald S. Bultje <rsbultje@gmail.com> > > wrote: > >> > >> Hi, > >> > >> On Mon, Aug 29, 2016 at 11:23 AM, Vittorio Giovara < > >> vittorio.giovara@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, as well as a generic option > >> > to set all properties at once. > >> > > >> > Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com> > >> > --- > >> > * added iall option > >> > * updated filter documentation > >> > > >> > Please CC. > >> > Vittorio > >> > > >> > doc/filters.texi | 20 ++++++++++++++++++++ > >> > libavfilter/vf_colorspace.c | 39 > >> > ++++++++++++++++++++++++++++++++++----- > >> > 2 files changed, 54 insertions(+), 5 deletions(-) > >> > >> > >> lgtm. > >> > >> (I wonder if the error message - if the input AVFrame has no > >> trc/rng/csp/prm - should be changed to reflect that you can override > them > >> using the added properties? This isn't a big deal but maybe someone > feels > >> that's important.) > > > > > > Still breaks backward compatibility. > > I fail to see how, can you provide more details? You can use ordered, unnamed properties to configure filters (-vf colorspace=bt709:bt709:jpeg is identical to -vf colorspace=all=bt709:space=bt709:range=jpeg; this probably shows how range should've been before space to be especially useful, but whatever), and that breaks after this patch because you changed the ordering. Ronald
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c index 37e77d1..8ef362e 100644 --- a/libavfilter/vf_colorspace.c +++ b/libavfilter/vf_colorspace.c @@ -129,10 +129,10 @@ typedef struct ColorSpaceContext { ColorSpaceDSPContext dsp; enum Colorspace user_all; - enum AVColorSpace in_csp, out_csp, user_csp; - enum AVColorRange in_rng, out_rng, user_rng; - enum AVColorTransferCharacteristic in_trc, out_trc, user_trc; - enum AVColorPrimaries in_prm, out_prm, user_prm; + enum AVColorSpace in_csp, out_csp, user_csp, user_icsp; + enum AVColorRange in_rng, out_rng, user_rng, user_irng; + enum AVColorTransferCharacteristic in_trc, out_trc, user_trc, user_itrc; + enum AVColorPrimaries in_prm, out_prm, user_prm, user_iprm; enum AVPixelFormat in_format, user_format; int fast_mode; enum DitherMode dither; @@ -581,6 +581,8 @@ static int create_filtergraph(AVFilterContext *ctx, if (!s->out_primaries || !s->in_primaries) { s->in_prm = in->color_primaries; + if (s->user_iprm != AVCOL_PRI_UNSPECIFIED) + s->in_prm = s->user_iprm; s->in_primaries = get_color_primaries(s->in_prm); if (!s->in_primaries) { av_log(ctx, AV_LOG_ERROR, @@ -638,6 +640,8 @@ static int create_filtergraph(AVFilterContext *ctx, if (!s->in_txchr) { av_freep(&s->lin_lut); s->in_trc = in->color_trc; + if (s->user_itrc != AVCOL_TRC_UNSPECIFIED) + s->in_trc = s->user_itrc; s->in_txchr = get_transfer_characteristics(s->in_trc); if (!s->in_txchr) { av_log(ctx, AV_LOG_ERROR, @@ -680,7 +684,11 @@ static int create_filtergraph(AVFilterContext *ctx, if (!s->in_lumacoef) { s->in_csp = in->colorspace; + if (s->user_icsp != AVCOL_SPC_UNSPECIFIED) + s->in_csp = s->user_icsp; s->in_rng = in->color_range; + if (s->user_irng != AVCOL_RANGE_UNSPECIFIED) + s->in_rng = s->user_irng; s->in_lumacoef = get_luma_coefficients(s->in_csp); if (!s->in_lumacoef) { av_log(ctx, AV_LOG_ERROR, @@ -1014,6 +1022,9 @@ static const AVOption colorspace_options[] = { { "space", "Output colorspace", OFFSET(user_csp), AV_OPT_TYPE_INT, { .i64 = AVCOL_SPC_UNSPECIFIED }, AVCOL_PRI_RESERVED0, AVCOL_PRI_NB - 1, FLAGS, "csp" }, + { "ispace", "Input colorspace", + OFFSET(user_icsp), AV_OPT_TYPE_INT, { .i64 = AVCOL_SPC_UNSPECIFIED }, + AVCOL_PRI_RESERVED0, AVCOL_PRI_NB - 1, FLAGS, "csp" }, ENUM("bt709", AVCOL_SPC_BT709, "csp"), ENUM("fcc", AVCOL_SPC_FCC, "csp"), ENUM("bt470bg", AVCOL_SPC_BT470BG, "csp"), @@ -1024,12 +1035,18 @@ static const AVOption colorspace_options[] = { { "range", "Output color range", OFFSET(user_rng), AV_OPT_TYPE_INT, { .i64 = AVCOL_RANGE_UNSPECIFIED }, AVCOL_RANGE_UNSPECIFIED, AVCOL_RANGE_NB - 1, FLAGS, "rng" }, + { "irange", "Input color range", + OFFSET(user_irng), AV_OPT_TYPE_INT, { .i64 = AVCOL_RANGE_UNSPECIFIED }, + AVCOL_RANGE_UNSPECIFIED, AVCOL_RANGE_NB - 1, FLAGS, "rng" }, ENUM("mpeg", AVCOL_RANGE_MPEG, "rng"), ENUM("jpeg", AVCOL_RANGE_JPEG, "rng"), { "primaries", "Output color primaries", OFFSET(user_prm), AV_OPT_TYPE_INT, { .i64 = AVCOL_PRI_UNSPECIFIED }, AVCOL_PRI_RESERVED0, AVCOL_PRI_NB - 1, FLAGS, "prm" }, + { "iprimaries", "Input color primaries", + OFFSET(user_iprm), AV_OPT_TYPE_INT, { .i64 = AVCOL_PRI_UNSPECIFIED }, + AVCOL_PRI_RESERVED0, AVCOL_PRI_NB - 1, FLAGS, "prm" }, ENUM("bt709", AVCOL_PRI_BT709, "prm"), ENUM("bt470m", AVCOL_PRI_BT470M, "prm"), ENUM("bt470bg", AVCOL_PRI_BT470BG, "prm"), @@ -1040,6 +1057,9 @@ static const AVOption colorspace_options[] = { { "trc", "Output transfer characteristics", OFFSET(user_trc), AV_OPT_TYPE_INT, { .i64 = AVCOL_TRC_UNSPECIFIED }, AVCOL_TRC_RESERVED0, AVCOL_TRC_NB - 1, FLAGS, "trc" }, + { "itrc", "Input transfer characteristics", + OFFSET(user_itrc), AV_OPT_TYPE_INT, { .i64 = AVCOL_TRC_UNSPECIFIED }, + AVCOL_TRC_RESERVED0, AVCOL_TRC_NB - 1, FLAGS, "trc" }, ENUM("bt709", AVCOL_TRC_BT709, "trc"), ENUM("gamma22", AVCOL_TRC_GAMMA22, "trc"), ENUM("gamma28", AVCOL_TRC_GAMMA28, "trc"),
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@gmail.com> --- Please keep me in CC. Vittorio libavfilter/vf_colorspace.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)