Saved live stream problem

View: New views
5 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 | Next >

Re: Saved live stream problem

by Thomas Auge :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I think I'm experiencing the same problem. I can't confirm that it is
limited to saved live streams though.

I record webcam streams directly in Red5, but I also convert videos
uploaded videos from ffmpeg.

I serve both of these video types through apaches httpd without any
bandwidth issues. I figured it'd be more elegant to stream them from
red5, but there I am running into bandwidth issues, even though server
and network health is good.

To me it looks like there is a short burst at the beginning of the
buffering, with throughput declining shortly after. On a short video,
the initial burst is enough to offset for the later lack in throughput,
but for long videos it is not.

The application I am using to stream the videos does nothing except some
access control in appConnect(). So unless I am missing some
configuration option, which could throttle bandwidth, the red5
throughput for streaming from video files currently is way too low.



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


_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: Saved live stream problem

by edjayks :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Thomas, do you have any idea on how to solve this or a workaround maybe?
Thanks.

Thomas Auge wrote:
I think I'm experiencing the same problem. I can't confirm that it is
limited to saved live streams though.

I record webcam streams directly in Red5, but I also convert videos
uploaded videos from ffmpeg.

I serve both of these video types through apaches httpd without any
bandwidth issues. I figured it'd be more elegant to stream them from
red5, but there I am running into bandwidth issues, even though server
and network health is good.

To me it looks like there is a short burst at the beginning of the
buffering, with throughput declining shortly after. On a short video,
the initial burst is enough to offset for the later lack in throughput,
but for long videos it is not.

The application I am using to stream the videos does nothing except some
access control in appConnect(). So unless I am missing some
configuration option, which could throttle bandwidth, the red5
throughput for streaming from video files currently is way too low.



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
>


_______________________________________________
Red5 mailing list
Red5@osflash.org
http://osflash.org/mailman/listinfo/red5_osflash.org

Re: Saved live stream problem

by edjayks :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Instead of using .saveAs() and .stopRecording() in ClientBroadcastStream, is there other interface or classes that i could use to record stream?


Hi, I'm using the client provided in Red5
http://localhost:5080/demos/publisher.html

I'm trying to use xuggle now to listen to the stream in red5 (just started, don't know whether it would works) and save it to .flv, so that i don't rely on Red5's stream recording function. What do you think about this?

Do you have other idea or workaround? Because i really need stream recording on the server.

Thanks.

Gavriloaie Eugen-Andrei wrote:
Your low fps rate has absolutely nothing to do with the bandwidth. I  
have the same problem. I fact, I still have it from time to time. I'm  
using Mac OS X Leopard and from time to time, the built-in camera just

