當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

Netflix媒体数据库：媒体时间线数据模型

發布時間：2024/4/11 数据库 38 豆豆

生活随笔收集整理的這篇文章主要介紹了 Netflix媒体数据库：媒体时间线数据模型小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

如何設計高效的視頻數據庫，Netflix的NMDB給出了答案。本文是系列文章的第二篇，感謝Hulu的小伙伴們的技術審校。

文 / Subbu Venkatrav, Arsen Kostenko, Shinjan Tiwary, Sreeram Chakrovorthy, Cyril Concolato, Rohit Puri and Yi Guo

譯 / 元寶

技術審校 / Hulu的小伙伴們

原文 https://medium.com/netflix-techblog/netflix-mediadatabase-media-timeline-data-model-4e657e6ffe93?source=collection_home---4------0---------------------

在本系列的前一篇文章中，我們描述了Netflix的一些重要業務需求以及被稱為“Netflix媒體數據庫(NMDB)”的媒體數據系統的特點。好奇的讀者可能已經注意到，這些特性中的大部分與NMDB管理的數據的屬性有關。具體地說，結構化數據是圍繞媒體時間軸的概念建模的，具有額外的空間屬性。這篇博客文章詳細介紹了NMDB使用的媒體時間線數據模型的結構，稱為“媒體文檔”。

媒體文檔模型

媒體文檔模型旨在成為一種靈活的框架，可用于表示各種媒體模態的靜態和動態（隨時間和空間變化）元數據。例如，我們希望能夠表示（1）具有29.97 fps NTSC幀速率的視頻文件的每一幀的顏色和亮度信息，（2）基于“媒體時間基線”單位來描述的時序文本文件中的字幕樣式和布局信息，以及（3）由VFX藝術家生成的時變3D模型的空間屬性，所有這些都要求時間和空間維度的完全精確性。

媒體文檔模型包羅萬象，它可以用來描述大量的文檔類型，包括描述視頻流編碼分析結果和VMAF分數的文檔、描述在多個時序文本流中同時發生的事件的信息的文檔、以及描述形成電影剪輯的一系列DPX圖像的結構化信息的文檔。為了滿足所有這些用例，媒體文檔圍繞以下詳述的一些核心原則構建。

時間模型

我們使用媒體文檔模型來描述媒體文件中的時序元數據。因此，我們主要圍繞時序事件的概念進行設計。時序事件可以描述本質上屬于“周期性”以及“基于事件”的時間線。圖1顯示了連續視頻幀的周期序列。在這種情況下，感興趣的事件是在第三幀之后發生了鏡頭更改事件。

圖1：跨越鏡頭變化的一系列視頻幀

對應于圖1的媒體文檔實例片段可以如下。

{
?…
?“events”: [
?{
? ?“startTime”: T0,
? ?“endTime”: T1,
? ?“metadata”: {
? ? ?“shotEnvironment”: “outdoors”
? ?}
?},
?{
? ? “startTime”: T1,
? ? “endTime”: T2,
? ? “metadata”: {
? ? ? “shotEnvironment”: “indoors”
? ? }
?},
?…
?]
…
}

時序事件類似于TTML（定時文本標記語言）字幕事件，但主要區別在于，在媒體文檔中，這些事件并不意味著向最終用戶顯示。更確切地說，這些事件是描述媒體文件中特定時間間隔內的元數據。在我們的模型中,我們選擇將給定的媒體文檔實例中的所有事件對應一個時間線，匹配媒體文件的時間線(我們想要指出,媒體文檔時間模型相當于SMIL規范中與par相關元素的時間線)。這個選擇背后的一個目標是促進時序查詢，既可以從一個文檔實例中查詢(獲取電影中從56秒到80秒之間發生的所有事件)，也可以從跨文檔實例中查詢(電影中從132秒到149秒之間的所有語言中是否有活動的字幕信息？)。?

圖2：與字幕事件對應的媒體時間線

在我們的模型中，每個事件在時間線上占用一個時間間隔。我們不會對事件的相關性做出任何假設。例如，在ISO基本媒體文件格式（BMFF）文件中，樣本可能不重疊并且在軌道內是連續的。但是，在媒體文檔模型中，事件可能會重疊。時間線中也可能存在間隙，即沒有事件的間隔。圖2顯示了基于事件的字幕時間線，其中一些間隔沒有事件。對應于圖2的媒體文檔實例片段可以如下。

{
???…
??“events”:?[
??{
????“startTime”:?T0,
????“endTime”:?T1,
????“metadata”:?{
??????“subtitle”:?“Hi?there!?How?are?you?”
????}
??},
??{
????“startTime”:?T2,
????“endTime”:?T3,
????“metadata”:?{
??????“subtitle”:?“Thanks?for?asking?—?i?am?good.?How?are?you?”
????}
??},
??{
????“startTime”:?T4,
????“endTime”:?T5,
????“metadata”:?{
??????“subtitle”:?“Very?well?—?thanks?a?lot!”
????}
??}
??]
…
}

