W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] On implementing videos with multiple tracks in HTML5

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 21 Aug 2010 10:53:34 +1000
Message-ID: <AANLkTik=Wm5f0_p-Zg25n5+6_DEb7txTZk44q_7h84QK@mail.gmail.com>
On Sat, Aug 21, 2010 at 10:03 AM, Eric Carlson <eric.carlson at apple.com>wrote:

>
> On Aug 19, 2010, at 5:23 PM, Silvia Pfeiffer wrote:
>
> >
> > * Whether to include a multiplexed download functionality in browsers for
> media resources, where the browser would do the multiplexing of the active
> media resource with all the active text, audio and video tracks? This could
> be a context menu functionality, so is probably not so much a need to
> include in the HTML5 spec, but it's something that browsers can consider to
> provide. And since muxing isn't quite as difficult a functionality as e.g.
> decoding video, it could actually be fairly cheap to implement.
> >
>
>   I don't understand what you mean here, can you explain?
>
>
>

Sure. What I mean is: you get a video resource through the <video> element
and a list of text resources through the <track> element. If I as a user
want to take away (i.e. download and share with friends) the video file with
the text tracks that I have activated and am currently watching, then I'd
want a download feature that allows me to download a single multiplexed
video file with all the text tracks inside. Something like a MPEG-4 file
with the <track> resources encoded into, say, 3GPP-TT. Or a WebM with WebSRT
encoded (if there will be such a mapping). Or a Ogg file with WebSRT - maybe
encoded in Kate or natively.

The simplest implementation of such a functionality is of course where the
external text track totally matches the format used in the media resource
for encoding text. Assuming WebM will have such a thing as a WebSRT track,
the "download" functionality would then consist of multiplexing a new WebM
resource by re-using the original WebM resource and including the WebSRT
tracks into that. It wouldn't require new video and audio encoding, since
it's just a matter of a different multiplexed container. If transcoding to
the text format in the native container is required, then it's a bit more
complex, but no less so than what we need to do for extracting such data
into a Web page for the JavaScript API (it's in fact the inverse of that
operation).

So, I wouldn't think it's a very complex functionality, but it certainly
seems to be outside the HTML spec and a browser feature, possibly at first
even a browser plugin. Sorry if this is now off topic. :-)

Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100821/e7a65fbc/attachment.htm>
Received on Friday, 20 August 2010 17:53:34 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:26 UTC