[FFmpeg-devel] [PATCH 2/6] sink_buffer: make opaque argument optional.

[Clément Bœsch]

On Sun, Jul 01, 2012 at 11:57:55PM +0200, Stefano Sabatini wrote:
> On date Sunday 2012-07-01 15:09:14 +0200, Nicolas George encoded:
> > Le decadi 10 messidor, an CCXX, Stefano Sabatini a écrit :
> [...]
> > > As for what regards the syntax, many filters were ported from mplayer
> > > and we tried to keep the same syntax, also when we started working on
> > > lavfi many parsing facilities were not available (opt/error/eval in
> > > libavcodec, no parsing facilities).
> > 
> > Thanks for the explanations. Do not take my mail for a reproach about the
> > past, but as ideas for the future.
> 
> No offense taken, I just believed that it was useful to explain why
> things are the way they are, which could make more or less sense
> depending on the knowledge of the past codebase history.
>  
> > > This would require a custom API for each filter which needs opaque
> > > data, which seems a worse solution than the previous one (before the
> > > opaque field "cleanup").
> > 
> > The declaration of the opaque structure is already a custom API for each
> > filter. The function to allocate said structure so as not to make it size
> > part of the ABI even more so (but this one could be avoided with a field
> > "opaque_size" in the filter structure).
> > 
> 
> > I do not see the problem with custom API, provided they are well designed
> > and consistent. Gtk+ does that for object creation, and it never bothered
> > me, for example.
> 
> A struct *is* an object in a way, and provides already the most
> flexible way (from the programmer point of view) for passing around
> data, provided that you put some care when doing it, and in my
> experience that's hardly a problem, and it is usually less problematic
> than figuring out how to use a custom API (and requires less mental
> effort to the programmer - she just need to pass around this and this
> to the init function, no need to juggle around with layers and layers
> of OO-obsessed APIs).
>  
> > The other solution would be to use AVOption extensively, but that would
> > require a redesign of the init mechanism (init assumes that all the
> > arguments are already set), and extending it with more complex types (lists,
> > to begin with).
> 
> Anyway I'm not against an alternative solution, if can work and is not
> less flexible than opaque struct passing.
> 

I don't know if it's been already proposed but haven't you the possibility
to add a second init function taking an opaque instead of a string?; this
would simplify compatibility with Libav (we would just have an alternate
init function, not incompatible with the first).

Another hack: use the AVOption to pass a flag indicating if the arg is a
string or a pointer-to-struct.

[...]

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120702/8d691885/attachment.asc>