Nope that seems like a unrelated issue.- I will try to have a look into that though asap.
- Luke On 4/13/07, Dan Rossi <[EMAIL PROTECTED]> wrote: > Will this fix the reason why the connection drops out as soon as > playback starts ? I havent to set the timeout to 10000000 currently. > > Dan Rossi wrote: > > 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 > > > > > > > _______________________________________________ > 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
