Discussion:
The dark side of QtMultimedia
(too old to reply)
Massimo Callegari
2014-11-08 15:00:32 UTC
Permalink
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"
Nichols Andy
2014-11-09 03:30:38 UTC
Permalink
Hi Massimo et alia,

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<https://bugreports.qt-project.org/browse/QTBUG/component/19173#selectedTab=com.atlassian.jira.plugin.system.project:component-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.

The problem you are describing here is true and is something that needs to be addressed. I held a discussion at the 2014 Qt contributors summit and said basically the same thing. QtMultimedia contains a rather large set of APIs but for most platforms there are huge gaps in the features available. The problem as you stated has to do with resources and prioritisation. The number of “active” QtMultimedia contributors can be counted on 1 hand, and almost all of the work requires detailed knowledge of the native multimedia APIs for each platform. This leads to a situation where only the most important bugs on the most used platforms get fixed, and the other serious bugs will stay in the queue. Qt has a huge scope yet a finite amount of development resources. QtMultimedia is a victim of the prioritisation of developer resources.

With the current state of QtMultimedia, it is not uncommon for users who have a heavy dependance of multimedia functionality to use the native API’s directly rather than using QtMultimedia.

A bit of history for those of you who don’t know. QtMultimedia was developed and maintained in Brisbane, Australia by the Qt team in Nokia. When Nokia divested in Qt, they closed the Brisbane office and suddenly the QtMultimedia team ceased to exist. At this point Qt 5.0.0 had not yet been released, and many other modules that had been the responsible of the Brisbane team were dropped due to being unfinished, but still “add-ons”. QtMultimedia being considered an “essential” module was not dropped, but was still unfinished. 3 developers then with Digia (myself included) volunteered to contribute part-time to QtMultimedia to try and get it up to a “usable” state for release, but there was a considerable amount of work left come release time. The decision was made to keep the module in the release despite the many gaps in functional of the various backends because of it’s essential nature. Since the release we have added at least 3 additional platform backends (iOS, Android, WinRT) each of which usually have both a high-level multimedia backend as well as a low level audio API. This succeeded in spreading us even more thin regarding developer resources.

It is worth mentioning that while I am no longer working with QtMultimedia, Yoann who is the current maintainer of QtMultimedia module is working full-time on it. There have also been contributions towards GStreamer 1.x support recently that has been greatly appreciated.

Now is a great time to become a contributor to QtMultimedia as it definitely needs some love. If anyone is interested in becoming a contributor to QtMultimedia I would be happy to answer questions to help get you up to speed.

Regards,
Andy Nichols
Kevin Kofler
2014-11-09 22:09:37 UTC
Permalink
Nichols Andy wrote:
> A bit of history for those of you who don’t know. QtMultimedia was
> developed and maintained in Brisbane, Australia by the Qt team in Nokia.
> When Nokia divested in Qt, they closed the Brisbane office and suddenly
> the QtMultimedia team ceased to exist. At this point Qt 5.0.0 had not yet
> been released, and many other modules that had been the responsible of the
> Brisbane team were dropped due to being unfinished, but still “add-ons”.
> QtMultimedia being considered an “essential” module was not dropped, but
> was still unfinished. 3 developers then with Digia (myself included)
> volunteered to contribute part-time to QtMultimedia to try and get it up
> to a “usable” state for release, but there was a considerable amount of
> work left come release time. The decision was made to keep the module in
> the release despite the many gaps in functional of the various backends
> because of it’s essential nature. Since the release we have added at
> least 3 additional platform backends (iOS, Android, WinRT) each of which
> usually have both a high-level multimedia backend as well as a low level
> audio API. This succeeded in spreading us even more thin regarding
> developer resources.

How is QtMultimedia "essential" when there had been a working alternative
(Phonon) even before QtMultimedia was started? In fact, Phonon used to be
hailed as the showcase for perfect collaboration between Qt and KDE, and
even shipped with Qt, until Nokia decided to reinvent the wheel. (At that
point, the bundled copy of Phonon in Qt 4 ceased being updated and was
arbitrarily "deprecated", while the Phonon project moved on.)

IMHO, QtMultimedia should have been dropped from Qt 5 and its users moved to
Phonon (upstream Phonon from KDE, not some ancient bundled copy of it)
instead. QtMultimedia is a gigantic waste of resources. Those developers
wanting to improve multimedia in Qt should be helping develop Phonon instead
(which could also use more manpower, despite not being as stagnant as
QtMultimedia). For example, QML integration is planned but (last I checked)
not yet implemented.

Kevin Kofler
Holger Hans Peter Freyther
2014-11-10 08:43:25 UTC
Permalink
On Sun, Nov 09, 2014 at 11:09:37PM +0100, Kevin Kofler wrote:
> Nichols Andy wrote:

> How is QtMultimedia "essential" when there had been a working alternative
> (Phonon) even before QtMultimedia was started? In fact, Phonon used to be
> hailed as the showcase for perfect collaboration between Qt and KDE, and
> even shipped with Qt, until Nokia decided to reinvent the wheel. (At that
> point, the bundled copy of Phonon in Qt 4 ceased being updated and was
> arbitrarily "deprecated", while the Phonon project moved on.)

tossing my two cents. Multimedia is hard. I sat three days at a
korean company trying to figure out why Qt Phonon wouldn't play
a MP3. In the end I was asked to stop debugging but the issues
were:

* Phonon making certain assumptions on GStreamer
* GStreamer making certain assumptions on its plugins
* HW Vendor not caring about any assumption when creating/
providing plugins.

The issue is that neither GStreamer nor Phonon verified its'
assumptions. This means if something goes wrong... you will
debug for a long time (abstractions for an abstraction, etc).
At the same time "gst-launch playbin(2) .." just worked.

Multimedia is hard and creating an abstraction is a nice goal
but the details and fall-out can be horrible (just like in my
Phonon example and QtMultimedia in this threads experience).

Now really getting to my two cents. Instead of wrapping API
Qt should make sure the framework can be integrated. E.g. in
terms of GStreamer provide plugins that allows to easily embed
video into Qt applications but ask users to use the "native"
API to manage the pipeline/playback.

kind regards
holger
Simon Hausmann
2014-11-11 08:47:08 UTC
Permalink
On Monday 10. November 2014 09.43.25 Holger Hans Peter Freyther wrote:
[...]
> Now really getting to my two cents. Instead of wrapping API
> Qt should make sure the framework can be integrated. E.g. in
> terms of GStreamer provide plugins that allows to easily embed
> video into Qt applications but ask users to use the "native"
> API to manage the pipeline/playback.

I share that philosophy and support any efforts towards making integrations
like that easier. In the case of multimedia that can be tricky though, but
that's not necessarily Qt's fault. It did take a while until gstreamer had
basic OpenGL texture streaming support, while frameworks on other platforms
have had it longer. Nevertheless once you can get hold of that, I think the Qt
Quick Scene Graph API is rather well suited for the graphics integration.



Simon
Knoll Lars
2014-11-11 09:41:49 UTC
Permalink
On 11/11/14 09:47, "Simon Hausmann" <***@theqtcompany.com>
wrote:

>On Monday 10. November 2014 09.43.25 Holger Hans Peter Freyther wrote:
>[...]
>> Now really getting to my two cents. Instead of wrapping API
>> Qt should make sure the framework can be integrated. E.g. in
>> terms of GStreamer provide plugins that allows to easily embed
>> video into Qt applications but ask users to use the "native"
>> API to manage the pipeline/playback.
>
>I share that philosophy and support any efforts towards making
>integrations
>like that easier. In the case of multimedia that can be tricky though,
>but
>that's not necessarily Qt's fault. It did take a while until gstreamer
>had
>basic OpenGL texture streaming support, while frameworks on other
>platforms
>have had it longer. Nevertheless once you can get hold of that, I think
>the Qt
>Quick Scene Graph API is rather well suited for the graphics integration.

Well, if you’re doing a complex multimedia app, this might be the right
approach. But for the 90% use case (show a video, play a sound, capture
something from the camera), we can’t tell people to write 10 different
implementations for the 10 platforms/OSes we support.

Cheers,
Lars
Simon Hausmann
2014-11-11 09:50:25 UTC
Permalink
On Tuesday 11. November 2014 10.41.49 Knoll Lars wrote:
> On 11/11/14 09:47, "Simon Hausmann" <***@theqtcompany.com>
> wrote:
>
>
> >On Monday 10. November 2014 09.43.25 Holger Hans Peter Freyther wrote:
> >[...]
> >
> >> Now really getting to my two cents. Instead of wrapping API
> >> Qt should make sure the framework can be integrated. E.g. in
> >> terms of GStreamer provide plugins that allows to easily embed
> >> video into Qt applications but ask users to use the "native"
> >> API to manage the pipeline/playback.
> >
> >
> >I share that philosophy and support any efforts towards making
> >integrations
> >like that easier. In the case of multimedia that can be tricky though,
> >but
> >that's not necessarily Qt's fault. It did take a while until gstreamer
> >had
> >basic OpenGL texture streaming support, while frameworks on other
> >platforms
> >have had it longer. Nevertheless once you can get hold of that, I think
> >the Qt
> >Quick Scene Graph API is rather well suited for the graphics integration.
>
>
> Well, if you’re doing a complex multimedia app, this might be the right
> approach. But for the 90% use case (show a video, play a sound, capture
> something from the camera), we can’t tell people to write 10 different
> implementations for the 10 platforms/OSes we support.

Yeah, I think that justifies the existence of qtmultimedia very well.


Simon
Gianluca
2014-11-11 10:32:33 UTC
Permalink
Il giorno 11/nov/2014, alle ore 10:41, Knoll Lars <***@theqtcompany.com> ha scritto:

> On 11/11/14 09:47, "Simon Hausmann" <***@theqtcompany.com>
> wrote:
>
>> On Monday 10. November 2014 09.43.25 Holger Hans Peter Freyther wrote:
>> [...]
>>> Now really getting to my two cents. Instead of wrapping API
>>> Qt should make sure the framework can be integrated. E.g. in
>>> terms of GStreamer provide plugins that allows to easily embed
>>> video into Qt applications but ask users to use the "native"
>>> API to manage the pipeline/playback.
>>
>> I share that philosophy and support any efforts towards making
>> integrations
>> like that easier. In the case of multimedia that can be tricky though,
>> but
>> that's not necessarily Qt's fault. It did take a while until gstreamer
>> had
>> basic OpenGL texture streaming support, while frameworks on other
>> platforms
>> have had it longer. Nevertheless once you can get hold of that, I think
>> the Qt
>> Quick Scene Graph API is rather well suited for the graphics integration.
>
> Well, if you’re doing a complex multimedia app, this might be the right
> approach. But for the 90% use case (show a video, play a sound, capture
> something from the camera), we can’t tell people to write 10 different
> implementations for the 10 platforms/OSes we support.
>
> Cheers,
> Lars
>

Dear Lars,
you are right, but Qt Multimedia is very far from achieve what 90% use case needs.
Since Qt 5.1, I wrote some small apps showing video and playing sound and capture camera, and even when the target was just one platform (iOS most of the case), Qt Multimedia failed to works and I was forced to use the native API and write a lot of code for using Qt Quick with native multimedia API that was more than the code for the rest of the app.
So, I like the Qt Multimedia approach, but it’s not usable now. For me the status is something like alpha instead of stable as it seems from the Digia’s blog.
I’ve never filed a bug regarding my situation just because a simple search on the forum will arise always with a documentation somewhere in the wiki indicating that the features was not supported on that platform.

>From a user that does not need to write complex multimedia apps, but just need to show some videos and doesn’t know almost anything about the complexity of videos playback, the frustration of using Qt Multimedia module is from the lack of clear statement of all “hole” in the implementation.
I don’t know if the Qt Multimedia team has the awareness that from external point of view what appear from Digia’s blog and documentation about the Qt Multimedia is something like the holy gral of cross-platform multimedia library, but when you try to use in a toy situation just doesn’t work as expected.

For me, at the moment, Qt Multimedia is the most weakest module of Qt and at the same time is the most advertised.

Cheers,
Gianluca.
Knoll Lars
2014-11-11 12:09:27 UTC
Permalink
On 11/11/14 11:32, "Gianluca" <***@gmail.com> wrote:

>
>Il giorno 11/nov/2014, alle ore 10:41, Knoll Lars
><***@theqtcompany.com> ha scritto:
>
>> On 11/11/14 09:47, "Simon Hausmann" <***@theqtcompany.com>
>> wrote:
>>
>>> On Monday 10. November 2014 09.43.25 Holger Hans Peter Freyther wrote:
>>> [...]
>>>> Now really getting to my two cents. Instead of wrapping API
>>>> Qt should make sure the framework can be integrated. E.g. in
>>>> terms of GStreamer provide plugins that allows to easily embed
>>>> video into Qt applications but ask users to use the "native"
>>>> API to manage the pipeline/playback.
>>>
>>> I share that philosophy and support any efforts towards making
>>> integrations
>>> like that easier. In the case of multimedia that can be tricky though,
>>> but
>>> that's not necessarily Qt's fault. It did take a while until gstreamer
>>> had
>>> basic OpenGL texture streaming support, while frameworks on other
>>> platforms
>>> have had it longer. Nevertheless once you can get hold of that, I think
>>> the Qt
>>> Quick Scene Graph API is rather well suited for the graphics
>>>integration.
>>
>> Well, if you’re doing a complex multimedia app, this might be the right
>> approach. But for the 90% use case (show a video, play a sound, capture
>> something from the camera), we can’t tell people to write 10 different
>> implementations for the 10 platforms/OSes we support.
>>
>> Cheers,
>> Lars
>>
>
>Dear Lars,
>you are right, but Qt Multimedia is very far from achieve what 90% use
>case needs.
>Since Qt 5.1, I wrote some small apps showing video and playing sound and
>capture camera, and even when the target was just one platform (iOS most
>of the case), Qt Multimedia failed to works and I was forced to use the
>native API and write a lot of code for using Qt Quick with native
>multimedia API that was more than the code for the rest of the app.
>So, I like the Qt Multimedia approach, but it’s not usable now. For me
>the status is something like alpha instead of stable as it seems from the
>Digia’s blog.
>I’ve never filed a bug regarding my situation just because a simple
>search on the forum will arise always with a documentation somewhere in
>the wiki indicating that the features was not supported on that platform.
>
>>From a user that does not need to write complex multimedia apps, but
>>just need to show some videos and doesn’t know almost anything about the
>>complexity of videos playback, the frustration of using Qt Multimedia
>>module is from the lack of clear statement of all “hole” in the
>>implementation.
>I don’t know if the Qt Multimedia team has the awareness that from
>external point of view what appear from Digia’s blog and documentation
>about the Qt Multimedia is something like the holy gral of cross-platform
>multimedia library, but when you try to use in a toy situation just
>doesn’t work as expected.
>
>For me, at the moment, Qt Multimedia is the most weakest module of Qt and
>at the same time is the most advertised.

