Re: An open, standard video/audio API?

On Tue, Apr 20, 2004 at 02:14:43AM +0400, Mikhail Ramendik wrote:
> > > 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.

Our API designs can run on one cpu or multiple cpus. But there's
simply no way to spread them out across multiple systems without
shared memory. It's many many orders of magnitude too slow to be
useful. Every time data has to be processed/copied, that's 20
megs/second of bandwidth, assuming full DVD resolution. You simply
CANNOT be wasting time on additional copies. Copying over a network is
totally useless unless you have gigabit ethernet, and even then the
cpu load of all that network traffic will be so high that it will
negate any benefit you get of processing on multiple computers.

> A socket-based interface does not have to be the only one. It may be a
> wrapper for exchange of standard data structures.

I failed to mention before that sockets creates a whole new layer of
trouble you don't even want to deal with. If you use unix sockets,
it's unix-specific and not portable to windows and such. Using tcp
sockets is totally out of the question since it requires an
authentication layer with advanced key verification, encryption, etc.
We will NOT go through the hell of ensuring that something like that
is secure against cryptographic attack and not vulnerable to exploits
in the implementation, when it's not even useful. Network
functionality does not belong at this level. You can build other
bloatware layers on top of the basic API to put this dangerous, slow,
useless code in, if you really insist.

> > > 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! 

BTW, I'm curious...since when does transcode have lots of useful
filters? Last I checked it was quite limited, and some of the filters
were just ports from MPlayer.

> > 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?

The design we're working on covers all of these things. Your design
_only_ covers slow nonlinear video editing apps. It's prohibitively
slow for playback or transcoding.

> And then there's streaming video both ways (in and out).

There's no reason this needs to be connected to the API for processing
it. Transporting data and processing it are two separate tasks.

Rich