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

[Reimar Döffinger]

On Fri, Jan 02, 2009 at 10:09:35AM -0600, Laine Lee wrote:
> On 1/1/09 2:18 AM, "Reimar Döffinger" wrote:
> 
> > -lavcopts vcodec=mpeg2video:vqscale=2
> > no any other encoder options.
> 
> 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.

Well, okay...
I usually stay with vqscale=2 because _I_ can not see any quality
difference beyond that ever.
But I can say for sure, that you should not be able to get a more
accurate image than with
-lavcopts vcodec=mpeg2video:vqscale=1:vqmin=1:mbd=2:dc=10
and I do have some doubts about what effect (if any) the mbd and dc
option have here.

> >> 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'd say either you have a very special kind of input you encode, you hit
a really rare bug or what you consider "extreme blockiness" is something
I and a lot of others would not even notice.
I think you should find a way to assign a "encoding artifact
sensitivity" number to everyone which must be quoted for any bug
reports/help requests ;-).
I admit I almost always use mpeg4 and not mpeg2 though.

> > 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.

Two-pass is for videos with strongly varying complexity (e.g. long still
frames and some high speed action scenes), low bitrate and very loose
bitrate constraints (high or no vrc_buf_size).
I admit that might be close to the opposite of what you are doing.

> 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

Have you tried without threads=2? I heard some (unverified) claims it is broken,
though that might have been for decoding.

Greetings,
Reimar Döffinger