[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: kdemm backends & Helix
From:       Ryan Gammon <rgammon () real ! com>
Date:       2004-09-15 2:14:58
Message-ID: 4147A5A2.5050704 () real ! com
[Download RAW message or body]

Matthias Kretz wrote:

>On Tuesday 14 September 2004 20:25, Ryan Gammon wrote:
>  
>
>>A couple of quick questions:
>>1. Is anyone interested in a helix-based implementation of these
>>interfaces? (helixcommunity.org, helix client is the open-source media
>>engine that powers the RealPlayer).
>>    
>>
>
>I am. And I'm all for including it in kdemultimedia. I won't be the person 
>implementing it, though.
>  
>

Sure :) The interfaces as they stand right now don't look like they're 
something that's going to be too difficult to develop. I'm sure I could 
take a stab at the basics it when I have some spare time.

>>2. I'm a little confused by channels -- if there's something someone can
>>point me at that talks a bit about what this is, it'd be much appreciated.
>>    
>>
>
>The Channel interface is not finished. It's pretty much a placeholder 
>currently for an idea of Dik Takken (look at his mails to kde-multimedia - 
>and the one to kde-core-devel if you want to know all the details). But 
>basically it's a means of making apps use more advanced features of the media 
>backend without the app actually knowing. So you could define a Channel that 
>would send the audio through some effects before playing to the soundcard. Or 
>another one that would send the data to a file or another computer.
>  
>

Ok, makes sense. From a different point of view, a channel is kind of a 
bunch of settings for the media engine (volume, equalizer settings, 
reverb, brightness, hue, device/computer name, etc.)

>>3. If one wanted to provide access to extended media engine
>>functionality with these interfaces, how would they go about doing it?
>>    
>>
>
>The idea currently is: "not at all". All the interface provides is the name 
>and some general info on the backend kdemm would use. If an app wants more 
>than the simple API in kdemm it's supposed to use the backend framework 
>directly and don't mess with kdemm at all (of course it's not disallowed to 
>do, but it's probably not a good idea).
>  
>

Ok.

>>For example, we developed a simplifed gtk widget around the Helix Player
>>for our Helix Player 1.0 / RealPlayer 10 for linux project. There's a
>>lot of media engine functionality that we didn't want to add to the gtk
>>api -- we wanted to keep it simple -- so we added a mechanism to get at
>>the underlying engine.
>>    
>>
>
>And how do you do that? Thinking of kdemm that would mean installing a lib for 
>all backends that can then be used at compile time by apps? Isn't just using 
>the backend's API directly enough?
>  
>

The "how" in our gtk widget case is that we created methods in our 
widget wrapper that provide access to the underlying IUnknown's for the 
COM-based client engine.  Using those IUnknown's, one can navigate 
through the various components that make up the underlying engine, 
tweaking the advanced functionality as required.

For kdemm, one idea would be to use QCOM 
(http://doc.trolltech.com/3.0/component.html). I'm not sure how much 
QCOM is actually used in kde, if at all, but if it's viable, one could:
- add a getUnknown() method to KDE::Multimedia::Player that returns a 
QUnknownInterface
- most apps use the basic KDE::Multimedia::Player api
- apps that want/need advanced engine functionality can QueryInterface 
for back-end specific extensions
- apps need header files for the interface definitions for those 
extensions, but don't actually have to link directly to the back-end.

If QCOM's not popular there're other possibilites. Maybe KParts...

I think I understand your original point here though -- why use a 
generalized framework with various backends, and then turn around and 
link directly to the underlying backend for specific functionality, thus 
tying the app to that specific backend. Why not use the specific backend 
to start with?

Well, we have something for people who want to develop against helix as 
a specific backend called hxclientkit.
https://player.helixcommunity.org/nonav/2004/developer/doc/hxclientkit/HXClient.htm

It's a C api. You pass in an XID and a display, and you're set. If 
people want to take that and create a KDE player, awesome. One could 
even create a QWidget-derived widget around that base, and have a first 
class qt widget.

I think, though, that the api you guys are developing is going to be 
wildly popular. It's simple, it's developed with kde in mind, it will be 
part of the kde platform and will meet the play-stop-pause needs of 90% 
of the apps.

With a way of handling extensions, it could handle the needs of 100% of 
kde apps. There'd then be no need for the hypothetical QWidget-derived 
widget thing, and the poor linux multimedia application developer is 
saved from grokking yet another multimedia api. The KDE platform gives 
him everything he needs to get up and running, multimedia included.

Does this make sense? Would people rather see a "class HelixVideoPlayer 
: public QWidget" layer that a player has to use directly, or something 
that implements KDE::Multimedia::Player and provides extensions for 
anything outside of that basic API? Would anyone use a HelixVideoPlayer 
instead of KDE::Multimedia::Player?

>>Let's say I wanted to make playback statistics (packet loss, etc)
>>available to an app, but that statistics was not something that was
>>standardized enough across backends that it made sense for kdemm.
>>
>>Would I implement those methods on a hypothetical HelixVideoPlayer
>>class, and cast from a VideoPlayer up to a HelixVideoPlayer in my app?
>>    
>>
>
>One could do that, but I don't think it's a good idea. What would be better 
>IMHO is to have Qt/KDE bindings (meaning C++ with Qt/KDE APIs) for the 
>framework.
>  
>

Bindings are a cool idea, but not something I'd really sign up for in my 
spare time :) -- not only are there a lot interfaces to cover in the 
Helix Client, there'd be some ongoing work there to keep the bindings up 
to date as new COM interfaces are added to expose new functionality.

-- 
Ryan Gammon
rgammon@real.com
Developer for Helix Player
https://player.helixcommunity.org

_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]