- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sat, 21 Aug 2010 10:53:34 +1000
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