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

Baptiste Coudurier baptiste.coudurier
Thu May 28 21:25:22 CEST 2009


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.

Patch attached.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: probe_pktl6.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090528/949a4dba/attachment.txt>



More information about the ffmpeg-devel mailing list