IMHO, I believe this should be a user interface setting, and a clients
decision as to if they want high latency or not. In my scenario - we
have huge pipelines and a dedicated network for this application, and
require little to no skip protection.
Keep up the great work.
Pash
--------
On Monday, January 13, 2003, at 03:40 AM, Billy Brown wrote:
QT Broadcaster and QTSS is not intended for use where low-latency is
required, and as such will not suit your purposes if you are needing
to communicate with zero-latency in real-time. The reason for this is
fairly simple. When you reduce the latency to the bare minimum
"cutting edge", then if there is any drop outs or packet-loss there
just isn't enough time (buffer/latency) to properly deal with
retransmitting the missed packets. When streaming over the Internet
you're constantly sharing bandwidth with everyone else. In general,
TCP/IP does not guarantee real-time packet arrival times, but rather
aims towards data integrity (even if that means retransmitting a
packet again and again). UDP on the other hand normally doesn't have
retransmits. However, with QTSS 4.x we implement our own form of
"reliable" UDP and are able to do retransmits between the Server and
QT Client in the event there was any packet-loss occuring.
QTSS provides great quality of services (QOS) through its Skip
Protection features - which includes not only Instant-on buffering of
movies (on-demand and live), but also overbuffering and Skip
Protection for live reflected streams.
What this means is that in addition to any original latency in the
compressed video stream, QTSS will then automatically add up to 10
seconds of overbuffering "latency" to the stream so that each
individual QuickTime player client (watching the stream) will receive
the best quality available - even if network conjestion or packet-loss
occurs due to spikes or for short periods of time. The Skip
Protection going on between QT Player and QTSS will then have enough
time to hopefully retransmit any missing or lost data so that the end
result is that the person actually watching the stream doesn't ever
see or notice packet-loss occuring. All of this negotiation happens
automatically between a QTSS 4.x server and QT5 or QT 6 player (QT 4
did not support Skip Protection).
The benefits to this is that if there is a minor drop out or momentary
spike in the data, QTSS and the QT Player client are able to negotiate
any retransmits so that the end user never looses any frames and the
stream continues to play to the end-user just fine. This type of
Quality of Service a trade-off between having a modest buffer (10
seconds or so between client and server), vs. no buffer at all - but
this would risk packet-loss interferring with your stream with no time
for recover or retransmits to help.
--
Billy Brown
On Friday, January 10, 2003, at 11:42 AM, Edward Premus wrote:
Help before I get the axe.
We are trying to use the Quicktime broadcaster to stream live video
to several sources across the internet. However it becomes
ineffective when even over the local lan we have a 20 second latency
time. How can we get rid of the latency problems if people have to
communicate in real time or is it just impossible? This must be high
quality video and would like to make it highly available (from the
dell commercial).
Thanks,
Ed
_______________________________________________
streaming-server-users mailing list |
email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/streaming-server-users
Do not post admin requests to the list. They will be ignored.
