JP3569241B2 - パケット受信装置及びパケット受信方法 - Google Patents
パケット受信装置及びパケット受信方法 Download PDFInfo
- Publication number
- JP3569241B2 JP3569241B2 JP2001161398A JP2001161398A JP3569241B2 JP 3569241 B2 JP3569241 B2 JP 3569241B2 JP 2001161398 A JP2001161398 A JP 2001161398A JP 2001161398 A JP2001161398 A JP 2001161398A JP 3569241 B2 JP3569241 B2 JP 3569241B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- receiving
- error
- unit
- procedure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/20—Arrangements for detecting or preventing errors in the information received using signal quality detector
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/30—Connection release
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
- Information Transfer Between Computers (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、パケット受信装置及びパケット受信方法に関する。
【０００２】
【従来の技術】
従来、ＳＭＩＬ（Synchronized Multimedia Integration Language）と呼ばれる技術がある。この技術は、テキスト、静止画、動画、音声を含むコンテンツを統合し、空間的および時間的配置を記述する方法としてＷ３Ｃ（World Wide Web Consortium）によって標準化されたものである。ＳＭＩＬ記述言語は、インターネットを通じて非常に普及しているハイパーテキスト記述言語ＨＴＭＬ（Hypertext Markup Language）と似たものであるが、それと比較してコンテンツに時間情報を持つ利点を有している。
【０００３】
ここで、図を用いてＳＭＩＬによって記述されたサーバ上のコンテンツを、ネットワークを介してクライアントが再生する方法について説明する。
【０００４】
図５はＳＭＩＬを用いたコンテンツ配信を説明するための図である。
この図において、ユーザーがネットワーク２００を介してクライアント２０１からサーバ２０３へアクセスし、コンテンツが記述されたＳＭＩＬファイルを取得すると、クライアント２０１がそのＳＭＩＬファイルを解釈する。そして、そのファイルに記述されているテキスト、静止画、動画または音声等のメディアをサーバ２０２、２０４から取得する一方、同ファイルに記述されている時間情報に基づいてそれぞれのメディアを適切な時刻で再生する。なお、図５ではＳＭＩＬファイルや動画データ等の各メディアファイルがそれぞれ個別のサーバ２０２、２０３、２０４に保存されているが、１つのサーバに保存されている場合もある。
【０００５】
次に、ＳＭＩＬファイルや各メディアの伝送方法について説明する。
ＳＭＩＬファイル、静止画データ、テキストファイル等の各メディアファイルをサーバからクライアントへ伝送する場合、インターネットで広く普及しているＨＴＭＬと同様に信頼性のあるプロトコルであるＴＣＰ（Transmission Control Protocol）が一般的に用いられる。一方、音声データや動画データといった時間的に連続するデータについては、リアルタイム性を優先したＲＴＰ（Real-time Transport Protocol）およびＵＤＰ（User Datagram Protocol）というプロトコルを用いて伝送されることが多い。
【０００６】
ＴＣＰまたはＲＴＰ／ＵＤＰを伝送する下位プロトコルとして、ＩＰ（Internet Protocol）プロトコルが一般的に用いられている。
以上のＴＣＰ、ＲＴＰ、ＵＤＰ、ＩＰプロトコルは全てＩＥＴＦ（Internet Engineering Task Force）によって標準化されており、インターネットを中心に広く普及している。
【０００７】
次に、ＳＭＩＬファイルのコンテンツ記述方法について簡単に説明する。
図６はＳＭＩＬで記述された文章の一例を示す図である。
この図において、左端の数字１、２、…は説明のための行番号であり、右端は説明文である。なお、これらは実際のＳＭＩＬファイルには記述されない。
【０００８】
数字１と数字１５とで囲まれたテキストがＳＭＩＬ文書であることを示す。ＳＭＩＬ文書の内容は、数字２から数字８で囲まれるヘッダ部分と、数字９から数字１４で囲まれる本文とからなる。ヘッダ部分は時間情報と無関係なレイアウト情報等が記述される。本文には実際のメディア情報と再生に関する時間情報が記述される。数字１１は動画を表示する制御文であり、数字１２は静止画を表示する制御文であり、これらは数字１０と数字１３のように、＜ｐａｒ>で囲まれるので、同時に再生することを表している。メディアの所在は"ｓｒｃ"によって記述される。また、メディアの再生時間に関する指定は"ｂｅｇｉｎ"、"ｅｎｄ"、"ｄｕｒ"等を用いて記述される。この場合、"ｂｅｇｉｎ"はメディア開始時刻、"ｅｎｄ"はメディア終了時刻、"ｄｕｒ"はメディアの再生時間をそれぞれ指定している。
【０００９】
数字１１の記述は、"ａ"という領域に、"ｓｒｃ"で指定された動画データを３秒から２０秒の間表示することを示している。数字１２の記述は、"ｂ"という領域に"ｓｒｃ"で指定された静止画データを１０秒間表示することを示している。
【００１０】
再生開始・終了を数字１１及び数字１２の記述のように絶対時刻で指定する以外に、以下の例１、例２に示すようにシーケンス的に指定することも可能である。
例１
<seq>
<video id="video1" src="rtsp://example.com/video1.m4v" />
<video id="video2" src="rtsp://example.com/video2.m4v"…/>
</seq>
例２
<par>
<video id="video1" src="rtsp://example.com/video1.m4v" />
<video id="video2" src="rtsp://example.com/video2.m4v" begin="video1.end"…/>
</par>
例１、例２は共にビデオ１の再生が終了した後にビデオ２を再生するようにした記述である。なお、例１、例２では共に動画の場合であるが、動画と静止画でも同様である。
【００１１】
次に、上記例におけるクライアントとサーバとの間の実際の動作について説明する。
図７はメディアを連続再生する場合のシーケンス図である。この図において、実線はリアルタイムデータの制御用に用いられるプロトコルであるＲＴＳＰ（Real Time Streaming Protocol）のコマンドおよびレスポンス信号を表す。ＲＴＳＰは信頼性のあるプロトコルであるＴＣＰ上を介して通信される。一方、実際のメディアデータは点線で表したように非信頼性であるがリアルタイム通信に適したＲＴＰプロトコルが用いられる。また、データの終わりを表すコマンドもＲＴＰを用いて伝送される。
【００１２】
さて、クライアントは、ＳＭＩＬ文書中のｖｉｄｅｏ１を再生する記述を解釈し、サーバに対して再生を要求する（ステップ１）。サーバは、クライアントからの再生要求を受けると再生準備を開始し、その準備が整った時点でＯＫを返す（ステップ２）。ＯＫを返した後、ｖｉｄｅｏ１のデータの送信を開始する（ステップ３）。そして、ｖｉｄｅｏ１のデータを全て送信し終えると、ＲＴＰプロトコルで規定されているＲＴＣＰＢＹＥという制御信号をクライアントに送信し、ｖｉｄｅｏ１のデータを全て送信したことを通知する（ステップ４）。
【００１３】
クライアントは、ＲＴＣＰ（RTP control protocol） ＢＹＥを受信すると、セッションを終了するためにＲＴＳＰＴＥＡＲＤＯＷＮというコマンドを送信する（ステップ５）。サーバはＴＥＡＲＤＯＷＮコマンドを受信するとセッションを終了し、その終了をクライアントに通知する（ステップ６）。クライアントはｖｉｄｅｏ１の再生が終了したので、続いてｖｉｄｅｏ２の再生動作に移行する。ステップ７からステップ１２まではｖｉｄｅｏ１と同様のシーケンスによりｖｉｄｅｏ２の伝送を行う。
【００１４】
【発明が解決しようとする課題】
しかしながら、この従来のパケット受信方法においては、次のような問題がある。
すなわち、音声データや動画データのようなリアルタイムデータを、ＲＴＰを用いて無線回線などのビット誤りの発生しやすい回線を用いて伝送する場合、メディアデータの終了を表すＲＴＣＰＢＹＥのパケットにビット誤りが生じると、図８のシーケンス図に示すようにクライアントの下位レイヤによって破棄されてしまう。このようになると、データの終わりがクライアントでは分からないので、データの送信が全て終了したとしても次のメディアの再生を開始することができなくなる。また、バースト誤りによるメディアの一時中断時には、セッションを終了してしまうことがある。
【００１５】
本発明は係る点に鑑みてなされたものであり、メディア終了通知パケットであるＢＹＥパケットが伝送誤りによって受信できない場合であっても、次のメディアの再生を開始することができるとともに、バースト誤りによるメディアの一時中断時にはセッションを終了せずに待機できるパケット受信装置及びパケット受信方法を提供することを目的とする。
【００１６】
【課題を解決するための手段】
本発明のパケット受信装置は、メディアデータを含むパケットと前記メディアデータの終了を通知するメディアデータ終了信号を含むパケットとを受信するパケット受信手段と、
前記パケット受信手段で受信したパケットの誤りを検出し、誤りが検出されたパケットを破棄するパケット破棄手段と、前記パケット破棄手段によって破棄されなかったパケットが入力されるメディア受信手段と、前記メディア受信手段においてパケットが入力されない場合、前記パケット破棄手段におけるパケットの誤りの検出状況に応じてパケットの受信状況を判定するパケット終了判定手段と、を具備する構成を採る。
【００１７】
この構成によれば、伝送誤り等によってメディアデータの終了を通知するパケットやメディアデータを含むパケットの損失が生じても、メディアデータの受信状況を判定するので、速やかに次のメディアデータの受信を再開することや、誤ってセッションを中断してしまう事態を低減させることが可能となる。
【００３２】
【発明の実施の形態】
本発明の骨子は、ＲＴＰパケットの受信手段であるＲＴＰ受信手段より下位に位置するＩＰレイヤやＵＤＰレイヤにおいてパケット損失を監視することによって、伝送損失等によりメディアデータの終了を表すＢＹＥパケットの損失が生じた場合であっても、メディアデータの終了を判定するとともに、誤ってメディアの終了を判定してしまうことを防止することである。
【００３３】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００３４】
図１は、本発明の実施の形態に係るコンテンツ受信再生装置の構成を示すブロック図である。
この図において、本実施の形態のコンテンツ受信再生装置は、アンテナ１０１と、送受信部１０２と、ＩＰパケット送受信部１０３と、ＴＣＰ送受信部１０４と、ＵＤＰ受信部１０５と、ＲＴＰ受信部１０６と、コンテンツ制御部１０７と、パケット損失監視部１１０と、終了時刻判定部１１１とを備えて構成される。コンテンツ制御部１０７は、再生表示部１０８と制御コマンド送受信部１０９とを有して構成される。
【００３５】
送受信部１０２は、アンテナ１０１を介して受信したＩＰパケットに無線処理（ダウンコンバート、Ａ／Ｄ変換等の処理）と復調処理を施し、復調したパケット信号をＩＰパケット送受信部１０３に入力する。また、ＩＰパケット送受信部１０３から入力されたパケット信号に変調処理と無線処理を施し、無線処理後のＩＰパケットをアンテナ１０１から中空へ放出する。ＩＰパケット送受信部１０３は、ＩＰパケットの送受信を行うとともに、受信したＩＰパケットの誤りを検査し、誤りがあればそのＩＰパケットのＩＰヘッダをパケット損失監視部１１０に入力した後、パケットそのものを破棄する。一方、受信したＩＰパケットに誤りがなければそのＩＰパケットのＩＰヘッダを削除した後、ＴＣＰセグメントの場合はＴＣＰ送受信部１０４に、ＵＤＰセグメントの場合はＵＤＰ受信部１０５に入力する。
【００３６】
ＴＣＰ送受信部１０４は、ＩＰパケット送受信部１０３から入力されたＴＣＰセグメントをコンテンツ制御部１０７の制御コマンド送受信部１０９に入力する。また、コンテンツ制御部１０７の制御コマンド送受信部１０９から入力された制御コマンドをＴＣＰセグメントとしてＩＰパケット送受信部１０３に入力する。ＵＤＰ受信部１０５は、ＩＰパケット送受信部１０３から入力されたＵＤＰセグメントに含まれる誤りを検査し、誤りがある場合にはそのＵＤＰセグメントのヘッダをパケット損失監視部１１０に入力した後、セグメントそのものを破棄する。一方、誤りがない場合にはＵＤＰセグメントをＲＴＰパケットにしてＲＴＰ受信部１０６に入力する。ＲＴＰ受信部１０６は、入力されたＲＴＰパケットをコンテンツ制御部１０７の再生表示部１０８に入力するとともに、ＲＴＰパケットの受信状況を終了時刻判定部１１１に報告する。
【００３７】
コンテンツ制御部１０７において、制御コマンド送受信部１０９は、図示せぬサーバからの制御コマンドを、ＴＣＰ／ＩＰパケットを用いて受信する。また、ＴＣＰ／ＩＰパケットを用いて図示せぬサーバへ制御コマンドを送信する。また、コンテンツの記述に応じて再生表示部１０８に対してメディアの再生開始や再生停止を指示する。再生表示部１０８は、制御コマンド送受信部１０９からの指示に従ってＲＴＰ受信部１０６より入力されたＲＴＰパケットに含まれるメディアデータを再生・表示する。
【００３８】
終了時刻判定部１１１は、ＲＴＰ受信部１０６にてメディアの終了を表すＢＹＥパケットが受信された場合に、メディアの終了と判定してそのＢＹＥパケットを制御コマンド送受信部１０９に入力する。
【００３９】
また、終了時刻判定部１１１は、ＲＴＰ受信部１０６にてＢＹＥパケットが受信されなくても、パケット損失監視部１１０からのパケット損失情報およびＲＴＰ受信部１０６からのＲＴＰパケット受信状況情報を考慮して、パケット損失が生じてなくて、ＲＴＰパケットを受信しない状態が一定時間続いた場合は、サーバからのメディアデータの送信が終了したと判定して制御コマンド送受信部１０９にメディアの停止を指示する。この場合、ＲＴＰ受信部１０６がＲＴＰパケットを受信していなくても、パケット損失情報から下位レイヤのパケット損失が生じていれば、メディアデータの送信が終了したとは判定しない。
【００４０】
すなわち、ＩＰレイヤ又はＵＤＰレイヤにおけるパケット損失が発生していれば、ＲＴＰパケットを一定時間受信していなくても、メディアデータの送信が終了としたとは判定しない。なお、ＲＴＰ受信部１０６がＲＴＰパケットを受信していなくても、下位レイヤのパケット損失が生じている場合とは、再生表示部１０８において再生が中断する場合が続いた場合である。
【００４１】
ここで、ＢＹＥパケットが誤りのため破棄されて、クライアントにメディアの終了時刻が通知されない場合の動作について説明する。
図２は、メディアの連続再生において、ＢＹＥパケットに伝送誤りが発生した場合の動作を示すシーケンス図である。なお、この図において、ステップ１からステップ３までは図７のシーケンス図と同様であるので、説明を省略する。
【００４２】
図２において、伝送誤りによってＢＹＥパケットに誤りが発生すると、そのＢＹＥパケットがクライアント側で破棄される（ステップ４）。この時点では既にサーバからメディアデータの送信が全て終了しているので、メディアデータが送信されることはないが、クライアント側ではメディアデータの送信が終了したかどうかは分からない。このため、クライアント側では一定時間メディアデータを受信できる状態を維持し、その間にメディアデータを受信できなければ、メディアデータの送信が終了したと判断してサーバに対してセッション切断を要求する（ステップ５）。
【００４３】
次に、無線回線上で頻繁に起こることが知られているバーストエラーが発生した場合の動作について説明する。なお、バーストエラーとは、伝送誤りがある一定期間集中して起こるような誤りのパターンのことである。
図３は、メディアの連続再生において、バースト誤りがメディアパケットに発生した場合の動作を示すシーケンス図である。本シーケンス図では、図２と同様に、ステップ３において、サーバから複数のパケットによってメディアデータをクライアントに送信する。
【００４４】
図３において、サーバからクライアントに向けてメディアデータを送信中に、バーストエラーが発生すると、連続するパケットに誤りが生じるため、ＩＰレイヤとＵＤＰレイヤにおいて誤りを検出し全て破棄する処理を行う。その結果、ＲＴＰ受信部１０６はバーストエラーが発生している間全くメディアデータを受信することができなくなる。ＩＰレイヤとＵＤＰレイヤからはパケット損失情報が出力されるので、終了時刻判定部１１１はメディアデータの受信が終了しているとは判定しない。したがって、クライアントはメディアデータを受信できる状態をそのまま維持し、その後にバーストエラーが終了した時点でメディアデータの受信を再開する。
【００４５】
このように、本実施の形態のコンテンツ受信再生装置によれば、再生時間が指定されていないコンテンツを再生する場合において、伝送誤り等によってメディアデータの終了を通知するＢＹＥパケットの損失が生じても、メディアデータの受信不能状態が所定時間継続した場合で、且つその間にパケットの誤りが検出されなければ、メディアデータの送信が終了したと判定するので、速やかに次のメディアデータの受信を再開することが可能となる。
【００４６】
また、伝送誤り等によるパケットの誤りが検出されれば、メディアデ−タの受信待ち状態を維持するので、バースト誤り等によってメディアデータの受信が一時的に中断した場合に、誤ってセッションを中断してしまって再生を停止してしまい、後続のデータを再生できなくなる事態を回避することが可能となる。
【００４７】
なお、上記実施の形態では、コンテンツを受信して再生するコンテンツ受信再生装置について述べたが、コンテンツ制御部１０７を取り除いてコンテンツの受信のみを行うパケット受信装置としてもよい。図４にそのパケット受信装置の構成を示す。
【００４８】
また、上記実施の形態では、コンテンツの受信再生をハードウェア構成で行う場合について説明したが、これに限るものではなく、このコンテンツ受信再生をソフトウェアとして行うことも可能である。例えば、コンテンツ受信再生を行うプログラムをコンピュータで読み取り可能な記録媒体に格納し、このプログラムをコンピュータのＲＡＭ（Random Access Memory）に記録して、コンピュータをそのプログラムに従って動作させるようにしてもよい。
【００４９】
このパケット受信プログラムは、例えば、サーバから送信されたパケットを受信するパケット受信手順と、パケット受信手順にて受信されたパケットの伝送誤りを検出する誤りパケット検出手順と、誤りパケット検出手順にて検出された誤りパケットを破棄するパケット破棄手順と、パケット受信手順にて伝送誤り無く受信されたパケットより音声データや動画データであるメディアデータを受信するメディア受信手順と、メディア受信手順がメディアデータの受信開始後、メディアデータの受信不能状態が所定時間継続した場合で、且つその間に誤りパケット検出手順にてパケットの誤りが検出されなければ、メディアデータの送信が終了したことを判定し、メディアデータの受信不能状態が所定時間継続した場合でも、その間に誤りパケット検出手順にてパケットの誤りが検出されれば、サーバからのメディアデータの送信が終了していないと判定するデータ終了判定手順と、を具備するものである。
【００５０】
ソフトウェアで制御する場合においても、上記実施の形態と同様の作用および効果を呈する。すなわち、伝送誤り等によってメディアデータの終了を通知するパケットの損失が生じても、メディアデータの受信不能状態が所定時間継続した場合で、且つその間にパケットの誤りが検出されなければ、メディアデータの送信が終了したと判定するので、速やかに次のメディアデータの受信を再開することが可能となる。また、伝送誤り等によるパケットの損失がある場合にはメディアデ−タの受信待ち状態を維持するので、バースト誤り等によってメディアデータの受信が一時的に中断した場合に、誤ってセッションを中断してしまう事態を低減させることが可能となる。
【００５１】
コンテンツ受信再生を行うプログラムを記録する記録媒体としては、上記ＲＡＭなどの半導体記憶手段の他、磁気記憶手段、光記憶手段又は光磁気記憶手段であっても構わない。
【００５２】
また、上記実施の形態では、コンテンツ記述言語としてＳＭＩＬを用いたが、他の記述言語としてＨＴＭＬを用いてもよい。また、コンテンツを記述せずに単にメディアを繰り返し再生する場合でもよい。
【００５３】
また、上記実施の形態では、コンテンツに含まれる複数のメディアを連続再生する場合について説明したが、１つのメディアをライブ中継するようなコンテンツでもよい。ライブ中継の場合は、終了時刻が明示されないことが多いので、本発明に用いることによって、ライブ中継コンテンツであっても正しく再生を終了することができる。
【００５４】
【発明の効果】
以上説明したように、本発明によれば、再生時間が指定されていないコンテンツを再生する場合であり、かつＢＹＥパケットが正しく受信されなかった場合であっても、終了時間を適切に判定することができる。さらに、パケット損失による再生の中断が発生した場合であっても、パケット損失を監視して終了時刻判定に用いるので、誤ってメディアデータの終了と判断して再生を停止してしまい後続のデータを再生できなくなる事態を回避することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るコンテンツ受信再生装置の構成を示すブロック図
【図２】本発明の実施の形態に係るコンテンツ受信再生装置のメディア連続再生時の動作を説明するためのシーケンス図
【図３】本発明の実施の形態に係るコンテンツ受信再生装置のメディア連続再生時の動作を説明するためのシーケンス図
【図４】本発明の実施の形態に係るパケット受信装置の構成を示すブロック図
【図５】ＳＭＩＬを用いたコンテンツ配信を説明するための図
【図６】ＳＭＩＬで記述された内容を説明するための図
【図７】メディアを連続再生する場合のシーケンス図
【図８】従来のメディア連続再生時の問題を説明するためのシーケンス図
【符号の説明】
１０１ アンテナ
１０２ 送受信部
１０３ ＩＰパケット送受信部
１０４ ＴＣＰ送受信部
１０５ ＵＤＰ受信部
１０６ ＲＴＰ受信部
１０７ コンテンツ制御部
１０８ 再生表示部
１０９ 制御コマンド送受信部
１１０ パケット損失監視部
１１１ 終了時刻判定部
【発明の属する技術分野】
本発明は、パケット受信装置及びパケット受信方法に関する。
【０００２】
【従来の技術】
従来、ＳＭＩＬ（Synchronized Multimedia Integration Language）と呼ばれる技術がある。この技術は、テキスト、静止画、動画、音声を含むコンテンツを統合し、空間的および時間的配置を記述する方法としてＷ３Ｃ（World Wide Web Consortium）によって標準化されたものである。ＳＭＩＬ記述言語は、インターネットを通じて非常に普及しているハイパーテキスト記述言語ＨＴＭＬ（Hypertext Markup Language）と似たものであるが、それと比較してコンテンツに時間情報を持つ利点を有している。
【０００３】
ここで、図を用いてＳＭＩＬによって記述されたサーバ上のコンテンツを、ネットワークを介してクライアントが再生する方法について説明する。
【０００４】
図５はＳＭＩＬを用いたコンテンツ配信を説明するための図である。
この図において、ユーザーがネットワーク２００を介してクライアント２０１からサーバ２０３へアクセスし、コンテンツが記述されたＳＭＩＬファイルを取得すると、クライアント２０１がそのＳＭＩＬファイルを解釈する。そして、そのファイルに記述されているテキスト、静止画、動画または音声等のメディアをサーバ２０２、２０４から取得する一方、同ファイルに記述されている時間情報に基づいてそれぞれのメディアを適切な時刻で再生する。なお、図５ではＳＭＩＬファイルや動画データ等の各メディアファイルがそれぞれ個別のサーバ２０２、２０３、２０４に保存されているが、１つのサーバに保存されている場合もある。
【０００５】
次に、ＳＭＩＬファイルや各メディアの伝送方法について説明する。
ＳＭＩＬファイル、静止画データ、テキストファイル等の各メディアファイルをサーバからクライアントへ伝送する場合、インターネットで広く普及しているＨＴＭＬと同様に信頼性のあるプロトコルであるＴＣＰ（Transmission Control Protocol）が一般的に用いられる。一方、音声データや動画データといった時間的に連続するデータについては、リアルタイム性を優先したＲＴＰ（Real-time Transport Protocol）およびＵＤＰ（User Datagram Protocol）というプロトコルを用いて伝送されることが多い。
【０００６】
ＴＣＰまたはＲＴＰ／ＵＤＰを伝送する下位プロトコルとして、ＩＰ（Internet Protocol）プロトコルが一般的に用いられている。
以上のＴＣＰ、ＲＴＰ、ＵＤＰ、ＩＰプロトコルは全てＩＥＴＦ（Internet Engineering Task Force）によって標準化されており、インターネットを中心に広く普及している。
【０００７】
次に、ＳＭＩＬファイルのコンテンツ記述方法について簡単に説明する。
図６はＳＭＩＬで記述された文章の一例を示す図である。
この図において、左端の数字１、２、…は説明のための行番号であり、右端は説明文である。なお、これらは実際のＳＭＩＬファイルには記述されない。
【０００８】
数字１と数字１５とで囲まれたテキストがＳＭＩＬ文書であることを示す。ＳＭＩＬ文書の内容は、数字２から数字８で囲まれるヘッダ部分と、数字９から数字１４で囲まれる本文とからなる。ヘッダ部分は時間情報と無関係なレイアウト情報等が記述される。本文には実際のメディア情報と再生に関する時間情報が記述される。数字１１は動画を表示する制御文であり、数字１２は静止画を表示する制御文であり、これらは数字１０と数字１３のように、＜ｐａｒ>で囲まれるので、同時に再生することを表している。メディアの所在は"ｓｒｃ"によって記述される。また、メディアの再生時間に関する指定は"ｂｅｇｉｎ"、"ｅｎｄ"、"ｄｕｒ"等を用いて記述される。この場合、"ｂｅｇｉｎ"はメディア開始時刻、"ｅｎｄ"はメディア終了時刻、"ｄｕｒ"はメディアの再生時間をそれぞれ指定している。
【０００９】
数字１１の記述は、"ａ"という領域に、"ｓｒｃ"で指定された動画データを３秒から２０秒の間表示することを示している。数字１２の記述は、"ｂ"という領域に"ｓｒｃ"で指定された静止画データを１０秒間表示することを示している。
【００１０】
再生開始・終了を数字１１及び数字１２の記述のように絶対時刻で指定する以外に、以下の例１、例２に示すようにシーケンス的に指定することも可能である。
例１
<seq>
<video id="video1" src="rtsp://example.com/video1.m4v" />
<video id="video2" src="rtsp://example.com/video2.m4v"…/>
</seq>
例２
<par>
<video id="video1" src="rtsp://example.com/video1.m4v" />
<video id="video2" src="rtsp://example.com/video2.m4v" begin="video1.end"…/>
</par>
例１、例２は共にビデオ１の再生が終了した後にビデオ２を再生するようにした記述である。なお、例１、例２では共に動画の場合であるが、動画と静止画でも同様である。
【００１１】
次に、上記例におけるクライアントとサーバとの間の実際の動作について説明する。
図７はメディアを連続再生する場合のシーケンス図である。この図において、実線はリアルタイムデータの制御用に用いられるプロトコルであるＲＴＳＰ（Real Time Streaming Protocol）のコマンドおよびレスポンス信号を表す。ＲＴＳＰは信頼性のあるプロトコルであるＴＣＰ上を介して通信される。一方、実際のメディアデータは点線で表したように非信頼性であるがリアルタイム通信に適したＲＴＰプロトコルが用いられる。また、データの終わりを表すコマンドもＲＴＰを用いて伝送される。
【００１２】
さて、クライアントは、ＳＭＩＬ文書中のｖｉｄｅｏ１を再生する記述を解釈し、サーバに対して再生を要求する（ステップ１）。サーバは、クライアントからの再生要求を受けると再生準備を開始し、その準備が整った時点でＯＫを返す（ステップ２）。ＯＫを返した後、ｖｉｄｅｏ１のデータの送信を開始する（ステップ３）。そして、ｖｉｄｅｏ１のデータを全て送信し終えると、ＲＴＰプロトコルで規定されているＲＴＣＰＢＹＥという制御信号をクライアントに送信し、ｖｉｄｅｏ１のデータを全て送信したことを通知する（ステップ４）。
【００１３】
クライアントは、ＲＴＣＰ（RTP control protocol） ＢＹＥを受信すると、セッションを終了するためにＲＴＳＰＴＥＡＲＤＯＷＮというコマンドを送信する（ステップ５）。サーバはＴＥＡＲＤＯＷＮコマンドを受信するとセッションを終了し、その終了をクライアントに通知する（ステップ６）。クライアントはｖｉｄｅｏ１の再生が終了したので、続いてｖｉｄｅｏ２の再生動作に移行する。ステップ７からステップ１２まではｖｉｄｅｏ１と同様のシーケンスによりｖｉｄｅｏ２の伝送を行う。
【００１４】
【発明が解決しようとする課題】
しかしながら、この従来のパケット受信方法においては、次のような問題がある。
すなわち、音声データや動画データのようなリアルタイムデータを、ＲＴＰを用いて無線回線などのビット誤りの発生しやすい回線を用いて伝送する場合、メディアデータの終了を表すＲＴＣＰＢＹＥのパケットにビット誤りが生じると、図８のシーケンス図に示すようにクライアントの下位レイヤによって破棄されてしまう。このようになると、データの終わりがクライアントでは分からないので、データの送信が全て終了したとしても次のメディアの再生を開始することができなくなる。また、バースト誤りによるメディアの一時中断時には、セッションを終了してしまうことがある。
【００１５】
本発明は係る点に鑑みてなされたものであり、メディア終了通知パケットであるＢＹＥパケットが伝送誤りによって受信できない場合であっても、次のメディアの再生を開始することができるとともに、バースト誤りによるメディアの一時中断時にはセッションを終了せずに待機できるパケット受信装置及びパケット受信方法を提供することを目的とする。
【００１６】
【課題を解決するための手段】
本発明のパケット受信装置は、メディアデータを含むパケットと前記メディアデータの終了を通知するメディアデータ終了信号を含むパケットとを受信するパケット受信手段と、
前記パケット受信手段で受信したパケットの誤りを検出し、誤りが検出されたパケットを破棄するパケット破棄手段と、前記パケット破棄手段によって破棄されなかったパケットが入力されるメディア受信手段と、前記メディア受信手段においてパケットが入力されない場合、前記パケット破棄手段におけるパケットの誤りの検出状況に応じてパケットの受信状況を判定するパケット終了判定手段と、を具備する構成を採る。
【００１７】
この構成によれば、伝送誤り等によってメディアデータの終了を通知するパケットやメディアデータを含むパケットの損失が生じても、メディアデータの受信状況を判定するので、速やかに次のメディアデータの受信を再開することや、誤ってセッションを中断してしまう事態を低減させることが可能となる。
【００３２】
【発明の実施の形態】
本発明の骨子は、ＲＴＰパケットの受信手段であるＲＴＰ受信手段より下位に位置するＩＰレイヤやＵＤＰレイヤにおいてパケット損失を監視することによって、伝送損失等によりメディアデータの終了を表すＢＹＥパケットの損失が生じた場合であっても、メディアデータの終了を判定するとともに、誤ってメディアの終了を判定してしまうことを防止することである。
【００３３】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００３４】
図１は、本発明の実施の形態に係るコンテンツ受信再生装置の構成を示すブロック図である。
この図において、本実施の形態のコンテンツ受信再生装置は、アンテナ１０１と、送受信部１０２と、ＩＰパケット送受信部１０３と、ＴＣＰ送受信部１０４と、ＵＤＰ受信部１０５と、ＲＴＰ受信部１０６と、コンテンツ制御部１０７と、パケット損失監視部１１０と、終了時刻判定部１１１とを備えて構成される。コンテンツ制御部１０７は、再生表示部１０８と制御コマンド送受信部１０９とを有して構成される。
【００３５】
送受信部１０２は、アンテナ１０１を介して受信したＩＰパケットに無線処理（ダウンコンバート、Ａ／Ｄ変換等の処理）と復調処理を施し、復調したパケット信号をＩＰパケット送受信部１０３に入力する。また、ＩＰパケット送受信部１０３から入力されたパケット信号に変調処理と無線処理を施し、無線処理後のＩＰパケットをアンテナ１０１から中空へ放出する。ＩＰパケット送受信部１０３は、ＩＰパケットの送受信を行うとともに、受信したＩＰパケットの誤りを検査し、誤りがあればそのＩＰパケットのＩＰヘッダをパケット損失監視部１１０に入力した後、パケットそのものを破棄する。一方、受信したＩＰパケットに誤りがなければそのＩＰパケットのＩＰヘッダを削除した後、ＴＣＰセグメントの場合はＴＣＰ送受信部１０４に、ＵＤＰセグメントの場合はＵＤＰ受信部１０５に入力する。
【００３６】
ＴＣＰ送受信部１０４は、ＩＰパケット送受信部１０３から入力されたＴＣＰセグメントをコンテンツ制御部１０７の制御コマンド送受信部１０９に入力する。また、コンテンツ制御部１０７の制御コマンド送受信部１０９から入力された制御コマンドをＴＣＰセグメントとしてＩＰパケット送受信部１０３に入力する。ＵＤＰ受信部１０５は、ＩＰパケット送受信部１０３から入力されたＵＤＰセグメントに含まれる誤りを検査し、誤りがある場合にはそのＵＤＰセグメントのヘッダをパケット損失監視部１１０に入力した後、セグメントそのものを破棄する。一方、誤りがない場合にはＵＤＰセグメントをＲＴＰパケットにしてＲＴＰ受信部１０６に入力する。ＲＴＰ受信部１０６は、入力されたＲＴＰパケットをコンテンツ制御部１０７の再生表示部１０８に入力するとともに、ＲＴＰパケットの受信状況を終了時刻判定部１１１に報告する。
【００３７】
コンテンツ制御部１０７において、制御コマンド送受信部１０９は、図示せぬサーバからの制御コマンドを、ＴＣＰ／ＩＰパケットを用いて受信する。また、ＴＣＰ／ＩＰパケットを用いて図示せぬサーバへ制御コマンドを送信する。また、コンテンツの記述に応じて再生表示部１０８に対してメディアの再生開始や再生停止を指示する。再生表示部１０８は、制御コマンド送受信部１０９からの指示に従ってＲＴＰ受信部１０６より入力されたＲＴＰパケットに含まれるメディアデータを再生・表示する。
【００３８】
終了時刻判定部１１１は、ＲＴＰ受信部１０６にてメディアの終了を表すＢＹＥパケットが受信された場合に、メディアの終了と判定してそのＢＹＥパケットを制御コマンド送受信部１０９に入力する。
【００３９】
また、終了時刻判定部１１１は、ＲＴＰ受信部１０６にてＢＹＥパケットが受信されなくても、パケット損失監視部１１０からのパケット損失情報およびＲＴＰ受信部１０６からのＲＴＰパケット受信状況情報を考慮して、パケット損失が生じてなくて、ＲＴＰパケットを受信しない状態が一定時間続いた場合は、サーバからのメディアデータの送信が終了したと判定して制御コマンド送受信部１０９にメディアの停止を指示する。この場合、ＲＴＰ受信部１０６がＲＴＰパケットを受信していなくても、パケット損失情報から下位レイヤのパケット損失が生じていれば、メディアデータの送信が終了したとは判定しない。
【００４０】
すなわち、ＩＰレイヤ又はＵＤＰレイヤにおけるパケット損失が発生していれば、ＲＴＰパケットを一定時間受信していなくても、メディアデータの送信が終了としたとは判定しない。なお、ＲＴＰ受信部１０６がＲＴＰパケットを受信していなくても、下位レイヤのパケット損失が生じている場合とは、再生表示部１０８において再生が中断する場合が続いた場合である。
【００４１】
ここで、ＢＹＥパケットが誤りのため破棄されて、クライアントにメディアの終了時刻が通知されない場合の動作について説明する。
図２は、メディアの連続再生において、ＢＹＥパケットに伝送誤りが発生した場合の動作を示すシーケンス図である。なお、この図において、ステップ１からステップ３までは図７のシーケンス図と同様であるので、説明を省略する。
【００４２】
図２において、伝送誤りによってＢＹＥパケットに誤りが発生すると、そのＢＹＥパケットがクライアント側で破棄される（ステップ４）。この時点では既にサーバからメディアデータの送信が全て終了しているので、メディアデータが送信されることはないが、クライアント側ではメディアデータの送信が終了したかどうかは分からない。このため、クライアント側では一定時間メディアデータを受信できる状態を維持し、その間にメディアデータを受信できなければ、メディアデータの送信が終了したと判断してサーバに対してセッション切断を要求する（ステップ５）。
【００４３】
次に、無線回線上で頻繁に起こることが知られているバーストエラーが発生した場合の動作について説明する。なお、バーストエラーとは、伝送誤りがある一定期間集中して起こるような誤りのパターンのことである。
図３は、メディアの連続再生において、バースト誤りがメディアパケットに発生した場合の動作を示すシーケンス図である。本シーケンス図では、図２と同様に、ステップ３において、サーバから複数のパケットによってメディアデータをクライアントに送信する。
【００４４】
図３において、サーバからクライアントに向けてメディアデータを送信中に、バーストエラーが発生すると、連続するパケットに誤りが生じるため、ＩＰレイヤとＵＤＰレイヤにおいて誤りを検出し全て破棄する処理を行う。その結果、ＲＴＰ受信部１０６はバーストエラーが発生している間全くメディアデータを受信することができなくなる。ＩＰレイヤとＵＤＰレイヤからはパケット損失情報が出力されるので、終了時刻判定部１１１はメディアデータの受信が終了しているとは判定しない。したがって、クライアントはメディアデータを受信できる状態をそのまま維持し、その後にバーストエラーが終了した時点でメディアデータの受信を再開する。
【００４５】
このように、本実施の形態のコンテンツ受信再生装置によれば、再生時間が指定されていないコンテンツを再生する場合において、伝送誤り等によってメディアデータの終了を通知するＢＹＥパケットの損失が生じても、メディアデータの受信不能状態が所定時間継続した場合で、且つその間にパケットの誤りが検出されなければ、メディアデータの送信が終了したと判定するので、速やかに次のメディアデータの受信を再開することが可能となる。
【００４６】
また、伝送誤り等によるパケットの誤りが検出されれば、メディアデ−タの受信待ち状態を維持するので、バースト誤り等によってメディアデータの受信が一時的に中断した場合に、誤ってセッションを中断してしまって再生を停止してしまい、後続のデータを再生できなくなる事態を回避することが可能となる。
【００４７】
なお、上記実施の形態では、コンテンツを受信して再生するコンテンツ受信再生装置について述べたが、コンテンツ制御部１０７を取り除いてコンテンツの受信のみを行うパケット受信装置としてもよい。図４にそのパケット受信装置の構成を示す。
【００４８】
また、上記実施の形態では、コンテンツの受信再生をハードウェア構成で行う場合について説明したが、これに限るものではなく、このコンテンツ受信再生をソフトウェアとして行うことも可能である。例えば、コンテンツ受信再生を行うプログラムをコンピュータで読み取り可能な記録媒体に格納し、このプログラムをコンピュータのＲＡＭ（Random Access Memory）に記録して、コンピュータをそのプログラムに従って動作させるようにしてもよい。
【００４９】
このパケット受信プログラムは、例えば、サーバから送信されたパケットを受信するパケット受信手順と、パケット受信手順にて受信されたパケットの伝送誤りを検出する誤りパケット検出手順と、誤りパケット検出手順にて検出された誤りパケットを破棄するパケット破棄手順と、パケット受信手順にて伝送誤り無く受信されたパケットより音声データや動画データであるメディアデータを受信するメディア受信手順と、メディア受信手順がメディアデータの受信開始後、メディアデータの受信不能状態が所定時間継続した場合で、且つその間に誤りパケット検出手順にてパケットの誤りが検出されなければ、メディアデータの送信が終了したことを判定し、メディアデータの受信不能状態が所定時間継続した場合でも、その間に誤りパケット検出手順にてパケットの誤りが検出されれば、サーバからのメディアデータの送信が終了していないと判定するデータ終了判定手順と、を具備するものである。
【００５０】
ソフトウェアで制御する場合においても、上記実施の形態と同様の作用および効果を呈する。すなわち、伝送誤り等によってメディアデータの終了を通知するパケットの損失が生じても、メディアデータの受信不能状態が所定時間継続した場合で、且つその間にパケットの誤りが検出されなければ、メディアデータの送信が終了したと判定するので、速やかに次のメディアデータの受信を再開することが可能となる。また、伝送誤り等によるパケットの損失がある場合にはメディアデ−タの受信待ち状態を維持するので、バースト誤り等によってメディアデータの受信が一時的に中断した場合に、誤ってセッションを中断してしまう事態を低減させることが可能となる。
【００５１】
コンテンツ受信再生を行うプログラムを記録する記録媒体としては、上記ＲＡＭなどの半導体記憶手段の他、磁気記憶手段、光記憶手段又は光磁気記憶手段であっても構わない。
【００５２】
また、上記実施の形態では、コンテンツ記述言語としてＳＭＩＬを用いたが、他の記述言語としてＨＴＭＬを用いてもよい。また、コンテンツを記述せずに単にメディアを繰り返し再生する場合でもよい。
【００５３】
また、上記実施の形態では、コンテンツに含まれる複数のメディアを連続再生する場合について説明したが、１つのメディアをライブ中継するようなコンテンツでもよい。ライブ中継の場合は、終了時刻が明示されないことが多いので、本発明に用いることによって、ライブ中継コンテンツであっても正しく再生を終了することができる。
【００５４】
【発明の効果】
以上説明したように、本発明によれば、再生時間が指定されていないコンテンツを再生する場合であり、かつＢＹＥパケットが正しく受信されなかった場合であっても、終了時間を適切に判定することができる。さらに、パケット損失による再生の中断が発生した場合であっても、パケット損失を監視して終了時刻判定に用いるので、誤ってメディアデータの終了と判断して再生を停止してしまい後続のデータを再生できなくなる事態を回避することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るコンテンツ受信再生装置の構成を示すブロック図
【図２】本発明の実施の形態に係るコンテンツ受信再生装置のメディア連続再生時の動作を説明するためのシーケンス図
【図３】本発明の実施の形態に係るコンテンツ受信再生装置のメディア連続再生時の動作を説明するためのシーケンス図
【図４】本発明の実施の形態に係るパケット受信装置の構成を示すブロック図
【図５】ＳＭＩＬを用いたコンテンツ配信を説明するための図
【図６】ＳＭＩＬで記述された内容を説明するための図
【図７】メディアを連続再生する場合のシーケンス図
【図８】従来のメディア連続再生時の問題を説明するためのシーケンス図
【符号の説明】
１０１ アンテナ
１０２ 送受信部
１０３ ＩＰパケット送受信部
１０４ ＴＣＰ送受信部
１０５ ＵＤＰ受信部
１０６ ＲＴＰ受信部
１０７ コンテンツ制御部
１０８ 再生表示部
１０９ 制御コマンド送受信部
１１０ パケット損失監視部
１１１ 終了時刻判定部
Claims (17)
- メディアデータを含むパケットと前記メディアデータの終了を通知するメディアデータ終了信号を含むパケットとを受信するパケット受信手段と、
前記パケット受信手段で受信したパケットの誤りを検出し、誤りが検出されたパケットを破棄するパケット破棄手段と、
前記パケット破棄手段によって破棄されなかったパケットが入力されるメディア受信手段と、
前記メディア受信手段においてパケットが入力されない場合、前記パケット破棄手段におけるパケットの誤りの検出状況に応じてパケットの受信状況を判定するパケット終了判定手段と、を備えたパケット受信装置。 - 前記パケット終了判定手段は、前記メディア受信手段においてパケットが入力されず、且つ前記パケット破棄手段におけるパケットの誤りが検出された場合、パケットの受信が終了していないと判定する請求項１記載のパケット受信装置。
- 前記パケット終了判定手段は、前記メディア受信手段においてパケットが入力されず、且つ前記パケット破棄手段におけるパケットの誤りが検出されない場合、所定時間経過後にパケットの受信が終了したと判定する請求項１または請求項２記載のパケット受信装置。
- 前記パケット破棄手段で検出されたパケットの誤りの有無が入力されることにより、パケットの誤り状況を監視し、パケット損失情報をパケット終了判定手段に出力するパケット監視手段を設け、前記パケット終了判定手段は、前記メディア受信手段においてパケットが入力されない場合、前記パケット監視手段からのパケット損失情報に応じてパケットの受信状況を判定するようにした請求項１から請求項３のいずれか１項記載のパケット受信装置。
- ＩＰパケットを受信する受信部と、
前記受信部で受信したパケットの誤りを検出し、誤りが検出されたＩＰパケットを破棄するＩＰパケット破棄部と、
前記ＩＰパケット破棄部により破棄されなかったＩＰパケットの誤りを検出し、誤りが検出されたＵＤＰパケットを破棄するＵＤＰパケット破棄部と、
前記ＵＤＰパケット破棄部により破棄されなかったＵＤＰパケットのうち、ＲＴＰパケットが入力されるＲＴＰパケット受信部と、
前記ＩＰパケット破棄部で検出されたパケットの誤りの有無と前記ＵＤＰパケット破棄部で検出されたパケットの誤りの有無とが入力されることにより、パケットの誤り状況を監視するパケット監視部と、
前記ＲＴＰパケット受信部にＲＴＰパケットが入力されない状態で、前記パケット監視部がパケットの誤りを検出した場合は、パケットの送信は終了していないと判定し、前記ＲＴＰパケット受信部にＲＴＰパケットが入力されない状態で、前記パケット監視部がパケットの誤りを検出しない場合には、パケットの受信が終了したと判定するパケット終了判定手段と、を備えたパケット受信装置。 - 前記メディア受信手段でメディアデータ終了信号が入力された場合、前記パケット終了判定手段は、パケットの受信が終了したと判定する請求項１から請求項５のいずれか１項記載のパケット受信装置。
- 請求項１から請求項６のいずれか１項記載のパケット受信装置に、さらに、前記パケット終了判定手段がパケットの受信が終了したと判定した場合、送信側にセッション終了信号を送信する送信手段を備えたパケット送受信装置。
- 請求項１から請求項６のいずれか１項記載のパケット受信装置、もしくは、請求項７記載のパケット送受信装置と、前記メディア受信手段で入力されたパケットに含まれるメディアデータを再生・表示する再生表示手段と、を備えたパケット受信再生装置。
- メディアデータを含むパケットと前記メディアデータの終了を通知するメディアデータ終了信号を含むパケットとを受信するパケット受信手順と、
前記パケット受信手順で受信したパケットの誤りを検出し、誤りが検出されたパケットを破棄するパケット破棄手順と、
前記パケット破棄手順によって破棄されなかったパケットが入力されるメディア受信手順と、
前記メディア受信手順においてパケットが入力されない場合、前記パケット破棄手順におけるパケットの誤りの検出状況に応じてパケットの受信状況を判定するパケット終了判定手順と、を備えたパケット受信方法。 - 前記パケット終了判定手順は、前記メディア受信手順においてパケットが入力されず、且つ前記パケット破棄手順におけるパケットの誤りが検出された場合、パケットの受信が終了していないと判定する請求項９記載のパケット受信方法。
- 前記パケット終了判定手順は、前記メディア受信手順においてパケットが入力されず、且つ前記パケット破棄手順におけるパケットの誤りが検出されない場合、所定時間経過後にパケットの受信が終了したと判定する請求項９または請求項１０記載のパケット受信方法。
- 前記パケット破棄手順で検出されたパケットの誤りの有無が入力されることにより、パケットの誤り状況を監視し、パケット損失情報をパケット終了判定手段に出力するパケット監視手順を設け、前記パケット終了判定手順は、前記メディア受信手順においてパケットが入力されない場合、前記パケット監視手順からのパケット損失情報に応じてパケットの受信状況を判定するようにした請求項９から請求項１１のいずれか１項記載のパケット受信方法。
- ＩＰパケットを受信する受信手順と、
前記受信手順で受信したパケットの誤りを検出し、誤りが検出されたＩＰパケットを破棄するＩＰパケット破棄手順と、
前記ＩＰパケット破棄手順により破棄されなかったＩＰパケットの誤りを検出し、誤りが検出されたＵＤＰパケットを破棄するＵＤＰパケット破棄手順と、
前記ＵＤＰパケット破棄手順により破棄されなかったＵＤＰパケットのうち、ＲＴＰパケットが入力されるＲＴＰパケット受信手順と、
前記ＩＰパケット破棄手順で検出されたパケットの誤りの有無と前記ＵＤＰパケット破棄手順で検出されたパケットの誤りの有無とが入力されることにより、パケットの誤り状況を監視するパケット監視手順と、
前記ＲＴＰパケット受信手順にＲＴＰパケットが入力されない状態で、前記パケット監視手順がパケットの誤りを検出した場合は、パケットの送信は終了していないと判定し、前記ＲＴＰパケット受信手順にＲＴＰパケットが入力されない状態で、前記パケット監視部がパケットの誤りを検出しない場合には、パケットの受信が終了したと判定するパケット終了判定手順と、を備えたパケット受信方法。 - 前記メディア受信手順でメディアデータ終了信号が入力された場合、前記パケット終了判定手順は、パケットの受信が終了したと判定する請求項９から請求項１３のいずれか１項記載のパケット受信方法。
- 請求項９から請求項１４のいずれか１項記載のパケット受信方法に、さらに前記パケット終了判定手順がパケットの受信が終了したと判定した場合、送信側にセッション終了信号を送信する送信手順を備えたパケット送受信方法。
- 請求項９から請求項１４のいずれか１項記載のパケット受信方法、もしくは、請求項１５のパケット送受信方法と、前記メディア受信手順で入力されたパケットに含まれるメディアデータを再生・表示する再生表示手順と、を備えたパケット受信再生方法。
- メディアデータを含むパケットを送信するサーバと、
前記サーバから送信されたパケットを受信するパケット受信手段と、
前記パケット受信手段で受信したパケットのうち、誤りがあるパケットを破棄するパケ ット破棄手段と、
前記パケット破棄手段によって破棄されなかったパケットが入力されるメディアデータ受信手段と、
前記メディア受信手段におけるパケットが入力されない場合、パケット破棄手段におけるパケット破棄状況に応じてパケットの送信状況を判定するパケット終了判定手段と、
前記パケット終了判定手段がサーバからのパケットの送信が終了したと判断した場合、サーバにセッション終了信号を送信する送信手段と、を備えたパケット送受信システム。
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001161398A JP3569241B2 (ja) | 2001-05-29 | 2001-05-29 | パケット受信装置及びパケット受信方法 |
| EP02726448.0A EP1301009B1 (en) | 2001-05-29 | 2002-05-21 | Packet reception apparatus and packet reception method |
| CNB028023331A CN1198435C (zh) | 2001-05-29 | 2002-05-21 | 内容接收和播放装置和数据包接收方法 |
| PCT/JP2002/004901 WO2002098109A1 (en) | 2001-05-29 | 2002-05-21 | Packet reception apparatus and packet reception method |
| US10/333,587 US7296081B2 (en) | 2001-05-29 | 2002-05-21 | Packet reception apparatus and packet reception method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001161398A JP3569241B2 (ja) | 2001-05-29 | 2001-05-29 | パケット受信装置及びパケット受信方法 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004144151A Division JP2004289862A (ja) | 2004-05-13 | 2004-05-13 | パケット受信装置及びパケット受信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002354032A JP2002354032A (ja) | 2002-12-06 |
| JP3569241B2 true JP3569241B2 (ja) | 2004-09-22 |
Family
ID=19004679
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001161398A Expired - Fee Related JP3569241B2 (ja) | 2001-05-29 | 2001-05-29 | パケット受信装置及びパケット受信方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7296081B2 (ja) |
| EP (1) | EP1301009B1 (ja) |
| JP (1) | JP3569241B2 (ja) |
| CN (1) | CN1198435C (ja) |
| WO (1) | WO2002098109A1 (ja) |
Families Citing this family (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3821086B2 (ja) * | 2002-11-01 | 2006-09-13 | ソニー株式会社 | ストリーミングシステム及びストリーミング方法、クライアント端末及びデータ復号方法、並びにプログラム |
| EP1673773A4 (en) * | 2003-09-25 | 2008-11-19 | Samsung Electronics Co Ltd | APPARATUS AND METHOD FOR PRESENTING MULTIMEDIA DATA COMBINED WITH TEXT, AND RECORDING MEDIUM CONTAINING A PROGRAM FOR EXECUTING SAID METHOD |
| CN1305276C (zh) * | 2004-01-15 | 2007-03-14 | 中兴通讯股份有限公司 | 一种快速处理实时媒体流数据包的方法及其系统 |
| KR100652650B1 (ko) * | 2004-07-28 | 2006-12-06 | 엘지전자 주식회사 | 서비스 음영지역에서 동기화를 위한 피티티 서비스 시스템및 방법 |
| US20060149811A1 (en) * | 2004-12-31 | 2006-07-06 | Sony Ericsson Mobile Communications Ab | Method for remotely controlling media devices via a communication network |
| US8473617B2 (en) | 2004-12-31 | 2013-06-25 | Sony Corporation | Media client architecture for networked communication devices |
| CN1855910B (zh) * | 2005-04-27 | 2010-12-15 | 国际商业机器公司 | 基于Web的统一通信系统和方法以及Web通信管理器 |
| CN100512300C (zh) * | 2006-01-13 | 2009-07-08 | 华为技术有限公司 | 一种在传输实时流时业务切换的方法 |
| US7769014B2 (en) * | 2007-02-13 | 2010-08-03 | Seiko Epson Corporation | Transmitting and receiving system, transmitting apparatus, and receiving apparatus |
| US8774203B2 (en) * | 2007-06-07 | 2014-07-08 | Intel Corporation | One-way message notification with out-of-order packet delivery |
| US9831966B2 (en) * | 2007-06-18 | 2017-11-28 | Nokia Technologies Oy | Method and device for continuation of multimedia playback |
| JP4735680B2 (ja) * | 2008-08-12 | 2011-07-27 | ソニー株式会社 | 同期回路及び同期方法 |
| WO2010023890A1 (ja) * | 2008-08-28 | 2010-03-04 | パナソニック株式会社 | 無線伝送装置、無線伝送方法、プログラム、及び集積回路 |
| CN101753367B (zh) * | 2008-11-28 | 2013-03-20 | 北京邮电大学 | 基于势函数构造拥塞丢包隶属度函数的方法 |
| US8554851B2 (en) | 2010-09-24 | 2013-10-08 | Intel Corporation | Apparatus, system, and methods for facilitating one-way ordering of messages |
| CN102571479B (zh) * | 2010-12-31 | 2014-12-10 | 中国移动通信集团河北有限公司 | 延时的测量方法、装置及系统 |
| ITTO20130376A1 (it) * | 2013-05-10 | 2014-11-11 | Recwon S R L | Metodo per la registrazione di una pluralità di file audio |
| CN108347718B (zh) * | 2018-02-02 | 2021-07-30 | 北京小米移动软件有限公司 | 监听通信包的方法、装置以及存储介质 |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0230253A (ja) | 1988-07-20 | 1990-01-31 | Ricoh Co Ltd | ワークステーション装置の制御方法 |
| JPH04307838A (ja) | 1991-04-05 | 1992-10-30 | Matsushita Electric Ind Co Ltd | データ送受信方法 |
| JPH0653990A (ja) | 1992-07-29 | 1994-02-25 | Nec Corp | 電子計算機 |
| US5450425A (en) * | 1993-11-19 | 1995-09-12 | Multi-Tech Systems, Inc. | Protocol for communication of a data packet |
| JPH10215278A (ja) | 1997-01-30 | 1998-08-11 | Fujitsu Ltd | 無通信回避方法および装置 |
| US6031818A (en) * | 1997-03-19 | 2000-02-29 | Lucent Technologies Inc. | Error correction system for packet switching networks |
| JPH11243419A (ja) * | 1998-02-26 | 1999-09-07 | Fujitsu Ltd | Ｔｃｐレイヤのレート制御方式 |
| JPH11341046A (ja) | 1998-05-26 | 1999-12-10 | Nec Corp | 通信処理システム、装置及び方法 |
| FI105734B (fi) * | 1998-07-03 | 2000-09-29 | Nokia Networks Oy | Automaattinen uudelleenlähetys |
| JP2000078557A (ja) | 1998-08-31 | 2000-03-14 | Canon Inc | 映像データ通信装置および映像ネットワークシステム、映像データ通信方法、記録媒体 |
| DE69938094T2 (de) * | 1998-11-30 | 2009-02-05 | Matsushita Electric Industries Co. Ltd., Kadoma | Paketwiederübertragungskontrolle mit Prioritätsinformationen |
| JP4028111B2 (ja) | 1998-12-03 | 2007-12-26 | 古河電気工業株式会社 | 通信装置及び記録媒体 |
| US6757256B1 (en) * | 1999-08-10 | 2004-06-29 | Texas Instruments Incorporated | Process of sending packets of real-time information |
| US6680955B1 (en) * | 1999-08-20 | 2004-01-20 | Nokia Networks Oy | Technique for compressing a header field in a data packet |
| JP3478259B2 (ja) | 2000-10-23 | 2003-12-15 | 日本電信電話株式会社 | ストリーム中継制御装置、ストリーム中継制御システム、ストリーム中継制御方法，ならびに該方法を記録した記録媒体 |
| US7007209B2 (en) * | 2002-02-25 | 2006-02-28 | Richard Charles Jaworski | System of testing the upstream cable modem channel |
| US7251690B2 (en) * | 2002-08-07 | 2007-07-31 | Sun Microsystems, Inc. | Method and system for reporting status over a communications link |
-
2001
- 2001-05-29 JP JP2001161398A patent/JP3569241B2/ja not_active Expired - Fee Related
-
2002
- 2002-05-21 WO PCT/JP2002/004901 patent/WO2002098109A1/ja active Application Filing
- 2002-05-21 EP EP02726448.0A patent/EP1301009B1/en not_active Expired - Lifetime
- 2002-05-21 US US10/333,587 patent/US7296081B2/en not_active Expired - Fee Related
- 2002-05-21 CN CNB028023331A patent/CN1198435C/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CN1198435C (zh) | 2005-04-20 |
| EP1301009A1 (en) | 2003-04-09 |
| WO2002098109A1 (en) | 2002-12-05 |
| EP1301009B1 (en) | 2015-07-01 |
| CN1465170A (zh) | 2003-12-31 |
| US20030156544A1 (en) | 2003-08-21 |
| EP1301009A4 (en) | 2005-10-26 |
| US7296081B2 (en) | 2007-11-13 |
| JP2002354032A (ja) | 2002-12-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3569241B2 (ja) | パケット受信装置及びパケット受信方法 | |
| JP3631439B2 (ja) | 非信頼ネットワークにおけるデータ伝送方法及び装置 | |
| US6990512B1 (en) | Method and system for using live time shift technology to control a multimedia file | |
| US6754715B1 (en) | Methods and apparatus for implementing control functions in a streamed video display system | |
| US20060195884A1 (en) | Interactive multichannel data distribution system | |
| JP2005110244A (ja) | マルチメディアストリーミングサービスシステム及びその方法 | |
| US8806048B2 (en) | Method and apparatus for transmitting and receiving streaming data based on real-time streaming protocol (RTSP) session | |
| WO2008020547A1 (fr) | Dispositif de traitement des communications, procédé de commande des communications, et programme informatique | |
| JP2005522916A (ja) | ダウンロードとストリーミングを組み合わせる伝送方法 | |
| JP2004272712A (ja) | 受信装置および情報閲覧方法 | |
| JP2001242876A (ja) | データ受信再生方法、データ受信再生装置、データ送信方法、およびデータ送信装置 | |
| KR101164746B1 (ko) | 실시간 스트리밍 프로토콜을 기반으로 한 동영상 재생 서비스에서 동영상 재생 지연 보상 시스템 및 방법 | |
| JP5264349B2 (ja) | 映像受信装置及び映像受信方法 | |
| WO2010057391A1 (zh) | 一种流媒体播放控制方法、设备及系统 | |
| KR20080062692A (ko) | 스트림 녹화 방법, 장치 및 시스템 | |
| JP2004007172A (ja) | 情報配信システム、情報配信装置および方法、情報端末装置および情報処理方法、記録媒体、並びにプログラム | |
| JP2004289862A (ja) | パケット受信装置及びパケット受信方法 | |
| JP2005167891A (ja) | コンテンツサーバ、コンテンツ受信装置、プログラム及び記憶媒体 | |
| WO2014073202A1 (ja) | 情報処理装置、情報処理方法、コンテンツ配信システム及びコンピュータプログラム記録媒体 | |
| KR100624854B1 (ko) | 미디어 재전송 장치 및 방법 | |
| WO2005006760A1 (en) | Method and system for uneven distribution of data | |
| JP2005110013A (ja) | 受信装置、受信方法および受信プログラム | |
| JP4635801B2 (ja) | 情報処理装置及び情報処理方法 | |
| KR100621313B1 (ko) | 데이터 버퍼링 장치 및 방법 | |
| JP2006185384A (ja) | コンテンツサーバ、コンテンツ受信装置、プログラム及び記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040316 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040513 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040615 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040617 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080625 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080625 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090625 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100625 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100625 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110625 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120625 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120625 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130625 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |