How to package telegram-desktop with dependency of openh264?
Hello all, I am the maintainer of telegram-desktop package in OSS and I am seeking advice about how to update the package as its recent change is blocked by openSUSE's openh264 license issue. 2 weeks ago, tg_owt made a commit to use system-level openh264 instead of bundled version (https://github.com/desktop-app/tg_owt/commit/204f1abf4646a77b5c6903bd2cc8501...), this will break the build of telegram-desktop on b.o.o obs because on opensuse openh264 is distributed separately at https://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/x86_64/. I can think of the following options: 1. patch tg_owt to make openh264 an optional dependency instead of hard dependency, but this will probably be rejected by upsteam and we have to maintain our own patchset. 2. bundle openh264 library with tg_owt and maintain the previous behavior, but I am not sure if this will violate the rules of OBS 3. delete telegram-desktop package on b.o.o (https://build.opensuse.org/package/show/server:messaging/telegram-desktop) and ask users to use the flatpak version 4. if there is a plan to push openh264 into OSS factory, we can keep telegram-desktop and wait until openh264 is available in OSS factory repo. Please advice on which option we should take, or if you have other opinions. Your advice is much appreciated. Best, Xu Zhao -- Xu Zhao i@xuzhao.net
Hi, Am Donnerstag, 1. August 2024, 15:53:59 MESZ schrieb Xu Zhao:
Hello all,
I am the maintainer of telegram-desktop package in OSS and I am seeking advice about how to update the package as its recent change is blocked by openSUSE's openh264 license issue.
2 weeks ago, tg_owt made a commit to use system-level openh264 instead of bundled version (https://github.com/desktop-app/tg_owt/commit/204f1abf4646a77b5c6903bd2cc8501...), this will break the build of telegram-desktop on b.o.o obs because on opensuse openh264 is distributed separately at https://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/x86_64/.
I can think of the following options: 1. patch tg_owt to make openh264 an optional dependency instead of hard dependency, but this will probably be rejected by upsteam and we have to maintain our own patchset. 2. bundle openh264 library with tg_owt and maintain the previous behavior, but I am not sure if this will violate the rules of OBS 3. delete telegram-desktop package on b.o.o (https://build.opensuse.org/package/show/server:messaging/telegram-desktop) and ask users to use the flatpak version 4. if there is a plan to push openh264 into OSS factory, we can keep telegram-desktop and wait until openh264 is available in OSS factory repo.
There are three options: 1. Make the libopenh264 repo available in OBS (definitely technically possible, but can be a pain) 2. Use dlopen on libopenh264.so.* during runtime. That's what libfreerdp and ffmpeg do: https://github.com/FreeRDP/FreeRDP/blob/master/libfreerdp/codec/h264_openh26... https://build.opensuse.org/projects/openSUSE:Factory/packages/ffmpeg-7/files... 3. Build a fake libopenh264 in OBS that is just enough to build against it, but doesn't actually do encoding/decoding. 2 is already used, so probably the best option. Also something upstreamable. Cheers, Fabian
Please advice on which option we should take, or if you have other opinions. Your advice is much appreciated.
Best, Xu Zhao
-- Xu Zhao i@xuzhao.net
Fabian Vogt <fvogt@suse.de> writes:
Hi,
Am Donnerstag, 1. August 2024, 15:53:59 MESZ schrieb Xu Zhao:
Hello all,
I am the maintainer of telegram-desktop package in OSS and I am seeking advice about how to update the package as its recent change is blocked by openSUSE's openh264 license issue.
2 weeks ago, tg_owt made a commit to use system-level openh264 instead of bundled version (https://github.com/desktop-app/tg_owt/commit/204f1abf4646a77b5c6903bd2cc8501...), this will break the build of telegram-desktop on b.o.o obs because on opensuse openh264 is distributed separately at https://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/x86_64/.
I can think of the following options: 1. patch tg_owt to make openh264 an optional dependency instead of hard dependency, but this will probably be rejected by upsteam and we have to maintain our own patchset. 2. bundle openh264 library with tg_owt and maintain the previous behavior, but I am not sure if this will violate the rules of OBS 3. delete telegram-desktop package on b.o.o (https://build.opensuse.org/package/show/server:messaging/telegram-desktop) and ask users to use the flatpak version 4. if there is a plan to push openh264 into OSS factory, we can keep telegram-desktop and wait until openh264 is available in OSS factory repo.
There are three options:
1. Make the libopenh264 repo available in OBS (definitely technically possible, but can be a pain) 2. Use dlopen on libopenh264.so.* during runtime. That's what libfreerdp and ffmpeg do: https://github.com/FreeRDP/FreeRDP/blob/master/libfreerdp/codec/h264_openh26... https://build.opensuse.org/projects/openSUSE:Factory/packages/ffmpeg-7/files... 3. Build a fake libopenh264 in OBS that is just enough to build against it, but doesn't actually do encoding/decoding.
2 is already used, so probably the best option. Also something upstreamable.
The exact same issue also exits for Electron the recommendation was to add option 2 to it too. It's not so uncommon, especially for cross platform apps.
"Bruno Pitrus" <brunopitrus@hotmail.com> writes:
The exact same issue also exits for Electron Electron maintainer here.
We currently ship four Electron apps (element, bitwarden, vscode, signal). Please tell me what functionality in any of those apps requires openh264.
Any app that wants to play decode videos that use h264 such as Teams (there's an inofficial app wrapping the webapp into electron). If someone tries to play a video in Signal or Element the issue should be similar.
If someone tries to play a video in Signal or Element the issue should be similar. you can point electron to a video available on the web with a <video> tag. Please show me a video that does not play.
[I'm claiming that Electron does not use openh264 but ffmpeg for *playing videos*, and enabling openh264 has zero relevance to any of this.]
participants (4)
-
Björn Bidar
-
Bruno Pitrus
-
Fabian Vogt
-
Xu Zhao