Media Capabilities and any overlap with QoE?.

  • Media capability discovery is very important, OTT be the norm across the ecosystem
  • ask at runtime can I play.
  • isTypeSupproted, CanPlay?, and mediaCapability proposal.; HDR
  • Current mediaCapability proposal:
    * what codecs and resolutions, and frame rates does this device support? Is it power efficient. 
    * it takes a JSON object in terms of its codec, resolution bitrate. both for video audio
    * response is a boolean, supported, power efficient, play smoothly.
    * Media playback quality API, in incubation. 
    * actually answer these questions is hard. Basically profiling the device as the attempt is made. 
    * power efficient at lower resolution.   
    * initially a per-device profiling. 
    * Are the media Capabilities rich enough. 
    * Request extended to allow profiles. 
    profiles that package, simplify the package. 
  • Is the source of truth "mov atom" contains all details for capability.
  • People are not asking the right question with canPlayType
  • If we gave the init.
  • In chrome its keeping track of playback on every video player experince.
  • OTT, chromecast will be very reliable.
  • Media Profile->

  • Bake the init into the manifest. ( only works fragmented mp4 )
  • A lot of device fragmentation, feed the best solution per device.
  • DRM has different restrictions from clear content.
  • wants to solve within Media Capabilities.
  • interface between MediaCapabilities? and EME.
  • HLS in safari .. "we take care of it".
  • Avoid two ways to describe things. The mov atom already describes this to an extent.
  • Hardware with different decode capabilities for different codecs; trade off battery vs bandwidth.
  • Working on mediaCapabilites in chrome, what we have done so far fits the requirements.
  • Glitches going from hardware to software.
  • Monitoring bitrate not as robust as you expect.
  • Media Capabilities for better ABR experiences.
  • Super important for Players to know what it supports or not, probably or maybe is not very efficient.
  • Media Capabilities beyond browser.
  • Metered internet or not ?
  • Battery status, network.
  • What are the capabilities of "an audience", when is it appropriate to introduce a new codec.
  • Browser app suspension, offline QoE?.
  • Measuring QoE? features at video pipeline level of the browser.
  • The ability to fingerprint your user? ( privacy considerations )
  • As your playing, do the mediaCapabilites change ? Change events ? A lot of things that can happen on the system can effect your ability to decode.
  • Figure out user intent; running on battery want to use power efficient; represent the intent of the user.
  • In windows ... best quality or save battery.

Fingerprint is hard to counter, over time of product people are identify. There are best efforts to bucket the capabilities.

We could spend forever specifying... we lie at first and build the model over time.

Codec switching, how would this affect the API?