[FFmpeg-devel] [PATCH] stop av_find_stream_info per packet dts

[Baptiste Coudurier]

Michael Niedermayer wrote:
> On Sat, Mar 14, 2009 at 11:39:26PM -0700, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>> On Sat, Mar 14, 2009 at 08:50:25PM -0700, Baptiste Coudurier wrote:
>>>> Michael Niedermayer wrote:
>>>>> On Sat, Mar 14, 2009 at 08:25:25PM -0700, Baptiste Coudurier wrote:
>>>>>> Hi
>>>>>>
>>>>>> It seems stopping av_find_stream_info by packet duration causes a
>>>>>> problem when a packet with long duration (still image, sub) is very long.
>>>>>>
>>>>>> Scenario:
>>>>>> 1 video stream containing a single image with very long duration
>>>>>> 1 video stream cfr.
>>>>>>
>>>>>> Demuxing will happen in this order since dts are in this order.
>>>>>>
>>>>>> av_find_stream_info will stop after the single image, while the next
>>>>>> packet dts will still be < max analyze duration.
>>>>>>
>>>>>> I'd like your opinion on this I don't know if this might have side effects.
>>>>> i think the idea is good but dts might not start at 0 (cut mpeg-ps/ts being
>>>>> an example)
>>>>> also before you write a patch that sums dts differences, this can break
>>>>> with timestamp discontinuities.
>>>>> maybe something like using the previous sum of durations for each stream
>>>>> instead of the latest?
>>>>>
>>>> Like this ?
>>>>
>>> [...]
>>>
>>> no i meant to move the codec_info_duration check before the change that is
>>>
>>> if(codec_info_nb_frames[st->index]>1){
>>>     if (st->time_base.den > 0 && av_rescale_q(codec_info_duration[st->index], st->time_base, AV_TIME_BASE_Q) >= ic->max_analyze_duration)
>>>         break;
>>>     codec_info_duration[st->index] += pkt->duration;
>>> }
>>>
>>> a possible problem with your suggestion is that it might never reach
>>> the break if some stream simply doesnt contain any (more) packets
>>>
>> Right, I understand now.
>>
>> Patch attached.
> 
> looks ok
> 

Applied.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org