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.
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.
Now that we're probably clear on what we are talking about, how should we express this to get the right understanding at the reader?
Some wording in the intro section could help with this. Thanks. -acbegen