空間模型

與時序模型一樣，媒體文檔與單個空間坐標空間相關聯，并且事件可以通過空間屬性進一步限定，提供事件在此坐標空間中發生的位置的詳細信息。這使我們能夠提供空間查詢（“獲取貫穿整個電影的媒體文件的這個區域中出現的所有事件”）或時空查詢（“獲取給定區域中在給定時間間隔內發生的所有事件“）。

圖3：一系列視頻幀，其中感興趣的空間區域隨時間變化

圖3顯示了由兩個時間事件組成的視頻時間軸的可視化，這兩個時間事件由鏡頭變化分開。在每個時間事件內，不同的空間區域（對應于人臉并用彩色矩形示出）形成感興趣的區域。在本節的末尾描述了與此媒體時間線對應的完整媒體文檔實例。

嵌套結構

受行業領先的媒體容器格式（例如SMPTE可互操作主格式（IMF）或ISO BMFF）的啟發，媒體文檔模型將具有類似屬性的事件分組。可以使用兩種嵌套級別的分組：軌道和組件。我們的模型是靈活的：在時間線上同屬于某個公共間隔的兩個事件可以放置在同一軌道的同一組件中，也可以放置在同一軌道的兩個不同組件中，還可以放置在不同軌道的各自組件中。

組件和軌道的語義可以由媒體文檔實例的作者自由定義。對于一個典型的多媒體文件的實例，媒體文檔實例會對媒體文件中的每個媒體模態都會創建一個軌道元素，比如說，對于一個同時包含了音頻和視頻的文件，媒體文檔實例就會創建兩個軌道來描述。在圖4中展示了如何描述一個包含了音頻、視頻和文本模態的文件。

圖4：包括多個軌道的媒體時間線

如上所述，對應于圖4的媒體文檔實例片段可以如下。

{
??...
??"tracks":?[
??{
????"id":?"1",
????"metadata":?{"type":?"video"},
????...
??},
??{
????"id":?"2",
????"metadata":?{"type":?"audio"},
????...
??},
??{
????"id":?"3",
????"metadata":?{"type":?"text"},
????...
??}
]
}

或者，對于多聲道音頻文件，媒體文檔實例可以描述成一個軌道，但在軌道內，單獨的組件元素將為每個通道提供元數據和事件來描述它，如圖5所示。

圖5：顯示屬于單個軌道的多個組件的媒體時間軸

對應于圖5的媒體文檔片段可以如下。

{
??...
??"tracks":?[
??{
????"id":?"1",
????"metadata":?{"type":?"stereo?audio"},
????"components":?[
????{
??????"id":?"0",
??????"metadata":?{"channel":?"left"},
??????...
????},
????{
??????"id":?"1",
??????"metadata":?{"channel":?"right"},
??????...
????},
????]
??}
??]
}

媒體文檔的整體嵌套結構如圖6所示。每個級別都要求作者指定所有媒體文檔實例的共同（必需）信息（每個級別的id、組件級別的時間和空間解析單元、事件級別的時間間隔信息、區域級別的空間信息）。此外，每個級別允許作者提供特定于每個級別的每個媒體文檔類型的元數據（例如，事件級別的每個幀的VMAF分數或文檔級別的平均值，或者組件或軌道級別的音頻的響度信息）。

圖6：媒體文檔的數據結構層次結構

雖然媒體文檔實例可以用任何流行的序列化格式表示，例如JSON，Google Protocol Buffers或XML，但我們使用JSON作為首選格式。這在一定程度上源于不同web系統之間通常使用JSON作為有效負載格式。更重要的是，許多流行的分布式文檔索引數據庫，如Elasticsearch和MongoDB使用JSON文檔。選擇JSON作為我們的序列化格式，可以使用任何這些可伸縮文檔數據庫來索引媒體文檔實例。值得一提的是，對事件級時間間隔信息以及區域級空間信息的索引提供了開箱即用的時空查詢能力。

以下示例顯示了一個完整的媒體文檔實例，該實例通過圖3所示的視頻序列的時間軸表示人臉檢測元數據。所討論的視頻序列是高清視頻序列（1920x1080空間分辨率），幀率為23.976幀每秒。它包括兩個不同的時間事件。每一個事件都包含單個感興趣的空間區域，對應于檢測到的人臉矩形邊界框。

{
??"metadata":{
????"algorithm":?"video_face_detection"
??},
??"tracks":?[
??{
????"id":?0,
????"components":?[
????{
??????"id":?0,
??????"eventRateNumerator":?24000,
??????"eventRateDenominator":?1001,
??????"xSize":?1920,
??????"ySize":?1080,
??????"events":?[
??????{
????????"startTime":?0,
????????"endTime":?2,
????????"regions":?[
????????{
??????????"xmin":?1152,
??????????"xmax":?1536,
??????????"ymin":?108,
??????????"ymax":?648
????????}
????????]
??????},
??????{
????????"startTime":?3,
????????"endTime":?4,
????????"regions":?[
????????{
??????????"xmin":?576,
??????????"xmax":?960,
??????????"ymin":?108,
??????????"ymax":?648
????????}
????????]
??????}
??????]
????}
????]
??}
??]
}

