HTML video 标签无rotation属性，所谓“设rotation防投屏”是误解；浏览器仅依视频容器中rotate元数据调整渲染方向，不影响投屏；FFmpeg修改该元数据仅优化本地观看体验，不提供任何投屏防护。
video 标签的 rotation 属性和转码无关，别被名字误导
HTML video 标签没有 rotation 属性。所谓“设置 rotation 防投屏”是常见误解——浏览器读取的是视频文件容器层（如 MP4 的 tkhd box）里的旋转元数据（rotate tag），它只影响画面方向渲染，和投屏行为完全无关。强行用 CSS transform: rotate() 不仅不能防投屏，还会导致全屏错位、黑边、控件失焦，且 video.videoWidth 等属性仍返回原始尺寸，后续 JS 逻辑容易出错。
FFmpeg 写入 rotate metadata 对投屏无任何防护作用
用 FFmpeg 修改 rotation 元数据（例如 ffmpeg -i in.mp4 -c:v copy -c:a copy -metadata:s:v:0 rotate=90 out.mp4）只是让浏览器正确显示竖屏视频，不改变内容可投性。Chromecast、AirPlay 等协议在投屏时会忽略该标记，直接按原始帧宽高拉伸或裁剪；Safari 在 AirPlay 时甚至可能重置方向。这个操作对防投屏零贡献，但它能避免用户本地观看时画面歪斜——属于体验优化，不是安全加固。
真正影响投屏能力的是 DRM 输出保护策略
防投屏的有效控制点不在前端 video 标签，也不在转码参数，而在 DRM 许可证服务器（license server）下发的 outputProtection 策略。例如：
- Widevine：通过
hdcpEnforcement要求 HDCP 1.4/2.2，未满足则拒绝解密或降级为 SD - FairPlay：配置
outputProtection为required，并指定allowedOutputs（如禁用airplay）
这些策略由播放器（如 Shaka Player、Video.js + contrib-eme）在请求 license 时传递给服务端，再由 license server 决定是否授权、以何种输出能力授权。FFmpeg 转码过程无法嵌入或修改这些策略。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
转码本身可能削弱 DRM 保护链
如果视频已启用 Widevine/FairPlay，擅自用 FFmpeg 重新封装（哪怕只改 metadata）可能导致以下风险：
- 破坏原始加密密钥绑定（如 CENC
psshbox 与轨道的关联） - 丢失或错位
tencbox，使解密失败 - HEVC 视频若用
-c:v libx265重编码，可能触发某些 CDM 的硬件解码降级，间接影响 outputProtection 生效
生产环境应避免对已 DRM 加密的内容做任何转码操作。如需统一方向，应在加密前完成 FFmpeg 处理，并确保 pssh、tenc、avcC/hvcC 等关键 box 完整保留。
归根结底，转码参数解决不了投屏问题。想限制投屏，必须走 DRM + license policy 路线；想隐藏下载按钮，用 controlslist="nodownload"；想提示浏览器勿投屏，写死 disableRemotePlayback；而所有这些，都和 FFmpeg 的 -metadata 或 -vf 无关。
