** Description changed:
- Summary says it all...
+ 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.
+
+ 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.
** Also affects: oxide-qt (Ubuntu)
Importance: Undecided
Status: New
** Also affects: oxide-qt (Ubuntu Trusty)
Importance: Undecided
Status: New
** Also affects: oxide-qt (Ubuntu U-series)
Importance: Undecided
Status: New
** Changed in: oxide-qt (Ubuntu U-series)
Importance: Undecided => High
** Changed in: oxide-qt (Ubuntu Trusty)
Importance: Undecided => High
** Description changed:
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.
+ 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.
** Description changed:
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.
+ fixes over a period of up to 5 years.
** Changed in: oxide-qt (Ubuntu U-series)
Assignee: (unassigned) => Ricardo Salveti (rsalveti)
** Changed in: oxide-qt (Ubuntu U-series)
Status: New => Triaged
** Changed in: oxide-qt (Ubuntu Trusty)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1249387
Title:
hook Oxide into Ubuntu platform API for media-hub
To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1249387/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
