统一“顶设”的智能媒体服务。
邹娟|演讲者
大家好,首先欢迎各位来到LVS的阿里云专场,我是来自阿里云视频云的邹娟。我本次分享的主题为《从规模化到全智能:智能媒体服务的重组与进化》。
本次分享分为以上四部分,一是媒体服务(Mediaservices)面临的技术难题;二是如何使用统一“顶设”进行媒体服务的架构重组与规划设计;三是阿里云视频云服务不同企业客户不同场景需求面临的技术挑战、解法以及关于智能化演进的思路和实践;四是关于智能媒体服务的未来展望。
01 媒体服务(Mediaservices)的技术难题
第一部分主要介绍媒体服务(Mediaservices)的技术难题。
在此之前我们先对“媒体服务”的含义进行解释,我们将“媒体服务”定义为:客户音视频相关业务中,媒体层技术和服务能力的集合。
媒体服务当前面临的技术难题可以总结为三大类:一是如何灵活支持不同行业、市场、客户、场景的音视频业务;二是如何在此基础上满足这些迥异的业务场景的规模化需求;三是随着AIGC的兴起,在将AI技术融入媒体服务迭代的过程中,如何平衡短期利益和长期技术方向,做好长短期结合的智能化演进。
接下来对三类问题进行具体分析,首先是关于多种音视频业务如何灵活支持。
当前视频云领域包括视频点播、视频直播和音视频通信三大核心业务,他们的链路基本相同,均涵盖生产、处理、分发和消费四个主要部分。
我们的“旧有思路“是针对业务构建全链路的产品技术,而不同业务在相同环节可能拥有类似的媒体能力,如VOD产品中的“媒体处理MPS”与Live产品中的“直播转码”就非常类似,当随着视频社会化趋势不断发展,衍生出更多垂直的音视频业务时,沿用这种思路无疑会带来较多重复开发。
其次,不同场景的规模化需求大相径庭。
ToB云业务的规模化不仅包括大家印象中的“传统”大规模,如:海量、高并发、低成本等,还涵盖了诸如业务流多场景、多租户的要求,不同场景对媒体服务能力深度+广度的多样性要求等,因此ToB需要多个角度的总结、提炼和抽象。
第三是关于如何规划长短期结合的智能化演进。
针对短期,我们目前重点关注工业级AI应用的效果,当前AI的角色仍以辅助为主,多数业务为视频的检测、识别、分割等。
当前大模型及应用如雨后春笋般层出不穷,但离AGI时代的真正到来还有一定距离,我们需要关注相关的研究和技术储备如何从短期落地的状态平滑过渡,并规划一条衔接长短期演进的技术路线。
02 统一顶层设计:媒体服务架构的重组思路
基于以上背景,我们首先对音视频业务的媒体能力进行了框架式的统一顶设,定义为第0层重组。
重组前,媒体服务的各项能力已经存在于视频点播、直播、音视频通信等业务中,因此该过程并非从0到1造轮子,而是将既有媒体原子能力进行打散、重组,从而更好的实现资源复用,解决更多新业务自由搭建的问题。
重组后,媒体服务的整体框架如上图所示,最底层是基于云原生技术的存储、分发、传输等IaaS基础设施,在此之上是媒体PaaS服务的算法底座,媒体的PaaS层能力按照音视频生命周期划分为媒体汇聚、媒体生产制作、媒体处理、媒体消费和媒资管理5个板块,上层则是基于PaaS层搭建的PaaS+解决方案和各种行业场景应用。
将PaaS层5个板块进行服务的细粒度拆分,各项能力进一步内聚和丰富,形成媒体全景能力集,详见上图,列举了一些媒体服务的典型能力。
这些从不同业务中总结并提炼出的媒体服务能力,对相似性做抽象,对部分差异性做融合&增强,外加将多个服务的输入输出参数体系标准化,不仅可以提供阿里云视频云的自研服务,还具备一定的开放性,从框架层面允许通过安全认证的第三方服务的接入。
如此一来,重组后的媒体服务除了作为直播、点播等已有业务的媒体能力底座外,还为快速拓展新业务和新场景(如汽车、IOT、行业+等)提供了有效的支持。
在第0层重组做好整体规划的基础上,我们构建了统一的“媒体引擎”,进一步完成媒体服务的第1层重组。作为底层技术核心,它是媒体任务在“执行层”实现高时效、高性能及丰富功能的基石。
首先,作为持续发展的云原生服务,媒体引擎需要充分利用不同时期的机器资源,这就要求引擎层具备异构和软硬一体能力,支持CPU、GPU、ARM和ASIC等设备资源。其次,媒体引擎集成的算法既包括媒体处理算法与AI算法,也包括自研算法和二三方算法,它对算法集成进行了统一设计,通过算法效果/性能/成本自测系统、编码规范及合规自查系统、流量回放和陪跑系统保证引擎的稳定性与基础性能。第三是构建了统一的媒体处理框架,并通过单任务的分布式媒体计算引擎和复杂任务决策引擎实现底层资源的最优组织和复杂任务的最佳决策与反向调度。
近几年分布式云逐渐兴起,很多行业客户的视频服务部署在边缘云或混合云中,为了实现一套代码多云部署,我们进行了媒体服务的第2层重组。
这里主要面临两大挑战,一是不同环境依赖的组件不同,需要将依赖组件细化后进行动态配置;二是在最终部署前需要完成大量的多环境统一CICD和标准化一键部署方案。它本质上是一项统筹编程和持续集成的工作。
媒体服务的第3层重组主旨是通过定义统一的媒体数据协议及流转框架,消除数据在不同服务间转换造成的损失。
而媒资的核心角色之一正是媒体服务的数据底层,因此第3层重组最重要的工作是构建视频云不同产品服务间的统一媒资系统,设计上主要分三层:
最底层是统一媒资的数据底座,1)对直播、点播等不同服务的媒体信息构建OneMediaID,2)通过媒体流程引擎和开放服务注册构建统一工作流,3)通过统一任务处理流程、管道定义、参数模板构建统一媒体处理协议框架。
中间层为关于媒资库的统一设计,设计标准对标广电媒资,核心思路是通过统一的包括多种实体定义(如基于文本的关系型元数据库和基于特征值的向量元数据库)的动态元数据体系来支持不同形态媒资实体存储。
顶层为媒资的体系化,核心是两个体系:元数据体系与存储文件体系。关键词则是媒资体系的灵活性和自构建能力,提供不同客户可自定义媒资Structure和Value体系的能力。
03 媒体服务进阶技术:规模化挑战与全智能演进
接下来介绍关于媒体服务的进阶技术,阿里云ToB业务当前面临的最大挑战是不同场景、不同客户带来的规模化技术挑战。
与C端业务支持相对聚焦的场景不同,云视频业务因其多行业、多市场、多客户、多场景应用的背景使得高可靠、低成本、高时效等规模化难度倍增。因此规模化对于视频云厂商而言,既是“特有”的机会,也是挑战。
阿里云视频云规模化技术的整体实现思路请见下图:
首先,我们采用了云原生架构作为整体实现框架,利用云的先天优势做好弹性和按需处理,并且在视频云的IaaS层实现软硬一体、云边一体和云端一体。其次,媒体服务规模化技术的实现依赖算法、引擎、调度、分布式服务四层的相互配合,缺一不可。
以一个长视频超分加HDR的处理任务为例,分布式服务层在接受任务后负责进行流程分析和编排,并将任务指令发送至调度层,调度层负责依据任务参数进行预处理和并行拆分,引擎层负责依据拆分结果组织最优算法完成任务执行。单一任务尚且如此,海量任务高效且有质量的完成则更需要四层之间的配合。
规模化技术中的一项关键点为媒体引擎的单任务优化。
无论多么海量和大规模的媒体处理与生产任务,最终仍需被拆分为单任务进行处理,它可被看做规模化的基石。从上图中媒体处理的标准流程来看,引擎侧需综合考虑单任务全链路环节的稳定性、成本、性能以及时效性。
我们通过末端异常感知(稳定性优化)、多维度性能优化(利用算法工程优化、指令集优化、硬件加速优化和结合业务策略优化来优化单帧处理时间,进一步降低成本)、任务Quota动态调整(调度层依据引擎层动态反馈最优调整资源池配置,以节约成本)和单任务的分布式处理(将复杂任务拆分处理)实现单任务优化。
媒体引擎对基础设施的多样性支持,配合逐层递进的分布式媒体调度与PaaS服务,可放大规模化效果。
媒体引擎可以更好地联合调度层做好水位和资源池控制,实现降本增效。而业务层和引擎层程序直接接触业务特性本身,对其非常敏感,我们还可以和业务层的规则引擎更好配合,将不同客户场景要求、任务处理模式(标准模式、注重时效性的高倍速模式、注重资源独占的独享模式和注重成本的闲时模式)与任务调度、资源调度、原子服务在引擎层的执行进行逐层递进的配合,从而完成多场景和海量视频的高并发处理。
接下来介绍三个关于规模化技术的实践。首先,是最常见的关于短视频高时效性与成本平衡的实践。
短视频时长短、数量多,客户对视频处理的耗时容忍度较低,同时对成本控制的要求较高。在该场景下我们主要考虑多指标的兼顾与平衡,采用了单任务性能优化、媒体文件预处理,媒体处理多策略选择的三重优化策略。
比如可通过准确分析音视频流信息的秒级预处理为下一步决策提供依据,在某短视频场景中,客户选择以可播放作为媒体处理主策略的牵引,如果源片可播即优先播放源片,如果源片不可播,可以优先播放低分辨率转码文件,实现快速播放,如果源片有热度,需要高质量呈现,可动态替换播放地址为高画质转码视频,或者直接使用动态多码率根据设备与网络的情况,动态选择适合的文件切片播放,最终再结合上图所示策略有针对性的进行单任务性能优化。
第二个实践是关于长视频的倍速处理。
在长视频的转码与剪辑处理中,时效性无疑是最大的痛点,尤其是当客户的行业是新闻资讯等需要快速分发的场景时,则显得更加重要。与我们上个版本的的高倍速并行处理技术相比,最新版本增加了三个特性:1)高倍速并行框架既支持单入多出的转码场景,也支持输入为多轨道/素材/效果编排的时间线的剪辑场景;2)无论时间线(timeline)的格式如何,我们均支持在任意位置split,精度到帧级别;3)不依赖客户的主动配置,智能判断timeline是否适合分片以及如何分片能拿到最高的收益。
第三个实践是关于高并发的实时媒体处理与生产。
它的特点与非实时的基于文件的媒体生产完全不同,这场场景最大的痛点是在出现突发状况的情况下保证稳定性和实时画面质量,由此我们采用了多资源池隔离&容灾互备、弹性伸缩、单流自动逃逸、多维度降级策略、无缝迁移、帧级别流同步等技术来保障这一点,还会与流媒体网络的QoS紧密配合,保证客户观看实时流的体验。
那么该如何理解“规模化”与“全智能”的关系?
“规模化”和“全智能”看似无关,实际在云计算场景下它们关联密切,规模化全场景意味着AI对多业务的渗透,而AI的加入对媒体业务的时效性有较大提升,AI+云计算则令海量的视频智能处理成为可能。总体来看,全智能是实现规模化有效的手段和方法,并且随着大模型技术的发展,以前AI最被诟病的效果问题也有了相当的改善,媒体处理与生产的质量得到显著提升。 我们在规模化进程中也会沿用媒体服务的顶层设计思路,持续实践全智能应用。
接下来分享关于全智能三个阶段的实践。
阶段1主要为较零散的智能辅助处理,严格意义上还不能属于全智能生产。
以生产制作、媒资和媒体处理的应用为例,在生产制作的五个主要环节中,可以看到AI的主要任务是进行预处理和预分析,为人的决策提供依据。在渲染与合成中涉及的AI特性也仅为一些单一场景的特性,会针对特定场景进行规模化微调。
在媒资与媒体处理的环节中,AI主要针对视频进行单一维度的内容理解,生成一些标签和特征值作为下一步骤的数据支持,人的参与至关重要,也难以进行全流程的规模化。
阶段2为全智能的初级阶段。
以生产制作领域为例,主要在阶段1的基础上增加了“素材智能挑选”和“时间线编排智能”两项功能。
案例视频:https://v.youku.com/v_show/id_XNTk3MDQyNzc4OA==.html
如上面的例子,根据有限的素材进行批量混剪,帮助客户进行短视频营销。在这个阶段我们尝试在无人干预的情况下规模化制作视频,将原始素材通过画面分析和AI预处理加工为中间片段,使用美学、丰富度优先等多种策略进行素材挑选,并参考短视频模板规则进行时间线的部分智能生成,最终实现利用有限素材,智能生成多个不同的营销成品视频。
阶段3为全智能的进阶。仍然以生产制作为例,在前2个阶段的基础上,我们增加了“素材生成智能”和“时间线处理智能”两项功能。
随着AIGC大模型的火爆,部分视频素材可以由人工拍摄转变为AI生成,解决了视频生产制作过程中的一项难题。而时间线的智能处理则将阶段2时间线编排中的轨道、素材、效果对象的进行综合智能处理,如驱动数字人、抠像与替换、叠加与增强等。
案例视频:https://v.youku.com/v_show/id_XNTk5NjA4OTAxNg==.html
如上视频为生成的成片效果,短短20s的视频(该视频为程序员自主生成,可忽略美学效果)囊括了视频摘要与搜索、素材片段截取、图/文生图/视频、数字人、人声复刻等多项AI技术,在这个阶段的实践中,AI已经全面覆盖了视频制作的各个环节。
那么现在的AIGC足够做出完美成片了吗?
从视频生产制作业务本身的创意、素材、编排、剪辑与包装、渲染与合成等角度来看:AIGC很难提供原创的创意;在素材生成方面,AI已经取得了比较明显的进展,但在素材及其片段的挑选方面基本还靠人工,比如文生图一般都会提供多张供用户挑选;时间线编排仍然以人工编排或模版套用为主,完全的智能化尚处于起步阶段;在剪辑与包装、渲染与合成方面,AI以传统的场景驱动和散状支持为主。
总体上,当前AIGC在视频生产制作领域主要是用于生成素材,成片以人工或固定逻辑串接为主,虽然其成长空间是巨大的,但此刻距离完美成片仍有很长的路要走。
事实上,在AIGC火爆之前,媒体服务在生产制作领域,就针对全智能进行了布局。
我们从生产制作的业务流程(创意、素材、编排、剪辑与包装、渲染与合成)出发,推演全智能的发展趋势。另一方面,生产制作的输出=媒资与媒体处理的输入,我们认为这会进一步带动媒资、媒体处理的全智能。
从上图可以看出,当前处于第三和第四阶段的初期,我们相信第五阶段终将到来,AI能够依据海量丰富的数据自行发掘创意点,做有故事的视频,真正拥有“创作力”。
04 智能媒体服务的未来展望
关于智能媒体服务的未来展望,基于当下大模型的发展趋势,我们认为基础大模型将像操作系统、浏览器一样成为AI基础设施与开发平台底座,智能媒体服务也会基于新一代智能底座围绕专业化、多场景、开放性、沉浸式和通用智能再度进化:
一是为行业化视频应用功能百花齐放做好PaaS层支持;二是利用AI进行内容创作的门槛大幅降低,大众式的视频内容创作可能即将来临;三是视频赛道的整体内容质量将大幅提升;四是对音视频体验有极致要求的场景比例将持续扩大;五是传统互联网媒资将演进为智能数字资产管理;六是媒体服务支撑的各个领域,基于大模型的企业垂直应用,将快速搭建与生成。无论技术如何演进,智能媒体服务为企业提供丰富、灵活、高效、智能的媒体能力的初衷依然不会改变。
我今天的分享就到这里,谢谢大家!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。