視頻流提供方法及裝置與流程

2023-10-17 03:39:44 2

本發明涉及通信領域，尤其涉及視頻流提供方法及裝置。

背景技術：

虛擬機頂盒技術是指電視運營商通過伺服器集中管理用戶收視的新型技術。採用虛擬機頂盒技術，客戶端可以將用戶操作直接發送到伺服器，而伺服器則可以直接向不同客戶端返回不同的視頻流，從而使客戶端可以不再對用戶的操作及視頻數據進行處理，有效降低管理用戶收視對客戶端的硬體要求。

在採用虛擬機頂盒技術對用戶收視進行管理時，不同的用戶收看的節目不同，因此伺服器需要為不同的客戶端提供不同的視頻流。由於每一個用戶並非持續收看電視節目，因此伺服器並不需要持續為客戶端提供視頻流，而只需要在用戶收看電視節目時為客戶端提供視頻流即可。因此為節省資源，伺服器通常會使用有狀態會話(Stateful Session Bean)對客戶端進行區分並相應提供不同的視頻流，有狀態會話是指伺服器在每次為客戶端服務時為該客戶端提供創建一個會話，通過該會話的信息記錄需要為該客戶端提供的視頻流，並在結束為該客戶端服務後銷毀該會話。

在客戶端數量較多時，電視運營商可能需要同時使用多個伺服器管理和服務多個客戶端，在不同的時刻也可能由不同的伺服器為同一虛擬客戶端提供視頻流。如果伺服器採用有狀態會話對客戶端進行區分和管理，在不同的時刻由不同的伺服器為客戶端提供視頻流時，就需要不斷的創建和銷毀會話，或者採用複雜的處理機制實現伺服器之間的會話遷移，從而造成收視管理過程複雜。

技術實現要素：

本發明實施例提供了視頻流提供方法及裝置，可以簡化收視管理的處理過程。

第一方面，本發明實施例提供了一種視頻流提供方法，該方法包括：接收客戶端發送的請求信息，所述請求信息攜帶用戶身份證明UID；從會話管理器中獲取與所述UID對應的會話信息；根據所述會話信息生成應向所述客戶端發送的用戶界面；將所述用戶界面編碼為視頻流；將所述視頻流發送給所述客戶端。

結合第一方面，在第一方面第一種可能的實現方式中，所述方法還包括：更新所述用戶界面；根據更新後的所述用戶界面更新所述會話信息。

結合第一方面或第一方面第一種可能的實現方式，在第一方面第二種可能的實現方式中，所述從會話管理器中獲取與所述UID對應的會話信息包括：從會話管理器中獲取與所述UID對應的統一資源標識符URI。

結合第一方面第二種可能的實現方式，在第一方面第三種可能的實現方式中，根據所述會話信息獲取應向所述客戶端發送的待發送數據包括：向內容伺服器發起所述URI對應的超文本傳輸協議HTTP請求；獲取所述HTTP請求對應的響應內容；根據所述響應內容生成用戶界面。

結合第一方面第三種可能的實現方式，在第一方面第四種可能的實現方式中，更新所述用戶界面包括：從客戶端獲取用戶操作；根據用戶操作更新所述用戶界面。

結合第一方面第三種可能的實現方式，在第一方面第五種可能的實現方式中，更新所述用戶界面包括：根據所述響應內容更新所述用戶界面。

結合第一方面第一至五種可能的實現方式其中任意一種，在第一方面第六種可能的實現方式中，根據更新後的所述用戶界面更新所述會話信息包括：緩存與更新後的所述用戶界面相對應的URI；在符合預定條件時，將與所述UID對應的會話信息更新為與更新後的所述用戶界面相對應的URI。

結合第一方面或結合第一方面第一至六種可能的實現方式其中任意一種，在第一方面第七種可能的實現方式中，接收客戶端發送的請求信息包括：接收調度器轉發的所述請求信息。

