[FFmpeg-devel] Google Summer of Code participation

Thilo Borgmann thilo.borgmann
Sat Mar 28 17:51:53 CET 2009

Kostya schrieb:
> On Sat, Mar 28, 2009 at 12:20:32PM +0100, Thilo Borgmann wrote:
> [...]
>> no. 12: "16-bit Interplay Video Decoder"
>> Sounds interesting and as there is a working 8-bit decoder, wich throws 
>> some errors if operating on the 16-bit demo file, there seems to be a 
>> good starting point. Unfortunately, the section about 16-bit opcodes is 
>> far from useful, if opcodes would have to be changed, this task becomes 
>> very difficult...
>> http://wiki.multimedia.cx/index.php?title=Interplay_Video
>> -> The suggestion in the wiki is to ask the development community (you!) 
>> about a good start-off with that problem. So I do: Anyone who can help 
>> on this? Anyone with more information about the 16-bit mode?
>> (Already inspected the code here... sounds like altering the #define'd 
>> functions but how to know if it is 8-bit palette mode or 16-bit 
>> whatsoever mode?)
> I suppose, it's only Google who knows more about this format.
> Maybe some container parameters should give demuxer a hint on whether this
> is 16-bit mode or not.
>> no. 23: "CorePNG Decoder"
>> Well, the descriptions sound quite easy, BUT the current svn version of 
>> ffmpeg (as well as my very old one) say that it "could not find codec 
>> parameters". Thus, I suppose there is no existing PNG1 decoder wich 
>> decodes RGB I-Frame video? Is there a PNG1 coded RGB I-Frame demo video? 
>> So this task seems to me like implementing a whole decoder on top of the 
>> png image decoder?
>> http://samples.mplayerhq.hu/V-codecs/PNG1/
>> -> Seems to be a not that difficult task but to have a complex start-off.
>> Anyone has an idea about these?
> I've looked at it once. If you use PNG decoder for that frames you'll see
> good picture for the first frame and many colourful dots on the latter. That's
> because its developer(s) decided to store latter frames as a difference to
> the key frame and you have to use demuxer keyframe flag to distinguish between
> both.
> Download http://samples.mplayerhq.hu/V-codecs/PNG1/corepng.avi
> run
> ffmpeg -i corepng.avi -f image2 -vcodec copy %04d.png
> and see that for yourself.
> P.S. We of FFmpeg welcome creativity since it's not that rare when the only
> information about codec is located in libavcodec/*.c

Ok next problem arises. I'm currently trying to distinguish the I and P 
frames to be decoded.
As you mentioned, I tried to check the keyframe flag, that comes from 
For that, I "av_log"ed the "key_frame" and "pict_type" attributes:

static int decode_frame(AVCodecContext *avctx,
                        void *data, int *data_size,
                        const uint8_t *buf, int buf_size)
    PNGDecContext * const s = avctx->priv_data;
    AVFrame *picture = data;
    AVFrame * const p= &s->picture;
#ifdef DEBUG
av_log(avctx, AV_LOG_DEBUG, "data->key_frame: %i, data->pict_type: %d\n",
       picture->key_frame, picture->pict_type);
av_log(avctx, AV_LOG_DEBUG, "s->picture->key_frame: %i, 
s->picture->pict_type: %d\n",
       p->key_frame, p->pict_type);
(source listing is highly mailing list dependent - tell me how you like 
it if this is a pain in your eyes)

As these debug outputs are telling that every frame is a key frame, 
which most of them are not, the question is if I'm looking at the wrong 
attributes or if this information is not parsed at all?
I'm asking that question because you seem to know how to distinguish 
these frames, if not, I'll have to trace the assignment of these 
attributes before the decode_frame function is called.
(Which I've already tried but the jungle of files out there didn't want 
me to find it quickly...)


More information about the ffmpeg-devel mailing list