W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2012

Re: [whatwg] Comments about the track element

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 26 Jul 2012 08:54:40 +1000
Message-ID: <CAHp8n2=iOvfmzdVqtVRhknTE=pmdMrb7s4ACqnB=18O+q-wssQ@mail.gmail.com>
To: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Cc: whatwg@lists.whatwg.org, Henri Sivonen <hsivonen@iki.fi>
On Wed, Jul 25, 2012 at 11:51 PM, Cyril Concolato
<cyril.concolato@telecom-paristech.fr> wrote:
> Hi Silvia,
>
> Le 7/25/2012 3:42 PM, Silvia Pfeiffer a écrit :
>
>> On Wed, Jul 25, 2012 at 10:55 PM, Henri Sivonen<hsivonen@iki.fi>  wrote:
>>>
>>> On Wed, Jul 25, 2012 at 11:24 AM, Silvia Pfeiffer
>>> <silviapfeiffer1@gmail.com>  wrote:
>>>>
>>>> But you can use cue.text and parse it as a SVG fragment.
>>>
>>> That would be RSS all over again. :-(
>>
>> To some extent. If we are very clear about what will be in the cues
>> and that it will always be just SVG, we could just create a
>> @kind="svg".
>
> The SVG WG resolved to write a document describing how to store SVG content
> into streaming packets (or cues) whether full documents or document
> fragments for progressive loading of content. I'll be the editor of this
> document. You can already have an idea of what would be in this document
> looking at http://www.w3.org/Graphics/SVG/WG/wiki/SVGStreaming. I plan to
> talk about cue content and associated signaling timing, random access point
> ...

I think the @mediagroup approach is indeed better, in particular for
SVG content that should synchronize frame-by-frame.

Silvia.
Received on Wednesday, 25 July 2012 22:55:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:09 GMT