- 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