On 31-Jan-2003 Matto Marjanovic wrote:
|
| Actually, it *does* make a difference where it happens.
| (i.e., now it is your turn to get flamed by me for shoddy work... :)
OK, OK. I have been in an angry mood while writing theese lines. And also
in hurry while doing the tests. My fault.
But nevertheless, there is work to do identifying/fixing the
non-compliant tools one by one. Which tools are known to be compliant?
Which have clearly identified problems with value-ranges? Which have an
unknown state?
|
| 1) Your test scenario is *far* from simple --- it uses at least 6
| different utilities, some with well-known flaws, and some
| which are not part of this MJPEGtools project...
True. Sorry. But this tool-chain came out of practical use. I first set it
up to convert my holiday movies and then I discovered the problems...
|
| 2) You *should* have just created a program to produce a synthetic
| YUV4MPEG2 stream which you could feed through the various
| tools, and then you *should* have analyzed the results,
| directly from the output YUV4MPEG2 stream.
True again. But in my oppinion another permissible method is to set up an
arbitrary tool-chain and check the correctness of the Y'CbCr stream after
each state by measuring the min/max of the values. This is what I did. I
should have mentioned.
|
| 3) It's not "YUV". It is "Y'CbCr" or "YCbCr". If you are going to
| be picky about standards, then you should conform yourself to those
| standards.
Sorry again. I'm just picky about disconformances if they hurt. This case
garbled my movie.
|
| 4) OF COURSE you are getting clipping --- you are taking
| out-of-range Y'CbCr values, passing them through some
| byzantine collection of codecs, and then, as your final
| step, you are converting them to R'G'B' in the Gimp!
| That last step is always going to clip Y'CbCr values which are
| out of the range of the R'G'B' color cube.
| I would venture to say that mplayer is actually doing the correct
| rescaling of the Y'CbCr in the MPEG stream it is converting to
| JPEG, and thus the clipping is (correctly) occurring there.
As I rescaled the values myself before feeding them into
"mpeg2enc->mplayer->jpeg->gimp", I avoided the clipping there.
The clipping itself is not the problem, but the only way to cope with the
problem. The actual source of the problem is some tool (I think
yuvdenoise) which reads a conforming Y'CbCr stream and outputs a broadend
one.
|
| 5) At most, you have demonstrated that jpeg2yuv didn't properly
| rescale the Y'CbCr values in your colorbars. This is not
| news; it is documented in the jpeg2yuv manpage, and it was
| fixed by Gernot this week.
After jpeg2yuv I measured no out-of-range values. But after yuvdenoise, I
did. Yuvdenoise seems to be the tool that broadens the value-range. When
I leave it out of the chain the clipping effect dissappears. So I expect a
problem there, too.
Sorry again for the flames. I respect the work of other people and I'm
happy to be able to use this software for free. Anyhow I'm interested in
making the software better. As video-code is not my domain, but I like it,
I try to stick to give hints and test results to the gurus.
Regards,
Ralf Oehler
--
--------------------------------------------------------------------------
| Ralf Oehler
|
| GDA - Gesellschaft fuer Digitale _/
| Archivierungstechnik mbH & CoKG _/
| Ein Unternehmen der Bechtle AG #/_/_/_/ _/_/_/_/ _/_/_/_/
| _/ _/ _/ _/ _/
| E-Mail: [EMAIL PROTECTED] _/ _/ _/ _/ _/ _/
| Tel.: +49 6182-9271-23 _/_/_/_/ _/_/_/#/ _/_/_/#/
| Fax.: +49 6182-25035 _/
| Mail: GDA, Bensbruchstraße 11, _/_/_/_/
| D-63533 Mainhausen
| HTTP: www.GDAmbH.com
--------------------------------------------------------------------------
time is a funny concept
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
