WO2004086765A1 - データ送信装置 - Google Patents

データ送信装置 Download PDF

Info

Publication number
WO2004086765A1
WO2004086765A1 PCT/JP2004/004018 JP2004004018W WO2004086765A1 WO 2004086765 A1 WO2004086765 A1 WO 2004086765A1 JP 2004004018 W JP2004004018 W JP 2004004018W WO 2004086765 A1 WO2004086765 A1 WO 2004086765A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
information
content
file
content data
Prior art date
Application number
PCT/JP2004/004018
Other languages
English (en)
French (fr)
Inventor
Tadamasa Toma
Yoshinori Matsui
Original Assignee
Matsushita Electric Industrial Co. Ltd.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co. Ltd. filed Critical Matsushita Electric Industrial Co. Ltd.
Priority to US10/534,546 priority Critical patent/US20060059245A1/en
Priority to EP04722977A priority patent/EP1566966A4/en
Publication of WO2004086765A1 publication Critical patent/WO2004086765A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2368—Multiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H04N21/6543—Transmission by server directed to the client for forcing some client operations, e.g. recording
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17336—Handling of requests in head-ends
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/101—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management

Definitions

  • the present invention relates to a data transmission device that converts digital content data, such as moving images, sounds, and text, into buckets and transmits the buckets.
  • digital content data such as moving images, sounds, and text
  • TS 26.23 4 Transparent end-to-end packet sw ⁇ tched
  • 3GPP Third Generation Partnership Project
  • Streaming service is expected to expand the distribution of video services even at the end of 3 mobile phones, as determined.
  • MP4 has been standardized as a multiplexed file format for this purpose.
  • MP4 is ISO / IEC JTC1 / SC29 / W6 11 (International
  • One of the above two types of video distribution services is a method called the download type that directly sends and receives MP4 files.
  • this method is the mainstream for video distribution on wireless terminals.
  • this video distribution service has drawbacks that it is not suitable for long-time content distribution with a large file size, and that special playback such as fast forward cannot be performed.
  • the other of the above two types of video distribution services is a method called streaming.
  • the service on the wireless terminal will be started as a method to solve the problem of the download type.
  • the MP4 file used in the streaming type stores media data multiplexed in the download type MP4 file and information called hint data for bucketing the media data.
  • a streaming type video distribution service the MP4 file itself is not distributed, but the server refers to the hint data to packetize the media data, and the bucketed media data is transmitted to the terminal. It is distributed to.
  • the framework of the hint data is disclosed by Apple Inc. in Japanese Patent Laid-Open No. 2001-197210.
  • streaming-type video distribution services are suitable for long-term content distribution because media data (content data) is packetized and distributed.
  • this video distribution service is suitable for special playback such as fast-forwarding and jump-in playback, because the server can select and distribute data at any time of the content.
  • the streaming type video distribution service using MP4 files is described in detail below.
  • the header and media data are stored in an object called BOX.
  • FIG. 1 is a diagram for explaining the structure of Box. Box, siz It contains an e-field, a type field, a version field, a fIags field, and a data field.
  • the size of the entire Box including the size field is stored in the size field.
  • the t y p e field stores the B o X identifier (usually four letters).
  • the field length is 4 bytes.
  • the search for BOX in the MP4 file is performed by determining whether or not it matches the identifier of the data force type field for four consecutive bytes.
  • the version number of Box is stored in the v ersion field.
  • the fIags field stores flag information set for each BOX.
  • the data field stores header information and media data. Note that the version field and the fIags field are not required, so these fields do not exist depending on BOX.
  • the identifier of the type field will be used to refer to BoX. For example, Box whose identifier is 'moov' will be referred to as moov.
  • FIG. 2 is a data configuration diagram showing the structure of the MP4 file.
  • the MP4 file is composed of three Boxes, ftyp, mov, and mdat, and ftyp is placed at the beginning of the file.
  • ftyp contains information for identifying the MP4 file.
  • m d at stores media data and hint data.
  • the hint data is information necessary for transmitting media data in the form of RTP (Real Time Transmission Protocol) packets.
  • the server refers to the hint data and converts the media data into RTP packets for distribution.
  • Each media and hint data included in m dat is called a track, and each track is identified by a track ID.
  • MP4 data is handled in units called samples.
  • a media track one or more frames of video or audio correspond to a sample, and in a hint track, a sample corresponds to the information for creating one or more RTP packets.
  • header information about the sample included in each track of mdat is stored.
  • the use of moV in the MP4 file is mandatory, and the number is one.
  • BOX is hierarchically arranged in mov, and header information common to the entire file is stored in mvhd.
  • audio, video, and hint track header information associated with each media track are stored in their respective traks.
  • the track ID which is the track identification information, is indicated by tkhd in trak.
  • trak is configured as shown in (c) of FIG. 2, and information such as sample size / decoding time and display start time is stored in each Box in stbI.
  • SttS stores the decoding time of the sample. That is, the difference value of the decoding time between two consecutive samples is stored in SttS. Therefore, the decoding time of each sample can be obtained by adding the difference values. Further, when the decoding time and the display time are different, Box called ctts which stores the difference between the decoding time and the display time is used. For example, since the decoding time and the display time are different for frames encoded using bidirectional prediction, c t t
  • stss When playback is started (random access) from the middle of a track, information indicating samples from which decoding can be started is required.
  • stss is used as BoX, and a list of randomly accessible samples (hereinafter referred to as sink samples) is stored in stss. If stss does not exist, all samples in the track are random Indicates that access is possible.
  • sink samples a list of randomly accessible samples
  • FIG. 3 is a diagram for explaining how to use the hint data.
  • the server refers to the trak for the video hint track and obtains a sync sample that stores the RTP packetization information for the sample of the video track whose display time matches or is close to T. .
  • the sync sample is specified by referring to Stts and Stss, and acquiring the display time.
  • the acquired sync samples store the information needed to create one or more RTP buckets.
  • the display time of the sync sample indicates the display time of the sample of the video track whose transmission is started by the first RTP packet.
  • the sync samples indicate which part of the video track each bucket transmits data by the sample number of the video track and the byte position within the sample. For example, the Rth RTP packet transmits from the Lth byte of the ⁇ ⁇ ⁇ ⁇ th sample to the ⁇ th byte of the ⁇ ⁇ ⁇ ⁇ th sample.
  • the server refers to the trak for the video track, and obtains the Kth power and the storage positions of the samples from the ⁇ th to the ⁇ th.
  • the server obtains data from the second byte of the ⁇ ⁇ ⁇ ⁇ th sample to the ⁇ th byte of the ⁇ ⁇ ⁇ ⁇ th sample based on the storage position obtained in (2).
  • the server sets the other information necessary for R- ⁇ packetization in the obtained data and creates an R- ⁇ packet.
  • FIG. 7 is a diagram for explaining a procedure distributed as a TP packet.
  • the MP4 file is stored in the storage device, and the playback control between the server and the terminal uses RTSP (Real Time Transmission Protocol).
  • RTSP Real Time Transmission Protocol
  • the storage device may be inside the server or outside the server.
  • the terminal requests the server to transmit content data (news, mp4) using RTSP.
  • the server checks whether news, mp4 is available, and accesses ⁇ ws, mp4 when available.
  • the server analyzes the hint track of news, mp4, acquires content data to be transmitted to the terminal, and creates an RTP bucket from the content data.
  • the server sends the RTP packet storing the content data to the terminal.
  • FIG. 5 is a diagram showing an example of an RTSP message exchanged in reproduction control between a server and a terminal.
  • G_> S indicates a message from the terminal to the server
  • S—> C indicates a message from the server to the terminal.
  • the terminal requests the content data of news.mp4 from the server by using the DESCRIBE instruction.
  • the server responds that news.mp4 is available, and sends an SDP (Session Description Protocol) (and hence news.mp4 (information about access to news.mp4, etc.))
  • SDP Session Description Protocol
  • part of the contents of the SDP is stored in a box called udta immediately below the hint track trak and moov of the MP4 file.
  • the terminal sets parameters for transmission to the server.
  • the server notifies the terminal of the transmission parameters.
  • the transmission path between the server and the terminal is established and initialized.
  • the terminal issues a PLAY instruction to the server, and requests the start of transmission of the content data of news, mp4.
  • the server In response to the PLAY command, the server returns a message to start transmission, and then transmission of the RTP packet starts.
  • the server may issue a response to the PLAY command after starting transmission of the RTP packet.
  • audio and video media data (content data) is transmitted by an RTP bucket having a different identifier for each medium.
  • the identifier includes the SSR C included in the header of the RTP packet.
  • the RTP bucket may identify the media data transmitted by the RTP packet based on the port number.
  • the data transmitted by the RTP bucket can be identified by the same method.
  • (7) to (10) in FIG. 5 show the procedure when random access is performed.
  • the messages listed in (7) to (10) show the contents when the terminal user skips to the 30th second while viewing the 10th second of the content data.
  • the terminal requests the server to stop transmitting data.
  • the server stops sending data.
  • the terminal requests the data from the 30th second of news.mp4 by issuing the PLAY command.
  • the server sends a message to the effect that it sends from 30 seconds to the end (60 seconds) in response to the PLAY command. After this, the content data from the 30th second is transmitted to the terminal.
  • the terminal prompts the server to terminate the communication.
  • the server performs a communication termination procedure.
  • FIG. 6 is a block diagram showing the configuration of a conventional data transmission device (server).
  • the data transmission device includes a file analysis unit 801, an RTP creation unit 802, an RTP transmission unit 803, and an RTSP processing unit 804.
  • the processing unit 8004 transmits the transmission message d806 to the data receiving device (terminal), and receives the reception message d807 from the data receiving device, so that the data receiving device Playback control using RTSP is performed between this and.
  • the RTSP processing unit 804 analyzes the received message d807 and converts the RTSP request data d808 including the file name, storage location, and display time position of the transmission request of the MP4 file. Output to the file analyzer 8001.
  • the file analysis unit 8001 acquires the MP4 file d801 shown in the RTSP request data d808 from a storage device (not shown). Next, the file analysis unit 801 acquires a sample corresponding to the display time position requested for transmission by analyzing the hint track. The file analysis unit 8001 outputs the obtained sample to the RTP creation unit 802 as bucket creation data d802 together with information necessary for creating an RTP bucket header. Further, the file analysis unit 8001 displays the display time information of the media data contained in the SDP or the first RTP packet at the start of transmission. And outputs RTSP transmission information d 805 to the RTSP processing unit 804.
  • the RTP creation unit 802 acquires the bucket creation data d 802 from the file analysis unit 801, and also obtains the bucket header information d 809, which is the header information of the RTP packet, from a device (not shown). get. Then, the RTP creation unit 8002 creates an RTP bucket d803 based on the packet creation data d802 and the packet header information d809, and generates an RTP packet.
  • the RTP sending section 803 acquires the RTP packet data d 803 output from the RTP creating section 802 and sends it to the data receiving device (terminal) as an RTP bucket d 804. Send.
  • FIG. 7 is a flowchart showing the operation of the file analysis unit 801 of the data transmission device.
  • the data transmission device converts the data of the video track into RTP packets from the data of the portion where the display time is T, and transmits the data.
  • the file analyzer 801 acquires data of the specified sync sample with reference to the other Boxes in stbI (step S803).
  • the file analysis unit 801 analyzes the trak of the track whose track ID is 1, and obtains the data of the sample specified as the target of the RTP bucket in step S804. (Step S805) If there is a sample of the hint track after the sync sample identified in step S802, the file analysis unit 8001 obtains the sample, and obtains the sample. The same operation as in steps S804 and S805 is performed based on.
  • the data receiving apparatus obtains the RTP packet d804 (encoded data) output from the above-described data transmitting apparatus, and stores the encoded data in a memory called a buffer while encoding the data in the memory. Decrypt the data.
  • a model called a buffer model is specified.
  • This buffer model is designed so that when a coded data flows at a predetermined rate, if a buffer of a predetermined size is prepared, the buffer becomes empty (underflow). Or guarantee that decryption can be performed without overflow.
  • the buffer model is defined for each encoding method such as MPEG-4 AVC (Advanced Video Godging) and MPEG-4 (Moving Picture Expert Group Visual), and the encoded data follows this buffer model. Encoded.
  • FIG. 8 is a diagram showing the relationship between the elapsed time from the start of the inflow of encoded data (horizontal axis) and the occupancy of the buffer of the data receiving device (vertical axis).
  • the buffer occupancy is the amount of encoded data that exists in the buffer at a certain time. For example, as shown in FIG. 8, encoded data flows into a buffer by a bit train having a slope R.
  • the data receiving apparatus starts decoding processing for picture P 1 at time t 1, and decodes subsequent pictures at times t 2, t 3,..., Respectively. That is, at the decoding time (t 1, t 2,...) Of each picture, data corresponding to the picture to be decoded is extracted from the buffer. For example, when the data of the picture to be decoded is extracted from the buffer at time t2, the buffer occupancy is reduced by the data amount Ps2 of the picture to be decoded.
  • the pre-buffering time is t 1. If the data receiving device starts decoding based on the buffer model and observes the pre-buffering time specified at the time of encoding, the buffer occupancy will be the buffer specified by the video encoding standard (such as MPEG-4). Decoding the encoded data without exceeding the size and in a state where the data of the decoding target picture is completely prepared at the decoding time of the picture. Can continue. In other words, as shown in Fig. 8, the buffer occupancy is always kept between zero and the buffer size.
  • the data receiving device decodes the data from the picture (the fifth picture P5) in the middle of the encoded data.
  • the buffer occupancy must be set to the offset os5 after the data of picture P5 is extracted from the buffer.
  • the buffer occupancy becomes smaller than the offset os 5 after the data of the picture P 5 is extracted. There is.
  • FIG. 9 is a diagram showing a temporal change of the buffer occupancy that varies depending on the pre-buffering time.
  • the data receiving apparatus sets the picture occupancy of the picture P6 to the offset os5. Subsequent pictures can also be decoded normally at the decoding time.
  • the data receiving apparatus when the decoding of picture P5 starts after the elapse of pre-buffering time da, the data receiving apparatus has a buffer occupancy of zero. At the decoding time, the data of picture P6 is not complete, and picture P6 cannot be decoded. For this reason, the data receiving apparatus stops the redisplay in which the decoding operation is stopped until the data of the picture P6 is completed.
  • the appropriate pre-buffering time for preventing the buffer overflow and underflow differs depending on the picture to be decoded. Since the data receiving apparatus cannot obtain information necessary for appropriate playback such as an appropriate pre-buffering time for each picture, the data receiving apparatus stops displaying the picture during playback or waits until decoding starts. The waiting time becomes longer than necessary.
  • the present invention has been made in view of such a problem, and an object of the present invention is to provide a data transmission device that causes a data reception device to execute appropriate reproduction processing of content data. Disclosure of the invention
  • a data transmission device for extracting digital work content data from a file and transmitting the content data to a reception device, wherein the file is the content data. And the reproduction control information used for the reproduction processing of the content data.
  • the data transmission device is configured to establish and initialize a transmission path for the content data with the reception device.
  • a bucket generating means for acquiring at least a part of the content data from the file and converting it into a bucket; and the bucket generating means.
  • Content transmission means for transmitting at least a part of the bucketed content data.
  • the reproduction control information is retrieved from the file and transmitted to the receiving apparatus.
  • the content sent from the content sending means Upon receiving the content data and the reproduction control information transmitted from the control transmitting means, the content data can be appropriately reproduced using the reproduction control information.
  • the reproduction control information multiplexed in the file is configured in a table including, for each of a plurality of data units included in the content data, reproduction control unit information used for reproduction from the data unit,
  • the control transmitting unit retrieves the reproduction control unit information related to a data unit in response to a request from the receiving device from the reproduction control information of the file and transmits the retrieved control unit information.
  • the content data may be obtained from a data unit in response to a request from the receiving device and may be bucketed.
  • the content data from the data unit according to the request from the receiving device is converted into a bucket and transmitted, and the reproduction control unit information competing with the data unit is also transmitted from the control transmission unit. Therefore, the receiving device can appropriately reproduce a part of the content data requested by itself from the first data unit included in the part using the reproduction control unit information.
  • the reproduction control unit information indicates contents for notifying a timing to start a decoding process to content data transmitted from the content transmitting unit and received by the receiving device. Is also good.
  • the playback control unit information indicates the time from the start of reception of the content data by the receiving device to the start of the decoding process as the content for notifying the timing.
  • the reproduction control unit information indicates a data amount of the content data accumulated by the receiving device as content for notifying the timing.
  • the receiving device can use the playback control unit information to know when to start decoding processing for the content data stored in the buffer, and to prevent buffer overblowing and underflow. It is possible to prevent the occurrence and appropriately perform the reproduction processing of the stored content data. Also, when the playback control unit information indicates time, the receiving device can know the above timing by measuring the time from the start of reception, and when the playback control unit information indicates the data amount, The receiving device can know the above timing based on the amount of data stored in the buffer.
  • control transmitting means converts the data amount indicated by the reproduction control unit information into a time from the start of reception of the content data by the receiving device to the start of the decoding process, and It may be characterized by transmitting unit information.
  • control transmission unit converts the reproduction control unit information in accordance with a transmission state of the content data in the content transmission unit.
  • the amount of data indicated by the reproduction control unit information is converted into time and notified to the receiving device. You can know the mining. Further, when the above conversion is performed in accordance with the transmission state of the content data, it is possible to notify the receiving device of an appropriate time that is not affected by the transmission state. For example, when the transmission speed of the content data decreases, it is possible to convert the transmission time to be longer and to notify the receiving device of an appropriate time.
  • the content transmitting means may change a transmission speed of the content data based on a state of a transmission path.
  • the content data is moving image data including a plurality of images
  • the reproduction control unit information indicates whether a correct decoding process result can be obtained from the first image of the data unit. It may be featured to show.
  • the content data is moving image data configured to include a plurality of images, and the reproduction control unit information is initially correct when decoding processing is started from the first image of the data unit. It may be characterized by indicating a part where the decoding result is obtained.
  • the content data is moving image data including, as the data unit, a scene composed of a plurality of continuous images, and the reproduction control information decodes an image constituting each of the scenes. It may be characterized by indicating information required for initialization at the time of initialization.
  • the data transmitting apparatus transmits reproduction control unit information associated with each scene together with the scenes.
  • the receiving device can appropriately initialize each scene using the playback control unit information and display each image.
  • the content data is moving image data including a plurality of images
  • the reproduction control information indicates a period of a randomly accessible image of the plurality of images. It may be.
  • the receiving device that has received the reproduction control information can specify the parts of the content data that can be randomly accessed based on the reproduction control information, and the receiving device can appropriately perform the reproduction process from those parts. it can.
  • the present invention can also be realized as a data transmission method or a program for transmitting content data by the data transmission device, and a storage medium for storing the program.
  • FIG. 1 is a diagram for explaining the structure of BOX of an MP4 file.
  • FIG. 2 is a data configuration diagram showing the structure of the MP4 file.
  • FIG. 3 is a diagram for explaining how to use the hint data.
  • FIG 4 shows that the media data (content data) is sent from the server to the terminal.
  • FIG. 9 is a diagram for explaining a procedure distributed as a TP bucket.
  • FIG. 5 is a diagram showing an example of an RTSP message exchanged in reproduction control between a server and a terminal.
  • Fig. 6 is a block diagram showing the configuration of a conventional data transmission device (server).
  • FIG. 7 is a flowchart showing the operation of the file analysis unit of the data transmission device of the above.
  • FIG. 8 is a diagram showing the relationship between the elapsed time from the start of the inflow of encoded data (horizontal axis) and the occupancy of the buffer of the data receiving device (vertical axis).
  • FIG. 9 is a diagram showing a temporal change of the buffer occupancy that varies depending on the pre-buffering time.
  • FIG. 10 is a block diagram showing a configuration of the data transmitting apparatus according to Embodiment 1 of the present invention.
  • FIG. 11 is a data content display diagram showing an example of the content of the pre-buffering information stored in st sp.
  • Figure 12 shows the contents of the pre-buffering information stored in stsp. It is a data content display figure which shows the example of (a).
  • FIG. 13 is a flowchart showing the operation of the file analysis unit of the data transmission device.
  • FIG. 14 is a flowchart showing the detailed operation of the pre-buffering information acquisition process (step S105 in FIG. 13).
  • FIG. 15 is a diagram showing an example of an RTSP message exchanged between the data transmitting device and the data receiving device.
  • FIG. 16 is a block diagram showing a configuration of the data receiving apparatus according to Embodiment 2 of the present invention.
  • FIG. 17 is a flowchart showing the operation of the instruction unit of the data transmission device of the above.
  • FIG. 18 is a diagram showing the data transmission device and the data reception
  • FIG. 11 is an explanatory diagram of a storage medium that stores a program for realizing the device by a computer system.
  • FIG. 10 is a block diagram showing a configuration of the data transmitting apparatus according to Embodiment 1 of the present invention.
  • the data transmitting apparatus 100 retrieves information (reproduction control information) necessary for appropriate reproduction, such as pre-buffering time, from the MP4 file and transmits it to the data receiving apparatus. By doing so, the data receiving device can execute an appropriate reproduction process.
  • MP4 files used in this embodiment may be audio, video, or text
  • the media data and the hint data are multiplexed, and the reproduction control information is multiplexed in the header of the hint data.
  • the MP4 file used in the present embodiment indicates video data encoded by an encoding method such as MPEG-4 AVC, MPEG-4 Visua I, or H.263.
  • Such a data transmission device 100 includes a file analysis unit 110, an RTSP processing unit 101, an RTP creation unit 102, an RTP transmission unit 103, and a file creation unit 104. Is provided.
  • the file creation unit 104 acquires the stream of the content data, creates an MP4 file, and stores the MP4 file in the storage device.
  • the RTSP processing unit 101 transmits a transmission message d107 to the data receiving device, and receives a reception message d108 from the data receiving device to establish a communication with the data receiving device. Performs playback control using RTSP.
  • the transmission message d107 includes at least one of the RTSP transmission information d105 and the reproduction parameter information d110 obtained from the file analysis unit 110.
  • the RTSP processing unit 101 analyzes the received message d108 and obtains the RTSP request data d1 including the file name of the MP4 file, the storage location, and the display time position requested for transmission. 0 1 is output to the file analysis unit 110.
  • the file analysis unit 110 analyzes the MP4 file and creates data necessary for creating an RTP bucket and data necessary for RTSP communication.
  • An acquisition unit 111, a reproduction analysis unit 113, and a conversion unit 114 are provided.
  • the RTP analysis unit 112 acquires the RTSP request data d 101 via the information acquisition unit 111 and analyzes the hint track of the MP4 file to obtain the RTSP request data dl 0.
  • the RTP analysis unit 112 outputs the acquired sample data d102 to the information acquisition unit 111, and includes the sample number of the sample at the head of the sample data d102.
  • the sample number information d 103 is output to the reproduction analyzer 113.
  • the sample number is a number for identifying a sample. For example, for each sample of the track, sample numbers 1, 2, 3, ... are assigned in order from the first sample.
  • the sample number information d103 may include the track ID of the hint track / media track.
  • the information acquisition unit 111 acquires sample data d102 from the RTP analysis unit 112.
  • the information acquisition unit 111 converts the acquired sample data d 102 and information necessary for creating an RTP packet header into packet creation data d 104 as an RTP creation unit 110. Output to 2. Further, based on the sample data d102, the information acquiring unit 111 displays the display time information of the media data included at the beginning at the start of transmission of the sequence number, time stamp, SDP, or RTP packet, It creates RTSP transmission information d105 including such information and outputs it to the RTSP processing unit 101.
  • the reproduction analysis unit 113 acquires the sample number information d103 from the RTP analysis unit 112.
  • the reproduction analysis unit 113 acquires the reproduction control information d109 regarding each sample after the sample of the sample number indicated by the acquired sample number information d103 from the hint track of the MP4 file. Then, the reproduction analysis unit 113 outputs the obtained reproduction control information d109 to the conversion unit 114.
  • the reproduction control information d109 is information for appropriately performing reproduction processing from the sample having the sample number indicated by the sample number information d103 on the data receiving device side.
  • the reproduction control information d109 is used as a pre-buffer for performing appropriate pre-buffering so that overflow or underflow does not occur in the buffer of the data receiving apparatus. This is the ringing information.
  • the conversion unit 114 converts the playback control information d 109 acquired from the playback analysis unit 113 into RTSP parameters to generate playback parameter information d 110, which is then converted to the RTSP processing unit 110. Output to 1.
  • the RTP creation unit 102 acquires the packet creation data d104 from the file analysis unit 110, and the packet header information d111 as the header information of the RTP bucket. To get from. Note that the packet header information d111 includes an initial value of the sequence number and the like. Then, the RTP creating unit 102 creates the RTP packet d112 based on the bucket creating data d104 and the packet header information d111.
  • the RTP sending unit 103 sends the RTP packet d112 created by the RTP creating unit 102 to the data receiving device.
  • Such a data transmitting apparatus 100 of the present embodiment for example, when the data receiving apparatus requests to transmit data from the middle of video, refers to the St SS for the hint track. I do. And the data transmission device
  • the data transmitting device 100 specifies the most appropriate sample for the data receiving device request from the sync samples of the hint track, and based on the samples after the specified sample, the RTP bucket of the video data is determined. Generate and send.
  • data RTP packet
  • the data transmitting device 100 sets the display time equal to T, or the hint closest to T before T. Identify the track sync sample. Note that the data transmitting apparatus 100 may specify a sync sample whose display time is after T and is closest to ⁇ .
  • the data transmitting apparatus 100 is capable of generating one or more RTP buckets based on a hint track sync sample. Then, the reproduction parameter information d 110 for the sample of the video track transmitted first by the first RTP bucket is transmitted to the data receiving device as a transmission message d 107. The data receiving device that has received the RTP packet from the data transmitting device 100 transmits the received RTP packet based on the reproduction parameter information d110 (reproduction control information d109). Therefore, it is possible to perform appropriate reproduction for
  • the MP4 file includes prebuffering information as playback control information.
  • the reproduction control information is information for allowing the data receiving device to appropriately perform reproduction processing from each sample.
  • the pre-buffering information is information for pre-buffering from each sample to be performed properly.
  • the pre-buffering information includes the time required for pre-buffering from the start of reception to the start of decoding (necessary pre-buffering time) and the pre-buffer from the start of reception to the start of decoding, according to each sample (picture). Indicates the data amount required for ringing (data amount required for pre-buffering).
  • FIG. 11 is a data content display diagram showing an example of the content of the pre-buffering information stored in stsp.
  • the prebuffering information D109 corresponds to the sample number of the sync sample of the hint track (sync sample number) and the sync sample of the sample number.
  • Prebuffering Includes required data amount.
  • the amount of data required for pre-buffering is calculated from the start of reception to the start of decoding when the data receiver starts receiving data from an RTP bucket created based on the corresponding sync sample. Indicates the amount of data that needs to be stored in the buffer of the data receiving device.
  • the data receiving device when the data receiving device starts receiving data from an RTP packet d112 created based on the sync sample of sample number 1, the data receiving device transmits the RTP packet d112 up to 1500000 bytes. Start decoding after receiving.
  • the required amount of pre-buffering is determined by the amount of encoded video or audio data contained in the bucket. It may be an amount.
  • FIG. 11 is a diagram illustrating an example of the syntax of st sp storing the pre-buffering information D 109 as described above.
  • sync sample —number indicates the sample number of the sync sample
  • prebuf data_byte indicates the amount of data required for pre-buffering.
  • FIG. 12 is a data content display diagram showing another example of the content of the pre-buffering information stored in stsp.
  • the prebuffering information D109 includes a sample number (sync sample number) of the sync sample of the hint track and a prebuffer buffer corresponding to the sync sample of the sample number. Including required time.
  • FIG. 12 shows the pre-buffering information D109 as described above.
  • FIG. 11 is a diagram illustrating an example of syntax of stsp to be stored.
  • sync sample—number indicates the sample number of the sync sample
  • prebuf period indicates the required pre-buffering time.
  • the pre-buffering information of the sync sample may be stored in the MP4 file by another method.
  • the pre-buffering information is placed in the b ⁇ st in stb I in the same way as the index number of the sample entry referenced by the sample is indicated using the Samp Ie to Chunk Box ('stsc').
  • the data is stored as an entry of the table data to be stored, and the sink sample is associated with the index number of the entry.
  • FIG. 13 is a flowchart showing the operation of the file analysis unit 110 of the data transmitting apparatus 100.
  • the reproduction control information d109 will be described below as prebuffering information.
  • the data transmitting apparatus 100 converts the data of the video track into an RTP packet from the data of the portion where the display time is T and transmits the data.
  • pre-buffering information may also be used for audio or text data.
  • the data transmitting apparatus 100 may perform the prebuffering information acquisition processing (step S105) before acquiring the sync sample (step S103), and may perform the processing of the video track sample. It may be performed after the acquisition (step S107).
  • FIG. 14 shows the pre-buffering information acquisition process (step S in Fig. 13).
  • FIG. 10 is a flowchart showing a detailed operation of the present embodiment.
  • st sp is represented by the syntax shown in (b) of FIG. 11, and it is assumed that the sample number of the sync sample of the hint track specified in step S 103 of FIG. 13 is N.
  • the file analysis unit 110 sets a pointer for reading data at the head of the entry-count field of stsp, and sets a count value to 0 (step S201).
  • the file analysis unit 110 obtains the number of entries M included in stsp (step S202), and advances the pointer by 4 bytes (step S203).
  • the file analysis unit 110 adds 1 to the count value (step S204), and obtains a sample number (sync—number) of the sync sample (step S205).
  • the file analysis unit 110 further advances the pointer by four bytes (step S206).
  • the file analysis unit 110 determines whether or not the sample number (sync_number) of the sync sample obtained in step S105 is equal to N (step S207). If it is equal to N (Yes in step S207), the file analysis unit 110 acquires prebuffering information d109 corresponding to the sync sample whose sample number is N ( Step S208). If they are not equal (No in step S207), the file analysis unit 110 determines whether the count value is smaller than the number of entries M (step S207). 9). Here, if the count value is smaller than the number of entries M (Yes in step S209), the file analysis unit 110 performs the processing in steps S204 to S207. Execute repeatedly.
  • the file analysis unit 110 sends the pre-buffer corresponding to the sync sample of sample number N to the pre-buffer. Ring information d109 cannot be obtained, and a preset default value is obtained, and the default value is used as prebuffer ring information d109 (step S21) 0).
  • FIG. 15 is a diagram illustrating an example of an RTSP message exchanged between the data transmitting apparatus 100 and the data receiving apparatus according to the present embodiment.
  • the data transmitting apparatus 100 establishes and initializes a transmission path with the data receiving apparatus, and then reproduces the pre-buffering information d109. It is converted to parameter information d111 and transmitted to the data receiving device as a response to the PLAY command of RTSP.
  • the data transmitting apparatus 100 transmits pre-buffering information d 109 indicating the required pre-buffering time to X-in ⁇ defined by the 3GPP TS 26.234 standard. It is converted into reproduction parameter information d 110 such as prebuf per iod, and the reproduction parameter information d 110 is included in the transmission message d 107 and transmitted.
  • the reproduction parameter information d110 transmitted in (6) of Fig. 15 will be specifically described.
  • the pre-buffering information d corresponding to the sync sample of sample number 300
  • the data transmission device 1000 obtains the data amount required for pre-buffering 900 0 J as 109.
  • the transmission rate of the RTP packet is 6400 bps and the time is If the scale is 9000, the obtained pre-buffering information d109 is converted to 9000 Convert to playback parameter information d1 10 (x-initprebufperiod).
  • the data transmitting apparatus 100 transmitted the reproduction parameter information d 110 (pre-buffering information) in response to the PLAY instruction, but the content (eg, video)
  • the playback parameter information d110 may be stored in the SDP and transmitted.
  • the data transmitting apparatus 100 transmits the reproduction parameter information d 110 not as a response to the PLAY instruction but as a response to another instruction in the RTSP standard or a newly created instruction. You can do it.
  • the default value is set as a pre-buffering required data amount. For example, it indicates the data amount corresponding to two thirds of the buffer size.
  • the buffer size specified by the standard is three minutes. It is stipulated that decoding should be started after pre-buffering encoded video data of data amount equivalent to ing. Therefore, the data transmitting apparatus 100 uses a data amount corresponding to two thirds of the buffer size as a default value.
  • the data transmitting apparatus 100 converts the pre-buffering information d 109 into reproduction parameter information d 110 and transmits it to the data receiving apparatus. Can determine an appropriate decoding start time of the RTP bucket based on the converted pre-buffering information d109. As a result, the data receiving apparatus can, for example, continuously reproduce the video data transmitted from the data transmitting apparatus 100 by RTP.
  • SEI Supplemental Enhancement Information
  • SE ⁇ Supplemental Enhancement Information
  • SE ⁇ is information that assists in decoding.For example, it can indicate information on pre-buffering required time and random access.
  • Called Buffering period SEI which stores the length of time from when the picture data immediately after Buffering per iod SEI starts flowing into the MPEG-4 AVC decoding buffer until decoding of the picture starts.
  • the file creating unit 104 creates an MP4 file having the above st sp with reference to the Buffering period SEI included in the stream.
  • the Buffering period SEI indicates 1 second as the time length until the decoding of picture N starts, and the rate used as the basis for calculating the time until the decoding starts is 6
  • the case of 400 bps will be described below.
  • the number of RTP buckets necessary to transmit 800 bytes of video data is determined when creating a hinted track of an MP4 file.
  • the file creation unit 104 acquires the picture prebuffering information separately from the stream. Alternatively, the file creating unit 104 calculates pre-buffering information from the size of each picture included in the stream, the decoding time, and the like.
  • the parameters in the VOL (Video Object Layer) of the stream of video data indicate the buffer occupancy just before the VOP (Video Object Plane) data immediately after the VOL is extracted from the buffer. That is, this buffer occupancy indicates the amount of data required for pre-buffering. Therefore, if a VOL is placed before a picture that can be accessed randomly, the file creator 104 determines from the parameters in that VOL the amount of pre-buffering data required for the picture immediately after the VOL (pre-buffer). (Ring information).
  • the data transmitting apparatus 100 according to the present invention has been described using the above embodiment, but the data transmitting apparatus 100 according to the present invention is not limited to these.
  • the prebuffering information indicating the required prebuffering time is included in stsp, but since the transmission rate may change,
  • the transmission rate used as a reference for deriving the pre-buffering required time may be stored in stsp. It may be stored in another location of the MP4 file.
  • the transmission rate in the network is not always constant, and fluctuation occurs. For example, even if the data transmitting device 100 transmits an RTP packet at a transmission rate of 640000 bps, if the network becomes congested, the transmission rate will be 600 000. May drop to 0 bps. In such a situation, if the data receiving device that has received the RTP packet has the required pre-buffering time set to 1 second, the data amount required for pre-buffering is 6400 bits. However, decoding starts when the buffer occupancy reaches 600 bits. Therefore, if the transmission rate is stored in stsp as described above, the data transmitting apparatus 100 needs to transmit the transmission rate to the data receiving apparatus as well, so that the data receiving apparatus needs appropriate pre-buffering. Time can be specified.
  • the field of the sync sample number is provided in st sp, but this field may be omitted.
  • the transmission rate of RTP packets is fixed, but transmission path conditions such as network congestion or the frequency of occurrence of packet loss during transmission of content are considered. If so, the situation The transmission rate of the RTP packet may be positively changed according to the change of the RTP packet.
  • the data transmitting apparatus 100 obtains the required data amount of pre-buffering from the pre-buffering information D109 stored in stsp, and performs pre-buffering according to the transmission rate at the time of transmission. Calculate the required time.
  • the data transmitting apparatus 100 responds to the PLAY command by adding “pre-buffering information d 1 09 indicating the required pre-buffering time 2.0 seconds J” to the reproduction parameter information d 1 1 1. It is converted to 0 and transmitted to the data receiving device.
  • the data receiving device notifies from the data transmitting device 100 Within the pre-buffering time required, only 1 to N—the second RTP bucket may be received. is there. At this time, if the data receiving apparatus starts decoding when the required pre-buffering time has elapsed, the buffer underflow occurs because the N-1 and N-th RTP buckets are insufficient.
  • the data transmitting apparatus 100 receives information for specifying an RTP bucket that needs to be received before decoding starts, for example, a sequence number, as pre-buffering information d109. It may be sent to the device.
  • the header of the RTP packet includes a packet identification number called a sequence number.
  • the sequence number included in the header of the RTP packet is a value obtained by adding 1 to the sequence number included in the header of the immediately preceding RTP packet transmitted from the data transmitting apparatus 100. Therefore, if the first to Nth RTP packets need to be received before the start of decoding, if the sequence numbers of those RTP packets are 1 to N, the data transmitting apparatus 100 will have a pre-buffer buffer. Information indicating the sequence numbers 1 to N is transmitted to the data receiving device as signaling information d109.
  • the prebuffering information D109 is included as playback control information in the hint track (trak for a hint track) of an MP4 file. It may include information indicating the waiting time from the end of decryption to the display, the buffer size required for decrypting a specific section of the content, and information on encryption during transmission.
  • the data transmitting apparatus 100 obtains such reproduction control information from the trak of the MP4 file, converts it into reproduction parameter information d 110, and transmits it to the data receiving apparatus.
  • scene initialization information required for initializing the decoding process of e-data in a scene unit composed of a plurality of continuous images is used to identify a scene such as a scene index number or a sample number of a first sample of the scene. May be included in the MP4 file as playback control information in association with the information for playback.
  • a sequence 'parameter set (Sequence Parameter Set) and a hike-parameter set (Picture Parameter Set) correspond to scene initialization information.
  • the data transmitting device 100 transmits the requested image data of each scene as an RTP bucket.
  • the data receiving device performs appropriate initialization for each scene using the scene initialization information, and decodes each image. Can be displayed.
  • the scene initialization information of the first scene from which reception is started may not be included in the PLAY response because the scene initialization information can be included in the SDP.
  • image cycle information indicating the cycle of a randomly accessible image included in the video data may be included in the MP4 file as playback control information.
  • the data receiving device that has received the image cycle information can specify a randomly accessible portion of the video data based on the image cycle information, and perform appropriate reproduction processing from those portions. .
  • the data receiving device can determine in advance from the specified result whether or not the image at the time position about 30 seconds ahead can be randomly accessed. In this way, it is possible to prevent sudden access to the image at the time position 5 minutes ahead.
  • pre-buffering information d 109 (reproduction parameter information d 110) is transmitted to the data receiving device using R-SP, but transmission is performed using a protocol other than RTSP. You may.
  • prebuffering information D109 corresponding to video is stored in stsp, but prebuffering information corresponding to content (media) other than video, such as audio and text, is stored. Information may be stored.
  • stsp is used to multiplex the prebuffering information D109 into an MP4 file.
  • this stsp is used for transmission other than RTP such as MPEG-2 TS (Transport Stream). Also used when multiplexing information for creating a packet into an MP4 file in the format.
  • pre-buffering information for the sync sample indicated by st s s is stored in st sp, but pre-buffering information for other samples may also be stored.
  • samples storing I-pictures other than sync samples, or pre-buffering information for all samples may be stored in stsp.
  • Pre-buffering for samples storing I-pictures with Recovery Point SEI added Ring information may be stored in stsp.
  • playback control information such as pre-buffering information may be stored in the header information of the video track.
  • pre-buffering information about the sync sample of the video track can be included in the Box.
  • the video referenced from the hint track sync sample Since the sample of the video track is a sync sample or a sample that can be accessed randomly other than the sync sample, the pre-buffering information on the video track sample is stored in the header information of the video track.
  • the pre-buffering information for the sample including the Recovery Point SEI may be stored in the header information.
  • An IDR picture is a picture in which the pictures after the IDR picture in decoding order can be decoded without referring to the pictures before the IDR picture in decoding order, and are the same as the first I picture of c-osed GOP in MPEG-2. It has the following characteristics. In MPEG-4AVC, there are pictures that can be accessed randomly in addition to IDR pictures, and these pictures are identified by the above-mentioned Recovery Point SEI.
  • the Recovery Point SEI is information that indicates how many pictures should be decoded to obtain a picture of the same quality as the original image when decoding starts from the picture immediately after this SEI, or a broken link. Contains identification information.
  • the I picture to which the Recovery Point SEI is added has the same characteristics as the open I GOP first I picture in MPEG-2. Therefore, as described above, the pre-buffer-ring information for the sample of the I-picture Recovery Point SEI is added also than may be stored in STSP (The data transmitting apparatus 1 0 0, the above-mentioned Recovery Point SEI As a result, the data receiving apparatus that has received video data from the I picture to which the Recovery Point SEI has been added may obtain the information before receiving the information. Incomplete playback control information It is possible to select whether to display the decoded image or to start displaying after the correct decoded image is obtained, and it is necessary to decode in advance to display from the correct decoded image It is possible to obtain the number of unique pictures.
  • prebuffering information D109 is stored in stsp of trak of the MP4 file, but it may be stored as SDP data immediately below trak or moov.
  • the definition of the sample in the hint track may be extended, and the prebuffering information D109 may be stored in m dat as the hint track sample.
  • the data receiving apparatus uses the reproduction control information (reproduction parameter information) received from the data transmitting apparatus 100 according to the first embodiment based on RTSP, and appropriately converts media (content) data. Perform playback.
  • the video data received by the data receiving apparatus as media data may be MPEG-4 AVC encoded data such as MPEG-4 Visua I or H.263. Video data of another encoding system may be used.
  • FIG. 16 is a block diagram showing the configuration of the data receiving device according to the present embodiment.
  • the data receiving device 200 includes an RTP reception processing unit 201, a decoding unit 202, a display unit 203, an RTSP processing unit 204, and an instruction unit 205.
  • the RTSP processing unit 204 receives the received message d205 containing the reproduction parameter information from the data transmitting device 100, By transmitting the transmission message d207 to the device 100, playback control using RTSP is performed with the data transmitting device 100.
  • the reproduction parameter information will be described below as indicating pre-buffering information.
  • the RTSP processing unit 204 Upon acquiring the pre-buffering information included in the received message d 205, the RTSP processing unit 204 specifies the required pre-buffering time from the pre-buffering information. For example, when the RTP bucket is received by the RTP reception processing unit 201, the RTSP processing unit 204 determines the required pre-buffering time specified based on the pre-buffering information from the start of reception. In addition, the RTSP processing unit 204 determines that the decoding should be started when the time has passed, and the RTSP processing unit 204 converts the RTP control data d 206 including the synchronization information of the RTP bucket for each medium (content) into the RTP data. In addition to outputting to decoding processing unit 201, decoding start information d209 including the necessary pre-buffering time is output to instruction unit 205.
  • the RTSP processing unit 204 acquires the external instruction d208.
  • the external command d208 is information generated by a user's operation of the data receiving device 200, and is used to start or end receiving content, to temporarily stop receiving the content, or to return to a specific time position during the content. Indicates the content to instruct a jump, etc.
  • the RTP reception processing unit 201 receives the RTP bucket d 201, obtains, for example, video encoded data d 202 from the RTP bucket d 201, and then obtains the encoded data d 202 0 2 is output to the decoding unit 202. Note that the RTP reception processing unit 201 instantaneously performs processing from the reception of the RTP bucket d201 to the output of the encoded data d202. Further, the RTP bucket to be the start of decoding is determined based on the RTP control data d206.
  • the RTP reception processing unit 201 receives the RTP packet d 201.
  • the reception start signal d 210 is output to the instruction unit 205.
  • the instruction unit 205 determines the timing to start decoding based on the reception start signal d210 and the decoding start information d209, and outputs the start instruction signal d211 to instruct the start of decoding. Output to the decoding unit 202.
  • the decoding section 202 When acquiring the start instruction signal d211 from the instruction section 205, the decoding section 202 starts decoding the encoded data d202 and displays the decoded data d203 on the display section 2 0 Output to 3.
  • the decoding unit 202 of the present embodiment starts the decoding process when the required pre-buffering time has elapsed since the RTP bucket d 201 was received by the RTP reception processing unit 201. I do.
  • the display unit 203 Upon obtaining the decoded data d 203 from the decoding unit 202, the display unit 203 displays the contents of the decoded data d 203.
  • FIG. 17 is a flowchart showing the operation of the instruction unit 205 of the data receiving apparatus 200 in the present embodiment.
  • the instruction unit 205 obtains the reception start signal d210 from the RTP reception processing unit 201 and the decoding start information d209 from the RTSP processing unit 204 (step S400). 1).
  • Instructing section 205 triggered by the reception of reception start signal d210, triggers the elapsed time from the start of reception of RTP bucket d201 (step S402).
  • the instruction unit 205 determines whether or not the elapsed time measured in step S402 is equal to the required pre-buffering time included in the decoding start information d209 (step S402). 4 0 3).
  • the received data d205 which is the track data and is a response to the PLAY instruction of RTSP, is set to "necessary pre-buffering time Msec", and the pre-buffering information is included Is assumed.
  • step S403 When the instruction unit 205 determines that the time is equal to the required pre-buffering time (Yes in step S403), the instruction unit 205 outputs a start instruction signal d211 to the decoding unit 202 ( In step S404), if it is determined that the time is different from the pre-buffering required time (No in step S403), the operation from step S402 is executed again.
  • the data receiving apparatus 200 according to the present invention has been described using the above embodiment, but the data receiving apparatus 200 according to the present invention is not limited to these.
  • the pre-buffering information is obtained from the received message d205 which is a response to the PLAY instruction of the RTSP, but an existing instruction other than the PLAY instruction in the RTSP, or a newly specified instruction is provided.
  • the pre-buffering information may be obtained from the received message d205 which is a response to the issued instruction.
  • the pre-buffering information may be obtained from a message according to a protocol other than RTSP.
  • the pre-buffering information indicating the required pre-buffering time is obtained, but the pre-buffering information indicating the pre-buffering required data amount may be obtained.
  • the RTP reception processing unit 201 sends the total amount information indicating the total data amount of the RTP bucket d 201 received for each medium (content) every time the bucket is received or for a certain period of time. Is output to the instruction unit 205 every time. The instruction unit 205 determines the RTP bucket based on the total amount information. (G) Compare the total data amount of d201 with the data amount required for pre-buffering, and output a start instruction signal d211 when the data amounts match. The comparison of the data amount may be performed each time the total amount information is obtained or at regular intervals.
  • the pre-buffering information converted to the playback parameter information is obtained as the playback control information, but information related to reception, decoding, or display processing is obtained as the playback control information. May be acquired.
  • the instruction unit 205 or the RTSP processing unit 204 controls the decoding unit 202 and the display unit 203 based on the acquired information.
  • the necessary pre-buffering time is obtained as pre-buffering information, but a sequence number may be obtained as pre-buffering information.
  • the data receiving apparatus 200 starts the decoding process when all the RTP packets indicated by the acquired sequence number have been received. When all the RTP buckets cannot be received, the data receiving apparatus 200 requests the data transmitting apparatus 100 for the RTP bucket that could not be received. Alternatively, the data receiving apparatus 200 seals and warns the user before starting decoding, and then starts decoding based on a preset condition. This warning informs the user that the display of content may be stopped due to an underflow or overflow that occurs during the decoding process.
  • FIG. 18 is an explanatory diagram of a storage medium that stores a program for realizing the data transmitting device 100 and the data receiving device 200 of the first and second embodiments by a computer system.
  • FIG. 18 shows the external appearance of the flexible disk FD as viewed from the front and side, and the external appearance of the disk body FD1, which is the main body of the recording medium, as viewed from the front, and (a) in FIG. Shows an example of the physical format of the disk body FD1.
  • the disk body FD 1 is built in the case F. On the surface of the disk body FD 1, a plurality of tracks T are formed concentrically from the outer circumference toward the inner circumference, and each track has an angle of 16. Therefore, in the flexible disk FD storing the above program, the above program is recorded in an area allocated on the above disk main body FD1.
  • FIG. 18 shows a configuration for recording and reproducing the above-mentioned program on a flexible disk FD.
  • the computer system CS reads the program via the flexible disk drive FD.
  • the program in the flexible disk FD is built in the computer system C s, the program is read from the flexible disk FD by the flexible disk drive FDD and transferred to the computer system C s. .
  • the same can be performed using an optical disk.
  • the recording medium is not limited to this, and the present invention can be similarly implemented as long as it can record a program such as an IC card or a ROM cassette.
  • the data transmission device can cause a data reception device to execute appropriate reproduction processing of content data, and is useful, for example, for a server used for a moving image distribution service for mobile terminals.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

