- From: Clarke Stevens <C.Stevens@CableLabs.com>
- Date: Thu, 11 Aug 2011 11:16:14 -0600
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- CC: Scott Wilson <scott.bradley.wilson@gmail.com>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Note: I am responding to this message to change the issue number. It was previously listed as issue-34 (which is adaptive bit rate video). The issue number for ViewPort support is issue-37. The corrected issue number should help it be properly tracked. Thanks, -Clarke On 8/11/11 4:49 AM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote: >On Thu, Aug 11, 2011 at 6:59 PM, Cyril Concolato ><cyril.concolato@telecom-paristech.fr> wrote: >> Hi Scott, >> >> Le 10/08/2011 14:15, Scott Wilson a écrit : >>> >>> Well, right now you could use a<track> pointing to an SVG file if you >>> wanted to. I don't think thats a significant restriction. >>> >>> The real question is - will browsers implement support for SVG >>>documents >>> linked in<track> elements, or just WebVTT/Subrip formatted >>>synchronized >>> text files? >> >> That's a good question. Given that they all implement SVG, including >> animations, I don't think it would be too hard to implement for them. >>But >> it's a guess. > >If you want to put SVG into WebVTT cues and pick them up over the >timeline of the video through JavaScript, then throw the SVG at the >browser for decoding, that would work. You can do that now with >@kind=metadata on <track> and using getCueAsSource() to extract the >SVG. > > >Cheers, >Silvia. >
Received on Thursday, 11 August 2011 17:16:57 UTC