On Tue, 20 Jul 2004, Marc Gregoire wrote:
> > > F:\dvdauthor/jpeg2yuv.exe -n 1 -f 25 -I p -j flower.jpg >
> > flower.yuv
> > > F:\dvdauthor/mpeg2enc.exe -q 4 -n p -a 2 -f 8 -I 0 -4 1 -2
> > 1 -D 10 -h
> > > -F 3 -o flower.m2v < flower.yuv
I didn't comment on it earlier but it would appear that you're using
a really old windows version of mpeg2enc. Over time there have been
quite a few changes that stood a good chance of breaking the Win32
build but no one's mentioned anything - that either means mjpegtools
still builds ok on win32 (and no one's said anything) _or_ it doesn't
build but no one has noticed...
> > > the resulting m2v file generated by mpeg2enc is 57 KB for the
> > > ... while the m2v file generated by the other encoder is 173 KB.
> > other encoder is using about 3x the bitrate. Naturally with that
> > kind of disparity one would expect to visual differences ;)
> > Try using -q 3 or perhaps -q 2 with mpeg2enc. I'm not
> Yes, I know that the other program is generating 3x as big files and I know
> that's why the image quality is much better, but I'm unable to let mpeg2enc
> generate still mpegs of that size and quality.
> Btw: is there any way I can query the bitrate of an .m2v file,
> so as that I can check the bitrate of the other encoder.
Other than a bitstream analyzer ($$$ unless someone knows of a less
expensive or even free one) the only thing I know of is to mplex the
.m2v file with NO audio and look at the bitrate summary.
mplex -f 8 -o /dev/null flower.m2v
Towards the end of the report you'll see lines like:
INFO: [mplex] No. I Frames : 833 avg. size 43149 bytes
INFO: [mplex] No. P Frames : 3280 avg. size 34467 bytes
INFO: [mplex] No. B Frames : 8169 avg. size 26840 bytes
INFO: [mplex] Average bit-rate : 7188400 bits/sec
INFO: [mplex] Peak bit-rate : 7210400 bits/sec
If you see something about "D frames" then that is a _really_ ancient
version of mplex ;)
> I have tried like you suggested to use -q 3, and I also tried -q 2 and -q 1.
> With -q 1 the size of the file becomes 64 KB (far from the 173 KB) and the
> artifacts are still there. :(
That doesn't seem right. I'd have expected a big jump in filesize
going from -q 4 to -q 2. The only thing I can think of is
that the default bitrate of mpeg2enc is restraining the size. The
default is 7500Kb/s. You might try raising that with "-b 9800" and
see if an extra 25% or so makes a difference.
I did take a look at the two images you mentioned (PNG would be lossless
so you wouldn't have to worry about introducing artifacts during the
re-creation of the .jpg files). Yes, I see a bit of fringing around
the edges of the flowers. I can't see the difference in crispness
that was mentioned though.
Could you make available the original flower.jpg file? It's probably
too big to post to the list - so a mail item to the list with a link
would work well. I'm curious what recent versions of mpeg2enc will do
with the same
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
