See also: IRC log
<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[End of scribe.perl diagnostic output]