【问题标题】:Legal issues in shipping apps based on Electron framework (libffmpeg)基于 Electron 框架 (libffmpeg) 发布应用程序的法律问题
【发布时间】:2021-06-02 05:27:33
【问题描述】:

我们正在 electron v 12.0.7 上构建和部署基于桌面的应用程序。它将是一个(免费)商业软件,部署到全球约 2-3M 用户。 最近我们的法律团队询问了与 Chromium 捆绑的专有编解码器,我认为确认这一点的最佳方式是联系这里。

所以,以下是我需要帮助的具体事项:

  1. 我们是否使用专有编解码器运送 chromium?如果是,那么在与 electron v 12.0.7 捆绑的 Chromium 中默认提供的可能有争议的编解码器是什么?

  2. 有没有关于电子团队如何构建 chromium 的文档(带有哪些标志)?

  3. 默认的 libffmpeg.dylib/dll 是否与 electron 构建 ffmpeg 捆绑在一起,支持 H.264 和 MP3 编解码器等内容?

  4. 我注意到每个电子版本都有可用的 libffmpeg 二进制文件,例如https://github.com/electron/electron/releases/download/v12.0.7/ffmpeg-v12.0.7-darwin-arm64.zip 。这个二进制文件的目的是什么?

任何帮助将不胜感激。

【问题讨论】:

标签: ffmpeg electron codec


【解决方案1】:

好的,需要一段时间才能全面了解所有信息。 我从https://github.com/electron/libchromiumcontent/issues/174#issuecomment-184187254 开始,最后在电子的不和谐服务器上与电子团队的多个人交谈。我在这里整理我的发现,以便为某人节省一些时间。 这是我发现的。任何更正/编辑都非常受欢迎,因此此处提供的信息是正确的。

  1. 我们是否使用专有编解码器运送 chromium? 如果是,那么在与 electron v 12.0.7 捆绑的 Chromium 中默认提供的可能有争议的编解码器是什么?

是的。至少在 OSX 上,默认情况下随电子提供的 libffmpeg.dylib 包含用于 AAC 和 H264 的导出符号(用于专有解码器)。 因此,它们仍属于非免版税软件领域。我认为如果您打算将您的应用程序商业化(使用默认电子 + libffmpeg.dylib),这里需要法律建议 p>

例如可以使用以下命令查看从 dylib 导出的解码器列表:

nm -gU /Applications/{your-app-name}.app/Contents/Frameworks/Electron\ Framework.framework/Versions/A/Libraries/libffmpeg.dylib | grep 'decoder'

我编写了一个简单的 python 脚本来查看任何基于电子的应用程序,并打印 libffmpeg 中可用的解码器列表(捆绑在基于电子的应用程序中)。 我的脚本的示例输出:(我的应用是使用 electron v 12.0.7 构建的)

从 libffmpeg.dylib 中可用/导出的解码器:['aac', 'aac-latm', 'flac','h264','libopus','mp3','pcm-alaw','pcm-f32le', 'pcm-mulaw','pcm-s16be','pcm-s16le','pcm-s24be','pcm-s24le', 'pcm-s32le'、'pcm-u8'、'theora'、'vorbis'、'vp3'、'vp8']

因此,我们基于电子的应用程序默认有 aach264 解码器(非免版税软件)。据我所知,这些可能会导致可能的专利侵权问题。

2。 是否有关于电子团队如何构建 chromium 的文档(带有哪些标志)?

我找不到任何确凿的文件,但 https://github.com/electron/electron/blob/58c58c46c4e03c996983a0c71163e1a5efed12fa/build/args/all.gn 暗示默认情况下,在 electron 的构建中,private_codecs 设置为 true

3。 默认的 libffmpeg.dylib/dll 是否与电子构建 ffmpeg 捆绑在一起,支持 H.264 和 MP3 编解码器等内容?

看起来确实是这样(基于上述)

4. 我注意到每个电子版本都有可用的 libffmpeg 二进制文件,例如https://github.com/electron/electron/releases/download/v12.0.7/ffmpeg-v12.0.7-darwin-arm64.zip 。这个二进制文件的目的是什么?

如果您关心发布免版税二进制文件而不是处理专利问题,那么这可能是您应该使用的(除非您选择通过自己调整 gn args 来构建整个电子)。

对这些 ffmpeg.dylib 的快速检查表明不存在 AAC 和 H264 解码器(或者至少它没有为它们导出符号)。所以它让我相信这些自定义版本的 dylib 是由电子团队构建的,牢记这一点。使用相同的脚本,这是自定义版本的 libffmpeg 中可用的解码器列表的输出

从 libffmpeg.dylib 可用/导出的解码器:['flac', 'libopus', 'mp3','pcm-alaw','pcm-f32le','pcm-mulaw','pcm-s16be','pcm-s16le', 'pcm-s24be','pcm-s24le','pcm-s32le','pcm-u8','theora','vorbis', 'vp3', 'vp8']

所以这就是 dylib 两个版本之间的区别(左边一个是从电子站点下载的,右边一个是电子默认提供的) 看来这个问题已经被确定了,我们有一个电子打包器插件,可以为您完成所有繁重的工作:https://github.com/MarshallOfSound/electron-packager-plugin-non-proprietary-codecs-ffmpeg

由于我们不使用电子打包器(但电子生成器),我不得不求助于将替换 libffmpeg 的逻辑放入 afterPackHook :https://www.electron.build/configuration/configuration#afterpack

需要记住的重要步骤是:此替换需要在我们对整个应用进行代码签名之前完成(否则会破坏代码签名的完整性)。

希望它可以帮助其他人解决同样的问题。 干杯!

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-03-29
    • 2012-09-14
    • 2011-03-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-04-01
    相关资源
    最近更新 更多