This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I am working on dm6467 platform. We are facing latency performance issues. I have observed that if i comment out the vidioc_dqbuf call i see a substantial improvement in latency(50-80msec). Has anybody faced any problem with this call before? Also, we are performing VDCE operation before giving it to the display driver, can this cause any problem?
Which VDCE operation are you using? Also what is the frame size for the VDCE operation? VPIf does not have latency issue, but because of VDCE operation taking londer time, you might see latency issue. You could check the time it takes to do a VDCE operation, if it is not real time, it is an issue..
VPIF will return buffer only if it has one more buffer to write to. so you need to enqueue buffers in time to VPIF, otherwise you will latency in DEQUEUE operation.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Brijesh Jadav:
VDCE is performing chroma conversion - 420 Semi Planar to 422 Semi Planar. Frame size is 1280 x 720.
If I comment either the DEQUEUE operation (i.e. allow application to overwrite display driver buffer without checking if driver buffer is available) or the VDCE operation, I observe substantial drop in latency. So, I am doubting some conflict in the shared resources. Maybe both display driver and VDCE are using the same EDMA transfer queue?
I am using linux bios. Can anybody tell me where can I find the assigned EDMA tansfer control queue for both VPIF and VDCE(in which files is the macro defined for default values for TC for these two) and how can I change the values for the same?
In reply to Shruti Purohit:
VDCE should be able to perform chroma conversion for this frame size in real time. VPIF does not use EDMA, it has its own internal dma, so does not depend on EDMA. it does not look like the conflict in the shared resource..
I have couple of questions, how are measuring latency? from which point to which point? Could you measure how much time VDCE operation takes?
I am measuring glass to glass latency (time difference between input source and the decoded output being displayed on television) which is coming out to be 300 to 400 ms.
The flow of the system is as follows -
Capture(720P60 from a camera) -> Encode(H.264) -> Mux (MPEG2-TS muxer ) -> stream out over ethernet -> Receive it on another DM6467 board -> Demux (MPEG2-TS demuxer) -> Decode(H.264) -> Perform VDCE operation (420 to 422 conversion) -> Display it on television
VDCE operation is taking somewhere between 6 to 8 ms.
Thanks and Regards
If VDCE operation itself is taking around 6 to 8ms, delay in latency is not because of VDCE. It is something else, may some issue in the design itself. do you have separate thread for VDCE operation? if yes, what's its priority? if not, is it part of display thread? is the output buffer for vdce operation comes from display? do you do memcpy to display buffer?
No we dont have separate thread for VDCE operation. VDCE operation is part of display thread. Yes the output buffer of VDCE operation comes from display driver.
what i am not getting is even if VDCE oparation takes around 8ms, it introduces latency of 40ms. how is this possible? if you comment out VDCE operation and use sw based conversion, you get improvement of 40ms? Can you explain the data/buffer flow in your case? i feel there is somewhere memcpy involved? It could be in input or output of the VDCE? Could you check this?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.