[Red5] New Bandwidth Control Code is committed and documented

[Steven Gong]

Jerky video is better than no video at all. If you are in a video conference
and your bandwidth is limited, I think the best result is you still can hear
others talking and see some of the motions of others.

On 3/15/07, Dan Rossi <spam at electroteque.org> wrote:
>
> Hi Steve
> >
> >
> > A simple usage model might be:
> > In a live meeting session, when the bandwidth limit is low, you might
> > want
> > to bias the audio against video. So you could set the bandwidth of
> > video to
> > a low value (so that video will look jerky). And the audio sounds just
> > fine.
> I read the FMS speeds up the audio to keep up with video or something
> like that when its being slowed down. I dont think jerky video is the
> expected output at all, its what currently happens, ive tried everything
> to get a nice smooth rate without frames being dropped. I did notice
> that a quality setting minus 80 works better than 90-100 but its too
> blocky to be useful. We're trying to live stream at 240x180 video size
> though which was ok for windows media streaming via the encoder. I dont
> think jerky video is of much use for vod streaming also.
> >
> > There're many other usage models. You can also contribute your own
> > here. I
> > just provide a framework to make them feasible.
> >
> Ill have to spend time to test things out, i wonder if the server can do
> dynamic buffering if not enough video data is being pushed out ?
>
>
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
>



-- 
I cannot tell why this heart languishes in silence. It is for small needs it
never asks, or knows or remembers.  -- Tagore

Best Regards
Steven Gong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20070315/1b73175c/attachment-0001.htm