WebAPI/2014-03-11

« previous week | index | next week »

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)