查看详情

OTT 开发的挑战

做 OTT 设备相关的开发有一段时间了，计划写一点关于这些设备上开发商学习到的经验和以及比较困难的部分。这里面有非常多反直觉的东西， 它和我们传统 WEB 开发有些区区别。 设备老化 这个是我觉得自己在从 WEB / Android 开发转型 OTT 开发面临的一个问题。电视和手机是完全不一样的消费场景。手机厂商每年会头发大量的资源做手机的更新，但是电视不一样。对于很多人，可能手机三年或者四年就计划换新，因为手机迭代的功能非常快，几年不换，就缺一些功能了。由于手机已经早已拜托了打电话单一功能的限制，变成了多功能的娱乐设备。很多人会用来看视频， 玩游戏，拍照等。 然而电视或者 OTT 盒子，它目前为止娱乐场景非常单一。你只能把它放到家里，而且时间比较单一，晚上或者周末。没有人出去旅游，拿一台自己的 FireTV stick 去酒店播放。所以他们的更新频率会慢道七八年，甚至10年多。没错，我们的数据反馈出有超过大部分用户依旧用着七年前的设备，超过十年的设备已经运行着。 平均更换周期： 根据市场调研公司 Circana（前身为 NPD Group）的最新数据，美国消费者平均每 6.6 年 详情 »

查看详情

【DRAFT】ES2025 的语法糖科普

不知不觉 ES2025 都快推出了，这里分享一些比较有趣的用法。 Time API 更新的时间API // Simplified date creation const now = Temporal.now(); const birthday = @2024-01-15; // New date literal syntax const meeting = @2024-12-25T10:30:00[Asia/Shanghai]; // Syntactic sugar for date/time arithmetic const nextWeek = now + 7.days; const lastMonth = now - 1.month; const deadline = meeting + 2.hours + 30.minutes; // Time range syntax const 详情 »

查看详情

为什么 Android Webview 不支持 L1 级别的 Widevine DRM 安全级别

接着前一篇文章 DRM Widevine L1 在 Android Webview 的支持情况, 这一篇文章是基于 Cursor 对 Chroimum 源码分析得出的一些结论。本文主要回答两个问题： 为什么 Android Webview 不支持 L1 级别的 Widevine DRM 安全级别 为什么 Android Chrome 应用支持 L1 级别的 Widevine DRM 安全级别 为什么 Android Webview 不支持 L1 级别的 Widevine DRM 安全级别? 主要原因： 1. 硬件安全解码要求 根据 Chromium 代码中的逻辑，在 Android 平台上： // 在 Android 上，SW_SECURE_DECODE 详情 »

查看详情

DRM Widevine L1 在 Android Webview 的支持情况

