This is one of my end applications of the Overo.  I want to mount this device onto a rover/uav and get real-time streaming, good quality video.  I also didn't want the operation to dominate the CPU.  Ideally my other applications will be able to run along side the video stream.  Therefore, I had to use the DSP.  So once I got it running it was time to stream.

Scott's discussion and example pipelines were great but I had previously tested some gstreamer code on Linux machines that I wanted to try.  I got the code from here, there's a whole bunch of sample files.  What I initially did was change the server code to suit the TI codecs

gst-launch -v gstrtpbin name=rtpbin v4l2src ! queue ! videorate ! ffmpegcolorspace ! video/x-raw-yuv,width=640,height=480,framerate=15/1 ! TIVidenc1 codecName=h264enc engineName=codecServer ! rtph264pay ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0 ! udpsink port=5000 host=$DEST ts-offset=0 name=vrtpsink rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=$DEST sync=false async=false name=vrtcpsink udpsrc port=5005 name=vrtpsrc ! rtpbin.recv_rtcp_sink_0

You'll notice I removed all the audio chunks.  At the moment I don't have a mic so what's the point.  I did however leave in all the control flow (RTCP).  This is nice to sync up the streams.  I don't fully understand what's going on but I have played with the timing and seen the video change using the RTCP settings, basically performance seemed to improve.  In the above code, I set DEST to the ip address or DNS name of my client.nbsp;

The first client I tested was a windows maching with VLC and this client file client-PCMA.sdp.  Things worked ok (as long as you open up the client first and before the connection times out you fire up the server).  However, there was a pretty good lag (roughly 1 sec) in the video.  So I tried out the linux sh file and things looked much better.  I also don't know if it had anything to do with it but I setup the ntpdate package on the Overo so that it would correctly set the date (I think the RTCP uses time stamping to improve performance but I could be wrong).  I figured having the correct date/time would be good.  To get it to display the correct time zone I used  export TZ=PST8PDT.  However I can't get it to be persistent.  I tried putting it in a file at /etc/TZ but that didn't work, I'll play around with it later.

Now I wanted to stream stuff to a windows machine.  I did a quick search and found this website.  The OSSBuild comes with some precompiled binaries, one of which is gst-launch.  With that binary I used the following command

gst-launch -v gstrtpbin name=rtpbin latency=50 udpsrc caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, sprop-parameter-sets=(string)\"Z0KAHukBQHpCAAAH0AAB1MAIAA\\=\\=\\,aM48gAA\\=\"" port=5000 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! autovideosink udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 rtpbin.send_rtcp_src_0 ! udpsink port=5005 host=$OVERO sync=false async=false

I set OVERO to be the ip/dns name of the Overo wifi adapter.  You'll notice I added the sprop-parameter-sets as per Scott's instructions so that client or server can be started first.  I also messed around with the latency value.  It's definitely dependent on the speed of the client.  Some I could set low, others needed to be higher.  I believe it adds a bit of lag to the video.  Anyway, what I got was really good video with very little lag.  Also, one of the reasons I was doing this test was to see the CPU load.  So ... with 640x480 at 15 frames per second over wifi I got about 20% cpu load.

top - 20:17:26 up 37 min,  2 users,  load average: 0.08, 0.06, 0.01
Tasks:  67 total,   1 running,  66 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.0%us,  0.8%sy,  0.0%ni, 95.9%id,  0.8%wa,  0.6%hi,  0.0%si,  0.0%st
Mem:    469008k total,    71380k used,   397628k free,     3200k buffers
Swap:        0k total,        0k used,        0k free,    46712k cached

 1013 root      20   0 87720 7660 5132 S 19.2  1.6   0:34.72 gst-launch-0.10

This is pretty sweet, ready to test other stuff while streaming video. I still need to play with the latency. It's not very large but definitely noticable. I haven't determined if it's the client or the server. Now that I have an LCD screen (thanks Don) I'm going to try looping back the video and see if the latency is apparent, stay tuned.

Last modified Sun, 4 Sep, 2011 at 16:41