ubuntu-webapps-bugs team mailing list archive

[David Barth <david.barth@xxxxxxxxxxxxx>]

** Also affects: media-hub
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1249387

Title:
  hook Oxide into Ubuntu platform API for media-hub

Status in Media Hub:
  New
Status in Oxide Webview:
  In Progress
Status in “oxide-qt” package in Ubuntu:
  Triaged
Status in “oxide-qt” source package in Trusty:
  Triaged
Status in “oxide-qt” source package in Utopic:
  Triaged

Bug description:
  Right now oxide uses software rendering for audio and video via the
  chromium content api ffmpeg implementation for libffmpegsumo.so. This
  is provided in either oxideqt-codecs (suitable for main) or oxideqt-
  codecs-extra (suitable for universe). oxideqt-codecs-extra includes
  mp3 and h264 playback. Software rendering is not ideal on the phone,
  but in addition to that, webbrowser-app, webapp-container and apps
  using Oxide or UbuntuWebView are subject to application lifecycle and
  therefore the user experience for things such as grooveshark playlists
  and youtube videos is poor because the device will shut off the screen
  or suspend during playback.

  The correct way to solve this is for Oxide to use the media-hub in
  some manner. This was somewhat easily solved with QtWebKit since it
  used gstreamer and it could be made to hook into the media-hub.
  However, QtWebKit is dead upstream which is one reason why we are
  using Oxide. We should look to see how qtwebengine is handling this
  (ie, are they just using the software rendering or are they redoing
  the QtWebKit gstreamer work for qtwebengine). Perhaps we could provide
  our own libffmpegsumo.so or wrap it in some manner. Perhaps we can
  work with upstream to have something that works better on Linux/Ubuntu
  in general. Whatever method is chosen should be maintainable in the
  face of weekly or biweekly stable updates (low api churn) and 6-8 week
  beta updates (potential api churn) to the chromium content api, since
  we expect this update frequency in our stable releases for security,
  bug and web compatibility fixes over a period of up to 5 years.

To manage notifications about this bug go to:
https://bugs.launchpad.net/media-hub/+bug/1249387/+subscriptions