[MPlayer-users] mencoder: effective use of qp, crf params for x264?

[Guillaume POIRIER]

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