DEI Links instances

Hi Brijesh,

Thank you very much for the reply. Just one more thing if I'm allowed. Is there any purpose for limiting number of instances of DEI or other Links ? In the tutorial I find that "All links can be instanced multiple times except  capture, encoder, decoder" ) ?

Thanks,

Ran

Hi Ran,

This mainly depends on the usecase, memory requirement and type of link. As you know, capture and display links can not be opened multiple times since they operate on a real time ports, which cannot be multi instantiated. whereas DEI, which is a memory to memory operation, can be multi instantiated.   

Thanks,

Brijesh Jadav

Hi Brijesh, Hardik,

Adding more instances of same Link means added memory requirements, but I would like to understand what is the price of added instance in terms of performance.
Is it right to assume that 2 instances of DEI, will result in doubled effective time delay in performance, for the worse case, such that if the time delay for now is ~10msec in DEI, adding another DEI instance will result in 10x2=~20msec effective time delay in the peak worse case (I assume the  average will still be closer to 10-15 msec, because DEI will also have idle time ).

Regards,

Ran

Each link instance will be an independent thread. I am not able to understand your comment about "adding another DEI instance will result in 10x2=~20msec effective time delay in the peak worse case". We are eventually limited by the IP bandwidth. For example on 816x with DSS @ 280  Mhz, DEI can theoretically operate on 280 mega pixels / sec . This is ignoring all overheads which is not the realistics case. So the total available IP bandwidth will be shared by all the link instances.

Hi Badri,

Let's assume we're dealing with HD 1920x1080 frame. If we use 1 DEI Link , 280M pixel/sec -> it takes ~7msec to process this HD frame.
Now let's use two instances of DEI, as you say all instances share the same IP resource, this means each gets 140 Mhz, now we get that for the same HD frame it takes ~14msec , twice time delay then before.

Thanks, Ran

>So the total available IP bandwidth will be shared by all the link instances

As I understand, this mean that the delay time in the Link might be doubled at worse case (when both link need frame process at the same time). As an example, for HD, 1920x1080 it will take 14msec instead of 7 msec.

Thanks, Ran

This is correct but the delay due to IP processing time will be present whether multiple links are used or a single link is used. To take your example,.let us say there is a single DEI link instance.It is currently started processing a HD frame. The next HD frame cannot be queued for processing in the link for another 7ms approx.So the next HD frame will experience delay of 7 ms (previous frame processing time) + 7 ms (current frame processing time). Maybe I am not understanding your concern.Does your application require very low latency ? If so you can consider slice based processing. Slice based processing is supported in most hdvpss drivers (except DEI and display). The McFW links dont support slice based processing and will have to enhanced to support this feature.,

Slice based processing is supported in most hdvpss drivers (except DEI and display)

How long does it take from the time a complete frame is ready for display, before the data appears on the HDMI port?

I want to use the compositor to overlay data (Which I think happens when the HDVPSS sends data out to the HDMI port).

Oliver

Hi Oliver,

It depends on lot of other factors, like slice size, number of slices, number of modules used from capture to display, individual module requirement. Depending on all of these factors, we could calculate the time it takes for the complete frame to reach to the display.

Rgds,

Brijesh Jadav

Brijesh,

Thank you for getting back to me.  I am concerned about some numbers we have seen for displaying images after the H.264 decode has been completed.  You said,

It depends on lot of other factors, like slice size, number of slices, number of modules used from capture to display, individual module requirement. Depending on all of these factors, we could calculate the time it takes for the complete frame to reach to the display.

It would be really useful to have a formula, but I have not seen one in the TI literature for the RDK.  Here is an example

Assume slice size < 10K worst case

There are 17 slices in total

I am note sure what you mean by the number of modules.  I am trying to estimate the the time after we have H264 decoded, and converted to 4:2:2, how long it takes to display the data with a an overlay (compositor).  If you have a formula it would be really useful to know it. However here is our planned flow:

a) Capture 1080P60

b) 4:2:2 -> 4:2:0

c) H.264 encode

d) Ethernet transport (100Mbits we have good latency numbers for when this is in on our network)

e) H.264 decode

f) 4:2:0 -> 4:2:2 (we think the HDVPSS needs this)

g) Compositor with alpha blending

h) Output to HDMI

The encode and decode occur on different processors on different boards.  We are looking to use an 81XX for both the encode and decode.  We have a 100Mbit link between the two boards.  What we want is low latency between both boards.  We are really concerned with the time on steps g and h.  There is not a lot of documentation on how long these two steps take.

Oliver

Hi Oliver,

I was asking about slice size and number of slices per frames.  As such, there is no standard formula, you will have to calculate it based on slice size, number of modules, module requirements etc.

Number of modules here means what all HDVPSS modules you are using, what all other component come in the pipeline.  Each module can have different requirement like to operate in slice mode for the scalar, it requires couple of extra lines at the top and bottom of the frame, so it requires some pertion of the previous as well as next slice. So even if first slice is available, we could not start processing in the scalar, we have to wait for the second slice to get completed and start processing for the first slice.

There will be other variable delays like delay in the network.

Rgds,

Brijesh Jadav