データ送信装置（１００）は、データ受信装置に対してコンテンツデータの適切な再生処理を実行させるものであって、そのデータ受信装置との間でコンテンツデータの伝送路の確立及び初期化を行い、その後、再生制御情報をＭＰ４ファイルから取り出して、データ受信装置に送信するファイル解析部（１１０）及びＲＴＳＰ処理部（１０１）と、ファイル解析部（１１０）を介してＭＰ４ファイルからコンテンツデータを取得してパケット化するＲＴＰ作成部（１０２）と、ＲＴＰ作成部（１０２）によりパケット化されたコンテンツデータを送信するＲＴＰ送出部（１０３）とを備える。

Description

明 細 書 データ送信装置 技術分野
本発明は、 動画像や音声、 テキス トなどのデジタルコ ンテンツデータ をバケツ ト化して伝送するデータ送信装置に関する。 背景技術
近年、 通信ネッ トワークの大容量化および伝送技術の進歩によ り 、 ィ ンターネッ ト上での P C (Personal Computer) 向け動画配信サービスが 普及してきた。 また、 無線網における受信端末の規格を定める国際標準 化団体である 3 G P P (Third Generation Partnership Project)におけ る規格と して T S 2 6. 2 3 4 (Transparent end-to-end packet sw ί tched stream i ng serv i ce)力《定められるなど、 携帯 3耑末におし、ても動 画配信サービスの拡大が見込まれる。 音声、 動画、 静止画、 およびテキ ス トなどのメディァデータが蓄積及び配信される際には、 メディ アデー タの再生および配信に必要なへッダ情報とメディアデータ とが多重化さ れる。 そのための多重化ファイルフォーマツ トと して M P 4が標準化さ れた。 M P 4は、 ISO/IEC JTC1/SC29/W6 11 (International
Standardization Organization/International Engineering
Consortium)において標準化された多重化ファイルフォーマツ トであり、 3 G P Pの T S 2 6. 2 3 4においても採用されている。 M P 4を用い た動画配信サービスには 2種類ある。
上記 2種類の動画配信サービスのうちの 1 つの種類は、 M P 4フアイ ルを直接送受信するダウンロー ド型と呼ばれる方式である。 現在のと こ ろ、 無線端末上の動画配信ではこの方式が主流である。 しかし、 この動 画配信サービスには、 ファイルサイズが大きい長時間コンテンッの配信 には適さない、 また、 早送りなどの特殊再生ができないといった欠点が ある。
上記 2種類の動画配信サービスのうちの他の 1 つの種類は、 ス トリ.一 ミング型と呼ばれる方式であり、 ダウンロード型における問題点を解決 する方式として、 無線端末上でのサービスが開始されようと している。 ス トリーミング型で使用される M P 4ファイルは、 ダウンロード型の M P 4ファイルにおいて多重化されるメディアデータに加えて、 メディア データをバケツ ト化するためのヒン トデータと呼ばれる情報が格納され る。
ス ト リーミ ング型の動画配信サービスでは、 M P 4 フアイル自体が配 信されるのではなく 、 サーバ側がヒン トデータ を参照してメディアデー タをパケッ ト化し、 バケツ ト化されたメディアデータが端末に向けて配 信される。 なお、 ヒントデータの枠組みについては、 特開 2 0 0 1 — 1 9 7 1 2 0においてアップル社よ り開示されている。 このよ うに、 ス ト リーミング型の動画配信サービスは、 メディアデータ （コ ンテンツデー タ） をパケッ ト化して配信するため、 長時間コ ンテンツの配信に適して いる。 さらに、 この動画配信サービスは、 サーバがコンテンツの任意時 間のデータを選択して配信することができるため、 早送りや飛び込み再 生などの特殊再生にも適している。
以下に、 M P 4ファイルを使用したス トリーミング型の動画配信サー ビスについて詳細に説明する。
M P 4では、 ヘッダやメディアデータは B o X と呼ばれるオブジェク ト単位で格納される。
図 1 は、 B o xの構造を説明するための図である。 B o xは、 s i z e フィ一ル ドと、 t y p e フィ——ル ドと、 v e r s i o n ノィ一ゾレ ドと、 f I a g s フィールドと、 データフィールドとを含む。
s i z eフィールドには、 その s i z eフィールドも含めた B o x全 体のサイズが格納される。
t y p e フィールドには、 B o Xの識別子 （通常はアルファベッ ト 4 文字） が格納される。 フィールド長は 4バイ トである。 M P 4ファイル 内での B o Xの検索は、 連続する 4バイ ト分のデータ力 t y p e フィー ルドの識別子と一致するかどうかを判定することにより行われる。
v e r s i o nフィールドには、 B o xのバ一ジョン番号が格納され る。 f I a g sフィールドには、 B o X毎に設定されるフラグ情報が格 納される。 データフィールドには、 ヘッダ情報やメディアデータが格納 される。 なお、 v e r s i o nフィールドと f I a g sフィール は必 須でないため、 B o Xによってはこれらのフィールドは存在しない。 以後、 B o X の参照には t y p e フィール ドの識別子を使用すること と し、例えばその識別子が ' m o o V ' である B o xを m o o v と呼ぶ。 図 2は、 M P 4ファイルの構造を示すデータ構成図である。
M P 4ファイルは、 図 2の （ a ) に示すように、 f t y p , m o o v , 及び m d a t の 3つの B o xから構成され、 f t y pがファイルの先頭 に配置される。 f t y pは、 M P 4ファイルを識別するための情報を含 む。 m d a t はメディアデータおよびヒン トデータを格納する。 ヒン ト データ とは、 メディアデータを R T P (Real T ime Transmi ss i on Protocol) パケッ ト化して伝送するために必要な情報である。 サーバは ヒン トデータを参照してメディアデータを R T Pパケッ ト化して配信す る。なお、 m d a t に含まれる各メディア及びヒン 卜データはそれぞれ、 トラックと呼ばれ、 各トラックはトラック I Dにより識別される。
また、 M P 4では、サンプルと呼ばれる単位でデータが取り扱われる。 メディア トラックでは、 ビデオやオーディオの 1 枚又は複数のフレーム がサンプルに相当し、 ヒン ト トラックでは、 1 つ以上の R T Pパケッ ト を作成するための情報がサンプルに相当する。
m o o Vには m d a t の各 トラックに含まれるサンプルについてのへ ッダ情報が格納される。 M P 4ファイルにおいて m o o Vの使用は必須 であり、 その個数は 1 つである。 図 2の （ b ) に示すように、 m o o v 内には B o Xが階層的に配置されておリ、 ファイル全体に共通なヘッダ 情報は m v h dに格納される。 さらに、 オーディオ、 ビデオ、 および各 メディアの 卜ラックに関連するヒン ト トラックのヘッダ情報は、 それぞ れ别々の t r a kに格納される。 ここで、 トラックの識別情報である ト ラック I Dは t r a k内の t k h dによって示される。 t r a kは、 図 2の ( c ) に示すように構成され、 サンプルのサイズゃ復号時間、 表示 開始時間などの情報が s t b I 内の各 B o xに格納される。
S t t Sには、 サンプルの復号時間が格納される。 即ち、 S t t Sに は、 連続する 2つのサンプル間における復号時間の差分値が格納されて いる。 したがって、 この差分値を加算することによ り、 各サンプルの復 号時間を取得することができる。 さらに、 復号時間と表示時間が異なる 際には、 復号時間と表示時間との差分を格納する c t t s と呼ばれる B o xが使用される。 例えば、 双方向予測を用いて符号化されたフ レーム では復号時間と表示時間が異なるため、 表示時間を求めるために c t t
Sが使用される。
また、 トラックの途中から再生が開始 （ランダムアクセス） されると きには、 復号化の開始可能なサンプルを示す情報が必要になる。 このた めの B o Xと して s t s sがあり、 s t s sにはランダムアクセス可能 なサンプル （以降、 シンクサンプルと呼ぶ。 ） の一覧が格納される。 な お、 s t s sが存在しない場合は、 トラック内の全サンプルがランダム アクセス可能であることを示す。 ここでは説明を省略するが、 s t b I には、 上記 B o xの他にもサンプルのサイズを示す s t s zなど複数の B o Xが格納される。
次に、 ヒン トデータの使用方法について図 3を参照して説明する。 図 3は、 ヒン トデータの使用方法を説明するための図である。
ここでは、 サーバがビデオ トラックの途中のサンプル （表示時間 T ) から R T Pパケッ トを作成するときの手順について説明する。
( 1 ) サーバはビデオのヒント 卜ラック用の t r a kを参照し、 表示 時間が Tと一致、 あるいは T近傍であるビデオ トラックのサンプルに対 する R T Pパケッ ト化情報が格納されたシンクサンプルを取得する。 シ ンクサンプルの特定は、 S t t S および s t s s を参照し、 表示時間を 取得することによ り行う。 取得したシンクサンプルには、 1 つ以上の R T Pバケツ トを作成するために必要な情報が格納される。
なお、 シンクサンプルの表示時間は、 先頭 R T Pパケッ トにより伝送 が開始されるビデオ トラックのサンプルの表示時間を示す。 シンクサン プルは、 それぞれのバケツ 卜がビデオ トラックのどの部分のデータ を伝 送するかを、 ビデオ トラ ックのサンプル番号及びサンプル内のバイ ト位 置により示す。 例えば、 ί 番目の R T Pパケッ トは、 Κ番目サンプルの Lバイ ト目から、 Μ番目サンプルの Νバイ ト目までを伝送する。
( 2 ) サーバは、 ビデオ トラック用の t r a kを参照して、 K番目力、 ら Μ番目までのサンプルの格納位置を取得する。
( 3 ) サーバは、 （ 2 ) で取得した格納位置を元に、 Κ番目サンプル のしバイ ト目から、 Μ番目サンプルの Νバイ 卜目までのデータを取得す る。 サーバは、 その取得したデータに、 R Τ Ρパケッ ト化に必要な他の 情報を設定して R Τ Ρパケッ トを作成する。
図 4は、 サーバから端末にメディアデータ （コンテンツデータ） が R T Pパケッ トと して配信される手順を説明するための図である。
ここでは、 M P 4ファイルは蓄積装置に格納され、 サーバと端末との 間の再生制御には R T S P (Real Time Transmission Protocol) が使用 される。 なお、 蓄積装置はサーバの内部にあってもよいし、 外部にあつ てもよい。
( 1 ) まず、 端末は、 サーバに対して、 R T S Pを使用してコンテンツ データ （ n e w s , m p 4 ) の送信を要求する。
( 2 ) サーバは、 n e w s , m p 4が利用できるかどうか確認し、 利用 できる際には η β w s . m p 4にアクセスする。
( 3 ) サーバは、 n e w s , m p 4のヒン ト トラックを解析し、 端末へ 送信するコンテンツデータを取得して、 そのコンテンツデータから R T Pバケツ トを作成する。
( 4 ) サーバは、 コンテンツデータを格納した R T Pパケッ トを端末に 対して送信する。
次に、サーバと端末の間で行われる再生制御の詳細について説明する。 図 5は、 サーバと端末と間の再生制御において交換される R T S Pメ ッセージの一例を示す図である。 図中の G _ > Sは端末からサーバへの メ ッセージを示し、 S — > Cはサーバから端末へのメ ッセージを示す。
( 1 )端末は、サーバに対して D E S C R I B E命令を用いて n e w s . m p 4のコンテンツデータを要求する。
( 2 ) サーバは n e w s . m p 4が利用可能であると応答し、 S D P (Session Description Protocol) (こよ り n e w s . m p 4 (こ関する情 報 （ n e w s . m p 4へのアクセス情報など） を送信する。 こ こで、 S D Pの内容の一部は、 M P 4ファイルのヒン ト トラック用 t r a k及び m o o v直下の u d t a と呼ばれる B o xに格納されている。 そこで、 サーバは、 上記一部の内容に残りの情報を付加することにより、 S D P の内容を作成する。
( 3 ) 端末はサーバに対して伝送時のパラメータ設定を行う。
( 4 ) サーバは端末に対して伝送時のパラメータ を通知する。
このような （ 1 ) 〜 （ 4 ) に示す R T S Pメ ッセージの送受信によ り、 サーバと端末との間の伝送路の確立及び初期化が行われる。
( 5 ) 端末はサーバに向けて P L A Y命令を発行し、 n e w s , m p 4 のコ ンテンツデータの送信開始を要求する。
( 6 ) サーバは P L A Y命令の応答と して、 送信を開始する旨のメ ッセ ージを返し、 その後 R T Pパケッ トの送信が開始される。 なお、 サーバ は、 P L A Y命令の応答を、 R T Pパケッ トの送信開始後に発行しても 良い。
ここで、 オーディオやビデオのメディアデータ （コンテンツデータ） は、 メディア毎に異なる識別子を持った R T Pバケツ トにより伝送され る。 識別子には、 R T Pパケッ トのヘッダに含まれる S S R C
( Synchron i zat i on Source) が使用される。 また、 オーディオやヒ亍ォ のメディァデータを伝送する R T Pパケッ トは、 端末のそれぞれ異なる ポートに送信されるため、 ポート番号によリ R T Pバケツ 卜が伝送する メディアデータ を識別しても良い。 なお、 オーディオのデータが 2種類 あるなど、 同一メディアの複数のデータ を送信する際にも、 同様の方法 によ り R T Pバケツ 卜が伝送するデータ を識別することができる。 図 5の （ 7 ) 〜 （ 1 0 ) は、 ランダムアクセスが行われる際の手順を 示す。 この （ 7 ) 〜 （ 1 0 ) に挙げるメ ッセージは、 端末のユーザがコ ンテンッデータの 1 0秒目を視聴しているときに 3 0秒目までスキップ する場合の内容を示す。
( 7 ) 端末はサーバに対してデータの送信停止を要求する。
( 8 ) サーバはデータの送信を停止する。 ( 9 ) 端末は、 P L A Y命令の発行により、 n e w s . m p 4の 3 0秒 目からのデータを要求する。
( 1 0 ) サーバは、 3 0秒から最後 （ 6 0秒） までを送信する旨のメ ッ セージを P L A Y命令の応答と して送信する。 この後、 3 0秒目からの コンテンツデータが端末に送信される。
( 1 1 ) 端末は、 サーバに通信の終了手続きを促す。
( 1 2 ) サーバは、 通信の終了手続きを行う。
図 6は、 従来のデータ送信装置 （サーバ） の構成を示すブロック図で ある。
データ送信装置は、ファィル解析部 8 0 1 と、 R T P作成部 8 0 2と、 R T P送出部 8 0 3 と、 R T S P処理部 8 0 4とを備える。
1^丁 3 処理部 8 0 4は、 データ受信装置 （端末） に送信メ ッセージ d 8 0 6 を送信するとともに、 データ受信装置から受信メ ッセージ d 8 0 7を受信することにより、 データ受信装置との間で R T S Pを用いた 再生制御を行う。 R T S P処理部 8 0 4は、 受信メッセ一ジ d 8 0 7を 解析し、 M P 4 ファイルのファイル名、 格納場所、 及ぴ送信要求されて いる表示時間位置を含む R T S P要求データ d 8 0 8 をファイル解析部 8 0 1 に出力する。
ファイル解析部 8 0 1 は、 図示しない蓄積装置から、 R T S P要求デ ータ d 8 0 8に示される M P 4ファイル d 8 0 1 を取得する。 次に、 フ アイル解析部 8 0 1 は、 送信要求された表示時間位置に対応するサンプ ルを、 ヒン ト トラックを解析することにより取得する。 ファイル解析部 8 0 1 は、 その取得したサンプルを、 R T Pバケツ 卜のヘッダの作成に 必要な情報とともにバケツ ト作成データ d 8 0 2として R T P作成部 8 0 2へ出力する。 さらに、 ファイル解析部 8 0 1 は、 S D P、 又は送信 開始時の先頭 R T Pパケッ トに含まれるメディアデータの表示時間情報 を含む R T S P送出情報 d 8 0 5を R T S P処理部 8 04に出力する。
R T P作成部 8 0 2は、 ファイル解析部 8 0 1 からバケツ ト作成デー タ d 8 0 2を取得すると ともに、 図示しない装置から、 R T Pパケッ ト のヘッダ情報であるバケツ トヘッダ情報 d 8 0 9を取得する。 そして、 R T P作成部 8 0 2は、 そのパケッ ト作成データ d 8 0 2とパケッ トへ ッダ情報 d 8 0 9 とに基づいて、 R T Pバケツ ト d 8 0 3を作成して R
T P送出部 8 0 3に出力する。
R T P送出部 8 0 3は、 R T P作成部 8 0 2から出力された R T Pパ ケッ 卜データ d 8 0 3を取得し、 これを R T Pバケツ ト d 8 0 4と して データ受信装置 （端末） に送信する。
図 7は、 データ送信装置のファイル解析部 8 0 1 の動作を示すフロー 図である。
ここでは、 データ送信装置は、 ビデオ トラックのデータを、 表示時間 が Tである部分のデータから R T Pパケッ ト化して送信する。 また、 ビ デォ トラ ックの トラ ック I Dは 1 であり 、 ビデオ トラ ック用のヒン ト ト ラックの トラ ック ί Dは 3である。 即ち、 ファイル解析部 8 0 1 は、 ト ラック I D = 3であるヒン ト トラ ック を参照することによ り、 トラ ック I D = 1 である ビデオ トラックのデータ を R T Pバケツ 卜化して送信す る。
まず、 ファイル解析部 8 0 1 は、 トラ ック I D = 3である トラックの s t s sおよび s t t s を解析する (ステップ S 8 0 1 ) 。 この解析に よ リ ファイル解析部 8 0 1 は、 表示時間が Tと一致する、 あるいは T以 前で最も Tに近いシンクサンプルを特定する （ステップ S 8 0 2 ) 。 な お、 ファイル解析部 8 0 1 は、 表示時間が T以降で最も Tに近いシンク サンプルを特定しても良い。 また、 オーディオなどでは通常全てのサン プルがシンクサンプルであるため s t s sが存在しない。 このように s t s sが存在しない場合は、 ファイル解析部 8 0 1 は、 全てのサンプル をシンクサンプルと して扱う。
次に、ファイル解析部 8 0 1 は、 s t b I 内の他の B o xを参照して、 特定されたシンクサンプルのデータ を取得する （ステップ S 8 0 3 ) 。 . さ らに、 ファイル解析部 8 0 1 は、 取得したシンクサンプルを解析す ることによ り、 そのシンクサンプルによ り作成される R T Pバケツ 卜で 伝送される トラック I D = 1 のビデオ 卜ラックのサンプルを特定する (ステップ S 8 0 4 ) 。
次に、 ファイル解析部 8 0 1 は、 トラック I D = 1 である トラ ックの t r a kを解析し、 ステップ S 8 0 4において R T Pバケツ ト化の対象 と して特定されたサンプルのデータ を取得する (ステップ S 8 0 5 ) また、 ファイル解析部 8 0 1 は、 ステップ S 8 0 2で特定したシンク サンプル以降にヒン ト トラックのサンプルがある場合には、 そのサンプ ルを取得して、 そのサンプルに基づいてステップ S 8 0 4 , S 8 0 5と 同様の動作を行う。
以上では、単一のメディ アデータ を取得する手続きについて述べたが、 オーディオと ビデオなど複数のメディアを扱う際には、 各メディ アにつ いて同様の処理が行われる。 なお、 各メディア トラック と、 対応する ヒ ン ト トラック とは、 トラ ック I Dによ り関連付けられている。
データ受信装置は、 上述のデータ送信装置から出力された R T Pパケ ッ ト d 8 0 4 (符号化データ） を取得し、 その符号化データ をバッファ と呼ばれるメモリ に保持しながら、 メモリ内の符号化データの復号化を 行う。
こ こで、 バッファモデルと呼ばれるモデルが規定されている。 このバ ッファモデルは、 所定のレー トで符号化データが流入する際に、 所定の サイズのバッファを用意すれば、バッファが空になる（アンダーフロー）、 あるいは溢れる （オーバーフロー） ことなしに復号化が行えることを保 証する。
バッファモデルは、 M P E G— 4 A V C (Advanced Vi deo God i ng) や M P E G— 4 (Moving Picture Expert Group Visual) などの符号化 方式ごとに定められており、 符号化データはこのバッファモデルに従つ て符号化される。
図 8は、 符号化データの流入開始からの経過時間 （横軸） と、 データ 受信装置のバッファの占有量 （縦軸） との関係を示す図である。
バッファ占有量とは、 ある時間にバッファに存在する符号化データの データ量である。 例えばこの図 8に示すように、 傾き Rを持つビッ トレ 一卜によりバッファに符号化データが流入する。 データ受信装置は、 時 刻 t 1 にピクチャ P 1 に対して復号化処理を開始し、 続く ピクチャをそ れぞれ t 2 , t 3 , …の時刻で復号化する。 即ち、 それぞれのピクチャ の復号化時刻 （ t 1 , t 2 , ·■·) において、 復号化対象のピクチャに相 当するデータがバッファから引き抜かれる。 例えば、 時刻 t 2において 復号化対象のピクチャのデータがバツファから引き抜かれることにより . その復号化対象ピクチャのデータ量 P s 2だけバッファ占有量が少なく なる。
ここで、 バッファへの符号化データの流入が開始されてから復号化が 開始されるまでの時間をプリバッファリング時間と呼ぶ。 図 8に示す動 作をデータ受信装置が行う場合、プリバッファ リング時間は t 1 である。 データ受信装置は、 バッファモデルに基づき、 符号化時に定められたプ リバッファリング時間を守って復号化を開始すれば、 バッファ占有量が ビデオ符号化規格 （M P E G— 4など） により規定されたバッファサイ ズを超えることなく、 且つ、 ピクチャの復号化時刻において復号化対象 ピクチャのデータが完全に揃っている状態で、 符号化データの復号化を 継続することができる。 つまり、 図 8に示すように、 バッファ占有量は 常にゼロ以上バッファサイズ以下の状態に保たれる。
しかしながら、 上記従来のデータ送信装置では、 データ受信装置に伝 えるべき、 R T Pバケツ ト 8 0 4の再生に必要な情報が不足している ため、 R T Pパケッ ト d 8 0 4によリ伝送される符号化データを、 デー タ受信装置に対して適切に再生させることができないという問題がある, データ受信装置は、 符号化データの途中のピクチャ （ 5枚目のピクチ ャ P 5 ) から復号化を開始する場合、 バッファのアンダーフロー及びォ 一バーフローを防ぐため、 ピクチャ P 5のデータをバッファから引き抜 いた後に、 バッファ占有量をオフセッ ト o s 5にしておく必要がある。 ところが、 データ受信装置は、 プリバッファリング時間と して常に一定 時間の経過後に復号を開始するため、 ピクチャ P 5のデータの引き抜き 後、 バッファ占有量をオフセッ ト o s 5よりも少なく してしまう場合が る。
図 9は、 プリバッファリング時間に応じて異なるバッファ占有量の時 間的な変化を示す図である。
データ受信装置は、 図 9の （ a ) に示すように、 プリバッファリ ング 時間 d bの経過後にピクチャ P 5の復号化を開始すると、 バッファ占有 量がオフセッ ト o s 5となるため、 ピクチャ P 6以降のピクチャも復号 化時刻において正常に復号化することができる。
ところが、 データ受信装置は、 図 9の （ b ) に示すように、 プリバッ ファリング時間 d aの経過後にピクチャ P 5の復号化を開始すると、 バ ッファ占有量がゼロとなるため、 ピクチャ P 6の復号化時刻においてピ クチャ P 6のデータが揃っておらず、 ピクチャ P 6を復号化することが できない。 このため、 データ受信装置は、 ピクチャ P 6のデータが揃う まで復号化動作を停止したリ表示を停止したりする。 このように、 バッファのオーバ一フロー及びアンダーフローを防ぐ適 切なプリバッファリング時間は、 復号化の開始対象となるピクチャによ つて異なる。 データ受信装置は、 このようなピクチャごとに適切なプリ バッファリング時間など、 適切な再生に必要な情報を得ることができな いため、 再生中にピクチャの表示を停止したり、 復号化開始までの待ち 時間を必要以上に長く してしまう。
本発明は、 かかる問題に鑑みてなされたものであり、 データ受信装置 に対してコンテンツデータの適切な再生処理を実行させるデータ送信装 置を提供することを目的とする。 発明の開示
上記目的を達成するために、 本発明のデータ送信装置は、 デジタル著 作物たるコンテンツデータ をファイルから取り出して受信装置に対して 送信するデータ送信装置であって、 前記ファイルは、 前記コ ンテンツデ ータと、 前記コ ンテンツデータの再生処理に用いられる再生制御情報と を多重化して構成され、 前記データ送信装置は、 前記受信装置との間で コ ンテンツデータの伝送路の確立及び初期化を行う前置処理手段と、 前 記前置処理手段による伝送路の確立及び初期化の後、 前記再生制御情報 の少なく とも一部を前記ファイルから取り出して、 前記受信装置に送信 する制御送信手段と、 前記ファイルからコンテンツデータの少なく とも 一部を取得してバケツ ト化するバケツ ト生成手段と、 前記バケツ ト生成 手段によりバケツ ト化されたコンテンツデータの少なく とも一部を送信 するコンテンツ送信手段とを備えることを特徴とする。
これによつて、 前置処理手段による伝送路の確立及び初期化の後、 再 生制御情報の少なく とも一部がファィルから取リ出されて受信装置に送 信されるため、 受信装置は、 コンテンツ送信手段から送信されたコンテ ンッデータ、 及び制御送信手段から送信された再生制御情報を受信する と、 その再生制御情報を用いてコ ンテンツデータを適切に再生処理する ことができる。
また、 前記ファイルに多重化された再生制御情報は、. 前記コンテンツ データに含まれる複数のデータ単位ごとに、 当該データ単位からの再生 に用いられる再生制御単位情報を含んでテーブル状に構成され、 前記制 御送信手段は、 前記受信装置からの要求に応じたデータ単位に関連する 前記再生制御単位情報を、 前記フアイルの再生制御情報から取リ出して 送信し、 前記バケツ ト生成手段は、 前記受信装置からの要求に応じたデ ータ単位からの前記コンテンツデータを取得してバケツ ト化することを 特徴と しても良い。
これによ り、 受信装置からの要求に応じたデータ単位からのコ ンテン ッデータがバケツ ト化されて送信されると ともに、 そのデータ単位に闘 連する再生制御単位情報も制御送信手段から送信されるため、 受信装置 は、 自らが要求したコ ンテンツデータの一部分を、 再生制御単位情報を 用いて、 その一部分に含まれる先頭のデータ単位から適切に再生処理す ることができる。
また、 前記再生制御単位情報は、 前記コ ンテンツ送信手段から送信さ れて前記受信装置に受信されるコンテンツデータに対して、 復号処理を 開始すべきタイミングを知らせる内容を示すことを特徴と しても良い。 例えば、 前記再生制御単位情報は、 前記タイ ミングを知らせる内容と し て、 前記受信装置によるコンテンツデータの受信開始から前記復号処理 の開始までの時間を示す。 又は、 前記再生制御単位情報は、 前記タイ ミ ングを知らせる内容と して、 前記受信装置によって蓄積されるコンテン ッデータのデータ量を示す。
これにより、 コンテンツデータを受信してバッファへの蓄積を開始し た受信装置は、 再生制御単位情報を用いることで、 そのバッファに蓄積 されるコ ンテンツデータに対して復号処理を開始すべきタイ ミ ングを知 ることができ、 バッファのオーバーブローやアンダーフローの発生を防 いで、 その蓄積されるコンテンツデータの再生処理を適切に行う ことが できる。 また、 再生制御単位情報が時間を示すときには、 受信装置は受 信開始からの時間を計時することによ り上記タイ ミ ングを知ることがで き、 再生制御単位情報がデータ量を示すときには、 受信装置はバッファ に蓄積されるデータ量に基づいて上記タイ ミ ングを知ることができる。 また、前記制御送信手段は、前記再生制御単位情報の示すデータ量を、 前記受信装置によるコ ン亍ンッデータの受信開始から前記復号処理の開 始までの時間に変換し、 前記変換された再生制御単位情報を送信するこ とを特徴と しても良い。 ここで、 前記制御送信手段は、 前記再生制御単 位情報を、 前記コ ンテンッ送信手段においけるコ ンテンツデータの伝送 状況に応じて変換する。
これによ り、 再生制御単位情報の示すデータ量が時間に変換されて受 信装置に通知されるため、 バッファに蓄積されるデータ量を把握不可能 な受信装置であっても適切に上記タイ ミ ングを知ることができる。また、 コンテンツデータの伝送状況に応じて上記変換が行われる場合には、 そ の伝送状況に影響されることなぐ適切な時間を受信装置に通知すること ができる。 例えばコ ンテンッデータの送信速度が低下したときには、 そ の時間が長く なるように変換し、 適切な時間を受信装置に通知すること ができる。
また、 前記コ ンテンツ送信手段は、 伝送路の状況に基づいて、 コ ンテ ンッデータの送信速度を変化させることを特徴と しても良い。
これによ り、 受信装置は安定した品質でコ ンテンツデータ を再生する ことができる。 また、 前記コ ンテンツデータは、 複数の画像を含んで構成される動画 像データであって、 前記再生制御単位情報は、 当該データ単位の先頭の 画像から正しい復号処理結果が得られるか否かを示すことを特徴と して も良い。 又は、 前記コンテンツデータは、 複数の画像を含んで構成され る動画像データであって、 前記再生制御単位情報は、 当該データ単位の 先頭の画像から復号処理が開始された場合に、 最初に正しぃ復号処理結 果が得られる部位を示すことを特徴と しても良い。
これにより、 データ送信装置からコ ンテンツデータを受信した受信装 置は、不完全に復号処理される画像からコ ンテンツの内容を出力する力、、 正しく復号処理される画像からコ ンテンツの内容を出力するかを選択す ることができる。
また、 前記コ ンテンツデータは、 連続する複数の画像から構成される シーンを前記データ単位と して含む動画像データであって、 前記再生制 御情報は、 前記各シーンを構成する画像を復号化する際の初期化に要す る情報を示すことを特徴と しても良い。
これによ り、 例えばク リ ヅプ再生のように異なるシーンの画像を順に 受信装置が要求したときには、 データ送信装置は各シーンとともに、 そ れらに関連する再生制御単位情報を送信するため、 受信装置は再生制御 単位情報を用いて各シーンごとに適切に初期化を行い、 各画像を表示す ることができる。
また、 前記コ ンテンツデータは、 複数の画像を含んで構成される動画 像データであって、 前記再生制御情報は、 前記複数の画像のうちのラン ダムアクセス可能な画像の周期を示すことを特徴と しても良い。
これにより、 再生制御情報を受信した受信装置は、 その再生制御情報 に基づいてコンテンツデータのランダムアクセス可能な部位を特定する ことができ、 受信装置はそれらの部位から適切に再生処理を行うことが できる。
なお、 本発明は、 上記データ送信装置によってコンテンツデータを送 信するデータ送信方法やプログラム、 そのプログラムを格納する記憶媒 体と して実現することもできる。 図面の簡単な説明
図 1 は、 M P 4ファイルの B o Xの構造を説明するための図である。 図 2は、 M P 4 ファイルの構造を示すデータ構成図である。
図 3は、 ヒン トデータの使用方法を説明するための図である。
図 4は、 サーバから端末に'メディアデータ （コンテンツデータ） が R
T Pバケツ 卜と して配信される手順を説明するための図である。
図 5は、 サーバと端末と間の再生制御において交換される R T S P≠ ッセージの一例を示す図である。
図 6は、 従来のデータ送信装置 (サーバ) の構成を示すブロック図で £¾ ' ϊ
図 7は、 同上のデータ送信装置のファイル解析部の動作を示すフロー 図である。
図 8は、 符号化データの流入開始からの経過時間 （横軸） と、 データ 受信装置のバッファの占有量 （縦軸） との関係を示す図である。
図 9は、 プリバッファリング時間に応じて異なるバッファ占有量の時 間的な変化を示す図である。
図 1 0は、 本発明の実施の形態 1 に係るデータ送信装置の構成を示す ブロック図である。
図 1 1 は、 s t s pに格納されたプリバッファリング情報の内容の一 例を示すデータ内容表示図である。
図 1 2は、 s t s pに格納されたプリバッファリング情報の内容の他 の例を示すデータ内容表示図である。
図 1 3は、 データ送信装置のファイル解析部の動作を示すフロー図で foる。
図 1 4は、 プリバッファリング情報の取得処理 （図 1 3のステップ S 1 0 5 ) の詳細な動作を示すフロー図である。
図 1 5は、 データ送信装置とデータ受信装置との間で交換される R T S Pメ ッセージの一例を示す図である。
図 1 6は、 本発明の実施の形態 2に係るデータ受信装置の構成を示す ブロック図である。
図 1 7は、 同上のデータ送信装置の指示部の動作を示すフロー図であ 図 1 8は、 本発明の実施の形態 3 における、 実施の形態 1 又は 2のデ ータ送信装置及びデータ受信装置をコンピュータ システムによ り実現す るためのプログラムを格納する記憶媒体についての説明図である。 発明を実施するための最良の形態
(実施の形態 1 )
以下、 本発明の第 1 の実施の形態におけるデータ送信装置について、 図面を参照しながら説明する。
図 1 0は、 本発明の実施の形態 1 に係るデータ送信装置の構成を示す ブロック図である。
本実施の形態に係るデータ送信装置 1 0 0は、 例えばプリバッファリ ング時間などの適切な再生に必要な情報 （再生制御情報） を M P 4 ファ ィルから取リ出してデータ受信装置に送信することにより、 そのデータ 受信装置に対して適切な再生処理を実行させるものである。 本実施の形 態に使用される M P 4ファイルは、 オーディオ、 ビデオ、 又はテキス ト のメディアデータ と、 ヒン トデータ とが多重化されたものであって、 上 記再生制御情報はそのヒン トデータのヘッダに多重化されている。なお、 本実施の形態において使用される M P 4ファイルは、 M P E G— 4 A V Cや、 M P E G— 4 V i s u a I 、 H . 2 6 3などの符号化方式で符号 化されるビデオデータを示す。
このようなデータ送信装置 1 0 0は、 フアイル解析部 1 1 0と、 R T S P処理部 1 0 1 と、 R T P作成部 1 0 2と、 R T P送出部 1 0 3 と、 ファイル作成部 1 0 4とを備える。
ファイル作成部 1 0 4は、コ ンテンツデータのス ト リームを取得して、 M P 4ファイルを作成し、 その M P 4ファイルを蓄積装置に格納する。
R T S P処理部 1 0 1 は、 データ受信装置に送信メ ッセージ d 1 0 7 を送信すると ともに、 データ受信装置から受信メ ッセージ d 1 0 8を受 信することによ り、 データ受信装置との間で R T S Pを用いた再生制御 を行う。 ここで送信メ ッセージ d 1 0 7には、 ファイル解析部 1 1 0か ら取得した R T S P送出情報 d 1 0 5及び再生パラメ一タ情報 d 1 1 0 の少なく とも一方が含まれる。 R T S P処理部 1 0 1 は、 受信メ ッセ一 ジ d 1 0 8を解析し、 M P 4ファイルのファイル名、 格納場所、 及び送 信要求されている表示時間位置を.含む R T S P要求データ d 1 0 1 をフ アイル解析部 1 1 0に出力する。
ファイル解析部 1 1 0は、 M P 4ファイルを解析して R T Pバケツ ト の作成に必要なデータや、 R T S Pの通信に必要なデータ を作成するも のであって、 R T P解析部 1 1 2と、 情報取得部 1 1 1 と、 再生解析部 1 1 3 と、 変換部 1 1 4とを備える。
R T P解析部 1 1 2は、 情報取得部 1 1 1 を介して R T S P要求デー タ d 1 0 1 を取得し、 M P 4ファイルのヒン ト トラックを解析すること によ り、 その R T S P要求データ d l 0 1 に対応するサンプルを含むサ ンプルデータ d 1 0 2 を取得する。 さ らに、 R T P解析部 1 1 2は、 そ の取得したサンプルデータ d 1 0 2 を情報取得部 1 1 1 に出力し、 サン プルデータ d 1 0 2の先頭にあるサンプルのサンプル番号を含むサンプ ル番号情報 d 1 0 3 を再生解析部 1 1 3に出力する。サンプル番号とは、 サンプルを識別するための番号である。 例えば、 トラ ックの各サンプル に対して、 先頭のサンプルから順にサンプル番号 1 ， 2 ， 3…が割り当 てられる。 なお、 サンプル番号情報 d 1 0 3は、 ヒン ト トラ ックゃメデ ィァ トラックの トラック I Dを含んでいても良い。
情報取得部 1 1 1 は、 R T P解析部 1 1 2からサンプルデータ d 1 0 2 を取得する。 情報取得部 1 1 1 は、 その取得したサンプルデータ d 1 0 2 と、 R T Pパケッ トのヘッダの作成に必要な情報とを、 パケッ ト作 成データ d 1 0 4 と して R T P作成部 1 0 2に出力する。 さ らに、 情報 取得部 1 1 1 は、サンプルデータ d 1 0 2に基づいて、シーケンス番号、 タイムスタ ンプ、 S D P、 又は R T Pパケッ トの送信開始時に先頭に含 まれるメディアデータの表示時間情報、 などを含む R T S P送出情報 d 1 0 5 を作成して R T S P処理部 1 0 1 に出力する。
再生解析部 1 1 3は、 R T P解析部 1 1 2からサンプル番号情報 d 1 0 3 を取得する。 再生解析部 1 1 3は、 その取得したサンプル番号情報 d 1 0 3の示すサンプル番号のサンプル以降の各サンプルに関する再生 制御情報 d 1 0 9 を、 M P 4 ファイルのヒン ト トラックから取得する。 そして、 再生解析部 1 1 3は、 取得した再生制御情報 d 1 0 9 を変換部 1 1 4に出力する。 再生制御情報 d 1 0 9は、 サンプル番号情報 d 1 0 3の示すサンプル番号のサンプルからの再生処理がデータ受信装置側で の適切に行われるための情報である。 例えば、 この再生制御情報 d 1 0 9は、 データ受信装置のバッファでオーバーフローやアンダーフローが 生じないような適切なプリバッファ リ ングが行われるためのプリバッフ ア リ ング情報である。
変換部 1 1 4は、 再生解析部 1 1 3から取得した再生制御情報 d 1 0 9を R T S Pのパラメータに変換して再生パラメータ情報 d 1 1 0を生 成し、 これを R T S P処理部 1 0 1 に出力する。
R T P作成部 1 0 2は、 'ファイル解析部 1 1 0からバケツ ト作成デー タ d 1 0 4を取得すると ともに、 R T Pバケツ 卜のヘッダ情報であるパ ケッ トヘッダ情報 d 1 1 1 を図示しない装置から取得する。 なお、 この パケッ トヘッダ情報 d 1 1 1 は、 シーケンス番号の初期値などを含む。 そして、 R T P作成部 1 0 2は、 バケツ ト作成データ d 1 0 4及びパケ ッ トへッダ情報 d 1 1 1 に基づいて、 R T Pパケッ ト d 1 1 2を作成す る。
R T P送出部 1 0 3は、 R T P作成部 1 0 2で作成された R T Pパケ ッ ト d 1 1 2をデータ受信装置に送信する。
このよ うな本実施の形態のデータ送信装置 1 0 0は、 例えばビデオの 途中からのデータ を送信するようにデータ受信装置から要求されたとき には、 ヒ ン ト トラック用の S t S S を参照する。 そしてデータ送信装置
1 0 0は、 ヒン ト トラックのシンクサンプルの中から、 データ受信装置 の要求に対して最も適当なサンプルを特定し、 その特定したサンプル以 降のサンプルに基づいて、 ビデオデータの R T Pバケツ トを生成して送 信する。 表示時間 Tの部分からのデータ （ R T Pパケッ ト） がデータ受 信装置から要求された場合には、 データ送信装置 1 0 0は、 表示時間が Tと等しい、 又は T以前で最も Tに近いヒン ト トラックのシンクサンプ ルを特定する。 なお、 データ送信装置 1 00は、 表示時間が T以降で最 も τに近いシンクサンプルを特定しても良い。
さ らに本実施の形態に係るデータ送信装置 1 0 0は、 ヒン ト トラ ック のシンクサンプルに基づいて 1 つ以上の R T Pバケツ トを作成するとき には、 先頭の R T Pバケツ トによ り最初に伝送される ビデオ トラックの サンプルに対する再生パラメータ情報 d 1 1 0 を、 送信メ ッセージ d 1 0 7 と してデータ受信装置に送信する。 このようなデータ送信装置 1 0 0から R T Pバケツ トを受信したデータ受信装置は、 その再生パラメ一 タ情報 d 1 1 0 (再生制御情報 d 1 0 9 ) に基づいて、 その受信した R T Pパケッ トに対して適切な再生を行う ことができるのである。
ここで、 本実施の形態のデータ送信装置 1 0 0が取り扱う M P 4 ファ ィルの構造について説明する。
M P 4 ファイルは、 再生制御情報と してプリバッファ リ ング情報を含 む。 再生制御情報は、 各サンプルからの再生処理がデータ受信装置によ つて適切に行われるための情報である。 プリバッファ リ ング情報は、 各 サンプルからのプリバッファリングが適切に行われるための情報であつ て、 ヒン ト トラック用の t r a kの s t b I の直下に配置される s t s p ( SyncSamp l e To P r ebuf Box ) に、 テーブル構造となって格納される。 具体的にプリバッファ リング情報は、各サンプル（ピクチャ） に応じて、 受信開始から復号開始までのプリバッファリングに必要な時間 （プリバ ッファリ ング必要時間） や、 受信開始から復号開始までのプリバッファ リ ングに必要なデータ量 （プリバッ ファ リ ング必要データ量） を示す。 図 1 1 は、 s t s pに格納されたプリバッファ リ ング情報の内容の一 例を示すデータ内容表示図である。
プリバッファ リ ング情報 D 1 0 9は、 図 1 1 の （ a ) に示すよ うに、 ヒン ト トラ ックのシンクサンプルのサンプル番号（シンクサンプル番号） と、 そのサンプル番号のシンクサンプルに対応するプリバッファ リ ング 必要データ量とを含む。 プリバッファ リ ング必要データ量は、 これに対 応ずるシンクサンプルに基づいて作成された R T Pバケツ 卜からデータ 受信装置による受信が開始された場合に、 その受信開始から復号開始ま でにデータ受信装置のバッファに蓄積が必要なデータ量を示す。
例えば、 データ受信装置は、 サンプル番号 1 のシンクサンプルに基づ いて作成された R T Pパケッ ト d 1 1 2から受信を開始するときには、 R T Pバケツ ト d 1 1 2を 1 5 0 0 0バイ 卜まで受信してから復号化を 開始する。 なお、 プリバッファリング必要データ量が、 R T Pなどの伝 送プロ トコルに依存することがないように、 そのプリバッファリ ング必 要データ量を、 バケツ 卜に含まれるビデオやオーディオの符号化データ の量と しても良い。
図 1 1 の ( b ) は、 上述のようなプリバッファリング情報 D 1 0 9を 格納する s t s pのシンタックスの一例を示す図である。 図 1 1 中の sync —sample —number (まシンクサンプ』レのサンプ レ番号を示し、 prebuf —data _byteは、 プリバッファ リ ング必要データ量を示す。
図 1 2は、 s t s p に格納されたプリバッファ リ ング情報の内容の他 の例を示すデータ内容表示図である。
プリバッファリング情報 D 1 0 9は、 図 1 2の （ a ) に示すように、 ヒン ト トラックのシンクサンプルのサンプル番号（シンクサンプル番号） と、 そのサンプル番号のシンクサンプルに対応するプリバッファ リ ング 必要時間とを含む。
例えば、 データ受信装置は、 サンプル番号 1 のシンクサンプルに基づ いて作成された R T Pバケツ ト d 1 1 2から受信を開始したときには、 その受信開始から 1 . 8 7 5 ( s ) 経過後に R T Pパケッ ト d 1 1 2の 復号化を開始する。 言い換えれば、 送信レー トが 6 4 0 0 0 ( b p s ) である場合、 データ受信装置は、 6 40 0 0 X 1 . 8 7 5 /8 = 1 5 0 0 0バイ 卜のデータがバッファに蓄積されたときに、 R T Pバケツ ト d 1 1 2の復号化を開始する。
図 1 2の （ b ) は、 上述のようなプリバッファリング情報 D 1 0 9を 格納する s t s pのシンタ ックスの一例を示す図である。 図 1 2中の sync—sample—numberはシンクサンプルのサンプル番号を示し、 prebuf —per i odはプリバッファ リ ング必要時間を示す。
なお、 シンクサンプルのプリバッファ リ ング情報を示すことができる のであれば、 そのプリバッファ リ ング情報を他の方法によ り M P 4ファ ィルに格納してもよい。 例えば'、 サンプルが参照するサンプルエン ト リ のインデックス番号を Samp I e to Chunk Box ( ' s t s c ' ) を用いて 示すのと同様に、 プリバッファ リ ング情報を s t b I 内の Β ο χにおけ るテーブルデータのェン ト リ と して格納し、 シンクサンプルと前記ェン ト リのイ ンデックス番号とを関連付ける。
図 1 3は、 データ送信装置 1 0 0のフアイル解析部 1 1 0の動作を示 すフロー図である。 なお、 再生制御情報 d 1 0 9をプリバッファ リ ング 情報と して以下説明する。
ここでは、 データ送信装置 1 0 0は、 ビデオ トラックのデータ を、 表 示時間が Tである部分のデータから R T Pパケッ ト化して送信する。 ま た、 ビデオ トラ ックの トラック ί Dは 1 であり、 ビデオ トラック用のヒ ン ト トラ ックの トラック I Dが 3である。 即ち、 ファイル解析部 1 1 0 は、 トラック I D = 3であるヒン ト トラ ックを参照することによ り 、 ト ラック I D = 1 であるビデオ トラックのデータ を R T Pパケッ ト化して 送信する。 なお、 ここではビデオデータについて説明するが、 オーディ ォ、 あるいはテキス トデータについてもプリバッファ リ ング情報を使用 しても良い。
まず、 ファイル解析部 1 1 0は、 トラ ック I D = 3である トラック （ヒ ン ト トラック） の s t b l ( s t s sおよび s t t s ) を解析する （ス テツプ S 1 0 1 ) 。 この解析によ リ ファイル解析部 1 1 0は、 表示時間 が Tと一致する、 又は T以前で最も Tに近いシンクサンプルを特定する (ステップ S 1 0 2 ) 。 次に、 ファイル解析部 1 1 0は、 s t b I 内の 他の B o x を参照して、 特定されたシンクサンプルのデータ を取得する (ステップ S 1 0 3 ) 。 さ らに、 ファイル解析部 1 1 0は、 取得したシ ンクサンプルを解析することによ り、 そのシンクサンプルによ り作成さ れる R T Pバケツ 卜によって伝送される トラ ック I D = 1 のビデオ トラ ックのサンプルを特定する （ステップ S 1 0 4 ) 。
次に、 ファイル解析部 1 1 0は、 トラック I D = 3であるヒン ト トラ ックの s t s p を参照することによ り、 ステップ S 1 0 3で特定したシ ンクサンプル ( 卜ラ ック I D = 3 ) に基づいて R T Pパケッ ト化される 先頭の R T Pパケッ ト (ピクチャ） に対するプリバッファ リ ング情報 d 1 0 9 を取得する （ステップ S 1 0 5 )
プリバッファ リ ング情報 d 1 0 9 を取得したファイル解析部 1 1 0は. そのプリバッファ リ ング惰報 d 1.0 9 を R T S Pのパラメータに変換し て、 再生パラメ一タ情報 d 1 1 0 を生成する （ステップ S 1 0 6 ) 。 その後、 ファイル解析部 1 1 0は、 トラ ック I D = 1 であるビデオ ト ラックの t r a k を解析し、 ステップ S 1 0 4において R T Pパケッ ト 化の対象と して特定されたサンプルを取得する （ステップ S 1 0 7 ) 。 また、 ファイル解析部 1 1 0は、 ステップ S 1 0 2で特定したシンク サンプル以降のヒン 卜 トラックのサンプルについては、 そのサンプルの データ を取得し、 続いてステップ S 1 0 4 , S 1 0 7 と同様の動作を行 ラ。
なお、 データ送信装置 1 0 0は、 プリバッファ リ ング情報の取得処理 (ステップ S 1 0 5 ) を、 シンクサンプルの取得 （ステップ S 1 0 3 ) 前に行っても良く 、 ビデオ トラックのサンプルの取得 （ステップ S 1 0 7 ) 後に行っても良い。
図 1 4は、 プリバッファ リ ング情報の取得処理 （図 1 3のステップ S 1 0 5 ) の詳細な動作を示すフロー図である。
なお、 s t s pは、 図 1 1 の （ b ) に示すシンタ ックスで表され、 図 1 3のステップ S 1 0 3で特定されたヒン ト トラックのシンクサンプル のサンプル番号が Nであると想定する。
まず、ファイル解析部 1 1 0は、データを読み出すためのポイ ンタ を、 s t s pの entry— count フィール ドの先頭にセッ ト し、 カウン ト値を 0 にセッ トする （ステップ S 2 0 1 ) 。
次に、 ファイル解析部 1 1 0は、 s t s p に含まれるエン ト リ数 Mを 取得し (ステップ S 2 0 2 ) 、 ポイ ンタ を 4バイ ト分進める （ステップ S 2 0 3 ) 。
その後、 ファイル解析部 1 1 0は、 カウン ト値に 1 を加算し （ステツ プ S 2 0 4 ) 、 シンクサンプルのサンプル番号 （sync— number) を取得す る （ステップ S 2 0 5 ) 。 ファイル解析部 1 1 0は、 さ らにポイ ンタ を 4バイ ト分進める (ステップ S 2 0 6 ) 。
ファイル解析部 1 1 0は、 ステップ S 1 0 5で取得したシンクサンプ ルのサンプル番号 （sync_number) が N と等しいか否かを判定する （ステ ップ S 2 0 7 ) 。 N と等しければ （ステップ S 2 0 7の Y e s ) 、 ファ ィル解析部 1 1 0は、 サンプル番号が Nであるシンクサンプルに対応す るプリバッファ リ ング情報 d 1 0 9 を取得する （ステップ S 2 0 8 ) 。 等し く ない場合は (ステップ S 2 0 7の N o ) 、 ファイル解析部 1 1 0 は、 カウン ト値がエン ト リ数 Mよ り も小さいか否かを判定する (ステツ プ S 2 0 9 ) 。 ここで、 ファイル解析部 1 1 0は、 カウン ト値がェン ト リ数 Mよ り も小さければ （ステップ S 2 0 9の Y e s ) 、 ステップ S 2 0 4〜 S 2 0 7の処理を繰り返し実行する。 一方、 カウン ト値がェン ト リ数 M以上であるときには （ステップ S 2 0 9の N o ) 、 ファイル解析 部 1 1 0は、 サンプル番号 Nのシンクサンプルに対応するプリバッファ リ ング情報 d 1 0 9 を取得することができず、 予め設定されたデフオル ト値を取得し、 そのデフォル ト値をプリバッファ リ ング情報 d 1 0 9 と して使用する （ステップ S 2 1 0 ) 。
図 1 5は、 本実施の形態におけるデータ送信装置 1 0 0 とデータ受信 装置との間で交換される R T S Pメ ッセージの一例を示す図である。 データ送信装置 1 0 0は、 （ 1 ) 〜 （ 5 ) に示すように、 データ受信 装置との間の伝送路の確立及び初期化を行った後、 プリバッファ リ ング 情報 d 1 0 9 を再生パラメ一タ情報 d 1 1 0に変換し、 これを R T S P の P L A Y命令の応答と してデータ受信装置に送信する。 例えば図 1 5 に示すように、 データ送信装置 1 0 0は、 プリバッファ リ ング必要時間 を示すプリバッファ リ ング情報 d 1 0 9 を、 3GPP TS 26.234規格によ リ 規定された X- in ^prebuf per iod といった再生パラメータ情報 d 1 1 0 に変換し、 その再生パラメータ情報 d 1 1 0 を送信メ ッセージ d 1 0 7 に含めて送信する。
図 1 5の ( 6 ) で送信される再生パラメータ情報 d 1 1 0について、 具体的に説明する。
例えば、 図 1 1 の （ a ) に示すプリバッファ リ ング情報 D 1 0 9が s t s pに格納されている場合、 データ送信装置 1 0 0は、 サンプル番号 1 のシンクサンプルに対応するプリバッファ リ ング情報 d 1 0 9 と して 「プリバッファ リ ング必要データ量 1 5 0 0 0バイ ト」 を取得する。 デ ータ送信装置 1 0 0は、 R T Pバケツ 卜の伝送レー トが 6 4 0 0 0 b p s であって、 タイムスケールが 9 0 0 0 0であると、 その取得したプリ バッファ リング情報 d 1 0 9 を 9 0 0 0 0 X 1 5 0 0 0 X 8 /6 4 0 0 0 = 1 6 8 7 5 0の再生パラメータ情報 d 1 1 0 ( x-i n i tprebuf per i od) に変換する。
図 1 5の（ 1 0 )で送信される再生パラメータ情報 d 1 1 0について、 具体的に説明する。
例えば、 データ送信装置 1 0 0は、 ビデオ トラ ックの表示時間が 3 0 秒の位置にあるサンプルから送信を開始する場合、 サンプル番号 3 0 0 のシンクサンプルに対応するプリバッファ リ ング情報 d 1 0 9 と して 「プリバッファ リ ング必要データ量 9 0 0 0 J を取得する。 データ送信 装置 1 0 0は、 R T Pパケッ トの伝送レー ト力 6 4 0 0 0 b p s であつ て、 タイムスケールが 9 0 0 0 0であると、 その取得したプリバッファ リ ング情報 d 1 0 9 を 9 0 0 0 0 x 9 0 0 0 x 8 /6 4 0 0 0 = 1 0 1 2 5 0の再生パラメータ情報 d 1 1 0 (x-initprebufperiod) に変換す る。
なお、 図 1 5に示す例では、 データ送信装置 1 0 0は、 P L A Y命令 の応答と して再生パラメータ情報 d 1 1 0 (プリバッファ リ ング情報） を送信したが、 コ ンテンツ （例えばビデオ） の先頭から R T Pパケッ ト の送信を開始する場合、 再生パラメータ情報 d 1 1 0 を S D Pに格納し て送信しても良い。 また、 データ送信装置 1 0 0は、 P L A Y命令の応 答と してではなく 、 R T S P規格における別の命令や、 新規に作成され た命令などに対する応答と して再生パラメータ情報 d 1 1 0 を送信して も良い。
ここで、 上述のようにデータ送信装置 1 0 0が s t s pからプリバッ フア リ ング情報を取得する代わりにデフォル ト値を用いる場合、 そのデ フォル ト値は、 プリバッファ リ ング必要データ量と して、 例えばバッフ ァサイズの 3分の 2に相当するデータ量を示す。
例えば、 M P E G— 4 V i s u a I の場合には、 V O L ( V i deo Ob j ect Layer) 内にプリバッファ リ ング情報が示されない際には、 規格によ リ決 められたバッファサイズの 3分の 2に相当するデータ量の符号化ビデオ データ をプリバッファ リ ングしてから復号化を開始することが規定され ている。 そこで、 データ送信装置 1 0 0は、 バッファサイズの 3分の 2 に相当するデータ量をデフォルト値と して使用する。
このように本実施の形態のデータ送信装置 1 0 0は、 プリバッファリ ング情報 d 1 0 9を再生パラメータ情報 d 1 1 0に変換し、 データ受信 装置に対して送信するため、 データ受信装置はその変換されたプリバッ ファリング情報 d 1 0 9に基づいて、 R T Pバケツ 卜の適切な復号開始 時間を特定することができる。 その結果、 データ受信装置は、 例えば、 データ送信装置 1 0 0から R T Pにより送信されたビデオデータを途切 れなく再生することができる。
ここで、 M P E G— 4 A V C及び M P E G— 4 V i s u a I のそれ ぞれの場合におけるファイル作成部 1 04の動作について詳細に説明す
。
M P E G— 4 A V Cでは、 ビデオデータのス ト リーム内に、 S E I (Supplemental Enhancement Information) と呼ばれる復号化のための 補助情報を入れることができる。 S E 〖 は、 復号化において直接必要は ないが、 復号化を行う際の手助けとなる情報であり、 例えばプリバッフ ァリング必要時間やランダムアクセスに関する情報を示すことができる 特にプリバッファリング情報を示す S E I は、 Buffering period SEI と呼ばれ、 Buffer ing per iod SEI 直後のピクチャのデータが M P E G - 4 A V Cの復号化バッファに流入開始してから、そのピクチャの復号化 を開始するまでの時間長が格納される。
即ち、 フアイル作成部 1 0 4は、 ス トリームに含まれる Buffering period SEI を参照して、 上述のような s t s pを有する M P 4ファイル を作成する。
例えば、 Buffering period SEI が、 ピクチャ Nの復号化開始までの時 間長と して 1 秒を示し、 復号開始まで時間の算出基準となるレー トが 6 4 0 0 0 b p sである場合について、 以下説明する。
この場合、 6 4 0 0 0 x 1 /8 = 8 0 0 0バイ ト分の M P E G— 4 A V Cのビデオデータを受信してからピクチャ Mの復号化が開始される。 ここで、 8 0 0 0バイ ト分のビデオデータを伝送するために必要な R T Pバケツ 卜の個数は M P 4ファイルのヒン ト トラックを作成する際に決 定されるため、 ファイル作成部 1 0 4は、 8 0 0 0バイ トに、 R T Pパ ケッ トのヘッダのサイズの総和を加算する。 そしてファイル作成部 1 0 4は、 その加算結果を、 プリバッファリング必要データ量 （プリバッフ ァリング情報） と して s t s pに格納する。 例えば、 2 0個の R T Pパ ケッ 卜で 8 0 0 0バイ トのビデオデータが伝送され、 R T Pバケツ 卜の ヘッダサイズが 1 2バイ トとすると、 R T Pパケッ トのヘッダのサイズ の総和は 1 2 X 2 0 = 2 4 0バイ トとなる。 その結果、 8 0 0 0 + 2 4 0 = 8 2 4 0バイ 卜がプリバッファ リ ング必要データ量となる。
なお、 M P E G— 4 A V Cのビデオデータのス ト リームに Buffering period SEI が使用されない場合には、 ファイル作成部 1 0 4は、 ピクチ ャのプリバッファ リ ング情報をス ト リームとは別に取得する。 又は、 フ アイル作成部 1 0 4は、 そのス ト リームに含まれる各ピクチャのサイズ 及び復号化時間などからプリバッファリング情報を算出する。
一方、 M P E G— 4 V i s u a I では、 ビデオデータのス トリームの V O L (Video Object Layer) 内のパラメータが、 V O L直後の V O P (Video Object Plane) データをバッファから引き抜く直前のバッファ 占有量を示す。 即ち、 このバッファ占有量は、 プリバッファ リング必要 データ量を示す。 そこで、 ランダムアクセス可能なピクチャの前に V O Lが配置されていれば、 フアイル作成部 1 0 4は、 その V O L内のパラ メータから、 V O L直後のピクチャに対するプリバッファリング必要デ ータ量 （プリバッファリング情報） を算出する。 以上、 本発明に係るデータ送信装置 1 0 0ついて上記実施の形態を用 いて説明したが、 本発明に係るデータ送信装置 1 0 0はこれらに限定さ れるものではない。
例えば、 本実施の形態では、 図 1 2に示すように、 プリバッファ リ ン グ必要時間を示すプリバッファ リ ング情報のみを s t s p に含めたが、 送信レー トが変化する場合があるため、 そのプリバッファ リ ング必要時 間を導出するための基準と した送信レー トを s t s p 内に格納しても良 い。 また M P 4ファイルの別の場所に格納しても良い。
R T Pバケツ トなどのバケツ トデータがネッ トワーク を介して送信さ れる場合、 ネッ トワークにおける送信レー トは必ずしも一定とならず、 揺らぎが生ずる。 例えば、 データ送信装置 1 0 0が 6 4 0 0 0 b p sの 送信レー トで R T Pパケッ トを送信したと しても、 ネッ トワークが混雑 して く ると、 その送信レー トが 6 0 0 0 0 b p s に下がることがある。 このような状況で R T Pパケッ トを受信したデータ受信装置は、 プリ バッファ リ ング必要時間が 1 秒と して設定されていると、 プリバッファ リ ングに必要なデータ量が 6 4 0 0 0 ビッ トでありながら、 バッファ占 有量が 6 0 0 0 0 ビッ トに達した時点で復号化を開始して しまう。 そこで、 上述のように送信レー トが s t s p に格納されていれば、 デ ータ送信装置 1 0 0はその送信レー トもデータ受信装置に伝えることで データ受信装置に適切なプリバッファ リ ング必要時間を特定させること ができる。
また、 本実施意の形態では、 s t s p にシンクサンプル番号のフィ一 ル ドを設けたが、 これを省いても良い。
また、 本実施の形態では、 R T Pパケッ トの送信レー トを一定にした が、 コ ンテンツが送信されている最中に、 ネッ トワークの輻輳、 又はパ ケッ トロスの発生頻度など伝送路の状況が変化する場合には、 その状況 の変化に応じて R T Pパケッ トの送信レー トを積極的に変化させても良 い。 この場合、 データ送信装置 1 0 0は、 s t s pに格納されているプ リバッファ リ ング情報 D 1 0 9からプリバッファ リ ング必要データ量を 取得し、 送信時の送信レー 卜に応じてプリバッファ リ ング必要時間を計 算する。
例えば、 データ送信装置 1 0 0は、 P L A Y命令によ リ要求されたビ デォデータに対するプリバッファ リ ング情報 d 1 0 9 と して 「プリバッ ファ リ ング必要データ量 1 5 0 0 0バイ ト」 を取得すると、 送信レー ト 6 4 0 0 0 b p s に基づいて、 プリバッファ リ ング必要時間は 1 5 0 0 0 x 8 /6 4 0 0 0 = 1 . 8 7 5秒であると判断する。 と ころが、 データ 送信装置 1 0 0は、 ネッ トワークが混雑しているため、 P L A Y命令に よ り要求されたビデオデータの送信開始時に、 主体的又は必然的に 上 記送信レー トを 6 0 0 0 0 b p s に変更する。 これによ り、 データ送信 装置 1 0 0は、プリバッファ リ ング必要時間が 1 5 0 0 0 X 8 /6 0 0 0 0 = 2. 0秒であると して上記判断を改める。 そして、 データ送信装置 1 0 0は、 P L A Y命令への応答と して、 「プリバッファ リ ング必要時 間 2. 0秒 J を示すプリバッファ リ ング情報 d 1 0 9 を再生パラメータ 情報 d 1 1 0に変換してデータ受信装置に送信する。
ただし、 伝送路においてパケッ トロスが発生したときには、 上述のよ うにデータ受信装置に伝えるプリバッファ リ ング必要時間を単に変更し ただけでは、 データ受信装置側でのバッファのオーバーフロー及びアン ダーフ口一を防ぐことができない場合がある。
例えば、 復号化の開始時には 1 〜 N番目の N個の R T Pバケツ トが必 要と されるにも関わらず、 パケッ トロスの発生によ り、 データ受信装置 は、 データ送信装置 1 0 0から通知されたプリバッファ リ ング必要時間 内において、 1 から N— 2番目の R T Pバケツ ト しか受信しないこ とが ある。 このとき、 データ受信装置がプリバッファリング必要時間を経過 した時点で復号化を開始すると、 N— 1 および N番目の R T Pバケツ ト が不足しているため、 バッファのアンダーフローが発生する。
そこで、 データ送信装置 1 0 0は、 復号化開始までに受信することが 必要な R T Pバケツ トを特定するための情報、例えばシーケンス番号を、 プリバッファ リ ング情報 d 1 0 9と してデータ受信装置に送信しても良 い。 R T Pパケッ トのヘッダには、 シーケンス番号と呼ばれるパケッ ト の識別番号が含まれる。 R T Pバケツ 卜のヘッダに含まれるシーケンス 番号は、 データ送信装置 1 0 0から送信された直前の R T Pパケッ トの ヘッダに含まれるシーケンス番号に 1 を加算した値である。 そこで、 1 番目〜 N番目の R T Pパケッ 卜の受信が復号化開始までに必要な場合、 それらの R T Pバケツ 卜のシーケンス番号を 1 〜 N とすると、 データ送 信装置 1 0 0は、 プリバッファ リ ング情報 d 1 0 9 と して、 シーケンス 番号 1 〜 Nを示す情報をデータ受信装置に伝える。
また、 本実施の形態では、 M P 4ファイルのヒント トラック （ヒン ト トラック用の t r a k ) にプリバッファ リ ング情報 D 1 0 9 を再生制御 情報と して含めたが、 それ以外にも、 ピクチャの復号化を終了 してから 表示するまでの待ち時間を示す情報や、 コンテンツの特定の区間を復号 化する際に必要となるバッファサイズ、 送信時の暗号化に関する情報を 含めてもよい。 さらに、 R T Pパケッ トにおいて符号化データをインタ リーブして送信する場合には、 ( 1 ) インタ リーブの深さを示す情報、 ( 2 ) 1 ピクチャ分のデータの受信開始から終了までにかかる時間、 あ るいは受信開始時刻と復号時刻との差分値などインタ リーブに起因する 遅延時間の情報、 あるいは （ 3 ) インタ リーブして R T Pパケッ ト化さ れた符号化データを受信及び再構成して 1 ピクチャずつ分離するために 必要なバッファのサイズを示す情報など、 データ受信装置におけるデー タ受信、 復号化、 又は表示の際に有効な情報を、 再生制御情報と して含 めても良い。 この場合、 データ送信装置 1 0 0は、 そのような再生制御 情報を M P 4ファイルの t r a kから取得して再生パラメータ情報 d 1 1 0に変換し、 データ受信装置に送信する。
また、 連続する複数の画像から構成されるシーン単位で eデォデータ の復号化処理の初期化に要するシーン初期化情報を、 シーンのインデッ クス番号あるいはシーンの先頭サンプルのサンプル番号などのシーンを 識別するための情報と関連付けて、 再生制御情報と して M P 4ファイル に含めておいても良い。 M P E G— 4 A V Cでは、 シーケンス ' パラ メータセッ ト (Sequence Parameter Set) と ヒクチャ - パラメ一タセッ ト （Picture Parameter Set)がシーン初期化情報に相当する。 この場合、 例えばク リ ップ再生のよ うに異なるシーンの画像を順にデータ受信装置 が要求したときには、 データ送信装置 1 00は要求された各シーンの画 像データ を R T Pバケツ トと して送信すると ともに、 それらに関連する シーン初期化情報を R T S Pの P L A Y応答などに含めて送信するため データ受信装置はシーン初期化情報を用いて各シーンごとに適切に初期 化を行い、 各画像を復号して表示することができる。 なお、 受信を開始 する先頭シーンのシーン初期化情報については、 そのシーン初期化情報 を S D Pに含めることができるため、 P L A Y応答に含めなく てもよい。 また、 ビデオデータに含まれるランダムアクセス可能な画像の周期を 示す画像周期情報を、 再生制御情報と して M P 4ファイルに含めておい ても良い。 この場合、 画像周期情報を受信したデータ受信装置は、 その 画像周期情報に基づいてビデオデータのランダムアクセス可能な部位を 特定することができ、 それらの部位から適切に再生処理を行う ことがで きる。 例えば、 データ受信装置は、 その特定結果から約 3 0秒先の時間 位置の画像にランダムアクセスできるか否かを事前に判別することがで き、 いきなり 5分先の時間位置の画像にラ ダムアクセスしてしまう こ とを防ぐことができる。
また、 本実施の形態では、 R丁 S Pを用いてプリバッファ リ ング情報 d 1 0 9 (再生パラメータ情報 d 1 1 0 ) をデータ受信装置に送信した が、 R T S P以外のプロ トコルを用いて送信しても良い。
また、 本実施の形態では、 ビデオに対応するプリバッファ リ ング情報 D 1 0 9を s t s pに格納したが、ビデオ以外のコンテンツ（メ ディ ア）、 例えばオーディオやテキス トなどに対応するプリバッファ リ ング情報を 格納しても良い。
また、 本実施の形態では、 プリバッファ リ ング情報 D 1 0 9を M P 4 ファイルに多重化するために s t s pを用いたが、 この s t s pは、 M P E G— 2 T S (Transport Stream) など R T P以外の伝送方式におい てパケッ トを作成するための情報を M P 4ファイルに多重化する場合に も使用される。
また、 本実施の形態では、 s t s sによって示されるシンクサンプル に対するプリバッファリング情報のみを s t s pに格納したが、 それ以 外のサンプルに対するプリバッファリング情報も格納しても良い。 例え ば、 シンクサンプル以外の I ピクチャを格納するサンプル、 又は全ての サンプルに対するプリバッファ リ ング情報を s t s pに格納しても良い また、 Recovery Point SEI が付加された I ピクチャを格納するサンプル に対するプリバッファ リ ング情報を s t s pに格納しても良い。
なお、 プリバッファ リ ング情報などの再生制御情報をビデオ トラ ック のへッダ情報に格納してもよい。 例えば、 ビデオ トラックについても s t s pのような B o xを定義することで、 ビデオ トラックのシンクサン プルについてのプリバッファ リ ング情報をその B o X に含めることがで きる。 具体的には、 ヒン ト トラ ックのシンクサンプルから参照される ビ デォ トラックのサンプルは、 シンクサンプルあるいはシンクサンプル以 外のランダムアクセス可能なサンプルであるため、 そのビデオ トラ ック のサンプルについてのプリバッファ リ ング情報をビデオ トラックのへッ ダ情報に格納する。 M P E G— 4 A V Cでは、 Recovery Point SEI を 含むサンプルについてのプリバッファ リ ング情報をヘッダ情報に格納し てもよい。
ここで、 上述の Recovery Point SEI について説明する。
M P E G— 4 A V Cでは、 s t s s によ リ示されるシンクサンプルは、 I D R ( Instantaneous Decoder Refresh) ヒクチャを示す。 I D R ヒク チヤとは、 復号順で I D Rピクチャ以降のピクチャは、 復号順で I D R ピクチャ以前のピクチャを參照せずに復号できるという ピクチャであり、 M P E G— 2における c I o s e d G O Pの先頭 I ピクチャと同様の 特徴をもつ。 M P E G— 4 A V Cでは、 I D Rピクチャ以外にもランダ ムアクセス可能なピクチャがあり、 これらのピクチャは上述の Recovery Point SEI によ リ識別される。
Recovery Point SEI は、 本 S E I 直後のピクチャから復号化を開始し た際に、 何枚のピクチャを復号化すれば元の画像と同等品質のピクチャ が得られるかを示す情報、 又はブローク ンリ ンクの識別情報を含む。 つ ま リ、 Recovery Poi nt SEI が付加された I ピクチャは、 M P E G— 2に おける o p e n — G O Pの先頭 I ピクチャと同様の特徴をもつ。 そこで 上述のように、 Recovery Point SEI が付加された I ピクチャのサンプル に対するプリバッファ リ ング情報も s t s pに格納しても良いのである ( また、 データ送信装置 1 0 0は、 上述の Recovery Point SEI によ り示 される情報を再生制御情報と して扱っても良い。 これによ り、 Recovery Point SEI が付加された I ピクチャから ビデオデータ を受信したデータ 受信装置は、 その受信の事前に取得した再生制御情報によ り、 不完全な 復号画像を表示するか、 正しい復号画像が得られるよ うになつてから表 示を開始するかを選択することができると共に、 正しい復号画像から表 示するために予め復号しておく こどが必要なピクチャの枚数を取得する ことができる。
また、 本実施の形態では、 プリバッファ リ ング情報 D 1 0 9 を M P 4 ファイルの t r a kの s t s pに格納したが、 t r a k又は m o o vの 直下に S D Pデータ と して格納しても良い。 また、 ヒン ト トラックにお けるサンプルの定義を拡張し、 ヒン ト トラックのサンプルと して m d a t にプリバッファ リ ング情報 D 1 0 9 を格納しても良い。
(実施の形態 2 )
以下、 本発明の第 2の実施の形態におけるデータ受信装置について、 図面を参照しながら説明する。
本実施の形態におけるデータ受信装置は、 実施の形態 1 のデータ送信 装置 1 0 0から R T S Pに基づいて受信した再生制御情報 （再生パラメ ータ情報) を用い、 メディア (コ ンテンツ） データの適切な再生を行う。 なお、 このデータ受信装置がメ ディアデータ と して受信するビデオデ ータは、 M P E G— 4 A V Cによ り符号化されたデータであっても、 M P E G— 4 V i s u a I や H . 2 6 3など他の符号化方式のビデオデ一 タであってもよい。
図 1 6は、 本実施の形態におけるデータ受信装置の構成を示すブロ ッ ク図である。
データ受信装置 2 0 0は、 R T P受信処理部 2 0 1 と、 復号部 2 0 2 と、 表示部 2 0 3 と、 R T S P処理部 2 0 4 と、 指示部 2 0 5 とを備え る。
R T S P処理部 2 0 4は、 再生パラメータ情報を含む受信メ ッセージ d 2 0 5 をデータ送信装置 1 0 0から受信すると ともに、 データ送信装 置 1 0 0に送信メ ッセージ d 20 7を送信することによ り、 データ送信 装置 1 0 0との間で R T S Pを用いた再生制御を行う。 ここでは、 再生 パラメータ情報は、 プリバッファ リ ング情報を示すものと して以下説明 する。
R T S P処理部 2 0 4は、 受信メ ッセージ d 2 0 5に含まれるプリバ ッファ リ ング情報を取得すると、 そのプリバッファ リ ング情報からプリ ッ ファ リ ング必要時間を特定する。例えば、 R T S P処理部 2 0 4は、 R T Pバケツ 卜が R T P受信処理部 2 0 1 に受信されると、 その受信開 始から、 プリバッファ リ ング情報に基づいて特定されたプリバッファ リ ング必要時間だけ経過したときに復号化を開始すべきであると判断する さ らに、 R T S P処理部 2 04は、 メディア （コンテンツ） 毎の R T Pバケツ 卜の同期情報を含む R T P制御データ d 2 0 6を R T P受信処 理部 2 0 1 に出力すると ともに、 指示部 2 0 5に対して、 上記プリバッ ファ リ ング必要時間を含む復号化開始情報 d 2 0 9を出力する。
また、 R T S P処理部 2 04は外部命令 d 2 0 8を取得する。 この外 部命令 d 2 0 8は、 データ受信装置 2 0 0のユーザの操作によって生じ る情報であって、 コ ンテンツの受信の開始や終了、 一時停止、 コ ンテン ッ中の特定時間位置へのジャンプなどを指示する内容を示す。
R T P受信処理部 2 0 1 は、 R T Pバケツ ト d 2 0 1 を受信し、 R T Pバケツ ト d 2 0 1 から例えばビデオの符号化データ d 2 0 2を取得し た後、 その符号化データ d 2 0 2を復号部 2 0 2に出力する。 なお、 R T P受信処理部 2 0 1 は、 R T Pバケツ ト d 2 0 1 の受信から符号化デ —タ d 2 0 2の出力までの処理を瞬時に行う。 また、 復号化の開始の対 象となる R T Pバケツ トは、 R T P制御データ d 2 0 6に基づいて決定 される。
また、 R T P受信処理部 2 0 1 は、 R T Pパケッ ト d 2 0 1 の受信を 開始した時点で、 受信開始信号 d 2 1 0を指示部 2 0 5に出力する。 指示部 2 0 5は、 受信開始信号 d 2 1 0および復号化開始情報 d 2 0 9に基づいて復号化を開始するタイミングを決定し、 復号化開始を指示 する開始指示信号 d 2 1 1 を復号部 2 0 2に出力する。
復号部 2 0 2は、 開始指示信号 d 2 1 1 を指示部 2 0 5から取得する と、 符号化データ d 2 0 2の復号化を開始し、 復号化データ d 2 0 3を 表示部 2 0 3に出力する。
即ち、 本実施の形態の復号部 2 0 2は、 R T P受信処理部 2 0 1 に R T Pバケツ ト d 2 0 1 が受信されてからプリバッファリ ング必要時間だ け経過したときに復号処理を開始する。
表示部 2 0 3は、 復号部 2 0 2から復号化データ d 2 0 3 を取得する と、 その復号化データ d 2 0 3の内容を表示する。
図 1 7は、 本実施の形態におけるデータ受信装置 2 0 0の指示部 2 0 5の動作を示すフロー図である。
まず、 指示部 2 0 5は、 R T P受信処理部 2 0 1 から受信開始信号 d 2 1 0 と、 R T S P処理部 2 0 4から復号化開始情報 d 2 0 9 とを取得 する （ステップ S 4 0 1 ) 。 例えば、 受信開始信号 d 2 1 0は、 トラッ ク I D = 1 であるビデオ トラックに関する R T Pバケツ ト d 2 0 1 の受 信が開始されたことを示す。
指示部 2 0 5は、 その受信開始信号 d 2 1 0の受信を トリガーに、 R T Pバケツ ト d 2 0 1 の受信が開始されてからの経過時間を計時する (ステップ S 4 0 2 ) 。
次に、 指示部 2 0 5は、 ステップ S 4 0 2で計時した経過時間が、 復 号化開始情報 d 2 0 9に含まれるプリバッファリング必要時間と等しい か否かを判別する （ステップ S 4 0 3 ) 。 例えば、 R T P受信処理部 2 0 1 に受信された R T Pパケッ ト d 2 0 1 力 トラック I D = 1 のビデオ トラックのデータであって、 R T S Pの P L A Y命令の応答である受信 メ ッセ一ジ d 2 0 5に 「プリバッファ リ ング必要時間 M秒」 としヽぅ プリ バッファ リ ング情報が含まれている場合を想定する。 この場合、 指示部 2 0 5は、 トラック I D = 1 のビデオ トラックの R T Pバケツ 卜 d 2 0 1 が受信開始されてから M秒経過したかどうかを判定する。
指示部 2 0 5は、 プリバッファ リ ング必要時間と等しいと判別 したと きには （ステップ S 4 0 3の Y e s ) 、 開始指示信号 d 2 1 1 を復号部 2 0 2に出力 し （ステップ S 4 0 4 ) 、 プリバッファ リ ング必要時間と 異なると判別したときには (ステップ S 4 0 3の N o ) 、 再びステップ S 4 0 2からの動作を実行する。
以上、 本発明に係るデータ受信装置 2 0 0ついて上記実施の形態を用 いて説明したが、 本発明に係るデータ受信装置 2 0 0はこれらに限定さ れるものではない。
例えば、 本実施の形態では、 R T S Pの P L A Y命令の応答である受 信メ ッセージ d 2 0 5からプリバッファ リ ング情報を取得したが、 R T S Pにおける P L A Y命令以外の既存の命令、 又は新規に規定された命 令に対する応答である受信メ ッセージ d 2 0 5からプリバッファ リ ング 情報を取得しても良い。 また、 R T S P以外のプロ トコルによるメ ッセ ージからプリバッファ リ ング情報を取得しても良い。
また、 本実施の形態では、 プリバッファ リ ング必要時間を示すプリバ ッフア リ ング情報を取得したが、 プリバッファ リ ング必要データ量を示 すプリバッフア リ ング情報を取得しても良い。
この場合、 R T P受信処理部 2 0 1 は、 メディア （コ ンテンツ） ごと に受信した R T Pバケツ ト d 2 0 1 の総データ量を示す総量情報を、 そ のバケツ トを受信するたびに又は一定時間ごとに、 指示部 2 0 5 に対し て出力する。 指示部 2 0 5は、 その総量情報に基づいて、 R T Pバケツ ト d 2 0 1 の総データ量とプリバッファ リ ング必要データ量を比較し、 それらのデータ量が一致したときに、開始指示信号 d 2 1 1 を出力する。 なお、 データ量の比較は、 総量情報を取得するごとに、 又は一定時間ご とに行っても良い。
また、 本実施の形態では、 再生パラメータ情報に変換されたプリバッ ファ リ ング情報を再生制御情報と して取得したが、 受信、 復号化、 又は 表示処理に関連する情報を再生制御情報と して取得しても良い。 この場 合、 指示部 2 0 5又は R T S P処理部 2 0 4は、 取得した情報に基づい て復号部 2 0 2及び表示部 2 0 3 を制御する。
また、 本実施の形態では、 プリバッファ リ ング情報と してプリバッフ ァ リ ング必要時間を取得したが、 シーケンス番号をプリバッファ リ ング 情報と して取得しても良い。 この場合、 データ受信装置 2 0 0は、 取得 したシーケンス番号によ り示される R T Pパケッ トが全て受信されたと きに、 復号化処理を開始する。 データ受信装置 2 0 0は、 R T Pバケツ トを全て受信できなかったときには、 受信できなかった R T Pバケツ ト をデータ送信装置 1 0 0に要求する。または、データ受信装置 2 0 0は、 復号化開始前に、 ユーザに封して警告をした上で、 予め設定された条件 に基づいて復号化を開始する。 この警告は、 復号化処理の途中で発生す るアンダーフロー又はオーバーフローのため、 コ ンテンツの表示が停止 する可能性があることをユーザに知らせるものである。
(実施の形態 3 )
さ らに、 上記各実施の形態で示したデータ送信装置 1 0 0及びデータ 受信装置 2 0 0 を実現するためのプログラムを、 フ レキシブルディ スク 等の記憶媒体に記録するようにすることによ り、 上記各実施の形態で示 した処理を、 独立したコンピュータ システムにおいて簡単に実施するこ とが可能となる。 図 1 8は、 実施の形態 1 ， 2のデータ送信装置 1 0 0及びデータ受信 装置 2 0 0をコ ンピュータ システムによ り実現するためのプログラムを 格納する記憶媒体についての説明図である。
図 1 8中の （ b ) は、 フ レキシブルディスク F Dの正面及び側面から みた外観と、 記録媒体の本体であるディスク本体 F D 1 の正面からみた 外観とを示し、 図 1 8中の （ a ) は、 ディスク本体 F D 1 の物理フォー マツ 卜の例を示している。
ディスク本体 F D 1 はケース F内に内蔵され、 ディスク本体 F D 1 の 表面には、 同心円状に外周からは内周に向かって複数の トラック T 「 が 形成され、各 トラックは角度方向に 1 6のセクタ S e に分割されている。 従って、 上記プログラムを格納したフ レキシブルディスク F Dでは、 上 記ディスク本体 F D 1 上に割り当てられた領域に、 上記プログラムが記 録されている。
また、 図 1 8中の ( c ) は、 フ レキシブルディ スク F Dに上記プログ ラムの記録再生を行うための構成を示す。
上記プログラムをフ レキシブルディスク F Dに記録する場合は、 コ ン ピュータシステム C sが上記プログラムをフ レキシブルディスク ドライ ブ F D Dを介して甞き込む。 また、 フ レキシブルディスク F D内のプロ グラムをコンピュータ システム C s 中に構築する場合は、 フ レキシブル ディスク ドライブ F D Dによ り プログラムがフ レキシブルディスク F D から読み出され、 コ ンピュータシステム C s に転送される。
なお、 上記説明では、 記録媒体と してフ レキシブルディスク F Dを用 いて説明を行ったが、 光ディスクを用いても同様に行う ことができる。 また、 記録媒体はこれに限らず、 I Cカー ド、 R O Mカセッ ト等、 プロ グラムを記録できるものであれば同様に実施することができる。 産業上の利用の可能性
本発明に係るデータ送信装置は、 データ受信装置に対してコンテンッ データの適切な再生処理を実行させることができ、 例えば携帯端末向け の動画像配信サービスに利用されるサーバなどに有用である。

