[Development] The dark side of QtMultimedia

[Massimo Callegari]

Dear Qt team,
I am well aware you guys do your best to provide a quality 
cross-platform framework and so far you did an excellent job !
Unfortunately I cannot say such thing for the Qt Multimedia module. If 
you stick to the provided examples (properly tailored to hide all the 
bugs) they all almost work. If you try to use the multimedia 
functionalities in a serious project and try to deploy it, then the pain 
comes around.
I found Qt Multimedia buggy, unsupported and moreover not cross-platform.

I am the maintainer of an open source project and so far I provided 
multimedia audio input/output on Qt4 using ALSA on Linux, WAVEIN/WAVEOUT 
on Windows and PortAudio on OSX.
In the last 9 months I tried to switch to Qt5 Multimedia and opened a 
number of issues on JIRA and none of them has been resolved or taken 
into account.

It seems the priority goes to things like Camera input, instead of 
fixing and consolidating the current functionalities.
As of today, on Gerrit there are only 12 open commits. 5 of them related 
to Camera input. 9 of them are 4 or more months old.
https://codereview.qt-project.org/#/q/status:open+project:qt/qtmultimedia,n,z
On JIRA there 178 open tickets. More than 100 are P1 or P2 but it seems 
nobody is actively taking care of them:
https://bugreports.qt-project.org/browse/QTBUG/component/19173#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponent-issues-panel

So the question is, are you guys actually interested in improving Qt 
Multimedia ?
Is there any internal problem in maintaining this module that we should 
be aware of ?

Please let us know something about the future of this module, cause 
right now it is quite difficult to rely on it and include it on a project.
I would offer my contribution to fix some of the issues I found, but 
unfortunately my time is very limited and I'd risk to not being able to 
follow the activities.

My personal suggestion: to take this seriously you need 2-3 developers 
working 8 hours a day on this module. At least until it reaches the 
quality of the other Qt modules.

Thanks in advance and regards.
Massimo

Here's the issues I opened on JIRA plus a few other considerations
(apologies if the description is not complete, the issues on JIRA have 
been locked so I couldn't improve them anymore)

----
https://bugreports.qt-project.org/browse/QTBUG-37004
*February 22nd 2014**: QAudioDeviceInfo should have a displayName() or 
description() function*
On OSX devices names are correct.
On Windows they are truncated to 31 characters
On Linux it's a mess. I think no user wants something like this: 
http://pbrd.co/1tpyzuu

----
https://bugreports.qt-project.org/browse/QTBUG-37005
*February 22nd 2014**: QMediaPlayer supported mime types*
The documentations says we shouldn't use 
QMediaPlayer::supportedMimeTypes() but:
- on OSX it returns a list of mime types even though it says it supports 
AVI video playback and instead it doesn't
- on Windows and Linux it returns an empty QStringList
- the alternative is to use the 'hasSupport' method, which is a pure 
non-sense/blind shooting way to understand the capabilities of the 
MediaPlayer engine

----
https://bugreports.qt-project.org/browse/QTBUG-42034
*October 18th 2014**: QMediaPlayer metaDataChanged signal not emitted on 
OSX*
An example of NOT cross-compatibility. The signal is emitted on Windows 
and Linux.

----
https://bugreports.qt-project.org/browse/QTBUG-37882
*March 27th 2014**: QAudioDeviceInfo nearestFormat not working on OSX*
Another example of NOT-cross compatilibity. A code that works on Linux 
and Windows doesn't work on OSX.
It took me months to find a non-sense workaround to make my code to work.
In the meantime, the original code was hanging on OSX, which shouldn't 
happen anyway.

----
*Audio input example doesn't work on Windows 7 and Realtek audio card*
Unfortunately the OS and card combination is quite popular on the 
market. RTK cards are most likely integrated in desktop motherboards. On 
Linux the same example with the same card works as expected.
Here there are 2 issues:
- the example gets a QIODevice from the QAudioInput::start() method. The 
QIODevice is used to read data from the audio card, but if I call the 
QIODevice::bytesAvailable() method
   it always returns 0. QAudioInput::bytesReady() must be used instead. 
I believe that the first approach should work if the subclassing was 
done properly
- with the Realtek card, QIODevice::read always reads 3840 bytes, no 
matter what QAudioInput::bytesReady() returns.
   For example: the app needs 4096 bytes, bytesReady returns 7680 bytes 
and QIODevice::read reads 3840 instead of 4096 as requested.
In my case I need 4096 bytes to perform a FFT. If the device returns 
less bytes, the FFT fails.

----
*GStreamer 1.0 support*
GStreamer 1.0 has been released more than 2 years ago. An issue on JIRA 
has been opened on Sep 9th 2013 and it's still ongoing.
This porting is fundamental for the Raspberry Pi since it cannot afford 
to software decode videos.
How can you guys "officially" support (as a paid enterprise service) the 
Raspberry Pi if you don't have such a basic functionality ?
http://blog.qt.digia.com/blog/2013/10/24/introducing-qt-enterprise-embedded-aka-boot-to-qt/
You should say "we support the Pi, except for the multimedia 
functionalities"


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20141108/5d64f63b/attachment.html>