GNOME Bugzilla – Bug 792861
splitmuxsrc: short segment duration causes rtsp-server to eos after one fragment
Last modified: 2018-01-29 11:31:50 UTC
Created attachment 367361 [details] gst_debug level 5 when splitmuxsrc made a file swap I am using such rtsp-server url: splitmuxsrc location=@0/*.mkv ! h264parse ! rtph264pay name=pay0 pt=96". I have multiple mkv fails each in length of 1min. The problem is that after splitmuxsrc made the first fragment swap from filesrc0 to filesrc1, the client session is not alive. So the client cant get any rtsp stream anymore. Repeat: Run gst-rtsp-server with url above. Once the media is prepared, start playing rtsp:://... with gst-play-1.0 or any other pipeline. Wait until the first file content should be swapped with the next file. Client receives EOS. Session gets closed. Rtsp-stream still works but client is disconnected. Notes: With GST_DEBUG=5 i notices that even if the client receives EOS, rtsp-server rtsp stream under factory still works. In attachment can see that the console output at the moment of swap.
After additional debugging I found out that there might be some problems to get seeking range for the next fragment. As i have a test case with 3 files in length of ~1min, than i see such message that seems logical : 0x169b680 INFO rtspmedia rtsp-media.c:2191:gst_rtsp_media_seek: current 0:00:00.000000000 - 0:00:59.160864475 And after the very next swap, rtsp-media-stream is not making another seek range update. So my question is, wether that is a reasonable to try reset seek on rtsp media stream, once i got the splitmuxsrc message on the bus "splitmuxsink-fragment-opened". And if i reset the seek position, i suppose the stream should be prerolled. So client should not receive EOS.
Can be reproduced with: Create chunks: gst-launch-1.0 videotestsrc num-buffers=1000 ! timeoverlay font-desc=Sans,25 ! x264enc key-int-max=10 ! splitmuxsink muxer=matroskamux location=/tmp/part-%03d.mkv max-size-time=5000000000 Works: gst-play-1.0 'splitmux:///tmp/part*.mkv' Stops after one chunk (5s): ./test-uri 'splitmux:///tmp/part*.mkv' gst-play-1.0 rtsp://127.0.0.1:8554/test
Looks like a problem in splitmuxsrc: gst-launch-1.0 'splitmux:///tmp/part*.mkv' ! fakesink silent=false -v event ******* (fakesink0:sink) .. GstSegment, ... 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)4666666666
Created attachment 367408 [details] [review] splitmuxsrc: properly set total duration on outgoing segment We would accidentally pass through the duration value from the demuxer from a single fragment, which causes problems when feeding the stream from splitmuxsrc to rtsp-server. Streaming would stop after one fragment due to that.
Or we just unset segment.duration, that should work as well, but it would be nice to set the stop to the duration then if it's not configured through a seek.
Review of attachment 367408 [details] [review]: LGTM
commit ddd4fe680f5379d4ddf6ee06166870626f9c5cec (HEAD -> master) Author: Tim-Philipp Müller <tim@centricular.com> Date: Thu Jan 25 00:46:57 2018 +0000 splitmuxsrc: properly set total duration on outgoing segment We would accidentally pass through the duration value from the demuxer from a single fragment, which causes problems when feeding the stream from splitmuxsrc to rtsp-server. Streaming would stop after one fragment due to that. https://bugzilla.gnome.org/show_bug.cgi?id=792861