See also: IRC log
<scribe> scribenick: ddavis
Bin_Hu: There'll be the
Fraunhofer FOKUS event next week.
... There'll also be a face-to-face meeting for the Second
Screen Working Group.
... Sean (editor) will be attending both and giving a
presentation of the TV API there.
seanlin: Maybe I can get some more information at the event and share it over email or next conference call
Bin_Hu: Looks like you also wrote a blog post last week that summarizes the TV API: https://hacks.mozilla.org/2015/05/how-tv-functionality-leverages-web-technology/
Bin_Hu: There were two open action items.
http://www.w3.org/community/tvapi/track/actions/open
Bin_Hu: I'd like to leave the
triggered overlay action item #27 open.
... The next is action #30 - Skim the work done by the media
pipeline tf and let this cg know (Kaz)
ddavis: Kaz is currently
travelling so not on the call.
... There's also a typhoon here so he might be busy!
Bin_Hu: Let's leave that item open.
skim13: I volunteered to work on
Conditional Access System (CAS) requirements
... I've looked at it a bit.
... I said I would look at EME. Since because this is
protection of content I thought EME could perhaps be used, but
EME is not for real-time streaming so I think we need a new API
to protect TV contents.
... We can use the style that's in EME in a new API but I think
there's a gap between EME and CAS that we're thinking of
having.
... That's what we have so far.
<aldafu> actually EME is not excluded from live streaming, it's very much a use case
skim13: Also, the requirements that we have are a bit too short to accurately protect TV programs.
Bin_Hu: So we need to leverage some features. Would you mind looking into to see if we can propose a CAS system for the API spec?
ddavis: Alex (not on the call) says streaming is a use case for EME.
skim13: I mean live streaming for
TV. Broadcast streams have a different style - we want to make
clear that live streaming is different from TV content.
... We think it's impossible to use EME for TV content.
Bin_Hu: It would be better to have an example of how it might be possible to use EME for TV content.
<aldafu> didn't want to cause confusion, sorry. i think that skim13 is right when he says broadcast streaming can't be done with EME. EME relies on MSE which relies on HTTP. skim13's idea to create something EME compatible for broadcast streams might be a good idea
Bin_Hu: So we have covered the
progress measurement - more work is needed.
... We have work to do on time-shifting, program recording, and
parental controls.
cpn: I'd like to do more on
time-shifting but I'm not sure I'll have the time before the
next call.
... I'd like to ask seanlin about his experience on using the
Media Streams API for handling streams.
... How have you approached pause and resume for live TV?
seanlin: For time-shifting we
didn't implement the current Media Streams API.
... I don't have details right now but I can check with my
colleagues and get back to you.
cpn: If you could reply on the mailing list that would be great.
seanlin: As far as I know there might be some gaps in our implementation.
cpn: We still have to define an interface in our spec for time-shifting.
Bin_Hu: Thank you cpn. Can anyone else sign up for parent control or program recording?
ddavis: It might be worth send a request to the mailing list asking for volunteers.
Bin_Hu: Apart from that there are
various small gaps.
... So for the next stage we work to improve the trigger
proposal for Kaz and time-shifting requirements.
... Then we can work on the minor gaps in the tuner and channel
sections to hopefully have a spec by the end of the year.
... kaz requested to talk about Tuner APIs for Genivi.
... kaz requested to talk about Tuner APIs for Genivi.
kaz: I attended the automotive
group meeting three weeks ago in Germany.
... They were very interested in this work.
... Francois (tidoust) mentioned the work that's being done and
the automotive people wanted to share ideas.
... We could add a column to the requirements table to give
ideas from this group's viewpoint.
Bin_Hu: I think it's OK to add
that to the gap analysis table, if we can find a volunteer to
fill it in.
... Kaz, can you take that action?
kaz: Yes, I can do that.
<scribe> ACTION: kaz to add column to gap analysis/requirements table for Genivi ideas [recorded in http://www.w3.org/2015/05/12-tvapi-minutes.html#action01]
<trackbot> Created ACTION-32 - Add column to gap analysis/requirements table for genivi ideas [on Kazuyuki Ashimura - due 2015-05-19].
kaz: And if automotive group participants want to join this group they are free to do that.
<kaz> requirements mapping table
Bin_Hu: Any other business from anyone?
Paul_Higgs: What will we do if we don't have coverage in these other areas?
Bin_Hu: That would mean there's
not sufficient interest so wouldn't make it into the spec, or
at least dropped from the 1st version.
... Maybe in a future version they could be added if there's
enough interest.
Paul_Higgs: The spec we've
written is as much as we can do based on the initial
scope.
... It feels like some of it are gaps in other specs, where
things are lacking.
... Are you saying participants in this groups should work in
other groups to fill those gaps in other specs?
Bin_Hu: It's challenging to try
to convince other groups to revise their specification to cover
the TV part.
... At the same time, it's worth trying to do that and we'll
see if anybody is willing to do it either way.
... Either with an API that's compatible but made by a separate
group, or made here.
... For example with the EME issue earlier where we may need to
modify EME to work with TV content.
... I don't know how much time we can spend on improving that
in a short time period.
Paul_Higgs: I was trying to think
how I'd tackle it. One way is for us to write our own patches
on top of e.g. File API, EME, Media Stream API.
... The other approach is why don't we just define what we
need?
... The video object is extensible so we could create e.g. a
Broadcast Media Extension.
... That would cover the middle ground.
... We seem to be creating a lightweight API that's bridging
other W3C specs, which is fine.
... But maybe we should build something with more logic in
it.
Bin_Hu: I think that's what we're
doing now. This spec is a kind of extension of the functions we
want to support.
... This is the plan e.g. for the CAS requirements, based on
EME but extending it to be our own API to support CAS.
Paul_Higgs: That would probably
work for content scrambling.
... But I was also thinking about time-shifting and other
things.
Bin_Hu: Right now there are three
major gaps - program recording, time-shifting, and parental
controls.
... cpn has just volunteered to look into time-shifting. You
are welcome to look into that with him.
... Also, you can look into other gaps if you're
interested.
... There are also minor gaps in the tuner and channel
requirements.
... It depends on your personal interested.
Paul_Higgs: OK. There might be more than one way to get this job done.
Bin_Hu: The most important thing is to have a spec that either extends an existing spec or adds a new spec with new functionality, but either way we need to have a spec that supports these features.
Paul_Higgs: I think parental
controls feels closer to the CA system. Maybe there could be
some way of injecting parental ratings as that's
happening.
... Whereas time-shifting and program recording are more on the
playback side.
... I'll try to give some more thought into how we can do
this.
... Maybe we just want to have recording functionality locally,
not in the cloud. I'll have to think about it.
Bin_Hu: Thanks - we'll consider
that an unofficial action item at the moment.
... If you have more bandwidth I'd also suggest giving
suggestions to skim13 or cpn about the specs.
skim13: OK for me. I think
broadcast engineers are more focussed on CAS than DRM.
... I wasn't sure if they could help me with that but I'll ask
their thoughts and ideas.
... And for other external standards, how they've done this and
if we can use their ideas in our APIs.
Bin_Hu: So at least we have
high-level assignments of work. Let's see how we've progressed
at the next meeting.
... Any other business?
... Thank you everybody for your time and dedication.
ddavis: We'll have to move to Webex so I'll let you know about the details for this.
Bin_Hu: Thank you.
Meeting adjourned.
s/summarizes the TV API/summarizes the TV API: https:\/\/hacks.mozilla.org\/2015\/05\/how-tv-functionality-leverages-web-technology\//
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ triggered overlay action item/ triggered overlay action item #27/ Succeeded: s/EME>/EME./ Succeeded: s/Bin_Hu,// Succeeded: s/the table/the requirements table/ Succeeded: s/I attending/I attended/ Succeeded: s/I'll/I'd/ Succeeded: s/There's be/There'll be/ WARNING: Bad s/// command: s/summarizes the TV API/summarizes the TV API: https:\/\/hacks.mozilla.org\/2015\/05\/how-tv-functionality-leverages-web-technology\// Succeeded: s|summarizes the TV API.|summarizes the TV API: https://hacks.mozilla.org/2015/05/how-tv-functionality-leverages-web-technology/| Succeeded: s|wrote a blog post|wrote a blog post ( https://hacks.mozilla.org/2015/05/how-tv-functionality-leverages-web-technology/ )| Succeeded: s| ( https://hacks.mozilla.org/2015/05/how-tv-functionality-leverages-web-technology/ )|| Succeeded: s/For TV content/for TV content/ Found ScribeNick: ddavis Inferring Scribes: ddavis Default Present: +1.650.946.aaaa, Bin_Hu, +88628786aabb, +44.303.040.aacc, cpn, seanlin, skim13, ddavis, Kazuyuki, Paul_Higgs Present: Bin_Hu seanlin cpn skim13 kaz ddavis Paul_Higgs Regrets: aldafu Got date from IRC log name: 12 May 2015 Guessing minutes URL: http://www.w3.org/2015/05/12-tvapi-minutes.html People with action items: kaz WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]