ビデオ・データ・ストリーム評価方法及びシステム
【課題】複数の放送チャンネルを含むビデオ・データ・ストリームをほぼリアルタイムで評価する。
【解決手段】この評価方法では、まず、特定チャンネルについて少なくとも２つのビデオ・フレームを選択する。ビデオ・データ・ストリームから選択されたビデオ・フレームを抽出し、デコードする。デコードされたビデオ・フレームの１つを、デコードされた他のビデオ・フレーム又は前もって蓄積されたビデオ・フレームと比較し、この比較に基づいてビデオ・データ・ストリームの評価を生成する。
【解決手段】この評価方法では、まず、特定チャンネルについて少なくとも２つのビデオ・フレームを選択する。ビデオ・データ・ストリームから選択されたビデオ・フレームを抽出し、デコードする。デコードされたビデオ・フレームの１つを、デコードされた他のビデオ・フレーム又は前もって蓄積されたビデオ・フレームと比較し、この比較に基づいてビデオ・データ・ストリームの評価を生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビデオ・データ・ストリームの送信に関し、特に、複数の放送チャンネルを含むビデオ・データ・ストリームをモニタし、評価することに関する。
【背景技術】
【０００２】
ビデオ及び音声データの両方を伝送する技術は、従来の技術からどんどん変化している。例えば、テレビジョン放送施設では、同軸ケーブルを通したシリアル・デジタル・インターフェース（ＳＤＩ）や非同期シリアル・インターフェース（ＡＳＩ）などの伝統的な伝送形式よりも、イーサネット（登録商標）接続を通したインターネット・プロトコル（ＩＰ）伝送を用いて、放送データを伝送する方を現在では好んでいる。地上波放送、ケーブル・テレビ、衛星放送を介してビデオを送信するのに必要な帯域を減らすために、ビデオ圧縮技術が放送送信に関連して用いられる。
【０００３】
イーサネット／ＩＰプロトコルで運ばれる圧縮されたビデオは、通常、「ＩＰビデオ」と呼ばれ、個人宅への送信はもちろんのこと、プロフェッショナルの施設内においても、イーサネット／ＩＰトランスポートが含まれる。ＩＰビデオは、数百チャンネルのビデオ及び音声を多重形式で効率よく運ぶことができる。チャンネルは、標準画質（ＳＤ）及び高解像度画質（ＨＤ）コンテンツをミックスでき、複数のＳＤチャンネルと複数のＨＤチャンネルについて、並行して異なるフォーマットで送信される。典型的なＩＰビデオ・ストリームは、例えば、地域のサブ・ステーションへ接続する幹線では毎秒１０ギガ・ビット（Ｇｂｐｓ）の接続で運ばれ、また、例えば、地域サブ・ステーションから個人宅へは１Ｇｂｐｓイーサネット物理リンクで運ばれる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−２５１６５０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ビデオ放送業界が直面する重大な問題は、典型的には１つの放送プロバイダで放送される数百チャンネルのビデオ及び音声の送信品質を効率よく且つ効果的にモニタ（監視）できないことである。ビデオ放送プロバイダは、顧客の視聴状況に大きな影響を与える送信上の問題に、かなり時間が経つまで気づかないことが多々ある。顧客は、瞬間的な「グリッチ」が時々ある分には多くの場合良しとしても、ブラック・ビデオ（放送停止：black video）、フリーズ・ビデオ（映像が固まる：frozen video）、又はブロック・ノイズ・ビデオ（blocky video）の出現のようなビデオ送信に関する頻繁又は長時間の問題については多くの顧客が耐えられない。
【０００６】
ブラック・ビデオ（black video）、フリーズ・ビデオ（frozen video）、ブロック・ノイズ・ビデオ（blocky video）などのビデオ送信問題でいらいらした顧客は、他のビデオ・プロバイダに単にスイッチを着換えるだけで、簡単に元顧客になってしまう。また、顧客が結局のところ他のプロバイダに切り替えるとしても、顧客からのサービス・コール（電話）は、顧客サポート及び技術的サポート・リソースの観点から、非常にコストのかかるものとなってしまう。顧客からの電話によって、現場の技術者を顧客の敷地に派遣する必要が生じるので、これはプロバイダにとっては特にコストのかかるものとなってしまう。
【０００７】
このように、数百の多重ビデオ及び音声チャンネルについてベースバンド測定を実施できる能力は、発展段階にあるＩＰビデオ監視領域においてキーとなる問題である。現在のシステムは、典型的には、ベースバンドについて特にチェックすることなく、エラー情報についてトランスポート層を監視するものである。例えば、旧来の製品では、トランスポート層は詳細に監視するとしても、デコードされたベースバンド・ビデオについては、あったとしてもほんの少し監視するだけである。送信問題は、トランスポート層及び伸張されたベースバンド・ビデオの両方に跨がって起こりえるし、頻繁に起こるのであるから、こうしたシステムは、特にＩＰビデオには不十分である。もっと最近の製品では、デコードされたベースバンド・ビデオの測定を実施しようとするものもあるが、これらは伸張されたベースバンド・データのチャンネルが２〜３チャンネルを超えると監視できず、まして、数百の多重チャンネルを並行してなど無理である。
【課題を解決するための手段】
【０００８】
開示技術による実施形態では、数百チャンネルのインターネット・プロトコル（ＩＰ）ビデオについて、特に、１Ｇｂｐｓイーサネット・リンクのフル・ライン・レートについて、いくつかのデコードされたベースバンドをほぼリアル・タイムで測定できる。ある実施形態では、高速ＩＰビデオ・ストリームで運ばれる数百チャンネルのＩＰビデオまで、高速モニタリング及び詳細モニタリングの両方をサポートでき、これによって、測定についてタイムリーで価値ある品質の体験（QoE：quality of experience）を提供する共に、顧客に提供するビデオ品質に関して警報を出す能力を放送ビデオ・プロバイダに提供できる。
【０００９】
本願の第１観点は、マシン制御によるビデオ・データ・ストリーム評価方法であって、複数のビデオ・フレームを夫々含むチャンネルが、夫々複数含まれるビデオ・データ・ストリームをビデオ・データ・ソースから受けるステップと、複数の上記チャンネルの内の１つの特定チャンネルに対応する複数の上記ビデオ・フレームから少なくとも２つのビデオ・フレームを選択するステップと、上記ビデオ・データ・ストリームから選択された上記ビデオ・フレームを抽出するステップと、抽出された上記ビデオ・フレームを夫々デコードするステップと、デコードされた上記ビデオ・フレームの少なくとも１つを、デコードされた他の上記ビデオ・フレーム又は前もって蓄積されたビデオ・フレームの少なくとも１つと比較するステップと、上記比較ステップにおける比較結果に少なくとも一部は基づいて上記ビデオ・データ・ストリームの評価を生成するステップとを具えている。
【００１０】
本願の第２観点は、第１観点の方法において、上記ビデオ・データ・ストリームが、インターネット・プロトコル（ＩＰ）ビデオ、衛星放送ビデオ、ケーブル・ビデオ、地上波伝播ビデオのうちの１つであることを特徴としている。
【００１１】
本願の第３観点の発明は、第１観点の方法の上記選択ステップにおいて、複数の上記チャンネル内の１つに対応する少なくとも２つの独立ビデオ・フレーム（Ｉフレーム）を選択することを特徴としている。
【００１２】
本願の第４観点は、第１観点の方法の上記選択ステップにおいて、少なくとも１つの独立ビデオ・フレーム（Ｉビデオ・フレーム）と、少なくとも１つのバイ・ディレクショナル・ビデオ・フレーム（Ｂビデオ・フレーム）又はプリディクティブ（予測：predictive）ビデオ・フレーム（Ｐビデオ・フレーム）とを選択することを特徴としており、これらビデオ・フレームはいずれも複数の上記チャンネル内の上記特定チャンネルに対応している。
【００１３】
本願の第５観点は、第１観点の方法において、複数の上記チャンネルの内の上記特定チャンネル以外の１チャンネルに対応する複数のビデオ・フレーム中の少なくとも２つのビデオ・フレームについて、上述の選択、抽出、デコード、比較及び評価作成のステップを更に実行することを特徴としている。
【００１４】
本願の第６観点は、第５観点の方法において、上記複数チャンネルの個数以下の個数のチャンネルからなる優先順位リストに少なくとも一部分は基づいて、複数の上記チャンネルから上記特定チャンネル以外の上記１チャンネルを選択するステップを更に具えていることを特徴としている。
【００１５】
本願の第７観点は、第１観点の方法において、更に、上記特定チャンネル以外の複数の上記チャンネルの夫々に対応する複数のビデオ・フレームの少なくとも２つのビデオ・フレームについて、上述の選択、抽出、デコード、比較及び評価作成のステップを実行するのに続いて、複数の上記チャンネル中の上記特定チャンネルについて、上記選択、抽出、デコード、比較及び評価作成のステップを繰り返すことを特徴としている。
【００１６】
本願の第８観点は、第１観点の方法における抽出ステップが、選択されたビデオ・フレーム夫々に対応する情報を含む合成データ・ストリームを生成するステップと、上記合成データ・ストリームをフォーマットするステップと、上記合成データ・ストリームに、選択されたビデオ・フレーム夫々に対応するビデオ・フレーム特定情報を付加するステップとを有することを特徴としており、このとき、ビデオ・フレーム特定情報は、チャンネル情報、タイミング情報及びメタデータの少なくとも１つを含んでいる。
【００１７】
本願の第９観点は、第１観点の方法におけるデコード・ステップが、抽出したビデオ・フレームを受けるデコーダを用意するステップと、抽出したビデオ・フレームが上記デコーダを通過するステップと、デコーダからの出力データをキャプチャするステップとを有しており、このとき、第１観点の方法が、デコード中のエラーに応じてエラー・メッセージを制御ブロックに送るステップを更に具えていることを特徴としている。
【００１８】
本願の第１０観点は、第１観点の方法において、最初のデコード・ステップに続く評価生成ステップにおいて、デコーダをリセットするステップを更に有している。
【００１９】
本願の第１１観点は、第１観点の方法において、上記比較ステップが、デコードしたビデオ・フレームに実質的にブラック・ビデオが現れているか、又は、実質的にフリーズ・ビデオが現れているかもしれないとの判断に応じて、警告（アラート）を生成するステップを有していることを特徴としている。
【００２０】
本願の第１２観点は、第１１観点の方法において、警告が生成された時に、上記ビデオ・データ・ストリーム中の特定数の更なるビデオ・フレームについて、上記選択、抽出、デコード、比較及び評価作成のステップを繰り返すことによって、ビデオ・フレームの第２の評価を生成することを特徴としている。
【００２１】
本願の第１３観点は、第１観点の方法において、上記比較ステップが、デコードされたビデオ・フレームにブロック・ノイズが現れているかもしれないとの判断に応じて、警告を発生するステップを有していることを特徴としている。
【００２２】
本願の第１４観点は、第１３観点の方法において、警告が生成された時に、上記ビデオ・データ・ストリーム中の特定数の更なるビデオ・フレームについて、上記選択、抽出、デコード、比較及び評価作成のステップを繰り返すことによって、ビデオ・フレームの第２の評価を生成することを特徴としている。
【００２３】
本願の第１５観点は、第１観点の方法において、選択されたビデオ・フレームを蓄積するステップを更に具えることを特徴としている。
【００２４】
本願の第１６観点は、マシンで実行された時に、第１観点によるビデオ・データ・ストリームの評価方法をマシンで実行するためのマシンで実行可能な命令を記録しており、有形でマシンで読み込み可能な１つ以上のメディアである。
【００２５】
本願の第１７観点は、ビデオ・データ・ストリーム評価システムであって、
入力されるビデオ・データ・ストリームを受けるように動作するビデオ・データ・レシーバと、
入力される上記ビデオ・データ・ストリーム内の１つの特定チャンネルに対応する少なくとも２つのビデオ・フレームを選択するよう動作するビデオ・データ選択モジュールと、
上記ビデオ・データ・ストリームから選択された上記ビデオ・フレームを抽出するよう動作するビデオ・データ抽出モジュールと、
上記ビデオ・データ・ストリームから選択され、抽出された上記ビデオ・フレームをデコードするよう動作するビデオ・データ・デコーダと、
デコードされた上記ビデオ・フレームの夫々を少なくとも１つの基準ビデオ・フレームに対して比較するよう動作するビデオ・データ比較モジュールと、
上記ビデオ・データ比較モジュールから受けた出力情報に少なくとも一部は基づいて上記特定チャンネルについてのレポートを生成するよう動作するビデオ・データ評価モジュールと
を具えている。
【００２６】
本願の第１８観点は、第１７観点のビデオ・データ・ストリーム評価システムにおいて、少なくとも１つの上記基準ビデオ・フレームが、デコードされたビデオ・フレームの別のものか、前もって蓄積されたビデオ・フレームを含むか、又は、デコードされたビデオ・フレーム又は前もって蓄積されたビデオ・フレームを含んでいることを特徴としている。
【００２７】
本願の第１９観点は、第１７観点のビデオ・データ・ストリーム評価システムが、選択されたビデオ・フレームを蓄積し、蓄積されたビデオ・フレームをビデオ・データ比較モジュールで続いて行われる比較ステップのために供給するよう動作する蓄積モジュールを更に具えることを特徴としている。
【００２８】
本願の第１９観点は、第１７観点のビデオ・データ・ストリーム評価システムにおいて、上記ビデオ・データ評価モジュールが、指定した受け手に上記特定チャンネルについてのレポートを送るように動作することを特徴としている。
【図面の簡単な説明】
【００２９】
【図１】図１は、異なる種類のビデオ・フレームを有するエレメンタリ・ストリームの例を示したブロック図である。
【図２】図２は、用途を変えるために第１の解像度から第２の低解像度へとビデオを変更する例を示したブロック図である。
【図３】図３は、開示技術の実施形態に沿ったビデオ・データ・ストリーム評価システムの例を示したブロック図である。
【図４】図４は、開示技術の実施形態に沿ったビデオ・フレーム下処理モジュールの例を示したブロック図である。
【図５】図５は、開示技術の実施形態に沿ったマルチ・チャンネル用ビデオ・データ・ストリーム評価システムの例を示したブロック図である。
【図６】図６は、開示技術の実施形態に沿った高速スキャン及び詳細スキャン評価モジュールを有するビデオ・データ・ストリーム評価システムの例を示したブロック図である。
【図７】図７は、開示技術の実施形態に沿ったマシン制御によるビデオ・データ・ストリーム評価方法の例を示したフローチャートである。
【図８】図８は、開示技術の実施形態に沿ったマシン制御によるビデオ・データ・ストリーム評価方法の別の例を示したフローチャートである。
【発明を実施するための形態】
【００３０】
図１は、エレメンタリ・ビデオ・データ・ストリーム（ＥＳストリーム）１００を描いたブロック図である。この例では、ＥＳストリーム１００は、インディペンデント（独立：independent）フレーム（Ｉフレーム）１０２ａ及び１０２ｄ、プリディクティブ（予測：predictive）フレーム（Ｐフレーム）１０２ｂ、バイ・ディレクショナル（双方向：bi-directional）フレーム（Ｂフレーム）１０２ｃの４つの個別のフレームを有している。Ｉフレーム１０２ａ及び１０２ｄは、静止画像のように、基本的に各自で全体を描画可能な画像である。Ｐフレーム１０２ｂ及びＢフレーム１０２ｃは、それぞれ対応する画像情報の一部分のみを保持しているので、Ｉフレーム１０２ａ及び１０２ｄに比べて必要な記憶容量が小さくてすむ。
【００３１】
Ｐフレーム１０２ｂは、現在のフレームと前のフレーム（つまり、最初のＩフレーム１０２ａ）間の変化だけを記憶しており、これがＰフレームが一般に「デルタ・フレーム」とも呼ばれる理由である。例えば、もしＩフレーム１０２ａ及びＰフレーム１０２ｂ間の画像の変化が、画像の前景で動いているキャラクターだけであるなら、変化しない画像の背景の画素はＰフレーム１０２ｂ中には記憶されない。Ｂフレーム１０２ｃは、前のフレーム（つまり、Ｐフレーム１０２ｂ）及び後のフレーム（つまり、Ｉフレーム１０２ｄ）の両方と、現在のフレームとの差を用いて表示されるコンテンツを特定することで、更に記憶容量を節約する。
【００３２】
パケット化エレメンタリ・ストリーム（ＰＥＳ）は、典型的には、複数のＰＥＳパケットを含み、それぞれが図１のＥＳ１００のようなＥＳ内のビデオ・データから構成される。ＰＥＳパケットは、通常、固定サイズのトランスポート・ストリーム（ＴＳ）パケットに分割される。トランスポート・ストリームは、一般に複数の１８８バイトのＴＳパケットを含み、これらは一度に容易に多重化でき、ＩＰビデオ・ストリームの一部として代表的な放送伝送技術を用いて送信される。
【００３３】
図２は、高解像度（ＨＤ）ビデオ・データ２０２の標準解像度（ＳＤ）ビデオ・データ２０４へのデータ減少処理２００を描いたブロック図である。例えば、ＨＤビデオ・データ２０２は、１０８０ｉの解像度を持っており、これをＳＤビデオ・データ２０４用に転用する、つまり、６４０×４８０の解像度に減少させるとしても良い。また、ある状況においては、ＳＤビデオ・データ２０４をポータブル・ビデオ・データ２０６へと減少させ、例えば、ハンドヘルド・コンピュータや携帯電話でこれを表示可能にする必要があるかもしれない。転用する際の共通の課題は、各デ―タ減少段階において、ビデオ・データの画質が劣化する可能性があることである。例えば、ある解像度から第２の低解像度へと画像を減少させると、その低解像度で画像を表示させるデバイスでは画像がソフトでぼんやりとすることがある。
【００３４】
ビデオ・データ・ストリームについては、各層独自のエラーが生じる可能性があるので、各層についてエラーを監視する必要がある。また、１つの層（例えば、１つのＩＰパケット）における問題は、他の層（例えば、対応するＴＳパケット）におけるエラーにつながることが多々ある。実際、１つのビデオ・フレームが壊れていることが原因の１つのエラーは、多数のビデオ・フレームに伝播する。もし結合装置が悪い結合点を捕捉（選択）するようなら、例えば、そのデータ・ストリームを壊すために、１ビットだけオフにする必要がある。現在のシステムのなかには、エラー補正機能を内蔵するものもあるが、それらは非常に限られている。例えば、現在のシステムの中には、与えられたトランスポート・ストリーム又はパケット化エレメンタリ・ストリーム（ＰＥＳ）の限定的な評価をサポートするものもある。
【００３５】
問題が複雑なのは、Ｈ.２６４のような新しい規格は、より多くの処理能力を必要とする傾向があり、数百チャンネルはもちろん、１チャンネルの評価でさえ、プロセッサの能力がすぐに不足することである。実際、高性能のパソコンでも、複雑なために、２、３個のＨ.２６４ビデオ・ストリームしか処理できない。ハードウェア・デコーダでも、典型的には、多くても４個のＨ.２６４ビデオ・ストリームしか処理できず、その場合も、時間をかけてこれらを切り替えて処理するだけである。これは、非常に能力の高いハードウェアを用いても、全てのデータをデコードするには、非常に多くの処理リソースを必要とするためである。
【００３６】
ブラック・フレーム、フリーズ・フレームやブロック・ノイズ（Blockiness）の検出と言ったデコードされたベースバンドの重大な局面を、リアルタイムで測定することが好ましい。ブラック・フレームとは、一般に表示映像が実質的又は完全に黒のままで動かなくなってしまうことを指す。フリーズ・フレームとは、一般に表示映像が１つのフレームのままで動かなくなって、そのフレームを基本的には繰り返してしまう状況を指す。ブロック・ノイズ（Blockiness）は、一般にブロック形状又は矩形のエッジを有する視覚的な歪み（artifact）が現れることを指す。当業者であれば、こうした振る舞いが現れている表示映像にノイズが含まれることを理解しているであろう。例えば、ブラック・フレームは、視聴者は表示映像が黒のままで止まっているというかもしれないが、実際にはそこにある程度のノイズがあって、データが実際的には完全には均一ではない。
【００３７】
図３は、ビデオ・データ・ストリーム評価システム３００の例のブロック図である。ビデオ・ソース（映像源）３０２が、ビデオ・データ・ストリーム評価システム３００にビデオ・データ・ストリームを供給する。ビデオ・データ・ストリームは、多数の別々の放送チャンネルを含んでいるとしても良い。この例では、ビデオ・データ・ストリーム評価システム３００は、ビデオ・フレーム下処理モジュール３０４を有し、これはビデオ・ソース３０２からビデオ・データ・ストリームを受けて、例えば、図４に示す例に関して以下で説明するビデオ・フレームのフォーマットなどの下処理（前処理）ができる。実施形態によっては、ビデオ・フレーム下処理モジュール３０４は、図５に示す例に関して詳細に説明するように、ＨＤデータとＳＤデータなどのビデオ・データ形式毎に、ビデオ・データをグループ化しても良い。
【００３８】
１つ又は複数のチャンネルからのビデオ・データを適切にフォーマットし、オプションで他チャンネルの同じ変形をしたデータとまとめられたビデオ・データの１セット（組）が用意できると、ビデオ・フレーム下処理モジュール３０４は、例えば、ビデオ・データをデコーダのキュー（queue：処理待ちの列）の先頭に配置できるが、これは、結果としてビデオ・データをデコーダのリソース、例えば、ビデオ・フレーム・デコード・モジュール３０６に送ることができるということになる。ビデオ・フレーム・デコード・モジュール３０６は、ビデオ・フレーム下処理モジュール３０４から受けたビデオ・フレームをデコードし、デコードしたビデオ・フレームをビデオ・フレーム評価モジュール３０８に送る。
【００３９】
もし期待した数の適切にデコードされたビデオ・フレームがビデオ・フレーム・デコード・モジュール３０６から現れなければ、どういう対応をするか判断するために、例えば、エラーを制御ブロックに送るようにしても良い。こうした状況は、ビデオ・データ中に実際にエラー（これは他の処理でもっと詳細に評価する必要がある）があるのが原因ということもあり得るが、そうした状況は、また、例えば、ビデオ・フレーム・デコード・モジュール３０６を充分にプリセットする時間がない又はデータを設定していない、といったデコーダに関する問題によっても引き起こされることがある。こうしたシナリオにおいては、ビデオ・フレーム・デコード・モジュール３０６は、リトライ（再挑戦）しても良く、次のサイクルでもっとビデオ・データを送るように要求するか、又は、特定のユーザに注意を促すようにしても良い。
【００４０】
ビデオ・フレーム・デコード・モジュール３０６からデコードされたビデオ・フレームを受けると、ビデオ・フレーム評価モジュール３０８は、ビデオ・フレーム・デコード・モジュール３０６から受けたデコードされたビデオ・フレームに基いて、チャンネルを特定した評価を実施する。例えば、ビデオ・フレーム評価モジュール３０８は、ビデオ（映像）が、ブラック、フリーズ又はブロック・ノイズが現れるなどのような、何らかの望ましくない特性を示しているかどうかを判断できる。
【００４１】
ある実施形態においては、ビデオ・フレーム評価モジュール３０８は、例えば、一般に使用されている多数のビデオ・フレーム比較アルゴリズムのいくつかを用いて、デコードされた複数のビデオ・フレームを、１つずつ個別に、そして互いに比較することによる測定によって、比較することで、複数のビデオ・フレームを評価する。ビデオ・フレーム評価モジュール３０８は、オプションで、将来あり得る評価のため、例えば、比較のために、各チャンネルにつき、少なくとも１つ前のサイクルの複数のビデオ・フレームのコピーを保存しておいても良い。
【００４２】
ある実施形態においては、フリーズ・フレームについて、誤りを示すレートを効果的に減少させるために、例えば、同じチャンネルからの複数のビデオ・フレーム間に分離時間を設けるようにしても良い。もしそれらビデオ・フレームが、数秒の広がりにおいてほぼ同一であるなら、ノイズを除いて、隣接するフレームがほぼ類似しているというよりは、ビデオが本当にフリーズしている可能性がかなり高い。これは、隣接するフレームは通常高い相関があるからである。従って、ブラック又はフリーズ画像を効果的に検出するには、少なくとも２つのフレームを比較するビデオ・フレーム評価モジュール３０８が必要である。また、装置のエラーは、Ｉフレーム又はＩＤＲフレームを単に見ているだけでは見逃す可能性があるので、ビデオ・フレーム評価モジュール３０８は、一般には、Ｉフレームに加えて、Ｐフレーム又はＢフレームを注意して観察する。
【００４３】
実施形態によっては、ビデオ・フレーム評価モジュール３０８が１つ又は複数のレポート３１２を発生でき、これは連続的、特定時点、又はある条件への合致に応答して送られる。例えば、ビデオ・フレーム評価モジュール３０８は、ビデオが特定の特性を示したときだけレポート３１２を送るように設定できる。レポート３１２には、警告（アラート）又はトリガ警告（図示せず）を含んでも良い。例えば、もしあるチャンネルが現在フリーズしているなら、ビデオ・フレーム評価モジュール３０８は、ローカルの技術サポート・チームへの警告（アラート）を含むレポート３１２又は警告としてのレポート３１２を発することができ、これによって、問題解決を直ちに開始できる。レポート３１２には、どのチャンネルが不調か、どのような症状が現在そのチャンネルで現れているか、どれくらい長くその症状が現れているか、というような種々の形式の情報を含めても良い。
【００４４】
デコードされたビデオ・フレームの評価の一部として、ビデオ・フレーム評価モジュール３０８は、内部又は遠隔データベースのようなフレーム収納庫３１０から、予め蓄積したビデオ・フレームを取り出すことができる。例えば、ビデオ・フレーム評価モジュール３０８は、最も最近の前のビデオ・フレームのような多数の先のビデオ・フレームのいずれかと、現在のいくつかのビデオ・フレームとを比較できる。また、ビデオ・フレーム評価モジュール３０８は、今評価したビデオ・フレームをフレーム収納庫３１０に蓄積できるので、後に続く評価において、ビデオ・フレーム評価モジュール３０８はそれらを利用できる。
【００４５】
開示した技術におけるある実施形態では、費用対効果が高く、ほぼリアルタイムの測定を、ＩＰビデオ・ストリーム中の数百のビデオについて行うことができる。例えば、５００チャンネルを有するＩＰビデオ・ストリームの場合を考えてみよう。２つの６０フレーム毎秒ハードウェア・デコーダを含む実施形態では、平均して１チャンネル当たり３フレーム倍でデコードされると仮定すれば、５００チャンネル全てを通しての１サイクルを１２秒で完了できる。
【００４６】
当業者であれば、ビデオ・データ・ストリーム評価システム３００は、多数の異なるやり方で実施可能なことを理解できるであろう。例えば、ビデオ・データ・ストリーム評価システム３００の個々の構成要素は、ハードウェア要素、ソフトウェア要素、又はこれらの組合せた要素で実現可能である。ハードウェア要素を含む実施形態では、構成要素を互いに別個なもの、１つのハードウェア要素の部分、又は、これらの組合せとしても良い。
【００４７】
当業者であれば、開示技術には、ビデオ・データ・ストリーム評価システムに加えて（又はこれに代わる）、音声データ・ストリーム評価システムが含まれることを理解できるであろう。実施形態によっては、図３のビデオ・データ・ストリーム評価システム３００のような１つのデータ・ストリーム評価システムが、多数の放送チャンネルの夫々に対応する音声データとビデオ・データの両方を扱うように構成できる。
【００４８】
図４は、図３のビデオ・フレーム下処理モジュール３０４の詳細な例を示すブロック図である。この例では、ビデオ・フレーム下処理モジュール３０４が、ビデオ・フレーム選択モジュール４０２を含み、これは、ビデオ・ソース３０２から受け取ったビデオ・データ・ストリームからの１つの特定チャンネルについて、少なくとも２つのビデオ・フレームを選択する。ビデオ・フレーム選択モジュール４０２を使用して、入力されるビデオ・ストリーム通して読み、各チャンネルにつきデコード・リソースに最終的に送られる２つのビデオ・フレームだけを選択することによって、データを大幅に減少できる。ビデオ・ストリーム中のビデオ・オブジェクトを見つけるのに、全てをデコードする場合に比較して、大幅に少ない処理リソースで済む。
【００４９】
ビデオ・フレーム選択モジュール４０２は、１つのチャンネルにつき、２つのＩフレームを選択しても良い。これに代えて、ビデオ・フレーム選択モジュール４０２が、１つのＩフレームと、Ｐフレーム又はＢフレームの１つを選択しても良い。さらに別の実施形態では、ビデオ・フレーム選択モジュール４０２が、仮想的にＩフレーム、Ｐフレーム及びＢフレームの任意の組合せを選択しても良い。ある実施形態では、ビデオ・フレーム選択モジュール４０２は、１つのビデオ・ストリーム内で、２つ以上のビデオ・フレームを選択しても良い。
【００５０】
ビデオ・フレームが選択された時点で、ビデオ・フレーム選択モジュール４０２は、選択されたビデオ・フレームのＩＤをビデオ・フレーム抽出モジュール４０４を送るようにしても良く、これによってビデオ・データ・ストリームから選択されたビデオ・フレームが抽出される。当業者であれば、ビデオ・フレーム選択モジュール４０２及びビデオ・フレーム抽出モジュール４０４がまとめて実装されても良いし、更には１つの部品として実装されても良いことが理解されるであろう。ビデオ・フレーム抽出モジュール４０４が選択されたビデオ・フレームを抽出した時点で、選択されたビデオ・フレームをビデオ・フレーム・フォーマット・モジュール４０６に送る。
【００５１】
ビデオ・フレーム・フォーマット・モジュール４０６は、ビデオ・フレーム抽出モジュール４０４から受けた抽出ビデオ・フレームをフォーマットできる。例えば、選択されたフレームの位置が特定された時点で、ビデオ・フレーム・フォーマット・モジュール４０６は、データを処理待ち状態にし、ビデオ・フレーム・デコード・モジュール３０６での使用に適したフォーマットに設定する。実施形態によっては、ビデオ・フレーム・フォーマット・モジュール４０６が１つ以上の合成データ・ストリームを生成でき、それぞれは対応するビデオ・データをビデオ・フレーム・デコード・モジュール３０６でデコードするのに適したフォーマットにコピーする。ビデオ・フレーム・フォーマット・モジュール４０６は、デコード・タイムスタンプ（復号時刻情報）、プレゼンテーション・タイムスタンプ（提示時刻情報）及びメタデ―タのようなＭＰＥＧフォーマットの種々の細かい点を考慮でき、これらはビデオ・フレーム・デコード・モジュール３０６の適切な動作が確実になるように必要に応じて変形されても良い。
【００５２】
図５は、複数チャンネル形式を扱うように、図３のビデオ・データ・ストリーム評価システム ３００を変形した例を示すブロック図である。この例では、ビデオ・フレーム下処理モジュール３０４は、デコード処理を通して、データを送る前に同じ形式のビデオ・フレームをまとめて一緒に処理（バッチ処理）することで、デコーダのリセット時間及びセットアップ時間を減らすことができる。ある実施形態では、ビデオ・フレーム下処理モジュール３０４が、各ビデオ形式について、合成ストリームを生成できる。ここで使われているように、合成ストリームとは、新たに構成されたデータ・ストリームのことを一般に述べていて、これは対応する実際のビデオ・ストリームからコピーされたビデオ・データ（例えば、ある形式の全てのビデオ・データ）を含んでいる。
【００５３】
抽出されたビデオ・フレームの比較的小さなセットを、それを受け取るデコーダが期待するフォーマットに再フォーマットすることによって、システムはデコーダをリセットする必要を回避でき、結果として、一般的にこれに係るであろう処理時間のロスを避けることができる。ビデオ・フレームの異なる形式の数は、通常、少ない（例えば、５個の形式）ので、数個の合成チャンネルを使用することによって、数百チャンネルのビデオ・パイプライン処理を含む状況においてさえ、デコード・リソースで非常に効率的な処理が行える。
【００５４】
ビデオ・フレームがＳＤビデオ・チャンネルとＨＤビデオ・チャンネルが混じったものを含む状況においては、例えば、ビデオ・フレーム下処理モジュール３０４が複数のＳＤチャンネルを一度に処理（バッチ処理）して第１合成ストリームとし、第１合成ストリームをビデオ・フレーム・デコード・モジュール３０６に送ることができる。ビデオ・フレーム下処理モジュール３０４は、また、複数のＨＤチャンネルを一度に処理（バッチ処理）して第２合成ストリームとし、第２合成ストリームをもう１つのビデオ・フレーム・デコード・モジュール５０６に送ることができ、ビデオ・フレーム・デコード・モジュール５０６はストリームをデコードして、デコードしたフレームをもう１つのビデオ・フレーム評価モジュール５０８に渡し、これがＨＤデータに関するレポート５１０をオプションで生成するようにしても良い。
【００５５】
ＨＤチャンネルの変形版が複数ある状況においては、ビデオ・フレーム下処理モジュール３０４は、各変形版をバッチ処理できる。例えば、図５のビデオ・フレーム下処理モジュール３０４は、変形版をまとめてバッチ処理し、それを１つのストリームとして更に別のビデオ・フレーム・デコード・モジュール５１２に送る。モジュール５１２は、複数のビデオ・フレームをデコードし、それらを第３のビデオ・フレーム評価モジュール５１４に送る。モジュール５１４は、オプションでその変形版に関するレポート５１６を生成しても良い。
【００５６】
図５のビデオ・データ・ストリーム評価システム ３００では、ビデオ・フレーム・デコード・モジュール３０６、５０６及び５１２と、ビデオ・フレーム評価モジュール３０８、５０８及び５１４の夫々からなる別々の３セットで示している。しかし、当業者であれば、別の実施形態として、複数別々のデコード・リソース及び評価コンポーネントの代わりに、複数ストリームの複数グループを処理する１つのビデオ・フレーム・デコード・モジュール又は１つのビデオ・フレーム評価モジュールを含むものでも良いことが理解できるであろう。
【００５７】
図６は、図３のビデオ・データ・ストリーム評価システム３００の例を示すブロック図である。これには、高速スキャン・ビデオ評価モジュール６０２及び詳細（deep：ディープ）スキャン・ビデオ評価モジュール６０４がある。この例では、高速スキャン・ビデオ評価モジュール６０２は、ブラック、フリーズ又はブロック・ノイズが現れるといった特定のエラーについて、高速なスキャンを実行できる。ここで用いているように、高速スキャンとは、多数の異なるチャンネルの連続スキャンのことを言っていて、このとき、高速スキャン・ビデオ評価モジュール６０２は、次に評価するチャンネルに進む前に、１チャンネルにつき最小数のフレーム、例えば、２フレームを選択し、抽出し、評価する。
【００５８】
高速スキャン・ビデオ評価モジュール６０２は、全てのチャンネルに渡って高速スキャンを実行する。ただし、これは詳細さ（deep：深さ）に制限があり、１チャンネルにつき検査するデータ量に制約がある。このように、ある１つのチャンネルについてのベースバンドの限られたセットについて測定を実施し、そのチャンネルについての結果をレポートし、そして、次のチャンネルへと高速に、典型的にはリアルタイムに近いサイクルで進む。もし高速スキャン・ビデオ評価モジュール６０２がトリガとなり得るもの、例えば、ブラック・ビデオやフリーズ・ビデオの可能性のあるものを検出すると、ビデオ・データ・ストリーム評価システム ３００は、詳細スキャン・ビデオ評価モジュール６０４を起動し、より長い時間をかけてそのチャンネルを調べ、その疑わしい状態が本当に存在するのかを確認する。
【００５９】
ここで用いているように、詳細スキャン（deep scan）又は詳細探査（deep dive）とは、一般に、あるチャンネルのより長時間で、より詳細なビデオ分析のことを言っている。詳細スキャンは、高速スキャンでの疑惑のあるものを効率よく検討し、それらを確実性の高い結果へと変換する。例えば、高速スキャン・ビデオ評価モジュール６０２による高速スキャンによって、ある特定のチャンネルがフリーズして提示されているように見うけられる場合には、詳細スキャン・ビデオ評価モジュール６０４は、そのチャンネルが本当にフリーズしているか、そのチャンネルを数秒かけて詳細に観測し、信頼性の高い結果を得る。詳細スキャンが起動することのある別の状況としては、ある１つのチャンネルについてＧＯＰ（group of pictures：複数画面からなるグループ）の構成が変わった場合がある。こうした状況では、詳細スキャン・ビデオ評価モジュール６０４が、ＧＯＰの変化が原因でベースバンド・ビデオに問題が生じているか、そのチャンネルについて通常よりも多くの注意を払うようにできる。
【００６０】
ある実施形態では、評価対象チャンネルのリストによって、詳細スキャン・ビデオ評価モジュール６０４を駆動するようにもできる。このリストによって、複数チャンネルについての優先順位を示すことができる。例えば、このリストは、例えば、外部の自動ビデオ管理システムから、高速スキャン処理又はユ―ザ要求によって特定されたチャンネルについて、詳細分析の優先順位を高くするようにできる。このリストによって、詳細スキャン・ビデオ評価モジュール６０４に、ある特定チャンネルについて詳細スキャンを実施するようしたり、例えば、ペイ・パー・ビュー・チャンネルのような優先順位の高いチャンネルについて、より頻繁に詳細スキャンを実施するように管理できる。詳細スキャン・ビデオ評価モジュール６０４は、例えば、リストによって詳細スキャン処理をしないようになっているときも、全チャンネルについて詳細スキャンを連続して実施するようにも設定できる。
【００６１】
ある実施形態においては、観測するチャンネルのリストを設定するのに、スマート・アラーム処理及びエンジン・コントロールを用いても良い。スマート・アラーム処理及びエンジン・コントロールによって、システムが検知し、追跡すべき多数のビデオ特性を指定することもできる。ある実施形態においては、スマート・アラーム処理及びエンジン・コントロールは、例えば、図３のレポート３１２のような分析結果を受けて、その情報をどのように扱うかを判断できる。その情報に基づいて、スマート・アラーム処理及びエンジン・コントロールは、アラームを生成し、例えば、特定のユーザ又はネットワーク管理システムにアラームを送信するかどうかを決定できる。
【００６２】
図７は、マシン制御によるビデオ・データ・ストリーム評価方法７００の例を示したフローチャートである。ステップ７０２では、入力されるビデオ・データ・ストリーム内のある１つの特定チャンネルについて、２以上のビデオ・フレームが選択される。ある実施形態においては、システムがＩフレーム又はＩＤＲフレームの最初から開始しても良い。そのチャンネルについて２つ以上のフレームが選択された時点で、それらはステップ７０４に示されるようにビデオ・データ・ストリームから抽出できる。ある実施形態においては、抽出とは、選択されたビデオ・フレームに対応するビデオ・データを新しく生成した合成ストリームにコピーすることを述べている。
【００６３】
ステップ７０６では、抽出ビデオ・フレームがデコード・リソースに送られる前にフォーマットされる。次にフォーマットされたビデオ・フレームは、ステップ７０８に示されるようにデコードされる。デコード・リソースが既にいくらかのビデオ・フレームをデコードしている実施形態においては、デコード処理は、デコーダをリセットし、次のデータ・セットを受けるように準備することによって開始しても良い。デコーダの準備ができた時点で、ビデオ・データはデコーダを通して送信され、その出力がキャプチャされるようにできる。そして、得られたフレームには、評価リソースに送られる前に、チャンネル情報、タイミング情報、その他のメタデータ（デコーダ・フラグなど）といったタグが付与される。
【００６４】
ステップ７１０では、デコーダから受けたフォーマット済みビデオ・フレームが評価される。例えば、複数のビデオ・フレームは、ブラック・ビデオ、フリーズ・ビデオ、又は、ブロック・ノイズがあるかといった特定の望ましくない特性が評価対象のビデオ・フレームに現れているかどうか判定するのに、お互いを比較して、又は、前もって蓄積されたビデオ・フレームと比較して評価しても良い。ステップ７１２に示されるように、評価結果が生成され、更にオプションで、結果に基いて取り得るアクションに合わせて１つ又は複数の受け手に評価結果が送られる。例えば、放送ビデオ・プロバイダは、怒った顧客から電話を受ける前に、あるチャンネルについて検出されたブラック・ビデオ又はフリーズ・ビデオについて、先手先手で注意を払うように技術サポート担当者に勧告できる。
【００６５】
図８は、マシン制御によるビデオ・データ・ストリーム評価の別の例による方法８００を示したフローチャートである。ステップ８０２では、ある１つの特定チャンネルについて、ビデオ・データ・ストリームから２つ以上のビデオ・フレームが選択される。ステップ８０４では、選択されたビデオ・フレームが抽出され、フォーマットされ、デコード・リソースに送られて、デコード・リソースがステップ８０６に示すようにビデオ・フレームをデコードする。
【００６６】
ステップ８０８では、ステップ８０６でのデコード中に何らかのエラーが生じたかどうかに関して判断される。もしエラーが検出されると、ステップ８１０に示すように、エラー処理を起動しても良い。例えば、エラー・メッセージが指定の受け手に送られるようにしても良い。もしエラーが検出されないか、又はあるエラーが検出されたものの害がないと見なせるものか、現在の処理と関係のないものの場合には、ステップ８１２に示すようにビデオ・フレームが評価される。例えば、現在そのチャンネルに配信されているビデオがブラック、フリーズ又はブロック・ノイズであるかどうかを、システムが判断できる。ステップ８１２での評価は、チャンネルの高速スキャンを含むとしても良い。
【００６７】
ステップ８１４では、評価対象チャンネルについて詳細スキャンを実行するかに関して判断される。そのチャンネルの高速スキャンの結果、そのチャンネルにブラック・ビデオ又はフリーズ・ビデオが現れている可能性が検出されると、そのチャンネルに本当にその特定の特性が現れているかどうか確認するするため、システムは、そのチャンネルの詳細スキャンを起動できる。もし詳細スキャンを行うことになったら、処理はステップ８０２に戻る。もしブラック・ビデオ又はフリーズ・ビデオの可能性が確認されたら、システムは、そのチャンネルについてもっと多数のビデオ・フレームをもっと長時間観察し、信頼性の高い判断基準を得る。もし詳細スキャンをしないなら、ステップ８１６に示すように、現在のチャンネルの処理は停止できる。この時点で、方法８００は、次の被評価チャンネルに関して開始できる。
【００６８】
開示技術について示した実施形態は、おおよそＩＰビデオにフォーカスしたものであるが、当業者であれば、衛星、ケーブル又は地上波の伝播メディアにも応用可能であることが理解されるであろう。以下に、開示技術の実施形態を実現するのに適切したマシンの一般的な説明を行う。
【００６９】
以下の説明は、開示技術の実施形態を実現可能な適切なマシンについて、簡潔で一般的に記述しようと意図したものである。ここで用いているように、用語「マシン（マシン：機械）」とは、単一のマシンか、一緒に動作する複数のマシン又はデバイスが通信可能に結合したシステムを広く網羅している。典型的なマシンは、パソコン、ワークステーション、サーバ、ポータブル・コンピュータ、ハンドヘルド・デバイス、テブレット・デバイスなどのようなコンピューティング・デバイスを含んでも良い。
【００７０】
典型的には、マシンには、システム・バスがあり、これにプロセッサ、メモリ（例えば、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）その他のステート保持メディア）、ストレージ・デバイス、ビデオ・インタフェース、そして、入出力インタフェース・ポートが取り付けられる。マシンは、また、プログラマブル又はノン・プログラマブル・ロジック・デバイス又はアレー、ＡＳＩＣ（特定用途向けＩＣ）、エンベッデッド・コンピュータ、スマート・カードのようなエンベッデッド（embedded：埋め込み）コントローラを含んでも良い。マシンは、少なくとも一部は、他のマシンや、仮想現実環境を用いたインターアクション、バイオメトリック・フィードバック、その他の入力信号からの指示によってだけでなく、従来の入力デバイス（例えば、キーボード、マウスなど）からの入力によって制御されても良い。
【００７１】
マシンは、ネットワーク・インタフェース、モデムなどの通信手段を通して、１つ以上の遠隔マシンへの１つ以上の接続を利用しても良い。複数のマシンは、イントラネット、インターネット、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）などのような物理的又は論理的なネットワークによって、相互に接続されても良い。当業者であれば、ネットワーク通信は、無線周波数（ＲＦ）、衛星、マイクロウェーブ、ＩＥＥＥ５４５.１１、Bluetooth、光、赤外線、ケーブル、レーザを含む種々の有線又は無線の短距離又は長距離キャリア及びプロトコルを用いることができることを理解できるであろう。
【００７２】
開示技術の実施形態は、マシンでアクセスされたときに、マシンがタスクを実行したり、概要データ形式又は低レベル・ハードウェア・コンテキストを定義するという結果が得られる機能、処理手順、データ構造、アプリケーション・プログラム、命令などを含む関連データを参照したり、併せて考えることで説明できる。関連データは、例えば、揮発性又は不揮発性メモリ（例えば、ＲＡＭ及びＲＯＭ）や他のストレージ・デバイス及び関連するストレージ・メディアに記録できる。このストレージ・メディアには、ハードディスク・ドライブ、フレキシブル・ディスク・ドライブ、光ストレージ・メディア、フラッシュ・メモリ、メモリ・スティック、デジタル・ビデオ・ディスク、バイオロジカル・ストレージ、その他の有形の物理的ストレージ・メディアを含めることができる。
【００７３】
関連データは、物理的又は論理的ネットワークを含む伝送環境を通じて、パケット、シリアル・データ、パラレル・データ、伝播された信号などとして配信でき、圧縮又は暗号化されたフォーマットの形で利用できる。関連データは、分布された環境で利用でき、マシンがアクセスに関してローカルに又は遠隔に蓄積される。
【００７４】
本発明の原理は、図示した実施形態を参照しつつ、説明及び図示してきたが、図示した実施形態はそうした原理から逸脱することなく、配置や詳細を変形でき、また、望ましい形態に組み合わせることができることが理解できるであろう。そして、上述の説明は特定の複数の実施形態にフォーカスしたものであったが、他の構成も考えられる。特に、「本発明の実施形態によると」などの表現がここでは用いられているが、こうした言い回しは、一般的に参考として実現可能な実施形態であることを意味するもので、本発明が特定の実施形態の構成に限定されることを意味するものではない。ここで用いているように、これら用語は、参考までに同じ又は異なる実施形態であって、他の実施形態に組合せ可能なことを意味する。
【００７５】
結果として、ここに記載した実施形態は広く種々の変更が行えるという観点から、本願における詳細な説明及び付随する資料は、説明用に過ぎず、本発明の要旨を限定するものと考えるべきではない。本願発明には、以下の特許請求の範囲の記載とそれに等化なものに基づく要旨と思想の範囲に含まれる全ての変形が含まれる。
【符号の説明】
【００７６】
３００ ビデオ・データ・ストリーム評価システム
３０２ ビデオ・ソース
３０４ ビデオ・フレーム下処理モジュール
３０６ ビデオ・フレーム・デコード・モジュール
３０８ ビデオ・フレーム評価モジュール
３１０ フレーム収納庫
３１２ レポート
４０２ ビデオ・フレーム選択モジュール
４０４ ビデオ・フレーム抽出モジュール
４０６ ビデオ・フレーム・フォーマット・モジュール
５０６ ビデオ・フレーム・デコード・モジュール
５０８ ビデオ・フレーム評価モジュール
５１０ レポート
５１２ ビデオ・フレーム・デコード・モジュール
５１４ ビデオ・フレーム評価モジュール
５１６ レポート
６０２ 高速スキャン・ビデオ評価モジュール
６０４ 詳細スキャン・ビデオ評価モジュール
６０６ レポート
６０８ レポート
【技術分野】
【０００１】
本発明は、ビデオ・データ・ストリームの送信に関し、特に、複数の放送チャンネルを含むビデオ・データ・ストリームをモニタし、評価することに関する。
【背景技術】
【０００２】
ビデオ及び音声データの両方を伝送する技術は、従来の技術からどんどん変化している。例えば、テレビジョン放送施設では、同軸ケーブルを通したシリアル・デジタル・インターフェース（ＳＤＩ）や非同期シリアル・インターフェース（ＡＳＩ）などの伝統的な伝送形式よりも、イーサネット（登録商標）接続を通したインターネット・プロトコル（ＩＰ）伝送を用いて、放送データを伝送する方を現在では好んでいる。地上波放送、ケーブル・テレビ、衛星放送を介してビデオを送信するのに必要な帯域を減らすために、ビデオ圧縮技術が放送送信に関連して用いられる。
【０００３】
イーサネット／ＩＰプロトコルで運ばれる圧縮されたビデオは、通常、「ＩＰビデオ」と呼ばれ、個人宅への送信はもちろんのこと、プロフェッショナルの施設内においても、イーサネット／ＩＰトランスポートが含まれる。ＩＰビデオは、数百チャンネルのビデオ及び音声を多重形式で効率よく運ぶことができる。チャンネルは、標準画質（ＳＤ）及び高解像度画質（ＨＤ）コンテンツをミックスでき、複数のＳＤチャンネルと複数のＨＤチャンネルについて、並行して異なるフォーマットで送信される。典型的なＩＰビデオ・ストリームは、例えば、地域のサブ・ステーションへ接続する幹線では毎秒１０ギガ・ビット（Ｇｂｐｓ）の接続で運ばれ、また、例えば、地域サブ・ステーションから個人宅へは１Ｇｂｐｓイーサネット物理リンクで運ばれる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−２５１６５０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ビデオ放送業界が直面する重大な問題は、典型的には１つの放送プロバイダで放送される数百チャンネルのビデオ及び音声の送信品質を効率よく且つ効果的にモニタ（監視）できないことである。ビデオ放送プロバイダは、顧客の視聴状況に大きな影響を与える送信上の問題に、かなり時間が経つまで気づかないことが多々ある。顧客は、瞬間的な「グリッチ」が時々ある分には多くの場合良しとしても、ブラック・ビデオ（放送停止：black video）、フリーズ・ビデオ（映像が固まる：frozen video）、又はブロック・ノイズ・ビデオ（blocky video）の出現のようなビデオ送信に関する頻繁又は長時間の問題については多くの顧客が耐えられない。
【０００６】
ブラック・ビデオ（black video）、フリーズ・ビデオ（frozen video）、ブロック・ノイズ・ビデオ（blocky video）などのビデオ送信問題でいらいらした顧客は、他のビデオ・プロバイダに単にスイッチを着換えるだけで、簡単に元顧客になってしまう。また、顧客が結局のところ他のプロバイダに切り替えるとしても、顧客からのサービス・コール（電話）は、顧客サポート及び技術的サポート・リソースの観点から、非常にコストのかかるものとなってしまう。顧客からの電話によって、現場の技術者を顧客の敷地に派遣する必要が生じるので、これはプロバイダにとっては特にコストのかかるものとなってしまう。
【０００７】
このように、数百の多重ビデオ及び音声チャンネルについてベースバンド測定を実施できる能力は、発展段階にあるＩＰビデオ監視領域においてキーとなる問題である。現在のシステムは、典型的には、ベースバンドについて特にチェックすることなく、エラー情報についてトランスポート層を監視するものである。例えば、旧来の製品では、トランスポート層は詳細に監視するとしても、デコードされたベースバンド・ビデオについては、あったとしてもほんの少し監視するだけである。送信問題は、トランスポート層及び伸張されたベースバンド・ビデオの両方に跨がって起こりえるし、頻繁に起こるのであるから、こうしたシステムは、特にＩＰビデオには不十分である。もっと最近の製品では、デコードされたベースバンド・ビデオの測定を実施しようとするものもあるが、これらは伸張されたベースバンド・データのチャンネルが２〜３チャンネルを超えると監視できず、まして、数百の多重チャンネルを並行してなど無理である。
【課題を解決するための手段】
【０００８】
開示技術による実施形態では、数百チャンネルのインターネット・プロトコル（ＩＰ）ビデオについて、特に、１Ｇｂｐｓイーサネット・リンクのフル・ライン・レートについて、いくつかのデコードされたベースバンドをほぼリアル・タイムで測定できる。ある実施形態では、高速ＩＰビデオ・ストリームで運ばれる数百チャンネルのＩＰビデオまで、高速モニタリング及び詳細モニタリングの両方をサポートでき、これによって、測定についてタイムリーで価値ある品質の体験（QoE：quality of experience）を提供する共に、顧客に提供するビデオ品質に関して警報を出す能力を放送ビデオ・プロバイダに提供できる。
【０００９】
本願の第１観点は、マシン制御によるビデオ・データ・ストリーム評価方法であって、複数のビデオ・フレームを夫々含むチャンネルが、夫々複数含まれるビデオ・データ・ストリームをビデオ・データ・ソースから受けるステップと、複数の上記チャンネルの内の１つの特定チャンネルに対応する複数の上記ビデオ・フレームから少なくとも２つのビデオ・フレームを選択するステップと、上記ビデオ・データ・ストリームから選択された上記ビデオ・フレームを抽出するステップと、抽出された上記ビデオ・フレームを夫々デコードするステップと、デコードされた上記ビデオ・フレームの少なくとも１つを、デコードされた他の上記ビデオ・フレーム又は前もって蓄積されたビデオ・フレームの少なくとも１つと比較するステップと、上記比較ステップにおける比較結果に少なくとも一部は基づいて上記ビデオ・データ・ストリームの評価を生成するステップとを具えている。
【００１０】
本願の第２観点は、第１観点の方法において、上記ビデオ・データ・ストリームが、インターネット・プロトコル（ＩＰ）ビデオ、衛星放送ビデオ、ケーブル・ビデオ、地上波伝播ビデオのうちの１つであることを特徴としている。
【００１１】
本願の第３観点の発明は、第１観点の方法の上記選択ステップにおいて、複数の上記チャンネル内の１つに対応する少なくとも２つの独立ビデオ・フレーム（Ｉフレーム）を選択することを特徴としている。
【００１２】
本願の第４観点は、第１観点の方法の上記選択ステップにおいて、少なくとも１つの独立ビデオ・フレーム（Ｉビデオ・フレーム）と、少なくとも１つのバイ・ディレクショナル・ビデオ・フレーム（Ｂビデオ・フレーム）又はプリディクティブ（予測：predictive）ビデオ・フレーム（Ｐビデオ・フレーム）とを選択することを特徴としており、これらビデオ・フレームはいずれも複数の上記チャンネル内の上記特定チャンネルに対応している。
【００１３】
本願の第５観点は、第１観点の方法において、複数の上記チャンネルの内の上記特定チャンネル以外の１チャンネルに対応する複数のビデオ・フレーム中の少なくとも２つのビデオ・フレームについて、上述の選択、抽出、デコード、比較及び評価作成のステップを更に実行することを特徴としている。
【００１４】
本願の第６観点は、第５観点の方法において、上記複数チャンネルの個数以下の個数のチャンネルからなる優先順位リストに少なくとも一部分は基づいて、複数の上記チャンネルから上記特定チャンネル以外の上記１チャンネルを選択するステップを更に具えていることを特徴としている。
【００１５】
本願の第７観点は、第１観点の方法において、更に、上記特定チャンネル以外の複数の上記チャンネルの夫々に対応する複数のビデオ・フレームの少なくとも２つのビデオ・フレームについて、上述の選択、抽出、デコード、比較及び評価作成のステップを実行するのに続いて、複数の上記チャンネル中の上記特定チャンネルについて、上記選択、抽出、デコード、比較及び評価作成のステップを繰り返すことを特徴としている。
【００１６】
本願の第８観点は、第１観点の方法における抽出ステップが、選択されたビデオ・フレーム夫々に対応する情報を含む合成データ・ストリームを生成するステップと、上記合成データ・ストリームをフォーマットするステップと、上記合成データ・ストリームに、選択されたビデオ・フレーム夫々に対応するビデオ・フレーム特定情報を付加するステップとを有することを特徴としており、このとき、ビデオ・フレーム特定情報は、チャンネル情報、タイミング情報及びメタデータの少なくとも１つを含んでいる。
【００１７】
本願の第９観点は、第１観点の方法におけるデコード・ステップが、抽出したビデオ・フレームを受けるデコーダを用意するステップと、抽出したビデオ・フレームが上記デコーダを通過するステップと、デコーダからの出力データをキャプチャするステップとを有しており、このとき、第１観点の方法が、デコード中のエラーに応じてエラー・メッセージを制御ブロックに送るステップを更に具えていることを特徴としている。
【００１８】
本願の第１０観点は、第１観点の方法において、最初のデコード・ステップに続く評価生成ステップにおいて、デコーダをリセットするステップを更に有している。
【００１９】
本願の第１１観点は、第１観点の方法において、上記比較ステップが、デコードしたビデオ・フレームに実質的にブラック・ビデオが現れているか、又は、実質的にフリーズ・ビデオが現れているかもしれないとの判断に応じて、警告（アラート）を生成するステップを有していることを特徴としている。
【００２０】
本願の第１２観点は、第１１観点の方法において、警告が生成された時に、上記ビデオ・データ・ストリーム中の特定数の更なるビデオ・フレームについて、上記選択、抽出、デコード、比較及び評価作成のステップを繰り返すことによって、ビデオ・フレームの第２の評価を生成することを特徴としている。
【００２１】
本願の第１３観点は、第１観点の方法において、上記比較ステップが、デコードされたビデオ・フレームにブロック・ノイズが現れているかもしれないとの判断に応じて、警告を発生するステップを有していることを特徴としている。
【００２２】
本願の第１４観点は、第１３観点の方法において、警告が生成された時に、上記ビデオ・データ・ストリーム中の特定数の更なるビデオ・フレームについて、上記選択、抽出、デコード、比較及び評価作成のステップを繰り返すことによって、ビデオ・フレームの第２の評価を生成することを特徴としている。
【００２３】
本願の第１５観点は、第１観点の方法において、選択されたビデオ・フレームを蓄積するステップを更に具えることを特徴としている。
【００２４】
本願の第１６観点は、マシンで実行された時に、第１観点によるビデオ・データ・ストリームの評価方法をマシンで実行するためのマシンで実行可能な命令を記録しており、有形でマシンで読み込み可能な１つ以上のメディアである。
【００２５】
本願の第１７観点は、ビデオ・データ・ストリーム評価システムであって、
入力されるビデオ・データ・ストリームを受けるように動作するビデオ・データ・レシーバと、
入力される上記ビデオ・データ・ストリーム内の１つの特定チャンネルに対応する少なくとも２つのビデオ・フレームを選択するよう動作するビデオ・データ選択モジュールと、
上記ビデオ・データ・ストリームから選択された上記ビデオ・フレームを抽出するよう動作するビデオ・データ抽出モジュールと、
上記ビデオ・データ・ストリームから選択され、抽出された上記ビデオ・フレームをデコードするよう動作するビデオ・データ・デコーダと、
デコードされた上記ビデオ・フレームの夫々を少なくとも１つの基準ビデオ・フレームに対して比較するよう動作するビデオ・データ比較モジュールと、
上記ビデオ・データ比較モジュールから受けた出力情報に少なくとも一部は基づいて上記特定チャンネルについてのレポートを生成するよう動作するビデオ・データ評価モジュールと
を具えている。
【００２６】
本願の第１８観点は、第１７観点のビデオ・データ・ストリーム評価システムにおいて、少なくとも１つの上記基準ビデオ・フレームが、デコードされたビデオ・フレームの別のものか、前もって蓄積されたビデオ・フレームを含むか、又は、デコードされたビデオ・フレーム又は前もって蓄積されたビデオ・フレームを含んでいることを特徴としている。
【００２７】
本願の第１９観点は、第１７観点のビデオ・データ・ストリーム評価システムが、選択されたビデオ・フレームを蓄積し、蓄積されたビデオ・フレームをビデオ・データ比較モジュールで続いて行われる比較ステップのために供給するよう動作する蓄積モジュールを更に具えることを特徴としている。
【００２８】
本願の第１９観点は、第１７観点のビデオ・データ・ストリーム評価システムにおいて、上記ビデオ・データ評価モジュールが、指定した受け手に上記特定チャンネルについてのレポートを送るように動作することを特徴としている。
【図面の簡単な説明】
【００２９】
【図１】図１は、異なる種類のビデオ・フレームを有するエレメンタリ・ストリームの例を示したブロック図である。
【図２】図２は、用途を変えるために第１の解像度から第２の低解像度へとビデオを変更する例を示したブロック図である。
【図３】図３は、開示技術の実施形態に沿ったビデオ・データ・ストリーム評価システムの例を示したブロック図である。
【図４】図４は、開示技術の実施形態に沿ったビデオ・フレーム下処理モジュールの例を示したブロック図である。
【図５】図５は、開示技術の実施形態に沿ったマルチ・チャンネル用ビデオ・データ・ストリーム評価システムの例を示したブロック図である。
【図６】図６は、開示技術の実施形態に沿った高速スキャン及び詳細スキャン評価モジュールを有するビデオ・データ・ストリーム評価システムの例を示したブロック図である。
【図７】図７は、開示技術の実施形態に沿ったマシン制御によるビデオ・データ・ストリーム評価方法の例を示したフローチャートである。
【図８】図８は、開示技術の実施形態に沿ったマシン制御によるビデオ・データ・ストリーム評価方法の別の例を示したフローチャートである。
【発明を実施するための形態】
【００３０】
図１は、エレメンタリ・ビデオ・データ・ストリーム（ＥＳストリーム）１００を描いたブロック図である。この例では、ＥＳストリーム１００は、インディペンデント（独立：independent）フレーム（Ｉフレーム）１０２ａ及び１０２ｄ、プリディクティブ（予測：predictive）フレーム（Ｐフレーム）１０２ｂ、バイ・ディレクショナル（双方向：bi-directional）フレーム（Ｂフレーム）１０２ｃの４つの個別のフレームを有している。Ｉフレーム１０２ａ及び１０２ｄは、静止画像のように、基本的に各自で全体を描画可能な画像である。Ｐフレーム１０２ｂ及びＢフレーム１０２ｃは、それぞれ対応する画像情報の一部分のみを保持しているので、Ｉフレーム１０２ａ及び１０２ｄに比べて必要な記憶容量が小さくてすむ。
【００３１】
Ｐフレーム１０２ｂは、現在のフレームと前のフレーム（つまり、最初のＩフレーム１０２ａ）間の変化だけを記憶しており、これがＰフレームが一般に「デルタ・フレーム」とも呼ばれる理由である。例えば、もしＩフレーム１０２ａ及びＰフレーム１０２ｂ間の画像の変化が、画像の前景で動いているキャラクターだけであるなら、変化しない画像の背景の画素はＰフレーム１０２ｂ中には記憶されない。Ｂフレーム１０２ｃは、前のフレーム（つまり、Ｐフレーム１０２ｂ）及び後のフレーム（つまり、Ｉフレーム１０２ｄ）の両方と、現在のフレームとの差を用いて表示されるコンテンツを特定することで、更に記憶容量を節約する。
【００３２】
パケット化エレメンタリ・ストリーム（ＰＥＳ）は、典型的には、複数のＰＥＳパケットを含み、それぞれが図１のＥＳ１００のようなＥＳ内のビデオ・データから構成される。ＰＥＳパケットは、通常、固定サイズのトランスポート・ストリーム（ＴＳ）パケットに分割される。トランスポート・ストリームは、一般に複数の１８８バイトのＴＳパケットを含み、これらは一度に容易に多重化でき、ＩＰビデオ・ストリームの一部として代表的な放送伝送技術を用いて送信される。
【００３３】
図２は、高解像度（ＨＤ）ビデオ・データ２０２の標準解像度（ＳＤ）ビデオ・データ２０４へのデータ減少処理２００を描いたブロック図である。例えば、ＨＤビデオ・データ２０２は、１０８０ｉの解像度を持っており、これをＳＤビデオ・データ２０４用に転用する、つまり、６４０×４８０の解像度に減少させるとしても良い。また、ある状況においては、ＳＤビデオ・データ２０４をポータブル・ビデオ・データ２０６へと減少させ、例えば、ハンドヘルド・コンピュータや携帯電話でこれを表示可能にする必要があるかもしれない。転用する際の共通の課題は、各デ―タ減少段階において、ビデオ・データの画質が劣化する可能性があることである。例えば、ある解像度から第２の低解像度へと画像を減少させると、その低解像度で画像を表示させるデバイスでは画像がソフトでぼんやりとすることがある。
【００３４】
ビデオ・データ・ストリームについては、各層独自のエラーが生じる可能性があるので、各層についてエラーを監視する必要がある。また、１つの層（例えば、１つのＩＰパケット）における問題は、他の層（例えば、対応するＴＳパケット）におけるエラーにつながることが多々ある。実際、１つのビデオ・フレームが壊れていることが原因の１つのエラーは、多数のビデオ・フレームに伝播する。もし結合装置が悪い結合点を捕捉（選択）するようなら、例えば、そのデータ・ストリームを壊すために、１ビットだけオフにする必要がある。現在のシステムのなかには、エラー補正機能を内蔵するものもあるが、それらは非常に限られている。例えば、現在のシステムの中には、与えられたトランスポート・ストリーム又はパケット化エレメンタリ・ストリーム（ＰＥＳ）の限定的な評価をサポートするものもある。
【００３５】
問題が複雑なのは、Ｈ.２６４のような新しい規格は、より多くの処理能力を必要とする傾向があり、数百チャンネルはもちろん、１チャンネルの評価でさえ、プロセッサの能力がすぐに不足することである。実際、高性能のパソコンでも、複雑なために、２、３個のＨ.２６４ビデオ・ストリームしか処理できない。ハードウェア・デコーダでも、典型的には、多くても４個のＨ.２６４ビデオ・ストリームしか処理できず、その場合も、時間をかけてこれらを切り替えて処理するだけである。これは、非常に能力の高いハードウェアを用いても、全てのデータをデコードするには、非常に多くの処理リソースを必要とするためである。
【００３６】
ブラック・フレーム、フリーズ・フレームやブロック・ノイズ（Blockiness）の検出と言ったデコードされたベースバンドの重大な局面を、リアルタイムで測定することが好ましい。ブラック・フレームとは、一般に表示映像が実質的又は完全に黒のままで動かなくなってしまうことを指す。フリーズ・フレームとは、一般に表示映像が１つのフレームのままで動かなくなって、そのフレームを基本的には繰り返してしまう状況を指す。ブロック・ノイズ（Blockiness）は、一般にブロック形状又は矩形のエッジを有する視覚的な歪み（artifact）が現れることを指す。当業者であれば、こうした振る舞いが現れている表示映像にノイズが含まれることを理解しているであろう。例えば、ブラック・フレームは、視聴者は表示映像が黒のままで止まっているというかもしれないが、実際にはそこにある程度のノイズがあって、データが実際的には完全には均一ではない。
【００３７】
図３は、ビデオ・データ・ストリーム評価システム３００の例のブロック図である。ビデオ・ソース（映像源）３０２が、ビデオ・データ・ストリーム評価システム３００にビデオ・データ・ストリームを供給する。ビデオ・データ・ストリームは、多数の別々の放送チャンネルを含んでいるとしても良い。この例では、ビデオ・データ・ストリーム評価システム３００は、ビデオ・フレーム下処理モジュール３０４を有し、これはビデオ・ソース３０２からビデオ・データ・ストリームを受けて、例えば、図４に示す例に関して以下で説明するビデオ・フレームのフォーマットなどの下処理（前処理）ができる。実施形態によっては、ビデオ・フレーム下処理モジュール３０４は、図５に示す例に関して詳細に説明するように、ＨＤデータとＳＤデータなどのビデオ・データ形式毎に、ビデオ・データをグループ化しても良い。
【００３８】
１つ又は複数のチャンネルからのビデオ・データを適切にフォーマットし、オプションで他チャンネルの同じ変形をしたデータとまとめられたビデオ・データの１セット（組）が用意できると、ビデオ・フレーム下処理モジュール３０４は、例えば、ビデオ・データをデコーダのキュー（queue：処理待ちの列）の先頭に配置できるが、これは、結果としてビデオ・データをデコーダのリソース、例えば、ビデオ・フレーム・デコード・モジュール３０６に送ることができるということになる。ビデオ・フレーム・デコード・モジュール３０６は、ビデオ・フレーム下処理モジュール３０４から受けたビデオ・フレームをデコードし、デコードしたビデオ・フレームをビデオ・フレーム評価モジュール３０８に送る。
【００３９】
もし期待した数の適切にデコードされたビデオ・フレームがビデオ・フレーム・デコード・モジュール３０６から現れなければ、どういう対応をするか判断するために、例えば、エラーを制御ブロックに送るようにしても良い。こうした状況は、ビデオ・データ中に実際にエラー（これは他の処理でもっと詳細に評価する必要がある）があるのが原因ということもあり得るが、そうした状況は、また、例えば、ビデオ・フレーム・デコード・モジュール３０６を充分にプリセットする時間がない又はデータを設定していない、といったデコーダに関する問題によっても引き起こされることがある。こうしたシナリオにおいては、ビデオ・フレーム・デコード・モジュール３０６は、リトライ（再挑戦）しても良く、次のサイクルでもっとビデオ・データを送るように要求するか、又は、特定のユーザに注意を促すようにしても良い。
【００４０】
ビデオ・フレーム・デコード・モジュール３０６からデコードされたビデオ・フレームを受けると、ビデオ・フレーム評価モジュール３０８は、ビデオ・フレーム・デコード・モジュール３０６から受けたデコードされたビデオ・フレームに基いて、チャンネルを特定した評価を実施する。例えば、ビデオ・フレーム評価モジュール３０８は、ビデオ（映像）が、ブラック、フリーズ又はブロック・ノイズが現れるなどのような、何らかの望ましくない特性を示しているかどうかを判断できる。
【００４１】
ある実施形態においては、ビデオ・フレーム評価モジュール３０８は、例えば、一般に使用されている多数のビデオ・フレーム比較アルゴリズムのいくつかを用いて、デコードされた複数のビデオ・フレームを、１つずつ個別に、そして互いに比較することによる測定によって、比較することで、複数のビデオ・フレームを評価する。ビデオ・フレーム評価モジュール３０８は、オプションで、将来あり得る評価のため、例えば、比較のために、各チャンネルにつき、少なくとも１つ前のサイクルの複数のビデオ・フレームのコピーを保存しておいても良い。
【００４２】
ある実施形態においては、フリーズ・フレームについて、誤りを示すレートを効果的に減少させるために、例えば、同じチャンネルからの複数のビデオ・フレーム間に分離時間を設けるようにしても良い。もしそれらビデオ・フレームが、数秒の広がりにおいてほぼ同一であるなら、ノイズを除いて、隣接するフレームがほぼ類似しているというよりは、ビデオが本当にフリーズしている可能性がかなり高い。これは、隣接するフレームは通常高い相関があるからである。従って、ブラック又はフリーズ画像を効果的に検出するには、少なくとも２つのフレームを比較するビデオ・フレーム評価モジュール３０８が必要である。また、装置のエラーは、Ｉフレーム又はＩＤＲフレームを単に見ているだけでは見逃す可能性があるので、ビデオ・フレーム評価モジュール３０８は、一般には、Ｉフレームに加えて、Ｐフレーム又はＢフレームを注意して観察する。
【００４３】
実施形態によっては、ビデオ・フレーム評価モジュール３０８が１つ又は複数のレポート３１２を発生でき、これは連続的、特定時点、又はある条件への合致に応答して送られる。例えば、ビデオ・フレーム評価モジュール３０８は、ビデオが特定の特性を示したときだけレポート３１２を送るように設定できる。レポート３１２には、警告（アラート）又はトリガ警告（図示せず）を含んでも良い。例えば、もしあるチャンネルが現在フリーズしているなら、ビデオ・フレーム評価モジュール３０８は、ローカルの技術サポート・チームへの警告（アラート）を含むレポート３１２又は警告としてのレポート３１２を発することができ、これによって、問題解決を直ちに開始できる。レポート３１２には、どのチャンネルが不調か、どのような症状が現在そのチャンネルで現れているか、どれくらい長くその症状が現れているか、というような種々の形式の情報を含めても良い。
【００４４】
デコードされたビデオ・フレームの評価の一部として、ビデオ・フレーム評価モジュール３０８は、内部又は遠隔データベースのようなフレーム収納庫３１０から、予め蓄積したビデオ・フレームを取り出すことができる。例えば、ビデオ・フレーム評価モジュール３０８は、最も最近の前のビデオ・フレームのような多数の先のビデオ・フレームのいずれかと、現在のいくつかのビデオ・フレームとを比較できる。また、ビデオ・フレーム評価モジュール３０８は、今評価したビデオ・フレームをフレーム収納庫３１０に蓄積できるので、後に続く評価において、ビデオ・フレーム評価モジュール３０８はそれらを利用できる。
【００４５】
開示した技術におけるある実施形態では、費用対効果が高く、ほぼリアルタイムの測定を、ＩＰビデオ・ストリーム中の数百のビデオについて行うことができる。例えば、５００チャンネルを有するＩＰビデオ・ストリームの場合を考えてみよう。２つの６０フレーム毎秒ハードウェア・デコーダを含む実施形態では、平均して１チャンネル当たり３フレーム倍でデコードされると仮定すれば、５００チャンネル全てを通しての１サイクルを１２秒で完了できる。
【００４６】
当業者であれば、ビデオ・データ・ストリーム評価システム３００は、多数の異なるやり方で実施可能なことを理解できるであろう。例えば、ビデオ・データ・ストリーム評価システム３００の個々の構成要素は、ハードウェア要素、ソフトウェア要素、又はこれらの組合せた要素で実現可能である。ハードウェア要素を含む実施形態では、構成要素を互いに別個なもの、１つのハードウェア要素の部分、又は、これらの組合せとしても良い。
【００４７】
当業者であれば、開示技術には、ビデオ・データ・ストリーム評価システムに加えて（又はこれに代わる）、音声データ・ストリーム評価システムが含まれることを理解できるであろう。実施形態によっては、図３のビデオ・データ・ストリーム評価システム３００のような１つのデータ・ストリーム評価システムが、多数の放送チャンネルの夫々に対応する音声データとビデオ・データの両方を扱うように構成できる。
【００４８】
図４は、図３のビデオ・フレーム下処理モジュール３０４の詳細な例を示すブロック図である。この例では、ビデオ・フレーム下処理モジュール３０４が、ビデオ・フレーム選択モジュール４０２を含み、これは、ビデオ・ソース３０２から受け取ったビデオ・データ・ストリームからの１つの特定チャンネルについて、少なくとも２つのビデオ・フレームを選択する。ビデオ・フレーム選択モジュール４０２を使用して、入力されるビデオ・ストリーム通して読み、各チャンネルにつきデコード・リソースに最終的に送られる２つのビデオ・フレームだけを選択することによって、データを大幅に減少できる。ビデオ・ストリーム中のビデオ・オブジェクトを見つけるのに、全てをデコードする場合に比較して、大幅に少ない処理リソースで済む。
【００４９】
ビデオ・フレーム選択モジュール４０２は、１つのチャンネルにつき、２つのＩフレームを選択しても良い。これに代えて、ビデオ・フレーム選択モジュール４０２が、１つのＩフレームと、Ｐフレーム又はＢフレームの１つを選択しても良い。さらに別の実施形態では、ビデオ・フレーム選択モジュール４０２が、仮想的にＩフレーム、Ｐフレーム及びＢフレームの任意の組合せを選択しても良い。ある実施形態では、ビデオ・フレーム選択モジュール４０２は、１つのビデオ・ストリーム内で、２つ以上のビデオ・フレームを選択しても良い。
【００５０】
ビデオ・フレームが選択された時点で、ビデオ・フレーム選択モジュール４０２は、選択されたビデオ・フレームのＩＤをビデオ・フレーム抽出モジュール４０４を送るようにしても良く、これによってビデオ・データ・ストリームから選択されたビデオ・フレームが抽出される。当業者であれば、ビデオ・フレーム選択モジュール４０２及びビデオ・フレーム抽出モジュール４０４がまとめて実装されても良いし、更には１つの部品として実装されても良いことが理解されるであろう。ビデオ・フレーム抽出モジュール４０４が選択されたビデオ・フレームを抽出した時点で、選択されたビデオ・フレームをビデオ・フレーム・フォーマット・モジュール４０６に送る。
【００５１】
ビデオ・フレーム・フォーマット・モジュール４０６は、ビデオ・フレーム抽出モジュール４０４から受けた抽出ビデオ・フレームをフォーマットできる。例えば、選択されたフレームの位置が特定された時点で、ビデオ・フレーム・フォーマット・モジュール４０６は、データを処理待ち状態にし、ビデオ・フレーム・デコード・モジュール３０６での使用に適したフォーマットに設定する。実施形態によっては、ビデオ・フレーム・フォーマット・モジュール４０６が１つ以上の合成データ・ストリームを生成でき、それぞれは対応するビデオ・データをビデオ・フレーム・デコード・モジュール３０６でデコードするのに適したフォーマットにコピーする。ビデオ・フレーム・フォーマット・モジュール４０６は、デコード・タイムスタンプ（復号時刻情報）、プレゼンテーション・タイムスタンプ（提示時刻情報）及びメタデ―タのようなＭＰＥＧフォーマットの種々の細かい点を考慮でき、これらはビデオ・フレーム・デコード・モジュール３０６の適切な動作が確実になるように必要に応じて変形されても良い。
【００５２】
図５は、複数チャンネル形式を扱うように、図３のビデオ・データ・ストリーム評価システム ３００を変形した例を示すブロック図である。この例では、ビデオ・フレーム下処理モジュール３０４は、デコード処理を通して、データを送る前に同じ形式のビデオ・フレームをまとめて一緒に処理（バッチ処理）することで、デコーダのリセット時間及びセットアップ時間を減らすことができる。ある実施形態では、ビデオ・フレーム下処理モジュール３０４が、各ビデオ形式について、合成ストリームを生成できる。ここで使われているように、合成ストリームとは、新たに構成されたデータ・ストリームのことを一般に述べていて、これは対応する実際のビデオ・ストリームからコピーされたビデオ・データ（例えば、ある形式の全てのビデオ・データ）を含んでいる。
【００５３】
抽出されたビデオ・フレームの比較的小さなセットを、それを受け取るデコーダが期待するフォーマットに再フォーマットすることによって、システムはデコーダをリセットする必要を回避でき、結果として、一般的にこれに係るであろう処理時間のロスを避けることができる。ビデオ・フレームの異なる形式の数は、通常、少ない（例えば、５個の形式）ので、数個の合成チャンネルを使用することによって、数百チャンネルのビデオ・パイプライン処理を含む状況においてさえ、デコード・リソースで非常に効率的な処理が行える。
【００５４】
ビデオ・フレームがＳＤビデオ・チャンネルとＨＤビデオ・チャンネルが混じったものを含む状況においては、例えば、ビデオ・フレーム下処理モジュール３０４が複数のＳＤチャンネルを一度に処理（バッチ処理）して第１合成ストリームとし、第１合成ストリームをビデオ・フレーム・デコード・モジュール３０６に送ることができる。ビデオ・フレーム下処理モジュール３０４は、また、複数のＨＤチャンネルを一度に処理（バッチ処理）して第２合成ストリームとし、第２合成ストリームをもう１つのビデオ・フレーム・デコード・モジュール５０６に送ることができ、ビデオ・フレーム・デコード・モジュール５０６はストリームをデコードして、デコードしたフレームをもう１つのビデオ・フレーム評価モジュール５０８に渡し、これがＨＤデータに関するレポート５１０をオプションで生成するようにしても良い。
【００５５】
ＨＤチャンネルの変形版が複数ある状況においては、ビデオ・フレーム下処理モジュール３０４は、各変形版をバッチ処理できる。例えば、図５のビデオ・フレーム下処理モジュール３０４は、変形版をまとめてバッチ処理し、それを１つのストリームとして更に別のビデオ・フレーム・デコード・モジュール５１２に送る。モジュール５１２は、複数のビデオ・フレームをデコードし、それらを第３のビデオ・フレーム評価モジュール５１４に送る。モジュール５１４は、オプションでその変形版に関するレポート５１６を生成しても良い。
【００５６】
図５のビデオ・データ・ストリーム評価システム ３００では、ビデオ・フレーム・デコード・モジュール３０６、５０６及び５１２と、ビデオ・フレーム評価モジュール３０８、５０８及び５１４の夫々からなる別々の３セットで示している。しかし、当業者であれば、別の実施形態として、複数別々のデコード・リソース及び評価コンポーネントの代わりに、複数ストリームの複数グループを処理する１つのビデオ・フレーム・デコード・モジュール又は１つのビデオ・フレーム評価モジュールを含むものでも良いことが理解できるであろう。
【００５７】
図６は、図３のビデオ・データ・ストリーム評価システム３００の例を示すブロック図である。これには、高速スキャン・ビデオ評価モジュール６０２及び詳細（deep：ディープ）スキャン・ビデオ評価モジュール６０４がある。この例では、高速スキャン・ビデオ評価モジュール６０２は、ブラック、フリーズ又はブロック・ノイズが現れるといった特定のエラーについて、高速なスキャンを実行できる。ここで用いているように、高速スキャンとは、多数の異なるチャンネルの連続スキャンのことを言っていて、このとき、高速スキャン・ビデオ評価モジュール６０２は、次に評価するチャンネルに進む前に、１チャンネルにつき最小数のフレーム、例えば、２フレームを選択し、抽出し、評価する。
【００５８】
高速スキャン・ビデオ評価モジュール６０２は、全てのチャンネルに渡って高速スキャンを実行する。ただし、これは詳細さ（deep：深さ）に制限があり、１チャンネルにつき検査するデータ量に制約がある。このように、ある１つのチャンネルについてのベースバンドの限られたセットについて測定を実施し、そのチャンネルについての結果をレポートし、そして、次のチャンネルへと高速に、典型的にはリアルタイムに近いサイクルで進む。もし高速スキャン・ビデオ評価モジュール６０２がトリガとなり得るもの、例えば、ブラック・ビデオやフリーズ・ビデオの可能性のあるものを検出すると、ビデオ・データ・ストリーム評価システム ３００は、詳細スキャン・ビデオ評価モジュール６０４を起動し、より長い時間をかけてそのチャンネルを調べ、その疑わしい状態が本当に存在するのかを確認する。
【００５９】
ここで用いているように、詳細スキャン（deep scan）又は詳細探査（deep dive）とは、一般に、あるチャンネルのより長時間で、より詳細なビデオ分析のことを言っている。詳細スキャンは、高速スキャンでの疑惑のあるものを効率よく検討し、それらを確実性の高い結果へと変換する。例えば、高速スキャン・ビデオ評価モジュール６０２による高速スキャンによって、ある特定のチャンネルがフリーズして提示されているように見うけられる場合には、詳細スキャン・ビデオ評価モジュール６０４は、そのチャンネルが本当にフリーズしているか、そのチャンネルを数秒かけて詳細に観測し、信頼性の高い結果を得る。詳細スキャンが起動することのある別の状況としては、ある１つのチャンネルについてＧＯＰ（group of pictures：複数画面からなるグループ）の構成が変わった場合がある。こうした状況では、詳細スキャン・ビデオ評価モジュール６０４が、ＧＯＰの変化が原因でベースバンド・ビデオに問題が生じているか、そのチャンネルについて通常よりも多くの注意を払うようにできる。
【００６０】
ある実施形態では、評価対象チャンネルのリストによって、詳細スキャン・ビデオ評価モジュール６０４を駆動するようにもできる。このリストによって、複数チャンネルについての優先順位を示すことができる。例えば、このリストは、例えば、外部の自動ビデオ管理システムから、高速スキャン処理又はユ―ザ要求によって特定されたチャンネルについて、詳細分析の優先順位を高くするようにできる。このリストによって、詳細スキャン・ビデオ評価モジュール６０４に、ある特定チャンネルについて詳細スキャンを実施するようしたり、例えば、ペイ・パー・ビュー・チャンネルのような優先順位の高いチャンネルについて、より頻繁に詳細スキャンを実施するように管理できる。詳細スキャン・ビデオ評価モジュール６０４は、例えば、リストによって詳細スキャン処理をしないようになっているときも、全チャンネルについて詳細スキャンを連続して実施するようにも設定できる。
【００６１】
ある実施形態においては、観測するチャンネルのリストを設定するのに、スマート・アラーム処理及びエンジン・コントロールを用いても良い。スマート・アラーム処理及びエンジン・コントロールによって、システムが検知し、追跡すべき多数のビデオ特性を指定することもできる。ある実施形態においては、スマート・アラーム処理及びエンジン・コントロールは、例えば、図３のレポート３１２のような分析結果を受けて、その情報をどのように扱うかを判断できる。その情報に基づいて、スマート・アラーム処理及びエンジン・コントロールは、アラームを生成し、例えば、特定のユーザ又はネットワーク管理システムにアラームを送信するかどうかを決定できる。
【００６２】
図７は、マシン制御によるビデオ・データ・ストリーム評価方法７００の例を示したフローチャートである。ステップ７０２では、入力されるビデオ・データ・ストリーム内のある１つの特定チャンネルについて、２以上のビデオ・フレームが選択される。ある実施形態においては、システムがＩフレーム又はＩＤＲフレームの最初から開始しても良い。そのチャンネルについて２つ以上のフレームが選択された時点で、それらはステップ７０４に示されるようにビデオ・データ・ストリームから抽出できる。ある実施形態においては、抽出とは、選択されたビデオ・フレームに対応するビデオ・データを新しく生成した合成ストリームにコピーすることを述べている。
【００６３】
ステップ７０６では、抽出ビデオ・フレームがデコード・リソースに送られる前にフォーマットされる。次にフォーマットされたビデオ・フレームは、ステップ７０８に示されるようにデコードされる。デコード・リソースが既にいくらかのビデオ・フレームをデコードしている実施形態においては、デコード処理は、デコーダをリセットし、次のデータ・セットを受けるように準備することによって開始しても良い。デコーダの準備ができた時点で、ビデオ・データはデコーダを通して送信され、その出力がキャプチャされるようにできる。そして、得られたフレームには、評価リソースに送られる前に、チャンネル情報、タイミング情報、その他のメタデータ（デコーダ・フラグなど）といったタグが付与される。
【００６４】
ステップ７１０では、デコーダから受けたフォーマット済みビデオ・フレームが評価される。例えば、複数のビデオ・フレームは、ブラック・ビデオ、フリーズ・ビデオ、又は、ブロック・ノイズがあるかといった特定の望ましくない特性が評価対象のビデオ・フレームに現れているかどうか判定するのに、お互いを比較して、又は、前もって蓄積されたビデオ・フレームと比較して評価しても良い。ステップ７１２に示されるように、評価結果が生成され、更にオプションで、結果に基いて取り得るアクションに合わせて１つ又は複数の受け手に評価結果が送られる。例えば、放送ビデオ・プロバイダは、怒った顧客から電話を受ける前に、あるチャンネルについて検出されたブラック・ビデオ又はフリーズ・ビデオについて、先手先手で注意を払うように技術サポート担当者に勧告できる。
【００６５】
図８は、マシン制御によるビデオ・データ・ストリーム評価の別の例による方法８００を示したフローチャートである。ステップ８０２では、ある１つの特定チャンネルについて、ビデオ・データ・ストリームから２つ以上のビデオ・フレームが選択される。ステップ８０４では、選択されたビデオ・フレームが抽出され、フォーマットされ、デコード・リソースに送られて、デコード・リソースがステップ８０６に示すようにビデオ・フレームをデコードする。
【００６６】
ステップ８０８では、ステップ８０６でのデコード中に何らかのエラーが生じたかどうかに関して判断される。もしエラーが検出されると、ステップ８１０に示すように、エラー処理を起動しても良い。例えば、エラー・メッセージが指定の受け手に送られるようにしても良い。もしエラーが検出されないか、又はあるエラーが検出されたものの害がないと見なせるものか、現在の処理と関係のないものの場合には、ステップ８１２に示すようにビデオ・フレームが評価される。例えば、現在そのチャンネルに配信されているビデオがブラック、フリーズ又はブロック・ノイズであるかどうかを、システムが判断できる。ステップ８１２での評価は、チャンネルの高速スキャンを含むとしても良い。
【００６７】
ステップ８１４では、評価対象チャンネルについて詳細スキャンを実行するかに関して判断される。そのチャンネルの高速スキャンの結果、そのチャンネルにブラック・ビデオ又はフリーズ・ビデオが現れている可能性が検出されると、そのチャンネルに本当にその特定の特性が現れているかどうか確認するするため、システムは、そのチャンネルの詳細スキャンを起動できる。もし詳細スキャンを行うことになったら、処理はステップ８０２に戻る。もしブラック・ビデオ又はフリーズ・ビデオの可能性が確認されたら、システムは、そのチャンネルについてもっと多数のビデオ・フレームをもっと長時間観察し、信頼性の高い判断基準を得る。もし詳細スキャンをしないなら、ステップ８１６に示すように、現在のチャンネルの処理は停止できる。この時点で、方法８００は、次の被評価チャンネルに関して開始できる。
【００６８】
開示技術について示した実施形態は、おおよそＩＰビデオにフォーカスしたものであるが、当業者であれば、衛星、ケーブル又は地上波の伝播メディアにも応用可能であることが理解されるであろう。以下に、開示技術の実施形態を実現するのに適切したマシンの一般的な説明を行う。
【００６９】
以下の説明は、開示技術の実施形態を実現可能な適切なマシンについて、簡潔で一般的に記述しようと意図したものである。ここで用いているように、用語「マシン（マシン：機械）」とは、単一のマシンか、一緒に動作する複数のマシン又はデバイスが通信可能に結合したシステムを広く網羅している。典型的なマシンは、パソコン、ワークステーション、サーバ、ポータブル・コンピュータ、ハンドヘルド・デバイス、テブレット・デバイスなどのようなコンピューティング・デバイスを含んでも良い。
【００７０】
典型的には、マシンには、システム・バスがあり、これにプロセッサ、メモリ（例えば、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）その他のステート保持メディア）、ストレージ・デバイス、ビデオ・インタフェース、そして、入出力インタフェース・ポートが取り付けられる。マシンは、また、プログラマブル又はノン・プログラマブル・ロジック・デバイス又はアレー、ＡＳＩＣ（特定用途向けＩＣ）、エンベッデッド・コンピュータ、スマート・カードのようなエンベッデッド（embedded：埋め込み）コントローラを含んでも良い。マシンは、少なくとも一部は、他のマシンや、仮想現実環境を用いたインターアクション、バイオメトリック・フィードバック、その他の入力信号からの指示によってだけでなく、従来の入力デバイス（例えば、キーボード、マウスなど）からの入力によって制御されても良い。
【００７１】
マシンは、ネットワーク・インタフェース、モデムなどの通信手段を通して、１つ以上の遠隔マシンへの１つ以上の接続を利用しても良い。複数のマシンは、イントラネット、インターネット、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）などのような物理的又は論理的なネットワークによって、相互に接続されても良い。当業者であれば、ネットワーク通信は、無線周波数（ＲＦ）、衛星、マイクロウェーブ、ＩＥＥＥ５４５.１１、Bluetooth、光、赤外線、ケーブル、レーザを含む種々の有線又は無線の短距離又は長距離キャリア及びプロトコルを用いることができることを理解できるであろう。
【００７２】
開示技術の実施形態は、マシンでアクセスされたときに、マシンがタスクを実行したり、概要データ形式又は低レベル・ハードウェア・コンテキストを定義するという結果が得られる機能、処理手順、データ構造、アプリケーション・プログラム、命令などを含む関連データを参照したり、併せて考えることで説明できる。関連データは、例えば、揮発性又は不揮発性メモリ（例えば、ＲＡＭ及びＲＯＭ）や他のストレージ・デバイス及び関連するストレージ・メディアに記録できる。このストレージ・メディアには、ハードディスク・ドライブ、フレキシブル・ディスク・ドライブ、光ストレージ・メディア、フラッシュ・メモリ、メモリ・スティック、デジタル・ビデオ・ディスク、バイオロジカル・ストレージ、その他の有形の物理的ストレージ・メディアを含めることができる。
【００７３】
関連データは、物理的又は論理的ネットワークを含む伝送環境を通じて、パケット、シリアル・データ、パラレル・データ、伝播された信号などとして配信でき、圧縮又は暗号化されたフォーマットの形で利用できる。関連データは、分布された環境で利用でき、マシンがアクセスに関してローカルに又は遠隔に蓄積される。
【００７４】
本発明の原理は、図示した実施形態を参照しつつ、説明及び図示してきたが、図示した実施形態はそうした原理から逸脱することなく、配置や詳細を変形でき、また、望ましい形態に組み合わせることができることが理解できるであろう。そして、上述の説明は特定の複数の実施形態にフォーカスしたものであったが、他の構成も考えられる。特に、「本発明の実施形態によると」などの表現がここでは用いられているが、こうした言い回しは、一般的に参考として実現可能な実施形態であることを意味するもので、本発明が特定の実施形態の構成に限定されることを意味するものではない。ここで用いているように、これら用語は、参考までに同じ又は異なる実施形態であって、他の実施形態に組合せ可能なことを意味する。
【００７５】
結果として、ここに記載した実施形態は広く種々の変更が行えるという観点から、本願における詳細な説明及び付随する資料は、説明用に過ぎず、本発明の要旨を限定するものと考えるべきではない。本願発明には、以下の特許請求の範囲の記載とそれに等化なものに基づく要旨と思想の範囲に含まれる全ての変形が含まれる。
【符号の説明】
【００７６】
３００ ビデオ・データ・ストリーム評価システム
３０２ ビデオ・ソース
３０４ ビデオ・フレーム下処理モジュール
３０６ ビデオ・フレーム・デコード・モジュール
３０８ ビデオ・フレーム評価モジュール
３１０ フレーム収納庫
３１２ レポート
４０２ ビデオ・フレーム選択モジュール
４０４ ビデオ・フレーム抽出モジュール
４０６ ビデオ・フレーム・フォーマット・モジュール
５０６ ビデオ・フレーム・デコード・モジュール
５０８ ビデオ・フレーム評価モジュール
５１０ レポート
５１２ ビデオ・フレーム・デコード・モジュール
５１４ ビデオ・フレーム評価モジュール
５１６ レポート
６０２ 高速スキャン・ビデオ評価モジュール
６０４ 詳細スキャン・ビデオ評価モジュール
６０６ レポート
６０８ レポート
【特許請求の範囲】
【請求項１】
マシン制御によるビデオ・データ・ストリームの評価方法であって、
複数のビデオ・フレームを夫々含むチャンネルが、夫々複数含まれるビデオ・データ・ストリームをビデオ・データ・ソースから受けるステップと、
複数の上記チャンネルの内の１つの特定チャンネルに対応する複数の上記ビデオ・フレームから少なくとも２つのビデオ・フレームを選択するステップと、
上記ビデオ・データ・ストリームから選択された上記ビデオ・フレームを抽出するステップと、
抽出された上記ビデオ・フレームを夫々デコードするステップと、
デコードされた上記ビデオ・フレームの少なくとも１つを、デコードされた他の上記ビデオ・フレーム又は前もって蓄積されたビデオ・フレームの少なくとも１つと比較するステップと、
上記比較ステップにおける比較結果に少なくとも一部は基づいて上記ビデオ・データ・ストリームの評価を生成するステップと
を具えるビデオ・データ・ストリーム評価方法。
【請求項２】
入力されるビデオ・データ・ストリームを受けるように動作するビデオ・データ・レシーバと、
入力される上記ビデオ・データ・ストリーム内の１つの特定チャンネルに対応する少なくとも２つのビデオ・フレームを選択するよう動作するビデオ・データ選択モジュールと、
上記ビデオ・データ・ストリームから選択された上記ビデオ・フレームを抽出するよう動作するビデオ・データ抽出モジュールと、
上記ビデオ・データ・ストリームから選択され、抽出された上記ビデオ・フレームをデコードするよう動作するビデオ・データ・デコーダと、
デコードされた上記ビデオ・フレームの夫々を少なくとも１つの基準ビデオ・フレームに対して比較するよう動作するビデオ・データ比較モジュールと、
上記ビデオ・データ比較モジュールから受けた出力情報に少なくとも一部は基づいて上記特定チャンネルについてのレポートを生成するよう動作するビデオ・データ評価モジュールと
を具えるビデオ・データ・ストリーム評価システム。
【請求項１】
マシン制御によるビデオ・データ・ストリームの評価方法であって、
複数のビデオ・フレームを夫々含むチャンネルが、夫々複数含まれるビデオ・データ・ストリームをビデオ・データ・ソースから受けるステップと、
複数の上記チャンネルの内の１つの特定チャンネルに対応する複数の上記ビデオ・フレームから少なくとも２つのビデオ・フレームを選択するステップと、
上記ビデオ・データ・ストリームから選択された上記ビデオ・フレームを抽出するステップと、
抽出された上記ビデオ・フレームを夫々デコードするステップと、
デコードされた上記ビデオ・フレームの少なくとも１つを、デコードされた他の上記ビデオ・フレーム又は前もって蓄積されたビデオ・フレームの少なくとも１つと比較するステップと、
上記比較ステップにおける比較結果に少なくとも一部は基づいて上記ビデオ・データ・ストリームの評価を生成するステップと
を具えるビデオ・データ・ストリーム評価方法。
【請求項２】
入力されるビデオ・データ・ストリームを受けるように動作するビデオ・データ・レシーバと、
入力される上記ビデオ・データ・ストリーム内の１つの特定チャンネルに対応する少なくとも２つのビデオ・フレームを選択するよう動作するビデオ・データ選択モジュールと、
上記ビデオ・データ・ストリームから選択された上記ビデオ・フレームを抽出するよう動作するビデオ・データ抽出モジュールと、
上記ビデオ・データ・ストリームから選択され、抽出された上記ビデオ・フレームをデコードするよう動作するビデオ・データ・デコーダと、
デコードされた上記ビデオ・フレームの夫々を少なくとも１つの基準ビデオ・フレームに対して比較するよう動作するビデオ・データ比較モジュールと、
上記ビデオ・データ比較モジュールから受けた出力情報に少なくとも一部は基づいて上記特定チャンネルについてのレポートを生成するよう動作するビデオ・データ評価モジュールと
を具えるビデオ・データ・ストリーム評価システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１２−２０４８７８（Ｐ２０１２−２０４８７８Ａ）
【公開日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願番号】特願２０１１−６４９１７（Ｐ２０１１−６４９１７）
【出願日】平成２３年３月２３日（２０１１．３．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（５０３０５０９５１）テクトロニクス・インターナショナル・セールス・ゲーエムベーハー (35)
【Ｆターム（参考）】
【公開日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願日】平成２３年３月２３日（２０１１．３．２３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（５０３０５０９５１）テクトロニクス・インターナショナル・セールス・ゲーエムベーハー (35)
【Ｆターム（参考）】
[ Back to top ]