Re: Proposal for Audio and Video Track Selection and Synchronisation for Media Elements

On Mar 21, 2011, at 1:11 PM, Tab Atkins Jr. wrote:

> On Mon, Mar 21, 2011 at 12:59 PM, Mark Watson <watsonm@netflix.com> wrote:
>> For the case where the multiple video tracks are inband tracks in the same resource, would it make sense for the video elements in the same group to more explicitly share a source ? e.g. if no source is specified then a video element is assumed to have the same source as the other elements in the same group (which must then all have the same source) ?
> 
> That doesn't seem to make sense.  If you had the exact same @src as
> another <video>, then you'd be showing the exact same thing.

Not if you used the Javascript API to select different tracks.

>  The URLs
> in Hixie's examples used Media Fragments to target particular tracks
> of the same resource.  For most purposes, the two @src values are
> completely different resources; it just happens that they're encoded
> in the same file, so you can download a single thing and get the
> second track for free.

I'm most interested in adaptive streaming sources, which will look to this API like a resource with multiple tracks - for different languages etc. - but which, under the covers, download only the selected tracks.

You generally won't know what tracks are available in the resource until you have loaded the metadata. That would be the point at which you decide whether to create a new video element for the sign language track etc. if you find one. It seems logical to have a direct way to say "this new video element has the same source as that one, but will play a different video track".

I agree this could be just by matching URLs: I set the @src of the new element to equal the @currentSource of the main element. I'll admit to not being completely familiar with the source selection algorithms: are there scenarios in which the source of the main element might change in which you'd want the source of the sign language element to also change in sync ?

...Mark

> 
> ~TJ
> 
>

Received on Monday, 21 March 2011 23:15:01 UTC