Re: mpeg2enc with MJPEG Tools 1.9.0rc2 buggy !

Hi I have the same problem with rc2 !

I encode a DVD with an older version of mpeg2enc (just before rc1) the problem doesn't appear, 
the quality is perfect.

If I use mpeg2enc rc2 with the same video file and the same parameters, the image quality
is VERY VERY POOR !

I think it's a bug in rc2, introduce after rc1.

I have compiled rc2 on a MacIntel, the speed is good, the quality very poor
I have compiled rc2 on a Mac PPC, the speed is VERY VERY SLOOOOOW and the quality very poor.

If I try mpeg2enc juste before rc1 on a MacIntel or MacPPC theses problems doesn't appears.

I am sure that this is a bug of mpeg2enc, I use mpeg2enc for 3 years now, and I doesn't have seen
this problem before 1.9.0 rc2.

Christophe
 
On Monday, March 19, 2007, at 08:14AM, "stefan" <[email protected]> wrote:
>stefan schrieb:
>>> First, if you are encoding for DVD do *NOT* use '-q 1 -b 9000'!
>>>     
>>
>> Which is very mpeg2enc related. I now know several encoders (ffmpeg 
>> included), which produce a *lot* less bitrate-spikes and seem to avoid 
>> them completely in 2-pass-mode ... I have even seen some files where 
>> there have not been any spikes...
>>
>>   
>>> If you use "-q 3" or "-q 4" the problem appears to go away.
>>>     
>> Sorry,... not here... :-(
>>   
>>> Ideally and eventually '-q' should go away completely.  ALl that should
>>> be specified is a desired average bitrate and a tolerance (how much
>>> above/below the average is acceptable).
>>>   
>>>     
>> 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 
>> completly black frame: P+B frames could be close to zero-size (just the 
>> overhead to say the decoder "same than before"...).
>>
>> 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...
>>
>> 2) average-bitrate-mode or "filesize-mode": Here it makes some sense to 
>> specify an upper-bound-tolerance, only.
>
>and in case someone asks... an average-bitrate, of course...
>
>>  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...
>>
>> hmm,... seems like I must use ffmpeg, currently...
>>
>> cu
>> Stefan
>>
>>
>> -------------------------------------------------------------------------
>> 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-developer mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/mjpeg-developer
>>   
>
>
>-------------------------------------------------------------------------
>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-developer mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/mjpeg-developer
>
>

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