ホーム > 特許ランキング > ソニーグループ株式会社
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-09-03
(54)【発明の名称】ストリーム修復メモリ管理
(51)【国際特許分類】
H04N 21/438 20110101AFI20240827BHJP
【ＦＩ】
H04N21/438
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024506969
(86)(22)【出願日】2022-08-05
(85)【翻訳文提出日】2024-02-05
(86)【国際出願番号】 IB2022057325
(87)【国際公開番号】W WO2023012751
(87)【国際公開日】2023-02-09
(31)【優先権主張番号】63/260,022
(32)【優先日】2021-08-06
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/506,592
(32)【優先日】2021-10-20
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＵＮＩＸ
２．ＨＤＭＩ
３．ＪＡＶＡＳＣＲＩＰＴ
(71)【出願人】
【識別番号】000002185
【氏名又は名称】ソニーグループ株式会社
(74)【代理人】
【識別番号】100092093
【弁理士】
【氏名又は名称】辻居 幸一
(74)【代理人】
【識別番号】100109070
【弁理士】
【氏名又は名称】須田 洋之
(74)【代理人】
【識別番号】100067013
【弁理士】
【氏名又は名称】大塚 文昭
(74)【代理人】
【識別番号】100141553
【弁理士】
【氏名又は名称】鈴木 信彦
(72)【発明者】
【氏名】キャンデロア ブラント
(72)【発明者】
【氏名】ゴールドバーグ アダム
(72)【発明者】
【氏名】アンスフィールド フレッド
(72)【発明者】
【氏名】クリフト グラハム
(72)【発明者】
【氏名】ピネダ ローレン エフ
【テーマコード（参考）】
5C164
【Ｆターム（参考）】
5C164FA04
5C164UB21P
5C164UB38S
5C164UB41S
5C164UC27S
5C164YA21
(57)【要約】
次世代放送テレビサービスを確実に提供する上で高度テレビシステム委員会（ＡＴＳＣ）３．０テレビプロトコルを拡張及び／又は改善する技術について説明する。複数のメモリバッファを使用して、放送パケットの修復及び提示又は記憶を管理する。
【選択図】 なし
【選択図】 なし
【特許請求の範囲】
【請求項1】
少なくとも１つの受信機が放送信号を受信できるデジタルテレビにおいて、放送デジタルテレビ（ＤＴＶ）データ要素をバッファ内に受信することと、
前記バッファが閾値を満たすデータ量を含んでいることに応答して、前記バッファ内のＤＴＶデータ要素のパケットエラーのためのいずれかの置換用コンテンツが利用可能であるかどうかを識別することと、
置換用コンテンツが利用可能であることに応答して、前記バッファ内の少なくとも第１のＤＴＶデータ要素を修復することと、
前記バッファ内のＤＴＶデータ要素を少なくとも１つの解凍又は記憶エンジンに伝達して、前記ＤＴＶデータ要素を提示又は記憶のために処理することと、
を含むことを特徴とする方法。
【請求項2】
第２のＤＴＶデータ要素のための置換用コンテンツが利用可能でないことに応答して、少なくとも前記第２のＤＴＶデータ要素が少なくとも１つのエラーを含む旨を前記解凍又は記憶エンジンにシグナリングすることを含む、請求項１に記載の方法。
【請求項3】
前記ＤＴＶデータ要素はＤＴＶパケットを含む、請求項１に記載の方法。
【請求項4】
前記バッファは、第１のメモリアドレス範囲を含む第１のバッファであり、前記方法は、前記第１のバッファが満杯になる前に前記第１のバッファ内に前記ＤＴＶデータ要素が受信されている間に、第２のメモリアドレス範囲を含む第２のバッファ内のＤＴＶデータ要素のエラーを修復することを含む、請求項１に記載の方法。
【請求項5】
前記方法は、前記第１のバッファが満杯になる前に前記ＤＴＶデータ要素が前記第１のバッファ内に受信されていて、前記第２のバッファ内でエラーが修復されている間に、第３のメモリアドレス範囲を含む第３のバッファから前記解凍又は記憶エンジンにＤＴＶデータ要素を伝達することを含む、請求項４に記載の方法。
【請求項6】
前記第２のバッファ内のＤＴＶデータ要素のエラー修復の完了時に、前記第２のバッファから前記解凍又は記憶エンジンにＤＴＶデータ要素を伝達することを含む、請求項４に記載の方法。
【請求項7】
前記第３のバッファからのＤＴＶデータ要素の伝達の完了時に、前記第３のバッファ内にＤＴＶデータ要素を受信することを含む、請求項６に記載の方法。
【請求項8】
前記ＤＴＶ受信機は、高度テレビシステム委員会（ＡＴＳＣ）３．０受信機を含む、請求項１に記載の方法。
【請求項9】
デジタルテレビ（ＤＴＶ）装置であって、少なくとも１つのデジタルテレビ（ＤＴＶ）受信機と、
前記ＤＴＶ受信機に関連する、命令をプログラムされた少なくとも１つのプロセッサと、
を備え、前記命令は、前記プロセッサを、
放送デジタルテレビ（ＤＴＶ）データ要素を同時にそれぞれ受信し、ＤＴＶデータ要素を修復し、ＤＴＶデータ要素を少なくとも１つのディスプレイ上での提示のため又はＤＴＶデータ要素において表現されるコンテンツの記憶のために処理エンジンに伝達するように、少なくとも第１、第２及び第３のバッファを制御する、
ように構成する、
ことを特徴とするＤＴＶ装置。
【請求項10】
前記命令は、前記第１のバッファ内にＤＴＶデータ要素を受信し、
前記第１のバッファが閾値を満たすデータ量を含んでいることに応答して、前記第１のバッファ内のＤＴＶデータ要素のパケットエラーのためのいずれかの置換用コンテンツが利用可能であるかどうかを識別し、
置換用コンテンツが利用可能であることに応答して、前記第１のバッファ内の少なくとも第１のＤＴＶデータ要素を修復し、
前記第１のバッファ内のＤＴＶデータ要素を処理エンジンに伝達する、
ように実行可能である、請求項９に記載のＤＴＶ装置。
【請求項11】
前記命令は、第２のＤＴＶデータ要素のための置換用コンテンツが利用可能でないことに応答して、少なくとも前記第２のＤＴＶデータ要素が少なくとも１つのエラーを含む旨を前記処理エンジンにシグナリングする、
ように実行可能である、請求項１０に記載のＤＴＶ装置。
【請求項12】
前記ＤＴＶデータ要素はＤＴＶパケットを含む、請求項９に記載のＤＴＶ装置。
【請求項13】
前記第１のバッファは第１のメモリアドレス範囲を含み、前記命令は、前記第１のバッファが満杯になる前に前記第１のバッファ内に前記ＤＴＶデータ要素が受信されている間に、第２のメモリアドレス範囲を含む第２のバッファ内のＤＴＶデータ要素のエラーを修復する、
ように実行可能である、請求項９に記載のＤＴＶ装置。
【請求項14】
前記命令は、前記第１のバッファが満杯になる前に前記ＤＴＶデータ要素が前記第１のバッファ内に受信されていて、前記第２のバッファ内でエラーが修復されている間に、第３のメモリアドレス範囲を含む第３のバッファから前記処理エンジンにＤＴＶデータ要素を伝達するように実行可能である、請求項１３に記載のＤＴＶ装置。
【請求項15】
前記命令は、前記第２のバッファ内のＤＴＶデータ要素のエラー修復の完了時に、前記第２のバッファから前記処理エンジンにＤＴＶデータ要素を伝達するように実行可能である、請求項１４に記載のＤＴＶ装置。
【請求項16】
前記命令は、前記第３のバッファからのＤＴＶデータ要素の伝達の完了時に、前記第３のバッファ内にＤＴＶデータ要素を受信するように実行可能である、請求項１５に記載のＤＴＶ装置。
【請求項17】
前記ＤＴＶ受信機は、高度テレビシステム委員会（ＡＴＳＣ）３．０受信機を含む、請求項９に記載のＤＴＶ装置。
【請求項18】
少なくとも１つのプロセッサを備えた装置であって、前記少なくとも１つのプロセッサは、受信した放送デジタルテレビ（ＤＴＶ）を、受信、エラー訂正及びデータ読み出しを含む少なくとも３つのバッファ動作間で循環させることであって、各バッファ動作は、それぞれのメモリレジスタ割り当てを有する少なくとも第１、第２及び第３のバッファの各々において順次に実行される、ことと、
バッファ動作を実行するアプリケーション間でのバッファ使用のための競合を防ぐことと、
を行うように構成される、
ことを特徴とする装置。
【請求項19】
前記装置は、高度テレビシステム委員会（ＡＴＳＣ）３．０受信機を含む、請求項１８に記載の装置。
【請求項20】
前記プロセッサは、放送デジタルテレビ（ＤＴＶ）データ要素を同時にそれぞれ受信し、ＤＴＶデータ要素を修復し、ＤＴＶデータ要素をコンテンツの提示又は記憶のために処理エンジンに伝達するように、少なくとも前記第１、第２及び第３のバッファを制御するよう構成される、請求項１８に記載の装置。
【発明の詳細な説明】
【技術分野】
【0001】
本出願は、デジタルテレビを対象とする、必然的にコンピュータ技術に根ざした技術的進歩に関し、具体的には高度テレビシステム委員会（ＡＴＳＣ）３．０に関する。
【背景技術】
【0002】
高度テレビシステム委員会（ＡＴＳＣ）３．０規格群は、Ａ／３００に示されている、次世代放送テレビを配信するための数多くの業界技術標準の組である。ＡＴＳＣ３．０は、超高精細テレビから無線電話機までの数多くの受信装置に対するテレビ放送ビデオ（ｔｅｌｅｖｉｓｅｄ ｖｉｄｅｏ）、双方向サービス、非リアルタイムデータ配信、及び的を絞った広告（ｔａｉｌｏｒｅｄ ａｄｖｅｒｔｉｓｉｎｇ）などの幅広いテレビサービスの提供をサポートする。ＡＴＳＣ３．０は、（「オーバージエア（Ｏｖｅｒ ｔｈｅ Ａｉｒ）」又はＯＴＡと呼ばれる）放送コンテンツと（「オーバーザトップ（Ｏｖｅｒ ｔｈｅ Ｔｏｐ）」又はＯＴＴと呼ばれる）関連するブロードバンド配信コンテンツ及びサービスとの間の協調も取りまとめる。ＡＴＳＣ３．０は、技術の進化と共にいずれかの関連する技術標準を全面的に見直す必要なく容易に進歩を組み込むことができるような柔軟性を有するように設計されている。
【0003】
本明細書で理解されるように、ＡＴＳＣ３．０受信機は、単一周波数ネットワーク（ＳＦＮ）又はマルチ周波数ネットワーク（ＭＦＮ）においてサービスをスキャンする。また、ＡＴＳＣ３．０受信機は、これら両タイプの周波数ネットワークが利用可能でない場合にはブロードバンドを介してサービスを受信することもできる。ＡＴＳＣ３．０受信機は、コンテンツをリアルタイムでディスプレイにレンダリングし、又はコンテンツを記憶装置に記録することができる。
【発明の概要】
【発明が解決しようとする課題】
【0004】
本明細書でさらに理解されるように、放送コンテンツは、受信されると処理されてエラーが訂正される。ＡＴＳＣ放送ストリームは、採用する変調スキームに、ＡＴＳＣリンク層パケット（ＡＴＳＣ Ｌｉｎｋ Ｌａｙｅｒ Ｐａｃｋｅｔｓ：ＡＬＰ）内の多くのシングルビットエラーを修正する順方向誤り訂正（ＦＥＣ）を組み込んでいる。マルチビット又は欠落パケットは、信号経路が劣化する又は信号ロックの損失が存在する境界条件で発生し得る深刻なエラーである。この種のエラーはＦＥＣで修復することができない。本明細書で認識されるように、このようなコンテンツは、レンダリング前又はストレージへの書き込み前に、欠落した又は訂正不能なパケットを置き換えることによって改善されることが望ましい。このプロセスでは、コンテンツにエラーがないかを調べた後に、大規模な修復プロセスを開始すべきであるかどうかを決定する必要があり、或いは場合によっては、例えばＭＦＮ内に第２の周波数が存在する場合には、一次放送フィードが何であるかについての再選択を開始すべきであるかどうかを決定する必要がある。たとえ第２の周波数に同等のサービスが存在する場合でも、アクセスは一時的なものであって一次放送のフィードを変更すべきではないと判定することができる。しかしながら、修復を試みるべきである場合には、通常、欠落したパケット又はエラーを含むパケットだけでなく、これらのパケットが存在するフレーム群内の全ての関連するパケットを置き換える必要がある。これらのパケットは、サービスから第２の周波数で取得されたパケットから、或いはそれらが利用可能でない場合にはブロードバンドを通じて取得することができる。修復アプリケーションは、コンテンツメモリへの自由なアクセスを必要とする。しかしながら、同じ装置上で動作して同じメモリにアクセスしようと試みる異なるソフトウェアアプリケーション又はハードウェア回路がコンテンツメモリに同時に書き込みを行うと、問題が生じる場合がある。具体的には、１つのソフトウェアアプリケーション又はハードウェア回路がメモリにアクセスしている時には、これらが他のアプリケーション又はハードウェア回路に対してメモリをロックアップしてしまうことがある。すなわち、修復に関与するアプリケーションが欠落又は破損したコンテンツセグメントを置き換える必要がある一方で、受信用アプリケーション又は回路が着信コンテンツセグメントを記憶する必要があり、レンダリング又は記憶用アプリケーション又は回路が解凍及び再生目的でそのメモリに、或いはハードディスクドライブ又はソリッドステートドライブなどの長期ストレージにアクセスする必要があることによって同じメモリへのアクセス権を求めて競合する場合などに、アプリケーション又はハードウェア回路に競合が発生する可能性がある。
【課題を解決するための手段】
【0005】
従って、少なくとも１つの受信機が放送信号を受信できるデジタルテレビにおいて、方法が、放送デジタルテレビ（ＤＴＶ）データ要素をバッファ内に受信することを含む。方法は、バッファが閾値を満たすデータ量を含んでいることに応答して、バッファ内のＤＴＶデータ要素のパケットエラーのためのいずれかの置換用コンテンツが利用可能であるかどうかを識別することと、置換用コンテンツが利用可能であることに応答して、バッファ内の少なくとも第１のＤＴＶデータ要素を修復することと、を含む。方法は、バッファ内のＤＴＶデータ要素を少なくとも１つの解凍又は記憶エンジンに伝達して、ＤＴＶデータ要素を少なくとも１つのディスプレイ上での提示のため又は記録媒体への記憶のために処理することを含む。
【0006】
いくつかの実施形態では、方法が、第２のＤＴＶデータ要素のための置換用コンテンツが利用可能でないことに応答して、少なくとも第２のＤＴＶデータ要素が少なくとも１つのエラーを含む旨を解凍又は記憶エンジンにシグナリングすることを含むことができる。
【0007】
実装例では、ＤＴＶデータ要素がＤＴＶパケットを含むことができる。
【0008】
実施形態例では、バッファが、第１のメモリアドレス範囲を含む第１のバッファであり、方法は、第１のバッファが満杯になる前に第１のバッファ内にＤＴＶデータ要素が受信されている間に、第２のメモリアドレス範囲を有する第２のバッファ内のＤＴＶデータ要素のエラーを修復することを含む。いくつかの実装では、方法が、第１のバッファが満杯になる前にＤＴＶデータ要素が第１のバッファ内に受信されていて、第２のバッファ内でエラーが修復されている間に、第３のバッファから解凍又は記憶エンジンにＤＴＶデータ要素を伝達することを含む。第３のバッファは第３のメモリアドレス範囲を有する。第３のバッファが空になると、そのメモリポインタは第２のバッファのためのものであったメモリポインタに変更される。第２のバッファ内に存在していたＤＴＶデータ要素のエラー修復が完了すると、この時点で第３のバッファ内に存在している第２のバッファからのＤＴＶデータ要素を解凍又は記憶エンジンに伝達することができる。
【0009】
バッファのメモリアドレスは全て互いに異なり、必要に応じて互いに重複しない。様々なバッファへのポインタは、必要に応じて変化することができる。第１のバッファは、バッファが満杯である時などの閾値を満たすデータ量を含む時には第２のバッファになる。修復アプリケーションには、第１のバッファであったもののメモリ位置ポイントを与えることができる。バッファには、終端アドレス又はバッファサイズを与えることができる。古い第２のバッファのポインタは、この時点でレンダリングに関与するアプリケーションに与えられ、この時点で第２のバッファは第３のバッファになる。古いコンテンツを含む古い第３のバッファは、この時点で利用可能なバッファになって、着信パケットを受け取る第１のバッファになることができる。
【0010】
別の態様では、デジタルテレビ（ＤＴＶ）装置が、少なくとも１つのデジタルテレビ（ＤＴＶ）受信機と、命令をプログラムされた少なくとも１つのプロセッサとを含み、この命令は、プロセッサを、放送デジタルテレビ（ＤＴＶ）データ要素を同時にそれぞれ受信し、ＤＴＶデータ要素を修復し、ＤＴＶデータ要素を少なくとも１つのディスプレイ上での提示のため又はＤＴＶデータ要素において表現されるコンテンツの記録媒体への記憶のために処理エンジンに伝達するように、少なくとも第１、第２及び第３のバッファを制御するように構成する、
【0011】
別の態様では、装置が、受信した放送デジタルテレビ（ＤＴＶ）を、受信、エラー訂正及びデータ読み出しを含む少なくとも３つのバッファ動作間で循環させるように構成された少なくとも１つのプロセッサを含む。各バッファ動作は、それぞれのメモリレジスタ割り当てを有する少なくとも第１、第２及び第３のバッファの各々において順次に実行される。プロセッサは、バッファ動作を実行するアプリケーション間でのバッファ使用のための競合を防ぐように構成される。
【0012】
本出願の詳細は、その構造及び動作の両方に関し、同様の要素を同様の参照符号で示す添付図面を参照することで最も良く理解することができる。
【図面の簡単な説明】
【0013】
【図1】高度テレビシステム委員会（ＡＴＳＣ）３．０システムを示す図である。
【図3】具体的なシステム例を示す図である。
【図4】デジタルＴＶ受信機の第１の実施形態例を示す図である。
【図5】デジタルＴＶ受信機の第２の実施形態例を示す図である。
【図6】特定の受信機メモリシステム例を示す図である。
【図7】第１のバッファのロジック例をフローチャート例形式で示す図である。
【図8】第２のバッファのロジック例をフローチャート例形式で示す図である。
【図9】第３のバッファのロジック例をフローチャート例形式で示す図である。
【発明を実施するための形態】
【0014】
本開示は、高度テレビシステム委員会（ＡＴＳＣ）３．０テレビなどのデジタルテレビの技術的進歩に関する。本明細書におけるシステム例は、互いにデータを交換できるように放送及び／又はネットワークを介して接続されたＡＴＳＣ３．０ソースコンポーネント及びクライアントコンポーネントを含むことができる。クライアントコンポーネントは、ポータブルテレビ（例えば、スマートＴＶ、インターネット対応ＴＶ）、ラップトップ及びタブレットコンピュータなどのポータブルコンピュータ、並びにスマートフォン及び後述するさらなる例を含むその他のモバイル装置などの１又は２以上のコンピュータ装置を含むことができる。これらのクライアント装置は、様々な動作環境で動作することができる。例えば、クライアントコンピュータの一部は、一例としてＭｉｃｒｏｓｏｆｔ社のオペレーティングシステム、又はＵｎｉｘオペレーティングシステム、或いはＡｐｐｌｅ Ｃｏｍｐｕｔｅｒ社又はＧｏｏｇｌｅ社によって製造されたＡｎｄｒｏｉｄ（登録商標）などのオペレーティングシステムを採用することができる。これらの動作環境は、Ｍｉｃｒｏｓｏｆｔ社、Ｇｏｏｇｌｅ社又はＭｏｚｉｌｌａによって作成されたブラウザ、或いは後述するインターネットサーバによってホストされたウェブサイトにアクセスできるその他のブラウジングプログラムなどの１又は２以上のブラウジングプログラムを実行するために使用することができる。
【0015】
引用により本明細書に組み入れられるＡＴＳＣ３．０出版物Ａ／３４４は、とりわけ本明細書で説明する技術に関連することができる。
【0016】
ＡＴＳＣ３．０ソースコンポーネントは、放送送信コンポーネントと、インターネットなどのネットワークを介したデータ放送及び／又はデータ送信を行うようにソースコンポーネントを構成する命令を実行する１又は２以上のプロセッサを含むことができるサーバ及び／又はゲートウェイとを含むことができる。クライアントコンポーネント及び／又はローカルＡＴＳＣ３．０ソースコンポーネントとしては、Ｓｏｎｙ ＰｌａｙＳｔａｔｉｏｎ（登録商標）などのゲーム機、パーソナルコンピュータなどを具体例として挙げることができる。
【0017】
クライアントとサーバとの間では、ネットワークを介して情報を交換することができる。この目的及びセキュリティのために、サーバ及び／又はクライアントは、ファイヤウォール、ロードバランサ、一時ストレージ、及びプロキシ、並びに真正性及びセキュリティを高めるその他のネットワークインフラを含むことができる。
【0018】
本明細書で使用する命令とは、システム内で情報を処理するためのコンピュータ実装ステップのことを意味する。命令は、ソフトウェア、ファームウェア又はハードウェアで実装することができ、システムのコンポーネントが行うあらゆるタイプのプログラムステップを含むことができる。
【0019】
プロセッサは、アドレス回線、データ回線及び制御回線などの様々な回線、並びにレジスタ及びシフトレジスタによってロジックを実行できるシングルチップ又はマルチチッププロセッサであることができる。
【0020】
フローチャートによって説明するソフトウェアモジュール、及び本明細書におけるユーザインターフェイスは、様々なサブルーチン、手続きなどを含むことができる。本開示を限定することなく、特定のモジュールによって実行されるものとして開示するロジックは、他のソフトウェアモジュールに再分配し、及び／又は単一のモジュールに組み合わせ、及び／又は共有可能なライブラリ内で利用することもできる。フローチャート形式を使用することもできるが、ソフトウェアは、状態機械又はその他の論理的方法として実装することもできると理解されたい。
【0021】
本明細書で説明する本原理は、ハードウェア、ソフトウェア、ファームウェア又はこれらの組み合わせとして実装することができ、従って例示的なコンポーネント、ブロック、モジュール、回路及びステップについてはこれらの機能面から説明する。
【0022】
上記で示唆したものに加え、論理ブロック、モジュール及び回路は、汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は特定用途向け集積回路（ＡＳＩＣ）などの他のプログラマブルロジックデバイス、離散ゲート又はトランジスタロジック、離散ハードウェアコンポーネント、又は本明細書で説明する機能を実行するように設計されたこれらのいずれかの組み合わせを使用して実装又は実行することができる。プロセッサは、コントローラ、状態機械、又はコンピュータ装置の組み合わせによって実装することができる。
【0023】
以下で説明する機能及び方法は、ソフトウェアで実装した場合、以下に限定するわけではないが、ハイパーテキストマークアップ言語（ＨＴＭＬ）－５、Ｊａｖａ（登録商標）／Ｊａｖａｓｃｒｉｐｔ、Ｃ＃、Ｃ＋＋などの適当な言語で書くことができ、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、電気的に消去可能でプログラム可能なリードオンリメモリ（ＥＥＰＲＯＭ）、コンパクトディスクリードオンリメモリ（ＣＤ－ＲＯＭ）、又はデジタル多用途ディスク（ＤＶＤ）などの他の光ディスクストレージ、磁気ディスクストレージ、又は取り外し可能なユニバーサルシリアルバス（ＵＳＢ）サムドライブなどを含む他の磁気ストレージ装置などのコンピュータ可読記憶媒体に記憶し、又はこれらを通じて伝送することができる。ある接続は、コンピュータ可読媒体を構築することができる。このような接続は、一例として、光ファイバ、同軸線、デジタル加入者回線（ＤＳＬ）及びツイストペア線を含む有線ケーブルを含むことができる。
【0024】
１つの実施形態に含まれるコンポーネントは、他の実施形態においていずれかの適切な組み合わせで使用することができる。例えば、本明細書において説明する及び／又は図に示す様々なコンポーネントのいずれかは、組み合わせ、置き換え、又は他の実施形態から除外することができる。
【0025】
「Ａ、Ｂ及びＣのうちの少なくとも１つを有する（同様に、「Ａ、Ｂ又はＣのうちの少なくとも１つを有する」、及び「Ａ、Ｂ、Ｃのうちの少なくとも１つを有する」）」との記載は、Ａのみ、Ｂのみ、Ｃのみ、ＡとＢの両方、ＡとＣの両方、ＢとＣの両方、及び／又はＡとＢとＣ全てなどを含む。
【0026】
本原理は、ディープラーニングモデルを含む様々な機械学習モデルを採用することができる。本原理による機械学習モデルは、教師あり学習、教師なし学習、半教師あり学習、強化学習、特徴学習、自己学習及びその他の学習形態を含む方法で訓練された様々なアルゴリズムを使用することができる。コンピュータ回路によって実装できるこのようなアルゴリズムの例としては、畳み込みニューラルネットワーク（ＣＮＮ）、再帰型ニューラルネットワーク（ＲＮＮ）、長短期記憶（ＬＳＴＭ）ネットワークとして知られているタイプのＲＮＮなどの１又は２以上のニューラルネットワークが挙げられる。サポートベクターマシン（ＳＶＭ）及びベイジアンネットワークも機械学習モデルの一例であると考えることができる。
【0027】
従って、本明細書で理解されるように、機械学習を実行することは、モデルがさらなるデータを処理して推論を行えるように、訓練データにアクセスした後に訓練データに基づいてモデルを訓練することを伴うことができる。従って、機械学習を通じて訓練された人工ニューラルネットワーク／人工知能モデルは、入力層と、出力層と、適切な出力に関する推論を行うように構成され重み付けされた、これらの間の複数の隠れ層とを含むことができる。
【0028】
図１を参照すると、「放送局設備」１０として表記するＡＴＳＣ３．０ソースコンポーネントの例は、典型的には１対多の関係で直交周波数分割多重（ＯＦＤＭ）を介してＡＴＳＣ３．０テレビなどの複数の受信機１４にテレビデータを無線で放送するオーバージエア（ＯＴＡ）設備１２を含むことができる。１又は２以上の受信機１４は、Ｂｌｕｅｔｏｏｔｈ（登録商標）、低エネルギーＢｌｕｅｔｏｏｔｈ、その他の近距離無線通信（ＮＦＣ）プロトコル、赤外線（ＩＲ）などによって実装できる、典型的には無線である短距離リンク１８を介してリモコン装置、ヘッドフォン、タブレットコンピュータ及び携帯電話機などの１又は２以上のコンパニオンデバイス１６と通信することができる。
【0029】
また、受信機１４のうちの１つ又は２つ以上は、インターネットなどの有線及び／又は無線ネットワークリンク２０を介して放送局設備１０のオーバーザトップ（ＯＴＴ）設備２２と、典型的には１対１の関係で通信することもできる。ＯＴＡ設備１２は、ＯＴＴ設備２２と同じ位置に存在することができ、或いは放送局設備１０の両設備１２、２２は、互いに離れて適切な手段を通じて互いに通信することもできる。いずれにせよ、受信機１４は、同調したＡＴＳＣ３．０テレビチャンネルを介してＡＴＳＣ３．０テレビ信号をＯＴＡで受信することも、或いはテレビを含む関連コンテンツをＯＴＴ（ブロードバンド）で受信することもできる。なお、本明細書の全ての図において説明するコンピュータ装置は、図１及び図２の様々な装置について示すコンポーネントの一部又は全部を含むことができる。
【0030】
次に図２を参照すると、図１に示すコンポーネント例の詳細を見ることができる。図２には、ハードウェアとソフトウェアとの組み合わせによって実装できるプロトコルスタック例を示す。放送局は、図２に示す放送局側のために適宜に修正されたＡＴＳＣ３．０プロトコルスタックを使用して、（本明細書では「ブロードバンド」及び「オーバーザトップ」（ＯＴＴ）と呼ぶ）コンピュータネットワークと、（本明細書では「放送」及び「オーバージエア」（ＯＴＡ）と呼ぶ）無線放送とを介して１又は２以上の番組要素を配信するハイブリッドサービス配信を送信することができる。図２には、受信機によって具現化できるハードウェアを含む例示的なスタックも示す。
【0031】
図２を放送局設備１０の観点から開示すると、本明細書で説明するいずれかのメモリ又はストレージなどの１又は２以上のコンピュータ記憶媒体２０２にアクセスする１又は２以上のプロセッサ２００は、最上位のアプリケーション層２０４において１又は２以上のソフトウェアアプリケーションを提供するように実装することができる。アプリケーション層２０４は、ランタイム環境で動作する、例えばＨＴＭＬ５／Ｊａｖａｓｃｒｉｐｔで書かれた１又は２以上のソフトウェアアプリケーションを含むことができる。限定するわけではないが、アプリケーションスタック２０４のアプリケーションは、リニアＴＶアプリケーション、インタラクティブサービスアプリケーション、コンパニオンスクリーンアプリケーション、個人化アプリケーション、緊急アラートアプリケーション、及び使用報告アプリケーションを含むことができる。通常、アプリケーションは、ビデオコーディング、オーディオコーディング及びランタイム環境を含む、視聴者が体験する要素を表すソフトウェアで具現化される。一例として、ユーザによるダイアログの制御、代替オーディオトラックの使用、並びに正規化及びダイナミックレンジなどのオーディオパラメータの制御などを可能にするアプリケーションを提供することができる。
【0032】
アプリケーション層２０４の下位にはプレゼンテーション層２０６が存在する。プレゼンテーション層２０６は、受信機に実装された時に無線で放送されたオーディオビデオコンテンツを復号して１又は２以上のディスプレイ及びスピーカ上で再生するメディア処理ユニット（ＭＰＵ）２０８と呼ばれる放送オーディオビデオ再生装置を放送（ＯＴＡ）側に含む。ＭＰＵ２０８は、国際標準化機構（ＩＳＯ）ベースメディアファイルフォーマット（ＢＭＦＦ）データ表現２１０、及び高効率ビデオコーディング（ＨＥＶＣ）のビデオを、例えばドルビーオーディオ圧縮（ＡＣ）－４フォーマットのオーディオで提示するように構成される。ＩＳＯ ＢＭＦＦは、「セグメント」とプレゼンテーションメタデータとに分割される時間ベースのメディアファイルのための一般的ファイル構造である。基本的に、各ファイルは、それぞれがタイプ及び長さを有する一群のネスト化オブジェクト（ｎｅｓｔｅｄ ｏｂｊｅｃｔｓ）である。ＭＰＵ２０８は、暗号解読を容易にするために、放送側暗号化メディア拡張（ｅｎｃｒｙｐｔｅｄ ｍｅｄｉａ ｅｘｔｅｎｓｉｏｎ：ＥＭＥ）／共通暗号化（ｃｏｍｍｏｎ ｅｎｃｒｙｐｔｉｏｎ：ＣＥＮＣ）モジュール２１２にアクセスすることができる。
【0033】
図２には、放送側において、プレゼンテーション層２０６が、アプリケーション層２０４にアクセス可能な非リアルタイム（ＮＲＴ）コンテンツ２１８を配信するために、動画専門家集団（ＭＰＥＧ）メディア転送プロトコル（ＭＭＴＰ）シグナリングモジュール２１４、又は単方向トランスポートを介したリアルタイムオブジェクト配信（ｒｅａｌ－ｔｉｍｅ ｏｂｊｅｃｔ ｄｅｌｉｖｅｒｙ ｏｖｅｒ ｕｎｉｄｉｒｅｃｔｉｏｎａｌ ｔｒａｎｓｐｏｒｔ：ＲＯＵＴＥ）シグナリングモジュール２１６のいずれかを含むシグナリングモジュールを含むことができることをさらに示す。ＮＲＴコンテンツは、限定するわけではないが、記憶された代替広告を含むことができる。
【0034】
ブロードバンド（ＯＴＴ又はコンピュータネットワーク）側では、受信機によって実装された場合、プレゼンテーション層２０６が、インターネットからのオーディオビデオコンテンツを復号して再生するために、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を介した１又は２以上の動的適応型ストリーミング（ＤＡＳＨ）プレーヤ／デコーダ２２０を含むことができる。この目的のために、ＤＡＳＨプレーヤ２２０は、ブロードバンド側のＥＭＥ／ＣＥＮＣモジュール２２２にアクセスすることができる。ＤＡＳＨコンテンツは、ＩＳＯ／ＢＭＦＦフォーマットのＤＡＳＨセグメント２２４として提供することができる。
【0035】
プレゼンテーション層２０６のブロードバンド側は、放送側と同様に、ファイル２２６内にＮＲＴコンテンツを含むとともに、再生シグナリングを提供するシグナリングオブジェクト２２８を含むことができる。
【0036】
プロトコルスタック内のプレゼンテーション層２０６の下位にはセッション層２３０が存在する。セッション層２３０は、放送側にＭＭＴＰプロトコル２３２又はＲＯＵＴＥプロトコル２３４のいずれかを含む。なお、ＡＴＳＣ標準は、伝送にＭＰＥＧ ＭＭＴを使用するオプションを提供するが、ここには示していない。
【0037】
セッション層２３０は、ブロードバンド側にＨＴＴＰ－ｓｅｃｕｒｅ（ＨＴＴＰ（Ｓ））として実装できるＨＴＴＰプロトコル２３６を含む。セッション層２３０のブロードバンド側は、ＨＴＴＰプロキシモジュール２３８及びサービスリストテーブル（ＳＬＴ）２４０を採用することもできる。ＳＬＴ２４０は、基本サービスリストを構築して放送コンテンツのブートストラップ発見を提供するために使用されるシグナリング情報のテーブルを含む。「ＲＯＵＴＥシグナリング」テーブルには、ＲＯＵＴＥトランスポートプロトコルによってユーザデータグラムプロトコル（ＵＤＰ）を介して配信されるメディアプレゼンテーション記述（ＭＰＤ）が含まれる。
【0038】
プロトコルスタック内のセッション層２３０の下位には、低遅延かつ損失耐性のある（ｌｏｓｓ－ｔｏｌｅｒａｔｉｎｇ）接続を確立するためのトランスポート層２４２が存在する。トランスポート層２４２は、放送側ではＵＤＰ２４４を使用し、ブロードバンド側では伝送制御プロトコル（ＴＣＰ）２４６を使用する。
【0039】
図２に示す非限定的なプロトコルスタック例は、トランスポート層２４２の下位にネットワーク層２４８も含む。ネットワーク層２４８は、ＩＰパケット通信のために両方の側においてインターネットプロトコル（ＩＰ）を使用し、放送側ではマルチキャスト配信が典型的であり、ブロードバンド側ではユニキャストが典型的である。
【0040】
ネットワーク層２４８の下位には、両方の側に関連するそれぞれの物理媒体上で通信を行うための放送送信／受信設備２５２及び（単複の）コンピュータネットワークインターフェイス２５４を含む物理層２５０が存在する。物理層２５０は、インターネットプロトコル（ＩＰ）パケットを関連する媒体上での伝送に適するように変換して、受信機における誤り訂正を可能にする順方向誤り訂正機能を追加するとともに、変調及び復調機能を組み込むために変調及び復調モジュールを含むことができる。物理層２５０は、長距離送信及び帯域幅効率向上のためにビットをシンボルに変換する。物理層２５０は、通常、ＯＴＡ側には直交周波数分割多重（ＯＦＤＭ）を使用して無線でデータを放送する無線放送送信機を含み、ＯＴＴ側にはインターネットを介してデータを送信するコンピュータ送信コンポーネントを含む。
【0041】
ブロードバンド側では、プロトコルスタック内の様々なプロトコル（ＨＴＴＰ／ＴＣＰ／ＩＰ）を通じて送信されるＤＡＳＨ業界フォーラム（ＤＡＳＨ Ｉｎｄｕｓｔｒｙ Ｆｏｒｕｍ：ＤＡＳＨ－ＩＦ）プロファイルを使用することができる。ＩＳＯ ＢＭＦＦに基づくＤＡＳＨ－ＩＦプロファイル内のメディアファイルは、放送配信及びブロードバンド配信の両方のための配信、メディアカプセル化及び同期フォーマットとして使用することができる。
【0042】
通常、各受信機１４は、放送局設備のプロトコルスタックと相補的なプロトコルスタックを含む。
【0043】
図１の受信機１４は、図２に示すように、（ＴＶを制御するセットトップボックスと同等の）ＡＴＳＣ３．０ＴＶチューナ２５６を有するインターネット対応ＴＶを含むことができる。受信機１４は、Ａｎｄｒｏｉｄ（登録商標）ベースのシステムであることができる。或いは、受信機１４は、コンピュータ化されたインターネット対応（「スマート」）電話機、タブレットコンピュータ、ノートブックコンピュータ、及び仮想現実（ＶＲ）ゴーグル又はやスマートメガネなどのウェアラブルコンピュータ装置などによって実装することもできる。それにもかかわらず、本明細書で説明する受信機１４及び／又は他のコンピュータは、本原理を実施する（例えば、他の装置と通信して本原理を実施し、本明細書で説明するロジックを実行し、本明細書で説明する他のいずれかの機能及び／又は動作を実行する）ように構成されると理解されたい。
【0044】
従って、受信機１４は、このような原理を実施するために、図１に示すコンポーネントの一部又は全部によって確立することができる。例えば、受信機１４は、高精細又は超高精細「４Ｋ」又はそれ以上のフラットスクリーンによって実装されて、ディスプレイ上のタッチを介してユーザ入力信号を受け取るタッチ対応型であることも又はそうでないこともできる１又は２以上のディスプレイ２５８を含むことができる。受信機１４は、本原理に従ってオーディオを出力するための１又は２以上のスピーカ２６０と、例えば受信機１４を制御する可聴コマンドを受信機１４に入力するための、例えばオーディオ受信機／マイクなどの少なくとも１つのさらなる入力装置２６２とを含むこともできる。受信機１４の例としては、１又は２以上のプロセッサ２６６の制御下でインターネット、ＷＡＮ、ＬＡＮ、ＰＡＮなどの少なくとも１つのネットワークを介して通信するための１又は２以上のネットワークインターフェイス２６４をさらに挙げることができる。従って、インターフェイス２６４は、限定するわけではないがメッシュネットワークトランシーバなどの無線コンピュータネットワークインターフェイスの一例であるＷｉ－Ｆｉトランシーバであることができる。インターフェイス２６４は、以下に限定するわけではないが、Ｂｌｕｅｔｏｏｔｈ（登録商標）トランシーバ、Ｚｉｇｂｅｅ（登録商標）トランシーバ、赤外線通信協会（ＩｒＤＡ）トランシーバ、無線ＵＳＢトランシーバ、有線ＵＳＢ、有線ＬＡＮ、電力線又はＭｕｌｔｉｍｅｄｉａ ｏｖｅｒ Ｃｏａｘ Ａｌｌｉａｎｃｅ（ＭｏＣＡ）であることができる。プロセッサ２６６は、例えば画像の提示及び入力の受信を行うようにディスプレイ２５８を制御することなどの、本明細書で説明した受信機１４の他の要素を含めて本原理を実施するように受信機１４を制御すると理解されたい。さらに、ネットワークインターフェイス２６４は、例えば有線又は無線モデム又はルータ、或いは無線電話トランシーバ又は上述したＷｉ－Ｆｉトランシーバなどの他の適切なインターフェイスであることができる。
【0045】
上記に加えて、受信機１４は、別のＣＥ装置に（有線接続を使用して）物理的に接続するための、高精細マルチメディアインターフェイス（ＨＤＭＩ）ポート又はＵＳＢポートなどの１又は２以上の入力ポート２６８、及び／又は受信機１４にヘッドフォンを接続して受信機１４からヘッドフォンを通じてユーザにオーディオを提示するためのヘッドフォンポートを含むこともできる。例えば、入力ポート２６８は、有線又は無線を介してオーディオビデオコンテンツのケーブル又は衛星ソースに接続することができる。従って、ソースは、独立した又は統合されたセットトップボックス又は衛星受信機であることができる。或いは、ソースは、ゲーム機又はディスクプレーヤであることもできる。
【0046】
受信機１４は、いくつかの事例では受信機のシャーシ内にスタンドアロン装置として、受信機のシャーシの内部又は外部の、オーディオビデオ（ＡＶ）プログラムを再生するためのパーソナルビデオ録画装置（ＰＶＲ）又はビデオディスクプレーヤとして、或いは取り外し可能記憶媒体として具現化される、一時的信号ではないディスクベースストレージ又はソリッドステートストレージなどの１又は２以上のコンピュータメモリ２７０をさらに含むことができる。また、いくつかの実施形態では、受信機１４が、例えば少なくとも１つの衛星又は携帯電話タワーから地理的位置情報を受け取ってこの情報をプロセッサ２６６に提供し、及び／又は受信機１４がプロセッサ２６６と共に配置される高度を決定するように構成された、限定するわけではないが、携帯電話受信機、全地球測位衛星（ＧＰＳ）受信機、及び／又は高度計などの位置又は場所受信機２７２を含むことができる。しかしながら、例えば３次元全てにおいて受信機１４の位置を決定するために、本原理に従って携帯電話受信機、ＧＰＳ受信機及び／又は高度計以外の別の好適な位置受信機を使用することもできると理解されたい。
【0047】
受信機１４の説明を続けると、いくつかの実施形態では、受信機１４が、本原理に従って写真／画像及び／又はビデオを収集するために、熱探知カメラ、ウェブカメラなどのデジタルカメラ、及び／又は受信機１４に統合されてプロセッサ２６６によって制御可能なカメラのうちの１つ又は２つ以上を含むことができる１又は２以上のカメラ２７４を含むことができる。また、受信機１４には、Ｂｌｕｅｔｏｏｔｈ（登録商標）及び／又はＮＦＣ技術を使用して他の装置と通信するためのＢｌｕｅｔｏｏｔｈ（登録商標）トランシーバ２７６又は他の近距離通信（ＮＦＣ）要素をそれぞれ含めることもできる。ＮＦＣ要素例は、無線周波数識別（ＲＦＩＤ）要素であることができる。
【0048】
さらに、受信機１４は、プロセッサ２６６に入力を提供する（加速度計、ジャイロスコープ、サイクロメータ又は磁気センサ及びこれらの組み合わせなどのモーションセンサなどの）１又は２以上の補助センサ２７８、リモコン装置からＩＲコマンドを受け取るための赤外線（ＩＲ）センサ、光学センサ、速度及び／又はケイデンスセンサ、（ジェスチャコマンドを検知するための）ジェスチャセンサなどを含むこともできる。無線リモコンからコマンドを受け取るためにＩＲセンサ２８０を設けることもできる。受信機１４に電力を供給するためにバッテリ（図示せず）を設けることもできる。
【0049】
コンパニオンデバイス１６は、上述した受信機１４に関連して示した要素の一部又は全部を含むことができる。
【0050】
本明細書で説明する方法は、プロセッサ、好適に構成された特定用途向け集積回路（ＡＳＩＣ）又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）モジュール、又は当業者が理解するであろう他のいずれかの便利な方法によって実行されるソフトウェア命令として実装することができる。ソフトウェア命令は、採用する場合にはＣＤ ＲＯＭ又はフラッシュドライブなどの非一時装置に具現化することができる。或いは、ソフトウェアコード命令は、無線信号又は光信号などの一時的構成で、又はインターネットを介したダウンロードを通じて具現化することもできる。
【0051】
次に、図３に、ＡＴＳＣ３．０システムなどの単純化したデジタルＴＶシステムを示す。図３では、図１及び図２に関連して上述した関連するコンポーネントの一部又は全部を含むことができるＡＴＳＣ３．０受信機３００などの移動型又は固定型デジタルＴＶ受信機が、第１及び第２のＡＴＳＣ３．０放送局又はアセンブリ３０４間の境界領域３０２に配置されており、両放送局３０４からの信号が領域３０２内の受信機３００によって拾われる。第１の放送局３０４からは、第１のＡＴＳＣ３．０サービス（「サービスＡ」）が第１の周波数３０６で放送されるのに対し、第２の放送局３０４からは、同じサービスＡが第１の周波数３０６とは異なる第２の周波数３０８で放送される。受信機３００は両周波数を拾い、すなわち受信機３００は両放送局３０４からの信号を拾う。
【0052】
図４に、図１及び図２に関連して上述した関連するコンポーネントの一部又は全部を含むことができるＡＴＳＣ３．０受信機４００などのデジタルＴＶ受信機の非限定的な実施形態例を示す。図示の例では、ＡＴＳＣ３．０受信機４００が、例えば家庭内に配置された受信機などの固定型受信機であることができる。いくつかの例では、ＡＴＳＣ３．０受信機４００が、例えば携帯電話機に実装又は移動車両内に配置されるような移動型受信機であることができる。
【0053】
図４に示すＡＴＳＣ３．０受信機例４００は、１又は２以上のアンテナ４０６から拾い上げた信号を復調器４０４に送るチューナ４０２を含む。受信機４００は、１つのみのチューナ、１つのみの復調器、及び１つのみのアンテナを含む。
【0054】
対照的に、図５には、図１及び図２に関連して上述した関連するコンポーネントの一部又は全部を含むことができるＡＴＳＣ３．０受信機５００などのデジタルＴＶ受信機の非限定的な実施形態例を示す。図示の例では、ＡＴＳＣ３．０受信機５００が、例えば携帯電話機に実装又は移動車両内に配置されるような移動型受信機であることができる。いくつかの例では、ＡＴＳＣ３．０受信機５００が、例えば家庭内に配置された受信機などの固定型受信機であることができる。
【0055】
図５に示すＡＴＳＣ３．０受信機例５００は、１又は２以上のアンテナ５０６から拾い上げた信号をそれぞれの復調器５０４に送信する複数のチューナ５０２を含む。図示の非限定的な例では、ＡＴＳＣ３．０受信機５００が２つのチューナ及び２つの復調器を有するが、これよりも多くの又は少ない数のチューナ／復調器を有することもできると理解されたい。図示の非限定的な例では、ＡＴＳＣ３．０受信機５００が４つのアンテナを有するが、これよりも多くの又は少ない数のアンテナを有することもできると理解されたい。受信機５００は、チューナへのアンテナ入力を切り替えることができ、従って第１のチューナが３つのアンテナなどから信号を受信し、第２のチューナが第４のアンテナから信号を受信した後に、チューナ間でアンテナ入力を入れ替えるように切り替えを行うことができる。２つのアンテナが、各それぞれのチューナに入力を提供することもできる。４つのアンテナ全てから単一のチューナに入力を提供することもできる。これらの及びその他のアンテナ－チューナ構成は、必要に応じて動作中にオンザフライで変更することができる。なお、異なる構成の地上アンテナを用いたＯＴＡ信号の受信を想定しているが、受信機５００は、依然として電話、ＷＩ－ＦＩ又は衛星データサービスへのブロードバンド接続２５０を保持することもできる。
【0056】
本明細書の技術は、上記装置、システム及び構成のいずれかを使用して実装することができる。
【0057】
以下でさらに詳細に説明するように、本明細書で説明するコンテンツ修復技術は、分離されたメモリブロックに配列され区分化された複数のバッファを利用する。全ての様々なＡＴＳＣ３．０送信シナリオでは、コンテンツ及び関連するメタデータがＡＴＳＣリンク層プロトコル（ＡＬＰ）パケットを使用して送信される。例えば、バッファ１は、ＡＬＰパケットを使用して着信コンテンツ及びＵＤＰ／ＩＰコンテンツを受信する。バッファ１は物理層パイプ（ＰＬＰ）の上の層である。多くの場合は、低レベル復調器からメモリへの接続が存在して、プロセッサ２００が設定以外にそれほど関与することなくコンテンツをバッファ１内に受け取ることができる。バッファ１をモニタすることで、バッファ１がどれほど多くのデータを含んでいるかを判定して、満杯の８０％、１００％満杯又はその他の閾値などの閾値をいつデータ量が満たしたかを判定することができる。エラーを含むパケットには、各ＡＬＰパケットに関連するエラーインジケータビットを設定することによってメモリ内でフラグを立てることができる。通常は、パケットが巡回冗長検査（ＣＲＣ）に引っかかると、復調器は、このビットの受信時にビットの値を設定することができる。また、欠落パケットにはヌルパケットとしてフラグを立てることができる。バッファ１が満杯である場合又は閾値を満たす量のデータを別様に含んでいる場合、プロセッサ２００は、再生メモリなどの空きメモリへの新たなメモリポインタを使用してバッファ１を再初期化することができる。本明細書で概説する修復シナリオでは、この時点でバッファ１のメモリがバッファ２になる。通常、バッファ２は解凍エンジン（ｄｅｃｏｍｐｒｅｓｓｉｏｎ ｅｎｇｉｎｅ）にリンクすることができる。しかしながら、この場合、修復プロセスは、ＦＥＣが１又は２以上のエラーを修正できなかった結果、受け取られたデータがハードウェアチェックサム動作に引っかかったことを示すエラーインジケータビットが設定されているかどうかを確かめるために、プロセッサがバッファ２内の各パケットを確認することを必要とする。プロセッサは、修復動作が理にかなっているかどうかを判定することができる。１つのパケットのみがエラーを有する場合には、解凍時の単純な誤り隠蔽で十分な場合もある。複数のパケットがエラーを含み又は欠落している場合には、プロセッサが措置を講じることができる。放送システムでは、異なる送信システムが帯域幅を節約するためにトランスコーディングに違いがある可能性があり、従って同じコンテンツが全く同じように取り扱われるわけではないので、最も安全な方法は、欠落パケット又はエラーを有するパケット、並びにＢ－フレーム及びＰ－フレームを含む全てのパケットよりも前のイントラコード化フレーム（Ｉｎｔｒａｃｏｄｅｄ－Ｆｒａｍｅ：Ｉ－Ｆｒａｍｅ）の開始フレーム（Ｓｔａｒｔ ｏｆ Ｆｒａｍｅ：ＳＯＦ）から開始するピクチャ群のパケットをプロセッサが置き換えることである。オーディオはそれほど高度に圧縮されていない。また、必要に応じて、影響を受けたビデオパケットと共に受け取られた全てのオーディオパケットを置き換えることもできる。
【0058】
データは、コンテンツセグメントを調べて欠落又は破損したコンテンツセグメントを特定する（さらには（並行して同調できる）隣接するサービス送信から又は（放送局ブロードバンドＯＴＴサービス２２に返信する）インターネットを介してこれらを置き換えようと試みる）修復アプリケーションによって処理され、バッファ３は、解凍又は記憶エンジンに送信される準備が整った最良の修復状態のコンテンツを有するバッファである。バッファ３は、使用されるとそのポインタがゼロになり、バッファ１になって新たなコンテンツを受け入れる。従って、メモリはセグメント化されており、いくつかのアプリケーションは、タスクを行っていない隣接するメモリからロックアウトされる。実際には４つのバッファが存在することができる。バッファ３は、使用されると一時バッファであるバッファ４になり、（バッファ１の着信書き込み（ｉｎｃｏｍｉｎｇ ｗｒｉｔｅｓ）が終了すると）これがバッファ１になることができる。
【0059】
本技術は、可能な場合には同じ受信機内の別のアンテナ／復調器から、或いは放送局又はアグリゲータのウェブコンテンツ２２などのインターネットから利用可能なコンテンツから、ノイズ及び欠落パケットによるエラーを修復する。この修復は、コンテンツが継続的に受信機にストリーミングされてディスプレイ上にレンダリングされている間又はメモリ２７０に記憶されている間に行われなければならない。バッファは、修復バッファを処理して欠落したコンテンツを決定し、リモートサーバに修復データを要求して受け取り、又は第２のチューナ／復調器に接続された別のメモリからコンテンツを抽出するのに必要な時間に対応できるほど十分に大きなものとすべきである。通常、この方法は、セルラーネットワーク又は衛星ネットワークから修復データを取り出すよりも安価である。
【0060】
図６に、（ＡＳＣ３．０などの）放送デジタルＴＶコンテンツパケット６０４を受け取って処理するために、例えば図５のマルチチューナ／復調器受信機５００などの、本明細書で説明する受信機のうちのいずれかなどのデジタルＴＶ受信機内の１又は２以上のプロセッサ６０２がアクセスできる１又は２以上のメモリ６００を示す。メモリ６００は、１つの例では少なくとも３つのバッファを含み、図示の例では（図６では６０６、６０８、６１０及び６１２として表記する）４つのバッファ１～４を含む。各バッファには永続メモリレジスタが割り当てられ、第１のバッファ６０６にはレジスタ０～Ｎ－１が、第２のバッファ６０８にはレジスタＮ～Ｍ－１が、第３のバッファ６１０にはレジスタＭ～Ｐ－１が、第４のバッファ６１２にはレジスタＰ～Ｑがそれぞれ割り当てられる。それぞれのバッファのそれぞれの機能を動作させるためにプロセッサ６０２によって実行されるアプリケーションは、他のバッファのメモリアドレスに同時にアクセスすることができない。
【0061】
従って、プロセッサは、図７で説明するようなパケット受信ロジックを第１のバッファ６０６内で実行する第１のアプリケーションと、図８で説明するようなパケット修復ロジックを第２のバッファ６０８内で実行する第２のアプリケーションと、図９で説明するようなパケット読み出しロジックを第３のバッファ６１０内で実行する第３のアプリケーションとを同時に実行し、これらのアプリケーションは、他のバッファが以下でさらに説明するような適切な機能に循環するまで他のバッファにアクセスすることができない。
【0062】
第３のバッファから読み出されたデータは、最終的に本明細書におけるいずれかのディスプレイなどのディスプレイ６１６上でのコンテンツの表示のために、解凍エンジン６１４、又は記憶エンジン６１５などの他の適切な処理コンポーネントに送信することができる。
【0063】
従って、第１のアプリケーションは、第１のバッファがパケットを受け取る際に第１のバッファのメモリレジスタを割り当てられ、この時間中は第２及び第３のバッファのメモリレジスタからロックアウトすることができる。第２及び第３のアプリケーションは、この時間中に第２及び第３のバッファのメモリレジスタをそれぞれ割り当てられる。その後、第１のバッファが満杯になり、又は（満杯状態に対する高い割合、例えば満杯の９０％などの）閾値を満たすのに十分なデータを含んで第２のバッファの役割を担うと、第１のアプリケーションを第１のバッファのメモリレジスタからロックアウトして、着信パケットを受け取るために新たなバッファ（例えば、提供されている場合には第３のバッファ又は第４のバッファ）のメモリレジスタを割り当てることができる。このシフトによれば、第２のアプリケーション（エラー訂正）は、第１のバッファのメモリレジスタを割り当てられて他のバッファからロックアウトされ、第３のアプリケーション（解凍器（ｄｅｃｏｍｐｒｅｓｓｏｒ）に読み出されるデータ）は、この時点で訂正済みである第２のバッファのメモリレジスタを割り当てられて他のバッファからロックアウトされる。このアプリケーションに対するメモリレジスタ割り当てのシフトは、アプリケーション間の競合を防ぐために、コンテンツが流入して各バッファシフトが発生する度に継続する。
【0064】
図７のブロック７００から開始して、ブロードキャストデータのパケット（又はブロードキャストを介して受け取られた非パケット化コンテンツデータ）を第１のバッファに供給する。ブロック７０２において、第１のバッファが、破損データ又は欠落データなどのいずれかのエラーが検出されたかどうかを検出してシグナリングすることができる。判定区画７０４は、バッファが満杯になることなどによって閾値を満たすのに十分なデータを有するまでこのプロセスが継続することを示しており、その時点でロジックはブロック７０６に進み、第１のバッファは第２のバッファのエラー訂正機能を担い、第２のバッファはエラー訂正機能から第３のバッファの読み出し機能に循環し、第３のバッファは読み出し機能から第１のバッファの受信機能に循環する。いくつかの事例では、第３のバッファがデータの読み出しを完了する前に第１のバッファの受信機能を担う第４の「予備」バッファを設けることもできる。
【0065】
従って、図７ではＩＰアドレスに対してフィルタリングを行うことができ、受信機ハードウェアは、第１のバッファ６０６を含む特定のメモリ範囲にＡＴＳＣ３．０ ＩＰパケットを直接供給するように構成される。ハードウェアは、メモリ内に受け取られたいずれかのパケットのエラーをシグナリングする。バッファは、割り込み駆動バッファ（ｉｎｔｅｒｒｕｐｔ ｄｒｉｖｅｎ ｂｕｆｆｅｒ）又はポーリング駆動バッファ（ｐｏｌｌ ｄｒｉｖｅｎ ｂｕｆｆｅｒ）であることができる。第１のバッファ６０６は、満杯時又は閾値を満たすのに十分なデータを別様に含む時には第２のバッファ６０８としてマークされ（第２のバッファ６０８の役割を担い）、第２のバッファ６０８は第３のバッファ６１０としてマークされ（第３のバッファ６１０の役割を担い）、第３のバッファは第１のバッファ又は（提供されている場合には）第４のバッファ６１２としてマークされる。
【0066】
図８に、満杯でエラー訂正の準備が整ったバッファ上で動作する第２のアプリケーションのエラー訂正ロジックを示す。ブロック８００は、バッファがデータで満たされている時にハードウェアがエラーをシグナリングしたかどうかを識別することを示す。エラーがシグナリングされなかった場合、ロジックは終了する。一方で、エラーがシグナリングされた場合、ロジックは判定区画８０２に進み、シグナリングされたエラーについて置換用コンテンツが利用可能であるかどうかを判定する。置換用コンテンツが利用可能でない場合、ブロック８０４において、コンテンツは修正されず、解凍エンジンにその旨がシグナリングされて、解凍エンジンがコンテンツのあらゆるエラーを平滑化又は隠蔽しようと試みることができる。これに加えて又は代えて、データは、このロジックの経路に沿って図６の記憶エンジン６１５などの記憶エンジンに送信することもできる。
【0067】
一方で、置換用コンテンツが利用可能である場合、ロジックはブロック８０６に進み、ＯＴＡで受信される、処理中のものと同じサービスを伝える別の放送周波数から、或いは図３の境界領域３０２などで起こり得るように放送局から、ブロードバンドを介して置換用コンテンツをフェッチする。なお、このような重複ストリームは、図５に示すような第２のチューナ／復調器ペアを介して受信することができる。或いは、置換用コンテンツは、放送事業者又はアグリゲータのネットワークサーバからＯＴＴで取得することもできる。置換用コンテンツは、削除された破損データの適切な位置においてデータに挿入される。
【0068】
コンテンツの置換では、具体的なエラーがどのようなものであったか、どのようなデータが欠落しているか、大抵の場合そうであるように破損パケット又は欠落パケットが見つかったピクチャ群全体を置換する必要があるかどうかを識別することができる。このプロセスでは、受け取られた第２のストリーム又は放送局コンテンツキャッシュ内のピクチャ群の位置を特定する必要がある。開始フレームが位置する特定のＩＰパケットを特定してそこから開始することなどが必要な場合もある。
【0069】
ブロック８０８において、上述したアプリケーションのうちの第３のアプリケーションによって実行される図９の解凍ロジックに必要な連続メモリを作成するために、フェッチされたコンテンツと共にコンテンツブロックを移動させて追加することができる。
【0070】
実際に、図９に、ブロック９００において第３のアプリケーションが図６の解凍エンジン６１４と通信して、図８のロジックからのエラー訂正を完了したばかりのバッファのメモリレジスタ識別を解凍エンジンハードウェアに供給することを示す。ブロック９０２は、解凍及び表示又は記憶のための読み出しに新たなコンテンツが利用可能であることをアプリケーションが解凍エンジン又は記憶エンジンにシグナリングし、解凍エンジンがバッファからのデータを解凍して図６のディスプレイ６１６に提供することを示す。通常、これは「ファイア・アンド・フォーゲット（ｆｉｒｅ ａｎｄ ｆｏｒｇｅｔ）」動作である。メモリ２７０にコンテンツを書き込む動作についても同様である。
【0071】
いくつかの実施形態例を参照しながら本原理について説明したが、これらの実施形態は限定的であるように意図するものではなく、本明細書において特許請求する主題は様々な別の構成を用いて実装することもできると理解されるであろう。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【国際調査報告】