JP2005086362A - Data multiplexing method, data transmitting method and data receiving method - Google Patents
Data multiplexing method, data transmitting method and data receiving method Download PDFInfo
- Publication number
- JP2005086362A JP2005086362A JP2003314530A JP2003314530A JP2005086362A JP 2005086362 A JP2005086362 A JP 2005086362A JP 2003314530 A JP2003314530 A JP 2003314530A JP 2003314530 A JP2003314530 A JP 2003314530A JP 2005086362 A JP2005086362 A JP 2005086362A
- Authority
- JP
- Japan
- Prior art keywords
- data
- response
- size information
- header
- fragment
- 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.)
- Pending
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Television Systems (AREA)
Abstract
Description
本発明は、動画像データや音声データ等のメディアデータの多重化方法、多重化したデータの送信方法および多重化したデータの受信方法に関し、特に、ライブストリーミング再生を行なうためのデータ多重化方法、データ送信方法およびデータ受信方法に関する。 The present invention relates to a method for multiplexing media data such as moving image data and audio data, a method for transmitting multiplexed data, and a method for receiving multiplexed data, and in particular, a data multiplexing method for performing live streaming playback, The present invention relates to a data transmission method and a data reception method.
近年、通信ネットワークの大容量化および伝送技術の進歩により、インターネット上で、動画、音声、テキスト、あるいは、静止画等のマルチメディアコンテンツを含む動画像ファイルをパーソナルコンピュータに配信する動画配信サービスの普及が著しい。また、携帯端末等のいわゆる第３世代の移動体通信システムの規格の標準化を図ることを目的とする国際標準化団体3GPP(Third Generation Partnership Project)で、無線による動画配信に関する規格としてTS26.234(Transparent end-to-end packet switched streaming service)が定められる等の動きも見られ、動画配信サービスは、携帯電話機やＰＤＡ等の移動体通信端末への提供の拡大も見込まれている。 In recent years, with the increase in communication network capacity and advances in transmission technology, the spread of video distribution services that distribute video files including multimedia content such as video, audio, text, or still images to personal computers over the Internet Is remarkable. Also, the international standardization organization 3GPP (Third Generation Partnership Project), which aims to standardize the standard of so-called third generation mobile communication systems such as mobile terminals, is the TS26.234 (Transparent The end-to-end packet switched streaming service has been established, and the video distribution service is expected to be expanded to mobile communication terminals such as mobile phones and PDAs.
動画配信サービスにおいて、動画像ファイルを配信する際には、まず、多重化装置において、動画、静止画、音声およびテキスト等のメディアデータを取り込んで、メディアデータの再生に必要なヘッダ情報とメディアデータの実体データとを多重化して動画像ファイルデータを作成することが必要となるが、この動画像ファイルデータの多重化ファイルフォーマットとして、ＭＰ４ファイルフォーマットが注目されている。 When distributing a moving image file in a moving image distribution service, first, the multiplexing device captures media data such as a moving image, a still image, audio and text, and header information and media data necessary for reproducing the media data. However, the MP4 file format is attracting attention as a multiplexed file format of the moving image file data.
このＭＰ４ファイルフォーマットは、国際標準化団体であるISO/IEC(International Standardization Organization/International Engineering Consortium) JTC1/SC29/WG 11において標準化が進められている多重化ファイルフォーマットであり、上記3GPPのTS26.234でも採用されていることから、広く普及するものと予想されている。
ここで、ＭＰ４ファイルのデータ構造について説明する。なお、このＭＰ４ファイルのデータ構造については、非特許文献１に開示されている。
This MP4 file format is a multiplexed file format that is being standardized by the international standardization organization ISO / IEC (International Standardization Organization / International Engineering Consortium) JTC1 / SC29 / WG11. Because it is adopted, it is expected to be widely spread.
Here, the data structure of the MP4 file will be described. The data structure of this MP4 file is disclosed in
ＭＰ４ファイルは、ボックスと呼ばれるオブジェクト単位でヘッダ情報やメディアデータの実体データが格納されており、複数のボックスを階層的に配列することによって構成される。 The MP4 file stores entity information such as header information and media data in units of objects called boxes, and is configured by arranging a plurality of boxes hierarchically.
図２２は、ＭＰ４ファイルを構成するボックスの構造を説明するための図である。
ボックス９０１は、ボックス９０１のヘッダ情報が格納されるボックスヘッダ部９０２と、ボックス９０１に含まれるデータ（例えば、そのボックスの下の階層のボックスや情報を記述するためのフィールド等）が格納されるボックスデータ格納部９０３とから構成される。
FIG. 22 is a diagram for explaining the structure of boxes constituting an MP4 file.
The
このボックスヘッダ部９０２は、ボックスサイズ９０４、ボックスタイプ９０５、バージョン９０６、フラグ９０７のフィールドを有している。
ボックスサイズ９０４は、このフィールドに割り当てられたバイトサイズも含めてボックス９０１全体のサイズ情報が記述されるフィールドである。
ボックスタイプ９０５は、ボックス９０１の種別を識別するための識別子が記述されるフィールドである。この識別子は、通常４つのアルファベット文字列によって表される。なお、以下、本明細書中において、この識別子によって各ボックスを示す場合がある。
The
The
The
バージョン９０６は、ボックス９０１のバージョンを示すバージョン番号が記述されるフィールドであり、フラグ９０７は、ボックス９０１毎に設定されるフラグ情報が記述されるフィールドである。このバージョン９０６とフラグ９０７は、全てのボックス９０１に必須のフィールドではないので、これらのフィールドを有しないボックス９０１も存在しうる。
The
このような構造のボックス９０１が複数連なって構成されるＭＰ４ファイルは、ファイルの構成に不可欠な基本部と、必要に応じて使用される拡張部とに大別することができる。まず、ＭＰ４ファイルの基本部について説明する。
図２３は、従来のＭＰ４ファイルの基本部を説明するための図である。
ＭＰ４ファイル９１０の基本部９１１は、ファイルヘッダ部９１２とファイルデータ部９１３とから構成される。
An MP4 file composed of a plurality of
FIG. 23 is a diagram for explaining a basic part of a conventional MP4 file.
The
ファイルヘッダ部９１２は、ファイル全体のヘッダ情報、例えば、動画像（ビデオ）データの圧縮符号化方式等の情報が格納される部分であり、ファイルタイプボックス９１４とムービーボックス９１５とから構成される。
ファイルタイプボックス９１４は、"ｆｔｙｐ"の識別子で識別されるボックスであり、ＭＰ４ファイルを識別するための情報が格納される。ＭＰ４ファイルにどのようなメディアデータを格納するかについて、また、どのような圧縮符号化方式を用いた動画像（ビデオ）データや音声（オーディオ）データ等を格納するかについては、標準化団体やサービス事業者が独自に規定することができるため、ＭＰ４ファイルがどの規定に従って作成されたものであるかを識別するための情報を、このファイルタイプボックス９１４に格納する。
The
The
ムービーボックス９１５は、"ｍｏｏｖ"の識別子で識別されるボックスであり、ファイルデータ部９１３に格納される実体データのヘッダ情報、例えば、表示時間長等の情報が格納される。また、このムービーボックス９１５には、ビデオトラックやオーディオトラック等、トラック毎のヘッダ情報が格納されている。なお、ここにいうトラックとは、ＭＰ４ファイル９１０に含まれる各メディアのサンプルデータ全体を意味し、動画像や音声やテキスト等のトラックは、それぞれビデオトラック、オーディオトラックやテキストトラック等と称される。また、ＭＰ４ファイル９１０内に同一メディアのデータが複数存在する場合は、同一メディアに対して複数のトラックが存在することになる。具体的に説明すると、例えば、ＭＰ４ファイル９１０内に２種類の動画像データが含まれている場合、２つのビデオトラックが存在することになる。
The
ファイルデータ部９１３は、"ｍｄａｔ"の識別子で識別されるムービーデータボックス９１６によって構成される。なお、このファイルデータ部９１３の代わりに、このＭＰ４ファイル９１０とは異なる外部のファイルを参照することもできる。このように、外部のファイルを参照する場合には、ＭＰ４ファイル９１０の基本部９１１は、ファイルヘッダ部９１２のみから構成されることになる。本明細書では、この外部ファイルの参照をする場合ではなく、ＭＰ４ファイル９１０内に実体データを含む場合について説明する。
The
ムービーデータボックス９１６は、サンプルと称される単位でメディアデータの実体データを格納するボックスである。このサンプルとは、ＭＰ４ファイルにおける最小のアクセス単位であり、MPEG(Moving Picture Experts Group)-4 Visualの圧縮符号化方式によって符号化したビデオデータのVOP(Video Object Plane)やオーディオデータのフレームに相当するものである。
The
ＭＰ４ファイルフォーマットの標準化当初、ＭＰ４ファイル９１０は、上記基本部９１１のみから構成されていた。しかし、基本部９１１のみから構成されるＭＰ４ファイル９１０では、全てのヘッダ情報が格納されるムービーボックス９１５が、コンテンツ全体の符号化データが揃うまで作成されないので、コンサート中継やスポーツ中継等のライブコンテンツの配信、いわゆるライブストリーミングを実現することができないという問題があった。また、ライブコンテンツの時間長に比例してムービーボックス９１５のサイズが増大するため、ライブコンテンツが長時間になればなる程、ムービーボックス９１５のダウンロードに要する時間が長くなり、ストリーミング再生時における初期遅延時間が増大するという問題があった。
At the beginning of standardization of the MP4 file format, the
このように、標準化当初のＭＰ４ファイルフォーマットには、ストリーミング再生への適用が難しい等の問題があり、ＭＰ４ファイルフォーマットは、ヘッダボックスとデータボックスとの組が複数連なる拡張部の使用を加える改良がなされている。 As described above, the MP4 file format at the time of standardization has a problem that it is difficult to apply to streaming playback, and the MP4 file format is improved by using an extension unit in which a plurality of pairs of header boxes and data boxes are used. Has been made.
図２４は、従来における拡張部を含むＭＰ４ファイルの構造を示す図である。
図２４に示すように、上記改良が加えられたＭＰ４ファイル９２０は、基本部９１１と拡張部９２１とから構成される。この拡張部９２１を含むＭＰ４ファイル９２０では、全てのメディアデータを拡張部９２１に格納することができるので、ＭＰ４ファイル基本部９１１のムービーデータボックス９１６を省略することとしてもよい。
FIG. 24 is a diagram showing a structure of a conventional MP4 file including an extension unit.
As shown in FIG. 24, the
拡張部９２１は、所定の単位で区切られたパケット９２２が複数連なって構成される。
このパケット９２２は、ムービーフラグメントボックス９２３とムービーデータボックス９１６とが一対となって構成され、ムービーフラグメントとも称される（以下、本明細書では、「フラグメント」と略記する。）
ムービーデータボックス９１６は、上記区切られた所定の単位でトラック毎のサンプルを格納し、ムービーフラグメントボックス９２３は、このムービーデータボックス９１６に対応するヘッダ情報を格納するためのボックスであり、"ｍｏｏｆ"という識別子によって識別される。
The
The
The
なお、このとき、ＭＰ４ファイル９２０の基本部９１１のムービーデータボックス９１６を省略した場合、基本部９１１のムービーボックス９１５には、コンテンツ全体に共通のヘッダ情報、例えば、コンテンツ全体の再生時間長や符号化方式等が格納されることになる。また、ＭＰ４ファイル９２０の基本部９１１のムービーデータボックス９１６を省略せずにコンテンツの先頭部分のデータが格納されている場合、基本部９１１のムービーボックス９１５には、コンテンツ全体に共通のヘッダ情報と、そのデータのサンプル単位のヘッダ情報が格納されることになる。本明細書では、ＭＰ４ファイル基本部９１１のムービーデータボックス９１６は省略され、基本部９１１のムービーボックス９１５には、上記共通のヘッダ情報のみが格納されていることとする。さらに、各フラグメントは、フラグメントに含まれる各メディアの先頭サンプルの再生開始時間が揃うように作成されているものとする。具体的には、オーディオデータやビデオデータ、あるいは、テキストデータのサンプルのうち、互いの再生開始時間が最も近いサンプルをフラグメントの先頭サンプルとして格納する。
At this time, when the
このようなＭＰ４ファイルの改良によって、ビデオデータやオーディオデータを取り込んで符号化するエンコーダは、コンテンツ全体の符号化データが揃わなくても、所定の単位分の符号化データが揃った段階でフラグメントを生成することができ、また、ライブコンテンツを格納したＭＰ４ファイルをクライアント端末に配信するサーバは、フラグメント単位でＭＰ４ファイルをクライアント端末に配信することができるようになるので、ストリーミング再生を実現することが可能となっている。 With such improvements to the MP4 file, an encoder that captures and encodes video data and audio data does not have all the encoded data for the entire content, but can encode fragments when the encoded data for a predetermined unit is complete. The server that can generate the MP4 file that stores the live content to the client terminal can distribute the MP4 file to the client terminal in units of fragments, thereby realizing streaming playback. It is possible.
また、サーバとクライアント端末とのデータのやり取りについては、通信プロトコルの規定に則る必要があるが、音声や映像をストリーミング再生するためのプロトコルとして、ＲＴＰ(Real-time Transport Protocol)やＵＤＰ(User Datagram Protocol)などの通信プロトコルが従来から用いられている。
しかしながら、上記の改良が加えられたＭＰ４ファイルにおいても、受信側のクライアント端末は、ファイルの先頭に位置するフラグメントからしかデータを取得することができないので、例えば、ライブコンテンツの途中から受信を開始する場合であっても、ライブコンテンツの最初から再生しなければならず、ライブコンテンツを実時間で再生することができないという問題がある。図を用いて詳しく説明する。 However, even in the MP4 file with the above improvements, the receiving client terminal can only acquire data from the fragment located at the beginning of the file, so for example, it starts receiving from the middle of live content Even in such a case, the live content must be reproduced from the beginning, and there is a problem that the live content cannot be reproduced in real time. This will be described in detail with reference to the drawings.
図２５は、従来におけるＭＰ４ファイルによるライブストリーミング時における問題点を説明するための図である。
エンコーダ９３０は、ビデオカメラ等であり、コンサートの映像および音声を記録して、ビデオデータとオーディオデータとを符号化および多重化することによって生成したＭＰ４ファイルのフラグメントを順次配信サーバ９４０に転送する。ここで、エンコーダ９３０から配信サーバ９４０に転送される最新のフラグメントをフラグメントＮとしておく。また、ＭＰ４ファイルのファイルタイプボックスとムービーボックスとを併せて初期ヘッダと称することにする。
FIG. 25 is a diagram for explaining a problem at the time of live streaming by a conventional MP4 file.
The
この時点で、クライアント端末９５０が、配信サーバ９４０にライブコンテンツの配信要求を送信すると、配信サーバ９４０は、初期ヘッダとＭＰ４ファイルの先頭のフラグメントをクライアント端末９５０に配信するので、クライアント端末９５０が再生するデータは、ライブコンテンツの実時間のデータに対して遅延してしまうことになり、ライブコンテンツをリアルタイムで再生することができない。
At this point, when the
また、配信サーバ９４０とクライアント端末９５０とを接続するネットワークの輻輳などで、ライブコンテンツのデータを実時間で配信することができない場合にも、クライアント端末９５０が再生するデータと、ライブコンテンツの実時間のデータとの間に遅延が生じてしまうという問題がある。
Further, even when live content data cannot be distributed in real time due to congestion of the network connecting the
さらに、ＲＴＰによる通信はリアルタイム性に優れるというメリットがあるものの、配信サーバおよびクライアント端末が共にＲＴＰに対応していなければならず、ＲＴＰに対応させるための増設コストがかかるという問題が生じうる。また、ＲＴＰでは、データが相手方に届くことは保証されないので、信頼性が低く、パケットロス対策などの品質制御機構が必要となるという問題もある。 Furthermore, although communication by RTP has the merit that it is excellent in real-time property, both the distribution server and the client terminal must be compatible with RTP, and there may be a problem that additional costs for supporting RTP are required. In addition, since RTP does not guarantee that data reaches the other party, there is a problem that reliability is low and a quality control mechanism such as a packet loss countermeasure is required.
そこで、本発明は、上記問題点に鑑みなされたものであり、増設コストをかけることなく、ライブコンテンツを格納したＭＰ４ファイルを実時間に対して低遅延で受信し、リアルタイムでの再生を実現することができるデータ受信方法を提供することを第１の目的とする。
また、本発明は、ネットワークの通信状態にかかわらず、リアルタイム性を維持してＭＰ４ファイルを低遅延で送信することができるデータ送信方法を提供することを第２の目的とする。
Therefore, the present invention has been made in view of the above problems, and realizes real-time playback by receiving an MP4 file storing live content with low delay relative to real time without incurring additional costs. It is a first object of the present invention to provide a data receiving method capable of receiving data.
A second object of the present invention is to provide a data transmission method capable of transmitting an MP4 file with low delay while maintaining real-time characteristics regardless of the communication state of the network.
さらに、本発明は、ライブコンテンツを格納したＭＰ４ファイルを低遅延で送受信する場合に、ライブコンテンツを構成する複数のメディア間の同期再生を実現することができるデータ多重化方法を提供することを第３の目的とする。 Furthermore, the present invention provides a data multiplexing method capable of realizing synchronized reproduction between a plurality of media constituting live content when transmitting and receiving MP4 files storing live content with low delay. The purpose of 3.
上記第１の目的を達成するために、本発明に係るデータ受信方法は、コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを、ネットワークで接続されたサーバ装置から受信するデータ受信方法であって、前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を前記サーバ装置に要求するデータ取得リクエストを作成するリクエスト作成ステップと、前記データ取得リクエストを、ＨＴＴＰ(Hypertext Transfer Protocol)によって前記サーバ装置に送信するリクエスト送信ステップと、前記データ取得リクエストに対する応答として、前記共通ヘッダおよび前記最新パケットを含むレスポンスを前記サーバ装置からＨＴＴＰによって受信するレスポンス受信ステップとを含むことを特徴とする。これによって、既存のＨＴＴＰを用いて、最新のフラグメントから受信を開始することができるので、増設コストをかけずに、ライブコンテンツの実時間に対して低遅延でデータを受信することが可能となる。 In order to achieve the first object, a data receiving method according to the present invention includes a common header that is a header common to all contents, a plurality of packets storing entity data of the content and header information of the entity data. Is a data reception method for receiving a file composed of: from a server device connected via a network, and requests the server device to distribute the latest packet storing the latest header data in the common header and the content A request creation step for creating a data acquisition request, a request transmission step for transmitting the data acquisition request to the server device by HTTP (Hypertext Transfer Protocol), and the common header and the latest packet as a response to the data acquisition request Responsible including The characterized in that it comprises a response reception step of receiving by HTTP from the server device. Accordingly, since reception can be started from the latest fragment using existing HTTP, it is possible to receive data with a low delay with respect to the real time of live content without incurring additional costs. .
また、上記第２の目的を達成するために、本発明に係るデータ送信方法は、コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを、ネットワークで接続された端末装置に送信するデータ送信方法であって、前記端末装置から前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を要求するデータ取得リクエストを受信するリクエスト受信ステップと、前記データ取得リクエストを解析して、前記最新パケットを決定する最新パケット判定ステップと、前記データ取得リクエストに対する応答であり、前記共通ヘッダと、前記最新パケット判定ステップにおいて決定した前記最新パケットとを含むレスポンスを作成するレスポンス作成ステップと、前記レスポンスを、ＨＴＴＰによって前記端末装置に送信するレスポンス送信ステップと、送信されるパケットに含まれる前記データの再生開始時間が、実時間で再生した場合に対してどれだけ遅延しているかを示す遅延時間を取得する遅延時間取得ステップと、前記遅延時間取得ステップにおいて取得した情報に基づいて、前記遅延時間が所定の閾値以上開いたか否かを判定する遅延判定ステップと、前記遅延判定ステップにおいて、前記遅延時間が所定の閾値以上開いたと判定した場合に、時間的に不連続となるパケットの送信を決定するスキップ決定ステップとを含み、前記レスポンス作成ステップにおいて、前記スキップ決定ステップにおける決定に基づいて、前記時間的に不連続となるパケットを含むスキップレスポンスを作成し、前記レスポンス送信ステップにおいて、前記スキップレスポンスをＨＴＴＰによって前記端末装置に送信することを特徴とする。これによって、ネットワークの通信状態が悪い場合でも、最新のフラグメントまでスキップすることができるので、リアルタイム性を維持してＭＰ４ファイルを低遅延で送信することができるようになる。 In order to achieve the second object, a data transmission method according to the present invention includes a common header that is a header common to all contents, a plurality of pieces of entity data of the contents, and header information of the entity data. Is a data transmission method for transmitting a file composed of a plurality of packets to a terminal device connected via a network, wherein the terminal device distributes the latest packet storing the common header and the latest entity data in the content. A request reception step for receiving a requested data acquisition request; a latest packet determination step for analyzing the data acquisition request to determine the latest packet; a response to the data acquisition request; the common header; The latest parameter determined in the packet determination step. A response generation step for generating a response including a packet, a response transmission step for transmitting the response to the terminal device by HTTP, and a reproduction start time of the data included in the transmitted packet is reproduced in real time. A delay time acquisition step for acquiring a delay time indicating how much is delayed with respect to the case, and based on the information acquired in the delay time acquisition step, whether or not the delay time is opened more than a predetermined threshold A delay determining step for determining, and a skip determining step for determining transmission of a packet that is temporally discontinuous when it is determined in the delay determining step that the delay time is opened by a predetermined threshold or more, and the response In the creating step, based on the determination in the skip determining step, During manner to create a skip response including a discontinuous packet in the response transmission step, and transmits the skip response to the terminal device by HTTP. As a result, even when the communication state of the network is bad, it is possible to skip to the latest fragment, so that the MP4 file can be transmitted with low delay while maintaining the real-time property.
さらに、上記第３の目的を達成するために、本発明に係るデータ多重化方法は、コンテンツに含まれる複数のメディアデータを多重化して、当該コンテンツ全体に共通のヘッダである共通ヘッダと、当該コンテンツの実体データおよび当該実体データのヘッダ情報を格納する複数のパケットとから構成されるファイルを作成するデータ多重化方法であって、１つ以上のパケット毎に前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を作成する同期情報作成ステップと、前記同期情報作成ステップにおいて作成した同期情報を含むファイルを作成するファイル作成ステップとを含むことを特徴とする。これによって、ライブストリーミング再生時においても同期情報を参照することができるので、同期再生を担保することができる。 Furthermore, in order to achieve the third object, a data multiplexing method according to the present invention multiplexes a plurality of media data included in a content, a common header that is a header common to the entire content, A data multiplexing method for creating a file composed of entity data of content and a plurality of packets storing header information of the entity data, between media data included in the packet for each one or more packets It includes a synchronization information creation step for creating synchronization information for synchronized playback, and a file creation step for creating a file including the synchronization information created in the synchronization information creation step. As a result, the synchronization information can be referred to even during live streaming reproduction, so that the synchronized reproduction can be ensured.
なお、本発明は、このようなデータ多重化方法、データ受信方法およびデータ送信方法として実現することができるだけでなく、このようなデータ多重化方法等に含まれる特徴的なステップを手段として備えたデータ多重化装置等として実現したり、また、それぞれの特徴的な全てのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。 The present invention can be realized not only as such a data multiplexing method, data receiving method, and data transmitting method, but also as a means including characteristic steps included in such a data multiplexing method. It can be realized as a data multiplexing device or the like, or can be realized as a program for causing a computer to execute all the characteristic steps. Needless to say, such a program can be distributed via a recording medium such as a CD-ROM or a transmission medium such as the Internet.
以上のように、本発明によれば、ライブコンテンツの実時間に対する遅延を生じさせずに、ＭＰ４ファイルのデータを取得することができるので、ライブコンテンツの途中から受信を開始する場合であっても、リアルタイム再生を実現することができるという効果が奏される。また、既存のＨＴＴＰを用いることができるので、サーバ装置や端末装置の増設コストが不要という効果もある。さらに、通信状態が悪い場合であっても、リアルタイム再生を維持することができ、ライブコンテンツを構成するメディア間の同期再生をも担保することができる。 As described above, according to the present invention, the MP4 file data can be acquired without causing a delay with respect to the real time of the live content. Therefore, even when reception is started in the middle of the live content. The effect that real-time reproduction can be realized is achieved. Moreover, since the existing HTTP can be used, there is an effect that the cost for adding a server device or a terminal device is unnecessary. Furthermore, even if the communication state is poor, real-time playback can be maintained, and synchronized playback between media constituting live content can be ensured.
以下、本発明を実施するための最良の形態について詳細に説明する。
（実施の形態１）
まず、本発明の実施の形態１に係るライブストリーミングシステムについて説明する。
図１は、本発明の実施の形態１に係るライブストリーミングシステムの全体構成を示す図である。
Hereinafter, the best mode for carrying out the present invention will be described in detail.
(Embodiment 1)
First, the live streaming system according to
FIG. 1 is a diagram showing an overall configuration of a live streaming system according to
このライブストリーミングシステムは、コンサート中継やスポーツ中継などのライブコンテンツをリアルタイムで配信する画像配信システムであり、コンサート等の映像や音声を記録して、ビデオデータとオーディオデータとを符号化および多重化するエンコーダ１０と、エンコーダ１０から多重化されたデータを取得して、蓄積させる配信サーバ２０と、配信サーバ２０からＨＴＴＰを用いてライブコンテンツのデータを受信するクライアント端末３０とから構成される。
This live streaming system is an image distribution system that distributes live content such as concert broadcasts and sports broadcasts in real time, records video and audio of concerts, etc., and encodes and multiplexes video data and audio data. The
ライブストリーミングシステムを構成するこれらの装置について、以下詳しく説明する。
図２は、クライアント端末３０の構成を示すブロック図である。
クライアント端末３０は、配信サーバ２０からライブコンテンツを格納したＭＰ４ファイルをリアルタイムで受信するデータ受信装置であり、具体的には、動画像再生機能付きの携帯電話機や、パーソナルコンピュータ、ＰＤＡ(Personal Digital Assistant)等である。そして、このクライアント端末３０は、コンテンツＵＲＬ取得部３０１、第１リクエスト作成部３０２、リクエスト送信部３０３、レスポンス受信部３０４、第１レスポンス解析部３０５、第２リクエスト作成部３０６、第２レスポンス解析部３０７、受信データメモリ３０８、フラグメント受信完了判定部３０９、多重化データ分離部３１０、ヘッダ解析部３１１、サンプルデータ取得部３１２および復号表示部３１３を備える。
These devices constituting the live streaming system will be described in detail below.
FIG. 2 is a block diagram showing the configuration of the
The
コンテンツＵＲＬ取得部３０１は、ユーザが再生を所望するライブコンテンツのＵＲＬ(Uniform Resource Locator)の入力を受け付けて第１リクエスト作成部３０２および第２リクエスト作成部３０６に出力する処理部である。なお、ここで、コンテンツへのアクセスのためにＵＲＬを用いているが、コンテンツにアクセスするための情報であれば、ＵＲＬ以外の情報であってもよい。
The content
第１リクエスト作成部３０２は、ＨＴＴＰを用いて、ＭＰ４ファイルの初期ヘッダおよび各フラグメントのサイズ情報の取得を配信サーバに要求するサイズ情報取得リクエストのコマンドを作成する処理部である。
リクエスト送信部３０３は、第１リクエスト作成部３０２および第２リクエスト作成部３０６が作成したリクエストを、ＨＴＴＰにより配信サーバ２０に送信する通信インターフェースである。
The first
The
レスポンス受信部３０４は、リクエスト送信部３０３から送信されたリクエストに対する配信サーバ２０からの返信、すなわち、レスポンスをＨＴＴＰにより受信する通信インターフェースであり、第１リクエスト作成部３０２が作成したリクエストに対するレスポンスを第１レスポンス解析部３０５に出力し、第２リクエスト作成部３０６が作成したリクエストに対するレスポンスを第２レスポンス解析部３０７に出力する。
The
第１レスポンス解析部３０５は、レスポンス受信部３０４からサイズ情報取得リクエストに対するレスポンスであるサイズ情報レスポンスを取得して、第２リクエスト作成部３０６に、そのレスポンスのエンティティボディに含まれる初期ヘッダおよび各フラグメントのサイズ情報と、リクエスト作成命令を出力する処理部である。また、第１レスポンス解析部３０５は、各フラグメントのサイズ情報をフラグメント受信完了判定部３０９にも出力する。
The first
第２リクエスト作成部３０６は、第１レスポンス解析部３０５から出力されるリクエスト作成命令を取得すると、第１レスポンス解析部３０５から出力される初期ヘッダおよび各フラグメントのサイズ情報に基づいて、ライブコンテンツを格納するＭＰ４ファイルの初期ヘッダおよび最新のフラグメントデータの取得を配信サーバ２０に要求する初期ヘッダ・フラグメント取得リクエストのコマンドを作成する処理部である。
When the second
第２レスポンス解析部３０７は、レスポンス受信部３０４から初期ヘッダ・フラグメント取得リクエストに対するレスポンスである初期ヘッダ・フラグメントレスポンスを取得して、そのレスポンスのエンティティボディに含まれる初期ヘッダや最新フラグメントのデータ、および以降のフラグメントデータを受信データメモリ３０８に蓄積させる処理部である。なお、ここでは、初期ヘッダや最新フラグメントのデータは、レスポンスのエンティティボディに含まれることとしているが、エンティティボディに限られず、レスポンスの一部として含まれていればよい。
The second
受信データメモリ３０８は、受信した初期ヘッダやフラグメントデータを一時的に保持するキャッシュメモリやＲＡＭ（Random Access Memory）等である。
フラグメント受信完了判定部３０９は、第１レスポンス解析部３０５から取得した初期ヘッダおよびフラグメントのサイズ情報に基づいて、受信データメモリ３０８をチェックして初期ヘッダおよびフラグメントデータの受信が完了したか否かを判定する処理部であり、初期ヘッダおよびフラグメントデータの受信完了を判定すると、多重化データ分離部３１０に初期ヘッダおよびフラグメントデータの受信完了を知らせる情報と、そのサイズ情報とを含むフラグメント受信完了信号を出力する。なお、ここで、フラグメント受信完了判定部３０９は、フラグメントデータを構成するｍｏｏｆおよびｍｄａｔのヘッダに含まれるサイズ情報や、別途フラグメントに格納されたフラグメントのサイズ情報などを用いたり、そのフラグメントデータの次のフラグメントデータの受信開始を検知したりすることによって、フラグメントデータの受信完了を判定することとしてもよい。
The
The fragment reception
多重化データ分離部３１０は、フラグメント受信完了判定部３０９からフラグメント受信完了信号を取得すると、サイズ情報に基づいて受信データメモリ３０８から受信が完了した初期ヘッダとフラグメントデータとを読み出して逆多重化する処理部である。なお、ここで、多重化データ分離部３１０は、フラグメントデータの全てを受信していなくても、ｍｏｏｆと、ｍｄａｔの先頭部分とを受信すれば再生を開始することとしてもよい。この場合、フラグメント受信完了判定部３０９で、予め定められた再生時間長分、あるいは、サイズ分のサンプルデータの受信完了等を基準として、ｍｄａｔのデータをどれだけ受信すれば復号および再生処理を開始するかを決定しておき、そのルールに従って多重化データ分離部３１０にフラグメント受信完了信号を出力することになる。
When the multiplexed
ヘッダ解析部３１１は、多重化データ分離部３１０によって逆多重化された初期ヘッダとフラグメントデータのうちヘッダ部分（ｍｏｏｆ）とを解析して、メディアデータの符号化レートやコンテンツの再生時間長等、メディアデータの解析に必要なメディア情報を取得する処理部である。
サンプル取得部３１２は、ヘッダ解析部３１１からサンプルのサイズや受信データメモリ３０８におけるサンプルの格納位置を取得して、取得した情報に基づいてサンプルの実体データ（サンプルデータ）を読み出して、復号表示部３１３に出力する処理部である。
The
The
復号表示部３１３は、ヘッダ解析部３１１が出力するサンプルの再生時間を取得し、その再生時間に従って、サンプル取得部３１２が出力するサンプルデータを復号化して、データを再生しディスプレイ等の表示装置に出力する処理部である。
図３は、配信サーバ２０の構成を示すブロック図である。
配信サーバ２０は、エンコーダ１０から取得した多重化データを蓄積させ、クライアント端末３０からのリクエストに応じて、ライブコンテンツを格納したＭＰ４ファイルをリアルタイムでクライアント端末３０に送信するデータ送信装置であり、具体的には、Ｗｅｂサーバ装置等である。そして、この配信サーバ２０は、多重化データ受信部２０１、多重化データ蓄積部２０２、リクエスト受信部２０３、リクエスト解析部２０４、サイズ情報取得部２０５、送信データ制御部２０６、送信データメモリ２０７およびレスポンス送信部２０８を備える。
The
FIG. 3 is a block diagram illustrating a configuration of the
The
多重化データ受信部２０１は、エンコーダ１０から多重化データを取得する通信インターフェースであり、取得した多重化データを順次、多重化データ蓄積部２０２に蓄積させる。
多重化データ蓄積部２０２は、多重化データ受信部２０１が受信した多重化データを一時的に保持するキャッシュメモリやＲＡＭ等である。
The multiplexed
The multiplexed
リクエスト受信部２０３は、クライアント端末３０から送信されたリクエストをＨＴＴＰにより受信する通信インターフェースであり、受信したリクエストをリクエスト解析部２０４に出力する。
リクエスト解析部２０４は、リクエスト受信部２０３から出力されたリクエストを解析する処理部であり、サイズ情報取得リクエストを解析すると、初期ヘッダと各フラグメントデータのサイズ情報の取得を指示するサイズ情報取得指示をサイズ情報取得部２０５に出力し、初期ヘッダ・フラグメント取得リクエストを解析すると、リクエスト中で指定されたデータの送信開始を指示する送信開始指示を送信データ制御部２０６に出力する。また、リクエスト解析部２０４は、クライアント端末３０から送信された接続の終了を要求する接続終了リクエストをリクエスト受信部２０３を介して取得し解析すると、接続を終了する旨のレスポンスの送信指示（接続終了指示）をレスポンス送信部２０８に出力する。
The
The
サイズ情報取得部２０５は、リクエスト解析部２０４から出力されるサイズ情報取得指示に基づいて、多重化データ蓄積部２０２に保持されている初期ヘッダおよびフラグメントデータを読み出して、それらのサイズ情報を取得する処理部であり、取得したサイズ情報、すなわち、初期ヘッダサイズおよびフラグメントサイズを送信データ制御部２０６に出力する。
Based on the size information acquisition instruction output from the
送信データ制御部２０６は、リクエスト解析部２０４から出力される送信開始指示に基づいて、送信するデータをＨＴＴＰの送信単位であるｃｈｕｎｋ（チャンク）毎にまとめる処理部である。送信データ制御部２０６は、リクエスト解析部２０４から出力される送信開始指示がサイズ情報取得リクエストに基づくものである場合には、サイズ情報取得部２０５から出力されるサイズ情報を１ｃｈｕｎｋにまとめて送信するデータを送信データメモリ２０７に蓄積させ、レスポンス送信部２０８にそのｃｈｕｎｋの送信を指示するｃｈｕｎｋデータ送信指示を出力する。また、リクエスト解析部２０４から出力される送信開始指示が初期ヘッダ・フラグメント取得リクエストに基づくものである場合には、多重化データ蓄積部２０２に保持されている初期ヘッダやフラグメントデータを読み出して、１ｃｈｕｎｋにまとめて送信データを送信データメモリ２０７に蓄積させ、レスポンス送信部２０８にそのｃｈｕｎｋの送信を指示するｃｈｕｎｋデータ送信指示を出力する。なお、初期ヘッダおよびフラグメントデータについては、送信データメモリ２０７を介さずに、多重化データ蓄積部２０２から、直接レスポンス送信部２０８に入力することとしてもよい。
The transmission
ここで、１ｃｈｕｎｋに複数のフラグメントデータを格納する、あるいは、１つのフラグメントデータを分割して複数のｃｈｕｎｋに格納することも可能であるが、１フラグメントを複数のｃｈｕｎｋに格納するとオーバーヘッドが増加しうるので、１ｃｈｕｎｋに１つのフラグメントデータを格納するのが望ましい。また、初期ヘッダとフラグメントデータとを同時に取得を求める初期ヘッダ・フラグメント取得リクエストに対しては、１ｃｈｕｎｋに初期ヘッダとフラグメントデータとを含めてもよいし、１ｃｈｕｎｋに初期ヘッダを含めて、他の１ｃｈｕｎｋにフラグメントデータを含めることとしてもよい。 Here, a plurality of fragment data can be stored in one chunk, or one fragment data can be divided and stored in a plurality of chunks, but if one fragment is stored in a plurality of chunks, the overhead can be increased. Therefore, it is desirable to store one fragment data in one chunk. In addition, for an initial header / fragment acquisition request for acquiring an initial header and fragment data at the same time, the initial header and fragment data may be included in 1 chunk, or the initial header is included in 1 chunk and another 1 chunk is included. It is good also as including fragment data in.
送信データメモリ２０７は、送信データ制御部２０６から出力される送信データを一時的に保持するキャッシュメモリやＲＡＭ等である。
レスポンス送信部２０８は、送信データ制御部２０６から出力されるｃｈｕｎｋデータ送信指示に基づいて、送信データメモリ２０７に保持されている送信データを読み出し、その送信データをエンティティボディに含むレスポンスをＨＴＴＰによりクライアント端末３０に送信する通信インターフェースである。また、レスポンス送信部２０８は、リクエスト解析部２０４から出力される接続終了指示を取得すると、接続の終了を示すレスポンスをＨＴＴＰによりクライアント端末３０に送信する。
The
The
図４は、エンコーダ１０の構成を示すブロック図である。
エンコーダ１０は、コンサート等の映像や音声を記録して、ビデオデータとオーディオデータとを符号化および多重化する多重化装置であり、具体的には、デジタルビデオカメラ等である。そして、このエンコーダ１０は、ビデオ符号化部１０１、ビデオデータ蓄積部１０２、オーディオ符号化部１０３、オーディオデータ蓄積部１０４、パケット作成命令部１０５、パケットヘッダ作成部１０６、パケットサイズ判定部１０７、サイズ調整部１０８、パケットデータ作成部１０９およびパケット結合部１１０を備える。
FIG. 4 is a block diagram showing the configuration of the
The
ビデオ符号化部１０１は、ビデオデータを取り込んで、ＭＰＥＧ−４ Ｖｉｓｕａｌ等の符号化方式により符号化する処理部であり、符号化したビデオデータを順次、ビデオデータ蓄積部１０２に蓄積させる。このビデオ符号化部１０１は、全てのフラグメントのサイズが予め設定されている設定フラグメントサイズと等しくなるように、単位時間当たりの最大データ量が予め設定されている範囲以下となるように符号化を行なう。具体的には、フラグメントの時間長が２ｓであり、ビットレートが６４０００ｂｐｓである場合には、０ｓ−２ｓ、２ｓ−４ｓ、４ｓ−６ｓ・・・の各フラグメントのデータ量が、１２８０００ｂｉｔ（２×６４０００）以下となるように符号化を行なう。
The
ビデオデータ蓄積部１０２は、符号化後のビデオデータを一時的に保持するキャッシュメモリやＲＡＭ等である。
オーディオ符号化部１０３は、オーディオデータを取り込んで、ＭＰＥＧ−４ ＡＡＣ等の符号化方式により符号化する処理部であり、符号化したオーディオデータを順次、オーディオデータ蓄積部１０４に蓄積させる。このオーディオ符号化部１０３もビデオ符号化部１０１と同様に、全てのフラグメントのサイズが設定フラグメントサイズと等しくなるように、単位時間当たりの最大データ量が予め設定されている範囲以下となるように符号化を行なう。ここで、ビデオおよびオーディオフラグメントにおける設定フラグメントサイズ決定時には、まず、ビデオおよびオーディオのフレームレートが一定であるか、また、オーディオのサンプルサイズが一定であるか等に基づいて、作成されるｍｏｏｆのサイズを見積もる。そして、ｍｄａｔのサイズについては、ビデオおよびオーディオのビットレートから見積もり、ｍｏｏｆとｍｄａｔのサイズの和を設定フラグメントとする。なお、見積もられたｍｏｏｆとｍｄａｔのサイズ和よりも大きいサイズを、設定フラグメントサイズとしてもよい。
The video
The
オーディオデータ蓄積部１０４は、符号化後のオーディオデータを一時的に保持するキャッシュメモリやＲＡＭ等である。
パケット作成命令部１０５は、予め定められたフラグメントの時間長に基づいて、ビデオデータ蓄積部１０２とオーディオデータ蓄積部１０４とをチェックして、その時間長分のビデオデータおよびオーディオデータの符号化が完了したか否かを判定する処理部である。なお、符号化されたビデオデータおよびオーディオデータのサイズにより、符号化の完了を判定することとしてもよい。このパケット作成命令部１０５は、所定の時間長分のビデオデータおよびオーディオデータの符号化完了を判定する毎に、パケットヘッダ作成部１０６にパケットヘッダ部、すなわちｍｏｏｆの作成を指示するパケット作成開始信号を出力する。
The audio
The packet creation command unit 105 checks the video
パケットヘッダ作成部１０６は、パケット（フラグメント）のヘッダ情報が格納されるｍｏｏｆを作成する処理部であり、ＣＰＵやメモリによって実現される。パケットヘッダ作成部１０６は、パケット作成命令部１０５から出力されるパケット作成開始信号を取得すると、ビデオデータ蓄積部１０２に保持されている符号化済みのビデオデータのヘッダ情報（ビデオヘッダ情報）を読み出し、また、オーディオデータ蓄積部１０４に保持されている符号化済みのオーディオデータのヘッダ情報（オーディオヘッダ情報）を読み出してｍｏｏｆを作成し、パケット結合部１１０に出力する。なお、ビデオヘッダ情報には、ビデオサンプルのサイズ、再生時間長およびイントラフレームであるか否かを示す情報が含まれ、さらに、双方向予測を用いたビデオサンプルの場合には、復号時間と表示時間の差分情報も含まれる。そして、オーディオヘッダ情報には、オーディオサンプルのサイズおよび再生時間長を示す情報が含まれている。
The packet
また、パケットヘッダ作成部１０６は、フラグメントに含まれるビデオサンプルおよびオーディオサンプルの実体データが、ビデオデータ蓄積部１０２およびオーディオデータ蓄積部１０４のどこに格納されているかを示すポインタ情報や、サンプルのサイズを示すサンプルサイズ情報や、パケットデータ部（ｍｄａｔ）の作成を指示する信号が含まれるｍｄａｔ情報をパケットデータ作成部１０９に出力する。
The packet
さらに、このパケットヘッダ作成部１０６は、ｍｏｏｆのサイズおよびｍｏｏｆ内のサンプルサイズ情報からパケットデータ部（ｍｄａｔ）のサイズを取得し、ｍｏｏｆとｍｄａｔのサイズの和をフラグメントサイズとして、パケットサイズ判定部１０７に出力する。
パケットサイズ判定部１０７は、パケットヘッダ作成部１０６から出力されるフラグメントサイズが、設定フラグメントサイズと一致するか否かを判定する処理部であり、一致していない場合には、その差分を示すサイズ差分情報をサイズ調整部１０８に出力する。なお、フラグメントサイズと設定フラグメントサイズとが一致している場合には、差分が０であることを示すサイズ差分情報をサイズ調整部１０８に出力する。
Further, the packet
The packet size determination unit 107 is a processing unit that determines whether or not the fragment size output from the packet
サイズ調整部１０８は、パケットサイズ判定部１０７から出力されるサイズ差分情報に基づいて、全てのフラグメントのサイズを統一するためにフラグメントのサイズを調整する処理部であり、フラグメントサイズと設定フラグメントサイズとの差分を示すサイズ差分情報を取得した場合には、その差分と等しいバイトサイズのパディングデータを含むフリーボックスを作成して、作成したフリーボックスをｍｏｏｆとｍｄａｔの後ろに追加する旨の指示であるフリーボックス情報とともにパケット結合部１１０に出力する。ここで、フリーボックスの最小サイズは８バイトであるため、設定フラグメントサイズの計算時、あるいは、ビデオデータおよびオーディオデータの符号化時に、作成されるフラグメントサイズが設定フラグメントサイズと同一、あるいは、８バイト以上小さくなるように処理する必要がある。一方、サイズ調整部１０８は、差分が０であることを示すサイズ差分情報を取得した場合には、フリーボックスを作成せずに、フリーボックスの追加が発生しないことを示すフリーボックス情報をパケット結合部１１０に出力する。
The
パケットデータ作成部１０９は、フラグメントの実体データが格納されるｍｄａｔを作成する処理部であり、ＣＰＵやメモリによって実現される。
このパケットデータ作成部１０９は、パケットヘッダ作成部１０６からｍｄａｔ情報を取得すると、ｍｄａｔ情報に含まれるポインタ情報とサンプルサイズ情報とに基づいて、ビデオデータ蓄積部１０２からフラグメントに含まれるビデオサンプルの実体データ（ビデオフラグメントデータ）を読み出し、オーディオデータ蓄積部１０４からフラグメントに含まれるオーディオサンプルの実体データ（オーディオフラグメントデータ）を読み出してｍｄａｔを作成し、パケット結合部１１４に出力する。
The packet
When the packet
パケット結合部１１０は、ｍｏｏｆとｍｄａｔとを結合させて、または、ｍｏｏｆとｍｄａｔを結合させた後ろにフリーボックスを追加して、フラグメントを作成する処理部であり、ＣＰＵやメモリによって実現される。このパケット結合部１１４は、パケットヘッダ作成部１０６からｍｏｏｆを取得し、パケットデータ作成部１０９からｍｄａｔを取得して、ｍｏｏｆとｍｄａｔとを結合させる。ここで、パケット結合部１１０は、サイズ調整部１０８からフリーボックスを追加する旨のフリーボックス情報を取得すると、サイズ調整部１０９からフリーボックスを取得して、ｍｏｏｆとｍｄａｔの後ろに追加してフラグメントを作成する。一方、パケット結合部１１０は、フリーボックスの追加が発生しないことを示すフリーボックス情報を取得すると、結合させたｍｏｏｆとｍｄａｔとをフラグメントとして取り扱う。そして、パケット結合部１１０は、このようにして作成したフラグメントを多重化データとして、順次配信サーバ２０に転送する。なお、ここで、フリーボックスは、ｍｏｏｆとｍｄａｔの間に挟んで、あるいは、ｍｏｏｆの前に配置することとしてもよい。
The packet combining unit 110 is a processing unit that creates a fragment by combining moof and mdat or adding a free box after combining moof and mdat, and is realized by a CPU or a memory. The packet combining unit 114 acquires moof from the packet
このような構成を備えた各装置は、ライブストリーミングシステムにおいて次のように動作する。
図５は、ライブストリーミングシステムにおける各装置間の通信シーケンス図である。
まず、エンコーダ１０は、ライブコンテンツの録画を開始するにあたって、初期ヘッダを作成し（Ｓ１０）、作成した初期ヘッダを配信サーバ２０に転送する（Ｓ１２）。
Each device having such a configuration operates as follows in the live streaming system.
FIG. 5 is a communication sequence diagram between devices in the live streaming system.
First, the
初期ヘッダを配信サーバ２０に転送すると、エンコーダ１０は、ライブコンテンツを構成するビデオデータとオーディオデータとを取得して（Ｓ１４）、符号化処理を開始する（Ｓ１６）。
エンコーダ１０は、所定のデータ量のビデオデータおよびオーディオデータの符号化を終えると、多重化して最初のフラグメント１を作成して、配信サーバ２０に転送する（Ｓ１８）。その後、エンコーダ１０は、所定のデータ量のビデオデータおよびオーディオデータの符号化を終える度に、多重化してフラグメント２、フラグメント３というように、順次作成したフラグメントを配信サーバ２０に転送する。
When the initial header is transferred to the
When the encoding of video data and audio data of a predetermined data amount is completed, the
ここで、クライアント端末３０に、ユーザからのライブコンテンツのＵＲＬの入力があると、クライアント端末３０は、サイズ情報取得リクエストを作成して（Ｓ２０）、配信サーバ２０にＨＴＴＰにより送信する（Ｓ２２）。
配信サーバ２０は、サイズ情報取得リクエストを受信すると、そのリクエストに対するレスポンスのエンティティボディにサイズ情報を含めてクライアント端末３０にＨＴＴＰにより送信する（Ｓ２４）。
Here, when the URL of the live content is input from the user to the
Upon receiving the size information acquisition request, the
続いて、クライアント端末３０は、受信したレスポンスのエンティティボディに含まれるサイズ情報を参照して、初期ヘッダおよび最新のフラグメントの取得を要求するリクエストを作成し（Ｓ２６）、作成した初期ヘッダ・最新フラグメント取得リクエストを配信サーバ２０に送信する（Ｓ２８）。
配信サーバ２０は、初期ヘッダ・最新フラグメント取得リクエストを受信すると、送信可能な最新のフラグメントを判定する（Ｓ３０）。本図では、送信可能となっている、すなわち、配信サーバ３０に蓄積されている最新のフラグメントは、フラグメントＮであることから、配信サーバ３０は、初期ヘッダ・最新フラグメント取得リクエストに対するレスポンスのエンティティボディに初期ヘッダとフラグメントＮとを含めてクライアント端末３０に送信する（Ｓ３２）。
Subsequently, the
When receiving the initial header / latest fragment acquisition request, the
そして、クライアント端末３０は、受信した初期ヘッダとフラグメントＮに含まれるｍｏｏｆとを解析して、フラグメントＮのｍｄａｔに格納されている実体データを逆多重化して、ディスプレイ等の表示装置に再生出力する（Ｓ３４）。
その後、ＭＰ４ファイルを構成する最後のフラグメントに至るまで、配信サーバ２０は、エンコーダ１０から、フラグメント（Ｎ＋１）、フラグメント（Ｎ＋２）というように順次転送されるフラグメントをクライアント端末３０にＨＴＴＰを用いて送信し、クライアント端末３０は、受信したフラグメントを再生出力して、ライブコンテンツのストリーミング再生を行なう。
Then, the
Thereafter, the
ここで、配信サーバ２０とクライアント端末３０間のＨＴＴＰを用いたリクエストおよびレスポンスの送受信について説明する。
図６は、ＨＴＴＰを用いた配信サーバ２０とクライアント端末３０間の通信シーケンスの第１例を示す図である。
まず、クライアント端末３０は、サイズ情報取得リクエストを配信サーバ２０に送信する（Ｓ４０）。ここで送信されるサイズ情報取得リクエストには、リクエストがデータの取得を要求するものであることを示すメソッド(GET)と、取得要求の対象となるファイルのＵＲＬ（http://…/….mp4）と、サイズ情報の取得であることを示すＨＴＴＰの拡張部(&size#1 &size#2)と、ＨＴＴＰのバージョン(HTTP/1.1)とが含まれている。
Here, transmission and reception of requests and responses using HTTP between the
FIG. 6 is a diagram illustrating a first example of a communication sequence between the
First, the
配信サーバ２０は、サイズ情報取得リクエストを受信すると、リクエストが成功したことをクライアント端末３０に通知するレスポンスをクライアント端末３０に送信する（Ｓ４２）。ここで送信されるレスポンスには、ＨＴＴＰのバージョン(HTTP/1.1)と、リクエストの成功を示すステータスコード(200)と、そのステータスコードの意味(OK)とが含まれている。
When receiving the size information acquisition request, the
そして、リクエストの成功をクライアント端末３０に通知するレスポンスを送信した後、配信サーバ２０は、エンティティボディに初期ヘッダのサイズ情報と、１フラグメントのサイズ情報とを含めたレスポンスをクライアント端末３０に送信する（Ｓ４４）。
クライアント端末３０は、初期ヘッダおよびフラグメントのサイズ情報を取得すると、そのサイズ情報に基づいて、初期ヘッダ・最新フラグメント取得リクエストを配信サーバ２０に送信する（Ｓ４６）。ここで送信される初期ヘッダ・最新フラグメント取得リクエストには、先に述べたサイズ情報取得リクエストと同様に、メソッド(GET)、ＵＲＬ（http://…/….mp4）およびＨＴＴＰバージョン(HTTP/1.1)に加えて、リクエストヘッダフィールドが含まれており、このリクエストヘッダフィールドにデータの取得範囲(:Range byte=0-999,-15000)が記述されている。本図では、初期ヘッダのサイズが１０００バイトであり、１フラグメントのサイズが１５０００バイトである場合の初期ヘッダ・最新フラグメント取得リクエストを示している。ここで、"−１５０００"としているのは、ファイルの終端から、１５０００バイト分、遡った位置にあるデータの取得を意味している。また、本実施の形態１のエンコーダ１０では、サイズが一定となるように各フラグメントは生成されているので、一旦受信を中断した後に、同一のコンテンツの受信を再開する際などにも、各フラグメントのサイズ情報を取得するためのリクエストおよびレスポンスの送受信を行なう必要がない。なお、フラグメントのサイズ情報を取得する代わりに、最新フラグメントのファイル先頭からのバイト位置を取得することとしてもよい。このとき、最新フラグメント取得リクエストにおいては、取得したバイト位置のフラグメントデータから送信開始することを要求する。ただし、受信中断後に同一コンテンツの受信を再開する際などには、毎回バイト位置情報が必要となる。
Then, after transmitting a response for notifying the
Upon acquiring the initial header and fragment size information, the
その後、配信サーバ２０は、初期ヘッダ・最新フラグメント取得リクエストを受信すると、サイズ情報取得リクエストの場合と同様に、リクエストが成功したことをクライアント端末３０に通知するレスポンスをクライアント端末３０に送信する（Ｓ４８）。
そして、リクエストの成功をクライアント端末３０に通知するレスポンスを送信した後、配信サーバ２０は、エンティティボディに初期ヘッダと、最新のフラグメントであるフラグメントＮとを含めたレスポンスをクライアント端末３０に送信し（Ｓ５０）、送信の中断を要求するリクエストの受信、あるいは、クライアント端末３０の電波受信状況が悪化して配信サーバ２０との接続が切断されること等がない限り、ＭＰ４ファイルの終端のフラグメントに至るまで、フラグメントの送信を続ける（Ｓ５２）。このとき、配信サーバ２０は、送信データを任意の大きさのｃｈｕｎｋに分け、そのｃｈｕｎｋの大きさが記述されたヘッダをつけて送信するｃｈｕｎｋ形式エンコーディング方式により、初期ヘッダやフラグメントデータをクライアント端末３０に送信する。なお、このｃｈｕｎｋ形式エンコーディング方式では、ｃｈｕｎｋサイズが０であるｃｈｕｎｋを送信することによって、配信サーバ２０は、送信が終了したことをクライアント端末３０にシグナリングする。
Thereafter, when receiving the initial header / latest fragment acquisition request, the
Then, after transmitting a response notifying the
このように本実施の形態１に係るライブストリーミングシステムによれば、ライブコンテンツの途中からストリーミング再生を開始する場合であっても、クライアント端末３０は、初期ヘッダと、ライブコンテンツの最新部分のデータを含むフラグメントから受信を開始することができるので、ライブコンテンツを、実時間に対して低遅延で受信してリアルタイムで再生することができるようになる。
As described above, according to the live streaming system according to the first embodiment, even when streaming playback is started in the middle of live content, the
ここで、ライブコンテンツの最新部分のデータを含むフラグメント、すなわち、最新フラグメントとは、厳密に最新のものである必要はなく、例えば、最新フラグメントの１つ前、或いは、２つ前のフラグメント等を意味するものであってもよい。
また、上記実施の形態１では、クライアント端末３０は、配信サーバ２０から初期ヘッダおよびフラグメントのサイズ情報を取得し、そのサイズ情報に基づいて、初期ヘッダおよび最新フラグメントを取得するためのリクエストを送信することとしているが、サイズ情報の取得を要求するリクエストを行なうことなく、初期ヘッダと最新フラグメントを取得することとしてもよい。
Here, the fragment including the data of the latest part of the live content, that is, the latest fragment does not need to be strictly the latest, for example, the fragment before the latest fragment or the fragment two before It may mean something.
In the first embodiment, the
このような場合における配信サーバ２０とクライアント端末３０間のＨＴＴＰを用いたリクエストおよびレスポンスの送受信は、以下のようになる。
図７は、ＨＴＴＰを用いた配信サーバとクライアント端末間の通信シーケンスの第２例を示す図である。
まず、クライアント端末３０は、初期ヘッダを取得するためのリクエストを配信サーバ２０に送信する（Ｓ６０）。ここで送信されるリクエストには、リクエストがデータの取得を要求するものであることを示すメソッド(GET)と、取得要求の対象となるファイルのＵＲＬ（http://…/….mp4）と、初期ヘッダの取得要求であることを示すＨＴＴＰの拡張部(&init)と、ＨＴＴＰのバージョン(HTTP/1.1)とが含まれている。
In such a case, transmission and reception of requests and responses using HTTP between the
FIG. 7 is a diagram illustrating a second example of a communication sequence between a distribution server and a client terminal using HTTP.
First, the
配信サーバ２０は、この初期ヘッダ取得リクエストを受信すると、上記の場合と同様に、リクエスト成功レスポンスをクライアント端末３０に送信する（Ｓ６２）。
そして、配信サーバ２０は、リクエスト成功レスポンスを送信した後、初期ヘッダ取得リクエストのＨＴＴＰの拡張部(&init)から、そのリクエストが初期ヘッダの取得要求であることを識別し、エンティティボディに初期ヘッダを含めたレスポンスをクライアント端末３０に送信する（Ｓ６４）。
When receiving the initial header acquisition request, the
Then, after transmitting the request success response, the
続いて、クライアント端末３０は、最新フラグメントを取得するためのリクエストを配信サーバ２０に送信する（Ｓ６６）。ここで送信されるリクエストには、先に述べた初期ヘッダ取得リクエストと同様に、メソッド(GET)と、ＵＲＬ（http://…/….mp4）と、最新フラグメントの取得要求であることを示すＨＴＴＰの拡張部(&frag)と、ＨＴＴＰバージョン(HTTP/1.1)とが含まれている。
Subsequently, the
配信サーバ２０は、この最新フラグメント取得リクエストを受信すると、上記の場合と同様に、リクエスト成功レスポンスをクライアント端末３０に送信する（Ｓ６８）。
そして、配信サーバ２０は、リクエスト成功レスポンスを送信した後、最新フラグメント取得リクエストのＨＴＴＰの拡張部(&frag)から、そのリクエストが最新フラグメントの取得要求であることを識別し、エンティティボディに最新フラグメントを含めたレスポンスをクライアント端末３０に送信し（Ｓ７０）、送信の中断を要求するリクエストの受信等がない限り、ＭＰ４ファイルの終端のフラグメントに至るまで、フラグメントの送信を続ける（Ｓ７２）。
When receiving the latest fragment acquisition request, the
Then, after transmitting the request success response, the
このように、配信サーバ２０に、ＨＴＴＰの拡張部を解析する機能を持たせることによって、サイズ情報の取得を要求するリクエストとそのリクエストに対するレスポンスを行なわなくても、初期ヘッダと最新フラグメントを取得することができるようになる。また、本方法では、各フラグメントのサイズを一定とすることなしに、受信中断後に再開する際などにも、サイズ情報の取得を要求するリクエストとそのリクエストに対するレスポンスを省略することができる。
In this way, by providing the
また、上記では、配信サーバ２０には、コンテンツの先頭フラグメントから最新フラグメントまでの全てのフラグメントがＭＰ４ファイルとして蓄積されていることとしたが、初期ヘッダおよび最新フラグメントのみを蓄積することとしてもよい。
ここで、初期ヘッダと最新フラグメントにそれぞれ異なるＵＲＬを持たせれば、初期ヘッダと最新フラグメントのＵＲＬに対してＧＥＴ要求を行なうことにより、クライアント端末３０はコンテンツ受信を開始することができる。また、配信サーバ２０では、クライアント端末３０に対してフラグメントデータの送信が開始されると、以降は最新フラグメントを順次送信することとする。この方式によれば、ＨＴＴＰの拡張は不要となる。
In the above description, all the fragments from the first fragment of the content to the latest fragment are stored as MP4 files in the
Here, if the initial header and the latest fragment have different URLs, the
なお、配信サーバ２０においては、全てのフラグメントデータが揃った完全なＭＰ４ファイルを別途蓄積しておき、クライアント端末３０は、再送要求などを行なう際に、完全なＭＰ４ファイルに対してデータ取得要求を行なうこととしてもよい。
The
（実施の形態２）
次に、本発明の実施の形態２に係るライブストリーミングシステムについて説明する。
本実施の形態２に係るライブストリーミングシステムは、大枠の構成を上記実施の形態１と同一とするが、配信サーバの構成において異なる。以下、この異なる点を中心に説明する。なお、上記実施の形態１と同一の構成要素については、同一の符号を付し、その説明を省略する。
図８は、本実施の形態２に係るライブストリーミングシステムにおける配信サーバの構成を示すブロック図である。
(Embodiment 2)
Next, a live streaming system according to
The live streaming system according to the second embodiment has the same general configuration as that of the first embodiment, but differs in the configuration of the distribution server. Hereinafter, this difference will be mainly described. In addition, about the component same as the said
FIG. 8 is a block diagram showing a configuration of a distribution server in the live streaming system according to the second embodiment.
この配信サーバ２０ａは、遅延判定部２１１を備えており、送信データ制御部２１６およびレスポンス送信部２１８における機能の点で、上記実施の形態１における配信サーバ２０と異なる。
遅延判定部２１１は、配信サーバ２０ａが、クライアント端末３０からコンテンツの受信要求を受けて、クライアント端末３０に向けて最初のフラグメント（ここでは、フラグメントＮとしておく。）の送信を開始してからの経過時間を計測するタイマーを有しており、この経過時間と、次に送信される予定であるフラグメントの直前のフラグメントまでの再生時間長の総和（ここでは、ｓｕｍ＿ｄｕｒａｔｉｏｎとしておく。）との差分値を、フラグメント送信時における遅延時間として計算する処理部である。この遅延判定部２１１は、レスポンス送信部２１８からフラグメントＮの送信開始を示す送信開始信号を取得することにより、経過時間の計測を開始し、また、送信データ制御部２１６から随時、各フラグメントの再生時間長を取得して、実際に送信したフラグメントではなくコンテンツを格納したＭＰ４ファイル内に含まれる全てのフラグメントの再生時間長を加算することにより、ｓｕｍ＿ｄｕｒａｔｉｏｎを計算する。ここで、遅延時間の計算は、次に送信するフラグメントを決定する直前に行なうこととするが、一定の周期で遅延時間を計算することとしてもよい。
This
The
そして、この遅延判定部２１１は、計算した遅延時間が所定の閾値以下であるか否かを判定し、所定の閾値より遅延時間が大きくなると、現在送信中のフラグメントに続く送信予定のフラグメントをスキップすることを指示するスキップ指示を送信データ制御部２１６に出力する。
Then, the
具体的には、遅延判定部２１１は、以下のような手順で、スキップの有無を判定する。
まず、遅延判定部２１１は、送信データ制御部２１６から各フラグメントの再生時間長を取得し、次に送信する予定のフラグメントをｉ番目のフラグメントであると仮定して、ｓｕｍ＿ｄｕｒａｔｉｏｎを計算する。
そして、計測した経過時間からｓｕｍ＿ｄｕｒａｔｉｏｎを減算した値、すなわち、両者の差分値（遅延時間）が、所定の閾値より大きいか否かを判定する。
ここで、遅延時間が所定の閾値以下であれば、スキップを行なわないことを決定し、送信データ制御部２１６にスキップが発生しないことを通知する信号を出力する。
Specifically, the
First, the
Then, it is determined whether or not a value obtained by subtracting sum_duration from the measured elapsed time, that is, a difference value (delay time) between the two is greater than a predetermined threshold value.
Here, if the delay time is equal to or less than a predetermined threshold, it is determined that skipping is not performed, and a signal notifying the transmission
一方、遅延時間が所定の閾値より大きい場合は、送信データ制御部２１６からｉ番目のフラグメントの再生時間長を取得し、次に送信する予定のフラグメントをｉ＋１番目のフラグメントであると仮定して、ｓｕｍ＿ｄｕｒａｔｉｏｎの値を更新する。
On the other hand, if the delay time is larger than the predetermined threshold, the reproduction time length of the i-th fragment is obtained from the transmission
そして、経過時間から更新されたｓｕｍ＿ｄｕｒａｔｉｏｎを減算して、遅延時間を更新し、再び、所定の閾値より大きいか否かを判定し、遅延時間が所定の閾値以下になるまで、このｓｕｍ＿ｄｕｒａｔｉｏｎの更新を繰り返す。
ここで、次に送信する予定のフラグメントをｉ＋ｎ番目のフラグメントと仮定した時に、遅延時間が所定の閾値以下となった場合、遅延判定部２１１は、ｉ＋（ｎ−１）番目までのフラグメントをスキップする旨のスキップ指示を送信データ制御部２１６に出力する。
Then, the updated sum_duration is subtracted from the elapsed time, the delay time is updated, and it is determined again whether or not the sum_duration is larger than the predetermined threshold value. repeat.
Here, when it is assumed that the fragment to be transmitted next is the i + nth fragment and the delay time is equal to or less than a predetermined threshold, the
このような手順で、遅延判定部２１１は、スキップの有無を判定する。
なお、クライアント端末３０において、受信したフラグメントの遅延時間情報を取得して配信サーバ２０ａに通知し、配信サーバ２０ａにおいては、通知された遅延時間情報に基づいてスキップを判定することとしてもよい。このとき、全フラグメントの再生時間長を一定にしておき、予め定められた規則に従って設定されたフラグメントのシーケンス番号をもとに、クライアント端末３０において、ｓｕｍ＿ｄｕｒａｔｉｏｎを計算する。また、フラグメントに含まれる各メディアの先頭サンプルの再生開始時間を、フラグメント内に格納する等してクライアント端末３０に通知することにより、クライアント端末３０でｓｕｍ＿ｄｕｒａｔｉｏｎを計算してもよい。なお、クライアント端末３０における、フラグメントのデータを受信して再生する際の再生開始時間と、ＭＰ４ファイルを実時間で再生した際の当該パケットの再生開始時間との差分値に基づいていれば、上記以外の方法で遅延時間を計算することとしてもよい。
By such a procedure, the
The
送信データ制御部２１６は、遅延判定部２１１から出力されるスキップ指示に基づいて、送信する予定であったフラグメントをスキップして、スキップ後のフラグメントを１ｃｈｕｎｋにまとめて送信データを作成し、送信データメモリ２０７に蓄積させる。なお、遅延判定部２１１からスキップが発生しないことを通知する信号を取得した場合には、スキップをせずに、送信する予定のフラグメントを１ｃｈｕｎｋにまとめて送信データを作成し、送信データメモリ２０７に蓄積させる。
Based on the skip instruction output from the
また、送信データ制御部２１６は、レスポンス送信部２１８からｃｈｕｎｋの送信が完了したことを示す送信完了信号を取得してから、次に送信すべきｃｈｕｎｋデータの送信指示をレスポンス送信部２１８に出力する。ここで、１ｃｈｕｎｋに複数のフラグメントデータを格納し、配信サーバ２０ａにおいてｃｈｕｎｋ単位で送信管理を行なうとすれば、遅延時間によりスキップを判定する際の粒度が荒くなるので、上記実施の形態１と同様に、１ｃｈｕｎｋに１つのフラグメントデータを格納することによって、遅延時間によりスキップを判定する際の粒度が荒くなることを防止することができる。
Further, the transmission
このような構成を備えた配信サーバ２０ａを有するライブストリーミングシステムは、以下のように動作する。
図９は、実施の形態２に係るライブストリーミングシステムにおける各装置間の通信シーケンス図である。本図では、上記実施の形態１におけるサイズ情報取得リクエストの送信や、サイズ情報取得リクエストに対するレスポンス等が既に行なわれ、ライブストリーミング再生が行なわれている状況から説明する。
The live streaming system having the
FIG. 9 is a communication sequence diagram between apparatuses in the live streaming system according to the second embodiment. This figure will be described from the situation in which the transmission of the size information acquisition request and the response to the size information acquisition request in the first embodiment has already been performed and the live streaming reproduction is being performed.
まず、上記実施の形態１と同様に、エンコーダ１０は、ライブコンテンツを構成するビデオデータやオーディオデータを取り込んで（Ｓ１００）、符号化および多重化して配信サーバ２０ａに順次フラグメントを転送し（Ｓ１０２）、配信サーバ２０ａは、フラグメントをクライアント端末３０にＨＴＴＰを用いて送信して（Ｓ１０４）、クライアント端末３０は、ＨＴＴＰを用いて受信したフラグメントを再生出力する（Ｓ１０６）。
First, as in the first embodiment, the
ここで、配信サーバ２０ａからクライアント端末３０にフラグメントを送信する伝送路に輻輳等が生じたり、クライアント端末３０の受信状況が悪化したりすると、配信サーバ２０ａからクライアント端末３０へのフラグメントの送信時間（本図に示すｄｌ＿ｔｉｍｅ）が長くなる（Ｓ１０８）。
この間、配信サーバ２０ａは、エンコーダ１０から順次転送されてくるフラグメントを蓄積させていく。
Here, when congestion or the like occurs in the transmission path for transmitting fragments from the
During this time, the
ここで、フラグメント（Ｎ＋２）をスキップせずに送信するためには、フラグメント（Ｎ＋１）の送信を、図中のｄｌ＿ｌｉｍｉｔで示す時間内に完了しなければならないとする。実際には、フラグメント（Ｎ＋１）の送信には、図中のｄｌ#ｔｉｍｅで示す時間がかかったために、フラグメント（Ｎ＋２）がスキップされる。
そして、配信サーバ２０ａは、スキップ後の最新フラグメント（Ｎ＋３）をクライアント端末３０にＨＴＴＰを用いて送信し（Ｓ１１２）、クライアント端末３０は、ＨＴＴＰを用いて受信したフラグメント（Ｎ＋３）を再生出力する（Ｓ１１４）。
Here, in order to transmit the fragment (N + 2) without skipping, it is assumed that the transmission of the fragment (N + 1) must be completed within the time indicated by dl_limit in the figure. Actually, since the transmission of the fragment (N + 1) took time indicated by dl # time in the figure, the fragment (N + 2) is skipped.
Then, the
その後、上記実施の形態１と同様に、ＭＰ４ファイルを構成する最後のフラグメントに至るまで、配信サーバ２０ａは、エンコーダ１０から、フラグメント（Ｎ＋４）、フラグメント（Ｎ＋５）というように順次転送されるフラグメントをクライアント端末３０にＨＴＴＰを用いて送信し、クライアント端末３０は、受信したフラグメントを再生出力して、ライブコンテンツのストリーミング再生を行なう。
Thereafter, in the same manner as in the first embodiment, until the last fragment constituting the MP4 file is reached, the
このように、本実施の形態２に係るライブストリーミングシステムによれば、ネットワークの輻輳や受信状態の悪化などによって、実時間でデータを伝送しきれず、受信端末側の受信データとライブデータとの間に時間的なギャップが発生する場合であっても、以後のフラグメントをスキップして送信するので、受信端末側におけるリアルタイム再生を担保することができる。 As described above, according to the live streaming system according to the second embodiment, data cannot be transmitted in real time due to network congestion, deterioration of reception conditions, and the like. Even when a time gap occurs, since subsequent fragments are transmitted while being skipped, real-time reproduction on the receiving terminal side can be ensured.
なお、本実施の形態２では、フラグメントのスキップを行なう場合には、再生されるフラグメントが時間的に不連続となることもあるので、設定によってスキップをしないモードとスキップを行なうモードとに分けてデータの取得を可能とするようにしてもよい。この場合、例えば、フラグメントを取得する際のリクエストを拡張して、そのＨＴＴＰ拡張部に、スキップをしないモードでデータ取得を要求する旨を示す情報（&No-Skip）を含めて配信サーバ２０ａに送信し、配信サーバ２０ａは、この情報が含まれているリクエストを受信した場合には、スキップ判定を行なわない等とすればよい。あるいは、端末側でコンテンツ取得用に複数のＵＲＬを選択できるようにしておき、コンテンツの受信をリクエストするＵＲＬに依存して、スキップあり／なし、のいずれのモードで受信するかを選択できるようにしてもよい。
In the second embodiment, when a fragment is skipped, the reproduced fragment may be temporally discontinuous. Therefore, it is divided into a mode in which skipping is not performed and a mode in which skipping is performed depending on settings. Data may be acquired. In this case, for example, the request for acquiring the fragment is extended, and the HTTP extension unit is transmitted to the
（実施の形態３）
続いて、本発明の実施の形態３に係るライブストリーミングシステムについて説明する。
上記実施の形態１では、最新のフラグメントからの再生を可能として、低遅延でのライブストリーミング再生を実現することについて説明した。また、上記実施の形態２では、伝送路における輻輳が発生した場合等でも、最新のフラグメントまで以後のフラグメントをスキップすることを可能として、リアルタイム再生を実現することについて説明した。
上記いずれの実施の形態においても、ＭＰ４ファイルの途中のフラグメントから再生を開始または再開することとなるが、再生開始位置となるフラグメントの先頭に格納されているビデオサンプルとオーディオサンプルとの同期がずれてしまうおそれがある。
(Embodiment 3)
Subsequently, a live streaming system according to
In the first embodiment, it has been described that the reproduction from the latest fragment is enabled and the live streaming reproduction with a low delay is realized. In the second embodiment, real-time reproduction is realized by enabling subsequent fragments up to the latest fragment even when congestion occurs in the transmission path.
In any of the above embodiments, playback is started or restarted from a fragment in the middle of the MP4 file. However, the video sample stored at the beginning of the fragment that is the playback start position and the audio sample are out of synchronization. There is a risk that.
本実施の形態３に係るライブストリーミングシステムは、上記実施の形態１および２で説明した内容に加えて、ビデオデータとオーディオデータとの同期再生をも担保するライブストリーミングシステムである。
そのため、本実施の形態３に係るライブストリーミングシステムは、大枠の構成を上記実施の形態１および２と同一とするが、エンコーダおよびクライアント端末の構成において相違点を有する。以下、この相違点を中心に説明する。なお、上記実施の形態１および２と同一の構成要素については、同一の符号を付し、その説明を省略する。
The live streaming system according to the third embodiment is a live streaming system that guarantees synchronized reproduction of video data and audio data in addition to the contents described in the first and second embodiments.
Therefore, the live streaming system according to the third embodiment has the same general configuration as that of the first and second embodiments, but has a difference in the configuration of the encoder and the client terminal. Hereinafter, this difference will be mainly described. Note that the same components as those in the first and second embodiments are denoted by the same reference numerals and description thereof is omitted.
図１０は、本実施の形態３に係るライブストリーミングシステムにおけるエンコーダの一部構成を示すブロック図である。
図１０に示すように、本実施の形態３に係るライブストリーミングシステムを構成するエンコーダは、パケットヘッダ作成部１０６ａにその特徴を有している。
このパケットヘッダ作成部１０６ａは、ビデオヘッダ情報解析部１２１と、オーディオヘッダ情報解析部１２２と、同期情報決定部１２３と、同期情報格納ボックス作成部１２４と、ヘッダ情報作成部１２５とを備える。
FIG. 10 is a block diagram showing a partial configuration of the encoder in the live streaming system according to the third embodiment.
As shown in FIG. 10, the encoder constituting the live streaming system according to the third embodiment has a feature in the packet
The packet
ビデオヘッダ情報解析部１２１は、ビデオデータ蓄積部１０２からビデオヘッダ情報を読み出して解析する処理部であり、フラグメントに格納するビデオサンプル毎の再生時間長を記述したテーブルを同期情報決定部１２３に出力し、また、ビデオサンプルのサンプルサイズやビデオデータ蓄積部１０２におけるサンプルの格納位置等をヘッダ情報作成部１２５に出力する。
The video header
オーディオヘッダ情報解析部１２２は、オーディオデータ蓄積部１０４からオーディオヘッダ情報を読み出して解析する処理部であり、フラグメントに格納するオーディオサンプル毎の再生時間長を記述したテーブルを同期情報決定部１２３に出力し、また、オーディオサンプルのサンプルサイズやオーディオデータ蓄積部１０４におけるサンプルの格納位置等をヘッダ情報作成部１２５に出力する。
The audio header
同期情報決定部１２３は、ビデオヘッダ情報解析部１２１から出力されるビデオ再生時間長テーブルと、オーディオヘッダ情報解析部１２２から出力されるオーディオ再生時間長テーブルとを用いて、ビデオとオーディオの同期再生のための情報を作成する処理部である。ここで、ビデオとオーディオの同期再生のための情報としては、フラグメントに格納する先頭のビデオサンプルの表示時刻（ｖ＿ｐｔｓ）およびフラグメントに格納する先頭のオーディオサンプルの表示時刻（ａ＿ｐｔｓ）を用いることができる。なお、このｖ＿ｐｔｓおよびａ＿ｐｔｓは、各再生時間長テーブルに記述されているサンプルの再生時間長の総和をフラグメント毎に加算し更新することによって得ることができる。なお、ビデオヘッダ情報解析部１２１およびオーディオヘッダ情報解析部１２２から、それぞれビデオおよびオーディオのフラグメントにおける先頭サンプルの再生開始時間を直接取得することとしてもよい。
The synchronization
そして、同期情報決定部１２３は、作成したｖ＿ｐｔｓおよびａ＿ｐｔｓを同期情報格納ボックス作成部１２４に出力する。
同期情報格納ボックス作成部１２４は、同期情報決定部１２３において作成した同期情報をＭＰ４ファイルのボックス構造に変換して、同期情報格納ボックス（以下、「ムービーフラグメントシンクロボックス」または「ｍｆｓｙ」と称する。）を作成する処理部である。この同期情報格納ボックス作成部１２４は、ｖ＿ｐｔｓおよびａ＿ｐｔｓ毎にムービーフラグメントシンクロボックスを作成して、ヘッダ情報作成部１２５に出力する。
Then, the synchronization
The synchronization information storage
図１１は、ムービーフラグメントシンクロボックスのシンタックスの例を示す図である。
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅのフィールドには、フラグメントの先頭サンプルの再生開始時間が記述される。
また、ｔｒａｃｋ＿ＩＤのフィールドには、ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅフィールドにより、フラグメントの先頭サンプルの再生開始時間長が提供されるトラックのＩＤ（トラックヘッダボックスに示される各トラック固有のＩＤ番号）が記述される。
FIG. 11 is a diagram illustrating an example of the syntax of a movie fragment sync box.
In the field of presentation_time, the reproduction start time of the first sample of the fragment is described.
In the track_ID field, the ID of the track (ID number unique to each track shown in the track header box) in which the playback start time length of the first sample of the fragment is provided is described by the presentation_time field.
そして、ヘッダ情報作成部１２５は、ビデオヘッダ情報解析部１２１から出力されるビデオサンプルのサンプルサイズ等と、オーディオヘッダ情報解析部１２２から出力されるオーディオサンプルのサンプルサイズ等と、同期情報格納ボックス作成部１２４から出力されるｍｆｓｙとを用いて、ｍｏｏｆを作成する処理部である。このヘッダ情報作成部１２５は、ｍｏｏｆ直下のボックスデータ格納部にｍｆｓｙを格納してｍｏｏｆを作成し、作成したｍｏｏｆをパケット結合部１１０に出力する。また、ヘッダ情報作成部１２５は、ｍｄａｔ情報をパケットデータ作成部１０９に出力する。
Then, the header
なお、ここで、パケットヘッダ作成部１０６ａは、ヘッダ情報作成部１２５において、ｍｏｏｆ直下のボックスデータ格納部にｍｆｓｙを格納するのではなく、同期情報格納ボックス作成部１２４において、ｍｆｓｙと、ｍｆｓｙをｍｏｏｆとｍｄａｔの間に位置させるようにフラグメントの結合を指示するｍｆｓｙ配置情報をパケット結合部１１０に出力する構成としてもよい。また、ｍｆｓｙをトラックフラグメントボックス（ｔｒａｆ）の直下に配置して、トラック単位の情報を示すこととしてもよい。このとき、ｅｎｔｒｙ＿ｃｏｕｎｔおよびｔｒａｃｋ＿ＩＤのフィールドは不要となる。また、ｍｆｓｙは、予め定められたルールに基づいて、特定のフラグメントにのみ格納することとしてもよい。
Here, the packet
図１２は、実施の形態３に係るライブストリーミングシステムにおけるクライアント端末の一部構成を示すブロック図である。
上記のパケットヘッダ作成部１０６ａを備えたエンコーダによって作成されたＭＰ４ファイルのフラグメントを再生するため、図１２に示すように、本実施の形態３に係るクライアント端末は、第２レスポンス解析部３０７ａやヘッダ解析部３１１ａ等にその特徴を有している。
FIG. 12 is a block diagram illustrating a partial configuration of a client terminal in the live streaming system according to the third embodiment.
In order to reproduce the fragment of the MP4 file created by the encoder including the packet
第２レスポンス解析部３０７ａは、同期情報設定フラグメント判定部３２１を備える。この同期情報設定フラグメント判定部３２１は、レスポンス受信部３０４から出力される初期ヘッダ・フラグメントレスポンスのエンティティボディに含まれるフラグメントが、同期情報を用いて再生するフラグメントであるか否かを判定する処理部である。そして、同期情報設定フラグメント判定部３２１は、レスポンス受信部３０４から取得したフラグメントが、ＭＰ４ファイルの途中から受信を開始した際の先頭のフラグメントであるか否か、或いは、スキップ直後のフラグメントであるか否かを判定し、これら同期情報を用いて再生することが必要なフラグメントである場合に、ｍｆｓｙをｍｏｏｆから分離して解析することを指示する同期フラグを、ｍｆｓｙ分離解析部３２３に出力する。
The second
ヘッダ解析部３１１ａは、ｔｒａｆ分離解析部３２２と、ｍｆｓｙ分離解析部３２３とを備える。
ｔｒａｆ分離解析部３２２は、ｍｏｏｆに含まれるトラックフラグメントボックス（ｔｒａｆ）を分離して解析する処理部である。ここで、ｔｒａｆとは、トラック毎のヘッダ情報が格納されるボックスである。また、トラックとは、ライブコンテンツを構成する各メディアのサンプルデータ全体を意味し、動画像や音声やテキスト等のトラックは、それぞれビデオトラック、オーディオトラックやテキストトラック等と称される。
The
The traf
すなわち、このｔｒａｆ分離解析部３２２は、ビデオトラックのｔｒａｆとオーディオトラックのｔｒａｆとを分離して解析し、その解析結果をサンプルデータ取得部３１２や復号表示部３１３ａに出力する。
ｍｆｓｙ分離解析部３２３は、同期情報設定フラグメント判定部３２１から出力される同期フラグを取得した場合に、ｍｏｏｆに含まれるｍｆｓｙを分離して解析する処理部である。このｍｆｓｙ分離解析部３２３は、その解析結果としてｖ＿ｐｔｓおよびａ＿ｐｔｓを復号表示部３１３ａに出力する。
That is, the traf
The mfsy
そして、復号表示部３１３ａは、ｔｒａｆ分離解析部３２２が出力するサンプルの再生時間と、ｍｆｓｙ分離解析部３２３が出力するｖ＿ｐｔｓおよびａ＿ｐｔｓとを取得し、その再生時間と同期情報とを用いて、サンプル取得部３１２が出力するサンプルデータを復号化して、データを再生出力する。具体的には、ｖ＿ｐｔｓがａ＿ｐｔｓよりも大きい場合には、その差分値の分だけ、ビデオの再生開始時間をオーディオの再生開始時間に対して遅延させる。ａ＿ｐｔｓがｖ＿ｐｔｓよりも大きい場合にも同様に、その差分値の分だけ、オーディオの再生開始時間をビデオの再生開始時間に対して遅延させる。
Then, the decoding display unit 313a acquires the reproduction time of the sample output by the traf
このように構成されるエンコーダおよびクライアント端末を有する本実施の形態３のライブストリーミングシステムによれば、各フラグメントに先頭ビデオサンプルと先頭オーディオサンプルとの同期再生に関する情報を格納するので、ＭＰ４ファイルの途中のフラグメントから再生を開始する場合でも、ビデオとオーディオ間の同期再生を担保することができる。 According to the live streaming system of the third embodiment having the encoder and the client terminal configured as described above, information related to the synchronized playback of the first video sample and the first audio sample is stored in each fragment. Even when playback is started from the other fragment, synchronized playback between video and audio can be ensured.
（実施の形態４：記録・再送要求）
さらに続いて、本発明の実施の形態４に係るライブストリーミングシステムについて説明する。
(Embodiment 4: Recording / Retransmission Request)
Subsequently, a live streaming system according to
上記実施の形態１〜３では、主にライブコンテンツのストリーミングによるリアルタイム再生について説明したが、本実施の形態４に係るライブストリーミングシステムは、上記実施の形態１〜３で説明した内容に加えて、クライアント端末側でライブコンテンツのデータを記録することができるライブストリーミングシステムである。
そのため、本実施の形態４に係るライブストリーミングシステムは、上記実施の形態１〜３の構成と略共通するが、クライアント端末の構成において相違点を有する。以下、この相違点を中心に説明する。なお、上記実施の形態１〜３と同一の構成要素については、同一の符号を付し、その説明を省略する。
In the first to third embodiments, real-time playback mainly by streaming live content has been described. However, in addition to the contents described in the first to third embodiments, the live streaming system according to the fourth embodiment includes: This is a live streaming system capable of recording live content data on the client terminal side.
Therefore, the live streaming system according to the fourth embodiment is substantially the same as the configuration of the first to third embodiments, but has a difference in the configuration of the client terminal. Hereinafter, this difference will be mainly described. In addition, about the component same as the said Embodiment 1-3, the same code | symbol is attached | subjected and the description is abbreviate | omitted.
図１３は、本実施の形態４に係るライブストリーミングシステムにおけるクライアント端末の一部構成を示すブロック図である。
図１３に示すように、本実施の形態４に係るライブストリーミングシステムを構成するクライアント端末は、上記実施の形態１〜３のクライアント端末に加えて、さらに、ユーザ指示入力部３３１と、フラグメント記録制御部３３２と、記録部分フラグメント格納部３３３とを備える。
FIG. 13 is a block diagram showing a partial configuration of a client terminal in the live streaming system according to the fourth embodiment.
As shown in FIG. 13, in addition to the client terminals of the first to third embodiments, a client terminal that configures the live streaming system according to the fourth embodiment further includes a user
ユーザ指示入力部３３１は、ライブコンテンツの記録開始や記録終了等、ユーザからの指示の入力を受け付ける入力インターフェースであり、具体的には、携帯電話機のキーボタンや、パーソナルコンピュータのキーボードやマウス等である。このユーザ指示入力部３３１は、ユーザからライブコンテンツの記録開始指示の入力を受け付けると、フラグメント記録制御部３３２に、フラグメントの記録の開始を指示する記録指示を出力する。
The user
フラグメント記録制御部３３２は、ユーザ指示入力部３３１からの記録指示やフラグメント受信完了判定部３０９ａからの受信完了信号に基づいて、どのフラグメントから記録を開始するかを決定する処理部であり、受信完了信号を取得してからの経過時間を計測するタイマーを内部に備える。
このフラグメント記録制御部３３２は、記録指示を取得すると、タイマーによって計測した受信完了信号を取得してからの経過時間が、予め定められた値（この値を"Ｔ1"とする。）を経過しているか否かによって、記録を開始するフラグメントを決定する。具体的な詳しい説明については、後述する。
The fragment
When the fragment
また、フラグメント記録制御部３３２は、記録開始フラグメントを決定すると、受信データメモリ３０８ａから初期ヘッダと、記録開始フラグメントのフラグメントデータを読み出して、記録部分フラグメント格納部３３３に格納し、ユーザ指示入力部３３１から記録の終了を指示する記録終了指示を取得するまで、記録開始フラグメント以降のフラグメントデータを記録部分フラグメントデータとして、記録部分フラグメント格納部３３３に格納していく。
When the recording start fragment is determined, the fragment
記録部分フラグメント格納部３３３は、記録部分フラグメントデータを格納するためのハードディスク、ＣＤ−ＲやＤＶＤ−ＲＡＭ等の記憶媒体である。
また、受信データメモリ３０８ａは、所定の容量を有しており、受信中のフラグメントの直前のフラグメントデータを保持している。
このような構成を備えたクライアント端末の記録動作について説明する。
The recording partial
The
A recording operation of the client terminal having such a configuration will be described.
図１４は、クライアント端末における記録動作処理のフロー図である。
まず、ユーザ指示入力部３３１は、ユーザからの記録開始指示の入力を受け付けると（Ｓ２００）、フラグメント記録制御部３３２に記録指示を出力する。
次に、フラグメント記録制御部３３２は、ユーザ指示入力部３３１から記録指示を取得すると、タイマーによって計測した受信完了信号を取得してからの経過時間が、予め定められた値Ｔ1を経過しているか否かを判定する（Ｓ２０２）。
FIG. 14 is a flowchart of the recording operation process in the client terminal.
First, upon receiving an input of a recording start instruction from the user (S200), the user
Next, the fragment
ここで、経過時間がＴ1を超えている場合（Ｓ２０２のＹｅｓ）、フラグメント記録制御部３３２は、現在受信中のフラグメントを記録開始フラグメントとし、現在受信中のフラグメントの先頭から記録を開始する（Ｓ２０４）。
一方、経過時間がＴ1を超えていない場合（Ｓ２０２のＮｏ）、フラグメント記録制御部３３２は、現在受信中のフラグメントの１つ前に受信を完了したフラグメントを記録開始フラグメントとし、そのフラグメントの先頭から記録を開始する（Ｓ２０６）。
If the elapsed time exceeds T 1 (Yes in S202), the fragment
On the other hand, when the elapsed time does not exceed T 1 (No in S202), the fragment
その後、フラグメント記録制御部３３２は、ユーザ指示入力部３３１から記録終了指示を取得するまで、受信データメモリ３０８ａから各フラグメントのデータを読み出して、記録部分フラグメントデータを記録部分フラグメント格納部３３３に格納する動作を繰り返し（Ｓ２０８）、記録終了指示を取得すると、記録中のフラグメントの記録完了後に、記録動作を終了する。
Thereafter, the fragment
このように、ユーザからの記録開始指示を行なった時が、受信完了信号を取得してから所定の閾値Ｔ1以上経過しているか否かで、記録開始フラグメントを現在受信中のフラグメントか現在受信中のフラグメントの直前のフラグメントに決定することによって、ユーザが記録を所望する部分のデータを取りこぼすことなく、確実に記録することができるようになる。 Thus, when the, on whether or not the acquired reception completion signal has passed a predetermined threshold value above T 1, a fragment or currently received in the current reception recording start fragment was subjected to recording start instruction from the user By deciding the fragment immediately before the middle fragment, the user can surely record without missing the data of the portion desired to be recorded.
より具体的に詳しく説明すると、ユーザは、再生中の映像を見て記録開始を所望した場合、記録開始指示を入力した段階では、先の映像データを含むフラグメントの再生が終了して、次のフラグメントの再生が始まっていることがありうる。そのため、例えば、１フラグメントの再生時間長が５ｓであれば、閾値Ｔ1を３ｓに設定しておき、閾値Ｔ1を経過する前に記録開始指示の入力があれば、現在再生中のフラグメントの直前のフラグメントから記録を開始し、閾値Ｔ1を経過した後に記録開始指示の入力があれば、現在再生中のフラグメントから記録を開始することによって、ユーザの所望する映像データの部分を取りこぼすことなく記録することができる。 More specifically, when the user desires to start recording by watching the video being played back, when the recording start instruction is input, the playback of the fragment including the previous video data is finished, and the next It is possible that fragment regeneration has begun. Therefore, for example, if the playback time length of one fragment is 5 s, the threshold T 1 is set to 3 s, and if a recording start instruction is input before the threshold T 1 has passed, start recording from the fragment immediately before, if there is an input recording start instruction after an elapse of the threshold T 1, by starting the recording from the fragment that is currently playing, to lose information a desired portion of the video data of the user It can be recorded without.
なお、閾値Ｔ1を経過する前に記録開始指示の入力があった場合の記録開始フラグメントは、現在再生中のフラグメントの直前のフラグメントに限らず、現在再生中のフラグメントの２つ前、３つ前等のフラグメントであってもよく、受信データメモリ３０８ａの容量に応じて適宜調整することができるようにしてもよい。
このように、本実施の形態４に係るライブストリーミングシステムによれば、ユーザが記録開始の指示を行なったタイミングに応じて記録を開始するフラグメントを変更するので、ユーザが記録を所望するデータ部分を確実に記録することができる。
Note that the recording start fragment when the recording start instruction is input before the threshold value T 1 elapses is not limited to the fragment immediately before the fragment currently being played back, but is two before the fragment currently being played back, It may be a fragment such as a previous one, and may be adjusted as appropriate according to the capacity of the
As described above, according to the live streaming system according to the fourth embodiment, since the fragment to start recording is changed in accordance with the timing when the user gives an instruction to start recording, the data portion that the user desires to record is changed. It can be recorded reliably.
（第１変形例）
次に、本発明の実施の形態４の第１変形例について説明する。
まず、本実施の形態４の第１変形例に係るライブストリーミングシステムを構成するクライアント端末について、図を参照しながら説明する。
(First modification)
Next, a first modification of the fourth embodiment of the present invention will be described.
First, a client terminal constituting a live streaming system according to a first modification of the fourth embodiment will be described with reference to the drawings.
図１５は、第１変形例に係るクライアント端末の一部構成を示すブロック図である。
図１５に示すように、この第１変形例に係るクライアント端末は、ユーザ指示入力部３３１ａと、フラグメント記録制御部３３２ａと、記録箇所情報メモリ３４１と、再生区間判定部３４２と、第２リクエスト作成部３０６ａとを備えている。
ユーザ指示入力部３３１ａは、記録指示や記録終了指示をフラグメント記録制御部３３２ａに出力するとともに、記録した箇所をライブストリーミング再生の終了後に改めて再生することを指示する再生指示を再生区間判定部３４２に出力する。
FIG. 15 is a block diagram illustrating a partial configuration of a client terminal according to the first modification.
As shown in FIG. 15, the client terminal according to the first modification includes a user
The user
フラグメント記録制御部３３２ａは、記録指示を取得すると、受信完了信号の取得からの経過時間が、閾値Ｔ1を経過しているか否かで、記録を開始するフラグメントを決定する。ここで、フラグメント記録制御部３３２は、記録開始フラグメントを決定すると、受信データメモリ３０８ａから、ＭＰ４ファイルのファイル名と、記録開始フラグメントのシーケンス番号（ファイルの先頭のフラグメントから各フラグメントに昇順で割り当てられる番号であり、ｍｏｏｆ直下のムービーフラグメントヘッダボックスに格納される。）とを読み出す。
Fragments recording
そして、フラグメント記録制御部３３２ａは、記録終了指示を取得するまで、記録開始フラグメント以降のフラグメントのシーケンス番号を順次読み出し、記録終了指示を取得またはファイルの終端に到達すると、最後に記録するフラグメント（記録終了フラグメント）のシーケンス番号を読み出して、先に読み出したファイル名と、記録開始フラグメントおよび記録終了フラグメントのシーケンス番号を記録箇所情報として記録箇所情報メモリ３４１に格納する。また、シーケンス番号が循環した際には、循環した回数を同時記録しておく等して、記録した最終フラグメントを判別することとする。なお、ここでは、シーケンス番号の増分が一定である等、予め定められたルールに基づいてシーケンス番号が設定されていることを前提としている。シーケンス番号がランダムに設定される際には、記録したフラグメントのシーケンス番号を全て記録箇所情報メモリ３４１に格納する。
The fragment
記録箇所情報メモリ３４１は、記録箇所情報を格納するためのメモリやハードディスク等である。
再生区間判定部３４２は、ユーザ指示入力部３３１ａから出力される再生指示を取得すると、記録箇所情報メモリ３４１を参照して記録箇所情報を読み出して、記録箇所を判定し、その記録箇所の再生に必要なフラグメントの再送を要求する再送リクエスト作成指示を第２リクエスト作成部３０６ａに出力する処理部である。
The recording
When the playback
第２リクエスト作成部３０６ａは、再生区間判定部３４２から再送リクエスト作成指示を取得すると、先に読み出したファイル名と、記録開始フラグメントおよび記録終了フラグメントのシーケンス番号とに基づいて、再送リクエストを作成してリクエスト送信部３０３に出力する。
クライアント端末をこのような構成とすることで、記録部分のフラグメントの実体データそのものを保持せずに、ファイル名と、記録開始箇所および記録終了箇所のシーケンス番号とを記録しておき、改めて再生する際に、これらの情報を用いて実体データの再送を要求して再生することができるので、携帯電話機やＰＤＡ等のように、メモリの容量が少ない携帯型の端末装置に適したものとなる。
When the second
By configuring the client terminal with such a configuration, the file name and the sequence number of the recording start location and the recording end location are recorded and reproduced again without retaining the entity data itself of the fragment of the recording portion. At this time, since it is possible to request and reproduce the retransmission of the entity data using these pieces of information, it becomes suitable for a portable terminal device with a small memory capacity such as a cellular phone or a PDA.
（第２変形例）
次に、本実施の形態４の第２変形例に係るライブストリーミングシステムを構成するクライアント端末について説明する。
図１６は、第２変形例に係るクライアント端末の一部構成を示すブロック図である。
図１６に示すように、この第２変形例に係るクライアント端末は、ユーザ指示入力部３３１ｂと、フラグメント記録制御部３３２ｂと、記録部分フラグメント格納部３３３と、スキップ判定部３５１と、再送リクエスト作成部３５２と、復号表示部３１３ｂとを備えている。
(Second modification)
Next, a client terminal constituting the live streaming system according to the second modification of the fourth embodiment will be described.
FIG. 16 is a block diagram illustrating a partial configuration of a client terminal according to the second modification.
As illustrated in FIG. 16, the client terminal according to the second modification includes a user
ユーザ指示入力部３３１ｂは、記録指示や記録終了指示をフラグメント記録制御部３３２ｂに出力するとともに、ライブストリーミング再生時にフラグメントのスキップが発生している場合等、受信していないフラグメントのデータの再送を要求する再送リクエスト作成指示を再送リクエスト作成部３５２に出力する。
フラグメント記録制御部３３２ｂは、記録指示を取得すると、受信完了信号の取得からの経過時間が、閾値Ｔ1を経過しているか否かで、記録を開始するフラグメントを決定する。ここで、フラグメント記録制御部３３２は、記録開始フラグメントを決定すると、受信データメモリ３０８ａから、初期ヘッダと、記録開始フラグメントのフラグメントデータを読み出して、スキップ判定部３５１に出力し、記録終了指示を取得するまで、順次記録開始フラグメント以降のフラグメントデータをスキップ判定部３５１に出力する。
The user
Fragments recording
スキップ判定部３５１は、フラグメント記録制御部３３２ｂから順次出力されるフラグメントデータを取得して、フラグメントのスキップの有無を判定し、スキップが発生している場合に、スキップの発生している箇所を示すスキップ情報を再送リクエスト作成部３５２に出力するとともに、取得したフラグメントデータを記録部分フラグメント格納部３３３に格納する処理部である。
The
このスキップ判定部３５１は、記録開始フラグメントから順番に各フラグメントのシーケンス番号の増分をカウントすることによって、フラグメントのスキップの有無を判定する。すなわち、フラグメントのシーケンス番号が予め定められている規定に従って増加していない場合には、スキップの発生であると判定する。図を用いて、より具体的に説明する。
The
図１７（ａ）は、スキップが発生した場合におけるＭＰ４ファイルの構造の第１例を説明するための図である。
スキップ判定部３５１は、記録開始フラグメント（本図では、フラグメント５）からＭＰ４ファイル４００を構成する各フラグメントを順次取得し、各フラグメントのシーケンス番号（ＳＮ）の増分をカウントする。ここで、スキップ判定部３５１は、シーケンス番号６のフラグメント６に続いて、シーケンス番号８のフラグメント８を取得すると、シーケンス番号７のフラグメント（図中破線で示す箇所）がスキップされていると判定する。
FIG. 17A is a diagram for describing a first example of the structure of an MP4 file when a skip occurs.
The
なお、スキップ判定部３５１がスキップの有無を判定する際には、シーケンス番号以外の要素を用いることもできる。すなわち、各フラグメントにＭＰ４ファイルの先頭からの絶対アドレス値を持たせて、それぞれのフラグメントの先頭に、この絶対アドレス値の情報を記述し、絶対アドレス値の増分をカウントすることによってスキップの有無を判定することもできる。図を用いて、より具体的に説明する。
When the
図１７（ｂ）は、スキップが発生した場合におけるＭＰ４ファイルの構造の第２例を説明するための図である。
スキップ判定部３５１は、記録開始フラグメント（本図では、フラグメント５）からＭＰ４ファイル５００を構成する各フラグメントを順次取得し、各フラグメントの先頭に記述されている絶対アドレス値の増分をカウントする。ここで、絶対アドレス値の増分は、１フラグメントあたり２０００バイトであり、スキップ判定部３５１は、絶対アドレス値２００００バイトのフラグメント６に続いて、絶対アドレス値２４０００バイトのフラグメント８を取得すると、絶対アドレス値２２０００バイトのフラグメント（図中破線で示す箇所）がスキップされていると判定する。
FIG. 17B is a diagram for explaining a second example of the structure of the MP4 file when a skip occurs.
The
また、このスキップ判定部３５１は、スキップの発生を判定すると、スキップが発生した箇所を示すスキップ箇所表示情報を復号表示部３１３ｂに出力する。
そして、復号表示部３１３ｂは、スキップ判定部３５１からスキップ箇所表示情報を取得すると、この情報を用いて、スキップが発生した箇所を画像、音声またはテキストによって明示して再生出力する。
Further, when the
When the
図１８は、スキップが発生した場合におけるクライアント端末の画面表示例である。
携帯電話機であるクライアント端末３０ａの液晶表示部に、コンサート中継の映像が表示されている。ここで、現在の再生位置および再生済み箇所が画面中下方のバーに示されている。このバーで、ライブコンテンツの途中から再生を開始しているために、受信および再生されていない先頭部分を破線で示し、また、スキップが発生したために、受信および再生されていない箇所を点線で示すことによって、データ未受信の箇所を明示している。なお、この図は、表示の一例にすぎず、再生済みの箇所を緑色のバーで示し、スキップ発生箇所を赤色のバーで示す等の色分け表示によって明示する等してもよい。
FIG. 18 is a screen display example of the client terminal when a skip occurs.
Concert broadcast video is displayed on the liquid crystal display of the
再送リクエスト作成部３５２は、ユーザ指示入力部３３１ｂから再送リクエスト作成指示を取得すると、スキップ判定部３５１から出力されるスキップ情報に基づいて、スキップされたフラグメントデータの再送を要求する再送リクエストを作成し、リクエスト送信部３０３に出力する処理部である。
その後、リクエスト送信部３０３は、再送リクエスト作成部３５２から出力される再送リクエストをＨＴＴＰを用いて配信サーバ２０ａに送信する。
When the retransmission
Thereafter, the
図１９（ａ）は、ＨＴＴＰを用いた配信サーバ２０ａとクライアント端末３０ａ間の通信シーケンスの第１例を示す図である。
図１９（ａ）に示すように、まず、クライアント端末３０ａは、再送リクエストを配信サーバ２０ａに送信する（Ｓ３００）。ここで、送信される再送リクエストには、メソッド(GET)と、ファイルのＵＲＬ（http://…/….mp4）と、シーケンス番号１から４までのフラグメントの取得であることを示すＨＴＴＰ拡張部(SN=1-4)と、ＨＴＴＰのバージョン(HTTP/1.1)とが含まれている。
FIG. 19A is a diagram illustrating a first example of a communication sequence between the
As shown in FIG. 19A, first, the
配信サーバ２０ａは、再送リクエストを受信すると、リクエスト成功レスポンスをクライアント端末３０ａに送信し（Ｓ３０２）、続いて、エンティティボディにシーケンス番号１から４までのフラグメントデータを含めたレスポンスをクライアント端末３０ａに送信する（Ｓ３０４）。
クライアント端末３０ａは、同様に、シーケンス番号７のフラグメントの送信を求める再送リクエストを配信サーバ２０ａに送信する（Ｓ３０６）。
Upon receiving the retransmission request, the
Similarly, the
配信サーバ２０ａは、その再送リクエストを受信すると、こちらも同様に、リクエスト成功レスポンスをクライアント端末３０ａに送信し（Ｓ３０８）、続いて、エンティティボディにシーケンス番号７のフラグメントデータを含めたレスポンスをクライアント端末３０ａに送信する（Ｓ３１０）。
一方、絶対アドレス値の増分をカウントすることによってスキップの有無を判定する場合の通信シーケンスは、図１９（ｂ）のようになる。
When the
On the other hand, the communication sequence in the case where the presence / absence of the skip is determined by counting the increment of the absolute address value is as shown in FIG.
まず、クライアント端末３０ａは、再送リクエストを配信サーバ２０ａに送信する（Ｓ３２０）。ここで、送信される再送リクエストには、先に述べた再送リクエストと同様に、メソッド(GET)、ファイルのＵＲＬ（http://…/….mp4）およびＨＴＴＰのバージョン(HTTP/1.1)の他、リクエストヘッダフィールドが含まれており、このリクエストヘッダフィールドにデータの取得範囲(:Range byte=10000-17999)が記述されている。
First, the
配信サーバ２０ａは、再送リクエストを受信すると、リクエスト成功レスポンスをクライアント端末３０ａに送信し（Ｓ３２２）、続いて、エンティティボディに１００００バイトから１７９９９バイト分のフラグメントデータ、すなわち、図１７（ｂ）で示したＭＰ４ファイルでいえば、フラグメント１〜４までのフラグメントデータを含めたレスポンスをクライアント端末３０ａに送信する（Ｓ３２４）。
Upon receiving the retransmission request, the
クライアント端末３０ａは、同様に、絶対アドレス値が２２０００バイトの値を有するフラグメントの送信を求める再送リクエストを配信サーバ２０ａに送信する（Ｓ３２６）。この場合も、リクエストヘッダフィールドに、データの取得範囲(Range byte=22000-23999)が記述される。
配信サーバ２０ａは、その再送リクエストを受信すると、こちらも同様に、リクエスト成功レスポンスをクライアント端末３０ａに送信し（Ｓ３２８）、続いて、エンティティボディに２２０００バイトから２３９９９バイト分のフラグメントデータ、すなわち、図１７（ｂ）で示したＭＰ４ファイルでいえば、フラグメント７のフラグメントデータを含めたレスポンスをクライアント端末３０ａに送信する（Ｓ３３０）。ここでは、再送リクエストはコンテンツのストリーミング視聴終了後に行なうが、ストリーミング視聴中に再送リクエストを発行することとしてもよい。なお、上記ではスキップ発生時について述べたが、伝送路においてフラグメントデータが欠落した際にも同様の処理を適用することができる。
Similarly, the
When the
以上説明したようなクライアント端末の構成とすることで、上記実施の形態１〜３で説明したリアルタイム再生を実現するライブストリーミングシステムのように、フラグメントのスキップの発生等によってフラグメントデータが欠落する場合でも、欠落したフラグメントデータの再送を要求して、全てのフラグメントデータを揃えて記録することができるようになる。 By adopting the client terminal configuration as described above, even when fragment data is lost due to the occurrence of fragment skip, etc., as in the live streaming system that realizes real-time playback described in the first to third embodiments. Requesting retransmission of the missing fragment data makes it possible to record all the fragment data together.
（第３変形例）
さらに、本実施の形態４の第３変形例に係るライブストリーミングシステムを構成するクライアント端末について説明する。
図２０は、第３変形例に係るクライアント端末の一部構成を示すブロック図である。
図２０に示すように、この第３変形例に係るクライアント端末は、上記第２変形例のクライアント端末の構成と比較して、スタッフィング部３６１を備えている点で異なる。以下、この異なる点を中心に説明する。
(Third Modification)
Furthermore, a client terminal constituting the live streaming system according to the third modification of the fourth embodiment will be described.
FIG. 20 is a block diagram illustrating a partial configuration of a client terminal according to the third modification.
As shown in FIG. 20, the client terminal according to the third modification is different from the client terminal according to the second modification in that a stuffing unit 361 is provided. Hereinafter, this difference will be mainly described.
スキップ判定部３５１ａは、フラグメント記録制御部３３２ｂからフラグメントデータを取得して、フラグメントのスキップの有無を判定し、スキップが発生している箇所を示すスキップ情報をスタッフィング部３６１に出力するとともに、取得したフラグメントデータを記録部分フラグメント格納部３３３ａに格納する。
スタッフィング部３６１は、スキップ判定部３５１から出力されるスキップ情報に基づいて、記録開始フラグメント以前のフラグメントやスキップされたフラグメント等、未受信のデータ箇所を埋めるため、その箇所と同一サイズのフリーボックスからなるスタッフィングデータを作成して、記録部分フラグメント格納部３３３ａに格納する処理部である。スキップされたフラグメントのサイズは、フラグメントのサイズを一定にしておく、あるいは、各フラグメントの開始アドレスを示す情報をフラグメント内に格納しておくことにより取得する。
The
Based on the skip information output from the
また、このスタッフィング部３６１は、作成したスタッフィングデータが、どのシーケンス番号のフラグメントを埋めているかを示すスタッフィング情報を再送リクエスト作成部３５２ａに出力する。
再送リクエスト作成部３５２ａは、ユーザ指示入力部３３１ｂから出力される再送リクエスト作成指示を取得すると、スタッフィング部３６１から出力されるスタッフィング情報に基づいて、スタッフィングデータで埋められているフラグメントデータの再送を要求する再送リクエストを作成し、リクエスト送信部３０３に出力する。
In addition, the stuffing unit 361 outputs stuffing information indicating which sequence number fragment the created stuffing data embeds to the retransmission
When the retransmission
その後、リクエスト送信部３０３は、再送リクエストをＨＴＴＰを用いて配信サーバ２０ａに送信する。そして、クライアント端末が、配信サーバ２０ａからその再送リクエストに対するレスポンスのエンティティボディに含まれるフラグメントデータを取得すると、スキップ判定部３５１ａは、受信データメモリ３０８ａやフラグメント記録制御部３３２ｂを経由して取得したフラグメントデータを、スタッフィングデータと置換して記録部分フラグメント格納部３３３ａに格納する。このスタッフィングデータと置換する様子を、図を用いて説明する。ここで、上記第２変形例と同様に、記録開始フラグメントがシーケンス番号５のフラグメント５であり、シーケンス番号７のフラグメント７がスキップされているとする。
Thereafter, the
図２１は、スタッフィングデータを用いた場合におけるＭＰ４ファイルの構造を説明するための図である。
まず、ライブストリーミング再生の終了段階では、スキップ判定部３５１ａが、順次受信したフラグメントデータを記録部分フラグメント格納部３３３ａに格納し、スキップの発生等によって受信していないフラグメントデータについては、スタッフィング部３６１がそのフラグメントデータを埋めるための、同じバイトサイズ分のフリーボックス６０１および６０２を作成して、記録部分フラグメント格納部３３３ａに格納するので、ＭＰ４ファイル６００が記録部分フラグメント格納部３３３ａに格納されることになる。
FIG. 21 is a diagram for explaining the structure of an MP4 file when stuffing data is used.
First, at the end stage of the live streaming playback, the
ここで、ユーザ指示入力部３３１ｂから再送リクエスト作成部３５２ａに再送リクエスト作成指示が出力されると、配信サーバ２０ａに再送リクエストがＨＴＴＰを用いて送信され、配信サーバ２０ａから、その再送リクエストに対するレスポンスとして、エンティティボディにシーケンス番号１〜４のフラグメントデータ６０３とシーケンス番号７のフラグメントデータ６０４とが含まれたレスポンスが返ってくる。
Here, when a retransmission request creation instruction is output from the user
スキップ判定部３５１ａは、受信データメモリ３０８ａやフラグメント記録制御部３３２ｂを経由して、このフラグメントデータ６０３を取得すると、記録部分フラグメント格納部３３３ａに格納されているＭＰ４ファイル６００のフリーボックス６０１の部分に、フラグメントデータ６０３を上書きする。同様にして、スキップ判定部３５１ａは、記録部分フラグメント格納部３３３ａに格納されているＭＰ４ファイル６００のフリーボックス６０２の部分に、フラグメントデータ６０４を上書きする。
When the
このようにして、最終的には、記録部分フラグメント格納部３３３ａに、欠落したフラグメントのないＭＰ４ファイル６１０が格納されることになる。
このようにクライアント端末を構成することで、フラグメントのスキップの発生等によってフラグメントデータが欠落している箇所に、欠落したフラグメントデータ分のスタッフィングデータを作成しておくことができる。そして、送信要求により全てのフラグメントデータを揃えて記録する際には、このスタッフィングデータに取得したフラグメントデータを置き換えればよく、既に記録済みのフラグメントデータの格納領域を書き換える必要がなくなり、ＭＰ４ファイルの再構成時の処理負担を軽減することができる。
In this way, finally, the
By configuring the client terminal in this way, it is possible to create stuffing data for the missing fragment data at a location where the fragment data is missing due to fragment skipping or the like. When all the fragment data is recorded in accordance with the transmission request, it is only necessary to replace the acquired fragment data with the stuffing data, and it is not necessary to rewrite the storage area of the already recorded fragment data. The processing burden during configuration can be reduced.
以上、本発明に係るデータ多重化方法、データ送信方法およびデータ受信方法について各実施の形態および変形例に基づき説明したが、本発明は、これらの実施の形態や変形例に限定されるものではない。
例えば、上記各実施の形態では、ビデオデータの符号化方式として、ＭＰＥＧ−４ Ｖｉｓｕａｌを例示しているが、ＭＰＥＧ−４ ＡＶＣ(Advanced Video Coding)やＨ．２６３等のその他の動画像圧縮符号化方式を用いてもよい。なお、ＭＰＥＧ−４ ＡＶＣやＨ．２６３の符号化データでは、１ピクチャが１サンプルに相当することになる。
As described above, the data multiplexing method, the data transmission method, and the data reception method according to the present invention have been described based on the respective embodiments and modifications. However, the present invention is not limited to these embodiments and modifications. Absent.
For example, in each of the above embodiments, MPEG-4 Visual is exemplified as a video data encoding method, but MPEG-4 AVC (Advanced Video Coding) or H.264 is exemplified. Other video compression encoding methods such as H.263 may be used. MPEG-4 AVC and H.264 In the encoded data of H.263, one picture corresponds to one sample.
同様に、オーディオデータの符号化方式として、ＭＰＥＧ−４ ＡＡＣを例示しているが、ＡＭＲやＧ．７２６等のその他の音声圧縮符号化方式を用いてもよい。
また、上記各実施の形態では、ビデオデータとオーディオデータとを用いて説明しているが、テキストデータ等を排除する趣旨でないことはいうまでもない。
さらに、上記実施の形態３において、ビデオサンプルとオーディオサンプルとの同期を図るための同期情報として、ビデオサンプルおよびオーディオサンプルの表示時刻を用いているが、ビデオサンプルの表示開始時間とオーディオサンプルの表示開始時間との差分値を用いることとしてもよい。
Similarly, MPEG-4 AAC is exemplified as an audio data encoding method. Other audio compression encoding schemes such as 726 may be used.
In each of the above embodiments, video data and audio data are used for explanation, but it goes without saying that text data and the like are not excluded.
Further, in the third embodiment, the display time of the video sample and the audio sample is used as the synchronization information for synchronizing the video sample and the audio sample. However, the display start time of the video sample and the display of the audio sample are used. A difference value from the start time may be used.
なお、上記各実施の形態において使用するＭＰ４ファイルでは、基本部のムービーデータボックスを省略することとしたが、コンテンツのサムネイル画像や、コンテンツの紹介映像などを基本部のムービーデータボックスに格納し、初期ヘッダ情報と合わせてクライアント端末に送信することとしてもよい。クライアント端末では、コンテンツの再生開始前に自動的に、あるいは、ユーザの指示や端末設定に応じて選択的に、基本部のムービーデータボックスに格納されたデータを再生する。 In the MP4 file used in each of the above embodiments, the movie data box of the basic part is omitted. However, the thumbnail image of the content, the introduction video of the content, etc. are stored in the movie data box of the basic part, It is good also as transmitting to a client terminal together with initial header information. The client terminal reproduces the data stored in the movie data box of the basic part automatically before starting the reproduction of the content or selectively according to a user instruction or terminal setting.
本発明に係るデータ多重化方法、データ受信方法およびデータ送信方法は、コンサート中継やスポーツ中継等のライブコンテンツを配信する画像配信システム等に適用することができ、特に、ＭＰ４ファイルをＨＴＴＰを用いてリアルタイム配信するライブストリーミングシステム等に好適である。 The data multiplexing method, data receiving method, and data transmitting method according to the present invention can be applied to an image distribution system that distributes live content such as a concert broadcast or a sports broadcast, and in particular, an MP4 file using HTTP. It is suitable for a live streaming system that distributes in real time.
１０、９３０ エンコーダ
２０、２０ａ、９４０ 配信サーバ
３０、３０ａ、９５０ クライアント端末
１０１ ビデオ符号化部
１０２ ビデオデータ蓄積部
１０３ オーディオ符号化部
１０４ オーディオデータ蓄積部
１０５ パケット作成命令部
１０６、１０６ａ パケットヘッダ作成部
１０７ パケットサイズ判定部
１０８ サイズ調整部
１０９ パケットデータ作成部
１１０ パケット結合部
１２１ ビデオヘッダ情報解析部
１２２ オーディオヘッダ情報解析部
１２３ 同期情報決定部
１２４ 同期情報格納ボックス作成部
１２５ ヘッダ情報作成部
２０１ 多重化データ受信部
２０２ 多重化データ蓄積部
２０３ リクエスト受信部
２０４ リクエスト解析部
２０５ サイズ情報取得部
２０６、２１６ 送信データ制御部
２０７ 送信データメモリ
２０８、２１８ レスポンス送信部
２１１ 遅延判定部
３０１ コンテンツＵＲＬ取得部
３０２ 第１リクエスト作成部
３０３ リクエスト送信部
３０４ レスポンス受信部
３０５ 第１レスポンス解析部
３０６、３０６ａ 第２リクエスト作成部
３０７、３０７ａ 第２レスポンス解析部
３０８、３０８ａ 受信データメモリ
３０９、３０９ａ フラグメント受信完了判定部
３１０、３１０ａ 多重化データ分離部
３１１、３１１ａ ヘッダ解析部
３１２ サンプルデータ取得部
３１３、３１３ａ、３１３ｂ 復号表示部
３２１ 同期情報設定フラグメント判定部
３２２ ｔｒａｆ分離解析部
３２３ ｍｆｓｙ分離解析部
３３１、３３１ａ、３３１ｂ ユーザ指示入力部
３３２、３３２ａ、３３２ｂ フラグメント記録制御部
３３３、３３３ａ 記録部分フラグメント格納部
３４１ 記録箇所情報メモリ
３４２ 再生区間判定部
３５１、３５１ａ スキップ判定部
３５２、３５２ａ 再送リクエスト作成部
３６１ スタッフィング部
４００、５００、６００、６１０、９１０、９２０ ＭＰ４ファイル
６０１、６０２ フリーボックス
６０３、６０４ フラグメントデータ
９０１ ボックス
９０２ ボックスヘッダ部
９０３ ボックスデータ格納部
９０４ ボックスサイズ
９０５ ボックスタイプ
９０６ バージョン
９０７ フラグ
９１１ 基本部
９１２ ファイルヘッダ部
９１３ ファイルデータ部
９１４ ファイルタイプボックス
９１５ ムービーボックス
９１６ ムービーデータボックス
９２１ 拡張部
９２２ ムービーフラグメント
９２３ ムービーフラグメントボックス
DESCRIPTION OF SYMBOLS 10,930 Encoder 20,20a, 940 Distribution server 30,30a, 950 Client terminal 101 Video encoding part 102 Video data storage part 103 Audio encoding part 104 Audio data storage part 105 Packet creation command part 106, 106a Packet header preparation part 107 packet size determination unit 108 size adjustment unit 109 packet data creation unit 110 packet combination unit 121 video header information analysis unit 122 audio header information analysis unit 123 synchronization information determination unit 124 synchronization information storage box creation unit 125 header information creation unit 201 multiplexing Data reception unit 202 Multiplexed data storage unit 203 Request reception unit 204 Request analysis unit 205 Size information acquisition unit 206, 216 Transmission data control unit 207 Transmission data memory 208, 218 Response transmission unit 211 Delay determination unit 301 Content URL acquisition unit 302 First request creation unit 303 Request transmission unit 304 Response reception unit 305 First response analysis unit 306, 306a Second request creation unit 307, 307a Second response analysis Unit 308, 308a Received data memory 309, 309a Fragment reception completion determination unit 310, 310a Multiplexed data separation unit 311, 311a Header analysis unit 312 Sample data acquisition unit 313, 313a, 313b Decoding display unit 321 Synchronization information setting fragment determination unit 322 traf separation analysis unit 323 mfsy separation analysis unit 331, 331a, 331b user instruction input unit 332, 332a, 332b fragment recording control unit 333, 333a recording part Fragment storage unit 341 Recording location information memory 342 Playback section determination unit 351, 351a Skip determination unit 352, 352a Retransmission request creation unit 361 Stuffing unit 400, 500, 600, 610, 910, 920 MP4 file 601, 602 Free box 603, 604 Fragment data 901 Box 902 Box header part 903 Box data storage part 904 Box size 905 Box type 906 Version 907 Flag 911 Basic part 912 File header part 913 File data part 914 File type box 915 Movie box 916 Movie data box 921 Extension part 922 Movie Fragment 923 Movie fragment box
Claims (18)
前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を前記サーバ装置に要求するデータ取得リクエストを作成するリクエスト作成ステップと、
前記データ取得リクエストを、ＨＴＴＰ(Hypertext Transfer Protocol)によって前記サーバ装置に送信するリクエスト送信ステップと、
前記データ取得リクエストに対する応答として、前記共通ヘッダおよび前記最新パケットを含むレスポンスを前記サーバ装置からＨＴＴＰによって受信するレスポンス受信ステップとを含む
ことを特徴とするデータ受信方法。 Data reception for receiving a file composed of a common header, which is a header common to the entire content, and entity data of the content and a plurality of packets storing header information of the entity data from a server device connected via a network A method,
A request creation step of creating a data acquisition request for requesting the server device to deliver a latest packet storing the latest entity data in the common header and the content;
A request transmission step of transmitting the data acquisition request to the server device by HTTP (Hypertext Transfer Protocol);
A response reception step of receiving, as a response to the data acquisition request, a response including the common header and the latest packet from the server device by HTTP.
前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報の配信を前記サーバ装置に要求するサイズ情報取得リクエストを作成するサイズ情報取得リクエスト作成ステップと、
前記サイズ情報取得リクエストを、ＨＴＴＰによって前記サーバ装置に送信するサイズ情報取得リクエスト送信ステップと、
前記サイズ情報取得リクエストに対する応答として、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を含むサイズ情報レスポンスを前記サーバ装置からＨＴＴＰによって受信するサイズ情報レスポンス受信ステップとを含み、
前記リクエスト作成ステップにおいて、前記サイズ情報レスポンス受信ステップにおいて受信した前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報に基づいて、前記データ取得リクエストを作成する
ことを特徴とする請求項１記載のデータ受信方法。 The data receiving method further includes:
A size information acquisition request creating step for creating a size information acquisition request for requesting the server device to deliver the size information of the common header and the size information of the latest packet;
A size information acquisition request transmission step of transmitting the size information acquisition request to the server device by HTTP;
As a response to the size information acquisition request, a size information response reception step of receiving a size information response including the size information of the common header and the size information of the latest packet from the server device by HTTP,
2. The data according to claim 1, wherein, in the request creation step, the data acquisition request is created based on the size information of the common header and the size information of the latest packet received in the size information response reception step. Receiving method.
ことを特徴とする請求項１記載のデータ受信方法。 The data reception request according to claim 1, wherein, in the request creation step, the data acquisition request is created by describing information indicating that the common header and the delivery of the latest packet are requested in an extension part of HTTP. Method.
前記リクエスト受信ステップにおいて、前記第１データ取得リクエストに対する応答として、前記共通ヘッダを含む第１レスポンスと、前記第２データ取得リクエストに対する応答として、前記最新パケットを含む第２レスポンスとをＨＴＴＰによって受信する
ことを特徴とする請求項１〜３のいずれか１項に記載のデータ受信方法。 In the request creation step, a first data acquisition request for requesting delivery of the common header and a second data acquisition request for requesting delivery of the latest packet are created. In the request transmission step, the first data acquisition request A request and the second data acquisition request are independently transmitted to the server apparatus by HTTP;
In the request reception step, as a response to the first data acquisition request, a first response including the common header and a second response including the latest packet as a response to the second data acquisition request are received by HTTP. The data receiving method according to any one of claims 1 to 3.
前記パケットに含まれるデータを受信して再生する際の再生開始時間が、前記ファイルを実時間で再生した際の当該パケットの再生開始時間に対して所定の閾値以上遅延する場合に、時間的に不連続となるパケットの受信を行なうか、時間的に連続するパケットの受信を行なうかの選択を受け付けるスキップ受信選択受付ステップを含み、
前記リクエスト作成ステップにおいて、前記スキップ受信選択受付ステップにおける選択結果を示す情報を記述したデータ取得リクエストを作成する
ことを特徴とする請求項１〜４のいずれか１項に記載のデータ受信方法。 The data receiving method further includes:
When the playback start time when receiving and playing back the data included in the packet is delayed by a predetermined threshold or more with respect to the playback start time of the packet when the file is played back in real time, A skip reception selection accepting step for accepting a selection of whether to receive a discontinuous packet or a temporally continuous packet;
5. The data reception method according to claim 1, wherein, in the request creation step, a data acquisition request describing information indicating a selection result in the skip reception selection reception step is created.
前記スキップ受信選択受付ステップにおいて、時間的に不連続となるパケットの受信を行なう選択を受け付けた場合に、不連続となった箇所を表示するスキップ発生表示ステップを含む
ことを特徴とする請求項５記載のデータ受信方法。 The data receiving method further includes:
The skip reception selection reception step includes a skip generation display step of displaying a discontinuous portion when a selection for receiving a packet that is discontinuous in time is received. The data receiving method described.
１つ以上のパケット毎に作成された前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を取得する同期情報取得ステップと、
前記同期情報取得ステップにおいて取得した同期情報を用いて、前記メディアデータを再生する同期再生ステップとを含む
ことを特徴とする請求項１〜６のいずれか１項に記載のデータ受信方法。 The data receiving method further includes:
A synchronization information acquisition step of acquiring synchronization information for synchronizing playback between media data included in the packets created for each of one or more packets;
The data reception method according to claim 1, further comprising: a synchronous reproduction step of reproducing the media data using the synchronization information acquired in the synchronization information acquisition step.
前記端末装置から前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報の配信を要求するサイズ情報取得リクエストを受信するサイズ情報取得リクエスト受信ステップと、
前記サイズ情報取得リクエストを解析して、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を作成するサイズ情報作成ステップと、
前記サイズ情報取得リクエストに対する応答として、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を含むサイズ情報レスポンスを作成するサイズ情報レスポンス作成ステップと、
前記サイズ情報レスポンスを、ＨＴＴＰによって前記端末装置に送信するサイズ情報レスポンス送信ステップと
前記端末装置から、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報に基づいて作成され、前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を要求するデータ取得リクエストを受信するリクエスト受信ステップと、
前記データ取得リクエストを解析して、前記最新パケットを決定する最新パケット判定ステップと、
前記データ取得リクエストに対する応答であり、前記共通ヘッダと、前記最新パケット判定ステップにおいて決定した前記最新パケットとを含むレスポンスを作成するレスポンス作成ステップと、
前記レスポンスを、ＨＴＴＰによって前記端末装置に送信するレスポンス送信ステップとを含む
ことを特徴とするデータ送信方法。 Data transmission for transmitting a file composed of a common header, which is a header common to all contents, and entity data of the content and a plurality of packets storing the header information of the entity data to a terminal device connected via a network A method,
A size information acquisition request receiving step for receiving a size information acquisition request for requesting distribution of the size information of the common header and the size information of the latest packet from the terminal device;
Analyzing the size information acquisition request, creating size information for creating the size information of the common header and the size information of the latest packet;
As a response to the size information acquisition request, a size information response creating step for creating a size information response including the size information of the common header and the size information of the latest packet;
A size information response transmission step for transmitting the size information response to the terminal device by HTTP, and the terminal device is created based on the size information of the common header and the size information of the latest packet, and the common header and the content A request receiving step for receiving a data acquisition request for requesting delivery of the latest packet storing the latest entity data in
Analyzing the data acquisition request to determine the latest packet; a latest packet determining step;
A response creation step for creating a response that is a response to the data acquisition request and includes the common header and the latest packet determined in the latest packet determination step;
A response transmission step of transmitting the response to the terminal device by HTTP.
前記レスポンス送信ステップにおいて送信されるパケットに含まれる前記データの再生開始時間が、前記ファイルを実時間で再生した場合に対してどれだけ遅延しているかを示す遅延時間を取得する遅延時間取得ステップと、
前記遅延時間取得ステップにおいて取得した情報に基づいて、前記遅延時間が所定の閾値以上開いたか否かを判定する遅延判定ステップと、
前記遅延判定ステップにおいて、前記遅延時間が所定の閾値以上開いたと判定した場合に、時間的に不連続となるパケットの送信を決定するスキップ決定ステップとを含み、
前記レスポンス作成ステップにおいて、前記スキップ決定ステップにおける決定に基づいて、前記時間的に不連続となるパケットを含むスキップレスポンスを作成し、
前記レスポンス送信ステップにおいて、前記スキップレスポンスをＨＴＴＰによって前記端末装置に送信する
ことを特徴とする請求項８記載のデータ送信方法。 The data transmission method further includes:
A delay time acquisition step of acquiring a delay time indicating how much the reproduction start time of the data included in the packet transmitted in the response transmission step is delayed with respect to a case where the file is reproduced in real time; ,
Based on the information acquired in the delay time acquisition step, a delay determination step of determining whether or not the delay time is opened more than a predetermined threshold;
In the delay determination step, when it is determined that the delay time is opened more than a predetermined threshold, a skip determination step of determining transmission of a packet that is discontinuous in time,
In the response creation step, based on the determination in the skip determination step, create a skip response including the temporally discontinuous packet,
The data transmission method according to claim 8, wherein, in the response transmission step, the skip response is transmitted to the terminal device by HTTP.
１つ以上のパケット毎に前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を作成する同期情報作成ステップと、
前記同期情報作成ステップにおいて作成した同期情報を含むファイルを作成するファイル作成ステップとを含む
ことを特徴とするデータ多重化方法。 A file composed of a plurality of media data included in a content and a common header that is a header common to the entire content, and entity data of the content and a plurality of packets that store header information of the entity data A data multiplexing method for creating
A synchronization information creation step of creating synchronization information for synchronizing playback between media data included in the packets for each of one or more packets;
And a file creation step of creating a file including the synchronization information created in the synchronization information creation step.
前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を前記サーバ装置に要求するデータ取得リクエストを作成するリクエスト作成手段と、
前記データ取得リクエストを、ＨＴＴＰによって前記サーバ装置に送信するリクエスト送信手段と、
前記データ取得リクエストに対する応答として、前記共通ヘッダおよび前記最新パケットを含むレスポンスを前記サーバ装置からＨＴＴＰによって受信するレスポンス受信手段とを備える
ことを特徴とするデータ受信装置。 Data reception for receiving a file composed of a common header, which is a header common to the entire content, and entity data of the content and a plurality of packets storing header information of the entity data from a server device connected via a network A device,
Request creation means for creating a data acquisition request for requesting the server device to deliver a latest packet storing the latest actual data in the common header and the content;
Request transmission means for transmitting the data acquisition request to the server device by HTTP;
Response receiving means for receiving, as a response to the data acquisition request, a response including the common header and the latest packet from the server device by HTTP.
前記端末装置から前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報の配信を要求するサイズ情報取得リクエストを受信するサイズ情報取得リクエスト受信手段と、
前記サイズ情報取得リクエストを解析して、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を作成するサイズ情報作成手段と、
前記サイズ情報取得リクエストに対する応答として、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を含むサイズ情報レスポンスを作成するサイズ情報レスポンス作成手段と、
前記サイズ情報レスポンスを、ＨＴＴＰによって前記端末装置に送信するサイズ情報レスポンス送信手段と
前記端末装置から、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報に基づいて作成され、前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を要求するデータ取得リクエストを受信するリクエスト受信手段と、
前記データ取得リクエストを解析して、前記最新パケットを決定する最新パケット判定手段と、
前記データ取得リクエストに対する応答であり、前記共通ヘッダと、前記最新パケット判定手段が決定した前記最新パケットとを含むレスポンスを作成するレスポンス作成手段と、
前記レスポンスを、ＨＴＴＰによって前記端末装置に送信するレスポンス送信手段とを備える
ことを特徴とするデータ送信装置。 Data transmission for transmitting a file composed of a common header, which is a header common to all contents, and entity data of the content and a plurality of packets storing the header information of the entity data to a terminal device connected via a network A device,
Size information acquisition request receiving means for receiving a size information acquisition request for requesting distribution of the size information of the common header and the size information of the latest packet from the terminal device;
Analyzing the size information acquisition request, size information creating means for creating size information of the common header and size information of the latest packet;
As a response to the size information acquisition request, size information response creating means for creating a size information response including size information of the common header and size information of the latest packet;
The size information response is generated based on the size information of the common header and the size information of the latest packet from the terminal device, and the size information response transmission means for transmitting the size information response to the terminal device by HTTP. Request receiving means for receiving a data acquisition request for requesting delivery of the latest packet storing the latest entity data in
Analyzing the data acquisition request and determining the latest packet; latest packet determination means;
A response creation unit that creates a response that is a response to the data acquisition request and includes the common header and the latest packet determined by the latest packet determination unit;
Response transmitting means for transmitting the response to the terminal device by HTTP. A data transmitting device comprising:
前記レスポンス送信手段が送信するパケットに含まれる前記データの再生開始時間が、前記ファイルを実時間で再生した場合に対してどれだけ遅延しているかを示す遅延時間を取得する遅延時間取得手段と、
前記遅延時間取得手段が取得した情報に基づいて、前記遅延時間が所定の閾値以上開いたか否かを判定する遅延判定手段と、
前記遅延判定手段が、前記遅延時間が所定の閾値以上開いたと判定した場合に、時間的に不連続となるパケットの送信を決定するスキップ決定手段とを備え、
前記レスポンス作成手段は、前記スキップ決定手段の決定に基づいて、前記時間的に不連続となるパケットを含むスキップレスポンスを作成し、
前記レスポンス送信手段は、前記スキップレスポンスをＨＴＴＰによって前記端末装置に送信する
ことを特徴とする請求項１２記載のデータ送信装置。 The data transmission device further includes:
A delay time acquisition means for acquiring a delay time indicating how much the reproduction start time of the data included in the packet transmitted by the response transmission means is delayed when the file is reproduced in real time;
A delay determining unit that determines whether or not the delay time is opened by a predetermined threshold or more based on the information acquired by the delay time acquiring unit;
When the delay determination unit determines that the delay time is opened more than a predetermined threshold, a skip determination unit that determines transmission of a packet that is temporally discontinuous,
The response creating means creates a skip response including the temporally discontinuous packet based on the determination of the skip determining means,
The data transmission device according to claim 12, wherein the response transmission unit transmits the skip response to the terminal device by HTTP.
１つ以上のパケット毎に前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を作成する同期情報作成手段と、
前記同期情報作成手段が作成した同期情報を含むファイルを作成するファイル作成手段とを備える
ことを特徴とするデータ多重化装置。 A file composed of a plurality of media data included in a content and a common header that is a header common to the entire content, and entity data of the content and a plurality of packets that store header information of the entity data A data multiplexing device for creating
Synchronization information creating means for creating synchronization information for synchronizing reproduction between media data included in the packets for each of one or more packets;
A data multiplexing apparatus comprising: a file creation unit that creates a file including the synchronization information created by the synchronization information creation unit.
前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を前記サーバ装置に要求するデータ取得リクエストを作成するリクエスト作成ステップと、
前記データ取得リクエストを、ＨＴＴＰによって前記サーバ装置に送信するリクエスト送信ステップと、
前記データ取得リクエストに対する応答として、前記共通ヘッダおよび前記最新パケットを含むレスポンスを前記サーバ装置からＨＴＴＰによって受信するレスポンス受信ステップとをコンピュータに実行させる
ことを特徴とするプログラム。 Data reception for receiving a file composed of a common header, which is a header common to the entire content, and entity data of the content and a plurality of packets storing header information of the entity data from a server device connected via a network A program for a device,
A request creation step of creating a data acquisition request for requesting the server device to deliver a latest packet storing the latest entity data in the common header and the content;
A request transmission step of transmitting the data acquisition request to the server device by HTTP;
A program that causes a computer to execute a response reception step of receiving a response including the common header and the latest packet from the server device by HTTP as a response to the data acquisition request.
前記端末装置から前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報の配信を要求するサイズ情報取得リクエストを受信するサイズ情報取得リクエスト受信ステップと、
前記サイズ情報取得リクエストを解析して、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を作成するサイズ情報作成ステップと、
前記サイズ情報取得リクエストに対する応答として、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報を含むサイズ情報レスポンスを作成するサイズ情報レスポンス作成ステップと、
前記サイズ情報レスポンスを、ＨＴＴＰによって前記端末装置に送信するサイズ情報レスポンス送信ステップと
前記端末装置から、前記共通ヘッダのサイズ情報および前記最新パケットのサイズ情報に基づいて作成され、前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を要求するデータ取得リクエストを受信するリクエスト受信ステップと、
前記データ取得リクエストを解析して、前記最新パケットを決定する最新パケット判定ステップと、
前記データ取得リクエストに対する応答であり、前記共通ヘッダと、前記最新パケット判定ステップにおいて決定した前記最新パケットとを含むレスポンスを作成するレスポンス作成ステップと、
前記レスポンスを、ＨＴＴＰによって前記端末装置に送信するレスポンス送信ステップとをコンピュータに実行させる
ことを特徴とするプログラム。 Data transmission for transmitting a file composed of a common header, which is a header common to all contents, and entity data of the content and a plurality of packets storing the header information of the entity data to a terminal device connected via a network A program for a device,
A size information acquisition request receiving step for receiving a size information acquisition request for requesting distribution of the size information of the common header and the size information of the latest packet from the terminal device;
Analyzing the size information acquisition request, creating size information for creating the size information of the common header and the size information of the latest packet;
As a response to the size information acquisition request, a size information response creating step for creating a size information response including the size information of the common header and the size information of the latest packet;
A size information response transmission step for transmitting the size information response to the terminal device by HTTP, and the terminal device is created based on the size information of the common header and the size information of the latest packet, and the common header and the content A request receiving step for receiving a data acquisition request for requesting delivery of the latest packet storing the latest entity data in
Analyzing the data acquisition request to determine the latest packet; a latest packet determining step;
A response creation step for creating a response that is a response to the data acquisition request and includes the common header and the latest packet determined in the latest packet determination step;
A program that causes a computer to execute a response transmission step of transmitting the response to the terminal device by HTTP.
１つ以上のパケット毎に前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を作成する同期情報作成ステップと、
前記同期情報作成ステップにおいて作成した同期情報を含むファイルを作成するファイル作成ステップとをコンピュータに実行させる
ことを特徴とするプログラム。 A file configured by multiplexing a plurality of media data included in a content and including a common header which is a header common to the entire content, and a plurality of packets storing entity data of the content and header information of the entity data A program for a data multiplexing device for creating
A synchronization information creation step of creating synchronization information for synchronizing playback between media data included in the packets for each of one or more packets;
A program for causing a computer to execute a file creation step for creating a file including the synchronization information created in the synchronization information creation step.
前記データ多重化装置は、
１つ以上のパケット毎に前記パケットに含まれるメディアデータ間の同期再生を図るための同期情報を作成する同期情報作成手段と、
前記同期情報作成手段が作成した同期情報を含むファイルを作成するファイル作成手段とを備え、
前記データ受信装置は、
前記共通ヘッダおよび前記コンテンツにおける最新の実体データを格納する最新パケットの配信を前記データ送信装置に要求するデータ取得リクエストを作成するリクエスト作成手段と、
前記データ取得リクエストを、ＨＴＴＰによって前記データ送信装置に送信するリクエスト送信手段と、
前記データ取得リクエストに対する応答として、前記共通ヘッダおよび前記最新パケットを含むレスポンスを前記データ送信装置からＨＴＴＰによって受信するレスポンス受信手段と、
前記同期情報を用いて、前記メディアデータを再生する同期再生手段とを備え、
前記データ送信装置は、
前記データ受信装置から前記データ取得リクエストを受信するリクエスト受信手段と、
前記データ取得リクエストを解析して、前記最新パケットを決定する最新パケット判定手段と、
前記データ取得リクエストに対する応答として、前記レスポンスを作成するレスポンス作成手段と、
前記レスポンスを、ＨＴＴＰによって前記データ受信装置に送信するレスポンス送信手段とを備える
ことを特徴とするストリーミング配信システム。
A file composed of a plurality of media data included in a content and a common header that is a header common to the entire content, and entity data of the content and a plurality of packets that store header information of the entity data Streaming distribution comprising: a data multiplexing device for generating a file; a data transmitting device for transmitting the file to a data receiving device connected via a network; and a data receiving device for receiving the file from a data transmitting device connected via a network A system,
The data multiplexing device comprises:
Synchronization information creating means for creating synchronization information for synchronizing reproduction between media data included in the packets for each of one or more packets;
A file creation means for creating a file including the synchronization information created by the synchronization information creation means,
The data receiving device is:
Request creation means for creating a data acquisition request for requesting the data transmission device to deliver the latest packet storing the latest actual data in the common header and the content;
Request transmitting means for transmitting the data acquisition request to the data transmitting apparatus by HTTP;
As a response to the data acquisition request, a response receiving unit that receives a response including the common header and the latest packet from the data transmission device by HTTP;
Synchronous playback means for playing back the media data using the synchronization information,
The data transmission device includes:
Request receiving means for receiving the data acquisition request from the data receiving device;
Analyzing the data acquisition request and determining the latest packet; latest packet determination means;
Response creation means for creating the response as a response to the data acquisition request;
Response distribution means for transmitting the response to the data receiving device by HTTP. A streaming distribution system comprising:
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003314530A JP2005086362A (en) | 2003-09-05 | 2003-09-05 | Data multiplexing method, data transmitting method and data receiving method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003314530A JP2005086362A (en) | 2003-09-05 | 2003-09-05 | Data multiplexing method, data transmitting method and data receiving method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2005086362A true JP2005086362A (en) | 2005-03-31 |
Family
ID=34415096
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003314530A Pending JP2005086362A (en) | 2003-09-05 | 2003-09-05 | Data multiplexing method, data transmitting method and data receiving method |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2005086362A (en) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006323678A (en) * | 2005-05-19 | 2006-11-30 | Canon Inc | Content reproduction method, content reproduction system and computer program |
| WO2007074520A1 (en) * | 2005-12-27 | 2007-07-05 | Mitsubishi Denki Kabushiki Kaisha | Distributing apparatus and reproducer |
| WO2008020547A1 (en) | 2006-08-17 | 2008-02-21 | Sony Corporation | Communication processing device, communication control method, and computer program |
| JP2009225025A (en) * | 2008-03-14 | 2009-10-01 | Fujitsu Ltd | Receiving apparatus and receiving method |
| JP2011228791A (en) * | 2010-04-15 | 2011-11-10 | Fujitsu Toshiba Mobile Communications Ltd | Content playback apparatus and content playback method |
| JP2013503390A (en) * | 2009-08-28 | 2013-01-31 | アップル インコーポレイテッド | Chunk format download on content distribution network |
| WO2013018517A1 (en) * | 2011-07-29 | 2013-02-07 | ソニー株式会社 | Streaming distribution device and method, streaming receiving device and method, streaming system, program, and recording medium |
| US8411755B2 (en) | 2008-08-29 | 2013-04-02 | Canon Kabushiki Kaisha | Video transmission apparatus and control method for video transmission apparatus |
| JP2014116805A (en) * | 2012-12-10 | 2014-06-26 | Canon Inc | Imaging device, information processing device, control method therefor, and video processing system |
| JP2014529258A (en) * | 2011-09-06 | 2014-10-30 | クアルコム，インコーポレイテッド | Network streaming of encoded video data |
| JP2019517219A (en) * | 2016-05-24 | 2019-06-20 | ディビックス， エルエルシー | System and method for providing audio content during trick play playback |
| JP2021508428A (en) * | 2018-05-29 | 2021-03-04 | 北京字節跳動網絡技術有限公司Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ． | Media file playback methods, devices and storage media based on web pages |
| US11178205B2 (en) | 2020-01-20 | 2021-11-16 | Ideaforge Technology Pvt. Ltd. | System and method for providing live streaming of video data in a low-bandwidth network |
| CN113709412A (en) * | 2020-05-21 | 2021-11-26 | 中国电信股份有限公司 | Live stream processing method, device and system and computer readable storage medium |
-
2003
- 2003-09-05 JP JP2003314530A patent/JP2005086362A/en active Pending
Cited By (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006323678A (en) * | 2005-05-19 | 2006-11-30 | Canon Inc | Content reproduction method, content reproduction system and computer program |
| WO2007074520A1 (en) * | 2005-12-27 | 2007-07-05 | Mitsubishi Denki Kabushiki Kaisha | Distributing apparatus and reproducer |
| JPWO2007074520A1 (en) * | 2005-12-27 | 2009-06-04 | 三菱電機株式会社 | Distribution device and playback device |
| JP4680268B2 (en) * | 2005-12-27 | 2011-05-11 | 三菱電機株式会社 | Distribution device and playback device |
| WO2008020547A1 (en) | 2006-08-17 | 2008-02-21 | Sony Corporation | Communication processing device, communication control method, and computer program |
| JP2009225025A (en) * | 2008-03-14 | 2009-10-01 | Fujitsu Ltd | Receiving apparatus and receiving method |
| US8411755B2 (en) | 2008-08-29 | 2013-04-02 | Canon Kabushiki Kaisha | Video transmission apparatus and control method for video transmission apparatus |
| JP2013503390A (en) * | 2009-08-28 | 2013-01-31 | アップル インコーポレイテッド | Chunk format download on content distribution network |
| JP2011228791A (en) * | 2010-04-15 | 2011-11-10 | Fujitsu Toshiba Mobile Communications Ltd | Content playback apparatus and content playback method |
| JPWO2013018517A1 (en) * | 2011-07-29 | 2015-03-05 | ソニー株式会社 | Streaming distribution apparatus and method, streaming receiving apparatus and method, streaming system, program, and recording medium |
| WO2013018517A1 (en) * | 2011-07-29 | 2013-02-07 | ソニー株式会社 | Streaming distribution device and method, streaming receiving device and method, streaming system, program, and recording medium |
| US9113178B2 (en) | 2011-07-29 | 2015-08-18 | Sony Corporation | Streaming distributing device and method, streaming receiving device and method, streaming system, program, and recording medium |
| US9357275B2 (en) | 2011-09-06 | 2016-05-31 | Qualcomm Incorporated | Network streaming of coded video data |
| JP2014529258A (en) * | 2011-09-06 | 2014-10-30 | クアルコム，インコーポレイテッド | Network streaming of encoded video data |
| JP2017022715A (en) * | 2011-09-06 | 2017-01-26 | クアルコム，インコーポレイテッド | Network streaming of coded video data |
| US9900363B2 (en) | 2011-09-06 | 2018-02-20 | Qualcomm Incorporated | Network streaming of coded video data |
| JP2014116805A (en) * | 2012-12-10 | 2014-06-26 | Canon Inc | Imaging device, information processing device, control method therefor, and video processing system |
| US9544529B2 (en) | 2012-12-10 | 2017-01-10 | Canon Kabushiki Kaisha | Information processing apparatus, image capturing apparatus, and control methods for the same |
| US10701417B2 (en) | 2016-05-24 | 2020-06-30 | Divx, Llc | Systems and methods for providing audio content during trick-play playback |
| JP2019517219A (en) * | 2016-05-24 | 2019-06-20 | ディビックス， エルエルシー | System and method for providing audio content during trick play playback |
| US11044502B2 (en) | 2016-05-24 | 2021-06-22 | Divx, Llc | Systems and methods for providing audio content during trick-play playback |
| US11546643B2 (en) | 2016-05-24 | 2023-01-03 | Divx, Llc | Systems and methods for providing audio content during trick-play playback |
| JP2021508428A (en) * | 2018-05-29 | 2021-03-04 | 北京字節跳動網絡技術有限公司Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ． | Media file playback methods, devices and storage media based on web pages |
| US11178452B2 (en) | 2018-05-29 | 2021-11-16 | Beijing Bytedance Network Technology Co., Ltd. | Playing method, device and storage medium of webpage-based media file |
| JP7072668B2 (en) | 2018-05-29 | 2022-05-20 | 北京字節跳動網絡技術有限公司 | Media file playback methods, devices and storage media based on web pages |
| US11178205B2 (en) | 2020-01-20 | 2021-11-16 | Ideaforge Technology Pvt. Ltd. | System and method for providing live streaming of video data in a low-bandwidth network |
| CN113709412A (en) * | 2020-05-21 | 2021-11-26 | 中国电信股份有限公司 | Live stream processing method, device and system and computer readable storage medium |
| CN113709412B (en) * | 2020-05-21 | 2023-05-19 | 中国电信股份有限公司 | Live stream processing method, device and system and computer readable storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11470405B2 (en) | Network video streaming with trick play based on separate trick play files | |
| RU2652099C2 (en) | Transmission device, transmission method, reception device and reception method | |
| AU2016219369B2 (en) | Low latency video streaming | |
| EP3363181B1 (en) | Deadline signaling for streaming of media data | |
| US8938767B2 (en) | Streaming encoded video data | |
| US9247317B2 (en) | Content streaming with client device trick play index | |
| CN110099288B (en) | Method and device for sending media data | |
| KR101575740B1 (en) | Switch signaling methods providing improved switching between representations for adaptive http streaming | |
| US9185439B2 (en) | Signaling data for multiplexing video components | |
| US8301725B2 (en) | Variant streams for real-time or near real-time streaming | |
| US20200112753A1 (en) | Service description for streaming media data | |
| US20130013803A1 (en) | Method for recovering content streamed into chunk | |
| WO2014193996A2 (en) | Network video streaming with trick play based on separate trick play files | |
| US11765444B2 (en) | Streaming media data including an addressable resource index track | |
| JP2005086362A (en) | Data multiplexing method, data transmitting method and data receiving method | |
| US20190243881A1 (en) | Processing dynamic web content of an iso bmff web resource track | |
| EP1274248A1 (en) | Data reproduction apparatus and data reproduction method | |
| JP4526294B2 (en) | STREAM DATA TRANSMITTING DEVICE, RECEIVING DEVICE, RECORDING MEDIUM CONTAINING PROGRAM, AND SYSTEM | |
| KR101452269B1 (en) | Content Virtual Segmentation Method, and Method and System for Providing Streaming Service Using the Same | |
| JP2008016894A (en) | Transmission apparatus and receiving apparatus | |
| KR20110117568A (en) | Method and apparatus for transmitting/receiving service discovery information in a multimedia transmission system | |
| JP2004312713A (en) | Data transmitting apparatus | |
| KR20200018890A (en) | Wireless streaming method | |
| JP2004056774A (en) | Stream distribution system, stream server device, cache server device, and stream recording and reproducing apparatus, method and program | |
| KR20030042486A (en) | Multimedia contents download service method |