On 10/04/2017 03:50 AM, Michael Niedermayer wrote: > On Fri, Sep 29, 2017 at 08:54:08AM -0700, John Stebbins wrote: >> When keyframe intervals of dash segments are not perfectly aligned, >> fragments in the stream can overlap in time. Append new "trun" index >> entries to the end of the index instead of sorting by timestamp. >> Sorting by timestamp causes packets to be read out of decode order and >> results in decode errors. >> --- >> libavformat/mov.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/libavformat/mov.c b/libavformat/mov.c >> index 899690d920..c7422cd9ed 100644 >> --- a/libavformat/mov.c >> +++ b/libavformat/mov.c >> @@ -4340,8 +4340,8 @@ static int mov_read_trun(MOVContext *c, AVIOContext >> *pb, MOVAtom atom) >> MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES)); >> if (keyframe) >> distance = 0; >> - ctts_index = av_add_index_entry(st, offset, dts, sample_size, >> distance, >> - keyframe ? AVINDEX_KEYFRAME : 0); >> + ctts_index = add_index_entry(st, offset, dts, sample_size, distance, >> + keyframe ? AVINDEX_KEYFRAME : 0); > can this lead to timestamps being out of order not just changing > from strictly monotone to monotone ? > > Maybe iam missing somehing but out of order could/would cause problems > with av_index_search_timestamp() and possibly others > >
I'm not sure I understand the question. But I think I can answer. The new fragment can start before the last fragment ends. I'll make a concrete example. Lets say the new fragment's first DTS is 10 frames before the end of the previous fragment. So the first DTS of the new fragment is before the timestamp of 10 entries in the index from the previous fragment. av_add_index_entry searches the existing index and inserts the first sample of the new fragment in position nb_index_entries - 10 (and shifts the existing entries). The next 9 samples of the new fragment get intermixed with the remaining 9 samples of the previous fragment, sorted by DTS. When the samples are read out, you get samples from the last fragment and the new fragment interleaved together causing decoding errors. Using add_index_entry will result in the timestamps in the index going backwards by 10 frames at the fragment boundary in this example. In the other patch that accompanied this one, I've marked the samples from the new fragment that overlap previous samples with AVINDEX_DISCARD. ff_index_search_timestamp appears to be AVINDEX_DISCARD aware. So I think av_index_search_timestamp will do the right thing. -- John GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01 83F0 49F1 D7B2 60D4 D0F7
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
