JP2012044306A - 分散トランスコーディングシステム並びに方法、及びトランスコーディング装置 - Google Patents

Abstract

【課題】シングルポイント障害及びシステム拡張の際のボトルネック問題を解消することができる分散トランスコーディングシステムを提供する。
【解決手段】複数のノード５〜９と、少なくとも一つのデータベース４とを有する分散トランスコーディングシステム１であって、前記複数のノード５〜９は、前記データベース４上のトランスコーディングに関するタスクリストから取得したタスクを実行するタスク実行部５ａ〜９ａと、前記タスク実行部５ａ〜９ａが前記取得したタスクを実行した後に実行されるべき少なくとも一つのタスクを生成し、前記タスクリストを更新するタスク生成部５ｂ〜９ｂと、を備える。
【選択図】図１

Description

本発明はマルチメディアデータの分散トランスコーディングシステム並びに方法、及びトランスコーディング装置に関するものである。

ＹｏｕＴｕｂｅ（登録商標）のようなユーザが作成したコンテンツを掲載するサイトや、インターネットを介してテレビコンテンツをオンデマンドに配信するフールー（Ｈｕｌｕ）のような企業の出現により、インターネットビデオに革命が起こりつつある。これに伴い、オーディオビジュアルコンテンツの作成、編集及び配信に使用されるビデオコーデックも増加している。これらのコーデックには、Ｈ．２６４／ＡＶＣ、Ｔｈｅｏｒａ、ＭＰＥＧ４のような非常に複雑なものも含まれる。

他方、様々な端末装置や再生装置においてこれらのインターネットビデオを再生するためには、様々なビデオフォーマットが要求される。例えば、携帯電話は３ＧＰ又は３ＧＰ２に、ＰＣはＡＶＩ、ＭＰＥＧ４、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ又はＦＬＶに、ＩＰＴＶ（Internet Protocol Television）のセットトップボックスはＭＰＥＧ２に、それぞれ対応している。

従って、同じインターネットビデオを、様々な装置及びプラットフォームで再生するためには、様々なビデオフォーマットに変換する必要がある。このためには、ビデオ配信会社は、膨大な量のビデオトランスコーディングタスクを行わなくてはならない。

要求されるフォーマットやコーデックによっては、トランスコード処理は非常に複雑であり時間がかかる。例えば、一つのフルハイビジョン動画をＨ．２６４／ＡＶＣ動画に変換するためには、比較的高スペックのＰＣ（Quad Core 2.9GHz, 4GB RAM）を用いても、動画自体の長さの約８倍〜１０倍の時間がかかる。トランスコードにこれ程の時間がかかると、ビデオ配信会社が、数百〜数千ものビデオを様々な出力フォーマット及びコーデックにトランスコードする際に、タイミングよくトランスコーディングシステムを動作させることが非常に難しくなる。更に、一つの装置により一つの動画データをトランスコードするシステムは、装置の故障に対して非常に脆弱である。

そこで、トランスコーディングに複数の装置を用いるトランスコーディングシステムが開発されてきた。例えば、特許文献１に記載のシステムは、スケジューラを内蔵するソースサーバを備える。ソースサーバは、動画データをセグメントに分割し、各セグメントを各トランスコード装置へ送信する。そして、各トランスコード装置は、トランスコードした動画データを結合サーバへと送り、結合サーバはそれらを結合する。このように、複数のトランスコード装置によりトランスコード処理を並列的に実行するため、処理効率が向上する。

特開２００５−１７６０６９号公報

しかし、このようなシステムは、ソースサーバに備えられたスケジューラがどのセグメントをどのトランスコード装置に送信するかを決定し、分配するため、シングルポイント障害に対して脆弱である。更には、従来の分散トランスコーディングシステムは、システムの拡張性にも欠いていた。例えば、処理を高速化するために、何百又は何千ものトランスコード装置を用いる分散トランスコーディングシステムを構築することを想定した場合、スケジューラの負荷が増大してしまうため、トランスコード装置の数を増やしても、スケジューラがボトルネックとなって、タスク処理の迅速性を十分に向上させることができない。

したがって、かかる点に鑑みてなされた本発明の目的は、シングルポイント障害及びシステム拡張の際のボトルネック問題を解消することができる分散トランスコーディングシステムを提供することにある。

上記目的を達成する第１の観点に係るシステムの発明は、
複数のノードが協調して一つのデータベースを構築する分散トランスコーディングシステムであって、
前記複数のノードは、
前記データベース上のトランスコーディングに関するタスクリストから取得したタスクを実行するタスク実行部と、
前記タスク実行部が前記取得したタスクを実行した後に実行されるべき少なくとも一つのタスクを生成し、前記タスクリストを更新するタスク生成部と、を備える
ことを特徴とするものである。

第２の観点に係る発明は、第１の観点に係るシステムであって、
前記タスク生成手段は、前記タスク実行手段が所定のタスクを実行した後に複数のタスクを生成する、ことを特徴とするものである。

