From bae7b2f01fe5390052dbb00d4a13ac1eb8ec335f Mon Sep 17 00:00:00 2001 From: "Joshua M. Boniface" Date: Sat, 11 Jun 2022 16:03:00 -0400 Subject: [PATCH] Add link to NVidia docs --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index a4d6fda..dbafdbc 100644 --- a/README.md +++ b/README.md @@ -113,6 +113,6 @@ If you are using NVEnv/NVDec, it's probably a good idea to symlink the `.nv` fol Be sure to adjust these paths to match your Jellyfin setup. The name of the target doesn't matter too much, as long as `.nv` inside the homedir is symlinked to it and it is owned by the `jellyfin` service user. -This is because some functions of FFMpeg's NVEnc/NVDec stack - specifically the `scale_cuda` and `tonemap_cuda` filters - leverage this directory to cache their JIT codes, and this can result in very slow startup times for FFMpeg on the remote side due to NFS locking issues. +This is because some functions of FFMpeg's NVEnc/NVDec stack - specifically the `scale_cuda` and `tonemap_cuda` filters - leverage this directory to cache their JIT codes, and this can result in very slow startup times for FFMpeg on the remote side due to NFS locking issues. See https://developer.nvidia.com/blog/cuda-pro-tip-understand-fat-binaries-jit-caching/ for further information. Alternatively, you can simplify the NFS mount to only export and mount the directories that are actually required to pass transcoded data back (at the least, `transcodes` and `data/subtitles`) over NFS, and leave the rest of the directory local to the remote host, but this likely isn't required with this workaround and makes setup more complex. Feel free to experiment and find the best solution for your setup.