[FFmpeg-devel] Issues with ljpeg
Wed Aug 27 18:07:09 CEST 2008
On Wed, Aug 27, 2008 at 04:29:27PM +0200, Mathieu Malaterre wrote:
> 2008/8/16 Michael Niedermayer <michaelni at gmx.at>:
> > we need a patch that when applied fixes the bug and the regression tests.
> > have you tested the RGB32 code? if not please do, i think it is buggy as well
> > and iam not going to apply a patch that fixes one function while one above
> > is left with the identical bug.
> > hint: the &0x1FF
> Sorry but I do not understand how I am supposed to access this part of
> code. There is not a single line of comment in this file. Is this
> where 32bits image get compressed ?
Exactly 48 lines above the code you changed. The only place in that file
where "RGB32" appears ;-)
> That does not even make sense,
> since I would just discard the alpha component and reuse the other
You can not use the code for YUV for RGB, those are different formats
(though it does do a "pseudo YUV -> RGB"). And alpha is discarded
> I tried anyway with a 32bits RGB png I had on disk:
> $ ./ffmpeg -f image2 -i fran_cut.png -f image2 -pred 6 -vcodec ljpeg
> Input #0, image2, from 'fran_cut.png':
> Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
> Stream #0.0: Video: png, rgb32, 256x256, 25.00 tb(r)
> Output #0, image2, to '/tmp/out6.ljpeg':
> Stream #0.0: Video: ljpeg, rgb32, 256x256, q=2-31, 200 kb/s, 25.00 tb(c)
> Stream mapping:
> Stream #0.0 -> #0.0
> [ljpeg @ 0xe2e5f0]colorspace not supported in jpeg
> Error while opening codec for output stream #0.0 - maybe incorrect
> parameters such as bit_rate, rate, width or height
Yay, so nobody _ever_ tested this?! Great.
In mpegvideo_enc.c line 263 you can comment out the "return -1;" but I
do not know what exactly will happen then.
More information about the ffmpeg-devel