[FFmpeg-user] Mathematically lossless MotionJPEG2000 encoding possible?

[Carl Eugen Hoyos]

On Tuesday 28 October 2014 10:39:18 am Christoph Gerstbauer wrote:
> > 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?

I was hoping you would understand that this money is (from your point 
of view) wasted.
Since this would be a very welcome patch to FFmpeg, please ask Michael 
or Kamil Nowosad. Note that the decoder should be fixed at the same time.

> > 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.

This seems unlikely to me but I am definitely no j2k expert.

> 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)
                                   ^^^^^^^^

There is some contradiction in your writing...

> 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.

That seems useless for archiving.

> > 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.

Of course.
Sorry if you believe that this is not sufficiently documented, this 
is one of the very indirect (but still bad) consequences of the fork.

> 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?

(Did you already guess why Carbon Coder produces the same output as ffplay?)

Could you please send the Carbon Coder EULA either to this mailing list or 
to me personally? This would be *very* welcome!

Thank you, Carl Eugen