has a 16mbit capacity e.g. the buffer should have filled within 1 tot 1.5
seconds). This test uses bufferlength = 10 seconds.
again. The local player stalls, asks for more data but does not get the
packets. When scrubbing to a position minutes ahead Red5 pushes fills the
playing and stops when buffer is empty. The video effectively hangs.
the same videos. It's just the newer versions that seem to hang.
>
> Hi Walter, thanks for the elaborate explanation.
> But the testing is done by running the red5 server and client(flex and
> openlaszlo) app in the same computer, so I could ignore the delays and
> hickups in broadband for now, right.
>
> Regarding the bufferLength, I did try setting it to 5 seconds, the first
> 10
> seconds will play smoothly, then the video pause for about 5 seconds, then
> the next 10 seconds play smoothly, then it pause for another 5 seconds,
> then
> the next 10 seconds will play smoothly too, and it goes on and on....
> Because the test is running on the same computer, i shouldn't see the
> video
> pausing to fill up the buffer right? I mean the video should play smoothly
> without delay or hickup as there is no latency,right?
>
> So, this brings me to the question that whether Red5 save the stream as
> .flv
> file correctly? Please note that Red5 0.8.0 rc1 doesn't have this problem,
> I
> only notice this problem when i upgrade to Red5 0.9.0 Hudson build #156.
>
>
> Walter Tak wrote:
>>
>> Red5 just pushes data to your client.
>>
>> You want your client to buffer a few seconds of video at least. So
>> bufferLength should be somewhere between 2 to 10 seconds, depending on
>> the
>> quality of your link/bandwidth. If you have a clear line and can download
>> at
>> speeds of 10 mbit/sec without problems then any stream of less than 5
>> mbit/sec should be viewable without any hickup.
>>
>> However hickups do occur now and then between the server and your
>> client(s)
>> and that's why you want a little buffer. For teleconfering with
>> live-to-live
>> streams you might want to have a low buffer to avoid the 'latency', for
>> viewing movies/longer videos you could go for 5-10 seconds buffer for
>> near
>> perfect viewing.
>>
>> For those that care ; there are various ways to do 'dynamic stream
>> switching' by trying to determine the actual bandwidth of a client on the
>> client-side with some action-script code. Various code-snippets can be
>> found
>> here:
>>
>>
http://labs.influxis.com/?p=269>>
>>
http://www.adobe.com/devnet/flashmediaserver/articles/dynstream_on_demand.html>>
>>
http://www.adobe.com/devnet/flashmediaserver/articles/fms_dual_buffering.html>>
>> The last link is very interesting ; Fabio did back in the days some nice
>> investigation ; the graph shows real-life behaviour of your
>> 'consumer-grade'
>> internet-connection ; the available bandwidth is far from 'stable'.
>> Besides
>> that your own client could suddenly have limited resources (virusscanner
>> starts, you start another download in the background, your torrent
>> decides
>> to upload at 95% of your capacity, the server might hit a spike due to 15
>> other requests , the creation of statistics at exactly 00:00 hours or a
>> backup operation.
>>
>> Once you understand that streaming is balancing on a cord above the grand
>> canyon you'll see that there are no default values that will work in all
>> situations. You want to have some dynamic logic. The easiest thing is to
>> do
>> that on client side.
>>
>> The concept is simple ; check the bandwidth by sending small packets of
>> random-data. Measure how long it takes to transfer those little packets
>> to
>> the server. Calculate the supposed available bandwidth. Switch to a
>> stream
>> with a matching bitrate. This assumes you store your video in at least
>> two
>> or more bitrates. Think of 100 kbit , 500 kbit, 1000 kbit etc. Like the
>> Youtube "HD" option.
>>
>> ----- Original Message -----
>> From: "edjayks" <
edjayks@...>
>> To: <
Red5@...>
>> Sent: Tuesday, 14 July 2009 02:35
>> Subject: Re: [Red5] Saved live stream problem
>>
>>
>>>
>>> The buffer length at the client site is left at 0.1 seconds, this
>>> setting
>>> was
>>> fine when i run it with Red5 0.8 RC1. Does the red5 have a setting for
>>> buffer length too? If yes, where do i find it?
>>>
>>> The file itself is around 2.5Megabytes for 2minutes of recording.
>>>
>>> Well, if the file itself is corrupt, don't you think it's the Red5 that
>>> is
>>> causing it?
>>>
>>>
>>> Andy Shaules wrote:
>>>>
>>>> sounds like the buffer length is too little.
>>>>
>>>> and the file is too phat.
>>>>
>>>> Or the file itself is corrupt.
>>>>
>>>> ----- Original Message -----
>>>> From: "edjayks" <
edjayks@...>
>>>> To: <
Red5@...>
>>>> Sent: Monday, July 13, 2009 1:32 AM
>>>> Subject: Re: [Red5] Saved live stream problem
>>>>
>>>>
>>>>>
>>>>> Ok, i did one more testing, I put the recorded .flv file into Flash
>>>>> media
>>>>> server vod's directory, then i use the client application built in
>>>>> Adobe
>>>>> flex, the video plays smoother, it plays smooth for about 3-6 seconds
>>>>> then
>>>>> it pause for 1-2 seconds then it plays again, and the play and pause
>>>>> thing
>>>>> repeat until the video has finished playing.
>>>>> Compared to it being stream from red5, the video would be jerky every
>>>>> second, like pause and play for a few times in every seconds until the
>>>>> end
>>>>> of the video.
>>>>>
>>>>> Somebody, please help.:-(
>>>>>
>>>>>
>>>>> edjayks wrote:
>>>>>>
>>>>>> I have a client that broadcast video and audio, then on the server,
>>>>>> it
>>>>>> would save the stream into a flv file.
>>>>>> When i playback the video, it's very jerky.
>>>>>> I'm using Red5 hudson build #156. It was fine before the patch from
>>>>>> absolute to relative timestamp.
>>>>>>
>>>>>> More information, on the server code, I call
>>>>>>
>>>>>> ClientBroadcastStream stream = ...;
>>>>>> stream.saveAs(steamNAme,false);
>>>>>>
>>>>>> to start recording the live stream. Then i call
>>>>>>
>>>>>> ClientBroadcastStream stream = ...;
>>>>>> stream.stopRecording();
>>>>>>
>>>>>> to stop recording the live stream.
>>>>>>
>>>>>> I tried creating a simple video playback application in openlaszlo
>>>>>> and
>>>>>> adobe flex, both will play the video jerkyly. Seems like the video
>>>>>> pause
>>>>>> and play very frequently.
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
http://www.nabble.com/Saved-live-stream-problem-tp24403684p24457882.html>>>>> Sent from the Red5 - English mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Red5 mailing list
>>>>>
Red5@...
>>>>>
http://osflash.org/mailman/listinfo/red5_osflash.org>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Red5 mailing list
>>>>
Red5@...
>>>>
http://osflash.org/mailman/listinfo/red5_osflash.org>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>>
http://www.nabble.com/Saved-live-stream-problem-tp24403684p24471849.html>>> Sent from the Red5 - English mailing list archive at Nabble.com.
>>>
>>>
>>> _______________________________________________
>>> Red5 mailing list
>>>
Red5@...
>>>
http://osflash.org/mailman/listinfo/red5_osflash.org>>>
>>>
>>>
>>> --
>>> Internal Virus Database is out-of-date.
>>> Checked by AVG.
>>> Version: 7.5.560 / Virus Database: 270.12.26/2116 - Release Date:
>>> 15-05-09
>>> 06:16
>>>
>>
>>
>> _______________________________________________
>> Red5 mailing list
>>
Red5@...
>>
http://osflash.org/mailman/listinfo/red5_osflash.org>>
>>
>
> --
> View this message in context:
>
http://www.nabble.com/Saved-live-stream-problem-tp24403684p24472375.html> Sent from the Red5 - English mailing list archive at Nabble.com.
>
>
> _______________________________________________
> Red5 mailing list
>
Red5@...
>
http://osflash.org/mailman/listinfo/red5_osflash.org>
>
>
> --
> Internal Virus Database is out-of-date.
> Checked by AVG.
> Version: 7.5.560 / Virus Database: 270.12.26/2116 - Release Date: 15-05-09
> 06:16
>