GNOME Bugzilla – Bug 616516
[qtdemux] h264 playback gets skippy after a seek
Last modified: 2010-05-11 09:09:40 UTC
Created attachment 159336 [details] 2s after start, do a seek +10s with our dvbvideosink, we can directly output h264 PES on the decoder chip. with release 0.10.25 of gstreamer (gst-plugins-good-0.10.15) playback of mp4 files was fine, also after seeking. now in recent 0.10.28 of gstreamer and gst-plugins-good-0.10.21, after a seek, video becomes stuttering. as if the decoder was missing every other frame or just played iframes from then. the problem is reproducable and i made some dumps of the bitstream. after the seek, i dump the bytes 0x464C555348 ("FLUSH") into the file. technically, the files should match (maybe plus/minus a couple of frames due to timer event jitter) but i couldn't find any matching PES headers from that point on. source file: http://kai3.tv/cc2/CC-Zwei-36-NRWTV.mp4 http://dreamboxupdate.com/videodump-01025.pes http://dreamboxupdate.com/videodump-01028.pes here's our sink: http://schwerkraft.elitedvb.net/scm/viewvc.php/dvbmediasink/src/gstdvbvideosink.c?revision=1.69&root=dvbmediasink&view=markup
update on the dump analysis: with the old version, PTS are monotonically increasing, like expected by a hardware decoder. with the new version, they are jumping back and forth
next update: problem introduced with qtdemux from release gst-plugins-base **0.10.18**
Created attachment 159343 [details] more useful testcase diff -u noseek.log seek.log: -ts 0:00:01.880000000 -ts 0:00:01.960000000 -ts 0:00:01.920000000 -ts 0:00:02.040000000 -ts 0:00:02.000000000 -ts 0:00:02.120000000 ts 0:00:02.080000000 +ts 0:00:02.120000000 ts 0:00:02.160000000 -ts 0:00:02.240000000 ts 0:00:02.200000000 -ts 0:00:02.320000000 +ts 0:00:02.240000000 ts 0:00:02.280000000 -ts 0:00:02.440000000 -ts 0:00:02.400000000 +ts 0:00:02.320000000 ts 0:00:02.360000000 -ts 0:00:02.560000000 -ts 0:00:02.520000000 +ts 0:00:02.400000000 +ts 0:00:02.440000000 ts 0:00:02.480000000 -ts 0:00:02.680000000 -ts 0:00:02.640000000 +ts 0:00:02.520000000 +ts 0:00:02.560000000 ts 0:00:02.600000000 -ts 0:00:02.800000000 -ts 0:00:02.760000000 +ts 0:00:02.640000000 +ts 0:00:02.680000000
(In reply to comment #3) > Created an attachment (id=159343) [details] > more useful testcase > > diff -u noseek.log seek.log: > -ts 0:00:02.120000000 > ts 0:00:02.080000000 > +ts 0:00:02.120000000 > ts 0:00:02.160000000 > -ts 0:00:02.240000000 > ts 0:00:02.200000000 > -ts 0:00:02.320000000 > +ts 0:00:02.240000000 > ts 0:00:02.280000000 > -ts 0:00:02.440000000 > -ts 0:00:02.400000000 > +ts 0:00:02.320000000 > ts 0:00:02.360000000 This looks like without seeking the timestamps are in coded order and after they're in display order.
Created attachment 160737 [details] [review] Fix partial parsing of ctts table There was indeed a discrepancy between timestamps with or without seek. In fact, without seeking timestamps would be PTS, and after a seek they could simply be DTS (so ascending). Attached patch makes things consistent, so timestamps will be PTS all the time (with or without seeking).
it seems to work perfectly for me now as the visual inspection of the output video is now studder-free after a seek. i'd have to proofread the bitstream to give a 100% acknowledgment though
commit e934f637b64eac1bcc73bec7338d36804273c3ef Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon May 10 18:33:03 2010 +0200 qtdemux: fix partial parsing of ctts table Fixes #616516.