W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2011

Re: Spec question - multiple video tracks in a MediaStream?

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 25 Aug 2011 13:16:47 +0200
Message-ID: <4E562F1F.3070002@alvestrand.no>
To: public-webrtc@w3.org
On 08/25/11 12:44, Stefan Håkansson LK wrote:
> On 2011-08-25 11:34, Harald Alvestrand wrote:
>> This came up on my team while implementing, and I'm posting it so we do
>> not forget:
>> If there are multiple video tracks active in a MediaStream, how should
>> we connect them to<video>  tags?
>> At the moment, the connection goes via URLs, and the URL is a function
>> of the MediaStream, not of a track in the MediaStream. And I don't think
>> <video>  has a defined behaviour for playing multiple video tracks at 
>> once.
>> Possible solutions:
>> - Declare that there can be at most one video track active in a
>> MediaStream (this was true at one point)
>> - Give the URL-generating function an optional parameter for the track
>> index (defaulting to first video)
>> - Feed the URL-generating function a track instead of a MediaStream
>> - Just leave this behaviour undefined?
> One solution is outlined in step 9 of 
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#getting-media-metadata> 
> (selects the first active video track for rendering).
This text is:


      If either themedia resource
      the address of thecurrent media resourceindicate a particular set
      of audio or video tracks to enable, then the selected audio tracks
      must be enabled in the element's|audioTracks
      and, of the selected video tracks, the one that is listed first in
      the element's|videoTracks
      must be selected

I don't have a problem with that; if we have 2 video tracks and need to 
show them both, we can duplicate the MediaStream and disable the 1st 
track in the copy, then feed them to different <video> tags.

The behaviour of <video> is something we don't want to specify in our 
document if we can avoid it, I think.
Received on Thursday, 25 August 2011 11:17:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC