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

[Wayde Milas]

On Mon, 2004-06-07 at 12:48, Jason Tackaberry wrote:
> Multi-TB?  I'd be curious to hear how you have that set up.

Well, I lied a bit.. its just over 1.5TB raided 5. So  not exactly many
multiple.

I have an msi 865pe mobo with that cse or whatever streaming arch.
Seperates the gigabit ether from the other pci devices. has 4 udma
133/166 ports and 4 Sata ports. One 80 gig drive on the udma master for
boot, and the dvd burner on the otehr master.

4 250 gig maxtor drives on each Sata. bought a 4 header out sata
(promise I believe.. same chipset thats native on teh MSI.. its REALLY
nice) and droped 4 more 250 gig maxtor drives on it.

Raid 5, linux kenel raid. So 7x250 useable 1 hot spare, minus formatted
loss. I use Reiserfs on it.

Its fast. REALLY fast. Plus it holds a bunch and isnt all that expensive
when ya come down to it. Considering i was putting 2 or 3 drives in some
of the boxes around the house, and now its jsut all nfs/SMB mounted.

> 
> MPlayer would have to convert this 5+ channel Vorbis into AC3 so that I
> can still get my pass-through, though.  But yeah, that would be pretty
> cool. :)

Its theoreticly possible via the AC3lib that already exists.

> 
> This depends entirely on the values you give the denoise filter.  With
> hqdn3d=2:1:2 I haven't been able to see any difference except in bitrate
> on every video I've tested.  With 4:3:6, the defaults, on occasion I've
> seen it do unwanted things to the video.

I'm going to have to play wtih this.

> 
> > How safe is this to actually use on high quality archival streams?
> 
> I'd say light values are perfectly safe.  Of course, your mileage may
> vary.  But my experience is that at least a little bit of denoise helps
> much more than it hurts.

I'm doing quality tests on a 19 inch flat panel lcd. I dont have a
monster hdtv to test display on. I'm wondering how it looks blown up
huge.

> 
> I mentioned this in the guide (did you read it?  Any comments?).  You
> can add the noise back in with the noise filter.  A small amount of
> temporal noise makes night-and-day difference when there are blocky
> artifacts in the AVI.  I use:
> 
>    mplayer movie.avi -vf spp,noise=9ah:5ah -autoq 3
> 
> You might want to use -autoq 2 if you have a slower CPU.  -autoq
> controls the quality level of the spp filter, which does help visibly by
> smoothing out the blockiness.  With these two filters and a high bitrate
> rip, I frequently have a hard time telling apart the MPEG4 and the DVD.

Yes I read this. Its much better than the default on btw, and I added
some comments at the end of my last email.

does that noise bit add in the 2:1:2 that was taken out?

Also, I know spp can improve quality on bad looking streams.. But I'm
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"?

> 
> > Let me qualify that. I know this is lossy. By original I mean an encoded
> > stream that has no denoise filter applied when encoded.
> 
> With no denoise filter you may end up having lower quality because lavc
> will use a lower quantizer on frames that don't need it in order to
> preserve the noise in the original source.  Filtering some of the noise
> out means that lavc can use lower quantizers in places that matter.

Of course. I'm just afraid of it taking out detail that it thinks is
noise.

