#22 Simplify multimedia codec installation
Opened 6 months ago by lkocman. Modified a week ago

This is an action item from Leap 15.3 retrospective. We'd like to investigate a simplification of codec installation for freshly installed systems.

One of the ideas in the past was to use a pointer in the openSUSE Welcome screen.
This request must be explicitly approved by Legal.

We also need to figure out what's the official recommendation for individual codecs.
Then there is also OPI which perhaps deserves bit more advertisment https://etherpad.opensuse.org/p/ReleaseEngineering-Leap-15.3-retro-20200616#L548

Our focus should be on following codecs which are not part of openSUSE:

AAC
h.264

Otherwise we already have following ones
mp3
LDAC
mpeg2

This should be sufficient for a basic multimedia desktop support.


Requested explicit ECO (including legal review) as we need a guidance here.

Metadata Update from @lkocman:
- Custom field SUSE Jira adjusted to https://jira.suse.com/browse/OPENSUSE-46

6 months ago

Metadata Update from @Pharaoh_Atem:
- Issue tagged with: Legal-Accept-Pending

6 months ago

Email sent to Legal on Wed 7th July, and today.

Uploading welcome screen (the place where we could technically add pointer to e.g. packman).

Marking this for Board review, since this involves general policy around what is shippable in openSUSE.

Metadata Update from @Pharaoh_Atem:
- Issue tagged with: Board-Accept-Pending

6 months ago

Got feedback from Ciarran, however he just pointed me to some existing wiki page "How to get codecs". We really intend to have such information as part of first boot experience. I'll get back to legal.

I did involve Dominique and Gerald in the email thread. Hopefully it will start moving forward.

One thing that we should revisit is if we really want to recommend packman or choose another alternative https://en.opensuse.org/Codecs

Problem with packman and openSUSE Leap is always problems during migration/dup. This is something we don't have fully in control.

I did involve Dominique and Gerald in the email thread. Hopefully it will start moving forward.

One thing that we should revisit is if we really want to recommend packman or choose another alternative https://en.opensuse.org/Codecs

Problem with packman and openSUSE Leap is always problems during migration/dup. This is something we don't have fully in control.

Would it be worthwhile to consider either

a) Talking to Packman to get them to comply with our standards/testing/processes so we don't need to be fully in control but can be assured that what they produce is actually viable?

b) Opening a call to the community to build an alternative to Packman, probably smaller in scope (just the Codecs?) that would be more in control/in compliance with our standards/testing/processes?

I did involve Dominique and Gerald in the email thread. Hopefully it will start moving forward.

One thing that we should revisit is if we really want to recommend packman or choose another alternative https://en.opensuse.org/Codecs

Problem with packman and openSUSE Leap is always problems during migration/dup. This is something we don't have fully in control.

Would it be worthwhile to consider either

a) Talking to Packman to get them to comply with our standards/testing/processes so we don't need to be fully in control but can be assured that what they produce is actually viable?

b) Opening a call to the community to build an alternative to Packman, probably smaller in scope (just the Codecs?) that would be more in control/in compliance with our standards/testing/processes?

Personally speaking, I think the latter option is more viable. It is unfortunate that Packman doesn't really enforce the same level of quality that openSUSE itself does.

This is something that on the Fedora-side that RPM Fusion does, and it really makes it more trustworthy and reliable. I want that for openSUSE too.

Artwork concept in progress https://github.com/openSUSE/openSUSE-welcome/issues/22

Legal requires a screenshot of what we intend to display on the welcome dialog.

Lubos to contact packman mailing list, prior considering packman replacement.

@Pharaoh_Atem thinks that we would have to break down the repo into multiple.

Note that any such repo can't include "-freeworld" or similar replacement packages that enable all stripped codecs, because then we can't actually offer it in openSUSE at all without potential legal issues. Stuff to ship needs to get evaluated by the Board and Legal before we can offer them.

I did ask community around packman@links2linux.de to join this ticket and generally participate in the effort.

Just as a remark: Cisco has an arrangement with Fedora for rebuilding and re-distributing h.264 codec. We might want to consider similar approach.

https://koji.fedoraproject.org/koji/packageinfo?packageID=21431
https://codecs.fedoraproject.org/openh264/

Talking to Packman to get them to comply with our standards/testing/processes so we don't need to be fully in control but can be assured that what they produce is actually viable?

Packman is producing viable packages since before anyone in this conversation was part of the openSUSE community. Just sayin... :-)

Opening a call to the community to build an alternative to Packman

Those who do decide...

Reminded packman about this idea.

