[FFmpeg-devel] Evolution of lavfi's design and API

[Nicolas George]

Le duodi 2 brumaire, an CCXXIII, Clement Boesch a écrit :
> I'd be curious to hear about how VapourSynth & friends handle that
> problem, because AFAIK it's only one way. It's likely they don't have to
> deal with the same problems we have though (the usage is more limited, no
> audio typically); typically because they don't seem stream but file based
> (so easy to index and exact seek etc.).

I am not sure what you mean here. This was about recursive design. It is not
very difficult to turn the recursive design into an iterative one: just
handle the call stack manually. In this particular case, most of the filters
use only tail-recursion ("return ff_filter_frame(outlink, frame);"), so
there is even no need to handle a stack: just replace the function calls by
message passing.

People here seem impressed by VapourSynth's "nice" python syntax to build
scripts, but it does not look extraordinary to me. I am convinced this is
"just" a syntax to build the graph. For example, where lavfi requires to
write "[v][s]overlay=x=42:y=12[vs]", VapourSynth would require something
like "vs = v.overlay(s, 42, 12)". Just a syntactic matter. The actual work
certainly happens when the graph is connected to its output.

I believe it would be rather easy to have the same kind of interface for
lavfi; all the filters are already introspectable, and that is the most
major point. Unfortunately, two issues would make it of little use. First,
lavfi handles only frames, not packets, so all the encoding and muxing would
have to be handled separately. Second, lavfi is designed to make a lot of
format decisions when the graph is complete, so the scripting capabilities
would not have a lot of relevant information to work on. I wonder how
VapourSynth handles that, but I am afraid to learn that it just do automatic
conversions on the spot without globally optimizing them.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141024/c5ee8353/attachment.asc>