[vorbis] Re: Website for Ogg/Vorbis support for MPEG4IP

[Akos Maroy]

Mark Hetherington wrote:
> Ok, fair enough, but doesn't icecast just rebuffer if it gets too far behind? 
> Or is this the problem? Could icecast be modified to just send UDP packets? 

The problem is at the transport layer level. Say you have a 24 kb/s 
stream. Then you send 24 kbits / second (obviously). But if the 
connection gets stuck for some reason, then you start to build up the 
amount of data to send. E.g. if you have a 1 second drop in the 
connection, then you immediately have 2 * 24 kbits to send the second 
after, another 24 kbits the second therafter, etc. Given a 32 kb/s modem 
connection, it would look something like (in a most optimistic point of 
view):

0. second: dropout
1. second: 2 * 24 kbits = 48 kbits,
            but only 32 kbits gets through,
            16 kbits remain
2. second  16 + 24 kbits = 40 kbits,
            but only 32 kbits gets through,
            8 kbits remain
3. second: 8 + 24 kbits = 32 kbits,
            all 32 kbits get through

and the "normal" streaming resumes.

All this happens at the TCP/IP stack level, and the question is: will 
the stack drop the connection because of the amount of data that has to 
buffer in the stack. Also, resending is very expensive, as basically you 
send and send, wait for acknoledgement for a while, then start to resend 
if you didn't get the ack. (Thus the above is a very optimistic scenario).

This usually looks like:

0. second: send new data: 24 kbits
            store sent 0. sec data in the stack buffer
1. second: send new data: 24 kbits
            recieve ack for 0. sec 24 kbits
            clear 0. sec 24 kbits from stack buffer
            store sent 1. sec 24 kbit data in the stack buffer
...

<p>now if something goes wrong, and the stack waits 2 secs before a resend:

0. second: send new data: 24 kbits
            store sent 0. sec data in the stack buffer
1. second: send new data: 24 kbits
            no ack recieved
            store sent 1. sec 24 kbit data in the stack buffer
            stack buffer holds 0. and 1. sec data (48 kbits)
2. second: try to resend, start from 0. sec data (2*24 kbits)
            send new data: 24 kbits
            store new 2. second data in stack buffer
            stack buffer holds 0., 1. and 2. sec data
            (3*24 = 72 kbits)
3. second: ack recieved for 32 kbits of 0. and 1. sec data
            send new data: 24 kbits
            clear 32 kbits from stack buffer (0. and 1. sec data)
            store new 3. sec data into stack buffer
            stack buffer holds 1. (16 kbits), 2. and 3. sec data
            (64 kbits)
4. second: ack recieved for 32 kbits of 1. and 2. sec data
            send new data: 24 kbits
            clear 32 kbits from stack buffer (1. and 2. sec data)
            store new 4. sec data into stack buffer
            stack buffer holds 2. (8 kbits), 3. and 4. sec data
            (56 kbits)
5. second: ack recieved for 32 kbits of 2. and 3. sec data
            send new data: 24 kbits
            clear 32 kbits from stack buffer (2. and 3. sec data)
            store new 5. sec data into stack buffer
            stack buffer holds 4. and 5. sec data (48 kbits)
6. second: ack recieved for 32 kbits of 4. and 5. sec data
            send new data: 24 kbits
            clear 32 kbits from stack buffer (4. and 5. sec data)
            store new 6. sec data into stack buffer
            stack buffer holds 5. and 6. sec data (40 kbits)
....

it takes quite a while for the stream to catch up with real time. If at 
any point the TCP/IP stack gives up (say it doesn't want to hold that 
much data in the stack buffer), then the connection is dropped.

The main problem here is with live streams, as rebuffering doesn't help 
you much: you have to keep up with the real time stream.

<p>Akos

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.