[MPlayer-G2-dev] Re: Limitations in vo2 api :(

[D Richard Felker III]

On Tue, Dec 23, 2003 at 06:13:42PM +0200, Andriy N. Gritsenko wrote:
> >No individual filter needs to know. Rather, vp_pull_frame does. For
> >various reasons, the recursive calling was abandoned in favor of a
> >"walk-the-list" approach.
> 
>     Hmm, so you want to deny direct pulling frames by filters? If it's so
> then how you suppose to handle such filters as "interleaving mixer" (two
> frames from one then three frames from second then one frame from third,
> and again from one, for example) or "time-scaling" (i.e. scaling clip
> from 0.2s long to 1.15s)? Or if you allow direct pulling frames then how
> your vf_pull_frame() will count them? I wonder if that possible without
> direct pulling frames by filter because only filter may know how much
> portion of video it wants and only filter may know if it wish just drop
> frame or change it's PTS/duration.

Again, please _read_ the fine documentation and (maybe not-so-fine)
source. :)

Nodes of the pipeline call vp_request_frame() on a link when they want
to receive a frame over it. So it's still entirely pull based, just
not carried out by call-recursion.

Originally I thought call recursion was the most graceful and simple
way to run the pipeline, but it requires ugly hacks for auto-inserting
filters (which Arpi didn't like, and I eventually came to agree with),
and it makes it impossible to bail-out early (for example, to return
to the caller once a certain amount of time has passed, so the caller
can process user input, and then resume filtering where we left off
later). The new system is not _quite_ as graceful, but it's not ugly
or awkward either. I think Ivan prefers the new way a lot too, even
though it's not quite what he had in mind.

Rich