Ok thanks, ill give this a try again today. Luke Hubbard wrote: > After playing with some settings I think ive fixed it, check out the > latest trunk. > Im able to stream from the states to thailand with 2s buffer without > any underruns. Joachims new buffer code rocks :) The buffer was within > 20ms of the set value. > > There are some new settings in red5-core.xml. > > <property name="sessionConfig.receiveBufferSize" value="65536" /><!-- 64k --> > <property name="sessionConfig.sendBufferSize" value="271360" /><!-- 256k --> > <property name="sessionConfig.tcpNoDelay" value="true" /> > > Thanks for reporting this problem. > > Regards, > Luke > > On 4/12/07, Luke Hubbard <[EMAIL PROTECTED]> wrote: > >> Hi All, >> >> Lets get to the bottom of this one once and for all. I'm fairly sure >> its a network issue, probably something to do with mina. I've checked >> the server when its streaming and as far as it is aware its actually >> sending the file fast enough. So for some reason slowing down going >> over the network. But this is NOT a network issue. >> >> When running those swfs you send, I get 26-32kbps on red5 and >> 62-65kbps on wowza. >> Clearly there is a problem.. with red5, mina, and rtmp. As far as I'm >> aware wowza also uses mina so I dont think problem is mina but perhaps >> something with our settings or the size of the packets we are sending. >> >> Things I've tried so far.. >> >> tcp no delay off makes no difference. >> tried with rtmp and the problem is not there which tells us it must be >> a mina issue. >> >> Ideas and suggestions of things we can try to fix this?? I will keep >> trying things. >> >> Regards, >> Luke >> >> >> >> >> >> >> >> On 4/12/07, Dan Rossi <[EMAIL PROTECTED]> wrote: >> >>> http://69.42.91.84:5080/RED5_WWW2.swf >>> >>> http://69.42.91.84:5080/WOWZA_WWW2.swf >>> >>> could be different in various locations but click the video centre for >>> the stats, if you see a big difference in the buffer length between the >>> two its a good start to work out the problem I guess ? From my >>> observation the others "push" extra bits somehow to keep it up to speed. >>> >>> There is absolutely nothing wrong with our connection then or even too >>> much latency which is about 200ms from the looks of it. >>> >>> Dan Rossi wrote: >>> >>>> Im really unsure whats the maximum video bitrate we could be streaming >>>> without a problem, as of now it seems a 180k video is the maximum >>>> without the buffer length issues. >>>> >>>> Back to the wowza comparison, im playing a 512k stream perfect with 9-10 >>>> second buffer length, starts straight away, in red5 the same clip drops >>>> the ball in pretty much immediately, and the buffer length decreases >>>> every 3 seconds which is on par with the 300k clip,so its not reducing >>>> faster than the 300k clip. >>>> >>>> A 780k stream wowza is yet again able to play fine, keeps a length of 10 >>>> seconds, red5 rebuffers every 10 seconds. >>>> >>>> Here is my ping status to our server >>>> >>>> PING 69.42.93.22 (69.42.93.22): 56 data bytes >>>> 64 bytes from 69.42.93.22: icmp_seq=0 ttl=112 time=255.277 ms >>>> 64 bytes from 69.42.93.22: icmp_seq=1 ttl=112 time=255.172 ms >>>> 64 bytes from 69.42.93.22: icmp_seq=2 ttl=112 time=255.172 ms >>>> 64 bytes from 69.42.93.22: icmp_seq=3 ttl=112 time=255.663 ms >>>> 64 bytes from 69.42.93.22: icmp_seq=4 ttl=112 time=255.009 ms >>>> 64 bytes from 69.42.93.22: icmp_seq=5 ttl=112 time=254.927 ms >>>> 64 bytes from 69.42.93.22: icmp_seq=6 ttl=112 time=255.430 ms >>>> 64 bytes from 69.42.93.22: icmp_seq=7 ttl=112 time=255.199 ms >>>> 64 bytes from 69.42.93.22: icmp_seq=8 ttl=112 time=255.265 ms >>>> 64 bytes from 69.42.93.22: icmp_seq=9 ttl=112 time=255.086 ms >>>> 64 bytes from 69.42.93.22: icmp_seq=10 ttl=112 time=255.159 ms >>>> ^C >>>> --- 69.42.93.22 ping statistics --- >>>> 11 packets transmitted, 11 packets received, 0% packet loss >>>> round-trip min/avg/max/stddev = 254.927/255.214/255.663/0.191 ms >>>> >>>> >>>> >>>> Dan Rossi wrote: >>>> >>>> >>>>> I just tried a 38K clip and obviouslly it stayed at 8 second buffer >>>>> length, not sure if anyone has read my comparisons both FMS and wowza >>>>> "push" extra into the buffer it increases more than the buffer time, >>>>> when the length goes back to the buffer time in pushes it back to about >>>>> double the buffer length. red5 seems to just keep it at the buffer time, >>>>> >>>>> I just tried a 180K clip, and the length increases but only slightly. >>>>> Some things might have been fixed because on a 1MB and 5MB adsl >>>>> connection it was not possible to play either. >>>>> >>>>> I just tried a non red5 demo video, which was a 300k video, there is a >>>>> pattern forming here, it degrades every 10 seconds or so. >>>>> >>>>> I ran a bandwidth test on cnet and says our conn is 156kbps, >>>>> >>>>> http://reviews.cnet.com/7009-7254_7-0.html?CType=2278&ac=2&ISPID=&ISPNAME=&&kbps=156 >>>>> >>>>> our adsl conn is 8MB but im not sure what it syncs at does this sound >>>>> about right ? When i test on a 5MB syncing adsl connection it cannot >>>>> play anything larger than 180 either. >>>>> >>>>> We can play windows media 780k streams fine, its setup with http >>>>> protocol streaming though, but isnt progressive download or would it be >>>>> partially ? >>>>> >>>>> I ran our bwchecker again, the numbers are much lower than before. Im >>>>> not really sure though how to match these values to video bitrate >>>>> numbers, i know i sound retarded, why would cnet show our conn to be >>>>> 156kbps when these numbers are showing anything between 300-2000 KBdown, >>>>> are these kbits or kbyte ? From the code it seems the KBdown is in fact >>>>> kbit per second, so should match the bitrate of the videos >>>>> >>>>> deltaDown = (endStats.getWrittenBytes() - beginningValues.get("b_down")) >>>>> * 8 / 1000; // bytes to kbits >>>>> deltaTime = ((now - beginningValues.get("time")) - (latency * >>>>> cumLatency)) / 1000; // total dl time - latency for each packet sent in >>>>> secs >>>>> >>>>> if (deltaTime <= 0) { >>>>> deltaTime = (now - beginningValues.get("time")) / 1000; >>>>> } >>>>> >>>>> kbitDown = Math.round(deltaDown / deltaTime); // kbits / sec >>>>> >>>>> log.info("onBWDone: kbitDown = " + kbitDown + ", deltaDown= " + >>>>> deltaDown + ", deltaTime = " + deltaTime + ", latency = " + this.latency); >>>>> >>>>> this.callBWDone(this.kbitDown, this.deltaDown, this.deltaTime, >>>>> this.latency); >>>>> >>>>> >>>>> KBDown: 681 Delta Down: 1047 Delta Time: 1.538 Latency: 238 >>>>> KBDown: 593 Delta Down: 1047 Delta Time: 1.765 Latency: 239 >>>>> KBDown: 308 Delta Down: 176 Delta Time: 0.572 Latency: 250 >>>>> KBDown: 440 Delta Down: 1047 Delta Time: 2.379 Latency: 235 >>>>> >>>>> >>>>> Dan Rossi wrote: >>>>> >>>>> >>>>> >>>>>> Hi mate yes you were saying, its always been a problem here and doing my >>>>>> head in :) >>>>>> >>>>>> rtmp://69.42.93.22/oflaDemo >>>>>> >>>>>> i had to make that change in the core to increase the timeout to 1000000 >>>>>> or else id get disconnected. The oflademo swf is definitely doing >>>>>> exactly the same thing as my flex player. >>>>>> >>>>>> >>>>>> joseph wamicha wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hey Dan, >>>>>>> >>>>>>> I'm having exactly the same problems. It works in LAN but fails. I'm >>>>>>> located in Nairobi and our networks are poor and have a lot of >>>>>>> latencies. It was working previously so I'm guessing it's something >>>>>>> related to the latency. It used to work pretty well before but now >>>>>>> plays for some seconds and then stops. I'll probably do more tests >>>>>>> later. >>>>>>> >>>>>>> On 4/12/07, *Dan Rossi* <[EMAIL PROTECTED] >>>>>>> <mailto:[EMAIL PROTECTED]>> wrote: >>>>>>> >>>>>>> Kinda odd really, here is what the bandwdith detection app returns, >>>>>>> although im not really sure how to make use of the data yet, i >>>>>>> refresh a >>>>>>> few times as it seems to return inconcistant data, we should be >>>>>>> able to >>>>>>> play the 400k star wars trailer fine on this connection really, >>>>>>> Ill try >>>>>>> a very low bitrate video but im pretty sure its got nothing to do >>>>>>> with >>>>>>> bits, but how its pushed out. >>>>>>> >>>>>>> KBDown: 1497 Delta Down: 1918 Delta Time: 1.281 Latency: 45 >>>>>>> KBDown: 1803 Delta Down: 1918 Delta Time: 1.064 Latency: 52 >>>>>>> KBDown: 149 Delta Down: 176 Delta Time: 1.185 Latency: 60 >>>>>>> KBDown: 1258 Delta Down: 1047 Delta Time: 0.832 Latency: 93 >>>>>>> >>>>>>> Dan Rossi wrote: >>>>>>> > Apologies, i just tried my flex player in a standalone flash and >>>>>>> it >>>>>>> > plays right away, this seem to be some wierd thing debugging in >>>>>>> flex >>>>>>> > maybe on the pc ? Its still dropping the buffer length after >>>>>>> each buffer >>>>>>> > so every 8 seconds it rebuffers. I was alerted that it was fixed >>>>>>> :\ >>>>>>> > >>>>>>> > Dan Rossi wrote: >>>>>>> > >>>>>>> >> Hi i set the setting a few more zeros and finally wanted to >>>>>>> play, so its >>>>>>> >> dropping the connection not soon after its playing because it >>>>>>> thinks its >>>>>>> >> timing out ?. >>>>>>> >> >>>>>>> >> It is however doing exactly as before, buffers, begins to play, >>>>>>> seeks to >>>>>>> >> 8 seconds, stops, buffers, plays, then buffer length drops >>>>>>> down to 0 >>>>>>> >> not soon after. This buffer problem has never really managed to >>>>>>> work. >>>>>>> >> >>>>>>> >> <bean id="rtmpMinaConnection" scope="prototype" >>>>>>> >> class="org.red5.server.net.rtmp.RTMPMinaConnection"> >>>>>>> >> <property name="keepAliveInterval" value="100000000" /> >>>>>>> >> </bean> >>>>>>> >> >>>>>>> >> Is this correct ? >>>>>>> >> >>>>>>> >> Joachim Bauch wrote: >>>>>>> >> >>>>>>> >> >>>>>>> >>> Hi Dan, >>>>>>> >>> >>>>>>> >>> Dan Rossi schrieb: >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>>> Hi ive updated trunk to check out if the latency issue has >>>>>>> been removed >>>>>>> >>>> however no, when it reaches 7 seconds into the stream the >>>>>>> playback >>>>>>> >>>> stops, and there is no error returned. Any ideas ? >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>> can't reproduce this. Using ofla_demo.swf everything works >>>>>>> just fine. >>>>>>> >>> You could try changing the "keepAliveInterval" property in the >>>>>>> bean >>>>>>> >>> "rtmpMinaConnection" in "red5-core.xml" to check if your >>>>>>> client gets >>>>>>> >>> disconnected by the ghost detection code. >>>>>>> >>> The ghost detection code is something we will be working on >>>>>>> for the >>>>>>> >>> 0.6 final release. >>>>>>> >>> >>>>>>> >>> Joachim >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> _______________________________________________ >>>>>>> >>> Red5 mailing list >>>>>>> >>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>>> >>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >> _______________________________________________ >>>>>>> >> Red5 mailing list >>>>>>> >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>>> >> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > Red5 mailing list >>>>>>> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>>> > http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Red5 mailing list >>>>>>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> C is forever. >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Red5 mailing list >>>>>>> [EMAIL PROTECTED] >>>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Red5 mailing list >>>>>> [EMAIL PROTECTED] >>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Red5 mailing list >>>>> [EMAIL PROTECTED] >>>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Red5 mailing list >>>> [EMAIL PROTECTED] >>>> http://osflash.org/mailman/listinfo/red5_osflash.org >>>> >>>> >>>> >>> _______________________________________________ >>> Red5 mailing list >>> [EMAIL PROTECTED] >>> http://osflash.org/mailman/listinfo/red5_osflash.org >>> >>> >> -- >> Luke Hubbard >> codegent | coding for the people >> http://www.codegent.com >> >> NMA Top 100 Interactive Agencies - Ones to watch! >> http://www.codegent.com/top100/ >> >> want to know more? >> http://www.codegent.com/showreel/ >> >> This e-mail may contain information which is privileged, confidential >> and protected from disclosure. If you are not the intended recipient >> of this e-mail, or any part of it, please delete this email and any >> attachments immediately on receipt. You should not disclose the >> contents to any other person or take copies. Any views expressed in >> this message are those of the individual sender, except where the >> sender specifically states them to be the views of codegent limited. >> >> > > >
_______________________________________________ Red5 mailing list [EMAIL PROTECTED] http://osflash.org/mailman/listinfo/red5_osflash.org
