« Return to Thread: Saved live stream problem

Re: Saved live stream problem

by edjayks :: Rate this Message:

Reply to Author | View in Thread

Hi walter, that is exactly the problem I'm facing now.
Nice to know that I'm not alone on this.

Walter Tak wrote:
I see weird buffer problems with all versions newer from 0.8RC2 to latest
trunk (y'day) as well.

In my case the local buffer on the clients fills up, rather slowly (think of
3 seconds to fill "10 seconds of 2mbit/sec videodata", while the downlink
has a 16mbit capacity e.g. the buffer should have filled within 1 tot 1.5
seconds). This test uses bufferlength = 10 seconds.

When the video starts to play the local buffer decreases ; no new data is
being pushed from Red5 to the client.

After 10 seconds the local buffer is empty and Red5 doesn't fill the buffer
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
buffer (for the full 10 seconds), the videos starts playing after the buffer
is filled, then the whole problem repeats ; buffer decreases while video is
playing  and stops when buffer is empty. The video effectively hangs.

The file was a 1750 kbit movie trailer VP6-S, 2+ minutes, FLV (no H264
whatsoever).

I've tested this with multiple versions (080RC2, 080final, various 090
hudson builds from 144 to 164) on my local desktop, on my remote high-cap
servers and on a remote low-cap virtual machine and I'm quite puzzled.

An old version of Red5 (version number between 070 and 080) works fine for
the same videos. It's just the newer versions that seem to hang.

Using JDK 1.6.0.4/1.6.0.12 btw.

----- Original Message -----
From: "edjayks" <edjayks@yahoo.com>
To: <Red5@osflash.org>
Sent: Tuesday, 14 July 2009 03:43
Subject: Re: [Red5] Saved live stream problem


>
> 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@yahoo.com>
>> To: <Red5@osflash.org>
>> 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@yahoo.com>
>>>> To: <Red5@osflash.org>
>>>> 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@osflash.org
>>>>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Red5 mailing list
>>>> Red5@osflash.org
>>>> 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@osflash.org
>>> 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@osflash.org
>> 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@osflash.org
> 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@osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org

 « Return to Thread: Saved live stream problem