[Bug 797262] MP4(H.264+MP3) file can't be seeked anymore since 1.5.x

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797262

--- Comment #19 from Ricky Gong <rickyqiqi at hotmail.com> ---
OK. After several ten hours of check on the master branch, I finnally on the
way to do some help work. I found that 850e678813f11b439994d434f2800bfbbb140864
commit (the second commit just after 1.14.0 tag) in gst-plugins-good solved the
seeking problem:

Author: Sebastian Dröge <sebastian at centricular.com>  2018-03-05 18:48:15
Committer: Sebastian Dröge <sebastian at centricular.com>  2018-03-20 18:08:28
Tags: 6
Parent: ed2ccb1a60f6756b5c59df40460dc2dd0b7f7f37 (rtp: Fix compilation with
non-C99 compilers)
Child:  589019d8f5072d4470ea2ed76cfffa75f45e9426 (udpsrc: optimize GstUdpSrc
object for cache performance)
Branch: remotes/origin/master
Follows: 7
Precedes: 5

    qtdemux: Fix seeking on streams with frame reordering

    The samples table is sorted by DTS, not PTS. As such we can only get the
    correct result when using a binary search on it, if we search for the
    DTS.
    Also if we only ever search for the frame, where the following frame is
    the first one with a PTS after the search position, we will generally
    stop searching too early if frames are reordered.

    In forwards playback this is not really a problem (after the decoder
    reordered the frames, clipping is happening), in reverse playback
    it means that we can output one or more frames too few as we stop too
    early and the decoder would never receive it.

    https://bugzilla.gnome.org/show_bug.cgi?id=782118

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.