FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 11-05-2008, 09:54 PM
Scott Silva
 
Default Check my math please

on 11-5-2008 2:06 PM Sean Carolan spake the following:
>> The size of the file doesn't make much difference. What matters is the
>> resolution and framerate of the vide
>
> For a back-of-the napkin calculation can we not assume that data equal
> to the entire size of the file will be streamed to the client during
> playback? I understand that frame rate, etc. are important as well
> but I do not need exact figures, just a general idea of what size
> tube** is required on the viewer's side to see the video without
> skipping.
>
> ** The internet is not really made of tubes. Unless you're from Alaska.
A lot of it is.
Some of the tubes are copper, some are glass fiber.

--
MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-05-2008, 10:42 PM
Monty Shinn
 
Default Check my math please

Sean Carolan wrote:

The size of the file doesn't make much difference. What matters is the
resolution and framerate of the vide


For a back-of-the napkin calculation can we not assume that data equal
to the entire size of the file will be streamed to the client during
playback? I understand that frame rate, etc. are important as well
but I do not need exact figures, just a general idea of what size
tube** is required on the viewer's side to see the video without
skipping.

** The internet is not really made of tubes. Unless you're from Alaska.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos



Yes, you're right. You did define the length of the clip, after all...:>

I'm just use to streaming wild, not off of an existing file.

That being said, you may want to look at H.264 as a possible compression
codec. It looks pretty good. For example, on one of our streamers, we
are streaming 640x480@24fps, using H.264 compression, and seeing the
bandwidth usage fluctuating around 800kb/sec, depending on video
content. The compression setting is "best", which means lightest
compression.


(We use quicktime broadcaster to feed Darwin Streaming Server on a
Centos 5.x box.)


Sorry I didn't pay more attention to the OP. I must keep my hands off
the keyboard...


Later,

Monty
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-06-2008, 07:32 PM
Warren Young
 
Default Check my math please

Sean Carolan wrote:


For a back-of-the napkin calculation can we not assume that data equal
to the entire size of the file will be streamed to the client during
playback?


You can if you're using some of the fudge factors others have mentioned
here. The headers for IP + UDP + RTP take at least 3.5% of the
bandwidth for a network using a PMTU of 1500 bytes. If the smallest MTU
between your system and the receiver is smaller, the percentage goes up.
And, the percentage goes up anyway because those numbers only talk
about the minimum overhead. RTP headers are flexible, as are most
higher-level protocols, like TCP.


We're also ignoring any other traffic on the link. With RTP, for
instance, there are usually RTCP and RTSP channels as well. Without
these parallel data channels, the stream doesn't work.


You also have to account for retries and buffering. If your network
link is exactly as big as it has to be for the ideal case, you will
still have problems because the time it takes to deal with lost or
damaged packets comes out of your bit rate budget. There's a limit to
the effectiveness of prebuffering.


10% total overhead isn't unreasonable.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-06-2008, 11:16 PM
Nifty Cluster Mitch
 
Default Check my math please

On Wed, Nov 05, 2008 at 03:59:34PM -0600, Sean Carolan wrote:
>
> > Don't forget that the data speed != line speed.
> > A line will only carry about 70% of the line
> > speed as data because of packet overheads.
>
> Thanks for pointing this out. I believe I have enough information to
> make my case. My guesstimate before seeing the actual file sizes was
> that this would never work with less than a 2Mb/s connection, turns
> out I was pretty close!

Also compute the error recovery and lost packet detection and recovery
issues in terms of buffering. In general you want a pad and flow
control strategy. Some streams do well and others not.....

If you use a reliable stream you will depend on the protocol for error recovery.
Reliable data streams may not match your data's data structures and may require
larger buffers than an initial back of envelope computation will indicate.

see http://en.wikipedia.org/wiki/Sorcerer%27s_Apprentice_Syndrome



--
T o m M i t c h e l l
Found me a new hat, now what?

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 06:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org