Question

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.

Answer 1

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 …