I will agree with you that’s it’s one of the modules that need most work.
Andy’s email explains pretty well why this is the case. I’d be extremely
happy if we can finally find a way to fix that situation, but it isn’t all
that easy unfortunately. I certainly don’t think it’s the most advertised
module we have. Qt Quick and e.g. Qt WebEngine are for sure getting more
focus in terms of marketing.

Cheers,
Lars
Gianluca
2014-11-11 12:29:05 UTC
Permalink
Il giorno 11/nov/2014, alle ore 13:09, Knoll Lars <***@theqtcompany.com> ha scritto:

> On 11/11/14 11:32, "Gianluca" <***@gmail.com> wrote:
>
>>
>> Il giorno 11/nov/2014, alle ore 10:41, Knoll Lars
>> <***@theqtcompany.com> ha scritto:
>>
>>> On 11/11/14 09:47, "Simon Hausmann" <***@theqtcompany.com>
>>> wrote:
>>>
>>>> On Monday 10. November 2014 09.43.25 Holger Hans Peter Freyther wrote:
>>>> [...]
>>>>> Now really getting to my two cents. Instead of wrapping API
>>>>> Qt should make sure the framework can be integrated. E.g. in
>>>>> terms of GStreamer provide plugins that allows to easily embed
>>>>> video into Qt applications but ask users to use the "native"
>>>>> API to manage the pipeline/playback.
>>>>
>>>> I share that philosophy and support any efforts towards making
>>>> integrations
>>>> like that easier. In the case of multimedia that can be tricky though,
>>>> but
>>>> that's not necessarily Qt's fault. It did take a while until gstreamer
>>>> had
>>>> basic OpenGL texture streaming support, while frameworks on other
>>>> platforms
>>>> have had it longer. Nevertheless once you can get hold of that, I think
>>>> the Qt
>>>> Quick Scene Graph API is rather well suited for the graphics
>>>> integration.
>>>
>>> Well, if you’re doing a complex multimedia app, this might be the right
>>> approach. But for the 90% use case (show a video, play a sound, capture
>>> something from the camera), we can’t tell people to write 10 different
>>> implementations for the 10 platforms/OSes we support.
>>>
>>> Cheers,
>>> Lars
>>>
>>
>> Dear Lars,
>> you are right, but Qt Multimedia is very far from achieve what 90% use
>> case needs.
>> Since Qt 5.1, I wrote some small apps showing video and playing sound and
>> capture camera, and even when the target was just one platform (iOS most
>> of the case), Qt Multimedia failed to works and I was forced to use the
>> native API and write a lot of code for using Qt Quick with native
>> multimedia API that was more than the code for the rest of the app.
>> So, I like the Qt Multimedia approach, but it’s not usable now. For me
>> the status is something like alpha instead of stable as it seems from the
>> Digia’s blog.
>> I’ve never filed a bug regarding my situation just because a simple
>> search on the forum will arise always with a documentation somewhere in
>> the wiki indicating that the features was not supported on that platform.
>>
>>> From a user that does not need to write complex multimedia apps, but
>>> just need to show some videos and doesn’t know almost anything about the
>>> complexity of videos playback, the frustration of using Qt Multimedia
>>> module is from the lack of clear statement of all “hole” in the
>>> implementation.
>> I don’t know if the Qt Multimedia team has the awareness that from
>> external point of view what appear from Digia’s blog and documentation
>> about the Qt Multimedia is something like the holy gral of cross-platform
>> multimedia library, but when you try to use in a toy situation just
>> doesn’t work as expected.
>>
>> For me, at the moment, Qt Multimedia is the most weakest module of Qt and
>> at the same time is the most advertised.
>
> I will agree with you that’s it’s one of the modules that need most work.
> Andy’s email explains pretty well why this is the case. I’d be extremely
> happy if we can finally find a way to fix that situation, but it isn’t all
> that easy unfortunately. I certainly don’t think it’s the most advertised
> module we have. Qt Quick and e.g. Qt WebEngine are for sure getting more
> focus in terms of marketing.
>
> Cheers,
> Lars
>

Dear Lars,
I’m using Qt from more than 10 years, and I like so much the Qt library that I always want to contribute in some way. I cannot afford at the moment to put myself in working at the Qt code, so often I think to buy a commercial license only to contribute in some way to development even if I don’t need it. But I cannot afford it too.
So, I throw a suggestion for the future in this email even if it’s off-topic: why don’t ask donation for some specific module improvement and development ? I was very happy to donate some money to help the development of Qt Multimedia. And maybe, with a survey it would be possible to know which module will get more contribution to its development via donation.
What do you think ?

Cheers,
Gianluca.
André Somers
2014-11-11 12:32:52 UTC
Permalink
Gianluca schreef op 11-11-2014 13:29:
>
> Dear Lars,
> I’m using Qt from more than 10 years, and I like so much the Qt library that I always want to contribute in some way. I cannot afford at the moment to put myself in working at the Qt code, so often I think to buy a commercial license only to contribute in some way to development even if I don’t need it. But I cannot afford it too.
> So, I throw a suggestion for the future in this email even if it’s off-topic: why don’t ask donation for some specific module improvement and development ? I was very happy to donate some money to help the development of Qt Multimedia. And maybe, with a survey it would be possible to know which module will get more contribution to its development via donation.
> What do you think ?
>

While it sounds sympathetic, I have yet to see such donation/bounty
based systems really work. They've popped up for other projects in the
past, but the ones I have seen have not yielded much. And nobody ever
claimed the bounties I have offered. I'd be afraid it takes more
resources to setup and maintain than it would yield in terms of donations.

André
Cristian Adam
2014-11-11 12:43:18 UTC
Permalink
On Tue, Nov 11, 2014 at 1:29 PM, Gianluca <***@gmail.com> wrote:

>
> Dear Lars,
> I’m using Qt from more than 10 years, and I like so much the Qt library
> that I always want to contribute in some way. I cannot afford at the moment
> to put myself in working at the Qt code, so often I think to buy a
> commercial license only to contribute in some way to development even if I
> don’t need it. But I cannot afford it too.
> So, I throw a suggestion for the future in this email even if it’s
> off-topic: why don’t ask donation for some specific module improvement and
> development ? I was very happy to donate some money to help the development
> of Qt Multimedia. And maybe, with a survey it would be possible to know
> which module will get more contribution to its development via donation.
> What do you think ?
>
>
Would this recently posted blog entry
http://www.kdab.com/new-service-fix-qt-bug/ help?

Cheers,
Cristian.
André Somers
2014-11-11 12:44:09 UTC
Permalink
Cristian Adam schreef op 11-11-2014 13:43:
> On Tue, Nov 11, 2014 at 1:29 PM, Gianluca <***@gmail.com
> <mailto:***@gmail.com>> wrote:
>
>
> Dear Lars,
> I'm using Qt from more than 10 years, and I like so much the Qt
> library that I always want to contribute in some way. I cannot
> afford at the moment to put myself in working at the Qt code, so
> often I think to buy a commercial license only to contribute in
> some way to development even if I don't need it. But I cannot
> afford it too.
> So, I throw a suggestion for the future in this email even if it's
> off-topic: why don't ask donation for some specific module
> improvement and development ? I was very happy to donate some
> money to help the development of Qt Multimedia. And maybe, with a
> survey it would be possible to know which module will get more
> contribution to its development via donation.
> What do you think ?
>
>
> Would this recently posted blog entry
> http://www.kdab.com/new-service-fix-qt-bug/ help?
>
Based on the disclaimer on that site, I don't think the service would
help in this case...

André
Holger Hans Peter Freyther
2014-11-12 08:22:54 UTC
Permalink
On Tue, Nov 11, 2014 at 09:41:49AM +0000, Knoll Lars wrote:

Good Morning Lars,

> Well, if you’re doing a complex multimedia app, this might be the right
> approach. But for the 90% use case (show a video, play a sound, capture
> something from the camera), we can’t tell people to write 10 different
> implementations for the 10 platforms/OSes we support.

Well, somebody needs to support these 10 platforms. And to make
it worse. With things like GStreamer.. a lot depends on the used
plugins. So any abstraction built needs to be superior to Phonon
to help in detecting and debugging crazy vendor stuff.

When things don't work the promise of Qt falls apart (no matter
how crappy that vendor plugin is, specially when playbin just
does the right thing). And when the cost of debugging/analyzing
is higher than the cost of integrating directly with the OS
multimedia stack it looks worse.

How is multimedia different from the X11/Win extras?


holger
v***@gmail.com
2014-11-12 13:58:53 UTC
Permalink
Il 12/11/2014 09:22, Holger Hans Peter Freyther ha scritto:
> On Tue, Nov 11, 2014 at 09:41:49AM +0000, Knoll Lars wrote:
>
> Good Morning Lars,
>
>> Well, if you’re doing a complex multimedia app, this might be the right
>> approach. But for the 90% use case (show a video, play a sound, capture
>> something from the camera), we can’t tell people to write 10 different
>> implementations for the 10 platforms/OSes we support.
> Well, somebody needs to support these 10 platforms. And to make
> it worse. With things like GStreamer.. a lot depends on the used
> plugins. So any abstraction built needs to be superior to Phonon
> to help in detecting and debugging crazy vendor stuff.
Why phonon(t1) could not be made superior to phonon(t0) ?
And benefit both qt and kde in the process?

>
> When things don't work the promise of Qt falls apart (no matter
> how crappy that vendor plugin is, specially when playbin just
> does the right thing). And when the cost of debugging/analyzing
> is higher than the cost of integrating directly with the OS
> multimedia stack it looks worse.
>
> How is multimedia different from the X11/Win extras?
>
>
> holger
>
Thiago Macieira
2014-11-12 20:37:13 UTC
Permalink
On Wednesday 12 November 2014 09:22:54 Holger Hans Peter Freyther wrote:
> Well, somebody needs to support these 10 platforms. And to make
> it worse. With things like GStreamer.. a lot depends on the used
> plugins. So any abstraction built needs to be superior to Phonon
> to help in detecting and debugging crazy vendor stuff.

I'm sorry, I disagree. People should configure their GStreamers properly and Qt
should assume that it is working properly. GStreamer is a very complex
framework, as you said, with lots of configuration, so figuring out what's wrong
with it from inside the Qt layer, at runtime, is probably too much.

We should provide scripts for people to test their GStreamers, so we can
isolate problems. If it is on GStreamer's side, we "punt" the problem to the
Linux distribution and wash our hands off. That will make people choose decent
Linux distributions, even for embedded systems (like Yocto). If they can't do
that, they have the option of throwing money at the problem and paying
consultants to fix the problem.

Note: I'm advocating this for system misconfiguration, not for systemic /
structural problems of the frameworks. If GStreamer has bugs that affect us, we
work around them, much in the same way we work around Bionic limitations on
Android.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Holger Hans Peter Freyther
2014-11-12 22:17:57 UTC
Permalink
On Wed, Nov 12, 2014 at 12:37:13PM -0800, Thiago Macieira wrote:

Good Evening Thiago,

> We should provide scripts for people to test their GStreamers, so we can
> isolate problems. If it is on GStreamer's side, we "punt" the problem to the
> Linux distribution and wash our hands off. That will make people choose decent
> Linux distributions, even for embedded systems (like Yocto). If they can't do
> that, they have the option of throwing money at the problem and paying
> consultants to fix the problem.

I haven't done consumer products for the last two years and I would
be happy if the following has changed. I had to listen things like:
"GDB is not supported on this device" (because the SoC vendor didn't
put a binary into the "SDK")...

Anyway, if "gst-launch playbin uri=file:///music.mp3" works and the
same doesn't work with Qt.. you have a hard time arguing that their
system is broken. That is the difference of working in the comfort
zone with a sane Linux system and going out in the field and see
what the companies actually use.

I don't have the spare time to work on multimedia things, so it is
really just my two cents.

holger
Thiago Macieira
2014-11-13 00:04:52 UTC
Permalink
On Wednesday 12 November 2014 23:17:57 Holger Hans Peter Freyther wrote:
> I haven't done consumer products for the last two years and I would
> be happy if the following has changed. I had to listen things like:
> "GDB is not supported on this device" (because the SoC vendor didn't
> put a binary into the "SDK")...

