[Bug 692832] New: [avidemux] long preroll time after seek for avi file

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Tue Jan 29 12:36:14 PST 2013


https://bugzilla.gnome.org/show_bug.cgi?id=692832
  GStreamer | gst-plugins-good | 1.x

           Summary: [avidemux] long preroll time after seek for avi file
    Classification: Platform
           Product: GStreamer
           Version: 1.x
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: rawoul at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


The following file takes a long time to seek, the video is frozen until audio
catches up:

playback-test 0 http://10.126.6.15/hd/avi/S21E02.La.Reponse.De.Bart.FR.avi

For example a seek at time 100000ms with FLUSH and KEYFRAME flags will find:

 - video keyframe at index 2484, ts=0:01:39.360000000
 - audio keyframe at index 10, ts=0:01:31.922666666

The audio buffers are 10sec long, that's why the difference is so big. The
newsegment output on audio and video pads has a start time of
0:01:31.922666666, and the first video frame has a start time of
0:01:39.360000000, so the video freezes for 7.5sec while audio is played after
the seek.

IMO the segment start is wrong, it should be 0:01:39.360000000. The audio
packets would be dropped very quickly by the renderer since they would be out
of segment, and playback would start in sync much quicker.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list