On Thu, 22 Jul 2004, Marc Gregoire wrote:
> First, thank you for the elaborate reply. I really appreciate this.
Welcome!
> Second, I don't have the original flower (it's not my picture), so I took
> another image of which I do have the original to work with.
> This picture can be found at the following links:
Ah, ok - I'll take a look and do some experimenting later tonight
when I have time.
> The original picture above was taken with a Sony digital video camera...
> 1360x1020. The camera automatically saves them to a lowly (to avoid
> graphical artifacts) compressed JPG.
Some cameras have the ability to select the "quality" (degree of jpg
loss).
> The same scaled image was used by the commercial encoder so that non of the encoders
> had to do any scaling.
Actually I think it does. If the commercial encoder was constrained
to ~11Mb/s I think we'd see the same degree of distortion as mpeg2enc.
And taking a look, at least at the flower image, there is the fringing
observable - and I think that's a combination of jpeg compression and
scaling (at least to a certain extent).
> The ringing might come from the jpg artifacts which are then enlarged by mpeg2enc.
> But, see my new tests above, you clearly see that
Exactly! With a sufficiently high bitrate the two encoders become
quite close in visible image. It's the 3x bitrate difference that's
causing imperfections to be magnified.
> Are you one of the developers on mjpegtools?
I dabble around a bit :)
> If so, perhaps you can add a --version or something to query the version of
> mpeg2enc. Just a suggestion ;)
Yeah, I thought there was one and Hmmm, i see there isn't - something
to fix in my copious free time ;)
> I will try to compile the latest CVS version when I find some more time and will
> post my results to this mailinglist.
>
or the -developer list - which ever you prefer. Yes, that would
be appreciated (and "diff -u" patches even more so <grin>)
> Ok, the rate control might be better but I still get those discontinuities between
> blocks.
> Isn't there anything about mpeg2 stills in the mpeg or DVD standards?
> Perhaps the standards allow for much higher bitrates for stills?
That might indeed be the case. I know mpeg2enc has "VCD" and "SVCD"
still capability but for DVDs, well, it appears we're trying to
abuse the general encoding capability.
That's an excellent idea though - perhaps someone more familiar with
the mpeg2enc internals could look into adding a "-f 10" for "DVD stills"
> What do you mean 'wacked'? Do note that the stills created with
I mean it's going to 35Mb/s instead of trying to constrain it to < 10
or so.
> I'll have to checkout that CVS version then ;)
Good idea. AT that point you can manually give the parameters to
get a much larger still frame size.
> > The differences between encoders is, as you'd expect,much less when
> > comparable (but wildly high) bitrates are used. Not
> > identical but close enough.
>
> Did you see any discontinuities between blocks in the mpeg2enc results?
The blockiness/fringing is much reduced and similar - you have to
zoom up a bit before seeing it. So yes, it;s better than before.
Perfect? Probably not but then I don't have golden eyeballs ;)
> PS: Do note that the discontinuities in the blocks are visible when
> playing the DVD's on the PC and are much less visible when playing the
> DVD's on a TV set, but I just thought I'd mention this quality issue.
THat was my though too - on most TV sets the resolution/bandwidth is
lower and you'd not see the differences.
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
