[MEncoder-users] divx v's x264
Raimund Berger
raimund.berger at gmail.com
Fri Jun 6 20:14:29 CEST 2008
Alex Samad <alex at samad.com.au> writes:
> On Thu, Jun 05, 2008 at 05:22:27PM -0300, Diogo Franco wrote:
>> Em Sex, 2008-06-06 às 05:34 +1000, Alex Samad escreveu:
>> > My understanding is that cabac is an option that makes the resulting
>> > file is more cpu intensive to decode, I have run into problems whilst
>> > playing it on my xbox with XBMC
>> It doesn't 'just' make the file 'more cpu intensive to decode', but has
>> a much better compression efficiency. Unless you really want that cpu
>
> that is what i have read int he man pages, more cpu intensive in
> encoding and decoding, from my experience, it has caused me problems
> with viewing on my xbox, it has caused me problems with viewing on my
> xbox
> have also turned of b_frames because of this. But having checked the
> website again, it looks like setting bframes=1 (when i was reading about
> qt compatibility)
>
>
>> time, cabac will allow your file to be smaller than with cavlc.
>
> See I find this last statement counter intuitive. It has been mentioned
> on this thread that once you set the bitrate the file size should be the
> same no matter what codec is used.
Video encoding trades off the variables against each other:
* en/decoding speed
* bitrate
* quality
You can fix anyone of them (like fixed bitrate), in which case any
gain on one of the other (like higher decoding speed with nocabac)
usually implies a loss on the third (lower quality).
You can also fix the quality with crf. In that case, if you compare
cabac versus nocabac encodings, the latter would have a greater
filesize. Of course, due to higher bitrates chosen by the encoder to
maintain the quality you asked for.
Just think about it for a moment, it's really very simple.
Cf.
http://forum.doom9.org/showpost.php?p=1020500&postcount=33
More information about the MEncoder-users
mailing list