[FFmpeg-devel] [RFC][PATCH] return packets for known codecs earlier when codec probing is done

Baptiste Coudurier baptiste.coudurier
Mon May 25 22:50:19 CEST 2009


On 5/25/2009 1:10 PM, Baptiste Coudurier wrote:
> On 5/25/2009 7:08 AM, Michael Niedermayer wrote:
>> On Sun, May 24, 2009 at 03:03:33PM -0700, Baptiste Coudurier wrote:
>>> On 5/23/2009 5:58 PM, Baptiste Coudurier wrote:
>>>> On 5/23/2009 5:49 PM, Michael Niedermayer wrote:
>>>>> On Sat, May 23, 2009 at 03:56:11PM -0700, Baptiste Coudurier wrote:
>>>>>> Hi,
>>>>>>
>>>>>> $subject.
>>>>>>
>>>>>> I'd like comments on this. I don't really get why we wouldn't return
>>>>>> packets for known codecs. Why do we buffer them ?
>>>>> if we have packets in the buffer we must return them first, before the
>>>>> current packet even if the codec is known, adding the current packet
>>>>> to the buffer is needed as we return an earlier packet first. And cant
>>>>> return 2 at once.
>>>>> But maybe you meant something else?
>>>> Ok.
>>>>
>>>>>> Problem is that packets for known codecs get buffered but never returned
>>>>>> until codec is sucessfully probed for the unkwnown stream, which might
>>>>>> not even happen.
>>>>> That sounds like a seperat issue, 
>>>>> There could be a size limit at which we turn PROBE in NONE and return
>>>>> stuff ...
>>>> Yes, that's what's needed.
>>> What about this ?
>>>
>>> flush_packet_queue needs to flush raw_packet_buffer too.
>>>
>>> Do you have samples that need probing I could test against ?
>> i certainly do but i dont think i would find them, some MPEG files ...
>>
>>
>>> [...]
>>>  
>>>  int av_read_packet(AVFormatContext *s, AVPacket *pkt)
>>>  {
>>> -    int ret;
>>> +    int ret, i, read_size = 0;
>>>      AVStream *st;
>>>  
>>>      for(;;){
>> i think the read_size variable will in some form have to be put in AVStream
> 
> Maybe in the future.
> 
>>> @@ -537,10 +537,18 @@ int av_read_packet(AVFormatContext *s, AVPacket *p
>>>  
>>>          av_init_packet(pkt);
>>>          ret= s->iformat->read_packet(s, pkt);
>>> -        if (ret < 0)
>>> -            return ret;
>>> +        if (ret < 0) {
>>> +            if (!pktl)
>>> +                return ret;
>>> +            for (i = 0; i < s->nb_streams; i++)
>>> +                if (s->streams[i]->codec->codec_id == CODEC_ID_PROBE)
>>> +                    s->streams[i]->codec->codec_id = CODEC_ID_NONE;
>>> +            continue;
>>> +        }
>> i dont like this
> 
> What do you propose ? Code needs to return packets buffered when error
> is encoutered. Changed approched.
> 
>>>          st= s->streams[pkt->stream_index];
>>>  
>>> +        read_size += pkt->size;
>>> +
>> I think read_size++ is more robust in light of streams of widely
>> varriing bitrate 10mbit video vs. a few kbit speech codec
> 
> Ok.
> 
>> [...]
>>
>> while(s->raw_packet_buffer){
>>     pktl = s->raw_packet_buffer;
>>     s->raw_packet_buffer = pktl->next;
>>     av_free_packet(&pktl->pkt);
>>     av_free(pktl);
>> }
> 
> Ok.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Index: libavformat/utils.c
> ===================================================================
> --- libavformat/utils.c	(revision 18912)
> +++ libavformat/utils.c	(working copy)
> [...]
>
> @@ -537,10 +538,15 @@
>  
>          av_init_packet(pkt);
>          ret= s->iformat->read_packet(s, pkt);
> -        if (ret < 0)
> -            return ret;
> +        if (ret < 0) {
> +            if (!pktl)
> +                return ret;
> +            continue;
> +        }
>          st= s->streams[pkt->stream_index];
>  
> +        st->probe_packets++;
> +

This would be better moved under:

@@ -561,6 +566,8 @@
         if(st->codec->codec_id == CODEC_ID_PROBE){
             AVProbeData *pd = &st->probe_data;

+            st->probe_packets++;
+
             pd->buf = av_realloc(pd->buf,
pd->buf_size+pkt->size+AVPROBE_PADDING_SIZE);


-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-devel mailing list