I know, but I really wish people would stop buying boards from those vendors.
The saving of a few cents or dollars in those boards translate to more work
for us and we don't get paid for it. That's why I said it's ok to hire
consultants to fix the problem. When the accountants come in later and figure
out that it cost more than going with a better vendor, maybe we'll effect
change.

> Anyway, if "gst-launch playbin uri=file:///music.mp3" works and the
> same doesn't work with Qt.. you have a hard time arguing that their
> system is broken. That is the difference of working in the comfort
> zone with a sane Linux system and going out in the field and see
> what the companies actually use.

That's my point: we have to provide scripts that test GStreamer so we can be
confident it's properly configured, providing the functionality we need. If that
command above is representative, then great.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Knoll Lars
2014-11-13 07:21:38 UTC
Permalink
On 13/11/14 01:04, "Thiago Macieira" <***@intel.com> wrote:

>On Wednesday 12 November 2014 23:17:57 Holger Hans Peter Freyther wrote:
>> I haven't done consumer products for the last two years and I would
>> be happy if the following has changed. I had to listen things like:
>> "GDB is not supported on this device" (because the SoC vendor didn't
>> put a binary into the "SDK")...
>
>I know, but I really wish people would stop buying boards from those
>vendors.
>The saving of a few cents or dollars in those boards translate to more
>work
>for us and we don't get paid for it. That's why I said it's ok to hire
>consultants to fix the problem. When the accountants come in later and
>figure
>out that it cost more than going with a better vendor, maybe we'll effect
>change.

I fully agree here. It is not Qt's responsibility to fix fundamental
issues in crappy linux distributions.

>> Anyway, if "gst-launch playbin uri=file:///music.mp3" works and the
>> same doesn't work with Qt.. you have a hard time arguing that their
>> system is broken. That is the difference of working in the comfort
>> zone with a sane Linux system and going out in the field and see
>> what the companies actually use.
>
>That's my point: we have to provide scripts that test GStreamer so we can
>be
>confident it's properly configured, providing the functionality we need.
>If that
>command above is representative, then great.

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.


Cheers,
Lars
Thiago Macieira
2014-11-13 07:40:12 UTC
Permalink
On Thursday 13 November 2014 07:21:38 Knoll Lars wrote:
> 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.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Knoll Lars
2014-11-13 07:56:31 UTC
Permalink
On 13/11/14 08:40, "Thiago Macieira" <***@intel.com> wrote:

>On Thursday 13 November 2014 07:21:38 Knoll Lars wrote:
>> 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.

Lars
Thiago Macieira
2014-11-13 08:05:32 UTC
Permalink
On Thursday 13 November 2014 07:56:31 Knoll Lars wrote:
> On 13/11/14 08:40, "Thiago Macieira" <***@intel.com> wrote:
>
>
> >On Thursday 13 November 2014 07:21:38 Knoll Lars wrote:
> >
> >> 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.

Agreed, and you'd expect that a decent Linux distribution runs them to be sure
that they've installed everything correctly.

But we're discussing a non-decent state already. If we could provide a handful
of manual test scripts that let people check their conditions, we can isolate
the problem and convince them it's not our fault.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Al-Khanji Louai
2014-11-13 08:27:49 UTC
Permalink
> > 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.
>
> Agreed, and you'd expect that a decent Linux distribution runs them to be
> sure
> that they've installed everything correctly.
>
> But we're discussing a non-decent state already. If we could provide a
> handful
> of manual test scripts that let people check their conditions, we can isolate
> the problem and convince them it's not our fault.
>

I have to say I agree. In practice a lot of systems are very poorly configured to the point that functionality that the vendor specifically advertises does not work.

I'm currently looking at a board where a glClear() followed by eglSwapBuffers() does not run above 52 fps on a 60hz display. This is clearly an issue outside Qt - I am able to demonstrate this with a sample that uses DRM, GBM and EGL directly. As long as Qt is in the equation there is always the suspicion that the cause lies with it.

This is not the first time I have to show that some issue is not caused by Qt. I have also watched many of my colleagues go through contortions to convince customers that their setups are just broken or plain not fast enough - although of course sometimes it really is down to something within Qt. :) Even for those cases an independent "Qt Conformance Suite" would be useful.

Maybe such tests could be incorporated into the module unit tests as a sort of precondition - if these tests don't work, then the module won't work properly either.

-- Louai
Tim Blechmann
2014-11-13 08:19:23 UTC
Permalink
>>> 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.
Gianluca
2014-11-13 08:45:35 UTC
Permalink
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 <***@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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Kevin Kofler
2014-11-15 11:47:19 UTC
Permalink
Holger Hans Peter Freyther wrote:
> The issue is that neither GStreamer nor Phonon verified its'
> assumptions. This means if something goes wrong... you will
> debug for a long time (abstractions for an abstraction, etc).
> At the same time "gst-launch playbin(2) .." just worked.

FYI, current versions of Phonon-GStreamer (from upstream Phonon, not the
ancient version bundled with Qt 4) use playbin2.

Kevin Kofler
Kevin Kofler
2014-11-09 22:02:52 UTC
Permalink
Massimo Callegari wrote:
> 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.

Have you considered using Phonon? Not the ancient version bundled with Qt 4,
but the real thing, directly from the KDE developers? It can also be built
against Qt 5 now.

Kevin Kofler
Gianluca
2014-11-09 22:29:48 UTC
Permalink
Phonon ?!?!
Please can you give us some links to this Phonon for Qt5 ?
On which platform has been ported Phonon ? I really need a good multimedia module for android and iOS.

Thanks,
Gianluca.


Il giorno 09/nov/2014, alle ore 23:09, Kevin Kofler <***@chello.at> ha scritto:

> Massimo Callegari wrote:
>> 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.
>
> Have you considered using Phonon? Not the ancient version bundled with Qt 4,
> but the real thing, directly from the KDE developers? It can also be built
> against Qt 5 now.
>
> Kevin Kofler
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Kevin Kofler
2014-11-09 23:57:19 UTC
Permalink
Gianluca wrote:
> Phonon ?!?!
> Please can you give us some links to this Phonon for Qt5 ?

https://phonon.kde.org/ (some of the linked wiki information is outdated)
https://projects.kde.org/projects/kdesupport/phonon
http://download.kde.org/stable/phonon/
Build the latest release with -DPHONON_BUILD_PHONON4QT5:BOOL=ON to use Qt 5.

> On which platform has been ported Phonon ?

Basically, everything either GStreamer (1.x for Phonon 4.8) or VLC (libvlc)
can be compiled for should work.

There used to be some other backends too:
https://userbase.kde.org/Phonon#Backend_libraries
but none of them is actively maintained, so they will probably not work with
the latest Phonon, especially on Qt 5.

> I really need a good multimedia module for android and iOS.

The GStreamer project supports both Android and iOS, so in principle, you
should be able to build GStreamer and Phonon for them. (For GStreamer, there
are also prebuilt binaries provided by the GStreamer project at
http://gstreamer.freedesktop.org/data/pkg/ .) VLC also supports VLC the
application on Android and iOS, not sure about usage as a library though
(which is what matters for Phonon). GStreamer is only a library. But whether
anybody has tested Phonon on those platforms yet, I don't know.

In your case, you say in the other thread that you're using Qt Quick, so
unfortunately, you'll probably have to wait until they get their Qt Quick
support sorted out (or help with that yourself). There is some code in the
"declarative" subdirectory, but it is not built by default (only if
-DPHONON_BUILD_DECLARATIVE_PLUGIN:BOOL=ON is passed to CMake), it only
targets QML 1 at this time, and I don't know whether and how well it works.

I know that QML / Qt Quick support is on the Phonon developers' radar and
I'm sure they would appreciate any help with getting that done.

Kevin Kofler
Massimo Callegari
2014-11-13 21:36:15 UTC
Permalink
Massimo Callegari wrote:
> 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.

>> Have you considered using Phonon? Not the ancient version bundled with Qt 4,
>> but the real thing, directly from the KDE developers? It can also be built
>> against Qt 5 now.
>>
>> Kevin Kofler
Hello again,I'm glad that the topic I raised is somehow of interest, but I noticed that, as usually good technicians do, you guys went straight into techy bits, forgetting what the original post spotted.They say that when you are aware of a problem you have it 50% solved.What concerns me is the remaining 50%, and since plans (and money) move this world, I would kindly ask if someone is in charge of making a plan to address the QtMultimedia issues and making it a quality part of the Qt framework.
For example, what sounds a good plan to me is something like: we'll dedicate the necessary resources to close all the JIRA issues for version 5.5. OK...80% would be fair enough :)Just an example that includes numbers and a time line.
Discussing the bits without a plan, is like discussing the sex of the angels (like we say in Italy) as nobody will do anything in the end.
Random notes on the various replies:- 2 years ago, Phonon was exactly the reason why I decided to write my own implementations on Qt4. I was scared of the consequences of deploying on 3 platforms with it (IF that was ever possible). Maybe now the situation is different, but there's Android and iOS and I still would not go to Phonon anyway.I don't understand why everybody wants to walk their own way. Why can't you Phonon guys help on QtMultimedia (you could have joined in 2012...) instead of advertising a module by telling people which flags they need to use to build it ? Are you aware of how difficult it is to build ANYTHING with MinGW on Windows ? (and no, I won't use M$ compilers, thanks)
- I agree with everybody that cross-platform multimedia integrations are a tough job and a quite delicate matter. But once it's done it's done and the bright side of the thing is that Qt has a super vast community that gives feedback on different OSes, hardware and usages.
- I super agree with Lars. The Qt promise of writing code once and deploying everywhere is the key of it all. If this isn't met, then it's not Qt anymore.
- I haven't really got an opinion about issues-oriented donations, but you might end up having 200 $20 donations for 200 different issues. Then which one will you solve first ?
Cheers,Massimo
Kevin Kofler
2014-11-15 13:03:56 UTC
Permalink
Massimo Callegari wrote:
> Hello again,I'm glad that the topic I raised is somehow of interest, but I
> noticed that, as usually good technicians do, you guys went straight into
> techy bits, forgetting what the original post spotted.

Because the "techy bits" are the (essential) first part of solving the
problem.

> For example, what sounds a good plan to me is something like: we'll
> dedicate the necessary resources to close all the JIRA issues for version
> 5.5.

Well, I don't have any "resources" to "dedicate" (other than my limited free
time). That's something that only Digia (or some other company involved with
Qt) can decide. So I'll rather focus on the "how" (i.e. the "techy bits").

> Random notes on the various replies:- 2 years ago, Phonon was exactly the
> reason why I decided to write my own implementations on Qt4.

Please do note that Phonon has improved in the last 2 years, and that, if
the "Phonon" you were using was the one bundled with Qt 4, that's a several
years (!) old version, so if that was the case, Phonon had already improved
back then, you were just using an obsolete version. But even if you were
using the (then) current upstream Phonon, there have been improvements in
those 2 years, such as the port of the GStreamer backend to GStreamer 1, the
maturation of the VLC backend (to the point where it is now the "preferred"
backend according to the Phonon developers, but the GStreamer backend is
also fine) and many bugfixes.

This whole "bundled Phonon in Qt" story really proved to be a big disaster
in hindsight. It started with perfectly good intentions: ensuring this KDE-
developed technology becomes an integral part of Qt, delivered to Qt
customers (while keeping its LGPL license) and included in downloadable Qt
binaries. Unfortunately, what happened instead is that, shortly after
accepting the contribution with much press release fanfare, Qt decided to
reinvent the wheel by starting QtMultimedia, advertise that as the
"replacement" to the "deprecated" Phonon, and just stopping to update the
bundled copy of Phonon, despite the upstream Phonon project having long
moved on. That painted an image of Phonon being old and deprecated, when
that only applied to Qt's ancient bundled copy (which has become pure dead
weight, no sane distributor ships that version).

> I was scared of the consequences of deploying on 3 platforms with it (IF
> that was ever possible).

It has always been possible. Early versions (such as the one Qt 4 STILL
bundles, after all these years) had native DirectShow (Windows) and
QuickTime (Mac OS X) backends, next to first Xine and then GStreamer 0.10
for GNU/Linux. In later versions, the focus shifted to portable multimedia
frameworks: VLC support was added to Phonon, and GStreamer has been ported
to many platforms by the GStreamer developers. This change of focus happened
because of the quirks in the native proprietary multimedia frameworks that
are hard to work around, and because working with the same backend(s) on all
platforms results in significantly reduced maintenance work. (An additional,
non-technical reason for the switch was that the native backends had been
written by Trolltech for Qt 4's bundled Phonon, so when Trolltech stopped
maintaining them, interest faded. The only Trolltech-developed backend that
survived, with major refactoring, is the GStreamer one.) It also solves one
of the problems described in this thread, the one of different capabilities
of QtMultimedia (and old versions of Phonon) on different platforms.

> Maybe now the situation is different, but there's Android and iOS

Both GStreamer and VLC have been ported to those mobile platforms, so the
hard work has already been done. It just takes somebody to compile and test
Phonon for them.

> Why can't you Phonon guys help on QtMultimedia (you could have joined in
> 2012...)

Two things here:
1. I am not a Phonon developer. I am a KDE developer and a Fedora packager,
and as such I also help package Phonon for Fedora, but I am not directly
involved in Phonon development.
2. You are getting the history wrong. Phonon was there first! It's the
QtMultimedia folks who decided to not join Phonon, but reinvent the wheel
instead. Why should the Phonon developers have dropped their hard work to
join a pointless "Not Invented Here" project (which, at least back in
2012, was clearly inferior, and this thread shows that it's still of
dubious quality)?

> instead of advertising a module by telling people which flags they need to
> use to build it ?

I'm just trying to be helpful.

