Remove QtMultimedia as playback option

Authored by astippich on Aug 22 2019, 8:58 PM.



All new features like radio support are only
implemented for VLC. QtMultimedia is not
tested anymore so remove it to lower

Diff Detail

R255 Elisa
No Linters Available
No Unit Test Coverage
Build Status
Buildable 15509
Build 15527: arc lint + arc unit
astippich requested review of this revision.Aug 22 2019, 8:58 PM
astippich created this revision.
astippich updated this revision to Diff 64360.Aug 22 2019, 9:03 PM
  • cleanup unused AudioRole

That is probably not an option for at least Fedora. Please can you check with the distributions?
As far as radio support is concerned, I think that it would be better to fix it.

astippich added a comment.EditedAug 22 2019, 9:32 PM

There are RPM Fusion packages available, but from a quick glimpse I could not find packages directly from Fedora.
Debian(based), Arch and openSUSE etc seem to have packages available.

Actually, radio is working, don't know what I've done before.

Still, IMHO it is pretty bad if there are two very distinct code path within Elisa. We do not regularly test both. Power management was also only implement first for Elisa and missing for some time for QtMultimedia.

pino added a subscriber: pino.Aug 23 2019, 4:04 AM

(Not arguing for or against this patch, just providing more info on the Fedora situation.)

Because of patented codecs, ffmpeg is not available in the main Fedora repository, and thus everything that requires it is not. However, ffmpeg is in RPMfusion, and so is VLC (and phonon-vlc too).
Right now Elisa is in Fedora [1], using QtMultimedia only; requiring VLC means it would be removed from there, and maybe maintained on RPMfusion (it depends on the current maintainer).


pino removed a subscriber: pino.Aug 23 2019, 4:04 AM
astippich abandoned this revision.Fri, Aug 23, 8:00 PM

I see... I still think the situation is not optimal, but dropping Fedora is also not a good option.

I see... I still think the situation is not optimal, but dropping Fedora is also not a good option.

Maybe we could transform those into real plug-in that could be selected at runtime. It would make it easier to test both implementations.

Does this makes sense?

That is a good idea, or at least basing the two implementation on a common base class. I'm currently planning to do other things first though, and I don't know when and if I have time to look into it