[MPlayer-users] RFC: docs update for "how to create a high quality DVD rip"

[Wayde Milas]

On Mon, 2004-06-07 at 15:36, Jason Tackaberry wrote:

> 
> I notice about the same amount of artifacting when my face is 1 foot
> away from my 15" LCD laptop screen as I do when I watch the video on my
> 52" rear projection about 9 feet away.  Perhaps slightly more on the tv,
> but it's close.

Nice. I gotta get me a real TV :)
> 
> > Yes I read this. Its much better than the default on btw, and I added
> > some comments at the end of my last email.
> 
> Ok, thanks.  I'll do a bunch of testing with *cmp=(2|3) so I can
> convince myself it's superior. :)
> 
> > does that noise bit add in the 2:1:2 that was taken out?
> 
> It adds a lot more, in fact.  hqdn3d=2:1:2 is very little.  Too little,
> according to Rich, but I'd rather be overly conservative.  With -vf
> noise=8ah:5ah (or so), it has about as much noise as the DVD does, and
> it masks certain artifacts.
> 

Could you explain that further? I'm not sure what you mean by adds as
much noise as the DVD does.. do dvd players actually add noise to the
signal?

> It all comes down to perception.  Obviously by adding random noise
> you're lowering the PSNR, but it _looks_ a lot more convincing.

Hum. I gotta think about that some.

> > wondering if you should depend on spp, or just up the bit rate? Ie,
> > should I be doing my tests by running the stream through spp for
> > viewing, or just viewing it "as is"?
> 
> Upping the bitrate stops helping when every frame is already using qp=2.
> spp helps clean up the image to a certain extent, and adding a bit of
> noise helps even more, IMO.

Well, you dont want every frame to be q=2 do you? I was under the
assumtion that you can get away wtih q > 2 on low motion frames.

Let me ask this. Does q=2 use as much space on a fast motion frame as it
does on a low motion frame? I always thought solid q values used about
teh same bits no matter what they were encoding?


> 
> I think relying on PSNR to find your optimal bitrate is a mistake.  At
> higher bitrates, PSNR appears to be much less meaningful.
> 
> Write a script that encodes your clips at various bitrates and view
> them.  Have your script also take several still frames at various
> positions so that you can do an A/B toggle.  (Doing A/B on stills is
> less telling, but at least it's something.)
> 
> In fact, I've already written such a script (brutal hack) to do some
> lavc/xvid comparisons.  It's definitely interesting to view the results.

I dont know if i agree. At some eprcentage below optimal encoding PSNR
falls off sharply. Gut feeling tells me this falloff is where the human
eye starts to notice problems.

Encode a 240 second chunk at various bitrates and graph it. PSNR values
are not linear. Its that non linearity that has me pondering different
schemes.

> 
> > Er what did he do last night? whats cmp=10?
> 
> Read the last few emails in the "lavc vs. xvid" thread.  I uploaded a
> clip where lavc showed quite a lot of blocky artifacts, and he added a
> new cmp func called NSSE that worked wonders.

Ah. I stopped reading towards the end. I need to read and check it out.

> 
> > Is that the 10 function? In the past higher psnr values have always
> > looked better, or the same to me. I can't remember when a lower one
> > actually looked better...
> 
> PSNR might be the best quantifiable way to measure quality, but quality
> is also a matter of perception.  Adding noise reduces PSNR but masks
> those pesky blocks.  The brain has an easier time ignoring random noise
> than dancing blocks.  (At least my brain does.)

I completely agree with this. However past a certain point those washed
out blocks tend to run mudding looking. This is jsut as bad, if not
worse.

> 
> 
> > I think some of the asm optimizations for p4 are fubared somewhere :P
> 
> I think most of the asm optimizations are MMX, with work the same on
> both AMD and Intel.  I don't know enough about mplayer to explain the
> difference.
> 

Hopefully someone does. Its been bugging me for a while.
-------------- 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/20040607/6800344d/attachment.pgp>