[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