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