上記目的を達成する第３の観点に係る方法の発明は、
複数のノードと、少なくとも一つのデータベースとを用いる分散トランスコーディング方法において、
前記複数のノードが、
データベース上のトランスコーディングに関するタスクリストから取得したタスクを実行するステップと、
前記取得したタスクを実行した後に実行されるべき少なくとも一つのタスクを生成し、前記タスクリストを更新するステップと、を含む
ことを特徴とするものである。

第４の観点に係る発明は、第３の観点に係る方法であって、
前記複数のノードが、所定のタスクを実行した後に複数のタスクを生成する、ことを特徴とするものである。

上記目的を達成する第５の観点に係る方法の発明は、
少なくとも一つのデータベースを有する分散トランスコーディングシステムに含まれるノードであって、
前記データベース上のトランスコーディングに関するタスクリストから取得したタスクを実行するタスク実行部と、
前記タスク実行部が前記取得したタスクを実行した後に実行されるべき少なくとも一つのタスクを生成し、前記タスクリストを更新するタスク生成部と、を備える
ことを特徴とするものである。

本発明によれば、シングルポイント障害及びシステム拡張の際のボトルネック問題を解消することができる分散トランスコーディングシステムを提供することができる。

本発明の一実施の形態に係る分散トランスコーディングシステムの概略構成を示す図である。 本発明の一実施の形態に係る分散トランスコーディングシステムにおける処理の流れを示すフローチャートである。 本発明の一実施の形態に係る分散トランスコーディングシステムにおける、段階的なタスクの実行を説明する図である。 本発明の一実施の形態に係る分散トランスコーディングシステムにおける、タスクの選択、実行、生成過程を示す概略フローチャートである。

以下、本発明の実施の形態について、図を参照して説明する。

図１は、本発明の一実施の形態に係る分散トランスコーディングシステムの概略構成を示す図である。分散トランスコーディングシステム１は、ネットワーク２に接続するデータベースサーバ３、複数のノード５〜９、ストレージ１０、クライアント１１を有する。ネットワーク２は、例えば、ＬＡＮ（local area network）やインターネットである。データベースサーバ３は、例えば、リレーショナルデータベースマネジメントシステム（ＲＤＢＭＳ）を有する。更に、データベースサーバ３はデータベース４を有し、データベース４は、例えば、ＭｙＳＱＬ Ｃｌｕｓｔｅｒのようなトランザクションをサポートするクラスタデータベースとして実装される。データベース４は、トランスコーディングに関連するタスクリストを有する。

トランスコーディングに関連する基本的なタスクには、ビデオソースファイルをシステムに取り込む「取り込みタスク」と、ビデオデータとオーディオデータとを分離する「分離タスク」と、「ビデオデコードタスク」と、「ビデオフィルタリングタスク」と、「ビデオ分析タスク」と、「ビデオセグメンテーションタスク」と、「オーディオデコードタスク」と、「オーディオフィルタリングタスク」と、「オーディオ分割タスク」と、「エンコードタスク」と、「結合タスク」と、「多重化タスク」とが含まれる。これらのタスクの間には実行順序依存関係がある。

例えば、「ビデオ分析タスク」の完了後でなければ「ビデオセグメンテーションタスク」を実行できず、「ビデオセグメンテーションタスク」の完了後で無ければ「ビデオエンコードタスク」を実行できず、「エンコードタスク」の完了後でなければ、「結合タスク」を実行できない。

ノード５〜９は、例えば、サーバやＰＣ（personal computer）である。そして、ノード５〜９は、それぞれ、データベース４上のタスクリストから取得したタスクを実行するタスク実行部５ａ〜９ａと、一つのタスクの実行を完了すると次に実行されるべきタスクを生成し、データベース４上のタスクリストを更新するタスク生成部５ｂ〜９ｂを備える。このようにして、タスク生成部５ｂ〜９ｂは、タスク間の実行順序依存関係を担保する。また、タスクの実行にあたって、タスク実行部５ａ〜９ａは、自ノード内のリソースが許容する場合に、タスクリストからタスクを取得し、実行する。尚、タスク実行部５ａ〜９ａ及びタスク生成部５ｂ〜９ｂは、例えば、ＣＰＵ（Central Processing Unit）により構成される。

ここで、タスク実行部５ａ〜９ａ又はタスク生成部５ｂ〜９ｂは、タスクの実行や完了に基づいて、タスクの状態が、（１）未処理、（２）実行中、（３）完了、（４）失敗、（５）失効のうちの何れの状態であるかを、協調してデータベース４上のタスクリストに更新する。以下に各状態について説明する。

（１）「未処理」とは、各タスクの初期状態であり、タスクが新規に作成されたものであり、且つ処理を待機している状態を指す。
（２）「実行中」とは、何れかのノードがタスクを取得し、実行中であることを示す。
（３）「完了」とは、タスクが完了し、更なる処理が不要な状態であることを示す。
（４）「失敗」とは、何らかの問題によりタスクが完了せず、問題回復のための措置を必要としている状態を指す。
（５）「失効」とは、「実行中」状態のタスクが、所定時間以上ノードにより更新されない状態を指す。このような状態は、例えば、ネットワークやハードウェアに何らかの障害が生じたことにより、ノードがタスク状態を「失敗」に変更することができなかった場合に発生する。

