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