基本情况：我的硬件是J3455，华擎的那块板子，内存暂时上的4G，硬盘只插了两块sata固态，因为只是测试阶段，原有群晖（j1900）上的一堆服务暂时不敢贸然迁移过来，所以没有给测试机的配置堆得很高。

 

情况说明：我装的是nyanmisaka/jellyfin，中国特供版，以前的黑裙上就一直用的这个，很好用。这次在unraid上第一时间就装了这个docker，而且测试后也能顺利硬解4k h265 sdr的视频，观看体验也没有问题，当时感觉很受鼓舞，心里落下一块石头，就转而测试其他docker的安装情况了。

不过在折腾了其他docker几天后，偶然打开jellyfin硬解同一个4k h265 sdr的视频时，发现声音每隔几秒有卡顿现象，当时一通查资料也没解决，而且也忘记去查日志了，于是想当然的以为重装大法能解决，结果就悲剧了。无论怎么重装，甚至拔下硬盘和U盘，通通格式化再按照当初的步骤重新来一遍，还是无法硬解，一直提示“该客户端与媒体不兼容，服务器未发送兼容的媒体格式”。明明ls /dev/dri也都通过了的。

这次想到了查看日志，发现好像和ffmpeg有关。但是昨晚折腾了一晚还是没能成功，而且我发现jellyfin默认的这个/usr/lib/jellyfin-ffmpeg/ffmpeg路径根本就不存在，命令行里只能看到/usr/lib/为止，所以我也试过手动下载ffmpeg文件，手动创建相应的文件夹，但是照着别人成功的教程一通折腾后还是不行。

 

这里贴上部分日志：

[18:01:42] [INF] [13] Jellyfin.Api.Helpers.TranscodingJobHelper: /usr/lib/jellyfin-ffmpeg/ffmpeg -analyzeduration 200M -probesize 1G -init_hw_device vaapi=va:,kernel_driver=i915,driver=iHD -init_hw_device qsv=qs@va -filter_hw_device qs -hwaccel vaapi -hwaccel_output_format vaapi -autorotate 0 -i file:"/Movie/流浪地球2.2023/流浪地球2.2023.mp4" -autoscale 0 -map_metadata -1 -map_chapters -1 -threads 0 -map 0:0 -map 0:1 -map -0:s -codec:v:0 h264_qsv -preset veryfast -look_ahead 0 -b:v 7015463 -maxrate 7015463 -bufsize 14030926 -profile:v:0 high -level 51 -g:v:0 96 -keyint_min:v:0 96 -vf "setparams=color_primaries=bt709:color_trc=bt709:colorspace=bt709,scale_vaapi=format=nv12:extra_hw_frames=24,hwmap=derive_device=qsv,format=qsv" -flags -global_header -codec:a:0 libfdk_aac -ac 2 -ab 124799 -ar 48000 -copyts -avoid_negative_ts disabled -max_muxing_queue_size 2048 -f hls -max_delay 5000000 -hls_time 4 -hls_segment_type mpegts -start_number 0 -hls_base_url "hls/04a6b91cf5c3263b9ab936bfb23d75eb/" -hls_segment_filename "/config/transcodes/04a6b91cf5c3263b9ab936bfb23d75eb%d.ts" -hls_playlist_type event -hls_list_size 0 -y "/config/transcodes/04a6b91cf5c3263b9ab936bfb23d75eb.m3u8"
[18:01:42] [ERR] [8] Jellyfin.Api.Helpers.TranscodingJobHelper: FFmpeg exited with code 1
[18:01:42] [ERR] [13] Jellyfin.Server.Middleware.ExceptionMiddleware: Error processing request. URL GET /videos/f69569c2-9a03-c082-2c47-c847c9e91f0a/live.m3u8.

MediaBrowser.Common.FfmpegException: FFmpeg exited with code 1

 

其实我也试过装linuxserver/jellyfin以求对比验证，奈何下了几次都下不了，而且每次都导致webui崩溃。而且我发现但凡是linuxserver/xxxx的docker都下不了，速度都非常慢，挂了节点、开镜像源都不行，这也是让我挠头的一点。现在墙封锁的已经这么厉害了吗？两年前在群晖上下载的时候记得一切都挺顺利的。

 

在查找问题的过程中，我发现unraid的应用市场下载docker虽然挺方便的，但是下载这个nyanmisaka/jellyfin的时候，居然不能手动加tag，导致每次下载的都是10.8.0的版本，这都是多久之前的版本了。而想要手动加tag，就必须在docker页面手动添加镜像才行。而若是在命令行手动pull镜像，下载下来的只会是孤立映像，完全不能用。真是让人挠头的现象，我想这些在群晖上轻易实现的功能unraid上却实现不了，有点颠覆我之前的印象。可能是我刚上手，还不会用吗？（小小吐槽一下）

 

j3455性能和核显解码太弱了，换硬件吧，除非你客户端直接解码

3 minutes ago, anpple said:

j3455性能和核显解码太弱了，换硬件吧，除非你客户端直接解码

谢谢回复，J3455的性能基本满足我的需求吧，第一次成功硬解时测试过，4K H265硬解转码能有57帧左右，两人同时解码能有27帧左右。而且我主要是看H265 1080p的动漫，够用了。

2 minutes ago, taletiger said:

谢谢回复，J3455的性能基本满足我的需求吧，第一次成功硬解时测试过，4K H265硬解转码能有57帧左右，两人同时解码能有27帧左右。而且我主要是看H265 1080p的动漫，够用了。

播放终端解码是最简单有效的，比如apple tv/手机/平板主流设备解码能力足够覆盖，j3455的核显比较弱，不支持的格式靠U软解自然是不行的

Just now, anpple said:

播放终端解码是最简单有效的，比如apple tv/手机/平板主流设备解码能力足够覆盖，j3455的核显比较弱，不支持的格式靠U软解自然是不行的

是的，我之前一直都是播放端解码，毕竟J1900的硬解性能等于没有。不过偶尔还是会有硬解的需求，而且J3455的性价比堪堪满足了我的需求，所以就选择了它。

我错了，原来是因为我把docker里面的/dev/dri参数赋给了变量，而不是设备，怪不得我没有当初打开特权选项的记忆。orz