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

[Michael Niedermayer]

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 =

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090214/e12f6c96/attachment.pgp>