Re: Re: Limitations in vo2 api :(
D Richard Felker III <[email protected]>
| Newsgroups | gmane.comp.video.mplayer.g2.devel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Dec 22, 2003 at 01:51:16PM +0200, Andriy N. Gritsenko wrote: > >I created the idea of primary input/output on purpose. A filter that > >doesn't want to distinguish is free to ignore the difference, or to > >use only secondary links if it prefers. > > Yes, I thought the same - main (layer-specific) node structure have Uhg... > >> So we have no right to application to > >> manipulate any prev or next pointers - it must be done only by functions > >> link_video_chain() and unlink_video_chain(). :) > > >Something like that. > > I'm glad we agree with that. :) So as resume - we don't need to have > prev/next pointers in main (common,public,etc.) node structure since no > application may use it. > > Summary of arguments to have layer-independent node structure: > 1. Application will not see layer-specific data. > 2. Application cannot alternate links pointers so we get rid of bad > developers who may want to manipulate it but they will use (un)link_* > functions instead. > 3. Application's developers will see less docs so it will be simpler for > they. > 4. We will have only one node structure instead of 5 (1: compressed (or > undefined) stream between demuxer and decoder or between codec and muxer, > 2: video, 3: audio, 4: text/sub, 5: menu/etc.) so will have less of mess. > > Do you see any arguments against it? Yes, it's stupid. We are not C++ coders. Go take your ideas to avifile or something. 1. An application doesn't see internals unless it tries to. 2. I don't care if an app stupidly tries to use internals. It will crash when we change stuff and then the author will look stupid. 3. Non sequitur. 4. There are only 3, not five: video/audio/sub. WTF are you smoking? A menu chain?!?! Anyway, Andriy, I'm really not interested in talking with you much more about this. You refuse to RTFS and RTFp (p=proposal) and instead pretend you're coming up with new ideas when you say what's been there for months. Second, you refuse to understand the details, and only think like a stupid C++ class hierarchy designer rather than a coder. And third, you keep suggesting nonsense wrappers and obfuscation that just slow things down (to code and to run). Maybe you're well-meaning, but it's not coming across that way. If you want to make further comments, _please_ RTFS in detail and respond to it, rather than writing these general OOP-fantasy emails. Rich