[Bug 766868] New: qtdemux: Segments start at 0 on live MSS time-based streams, ignoring the start time configured upstream
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Wed May 25 13:50:40 UTC 2016
https://bugzilla.gnome.org/show_bug.cgi?id=766868
Bug ID: 766868
Summary: qtdemux: Segments start at 0 on live MSS time-based
streams, ignoring the start time configured upstream
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-plugins-good
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: eocanha at igalia.com
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Since updating from GStreamer 1.6.3 to GStreamer 1.8.1, live MSS streams aren't
working for us.
Out pipeline has a GstMSSDemux component which fetches the audio and video
streams. These are fed to two GstQTDemux working in push mode. The element
connected to the qtdemux sink is providing a right [10058:15:55.58, infinity]
segment (these are live streams which don't start from 0), but qtdemux ignores
it and emits a [0, infinity] segment event instead. The generated PTSs are in
the [10058:15:55.58, infinity] range, so in theory nothing would be shown on
the screen until time reaches 10058.
Unfortunately, I can't easily provide a publicly available test case using
gst-launch. However, I can provide relevand log outputs of the 1.6.3 and 1.8.1
behaviours:
---------------------
Good (1.6.3): Qtdemux produces a correct segment
0:00:05.075236404 808 0xa95890 DEBUG qtdemux
qtdemux.c:1009:gst_qtdemux_push_event:<qtdemux0> pushing segment event on all
source pads
0:00:05.075858904 808 0xa95890 LOG GST_PADS
gstpad.c:5047:store_sticky_event:<qtdemux0:video_0> stored sticky event segment
0:00:05.076012966 808 0x7120b060 DEBUG basesrc
gstbasesrc.c:2355:gst_base_src_update_length:<souphttpsrc0> reading offset
706553, length 4096, size 926405, segment.stop -1, maxsize -1
0:00:05.076886196 808 0xa95890 DEBUG decodebin
gstdecodebin2.c:2030:demuxer_source_pad_probe:<qtdemux0:video_0> Saw event
segment
0:00:05.077406143 808 0xa95890 LOG GST_PADS
gstpad.c:5210:gst_pad_push_event_unchecked:<qtdemux0:video_0> sending event
0x6f706578 (segment) to peerpad <multiqueue1:sink_0>
0:00:05.077484373 808 0xa95890 DEBUG GST_EVENT
gstpad.c:5496:gst_pad_send_event_unchecked:<multiqueue1:sink_0> have event type
segment event: 0x6f706578, time 99:99:99.999999999, seq-num 125,
GstEventSegment, segment=(GstSegment)"GstSegment,
flags=(GstSegmentFlags)GST_SEGMENT_FLAG_RESET, rate=(double)1,
applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0,
offset=(guint64)0, start=(guint64)36209755584877700,
stop=(guint64)18446744073709551615, time=(guint64)36209755584877700,
position=(guint64)0, duration=(guint64)18446744073709551615;";
^^^ GOOD SEGMENT START TIME!!!
0:00:05.090253279 808 0xa95890 DEBUG multiqueue
gstmultiqueue.c:2052:gst_multi_queue_sink_event:<multiqueue1> SingleQueue 0 :
Enqueuing event 0x6f706578 of type segment with id 4
0:00:05.091063748 808 0xa95890 DEBUG multiqueue
gstmultiqueue.c:1236:apply_segment:<multiqueue1> queue 0, configured SEGMENT
time segment start=10058:15:55.584877700, offset=0:00:00.000000000,
stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x01,
time=10058:15:55.584877700, base=0:00:00.000000000, position
10058:15:55.584877700, duration 99:99:99.999999999
---------------------
Bad (1.8.1): Qtdemux produces an incorrect segment
0:00:03.923238853 516 0xe14890 DEBUG qtdemux
qtdemux.c:1015:gst_qtdemux_push_event:<qtdemux0> pushing segment event on all
source pads
0:00:03.923312863 516 0xe14890 LOG GST_PADS
gstpad.c:5068:store_sticky_event:<qtdemux0:video_0> stored sticky event segment
0:00:03.924766821 516 0xe14890 DEBUG decodebin
gstdecodebin2.c:2031:demuxer_source_pad_probe:<qtdemux0:video_0> Saw event
segment
0:00:03.924952915 516 0xe14890 LOG GST_PADS
gstpad.c:5231:gst_pad_push_event_unchecked:<qtdemux0:video_0> sending event
0x6f614c08 (segment) to peerpad <multiqueue1:sink_0>
0:00:03.925082967 516 0xe14890 DEBUG GST_EVENT
gstpad.c:5517:gst_pad_send_event_unchecked:<multiqueue1:sink_0> have event type
segment event: 0x6f614c08, time 99:99:99.999999999, seq-num 213,
GstEventSegment, segment=(GstSegment)"GstSegment,
flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1,
applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0,
offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615,
time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";
^^^ BAD SEGMENT START TIME!!!
0:00:03.926196301 516 0xe14950 DEBUG basesrc
gstbasesrc.c:1674:gst_base_src_perform_seek:<souphttpsrc1> segment configured
from 0 to -1, position 0
0:00:03.926354894 516 0xe14890 DEBUG multiqueue
gstmultiqueue.c:2071:gst_multi_queue_sink_event:<multiqueue1> SingleQueue 0 :
Enqueuing event 0x6f614c08 of type segment with id 4
0:00:03.926271717 516 0xe14950 INFO basesrc
gstbasesrc.c:1344:gst_base_src_do_seek:<souphttpsrc1> seeking: bytes segment
start=0, offset=0, stop=-1, rate=1.000000, applied_rate=1.000000, flags=0x00,
time=0, base=0, position 0, duration -1
0:00:03.926839999 516 0xe14890 DEBUG multiqueue
gstmultiqueue.c:1257:apply_segment:<multiqueue1> queue 0, configured SEGMENT
time segment start=0:00:00.000000000, offset=0:00:00.000000000,
stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00,
time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000,
duration 99:99:99.999999999
---------------------
Debugging the origin of the wrong start segment, I found that it comes from
gst_qtdemux_handle_sink_event() [1]. The only relevant change in that function
between 1.6.3 and 1.8.1 comes from the patch of bug 763165 [2]. That patch
resets the pending_newsegment which was storing the values properly specified
by the upstream segment event [3]. Temporarily reverting the patch fixed the
issue for me.
[1]
https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/isomp4/qtdemux.c?id=180219a24fadc66a08c0381ecb5b8c3663103b64#n2113
[2] https://bugzilla.gnome.org/show_bug.cgi?id=763165
[3]
https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/isomp4/qtdemux.c?id=180219a24fadc66a08c0381ecb5b8c3663103b64#n2039
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list