JP2010087546A - 電子機器、コンテンツ再生方法及びプログラム - Google Patents

Abstract

【課題】バッファのオーバーフローを起こすことなく、一時停止されたストリーミングデータの再生を円滑に再開すること。
【解決手段】ＴＶ１００のＲＴＰ処理部２２１は、コンテンツの再生の一時停止操作時における受信バッファの先頭のデータ、一時停止操作時にサーバ２００から受信されたデータ、再生再開操作前に最後に受信されたデータ、再生再開後に最初に受信されたデータの各タイムスタンプＴｏ、Ｔｐ、Ｔｌ及びＴｒを定義し、Ｔｒが、Ｔｏ、Ｔｐ及びＴｌと比較してどの位置にあるかに応じて、再生再開後の受信データと受信バッファ内とにおける重複データを受信バッファから削除し、デコード再開のタイミングを決定する。
【選択図】図９

Description

本発明は、ネットワークを介してコンテンツをストリーミング再生することが可能な電子機器、当該電子機器におけるコンテンツ再生方法及びプログラムに関する。

近年、ネットワークのブロードバンド化とともに、ネットワークを経由して動画コンテンツを再生する需要が高まっており、それに関連して様々な規格の策定やサービスの提供が行われている。

このようなサービスの方式としては、ダウンロード方式とストリーミング方式とが存在する。このうちストリーミング方式は、サーバが、オンデマンド形式で受信装置にコンテンツのストリーミングデータを送信しながら、受信装置が、受信済みのストリーミングデータに基づいてコンテンツを再生する方式である。この場合、ユーザは受信装置を介してコンテンツの早送り、一時停止、変速再生等のトリックプレイをサーバに要求することができる。

受信装置がストリーミング方式でコンテンツを再生する場合、サーバと受信装置との間でパケットの送受信によってリクエストやデータをやり取りする必要がある。このため、一般的にそのネットワーク環境に応じた伝播遅延が発生する。したがって、受信装置側でユーザ操作によりリクエストを行った画面と、実際にサーバから送信されたデータとの間には、無視できないずれが発生する。

このような問題に関連して、下記特許文献１には、ストリーミングデータの切り替え要求の操作が行われたことが検出された場合に、バッファに蓄積されているストリーミングデータを早送りすることで、データ遅延の減少を図った受信装置が記載されている。ここでいうストリーミングデータの切り替え要求の操作とは、例えばストリーミングデータを送信する機器切り替え、チャンネルの切り替え、コンテンツの巻き戻し、早送り、一時停止、停止等の操作である。

特開２００８−０２２５０７号公報

ところで、サーバが受信装置へ送信するデータは、伝送プロトコルとしてＲＴＰ（Real-time Transport Protocol）を用いる場合、意味のある映像データとして処理が可能なＧＯＰ（Group Of Picture）単位で送信されるのが一般的である。このため、受信装置がコンテンツ再生の一時停止処理及び再開（レジューム再生）処理を行う際、ユーザ操作により一時停止が要求されたデータ位置がＧＯＰの途中に位置する場合には、再生再開時には、サーバはそのＧＯＰの先頭からデータを送信する。すなわち、受信装置において一時停止が要求されたデータ位置と、再生再開後に受信装置へサーバから送信されるデータ位置とが一致している保証がない。したがって、受信装置がサーバから送信されてくるデータをそのまま処理すると、再生再開時に、コンテンツの巻き戻りやスキップが発生し、それに付随した画像の乱れが生じるという問題がある。この問題は、上記特許文献１に記載の技術によっても解決できない。

そこで、受信装置が再生再開時に、一時停止後にバッファに蓄積されたデータを用いて再生を行うことも考えられる。しかし、この場合、一時停止時にネットワークに滞留していたデータがバッファに余分に蓄積されることが考えられるため、一時停止処理及び再開処理の繰り返しによって、バッファのオーバーフローが起こる可能性がある。

以上のような事情に鑑み、本発明の目的は、バッファのオーバーフローを起こすことなく、一時停止されたストリーミングデータの再生を円滑に再開することが可能な電子機器、当該電子機器におけるコンテンツ再生方法及びプログラムを提供することにある。

上述の課題を解決するため、本発明の一の形態に係る電子機器は、受信手段と、バッファリング手段と、再生手段と、操作受付手段と、送信手段と、制御手段とを有する。
上記受信手段は、送信装置からストリーミング送信されたコンテンツのデータを受信する。
上記バッファリング手段は、上記受信されたデータをバッファリングする。
上記再生手段は、上記バッファリングされたデータを順次読み出して再生する。
上記操作受付手段は、上記データの再生の一時停止操作及び再開操作を受け付ける。
上記送信手段は、上記一時停止操作及び再開操作に応じて、上記送信装置へ上記再生の一時停止要求及び再開要求を送信する。
上記制御手段は、上記バッファリング手段によりバッファリングされているデータのうち上記再開要求後に受信されたデータと重複するデータを破棄するように上記バッファリング手段を制御する。また上記制御手段は、上記再開要求後に受信された上記破棄されたデータをバッファリングするように上記バッファリング手段を制御する。
ここで電子機器とは、例えばテレビ受像機、ＨＤＤ（Hard Disk Drive）／ＢＤ（Blu-ray Disc）／ＤＶＤレコーダ等の再生装置、ＰＣ、ゲーム機器、携帯型ＡＶ機器、携帯電話機、カーナビゲーション装置等である。データの再生は、デコード処理及びデコードされたデータの出力処理を含む。
この構成により、バッファリングされているデータのうち、再開要求後に受信されたデータと重複するデータが破棄されるため、一時停止時のデータと再開時のデータとの連続性が保証され、一時停止後のコンテンツの再生が円滑に再開される。それとともに、破棄されたデータに換わり再開要求後に受信されたデータが新たにバッファリングされるため、バッファリング手段にオーバーフローが生じることが防止される。

上記電子機器において、上記制御手段は、上記一時停止操作時に受信されたデータの、上記コンテンツの再生時間軸上における第１の位置と、上記再開操作後に最初に受信されたデータの上記再生時間軸上における第２の位置とを検出してもよい。上記第２の位置が上記第１の位置よりも前である場合、制御手段は、上記バッファリングされている上記第２の位置から上記第１の位置までの間のデータを破棄するように上記バッファリング手段を制御してもよい。また制御手段は、上記破棄後に受信された上記第２の位置から上記第１の位置までのデータをバッファリングするように上記バッファリング手段を制御してもよい。
この場合、上記制御手段は、上記破棄後に受信された上記第２の位置から上記第１の位置までのデータがバッファリングされたときに上記再生を再開するように上記再生手段を制御してもよい。
これにより、制御手段は、上記第１の位置及び第２の位置を検出することで、既にバッファリングされているデータと、再生再開後に受信されたデータとの重複関係を把握することができる。第１の位置から第２の位置までのデータがバッファリング手段から破棄された上で、新たに受信された第２の位置以降のデータがバッファリングされるため、バッファリングされるデータ量が一定に保たれる。したがって電子機器は、バッファリング手段のオーバーフロー及びアンダーフローを防ぐことができる。上記第１及び第２の位置は、例えばデータパケット内に含まれるタイムスタンプにより把握されるが、それ以外の情報を基に把握されてもよい。

上記電子機器において、上記制御手段は、上記一時停止操作時に上記バッファリング手段にバッファリングされているデータのうち最初に受信されたデータの上記再生時間軸上における第３の位置を検出してもよい。上記第２の位置が上記第３の位置よりも前である場合、制御手段は、上記バッファリングされている上記第３の位置から上記第１の位置までのデータと、上記受信された上記第３の位置より前のデータとを破棄するように上記バッファリング手段を制御してもよい。また制御手段は、上記破棄後に受信された上記第３の位置から上記第１の位置までのデータをバッファリングするように上記バッファリング手段を制御してもよい。
この場合、上記制御手段は、上記破棄後に受信された上記第３の位置から上記第１の位置までのデータがバッファリングされたときに上記再生を再開するように上記再生手段を制御してもよい。
これにより、制御手段は、上記第３の位置を検出し、当該第３の位置と第２の位置とを比較することで、再生再開後の受信データがバッファリングされていない場合を把握できる。この場合とは、すなわち当該データが再生手段に既に読み出されている場合である。この場合、バッファリング手段はバッファリングしているデータを全て破棄し、さらに第３の位置のデータを受信するまで受信データを破棄する。またバッファリング手段は、第３の位置から第１の位置までの受信データをバッファリングする。したがって、電子機器は、再生再開後の最初の受信データが既に再生手段に読み出されている場合でも、受信データを破棄し、第１の位置までの受信データを再度バッファリングすることで、オーバーフローを防ぎながら円滑に再生を再開できる。

