The right ffmpeg path?

[martadinata666]

Describe the bug Building failed due ffmpeg and ffprobe

To Reproduce Steps to reproduce the behavior:

1. cargo run --features vaapi --release
2. Err

#19 821.3 2022-06-25T06:19:35.857136Z ERROR dim: 72: Could not find: /dim/target/release/utils/ffmpeg
#19 821.3 2022-06-25T06:19:35.857169Z ERROR dim: 72: Could not find: /dim/target/release/utils/ffprobe

4. ffmpeg and ffprobe linking successfully at utils/
5. So the question is where is the right path? Relative to clone directory.

utils/ffmpeg

static find from root direcory /dim

/dim/target/release/utils/ffmpeg

Expected behavior Build correctly

Additional context Will cargo run --release will asking ffmpeg? And will it build with vaapi support?

[martadinata666]

Im looking the dockerfile should be cargo build --features vaapi --release. Read the readme again, yeah it RUNNING from source not BUILDING

[mental32]

This is still a bug.

There was a change that made the ffmpeg paths based relative on the current exe path, makes it super awkward to spin up a local instance.

[martadinata666]

TBF for more info. I build via container, so the clone path is at /dim. Linking ffmpeg and ffprobe to utils/ that mean /dim/utils. When i accidentally using cargo run it looking at /dim/target/release/utils/ffmpeg. But if i link it to target/release/utils/ffmpeg it will run correctly, so either documentation miss or something not intended.

[mental32]

In your case there's less of an issue because you're building the container and it works there, I'm running with cargo run directly so I've actually hit this wall before and I have found it incredibly annoying.

Unless the linking step happens in automation i.e. in a build script somewhere I'm considering it an issue because:

• build directories like those are temporary, they will get cleaned out at some point and you do have to keep re-linking.
• if ffmpeg and ffprobe are exposed as hooks so that any Dim admin can supply them then it's a huge PITA when the paths are going to be relative to the executables current path.
• if Dim isn't containerized and installed to /usr/bin/dim then these paths would have to be in /usr/bin/utils/ffmpeg and that's a lot messier than having a tmpdir made for it /tmp/dim/utils/ .

However if utils/ffmpeg and utils/ffprobe are considered private implementation details and there's no need for manually linking them to those paths then it's fine, but I still think it's weird to use the current exe path as a base.

cc @vgarleanu

[martadinata666]

I see, fair point. i think dim need look at ffmpeg system installation then go to it relative path. like /usr/local/bin/ffmpeg -> /usr/bin/ffmpeg -> dim utils/ path.

[vgarleanu]

The main issue is that when deploying dim in release form we need to access ffmpeg relative to the binary. In debug mode this is disabled for obvious reasons. We also cant just use the global ffmpeg binary for now as we dont have any form of feature detection.

We ship our own ffmpeg binaries because we are sure theyre all gonna be the same version and have the same features enabled. Sometimes distros ship old, buggy ffmpeg binaries that would make debugging playback issues very painful.

I think what we could do here is have a runtime arg that we can use to specify where ffmpeg is located, but it would default either to the location of the cargo manifest or the location of the binary depending on if we run in debug or release.

[vgarleanu]

Honestly I wish we could get rid of our own ffmpeg binaries. I'm also not even sure if the binaries we ship are compliant with their licenses. We include some proprietary modules like the nvenc ones, and theyre not even fully statically linked. It'd be ideal if we could get rid of our binaries but in return add some form of version and feature detection to nightfall and be able at runtime to bail if we are missing some stuff, or selectively disable various playback profiles while letting server admins know.

I.e if NVENC is not enabled in ffmpeg, but we can clearly see a nvidia gpu attached to the system (+ maybe correct drivers loaded) we can tell the admin that the globally available ffmpeg binary is either too old and needs to be updated or hasn't been compiled with nvenc support enabled.

[mental32]

We ship our own ffmpeg binaries because we are sure theyre all gonna be the same version and have the same features enabled. Sometimes distros ship old, buggy ffmpeg binaries that would make debugging playback issues very painful.

Why not have our ffmpeg/ffprobe binaries be present within the system binaries dim-ffmpeg and dim-ffprobe instead of doing a relative-path search for them in utils/ffmpeg?

[vgarleanu]

I'd prefer to avoid touching /usr/bin and /bin. Dim should be installed to /opt/dim just like in the docker container, and plus again windows doesnt really have the equivalent of /usr/bin. In window's case we'd need to find them relative to the binary anyway. Having just one method of looking up ffmpeg would make things a lot simpler.

[mental32]

So let's make it relative to the current working directory like it was before

[martadinata666]

Honestly I wish we could get rid of our own ffmpeg binaries. I'm also not even sure if the binaries we ship are compliant with their licenses. We include some proprietary modules like the nvenc ones, and theyre not even fully statically linked. It'd be ideal if we could get rid of our binaries but in return add some form of version and feature detection to nightfall and be able at runtime to bail if we are missing some stuff, or selectively disable various playback profiles while letting server admins know.

I.e if NVENC is not enabled in ffmpeg, but we can clearly see a nvidia gpu attached to the system (+ maybe correct drivers loaded) we can tell the admin that the globally available ffmpeg binary is either too old and needs to be updated or hasn't been compiled with nvenc support enabled.

about ffmpeg, why we dont use jellyfin-ffmpeg? as it readily available for use and support many platform.

[vgarleanu]

about ffmpeg, why we dont use jellyfin-ffmpeg? as it readily available for use and support many platform.

As far as I remember, they were stuck on a old version of ffmpeg because of some playback issues. This mightve been fixed tho. Iirc their fork has some nice improvements to HW tone mapping that hasn't been merged upstream yet. That said I'm unsure if using their fork would overall be a better idea than using the ffmpeg binaries available on system.

[martadinata666]

Yeah, it just distro ffmpeg just not liking enable hardware acceleration by default, either rebuild ourself or use third party one.