Hi,
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?
Thanks
Shruti
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.
Regards,
Brijesh Jadav
Please mark this post as answered via the Verify Answer button below if you think it answers your question. Thanks!
Hi Brijesh,
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?
Hi Shruti,
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.
Regards
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?