Mirrors/rffmpeg
1
0
Fork 0
mirror of https://github.com/joshuaboniface/rffmpeg.git synced 2026-07-18 00:45:53 +00:00
Code Issues Projects Releases Packages Wiki Activity

Add link to NVidia docs

Browse source
This commit is contained in:
Joshua M. Boniface 2022-06-11 16:03:00 -04:00
parent ab99b29356
commit bae7b2f01f
1 changed files with 1 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -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.