From: Steve Mack <[EMAIL PROTECTED]>
Subject: SMIL power

Hey Remo -

Your hunches are absolutely right. Once the background is in, the pipe
opens back up.

34kbps is quoted as the optimal bitrate for 56k modems because they
generally connect at 33.6 - 40kbps. This doesn't mean the presentation will
be stable at all times if you author at 34k; it means your chances are
greatly improved. And if the viewer's bandwidth drops below 34k, they will
merely experience some rebuffering or the video will drop down to the next
lower surestream rate.

Bearing this in mind, here's what I'd do:

1) Since the background comes in on it's own, it can take up the full 34k
to start with. This will make it download much quicker, so the rest of the
presentation should start sooner. You can accomplish this by altering the
bitrate in the .rp file or by bringing it in as a direct reference in the
SMIL file.

2) Now that the backgournd is 'frozen' into place, your full 34kbps are
again available to you. If your slides only require 3.6kbps, then you have
30.4 bps left over for the A/V. I might drop that down to 28kbps for
safety. Remember, the lower your bitrate, the better chance it is going to
play without interuptions.

So your SMIL code should look roughly like this:

<par> <!-- always start with a par group to set your master timeline -->

        <seq> <!-- we bring in the background FIRST, then the rest, so we use seq -->

                < your background, either in .rp format or just brought in directly in
the SMIL >

                <par> <!-- now you run the slides and a/v in parallel -->

                        < your a/v >
                        < your slides >

                </par>
        </seq>
</par>

make sense?

s.

At 04:22 AM 12/10/99 -0800, you wrote:
 >From: Remo Jin <[EMAIL PROTECTED]>
 >Subject: Video Quality/ Bandwidth Questions

 >Current Presentation Specs:
 >Real Pix - (Background 1) : 6.0 Kbps
 >Real Pix - (Slides) : 3.6 Kbps
 >Video & Audio : 24.4 Kbps
 >
 >Total Required Bandwidth: 34 Kbps
 >* Equal to the suggested max. bit rate
 >
 >Timeline of my presentation:
 >0 - 20secs :
 >      - Background Image appears.
 >20s - end :
 >      - Background image changes at the 20sec mark and stays
 >      constant till the end.
 >      - Video starts at the 20sec mark, plays till end.
 >      - Throughout this segment(20sec - end) , images (ie: slides)
 >      are replaced at certain times corresponding to what is said
 >      in the video.
 >
 >Q1: When a my stream is opened it currently streams at 34 Kbps.
 >However, if an image like the second background is only required once
 >and stays constant throughout the presentation, can the 6.0 Kbps
 >stream (allocated for that particular Real Pix stream) be used by the video!?
 >
 >Q2: If so, does it mean that in my case, the video can be encoded higher
 >than 24.4 Kbps, to utilize the bandwidth not used by other streams!?
 >
 >ie: my video can now be encoded at:
 >      24.4 Kbps + 6.0 (unused) Kbps. = 30.4 Kbps !?
 >without worrying about not having enough bandwidth, and cause it to
 >crash!?
 >
 >Q3: Does the max. suggested BitRate of 34 Kbps, (in the real player docs)
 >mean that as long as you ensure your not streaming more than 34 Kbps
 >at "any one time" during the presentation, the stream will be stable!?
 >
 >Q4: Does the total size of the stream (indicated in the bottom left in
 >the green real player controls) really matter!?  Or as long as at any
 >point your not trying to exceeding the max. target bit rate of 34.0 Kbps.
 >the presentation will be stable (not crash)!?
 >
 >- - Remo
 >


*******************************************************
The RealForum is an email discussion group focused on using RealNetworks
products. The RealForum is a place to post messages about the best methods
for creating content using RealNetworks technologies and the planning and
implementation of streaming-media web sites.  Archives of RealForum can
be found at http://realforum.real.com

If you ever want to remove yourself from this mailing list,
you can send mail to <[EMAIL PROTECTED]> with the following
command in the body of your email message:

    unsubscribe realforum

or from another account, besides the address you subscribed with:

    unsubscribe realforum <[EMAIL PROTECTED]>

Reply via email to