Understood - thanks for the details! On 20 January 2015 at 09:46, David Barth <[email protected]> wrote:
> Later, we're talking about many weeks of work before this can perform with > the stability and performance level required for switching. > > On Mon, Jan 19, 2015 at 3:28 PM, John McAleely <[email protected] > > > wrote: > > > @dbarth - will video land on the ww05-2015 milestone or later? > > > > -- > > You received this bug notification because you are a member of Oxide > > Developers, which is subscribed to oxide-qt in Ubuntu. > > Matching subscriptions: oxide in 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/canonical-devices-system-image/+bug/1249387/+subscriptions > > > > -- > You received this bug notification because you are subscribed to a > duplicate bug report (1403478). > https://bugs.launchpad.net/bugs/1249387 > > Title: > hook Oxide into Ubuntu platform API for media-hub > > Status in the base for Ubuntu mobile products: > Fix Committed > Status in Media Hub: > Fix Committed > Status in Oxide Webview: > Fix Committed > Status in oxide-qt package in Ubuntu: > Fix Committed > > 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 > -- 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/canonical-devices-system-image/+bug/1249387/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
