[FFmpeg-devel] [PATCH] swscale: Make sws_alloc_set_opts() public

[wm4]

On Sun, 9 Aug 2015 13:12:34 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Sat, Aug 08, 2015 at 07:45:23PM +0200, wm4 wrote:
> > On Sat, 8 Aug 2015 19:05:39 +0200
> > Michael Niedermayer <michael at niedermayer.cc> wrote:
> > 
> > > > Where are the
> > > > input and output colorspaces and ranges set?
> > > 
> > > they would be set with sws_setColorspaceDetails()
> > 
> > But they're pretty important, so why aren't they part of the parameter
> > list too? In the end, the parameter list would grow too long. Or it
> > would be kind of inconsistent. (Maybe convenience functions like e.g.
> > "sws_set_input_size()" would be helpful without being terribly
> > unorthogonal.)
> > 
> > > > There's my very old patch, which made libswscale transparently set the
> > > > parameters of an input AVFrame. This would actually be the simplest API.
> > > 
> > > can you update the patch so the comments raised by stefano are taken
> > > care of ?
> > 
> > My main worry about this is that if new fields are added to AVFrame,
> > the new libswscale API would have to pick them up and adjust the scaler
> > settings accordingly. So if the user was setting this option manually,
> > a change to libswscale setting this option automatically from AVFrame
> > would break the user code.
> > 
> 
> > Distinguish between set and unset options might help here.
> 
> yes, and most fields have a "not set" value,
> AVCOL_RANGE_UNSPECIFIED, AVCHROMA_LOC_UNSPECIFIED,
> AVCOL_SPC_UNSPECIFIED, ...
> 
> so that should not be a problem

To expand on this: my patch sets these parameters in the scaler
function (from the AVFrame functions). So if I use these "unspecified"
values, I could avoid overriding user settings, but I also couldn't
transparently reconfigure swscale if the AVFrame input format changes.
(And I think making it able to handle this is a worthy goal.)