Claims

請 求 の 範 囲 1 . デジタル著作物たるコ ンテンツデータ をファイルから取り出 して 受信装置に対して送信するデータ送信装置であって、
前記ファイルは、 前記コ ンテンツデータ と、 前記コ ンテンツデータの 再生処理に用いられる再生制御情報とを多重化して構成され、
前記データ送信装置は、
前記受信装置との間でコ ンテンツデータの伝送路の確立及び初期化を 行う前置処理手段と、
前記前置処理手段による伝送路の確立及び初期化の後、 前記再生制御 情報の少なく とも一部を前記ファイルから取り出 して、 前記受信装置に 送信する制御送信手段と、
前記ファイルからコンテンツデータの少なく とも一部を取得してパケ ッ ト化するバケツ ト生成手段と、
前記バケツ ト生成手段によ リバケツ 卜化されたコ ンテンッデータの少 なく とも一部を送信するコ ンテンッ送信手段と
を備えることを特徴とするデータ送信装置。
2 . 前記ファイルに多重化された再生制御情報は、 前記コ ンテンツデ ータに含まれる複数のデータ単位ごとに、 当該データ単位からの再生に 用いられる再生制御単位情報を含んでテーブル状に構成され、
前記制御送信手段は、 前記受信装置からの要求に応じたデータ単位に 関連する前記再生制御単位情報を、 前記フアイルの再生制御情報から取 リ出して送信し、
前記パケッ ト生成手段は、 前記受信装置からの要求に応じたデータ単 位からの前記コン亍ンッデータ を取得してバケツ ト化する ことを特徴とする請求の範囲第 1 項記載のデータ送信装置。
3 . 前記再生制御単位情報は、 前記コンテンツ送信手段から送信され て前記受信装置に受信されるコンテンツデータに対して、 復号処理を開 始すべきタイミングを知らせる内容を示す
ことを特徴とする請求の範囲第 2項記載のデータ送信装置。
4 . 前記再生制御単位情報は、前記タイミングを知らせる内容と して、 前記受信装置によるコンテンツデータの受信開始から前記復号処理の開 始までの時間を示す
ことを特徴とする請求の範囲第 3項記載のデータ送信装置。
5 . 前記再生制御単位情報は、前記タィミングを知らせる内容と して、 前記受信装置によって受信されるコンテンツデータのデータ量を示す ことを特徴とする請求の範囲第 3項記載のデータ送信装置。
6 . 前記制御送信手段は、 前記再生制御単位情報の示すデータ量を、 前記受信装置によるコンテンッデータの受信開始から前記復号処理の開 始までの時間に変換し、 前記変換された再生制御単位情報を送信する ことを特徴とする請求の範囲第 5項記載のデータ送信装置。
7 . 前記制御送信手段は、 前記再生制御単位情報を、 前記コンテンツ 送信手段におけるコンテンツデータの伝送状況に応じて変換する
ことを特徴とする請求の範囲第 6項記載のデータ送信装置。
8 . 前記コンテンツ送信手段は、 伝送路の状況に基づいて、 コンテン ッデータの送信速度を変化させる .
ことを特徴とする請求の範囲第 7項記載のデータ送信装置。
9 . 前記コ ンテンツデータは、 複数の画像を含んで構成される動画像 データであって、
前記再生制御情報は、 前記コ ンテンツデータに含まれる全ての画像ご とに、 前記再生制御単位情報を含んで構成されている
ことを特徴とする請求の範囲第 2項記載のデータ送信装置。
1 0 . 前記コ ンテンツデータは、 複数の画像を含んで構成される動画 像データであって、
前記再生制御情報は、 前記コンテンツデータに含まれる画面内符号化 された画像ごとに、 前記再生制御単位情報を含んで構成されている ことを特徴とする請求の範囲第 2項記載のデータ送信装置。
1 1 . 前記コ ンテンツデータは、 複数の画像を含んで構成される動画 像データであって、
前記再生制御単位情報は、 当該データ単位の先頭の画像から正しぃ復 号処理結果が得られるか否かを示す
ことを特徴とする請求の範囲第 2項記載のデータ送信装置。
1 2 . 前記コ ンテンツデータは、 複数の画像を含んで構成される動画 像データであって、
前記再生制御単位情報は、 当該データ単位の先頭の画像から復号処理 が開始された場合に、 最初に正しい復号処理結果が得られる部位を示す ことを特徴とする請求の範囲第 2項記載のデータ送信装置。
1 3 . 前記コンテンツデータは、 連続する複数の画像から構成される シーンを前記データ単位と して含む動画像データであって、
前記再生制御情報は、 前記各シーンを構成する画像を復号化する際の 初期化に要する情報を示す
ことを特徴とする請求の範囲第 2項記載のデータ送信装置。
1 4 . 前記コンテンツデータは、 複数の画像を含んで構成される動画 像テータであって、
前記再生制御情報は、 前記複数の画像のうちのランダムアクセス可能 な画像の周期を示す
ことを特徴とする請求の範囲第 1 項記載のデータ送信装置。
1 5 . 前記ファイルに多重化された再生制御情報は、 前記コンテンツ データに含まれる所定の 1 つのデータ単位からの再生に用いられる再生 制御単位情報であって、
前記制御送信手段は、 前記受信装置からの要求に応じて前記再生制御 単位情報を前記ファイルから取り出して送信し、
前記バケツ ト生成手段は、 前記受信装置からの要求に応じて前記デー タ単位からの前記コンテンツデータを取得してバケツ ト化する
ことを特徴とする請求の範囲第 1 項記載のデータ送信装置。
1 6 . デジタル著作物たるコンテンツデータをファイルから取り出し て受信装置に対して送信するデータ送信方法であって、
前記ファイルは、 前記コンテンツデータと、 前記コンテンツデータの 再生処理に用いられる再生制御情報とを多重化して構成され、 前記データ送信方法は、
前記受信装置との間でコ ンテンツデータの伝送路の確立及び初期化を 行う前置処理ステップと、
前記伝送路の確立及び初期化が行われた後、 前記再生制御情報の少な く とも一部を前記ファイルから取り出 して、 前記受信装置に送信する制 御送信ステップと、
前記ファイルからコンテンツデータの少なく とも一部を取得してパケ ッ 卜化するパケッ ト生成ステップと、 .
前記バケツ ト生成ステップでバケツ ト化されたコ ンテンツデータの少 なく とも一部を送信するコ ンテンツ送信ステップと
を含むことを特徴とするデータ送信方法。
1 7 . 前記ファイルに多重化された再生制御情報は 前記コ ンテンツ データに含まれる複数のデータ単位ごとに、 当該データ単位からの再生 に用いられる再生制御単位情報を含んでテーブル状に構成され、 前記制御送信ステップでは、 前記受信装置からの要求に応じたデータ 単位に関連する前記再生制御単位情報を、 前記フアイルの再生制御情報 から取リ出して送信し、
前記バケツ ト生成ステップでは、 前記受信装置からの要求に応じたデ ータ単位からの前記コ ンテンツデータ を取得してバケツ ト化する
ことを特徴とする請求の範囲第 1 6項記載のデータ送信方法。
1 8 . 前記再生制御単位情報は、 前記コンテンツ送信ステップで送信 されて前記受信装置に蓄積されるコ ンテンツデータに対して、 再生処理 を開始すべきタイ ミ ングを知らせる内容を示す
ことを特徴とする請求の範囲第 1 7項記載のデータ送信方法。
1 9 . デジタル著作物たるコ ンテンツデータ をファイルから取り 出 し て受信装置に対して送信するためのプログラムであって、
前記ファイルは、 前記コ ンテンツデータ と、 前記コンテンツデータの 再生処理に用いられる再生制御情報とを多重化して構成され、
前記データ送信方法は、
前記受信装置との間でコ ンテンッデータの伝送路の確立及び初期化を 行う前置処理ステツプと、
前記伝送路の確立及び初期化が行われた後、 前記再生制御情報の少な く とも一部を前記ファイルから取り出して、 前記受信装置に送信する制 御送信ステツプと、
前記ファイルからコンテンツデータの少なく とも一部を取得してパケ ッ ト化するパケッ ト生成ステップと、
前記バケツ ト生成ステップでバケツ ト化されたコンテンツデータの少 なく と も一部を送信するコ ンテンツ送信ステップと
をコ ンピュータに実行させることを特徴とするプログラム。
PCT/JP2004/004018 2003-03-25 2004-03-24 データ送信装置 WO2004086765A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/534,546 US20060059245A1 (en) 2003-03-25 2004-03-24 Data transmission device
EP04722977A EP1566966A4 (en) 2003-03-25 2004-03-24 DATA TRANSMISSION DEVICE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2003083681 2003-03-25
JP2003-083681 2003-03-25

