JP2010252260A - ネットワークサーバ、メディア形式変換方法、及び、メディア形式変換システム - Google Patents

ネットワークサーバ、メディア形式変換方法、及び、メディア形式変換システム Download PDF

Info

Publication number
JP2010252260A
JP2010252260A JP2009102102A JP2009102102A JP2010252260A JP 2010252260 A JP2010252260 A JP 2010252260A JP 2009102102 A JP2009102102 A JP 2009102102A JP 2009102102 A JP2009102102 A JP 2009102102A JP 2010252260 A JP2010252260 A JP 2010252260A
Authority
JP
Japan
Prior art keywords
content
media format
conversion
unit
network server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2009102102A
Other languages
English (en)
Other versions
JP5487697B2 (ja
Inventor
Yoshinori Honjo
良規 本庄
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2009102102A priority Critical patent/JP5487697B2/ja
Priority to US12/729,712 priority patent/US8250239B2/en
Priority to CN201010163559A priority patent/CN101867568A/zh
Publication of JP2010252260A publication Critical patent/JP2010252260A/ja
Application granted granted Critical
Publication of JP5487697B2 publication Critical patent/JP5487697B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4344—Remultiplexing of multiplex streams, e.g. by modifying time stamps or remapping the packet identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4334—Recording operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals

Abstract

【課題】ネットワークを介したコンテンツの出力においてより優れた互換性を有するネットワークサーバ等を提供する。
【解決手段】ネットワークを介して接続されたクライアント装置からコンテンツを受信する受信部と、コンテンツのメタデータを取得し、メタデータに応じてコンテンツのメディア形式を変換するか否かを決定し、メタデータに応じて変換後のメディア形式を選択する変換判定部と、コンテンツのメディア形式を前記変換判定部で選択されたメディア形式に変換する形式変換部と、を備えるネットワークサーバ。
【選択図】図２

Description

本発明は、ネットワークサーバ、メディア形式変換方法、及び、メディア形式変換システムに関する。より詳しくは、コンテンツのメディア形式を変換するネットワークサーバ、メディア形式変換方法、及び、メディア形式変換システムに関する。
近年、テレビ放送等のコンテンツを記憶媒体に記録し、記憶されたコンテンツをネットワークを介して出力するネットワークサーバについて研究が行われている。ネットワークサーバは、記録されたコンテンツをＨＤＭＩ（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ、登録商標）ケーブル等を介して出力するだけでなく、各種のホームネットワークを介して表示装置に出力することができる。ホームネットワークとは、例えば、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ、登録商標）で規定されるネットワークなどである。
ホームネットワークを経由してＴＳパケットが伝送される場合においては、伝送する側の装置がＴＳパケットにタイムスタンプを付加し、受信機がＴＳパケットに付加されているタイムスタンプを使用して、当該ＴＳパケットをデコーダに出力するタイミングを制御する方法が有効である。例えば、ＴＳパケットにタイムスタンプを付加する技術としては様々なものが開示されている（例えば、特許文献１参照）。
特開２００８−６１１５０号公報
しかし、多様なメディア形式が存在するため、ネットワークサーバがネットワークを介してコンテンツを表示装置に出力しても、表示装置が出力されたコンテンツを適切に処理できない場合があった。
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、ネットワークを介した出力においてより優れた互換性を有する、新規かつ改良されたネットワークサーバ、メディア形式変換方法、及び、メディア形式変換システムを提供することにある。
上記課題を解決するために、本発明のある観点によれば、ネットワークを介して接続されたクライアント装置からコンテンツを受信する受信部と、上記コンテンツのメタデータを取得し、上記メタデータに応じて上記コンテンツのメディア形式を変換するか否かを決定し、上記メタデータに応じて変換後のメディア形式を選択する変換判定部と、上記コンテンツのメディア形式を上記変換判定部で選択されたメディア形式に変換する形式変換部と、を備えるネットワークサーバ。
上記変換判定部は、上記受信部が上記コンテンツを受信する前提として、上記メタデータを上記クライアント装置から取得するようにしてもよい。
上記ネットワークサーバは、上記クライアント装置から受信したコンテンツ又は上記形式変換部で変換されたコンテンツをネットワークを介して接続された表示装置に配信する配信部をさらに備えていてもよい。
上記ネットワークサーバは、変換後のメディア形式の優先順位を示す情報が記憶されたメディア形式情報記憶部をさらに備え、上記変換判定部は、上記優先順位に従って変換後のメディア形式を選択するようにしてもよい。
上記変換判定部は、上記コンテンツのメディア形式がタイムスタンプを有しないものであるとき、変換後のメディア形式としてタイムスタンプが付加されたメディア形式を選択するようにしてもよい。
上記クライアント装置と上記受信部とはＤＬＮＡによるネットワークを介して通信し、上記変換判定部は、上記クライアント装置から送信されたＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストの入力引数で指定されたプロトコル情報に基づいてメディア形式を変換するか否かを決定し、変換後のメディア形式を決定するようにしてもよい。
上記受信部は、上記クライアント装置から送信されたｈｔｔｐ ｐｏｓｔリクエストに従って上記コンテンツのデータを取得するようにしてもよい。
上記課題を解決するために、本発明の別の観点によれば、ネットワークを介して接続されたクライアント装置からコンテンツのメタデータを取得し、上記メタデータに応じて上記コンテンツのメディア形式を変換するか否かを決定し、上記メタデータに応じて変換後のメディア形式を選択する変換判定ステップと、上記クライアント装置から上記コンテンツを受信する受信ステップと、上記コンテンツのメディア形式を上記変換判定ステップで選択されたメディア形式に変換する形式変換ステップと、を含むメディア形式変換方法が提供される。
上記課題を解決するために、本発明の別の観点によれば、ネットワークを介して接続されたクライアント装置からコンテンツを受信する受信部と、上記コンテンツのメタデータを取得し、上記メタデータに応じて上記コンテンツのメディア形式を変換するか否かを決定し、上記メタデータに応じて変換後のメディア形式を選択する変換判定部と、上記コンテンツのメディア形式を上記変換判定部で選択されたメディア形式に変換する形式変換部と、を備えるネットワークサーバと、上記ネットワークサーバにネットワークを介して上記コンテンツを送信する上記クライアント装置と、上記ネットワークサーバからネットワークを介して上記コンテンツ又は上記形式変換部で変換されたコンテンツの配信を受ける表示装置と、を有するメディア形式変換システムが提供される。
以上説明したように本発明によれば、ネットワークを介したコンテンツの出力においてより優れた互換性を有するネットワークサーバ、メディア形式変換方法、及び、メディア形式変換システムを提供することができる。
本発明の一実施形態に係るネットワークサーバの具体的な構成例を示す説明図である。 本発明の一実施形態に係るネットワークサーバのさらに具体的な構成例を示す説明図である。 本発明の一実施形態に係るネットワークサーバにコンテンツをアップロードするクライアント装置の具体的な構成例を示す説明図である。 本発明の一実施形態に係るネットワークサーバからネットワークを介してコンテンツの配信を受ける表示装置の具体的な構成例を示す説明図である。 本発明の一実施形態に係るネットワークサーバのハードウェア構成例を示すブロック図である。 本発明の一実施形態に係るネットワークサーバのメディア形式変換の一例を示すフローチャートである。 本発明の一実施形態に係るネットワークサーバのメディア形式変換の一例を示すフローチャートである。 メディア形式変換作業におけるネットワークサーバとクライアント装置との情報のやりとりの流れを示したシーケンス図である。
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
なお、説明は以下の順序で行うものとする。
１．本発明の一実施形態に係るメディア形式変換システムの構成
２．本発明の一実施形態に係るネットワークサーバの構成
３．本発明の一実施形態に係るネットワークサーバのより具体的な構成
４．本発明の一実施形態に係るネットワークサーバにコンテンツをアップロードするクライアント装置の構成
５．ネットワークサーバからコンテンツの配信を受ける表示装置の構成
６．本発明の一実施形態に係るネットワークサーバのハードウェア構成の具体例
７．ネットワークサーバ及びクライアント装置の前提技術
８．本発明の一実施形態に係るネットワークサーバによるメディア形式変換の流れ
９．メディア形式変換作業におけるネットワークサーバとクライアント装置との間における情報の流れ
１０．ネットワークサーバ１００におけるメタデータの取り扱い
＜１．本発明の一実施形態に係るメディア形式変換システムの構成＞
本発明の一実施形態に係るメディア形式変換システムは、例えば、ネットワークサーバ１００と、クライアント装置２００と、表示装置３００と、を備える。ネットワークサーバ１００は、後述するネットワーク１０を介してクライアント装置２００からコンテンツのデータを取得する。また、ネットワークサーバ１００は、後述するネットワーク１１を介して表示装置３００にコンテンツを配信する。クライアント装置２００は、ネットワーク１０を介してネットワークサーバ１００にコンテンツのデータをアップロードする。表示装置３００は、ネットワーク１１を介してネットワークサーバ１００からコンテンツの配信を受けて、コンテンツを表示出力する。
ネットワーク１０は、例えば、ＨＤＲＬ（ＨＤ Ｒｅｃｏｒｄｋｉｎｇ Ｌｉｎｋ）で規定されたホームネットワーク等で構成される。また、ネットワーク１１は、例えば、ＤＬＮＡで規定されたネットワーク等で構成される。ネットワーク１０及びネットワーク１１は、これらに限定されるものではなく、その他のネットワークによって構成されていてもよい。
＜２．本発明の一実施形態に係るネットワークサーバの構成例＞
図１は、本発明の一実施形態に係るネットワークサーバ１００の具体的な構成例を示すブロック図である。ネットワークサーバ１００は、例えば、受信部１０２と、変換判定部１０４と、形式変換部１０６と、配信部１０８と、メディア形式情報記憶部１１０と、コンテンツ記憶部１１２と、書き込み部１１４と、を備える。各部で行われる処理は、ハードウェア又はＣＰＵがプログラムを実行することによって行われる。
受信部１０２は、クライアント装置２００に備えられたストリーム受信部２０２が放送波から取得したコンテンツのデータをネットワーク１０を介してクライアント装置２００から受信する。受信部１０２は、変換判定部１０４の判定結果に従って、クライアント装置２００から受信したコンテンツのデータを形式変換部１０６に提供する。受信部１０２は、クライアント装置２００から受信したコンテンツのデータをコンテンツ記憶部１１２に記憶させてもよい。
変換判定部１０４は、受信部１０２がクライアント装置２００からコンテンツのデータを受信する前提として、クライアント装置２００からネットワーク１０を介してコンテンツのメタデータを取得する。変換判定部１０４は、取得したメタデータに応じてコンテンツのメディア形式を変換するか否かを判定する。また、変換判定部１０４は、取得したメタデータに応じて変換後のコンテンツのメディア形式を選択する。変換判定部１０４は、これらの判定結果を受信部１０２及び変換判定部１０６等に伝達する。変換判定部１０４は、上記クライアント装置から送信されたＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストの入力引数で指定されたプロトコル情報（Ｍｉｍｅ−ｔｙｐｅ及びＰｒｏｆｉｌｅ−ｎａｍｅ）からメタデータを取得してもよい。また、変換判定部１０４は、クライアント装置２００からＨＴＴＰ ＰＯＳＴリクエストによってコンテンツのアップロードを要求されたときに、Content-TypeヘッダからMime-typeを取得してもよい。また、変換判定部１０４は、contentFeatures.dlna.orgヘッダからprofile-nameを取得してもよい。
形式変換部１０６は、クライアント装置２００から受信したコンテンツのメディア形式を変換判定部１０４で選択されたメディア形式に変換する。形式変換部１０６は、変換後のコンテンツをコンテンツ記憶部１１２及び書き込み部１１４に提供する。
配信部１０８は、受信部１０２がクライアント装置２００から受信したコンテンツ、形式変換部１０６で変換されたコンテンツ、又は、コンテンツ記憶部１１２に記憶されたコンテンツをネットワーク１１を介して接続された表示装置３００に配信する。このとき、配信部１０８は、コンテンツ記憶部１１２にコンテンツを記憶させ、後からコンテンツ記憶部１１２に記憶されたコンテンツを読み出して表示装置３００に配信してもよいし、バッファ等に一時的に格納して表示装置３００に配信してもよい。また、配信部１０８は、ＨＤＭＩ等のケーブルを使用することによって、ネットワーク１１を介しない接続方法でコンテンツを表示装置３００に配信してもよい。
メディア形式情報記憶部１１０は、メディア形式の変換を行う必要があるメディア形式に関する情報及び変換後のメディア形式の優先順位を示す情報を記憶しており、これらの情報を変換判定部１０４に提供する。変換後のメディア形式の優先順位を示す情報において、表示装置３００のデコード機能を考慮して互換性により優れたメディア形式の順位をより高く設定することが好ましい。例えば、Ｈ．２６４／ＡＶＣ形式よりもＭＰＥＧ２形式（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ２−Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）が優先するように設定されてもよい。また、ＭＰＥＧ２−ＴＳ形式よりもＭＰＥＧ２−ＴＴＳ形式が優先するように設定されてもよい。また、メディア形式情報記憶部１１０は、変換判定部１０４、形式変換部１０６、及び、配信部１０８をソフトウェア処理によって実現するためのプログラムを格納していてもよい。
コンテンツ記憶部１１２は、変換判定部１０４でメディア形式を変換する必要があると判定され、形式変換部１０６でメディア形式の変換が行われた場合、変換されたコンテンツを記憶する。また、コンテンツ記憶部１１２は、変換判定部１０４でメディア形式を変換する必要がないと判定された場合、受信部１０２がクライアント装置２００から受信したコンテンツをそのまま記憶する。
書き込み部１１４は、形式変換部１０６で変換されたコンテンツのデータを形式変換部１０６から取得して記憶媒体に書き込むことができる。また、書き込み部１１４は、コンテンツ記憶部１１２に記憶されたコンテンツのデータを記憶媒体に書き込むことができる。ここでいう記憶媒体には、ＤＶＤ又はブルーレイディスクなどのディスク状記憶媒体が含まれる。
＜２．本発明の一実施形態に係るネットワークサーバ１００のさらに具体的な構成例＞
続いて、図２を参照しながら、本発明の一実施形態に係るネットワークサーバのさらに具体的な構成について説明する。
図２は、本発明の一実施形態に係るネットワークサーバのさらに具体的な構成例を示すブロック図である。図２は、図１に示されるネットワークサーバ１００の機能をさらに具体的に説明するためのブロック図である。図２に示されるように、ネットワークサーバ１００は、例えば、第１パイプライン変換部１５０と、コンテンツディレクトリサービス部（ＣＤＳ）１６０と、ライターセットアップ部（Ｗｒｉｔｅｒ Ｓｅｔｕｐ）１６２と、を備える。また、ネットワークサーバ１００は、リーダーセットアップ部（Ｒｅａｄｅｒ Ｓｅｔｕｐ）１６４と、第１ハードディスクドライブ（ＨＤＤ）１７０、第２ハードディスクドライブ（ＨＤＤ）１７５と、を備える。さらに、ネットワークサーバ１００は、第２パイプライン変換部１８０と、ＡＡＣＳ暗号化部（ＢＤ／ＡＡＣＳ）１９０と、ブルーレイディスク書込部（ＢＤ）１９２と、を備える。
図２の第１パイプライン変換部１５０は、図１の形式変換部１０６に対応する。第１パイプライン変換部１５０は、ＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）復号処理部（Ｄｔｃｐ ｄｅｃ）１５１と、タイムスタンプ付加処理部（Ｏｆｔｓ）１５２と、を含む。また、第１パイプライン変換部１５０は、さらに、ローカル暗号化処理部（Ｌｏｃａｌ ｅｎｃ）１５３と、ＴＴＳライターフィルタ処理部（Ｔｔｓ）１５４と、ローカルストレージ書込処理部（Ｌｏｃａｌ）１５５とを含む。第１パイプライン変換部１５０で行われる各処理は、ＣＰＵ及びソフトウェアによる処理で行われてもよく、ハードウェア処理と、ＣＰＵ及びソフトウェアによる処理とを組み合わせて行われてもよい。ＤＴＣＰ復号処理部１５１、タイムスタンプ付加処理部１５２、及び、ローカル暗号化処理部１５３は、ロバストネスの観点から、通常、一体的なハードウェアによって行われる。
ＤＴＣＰ復号処理部（Ｄｔｃｐ ｄｅｃ）１５１は、ＤＴＣＰ規格に従って暗号化されたコンテンツを復号する処理を行う。ここで、ＤＴＣＰとは、コンテンツデータを送受信できる２の装置間の距離を限定し、著作権保護を実現する技術である。距離の限定は、ＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）技術を応用し、ホームネットワークに含まれる２の装置間の応答時間（ＲＴＴｔｉｍｅ）の許容値を設定することによって行われる。
タイムスタンプ付加処理部（Ｏｆｔｓ）１５２は、パーシャルシングルプログラムＴＳ形式のコンテンツにタイムスタンプを付加する処理を行う。なお、タイムスタンプ付加処理部１５２は、必ずしも第１パイプライン変換部１５０の先頭で行われる必要はなく、中間で行われてもよい。
ローカル暗号化処理部（Ｌｏｃａｌ ｅｎｃ）１５３は、ネットワークサーバ１００の固有の情報などに基づいて生成される暗号鍵により、コンテンツを暗号化する処理を行う。ＴＴＳライターフィルタ処理部（Ｔｔｓ）１５４は、タイムシークやビットレート演算などタイムスタンプを利用した時間に関連する処理を行う。ローカルストレージ書込処理部（Ｌｏｃａｌ）１５５は、上記各処理を経たコンテンツをＨＤＤ１７５に書き込む処理を行う。
図２のコンテンツディレクトリサービス部（ＣＤＳ）１６０、ライターセットアップ部（Ｗｒｉｔｅｒ Ｓｅｔｕｐ）１６２、及び、リーダーセットアップ部（Ｒｅａｄｅｒ Ｓｅｔｕｐ）１６４は、図１の変換判定部１０４と対応する。
コンテンツディレクトリサービス部１６０は、ＤＬＮＡで規定されたネットワークにおけるアイテム及びコンテナ等のオブジェクトを管理する。
ライターセットアップ部１６２は、コンテンツディレクトリサービス部１６０からコンテンツのメタデータ及び変換後のコンテンツのメタデータの提供を受け、これらのメタデータに応じて第１パイプライン変換部１５０でいずれの変換処理を行うかを指令する。
リーダーセットアップ部１６４は、コンテンツディレクトリサービス部１６０から提供されるコンテンツのメタデータに応じて第２パイプライン変換部１８０でいずれの変換処理を行うかを指令する。
第１ハードディスクドライブ１７０は、図１のメディア形式情報記憶部１１０に対応する。また、第２ハードディスクドライブ１７５は、図１のコンテンツ記憶部１１２に対応する。図２では、第１ハードディスクドライブと第２ハードディスクドライブとが別々のハードディスクドライブで構成されているが、これらは、１つのハードディスクドライブで構成されていてもよい。
第２パイプライン変換部１８０は、図１の配信部１０８に対応する。第２パイプライン変換部１８０は、ローカル読出処理部（Ｌｏｃａｌ）１８１と、ＴＴＳライターフィルタ処理部（Ｔｔｓ）１８２と、ローカル暗号復号処理部（Ｌｏｃａｌ ｄｅｃ）１８３と、ＤＴＣＰ復号処理部（ＤＴＣＰ ｄｅｃ）１８４とからなる。第２パイプライン変換部１８０で行われる各処理は、ＣＰＵ及びソフトウェアによる処理で行われてもよく、第１パイプライン変換部１５０と同様に、所定の処理を一体的なハードウェアによって行われてもよい。
ローカル読出処理部（Ｌｏｃａｌ）１８１は、ＨＤＤ１７５に記憶されたコンテンツのデータを読み出す処理を行う。ＴＴＳリーダーフィルタ処理部（Ｔｔｓ）１８２は、タイムシークやビットレート演算などタイムスタンプを利用した時間に関連する処理を行う。
ローカル暗号復号処理部（Ｌｏｃａｌ ｄｅｃ）１８３は、ネットワークサーバ１００の固有の情報などに基づいて生成される暗号鍵により暗号化されたコンテンツを復号する処理を行う。ＤＴＣＰ復号処理部（ＤＴＣＰ ｄｅｃ）１８４は、ＤＴＣＰ規格に従って暗号化されたコンテンツを復号する処理を行う。
ＡＡＣＳ暗号化部（ＢＤ／ＡＡＣＳ）１９０は、ＤＴＣＰ復号処理部１５１及びタイムスタンプ付加処理部１５２で処理されたコンテンツを取得し、ＡＡＣＳ規格に従ってコンテンツの暗号化処理を行う。なお、ＡＡＣＳ（Ａｄｖａｎｃｅｄ Ａｃｃｅｓｓ Ｃｏｎｔｅｎｔ Ｓｙｓｔｅｍ）は、再生専用のブルーレイディスクディスクで採用される映像コンテンツのコピープロテクト規格である。
ブルーレイディスク書込部（ＢＤ）１９２は、ＡＡＣＳ暗号化部１９０から暗号化されたコンテンツのデータを取得し、ブルーレイディスクに書き込む。コンテンツデータをブルーレイディスク書込部１９２でブルーレイディスクに書き込む場合は、ＤＴＣＰ復号処理部１５１及びタイムスタンプ付加処理部１５２で処理されたコンテンツのデータをＡＡＣＳ暗号化部１９０に提供することが好ましい。
＜４．ネットワークサーバにコンテンツをアップロードするクライアント装置の構成＞
続いて、クライアント装置２００について説明する。クライアント装置２００は、ケーブルテレビやデジタル放送等を受像してテレビで視聴可能な信号へと変換するセットトップボックス等のチューナー機器である。このようなクライアント装置２００は、コスト面等の理由によって、コンテンツのメディア形式を自動的に変換する機能を有しない場合があり、ベンダや放送オペレータの意向によって装置の仕様が決定される場合がある。以下にクライアント装置の具体的な構成例について説明する。
図３は、本発明の一実施形態に係るネットワークサーバ１００にコンテンツをアップロードするクライアント装置２００の具体的な構成例を示すブロック図である。クライアント装置２００は、例えば、ストリーム受信部２０２と、記憶部２０４と、通信部２０６と、表示制御部２０８と、入力部２１０と、を備える。
ストリーム受信部２０２は、放送局等から送信される放送波からストリームを受信し、ストリームから取得した映像データを表示制御部２０８に伝送する。また、ストリーム受信部２０２は、受信したコンテンツを通信部２０６を介してネットワークサーバ１００に送信する。また、ストリーム受信部２０２は、受信したコンテンツを記憶部２０４に記憶させることができる。
記憶部２０４は、ストリーム受信部２０２で取得されたコンテンツのデータを記憶する。また、通信部２０６は、ストリーム受信部２０２で取得されたコンテンツのデータ又は記憶部２０４に記憶されたコンテンツのデータをネットワーク１０を介してネットワークサーバ１００に送信する。
表示制御部２０８は、ストリーム受信部２０２で取得されたコンテンツを接続された表示機器に表示させるように制御する。なお、ここでいう表示機器は、クライアント装置２００にＨＤＭＩケーブル等を使用して直接接続されるものであり、ＤＬＮＡ等のネットワークを介してネットワークサーバ１００に接続される表示装置３００とは異なる。
入力部２１０は、マウス、キーボード、タッチパネル、ボタン、マイク、スイッチおよびレバーなどユーザが情報を入力するための入力手段を有しており、入力された操作に応じてストリーム受信部２０２及び通信部２０６等の動作を制御する制御信号を伝送する。
＜５．ネットワークサーバからコンテンツの配信を受ける表示装置の構成＞
続いて、表示装置３００について説明する。表示装置３００は、ネットワークサーバ１００からＤＬＮＡなどのネットワーク１１を介してコンテンツの配信を受け、コンテンツを表示出力する装置である。以下に表示装置３００の具体的な構成例について説明する。
図５は、本発明の一実施形態に係るネットワークサーバからネットワークを介してコンテンツの配信を受ける表示装置３００の具体的な構成例を示すブロック図である。表示装置３００は、例えば、通信部３０２、デコード部３０４と、表示制御部３０６と、表示出力部３０８と、入力部３１０を備える。
通信部３０２は、ネットワーク１１を介してネットワークサーバ１００と双方向通信を行う。通信部３０２は、ネットワークサーバ１００からコンテンツの配信を受ける。
デコード部３０４は、通信部３０２から符号化されたコンテンツのデータを受け取り、データを復号する。また、デコード部３０４は、デコードした画像データを表示制御部３０６を介して表示出力部３０８に提供する。ここで、表示装置３００のデコード部３０４は、通常、デコード可能なメディア形式が限られている。したがって、表示装置３００がネットワークサーバ１００からネットワークを介してコンテンツの配信を受ける場合は、デコード部３０４がデコードできるメディア形式でコンテンツを受信することが必要となる。
表示制御部３０６は、ネットワークサーバ１００から配信されたコンテンツの映像及び音声データを表示出力部３０８に表示させるように制御する。
表示出力部３０８は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）ディスプレイ装置、液晶ディスプレイ（ＬＣＤ）装置、ＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）などの表示装置で構成される。表示出力部３０８は、表示制御部３０６による制御に従ってコンテンツの映像及び音声データなどを表示する。
入力部３１０は、ユーザが表示装置３００を操作をするための指示の入力を受け付ける装置であり、ユーザが入力した指示に応じて、表示装置３００の動作を制御するための電気信号を各部へ伝送する。
＜６．本発明の一実施形態に係るネットワークサーバのハードウェア構成の具体例＞
続いて、本発明の一実施形態に係るネットワークサーバ１００のハードウェア構成について説明する。本発明の一実施形態に係るネットワークサーバ１００は、図５で示されるハードウェア構成によって実現される。
ネットワークサーバ１００は、デジタルチューナ４０１と、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４０２と、デコーダ４０３と、を備える。また、ネットワークサーバ１００は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）４０４と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）４０６と、ホストバス４０８ａとを備える。さらに、ネットワークサーバ１００は、ブリッジ４０８と、外部バス４０８ｂと、インタフェース４１０と、入力装置４１２と、ストレージ装置（ＨＤＤ）４１４と、ドライブ４１６と、接続ポート４１８と、通信装置４２０とを備える。
デジタルチューナ４０１は、放送波を処理して、所定のトランスポートストリームを取り出す。例えば、デジタル放送の場合、デジタルチューナ４０１は、デジタルアンテナから送られてくる放送波信号を受け取り、受け取った放送波信号をＭＰＥＧ２−ＴＳ（ＭＰＥＧ２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）に変換する。デジタルチューナ４０１は、図１及び２には図示されていない。
ＣＰＵ４０２は、演算処理装置および制御装置として機能し、各種プログラムに従ってネットワークサーバ１００内の動作全般を制御する。また、ＣＰＵ４０２は、マイクロプロセッサであってもよい。ＲＯＭ４０４は、ＣＰＵ４０２が使用するプログラムや演算パラメータ等を記憶する。ＲＡＭ４０６は、ＣＰＵ４０２の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一時記憶する。これらはＣＰＵバスなどから構成されるホストバス４０８ａにより相互に接続されている。ＣＰＵ４０２は、ストレージ装置４１４等に格納されたプログラムを実行することによって、図１の変換判定部１０４、形式変換部１０６、配信部１０８等の機能を実現する。
デコーダ４０３は、デジタルチューナ４０１から送られてくるＭＰＥＧ２−ＴＳを受け取り、音声についてはＭＰＥＧ２−ＴＳからデジタルの音声信号に変換し、映像についてはＭＰＥＧ２−ＴＳからデジタルコンポーネント信号に変換する。なお、デコーダ４０３は、図１及び２には図示されていない。
ホストバス４０８ａは、ブリッジ４０８を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バスなどの外部バス４０８ｂに接続されている。なお、必ずしもホストバス４０８ａ、ブリッジ４０８および外部バス４０８ｂを分離構成する必要はなく、一のバスにこれらの機能を実装してもよい。
入力装置４１２は、マウス、キーボード、タッチパネル、ボタン、マイク、スイッチおよびレバーなどユーザが情報を入力するための入力手段と、ユーザによる入力に基づいて入力信号を生成し、ＣＰＵ４０２に出力する入力制御回路などから構成されている。ネットワークサーバ１００に対して各種のデータを入力したり処理動作を指示したりすることができる。入力装置４１２は、図１の入力部２１０に対応する。
ストレージ装置４１４は、記憶媒体、記憶媒体にデータを記録する記録装置、記憶媒体からデータを読み出す読出し装置および記憶媒体に記録されたデータを削除する削除装置などを含んでもよい。ストレージ装置４１４は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）で構成される。このストレージ装置４１４は、ハードディスクを駆動し、ＣＰＵ４０２が実行するプログラムや各種データを格納する。ストレージ装置４１４は、図１のメディア形式情報記憶部１１０及びコンテンツ記憶部１１２、又は、図２のＨＤＤ１７０及びＨＤＤ１７５に対応する。
ドライブ４１６は、記憶媒体用リーダライタであり、ネットワークサーバに内蔵、あるいは外付けされる。ドライブ４１６は、装着されている磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記録媒体にデータを読み書きをすることができる。ドライブ４１６は、図１の書き込み部１１４又は図２のブルーレイディスク書込部１９２に対応する。
接続ポート４１８は、外部機器と接続されるインタフェースであって、例えば、ＨＤＭＩなどによりデータ伝送可能な外部機器との接続口である。また、通信装置４２０は、例えば、通信網１０に接続するための通信デバイス等で構成された通信インタフェースである。また、通信装置４２０は、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）対応通信装置であっても、ワイヤレスＵＳＢ対応通信装置であっても、有線による通信を行うワイヤー通信装置であってもよい。接続ポート４１８及び通信装置４２０は、図１の受信部１０２及び配信部１０８、又は、図２の第１パイプライン変換部１５０及び第２パイプライン変換部１８０の通信機能を実現する。
クライアント装置２００もまた、図４で示されるハードウェア構成によって実現される。
＜７．ネットワークサーバ及びクライアント装置の前提技術＞
続いて、ネットワークサーバ１００によるメディア形式変換の流れについて詳細に説明する前提として、ネットワークサーバ１００及びクライアント装置２００の前提技術についてさらに詳しく説明する。なお、以下の説明では、クライアント装置２００をＳＴＢ／ＰＶＲという。ＳＴＢとは、セットトップボックスであり、ＰＶＲとは、パーソナルビデオレコーダである。
放送オペレータ、ＳＴＢ／ＰＶＲベンダは、ＳＴＢ／ＰＶＲを廉価に販売／レンタルしたい思惑から、ＳＴＢ／ＰＶＲに対するコスト要求が厳しくなりがちである。そのため、ＳＴＢ／ＰＶＲからネットワークサーバへのコンテンツのアップロード時のメディア形式として自己の放送に用いられている形式に最も近いメディア形式を望むことが考えられる。自己の放送に用いられている形式に最も近いものとは、例えば、ビデオについて、ＭＰＥＧ−２（ＩＳＯ１３８１８−２）形式が挙げられる。また、例えば、Ｈ．２６４ＡＶＣ形式をＭＰＥＧ−２システムレイヤー(ＩＳＯ１３８１８−１)で定められるＴｒａｎｓｆｅｒＳｔｒｅａｍ（以下ＴＳ）形式でパケット化したものが挙げられる。また、ＳＴＢ／ＰＶＲなどのクライアント装置は、デジタルチューナー等からリアルタイム配信可能なコンテンツをリアルタイムにネットワークサーバにアップロードすることが考えられる。
これを実現するため、ネットワークサーバが受付可能なメディア形式に合わせるためにメディア形式変換を実時間処理できるように、ＳＴＢ／ＰＶＲのＣＰＵ等のハードウェア構成を高スペックなものとすると、コスト増を招くこととなる。ＳＴＢ／ＰＶＲは、上記放送に用いられている複数プログラムが混在したフルＴＳストリームから、１つ（規格上は、または複数と書かれている）のプログラムを抽出しシングルプログラムＴＳとする。ＳＴＢ／ＰＶＲは、さらにＡＲＩＢ ＳＴＤ Ｂ２１やＤＶＢで定められた形式に適合するようＳＩ／ＰＳＩ情報パケットを変換したパーシャルＴＳとしたコンテンツ（以下タイムスタンプなしＴＳ形式）をネットワークサーバへアップロードする。このメディア形式は、メタデータにおいて、Mime-type=Video/mpeg、Profile-name=MPEG_TS_HD_EU_ISOなどと記述される。さらにこれをＤＴＣＰＩＰで著作権保護したメディア形式は、Mime-type=applilcation/x-dtcp1;CONTENTFORMAT=Video/mpeg、Profile-nameは=PEG_TS_HD_EU_ISOなどと記述される。
これに対して、パーシャルシングルプログラムＴＳに４バイトのタイムスタンプを付加したタイムスタンプ付きＴＳ形式がＤＬＮＡ対応テレビなどで一般的に用いられる。タイムスタンプ付きＴＳ形式は、例えば、ARIB STD B21等で定められている。実時間以外での伝送やＩＰネットワークなどの高ジッター伝送、ストレージなどを経由したストリームのデコードに際してパケット単位の時間軸情報があることで、デコーダへの伝送量をパケット単位で制御できる利点があるからである。このメディア形式は、メタデータにおいてMime-typeがvideo/vnd.hdlnk.mpeg-tts、Profile-nameがMPEG_TS_HD_EU_Tなどと記述される。さらにこれをＤＴＣＰＩＰで著作権保護したメディア形式は、Mime-type=applilcation/x-dtcp1;CONTENTFORMAT=Video/vnd.hdlnk.mpeg-tts、Profile-name=MPEG_TS_HD_EU_Tなどと記述される。
＜８．本発明の一実施形態に係るネットワークサーバによるメディア形式変換の流れ＞
続いて、図６を参照しながら、本発明の一実施形態に係るネットワークサーバ１００がコンテンツのメディア形式を変換する処理の流れについて説明する。図６は、本発明の一実施形態に係るネットワークサーバ１００がコンテンツのメディア形式を変換するまでの流れの一例を示したフローチャートである。
＜メディア形式変換例１＞
変換判定部１０４は、クライアント機器２００から受信部１０２がコンテンツを受信する前提として、クライアント機器２００からコンテンツのメタデータを取得する（ステップＳ１００）。変換判定部１０４は、メディア形式情報記憶部１１０を参照し、メディア形式変換を行う必要があるメディア形式のリストを取得する（ステップＳ１０２）。変換判定部１０４は、取得したメディア形式のリスト及びコンテンツのメタデータに基づいて、コンテンツのメディア形式を変換する必要があるか否かを判定する（ステップＳ１０４）。
ステップＳ１０４でメディア形式変換を行う必要があると判定された場合、変換判定部１０４は、メディア形式情報記憶部１１０から変換後のメディア形式として選択すべきメディア形式の優先順位に関する情報を取得する（ステップＳ１０６）。変換判定部１０４は、優先順位に関する情報に従って変換後のメディア形式を決定し、決定したメディア形式を受信部１０２及び形式変換部１０６に通知する。続いて、受信部１０２は、クライアント機器２００からコンテンツを受信し（ステップＳ１０８）、受信したコンテンツを形式変換部１０６に提供する。形式変換部１０６は、コンテンツのメディア形式を変換判定部１０４で決定されたメディア形式に変換する（ステップＳ１１０）。
ステップＳ１０４でメディア形式変換を行う必要がないと判定された場合、変換判定部１０４は、メディア形式変換を行う必要がない旨を受信部１０２へ伝達し、受信部１０２は、クライアント機器２００からコンテンツを受信する（ステップＳ１１２）。このとき、形式変換部１０６は、メディア形式変換を行わない。
コンテンツ記憶部１１２は、ステップＳ１１０又はステップＳ１１２において得られたコンテンツデータを記憶する（ステップＳ１１４）。その後、配信部１０８は、表示装置３００からのリクエストに応じて、コンテンツ記憶部１１２に記憶されたコンテンツをネットワーク１１を介して接続された表示装置３００に配信する（ステップＳ１１６）。
続いて、図７を参照しながら、本発明の一実施形態に係るネットワークサーバ１００がメディア形式を変換する流れについて説明する。図７は、本発明の一実施形態に係るネットワークサーバ１００がコンテンツのメディア形式を変換するまでの流れの一例を示したフローチャートである。
＜メディア形式変換例２＞
変換判定部１０４は、クライアント機器２００から受信部１０２がコンテンツを受信する前提として、クライアント機器２００からコンテンツのメタデータを取得する（ステップＳ２００）。変換判定部１０４は、取得したメタデータに基づいて、クライアント機器２００から受信するコンテンツがタイムスタンプを有するメディア形式であるか否かを判定する（ステップＳ２０２）。
クライアント機器２００から受信するコンテンツがタイムスタンプを有しないメディア形式であるとステップＳ２０２で判定された場合、変換判定部１０４は、その旨を受信部１０２及び形式変換部１０６に伝達する。続いて、受信部１０２がクライアント機器２００からコンテンツを受信し（ステップＳ２０４）、形式変換部１０６は、クライアント機器２００から受信したコンテンツにタイムスタンプ付加処理を行う（ステップＳ２１０）。
クライアント機器２００から受信するコンテンツがタイムスタンプを有するメディア形式であるとステップＳ２０２で判定された場合、変換判定部１０４は、その旨を受信部１０２及び形式変換部１０６に伝達する。続いて、受信部１０２がクライアント機器２００からコンテンツを受信し（ステップＳ２０８）、タイムスタンプ付加処理が行われずにコンテンツがそのままコンテンツ記憶部１１２に記憶される（ステップＳ２１０）。
その後、配信部１０８は、表示装置３００からのリクエストに応じて、コンテンツ記憶部１１２に記憶されたコンテンツを読み出してネットワーク１１を介して接続された表示装置３００に配信する（ステップＳ２１２）。
ネットワークサーバ１００は、上記のようにタイムスタンプ付加処理を行うことによって、タイムスタンプ付きＴＳ形式、及び、タイムスタンプなしＴＳ形式の両者のアップロードを受け付けることができる。すなわち、ネットワークサーバ１００は、タイムスタンプなしＴＳ形式のコンテンツをタイムスタンプ付きＴＳ形式に変換して配信を行うことで、表示装置３００である既存のＤＬＮＡ対応ＴＶなどと良好な接続性を実現する。そのため、クライアント装置２００とネットワークサーバ１００との間のメディア形式のギャップを埋めることができ、より多種多様なＳＴＢ／ＰＶＲとの互換性が実現される。なお、上述したように、タイムスタンプ付きＴＳ形式とは、パーシャルシングルプログラムＴＳに４バイトのタイムスタンプを付加したものであり、表示装置３００である既存のＤＬＮＡ対応テレビなどで一般的に用いられる形式である。
ここで、ネットワークサーバ１００は、タイムスタンプなしＴＳ形式のストリームを受信すると同時に、実時間情報やＴＳストリーム中のＰＣＲ情報をもとにタイムスタンプを付加し、タイムスタンプ付きＴＳ形式に即時変換する。これをオンザフライタイムスタンピングという。あるいは、ネットワークサーバ１００は、コンテンツをいったんストレージに蓄積したのち、上記と同様の変換処理を配信部１０８（ハードウェア処理又はＣＰＵ及びソフトウェアによる処理）によって行うことも可能である。
このほか、ネットワークサーバ１００では、ＢＤ規格にオーディオやビデオの符号化層を適合させるために、ビデオストリームや、オーディオストリームのトランスコードを行う。この際、ネットワークサーバ１００は、ＢＤ規格に適合したタイムスタンプを付加してもよい。ＢＤ規格に適合したタイムスタンプは、上記タイムスタンプ付きＴＳ形式とわずかに形式が異なっているが変換は容易である。ネットワークサーバ１００は、こういった変換を、著作権保護用にＤＴＣＰＩＰ等でリンクプロテクションされたストリームの復号処理や、ローカルストレージへの格納時の再暗号化などと同時に行うこともできる。
＜９．メディア形式変換作業におけるネットワークサーバとクライアント装置との間における情報の流れ＞
続いて、図８を参照しながら、メディア形式変換作業におけるネットワークサーバ１００とクライアント装置２００との間における情報の流れについて説明する。図８は、ネットワークサーバ１００とクライアント装置２００との間における情報の流れの一例を示したシーケンス図である。
まず、ユーザーは、クライアント装置２００のユーザーインターフェースにより、リモコンなどを通じて、アップロードするコンテンツ、アップロード先の機器及びドライブ（ＢＤ又はＨＤＤか等）を対話的に選択する（ステップＳ３００〜Ａ３３８）。この過程で、ＨＤＲＬ、ＤＬＮＡ、又は、ＵＰｎＰに規定された方法で、クライアント装置２００とネットワークサーバ１００とのネットワーク接続設定がなされる。クライアント装置２００は、ネットワークサーバ１００にアップロードを行う前に、CDS:X_GetDLNAUploadProfilesリクエストを発行する（ステップＳ３１６）。リクエストに対して、ネットワークサーバ１００は、当該サーバがどのProfile-nameを取扱可能かをクライアント装置２００に通知する（ステップＳ３１８）。クライアント装置２００からのCDS:X_GetDLNAUploadProfilesリクエストに対し、ネットワークサーバ１００は、MPEG_TS_HD_EU_ISO、MPEG_TS_HD_EU_Tのどちらも受けられる、とレスポンスする（ステップＳ３１８）。ここで、ネットワークサーバ１００は、すでにタイムスタンプ付きＴＳ形式になっているコンテンツのアップロードを受けるときには、上記のタイムスタンプ付加等の変換を行う必要はないので、これを自動的に判別し、タイムスタンプ付加を行わない。
アップロードするコンテンツ及びアップロード先の選択において、まず、クライアント装置２００であるＳＴＢ／ＰＶＲは、ネットワークサーバ１００であるＢＤレコーダやその他のサーバー機器を発見する（ステップＳ３００及びＳ３０２）。続いて、クライアント装置２００は、ユーザーにそのリストを提示する（ステップＳ３０４）。ユーザーは、提示された機器のリストから１のサーバを選択する（ステップＳ３０６）。クライアント装置２００であるＳＴＢ／ＰＶＲは、選択されたネットワークサーバ１００からドライブのリストや関連情報を取得し（ステップＳ３０８〜ステップＳ３１８）、ユーザーにそのリストや関連情報を提示する（ステップＳ３２４）。ユーザーが１のドライブを選択し、さらにユーザーがアップロードしたいクライアント装置２００内のコンテンツを選択する（ステップＳ３２６、ステップＳ３３４）。クライアント装置２００は、選択されたコンテンツのメタデータ、選択されたドライブＩＤをネットワークサーバ１００に送信する（ステップＳ３３６）。これに対して、ネットワークサーバ１００は、当該ドライブ内のコンテナＩＤをクライアント装置２００に通知する（ステップＳ３３８）。なお、図８において、ユーザに情報を提示する方法としては、例えば、クライアント装置２００の表示制御部２０８と接続された表示装置等に情報を表示することによって行われる。
ここで、ステップＳ３２０〜ステップＳ３３６において行われる通信は、ＨＤＲＬで規定されたネットワークを介して行うことができる。また、その他のステップで行われる通信は、ＤＬＮＡで規定されたネットワークを介して行うことができる。
ここで、ＨＤＲＬで規定されたネットワークでは、クライアント装置２００とネットワークサーバ１００とは、追加定義されたＣＤＳアクションによってドライブ選択に関連する情報をやりとりする。クライアント装置２００のCDS:CreateObectリクエストに対して、ネットワークサーバ１００がレスポンス中のres@importURIの値を生成する。このとき、ネットワークサーバ１００は、CDS:CreateObjectリクエストのContainerIDを参照して、ドライブ選択情報をURIに内包させたり、URIとドライブ選択情報の対照テーブルなどを作成する。このようなＣＤＳアクションによって、クライアント装置２００とネットワークサーバ１００とは、ドライブ選択に関連する情報等をやりとりすることができる。
クライアント装置２００は、ネットワークサーバ１００にコンテンツバイナリのアップロードを行う前に、CDS:CreateObjectリクエストを発行することで、メタデータデータベースであるＣＤＳにオブジェクトを作成する（ステップＳ３４０）。この際、コンテンツのメタデータをElements入力引数で指定する。Elements入力引数の値は、DIDL-Liteというスキーマを持つＸＭＬ文書である。その中のエレメントのProtocolInfoアトリビュートの値である文字列の第３フィールドと第４フィールドに、Mime-typeとProfile-nameを指定する。クライアント装置２００は、HTTPPOSTリクエストを行い（ステップＳ３４４）、これをネットワークサーバ１００が許可すると、ネットワークサーバ１００がセットアップされる（ステップＳ３４６）。セットアップされたネットワークサーバ１００は、コンテンツのアップロードを許可する旨をクライアント装置２００に通知する（ステップＳ３４８）。
ここで、クライアント装置２００がCDS:CreateObject等をリクエストする（ステップＳ３４０）ときには、自身のアップロード時のコンテンツストリームに合致したProtocolInfoを指定するようにする。クライアント装置２００は、タイムスタンプなしＴＳ形式でコンテンツをアップロードする場合、Mime-type=Video/mpeg、Profile-name=MPEG_TS_HD_EU_ISOとしたものをProtocolInfoに指定し、CDS:CreateObjectリクエストを行う。ネットワークサーバ１００は、CreateObjectリクエストを受信した時に、レスポンスを返すまでに、Mime-type、Profile-Nameを受け取る。ネットワークサーバ１００は、Mime-type、Profile-Nameをキーに、テーブル参照や条件判断などから、変換なしで(1)受付可、(2)変換して受付可、(3)受付不可のいずれかを決定する。(2)の場合はさらに、ＣＤＳ１６０が、変換後のMime-type、Profile-name、変換モジュールへの参照、サイズ見積りモジュールへの参照などを得る。変換後のMime-type、Profile-nameをもとにProtocolInfoを作り直す。変換前のサイズが指定されているときは、変換前後のMime-type、profile-name又はサイズ見積りモジュールへの参照をもとに変換後の見積りサイズを計算する。変換後の見積りサイズは、CDS::CreateObjectレスポンス中のResult出力引数中のres@size属性などに反映される。サイズの取扱の詳細については後述する。
（ネットワークサーバ１００におけるメタデータの取り扱い）
ネットワークサーバ１００は、上記サイズに関する情報をオブジェクトのメタデータとしてＣＤＳ１６０が管理するＨＤＤ１７０に記憶させる。また、ネットワークサーバ１００は、変換前のMime-type、Profile-name、変換モジュールへの参照、サイズ見積りモジュールへの参照などをＣＤＳ１６０内の当該オブジェクトと連携してＨＤＤ１７０に記憶させる。ＣＤＳ１６０は、アップロードの完了をまたずに配信するおっかけ再生に対応するために、テキスト値に配信用ＵＲＬを即座に生成してもよい。ＣＤＳ１６０は、コンテンツバイナリのアップロード先のストレージの実体（ドライブやディレクトリ）をメタデータなどから決定し、そのＵＲＬとなるres@importURIの値を生成する。以上の後CSD::CreateObjectレスポンスが返される。従来とは異なり、CDS::CreateObjectのリクエスト中のElements入力引数と、レスポンス中のResult出力引数のそれぞれの値で、ProtocolInfoなどのメタデータが異なるが、ＤＬＮＡ規定ではメディアサーバはメタデータの修正を行うことができる。
メディア形式の表現は、ＨＤＲＬ、ＤＬＮＡ、ＵＰｎＰ又はＡＲＩＢの各規定により、また、国や放送媒体の違いなどによって、多様な形式が用いられる。しかし、Mime-type及びProfile-nameによってコンテンツのメディア形式が識別される点では、上記各規定は一致している。Mime-type及びProfile-nameは、ProtocolInfoと呼ばれる文字列の第３フィールドと第４フィールドに含まれる。多くの場合、ネットワークメディアサーバは、クライアント装置から受信したメタデータについて、コンテンツサイズ、アドレス情報などを修正し、メディア形式についてはほぼそのまま記録し、後のCDS:Browseリクエストに応えるものであった。これに対し、本実施形態では、上述のようにコンテンツバイナリの全体または一部は、アップロードとともにネットワークサーバ１００内のＨＤＤ１７５、ブルーレイディスク書込部１９２、バッファメモリ（図示せず）などにおいて記録される。
（コンテンツのアップロード開始後のネットワークサーバ１００の動作）
コンテンツバイナリの全体または一部のアップロードが成功すると、ネットワークサーバ１００はアップロード済みのコンテンツをネットワーク経由で配信することができる。表示装置３００であるＤＬＮＡ対応ＴＶは、CDS:Browseリクエストを発行し、そのレスポンスのResult出力引数により当該サーバ内のコンテンツリストとそのメタデータを得ることができる。Result出力引数の値はElementsと同じスキーマを持つＸＭＬ文書であり、その中のエレメントのProtocolInfoアトリビュートの値である文字列の第３フィールドと第４フィールドに、Mime-typeとProfile-nameが示される。
なお、ネットワークサーバ１００は、コンテンツバイナリアップロードの受信開始時にもCDS::CreateObjectリクエスト受信時（ステップＳ３４０）と同じようなメディア変換方針決定を行うことができる。コンテンツバイナリアップロードは、一般的に、ＨＴＴＰ ＰＯＳＴメソッドにより行われ、ＤＬＮＡの規定では、Content-Typeヘッダにて、Mimeが示され、contentFeatures.dlna.orgヘッダにて、profile-nameが示される。これらを変換前のMime-type、profile-nameキーとして、テーブル検索が可能である。しかし、contentFeatures.dlna.orgヘッダが規定上オプションであることなどから、必ずしもprofile-nameが得られない場合はこの方法だけではうまくいかない場合も考えられる。このため、ＨＴＴＰ ＰＯＳＴリクエスト行に示されるパスがCDS:CreateObjectレスポンス時に返したres@importURIの値に呼応することを利用してもよい。クライアント装置２００及び表示装置３００は、res@importURIの値をキーとしてネットワークサーバ１００内部のＣＤＳ管理機能（ＣＤＳ１６０）に問い合わせを行うことができる。これによって、作成済みのオブジェクトへの参照とそれに連携されて記憶されている情報が得られる。
また、別の方法として、ネットワークサーバ１００は、CDS:CreateObjectレスポンスを生成する時点で、後のアップロード時に必要となる情報を、res@importURIのクエリ文字列中にエンコードして埋め込むようにしてもよい。ネットワークサーバ１００は、コンテンツアップロードを受けるときに、クライアント装置２００から受信したPOSTリクエスト行のパスからクエリ部分を抽出デコードすることで、必要な情報を得ることもできる。ネットワークサーバ１００は、コンテンツバイナリのアップロード時に、変換モジュールの要不要やその他の処理の選択を行う必要がある。上記の変換モジュール参照または変換前後のMime-type、Profile-nameなどから、この選択を行うことができる。
続いて、変換前後のメタデータに記述されるMime-type、Profile-nameを得て、変換後のメディア形式の選択を行う実装について、コンテンツバイナリのアップロード開示時点でのネットワークサーバ１００の処理（Ｏｐｅｎ処理）について説明する。
（第１パイプライン変換部１５０のメディア変換処理）
ネットワークサーバ１００がコンテンツバイナリをネットワークを介してクライアント装置２００から受信してストレージする処理は、複数のライターフィルタクラスオブジェクトをスタックする形（第１パイプライン変換部１５０）で構成されている。フィルタは、純粋なソフトウェアの場合もあるし、ハードウェアやデバイスドライバを含む場合もある。最初に、最もストレージよりのローカルストレージライタークラスオブジェクトが無条件に作成される。
次に、変換後のMime-type、Profile-nameがタイムスタンプ付きＴＳ形式の場合、ＴＴＳフィルタライタークラスオブジェクト（Ｔｔｓ１５４）がスタックされる。タイムシークやビットレート演算などタイムスタンプを利用した時間に関連する処理が行われる。次にＤＴＣＰＩＰコンテンツかつ変換前のコンテンツが上記パーシャルシングルプログラムＴＳの場合は、タイムスタンプ付加機能ありＤＴＣＰＩＰフィルタ（ＤＴＣＰ ｄｅｃ１５１及びＯｆｔｓ１５２）がスタックされる。ＤＴＣＰＩＰコンテンツかつ変換前のコンテンツが上記タイムスタンプ付きＴＳの場合は、タイムスタンプ付加機能なしＤＴＣＰＩＰフィルタ（ＤＴＣＰ ｄｅｃ１５１）がスタックされる。非ＤＴＣＰＩＰコンテンツかつ変換前のコンテンツが上記パーシャルシングルプログラムＴＳの場合は、タイムスタンプ付加のみを行うフィルタ（Ｏｆｔｓ１５２）がスタックされる。非ＤＴＣＰＩＰコンテンツかつ変換前のコンテンツが上記タイムスタンプ付きＴＳ形式の場合は、何もスタックされない。これらがパイプライン的に変換処理を行うことでネットワーク上の形式が、最終的にストレージ上の形式に変換される。メディア形式が変換されたコンテンツのデータは、ローカルストレージに保存される。なお、ＨＤＤとＢＤの両方を持つＢＤレコーダのようなネットワークサーバ１００において、ストレージ先の選択は、上記メディア形式に基づく選択とは別に行われる。
上記フィルタによる各処理は、ＣＤＳ１６０から提供されるメディア形式変換前のメタデータ及びメディア形式変換後のメタデータ等に従って、ライターセットアップ部１６２によって使用されるか否か（図２のｏｎ／ｏｆｆ）が決定される。また、第２パイプライン変換部１８０におけるフィルタ処理は、ＨＤＤ１７５に保存されたコンテンツのメタデータ等に従って、リーダーセットアップ部１６４によって使用されるか否か（図２のｏｎ／ｏｆｆ）が決定される。リーダーセットアップ部１６４は、第２パイプライン変換部１８０で変換されたコンテンツの変換後のメタデータを１６０に通知する。
ＤＴＣＰＩＰ処理（ＤＴＣＰ ｄｅｃ１５１）とタイムスタンプ付加（Ｏｆｔｓ１５２）がフィルタとして分離していないのは、著作権保護のための復号、タイムスタンプ付加及びローカル暗号化を一体的なハードウェアで行い、ロバストネスを稼ぐためである。各部を異なるフィルタに分離した実装やソフトウェアだけでの実装なども許容されている。また、タイムスタンプ付加は、かならずしも処理パイプラインの先頭で行われるのではなく、中間で行われる場合もある。
変換前において、ＤＴＣＰＩＰかつパーシャルシングルプログラムＴＳの場合は、メディア形式は、例えば、Mime-type=application/x-dtcp1;CONTENTFORMAT=Video/mpeg、Profile-name=MPEG_TS_HD_EU_ISO等とメタデータに記述される。上記メタデータで表されるメディア形式のコンテンツは、ＤＴＣＰＩＰの復号処理（ＤＴＣＰ ｄｅｃ１５１）、タイムスタンプ付加処理（Ｏｆｔｓ１５２）、ローカル暗号化処理（Ｌｏｃａｌ ｅｎｃ１５３）の順で処理される。さらに、コンテンツは、ＴＴＳライターフィルタ処理（Ｔｔｓ１５４）、ローカルストレージ書き込み（Ｌｏｃａｌ １５５）の順で処理される。それによって、上記メタデータで表されるメディア形式を有するコンテンツは、Mime-type=application/x-dtcp1;CONTENTFORMAT=video/vnd.hdlnk.mpeg-tts、Profile-name=MPEG_TS_HD_EU_Tとメタデータに記述されたメディア形式に変換される。
（コンテンツのネットワークドメインサイズに関する情報の取り扱い）
ＣＤＳ１６０におけるコンテンツのネットワークドメインサイズに関する情報の取り扱いについて以下に説明する。サイズの取扱について、res@sizeは、ネットワーク上でのペイロードバイト数（ネットワークドメインサイズ）を表すものとＤＬＮＡ等で規定されている。CDS:CreateObjectリクエスト時にres@size指定がある場合は、ＣＤＳ１６０は、その時点で、変換後のサイズをサイズ見積りモジュールによって見積もることができる。
しかし、以下のような理由でこの値はその後修正される可能性がある。ネットワークサーバ１００がアップロードの受信開始時にchunked以外の値がContent-Length:ヘッダに指定されている場合、さらにサイズ見積りを行い、res@sizeに反映させることが考えられる。さらに、配信時のＨＴＴＰ ＧＥＴレスポンスのContent-Lengthに示す値などは、ＨＴＴＰプロトコルの要請から、厳密に実際送信するＢｏｄｙサイズに一致している必要がある。それにもかかわらず、アップロードが完了するまでは、未知のパラメータが存在し、厳密な意味ではサイズや変換パラメータが確定しない。例えば、メディア形式の変換がない場合でさえ、ＤＴＣＰＩＰ処理（ＤＴＣＰ ｄｅｃ１５１）にて、動的に変化するＰＣＰ長さ(ＬＥＮ)のために、アップロード時と配信時でネットワークドメインサイズがかわることが考えられる。
また、CreateObject時にres@sizeが指定されていなく、かつ、アップロード開始時に、Content-Length:chunkedの場合などは、実際にアップロードが完了しないとコンテンツサイズがネットワークサーバ１００にはわからない。よってアップロード完了時にも更新res@sizeを更新する必要が生じる場合がある。さらにネットワークサーバ１００がレンジヘッダ付きＨＴＴＰ ＧＥＴリクエストによるシーク要求を受ける場合には、デコーダフレンドリネスなどの処理を含めて、サイズの厳密な計算が要求される。こうしたことなどから、アップロード完了時や配信時のサイズ変換モジュールは、CDS:CreateObject時などに用いる見積りモジュールとは別に、上記ライターフィルタの反対の処理を行うリーダーフィルタクラスの１メソッドとして実装される。そのため、ＣＤＳ１６０は、実際のストレージサイズをもとに、スタックされたリーダーフィルタ毎にサイズを変換していく形で正確なサイズを求めることができる。ネットワークサーバ１００は、追っかけ再生等のようにアップロードが完了する前に表示装置３００からＨＴＴＰ ＧＥＴリクエストを受けた場合には、すでの受信したサイズをもとに表示装置３００にレスポンスしてもよい。あるいは、Contet-Length:chunkedとしてchunked encodeingによりレスポンスすることが考えられる。
なお、本発明のネットワークサーバにおいて、変換前のコンテンツと変換後のコンテンツの両方を保存しておくことも可能である。この場合、複数のリソース（CDSでの<res>エレメントに対応する）を使用したり、別のコンテナやアイテムを生成するなどの方法が考えられる。また、オンザフライでメディア変換を行う実装を示したが、いったんオリジナルのメディア形式でアップロード受信したものをオフラインでメディア形式変換することもできる。
以上のように、本発明の一実施形態に係るネットワークサーバ１００によれば、下記（１）及び（２）の有利な効果が得られる。（１）ＰＶＲ／ＳＴＢ等のクライアント装置２００及びＢＤレコーダ等のネットワークサーバ１００（メディアサーバ）のコスト戦略に応じて、自由に機能の振り分けを行うことができる。（２）ネットワークサーバ１００からの配信においてより互換性に優れたメディア形式を選択することができるなど、メディア形式を戦略的な理由により決定し得る。
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
例えば、上記実施形態では、ＨＤＲＬ、ＤＬＮＡで規定されたネットワークである場合を説明したが、本発明はかかる例に限定されない。
１０、１１ ネットワーク
１００ ネットワークサーバ
１０２ 受信部
１０４ 変換判定部
１０６ 形式変換部
１０８ 配信部
１１０ メディア形式情報記憶部
１１２ コンテンツ記憶部
１１４ 書き込み部
１５０ 第１パイプライン変換部１５０
１６０ コンテンツディレクトリサービス
１６２ ライターセットアップ部
１６４ リーダーセットアップ部
１７０ 第１ハードディスクドライブ
１７５ 第２ハードディスクドライブ
１８０ 第２パイプライン変換部
２００ クライアント装置
３００ 表示装置

Claims (9)

  1. ネットワークを介して接続されたクライアント装置からコンテンツを受信する受信部と、
    前記コンテンツのメタデータを取得し、前記メタデータに応じて前記コンテンツのメディア形式を変換するか否かを決定し、前記メタデータに応じて変換後のメディア形式を選択する変換判定部と、
    前記コンテンツのメディア形式を前記変換判定部で選択されたメディア形式に変換する形式変換部と、
    を備えるネットワークサーバ。
  2. 前記変換判定部は、前記受信部が前記コンテンツを受信する前提として、前記メタデータを前記クライアント装置から取得する、請求項１に記載のネットワークサーバ。
  3. 前記クライアント装置から受信したコンテンツ又は前記形式変換部で変換されたコンテンツをネットワークを介して接続された表示装置に配信する配信部をさらに備える、請求項１に記載のネットワークサーバ。
  4. 変換後のメディア形式の優先順位を示す情報が記憶されたメディア形式情報記憶部をさらに備え、
    前記変換判定部は、前記優先順位に従って変換後のメディア形式を選択する、請求項１に記載のネットワークサーバ。
  5. 前記変換判定部は、前記コンテンツのメディア形式がタイムスタンプを有しないものであるとき、変換後のメディア形式としてタイムスタンプが付加されたメディア形式を選択する、請求項４に記載のネットワークサーバ。
  6. 前記クライアント装置と前記受信部とはＤＬＮＡによるネットワークを介して通信し、
    前記変換判定部は、前記クライアント装置から送信されたＣＤＳ：ＣｒｅａｔｅＯｂｊｅｃｔリクエストの入力引数で指定されたプロトコル情報に基づいてメディア形式を変換するか否かを決定し、変換後のメディア形式を決定する、請求項１に記載のネットワークサーバ。
  7. 前記受信部は、前記クライアント装置から送信されたｈｔｔｐ ｐｏｓｔリクエストに従って前記コンテンツのデータを取得する、請求項１に記載のネットワークサーバ。
  8. ネットワークを介して接続されたクライアント装置からコンテンツのメタデータを取得し、前記メタデータに応じて前記コンテンツのメディア形式を変換するか否かを決定し、前記メタデータに応じて変換後のメディア形式を選択する変換判定ステップと、
    前記クライアント装置から前記コンテンツを受信する受信ステップと、
    前記コンテンツのメディア形式を前記変換判定ステップで選択されたメディア形式に変換する形式変換ステップと、
    を含むメディア形式変換方法。
  9. ネットワークを介して接続されたクライアント装置からコンテンツを受信する受信部と、前記コンテンツのメタデータを取得し、前記メタデータに応じて前記コンテンツのメディア形式を変換するか否かを決定し、前記メタデータに応じて変換後のメディア形式を選択する変換判定部と、前記コンテンツのメディア形式を前記変換判定部で選択されたメディア形式に変換する形式変換部と、を備えるネットワークサーバと、
    前記ネットワークサーバにネットワークを介して前記コンテンツを送信する前記クライアント装置と、
    前記ネットワークサーバからネットワークを介して前記コンテンツ又は前記形式変換部で変換されたコンテンツの配信を受ける表示装置と、
    を有するメディア形式変換システム。
JP2009102102A 2009-04-20 2009-04-20 ネットワークサーバ、メディア形式変換方法、及び、メディア形式変換システム Expired - Fee Related JP5487697B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2009102102A JP5487697B2 (ja) 2009-04-20 2009-04-20 ネットワークサーバ、メディア形式変換方法、及び、メディア形式変換システム
US12/729,712 US8250239B2 (en) 2009-04-20 2010-03-23 Network server, media format conversion method and media format conversion system
CN201010163559A CN101867568A (zh) 2009-04-20 2010-04-13 网络服务器、媒体格式转换方法和媒体格式转换系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009102102A JP5487697B2 (ja) 2009-04-20 2009-04-20 ネットワークサーバ、メディア形式変換方法、及び、メディア形式変換システム

Publications (2)

Publication Number Publication Date
JP2010252260A true JP2010252260A (ja) 2010-11-04
JP5487697B2 JP5487697B2 (ja) 2014-05-07

Family

ID=42959134

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009102102A Expired - Fee Related JP5487697B2 (ja) 2009-04-20 2009-04-20 ネットワークサーバ、メディア形式変換方法、及び、メディア形式変換システム

Country Status (3)

Country Link
US (1) US8250239B2 (ja)
JP (1) JP5487697B2 (ja)
CN (1) CN101867568A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016519471A (ja) * 2013-03-15 2016-06-30 アリス テクノロジー インコーポレイテッドＡｒｒｉｓ Ｔｅｃｈｎｏｌｏｇｙ， Ｉｎｃ． 安全なメディア再生のためのｄｌｎａ（登録商標）／ｄｔｃｐストリーム変換

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NO330630B1 (no) * 2009-07-01 2011-05-30 Tandberg Telecom As System og fremgangsmate for a opprette et anrop ved hjelp av et globalt register
US20130298171A1 (en) * 2010-11-18 2013-11-07 Sharp Kabushiki Kaisha Device for generating content data, method for generating content data, and recording medium
CN102541768B (zh) * 2010-12-21 2015-11-25 联想(北京)有限公司 一种移动终端、状态切换方法及显示方法
KR101769845B1 (ko) * 2011-02-10 2017-08-21 삼성전자주식회사 기기 간의 컨텐츠 공유 방법 및 장치
KR101866270B1 (ko) * 2011-02-21 2018-07-05 삼성전자주식회사 데이터 공유 시스템 및 방법
CN102752231A (zh) * 2011-04-22 2012-10-24 中兴通讯股份有限公司 媒体消息安全机制的处理方法和网关设备
EP2566177B1 (en) 2011-08-31 2020-10-07 Samsung Electronics Co., Ltd. Electronic apparatus and method for transferring contents on cloud system to device connected to DLNA
KR102079339B1 (ko) * 2011-08-31 2020-02-19 삼성전자주식회사 클라우드 시스템상의 컨텐츠를 디엘엔에이로 연결된 디바이스로 전달하는 전자 장치 및 방법
KR101862700B1 (ko) * 2011-10-11 2018-05-31 삼성전자주식회사 휴대용 단말기의 메타데이터 데이터베이스 복사를 이용한 멀티미디어 공유장치 및 방법
US20130198342A1 (en) * 2012-01-26 2013-08-01 General Instrument Corporation Media format negotiation mechanism delivering client device media capabilities to a server
US20130219011A1 (en) * 2012-02-21 2013-08-22 Ehrsolutions, Llc System and method for providing patient relationship management
US9049245B2 (en) * 2012-10-26 2015-06-02 Mckesson Financial Holdings Method and apparatus for flexibly converting and routing data between disparate systems
US20150256600A1 (en) * 2014-03-05 2015-09-10 Citrix Systems, Inc. Systems and methods for media format substitution
KR20160102731A (ko) * 2015-02-23 2016-08-31 삼성전자주식회사 전자 장치 및 전자 장치의 drm 컨텐츠 제공 방법
CN105142015B (zh) * 2015-09-19 2018-10-09 暴风集团股份有限公司 一种基于dlna共享播放bhd文件的方法
WO2021008465A1 (zh) * 2019-07-12 2021-01-21 海信视像科技股份有限公司 数字内容发送装置、发送方法、数字内容接收装置、接收方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002297496A (ja) * 2001-04-02 2002-10-11 Hitachi Ltd メディア配信システム及びマルチメディア変換サーバ
JP2008199436A (ja) * 2007-02-15 2008-08-28 Sony Corp 通信システム、情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
JP2008219842A (ja) * 2007-03-03 2008-09-18 Nihon Avis Kk コンテンツの投稿配信システム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030200548A1 (en) * 2001-12-27 2003-10-23 Paul Baran Method and apparatus for viewer control of digital TV program start time
KR20060006532A (ko) * 2004-07-16 2006-01-19 삼성전자주식회사 요청된 미디어파일의 재생 가능여부를 알리는 미디어파일저장장치 및 전송방법
CN101438256B (zh) * 2006-03-07 2011-12-21 索尼株式会社 信息处理设备、信息通信系统、信息处理方法
CN100442849C (zh) * 2006-03-28 2008-12-10 中山大学 使数字家庭网络的终端可播放多种媒体格式的装置及方法
JP2008061150A (ja) 2006-09-04 2008-03-13 Hitachi Ltd 受信機及び情報処理方法
CN100479529C (zh) * 2006-09-30 2009-04-15 中兴通讯股份有限公司 一种广播网络复用协议的转换方法
EP1959642B1 (en) * 2007-01-30 2015-05-13 Sony Corporation Content transmission system, content sending apparatus and method, content reception apparatus and method, program, and recording media
CN101404652A (zh) * 2008-10-10 2009-04-08 华南理工大学 一种应用于数字家庭的媒体格式转换系统及方法
US9195775B2 (en) * 2009-06-26 2015-11-24 Iii Holdings 2, Llc System and method for managing and/or rendering internet multimedia content in a network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002297496A (ja) * 2001-04-02 2002-10-11 Hitachi Ltd メディア配信システム及びマルチメディア変換サーバ
JP2008199436A (ja) * 2007-02-15 2008-08-28 Sony Corp 通信システム、情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
JP2008219842A (ja) * 2007-03-03 2008-09-18 Nihon Avis Kk コンテンツの投稿配信システム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016519471A (ja) * 2013-03-15 2016-06-30 アリス テクノロジー インコーポレイテッドＡｒｒｉｓ Ｔｅｃｈｎｏｌｏｇｙ， Ｉｎｃ． 安全なメディア再生のためのｄｌｎａ（登録商標）／ｄｔｃｐストリーム変換

Also Published As

Publication number Publication date
JP5487697B2 (ja) 2014-05-07
US8250239B2 (en) 2012-08-21
CN101867568A (zh) 2010-10-20
US20100268765A1 (en) 2010-10-21

Similar Documents

Publication Publication Date Title
JP5487697B2 (ja) ネットワークサーバ、メディア形式変換方法、及び、メディア形式変換システム
JP6742969B2 (ja) 無線メディア・ストリーム配信システム
JP4593618B2 (ja) パケット送信装置
JP4580871B2 (ja) パケット送信装置
US7929560B2 (en) Packet transmitting apparatus
US9509668B2 (en) Content distribution method, content distribution system, source device, and sink device
JP6077173B2 (ja) 安全なメディア再生のためのｄｌｎａ（登録商標）／ｄｔｃｐストリーム変換
WO2012067219A1 (ja) コンテンツデータ生成装置、コンテンツデータ生成方法、コンピュータプログラムおよび記録媒体
US20120315017A1 (en) Content list and content delivery apparatus and method
WO2009093694A1 (ja) 送信装置、受信装置、指示装置、通信システム、送信方法、受信方法、指示方法、プログラム、及び、記録媒体
JP2015103890A (ja) コンテンツ受信装置及びコンテンツ受信方法、並びにコンテンツ送信装置及びコンテンツ送信方法
US20120311626A1 (en) Distributing apparatus for content list and content, and transmitting method
CN101867756B (zh) 信息记录设备、信息发布服务器、信息记录系统和方法
JP2009010898A (ja) 録画装置および放送受信装置
US20120272280A1 (en) Video processor and video processing method
JP2006005726A (ja) 送信装置、媒体及び情報集合体
US20130347119A1 (en) Data processor, communication device, data transmission method
JP2018074348A (ja) 映像処理装置、映像処理方法および映像処理プログラム
JP2010021905A (ja) デジタル放送受信装置、送信方法、送信装置
JP2008181465A (ja) データ処理装置および方法、プログラム、並びに記録媒体
EP2629547A1 (en) Reproduction apparatus, recording/delivery apparatus, reproduction method, and recording/delivery method
JP2012016053A (ja) ディジタル信号処理装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120301

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130410

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130423

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130624

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140128

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140210

LAPS Cancellation because of no payment of annual fees