データベース４はトランザクションをサポートしているため、仮に、２つのノードが同時に同じタスクを取得し、実行しようとしたとしても、コリジョンが生じない。

また、タスク実行部５ａ〜９ａ及びタスク生成部５ｂ〜９ｂは、ストレージ１０にアクセス可能である。ストレージ１０は、例えば、従来の集中システムにおいて一般的に用いられていたようなＮＡＳ（network attached storage）や、ＭｏｇｉｌｅＦＳ及びＨａｄｏｏｐファイルシステムのような分散ファイルシステムである。

さらに、クライアント１１は、トランスコーディングジョブを分散トランスコーディングシステム１に提出するためのジョブ提出部１２を有する。ジョブ提出部１２が提出するトランスコーディングジョブは、例えば、ＸＭＬファイルのようなテキストデータであり、ビットレート、フレームレート、解像度、画像サイズ、適用すべきフィルタ、エンコード方式等のトランスコードに関連する全てのパラメータや、トランスコードすべきデータ（ソースファイル）の場所を示す、ＵＲＩのようなポインタを含む。エンコード方式は、例えばＣＢＲ（Constant Bit Rate）方式と、ＶＢＲ（Variable Bit Rate）方式がある。

図２は、本発明の一実施の形態に係る分散トランスコーディングシステム内のタスク処理の概要を示すフローチャートである。タスク実行部５ａ〜９ａは、適宜、自ノードの空きリソースや、ネットワーク状態をモニタリングしているものとする。これにより、それぞれのノードにおいて、適切なタスクを取得し実行することが可能になる。

タスク実行部５ａ〜９ａの何れかが、クライアント１１からの、新たなトランスコーディングジョブを検出することによりトランスコーディング処理が開始する。タスク実行部５ａがトランスコーディングジョブを検出したとすると、タスク生成部５ｂは、トランスコーディングジョブの内容に基づいて、ソースファイル読み込みタスクを作成し、データベース４上のタスクリストを更新する（ステップS１１）。

タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、ソースファイル取り込みタスクを自ノードで行うか否か決定する。このときの決定方法は、図４を参照して後述する方法に従う。

ここでは、ノード６のタスク実行部６ａがソースファイル取り込みタスクを行うことを決定したとする(ステップＳ１２)。ステップＳ１２において、タスク実行部６ａは、トランスコーディングジョブに含まれるポインタ情報（ＵＲＩ）に示された場所からソースファイルをコピーし、ストレージ１０に保存する。これにより、分散トランスコーディングシステム１内の全てのノード５〜９が、ソースファイルにアクセスできるようになる。さらに、ステップＳ１２ではタスク生成部６ｂは次に行うべきタスクであるビデオ／オーディオ分離タスクを生成し、データベース４上のタスクリストを更新する(ステップＳ１２)。

ステップＳ１２と同様に、タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、ビデオ／オーディオ分離タスクを自ノードで行うか否かを決定する。

ここでは、ノード７のタスク実行部７ａがビデオ／オーディオ分離タスクを行うことを決定したとする（ステップＳ１３）。ステップＳ１３において、タスク実行部７ａは、ストレージ１０からソースファイルをダウンロードし、ソースファイルをオーディオデータとビデオデータとに分離し、分離した各データをストレージ１０にアップロードする。アップロードが完了すると、タスク生成部７ｂは、次に行うべきタスクであるビデオデコードタスクと、オーディオ分割タスクとを生成する。

先ず、ステップＳ１４におけるビデオデコードタスクについて説明する。タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、ビデオデコードタスクを自ノードで行うか否かを決定する。

ここでは、ノード８のタスク実行部８ａがビデオデコードタスクを行うことを決定したとする（ステップＳ１４）。ステップＳ１４において、タスク実行部８ａは、ストレージ１０からステップＳ１３において分離されたビデオデータをダウンロードし、元のフォーマットから、例えば、ＹＵＶ４２２又はＲＧＢのようなローフォーマットにデコードし、ストレージ１０にアップロードする。デコードを完了すると、タスク生成部８ｂは、次に行うべきタスクであるビデオフィルタリングタスクを生成し、データベース４上のタスクリストに更新する（ステップS１４）。

タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、ビデオフィルタリングタスクを自ノードで行うか否かを決定する。

ここでは、ノード９のタスク実行部９ａがビデオフィルタリングタスクを行うことを決定したとする（ステップＳ１５）。ステップＳ１５において、タスク実行部９ａは、ストレージ１０からステップＳ１４においてローフォーマットにデコードされたデータ（ローデータ）をダウンロードし、いくつかのフィルタリング処理を実行し、ストレージ１０にアップロードする。そして、タスク生成部９ｂは、次に行うべきタスクであるビデオ分析タスク（ステップＳ１６）又はビデオ分割タスク（ステップＳ１７）を生成し、データベース４上のタスクリストに更新する（ステップS１５）。

