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
