After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 733490 - tsdemux: H264 seeking broken in push mode
tsdemux: H264 seeking broken in push mode
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
Other Linux
: Normal blocker
: 1.4.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2014-07-21 11:02 UTC by Arnaud Vrac
Modified: 2014-07-22 13:57 UTC
See Also:
GNOME target: ---
GNOME version: ---

Fixes the first issue (1.20 KB, patch)
2014-07-21 16:24 UTC, Mathieu Duponchelle
accepted-commit_now Details | Review
Fixes the second issue (975 bytes, patch)
2014-07-21 16:24 UTC, Mathieu Duponchelle
reviewed Details | Review

Description Arnaud Vrac 2014-07-21 11:02:56 UTC
The patch in Bug #675132 breaks seeking in push mode in files with H264 video. Here is a log of what happens:

stm0: seek to 959864ms from start
tsdemux: <tsdemux0> stream PTS 0:18:02.349048482 DTS 0:18:02.229048482
tsdemux: Moving data forward by 19 bytes (packet_size:37899, have:184)
tsdemux: query seeking
basesrc: <source> query seeking returns 0
tsdemux: <tsdemux0:audio_0045> stream:0x74f25cd8, pid:0x0045 stream_type:15 state:2
tsdemux: <tsdemux0:audio_0045> stream->pts 0:18:01.469048482
tsdemux: <tsdemux0:audio_0045> Pushing buffer with PTS: 0:18:01.469048482 , DTS: 99:99:99.999999999
tsdemux: <tsdemux0:audio_0045> Returned ok
tsdemux: <tsdemux0:video_0044> Got event seek
mpegtsbase: seek event, rate: 1.000000 start: 0:15:59.864000000 stop: 99:99:99.999999999
mpegtsbase: <tsdemux0> sending flush start
basesrc: <source> handle event flush-start event: 0x80932d0, time 99:99:99.999999999, seq-num 881, (NULL)
basesrc: <source> flushing 1, live_play 0
tsdemux: <tsdemux0:video_0044> Got event qos
souphttpsrc: <source> unlock()
tsdemux: <tsdemux0:audio_0045> combined ok
basesrc: <source> no sync needed
basesrc: <source> buffer ok
souphttpsrc: <source> unlock_stop()
basesrc: <source> pausing after gst_pad_push() = flushing
basesrc: <source> pausing task, reason flushing
mpegtsbase: <tsdemux0> sending flush stop
basesrc: <source> handle event flush-stop event: 0x80932d0, time 99:99:99.999999999, seq-num 881, GstEventFlushStop, reset-time=(boolean)true;
basesrc: <source> flushing 0, live_play 1
tsdemux: flushing stream 0x74f2a570
tsdemux: flushing stream 0x74f25cd8
tsdemux: seek event, rate: 1.000000 start: 0:15:59.864000000 stop: 99:99:99.999999999
tsdemux: <tsdemux0> configuring seek
mpegtsbase: <tsdemux0> sending flush stop
[New Thread 0x6f8ffb40 (LWP 2998)]
mpegtsbase: Pulling data from 592253403

(fbxmms:2973): GStreamer-CRITICAL **: pullrange on pad tsdemux0:sink but it was not activated in pull mode

I think this happens because the h264 keyframe scanning function sets the base->mode value to SEEKING instead of PUSHING. The mpegts_base_handle_seek_event() function is then called in the wrong mode and the push mode seek specific handling is not used.

IMHO the simplest solution is to disable keyframe scanning in push-mode. This is counter productive anyway since the scan triggers backwards seeking, which shouldn't be done in push mode.
Comment 1 Edward Hervey 2014-07-21 11:06:05 UTC
Indeed, we should disable it in push-mode. Weird this one crept through
Comment 2 Edward Hervey 2014-07-21 11:07:12 UTC
It goes into this code path without the ACCURATE seek flag ?
Comment 3 Arnaud Vrac 2014-07-21 12:07:43 UTC
Yes it does
Comment 4 Mathieu Duponchelle 2014-07-21 13:23:41 UTC
Could you provide specific steps to reproduce, ideally using gst-validate?
Comment 5 Tim-Philipp Müller 2014-07-21 13:33:43 UTC
totem pushfile:///path/to/foo.ts
Comment 6 Arnaud Vrac 2014-07-21 14:16:01 UTC
gst-validate-1.0 --set-scenario /usr/share/gstreamer-1.0/validate-scenario/seek_forward.scenario ! tsdemux ! fakesink
Comment 7 Mathieu Duponchelle 2014-07-21 16:20:18 UTC

There were two issues there: the codepath was indeed activated when seeking without the accurate flag, and no scanning should be performed when operating in push mode.

I'll attach patches.
Comment 8 Mathieu Duponchelle 2014-07-21 16:24:04 UTC
Created attachment 281327 [details] [review]
Fixes the first issue
Comment 9 Mathieu Duponchelle 2014-07-21 16:24:28 UTC
Created attachment 281328 [details] [review]
Fixes the second issue
Comment 10 Arnaud Vrac 2014-07-21 16:33:35 UTC
Thanks Mathieu, those patches do fix the regressions I had.
Comment 11 Sebastian Dröge (slomo) 2014-07-22 07:27:18 UTC
Comment on attachment 281328 [details] [review]
Fixes the second issue

Shouldn't we scan for keyframes nonetheless if ACCURATE seeking was requested?
Comment 12 Mathieu Duponchelle 2014-07-22 12:49:00 UTC
Arnaud said backwards seeking should not happen in push mode, I suppose he's got good reasons to say so, so I deactivated accurate seeking altogether as suggested.
Comment 13 Sebastian Dröge (slomo) 2014-07-22 13:16:46 UTC
I think it should still be done in push mode if ACCURATE seeking is requested. You'll however have to detect properly if upstream can seek.
Comment 14 Mathieu Duponchelle 2014-07-22 13:57:29 UTC
commit ab1c328bb1544d5c9813abb31075ce52094965ba
Author: Mathieu Duponchelle <>
Date:   Mon Jul 21 18:22:18 2014 +0200

    tsdemux: Do not scan for keyframe when in push mode.

commit 58b2d582223ba35337d226b8084737e5b2431832
Author: Mathieu Duponchelle <>
Date:   Mon Jul 21 18:21:41 2014 +0200

    tsdemux: Do not scan for a keyframe in non-accurate mode.

Both patches pushed on master and 1.4