結合第一方面第七種可能的實現方式，在第一方面第八種可能的實現方式中，所述將所述視頻流發送給所述客戶端包括：將所述視頻流及UID發送給所述調度器，以便於所述調度器將所述視頻流發送至與所述UID對應的客戶端。

結合第一方面或結合第一方面第一至八種可能的實現方式其中任意一種，在第一方面第九種可能的實現方式中，在接收客戶端發送的請求信息之前還包括：生成與所述客戶端對應的會話信息；通過所述會話管理器保存所述客戶端所對應的會話信息與所述客戶端的UID之間的對應關係。

第二方面，本發明實施例提供了一種視頻流提供裝置，該裝置包括：接收單元，用於接收客戶端發送的請求信息，所述請求信息攜帶用戶身份證明UID；獲取單元，用於從會話管理器中獲取與所述UID對應的會話信息；生成單元，用於根據所述會話信息生成應向所述客戶端發送的用戶界面；編碼單元，用於將所述用戶界面編碼為視頻流；發送單元，用於將所述視頻流發送給所述客戶端。

結合第一方面，在第一方面第一種可能的實現方式中，所述裝置還包括更新單元，所述生成單元，還用於更新所述用戶界面；所述更新單元，用於根據更新後的所述用戶界面更新所述會話信息。

結合第一方面或第一方面第一種可能的實現方式，在第一方面第二種可能的實現方式中，所述獲取單元，具體用於從會話管理器中獲取與所述UID對應的統一資源標識符URI。

結合第一方面第二種可能的實現方式，在第一方面第三種可能的實現方式中，所述生成單元包括：請求子單元，用於向內容伺服器發起所述URI對應的超文本傳輸協議HTTP請求；獲取子單元，用於獲取所述HTTP請求對應的響應內容；生成子單元，用於根據所述響應內容生成用戶界面。

結合第一方面第三種可能的實現方式，在第一方面第四種可能的實現方式中，所述接收單元，用於從客戶端獲取用戶操作；所述生成單元，還用於根據用戶操作更新所述用戶界面。

結合第一方面第三種可能的實現方式，在第一方面第五種可能的實現方式中，所述生成單元，還用於根據所述響應內容更新所述用戶界面。

結合第一方面第一至五種可能的實現方式其中任意一種，在第一方面第六種可能的實現方式中，所述更新單元包括：緩存子單元，用於緩存與更新後的所述用戶界面相對應的URI；更新子單元，用於在符合預定條件時，將與所述UID對應的會話信息更新為與更新後的所述用戶界面相對應的URI。

結合第一方面或結合第一方面第一至六種可能的實現方式其中任意一種，在第一方面第七種可能的實現方式中，所述接收單元，具體用於接收調度器轉發的所述請求信息。

結合第一方面第七種可能的實現方式，在第一方面第八種可能的實現方式中，所述發送單元，具體用於將所述視頻流及UID發送給所述調度器，以便於所述調度器將所述視頻流發送至與所述UID對應的客戶端。

結合第一方面或結合第一方面第一至八種可能的實現方式其中任意一種，在第一方面第九種可能的實現方式中，所述裝置還包括：會話信息生成單元，用於生成與所述客戶端對應的會話信息；會話信息保存單元，用於通過所述會話管理器保存所述客戶端所對應的會話信息與所述客戶端的UID之間的對應關係。

本發明實施例中，接收客戶端發送的請求信息，所述請求信息攜帶用戶身份證明 UID；從會話管理器中獲取與所述UID對應的會話信息；根據所述會話信息生成應向所述客戶端發送的用戶界面；將所述用戶界面編碼為視頻流；將所述視頻流發送給所述客戶端。由於可以利用會話管理器保存和管理會話，因而伺服器無需再頻繁創建和銷毀會話，也無需再採用複雜的處理機制實現伺服器之間的會話遷移，因而可以大大簡化收視管理的處理過程。

附圖說明

為了更清楚地說明本發明實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，對於本領域普通技術人員而言，在不付出創造性勞動性的前提下，還可以根據這些附圖獲得其他的附圖。

