Qt 4.7 scope change regarding Qt Multimedia

Published Thursday May 6th, 2010
21 Comments on Qt 4.7 scope change regarding Qt Multimedia
Posted in Multimedia, Qt Quick, QtMobility, WebKit

Over the past few releases, Qt has become richer, more powerful — and bigger. So far we have been using the same source code repository for all the modules that are included in Qt 4.x releases, but during the integration phase of Qt 4.7, it has become clear that we need to make Qt more modular in the future.

A Qt release should still consist of a set of modules that have been verified to work together, but we shouldn’t have to integrate all code to the same source code tree. So we have decided to make the modularization of Qt as one of the targets for Qt 4.8.

In the light of this future goal, we also realized that Qt 4.7 is actually not the best time to integrate the new Qt Multimedia features into Qt. That’s why we have decided to not include any new Qt Multimedia functionality in the final release of Qt 4.7.

Today’s beta packages still include a subset of the Qt Multimedia functionality, but we will remove this code from Qt before the final release of Qt 4.7.0. Not to fear however, this Multimedia API is part of the new Qt APIs for mobile development package, released as Qt Solutions last week.

Such a late scope change is of course quite exceptional, but the consequences are almost entirely positive. The reason for the “almost” is that we will temporarily lose the declarative elements for audio, video and sound effects in Qt Quick. We’re working on releasing the declarative elements as an additional module based on the Qt Multimedia Solution. Also QtWebKit will continue to rely on the Phonon framework to implement HTML5 media support in Qt 4.7. Improving HTML5 media in general is on our roadmap for the next releases of QtWebKit.

Then to the positive side. First, we’ll only have one Qt Multimedia framework instead of two different copies, a subset in Qt 4.7 and the whole framework in Qt Solutions. This makes it easier to understand our offering.

Second, the same use cases that are now in the Beta (plus more) are still going to be available, with API and binary compatibility, from the Qt Solutions release, and with roughly the same schedule.

Third, since our multimedia team can now focus on maintaining a single copy of the framework, we’ll have more time to polish it and with this we hope to reach a higher level of quality.

We also know we’re doing the right thing with regard to the future of Qt. So upward and onward to a modular and multimedia capable Qt!

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Multimedia, Qt Quick, QtMobility, WebKit


diego.marcos says:

I have just installed the beta on my mac from the .dmg and the framework QtDeclarative is missing. Do I have to install it separately now?

Henry Haverinen says:

Diago, that’s weird… QtDeclarative should be included in Qt 4.7 beta now and definitely also in the final.

diego.marcos says:

I know… I had compiled and installed from the sources the 4.7 technical preview and the Qt Declarative framework was indeed there. The binary distribution for mac (.dmg) of the 4.7 Beta 1 does not install the declarative framework. Is anyone having the same problem? I will try to compile from the sources in a while and check myself…

Nick Young says:

So, before we had two complete copies of Qt Multimedia, one in Qt and one in QtMobility/Qt Solutions. Now we have the complete API in QtMobility/Qt Solutions and a subset in Qt. I don’t see how the latter option is easier to maintain than the former.

I would have thought the more maintainable option would be to have the entire Multimedia API in Qt, given that Qt is a dependency for QtMobility/Qt Solutions. Of course, some may object to having a complete (bulky, namespace cluttering) multimedia API in Qt – but then again, Phonon is in Qt already, and it’s more than clear from this blog post that Qt 4.7 is dependent on some Qt Multimedia components…

Fun Times!


I think the aim so far as I can tell is to split ‘Qt’ into multiple modules in code as well as in name, instead of just having a large monolithic ‘Qt’ containing QtGui, QtCore, QtMultimedia, QtWebkit, etc.

Daniel says:

So what about people interested in Qt Multimedia on the desktop? Does this Qt Mobility thing work on the desktop as well? If so, why is it called Qt Mobility?

Nick Young says:


That logic I do understand. Though, correct me if I’m wrong, Qt largely resembles that structure anyway, aside from the issue of a common namespace.
Admittedly there are quite a few interdependencies between those modules – personally I think that’s a sign of good cohesion within the Qt Framework as a whole.

Jason McDonald says:

@Diego: It looks like we made an error with omitting QtDeclarative from the pre-built mac binary packages. We’re looking into it now….

diego.marcos says:

I tried to compile yesterday qt 4.7 and the declatarative module is disabled by default. If you generated the package with the default options it makes sense that declarative is not there.

Henry Haverinen says:


The mission of the Mobility project is to make the Qt API more complete. The project prioritizes mobile platforms high, but it is not restricted to mobile devices. For example. playing back video or audio will be possible on Windows, Mac and Linux with this solution. Check out this page for more information about the platform compatibility:

@Nick, Robin,

In Qt 4.7.0, we will only have the same low-level multimedia services that were already included in Qt 4.6. So there will be just one copy of the actually interesting code (the high level use cases), and that code will live in the solution.

We haven’t yet defined the goals for the modularization project. This work is only starting now. One of the reasons for moving away from a “monolithic” Qt is our continuous integration system, which would probably work better and faster for smaller modules.

