Phonon design in general

[Thierry Bastian]

Hello Matthias,

Thanks for replying. It's very much appreciated.

1 Effects

I would say that my point is also about knowing what are the effects we
commit to have in all backends...
Can we be sure to have such controls everywhere? What happens if a backend
doesn't support it? Aren't we supposed to have more effects?

On the design perspective: if we can only control the brightness and
deinterlace on the renderer, how do we then explain that it doesn't exactly
work as a "normal" effect. I mean that when you set up an effect chain the
input from one depends on the output of the previous one.
It seems that those controls are done on the renderer at least for xine and
DirectShow. What about having "Interfaces" then on the renderer (a bit like
addoninterface) ? This would allow us to actually make sure the backend
support it.

On the use-cases (poll ;) ): who is actually using the
brightness/deinterlace control on their video playback ? I've never done
that in any media player which anyway rarely offer those features (at least
under Windows). So this boils down to: do we really need them? You know my
answer and I would love to have feedback from the other team members ;).

2 Model, Players and sliders

Phonon is currently too big, especially compared to the native lib that are
present on embedded. Håvard will test this and provide us with the actual
savings of removing those classes. The thing is that Qt itself is already
seen as too big by some of our embedded customers. So in any case any byte
saved is good to have.

To me those classes are interesting but don't really fit in the library
because (again to me) phonon is all about having a frontend to the backend
functionality. It should ideally be small and extensible (like with the
addoninterface, the effect implementation).

Having an additional library is hopefully an option. In worst case (ie.
Håvard tells us that it's a tremendous amount of memory saved and having a
second lib is rejected by the kde guys) we could still provide the code and
people could put it into their apps.

3 EffectWidget

That's funny because I'm currently writing another loooong email about
effects and I came across EffectWidget. And in this case, I tend to think
that it makes sense to have that functionality inside phonon... Surprised?
Well wait a minute ;). The thing is that DirectShow (and I guess maybe
quicktime) offer an built-in way to configure effects showing nice dialogs.
And of course people will ask to have those dialogs instead of the built-in
EffectWidget.
So I think we should have a way to call the backend configuration dialog and
the current EffectWidget could be the fallback implementation inside the
backend plugin.
Maybe we could have something as simple as Effect::configure that would ask
the backend to display a dialog to the user. Any thought about that is of
course welcome.


My take:
Basically as a rule every class that have backend-calls in their
implementation should be in phonon. The other ones are questionable.


I'll send another email with a patch for EffectWidget. I hope this doesn't
steal too much time from your studies. Thanks again for your time.

Best Regards,
Thierry

-----Original Message-----
From: Matthias Kretz [mailto:kretz at kde.org] 
Sent: jeudi 28 juin 2007 21:11
To: phonon-backends at kde.org
Subject: Re: Phonon design in general

On Thursday 28 June 2007, Thierry Bastian wrote:
>  So my idea was to try to focus on reducing the number of classes we 
> have in Phonon to the core ones we need. After all Phonon is about 
> having a cool cross-platform front-end API to the backends (insanely 
> powerful platform-specific multimedia framework).
>
> These are:
>
> -          ObjectDescriptionModel: it is a convenient class that can be
> used to nicely display ObjectDescription to for example choose which 
> effect or output audio device to use.
>
> -          BrightnessControl & DeinterlaceFilter: to this point there is
> nothing like that in DirectShow and I wonder if abstracting those 
> effects is a really good idea at this point. Directshow gives us the 
> possibility to control the brightness and deinterlace but this is only 
> on the video renderer. A more abstract way of viewing the effects like 
> it is with the enumeration coming from the backend capabilities and 
> and EffectParameter makes at this point more sense to me (Note: on 
> Windows by default there is no video effect provided by the system)

Those effects are actually expected to be implemented using the renderer. At
least when all the backend is told to do is to play a video on one
VideoWidget. As soon as we have something like MediaObject -> Path ->
VideoDataOutput the brightness and deinterlace effects have to be done in
software.

> -          VideoPlayer & AudioPlayer & SeekSlider & VolumeSlider : nice
> things to have but it looks to me there are more like example code 
> than really core functionality. They have no interface to the backend.
>
>
>
> This code is all great value to phonon and I think we should not remove
it.
> It just makes more sense to have them in a separate ?example? directory.
> I?m pretty sure most people won?t use them.

http://lxr.kde.org/ident?i=AudioPlayer
http://lxr.kde.org/ident?i=SeekSlider
VolumeSlider is only used in JuK at this point.

> And if they want to use them,
> they can still integrate them into their own app (like the 
> ObjectDescriptionModel for KCM).

The model I agree to make 100% inline if possible and if it's safe to do
that. 
Removing the Player and Slider classes I'm not very happy about.

I just tested the savings of removing VideoPlayer and it's 7532 bytes. 
Removing only the Q_OBJECT macro saves only 36 bytes, removing all public
slots (keeping Q_OBJECT) saves 28 bytes (this is very impressive!).

If those 50kB really improve the situation on embedded (btw, how big are
QtCore and QtGui? stripped on my machine they're 1.5MB and 7.6MB) we should
consider a libphononutils or so. Another candidate for that lib would be
EffectWidget.

> On my windows machine, removing those classes made the library 20% 
> slimmer (248KB down to 196KB). That?s a huge gain (hopefully 
> reproducible with ARM).

--
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de