WO2018054193A1 - 一种数据传输方法、装置及电子设备 - Google Patents

一种数据传输方法、装置及电子设备 Download PDF

Info

Publication number
WO2018054193A1
WO2018054193A1 PCT/CN2017/098632 CN2017098632W WO2018054193A1 WO 2018054193 A1 WO2018054193 A1 WO 2018054193A1 CN 2017098632 W CN2017098632 W CN 2017098632W WO 2018054193 A1 WO2018054193 A1 WO 2018054193A1
Authority
WO
WIPO (PCT)
Prior art keywords
bit
frame
data packet
padding
data
Prior art date
Application number
PCT/CN2017/098632
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 US16/335,770 priority Critical patent/US10869106B2/en
Priority to EP17852262.9A priority patent/EP3518486B1/en
Publication of WO2018054193A1 publication Critical patent/WO2018054193A1/zh

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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H04W28/065—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets

Definitions

  • the present application relates to data transmission and storage technologies, and in particular, to a data transmission method, apparatus, and electronic device.
  • one channel of audio and video data needs to occupy a network transmission channel independently, and the number of audio and video data to be transmitted is large, and the network resource overhead is large, and at the receiving end, it is required to perform time stamp information according to each channel of audio and video data. Frame stitching, the delay is large.
  • the embodiments of the present application provide a data transmission method, device, and electronic device, which can reduce network resource overhead and framing delay.
  • an embodiment of the present application provides a data transmission method, including:
  • the data type bit, the frame start bit, the frame end bit, and the payload packet type bit flag are performed on the load data packet to obtain a packaged real-time transport protocol data packet;
  • the padding field corresponding to the padding bit includes: a data padding field and an extension field, where the extension field occupies 4 bytes, including: reserved field, synthesized data
  • the frame indicates the bit field and the padding size field.
  • the data type bit in the composite data frame indication bit field occupies 2 bits, and the frame start bit and the frame end bit each occupy 1 bit.
  • the payload packet type bit occupies 2 bits.
  • the composite data frame indication bit field further includes: a load packet sequence number bit and a channel bit each occupying 4 bits.
  • the obtained real-time transport protocol data packet includes:
  • the frame start bit in the padding field corresponding to the padding bit is marked as valid, and the frame end bit flag is invalid.
  • the load data packet is the first load data packet of the data frame and is the last load data packet, mark the frame start bit in the padding field corresponding to the padding bit as valid, and the frame end bit flag is valid. ;
  • the frame start bit in the padding field corresponding to the padding bit is marked as invalid, and the frame end bit flag is marked as valid.
  • the load data packet is a non-first load data packet of the data frame and is not the last one Loading the data packet, marking the start bit of the frame in the padding field corresponding to the padding bit as invalid, and marking the frame end bit as invalid;
  • the method before the loading the data packet of the package, the method further includes:
  • the load data packet is a video I frame
  • the data type bit in the padding field corresponding to the padding bit is marked as 00
  • the payload data packet type bit is marked as 00, according to the load data packet in the data frame.
  • the serial number of the segmentation marks the serial number of the load data packet;
  • the load data packet is a video P frame
  • the data type bit in the padding field corresponding to the padding bit is marked as 00
  • the payload data packet type bit is marked as 01, according to the load data packet in the data frame.
  • the serial number of the segmentation marks the serial number of the load data packet;
  • the load data packet is a video B frame
  • the data type bit in the padding field corresponding to the padding bit is marked as 00
  • the payload data packet type bit is marked as 10, according to the load data packet in the data frame.
  • the serial number of the segmentation marks the serial number of the load data packet;
  • the load data packet is audio
  • the data type bit in the padding field corresponding to the padding bit is marked as 01
  • the payload data packet type bit is marked as 01
  • the data packet is segmented according to the load data packet.
  • the serial number of the load packet is numbered;
  • the load data packet is private data
  • the data type bit in the padding field corresponding to the padding bit is marked as 10
  • the payload data packet type bit is marked as 11
  • the load data packet is cut in the data frame according to the load data packet.
  • the serial number of the sub-label is the load packet sequence number.
  • the method further includes:
  • the bit markers in the padding field corresponding to the padding bits are read, and the payload data packets in the encapsulated real-time transport protocol data packets are parsed according to the read bit markers.
  • the parsing the load data packet in the real-time transport protocol data packet according to the read each bit flag includes:
  • the data type bit mark in the padding field corresponding to the padding bit If it is 01 or 10, read the frame start bit and the frame end bit in the padding field corresponding to the padding bit. If the frame start bit flag is valid, the frame end bit is Marked as valid, it is determined that the transmitted data frame contains only the load data packet behind the currently parsed real-time transport protocol header; if the frame start bit flag is valid, the frame end bit flag is invalid, and the current parsed real-time transport protocol header is determined.
  • the load data packet is the first load data packet in the transmitted data frame; if the frame start bit flag is invalid, the frame end bit flag is marked as valid, and the load data packet behind the currently parsed real-time transport protocol header is determined to be the transmitted data frame.
  • the last load packet in the frame if the frame start bit is marked as invalid, the frame end bit is marked as invalid, and the load packet sequence number in the padding field corresponding to the padding bit is read to determine the load behind the currently parsed real-time transport protocol header.
  • the location of the data packet in the transmitted data frame if the frame start bit is marked as invalid, the frame end bit is marked as invalid, and the load packet sequence number in the padding field corresponding to the padding bit is read to determine the load behind the currently parsed real-time transport protocol header.
  • the load packet type bit in the padding field corresponding to the padding bit is read, and the load packet behind the currently parsed real-time transport protocol header is determined to be a video.
  • I frame, video P frame or video B frame and read the frame start bit, the frame end bit, or the frame start bit, the frame end bit, and the load packet sequence number in the padding field corresponding to the padding bit, and determine the currently parsed The location of the payload packet behind the real-time transport protocol header in the transmitted data frame.
  • the method further includes:
  • the original stream packet data packet is stored.
  • the padding field corresponding to the padding field has a maximum number of bytes of no more than 7 bytes and a minimum of 4 bytes, including A padding byte and an extension field, wherein the extension field is located between the original stream packet fixed header and the padding byte.
  • the embodiment of the present application provides a data transmission apparatus, including: a segmentation module, a real-time transmission protocol header tag module, a padding field tag module, and a transmission module, where
  • a sharding module configured to divide the data frame to be transmitted into one or more load data packets of a predetermined length
  • a real-time transport protocol header tagging module configured to add a real-time transport protocol header for each load data packet, and mark a padding bit in the real-time transport protocol header as filled;
  • a padding field tagging module configured to perform, in a padding field corresponding to the padding bit, a data type bit, a frame start bit, a frame end bit, and a payload packet type bit tag for the payload data packet, to obtain a encapsulated real-time transport protocol data packet.
  • a transmission module configured to transmit the encapsulated real-time transport protocol data packet.
  • the padding field corresponding to the padding bit includes: a data padding field and an extension field, where the extension field occupies 4 bytes, including: a reserved field, a synthesized data
  • the frame indicates the bit field and the padding size field.
  • the data type bit in the composite data frame indication bit field occupies 2 bits, and the frame start bit and the frame end bit each occupy 1 bit.
  • the payload packet type bit occupies 2 bits.
  • the composite data frame indication bit field further includes: a load packet sequence number bit and a channel bit each occupying 4 bits.
  • the padding field marking module comprises: a padding field tag unit and a package Unit, where
  • the load data packet is the first load data packet of the data frame and is the last load data packet, mark the frame start bit in the padding field corresponding to the padding bit as valid, and the frame end bit flag is valid. ;
  • the frame start bit in the padding field corresponding to the padding bit is marked as invalid, and the frame end bit flag is marked as valid.
  • the load data packet is a non-first load data packet of the data frame and not a last load data packet, marking a frame start bit in the padding field corresponding to the padding bit as invalid, and the frame end bit flag is marked as invalid;
  • a packaging unit configured to encapsulate the labeled load data packet, to obtain a packaged real-time transport protocol data packet.
  • the padding field marking module further includes:
  • a load packet type bit flag unit if the load data packet is a video I frame, marking a data type bit in the padding field corresponding to the padding bit as 00, and a load packet type bit flag as 00, according to the load
  • the serial number of the data packet in the data frame is marked with a load data packet sequence number;
  • the load data packet is a video P frame
  • the data type bit in the padding field corresponding to the padding bit is marked as 00
  • the payload data packet type bit is marked as 01, according to the load data packet in the data frame.
  • the serial number of the segmentation marks the serial number of the load data packet;
  • the load data packet is a video B frame
  • the data type bit in the padding field corresponding to the padding bit is marked as 00
  • the payload data packet type bit is marked as 10, according to the load data packet in the data frame.
  • the serial number of the segmentation marks the serial number of the load data packet;
  • the load data packet is audio
  • the data type bit in the padding field corresponding to the padding bit is marked as 01
  • the payload data packet type bit is marked as 01
  • the data packet is segmented according to the load data packet.
  • the serial number of the load packet is numbered;
  • the data type bit in the padding field corresponding to the padding bit is marked as 10
  • the payload data packet type bit is marked as 11, according to the load data packet in the
  • the sequence number of the segmentation in the data frame indicates the load data packet sequence number
  • the marked load data packet is output to the package unit.
  • the device further includes: a receiving module, a parsing module, and load data Package acquisition module, wherein
  • a receiving module configured to receive the encapsulated real-time transport protocol data packet
  • a parsing module configured to parse a real-time transport protocol header of the received encapsulated real-time transport protocol data packet
  • a load data packet obtaining module if the padding bit in the real-time transport protocol header is marked as filled, reading each bit mark in the padding field corresponding to the padding bit, and parsing the encapsulated real-time transport protocol data packet according to the read each bit tag Load packets in .
  • the analyzing, by the read each of the tags, the load data packet in the encapsulated real-time transport protocol data packet includes:
  • the data type bit mark in the padding field corresponding to the padding bit If it is 01 or 10, read the frame start bit and the frame end bit in the padding field corresponding to the padding bit. If the frame start bit flag is valid, the frame end bit is Marked as valid, it is determined that the transmitted data frame contains only the load data packet behind the currently parsed real-time transport protocol header; if the frame start bit flag is valid, the frame end bit flag is invalid, and the current parsed real-time transport protocol header is determined.
  • the load data packet is the first load data packet in the transmitted data frame; if the frame start bit flag is invalid, the frame end bit flag is marked as valid, and the load data packet behind the currently parsed real-time transport protocol header is determined to be the transmitted data frame.
  • the last load packet in the frame if the frame start bit is marked as invalid, the frame end bit is marked as invalid, and the load packet sequence number in the padding field corresponding to the padding bit is read to determine the load behind the currently parsed real-time transport protocol header.
  • the location of the data packet in the transmitted data frame if the frame start bit is marked as invalid, the frame end bit is marked as invalid, and the load packet sequence number in the padding field corresponding to the padding bit is read to determine the load behind the currently parsed real-time transport protocol header.
  • the load packet type bit in the padding field corresponding to the padding bit is read, and the load packet behind the currently parsed real-time transport protocol header is determined to be a video.
  • I frame, video P frame or video B frame and read the frame start bit, frame end bit, or frame start bit, frame end bit, and load number in the padding field corresponding to the padding bit
  • the location of the load data packet behind the currently parsed real-time transport protocol header in the transmitted data frame is determined.
  • the device further includes: an original stream packet encapsulation module and a storage module, where
  • the original stream packet encapsulating module is configured to add a original stream packet fixed header to the currently parsed load data packet, and mark the padding bit in the original stream packet fixed header as padding; in the padding field corresponding to the padding bit,
  • the load data packet performs a data type bit, a frame start bit, a frame end bit, and a payload packet type bit flag to obtain an original stream packet data packet;
  • a storage module configured to store the original stream packet data packet.
  • the padding field corresponding to the padding field has a maximum number of bytes of no more than 7 bytes and a minimum of 4 bytes, including padding.
  • an embodiment of the present application provides an electronic device, including: a housing, a processor, a memory, a circuit board, and a power supply circuit, wherein the circuit board is disposed inside the space enclosed by the housing, and the processor And a memory disposed on the circuit board; a power supply circuit for powering each circuit or device of the electronic device; a memory for storing executable program code; and the processor operating by reading executable program code stored in the memory A program corresponding to the program code for executing the data transmission method of any of the foregoing.
  • an embodiment of the present application provides a storage medium for storing executable program code, the executable program code being executed to perform the data transmission method of any of the foregoing.
  • a data transmission method, device, and electronic device provided by the embodiment of the present application, by dividing a data frame to be transmitted into one or more load data packets of a predetermined length; adding a real-time transmission protocol header for each load data packet, Marking the padding bits in the real-time transport protocol header as padding; in the padding field corresponding to the padding bits, performing data type bits, frame start bits, frame end bits, and payload packet type bit flags on the payload data packet Obtaining a packaged real-time transport protocol data packet; transmitting the encapsulated real-time transport protocol data packet can reduce network resource overhead and framing delay.
  • FIG. 1 is a schematic flowchart of a data transmission method according to Embodiment 1 of the present application.
  • FIG. 2 is a schematic structural diagram of a frame RTP data packet
  • FIG. 3 is a schematic structural diagram of an RTP header of the embodiment
  • FIG. 4 is a schematic structural diagram of an RTP data packet encapsulated in a prior art
  • FIG. 5 is a schematic structural diagram of an RTP data packet encapsulated in the embodiment.
  • FIG. 6 is a schematic diagram of a syntax format of a synthesized data frame indication bit field in this embodiment
  • FIG. 7 is a schematic structural diagram of a PES packet of a prior art package
  • FIG. 8 is a schematic structural diagram of a PES packet encapsulated in the embodiment.
  • FIG. 9 is a schematic structural diagram of a data transmission apparatus according to Embodiment 2 of the present application.
  • FIG. 10 is a schematic structural diagram of an embodiment of an electronic device according to the present application.
  • FIG. 1 is a schematic flowchart of a data transmission method according to Embodiment 1 of the present application. As shown in FIG. 1 , the method in this embodiment may include:
  • Step 101 Divide a data frame to be transmitted into one or more load data packets of a predetermined length
  • the predetermined length is 4 bytes.
  • the length of the last payload packet is less than or equal to 4 bytes.
  • Step 102 Add a real-time transport protocol header for each load data packet, and mark the padding bit in the real-time transport protocol header as filled;
  • the Real Time Transport Protocol is a standard data packet protocol for transmitting data on the Internet.
  • the real-time transport protocol is used to encapsulate the load data packet to make it a (packaged) real-time transport protocol data packet, which can enhance the real-time performance of the data transmission.
  • multiple real-time transport protocol data packets form a frame RTP data packet.
  • FIG. 2 is a schematic structural diagram of a frame RTP data packet.
  • one frame of RTP data packets includes one or more RTP data packets (RTP Packets), and each RTP data packet includes: an RTP header standard field (RTP). Header), RTP header private extension field, RTP standard payload field, and RTP padding field.
  • RTP padding field includes: a padding data field, a custom field, and an extended length field.
  • FIG. 3 is a schematic structural diagram of an RTP header according to the embodiment.
  • the definition of each grammar of the RTP header is as follows:
  • Padding which occupies 1 bit, identifies whether there is a padding part. When set to 1, it indicates that there is a padding part at the end of the RTP packet, and the last byte of the padding part indicates the length of the padding part (including the byte) Length itself);
  • Extension(X), which is 1 bit, is an extension bit, and indicates whether there is an extension field. When set to 1, it indicates that the RTP header of the RTP packet contains an extension field;
  • CSRC count which is 4 bits, and identifies the number of participating sources (CSRC, Contributing Source) fields;
  • the marker bit (M), which is 1 bit, when set to 1, indicates that the current RTP packet is the last packet transmitted.
  • the payload type (PT), which is 7 bits, is used to identify the type of data content transmitted;
  • Timestamp which is 32 bits, is used to identify the acquisition (sampling) time of the content contained in the RTP packet;
  • SSRC synchronization source
  • identifier identifier
  • CSRC identifier identifier
  • specific syntax is described in the related protocol, which is omitted here.
  • Step 103 In the padding field corresponding to the padding bit, perform data type, frame start bit, frame end bit, and payload packet type tag on the payload data packet to obtain a packaged real-time transport protocol data packet.
  • the encapsulation when RTP encapsulation of the payload data packet is performed, the encapsulation is performed in a 4-byte alignment manner.
  • the length of each RTP actual load is not strictly aligned in 4 bytes. Therefore, padding processing needs to be performed in the RTP standard payload field.
  • the number of bytes to be padded is 1, 2 or 3, and the end of the padding length.
  • the byte indicates the length of the padding.
  • FIG. 4 is a schematic structural diagram of an RTP data packet encapsulated by a related art, as shown in FIG. 4.
  • 0, 1, 2, and 3 in the figure are padding bytes, that is, padding fields corresponding to padding bits.
  • the payload packet length is 4 bytes
  • the padding byte is 0, and the dashed box in the figure is empty, indicating that there is no padding
  • the payload packet length is 3 bytes
  • the padding byte is 1, and the dotted frame is The byte is 0xff 0x01
  • the payload packet length is 2 bytes
  • the padding byte is 2
  • the byte of the dotted box is 0xff 0x02 and so on.
  • FIG. 5 is a schematic structural diagram of the RTP data packet encapsulated in the embodiment.
  • the padding field at least 4 bytes are padded.
  • the padding field is expanded by 4 bytes, wherein
  • the padding field corresponding to the padding bit includes: a data padding field and an extension field, where the extension field occupies 4 bytes, and the sequence includes: a reserved field (res), a composite data frame indication Bit field (MFI, Multiple Frame Indicator) and padding size field. among them,
  • the reserved field occupies 2 bytes, and the default is 0.
  • the fill size field refers to the actual data size other than the load data, and contains itself.
  • One byte used, for example, the padding size includes: 0, 1, 2 and res, MFI, padding size fields in Figure 5.
  • FIG. 6 is a schematic diagram of a syntax format of a synthesized data frame indication bit field in this embodiment.
  • the synthesized data frame indicates that the bit field occupies 2 bytes, wherein a "-" indicates 1 bit, and the syntax is as follows:
  • V occupying 2 bits, and identifying the MFI type version number
  • T the data type bit, occupying 2 bits, identifying the data type, wherein 00 identifies the video, 01 identifies the audio, 10 identifies the private frame, and 11 serves as a reserved bit;
  • the start bit of the frame occupying 1 bit, and identifying the start of the synthesized data frame (data frame), wherein if set (valid), the identified composite data frame (data frame) is the starting RTP starting from the I mi frame or the P mi frame. a data packet; if set to 0 (invalid), the composite data frame is identified as an RTP data packet after the initial RTP data packet;
  • the end of the frame occupying 1 bit, and identifying the end of the synthesized data frame. If set, the identified composite data frame is an RTP data packet ending with an I mi frame or a P mi frame. If set to 0, the other synthesized data frame transmission is identified. End;
  • T is 00 (video)
  • the data frame to be transmitted is a video
  • T is 01 (audio), use 01 for identification, and others for reservation;
  • T 10 (private frame), it is identified by 11 and the others are used as reservations;
  • the load data packet sequence number occupying 4 bits, and identifying the channel number of the channel to which the load data packet (encapsulated real-time transport protocol data packet) belongs, the sequence number ranges from 0 to 15;
  • the channel number of the channel to which the above-mentioned transmitted load data packet belongs may be equivalent to the sequence number of the load data packet that is subsequently divided in the data frame.
  • the channel bit occupies 4 bits, and identifies the number of channels of the data frame to be transmitted.
  • the channel bit can identify the number of channels of the data frame to be transmitted, that is, the data frame to which the data frame to be transmitted is specifically a plurality of data to be transmitted.
  • the sequence number N of the payload data packet in the data frame and the number of channels T1 of the data frame to be transmitted are used to identify which channel data is received during the actual transmission process. And the position of the data in the data frame, so that by analyzing the sequence number and the channel number at the receiving end, it is possible to distinguish which channel data and the specific location of the received data.
  • T1 is set to 3 channels of video data
  • T1 is set to 6
  • N the real-time transport protocol packet sequence number
  • T1 the real-time transport protocol packet sequence number
  • S the data frame start flag
  • the S mark can be read to know that The data frame starts to be transmitted, so that the (packaged) RTP data packet can be continuously acquired.
  • the serial number of an RTP data packet is also 0, and the E flag is 1, the first video data can be considered at this time. After the transfer is completed, the transmitted first video data can be extracted.
  • N the real-time transport protocol packet sequence number
  • T1, S, and E may be used to determine whether the current I- mi frame ends, and then the actual included in the synthesized data frame is recorded.
  • N refers to which channel data
  • the corresponding sequence number N can be set to 0
  • S is the data frame start tag, and the S tag can be read to know that The data frame starts to be transmitted, so that the (packaged) RTP data packet can be continuously acquired.
  • the sequence number N of an RTP data packet is also 0, and the E flag is 1, the first channel video can be considered. After the data transmission is completed, the transmitted first video data can be extracted.
  • the synthesized data frame there is no mixed type of data in the synthesized data frame (data frame).
  • data frame there are I frames and P frames at the same time, or there are video frames and audio frames at the same time, or there is a video at the same time.
  • a frame and a private frame are crossed by two.
  • an RTP header is added for each data unit, and a data unit information definition is performed in a padding padding field in the RTP header, that is, in RTP padding.
  • the start end flag of the data is introduced, so that the delay problem in data parsing can be effectively reduced.
  • the multi-channel audio and video data is synthesized in a network transmission Transmission in the channel effectively reduces network resource overhead.
  • the encapsulated real-time transport protocol data packet includes:
  • the frame start bit in the padding field corresponding to the padding bit is marked as valid, and the frame end bit flag is invalid.
  • the load data packet is the first load data packet of the data frame and is the last load data packet, mark the frame start bit in the padding field corresponding to the padding bit as valid, and the frame end bit flag is valid. ;
  • the frame start bit in the padding field corresponding to the padding bit is marked as invalid, and the frame end bit flag is marked as valid.
  • the load data packet is a non-first load data packet of the data frame and not a last load data packet, marking a frame start bit in the padding field corresponding to the padding bit as invalid, and the frame end bit flag is marked as invalid;
  • the method before the loading the data packet of the package, the method further includes:
  • the load data packet is a video I frame
  • the data type bit in the padding field corresponding to the padding bit is marked as 00
  • the payload data packet type bit is marked as 00, according to the load data packet in the data frame.
  • the serial number of the segmentation marks the serial number of the load data packet;
  • the load data packet is a video P frame
  • the data type bit in the padding field corresponding to the padding bit is marked as 00
  • the payload data packet type bit is marked as 01, according to the load data packet in the data frame.
  • the serial number of the segmentation marks the serial number of the load data packet;
  • the load data packet is a video B frame
  • the data type bit in the padding field corresponding to the padding bit is marked as 00
  • the payload data packet type bit is marked as 10, according to the load data packet in the data frame.
  • the serial number of the segmentation marks the serial number of the load data packet;
  • the load data packet is audio
  • the data class in the padding field corresponding to the padding bit The type bit is marked as 01
  • the load packet type bit is marked as 01
  • the load data packet sequence number is marked according to the serial number of the load data packet divided in the data frame
  • the load data packet is private data
  • the data type bit in the padding field corresponding to the padding bit is marked as 10
  • the payload data packet type bit is marked as 11
  • the load data packet is cut in the data frame according to the load data packet.
  • the serial number of the sub-label is the load packet sequence number.
  • Step 104 Transmit the encapsulated real-time transport protocol data packet.
  • the method further includes:
  • the bit markers in the padding field corresponding to the padding bits are read, and the payload data packets in the encapsulated real-time transport protocol data packets are parsed according to the read bit markers.
  • parsing out the load data packet in the encapsulated real-time transport protocol data packet according to the read each bit flag includes:
  • the data type bit mark in the padding field corresponding to the padding bit If it is 01 or 10, read the frame start bit and the frame end bit in the padding field corresponding to the padding bit. If the frame start bit flag is valid, the frame end bit is Marked as valid, it is determined that the transmitted data frame contains only the load data packet behind the currently parsed real-time transport protocol header; if the frame start bit flag is valid, the frame end bit flag is invalid, and the current parsed real-time transport protocol header is determined.
  • the load data packet is the first load data packet in the transmitted data frame; if the frame start bit flag is invalid, the frame end bit flag is marked as valid, and the load data packet behind the currently parsed real-time transport protocol header is determined to be the transmitted data frame.
  • the last load packet in the frame if the frame start bit is marked as invalid, the frame end bit is marked as invalid, and the load packet sequence number in the padding field corresponding to the padding bit is read to determine the load behind the currently parsed real-time transport protocol header.
  • the location of the data packet in the transmitted data frame if the frame start bit is marked as invalid, the frame end bit is marked as invalid, and the load packet sequence number in the padding field corresponding to the padding bit is read to determine the load behind the currently parsed real-time transport protocol header.
  • the load packet type bit in the padding field corresponding to the padding bit is read, and the load packet behind the currently parsed real-time transport protocol header is determined to be a video.
  • I frame, video P frame or video B frame, and read the padding corresponding to The frame start bit, the frame end bit, or the frame start bit, the frame end bit, and the load packet sequence number bit in the padding field determine the position of the payload data packet following the currently parsed real-time transport protocol header in the transmitted data frame.
  • the frame start bit, the frame end bit, or the frame start bit, the frame end bit, and the load packet sequence number bit in the padding field corresponding to the padding bit are read, and the load behind the currently parsed real-time transport protocol header is determined.
  • the location of the packet in the transmitted data frame includes:
  • the frame start bit is marked as valid, the frame end bit is marked as valid, and it is determined that the transmitted data frame contains only the load data packet following the currently parsed real-time transport protocol header; if the frame start bit flag is valid, the frame end bit flag is invalid. Determining that the load data packet behind the currently parsed real-time transport protocol header is the first load data packet in the transmitted data frame; if the frame start bit flag is invalid, the frame end bit flag is valid, and determining the currently parsed real-time transport protocol The load data packet behind the header is the last load data packet in the transmitted data frame; if the frame start bit flag is invalid, the frame end bit flag is invalid, and the load data packet sequence number in the padding field corresponding to the padding bit is read. Determines the location of the payload packet behind the currently parsed real-time transport protocol header in the transmitted data frame.
  • the data frame may be obtained according to the position of each load data packet in the transmitted data frame.
  • the method may further include:
  • the original stream packet data packet is stored.
  • the MPEG2PS/TS is a package container for multiplexing digital audio, video, and the like, and the basic unit of the package format is a PES (Packetized Elementary Stream) data packet.
  • data storage is designed based on standard documents of RTP and MPEG2PS. Format, in order to improve the processing efficiency of data, MPEG2PS is processed by default using 4-byte alignment.
  • the parsed load data packet is encapsulated in a 4-byte alignment manner, that is, the PES fixed header plus the padding byte plus the load is configured as a whole four-byte alignment, and there is no limitation on whether the actual load data is 4-byte aligned.
  • FIG. 7 is a schematic structural diagram of a PES packet of a prior art package
  • FIG. 8 is a schematic structural diagram of a PES packet encapsulated in the embodiment.
  • the padding bytes may be 0, 1, 2 in the padding field corresponding to the padding bits. 3 bytes, that is, the fill length (Stuff-len) is no more than 3 bytes, the minimum is not filled with bytes, and the padding bytes are filled at the end of the data header (PES fixed header).
  • the padding field corresponding to the padding bit includes a padding byte and an extension field, where
  • the length of the padding byte may be 0, 1, 2, 3 bytes, the maximum is no more than 3 bytes, and the minimum is not padded bytes;
  • the extension field is 4 bytes.
  • the number of bytes of the padding field corresponding to the padding bit is 4, 5, 6, or 7 bytes, the maximum is no more than 7 bytes, and the minimum is 4 bytes.
  • the extension field is located between the PES fixed header and the padding byte, and includes: a first reserved field, a synthesized data frame indicator bit field, and a second reserved field, where
  • the first reserved field (res1) and the second reserved field (res2) occupy 1 byte respectively;
  • the composite data frame indication bit field occupies two bytes, which is the same as the MFI in the RTP data packet.
  • the syntax is as follows:
  • V occupying 2 bits, and identifying the MFI type version number
  • the data type bit occupy 2bit, identify the data type, where 00 identifies the video, 01 mark Audio, 10 identifies a private frame, 11 is used as a reserved bit;
  • the start bit of the frame occupying 1 bit, and identifying the start of the synthesized data frame (data frame), wherein if set (valid), the identified composite data frame (data frame) is the starting RTP starting from the I mi frame or the P mi frame. a data packet; if set to 0 (invalid), the composite data frame is identified as an RTP data packet after the initial RTP data packet;
  • the end of the frame occupying 1 bit, and identifying the end of the synthesized data frame. If set, the identified composite data frame is an RTP data packet ending with an I mi frame or a P mi frame. If set to 0, the other synthesized data frame transmission is identified. End;
  • T is 00 (video)
  • the data frame to be transmitted is a video
  • T is 01 (audio), use 01 for identification, and others for reservation;
  • T 10 (private frame), it is identified by 11 and the others are used as reservations;
  • the load data packet sequence number occupying 4 bits, and identifying the channel number of the channel to which the load data packet (encapsulated real-time transport protocol data packet) belongs, the sequence number ranges from 0 to 15;
  • Tl occupying 4 bits, identifies the number of channels of the data frame to be transmitted.
  • the payload packet type bit is a subtype bit of the data type bit.
  • the data storage is performed by selecting the MPEG2PS/TS format commonly used in the security industry, and the interworking mechanism between RTP and MPEG2PS/TS is provided, and the storage format of the multi-channel audio and video data based on MPEG2PS/TS is defined.
  • the storage format of the multi-channel audio and video data, the multi-channel audio and video data is encapsulated in MPEG2PS/TS, and different data type bit identifiers (stream identificators) need to be selected for distinguishing, that is, according to ISO 138181 for PS/TS.
  • the data type bit identifier (ID) of the video data can select the field between 0xe0-0xef; the data type bit identifier of the audio data can select 0xc0-0xcf.
  • ID the data type bit identifier
  • the information of each data stream (load data packet) is defined by an extension field, and a data type bit identifier is selected by using audio and video data and private data.
  • Encapsulation and storage of data (stream) makes processing simple and can effectively improve storage efficiency.
  • data storage is performed by selecting the MPEG2PS/TS format commonly used in the security industry, providing an interworking mechanism between RTP and MPEG2PS/TS, and defining a storage format of multi-channel audio and video data based on MPEG2PS/TS.
  • MPEG-2 is one of the video and audio lossy compression standards developed by the MPEG (Moving Picture Experts Group) organization.
  • the name of MPEG-2 can be "compression standard for moving pictures and voice based on digital storage media".
  • the service and the client interaction may be performed based on a standard RTSP (Real Time Streaming Protocol) protocol, and data transmission is performed using the RTP data packet.
  • RTSP Real Time Streaming Protocol
  • the attributes of the SDP (Session Description Protocol) of the RTSP protocol are extended.
  • the extension defines a new attribute definition based on the RTSP protocol, and is used to notify the client of the actual code stream by using the extension field. The number of audio and video channels and the encoding parameters of audio and video.
  • program code segment defined by the SDP newly added attribute may be as follows:
  • Video_config video parameter configuration information, for example, the width and height of the video
  • Audio_config audio parameter configuration information
  • the program code segment defined by the corresponding SDP new attribute can be as follows:
  • the RTP data packet received by the client is converted into PS data for storage.
  • the stored PS data can be converted into RTP packets for network transmission.
  • the conversion process of converting the RTP data packet into the PS data may be: the client extracts the load data packet from the RTP data packet, and encapsulates the extracted load data packet to obtain the PS data. . Subsequently, the client can store the PS data obtained above.
  • the data transmission method in the embodiment of the present application defines the data transmission mode based on the standard RTSP protocol, and in the case of complying with the standard protocol, the new attributes of the audio and video and the private data in the SDP information of the multi-path data are designed.
  • the definition is such that the data transmitting party and the receiving party can know the quantity and configuration information of the media data stream, which increases the flexibility of multi-path data processing; further, sets the frame start bit, the frame end bit, the data type bit and the load through the extended field.
  • the packet type bit can quickly realize framing and effectively reduce the delay; in addition, based on the MPEG2PS/TS definition data storage format, it provides a way for multiple streams to store using a small number of data type bits, for the number of multiple streams Without restrictions, it will facilitate a large number of multi-stream data synthesis in the future.
  • the apparatus of this embodiment may include: a segmentation module 91, a real-time transmission protocol header tagging module 92, a padding field tagging module 93, and a transmission module. 94, of which,
  • a segmentation module 91 configured to slice the data frame to be transmitted into one or more load data packets of a predetermined length
  • the predetermined length is 4 bytes.
  • Real-time transport protocol header tagging module 92 for adding a real-time transport protocol for each payload packet Header, marking the padding bits in the real-time transport protocol header as filled;
  • syntax formats of the RTP header are as follows:
  • Padding which occupies 1 bit, identifies whether there is a padding part. When set to 1, it indicates that there is a padding part at the end of the RTP packet, and the last byte of the padding part indicates the length of the padding part (including the byte) Length itself);
  • Extension(X), which is 1 bit, is an extension bit, and indicates whether there is an extension field. When set to 1, it indicates that the RTP header of the RTP packet contains an extension field;
  • CSRC count which is 4 bits, and identifies the number of participating sources (CSRC, Contributing Source) fields;
  • the marker bit (M), which is 1 bit, when set to 1, indicates that the current RTP packet is the last packet transmitted.
  • the payload type (PT), which is 7 bits, is used to identify the type of data content transmitted;
  • Sequence number which is 16 bits, is used to identify the order in which RTP packets are sent, that is, the order in which the receiver receives the packets and sends them to the decoder. Each RTP packet is incremented by one;
  • Timestamp which is 32 bits, is used to identify the acquisition (sampling) time of the content contained in the RTP packet;
  • SSRC synchronization source
  • identifier identifier
  • CSRC identifier identifier
  • specific syntax is described in the related protocol, which is omitted here.
  • the padding field tagging module 93 is configured to perform, in the padding field corresponding to the padding bit, a data type bit, a frame start bit, a frame end bit, and a payload packet type bit flag on the payload data packet to obtain encapsulated real-time transport protocol data. package;
  • the padding field corresponding to the padding bit includes: a data padding field and an extension field, where the extension field occupies 4 bytes, including: a reserved field, a synthesized data frame indicator bit field, and a padding size. Field. among them,
  • the data type bit in the composite data frame indication bit field occupies 2 bits, the frame start bit and the frame end bit. Each bit occupies 1 bit, and the payload packet type bit occupies 2 bits.
  • the synthesized data frame indication bit field further includes: a load data packet sequence number occupying 4 bits and a channel bit.
  • the synthesized data frame indicates that the bit field occupies 2 bytes, and the syntax format is as follows:
  • V occupying 2 bits, and identifying the MFI type version number
  • T the data type bit, occupying 2 bits, identifying the data type, wherein 00 identifies the video, 01 identifies the audio, 10 identifies the private frame, and 11 serves as a reserved bit;
  • the start bit of the frame occupying 1 bit, and identifying the start of the synthesized data frame (data frame), wherein if set (valid), the identified composite data frame (data frame) is the starting RTP starting from the I mi frame or the P mi frame. a data packet; if set to 0 (invalid), the composite data frame is identified as an RTP data packet after the initial RTP data packet;
  • the end of the frame occupying 1 bit, and identifying the end of the synthesized data frame. If set, the identified composite data frame is an RTP data packet ending with an I mi frame or a P mi frame. If set to 0, the other synthesized data frame transmission is identified. End;
  • T is 00 (video)
  • the data frame to be transmitted is a video
  • T is 01 (audio), use 01 for identification, and others for reservation;
  • T 10 (private frame), it is identified by 11 and the others are used as reservations;
  • the load data packet sequence number occupying 4 bits, and identifying the channel number of the channel to which the load data packet (encapsulated real-time transport protocol data packet) belongs, the sequence number ranges from 0 to 15;
  • the channel bit occupies 4 bits, and identifies the number of channels of the data frame to be transmitted.
  • the padding field tagging module 93 includes: a padding field tag unit and a encapsulating unit (not shown), where
  • the load data packet is the first load data packet of the data frame and is the last load data packet, mark the frame start bit in the padding field corresponding to the padding bit as valid, and the frame end bit flag is valid. ;
  • the frame start bit in the padding field corresponding to the padding bit is marked as invalid, and the frame end bit flag is marked as valid.
  • the load data packet is a non-first load data packet of the data frame and not a last load data packet, marking a frame start bit in the padding field corresponding to the padding bit as invalid, and the frame end bit flag is marked as invalid;
  • a packaging unit configured to encapsulate the labeled load data packet, to obtain a packaged real-time transport protocol data packet.
  • the padding field tagging module 93 further includes:
  • a load packet type bit flag unit if the load data packet is a video I frame, marking a data type bit in the padding field corresponding to the padding bit as 00, and a load packet type bit flag as 00, according to the load
  • the serial number of the data packet in the data frame is marked with a load data packet sequence number;
  • the load data packet is a video P frame
  • the data type bit in the padding field corresponding to the padding bit is marked as 00
  • the payload data packet type bit is marked as 01, according to the load data packet in the data frame.
  • the serial number of the segmentation marks the serial number of the load data packet;
  • the load data packet is a video B frame
  • the data type bit in the padding field corresponding to the padding bit is marked as 00
  • the payload data packet type bit is marked as 10, according to the load data packet in the data frame.
  • the serial number of the segmentation marks the serial number of the load data packet;
  • the load data packet is audio
  • the data type bit in the padding field corresponding to the padding bit is marked as 01
  • the payload data packet type bit is marked as 01
  • the data packet is segmented according to the load data packet.
  • the serial number of the load packet is numbered;
  • the data type bit in the padding field corresponding to the padding bit is marked as 10
  • the payload data packet type bit is marked as 11, according to the load data packet in the
  • the sequence number of the segmentation in the data frame indicates the load data packet sequence number
  • the marked load data packet is output to the package unit.
  • the transmission module 94 is configured to transmit the encapsulated real-time transport protocol data packet.
  • the apparatus further includes: a receiving module, a parsing module, and a load data packet acquiring module (not shown), where
  • a receiving module configured to receive the encapsulated real-time transport protocol data packet
  • a parsing module configured to parse a real-time transport protocol header of the received encapsulated real-time transport protocol data packet
  • a load data packet obtaining module if the padding bit in the real-time transport protocol header is marked as filled, reading each bit mark in the padding field corresponding to the padding bit, and parsing the encapsulated real-time transport protocol data packet according to the read each bit tag Load packets in .
  • parsing out the load data packet in the encapsulated real-time transport protocol data packet according to the read each bit flag includes:
  • the data type bit mark in the padding field corresponding to the padding bit If it is 01 or 10, read the frame start bit and the frame end bit in the padding field corresponding to the padding bit. If the frame start bit flag is valid, the frame end bit is Marked as valid, it is determined that the transmitted data frame contains only the load data packet behind the currently parsed real-time transport protocol header; if the frame start bit flag is valid, the frame end bit flag is invalid, and the current parsed real-time transport protocol header is determined.
  • the load data packet is the first load data packet in the transmitted data frame; if the frame start bit flag is invalid, the frame end bit flag is marked as valid, and the load data packet behind the currently parsed real-time transport protocol header is determined to be the transmitted data frame.
  • the last load packet in the frame if the frame start bit is marked as invalid, the frame end bit is marked as invalid, and the load packet sequence number in the padding field corresponding to the padding bit is read to determine the load behind the currently parsed real-time transport protocol header.
  • the location of the data packet in the transmitted data frame if the frame start bit is marked as invalid, the frame end bit is marked as invalid, and the load packet sequence number in the padding field corresponding to the padding bit is read to determine the load behind the currently parsed real-time transport protocol header.
  • the load packet type bit in the padding field corresponding to the padding bit is read, and the load packet behind the currently parsed real-time transport protocol header is determined to be a video.
  • I frame, video P frame or video B frame and read the frame start bit, frame end bit, or frame start bit, frame end bit, and load number in the padding field corresponding to the padding bit
  • the location of the load data packet behind the currently parsed real-time transport protocol header in the transmitted data frame is determined.
  • the frame start bit, the frame end bit, or the frame start bit, the frame end bit, and the load packet sequence number bit in the padding field corresponding to the padding bit are read, and the current parsing is determined.
  • the location of the payload packet behind the real-time transport protocol header in the transmitted data frame includes:
  • the frame start bit is marked as valid, the frame end bit is marked as valid, and it is determined that the transmitted data frame contains only the load data packet following the currently parsed real-time transport protocol header; if the frame start bit flag is valid, the frame end bit flag is invalid. Determining that the load data packet behind the currently parsed real-time transport protocol header is the first load data packet in the transmitted data frame; if the frame start bit flag is invalid, the frame end bit flag is valid, and determining the currently parsed real-time transport protocol The load data packet behind the header is the last load data packet in the transmitted data frame; if the frame start bit flag is invalid, the frame end bit flag is invalid, and the load data packet sequence number in the padding field corresponding to the padding bit is read. Determines the location of the payload packet behind the currently parsed real-time transport protocol header in the transmitted data frame.
  • the data frame may be obtained according to the position of each load data packet in the transmitted data frame.
  • the apparatus further includes: an original stream packet encapsulation module and a storage module (not shown), where
  • the original stream packet encapsulating module is configured to add a original stream packet fixed header to the currently parsed load data packet, and mark the padding bit in the original stream packet fixed header as padding; in the padding field corresponding to the padding bit,
  • the load data packet performs a data type bit, a frame start bit, a frame end bit, and a payload packet type bit flag to obtain an original stream packet data packet;
  • a storage module configured to store the original stream packet data packet.
  • the padding field corresponding to the padding field has a maximum number of bytes of no more than 7 bytes, and a minimum of 4 bytes, including padding bytes and an extension field, where the extension field is located in the original stream packet fixed header and padding bytes. between.
  • the device in this embodiment may be used to implement the technical solution of the method embodiment shown in FIG. 1 to FIG. 8.
  • the implementation principle and technical effects are similar, and details are not described herein again.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • a "computer-readable medium” can be any apparatus that can contain, store, communicate, propagate, or transport a program for use in an instruction execution system, apparatus, or device, or in conjunction with the instruction execution system, apparatus, or device.
  • computer readable media include the following: electrical connections (electronic devices) having one or more wires, portable computer disk cartridges (magnetic devices), random access memory (RAM), Read only memory (ROM), erasable editable read only memory (EPROM or flash memory), fiber optic devices, and portable compact disk read only memory (CDROM).
  • the computer readable medium may even be a paper or other suitable medium on which the program can be printed, as it may be optically scanned, for example by paper or other medium, followed by editing, interpretation or, if appropriate, other suitable The method is processed to obtain the program electronically and then stored in computer memory.
  • multiple steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system.
  • a suitable instruction execution system For example, if implemented in hardware, as in another embodiment, it can be implemented by any one or combination of the following techniques well known in the art: having logic gates for implementing logic functions on data signals. Discrete logic circuits, application specific integrated circuits with suitable combinational logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.
  • the embodiment of the present application further provides an electronic device, where the electronic device includes the device described in any of the foregoing embodiments.
  • FIG. 10 is a schematic structural diagram of an embodiment of an electronic device according to the present application.
  • the electronic device may include: a housing 11, a processor 12, and a memory. 13.
  • Each circuit or device is powered;
  • the memory 13 is for storing executable program code;
  • the processor 12 runs a program corresponding to the executable program code by reading executable program code stored in the memory 13 for performing any of the foregoing embodiments The data transmission method described.
  • the processor of the electronic device runs a program corresponding to the executable program code by reading the executable program code stored in the memory, and the program executes the data provided by the embodiment of the present application at runtime.
  • the transmission method can therefore achieve the purpose of reducing network resource overhead and framing delay.
  • the embodiment of the present application provides an executable program code, where the executable program code is used to execute the data transmission method provided by the embodiment of the present application, where the data transmission method may include the following steps:
  • the data type bit, the frame start bit, the frame end bit, and the payload packet type bit flag are performed on the load data packet to obtain a packaged real-time transport protocol data packet; and the package is transmitted in real time.
  • Transport protocol packets are performed on the load data packet to obtain a packaged real-time transport protocol data packet; and the package is transmitted in real time.
  • the executable program code performs the data transmission method provided by the embodiment of the present application at runtime, and thus can achieve the purpose of reducing network resource overhead and framing delay.
  • the embodiment of the present application provides a storage medium for storing executable program code, the executable program code being executed to execute the data transmission method provided by the embodiment of the present application, wherein
  • the data transmission method may include the following steps:
  • the data type bit, the frame start bit, the frame end bit, and the payload packet type bit flag are performed on the load data packet to obtain a packaged real-time transport protocol data packet; and the package is transmitted in real time.
  • Transport protocol packets are performed on the load data packet to obtain a packaged real-time transport protocol data packet; and the package is transmitted in real time.
  • the storage medium stores an application that performs the data transmission method provided by the embodiment of the present application at runtime, and thus can achieve the purpose of reducing network resource overhead and framing delay.
  • Mobile communication devices These devices are characterized by mobile communication functions and are mainly aimed at providing voice and data communication.
  • Such terminals include: smart phones (such as iPhone), multimedia phones, functional phones, and low-end phones.
  • Ultra-mobile personal computer equipment This type of equipment belongs to the category of personal computers, has computing and processing functions, and generally has mobile Internet access.
  • Such terminals include: PDAs, MIDs, and UMPC devices, such as the iPad.
  • Portable entertainment devices These devices can display and play multimedia content. Such equipment These include: audio, video players (such as iPods), handheld game consoles, e-books, and smart toys and portable car navigation devices.
  • the server consists of a processor, a hard disk, a memory, a system bus, etc.
  • the server is similar to a general-purpose computer architecture, but because of the need to provide highly reliable services, processing power and stability High reliability in terms of reliability, security, scalability, and manageability.
  • each unit/module may be implemented in the same software or software and/or hardware when implementing the present application.
  • the present application can be implemented by means of software plus a necessary general hardware platform. Based on such understanding, the technical solution of the present application may be embodied in the form of a software product in essence or in the form of a software product, which may be stored in a storage medium such as a ROM/RAM or a disk. , an optical disk, etc., includes instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform the methods described in various embodiments of the present application or portions of the embodiments.
  • a computer device which may be a personal computer, server, or network device, etc.

