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
