[webkit-qt] QtWebKit, the multimedia support today and tomorrow.

[Dawit A]

On Sat, Jun 25, 2011 at 12:45 PM,  <noam.rosenthal at nokia.com> 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 ?