Fwd: Re: [MEDIA_PIPELINE_TF] ISSUE-37: ViewPort-Support

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 09:36:27 +0000
Resent-From: public-web-and-tv@w3.org
Date: Thu, 11 Aug 2011 11:35:55 +0200
From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Organization: Telecom ParisTech
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: public-web-and-tv@w3.org

Hi Sylvia,

> Can you fill the TextTrack object and the cues from a SVG? As long as
> you can make a mapping, it's possible. If the format doesn't fit with
> the elements, then it's an orthogonal concept that won't fit the bill.
Reading http://www.w3.org/TR/html5/video.html#text-track it says:
"A text track consists of:"
* "The kind of text track": would apply to SVG tracks
* "A label": would apply to SVG tracks
* "A language": would apply to SVG tracks
* "A readiness state": would apply as well
* "A mode": same
* "A list of zero or more cues"

A Cue is defined as:
* "An identifier": applicable to SVG tracks

* "A start time"/"An end time":
As such SVG does not define frame-based content as Flash would do or other subtitling formats, but you can define frame-based content such as:

* A pause-on-exit flag:
not sure what it means but seems applicable

* A writing direction: when restricted to unidirectional text content, itwould be applicable but I don't see it in the TextTrackCue object (http://www.w3.org/TR/html5/video.html#texttrackcue)

* A size:
not sure I understand why it's not 2 numbers but it could match the SVG width (also not in the interface)

* The text of the cue:
if the SVG animation contains text, it could be passed, if not, could be an empty string (or the content of a <desc> element) if required.

The active flag: applicable
The display state: applicable

What I'm trying to say is that it seems very restrictive to limit the track element to pure text tracks. It disables interesting use cases (synchronized graphics overlay) while options to do it are there with SVG, already implemented in browsers.

> In my understanding, SVG has a complex DOM that goes far beyond what
> TextTrack is capable of representing.
I don't get this point. The definition of a TextTrack element should not care about the expressiveness of the language used to represent the text content as long as this language can be mapped to the TextTrack features:if it has graphics or not, if it can do bold/italic or not, if it can dobidi text or not ...

> So, I think it's too rich a
> format for the feature.
"Oh I don't want your color TV, I just need a black-and-white one".

> Of course you can always throw any format at a HTML element.However,
> if browsers don't support it, you can only deal with it through
> JavaScript - so it's not a standardised feature and not really
> relevant to the W3C.
SVG is not any format. It's a W3C format. I think it's relevant.


Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France

Received on Friday, 12 August 2011 21:22:22 UTC