圖1為本發明收視管理系統的結構示意圖；

圖2為本發明視頻流提供方法一個實施例的流程示意圖；

圖3為本發明視頻流提供方法另一個實施例的流程示意圖；

圖4為本發明視頻流提供方法另一個實施例的流程示意圖；

圖5為本發明視頻流提供裝置一個實施例的結構示意圖；

圖6為本發明伺服器一個實施例的結構示意圖。

具體實施方式

下面將結合本發明實施例中的附圖，對本發明實施例中的技術方案進行清楚、完整的描述，顯然，所描述的實施例僅僅是本發明一部分實施例，而不是全部的實施例。基於本發明中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬於本發明保護的範圍。

參見圖1，為本發明收視管理系統的結構示意圖。

如圖1所示，所述系統可以包括：至少一個調度器101、至少一個會話管理器102與至少兩個伺服器103。會話管理器用於保存伺服器103與客戶端104之間的會會話信息，調度器101用於將各個客戶端104發送的收拾請求分發到各個伺服器103，並將各個伺服器103生成的視頻流分發至對應的客戶端104。所述視頻流由伺服器103根據從內容伺服器105中獲取到的數據生成。所述內容伺服器105可以包括IPTV(Internet Protocol Television)服務者網際網路應用伺服器等。

其中，所述調度器101、所述會話管理器102及所述伺服器103均可以通過硬體實現，也均可以通過軟體實現。例如，所述會話管理器102可以為資料庫，所述調度器101可以為負載均衡組件，所述伺服器103可以為瀏覽器。

參見圖2，為本發明視頻流提供方法一個實施例的流程圖，該方法包括如下步驟：

步驟201，接收客戶端發送的請求信息，所述請求信息攜帶用戶身份證明(User Identification，簡稱UID)。

調度器在接收到客戶端發送的收拾請求後，根據各個伺服器的負載狀況選擇一個伺服器，並將該收拾請求分發到該伺服器。其中，收拾請求是指用於收看電視節目、瀏覽網頁內容等操作的用戶操作。

在接收客戶端發送的請求信息之前，伺服器還可以先生成與所述客戶端對應的會話信息，然後通過所述會話管理器保存所述客戶端所對應的會話信息與所述客戶端的UID之間的對應關係。

例如，如果客戶端為新增的客戶端，那麼伺服器可以在接收到該客戶端首次發送的請求信息之前，根據默認的生成規則預先生成與該客戶端對應的會話信息，並通過會話管理器對該請求信息進行保存。或者，伺服器也可以在接收到該客戶首次發送的請求信息之後生成與該客戶端對應的會話信息。

步驟202，從會話管理器中獲取與所述UID對應的會話信息。

伺服器在接收到請求信息後，首先獲取收拾請求中包含的UID。然後將UID發送至會話管理器。會話管理器根據UID查找對應的會話信息，然後再將查找到的會話信息返回給伺服器。為便於查找，會話管理器可以以鍵值對的形式存儲UID及UID對應的會話信息。

所述會話信息可以為統一資源標識符(Uniform Resource Identifier，簡稱URI)，其中，URI的格式可以如下：

http://website_address:port/ui_page/position_id#sub_id？uid＝xxxxx

如上述URI示例所示，URI的前半部分為內容伺服器的IP位址與埠號或是內容伺服器的域名與埠號，而URI的後半部分是具體的頁面地址以及頁面內部元素的位置錨點，除此之外，URI中還可以攜帶對應的UID。

在此需要說明的是，伺服器在接收到客戶端首次發送的請求信息之前預先生成與所 述客戶端對應的會話信息時，URI的前半部分及後半部分均可以為默認內容。

步驟203，根據所述會話信息生成應向所述客戶端發送的用戶界面。

在獲取到所述會話信息後，伺服器可以根據所述會話信息確定需要向客戶端返回的內容，並且對所述內容進行解析執行，從而生成用戶界面。

