** Also affects: media-hub (Ubuntu)
Importance: Undecided
Status: New
** Also affects: media-hub (Ubuntu RTM)
Importance: Undecided
Status: New
** Changed in: media-hub (Ubuntu)
Status: New => In Progress
** Changed in: media-hub (Ubuntu RTM)
Status: New => In Progress
** No longer affects: media-hub
** Changed in: media-hub (Ubuntu)
Importance: Undecided => High
** Changed in: media-hub (Ubuntu RTM)
Importance: Undecided => High
** Changed in: media-hub (Ubuntu)
Assignee: (unassigned) => Justin McPherson (justinmcp)
** Changed in: media-hub (Ubuntu RTM)
Assignee: (unassigned) => Justin McPherson (justinmcp)
--
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 Canonical System Image:
Fix Released
Status in Oxide:
In Progress
Status in media-hub package in Ubuntu:
In Progress
Status in oxide-qt package in Ubuntu:
Fix Released
Status in media-hub package in Ubuntu RTM:
In Progress
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/canonical-devices-system-image/+bug/1249387/+subscriptions
--
Mailing list: https://launchpad.net/~ubuntu-webapps-bugs
Post to : ubuntu-webapps-bugs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-webapps-bugs
More help : https://help.launchpad.net/ListHelp
