(57)【要約】  本開示は、配信するコンテンツの編集を適切に行うことができるようにするコンテンツ処理装置およびコンテンツ処理方法、並びにプログラムに関する。オンライン編集部は、ライブ配信用のコンテンツデータを編集用バッファに格納して、問題個所があった場合には編集用バッファ内で前記コンテンツデータを修正し、修正後のコンテンツデータを差し替えて配信する。オフライン編集部は、保存部からコンテンツデータを読み出して、複数の編集レベルで編集を行う。本技術は、例えば、PEG-DASHによりコンテンツを配信する配信システムに適用できる。
2018173876.tif 000002
【特許請求の範囲】
【請求項１】
ライブ配信用のコンテンツデータを編集用バッファに格納して、問題個所があった場合には前記編集用バッファ内で前記コンテンツデータを修正し、修正後のコンテンツデータを差し替えて配信するオンライン編集部
を備えるコンテンツ処理装置。
【請求項２】
前記オンライン編集部により修正が施された前記コンテンツデータを保存する保存部と、
前記保存部から前記コンテンツデータを読み出して、複数の編集レベルで編集を行うオフライン編集部と
をさらに備える請求項１に記載のコンテンツ処理装置。
【請求項３】
前記コンテンツデータを所定のセグメントごとにエンコードし、コンテンツの配信の制御に用いられる制御情報を生成するエンコード処理部
をさらに備え、
前記エンコード処理部は、前記オンライン編集部により編集された前記コンテンツデータ、または、前記オフライン編集部により編集された前記コンテンツデータを、前記制御情報を書き換えることにより前記セグメント単位で置換する
請求項２に記載のコンテンツ処理装置。
【請求項４】
前記オフライン編集部は、前記コンテンツデータに対して部分ごとに段階的に編集を行い、前記コンテンツデータのライブ配信からの時間の経過に応じて、より高度な編集レベルの編集を行う
請求項３に記載のコンテンツ処理装置。
【請求項５】
前記エンコード処理部は、前記オフライン編集部により前記コンテンツデータに対する編集が行われると、その編集が行われた部分をセグメントごとに順次置き換える
請求項４に記載のコンテンツ処理装置。
【請求項６】
前記オフライン編集部により編集された前記コンテンツデータを前記セグメントごとに置き換えるのに用いる前記制御情報が、SAND（Server and Network Assisted DASH）の拡張によって、DASH（Dynamic Adaptive Streaming over HTTP）配信サーバからCDN（Content Delivery Network）サーバに伝達される
請求項３に記載のコンテンツ処理装置。
【請求項７】
前記CDNサーバに配置された前記コンテンツデータのうち、前記オフライン編集部により編集された部分の置換情報が前記CDNサーバに通知される
請求項６に記載のコンテンツ処理装置。
【請求項８】
ライブ配信用のコンテンツデータを編集用バッファに格納して、問題個所があった場合には前記編集用バッファ内で前記コンテンツデータを修正し、修正後のコンテンツデータを差し替えて配信する
ステップを含むコンテンツ処理方法。
【請求項９】
ライブ配信用のコンテンツデータを編集用バッファに格納して、問題個所があった場合には前記編集用バッファ内で前記コンテンツデータを修正し、修正後のコンテンツデータを差し替えて配信する
ステップを含むコンテンツ処理をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コンテンツ処理装置およびコンテンツ処理方法、並びにプログラムに関し、特に、配信するコンテンツの編集を適切に行うことができるようにしたコンテンツ処理装置およびコンテンツ処理方法、並びにプログラムに関する。
【背景技術】
【０００２】
IPTV（Internet Protocol Television）等のインターネットストリーミングにおける標準化の流れとして、HTTP（Hypertext Transfer Protocol）ストリーミングによるVOD（Video On Demand）ストリーミングや、ライブストリーミングに適用される方式の標準化が行われている。【０００３】
特に、ISO/IEC/MPEGで標準化が行われているMPEG-DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP)が注目されている（例えば、非特許文献１参照）。【０００４】
ところで、従来、音楽コンサートやスポーツなどのイベントをMPEG DASHを用いたライブストリーミングで配信したのち、同じ映像データをオンデマンド配信することが行われている。このとき、オンデマンド配信に際しては、出演者や主催者等の意向によって一部のデータをライブ配信時のものと差し替える場合がある。【０００５】
例えば、音楽アーティストの公演などの生中継による放送が行われるとともに、後日それがDVDやBlu-ray Discのようなパッケージメディアとして販売されることがある。しかし、そのような場合であっても放送とパッケージメディア向けのコンテンツ制作は別々に行われることが多く、放送で流された映像および音声がそのままパッケージメディアとして販売されるわけではない。その理由として、パッケージメディアはそれ自体がアーティストの作品であるためその品質に対する要求が高く、生収録の映像や音声をそのまま用いるだけでなく、様々な編集や加工を施す必要があるからである。【０００６】
一方で、最近ではインターネット等を経由したDASHストリーミングを用いてライブ配信を行い、その同じコンテンツをストリーミング開始から一定の時間が経過した後、または、ストリーミング終了後にオンデマンド配信によって提供することが行われるようになった。なお、実際にライブ収録またはキャプチャされたものだけでなく、放送局などからのフィードをリアルタイムでDASHセグメント化したものである場合もある。【０００７】
例えば、ライブ（リアルタイム）配信を見逃したユーザに向けたキャッチアップ視聴サービスや、クラウドでの録画に相当するサービスなどである。例えば、後者は、一般にnPVR（Network Personal Video Recorder）と呼ばれることがある。【０００８】
音楽アーティストの公演もこれと同じようにDASHストリーミングによるライブ配信を行い、これを随時オンデマンド化することが考えられるが、前述のパッケージメディアに相当する、長期間にわたって視聴可能なコンテンツとしてライブ配信時のものをそのまま使用することに対してはアーティストの許諾が得られない場合がある。そうなると、従来の生放送とパッケージメディアのようにそれぞれを別のコンテンツとして制作することとなり、ライブ配信のために配信サーバに配置されＣＤＮ内にいきわたったデータはライブ配信期間を過ぎれば無用のデータとなり、変わってオンデマンド配信用の別のデータをサーバに配置およびＣＤＮで流通させなければならない。【０００９】
実際には、ライブ配信時とオンデマンド配信用のコンテンツの全ての時間において内容（映像、音声）が異なるわけではなく重複する内容（映像、音声）があるはずであるが、その分も含めて配信サーバへのアップロードやＣＤＮのキャッシュへの配送を重ねて行うことになり、その分の通信コストが発生してしまう。【００１０】
また、最終的なオンデマンド配信向けの作品（パッケージメディアとして販売するレベル）に仕上げるための編集・調整・加工にはそれなりの時間がかかり、ライブ配信終了からオンデマンド配信での提供までの間隔が長くなってしまう。
【先行技術文献】
【特許文献】
【００１１】
【非特許文献１】ISO/IEC 23009-1:2012 Information technology Dynamic adaptive streaming over HTTP (DASH)
【非特許文献２】FDIS ISO/IEC 23009-5: 201x Server and Network Assisted DASH (SAND)
【発明の概要】
【発明が解決しようとする課題】
【００１２】
上述したように、従来、コンテンツの編集に時間がかかっていたため、配信するコンテンツの編集を適切に行えるようにすることが求められている。【００１３】
本開示は、このような状況に鑑みてなされたものであり、配信するコンテンツの編集を適切に行うことができるようにするものである。
【課題を解決するための手段】
【００１４】
本開示の一側面のコンテンツ処理装置は、ライブ配信用のコンテンツデータを編集用バッファに格納して、問題個所があった場合には前記編集用バッファ内で前記コンテンツデータを修正し、修正後のコンテンツデータを差し替えて配信するオンライン編集部を備える。【００１５】
本開示の一側面のコンテンツ処理方法またはプログラムは、ライブ配信用のコンテンツデータを編集用バッファに格納して、問題個所があった場合には前記編集用バッファ内で前記コンテンツデータを修正し、修正後のコンテンツデータを差し替えて配信するステップを含む。【００１６】
本開示の一側面においては、ライブ配信用のコンテンツデータを編集用バッファに格納して、問題個所があった場合には編集用バッファ内でコンテンツデータを修正し、修正後のコンテンツデータが差し替えられて配信される。
【発明の効果】
【００１７】
本開示の一側面によれば、配信するコンテンツの編集を適切に行うことができる。
【図面の簡単な説明】
【００１８】
【図１】本技術を適用したコンテンツ配信システムの一実施の形態の構成例を示すブロック図である。
【図２】ライブ配信データの生成から、DASH配信サーバへのアップロードまでの処理について説明する図である。
【図３】セグメント単位での置換を説明する図である。
【図４】オフライン編集を行う処理について説明する図である。
【図５】ライブ配信時のMPDの一例を示す図である。
【図６】ライブ配信時のMPDに対して置換するセグメントの情報を付加したMPDの一例を示す図である。
【図７】MPDの一例を示す図である。
【図８】セグメントを置換したMPDの一例を示す図である。
【図９】SegmentTimeline elementの例を示す図である。
【図１０】AlteredSegmentTimelineの例を示す図である。
【図１１】SegmentTimelineの例を示す図である。
【図１２】置換告知SANDメッセージの概念を説明する図である。
【図１３】SANDメッセージの例を示す図である。
【図１４】ResourceStatusエレメントの定義例を示す図である。
【図１５】ビデオ自動処理およびオーディオ自動処理について説明する図である。
【図１６】修正のレベルについて説明する図である。
【図１７】DASHクライアント部の構成例を示すブロック図である。
【図１８】ライブ配信処理を説明するフローチャートである。
【図１９】ビデオ自動処理を説明するフローチャートである。
【図２０】オーディオ自動処理を説明するフローチャートである。
【図２１】DASHクライアント処理を説明するフローチャートである。
【図２２】オフライン編集処理を説明するフローチャートである。
【図２３】置換データ生成処理を説明するフローチャートである。
【図２４】本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
【発明を実施するための形態】
【００１９】
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
【００２０】
＜コンテンツ配信システムの構成例＞
【００２１】
図１は、本技術を適用したコンテンツ配信システムの一実施の形態の構成例を示すブロック図である。
【００２２】
図１に示すように、コンテンツ配信システム１１は、撮影装置１２−１乃至１２−３、収音装置１３−１乃至１３−３、ビデオオンライン編集部１４、オーディオオンライン編集部１５、エンコードDASH処理部１６、DASH配信サーバ１７、ビデオ保存部１８、ビデオオフライン編集部１９、オーディオ保存部２０、オーディオオフライン編集部２１、および、DASHクライアント部２２を備えて構成される。また、コンテンツ配信システム１１では、DASH配信サーバ１７およびDASHクライアント部２２が、インターネットなどのネットワーク２３を介して接続されている。
【００２３】
例えば、コンテンツ配信システム１１においてライブ配信（放送）を行うときには、複数台の撮影装置１２および収音装置１３（図１の例では３台ずつ）が使用され、様々な方向からライブの様子が撮影および収音される。
【００２４】
撮影装置１２−１乃至１２−３は、例えば、映像を撮影可能なデジタルビデオカメラにより構成され、それぞれライブの映像を撮影して、それらの映像をビデオオンライン編集部１４およびビデオ保存部１８に供給する。
【００２５】
収音装置１３−１乃至１３−３は、例えば、音声を収音可能なマイクロフォンにより構成され、それぞれライブの音声をそれぞれ収音して、それらの音声をオーディオオンライン編集部１５に供給する。
【００２６】
ビデオオンライン編集部１４は、撮影装置１２−１乃至１２−３それぞれから供給される映像に対し、スイッチャやミキサーによって選択や混合を行い、さらには各種のエフェクト（効果）なども加える。また、ビデオオンライン編集部１４は、ビデオ自動処理部３１を有しており、ビデオ自動処理部３１により、撮影装置１２−１乃至１２−３による撮影後のRAWデータに修正を加えることができる。そして、ビデオオンライン編集部１４は、そのような編集を適用して配信用の映像ストリームを生成し、エンコードDASH処理部１６に出力するとともに、ビデオ保存部１８に供給して保存させる。
【００２７】
オーディオオンライン編集部１５は、収音装置１３−１乃至１３−３それぞれから供給される音声に対し、スイッチャやミキサーによって選択や混合を行い、さらには各種のエフェクト（効果）なども加える。また、オーディオオンライン編集部１５は、オーディオ自動処理部３２を有しており、オーディオ自動処理部３２により、収音装置１３−１乃至１３−３による収音後の音声データに修正を加えることができる。そして、オーディオオンライン編集部１５は、そのような編集を適用して配信用の音声ストリームを生成し、エンコードDASH処理部１６に出力するとともに、オーディオ保存部２０に供給して保存させる。
【００２８】
エンコードDASH処理部１６は、ビデオオンライン編集部１４から出力される配信用の映像ストリーム、および、オーディオオンライン編集部１５から出力される配信用の音声ストリームを、必要に応じて複数のビットレートでエンコードする。これにより、エンコードDASH処理部１６は、配信用の映像ストリームおよび配信用の音声ストリームをDASH media segment化して、DASH配信サーバ１７に随時アップロードする。このとき、エンコードDASH処理部１６は、映像および音声の配信の制御に用いられる制御情報として、MPD（Media Presentation Description）データを生成する。また、エンコードDASH処理部１６は、セグメント管理部３３を有しており、セグメント管理部３３は、データの欠落などを監視し、問題がある場合にはMPDに反映させたり、図３を参照して後述するように、セグメント単位でデータを置換することができる。
【００２９】
DASH配信サーバ１７は、セグメントデータおよびMPDデータがアップロードされ、DASHクライアント部２２とネットワーク２３を介してHTTP通信を行う。
【００３０】
ビデオ保存部１８は、後の編集および制作のために、配信用の映像ストリームを保存する。また、ビデオ保存部１８には、ライブ配信向けの元ストリームも同時に保存される。さらに、ビデオ保存部１８には、ライブ配信向けストリームに選択および使用された映像の情報（カメラ番号など）も記録しておく。
【００３１】
ビデオオフライン編集部１９は、オンデマンド配信のためのストリームを、ビデオ保存部１８に保存されたライブ配信向けストリームをベースとして制作する。ビデオオフライン編集部１９が行う編集内容は、例えば、一部をライブ配信時とは異なるアングルから撮影されたカメラの映像に差し替えたり、複数のカメラからの映像を合成したり、カメラ（映像）の切り替え時に追加のエフェクト処理を行ったりするものである。
【００３２】
オーディオ保存部２０は、配信用の音声ストリームを保存する。
【００３３】
オーディオオフライン編集部２１は、オーディオ保存部２０に保存された配信用の音声ストリームを編集する。例えば、オーディオオフライン編集部２１が行う編集内容は、音声の乱れた部分を別途録音したものと差し替えたり、ライブ時にはなかった音を加えたり、エフェクト処理を加えたりするものである。
【００３４】
DASHクライアント部２２は、DASH配信サーバ１７からネットワーク２３を介して配信されるDASHコンテンツをデコードして再生し、DASHクライアント部２２のユーザに視聴させる。なお、DASHクライアント部２２の具体的な構成については、図１７を参照して後述する。
【００３５】
図２を参照して、ライブ配信データの生成から、DASH配信サーバ１７へのアップロードまでの処理について説明する。
【００３６】
例えば、複数の撮影装置１２からビデオオンライン編集部１４に映像が入力されるともに、複数の収音装置１３からオーディオオンライン編集部１５に音声が入力され、それらの映像および音声に対してスイッチングやエフェクトなどの処理が施されライブ配信用の映像・音声ストリームとして出力される。映像・音声ストリームは、エンコードDASH処理部１６に供給されるとともに、ビデオ保存部１８およびオーディオ保存部２０に保存される。また、カメラ選択情報もビデオ保存部１８に保存される。
【００３７】
エンコードDASH処理部１６は、映像・音声ストリームを符号化してDASHデータを生成し、セグメントごとにISOBMFF Segment化して、DASH配信サーバ１７へアップロードする。また、エンコードDASH処理部１６は、Live MPDを生成して、Segment Timecode情報として出力する。そして、DASH配信サーバ１７では、Live用のMPDに従って、セグメントごとに配信が制御される。
【００３８】
このとき、エンコードDASH処理部１６は、DASH化されたセグメントファイルを参照し、問題個所があればMPDを書き換えることにより、符号化されたデータをセグメント単位で置換することができる。
【００３９】
例えば、図３に示すように、ライブ用に、セグメント＃１、セグメント＃２、およびセグメント＃３を配信し、セグメント＃２で事故が発生した場合には、そのセグメント＃２が、他のセグメント＃２’に置換される。
【００４０】
図４を参照して、オフライン編集を行う処理について説明する。
【００４１】
例えば、ライブ配信向けストリームから、編集・調整を加えた部分の置換用メディア・セグメントを生成してオンデマンド配信用のDASHストリーム・データを構成することができる。なお、オフライン編集は、ライブ配信終了後にその緊急度、重要性、あるいはコンテンツ付加価値の向上等のために複数回行われることがある。例えば、オフライン編集により、映像・音声ストリームに対して部分ごとに段階的に編集が行われ、ライブ配信からの時間の経過に応じて、より高度な編集レベルの編集が行われるようにしてもよい。
【００４２】
例えば、複数の撮影装置１２により撮影された映像がビデオ保存部１８からビデオオフライン編集部１９に読み出されるとともに、複数の収音装置１３により収音された音声がオーディオ保存部２０からオーディオオフライン編集部２１に読み出される。そして、ビデオオフライン編集部１９およびオーディオオフライン編集部２１では、編集区間指定UI（User Interface）を利用して編集区間が指定され、Segment Timecode情報およびカメラ選択情報を参照して、編集区間が調整される。そして、その編集が施された映像および音声が、置換用ストリームとして出力される。
【００４３】
エンコードDASH処理部１６は、置換用ストリームを符号化してDASHデータを生成するとともに、MPDを書き換えて置換適用MPDを生成し、DASH配信サーバ１７へアップロードする。そして、DASH配信サーバ１７では、置換用のMPDに従って、セグメントごとに置換して配信が制御される。例えば、エンコードDASH処理部１６は、ビデオオフライン編集部１９およびオーディオオフライン編集部２１により編集が行われると、その編集が行われた部分をセグメントごとに、順次置き換える。これにより、DASH配信サーバ１７は、編集が行われた部分を順次置き換えながら配信することができる。
【００４４】
＜MPDによるセグメントの置換＞
図５には、ライブ配信時のMPDの一例が示されており、図６には、ライブ配信時のMPDに対して置換するセグメントの情報を付加したMPDの一例が示されている。
【００４５】
図５に示すように、通常、ライブ配信時には、Segment Templateを用いAdaptation Setおよびそれに含まれるRepresentationは、Base URL、Segment Template、およびSegment Timelineを用いて表現される。なお、図５には、Videoの例が示されている。
【００４６】
例えば、SegmentTemplate の timescale 属性の値が 90000 であり、AdaptationSet の frameRate の値が 30000/1001 = 29.97 frame per second (fps) である。図５に示す例では、SegmentTimeline で指定されている duration="180180" ということで、各セグメントは 180180/90000=2.002 秒分、これは 60 frameに相当する時間となる。
【００４７】
ここで、各セグメントの URL は Period 直下の Base URL と Adaptation Set レベルの Base URLを結合したものに、Segment Template の $Time$ を Segment Timeline の S elementから算出される先頭からの経過時間に置き換え $Bandwidth$を各Representationに与えられた bandwidth アトリビュートの値（文字列）に置き換えたものをさらに結合することで得られる。例えば、id="v0" のRepresentationの5番目のセグメントの URL は http://cdn1.example.com/video/250000/720720.mp4v となる。(720720 = 180180 * 4; 最初のセグメントのfile名は "0.mp4v")
【００４８】
ここに、置換するセグメントの情報を付加するが、それには SegmentTemplate エレメントの子エレメントとして AlteredSegmentTimeline エレメントを定義する。これにより、図７のMPDは、図８に示すように表現することができる。この例は、123番目から 179番目までの 57個の Segment を置き換えた場合となる。
【００４９】
また、AlteredSegmentTimeline エレメントの定義は、図９に示す以下の通りである。
【００５０】
これにより、クライアントは 123番目から179番目まで57個のセグメントについてはURL生成のBaseURL（Adaptation Setレベル）として "video2/" を用い、当初ライブ配信向けに用意されたセグメントではなく、オフライン編集後に生成された置換すべきセグメントを取得して再生する。
【００５１】
例えば、123番目の置換後のSegmentのURLは、180180×122＝21981960と求められるため、http://cdn1.example.com/video2/250000/21981960.mp4vとなる。
【００５２】
なお、置換後のセグメントについて、各セグメントの長さは置換前のセグメントとまったく同一である必要はなく、セグメント毎に異なる値にすることができる。例えば、映像の特性に応じたエンコードのために一部分についてDASHにおいてSAP（Stream Access Point、segment の先頭は SAP である必要がある）と呼ばれるピクチャ・タイプの間隔を変更したいという場合が考えられる。ただし、その場合であっても一連の置換されるセグメントの数と合計の長さ(duration)は、置換前のものと一致させる必要がある。
【００５３】
例えば、図８に示したように、合計５７個のセグメントを置換する場合で、中間部に SAPの間隔を狭めた部分が必要となった場合、その間隔を狭めた一つまたは複数のセグメントの分だけ、他のセグメントのdurationを調整しなければならない。その結果、図１０に示すように複数のAltSエレメントを用いて置換セグメントの列が表現される。
【００５４】
図１０に示す例では、123番目〜126番目までと132番目から179番目までのセグメントは置換前のsegmentと同じdurationを持ち、127番目〜129番目は置換前の半分の長さ、130番目〜132番目は置換前のセグメントの1.5倍の長さに調整している。
【００５５】
なお、置換セグメントの提供後に元のセグメントをサーバから削除する場合には、AlteredSegmentTimelineを正しく解釈した場合にしか正しくストリーム再生することができないため、それを表現するためにAlteredSegmentTimelineエレメントが使用されていることを示すためにschemeIdUri="urn:mpeg:dash:altsegment:20xx"のEssential Property DescriptorをAdaptation Setレベルに付加する。
【００５６】
また、AlteredSegmentTimelineエレメントを新たに定義するかわりに、既存のSegmentTimelineエレメントに@altBaseUrlアトリビュートを追加定義することによっても、SegmentTimelineで表現されたうちの一部のセグメントについて、AdaptationSetまたはRepresentationに与えられたBaseURLを置き換え後のものに変更することも可能である。
【００５７】
図１１には、その場合におけるSegmentTimeline elementの例が示されている。図１１に示すように、123番目から179番目まで57個のセグメントについてURL生成のBaseURL（Adaptation Setレベル）として"video2/"が適用されている。
【００５８】
次に、オフライン編集によって作成されたセグメントによって置き換えられるセグメントの情報（MPD）を次のMPEG規格（SAND）の拡張によってDASH配信サーバからCDNサーバに伝達する方法（例えば、非特許文献２参照）を説明する。
【００５９】
図１２は、DASH配信サーバ１７からCDN（cache）サーバ２４を経由してMPDおよびMedia SegmentがDASHクライアント部２２に伝達される概念を示すブロック図である。
【００６０】
MPEG SAND規格は、DASH配信サーバ１７とCDNサーバ２４またはDASHクライアント部２２との間のメッセージ交換により、データの配信を効率化する目的で定められたものである。この中でDASH配信サーバ１７とCDNサーバ２４の間でやり取りされるメッセージはPED（Parameter Enhancing Delivery）メッセージと呼ばれ、本実施の形態におけるセグメント置換通知の伝達は、このPEDメッセージの一つとなる。
【００６１】
なお、現状、MPEG規格ではPEDメッセージはアーキテクチャ上言及されているのみで、具体的なメッセージは定義されていない。また、PEDメッセージを送受信する DASH配信サーバ１７やCDNサーバ２４はSAND規格においてDASH Aware Network Element (DANE)と称される。
【００６２】
DANE間におけるSAND Messageのやり取りは、以下の２通りの方法がSAND規格に規定されている。
【００６３】
第１の方法は、上流のDANEに対する下流DANEからの例えばMedia Segment取得のためのHTTP GET requestに対するresponseに、SAND Message取得のためのURLを記載した拡張HTTP headerを付加し、それを受信した下流DANEが当該URLにHTTP GET requestを送信して、SAND Messageを取得する方法である。
【００６４】
第２の方法は、DANE間で予めSAND message交換のためのWebSocketチャネルを確立しておき、そのチャネルを使ってメッセージを送る方法である。
【００６５】
本実施の形態では、これらの２通りの方法のどちらを使っても目的を達成することができる。但し、第１の方法では、メッセージの伝達先がMedia Segmentの取得リクエストを送付してきた場合に限られるため、第２の方法によりメッセージを送ることが望ましい。もちろん、第１の方法によりメッセージを送っても、一定の範囲で効果を得ることができる。なお、いずれの場合も、SAND Message自体はXML文書で記述されることが想定されており、具体的には、図１３に示すように表現することができる。
【００６６】
ここで、図１３に示されている<CommonEnvelope>には、attributeとしてsenderID，generationTimeを付加することができる。例えば、messageIdの値は、SAND Messageの種別を表すが、ここでは規格に未定義の新たなメッセージのため"reserved for future ISO use"とされている値とした。
【００６７】
また、ResourceStatus エレメントの定義例は、図１４に示す通りである。
【００６８】
図１５を参照して、ビデオ自動処理およびオーディオ自動処理について説明する。
【００６９】
例えば、ビデオオンライン編集部１４では、ビデオ自動処理部３１により、撮影装置１２−１乃至１２−３による撮影後のRAWデータに修正を加えることができる。同様に、オーディオオンライン編集部１５では、オーディオ自動処理部３２により、収音装置１３−１乃至１３−３による収音後のPCMデータに修正を加えることができる。
【００７０】
ビデオ自動処理部３１は、映像データをビデオフレームバッファに一時的に格納し、フレームバッファ内の映像データに問題個所、例えば、撮影時の異常映像ノイズや映像ディレクタが不適切であると指摘するNGシーンなどがないか検出する。そして、ビデオ自動処理部３１は、問題個所があった場合には、その問題個所の映像データを、塗りつぶしたり、ぼかしたりして修正する。その後、ビデオ自動処理部３１は、問題データを修正データで差し替えて上書きする。また、ビデオ自動処理部３１は、このような処理を、配信遅延の範囲内の時間で行うことができる。
【００７１】
オーディオ自動処理部３２は、オーディオデータをオーディオサンプルバッファに一時的に格納し、オーディオサンプルバッファ内のオーディオデータに問題個所、例えば、異常音や音程ズレなどがないか検出する。そして、オーディオ自動処理部３２は、問題個所があった場合には、その問題個所のオーディオデータを、異常音除去したり音程調整したりして修正する。その後、オーディオ自動処理部３２は、問題データを修正データで差し替えて上書きする。また、オーディオ自動処理部３２は、このような処理を、配信遅延の範囲内の時間で行うことができる。
【００７２】
図１６を参照して、編集のレベルについて説明する。
【００７３】
まず、ライブ配信では、図１５を参照して説明したように、ビデオ自動処理部３１およびオーディオ自動処理部３２により自動修正が行われ、ライブにおけるNG部分が応急処置される。
【００７４】
例えば、ライブ配信においても、アーティストやコンテンツプロバイダの意向に沿ったデータ加工が可能となる。そして、ライブ配信後、段階的にコンテンツがアップデートされ、最終的にビデオオンデマンド配信に至る。これにより、視聴者は時間的な間隔を空けず、随時、その時点で更新されたコンテンツのストリーミング視聴が可能となる。
【００７５】
段階的なコンテンツアップデートにより、コンテンツの質を高め、機能を拡充できる。視聴者はより洗練されたコンテンツ視聴が可能となる。例えば、単視点から多視点となり、様々なアングルを楽しめる。段階的なコンテンツアップデートにより、段階的な課金モデルを構築することができる。
【００７６】
つまり、ライブ配信、レベル１〜レベル３の配信、およびオンデマンド配信と、コンテンツ価値を増大させることで、それぞれに適した価格設定を行うことができる。
【００７７】
ここで、ライブ配信において、自動修正含む配信コンテンツは、「アーティストや映像ディレクターが不適切であるとNG指摘する部分の応急処置版」と定義する。ビデオ自動処理は、不適切な映像の「塗りつぶし」や「ぼかし」に対応し、カメラ映像切り替えを行うことができる。オーディオ自動処理は、マイクからの異常音に対する処理や、音程ずれの対応を行うことができる。また、それらの処理に要する時間は、数秒程度であり、配信対象者は、ライブ視聴を申請および登録した人とする。
【００７８】
また、レベル１の配信において、配信コンテンツは、「ライブのNG部分の簡易修正版」と定義し、例えば、ライブ参加者や視聴者限定のサービスとする。ビデオ・オーディオ処理は、アーティストや映像ディレクターNG部分のみの簡易修正であり、視聴視点数は単視点とし、配信対象者は、ライブに参加し、もう一度すぐに視聴したい人、ライブ配信を視聴した人とする。また、配信時期は、ライブから数日後とすることができる。
【００７９】
また、レベル２の配信において、配信コンテンツは、「NG部分の修正版、および２視点対応版」と定義する。例えば、ここからはオンデマンドに向けての作りこみが前提となる。ビデオ・オーディオ処理は、アーティストや映像ディレクターNG部分の修正版であり、視聴視点数は2視点とし、ユーザはアングルの選択が可能である。また、配信対象者は、アーティストのファンでライブパフォーマンスを楽しみたい人とする。また、配信時期は、ライブ２週間後とすることができる。
【００８０】
また、レベル３の配信において、配信コンテンツは、「NG部分の完全版、および多視点対応版」と定義する。即ち、作りこみの最終前である。ビデオ・オーディオ処理は、アーティストや映像ディレクターNG部分の完全修正、人物、肌処理も施される。視聴視点数は3視点とし、ユーザはアングルの選択が可能である。また、配信対象者は、アーティストのファンでライブパフォーマンスを楽しみたい人や、オンデマンドよりも早く視聴したい人などであり、配信時期は、ライブ4週間後とすることができる。
【００８１】
また、オンデマンド配信において、配信コンテンツは、「アーティストや映像ディレクターの意向に沿った最終作品」と定義する。即ち、作りこみの最終版となる。ビデオ・オーディオ処理は、映像と音声は全編処理が施され、メインコンテンツ以外にボーナスコンテンツもある。視聴視点数は多視点とし、３視点以上とすることが好ましく、ユーザーはユーザインタフェースを使ってアングルを選択することができる。また、配信対象者は、アーティストのファンをはじめ、音楽好きな人全般、作品として楽しみたい人などであり、配信時期は、ライブ数か月後とすることができる。
【００８２】
図１７は、DASHクライアント部２２の構成例を示すブロック図である。
【００８３】
図１７に示すように、DASHクライアント部２２は、データストレージ４１、DEMUX部４２、ビデオデコード部４３、オーディオデコード部４４、ビデオ再生部４５、およびオーディオ再生部４６を備えて構成される。そして、DASHクライアント部２２は、図１のネットワーク２３を介してDASH配信サーバ１７からセグメントデータおよびMPDデータを受け取ることができる。
【００８４】
データストレージ４１は、DASHクライアント部２２がDASH配信サーバ１７から受け取ったセグメントデータおよびMPDデータを一時的に保持する。
【００８５】
DEMUX部４２は、データストレージ４１から読み出したセグメントデータを、デコードするために分離して、ビデオデータをビデオデコード部４３に供給し、オーディオデータをオーディオデコード部４４に供給する。
【００８６】
ビデオデコード部４３は、ビデオデータのデコードを行ってビデオ再生部４５に供給する。オーディオデコード部４４は、オーディオデータのデコードを行ってオーディオ再生部４６に供給する。
【００８７】
ビデオ再生部４５は、例えばディスプレイであり、デコードされた映像を再生して映し出す。オーディオ再生部４６は、例えばスピーカであり、デコードされた音声を再生して出力する。
【００８８】
図１８は、コンテンツ配信システム１１で実行されるライブ配信処理を説明するフローチャートである。
【００８９】
ステップＳ１１において、ビデオオンライン編集部１４は、撮影装置１２により撮影された映像を取得し、オーディオオンライン編集部１５は、収音装置１３により収音された音声を取得する。
【００９０】
ステップＳ１２において、ビデオオンライン編集部１４は、映像に対するオンライン編集を行い、オーディオオンライン編集部１５は、音声に対するオンライン編集を行う。
【００９１】
ステップＳ１３において、ビデオオンライン編集部１４は、オンライン編集を行った映像をビデオ保存部１８に供給して保存し、オーディオオンライン編集部１５は、オンライン編集を行った音声をオーディオ保存部２０に供給して保存する。
【００９２】
ステップＳ１４において、ビデオ自動処理部３１およびオーディオ自動処理部３２は、自動処理が必要か否かを判定する。
【００９３】
ステップＳ１４において、ビデオ自動処理部３１およびオーディオ自動処理部３２が、自動処理が必要であると判定した場合、処理はステップＳ１５に進んで自動処理が行われる。そして、自動処理の処理後、処理はステップＳ１２に戻り、以下、同様の処理が繰り返される。
【００９４】
一方、ステップＳ１４において、ビデオ自動処理部３１およびオーディオ自動処理部３２が、自動処理が必要でないと判定した場合、処理はステップＳ１６に進む。ステップＳ１６において、エンコードDASH処理部１６は、映像・音声ストリームを符号化してDASHデータを生成し、セグメントごとにISOBMFF Segment化する。
【００９５】
ステップＳ１７において、エンコードDASH処理部１６は、ステップＳ１６でセグメントごとにISOBMFF Segment化したDASHデータを、DASH配信サーバ１７にアップロードする。
【００９６】
ステップＳ１８において、配信を終了するか否かが判定され、配信を終了しないと判定された場合、処理はステップＳ１１に戻り、以下、同様の処理が繰り返される。一方、ステップＳ１８において、配信を終了すると判定された場合、ライブ配信処理は終了される。
【００９７】
図１９は、図１８のステップＳ１５において実行されるビデオ自動処理を説明するフローチャートである。
【００９８】
ステップＳ２１において、ビデオ自動処理部３１は、映像データをフレームバッファに格納する。例えば、リアルタイムで撮影装置１２により撮影されている映像信号が、ＶＥを通して、ビデオフレームのグループでバッファに格納される。
【００９９】
ステップＳ２２において、ビデオ自動処理部３１は、問題データが検出されたか否かを判定する。例えば、フレームバッファ内の映像データを参照し、異常映像ノイズや不適切なシーンが映り込んでいないかを検出する。そして、ステップＳ２２において、問題データが検出されたと判定された場合、処理はステップＳ２３に進む。
【０１００】
ステップＳ２３において、ビデオ自動処理部３１は、問題データを特定する。例えば、ビデオ自動処理部３１は、問題個所の映像エリア、対象画素や区間を特定する。
【０１０１】
ステップＳ２４において、ビデオ自動処理部３１は、問題データをバッファに格納し、ステップＳ２５において、バッファ内でデータを修正する。例えば、問題映像エリアを塗りつぶしたり、ぼかしを入れたりする修正が行われる。
【０１０２】
ステップＳ２６において、ビデオ自動処理部３１は、問題のあるオリジナルのデータに、ステップＳ２５で修正した修正済みのデータで上書きして、データを差し替えた後、ビデオ自動処理は終了される。
【０１０３】
図２０は、図１８のステップＳ１５において実行されるオーディオ自動処理を説明するフローチャートである。
【０１０４】
ステップＳ３１において、オーディオ自動処理部３２は、オーディオデータをオーディオサンプルバッファに格納する。例えば、リアルタイムで収音装置１３により収音されているPCMオーディオがPAを通して、オーディオサンプルのグループでバッファに格納される。
【０１０５】
ステップＳ３２において、オーディオ自動処理部３２は、問題データが検出されたか否かを判定する。例えば、オーディオサンプルバッファ内のオーディオデータの波形をチェックし、異常音や音程ズレを検出する。そして、ステップＳ３２において、問題データが検出されたと判定された場合、処理はステップＳ３３に進む。
【０１０６】
ステップＳ３３において、オーディオ自動処理部３２は、問題データを特定する。例えば、オーディオ自動処理部３２は、問題個所のオーディオサンプル区間を特定する。
【０１０７】
ステップＳ３４において、オーディオ自動処理部３２は、問題データをバッファに格納し、ステップＳ３５において、バッファ内でデータを修正する。例えば、問題映像エリアを塗りつぶしたり、ぼかしを入れたりする修正が行われる。
【０１０８】
ステップＳ３６において、オーディオ自動処理部３２は、問題のあるオリジナルのデータに、ステップＳ３５で修正した修正済みのデータで上書きして、データを差し替えた後、オーディオ自動処理は終了される。
【０１０９】
図２１は、図１７のDASHクライアント部２２が実行するDASHクライアント処理を説明するフローチャートである。
【０１１０】
ステップＳ４１において、DASHクライアント部２２は、図１のネットワーク２３を介してDASH配信サーバ１７とHTTP通信を行う。
【０１１１】
ステップＳ４２において、DASHクライアント部２２は、DASH配信サーバ１７からセグメントデータとMPDデータを取得し、データストレージ４１に一時的に保持させる。
【０１１２】
ステップＳ４３において、DASHクライアント部２２は、さらなるデータの取得が必要か否かを判定する。そして、さらなるデータの取得が必要であると判定された場合、処理はステップＳ４４に進み、DASHクライアント部２２は、DASH配信サーバ１７に対してデータの更新を確認し、処理はステップＳ４１に戻る。
【０１１３】
一方、ステップＳ４３において、さらなるデータの取得が必要でないと判定された場合、処理はステップＳ４５に進む。
【０１１４】
ステップＳ４５において、DEMUX部４２は、データストレージ４１から読み出したセグメントデータをデマックスして、ビデオデータをビデオデコード部４３に供給し、オーディオデータをオーディオデコード部４４に供給する。
【０１１５】
ステップＳ４６において、ビデオデコード部４３はビデオデータをデコードし、オーディオデコード部４４はオーディオデータをデコードする。
【０１１６】
ステップＳ４７において、ビデオ再生部４５は、ビデオデコード部４３によりデコードされた映像を再生し、オーディオ再生部４６は、オーディオデコード部４４によりデコードされた音声を再生する。その後、DASHクライアント処理は終了される。
【０１１７】
図２２は、オフライン編集処理を説明するフローチャートである。
【０１１８】
ステップＳ５１において、ビデオオフライン編集部１９は、ビデオ保存部１８に保存されたライブ配信向けストリームを読み出して編集を行う。
【０１１９】
ステップＳ５２において、ビデオオフライン編集部１９は、ライブ配信時のデータ構造に応じた置換セグメントを生成する置換データ生成処理（図２３）を行う。
【０１２０】
ステップＳ５３において、ビデオオフライン編集部１９は、置換を反映したMPDを生成し、置換セグメントとともにDASH配信サーバ１７に配置する。
【０１２１】
ステップＳ５４において、さらなる編集が必要か否かの判定が行われ、さらなる編集が必要であると判定された場合には処理はステップＳ５１に戻って、同様の処理が繰り返して行われる。一方、さらなる編集は必要ないと判定された場合には、オフライン編集処理は終了される。
【０１２２】
図２３は、図２２のステップＳ５２で実行される置換データ生成処理を説明するフローチャートである。
【０１２３】
ステップＳ６１において、ビデオオフライン編集部１９およびオーディオオフライン編集部２１は、ライブ配信ストリームの映像および音声に対して、それぞれ編集が必要な部分のタイムコードを抽出する。
【０１２４】
ステップＳ６２において、ビデオオフライン編集部１９およびオーディオオフライン編集部２１は、ライブ配信ストリームのDASHデータ生成時に保存したSegment Timecode情報を用いて、編集の開始点および終了点をセグメントの境界に合わせて調整する。
【０１２５】
ステップＳ６３において、ビデオオフライン編集部１９およびオーディオオフライン編集部２１は、保存されている元データから置換するセグメント分の編集後ストリームを作成して、エンコードDASH処理部１６に供給する。
【０１２６】
ステップＳ６４において、エンコードDASH処理部１６は、編集後ストリームをDASHセグメント化するとともに、置換後のMPDを生成する。
【０１２７】
その後、置換データ生成処理は終了され、処理は図２２のステップＳ５３に進み、ステップＳ６４で生成された置換用セグメントと、置換を適用したMPDがDASH配信サーバ１７にアップロードされる。
【０１２８】
以上のように、本実施の形態のコンテンツ配信システム１１では、データをセグメント単位で置換して、映像および音声を編集することができる。そして、一つまたは連続する複数のDASHメディア・セグメントの単位で行うことによって、ライブ配信時のデータのうち使用可能なデータをそのまま活用しつつ、配信サーバ上だけでなくＣＤＮ（Content Delivery Network）によってキャッシュされているデータを効率よく置換し、かつストリーミング再生クライアントに対して取得すべきセグメントデータを伝えることができる。
【０１２９】
これにより、コンテンツ配信システム１１は、ライブ配信データのうちポスト編集によって置き換えるべきセグメントデータのみを配信サーバに配置して、ライブ配信時のデータと置換することができる。また、コンテンツ配信システム１１は、ライブ配信時に使用したMPDに対して置換されたセグメントに対してのみ置換後のURLに関する情報を追加することで、ライブ配信時のデータをそのまま利用可能なセグメントは再利用することができる。さらに、コンテンツ配信システム１１は、DASH配信サーバ１７上のセグメントが置換された際に、その置換情報を更新情報としてCDNサーバ２４に対して通知することができる。
【０１３０】
なお、上述のフローチャートを参照して説明した各処理は、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。また、プログラムは、１のCPUにより処理されるものであっても良いし、複数のCPUによって分散処理されるものであっても良い。
【０１３１】
また、上述した一連の処理（コンテンツ処理方法）は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラムが記録されたプログラム記録媒体からインストールされる。
【０１３２】
図２４は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
【０１３３】
コンピュータにおいて、CPU（Central Processing Unit）１０１，ROM（Read Only Memory）１０２，RAM（Random Access Memory）１０３は、バス１０４により相互に接続されている。
【０１３４】
バス１０４には、さらに、入出力インタフェース１０５が接続されている。入出力インタフェース１０５には、キーボード、マウス、マイクロホンなどよりなる入力部１０６、ディスプレイ、スピーカなどよりなる出力部１０７、ハードディスクや不揮発性のメモリなどよりなる記憶部１０８、ネットワークインタフェースなどよりなる通信部１０９、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１を駆動するドライブ１１０が接続されている。
【０１３５】
以上のように構成されるコンピュータでは、CPU１０１が、例えば、記憶部１０８に記憶されているプログラムを、入出力インタフェース１０５及びバス１０４を介して、RAM１０３にロードして実行することにより、上述した一連の処理が行われる。
【０１３６】
コンピュータ（CPU１０１）が実行するプログラムは、例えば、磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM(Compact Disc-Read Only Memory),DVD(Digital Versatile Disc)等）、光磁気ディスク、もしくは半導体メモリなどよりなるパッケージメディアであるリムーバブルメディア１１１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供される。
【０１３７】
そして、プログラムは、リムーバブルメディア１１１をドライブ１１０に装着することにより、入出力インタフェース１０５を介して、記憶部１０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１０９で受信し、記憶部１０８にインストールすることができる。その他、プログラムは、ROM１０２や記憶部１０８に、あらかじめインストールしておくことができる。
【０１３８】
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
（１）
ライブ配信用のコンテンツデータを編集用バッファに格納して、問題個所があった場合には前記編集用バッファ内で前記コンテンツデータを修正し、修正後のコンテンツデータを差し替えて配信するオンライン編集部
を備えるコンテンツ処理装置。
（２）
前記オンライン編集部により修正が施された前記コンテンツデータを保存する保存部と、
前記保存部から前記コンテンツデータを読み出して、複数の編集レベルで編集を行うオフライン編集部と
をさらに備える上記（１）に記載のコンテンツ処理装置。
（３）
前記コンテンツデータを所定のセグメントごとにエンコードし、コンテンツの配信の制御に用いられる制御情報を生成するエンコード処理部
をさらに備え、
前記エンコード処理部は、前記オンライン編集部により編集された前記コンテンツデータ、または、前記オフライン編集部により編集された前記コンテンツデータを、前記制御情報を書き換えることにより前記セグメント単位で置換する
上記（２）に記載のコンテンツ処理装置。
（４）
前記オフライン編集部は、前記コンテンツデータに対して部分ごとに段階的に編集を行い、前記コンテンツデータのライブ配信からの時間の経過に応じて、より高度な編集レベルの編集を行う
上記（３）に記載のコンテンツ処理装置。
（５）
前記エンコード処理部は、前記オフライン編集部により前記コンテンツデータに対する編集が行われると、その編集が行われた部分をセグメントごとに順次置き換える
上記（４）に記載のコンテンツ処理装置。
（６）
前記オフライン編集部により編集された前記コンテンツデータを前記セグメントごとに置き換えるのに用いる前記制御情報が、SAND（Server and Network Assisted DASH）の拡張によって、DASH（Dynamic Adaptive Streaming over HTTP）配信サーバからCDN（Content Delivery Network）サーバに伝達される
上記（３）から（５）までのいずれかに記載のコンテンツ処理装置。
（７）
前記CDNサーバに配置された前記コンテンツデータのうち、前記オフライン編集部により編集された部分の置換情報が前記CDNサーバに通知される
上記（６）に記載のコンテンツ処理装置。
（８）
ライブ配信用のコンテンツデータを編集用バッファに格納して、問題個所があった場合には前記編集用バッファ内で前記コンテンツデータを修正し、修正後のコンテンツデータを差し替えて配信する
ステップを含むコンテンツ処理方法。
（９）
ライブ配信用のコンテンツデータを編集用バッファに格納して、問題個所があった場合には前記編集用バッファ内で前記コンテンツデータを修正し、修正後のコンテンツデータを差し替えて配信する
ステップを含むコンテンツ処理をコンピュータに実行させるプログラム。
【０１３９】
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
【符号の説明】
【０１４０】
１１  コンテンツ配信システム，  １２  撮影装置，  １３  収音装置，  １４  ビデオオンライン編集部，  １５  オーディオオンライン編集部，  １６  エンコードDASH処理部，  １７  DASH配信サーバ，  １８  ビデオ保存部，  １９  ビデオオフライン編集部，  ２０  オーディオ保存部，  ２１  オーディオオフライン編集部，  ２２  DASHクライアント部，  ２３  ネットワーク，  ３１  ビデオ自動処理部，  ３２  オーディオ自動処理部，  ３３  セグメント管理部
【図１】
2018173876.tif 000003
【図２】
2018173876.tif 000004
【図３】
2018173876.tif 000005
【図４】
2018173876.tif 000006
【図５】
2018173876.tif 000007
【図６】
2018173876.tif 000008
【図７】
2018173876.tif 000009
【図８】
2018173876.tif 000010
【図９】
2018173876.tif 000011
【図１０】
2018173876.tif 000012
【図１１】
2018173876.tif 000013
【図１２】
2018173876.tif 000014
【図１３】
2018173876.tif 000015
【図１４】
2018173876.tif 000016
【図１５】
2018173876.tif 000017
【図１６】
2018173876.tif 000018
【図１７】
2018173876.tif 000019
【図１８】
2018173876.tif 000020
【図１９】
2018173876.tif 000021
【図２０】
2018173876.tif 000022
【図２１】
2018173876.tif 000023
【図２２】
2018173876.tif 000024
【図２３】
2018173876.tif 000025
【図２４】
2018173876.tif 000026
【手続補正書】
【提出日】平成30年6月19日(2018.6.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ライブ配信用のストリームデータに基づいて複数のビットレートで符号化された複数の配信用セグメントを生成し、前記生成された配信用セグメントへのアクセス情報を制御する制御情報を生成し、前記制御情報の第１の配信用セグメントへのアクセス情報を、前記第１の配信用セグメントとは異なる第２の配信用セグメントへのアクセス情報に書き換え、前記配信用セグメントと前記制御情報を配信用サーバへ転送するエンコード処理部
を備えるコンテンツ処理装置。
【請求項２】
前記エンコード処理部は、前記第１の配信用セグメントに問題があった場合には、前記第１の配信用セグメントとは異なる前記複数の配信用セグメントから正常なセグメントを第２の配信用セグメントとして選択し、前記制御情報のアクセス情報を書き換える
請求項１に記載のコンテンツ処理装置。
【請求項３】
前記エンコード処理部は、前記生成されたセグメントを管理するセグメント管理部を有し、
前記セグメント管理部は、前記第１の配信用セグメントにデータの欠落がないかを監視する
請求項２に記載のコンテンツ処理装置。
【請求項４】
前記第２の配信用セグメントは、前記第１の配信用セグメントとはビットレートの異なる正常なセグメントである
請求項３に記載のコンテンツ処理装置。
【請求項５】
前記ライブ配信用のストリームデータ及びライブ配信向けの元ストリームデータを保存する保存部と、
前記保存部から前記ストリームデータを読み出し、複数の編集レベルで編集を行うオフライン編集部と
を更に備え、
前記エンコード処理部は、前記オフライン編集部により生成される編集された部分に関する置換用ストリームデータを符号化し、前記第２の配信用セグメントとしてセグメントデータを生成する
請求項１に記載のコンテンツ処理装置。
【請求項６】
前記オフライン編集部は、前記コンテンツデータに対して部分ごとに段階的に編集を行い、前記コンテンツデータのライブ配信からの時間の経過に応じて、より高度な編集レベルの編集を行う
請求項５に記載のコンテンツ処理装置。
【請求項７】
前記オフライン編集部により編集された前記コンテンツデータを前記セグメントごとに置き換えるのに用いる前記制御情報が、ＳＡＮＤ（Ｓｅｒｖｅｒ  ａｎｄ  Ｎｅｔｗｏｒｋ  Ａｓｓｉｓｔｅｄ  ＤＡＳＨ）の拡張によって、ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）配信サーバからＣＤＮ（Ｃｏｎｔｅｎｔ  Ｄｅｌｉｖｅｒｙ  Ｎｅｔｗｏｒｋ）サーバに伝達される
請求項５に記載のコンテンツ処理装置。
【請求項８】
前記ＣＤＮサーバに配置された前記コンテンツデータのうち、前記オフライン編集部により編集された部分の置換情報が前記ＣＤＮサーバに通知される
請求項７に記載のコンテンツ処理装置。
【請求項９】
ライブ配信向けの元ストリームデータを、編集用にバッファに格納して編集するオンライン編集部を更に備え、
前記オンライン編集部は、前記バッファ内のライブ配信向けの元ストリームデータに問題があった場合には、前記編集用バッファ内で前記コンテンツデータを修正し、修正されたコンテンツデータを前記ライブ配信用のストリームデータとして前記エンコード処理部に出力する
請求項１に記載のコンテンツ処理装置。
【請求項１０】
ライブ配信用のストリームデータに基づいて複数のビットレートで符号化された複数の配信用セグメントを生成し、前記生成された配信用セグメントへのアクセス情報を制御する制御情報を生成し、前記制御情報の第１の配信用セグメントへのアクセス情報を、前記第１の配信用セグメントとは異なる第２の配信用セグメントへのアクセス情報に書き換え、前記配信用セグメントと前記制御情報を配信用サーバへ転送する
ステップを含むコンテンツ処理方法。
【請求項１１】
ライブ配信用のストリームデータに基づいて複数のビットレートで符号化された複数の配信用セグメントを生成し、前記生成された配信用セグメントへのアクセス情報を制御する制御情報を生成し、前記制御情報の第１の配信用セグメントへのアクセス情報を、前記第１の配信用セグメントとは異なる第２の配信用セグメントへのアクセス情報に書き換え、前記配信用セグメントと前記制御情報を配信用サーバへ転送する
ステップを含むコンテンツ処理をコンピュータに実行させるプログラム。
【国際調査報告】
2018173876.tif 000027
2018173876.tif 000028
2018173876.tif 000029
2018173876.tif 000030