On Sat, Aug 21, 2010 at 10:03 AM, Eric Carlson <span dir="ltr"><<a href="mailto:eric.carlson@apple.com">eric.carlson@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
On Aug 19, 2010, at 5:23 PM, Silvia Pfeiffer wrote:<br>
<br>
><br>
</div><div class="im">> * 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.<br>


><br>
<br>
</div><div class="im">  I don't understand what you mean here, can you explain?<br>
<br>
</div> <br></blockquote><div><br>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.<br><br>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).<br>

<br>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. :-)<br>

<br>Cheers,<br>Silvia.<br><br> </div></div>