上記電子機器において、上記制御手段は、上記一時停止操作後かつ上記再開操作前に最後に受信されたデータの上記再生時間軸上における第４の位置を検出してもよい。上記第２の位置が上記第１の位置と上記第４の位置との間である場合、制御手段は、上記バッファリングされている上記第２の位置から上記第４の位置までのデータを破棄するように上記バッファリング手段を制御してもよい。
この場合、上記制御手段は、上記第２の位置から上記第４の位置までのデータが破棄されたときに上記再生を再開するように上記再生手段を制御してもよい。
これにより、制御手段は、上記第４の位置を検出し、当該第４の位置と、上記第２の位置及び第１の位置とを比較することで、第２の位置第４の位置との間にある場合を把握できる。この場合とは、すなわち再生再開後の受信データが一時停止時にバッファリングされていたデータを含まない場合である。この場合、バッファリング手段は、一時停止後かつ再開操作前に受信されバッファリングされたデータのうち、再生再開後に受信されたデータと重複するデータを破棄する。再生手段は、このデータが破棄された時点で再生を再開する。したがって、電子機器は、バッファリングされるデータの増分を極力抑えながら、円滑に再生を再開できる。

上記電子機器において、上記制御手段は、上記第２の位置が上記第４の位置よりも後であった場合、上記再開要求の次回の送信時に、上記第１の位置から上記データを送信するように要求する上記再開要求を上記送信装置へ送信するように上記送信手段を制御してもよい。
これにより、一時停止操作時に受信されたデータと、再生再開後に受信されたデータとの間にギャップが生じた場合には、送信手段が、上記再開要求の次回の送信時に、一時停止操作時の受信データからデータの送信を再開するように送信装置に要求することができる。したがって、送信装置が送信再開時にＧＯＰの先頭からデータを送信する仕様であっても、次回の送信再開時には、少なくとも上記一時停止時のデータを含むＧＯＰの先頭のデータからデータの送信が再開される。再開後の受信データが、バッファリングされたデータと重複する場合は、上述の処理が実行される。よって、電子機器は、再生再開時におけるデータのスキップを防いで、円滑に再生を再開することができる。

上記電子機器において、上記制御手段は、上記一時停止操作後かつ上記再開操作前に最後に受信されたデータの上記再生時間軸上における第４の位置を検出してもよい。上記第２の位置が上記第１の位置と上記第４の位置との間であった場合、上記制御手段は、上記再開要求の次回の送信時に、上記第１の位置から上記データを送信するように要求する上記再開要求を上記送信装置へ送信するように上記送信手段を制御してもよい。
これにより、再生再開後の受信データが、一時停止操作後かつ再開操作前に受信されたデータであった場合には、送信手段が、上記再開要求の次回の送信時に、一時停止操作時の受信データからデータの送信を再開するように送信装置に要求することができる。したがって、送信装置が送信再開時にＧＯＰの先頭からデータを送信する仕様であっても、次回の送信再開時には、少なくとも上記一時停止時のデータを含むＧＯＰの先頭のデータからデータの送信が再開される。再開後の受信データが、バッファリングされたデータと重複する場合は、上述の処理が実行される。よって、電子機器は、上記一時停止操作後かつ再開操作前に受信されたデータが余分にバッファリングされバッファリング手段にオーバーフローが生じるのを防ぐことができる。

またこの場合、上記制御手段は、上記バッファリング手段にバッファリングされたデータの量が所定量を超えた場合に、上記第１の位置から上記データを送信するように要求する上記再開要求を上記送信装置へ送信するように上記送信手段を制御してもよい。
これにより、制御手段は、バッファリング手段のバッファリングデータ量が所定量を超えずに、オーバーフローの危険性がない場合には、上記第１の位置からの再開要求を行わないように制御することができる。したがって、電子機器は、上記再開要求の送信の有無を動的に制御することで、バッファリング手段のオーバーフローを防ぎながら、再開操作後に再開要求を送信することによるユーザレスポンスの低下を防ぐことができる。

本発明の他の形態に係るコンテンツ再生方法は、送信装置からストリーミング送信されたコンテンツのデータを受信することを含む。
上記受信されたデータはバッファリングされる。
上記バッファリングされたデータは順次読み出され再生される。
上記データの再生の一時停止操作及び再開操作が受け付けられる。
上記一時停止操作及び再開操作に応じて、上記送信装置へ上記再生の一時停止要求及び再開要求が送信される。
上記バッファリング手段によりバッファリングされているデータのうち上記再開要求後に受信されたデータと重複するデータは破棄され、上記再開要求後に受信された上記破棄されたデータがバッファリングされる。
この構成により、バッファリングされているデータのうち、再開要求後に受信されたデータと重複するデータが破棄されるため、一時停止時のデータと再開時のデータとの連続性が保証され、一時停止後のコンテンツの再生が円滑に再開される。それとともに、破棄されたデータに換わり再開要求後に受信されたデータが新たにバッファリングされるため、バッファリング手段にオーバーフローが生じることが防止される。

本発明の他の形態に係るプログラムは、電子機器に、受信ステップと、バッファリングステップと、再生ステップと、操作受付ステップと、送信ステップと、制御ステップとを実行させるものである。
上記受信ステップは、送信装置からストリーミング送信されたコンテンツのデータを受信する。
上記バッファリングステップは、上記受信されたデータをバッファリングする。
上記再生ステップは、上記バッファリングされたデータを順次読み出して再生する。
上記操作受付ステップは、上記データの再生の一時停止操作及び再開操作を受け付ける。
上記送信ステップは、上記一時停止操作及び再開操作に応じて、上記送信装置に上記再生の一時停止要求及び再開要求を送信する。
上記制御ステップは、上記バッファリング手段によりバッファリングされているデータのうち上記再開要求後に受信されたデータと重複するデータを破棄する。また上記制御ステップは、上記再開要求後に受信された上記破棄されたデータをバッファリングする。

以上のように、本発明によれば、バッファのオーバーフローを起こすことなく、一時停止されたストリーミングデータの再生を円滑に再開することができる。

以下、本発明の実施の形態を図面に基づき説明する。

［システムの概要］
図１は、本発明の一実施形態に係る電子機器としてのテレビ受像機を含むコンテンツ配信システムの概要を示した図である。

同図に示すように、本実施形態におけるコンテンツ配信システムは、複数のテレビ受像機１００（以下、ＴＶ１００）と、サーバ２００とがネットワーク１５０を介して接続されることで構成される。

サーバ２００は、コンテンツのデータを記憶し、ネットワーク１５０を介して接続されるＴＶ１００からの要求に応じて、当該コンテンツのデータをストリーミング配信する。ＴＶ１００は、ユーザからの要求に基づき、サーバ２００との間で、コンテンツのデータの送信要求や当該データの受信等の各種処理を行い、受信したストリーミングデータを再生する。本実施形態におけるストリーミングデータのフォーマットは、例えばタイムスタンプ付きのＭＰＥＧ２−ＴＳ（Transport Stream）である。

ネットワーク１５０は、例えばサーバ２００と、サーバ２００に接続する権限を有する特定のＴＶ１００とで構築され、ストリーミング配信のための伝送プロトコルとしては、例えばＵＤＰ（User Datagram Protocol）及びＲＴＰが用いられる。しかし、ネットワーク１５０は、任意のＴＶ１００が利用可能なインターネット等のオープンなネットワークでもよい。伝送プロトコルとしては、ＨＴＴＰ（Hypertext Transfer Protocol）及びＴＣＰ（Transmission Control Protocol）が用いられてもよい。伝送路としては、例えば光ファイバー等の有線ケーブルが用いられてもよく、無線電波等の無線伝送路が用いられてもよい。またネットワーク１５０は、ルータや基地局等の中継機を含んでもよい。コンテンツは例えば映画、テレビ番組、文書、写真、絵画及び図表等の映像データ、音楽やラジオ番組等の音声データ、ゲームプログラム等の任意のデータである。

［ＴＶのハードウェア構成］
図２は、上記ＴＶ１００のハードウェア構成を示したブロック図である。
同図に示すように、ＴＶ１００は、ＣＰＵ（Central Processing Unit）１、フラッシュメモリ２、ＤＲＡＭ（Dynamic Random Access Memory）３、内部バス４、リモコン受光部５、デジタルアンテナ入力端子６、デジタルチューナ７、通信部８、ＭＰＥＧデコーダ９、映像信号処理回路１１、グラフィック生成部１２、パネル駆動回路１３、表示パネル１４、音声信号処理回路１５、音声信号増幅回路１６及びスピーカ１７を有する。

デジタルアンテナ入力端子６は、図示しないデジタルアンテナにより受信されたデジタル放送の放送信号を入力する。デジタルチューナ７は、当該放送信号から指定されたチャンネルの信号を選局して、ＭＰＥＧデコーダ９に出力する。通信部８は、例えばネットワークインタフェースカード等からなり、ネットワーク１５０を介して上記サーバ２００との間の通信処理を実行する。

ＭＰＥＧデコーダ９は、ＭＰＥＧ規格によりエンコードされた放送信号やサーバ２００から受信されたストリーミングデータをデコードし、デコードした信号のうち映像信号を映像信号処理回路１１へ、音声信号を音声信号処理回路１５へ出力する。

映像信号処理回路１１は、入力された映像信号に必要な映像処理を施し、グラフィック生成部１２へ出力する。グラフィック生成部１２は、入力された映像信号とＧＵＩ（Graphical User Interface）画面等をＯＳＤ（On Screen Display）処理により合成して、パネル駆動回路１３へ出力する。パネル駆動回路１３は、グラフィック生成部１２から供給される映像信号のデジタル／アナログ変換等を行い、アナログ映像信号に応じて表示パネル１４を駆動する。表示パネル１４は、例えばＬＣＤ（Liquid Crystal Display）やＰＤＰ（Plasma Display Panel）、ＯＥＬ（Organic Electro-Luminescence）ディスプレイ等であり、パネル駆動回路１３から入力されたアナログ映像信号を表示する。

