[DM8168] Video Display Latency

Hi Philipp

i think the shift issue related to the startX and startY offset generated by decoder is not handing in Display link.  The decode allocated a slightly bigger buffer than the actual picture size and it uses the remaining as scratch area.  so there is a 32 pixel width vertical strip in the left of the image and 24 pixel breadth horizontal strip from the TOP need to be removed while displaying.  This was handled in SWMS and now when you bypass SWMS the same logic need to be added at the input side of display link or the output side of Decoder link.  Its mainly the buffer point manipulation

new buff address = original address + startY * pitch + stratX 

where startX = 32, startY = 24

this should be done for both Luma and chroma buffer pointers

please refer the SWMS function SwMsLink_drvModifyFramePointer() 

regards, shiju

Ah yes, that looks promising. I will investigate this. Thanks Shiju!

Your advice was dead-on Shiju! Thanks!

Unfortunately, I was unable to appropriately mirror the mosaicer code as the display seems to be lacking some information regarding startX, startY etc.. Or did I miss something there?

I ended up with the following patch to remove the extra data:

diff --git a/mcfw/src_bios6/links_m3vpss/display/displayLink_drv.c b/mcfw/src_bios6/links_m3vpss/display/displayLink_drv.c
index 82e60c4..2ad5ace 100755
--- a/mcfw/src_bios6/links_m3vpss/display/displayLink_drv.c
+++ b/mcfw/src_bios6/links_m3vpss/display/displayLink_drv.c
@@ -1553,21 +1553,36 @@ Int32 DisplayLink_drvProcessData(DisplayLink_Obj * pObj)
             {
                 Bool frameReject;
                 UInt32 pitch0,pitch1;
+                Int32 offset0, offset1;
+                Int32 bytesPerPixel = 1;

                 pitch0 = pObj->displayFormat.pitch[0];
                 pitch1 = pObj->displayFormat.pitch[1];
+
                 if (DisplayLink_drvDoInputPitchDoubling(pObj))
                 {
                     pitch0 /= 2;
                     pitch1 /= 2;
                 }

+                // The swms used to take care of adjusting the memory pointers.
+                // Now we have to do it ourselves.
+                // TODO Clean up this hack
+                offset0 = pitch0 * 24 + 32 * bytesPerPixel;
+                offset1 = pitch1 * 24 / 2 + 32 * bytesPerPixel;
+
                 UTILS_assert(DISPLAY_LINK_BLANK_FRAME_CHANNEL_NUM !=
                              pFrame->channelNum);
+
                 pFrame->addr[1][0] =
                     (UInt8 *) pFrame->addr[0][0] + pitch0;
                 pFrame->addr[1][1] =
                     (UInt8 *) pFrame->addr[0][1] + pitch1;
+
+                // Adjust the image address pointers
+                pFrame->addr[0][0] = (UInt8 *) pFrame->addr[0][0] + offset0;
+                pFrame->addr[0][1] = (UInt8 *) pFrame->addr[0][1] + offset1;
+
     #ifdef SYSTEM_DEBUG_DISPLAY_RT
                 Vps_printf(" %d: DISPLAY: Queue %d frames\n", Utils_getCurTimeInMsec(),
                            displayFrameList.numFrames);

Shiju,

When you say

Shiju Sivasankaran said:

In RDK 3.5,  420 path display is supported for both 816x and  810x, but not supported for 814x.  

I assume that it is not due to a hardware limitation for 814x, but rather just

a software issue?  What would it take to support 420 path display for 814x?

Regards,

John Whittington

John

yes, you are correct. There is no HW limitation, this is only a SW limitation. Next RDK release 4.0 will support 420 display for all three platforms including DM814x

regards, shiju

Philipp

Great! thanks for the update.

Please note that these changes in display link works only when decode link as the previous link. Only decoder populate these values as 32 and 24, for all other links these are set to 0

As your chain is working fine now, may be you can modify this fix by taking stratX and stratY from the input frame Appdata rather than hard coding

Input frame has a field "appData" of type System_FrameInfo and this data structure has fields such as

pFrameInfo->rtChInfo.width

pFrameInfo->rtChInfo.height

pFrameInfo->rtChInfo.startX

pFrameInfo->rtChInfo.startY

pFrameInfo->rtChInfo.pitch[]

These values are updated and sending along with each and every frame.  So you can use these values directly to modify the frame pointer

This is only a suggestion, please ignore this if you are comfortable with your current modification

regards, shiju

Hi Shiju,

That's a great suggestion, thank you. I was hoping for parameters like that.

I will modify the code to use the supplied parameters.

Thanks again,
Philipp

hi, Mishael

    I am using the DM814X for cap+sclr+nsf+enc. I want to know the total latency. And I find in this post that you have measure the total latency using DVRRDK. my DVRRDK is 3.0.  I thinking the measure method should be similarly. Could you tell me how to have the total latency in detail. I don't know how to test it at all...

regards,

oguri 

hi,Shiju

I'm using DVRRDK on 814x for cap+sclr+enc, and I want to know the total latency, below is my print info. Do you have a clear way to get the total latency? 

below is my print info

Hello

DVR RDK 3.0 do not have proper hooks to measure the end to end latency.  Please use RDK 3.5, where capture insert time stamp for each frame when it is getting captured.  IpcBitsIn (HLOS) is the A8 side link receives the encoded frames. You can call the Ay syn API Avsync_getWallTime() and this gives the current system Time.

now the latency is

latency = ((UInt32)(Avsync_getWallTime()) - pInFrame->timeStamp);

regards, shiju

Shiju,

     I come to ask you some other question.

     I want to change the bufsize or the bufnum of the buflist, in order to change the total latency.  Could someone tell me if  the size can be changed on M3 or not?... If it can be changed, how should I do?...

Shun

can you elaborate on how do you plan to reduce the latency be reducing the buffers size? Do you think for slice based display  if yes, it is not supported by both display link and display driver. Number of buffers or the disply queue depth can be contolled at build time

regards, shiju

shiju,

    my chain is cap+nsf+enc. I want to reduce  the total latency by reducing the buffer nums of each link. could this be available? 

 you told upstairs that the display queue can be controlled at build time. Do other link queue can be controlled at buile time, and how to do?

Hi

For all the links that your are used in your chain (such as Cap, NSF and enc) you could specify the number of output buffers in the use case file. RDK only picks the default value if this is not specified

regards, shiju

Shiju,

where is the use case file. could you tell me the directory and a way to change some usecase file... I don't know where and how to specify my number of ouput buffers.

Could you tell me a little bit more of that? 

Thanks!

Shun

Shiju,

could you tell me the directory and a way to change a usecase file... I don't know where and how to specify my number of ouput buffers.

Could you tell me a little bit more of that? 

Thanks!

Shun

Hi,

DVR RDK demo usecase files are under dvr_rdk\mcfw\src_linux\mcfw_api\usecases\ directory.  For example see the file multich_progressive_4d1_vcap_venc_vdec_vdis.c under

vr_rdk\mcfw\src_linux\mcfw_api\usecases\ti810x

in this file you could see

capturePrm.numBufsPerCh = NUM_CAPTURE_BUFFERS; - To set the number of capture link output buffers

nsfPrm2.numBufsPerCh = NUM_NSF_BUFFERS; - To set the number of NSFlink output buffers

deiPrm.numBufsPerCh[DEI_LINK_OUT_QUE_DEI_SC] = NUM_DEI_ENC_BUFFERS; - To set the number of DEI link output buffers

encPrm.numBufPerCh[0] = NUM_ENCODE_D1_BUFFERS; - To set the number of ENC link output buffers

encPrm.numBufPerCh[1] = NUM_ENCODE_CIF_BUFFERS; - To set the number of ENC link output buffers

decPrm.chCreateParams[i].numBufPerCh = NUM_DECODE_BUFFERS; - To set the number of DEC link output buffers

regards, shiju

Shiju Sivasankaran said:

capturePrm.numBufsPerCh = NUM_CAPTURE_BUFFERS; - To set the number of capture link output buffers

nsfPrm2.numBufsPerCh = NUM_NSF_BUFFERS; - To set the number of NSFlink output buffers

deiPrm.numBufsPerCh[DEI_LINK_OUT_QUE_DEI_SC] = NUM_DEI_ENC_BUFFERS; - To set the number of DEI link output buffers

encPrm.numBufPerCh[0] = NUM_ENCODE_D1_BUFFERS; - To set the number of ENC link output buffers

encPrm.numBufPerCh[1] = NUM_ENCODE_CIF_BUFFERS; - To set the number of ENC link output buffers

decPrm.chCreateParams[i].numBufPerCh = NUM_DECODE_BUFFERS; - To set the number of DEC link output buffer

Hi Shiju

      This is John.

      I have a brief question.

      I'd like to know will the "Buffers number" of those links ( cap / nsf /dei / .etc ) effect / introduce the latency from capture to screen displaying?

Hi Shiju,

     I just tested with the simple chain ( cap -> display ).

     The captured frame & display configuring are 1080p@60.

     I feel there is no much difference in total latency when I changed capturePrm.numBufsPerCh between 6 <-> 13.

     Is that result matches your expectation?