[Suggestion] add ffmpeg as part of the runtime

[baptisterajaut]

Greetings.

Not a bug report, just a small suggestion.
A small game (Your only move is hustle) has a mod (YomiRecord) that requires access to a binary form of ffmpeg to create video replay files. As the runtime sandboxes the binaries, if a game requires one that is not included in the runtime, you just can't access it (as a workaround, the legacy runtime 1.0 seems not to have this feature)
I know the native steam replay feature may be the reason ffmpeg is not included (anymore? yomirecord broke quite recently) but it could be useful still for such a common program to be included in the standard runtime.

Feel free to lock this issue if it doesn't fit the tracker CoC or if you deem this suggestion is invalid.

Have a wonderful day.

EDIT : wait, am i even at the right place to ask this? Or shall i go to the steamos gitlab?

[smcv]

This is the correct place to suggest additions to the runtime.

However, I don't think we are likely to add the ffmpeg(1) executable or the avcodec/ffmpeg libraries to the runtime, because we can't know which audio/video codecs would be needed by any given game (or mod), and indiscriminately adding all of them would take up a lot of space, likely add a lot of security vulnerabilities, and require a lot of legal checking.

It is technically possible for a game or mod to launch arbitrary commands outside the Steam Linux Runtime container, with no compatibility guarantees at all (this is very much on an "if it works, it works" basis). #717 has some more details of the mechanism that the mod author could use to run ffmpeg on the user's system outside the container, if they want to support that use-case. However, if they do this, they need to be aware that Steam will no longer be giving them any help with portability.

as a workaround, the legacy runtime 1.0 seems not to have this feature

Yes, the purpose of the legacy runtime is that it keeps your host OS's libraries and executables available and maybe-working (not necessarily fully working, but no worse than they were before the introduction of the container runtime!) so that if a game or a mod makes assumptions about the facilities that the OS will provide, there is a possibility that it might work.

As the runtime sandboxes the binaries

A correction to this: when we say sandboxing we usually mean a security boundary, but the Steam Linux Runtime container is a compatibility mechanism, not a security mechanism. The game is still just as trusted as it always was, it can "escape" and run code outside the container if it wants to, and that is not considered to be a security vulnerability.