音声信号処理回路１５は、入力された音声信号に必要な音声処理を施し、音声信号増幅回路１６へ出力する。音声信号増幅回路１６は、入力された音声信号を必要な音量に調整し、スピーカ１７へ出力して再生させる。

ＣＰＵ１は、必要に応じてＤＲＡＭ３等にアクセスし、ＴＶ１００の各ブロックを統括的に制御する。フラッシュメモリ２は、ＣＰＵ１に実行させるＯＳ、コンテンツの受信及び再生のためのアプリケーション等のプログラムや各種パラメータなどのファームウェアを固定的に記憶する不揮発性のメモリである。ＤＲＡＭ３は、ＣＰＵ１の作業用領域等として用いられ、ＯＳやプログラム、処理データ等を一時的に保持するメモリである。ＣＰＵ１、フラッシュメモリ２及びＤＲＡＭ３は内部バス４に接続され、相互にアクセスされることでＴＶ１００の全体が制御される。

リモコン受光部５は、リモートコントローラ１０（以下、リモコン１０）から遠隔制御信号によりユーザ操作を受け付け、当該遠隔制御信号をＣＰＵ１へ出力する。これにより、ユーザ操作に応じたコンテンツの受信や再生等の、ＴＶ１００の制御処理が実行される。リモコン１０は、例えば放送チャンネルに対応した数字キーや、メニューボタン、再生ボタン、一時停止ボタン、早送りボタン、巻き戻しボタン等の各種操作部を有している。ＴＶ１００は、リモコン１０及びリモコン受光部５に加えて、ユーザにより直接操作されて各種操作を受け付けるボタン、キー、タッチパネル等を有していてもよく、マウスやキーボード等の他の入力装置から操作を受け付けてもよい。

サーバ２００のハードウェア構成に関する詳細な説明は省略するが、サーバ２００は、ＣＰＵ、ＲＡＭ、ＨＤＤ、通信部、通信用アプリケーション等、コンピュータとして機能するための最低限のハードウェア要素及びソフトウェア要素を有している。

［ＴＶのソフトウェア構成］
図３は、ＴＶ１００のソフトウェア構成を示した図である。
同図に示すように、ＴＶ１００は、ソフトウェアとして、通信インタフェース（Ｉ／Ｆ）２１、通信処理部２２、ストリーミング処理部２３、ディクリプタ２６、ＣＡＳ（Conditional Access System）／ＤＲＭ（Digital Rights Management）クライアント２７を有する。またＴＶ１００は、ソフトウェアとして、デマルチプレクサ２８、再生処理部２９、ブラウザ３５、映像／音声出力処理部３６、映像／音声出力インタフェース３７及びリモコンインタフェース３８の各ソフトウェアも有する。同図において太線矢印はコンテンツ（ストリーミングデータ）の流れを、細線矢印はその他のデータの流れを、破線矢印はリモコン１０からの制御信号の流れをそれぞれ示している。

通信インタフェース（Ｉ／Ｆ）２１は、上記通信部８及び通信処理部２２による上記サーバ２００との間のパケットの通信処理を制御する。通信処理部２２は、ＯＳＩ参照モデルにおける物理層、データリンク層、ネットワーク層、トランスポート層及びアプリケーション層における各種プロトコルを用いてそれぞれパケット通信を実行する複数の処理部（プログラム）を有する。ネットワーク層では、ＩＰ（Internet Protocol）及びＩＧＭＰ（Internet Group Management Protocol）／ＭＬＤ（Multicast Listener Discover Protocol）が機能する。トランスポート層では、ＵＤＰ（User Datagram Protocol）及びＴＣＰ（Transmission Control Protocol）が機能する。アプリケーション層では、ＵＤＰの上位層のプロトコルとしてＲＴＰが機能し、ＴＣＰの上位層のプロトコルとしてＲＴＳＰ（Real Time Streaming Protocol）及びＨＴＴＰ（Hypertext Transfer Protocol）／ＴＬＳ（Transport Layer Security）が機能する。本実施形態において、サーバ２００からストリーミング配信されるコンテンツは、ＲＴＰパケットとしてＲＴＰ処理部２２１に処理される。ＲＴＳＰ処理部２２２は、当該ＲＴＰパケットとして受信されたコンテンツの再生時に、プレイ、ポーズ等のＲＴＳＰリクエストをサーバに送信する。

ストリーミング処理部２３は、通信処理部２２によりＲＴＰを用いてサーバ２００から受信されたストリーミングデータ（ＲＴＰパケットデータ）を処理し、ディクリプタ２６に供給する。バッファリング処理部２４及びＦＥＣ（Forward Error Correction）処理部２５を有する。バッファリング処理部２４は、当該受信されたストリーミングデータをバッファリングするためのバッファ（以下、受信バッファと称する）を有する。受信バッファにバッファリングされたストリーミングデータは、このストリーミング処理部２３によりオーバーフロー及びアンダーフローしない適切なバッファ量に保たれて、適切なタイミングで再生処理部２９へ供給される。受信バッファのフロー制御の詳細については後述する。

ＦＥＣ処理部２５は、バッファリング処理部２４にバッファリングされたストリーミングデータに付加されているＦＥＣを用いて、ストリーミングデータのエラーを検出し訂正する。また、このストリーミング処理部２３では、ストリーミングデータに発生したジッタの除去等も行われる。

ディクリプタ２６は、ストリーミング処理部２３から供給された、暗号化されたストリーミングデータを、ＣＡＳ／ＤＲＭクライアント２７から取得される復号鍵を用いて復号する。

ＣＡＳ／ＤＲＭクライアント２７は、ネットワーク１５０上のＣＡＳ／ＤＲＭサーバ（図示せず）からＣＡＳ及びＤＲＭに関するライセンス情報を受信及び解析する。そしてＣＡＳ／ＤＲＭクライアント２７は、当該ＴＶ１００が、ＣＡＳ及びＤＲＭにより暗号化されたコンテンツの正当な視聴権限を有すると判断した場合に、上記ディクリプタ２６に上記復号鍵を供給する。

デマルチプレクサ２８は、ディクリプタ２６から供給された、多重化されたストリーミングデータを、映像、音声、字幕の各エレメンタリストリーム（ＥＳ：Elementary Stream）に分割し、再生処理部２９に供給する。映像ＥＳは映像デコーダ３０に、音声ＥＳは音声デコーダ３１に、字幕ＥＳは字幕デコーダ３２にそれぞれ出力される。

再生処理部２９は、上記映像デコーダ３０、音声デコーダ３１、字幕デコーダ３２を有し、上記ＭＰＥＧデコーダ９等と協働して、デマルチプレクサ２８から供給された各ＥＳを処理する。映像デコーダ３０は、映像ＥＳをデコードし、映像信号を生成する。音声デコーダ３１は、音声ＥＳをデコードし、音声信号を生成する。字幕デコーダ３２は、字幕ＥＳをデコードして字幕信号を生成し、上記映像信号に重畳する。生成された映像信号及び音声信号は、映像／音声出力処理部３６へ供給される。各デコーダ３０〜３２は、それぞれ内部にバッファを有し、当該バッファに各信号を蓄積して、各信号を映像／音声出力処理部３６へ供給するタイミングを調整する。

映像ＥＳの圧縮フォーマットは、例えばＭＰＥＧ−２である。しかし、ＭＰＥＧ−４等の他の圧縮フォーマットが用いられてもよい。音声ＥＳの圧縮フォーマットは、例えばＡＡＣ（Advanced Audio Coding）である。しかし、ＭＰＥＧ−２ＢＣ（Backward Compatible）、ＭＰ−３（MPEG1 Layer-3）、ＬＰＣＭ（Linear PCM）、ＷＭＡ９（Windows（登録商標） Media Audio9）、ＡＴＲＡＣ（Adaptive Transform Acoustic Coding）、ＡＴＲＡＣ３等の他の圧縮フォーマットが用いられてもよい。

また再生処理部２９は、再生操作部３３及び選局操作部３４を有する。再生操作部３３は、ストリーミングデータの再生時に、リモコン１０からの制御信号（リモコン信号）に基づいて、再生開始、一時停止、変速再生等の各種再生処理を行う。選局操作部３４は、デジタルチューナ７により受信された放送コンテンツの再生時に、上記リモコン信号に基づいて、チャンネルの選局（切り替え）処理を行う。

リモコンＩ／Ｆ３８は、ユーザの操作に基づきリモコン１０から送信される上記リモコン信号を受信し、上記再生操作部３３及び選局操作部３４へ供給する。

映像／音声出力処理部３６は、再生処理部２９から供給された映像信号及び音声信号に、出力のために必要なＤ／Ａ変換処理等の映像処理及び音声処理を施し、映像／音声出力Ｉ／Ｆ３７へ供給する。

映像／音声出力Ｉ／Ｆ３７は、上記映像信号処理回路１１及び音声信号処理回路１５と協働して、映像／音声出力処理部３６から供給された映像信号を上記表示パネル１４へ出力して表示させ、音声信号をスピーカ１７から出力させる。