I had short conversation with Ciaran on both openh264 (in a separate fedora-cisco-openh264 repository) and then about aac being part of fedora based on availability of https://fedoraproject.org/wiki/Licensing/FDK-AAC

Ciaran finds it difficult to believe that codec is part of fedora solely based on the availability of the license file.

fdk-aac-free is a stripped version of fdk-aac, it has problematic code removed in order to make suitable for inclusion. It's not the same as the original fdk-aac library.

We've agreed to initiate email discussion with both parties.

amm-info@iis.fraunhofer.de and Cisco contact is TBD.

You will probably want to loop in Wim Taymans (fdk-aac-free developer) as well. Kalev Lember is the one who works with Cisco for OpenH264 in Fedora.

Fedora is using https://fedoraproject.org/wiki/Changes/Third_Party_Software_Mechanism to mass-enable all 3rd party repositories. This seems to be possible only with DNF backend

Our proposal is to active 3rd party repository (would be opensuse-cisco-openh264) through the welcome screen button as on the attached mockup.

me and @Pharaoh_Atem agreed on it being better being fully written out Enable Third Party repositories as everything else on the welcome screen is in text

Problem with packman and openSUSE Leap is always problems during migration/dup. This is something we don't have fully in control.

Would it be worthwhile to consider either

a) Talking to Packman to get them to comply with our standards/testing/processes so we don't need to be fully in control but can be assured that what they produce is actually viable?

Personal opinion here: we all know the limitations both in hardware and manpower that packman has.

What do you have in mind as testing and processes?

Linking Cisco support case: 692251194

@alois my idea would be some more integration testing. Ensuring rarly availability/installability of the repository with first Beta builds etc.

To my knowledge we've had only -debuginfo rpms for majority of 15.3 Beta phase.

Lubos

Lubos to contact packman mailing list, prior considering packman replacement.

@Pharaoh_Atem thinks that we would have to break down the repo into multiple.

For years the Packman repo has been split into 5 different repos.

Full, Essentials, Extra, Games, Multimedia and a base folder that incloses all of those.

It could be possible to either have all the codecs in Multimedia and use that, or Essentials.

Right now there is a problem with the Leap build of ffmpeg on both the multimedia-lib repo and packman where the hardware encoding compiletime flags are not enabled during the initial compile meaning hardware video encoding is not possible. a report was made on the packman mailing list but seems to have died.

This leads to another issue with packman and there not being a way to easily bug report issues without having to resort to an antiquated system known as a mailing list.

It will be interesting to see how this is resolved

@Mir_ppc I suspect all that boils down to one thing: resources.

Can SUSE/openSUSE supply some without tainting itself legally?

So the idea is that we'd be legally okay. Fraunhofen ACC should be fine to integrated into both Factory and Leap, we did not receive no from the insititute.

And Cisco is still being discussed by our TAM team. They have also regular meetings on Monday, however I did not receive any update yet.

SR for multimedia:libs for fdk-aac-free has been prepared: https://build.opensuse.org/request/show/926104

Note that I don't know what license tag to use. Fedora uses a custom "FDK-AAC" tag here, and notes it accordingly here: https://fedoraproject.org/wiki/Licensing/FDK-AAC

SPDX has yet to recognize this license.

@Mir_ppc I suspect all that boils down to one thing: resources.

Can SUSE/openSUSE supply some without tainting itself legally?

Maybe not openSUSE directly, but we already use https://www.opensuse-community.org/ for some strange things.

The question is: would it make sense to host another bugtracker there?
At the moment, I hope that we might get rid of openSUSE-community.org in the future because everything can be integrated directly in openSUSE... ;-)

As an update for the openh264, I did ask Ciaran to try to reach out to his legal contacts. As we're not getting any clear information from the Cisco side, at least not to my current knowledge.

@Mir_ppc I suspect all that boils down to one thing: resources.

Can SUSE/openSUSE supply some without tainting itself legally?

Maybe not openSUSE directly, but we already use https://www.opensuse-community.org/ for some strange things.

The question is: would it make sense to host another bugtracker there?
At the moment, I hope that we might get rid of openSUSE-community.org in the future because everything can be integrated directly in openSUSE... ;-)

That is a guide on installing the codecs from the Packman repo and libdvdcss2 via CB00f's repo.

There isnt a bug tracker for packman as far as i can find. VLC isnt built for leap, VLC-beta is. The version of VLC in the opensuse main repos doesnt play H264 and h265 videos as well as some other obscure formats that VLC normaly now can play. Whoever packages VLC in the opensuse main repos strips too much out of vlc to make it useful.

