Re: An open, standard video/audio API?

Hello,

First: Rich, thanks for the sanity checks. While I disagree with some of
your points, others (notably the fact that IPC can not be required if
all one wants is a movie player) are valid. And some amount of heat
belongs in a kitchen anyway.

D Richard Felker III wrote:

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

Since when did this become VERY big, when we are talking of something
other than a home PC watching movies? A database cluster would handle
much more than that. And I was thinking of a setting not unlike a
database cluster.

There are CPUs for which a Gigabit Ethernet is not a big load. Then
there are other ways of communication, like FC/AL.

I definitely do agree now that sockets/IPC should not be the only way.
(Got some offlist comments with a good explanation of how this should
work, but I'm not sure I can quote them).

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

Actually, if the API allows for *easy* building of a stream wrapper
(said streams may then go through any IPC of choice, from mere pipes to
TCP sockets), it will be useful enough for my taste.

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

Either we're not on the same page on what constitutes a useful filter,
or my copy of MPlayer is too old, or I got lost in the MPlayer manpage
despite reading the relevant part several times.

Here are the filters in transcode that I think are useful, and that I
can't find in MPlayer (actually, the relevant comparison is with
MEncoder):

32detect - autodetect 3:2 pulldown and interlacing
cshift - chroma lag shifter
decimate - NTSC decimation in pure software
logoaway - removal of an image/logo from the movie
preview - preview while encoding
smartdeinter/smartyuv - "smart" deinterlacing, only deinterlaces motion
areas and keeps the full resoultion in others

Yours, Mikhail Ramendik