媒體文檔架構

前面的段落介紹了媒體文檔模型的基本原理。媒體文檔對象廣泛用于各種Netflix媒體處理工作流程中。以下是一個典型的生命周期：

運行在如Archer的平臺上的媒體處理算法產生出特定類型的媒體文檔實例，其中元數據部分包含特定域的元數據（例如，視頻幀中文本的邊界框）;

媒體文檔實例被攝取，持久化并索引到NMDB中;

NMDB用戶查詢具有類似特征的一組特定媒體文檔實例。通常，這些是具有額外特定域特征的時空查詢（例如“在屏幕中間查找所有出現的文本”）

特定域的API用于向下游用戶公開特定的媒體文檔實例。

if?(property1?instanceOf?String)?{
??…
}?else?if?(property1?instanceOf?Integer)?{
????…
}?else?if?(property1?instanceOf?Boolean)?{
??…
??if?(property2?instanceOf?Double)?{
????…
??}?else?if?(property2?instanceOf?List)?{
????…
??}
…
}

為了在Netflix規模上維持這個生命周期，我們意識到有必要采用一種“寫入模式”的方法。在此方法中，每個媒體文檔類型都會與對應模式相關聯。提交給NMDB的特定類型的所有媒體文檔實例都會被為該類型定義的模式進行驗證。如果媒體文檔實例不符合驗證規則，則會被拒絕。更具體地說，我們決定使用JSON Schema語法的子集來表達我們的驗證規則。因此，首先會要求媒體文檔實例的生產者提供描述相關媒體文檔類型結構的JSON Schema。這種方法帶來了幾個好處：

我們可以確保與域關聯的所有媒體文檔實例的結構類似。這允許我們編寫特定域的查詢并獲得一致的結果。例如，如果表示字幕內容的所有媒體文檔實例遵循相同的結構（例如，TTML body元素包含一個div元素，這個div元素包含p元素，p元素潛在包含幾個span元素），它可以使用一個請求查詢所有使用ruby注釋的TTML事件，這個查詢可以運行在一個媒體文檔實例里或對應域里的全部集合里。

我們可以確保對于相同的媒體文檔類型，文檔樹中給定位置的給定名稱的屬性是精確類型而不是通用字符串。例如，這使得能夠將本質上為數字的屬性的類型強制為數字類型。然后，可以對該屬性進行范圍查詢（具體來說，我們已經仔細選擇了JSON模式的子集，以確保沒有元素可以具有不明確的定義或允許不兼容的解釋，即，每個對象都被指定為其原始類型，包括字符串，布爾值，數字和整數）。在沒有模式的情況下，讀取媒體文檔實例可能會降級為類似下面的偽代碼。從軟件角度來看，這樣的實現難以維護，并且導致較低的讀取性能。

我們可以自動提供強類型API，以支持使用特定類型的媒體文檔實例。NMDB的用戶不必編寫代碼來解析媒體文檔實例，并且提供了強類型代碼來處理它們并提出特定于域的API。

此外，由于開發人員需要在他們的媒體文檔定義中保持靈活性，并且隨著時間發展，常常需要逐步演化其特定域的元數據，或更廣泛地演化特定域的媒體文檔類型，因此我們允許更新媒體文檔模式。但是，為了保留上述優點，我們對模式的更新進行了限制，只允許增加或更新可選字段。這可確保媒體文檔實例與媒體文檔讀取器之間的前向和后向兼容性，同時保持媒體文檔實例索引和查詢的穩定性。簡而言之，這種設計選擇既讓NMDB系統易于推廣，也讓我們在運營NMBD時保持了可擴展性。最后，當必要的更新無法和現有模式相兼容時，也可以創建新的媒體文檔類型。

下一步計劃

在下一篇博文中，我們將深入探討NMDB系統的實現。我們將討論我們的設計選擇，以實現Netflix業務需求產生的服務可用性和服務規模要求。

精品文章推薦

技術趨勢：

UDP成為低延時流媒體關鍵選SRT還是QUIC？
BBR如何讓Spotify流媒體更流暢？
CMAF將在2019年得到快速發展
YouTube高效傳輸策略：節省14%帶寬用戶體驗提升

人物專訪：

Akamai首席架構師Will：WebRTC、QUIC、DASH、AV1都前景可觀
馬思偉：視頻領域是個海洋，可以游泳、沖浪、潛水和遠航
劉文峰：讓科技成就藝術創意
張睿：OpenH264擁有產品級的魯棒性歡迎contribute
時永方：做到這三點，你就是多媒體內行了

總結

以上是生活随笔為你收集整理的Netflix媒体数据库：媒体时间线数据模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：基于HLS格式的低延时互动直播技术
下一篇：音视频技术开发周刊 74期