[Development] The dark side of QtMultimedia

[Gianluca]

Dear all,
I see that the discussion was focusing on GStreamer backend, but QtMultimedia is not only present on Linux.
So, I want to change the focus of discussion to the mobile and embedded platforms.
I want to do so, because in the case of ‘normal’ desktop environment (Linux, win and mac) there are a lot of tiny opensource projects that bind some multimedia kit with the Qt. And hence, in case one had problems with QtMM, can try some opensource projects to see if in their case works (with simple project and not complex multimedia apps it works, there are a lot of example on community forums and stack overflow).
But for mobile platforms the problem is different from two aspect:
 - for a mobile app, Qt strongly encourage to use Qt Quick, because it’s more suitable for that kind of app
 - into a mobile platforms you cannot easily install third-party libraries as a ‘normal’ desktop platform

In that situations, from my experiences there is two different level of “gaps” into QtMM usage:
 -A) features that the native mobile multimedia backend support and QtMM doesn’t support
 -B) features that QtMM support but not available in Qt Quick

Again, from my experiences, if you don’t need a complex multimedia app (90% of the cases as Lars suggested), you can always find a way to overcome the limitation on point A (for example, native backend support .MOV and MP4 playback but QtMM only support MP4 … it’s fine to play only  MP4 for simple app, or the recording support only .AAC while the native can support also other format, it’s ok, etc)

But for point B, there are some “gaps” that can completely block the usage of all QtMM in a Qt Quick application in some platforms. One example if the VideoOutput on iOS that cannot be integrated into the Qt Quick view as any other items. This make impossibile to use completely the video capability of the QtMM on iOS even on a very simple app.

So, from my point of view, I think it’s really important that QtMM is integrated into Qt Quick very well and in the same way on all platforms.
And, I’ll put on the second priority the complete coverage of all features of all native backends on all platforms.

Cheers,
Gianluca.


Il giorno 13/nov/2014, alle ore 09:19, Tim Blechmann <tim at klingt.org> ha scritto:

>>>> Yes, this could also simply be our qtmultimedia unit tests. Run the
>>>> tests
>>>> on your target platforms and if they pass it should be reasonably safe
>>>> to
>>>> assume that things are working. Of course we’re not there currently, our
>>>> coverage for QtMM is not good enough afaict.
>>> 
>>> QtMultimedia's own unit tests use QtMultimedia, so it doesn't isolate the
>>> problem. We need tests that use *only* the lower-level multimedia API,
>>> like 
>>> GStreamer.
>> 
>> Usually, I’d say that should be gstreamer’s job. They should provide unit
>> tests that allow testing a gstreamer implementation on a linux
>> system/board.
> 
> well, if Qt relies on gstreamer to provide feature X, this feature
> should be tested and validated by Qt. the end user won't care, which
> part of the system fails.
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development