Thank you for taking up this thread.
Andrew Stevens írta:
The big question is whether 'pure black' really is 'pure black'. If it isThe first time I noticed this issue was when I prepended some lead-in black/silence in front of actual digitized material in Cinelerra and then started to encode that with mpeg2enc.
digitised there will almost certainly be residual noise.
To simplify testing, I then generated a pure black [16,128,128] YUV4MPEG2 frame with a tiny C program, and created a tiny shell script to prepend a YUV4MPEG2 header and repeat the black frame to stdout to create a YUV4MPEG2 stream containing pure black frames in the desired length.
All my observations on mpeg2enc behavior related to this thread were done using such digitally pure black streams.
This is my current hypothesis indeed, especially considering the fact that the the one minute long, encoded MPEG Video stream could be compressed down to it's 1/90th size by such losless compression utilities as gzip or bzip2 - a quite unusual property of an MPEG Video stream.Files sizes for one second of pure black:However... there could be some bug in the motion compensation / macroblock type selection routines that is showing up. They really should be being skip-coded...
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?)
If I doing the math right, that makes six bytes per macroblock.
When I did my first test runs, I had -Q at 2.0. Bernhard Praschinger suggested to omit -Q, so this made me think and I ended up hypothesizing, -Q 2.0 could have perturbed the skip/encode decision logic due to the material lacking any size/complexity difference between macroblocks (there wasn't any statistically meaningful distribution of macroblock complexity to set a threshold over) resulting in all of the macroblocks getting classified as needing quantization reduction and therefore getting encoded instead of skipped.
It was today that I got around to do some tests without setting -Q, and the results are very similar.
Bernhard also asked about the number of I/P/B frames. GOP size is 15 frames, and the frame types follow a regular IBBPBBPBBPBBPBB pattern.
When encoding one minute (1500 frames) of pure black at [EMAIL PROTECTED] (or 25p - this fortunately doesn't matter much in this case), the total activity counter climbs continuously to finally arrive at 552000 - I'm not sure about the dimensions of that metric, but that's exactly 368 per frame (in our testcase a frame is 1080 macroblocks if I'm doing the math right).
Sorry about that; DNS trouble forced me to move some of my material between different servers. Here is a current link of my test case and demonstration:http://andras.kadinger.hu/lomtar/mjpegtests/
Tried to access this but got a 'not found'. Even more useful would be the .avi you encoeded so I can see what mpeg2enc is doing with the Data.
http://www.surfnonstop.com/~bandit/pureblack_testcase/
Best Regards, Andras
------------------------------------------------------- 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
