WO2015002500A1 - 실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 방송 신호의 송수신 방법 및 장치 - Google Patents

실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 방송 신호의 송수신 방법 및 장치 Download PDF

Info

Publication number
WO2015002500A1
WO2015002500A1 PCT/KR2014/006011 KR2014006011W WO2015002500A1 WO 2015002500 A1 WO2015002500 A1 WO 2015002500A1 KR 2014006011 W KR2014006011 W KR 2014006011W WO 2015002500 A1 WO2015002500 A1 WO 2015002500A1
Authority
WO
WIPO (PCT)
Prior art keywords
mff
media
file
packet
data
Prior art date
Application number
PCT/KR2014/006011
Other languages
English (en)
French (fr)
Inventor
박정욱
문경수
권우석
오세진
Original Assignee
엘지전자 주식회사
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 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to KR1020157037197A priority Critical patent/KR20160030133A/ko
Priority to US14/902,781 priority patent/US20160173556A1/en
Priority to CA2917290A priority patent/CA2917290C/en
Publication of WO2015002500A1 publication Critical patent/WO2015002500A1/ko

Links

Images

Classifications

    • 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/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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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/23614—Multiplexing of additional data 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/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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary 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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data 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/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, rendering scenes according to MPEG-4 scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 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/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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/68—Systems specially adapted for using specific information, e.g. geographical or meteorological information
    • H04H60/73—Systems specially adapted for using specific information, e.g. geographical or meteorological information using meta-information

