[MPlayer-users] lossless codecs make bigger files than raw DV ?!

Matthew W. Miller mwmiller at columbus.rr.com
Thu Feb 5 13:40:25 CET 2004


On Thu, Feb 05, 2004 at 12:56:18AM -0500, D Richard Felker III wrote:
>On Wed, Feb 04, 2004 at 03:36:39PM -0500, The Wanderer wrote:
>> I've never heard anything which suggests that trell has a downside
>> (or even an alternative against which to compete), aside from the
>> increased CPU requirements.

Well, the increased CPU requirement is a downside right there.

>I'm just going by 2 basic principles:
>1. Default should be bare-bones minimal mpeg4 without fancy stuff.
>2. If the default is _bad_ quality, newbies will have to rtfm and learn
>   how to encode properly.

I think I agree with Mr Felker here (not that I expect a perfectly
adequate default to change any time soon *anyway*).  The defaults pretty
much all yield top speed with decent encoding quality; many things like
trell, mbd=X, v4mv, cbp, mv0 cause greatly increased CPU use for only
small quality improvements; if you have more CPU cycles to throw at an
encode, great, you can read the documentation and learn how best to use
them.
	The "FF" in "FFMpeg" is there for a reason: FFMpeg (and thus
libavcodec) is intended to be useful for good-quality realtime encoding
and decoding with a minimal CPU hit (unless, of course, you want the
better quality).  I don't know what the FFMpeg or MPlayer developers may
think about this, but I personally think that making the defaults
higher-quality/greater-CPU-use would detract from that goal.
-- 
Matthew W. Miller <mwmiller at columbus.rr.com> "You shouldn't trust _any_
software. Software is _at best_ a faithful but bumbling zombie servant
that ineptly performs your bidding. At worst, it's an evil zombie that
wants to kill you and eat your brain." --Mr Bad, on Trusted Computing




More information about the MPlayer-users mailing list