JyotsnaT / xuggle

Automatically exported from code.google.com/p/xuggle
0 stars 0 forks source link

Allow IStreamCoder to encode IVideoPictures with different IPixelTypes if they are laid out the same in memory #129

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
For 2.1 we made a change to check that the pixel format of a IVideoPicture
was the same as the one set on IStreamCoder.  This was a good fix to work
around JVM corruption issues where people passed in IVideoPicture objects
that were laid out in memory differently than IStream Coder expected.

However, it's too aggressive of a fix, as it means you can't pass in codec
types that are the same in memory.  We should investigate a more permissive
fix.

This was brought up by Stas on the mailing list.  The key text is here:

Hi.

Tried this, got additional error.
On:

picStreamCoder=IStreamCoder.make(Direction.ENCODING);

picStreamCoder.setFrameRate(IRational.make(1,1) );

                                picStreamCoder.setPixelType(Type.YUV420P);

                                picStreamCoder.setBitRate(256000);

picStreamCoder.setTimeBase(IRational.make(1,1));

                                picStreamCoder.setWidth(cam.getWidth());

                                picStreamCoder.setHeight(cam.getHeight());

                                ICodec codec
=ICodec.findEncodingCodecByName("mjpeg");

                                picStreamCoder.setCodec(codec);

                                picStreamCoder.open();

I get (quite expected)

ERROR org.ffmpeg - [mjpeg @ 0x55d3c520] colorspace not supported in jpeg

When trying to follow the setComplete() advice and do:

f.setComplete(true, IPixelFormat.Type.YUVJ420P, f.getWidth(),
f.getHeight(), f.getPts());

I get:

DEBUG com.xuggle.xuggler - error: pixel formats don't match
(../../../../../../../csrc/com/xuggle/xuggler/VideoPicture.cpp:298)

Original issue reported on code.google.com by art.cla...@gmail.com on 29 May 2009 at 2:20

GoogleCodeExporter commented 9 years ago

Original comment by art.cla...@gmail.com on 15 Jun 2009 at 7:45

GoogleCodeExporter commented 9 years ago

Original comment by art.cla...@gmail.com on 16 Jun 2009 at 1:53

GoogleCodeExporter commented 9 years ago
Hi Stas,

I don't think this is needed if issue #164 is implemented.  If 164 is 
implemented,
you can create a new IVideoPicture wrapping the IVideoPicture.getData() of the 
other
IVideoPicture, and then 'lie' about the pixel format.

So I'm going to say "not implementing" for now in favor of #164.  Let me know 
if you
disagree.

- Art

Original comment by art.cla...@gmail.com on 2 Jul 2009 at 7:35