opening any animation generates a $HOME/libopenh264-2.4.1-linux64.7.so file

[ousia]

Describe the bug

On Linux (using this nightly),¹ I generate an empty file.swf and open it with Ruffle to get:

$ touch file.swf && ruffle file.swf 
2024-07-21T09:31:33.929568Z  INFO ruffle_desktop::gui::controller: Using preferred backend Vulkan
2024-07-21T09:31:33.942761Z  INFO ruffle_desktop::gui::controller: Using graphics API vulkan on AMD Radeon R7 M340 (RADV ICELAND) (type: DiscreteGpu)
2024-07-21T09:31:33.952084Z  WARN egui_wgpu::renderer: Detected a linear (sRGBA aware) framebuffer Bgra8UnormSrgb. egui prefers Rgba8Unorm or Bgra8Unorm    
2024-07-21T09:31:33.952737Z  INFO ruffle_desktop::gui::controller: loaded cjk fallback font "NotoSans-Regular"
2024-07-21T09:31:48.073233Z ERROR ruffle_frontend_utils::backends::executor: Async error: Invalid SWF: Couldn't read SWF: failed to fill whole buffer

Besides I have to press Ctrl+C to get the command line back, I always get a file named $HOME/libopenh264-2.4.1-linux64.7.so.

Expected behavior

No file named $HOME/libopenh264-2.4.1-linux64.7.so should be generated.

Content Location

touch file.swf displays the issue (no real content to trigger the issue is needed).

Affected platform

Desktop app

Operating system

Fedora 40 (Linux)

Footnotes

1. I think the version info might be wrong:

   $ ruffle --version
   Ruffle 0.1.0-nightly (1c8e95a061a40ccd4b2fdca30a66eb7cc2fbe12d 2024-07-19)
   

   ↩

[Dinnerbone]

This is somewhat intended right now, we need to download openh264 at runtime to comply with their license, and we use it for video decoding. We do that ahead of opening a SWF because we have no way of blocking a SWF that happens to need it.

There's a preference to disable it, and I believe it downloads the lib to be adjacent to Ruffle - but I may be wrong. I'd of course prefer if we had a better place for it, but...

@torokati44 may be able to chime in with more details too

[ousia]

This is somewhat intended right now, we need to download openh264 at runtime to comply with their license, and we use it for video decoding. We do that ahead of opening a SWF because we have no way of blocking a SWF that happens to need it.

Many thanks for your reply, @Dinnerbone.

I wonder why Ruffle is not able to detect the installed version:

$ rpm -q openh264
openh264-2.4.1-2.fc40.x86_64

There's a preference to disable it, and I believe it downloads the lib to be adjacent to Ruffle - but I may be wrong. I'd of course prefer if we had a better place for it, but...

Place is fine. My Ruffle binary is at $HOME.

I’m not closing the issue yet, since I guess Ruffle should be detecting openh264 installed on the system.

Many thanks for your help again.

[Dinnerbone]

I don't know if we're allowed to.

From the license:

In order for Cisco to be responsible for the MPEG LA licensing royalties for the module, Cisco must provide the packaging and distribution of this code in a binary module format (think of it like a plug-in, but not using the same APIs as existing plugins), in addition to several other constraints.

Cisco is only covering the licensing fees for its own binary module, and products or projects that utilize it must download it at the time the product or project is installed on the user's computer or device. Cisco will not be liable for any licensing fees incurred by other parties.

I suppose that if you've installed it from somewhere, the provider may be liable for those fees, but I'm not sure. Patents are hard. :(

[torokati44]

Thanks Dinnerbone for your replies! <3
Yes, this is completely intended, and yes, it's put next to the ruffle binary.
And yes, you can disable that feature (also required by the license BTW), and then Ruffle won't put it there anymore.

Just curious, does the file installed on your system match exactly with the one downloaded by Ruffle (as in, it has the same checksum)? If not, then honestly, I wouldn't risk loading and running it... Not because it's any more risky (from a security standpoint) than any other system utility/library/driver/etc that we're loading at runtime, but more from an API stability and reproducibility standpoint. Also, yeah, #*@& software patents, I hate that we have to do this this way.
And even if the file on your system does match (I'm fairly sure the distro packages also have to download that binary directly from Cisco at the time of installation, and they can't contain it directly), I don't know how likely it is that of the dozens of Linux distros people use, the same exact version is deployed everywhere at any given moment.

One alternative would be to use hardware decoding (VA-API, Vulkan Video, etc...), but I don't see the benefits to be worth the effort - especially considering the suboptimal likelihood that it will actually work well, or even at all, on any random user's computer.

[ousia]

@Dinnerbone & @torokati44, many thanks for your replies.

I completely disabled the feature.

I’m afraid there is a size mismatch 1.7MB (downloaded file) vs 1.1MB (installed file from OS) (there is a hash mismatch too).

[…] especially considering the suboptimal likelihood that it will actually work well, or even at all, on any random user's computer.

You could say that from almost any feature in a computer (I’d rather say).

Closing the issue myself, since I don’t want to waste any from your time on this (rather patently stupid) issue.

Many thanks for your help and for your work with Ruffle.

[torokati44]

BTW, since #17799, this file may not even be downloaded in the first place (if the correct version is found preinstalled on the system); and since #17803, even if it is, it will be "tucked away" in a hidden directory (most likely $HOME/.cache/ruffle/video/).