Using Gstreamer with OpenMax in a Raspberry Pi

This minipost shows a subgroup of commands tested in a Raspberry Pi to evaluate the possibilities of a usage of this hardware as a domestic TV Headend.

  • From UDP/TS source with video MPEG2 to another UDP multicast group transcoding the video
    stream with H264:gst-launch-1.0 -v  udpsrc uri=udp://239.123.123.3:1234 ! tsdemux ! queue ! mpegvideoparse ! omxmpeg2videodec ! videoconvert ! omxh264enc ! video/x-h264,stream-format=byte-stream,profile=high ! h264parse ! mpegtsmux ! udpsink host=239.123.124.3 port=1234 auto-multicast=true

    The Gstreamer pipeline doesn’t break/end but there is a bug in the h264parse: it sends not regularly the needed SPS / PPS information with it (http://www.raspberrypi.org/forums/viewtopic.php?f=70&t=59412). Then, resulting stream is only playable if you get the stream from the beginning.

  • From UDP/TS source with video MPEG2 and MP2 to another UDP multicast group transcoding the video stream with H264 and video with AAC:
    gst-launch-1.0 -v udpsrc uri=udp://239.123.123.1:1234 ! queue ! tsdemux name=dem \
    dem. ! queue ! mpegvideoparse ! mpeg2dec ! videoconvert ! omxh264enc control-rate=1 target-bitrate=1000000 ! video/x-h264,stream-format=byte-stream,profile=high ! h264parse config-interval=2 ! queue ! muxer. \
    dem. ! queue ! mpegaudioparse ! mpg123audiodec ! audioconvert ! faac ! queue ! muxer. \
    flvmux name=muxer ! queue ! rtmpsink location="rtmp://rtmp.server:1935/rtmp/test2 live=test2"

    The Gstreamer pipeline breaks for some unkknown reason.

  • From UDP/TS source with video MPEG2 to a RTMP server transcoding to H264:
    gst-launch-1.0 -v udpsrc uri=udp://239.123.123.1:1234 ! queue ! tsdemux name=dem \
    dem. ! queue ! mpegvideoparse ! mpeg2dec ! videoconvert ! omxh264enc control-rate=1 target-bitrate=1000000 ! video/x-h264,stream-format=byte-stream,profile=high ! h264parse config-interval=2 ! queue ! muxer. \
    flvmux name=muxer ! queue ! rtmpsink location="rtmp://rtmp.server:1935/rtmp/test2 live=test2"

    Works fine and smooth. Source is a MPEG/TS SD channel.

  • From UDP/TS source with audio MP2 to a RTMP server transcoding audio channel to AAC:
    gst-launch-1.0 -v udpsrc uri=udp://239.123.123.1:1234 ! queue ! tsdemux name=dem \
    dem. ! queue ! mpegaudioparse ! mpg123audiodec ! audioconvert ! faac ! queue ! muxer. \
    flvmux name=muxer ! queue ! rtmpsink location="rtmp://rtmp.server:1935/rtmp/test2 live=test2"

    Works fine and smooth.

Red5: The OpenSource RTMP server

Recently, I started to work with Red5 RTMP server. Red5 is a OpenSourceRTMP server based on Spring/Tomcat/Java technologies and this is the alternative to the privative Adobe FMS (Flash Media Server) .

Currently, Red5 project has reachend the 0.9 milestone of the Red5 roadmap. You can the latest feautures added to Red5 in: http://red5.org/wiki/Changelog.  Here’s a brief description of the features in Red5:

  • Streaming Audio/Video (FLV and MP3)
  • Recording Client Streams (FLV only)
  • Shared Objects
  • Live Stream Publishing (live h264 supported now)
  • Remoting ( AMF0/ AMF3)

You also need to know 2 concepts:

  • Red5 is a Java aplication server framework that provide all the logic for FLV reflection.
  • You will deploy aplications over Tomcat or stanalone Red5 launcher. This aplication will use the red5 jar library for implement the application logic.

Red5 community work primarly with Java progaming language. In anyway, you can work with another supported language to deploy the application and hadlers. For example: jython, jruby or action script. You can obtain more info in http://osflash.org/red5 and http://red5.org/