So maybe we’ll split some parts of the existing Qt into multiple code repositories. Maybe we’ll just create new things as separate modules from now on. One of the targets will be that the externally visible product structure must be easy to understand.

Jason McDonald says:

@diego: did you use the current 4.7 branch or the v4.7.0-beta1 tag? I’m pretty sure we want QtDeclarative enabled by default (it’s the biggest new feature in 4.7 and we want all the feedback we can get), but I’ll double check with the devs ASAP.

Also, which Mac OS version and configure line are you using?

Sean says:

“We haven’t yet defined the goals for the modularization project. This work is only starting now. ”

Sometimes I get the impression Qt Multimedia support is a moving target. That makes it hard for companies to make the jump to Qt when so much is in flux between QML, DUI, Orbit, QtMobility…Sometimes change is good. But too much change, creates the perception of indecision.

Sreedhar says:


I am trying to play Audio and video using QML Elements of Qt Creator


When i try to run this example it gives me a error

defaultServiceProvider::requestService(): no service found for –

I am new to this Qt and QML.

Can anyone one help me out

Bdur says:

Hi, I have the same problem than Sreedhar : unable to use audio in qml file (with qml launcher).
I have write the import sentence (import Qt.multimedia 4.7), but the service could’nt be found.
Thanks to help me !

Henrik Hartz says:

@sreedhar, @bdur; make sure that the media elements are built (in modules) and that your environment can correctly resolve the plugin dependencies (depends.exe, otool -L, ldd..)

In the future, you’ll build the multimedia elements from the mobility project which will install modules into your Qt imports, allowing you to use the media elements in the same way as now

ad5xj says:

I am totally confused??????

First you say that QtMultimedia is integrated into the 4.7 beta – then new development is in QtMobility for completeness. Why? Can’t it be complete in the basic cross-platform SDK?

Then you say QtMobility “prioritizes mobile platforms high, but it is not restricted to mobile devices. For example. playing back video or audio will be possible on Windows, Mac and Linux with this solution.” Why? If the new development has commonality with cross-platform applications, why restrict it to mobility or even start there for completeness?

Then you say “We haven’t yet defined the goals for the modularization project. This work is only starting now. One of the reasons for moving away from a “monolithic” Qt is our continuous integration system, which would probably work better and faster for smaller modules.”

It seems there is a lot of ambivalence as to what the Qt SDK Framework actually is. Your “monolithic” characterization is somewhat unfair where we are talking about SDK architecture. After all, not all of the SDK is necessarily used nor included in any specific project. The size of or perceived speed of the project and executable module is a product of the project linking and quality of coding – not the framework.

Where specific and unique platforms are involved (maemo, symbian, windows, etc.) specific and separate platform packages make sense to me. But separation of basic functions common on all platforms and prioritizing for mobility seems almost backward.

If there is multimedia commonality across platforms, it seems to me it belongs to the SDK – not mobility. And vice-verse if mobility has non-common needs they should be expressed and separated into the appropriate mobility or platform package. A good example is the almost exclusive use of DirectX on Windows (Vista, CE, etc.) and no other platform. This is a Windows platform specific issue that should be addressed in a Windows only separate package. The other common multimedia functions and characteristics should be a part of the SDK by default. I thought the reasons you describe for separating QtMultimedia were addressed by the plugin interface? Why not enhance the plugin interface to allow for platform specific plugin modules in much the same way you accommodate differences in database engines?

When I first started using Qt Framework, I was elated by having to only write my code once to move the application from Linux to Windows or any platform supported. Now, I am wondering just what Qt SDK Framework is becoming and how much more work I will be faced with going forward if it gets dismantled the way you describe.

Henry please help me with this. If I am being unfair please correct me.

axeljaeger says:

So this means you are breaking binary compatibility between Qt 4.6 and 4.7 and very likely again with 4.8 when you know more about where the modularization goes?

sidney says:


I have Qt 4.6.3 on Windows and have built the QtMobility 1.0.1 API on my PC successfully. I am trying to get the player example to display videos on my PC. However, I keep getting:

defaultServiceProvider::requestService(): no service found for – “com.nokia.qt.mediaplayer”

on QtCreator. A very similar (if not the same) was resolved by copying the plugins from the QtMobility to the Qt plugins directory. See:


However, that doesn’t seem to solve my case. Any ideas?

sidney says:

Ok. I figured it out myself. In my windows SDK, the QtMobility initial configuration had not built the direct show engine plugins. So I built it manually and copied to my Qt SDK’s plugin and voila! Great way to start the weekend 🙂

Rod says:

Ouch! The Phonon story is a bit fragmented so I’m _really_ looking forward to Multimedia arriving on the scene.

Meanwhile, is there any story on V4L2, or webcam support in general, with Multimedia? I haven’t yet found an app or code example of Multimedia with a webcam viewfinder. Any pointers?


Paul says:


Can we use QT mobility (last version is 1.1.0) and QT 4.7 (the last from git repositories or the one we could donwload as the Beta 2.1 in order to have QML (Qt declarative scriptable UI) ?

Is this possible?

Commenting closed.

Get started today with Qt Download now