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

[Andriy N. Gritsenko]

    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
on that.

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.
    Andriy.