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
