[Bug 733490] New: tsdemux: H264 seeking broken in push mode

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=733490
  GStreamer | gst-plugins-bad | 1.4.0

           Summary: tsdemux: H264 seeking broken in push mode
    Classification: Platform
           Product: GStreamer
           Version: 1.4.0
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: rawoul at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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.

-- 
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.