[FFmpeg-devel] Google Summer of Code participation

Michael Niedermayer michaelni
Mon Mar 30 03:04:16 CEST 2009

On Mon, Mar 30, 2009 at 12:33:01AM +0200, Thilo Borgmann wrote:
> Vitor Sessak schrieb:
>> Thilo Borgmann wrote:
>>> 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 
>>> 'outside'.
>>> 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);
>>> #endif
>>>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> (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?
>> There are three possibilities:
>> 1- This information is coded somewhere in the AVI format (and thus it is 
>> the work of the AVI demuxer to read it and set the parameters).
>> 2- This information is in some reserved bits of the PNG stream (and so it 
>> is in pngdec.c that it should be read).
>> 3- This information is nowhere and the codec follow some stupid convention 
>> like one frame every X are key-frames.
>> I suggest you to look in the available documentation/source code to know 
>> where this information is supposed to be. I find (1) unlikely since ffmpeg 
>> AVI demuxer is not so buggy, and it would set picture->key_frame 
>> correctly...
> Found something here. I think, the avi dumexer does its job and reads the 
> keyframe flags. I tested this by logging the PKT_FLAG_KEY or'ed into the 
> 'flags' attribute of the 'AVPacket' structure (libavcodec/avidec.c: 
> avi_read_packet)
> This detected a keyframe at the 1st, 7th, 8th, 21st and 22nd frames of the 
> stream, which makes sense as far as I can tell.
> Ok, but unfortunately, the AVPacket structure is not passed completely to 
> the decoder (libavcodec/pngdec.c: decode_frame()), just the attributes 
> 'data' and 'size'. (attribute 'flags' hold the keyframe information, as I 
> said above). These attributes are passed at the top level - ffplay.c: 
> video_thread().
> Next to this, an 'AVCodecContext' is passed to the decoder function. I've 
> already tried to get the keyframe information out of them but they declare 
> al frames to be keyframes. (see above for that)
> As far as I understand the code now, this AVCodecContext is created once 
> for each stream and therefore can not carry the information per frame. 
> (This ist right, isn't it?)

> Well, the keyframe flag is not coded in the PNG buffer either. So I do not 
> see a chance to get the keyframe flag from the packages read by the demuxer 
> into the decoder function. At least, not without changes at top level, 
> which means at ffplay.c which is not an option in my eyes.
> So, I wonder how other codecs get told about a keyframe they have to 
> decode...

other codecs store the keyframe info in the frames passed to the decoder.
btw, where is the source for corepng? i mean not a win32 self extracting

> As you mentioned, the demuxer detects the keyframes but the 
> picture->key_frame is not set. I checked this by my first attempt in 
> reading ist value (was always set to 'keyframe') and by looking into the 
> avidec.c (which is the avi demuxer, or am I completely wrong about that?), 
> where the key_frame attribute is never touched.
> Though, what would be the preferred way to carry this information from the 
> package-struct to the decoder function? (I hope I just missed a clue 
> somewhere but I looked through the code the whole day...)

If it really is not stored in the frames there are only 3 ways

1. change every muxer and demuxer that allows corepng to add&remove a
byte specifying the keyframe and fix pngdec/enc to handle that byte
2. add a avcodec_decode_video2() that takes a AVPacket and update
ffmpeg.c and ffplay.c (this was planned since a long time and is welcome)
3. try I & P and compare which is closer to the previous frame
this if course is not 100% but easy

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090330/5363f0ee/attachment.pgp>

More information about the ffmpeg-devel mailing list