> 
> > The question I think is at what point (maybe a lose rule of thumb.. of
> > course you need to play with individual movies to see the exact place)
> > does it make sense to scale the stream down to create a stream that
> > looks better X bitrate.
> 
> When your have no file size constraints, then no, it doesn't make sense.
> But when you do, then scaling down may likely be the right thing to do.
> 
> As Rich pointed out, the artifacting caused by using higher quantizers
> is much worse than the artifacts caused by scaling up a video (it will
> be blurrier).  When you have a size constraint, you need to find the
> right balance between scale and quantizer.  I'm sure there are some
> strategies to do this, but aside from trial and error I don't really
> know them.  (Of course, it'd not be difficult to write a script to try
> multiple scales at fixed bitrates and capture certain scenes, then
> compare the PSNR, and pull out still frames for A/B comparisons.  But
> there may be smarter approaches.)
> 
> Anyway, all that is unnecessary when you decide to trade bits for
> maximum quality.  But there's a place for scaling.
> 
> > I guess what I'm asking here is that if I have stream at X by Y at lets
> > say 960. Would it look better at X by Y or X/2 by Y/2? I know this is a
> > bad generalization, but I'm looking for a loose set of parameters to
> > know at what rate a good, modern, progressive 24fps widescreen dvd
> > encoded movie should be encoded at at full resulution, and at what
> > bitrate I should start thinking of scaling the resolution down.
> 
> Well, scaling the resolution down by _half_ is too much.  But scaling
> the resolution down say 20% will probably look appreciably better if
> lavc starts using higher quantizers at 960kbit.
> 
> I think around 1400kbit you might get better quality with scaling down.
> One easy way to find out is to play back the movie with -lavdopts
> debug=1 and have a look at what frame quantizers are being used.  If the
> quantizers are fairly low then scaling won't help, otherwise it will.
> 
> Anyway, all this is according to my intuition.  I've never needed to do
> this in practice.  Rich will be able to offer better advice if this is
> what you want to do.

Its not that I want to do it. Its jsut that it will give me a better gut
feel for what is actually going on. Finding the right bit rate seems to
be more of a art than a science.

What I was considering was taking a few chunks of a mpeg2 stream,
running basic q=2 high quality fast encoding on the chunks and recording
the psnr values in a script. then going BACK over those chunks in a
script with full options and altering the bitrate till the psnr values
are within a certain percentage.. maybe 5%.

That would theoreticly give me a bit rate that pretty damn close to the
original, and yet have the lowest bitstream. Somehow I don't think its
going to be quite this easy, or else someone would have already done it
:/

> 
> > Something else for high quality encoding. the cmp functions (default is
> > 1 I think) plain suck. Well, they arent cpu intensive but with some more
> > processsing time you yield dramaticly higher PSNR values on clean signal
> > originals.
> 
> I haven't played with the cmp functions much.  I'd be interested to hear
> others' results.  If general consensus is that cmp=0 is much lower
> quality, then that should be mentioned in the guide.

I've played with them extensively. A bunch of other people have too.
Everyone has come to teh conclusion that 2 yields 5 to 10% higher psnr
values on high quality input. 3 squeaks out even more but is slow as
hell.

This is assuming a high Q/high bit rate. It deminishes at lower
bitrates.

>  
> > 3 is a bit overkill but can be slightly better than 2 in my opinion. 2
> > is a diffinate must.
> 
> After Michael's changes last night, it's quite tempting to recommend
> cmp=10. :)  Of course that needs much more testing.

Er what did he do last night? whats cmp=10?

> 
> > On animated/cartoon stuff 7 seems to work well also. 2 nad 3 yield
> > higher bsnr values (by ALOT) on jsut about everything ive tried them on.
> > B&W dont get a smaller psnr boost.
> 
> At higher bitrates I've discovered that PSNR doesn't really mean much.
> Too often I've seen video with a 1-2dB lower PSNR look better.  This was
> shown even more with the new NSSE cmp function, where the PSNR is about
> 1dB less than the default cmp, but it looks _drastically_ better to my
> eye.

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

> 
> > Be prepared for longer encoding times.
> 
> Ehh, cycles are cheap. :)

Very true.

As a side note, I discovered something interesting. I've got some althon
XP 2500+ boxes and some p4 2.8 Ghz boxes. (each slight overcloced.. the
2500 is OC'd to 1984 mhz and the p4's are OC'd to 3 Ghz) The XP boxes
consistently encode faster than the intel boxes. I've checked and double
checked that mplayer is compiled with full optimization and running with
correct sse2 / 3dnow for each of the boxes. Against all intuition, the
athlon XP boxes are faster. Which is wierd as hell because the p4 boxes
are 865 chipsets with FAST ddr ram, while the athlon xp boxes are
elcheapo nvidia 2 chipsets with just ok ddr ram.

The p4 archetecture for this type of thing is way better.. not to
mention that the memory throughput on the p4 boxes is MUCH faster than
the amd boxes.

I can't figure it out. The difference isnt small.. its like 20-40%. I
can post hard numbers if anyone is interested.

I think some of the asm optimizations for p4 are fubared somewhere :P
-------------- 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/81c5db99/attachment.pgp>