>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 Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users