I can only second the below comment: a better way to balance the latency
with video quality would be great. Also, now I understand why I lost the
perfect instant on performance of just about 1/2 a second delay over our
internal network when upgrading to QTSS 4.x. Anything we can do to
avoid/reduce the latency?
Greetings, Thorkild Jensen
-----Oprindelig meddelelse-----
Fra: email@hidden
[mailto:email@hidden] Pe vegne af Pash
Sendt: 13. januar 2003 15:41
Til: Billy Brown
Cc: email@hidden
Emne: Re: latency problem
Great answer!
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.
> _______________________________________________
> 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.
_______________________________________________
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.
_______________________________________________
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.
