[Red5] video-conferencing, improving reliability, dropping frames from buffer

Wed Dec 31 11:11:10 PST 2008

Yes, this is a live stream.  It doesn't really appear that the memory
consumption of Red5 is out of the norm.  It hovers around 8-12%.

It's interesting that if I stop the video, the client continues to play
until it reaches the point where I stopped.  So, it's like all the video is
buffered somewhere and continues to flush the buffer, playing the video
until the buffer is empty... Question is, where?  Is it on the server side
or the client side?

It "feels" (totally without technical basis or merit) like it's sending the
video via TCP and TCP is doing its job making sure every packet reaches its
destination.  TCP will not loose a packet until its buffer is full and
overflows.  I think all TCP knows is that it sent a packet and it was
successfully received.  If that's the case, the buffer is building on the
client side.

What I don't know is if Red5 is using standard Windows sockets or managing
the TCP transmission itself.  If it's using Windows sockets, I'm not sure
there's much that can be done on the server side... Heck, I don't know what
can be done on the client side either for that matter.  Definitely an issue
for someone a lot smarter than me!  ;-)

Steve

rfkrocktk wrote:
> 
> Interesting thread. Is it a live (non-recorded) stream? And if so, have
> you
> noticed Red5's memory consumption start to increase? If over time you
> notice
> that the memory consumption of Red5 starts to get ridiculous, it's
> definitely a way to troubleshoot what's happening in the server.
> 
> This might just be a bug somewhere in the streaming mechanisms of Red5, I
> don't think this is a TCP problem. If it is a standard TCP problem, a lot
> of
> things will have to be fixed to adapt for it. TCP verifies that the
> packets
> get to where they're going, so if a lag starts to happen, frame dropping
> would have to happen at *exactly* the right place to ensure that it stops
> the new data from being sent.
> 
> On Tue, Dec 30, 2008 at 1:56 PM, SteveRicketts
> <velocedge at hotmail.com>wrote:
> 
>>
>> Jacob,
>>
>> Yes, it is an increasing delay.  I could live with a 1-3 second delay
>> with
>> no problem whatsoever!!  But in some cases the delay just continues to
>> increase.   It appears to happen when some clients just don't have the
>> bandwidth to keep up and nothing ever gets dropped.
>>
>> I really appreciate your response.  Let me know if there is anything I
>> can
>> do to help you... although my Java skills mostly suck!  ;-)
>>
>> Thanks again for any attention you can provide on this issue,
>>
>> Steve
>>
>>
>>
>>
>> Jacob Everist wrote:
>> >
>> > Steve,
>> >
>> > I remember reading this thread.  Are you having problems with an ever
>> > increasing delay or do you have a fixed delay that you're trying to
>> > reduce?  Like I said, my live A/V stream is constantly increasing its
>> > delay to those subscribing overseas.  1-3 second delay is fine with
>> > me, but having this delay increase over time is not acceptable.  It
>> > should be capped, dropping frames if necessary.
>> >
>> > I guess I need to look at the structure of Red5 to see how to make
>> > this work.  :(
>> >
>> > Jacob Everist
>> >
>> > On Tue, Dec 30, 2008 at 9:53 AM, SteveRicketts <velocedge at hotmail.com>
>> > wrote:
>> >>
>> >> Good luck on this.  There is a thread I've been following that's
>> looking
>> >> at
>> >> the buffer problem being out of synch.  You might want to take a look
>> at
>> >> it:
>> >>
>> >>
>> http://www.nabble.com/How-make-flash-player-to-stop-buffering-live-stream.-td18867639.html
>> >>
>> >> It seems to be a very difficult problem and as of yet, I've not seen a
>> >> good
>> >> answer for how to fix the ever growing delay.  If you find someone to
>> >> help,
>> >> I might be able to chip in a bit to get it resolved myself!  ;-)
>> >>
>> >> Steve
>> >>
>> >>
>> >>
>> >>
>> >> Jacob Everist wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I've got a simple video-conferencing app going on Red5.  I just
>> >>> publish and subscribe video streams of all the users in a context
>> >>> (scope?).  There's no custom Java code written for this, only Flash.
>> >>>
>> >>> Now I need to make some modifications to improve the reliability and
>> >>> also drop frames from the server-side buffer when the buffer gets too
>> >>> large (sometimes my conversations have become 30 seconds out of
>> sync!)
>> >>>
>> >>> Any guidance on where I can start to look to fix the buffer issue?
>> >>>
>> >>> I also haven't defined the "reliability" problem very well.  Is there
>> >>> a list of common issues and fixes out there for performance and
>> >>> reliability?
>> >>>
>> >>> Better yet, would someone be willing to work on this problem for a
>> >>> reasonable fee?
>> >>>
>> >>> --
>> >>>
>> >>> Jacob Everist
>> >>>
>> >>> _______________________________________________
>> >>> Red5 mailing list
>> >>> Red5 at osflash.org
>> >>> http://osflash.org/mailman/listinfo/red5_osflash.org
>> >>>
>> >>>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/video-conferencing%2C-improving-reliability%2C-dropping-frames-from-buffer-tp21200097p21220689.html
>> >> Sent from the Red5 - English mailing list archive at Nabble.com.
>> >>
>> >>
>> >> _______________________________________________
>> >> Red5 mailing list
>> >> Red5 at osflash.org
>> >> http://osflash.org/mailman/listinfo/red5_osflash.org
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > Jacob Everist
>> >
>> > _______________________________________________
>> > Red5 mailing list
>> > Red5 at osflash.org
>> > http://osflash.org/mailman/listinfo/red5_osflash.org
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/video-conferencing%2C-improving-reliability%2C-dropping-frames-from-buffer-tp21200097p21223706.html
>> Sent from the Red5 - English mailing list archive at Nabble.com.
>>
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
> 
> 
> 
> -- 
> And do this, knowing the time, that now it is high time to awake out of
> sleep;
> for now our salvation is nearer than when we first believed.
> 
> _______________________________________________
> Red5 mailing list
> Red5 at osflash.org
> http://osflash.org/mailman/listinfo/red5_osflash.org
> 
> 

-- 
View this message in context: http://www.nabble.com/video-conferencing%2C-improving-reliability%2C-dropping-frames-from-buffer-tp21200097p21235976.html
Sent from the Red5 - English mailing list archive at Nabble.com.