Hi - On Wed, 21 Jul 2004, Marc Gregoire wrote:
Combination reply to the last couple postings ... > > What size/resolution are the slides (source .jpg files)? Are they > > I had scaled the original image to 720x576 with an external program and used > the scaled version for both mpeg2enc and the other encoder. I'm still curious what the originals were before any scaling - were they from a multi-megapixel camera, a scanner, how were they converted to .jpg, etc. One other thought just hit me - if you can get the image into PPM format (which should be a lossless operation) then y4mscaler (and other mjpegtools programs) can be used. That would avoid going thru JPG which may introduce ringing at edges. > I scaled the image before encoding with another program. (720x576) This > scaled image can be seen at: > http://www.nuonsoft.com/temp/flower_orig.jpg I was hoping to get the raw unscaled/processed original so I could run an experiment or two and see if the distortion is coming in during the conversion to .jpg and scaling. From what I've seen that is the case - look at the flower_orig.jpg at a 2x or 4x zoom in the GIMP, there is the same ringing on the edges of the flowers and so on as the mpeg2enc version shows. > In response to your other reply: > I was using an older version of mpeg2enc as can be seen from the -h parameter > which is -H in the latest version. Ok. Yeah, using -h wasn't a good idea since that's conventionally the way to request help or the usage summary. >So I downloaded mjpegtools 1.6.2 and compiled it with cygwin without a problem. Super! I was fairly sure that was ok - but after that release a lot of changes were made. Some of those changes stood a good chance of breaking the win32 build. If you can try building the CVS version it'd be of interest (apparently none of the developers has much interest in windows - I know I don't ;)). > Using that mpeg2enc version, changing -h to -H I get almost the same > results. Even with a -q 1, the filesize just barely increases. The largest file I got was about 61000 bytes or so. Which is correct - even with a small number (1) of frames the rate control of mpeg2enc is better than the other encoder and is attempting to keep the bitrate out of the stratosphere. > Even when I increase the bitrate with -b to 15000 (which is way to high > for DVD !) I get a .M2V of barely 100 KB. True - but, that's just 1 frame. Peaks need to be a bit longer in duration than that (apparently) to cause problems - you definitely couldn't have that as any kind of longer term average. > If you find the time, could you take a look at the original image I posted Yes, I took a look at the image and experimented for a little while. One part of the experiment does require, I believe, the CVS version of mpeg2enc because a bug was recently fixed. Until a few days ago the "--no-constraints" option was broken - the effect of that breakage was that mpeg2enc would enforce the maximum bitrate for [EMAIL PROTECTED] (Main Profile @ Main Level), there was no way to give huge values for -b. > .M2V generated by mpeg2enc and by the commercial encoder. The results are: > For mpeg2enc: > INFO: [???] No. I Frames : 1 avg. size 58161 bytes > INFO: [???] No. P Frames : 0 avg. size 0 bytes > INFO: [???] No. B Frames : 0 avg. size 0 bytes > INFO: [???] Average bit-rate : 11632000 bits/sec > INFO: [???] Peak bit-rate : 0 bits/sec > > For the other encoder: > INFO: [???] No. I Frames : 1 avg. size176348 bytes > INFO: [???] No. P Frames : 0 avg. size 0 bytes > INFO: [???] No. B Frames : 0 avg. size 0 bytes > INFO: [???] Average bit-rate : 35269600 bits/sec > INFO: [???] Peak bit-rate : 0 bits/sec > So somehow the commercial DVD author package is creating a .M2V with a > reported average bitrate of 35 Mbit. This really confuses me Averages require more than 1 sample to be significant :) 1 frame isn't enough to compute an average. In fact for 1 frame you don't even need mplex. Just take the size of the frame, multiply by 25 (frames/sec) and then by 8 (bits/byte). That's all mplex is really doing in this case. Thus it appears that the rate control for the other encoder is rather wacked ;) > tested the DVD on (standalone and software players). I thought DVD's Well, software players will play anything subject to the available cpu power. > were limited to something around 10 Mbit max. They are - and if you created a stream at the bitrate above no player around would touch the resulting disc. But I wouldn't be surprised if there were a player somewhere that was allergic to 170KB frames. > When multiplexing (with a silent audio-frame) the commercial generated .M2V file > with mplex I do get the following warnings: > ++ WARN: [???] Stream e0: data will arrive too late sent(SCR)=13019 > ++ required(DTS)=0 That's because the VBV (Video Buffer Verifier) size is too small - that's the "-b" option to mplex. The VBV size is correct for up to ~10Mb/s but if you get a huge spike (as in ~35Mb/s) then the default 220KB buffer isn't the right size any more. HDTV (which in the US uses a 19.8Mb/s stream) has a VBV of 488KB for example. Ok, now on to the results of my testing this afternoon/evening. Created the Y4M file with: jpeg2yuv -n 1 -f 25 -I p -j flower_orig.jpg > flower_orig.y4m Then encoded that with: cat flower_orig.y4m | mpeg2enc -q 1 --no-constraints -b 30000 -V 488 -f 8 -I 0 -4 1 -2 1 -D 10 --keep-hf -o flower.m2v (I used 'cat' so I could easily place other filters inline before the encoder if I wanted to - and indeed using yuvmedianfilter was one that I tried, seemed to work ok). Note: the 30Mb/s rate and the use of a large VBV size. To go with higher rates I'd need to bump up -V some more but for now 30Mb/s was enough. The resulting .m2v file size is: -rw-rw-r-- 1 sms wheel 155345 Jul 21 10:35 flower.m2v If I used -b 35000 I think the size (and appearance) would be almost identical to the other encoder's. mplex -b 488 -o /dev/null flower.m2v reports: Average bit-rate : 31068800 bits/sec Now to view the result it's necessary to decode the .m2v file and get it to something the GIMP can display. For this I used 'mpeg2dec' (from the libmpeg2 project). Ordinarily I'd use MPlayer but it chokes on 1 frame .m2v files ;( mpeg2dec -o pgm flower.m2v produces a file that 'pgmtoy4m' (from the cvs version of mjpegtools) can convert to a Y4M file. From Y4M to PPM is done with 'y4mtoppm' of course. cat 0.pgm | pgmtoy4m | y4mscaler -O chromass=444 | y4mtoppm -L > 0.ppm Then use the GIMP to view 0.ppm (not going to .jpg at this point avoids further degradation). The 0.ppm file is large of course at "1244175 Jul 21 10:35 0.ppm" - even bzip2'd it's 674580 bytes. The differences between encoders is, as you'd expect, much less when comparable (but wildly high) bitrates are used. Not identical but close enough. If the image were processed or the data filtered the bitrate can be left at "sane" levels and the appearance improved that way. Perhaps a higher quality scaling method would exhibit less ringing on the edges - that would be one thing to try. Another thing to try would be processing the downsized image with the GIMP - perhaps a slight blur or median filter would help. One thing I did try, and it dropped the bitrate like a rock was add 'yuvmedianfilter' to the command sequence: cat flower_orig.y4m | yuvmedianfiler | \ mpeg2enc -q 1 --no-constraints -f 8 -I 0 -4 1 -2 1 -D 10 --keep-hf -o flower.m2v Came out looking quite decent - on a typical TV set I doubt you'd be able to tell the difference between that and the original. An interesting experiment would be to convert from BMP to PPM (which is lossless) instead of JPEG. Then use 'ppmtoy4m' to convert to Y4M (lossless) and use 'y4mscaler' with a 6 or 7 tap sinc scaling kernel - that is lossy of course BUT it's different than JPEG's lossy compression. Might result in better data going into the encoder but then it might not make all that much difference - have to try it and see what happens. Cheers, Steven Schultz ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users