Rincon Multimedia Streaming

The Rincon product family uses the TI Davinci processor for DSP accelerated video capture, compression, decompression, and display. The GStreamer framework is used to provide a multimedia streaming application that can be used in a variety of ways. The following transport mechanisms will be described here:

  • RTP/UDP unicast/multicast
  • RTSP

RTP/UDP unicast/multicast

The base protocol for multimedia network data is commonly RTP (Real-time Transport Protocol) which encapsulates undefined media payload with a common header that contains a timestamp. The RTP packets can be delivered either unicast or multicast. A client wishing to receive and decompress an RTP stream must have prior knowledge of the type of stream or examine the stream in detail to be able to decrypt it properly. This is likely the only downside to using plain old RTP.

The Rincon product family has a server implemented using a GStreamer pipeline by /etc/init.d/tivideo and the configuration file /etc/config/tivideo. The following characteristics can be specified:

  • type (client|server)
  • host (multicast ip address - to send to or receive from)
  • port (port to send or receive from)
  • codec (h264)
  • resolution (720x480|640x480|352x240|320x240)
  • bps (stream bitrate in bps)
  • quality (2 - High quality, 3 - High speed)
  • ratecontrol (1 = No rate control, 2 = Constant bit rate (CBR), 3 = Variable bit rate (VBR))
  • jitter (millisecond value of a de-jitter buffer for client - allows for smoother playback and packet re-ordering in jittery or MESH network environments)

In order to get around the fact that RTP by itself can't describe codec information to a client, that information can be stored in an SDP (Session Description Protocol) file that many clients can utilize to avoid manual configuration.

You can use the OpenWRT LuCI web-admin to configure, see the status of the RTP/UDP media service, and download an SDP file (for automatic launching of configured clients) from


RTSP or Real Time Streaming Protocol is a control protocol which negotiates a network transport mechanism and conveys information about the stream payload. It uses RTP/UDP for data payload (which can be unicast or multicast per the client's request) and RTCP to convey health of the client-server connection.

The benefit of RTSP is that the protocol conveys the stream codec information from the server to the client. An additional benefit is that the server is only sending a stream when there is a client that has requested it and that you can setup multiple stream configurations.

An experimental RTSP server is available for the Rincon product family but currently has no configuration script or web-admin integration. You can write your own init script or manually launch it via a command such as:

gst-rtspd --shared --debug video "v4l2src always-copy=0 queue-size=1 ! TIVidResize ! video/x-raw-yuv,width=720,height=480 ! TIVidenc1 engineName=encode encodingPreset=3 rateControlPreset=2 bitRate=1000000 frameRate=30 contiguousInputFrame=1 codecName=h264enc ! rtph264pay name=pay0 pt=96"

You can define multiple GStreamer pipelines and mappings on the commandline (gst-rtspd [OPTIONS] [path1 "pipeline1"] [path2 "pipeline2"] ...) or you can use the '--config <file>' argument to pass in a config file defining these such as the example in /etc/gst-rtsp_ti.conf.

Note that only a single pipeline can be active that utilizes the capture, display, or DSP functionality of the processor although if launched with the '--shared' option, any number of clients can be viewing a single shared pipeline.

Playback of Rincon streams on other Streaming Clients

While the Rincon product family can be used as either a streaming server (encoding/streaming audio/video from inputs) or a client (receiving/decoding and displaying audio/video to outputs) you may also want to play network streams on other platforms. Here are some suggestions and notes:

Notes about compatibility:

  • A client application must support both the network transport protocol being used on Rincon (ie RTP/UDP or RTSP (see above)) as well as the codec being used for stream compression (h264 video)
  • Many client applications suffer from issues caused by improperly handling multimedia timestamps which present themselves after long periods of time viewing a stream or after some network packetloss or routing changes have occurred.
  • Many clients require some amount of data to be buffered which increases latency.


GStreamer is not an application, but instead an open-source cross-platform multimedia framework. Its architecture lends very well to low-latency network streaming and it does come with a 'gst-launch' application that can be used for many cases. It is available for Windows, Linux, and MacOS. It's architecture relies on combining 'plugin elements' together in strings called 'pipelines' which can be used to create some very useful simple or complex scenarios for generating, encoding, streaming, decoding, transcoding, and capturing multimedia streams.


  • Playback stream from Rincon RTP/UDP streaming server:
    gst-launch playbin2 uri= video-sink="xvimagesink sync=false"  # Linux/X11
    gst-launch playbin2 uri= video-sink="directdrawsink sync=false"  # Windows
  • Playback stream ('video') from Rincon RTSP streaming server:
    gst-launch rtspsrc location=rtsp:// latency=0 ! decodebin ! xvimagesink sync=false  # Linux/X11 unicast
    gst-launch rtspsrc location=rtsp:// latency=0 protocols=GST_RTSP_LOWER_TRANS_UDP_MCAST ! decodebin ! xvimagesink sync=false  # Linux/X11 multicast
    gst-launch playbin2 uri=rtsp:// video-sink="directdrawsink sync=false"  # Windows unicast
    gst-launch -vvv playbin2 uri=rtsp:// uridecodebin0::source::latency=0 uridecodebin0::source::protocols=GST_RTSP_LOWER_TRANS_UDP_MCAST video-sink="directdrawsink sync=false"  # Windows multicast

For Windows, A GStreamer installer package is provided by the OssBuild project. We recommend and have tested using GStreamer-WinBuilds-GPL-x86-Beta04-0.10.7.msi


While VLC Media Player is a very stable and full-featured cross-platform media player, it does not perform well for live low-latency network streams because of the way it manages network buffers. We have found that if you loose network packets the vlc player will in-appropriately increase latency to compensate. Additionally it requires a certain amount of buffering (specified as milliseconds) and if that falls below some threshold (due to network pktloss or latency) it can cause the player to start having decode/display issues. This player is not recommended for anything other than quick tests


  • Playback stream from Rincon RTP/UDP streaming server:
    vlc --network-caching 150
  • Playback stream ('video') from Rincon RTSP streaming server:
    vlc rtsp:// --rtsp-caching 150


  • the 150 caching value above is in milliseconds - ideally you would want this to be 0 to disable all caching but vlc does not decode properly in buffer underrun scenarios. The value of 150 may not even be enough in some situations
  • you can use 'cvlc' for a UI-less command-line version


Last modified 9 months ago Last modified on 10/21/2017 10:28:45 PM