[Red5] Live video freezes with audio

[Nicolay Vizovitin]

The answers are inline.

On 9/13/09, Art Clarke <aclarke at xuggle.com> wrote:
>> Also I noticed that NetStatus events with codes "NetStream.Play.Reset"
>> and "NetStream.Play.Start" sometimes did not reach swf client (in such
>> cases one of the streams could play OK, but the other could be freezed
>> even before it received any sensible picture; so the latter looked
>> like a black screen with minor colored noise).
>
> Do you mean Red5 is generating these events, but you don't see them in
> your SWF trace logging?  If so, how do you know Red5 is generating
> them -- are there entries in the Red5 log?  If so, please paste them
> in this thread.

No, I'm not actually sure Red5 is generating those events, but they do
fire usually when stream starts to play. And therefore usually I do
see them in my SWF logging. Unfortunately I don't know how I should
set up loggers to get that kind of data into the Red5 log. But if you
explain I'll post the logs.

> Can you summarize for me the differences between the old version of
> your client that experiences the freezes, and the new version that
> doesn't?

My client resembles a conferencing tool. There are a number of windows
for video streams, and a text chat with buddy list. Client connects to
Red5 server through NetConnection. The same NetConnection is used for
all communication with the server: text chat (via SharedObject) and
video conferencing (via NetStream). For debug purposes all NetStreams
in both old and new client versions used the same name for stream.
After connection has been established client attempts to publish a
live stream from Camera and Microphone. Also some number of windows
for video are connected to the stream published on server. So, when
user launches the client he sees himself in those windows.

Now for the changes.
1) As a workaround for FP10 crash bug, I added code that attempts to
connect to a given LocalConnection and only if it succeeded access to
Camera is granted. That way maximum one FP instance is using Camera at
a time.
2) Reference to a class which publishes video (if permitted) was
assigned to method local varible. In the new version it is assigned to
a class instance variable.
3) Added number of try and catch blocks here and there. However each
catch block has some logging, so I would know if those exceptions had
really happened. Well, they actually don't in the testcase we are
interested in.

Finally, I can't wrap my head around one interesting fact. Sometimes
freeze may be significantly facilitated by interacting with client's
interface components, especially with buddy list (e.g. by just
hovering a mouse over it). Buddy list is implemented through
fl.controls.List. I thought of GC being the one to blame, but doing
only (2) did not solve the problem.


--Best regards,
  Nicolay