[FFmpeg-devel] Google Summer of Code participation

[Michael Niedermayer]

On Wed, Apr 08, 2009 at 01:10:09AM +0200, Thilo Borgmann wrote:
>
>
> Michael Niedermayer schrieb:
>> On Tue, Apr 07, 2009 at 11:32:36PM +0200, Thilo Borgmann wrote:
>>   
>>> Ronald S. Bultje schrieb:
>>>     
>>>>         
>>>>> But I think it would make sense to create a new function
>>>>> "try_decode_frame2()" in the same way as for avcodec_decode_video() 
>>>>> because
>>>>> it is parameterized with a pointer to the buffer and an int for the 
>>>>> size,
>>>>> but it should be called using an AVPacket struct instead. What do you 
>>>>> think?
>>>>>             
>>>> Michael may be better at answering here, but it's static to utils.c,
>>>> so no need for a new function, just change the prototype and update
>>>> the callers accordingly.
>>>>
>>>>
>>>>         
>>> Ok, I got the api-example.c, ffplay.c and ffmpeg.c redone for revision 1 
>>> of the api changes patch.
>>> As it is static seems to be a good reason not go the long way, ok.
>>>
>>> Revision 1 attached.
>>>     
>>
>> [...]
>>   
>>> @@ -1184,29 +1183,32 @@ static int output_packet(AVInputStream *ist, int 
>>> ist_index,
>>>      static short *samples= NULL;
>>>      AVSubtitle subtitle, *subtitle_to_free;
>>>      int got_subtitle;
>>> +    AVPacket avpkt;
>>> +
>>> +    av_init_packet(&avpkt);
[...]
>>> +        avpkt.data = NULL;
>>> +        avpkt.size = 0;
>>>          goto handle_eof;
>>>     
>>
>> what values do data & size have prior to these assignments?
>>   
> Undefined. Since they might be used for calls to the decoder funtions from 
> within the following switch, they need to be well defined - just like their 
> predecessors ptr and len.
> Is there something I don't understand?

no, sorry, i thought  av_init_packet() did set them but it doesnt

[...]
>>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>>> index 54c9202..1b89552 100644
>>> --- a/libavformat/utils.c
>>> +++ b/libavformat/utils.c
>>> @@ -1847,6 +1847,11 @@ static int try_decode_frame(AVStream *st, const 
>>> uint8_t *data, int size)
>>>      AVCodec *codec;
>>>      int got_picture, data_size, ret=0;
>>>      AVFrame picture;
>>> +    AVPacket avpkt;
>>> +
>>> +    av_init_packet(&avpkt);
>>> +    avpkt.data = data;
>>> +    avpkt.size = size;
>>>     if(!st->codec->codec){
>>>      codec = avcodec_find_decoder(st->codec->codec_id);
>>> @@ -1860,16 +1865,16 @@ static int try_decode_frame(AVStream *st, const 
>>> uint8_t *data, int size)
>>>    if(!has_codec_parameters(st->codec)){
>>>      switch(st->codec->codec_type) {
>>>      case CODEC_TYPE_VIDEO:
>>> -        ret = avcodec_decode_video(st->codec, &picture,
>>> -                                   &got_picture, data, size);
>>> +        ret = avcodec_decode_video2(st->codec, &picture,
>>> +                                   &got_picture, &avpkt);
>>>          break;
>>>      case CODEC_TYPE_AUDIO:
>>> -        data_size = FFMAX(size, AVCODEC_MAX_AUDIO_FRAME_SIZE);
>>> +        data_size = FFMAX(avpkt.size, AVCODEC_MAX_AUDIO_FRAME_SIZE);
>>>          samples = av_malloc(data_size);
>>>          if (!samples)
>>>              goto fail;
>>> -        ret = avcodec_decode_audio2(st->codec, samples,
>>> -                                    &data_size, data, size);
>>> +        ret = avcodec_decode_audio3(st->codec, samples,
>>> +                                    &data_size, &avpkt);
>>>          av_free(samples);
>>>          break;
>>>      default:
>>>     
>>
>> a mess
>>
>>   
> ... what I already did here and you obviously don't like it,  in which way 
> would you think this should be done? Or maybe, I don't get your thoughts 
> right... please tell me.

you have a AVPacket extract data & size pass that to a function and then
build a new AVPacket, this seems messy

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- 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/20090408/d00edb26/attachment.pgp>