In case anyone read this thread I ended up figuring out what was
happening. 

In my video conf component I would listen for events dispatched when a
new stream was published by a conference member.  As it turns out, on
Mac and Windoze Firefox 2.x the flash player would garbage collect the
NetStream objects unless I kept a map with a reference to the stream. 
Maybe this is expected behavior, but on IE and Firefox Linux the was not
the behavior.  Oddly, I still see deleteStream calls on the server, but
the clients still happily stream as expected.  This behavior also looked
a lot like a 'frozen' stream on the client where the last rendered frame
was left displayed on the Video component.

-Jeff

Jeff Simpson wrote:
> I'm still trying to figure this out, but not having much luck.  I moved 
> to the latest trunk build of red5 as of this morning, rev 2065.
>
> Anyways, I've tried various things like reducing the video size, fps 
> from 24 to 15 and fiddling with keyframe settings, etc.  None of these 
> changes seem to effect the outcome.  Eventually, it could be 1 to 2 
> seconds or a couple minutes, the flash player is invoking the 
> deleteStream service.  I don't understand why deleteStream would be 
> called on a live stream.
>
> Any clues?
>
> Thanks,
> -Jeff
>
> Jeff Simpson wrote:
>   
>> I'm not certain this is a Red5 problem, but I was hoping someone can
>> help anyways since I'm seeing the message in the logs.
>>
>> I have an application with some video conferencing functionality.   In
>> the simplest case there are two users both publishing streams and both
>> consuming each other's stream.  I'm using a single NetConnection to Red5
>> (although I tried creating a separate connection for the video streams,
>> but it did the same thing).  It seems as though seemingly random
>> activity in the app causes a deleteStream message to be sent to the
>> server.  It always seems to happen on my G4 Powerbook, 1.5mhz, 1gig
>> ram.  While displaying the local video stream it appears to be between
>> 70-90% CPU usage.  Oddly, when the error occurs the mac is still
>> publishing it's stream because I can see it on the linux client.  My
>> Linux machine seems to exhibit very little Firefox load streaming video
>> (maybe 10%).
>>
>> Anyways, here's the error:
>>
>> [INFO] 2476906 pool-3-thread-6:(
>> org.red5.server.net.rtmp.RTMPConnection.receivedBytesRead ) Client
>> received 36815426 bytes, written 36815426 bytes, 0 messages pending
>> [INFO] 2482786 pool-3-thread-11:(
>> org.red5.server.net.rtmp.RTMPConnection.receivedBytesRead ) Client
>> received 36881197 bytes, written 36881197 bytes, 0 messages pending
>> [INFO] 2483873 pool-3-thread-7:(
>> org.red5.server.net.rtmp.RTMPConnection.updateBytesRead )
>> StreamBytesRead: 33423525
>> [INFO] 2489544 pool-3-thread-16:(
>> org.red5.server.net.rtmp.RTMPConnection.receivedBytesRead ) Client
>> received 36948848 bytes, written 36949041 bytes, 0 messages pending
>> [INFO] 2490307 pool-3-thread-1:(
>> org.red5.server.net.rtmp.RTMPHandler.onInvoke ) call: Service: null
>> Method: deleteStream Num Params: 10: 1
>> [INFO] 2490307 pool-3-thread-1:(
>> org.red5.server.net.rtmp.RTMPHandler.onInvoke ) --deleteStream
>> [INFO] 2515968 pool-3-thread-9:(
>> org.red5.server.net.rtmp.RTMPConnection.updateBytesRead )
>> StreamBytesRead: 11059854
>>
>> The other client in this scenario is a Gentoo box running the latest
>> debug flash player (both machines use Firefox).
>>
>> >From the log info it appears the client is initiating this deleteStream
>> call?  Anyone seen this before? 
>>
>> BTW, I'm using Red5-0.6 final hosted on Gentoo.
>>
>> Thanks,
>> -Jeff
>>
>> _______________________________________________
>> Red5 mailing list
>> [email protected]
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>   
>>     
>
> _______________________________________________
> Red5 mailing list
> [email protected]
> http://osflash.org/mailman/listinfo/red5_osflash.org
>   
_______________________________________________
Red5 mailing list
[email protected]
http://osflash.org/mailman/listinfo/red5_osflash.org

Reply via email to