(57)【要約】【課題】放送と同期させるデータを効率的に配信できる配信装置、同期システム、配信方法及び配信プログラムを提供すること。【解決手段】配信サーバ２０は、放送と同期させるために、配信データを受信してから提示するまで遅延させた時間を示す遅延量を、複数のクライアント３０それぞれから受信する受信部２４と、遅延量に基づいて、配信データのチャンクサイズを決定する決定部２５と、決定されたチャンクサイズにより、配信データをチャンク化してクライアント３０へ配信させるデータ処理部２２と、を備える。【選択図】図２
2018037901.tif 000002
【特許請求の範囲】
【請求項１】
放送と同期させるために、配信データを受信してから提示するまで遅延させた時間を示す遅延量を、複数の受信機それぞれから受信する受信部と、
前記遅延量に基づいて、配信データのチャンクサイズを決定する決定部と、
前記決定部により決定されたチャンクサイズにより、配信データをチャンク化して前記受信機へ配信させる処理部と、を備える配信装置。
【請求項２】
前記決定部は、前記チャンクサイズを増加又は減少させた結果、前記遅延量がマイナスの受信機の数が減少していれば、前記チャンクサイズの増加又は減少を継続し、前記遅延量がマイナスの受信機の数が増加していれば、前記チャンクサイズの増加を減少に、又は減少を増加に変更する請求項１に記載の配信装置。
【請求項３】
前記決定部は、前記遅延量がマイナスの受信機がない場合、前記遅延量の最小値が増加していれば、前記チャンクサイズの増加又は減少を継続し、前記遅延量の最小値が減少していれば、前記チャンクサイズの増加を減少に、又は減少を増加に変更する請求項１又は請求項２に記載の配信装置。
【請求項４】
前記複数の受信機それぞれについて、前記配信データの伝搬遅延時間を計測する計測部と、
前記計測部により計測された伝搬遅延時間に基づいて、前記配信データの送信先の順序をソートするソート部と、を備える請求項１から請求項３のいずれかに記載の配信装置。
【請求項５】
請求項１から請求項４のいずれかに記載の配信装置と、前記複数の受信機とを備えた同期システムであって、
前記受信機は、
放送時刻値を取得する取得部と、
前記配信データの同期用時刻と前記放送時刻値との差分として、前記遅延量を算出し、前記配信装置へ送信する算出部と、を備える同期システム。
【請求項６】
放送と同期させるために、配信データを受信してから提示するまで遅延させた時間を示す遅延量を、複数の受信機それぞれから受信する受信ステップと、
前記遅延量に基づいて、配信データのチャンクサイズを決定する決定ステップと、
前記決定ステップにおいて決定されたチャンクサイズにより、配信データをチャンク化して前記受信機へ配信させる処理ステップと、をコンピュータが実行する配信方法。
【請求項７】
放送と同期させるために、配信データを受信してから提示するまで遅延させた時間を示す遅延量を、複数の受信機それぞれから受信する受信ステップと、
前記遅延量に基づいて、配信データのチャンクサイズを決定する決定ステップと、
前記決定ステップにおいて決定されたチャンクサイズにより、配信データをチャンク化して前記受信機へ配信させる処理ステップと、をコンピュータに実行させるための配信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送と同期させるコンポーネントの配信装置、同期システム、配信方法及び配信プログラムに関する。
【背景技術】
【０００２】
複数の映像、音声、字幕などのコンポーネントで構成されるマルチメディアコンテンツは、各コンポーネントが異なる複数の経路を使って配信される場合が想定される。この場合、１つ又は複数の受信端末がコンポーネント間の再生タイミングを同期して提示するシステムが必要となる。例えば、非特許文献１及び２には、受信点の装置（受信機）が１つの場合の同期手法が示されている。
【０００３】
このような同期システムでは、受信機でコンポーネント間の再生タイミングを同期させるために、送出側で各コンポーネントにタイムスタンプを付加する。このタイムスタンプは、各コンポーネントの配信ユニット（映像又は音声フレームなどの配信単位）ごとに付加されるものであり、この配信ユニットが受信側で提示されるべき時刻を示している。
【０００４】
伝送されるコンテンツは、コンポーネントごとに伝送経路が違うため、パケット到達までに要する時間が異なるが、受信機は、タイムスタンプの値を元に適宜バッファリングすることによって提示タイミングを合わせることができる（例えば、特許文献１〜３参照）。ＩＰＴＶＦＪ  ＳＴＤ−００１０放送通信連携システム仕様では、６．５．２放送コンテンツ・通信ストリームの同期動作モデルで、放送の基準クロック情報をＨＴＭＬ５の拡張ＡＰＩで取得し、通信ストリーム側をバッファリングして同期するシステムモデルが説明されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１２−１０００９号公報
【特許文献２】特開２０１２−２０５０７５号公報
【特許文献３】特開２０１５−２０７８７３号公報
【特許文献４】特開２０１４−２１２５０６号公報
【非特許文献】
【０００６】
【非特許文献１】松村欣司、鹿喰善明、Ｍｉｃｈａｅｌ  Ｊ  Ｅｖａｎｓ、「インターネット配信情報との連動による放送番組パーソナライズシステムの検討」、映像情報メディア学会年次大会講演予稿集、２００９年８月２６日、３−８
【非特許文献２】松村欣司、金次保明、浜田浩行、「放送と同期したＩＰストリーミングによる番組拡張サービスの試作」、映像情報メディア学会年次大会講演予稿集、２０１０年８月３１日、１０−５
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、放送と、フレーム時間単位（例えば、１／３０秒に１回）でサーバから配信されるデータとを受信端末（クライアント）で同期する場合、１台のサーバが複数のクライアントに配信すると、クライアントの数及び通信経路などによって、放送に対してデータが遅延し同期できないケースがある。
このような状況において、例えば、特許文献４では、クライアントごとの伝搬遅延を計測し、伝搬遅延の大きい順から配信するようソートする手法が提案されている。
しかしながら、クライアントの数が増加すると、伝搬遅延を解消することは難しく、１台のサーバで収容可能なクライアントの数が制限されていた。
【０００８】
本発明は、放送と同期させるデータを効率的に配信できる配信装置、同期システム、配信方法及び配信プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る配信装置は、放送と同期させるために、配信データを受信してから提示するまで遅延させた時間を示す遅延量を、複数の受信機それぞれから受信する受信部と、前記遅延量に基づいて、配信データのチャンクサイズを決定する決定部と、前記決定部により決定されたチャンクサイズにより、配信データをチャンク化して前記受信機へ配信させる処理部と、を備える。
【００１０】
前記決定部は、前記チャンクサイズを増加又は減少させた結果、前記遅延量がマイナスの受信機の数が減少していれば、前記チャンクサイズの増加又は減少を継続し、前記遅延量がマイナスの受信機の数が増加していれば、前記チャンクサイズの増加を減少に、又は減少を増加に変更してもよい。
【００１１】
前記決定部は、前記遅延量がマイナスの受信機がない場合、前記遅延量の最小値が増加していれば、前記チャンクサイズの増加又は減少を継続し、前記遅延量の最小値が減少していれば、前記チャンクサイズの増加を減少に、又は減少を増加に変更してもよい。
【００１２】
前記配信装置は、前記複数の受信機それぞれについて、前記配信データの伝搬遅延時間を計測する計測部と、前記計測部により計測された伝搬遅延時間に基づいて、前記配信データの送信先の順序をソートするソート部と、を備えてもよい。
【００１３】
本発明に係る同期システムは、前記配信装置と、前記複数の受信機とを備えた同期システムであって、前記受信機は、放送時刻値を取得する取得部と、前記配信データの同期用時刻と前記放送時刻値との差分として、前記遅延量を算出し、前記配信装置へ送信する算出部と、を備える。
【００１４】
本発明に係る配信方法は、放送と同期させるために、配信データを受信してから提示するまで遅延させた時間を示す遅延量を、複数の受信機それぞれから受信する受信ステップと、前記遅延量に基づいて、配信データのチャンクサイズを決定する決定ステップと、前記決定ステップにおいて決定されたチャンクサイズにより、配信データをチャンク化して前記受信機へ配信させる処理ステップと、をコンピュータが実行する。
【００１５】
本発明に係る配信プログラムは、放送と同期させるために、配信データを受信してから提示するまで遅延させた時間を示す遅延量を、複数の受信機それぞれから受信する受信ステップと、前記遅延量に基づいて、配信データのチャンクサイズを決定する決定ステップと、前記決定ステップにおいて決定されたチャンクサイズにより、配信データをチャンク化して前記受信機へ配信させる処理ステップと、をコンピュータに実行させる。
【発明の効果】
【００１６】
本発明によれば、配信装置において、放送と同期させるデータを効率的に配信できる。
【図面の簡単な説明】
【００１７】
【図１】実施形態に係る同期システムの全体構成を示す図である。
【図２】実施形態に係る配信サーバの機能構成を示す図である。
【図３】実施形態に係るクライアントの機能構成を示す図である。
【図４】実施形態に係るチャンクサイズの決定処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１８】
以下、本発明の実施形態の一例について説明する。
図１は、本実施形態に係る同期システム１の全体構成を示す図である。
同期システム１は、放送局１０と、配信サーバ２０（配信装置）と、複数のクライアント３０（例えば、テレビなどの受信機）と、を備える。
クライアント３０は、放送局１０から放送信号を受信すると共に、配信サーバ２０から配信データを受信し、両者を同期させてユーザに提示する。
【００１９】
配信データは、フレーム時間単位（例えば、１／３０秒に１回）で配信サーバ２０から配信されるが、このとき、配信サーバ２０は、データを数フレーム分にまとめて配信するチャンク化を行うことで、ヘッダ情報を削減し伝送を効率化できる。
ところが、チャンクサイズを大きくしすぎると、伝送効率が低下して、また遅延し同期できないケースが生じる。このため、配信サーバ２０は、同期に間に合うクライアント３０の数を可能な限り多くするため、後述するクライアント３０からの遅延量のフィードバックに基づいてチャンクサイズを動的に制御する機構により、最適なチャンクサイズを決定する。
【００２０】
図２は、本実施形態に係る配信サーバ２０の機能構成を示す図である。
配信サーバ２０は、データ生成部２１と、データ処理部２２と、配信処理部２３と、受信部２４と、決定部２５と、計測部２６と、ソート部２７とを備える。
【００２１】
データ生成部２１は、複数のクライアント３０へ配信するための、放送との同期用時刻を付加した配信データを生成する。
データ処理部２２は、配信データを、決定部２５により決定されたチャンクサイズでチャンク化し、配信処理部２３へ提供する。
配信処理部２３は、配信データを、複数のクライアント３０へ、設定された所定の順序で配信する。
【００２２】
受信部２４は、クライアント３０において配信データを放送と同期させるために、配信データを受信してから提示するまで遅延させた時間を示す遅延量を、複数のクライアント３０それぞれから受信する。
【００２３】
決定部２５は、受信部２４により受信された遅延量に基づいて、配信データのチャンクサイズを決定する。例えば、決定部２５は、チャンクサイズの現在値からの増加又は減少を決定し、データ処理部２２へ通知する。
【００２４】
計測部２６は、複数のクライアント３０のそれぞれについて、配信データの伝搬遅延時間を計測する。具体的には、計測部２６は、配信処理部２３が配信データに付加した配信時刻から、受信部２４が遅延量を受信した時刻までの経過時間を、伝搬遅延時間として計測する。
【００２５】
ソート部２７は、計測部２６により計測された伝搬遅延時間に基づいて、配信データの送信先の順序をソートし、配信処理部に指示する。ソート部２７は、伝搬遅延時間の大きい送信先から優先して配信するように複数のクライアント３０をソートし、伝搬遅延の低減を図る。
【００２６】
図３は、本実施形態に係るクライアント３０の機能構成を示す図である。
クライアント３０は、取得部３１と、算出部３２とを備える。
【００２７】
取得部３１は、放送局１０から送出された放送信号から、放送の提示時刻を示す放送時刻値を取得する。
【００２８】
算出部３２は、配信サーバ２０から受信した配信データの同期用時刻と放送時刻値との差分として遅延量を算出し、配信サーバ２０へ送信する。
ここで、「遅延量＝配信データの同期用時刻値−放送時刻値」であり、算出された遅延量は、放送に同期させて配信データを提示するまでの時間的な余裕度合いを示す。
【００２９】
図４は、本実施形態に係る決定部２５によるチャンクサイズの決定処理の一例を示すフローチャートである。
【００３０】
ステップＳ１において、決定部２５は、受信部２４から各クライアント３０で計測された遅延量を取得する。
ステップＳ２において、決定部２５は、遅延量がマイナスのクライアント数を同期失敗クライアント数（ＣｌｉｅｎｔＦａｉｌｕｒｅ２）とし、遅延量の最小値（ＤｅｌａｙＭｉｎ２）を取得する。
【００３１】
ステップＳ３において、決定部２５は、チャンクサイズの増減を示すフラグ（Ｆｌａｇ＿ＣｈｕｎｋＳｉｚｅ）を初期化する（例えば、Ｆｌａｇ＿ＣｈｕｎｋＳｉｚｅ＝”ＩＮＣ”）。
【００３２】
ステップＳ４において、決定部２５は、フラグ（Ｆｌａｇ＿ＣｈｕｎｋＳｉｚｅ）に従って、チャンクサイズの増減を決定し、データ処理部２２へ通知する。決定部２５は、Ｆｌａｇ＿ＣｈｕｎｋＳｉｚｅ＝”ＩＮＣ”のとき、チャンクサイズを大きくし、Ｆｌａｇ＿ＣｈｕｎｋＳｉｚｅ＝”ＤＥＣ”のとき、チャンクサイズを小さくする。
【００３３】
ステップＳ５において、決定部２５は、以下のステップＳ６〜Ｓ１４の繰り返し処理を開始する。
ステップＳ６において、決定部２５は、前回に取得した同期失敗クライアント数（ＣｌｉｅｎｔＦａｉｌｕｒｅ１）、及び遅延量の最小値（ＤｅｌａｙＭｉｎ１）を保存する。
【００３４】
ステップＳ７において、決定部２５は、受信部２４から各クライアント３０で計測された遅延量を取得する。
ステップＳ８において、決定部２５は、遅延量がマイナスのクライアント数を同期失敗クライアント数（ＣｌｉｅｎｔＦａｉｌｕｒｅ２）とし、遅延量の最小値（ＤｅｌａｙＭｉｎ２）を取得する。
【００３５】
ステップＳ９において、決定部２５は、同期に失敗したクライアント３０があるか（ＣｌｉｅｎｔＦａｉｌｕｒｅ２＞０）否かを判定する。この判定がＹＥＳの場合、処理はステップＳ１０に移り、判定がＮＯの場合、処理はステップＳ１２に移る。
【００３６】
ステップＳ１０において、決定部２５は、同期失敗クライアント数が前回より増加したか否かを判定する。この判定がＹＥＳの場合、決定部２５は、チャンクサイズの調整により配信の効率化に失敗したと判断し、処理はステップＳ１１に移る。一方、判定がＮＯで、同期失敗クライアント数が前回以下の場合、決定部２５は、配信の効率化に成功したと判断し、フラグ（Ｆｌａｇ＿ＣｈｕｎｋＳｉｚｅ）の値を前回と同じに維持し、処理はステップＳ１４に移る。
【００３７】
ステップＳ１１において、決定部２５は、チャンクサイズの増加又は減少による配信の効率化に失敗したので、フラグ（Ｆｌａｇ＿ＣｈｕｎｋＳｉｚｅ）の値を”ＩＮＣ”から”ＤＥＣ”に、又は”ＤＥＣ”から”ＩＮＣ”に反転させる。
【００３８】
ステップＳ１２において、決定部２５は、ステップＳ９で同期失敗クライアントがない（ＣｌｉｅｎｔＦａｉｌｕｒｅ２＝＝０）と判定されたので、次に、遅延量が最小で最も同期に余裕のないクライアント３０について、この遅延量の最小値が閾値以下か否かを判定する。この判定がＹＥＳの場合、処理はステップＳ１３に移る。一方、判定がＮＯの場合、各クライアント３０で同期のための余裕が十分にあるので、決定部２５は、チャンクサイズの調整をせず、処理はステップＳ５に戻る。
【００３９】
ステップＳ１３において、決定部２５は、遅延量の最小値が前回より小さくなったか（ＤｅｌａｙＭｉｎ２＜ＤｅｌａｙＭｉｎ１）否かを判定する。この判定がＹＥＳの場合、決定部２５は、チャンクサイズの調整により配信の効率化に成功したと判断し、処理はステップＳ１４に移る。一方、判定がＮＯの場合、配信の効率化に失敗したと判断し、処理はステップＳ１１に移る。
【００４０】
ステップＳ１４において、決定部２５は、ステップＳ４と同様に、フラグ（Ｆｌａｇ＿ＣｈｕｎｋＳｉｚｅ）に従って、チャンクサイズの増減を決定し、データ処理部２２へ通知する。
【００４１】
本実施形態によれば、同期システム１は、クライアント３０において計算された配信データの遅延量を配信サーバ２０にフィードバックし、配信サーバ２０がこの遅延量に基づいて、データ配信時のチャンクサイズを調整する。
これにより、同期システム１は、配信データのチャンクサイズを動的に調整し、複数のクライアント３０の全体に対して、放送と同期させる配信データが放送よりも早く到着するように効率的に配信できる。この結果、同期システム１は、１台の配信サーバ２０で収容可能なクライアント３０の数を最適化することができる。
【００４２】
配信サーバ２０は、遅延量がマイナスとなったクライアント３０を同期に失敗したクライアント３０として計上し、この数が少なくなるようにチャンクサイズを修正する。具体的には、配信サーバ２０は、チャンクサイズを増加又は減少させた結果、同期失敗クライアント数が減少していれば、チャンクサイズの増加又は減少を継続し、同期失敗クライアント数が増加していれば、チャンクサイズの増加を減少に、又は減少を増加に変更する。
これにより、同期システム１は、複数のクライアント３０の全体にわたって同期の失敗を減少させ、多数のクライアント３０に対して安定したサービスを提供できる。
【００４３】
配信サーバ２０は、全てのクライアント３０が同期に成功している場合は、クライアント３０の全体について、配信データが放送よりも早く余裕を持って到着するようチャンクサイズを調整する。具体的には、配信サーバ２０は、遅延量の最小値が増加していれば、チャンクサイズの増加又は減少を継続し、遅延量の最小値が減少していれば、チャンクサイズの増加を減少に、又は減少を増加に変更する。
これにより、同期システム１は、各クライアント３０において同期処理のための時間的余裕を確保でき、収容可能なクライアント３０の数を増やすことができる。
【００４４】
配信サーバ２０は、遅延量の最小値が閾値を超える場合、チャンクサイズを変更しない。これにより、同期システム１は、全てのクライアント３０において十分な遅延量が確保されている場合には、配信時の手順を省略し、処理負荷を低減できる。
【００４５】
また、同期システム１は、クライアント３０毎の配信データの伝搬遅延時間に基づいて、配信データの送信先の順序をソートする。したがって、同期システム１は、複数のクライアント３０への配信の順序を適切に調整でき、同期失敗クライアント数及び遅延量の改善が期待できる。
【００４６】
以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。
【００４７】
本実施形態におけるチャンクサイズ決定のアルゴリズムは一例であり、遅延量を増やすための決定ルールは適宜設定されてよい。例えば、チャンクサイズの増減の単位は適宜設定可能であり、決定部２５は、同期失敗クライアント数又は遅延量の大きさに基づいて、増減量を変化させてもよい。
【００４８】
ソート部２７は、伝搬遅延として、配信データの伝搬遅延時間に基づいて配信順序を調整したが、これには限られず、例えば前述の遅延量に基づいて伝搬遅延が評価されもよい。この場合、遅延量が小さいほど伝搬遅延が大きい。
【００４９】
本実施形態では、主に同期システム１の構成と動作について説明したが、本発明はこれに限られず、各構成要素を備え、データを配信するための方法、又はプログラムとして構成されてもよい。
【００５０】
さらに、同期システム１の機能を実現するためのプログラムをコンピュータで読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。
【００５１】
ここでいう「コンピュータシステム」とは、ＯＳや周辺機器などのハードウェアを含むものとする。また、「コンピュータで読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭなどの可搬媒体、コンピュータシステムに内蔵されるハードディスクなどの記憶装置のことをいう。
【００５２】
さらに「コンピュータで読み取り可能な記録媒体」とは、インターネットなどのネットワークや電話回線などの通信回線を介してプログラムを送信する場合の通信線のように、短時刻の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時刻プログラムを保持しているものも含んでもよい。また、上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
【符号の説明】
【００５３】
１  同期システム
１０  放送局
２０  配信サーバ
２１  データ生成部
２２  データ処理部
２３  配信処理部
２４  受信部
２５  決定部
２６  計測部
２７  ソート部
３０  クライアント
３１  取得部
３２  算出部
【図１】
2018037901.tif 000003
【図２】
2018037901.tif 000004
【図３】
2018037901.tif 000005
【図４】
2018037901.tif 000006