Re: Handling simulcast

On 2013-09-06 19:31, Harald Alvestrand wrote:
> 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)

Haven't we said previously that the video track to play is determined by 
"selected" property on the VideoTrack in the media element 
VideoTrackList [1], and that is the video played (regardless of 
combinations of enabled/disabled/muted on the individual video tracks in 
the MediaStream)?

To me it seems that it is there we should specify if we want to enable 
another behavior (e.g. rather then have the script change which track 
that is "selected" tell the media element to play the active track). The 
app can then make sure that only the MediaStream-video track it wants 
played is enabled.

The problem with getting the disabled/paused info over the net remains 
though.

[1] 
http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#videotracklist

>
> 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:59:24 UTC