ステップＳ１５において、タスク実行部９ａが使用するフィルタは、例えば、デインターレースフィルタ、逆テレシネフィルタ、解像度変換フィルタ、ビデオフレームレートリサンプリングフィルタである。

このとき、タスク生成部７ｂは、以下に述べる理由により、エンコード方式がＣＢＲのビデオを出力する場合に限って、ビデオ分析タスクを生成する。出力ビデオのエンコード形式がＶＢＲの場合は、ビデオ分析タスクは行われない。

ＣＢＲエンコーディングを行う場合には、トランスコード後のファイルにおけるビットレートの制約に基づいてビデオの分割ポイントを選択する必要がある。仮に、ステップＳ１７におけるビデオ分割タスクにおいて、ランダムに分割ポイントを選択した場合、トランスコード済みのファイル内でのビットレート分布が不均一となるおそれがあるためである。

一方、ＶＢＲエンコーディングを行う場合には、ビットレート制約に関わらず、ビデオ全体を通じて品質が一定であることが望ましい。この場合、エンコード後のビデオ内におけるビットレート分布をどのようなものにするかに関わらず、自由にビデオを分割することができるため、「分析」タスクが必須ではない。以下、タスク実行部タスク実行部５ａ〜９ａはＣＢＲエンコーディングを行うものとして各ステップについて説明する。

タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、ビデオ分析タスクを自ノードで行うか否かを決定する。

ここでは、ノード５のタスク実行部５ａがビデオ分析タスクを行うことを決定したとする（ステップＳ１６）。ステップＳ１６において、タスク実行部５ａは、ストレージ１０からステップＳ１５においてフィルタリングされたデータをダウンロードし、分析する。例えば、タスク実行部５ａは、ファストパスエンコーディングを実行し、例えば、キーフレームやＩフレーム（イントラ符号化フレーム）を特定し、又はビットレート分布などの統計情報を取得する。そして、タスク生成部５ｂは、得られたフレーム情報や統計情報を含むビデオ分割タスクを生成して、データベース４上のタスクリストを更新する（ステップＳ１６）。

なお、ＣＢＲエンコーディングにおいては、２以上のエンコーディングパスを用いることが可能である。それぞれのパスにおいて、現在又は次のパスにおけるビット分布を改良するために、それより前のパスにおいて分析された統計値を活用する。

次に、タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、ビデオ分割タスクを自ノードで行うか否かを決定する。

ここでは、ノード６のタスク実行部６ａがビデオ分割タスクを行うことを決定したとする（ステップＳ１７）。ステップＳ１７において、タスク実行部６ａは、ストレージ１０からローデータをダウンロードし、ビデオ分割タスクにおいて取得されたフレーム情報及び統計情報を参照して、ローデータを分割する。「分割」と記載したが、必ずしもローデータを物理的に分割する必要は無く、例えばＸＭＬ、又はＪＳＯＮのような構造化テキストファイルに、ローデータにおける最適な分割ポイントの情報を記載することで、後続のタスクの実行に際して各ノードがダウンロードすべきローデータを部分を特定し、部分ダウンロードを実行することも可能である。そして、タスク生成部６ｂは、分割ポイントの情報を含む、複数のビデオセグメントエンコードタスクを生成して、データベース４上のタスクリストを更新する（ステップＳ１７）。

ここで、ＣＢＲ、ＶＢＲエンコーディングのいずれの場合においても、ビデオ分割タスクの実行時において決定するセグメントの数は、２の階乗とすることが好ましい。これにより、ビデオ結合タスクにおいて、結合相手となるセグメント（ペアセグメント）を探索することが容易になる。

ここでは、それぞれ異なるノード８、９、５、及び６がステップＳ１４〜Ｓ１７までの処理を行うものとして説明した。しかし、ローデータのデータ量は非常に大きいか、又はアップロードチャネルが遅ければ、データの、ダウンロード及びアップロードに時間がかかる。これを回避するために、ステップＳ１４〜Ｓ１７において実行されたタスクを、一つのタスクとして生成し、一つのノードにおいて行うことも可能である。

次に、タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、ビデオセグメントエンコードタスクを自ノードで行うか否かを決定する。

ここでは、タスク実行部５ａ〜９ａ全てがビデオセグメントエンコードタスクを自ノードで行うことを決定したとする（ステップＳ１８）。ビデオセグメントエンコードタスクを取得したタスク実行部５ａ〜９ａは、ビデオセグメントエンコードタスクにおいて取得された分割ポイントの情報に基づいて、ストレージ１０からローデータのフラグメントを部分ダウンロードし、トランスコーディングジョブに含まれる種々のパラメータに従って、部分ダウンロードしたローデータをエンコードする。エンコードが完了すると、タスク実行部５ａ〜９ａは、それぞれ、エンコード済みのデータをストレージ１０にアップロードする。タスク生成部５ｂ〜９ｂは、それぞれ、次に行われるべきタスクであるビデオ結合タスクを生成して、データベース４上のタスクリストを更新する（ステップＳ１８）。

