查看详情

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/ 详情 »

查看详情

Multiple DRM Keys 介绍

本来没有这一期的,但是最近项目上遇到了,便记录一下。 往期回顾 多重DRM(Multiple Digital Rights Management)是一种通过叠加多种数字版权管理技术来保护数字内容的综合性解决方案。简单来说,就是给数字内容穿上多层“铠甲”,让盗版者难以攻破。 为什么需要多重DRM? 随着数字内容的爆炸式增长,盗版问题也日益严峻。单一的DRM技术很容易被破解,而多重DRM则通过组合不同的DRM技术,大大提高了内容保护的安全性。 多层防护: 就像密码设置一样,多重DRM相当于设置了多道关卡,破解难度成倍增加。 适应性强: 不同的DRM技术适用于不同的场景,多重DRM可以根据内容的价值和受众特点,灵活组合不同的技术。 抵御新型攻击: 黑客不断更新攻击手段,多重DRM可以通过及时更新和调整技术组合,来应对新的威胁。 多重DRM的工作原理 多重DRM通常包括以下几个步骤: 内容加密: 使用多种加密算法对内容进行加密,让未经授权的用户无法直接读取。 许可证管理: 生成不同的许可证,授予不同用户不同的访问权限,例如只能在线观看、不能下载等。 设备绑定: 将内容的使用与特定的设备绑定,防止内容被非法复制到其他设备。 动态密钥管理: 定期更新密钥,增加破解难度。 两种常见实现方案 单独定义不同内容要求的 DRM 秘钥 使用不同的 DRM 许可证保护内容的哪些轨道,因为这些许可证定义了允许播放指定内容的不同环境。 详情 »

查看详情

HDCP 介绍以及在 Web 的应用

HDCP(High-Definition Content Protection)是数字内容保护的一种方案,旨在保护数字视频内容在从设备传输到显示器或投影仪的途中不被非法复制。它由英特尔开发,并已成为高清数字内容传输的行业标准。 HDCP 的工作原理 HDCP 使用一对加密密钥来保护数字内容。第一个密钥由源设备(例如蓝光播放器或计算机)生成,第二个密钥由显示器或投影仪生成。当源设备将视频信号发送到显示器或投影仪时,它会使用第一个密钥对信号进行加密。显示器或投影仪使用第二个密钥来解密信号。如果缺少正确的密钥,则无法解密信号,因此无法复制内容。 HDCP 兼容设备拥有自己独特的加密密钥集,当尝试将受 HDCP 保护的内容从一台设备传输到另一台设备时,它们会相互交换这些密钥。这些加密密钥既可以确认每台设备都符合 HDCP 标准,又可用于在传输内容时对其进行加密,然后在另一端解密。这可以防止中间人攻击在传输过程中窃取未受保护的媒体。 现代显示器理所当然地都支持 HDCP,因此您最有可能遇到与推出时不支持 HDCP 的旧高清电视的兼容性问题。如果您使用不支持 HDCP 的电缆或分线器,即使显示器本身支持 HDCP,也会出现这种情况。 虽然 HDCP 最常用于蓝光光盘等物理媒体,但它也用于一些流媒体服务。例如,迪士尼和华纳兄弟使用 HDCP 来加密和保护几乎所有自己的节目,因此如果您在流媒体服务(尤其是他们的第一方服务)上遇到它们, 详情 »

查看详情

解读 GDPR

