RE: TT Content Buffering and Timing Scenarios

A large RealText file sent via HTTP can begin playback before the entire
file has been delivered.  The client-side element that handles the parsing
and presentation of the RealText file may decide that it has enough data
to begin displaying the text even if it doesn't have all of it yet.

         - Erik

At 11:54 PM 1/30/2003 +0000, Neil Smith wrote:

>Hi Glenn - I don't have the URL to hand, but realtext can be streamed 
>(though only through RTP, not from HTTP afaik) : RealText has 
><required>...</required> tags
>
>Tealtext manual : "Use these tags to enclose text that must be delivered 
>to RealPlayer under any circumstance. During extremely adverse network 
>conditions, RealSystem will halt the presentation if necessary rather than 
>drop the text."
>
>In practice, the bandwidth for streamed text is so low this would never 
>realistically happen from a Helix / Realserver box. But these systems 
>*definitely* stream the text too, whereas HTTP I guess will deliver the 
>whole file verbatim - I don't have a big enough example to time it :-)
>
>Not too sure about SAMI though - it seems to be a bolt-on, and is handled 
>by the player rather than the server afaik (ie, using a ?SAMI=url or by 
>adding to the media directory). Maybe I'll sniff my server logs and see 
>what the timing of requests is.
>
>Cheersn
>Neil Smith.
>
>At 20:22 29/01/2003 -0500, you wrote:
>
>
>>I should have added the following:
>>
>>In using RealText and QuickText as (potential) examples of non-streaming
>>TT content, I did not mean to imply that they were only non-streaming; I
>>believe (but am not completely certain) that they also may be delivered
>>in streaming mode; perhaps someone can confirm this for me.
>>
>>G.
>
>
>
>
>========================================================
>VideoChat with friends online, get Freshly Toasted every
>day at http://www.fresh-toast.net : NetMeeting solutions
>for a connected world.
>
>
>

Received on Thursday, 30 January 2003 19:32:45 UTC