[FFmpeg-devel] Google Summer of Code participation
Thilo Borgmann
thilo.borgmann
Wed Apr 8 16:09:01 CEST 2009
Michael Niedermayer schrieb:
>>
>> This is patch "tb.changedTry_decode_frame.patch" then.
>>
>>
You're ok with that?
>>
>>
>> Michael Niedermayer schrieb:
>>
>>>> @@ -1586,9 +1586,9 @@ static int audio_decode_frame(VideoState *is,
>>>> double *pts_ptr)
>>>> /* NOTE: the audio packet can contain several frames */
>>>> while (is->audio_pkt_size > 0) {
>>>> data_size = sizeof(is->audio_buf1);
>>>> - len1 = avcodec_decode_audio2(dec,
>>>> + len1 = avcodec_decode_audio3(dec,
>>>> (int16_t *)is->audio_buf1,
>>>> &data_size,
>>>> - is->audio_pkt_data,
>>>> is->audio_pkt_size);
>>>> + pkt);
>>>> if (len1 < 0) {
>>>> /* if error, we skip the frame */
>>>> is->audio_pkt_size = 0;
>>>>
>>>>
>>> is that the same?
>>>
>>>
>>>
>> Fixed in revision 2.
>> The last two lines which are altered in ffplay.c (audio_decode_frame):
>> ::::
>> - is->audio_pkt_data = pkt->data;
>> - is->audio_pkt_size = pkt->size;
>> + avpkt.data = pkt->data;
>> + avpkt.size = pkt->size;
>> ::::
>> These may have become deprecated now, as the original
>> is->audio_pkt_{data,size} are not changed anymore. I may be wrong but I
>> think these two lines are for cleaning up. If I'm right, these can be
>> deleted now but I'm not 110% sure about that, may be you'll have a look.
>>
>
> your change to ffplay.c still looks wrong
>
Hm. I compiled it and it works. Forget about the last two lines to be
just for cleanup, I understand it right meanwhile...
I don't see anything wrong in there. The local AVPacket is a dummy
packet of which the .data and .size attributes are used as iterating
pointers through the real buffer during the while loop.
After that, if another packet is there to be decoded, this dummy is set
to the new packet data.
So, the 'original' pointer pkt can not be used instead as it has to keep
pointing to the begin of the buffer which is free'd after decoding. The
local AVPacket is just the new way to provide changeable pointers into
the buffer which replaces the use of is->data & is->size.
Thus, I can't see semantical failure nor unnecessary code... what do you
see there which is wrong?
> also maybe you could split the patch a little the changes to ffplay dont
> depend on changes to ffmpeg nor apiexample ...
>
>
Ok I've done although I thought each patch should correlate to one
logical entity which I would say that the API changes are... but I don't
mind.
>> diff --git a/libavcodec/api-example.c b/libavcodec/api-example.c
>> index 2a47fea..45eaa5b 100644
>> --- a/libavcodec/api-example.c
>> +++ b/libavcodec/api-example.c
>> @@ -115,10 +115,14 @@ static void audio_decode_example(const char *outfilename, const char *filename)
>> {
>> AVCodec *codec;
>> AVCodecContext *c= NULL;
>> - int out_size, size, len;
>> + int out_size, len;
>> FILE *f, *outfile;
>> uint8_t *outbuf;
>> - uint8_t inbuf[INBUF_SIZE + FF_INPUT_BUFFER_PADDING_SIZE], *inbuf_ptr;
>> + uint8_t inbuf[INBUF_SIZE + FF_INPUT_BUFFER_PADDING_SIZE];
>> + AVPacket avpkt;
>> +
>>
>
>
>> + /* initialize the packet */
>> + av_init_packet(&avpkt);
>>
>
> the comment is useless, it just repeats the name of the function
>
>
Ah yes. I thought about "filling the packet with initial values" but I
think which way soever the function is self-explanatory. Thus deleted
from the new renamed patch.
Ok, there are two new patches attached, one for the ffmpeg.c and one for
api-example.c. I'll provide the one for ffplay.c as soon as we've
reached a consensus on that file...
TB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tb.APICallsInAPIExample.patch
Type: text/x-patch
Size: 4556 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090408/0d051508/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tb.APICallsInFFmpeg.patch
Type: text/x-patch
Size: 4581 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090408/0d051508/attachment-0001.bin>
More information about the ffmpeg-devel
mailing list