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

[Alexis Menard]

On Sat, Jun 25, 2011 at 4:28 PM, Dawit A <adawit at kde.org> wrote:
> 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 ?

It uses the same way of fetching the data that QtWebKit does. The
GStreamer backend uses the concept of WebKitWebSrc which have a
ResourceHandleClient and in the Qt port is hookup up to the normal
networking stack. So in that matter it's not worst than before I
believe. With this data we feed GStreamer.

I hope it answers your concerns.

> _______________________________________________
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
>



-- 
Alexis Menard
Software Engineer
INdT Recife Brazil