Hello Steven, Thank you for your reply! =)
On Wed, Apr 05, 2006 at 11:31:29AM -0700, Steven M. Schultz wrote: > > On Wed, 5 Apr 2006, Nicolas wrote: > > > I use mpeg2enc and mplex to create my DVD from videos made with > > Cinelerra. Cinelerra outputs an YUV4MPEG stream which I encode "on the > > fly" with mpeg2enc. Here's the pipe I use : > > Let's play "find the be incorrect options" game :) > > > /usr/bin/yuvcorrect -T INTERLACED_BOTTOM_FIRST | /usr/bin/yuvscaler -v 0 > > hmmm - Cinelerra getting the field order wrong? Exactly. At least with the SVN version I fetched 1 month ago. There's a problem with the field order information in batch mode only. In "normal rendering mode", the field order information is fine, and I don't have to use yuvcorrect. > > -I ACTIVE_702x560+8+8 -M BICUBIC | /usr/bin/mpeg2enc -v 0 -r 32 -4 1 -2 > > 1 -V 1853 -s -D 1 0 -g 6 -G 15 -I 1 -b 9800 -D 10 -f 8 -o $1 > > Is that a typo? "-D 1" is an illegal value. The argument to -D > needs to be 8, 9 or 10. You're right, that's a typo when I paste the command line in mutt. The right command line I use is : /usr/bin/yuvcorrect -T INTERLACED_BOTTOM_FIRST | /usr/bin/yuvscaler -v 0 -I ACTIVE_702x560+8+8 -M BICUBIC | /usr/bin/mpeg2enc -v 0 -r 32 -4 1 -2 1 -V 1853 -s -D 10 -g 6 -G 15 -I 1 -b 9800 -f 8 -o $1 > Also, a search radius of 32 is past the point of diminishing returns, > all it's doing is slowing the process down. 24 may be of some value > but 32? Doubtful. OK. I'll use 24 instead! > -I 1 isn't needed - mpeg2enc will do the right thing without it. OK. > -s isn't needed (-f 8 does that for the DVD format). OK. The problem is that I don't know which options are set when using -f 8. > -V 1853 is ABSURDLY high. That value is the amount of "buffering" > in KB for the stream. I REALLY DOUBT that any DVD player being made > will have 1853 * 1024 bytes of memory for buffering the MPEG-2 > data ;) > > IF the default (for -f 8) of 224 (KB) does not work then the '-b' > value is too high. Damn! I thought the value was in kb, not KB. That's why I used 1853. In fact, that equals to the default buffer size of 224 when using -f 8, as you said. Thanks for that information ! > Don't use the max bitrate for '-b'! True, the DVD specs say the > max rate from DVD is 10.08 but that includes the video stream, audio > stream AND navigation info. > > Also, as has been mentioned many times before, using a max value > doesn't 1) leave any room for spikes/peaks in the rate which can > cause some players to have problems and 2) may cause problems with > recordable media in some players. > > Some players have trouble reading recordable media at very high > rates. Some players work fine. Do you know what players everyone > will be using? ;) Well, in fact, I set -b 9800 to get the highest possible quality while staying in the "standard limits". I really want CBR, since I put only 45 minutes on each DVD. That's why I don't use -q 3 for example. My audio bitrate is 384 kbps. When mplexing the streams I get a total bitrate of 10404, which is below the limit. I know the DVD players on which the DVD will be played indeed. Those DVDs are family movies, and the standalone DVD players are modern and can play the mpeg videos without any trouble. However, I understand things are really different when one don't know how the DVD will be played (old standalone DVD players...) > > I also output an AC3 audio stream, and I use mplex to create the mpeg > > video: > > mplex -f 8 -b 1835 -r 10404 audio.ac3 video.m2v -o movie.mpeg > > Again, if the stream is properly formed you don't need to specify > a bogusly high value of '-b'! Even HIGH DEFINITION MPEG-2 only > needs '-b' of 488 (KB)! > > No need to specify '-r' if the stream is DVD compatible. > > > However, I noticed a strange thing in mplex output : > > INFO: [mplex] Video Stream length: 505039125 bytes > > INFO: [mplex] Sequence headers: 727 > > INFO: [mplex] Sequence ends : 1 > > INFO: [mplex] No. Pictures : 10904 > > INFO: [mplex] No. Groups : 727 > > INFO: [mplex] No. I Frames : 727 avg. size 58042 bytes > > INFO: [mplex] No. P Frames : 10177 avg. size 45479 bytes > > INFO: [mplex] No. B Frames : 0 avg. size 0 bytes > > > > There seems to be no B frame at all in the mpeg. That's strange since > > That's (usually) a good thing! > > Oh, no b frames MAY cause SOME players to have difficulty with smooth > fast forward playing but if that's not important then don't use > B frames. > > > Note: Mpeg2enc is currently hard-wired to produce 2 B frames between > > each I/P frame unless the GOP size forces less. This is reasonable for > > That option is only effective if you're using B frames ;) > > -R sets the number of B frames. By default it is 0. > > > -P|--force-b-b-p > > This flag forces the GOP size selection to choose sizes that ensure > > 2 B frames appear between adjacent I/P frames. Several common MPEG-1 > > decoders can't handle streams where less than 2 B-frames appear between > > I/P frames. > > You're not generating MPEG-1 and that comment was written years ago. > > ALSO "B frames" have always been an optional part of the MPEG specs, > so there's NOTHING that says they MUST be used. > > > What's wrong? Did I use a wrong setting? I really would like to get 2 B > > Other than a bunch of incorrect options you're doing fine :) :) > > > frames in each GOP, to get the best image quality (as you probably > > noticed, I encode in CBR at 9800 kbps). > > Who told you B frames improve quality? In *some* cases using > B frames with pristine (extremely clean) source material you *may* > see *some* quality improvement. > > I think you'd be much better off with just fixing up the commands > and staying with "-R 0" (no b frames). BUT if you want to try > something that might be useful try adding "--dualprime-mpeg2" to the > mpeg2enc options. > > However, if you've any noise at all what you gain with smaller B > frames you lose with larger P frames. > > Check the mailinglist archives for the previous discussions - in fact > there was mention fairly recently i think. OK. So, I don't worry anymore about the "missing B frames". ;-) I now use the following pipe command: /usr/bin/yuvcorrect -v 0 -T INTERLACED_BOTTOM_FIRST | /usr/bin/yuvscaler -v 0 -I ACTIVE_702x560+8+8 -M BICUBIC | /usr/bin/mpeg2enc -v 0 -r 24 -4 1 -2 1 -D 10 -g 15 -G 15 -b 9800 -f 8 -o $1 And I mplex with this command : mplex -f 8 01.ac3 01.m2v -o 01_new.mpeg I do not specify a value for -r. However, I have that warning message : INFO: [mplex] rough-guess multiplexed stream data rate : 10403400 INFO: [mplex] target data-rate specified : 10080000 ++ WARN: [mplex] Target data rate lower than computed requirement! ++ WARN: [mplex] N.b. a 20% or so discrepancy in variable bit-rate ++ WARN: [mplex] streams is common and harmless provided no time-outs will occur INFO: [mplex] Run-in Sectors = 89 Video delay = 13019 Audio delay = 16619 I don't get that message if I use the -r 10404 value as I did before. The warning explanation given in the message don't help me. I use CBR bitrate, not VBR. Is that message a problem? Is there any problem using -r 10404 as I did before? Thank you. Nicolas. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