libdvdcss2 has been a personal repo of cb00f since i started with the opensuse project as a daily drivers back in 2005. You'd want to talk to them about that. It is very unlikely that libdvdcss2 will pass legal due to it being illegal in some territories.

fdk-aac-free is now present in openSUSE:Factory: https://build.opensuse.org/package/show/openSUSE:Factory/fdk-aac-free

@lkocman Can you get the SLE folks to pull it into SLE 15.4 and flip the toggles to get stuff like PipeWire using this library?

Beside the direct provision of codecs there was the idea to enable community repos (like Packman) during installation.
Was that discussed with legal as well?

Beside the direct provision of codecs there was the idea to enable community repos (like Packman) during installation.
Was that discussed with legal as well?

Yeah, we can't do that.

We have received a go for handling openh264 the Fedora way from our CTO Dr. T. Let's proceed

we need to handle the packaging and then thirdparty repo creation
opensuse-leap-cisco-openh264 respectively opensuse-cisco-openh264
This will need to go Factory first.

fdk-aac-free is now present in openSUSE:Factory: https://build.opensuse.org/package/show/openSUSE:Factory/fdk-aac-free

@lkocman Can you get the SLE folks to pull it into SLE 15.4 and flip the toggles to get stuff like PipeWire using this library?

Antonio Larrosa confirmed that he has been working on this part for a while.

Metadata Update from @lkocman:
- Issue untagged with: Legal-Accept-Pending
- Issue tagged with: Legal-Accepted

2 weeks ago

Just to clarify agreeemnt is to rebuild it in OBS and have binary redistributed via a 3rd party Cisco repository. Repo definition would be present on the system (Leap, TW), but would be off by default.

I did ask our Tam to re-communicate this to Cisco.

Metadata Update from @Pharaoh_Atem:
- Issue untagged with: Board-Accept-Pending
- Issue tagged with: Board-Accepted

2 weeks ago

This is also being worked on the SLE side, so marking with SLE and SLE-Accepted tags.

Metadata Update from @Pharaoh_Atem:
- Issue tagged with: SLE, SLE-Accepted

2 weeks ago

We have received a go for handling openh264 the Fedora way from our CTO Dr. T. Let's proceed

we need to handle the packaging and then thirdparty repo creation
opensuse-leap-cisco-openh264 respectively opensuse-cisco-openh264
This will need to go Factory first.

Just to clarify agreeemnt is to rebuild it in OBS and have binary redistributed via a 3rd party Cisco repository. Repo definition would be present on the system (Leap, TW), but would be off by default.

I did ask our Tam to re-communicate this to Cisco.

Reading the liscense on github there is no need to put it on a third party repo like packman. https://github.com/cisco/openh264/blob/master/LICENSE

Putting it on yet another third party repo kinda kill the whole point of having it work out of the box, thus making the user experience far more difficult.

We have received a go for handling openh264 the Fedora way from our CTO Dr. T. Let's proceed

we need to handle the packaging and then thirdparty repo creation
opensuse-leap-cisco-openh264 respectively opensuse-cisco-openh264
This will need to go Factory first.

Just to clarify agreeemnt is to rebuild it in OBS and have binary redistributed via a 3rd party Cisco repository. Repo definition would be present on the system (Leap, TW), but would be off by default.

I did ask our Tam to re-communicate this to Cisco.

Reading the liscense on github there is no need to put it on a third party repo like packman. https://github.com/cisco/openh264/blob/master/LICENSE

Putting it on yet another third party repo kinda kill the whole point of having it work out of the box, thus making the user experience far more difficult.

We have to be put it in a third party repo where the binaries are hosted by Cisco in order to take advantage of Cisco's H.264 patent grant. Otherwise we can't ship it due to software patents on MPEG AVC.

After reading openh264.org i now understand. the binary cannot be hosted.

The one thing to look into is having some sort of package that would add the 3rd party repository and install the required packages. The main thing is to make this more seemless than it is with the codecs from packman.

Another option is to add the cisco repo to the community repository area in Yast's Repository Management for Leap, SLE, and Tumbleweed.

Also adding it as an option during install would be good similar to what Ubuntu does now. Having the MPEG1 Layer 3 and openH264 codec as options during the installation process would make things a lot easier for new uers and less of a headache for those who are more experienced.

MP3 and AAC are going to be baked into Leap 15.4. We'll look into adjustments to get OpenH264 auto-installed once we have the arrangement in place.

Login to comment on this ticket.

Metadata