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
