- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Sat, 13 Aug 2011 06:23:16 +0900
- To: TV and WEB <public-web-and-tv@w3.org>
forwarding to archive with proper ISSUE ID (ISSUE-37) -------- Original Message -------- Subject: Re: [MEDIA_PIPELINE_TF] ISSUE-34: ViewPort-Support Resent-Date: Thu, 11 Aug 2011 10:50:06 +0000 Resent-From: public-web-and-tv@w3.org Date: Thu, 11 Aug 2011 20:49:19 +1000 From: Silvia Pfeiffer <silviapfeiffer1@gmail.com> To: Cyril Concolato <cyril.concolato@telecom-paristech.fr> CC: Scott Wilson <scott.bradley.wilson@gmail.com>, public-web-and-tv@w3.org 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 Friday, 12 August 2011 21:22:51 UTC