> Are you aware of how difficult it is to build ANYTHING with MinGW on
> Windows ?

For anything using CMake (and that includes Phonon), you just run the CMake
installer, and then:

cmake -G "MinGW Makefiles" (add any other options here) .
mingw32-make

or if you prefer MSYS:

cmake -G "MSYS Makefiles" (add any other options here) .
make

It's much less of a PITA than the dreaded autocrap (that even annoys me on
GNU/Linux more often than not).

There is also some tooling by the kdewin project (kdewin emerge) that can be
used to compile things. They also have prebuilt binaries, but not of Qt 5
stuff yet (they're still working on it).

Kevin Kofler
Nichols Andy
2014-11-15 17:54:29 UTC
Permalink
Hi Kevin and others,

I still think that this discussion has derailed. I do not think Phonon is the solution to fix or replace QtMultimedia so I hope to make this clear so we can move on to a real solution.

The current state of Phonon is thus:

Phonon is part of the KDE project and is licensed as LGPLv2.1 only. This is an issue for Qt because if Phonon is to again become our solution for providing multimedia, then it only really covers a percentage of our user base. It is important for us to be able to offer flexible licensing options to our customers, and without the option to do so this is already a non-starter. The same goes for the rest of the KDE 5 frameworks. Some people are OK with using the LGPL license and that is fine, but the Qt product itself needs more options.

Phonon is only somewhat actively developed, as I counted about 15 real commits in the phonon/master and 30 real commits the the phonon-gstreamer/master repository this year (commits that weren’t merges or version bumps). By comparison QtMultimedia received this year around 150 commits from Christian and Yoann alone, with over 40 additional unique contributors with at least one patch this year. Sure we have a much large scope in having to support so many platforms, but that is not insignificant.

Phonon is primarily targeted at Qt 4. It is compatible with Qt 5, but in the same way that many Qt 4 applications can easily be ported to Qt 5 due to us being mostly source compatible.

Phonon does not have support for Qt Quick 2. This is related to the previous point, as there is currently only support for QtQuick 1 (QGraphicsView). Additional development effort would be required to fully bring Phonon into the Qt 5 era.

Phonon is only supported on the Desktop platforms. Any support for mobile platforms is theoretical in that the libVLC and GStreamer dependencies of the backends have support for running there.

Phonon being part of the KDE project uses the Cmake build system. While not a problem in itself, a Qt essentials module should distributed as part of Qt 5 should be build with the default build system qmake. Not a hard problem to overcome but yet another barrier to current acceptance.

Phonon has dropped its native backends in favour of using libVLC and GStreamer. This seems to be the Phonon project’s solution to not having enough resources available to maintain native backends, and while this is a tempting option we have considered for QtMultimedia, it may not be the right solution either. If we depend on a 3rd party library like libVLC or GStreamer (on platforms other than Linux), then if someone would like to use the multimedia functionality, then they would need to have this dependency when developing and deploy it along with their application. We likely could not distribute either libVLC or GStreamer along with Qt releases due to licensing and patent concerns, so this would be one more barrier to getting started. What is nice about using the native frameworks is that they are already available on the machines, and they give the most flexibility with regards to features and performance. Using the native backends also means that deployment is easier as the end user will not need to bundle libVLC or GStreamer with their application. If anything I think we should offer these backends as an option(cross-platform GStreamer and libVLC) along side the existing native backends in QtMultimedia.

Most of these issues could be resolved with some development effort, however this will not fix the critical issue of licensing.

Hopefully this adds some perspective to the discussion.

Regards,
Andy Nichols
Gianluca
2014-11-17 08:10:06 UTC
Permalink
Il giorno 17/nov/2014, alle ore 07:26, Konstantin Podsvirov <***@podsvirov.pro> ha scritto:

> On Sunday 16 November 2014 22:31:45 Gianluca wrote:
>> So, from my point of view, the QtMultimedia seems abandoned (I hope it’s a
>> wrong deduction from a superficial view of the project). The indication of
>> that deduction comes, for example, from the wiki page
>
> It's wrong. You're looking at wrong data. Forget the wiki, look only at commit
> history and the bugtracker, to see if bugs are being fixed. There were 318
> commits since the beginning of the year. That's not abandoned.

I’m very happy. That’s give a complete different view. But, I would disagree about your suggestion of “forget the wiki”, because the main communication with the Qt user should pass from there. Only few users has the will and the ability to look at the commit history and the bug tracker. I think that most of the users of Qt just look on the release notes and the blogs and the wiki to see if there is something new or improvements.
But this is another topic :-)

>
>> So, why there is so few resources and/or interest on developing the
>> QtMultimedia module ? For me, it seems a very fundamental module that I’m
>> really surprised that Digia’s do not commit strong resources on developing
>> it.
>
> Digia and now The Qt Company are companies and have business needs and
> business cases. They put the resources to work where their business needs and
> business cases show there's greatest advantage. If you want to influence those
> business concerns, please talk to your sales rep.

:-) I’m alone. In the sense, that I use Qt for my hobbies project, and recently I become a freelance activity and hence I don’t have any sales rep to talk about.

>
> If you're using the open source version of Qt, then please talk to one of the
> consulting companies to see if they will do the work for you, or at least do
> some work somewhere so that the resources that can work on QtMultimedia will
> be freed from other work. You can also do work yourself and contribute to Qt.

I would contribute by myself, but I’ve never involved in such a big projects and I don’t know where to start from.
Some days ago, I follow a suggestion to commit some improvements on the documentation because I wrote a clarification that user likes, but when I went on the page explaining all the procedure behind, I saw a long path only to read all the documentation about all the infrastructure used to maintain Qt. Consider that I’ve few experience on Git and none on Gerrit. So, it needs long time for me to grasp everything on the process and start contributing on Qt.

>
> Note: "so few resources" are responsible for 62% of the 318 commits.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Thiago Macieira
2014-11-17 16:47:39 UTC
Permalink
On Monday 17 November 2014 09:10:06 Gianluca wrote:
> I’m very happy. That’s give a complete different view. But, I would disagree
> about your suggestion of “forget the wiki”, because the main communication
> with the Qt user should pass from there. Only few users has the will and
> the ability to look at the commit history and the bug tracker. I think that
> most of the users of Qt just look on the release notes and the blogs and
> the wiki to see if there is something new or improvements.

I disagree. While it would be nice if everyone could follow the discussion,
that is not required. What is required is that other developers working on Qt
can follow the discussion. The primary communication channels are this mailing
list, Git, Gerrit and JIRA.

Note specially that if you're posting on this mailing list, you're expected to
have a Git checkout of the Qt source code.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Gianluca
2014-11-17 16:55:38 UTC
Permalink
Il giorno 17/nov/2014, alle ore 17:47, Thiago Macieira <***@intel.com> ha scritto:

> On Monday 17 November 2014 09:10:06 Gianluca wrote:
>> I’m very happy. That’s give a complete different view. But, I would disagree
>> about your suggestion of “forget the wiki”, because the main communication
>> with the Qt user should pass from there. Only few users has the will and
>> the ability to look at the commit history and the bug tracker. I think that
>> most of the users of Qt just look on the release notes and the blogs and
>> the wiki to see if there is something new or improvements.
>
> I disagree. While it would be nice if everyone could follow the discussion,
> that is not required. What is required is that other developers working on Qt
> can follow the discussion. The primary communication channels are this mailing
> list, Git, Gerrit and JIRA.
>
> Note specially that if you're posting on this mailing list, you're expected to
> have a Git checkout of the Qt source code.

That is where maybe Qt communication fails.
Because I don’t have Git checkout of Qt source code, I was always tend to avoid this mailing-list and to write only on the community forum. But maybe you should take a look on the forum, because I seen a lot of time people answering that the only way to get an answer is to ask on the development mailing-list because only developer knows everything. But sometimes it’s wrong.
In fact, I continue to think that it’s wrong to write on development mailing-list to know if a certain module is under development or not, and what features and improvements are planned for the next release. I think in this way, because also normal Qt user (those without git checkout of the source code) wants to know such information in order to plan their development and to choose if remain with Qt or user other tools.
Also part of this discussion (and this email) it’s off-topic for the development mailing-list, and I’m sorry for that.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Thiago Macieira
2014-11-17 17:01:19 UTC
Permalink
On Monday 17 November 2014 17:55:38 Gianluca wrote:
> That is where maybe Qt communication fails.
> Because I don’t have Git checkout of Qt source code, I was always tend to
> avoid this mailing-list and to write only on the community forum. But maybe
> you should take a look on the forum, because I seen a lot of time people
> answering that the only way to get an answer is to ask on the development
> mailing-list because only developer knows everything. But sometimes it’s
> wrong.

I have no clue about the forums. I will not post there or monitor there
because I dislike the medium.

However, I can tell you that the ***@qt-project.org mailing list is
monitored by a lot of developers. You can have discussions about the use of Qt
there. It's not required to have a Git checkout.

On this mailing list (development@), since we're talking about developing Qt,
if you're here you're mostly expected to be contributing to Qt or to be
willing to, which in turn translates to having a checkout.

> In fact, I continue to think that it’s wrong to write on development
> mailing-list to know if a certain module is under development or not, and
> what features and improvements are planned for the next release.

I agree. The interest@ mailing list would have been enough. My point is that
if you posted here, you're assumed to be a developer or willing to become one.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Nichols Andy
2014-11-17 00:34:48 UTC
Permalink
Hi Gianluca,

> But, what would be the solutions ?!?!

That is still up for discussion. The ideal solution would be more contributors and a clear mandate to fix the existing issues. Right now we have neither.

