View source for WebAPI/2014-03-11

<!-- Maybe don't screw with these links unless you've read this blog post:
http://blog.johnath.com/2011/01/20/automatic-date-links-in-mediawiki/
Just copy them to new pages and it should Just Work!
 -->

<small>[[WebAPI/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|&laquo; previous week]] | [[WebAPI|index]] | [[WebAPI/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week &raquo;]]</small>

<div class="h-event vevent">
'''<span class="p-summary summary">WebAPI Meeting</span> Details'''
* <span class="dt-start dtstart">Tuesday <span class="value">{{#time: Y-m-d | {{SUBPAGENAME}} }}</span> - <span class="value">8:00</span> am <abbr class="value" title="-0700">Pacific</abbr></span>
{{conf|98413}}
* <span class="location">[https://v.mozilla.com/flex.html?roomdirect.html&key=H1q64MSinl9H WebAPI Vidyo Room] / London-Allo Allo / Toronto-Spadina</span>
* Join irc.mozilla.org [irc://irc.mozilla.org/webapi #webapi] for back channel
</div>

Notes below archived from etherpad:  https://etherpad.mozilla.org/webapi-meetingnotes

== Notes ==
* TV Tuner API: https://etherpad.mozilla.org/f8MAQgMbZH
** Issue: which way to play the video/audio steam on a channel is better?
*** TV Tuner API will return MediaStream based on a channel, which can be set by the VideoElement to play.
**** the discussion seemed to conclude that this is better than the URI option below
*** TV Tuner API will return some tuner/channel specific information and apps needs to use them to generate URI for VideoElement to play.
**** dvb-t://...
**** av://...
**** hdmi://...
***** advantages:  apps can generate such a URI and pass it to <video>
***** disadvantages:
****** <video> needs to know about the variety of schemas
****** having to limit <video> to be able to play certain schemas when it's running in a certified app vs not
****** new URI schemes have wide-ranging effects
****** WebRTC precedent of not using URIs (we should find out their reasons for doing so)
****** standardization will need to be done with external bodies (ex. IETF)
** Issue: does it make sense to cover the Picture Information (e.g., brightness, contract, saturation... etc) and the Common Interface (i.e., a module is used to interface between the pay-to-view card and the TV) in the Settings API?
*** are these device-wide settings?
*** filters on top of <video> = no help necessary from platform (as long as we have ex. SVG filter implementations in hardware that are fast enough)
** certified-only for the time being
** concerns with proposed API
*** knowledge of currently-in-use tuner
*** is enough information exposed to support switching inputs on the TV ex. setSource or setTuner
*** managing inputs other than TV tuners (ex. something connected via HDMI)?  use getUserMedia to get media stream
*** what happens when calling scan() on a TV Tuner object that is sending a stream to a <video> element?
** project-wide concern:  get various interested partners to work together as much as possible
** Gene is going to confirm new APIs will only be certified-only
** Gene is going to try to get desired timelines in all requests to mailing lists
* hasFeature/getFeature proposal up on dev-webapi (current mailing list archiving is broken so hopefully interested parties are already subscribed)

[[Category:Web APIs]]
[[Category:Meeting Notes]]