W3C home > Mailing lists > Public > public-web-and-tv@w3.org > August 2011

[MEDIA_PIPELINE_TF] ISSUE-37: ViewPort-Support

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>
Message-ID: <CA6969EB.EE19%c.stevens@cablelabs.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:07 UTC