To verify this, you could try downloading the following swf file and  
play with the settings there (btw, what are you using right now? Would  
you like to share that swf file also? It would be great to have anoth

http://rtmpd.com/browser/trunk/docs/simpleLive/simpleLive.swf

you can find the download link just below. Something like this: "Try  
downloading the file instead"



On Jul 17, 2009, at 9:45 AM, edjayks wrote:

>
> Is there other way to record stream on the server?
> Can xuggle be used to listen to stream in red5 and then save it  
> into .flv
> file?
>
>
> edjayks wrote:
>>
>> Tried bumping up to 48Kbytes and drop to 20% quality. Resolution  
>> set at
>> 160x120.
>> I still get 7fps only.
>> When i record it on Red5 0.8.0RC1, I get 15 fps.
>>
>> And again, all test run in the same computer(red5 and client on same
>> computer), so the same webcam and mic is used throughout the test.
>>
>>
>> Walter Tak wrote:
>>>
>>> 1. make sure your videosetting is supported by the camera you use.
>>> Normally
>>> resolutions are like 320x240, 320x200, 160x120 etc. Your camera
>>> (driver)
>>> might lock up or Flash Player has to compensate and will actually  
>>> capture
>>> data at 160x120 and stretch the image to your custom resolution
>>>
>>> 2. 32 kbytes and 75% quality might result in less than 15 fps.  
>>> Imagine
>>> this
>>> ; you instruct the FP to create frames of only 32768 / 15 = 2184  
>>> bytes
>>> each.
>>> Lower the quality and check again. Perhaps just at 40% quality you  
>>> might
>>> achieve 15 fps.
>>>
>>> 3. audio really can take up quite some bandwidth. NellyMoser 22 kHz
>>> stereo
>>> might do around 4 kbytes/sec, that leaves just 28 kbytes for 15  
>>> frames.
>>>
>>> Just play with the 2 settings. Increase the 32 kbytes, lower the  
>>> quality,
>>> until it gives results you like.
>>>
>>> Then test with multiple webcams ; they all behave different. Even  
>>> webcams
>>> from the same make like Logitech act different from say Microsoft
>>> webcams.
>>> Lot's of variables :)
>>>
>>>
>>>> Hi Walter, thanks for the information. I do understand that on an
>>>> internet
>>>> connection, i wouldn't be able to get 15fps constantly.
>>>> But, the testing i'm doing in on a local pc, Red5 and the client is
>>>> running
>>>> on the same computer, would flash player still drop frame?
>>>> The video settings are: 183x170(width x height), fps 15, quality  
>>>> 75%,
>>>> max
>>>> bandwidth 32768 bytes per seconds, audio is set at 22khz.
>>>>
>>>>
>>>> Walter Tak wrote:
>>>>>
>>>>> If you set the 15 fps on the client that gives no guarantee that  
>>>>> your
>>>>> flash
>>>>> player actually sends 15 frames/sec to the server.
>>>>>
>>>>> If it can it will but if your setQuality for example is very  
>>>>> high it
>>>>> might
>>>>> even just send 1 frame per second to the server.
>>>>>
>>>>> See
>>>>> http://wiki.mediabox.fr/PDF/astro_langRefStandalone/flash/media/Camera.html#setQuality 
>>>>> ()
>>>>>
>>>>> If you'd use [ setQuality(32000, 100);  ] then Flash would send  
>>>>> out
>>>>> frames
>>>>> each with 100% quality.
>>>>> If a frame would exceed 32 Kb in size (and it will @ 100%  
>>>>> quality) then
>>>>> Flash would send less than 1 frame per second to the server.
>>>>>
>>>>> How can you always output 15 fps ? Well you can't. If the user is
>>>>> moving
>>>>> very fast in front of his webcam then Flash needs
>>>>> more than the available bandwidth (32 Kb). How much more ? You  
>>>>> can't
>>>>> calculate that. You could set the bandwidth to 0 (zero) which  
>>>>> means,
>>>>> use whatever you want, but you will hit the maximum upstream  
>>>>> capacity
>>>>> of
>>>>> your user (say 512 kbit or 1 mbit on xDSL lines) and Flash still
>>>>> doesn't send out exactly 15 fps.
>>>>>
>>>>> You can watch the incoming fps of a video using  
>>>>> "NetStream.currentFPS"
>>>>> :
>>>>> http://wiki.mediabox.fr/PDF/astro_langRefStandalone/flash/net/NetStream.html#currentFPS
>>>>>
>>>>> (copy the FPS to some TextField using a Timer or ENTER_FRAME  
>>>>> event to
>>>>> keep
>>>>> an eye on it)
>>>>>
>>>>> It will probably show very varying results.
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "edjayks" <edjayks@yahoo.com>
>>>>> To: <Red5@osflash.org>
>>>>> Sent: Thursday, 16 July 2009 12:39
>>>>> Subject: Re: [Red5] Saved live stream problem
>>>>>
>>>>>
>>>>>>
>>>>>> Did some testing:
>>>>>> A client publishes his webcam at 15fps, on the server i use  
>>>>>> save.As()
>>>>>> to
>>>>>> record the stream.
>>>>>> Then i use a program called FLV Metadata Injector to inject the
>>>>>> metadata
>>>>>> such is width, height, framerate and etc. And i saw that the  
>>>>>> framerate
>>>>>> is
>>>>>> around 7.3 and 7.4fps.
>>>>>>
>>>>>> Using the FLV Metadata Injector on flv files that are recorded  
>>>>>> on Red5
>>>>>> 0.8
>>>>>> RC1, i get framerate of 15fps.
>>>>>>
>>>>>> Anyone that is facing this problem, could you also verify this?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>> edjayks wrote:
>>>>>>>
>>>>>>> Anyone have any idea what is causing the problem and how to  
>>>>>>> fix it?
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>> Rhys Causey-2 wrote:
>>>>>>>>
>>>>>>>> I think I'm experiencing the same issue with the trunk. The  
>>>>>>>> file is
>>>>>>>> saved by Red5, it opens and somehow plays fine in Adobe Media
>>>>>>>> Player,
>>>>>>>> but the audio stutters if I play it in VLC (video is fine),  
>>>>>>>> and it
>>>>>>>> skips if I stream it from Red5 (similar behaviour to what you
>>>>>>>> described -- plays for a few seconds, stops, plays again,  
>>>>>>>> stops,
>>>>>>>> etc).
>>>>>>>> It also takes a much longer time to start than other video  
>>>>>>>> files.
>>>>>>>>
>>>>>>>> It worked okay in the previous version of Red5 that I was using
>>>>>>>> (startup log says revision 3607 -- not sure if this is  
>>>>>>>> accurate).
>>>>>>>>
>>>>>>>> Rhys
>>>>>>>>
>>>>>>>> On 14-Jul-09, at 10:12 AM, edjayks wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi walter, that is exactly the problem I'm facing now.
>>>>>>>>> Nice to know that I'm not alone on this.=^D
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> View this message in context:
>>>>>>>>> http://www.nabble.com/Saved-live-stream-problem-tp24403684p24480315.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-tp24403684p24514009.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-tp24403684p24527000.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-tp24403684p24529382.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


Re: Saved live stream problem

by Argenacho :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Has anybody taken this into account and submitted an issue to the red5 issue tracker so it does not get forgotten?
It sounds like there may be something funky in 0.8......


On Wed, Jul 22, 2009 at 5:55 AM, edjayks <edjayks@...> wrote:

Instead of using .saveAs() and .stopRecording() in ClientBroadcastStream, is
there other interface or classes that i could use to record stream?


edjayks wrote:
>
> Hi, I'm using the client provided in Red5
> http://localhost:5080/demos/publisher.html
>
> I'm trying to use xuggle now to listen to the stream in red5 (just
> started, don't know whether it would works) and save it to .flv, so that i
> don't rely on Red5's stream recording function. What do you think about
> this?
>
> Do you have other idea or workaround? Because i really need stream
> recording on the server.
>
> Thanks.
>
>
> Gavriloaie Eugen-Andrei wrote:
>>
>> Your low fps rate has absolutely nothing to do with the bandwidth. I
>> have the same problem. I fact, I still have it from time to time. I'm
>> using Mac OS X Leopard and from time to time, the built-in camera just
>>
>> To verify this, you could try downloading the following swf file and
>> play with the settings there (btw, what are you using right now? Would
>> you like to share that swf file also? It would be great to have anoth
>>
>> http://rtmpd.com/browser/trunk/docs/simpleLive/simpleLive.swf
>>
>> you can find the download link just below. Something like this: "Try
>> downloading the file instead"
>>
>>
>>
>> On Jul 17, 2009, at 9:45 AM, edjayks wrote:
>>
>>>
>>> Is there other way to record stream on the server?
>>> Can xuggle be used to listen to stream in red5 and then save it
>>> into .flv
>>> file?
>>>
>>>
>>> edjayks wrote:
>>>>
>>>> Tried bumping up to 48Kbytes and drop to 20% quality. Resolution
>>>> set at
>>>> 160x120.
>>>> I still get 7fps only.
>>>> When i record it on Red5 0.8.0RC1, I get 15 fps.
>>>>
>>>> And again, all test run in the same computer(red5 and client on same
>>>> computer), so the same webcam and mic is used throughout the test.
>>>>
>>>>
>>>> Walter Tak wrote:
>>>>>
>>>>> 1. make sure your videosetting is supported by the camera you use.
>>>>> Normally
>>>>> resolutions are like 320x240, 320x200, 160x120 etc. Your camera
>>>>> (driver)
>>>>> might lock up or Flash Player has to compensate and will actually
>>>>> capture
>>>>> data at 160x120 and stretch the image to your custom resolution
>>>>>
>>>>> 2. 32 kbytes and 75% quality might result in less than 15 fps.
>>>>> Imagine
>>>>> this
>>>>> ; you instruct the FP to create frames of only 32768 / 15 = 2184
>>>>> bytes
>>>>> each.
>>>>> Lower the quality and check again. Perhaps just at 40% quality you
>>>>> might
>>>>> achieve 15 fps.
>>>>>
>>>>> 3. audio really can take up quite some bandwidth. NellyMoser 22 kHz
>>>>> stereo
>>>>> might do around 4 kbytes/sec, that leaves just 28 kbytes for 15
>>>>> frames.
>>>>>
>>>>> Just play with the 2 settings. Increase the 32 kbytes, lower the
>>>>> quality,
>>>>> until it gives results you like.
>>>>>
>>>>> Then test with multiple webcams ; they all behave different. Even
>>>>> webcams
>>>>> from the same make like Logitech act different from say Microsoft
>>>>> webcams.
>>>>> Lot's of variables :)
>>>>>
>>>>>
>>>>>> Hi Walter, thanks for the information. I do understand that on an
>>>>>> internet
>>>>>> connection, i wouldn't be able to get 15fps constantly.
>>>>>> But, the testing i'm doing in on a local pc, Red5 and the client is
>>>>>> running
>>>>>> on the same computer, would flash player still drop frame?
>>>>>> The video settings are: 183x170(width x height), fps 15, quality
>>>>>> 75%,
>>>>>> max
>>>>>> bandwidth 32768 bytes per seconds, audio is set at 22khz.
>>>>>>
>>>>>>
>>>>>> Walter Tak wrote:
>>>>>>>
>>>>>>> If you set the 15 fps on the client that gives no guarantee that
>>>>>>> your
>>>>>>> flash
>>>>>>> player actually sends 15 frames/sec to the server.
>>>>>>>
>>>>>>> If it can it will but if your setQuality for example is very
>>>>>>> high it
>>>>>>> might
>>>>>>> even just send 1 frame per second to the server.
>>>>>>>
>>>>>>> See
>>>>>>> http://wiki.mediabox.fr/PDF/astro_langRefStandalone/flash/media/Camera.html#setQuality
>>>>>>> ()
>>>>>>>
>>>>>>> If you'd use [ setQuality(32000, 100);  ] then Flash would send
>>>>>>> out
>>>>>>> frames
>>>>>>> each with 100% quality.
>>>>>>> If a frame would exceed 32 Kb in size (and it will @ 100%
>>>>>>> quality) then
>>>>>>> Flash would send less than 1 frame per second to the server.
>>>>>>>
>>>>>>> How can you always output 15 fps ? Well you can't. If the user is
>>>>>>> moving
>>>>>>> very fast in front of his webcam then Flash needs
>>>>>>> more than the available bandwidth (32 Kb). How much more ? You
>>>>>>> can't
>>>>>>> calculate that. You could set the bandwidth to 0 (zero) which
>>>>>>> means,
>>>>>>> use whatever you want, but you will hit the maximum upstream
>>>>>>> capacity
>>>>>>> of
>>>>>>> your user (say 512 kbit or 1 mbit on xDSL lines) and Flash still
>>>>>>> doesn't send out exactly 15 fps.
>>>>>>>
>>>>>>> You can watch the incoming fps of a video using
>>>>>>> "NetStream.currentFPS"
>>>>>>> :
>>>>>>> http://wiki.mediabox.fr/PDF/astro_langRefStandalone/flash/net/NetStream.html#currentFPS
>>>>>>>
>>>>>>> (copy the FPS to some TextField using a Timer or ENTER_FRAME
>>>>>>> event to
>>>>>>> keep
>>>>>>> an eye on it)
>>>>>>>
>>>>>>> It will probably show very varying results.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "edjayks" <edjayks@...>
>>>>>>> To: <Red5@...>
>>>>>>> Sent: Thursday, 16 July 2009 12:39
>>>>>>> Subject: Re: [Red5] Saved live stream problem
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Did some testing:
>>>>>>>> A client publishes his webcam at 15fps, on the server i use
>>>>>>>> save.As()
>>>>>>>> to
>>>>>>>> record the stream.
>>>>>>>> Then i use a program called FLV Metadata Injector to inject the
>>>>>>>> metadata
>>>>>>>> such is width, height, framerate and etc. And i saw that the
>>>>>>>> framerate
>>>>>>>> is
>>>>>>>> around 7.3 and 7.4fps.
>>>>>>>>
>>>>>>>> Using the FLV Metadata Injector on flv files that are recorded
>>>>>>>> on Red5
>>>>>>>> 0.8
>>>>>>>> RC1, i get framerate of 15fps.
>>>>>>>>
>>>>>>>> Anyone that is facing this problem, could you also verify this?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>> edjayks wrote:
>>>>>>>>>
>>>>>>>>> Anyone have any idea what is causing the problem and how to
>>>>>>>>> fix it?
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rhys Causey-2 wrote:
>>>>>>>>>>
>>>>>>>>>> I think I'm experiencing the same issue with the trunk. The
>>>>>>>>>> file is
>>>>>>>>>> saved by Red5, it opens and somehow plays fine in Adobe Media
>>>>>>>>>> Player,
>>>>>>>>>> but the audio stutters if I play it in VLC (video is fine),
>>>>>>>>>> and it
>>>>>>>>>> skips if I stream it from Red5 (similar behaviour to what you
>>>>>>>>>> described -- plays for a few seconds, stops, plays again,
>>>>>>>>>> stops,
>>>>>>>>>> etc).
>>>>>>>>>> It also takes a much longer time to start than other video
>>>>>>>>>> files.
>>>>>>>>>>
>>>>>>>>>> It worked okay in the previous version of Red5 that I was using
>>>>>>>>>> (startup log says revision 3607 -- not sure if this is
>>>>>>>>>> accurate).
>>>>>>>>>>
>>>>>>>>>> Rhys
>>>>>>>>>>
>>>>>>>>>> On 14-Jul-09, at 10:12 AM, edjayks wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi walter, that is exactly the problem I'm facing now.
>>>>>>>>>>> Nice to know that I'm not alone on this.=^D
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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@...>
>>>>>>>>>>>> To: <Red5@...>
>>>>>>>>>>>> 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@...>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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-tp24403684p24480315.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-tp24403684p24514009.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-tp24403684p24527000.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-tp24403684p24529382.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-tp24403684p24602421.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

Re: Saved live stream problem

by Julien KRIVACSY :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

It's working well for me. I'm using saveAs and stopRecording to record live stream and it's working.

Julien
Le 24 juil. 09 à 16:36, Ignacio Lopez a écrit :

Has anybody taken this into account and submitted an issue to the red5 issue tracker so it does not get forgotten?
It sounds like there may be something funky in 0.8......


On Wed, Jul 22, 2009 at 5:55 AM, edjayks <edjayks@...> wrote:

Instead of using .saveAs() and .stopRecording() in ClientBroadcastStream, is
there other interface or classes that i could use to record stream?


edjayks wrote:
>
> Hi, I'm using the client provided in Red5
> http://localhost:5080/demos/publisher.html
>
> I'm trying to use xuggle now to listen to the stream in red5 (just
> started, don't know whether it would works) and save it to .flv, so that i
> don't rely on Red5's stream recording function. What do you think about
> this?
>
> Do you have other idea or workaround? Because i really need stream
> recording on the server.
>
> Thanks.
>
>
> Gavriloaie Eugen-Andrei wrote:
>>
>> Your low fps rate has absolutely nothing to do with the bandwidth. I
>> have the same problem. I fact, I still have it from time to time. I'm
>> using Mac OS X Leopard and from time to time, the built-in camera just
>>
>> To verify this, you could try downloading the following swf file and
>> play with the settings there (btw, what are you using right now? Would
>> you like to share that swf file also? It would be great to have anoth
>>
>> http://rtmpd.com/browser/trunk/docs/simpleLive/simpleLive.swf
>>
>> you can find the download link just below. Something like this: "Try
>> downloading the file instead"
>>
>>
>>
>> On Jul 17, 2009, at 9:45 AM, edjayks wrote:
>>
>>>
>>> Is there other way to record stream on the server?
>>> Can xuggle be used to listen to stream in red5 and then save it
>>> into .flv
>>> file?
>>>
>>>
>>> edjayks wrote:
>>>>
>>>> Tried bumping up to 48Kbytes and drop to 20% quality. Resolution
>>>> set at
>>>> 160x120.
>>>> I still get 7fps only.
>>>> When i record it on Red5 0.8.0RC1, I get 15 fps.
>>>>
>>>> And again, all test run in the same computer(red5 and client on same
>>>> computer), so the same webcam and mic is used throughout the test.
>>>>
>>>>
>>>> Walter Tak wrote:
>>>>>
>>>>> 1. make sure your videosetting is supported by the camera you use.
>>>>> Normally
>>>>> resolutions are like 320x240, 320x200, 160x120 etc. Your camera
>>>>> (driver)
>>>>> might lock up or Flash Player has to compensate and will actually
>>>>> capture
>>>>> data at 160x120 and stretch the image to your custom resolution
>>>>>
>>>>> 2. 32 kbytes and 75% quality might result in less than 15 fps.
>>>>> Imagine
>>>>> this
>>>>> ; you instruct the FP to create frames of only 32768 / 15 = 2184
>>>>> bytes
>>>>> each.
>>>>> Lower the quality and check again. Perhaps just at 40% quality you
>>>>> might
>>>>> achieve 15 fps.
>>>>>
>>>>> 3. audio really can take up quite some bandwidth. NellyMoser 22 kHz
>>>>> stereo
>>>>> might do around 4 kbytes/sec, that leaves just 28 kbytes for 15
>>>>> frames.
>>>>>
>>>>> Just play with the 2 settings. Increase the 32 kbytes, lower the
>>>>> quality,
>>>>> until it gives results you like.
>>>>>
>>>>> Then test with multiple webcams ; they all behave different. Even
>>>>> webcams
>>>>> from the same make like Logitech act different from say Microsoft
>>>>> webcams.
>>>>> Lot's of variables :)
>>>>>
>>>>>
>>>>>> Hi Walter, thanks for the information. I do understand that on an
>>>>>> internet
>>>>>> connection, i wouldn't be able to get 15fps constantly.
>>>>>> But, the testing i'm doing in on a local pc, Red5 and the client is
>>>>>> running
>>>>>> on the same computer, would flash player still drop frame?
>>>>>> The video settings are: 183x170(width x height), fps 15, quality
>>>>>> 75%,
>>>>>> max
>>>>>> bandwidth 32768 bytes per seconds, audio is set at 22khz.
>>>>>>
>>>>>>
>>>>>> Walter Tak wrote:
>>>>>>>
>>>>>>> If you set the 15 fps on the client that gives no guarantee that
>>>>>>> your
>>>>>>> flash
>>>>>>> player actually sends 15 frames/sec to the server.
>>>>>>>
>>>>>>> If it can it will but if your setQuality for example is very
>>>>>>> high it
>>>>>>> might
>>>>>>> even just send 1 frame per second to the server.
>>>>>>>
>>>>>>> See
>>>>>>> http://wiki.mediabox.fr/PDF/astro_langRefStandalone/flash/media/Camera.html#setQuality
>>>>>>> ()
>>>>>>>
>>>>>>> If you'd use [ setQuality(32000, 100);  ] then Flash would send
>>>>>>> out
>>>>>>> frames
>>>>>>> each with 100% quality.
>>>>>>> If a frame would exceed 32 Kb in size (and it will @ 100%
>>>>>>> quality) then
>>>>>>> Flash would send less than 1 frame per second to the server.
>>>>>>>
>>>>>>> How can you always output 15 fps ? Well you can't. If the user is
>>>>>>> moving
>>>>>>> very fast in front of his webcam then Flash needs
>>>>>>> more than the available bandwidth (32 Kb). How much more ? You
>>>>>>> can't
>>>>>>> calculate that. You could set the bandwidth to 0 (zero) which
>>>>>>> means,
>>>>>>> use whatever you want, but you will hit the maximum upstream
>>>>>>> capacity
>>>>>>> of
>>>>>>> your user (say 512 kbit or 1 mbit on xDSL lines) and Flash still
>>>>>>> doesn't send out exactly 15 fps.
>>>>>>>
>>>>>>> You can watch the incoming fps of a video using
>>>>>>> "NetStream.currentFPS"
>>>>>>> :
>>>>>>> http://wiki.mediabox.fr/PDF/astro_langRefStandalone/flash/net/NetStream.html#currentFPS
>>>>>>>
>>>>>>> (copy the FPS to some TextField using a Timer or ENTER_FRAME
>>>>>>> event to
>>>>>>> keep
>>>>>>> an eye on it)
>>>>>>>
>>>>>>> It will probably show very varying results.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: "edjayks" <edjayks@...>
>>>>>>> To: <Red5@...>
>>>>>>> Sent: Thursday, 16 July 2009 12:39
>>>>>>> Subject: Re: [Red5] Saved live stream problem
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Did some testing:
>>>>>>>> A client publishes his webcam at 15fps, on the server i use
>>>>>>>> save.As()
>>>>>>>> to
>>>>>>>> record the stream.
>>>>>>>> Then i use a program called FLV Metadata Injector to inject the
>>>>>>>> metadata
>>>>>>>> such is width, height, framerate and etc. And i saw that the
>>>>>>>> framerate
>>>>>>>> is
>>>>>>>> around 7.3 and 7.4fps.
>>>>>>>>
>>>>>>>> Using the FLV Metadata Injector on flv files that are recorded
>>>>>>>> on Red5
>>>>>>>> 0.8
>>>>>>>> RC1, i get framerate of 15fps.
>>>>>>>>
>>>>>>>> Anyone that is facing this problem, could you also verify this?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>> edjayks wrote:
>>>>>>>>>
>>>>>>>>> Anyone have any idea what is causing the problem and how to
>>>>>>>>> fix it?
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rhys Causey-2 wrote:
>>>>>>>>>>
>>>>>>>>>> I think I'm experiencing the same issue with the trunk. The
>>>>>>>>>> file is
>>>>>>>>>> saved by Red5, it opens and somehow plays fine in Adobe Media
>>>>>>>>>> Player,
>>>>>>>>>> but the audio stutters if I play it in VLC (video is fine),
>>>>>>>>>> and it
>>>>>>>>>> skips if I stream it from Red5 (similar behaviour to what you
>>>>>>>>>> described -- plays for a few seconds, stops, plays again,
>>>>>>>>>> stops,
>>>>>>>>>> etc).
>>>>>>>>>> It also takes a much longer time to start than other video
>>>>>>>>>> files.
>>>>>>>>>>
>>>>>>>>>> It worked okay in the previous version of Red5 that I was using
>>>>>>>>>> (startup log says revision 3607 -- not sure if this is
>>>>>>>>>> accurate).
>>>>>>>>>>
>>>>>>>>>> Rhys
>>>>>>>>>>
>>>>>>>>>> On 14-Jul-09, at 10:12 AM, edjayks wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi walter, that is exactly the problem I'm facing now.
>>>>>>>>>>> Nice to know that I'm not alone on this.=^D
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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@...>
>>>>>>>>>>>> To: <Red5@...>
>>>>>>>>>>>> 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@...>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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-tp24403684p24480315.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-tp24403684p24514009.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-tp24403684p24527000.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-tp24403684p24529382.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-tp24403684p24602421.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


_______________________________________________
Red5 mailing list
Red5@...
http://osflash.org/mailman/listinfo/red5_osflash.org
< Prev | 1 - 2 | Next >