写点什么

电影行业提升 DCP 传输效率,还能这样做!

  • 2020-03-19
  • 本文字数:1781 字

    阅读完需:约 6 分钟

电影行业提升 DCP 传输效率,还能这样做!

一、背景

DCP 全拼是 Digital Cinema Package,中文是数字电影包,用于存储和转换数字影像的音频、图像和数据流,是影院放映设备使用的媒体文件包。一部普通 2D 电影的 DCP 大小一般在 40G~60G 之间,一部普通 3D 电影要乘以 2 倍,如果是 IMAX 或者 4k 的电影,DCP 的大小达到 200G 以上也是正常的。


本文揭秘超过 200G 的超大数字电影包如何高效通过 TMS 传输到各个影厅。


现在影院拷贝 DCP 到各影厅的方式主要是使用 TMS(影院放映管理系统)的传输影片功能,由 TMS 负责把 DCP 传输到各个影厅,但是这种传输的效率不高,数据源只有 TMS,所以各影厅拷贝影片都要到 TMS 上拉取,带宽就成为了瓶颈。



(图 1 目前使用 TMS 向播放服务器传输 DCP 的模式)

二、使用类 P2P 方式传输

从图 1 可以看出,影厅的播放服务器拉取 DCP 后,它们的带宽就处于空闲状态,那么我们完全可以使用类似于 P2P(对等网络传输)传输方式解决,这样就可以用现有设施提高影院内 DCP 的分发效率,起到降本提效的效果。



(图 2 P2P 示意图)


根据上面的 P2P 方式,改造影院内传输 DCP 的模型:



(图 3 改进后的 TMS 向播放服务器传输 DCP 的模式)


上图主要叙述的是传输协调器协调各个影厅寻找传输源拉取 DCP 的过程。本改进方案的特点是增加了一个传输协调器作为共享状态机,协调各影厅拷贝 DCP 的路径,计算出传输路径最优解。传输协调器的核心功能是:


1)收集各厅播放服务器网络情况;


2)标记 DCP 在各厅播放服务器的存储情况;


3)根据网络情况,计算并派发传输任务到各厅播放服务器。


而且使用了本方案的传输方式,传输效率会有极大的提升。例如有一个 DCP 的文件总大小为 400GB,总共 10 个影厅,带宽为 1000Mbps≈125MB/s,那么使用传统 TMS 传输方式,起码要 400×1024×10÷125÷60÷60=9.10 小时,差不多一个工作日的时间。而如果使用新方式,仅需要 3 小时,可以提升 3 倍,而且随着影厅的增多,效率提升指数增加。

三、进一步改进方案

由图 3 了解到,虽然上述方案把带宽浪费的问题解决了,但是架构上还有一些问题:传输协调器就是一个单点,它挂了,传输就出问题了;数据只能有一个数据来源,来源挂了,传输就停止了,而且重新传输要从头开始。这时候我们要如何解决?


这两个问题可以使用传输协调器去中心化部署及文件分片断点续传方式下载解决:


1.传输协调器去中心化部署


我们可以把传输协调器部署到各个影厅,每个传输协调器是一个几乎无状态节点,节点之间无任何信息同步,每当一个影厅的 DCP 传输完成后,就广播到各个传输协调器中。但发送拷贝指令的方式就需要改造一下,由 TMS 统一发送下载影片的指令到各个影厅的传输协调器,然后传输协调器就负责询问邻近节点是否有可下载的 DCP,存在则下载,不再需要 TMS 的传输协调器为影厅指定下载地址。新的网络拓扑图如下:



(图 4 进一步改进后的网络拓补图)


2.文件分片断点续传方式下载 DCP


上一节的方案中,拷贝 DCP 还是使用播放服务器原生指令操作的,限制很大,不支持多数据源及文件分片操作。既然播放服务器不支持,那么我们就需要自己开发一个中介角色,需要支持多数据源及文件分片操作,并且具备拷贝 DCP 到播放服务器硬盘的能力,而部署在影厅的传输协调器恰好可以承担这个职责。多数据源及文件分片方案示意图如下:



(图 5 多数据源及文件分片方案示意图)


上述两种技术方案可以合并使用。


小结:虽然这种方式并不能提升多大的速度,但是在系统容错性方面有所提升,用户体验更好了。

四、总结