當所述會話信息為URI時，所述伺服器可以首先向IPTV伺服器或者網際網路應用伺服器等內容伺服器發起所述URI對應的超文本傳輸協議HTTP請求；然後接收由所述內容伺服器根據所述HTTP請求發送的響應內容。其中，所述響應內容的形式可以包括HTML、JS腳本、CSS等內容，也可以包括MPEG-4碼流等內容。在接收到所述響應內容之後，伺服器可以根所述響應內容生成用戶界面。

例如，當所述伺服器為瀏覽器，所述響應內容包括JS時，瀏覽器可以執行所述JS，通過javascript框架提供的相關API函數以所述URI所攜帶的UID信息，生成用戶界面。根據JS的不同或UID的不同，生成的用戶界面也各不相同。

步驟204，將所述用戶界面編碼為視頻流。

在用戶界面生成之後，伺服器對用戶界面進行編碼，從而生成視頻流。伺服器對用戶界面進行編碼時，可以根據UID的不同選擇不同的編碼方式，從而可以實現為不同客戶端提供不同類型視頻流的功能。

步驟205，將所述視頻流發送給所述客戶端。

在視頻流生成之後，伺服器可以直接將視頻流發送給與所述UID對應的客戶端；或者，也可以將視頻流及所述請求信息所攜帶的UID發送給所述調度器，再由所述調度器將所述視頻流發送至所述UID對應的客戶端。

從上述實施例可以看出，接收客戶端發送的請求信息，所述請求信息攜帶用戶身份證明UID；從會話管理器中獲取與所述UID對應的會話信息；根據所述會話信息生成應向所述客戶端發送的用戶界面；將所述用戶界面編碼為視頻流；將所述視頻流發送給所述客戶端。由於可以利用會話管理器保存和管理會話，因而伺服器無需再頻繁創建和銷毀會話，也無需再採用複雜的處理機制實現伺服器之間的會話遷移，因而可以大大簡化收視管理的處理過程。

為便於伺服器管理用戶收視，伺服器還需要根據實際情況對所述會話信息進行更新。因此如圖3所示，在所述步驟205之後，還可以包括：

步驟206，更新所述用戶界面。

伺服器可以從會話管理器或者調度器獲取客戶端發送的用戶操作，然後根據用戶操作更新所述用戶界面。所述用戶操作可以包括頻道瀏覽、頻道切換、網頁瀏覽等。例如，所述用戶操作為頻道切換時，伺服器可以從IPTV伺服器獲取與切換後頻道相對應的MPEG-4碼流，然後用切換後頻道相對應的MPEG-4碼流替換切換前頻道相對應的MPEG-4碼流，進而重新生成新的用戶界面，完成所述用戶界面的更新。

當所述伺服器為瀏覽器時，可以利用Javascript框架提供的API接口獲取用戶信息。例如，所述API可以為SessionManager.getUserAction(uid)，其作用是通過uid，從SessionManager獲取用戶操作。

伺服器也可以執行所述響應內容，然後根據響應內容的執行情況更新所述用戶界面。例如，當所述響應內容中包含JS腳本時，伺服器也可以根據JS腳本的執行狀況更新所述用戶界面。具體過程在此就不再贅述。

步驟207，根據更新後的所述用戶界面更新所述會話信息。

當所述用戶界面發生變化後，該用戶界面的URI也會對應發生變化。當所述會話信息為URI時，一旦用戶界面發生變化，所述會話信息也需要隨之進行更新。

伺服器可以在更新所述用戶界面之後，生成更新後的用戶界面所對應的URI，然後將所述URI與所述客戶端的UID發送至會話管理器。會話管理器再將與所述UID對應的會話信息更新為與更新後的所述用戶界面相對應的URI。

