[streaming] Re: Stream bandwidth limiting?

Gavin Hamill gdh at acentral.co.uk
Sun Apr 13 23:15:11 CEST 2003


On Friday 11 April 2003 03:08, Christopher DeMarco wrote:
> Hi guys... love the new work - kfir in vlc makes me happy!
>
> I see from the website that you're quoting 3-4Mbps for MPEG-2 and
> 6-9Mbps for DVD.
>
> Question #1: HOW and WHY does  the bandwidth usage vary among streams of
> a  particular  type?  Why  would  MPEG_A  use  more/less bandwidth  than
> MPEG_B?

A DVD gives you 9GB to store a 90-minute movie and maybe an hour of 'extras' - 
it costs no more to use all 9GB than it does to use only 3GB. Therefore, DVD 
authors will generally crank up the bandwidth to ensure a higher  picture 
quality.

Broadcast TV using MPEG2 will get as many TV channels at as low a bitrate as 
possible whilst keeping the picture quality 'acceptable'.. therefore the 
bitrate is much lower.  This way they pay for fewer satellite transponders.

> Question #2: What can  I do on the application side -  with vlc/vls - to
> limit the amount of bandwidth used  by a given outgoing stream?  This is
> of  course not considering  things like  Linux kernel  QoS/rate limiting
> facilities etc. - just on the VideoLAN side.

Unless you want to re-encode each stream so it conforms to a 'max bandwidth' 
you set, there's very little you can do :(

> Question  #3: If I  limit the  bandwidth available  to a  vlc/vls stream
> using kernel/network  stack tools, or  by simply running on  a congested
> network, how will  this affect the video stream as  it's received on the
> far end?   

If a stream takes on average 5Mbps, and you limit in the network to 5Mbps, 
then the stream will sometimes stutter and lose sync for a little while.. 
then it will recover again.

With regards to data loss due to network congestion, rather than simple 'speed 
limiting', It's not as simple as 'losing frames', because losing some data 
means you will screw up the whole MPEG picture sequence, and you will get a 
corrupted video stream until the next whole frame comes along and repaints 
the whole screen. This can take several seconds...

Cheers,
Gavin.

-- 
This is the streaming mailing-list, see http://www.videolan.org/streaming/
To unsubscribe, please read http://www.videolan.org/support/lists.html
If you are in trouble, please contact <postmaster at videolan.org>



More information about the streaming mailing list