[MEncoder-users] Compression too great, bitrate too low on detelecined deinterlaced mpeg2video

[Laine Lee]

Thanks again for replying.

On 1/1/09 2:18 AM, "Reimar Döffinger" wrote:

> -lavcopts vcodec=mpeg2video:vqscale=2
> no any other encoder options.

The vqscale=2 option seems to be unaffected by other options that don't
directly refer to bitrate, which are (as of my last posting):

threads=2:trell:mbd=2:preme=2:dia=-1:predia=-1:precmp=2:subcmp=3:cbp:vqmin=1
:dc=10:lmin=0.01:vstrict=0:aspect=16/9

In other words, if I include the above options along with vqscale=2, the
bitrate and quality of the output doesn't differ significantly from the
results I get if I leave them out, except for aspect, of course.

I still find that requesting a bitrate by number using the vbitrate option
(after deciding on the above options) when also including the options
vrc_buf_size=1835 and vrc_maxrate=9200 results in better image quality and a
higher bitrate and larger file size than using vqscale=2 with or without the
above options. Also the extremely low number for the lmin option appears to
have no benefit, although I haven't tested omitting that option entirely
(except by omitting the entire string and leaving only vqscale=2).

> 
>> One thing that baffles me is that the turbo option for the first pass not
>> only decreased the bitrate, but it resulted in 1 of every 15 frames (my
>> keyint specification is 15) being rendered with extreme blockiness in
>> certain passages whether or not I included the keyint option among the lavc
>> options in the first pass command string. To eliminate these unwanted
>> results, I omitted the turbo option. There was a detriment to encoding time
>> of course, but the bitrate went up, and the blocky 15th frames disappeared.
> 
> That is in the final video? Or have you been looking a the video after
> the first pass? How the video looks after the first pass is
> _irrelevant_, which is why you are often supposed to encode it into
> /dev/null

This is the final video. I never send the output of the first pass to a
file. I always test by running both passes on an excerpt, which, as you
confirm in the part of your reply which I've included below, is probably not
an ideal test method. Also, for my process, no benefit in saved encoding
time resulting from including "turbo" for the first pass is worth what it
has been costing me in consistent quality.

> 
>> Possibly the most serious concern for me, though, is that encoding results
>> for brief excerpts of the video (a minute or two) differed significantly
>> from the results for the same passages when encoded with the entire file
>> (110 minutes). Several of the results I am reporting here were only
>> confirmed after encoding the entire 110 minutes of video several times.
> 
> That's the whole point of doing two-pass encoding, allowing the encoder
> to distribute bits as it considers appropriate all over the video.

After taking that into consideration as well as the detriment to my results
apparently caused by "turbo", it now appears that my results are not
improved enough by using two passes to make doing that worthwhile. I've also
determined through more testing that applying the denoise filter is also not
desirable. I may even go as far as to try a sharpening filter. Anyway, my
latest attempt (below) seems to yield output that is at least as good as any
I've produced yet. Thanks again.

mencoder -oac copy -ovc lavc -lavcopts
vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9200:vbitrate=6000:threads=2
:trell:mbd=2:preme=2:dia=-1:predia=-1:precmp=2:subcmp=3:cbp:vqmin=1:dc=10:lm
in=1:keyint=15:vstrict=0:aspect=16/9 -vf
framestep=2,filmdint=fast=0,softskip,scale=720:480,harddup -noskip -of mpeg
-mpegopts format=dvd:tsaf -fps 60000/1001 -ofps 24000/1001 -o outfile.mpg
infile.mpg


-- 
Laine Lee