Abstract

本申请的实施例公开一种数据传输方法、装置及电子设备，涉及数据传输及存储技术，能够降低网络资源开销以及组帧时延。所述数据传输方法包括：将待传输的数据帧切分为一个或多个预定长度的负载数据包；为每一负载数据包添加实时传输协议头，将所述实时传输协议头中的填充位标记为有填充；在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到封装的实时传输协议数据包；传输所述封装的实时传输协议数据包。本申请适用于对数据进行RTP封装后传输。

Description

一种数据传输方法、装置及电子设备
本申请要求于2016年9月23日提交中国专利局、申请号为201610846489.3发明名称为“一种数据传输方法、装置及电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及数据传输及存储技术，尤其涉及一种数据传输方法、装置及电子设备。
背景技术
随着计算机通信以及互联网技术，尤其是4G通信技术的不断发展，电子设备，例如，智能移动电话、个人数字助理、掌上电脑、笔记本电脑等应用越来越广泛，电子设备中安装的应用程序(APP，Application)越来越多，提供的应用功能也越来越丰富。举例来说，随着流媒体技术的发展，用户可以通过安装在电子设备中的播放器，实现对多路音视频数据的同步播放，从而极大地增强和丰富了用户的体验。
目前，在实现多路音视频数据同步传输时，需要将多路音视频数据单独进行处理，每一路音视频数据的采集、编码、网络传输、解码及输出，相互独立，独自控制，只是在输出时的播放阶段进行播放的同步处理，即在输出时，将多路输出的音视频数据进行拼接处理，以实现多路画面在一显示器上输出。
但该数据传输方法，一路音视频数据需要独立占用一网络传输通道，需要传输的音视频数据数量多，网络资源开销大，且在接收端，需要依据各路音视频数据中的时间戳信息进行组帧拼接，时延较大。
发明内容
有鉴于此，本申请实施例提供一种数据传输方法、装置及电子设备，能够降低网络资源开销以及组帧时延。
第一方面，本申请实施例提供一种数据传输方法，包括：
将待传输的数据帧切分为一个或多个预定长度的负载数据包；
为每一负载数据包添加实时传输协议头，将所述实时传输协议头中的填充位标记为有填充；
在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到封装的实时传输协议数据包；
传输所述封装的实时传输协议数据包。
结合第一方面，在第一方面的第一种实施方式中，所述填充位对应的填充字段包括：数据填充字段以及扩展字段，其中，扩展字段占用4字节，包括：保留字段、合成数据帧指示位字段以及填充大小字段。
结合第一方面的第一种实施方式，在第一方面的第二种实施方式中，所述合成数据帧指示位字段中的数据类型位占用2bit，帧开始位以及帧结束位各占1bit，负载数据包类型位占用2bit。
结合第一方面的第二种实施方式，在第一方面的第三种实施方式中，所述合成数据帧指示位字段中，还包括：各占用4bit的负载数据包序号位以及通道位。
结合第一方面、第一方面的第一种至第三种中的任一种实施方式，在第一方面的第四种实施方式中，所述得到封装的实时传输协议数据包包括：
如果所述负载数据包为所述数据帧的第一个负载数据包且非最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为有效，帧结束位标记为无效；
如果所述负载数据包为所述数据帧的第一个负载数据包且为最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为有效，帧结束位标记为有效；
如果所述负载数据包为所述数据帧的最后一个负载数据包且非第一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束位标记为有效；
如果所述负载数据包为所述数据帧的非第一个负载数据包且非最后一个 负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束位标记为无效；
封装标记的所述负载数据包，得到封装的实时传输协议数据包。
结合第一方面的第四种实施方式，在第一方面的第五种实施方式中，在所述封装标记的所述负载数据包之前，所述方法还包括：
如果所述负载数据包为视频I帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为00，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为视频P帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为视频B帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为10，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为音频，将所述填充位对应的填充字段中的数据类型位标记为01，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为私有数据，将所述填充位对应的填充字段中的数据类型位标记为10，负载数据包类型位标记为11，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位。
结合第一方面、第一方面的第一种至第三种中的任一种实施方式，在第一方面的第六种实施方式中，所述方法还包括：
接收封装的实时传输协议数据包；
解析接收的封装的实时传输协议数据包的实时传输协议头；
如果所述实时传输协议头中的填充位标记为有填充，读取填充位对应的填充字段中的各位标记，依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包。
结合第一方面的第六种实施方式，在第一方面的第七种实施方式中，所述依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包包括：
读取填充位对应的填充字段中的数据类型位标记，如果为01或10，读取填充位对应的填充字段中的帧开始位以及帧结束位，如果帧开始位标记为有效，帧结束位标记为有效，确定传输的数据帧中只包含当前解析的实时传输协议头后面的负载数据包；如果帧开始位标记为有效，帧结束位标记为无效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的第一个负载数据包；如果帧开始位标记为无效，帧结束位标记为有效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的最后一个负载数据包；如果帧开始位标记为无效，帧结束位标记为无效，读取填充位对应的填充字段中的负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置；
如果读取的填充位对应的填充字段中的数据类型位标记为00，读取填充位对应的填充字段中的负载数据包类型位，确定当前解析的实时传输协议头后面的负载数据包为视频I帧、视频P帧或视频B帧，并读取填充位对应的填充字段中的帧开始位、帧结束位，或者，帧开始位、帧结束位以及负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置。
结合第一方面的第六种实施方式，在第一方面的第八种实施方式中，所述方法还包括：
为当前解析得到的负载数据包添加原始流分组固定头，将所述原始流分组固定头中的填充位标记为有填充；在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到原始流分组数据包；
存储所述原始流分组数据包。
结合第一方面的第八种实施方式，在第一方面的第九种实施方式中，所述填充位对应的填充字段的字节数最大不超过7字节，最小为4字节，包括 填充字节以及扩展字段，其中，扩展字段位于原始流分组固定头与填充字节之间。
第二方面，本申请实施例提供一种数据传输装置，包括：切分模块、实时传输协议头标记模块、填充字段标记模块以及传输模块，其中，
切分模块，用于将待传输的数据帧切分为一个或多个预定长度的负载数据包；
实时传输协议头标记模块，用于为每一负载数据包添加实时传输协议头，将所述实时传输协议头中的填充位标记为有填充；
填充字段标记模块，用于在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到封装的实时传输协议数据包；
传输模块，用于传输所述封装的实时传输协议数据包。
结合第二方面，在第二方面的第一种实施方式中，所述填充位对应的填充字段包括：数据填充字段以及扩展字段，其中，扩展字段占用4字节，包括：保留字段、合成数据帧指示位字段以及填充大小字段。
结合第二方面的第一种实施方式，在第二方面的第二种实施方式中，所述合成数据帧指示位字段中的数据类型位占用2bit，帧开始位以及帧结束位各占1bit，负载数据包类型位占用2bit。
结合第二方面的第二种实施方式，在第二方面的第三种实施方式中，所述合成数据帧指示位字段中，还包括：各占用4bit的负载数据包序号位以及通道位。
结合第二方面、第二方面的第一种至第三种中的任一种实施方式，在第二方面的第四种实施方式中，所述填充字段标记模块包括：填充字段标记单元以及封装单元，其中，
填充字段标记单元，如果所述负载数据包为所述数据帧的第一个负载数据包且非最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为有效，帧结束位标记为无效；
如果所述负载数据包为所述数据帧的第一个负载数据包且为最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为有效，帧结束位标记为有效；
如果所述负载数据包为所述数据帧的最后一个负载数据包且非第一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束位标记为有效；
如果所述负载数据包为所述数据帧的非第一个负载数据包且非最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束位标记为无效；
封装单元，用于封装标记的所述负载数据包，得到封装的实时传输协议数据包。
结合第二方面的第四种实施方式，在第二方面的第五种实施方式中，所述填充字段标记模块还包括：
负载数据包类型位标记单元，如果所述负载数据包为视频I帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为00，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为视频P帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为视频B帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为10，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为音频，将所述填充位对应的填充字段中的数据类型位标记为01，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为私有数据，将所述填充位对应的填充字段中的数据类型位标记为10，负载数据包类型位标记为11，依据所述负载数据包在所 述数据帧中切分的序号标记负载数据包序号位；
将标记的所述负载数据包输出至封装单元。
结合第二方面、第二方面的第一种至第三种中的任一种实施方式，在第二方面的第六种实施方式中，所述装置还包括：接收模块、解析模块以及负载数据包获取模块，其中，
接收模块，用于接收封装的实时传输协议数据包；
解析模块，用于解析接收的封装的实时传输协议数据包的实时传输协议头；
负载数据包获取模块，如果所述实时传输协议头中的填充位标记为有填充，读取填充位对应的填充字段中的各位标记，依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包。
结合第二方面的第六种实施方式，在第二方面的第七种实施方式中，所述依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包包括：
读取填充位对应的填充字段中的数据类型位标记，如果为01或10，读取填充位对应的填充字段中的帧开始位以及帧结束位，如果帧开始位标记为有效，帧结束位标记为有效，确定传输的数据帧中只包含当前解析的实时传输协议头后面的负载数据包；如果帧开始位标记为有效，帧结束位标记为无效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的第一个负载数据包；如果帧开始位标记为无效，帧结束位标记为有效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的最后一个负载数据包；如果帧开始位标记为无效，帧结束位标记为无效，读取填充位对应的填充字段中的负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置；
如果读取的填充位对应的填充字段中的数据类型位标记为00，读取填充位对应的填充字段中的负载数据包类型位，确定当前解析的实时传输协议头后面的负载数据包为视频I帧、视频P帧或视频B帧，并读取填充位对应的填充字段中的帧开始位、帧结束位，或者，帧开始位、帧结束位以及负载数 据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置。
结合第二方面的第六种实施方式，在第二方面的第八种实施方式中，所述装置还包括：原始流分组封装模块以及存储模块，其中，
原始流分组封装模块，用于为当前解析得到的负载数据包添加原始流分组固定头，将所述原始流分组固定头中的填充位标记为有填充；在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到原始流分组数据包；
存储模块，用于存储所述原始流分组数据包。
结合第二方面的第八种实施方式，在第二方面的第九种实施方式中，所述填充位对应的填充字段的字节数最大不超过7字节，最小为4字节，包括填充字节以及扩展字段，其中，扩展字段位于原始流分组固定头与填充字节之间。
第三方面，本申请实施例提供一种电子设备，所述电子设备包括：壳体、处理器、存储器、电路板和电源电路，其中，电路板安置在壳体围成的空间内部，处理器和存储器设置在电路板上；电源电路，用于为上述电子设备的各个电路或器件供电；存储器用于存储可执行程序代码；处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的程序，用于执行前述任一所述的数据传输方法。
第四方面，本申请实施例提供了一种存储介质，所述存储介质用于存储可执行程序代码，所述可执行程序代码被运行以执行前述任一所述的数据传输方法。
本申请实施例提供的一种数据传输方法、装置及电子设备，通过将待传输的数据帧切分为一个或多个预定长度的负载数据包；为每一负载数据包添加实时传输协议头，将所述实时传输协议头中的填充位标记为有填充；在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到封装的实时传输协议数据包；传输所述封装的实时传输协议数据包，能够降低网络资源开销以及组帧时延。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1为本申请的实施例一数据传输方法流程示意图；
图2为帧RTP数据包结构示意图；
图3为本实施例的RTP头结构示意图；
图4为现有技术封装的RTP数据包结构示意图；
图5为本实施例封装的RTP数据包结构示意图；
图6为本实施例合成数据帧指示位字段的语法格式示意图；
图7为现有技术封装的PES数据包结构示意图；
图8为本实施例封装的PES数据包结构示意图；
图9为本申请的实施例二数据传输装置结构示意图；
图10为本申请电子设备一个实施例的结构示意图。
具体实施方式
下面结合附图对本申请实施例进行详细描述。
应当明确，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
图1为本申请的实施例一数据传输方法流程示意图，如图1所示，本实施例的方法可以包括：
步骤101，将待传输的数据帧切分为一个或多个预定长度的负载数据包；
本实施例中，作为一可选实施例，预定长度为4字节。最后一负载数据包的长度小于或等于4字节。
步骤102，为每一负载数据包添加实时传输协议头，将所述实时传输协议头中的填充位标记为有填充；
本实施例中，实时传输协议(RTP，Realtime Transport Protocol)是互联网上传递数据的标准数据包协议。
本实施例中，通过为负载数据包添加实时传输协议头，利用实时传输协议对负载数据包进行封装，使之成为(封装的)实时传输协议数据包，可以增强数据传输的实时性。其中，多个实时传输协议数据包组成帧RTP数据包。
图2为帧RTP数据包结构示意图，参见图2，一帧RTP数据包(Frame RTP Packets)包含一个或多个RTP数据包(RTP Packet)，每一RTP数据包包括：RTP头标准字段(RTP头)、RTP头私有扩展字段、RTP标准负载字段以及RTP填充字段。其中，RTP填充字段包括：填充数据字段、自定义字段以及扩展长度字段。
图3为本实施例的RTP头结构示意图，参见图3，在两个“+”之间的“—”或“＝”，表示为一小格，每一小格表示1bit，其中，根据RFC3550的定义，RTP头的各语法格式说明如下：
version(V)，占2bit，标识版本；
padding(P)，占1bit，标识是否有填充部分，当设置为1时，表示在RTP数据包尾部有填充部分，且该填充部分的最后一个字节表示该填充部分的长度(包括该字节本身长度)；
extension(X)，占1bit，为扩展比特位，标志是否有扩展字段，当设置为1时，表示该RTP数据包的RTP头部包含扩展字段；
CSRC count(CC)，占4bits，标识参与源(CSRC，Contributing Source)字段的个数；
marker bit(M)，占1bit，当设置为1时，表示当前RTP包是所传输的最后一数据包。
payload type(PT)，占7bits，用于标识传输的数据内容的类型；
sequence number(SN)，占16bits，用于标识RTP数据包发送的顺序，即 接收端收到后送到解码器里的顺序，每一RTP数据包递增1；
Timestamp，占32bits，用于标识该RTP数据包所包含内容的采集(采样)时刻；
其他字段，例如，同步源(SSRC，synchronization source)标识符(identifier)、CSRC标识符(identifier)等，具体语法格式参见相关协议，在此略去详述。
步骤103，在填充位对应的填充字段中，对所述负载数据包进行数据类型、帧开始位、帧结束位以及负载数据包类型标记，得到封装的实时传输协议数据包；
本实施例中，在对负载数据包进行RTP封装时，按照4字节对齐的方式进行封装。由于实际应用中，每一RTP实际负载的长度不是严格按照4字节对齐，因而，需要在RTP标准负载字段中执行填充处理，填充的字节数为1、2或3，并且填充长度的末尾字节表示填充的长度。
图4为相关技术封装的RTP数据包结构示意图，如图4所示。图中的0，1，2，3为填充字节，即填充位对应的填充字段。例如，如果负载数据包长度为4字节，则填充字节为0，图中虚线框为空，表示不存在填充；如果负载数据包长度为3字节，填充字节为1，虚线框的字节为0xff 0x01；如果负载数据包长度为2字节，填充字节为2，虚线框的字节为0xff 0x02等。
本实施例中，对填充位对应的填充字段进行改进，扩展RTP头中充填(padding)字段的默认使用，如图5所示，图5为本实施例封装的RTP数据包结构示意图。在填充字段中，最少填充4字节。相对于图4的封装的RTP数据包结构方式，填充字段多扩展出4字节，其中，
本实施例中，作为一可选实施例，填充位对应的填充字段包括：数据填充字段以及扩展字段，其中，扩展字段占用4字节，依序包括：保留字段(res)、合成数据帧指示位字段(MFI，Multiple Frame Indicator)以及填充大小字段。其中，
保留字段占用2字节，默认填写为0；
填充大小字段指的是除了负载数据以外的实际数据大小，且包含自身占 用的一个字节，举例来说，填充大小包括：图5中0，1，2及res、MFI、填充大小字段。
图6为本实施例合成数据帧指示位字段的语法格式示意图。参见图6，合成数据帧指示位字段占用2字节，其中，一“-”表示1bit，语法格式如下：
V，占用2bit，标识MFI类型版本号；
T，数据类型位，占用2bit，标识数据类型，其中，00标识视频，01标识音频，10标识私有帧，11用作保留位；
S，帧开始位，占用1bit，标识合成数据帧(数据帧)开始，其中，如果置1(有效)，标识合成数据帧(数据帧)是以Imi帧或Pmi帧开始的起始RTP数据包；如果置0(无效)，标识合成数据帧为起始RTP数据包之后的RTP数据包；
E，帧结束位，占用1bit，标识合成数据帧结束，其中，如果置1，标识合成数据帧是以Imi帧或Pmi帧结束的RTP数据包，如果置0，标识其他合成数据帧传输结束；
FT，负载数据包类型位，占用2bit，标识负载数据包类型，其中，
如果T为00(视频)，即待传输的数据帧为视频，设置00标识I帧，01标识P帧，10标识B帧，11用作保留；
如果T为01(音频)，利用01进行标识，其他用作保留；
如果T为10(私有帧)利用11进行标识，其他用作保留；
N，负载数据包序号位，占用4bit，标识传输的负载数据包(封装的实时传输协议数据包)所属通道的通道序号，序号范围0～15；
在本申请的可选实施例中，上述的传输的负载数据包所属通道的通道序号，可以相当于后续提到的负载数据包在数据帧中切分的序号。
Tl，通道位，占用4bit，标识待传输数据帧的通道数。
通道位可以标识待传输数据帧的通道数，即可以标识待传输数据帧具体为几路待传输数据的数据帧。
本实施例中，通过在数据封装过程中填充该负载数据包在数据帧中的序号N以及待传输数据帧的通道数T1，用于标识实际传输过程中接收到的数据是哪一通道的数据以及该数据在数据帧中的位置，使得在接收端通过解析该序号和通道数，可以区分出接收的数据是哪一通道的数据以及具体的位置。
本实施例中，例如，如果待传输数据帧具有3通道视频数据，T1设置为3，如果具有6通道视频数据，T1设置为6。
本实施例中，在后续数据解析过程中，可以通过N(封装的实时传输协议数据包序号)、T1、S以及E来判断当前的Imi帧是否结束，进而记录一合成数据帧中实际音视频帧及相应的大小。其中，T1指的是具体哪一通道数据，例如，如果为RTP数据包第1通道视频数据，对应的序号T1可以设置为0，S是数据帧起始标记，读取到S标记可以获知是数据帧开始传输，从而可以不断的获取(封装的)RTP数据包，当读到某一RTP数据包的序号也是0，并且E标记为1的情况下，此时就可以认为第1路视频数据传输完毕，可以将传输完毕的第1路视频数据提取出来。
本实施例中，在后续数据解析过程中，可以通过N(封装的实时传输协议数据包序号)、T1、S以及E来判断当前的Imi帧是否结束，进而记录一合成数据帧中实际包含几个音视频数据及每一音视频数据相应的大小。其中，N指的是具体哪一通道数据，例如，如果RTP数据包为第1通道视频数据，对应的序号N可以设置为0，S是数据帧起始标记，读取到S标记可以获知是数据帧开始传输，从而可以不断的获取(封装的)RTP数据包，当读到某一RTP数据包的序号N也是0，并且E标记为1的情况下，此时就可以认为第1路视频数据传输完毕，可以将传输完毕的第1路视频数据提取出来。
本实施例中，合成数据帧(数据帧)内部不存在混合类型的数据，举例来说，不同时存在I帧和P帧，或者，不同时存在视频帧和音频帧，或者，不同时存在视频帧和私有帧两两交叉的情况。
本实施例中，通过将一帧数据分割成多个数据单元(负载数据包)，为每一数据单元添加一RTP头，在RTP头中的padding填充字段进行数据单元信息定义，即在RTP padding定义中，引入数据的起始结束标志，从而可以有效降低数据解析时的延时问题。同时，将多路音视频数据合成在一网络传输通 道中进行传输，有效降低了网络资源开销。
本实施例中，作为一可选实施例，得到封装的实时传输协议数据包包括：
如果所述负载数据包为所述数据帧的第一个负载数据包且非最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为有效，帧结束位标记为无效；
如果所述负载数据包为所述数据帧的第一个负载数据包且为最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为有效，帧结束位标记为有效；
如果所述负载数据包为所述数据帧的最后一个负载数据包且非第一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束位标记为有效；
如果所述负载数据包为所述数据帧的非第一个负载数据包且非最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束位标记为无效；
封装标记的所述负载数据包，得到封装的实时传输协议数据包。
本实施例中，作为一可选实施例，在所述封装标记的所述负载数据包之前，该方法还包括：
如果所述负载数据包为视频I帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为00，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为视频P帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为视频B帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为10，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为音频，将所述填充位对应的填充字段中的数据类 型位标记为01，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为私有数据，将所述填充位对应的填充字段中的数据类型位标记为10，负载数据包类型位标记为11，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位。
步骤104，传输所述封装的实时传输协议数据包。
作为一可选实施例，该方法还包括：
接收封装的实时传输协议数据包；
解析接收的封装的实时传输协议数据包的实时传输协议头；
如果所述实时传输协议头中的填充位标记为有填充，读取填充位对应的填充字段中的各位标记，依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包。
本实施例中，作为一可选实施例，依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包包括：
读取填充位对应的填充字段中的数据类型位标记，如果为01或10，读取填充位对应的填充字段中的帧开始位以及帧结束位，如果帧开始位标记为有效，帧结束位标记为有效，确定传输的数据帧中只包含当前解析的实时传输协议头后面的负载数据包；如果帧开始位标记为有效，帧结束位标记为无效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的第一个负载数据包；如果帧开始位标记为无效，帧结束位标记为有效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的最后一个负载数据包；如果帧开始位标记为无效，帧结束位标记为无效，读取填充位对应的填充字段中的负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置；
如果读取的填充位对应的填充字段中的数据类型位标记为00，读取填充位对应的填充字段中的负载数据包类型位，确定当前解析的实时传输协议头后面的负载数据包为视频I帧、视频P帧或视频B帧，并读取填充位对应的 填充字段中的帧开始位、帧结束位，或者，帧开始位、帧结束位以及负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置。
本实施例中，读取填充位对应的填充字段中的帧开始位、帧结束位，或者，帧开始位、帧结束位以及负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置包括：
如果帧开始位标记为有效，帧结束位标记为有效，确定传输的数据帧中只包含当前解析的实时传输协议头后面的负载数据包；如果帧开始位标记为有效，帧结束位标记为无效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的第一个负载数据包；如果帧开始位标记为无效，帧结束位标记为有效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的最后一个负载数据包；如果帧开始位标记为无效，帧结束位标记为无效，读取填充位对应的填充字段中的负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置。
本实施例中，在确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置后，依据各负载数据包在传输的数据帧中的位置进行组帧，可以得到数据帧。
本实施例中，由于封装的RTP数据包是一种网络数据传输方式，传输的RTP数据包携带的信息量较少，不适合进行存储。因而，作为一可选实施例，该方法还可以包括：
为当前解析得到的负载数据包添加原始流分组固定头，将所述原始流分组固定头中的填充位标记为有填充；在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到原始流分组数据包；
存储所述原始流分组数据包。
本实施例中，MPEG2PS/TS是一种多路复用数字音频、视频等的封装容器，该封装格式的基本单元为原始流分组(PES，Packetized Elementary Stream)数据包。本实施例中，基于RTP及MPEG2PS的标准文档来设计数据存储的 格式，其中，为了提高数据的处理效率，MPEG2PS都是默认采用4字节对齐的方式来处理。
本实施例中，对解析得到的负载数据包采用4字节对齐方式进行封装，即PES固定头加填充字节加负载整体四字节对齐，对于实际负载数据是否4字节对齐不做限制。
图7为现有技术封装的PES数据包结构示意图；
图8为本实施例封装的PES数据包结构示意图。参见图7及图8，现有PES包封装中，由于封装的PES数据包按照4字节对齐，因而，在填充位对应的填充字段中，填充字节的长度可能是0、1、2、3个字节，即填充长度(Stuff-len)最大不超过3个字节，最小没有填充字节，填充字节填充在数据头(PES固定头)的末尾。
本实施例封装的PES数据包中，在填充位对应的填充字段中，包括填充字节以及扩展字段，其中，
填充字节的长度可能是0、1、2、3个字节，最大不超过3个字节，最小没有填充字节；
扩展字段为4字节。
因而，本实施例中，填充位对应的填充字段的字节数为4、5、6或7个字节，最大不超过7字节，最小为4字节。
本实施例中，作为一可选实施例，扩展字段位于PES固定头与填充字节之间，依序包括：第一保留字段、合成数据帧指示位字段以及第二保留字段，其中，
第一保留字段(res1)、第二保留字段(res2)分别占用1字节；
合成数据帧指示位字段(MFI)占用两字节，与RTP数据包中MFI相同，语法格式如下：
V，占用2bit，标识MFI类型版本号；
T，数据类型位，占用2bit，标识数据类型，其中，00标识视频，01标 识音频，10标识私有帧，11用作保留位；
S，帧开始位，占用1bit，标识合成数据帧(数据帧)开始，其中，如果置1(有效)，标识合成数据帧(数据帧)是以Imi帧或Pmi帧开始的起始RTP数据包；如果置0(无效)，标识合成数据帧为起始RTP数据包之后的RTP数据包；
E，帧结束位，占用1bit，标识合成数据帧结束，其中，如果置1，标识合成数据帧是以Imi帧或Pmi帧结束的RTP数据包，如果置0，标识其他合成数据帧传输结束；
FT，负载数据包类型位，占用2bit，标识负载数据包类型，其中，
如果T为00(视频)，即待传输的数据帧为视频，设置00标识I帧，01标识P帧，10标识B帧，11用作保留；
如果T为01(音频)，利用01进行标识，其他用作保留；
如果T为10(私有帧)利用11进行标识，其他用作保留；
N，负载数据包序号位，占用4bit，标识传输的负载数据包(封装的实时传输协议数据包)所属通道的通道序号，序号范围0～15；
Tl，占用4bit，标识待传输数据帧的通道数。
本实施例中，负载数据包类型位为数据类型位的一子类型位。
本实施例中，通过选用安防行业常用的MPEG2PS/TS格式进行数据存储，提供RTP与MPEG2PS/TS的互转机制，并定义了基于MPEG2PS/TS的多路音视频数据的存储格式。相关技术中的多路音视频数据的存储格式，多路的音视频数据封装在MPEG2PS/TS中，需要选择不同的数据类型位标识(stream identificator)进行区分，即按照ISO 138181对于PS/TS的定义，视频数据的数据类型位标识(ID)可以选择0xe0-0xef之间的字段；音频数据的数据类型位标识可以选择0xc0-0xcf。而本实施例的数据存储格式，在MPEG2PS/TS的最小单元PES中，通过扩展字段定义每一数据流(负载数据包)的信息，采用音视频数据及私有数据各选用一数据类型位标识来进行处理，使用最多3个数据类型位(视频00、音频01、私有数据10)的情况下，实现多路音视频 数据(流)的封装存储，使得处理简单，能够有效提升存储效率。
也就是说，本实施例中，通过选用安防行业常用的MPEG2PS/TS格式进行数据存储，提供RTP与MPEG2PS/TS的互转机制，并定义了基于MPEG2PS/TS的多路音视频数据的存储格式。其中，根据传输媒体的质量不同，MPEG-2中定义了两种复合信息流：一种为TS(TransportStream，传送流)，其包结构是固定长度的；一种为PS(ProgramStream，节目流)，其包结构是可变长度的。MPEG-2是MPEG(Moving Picture Experts Group，运动图像专家组)组织制定的视频和音频有损压缩标准之一，MPEG-2的名称可以为"基于数字存储媒体运动图像和语音的压缩标准"。
本实施例中，可以基于标准的RTSP(Real Time Streaming Protocol，实时流协议)协议进行服务及客户端的交互，使用RTP数据包进行数据传输。在协议交互上，对于RTSP协议的SDP(Session Description Protocol，会话描述协议)的属性进行扩展，扩展在基于RTSP协议的基础上定义新增属性定义，用于通过扩展字段告知客户端实际码流中音视频的路数及音视频的编码参数等。
本实施例中，SDP新增属性定义的程序代码段可以如下：
a＝stream_mark:<stream mark tag>/<video count>/<audio count>/<privatecount>
a＝video_config:<stream0configure>/<stream1configure>…/<streamNconfigure>
a＝audio_config:<stream0configure>/<stream1configure>…/<streamNconfigure>
a＝priv_config:<stream0configure>/<stream1configure>…/<streamNconfigure>
stream_mark:多路流标志
video_config:视频参数配置信息，例如，视频的宽高等信息
audio_config:音频参数配置信息
priv_config:私有数据配置信息
例如，针对一多路流，相应SDP新增属性定义的程序代码段可以如下：
a＝stream_mark:MFI/video 2/audio 1/private 3
a＝video_config:<stream0“abcdef”>/<stream2“0fffcd”>
a＝audio_config:<stream0“xxxxaa”>
a＝priv_config:<stream0“abmmac”>/<stream2“ddeff”>/<stream2“0fffcd”>
本实施例中，将客户端接收的RTP数据包转换成PS数据进行存储。后续应用中，存储的PS数据可以再转换成RTP数据包进行网络发送。
在一种实现方式中，将RTP数据包转换成PS数据的转换过程可以是：客户端从RTP数据包中提取出负载数据包，并将所提取出的负载数据包进行PS封装，得到PS数据。后续的，客户端可以对上述所得的PS数据进行存储。
由上述可见，本申请实施例的数据传输方法，基于标准RTSP协议定义数据的传输方式，在遵守标准协议的情况下，设计了多路数据的SDP信息中的音视频及私有数据的新增属性定义，使得数据传输方以及接收方可以获知媒体数据流的数量及配置信息，增加了多路数据处理的灵活性；进一步地，通过扩展字段设置帧开始位、帧结束位、数据类型位以及负载数据包类型位，可以快速实现组帧，有效降低延时；此外，基于MPEG2PS/TS定义数据的存储格式，提供一种多路流使用少量数据类型位标识存储的方式，对于多路流的数量不进行限制，有利于未来大量的多路流数据合成。
图9为本申请的实施例二数据传输装置结构示意图，如图9所示，本实施例的装置可以包括：切分模块91、实时传输协议头标记模块92、填充字段标记模块93以及传输模块94，其中，
切分模块91，用于将待传输的数据帧切分为一个或多个预定长度的负载数据包；
本实施例中，作为一可选实施例，预定长度为4字节。
实时传输协议头标记模块92，用于为每一负载数据包添加实时传输协议 头，将所述实时传输协议头中的填充位标记为有填充；
本实施例中，RTP头的各语法格式说明如下：
version(V)，占2bit，标识版本；
padding(P)，占1bit，标识是否有填充部分，当设置为1时，表示在RTP数据包尾部有填充部分，且该填充部分的最后一个字节表示该填充部分的长度(包括该字节本身长度)；
extension(X)，占1bit，为扩展比特位，标志是否有扩展字段，当设置为1时，表示该RTP数据包的RTP头部包含扩展字段；
CSRC count(CC)，占4bits，标识参与源(CSRC，Contributing Source)字段的个数；
marker bit(M)，占1bit，当设置为1时，表示当前RTP包是所传输的最后一数据包。
payload type(PT)，占7bits，用于标识传输的数据内容的类型；
sequence number(SN)，占16bits，用于标识RTP数据包发送的顺序，即接收端收到后送到解码器里的顺序，每一RTP数据包递增1；
Timestamp，占32bits，用于标识该RTP数据包所包含内容的采集(采样)时刻；
其他字段，例如，同步源(SSRC，synchronization source)标识符(identifier)、CSRC标识符(identifier)等，具体语法格式参见相关协议，在此略去详述。
填充字段标记模块93，用于在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到封装的实时传输协议数据包；
本实施例中，作为一可选实施例，填充位对应的填充字段包括：数据填充字段以及扩展字段，其中，扩展字段占用4字节，包括：保留字段、合成数据帧指示位字段以及填充大小字段。其中，
合成数据帧指示位字段中的数据类型位占用2bit，帧开始位以及帧结束位 各占1bit，负载数据包类型位占用2bit。
本实施例中，作为一可选实施例，合成数据帧指示位字段中，还包括：各占用4bit的负载数据包序号位以及通道位。
本实施例中，合成数据帧指示位字段占用2字节，语法格式如下：
V，占用2bit，标识MFI类型版本号；
T，数据类型位，占用2bit，标识数据类型，其中，00标识视频，01标识音频，10标识私有帧，11用作保留位；
S，帧开始位，占用1bit，标识合成数据帧(数据帧)开始，其中，如果置1(有效)，标识合成数据帧(数据帧)是以Imi帧或Pmi帧开始的起始RTP数据包；如果置0(无效)，标识合成数据帧为起始RTP数据包之后的RTP数据包；
E，帧结束位，占用1bit，标识合成数据帧结束，其中，如果置1，标识合成数据帧是以Imi帧或Pmi帧结束的RTP数据包，如果置0，标识其他合成数据帧传输结束；
FT，负载数据包类型位，占用2bit，标识负载数据包类型，其中，
如果T为00(视频)，即待传输的数据帧为视频，设置00标识I帧，01标识P帧，10标识B帧，11用作保留；
如果T为01(音频)，利用01进行标识，其他用作保留；
如果T为10(私有帧)利用11进行标识，其他用作保留；
N，负载数据包序号位，占用4bit，标识传输的负载数据包(封装的实时传输协议数据包)所属通道的通道序号，序号范围0～15；
Tl，通道位，占用4bit，标识待传输数据帧的通道数。
本实施例中，作为一可选实施例，填充字段标记模块93包括：填充字段标记单元以及封装单元(图中未示出)，其中，
填充字段标记单元，如果所述负载数据包为所述数据帧的第一个负载数据包且非最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位 标记为有效，帧结束位标记为无效；
如果所述负载数据包为所述数据帧的第一个负载数据包且为最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为有效，帧结束位标记为有效；
如果所述负载数据包为所述数据帧的最后一个负载数据包且非第一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束位标记为有效；
如果所述负载数据包为所述数据帧的非第一个负载数据包且非最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束位标记为无效；
封装单元，用于封装标记的所述负载数据包，得到封装的实时传输协议数据包。
本实施例中，作为另一可选实施例，填充字段标记模块93还包括：
负载数据包类型位标记单元，如果所述负载数据包为视频I帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为00，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为视频P帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为视频B帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为10，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为音频，将所述填充位对应的填充字段中的数据类型位标记为01，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
如果所述负载数据包为私有数据，将所述填充位对应的填充字段中的数据类型位标记为10，负载数据包类型位标记为11，依据所述负载数据包在所 述数据帧中切分的序号标记负载数据包序号位；
将标记的所述负载数据包输出至封装单元。
传输模块94，用于传输所述封装的实时传输协议数据包。
本实施例中，作为一可选实施例，该装置还包括：接收模块、解析模块以及负载数据包获取模块(图中未示出)，其中，
接收模块，用于接收封装的实时传输协议数据包；
解析模块，用于解析接收的封装的实时传输协议数据包的实时传输协议头；
负载数据包获取模块，如果所述实时传输协议头中的填充位标记为有填充，读取填充位对应的填充字段中的各位标记，依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包。
本实施例中，作为一可选实施例，依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包包括：
读取填充位对应的填充字段中的数据类型位标记，如果为01或10，读取填充位对应的填充字段中的帧开始位以及帧结束位，如果帧开始位标记为有效，帧结束位标记为有效，确定传输的数据帧中只包含当前解析的实时传输协议头后面的负载数据包；如果帧开始位标记为有效，帧结束位标记为无效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的第一个负载数据包；如果帧开始位标记为无效，帧结束位标记为有效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的最后一个负载数据包；如果帧开始位标记为无效，帧结束位标记为无效，读取填充位对应的填充字段中的负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置；
如果读取的填充位对应的填充字段中的数据类型位标记为00，读取填充位对应的填充字段中的负载数据包类型位，确定当前解析的实时传输协议头后面的负载数据包为视频I帧、视频P帧或视频B帧，并读取填充位对应的填充字段中的帧开始位、帧结束位，或者，帧开始位、帧结束位以及负载数 据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置。
本实施例中，作为一可选实施例，读取填充位对应的填充字段中的帧开始位、帧结束位，或者，帧开始位、帧结束位以及负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置包括：
如果帧开始位标记为有效，帧结束位标记为有效，确定传输的数据帧中只包含当前解析的实时传输协议头后面的负载数据包；如果帧开始位标记为有效，帧结束位标记为无效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的第一个负载数据包；如果帧开始位标记为无效，帧结束位标记为有效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的最后一个负载数据包；如果帧开始位标记为无效，帧结束位标记为无效，读取填充位对应的填充字段中的负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置。
本实施例中，在确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置后，依据各负载数据包在传输的数据帧中的位置进行组帧，可以得到数据帧。
本实施例中，作为另一可选实施例，该装置还包括：原始流分组封装模块以及存储模块(图中未示出)，其中，
原始流分组封装模块，用于为当前解析得到的负载数据包添加原始流分组固定头，将所述原始流分组固定头中的填充位标记为有填充；在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到原始流分组数据包；
存储模块，用于存储所述原始流分组数据包。
本实施例中，填充位对应的填充字段的字节数最大不超过7字节，最小为4字节，包括填充字节以及扩展字段，其中，扩展字段位于原始流分组固定头与填充字节之间。
本实施例的装置，可以用于执行图1至图8所示方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。
尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。
应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。
在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。
本申请实施例还提供一种电子设备，所述电子设备包含前述任一实施例所述的装置。
图10为本申请电子设备一个实施例的结构示意图，可以实现本申请图1-9所示实施例的流程，如图10所示，上述电子设备可以包括：壳体11、处理器12、存储器13、电路板14和电源电路15，其中，电路板14安置在壳体11围成的空间内部，处理器12和存储器13设置在电路板14上；电源电路15，用于为上述电子设备的各个电路或器件供电；存储器13用于存储可执行程序代码；处理器12通过读取存储器13中存储的可执行程序代码来运行与可执行程序代码对应的程序，用于执行前述任一实施例所述的数据传输方法。
处理器12对上述步骤的具体执行过程以及处理器12通过运行可执行程序代码来进一步执行的步骤，可以参见本申请图1-9所示实施例的描述，在此不再赘述。
应用本申请实施例，该电子设备的处理器通过读取存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，该程序在运行时执行本申请实施例所提供的数据传输方法，因此能够实现：降低网络资源开销以及组帧时延的目的。
本申请实施例提供了一种可执行程序代码，所述可执行程序代码用于被运行以执行本申请实施例所提供的所述数据传输方法，其中，所述数据传输方法，可以包括步骤：
将待传输的数据帧切分为一个或多个预定长度的负载数据包；
为每一负载数据包添加实时传输协议头，将所述实时传输协议头中的填充位标记为有填充；
在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到封装的实时传输协议数据包；传输所述封装的实时传输协议数据包。
应用本申请实施例，可执行程序代码在运行时执行本申请实施例所提供的数据传输方法，因此能够实现：降低网络资源开销以及组帧时延的目的。
本申请实施例提供了一种存储介质，所述存储介质用于存储可执行程序代码，所述可执行程序代码被运行以执行本申请实施例所提供的所述数据传输方法，其中，所述数据传输方法，可以包括步骤：
将待传输的数据帧切分为一个或多个预定长度的负载数据包；
为每一负载数据包添加实时传输协议头，将所述实时传输协议头中的填充位标记为有填充；
在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到封装的实时传输协议数据包；传输所述封装的实时传输协议数据包。
应用本申请实施例，存储介质存储有在运行时执行本申请实施例所提供的数据传输方法的应用程序，因此能够实现：降低网络资源开销以及组帧时延的目的。
上述电子设备以多种形式存在，包括但不限于：
(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如iPhone)、多媒体手机、功能性手机，以及低端手机等。
(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。
(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备 包括：音频、视频播放器(例如iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。
(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。
(5)其他具有数据交互功能的电子设备。
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
为了描述的方便，描述以上装置是以功能分为各种单元/模块分别描述。当然，在实施本申请时可以把各单元/模块的功能在同一个或多个软件和/或硬件中实现。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (22)

  1. 一种数据传输方法，其特征在于，包括：
    将待传输的数据帧切分为一个或多个预定长度的负载数据包；
    为每一负载数据包添加实时传输协议头，将所述实时传输协议头中的填充位标记为有填充；
    在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到封装的实时传输协议数据包；
    传输所述封装的实时传输协议数据包。
  2. 根据权利要求1所述的数据传输方法，其特征在于，所述填充位对应的填充字段包括：数据填充字段以及扩展字段，其中，扩展字段占用4字节，包括：保留字段、合成数据帧指示位字段以及填充大小字段。
  3. 根据权利要求2所述的数据传输方法，其特征在于，所述合成数据帧指示位字段中的数据类型位占用2bit，帧开始位以及帧结束位各占1bit，负载数据包类型位占用2bit。
  4. 根据权利要求3所述的数据传输方法，其特征在于，所述合成数据帧指示位字段中，还包括：各占用4bit的负载数据包序号位以及通道位。
  5. 根据权利要求1至4任一项所述的数据传输方法，其特征在于，所述得到封装的实时传输协议数据包包括：
    如果所述负载数据包为所述数据帧的第一个负载数据包且非最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为有效，帧结束位标记为无效；
    如果所述负载数据包为所述数据帧的第一个负载数据包且为最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为有效，帧结束位标记为有效；
    如果所述负载数据包为所述数据帧的最后一个负载数据包且非第一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束 位标记为有效；
    如果所述负载数据包为所述数据帧的非第一个负载数据包且非最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束位标记为无效；
    封装标记的所述负载数据包，得到封装的实时传输协议数据包。
  6. 根据权利要求5所述的数据传输方法，其特征在于，在所述封装标记的所述负载数据包之前，所述方法还包括：
    如果所述负载数据包为视频I帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为00，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
    如果所述负载数据包为视频P帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
    如果所述负载数据包为视频B帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为10，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
    如果所述负载数据包为音频，将所述填充位对应的填充字段中的数据类型位标记为01，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
    如果所述负载数据包为私有数据，将所述填充位对应的填充字段中的数据类型位标记为10，负载数据包类型位标记为11，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位。
  7. 根据权利要求1至4任一项所述的数据传输方法，其特征在于，所述方法还包括：
    接收封装的实时传输协议数据包；
    解析接收的封装的实时传输协议数据包的实时传输协议头；
    如果所述实时传输协议头中的填充位标记为有填充，读取填充位对应的填充字段中的各位标记，依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包。
  8. 根据权利要求7所述的数据传输方法，其特征在于，所述依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包包括：
    读取填充位对应的填充字段中的数据类型位标记，如果为01或10，读取填充位对应的填充字段中的帧开始位以及帧结束位，如果帧开始位标记为有效，帧结束位标记为有效，确定传输的数据帧中只包含当前解析的实时传输协议头后面的负载数据包；如果帧开始位标记为有效，帧结束位标记为无效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的第一个负载数据包；如果帧开始位标记为无效，帧结束位标记为有效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的最后一个负载数据包；如果帧开始位标记为无效，帧结束位标记为无效，读取填充位对应的填充字段中的负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置；
    如果读取的填充位对应的填充字段中的数据类型位标记为00，读取填充位对应的填充字段中的负载数据包类型位，确定当前解析的实时传输协议头后面的负载数据包为视频I帧、视频P帧或视频B帧，并读取填充位对应的填充字段中的帧开始位、帧结束位，或者，帧开始位、帧结束位以及负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置。
  9. 根据权利要求7所述的数据传输方法，其特征在于，所述方法还包括：
    为当前解析得到的负载数据包添加原始流分组固定头，将所述原始流分组固定头中的填充位标记为有填充；在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到原始流分组数据包；
    存储所述原始流分组数据包。
  10. 根据权利要求9所述的数据传输方法，其特征在于，所述填充位对应 的填充字段的字节数最大不超过7字节，最小为4字节，包括填充字节以及扩展字段，其中，扩展字段位于原始流分组固定头与填充字节之间。
  11. 一种数据传输装置，其特征在于，包括：切分模块、实时传输协议头标记模块、填充字段标记模块以及传输模块，其中，
    切分模块，用于将待传输的数据帧切分为一个或多个预定长度的负载数据包；
    实时传输协议头标记模块，用于为每一负载数据包添加实时传输协议头，将所述实时传输协议头中的填充位标记为有填充；
    填充字段标记模块，用于在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到封装的实时传输协议数据包；
    传输模块，用于传输所述封装的实时传输协议数据包。
  12. 根据权利要求11所述的数据传输装置，其特征在于，所述填充位对应的填充字段包括：数据填充字段以及扩展字段，其中，扩展字段占用4字节，包括：保留字段、合成数据帧指示位字段以及填充大小字段。
  13. 根据权利要求12所述的数据传输装置，其特征在于，所述合成数据帧指示位字段中的数据类型位占用2bit，帧开始位以及帧结束位各占1bit，负载数据包类型位占用2bit。
  14. 根据权利要求13所述的数据传输装置，其特征在于，所述合成数据帧指示位字段中，还包括：各占用4bit的负载数据包序号位以及通道位。
  15. 根据权利要求11至14任一项所述的数据传输装置，其特征在于，所述填充字段标记模块包括：填充字段标记单元以及封装单元，其中，
    填充字段标记单元，如果所述负载数据包为所述数据帧的第一个负载数据包且非最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为有效，帧结束位标记为无效；
    如果所述负载数据包为所述数据帧的第一个负载数据包且为最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为有效，帧结束 位标记为有效；
    如果所述负载数据包为所述数据帧的最后一个负载数据包且非第一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束位标记为有效；
    如果所述负载数据包为所述数据帧的非第一个负载数据包且非最后一个负载数据包，将所述填充位对应的填充字段中的帧开始位标记为无效，帧结束位标记为无效；
    封装单元，用于封装标记的所述负载数据包，得到封装的实时传输协议数据包。
  16. 根据权利要求15所述的数据传输装置，其特征在于，所述填充字段标记模块还包括：
    负载数据包类型位标记单元，如果所述负载数据包为视频I帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为00，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
    如果所述负载数据包为视频P帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
    如果所述负载数据包为视频B帧，将所述填充位对应的填充字段中的数据类型位标记为00，负载数据包类型位标记为10，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
    如果所述负载数据包为音频，将所述填充位对应的填充字段中的数据类型位标记为01，负载数据包类型位标记为01，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
    如果所述负载数据包为私有数据，将所述填充位对应的填充字段中的数据类型位标记为10，负载数据包类型位标记为11，依据所述负载数据包在所述数据帧中切分的序号标记负载数据包序号位；
    将标记的所述负载数据包输出至封装单元。
  17. 根据权利要求11至14任一项所述的数据传输装置，其特征在于，所述装置还包括：接收模块、解析模块以及负载数据包获取模块，其中，
    接收模块，用于接收封装的实时传输协议数据包；
    解析模块，用于解析接收的封装的实时传输协议数据包的实时传输协议头；
    负载数据包获取模块，如果所述实时传输协议头中的填充位标记为有填充，读取填充位对应的填充字段中的各位标记，依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包。
  18. 根据权利要求17所述的数据传输装置，其特征在于，所述依据读取的各位标记解析出封装的实时传输协议数据包中的负载数据包包括：
    读取填充位对应的填充字段中的数据类型位标记，如果为01或10，读取填充位对应的填充字段中的帧开始位以及帧结束位，如果帧开始位标记为有效，帧结束位标记为有效，确定传输的数据帧中只包含当前解析的实时传输协议头后面的负载数据包；如果帧开始位标记为有效，帧结束位标记为无效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的第一个负载数据包；如果帧开始位标记为无效，帧结束位标记为有效，确定当前解析的实时传输协议头后面的负载数据包为传输的数据帧中的最后一个负载数据包；如果帧开始位标记为无效，帧结束位标记为无效，读取填充位对应的填充字段中的负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置；
    如果读取的填充位对应的填充字段中的数据类型位标记为00，读取填充位对应的填充字段中的负载数据包类型位，确定当前解析的实时传输协议头后面的负载数据包为视频I帧、视频P帧或视频B帧，并读取填充位对应的填充字段中的帧开始位、帧结束位，或者，帧开始位、帧结束位以及负载数据包序号位，确定当前解析的实时传输协议头后面的负载数据包在传输的数据帧中的位置。
  19. 根据权利要求17所述的数据传输装置，其特征在于，所述装置还包括：原始流分组封装模块以及存储模块，其中，
    原始流分组封装模块，用于为当前解析得到的负载数据包添加原始流分组固定头，将所述原始流分组固定头中的填充位标记为有填充；在填充位对应的填充字段中，对所述负载数据包进行数据类型位、帧开始位、帧结束位以及负载数据包类型位标记，得到原始流分组数据包；
    存储模块，用于存储所述原始流分组数据包。
  20. 根据权利要求19所述的数据传输装置，其特征在于，所述填充位对应的填充字段的字节数最大不超过7字节，最小为4字节，包括填充字节以及扩展字段，其中，扩展字段位于原始流分组固定头与填充字节之间。
  21. 一种电子设备，其特征在于，所述电子设备包括：壳体、处理器、存储器、电路板和电源电路，其中，电路板安置在壳体围成的空间内部，处理器和存储器设置在电路板上；电源电路，用于为上述电子设备的各个电路或器件供电；存储器用于存储可执行程序代码；处理器通过读取存储器中存储的可执行程序代码来运行与可执行程序代码对应的程序，用于执行前述任一权利要求1-10所述的数据传输方法。
  22. 一种存储介质，其特征在于，所述存储介质用于存储可执行程序代码，所述可执行程序代码被运行以执行前述任一权利要求1-10所述的数据传输方法。
PCT/CN2017/098632 2016-09-23 2017-08-23 一种数据传输方法、装置及电子设备 WO2018054193A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/335,770 US10869106B2 (en) 2016-09-23 2017-08-23 Data transmission method and apparatus, and electronic device
EP17852262.9A EP3518486B1 (en) 2016-09-23 2017-08-23 Data transmission method and apparatus, and electronic device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610846489.3 2016-09-23
CN201610846489.3A CN107872422B (zh) 2016-09-23 2016-09-23 一种数据传输方法、装置及电子设备

Publications (1)

Publication Number Publication Date
WO2018054193A1 true WO2018054193A1 (zh) 2018-03-29

Family

ID=61689356

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/098632 WO2018054193A1 (zh) 2016-09-23 2017-08-23 一种数据传输方法、装置及电子设备

Country Status (4)

Country Link
US (1) US10869106B2 (zh)
EP (1) EP3518486B1 (zh)
CN (1) CN107872422B (zh)
WO (1) WO2018054193A1 (zh)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108989286B (zh) * 2018-06-08 2020-01-14 北京开广信息技术有限公司 通用数据流的封装方法、解封装方法及装置
CN109167750B (zh) * 2018-07-06 2021-06-18 北京金山安全软件有限公司 一种数据包传输方法、装置、电子设备及存储介质
CN108989605A (zh) * 2018-07-27 2018-12-11 湖南科技大学 一种图像采集与传输系统及方法
CN111343415A (zh) * 2018-12-18 2020-06-26 杭州海康威视数字技术股份有限公司 数据传输方法及装置
CN111372035A (zh) * 2018-12-25 2020-07-03 杭州海康威视数字技术股份有限公司 多媒体数据处理方法、装置、电子设备及可读存储介质
CN111488171B (zh) * 2019-01-29 2023-11-03 杭州海康威视数字技术股份有限公司 一种数据生成和解析方法、装置及电子设备
CN110808925A (zh) * 2019-11-04 2020-02-18 苏州思必驰信息科技有限公司 语音数据传输方法
CN110971387A (zh) * 2019-12-10 2020-04-07 上海邦邦机器人有限公司 一种数据传输处理方法、发送设备和接收设备
CN112087418B (zh) * 2020-07-23 2022-08-09 北京经纬恒润科技股份有限公司 计算报文数据填充位的方法及装置
CN112015163B (zh) * 2020-08-20 2021-11-26 广州汽车集团股份有限公司 一种快速识别can总线上诊断主体的方法及装置
CN112769939B (zh) * 2021-01-13 2023-03-21 北京机电工程总体设计部 一种用于实时通讯的大数据可靠传输方法
CN113726895B (zh) * 2021-08-31 2023-08-25 广州艾美网络科技有限公司 文件传输方法、装置及网络ktv系统
CN114500475B (zh) * 2021-12-31 2024-02-09 赛因芯微(北京)电子科技有限公司 一种基于实时传输协议的网络数据传输方法、装置及设备
CN114979092B (zh) * 2022-05-13 2024-04-02 深圳智慧林网络科技有限公司 一种基于rtp的数据传输方法、装置、设备和介质
CN116192341B (zh) * 2023-02-27 2024-04-26 东方空间技术(山东)有限公司 运载火箭遥测系统pcm/fm码流传输方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070002860A1 (en) * 2005-06-30 2007-01-04 Cooper Frederick J Method and system for a digital home network trace and debug tool
CN101141408A (zh) * 2007-10-22 2008-03-12 中兴通讯股份有限公司 一种网络多媒体数据包规整化的方法
CN101646074A (zh) * 2008-08-05 2010-02-10 中兴通讯股份有限公司 视频数据的实时传输方法
CN104320416A (zh) * 2014-11-13 2015-01-28 杭州海康威视数字技术股份有限公司 对实时传输协议数据进行打包的方法及装置
CN104394117A (zh) * 2014-03-10 2015-03-04 贵阳朗玛信息技术股份有限公司 Rtp包的传输方法及装置
CN105577649A (zh) * 2015-12-11 2016-05-11 中国航空工业集团公司西安航空计算技术研究所 一种音视频流传输方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015002500A1 (ko) * 2013-07-05 2015-01-08 엘지전자 주식회사 실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 방송 신호의 송수신 방법 및 장치

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070002860A1 (en) * 2005-06-30 2007-01-04 Cooper Frederick J Method and system for a digital home network trace and debug tool
CN101141408A (zh) * 2007-10-22 2008-03-12 中兴通讯股份有限公司 一种网络多媒体数据包规整化的方法
CN101646074A (zh) * 2008-08-05 2010-02-10 中兴通讯股份有限公司 视频数据的实时传输方法
CN104394117A (zh) * 2014-03-10 2015-03-04 贵阳朗玛信息技术股份有限公司 Rtp包的传输方法及装置
CN104320416A (zh) * 2014-11-13 2015-01-28 杭州海康威视数字技术股份有限公司 对实时传输协议数据进行打包的方法及装置
CN105577649A (zh) * 2015-12-11 2016-05-11 中国航空工业集团公司西安航空计算技术研究所 一种音视频流传输方法

Also Published As

Publication number Publication date
US20190246184A1 (en) 2019-08-08
EP3518486A1 (en) 2019-07-31
EP3518486B1 (en) 2020-10-21
EP3518486A4 (en) 2019-09-18
US10869106B2 (en) 2020-12-15
CN107872422B (zh) 2020-01-10
CN107872422A (zh) 2018-04-03

Similar Documents

Publication Publication Date Title
WO2018054193A1 (zh) 一种数据传输方法、装置及电子设备
US11665384B2 (en) Method and apparatus for transmitting media data in multimedia transport system
RU2764459C2 (ru) Способ и устройство для инкапсуляции активов медиатранспорта стандарта экспертной группы по движущимся изображениям в международной организации стандартизации базовых медиафайлов
US8472477B2 (en) SAF synchronization layer packet structure and server system therefor
US10142757B2 (en) Transmission device, transmission method, reception device, and reception method
JP2018148577A (ja) ダウンローディング及びストリーミングをサポートするパケットの送信装置
KR102379530B1 (ko) 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치
KR101959260B1 (ko) Ｍｍｔ 시스템을 위한 미디어 데이터 전송 장치 및 방법, 그리고 미디어 데이터 수신 장치 및 방법
US20140282799A1 (en) Method for transmitting media data via a heterogeneous ip network independently of a media codec
US20230260523A1 (en) Transmission device, transmission method, reception device and reception method
US20210058669A1 (en) Transmission method, reception apparatus and reception method for transmitting a plurality of types of audio data items
CN107787586B (zh) 用于在多媒体系统中发送和接收信号的方法和装置
EP2453652B1 (en) Transmission method, receiving method and device for scalable video coding files
US9936266B2 (en) Video encoding method and apparatus
CN110753259A (zh) 视频数据的处理方法、装置、电子设备及计算机可读介质
US10476994B2 (en) Devices and methods for transmitting/receiving packet in multimedia communication system
CN103959796A (zh) 数字视频码流的解码方法拼接方法和装置
CN110574378B (zh) 用于媒体内容资产改变的方法及装置
WO2017092435A1 (zh) 音视频实时传输方法及装置、传输流打包方法及复用器
KR20160149144A (ko) 미디어 데이터의 처리를 위한 mmt 장치 및 방법

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: 17852262

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017852262

Country of ref document: EP

Effective date: 20190423