Hi luke its the weekend now but i just tested the streaming, it started str8 away and kept a buffer length of 10 seconds, which is on par with wowza. FMS seems to get much more, but i was testing this on a fairly standard ADSL conn over a wireless network, will test wired from a 24MB adsl later. But whatever you did freakin nailed it mate, i knew it all along it was mina settings, i tried to research some of it but it was too hard.
Can you please document again which settings were changed and where, so i can try and play with those settings, i guess ill just give it the most maximum level it can go ? It seems mina was shaping the packets or something ? Luke Hubbard wrote: > 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 >> >> > > > _______________________________________________ Red5 mailing list [EMAIL PROTECTED] http://osflash.org/mailman/listinfo/red5_osflash.org
