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 server-v4l2-H264-alsasrc-PCMA.sh 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 client-H264.sh 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
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
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
