Client Ad Insertion (ISSUE-31)

clarke: start use case discussion

<Clarke> Use case 1: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Client_Ad_Insertion

issue-31?

<trackbot> ISSUE-31 -- Client Ad Insertion -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/31

clarke: (explains the use case - issue-31)
... overlay and insertion
... local addition

jan: question about in-band/out-of-band
... SCTE 35 covers both?

clarke: does cover in-band
... what about out-of-band, Mark?

mark: don't know

jan: can check

clarke: also allows local content to be played
... and added
... application besides advertisement should be supported
... also some requirements derived
... timed text cue
... for advertisement

<JanL_> +q

clarke: may be multiple media streams
... content segment specified by time
... overlay over the existing stream
... any requirements or questions?

jan: two comments
... maybe should be more generic (rather than SCTE 35)

clarke: completely agree
... not try to copy SCTE 35
... just want to SCTE 35 covered

jan: should be rather "client content insertion"

clarke: ok

Media Synchronous Web Content (ISSUE-32)

<Clarke> Use case 2: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Media_Synchronous_Web_Content

issue-32?

<trackbot> ISSUE-32 -- Media Synchronized Web Content -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/32

clarke: media synchronous Web content
... presumably streaming media content
... (explains the use case description)
... the content provider can signal messages that control Web content lifecycle
... track elements expected to only at the beginning of a media stream
... make sense?
... (motivation)
... don't have any specific standard here
... but one example is CableLabs' EISS

jan: reference to EISS?
... isn't MPEG-7 another example?

clarke: will add reference
... timed text track cue
... need to identify paused/record/etc.
... any additional requirements?

Timed Text (ISSUE-33)

<Clarke> Use case 3: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Timed_Text

issue-33?

<trackbot> ISSUE-33 -- Timed Text -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/33

clarke: just called "Timed Text"
... basically, timed text for "closed captions" and "subtitles"
... Government-mandated standards

Mark: feedback from HTML5?
... I'm not an expert of closed captions or subtitles
... but the Accessibility Group should have been working with HTML5 group

jan: old issue with <video> element
... subtitle is not by default selected
... there is a requirement put on the bugzilla
... application would know how to switch subtitles
... which one to use first and which one next
... covered by issue-18

clarke: multiple-language caption

jan: suggestion is merging issue-33 and issue-18

clarke: good idea
... anything to add, Mark?

mark: no

kaz: anybody interested in HTML5 LC comments?

mark: I'm interested but how to organize the review?

kaz: will send a message and suggest a possible procedure

<scribe> ACTION: kaz to send out a message on HTML5 LC comments from the Web and TV IG [recorded in http://www.w3.org/2011/07/14-webtv-minutes.html#action01]

<trackbot> Created ACTION-54 - Send out a message on HTML5 LC comments from the Web and TV IG [on Kazuyuki Ashimura - due 2011-07-21].

mark: looking at the HTML5 editor's draft asking for review
... there is specific format expected for the review

jan: we should be very careful

clarke: they're not looking for new features

<mav_> From http://dev.w3.org/html5/spec/Overview.html "Feedback Comments Please enter your feedback, carefully indicating the title of the section for which you are submitting feedback, quoting the text that's wrong today if appropriate. If you're suggesting a new feature, it's really important to say what the problem you're trying to solve is. That's more important than the solution, in fact. "

kaz: also the WAI-PF group is interested in the IG's work
... will send a message to continue the discussion

<scribe> ACTION: kaz to send a message to the IG list and start discussion about possible joint meeting with WAI-PF group during TPAC 2011 [recorded in http://www.w3.org/2011/07/14-webtv-minutes.html#action02]

<trackbot> Created ACTION-55 - Send a message to the IG list and start discussion about possible joint meeting with WAI-PF group during TPAC 2011 [on Kazuyuki Ashimura - due 2011-07-21].

<Clarke> Use case 4: http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Discussions/Adaptive_Bit_Rate_Delivery

Adaptive Bit Rate Delivery (ISSUE-34)

issue-34?

<trackbot> ISSUE-34 -- Adaptive Bit Rate Delivery -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/34

clarke: this is adaptive bit rate
... assume sending video content on a reliable network
... user agent can support multiple adaptive bit rate
... (explains the description)

jan: how can you introduce adaptive bit rate which is not supported natively?

clarke: in the protocol some tag could be added

jan: similar issue in issue-18
... should have a standard way for the extension

clarke: ok

jan: point 2 should be modified
... next comment is
... we don't have to conclude the point 3

clarke: these are examples we might want

jan: we (=Open IPTV Forum) have supported JavaScript APIs for that purpose

adk m

mark: item 1 is currently supported
... but 2, 3 are not supported by standard way

clarke: might not be supported is continuing streams

jan: something is missing. we should consider changes over time

clarke: we're out of time
... don't think we can finish issue-34 today
... any questions?

mark: we should handle content protection as well

clarke: like that idea

jan: probably a category of use cases

mark: maybe more than one use cases, but might be just one

clarke: if you want to include that topic into the scope of this TF
... I'll change the charter's scope

jan: we don't have any mechanism for DRM
... for <video> element
... would be better to have extension for <video> element about content protection first, and then we could consider DRM

mark: something like plug-in or new standard API?

jan: thinking about standard API

mark: agree
... no DRM could be standardized by W3C
... so if there is some extension mechanism for proprietary DRM systems
... it would be good
... extensible <video> element would be a use case

clarke: I won't be here
... is anybody interested in charing the call next week?

mark: maybe focused on HTML5 extension

kaz: who will chair the call next week then?

clarke: will talk with people about that.

[ adjourned ]