Publications (1)

Publication Number Publication Date
WO2004086765A1 true WO2004086765A1 (ja) 2004-10-07

Family

ID=33094966

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/004018 WO2004086765A1 (ja) 2003-03-25 2004-03-24 データ送信装置

Country Status (5)

Country Link
US (1) US20060059245A1 (ja)
EP (1) EP1566966A4 (ja)
KR (1) KR20060011937A (ja)
CN (1) CN1765130A (ja)
WO (1) WO2004086765A1 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060239563A1 (en) * 2005-04-25 2006-10-26 Nokia Corporation Method and device for compressed domain video editing
EP1954054A1 (en) * 2007-02-02 2008-08-06 Thomson Licensing System and method for transporting interactive marks
US20110238785A1 (en) * 2008-12-18 2011-09-29 Kazunori Ozawa Multimedia providing service
KR101802273B1 (ko) * 2010-03-05 2017-11-28 삼성전자주식회사 복수 개의 스트림으로 구성된 컨텐츠 파일 송수신 장치 및 방법
KR101705813B1 (ko) 2010-06-23 2017-02-10 삼성전자주식회사 무선 통신 시스템에서 멀티미디어 컨텐츠의 랜덤 액세스 방법 및 장치
WO2013165215A1 (ko) * 2012-05-04 2013-11-07 엘지전자 주식회사 영상 정보 저장 방법 및 영상 정보 파싱 방법 그리고 이를 이용하는 장치
WO2014010894A1 (ko) 2012-07-11 2014-01-16 한국전자통신연구원 Mpeg 데이터의 랜덤 억세스를 지원하는 방법 및 시스템
KR102185384B1 (ko) 2012-07-11 2020-12-02 한국전자통신연구원 Mpeg 데이터의 랜덤 억세스를 지원하는 방법 및 시스템
US9413787B2 (en) * 2012-08-06 2016-08-09 Blackberry Limited Real-time delivery of location/orientation data
CN105359536B (zh) * 2013-07-17 2020-07-24 索尼公司 内容供给装置及方法、终端装置、以及内容供给系统
JP6498882B2 (ja) * 2013-07-22 2019-04-10 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 蓄積方法、再生方法、蓄積装置、および再生装置
US10547701B2 (en) * 2014-09-12 2020-01-28 Sony Corporation Transmission device, transmission method, reception device, and a reception method
US9984653B1 (en) * 2015-02-11 2018-05-29 Synaptics Incorporated Method and device for reducing video latency

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197120A (ja) * 2000-07-17 2001-07-19 Apple Computer Inc メディア・データ伝送のための方法および装置
JP2003087786A (ja) * 2001-06-29 2003-03-20 Matsushita Electric Ind Co Ltd データ再生装置、及びデータ再生方法
JP2003289526A (ja) * 2002-03-28 2003-10-10 Toshiba Corp 映像受信端末装置およびその再生制御方法
JP2004040329A (ja) * 2002-07-01 2004-02-05 Toshiba Corp 多重化分離装置及びその方法並びに多重化装置及びその方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6134243A (en) * 1998-01-15 2000-10-17 Apple Computer, Inc. Method and apparatus for media data transmission
EP1182875A3 (en) * 2000-07-06 2003-11-26 Matsushita Electric Industrial Co., Ltd. Streaming method and corresponding system
CN1253809C (zh) * 2001-06-29 2006-04-26 松下电器产业株式会社 数据重放装置及数据重放方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001197120A (ja) * 2000-07-17 2001-07-19 Apple Computer Inc メディア・データ伝送のための方法および装置
JP2003087786A (ja) * 2001-06-29 2003-03-20 Matsushita Electric Ind Co Ltd データ再生装置、及びデータ再生方法
JP2003289526A (ja) * 2002-03-28 2003-10-10 Toshiba Corp 映像受信端末装置およびその再生制御方法
JP2004040329A (ja) * 2002-07-01 2004-02-05 Toshiba Corp 多重化分離装置及びその方法並びに多重化装置及びその方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1566966A4 *

