<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Playback on TinyChen's Blog</title><link>https://tinychen.com/tags/playback/</link><description>Recent content in Playback on TinyChen's Blog</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Thu, 23 Jul 2026 12:00:00 +0800</lastBuildDate><atom:link href="https://tinychen.com/tags/playback/index.xml" rel="self" type="application/rss+xml"/><item><title>Octans-Android Media3实验路径能力边界</title><link>https://tinychen.com/20260623-octans-android-media3-capability-boundaries/</link><pubDate>Tue, 23 Jun 2026 12:00:00 +0800</pubDate><guid>https://tinychen.com/20260623-octans-android-media3-capability-boundaries/</guid><description>&lt;p&gt;本文是 &lt;a href="https://tinychen.com/20260526-octans-android-playback-engine-evolution/"&gt;Octans Android 播放内核演进&lt;/a&gt; 的能力边界附录：在「默认 libmpv + Media3 ExoPlayer 本地实验」已定之后，把实验内核上三条有独立证据的收口写清楚——&lt;strong&gt;外置音轨不进产品主线&lt;/strong&gt;、&lt;strong&gt;视频轨道允许超出声明能力尝试播放&lt;/strong&gt;、&lt;strong&gt;对白增强只保留一条低延迟图&lt;/strong&gt;。目标是给读者一张可对照的实验路径能力表，而不是再讲一遍双内核为什么打开。&lt;/p&gt;</description></item><item><title>Octans-跨端客户端Web基线与原生播放</title><link>https://tinychen.com/20260601-octans-cross-platform-ui-playback/</link><pubDate>Mon, 01 Jun 2026 12:00:00 +0800</pubDate><guid>https://tinychen.com/20260601-octans-cross-platform-ui-playback/</guid><description>&lt;p&gt;本文主要介绍一类媒体库产品在多端客户端上的总路线：为什么&lt;strong&gt;不能&lt;/strong&gt;把「跨平台 UI 框架是否足够好」当成顶层问题；为何应坚持 &lt;strong&gt;Web 做基线、各端原生 UI、各端 native 播放&lt;/strong&gt;；以及协议、能力上报与服务端 fallback 哪些可以共享、哪些必须按平台落地。&lt;/p&gt;</description></item><item><title>Octans-Android播放内核从libmpv到双内核</title><link>https://tinychen.com/20260526-octans-android-playback-engine-evolution/</link><pubDate>Tue, 26 May 2026 12:00:00 +0800</pubDate><guid>https://tinychen.com/20260526-octans-android-playback-engine-evolution/</guid><description>&lt;p&gt;本文主要介绍 Octans Android 客户端播放内核从「LGPL libmpv 单内核」到「默认 libmpv + Media3 ExoPlayer 本地实验」的选型与演进过程，以及 HTTPFILE / HLS、字幕、硬解等有证据支撑的能力边界。讨论的是决策可被 supersede 的工程取舍，而不是一套永恒正确的播放器教条。&lt;/p&gt;</description></item><item><title>Octans-win客户端libmpv与服务端FFmpeg分工</title><link>https://tinychen.com/20260526-octans-windows-libmpv-lgpl-runtime/</link><pubDate>Tue, 26 May 2026 12:00:00 +0800</pubDate><guid>https://tinychen.com/20260526-octans-windows-libmpv-lgpl-runtime/</guid><description>&lt;p&gt;本文主要介绍 Octans Windows 客户端为何不能直接复用服务端 full FFmpeg，而要单独维护一条受控 LGPL &lt;code&gt;libmpv&lt;/code&gt; 播放 runtime：许可证边界、动态链接与 source offer / SBOM 口径、本地播放配置，以及客户端能力如何上报给服务端做 DirectPlay / HLS 规划。讨论的是可 supersede 的工程取舍，不是法律意见，也不是已全量上线的发布承诺。&lt;/p&gt;</description></item><item><title>Octans-媒体库动态范围与色彩管线</title><link>https://tinychen.com/20260426-octans-dynamic-range-color-pipeline/</link><pubDate>Sun, 26 Apr 2026 12:00:00 +0800</pubDate><guid>https://tinychen.com/20260426-octans-dynamic-range-color-pipeline/</guid><description>&lt;p&gt;本文主要说明自托管媒体库（以 Octans 一类播放子系统为例）在协商 DirectPlay / DirectStream / Transcode 时，为何「能解码」不等于「能正确显示」：动态范围与色彩管线应作为独立事实进入 Planner，DirectStream 的视频 copy 不能自动修 HDR，tone mapping 属于完整转码，以及 Dolby Vision 为何必须按 profile / fallback 保守处理。&lt;/p&gt;</description></item><item><title>Octans-媒体库播放架构总览</title><link>https://tinychen.com/20260425-octans-playback-architecture-overview/</link><pubDate>Sat, 25 Apr 2026 12:00:00 +0800</pubDate><guid>https://tinychen.com/20260425-octans-playback-architecture-overview/</guid><description>&lt;p&gt;本文主要从&lt;strong&gt;架构边界&lt;/strong&gt;角度梳理一类自托管媒体库（以 Octans 播放子系统为例）：播放为何从 Catalog / 任务系统里拆出来，服务端与客户端各管什么，以及 PlaybackSession、Planner、DirectPlay / HLS 交付如何构成当前 Web 主链。重点是职责与名词，而不是接口字段大全。&lt;/p&gt;</description></item><item><title>Octans-媒体库播放能力规划与分流</title><link>https://tinychen.com/20260425-octans-playback-capability-planner/</link><pubDate>Sat, 25 Apr 2026 12:00:00 +0800</pubDate><guid>https://tinychen.com/20260425-octans-playback-capability-planner/</guid><description>&lt;p&gt;本文主要把一类自托管媒体库（以 Octans 播放子系统为例）的&lt;strong&gt;播放能力决策&lt;/strong&gt;写成可复用的 Planner 模型：输入不是「codec 能不能播」的布尔判断，而是客户端能力、媒体事实与策略的交叉求解；输出是 DirectPlay / DirectStream / Transcode（及无法成计划时的 Unsupported），并与交付方式（HttpFile / Hls 等）解耦。&lt;/p&gt;</description></item><item><title>Octans-媒体库播放排障从会话到HLS</title><link>https://tinychen.com/20260425-octans-playback-debugging-guide/</link><pubDate>Sat, 25 Apr 2026 12:00:00 +0800</pubDate><guid>https://tinychen.com/20260425-octans-playback-debugging-guide/</guid><description>&lt;p&gt;本文主要记录一类自托管媒体库（以 Octans 播放子系统为例）在 Web 与 Windows native/libmpv 播放链路上的排障方法：从创建会话、DirectPlay / HLS 分流、暂停恢复与 seek，到字幕资源、硬解回退与残留 window 清理。命令与路径已通用化，便于对照同类架构做定位。&lt;/p&gt;</description></item><item><title>Octans-媒体库转码支持矩阵怎么读</title><link>https://tinychen.com/20260425-octans-transcode-support-matrix-guide/</link><pubDate>Sat, 25 Apr 2026 12:00:00 +0800</pubDate><guid>https://tinychen.com/20260425-octans-transcode-support-matrix-guide/</guid><description>&lt;p&gt;本文主要讲一类自托管媒体库（以 Octans 播放子系统为例）的转码支持矩阵&lt;strong&gt;读法&lt;/strong&gt;：它回答什么、不回答什么，DirectPlay / DirectStream / Transcode 如何分层，以及客户端能力、媒体事实与服务端策略如何共同决定播放路线。重点是决策机制，而不是把整张能力表抄进文章。&lt;/p&gt;</description></item><item><title>Octans-客户端字幕渲染与不烧录策略</title><link>https://tinychen.com/20260412-octans-client-subtitle-rendering/</link><pubDate>Sun, 12 Apr 2026 12:00:00 +0800</pubDate><guid>https://tinychen.com/20260412-octans-client-subtitle-rendering/</guid><description>&lt;p&gt;本文主要说明自托管媒体库（以 Octans 播放链路为例）在「尽量 Direct Play、字幕不触发视频转码」前提下，如何把字幕识别、抽取与缓存放在服务端，把 WebVTT / ASS / PGS 等形态的实际绘制交给客户端；并厘清 full-cache、HLS sidecar delay 与烧录路线的边界，避免把排障问题误当成「再烧一遍就好了」。&lt;/p&gt;</description></item></channel></rss>