[FFmpeg-devel] [PATCH] libopenjpeg J2K encoder

[Michael Niedermayer]

Hi

On Thu, Nov 17, 2011 at 03:18:34PM -0700, Michael Bradshaw wrote:
> > Michael Bradshaw <mbradshaw <at> sorensonmedia.com> writes:
[...]
> 
> > > (though decoding YUV444P is tricky since it looks like RGB24)
> >
> > Are you describing a bug in our decoder, or a limitation of libopenjpeg (or of
> > the whole standard)?
> 
> I'm not sure, actually.  If, when decoding a picture, libopenjpeg
> properly sets the color_space variable in the opj_image struct, then
> it should be an easy fix in the decoder.  If libopenjpeg doesn't set
> that, it's either a problem on their side or a problem with the
> standard that prevents them from determining this.  I haven't looked
> into libopenjpeg's decoding process enough to tell, but from what I've
> seen FFmpeg's decoder has to guess at the pixel format.

The following text describes some ways to identify YCbCr vs RGB
www.jpeg.org/public/15444-2annexm.pdf

I havnt checked what real world jpeg2000 files and applications use



[...]
> @Michael Niedrmayer:
> Do you have a particular sample file, and could you tell me the output
> size and pixel format?

http://samples.multimedia.cx/benchmark/testsuite1/matrixbench_mpeg2.mpg


> What are the commands you're passing?  I've

./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -vcodec libopenjpeg test.avi
./ffmpeg_g -i ~/videos/matrixbench_mpeg2.mpg -vcodec libopenjpeg -vf scale=256:256 test.avi

also note that the crash didnt happen under valgrind


> done a little debugging and it looks like I'm not handling the frame's
> data properly.  When I tried to encode a video with output size of
> 300x800, the frame passed to the encode_frame function, I found the
> frame had a linesize[0] == 912, not the expected 900 (this was for
> RGB24, I haven't looked at the other formats).  Does FFmpeg pad the
> data?

the linesizes/ strides can be arbitrary, normally they are rounded up
at least enough to allow fast aligned SIMD accesses. But they can
be much larger or rarely even negative


[...]
> Attached is the revised patch.

Ill look at it in a moment, thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111117/5d5ff5c3/attachment.asc>