> The problem is that there is no clear evidence of development planning and improvements. As Callegari said in this email, he filed various bugs long time ago and they still there without any evidence of planning. From my side, I’m stuck on an limitation of VideoOutput on iOS that it’s still there from one year and I don’t see any planning of resolving the issue.
> So, from my point of view, the QtMultimedia seems abandoned (I hope it’s a wrong deduction from a superficial view of the project). The indication of that deduction comes, for example, from the wiki page about backend supports (http://qt-project.org/wiki/Qt_Multimedia_Backends). That page was not updated for a long time giving the impression that no work has been done to improve the QtMultimedia.
> In that table, there are a lot of “holes" and for each “hole” there is no indication if the “hole” has been planned to be resolved and in which Qt version, or if it is an “hole” impossibile to solve. So, it seems that better than this it’s not planned.
>
> For example, no one told me (even in this mailing list) if the VideoOutput limitation on iOS it’s impossible to solve or it’s planned to be solved in some Qt versione (i.e. Qt 5.5)

This is a bit of a side issue from the topic at hand, but I am the correct person to answer this question so I will. Regarding VideoOutput on iOS there is currently a serious limitation that we have been unable to over come. If you are using the QWidget based API on iOS (and you probably shouldn’t be) then everything should work fine. That is because it is easy to embed “native” controls in QWidget hierarchies, and thats what we do for QtMultimedia video output (overlay a AVPlayerLayer where the video output should go). However when we would like to render video in a Qt Quick 2 scene then we need to be able to render the video to a texture. On OS X it is possible to render video to a OpenGL texture from a hidden AVPlayerLayer window, and then render that in the Qt Quick 2 scene, but that API is not available on iOS. There is AFAIK currently no high-level API to render video from an AVPlayer to an OpenGL texture on iOS. The work around to provide any video at all in Qt Quick 2 is to to instead render to a “Window” control which instead falls back to the overlaying the native video window surface on top of the QQuickWindow. Yes it is less than ideal, but we are not the only framework with this limitation.

There are a couple of alternative approaches on iOS. It is actually possible using the AVFoundation API to decode encoded multimedia files that can be played and synced manually. For example you can feed AVFoundation a video file to be decoded and you will get access to: each image buffers (per frame), raw pcm audio data, and the timing information for synced playback, but then it is up to the end user to put that together as what gets seen and heard. I did study this route when I was working on the AVFoundation backend for iOS, but it was going to be too much work for the amount of time I had to get something working. Also as a comparison if you look at the Unity 3D game engine they have a similar limitation; it is possible to playback video’s to textures on iOS, but there is no support for audio simultaneously. Their workaround is to say that multimedia playback on iOS is only supported fullscreen (to a native window surface).

Another approach that is less than ideal is to use another API than AVFoundation. We could use another framework like libVLC which uses FFMpeg under the hood to render the video assets. This will generally be a less efficient path on iOS than using the native AVFoundation API, and also will potentially cause deployment headaches.

So unfortunately it is not being working on, their still isn’t a way to overcome this limitation that I’m aware of in the latest release of iOS, and the alternatives require quite a bit of effort and no one is volunteering to do this work.

>
> Since Qt 5.1, at each new release I’ll look into new features and improvements and what you can see is a very different pace of some modules respect to others and the QtMultimedia is always one of the slowest one in improvements and fixes.
>
> So, why there is so few resources and/or interest on developing the QtMultimedia module ? For me, it seems a very fundamental module that I’m really surprised that Digia’s do not commit strong resources on developing it.
>
> QtMultimedia has an very ambitious objective, and I think it cannot be good improvement just only hoping from community contributions, and there will be no good improvements if Digia (or some other big company) commit resources on it.

I think this comes back to the issue of resources. From the community side there has not been much interested in larger contributions to QtMultimedia. Many issues in QtMultimedia require more serious development effort than the average bug fix, so it’s harder to attract the interest of developers who would work on it in their spare time. I think the best approach here is to be open about what the situation is (as I have in this mail series), and to be as helpful as possible to anyone who would like to contribute to the project.

>From the commercial side resource allocation is influenced by customer demands. The is true for us at The Qt Company(Digia) and it is in our interest to prioritise the issues our customers are having on the platforms they are using. The more interest paying customers have in the QtMultimedia module, the more incentive we have to put more resources into it (vs other areas of Qt).

It is important that we are having this discussion to raise awareness of the situation in the QtMultimedia module but I don’t see a clear path forward to resolving these issues unless there are more developers out there genuinely able to contribute.

Regards,
Andy Nichols
Gianluca
2014-11-17 07:32:02 UTC
Permalink
Il giorno 17/nov/2014, alle ore 01:48, Thiago Macieira <***@intel.com> ha scritto:

> On Monday 17 November 2014 00:34:48 Nichols Andy wrote:
>> This is a bit of a side issue from the topic at hand, but I am the correct
>> person to answer this question so I will. Regarding VideoOutput on iOS
>> there is currently a serious limitation that we have been unable to over
>> come. If you are using the QWidget based API on iOS (and you probably
>> shouldn’t be) then everything should work fine. That is because it is easy
>> to embed “native” controls in QWidget hierarchies, and thats what we do for
>> QtMultimedia video output (overlay a AVPlayerLayer where the video output
>> should go). However when we would like to render video in a Qt Quick 2
>> scene then we need to be able to render the video to a texture. On OS X it
>> is possible to render video to a OpenGL texture from a hidden AVPlayerLayer
>> window, and then render that in the Qt Quick 2 scene, but that API is not
>> available on iOS. There is AFAIK currently no high-level API to render
>> video from an AVPlayer to an OpenGL texture on iOS. The work around to
>> provide any video at all in Qt Quick 2 is to to instead render to a
>> “Window” control which instead falls back to the overlaying the native
>> video window surface on top of the QQuickWindow. Yes it is less than
>> ideal, but we are not the only framework with this limitation.
>
> Why do you want to render video non-fullscreen anyway on a device with a small
> screen? Once the user clicks the play button, go to full screen with rotation
> support.

I don’t want to play in non-fullscreen, I typically play in full-screen. But the transition between full-screen video and QML side it’s very strange. I posted on the forum and someone told me that it’s a know limitations. But maybe he was wrong.
The problem is that when you change the visible property of VideoOutput on iOS you see on the screen something like a very fast flickering like it would be an animation moving out of the screen the video. This is very disturbing for a user.

And also, even when you play full-sreen a video, I want to put some overlay controls that appear and disappear on touch showing the play/pause button, the close button, the progress, the volume, etc. This is cannot possibile at the moment. (But this is less important that the ‘flickering’ problem).

Cheers,
Gianluca.
André Somers
2014-11-17 08:43:33 UTC
Permalink
Thiago Macieira schreef op 17-11-2014 01:48:
> Why do you want to render video non-fullscreen anyway on a device with
> a small screen? Once the user clicks the play button, go to full
> screen with rotation support.
What a short-sighted comment. I really respect you, but this comment
really misses the mark I think. Not every iOS device is a phone, and
even these can get rather large these days. And don't you need to render
controls? You don't think rendering video's embedded in a larger
application is ever needed in for example a simple video editor (for
which a device like the iPad Air 2 is perfectly suitable in terms of
processing power)?

IMHO, it is not up for framework developers to decide that user won't
need this kind of capability. It does need to be there, so application
developers can be creative in how they use video playback.

André
Pau Garcia i Quiles
2014-11-17 14:59:50 UTC
Permalink
On Mon, Nov 17, 2014 at 9:43 AM, André Somers <***@familiesomers.nl>
wrote:

IMHO, it is not up for framework developers to decide that user won't
> need this kind of capability. It does need to be there, so application
> developers can be creative in how they use video playback.
>
>
Indeed.

In fact, I am about to start development of a cross-platform application
(Windows, Linux, iOS, Android, Windows Phone). Showing a preview video in a
quarter-of-a-screen window is one of the fundamental requirements of the
app due to its nature.

I had considered Qt and Xamarin and bugs like this make me think if I
should change the team I selected and go for Xamarin instead :-/

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Thiago Macieira
2014-11-17 16:43:53 UTC
Permalink
On Monday 17 November 2014 09:43:33 André Somers wrote:
> Thiago Macieira schreef op 17-11-2014 01:48:
> > Why do you want to render video non-fullscreen anyway on a device with
> > a small screen? Once the user clicks the play button, go to full
> > screen with rotation support.
>
> What a short-sighted comment. I really respect you, but this comment
> really misses the mark I think. Not every iOS device is a phone, and
> even these can get rather large these days.

Unless it's a 23" screen or larger, it's still small. Render the video full
screen.

> And don't you need to render controls?

Yes, but I imagine that the video player has those controls already.

> You don't think rendering video's embedded in a larger
> application is ever needed in for example a simple video editor (for
> which a device like the iPad Air 2 is perfectly suitable in terms of
> processing power)?

No, I don't think there's any need to render in a smaller frame except for
specialised applications like the video editor that you mentioned. Those
specialised applications that do video as their main functionality will not
use the generic multimedia framework from the OS anyway.

> IMHO, it is not up for framework developers to decide that user won't
> need this kind of capability. It does need to be there, so application
> developers can be creative in how they use video playback.

While it would be nice if we could render at any resolution, in any window,
with any dynamic overlay controls, rendering it fullscreen with generic
controls is better than nothing.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Giuseppe D'Angelo
2014-11-17 16:48:05 UTC
Permalink
Il 17/11/2014 17:43, Thiago Macieira ha scritto:
> No, I don't think there's any need to render in a smaller frame except for
> specialised applications like the video editor that you mentioned. Those
> specialised applications that do video as their main functionality will not
> use the generic multimedia framework from the OS anyway.

Why specialized applications? Think of any simple video player with a
small preview that you may want to click on to bring it fullscreen...

--
Giuseppe D'Angelo | ***@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
Thiago Macieira
2014-11-17 16:56:48 UTC
Permalink
On Monday 17 November 2014 17:48:05 Giuseppe D'Angelo wrote:
> Il 17/11/2014 17:43, Thiago Macieira ha scritto:
> > No, I don't think there's any need to render in a smaller frame except for
> > specialised applications like the video editor that you mentioned. Those
> > specialised applications that do video as their main functionality will
> > not
> > use the generic multimedia framework from the OS anyway.
>
> Why specialized applications? Think of any simple video player with a
> small preview that you may want to click on to bring it fullscreen...

It would be nice, but a fullscreen is better than the current state.

My point is that those non-specialised applications can work with a fullscreen
without loss of functionality.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Gianluca
2014-11-17 16:49:37 UTC
Permalink
Il giorno 17/nov/2014, alle ore 17:43, Thiago Macieira <***@intel.com> ha scritto:

> On Monday 17 November 2014 09:43:33 André Somers wrote:
>> Thiago Macieira schreef op 17-11-2014 01:48:
>>> Why do you want to render video non-fullscreen anyway on a device with
>>> a small screen? Once the user clicks the play button, go to full
>>> screen with rotation support.
>>
>> What a short-sighted comment. I really respect you, but this comment
>> really misses the mark I think. Not every iOS device is a phone, and
>> even these can get rather large these days.
>
> Unless it's a 23" screen or larger, it's still small. Render the video full
> screen.

That’s your opinion … and I’m sure I'm not the only in disagree with you !

>
>> And don't you need to render controls?
>
> Yes, but I imagine that the video player has those controls already.

Can you explain this ? Maybe I’m stupid, but if I have some Qt Quick Item for play/pause button and close button, when the video start playing it goes full-screen and nothing behind it can be seen … so, there is not way to show controls.
What you mean video player has those control already !?! Where they are ?!?!


>
>> You don't think rendering video's embedded in a larger
>> application is ever needed in for example a simple video editor (for
>> which a device like the iPad Air 2 is perfectly suitable in terms of
>> processing power)?
>
> No, I don't think there's any need to render in a smaller frame except for
> specialised applications like the video editor that you mentioned. Those
> specialised applications that do video as their main functionality will not
> use the generic multimedia framework from the OS anyway.
>
>> IMHO, it is not up for framework developers to decide that user won't
>> need this kind of capability. It does need to be there, so application
>> developers can be creative in how they use video playback.
>
> While it would be nice if we could render at any resolution, in any window,
> with any dynamic overlay controls, rendering it fullscreen with generic
> controls is better than nothing.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Thiago Macieira
2014-11-17 16:57:34 UTC
Permalink
On Monday 17 November 2014 17:49:37 Gianluca wrote:
> >> And don't you need to render controls?
> >
> >
> >
> > Yes, but I imagine that the video player has those controls already.
>
> Can you explain this ? Maybe I’m stupid, but if I have some Qt Quick Item
> for play/pause button and close button, when the video start playing it
> goes full-screen and nothing behind it can be seen … so, there is not way
> to show controls. What you mean video player has those control already !?!
> Where they are ?!?!

The fullscreen video player that got launched has controls to play, pause,
seek, etc.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Gianluca
2014-11-17 17:11:59 UTC
Permalink
Il giorno 17/nov/2014, alle ore 17:57, Thiago Macieira <***@intel.com> ha scritto:

> On Monday 17 November 2014 17:49:37 Gianluca wrote:
>>>> And don't you need to render controls?
>>>
>>>
>>>
>>> Yes, but I imagine that the video player has those controls already.
>>
>> Can you explain this ? Maybe I’m stupid, but if I have some Qt Quick Item
>> for play/pause button and close button, when the video start playing it
>> goes full-screen and nothing behind it can be seen … so, there is not way
>> to show controls. What you mean video player has those control already !?!
>> Where they are ?!?!
>
> The fullscreen video player that got launched has controls to play, pause,
> seek, etc.

Qt Quick 2 VideoOutput does not have any controls. I’m sure, I’ve never seen such controls appear automatically on iOS neither on Android neither on Mac neither on Windows ! (Did not try on other platforms).

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Thiago Macieira
2014-11-17 17:15:22 UTC
Permalink
On Monday 17 November 2014 18:11:59 Gianluca wrote:
> > The fullscreen video player that got launched has controls to play,
> > pause,
> > seek, etc.
>
> Qt Quick 2 VideoOutput does not have any controls. I’m sure, I’ve never seen
> such controls appear automatically on iOS neither on Android neither on Mac
> neither on Windows ! (Did not try on other platforms).

It sounds to me that a full-fledged and controllable video player should have
options to configure what buttons to show and callbacks to decide what to do.
If the standard widget doesn't have it, maybe we can build it by ourselves and
provide it as a controllable QML element.

So you won't be able to draw your own elements and you won't be able to draw
besides the video player, but this is better than not playing anything at all.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Gianluca
2014-11-17 17:26:25 UTC
Permalink
Il giorno 17/nov/2014, alle ore 18:15, Thiago Macieira <***@intel.com> ha scritto:

> On Monday 17 November 2014 18:11:59 Gianluca wrote:
>>> The fullscreen video player that got launched has controls to play,
>>> pause,
>>> seek, etc.
>>
>> Qt Quick 2 VideoOutput does not have any controls. I’m sure, I’ve never seen
>> such controls appear automatically on iOS neither on Android neither on Mac
>> neither on Windows ! (Did not try on other platforms).
>
> It sounds to me that a full-fledged and controllable video player should have
> options to configure what buttons to show and callbacks to decide what to do.
> If the standard widget doesn't have it, maybe we can build it by ourselves and
> provide it as a controllable QML element.
>
> So you won't be able to draw your own elements and you won't be able to draw
> besides the video player, but this is better than not playing anything at all.

Yes, it’s sound a great idea. But I don’t know where to start for doing it :-)

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Kevin Kofler
2014-11-17 01:55:33 UTC
Permalink
Nichols Andy wrote:
> Phonon is only somewhat actively developed, as I counted about 15 real
> commits in the phonon/master and 30 real commits the the
> phonon-gstreamer/master repository this year (commits that weren’t merges
> or version bumps). By comparison QtMultimedia received this year around
> 150 commits from Christian and Yoann alone, with over 40 additional unique
> contributors with at least one patch this year. Sure we have a much large
> scope in having to support so many platforms, but that is not
> insignificant.

Yet Phonon officially supports GStreamer 1 now, QtMultimedia still doesn't.
These are the kinds of things we notice as GNU/Linux distributors, not
whether some developer adds some new feature to the legacy GStreamer 0.10
backend.

Kevin Kofler
Thiago Macieira
2014-11-17 04:16:14 UTC
Permalink
On Monday 17 November 2014 02:55:33 Kevin Kofler wrote:
> Yet Phonon officially supports GStreamer 1 now, QtMultimedia still doesn't.
> These are the kinds of things we notice as GNU/Linux distributors, not
> whether some developer adds some new feature to the legacy GStreamer 0.10
> backend.

Which just goes to show how misguided the distributions are under that
philosophy that usually comes from the GNOME world. Developers don't care
about having the latest version, they care about getting work done. Updating
just because the library is newer and cleaner is not enough; they need to get
something in return.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Rex Dieter
2014-11-17 06:37:20 UTC
Permalink
Thiago Macieira wrote:

> On Monday 17 November 2014 02:55:33 Kevin Kofler wrote:
>> Yet Phonon officially supports GStreamer 1 now, QtMultimedia still
>> doesn't. These are the kinds of things we notice as GNU/Linux
>> distributors, not whether some developer adds some new feature to the
>> legacy GStreamer 0.10 backend.
>
> Which just goes to show how misguided the distributions are under that
> philosophy that usually comes from the GNOME world. Developers don't care
> about having the latest version, they care about getting work done.
> Updating just because the library is newer and cleaner is not enough; they
> need to get something in return.

In fairness in this context, gst-0.10 is no longer supported (by gstreamer
upstream developers), whereas gst-1 is.

