similar to: Faststart: Second Try

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: :-) -rw-r--r-- 1 gallir gallir 5486 2003-01-21 01:29 update3c.diff -rw-r--r-- 1 gallir gallir 10014 2003-01-19 20:14 update3b.diff -rw-r--r--

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

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, 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 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 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,

-----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

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

-----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

> |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

One thing I noticed though when reading about ffmpeg to make the h.264 was that for internet, you could use qt-faststart to move some stuff (I think called MOOV) to the front of the file allowing the file to start playing before it was finished downloading. That certainly helps quite a bit, I was wondering if there is a similar type of thing for theora? Theora files I host do not seem 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

Hi all, Sorry if this has been answered previously, but I have not had any luck trying to find it. I am trying to connect my Asterisk server (1.0 stable, Fedora Core 2, kernel 2.6.8-1.521) to connect to a gateway that can only support H323. I have installed the asterisk-oh323 channel driver (version 0.6.3b) using Open H323 1.13.5 (patched as per asterisk-oh323's instructions) and PWLIB

Hello, I have installed oh323 channel driver. Outgoing calls to H.323 world do not include RFC2833 in the outgoing TerminalCapabilitiesSet despite that userInputMode=RFC2833 has already been set. Does anyone know how to make RFC 2833 DTMF relay work over oh323 channel? Kind regards, Fernando Herrera _____ De: Fernando Herrera [mailto:fherrera@iplan.com.ar] Enviado el:

-----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

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

On Monday 10 February 2003 13:25, Michael Smith shaped the electrons to shout: > If it takes this long, then there's something else wrong. It should be > well under a tenth of a second (and probably closer to 1/100). No, nothing wrong, at least darkice is doing very badly. With darkice as encoder at about 30 kbps, there are about 3 buffers per second, which mean that in the worst

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

Update on this problem: I gave up on the "native" h.323 because, like others, I couldn't get audio working. (yes, I tried disabling FastStart in ast_h323.cpp - no change) So I went and got the OH323 code from www.inaccessnetworks.com. Glad to say that everything seems to work so far. Not only does audio work, but even the handshaking is now working in both OpenPhone and even

I am trying to determine the optimal filesystem for accessing large numbers of files (25,000+) in a single directory. I have read that ext3fs uses a sequential search algorithm and wanted to verify that this was still indeed the case since this article was published a year ago. http://bulmalug.net/body.phtml?nIdNoticia=1154 <http://bulmalug.net/body.phtml?nIdNoticia=1154&nIdPage=7>