|
为大规模处理数据带来新方法和编解码器是媒体与娱乐行业首要任务，尤其是对VR和HDR而言。随着MPEG开始接替HEVC，我们需要为流式传输沉浸式媒体开发出超高效的压缩技术。 随着超高速5G移动网络的即将面世，视频的绝对数量和复杂程度将越来越高，如果要随时随地支持实时VR流式传输和其他超高分辨率低延迟媒体应用，实现高效的数据处理将十分关键。 可以说，诸如MPEG这样的标准组织一直都十分繁忙。这家已有30年历史的机构自成立以来每年平均起草和发布六项标准。  爱立信媒体解决方案（Ericsson Media Solutions）的首席技术专家Tony Jones表示：“压缩效率是提供新服务或更好服务的主要工具之一，可将分发成本降至最低，或将两者结合起来。” 所以，开发能够处理大规模数据的工具变得非常紧迫，而其中最主要的任务之一是制定当前视频流标准HEVC的“继任者”。由MPEG和ITU-T Study Group 16旗下VCEG组成的联合视频专家团队（JVET）已经开始着手制定效率高出50%以上的多功能视频编码（Versatile Video Coding ，VVC)。 MPEG的发言人Christian Timmerer指出：“VVC的目标是提供比现有HEVC标准更高的压缩性能，并在2020年完成。” 同时是奥地利克拉根福特大学副教授，以及编解码器供应商Bitmovin研究主管的Timmerer补充道：“主要的目标应用和服务包括但不限于360度和高动态范围（HDR）视频。 ” MPEG指出，VVC的初步方案在超高清视频测试材料上表现出“特别有效”。他们预测最终标准的压缩效率将“远远超过目标的50％”。 因此，VVC将加入一个日益拥挤的OTT流媒体市场，其中包括当前最常用的编解码器AVC，VP9和HEVC，以及新成员AV1。 刚刚发布了上述编解码器比较测试结果的Bitmovin认为，多个编解码器标准可以同时存在。事实上，他们表示如果要支持各种设备和平台，这是“最必要的”元素，并且补充说，“多视频编解码器的支持已通过VVC的面世得到证实。” VVC的一个重要方面是编码更专注于360度框架的特定区域，亦即大多数用户关注的主场景。Timmerer说道：“VVC仍处于起步阶段，但我们可能会在IBC中看到各公司发布与这个方向相关的公告。” 1. JPEG XS  MPEG通常用于终端用户的存储，传输和消费，而JPEG则主要集中于静态图像，但它刚刚为视频制作和流式传输带来了新的编解码器。 开源的JPEG XS具有6：1的压缩比，实际上比标准JPEG（10：1）更低，与编解码器的发展背道而驰。 洛桑联邦理工学院Touradj Ebrahimi教授表示：“这是图像编码史上的第一次，我们为了更好地维持质量而降低了压缩率，我们正在使用更少的资源来加快速度。” 领导JPEG XS开发的Ebrahimi补充道：“我们希望在做事方面变得更聪明。我们希望使用更少的资源，并且可以更明智地使用它们。这是一个真正的范式转变。” JPEG XS是TICO编解码器（SMPTE RDD 35）的进化，其本身基于JPEG2000。 TICO背后的比利时公司IntoPix也帮助设计了JPEG XS。IntoPix市场营销总监Jean-Baptiste Lorent认为，对于“当前使用未压缩视频”的工作流程来说，这将最为有用。 Lorent补充说：“由于分辨率提高，帧速率更高，360度捕获和更高质量的像素，因此我们需要新的编解码器来处理不断增加的数据量。” JPEG XS旨在解决需要低复杂度和低延迟，但可以使用相当高带宽的用例。Tony Jones说：“JPEG XS是一种内部编码技术。也就是说，它不执行时间预测。这实现了比AVC和HEVC等压缩标准低得多的效率，但反过来提供了非常低的延迟。” Jones补充道：“有很多潜在的专业用例，包括对延迟非常敏感，但仍然可访问高带宽的工作室，远程制作和其他用例。” 这可能适合4K和8K，尤其是制作和编辑，但其配置文件同时包括处理10K。Jones表示：“像JPEG XS这样的轻量级压缩技术是一种保证贷款，文件大小和文件传输时间的有效技术。JPEG XS对于维持低延迟远上也非常有用。” Jean-Baptiste Lorent则认为，这种低延迟，低压缩和高效率编解码器非常适合通过Wi-Fi和5G进行流式传输的视频，并且未来可以协助无人驾驶飞机和自动驾驶汽车。 为Adobe Premiere Pro CC开发了JPEG XS插件的Fraunhofer IIS指出，优化过的编解码十分适合需要通过有限带宽传输高图像质量数据，或者必须使用有限计算资源进行处理的用例。 JPEG XS很可能会在2018年年底之前获得国际标准化组织的批准，而包括相机在内的第一批产品也将在这之后的不久面世。 2. 全向VR  MPEG还致力于提供沉浸式媒体，如360度视频和VR。根据爱立信的Tony Jones的说法，这两种情况都存在非常严格的运动到光子要求：显示器对一切头部位置变化的响应速度必须非常低。 Jones指出：“对于360度视频，渲染是从整个360度图像或从其中适当大小的一部分进行本地执行，而对于VR，场景本身必须基于头部运动创建。如果可以在本地执行场景创建，挑战性将能大为降低。另一方面，如果渲染是远程执行，而且需要在没有过多比率需求的情况下实现，要实现这个目标将面临非常大的挑战。” 一个可能有帮助的倡议是MPEG-I。其内容正处于不同的发展阶段，定义系统，音频和视频参数的第一部分即将发布，而其他部分仍处于大纲之中。 MPEG-I最有趣的阶段是全向媒体格式（Omnidirectional Media Format，OMAF）。第一个版本的目标是HEVC中的360度视频压缩，而且现在已经完成。 Timmerer指出：“OMAF带来了一系列的优化，但可能需要一定的时间才能实现广泛采用，而它基本上将对编码，流媒体，解码和渲染产生重大的影响。” 将在10月份起草的第二版本（OMAFv2）把目标瞄准的3DoF+，这项包括“运动视差”的进展可以允许观众看到“对象的背后”。换句话说，OMAF正致力于实现潜在的全息显示器。 OMAF的后续版本还将针对“社交VR的全方位6自由度”，甚至“光场的密集表示”。Timmerer将社交VR描述为“用户可以在相同社交环境中消费VR内容”。 MPEG-I的其他方面则关于点云压缩。这种深度信息形式可用于生成三维或全息场景。 根据Timmerer的说法，VVC和OMAF之间没有关系，但未来可能会改变（也许到2020年）。他指出：“我预计OMAFv2将比VVC更早完成，因此OMAFv2仍将依靠HEVC。这是我目前的估计。” OMAF的第一版本将由ISO发布，但现在已经可以使用国际标准的最终草案。 “基本用例已经可以部署。我确信IBC中将出现一定的演示作品。” 3. 用于全息图的压缩  这里还有另外一层，一个关于压缩记录为光场的海量数据的方案。尽管都属于MPEG-I的一部分，但在解决方案上大家存在一定的分歧。 流式传输“真正本地的光场”需要500Gbps的宽带速度，最高可达1TBps。这个估计来自于全息显示器开发商Light Field Lab的CEO Jon Karafin。但他补充说：“这在我们有生之年都不会走进千家万户。” 处理如此多的数据需要十分严格的压缩标准，更不用说传输。MPEG的一个工作小组正在起草一种令“支持创建和渲染丰富沉浸式体验的内容交换”成为可能的解决方案。 它的名称是混合自然/合成场景数据容器（Hybrid Natural/Synthetic Scene；HNSS）。MPEG指出，HNSS应该提供一种手段来支持“遵循自然光流，能量传播和物理运动操作的场景”。 Timmerer表示该小组正在研究MPEG-I中的场景描述，“研究现有的格式和工具，以及它们是否可以用于MPEG-I。” 该方法不同于传统的视频压缩技术：其主要是捕捉纹理，几何图形和其他体三维数据，然后将其包裹在“媒体容器”中来创建场景的3D模型。 但不是每个人都相信媒体容器是正确的解决方案。麻省理工学院全息技术专家V. Michael Bove指出：“目前还没有普遍得到认同的最佳做法。我希望这个问题可以得到解决。这不是一个无法解决的问题。”
声明：晶品映像《gpimg.cn》所发布的内容均来源于互联网，目的在于传递信息，但不代表本站赞同其观点及立场，版权归 属原作者，如有侵权请联系删除。 |
