On Sun, 9 Aug 2015 13:12:34 +0200 Michael Niedermayer <mich...@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 <mich...@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.) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