ブラウザ３５は、上記リモコン信号を基に、通信処理部２２と協働して、Ｗｅｂページを構成するＨＴＭＬ（HyperText Markup Language）ファイルや画像ファイル等をダウンロードし、レイアウトを解析して映像／音声出力処理部３６へ供給し、出力させる。

［ストリーミングデータの構成］
次に、本実施形態においてサーバ２００から伝送されるストリーミングデータの構成について説明する。

図４は、上記ストリーミングデータのＧＯＰ構造を示した図である。
同図に示すように、ストリーミングデータを構成する各フレームは、ＧＯＰ単位で圧縮され伝送される。各ＧＯＰには、１つのＩフレームと、複数のＰフレーム及びＢフレームが含まれる。

ＴＶ１００が、コンテンツの再生の一時停止後に、再生を再開する場合、例えばＲＴＳＰでは、一時停止時にサーバ２００から取得したポーズポイントを指定してプレイリクエストを送信する。このポーズポイントは、標準速度で再生した場合の再生時間を示すＮＰＴ（Normal Play Time）で表され、その範囲がRange値で指定される。

また、本出願人も含む日本国内の家電メーカーや通信事業者により設立されたＩＰＳＰ（IP Service Project）の仕様では、１００ｍｓ単位でのポーズポイントの指定に対して、そのポーズポイントにおけるデータを含むＧＯＰの先頭からデータの送信を再開する。

例えば、ＧＯＰ＃ｎのＧＯＰの途中であるポイントＢが上記Range値またはポーズポイントで指定され、再生再開がサーバ２００にリクエストされた場合、サーバ２００は、ＧＯＰ＃ｎの先頭であるポイントＡのデータからデータの送信を再開する。

したがって、ユーザの一時停止操作によりサーバ２００がデータの送信を停止したのがポイントＢであったとしても、再生再開後には、ポイントＡからポイントＢまでのデータが重複して送信されることとなる。この場合、従来の再生装置においては、再生再開後の受信データをそのまま再生すると、コンテンツの巻き戻りが発生し、画像や音声の乱れが生じるという問題が想定された。

また、サーバの仕様によっては、ポーズポイントに最も近いＧＯＰの先頭から送信を再開する場合もある。例えば、ポーズポイントがポイントＣである場合、そのポイントＣに最も近いＧＯＰ＃ｎ＋１の先頭であるポイントＤからデータの送信が再開される場合もある。この場合、ポーズポイントであるポイントＣからポイントＤまでのデータは送信されないため、従来の再生装置においては、受信データにスキップが生じるという問題が想定された。さらに、送信再開時に、サーバ２００が何らかの異常によりデータを正しく送信しなかった場合や、送信中にネットワーク１５０上でデータが失われた場合等にも、上記受信データにスキップが生じることが想定される。

そこで、本実施形態に係るＴＶ１００は、コンテンツの再生の一時停止後、再生再開時に、一時停止時に受信バッファに格納されているデータと再生再開後にサーバ２００から送信されるデータの重複部分（以下、重複データと称する）を破棄する機能を有する。これにより、一時停止後のストリーミングデータの再生が円滑に再開される。さらに、ＴＶ１００は、受信バッファのデータ量が一定に保たれるため、受信バッファのアンダーフロー及びオーバーフローも防いでいる。

図５は、サーバ２００から送信されるストリーミングデータのＭＴＵ（Maximum Transmission Unit）構成例を示した図である。
ＭＴＵは、ストリーミングデータのサーバ２００からの最大送信単位を示す。ＭＴＵは、複数のタイプスタンプ付きＴＳ（ＴＴＳ）パケットと、ＲＴＰヘッダ、ＵＤＰヘッダ、およびＩＰパケットを含む。各ＴＴＳパケットには、先頭に例えば４バイトで表現されるタイムスタンプが付されている。

このタイムスタンプは単調増加するため、ＴＶ１００は、このタイムスタンプを、ストリーミングデータの各ＴＴＳパケットを一意に識別するための識別子として用いることができる。

図６は、上記ＴＴＳパケットとしてのＲＴＰパケットの構成例を示した説明図である。
同図に示すように、ＲＴＰパケットは、バージョン情報（Ｖ）５１、パディング情報（Ｐ）５２、エクステンション情報（Ｘ）５３、ＣＳＲＣカウント情報（ＣＣ）５４、境界情報（Ｍ）５５、ペイロードタイプ情報（ＰＴ）５６、シーケンス番号５７、上記タイムスタンプ５８、ＳＳＲＣ識別子５９を含む。

ＳＳＲＣ識別子５９は、ストリーミングデータのセッションを識別するための情報である。例えば、ＴＶ１００が一時停止前に取得したストリーミングデータに含まれるＳＳＲＣ識別子５９と、再生再開後に取得したストリーミングデータに含まれるＳＳＲＣ識別子５９とには、異なる値が記載される。したがって、ＴＶ１００は、このＳＳＲＣ識別子５９により、一時停止前と再生再開後におけるストリームの切り替わりを判別することができる。

また、ＲＴＰパケットは、ＣＳＲＣ識別子６０、ヘッダ拡張６１、ペイロードヘッダ６２、ペイロードデータ６３、およびパディング６４を含む。

［システムの動作］
次に、以上のように構成されたコンテンツ配信システムの動作について、ＴＶ１００の動作を中心に説明する。

まず、本システムが動作するにあたっての前提条件について説明する。本システムが動作するには、以下の３つの条件が必要となる。
（１）ストリーミングデータは、それを構成するパケットデータを一意に識別するための情報を持つ必要がある。この識別子としては、上述したように、例えばタイムスタンプが用いられる。
（２）サーバ２００は、コンテンツの一時停止前と再生再開後とにおいて、データを重複して送信することが望ましい。「重複して送信する」とは、コンテンツの再生の一時停止前に送信されたデータと再生再開後に送信されたデータとにおいて、上記識別子のうち少なくなくとも１つが重複することをいう。サーバ２００が重複したデータ送信を行わない場合には、ＴＶ１００側で、後述する再生再開点の調整処理を行うことで、再生再開時にデータが重複して送信されることが保証される。
（３）ＴＶ１００のストリーミング処理部２３の受信バッファにおいて、少なくとも１つの識別子を持つパケットデータが存在する必要がある。

次に、ＴＶ１００及びサーバ２００の動作の概要について説明する。
図７は、コンテンツの再生の一時停止から再生再開までの処理（レジューム再生処理）におけるＴＶ１００とサーバ２００との間の大まかなデータのやり取りを示すシーケンス図である。

同図に示すように、まず、コンテンツのストリーミング再生中に、ユーザの操作により、リモコン１０から一時停止要求を示すリモコン信号がＴＶ１００へ送信される（ステップ７１）。すると、ＴＶ１００は、その一時停止要求を受信した時点におけるタイムスタンプＴｐを、ＤＲＡＭ３等に保持し（ステップ７２）、当該一時停止要求に対して、速やかにＭＰＥＧデコーダ９の処理を停止させる（ステップ７３）。そして、ＴＶ１００は、サーバ２００へ、ストリーミングデータの送信の停止要求を送信する（ステップ７４）。

この停止要求に対して、サーバ２００は、既に送信準備ができていた最終ストリーミングデータを送信した上で（ステップ７５）、ストリーミングデータの送信を停止する（ステップ７５）。ＴＶ１００は、この最終ストリーミングデータとともに、サーバ２００のポーズポイントも受信する。このポーズポイントは、再生再開時にＴＶ１００からサーバ２００へ送信されるプレイリクエストに、再生再開ポイントとして含められる。

その後、ユーザの操作により、リモコン１０から、一時停止中のコンテンツの再生再開要求を示すリモコン信号がＴＶ１００へ送信される（ステップ７６）。ＴＶ１００は、当該再生再開要求を受信すると、再生再開後のサーバ２００からの受信データにスキップが発生している場合等、必要に応じて上記再生再開ポイントを調整する（ステップ７７）。この処理については後述する。そして、ＴＶ１００は、サーバ２００へ、上記再生再開ポイントからのストリーミングデータの送信再開を要求する（ステップ７８）。

この再生再開要求に対して、サーバ２００は、ストリーミングデータの送信を再開し（ステップ７９）、新規のストリーミングデータをＴＶ１００へ送信する（ステップ８０）。

ＴＶ１００は、送信再開後のストリーミングデータをサーバ２００から受信し、再生再開後における最初の受信データのタイムスタンプＴｒを基に、受信バッファ内の重複データを破棄する。そしてＴＶ１００は、上記Ｔｐを基に、コンテンツの再生（デコード）タイミングを決定して再生を再開する（ステップ８１）。

次に、ＴＶ１００によるコンテンツの再生の一時停止から再生再開までの具体的な動作について説明する。以下の説明では、主にＲＴＰ処理部２２１及びＲＴＳＰ処理部２２２を動作主体としてＴＶ１００の動作を説明するが、これらの動作は、ストリーミング処理部２３等の他のソフトウェアや、図２に示したＣＰＵ１等のハードウェアとの協働により実行される。

