[FFmpeg-devel] [PATCH] libavfilter-soc: make scale algorithm configurable

Stefano Sabatini stefano.sabatini-lala
Sun Feb 15 18:33:44 CET 2009


On date Saturday 2009-02-14 19:03:54 +0100, Michael Niedermayer encoded:
> On Sat, Feb 14, 2009 at 02:24:22PM +0100, Stefano Sabatini wrote:
> > On date Friday 2009-02-13 03:10:26 +0100, Michael Niedermayer encoded:
> > > On Fri, Feb 13, 2009 at 02:13:38AM +0100, Stefano Sabatini wrote:
> > > > On date Monday 2009-02-09 19:45:06 +0100, Michael Niedermayer encoded:
> > > > > On Sun, Feb 08, 2009 at 11:45:34PM +0100, Stefano Sabatini wrote:
> > > > > > On date Sunday 2009-02-08 03:01:37 +0100, Michael Niedermayer encoded:
> > > > > > > On Sat, Feb 07, 2009 at 08:30:01PM +0100, Stefano Sabatini wrote:
> > > > [...]
> > > > > > > > But I agree on the limitation of the libswscale API, ideally maybe we
> > > > > > > > should be able to pass in the opaque a pointer to an already allocated
> > > > > > > > swscale context already containing sws flags + vectors + whatever,
> > > > > > > > which we could allocate with something like:
> > > > > > > 
> > > > > > > am i missing something that make this opaque stuff needed, compared to
> > > > > > > simply passing char* ?
> > > > > > 
> > > > > > I'd like to avoid to convert the sws_flags of the AVFilterGraph to a
> > > > > > string when creating and inserting the scale filter.
> > > > > > 
> > > > > > The scale filter should be able to accept in input the sws context
> > > > > > parameters from the args string.
> > > > > > 
> > > > > > But using the args interface for passing the flags from the
> > > > > > AVFilterGraph sws_flags to the scale filter is quite awkward, and
> > > > > > involves doing snprintf in the
> > > > > > query_formats/avfilter_graph_config_formats() code.
> > > > > 
> > > > > i think i prefer if args is used instead of doing funny things with
> > > > > opaque dummy contexts
> > > > 
> > > > New patch, but I still would prefer a solution using somehow a
> > > > SwsContext in the AVFilterGraph.
> > > 
> > > i suspect we see this from a differnt point of view ...
> > > iam scared of passing 5 filter private contexts around randomly in
> > > AVFi*
> > > 
> > > now its just sws but that might change ...
> > > and a string is much clearer in that case ...
> > 
> > Fine, and we can change it later if we extend the lsws API, lavfi
> > major bumps shouldn't be too much an issue at this early stage.
> > 
> > Waiting for review/OK.
> > 
> > A possible issue we have now is that we need to escape the '=' char in
> > the command, for example:
> > 
> > ffplay ~/samples/asian-commercials-are-weird.flv -vfilters "scale=300:200:sws_flags\=experimental+bitexact+full_chroma_inp"
> > 
> > If we don't want to require such escaping for the '=' char, we could
> > apply the attached patch, but I'm not sure it's a good idea.
> 
> no comment about the patch but IMO the parser must not eat =

Another problem, I just noticed that with the patches applied ffplay
fails with:
swScaler: Exactly one scaler algorithm must be chosen

because it doesn't set the sws_flags in the AVFilterGraph.
Possible solutions:

1) make ffplay define sws_flags and set it in the AVFilterGraph.

2) make avfilter_graph_config_formats() use a default value when the
value for sws_flags in the graph is 0.

3) make avfilter_graph_config_formats() simply do not pass the
sws_flags to the auto-inserted scale filters when the sws_flags value
is 0, this way vf_scale use its own default value.

I cannot resolve myself on which solution (or a combination of them)
is the best.

Regards.
-- 
FFmpeg = Funny Frightening Majestic Puritan Extreme Governor




More information about the ffmpeg-devel mailing list