-- Rex
Thiago Macieira
2014-11-17 16:49:21 UTC
Permalink
On Monday 17 November 2014 00:37:20 Rex Dieter wrote:
> Thiago Macieira wrote:
> > On Monday 17 November 2014 02:55:33 Kevin Kofler wrote:
> >> Yet Phonon officially supports GStreamer 1 now, QtMultimedia still
> >> doesn't. These are the kinds of things we notice as GNU/Linux
> >> distributors, not whether some developer adds some new feature to the
> >> legacy GStreamer 0.10 backend.
> >
> > Which just goes to show how misguided the distributions are under that
> > philosophy that usually comes from the GNOME world. Developers don't care
> > about having the latest version, they care about getting work done.
> > Updating just because the library is newer and cleaner is not enough; they
> > need to get something in return.
>
> In fairness in this context, gst-0.10 is no longer supported (by gstreamer
> upstream developers), whereas gst-1 is.

I understand, but that only supports my point. So it wasn't the distros that
were shortsighted, the upstream developers were.

By the way, I read somewhere that some distros are considering not shipping
Qt 4 as early as their next releases. I also think that's shortsighted. Keep
it in your repos all the way into 2017...
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Kevin Kofler
2014-11-17 19:00:23 UTC
Permalink
Thiago Macieira wrote:
> > > Developers don't care about having the latest version, they care about
> > > getting work done.
[snip]
> I understand, but that only supports my point. So it wasn't the distros
> that were shortsighted, the upstream developers were.

But users do care about everything using the latest GStreamer, because it
means that they don't have to install 2 different versions of the codec
plugins and that they benefit from the improvements in codec support in the
maintained GStreamer branch. Not shipping GStreamer 0.10 by default (while
still having it available in the online repository) also saves a non-
negligible amount of space on our live images.

Plus, in the GStreamer case, there's also the problem that several things
drag in GStreamer indirectly through, e.g., QtWebKit or Phonon (the latter
also being dragged in by some KDE libraries/frameworks), and then if
QtMultimedia uses a different version, we get symbol conflicts and crashes.
(And it wouldn't be fair to blame GStreamer for that because Qt does not
support this situation either and will also crash if you link different
major versions into the same program.)

The latest versions of some GStreamer-using libraries (Phonon, kde-telepathy
and many of the non-Qt libraries) already only support GStreamer 1, which in
turn forces us to build some other libraries against GStreamer 1 (e.g.
QtWebKit), so we effectively cannot fully support a GStreamer-0.10
QtMultimedia on Fedora anymore. (Using QtWebKit and QtMultimedia together
will crash your application if QtMultimedia uses GStreamer 0.10.) We will
probably be shipping the experimental GStreamer 1 patches, and I'm even
considering backporting them to the Qt 4 version of QtMultimedia.

> By the way, I read somewhere that some distros are considering not
> shipping Qt 4 as early as their next releases. I also think that's
> shortsighted. Keep it in your repos all the way into 2017...

Fedora will not do that. I also consider that a major disservice to those
distros' users. We still ship even Qt 3 (of course only in the online
repository) in Fedora. GStreamer 0.10 is also still available, but there are
practical issues with things using the old version, as explained above. So
we really want everything ported to the latest version as soon as possible.

Kevin Kofler
Thiago Macieira
2014-11-17 19:10:40 UTC
Permalink
On Monday 17 November 2014 20:00:23 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > > > Developers don't care about having the latest version, they care about
> > > > getting work done.
>
> [snip]
>
> > I understand, but that only supports my point. So it wasn't the distros
> > that were shortsighted, the upstream developers were.
>
> But users do care about everything using the latest GStreamer, because it
> means that they don't have to install 2 different versions of the codec
> plugins and that they benefit from the improvements in codec support in the
> maintained GStreamer branch. Not shipping GStreamer 0.10 by default (while
> still having it available in the online repository) also saves a non-
> negligible amount of space on our live images.

I understand that. But applications and frameworks can't switch to a new
version of GStreamer overnight. Think of how long GStreamer 0.10 has been in
existence.

You should also understand that porting code from one version of a dependent
library to another is low-priority work if it already works with the old
version. Not only that, it's high risk, so the port needs to be done
carefully. I'd much rather people kept 0.10 working and in good state than
rush to 1.0 and introduce bugs and regressions due to incomplete porting.

> Plus, in the GStreamer case, there's also the problem that several things
> drag in GStreamer indirectly through, e.g., QtWebKit or Phonon (the latter
> also being dragged in by some KDE libraries/frameworks), and then if
> QtMultimedia uses a different version, we get symbol conflicts and crashes.
> (And it wouldn't be fair to blame GStreamer for that because Qt does not
> support this situation either and will also crash if you link different
> major versions into the same program.)

QtWebKit is under our control, so we should be able to control whether it
links to the same version or a different one.

Someone else loading a different version is out of our scope. It's like loading
Qt4 libraries, we can't do anything about it.

> > By the way, I read somewhere that some distros are considering not
> > shipping Qt 4 as early as their next releases. I also think that's
> > shortsighted. Keep it in your repos all the way into 2017...
>
> Fedora will not do that. I also consider that a major disservice to those
> distros' users. We still ship even Qt 3 (of course only in the online
> repository) in Fedora. GStreamer 0.10 is also still available, but there are
> practical issues with things using the old version, as explained above. So
> we really want everything ported to the latest version as soon as possible.

Thanks, Kevin.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Kevin Kofler
2014-11-17 19:31:33 UTC
Permalink
Thiago Macieira wrote:
> QtWebKit is under our control, so we should be able to control whether it
> links to the same version or a different one.

But if the choice is between having everything that links both QtWebKit and
Phonon (i.e. large parts of KDE) crash or having everything that links both
QtWebKit and QtMultimedia (nothing that we ship in Fedora right now, as far
as I can tell) crash, the choice for us as distributors is easily made. (The
actual situation is slightly more complicated because all the involved
libraries have a version for Qt 4 and one for Qt 5, but I kept it simple to
explain the issue.)

And what we ship as distributors is not really under your control. (Sure,
you could remove GStreamer 1 support from QtWebKit if you really want to
force the choice, but then we'd likely just readd it with a patch.)

Kevin Kofler
Kevin Kofler
2014-11-17 19:59:54 UTC
Permalink
Oh, and I forgot:

Thiago Macieira wrote:
> I understand that. But applications and frameworks can't switch to a new
> version of GStreamer overnight. Think of how long GStreamer 0.10 has been
> in existence.

We are not asking anybody to switch "overnight". GStreamer 1 has been out
for over 2 YEARS! (1.0.0 was released on September 24, 2012.) We are now
finally ready to switch the whole Qt/KDE stack to GStreamer 1 in the
upcoming Fedora 21 (i.e. over 2 years later), and QtMultimedia is the only
missing piece. We won't be waiting for it (considering that hardly anything
in Fedora even used QtMultimedia at all and that e.g. Phonon now supports
ONLY GStreamer 1 in its latest release).

Kevin Kofler
Thiago Macieira
2014-11-17 21:16:36 UTC
Permalink
On Monday 17 November 2014 20:59:54 Kevin Kofler wrote:
> Oh, and I forgot:
>
> Thiago Macieira wrote:
> > I understand that. But applications and frameworks can't switch to a new
> > version of GStreamer overnight. Think of how long GStreamer 0.10 has been
> > in existence.
>
> We are not asking anybody to switch "overnight". GStreamer 1 has been out
> for over 2 YEARS! (1.0.0 was released on September 24, 2012.) We are now
> finally ready to switch the whole Qt/KDE stack to GStreamer 1 in the
> upcoming Fedora 21 (i.e. over 2 years later), and QtMultimedia is the only
> missing piece. We won't be waiting for it (considering that hardly anything
> in Fedora even used QtMultimedia at all and that e.g. Phonon now supports
> ONLY GStreamer 1 in its latest release).

Right, so it's not 2 years, but it's still rather quickly. A transition of
this magnitude should be allowed to happen progressively for several years.
Qt 4's own transition should take 5+ years. Just remember that the Qt 3
transition took that long and it was much less complex than 4.

Also mind you that many of the board manufacturers providing plugins for
hardware acceleration and even MP3 support may not support GStreamer 1.0 yet.
Dropping support for GStreamer 0.10 right now is a short-sighted decision for
any framework.

So while I agree we should add support for 1.0 whenever resources become
available, dropping 0.10 to make it happen is not a good idea. And again, it
depends on whether board manufacturers are shipping 1.0 plugins or not.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Allan Sandfeld Jensen
2014-11-18 08:43:53 UTC
Permalink
On Monday 17 November 2014, Thiago Macieira wrote:
> QtWebKit is under our control, so we should be able to control whether it
> links to the same version or a different one.
>
QtWebKit builds with both 0.10 and 1.x, but prefers 1.x if dev files for both
are present.

Btw. I hope we merge the gstreamer-1.0 branch of qtmultimedia to dev soon. It
seems to work, but it would be great to have in branch as long as possible to
people have a chance of catching breakage.