次に、タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、ビデオ結合タスクを自ノードで行うか否かを決定する。

ここでは、タスク実行部５ａが、一つのビデオ結合タスクを取得したとする。図３に示すように、タスク実行部５ａは、ビデオ結合タスクを段階的に実行する。ここで、結合タスクは、共通のタスクＩＤ（「タスクＲ」とする）、ステージ番号（「＋ｎ」とする）、連続番号（「＿ｎ」とする）からなる、例えば、「ＴａｓｋＲ＋１＿１」のような識別情報を含んでいる。

ビデオ分割タスクにおいて、タスク実行部６ａは、２のｍ乗個のセグメントにローデータを分割したものとし、タスク生成部６ｂは、一つのビデオ分割タスクの生成後に生成した全てのビデオ結合タスクについては、同一のタスクＩＤが付す。また、ここでは、２^m＝ｎの関係が成り立つものする。ステージ番号は、結合タスクの段階が進むほどに大きくなる番号である。１つのビデオ結合タスク（識別情報［タスクＩＤ、ステージ番号、シリアル番号］を有する）を取得した一つのタスク実行部は、原則的に以下の規則に従って、結合相手となるタスク（ペアタスク）を取得する。

（１）連続番号が奇数の場合は、識別情報［タスクＩＤ、ステージ番号、シリアル番号＋１］を有するビデオ結合タスクを探索する。
（２）連続番号が偶数の場合は、識別情報［タスクＩＤ、ステージ番号、シリアル番号−１］を有するタスクを探索する。

例えば、タスク実行部５ａが取得したタスクが、識別情報［タスクＩＤ、ステージ番号、シリアル番号］＝［１０２、３、１］を有する場合には、タスク実行部５ａは、結合相手として、識別情報［１０２、３、２］を有するタスクをタスクリスト上で探索する。そして、結合相手である、識別情報［１０２、３、２］を有するタスクが取得可能であれば、タスク実行部５ａは、当該タスクを取得し、タスクに記載されたＵＲＩなどのポインタ情報に基づいて、ストレージ１０から２つのエンコード済みデータをダウンロードする。そして、タスク実行部５ａはこれら２つのエンコード済みデータを結合し、結合タスクが完了すると、タスク生成部５ｂは、新しいビデオ結合タスクを生成する。タスク生成部５ｂは、この新しいビデオ結合タスクに付与すべき識別情報の算出にあたって、ステージ番号については、１を加え、シリアル番号については、結合した２つのエンコード済みデータのそれぞれに対応するビデオ結合タスクのシリアル番号１及び２を比較して、大きい方の値である２を２で除算する（以後、ｍａｘ（１，２）／２と示す）。すなわち、タスク生成部５ｂは、新しいビデオ結合タスクについて識別情報［１０２、３＋１、ｍａｘ（１，２）／２］＝［１０２、４、１］を付与する。

一方、他のノード６のタスク実行部６ａが、識別情報［１０２、３、３］を有するビデオ結合タスクと、識別情報［１０２、３、４］を有するビデオ結合タスクの実行を完了すると、当該ノードのタスク生成部６ｂは、新しいビデオ結合タスクとして、識別情報［１０２、３＋１、ｍａｘ（３、４）／２］＝［１０２、４、２］を有する結合タスクを生成し、データベース４上のタスクリストに更新する。すると、他のノード７のタスク実行部７ａが識別情報［１０２、４、１］を有するビデオ結合タスクと、［１０２、４、２］を有するビデオ結合タスクとをデータベース４上のタスクリストから取得し、実行する。ビデオ結合タスクの実行が完了すると、当該ノードのタスク生成部７ｂは、新たなビデオ結合タスクとして、識別情報［１０２、４＋１、ｍａｘ（１、２）／２］＝［１０２、５、１］を有する新たな結合タスクを生成し、タスクリストにアップロードする。

データベース４上に残ったタスクが、識別情報［１０２、ｍ、１］を有するビデオ結合タスクのみであれば、タスク実行部５ａ〜９ａは、２のｍ乗個（ｎ個）のセグメントの全てに対応するビデオ結合タスクが完了したことを判断する。そして、タスク実行部５ａ〜９ａビデオ結合タスクが完了したことを判断すると、タスク生成部５ｂ〜９ｂの何れかは、次に行われるべきタスクであるビデオ多重化タスクを生成し、データベース上のタスクリストを更新する（ステップＳ１９）。

上述においては、タスク実行部５ａ〜９ａがＣＢＲエンコーディングを行うものとして説明してきた。しかし、タスク実行部５ａ〜９ａは、ＶＢＲエンコーディングを行う場合には、ビデオ分析タスク（ステップＳ１６）は行わず、ビデオ分割タスク（ステップＳ１７）においては、例えば、ビデオフィルタリングタスク（ステップＳ１５）において取得されたビデオの長さ情報、トランスコーディングシステム全体のスペック、各ノードのスペック、及びチャネル特性等に基づいて決定した分割後のセグメント数に基づいてビデオを分割する。

次に、オーディオデータに係るステップＳ２０〜Ｓ２４について説明する。タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、オーディオ分割タスクを自ノードで行うか否かを決定する。

