I'm working on a streaming project.
I have VLC running as a server, streaming mp4 (h264/aac) RTSP stream to Flumotion server (which is based on Gstreamer).
I think it's either a compatibility problem between VLC (which is based on Live555) and Flumotion (which is based on GStreamer) or the pipeline used to receive RTSP stream is mis-written.
Here's the pipeline used by flumotion and needs to be fixed (rtsp.py lines 44-49):
return ("rtspsrc name=src location=%s ! decodebin name=d ! queue "
" ! %s ffmpegcolorspace ! video/x-raw-yuv "
" ! videorate ! video/x-raw-yuv,framerate=%d/%d ! "
" @feeder:video@ %s ! @feeder:audio@"
% (location, scaling_template, framerate[0],
framerate[1], audio_template))
Edit: The problem is that RTSP-Producer component in flumotion can't recieve any data from the VLC stream. no errors, nothing, it just keeps in 'waking' status.
I tried some variations of GStreamer pipeline used by flumotion but couldn't get it to work.
I found many similar unsolved questions in StackOverflow which made me think it's a compatibility issue
I'm not a gst-pipeliner ! so please help me out of this struggle.
Okay now, since this command is working (usually):
gst-launch playbin uri="rtsp://127.0.0.1:8554/live"
I decided that there can't be compatibility problem! and the problem was solved by using 'rtspdecodebin' instead of 'rtspsrc' and 'decodebin'
So finally I modified that in rtsp.py::
return ("uridecodebin name=d uri=%s ! queue "
" ! %s ffmpegcolorspace ! video/x-raw-yuv "
" ! videorate ! video/x-raw-yuv,framerate=%d/%d ! "
" @feeder:video@ %s ! @feeder:audio@"
% (location, scaling_template, framerate[0],
framerate[1], audio_template))
Now it works! (most of the times) and it's probably something with the stream or QoS ...