媒体分发和管理平台的制作方法
【专利说明】媒体分发和管理平台
【背景技术】
[0001] 分发平台（例如，YouTube饭、NetfHX?和iTuneSI露）的成功已经使视频内 容的消费更加简单。但是，产生、分发和/或管理那些内容仍然是复杂的过程。同时，视频 的普遍存在要求组织结合（或加强）视频策略，W便使用社交网络、移动装置等来利用新出 现的观众。与不断多变的技术要求相结合，成功地创建和传递视频的过程要求对现有品牌 和相似的新来者的人和技术的投资。管理视频"生命周期"是复杂的。
【附图说明】
[0002] 通过所附权利要求书、一个或多个示例实施例的W下详细描述和对应附图，本发 明的实施例的特征和优点将变得显而易见，附图包括： 图1包括本发明的实施例的发布工作流程图； 图2包括本发明的实施例的更新工作流程图； 图3包括本发明的实施例的撤消发布工作流程图； 图4包括本发明的实施例的统计采集工作流程图； 图5包括本发明的实施例的更详细的授权工作流程图； 图6包括本发明的实施例的更详细的元数据验证工作流程图； 图7包括本发明的实施例的更详细的转码工作流程图； 图8包括本发明的实施例的更详细的传输工作流程图； 图9包括本发明的实施例中的图形用户界面（GUI); 图10包括本发明的实施例的分发工作流程图；W及 图11包括用于实现本发明的实施例的系统。
【具体实施方式】
[0003] 在W下描述中，提出许多具体细节，但是即使没有运些具体细节也可实施本发明 的实施例。没有详细示出众所周知的电路、结构和技术，W免影响对本描述的理解。"实施 例"、"各个实施例"等表示运样描述的实施例可包括特定特征、结构或特性，但是并不一定 每一个实施例都包括所述特定特征、结构或特性。一些实施例可具有部分、全部或者没有对 于其它实施例所述的特征。"第一"、"第二"、"第等描述共同对象，并且表示设及相似对 象的不同实例。运种形容词不是暗示运样描述的对象必须按照给定顺序，无论是时间、空间 上、按照等级还是按照任何其它方式。"连接"可表示元素相互进行直接物理或电接触，W及 "禪合"可表示元素相互协作或者交互，但是它们可W或者可W不进行直接物理或电接触。 另外，虽然相似或相同标号可在不同附图中用于标明相同或相似部件，但是运样做并不表 示包括相似或相同标号的所有附图构成单个或者相同实施例。本文中，描述有时同时涵盖 若干不同附图。为了清楚起见，附图包括组件，其中最高有效值表示包括该组件的附图（例 如元素3XX会在图3被找到，W及元素4XX会在图4被找到）。
[0004] 本发明的实施例简化"视频生命周期"等的管理。实施例包括一个或多个模块，其 通过抽象诸如视频发布、更新视频、撤消发布视频、与视频有关的检索或统计、处理视频的 授权、视频的验证、视频元数据处理、视频转码和/或视频传输之类的技术步骤来流线化视 频发布过程。 阳(K)日]视频生命周期
[0006] 从本发明的实施例的观点来看，视频生命周期设及至少四个过程：发布、更新、撤 消发布和统计检索。所有运些过程与一个或多个"目的地"一前一后地进行：分发平台，其 允许先前过程的某种组合。（例如，一些目的地仅支持发布和撤消发布，但不报告统计或者 允许最终用户更新视频。）实施例允许用户在开始过程之一之前、一旦过程已经发起、或者 两者、授权一个或多个目的地。
[0007] 发布过程在"视频文件"是可用的时刻开始。运个文件可与下列项同样简单：来自 照相装置的未编辑的剪辑或成品、要求来自合作者或客户的批准的完成的编辑、准备好分 发的最终版本或者中间阶段的任一个。
[0008] 客户端应用或最终用户可按照多种方式将视频文件提供给本发明的实施例：它可 经由诸如硬盘驱动器、DVD-ROM或磁带格式之类的物理存储介质来传递。备选地，它能够通 过网络经由HTTP或其它网络协议、例如FTP来传递。最后，如果本实施例具有对文件的本 地访问权，则可提供本地文件路径。
[0009] 在运点上，在实施例中，视频按照个别的目标平台来封装。对于最终用户选择的各 目的地，实施例可确定适当的后续步骤。视频可要求转码到一个或多个所需格式。视频文 件可要求经由网络（例如，文件传输协议（FTP)、内容传递网络（CDN)、应用程序接口（API) 等）的传递。最后，最终目的地可被装载有最终提供者所要求的各种转换中的视频元数据。 运个过程要求密切注意变化的API要求、视频支持差距和网络故障。
[0010] 一旦向一个或多个目标平台发布了视频，元数据和视频文件本身两者均可适合更 新。例如，如果最终用户决定改变视频的标题，则实施例重新封装元数据，并且经由传递规 范将它重新提交。本实施例可管理可更新各目标平台的资源的列表，其基于最终用户的账 户类型可W是可变的。
[0011] 许多目标平台跟踪与视频和用户交互有关的统计。例如，每一次视频被播放， 丫OiiTube忠增加"观看"计数。运些目的地的一些包括一种用于检索运些统计（例如，API 或月报）的方法。在运类情况下，实施例可检索那些统计，并且标准化跨目的地的值，使得 实施例的最终用户能够比较用户交互，并且确定哪些目的地表现良好（或不良）。特定度量 的重要性可取决于各用户对成功的解释。
[0012] 最终，视频可要求从目标平台中去除（无论是因内容中的错误还是简单地不再相 干）。实施例可支持从支持它的任何目的地中去除（或者"撤消发布"）视频。
[0013] 视频可要求存档。用户可期望保存最高可能的视频质量，使得任何将来的分发不 会因先前技术的限制而受损。例如，第一代Apple瑕的"AppleTV?"产品仅支持垂直分辨 率为702像素（称作720巧的渐进视频。但是，AppleTV⑧的最近版本支持高达1080像素 (称作1080巧的分辨率。通过存储原始视频质量，实施例确保在将来也能够传递最高质量。
[0014] 系统摘要
[0015] 实施例抽象各种基础系统。如采用App 1 eTV坂示例所提到，视频传递要求频繁地 发生变化。五年前是主流的格式和标准在将来可能不太相干（例如，FLV、Flash、RTMP)，W及分发格式和平台频繁地出现（例如，MPEGDA甜、化S、OTT等）。因此，实施例提供抽象资 源（例如，"视频"或"目的地"）的系统两者，其使最终用户能够易于执行简化操作（例如 "发布"或"更新"），而无需知道基础系统要求。例如，实施例可将隐藏转码视频文件（将一 个视频重新压缩或重新封装为另一个）选择作为发布或更新视频的"隐式"部分。
[0016] 实施例相当于资源的分离接口，其简化从存储层（其例如可W平衡技术，例如云 存储、FTP传递、CDN等）到发布层（其可抽象所有所支持的平台要求、API并且将细节转 码为目的地的并行系列）到统计层（其可合计来自各平台的观众度量）的视频生命周期。 运个抽象可通过图形应用使最终用户成为表面或者利用网络技术、例如基于HTTP的REST API使客户端应用的程序接口成为表面。
[0017] 发布工作流程
[0018] 图1包括本发明的实施例中用于向目的地发布视频的过程工作流程。在框100,最 终用户（或API的客户端应用）向实施例提供视频文件。运个文件可W是高质量主文件， 其必须经过转码W供目的地使用。最终用户可通过对客户端应用的本地访问、经由诸如基 于HTTP的API或FTP之类的网络协议、或者甚至数字磁带格式来提供文件。
[0019] 在框101，实施例确定视频的（一个或多个）特性。例如，实施例从上传视频中提 取并存储信息到数据库或者另一基于文件的存储系统中。运个信息可设及从例如并且非限 制性地包括下列项的组中选取的特性：文件类型（例如MPEG-4Part14容器）、视频编解码 器（例如H. 264/AVC、MPEG2等）、视频编解码器简档（例如主要（Main)、基准度aseline) 等）、音频编解码器（例如MP3、PCM等）、视频持续时间、视频分辨率、帖率、视频压缩比特 率、音频压缩比特率W及用于发布和其它过程所需的其它信息。
[0020] 在框102,实施例可提示最终用户或客户端应用关于发布中将要使用的一个或多 个目的地。在客户端应用中，运可W是一个或多个图形用户界面工作流程，其中用户可"点 击"或者W其它方式指示一个或多个期望的目的地。在框103,所选的各目的地的发布要求 可从数据库、配置文件、外部API或其它适当的位置采集。运些要求可包括但不限于（一个 或多个）转码格式、元数据要求、认证要求等。
[0021] 框104-107确定所选（一个或多个）目的地是否被授权。如果一个或多个目的地 未经授权并且能够被授权，则利用授权过程。过程104确定目的地当前是否被授权，运可包 括针对外部API验证凭证、通过从数据库中提取信息来检验所调度认证任务的结果或者由 目的地的能力所确定的其它方法。过程105解析过程104的结果，并且确保最终用户或客 户端应用能够授权（例如，外部目的地的认证服务进行响应、应用极限尚未达到等）。（参 见授权工作流程W获得过程106的更多细节。）在框107,检验授权的结果：如果授权过程 是成功的，则实施例可继续进行到框108。否则，实施例可能未达成请求，或者提示最终用户 或客户端应用再次尝试授权。
[0022] 框108确保已经提供和验证了视频（均在框101采集并且从最终用户或客户端应 用采集）的元数据。（参见验证工作流程W获得更多细节。）运个步骤所需的元数据要求 从框103来采集。一旦对各视频和目的地组合验证了元数据，其准备好用于传输。
[0023] 框109封装最终目的地所要求的任何转码。一些目的地支持多样的输入视频文 件（例如YouTube瑕），而其它目的地要求特定容器格式、视频和音频编解码器、分辨率 和视频压缩的其它方面。例如，HuUi懲当前要求MPEG-2程序流文件，其包括皿素材的 30-50MbpsMPEG-2视频流。如果用户或客户端应用提供不匹配一个或多个目的地的转码要 求的视频文件，则可在进行到传输之前生成附加转码。（参见转码工作流程W获得更多细 节。）在转码之后，可存储所产生文件供将来使用W及传输。
[0024] 一旦已经生成了（一个或多个）适当转码，实施例可采用框110-115从最终用户 或客户端应用请求任何附加所需文件。一些目的地要求补充文件，包括但不限于缩略图像、 备选语言音频流或文档。框110检查在框103所采集的目的地要求，并且确定任何附加文 件是否是必要的。另外，实施例可W能够生成某些所需附加文件而无需提示用户。
[00巧]如果用户或客户端应用必须提供（一个或多个）文件，则框111设及采用图形界 面提示用户或者具有用于提供所需文件的方法提示客户端应用。一旦实施例有权访问附加 文件，则它可分析和存储它们（框112)供存档和变换。存储原始文件用于与存储高质量视 频原版（videomaster)相似的目的：任何将来变换获益于较