図８は、ＴＶ１００の上記ＲＴＳＰ処理部２２２の動作の流れを示したフローチャートである。なお、本実施形態においては、上記ＲＴＳＰ処理部２２２の処理は非同期処理である。すなわち、ＲＴＳＰ処理部２２２は、リクエスト送信先による実際の処理の実行やその結果を待たずに次の処理に進む。

同図に示すように、まず、ＲＴＳＰ処理部２２２は、コンテンツの再生中に、ユーザによる一時停止操作があったか否か、すなわちリモコン１０から、コンテンツの再生の一時停止要求を受信したか否かを判断する（ステップ１０１）。一時停止操作があった場合、ＲＴＳＰ処理部２２２は、ＭＰＥＧデコーダ９に、受信バッファ内のパケットデータのデコード停止を指示し、コンテンツの再生を一時停止させる（ステップ１０２）。

続いて、ＲＴＳＰ処理部２２２は、上記ＲＴＰ処理部２２１へ、パケットデータの受信処理を停止するように要求するポーズリクエストを送信する（ステップ１０３）。これによりＲＴＰ処理部２２１における、コンテンツの円滑な再生再開のための処理が開始される。

当該ＲＴＰ処理部２２１へのポーズリクエストに続き、ＲＴＳＰ処理部２２２は、サーバ２００へパケットデータの送信を停止するように要求するポーズリクエストを送信する（ステップ１０４）。

続いて、ＲＴＳＰ処理部２２２は、上記ポーズリクエスト後に、ユーザによる再生再開操作があったか否か、すなわち、リモコン１０から、コンテンツの再生再開要求を受信したか否かを判断する（ステップ１０５）。再生再開操作があった場合、ＲＴＳＰ処理部２２２は、必要に応じて再生再開ポイント（ポーズポイント）の調整処理が必要か否かを判断する（ステップ１０６）。再生再開ポイントの調整処理が必要であると判断した場合（Ｙｅｓ）、ＲＴＳＰ処理部２２２は、再生再開ポイントを計算する（ステップ１０７）。この処理については後述する。

続いて、ＲＴＳＰ処理部２２２は、ポーズリクエスト時に上記サーバ２００から取得したポーズポイントまたは上記調整後の再生再開ポイントからパケットデータの送信を再開するように要求するプレイリクエストをサーバ２００へ送信する（ステップ１０８）。

続いて、ＲＴＳＰ処理部２２２は、ＲＴＰ処理部２２１から、デコードを一時停止していたデータのデコード再開の指示があるのを待つ（ステップ１０９）。当該デコード再開の指示があった場合（Ｙｅｓ）、ＲＴＳＰ処理部２２２は、ＭＰＥＧデコーダ９へデコードの再開を指示し、コンテンツの映像及び音声の再生を再開させる（ステップ１１０）。

次に、上記ＲＴＳＰ処理部２２２のポーズリクエストにより開始される、上記ＲＴＰ処理部２２１による上記円滑な再生再開のための処理について説明する。

この説明にあたり、ＲＴＰ処理部２２１の処理に必要な、上記パケットデータの識別子としてのタイムスタンプ値の定義について説明する。図９は、ＴＶ１００に受信されバッファリングされるパケットデータの位置及びそのタイムスタンプを説明するための図である。

同図に示すように、受信バッファに蓄積されているパケットデータは順次デマルチプレクサ２８に読み出され、デコード（再生）される。上述したように、ユーザによる一時停止操作を受けて、ＲＴＳＰ処理部２２２がサーバ２００へのポーズリクエストを送信することにより、サーバ２００によるパケットデータの送信は停止される。しかし、当該ポーズリクエストがサーバ２００へ到達する以前にサーバ２００から送信されネットワーク上に滞留していたパケットデータ等は、当該一時停止操作後にＴＶ１００に受信され、受信バッファに蓄積される。しかし、この一時停止操作後に受信されるデータは、受信バッファのオーバーフローを引き起こす可能性があるため、本実施形態では、極力受信バッファに蓄積されないように制御される。そして、上述したように、ユーザの再生再開操作を受けて、ＲＴＳＰ処理部２２２がサーバ２００へプレイリクエストを送信することで、サーバ２００からのデータの送信が再開される。

ここで、本実施形態においては、Ｔｏ、Ｔｐ、Ｔｌ及びＴｒの４つのタイムスタンプ値が、以下のように定義される。
Ｔｏ：受信バッファ内の先頭のパケットデータのタイムスタンプ
Ｔｐ：一時停止操作時点で最後に受信されたパケットデータのタイムスタンプ
Ｔｌ：再生再開前に最後に受信されたパケットデータのタイムスタンプ
Ｔｒ：再生再開後に最初に受信されたパケットデータのタイムスタンプ。

ＲＴＰ処理部２２１は、これら４つのタイムスタンプを基に、コンテンツの再生再開時における処理を実行する。

図１０、１１及び１２は、当該ＲＴＰ処理部２２１の動作の流れを示したフローチャートである。ここで、説明の便宜上、ＲＴＰ処理部２２１が、コンテンツの一時停止から円滑な再生再開を行うためにどのような追加処理が必要かを示すパラメータとして、"resume_mode"を定義する。このresume_modeとしては、０〜２までの以下の３つのモードが定義され、その初期値は０とされる。
resume_mode =０：追加処理を必要とせず、受信パケットデータを即時デコード可能なモード
resume_mode =１：Ｔｐに該当するパケットデータを受信するまで受信データを受信バッファに書き込むモード
resume_mode =２：Ｔｏに該当するパケットデータを受信するまで受信データを破棄するモード。

以下、ＲＴＰ処理部２２１の処理を、これらの各モードの遷移と併せて説明する。
図１０に示すように、まず、ＲＴＰ処理部２２１は、何らかの信号の入力を待つ（ステップ１２１）。信号の入力があった場合（Ｙｅｓ）、ＲＴＰ処理部２２１は、当該入力が、ＲＴＳＰ処理部２２２からのポーズリクエストであるか、サーバ２００からのパケットデータであるかを判断する（ステップ１２２）。

上記入力がポーズリクエストであった場合、ＲＴＰ処理部２２１は、上記Ｔｐを算出し（ステップ１２４）、上記ステップ１２１へ戻る。

上記入力がパケットデータの入力（受信）であった場合、ＲＴＰ処理部２２１は、当該受信されたパケットデータの上記ＳＳＲＣ識別子５９を検出する。そして、ＲＴＰ処理部２２１は、当該受信されたパケットデータのＳＳＲＣ識別子５９と、直前に受信されたパケットデータのＳＳＲＣ識別子５９とを比較し、両者の間でＳＳＲＣ識別子５９が変更されたか否かを判断する（ステップ１２３）。

ＳＳＲＣ識別子５９が変更されたと判断した場合（Ｙｅｓ）、すなわち、受信されたパケットデータが、再生再開後に最初に受信されたパケットデータである場合、ＲＴＰ処理部２２１は、図１１に示す処理へ進む。ＳＳＲＣ識別子５９が変更されていないと判断した場合（Ｎｏ）、すなわち、受信されたパケットデータが、再生再開後の最初のＲＴＰパケットよりも後のパケットデータである場合、ＲＴＰ処理部２２１は、図１２に示す処理へ進む。この場合には、受信されたパケットデータが、一時停止操作後に受信された、ネットワーク１５０上に滞留していたパケットデータである場合も含まれる。

まず、上記ステップ１２３において、受信されたパケットデータのＳＳＲＣ識別子５９が変更された場合の処理について説明する。
図１１に示すように、受信されたパケットデータのＳＳＲＣ識別子５９が変更された場合、ＲＴＰ処理部２２１は、受信バッファ内のデータ及び受信されたパケットデータから、上記Ｔｏ、Ｔｌ及びＴｒをそれぞれ算出する（ステップ１２５）。

続いて、ＲＴＰ処理部２２１は、Ｔｒ＜Ｔｏであるか否かを判断する（ステップ１２６）。Ｔｒ＜Ｔｏであるケースとは、すなわち、再生再開後に最初に受信されたパケットデータと同一のデータが、既にデマルチプレクサ２８に読み出されており、受信バッファに存在しない場合である（図９参照）。このケースは、一般的に、受信バッファにおけるパケットデータのバッファリングが十分でない（アンダーフローが発生している）ケースと考えられる。しかし、本実施形態では、このケースは極力起こらないように受信バッファが実装されているものとする。

Ｔｒ＜Ｔｏであると判断した場合（Ｙｅｓ）、ＲＴＰ処理部２２１は、受信バッファ内の全てのデータ（重複データ）を破棄する（ステップ１２７）。そして、ＲＴＰ処理部２２１は、上記resume_modeを２に切り替え（ステップ１２８）、上記図１０のステップ１２１へ戻る。

Ｔｒ≧Ｔｏであると判断した場合（Ｎｏ）、ＲＴＰ処理部２２１はさらに、Ｔｏ≦Ｔｒ≦Ｔｐであるか否かを判断する（ステップ１２９）。

Ｔｏ≦Ｔｒ≦Ｔｐであると判断した場合（Ｙｅｓ）、ＲＴＰ処理部２２１は、受信バッファ内で、Ｔｒ≦ＴｘとなるタイムスタンプＴｘを識別子として有するパケットデータ（重複データ）を破棄する（ステップ１３０）。そして、ＲＴＰ処理部２２１は、上記resume_modeを１に切り替え（ステップ１３１）、上記図１０のステップ１２１へ戻る。

