On Sat, Jun 25, 2011 at 12:45 PM, <[email protected]> wrote: > > On Jun 24, 2011, at 2:08 PM, ext Alexis Menard wrote: > >> Hello, >> >> - Makes harder to maintain : we have multiple backends and code path >> (but in the other hand we are not alone to maintain the backends). > There are multiple backends when we use QtMultimedia at as well, except > they're abstracted away under another layer. I think this exercise showed > that having multiple backends > is more maintainable than having multiple backends behind an extra > abstraction layer :) > >> - Removing Phonon backend from the tree. I asked on >> http://lists.kde.org/?l=kde-multimedia&m=130779689626212&w=2 and got >> no answer, which to me means nobody wants to take care of it. It >> brings confusion in the webkit community.
I attempted to look into this and started preliminary work. However, it is not something I have to time for maintaining nor am I part of the kdemultimedia group. There is one big concern for me as a maintainer of the KDE integration layer for QtWebKit, kdewebkit. That issue is how the media is streamed from the network this implementation. Is that left up to gstream's networking layer or do you retrieve the media through QtWebKit's networking layer and feed that to the gstream ? This matters because QtWebKit allows us to provide our own implementation of QNAM which we use to provide the KIO integration. Without that none of the session information such as cookies will not be shared and hence HTML5 multimedia support will not work in kdewebkit browsers if the content is behind password protected sites. Currently both the phonon and the QtMultimediaKit based backends seem to suffer from the fact the QNAM used in QtWebKit is not used by them to stream the media. How is this handled in this new gstreamer backend ? _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
