GNOME Bugzilla – Bug 629506
playbin2 hangs when trying to play RTSP stream with MPEG-2 video and MPEG audio
Last modified: 2012-05-25 08:53:48 UTC
playbin2 hangs when trying to play RTSP stream with MPEG-2 video and MPEG audio. The hang is always in the same place. rtspsrc has connected to the server, has sent OPTIONS, DESCRIBE and PLAY commands and received positive answers. Also, the decodebin2 instance (named decodebin20) inside the playbin2 internals has created a chain of elements up the the mpeg2dec and mpegaudioparse. It has also created a ghostpad for the mpeg2dec's source pad. Wireshark shows, that the media stream from the server comes to the computer's interface.
Created attachment 170137 [details] A dot-dump of the hang playbin2 pipeline.
Created attachment 170138 [details] Log of RTSP conversation and debug output of gst_debug=rtspsrc:5 Currently I have only Kasenna Mediabase 8.1 RTSP server. This server sends ordinary RTSP stream (as far as can be concluded from the Wireshark's dump analysis). The major difference of this server from the other ones is that it sends something called x-rtsp-mh instead of SDP. I've patched rtspsrc so, that it catches this message and translates it to the SDP. Incomplete patch is also attached.
Created attachment 170142 [details] [review] Partial support of playback from old Kasenna servers
One more thing. My application pauses the pipeline immediately after the first video frame is displayed. When it doesn't, the decodebin20 creates an audio decoder instance and a ghostpad for its source pad. The respective dot-dump is attached.
Created attachment 170144 [details] Dot-dump of the playing pipeline, processing rtsp:// uri
(In reply to comment #4) > One more thing. My application pauses the pipeline immediately after the first > video frame is displayed. For a live pipeline that would stop datatransfer. > When it doesn't, the decodebin20 creates an audio decoder instance and a > ghostpad for its source pad. What's so bad about that? it sounds like something it should do. > > The respective dot-dump is attached.
> > When it doesn't, the decodebin20 creates an audio decoder instance and a > > ghostpad for its source pad. > What's so bad about that? it sounds like something it should do. Nothing bad, just a description of the pipeline's state. The bug is that the pipeline stays in this state forever and doesn't proceed.
Created attachment 170236 [details] Simple RTSP server, whose stream is not played.
From the irc conversation with Wim Taymans: The culprit is mpeg2dec. It doesn't decode data when they don't contain sequence header. If I use sequence-header-every-gop=true on mpeg2enc on the server's side, the stream is played.
Created attachment 170243 [details] File created with gst-launch -v rtspsrc location=rtsp://192.168.24.148:8554/test ! rtpmp2tdepay ! mpegtsdemux ! gdppay ! filesink location=out.gdp sequence-header-every-gop=true was removed from the mpeg2enc on the server's side. The respective call was gst_rtsp_media_factory_set_launch (factory, "( " "videotestsrc is-live=1 " "! mpeg2enc " "! mpegtsmux " "! rtpmp2tpay name=pay0 pt=33 " " )" );
Created attachment 170245 [details] File created with gst-launch -v rtspsrc location=rtsp://kasenna_server/ ! rtpmp2tdepay ! mpegtsdemux ! gdppay ! filesink location=out.gdp Kasenna MediaBase 8.1 It sends mpeg2 transport stream, encapsulating mpeg2 video and mpeg audio. I've patched rtspsrc in order it could communicate with it. Kasenna uses x-rtsp-mh instead of SDP. I've added the code translating this message to the SDP one.
Created attachment 170248 [details] File created with gst-launch -v rtspsrc location=rtsp://kasenna_server/ ! rtpmp2tdepay ! mpegtsdemux ! video/mpeg ! gdppay ! filesink location=out.gdp
So ... this bug is essentially about supporting x-rtsp-mh in rtspsrc ? Is there any other issues ?
(In reply to comment #13) > So ... this bug is essentially about supporting x-rtsp-mh in rtspsrc ? Is there > any other issues ? No, this bug is about pipeline hangs. Please, see comments 8 and 9. This bug was reproduced without Kasenna, using GStreamer RTSP server. mpeg2dec doesn't decode data, when they don't contain sequence headers.
You can't decode mpeg2 without the sequence header. There's no way around that. So either: * You configure the server to do that (disabling it just doesn't make any sense) * Or that information is transferred via another medium (like in the SDP) and you re-inject it in the stream. Please provide some dumps from the original Kasenna stream (rtspsrc ! rtmp2tdepay ! gdppay ! filesink). I suspect they do transmit that info somehow.
(In reply to comment #15) > Please provide some dumps from the original Kasenna stream (rtspsrc ! > rtmp2tdepay ! gdppay ! filesink). I suspect they do transmit that info somehow. I was creating such dump already a year+ ago, when was developing the player, but bugzilla didn't accept it because of the size. Here is the link: http://dl.dropbox.com/u/11507187/out_kasenna.gdp Unfortunately, my company has stopped development using GStreamer, so I only have old results. Yes, indeed, Kassenna sends sequence headers, searching for 00 00 01 b3 in the file shows them quite regularly.
This was created with gst-launch -v rtspsrc location=rtsp://192.168.24.21/000 ! rtpmp2tdepay ! mpegtsdemux ! video/mpeg ! gdppay ! filesink location=out_kasenna.gdp
when running the following, it gets decoded properly: * filesrc location=out_kasenna.gdp ! gdpdepay ! rtpmp2tdepay ! tsdemux ! mpegvideoparse ! mpeg2dec ! xvimagesink * filesrc location=out_kasenna.gdp ! gdpdepay ! rtpmp2tdepay ! tsdemux ! mpeg2dec ! xvimagesink If I depayload the file (filesrc location=out_kasenna.gdp ! gdpdepay ! rtpmp2tdepay ! filesink location=out_kasenna.ts) This works: * filesrc location=out_kasenna.ts ! tsdemux ! mpeg2dec ! xvimagesink * filesrc location=out_kasenna.ts ! tsdemux ! mpegvideoparse ! mpeg2dec ! xvimagesink * playbin2 pushfile://out_kasenna.ts This doesn't work: * playbin2 file://out_kasenna.ts So to summarize: * Your initial problem is solved (works push-based, stream detected fine and decoded fine...) with tsdemux * There is only an issue when working pull-based with tsdemux (will clone bug for that)