媒體分發和管理平臺的制作方法
【專利說明】媒體分發和管理平臺
【背景技術】
[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)相似的目的：任何將來變換獲益于較