通过上述章节可以看出,我们通过将 P2P、FTP、断点续传、文件分片等技术的融合,产生了一个专用于局域网传输 DCP 的技术方案。我们借鉴 P2P 的思想,实现了影厅的片源在局域网内共享的效果,克服了传统 TMS 传输 DCP 单数据源的缺点;使用 FTP 作为传输手段,兼容现有影厅的传输模式;使用断点续传、文件分片提升系统的容错性。


这个方案其实是很典型的组合创新法,用的技术都是已有并且是很经典的,但通过将它们重新梳理整合,使其在性能上发生质的变化,以产生出新的价值。本文的方案正是使用这种方法诞生的,在设计这个方案的过程中,我也学会了组合创新法的一些皮毛,以后还要继续努力学习这种方法。


作者介绍


阿里文娱开发工程师 雨衡


相关阅读


电影垂直行业的云智开放平台如何炼成?


阿里工程师带你了解 B 端垂类营销中心如何设计?


云智前端技术如何赋能场馆院线?


60 秒售出 5 万张票!电影节抢票技术揭秘


2020-03-19 10:001482

评论

发布
暂无评论
发现更多内容

深入了解 Spring篇之BeanDefinition结构

邱学喆

对象初始化 BeanDefinition 对象创建 属性注入 对象检索

C++对象模型和this指针实例分析(二)

CtrlX

c++ 后端 面向对象思想 热门活动 8月月更

基于消息中间件开发的优点

阿泽🧸

消息中间件 8月月更

高层次综合(HLS)

贾献华

8月月更

Shell脚本中常用命令复习

Albert Edison

Linux centos 运维 shell脚本编程 8月月更

「控制反转」和「依赖倒置」,傻傻分不清楚?

蝉沐风

ioc 依赖倒置原则 DIP DI 控制反转

3 款非常实用的 Node.js 版本管理工具

Geek_z9ygea

JavaScript node.js 前端

提升领导力的有效方法

宇宙之一粟

领导力 8月月更

MPLS网络向SRv6网络演进

穿过生命散发芬芳

8月月更 SRv6

部署spark2.2集群(standalone模式)

程序员欣宸

spark 8月月更

测试也应该具备的项目管理能力

老张

项目管理 质量保障

用户权限-Linux系统ACL控制

Albert Edison

Linux centos 运维 服务器 8月月更

《MySQL入门很轻松》第2章:MySQL管理工具介绍

乌龟哥哥

8月月更

开源一夏|Flutter实现搜索的三种方式

坚果

开源 OpenHarmony 8月月更

rocketmq整合SpringCloudStream

急需上岸的小谢

8月月更

Sass.vs.Less | 简介

Jason199

SaaS 8月月更

阿里云云原生加速器企业硬之城携手阿里云 Serverless 应用引擎(SAE)打造低代码平台

阿里巴巴云原生

阿里云 Serverless 云原生 合作伙伴

Python爬虫eval混淆,爬虫进阶实战系列

梦想橡皮擦

Python 爬虫 8月月更

Ingress Nginx 接连披露高危安全漏洞,是否有更好的选择?

阿里巴巴云原生

阿里云 Kubernetes 云原生 ingress

生于云、长于云,RocketMQ 5.0 再出发

阿里巴巴云原生

阿里云 RocketMQ 云原生 消息队列

头脑风暴:除数博弈

HelloWorld杰少

8月月更

2022秋招前端面试题(六)(附答案)

helloworld1024fd

前端面试题

云原生时代下,微服务体系与 Serverless 架构的发展、治理与融合

阿里巴巴云原生

阿里云 Serverless 微服务 云原生

梦回战国,领略两千多年前公孙龙如何将面向对象运用得炉火纯青

迷彩

Java 面向对象 签约计划第三季 8月月更 面向过程编程

2022秋招前端面试题(五)(附答案)

helloworld1024fd

前端面试题

图数据科学和机器学习图数据科学GDS概览

flow

8月月更

结合实际聊聊防反接电路(防反接电路总结)

矜辰所致

防反接电路设计 8月月更

数据治理(三):数据质量管理

Lansonli

大数据 数据治理 8月月更

电影行业提升 DCP 传输效率,还能这样做!_文化 & 方法_阿里巴巴文娱技术_InfoQ精选文章