HOMO114514

@sungo
Intro Skipper 默认设置是什么都不用动的，新装的插件手动去计划任务里面触发下 Detect and Analyze Media Segments 任务，跑完之后自己就会有了，可以用 PC 端找电视剧测试
findroid 去设置-播放器里面打开一下片头跳过器和 trickplay

trickplay 也是一样的，让它手动跑一下 Generate Trickplay Images ，不过这个时间会很久，库比较大的时候跑 2-3 天没跑完都是正常的

@kaedeair
plex ，包括 emby 的官方客户端，尤其是 TV ，它们都是用 ExoPlayer 做后端的，从安卓的开发来看这是最标准而且规范的格式，硬要从技术路线来说没有问题，所以实际上所有人（ J/E/P 御三家）的官方客户端都同样支持不了 ass 字幕。另外，ExoPlayer 作为系统标准组件，其编解码能力完全取决于硬件和授权，所以遇到 HEVC ，HDR10 ，DV 这些前沿影视内容的时候他们的支持是最好的。

当观看的内容是电视剧和电影居多的时候，这个技术路线几乎可以称得上是没有问题，因为电影多用 PGS 图形字幕，而像 Netflix ，HBO ，ATV 这种巨大的串流平台他们统一都使用最基础的 SRT 文本字幕——毕竟就连 iOS 的 Native 也只能支持这个。
（吐槽一下，iOS 的 Native 应该是兼容性最烂的，比浏览器还差一档，不仅挑格式还挑容器）

ASS/SSA 的需求，更多在于动画片，Anime 字幕组的生态群大量借助 ASS 的高级特性去实现一些精彩纷呈的字幕，而 ASS 如我原文所说有一些很头疼的历史遗留问题。正因如此才让 EXO ，MX ，VLC 这些产品拥有一席之地，然而 EXO 和 VLC 到现在还没在安卓系统上打通 HDR 回放

至于说 jellyfin-ffmpeg 的先进性，他们已经几乎做到了所有容器、所有编码、所有动态范围的 Transcode/Remux/Stream/Detection 能力，吃得下最多的片源，在设备不支持 Direct 时能够提供最有可能的降级解决方案，这个方案不仅是视频源/音频源转码，同时涵盖了字幕烧录、HDR 处理、硬件加速支持等能力

@javazero


服务器后端转码给前端喂的是 hls ，从实现上来看是 3 秒一个的 ts 片，24min 的影片一场转码会产生 480 个零散的 ts 文件，而并非一整个视频。
至于为什么 3 秒一个，设计出发点我不清楚，但是开源的东西可以去摸代码看，说不定有解释。
硬是要说实现，前端自己拼流是可以做到的，可能只是各个客户端的开发者觉得没有需求？

@digimoon
Findroid 有一个隐藏手势，长按视频右半边跳转到下一章节，左半边则是上一章，但是这个手势没有出过任何显式的教学，全凭自己摸索🤣
Yamby 则是右上角的“书”图标选择章节
Vidhub 暂时没有

@hazy 确实是这样的，Emby 来得太早，有生态惯性了。
不过我也是押注 Jellyfin ，它的 jellyfin-ffmpeg 解码能力，还有各方面的特性另外两家已经赶不上了，接下来需要的只有时间

H987XU-RP

@nszr
不会有的，支持 btrfs 却至今为止没有实现快照的 nas 系统没有任何研究的价值
从发布到现在半年了吧，天天蹲在群里看他们更新日志，到现在他们自我感觉良好觉得系统完善了，又花钱买了一波推广，但不会告诉你迄今为止基础的底层功能都没实现：
数据跨盘（跨存储池）备份、iSCSI 、快照

去 dashboard 可以看到正在进行的任务，如果是在生成 trick play 的话，记得在设置里打开硬件解码，不然大一点的库空转一星期都不带停的
开硬件解码能提速 10 倍以上