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

Baptiste Coudurier baptiste.coudurier
Sun May 31 01:22:05 CEST 2009


On 5/28/2009 12:25 PM, Baptiste Coudurier wrote:
> Hi Michael,
> 
> On 5/28/2009 4:01 AM, Michael Niedermayer wrote:
>> On Wed, May 27, 2009 at 06:12:37PM -0700, Baptiste Coudurier wrote:
>>> On 5/27/2009 5:48 PM, Michael Niedermayer wrote:
>>>> On Wed, May 27, 2009 at 05:47:22PM -0700, Baptiste Coudurier wrote:
>>>>> On 5/27/2009 5:10 PM, Michael Niedermayer wrote:
>>>>>> On Wed, May 27, 2009 at 04:40:49PM -0700, Baptiste Coudurier wrote:
>>>>>>> On 5/27/2009 3:00 PM, Michael Niedermayer wrote:
>>>>>>>> On Wed, May 27, 2009 at 12:54:27AM -0700, Baptiste Coudurier wrote:
>>>>>>>>> Hi Michael,
>>>>>>>>>
>>>>>>>>> Michael Niedermayer wrote:
>>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>>> @@ -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
>>>>>>>>>>
>>>>>>>>> Well, we have a problem if probe_packets is not 0 when eof is reached.
>>>>>>>>> Do you see another way to avoid this ?
>>>>>>>> is this special case really relevant?
>>>>>>>> it just looses data on streams when all of the following is true
>>>>>>>> * stream is set to CODEC_ID_PROBE
>>>>>>>> * stream contains less than 100 packets in the whole file
>>>>>>>> * probing fails even with all packets in the whole file
>>>>>>> I think it is:
>>>>>>> code will call av_read_packet until st->probe_packets is 0, which will
>>>>>>> provoke an infinite loop.
>>>>>> hmm, i must be missing something, as i thought the packets would just never
>>>>>> be output and the player would end at EOF in whichever way it did before the
>>>>>> patch
>>>>> Before the patch, ie currently, if EOF is reach, packets are not outputed.
>>>>> This is a bug IMHO.
>>>> i agree its a bug, the patch without the controversal part would reduce it
>>>> to the case where less than 100 packets are in a whole file && probing
>>>> fails.
>>>> Your suggested fix, fixes it but introduces a new bug, namely that seeking
>>>> to EOF causes probing to fail for all streams permanently, even if the
>>>> user seeked back afterwards. 
>>> Well, probing should be executed by av_find_stream_info basically, and
>>> seeking should not occur during this process.
>> thats the ideal world case, yes but with mpeg-ts streams can start later
>> if iam not mistaken (like 2 movies which each happen to use different 
>> codecs or have subtitles in more or less languages)
> 
> Ok, thanks for clarifying.
> 
>>> But I don't really get what you mean by seeking to EOF and probing.
>>> Why would an user seek to EOF ?
>> because he clicked the wrong button ;)
>> users are silly, but ffmpeg should still not misbehave, especially not in
>> such a obscure way, i mean a mistaken seek to EOF shortly after a transition
>> between 2movies could lead to missing audio, maybe its a 1 in 100000 chance
>> or even less likely but its a bug from the users point of view
> 
> Ok, let's try to handle this the correct way.
> If the user seeks to EOF and a new stream (pid) was detected, codec will
> either be set to the right codec according to the pmt or if unknown
> codec probing will be called. If EOF is reached we must output packets
> buffered but it's not reasonable to set codecs to CODEC_ID_PROBE.
> 
> So during seek, probe packets should be reset to MAX_PROBE_PACKETS, and
> eof must set probe_packets to 0.
> 

How is it ? :)

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



More information about the ffmpeg-devel mailing list