Re: mpeg2enc with MJPEG Tools 1.9.0rc2 buggy !
"Steven M. Schultz" <[email protected]>
| Newsgroups | gmane.comp.video.mjpeg.devel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 19 Mar 2007, stefan wrote: > > Ideally and eventually '-q' should go away completely... > > > Huh? I don't regard this to be a good idea. There is no harm, if an > encoder uses less bits than specified by the bitrate. Imagine a Why? Your sugessions say the same thing - just using different words ;) > I think, mpeg2enc needs two bitrate-modes: > > 1) variable bitrate-mode: A local and short second pass is just used to > chop off bitrate-spikes. That is, whenever the encoder realizes that > there was a spike, it goes back some frames (a GOP?) and reencodes them > with a lower q-scale again. But only for that spike... So if the encoder is going to compute the -q why bother with the user specifying it? > 2) average-bitrate-mode or "filesize-mode": Here it makes some sense to > specify an upper-bound-tolerance, only. The encoder must not go beyond > this. If not possible otherwise, then use 2 passes... This mode should > fit a file as close as possible to a given file-size/average-bitrate... Again, where is -q? In BOTH cases you have set the bitrate or filesize and let the ENCODER COMPUTE the effective -q? WHY does the user have to specify both the rate and the initial q? Give a bitrate and let the encoder do the job. > hmm,... seems like I must use ffmpeg, currently... Or Compressor2 - that's what I'm doing until mpeg2enc is trustworthy once again :( Cheers, Steven Schultz ------------------------------------------------------------------------- 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