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"
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
