Hi,
find enclosed a patch to implement faststart (or prebuffering).
Basically, it stores a number of "refbuf"s, configurable by seconds.
When
a new client connects, it adds the prebuffers to que clients' queue so
they are delivered as fast as permitted by the connection. As result, the
players prebuffers are filled up faster giving a better "response".
I tried to minimise the impact, both in source code and execution. If
faststart is configured to zero, it has also zero impact in the
execution. If you don't feel very comfortable with the change in the
behaviour, you can change the default value to zero
(CONFIG_DEFAULT_FASTSTART).
Hope you like it.
Regards,
--
ricardo galli GPG id C8114D34
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update3.diff
Type: text/x-diff
Size: 6309 bytes
Desc: update3.diff
Url :
http://lists.xiph.org/pipermail/icecast-dev/attachments/20030118/8c00f73c/update3.bin
On Sunday 19 January 2003 08:09, Ricardo Galli wrote:> Hi, > find enclosed a patch to implement faststart (or prebuffering). > > Basically, it stores a number of "refbuf"s, configurable by seconds. When > a new client connects, it adds the prebuffers to que clients' queue so > they are delivered as fast as permitted by the connection. As result, the > players prebuffers are filled up faster giving a better "response". > > I tried to minimise the impact, both in source code and execution. If > faststart is configured to zero, it has also zero impact in the > execution. If you don't feel very comfortable with the change in the > behaviour, you can change the default value to zero > (CONFIG_DEFAULT_FASTSTART). > > Hope you like it. > > Regards,There's a bad interaction here between the predata and this faststart. Suppose we have two logical streams (A and B), and the stream has just recently got to logical stream B. Now, this means the fast start queue contains the end of stream A, then the stream B headers, then the start of stream B audio data. So, we send to the client: predata (stream B headers) faststart (stream A data, stream B headers, stream B data) Which is a corrupt stream. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Sunday 19 January 2003 03:35, Michael Smith shaped the electrons to shout:> There's a bad interaction here between the predata and this faststart. > Suppose we have two logical streams (A and B), and the stream has just > recently got to logical stream B. Now, this means the fast start queue > contains the end of stream A, then the stream B headers, then the start > of stream B audio data.Good point, I didn't think about this case (i'm streaming radio with just one logical stream).> So, we send to the client: > predata (stream B headers) > faststart (stream A data, > stream B headers, > stream B data) > > Which is a corrupt stream.Could be solved checking it before adding the fastart buffer to the client. Because the checking is done just once for the client, it shouldn't be expensive. The comparison could be (just for vorbis, mp3 has not predata): 1. Comparing the serialno of the current predata and last faststart buffer. The comparison could be done when a client connects or every time it add a new buffer to the faststart queue. 2. Storing the last predata sent to a client against the current one (less "precise"). <p>If you agree, I can fix it. ¿How would you implement/hide it to lower layers? ¿Add a "plugin->get_serialno" in format_xxx.c and then do something like "if (source->format->has_predata) -> ... source->format->get_serialno(refbuf); ..." for example? <p>PS: this can be also used for selectively dropping packages, altough I just read it doesn't seem to be interesting :-) -- ricardo galli GPG id C8114D34 --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.