<jcverdie> Hi, I'm stuck in another meeting. Will try to join as soon as I can

<Bin_Hu> Scribe: Alex

<Bin_Hu> http://www.w3.org/community/tvapi/track/actions/open

<cpn> ScribeNick: aldafu

Bin_Hu: regarding meeting during TPAC, it should be possible to share the meeting on monday with the public web and tv interest group
... next agenda item is reviewing consolidated use cases

<Bin_Hu> http://www.w3.org/community/tvapi/wiki/Main_Page/Technical_Requirement

gene: I've added requirements to that new technical requirements page already

chris: me too

genelian: let me address the CAS system, some channels are encrypted and decrypt card/module needs to be plugged into the TV. this is a common feature in lots of markets and needs to be supported

cpn: I added more details to existing requirements
... recording requirements updated to included a unique id for a program independent of it's scheduled air time
... added parental controls to recorded programs, should be based on content not only aired time slot
... also added API access to subtitles for accessibility
... clarification: the unique id for programs, is an unique instance which covers the unique airing of that single program
... also added API access to time-shifted programs
... it's meant as pause/playback support, not meant for recording
... paused live playback should be able to to continue playback from the buffer or forward to the current live playback

paul_higgs: a second requirement might be needed to address this

skim13: concerned that the scope of the requirements for the API is to big

cpn: I agree, still think it's useful to gather as much as possible for the complete picture, doesn't mean the API has too cover all of this

paul_higgs: for parental controls, is there a requirement to block playback?

cpn: usually handled on platform level, usually by pin entry. not clear if it should happen on the app level instead.

Bin_Hu: my understanding of current requirements for parental controls cover: 1) get info if channel is locked, 2) gives ability to unlock (either by platform or app)

paul_higgs: has to be understood that channel locking needs to be handled by the platform

genelian_: from app level we need interface to enable/disable if program is shown on the screen

Bin_Hu: regarding timeshift/recording buffering: platform should provide cache/buffer. size of the cache should depend on platform

paul_higgs: might be good to have a section on device capabilities

cpn: I agree, I can add device capabilities as part of timeshift and recording requirement sections
... for clarification, type and schema for media sources as part of channel requirements. what is this?

Bin_Hu: the schema denotes "protocol" type of URL, i.e. "tv://"
... not sure it defines codec for the actual channel

paul_higgs: it's really only an identifier, not addressing the payload

cpn: regarding triggered interactive overlay requirements, what does contextual information in content mean? mark regions in the content based on time?

Bin_Hu: triggers are based on content metadata

cpn: wonder if we need new requirements to expose segmentation with programs, for subsections based on time
... I'll add those

paul_higgs: wonder if we should deal with picture-in-picture and captions? maybe that's dealt with in HTML5. might not need one though.

genelian_: the captions requirement is meant for different subtitles in the program, the user should be able to switch between these

cpn: do we need define ways to expose timing informations for synchronization with second-screen devices?

Bin_Hu: handled in other groups already, gap analysis available

genelian_: regarding EPG requirement, do we need API to be able to search in the EPG (e.g. by title or actor)? Or should the app handle this by its own?

paul_higgs: an app could handle this through a web search/REST call

genelian_: certainly would make it easier to leave this out. just wanted to mention it for completeness.

Bin_Hu: next steps
... adress actions, see above
... till the next call, rethink requirements and review again?

genelian_: I think we can start spec writing, it's good to have a first version based on current requirements

Bin_Hu: I think that's good, let's to both in parallel and gather comments

genelian_ I can provide first draft/skeleton for a specification

<Bin_Hu> Since we will have f2f on Oct 27, please start to plan your travel for TPAC

<genelian_> Thank you Bin and Alex!

<cpn> rrsagent: draft minutes

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/??/CAS/
Succeeded: s/??/skim13/
Succeeded: s/to/too/
Succeeded: s/scope of the API/scope of the requirements for the API/
Succeeded: s/current reqs/my understanding of current requirements/
Succeeded: s/parental cover/parental controls cover/
Succeeded: s/identifiert/identifier/
Succeeded: s/picture in picture/picture-in-picture/
Succeeded: s/that app/an app/
Succeeded: s/I can you/I can/
Found Scribe: Alex
Found Scribe: aldafu
Found ScribeNick: aldafu
Scribes: Alex, aldafu

WARNING: No "Topic:" lines found.

Present: Bin_Hu cpn aldafu whyun skim13 shelly seanlin paul_higgs jcverdie GinaYeh genelian GaryChen evelyn datdoan
Got date from IRC log name: 08 Jul 2014
Guessing minutes URL: http://www.w3.org/2014/07/08-tvapi-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report