Definitions

  • the present invention relates to a method and / or apparatus for transmitting and receiving a media broadcast signal in a broadcast system. More specifically, the present invention relates to a method and / or apparatus for transmitting and receiving a media broadcast signal in a broadcast system based on a real time transport protocol.
  • a real-time transmission protocol is used, which is a protocol used for transmitting media such as audio and video.
  • the media packet by the real time transmission protocol is simply configured so that the packet can be processed quickly at the reception and is designed for real time playback. It is also designed to enable multicasting.
  • the real-time transfer protocol cannot communicate with the sender and the receiver such as re-request for a lost packet, such as Hyper Text Transfer Protocol (HTTP). Therefore, there is a difficulty in transferring a Media File Format (MFF) file suitable for a media format for a storage medium.
  • MFF Media File Format
  • the Media File Format is composed of data units called boxes.
  • the boxes are referred to as ftyp, moov, and mdat, and the metadata and media data are divided to form a hierarchical form.
  • the metadata mainly includes information such as the brand name of the file and the time of division, decoding and playback of the actual media information.
  • the media data includes actual media data to be processed by the decoder.
  • the receiver In the case of a media file format (MFF) file, the receiver must receive not only metadata but also media data to play the media.
  • the real-time transmission protocol has a characteristic that the data should be played at the same time as the reception of the data, and the media file format (MFF) file has the characteristic that playback can be performed when all the data related to the playback are completed. Therefore, when using a real-time transmission protocol to transmit a Media File Format (MFF) file in real time, there are difficulties due to the above characteristics.
  • MFF Media File Format
  • the receiver has no way of recognizing whether the file transmitted at the packet level is an MFF file, and thus there is a problem in receiving and playing the file in real time.
  • An object of the present invention is to solve the above problems, and to provide a method and / or apparatus for transmitting and receiving a media file format file based on a real-time transmission protocol.
  • an object of the present invention is to provide signaling information suitable for transmission of a media file format file based on a real time transport protocol.
  • an object of the present invention is to provide a method for distinguishing that data transmitted on a real-time transmission protocol is a media file format (MFF).
  • MFF media file format
  • an apparatus for receiving a media broadcast signal includes a receiver for receiving a packet by a protocol for real-time transmission, wherein the payload of the packet includes a media file format (MFF) file divided according to a data type.
  • MFF media file format
  • the segmented media file format (MFF) file includes an initial partial MFF file that includes metadata having full playback information and initial playback information and metadata having media data and partial playback information related to the media data.
  • the header of the packet is a media file identifying whether the divided media file format (MFF) file included in a payload is an initial part MFF file or a media part MFF file.
  • MFF Includes format (MFF) type information, analyzes media file format (MFF) files, A parsing unit for classifying the dear data and extracting information for reproduction, a decoder for decoding the media file format (MFF) file output from the parsing unit, and a media file format (MFF) decoded using the information extracted at the parsing unit. ) A playback unit for playing the file.
  • the media broadcast signal receiving apparatus controls the initial partial MFF file to be stored in a buffer when receiving a packet including a buffer for storing data included in the payload of the received packet and an initial partial MFF file.
  • the media broadcast signal receiving apparatus controls the initial partial MFF file to be stored in a buffer when receiving a packet including a buffer for storing data included in the payload of the received packet and an initial partial MFF file.
  • the media partial MFF file is output to the parser along with the initial partial MFF file stored in the buffer. If not stored in the buffer is characterized in that it further comprises a control unit for controlling the receiving unit to receive a new packet.
  • the header of the packet includes payload type information indicating a format of data included in a payload, and the payload type information indicates that the data included in the payload is a media file format (MFF). It is characterized by identifying that.
  • MFF media file format
  • the header of the packet further includes timestamp information indicating a starting point at which a media file format (MFF) file included in a payload is played, and the packet including the initial partial MFF file is the media partial MFF file. And has timestamp information equal to or faster than the included packet.
  • MFF media file format
  • the packet including the initial partial MFF file is continuously received periodically.
  • the protocol for real-time transmission is characterized in that it comprises a Real time Transport Protocol (RTP).
  • RTP Real time Transport Protocol
  • the media file format includes an ISO Base Media File Format (ISOBMFF).
  • ISOBMFF ISO Base Media File Format
  • a method for transmitting a media broadcast signal includes encoding media data including audio data and / or video data in a media file format (MFF), the encoded media file.
  • Dividing the file into a file, generating a packet including the divided media file format (MFF) file according to a protocol for real-time transmission, wherein a header of the generated packet is included in a payload File Format (MFF) Identifies whether the file is an initial partial MFF file or a media partial MFF file. It includes a media file format (MFF) type information, and transmitting the packet the generated.
  • MFF media file format
  • the header of the generated packet includes payload type information indicating a format of data included in a payload, and the payload type information identifies that the data included in the payload is a media file format (MFF). Characterized in that.
  • MFF media file format
  • the header of the generated packet further includes timestamp information indicating a starting point at which a media file format (MFF) file included in a payload is played, and the packet including the initial portion MFF file is the media portion. Characterized in that the MFF file has the same or faster time stamp information than the packet included.
  • MFF media file format
  • the packet including the initial partial MFF file is continuously transmitted periodically.
  • the protocol for real-time transmission is characterized in that it comprises a Real time Transport Protocol (RTP).
  • RTP Real time Transport Protocol
  • the media file format includes an ISO Base Media File Format (ISOBMFF).
  • ISOBMFF ISO Base Media File Format
  • a media file format (MFF) file can be transmitted in real time in a broadcasting system based on a real time transmission protocol.
  • a media file format (MFF) file can be received and played in real time in a broadcasting system based on a real time transmission protocol.
  • MFF media file format
  • RTP real time transport protocol
  • MFF media file format
  • FIG. 3 is a diagram illustrating an apparatus for receiving a media broadcast signal for reproducing a media file format (MFF) file in a stream format using a real-time transport protocol according to an embodiment of the present invention.
  • MFF media file format
  • FIG. 4 is a diagram illustrating a syntax of a fixed header of a real time transport protocol packet according to an embodiment of the present invention.
  • FIG. 5 is a diagram illustrating payload type information used in a real time transport protocol according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating a syntax including media file format (MFF) type information (MFF type) in an extension header of a real-time transport protocol packet according to an embodiment of the present invention.
  • MFF media file format
  • MFF type media file format information
  • MFF Type media file format type information
  • FIG. 8 is a diagram showing the structure of a Completed MFF according to an embodiment of the present invention.
  • FIG. 9 is a diagram showing the structure of an Initial Partial MFF according to an embodiment of the present invention.
  • FIG. 10 is a diagram showing the structure of a Media Partial MFF according to an embodiment of the present invention.
  • FIG. 11 is a diagram illustrating a data processing process in a receiving apparatus when an MFF file is divided and transmitted according to data types according to an embodiment of the present invention.
  • FIG. 12 is a diagram illustrating a syntax including fragment indicator information in an extension header of a real-time transport protocol packet according to an embodiment of the present invention.
  • FIG. 13 is a diagram illustrating fragment indicator value and meaning according to an embodiment of the present invention.
  • FIG. 14 is a diagram illustrating a data processing process in a receiving apparatus when an MFF file is divided and transmitted according to a data type and a data size according to an embodiment of the present invention.
  • 15 is a diagram illustrating a header of an RTP packet including a completed MFF according to an embodiment of the present invention.
  • 16 is a diagram illustrating a header of an RTP packet when an MFF file is divided into an Initial Partial MFF file and a Media Partial MFF file and transmitted through an RTP packet according to an embodiment of the present invention.
  • 17 is a diagram illustrating the structure of an RTP packet and a Completed MFF when a Completed MFF is included in a payload of the RTP packet and transmitted according to an embodiment of the present invention.
  • FIG. 18 is a diagram illustrating the structure of an RTP packet and an Initial Partial MFF when an Initial Partial MFF is included and transmitted in a payload of the RTP packet according to an embodiment of the present invention.
  • FIG. 19 illustrates a structure of an RTP packet and a Media Partial MFF when a Media Partial MFF is included in a payload of the RTP packet and transmitted according to an embodiment of the present invention.
  • FIG. 20 is a diagram illustrating a header of an RTP packet when an MFF file is divided according to data type and data size and transmitted through an RTP packet according to an embodiment of the present invention.
  • 21 is a diagram illustrating an operation flow of a hybrid broadcast service receiving apparatus based on interworking of a terrestrial broadcasting network and an internet protocol network according to an embodiment of the present invention.
  • 22 is a flowchart illustrating a method of transmitting a media broadcast signal according to an embodiment of the present invention.
  • MFF Media File Format
  • MP4 MPEG-4
  • 3GP 3GPP file format
  • ASF Advanced Streaming Format
  • WMV Windows Media Video
  • ISO Base Media File Format ISO Base Media File Format
  • ISO Base Media File Format defines a general structure for time-based multimedia files such as audio and video, and can be used as the basic structure for other media file formats such as MP4 or 3GP.
  • Payload Type may be called payload type information.
  • the MFF Type may be referred to as media file format (MFF) type information.
  • Fragment Indicator may be referred to as fragment indicator information.
  • Timestamp may be named time stamp information.
  • the Initial Partial MFF may be called an Initial Partial MFF File or an Initial Partial MFF File.
  • the Media Partial MFF may be called a Media Partial MFF File or a Media Partial MFF File.
  • the real-time transport protocol is a protocol for streaming video or audio in real time as a real time transport protocol (RTP), RTCP (RTP Control Protocol), Real Time Streaming Protocol (RTSP), RTMP (Real Time Messaging Protocol) may be applicable.
  • RTP real time transport protocol
  • RTCP RTP Control Protocol
  • RTSP Real Time Streaming Protocol
  • RTMP Real Time Messaging Protocol
  • RTP real time transport protocol
  • the Real Time Transport Protocol (RTP) protocol is a protocol for transporting media such as audio and video.
  • the header of the RTP packet is relatively simplified so that the receiver can process the packet quickly.
  • information necessary for media playback such as a sequence number and a timestamp can be defined to be designed for real-time playback.
  • multicasting is possible, so that multiple receivers can simultaneously receive information from one sender.
  • the header of the RTP packet includes an extension header (Extension Type) to prepare for future scalability of services.
  • HTTP Hyper Text Transfer Protocol
  • V Version
  • P Policy
  • X Extension
  • CC CSRC Count
  • M Marker
  • PT Payment Type
  • Sequence Number TimeStamp
  • SSRC Identifier Synchronization Source Identifier
  • CSRC Identifier Constributing Source Identifier
  • Extension Type Length, Reserved and / or Classifier.
  • V (Version) represents the version of the protocol.
  • P (Padding) indicates whether a padding byte exists. If this field is set, padding bytes are included at the end of the RTP packet. These padding bytes are used for encryption algorithms or to match packet length.
  • Extension indicates whether an extension header exists between the fixed header and the payload.
  • CSRC Count indicates how many CSRC identifiers are included after the fixed header.
  • M Marker is used to mark the frame boundary of the media.
  • Payload Type indicates the type of payload. It can indicate the encoding type of audio or video.
  • Sequence Number indicates the sequence number of the packet. Increment by 1 for every RTP packet sent. The receiver can detect packet loss and restore packet order through this field. The initial value of Sequence Number should be set randomly.
  • TimeStamp represents the first sampling point of an RTP data packet.
  • the recipient can use this field to enable synchronous playback of the received media.
  • SSRC Identifier (Syncrhronization Source Identifier) identifies the source of the RTP stream.
  • a CSRC Identifier (Contributing Source Identifier) identifies the sources that make up the media contained in the packet.
  • MFF media file format
  • the MFF is composed of data units called boxes.
  • the boxes are called ftyp, moov, and mdat, and the MFF consists of hierarchical forms of metadata and media data.
  • the metadata may mainly include information such as the brand name of the file and the time of division, decoding, and playback of the actual media information.
  • the media data may include actual media data to be processed at the decoder. In this case, the receiver must receive not only the metadata but also the media data to play the media.
  • the MFF may include a file type box (ftyp), a moov (movie box), and / or a media data box (mdat).
  • ftyp is a box indicating file type and file compatibility and may be referred to as a file type box.
  • moov is a box for storing all metadata related to media data and may be referred to as a movie box.
  • moov (movie box) may include mvhd (movie header box) and / or trak (track box), and trak (track box) may include tkhd (trak header box) and / or mdia (media box) have.
  • mvhd (movie header box) is a box indicating a movie header.
  • trak (track box) is a box representing each track or stream.
  • a track header box (tkhd) is a box containing general information about a track and may be referred to as a track header box.
  • mdia (media box) is a box indicating information about media data in a track.
  • mdat (media data box) is a box for storing actual media data and may be referred to as a media data box.
  • FIG. 3 is a diagram illustrating an apparatus for receiving a media broadcast signal for reproducing a media file format (MFF) file in a stream format using a real-time transport protocol according to an embodiment of the present invention.
  • MFF media file format
  • An apparatus for receiving media broadcast signals includes a server (Server) 3010, a receiver (RTP Receiving) 3020, a buffer (RTP buffer 3030), a controller 3040, a parser (MFF Parser; 3050). , A decoder 3060 and / or a renderer 3070.
  • Server 3010 indicates a location where an MFF file to be received is stored.
  • the reception unit (RTP Receiving) 3020 may receive a packet by the real-time transmission protocol from the server 3010.
  • a buffer (RTP buffer) 3030 may analyze the packets received by the receiver 3020 to analyze the order of the received packets, the reproduction time of the data, and the required buffer amount, and store the payload data in the buffer.
  • the controller 3040 may analyze the payload type information included in the header of the received packet and, when the payload type is MFF, may control to output the payload data stored in the buffer 3030 to the parser 3050. .
  • the controller 3040 checks the media file format type information (MFF Type) value of the packet of data stored in the buffer 3030, and if the value is "00". The control may be determined to be a completed MFF and output to the parser 3050.
  • the controller 3040 may check the value of the media file format type information (MFF Type) of the stored packet and determine whether the playback is possible when the value is not "00".
  • the controller 3040 checks the fragment indicator information of the packet, and when receiving the packets "01" and "11", the controller 3040 receives the packets from the beginning to the end of the divided data.
  • the packet may be controlled to be outputted to a packet, and the packet may be continuously received until a packet having a fragment indicator information value of “11” is received.
  • the controller 3040 may check the media file format type information (MFF Type) value of the stored packet and, if the value is “01”, control the initial partial MFF file (Initial Partial MFF) included in the packet to be stored in a buffer. Can be.
  • MFF Type media file format type information
  • the control unit checks the value of the media file format type information (MFF Type) of the stored packet, and if the value is "10", that is, if the received file included in the packet is a media partial MFF file, the initial part first. Check if the MFF file (Initial Partial MFF) is stored in the buffer, and if it is stored in the buffer, control the media partial MFF file to be output to the parser 3050 along with the initial partial MFF file stored in the buffer. If it is not stored in the buffer, the receiver 3020 may control to receive a new packet. Detailed description of the above-described Completed MFF, Initial Partial MFF File, and Media Partial MFF File will be described later.
  • MFF Type media file format type information
  • the parser (MFF Parser) 3050 may analyze the MFF file to extract metadata and media data to extract other information necessary for playback.
  • the decoder 3060 may receive the media information from the parser 3050 at each decoding time point and decode the received data with reference to the media information.
  • the renderer 3070 may perform a function of reproducing data decoded from the decoder 3060 for each reproduction time extracted by the parser 3050.
  • FIG. 4 is a diagram illustrating a syntax of a fixed header of a real time transport protocol packet according to an embodiment of the present invention.
  • the fixed header of the real-time transport protocol packet may include a Version field, a Padding field, an eXtension field, a CSRC Count field, a Marker field, a Payload Type field, a Sequence Number field, a Timestamp field, an SSRC field, and / or a CSRC. May contain fields.
  • the Version field indicates the version of RTP, which is fixed at 2.
  • the Padding field indicates whether padding bytes exist. If this field is set, padding bytes are included at the end of the RTP packet. These padding bytes are used for encryption algorithms or to match packet length.
  • the eXtension field indicates whether an extension header exists between the fixed header and the payload.
  • 1 is indicated for additional information required for transmission of an ISO Base Media File Format file.
  • the CSRC count field indicates how many CSRC identifiers are included after the fixed header.
  • Marker fields are interpreted differently depending on the profile and are used to mark important events such as frame boundaries.
  • the payload type field indicates a format of data to be transmitted by a packet.
  • the information can be used to determine the type of data at the packet end to prepare for decryption.
  • the payload type used for RTP is defined in RFC 3551 and described as shown in FIG. 5.
  • a payload type value "71" is temporarily defined as a packet type for transmitting an MFF file, but may be defined as a value of "35 to 71" or "77 to 127".
  • the Sequence Number field is information indicating the order of packets to be transmitted.
  • the starting point starts with an arbitrary number.
  • Each packet is incremented by one.
  • the Timestamp field indicates when the packet is sampled.
  • the value of this field tells the timing at which payload data of this packet should be reproduced. According to the data described in the payload, the value of the time unit information is changed. In one embodiment of the present invention, the start point of the playback of the MFF file is shown.
  • the SSRC field is used to distinguish each media stream source that is received. Multiple media can be streamed simultaneously in a session and use the value of this field to distinguish them. In one session, different media sources should have different SSEC values. In addition, the SSRC field is used as a data separator for synchronization, and this value may be arbitrarily generated.
  • the CSRC field is used as a separator for the transport contributor. This value is randomly generated and can have up to 15 values.
  • the payload field contains data bytes encoded in MFF.
  • the MFF included in the payload is based on the premise that the Mandatory Box is included, and the Optional Box may be further included as needed to provide expandability to the MFF.
  • FIG. 5 is a diagram illustrating payload type information used in a real time transport protocol according to an embodiment of the present invention.
  • PT indicates a value of a payload type
  • an Encoding Name indicates an encoding type of data included in the payload.
  • a / V indicates whether the data is audio or video.
  • payload type information "71” is defined as a value for the transmission of the MFF file, but may be defined as a value of "35 to 71" or "77 to 127".
  • the value of payload type of the existing RTP protocol is not defined for the MFF, so the existing receiver could not recognize the format when the MFF was transmitted at the RTP packet level.
  • the receiver may distinguish data at the delivered RTP packet level. Accordingly, the receiver can increase the efficiency for data processing.
  • the payload type information may identify that data included in the payload is a media file format (MFF).
  • MFF media file format
  • FIG. 6 is a diagram illustrating a syntax including media file format (MFF) type information (MFF type) in an extension header of a real-time transport protocol packet according to an embodiment of the present invention.
  • MFF media file format
  • MFF type media file format information
  • the real time transport protocol packet may be extended to divide and transmit the MFF file according to the data type.
  • the real-time transport protocol packet may include an RTP fixed time header, a real time transport protocol extension header, and a payload.
  • a timestamp field may be included in the RTP fixed header, and media file format type information (MFF Type) may be included in the RTP extension header.
  • MFF Type media file format type information
  • the Timestamp field indicates when the packet is sampled.
  • the value of this field tells the timing at which payload data of this packet should be reproduced. According to the data described in the payload, the value of the time unit information is changed. In one embodiment of the present invention, the start point of the playback of the MFF file is shown. When the MFF file is divided and transmitted, all packets including the divided data may have the same Timestamp value.
  • the MFF Type field is information for identifying a transmitted MFF file. Through this field, the receiver may analyze whether it is possible to independently play only the corresponding packet, or if the receiver can be played with other data packets. The meaning of the value of this field will be described later.
  • the receiver when the MFF file is divided and transmitted according to the type of data, the receiver may distinguish the packet through the MFF Type field included in the extension header of the RTP packet.
  • the MFF is a complete MFF that can be played independently in its own format, but only the Initial Partial MFF, including metadata with full play information and initial play information, and metadata and media data with partial play information related to media data.
  • Media Partial MFF including may be divided and transmitted.
  • Track identifying information and other common metadata may be included in the Initial Partial MFF and periodically transmitted by the sender.
  • metadata such as information on a sample (video frame) boundary of each corresponding time point and decoding time information and actual media data may be included in the Media Partial MFF and sequentially transmitted.
  • MFF Type media file format type information
  • Complete MFF may mean a file that can be independently played by itself, including all metadata and media data.
  • the initial partial MFF file may refer to a file including metadata having full reproduction information about the media file and initial reproduction information.
  • the media partial MFF file may refer to a file including media data and metadata having partial reproduction information related to the media data.
  • the value "11" of the MFF Type means a reserved value.
  • FIG. 8 is a diagram showing the structure of a Completed MFF according to an embodiment of the present invention.
  • Complete MFF is inserted and transmitted in the RTP payload, and includes all metadata and media data necessary for playback, so that media playback can be performed independently.
  • the Complete MFF according to an embodiment of the present invention has the same structure as the undivided media file format (MFF). Therefore, the detailed description of the drawings is replaced with the description of the drawings showing the structure of the above-described media file format (MFF).
  • FIG. 9 is a diagram showing the structure of an Initial Partial MFF according to an embodiment of the present invention.
  • Initial Partial MFF is composed of a common Mandatory box representing the entire media play information and metadata containing the overall initial play related information.
  • the information included in the Initial Partial MFF may be analyzed by the parser 3050 of the apparatus for receiving a media broadcast signal according to an embodiment of the present invention.
  • the Initial Partial MFF file must be sent periodically to the receiver so that the receiver can prepare for media playback.
  • FIG. 10 is a diagram showing the structure of a Media Partial MFF according to an embodiment of the present invention.
  • Media Partial MFF may include metadata having divided media data and partial reproduction information related to the media data.
  • Media data transmitted in Media Partial MFF can be played after receiving Initial Partial MFF.
  • Media data transmitted by RTP according to an embodiment of the present invention can be played back only when both Initial Partial MFF and Media Partial MFF are received. If only one of Initial Partial MFF and Media Partial MFF is received, media playback is not possible.
  • Media Partial MFF may include a styp (segment type box), sidx (segment index box), moof (movie fragment box) and / or mdat (media data box).
  • styp is a box that indicates the file type and file compatibility of a media segment.
  • sidx is a box that indexes each media segment.
  • the sidx box may include other information such as track information, divided sequence numbers, and total length of divided media.
  • moof is a box indicating which media samples are included in an mdat box to be described later.
  • the moof (movie fragment box) may include mfhd and / or traf, and the traf (track fragment box) may include tfhd (movie fragment header box) and / or trun (track fragment run box).
  • mfhd (movie fragment header box) is a box indicating a movie fragment header.
  • the traf (track fragment box) is a box containing metadata associated with each track fragment.
  • tfhd is a box indicating a track fragment header.
  • a track fragment run box (trun) indicates a track fragment run, and traf may include zero or more truns.
  • the receiver may know information such as the boundary of the sample of the mdat box and the number of reproduction time samples through the trun box.
  • mdat (media data box) is a box for storing actual media data.
  • FIG. 11 is a diagram illustrating a data processing process in a receiving apparatus when an MFF file is divided and transmitted according to data types according to an embodiment of the present invention.
  • the process of processing data at the receiving device is the same as a value indicating that the payload type of the RTP packet is MFF (S11010).
  • Step (S11020) if the payload type is not a value indicating that the MFF step of processing data of the payload according to the existing RTP standard recommendation method (S11110), if the payload type is a value indicating that the MFF type is "MFF" Checking whether it is 00 "(S11030), checking whether the MFF Type is" 01 "(S11040), if the MFF Type is" 01 ", storing the corresponding packet in the RTP buffer (S11050), and the MFF Type is" 01 ".
  • MFF Type is "10” (S11060). If the MFF Type is "10”, check whether the MFF Type is "10" in the RTP buffer. Is "00" or MFF Type is "10” and the RTP server was Analyzing the MFF included in the packet (S11080), decoding the MFF (S11090), and / or reproducing the MFF (S11100) when a packet having an MFF Type of "01" is stored in the packet. can do.
  • the receiving device receiving the RTP packet may check the version, extension, CSRC number, packet order, data reproduction time, SSRC and / or CSRC by performing a general RTP analysis (S11010).
  • S11010 a general RTP analysis
  • the payload type of the RTP packet is the same as the value indicating that the MFF, follow the processing method of the MFF file according to an embodiment of the present invention (S11020)
  • the payload type is not a value indicating that the MFF
  • the payload data may be processed according to the recommended method (S11110).
  • the MFF type included in the extension header of the RTP packet according to an embodiment of the present invention can be checked (S11030).
  • the payload may be immediately transmitted to a parser (MFF Parser) 3050 to perform decoding and reproduction (S11080, S11090, and S11100).
  • MFF Parser MFF Parser
  • the MFF Type is "01" (S11040)
  • the Payload is an Initial Partial MFF, and stores a new RTP packet by storing it in a buffer until a packet having a value of the MFF Type is "01". (S11050).
  • the MFF Type of the first received RTP packet is not "00" and "01"
  • the receiver receives a new packet.
  • MFF Type is "10" (S11060)
  • S11070 it is determined whether a conventional RTP packet having an MFF Type value of "01" has been received (S11070), and a packet having a MFF Type of "10” and a packet of "01". If all exist, parsing, decoding, and reproducing of the packets stored in the buffer are performed (S11080, S11090, and S11100).
  • FIG. 12 is a diagram illustrating a syntax including fragment indicator information in an extension header of a real-time transport protocol packet according to an embodiment of the present invention.
  • the MFF file may be divided and transmitted according to a data size by extending a real-time transport protocol packet.
  • the real-time transport protocol packet may include an RTP fixed time header, a real time transport protocol extension header, and a payload.
  • a timestamp field may be included in the RTP fixed header, and media file format type information (MFF Type) and fragment indicator information (Fragment Indicator) may be included in the RTP extension header.
  • MFF Type media file format type information
  • Frament Indicator fragment indicator information
  • the Timestamp field indicates when the packet is sampled.
  • the value of this field tells the timing at which payload data of this packet should be reproduced. According to the data described in the payload, the value of the time unit information is changed. In one embodiment of the present invention, the start point of the playback of the MFF file is shown. When the MFF file is divided and transmitted, all packets including the divided data may have the same Timestamp value.
  • the MFF Type field is information for identifying a transmitted MFF file. Through this field, the receiver may analyze whether it is possible to independently play only the corresponding packet, or if the receiver can be played with other data packets.
  • the meaning of the value of the corresponding field may be represented as shown in FIG. 7.
  • the receiver when the MFF file is divided and transmitted according to the type of data, the receiver may distinguish the packet through the MFF Type field included in the extension header of the RTP packet.
  • the Fragment Indicator field may indicate information on the boundary of data when the MFF is divided according to the data size and stacked in the RTP packet for transmission. The meaning according to the value of this field will be described later.
  • the transmitting side may divide and transmit an MFF file according to the size of data in order to increase transmission efficiency.
  • the receiver may distinguish the boundary for the divided data through the Fragment Indicator field included in the extension header of the RTP packet. That is, data included in the packet received through the Fragment Indicator field may be divided into any one of the first divided data, the intermediate data, and the last data of the MFF file, thereby distinguishing the boundary from other MFF files.
  • the receiver may receive an RTP packet including the MFF file and check the sequence number of the RTP to arrange the order of the packets.
  • the payload type, the SSRC, and the CCRC may be checked and the file transmitted through the payload type value may be recognized as an MFF file.
  • the receiver can confirm that the first and the split data have been received through the Fragment Indicator value of the extension header in the RTP packet.
  • the receiver checks the boundary of the data and uses one playable data. You can see that it has been received.
  • FIG. 13 is a diagram illustrating fragment indicator value and meaning according to an embodiment of the present invention.
  • the value of the fragment type is "00", it may indicate that the payload of the corresponding packet includes unfragmented data.
  • the value of the fragment type is "01" it may indicate that the payload of the corresponding packet includes the first divided data.
  • the value of the fragment type is "10" it may indicate that the payload of the corresponding packet includes the divided intermediate data.
  • the value of the fragment type is "11", it may indicate that the payload of the corresponding packet includes the last data divided.
  • FIG. 14 is a diagram illustrating a data processing process in a receiving apparatus when an MFF file is divided and transmitted according to a data type and a data size according to an embodiment of the present invention.
  • the process of processing data in the receiving apparatus receives an RTP packet (S14010), and the payload type of the RTP packet is MFF.
  • Step S14020 Checking whether the payload type is equal to MFF (step S14020), if the payload type is not a value indicating that MFF, and processing the data of the payload according to the existing RTP standard recommendation method (S14110), and payload type indicating a value of MFF.
  • the Fragment Indicator of the packet is not "00,” Verifying whether it is 01 “(S14130), if the fragment indicator of the corresponding packet is not” 01 “, checking whether it is” 11 "(S14140), and if the fragment indicator of the corresponding packet is" 00 “or” 11 ", the corresponding packet Analyzing the MFF included in (S14080), decoding the MFF (S14090) and / or reproducing the MFF (S14100).
  • the receiving device receiving the RTP packet may check the version, extension, CSRC number, packet order, data reproduction time, SSRC and / or CSRC by performing a general RTP analysis (S14010). At this time, if the payload type of the RTP packet is equal to the value indicating that the MFF, follow the processing method of the MFF file according to an embodiment of the present invention, and if the payload type is not a value indicating that the MFF, the existing RTP standard recommendation method Accordingly, the payload data may be processed (S14110).
  • the MFF type included in the extension header of the RTP packet according to an embodiment of the present invention can be checked (S14020).
  • the payload is an MFF that can be played independently.
  • the Fragment Indicator value included in the extension header of the RTP packet can then be checked to determine whether the MFF file has been divided according to the data size. There is (S14030).
  • the Fragment Indicator value is "00" since the data included in the payload of the corresponding packet is undivided data, the corresponding packet is delivered directly to the MFF Parser, and decoding and reproduction are performed (S14120).
  • the packet is stored in the buffer and a new packet can be received until the last part of the divided data is received. S14130).
  • the packet is stored in the buffer and a new packet can be received until the last portion of the divided data is received.
  • the packet is delivered to the MFF Parser together with the data of the previous order stored in the buffer, and decoding and reproduction are performed (S14140, S14080, and S14090). , S14100).
  • the MFF Type is "01"
  • the Payload is an Initial Partial MFF (S14040)
  • the packet is stored in a buffer until a packet having a value of the MFF Type is "01" is received and new The RTP packet may be received (S14050).
  • the MFF Type of the first received RTP packet is not "00" and "01"
  • the receiver may receive a new packet.
  • the MFF Type is "10"
  • the Fragment Indicator value is "00"
  • the data included in the payload of the packet indicates that the data is not divided, so that the packet is directly transmitted to the MFF Parser, and decoding and reproduction are performed (S14120, S14080, S14090, and S14100). ).
  • the packet is stored in the buffer and a new packet can be received until the last part of the divided data is received. S14130, S14050).
  • the packet is stored in the buffer and a new packet can be received until the last portion of the divided data is received.
  • the packet is delivered to the MFF Parser together with the data of the previous order stored in the buffer, and decoding and reproduction are performed (S14140, S14080, and S14090). , S14100).
  • 15 is a diagram illustrating a header of an RTP packet including a completed MFF according to an embodiment of the present invention.
  • the 20-second media content may be divided into two 10-second Completed MFF files and encoded.
  • the Timestamp value may be displayed as 0, and the Payload Type may be displayed as “71” to indicate that it is an MFF file.
  • the sequence number may start with any number, and in the case of the embodiment of FIG. 15, it can be seen that the sequence number starts from "10". Since the MFF Type is "00", it can be seen that the Completed MFF file is included in the payload of the corresponding packet.
  • the Timestamp value may be represented by 11000, and the Sequence Number value may be represented by “11”.
  • the remaining field values may have the same value as the 1st RTP packet.
  • 16 is a diagram illustrating a header of an RTP packet when an MFF file is divided into an Initial Partial MFF file and a Media Partial MFF file and transmitted through an RTP packet according to an embodiment of the present invention.
  • the 20 second media content may be divided into two Initial Partial MFF files and two 10 Second Media Partial MFF files to be encoded.
  • the 1st RTP packet contains an Initial Partial MFF file, it must be analyzed first. Therefore, it should have a Timestamp value that is equal to or faster than a Media Partial MFF file received later.
  • the timestamp of the packet may have 0 and the payload type may be displayed as “71” to indicate that the packet is an MFF file.
  • the sequence number may start with any number, and in the case of the embodiment of FIG. 16, it can be seen that the sequence number starts from "10". Since the MFF Type is "01", it can be seen that the Initial Partial MFF file is included in the payload of the corresponding packet.
  • the Timestamp value may be displayed as 0, and the Payload Type may be displayed as “71” to indicate that the MFF file is a. Since the Sequence Number is represented by "11" and the MFF Type is "10", it can be seen that the Media Partial MFF file is included in the payload of the corresponding packet.
  • the Timestamp value may be displayed as 11000, and the Payload Type may be displayed as "71" to indicate that it is an MFF file. Since the Sequence Number is represented by "12" and the MFF Type is "10", it can be seen that the Media Partial MFF file is included in the payload of the corresponding packet.
  • 17 is a diagram illustrating the structure of an RTP packet and a Completed MFF when a Completed MFF is included in a payload of the RTP packet and transmitted according to an embodiment of the present invention.
  • the reception apparatus Upon receiving the packet as shown in the figure, the reception apparatus according to an embodiment of the present invention analyzes the header of the RTP packet to grasp information about the order of the packet, the type of data and the starting point of reproduction, and then analyzes the MFF in the payload. can do.
  • the MFF may have a hierarchical data structure.
  • the top layer information in the MFF may be divided into a moov box and an mdat box.
  • the moov box may include metadata related to file playback, and the mdat box may include media data to be decoded in a bit string.
  • the receiver first knows the time specification used for playback, i.e. how many tices per second occurs through the @timescale value contained in the mvhd box inside the moov box, and the @duration value contained in the mvhd box indicates the You can find the total length and other information.
  • the receiver can analyze other information such as @track ID, @width and @height by analyzing the tkhd box which is a lower layer of the trak box inside the moov box.
  • the presence of the vmhd box below shows that the track is about video.
  • the receiver may know information such as the number of total samples (video frames) included in the MFF and a duration value per sample through the value of stts located under the stbl box, which is a lower layer of the minf box.
  • the information included in the stco box indicates the per-sample boundary in the mdat box in which the actual media information is arranged in a bit string.
  • FIG. 18 is a diagram illustrating the structure of an RTP packet and an Initial Partial MFF when an Initial Partial MFF is included and transmitted in a payload of the RTP packet according to an embodiment of the present invention.
  • the reception apparatus Upon receiving the packet as shown in the figure, the reception apparatus according to an embodiment of the present invention analyzes the header of the RTP packet to grasp information about the order of the packet, the type of data and the starting point of reproduction, and then analyzes the MFF in the payload. can do.
  • the MFF may have a hierarchical data structure. There may be a moov box including metadata related to file reproduction as the top layer information in the MFF.
  • the receiver first knows the time specification used for playback, i.e. how many tices per second occurs through the @timescale value contained in the mvhd box inside the moov box, and the @duration value contained in the mvhd box indicates the You can find the total length and other information.
  • the receiver analyzes the tkhd box, which is the lower layer of the trak box inside the moov box, to know other information such as @track ID, @width, @height, etc.
  • the receiver is connected to the minf box, which is another lower layer of the trak box.
  • the value of stts located under the included stbl box shows information such as the total number of samples (video frames) included in the MFF and the duration value per sample.
  • the information included in the stco box indicates the per-sample boundary in the mdat box in which the actual media information is arranged in a bit string.
  • the mdat box may be included in a Media Partial MFF file received following a packet including an Initial Partial MFF file.
  • the reception apparatus may know information about the entire content received through information included in each box of the Initial Partial MFF.
  • FIG. 19 illustrates a structure of an RTP packet and a Media Partial MFF when a Media Partial MFF is included in a payload of the RTP packet and transmitted according to an embodiment of the present invention.
  • the reception apparatus Upon receiving the packet as shown in the figure, the reception apparatus according to an embodiment of the present invention analyzes the header of the RTP packet to grasp information about the order of the packet, the type of data and the starting point of reproduction, and then analyzes the MFF in the payload. can do.
  • the MFF may have a hierarchical data structure.
  • the highest layer information in the MFF may be divided into a sidx box, a moof box, and an mdat box.
  • the sidx box may include other information such as track information, divided sequence numbers, and total length of divided media.
  • the tfhd box included in the traf box located below the moof box allows the receiver to know the data of the divided media of the media partial MFF file.
  • the receiver may know information such as the boundary of the sample of the mdat box and the number of reproduction time samples through the trun box.
  • the reception apparatus can know the playback information and the playback file for the divided media of the Media Partial MFF.
  • FIG. 20 is a diagram illustrating a header of an RTP packet when an MFF file is divided according to data type and data size and transmitted through an RTP packet according to an embodiment of the present invention.
  • the 20 second media content is first divided into an Initial Partial MFF and a 5 Second, 5 Second, and 10 Second Media Partial MFF according to the type of data, and then several MFFs according to the size of the data. It can be divided into and packetized into RTP packets.
  • the transmitter may periodically transmit an Initial Partial MFF.
  • the timestamp of the 1st RTP packet is 0, the Payload Type value is "71", and the Sequence Number value can start with any number "10". have. Since the 1st RTP packet includes the fragmented first data of the Initial Partial MFF file, the Fragment Indicator may have a value of "01", and the MFF Type may have a value of "01". The 2nd RTP packet may have the same Timestamp and Payload Type values as the 1st RTP packet, and the Sequence Number may have “11”. Since the 2nd RTP packet includes the fragmented last data of the Initial Partial MFF file, the Fragment Indicator value may have “11” and the MFF Type value may have “01”.
  • the 3rd RTP packet When the second Media Partial MFF is transmitted in the 3rd RTP packet, the 3rd RTP packet includes the first play time of the media, so the timestamp has "0", the payload type is "71", and the sequence number is "12". It can have in addition, since the 3rd RTP packet includes the unpartitioned Media Partial MFF file, the Fragment Indicator may have a value of "00", and the MFF Type may have a value of "10".
  • the timestamp of the 4th RTP packet is displayed as “6000”, indicating that the content starts from 6 seconds, and the sequence number may have “13”. have. Since the 4th RTP packet includes the first fragmented data of the Media Partial MFF file, the Fragment Indicator has a value of "01" and an MFF Type value of "10". The 5th RTP packet may have the same Timestamp and Payload Type values as the 4th RTP packet, and the sequence number may have “14”. Since the 5th RTP packet includes the fragmented last data of the Media Partial MFF file, the Fragment Indicator may have a value of "11" and the MFF Type may have a value of "10".
  • the 6th RTP packet may have the same Payload Type, Fragment Indicator, and MFF Type values as the 1st RTP packet, and the Sequence Number value is “15”. May have a value “10000” which is faster than the Media Partial MFF transmitted later.
  • the 7th RTP packet When the fifth Media Partial MFF is divided into three RTP packets and transmitted, the 7th RTP packet may have a payload type of "71", a sequence number of "16", and a timestamp value of "11000". May indicate that it has time information for 11 seconds. Since the 7th RTP packet includes the first fragmented data of the Media Partial MFF file, the Fragment Indicator may have a value of "01", and the MFF Type may have a value of "10". The 8th RTP packet may have the same Timestamp and Payload Type values as the 7th RTP packet and the Sequence Number may have “17”.
  • the Fragment Indicator value may have “10” and the MFF Type value may have “10”.
  • the timestamp and payload type of the 9th RTP packet are the same as the 8th RTP packet, and the sequence number may have “18”. Since the 9th RTP packet includes the fragmented last data of the Media Partial MFF file, the Fragment Indicator has a value of "11" and the MFF Type value may have a value of "10".
  • 21 is a diagram illustrating an operation flow of a hybrid broadcast service receiving apparatus based on interworking of a terrestrial broadcasting network and an internet protocol network according to an embodiment of the present invention.
  • An apparatus for receiving a hybrid broadcast service includes a channel synchronizer 21010, a channel equalizer 21020, a channel decoder 21030, a signaling decoder 21040. ), Baseband Operation Controller (21050), Transport Packet Interface (21060), Broadband Packet Interface (21070), Common Protocol Stack (21080), Application Processing Unit (Application Processor 210210), Service Guide Processor (21100), Audio / Video Processor (A / V Processor) 21110, Service Signaling Channel Processing Buffer and Parser (21120), Service Map DB 21130 and / or Service Guide DB 21140 It includes.
  • the channel synchronizer 21010 may perform a function of synchronizing symbol frequency and timing to enable proper decoding in the baseband.
  • the channel equalizer 21020 may perform a function of compensating for the received signal if it is distorted due to a multipath or a Doppler effect.
  • the channel decoder 21030 may perform a function of recovering the received signal into data having meaning. In addition, forward error correction (FEC) may be performed.
  • FEC forward error correction
  • the signaling decoder 21040 may perform a function of extracting and decoding signaling data transmitted from a channel. Signaling data transmitted through the terrestrial broadcasting network according to an embodiment of the present invention may be extracted and decoded by the signaling decoder 21040, and will be described later. May be extracted and decoded in.
  • the baseband operation controller 21050 may perform a function of controlling various processes related to the baseband.
  • the transport packet interface 21060 may perform a function of extracting a transport packet from a broadcast stream received from the channel decoder 21030. In addition, a function of combining signaling or an IP datagram from the extracted transport packet may be performed.
  • the broadband packet interface 21070 may perform a function of extracting a packet obtained through an internet protocol network and combining signaling or A / V data from the corresponding packet.
  • the common protocol stack 21080 may correspond to the protocol stack of FIG. 1.
  • data bundled in packet units may be divided into signaling, audio data, video data, service guide data, and the like through each layer of the protocol.
  • the application processor 21090 may perform a function of extracting and processing application related information from a received signal.
  • the service guide processor 21100 may extract announcement information from a received signal, manage a service guide database 21140 to be described later, and provide a service guide. You can perform the function provided.
  • the audio / video processor 21110 may perform a function of decoding and presenting the received audio and video data.
  • the service signaling channel processing buffer and parser 21120 may perform a function of extracting and parsing signaling information related to scanning and acquiring a service or content from an IP datagram or the like.
  • the service signaling channel processing buffer and parser 21120 may include the above-described signaling decoder 21040.
  • the service signaling channel processing buffer and parser 21120 included in the signaling decoder 21040 may be called a signaling information processing unit, and each of the signaling decoder 21040 and the signaling channel processing buffer and parser 21120 may be referred to as a signaling information processing unit.
  • the profile information of may be extracted and parsed by the signaling information processor as signaling information related to acquisition of a broadcast service.
  • the service map database 21130 may perform a function of storing signaling information decoded by the signaling decoder 21040, the service signaling channel processing buffer and the parser 21120, or the signaling information processing unit.
  • the service guide database 21140 may perform a function of storing a service guide extracted and processed through the service guide processor 21100.
  • 22 is a flowchart illustrating a method of transmitting a media broadcast signal according to an embodiment of the present invention.
  • the media broadcast signal may be transmitted through the following process.
  • data is encoded in a media file format (MFF) (S22010).
  • the data may include media data such as audio data or video data.
  • the description of the media file format has been described in the description of the above terms and abbreviations.
  • the encoded media file format file may be divided into an initial partial MFF file and a media partial MFF file according to the data type (S22020).
  • the initial partial MFF file may include metadata having playback information and initial playback information of the entire media file
  • the media partial MFF file includes metadata having media data and partial playback information related to the media data. can do. The description thereof has been described above with reference to FIGS. 6 to 11.
  • a packet including the divided media file format file is generated according to a protocol for real time transmission (S22030).
  • the transport protocol may include a real time transport protocol, a non-real time transport protocol, and the like, and packetize the media file encoded in the media file format in the above step according to the transport protocol.
  • the header of the generated packet may include media file format (MFF) type information for identifying whether the divided media file format file included in the payload is an initial partial MFF file or a media partial MFF file. This has been described above with reference to FIGS. 6 to 11 and 15 to 20.
  • the generated packet is transmitted (S22040).
  • the data packetized by the transmission protocol may be transmitted through at least one of a terrestrial broadcasting network, a cable network, and an internet protocol network.
  • the header of the packet generated in the step of generating the packet may include payload type information indicating the format of data included in the payload and the payload type information. Details are described above in the description of FIG. 4. In addition, various types of file formats are defined in the payload type information.
  • the payload type information may identify that data included in the payload is a media file format (MFF). This has been described above in the description of FIG. 5.
  • the header of the packet generated in the step of generating the packet includes time stamp information indicating a starting point at which a media file format (MFF) file included in a payload is played. can do.
  • the packet including the initial partial MFF file may have time stamp information equal to or faster than the packet including the media partial MFF file. The description thereof has been described above with reference to FIGS. 6 and 16.
  • a packet including the initial partial MFF file may be continuously transmitted periodically. The description thereof has been described above with reference to FIGS. 6 and 9.
  • the method may include dividing the encoded media file format file according to the size of data instead of dividing the encoded media file format file according to the type of data.
  • the header of the packet for transmitting the divided media file format file includes the divided media file format file included in the payload of the packet. Fragment indicator information that is classified according to the order of data may be included. This has been described above with reference to FIGS. 12 to 14 and 20.
  • the encoded media file format file may be divided into one of the first data, the intermediate data, and the last data, which constitute the entire media file according to the order of the data.
  • the header of the packet for transmitting the divided media file format file includes a timestamp indicating a start point of the playback of the media file format file included in the payload of the packet. May contain information.
  • each packet transmitting the media file format file classified according to the data order may have the same time stamp information. The description thereof has been described above with reference to FIGS. 12 to 14.
  • the media file format file divided according to the type of data may be divided and transmitted again according to the size of the data. The description thereof has been described above with reference to FIG. 20.
  • a protocol for transmitting a media file format file a protocol for real time transmission may be used, and a real time transport protocol (RTP) may be used among protocols for real time transmission.
  • RTP real time transport protocol
  • the transmitted media file format file may include an ISO Base Media File Format (ISOBMFF).
  • ISOBMFF ISO Base Media File Format
  • Apparatus and method according to the present invention is not limited to the configuration and method of the embodiments described as described above, the above-described embodiments may be selectively all or part of each embodiment so that various modifications can be made It may be configured in combination.
  • the image processing method of the present invention can be implemented as a processor-readable code on a processor-readable recording medium provided in the network device.
  • the processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor. Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet. .
  • the processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.
  • the present invention can be used throughout the broadcasting industry.

