Playback

本文主要记录「蓝光原盘」在工程上必须拆开的几类形态，以及 libbluray、Kodi / mpv、厂商盒子与媒体库产品各自停在哪一层。目标是建立边界心智模型，不是宣布某一客户端已经支持原盘菜单或加密商业碟。 ...

本文主要记录 Android Media3 路径上播放 Dolby Vision Profile 7（双层） 时的开播策略：为何能力声明不能当硬试开关、假成功黑屏为何不能自动猜切，以及用户三态（双层 / 单层 / 兼容层）与默认「单层」如何定。它是 Media3 实验路径能力边界的续写，不是 HDR 概念百科。 ...

本文主要记录 AVS2 / AVS3 在标准定位、消费级硬解现状、开源软解接入与许可证边界上的结论，以及这类编码在自托管媒体库播放架构里应如何处理。结论来自公开材料与工程对照，不代表产品已承诺支持 AVS 系列。 ...

本文主要对照 Kodi 对 VobSub（idx/sub）的客户端原生路径，与媒体库产品把 VobSub 统一转成 Blu-ray PGS（.sup） 再按既有 bitmap 合同分发的做法。目标是讲清架构差异与历史演进，不是承诺恢复 pair 数据面或各端自带 VobSub 渲染器。 ...

本文是 Octans Android 播放内核演进 的能力边界附录：在「默认 libmpv + Media3 ExoPlayer 本地实验」已定之后，把实验内核上三条有独立证据的收口写清楚——外置音轨不进产品主线、视频轨道允许超出声明能力尝试播放、对白增强只保留一条低延迟图。目标是给读者一张可对照的实验路径能力表，而不是再讲一遍双内核为什么打开。 ...

本文主要介绍一类媒体库产品在多端客户端上的总路线：为什么不能把「跨平台 UI 框架是否足够好」当成顶层问题；为何应坚持 Web 做基线、各端原生 UI、各端 native 播放；以及协议、能力上报与服务端 fallback 哪些可以共享、哪些必须按平台落地。 ...

本文主要介绍 Octans Android 客户端播放内核从「LGPL libmpv 单内核」到「默认 libmpv + Media3 ExoPlayer 本地实验」的选型与演进过程，以及 HTTPFILE / HLS、字幕、硬解等有证据支撑的能力边界。讨论的是决策可被 supersede 的工程取舍，而不是一套永恒正确的播放器教条。 ...

本文主要介绍 Octans Windows 客户端为何不能直接复用服务端 full FFmpeg，而要单独维护一条受控 LGPL libmpv 播放 runtime：许可证边界、动态链接与 source offer / SBOM 口径、本地播放配置，以及客户端能力如何上报给服务端做 DirectPlay / HLS 规划。讨论的是可 supersede 的工程取舍，不是法律意见，也不是已全量上线的发布承诺。 ...

本文主要说明自托管媒体库（以 Octans 一类播放子系统为例）在协商 DirectPlay / DirectStream / Transcode 时，为何「能解码」不等于「能正确显示」：动态范围与色彩管线应作为独立事实进入 Planner，DirectStream 的视频 copy 不能自动修 HDR，tone mapping 属于完整转码，以及 Dolby Vision 为何必须按 profile / fallback 保守处理。 ...

本文主要从架构边界角度梳理一类自托管媒体库（以 Octans 播放子系统为例）：播放为何从 Catalog / 任务系统里拆出来，服务端与客户端各管什么，以及 PlaybackSession、Planner、DirectPlay / HLS 交付如何构成当前 Web 主链。重点是职责与名词，而不是接口字段大全。 ...