[FFmpeg-devel] [PATCH] Add DPX decoder rev-18
Thu Jun 4 07:59:04 CEST 2009
On 2009-06-04 00:34, Michael Niedermayer wrote:
> On Wed, Jun 03, 2009 at 08:52:42PM +0200, Jimmy Christensen wrote:
>> On 2009-06-03 20:20, Reimar D?ffinger wrote:
>>> Hm. I really wonder which compiler you use.
>>> Anyway I guess Michael would accept a version using macros if it was
>>> done without adding useless calculation.
>>> Except that it's rather silly to use macros in cases like this when
>>> there is absolutely no reason to.
>>> static inline unsigned make_16bit(unsigned value)
>>> // mask away invalid bits
>>> value&= 0xFFC0;
>>> // correctly expand to 16 bits
>>> return value + (value>> 10);
>>> *dst++ = make_16bit(rgbBuffer>> 16);
>>> *dst++ = make_16bit(rgbBuffer>> 6);
>>> *dst++ = make_16bit(rgbBuffer<< 4);
>> Thanks for the code. Works perfectly and keeps it's speed. I'm using gcc
>> 4.3.3 on Ubuntu 9.04 amd64. C is not exactly my biggest force and
>> appreciate any help I can get.
>> Btw. should I also upload sample images to test with?
> hmm, dont we already have pngs somewhere ...
> anyway, uploading more surely doesnt hurt ...
pngs? This is a decoder for dpx files :) Have uploaded some samples to
the samples.mplayerhq.hu ftp. Both 10bit and 16bit samples.
>> +static int decode_frame(AVCodecContext *avctx,
>> + void *data,
>> + int *data_size,
>> + AVPacket *avpkt)
>> + const uint8_t *headerBuffer = avpkt->data;
>> + const uint8_t *buf = avpkt->data;
It was to make jumping from the start of the file to the offset easier.
Found another way to do it instead.
>> + avctx->width = w;
>> + avctx->height = h;
>> + if (w != avctx->width || h != avctx->height)
>> + avcodec_set_dimensions(avctx, w, h);
> this wont work in that order
Removed those 2 lines, as they did seem kinda rendundant aswell.
Added support for 16-bit dpx files aswell. I know the code looks
redundant, but I didn't want to make a if or switch case for each pixel.
With the switch case inside the for loops it took a performance hit of
about 6-7% of total encode time which I found a little unacceptable.
Also the 10bit files needs to first go into a temporary buffer for the
color information to get extracted. With 16-bit files it's not necessary
so that path should also be a little faster. Haven't tested encodes with
16-bit sequences, only single files.
Removed the version variable since it wasn't used anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8959 bytes
Desc: not available
More information about the ffmpeg-devel