Re: [Mjpeg-users] 26 frames 480x576@50i pure black compresses to 167kB - 1.6.1.90
On Fri, 3 Oct 2003, Andrew Stevens wrote: > ... modifications that meant intra coding was being preferred slightly to > non-intra coding.This is the wrong way around as non-intra can be skip > coded (when blocks are unchanged) whereas intra cannot... > > I've fixed this now in CVS... Super! Alas that means that only developers can get the changes. SourceForge is 72 (going on 96) hours behind - changes I made several days ago are still not visible in either the WWW CVS or anon CVS servers :( Steven Schultz --- 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
Re: [Mjpeg-users] 26 frames 480x576@50i pure black compresses to 167kB - 1.6.1.90
Hi Andras, I had a look at this issue and there was indeed a suble issue in some recent modifications that meant intra coding was being preferred slightly to non-intra coding.This is the wrong way around as non-intra can be skip coded (when blocks are unchanged) whereas intra cannot... I've fixed this now in CVS... Andrew --- 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
Re: [Mjpeg-users] 26 frames 480x576@50i pure black compresses to 167kB - 1.6.1.90
Andras Kadinger írta: 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://www.surfnonstop.com/~bandit/pureblack_testcase/ I'm sorry, the above link won't work due to DNS problems. Please try the one below instead: http://195.70.35.24/~bandit/pureblack_testcase/ --- 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
Re: [Mjpeg-users] 26 frames 480x576@50i pure black compresses to 167kB - 1.6.1.90
On Wed, 24 Sep 2003, Andras Kadinger wrote: > 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. To do that type of thing I have a simple program that can generate any color (-Y, -U, -V), any dimension, and allows setting the aspect, interlace, rate tags. Oh, can also genereate 4:1:1 output (NTSC's DV colorspace). It started out as a simple generate black frames (hence the name y4mblack ;)) but was added to over time.If others would find something like that useful I could add it to the mjpegtools package. Cheers, Steven Schultz --- 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
Re: [Mjpeg-users] 26 frames 480x576@50i pure black compresses to 167kB - 1.6.1.90
Greetings Andrew, Thank you for taking up this thread. Andrew Stevens írta: The big question is whether 'pure black' really is 'pure black'. If it is digitised there will almost certainly be residual noise. The 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. 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. 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?) If I doing the math right, that makes six bytes per macroblock. 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... 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. 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). 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. 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://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
Re: [Mjpeg-users] 26 frames 480x576@50i pure black compresses to 167kB - 1.6.1.90
Hi Andras, Sounds very interesting... > 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: The big question is whether 'pure black' really is 'pure black'. If it is digitised there will almost certainly be residual noise. > 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?) > If I doing the math right, that makes six bytes per macroblock. > 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... > 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. Thanks for feedback... Andrew --- 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
Re: [Mjpeg-users] 26 frames 480x576@50i pure black compresses to 167kB - 1.6.1.90
Hallo > 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 > Have you tried it without the -Q flaog ? > 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. > 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?) When you multiplex the file home man I/P/B frames do you have ? Have you take a look after how many frames you have a new I frame ? you should see that with he default output options. (GOP start (15 frames)) There mpeg2enc also tells you also the average framesize. in my case it was always I: 9023, P/B: 9770 bytes. (PAL) > 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.] Every I Frame has a specivic size mpeg2enc can't compress lower but any other programms can do. How did you generate pure black ? I did: lav2yuv test.eli | yuvscaler -I ACTIVE_4x4+0+0 | mp2enc -o test.mp2 I got a similar result for DVD size. > 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. Usually a black area in the image will help to save bits. > 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? No solution. Usually you have a lower bitrate for areas where you set to black. Instead of something that is near black. auf hoffentlich bald, Berni the Chaos of Woodquarter Email: [EMAIL PROTECTED] [EMAIL PROTECTED] www: http://www.lysator.liu.se/~gz/bernhard --- 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
