選擇經(jīng)由通信網(wǎng)絡傳送的多媒體內(nèi)容的片段的代表的方法
【技術領域】
[0001] 本發(fā)明涉及一種用于選擇經(jīng)由通信網(wǎng)絡傳送的多媒體內(nèi)容的片段的代表的方法。
[0002] 多媒體內(nèi)容旨在于指任何音頻或視頻內(nèi)容，或者更寬泛來說指任何其他數(shù)字內(nèi) 容。
[0003] 本發(fā)明尤其涉及經(jīng)由網(wǎng)絡傳送和接收多媒體內(nèi)容，尤其是經(jīng)由網(wǎng)絡連續(xù)下載，即 所謂的流傳輸多媒體內(nèi)容。
[0004] 其更確切而言涉及利用內(nèi)容的通用地址進行通信。
[0005] 其尤其適用于能夠經(jīng)由電信網(wǎng)絡進行通信以經(jīng)由通用地址，即所謂的URI (表示 Uniform Resource Identifier，統(tǒng)一資源標示符）訪問多媒體內(nèi)容的任何客戶終端（此后 簡稱為終端）。
[0006] 內(nèi)容的代表在此旨在于指創(chuàng)建代表內(nèi)容的數(shù)據(jù)流的一種特定方式。以某個編碼比 特率創(chuàng)建的數(shù)據(jù)流是該內(nèi)容的特定代表的一個示例。
【背景技術】
[0007] 為了訪問多媒體內(nèi)容，客戶終端通常利用通用地址，或URI。這種地址提供了在同 一時間對于內(nèi)容和與用于消費其（消費理解為例如在視頻內(nèi)容的情況下，下載/接收該內(nèi) 容，和之后可選地解碼和觀看其）的相關聯(lián)的協(xié)議有關的指示的訪問。
[0008] URI地址是標識物理或抽象資源的字符串。URI地址的語法遵從由IETF (Internet Engineering Task Force，國際互聯(lián)網(wǎng)工程任務組）頒布的一組標準，并且尤其遵從規(guī)范 RFC3986(規(guī)范：通用資源標識符（URI):泛型語法）。諸如此的通用地址將采取例如dvb:// contentl、rtsp://content2、HTTP: //content3、ftp://content4 等的形式。
[0009] 對多媒體內(nèi)容的訪問由請求經(jīng)由URI地址觸發(fā)。其常規(guī)表現(xiàn)是點播視頻服務：
[0010] -第一步驟，對于終端在于經(jīng)由 HTTP 協(xié)議（Hyper Text Transport Protocol 超文本傳輸協(xié)議）下載描述了用于對該服務的訪問的參數(shù)的文件（SDP，代表Session Description Protocol，會話描述協(xié)議），HTTP協(xié)議是為因特網(wǎng)，尤其是網(wǎng)絡而開發(fā)的客戶 端服務器通信協(xié)議；
[0011]-在第二步驟期間，服務實際上開始，也就是說，客戶終端可以借助所述文件（在 該示例中是SDP)中提供的信息接收和顯示視頻。將注意到的是，該文件可以是描述在特定 地址可以訪問的內(nèi)容的計算機文檔或者一組信息。
[0012] 此后，將根據(jù)上下文而采用表述"描述文檔"或"文件"。將注意到的是，該類型的 對服務的訪問可以要求（尤其在點對點或者"單播"通信的情況下）或者不要求（在"廣 播"或"多播"類型的一點對多點通信的情況下）服務器的存在。尤其，HTTP協(xié)議是點對點 ("單播"）類型的，并且因此涉及服務器的存在以便處理客戶端，所謂的HTTP客戶端的請 求。
[0013] 在該HTTP協(xié)議的上下文中常常為了在客戶端和服務器之間交換數(shù)據(jù)而訴諸 "HTTP自適應流傳輸"類型的技術。該類型的技術使得能夠尤其在考慮例如客戶終端和內(nèi) 容服務器之間的鏈路的帶寬變化的情況下提供良好的用戶體驗。常規(guī)地，例如對應于變化 的比特率而可以對于同一視頻編碼不同的質(zhì)量。每個比特率自行劃分為時間片段（或者內(nèi) 容的"碎片"）。使得對于這些變化的比特率的描述和通常這些片段以及內(nèi)容的碎片對于服 務平臺上的客戶終端可用。為了能夠訪問完整的內(nèi)容，因此有必要知道與多個片段對應的 多個地址（URI)。
[0014] 存在用于協(xié)助這種內(nèi)容流傳輸模式的分布的數(shù)個解決方案。這些方案提出了，向 客戶端提供包含多媒體內(nèi)容的不同質(zhì)量的不同片段的地址的一個或多個中間描述文檔，也 稱為文件或單據(jù)或資源。這些方案的基本原理是制作具有不同的比特率變型的可用內(nèi)容， 這些變型中的每個都以媒體數(shù)據(jù)的連續(xù)片段的形式可用，這些片段可以由客戶端借助HTTP 協(xié)議來下載。
[0015] 對于給定的客戶終端而言，根據(jù)"HTTP自適應流傳輸"技術讀取內(nèi)容在于：
[0016] -下載和分析對內(nèi)容進行描述的描述性文件，比特率的變型可用，并且訪問用于每 個比特率變型的數(shù)據(jù)片段的裝置可用；
[0017] -下載數(shù)據(jù)片段，并且對于每個片段選擇特定的代表，尤其是選擇用于編碼待下載 的片段的比特率；以及
[0018] -分析和聚束（bundle)數(shù)據(jù)片段，以便為了讀取內(nèi)容而對它們解碼。
[0019] 存在兩種選擇（或者自適應）片段的代表的模式。
[0020] 根據(jù)第一模式，選擇是客戶終端的責任。在該模式中，由客戶終端決定選擇對于 媒體數(shù)據(jù)的每個片段的代表，來作為客戶端內(nèi)部的參數(shù)的函數(shù)（例如，所測帶寬、終端的容 量，等等）；尤其，客戶終端對于每個片段選擇給定的編碼比特率。如果客戶端測量的帶寬 是足夠的，則客戶端通常選擇高編碼比特率。然而，將該自適應決定僅留給客戶端阻止了 內(nèi)容分發(fā)器對平臺（服務器）、其網(wǎng)絡和服務的掌控。對于分發(fā)器而言，主要風險是需要服 務過高數(shù)目的、對于具有高編碼比特率的片段進行訪問的請求。結果將會是網(wǎng)絡帶寬或者 HTTP服務器的飽和。這還會造成客戶終端上重放質(zhì)量的下降，表現(xiàn)例如是圖像凍結。
[0021] 根據(jù)第二模式，選擇是經(jīng)由網(wǎng)絡廣播（或分發(fā)）內(nèi)容的服務器的責任。在該配置 中，解決方案包括將與要求修改代表，例如要求降低編碼比特率相關的信息項插入到廣播 片段的數(shù)據(jù)中。該信息可以被包括到在MPEG DASH標準中描述的名為"事件"的字段中。 IS0/IEC標準化組織的MPEGDASH(代表經(jīng)由HTTP - IS0/IEC標準23009-1:2012 (E)的動態(tài) 自適應流傳輸）專用于經(jīng)由網(wǎng)絡對多媒體內(nèi)容進行流傳輸；與第二模式相關的問題是執(zhí)行 適應客戶側的反應時間。事實上，客戶端完整地接收數(shù)據(jù)片段，在認識包括對修改片段的代 表的要求的新單據(jù)之前完整地分析它。問題是包括修改要求的單據(jù)對于在與該修改請求相 同的流中接收的當前片段而言未被考慮。因此，該解決方案不僅涉及在所接收的片段中提 取新單據(jù)的操作，而且涉及以差的質(zhì)量重放該所接收的片段。
[0022] 本發(fā)明提出了一種不顯示出現(xiàn)有技術的缺陷的解決方案。

【發(fā)明內(nèi)容】

[0023] 為了該目的，根據(jù)一個功能性方面，本發(fā)明的一個主題是一種用于管理由終端從 服務器接收的內(nèi)容的數(shù)據(jù)片段的代表的方法，該方法包括獲取文件的步驟，基于該文件生 成通用地址，其中一個地址與由終端從該文件中描述的多個代表中選擇的感興趣片段的代 表相關聯(lián)，該片段能夠根據(jù)該所選的代表從服務器接收，其特征在于，該方法包括在終端水 平上的如下步驟：
[0024] -第一步驟，根據(jù)第一所選代表傳送對于訪問第一片段的請求，
[0025] -第一步驟，接收對該請求的響應，該請求包括對于修改第一代表的要求；
[0026] -第二步驟，根據(jù)第二代表傳送對于訪問第一片段的請求；
[0027] -第二步驟，根據(jù)第二代表從服務器接收第一片段。
[0028] 因此，由服務器傳送的片段的代表總是服務器所期望的代表。如果接收到具有并 非服務器所期望的代表的代表接收了片段，則服務器不傳送感興趣的片段，而是通過修改 要求的方式請求客戶終端從終端傳送具有另一代表的片段。服務器接收具有新的所期望的 代表的URI地址；僅在此時服務器才向具有新的代表的終端傳送感興趣的片段。
[0029] 上面設想的修改要求在與傳遞片段的數(shù)據(jù)流不同的消息中被傳送。因此，不影響 所接收的片段的質(zhì)量。
[0030] 因此，參考現(xiàn)有技術中采用的解決方案，本發(fā)明避免了分析包含數(shù)據(jù)片段的數(shù)據(jù) 流以從中提取新的描述性文檔。
[0031] 根據(jù)第一實施例，代表包括用于片段的編碼比特率值。在該配置中，第一和第二代 表包括不同的值。
[0032] 根據(jù)第二實施例，終端對于給定的持續(xù)時間考慮修改第一代表的要求。對于終端 而言，對于給定的時間間隔考慮修改要求的事實避免了內(nèi)容服務器連續(xù)幾次發(fā)送修改要 求。
[0033] 根據(jù)第三實施例，修改要求是根據(jù)HTTP協(xié)議傳送的。該特征避免了完全更新該描 述文檔。HTTP協(xié)議的使用允許快速寫入修改要求。這些片段由服務器例如每2秒發(fā)送一次， 該特征避免了等待新的單據(jù)，其從服務器傳送的頻率更可觀，通常為30秒。更具體而言，該 要求是包括RFC標準2616中限定類型的數(shù)字碼的http消息。數(shù)字碼由客戶終端接收，該 客戶終端借助對應表從中推導出信息項，在我們的示例中，與片段的代表有關的設置。
[0034] 根據(jù)硬件方面，本發(fā)明涉及能夠接收內(nèi)容的片段的終端，該終端能夠訪問文件，基 于該文件生成通用地址，其中一個地址與由終端從該文件中描述的多個代表中選擇的感興 趣片段的代表相關聯(lián)，其特征在于，該終端包括：
[0035] -第一模塊，用于根據(jù)第一所選代表傳送訪問第一片段的請求，
[0036] -第一模塊，用于接收對該請求的響