RE: Interactive Television

> -----Original Message-----
> From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-
> request@w3.org] On Behalf Of Silvia Pfeiffer
> Sent: Thursday, August 11, 2011 6:56 PM
> To: Adam Sobieski
> Cc: public-web-and-tv@w3.org
> Subject: Re: Interactive Television
> 
> Hi Adam,
> 
> what you are suggesting is already possible with the current
> specification of <track> and a @kind=metadata and the xml or json
> included in a WebVTT file's cues. We just need to wait until the
> browsers have actually implemented and released it.
> 
> That's why I was more curious to find out if we have any more specific
> application needs that actually require standardisation and suggested
> analysing them.
> 
> I think what Bob is doing sounds very interesting in this context.
> ETV, ads and parental control are indeed interesting use cases. Bob:
> do you have more information on these and specification proposals?

We are still early in our investigation. Currently we're developing how ETV, ad insertion and content advisory formats used by North American cable in MPEG-2 TS could be mapped to HTML5 metadata text track Cues. This will provide insight into what message data applications need, independent of the media delivery. This in turn will provide insight into what message formats might make sense in new types of media transport, e.g. MPEG-4 FF or DASH.

This effort also needs to be done, to some extent, for multiple audio and video tracks. Here there is no mapping of the track data but there is still the question regarding how the user agent recognizes these tracks across the supported media transport formats. I expect this will be largely defined by media transport format specs, but maybe not in all cases.

This topic will be discussed in the Web and TV IG/Media Pipeline task force, as noted in the 8/11 Media Pipeline Task Force call.

Bob 
> 
> Cheers,
> Silvia.
> 
> On Fri, Aug 12, 2011 at 1:33 AM, Adam Sobieski
> <adamsobieski@hotmail.com> wrote:
> > Silvia Pfeiffer,
> >
> > With regard to the HTML5 video track ideas, I disagree with the
> > indicated approach of analyzing exact needs and use cases first; the
> > benefits that the particular concepts bring to HTML5 video tracks are
> > sufficiently broad and general use that an exact needs and use cases
> approach seems suboptimal.
> > The best option is both XML and JSON.  Browser teams already have both
> > XML and JSON parsers and libraries handy and some data structures and
> > heuristics might be reusable between XML and JSON implementations for
> > the described <track/> object.  I like the extensiblity of XML and
> > what I like about the JSON approach is the convenient JavaScript
> syntax in the callback functions.
> >
> > I previously forwarded the XML ideas to the HTML5 working group.
> > Perhaps you can send an email describing the JSON <track/> idea to the
> > HTML5 video working group.
> >
> > Annotation as the kind for post-produced overlays sounds worthwhile.
> > I agree that exploring use cases on that makes sense.  That could
> > include an automation of some DHTML premises and perhaps some XAML
> concepts.
> >
> >
> > Kind regards,
> >
> > Adam Sobieski
> >
> >
> >> From: silviapfeiffer1@gmail.com
> >> Date: Thu, 11 Aug 2011 17:08:33 +1000
> >> Subject: Re: Interactive Television
> >> To: adamsobieski@hotmail.com
> >> CC: scott.bradley.wilson@gmail.com; public-web-and-tv@w3.org
> >>
> >> On Thu, Aug 11, 2011 at 4:35 PM, Adam Sobieski
> >> <adamsobieski@hotmail.com>
> >> wrote:
> >> > Hello Silvia,
> >> >
> >> > I like the idea about a new kind or kinds, possibly "xml" and/or
> "json".
> >> > Those could be catchalls for usage scenarios beyond the other kinds
> >> > of subtitles, captions, descriptions, chapters and metadata.
> >> > Another possible kind is outlines which resembles chapters.
> >>
> >> Metadata is already a catch-all. I think we first need to analyse
> >> what exact needs / use cases we have before making a decision.
> >>
> >>
> >> > Your example about DHTML overlays with hyperlinks sounds
> >> > interesting; DHTML overlays are possible wherever text and graphics
> >> > presently occur atop video from video post-production techniques
> >> > and new enhanced features are possible with hypertext. Video
> >> > post-production techniques can make use HTML5 video capabilities,
> >> > DHTML and overlays and so doing might provide for entirely new
> >> > features.
> >>
> >> We should then consider asking for a @kind=annotation and specify
> >> this use case some further. Also JSON may not necessarily the best
> >> solution for this use case. We should experiment with JavaScript
> >> first. This way we can identify the best possible solution.
> >>
> >> > I think that more kinds alleviates a misunderstanding that under
> >> > discussion was some sort of alternative to WebVTT. WebVTT seems apt
> >> > for its set of kinds and could even be of use in convergence
> >> > scenarios such as digital cable. New kinds for HTML5 video tracks,
> >> > "xml" and/or "json", can allow for more Flash-like functionality
> >> > with HTML5. By specifying an XML format with at least attributes
> >> > for temporal intervals, any XML that makes use of that XMLNS could
> >> > include time synchronization data that <track/> expects.
> >>
> >> Yes, WebVTT is designed to be a general container for
> >> time-synchronized data. But as I said: we should analyse the use
> >> cases in more detail and come up with better means of semantically
> >> labelling the included data than by format.
> >>
> >> > With regard to HTML5 video, it seems that new kinds are exciting to
> >> > discuss.
> >>
> >> Very much so!
> >>
> >> Cheers,
> >> Silvia.
> >

Received on Tuesday, 16 August 2011 16:29:08 UTC