Ｔｏ≦Ｔｒ≦Ｔｐでない、すなわちＴｐ＜Ｔｒ＜Ｔｐであると判断した場合（Ｎｏ）、ＲＴＰ処理部２２１はさらに、Ｔｐ＜Ｔｒ≦Ｔｌであるか否かを判断する（ステップ１３２）。Ｔｐ＜Ｔｒ≦Ｔｌであるケースとは、すなわち、一時停止操作時に受信されたパケットデータが、再生再開後にサーバ２００から最初に送信されるパケットデータに含まれないケースである。このケースは、例えばＩＰＳＰ等の仕様において、一時停止操作時に受信されたパケットデータを含むＧＯＰと、その前のＧＯＰの境界が、上記ＴｐとＴｌの間に存在した場合に発生しうる。

Ｔｐ＜Ｔｒ≦Ｔｌであると判断した場合（Ｙｅｓ）、ＲＴＰ処理部２２１は、受信バッファ内で、Ｔｒ≦ＴｘとなるタイムスタンプＴｘを識別子として有するパケットデータを破棄する（ステップ１３３）。そして、ＲＴＰ処理部２２１は、上記デコード再開の指示を待っている（ステップ１０９参照）ＲＴＳＰ処理部２２２へ、デコード再開を指示する通知を送信する（ステップ１３４）。これにより、パケットデータのデコードが再開され、コンテンツの映像及び音声の再生が円滑に再開される。

このＴｐ＜Ｔｒ≦Ｔｌであるケースでは、上記Ｔｏ≦Ｔｒ≦Ｔｐであるケースと比較して、受信バッファ内のＴｐからＴｒまでのパケットデータが破棄されないため、この破棄されないパケットデータが受信バッファに余分に蓄積される（図９参照）。しかし、１回のパケット受信処理で余分に蓄積されるパケットデータの量は十分に小さく、受信バッファのオーバーフローを引き起こすほどではない。しかし、このケースが複数回連続すると、余分なパケットデータが増加して、受信バッファのオーバーフローを引き起こす可能性がある。そのため、ＲＴＳＰ処理部２２２は、後述する再生再開ポイントの調整処理により、このケースが生じるのを回避することができる。

Ｔｐ＜Ｔｒ≦Ｔｌでない、すなわち、Ｔｌ＜Ｔｒであると判断した場合（Ｎｏ）、ＲＴＰ処理部２２１は、上記デコード再開の指示を待っている（ステップ１０９参照）ＲＴＳＰ処理部２２２へ、デコード再開を指示する通知を送信する（ステップ１３４）。

このケースは、すなわち、一時停止操作時に受信されたパケットデータと再生再開後に受信されるパケットデータとの間にギャップ（スキップ）が生じているケースである。この原因としては、図４で説明したように、サーバ２００に異常が発生した場合や、サーバ２００が、ポーズポイントを含むＧＯＰの先頭ではなく、ポーズポイントに最も近いＧＯＰの先頭から送信を再開するような仕様を有する場合がある。本実施形態においては、サーバ２００は、このようなケースが極力起こらないように設計されているものとする。しかし、仮にこのようなケースが発生しても、後述する再生再開ポイントの調整処理により、そのようなケースを最小限に抑えることができる。

次に、図１０のステップ１２３において、受信されたパケットデータのＳＳＲＣ識別子５９が変更されていない場合の処理について説明する。
図１２に示すように、受信されたパケットデータのＳＳＲＣ識別子５９が変更された場合、ＲＴＰ処理部２２１は、上記resume_modeが０であるか否かを判断する（ステップ１３５）。resume_modeが０である、すなわち、円滑な再生再開のための追加処理が必要ないと判断した場合（Ｙｅｓ）、ＲＴＰ処理部２２１は、受信されたパケットデータを受信バッファへ書き込み（ステップ１４０）、上記図１０のステップ１２１へ戻る。

resume_modeが０でないと判断した場合（Ｎｏ）、ＲＴＰ処理部２２１は、resume_modeが１であるか否かを判断する（ステップ１３６）。resume_modeが１であると判断した場合（Ｙｅｓ）、ＲＴＰ処理部２２１は、受信されたパケットデータのタイムスタンプＴｘが、Ｔｐ≦Ｔｘを満たすか否かを判断する（ステップ１３７）。

Ｔｐ≦Ｔｘである、すなわち、受信されたパケットデータのタイムスタンプが、一時停止操作時に受信されたパケットデータのタイムスタンプ以上であると判断した場合（Ｙｅｓ）、ＲＴＰ処理部２２１は、resume_modeを０に切り替える（ステップ１３８）。続いて、ＲＴＰ処理部２２１は、ＲＴＳＰ処理部へデコード再開を指示する通知を送信する（ステップ１３９）。そして、ＲＴＰ処理部２２１は、受信されたパケットデータを受信バッファへ書き込み（ステップ１４０）、上記図１０のステップ１２１へ戻る。

上記ステップ１３７において、Ｔｐ≦Ｔｘでないと判断した場合（Ｎｏ）、ＲＴＰ処理部２２１は、受信データを受信バッファへ書き込み（ステップ１４０）、上記図１０のステップ１２１へ戻る。

上記ステップ１３６において、resume_modeが１でない、すなわちresume_modeが２であると判断した場合（Ｎｏ）、ＲＴＰ処理部２２１は、受信されたパケットデータのタイムスタンプＴｘが、Ｔｏ≦Ｔｘを満たすか否かを判断する（ステップ１４１）。

Ｔｏ≦Ｔｘである、すなわち、受信されたパケットデータのタイムスタンプが、受信バッファ内の先頭のパケットデータのタイムスタンプ以上であると判断した場合（Ｙｅｓ）、ＲＴＰ処理部２２１は、resume_modeを１に切り替える（ステップ１４２）。そして、ＲＴＰ処理部２２１は、受信されたパケットデータを受信バッファへ書込み（ステップ１４０）、上記図１０のステップ１２１へ戻る。

上記ステップ１４１において、Ｔｏ≦Ｔｘでない、すなわち受信されたパケットデータのタイムスタンプがＴｏに満たないと判断した場合（Ｎｏ）、ＲＴＰ処理部２２１は、当該パケットデータを破棄し（ステップ１４３）、上記図１０のステップ１２１へ戻る。

以上の処理をまとめると、ＲＴＰ処理部２２１は、再生再開後に最初に受信されたパケットデータのタイムスタンプＴｒが、上記Ｔｏ、Ｔｐ及びＴｌと比較してどの範囲に存在するかに応じて、以下のような処理を実行する。

（Ｔｒ＜Ｔｏの場合）
ＲＴＰ処理部２２１は、受信バッファ内の全てのパケットデータを破棄し、再生再開後にＴｏに該当するタイムスタンプを有するパケットデータを受信するまで、受信されたパケットデータを破棄する。また、ＲＴＰ処理部２２１は、Ｔｏ以上に該当するタイムスタンプを有するパケットデータを受信バッファに書き込む。そして、ＲＴＰ処理部２２１は、Ｔｐに該当するタイムスタンプを有するパケットデータを受信した時点で、パケットデータのデコードを再開する。
これにより、ＲＴＰ処理部２２１部は、Ｔｐに該当するタイムスタンプを有するパケットデータが受信されるのを待ってデコードを再開することで、アンダーフローを回避しながら、一時停止時と再生再開時のパケットデータの連続性を保証することができる。

（Ｔｏ≦Ｔｒ≦Ｔｐの場合）
ＲＴＰ処理部２２１は、Ｔｒ以上のタイムスタンプを有する受信バッファ内のパケットデータを全て破棄する。また、ＲＴＰ処理部２２１は、再生再開後に、Ｔｐに該当するタイムスタンプを有するパケットデータを受信した時点で、パケットデータのデコードを再開する。
これにより、ＲＴＰ処理部２２１は、受信バッファのサイズを一定に保ちながら、一時停止時と再生再開時のパケットデータの連続性を保証することができる。

（Ｔｐ＜Ｔｒ≦Ｔｌの場合）
ＲＴＰ処理部２２１は、Ｔｒ以上のタイムスタンプを有する受信バッファ内のパケットデータを破棄し、その時点でデコードを再開する。
これにより、受信バッファに余分に蓄積されるパケットデータの量を極力抑えながら、一時停止時と再生再開時のパケットデータの連続性を保証することができる。

（Ｔｌ＜Ｔｒの場合）
ＲＴＰ処理部２２１は、受信したパケットデータによりそのままデコードを再開する。この場合は、一時停止時と再生再開時のパケットデータとの間にスキップが生じる。

次に、再生再開ポイントの調整処理について説明する。

ＲＴＳＰ処理部２２２は、上述したように、サーバ２００へ、再生再開を要求するプレイリクエストを再生再開ポイント（ポーズポイント）と共に送信する際、必要に応じてそのポーズポイントを調整する機能を有する。

