I have an application derived from the encodedecode demo from the DM6467T EVM. Note that typing "stop" on the console will stop the demo, just like the power off button on the remote control. (I don't have IR input on my custom board, also derived from DM6467T EVM.)
Well, when I press "stop", I see the OSD black box with text for just a frame or so, and then output display goes blank as the application stops. While the application is running, however, I don't see the OSD at all.
Shy of posting all my source code right now, perhaps I can dance around the problem and someone suggest a solution. Consider display.c, derived from the encodedecode demo. Tracing shows me that Blend_create() is being calls. Tracing also shows me that config() is getting called a few times in the beginning of the display while loop, and config() of course calls Blend_config(). Tracing further shows me that Blend_execute() is called every frame. So, I would think the OSD would show every frame, and not just the last one before the application stops.
I wonder if I've messed up buffer handling, somehow. I have modified the code to work with NTSC input from TVP5147M1, by adding a #define for USE_YUV422SP. This in in contrast to HD video that comes in as YUV420SP and must be converted to YUV422SP. Therefore, I've #ifdef'd out the Ccv stuff, including Ccv_create(), Ccv_config(), and Ccv_execute(). In doing so, I saw that Ccv_execute() received two buffers, hSrcBuf and hDstBuf. It appeared that Ccv_execute effectively copied the buffer contents from source to destination. Since I excluded the CCv_execute, I replaced it with an assignment statement "hDstBuf = hSrcBuf".
SOOOOO.... I replaced the assignment with a (slow) memcpy, and the OSD started working all the time. So I must have something out of kilter. With the assignment instead of memcpy, my application works fine. The codec does its thing to video passing through, the output looks great, and it's fast enough that I have ARM Load 4%, DSP Load 71%. But, of course, the OSD doesn't work. With the memcpy, frame rate falls to 27fps, ARM load goes up to 62% (and not able to feed the DSP fast enough, DSP load falls to 42%).
Why do I have to do the memcpy? I wondered if it was because Blend_config() receives hDstBuf before it gets reassigned to equal hSrcBuf, but then Blend_execute() receives hDstBuf AFTER it gets reassigned to equal hSrcBuf. However, I tried changing the hSrcBuf declaration to just a #define to be identical to hDstBuf. Then neither the memcpy() nor assign is necessary. But the OSD didn't display.
Perhaps THIS last thing was because the Fifo_get(..., &hSrcBuf) that gets the buffer from the video thread is changing hSrcBuf anyway, to be different from the buffer used in Blend_config(). What do you think? Is it possible that Blend_config() simply MUST be called for the exact same handle as Blend_execute(), and whenever Ccv was copying src to dst, it was always using a buffer in the dst queue? I'm confused now. Maybe some sleep will help. Am I on the right track?
Thanks,
Helmut
