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
