>On Thu, 16 Jun 2005, Matto Marjanovic wrote:
...
>> One would expect the _quality_ of the encoding to vary though. With the
>> 24fps input, mpeg2enc should have more room in the same file to store
>> real information. With the telecined input, mpeg2enc will squander
>> some of its limited bit reservoir in encoding those redundant fields.
>
> Is it reasonable to say:
>
> If it's not bitstarved in the first place (i.e. isn't using
> all the bits it was given) then reducing the amount of data
> substantially should result in a smaller (even less bitstarved)
> file?
Sounds reasonable to me.
I've kind of imagined that at "-q 2", mpeg2enc is almost always bitstarved,
in the sense that it is getting close to being asked "please try to
encode this losslessly, if possible".
704 * 480 * 1.5 * 8 * 24 = ~97,321 kbps
/ 6,400 kbps
------------------------
15:1 compression ratio required
704 * 480 * 1.5 * 8 * 30 = ~121,651 kbps
/ 6,400 kbps
------------------------
19:1 compression ratio required
"-q N" kind of translates into "minimum compression ratio".
"-q 2" probably equates to less than "15:1". (Yes? No?)
Following that logic, until a 'q' minimum is chosen which falls between
15:1 and 19:1, you won't see much difference in file size.
It'd be neat if mpeg2enc provided some statistics as to the 'q' levels
it actually uses per frame (since the command-line parameter is just
the minimum).
-m
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Mjpeg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
