similar to: PATCH: Faststart Try 3

On Tuesday 21 January 2003 10:38, Michael Smith shaped the electrons to shout: > This is much improved. There are a few things to clean up (comments, > for instance, since we're not targetting C99), plus actually writing > the generic implementation for get_predata() (which at the moment only > mp3 will use), but the design looks fine. I'm unlikely to have time to Hope you

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

Hi Mike, find the patch for faststart that takes in account different logical streams. I tried with ices' playlist, it works just fine [*]. I could be still further optimised, but it will make the code less clear (for example, I could check for has_paredata before checking for serailno, which saves a couple of calls and also will avoid any change in format_mp3.[ch]). <p>[*]

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

On Tuesday 21 January 2003 11:37, Ricardo Galli wrote: > Hi Mike > Find enclosed the patch with the fastart implementation for vorbis (for > the moment). > Now is based on size in bytes and the buffers are sent all together with > pre_data. > > Hope you like it. At least is the smallest one: :-) Ricardo, This is much improved. There are a few things to clean up (comments,

I must use Windows for Streaming. and the interface must be an port or something else, because the software interface runs on a dedicated server. ----- Original Message ----- From: "Ricardo Galli" <gallir@uib.es> To: <icecast-dev@xiph.org> Sent: Wednesday, February 25, 2004 10:10 AM Subject: Re: [icecast-dev] I need a Freelance Coder... <p>> On Wednesday 25 February

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Huh, why not just use ices with a perl song choser module ? This eliminates the need to develop the libshout based streamer (use ices instead) and give ices the title from your module, ices will take care of the rest. Or I am wrong ? :) On Wed, 25 Feb 2004, Renaud Waldura wrote: > For what's it's worth, I do something similar to this

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mike, I think you dealing with the development. Almost a year ago I've sent few patches to Jack, several of them are already applied to the current version. I'm back again, and tested the last version. I noticed it isn't as resilient to network congestion as my last patched version (just disconnect the ethernet cable of

On Friday 20 February 2004 00:09, Renaud Waldura shaped the electrons to shout: > 1- this is such a stoopid question I should be ashamed of myself -- > RTFM > > 2- this is a well-known issue that everybody's aware of, it doesn't > need further discussion thank you, as it is actively being worked on > > 3- it is meant to be that way and will not change. No, if you

On Saturday 18 January 2003 03:37, Michael Smith shaped the electrons to shout: > We can't just drop packets, the transmission model assumed by the > format handlers (and required by at least one of them) will not permit It's not vorbis. Does it? > us to drop any data. It'd be possible, in theory at least, to tag > buffers with a flag to say that they can be dropped, but

For what's it's worth, I do something similar to this with Andrew Taylor's libshout-java. The Web server manages a playlist, letting users add/remove tracks from the playlist. This playlist is consumed by a "streamer" process that accesses the audio data and pushes it to the Icecast server. [ Java Web Server ] <------> [ Playlist ] |

Is there anybody who can help my for implement a feature in icecast 2? I want to update ogg vorbis meta data album/title/genre/artist via an webbased interface. like metadata.xml for mp3 files. If there`s anybody, contact my benny@name-pool.net i would pay for this feature. thanks --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To

On Friday 20 February 2004 01:50, Michael Smith shaped the electrons to shout: > > |No, if you search old archives (almost two years ago, > > |http://breu.bulma.net/?l2480) you will see I've sent patches for > > | server buffering (fast start) and other things that were never > > | included. > > | > > |You can check the difference with

> |No, if you search old archives (almost two years ago, > |http://breu.bulma.net/?l2480) you will see I've sent patches for server > |buffering (fast start) and other things that were never included. > | > |You can check the difference with http://mcrg.uib.es:8000/live.ogg which > |run my code realiable for more than a year now. > | > |The server also had a remote DoS

On Wednesday 25 February 2004 09:50, Benny Fuchs shaped the electrons to shout: > Is there anybody who can help my for implement a feature in icecast 2? > I want to update ogg vorbis meta data album/title/genre/artist via an > webbased interface. like metadata.xml for mp3 files. If there`s > anybody, contact my benny@name-pool.net i would pay for this feature. I think it's not a

On Monday 20 January 2003 06:16, Ricardo Galli wrote: > Hi Mike, > find the patch for faststart that takes in account different logical > streams. I tried with ices' playlist, it works just fine [*]. > > I could be still further optimised, but it will make the code less clear > (for example, I could check for has_paredata before checking for > serailno, which saves a

In format_mp3.c tatic int format_mp3_write_buf_to_client(format_plugin_t *self, client_t *client, unsigned char *buf, int len) { int ret; if(((mp3_state *)self->_state)->metadata) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is always true because previously it did state->metadata = strdup("") in format_mp3_get_plugin(). It causes annoying artifacts in xmms

On Friday 20 February 2004 12:10, Ricardo Galli wrote: > > wants to send such a patch, we're happy to integrate them. I don't > > remember the DoS bug - that might be a real problem. It could be that a > > It started out with this: > > http://www.xiph.org/archives/icecast-dev/0366.html > > and I found the problem and sent the patch: > >

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry. The patch is hopely here. On Saturday 18 January 2003 03:38, Michael Smith shaped the electrons to shout: > > Hi, > > find a patch which is an update to a patch sent months ago. Before > > it was in net/sock.c, now I moved it to format.c, so net CVS module > > is not affected. It polls the socket before trying to

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, find a patch which is an update to a patch sent months ago. Before it was in net/sock.c, now I moved it to format.c, so net CVS module is not affected. It polls the socket before trying to send() any byte to check if the TCP buffers are full due to network congestion. See below the warning messages of "normal" (at least in