A frequent customer request is “how do I stream the video over the network?”.
There are some solutions out there that aren’t FOSS and if you try to extend the demo to do what you really need to do… you start running on issues. That’s the reason we push GStreamer based solutions, where the design allow simple and fast design and prototype of streaming media solutions.
We have been looking for some time to provide a FOSS solution for an RTSP server, and when we found the gst-rstsp-server, we were really happy. Kapil expended some time extending it to work for a customer scenario, but unfortunately we run into some out-of-memory situations quickly due to some design decisions on the code that assume more memory that what is typically available in embedded devices.
Then Diego stumble upon an article from some MIT folks where they used the Darwin Streaming Server (DSS) as RTSP server. This GStreamer+DSS approach have some advantages:
- The DSS core is only C++ code with no external dependencies.
- The DSS code base is used on production systems for media streaming.
- We take advantage of GStreamer on where it really shines and let DSS handling the RTSP part only. Glue-less integration is possible between DSS and GStreamer.
But we also have disadvantages:
- It’s limited to the sdp file approach. For more complex streaming scenarios it may fall short.
- It may be that DSS is over killer.
As the article points out, they used DSS running on a PC machine, not on the Nokia device. We need to run DSS from the board, so we just rolled up our sleeves and got to work. After a couple of hours and some help from community patches to build DSS on Linux machine we finally got DSS cross compiling using RidgeRun’s SDK and running the streaming core reliable on any of our boards.
We were successful streamed video from a Leopard VGA camera using the following pipeline (using DDOMPE branch):
gst-launch v4l2src always-copy=false ! dmaiaccel ! queue ! dmaienc_mpeg4 !
rtpmp4vpay ! udpsink port=5434 -v
We require the -v option so we can get the codec_data information generated by the encoder and passed on the caps of the sink pad of the dmaienc_mpeg4 element. This information needs to be put in the sdp file as detailed below.
And the following sdp file on /streaming/movies/leopardlivecamera.sdp:
v=0
o=- 132 362358265 IN IP4 127.0.0.0
s=QuickTime
t=0 0
a=range:npt=now-
a=control:rtsp://127.0.0.1/stream.sdp
m=video 5434 RTP/AVP 96
c=IN IP4 127.0.0.1
b=AS:6000
a=rtpmap:96 MP4V-ES/90000
a=fmtp:96 profile-level-id=5;config=000001010000012000845d4c28a021e0a21f
a=mpeg4-esid:201
a=cliprect:0,0,640,480
a=framesize:96 480-640
I’m not a dsp syntax expert, so I generated the sdp file with the help of the QuickTime Broadcaster and then just adjusted the parameters to the resolution of the camera, the config string with the information from the codec_data (obtained from the pipeline), and the IP addresses to pickup the stream from the localhost.
With this setup, we are able to stream from the camera into a local port and then having the DSS running on the same board serving the RTSP clients. To connect all you need is:
vlc rtsp://10.251.101.140/leopardlivecamera.sdp
Where the 10.251.101.140 IP is obviously the address of the board we are running from.
The only issues we notice so far seem related to latency of the video, but probably some tweaking of the parameters will solve the issue.
The CPU consumption of DSS is good, and the memory consumed is low, so we got a good start.
Enjoy!
Davinci, Gstreamer, LeopardBoard
Davinci, Gstreamer, LeopardBoard, RTSP