GNOME Bugzilla – Bug 692832
[avidemux] long preroll time after seek for avi file
Last modified: 2018-05-04 13:18:30 UTC
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.
Sorry here is the right URL to the file: http://absolut.zogzog.org/share/samples/avi/S21E02.La.Reponse.De.Bart.FR.avi
> 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. I agree, the segment start should snap to the video keyframe, and the audio decoder or sink should discard all buffers before that, with both video and audio starting at 01:39.xx
Preroll time seems fine with Totem on GStreamer 1.14.0