About NetStreamInfo

[Guest]

Hi,

Publisher ----- 1 -----> red5 (receive) ----- 2 -----> red5 (send) ---- 3 -----> Subscriber

* unbffered mode (bufferTime = 0)

How can I measure real delay times of 1, 2 and 3 ?

Can I do it using NetStreamInfo ?

If yes, could you explain what properties and how to calculate.

If no, can you give me some advice ?

Thanks in advance.

[sinious]

On the Flash side you know you have SRTT for an overall value (if RTMFP) but the specific numbers might require a server side solution:

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/NetStreamInfo.html#SRTT

I think the best you're going to do is check events as they roll in, measuring each event (start to connect = #1, connect to receive = #2 + #3).

To actually get #2 you might have to be on the Red5 side in logs. You can see in the manual they're implementing ping in multiple variants, one being to measure network delay between server and client (page 143), which can give you just #3, but again is server-side:

http://www.red5.org/downloads/docs/red5-reference-1.0.pdf

[Guest]

Thanks for your helpful information.

I believe you're right.

One more question to clear about NetstreamInfo.

What's meaning of liveDelay value ?

(unbuffered mode, RTMP)

In document, it is buffer length in subscriber's stream.

It can be also #3 ?

And liveDelay has some relation with droppedFrame?

Thanks.

[sinious]

I think you mean NetStream.liveDelay and yes that can be useful, to some extent, to tell you about #3. The docs are confusing because it reads like 2 different things, but the first sentence in the description is accurate (the second sounds almost like a latency meter). It's the number of seconds behind the user is from being "truely live".

In video chat it's very important because anything beyond around 2 seconds starts to become frustrating and very noticable. Also you mentioned you're using RTMP which uses TCP (no packet loss). Do note that RTMFP uses UDP and dropping packets/frames is usually much more desirable to keep the delay down.

If you're broadcasting anything other than live video chat it's not a huge deal if the liveDelay gets up to even 9 seconds. However around there I'd be suspicious of the users connection being slow and that would trigger me to re-establish a connection at a lower camera quality to reduce bandwidth.

Of course for live Red5 should be allowing you the property rtmp.tcp_nodelay=true.