Hi,
I am attempting to write a video streamer on an OMAP3530 based Embest Devkit8000 board. My development environment is based on a patched stack named OMAP35x-PSP-SDK-linux-kernel-02.01.03.11-devkit8000-patch-2 and available at http://code.google.com/p/devkit8000/ . The software I am writing is supposed to capture video, encode to H.264 using Codec Engine and broadcast over the network in RTP format. My development starting point was with a capture-display loopback demo named saMmapLoopback (from OMAP35x-PSP-SDK-02.01.03.11/src/examples/examples.tar.gz), which opens the capture and display drivers, and loops input video back out to the LCD monitor. Then I added code to open the Codec Engine and create an instance of an H.264 encoder, using TI's codec supplied with the DVSDK. The first thing I wanted to do was prevent the need to copy the captured video frame to the encoder's input buffer. I tried to get the video capture driver to write the incoming data directly to the CMEM buffer used as the codec's input buffer. This turned out to be impossible, and confirmed by a post on TI's discussion forum which added that a new PSP version solves that problem (sorry, I can't find that post right now). In any case, upgrading to a new PSP is not possible at the moment as the whole software stack is patched by Embest for this board and upgrading anything manually will likely cause problems. When looking at the saMmapLoopback example I saw that it used a regular memcpy operation to copy the captured video frame to the display output buffer. So, I decided to use a similar memcpy to copy the video data to the encoder input buffer instead. This worked - but performed very badly. A quick benchmark confirmed that copying from the capture to the display buffer takes about 10 msec, while copying to the encoder buffer took 40 msec! So... QUESTION 1: Why is CPU access to CMEM memory space far slower than other memory? Is there a way to fix this problem? My solution to this problem was to use the Resizer to copy the frame, using the FrameCopy module of DMAI, with HW acceleration enabled. The next step was to packetize the compressed video to RTP and send it over the network. When this worked and the video was visible in a VLC/Quicktime window, however, the next problem came to light: there was a slight jitter in the video that occured once every few seconds. After a bit of investigation it seems that the captured video frame is corrupted. Instead of being comprised of two new fields, it is made from one old field (perhaps from 3 frames previously) and one newly captured field. Sometimes the problem affects two consecutive frames before the capture returns to normal. I have verified that it is a capture problem and not an encode problem, by enabling the loopback to the LCD monitor and seeing the same corruption on the monitor. It's also not a hardware problem, we have two boards and the problem happens on both. I have spent weeks trying many approaches to solving this problem. I have tried to pinpoint the problem by eliminating various processing stages in my program. At one point I was convinced that the H264 encoding was causing the problem. Then I thought that the RTP packetization was causing a problem because it was accessing the encoder output buffer (which is also CMEM memory - see question 1). At another point it seemed that sending packets out to the network (the call to "sendto") was causing the problem. I've also tried to play with scheduling parameters and thread priorities (the app is multi-threaded). After all the investigation, however, I haven't been able to nail a single factor that is causing the video glitches, and it only seems that the less actions are done, the less frequently the glitches occur. QUESTION 2: Why am I seeing glitches in incoming video? I have a gut feeling that answering Question 1 may solve Question 2, that's why I bring both issues here. Thanks in advance for any assistance. Note that I have raised this question on Embest's forums but received no response. -itay
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
