Re: transcode filters

Hi,

> > > Once a standard is established - and the word of the MPlayer people
> > > means *much* in this regard - I think transcode will be under much
> > > pressure to conform.
> > 
> > I couldn't care less what transcode does. I've always found it slow,
> > awkward, and just plain broken.
> 
> Slow? Exactly how *can* it be slow (or fast), when by far the most CPU
> time is spent in either codecs or filters, and the much of the code
> there is the same?

No.
MEncoder is an MPlayer with ao/vo replaced with encoders & muxers.
And while the whole MPlayer video pipeline (demuxers, decoders, filters)
were designed for fast, realtime processing, transcode was always made
to be offline (non realtime) transcoder. MPlayer filter api is much more
complex than transcode's one, as it supports multiple colorspaces,
partial (for example, only one of 3 planes) changes, slices, direct
rendering/filtering etc. These can speed up processing a lot, and keep
better image quality (afaik transcode sometimes does yuv2->rgb, filter,
rgb->yuv, because of its lame filter api / filter implementations).
Also, as mencoder shares the whole stream/demuxer/decoder/filter layer with
mplayer, it supports every mplayer formats, from quicktime to real streaming.
Transcode afaik supports a very limited set of input formats and codecs.

imho advantages of mencoder over transcode:
- many supported input formats, codecs
- faster, due to DR and slices in filtering api
- sometimes better quality, due to less colorspace conversions

disadvantages:
- less output formats/muxers

anyway afaik there is a way to pipe mplayer's output to transcode,
so by combining these two you can get the best results.


A'rpi / MPlayer, Astral & ESP-team

--
PyMaViS - my answer to worm storm - http://mplayerhq.hu/~arpi/pymavis/