Am 26.02.2008 um 04:53 schrieb Steven M. Schultz:
>
>
> On Mon, 25 Feb 2008, [UTF-8] Bernhard Frühmesser wrote:
>
>> I was wondering if anyone knows the programm Compressor from Apple?!
>
> I've used it and the later version (Compressor2). Not very often
> for video, mostly for AC3 audio encoding. Haven't seen the latest
> version (3).
>
>> I am asking because i was curious and did a test with a 6 minutes
>> video,
>> one i encoded to MPEG2 using "Compressor" under MAC OSX and then i
>> used
>> mpeg2enc on the same video on my Linuxbox.
>
>> I am sure i used the same settings on both computers but the file
>
> That's impossible ;)
:-) Well ok, not exactly the same setting, but for both i used
(tested) 9,5Mbit and in Compressor i used 1 pass CBR with a max
number GOP Size of 6 (IPPPPP) for mpeg2enc i used -g 6 -G 12 and -q 6
> That of course requires some explanation so here we go...
>
> You almost certainly specified a "-q" with mpeg2enc. That is a
> flooor,
> a minimum below which mpeg2enc will NEVER go. mpeg2enc will raise
> "-q"
> (increase the amount of compression) to keep the bitrate below the
> maximum. In its extreme and buggy form this increase will cause the
> effective quantization to be 30, 40 or more and poor quality.
>
> However, if the encoding produces a bitrate LESS than what you
> specified
> on the command line then mpeg2enc will NOT lower '-q'!
>
> This has the effect of transforming the '-b' (bitrate) option into
> a "maximum" (try not to exceed) RATHER than an "average".
>
> SO if you don't specify a low enough value of '-q' the average
> bitrate
> will be less (often a lot less) than the value specified by '-b'.
> You
> may specify "-b 8000" but depending on the -q you may end up with an
> output file closer to 3500.
For -q i used 6 and for -b 9500 (testing),
> Compressor on the other hand uses the bitrate you specify as an
> AVERAGE and will not only increase the effective quantization ("-q")
> to keep the bitrate low enough, Compressor will also DECREASE the
> quantization to increase the bitrate towards the specified average
> value.
>
> This means it's really not possible to say much more than "I
> specified
> the same bitrate" to both compression programs. How that that
> value is
> used is different. And the concept of '-q' and the other options
> from mpeg2enc are not present in Compressor (just very limited choice
> of GOP size).
>
> Compressor is doing what mpeg2enc _should_, in my opinion, be doing:
> use the specified bitrate ('-b') as an average (not maximum) value
> and doing completely dynamic and _INTERNAL_ adjustment of
> quantization
> ("-q" should be removed from the list of options).
>
>> with mpeg2enc has only 114MB so far i don't see much quality
>> difference.
>
> Which brings me to the point I believe I've made before.
>
> Pushing -q too low doesn't necessarily increase visual/perceived
> quality. It will raise the bitrate but will you see the difference?
> Maybe, maybe not.
I have tested both programms with a video which has more contrast and
structure in it, and there (with the same settings used before) the
(bigger) output for Compressor is a bit better, as it keeps more detail.
> Too much time is wasted fiddling with "-q" in the name/quest of
> "quality". This is because mpeg2enc doesn't do it automatically
> but realistically most folks could just stick a "-q 4" in place and
> be done with it. Maybe some day -q will go away but I'm not holding
> my breath (you turn blue that way :)).
>
>> So i was wondering what this could come from? Any ideas?!
>
> I think, in your case, the video doesn't need as high a bitrate as
> you specified and the values you used with mpeg2enc caused a lower
> bitrate to be used. It's also possible you're seeing a mild version
> pf the bug that can causes mpeg2enc to push -q up too high.
Well, the Bitrate which i used was just for testing (curiosity) :-)
> You can get a good idea of the average bitrate like this:
>
> mplex -f 8 -o /dev/null input.m2v
>
> Try that on the two .m2v files you have and see what the average bit
> rate and frame sizes are.
>
Thanks !!
C,
BF.
> Cheers,
> Steven Schultz
>
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Mjpeg-users mailing list
> Mjpeg-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mjpeg-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
