On 3/3/2012 12:21 PM, Ali C. Begen (abegen) wrote:
Stored or live, that is a separate discussion but in the case of streaming of one-way content, the crucial thing is the tolerable delay not whether the content is pre-encoded or live.
To my way of thinking, the one-way case can usually tolerate delays of several seconds (see the "wardrobe malfunction buffer" used in the SuperBowl, for instance). I see this as out of scope for this set of Yes, that was my point. But, in your definition of "real-time" such buffers are not acceptable. That is why I thought making it clear would be appropriate in the title and text. Both are real-time media but interactive one has a delay budgets which are far less.
True.
requirements (although it's not unlikely that solutions we come up with here can be applicable to this use case). I am a bit skeptical about this. The one-way streaming that can tolerate seconds of delay needn't be as reactive to congestion or rate changes as the two-way conferencing apps. Time scales are quite different. Some tools/methods will of course be similar but they will not necessarily be identical or directly applicable.
One-way typically can tolerate lots of delay (and may want delay to locally buffer), but some "one-way" is actually interactive delay-sensitive - for example, remote surgery (and any sort of tele-operation). -- Randell Jesup randell-ietf@jesup.org