And you have shown convincingly that there is a better alternative
to one existing jpeg2000 implementation. It will be no problem to
write a faster one if you have the time (or the money), I am not sure
if compression will be better than with current libopenjpeg.
How much (approx) would it cost to write a faster jpeg2000 encoder for
ffmpeg?
Note that the issues with jpeg2000 are of course nothing against the
issues that mxf has, iirc you already know that there are as many
interpretations of the standard as implementations, don't you?
The most solutions which are using JPEG2000 are encoding in lossy
compression mode, as far as I know.
Additionally, I spoek last week with a very professional video guy, and
he said to me how he checks the "losslessness" of jpeg2000.
He makes a difference picture of the original source and the encoded
jpeg2000 -> and checks this just VISUALLY. (o.O)
He does not make frame md5s. So his (mathemtically) lossless checks are
only visually checks.
And yes, I know that there are so mich implementations. Like Samma Solo
(Front Porch) or OpenCube etc...
The most solutions which are using JPEG2000 are anyhow encoding in lossy
compression mode, as far as I know.
And regarding the "professional" solutions: Please ask them to show
you how to get the original content back after encoding once;-)
Please do not top-post here, Carl Eugen
Yesterday I tested to extract the original source from a libopenjpeg
encoded file, and it worked (check was done with framemd5 checksums).
But i need to force ffmpeg to use the libopenjpeg decoder.
If I give the jpeg2000 MXF file (libopenjpeg) as source into a CARBON
CODER, the picture looks exactly like the same I see in ffplay when I
DONT use the libopenjpeg decoder. Officially Carbon Coder is able to
READ jpeg2000.... but not to read correctly?
bg Christoph
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