ポーズポイントの調整は、（１）上記Ｔｐ＜Ｔｒ≦Ｔｌとなる可能性がある場合（受信バッファに余分なパケットデータが蓄積される可能性がある場合）または（２）上記Ｔｌ＜Ｔｒとなる可能性がある場合（一時停止時と再生再開時のパケットデータとの間にスキップが生じる可能性がある場合）に行われる。しかし、この処理は必須ではない。

すなわち、ＲＴＳＰ処理部２２２は、サーバ２００へプレイリクエストを送信して再生再開後の受信パケットを受信した際、上記（１）または（２）のケースが発生した場合には、次回のレジューム再生処理時に、プレイリクエスト送信に先立って、ポーズポイントの調整を実行してもよい。これは、前回のレジューム再生時に上記（１）または（２）のケースが発生した場合には、次回のレジューム再生時にも上記（１）または（２）のケースが発生することが想定されるため、次回のレジューム再生時にそれを未然に防ぐためである。

まず、上記（１）のケースが発生した場合の処理について説明する。

図１３は、ＲＴＳＰ処理部２２２がポーズポイントを調整する処理を説明するための図である。
同図に示すように、一時停止操作があると、デコーダの停止後（同図１．）、ＲＴＳＰ処理部２２２がＲＴＰ処理部２２１へポーズリクエストを送信し（同図２．）、ＲＴＳＰ処理部２２２からのポーズリクエストに応じてサーバ２００が送信を停止する（同図３．）。ＲＴＰ処理部２２１がポーズリクエストを受信した時点のタイムスタンプが上記Ｔｐであり、サーバ２００が送信を停止した時点のタイムスタンプが上記Ｔｌである。

そして、再生再開操作があると、ＲＴＳＰ処理部２２２は、サーバ２００のポーズポイントＰｌを用いてサーバ２００へプレイリクエストを送信する。このプレイリクエストに対して、サーバ２００は、Ｐｌを含むＧＯＰ＃ｎ＋１の先頭からパケットデータの送信を再開する。この際、サーバ２００のポーズポイントＰｌに対応するタイムスタンプＴｌが、ＧＯＰ＃ｎ＋１の先頭に比較的近い場合、再生再開後にサーバ２００から送信されるパケットデータの重複データが少なくなる。この場合、再生再開後に最初に送信されるパケットデータのタイムスタンプＴｒが、上記Ｔｐよりも後になり、上記（１）のケースが生じる。このケースが連続すると、受信バッファのオーバーフローが生じる可能性がある。

そこでＲＴＳＰ処理部２２２は、上記（１）のケースが生じた場合、次回のプレイリクエスト送信時には、同図に示すように、サーバのポーズポイントＰｌではなく、ＲＴＳＰ処理部２２２のポーズポイントＰｐから送信を再開するようサーバ２００へ要求する。ＲＴＰ処理部２２１は、上記（１）のケースが生じた場合、その旨を、例えば上記図１１のステップ１３４におけるデコード再開指示と共にＲＴＳＰ処理部２２２へ通知する。

上記Ｐｐは、サーバ２００から与えられる訳ではないため、ＲＴＳＰ処理部２２２は当該Ｐｐを上記Ｐｌ、Ｔｌ及びＴｐから算出する。すなわち、ＲＴＳＰ処理部２２２は、同図に示すように、上記Ｐｌに対応するタイムスタンプＴｌから、上記Ｐｐに対応するタイムスタンプＴｐを減じた値を２７ＭＨｚで除し、その値を１００ｍｓでラウンドアップしてＰｐを求める。ここで２７Ｍｚは、サーバ２００でタイムスタンプが生成される基準となったシステムクロックである。

そして、ＲＴＳＰ処理部２２２は、当該算出されたＰｐを、サーバ２００への次回のプレイリクエスト時に含める。これにより、サーバ２００が再生再開時に最初に送信するデータのタイムスタンプは、ＧＯＰ＃ｎ＋１の先頭ではなく、Ｔｐを含むＧＯＰ＃ｎの先頭となる。したがって、一時停止時と再生再開時とで、サーバ２００から新たに送信されてくるパケットデータと、受信バッファ内のパケットデータに十分な重複が生じ、上記Ｔｏ≦Ｔｒ≦Ｔｐの状態（resume_mode＝１の状態）を生じさせることができる。この後は、ＲＴＰ処理部２２１が上記図１１のステップ１２９以降の処理を実行することで、受信バッファのデータ量を一定に保ち、オーバーフローを防ぐことができる。

ただし、上記（１）のケースで受信バッファに余分に蓄積されるパケットデータ量は微小であると考えられるため、ＲＴＳＰ処理部２２２は、上記（１）のケースが生じても、上記ポーズポイントの調整を行わなくてもよい。

またＲＴＳＰ処理部２２２は、単に上記（１）のケースが生じただけでなく、受信バッファに蓄積されたパケットデータ量がオーバーフローの危険性のある所定の閾値を超えた場合に、上記ポーズポイントの調整を実行してもよい。
この場合、ＲＴＰ処理部２２１が、受信バッファ内のパケットデータ量を監視し、上記所定値を超えた場合に、その旨をＲＴＳＰ処理部２２２へ通知する。そしてＲＴＳＰ処理部２２２は、次回のレジューム再生時に上記Ｐｐを用いてプレイリクエストを送信する。

次に、上記（２）のケースが発生した場合の処理について説明する。

図１４は、ＲＴＳＰ処理部２２２がポーズポイントを調整する処理を説明するための図である。
上述したように、サーバ２００が、ポーズポイントＰｌを含むＧＯＰの先頭からパケットデータの送信を再開する仕様の場合、ＴＶ１００がサーバ２００から取得したポーズポイントを用いてプレイリクエストを送信する限りは、通常は上記スキップは生じない。したがって、この仕様の場合には、サーバ２００が正しくパケットデータを送信しなかった場合や、ネットワーク１５０上でパケットデータが失われた場合等の異常が発生した場合にデータのスキップが生じる。

したがって、ＲＴＳＰ処理部２２２は、サーバ２００が、ポーズポイントＰｌを含むＧＯＰの先頭からパケットデータの送信を再開する仕様の場合には、上記（１）のケースと同様の処理によりポーズポイントの調整を行えばよい。この場合、ＲＴＰ処理部２２１は、上記図１１のステップ１３２においてＴｌ＜Ｔｒと判断した場合、その旨を、例えば上記ステップ１３４におけるデコード再開指示と共にＲＴＳＰ処理部２２２へ通知する。これにより、ＲＴＳＰ処理部２２２は、次回の再生再開時におけるパケットデータのスキップを防ぐことができる。

一方、サーバ２００が、ポーズポイントＰｌを含むＧＯＰの先頭ではなく、ポーズポイントの直近のＧＯＰの先頭（境界）からパケットデータの送信を再開する仕様の場合、上記図１３で示した処理を行っても、Ｔｒは変更されない。すなわち、ＲＴＳＰ処理部２２２が、上記図１３におけるＰｌの代わりにＰｐを用いてプレイリクエストを送信しても、結局はＧＯＰ＃ｎ＋１の先頭から送信が再開されてしまい、依然としてスキップが生じる可能性がある。

そこで、ＲＴＳＰ処理部２２２は、サーバ２００から取得したポーズポイントＰｌを、半ＧＯＰだけ巻き戻し、この値を用いて上記Ｐｐを算出する。図１４は、この場合の処理を説明する図である。

同図に示すように、ＲＴＳＰ処理部２２２は、上記サーバ２００から取得したポーズポイントＰｌから、最大ＧＯＰ長（時間）の半分の時間であるMAX_GOP_TIME / 2を減じることで、Ｐｌを半ＧＯＰ長分巻き戻したＰｌ´を求める。そしてＲＴＳＰ処理部２２２は、当該Ｐｌ´を用いて上記Ｐｐを求める（Ｐｐ´）。これにより、Ｐｐ´は、ＧＯＰ＃ｎ＋１の先頭よりも、ＧＯＰ＃ｎの先頭に最も近くなる。よって、ＲＴＳＰ処理部２２２が、このＰｐ´を用いて上記プレイリクエストをサーバ２００へ送信することで、サーバ２００はＧＯＰ＃ｎの先頭からパケットデータの送信を再開する。

もちろん、この場合、ＲＴＳＰ処理部２２２は、先にＰｐを求めてから、このＰｐを半ＧＯＰ長分巻き戻しても、同様の効果を奏することができる。

以上の処理により、サーバ２００が、ポーズポイントの直近のＧＯＰの先頭（境界）からパケットデータの送信を再開する仕様の場合でも、ＲＴＳＰ処理部２２２は、次回の再生再開時におけるパケットデータのスキップを防ぐことができる。

以上説明したように、本実施形態によれば、ＴＶ１００は、コンテンツの再生の一時停止後、再生再開時において、Ｔｒの位置に応じて受信バッファから重複データを削除することで、一時停止時と再生再開時におけるパケットデータの連続性を保証できる。これにより、画像の音声の乱れのない、円滑なレジューム再生が実行される。また、ＴＶ１００は、受信バッファ内のパケットデータ量を一定に保つことで、受信バッファのオーバーフロー及びアンダーフローを防ぐことができる。

［変形例］
本発明は上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。

上述の実施形態における上記図８、１０〜１２のフローチャートでは、異常系の処理は記載していないが、異常が発生した場合には、処理の停止、エラー表示等の処理が適宜実行される。

