Op vr, 24-11-2006 te 00:26 -0800, schreef Steven M. Schultz: > > On Thu, 23 Nov 2006, Richard Rasker wrote: > > > question I have deals with one of the elusive Holy Grails of video > > processing: how to render a given DV file into the highest possible > > quality DVD. > > In addition to being a holy grail it is also known as a 'wild goose > chase' ;)
OK, as I said, I'm not very experienced in this field yet, and I just thought I'd ask - I hope to learn :) > > Actually it's not all that hard once you wrap your brain around that > fact that a few extra kbits/sec for video is NOT going to make > any difference at all in visual quality. Some very detailed and colourful material > > > mplex to merge both files, only to find that either the maximum bit rate > > and/or quantization value for DVD has been exceeded. After which I > > The bitrate is the only thing that is (or can be) exceeded. There is > no such concept as "quantization value for DVD being exceeded". Hmm, then how do you call it when quantization (-q) is chosen too low, resulting in mplex reporting buffer underrun errors? > > Sometimes it takes three attempts to reach the optimal values, and with... > > > > Example of the render pipe command: > > yuvcorrect -v 0 -T INTERLACED_BOTTOM_FIRST | mpeg2enc -M 2 -v 0 -r 32 -4 > > 1 -2 1 -D 10 -g 15 -G 15 -q 5 -b 9600 -f 8 -o % > > For one thing you could speed up the coding by deleting the "-r 32". > That is past the point of diminishing returns - i.e. you gain almost > nothing over the default "-r 16" but the encoding time is longer. > > I'm curious why 'yuvcorrect' is being used. DV is always bottom > field first - is something earlier in the pipeline mangling the > field order tag? Well, as I'm not too experienced yet (did I mention that already? :-), I started out by simply copying the pipe command from someone else who claimed that this would yield the best results. And indeed I did find a noticeable improvement when compared to the basic mpeg2enc -f 8 command. However, I *did* look up the man pages to see what each of these commands and options does. > -M is either useless (no speed gain) or worse (subtle threading > race can trigger an assert() error). I'm working on an AMD64 dual-core machine, and -M 2 (actually the only option I came up with myself) results in an overall speed gain of up to 40%. > And 9600 is too high for a bitrate value. Try 8800 or even a little > lower. [snip lots of excellent explanation] OK, I'll go experiment with small video clips once more, playing around with render pipe parameters; I'll also involve my spouse in some blind(!) tests - she's always been rather critical when it comes to picture quality, and doesn't mind seeing the same bit over and over again. That way, I can't fool myself into believing that the larger file is visibly better. Thanks a lot for your time, I'm learning a lot! Regards, Richard Rasker ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
