Quoting Mark Reid (2020-05-07 03:16:17)
> On Wed, May 6, 2020 at 1:07 PM Anton Khirnov <an...@khirnov.net> wrote:
>
> > Quoting mindm...@gmail.com (2020-04-29 05:02:35)
> > > From: Mark Reid <mindm...@gmail.com>
> > >
> > > ---
> > > libavcodec/exr.c | 103 +++++++++++++++++++++++++++++++++++++++--------
> > > 1 file changed, 86 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> > > @@ -1888,6 +1955,8 @@ static const AVOption options[] = {
> > > AV_OPT_TYPE_STRING, { .str = "" }, 0, 0, VD },
> > > { "gamma", "Set the float gamma value when decoding", OFFSET(gamma),
> > > AV_OPT_TYPE_FLOAT, { .dbl = 1.0f }, 0.001, FLT_MAX, VD },
> > > + { "float", "Output frame in floating point pixel format, apply_trc
> > does not get applied", OFFSET(output_float),
> > > + AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, VD},
> >
> > Wouldn't it make more sense to export the coded format rather than have
> > an option like this?
> >
> >
> I could do that, I just was worried about breaking any user's use case. But
> now that I think about it, I don't think it would, and I think that would
> be simpler.
Yes, if swscale supports this then it shouldn't cause problems.
I believe the general rule is that decoders should export the native
format inasmuch as possible and avoid doing conversion internally.
--
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
