I also think it would be better if we store pts-es in different lists for each track. However, it does NOT match the original design of data structures. Several boxes will be affected. So I am trying to commit this patch to discuss with maintainers.
At present, I prefer the last version patch(fall back to linear searching only if needed). I could research more later. Thanks and Regards, Charles Liu Marton Balint <c...@passwd.hu> 于2019年2月5日周二 上午4:42写道： > > > On Mon, 4 Feb 2019, Michael Niedermayer wrote: > > > On Sat, Feb 02, 2019 at 05:03:25PM +0100, Marton Balint wrote: > >> > >> > >> On Sat, 2 Feb 2019, Charles Liu wrote: > >> > >>> Binary searching would hang if the fragment items do NOT have > timestamp for the specified stream. > >>> > >>> For example, a fmp4 consists of separated 'moof' boxes for each track, > and separated 'sidx' for each segment, but no 'mfra' box. > >>> Then every fragment item only have the timestamp for one of its tracks. > >> > >> I don't see why you are changing the search to be linear. Is it > possible the > >> some of the stream fragmens have NOPTS_VALUE but other don't? In this > case > >> you should keep the binary search and only fall back to linear search if > >> binary search finds an AV_NOPTS_VALUE. See similar code in function > >> mxf_absolute_bodysid_offset of libavformat/mxfdec.c. > > > > The point of binary searching is to achieve O(log n) time > > if there is any linear search this is no longer achieved. > > So its not ideal to have any AV_NOPTS_VALUE in the array that is > > searched. It would be better if the unknown entries are not in the > > array that is used for the search or if their value is monotonized > > once for all searches > > that being ideal at least ... > > Yeah that is true, but that would require maintaining a different array > with pts-es, and getting/updating fragment pts-es are complicated as is. > > Considering that this fixes a hang, I'd rather see the last version of the > patch applied than wait for a more complicated, yet faster implementation. > > Regards, > Marton > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
