[FFmpeg-devel] [PATCH] lavf/mov: fix hang while seek on a kind of fragmented mp4.

[C.H.Liu]

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 <cus at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>