I have upgraded from a Mandrake-supplied 1.6.1 to self-compiled 1.6.1.90 yesterday after reading about that yuvdenoise can passthrough interlaced material now. Great work! yuvdenoise and mpeg2enc is much faster now!
I have cut a sports event footage containing both high-activity sports scenes and low activity interview scenes.
In an effort to fit it to a CD yet retain good quality, I wanted to go VBR (constant q) and spare bits during (heavily yuvdenoised) interview scenes to use for the sport scenes.
The material was PAL, digitized at [EMAIL PROTECTED], uncompressed YUV 4:2:2
However I have noticed, that during pure black mpeg2enc 1.6.1.90 uses up to 1.4 Mbit/s no matter whether -q is 1, 4, 8 or 12. This I find strange.
The command line used is as follows:
mpeg2enc -f 3 -g 6 -G 28 -b 5000 -q 12 -s -Q 2.0 -r 32 -I 1 -S 2000 -o <filename>
I hoped for - there being absolutely no change in the picture, that is no motion nor AC coefficients to code, so all macroblocks could be skipped - that pictures would end up being coded with, say, at most several hundred bits.
Not so!
Files sizes for one second of pure black:
171261 bytes -q 1
171287 bytes -q 4
171287 bytes -q 8
171287 bytes -q 12
(These sizes are so close to each other, I start to suspect some kind of padding might be done on purpose here to prevent video buffer underruns?)
File size for one minute of pure black at -q 8 is 9890165 bytes (1.31 Mbit/s). [Interestingly, gzip compresses this down to 1/93th: 106254 bytes.]
If I doing the math right, that makes six bytes per macroblock.
Then I theoretized maybe handling pure black has problems, but I will rarely have pure black areas in pictures anyway.
What I will have is pictures where large areas have no change.
To test behaviour in the 'no change' case, I took one frame out of an interview scene and duplicated it to make a clip, and encoded it with the same settings.
Files sizes for one second of 'no change': 597014 bytes -q 1 164578 bytes -q 4 57688 bytes -q 8 37687 bytes -q 12
File size for one minute of 'no change' at -q 8 is 3321980 bytes (443 kbit/s).
'No change' compresses to about one third of the size that pure black compresses to! This is totally contrary to my expectations. :)
I have uploaded the MPEG streams output by the above mpeg2enc runs for further inspection here:
http://andras.kadinger.hu/lomtar/mjpegtests/
Could this probably point to a deeper issue?
Or am I approaching VBR the wrong way?
Thank you in advance.
Best Regards, Andras Kadinger
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
