On Wed, 5 Apr 2006, Nicolas wrote:
Hi!
> Thank you for your reply! =)
You're welcome - I hope it was not too abrasive/obnoxious ;)
> > hmmm - Cinelerra getting the field order wrong?
>
> Exactly. At least with the SVN version I fetched 1 month ago. There's a
Ouch. One would think a problem like that would be fixed quickly, but
Cinelerra doesn't have mailinglists, etc and getting in touch with
the developer is difficult (I tried once years ago and never heard
anything).
> > Is that a typo? 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
Ah ok.
> OK. The problem is that I don't know which options are set when using -f 8.
The important ones ;) All you should need to specify is the '-q'
and perhaps a bitrate.
> > -V 1853 is ABSURDLY high. That value is the amount of "buffering"
>
> Damn! I thought the value was in kb, not KB. That's why I used 1853. In
kilo-bytes. So 1853 is enough for 4x a High-Def stream ;)
> 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
A couple hundred kilobits/sec won't be visible - even to "golden
eyeballs".
> 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.
Maybe not really - you forgot to include the muxing/navigation overhead.
There is additional information in a "VOB" stream that gets read in
addition to the video and audio streams. Best to leave a little extra
room.
Couple things to remember: NO encoder has 100% perfect rate control.
Doesn't matter if you're trying for 'cbr' or not - there's be a peak
or spike that'll cause the stream to slightly exceed the buffering
checking.
I didn't see that you used "--cbr" anywhere.
From the manpage:
NOTE: By default MPEG-2 streams (-f 3, 4, 5, 8 and 9 are VBR. Use the
--cbr option for generating CBR (Constant Bit Rate) streams.
Oh, another thing to remember is that there's a good possiblity you'll
simply cause the encoder to use "stuffing bits" to pad the bitrate.
Those are bits effectively read from /dev/null and put into the stream
to give you a constant bitrate. Padding/stuffing bits are 100% wasted
(non-picture) bits.
> 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
Your family's performing in a classical concert and you used good
external microphones to capture a high quality soundtrack (rather than
the microphones builtin to the camcorder which are not very good
I've found)?
384Kb/s for audio is overkill for video recorded with onboard/builtin
camcorder microphones. I think if you used 224Kb/s or even 192Kb/s
you wouldn't notice the difference and the slightly lower muxed data
rate would avoid the warnings you're seeing.
...
> OK. So, I don't worry anymore about the "missing B frames". ;-)
THat's a good idea - especially if there are "high motion" scenes.
"Home video" often has wild zooms/pans and so a straight IPPPP...
sequence is better anyhow.
> 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
That's just a warning based on mplex's estimated max rate
The target (-f 8) maximum rate is 10.08 Mb/s (10080000) but mplex
has estimated that the stream will actually need 10.4034 ( 10403400).
As long as no "under run" errors (which are Fatal) happen you're ok.
> 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?
could well be passing thru a stream with a rate spike that'll cause
problems.
Why not just go down slightly - try 224 for the audio and perhaps
9600 for the video. You won't hear or see the difference but it
will probably end the warnings.
Good Luck!
Steven Schultz
-------------------------------------------------------
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
