On Tue, Aug 24, 2010 at 1:07 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 style="word-wrap:break-word"><br><div><div><div></div><div class="h5"><div>On Aug 20, 2010, at 5:53 PM, Silvia Pfeiffer wrote:</div><br><blockquote type="cite">On Sat, Aug 21, 2010 at 10:03 AM, Eric Carlson <span dir="ltr"><<a href="mailto:eric.carlson@apple.com" target="_blank">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><br>
On Aug 19, 2010, at 5:23 PM, Silvia Pfeiffer wrote:<br>
<br>
><br>
</div><div>> * 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>  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></div></div></blockquote><blockquote type="cite"><div class="gmail_quote">

<div>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></div></div></blockquote><blockquote type="cite"><div class="gmail_quote"><div>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></div></div></blockquote></div></div><div>  Even in the hypothetical case where the external text track is already in a format supported by the media container file, saving will require the UA to regenerate the movie's "table of contents" (eg. the 'moov' atom in MPEG-4 or QuickTime files, Meta Seek Information in a WebM file) as well as muxing the text track with the other media data. </div>

<div><br></div><div>  As you note transcoding is "a bit more complex", especially in the case where a feature in the text track format is not supported by the text format of the native container.</div><div><br>
</div>
<div>  Further, what should a UA do in the case where the native container format doesn't support any form of text track - eg. mp3, WAVE, etc?</div></div></div></blockquote><div><br><br>Well, for those you cannot obviously expect a single download file. Maybe it makes sense to just have a download functionality that allows downloading the text tracks as well. I was just following on from some of the user requirements raised in this thread.<br>

<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div>  I disagree that it is not a complex feature, but I do agree that it is outside of the scope of the HTML spec.</div>

</div></div></blockquote><div><br><br>I guess the complexity really depends on the format in use. For Ogg there is plenty of software available to demux and remux bitstreams, which is the main functionality here. The second part is the encoding of the text track, which again for Ogg has separate tools and libraries. After downloading the text tracks and the Ogg file separately, I would find it very easy to create a new multiplexed file using all these tools. That's where my judgement of "simple" came from. But you are probably right and it's a lot more complicated for other formats.<br>

<br>Enough off-topic brainstorming. ;-) I think we have more important things to solve right now.<br><br>Cheers,<br>Silvia.<br><br></div></div>