`Allan
Dominik Holland
2014-11-18 08:48:16 UTC
Permalink
On 11/18/2014 09:43 AM, Allan Sandfeld Jensen wrote:
> On Monday 17 November 2014, Thiago Macieira wrote:
>> QtWebKit is under our control, so we should be able to control whether it
>> links to the same version or a different one.
>>
> QtWebKit builds with both 0.10 and 1.x, but prefers 1.x if dev files for both
> are present.
>
> Btw. I hope we merge the gstreamer-1.0 branch of qtmultimedia to dev soon. It
> seems to work, but it would be great to have in branch as long as possible to
> people have a chance of catching breakage.

As QtMutlimedia is built using plugins, couldn't we support both version
for the next couple of years ?
I know it's a burden to maintain, but it would be great if you have the
chance to use the gst-0.1 plugin if needed.

Especially for embedded boards where the most hardware accelerated
gstreamer plugins are still provided for gst-0.1 only

Dominik
Lopes Yoann
2014-11-18 11:31:36 UTC
Permalink
?The gst-0.10 backend is not going away, we'll still have it along gst-1.0. It was decided to do a soft release for the gst-1.0 port. In Qt 5.5, gst-0.10 will still be used by default, Qt will have to be configured with some option to enable gst-1.0. It will then become the default backend in Qt 5.6 and gst-0.10 will be optional. That way, we'll avoid potential regressions for the majority of people.


I'll merge the gstreamer-1.0 branch to dev sometime this week. I'm still doing some testing.


--

Yoann

?
Timo Jyrinki
2014-11-24 07:38:17 UTC
Permalink
2014-11-17 18:49 GMT+02:00 Thiago Macieira <***@intel.com>:
> By the way, I read somewhere that some distros are considering not shipping
> Qt 4 as early as their next releases. I also think that's shortsighted. Keep
> it in your repos all the way into 2017...

Debian plans to not have Qt 4 after Debian 8.0 [1]. But that means
~2017 indeed for stable release users, the removal itself happening
during 2015-2016 in the development version. The main reason is that
Qt 4 upstream support officially ends, and Debian needs to support
Jessie's Qt4 for critical/security bug fixes at least until 2018, or
even 2020 if the LTS effort continues.

[1] http://perezmeyer.blogspot.fi/2014/11/early-announce-qt4-removal-in-jessie1.html

-Timo
Thiago Macieira
2014-11-24 17:10:59 UTC
Permalink
On Monday 24 November 2014 09:38:17 Timo Jyrinki wrote:
> 2014-11-17 18:49 GMT+02:00 Thiago Macieira <***@intel.com>:
> > By the way, I read somewhere that some distros are considering not
> > shipping
> > Qt 4 as early as their next releases. I also think that's shortsighted.
> > Keep it in your repos all the way into 2017...
>
> Debian plans to not have Qt 4 after Debian 8.0 [1]. But that means
> ~2017 indeed for stable release users, the removal itself happening
> during 2015-2016 in the development version. The main reason is that
> Qt 4 upstream support officially ends, and Debian needs to support
> Jessie's Qt4 for critical/security bug fixes at least until 2018, or
> even 2020 if the LTS effort continues.

When did Debian remove Qt3?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Timo Jyrinki
2014-11-25 10:22:32 UTC
Permalink
2014-11-24 19:10 GMT+02:00 Thiago Macieira <***@intel.com>:
> When did Debian remove Qt3?

It seems only in 2012... Maybe the pkg-kde's Qt4 -> Qt5 plan is too
optimistic, but the ease of porting might result in Debian archive
void of Qt4-only packages surprisingly soon. Most proprietary Qt
software tends to ship the Qt version they need with them so it should
be the packages in archives that matter to users.

2014-11-25 3:44 GMT+02:00 Kevin Kofler <***@chello.at>:
> Red Hat will probably support Qt 4 in RHEL with security fixes for
> longer than that.

Resources like that are always nice, I didn't know Red Hat fully
supports Qt. Jessie+1 would need to be supported until ca. 2022.

-Timo
Kevin Kofler
2014-11-25 01:44:35 UTC
Permalink
Timo Jyrinki wrote:
> Debian plans to not have Qt 4 after Debian 8.0 [1]. But that means
> ~2017 indeed for stable release users, the removal itself happening
> during 2015-2016 in the development version. The main reason is that
> Qt 4 upstream support officially ends, and Debian needs to support
> Jessie's Qt4 for critical/security bug fixes at least until 2018, or
> even 2020 if the LTS effort continues.

So what? Red Hat will probably support Qt 4 in RHEL with security fixes for
longer than that. At least I (as a community, non-Red-Hat, Fedora packager)
am prepared to also do that work in Fedora. We still ship Qt 3 in Fedora
too.

Kevin Kofler
Lisandro Damián Nicanor Pérez Meyer
2014-11-30 00:31:12 UTC
Permalink
On Tuesday 25 November 2014 02:44:35 Kevin Kofler wrote:
> Timo Jyrinki wrote:
> > Debian plans to not have Qt 4 after Debian 8.0 [1]. But that means
> > ~2017 indeed for stable release users, the removal itself happening
> > during 2015-2016 in the development version. The main reason is that
> > Qt 4 upstream support officially ends, and Debian needs to support
> > Jessie's Qt4 for critical/security bug fixes at least until 2018, or
> > even 2020 if the LTS effort continues.
>
> So what? Red Hat will probably support Qt 4 in RHEL with security fixes for
> longer than that. At least I (as a community, non-Red-Hat, Fedora packager)
> am prepared to also do that work in Fedora. We still ship Qt 3 in Fedora
> too.

I'm really glad you have the time for Fedora. Sadly we don't have people with
the time and will to do it. Maybe if you have some more spare time... ;)

--
Quote me as saying I was mis-quoted.
-- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Lisandro Damián Nicanor Pérez Meyer
2014-11-30 00:28:59 UTC
Permalink
On Monday 24 November 2014 09:38:17 Timo Jyrinki wrote:
> 2014-11-17 18:49 GMT+02:00 Thiago Macieira <***@intel.com>:
> > By the way, I read somewhere that some distros are considering not
> > shipping
> > Qt 4 as early as their next releases. I also think that's shortsighted.
> > Keep it in your repos all the way into 2017...
>
> Debian plans to not have Qt 4 after Debian 8.0 [1]. But that means
> ~2017 indeed for stable release users, the removal itself happening
> during 2015-2016 in the development version. The main reason is that
> Qt 4 upstream support officially ends, and Debian needs to support
> Jessie's Qt4 for critical/security bug fixes at least until 2018, or
> even 2020 if the LTS effort continues.

Correct, the main reason here is stable. If we keep Qt4 for Stretch it means
we will need to support it until ~2020. Considering out current manpower
that's simply impossible.

Of course, if someone wants to step up to support it all the way until 2020 we
might reconsider it.

And yes, as Timo said, the easy of porting helps here.

On the other hand, when we removed Qt3 we only had 13 packages that where not
ported.



--
Alas, I am dying beyond my means.
Oscar Wilde, as he sipped champagne on his deathbed

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Bruno Coudoin
2014-11-16 20:43:03 UTC
Permalink
Le 08/11/2014 16:00, Massimo Callegari a écrit :
> 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.
>
Hi,

I started developing an educational application in QML in January and I
agree with you, Qt Multimedia is by far the weakest part of Qt Quick.
Even if we stick for now to basic feature like playing a wav or ogg
audio file, it is not well supported equally on all platforms. However
in our case we saw some improvements over times especially on Android
and Linux.

For now our main issue is the inability to play an audio file from a qrc
on MacOSX as tracked by this bug:
https://bugreports.qt-project.org/browse/QTBUG-36175

Regards,

Bruno.
Massimo Callegari
2015-07-04 16:36:35 UTC
Permalink
Hi everyone,
I'm afraid I need to raise this 8-months topic back again, and I have no
more words to describe the frustration QtMultimedia is giving me.
So this time I come up with a video clip I've taken:
https://www.youtube.com/watch?v=GE98h_HHuAk

I've built Qt 5.5.0 for the Raspberry Pi 2, with gstreamer-1.0 support,
and installed the GST OMX plugin, for hardware decoding.
Ran the player example on EGLFS and that's the result: omxplayer works
like a charm and QtMultimedia doesn't.
Attached the player example log with GST_DEBUG="omx:4" on.
It shows that QtMultimedia is actually using gstreamer + OMX.

I don't understand if things are tested before declaring them "supported".
I quote: " A lot of work has also gone into Qt Multimedia. On Linux, we
have now added gstreamer 1.0 support and lots of bugs have been fixed
for the other platforms."

Like this supreme demonstration of how unprofessionally bugs are
treated: https://bugreports.qt.io/browse/QTBUG-42034 ? (see the history)

I suspect, instead, the Qt Company has received money for a project
needing the camera input support,
so "the lot of work" is that all the manpower (1 dev ? 2 devs ?) have
gone into that.

If you're not willing to listen to the Qt community, then don't even
talk about a community.
Say instead "we do what we need, like it or not"

So the question is, when QtMultimedia can start to be fixed seriously ?

Regards,
Massimo


Il 08/11/2014 16:00, Massimo Callegari ha scritto:
> 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"
>
>
Thiago Macieira
2015-07-04 16:45:15 UTC
Permalink
On Saturday 04 July 2015 18:36:35 Massimo Callegari wrote:
> I've built Qt 5.5.0 for the Raspberry Pi 2, with gstreamer-1.0 support,
> and installed the GST OMX plugin, for hardware decoding.
> Ran the player example on EGLFS and that's the result: omxplayer works
> like a charm and QtMultimedia doesn't.
> Attached the player example log with GST_DEBUG="omx:4" on.
> It shows that QtMultimedia is actually using gstreamer + OMX.
>
> I don't understand if things are tested before declaring them "supported".
> I quote: " A lot of work has also gone into Qt Multimedia. On Linux, we
> have now added gstreamer 1.0 support and lots of bugs have been fixed
> for the other platforms."

Can you try the same on a platform that has open source drivers? The problem
may not be in QtMultimedia at all, but with those OMX plugins or the
proprietary OpenMAX backend.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Massimo Callegari
2015-07-04 20:19:28 UTC
Permalink
On Saturday 04 July 2015 18:36:35 Massimo Callegari wrote:
> I've built Qt 5.5.0 for the Raspberry Pi 2, with gstreamer-1.0 support,
> and installed the GST OMX plugin, for hardware decoding.
> Ran the player example on EGLFS and that's the result: omxplayer works
>> like a charm and QtMultimedia doesn't.
>> Attached the player example log with GST_DEBUG="omx:4" on.
>> It shows that QtMultimedia is actually using gstreamer + OMX.
>>
>> I don't understand if things are tested before declaring them "supported".
>> I quote: " A lot of work has also gone into Qt Multimedia. On Linux, we
>> have now added gstreamer 1.0 support and lots of bugs have been fixed
>> for the other platforms."

>Can you try the same on a platform that has open source drivers? The problem
>may not be in QtMultimedia at all, but with those OMX plugins or the
>proprietary OpenMAX backend.

Thiago, as I said the reference player, omxplayer (on which Kodi is based), works perfectly with the same files, and it's an open source project:https://github.com/huceke/omxplayer
I believe it proves that gstreamer + omx is working properly.
Thiago Macieira
2015-07-05 06:00:49 UTC
Permalink
On Saturday 04 July 2015 20:19:28 Massimo Callegari wrote:
> >Can you try the same on a platform that has open source drivers? The
> >problem may not be in QtMultimedia at all, but with those OMX plugins or
> >the proprietary OpenMAX backend.
>
> Thiago, as I said the reference player, omxplayer (on which Kodi is based),
> works perfectly with the same files, and it's an open source
> project:https://github.com/huceke/omxplayer I believe it proves that
> gstreamer + omx is working properly.

That doesn't mean it's working perfectly. This example working means this
example works, that's all.

Anyway, can you at least try raw gstreamer, like gst-launch?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Massimo Callegari
2015-07-05 08:09:05 UTC
Permalink
> That doesn't mean it's working perfectly. This example working means this 
> example works, that's all.

> Anyway, can you at least try raw gstreamer, like gst-launch?

Yes I ***@raspberrypi ~ $ gst-launch-1.0 filesrc location=sintel-1280-surround.mp4 ! qtdemux name=demuxer \ demuxer. ! queue ! faad ! alsasink \ demuxer. ! queue max-size-bytes=10000000 ! h264parse ! omxh264dec ! queue max-size-buffers=4 ! "video/x-raw, format=(string)I420" ! eglglessink
Setting pipeline to PAUSED ...Pipeline is PREROLLING ...Got context from element 'eglglessink0': gst.egl.EGLDisplay=context, display=(GstEGLDisplay)NULL;Pipeline is PREROLLED ...Setting pipeline to PLAYING ...New clock: GstAudioSinkClock
Works like a charm. No frame drops, no interruptions, no AV out of sync.I had to add that weird I420 format otherwise the video was flipped upside down.
For the sake of completeness I add also the OMX codecs inspection:***@raspberrypi ~ $ gst-inspect-1.0 | grep omxomx:  omxmpeg2videodec: OpenMAX MPEG2 Video Decoderomx:  omxmpeg4videodec: OpenMAX MPEG4 Video Decoderomx:  omxh263dec: OpenMAX H.263 Video Decoderomx:  omxh264dec: OpenMAX H.264 Video Decoderomx:  omxtheoradec: OpenMAX Theora Video Decoderomx:  omxvp8dec: OpenMAX VP8 Video Decoderomx:  omxmjpegdec: OpenMAX MJPEG Video Decoderomx:  omxvc1dec: OpenMAX WMV Video Decoderomx:  omxh264enc: OpenMAX H.264 Video Encoder
And also the packages installed in the distro:
***@raspberrypi ~ $ dpkg -l | grep gstii  gir1.2-gst-plugins-base-1.0           1.2.0-1co1rpi3                        armhf        Description: GObject introspection data for the GStreamer Plugins Base libraryii  gir1.2-gstreamer-1.0                  1.2.0-1rpi3                             armhf        Description: GObject introspection data for the GStreamer libraryii  gstreamer0.10-gconf:armhf             0.10.31-3+nmu1                          armhf        GStreamer plugin for getting the sink/source information from GConfii  gstreamer0.10-plugins-base:armhf      0.10.36-1.1                             armhf        GStreamer plugins from the "base" setii  gstreamer0.10-plugins-good:armhf      0.10.31-3+nmu1                          armhf        GStreamer plugins from the "good" setii  gstreamer0.10-plugins-ugly:armhf      0.10.19-2                               armhf        GStreamer plugins from the "ugly" setii  gstreamer0.10-x:armhf                 0.10.36-1.1                             armhf        GStreamer plugins for X11 and Pangoii  gstreamer1.0-alsa:armhf               1.2.0-1co1rpi3                          armhf        GStreamer plugin for ALSAii  gstreamer1.0-libav:armhf              1.2.0-1co2rpi1rpi3                      armhf        libav plugin for GStreamerii  gstreamer1.0-omx                      1.0.0.1-0+rpi13rpi2                     armhf        GStreamer OpenMAX pluginsii  gstreamer1.0-plugins-bad:armhf        1.2.1-0+rpi1rpi3                        armhf        GStreamer plugins from the "bad" setii  gstreamer1.0-plugins-base:armhf       1.2.0-1co1rpi3                          armhf        GStreamer plugins from the "base" setii  gstreamer1.0-plugins-good:armhf       1.2.0-1co6rpi3                          armhf        GStreamer plugins from the "good" setii  gstreamer1.0-tools                    1.2.0-1rpi3                             armhf        Tools for use with GStreamerii  gstreamer1.0-x:armhf                  1.2.0-1co1rpi3                          armhf        GStreamer plugins for X11 and Pangorc  libclutter-gst-1.0-0:armhf            1.5.4-1+build0                          armhf        Open GL based interactive canvas library GStreamer elementsii  libgstreamer-plugins-bad1.0-0:armhf   1.2.1-0+rpi1rpi3                        armhf        GStreamer development files for libraries from the "bad" setii  libgstreamer-plugins-base0.10-0:armhf 0.10.36-1.1                             armhf        GStreamer libraries from the "base" setii  libgstreamer-plugins-base1.0-0:armhf  1.2.0-1co1rpi3                          armhf        GStreamer libraries from the "base" setii  libgstreamer-plugins-base1.0-dev      1.2.0-1co1rpi3                          armhf        GStreamer development files for libraries from the "base" setii  libgstreamer0.10-0:armhf              0.10.36-1.2                             armhf        Core GStreamer libraries and elementsii  libgstreamer1.0-0:armhf               1.2.0-1rpi3                             armhf        Core GStreamer libraries and elementsii  libgstreamer1.0-dev                   1.2.0-1rpi3                             armhf        GStreamer core development files
Massimo Callegari
2015-07-05 08:11:38 UTC
Permalink
Sorry, ignore the previous. Stupid formatting :(

> That doesn't mean it's working perfectly. This example working means this
> example works, that's all.

> Anyway, can you at least try raw gstreamer, like gst-launch?


Yes I can.

***@raspberrypi ~ $ gst-launch-1.0 filesrc location=sintel-1280-surround.mp4 ! qtdemux name=demuxer \ demuxer. ! queue ! faad ! alsasink \ demuxer. ! queue max-size-bytes=10000000 ! h264parse ! omxh264dec ! queue max-size-buffers=4 ! "video/x-raw, format=(string)I420" ! eglglessink

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'eglglessink0': gst.egl.EGLDisplay=context, display=(GstEGLDisplay)NULL;
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock


Works like a charm. No frame drops, no interruptions, no AV out of sync.
I had to add that weird I420 format otherwise the video was flipped upside down.


For the sake of completeness I add also the OMX codecs inspection:
***@raspberrypi ~ $ gst-inspect-1.0 | grep omx
omx: omxmpeg2videodec: OpenMAX MPEG2 Video Decoder
omx: omxmpeg4videodec: OpenMAX MPEG4 Video Decoder
omx: omxh263dec: OpenMAX H.263 Video Decoder
omx: omxh264dec: OpenMAX H.264 Video Decoder
omx: omxtheoradec: OpenMAX Theora Video Decoder
omx: omxvp8dec: OpenMAX VP8 Video Decoder
omx: omxmjpegdec: OpenMAX MJPEG Video Decoder
omx: omxvc1dec: OpenMAX WMV Video Decoder
omx: omxh264enc: OpenMAX H.264 Video Encoder

And also the packages installed in the distro:


***@raspberrypi ~ $ dpkg -l | grep gst
ii gir1.2-gst-plugins-base-1.0 1.2.0-1co1rpi3 armhf Description: GObject introspection data for the GStreamer Plugins Base library
ii gir1.2-gstreamer-1.0 1.2.0-1rpi3 armhf Description: GObject introspection data for the GStreamer library
ii gstreamer0.10-gconf:armhf 0.10.31-3+nmu1 armhf GStreamer plugin for getting the sink/source information from GConf
ii gstreamer0.10-plugins-base:armhf 0.10.36-1.1 armhf GStreamer plugins from the "base" set
ii gstreamer0.10-plugins-good:armhf 0.10.31-3+nmu1 armhf GStreamer plugins from the "good" set
ii gstreamer0.10-plugins-ugly:armhf 0.10.19-2 armhf GStreamer plugins from the "ugly" set
ii gstreamer0.10-x:armhf 0.10.36-1.1 armhf GStreamer plugins for X11 and Pango
ii gstreamer1.0-alsa:armhf 1.2.0-1co1rpi3 armhf GStreamer plugin for ALSA
ii gstreamer1.0-libav:armhf 1.2.0-1co2rpi1rpi3 armhf libav plugin for GStreamer
ii gstreamer1.0-omx 1.0.0.1-0+rpi13rpi2 armhf GStreamer OpenMAX plugins
ii gstreamer1.0-plugins-bad:armhf 1.2.1-0+rpi1rpi3 armhf GStreamer plugins from the "bad" set
ii gstreamer1.0-plugins-base:armhf 1.2.0-1co1rpi3 armhf GStreamer plugins from the "base" set
ii gstreamer1.0-plugins-good:armhf 1.2.0-1co6rpi3 armhf GStreamer plugins from the "good" set
ii gstreamer1.0-tools 1.2.0-1rpi3 armhf Tools for use with GStreamer
ii gstreamer1.0-x:armhf 1.2.0-1co1rpi3 armhf GStreamer plugins for X11 and Pango
rc libclutter-gst-1.0-0:armhf 1.5.4-1+build0 armhf Open GL based interactive canvas library GStreamer elements
ii libgstreamer-plugins-bad1.0-0:armhf 1.2.1-0+rpi1rpi3 armhf GStreamer development files for libraries from the "bad" set
ii libgstreamer-plugins-base0.10-0:armhf 0.10.36-1.1 armhf GStreamer libraries from the "base" set
ii libgstreamer-plugins-base1.0-0:armhf 1.2.0-1co1rpi3 armhf GStreamer libraries from the "base" set
ii libgstreamer-plugins-base1.0-dev 1.2.0-1co1rpi3 armhf GStreamer development files for libraries from the "base" set
ii libgstreamer0.10-0:armhf 0.10.36-1.2 armhf Core GStreamer libraries and elements
ii libgstreamer1.0-0:armhf 1.2.0-1rpi3 armhf Core GStreamer libraries and elements
ii libgstreamer1.0-dev 1.2.0-1rpi3 armhf GStreamer core development files
Massimo Callegari
2015-07-05 11:06:33 UTC
Permalink
Update.
The message "No m_videoSink available!" is clearly an alarm that something is going wrong.

So I checked the code and...surprise !
The EGLFS platform is not even considered ! Well done !

Code extract from qtmultimedia/src/gsttols/qgstreamervideowindow.cpp line 59:

if (elementName) {
m_videoSink = gst_element_factory_make(elementName, NULL);
} else if (QGuiApplication::platformName().compare(QLatin1String("xcb"), Qt::CaseInsensitive) == 0) {
// We need a native X window handle to be able to use xvimagesink.
// Bail out if Qt is not using xcb (the control will then be ignored by the plugin)
m_videoSink = gst_element_factory_make("xvimagesink", NULL);
}

if (m_videoSink) {
...
}
else
qDebug() << "No m_videoSink available!";


I tried to add something like:
else if (QGuiApplication::platformName().compare(QLatin1String("eglfs"), Qt::CaseInsensitive) == 0) {
m_videoSink = gst_element_factory_make("eglglessink", NULL);
}

The error message disappears, but I get a black fullscreen result.
I don't even see the player example UI.
I guess it depends on the compositing between the gst window and the main eglfs window.
So I haven't gone any further.
I can tweak the player example to accept a filename from the command line and play it automatically.
At least I can check if the video playback is OK in this way.

This is extremely sad. I thought the gst 1.0 support came especially for the raspberry Pi, since the little dude cannot afford software decoding (thus the need of OMX -> thus the need of gst 1.0)

I can try the same tests on Xorg, but it's out of my scope.
I don't want to use Xorg but instead I will use Wayland.
Massimo Callegari
2015-07-05 12:16:48 UTC
Permalink
Update #2 (sorry for spamming)

I patched qgstreamervideowindow.cpp and qgstreamervideowidget.cpp to support the linuxfb platform.
It kinda works !!

Screenshot here: http://pasteboard.co/1JlYRT9l.jpg

Videos can be played hardware decoded with audio and video until the end.
It's definitely using the OMX plugin.

Some other issues raised like these:
***@raspberrypi ~ $ ./player -platform linuxfb sintel-1280-surround.mp4

(player:2857): GLib-GObject-WARNING **: g_object_set_valist: object class 'GstFBDEVSink' has no property named 'force-aspect-ratio'
This plugin does not support setParent!

(player:2857): GLib-GObject-WARNING **: g_object_set_valist: object class 'GstFBDEVSink' has no property named 'force-aspect-ratio'


My goal is to play fullscreen, so probably I can manage to find a way on the Linux FB.

In any case the issue is: QtMultimedia gstreamer-1.0 support has been written around XCB.
No eglfs, linuxfb, directfb, etc.

Someone should have written it in https://wiki.qt.io/New_Features_in_Qt_5.5



----- Messaggio originale -----
Da: Massimo Callegari <***@yahoo.it>
A: "***@qt-project.org" <***@qt-project.org>
Cc:
Inviato: Domenica 5 Luglio 2015 13:06
Oggetto: [Development] The dark side of QtMultimedia - strikes back



Update.
The message "No m_videoSink available!" is clearly an alarm that something is going wrong.

So I checked the code and...surprise !
The EGLFS platform is not even considered ! Well done !

Code extract from qtmultimedia/src/gsttols/qgstreamervideowindow.cpp line 59:

if (elementName) {
m_videoSink = gst_element_factory_make(elementName, NULL);
} else if (QGuiApplication::platformName().compare(QLatin1String("xcb"), Qt::CaseInsensitive) == 0) {
// We need a native X window handle to be able to use xvimagesink.
// Bail out if Qt is not using xcb (the control will then be ignored by the plugin)
m_videoSink = gst_element_factory_make("xvimagesink", NULL);
}

if (m_videoSink) {
...
}
else
qDebug() << "No m_videoSink available!";


I tried to add something like:
else if (QGuiApplication::platformName().compare(QLatin1String("eglfs"), Qt::CaseInsensitive) == 0) {
m_videoSink = gst_element_factory_make("eglglessink", NULL);
}

The error message disappears, but I get a black fullscreen result.
I don't even see the player example UI.
I guess it depends on the compositing between the gst window and the main eglfs window.
So I haven't gone any further.
I can tweak the player example to accept a filename from the command line and play it automatically.
At least I can check if the video playback is OK in this way.

This is extremely sad. I thought the gst 1.0 support came especially for the raspberry Pi, since the little dude cannot afford software decoding (thus the need of OMX -> thus the need of gst 1.0)

I can try the same tests on Xorg, but it's out of my scope.
I don't want to use Xorg but instead I will use Wayland.
Sune Vuorela
2015-07-05 16:07:59 UTC
Permalink
On 2015-07-05, Massimo Callegari <***@yahoo.it> wrote:
> Update #2 (sorry for spamming)
>
> I patched qgstreamervideowindow.cpp and qgstreamervideowidget.cpp to support the linuxfb platform.
> It kinda works !!
>
> Screenshot here: http://pasteboard.co/1JlYRT9l.jpg
>
> Videos can be played hardware decoded with audio and video until the end.
> It's definitely using the OMX plugin.

Nice. Did you submit your work to gerrit ?

/Sune
Hausmann Simon
2015-07-05 06:33:38 UTC
Permalink
Hi,

Could you elaborate how omxplayer uses gstreamer?

I only see openmax il usage, but perhaps I am missing something.

Thanks,
Simon

From: Massimo Callegari
Sent: Saturday, July 4, 2015 22:19
To: ***@qt-project.org
Reply To: Massimo Callegari
Cc: ***@intel.com
Subject: [Development] The dark side of QtMultimedia - strikes back




On Saturday 04 July 2015 18:36:35 Massimo Callegari wrote:
> I've built Qt 5.5.0 for the Raspberry Pi 2, with gstreamer-1.0 support,
> and installed the GST OMX plugin, for hardware decoding.
> Ran the player example on EGLFS and that's the result: omxplayer works
>> like a charm and QtMultimedia doesn't.
>> Attached the player example log with GST_DEBUG="omx:4" on.
>> It shows that QtMultimedia is actually using gstreamer + OMX.
>>
>> I don't understand if things are tested before declaring them "supported".
>> I quote: " A lot of work has also gone into Qt Multimedia. On Linux, we
>> have now added gstreamer 1.0 support and lots of bugs have been fixed
>> for the other platforms."

>Can you try the same on a platform that has open source drivers? The problem
>may not be in QtMultimedia at all, but with those OMX plugins or the
>proprietary OpenMAX backend.



Thiago, as I said the reference player, omxplayer (on which Kodi is based), works perfectly with the same files, and it's an open source project:

https://github.com/huceke/omxplayer

I believe it proves that gstreamer + omx is working properly.
Massimo Callegari
2015-07-05 08:18:51 UTC
Permalink
________________________________
Da: Hausmann Simon <***@theqtcompany.com>
A: Massimo Callegari <***@yahoo.it>; "***@qt-project.org" <***@qt-project.org>
Inviato: Domenica 5 Luglio 2015 8:33
Oggetto: Re: [Development] The dark side of QtMultimedia - strikes back


> Hi,

> Could you elaborate how omxplayer uses gstreamer?

> I only see openmax il usage, but perhaps I am missing something.

> Thanks,
> Simon


Simon, you are right. omxplayer goes straight into ffmpeg and omx. My fault here.

Anyway see my reply to Thiago with the gst-launch test.

The chain GST-1.0->OMX does indeed work as expected on the Pi.

Thanks,
Massimo
Massimo Callegari
2015-07-05 19:44:37 UTC
Permalink
>On 2015-07-05, Massimo Callegari <massimocallegari at yahoo.it> wrote:
>> Update #2 (sorry for spamming)
>>
>> I patched qgstreamervideowindow.cpp and qgstreamervideowidget.cpp to support the linuxfb platform.
>> It kinda works !!
>>
>> Screenshot here: http://pasteboard.co/1JlYRT9l.jpg
>>
>> Videos can be played hardware decoded with audio and video until the end.
>> It's definitely using the OMX plugin.

>Nice. Did you submit your work to gerrit ?

Nope, because all I've got are 8 lines of code that don't even work properly.
The eglfs change segfaults when playing. The linuxfb change shows the video as you can see in the picture I've taken.

A complete integration and test of the different platforms is needed before reaching Gerrit.

Anyway, here you go. You can simply copy the lines manually and recompile.


--- qgstreamervideowindow-ORI.cpp 2015-07-05 21:37:20.843145434 +0200
+++ qgstreamervideowindow.cpp 2015-07-05 13:49:54.784794043 +0200
@@ -62,6 +62,10 @@
// We need a native X window handle to be able to use xvimagesink.
// Bail out if Qt is not using xcb (the control will then be ignored by the plugin)
m_videoSink = gst_element_factory_make("xvimagesink", NULL);
+ } else if (QGuiApplication::platformName().compare(QLatin1String("eglfs"), Qt::CaseInsensitive) == 0) {
+ m_videoSink = gst_element_factory_make("eglglessink", NULL);
+ } else if (QGuiApplication::platformName().compare(QLatin1String("linuxfb"), Qt::CaseInsensitive) == 0) {
+ m_videoSink = gst_element_factory_make("fbdevsink", NULL);
}

if (m_videoSink) {
--- qgstreamervideowidget-ORI.cpp 2015-07-05 21:37:37.391433363 +0200
+++ qgstreamervideowidget.cpp 2015-07-05 13:50:35.273375245 +0200
@@ -102,6 +102,10 @@
// Bail out if Qt is not using xcb (the control will then be ignored by the plugin)
if (QGuiApplication::platformName().compare(QLatin1String("xcb"), Qt::CaseInsensitive) == 0)
m_videoSink = gst_element_factory_make ("xvimagesink", NULL);
+ else if (QGuiApplication::platformName().compare(QLatin1String("eglfs"), Qt::CaseInsensitive) == 0)
+ m_videoSink = gst_element_factory_make ("eglglessink", NULL);
+ else if (QGuiApplication::platformName().compare(QLatin1String("linuxfb"), Qt::CaseInsensitive) == 0)
+ m_videoSink = gst_element_factory_make("fbdevsink", NULL);

if (m_videoSink) {
// Check if the xv sink is usable
Continue reading on narkive:
Loading...