由於在實際使用中，用戶界面更新可能較為頻繁，如果在每次用戶界面更新之後都通過會話管理器更新會話信息，那麼伺服器就需要頻繁地與回話管理器進行交互，導致伺服器和回話管理器都會消耗比價多的資源。為避免資源消耗過多，伺服器可以在用戶界面更新後，緩存與更新後的所述用戶界面相對應的URI；並在符合預定條件時，再將與所述UID對應的會話信息更新為與更新後的所述用戶界面相對應的URI。其中，所述預定條件可以是時間條件，例如，每間隔預定時長，伺服器使用與更新後的所述用戶界面相對應的URI更新一次所述會話信息；或者，所述預定條件也可以觸發條件，例如，伺服器可以在客戶端斷開與伺服器的連接之後，使用與更新後的所述用戶界面相對應的URI更新所述會話信息。通過緩存URI可以避免每次URI發生變化都對會話信息進行更新，從而降低伺服器與會話管理器的資源消耗。

採用本實施例，可以完成對會話信息的更新，從而收視管理更加簡單。

參見圖4，為本發明視頻流提供方法另一個實施例的示意圖。下面結合圖5對本發明做進一步說明。

步驟401，客戶端將攜帶有UID的請求信息發送至調度器。

步驟402，調度器將請求信息分發至伺服器。

步驟403，伺服器將UID發送至會話管理器。

步驟404，會話管理器將UID對應的URI發送給伺服器。

步驟405，伺服器向內容伺服器發送所述URI對應的HTTP請求。

步驟406，內容伺服器向伺服器發送所述URI對應的響應內容。

步驟407，伺服器根據所述響應內容生成用戶界面。

步驟408，伺服器將所述用戶界面編碼為視頻流。

步驟409，伺服器將所述視頻流及所述UID發送至調度器。

步驟410，調度器將所述視頻流發送至所述UID對應的客戶端。

在步驟410之後還可以包括：

步驟411，伺服器更新用戶界面。

步驟412，伺服器緩存更新後用戶界面所對應的URI。

步驟413，伺服器將更新後用戶界面所對應的URI及所述UID發送至回話管理器。

步驟414，會話管理將所述UID對應的會話信息更新為與更新後用戶界面所對應的URI。

由於步驟401至步驟414的詳細執行方式在前面實施例中已經進行了詳細說明，因此相關內容參見前述實施例即可，在本實施例中就不再贅述。

採用本實施例，由於可以利用會話管理器保存和管理會話，因而伺服器無需再頻繁創建和銷毀會話，也無需再採用複雜的處理機制實現伺服器之間的會話遷移，因而可以大大簡化收視管理的處理過程。

與本發明視頻流提供方法相對應，本發明還提供了視頻流提供裝置。

參見圖5，為本發明視頻流提供裝置一個實施例的結構示意圖。所述裝置可以用於執行圖1至圖4所對應實施例中的視頻流提供方法。

如果圖5所示，所述裝置可以包括：接收單元501，獲取單元502，生成單元503，編碼單元504，發送單元505。

其中，接收單元501，用於接收客戶端發送的請求信息，所述請求信息攜帶用戶身份證明UID；獲取單元502，用於從會話管理器中獲取與所述UID對應的會話信息；生成單元503，用於根據所述會話信息生成應向所述客戶端發送的用戶界面；編碼單元504，用於將所述用戶界面編碼為視頻流；發送單元505，用於將所述視頻流發送給所述客戶端。

可選的，所述裝置還可以包括更新單元。

當所述裝置還包括更新單元時，所述生成單元503，還用於更新所述用戶界面；所述更新單元，用於根據更新後的所述用戶界面更新所述會話信息。

可選的，所述裝置還可以包括會話信息生成單元及會話信息保存單元。

其中，會話信息生成單元，用於生成與所述客戶端對應的會話信息；會話信息保存單元，用於通過所述會話管理器保存所述客戶端所對應的會話信息與所述客戶端的UID之間的對應關係。

可選的，所述獲取單元502，具體用於從會話管理器中獲取與所述UID對應的統一資源標識符URI。

