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

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.

Got feedback from Ciaran, 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/

As far as AAC goes fedora uses following: https://src.fedoraproject.org/rpms/fdk-aac-free

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.

We could use licensing@cisco.com from https://www.cisco.com/c/en/us/about/contact-cisco.html/software-licensing-support

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.

The Cisco repo in Fedora is enabled by default: https://src.fedoraproject.org/rpms/fedora-repos/blob/rawhide/f/fedora-cisco-openh264.repo

We've done it since Fedora 33: https://src.fedoraproject.org/rpms/fedora-repos/c/7f050d24a624be37efd8e21f12087d27a77695bc

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.

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.

OpenH264 package submitted for openSUSE Factory: https://build.opensuse.org/request/show/946170

Per the Board meeting minutes released today, marking this feature as Board-Accepted.

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

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.

Tracking question regardingb publishing at https://github.com/cisco/openh264/issues/3480

I forgot to put this in here, but thanks to Bjørn Lie, we have GStreamer plugins for this ready to go for the Cisco published repo.

Sources for the OpenH264 packages are available here: https://build.opensuse.org/project/show/multimedia:libs:cisco-openh264

I have credible reports that chromium 98.0.4758.102 built with proprietary_codecs=true and rtc_use_pipewire=true against a system libopenh264 via adding a symlink to the unbundle gn file works fine (replacing of the vendored one), however it won't start if that .so file isn't around. If there was a patch that made chromium build against just the openh264 headers and loads the so only when it is available then that might work for openSUSE. (Without this even with the codecs around chromium will not offer h264 for webrtc, as that implementation is independent of the one for normal video decoding.)

If there was a patch that made chromium build against just the openh264 headers and loads the so only when it is available

That is dynamic linking via libdl's dlopen function. Would be really useful. Then we could declare libopenh264 as recommended, so it gets pulled in, when available.

Summary of a call on the topic of openh264 distribution for openSUSE

We've just had a meeting with Cisco regarding providing easy access to the openh264 codec to the openSUSE users.

The outcome is that Cisco will help us with the redistribution side by utilizing the ciscobinary.openh264.org host. There seems to be more space for collaboration that could lead to the usage of OBS in some more of Cisco's open-source-related processes. OBS seems to be a good fit as we can cover builds for multiple distributions and image builds. Big thanks to Neal Gompa for raising this topic. Neal was really shining on the call :-)

We seem to found the right people for the job, and the rest of the discussion will happen in the email thread with selected people.

Big thanks to all the attendes and especially to Cisco for being supportive.

Related issues
https://github.com/cisco/openh264/issues/3480
https://code.opensuse.org/leap/features/issue/22

Document used for introduction to the issue
https://etherpad.opensuse.org/p/openh264-summary

The next meeting with Cisco is on Thursday 17th Nov 2022 17:00 UTC. Neal and I will be present. Bernhard, Fabian, Stefan W, Dominique were invited as well.

Let me start the new year by sharing some great news! Cisco engineering published openh264 binaries for openSUSE on the Cisco infra.

Big thanks to Cisco for making this happen!

I've captured the content of the currently extracted zip archive, together with our agreement at
https://en.opensuse.org/OpenH264

The next step is to set up a repository, including the gpg key that will point to the rpms hosted on Cisco infra (or involve redirecting). This could be hopefully achieved in the next few days.

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... :-)

My fullest agreement.
And even if nobody wants to hear that here.
The processes at Packman are not worse or better than at suse itself. Multimedia projects only cause problems with openSUSE/SUSE. With Packman they work.
And besides, you are now making yourself dependent on cisco. A company that is constantly criticized. Whose products have constantly some security gaps.
And if I understand it correctly, they are once again panting after Red Hat.
Grow up for once. And do your own thing.
A duplicate is eventually gone and only the original survives.
This seems to me another step in the wrong direction at Suse. Not the first.
Please consider the above sentences without anger, but openly and honestly.

See https://github.com/openSUSE/opi/pull/119 for discussion about how opi should deal with this.

Marking as resolved.

skelcd-control-openSUSE Changes landed in Leap:15.5 and openSUSE Tumbleweed
openSUSE-repos-{Tumbleweed,MicroOS,Leap} packages have openh264 in there as well.

New installations of Tumbleweed and Leap 15.5 will get it by default. Rest users are adviced to either add repository manually (https://en.opensuse.org/OpenH264#Installation) or install openSUSE-repos which will add your repo automatically after refresh (can be forced by zypper ref -s)