资源存储节约方案调研
需求分析
当片源资源过多时，由于有些相对较老的资源点播率较低，如果提前将所有资源都转换成特定分辨率的话，会严重浪费存储资源。为了达到节约存储资源的目的，也就是以节约硬件成本和运营成本为目标，需要调研出新的可施行的技术方案。
综合当前项目实际情况来看，为了满足需求，分别从以下几个方面调研可行方案：
使用实时转码工作流替代当前的预制转码工作流。
充分利用当前大量的CDN节点的存储资源替代专用的存储服务。
使用更高效视频压缩算法作为主播放格式。
统一梳理整体业务流程，尽量从业务系统设计的层面去掉冗余的资源需求。
优化方向
实时转码
当前视频压制方案大致是由高分辨率原片向低分辨率进行转码，最终得到1080p、720p和576p等多种分辨率的播放版本。如果能够使用实时转码操作替代当前的预制转码，能够大幅度减少存储空间，同时也能够大幅减少新资源的上架发布时间。而视频编码算法往往都是需要大量算力的投入才能够满足实时性能需求，以当前最通用的编码算法H264来说，此算法相对较早，编码算法的算力需求同后续新出的算法相比，需求量要少很多。但是即便是使用H264编码，但是单纯使用CPU进行音视频转码同样需要消耗大量的服务器资源才能够保证业务的实时性，因此还是需要使用专用的加速卡来提供编码算力，本次还是基于当前正在使用的MA35D加速卡做算力调研。
结合加速卡的官方纸面数据和实际测试数据来看，单张卡对应不同视频分辨率时的性能：
从上述数据来看，1080p的片子转码速度较慢，如果实时转码的话后端硬件资源性能可能不够。那么有两个方法进行应对：
继续增加多张加速卡，直到算力满足要求；
折中方案，1080p继续保持现有的预压制方式存储，而720p和576p分辨率的资源则在点播后直接实时转码生成。
从实施可行性来看，可以将上面两种方法分为两部来实施，首先将720p和576p分辨率的资源播放改成实时转码，然后再补充加速卡，第二阶段再将1080p也改为实时转码。这里举个实际例子，一部90分钟H265编码的电影，1080p的体积为615MB，而720p是331MB，576p是279MB，假设当前同时存三个分辨率片子的话，估算第一阶段同时去掉720p和576p预制的话能够减少约50%的固定存储空间。
充分利用CDN缓存
考虑到资源点播和直播在需求上有明确不同，因此点播业务并不需要依靠转码服务直接推送实时码流给用户，那么所有资源都需要经过CDN加速，由于每个CDN节点都有不小的容量，因此如果充分利用CDN节点的缓存空间，能够大幅度降低资源源站及转码服务的压力。为了充分利用CDN的缓存空间，使用上有下面几个关键实施点：
尽量保证CDN内容的持久化存储，尤其是不要随意的大批量删除数据。大规模清理缓存之后，转码服务很容易快速成为性能瓶颈。
存在多个CDN节点共同加速同一个源站资源的部署情况时（线上部署往往都是这种模式），一定要开启分片存储的功能（HyperCDN里面有分片缓存的选项）。
上述两点中开启分片存储功能尤其重要！开启此功能之后，同一组中的CDN节点不存在重复资源，这样以10个CDN节点为例，一个节点如果是3.2T空间的话，那么开启此功能之后就形成了一个32T容量的数据仓库。只要CDN节点足够多，单节点空间足够大，甚至可以将整个源站的数据全部装入到CDN节点中。
视频算法
当前整个业界主流使用的编码算法一共三种，即H264、H265和AV1三种。三种算法的视频压缩能力是逐步增加的，一部影片同样观感清晰度的情况下，H265比H264节约30%-50%的空间，而AV1编码相比H265又能够节约30%的空间。
另外由于MA35D加速卡内部有一半的计算资源固定为AV1编码器了，因此如果使用H264/H265时只能够发挥出计算卡一半的计算能力！结合这两个因素，如果后续能够将编码修改为AV1时，既能够节约空间，又能够将转码效率翻倍。
根据“caniuse“网站统计的浏览器信息来看，当前浏览器对AV1的直接兼容性还不是很好，但是如果播放体系全部都能够定制化的情况下（例如指定使用手机APP或者PC播放程序），那完全可以全套使用AV1编码，这个可以结合实际业务情况来规划具体实施步骤。
系统策略
从整个系统业务的设计层面，也有一些辅助性的策略能够优化转码和存储。这里假设当前实际情况是需要预压制1080p的视频，那么可以考虑实施下面两种辅助策略减少预压制任务：
根据统计数据来决定资源是否需要预压制：当存在海量资源时，由于存在很多冷门的资源属于长期限制状态，那么就可以统计所有资源的热度，当只有资源点播率超过一定热度之后预压制1080p的备用，冷门资源则在必要的时候才会进行压制。而且基于统计数据，定期删除掉不活动的冷门资源，避免长期占用存储空间。由于缺乏统计数据支撑，无法准确估算此策略节约的存储空间，但是从常规的“八二理论”推算，也就是按照20%热门资源计算，这种方式或许能够节约50%-80%的固定存储空间。
类似上述方案，引入一个概率预判机制。举几个例子，在节假日用户大多会点播一些类似贺岁片这种和节日氛围强关联的资源；有用户观看了连续剧的很多集，那么可以预见用户大概率会继续观看后续的资源。
如果结合上述方法调试出一套完备的决策机制之后，即能够大幅度减少存储空间，也可以从容应对相对变化的客户需求，避免突增的转码需求积压在后端转码服务。
约束条件及实施建议
结合调研过程中碰到的问题，及为了方案的顺利实施，当前总结了下面这些问题及实施建议：
实时转码时，由于技术条件限制，暂时不方便单独转ts片段，暂时如果需要转码资源时，只能够整体转码之后再进行ts切片，后续再研究能够单独转片段的方法。
由于1080p的片子转码速度较慢，而且是常用分辨率，如果实时转码的话后端硬件资源性能跟不上，建议先保留1080p的预压制，将较低分辨率改为实时转码。后续转码资源足够时再逐步向全实时转码过渡。由于前期无法准确估计转码性能是否足够，甚至可以考虑先实时转576p资源，再实时转720p，最后再实时转1080p这样逐步升级的实施路线。
如果实施过程中或者实施前已经能够提前感知到转码资源不够支撑访问量时，就必须要提前考虑增加转码硬件。
由于最终用于播放的资源有广告压制、字幕、片头片尾合并等多个环节，初次转码过程中间有大量的需要人工配合检查的环节，因此如果采用实时压制方案，最好是考虑访问提前量、或者前期将更上层的源片进行一些预制作，例如提前去黑边、添加片头片尾等信息。前期广告、字幕等处理完成之后，后续只需要进行分辨率转换即可而不需要任何人工参与，为后续实时处理提供良好条件。
常见播放分辨率是16：9，如果画面比例后续还引入4：3这样的比例，那同样建议提前预制对应的高分辨率资源。原因同上一条，而且直接从16：9比例画面强行转换到其它比例之后，嵌入到画面的文字信息和图像信息会产生变形。
MA35D转码模式中有专门用于实时直播的优化项，但是根据实际测试比较，此优化项主要关注转码速度，码流大小不在主要考虑范围，造成同样观感质量的情况下文件体积会大很多，因此不建议开启板卡的实时转码模式，继续沿用当前的转码参数。
如果直接从高分辨率的视频往极低分辨率转换时，由于画面重新压缩，嵌入画面的文字信息往往会在新文件中模糊不清。加速卡有“ROI功能”，此功能是通过板卡内部的AI引擎识别文字信息，减少文字信息区域画面的压缩率，但是这种方案由于转码时所有画面信息都需要经过引擎处理，会造成转码上的性能瓶颈，不推荐采用。因此转码过程中嵌入文字水印、字幕的过程建议放在最后步骤进行，实时转码的时候再嵌入到画面。或者干脆重构整个转码业务逻辑时，设计一个转码预览的机制，每次有新片源加入时，针对新资源进行预览转码，而且程序要保存符合最终效果的转码参数，那么最终实时转码的阶段将对应参数传入即可，这样就能够确保实时转码过程中无需插入人工审核环节。