GDPR,是指通用数据保护条例(General Data Protection Regulation)的缩写,是欧盟(EU)的一项法规,旨在保护欧盟公民的个人数据并赋予他们对其数据的更多控制权。它于2018年5月25日生效,取代了1998年数据保护指令。你可以前往的官方网站阅读具体的内容,里面罗列了非常详实的条款。 https://gdpr-info.eu/ 如果你的网络服务需要登录欧洲,这个协议是你必须了解的。GDPR 适用于在欧盟运营或处理个人数据的任何组织,无论其总部位于何处。这意味着即使您是一家美国公司,但您收集或处理来自欧盟公民的个人数据,则您也必须遵守 GDPR。你是懂欧洲的违法罚款的,尤其涉及数据隐私。 GDPR 带来的影响有: APP 必须获得个人的同意才能处理他们的个人数据 个人有权访问其个人数据并要求更正或删除不准确的数据 个人有权要求组织停止处理他们的个人数据或限制其处理 APP服务商必须任命数据保护官 (DPO),负责监督其遵守 GDPR 的情况 为了遵守GDPR,应用程序必须采取一些措施,例如: 获得用户的同意才能收集和处理他们的个人数据。 这意味着应用程序必须有一个明确的隐私政策,解释应用程序如何收集、使用和共享数据,以及用户如何控制他们的数据。用户必须能够轻松地同意或拒绝处理他们的数据的请求。 仅收集必要的个人数据。 应用程序只能收集为提供服务或履行合同所需的数据。他们不应该收集不必要或无关的数据。 以安全的方式保护个人数据。 应用程序必须采取适当的技术和组织措施来保护个人数据免遭未经授权的访问、使用、披露、 详情 »

查看详情

快速定位错误的 JEST 测试用例

随着代码集成越来越多,尤其大家对单测质量和覆盖率, 大家在 CI 里寻找错误的测试用例似乎非常麻烦。 其实有网友也有同样的需求: Print list of failed tests at the end of test run 这里面有个非常天才的小伙子,直接来了一个 npx jest 2>&1 | grep '●' Jest 失败的测试用例有个 ● 前缀!!! 为什么我比较喜欢这种,因为不需要更改配置,而且直接可以在网页浏览器搜索 '●' 详情 »

查看详情

实现类似 Medium 风格的视频加载

非常早之前写过关于一篇《[译]Medium 是如何优化图片加载的》 的文章。 最近在看一些视频封面的优化,其中会有一些黑屏的问题,于是乎想到了是不是可以借鉴这种风格。 大概原理还是,可以根据视频的 loadeddata 事件,然后将覆盖在上面的模糊的封面图隐藏,然后播放视频。 html <div class="video-container"> <video width="720" src=""></video> <div class="cover"></div> </div> CSS .video-container { position: relative; width: 720px; display: none; 详情 »

查看详情

AB 实验结果分析的多重性

在公司工作,普遍采用了AB实验去验证某个 Feature 的效果,但是客户端或者前端工作而言,我们在做实验分析的时候还需要做更多的事情。 去年自己遇到一个 Case 便是如此。这里不太会透露很多业务的细则。 比如自己再做的的一个实验 A, 它在前端整体跑下来的结果是 显著 positive 的。比如它从设计的出发,会带来某个指标的增长。从假设出发,到最后的结果,我们发现符合预期的。因此我们计划将它应用到全量用户。 总的来说这里没什么问题,但是我们都知道前端其实面临非常多设备型号, 有可能存在某种型号在这个 feature 上的失效,带来负面的影响。虽然我们看到了总体的增长,但是部分用户我们其实并没有看到预期增长,这个是我们工作需要去重视的。 因此后来我们也提议,在做实验结果 Review 的时候,可以 Review Top5 的机型指标增长情况。 很多人提出为什么不再测试阶段去针对多个机型的测试呢? 这里引入另外一个自己的 Case。前端工作的多重性,会让我们的工作总会有所疏漏。 自己在做的某个实验 B,它的假设是可以降低某种错误。然后我们开始进行多个平台的实验,发现普遍都取得了一些效果,然后我们准备去进行全量铺开。然后全量铺开的过程,发现它带来了某一项别的指标的异常上升。然后我们 Review 发现,它在某种机型某种条件下才会失效。 详情 »

查看详情

一台电脑与多个 Github 账户协作

很多公司都是企业组织在 Github 上进行代码的管理,因此大家可能需要一个工作的账户和个人的账户区分。其实这个非常好弄,只需要两部即可: Step1 配置多份配置 你可以在你的根目录,创建下面的的结构 ~ ├── .gitconfig <-- global └── Developer/ ├── personal/ │ ├── project_1/ │ ├── project_2/ │ ├── project_#/ │ └── .gitconfig <-- personal └── company/ ├── project_1/ ├── project_2/ ├── project_#/ └── .gitconfig <-- company 然后更新两份配置 # ~/Developer/personal/.gitconfig [credential] username = <github-user> [user] name = <github-user> email = <github-user>@users.noreply.github. 详情 »