動態傳遞內嵌優先順序佇列

本主題說明如何使用優先級設置來優化高優先級視頻的攝取時間。

簡介

Dynamic Delivery Ingest 現在有一個名為優先排隊允許發布者以所需的優先級設置向我們提交攝取作業,以影響處理作業的順序和及時性。

動態傳遞攝取隊列如何工作

如果使用普通優先級隊列,則動態交付接收每個帳戶最多只能有100個活動作業。當超過該限制時,提取系統會將其他請求排入隊列,以便以後處理。隊列的大小有一個單獨的限制,當達到該限制時,它將拒絕接收請求(返回429錯誤代碼)給客戶。作業完成後,容量將被釋放,排隊的作業將一次被接收並按接收順序處理。

中的視頻狀態CMS API不反映作業已排隊 - 狀態將為pending 作業是正在處理還是正在排隊。

優先隊列如何影響攝取

優先排隊允許用戶添加一個priority 標記為攝取請求。的允許值priority low normal .任何其他值都將導致請求被拒絕,並帶有422錯誤代碼。當用戶不指定任何優先級時,默認值為normal 用來。這是優先隊列如何更改如何從隊列處理作業的簡要說明:

  1. 如果沒有排隊的作業,並且有運行作業的能力,則該作業將立即運行。這適用於低優先級作業和普通優先級作業。
  2. 如果沒有容量可以運行其他作業,則將該作業排隊。
  3. 如果隊列中有作業,則所有新作業也將排隊。這意味著新作業無法在排隊的作業之前開始。
  4. 當有能力運行另一個作業並且有排隊的作業時,將從隊列中取出一個作業:
    • 如果隊列中有任何普通優先級作業,則將選擇最早的普通優先級作業。
    • 如果隊列中沒有正常優先級的作業,則將選擇最早的低優先級作業。
  5. 正常和低優先級作業被視為相同的可以有多少個正在運行的作業。無論優先級如何,每個帳戶處理的作業總數不得超過100個。
  6. 分離可以排隊的正常和低優先級作業的配額。
  7. 在任何給定時間,每個帳戶都限制在低優先級隊列中的 1000 個待處理作業。
  8. 在任何給定時間,每個帳戶在正常優先級隊列中都限制為 1000 個待處理作業。

要注意什麼

提交工作後,翻譯詳細信息已更改

創建動態攝取作業時,指定的攝取配置文件由動態攝取系統複製,並且該配置文件複製將用於處理,即使自提交作業以來配置文件已被修改。

對於低優先級作業,在某些情況下處理可能會延遲很長時間,可以修改該配置文件中指定的再現在實際處理作業之前。如果發生這種情況,用於處理視頻的再現將是新的這些演繹的定義;不是提交作業時再現的定義。

如果你想保證你得到演繹因為它們是在提交作業時指定的,您應該製作演繹版的副本並創建一個引用這些複製的演繹版的新配置文件,然後開始攝取過程。(如果視頻已經放入Video Cloud中,則可以使用更新後的配置文件對視頻進行重新轉碼。請記住,在完成對原始作業的處理之前,您無法對視頻進行重新轉碼。)

來源檔案上傳

上傳源文件會在24小時後刪除該S3存儲桶中的文件。由於在某些情況下,低優先級作業的處理時間可能不會超過24小時,因此文件可能已被刪除,在這種情況下,處理將失敗。我們不建議低優先級攝取源文件

樣品要求

以下是優先級較低的攝取請求主體的示例:

    {
    "master": {
    "url": "https://host/master.mp4"
    },
    "profile": "multi-platform-extended-static",
    "priority": "low",
    "callbacks": [
    "https://mydomain.com/di-callbacks.php"
    ]
    }
    
    

以下是正常優先級工作的示例:

    {
    "master": {
    "url": "https://host/master.mp4"
    },
    "profile": "multi-platform-extended-static",
    "priority": "normal",
    "callbacks": [
    "https://mydomain.com/di-callbacks.php"
    ]
    }
    
    

請注意,因為normal 是默認值,前一個請求將以與以下請求完全相同的方式處理:

    {
    "master": {
    "url": "https://host/master.mp4"
    },
    "profile": "multi-platform-extended-static",
    "callbacks": [
    "https://mydomain.com/di-callbacks.php"
    ]
    }
    
    

使用優先級隊列

從上一節的最後一個例子可以清楚地看出,如果你這樣做不是使用priority 在您的攝取作業中,它們將繼續像以前一樣被處理。

添加的priority 如果出現以下情況,該領域將主要使您受益:

  1. 您攝取了大量的視頻
  2. 獲得至關重要一些盡快在線發布您的視頻,同時不急於發布其他視頻(因為內容不那麼重要,或者您不打算立即發布視頻)
  3. 您有要重新轉碼的視頻,但又不想減慢新內容的提取速度

低優先級隊列如何工作

本節說明低優先級隊列的工作方式。

無法保證何時啟動普通或低優先級作業。但是,正常優先級的作業將始終在低優先級的作業之前啟動。

如果您以穩定,快速的速度提交正常優先級的作業,則啟動低優先級的作業可能需要花費大量時間。

與同一視頻的正常優先級相比,低優先級的作業可能要花更長的時間啟動並且也需要更長的處理時間。