可選的，所述生成單元503包括：請求子單元，用於向內容伺服器發起所述URI對應的超文本傳輸協議HTTP請求；獲取子單元，用於獲取所述HTTP請求對應的響應內容；生成子單元，用於根據所述響應內容生成用戶界面。

可選的，所述接收單元501，用於從客戶端獲取用戶操作；所述生成單元503，還用於根據用戶操作更新所述用戶界面。

可選的，所述生成單元503，還用於根據所述響應內容更新所述用戶界面。

可選的，所述更新單元包括：緩存子單元，用於緩存與更新後的所述用戶界面相對應的URI；更新子單元，用於在符合預定條件時，將與所述UID對應的會話信息更新為與更新後的所述用戶界面相對應的URI。

可選的，所述接收單元501，具體用於接收調度器轉發的所述請求信息。

可選的，所述發送單元505，具體用於將所述視頻流及UID發送給所述調度器，以便於所述調度器將所述視頻流發送至與所述UID對應的客戶端。

採用本實施例，由於可以利用會話管理器保存和管理會話，因而視頻流提供裝置無需再頻繁創建和銷毀會話，也無需再採用複雜的處理機制實現伺服器之間的會話遷移，因而可以大大簡化收視管理的處理過程。

與本發明視頻流提供方法及裝置相對應，本發明還提供了伺服器。

參加圖6，為本發明伺服器一個實施例的結構示意圖。所述伺服器可以用於執行圖1至圖4所對應實施例中的視頻流提供方法。

如圖6所示，所述伺服器可以包括：處理器601，存儲器602，通信接口603。這些組件通過一條或多條總線進行通信。本領域技術人員可以理解，圖中示出的伺服器的結構並不構成對本發明的限定，它既可以是總線形結構，也可以是星型結構，還可以包括比圖示更多或更少的部件，或者組合某些部件，或者不同的部件布置。

處理器601為所述裝置的控制中心，利用各種接口和線路連接整個電子設備的各個部分，通過運行或執行存儲在存儲器602內的軟體程序和/或模塊，以及調用存儲在存儲器602內的數據，以執行電子設備的各種功能和/或處理數據。所述處理器601可以由集成電路(Integrated Circuit，簡稱IC)組成，例如可以由單顆封裝的IC所組成，也可以由連接多顆相同功能或不同功能的封裝IC而組成。舉例來說，處理器601可以僅包括中央處理器(Central Processing Unit，簡稱CPU)，也可以是GPU、數位訊號處理器(Digital Signal Processor，簡稱DSP)、及通信單元中的控制晶片(例如基帶晶片)的組合。在本發明實施方式中，CPU可以是單運算核心，也可以包括多運算核心。

存儲器602可用於存儲軟體程序以及模塊，處理器601通過運行存儲在存儲器的軟體程序以及模塊，從而執行終端的各種功能應用以及實現數據處理。存儲器主要包括程序存儲區和數據存儲區，其中，程序存儲區可存儲作業系統、至少一個功能所需的應用程式，比如聲音播放程序、圖像播放程序等等；數據存儲區可存儲根據伺服器的使用所創建的數據，比如UID、會話信息、UI與會話信息之間的存儲等。在本發明具體實施方式中，存儲器可以包括易失性存儲器，例如非揮發性動態隨機存取內存(Nonvolatile Random Access Memory，簡稱NVRAM)、相變化隨機存取內存(Phase Change RAM，簡稱PRAM)、磁阻式隨機存取內存(Magetoresistive RAM，簡稱MRAM)等，還可以包括非易失性存儲器，例如至少一個磁碟存儲器件、電子可擦除可編程只讀存儲器(Electrically Erasable Programmable Read-Only Memory，簡稱EEPROM)、快閃記憶體器件，例如反或快閃記憶體(NOR flash memory)或是反及快閃記憶體(NAND flash memory)。非易失存儲器儲存處理器所執行的作業系統及應用程式。所述處理器從所述非易失存儲器加載運行程序與數據到內存並將數字內容儲存於大量儲存裝置中。所述作業系統包括用於控制和管理常規系統任務，例如內存管理、存儲設備控制、電源管理等，以及有助於各種軟硬體之間通信的各種組件和/或驅動器。在本發明實施方式中，所述作業系統可以是Google公司的Android系統、Apple公司開發的iOS系統或Microsoft公司開發的Windows作業系統等，或者是Vxworks這類的嵌入式作業系統。

