(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0019】
[第1実施形態]
図1は、本実施形態による再配信システム(再配信装置)の概略機能構成と、同システムにおけるコンテンツデータの流れとを示す概略図である。図示するように、再配信システム1は、受信部120と、編集部140と、統合部160と、配信部180とを含んで構成される。
【0020】
再配信システム1は、例えば外部の配信サーバーからHTTPストリーミング等で配信されるコンテンツを受信する。なお、HTTPは、ハイパーテキスト転送プロトコル(HyperText Transfer Protocol)の略である。再配信システム1が受信するコンテンツは、例えば、映像や音声やテキストなど、複数の種類のコンテンツを含んでいる。また、再配信システム1が受信するコンテンツは、例えば、複数の映像のコンテンツや、複数の音声のコンテンツ等を含んできてもよい。そして、再配信システム1は、受信したコンテンツの少なくとも一部に基づく新たなコンテンツを生成する。そして、再配信システム1は、受信した元のコンテンツと、生成した新たなコンテンツとを、まとめて1つのコンテンツのパッケージとして、再配信するものである。
【0021】
受信部120は、例えばHTTPストリーミング形式にエンコードされた少なくとも1種類のコンテンツを含む第1パッケージを受信する。受信部120は、複数の種類のコンテンツを受信してもよい。図示する例では、C(1)からC(m+n)までの(m+n)種類のコンテンツを含んだパッケージを受信する。なお、ここで、mは0以上の整数であり、nは1以上の整数である。なお、受信部120は、例えばHLSによりこれらのコンテンツを受信する。HLSは、「HTTPライブストリーミング」(HTTP Live Streaming)の略であり、インターネット等を介して映像等をストリーミング配信する方法(プロトコル)として知られる。
受信部120は、受信したコンテンツであるC(1)からC(m+n)を、統合部160に渡す。また、受信部120は、受信したコンテンツのうちのC(m+1)からC(m+n)を、編集部140に渡す。
【0022】
編集部140は、受信部120が受信した第1パッケージに含まれるコンテンツのうちの少なくとも一部の種類のコンテンツに基づく新たなコンテンツを生成して出力する。より具体的には、編集部140は、受信部120が受信したコンテンツのうちのC(m+1)からC(m+n)までのn種類のコンテンツを、受信部120から受け取る。そして、編集部140は、受け取ったコンテンツであるC(m+1)からC(m+n)までに基づいて、これらのコンテンツに関連する新たなコンテンツを生成する。編集部140が生成する新たなコンテンツは、C(m+n+1)からC(m+n+k)までのk種類のコンテンツである。ただし、kは、1以上の整数である。編集部140が受け取るコンテンツであるC(m+1)からC(m+n)までと、編集部が生成するコンテンツであるC(m++n+1)からC(m+n+k)までとの関係は様々であるが、両者はコンテンツとして関係を有している。また、両者は、相互に関連するものであるので、その再生等(より一般的には、提示)においてタイミングを合わせるべきものである。編集部140は、生成したコンテンツを、統合部160に渡す。
【0023】
統合部160は、受信部120が受信した第1パッケージに含まれるコンテンツと、編集部140によって生成された新たなコンテンツとを、一つの第2パッケージとして統合して出力する。統合部160は、受信部120から渡されたコンテンツであるC(1)からC(m+n)までと、編集部140から渡されたコンテンツであるC(m+n+1)からC(m+n+k)までとを統合する。なお、統合部160は、エンコードされたままの状態でC(1)からC(m+n)までを受け取り、そのままコンテンツであるC(m+n+1)からC(m+n+k)までとの統合を行う。そして、統合部160は、これらのコンテンツの全体を一つのパッケージとして、配信部180に渡す。なお、このとき、統合部160は、受信部120から渡されたコンテンツと編集部140から渡されたコンテンツとの間で、再生のタイミングが整合するように統合する。
なお、統合部160が、受信部120から渡されたコンテンツであるC(1)からC(m+n)までの全部ではなく、それらの一部のみを、C(m+n+1)からC(m+n+k)までと統合するようにしてもよい。この場合、C(1)からC(m+n)のうちのいずれをC(m+n+1)からC(m+n+k)までと統合するかは、適宜、定められる。
つまり、統合部160は、受信部120が受信した第1パッケージに含まれるコンテンツのうちの少なくとも一部のコンテンツと、編集部140によって生成された新たなコンテンツとを、一つの第2パッケージとして統合して出力する。
【0024】
配信部180は、統合部160から渡されたコンテンツ(第2パッケージ)を、再配信する。
【0025】
図2は、再配信システム1を含む、システム全体の構成例を示すブロック図である。図示するように、本システムは、配信サーバー装置2と、再配信システム1と、クライアント装置3とを含んで構成される。再配信システム1は、インターネット等の通信回線を介して、配信サーバー装置2およびクライアント装置3と接続されている。なお、この図においては、1台のクライアント装置3のみを示しているが、実際には多数のクライアント装置3が再配信システム1に接続されていてもよい。再配信システム1が受信部120と編集部140と統合部160と配信部180とを含んで構成される点は、
図1を参照しながら説明した通りである。
【0026】
配信サーバー装置2は、オリジナルのコンテンツを配信するサーバーコンピューターである。配信サーバー装置2が配信するコンテンツは、例えば、映像と音声とで構成されるコンテンツである。なお、配信サーバー装置2は、コンテンツの配信には、例えば、前述のHLSを用いる。
クライアント装置3は、再配信システム1が送出するコンテンツ(再配信されるコンテンツ)を受信する。クライアント装置3は、例えば、パーソナルコンピューター(PC)や、スマートフォン(スマホ)や、腕時計型の情報端末や、メガネ型の情報端末や、その他の情報機器等を用いて実現される。クライアント装置3は、例えば、ウェブブラウザーの機能を備えており、ウェブブラウザーがHTTPクライアントとして機能する。これにより、再配信システム1からHLSで再配信されるコンテンツが視聴可能となる。
【0027】
本実施形態の構成によれば、ベースバンド信号(非圧縮信号)によるコンテンツを受信することなく、ストリーミング形式で受信したコンテンツに関連する新たなコンテンツを付加したうえで、コンテンツの再配信を実現することが可能となる。つまり、工程や機材等を大幅に削減できるため、安価に再配信システムを実現することが可能となる。
【0028】
[第2実施形態]
次に、第2実施形態について説明する。なお、前実施形態において既に説明した事項については以下において説明を省略する場合がある。ここでは、本実施形態に特有の事項を中心に説明する。
【0029】
図3は、本実施形態による再配信システム(再配信装置)の概略機能構成と、同システムにおけるコンテンツデータの流れとを示す概略図である。図示するように、再配信システム11は、受信部220と、編集部240と、統合部260と、配信部280とを含んで構成される。
【0030】
再配信システム11は、映像および音声のコンテンツ(「音声A」と呼ぶ)を受信し、受信した音声のコンテンツに基づく別の音声のコンテンツ(「音声B」と呼ぶ)を生成し、受信した元のコンテンツ(音声Aをも含む)と、生成した音声のコンテンツ(音声B)とを統合したコンテンツを、再配信するものである。
【0031】
受信部220は、少なくとも1種類の映像のコンテンツと、少なくとも1種類の音声のコンテンツとを含む第1パッケージを受信する。具体的には、受信部220は、インターネット等の通信回線を介して配信されるストリーミング映像および音声(「音声A」と呼ぶ)のコンテンツを受信する。受信部220が受信する映像および音声Aは、エンコードされた状態で、例えば外部の配信サーバー等から送信されたものである。なお、一例として、受信専用のコンピューター装置などを用いて、受信部220を実現することが可能である。
【0032】
編集部240は、第1パッケージに含まれる少なくとも1種類の音声のコンテンツである第1音声を再生するとともに、その第1音声と、その第1音声に対応して入力される別の音声とを重畳して得られる第2音声を生成して新たなコンテンツとして出力する。つまり、編集部240は、受信部220が外部から受信したコンテンツのうち、少なくとも音声Aのコンテンツを受け取り、再生する。なお、編集部240が、映像のコンテンツをも受け取って再生するようにしてもよい。そして、編集部240は、音声Aのコンテンツと、編集部240に接続されたマイクロホン等から集音された音声とを、音声の帯域において混合し、所定の符号化方式でエンコードして、新たな音声(「音声B」と呼ぶ)のコンテンツとして出力する。
一例として、アナウンサーや解説者らが、編集部240で再生されるコンテンツ(映像および音声A)を視聴しながら、実況あるいは解説等を行う。つまり、アナウンサーや解説者らは、自身の声をマイクロホン等に向けて発し、その声を含む音声Bのコンテンツを編集部240が生成する。このように、デコードされた第1音声を再生して、アナウンサーや解説者らがその第1音声をリアルタイムで聞きながら自身の声を発する場合には、音声を処理するための遅延時間が生じないか、その遅延時間は無視できるほどに小さい。よって、第1音声と新たな音声とは、適切なタイミングで混合され、音声Bが生成される。
なお、他の方法によって音声Bを作成してもよい。その場合、音声Bの作成にあたっては、必要に応じて、第1音声と別の音声(アナウンサーや解説者らが発する声)とのタイミングが整合するように、タイミング合わせのための適切な処理を行ってもよい。
なお、コンピューターを用いて、編集部240を実現することも可能である。一例として、パーソナルコンピューターやスマートフォン(スマホ)などの、個人用の情報機器などを用いて、編集部240を実現することも可能である。
【0033】
統合部260は、第1パッケージに含まれる映像のコンテンツおよび音声のコンテンツと、上記の新たなコンテンツとの間で、再生のタイミングが整合するように統合して出力する。統合部260は、元々受信部220が受信したコンテンツ(映像と音声A)と、編集部240から渡されたコンテンツ(音声B)とを統合して、配信部280に渡す。統合部260は、これらのコンテンツを統合する際、受信部220が受信したコンテンツ(映像と音声A)と、編集部240から渡されたコンテンツ(音声B)との間で、タイミングが相互に整合するように調整する。また、統合部260は、受信部220から渡される音声Aと、編集部240から渡される音声Bとの間の、レベル調整を行う。なお、統合部260は、映像および音声Aを、エンコードされたままの状態で受信部220から受け取る。そして、そのままの状態で、音声Bとの統合を行う。
なお、統合部260が、受信部220から渡されたコンテンツの全部(映像と音声A)ではなく、それらの一部のみを、編集部240から渡されるコンテンツ(音声B)と統合するようにしてもよい。その場合、例えば、統合部260は、受信部220から渡される映像、および編集部240から渡される音声Bだけを統合してもよい。また、例えば、受信部220から渡される音声A、および編集部240から渡される音声Bだけを統合してもよい。これらのいずれの場合にも、統合部260は、コンテンツを統合する際、受信部220が受信したコンテンツと、編集部240から渡されたコンテンツとの間で、タイミングが相互に整合するように調整する。
つまり、統合部260は、受信部220が受信した第1パッケージに含まれるコンテンツのうちの少なくとも一部のコンテンツと、編集部240によって生成された新たなコンテンツとを、一つの第2パッケージとして統合して出力する。
なお、統合部260に依るタイミングの調整およびレベルの調整の処理は、自動的に行われる。統合部260がタイミングを調整する方法の詳細については、後で述べる。
【0034】
配信部280は、統合部260から出力されたコンテンツを、配信する。配信部280は、インターネット等を介して、コンテンツを配信する。
【0035】
図4は、本実施形態において、配信サーバー装置から配信されたコンテンツを再配信システムが再配信する際のコンテンツの流れを示す概略図である。同図において、受信部220と編集部240と統合部260と配信部280とは、
図3にも示した通り、再配信システム11を構成する装置(またはその一部の機能)である。また、再配信システム11を構成するこれらの機能と、配信サーバー装置2と、クライアント装置3とは、それぞれインターネットに接続されており相互に通信可能である。なお、通信のために、インターネット以外の手段を用いてもよい。なお、
図4において、クライアント装置3を1台のみ示しているが、実際には、多数のクライアント装置3が配信部280からの配信を受けるようにしてよい。
【0036】
図示するように、配信サーバー装置2は、映像および音声を含むコンテンツを、インターネット経由で配信する。コンテンツの配信には、例えば、前述のHLSを用いる。受信部220は、配信サーバー装置2から配信された上記コンテンツを受信する。受信部220は、受信したコンテンツである映像および音声(音声A)を、インターネット経由で、または他の回線等を経由して、統合部260に渡す。また、受信部220は、受信したコンテンツのうちの少なくとも音声Aを(必要に応じて映像をも)、インターネット経由で、または他の回線等を経由して、編集部240に渡す。編集部240は、受信部220から受信したコンテンツに基づいて、音声Aとは異なる音声コンテンツである音声Bを生成する。なお、音声B内に、音声Aが混合されていてもよい。典型的な適用例においては、音声Aはイベント等が行われている現地からの生中継音声であり、音声Bは、編集部240を用いるアナウンサーや解説者等が、音声Aに、マッチした発話を混合させたものである。編集部240は、音声Aを有するファイルに含まれるタイミング情報を参照し、音声Bに前記タイミング情報を付加してエンコードし、ファイルとして出力する。ここで、タイミング情報とは、例えばPTS(プレゼンテーションタイムスタンプ)である。さらに、編集部240は、音声Aと音声Bとの間で再生タイミングを一致させるためのメタデータ(音声Aと音声Bとの間で対応付けられるファイル名等のデータ)を生成する。そして、編集部240は、音声Bを、新たな音声のコンテンツとして統合部260に渡す。なお、編集部240は、この音声のコンテンツ(音声B)を統合部260に渡す際、インターネット経由で送信してもよいし、その他の回線等を経由して送信してもよい。
【0037】
統合部260は、受信部220から受け取ったコンテンツと、編集部240から受け取ったコンテンツとを、再生タイミングを一致させるためのメタデータ(ファイル名の対応関係等のデータ)に基づいて統合する。統合部260が行う重要な処理の一つは、受信部220側からのコンテンツと編集部240側からのコンテンツとの間で、上記のメタデータ(ファイル名の対応関係等)に基づいてタイミングを合わせることである。つまり、統合部260がコンテンツ間での同期を取ることにより、編集部240で生成された音声Bのコンテンツは、受信部220側からの映像および音声(音声A)のそれぞれと、整合したタイミングで配信することが可能となる。統合部260は、タイミングを整合させる対象となる受信部220側からのコンテンツと編集部240側からのコンテンツの到達時刻が不一致となる場合を考慮し、コンテンツを蓄積するバッファ領域を備える。統合部260は、統合されたコンテンツを、配信部280に渡す。そして、配信部280は、統合部260から渡されたコンテンツの全体を、インターネット経由で配信する。コンテンツの配信には、例えば、前述のHLSを用いる。クライアント装置3は、配信部280から再配信されたコンテンツを受信し、デコードして再生する。なお、クライアント装置3は、映像のコンテンツを再生するとともに、適宜、音声Aあるいは音声Bのいずれか一方の音声のコンテンツを再生するようにしてよい。
【0038】
次に、本実施形態において配信されるデータの形式等について説明する。
図5は、本実施形態において受信部220が受信するストリーミング配信データの構成例を示す概略図である。図示するように、配信サーバー装置2側から配信されるデータは、階層構造で構成されている。同図では、最も左側が最上位の階層、真中が中間の階層、最も右側が最下位の階層を表している。最上位の階層では、1個のインデックスファイルが存在しており、そのファイル名は「IndexFile.m3u8」である。このインデックスファイル「IndexFile.m3u8」は、下位層(中間の階層)の別の3種類のインデックスファイルの所在の情報(ファイル名、パス名等)を保持している。それらの3種類のインデックスファイルは、「Alternate−LowIndex」と、「Alternate−MidIndex」と、「Alternate−HiIndex」とである。これらの3種類のインデックスファイルは、適宜、確保可能な通信帯域幅に応じて使い分けることができる。例えば、配信を受けるクライアント装置側のユーザーが、低帯域幅、中帯域幅、高帯域幅の3種類の中から一つを指定できるようにする。「Alternate−LowIndex」と、「Alternate−MidIndex」と、「Alternate−HiIndex」のそれぞれは、所定時間長(例えば、6秒など)ごとの動画ファイルの所在情報のリストを保持している。一例として、インデックスファイル「Alternate−LowIndex」は、「Low_01.ts」と、「Low_02.ts」と、「Low_03.ts」と、「Low_04.ts」との4つの動画ファイルの所在の情報を保持している。なお、「Low_01.ts」と、「Low_02.ts」と、「Low_03.ts」と、「Low_04.ts」とは、順次再生されるべき動画ファイルである。なお、インデックスファイル「Alternate−LowIndex」は、4個に限らず、任意の数の動画ファイルの所在情報を持つことができる。ここではインデックスファイル「Alternate−LowIndex」を例として説明したが、「Alternate−MidIndex」と「Alternate−HiIndex」のそれぞれもまた、帯域幅に応じた動画ファイルの所在情報を保持する。
【0039】
なお、
図5に示すデータ構成の場合、音声(音声A)は、それぞれの動画ファイル(Low_01.tsや、Mid_01.tsや、Hi_01.tsなど)の中に含まれている。
一方、音声(音声A)を独立のファイルとして配信サーバー装置2側から配信し、受信部220がその音声ファイルをも受信するようにしてもよい。この場合、音声は、適切な長さに分割されて、時間の経過に沿った複数のファイルとして配信される。また、それらの音声ファイルは、動画ファイルをインデックスしているのと同一のインデックスファイルによってインデックスされている。
【0040】
図6は、本実施形態において統合部260が出力し、配信部280が配信するストリーミング配信データの構成例を示す概略図である。図示するように、統合部280が配信するデータもまた、階層構造で構成されている。
図5で説明したデータ構成と同様に、最も左側が最上位の階層、真中が中間の階層、最も右側が最下位の階層を表している。最上位の階層では、1個のインデックスファイルが存在しており、そのファイル名は「IndexFile.m3u8」である。このインデックスファイル「IndexFile.m3u8」は、下位層(中間の階層)の別の5種類のインデックスファイルの所在の情報(ファイル名、パス名等)を保持している。それらの5種類のインデックスファイルは、「Alternate−LowIndex」と、「Alternate−MidIndex」と、「Alternate−HiIndex」と、「mixed」と、「original」とである。
【0041】
このうち、「Alternate−LowIndex」と、「Alternate−MidIndex」と、「Alternate−HiIndex」との3種類は、
図5で説明したデータ構成と同様、動画のファイルに関するインデックスである。これらの3種類のインデックスファイルの下位の動画ファイルも
図5で説明したデータ構成と同様のものである。
【0042】
また、中間階層の上記5種類のインデックスファイルのうち、「mixed」と、「original」との2種類は、それぞれ、音声のファイルをインデックスする。「mixed」と「original」とのそれぞれは、所定時間長(例えば、6秒など)ごとの音声ファイルの所在情報のリストを保持している。一例として、インデックスファイル「mixed」は、「mixed_01.ts」と、「mixed_02.ts」と、「mixed_03.ts」と、「mixed_04.ts」との4つの音声ファイルの所在の情報を保持している。なお、「mixed_01.ts」と、「mixed_02.ts」と、「mixed_03.ts」と、「mixed_04.ts」とは、順次再生されるべき音声ファイルである。なお、インデックスファイル「mixed」は、4個に限らず、任意の数の音声ファイルの所在情報を持つことができる。「mixed」と全く同様に、「original」も、所定時間長(例えば、6秒など)ごとの別の音声ファイルの所在情報のリストを保持している。つまり、「original」は、「original_01.ts」と、「original_02.ts」と、「original_03.ts」と、「original_04.ts」との4つの、順次再生されるべき音声ファイルの所在の情報を保持する。
【0043】
なお、上記のインデックスファイル「mixed」がインデックスする音声ファイル(mixed_01.tsなど)は、編集部240によって出力される音声(音声B)を含むものである。また、インデックスファイル「original」がインデックスする音声フィアル(original_01.tsなど)は、受信部220が配信サーバー装置2側から受信したオリジナルの音声(音声A)を含むものである。
【0044】
元の配信サーバー装置2から音声Aの独立のファイルが配信される場合には、統合部260は、そのファイルをそのまま「original」によってインデックスされる音声ファイルとして出力すればよい。
元の配信サーバー装置2から配信される音声Aが、配信される動画ファイル内にしか存在しない場合には、統合部260は、それらの動画ファイルから音声を抽出して音声ファイルを生成する。そして、統合部260は、生成された音声ファイルを、「original」によってインデックスされる音声ファイルとして出力すればよい。
【0045】
図7は、本実施形態が用いるインデックスファイルの構成例を示す概略図である。なお、ここに例示するファイルは、階層構造における最上位のインデックスファイルである。このインデックスファイルのファイル名は「playlist.m3u8」である。図示するように、インデックスファイル「playlist.m3u8」は、拡張M3U形式のファイルであり、その内部にはインデックス情報を表すテキストを含んでいる。なお、
図7において、便宜的にテキストの各行に対応する行番号を付している。以下、インデックスファイル「playlist.m3u8」の内容を説明する。
【0046】
第1行目は、当ファイルが拡張M3U形式のファイルであることを示すヘッダーである。
第2行目と第3行目は、音声のコンテンツに関する情報を保持する。第2行目と第3行目は、ともに「TYPE=AUDIO」という記述を含んでおり、これは、第2行目と第3行目がそれぞれ音声のコンテンツのインデックスであることを示す。また、第2行目と第3行目は、ともに「GROUP−ID=”audio”」という記述を含んでおり、これは、第2行目と第3行目がともに「audio」という識別情報によって識別されるグループに属することを示す。
これらのうち、第2行目は、「NAME=”mixed”」という記述を含んでおり、これは、混合音声であること、即ち編集部240において付加音声が付加されたもの(つまり、音声B)であることを示すものである。また、第2行目は、「DEFAULT=YES」という記述を含んでおり、これは、デフォルトの音声であることを示している。また、第2行目は、当該音声に関する下位のインデックスファイルの所在情報を保持している。「URI=”mixed/playlist.m3u8”」という記述がその所在情報にあたる。
一方で、第3行目は、「NAME=”original”」という記述を含んでおり、これは、混合される前のオリジナルの音声であることを示している。即ち、付加音声が付加されていない、受信部220が受信した音声(音声A)であることを示すものである。また、第3行目は、「DEFAULT=NO」という記述を含んでおり、これは、デフォルトの音声ではないことを示している。また、第3行目は、当該音声に関する下位のインデックスファイルの所在情報を保持している。「URI=”original/playlist.m3u8”」という記述がその所在情報にあたる。
【0047】
第4行目は、コンテンツの当該セグメントが、独立セグメントであることを表す情報である。つまり、当該セグメントのコンテンツをデコードするために他のセグメントからの情報を必要としないことを表す。
【0048】
第5行目から第16行目までは、6種類の映像ファイルのインデックスの情報を含むものである。
第5行目および第6行目は、第1の映像のインデックスの情報を保持する。第1の映像は、帯域幅(BANDWIDTH)および平均帯域幅(AVERAGE-BANDWIDTH)がともに「545600」(単位は、ビット毎秒)である。また、この映像ストリームをデコードするためのコーデック(codec)は「avc1.66.30」と「mp4a.40.2」である。また、この映像の解像度は「480x270」である。また、この映像のインデックスファイルは、「stream1/playlist.m3u8」である。
第7行目および第8行目は、第2の映像のインデックスの情報を保持する。第2の映像は、帯域幅(BANDWIDTH)および平均帯域幅(AVERAGE-BANDWIDTH)がともに「765600」(ビット毎秒)である。また、この映像ストリームをデコードするためのコーデック(codec)は「avc1.66.30」と「mp4a.40.2」である。また、この映像の解像度は「640x360」である。また、この映像のインデックスファイルは、「stream2/playlist.m3u8」である。
第9行目および第10行目は、第3の映像のインデックスの情報を保持する。第3の映像は、帯域幅(BANDWIDTH)および平均帯域幅(AVERAGE-BANDWIDTH)がともに「1425600」(ビット毎秒)である。また、この映像ストリームをデコードするためのコーデック(codec)は「avc1.42c01f」と「mp4a.40.2」である。また、この映像の解像度は「640x360」である。また、この映像のインデックスファイルは、「stream3/playlist.m3u8」である。
【0049】
第11行目および第12行目は、第4の映像のインデックスの情報を保持する。第4の映像は、帯域幅(BANDWIDTH)および平均帯域幅(AVERAGE-BANDWIDTH)がともに「3955600」(ビット毎秒)である。また、この映像ストリームをデコードするためのコーデック(codec)は「avc1.4d401f」と「mp4a.40.2」である。また、この映像の解像度は「960x540」である。また、この映像のインデックスファイルは、「stream4/playlist.m3u8」である。
第13行目および第14行目は、第5の映像のインデックスの情報を保持する。第5の映像は、帯域幅(BANDWIDTH)および平均帯域幅(AVERAGE-BANDWIDTH)がともに「5640800」(ビット毎秒)である。また、この映像ストリームをデコードするためのコーデック(codec)は「avc1.4d401f」と「mp4a.40.2」である。また、この映像の解像度は「1280x720」である。また、この映像のインデックスファイルは、「stream5/playlist.m3u8」である。
第15行目および第16行目は、第6の映像のインデックスの情報を保持する。第6の映像は、帯域幅(BANDWIDTH)および平均帯域幅(AVERAGE-BANDWIDTH)がともに「7290800」(ビット毎秒)である。また、この映像ストリームをデコードするためのコーデック(codec)は「avc1.4d401f」と「mp4a.40.2」である。また、この映像の解像度は「1280x720」である。また、この映像のインデックスファイルは、「stream6/playlist.m3u8」である。
【0050】
なお、上記の第1の映像から第6の映像までに共通して、フレームレート(FRAME-RATE
)は「30.000」と定義されている。また、第1の映像から第6の映像までの映像に関してすべて「AUDIO=”audio”」という記述が含まれている。これは、各映像に関連付けられる音声のコンテンツは、”audio”というグループIDで識別されるものであることを表す。つまり、各映像に関連付けられる音声のコンテンツは、第2行目または第3行目で定義されているものである。
【0051】
図8は、本実施形態が用いるインデックスファイルの例を示す概略図である。ここに示すファイルは、
図7で示した最上位のインデックスファイルから参照される下位のインデックスファイルである。このインデックスファイルのファイル名は「mixed/playlist.m3u8」である。
図7で示した最上位のインデックスファイルの第2行目の記述における「URI=”mixed/playlist.m3u8”」という記述が、この
図8のファイルの所在を示している。ここで「mixed」はディレクトリ名であり、このディレクトリは混合音声(音声B)用のファイルを格納するディレクトリである。つまり、このインデックスファイル「mixed/playlist.m3u8」は、混合音声に関するインデックスの情報を保持する。このインデックスファイル「mixed/playlist.m3u8」もまた、拡張M3U形式のファイルである。なお、
図8においても、テキストの各行に対応する行番号を付している。以下、インデックスファイル「mixed/playlist.m3u8」の内容を説明する。
【0052】
第1行目は、当ファイルが拡張M3U形式のファイルであることを示すヘッダーである。
第2行目は、ファイル形式のバージョン情報である。具体的には、このファイル形式のバージョンが「3」であることを示している。
第3行目の「#EXT-X-TARGETDURATION」は、次に追加される予定のメディアファイルの予測時間長を示すものである。本データの例では、予測時間長は6秒である。
第4行目の「#EXT-X-MEDIA-SEQUENCE」は、本インデックスファイルが含む最初のメディアファイルのシーケンス番号を表す。本データ例では、最初のシーケンス番号は「417554」(第8行目で指定されているファイルのファイル名に、この番号が含まれている)である。
第5行目の「#EXT-X-DISCONTINUITY-SEQUENCE」については、説明を省略する。
【0053】
第6行目から第35行目までにおいて、3行ずつのまとまりを持つ組が、10回(計30行)繰り返されている。各組における第1行は、メディアファイルを日付・時刻に関連付ける。また、第2行は、そのメディアセグメントの長さを秒単位で表す。また、第3行は、メディアファイルそのものを参照するための情報である。
【0054】
ここでは、例として、第6行目から第8行目までの組について説明する。
第6行目の「#EXT-X-PROGRAM-DATE-TIME」は、参照されるメディアファイルを、日時に関連付ける。本データ例では、最初のメディアファイルは「2017-05-11T16:19:02.866+09:00」(年月日・時分秒および千分の一秒の表記)で示される日時(世界標準時から9時間先行する時間帯における日時)に関連付けられる。
第7行目の「#EXTINF」は、この組に対応するメディアセグメントの長さを表す。具体的には、その長さは6.000秒であることが指定されている。なお、「6.000」に後続するコンマの次には、タイトルを指定可能であるが、本データではタイトルの記述が省略されている。
第8行目は、この組のメディアファイル(ここでは、混合音声(音声B)の音声ファイル)のファイル名を記述している。本データでは、具体的には、「test2_270_417554.ts」である。
【0055】
この組に後続する9組においても、同様に、日時の情報と、メディアセグメントの長さの情報と、そのメディアセグメントにおけるメディアファイルのファイル名の情報とが記述されている。具体的な日時、メディアセグメントの長さ、ファイル名は、図面に記載されている通りであるため、ここでは説明を省略する。
【0056】
以上のように、ここに例示したインデックスファイルは、混合音声のファイルについて、10セグメント分の情報を保持している。また、各セグメントの長さは6秒であり、10セグメント分の合計の長さは60秒である。
【0057】
統合部260は、上の
図7に例示したインデックスファイルを生成して出力する。つまり、統合部260は、音声A(NAME=”original”)と音声B(NAME=”mixed”)の両方を含むコンテンツを、配信部280に渡す。配信部280は、そのように統合部260によって統合されたコンテンツを、クライアント装置3に配信する。
【0058】
次に、統合部260が、編集部240によって生成された(音声)音声Bのタイミングを、受信部220からわたされた映像および音声(音声A)のタイミングに合わせる方法の詳細について説明する。本実施形態の方法では、ファイルに含まれる提示時刻情報を利用する。つまり、受信部220が受信する映像および音声(音声A)のファイルには、再生のタイミング情報(PTS,プレゼンテーションタイムスタンプ)と、再生時間の長さの情報とが含まれている。HLSを用いる場合は、受信部220は、映像・音声データを含むTS(Transport Stream)ファイルからタイミング情報(PTS)を取得できる。また、配信サーバー装置2から配信されるインデックスファイル(M3U8ファイル)の「#EXTINF」の記述から、再生時間の長さの情報を取得することができる。編集部240は、元の音声Aを再生しながら音声B(混合音声)を生成するが、その際、音声Aのファイルに含まれていたタイミング情報および再生時間の長さの情報を、そのまま音声Bに埋め込む。例えば、音声の入力が開始した時点のタイミング情報(PTS−1)を取得し、音声Bを生成する際に出力ストリームの先頭のタイミング情報を、前記PTS−1とするように出力する。さらに、M3U8ファイルから取得した再生時間の長さが5秒の場合は、出力ストリームを5秒ごとのファイルに分割して生成する。つまり、編集部240は、音声Aを構成する個々のファイルと同一のタイミング情報および再生時間の長さの情報を有する、音声Bを生成し出力する。そして、統合部260は、音声Aと音声Bのファイルにおけるタイミング情報および再生時間の長さの情報が同一であることを確認して、受信部220からわたされた映像および音声(音声A)と生成した音声Bの再生タイミングが整合するように、映像、音声A、音声Bの情報を含む新たなM3U8ファイルを生成し、HLSコンテンツとして、M3U8ファイル、映像のTSファイル、音声AのTSファイル、音声BのTSファイルを配信する。
【0059】
つまり、編集部240は、第1パッケージに含まれるコンテンツが保持するタイミング情報に基づいて、整合するタイミング情報を、生成する新たなコンテンツに付与するものである。また、統合部260は、第1パッケージに含まれるコンテンツが保持するタイミング情報と、上記の新たなコンテンツに付与されたタイミング情報とに基づいて、再生のタイミングが整合するようにする。
【0060】
これにより、再配信システム11が受信したオリジナルのコンテンツと、再配信システム11が付加したコンテンツとの間でタイミングが合った状態で、コンテンツの再配信を行うことが可能となる。
【0061】
[第2実施形態:変形例]
次に、第2実施形態の変形例について説明する。この変形例の基本的な構成は、第2実施形態におけるそれと同一であるが、統合部260が音声Aと音声Bとの間のタイミングを合わせる方法の部分が第2実施形態とは異なる。
【0062】
この変形例において、統合部260は、次の通り、音声Aと音声Bとのタイミングを合わせる。編集部240は、オリジナルの音声(音声A)にアナウンサー等の発話などを混合した混合音声(音声B)を生成する。つまり、編集部240が生成する音声Bのデータには、音声Aの情報も含まれている。統合部260は、音声A(「比較用音声」とも呼ぶ)と音声B(発話によるコメントが付加されているため「コメント音声」とも呼ぶ)とを取得する。なお、統合部260は、音声Aを、受信部220から直接取得してもよいし、編集部240から取得してもよい。統合部260は、音声Bの中に音声Aの信号が含まれていることを利用して、音声Aと音声Bのタイミングを合わせるための処理を実行する。
【0063】
その一例として、統合部260は、次の計算を行う。音声Aおよび音声Bを、それぞれ、S
A(t)およびS
B(t)で表す。S
A(t)およびS
B(t)は、それぞれ、時刻tにおける信号値(例えば、音声信号の振幅)である。統合部260に音声Aと音声Bとが届くとき、その時点までのプロセスの経路の違いにより、両者のタイミングがずれている可能性がある。そのずれ量をΔt(デルタ・t)とする。
図3等に示す処理を装置として構成した場合の音声Aと音声Bとの間のタイミングのずれ量は、通常は最大でも1秒未満、特殊なケースでもせいぜい数秒以内と想定することは妥当である。そして、統合部260は、時刻tを含む所定の時間区間において、信号S
A(t)と信号S
B(t+Δt)との相互相関値を算出する。その相互相関値はc=corr(S
A(t),S
B(t+Δt))と表される。ここで、corr()は、2つの信号の相互相関値を求める関数である。そして、統合部260は、上記の相互相関値cを最大化するようなずれ量Δtを求める。そして、統合部260は、求められたずれ量Δtに基づいてタイミング情報(PTS)の値を変更し、音声Aと音声Bのコンテンツのタイミングを合わせて、出力する。
【0064】
なお、上記の関数corr()により相互相関値を算出する際、音声Aの信号レベルと音声Bの信号レベルとを、適宜、調整するようにしてもよい。また、ここでの信号レベルの調整量を、例えば機械学習等に基づいて、自動的に求めるようにしてもよい。
また、ここでは相互相関値を用いて音声Aと音声Bのタイミングを合わせる方法を例として挙げたが、統合部260が他の方法によって両者のタイミングを合わせるようにしてもよい。例えば、音声Aと音声Bの信号波形を、画像処理によって比較し、両者の波形の一致度が最も高くなるずれ量Δtを求めてもよい。
【0065】
整理すると、統合部260は、第1音声の波形と第2音声の波形との類似性に基づいて、第1音声のコンテンツを含む第1パッケージのコンテンツと、編集部240によって生成された新たなコンテンツである第2音声との、いずれか一方を時間方向に移動させることによって、再生のタイミングが整合するように第1音声と第2音声とを統合して出力する。
【0066】
[第3実施形態]
次に、第3実施形態について説明する。なお、前実施形態以前において既に説明した事項については以下において説明を省略する場合がある。ここでは、本実施形態に特有の事項を中心に説明する。
【0067】
図9は、本実施形態による再配信システム(再配信装置)の概略機能構成と、同システムにおけるコンテンツデータの流れとを示す概略図である。図示するように、再配信システム12は、受信部320と、編集部340と、統合部360と、配信部380とを含んで構成される。
【0068】
再配信システム12は、映像および音声のコンテンツを受信する。そして、再配信システム12は、受信した音声のコンテンツに基づいて、字幕テキストのコンテンツを生成する。そして、再配信システム12は、受信したオリジナルのコンテンツと、生成した字幕テキストのコンテンツとを、再生・提示するタイミングがあった状態で、再配信するものである。
【0069】
受信部320は、少なくとも1種類の音声のコンテンツを含む第1パッケージを受信する。具体的には、例えば、受信部320は、外部の配信サーバー装置から、映像および音声で構成されるコンテンツを、ストリーミングの形式で受信する。受信部320は、受信した映像のファイルおよび音声のファイルを、統合部360に送信する。また、受信部320は、受信した音声のファイルを、編集部340に送信する。
【0070】
編集部340は、第1パッケージに含まれる少なくとも1種類の音声のコンテンツの音声認識処理を行うことによってその音声のコンテンツに対応する字幕テキストのコンテンツを、新たなコンテンツとして生成する。編集部340は、音声認識エンジンを内部に備えており、入力された音声を文字列に変換する機能を有する。また、編集部340は、音声から変換された文字列を、さらに字幕テキストデータの形式に整形し、ライブストリーミングにおける映像の一部として表示可能な形態のファイルとして出力する。このとき、編集部340は、元の音声のファイルに含まれているタイミング情報(PTS,プレゼンテーションタイムスタンプ)と、ファイル内での時刻の相対位置等に基づいて、字幕テキストデータの断片ごとにタイミング情報を付与する。なお、編集部340は、例えば、タイムド・テキスト・マークアップ言語(TTML,Timed Text Markup Language)等の、タイミング情報を付加することのできるデータ形式で、字幕テキストを出力することができる。編集部340は、音声に基づいて生成された字幕テキストデータのファイルを、統合部360に送信する。
なお、音声認識エンジン自体には、既存の技術を適用することができる。音声認識エンジンは、基本的な処理として、入力される音声の音響的特徴を抽出し、必要に応じて言語としての特徴を考慮に入れながら、統計的に確からしい文字列を音声認識結果のテキストとして出力するものである。
【0071】
統合部360は、音声のコンテンツに含まれる音声信号と生成された字幕テキストとの間の時間方向の対応関係に基づいて、音声のコンテンツの再生のタイミングと字幕テキストの提示のタイミングが整合するように統合して出力する。つまり、統合部360は、受信部320から受け取った映像および音声のコンテンツのファイルと、編集部340から受け取った字幕テキストのファイルとを、パッケージとして統合して、配信部380に渡す。より具体的には、統合部360は、音声のコンテンツと字幕テキストのコンテンツとの間でのタイミング情報が整合している状態で、コンテンツのデータを出力する。なお、統合部360は、映像および音声のコンテンツを、エンコードされたままの状態で受信部320から受け取る。そして、そのままの状態で、字幕テキストのコンテンツとの統合を行う。
【0072】
配信部380は、インターネット等を経由して、統合部360から渡されたコンテンツのファイルを配信する。具体的には、配信部380は、映像と音声と字幕テキストのコンテンツを配信する。
【0073】
[第3実施形態:変形例1]
次に、第3実施形態の変形例1について説明する。この変形例の基本的な構成は、第2実施形態におけるそれと同一であるが、統合部360が、さらに言語翻訳を行う点が、特徴的な構成である。
【0074】
第3実施形態の変形例1において、編集部340は、言語翻訳エンジンを備える。言語翻訳エンジンは、自然言語によるテキストの他国語への翻訳を行う。例えば、統合部360は、音声認識処理の結果として得られた日本語のテキストを、英語に翻訳し、英語の字幕テキストデータを出力する。あるいは、編集部340は、音声認識処理の結果として得られたフランス語のテキストを、日本語に翻訳し、日本語の字幕テキストデータを出力する。なお、翻訳元と翻訳先の言語は、ここに例示したもの以外であってもよい。なお、元の音声に付加されていたタイミング情報に基づいて、翻訳後の字幕テキストにもタイミング情報が付与される。編集部340は、翻訳後の字幕テキストを、統合部360に送信する。その後の処理は、既に述べた形態における処理と同様である。
【0075】
[第3実施形態:変形例2]
次に、第3実施形態の変形例2について説明する。この変形例の基本的な構成は、第2実施形態におけるそれと同一であるが、統合部360が、さらに手話への翻訳を行う点が、特徴的な構成である。
なお、言語翻訳の機能自体には、既存の技術を適用すれば良い。
【0076】
第3実施形態の変形例2において、編集部340は、手話への翻訳機能を備える。言語翻訳エンジンは、音声認識処理の結果得られたテキストデータを、手話表現に翻訳する。そして、編集部340は、翻訳後の手話表現に対応する映像のコンテンツを生成し、出力する。手話は、例えば、コンピューターグラフィクス(CG)を用いて映像として表される。なお、元の音声に付加されていたタイミング情報に基づいて、出力される手話の映像にもタイミング情報が付与される。編集部340は、生成された手話の映像のデータを、統合部360に送信する。統合部360は、第3実施形態で説明した字幕テキストデータの代わりに、手話の映像のデータを、配信部380に渡す。配信部380は、元の映像および音声のコンテンツと、編集部340によって生成された手話の映像とを、配信する。
【0077】
なお、上述した実施形態およびその変形例における再配信システムの機能や、再配信システムを構成する一部の装置の機能をコンピューターで実現するようにしても良い。その場合、この機能を実現するためのプログラムをコンピューター読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピューターシステムに読み込ませ、実行することによって実現しても良い。なお、ここでいう「コンピューターシステム」とは、OSや周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM、DVD−ROM、USBメモリー等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【0078】
以上、説明した各実施形態またはその変形例のいずれかによれば、再配信システムは、インターネット等を介して、例えばHLS等の手段を用いて配信されるコンテンツを受信する。言い換えれば、再配信システムは、ベースバンド信号(非圧縮信号)で構成されるコンテンツを受信しない。そして、再配信システムは、受信したコンテンツの少なくとも一部に基づいて、別の新たなコンテンツを生成する。そして、再配信システムは、受信したオリジナルのコンテンツと、生成した新たなコンテンツとを統合したうえで、再配信する。再配信もまた、例えば、HLS等を用いる。これにより、クライアント装置は、新たなコンテンツが付加された状態でコンテンツのストリーミング配信を受けることが可能となる。
【0079】
そして、各実施形態またはその変形例によれば、最小限の工程および機材により、再配信システムを実現することが可能となり、システムを構築したり運用したりするコストを抑えられる。また、例えば、インターネットに接続できる環境さえあれば基本的にどこにおいても、配信形式のストリーミング映像に対して、音声等の新たなコンテンツを付加して再配信するサービスを実現することができる。
【0080】
コストに関して言えば、ベースバンド信号(非圧縮信号)のプロセッシングを行う高価な特殊機器が不要であり、インターネットにより映像の伝送が可能となるため、伝送コストの大幅な削減が期待できる。さらに、汎用的なコンピューターと、その上で稼働するソフトウェアのみでの処理が可能となるため、インターネット接続可能な場所であればどこからも、コンテンツを付加するサービスを実現することができる。また、元のコンテンツ(映像や音声等)と、付加するコンテンツ(たとえば、音声等)のタイミングを再配信システム内で自動的に同期させることができる。これにより、既存のストリーム映像音声にリアルタイムで新たなコンテンツ(音声等)を付加するという流れを1つにし、サービスの容易な実現が可能となる。コンテンツ配信等のサービスにおいて上の実施形態等で説明した構成を適用することにより、多様で、機動力に富んだサービスを提供することができるようになる。
【0081】
なお、再配信システムが新たに付加するコンテンツは、音声のコンテンツに限られない。既に説明した例では、テキスト(いわゆる字幕テキストを含む)や、映像(一例として手話の映像)を生成して付加することができる。また、ここに例示したもの以外のコンテンツを、生成して付加することも可能となる。
【0082】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではない。さらなる変形例で実施するようにしてもよい。また、この発明の要旨を逸脱しない範囲の設計等を行ってもよい。
【0083】
例えば、上記の実施形態では、映像や音声のコンテンツを配信するための形式としてHLSを用いたが、他の形式によって配信するようにしてもよい。例えば、MPEG−DASHや、HDSや、MS Smooth Streamingなどといった形式も、使用することができる。