ここでは、タスク実行部７ａがオーディオ分割タスクを行うことを決定したとする（ステップＳ２０）。ステップＳ２０において、タスク実行部７ａは、ストレージ１０からステップＳ１３においてソースファイルから分離したオーディオデータをダウンロードし、セグメントではなく、オーディオチャネルごとに分割し、ストレージ１０にアップロードする。そして、タスク生成部７ｂは、次に行われるべきオーディオチャネルデコードタスクを生成し、データベース４上のタスクリストを更新する（ステップＳ２０）。

タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、オーディオチャネルデコードタスクを自ノードで行うか否かを決定する。

ここでは、タスク実行部５ａ〜９ａ全てがオーディオチャネルデコードタスクを行うことを決定したとする（ステップＳ２１）。ステップＳ２１において、タスク実行部５ａ〜９ａは、それぞれ、ストレージ１０からデコードすべき一つのオーディオチャネルをダウンロードし、ローフォーマットにデコードし、ローフォーマットのオーディオチャネルファイルをストレージ１０にアップロードする。デコードを完了すると、タスク生成部５ｂ〜９ｂは、次に行うべきタスクであるオーディオチャネルフィルタリングタスクを生成し、データベース４上のタスクリストに更新する（ステップS２１）。

タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、オーディオチャネルフィルタリングタスクを自ノードで行うか否かを決定する。

ここでは、タスク実行部５ａ〜９ａ全てがオーディオチャネルフィルタリングタスクを行うことを決定したとする（ステップＳ２２）。ステップＳ２２において、タスク実行部５ａ〜９ａは、ストレージ１０からステップＳ２１においてローフォーマットにデコードされたデータをダウンロードし、いくつかのフィルタリング処理を実行し、ストレージ１０にアップロードする。フィルタリングを完了すると、タスク生成部５ｂ〜９ｂは、次に行うべきタスクであるオーディオチャネルエンコードタスクを生成し、データベース４上のタスクリストに更新する（ステップS２２）。

ステップＳ２２において、タスク実行部５ａ〜９ａが使用するフィルタは、例えば、オーディオリサンプリングフィルタ、チャネルリサンプリング及びダウン・アップミキシングフィルタ、音量調整フィルタ、及びオーディオサンプリング調整フィルタである。

次に、タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、オーディオチャネルエンコードタスクを自ノードで行うか否かを決定する。

ここでは、タスク実行部５ａ〜９ａ全てがオーディオチャネルエンコードタスクを自ノードで行うことを決定したとする（ステップＳ２３）。オーディオチャネルエンコードタスクを取得したタスク実行部５ａ〜９ａは、ストレージ１０からオーディオチャネルのローデータをダウンロードし、トランスコーディングジョブに含まれる種々のパラメータに従って、ダウンロードしたローデータをエンコードする。エンコードが完了すると、タスク実行部５ａ〜９ａは、エンコード済みのデータをストレージ１０にアップロードする。タスク生成部５ｂ〜９ｂは、次に行われるべきタスクであるオーディオ結合タスクを生成して、データベース４上のタスクリストを更新する（ステップＳ２３）。

ここでは、それぞれ異なるノード８、９、５がステップＳ２１〜Ｓ２３までの処理を行うものとして説明した。しかし、ローデータのデータ量は非常に大きく、ダウンロード及びアップロードに時間がかかるため、ステップＳ２１〜Ｓ２３は一つのノードにおいて行うことも可能である。

次に、タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、オーディオ結合タスクを自ノードで行うか否かを決定する。

ここでは、タスク実行部６ａがオーディオ結合タスクを取得したとする。タスク実行部６ａは、オーディオデータについては、チャネルごとに分割したデータを結合する。この結合タスクは、非常に負荷が少ない。したがって、ビデオ結合タスクのように段階的に実行する必要は無く、全ての結合タスクを一つのタスク実行部６ａにおいて処理することが可能である。そして、タスク実行部６ａが全ての音声データの結合タスクを終了し、結合相手となるタスクが存在しないことを判断すると、タスク生成部６ｂは、ビデオ／オーディオ多重化タスクを生成し、データベース４上のタスクリストを更新する（ステップＳ２４）。

ここでは、オーディオデータはチャネル毎に分割し（ステップＳ２０）、後続の処理、すなわち、デコード（ステップＳ２１）、フィルタリング（ステップＳ２２）、及びエンコード（ステップＳ２３）は、それぞれ、チャネル毎に行うものとして記載した。しかし、ビデオデータと同様に、オーディオデータについても、ステップＳ２０においてセグメント毎に分割し、デコード（ステップＳ２１）、フィルタリング（ステップＳ２２）、及びエンコード（ステップＳ２３）を各セグメントについて行うようにトランスコーディングシステムを構成することも可能である。この際、タスク実行部５ａ〜９ａの一つ又は複数は、ステップＳ２４におけるオーディオ結合タスクを、２段階で実行する。まず、第１段階として、タスク実行部５ａ〜９ａの一つ又は複数は、各オーディオチャネルのセグメント又はフラグメントを結合して、１つのオーディオチャネルのオーディオファイルとする。そして、第２段階として、タスク実行部５ａ〜９ａの一つ又は複数は、２つ又は複数のオーディオチャネルを一つのオーディオファイルに多重化する。そして、タスク実行部５ａ〜９ａの一つ又は複数は、多重化したオーディオファイルをストレージ１０にアップロードし、タスク生成部５ｂ〜９ｂは、ビデオ／オーディオ多重化タスクを生成し、データベース４上のタスクリストを更新する（ステップＳ２４）。

タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、ビデオ／オーディオ多重化タスクを自ノードで行うか否かを決定する。

ここでは、ノード７のタスク実行部７ａが、ビデオ／オーディオ多重化タスクを行うことを決定したとする（ステップＳ２５）。タスクリストから、ビデオ／オーディオ多重化タスクを取得すると、タスク実行部７ａは、データベース４上のタスクリスト内において、対応するオーディオ（ビデオ）多重化タスクを探索する。ここで、タスク実行部７ａは、多重化すべきタスクを例えばタスクIDのような識別情報によって識別することができる。データベース４上のタスクリストから、多重化すべき２つの多重化タスクを取得すると、タスク実行部７ａは、ストレージ１０から結合済みのビデオ及びオーディオデータをそれぞれダウンロードし、これらのデータの多重化を実行する。多重化したデータは、例えば、ＭＰ４、３ＧＰ、ＦＬＶ、ＷＭＶ、ＡＶＩのような、クライアント１１からのトランスコーディングジョブに含まれる所望のフォーマットである。多重化タスクが完了すると、タスク実行部７ａは多重化したデータ（トランスコード済みデータ）をストレージ１０にアップロードし、タスク生成部７ｂはトランスコード済みデータを送信すべき場所のＵＲＩの情報を含むアップロードタスクを生成し、データベース４上のタスクリストを更新する（ステップＳ２５）。

タスク実行部５ａ〜９ａは、それぞれ、自ノード内の空きリソース、ネットワーク状態等に基づいて、アップロードタスクを自ノードで行うか否かを決定する。

ここでは、ノード８のタスク実行部８ａがアップロードタスクを自ノードで行うことを決定したとする（ステップS２６）。タスクリストからアップロードタスクを取得すると、タスク実行部８ａは、トランスコード済みファイルをアップロードすべきＵＲＩに対して、トランスコード済みのファイルをストレージ１０からコピーして転送する。このときの転送方法は多様であり、例えば、ＦＴＰ（File Transfer Program）、ＳＦＴＰ（Secure File Transfer Program）、及びWebDav等が挙げられる。

図４は、タスク実行部５ａ〜９ａがタスクを選択、実行し、タスク生成部５b〜９ｂがタスクを生成する過程を示す概略フローチャートである。以下、タスク実行部５ａ〜９ａ及びタスク生成部５ｂ〜９ｂは、単に「タスク実行部」及び「タスク生成部」として示す。タスク実行部は、まず、データベース４上のタスクリストから「失効」状態のタスクのリストを取得する（ステップＳ３１）。これは、「失効」状態のタスクは、本来であれば既に処理が完了しているべきタスクであり、優先的に処理を行う必要性が高いからである。

「失効」状態のタスクが無ければ、タスク実行部は「未処理」状態のタスクをタスクリストから取得する（ステップＳ３２のＹ、ステップＳ３３）。「未処理」状態のタスクがあれば、タスク実行部は、タスクを選択する（ステップＳ３４のＮ、ステップＳ３５）。一方、「未処理」状態のタスクが無ければ、タスク実行部は所定時間の間スリープモードに移行する（ステップＳ３４のＹ、ステップＳ３６）。

ステップＳ３５においてタスクを選択するにあたって、タスク実行部は、例えば、自ノードの負荷状態、利用可能リソース、タスク作成日時、タスク処理負荷等に基づいて、実行すべきタスクを選択する。タスク作成日時の古いものは新しいタスクに優先して選択される。また、例えば、ＣＰＵ（Central Processing Unit）の速度が遅く、メモリ容量が小さいタスク実行部は、分割、結合、多重化などの処理負荷の小さいタスクを選択する。逆にＣＰＵの処理速度が速いノードは、オーディオ／ビデオエンコード又は分析タスクを選択する。また、特定のコーデックやフォーマットのデータについてのエンコード及び多重化にのみ対応するタスク実行部は、それらのデータのエンコード及び多重化タスクだけを実行する。そのようなタスク実行部を備えるノードは、例えば、ウィンドウズ・メディアコーデックを用いたエンコードや多重化にのみ対応しているウィンドウズプラットフォームである。