所述通信單元602用於建立通信信道，使伺服器通過所述通信信道以連接至客戶端、調度器等其他設備，並與其他設備進行通信。所述通信單元603可以包括無線區域網(Wireless Local Area Network，簡稱wireless LAN)模塊、藍牙模塊、基帶(Base Band)模塊等通信模塊，以及所述通信模塊對應的射頻(Radio Frequency，簡稱RF)電路，用於進行無線區域網路通信、藍牙通信、紅外線通信及/或蜂窩式通信系統通信，例如寬帶碼分多重接入(Wideband Code Division Multiple Access，簡稱W-CDMA)及/或高速下行封包存取(High Speed Downlink Packet Access，簡稱HSDPA)。所述通信模塊用於控制終端中的各組件的通信，並且可以支持直接內存存取(Direct Memory Access)。

其中，所述處理器601，用於通過所述通信接口603接收客戶端發送的請求信息，所述請求信息攜帶用戶身份證明UID；從存儲器602中獲取與所述UID對應的會話信息；根據所述會話信息生成應向所述客戶端發送的用戶界面；將所述用戶界面編碼為視頻流；將所述視頻流發送給所述客戶端。

可選的，所述處理器601，還用於更新所述用戶界面；並根據更新後的所述用戶界面更新所述會話信息。

可選的，所述處理器601，還用於從會話管理器中獲取與所述UID對應的統一資源標識符URI。

可選的，所述處理器601，還用於通過通信接口603向內容伺服器發起所述URI對應的超文本傳輸協議HTTP請求；通過通信接口603獲取所述HTTP請求對應的響應內容；根據所述響應內容生成用戶界面。

可選的，所述處理器601，還用於通過通信接口603從客戶端獲取用戶操作；根據用戶操作更新所述用戶界面。

可選的，所述處理器601，還用於根據所述響應內容更新所述用戶界面。

可選的，所述處理器601，還用於緩存與更新後的所述用戶界面相對應的URI；在符合預定條件時，將存儲器602中與所述UID對應的會話信息更新為與更新後的所述用戶界面相對應的URI。

可選的，所述處理器601，還用於通過通信接口603接收調度器轉發的所述請求信息。

可選的，所述處理器601，還用於通過通信接口603將所述視頻流及UID發送給所述調度器，以便於所述調度器將所述視頻流發送至與所述UID對應的客戶端。

可選的，所述處理器601，還用於生成與所述客戶端對應的會話信息；通過所述存儲器602保存所述客戶端所對應的會話信息與所述客戶端的UID之間的對應關係。

採用本實施例，由於可以利用會話管理器保存和管理會話，因而視頻流提供裝置無需再頻繁創建和銷毀會話，也無需再採用複雜的處理機制實現伺服器之間的會話遷移，因而可以大大簡化收視管理的處理過程。

本領域的技術人員可以清楚地了解到本發明實施例中的技術可藉助軟體加必需的通用硬體平臺的方式來實現。基於這樣的理解，本發明實施例中的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟體產品的形式體現出來，該計算機軟體產品可以存儲在存儲介質中，如ROM/RAM、磁碟、光碟等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，伺服器，或者網絡設備等)執行本發明各個實施例或者實施例的某些部分所述的方法。

本說明書中的各個實施例均採用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於裝置實施例及伺服器實施例而言，由於其基本相似於方法實施例，所以描述的比較簡單，相關之處參見方法實施例的部分說明即可。

以上所述的本發明實施方式，並不構成對本發明保護範圍的限定。任何在本發明的精神和原則之內所作的修改、等同替換和改進等，均應包含在本發明的保護範圍之內。