We have previously been able to capture NTSC frames (720x480), resize them to our target display (320x240) and display them at the full input rate of 30 FPS. We are now trying to incorporate this operation into the DVSDK encode demo, but we have run into some trouble. In the capture thread, I replaced all of the original code regarding capture and display with my own code which was working fine for simple "pass-through" to the display. This still works fine, but as soon as I introduce the code to get/put buffers from the video thread (which should in turn start the h264 codec running), I get tearing effects in my output buffer. Now here's the part that actually worries me: At no time do I ever try to copy or send either my capture or resized output buffers to the video thread: I am merely getting a buffer handle from the video thread, and then after capture-resize-display, I return it untouched.
My current guess as to what is happening, is that the resizer and h264 peripherals are fighting over the DMA peripheral(s) and the resizer is losing.
Despite the tearing, we did attempt to push on and encode the capture video, which provides some interesting points of information:
- When using Framecopy_exceute from my output buffer (mem-mapped from the framebuffer device) to the video thread's buffer, the artifacts seen on the screen are visible 1-for-1 in the encoded file. (Play back on the host PC shows the same effect)
- Trying to isolate the issue, I inserted code to manually fill first the output buffers with a simple test pattern (alternating colored vertical bars): This eliminated the problem. (So the issue must be occurring before Framecopy and display swap)
- I disabled the output buffer test pattern and applied a similar (larger dimensions) test pattern to the dequeued capture buffer and found that the problem is plainly visible.
- I then disable the Framecopy sections of the code (so now I am acquiring/returning buffers from/to the video thread but am not touch their contents)
- Re-running the application I see the exact same issue
- Finally, I disable the code that acquires and returns the video thread buffers, and the problem disappears.
See the following image and attached m4v video to see what I'm talking about. (VLC or QuickTime are required to view the video file which is a raw h264 video stream)
As my code has three capture buffers, I chose the fill color based on the current buffer index: dark gray for frame 0, light gray for frame 1 and white for frame 2. I neglected to enforce this ordering, but it appears that the capture device always returns the next buffer in the sequence.