Also Published As

Publication number Publication date
KR20060011937A (ko) 2006-02-06
EP1566966A4 (en) 2007-02-28
EP1566966A1 (en) 2005-08-24
US20060059245A1 (en) 2006-03-16
CN1765130A (zh) 2006-04-26

Similar Documents

Publication Publication Date Title
JP7506219B2 (ja) 再生方法および再生装置
CN111656796B (zh) 动态条件性广告插入
US10397295B2 (en) Processing continuous multi-period content
AU2016226206B2 (en) File format based streaming with dash formats based on LCT
KR102168596B1 (ko) 저 레이턴시 비디오 스트리밍
US9591361B2 (en) Streaming of multimedia data from multiple sources
TW201947938A (zh) 用於在一片段中之網路串流之媒體資料之發信丟失區段
KR20160110424A (ko) Dash의 강건한 라이브 동작
WO2004086765A1 (ja) データ送信装置
KR20230030589A (ko) 스위칭 세트들을 갖는 어드레스가능한 리소스 인덱스 트랙을 포함하는 미디어 데이터의 스트리밍
CN112771876B (zh) 检索媒体数据的方法和设备以及发送媒体数据的方法和设备
JP2004312713A (ja) データ送信装置
US20240357213A1 (en) Dynamic conditional advertisement insertion
KR20180120169A (ko) 송신 장치, 송신 방법, 수신 장치 및 수신 방법
KR20120058373A (ko) Ｓｖｃ 서버를 이용한 ｈｔｔｐ 스트리밍 수신 비디오 전송 및 단말 재생 시스템

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004722977

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2006059245

Country of ref document: US

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 10534546

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 1020057010876

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2004722977

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 20048082631

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 1020057010876

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 10534546

Country of ref document: US

WWW Wipo information: withdrawn in national office

Ref document number: 2004722977

Country of ref document: EP