Abstract

본 발명은 방송 시스템에서 미디어 방송 신호를 송신하는 방법 및 수신하는 장치에 관한 것이다. 미디어 방송 신호 수신 장치는 실시간 전송을 위한 프로토콜에 의한 패킷을 수신하는 수신부, 여기서, 상기 패킷의 페이로드는 데이터 종류에 따라 분할된 미디어 파일 포맷 (MFF) 파일을 포함하고, 상기 분할된 미디어 파일 포맷 (MFF) 파일은 전체 재생 정보와 초기 재생 정보를 가진 메타데이터를 포함하는 초기 부분 MFF 파일 및 미디어데이터와 상기 미디어데이터에 관련된 부분적 재생 정보를 가진 메타데이터를 포함하는 미디어 부분 MFF 파일 중 어느 하나에 해당하고, 미디어 파일 포맷 (MFF) 파일을 분석하여 메타데이터와 미디어데이터를 구분하고 재생에 필요한 정보를 추출하는 파싱부, 상기 파싱부로부터 출력된 미디어 파일 포맷 (MFF) 파일을 복호하는 디코더 및 상기 파싱부에서 추출된 정보를 이용하여 복호된 미디어 파일 포맷 (MFF) 파일을 재생하는 재생부를 포함한다.

Description

실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 방송 신호의 송수신 방법 및 장치
본 발명은 방송 시스템에서 미디어 방송 신호를 송수신하는 방법 및/또는 장치에 관한 것이다. 보다 상세하게는, 본 발명은 실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 방송 신호를 송수신하는 방법 및/또는 장치에 관한 것이다.
통신 기술의 발전에 따라, 미디어 방송을 실시간으로 송신 및 수신하고 실시간으로 재생할 수 있게 되었다. 미디어 방송의 실시간 전송을 위해서, 실시간 전송 프로토콜이 사용되는데 실시간 전송 프로토콜은 오디오, 비디오 등의 미디어를 전송하기 위해 사용되는 프로토콜이다.
실시간 전송 프로토콜에 의한 미디어 패킷은 수신입장에서 패킷에 대한 처리가 신속히 이루어 질 수 있도록 간소하게 구성되어 있고, 실시간 재생에 적합하게 설계되어 있다. 또한, 멀티캐스팅 또한 가능하도록 설계되어 있다.
하지만, 실시간 전송 프로토콜은 HTTP (Hyper Text Transfer Protocol)와 같이 손실된 패킷에 대한 재요청과 같은 송신자와 수신자간의 소통이 불가능하다. 따라서, 저장 매체용 미디어 포맷에 적합한 미디어 파일 포맷 (Media File Format; MFF) 파일을 전송하는 데에는 어려움이 존재한다.
미디어 파일 포맷 (Media File Format; MFF)은 box라고 불리는 데이터 단위로 구성되어 있다. 해당 box들은 ftyp, moov, mdat과 같이 지칭되며 메타데이터와 미디어데이터가 분할되어 계층형태를 이루고 있다. 메타데이터는 주로 파일에 대한 브랜드명과 실제 미디어정보에 대한 구분, 복호화 및 재생 시점과 같은 정보를 포함하고 있다. 그리고, 미디어데이터는 디코더에서 처리될 실제 미디어데이터들을 포함하고 있다. 미디어 파일 포맷 (Media File Format; MFF) 파일의 경우에 수신단에서는 메타데이터뿐만 아니라 미디어데이터도 모두 수신해야 해당 미디어를 재생할 수 있다.
따라서, 실시간 전송 프로토콜은 데이터의 수신과 동시에 재생이 되어야 하는 특성을 가지고 있고, 미디어 파일 포맷 (Media File Format; MFF) 파일은 재생관련 모든 데이터가 수신이 완료되어야 재생이 가능한 특성을 가지고 있다. 따라서, 미디어 파일 포맷 (Media File Format; MFF) 파일을 실시간으로 전송하기 위하여 실시간 전송 프로토콜을 이용하는 경우에는 위와 같은 상이한 특성에 의한 어려움이 존재한다.
또한, 수신기는 MFF 파일이 실시간 전송 프로토콜을 통하여 전송되는 경우에 패킷 레벨에서 전송되는 파일이 MFF 파일인 지를 인지할 수 있는 방법이 없어 해당 파일을 실시간 수신 및 재생함에 있어 문제점이 존재한다.
본 발명이 이루고자 하는 과제는, 전술한 문제점을 해결하기 위한 것으로, 실시간 전송 프로토콜을 기반으로 미디어 파일 포맷 파일을 송수신하는 방법 및/또는 장치를 제공하는 것이다.
나아가, 본 발명이 이루고자 하는 과제는, 실시간 전송 프로토콜 기반의 미디어 파일 포맷 파일의 전송에 적합한 시그널링 정보를 제공하는 것이다.
나아가, 본 발명이 이루고자 하는 과제는, 실시간 전송 포로토콜 상에서 전송되는 데이터가 미디어 파일 포맷 (Media File Format; MFF)임을 구분할 수 있는 방법을 제공하는 것이다.
본 발명의 일 실시예에 따른, 미디어 방송 신호 수신 장치는 실시간 전송을 위한 프로토콜에 의한 패킷을 수신하는 수신부, 여기서, 상기 패킷의 페이로드는 데이터 종류에 따라 분할된 미디어 파일 포맷 (MFF) 파일을 포함하고, 상기 분할된 미디어 파일 포맷 (MFF) 파일은 전체 재생 정보와 초기 재생 정보를 가진 메타데이터를 포함하는 초기 부분 MFF 파일 및 미디어데이터와 상기 미디어데이터에 관련된 부분적 재생 정보를 가진 메타데이터를 포함하는 미디어 부분 MFF 파일 중 어느 하나에 해당하고, 여기서, 상기 패킷의 헤더는 페이로드에 포함된 상기 분할된 미디어 파일 포맷 (MFF) 파일이 초기 부분 MFF 파일인지 미디어 부분 MFF 파일인지를 식별하는 미디어 파일 포맷 (MFF) 타입 정보를 포함하고, 미디어 파일 포맷 (MFF) 파일을 분석하여 메타데이터와 미디어데이터를 구분하고 재생에 필요한 정보를 추출하는 파싱부, 상기 파싱부로부터 출력된 미디어 파일 포맷 (MFF) 파일을 복호하는 디코더 및 상기 파싱부에서 추출된 정보를 이용하여 복호된 미디어 파일 포맷 (MFF) 파일을 재생하는 재생부를 포함한다.
바람직하게는, 상기 미디어 방송 신호 수신 장치는 상기 수신된 패킷의 페이로드에 포함된 데이터를 저장하는 버퍼 및 초기 부분 MFF 파일을 포함한 패킷을 수신하는 경우 상기 초기 부분 MFF 파일이 버퍼에 저장되도록 제어하고, 미디어 부분 MFF 파일을 포함한 패킷을 수신하는 경우 초기 부분 MFF 파일이 버퍼에 저장되어 있는지 확인하여 버퍼에 저장되어 있으면 미디어 부분 MFF 파일을 버퍼에 저장된 초기 부분 MFF 파일과 함께 파싱부로 출력되도록 제어하고, 버퍼에 저장되어 있지 않으면 수신부로 하여금 새로운 패킷을 수신하도록 제어하는 제어부를 더 포함하는 것을 특징으로 한다.
바람직하게는, 상기 패킷의 헤더는 페이로드에 포함된 데이터의 포맷을 나타내는 페이로드 타입 정보를 포함하고, 상기 페이로드 타입 정보는 페이로드에 포함된 데이터가 미디어 파일 포맷 (Media File Format; MFF)임을 식별하는 것을 특징으로 한다.
바람직하게는, 상기 패킷의 헤더는 페이로드에 포함된 미디어 파일 포맷 (MFF) 파일이 재생되는 시작점을 나타내는 타임스탬프 정보를 더 포함하고, 상기 초기 부분 MFF 파일이 포함된 패킷은 상기 미디어 부분 MFF 파일이 포함된 패킷과 같거나 더 빠른 타임스탬프 정보를 갖는 것을 특징으로 한다.
바람직하게는, 상기 초기 부분 MFF 파일이 포함된 패킷은 주기적으로 계속하여 수신되는 것을 특징으로 한다.
바람직하게는, 상기 실시간 전송을 위한 프로토콜은 RTP (Real time Transport Protocol)을 포함하는 것을 특징으로 한다.
바람직하게는, 상기 미디어 파일 포맷 (Media File Format)은 ISOBMFF (ISO Base Media File Format)을 포함하는 것을 특징으로 한다.
본 발명의 또 다른 일 실시예에 따른, 미디어 방송 신호 송신 방법은 오디오데이터 및/또는 비디오데이터를 포함하는 미디어데이터를 미디어 파일 포맷 (Media File Format; MFF)으로 인코딩하는 단계, 상기 인코딩된 미디어 파일 포맷 (MFF) 파일을 데이터 종류에 따라 전체 재생 정보 및 초기 재생 정보를 가진 메타데이터를 포함하는 초기 부분 MFF 파일과 미디어데이터 및 상기 미디어데이터에 관련된 부분적 재생 정보를 가진 메타데이터를 포함하는 미디어 부분 MFF 파일로 분할하는 단계, 실시간 전송을 위한 프로토콜에 따라 상기 분할된 미디어 파일 포맷 (MFF) 파일을 포함하는 패킷을 생성하는 단계, 여기서, 상기 생성된 패킷의 헤더는 페이로드에 포함된 상기 분할된 미디어 파일 포맷 (MFF) 파일이 초기 부분 MFF 파일인지 미디어 부분 MFF 파일인지를 식별하는 미디어 파일 포맷 (MFF) 타입 정보를 포함하고, 상기 생성된 패킷을 전송하는 단계를 포함한다.
바람직하게는, 상기 생성된 패킷의 헤더는 페이로드에 포함된 데이터의 포맷을 나타내는 페이로드 타입 정보를 포함하고, 상기 페이로드 타입 정보는 페이로드에 포함된 데이터가 미디어 파일 포맷 (MFF)임을 식별하는 것을 특징으로 한다.
바람직하게는, 상기 생성된 패킷의 헤더는 페이로드에 포함된 미디어 파일 포맷 (MFF) 파일이 재생되는 시작점을 나타내는 타임스탬프 정보를 더 포함하고, 상기 초기 부분 MFF 파일이 포함된 패킷은 상기 미디어 부분 MFF 파일이 포함된 패킷과 같거나 더 빠른 타임스탬프 정보를 갖는 것을 특징으로 한다.
바람직하게는, 상기 초기 부분 MFF 파일이 포함된 패킷은 주기적으로 계속하여 전송되는 것을 특징으로 한다.
바람직하게는, 상기 실시간 전송을 위한 프로토콜은 RTP (Real time Transport Protocol)을 포함하는 것을 특징으로 한다.
바람직하게는, 상기 미디어 파일 포맷 (Media File Format)은 ISOBMFF (ISO Base Media File Format)을 포함하는 것을 특징으로 한다.
본 발명에 따르면, 실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 파일 포맷 (Media File Format; MFF) 파일을 실시간으로 전송할 수 있는 효과가 있다.
본 발명에 따르면, 실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 파일 포맷 (Media File Format; MFF) 파일을 실시간으로 수신 및 재생할 수 있는 효과가 있다.
도 1은 본 발명의 일 실시예에 따른 RTP (Real time Transport Protocol) 패킷의 헤더 구조를 나타낸 도면이다.
도 2는 본 발명의 일 실시예에 따른 미디어 파일 포맷 (Media File Format; MFF)의 구조를 나타낸 도면이다.
도 3은 본 발명의 일 실시예에 따른 실시간 전송 프로토콜을 이용하여 미디어 파일 포맷 (Media File Format; MFF) 파일을 스트림 형식으로 재생하는 미디어 방송 신호 수신 장치를 나타낸 도면이다.
도 4는 본 발명의 일 실시예에 따른 실시간 전송 프로토콜 패킷의 고정 헤더의 Syntax를 나타낸 도면이다.
도 5는 본 발명의 일 실시예에 따른 실시간 전송 프로토콜에 사용되는 페이로드 타입 정보 (Payload Type)를 나타낸 도면이다.
도 6은 본 발명의 일 실시예에 따른 실시간 전송 프로토콜 패킷의 확장 헤더에 미디어 파일 포맷 (MFF)타입 정보 (MFF Type)가 포함된 Syntax를 나타낸 도면이다.
도 7은 본 발명의 일 실시예에 따른 미디어 파일 포맷 타입 정보 (MFF Type) 값과 의미를 나타낸 도면이다.
도 8은 본 발명의 일 실시예에 따른 Completed MFF의 구조를 나타낸 도면이다.
도 9는 본 발명의 일 실시예에 따른 Initial Partial MFF의 구조를 나타낸 도면이다.
도 10은 본 발명의 일 실시예에 따른 Media Partial MFF의 구조를 나타낸 도면이다.
도 11은 본 발명의 일 실시예에 따른 MFF 파일이 데이터의 종류별로 분할되어 전송되는 경우에 수신 장치에서 데이터의 처리과정을 나타낸 도면이다.
도 12는 본 발명의 일 실시예에 따른 실시간 전송 프로토콜 패킷의 확장 헤더에 프래그먼트 인디케이터 정보 (Fragment Indicator)가 포함된 Syntax를 나타낸 도면이다.
도 13은 본 발명의 일 실시예에 따른 프래그먼트 인디케이터 정보 (Fragment Indicator)값과 의미를 나타낸 도면이다.
도 14는 본 발명의 일 실시예에 따른 MFF 파일이 데이터 종류 및 데이터 크기에 따라 분할되어 전송되는 경우에 수신 장치에서 데이터의 처리과정을 나타낸 도면이다.
도 15는 본 발명의 일 실시예에 따른 Completed MFF를 포함한 RTP 패킷의 헤더를 나타낸 도면이다.
도 16은 본 발명의 일 실시예에 따른 MFF 파일이 Initial Partial MFF 파일과 Media Partial MFF 파일로 분할되어 RTP 패킷을 통해 전송되는 경우 RTP 패킷의 헤더를 나타낸 도면이다.
도 17은 본 발명의 일 실시예에 따른 RTP 패킷의 페이로드에 Completed MFF가 포함되어 전송되는 경우에 RTP 패킷 및 Completed MFF의 구조를 나타낸 도면이다.
도 18은 본 발명의 일 실시예에 따른 RTP 패킷의 페이로드에 Initial Partial MFF가 포함되어 전송되는 경우에 RTP 패킷 및 Initial Partial MFF의 구조를 나타낸 도면이다.
도 19는 본 발명의 일 실시예에 따른 RTP 패킷의 페이로드에 Media Partial MFF가 포함되어 전송되는 경우에 RTP 패킷 및 Media Partial MFF의 구조를 나타낸 도면이다.
도 20은 본 발명의 일 실시예에 따른 MFF 파일이 데이터 종류 및 데이터 크기에 따라 분할되어 RTP 패킷을 통해 전송되는 경우 RTP 패킷의 헤더를 나타낸 도면이다.
도 21은 본 발명의 일 실시예에 따른 지상파 방송망과 인터넷 프로토콜망 연동 기반의 하이브리드 방송 서비스 수신 장치의 동작 흐름을 나타낸 도면이다.
도 22는 본 발명의 일 실시예에 따른 미디어 방송 신호의 송신 방법의 흐름을 나타낸 도면이다.
이하 첨부 도면들 및 첨부 도면들에 기재된 내용들을 참조하여 본 발명의 실시예를 상세하게 설명하지만, 본 발명이 실시예들에 의해 제한되거나 한정되는 것은 아니다.
본 명세서에서 사용되는 용어는 본 발명에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당분야에 종사하는 기술자의 의도 또는 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 발명의 설명 부분에서 그 의미를 기재할 것이다. 따라서 본 명세서에서 사용되는 용어는, 단순한 용어의 명칭이 아닌 그 용어가 가지는 실질적인 의미와 본 명세서의 전반에 걸친 내용을 토대로 해석되어야 함을 밝혀두고자 한다
본 발명에 대한 이해와 설명의 편의를 위하여, 용어 및 약어에 대하여 아래와 같이 정의한다.
발명의 상세한 설명에서 사용되는 용어 중, 미디어 파일 포맷 (Media File Format; MFF)은 오디오 파일이나 비디오 파일과 같은 미디어 파일의 데이터 포맷을 의미하고, 예를 들어, MP4 (MPEG-4), 3GP (3GPP file format), ASF (Advanced Streaming Format), WMV (Windows Media Video), ISOBMFF (ISO Base Media File Format) 등이 미디어 파일 포맷에 해당될 수 있다. 또한, 미디어 파일 포맷은 MFF라고 약칭될 수 있다.
ISOBMFF (ISO Base Media File Format)은 오디오나 비디오와 같은 시간 기반의 멀티미디어 파일들을 위한 일반적인 구조를 정의하고 있고, MP4나 3GP 와 같이 다른 미디어 파일 포맷의 기본 구조로서 사용될 수 있다.
Payload Type은 페이로드 타입 정보라고 명명될 수 있다.
MFF Type은 미디어 파일 포맷 (MFF)타입 정보라고 명명될 수 있다.
Fragment Indicator는 프래그먼트 인디케이터 정보라고 명명될 수 있다.
Timestamp는 타임스탬프 정보라고 명명될 수 있다.
Initial Partial MFF는 초기 부분 MFF 파일 또는 초기 부분 MFF 파일 (Initial Partial MFF)이라고 명명될 수 있다.
Media Partial MFF는 미디어 부분 MFF 파일 또는 미디어 부분 MFF 파일 (Media Partial MFF)이라고 명명될 수 있다.
본 명세서에서 사용될 본 발명의 일 실시예에 따른 실시간 전송 프로토콜은 실시간으로 비디오나 오디오 스트리밍을 하기 위한 프로토콜로서 RTP (Real time Transport Protocol), RTCP (RTP Control Protocol), RTSP (Real Time Streaming Protocol), RTMP (Real Time Messaging Protocol) 등이 해당될 수 있다. 이하, 본 발명은 실시간 전송 프로토콜 중 RTP를 일 실시예로 설명하지만, 본 발명의 사상이 이에 국한되는 것은 아니다.
도 1은 본 발명의 일 실시예에 따른 RTP (Real time Transport Protocol) 패킷의 헤더 구조를 나타낸 도면이다.
RTP (Real time Transport Protocol) 프로토콜은 오디오와 비디오 같은 미디어를 전송하기 위한 프로토콜이다.
당해 도면에 도시된 바와 같이, RTP 패킷의 헤더는 비교적 간소화되어 있어 수신단에서 패킷에 대해 신속하게 처리할 수 있다. RTP 패킷의 헤더에 순서 번호 (Sequence Number), 타임스탬프 (TimeStamp) 등의 미디어 재생에 필요한 정보를 정의하여 실시간 재생에 적합하게 설계될 수 있다. 또한, 당해 도면의 RTP 패킷의 헤더를 이용하면, 멀티캐스팅이 가능하여 하나의 송신자로부터 다수의 수신자가 동시에 정보를 수신할 수 있다. 또한, RTP 패킷의 헤더는 확장 헤더 (Extension Type)를 구비함으로써 앞으로의 서비스 개발에 대한 확장성을 대비할 수 있다.
하지만, 실시간 전송 프로토콜의 경우에는 HTTP(Hyper Text Transfer Protocol)와 같이 손실된 패킷에 대한 재요청과 같은 송신자와 수신자간의 소통은 불가능할 수 있다.
본 발명의 일 실시예에 따른 RTP 패킷의 헤더는, V (Version), P (Padding), X (Extension), CC (CSRC Count), M (Marker), PT (Payload Type), Sequence Number, TimeStamp, SSRC Identifier (Syncrhronization Source Identifier), CSRC Identifier (Contributing Source Identifier), Extension Type, Length, Reserved 및/또는 Classifier를 포함한다.
V (Version)은 프로토콜의 버전을 나타낸다.
P (Padding)은 패딩 바이트가 존재하는 지를 나타낸다. 이 필드가 세트되면 RTP 패킷의 끝에 패딩바이트들이 포함된다. 이 패딩 바이트들은 암호화 알고리즘에 사용되거나 패킷 길이를 맞추는 데 사용된다.
X (Extension)는 고정 헤더와 페이로드 사이에 확장 헤더가 존재하는 지를 나타낸다.
CC (CSRC Count)는 고정 헤더 뒤에 CSRC identifier가 몇 개 포함되어 있는 지를 나타낸다.
M (Marker)는 미디어의 프레임 경계등을 표시하기 위해 사용된다.
PT (Payload Type)는 페이로드의 형식을 나타낸다. 오디오나 비디오의 인코딩 타입을 나타낼 수 있다.
Sequence Number는 패킷의 순서 번호를 나타낸다. 전송되는 RTP 패킷마다 1씩 증가한다. 수신측은 이 필드를 통해 패킷 손실을 감지할 수 있고 패킷 순서를 복원할 수 있다. Sequence Number의 초기 값은 무작위로 설정되어야 한다.
TimeStamp는 RTP 데이터 패킷의 첫 번째 샘플링 시점을 나타낸다. 수신자는 이 필드를 이용해서 수신된 미디어의 동기적인 재생이 가능하게 할 수 있다.
SSRC Identifier (Syncrhronization Source Identifier)는 RTP 스트림의 소스를 식별한다.
CSRC Identifier (Contributing Source Identifier)는 패킷에 포함된 미디어를 구성하는 소스들을 식별한다.
도 2는 본 발명의 일 실시예에 따른 미디어 파일 포맷 (Media File Format; MFF)의 구조를 나타낸 도면이다.
당해 도면에 도시된 바와 같이, MFF은 box라고 불리는 데이터 단위로 구성되어 있다. 해당 box들은 ftyp, moov, mdat로 지칭되며 MFF는 메타데이터와 미디어데이터가 분할된 계층형태로 구성되어 있다. 메타데이터는 주로 파일에 대한 브랜드명과 실제 미디어정보에 대한 구분, 복호화 및 재생 시점과 같은 정보를 포함할 수 있다. 그리고, 미디어데이터는 디코더에서 처리될 실제 미디어데이터들을 포함할 수 있다. 여기서, 수신기는 메타데이터뿐만 아니라 미디어데이터도 모두 수신해야 해당 미디어를 재생할 수 있다.
당해 도면에 도시된 바와 같이, MFF는 ftyp (file type box), moov (movie box) 및/또는 mdat (media data box)를 포함할 수 있다.
ftyp (file type box)는 파일 타입 (file type)과 파일의 호환성 (compatibility)을 나타내는 박스이고 파일 타입 박스로 지칭될 수 있다.
moov (movie box)는 미디어데이터에 관련한 모든 메타데이터를 저장하는 박스이고 무비 박스로 지칭될 수 있다. moov (movie box)는 mvhd (movie header box) 및/또는 trak (track box)을 포함할 수 있고, trak (track box)는 tkhd (trak header box) 및/또는 mdia (media box)를 포함할 수 있다. mvhd (movie header box)는 movie header를 나타내는 박스이다. trak (track box)는 각각의 트랙 또는 스트림을 나타내는 박스이다. tkhd (track header box)는 트랙에 관한 전반적인 정보를 포함하는 박스이고 트랙 헤더 박스로 지칭될 수 있다. mdia (media box)는 트랙 안의 미디어데이터에 대한 정보를 나타내는 박스이다.
mdat (media data box)는 실제 미디어데이터를 저장하는 박스이고 미디어데이터 박스로 지칭될 수 있다.
도 3은 본 발명의 일 실시예에 따른 실시간 전송 프로토콜을 이용하여 미디어 파일 포맷 (Media File Format; MFF) 파일을 스트림 형식으로 재생하는 미디어 방송 신호 수신 장치를 나타낸 도면이다.
본 발명의 일 실시예에 따른 미디어 방송 신호 수신 장치는 서버 (Server; 3010), 수신부 (RTP Receiving; 3020), 버퍼 (RTP buffer; 3030), 제어부 (3040), 파싱부 (MFF Parser; 3050), 디코더 (Decoder; 3060) 및/또는 재생부 (Renderer; 3070)를 포함할 수 있다.
서버 (Server; 3010)는 수신할 MFF 파일이 저장되어 있는 위치를 나타낸다.
수신부 (RTP Receiving; 3020)는 서버 (3010)로부터 실시간 전송 프로토콜에 의한 패킷을 수신할 수 있다.
버퍼 (RTP buffer; 3030)는 수신부 (3020)에서 수신한 패킷을 분석하여 수신된 패킷의 순서, 데이터의 재생 시점 및 필요 버퍼량을 분석하고 페이로드 데이터를 버퍼에 저장할 수 있다.
제어부 (3040)는 수신된 패킷의 헤더에 포함된 페이로드 타입 정보를 분석하여 페이로드 타입이 MFF인 경우, 버퍼 (3030)에 저장된 페이로드 데이터를 파싱부 (3050)로 출력되도록 제어할 수 있다. 제어부 (3040)는 MFF 파일이 데이터 종류 또는 데이터 크기에 따라 분할되어 전송되는 경우, 버퍼 (3030)에 저장된 데이터의 패킷의 미디어 파일 포맷 타입 정보 (MFF Type) 값을 확인하여 값이 "00"이면 Completed MFF로 판단하여 파싱부 (3050)로 출력되도록 제어할 수 있다. 제어부 (3040)는 저장된 패킷의 미디어 파일 포맷 타입 정보 (MFF Type) 값을 확인하여 값이 "00"이 아니면 재생이 가능한 지 여부를 판단할 수 있다. 제어부 (3040)는 패킷의 프래그먼트 인디케이터 정보 (fragment indicator) 값을 확인하여 "01" 및 "11"인 패킷을 수신한 경우에는 분할된 데이터의 처음부터 끝까지 다 수신한 것이므로 패킷을 파싱부 (3050)에 출력되도록 제어하고, 프래그먼트 인디케이터 정보 (fragment indicator) 값이 "11"인 패킷을 수신하기 전까지는 지속적으로 패킷을 수신하도록 제어할 수 있다. 제어부 (3040)는 저장된 패킷의 미디어 파일 포맷 타입 정보 (MFF Type) 값을 확인하여 값이 "01"이면 상기 패킷에 포함되어 수신된 초기 부분 MFF 파일 (Initial Partial MFF)이 버퍼에 저장되도록 제어할 수 있다. 제어부는 저장된 패킷의 미디어 파일 포맷 타입 정보 (MFF Type) 값을 확인하여 값이 "10"이면 즉, 상기 패킷에 포함되어 수신된 파일이 미디어 부분 MFF 파일 (Media Partial MFF)임을 나타내면, 먼저 초기 부분 MFF 파일 (Initial Partial MFF)이 버퍼에 저장되어 있는지 확인하고 버퍼에 저장되어 있으면 미디어 부분 MFF 파일을 버퍼에 저장된 초기 부분 MFF 파일과 함께 파싱부 (3050)로 출력되도록 제어하고, 초기 부분 MFF 파일이 버퍼에 저장되어 있지 않으면 수신부 (3020)로 하여금 새로운 패킷을 수신하도록 제어할 수 있다. 상기 전술한 Completed MFF, 초기 부분 MFF 파일 (Initial Partial MFF), 미디어 부분 MFF 파일 (Media Partial MFF)에 대한 상세한 설명은 후술한다.
파싱부 (MFF Parser; 3050)는 MFF 파일을 분석하여 메타데이터와 미디어데이터를 구분하여 재생에 필요한 기타 정보를 추출할 수 있다.
디코더 (Decoder; 3060)는 파싱부 (3050)로부터 디코딩 시점마다 해당 미디어 정보를 전달 받고 이를 참조하여 수신한 데이터를 디코딩할 수 있다.
재생부 (Renderer; 3070)는 디코더 (3060)로부터 디코딩된 데이터를 파싱부 (3050)가 추출한 재생 시점마다 재생하는 기능을 수행할 수 있다.
도 4는 본 발명의 일 실시예에 따른 실시간 전송 프로토콜 패킷의 고정 헤더의 Syntax를 나타낸 도면이다.
본 발명의 일 실시예에 따른 실시간 전송 프로토콜 패킷의 고정 헤더는, Version 필드, Padding 필드, eXtension 필드, CSRC Count 필드, Marker 필드, Payload Type 필드, Sequence Number 필드, Timestamp 필드, SSRC 필드 및/또는 CSRC 필드를 포함할 수 있다.
Version 필드는 RTP의 버전을 나타내며 이는 2로 고정되어 있다.
Padding 필드는 패딩 바이트가 존재하는 지를 나타낸다. 이 필드가 세트되면 RTP 패킷의 끝에 패딩바이트들이 포함된다. 이 패딩 바이트들은 암호화 알고리즘에 사용되거나 패킷 길이를 맞추는 데 사용된다.
eXtension 필드는 고정 헤더와 페이로드 사이에 확장 헤더가 존재하는 지를 나타낸다. 본 발명의 일 실시예에서는 ISO Base Media File Format 파일의 전송에 필요한 추가 정보를 위해 1로 표시된다.
CSRC count 필드는 고정 헤더 뒤에 CSRC identifier가 몇 개 포함되어 있는 지를 나타낸다.
Marker 필드는 프로파일에 따라 달리 해석되며 프레임 경계와 같은 중요한 이벤트를 표시하기 위해 사용된다.
Payload Type 필드는 패킷이 전송하고자 하는 데이터의 포맷을 나타낸다. 해당 정보를 통해 패킷단에서 데이터의 종류를 파악하여 복호화에 대한 준비를 할 수 있다. RTP에 사용되는 Payload Type은 RFC 3551에 정의되어 있으며 도 5와 같이 기술된다. 본 발명에서는 일 실시예로써 임시적으로 Payload Type 값 "71"이 MFF 파일의 전송을 위한 패킷 종류로 정의되었으나 "35~71" 혹은 "77~127"의 값으로 정의될 수 있다.
Sequence Number 필드는 전송하는 패킷의 순서를 나타내는 정보로 시작점은 임의의 숫자로 시작된다. 그리고 한 패킷이 전송될 때마다 1씩 증가하게 된다.
Timestamp 필드는 해당 패킷이 샘플링 된 시점을 나타낸다. 이 필드의 값으로 이 패킷의 페이로드 데이터가 재생되어야 하는 타이밍을 알 수 있다. 페이로드에 기술된 데이터에 따라 시간 단위 정보의 값이 달라지게 된다. 본 발명의 일 실시예에서는 MFF 파일이 재생되는 시작점을 나타낸다.
SSRC 필드는 수신되는 각각의 미디어 스트림 소스를 구별하는데 사용된다. 하나의 세션에서 여러 개의 미디어가 동시에 스트림 될 수 있으며 이들을 구분하기 위해 이 필드의 값을 사용한다. 하나의 세션에서는 미디어 소스마다 서로 다른 SSEC 값을 가져야 한다. 또한, SSRC 필드는 동기화를 위한 데이터 구분자로 사용되며 이 값은 임의적으로 생성될 수 있다.
CSRC 필드는 전송 공헌자에 대한 구분자로 사용된다. 이 값은 임의적으로 생성되며 최대 15개까지 값을 가질 수 있다.
Payload 필드는 MFF로 인코딩된 데이터 바이트를 포함한다. 본 발명의 일 실시예에서 Payload에 포함되는 MFF는 Mandatory Box가 포함되는 것을 전제로 하며 필요에 따라 Optional Box가 더 포함되면서 MFF에 대한 확장성을 갖출 수 있다.
도 5는 본 발명의 일 실시예에 따른 실시간 전송 프로토콜에 사용되는 페이로드 타입 정보 (Payload Type)를 나타낸 도면이다.
PT는 페이로드 타입의 값을 나타내고, Encoding Name은 페이로드에 포함된 데이터의 인코딩 종류를 나타낸다. 또한, A/V는 해당 데이터가 오디오인지 비디오인지를 나타낸다.
본 발명의 일 실시예에서 페이로드 타입 정보 (Payload Type) 값 "71"이 MFF 파일의 전송을 위한 값으로 정의되었으나, "35~71" 혹은 "77~127"의 값으로 정의될 수 있다.
기존 RTP 프로토콜의 Payload Type의 값은 MFF에 대한 값이 정의 되지 않아 기존의 수신기는 RTP 패킷 레벨에서 MFF가 전송 시 해당 포맷을 인지할 수 없었다. 하지만, 본 발명의 일 실시예에 따라 MFF에 대한 RTP 패킷의 Payload Type 값을 추가함으로써 수신기는 전달되는 RTP 패킷 레벨에서 데이터를 구분할 수 있다. 이에 따라서, 수신기는 데이터 처리에 대한 효율성을 증가 시킬 수 있다.
즉, 본 발명의 일 실시예에 따르면, 실시간 전송 프로토콜 상에서 페이로드에 포함된 데이터가 MFF임을 구분할 수 있는 방법을 제공할 수 있다.
본 발명의 일 실시예에 따르면, 페이로드 타입 정보는 페이로드에 포함된 데이터가 미디어 파일 포맷 (MFF)임을 식별할 수 있다.
도 6은 본 발명의 일 실시예에 따른 실시간 전송 프로토콜 패킷의 확장 헤더에 미디어 파일 포맷 (MFF)타입 정보 (MFF Type)가 포함된 Syntax를 나타낸 도면이다.
본 발명의 일 실시예에 따르면 실시간 전송 프로토콜 패킷을 확장하여 MFF 파일을 데이터 종류에 따라 분할하여 전송할 수 있다.
본 발명의 일 실시예에 따른 실시간 전송 프로토콜 패킷은 RTP 고정 헤더 (Real time Transport Protocol fixed header), RTP 확장 헤더 (Real time Transport Protocol extension header) 및 페이로드를 포함할 수 있다. RTP 고정 헤더에 타임스탬프 (Timestamp) 필드가 포함될 수 있고, RTP 확장 헤더에 미디어 파일 포맷 타입 정보 (MFF Type)가 포함될 수 있다.
Timestamp 필드는 해당 패킷이 샘플링 된 시점을 나타낸다. 이 필드의 값으로 이 패킷의 페이로드 데이터가 재생되어야 하는 타이밍을 알 수 있다. 페이로드에 기술된 데이터에 따라 시간 단위 정보의 값이 달라지게 된다. 본 발명의 일 실시예에서는 MFF 파일이 재생되는 시작점을 나타낸다. 그리고, MFF 파일이 분할되어 전송되는 경우에 분할된 데이터를 포함한 패킷은 모두 동일한 Timestamp 값을 가질 수 있다.
MFF Type 필드는 전송되는 MFF 파일을 구분하기 위한 정보이다. 해당 필드를 통해 수신자는 해당 패킷으로만 독립적으로 재생이 가능한지, 또는 다른 종류의 데이터 패킷과 함께 수신되어야 재생이 가능한지 여부에 대해 분석이 가능할 수 있다. 해당 필드의 값에 대한 의미는 후술한다.
본 발명의 일 실시예에 따르면, MFF 파일이 데이터의 종류별로 분할되어 전송되는 경우, 수신기는 RTP 패킷의 확장 헤더에 포함된 MFF Type 필드를 통해 패킷을 구분할 수 있다.
MFF는 포맷 하나 그 자체만으로 독립적 재생이 가능한 Completed MFF, 전송률의 효율성을 고려해 전체 재생 정보와 초기 재생 정보를 가진 메타데이터만을 포함한 Initial Partial MFF 및 미디어데이터에 관련된 부분적 재생 정보를 가진 메타데이터와 미디어데이터를 포함한 Media Partial MFF 중 어느 하나로 분할되어 전송될 수 있다.
예를 들어, 20초짜리 콘텐트가 Initial Partial MFF, Media Partial MFF(5초), Media Partial MFF(5초), Media Partial MFF(10초)로 분할되어 전송될 경우, 20초에 대한 전체 재생시간, 트랙을 구분할 수 있는 정보 및 다른 공통된 메타데이터들은 Initial Partial MFF에 포함되어 송신자에 의해 주기적으로 전송될 수 있다. 그리고, 각 해당 시점의 샘플(비디오 프레임) 경계에 대한 정보와 복호화 시간 정보와 같은 메타데이터 및 실제 미디어 데이터는 Media Partial MFF에 포함되어 순차적으로 전송될 수 있다. 이때, Initial Partial MFF가 먼저 수신 되어야 수신기에서 미디어 재생이 가능하므로 송신 측에서 Initial Partial MFF를 주기적으로 전송해야 Media Partial MFF에 대한 미디어 재생을 시작할 수 있다.
도 7은 본 발명의 일 실시예에 따른 미디어 파일 포맷 타입 정보 (MFF Type) 값과 의미를 나타낸 도면이다.
MFF Type의 값이 "00"이면, 분할된 MFF가 Complete MFF임을 나타낸다. Complete MFF는 메타데이터 전부와 미디어데이터를 포함하여 그 자체만으로 독립적 재생이 가능한 파일을 의미할 수 있다.
MFF Type의 값이 "01"이면, 분할된 MFF가 초기 부분 MFF 파일 (Initial Partial MFF)임을 나타낸다. 초기 부분 MFF 파일 (Initial Partial MFF)은 미디어 파일에 관한 전체 재생 정보와 초기 재생 정보를 가진 메타데이터를 포함하는 파일을 의미할 수 있다.
MFF Type의 값이 "10"이면, 분할된 MFF가 미디어 부분 MFF 파일 (Media Partial MFF)임을 나타낸다. 미디어 부분 MFF 파일 (Media Partial MFF)은 미디어데이터와 상기 미디어데이터에 관련된 부분적 재생 정보를 가진 메타데이터를 포함한 파일을 의미할 수 있다.
MFF Type의 값 "11"은 reserved 된 값을 의미한다.
도 8은 본 발명의 일 실시예에 따른 Completed MFF의 구조를 나타낸 도면이다.
본 발명의 일 실시예에 따른 Complete MFF는 RTP 페이로드에 삽입되어 전송되며, 재생에 필요한 모든 메타데이터와 미디어데이터를 모두 포함하고 있으므로 독자적으로 미디어 재생이 가능하다.
당해 도면에 도신된 바와 같이, 본 발명의 일 실시예에 따른 Complete MFF는 분할되지 않은 미디어 파일 포맷 (MFF)과 동일한 구조를 가지고 있다. 따라서, 당해 도면에 관한 상세한 설명은 전술한 미디어 파일 포맷 (Media File Format; MFF)의 구조를 나타낸 도면에 관한 설명으로 대체한다.
도 9는 본 발명의 일 실시예에 따른 Initial Partial MFF의 구조를 나타낸 도면이다.
본 발명의 일 실시예에 따른 Initial Partial MFF는 미디어 전체 재생 정보를 나타내는 공용적인 Mandatory box와 전체적 초기 재생 관련 정보가 담긴 메타데이터로 구성되어 있다. 여기서, Initial Partial MFF에 포함된 정보들은 본 발명의 일 실시예에 따른 미디어 방송 신호 수신 장치의 파싱부 (3050)에 의하여 분석될 수 있다. 또한, Initial Partial MFF 파일은 수신자에게 주기적으로 전송되어야 하고, 그래야만 수신자가 미디어 재생에 대한 준비를 할 수 있다.
본 발명의 일 실시예에 따른 Initial Partial MFF를 구성하는 각 박스에 대한 설명은 전술한 미디어 파일 포맷 (Media File Format; MFF)의 구조를 나타낸 도면에 관한 설명으로 대체한다.
도 10은 본 발명의 일 실시예에 따른 Media Partial MFF의 구조를 나타낸 도면이다.
본 발명의 일 실시예에 따른 Media Partial MFF에는 분할된 미디어데이터와 상기 미디어데이터에 관련된 부분적 재생 정보를 가진 메타데이터를 포함할 수 있다. Media Partial MFF에 포함되어 전송되는 미디어데이터는 Initial Partial MFF을 전송 받은 후 재생이 가능하다.
본 발명의 일 실시예에 따른 RTP에 의해 전송되는 미디어데이터는 Initial Partial MFF과 Media Partial MFF가 모두 수신되어야만 미디어 재생이 가능하다. Initial Partial MFF 및 Media Partial MFF 중 어느 하나만 수신되는 경우에는 미디어 재생이 불가능하다.
본 발명의 일 실시예에 따른 Media Partial MFF는 styp (segment type box), sidx (segment index box), moof (movie fragment box) 및/또는 mdat (media data box)를 포함할 수 있다.
styp (segment type box)는 미디어 세그먼트의 파일 타입 (file type)과 파일의 호환성 (compatibility)을 나타내는 박스이다.
sidx (segment index box)는 각 미디어 세그먼트를 인덱스 (index)하는 박스이다. sidx 박스에는 track 정보, 분할된 sequence number, 분할된 미디어의 총 길이 등의 기타 정보들이 포함될 수 있다.
moof (movie fragment box)는 후술할 mdat 박스에 어떤 미디어 샘플들이 포함되어 있는지를 나타내는 박스이다. moof (movie fragment box)는 mfhd 및/또는 traf를 포함할 수 있고, traf (track fragment box)는 tfhd (movie fragment header box) 및/또는 trun (track fragment run box)을 포함할 수 있다. mfhd (movie fragment header box)는 movie fragment header를 나타내는 박스이다. traf (track fragment box)는 각 트랙 프래그먼트에 관련한 메타데이터를 포함하는 박스이다. tfhd는 track fragment header를 나타내는 박스이다. trun (track fragment run box)는 트랙 프래그먼트 런스를 나타내며, traf는 0 또는 그 이상의 trun을 포함할 수 있다. 수신기는 trun 박스를 통해 mdat 박스의 샘플에 대한 경계 및 재생 시점 샘플의 개수 등의 정보를 알 수 있다.
mdat (media data box)는 실제 미디어데이터를 저장하는 박스이다.
도 11은 본 발명의 일 실시예에 따른 MFF 파일이 데이터의 종류별로 분할되어 전송되는 경우에 수신 장치에서 데이터의 처리과정을 나타낸 도면이다.
본 발명의 일 실시예에 따른 MFF 파일이 데이터의 종류별로 분할되어 전송되는 경우 수신 장치에서 데이터의 처리과정은 RTP 패킷을 수신하는 단계 (S11010), RTP 패킷의 Payload Type이 MFF 임을 나타내는 값과 동일한지 확인하는 단계 (S11020), Payload Type이 MFF 임을 나타내는 값이 아닌 경우 기존의 RTP 표준 권고 방식에 따라 페이로드의 데이터를 처리하는 단계 (S11110), Payload Type이 MFF 임을 나타내는 값인 경우 MFF Type이 "00"인지 확인하는 단계 (S11030), MFF Type이 "01"인지 확인하는 단계 (S11040), MFF Type이 "01"인 경우 해당 패킷을 RTP 버퍼에 저장하는 단계 (S11050), MFF Type이 "01"이 아닌 경우 MFF Type이 "10"인지 확인하는 단계 (S11060), MFF Type이 "10"인 경우 RTP 버퍼에 MFF Type이 "10"인 패킷이 저장되어 있는지 확인하는 단계 (S11070), MFF Type이 "00"이거나 MFF Type이 "10"이고 이전에 RTP 버퍼에 MFF Type이 "01"인 패킷이 저장되어 있는 경우에 해당 패킷에 포함된 MFF를 분석하는 단계 (S11080), MFF를 복호화하는 단계 (S11090) 및/또는 MFF를 재생하는 단계 (S11100)를 포함할 수 있다.
RTP 패킷을 수신 받은 수신 장치는 일반적인 RTP 분석을 진행하여 버전, 확장여부, CSRC 개수, 패킷 순서, 데이터 재생시점, SSRC 및/또는 CSRC를 확인할 수 있다 (S11010). 이 때 RTP 패킷의 Payload Type이 MFF 임을 나타내는 값과 동일한 경우, 본 발명의 일 실시예에 따른 MFF 파일의 처리 방식을 따르며 (S11020), Payload Type이 MFF 임을 나타내는 값이 아닌 경우, 기존의 RTP 표준 권고 방식에 따라 페이로드의 데이터를 처리할 수 있다 (S11110).
RTP 패킷의 Payload Type이 MFF 임을 나타내는 값과 동일한 경우, 본 발명의 일 실시예에 따른 RTP 패킷의 확장헤더에 포함된 MFF Type을 확인할 수 있다 (S11030).
MFF Type이 "00"인 경우 (S11030), 해당 Payload는 독립적으로 재생이 가능한 MFF이므로 바로 파싱부 (MFF Parser; 3050)에 전달되어 복호화 및 재생이 이루어 질 수 있다 (S11080, S11090, S11100).
하지만, MFF Type이 "01"인 경우 (S11040), 해당 Payload가 Initial Partial MFF임을 인지할 수 있고, MFF Type이 "01"인 값을 가진 패킷이 올 때까지 버퍼에 저장시키며 새로운 RTP 패킷을 수신한다 (S11050). 이 때 만약 처음 수신된 RTP 패킷의 MFF Type이 "00"과 "01"이 아닐 경우 수신기는 새로운 패킷을 수신한다.
MFF Type이 "10"인 경우 (S11060), 기존에 MFF Type 값이 "01"인 RTP 패킷이 수신되었는 지 여부를 판단하고 (S11070), MFF Type이 "10"인 패킷과 "01"인 패킷 모두가 존재할 경우, 버퍼에 저장된 패킷들에 대해 파싱, 복호화 및 재생을 진행한다 (S11080, S11090, S11100).
도 12는 본 발명의 일 실시예에 따른 실시간 전송 프로토콜 패킷의 확장 헤더에 프래그먼트 인디케이터 정보 (Fragment Indicator)가 포함된 Syntax를 나타낸 도면이다.
본 발명의 일 실시예에 따르면 실시간 전송 프로토콜 패킷을 확장하여 MFF 파일을 데이터 크기에 따라 분할하여 전송할 수 있다.
본 발명의 일 실시예에 따른 실시간 전송 프로토콜 패킷은 RTP 고정 헤더 (Real time Transport Protocol fixed header), RTP 확장 헤더 (Real time Transport Protocol extension header) 및 페이로드를 포함할 수 있다. RTP 고정 헤더에 타임스탬프 (Timestamp) 필드가 포함될 수 있고, RTP 확장 헤더에 미디어 파일 포맷 타입 정보 (MFF Type) 및 프래그먼트 인디케이터 정보 (Fragment Indicator)가 포함될 수 있다.
Timestamp 필드는 해당 패킷이 샘플링 된 시점을 나타낸다. 이 필드의 값으로 이 패킷의 페이로드 데이터가 재생되어야 하는 타이밍을 알 수 있다. 페이로드에 기술된 데이터에 따라 시간 단위 정보의 값이 달라지게 된다. 본 발명의 일 실시예에서는 MFF 파일이 재생되는 시작점을 나타낸다. 그리고, MFF 파일이 분할되어 전송되는 경우에 분할된 데이터를 포함한 패킷은 모두 동일한 Timestamp 값을 가질 수 있다.
MFF Type 필드는 전송되는 MFF 파일을 구분하기 위한 정보이다. 해당 필드를 통해 수신자는 해당 패킷으로만 독립적으로 재생이 가능한지, 또는 다른 종류의 데이터 패킷과 함께 수신되어야 재생이 가능한지 여부에 대해 분석이 가능할 수 있다. 해당 필드의 값에 대한 의미는 도 7과 같이 나타낼 수 있다.
본 발명의 일 실시예에 따르면, MFF 파일이 데이터의 종류별로 분할되어 전송되는 경우, 수신기는 RTP 패킷의 확장 헤더에 포함된 MFF Type 필드를 통해 패킷을 구분할 수 있다.
Fragment Indicator 필드는 MFF가 데이터 크기에 따라 분할되고 RTP 패킷에 쌓여 전송이 이루어질 경우, 데이터의 경계에 대한 정보를 나타낼 수 있다. 해당 필드의 값에 따른 의미는 후술한다.
본 발명의 일 실시예에 따르면, 송신측에서는 패킷의 크기가 제한되어 있는 상황에서 전송 효율을 증가시키기 위하여 MFF 파일을 데이터의 크기에 따라 분할하여 전송할 수 있다. 수신기는 RTP 패킷의 확장 헤더에 포함된 Fragment Indicator 필드를 통해 분할된 데이터에 대한 경계를 구분할 수 있다. 즉, Fragment Indicator 필드를 통해 수신된 패킷에 포함된 데이터가 MFF 파일의 분할된 첫 번째 데이터, 중간 데이터 및 마지막 데이터 중 어느 하나로 구분될 수 있고 이로써 다른 MFF 파일과 경계를 구분할 수 있다.
예를 들어, 송신자가 용량이 큰 MFF 파일 두 개를 연속적으로 수신자에게 전달하고자 하는 경우, 수신자는 MFF 파일을 포함한 RTP 패킷을 수신하고 RTP의 Sequence Number를 확인하여 패킷의 순서를 정렬할 수 있다. 그리고 Payload Type, SSRC, CCRC를 확인하고 Payload Type 값을 통해 전송되는 파일이 MFF 파일임을 인지할 수 있다. 이 때, 수신기는 RTP 패킷 내 확장 헤더의 Fragment Indicator 값을 통해 분할된 첫 번째 데이터와 분할된 마지막 데이터가 수신되었음을 확인할 수 있고, 이를 이용하여 데이터에 대한 경계를 확인하고 하나의 재생 가능한 데이터가 모두 수신 되었음을 알 수 있다.
도 13은 본 발명의 일 실시예에 따른 프래그먼트 인디케이터 정보 (Fragment Indicator)값과 의미를 나타낸 도면이다.
Fragment Type의 값이 "00"이면, 해당 패킷의 페이로드는 분할되지 않은 데이터를 포함하고 있음을 나타낼 수 있다.
Fragment Type의 값이 "01"이면, 해당 패킷의 페이로드는 분할된 첫 번째 데이터를 포함하고 있음을 나타낼 수 있다.
Fragment Type의 값이 "10"이면, 해당 패킷의 페이로드는 분할된 중간 데이터를 포함하고 있음을 나타낼 수 있다.
Fragment Type의 값이 "11"이면, 해당 패킷의 페이로드는 분할된 마지막 데이터를 포함하고 있음을 나타낼 수 있다.
도 14는 본 발명의 일 실시예에 따른 MFF 파일이 데이터 종류 및 데이터 크기에 따라 분할되어 전송되는 경우에 수신 장치에서 데이터의 처리과정을 나타낸 도면이다.
본 발명의 일 실시예에 따른 MFF 파일이 데이터의 종류 및 데이터 크기에 따라 분할되어 전송되는 경우 수신 장치에서 데이터의 처리과정은 RTP 패킷을 수신하는 단계 (S14010), RTP 패킷의 Payload Type이 MFF 임을 나타내는 값과 동일한지 확인하는 단계 (S14020), Payload Type이 MFF 임을 나타내는 값이 아닌 경우 기존의 RTP 표준 권고 방식에 따라 페이로드의 데이터를 처리하는 단계 (S14110), Payload Type이 MFF 임을 나타내는 값인 경우 MFF Type이 "00"인지 확인하는 단계 (S14030), MFF Type이 "01"인지 확인하는 단계 (S14040), MFF Type이 "01"인 경우 해당 패킷을 RTP 버퍼에 저장하는 단계 (S14050), MFF Type이 "01"이 아닌 경우 MFF Type이 "10"인지 확인하는 단계 (S14060), MFF Type이 "10"인 경우 RTP 버퍼에 MFF Type이 "10"인 패킷이 저장되어 있는지 확인하는 단계 (S14070), MFF Type이 "00"이거나 MFF Type이 "10"이고 이전에 RTP 버퍼에 MFF Type이 "01"인 패킷이 저장되어 있는 경우에 해당 패킷의 Fragment Indicator이 "00"인지 확인하는 단계 (S14120), 해당 패킷의 Fragment Indicator이 "00"이 아닌 경우 "01"인지 확인하는 단계 (S14130), 해당 패킷의 Fragment Indicator이 "01"이 아닌 경우 "11"인지 확인하는 단계 (S14140), 해당 패킷의 Fragment Indicator이 "00"이거나 "11"인 경우 해당 패킷에 포함된 MFF를 분석하는 단계 (S14080), MFF를 복호화하는 단계 (S14090) 및/또는 MFF를 재생하는 단계 (S14100)를 포함할 수 있다.
RTP 패킷을 수신 받은 수신 장치는 일반적인 RTP 분석을 진행하여 버전, 확장여부, CSRC 개수, 패킷 순서, 데이터 재생시점, SSRC 및/또는 CSRC를 확인할 수 있다 (S14010). 이 때 RTP 패킷의 Payload Type이 MFF 임을 나타내는 값과 동일한 경우, 본 발명의 일 실시예에 따른 MFF 파일의 처리 방식을 따르며, Payload Type이 MFF 임을 나타내는 값이 아닌 경우, 기존의 RTP 표준 권고 방식에 따라 페이로드의 데이터를 처리할 수 있다 (S14110).
RTP 패킷의 Payload Type이 MFF 임을 나타내는 값과 동일한 경우, 본 발명의 일 실시예에 따른 RTP 패킷의 확장헤더에 포함된 MFF Type을 확인할 수 있다 (S14020).
MFF Type이 "00"인 경우, 해당 Payload는 독립적으로 재생이 가능한 MFF이므로, 이 경우 이어서 RTP 패킷의 확장헤더에 포함된 Fragment Indicator 값을 확인하여 MFF 파일이 데이터 크기에 따라 분할되었는지 여부를 알 수 있다 (S14030).
Fragment Indicator 값이 "00"인 경우, 해당 패킷의 페이로드에 포함된 데이터는 분할되지 않은 데이터임을 나타내므로 해당 패킷은 MFF Parser로 바로 전달되고 복호화 및 재생이 이루어 진다 (S14120).
Fragment Indicator 값이 "01"인 경우, 해당 패킷은 분할된 데이터의 첫 번째 부분을 포함하고 있으므로 해당 패킷은 버퍼에 저장되고 분할된 데이터의 마지막 부분이 수신될 때까지 새로운 패킷을 수신 받을 수 있다 (S14130).
Fragment Indicator 값이 "10"인 경우, 해당 패킷은 분할된 데이터의 중간 부분을 포함하고 있으므로 해당 패킷은 버퍼에 저장되고 분할된 데이터의 마지막 부분이 수신될 때까지 새로운 패킷을 수신 받을 수 있다.
Fragment Indicator 값이 "11"인 경우, 해당 패킷은 분할된 데이터의 마지막 부분을 포함하고 있으므로 버퍼에 저장된 이전 순서의 데이터들과 함께 MFF Parser로 전달되고 복호화 및 재생이 이루어 진다 (S14140, S14080, S14090, S14100).
하지만, MFF Type이 "01"인 경우, 해당 Payload가 Initial Partial MFF임이 인지될 수 있고 (S14040), 해당 패킷은 MFF Type이 "01"인 값을 가진 패킷이 수신될 때까지 버퍼에 저장되며 새로운 RTP 패킷을 수신 받을 수 있다 (S14050). 이 때 만약 처음 수신된 RTP 패킷의 MFF Type이 "00"과 "01"이 아닐 경우 수신기는 새로운 패킷을 수신 받을 수 있다.
MFF Type이 "10"인 경우, 기존에 MFF Type 값이 "01"인 RTP 패킷이 수신되었는지 여부를 판단하고 (S14060, S14070), 버퍼에 MFF Type이 "10"인 패킷과 "01"인 패킷 모두가 존재할 경우, 이어서 RTP 패킷의 확장헤더에 포함된 Fragment Indicator 값을 확인하여 MFF 파일이 데이터 크기에 따라 분할되었는지 여부를 알 수 있다 (S14120).
Fragment Indicator 값이 "00"인 경우, 해당 패킷의 페이로드에 포함된 데이터는 분할되지 않은 데이터임을 나타내므로 해당 패킷은 MFF Parser로 바로 전달되고 복호화 및 재생이 이루어 진다 (S14120, S14080, S14090, S14100).
Fragment Indicator 값이 "01"인 경우, 해당 패킷은 분할된 데이터의 첫 번째 부분을 포함하고 있으므로 해당 패킷은 버퍼에 저장되고 분할된 데이터의 마지막 부분이 수신될 때까지 새로운 패킷을 수신 받을 수 있다 (S14130, S14050).
Fragment Indicator 값이 "10"인 경우, 해당 패킷은 분할된 데이터의 중간 부분을 포함하고 있으므로 해당 패킷은 버퍼에 저장되고 분할된 데이터의 마지막 부분이 수신될 때까지 새로운 패킷을 수신 받을 수 있다.
Fragment Indicator 값이 "11"인 경우, 해당 패킷은 분할된 데이터의 마지막 부분을 포함하고 있으므로 버퍼에 저장된 이전 순서의 데이터들과 함께 MFF Parser로 전달되고 복호화 및 재생이 이루어 진다 (S14140, S14080, S14090, S14100).
도 15는 본 발명의 일 실시예에 따른 Completed MFF를 포함한 RTP 패킷의 헤더를 나타낸 도면이다.
당해 도면에서 도시된 바와 같이, 20초짜리 미디어 콘텐트는 10초짜리 Completed MFF 파일 두 개로 분할되어 인코딩 될 수 있다.
1st RTP 패킷은 0초부터 시작하는 데이터를 포함하므로 Timestamp 값이 0으로 표시될 수 있으며, Payload Type은 "71"로 표시되어 MFF 파일임을 나타낼 수 있다. Sequence Number는 임의의 숫자로 시작될 수 있으며, 도 15의 일 실시예의 경우 "10"부터 시작되었음을 알 수 있다. MFF Type이 "00"이므로 해당 패킷의 페이로드에 Completed MFF 파일이 포함됨을 알 수 있다.
2nd RTP 패킷은 11초부터 시작하는 데이터를 포함하므로 Timestamp 값이 11000으로 표시될 수 있으며, Sequence Number 값은 "11"로 표시될 수 있다. 그리고 나머지 필드 값들은 1st RTP 패킷과 동일한 값을 가질 수 있다..
도 16은 본 발명의 일 실시예에 따른 MFF 파일이 Initial Partial MFF 파일과 Media Partial MFF 파일로 분할되어 RTP 패킷을 통해 전송되는 경우 RTP 패킷의 헤더를 나타낸 도면이다.
당해 도면에서 도시된 바와 같이, 20초짜리 미디어 콘텐트는 Initial Partial MFF 파일 한 개, 10초짜리 Media Partial MFF 파일 두 개로 분할되어 인코딩 될 수 있다.
1st RTP 패킷은 Initial Partial MFF 파일을 포함하므로 가장 먼저 분석이 이루어져야 한다. 따라서, 추후에 수신되는 Media Partial MFF 파일과 같거나 더 빠른 Timestamp 값을 가져야 한다. 해당 패킷의 Timestamp는 0을 가질 수 있으며 Payload Type은 "71"으로 표시되어 MFF 파일임을 나타낼 수 있다. Sequence Number는 임의의 숫자로 시작될 수 있으며, 도 16의 일 실시예의 경우 "10"부터 시작되었음을 알 수 있다. MFF Type은 "01"이므로 해당 패킷의 페이로드에 Initial Partial MFF 파일이 포함됨을 알 수 있다.
2nd RTP 패킷은 0초부터 시작되는 Media Partial MFF 파일을 포함하므로 Timestamp 값이 0으로 표시될 수 있으며, Payload Type은 "71"로 표시되어 MFF 파일임을 나타낼 수 있다. Sequence Number는 "11"로 표시되며, MFF Type이 "10"이므로 해당 패킷의 페이로드에 Media Partial MFF 파일이 포함됨을 알 수 있다.
3rd RTP 패킷은 11초부터 시작되는 Media Partial MFF 파일을 포함하므로 Timestamp 값이 11000으로 표시될 수 있으며, Payload Type은 "71"로 표시되어 MFF 파일임을 나타낼 수 있다. Sequence Number는 "12"로 표시되며, MFF Type이 "10"이므로 해당 패킷의 페이로드에 Media Partial MFF 파일이 포함됨을 알 수 있다.
도 17은 본 발명의 일 실시예에 따른 RTP 패킷의 페이로드에 Completed MFF가 포함되어 전송되는 경우에 RTP 패킷 및 Completed MFF의 구조를 나타낸 도면이다.
본 발명의 일 실시예에 따른 수신 장치는 당해 도면에서 도시된 바와 같은 패킷을 수신 받으면 RTP 패킷의 헤더를 분석하여 패킷의 순서, 데이터의 종류와 재생 시작점 등에 대한 정보를 파악한 뒤 Payload 안의 MFF를 분석할 수 있다.
당해 도면에서 도시된 바와 같이, MFF는 계층 형태의 데이터 구조를 갖출 수 있다. 해당 MFF에서 최상위 계층 정보는 moov 박스와 mdat 박스로 분할되어 구성될 수 있다.
moov 박스에는 파일 재생에 관련된 메타 데이터가 포함될 수 있으며, mdat 박스에는 복호화가 이루어져야 하는 미디어 데이터가 비트열로 나열되어 포함될 수 있다.
수신기는 먼저 moov 박스 내부의 mvhd 박스에 포함된 @timescale 값을 통해 재생에 사용되는 시간규격 즉, 초당 몇 번의 tic이 발생 하는지를 알 수 있고, mvhd 박스에 포함된 @duration 값을 통해 해당 미디어 콘텐트의 총 길이와 다른 기타 정보들을 알 수 있다.
그리고, 수신기는 moov 박스 내부의 trak 박스의 하위 계층인 tkhd 박스를 분석하여 @track ID, @width, @height 등의 기타 정보들을 알 수 있으며, 수신기는 trak 박스의 또 다른 하위 계층인 minf 박스의 아래에 위치한 vmhd 박스의 존재를 통해 해당 track이 비디오에 대한 정보임을 알 수 있다. 또한, 수신기는 minf 박스의 하위 계층인 stbl 박스 아래에 위치한 stts의 값을 통해 해당 MFF에 포함된 전체 샘플(비디오 프레임)의 개수와 샘플 별 duration 값 등의 정보들을 알 수 있다. 그리고, stco 박스에 포함된 정보를 통해 실제 미디어 정보들이 비트열로 나열되어 있는 mdat 박스 안에서의 샘플 별 경계를 알 수 있다.
본 발명의 일 실시예에 따른 Completed MFF를 구성하는 각 박스에 대한 설명은 전술한 미디어 파일 포맷 (Media File Format; MFF)의 구조를 나타낸 도면에 관한 설명으로 대체한다.
본 발명의 일 실시예에 따른 RTP 패킷의 헤더에 포함된 각 필드에 대한 설명은 전술한 RTP (Real time Transport Protocol) 패킷의 헤더 구조를 나타낸 도면에 관한 설명으로 대체한다.
도 18은 본 발명의 일 실시예에 따른 RTP 패킷의 페이로드에 Initial Partial MFF가 포함되어 전송되는 경우에 RTP 패킷 및 Initial Partial MFF의 구조를 나타낸 도면이다.
본 발명의 일 실시예에 따른 수신 장치는 당해 도면에서 도시된 바와 같은 패킷을 수신 받으면 RTP 패킷의 헤더를 분석하여 패킷의 순서, 데이터의 종류와 재생 시작점 등에 대한 정보를 파악한 뒤 Payload 안의 MFF를 분석할 수 있다.
당해 도면에서 도시된 바와 같이, MFF는 계층 형태의 데이터 구조를 갖출 수 있다. 해당 MFF에서 최상위 계층 정보로 파일 재생에 관련된 메타 데이터를 포함하는 moov 박스가 존재할 수 있다.
수신기는 먼저 moov 박스 내부의 mvhd 박스에 포함된 @timescale 값을 통해 재생에 사용되는 시간규격 즉, 초당 몇 번의 tic이 발생 하는지를 알 수 있고, mvhd 박스에 포함된 @duration 값을 통해 해당 미디어 콘텐트의 총 길이와 다른 기타 정보들을 알 수 있다.
그리고, 수신기는 moov 박스 내부의 trak 박스의 하위 계층인 tkhd 박스를 분석하여 @track ID, @width, @height 등의 기타 정보들을 알 수 있으며, 수신기는 trak 박스의 또 다른 하위 계층인 minf 박스에 포함된 stbl 박스 아래에 위치한 stts의 값을 통해 해당 MFF에 포함된 전체 샘플(비디오 프레임)의 개수와 샘플 별 duration 값 등의 정보들을 알 수 있다. 그리고, stco 박스에 포함된 정보를 통해 실제 미디어 정보들이 비트열로 나열되어 있는 mdat 박스 안에서의 샘플 별 경계를 알 수 있다. mdat 박스는 Initial Partial MFF 파일을 포함하는 패킷에 이어서 수신되는 Media Partial MFF 파일에 포함될 수 있다.
본 발명의 일 실시예에 따른 수신 장치는 Initial Partial MFF의 각각의 박스에 포함된 정보를 통하여 수신되는 전체 콘텐트에 대한 정보를 알 수 있다.
본 발명의 일 실시예에 따른 Initial Partial MFF를 구성하는 각 박스에 대한 설명은 전술한 미디어 파일 포맷 (Media File Format; MFF)의 구조를 나타낸 도면에 관한 설명으로 대체한다.
본 발명의 일 실시예에 따른 RTP 패킷의 헤더에 포함된 각 필드에 대한 설명은 전술한 RTP (Real time Transport Protocol) 패킷의 헤더 구조를 나타낸 도면에 관한 설명으로 대체한다.
도 19는 본 발명의 일 실시예에 따른 RTP 패킷의 페이로드에 Media Partial MFF가 포함되어 전송되는 경우에 RTP 패킷 및 Media Partial MFF의 구조를 나타낸 도면이다.
본 발명의 일 실시예에 따른 수신 장치는 당해 도면에서 도시된 바와 같은 패킷을 수신 받으면 RTP 패킷의 헤더를 분석하여 패킷의 순서, 데이터의 종류와 재생 시작점 등에 대한 정보를 파악한 뒤 Payload 안의 MFF를 분석할 수 있다.
당해 도면에서 도시된 바와 같이, MFF는 계층 형태의 데이터 구조를 갖출 수 있다. 해당 MFF에서 최상위 계층 정보는 sidx 박스, moof 박스 및 mdat 박스로 분할되어 구성될 수 있다.
sidx 박스에는 track 정보, 분할된 sequence number, 분할된 미디어의 총 길이 등의 기타 정보들이 포함될 수 있다.
moof 박스의 하위에 위치한 traf 박스에 포함된 tfhd 박스를 통해 수신기는 해당 Media Partial MFF 파일이 분할된 미디어의 몇 번째 데이터 인지를 알 수 있다.
그리고, 수신기는 trun 박스를 통해 mdat 박스의 샘플에 대한 경계 및 재생 시점 샘플의 개수 등의 정보를 알 수 있다.
전술한 데이터 처리 과정을 거쳐 본 발명의 일 실시예에 따른 수신 장치는 Media Partial MFF의 분할된 미디어에 대한 재생 정보 및 재생 파일을 알 수 있다.
본 발명의 일 실시예에 따른 Media Partial MFF를 구성하는 각 박스에 대한 설명은 전술한 Media Partial MFF의 구조를 나타낸 도면에 관한 설명으로 대체한다.
본 발명의 일 실시예에 따른 RTP 패킷의 헤더에 포함된 각 필드에 대한 설명은 전술한 RTP (Real time Transport Protocol) 패킷의 헤더 구조를 나타낸 도면에 관한 설명으로 대체한다.
도 20은 본 발명의 일 실시예에 따른 MFF 파일이 데이터 종류 및 데이터 크기에 따라 분할되어 RTP 패킷을 통해 전송되는 경우 RTP 패킷의 헤더를 나타낸 도면이다.
당해 도면에서 도시된 바와 같이, 20초짜리 미디어 콘텐트는 먼저 데이터의 종류에 따라 Initial Partial MFF와 5초, 5초, 10초짜리 Media Partial MFF로 분할되고 그 다음에 데이터의 크기에 따라 수 개의 MFF로 분할되어 RTP 패킷으로 패킷화될 수 있다.
방송 시스템과 같이, 수신 측에서는 데이터를 언제 수신 받을지 예측할 수 없으므로 송신 측은 Initial Partial MFF를 주기적으로 전송할 수 있다.
첫 번째 Initial Partial MFF가 데이터 크기에 따라 2개의 데이터로 분할되어 전송되는 경우, 1st RTP 패킷의 Timestamp는 0이며, Payload Type 값은 "71", Sequence Number 값은 임의의 숫자 "10"으로 시작할 수 있다. 1st RTP 패킷은 Initial Partial MFF 파일의 분할된 첫 번째 데이터를 포함하는 패킷이므로 Fragment Indicator의 값은 "01"을 가지며, MFF Type 값은 "01"을 가질 수 있다. 2nd RTP 패킷은 1st RTP 패킷과 동일한 Timestamp, Payload Type 값을 가지며, Sequence Number는 "11"을 가질 수 있다. 2nd RTP 패킷은 Initial Partial MFF 파일의 분할된 마지막 데이터를 포함하는 패킷이므로 Fragment Indicator의 값은 "11"을 가지며, MFF Type 값은 "01"을 가질 수 있다.
두 번째 Media Partial MFF가 3rd RTP 패킷에 포함되어 전송되는 경우, 3rd RTP 패킷은 미디어의 첫 재생 시점을 포함하고 있으므로 Timestamp는 "0"을 가지며, Payload Type은 "71", Sequence Number는 "12"를 가질 수 있다. 그리고, 3rd RTP 패킷은 분할되지 않은 Media Partial MFF 파일을 포함하는 패킷이므로 Fragment Indicator의 값은 "00"을 가지며, MFF Type 값은 "10"을 가질 수 있다.
세 번째 Media Partial MFF가 2개의 RTP 패킷으로 분할되어 전송되는 경우, 4th RTP 패킷의 Timestamp는 "6000"으로 표시되어 해당 콘텐트가 6초부터 시작됨을 알 수 있으며, Sequence Number는 "13"을 가질 수 있다. 4th RTP 패킷은 Media Partial MFF 파일의 분할된 첫 번째 데이터를 포함하는 패킷이므로 Fragment Indicator의 값은 "01"을 가지며, MFF Type 값은 "10"을 가질 수 있다. 5th RTP 패킷은 4th RTP 패킷과 동일한 Timestamp, Payload Type 값을 가지며, Sequence Number는 "14"를 가질 수 있다. 5th RTP 패킷은 Media Partial MFF 파일의 분할된 마지막 데이터를 포함하는 패킷이므로 Fragment Indicator의 값은 "11"를 가지며, MFF Type 값은 "10"을 가질 수 있다.
네 번째 Initial Partial MFF가 6th RTP 패킷에 포함되어 전송되는 경우, 6th RTP 패킷은 1st RTP 패킷과 동일한 Payload Type, Fragment Indicator, MFF Type 값을 가질 수 있고, Sequence Number 값은 "15"로, Timestamp 값은 이후에 전송되는 Media Partial MFF보다 빠른 값인 "10000"을 가질 수 있다.
다섯 번째 Media Partial MFF가 3개의 RTP 패킷으로 분할되어 전송되는 경우, 7th RTP 패킷의 Payload Type은 "71", Sequence Number는 "16"을 가질 수 있고, Timestamp 값은 "11000"으로 표시되어 해당 미디어가 11초에 대한 시간정보를 가지고 있음을 나타낼 수 있다. 7th RTP 패킷은 Media Partial MFF 파일의 분할된 첫 번째 데이터를 포함하는 패킷이므로 Fragment Indicator의 값은 "01"을 가지며, MFF Type 값은 "10"을 가질 수 있다. 8th RTP 패킷은 7th RTP 패킷과 동일한 Timestamp, Payload Type 값을 가질 수 있고 Sequence Number는 "17"을 가질 수 있다. 8th RTP 패킷은 Media Partial MFF 파일의 분할된 중간 데이터를 포함하는 패킷이므로 Fragment Indicator값은 "10"을 가지며, MFF Type 값은 "10"을 가질 수 있다. 9th RTP 패킷의 Timestamp, Payload Type은 8th RTP 패킷과 동일하며, Sequence Number는 "18"을 가질 수 있다. 9th RTP 패킷은 Media Partial MFF 파일의 분할된 마지막 데이터를 포함하는 패킷이므로 Fragment Indicator의 값은 "11"를 가지며, MFF Type 값은 "10"을 가질 수 있다.
도 21은 본 발명의 일 실시예에 따른 지상파 방송망과 인터넷 프로토콜망 연동 기반의 하이브리드 방송 서비스 수신 장치의 동작 흐름을 나타낸 도면이다.
본 발명의 일 실시예에 따른 하이브리드 방송 서비스 수신 장치는, 채널 동기부 (Channel Synchronizer; 21010), 채널 이퀄라이저 (Channel Equalizer; 21020), 채널 디코더 (Channel Decoder; 21030), 시그널링 디코더 (Signaling Decoder; 21040), 베이스밴드 작동 제어부 (Baseband Operation Controller; 21050), 트랜스포트 패킷 인터페이스 (Transport Packet Interface; 21060), 브로드밴드 패킷 인터페이스 (Broadband Packet Interface; 21070), 공통 프로토콜 스택 (Common Protocol Stack; 21080), 어플리케이션 처리부 (Application Processor; 21090), 서비스 가이드 처리부 (Service Guide Processor; 21100), 오디오/비디오 처리부 (A/V Processor; 21110), 서비스 시그널링 채널 처리 버퍼 및 파서 (Service Signaling Channel Processing Buffer and Parser; 21120), 서비스 맵 데이터베이스 (Service Map DB; 21130) 및/또는 서비스 가이드 데이터 베이스 (Service Guide DB; 21140)를 포함한다.
채널 동기부 (Channel Synchronizer; 21010)는 베이스밴드에서 적절한 디코딩이 가능하도록 심볼 주파수와 시간(timing)을 동기화하는 기능을 수행할 수 있다.
채널 이퀄라이저 (Channel Equalizer; 21020)는 수신된 신호가 Multipath, Doppler effect 등으로 인해 왜곡되었을 경우 이를 보상하는 기능을 수행할 수 있다.
채널 디코더 (Channel Decoder; 21030)는 수신된 신호를 의미를 가지는 데이터로 복구하는 기능을 수행할 수 있다. 또한, FEC (Forward Error Correction)를 수행할 수 있다.
시그널링 디코더 (Signaling Decoder; 21040)는 채널로부터 전달되는 시그널링 데이터를 추출하고 디코딩하는 기능을 수행할 수 있다. 본 발명의 일 실시예에 따른 지상파 방송망을 통해 전송되는 시그널링 데이터는 시그널링 디코더 (21040)에서 추출 및 디코딩될 수도 있고, 후술할 서비스 시그널링 채널 처리 버퍼 및 파서 (Service Signaling Channel Processing Buffer and Parser; 21120)에서 추출 및 디코딩될 수도 있다.
베이스밴드 작동 제어부 (Baseband Operation Controller; 21050)는 베이스밴드에 관련된 여러 가지 처리 과정을 제어하는 기능을 수행할 수 있다.
트랜스포트 패킷 인터페이스 (Transport Packet Interface; 21060)는 채널 디코더 (21030)로부터 수신한 방송 스트림에서 트랜스포트 패킷 (Transport Packet)을 추출하는 기능을 수행할 수 있다. 또한, 추출된 트랜스 포트 패킷으로부터 시그널링 또는 IP 데이터그램 (IP datagram)등을 조합하는 기능을 수행할 수 있다.
브로드밴드 패킷 인터페이스 (Broadband Packet Interface; 21070)는 인터넷 프로토콜망을 통해 획득된 패킷 (Packet)을 추출하고 해당 패킷으로부터 시그널링 또는 A/V 데이터 등을 조합하는 기능을 수행할 수 있다.
공통 프로토콜 스택 (Common Protocol Stack; 21080)은 도 1의 프로토콜 스택에 해당할 수 있다. 공통 프로토콜 스택 (21080)에서 패킷 단위로 묶인 데이터들은 프로토콜의 각 계층을 거치면서 시그널링, 오디오 데이터, 비디오 데이터, 서비스 가이드 데이터 등으로 구분될 수 있다.
어플리케이션 처리부 (Application Processor; 21090)는 수신 신호로부터 어플리케이션 관련 정보를 추출하고 처리하는 기능을 수행할 수 있다.
서비스 가이드 처리부 (Service Guide Processor; 21100)는 수신 신호로부터 어나운스먼트 (Announcement) 정보를 추출할 수 있고, 후술할 서비스 가이드 데이터 베이스 (Service Guide Database; 21140)를 관리할 수 있으며, 서비스 가이드를 제공하는 기능을 수행할 수 있다.
오디오/비디오 처리부 (A/V Processor; 21110)는 수신된 오디오 및 비디오 데이터를 디코딩하고 재생 (Presentation)하는 기능을 수행할 수 있다.
서비스 시그널링 채널 처리 버퍼 및 파서 (Service Signaling Channel Processing Buffer and Parser; 21120)는 IP 데이터그램 등으로부터 서비스 또는 컨텐츠의 스캔 및 획득 등과 관련된 시그널링 정보를 추출하고 파싱하는 기능을 수행할 수 있다. 또한, 서비스 시그널링 채널 처리 버퍼 및 파서 (21120)는 전술한 시그널링 디코더 (21040)를 포함할 수 있다. 또한, 시그널링 디코더 (21040)다 포함된 서비스 시그널링 채널 처리 버퍼 및 파서 (21120)는 시그널링 정보 처리부라고 명명될 수 있으며, 시그널링 디코더 (21040, 시그널링 채널 처리 버퍼 및 파서 (21120) 각각을 시그널링 정보 처리부라고 명명할 수 있다. 본 발명의 일 실시예에 따른 서비스 정보 테이블에 포함된 컴포넌트 식별 정보, 전송 네트워크 타입 정보, 데이터 경로 정보, ISO base media file format 규격의 버전 정보 및/또는 ISO base media file format 스트림의 프로파일 정보는 방송 서비스의 획득과 관련된 시그널링 정보로서 시그널링 정보 처리부에 의해서 추출되고 파싱될 수 있다.
서비스 맵 데이터베이스 (Service Map DB; 21130)는 시그널링 디코더 (21040), 서비스 시그널링 채널 처리 버퍼 및 파서 (21120)또는 시그널링 정보 처리부에 의해 디코딩된 시그널링 정보를 저장하는 기능을 수행할 수 있다.
서비스 가이드 데이터베이스 (Service Guide DB; 21140)는 서비스 가이드 처리부 (21100)를 통해 추출 및 처리된 서비스 가이드를 저장하는 기능을 수행할 수 있다.
도 22는 본 발명의 일 실시예에 따른 미디어 방송 신호의 송신 방법의 흐름을 나타낸 도면이다.
본 발명의 일 실시예에 따르면, 미디어 방송 신호는 다음과 같은 과정을 거쳐 송신될 수 있다. 먼저, 데이터를 미디어 파일 포맷 (Media File Format; MFF)으로 인코딩한다(S22010). 여기서, 데이터는 오디오 데이터나 비디오 데이터와 같은 미디어 데이터를 포함할 수 있다. 그리고 미디어 파일 포맷에 대한 설명은 전술한 용어 및 약어에 대한 설명 부분에서 기술하였다. 다음 과정으로, 인코딩된 미디어 파일 포맷 파일을 데이터 종류에 따라 초기 부분 MFF 파일과 미디어 부분 MFF 파일로 분할할 수 있다(S22020). 이 때, 초기 부분 MFF 파일은 미디어 파일 전체의 재생 정보 및 초기 재생 정보를 가진 메타데이터를 포함할 수 있고, 미디어 부분 MFF 파일은 미디어데이터와 상기 미디어데이터에 관련된 부분적 재생 정보를 가진 메타데이터를 포함할 수 있다. 이에 대한 설명은 도 6 내지 11의 설명 부분에서 전술하였다. 다음 과정으로, 실시간 전송을 위한 프로토콜에 따라 상기 분할된 미디어 파일 포맷 파일을 포함하는 패킷을 생성한다(S22030). 여기서, 전송 프로토콜은 실시간 전송 프로토콜, 비실시간 전송 프로토콜 등을 포함할 수 있고, 이와 같은 전송 프로토콜에 따라 상기 단계에서 미디어 파일 포맷으로 인코딩된 미디어 파일을 패킷화한다. 이 때, 상기 생성된 패킷의 헤더는 페이로드에 포함된 상기 분할된 미디어 파일 포맷 파일이 초기 부분 MFF 파일인지 미디어 부분 MFF 파일인지를 식별하는 미디어 파일 포맷 (MFF) 타입 정보를 포함할 수 있다. 이에 대한 내용은 도 6 내지 11 및 도 15 내지 20에서 전술하였다. 다음 과정으로, 상기 생성된 패킷을 전송한다(S22040). 여기서, 상기 전송 프로토콜에 의해 패킷화된 데이터들은 지상파 방송망, 케이블망 및 인터넷 프로토콜망 중 적어도 어느 하나를 통해 전송될 수 있다.
본 발명의 또 다른 일 실시예에 따르면, 상기 패킷을 생성하는 단계(S22030)에서 생성된 패킷의 헤더에는 페이로드에 포함된 데이터의 포맷을 나타내는 페이로드 타입 정보가 포함될 수 있고 페이로드 타입 정보에 대한 내용은 도 4에 대한 설명 부분에서 전술하였다. 또한, 상기 페이로드 타입 정보에는 여러 종류의 파일 포맷들이 정의되어 있다. 상기 페이로드 타입 정보는 페이로드에 포함된 데이터가 미디어 파일 포맷 (MFF)임을 식별할 수 있다. 이에 대한 내용은 도 5에 대한 설명 부분에서 전술하였다.
본 발명의 또 다른 일 실시예에 따르면, 상기 패킷을 생성하는 단계(S22030)에서 생성된 패킷의 헤더는 페이로드에 포함된 미디어 파일 포맷 (MFF) 파일이 재생되는 시작점을 나타내는 타임스탬프 정보를 포함할 수 있다. 그리고, 상기 초기 부분 MFF 파일이 포함된 패킷은 상기 미디어 부분 MFF 파일이 포함된 패킷과 같거나 더 빠른 타임스탬프 정보를 가질 수 있다. 이에 대한 설명은 도 6 및 16의 설명 부분에서 전술하였다.
본 발명의 또 다른 일 실시예에 따르면, 상기 초기 부분 MFF 파일이 포함된 패킷은 주기적으로 계속하여 전송될 수 있다. 이에 대한 설명은 도 6 및 9의 설명 부분에서 전술하였다.
본 발명의 또 다른 일 실시예에 따르면, 인코딩된 미디어 파일 포맷 파일을 데이터의 종류에 따라 분할하는 단계 대신 데이터의 크기에 따라 분할하는 단계를 포함할 수 있다. 당해 실시예와 같이 미디어 파일 포맷 파일을 데이터의 크기에 따라 분할하여 전송하는 경우, 상기 분할된 미디어 파일 포맷 파일을 전송하는 패킷의 헤더에는 당해 패킷의 페이로드에 포함된 분할된 미디어 파일 포맷 파일을 데이터의 순서에 따라 구분하는 프래그먼트 인디케이터 정보가 포함될 수 있다. 이에 대한 내용은 도 12 내지 14 및 도 20에서 전술하였다.
본 발명의 또 다른 일 실시예에 따르면, 인코딩된 미디어 파일 포맷 파일은 데이터의 순서에 따라서 전체 미디어 파일을 구성하는, 첫 번째 데이터, 중간 데이터 및 마지막 데이터 중 어느 하나로 분할될 수 있다. 그리고, 미디어 파일 포맷 파일이 데이터 크기에 따라 분할되어 전송되는 경우, 상기 분할된 미디어 파일 포맷 파일을 전송하는 패킷의 헤더에는 당해 패킷의 페이로드에 포함된 미디어 파일 포맷 파일의 재생 시작점을 나타내는 타임스탬프 정보를 포함할 수 있다. 그리고, 데이터 순서에 따라 구분되는 미디어 파일 포맷 파일을 전송하는 각 패킷은 모두 동일한 타임스탬프 정보를 가질 수 있다. 이에 대한 설명은 도 12 내지 14의 설명 부분에서 전술하였다.
본 발명의 또 다른 일 실시예에 따르면, 데이터의 종류에 따라서 분할된 미디어 파일 포맷 파일은 데이터의 크기에 따라서 또 다시 분할되어 전송될 수 있다. 이에 대한 설명은 도 20의 설명 부분에서 전술하였다.
본 발명의 또 다른 일 실시예에 따르면, 미디어 파일 포맷 파일을 전송하는 프로토콜은 실시간 전송을 위한 프로토콜이 사용될 수 있고, 실시간 전송을 위한 프로토콜 중에 RTP (Real time Transport Protocol)이 사용될 수 있다.
본 발명의 또 다른 일 실시예에 따르면, 전송되는 미디어 파일 포맷 파일은 ISOBMFF (ISO Base Media File Format)을 포함할 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 당업자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.
본 발명에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상술한 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 발명의 영상 처리 방법은 네트워크 디바이스에 구비된 프로세서가 읽을 수 있는 기록매체에 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수가 있다.
발명의 실시를 위한 형태는 전술한 바와 같이, 발명의 실시를 위한 최선의 형태로 상술되었다.
본 발명은 방송 산업 전반에서 이용 가능하다.

Claims (13)

  1. 실시간 전송을 위한 프로토콜에 의한 패킷을 수신하는 수신부,
    여기서, 상기 패킷의 페이로드는 데이터 종류에 따라 분할된 미디어 파일 포맷 (MFF) 파일을 포함하고, 상기 분할된 미디어 파일 포맷 (MFF) 파일은 전체 재생 정보와 초기 재생 정보를 가진 메타데이터를 포함하는 초기 부분 MFF 파일 및 미디어데이터와 상기 미디어데이터에 관련된 부분적 재생 정보를 가진 메타데이터를 포함하는 미디어 부분 MFF 파일 중 어느 하나에 해당하고,
    여기서, 상기 패킷의 헤더는 페이로드에 포함된 상기 분할된 미디어 파일 포맷 (MFF) 파일이 초기 부분 MFF 파일인지 미디어 부분 MFF 파일인지를 식별하는 미디어 파일 포맷 (MFF) 타입 정보를 포함하고;
    미디어 파일 포맷 (MFF) 파일을 분석하여 메타데이터와 미디어데이터를 구분하고 재생에 필요한 정보를 추출하는 파싱부;
    상기 파싱부로부터 출력된 미디어 파일 포맷 (MFF) 파일을 복호하는 디코더;
    상기 파싱부에서 추출된 정보를 이용하여 복호된 미디어 파일 포맷 (MFF) 파일을 재생하는 재생부;
    를 포함하는 미디어 방송 신호 수신 장치.
  2. 제 1 항에 있어서
    상기 미디어 방송 신호 수신 장치는 상기 수신된 패킷의 페이로드에 포함된 데이터를 저장하는 버퍼; 및 초기 부분 MFF 파일을 포함한 패킷을 수신하는 경우 상기 초기 부분 MFF 파일이 버퍼에 저장되도록 제어하고, 미디어 부분 MFF 파일을 포함한 패킷을 수신하는 경우 초기 부분 MFF 파일이 버퍼에 저장되어 있는지 확인하여 버퍼에 저장되어 있으면 미디어 부분 MFF 파일을 버퍼에 저장된 초기 부분 MFF 파일과 함께 파싱부로 출력되도록 제어하고, 버퍼에 저장되어 있지 않으면 수신부로 하여금 새로운 패킷을 수신하도록 제어하는 제어부;를 더 포함하는 것을 특징으로 하는 미디어 방송 신호 수신 장치.
  3. 제 1 항에 있어서
    상기 패킷의 헤더는 페이로드에 포함된 데이터의 포맷을 나타내는 페이로드 타입 정보를 포함하고, 상기 페이로드 타입 정보는 페이로드에 포함된 데이터가 미디어 파일 포맷 (Media File Format; MFF)임을 식별하는 것을 특징으로 하는 미디어 방송 신호 수신 장치.
  4. 제 1 항에 있어서,
    상기 패킷의 헤더는 페이로드에 포함된 미디어 파일 포맷 (MFF) 파일이 재생되는 시작점을 나타내는 타임스탬프 정보를 더 포함하고,
    상기 초기 부분 MFF 파일이 포함된 패킷은 상기 미디어 부분 MFF 파일이 포함된 패킷과 같거나 더 빠른 타임스탬프 정보를 갖는 것을 특징으로 하는 미디어 방송 신호 수신 장치.
  5. 제 1 항에 있어서,
    상기 초기 부분 MFF 파일이 포함된 패킷은 주기적으로 계속하여 수신되는 것을 특징으로 하는 미디어 방송 신호 수신 장치.
  6. 제 1 항에 있어서,
    상기 실시간 전송을 위한 프로토콜은 RTP (Real time Transport Protocol)을 포함하는 것을 특징으로 하는 미디어 방송 신호 수신 장치.
  7. 제 1 항에 있어서,
    상기 미디어 파일 포맷 (Media File Format)은 ISOBMFF (ISO Base Media File Format)을 포함하는 것을 특징으로 하는 미디어 방송 신호 수신 장치.
  8. 오디오데이터 및/또는 비디오데이터를 포함하는 미디어데이터를 미디어 파일 포맷 (Media File Format; MFF)으로 인코딩하는 단계;
    상기 인코딩된 미디어 파일 포맷 (MFF) 파일을 데이터 종류에 따라 전체 재생 정보 및 초기 재생 정보를 가진 메타데이터를 포함하는 초기 부분 MFF 파일과 미디어데이터 및 상기 미디어데이터에 관련된 부분적 재생 정보를 가진 메타데이터를 포함하는 미디어 부분 MFF 파일로 분할하는 단계;
    실시간 전송을 위한 프로토콜에 따라 상기 분할된 미디어 파일 포맷 (MFF) 파일을 포함하는 패킷을 생성하는 단계,
    여기서, 상기 생성된 패킷의 헤더는 페이로드에 포함된 상기 분할된 미디어 파일 포맷 (MFF) 파일이 초기 부분 MFF 파일인지 미디어 부분 MFF 파일인지를 식별하는 미디어 파일 포맷 (MFF) 타입 정보를 포함하고;
    상기 생성된 패킷을 전송하는 단계;
    를 포함하는 미디어 방송 신호 송신 방법.
  9. 제 8 항에 있어서,
    상기 생성된 패킷의 헤더는 페이로드에 포함된 데이터의 포맷을 나타내는 페이로드 타입 정보를 포함하고, 상기 페이로드 타입 정보는 페이로드에 포함된 데이터가 미디어 파일 포맷 (MFF)임을 식별하는 것을 특징으로 하는 미디어 방송 신호 송신 방법.
  10. 제 8 항에 있어서,
    상기 생성된 패킷의 헤더는 페이로드에 포함된 미디어 파일 포맷 (MFF) 파일이 재생되는 시작점을 나타내는 타임스탬프 정보를 더 포함하고,
    상기 초기 부분 MFF 파일이 포함된 패킷은 상기 미디어 부분 MFF 파일이 포함된 패킷과 같거나 더 빠른 타임스탬프 정보를 갖는 것을 특징으로 하는 미디어 방송 신호 송신 방법.
  11. 제 8 항에 있어서,
    상기 초기 부분 MFF 파일이 포함된 패킷은 주기적으로 계속하여 전송되는 것을 특징으로 하는 미디어 방송 신호 송신 방법.
  12. 제 8 항에 있어서,
    상기 실시간 전송을 위한 프로토콜은 RTP (Real time Transport Protocol)을 포함하는 것을 특징으로 하는 미디어 방송 신호 송신 방법.
  13. 제 8 항에 있어서,
    상기 미디어 파일 포맷 (Media File Format)은 ISOBMFF (ISO Base Media File Format)을 포함하는 것을 특징으로 하는 미디어 방송 신호 송신 방법.
PCT/KR2014/006011 2013-07-05 2014-07-04 실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 방송 신호의 송수신 방법 및 장치 WO2015002500A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
KR1020157037197A KR20160030133A (ko) 2013-07-05 2014-07-04 실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 방송 신호의 송수신 방법 및 장치
US14/902,781 US20160173556A1 (en) 2013-07-05 2014-07-04 Method and apparatus for transmitting/receiving media broadcasting signal in real time transport protocol-based broadcasting system
CA2917290A CA2917290C (en) 2013-07-05 2014-07-04 Method and apparatus for transmitting/receiving media broadcasting signal in real time transport protocol-based broadcasting system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201361843053P 2013-07-05 2013-07-05
US61/843,053 2013-07-05

Publications (1)

Publication Number Publication Date
WO2015002500A1 true WO2015002500A1 (ko) 2015-01-08

Family

ID=52144011

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2014/006011 WO2015002500A1 (ko) 2013-07-05 2014-07-04 실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 방송 신호의 송수신 방법 및 장치

Country Status (4)

Country Link
US (1) US20160173556A1 (ko)
KR (1) KR20160030133A (ko)
CA (1) CA2917290C (ko)
WO (1) WO2015002500A1 (ko)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5725242B1 (ja) * 2014-06-04 2015-05-27 ソニー株式会社 送信装置及び送信方法、並びに受信装置並びに受信方法
BR112017019464A2 (pt) * 2015-03-12 2018-07-03 Huawei Technologies Co., Ltd. método e aparelho de transmissão de pacote de protocolo de transporte em tempo real rtp
US10667018B2 (en) * 2016-05-13 2020-05-26 Time Warner Cable Enterprises Llc Asynchronous workflows
CN107872422B (zh) * 2016-09-23 2020-01-10 杭州海康威视数字技术股份有限公司 一种数据传输方法、装置及电子设备
US9584381B1 (en) 2016-10-10 2017-02-28 Extrahop Networks, Inc. Dynamic snapshot value by turn for continuous packet capture
US10567847B2 (en) * 2016-10-11 2020-02-18 Disney Enterprises, Inc. Systems and methods for transporting and retaining video header information for video content
US10476673B2 (en) 2017-03-22 2019-11-12 Extrahop Networks, Inc. Managing session secrets for continuous packet capture systems
US20180324061A1 (en) * 2017-05-03 2018-11-08 Extrahop Networks, Inc. Detecting network flow states for network traffic analysis
US9967292B1 (en) 2017-10-25 2018-05-08 Extrahop Networks, Inc. Inline secret sharing
US10389574B1 (en) 2018-02-07 2019-08-20 Extrahop Networks, Inc. Ranking alerts based on network monitoring
US10038611B1 (en) 2018-02-08 2018-07-31 Extrahop Networks, Inc. Personalization of alerts based on network monitoring
US10270794B1 (en) 2018-02-09 2019-04-23 Extrahop Networks, Inc. Detection of denial of service attacks
US10411978B1 (en) 2018-08-09 2019-09-10 Extrahop Networks, Inc. Correlating causes and effects associated with network activity
US10594718B1 (en) 2018-08-21 2020-03-17 Extrahop Networks, Inc. Managing incident response operations based on monitored network activity
US10965702B2 (en) * 2019-05-28 2021-03-30 Extrahop Networks, Inc. Detecting injection attacks using passive network monitoring
US11165814B2 (en) 2019-07-29 2021-11-02 Extrahop Networks, Inc. Modifying triage information based on network monitoring
US10742530B1 (en) 2019-08-05 2020-08-11 Extrahop Networks, Inc. Correlating network traffic that crosses opaque endpoints
US11388072B2 (en) 2019-08-05 2022-07-12 Extrahop Networks, Inc. Correlating network traffic that crosses opaque endpoints
US10742677B1 (en) 2019-09-04 2020-08-11 Extrahop Networks, Inc. Automatic determination of user roles and asset types based on network monitoring
US11165823B2 (en) 2019-12-17 2021-11-02 Extrahop Networks, Inc. Automated preemptive polymorphic deception
US11463466B2 (en) 2020-09-23 2022-10-04 Extrahop Networks, Inc. Monitoring encrypted network traffic
EP4218212A1 (en) 2020-09-23 2023-08-02 ExtraHop Networks, Inc. Monitoring encrypted network traffic
CN112911023B (zh) * 2021-04-20 2023-06-06 中国邮政储蓄银行股份有限公司 文件的传输方法、传输装置以及文件传输系统
US11349861B1 (en) 2021-06-18 2022-05-31 Extrahop Networks, Inc. Identifying network entities based on beaconing activity
US11296967B1 (en) 2021-09-23 2022-04-05 Extrahop Networks, Inc. Combining passive network analysis and active probing
US11843606B2 (en) 2022-03-30 2023-12-12 Extrahop Networks, Inc. Detecting abnormal data access based on data similarity
CN114979092B (zh) * 2022-05-13 2024-04-02 深圳智慧林网络科技有限公司 一种基于rtp的数据传输方法、装置、设备和介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080048054A (ko) * 2005-09-01 2008-05-30 노키아 코포레이션 리치 미디어 콘텐츠의 프로그레시브 다운로딩 및스트리밍을 위해 ｉｓｏ 기반 미디어 파일 포맷으로 ｓｖｇ콘텐츠를 임베딩 하는 방법
KR20090017028A (ko) * 2007-08-13 2009-02-18 삼성전자주식회사 미디어 파일 포맷에서 메타데이터의 생성 방법, 접근 방법및 그 장치
KR20090026012A (ko) * 2007-09-07 2009-03-11 삼성전자주식회사 스테레오스코픽 파일을 생성하기 위한 장치 및 방법
KR20100029137A (ko) * 2007-07-02 2010-03-15 프라운호퍼-게젤샤프트 추르 푀르데룽 데어 안제반텐 포르슝 에 파우 미디어 데이터 컨테이너 및 메타데이터 컨테이너를 포함하는 파일을 판독 및 처리하는 장치 및 방법
KR20110100170A (ko) * 2010-03-03 2011-09-09 삼성전자주식회사 미디어 파일 기록 및 재생 장치 및 방법과 그 기록 매체

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080048054A (ko) * 2005-09-01 2008-05-30 노키아 코포레이션 리치 미디어 콘텐츠의 프로그레시브 다운로딩 및스트리밍을 위해 ｉｓｏ 기반 미디어 파일 포맷으로 ｓｖｇ콘텐츠를 임베딩 하는 방법
KR20100029137A (ko) * 2007-07-02 2010-03-15 프라운호퍼-게젤샤프트 추르 푀르데룽 데어 안제반텐 포르슝 에 파우 미디어 데이터 컨테이너 및 메타데이터 컨테이너를 포함하는 파일을 판독 및 처리하는 장치 및 방법
KR20090017028A (ko) * 2007-08-13 2009-02-18 삼성전자주식회사 미디어 파일 포맷에서 메타데이터의 생성 방법, 접근 방법및 그 장치
KR20090026012A (ko) * 2007-09-07 2009-03-11 삼성전자주식회사 스테레오스코픽 파일을 생성하기 위한 장치 및 방법
KR20110100170A (ko) * 2010-03-03 2011-09-09 삼성전자주식회사 미디어 파일 기록 및 재생 장치 및 방법과 그 기록 매체

Also Published As

Publication number Publication date
KR20160030133A (ko) 2016-03-16
CA2917290C (en) 2018-10-30
US20160173556A1 (en) 2016-06-16
CA2917290A1 (en) 2015-01-08

Similar Documents

Publication Publication Date Title
WO2015002500A1 (ko) 실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 방송 신호의 송수신 방법 및 장치
WO2012011724A2 (ko) 미디어 파일 송수신 방법 및 그를 이용한 송수신 장치
WO2014209057A1 (ko) 지상파 방송망과 인터넷 프로토콜망 연동 기반의 하이브리드 방송 시스템에서 방송 서비스의 송수신 방법 및 장치
WO2012060581A2 (ko) 미디어 콘텐트 송수신 방법 및 그를 이용한 송수신 장치
WO2015008986A1 (ko) 하이브리드 방송 시스템의 방송 신호를 송신/수신하는 방법 및 장치
WO2011071290A2 (en) Streaming method and apparatus operating by inserting other content into main content
WO2011105811A2 (en) Method and apparatus for transmitting and receiving data
WO2012177041A2 (ko) 미디어 컨텐트 송수신 방법 및 그를 이용한 송수신 장치
WO2013048148A2 (en) Method and apparatus for transmitting and receiving content
WO2011059291A2 (en) Method and apparatus for transmitting and receiving data
WO2011155776A2 (ko) 프래그먼트 기반의 멀티미디어 스트리밍 서비스 제공 방법과 그 장치, 그리고 프래그먼트 기반의 멀티미디어 스트리밍 서비스 수신 방법과 그 장치
WO2016018042A1 (en) Apparatus and method for transmitting/receiving processes of a broadcast signal
WO2011132883A2 (ko) 인터넷 기반 컨텐츠 송수신 방법 및 그를 이용한 송수신 장치
WO2012077982A2 (ko) 멀티미디어 컨텐츠를 송수신하는 송신 장치 및 수신 장치와, 그 재생 방법
WO2011062385A2 (ko) 방송 신호 송수신 방법 및 그를 이용한 방송 수신 장치
WO2011132879A2 (ko) 인터넷 기반 컨텐츠 송수신 방법 및 그를 이용한 송수신 장치
WO2016111563A1 (ko) 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치
WO2015126117A1 (ko) 방송 신호 송수신 방법 및 장치
WO2012011722A2 (ko) 미디어 송수신 방법 및 그를 이용한 송수신 장치
WO2016111560A1 (en) Transmitting apparatus and receiving apparatus and signal processing method thereof
WO2011074844A2 (en) Method of processing non-real time service and broadcast receiver
WO2011132882A2 (ko) 인터넷 기반 컨텐츠 송수신 방법 및 그를 이용한 송수신 장치
WO2017135673A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2020096148A1 (ko) 미디어 서비스 채널 전환 방법 및 장치
WO2016178494A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14819491

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20157037197

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2917290

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 14902781

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14819491

Country of ref document: EP

Kind code of ref document: A1