GNOME Bugzilla – Bug 701141
tsdemux: multiple patches related to seeking
Last modified: 2013-07-15 09:22:59 UTC
While implementing push mode seeking in tsdemux, I've also added found some other issues that I've tried to fix. The patches can be found here: https://github.com/rawoul/gst-plugins-bad/commits/tsdemux tsdemux: fixes seeking in pull mode Cherry-picked from bug #698050 tsdemux: move some debug prints at the log level Cosmetic patch to make log output readable at the debug level tsdemux: fix M2TS stream resync Sync byte scan after a lost sync could result in an infinite loop for m2ts files, can be reproduced by seeking in an M2TS file (you can try with http://absolut.zogzog.org/share/samples/ts/hd_dolby_digital_plus_lossless.m2ts) tsdemux: recalculate new segment after byte seek The seeking start time is approximated from the seek offset in bytes using the accumulated PCR observations, so on a VBR stream there might be a big difference between the actual PCR and the estimated one after the seek. This might result in a long wait to skip all out of segments packets. Instead we just recalculate the new segment to start at the first PTS after the seek, so that playback starts immediatly. tsdemux: implement seeking in push mode Pretty straightforward, we just need to avoid flushing observations while seeking. I'm not sure the seek event is generated properly, please review. Works fine with playback-test.
I only pushed the following for now since they were obvious/trivial. The following ones need a bit more review. commit a5402d6eeb42e1b3f7ae986340ff6f3753dd69b4 Author: Arnaud Vrac <avrac@freebox.fr> Date: Mon May 27 22:22:32 2013 +0200 tsdemux: fix M2TS stream resync Sync byte scan is incorrect for M2TS streams because the timestamp 4 bytes were not included in the flush size. This can result in an infinite loop. Rework the scan code to be clearer and work in all cases. commit 065d421d34908eedabfe0690d77436e1dd9aa046 Author: Arnaud Vrac <avrac@freebox.fr> Date: Fri May 24 10:59:55 2013 +0200 tsdemux: move some debug prints at the log level
(In reply to comment #0) > tsdemux: recalculate new segment after byte seek > The seeking start time is approximated from the seek offset in bytes using > the accumulated PCR observations, so on a VBR stream there might be a big > difference between the actual PCR and the estimated one after the seek. This > might result in a long wait to skip all out of segments packets. Instead we > just recalculate the new segment to start at the first PTS after the seek, so > that playback starts immediatly. This sounds acceptable, but only if GST_SEEK_FLAG_ACCURATE is not used. And we should (in a separate/later commit) improve the PCR<=>offset code in mpegtspacketizer (by storing/taking-in-account more PCR/offset observations) so this difference is limited to a minimum.
Last two commits pushed. Thanks ! commit 024aa47f644dc141bcf9318a283aa4a3c6b0a7d0 Author: Arnaud Vrac <avrac@freebox.fr> Date: Fri May 24 18:18:35 2013 +0200 tsdemux: implement seeking in push mode commit 388c28381f0d5712bb50982a0ff85e83582d43f6 Author: Arnaud Vrac <avrac@freebox.fr> Date: Tue May 28 16:14:42 2013 +0200 tsdemux: recalculate new segment after byte seek The seeking start time is approximated from the seek offset in bytes using the accumulated PCR observations, so on a VBR stream there might be a big difference between the actual PCR and the estimated one after the seek. This might result in a long wait to skip all out of segments packets. Instead we just recalculate the new segment to start at the first PTS after the seek, so that playback starts immediatly.