專利名稱：在數(shù)據(jù)廣播中標示傳輸代碼集的方法和設(shè)備的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種標示(signal)傳輸代碼集(transmission code set)的設(shè)備和 方法，更具體地講，涉及一種在傳送關(guān)于對象庫侖纟番消息(object carousel message) 中的路徑名的字符編碼系統(tǒng)的數(shù)據(jù)中為了通過使用各種語言命名路徑名而標 示傳輸代碼集的方法。
背景技術(shù)：
數(shù)字廣播是一種執(zhí)行雙向數(shù)據(jù)傳送和不同于模擬廣播的數(shù)據(jù)再現(xiàn)和存儲 的先進的廣播技術(shù)。在數(shù)字廣播中，TV信號被壓縮并且作為編碼的數(shù)據(jù)信號 被記錄于其中的數(shù)字信號而被廣播。因為能夠經(jīng)由數(shù)字廣播而被傳送的信號 的數(shù)量比模擬廣播中的大六倍，所以數(shù)字廣播中的信號的分辨率至少是模擬 廣播中的兩倍。此外，因為數(shù)字無線電信號可以存儲多個圖像和音頻文件， 所以與模擬廣播中的 一條信道形成對比，在數(shù)字廣播中六至八條信道可以在 相同的帶寬中被運行。同樣地，數(shù)字廣播已成為信息時代的核心技術(shù)，通過 其，圖像和音頻文件可以被壓縮和傳送，并且各種信號可以通過使用基于計 算機的通信技術(shù)而被調(diào)制。因此，數(shù)字廣播中的TV從傳統(tǒng)消極的裝置被轉(zhuǎn) 換為積極的多媒體裝置。作為數(shù)字廣播的主要元素的數(shù)據(jù)廣播，除了圖像文件、聲音文件、軟件 應(yīng)用程序、和數(shù)據(jù)流以外的，還將數(shù)字/多媒體廣播內(nèi)容連續(xù)傳送到諸如PC、 數(shù)字機頂盒、和個人便攜式終端的信息處理設(shè)備。數(shù)據(jù)廣播不需要返回路徑， 并且信息處理設(shè)備不用請求內(nèi)容而接收內(nèi)容。這樣，數(shù)據(jù)廣播是一種結(jié)合廣 播方法、通信方法、和因特網(wǎng)來以非常高的速度傳送雙向多媒體內(nèi)容的高度 先進的技術(shù)。因此，數(shù)據(jù)廣播可以解決傳統(tǒng)的模擬廣播的單向性和簡單性以及關(guān)于圖像質(zhì)量、音調(diào)質(zhì)量、和因特網(wǎng)廣播容量的限制。數(shù)字廣播系統(tǒng)的例子包括作為地波接收系統(tǒng)在美國使用的先進電視系統(tǒng)委員會(ATSC)系統(tǒng)和在歐洲使用的數(shù)字視頻廣播-陸地(DVB-T)系統(tǒng)、以及 作為有線接收系統(tǒng)在美國使用的OpenCable系統(tǒng)和在歐洲使用的DVB-Cable (DVB-C)系統(tǒng)。用于數(shù)字廣播的中間件技術(shù)的例子包括DVB-多媒體家庭平 臺(DVB-MHP)、 OpenCable應(yīng)用平臺(OCAP)、和先進公共應(yīng)用平臺(ACAP)。 DVB-MHP是用于由DVB項目設(shè)計的歐洲數(shù)字TV的中間件系統(tǒng)。OCAP 是用于被美國的有線電視公司所采用的數(shù)字有線電視機頂盒和其它數(shù)字裝 置的中間件系統(tǒng)。ACAP已被設(shè)計以統(tǒng)一在有線廣4番中被使用的OCAP和在 地波廣播中被使用的數(shù)字TV應(yīng)用軟件環(huán)境(DASE)。DVB-MHP、 OCAP、和ACAP使用由ISO-IEC 13818-6標準定義的對象 輪播。為了交換用于命名數(shù)據(jù)、目錄、和文件的路徑名組件，對象輪播使用 定義在CORBA/IIOP 2.1規(guī)范中的公共對象請求代理架構(gòu)(CORBA)字串。另 夕卜，當字符編碼數(shù)據(jù)沒有在CORBA字串中被指定時，對象輪播使用用于編 碼系統(tǒng)的ISO 8859-1 (ISO Latin l)標準。因此，這些使用對象輪播的中間件 技術(shù)使用用于基本編碼系統(tǒng)的ISO 8859-1標準來命名路徑名、文件、和目錄。 然而，DVB-MHP、 OCAP、和ACAP對于路徑名僅僅支持拉丁語言，從而 不可能通過使用另 一種語言來表示路徑名。發(fā)明內(nèi)容本發(fā)明提供了 一種用于報告關(guān)于編碼系統(tǒng)的信息以在使用對象輪播的系 統(tǒng)中通過使用多種語言來表示路徑名的方法和設(shè)備。根據(jù)本發(fā)明的一方面，提供了 一種在使用對象輪播的數(shù)據(jù)廣播系統(tǒng)中使 用傳輸代碼集標示方法的客戶機，該客戶機包括系統(tǒng)接口，用于接收由服 務(wù)器廣播的廣播流；多路分解器，用于從由系統(tǒng)接口接收的廣播流中多路分 解對應(yīng)于由用戶選擇的節(jié)目的打包基本流(PES)包；圖像解碼器，用于對用于 圖像的多路分解的PES解碼；聲音解碼器，用于對用于聲音的多路分解的PES 解碼；和中央處理單元(CPU),用于從多路分解的消息PES中耳又出關(guān)于在對 象輪播消息中使用的字符串的傳輸代碼集的信息，并且基于該取出的關(guān)于傳 輸代碼集的信息對在對象輪播消息中使用的字符串解碼。根據(jù)本發(fā)明的另 一方面，提供了 一種在使用對象輪播的數(shù)據(jù)廣播系統(tǒng)中使用傳輸代碼集標示方法的服務(wù)器，該服務(wù)器包括圖像編碼器，用于對圖 像數(shù)據(jù)編碼并且產(chǎn)生圖像位流；聲音編碼器，用于對聲音數(shù)據(jù)編碼并且產(chǎn)生 聲音位流；多路復用器，用于多路復用圖像位流和聲音位流并且產(chǎn)生傳輸流； RF信號處理單元，用于將傳輸流調(diào)制成將被輸出的信號；和CPU，用于控制 圖像編碼器、聲音編碼器、多路復用器、和RF信號處理單元，產(chǎn)生將被加 載在傳輸流上的對象輪播消息，并且產(chǎn)生包括關(guān)于在該消息中使用的字符串 的傳輸代碼集的信息的消息。根據(jù)本發(fā)明的另一方面，提供了一種標示傳輸代碼集的方法，該方法包 括從服務(wù)器接收消息，該消息包括關(guān)于在對象輪播消息中使用的字符串的 傳輸代碼集的信息；從接收的消息中取出關(guān)于傳輸代碼集的信息；和基于關(guān)于傳輸代碼集的信息對在對象輪播消息中使用的字符串解碼。


