Re: An open, standard video/audio API?

On Tue, Apr 20, 2004 at 12:18:57PM +0400, Mikhail Ramendik wrote:
> 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.

How could an API make this difficult? I don't understand that. Just
make a filter that outputs over the IPC mechanism of your choice, or
gets its input from the same...

> 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

This is probably the port of my old bad vf_detc. Maybe with some
enhancements. But mplayer has much better filters for doing it now.
If you really need autodetection between the two, there's vf_filmdint,
but from my experience autodetection is always a bad idea -- you'll
invariably end up incorrectly deinterlacing frames that are actually
telecined.

> cshift - chroma lag shifter

What is chroma lag?

> decimate - NTSC decimation in pure software

What is NTSC decimation?

> logoaway - removal of an image/logo from the movie

This is useful, yes. If it's not a stupid implementation like the one
in mplayer.

> preview - preview while encoding

Useful but IMO it's a bit different than a filter.

> smartdeinter/smartyuv - "smart" deinterlacing, only deinterlaces motion
> areas and keeps the full resoultion in others

Similar to pp=md.

Rich