最近在开发中遇到了 Android TV 无法通过 L1 的检测。代码检测如下： async function checkWidevineL1Support() { const keySystem = 'com.widevine.alpha'; // Robustness levels to test, from most secure (L1 equivalent) to least secure (L3 equivalent) const robustnessLevels = [ 'HW_SECURE_DECODE', // Likely L1: decryption and decoding in TEE 'HW_SECURE_CRYPTO', // Likely L2: decryption in TEE, decoding in software 'SW_SECURE_DECODE', // Likely 详情 »

查看详情

Chromium 视频架构设计文档介绍

如果你一直在进行浏览器的音视频开发，一定要去阅读官方的设计文档。 文档地址 Chrome 在支持 HTML5 的 <video> 标签与 <img> 标签（仅要求浏览器知道如何解码少数几种图像格式）不同，<video> 标签要求浏览器知道如何： 通过网络获取视频数据 解复用（demux）容器格式以找到音频和视频轨道 解码各种各样的音频和视频编解码器 (codec)。 此外，时间同步对于播放至关重要：音频和视频必须根据容器格式和用户代理控件（播放、暂停、跳转/快进）指定的时间点相互同步地呈现出来。 Chromium 的媒体播放实现有几个部分 Pipeline：Chromium 的媒体播放引擎实现，处理音频/视频同步和资源获取 FFmpeg{解复用器， 音频解码器， 视频解码器}：用于容器解析和软件音视频解码的开源库。 Blink 的 HTMLMediaElement： 按照 WHATWG 的规定实现 HTML 和 Javascript 详情 »

查看详情

使用 JS 判断 PSSH Box

现在 AI 已经非常牛逼了，如果你有这样的需求，非常明确的，建议你直接使用 AI。这是谷歌 Gemini 给出的结果： 使用 JavaScript 检测 MP4 文件中的 PSSH（保护系统特定标头）是一项复杂的任务，主要是因为： 二进制数据：MP4 文件是二进制的，而不是基于文本的。浏览器环境中的 JavaScript 在低级别上限制了对二进制数据的直接访问。 文件结构：PSSH 嵌入在 MP4 的原子结构中，需要解析才能找到它。 浏览器安全性：浏览器限制直接文件系统访问，限制您直接读取任意 MP4 文件的能力。 但是，您可以通过多种技术组合来实现这一点，主要涉及用于检索文件的 fetch API、用于二进制数据处理的 ArrayBuffer 和自定义解析逻辑。以下是一般方法的细分： 获取 MP4 文件： async function getPSSH(url) { try { const response 详情 »

查看详情

useState 设置为函数类型时候需要注意的点

自己最近在一次重构中，尝试给予一个 state 为一个 class 的时候，却发现抛出了无法 new 的异常。 import React, { useState } from "react"; import A from './A' const MyComponent = (props) => { const [myCls, setCls] = useState(); const handleClick = () => { setCls(A); }; return ( <button type="button" onClick={handleClick}> A button </button> ); }; 其实设置函数类型时候，一般都不推荐这样用，因为在 usestate 里面有个隐藏的实现， 就是如果传入的是函数，会默认其为一个更新函数， 详情 »

查看详情

Media Key Session Close vs Remove

这其实是 Web 前端多媒体开发，非常细的点，可能很多人都不太会在意。但是如果你是做 DRM 的开发，则非常有可能会接触到。 MediaKeySession 代表与内容解密模块 (CDM) 进行消息交换的上下文。 其中有两个非常重要的接口： remove(): Promise 删除与当前对象关联的所有会话数据后返回close(): Promise 在通知当前媒体会话不再需要并且 CDM 应该释放与该对象相关的任何资源并将其关闭后返回。其中这里最重要的概念，就是你是否需要通知 CDM 模块进行释放，我们 JS 测其实不太会参与较多的关于加密相关的事情，而更多还是依靠 CDM 内部机制。 因此如果你的 Case 是，播放完该视频后，不会再进行复播，你最好是直接 Close, 如果你只是中断，后面会重新播放的，可以建议尝试 Remove。 我们日常 Web 播放由于绝大多数都是非常持久的 License，所以区别不是很大，但是如果是 persistent-license 则应该尤为注意。 目前 hls.js 侧给了非常标准的实现是 mediaKeySession.remove( 详情 »

查看详情

PSSH and PSSH Box 介绍

最近在工作遇到了关于 pssh0 的关键词标记。当然你第一样看，可能并不清楚这个是什么东西，但是如果你是做多媒体 DRM 的，你或许会对 PSSH 有所了解。这里结合着搜索的资料简单介绍下这个 PSSH是什么东西，而这里面的 0 又是什么含义。 PSSH-Protection System Specific Headers 顾名思义，就是保护系统特定头部信息。当视频内容受到 DRM 保护时，内容会被加密，并且会将元数据添加到内容中。添加此类元数据的过程称为 DRM 信号传输。 PSSH 是一个标准化容器，用于保存用于保护数字内容的保护系统所特有的元数据。因此，PSSH 是 DRM 信号传输的一部分。 PSSH不包含加密密钥本身（它是一个秘密），但它包含有关加密的必要信息，例如密钥 ID、加密方案以及从许可证服务器获取密钥所需的其他信息。 PSSH 最终在“ISO/IEC 23001-7:2023 MPEG 系统技术 - 第 7 部分： 详情 »

查看详情

HEVC DRM 在 Chrome 支持的问题

Chrome 在 105 版本后更新了对 HEVC 的支持，意味着，你可以直接在 Chrome浏览中播放 HEVC(H265) 的视频了。 对这个新的更新，当然大家都非常开心，可以放心给 Web 测提供 HEVC 的内容了，然而，这里还有一个点需要大家注意： 不幸的是，当前最大的缺点是，不支持带有 Widevine DRM 的 HEVC，只支持清晰、不受保护的内容。目前尚不清楚 Google 是否计划在未来增加对此的支持。 近期的验证告诉我们，当前Chrome依旧不支持 DRM + HEVC. 所以你依旧需要选择 AVC + DRM 的方式或者 AV1。 https://support.google.com/chrome/thread/206528835/does-chrome-desktop-107-support-hevc-with-widevine-drm?hl=en https://stackoverflow.com/questions/ 详情 »