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

[D Richard Felker III]

On Wed, Dec 24, 2003 at 11:54:06AM +0200, Andriy N. Gritsenko wrote:
>     Hi, D Richard Felker III!
> 
> Sometime (on Wednesday, December 24 at  8:37) I've received something...
> 
> >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.
> 
>     I've read your source. You assume that ->out and ->in are always
> filled and ->xout and ->xin are NULL-terminated lists. So you will deny
> filters and/or application don't have "primary" link. It's bad. Many
> filters may not have any priority and may want to have all links in one
> list. Beside of that that "primary" link may be deleted while "secondary"
> ones will still work so it may be a problem (as I already said).

Then reorder the links. It doesn't matter. This is NOT an issue worth
wasting time and complexity over. The 2 or 3 filters that actually
want to use multiple inputs or outputs can manage their lists.

>     To allow only layer manipulate links list is also impossible - only
> filter may know if it's possible to add second (third, fourth, etc.) link
> to list since it may depend on filter's current state. So adding and
> deleting links to(from) list must be controlled by filter itself. Isn't
> it an another problem for your current implementation?

No. It's not implemented because I am trying to make something that
works in this lifetime. That is sharply different from being a
problem. My design goal for multiple inputs/outputs in G2 is to make
sure there are no fundamental _obstacles_ to their implementation. But
I don't care about having them work anytime soon, since what I want is
a working mplayer-g2 and mencoder-g2.

BTW, of course the filter is involved in adding/removing links in some
way. We can decide on the exact method by which this is done MUCH
LATER, once playing movies and backing up DVDs works.

>     Again my questions. :)  If some filter wants to get a frame from one
> of links it must call vp_request_frame() then call vp_pull_frame(),
> doesn't it?

No, vp_pull_frame may NEVER be called by filers. To do so would be
recursive calling. If you need frames before you can process, you must
use vp_request_frame then RETURN.

> It seems overcomplicated for me but that time wasting isn't a
> big problem for current CPUs anyway so OK. Another thing is when filter
> from which we want a frame must drop a frame - will pull_frame() return 1
> then but with img=NULL?

No, an image MUST be returned because it contains pts. If a frame is
going to be dropped, you are free to return an image without filling
in the picture buffers. You can even use BUF_TYPE_DUMMY.

>     And another thing - must each filter implement push_frame()? I'm not
> sure if it's always possible.

If a filter doesn't want to, it can use the default implementation,
which will just store the image. In fact, filters that just process
each frame's contents independently are _encouraged_ to use the
simplified process_frame api, which is provided by leaving the default
implementations of push_frame and pull_frame in place.

>     Yet one question. Application may want get frames by something like
> got_frame=request_frame(start_pts,max_duration,*new_pts) and that frame

WTF? This is nonsense. When you get a frame, you always get the next
frame, ordered by time. If it doesn't have the pts you want, you pull
another. And another. Until you have the one you want. If you want
your silly request-by-pts api, you can make a wrapper to do this.

> may consume sources: three frames from first, no frames from second and
> one frame from third - just for example. Does your new VP implementation
> allow that? :)

Huh?? The notion of 'source' no longer exists at this point. The
application pulls from the end of the chain.

>     Anyway, don't be mad on me, please. I just want G2 to handle all
> needs of video editor (such as Adobe Premiere for example). I'm sure G2
> may be power enough to hahdle that task. Although one of my friends has
> told me G2 based video editor will not be finished while he's alive. ;)
> May be I'm naive but remember that Adam Rice said: "paradigm shifts often
> require a certain naivety". I liked that. :)))

Then let someone naive go make shitware like Adobe premier that only
supports a few colorspaces, doesn't support variable-fps formats with
exact rational timestamps, doesn't let filters retime the frames,
copies the image buffers ten times as often as needed so it's
incredibly slow, etc. etc. etc. Meanwhile I'll be writing something
that doesn't suck...

Rich