[MPlayer-users] info on -cbp -mv0 and -qprd

[Wayde Milas]

On Fri, 2004-02-27 at 19:16, D Richard Felker III wrote:
> On Fri, Feb 27, 2004 at 03:38:21PM -0600, Wayde Milas wrote:
> > On Fri, 2004-02-27 at 14:41, D Richard Felker III wrote:
> > 
> > > > Darnit, my cut and copy skills arent good today. that line should read:
> > > > mencoder dvd://1 -o blah.avi -mc 0 -noskip -skiplimit 0 -oac copy -ovc
> > > > lavc -vf crop=www:xxx:y:z -lavcopts
> > > > vcodec=mpeg4:vqscale=2:mbd=2:trell:vmax_b_frames=1:v4mv:autoaspect
> > > 
> > > What are www, xxx, y, and x? Width and height must both be multiples
> > > of 16 unless you're going to scale afterwards, horizontal offset must
> > > be even, and vertical offset should be even or a multiple of 4. Also,
> > 
> > I realize this. They are just place holders. I'm obtaining these numbers
> > from cropdetect so everything is good.
> 
> No, it's not good. cropdetect just gives you the raw values where it
> finds the image edges. These will not automatically be aligned.

I did not realize this. menencoder still encodes based off these values.
I assume that the misaligned blocks I'm generating cause extra bits to
be wasted?

> I really don't understand cbp.

I played with cbp. It seems to give a net gain in scenes where there is
alot of motion. PSNR values dont go down, but stay the same on static
scenes. It seems a win/win to enable, except it does use alot more
processing time.

> mv0 can only help. It just always tries encoding with (0,0) motion
> vector (texture only) to see if that's better than spending bits
> storing a motion vector.

Ah now I understand it. Thanks.

> > qpel adds more bits to a q=2 stream (from observation). I've heard
> > reports that there is no difference in quality (I cant see any) and the
> > stream is larger so....
> 
> I agree, qpel seems bad to me. I just said it might be useful.

I ran extensive tests over the weekend. With trellis enabled, I could
not find a case where qpel actually helped. It was around the same, or
worse in most cases. Without trellis enabled, there was a slight gain
sometimes, and worse othertimes. Overall, trellis is better.

> Yes, subcmp should in principle help qpel, but I don't know if it's
> enough to make it useful.

Testing over the weekend showd *cmp=2 as a net winner almost always, and
*cmp=3 as a marginal winner over 2, except it doestake more precessing
pwer. Anyways cmp turns out to be a great option if you have the
processing power :)

> Encoding with constant-quantizer is a very bad idea unless it's q=2 or
> q=1. Instead you should set qmax=4 and encode with 2pass and a proper
> bitrate. This will allow many frames to come out q=2 or 3 (when it
> doesn't use many more bits) and only resort to q=4 for really complex
> scenes. q=2 is not expensive on simple/still scenes, and these scenes
> are where having a low value of q really matters.

I'm leaning towards this approach after testing this weekend. My first
approach was to encode at a flat q=2 for maximum quality. After sitting
down and watching still images of scenes at q={2,5} on a lcd monitor,
its hard to tell the differences between 2 and 3. 4 I can see slight
artifacts. 5 is more noticeable. However, these are in still scenes. I
cant imagine I'd see any of them at 30 fps.

The only thing that worries me is that I dont have access to a large
HDTV. I'm wondering if artifacts at q=4 ar notizeable at 60+ inches? I'd
hate to have to re-encode them at a later date.

> You're correct, 2pass will do nothing when used with vqscale. I don't
> recommend doing this unless you can use vqscale=2, though.

Thats one of the attractions of using a set q. Half the encode time.
What I need to do is encode with a qmax and do a 2 pass to see just how
many bits are saved, and take a look at the psnr and q values and see
what they are compared to a static q=2.

Thanks much for your input Rich.

Wayde
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20040301/8582e6d6/attachment.pgp>