[MPlayer-G2-dev] Re: Limitations in vo2 api :(
Andriy N. Gritsenko
andrej at lucky.net
Tue Dec 23 12:14:06 CET 2003
Hi, D Richard Felker III!
I've already decided to don't continue that thread but it seems I must to
resolve last possible misunderstandings.
First of all, Rich, thank you for all criticism. :) I would never think
if my sincere wish to avoid manipulating node structure by application is
something like C++ (since I don't like C++ very much). OK, I've stopped
I've seen your VP layer progress. I don't have any objections. And since
you said it's internal side for now it looks fine. Only thing I want ask
you is to keep in mind (when you'll do application-side API) two moments:
1. muxer must get frames in some unified form independent from it's type.
It's why I wanted layer-independent node structure in the beginning.
2. since filters may put links in the node structure as they wish then
application cannot touch any of vp_link_t pointers in vp_node_t so for
application-side API I want to have some functions to manipulate (set
and remove) these pointers.
So it's all. :)
Sometime (on Tuesday, December 23 at 12:08) I've received something...
>The internal vp code has to be able to walk the pipeline for
>rendering, so it needs to know something...
It seems I don't understand something. We construct pipeline to get
frames via pull_frame(), don't we? So if pipeline is something alike
--> vp_node1 --> vp_node2 --> vp_node3 then vp_node3 will pull frame
from vp_node2 but vp_node3 has no needs to know if vp_node1 exists or
not. vp_node2 will give frame to vp_node3 from pending buffer or after
pulling it out from vp_node1. So no filter in pipeline need to know _all_
pipeline but _only_ own previous and next nodes, i.e. own links. If I'm
wrong then kick me there, please. ;)
With best wishes.
Thank you for your work.
More information about the MPlayer-G2-dev