一旦タスクを選択すると、タスク実行部はタスクをロックする（ステップＳ３７）。ここで、「タスクをロックする」とは、タスクリスト上におけるタスクの状態を「未処理」から「実行中」へと変更することをいうものとする。これにより、他のタスク実行部が同じタスクを取得することを回避する。ロックが完了すると、タスク実行部は、タスクがペアとなるタスクを必要とするか否かを判定する（ステップＳ３７のＹ、Ｓ３８）。ここで、「ペアとなるタスク」を必要とするタスクの一例としては、図２のステップＳ１９及び図３に示す結合タスクが挙げられる。結合タスクは、タスクの実行にあたって、結合相手となる結合タスクを必要とするものである。

一方、ロックに失敗すると、タスク実行部は、他のタスク実行部が既に当該タスクをロックしていると認識し、所定時間の間スリープモードに移行する（ステップＳ３７のＮ、Ｓ３６）。

ステップＳ３８において、タスクがペアとなるタスクを必要とするか否かを判定するにあたって、タスク実行部は、タスクに含まれる識別情報（例えば、［タスクＩＤ、ステージ番号、シリアル番号］）を参照する。そして、ペアとなるタスクが必要であると判断した場合、タスク実行部は、そのタスクを探索し、ロックする（ステップＳ３８のＹ，ステップＳ３９）。ステップＳ３９において、ペアとなるタスクのロックに成功した場合、タスク実行部はタスクを実行する（ステップＳ４０）。

一方、ステップＳ３８において、ペアとなるタスクが不要であると判断した場合、タスク実行部は、タスクを実行する（ステップＳ４０）。そして、タスクが完了すると、タスク生成部は次に行われるべきタスクを生成する（ステップS４１のＹ、Ｓ４２）。例えば、ペアとなるタスクが不要であるタスクの一例である分離タスクを完了した後には、タスク生成部は、後続するデコードタスクを生成する。このようにして、タスク生成部は、タスク間の順序依存性を担保する。

そして、タスクが完了すると、タスク実行部はタスクリストを更新してタスクの状態を「完了」に変更する（ステップＳ４３）。一方、選択したタスクの処理中にエラーが発生した場合には、タスク実行部はタスクの状態を「失敗」に変更する（ステップＳ４１のＮ、Ｓ４３）。エラー原因としては、取り込みファイルについてのＵＲＩが不正であること、ストレージからソースファイルを取り込めないこと、システム内のいずれのノードも対応していないエンコーディングパラメータがトランスコーディングジョブに含まれていること、等が挙げられる。

このように、本実施の形態に係る分散トランスコーディングシステムによれば、システムを構成する各ノードのタスク生成部において順次タスクを生成することにより、タスク間の順序依存性が担保される。このため、分散トランスコーディングシステムを構成するにあたってスケジューラが不要となり、シングルポイント障害及びシステム拡張の際のボトルネック問題を解消することができる。これにより、インターネットビデオのトランスコーディングのための所要時間を大幅に短縮することができる。また、分散トランスコーディングシステムを構成する全てのノードは、必要に応じてタスクリストを取得できるため、一つのノードが故障しても、当該ノードに代わって、他のノードがタスクを処理することが可能であり、システム全体として耐久性が高い。

以上、本発明の一実施の形態に係る分散トランスコーディングシステムについて説明したが、本発明は上記実施形態に制限されること無く、本発明の範囲内で自由に変更が可能である。

１ 分散トランスコーディングシステム
２ ネットワーク
３ データベースサーバ
４ データベース
５〜９ ノード
５ａ〜９ａ タスク実行部
５ｂ〜９ｂ タスク生成部
１０ ストレージ
１１ クライアント
１２ ジョブ提出部

Claims (5)

1. 複数のノードと、少なくとも一つのデータベースとを有する分散トランスコーディングシステムであって、
   前記複数のノードは、
   前記データベース上のトランスコーディングに関するタスクリストから取得したタスクを実行するタスク実行部と、
   前記タスク実行部が前記取得したタスクを実行した後に実行されるべき少なくとも一つのタスクを生成し、前記タスクリストを更新するタスク生成部と、を備える
   ことを特徴とする分散トランスコーディングシステム。
2. 前記タスク生成部は、前記タスク実行部が所定のタスクを実行した後に複数のタスクを生成する、ことを特徴とする請求項１に記載の分散トランスコーディングシステム。
3. 複数のノードと、少なくとも一つのデータベースとを用いる分散トランスコーディング方法において、
   前記複数のノードが、
   データベース上のトランスコーディングに関するタスクリストから取得したタスクを実行するステップと、
   前記取得したタスクを実行した後に実行されるべき少なくとも一つのタスクを生成し、前記タスクリストを更新するステップと、を含む
   ことを特徴とする分散トランスコーディング方法。
4. 前記複数のノードが、所定のタスクを実行した後に複数のタスクを生成する、ことを特徴とする請求項３に記載の分散トランスコーディング方法。
5. 少なくとも一つのデータベースを有する分散トランスコーディングシステムに含まれるノードであって、
   前記データベース上のトランスコーディングに関するタスクリストから取得したタスクを実行するタスク実行部と、
   前記タスク実行部が前記取得したタスクを実行した後に実行されるべき少なくとも一つのタスクを生成し、前記タスクリストを更新するタスク生成部と、を備える
   ことを特徴とするノード。

Images