Re: Handling simulcast

On 09/06/2013 07:10 PM, Martin Thomson wrote:
> On 6 September 2013 02:17, Harald Alvestrand <harald@alvestrand.no> wrote:
>> What we could do, hypothetically, to automate this is to suggest that the
>> HTML5 media load algorithm be changed - add a step on video playback that
>> says something like:
>>
>> "If multiple video streams are present in the resource, and the currently
>> selected video stream does not provide data that allows a picture to be
>> rendered at that time, the user agent may switch to the next enabled video
>> stream in the resource for the duration of the lack of data".
> That doesn't work in the general cases where there could be multiple
> tracks available, one showing the other speaker, the other showing a
> completely different scene.  Switching automatically would be bad.
>
>> The unsolved problem here is to make sure the user agent picks the streams
>> in the right order.
> Didn't we decide to remove track ordering?  Yes, that is hard.  How
> does the browser decide that track A is "better" than track B?  (I
> know how we might signal that in SDP, but that isn't the only source
> of metainformation about tracks, because RTCPeerConnection isn't the
> only source of tracks.
>
If we remain on the JS-driven model, I think it probably needs the 
addition of some type of call to set the playback fallback order:

mediaStream.setPlaybackFallback(track1, track2, track3)

But yes, I do think letting the UA handle the switch-down will work 
better than letting JS do it - which means that somehow, the signal "I'm 
deliberately not providing you video on this track" needs to be propagated.

SDP "a=inactive" is one way, which requires a signalling round trip 
(through whatever mechanism is being used for signalling).

TMMBN=0 is another.

draft-westerlund-avtext-rtp-stream-pause (expired October 2012) is a third.

It's not the lack of proposals that is preventing forward movement.....

Received on Friday, 6 September 2013 17:30:09 UTC