[FFmpeg-devel] [PATCH] stop av_find_stream_info per packet dts
Sun Mar 15 07:39:26 CET 2009
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:
>>>> 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.
>>>> 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 (st->time_base.den > 0 && av_rescale_q(codec_info_duration[st->index], st->time_base, AV_TIME_BASE_Q) >= ic->max_analyze_duration)
> 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.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer http://www.ffmpeg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1065 bytes
Desc: not available
More information about the ffmpeg-devel