[MPlayer-users] mencoder: effective use of qp, crf params for x264?
Guillaume POIRIER
poirierg at gmail.com
Fri Feb 2 00:12:21 CET 2007
Hi,
On 1/31/07, matthew.garman at gmail.com <matthew.garman at gmail.com> wrote:
> On Wed, Jan 31, 2007 at 08:25:47AM +0100, Guillaume POIRIER wrote:
> > If you wanna re-implement this (BTW, this is called a compression
> > test), say you encode 5% of the movie, with fast options, with 20
> > chunks of video taken at evenly separated parts of the movie. You
> > encode at qp=18, which corresponds to a "perfect" encode (i.e.
> > there won't be any encoding artifacts due to too high quants), yet
> > not lossless encode.
>
> Just out of curiosity, if qp=0 is lossless and qp=18 is "perfect",
> what do qp=1 through qp=17 represent?
Well, to me, 1-17 interval are level of quality that only Steve Austin
can tell appart.
> > Your sample ends up weighting 150MB, so 150*20=3000 the full encode
> > would be 3000MB.
>
> And you'd also use that 150MB to get the bitrate, right? E.g., if
> that 150MB represented a 20 second clip, then the bitrate would be
> 150*1024*1024 / 20 / 1024 = 7680KB/s, right?
That seems about right, though I think the technique you used (parsing
is averaging bitrate) is probably simpler to implement, as you don't
need to take container overhead, and audio tracks size.
> > You can bet that with two pass, better encoding options, longueur
> > encoded sequences, and the fact that quant 18 is probably
> > overkill, so it's safe to say that you can compute your bitrate
> > between 40 and 60% of the 3000MB found by the compression test.
>
> So then you'd take that 7680kbs * 60% = 4608kbs, and that's what
> you'd pass in for vbitrate in your x264encopts, right?
yep
> I started to work through this; I'll outline my methodology to make
> sure it's right (and hopefully help others out in the future). Note
> that I'm using the "Batman Begins" DVD for all this.
>
> - I used midentify to get the length of the video:
> $ midentify dvd://1 | grep ID_LENGTH
> ID_LENGTH=8392.80
>
> - I want to sample 5% of this movie, so 8392.8 * 0.05 = 419.64. I
> want 20 chunks of video to total about 419 seconds, so 419/20 =
> 21. So encode 21 secs at time 0, 419, 838, 1257, etc. (In my
> test I simplified the interval to 400)
> $ for i in 0 400 800 [...] 8000; do \
> echo "==== $i ====" ; \
> mencoder dvd://1 -v -alang en -aid 128 -oac copy -ovc x264
> -x264encopts qp=18:partitions=all:8x8dct:me=umh:subq=6:frameref=5:threads=auto:bframes=4:b_pyramid:weight_b \
> -idx -ofps 24000/1001
> -o /dev/null -ss $i -endpos 21 >/dev/null 2>>stderr.txt \
> ; done
>
> * I had some problems here (see below), but I'll ignore them for
> now
>
> - Analyze the stderr.txt file that resulted from the above command;
> look for occurances of the following line:
> x264 [info]: kb/s:3516.1
> Take the average of all the kb/s reported for each mencoder run.
>
> - Discover that my average is about 2000 kb/s. Take 2000 * 0.6 =
> 1200, and use that as my vbitrate for the full two-pass encoding
> of the entire movie.
>
> * Note that I use -ss and -endpos to "chunk" the movie. However,
> in the loop above, when I get to around ss=4400, mencoder
> segfaults (on that and every subsequent iteration):
I don't use -ss because I usually re-mux with several audio tracks,
and when video and audio are of different size, it's a pain to get
proper sync.
> The selected video_out device is incompatible with this codec.
> Try adding the scale filter, e.g. -vf spp,scale instead of -vf spp.
> Filters have not been configured! Empty file?
> Segmentation fault
>
> Hopefully I'm on the right track...
>
> Thank you and everyone else so much!
>
Your reciepe seems right to me.
Guillaume
More information about the MPlayer-users
mailing list