[DM385] Video Streaming Latency

Michael,

You need to look in to IPNC RDK (for 1080p30 capture+encode+stream) and DVR RDK (for decode+display). These are the two packages which would fullfill your customer's requirements. You can search for links to this releases in this forum itself. DVR RDK would be for their reference to see how decode + display would work, complete package (with GUI) is released by UDworks in case of DVR and NVR both. Customers can order the DVR/NVR boxes and get access to these packages through UDworks.

As far as it is single channel 1080p30, I think there should be no performance issue on either side. If you provide details of your customer's usecase if would be easy to analyze and  provide numbers. Please provide more information on  platform to be used on IPNC side, number of encode streams, type of encode, bitrate and on receiving side, platform to be used, number of channels (if they plan to connect mutiple ipcams), resolutions, decode types & number of displays. We do not have concrete numbers on network latency formally available yet. 

Yogesh,

Thanks for the reply!

My customer's only gating specification is the latency.  Do we have any worst case numbers, i'm fairly confident that they'll be under 150ms.

Thanks,

Michael,

I beleive there should be no latency problem in this case. DM385/DM8127 on streaming side and DM8107/DM8147 on receiving side should be able to meet the requirement if it is single channel 1080P30 over base 100 ethernet. Infact you can as well evaluate DM36X for streaming out 1080P30.

I will let experts comment on worst case numbers.

Raghu, Can you please comment on what DM8127 can do on streaming side?

Shiju, Kindly comment on 8107 NVR performance with GUI on receiving side.

Hello,

On IPNC side, for 1080p30 streaming the latency observed was arround 150ms, details are in the datasheet shared in the release

Regards,

Raghu

Hi Raghu,

I have an IPNC release and while i've managed to find the use-case descriptions in the Requirement_Centaurus_IPNC_RefDesign_0.3.pdf I haven't been able to locate any of the latency information.  Can you point me to the correct document?

Also, the 150ms latency number that you are speaking of is on the hairy edge of what they are looking for.  This is ok, if it is the worst case.  Can you break that number down a bit further. Does it include encode/transport (10/100 or 1000) /decode? Is it equally distributed if not which step take the longest? Does the above number include any parallal image image processing?

This will be used for steering an underwater vehicle, so latency has been their largest concern.

What is the DM385's operating point to acheive that and can it be speed up?

Thanks for your help!

Hi again Raghu,

I just received an update from my customer.  It appears that they changed their specifications.

They are now interested in a single 1080p60@60fps.  This is double the previous frame rate.  And they have lowered the total econde and decode time to 70ms.  Is this feasible?  And if not what are reasonable encode/decode latencies.

Thank you and sorry for the sudden change.

Hello Micheal,

The latency we measured is on the IPNC usecases.

Looks like you need encode+decode with 70ms for Video Conf type of application

To get low as 70ms , we might need to suport slice based encoding which is not supported in IPNC codebase .

Can you check if any VC RDK supported this low latency usecase

For IPNC, we have 150ms and this meets the IPNC requirement.

For lower than this, slice based is required.

Regards,

Raghu

Raghu,

Thanks for your help so far.

My customer is in a holding pattern trying to figure out the feasibility of this design.

So far it looks like the DM385 will not meet the needs in terms of latency.  They have experience with the DM8148 and are considering using an DM8168 to split the video into two stripes (using an FPGA) which will be treated as two 2 separate video feeds (30fps + 30fps).

Would that enable them to meet the 70ms latency requirement? 

Also, i haven't been able to find where in the documentation these latency numbers are described.  Could you tell me which document there found in?

Thanks,

Yogesh/Raghu

After reviewing the latency documentation.  My customer has two additional questions.

1. Is there a simple explanation for why the Scalar/Chroma Conversion and Display Delay is so much longer then the decode?  Is this due to having to memory translation from one space or cache to another?  Also can this be accelerated using the V-DAC or other means.

2. Why do the latency numbers increase for 1080p30 as compared to 1080p60.  One would expect it to go down as there are half the frames.

Also, can we move this thread to the public forums?

Thanks,

I think if Raghu confirms there is not confidential information in this thread we can move this to thread.

Yogesh,

you can move it to external forum, and check if any VC folks and take the low latency query

Regards,

Raghu

Hi,

with 1080P60, on DM8168, we got ~100msec's latency with this chain: 'Capture-->SC-->ENC-->Ethernet->Decode->SC->Display chain"; If your application always runs at only 1080P60, then both SC's can be removed, which saves 2 frames latency (~16msecX2). so, it should come around 70 msec's. If  sub-frame based mode is used in all components, Latency can be further reduced. sub-frame mode is supported at component level, but not at framework level. So, it involves considerable effort.

Regards,

L K Reddy

Reddy,

Thanks for the reply! 

Yes there will be no scaling involved.  The video will be captured at 1080p60 and displayed the at 1080p60 on the receiving side (potentially 1080p30).  Will lowering the framerate to 30fps on the receving end effect the latency? Was this not the case when the latency numbers were recorded? Do those numbers include white balancing and RGB2RGB color conversion pipelines or were those modules bypassed?

Also, i'm not familiar with the "sub-frame mode" is that supported by the Low Level HW API?  Is there documentation in the DVR-RDK that describes that functionality.  

Mike,

With 1080P30, latency will almost double, as it is in number of 'frame duration's' (i.e 33.33msec for P30 and 16.67msec for P60). Typically capture(1 frame)-->Enc(1 frame)-->stream(few msec's, depends on network)-->Decode(1 frame)-->Display(1-3 frames) = 4-6 frames.

For Capture, the number I quoted are with in DM8168, with external HDMI camera with VIP input. For DM385/814x based camera, I don't know exact numbers. But it should be possible to get it 1 frame, with basic ISP functions like AWB, RGBtoYUV conversion.

subframe mode is supported in HDVPSS drivers and H.264 Codec. You can refer to 'User Guides' in respective packages under ti_tools of RDK.