通過參照附圖對本發(fā)明的示例性實施例進行詳細的描述，本發(fā)明的以上 和其它的方面將會變得清楚，其中圖l是示出DSM-CC模型的概念的方框圖；圖2示出包括對象輪播譜(spectrum)的DVB服務(wù)；圖3示出BIOP消息的^^式；圖4示出downloadServerlnitiate (DSI)消息的ServiceGatewaylnfo()的才各式；圖5示出BIOP::DirectoryMessage的才各式；圖6示出BIOP::FileMessage的才各式；圖7是根據(jù)本發(fā)明示例性實施例的服務(wù)器的方框圖；圖8是根據(jù)本發(fā)明示例性實施例的客戶機的方框圖；和l ; 、 、 、、 '具體實施方式
通過參照下面對示例性實施例和附圖的詳細描述，本發(fā)明和實現(xiàn)本發(fā)明 的方法可以:帔更容易地理解。然而，本發(fā)明可以以不同的形式#:實施并且不 應(yīng)該被解釋為局限于在此闡述的示例性實施例。更合適地，提供這些示例性實施例以便于本公開將會徹底和完全并且將會完整地把本發(fā)明的概念傳達給 本領(lǐng)域的技術(shù)人員，并且本發(fā)明將僅僅被所附的權(quán)利要求所限定。說明書中 相同的標號始終表示相同的部件?，F(xiàn)在將參照顯示本發(fā)明的示例性實施例的附圖更完整地描述本發(fā)明。數(shù)字存儲介質(zhì)命令和控制(DSM-CC)標準是一套提供用于管理MPEG-1 和MPEG-2位流以發(fā)送多媒體寬帶服務(wù)的控制功能和操作的協(xié)議。對象輪播 的概念已被定義在DSM-CC標準中并被反映在DVB規(guī)范中，然后已經(jīng)被 DVB- MHP、 OCAP、和ACAP采用作為用于數(shù)字廣播的中間件規(guī)范。圖1示出DSM-CC模型的概念。在DSM-CC模型中，由服務(wù)器120產(chǎn)生的流被發(fā)送到客戶機110，服務(wù) 器120和客戶機IIO都被當作用戶。客戶機110是使用多i某體內(nèi)容的機頂盒、 PC、或個人便攜式終端。服務(wù)器120提供多媒體內(nèi)容和服務(wù)。網(wǎng)絡(luò)130表示 提供用戶間的連接的一套通信部件。在圖1中，運送用戶到網(wǎng)絡(luò)(U-N)數(shù)據(jù)的 連接136和運送用戶到用戶(U-U)數(shù)據(jù)的連接134被顯示。U-U信息流在客戶 機和服務(wù)器之間被使用，U-N信息流在網(wǎng)絡(luò)和客戶機之間或者網(wǎng)絡(luò)和服務(wù)器 之間被使用。DSM-CC定義了被稱為會話和資源管理器(SRM)的邏輯實體。 在這種情況下，SRM 132提供了會話和網(wǎng)絡(luò)資源的集中管理。DVB系統(tǒng)提供了通過采用來自DSM-CC規(guī)范的U-U連接經(jīng)過各種傳輸 介質(zhì)的MPEG-2傳輸流(TS)的傳輸。MPEG-2 TS包括MPEG-2視頻和MPEG-2 音頻。數(shù)據(jù)廣播被當作基于MPEG-2的DVB傳輸標準的主要擴充。數(shù)據(jù)廣 播的例子包括經(jīng)由衛(wèi)星、電纜、或地面鏈路的軟件下載、經(jīng)過廣播信道的因 特網(wǎng)服務(wù)的傳輸、和交互式TV。數(shù)據(jù)信息當被包括在MPEG-2 TS中時可以 被發(fā)送。發(fā)送數(shù)據(jù)信息的方法的例子包括數(shù)據(jù)管道、數(shù)據(jù)流、多協(xié)議封裝、 數(shù)據(jù)輪播、和對象輪播。圖2示出使用對象輪播的DVB服務(wù)。由DSM-CC定義的對象輪播是一種支持從使用目錄對象、文件對象、和 流對象的廣播服務(wù)器傳輸對象群到廣播接收器的數(shù)據(jù)結(jié)構(gòu)。在這種情況下， 真實的目錄和內(nèi)容位于服務(wù)器中。對象輪播規(guī)范支持這樣的數(shù)據(jù)廣播服務(wù)， 其要求DSM-CC U-U對象經(jīng)過兼容DVB的廣播網(wǎng)絡(luò)的定期廣播。服務(wù)器根 據(jù)對象輪播協(xié)議反復地把對象插入兼容DVB的MPEG-2 TS。被發(fā)送的目錄 210和文件220包括對象的內(nèi)容，并且被發(fā)送的流230是用于廣播的其它的流的參考(reference)。此外，流230可以包括關(guān)于在特定的流中一皮廣4番的 DSM-CC事件的信息。DSM-CC事件可以與普通流數(shù)據(jù)一起被廣播并且被用 于觸發(fā)DSM-CC應(yīng)用程序。多個客戶機通過反復地讀取#1發(fā)送的輪播數(shù)據(jù)而 把服務(wù)器上的對象偽裝成客戶機的對象實現(xiàn)，從而客戶機可以恢復該對象實 現(xiàn)。輪播的對象提供給客戶機一種訪問應(yīng)用程序和被應(yīng)用程序使用的內(nèi)容的 方法，就好像客戶機被連接到服務(wù)器一樣。對象輪播中的U-U對象的數(shù)據(jù)和屬性被作為消息發(fā)送。消息格式使用廣 播內(nèi)部ORB協(xié)議(BIOP)被描述。圖3示出BIOP消息格式。該BIOP消息由 消息頭312、消息段頭314、和消息體316構(gòu)成。消息頭312提供關(guān)于BIOP 協(xié)議版本和BIOP消息長度的信息。消息段頭314包括關(guān)于被發(fā)送的對象的 信息，例如，諸如文件、流、和目錄的對象類型和對象鍵(object key)。消息 體316包括U-U對象的數(shù)據(jù)。BIOP消息在數(shù)據(jù)輪播模塊320中被廣播。在這種情況下， 一個模塊320 由多于一個的連接的BIOP消息構(gòu)成。在一個模塊320中的每個對象通過使 用對象鍵而被識別。根據(jù)DSM-CC數(shù)據(jù)輪播規(guī)范，每個模塊被分成多于一個 的塊。這些塊作為DownloadDataBlock (DDB) 330而#1發(fā)送。每個DDB消息 作為一種MPEG-2區(qū)段340而被順序地發(fā)送。塊可以通過使用多路分解器的 硬件濾波器而從TS直接獲得。為了從廣播網(wǎng)絡(luò)獲得一個對象，每一個包括對 象的模塊應(yīng)該被獲得。因此，應(yīng)該獲得模塊的傳輸參數(shù)，例如，模塊版本、 模塊大小、塊大小、定時、和廣播信道。因為這些參數(shù)作為 Downloadlnfolndication (DII)消息而被發(fā)送，所以DII消息應(yīng)該先于模塊被獲 得。結(jié)果，從廣播網(wǎng)絡(luò)獲得對象的過程包括獲得DII消息和模塊。為了獲得從廣播流發(fā)送的對象，DownloadServerlnitiate (DSI)消息被獲 得，并且包括在該DSI消息中的ServiceGatewaylnfo結(jié)構(gòu);故解釋。DSI消息包 括關(guān)于被包括在超群(supergroup)中的群的信息。在這種情況下，超群由多于 一個的群構(gòu)成，并且群由多于一個的模塊構(gòu)成。圖4示出ServiceGatewaylnfo結(jié)構(gòu)i吾法。對象輪播表示特定服務(wù)域，其是一套DVB網(wǎng)絡(luò)中的DSM-CC U-U對象。 該服務(wù)域包括為接收器提供服務(wù)名和對象名的圖表的服務(wù)網(wǎng)關(guān)?？蛻魴C從ServiceGatewaylnfo獲得表示對象的位置的內(nèi)部可操作參考 (IOR) 410。被包括在ServiceGatewaylnfo中的IOR 410包括對象圖表的路由對象在服務(wù)網(wǎng)關(guān)，換句話說，在一個服務(wù)域中的位置信息。因為包括路由對 象的模塊應(yīng)該被獲得以確定一 個服務(wù)域的路由對象，所以路由對象(BIOP::DirectoryMessage)通過順序地獲得DII消息和DDB消息而被獲得。 圖5示出BIOP:: DirectoryMessage的形式。BIOP: :DirectoryMessage包括被包括在路由對象中的對象的位置、名稱、 和屬性。IOR字段510包括對象的位置信息，并且id—data—byte字段520包括 對象的名稱信息。objectKind—data字段540包括用于區(qū)分消息的類型的值， 并且BIOP::DirectoryMessage具有根據(jù)該值的"dir"。另一方面，當objectKind—data字段540的值是"srg"時，該消息變成具 有被包括在路由對象中的對象的信息的BIOP::ServiceGateway消息。因此， 除了 objectKind—data字段540的值之外，BIOP::ServiceGateway消息具有與 BIOP:: DirectoryMessage相同的才各式。BIOP::ServiceGateway 消息的 serviceContextList —data—byte字段530可以包括包含關(guān)于CORBA字串的傳輸 代碼集的信息的CORBA通用內(nèi)部ORB協(xié)議(GIOP)代碼集上下文結(jié)構(gòu)。 CORBAGIOP代碼集上下文結(jié)構(gòu)將參照圖7而被描述。圖6示出BIOP:: FileMessage的形式。BIOP:: FileMessage是包括真實字段內(nèi)容的數(shù)據(jù)消息?？蛻魴C通過執(zhí)行一 系列IOR獲得過程而獲得期望的對象。圖7是根據(jù)本發(fā)明示例性實施例的服務(wù)器700的方框圖。 服務(wù)器700包括用于對數(shù)據(jù)編碼的圖像編碼器710和聲音編碼器720、 多路復用器730、 RF信號處理單元740、傳輸流輸出單元750、和CPU 760。 圖像編碼器710對圖像數(shù)據(jù)編碼并且產(chǎn)生被提供給多路復用器730的圖像位 流。聲音編碼器720對聲音數(shù)據(jù)編碼并且產(chǎn)生被提供給多路復用器730的聲 音位流。多路復用器730多路復用在圖像編碼器710和聲音編碼器720中被 編碼的位流，并且產(chǎn)生一個或多個被提供給RF信號處理單元740的傳輸流。 信號處理單元740將傳輸流調(diào)制成可以被輸出的信號，并且將該信號提供給 傳輸流輸出單元750。傳輸流輸出單元750發(fā)送傳輸流。CPU760控制每個單 元的操作，并且產(chǎn)生將纟皮力口載在傳輸流上的諸如DSI消息、DII消息、和DDB 消息的對象輪播消息。當在對象消息中使用除了 ISO 8859-1以外的傳輸代碼集時，CPU 760產(chǎn)生包括關(guān)于傳輸代碼集的信息的BIOP::ServiceGateway消白在對象輪播中的字符串的傳輸遵循被定義在CORBA/IIOP 2.1規(guī)范中的 CORBA字串?；贑ORBA/IIOP2.1規(guī)范，當關(guān)于傳輸代碼的信息沒有被解 釋時，CORBA字串遵循ISO 8859-1 (ISO Latin l)標準。因此，使用對象輪播 的DVB-MHP、 OCAP、和ACAP使用ISO 8859-1標準作為用于文件名和目 錄名的基本傳輸代碼集。這樣，為了在CORBA字串中使用另一種傳輸代碼 集，例如UTF-8傳輸代碼集，要求發(fā)送關(guān)于使用的傳輸代碼集的信息。應(yīng)用于特定的CORBA字串實例的字符編碼規(guī)則基于下面的關(guān)于字串實例是窄字串(narrow string)還是寬字串(wide string)的參數(shù)窄字符傳輸代碼集(TCS-C)的值、和寬字符傳輸代碼集(TCS-W)的值，而被確定。當TCS-C的值未知時，ISO 8859-1標準的基本值被應(yīng)用。當TCS-W的值未知時，因為缺少用于TCS-W的基本值，所以對寬字串編碼或解碼就會發(fā)生錯誤。下面是GIOP代碼集服務(wù)上下文結(jié)構(gòu)的接口定義語言(IDL)表示。 Module CONV—FRAME {Typedef unsigned long CodeSetld;Struct CodeSetContext {CodeSetld char—data;CodeSetld wchar—data;根據(jù)CORBA/IIOP 2.1規(guī)范，TCS-C和TCS-W的值通過使用GIOP代碼 集服務(wù)上下文而被分配。這樣，為了把關(guān)于對象輪播的CORBA字串傳輸代 碼集的信息報告給客戶機，CORBA/IIOP 2.1規(guī)范的GIOP代碼集服務(wù)上下文 結(jié)構(gòu)可以被選4奪性地插入對象輪播的BIOP::ServiceGateway消息的 serviceContext List—data—byte字段530 。換句話說，當對于CORBA字串使用 除了 ISO 8859-1標準以外的傳輸代碼集，例如UTF-8傳輸代碼集時，TCS-C 值可以被設(shè)置為UTF-8傳輸代碼集，TCS-W值可以通過將未定義的GIOP代 碼集服務(wù)上下文結(jié)構(gòu)插入 BIOP::ServiceGateway 消息的 serviceContextList—data—byte字段530而^皮設(shè)置。而且，對象輪播消息的 CORBA字串可以基于CORBA在窄字串中的定義而被解釋。圖8是根據(jù)本發(fā)明示例性實施例的客戶機的方框圖。圖8的客戶機是數(shù)據(jù)廣播的機頂盒。機頂盒800包括系統(tǒng)接口 810、多 路分解器820、作為解碼單元的圖像解碼器830和聲音解碼器840、 CPU 880、 存儲器850、圖像輸出單元860、和聲音輸出單元870。系統(tǒng)接口 810接收被轉(zhuǎn)換成低頻信號的圖像/聲音信號，并且把接收的信 號調(diào)制成將被發(fā)射到TV的圖像/聲音信號。此外，系統(tǒng)接口810通過對調(diào)制 的圖像/聲音信號解擾碼(descramble)來產(chǎn)生傳輸流，并且"fe該傳輸流發(fā)送到多 路分解器820。多路分解器820通過使用濾波器從多個打包基本流(PES)在其 中被多路復用的傳輸流中選擇對應(yīng)于由用戶選擇的節(jié)目的PES包。圖像解碼 器830和聲音解碼器840對由多路分解器820選擇的PES解碼，以將解碼的 PES轉(zhuǎn)換成一種將被發(fā)射的流。然后，圖像解碼器830和聲音解碼器840通 過圖像輸出單元860和聲音輸出單元870輸出數(shù)據(jù)廣播。存儲器850存儲由 多路分解器820選擇的PES、解碼的圖像信號、或者解碼的聲音信號。CPU 880 控制機頂盒800的每個單元的操作，并且解釋從服務(wù)器發(fā)送的例如DSI消息、 DII消息、和DBB消息的對象輪播消息。更具體地講，當CPU 880接收BIOP:: ServiceGateway消息時，CPU 880 ,人4妻收的BIOP::ServiceGateway消息取出關(guān) 于在對象輪播消息中使用的字符串的傳輸代碼集的信息，以通過使用對應(yīng)于 該傳輸代碼集的解碼器對消息中的字符串解碼。圖9是示出才艮據(jù)本發(fā)明的示例性實施例的共享關(guān)于傳輸代碼集的信息的 方法的流程圖。在操作步驟S910中，服務(wù)器通過在BIOP::ServiceGateway消息的 serviceContextList—data—byte字段530中插入GIOP代碼集服務(wù)上下文，來發(fā) 送包括關(guān)于在對象輪播消息中使用的CORBA字串的傳輸代碼集的信息的 GIOP代碼集服務(wù)上下文，并且在操作步驟S920中客戶機接收該 BIOP::ServiceGateway消息。在操作步驟S930中，客戶機的CPU 880從 BIOP::ServiceGateway消息取出GIOP代碼集服務(wù)上下文，以取出關(guān)于傳輸代 碼集的信息。在操作步驟S940中，客戶機的CPU 880根據(jù)取出的傳輸代碼 集信息通過使用正確的字符解碼器，來對包括在消息中的路徑名解碼。盡管已參照其示例性實施例具體地顯示和描述了本發(fā)明，但是本領(lǐng)域的技術(shù)人員應(yīng)該理解的是，在不脫離由下面的權(quán)利要求所限定的本發(fā)明的精神和范圍的情況下，可以對其進行形式和細節(jié)上的各種修改。根據(jù)本發(fā)明的用于標示傳輸代碼集的設(shè)備和方法，通過標示傳輸代碼集 從而在傳送關(guān)于對象輪播消息中路徑名的字符編碼系統(tǒng)的數(shù)據(jù)中允許使用各 種語言來命名路徑名。
權(quán)利要求
1、一種經(jīng)由廣播接收數(shù)據(jù)流的客戶機，該客戶機包括接收器，用于接收包括數(shù)據(jù)和BIOP消息的對象輪播；處理器，用于從BIOP消息取回傳輸代碼集信息，其中，傳輸代碼集信息提供用于解釋BIOP消息的字符串的指令；和解碼器，基于由傳輸代碼集信息提供的指令對所述字符串解碼。
2、 如權(quán)利要求1所述的客戶機，其中，根據(jù)ISO-IEC 13838-6定義對象 輪播。
3、 如權(quán)利要求2所述的客戶機，其中，所述字符串是根據(jù)CORBA/IIOP 2.1定義的CORBA字串。
4、 如權(quán)利要求3所述的客戶機，其中，BIOP消息是BIOP::ServiceGateway消息。
5、 如權(quán)利要求4所述的客戶機，其中，處理器讀取BIOP::ServiceGateway 消息中的CORBA/IIOP 2.1的通用內(nèi)部ORB協(xié)議代碼集服務(wù)上下文中的傳輸 代碼集信息。
6、 如權(quán)利要求5所述的客戶機，其中，傳輸代碼集信息由通用內(nèi)部ORB 協(xié)議代碼集服務(wù)上下文中的char—data字段表示。
7、 如權(quán)利要求6所述的客戶機，其中，傳輸代碼集信息被包括在 BIOP::ServiceGateway消息中的通用內(nèi)部ORB協(xié)i義代碼集服務(wù)上下文中。
8、 如權(quán)利要求7所述的客戶機，其中，傳輸代碼集信息指示所述字符串 基于ISO 8859-1或UTF-8被編碼。
9、 如權(quán)利要求8所述的客戶機，其中，如果沒有在傳輸代碼集信息中明 確編碼系統(tǒng)，則解碼器基于ISO 8859-1對所述字符串進行解碼。
10、 如權(quán)利要求9所述的客戶機，其中，不對用于寬字符傳輸代碼集的 通用內(nèi)部ORB協(xié)議代碼集服務(wù)上下文進行定義。
11、 如權(quán)利要求10所述的客戶機，其中，wchar—data字段不用于確定所 述消息內(nèi)的字符串的編碼系統(tǒng)。
12、 一種對參考數(shù)據(jù)的消息內(nèi)的字符串解碼的方法，所述方法包括 接收參考通過對象輪播發(fā)送的數(shù)據(jù)的消息，其中，所述消息為BIOP消自'.確定關(guān)于用于對消息內(nèi)的字符串進行編碼的編碼系統(tǒng)的信息；和根據(jù)確定的信息對所述字符串進行解碼。
13、 如權(quán)利要求12所述的方法，其中，根據(jù)ISO-IEC 13838-6定義對象輪播。
14、 如權(quán)利要求13所述的方法，其中，所述字符串是根據(jù)CORBA/IIOP 2.1定義的CORBA字串。
15 、如權(quán)利要求14所述的方法，其中，BIOP消息是BIOP::ServiceGateway消息。
16、 如權(quán)利要求15所述的方法，還包括讀取BIOP::ServiceGateway消 息中的CORBA/IIOP2.1的通用內(nèi)部ORB協(xié)議代碼集服務(wù)上下文中的信息。
17、 如權(quán)利要求16所述的方法，其中，所述信息由通用內(nèi)部ORB協(xié)議 代碼集服務(wù)上下文中的char—data字段表示。
18、 如權(quán)利要求17所述的方法，其中，所述信息被包括在 BIOP::ServiceGateway消息中的通用內(nèi)部ORB協(xié)議代碼集服務(wù)上下文中。
19、 如權(quán)利要求18所述的方法，其中，所述信息指示所述字符串基于 ISO 8859-1或UTF-8被編碼。
20、 如權(quán)利要求19所述的方法，還包括如果沒有在所述信息中明確編 碼系統(tǒng)，則基于ISO 8859-1對字符串進行解碼。
21、 如權(quán)利要求20所述的方法，其中，不對用于寬字符傳輸代碼集的通 用內(nèi)部ORB協(xié)議代碼集服務(wù)上下文進行定義。
22、 如權(quán)利要求21所述的方法，其中，wchar—data字段不用于確定所述 消息內(nèi)的字符串的編碼系統(tǒng)。
全文摘要
提供一種用于在數(shù)據(jù)廣播中標示傳輸代碼集的方法和設(shè)備。一種使用傳輸代碼集標示方法的客戶機包括多路分解器，用于從由系統(tǒng)接口接收的廣播流中多路分解對應(yīng)于由用戶選擇的節(jié)目的打包基本流(PES)包；圖像解碼器，用于對用于圖像的多路分解的PES解碼；聲音解碼器，用于對用于聲音的多路分解的PES解碼；和CPU，用于從多路分解的消息PES中取出關(guān)于在對象輪播消息中使用的字符串的傳輸代碼集的信息，并且基于該取出的關(guān)于傳輸代碼集的信息對在對象輪播消息中使用的字符串解碼。
文檔編號H04N7/015GK101267549SQ20081000201
公開日2008年9月17日 申請日期2005年6月17日 優(yōu)先權(quán)日2004年8月24日
發(fā)明者A. 亞當斯·格倫, 李光基, 李度衡 申請人:三星電子株式會社