- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Mon, 13 Feb 2012 18:04:36 +0100
- To: public-webrtc@w3.org
On 02/13/2012 04:05 PM, Randell Jesup wrote: > On 2/13/2012 9:49 AM, Stefan Hakansson LK wrote: >> On 02/13/2012 03:23 PM, Randell Jesup wrote: >>> We've discussed it once or twice - muted tracks should generate >>> *something* until/unless signaling allows them to be turned off. We >>> found in our videophone company that 'black' was a bad choice for video, >>> as it confuses users ("is something broken?") >> >> My thinking was not that the black video would ever be shown, but rather >> that the application receiving it would detect that is was black and >> replace it with some image (detecting a certain color is quite simple >> with a canvas element). Not that I am saying black is a good choice. I >> guess transparency can be detected as well - so it could even be >> transparent. > > You can't guarantee what a destination will do with 'black' (even > assuming it goes through unmolested), and if gatewayed to other > equipment/networks ("legacy"), you're right out of luck. I think we know what will happen if the other side is another browser, but you're 100% correct that in a gatewayed scenario we may have worse success. > We (WorldGate) originally had a closed network, and just used > side-signaling over RTCP APP and 'black' for mute. When we started > interoperating with other devices, we had to replace black with a mute > image to avoid confusion. > > Also, 'black' means you ust run a "is frame black" test on every > frame... Just to support a mute image. Ugh. :-) I think you can do some smarter processing (test every nth frame, select a subset of the pixels). But I think your proposal of sending a mute image is interesting, and much more robust. >
Received on Monday, 13 February 2012 17:05:00 UTC