[streaming] Q: what does CPU do when just streaming?

[Warren Young]

Anthony Loiseau wrote:
> 
> Since ages, I thought streaming was just read a file and provide it to
> an UDP socket. In this case, it should not be CPU intensive at all.

First, realize that it's not "streaming" if the server sends the file as 
fast as the network will accept it.  We call that file download, and 
it's a lot easier to do than true streaming.  Streaming a 1 hour movie 
takes 1 hour, and the bandwidth used at any given time is no more than 
needed to maintain real-time playback.  A streaming server has to know 
the bit rate of the file in order to know how fast to send it out, and 
it has to cope with things like VBR files and network weirdness.  That's 
not easy to do.

Some streaming servers will read deeply enough into the media being 
streamed to infer the bit rate of the file as they read it.  That takes 
CPU power, because media files, being highly compressed, have to be 
scanned byte-by-byte to find the needed headers.  You can buffer the 
I/O, but a bit rate scanner still has to look at every byte.

Some servers make you tell it the bit rate for each file up front.  This 
is a PITA, but it does avoid the need to scan file file byte-by-byte. 
It can just send the data out in fixed-size chunks.  This works best 
with CBR, but it can also work with VBR if you do a little prebuffering.

Other servers precalculate the file's bit rate by scanning it on 
startup.  I suspect VLM is one of these, since its startup time seems to 
be a function of the size of the VLM command file you give it.  The 
downside of this method is that restarting the server can take many minutes.

Another clock cycle sink I've noticed in VLM in particular is that it 
seems to remux MPEG files when streaming them.  Maybe it does the same 
for other file types as well.  I don't believe the underlying Live555 
library does this.  That's based on seeing files that make certain 
clients barf when streamed through VLM, which will work fine streamed 
through something else, including live555MediaServer.  If you don't need 
the features VLM adds on top of Live555, you might consider switching to 
live555MediaServer to get lower overhead and less interference in the 
media: http://live555.com/mediaServer/

Finally, few streaming applications, in my experience, use any 
OS-specific network I/O facilities.  Several OSes have special 
nonstandard kernel features that let it send data to the network more 
efficiently than with plain old BSD sockets.  When you use sockets, 
there's a fair bit of CPU overhead because you have to read each chunk 
of data into user space RAM and then send it back out to the kernel, 
resulting in several copies of the data and several kernel to user space 
transitions.  Web servers typically use these facilities because they're 
often under greater loads than streaming media servers.

Not all of these facilities are suitable for media streaming.  For 
instance, sendfile(2) on some *ix type systems violates the definition 
of streaming above.  Others are suitable, such as aio_*() on *ix, and 
overlapped I/O on Windows.  I imagine if you were to make a patch to use 
these in VLM, they'd be happy to accept. :)