上述の実施形態では、サーバから送信されるデータのストリームフォーマットがタイムスタンプ付きＭＰＥＧ２−ＴＳ（ＴＴＳ）である場合について、タイムスタンプを識別氏として用いる例を説明した。しかし、本発明は、例えばＭＰＥＧ２−ＰＳ、ＭＰＥＧ４等、その他の様々なストリームフォーマットについても、フォーマットに応じて識別子を他のデータに置き換えることで、同様に適用可能である。例えばＭＰＥＧ２−ＰＳにおいては、ＴＶ１００は、ＧＯＰの先頭のＰＥＳヘッダに含まれるＰＴＳ（Presentation Time Stamp）の値と、その値からのオフセットの値を識別子として用いることで、上記ＴＴＳの場合と同様に重複データを一意に識別できる。

上述の実施形態においては、ＲＴＳＰ処理部２２２の処理は非同期処理であった。しかし、当該ＲＴＳＰ処理部２２２の処理の少なくとも１部は同期処理であってもよい。この場合、上記図８で示したＲＴＳＰ処理部２２２の処理及び図１０〜１２で示したＲＴＰ処理部２２１の処理の順序は適宜変更可能である。

上述の実施形態においては、サーバ２００からのストリーミングデータはタイムスタンプ付きのＭＰＥＧ２−ＴＳであった。しかし、ストリーミングデータのフォーマットは、ＭＰＥＧ２−ＰＳ（Program Stream）であってもよく、ＭＰＥＧ４等の他の圧縮フォーマットが用いられてもよい。

上述の実施形態では、コンテンツを受信する電子機器としてＴＶを例に挙げた。しかし、この電子機器は、例えばＨＤＤ／ＢＤ／ＤＶＤ等の記録媒体を有する記録再生装置、ＢＤ／ＤＶＤプレイヤー等の再生装置、ＰＣ、ゲーム機器、携帯型ＡＶ機器、携帯電話機、カーナビゲーション装置、ロボット装置等の他の電子機器でもよい。

本発明の一実施形態に係るＴＶを含むコンテンツ配信システムの概要を示した図である。 本発明の一実施形態に係るＴＶのハードウェア構成を示した図である。 本発明の一実施形態に係るＴＶのソフトウェア構成を示した図である。 本発明の一実施形態においてサーバから伝送されるストリーミングデータのＧＯＰ構造を示した図である。 本発明の一実施形態においてサーバから送信されるストリーミングデータのＭＴＵ構成例を示した図である。 本発明の一実施形態において受信されるＲＴＰパケットの構成例を示した説明図である。 本発明の一実施形態におけるコンテンツの再生の一時停止から再生再開までのＴＶとサーバとの間の大まかなデータのやり取りを示すシーケンス図である。 本発明の一実施形態に係るＴＶのＲＴＳＰ処理部の動作の流れを示したフローチャートである。 本発明の一実施形態に係るＴＶで受信されバッファリングされるデータの位置及びそのタイムスタンプを説明するための図である。 本発明の一実施形態に係るＴＶのＲＴＰ処理部の動作の流れを示したフローチャートである。 本発明の一実施形態に係るＴＶのＲＴＰ処理部の動作の流れを示したフローチャートである。 本発明の一実施形態に係るＴＶのＲＴＰ処理部の動作の流れを示したフローチャートである。 本発明の一実施形態に係るＴＶが再生再開ポイントを調整する処理を説明するための図である。 本発明の一実施形態に係るＴＶが再生再開ポイントを調整する処理を説明するための図である。

符号の説明

１…ＣＰＵ
８…通信部
９…ＭＰＥＧデコーダ
１０…リモートコントローラ（リモコン）
１１…映像信号処理回路
１５…音声信号処理回路
２１…通信インタフェース
２２…通信処理部
２３…ストリーミング処理部
２４…バッファリング処理部
２８…デマルチプレクサ
２９…再生処理部
３０…映像デコーダ
３１…音声デコーダ
３２…字幕デコーダ
３６…映像／出力処理部
１００…テレビ受像機（ＴＶ）
１５０…ネットワーク
２００…サーバ
２２１…ＲＴＰ処理部
２２２…ＲＴＳＰ処理部

Claims (9)

1. 送信装置からストリーミング送信されたコンテンツのデータを受信する受信手段と、
   前記受信されたデータをバッファリングするバッファリング手段と、
   前記バッファリングされたデータを順次読み出して再生する再生手段と、
   前記データの再生の一時停止操作及び再開操作を受け付ける操作受付手段と、
   前記一時停止操作及び再開操作に応じて、前記送信装置へ前記再生の一時停止要求及び再開要求を送信する送信手段と、
   前記バッファリング手段によりバッファリングされているデータのうち前記再開要求後に受信されたデータと重複するデータを破棄し、前記再開要求後に受信された前記破棄されたデータをバッファリングするように前記バッファリング手段を制御する制御手段と
   具備する電子機器。
2. 請求項１に記載の電子機器であって、
   前記制御手段は、前記一時停止操作時に受信されたデータの、前記コンテンツの再生時間軸上における第１の位置と、前記再開操作後に最初に受信されたデータの前記再生時間軸上における第２の位置とを検出し、前記第２の位置が前記第１の位置よりも前である場合に、前記バッファリングされている前記第２の位置から前記第１の位置までの間のデータを破棄し、前記破棄後に受信された前記第２の位置から前記第１の位置までのデータをバッファリングするように前記バッファリング手段を制御し、前記破棄後に受信された前記第２の位置から前記第１の位置までのデータがバッファリングされたときに前記再生を再開するように前記再生手段を制御する
   を有する電子機器。
3. 請求項２に記載の電子機器であって、
   前記制御手段は、前記一時停止操作時に前記バッファリング手段にバッファリングされているデータのうち最初に受信されたデータの前記再生時間軸上における第３の位置を検出し、前記第２の位置が前記第３の位置よりも前である場合に、前記バッファリングされている前記第３の位置から前記第１の位置までのデータと、前記受信された前記第３の位置より前のデータとを破棄し、前記破棄後に受信された前記第３の位置から前記第１の位置までのデータをバッファリングするように前記バッファリング手段を制御し、前記破棄後に受信された前記第３の位置から前記第１の位置までのデータがバッファリングされたときに前記再生を再開するように前記再生手段を制御する
   電子機器。
4. 請求項３に記載の電子機器であって、
   前記制御手段は、前記一時停止操作後かつ前記再開操作前に最後に受信されたデータの前記再生時間軸上における第４の位置を検出し、前記第２の位置が前記第１の位置と前記第４の位置との間である場合に、前記バッファリングされている前記第２の位置から前記第４の位置までのデータを破棄するように前記バッファリング手段を制御し、前記第２の位置から前記第４の位置までのデータが破棄されたときに前記再生を再開するように前記再生手段を制御する
   電子機器。
5. 請求項４に記載の電子機器であって、
   前記制御手段は、前記第２の位置が前記第４の位置よりも後であった場合に、前記再開要求の次回の送信時に、前記第１の位置から前記データを送信するように要求する前記再開要求を前記送信装置へ送信するように前記送信手段を制御する
   電子機器。
6. 請求項３に記載の電子機器であって、
   前記制御手段は、前記一時停止操作後かつ前記再開操作前に最後に受信されたデータの前記再生時間軸上における第４の位置を検出し、前記第２の位置が前記第１の位置と前記第４の位置との間であった場合に、前記再開要求の次回の送信時に、前記第１の位置から前記データを送信するように要求する前記再開要求を前記送信装置へ送信するように前記送信手段を制御する
   電子機器。
7. 請求項６に記載の電子機器であって、
   前記制御手段は、前記バッファリング手段にバッファリングされたデータの量が所定量を超えた場合に、前記第１の位置から前記データを送信するように要求する前記再開要求を前記送信装置へ送信するように前記送信手段を制御する
   電子機器。
8. 送信装置からストリーミング送信されたコンテンツのデータを受信し、
   前記受信されたデータをバッファリングし、
   前記バッファリングされたデータを順次読み出して再生し、
   前記データの再生の一時停止操作及び再開操作を受け付け、
   前記一時停止操作及び再開操作に応じて、前記送信装置へ前記再生の一時停止要求及び再開要求を送信し、
   前記バッファリング手段によりバッファリングされているデータのうち前記再開要求後に受信されたデータと重複するデータを破棄し、前記再開要求後に受信された前記破棄されたデータをバッファリングする
   コンテンツ再生方法。
9. 電子機器に、
   送信装置からストリーミング送信されたコンテンツのデータを受信するステップと、
   前記受信されたデータをバッファリングするステップと、
   前記バッファリングされたデータを順次読み出して再生するステップと、
   前記データの再生の一時停止操作及び再開操作を受け付けるステップと、
   前記一時停止操作及び再開操作に応じて、前記送信装置へ前記再生の一時停止要求及び再開要求を送信するステップと、
   前記バッファリング手段によりバッファリングされているデータのうち前記再開要求後に受信されたデータと重複するデータを破棄し、前記再開要求後に受信された前記破棄されたデータをバッファリングするステップと
   を実行させるためのプログラム。

Images