We are using the DM368 with custom hardware (modeled after the EVM board) in an application where we are streaming H.264 encoded 480P60 video. In our initial prototype, we were using DVSDK 3.10.00.19 along with the kernel version PSP 3.01.01.38 to successfully stream the 480P video downscaled to 480x272 on the encode end before encoding. We are also using the latest versions of both the encode and decode codecs and I am using extended parameters, primarily to insert periodic IDR frames and I frames.
Now, in the second iteration, I have switched to DVSDK 4.02.00.06 while retaining r38 of the PSP as we have a number of modifications made to the Davinci specific parts of the kernel to be compatible with our hardware. In testing of this implementation, I can successfully stream 1280x720 720P video; however, when attempting to stream 720x480 480P video, I have been running into a problem.
Specifically, the decoded video shows a vertical line of distortion at the extreme left side of the display and the video data itself is shifted to the right so that the extreme right part of the video frame is cut off. The vertical distorted line sometimes appears as if the pixels are “smeared” and the width of this line is probably around 30 or 40 pixels.
In attempting to find the cause of this problem, I have found that the older display code from DVSDK 3.10.00.19, which uses frame buffering, does not exhibit this problem; however, I cannot use it at 720x480 480P as the frame buffer operation causes the display thread to not leave enough time for the streaming video data to be processed and I am missing large numbers of packets. As an experiment, I changed to the MPEG4 codec and have found that it does not exhibit the same distortion as the h.264 codec. I also ran the MPEG4 codec using both YUV420 semi-planar and interleaved color space just to see if there were any differences, which there were not.
I am aware that the video code in 4.02.00.06 has been modified to allow this DVSDK’s display code to work without the frame buffer (according to comments in the file). However, I again see no difference using this video code as opposed to the video code from 3.10.00.19.
I would appreciate any suggestions as to any resolution to the problem as we would prefer to stay with the h.264 codec.
Thanks,
John
