Re: An open, standard video/audio API?
Mikhail Ramendik <[email protected]> Tue, 20 Apr 2004 02:14:43 +0400
| Newsgroups | gmane.comp.video.mplayer.g2.devel |
|---|---|
| Message-ID | <[email protected]> |
Hello, D Richard Felker III wrote: > > ffmpeg is not yet a standard. And it does not support all things needed. > > For example, it seems to support DV video but not DV audio (strange, but > > true - it's better at the video than libdv, just no audio!) > > We're talking about standard API, not the codec selection. It's not > really relevant that ffmpeg doesn't have DV audio, since it can be > added. If we call it the standard, we exclude all codecs that are not supported in ffmpeg. DV audio is just one example. > > > If you look for alternative of DirectShow, you may take a look of > > > GStreamer project. It is generally what are you trying to achieve. > > > > Not really. Well, perhaps it is an alternative - but it assumes too much > > "windoze-like" stuff. And, Gnome is really overkill outside of explicit > > GUI works. > > GStreamer uses GNOME? Uhg... I meant to write GLib. (Actually I just mustrust object orientation outside of GUIs.) > > I would really support a socket-based interface. > > This is totally ignorant. (Read slow) Why does there need to be any > IPC? Everything can take place in one process. Why does it have to be *limited* to all-in-one-process? This limits us to one PC, in some cases to one CPU. A socket-based interface does not have to be the only one. It may be a wrapper for exchange of standard data structures. > > An interface that is simple and yet efficient would be a true work of > > art. Supported by the well-known MPlayer team, it could stand a chance > > of becoming the standard. Not only ffmpeg, but other codecs could > > support it as well - and imagine availability of transcode's big set of > > filters for use outside of transcode, via this API! > > We're largely against a standard API because there's nothing to gain > from it, and all the people who want it want to make an API that > sucks. How about availability for specialized apps? For example, non-linear video editing. Or even what VirtualDub does -- easy transcoding and subtitling. Why does avidemux have to talk to many libraries? And then there's streaming video both ways (in and out). Yours, Mikhail Ramendik