CN1863314A - Method for real-time transmitting H.264 multimedia data - Google Patents
Method for real-time transmitting H.264 multimedia data Download PDFInfo
- Publication number
- CN1863314A CN1863314A CN200510113942.1A CN200510113942A CN1863314A CN 1863314 A CN1863314 A CN 1863314A CN 200510113942 A CN200510113942 A CN 200510113942A CN 1863314 A CN1863314 A CN 1863314A
- Authority
- CN
- China
- Prior art keywords
- transport protocol
- real time
- time transport
- header
- rtp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 46
- 230000006872 improvement Effects 0.000 claims description 62
- 238000005538 encapsulation Methods 0.000 claims description 52
- 238000004891 communication Methods 0.000 claims description 21
- 238000012546 transfer Methods 0.000 claims description 12
- 238000012545 processing Methods 0.000 claims description 11
- GOLXNESZZPUPJE-UHFFFAOYSA-N spiromesifen Chemical compound CC1=CC(C)=CC(C)=C1C(C(O1)=O)=C(OC(=O)CC(C)(C)C)C11CCCC1 GOLXNESZZPUPJE-UHFFFAOYSA-N 0.000 claims description 4
- 230000015572 biosynthetic process Effects 0.000 claims description 3
- 238000003786 synthesis reaction Methods 0.000 claims description 2
- 230000005540 biological transmission Effects 0.000 abstract description 16
- 230000007246 mechanism Effects 0.000 abstract description 8
- 230000008901 benefit Effects 0.000 description 9
- 230000008569 process Effects 0.000 description 9
- 238000007906 compression Methods 0.000 description 6
- 230000006835 compression Effects 0.000 description 6
- 238000012856 packing Methods 0.000 description 6
- 239000000047 product Substances 0.000 description 4
- 230000033228 biological regulation Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000010295 mobile communication Methods 0.000 description 3
- 238000009825 accumulation Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000009977 dual effect Effects 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000000750 progressive effect Effects 0.000 description 2
- 238000005070 sampling Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000005056 compaction Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000012467 final product Substances 0.000 description 1
- 238000009472 formulation Methods 0.000 description 1
- 230000012010 growth Effects 0.000 description 1
- 230000033001 locomotion Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000012797 qualification Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000005236 sound signal Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/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
- 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/8451—Structuring of content, e.g. decomposing content into time segments using Advanced Video Coding [AVC]
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
The invention relates to a multimedia video data transmitting method, disclosing a H.264 multimedia video data real-timely transmitting method, making RTP protocol able to carry H.264 multimedia video data in high efficiency, and adding quality of service (QoS) assurance mechanism on the premise of being compatible with the existing devices and transmission modes of using RTP protocol. And it gives a modified RTP (MRTP) protocol for carrying H.264 data, and integrates header bytes of all H.264 NALUs in the same RTP packet into header of the RTP packet, thus not only not influencing operation of the existing RTP protocol and devices but also able to directly express net load attributes of H.264 NALU in MRTP header; in addition, by modifying related fields in the existing RTP header, such as M and F fields, it gives a method for identifying the existing RTP and MRTP, making it possible that the existing network media devices supports both RTP and MRTP, and improving MRTP compatibility and application flexibility.
Description
Technical field
The present invention relates to multimedia data transmitting method, particularly multi-medium data method for real-time transmitting H.264.
Background technology
Along with the develop rapidly of computer internet (Internet) and mobile communications network, the application of stream media technology more and more widely, broadcasting, film are played to remote teaching and online news website etc. and have all used stream media technology from network.Current online transmission video, audio frequency mainly contain download (Download) and streaming transmits (Streaming) dual mode.It is to transmit the video/audio signal continuously that streaming transmits, when Streaming Media remainder when client computer is play continues on the backstage to download.Streaming transmits has progressive streaming to transmit (Progressive Streaming) and real-time streaming transmission (Realtime Streaming) dual mode.It is real-time transmission that real-time streaming transmits, and is particularly suitable for live event, and real-time streaming transmits and must coupling connect bandwidth, this means that picture quality can reduce variation because of network speed, to reduce the demand to transmission bandwidth.The notion of " in real time " is meant that the payment of data in an application must keep the precise time relation with the generation of data.
Especially along with 3-G (Generation Three mobile communication system) (3rd Generation, be called for short " 3G ") appearance and generally based on Internet protocol (Internet Protocol, abbreviation " IP ") network develops rapidly, and video communication just progressively becomes one of main business of communication.And both sides or multi-party video communication service, as video telephone, video conference, mobile multimedia terminal service etc., more transmission and the service quality to multimedia data stream proposes harsh requirement.It is better not only to require network to transmit real-time, and equivalence also require video data compaction coding efficient higher.
Demands status in view of media communication, (the InternationalTelecommunication Union Telecommunication Standardization Sector of ITU-T, be called for short " ITU-T ") after having formulated H.261, H.263, H.263+ waiting video compression standard, formally issued H.264 standard in 2003.This is ITU-T and (the InternationalStandardization Organization of International Standards Organization, abbreviation " ISO ") Motion Picture Experts Group (Moving PictureExperts Group is called for short " MPEG ") unites the adaptation new stage network media transmission of formulation and the efficient compressed encoding standard of communication requirement together.It also is the main contents of MPEG-4 standard the 10th part simultaneously.
Formulating H.264, the purpose of standard is to improve more effectively video coding efficient and its suitability to network.In fact owing to its superiority, H.264 the video compression coding standard has become the mainstream standard in the current multimedia communication soon gradually.A large amount of employing H.264 multimedia realtime communication product (as video conferencing, video telephone, 3G mobile communication terminal) and network flow-medium product is successively come out.Whether support H.264 to have become the key factor of decision product competitiveness in this market segment.Can predict that along with H.264 formal promulgation be extensive use of, the multimedia communication of IP based network and 3G, back 3G wireless network must enter a new stage of developing by leaps and bounds.
Multimedia communication not only requires media compression code efficiency height as previously mentioned, and the real-time that requires network to transmit.Media stream transmission at present all is to adopt real time transport protocol (Real-timeTransport Protocol is called for short " RTP ") and control protocol (Real-time Transport ControlProtocol is called for short " RTCP ") thereof basically.RTP is a transportation protocol going up multimedia data stream at Internet, by the Internet engineering duty group (Internet Engineering Task Force is called for short " IETF ") issue.RTP be defined in one to one or the transmission situation of one-to-many under work, its objective is provides temporal information and realizes that stream is synchronously.The typical case of RTP uses and is based upon User Datagram Protocol (UserDatagram Protocol, be called for short " UDP ") on, but also control protocol (TransportControl Protocol can transmitted, be called for short " TCP ") or asynchronous transfer mode (Asynchronous Transfer Mode is called for short " ATM ") wait on other agreements and work.
RTP itself only guarantees the transmission of real time data, can not provide reliable transfer mechanism for transfer data packets in order, and flow control or congested control are not provided yet, and it relies on RTCP that these services are provided.RTCP is in charge of delivery quality exchange of control information between the current application process.During the RTP session, each participant periodically transmits the RTCP bag, contains the quantity of data packets that has sent, the statistics of losing such as quantity of data packets in the bag, therefore, server can utilize these information dynamically to change transfer rate, even changes PT Payload Type.RTP and RTCP are used, and can make the transmission efficiency optimization with effective feedback and minimum expense, so be particularly suitable for transmitting online real time data.
And H.264 multi-medium data transmits on IP network, the unexceptional Real-time Transport Protocol that also is based on UDP and its upper strata.RTP itself structurally can both be suitable for for different media data type, but different upper-layer protocol or media compression coding standard in multimedia communication are (as H.261, H.263, MPEG-1/-2/-4, MP3 etc.), IETF can formulate the authority file at RTP payload (Payload) packaging method of this agreement, the method for specified in more detail RTP encapsulation packing, for this concrete agreement through optimization.Same, be H.264 Video of RFC 3984:RTPPayload Format for for H.264 also having corresponding ietf standard.Be the main standard that on IP network, transmits of video code flow H.264 before this standard mesh, use very extensive.In field of video communication, each mainstream vendor's product all is based on RFC 3984, also is only H.264/RTP load mode at present.
In fact, H.264 be H.264 to define a new aspect, be called network abstract layer (Network Abstract Layer is called for short " NAL ") with other the different key place of video compression coding agreement in the past.H.264 in order to increase its video coding layer (Video Coding Layer, be called for short " VCL ") with the separating and independence of the network transportation protocol layer of following mask body, bring bigger application flexibility, defined this new aspect of NAL, this layer, all do not have in H.263/H.263+/H.263++ such as H.261 in the early stage video compression coding agreement of ITU-T.Yet, how in NAL and Real-time Transport Protocol carrying collaborative work at H.264 higher, the better scheme of advantage design efficiency, make RTP better for load-carrying properties H.264, be very worth research and the problem that very big using value is arranged.
The method of RTP that the RFC3984 standard is proposed carrying NAL layer data H.264 is present only technical scheme, and this scheme is encapsulated in the NAL layer data in the RTP payload and carries on the basis of Real-time Transport Protocol (RFC 3550).The NAL layer is between VCL and RTP, and regulation will be divided into a series of NAL data cell (NAL Units is called for short " NALU ") to rule and the structure of video code flow according to definition.In RFC3984, defined the encapsulation format of RTP payload for NALU.Simply introduce the method for packing of NALU in the frame format of RTP and the prior art below successively.
The main purpose of RTP design is real-time multimedia meeting and continuous data storage, mutual distributed emulation, control and measurement application etc.RTP is carried on the udp protocol usually, to utilize its multiplexed and function verification.If bottom provides the multiple spot distribution, RTP supports multiaddress to transmit.The function that RTP provides comprises: load type is differentiated, sequence numbering, timestamp, and transmitting supervisory.
The form of RTP bag is as follows: RTP header most basic option takies 12 bytes (minimum), and the header of IP agreement and udp protocol takies 20 bytes and 8 bytes respectively, therefore RTP seals and is contained in the UDP bag and is encapsulated in the IP bag again, and it is the 12+8+20=40 byte that total header takies byte number.The detailed structure of the header of RTP bag as shown in Figure 1.
Shown in Fig. 1 from front to back the RTP header be followed successively by: the 1st byte (byte 0) is some fields about header structure itself, the 2nd byte (byte 1) is the definition payload type, the 3rd, 4 bytes (byte 2,3) be bag sequence number (Sequence Number), the 5-8 byte is timestamp (timestamp), the 9-12 byte is to contribute source identifier (Synchronous Source Identifier synchronously, be called for short " SSRCID "), be contribution source identifier (Contributing Source Identifiers at last, abbreviation " CSRCIDs ") tabulation, its number is uncertain.Notice, the byte 0 of the 1st byte in this paper describes for marking, the rest may be inferred afterwards.
Wherein preceding 12 bytes appear in all dissimilar RTP packets, and other data in the header just have such as contributing the source identifier sign to have only when blender inserts.Situation when therefore CSRC generally is used to exist medium to mix, such as in Multi-Party Conference, audio frequency needs to mix, and video also can provide the function of many pictures in this way.And Synchronization Source SSRC is exactly the sign of institute's carrying media stream in fact.
The concrete meaning and the full name of above-mentioned each field are described below respectively:
The V field is version (Version) information, account for 2 bits (bits), the version that adopts is 2 at present, therefore put V=2, and other values such as V=1 represent RTP version more early, V=0 represents the most original RTP predecessor, promptly adopt in voice IP (VOIP) communication system of using on the Mbone network in early days, be evolved into RTP afterwards, V=3 is then still undefined, is that the present invention is utilizable therefore;
The P field accounts for 1bit for filling sign (Padding), if P set represents that then the packet end comprises one or more byte of paddings (Padding), fills a part that does not belong to payload;
X field is expansion sign bit (Extension), account for 1bit, if X set, then the RTP head must expand with the head of a variable length at last (if the CSRC tabulation is arranged, the head expansion will be followed thereafter), mainly be to be preserved for the not enough situation of following information field of some applied environment, the length field that this header expansion comprises one 16 bit is counted the word what 32 bit long are arranged in the expansion, preceding 16 bits of head expansion are that a left side is open, so that distinguishing identifier symbol and parameter, the form of this 16 bit is by concrete aspect normalized definition, and the formal definition of this expansion has a detailed description in RFC3550 5.3.1 joint, no longer provides as space is limited herein;
The CC field is contribution source number (CSRC Count), accounts for 4bits, indicates the number of the rearmost CSRC identifier of header, and the recipient can determine the CSRC IDs list length of header back according to the CC field;
The M field is sign bit (Marker), account for 1bit, the explanation of this sign bit defines in specific aspect (Profile), it allows to identify the critical event in the data packet stream, an aspect can define additional sign bit or stipulate not identify bit, here so-called aspect just is meant concrete applied environment setting, is specifically reached an agreement on by communicating pair, is not subjected to the qualification of agreement;
The PT field is load type (Payload Type is called for short " PT "), and 7bits identifies the form of RTP load and determines his explanation in application program altogether; Flag bit and load type totally one byte are carried the aspect provisioning information, this byte may be redefined to adapt to different demands by concrete aspect, in concrete the application, can define so-called profile, be exactly one group of static state (being that communicating pair is appointed in advance) corresponding relation in fact, the value that the PT bit is different is mapped with different media formats.Can certainly carry out relation between dynamic negotiation definition PT value and the media formats by the signaling outside the RTP.In a RTP session (Session), PT can be changed in the RTP source.
Field then is exactly sequence number 16bits altogether, RTP packet of every transmission, and this sequence number value adds one, and the recipient can detect data-bag lost and recovery data packets order with it like this, and once the sequence number initial value in the communication can be given at random, do not influence communication.
Timestamp accounts for 32bits, and it has reflected the sampling time of first byte in the RTP packet, and the sampling time here must derive from the clock of a dull linear growth, and the recipient adjusts the media play time according to it or carries out synchronously.
Synchronisation source SSRC ID accounts for 32bits, and its occurrence can be selected at random, but will guarantee the uniqueness in the same RTP session, can source of media of unique identification, if a source has changed the transfer address, source, must select a new SSRC identifier.
CSRC tabulation in contribution source can be the 0-15 item as required, and every accounts for 32bits, and the length of this tabulation is that the number of CSRC ID is just in time marked by 4 bit of CC field.In fact, the CSRC identifier that is used to identify certain source of media is consistent with the SSRC identifier in its corresponding contribution source, only in role's difference of different recipients, and is changed to SSRC or CSRC.In multi-party communication, CSRC ID is inserted by blender.
Carrying under the situation of video H.264, RTP is packaged into RTP bag stream to NALU encapsulation H.264.In RFC 3984 files, mainly defined NALU, and provided the H.264 encapsulation packing form of layer NAL data in RTP based on this.The RTP encapsulation format of this NALU as shown in Figure 2.
Provide the encapsulating structure of a NALU in the payload of RTP among Fig. 2, first byte of front is the NALU header, be the data content of NALU afterwards, in the payload that is filled into the RTP bag that a plurality of NALU are end to end, in the end also have optional RTP to fill, this is the content of RTP packet format regulation, is in order to make the length of RTP bag meet certain particular requirement (such as reaching regular length), optionally generally all zero fillings of RTP padding data.
The NALU header i.e. the 1st byte, is also referred to as eight bit groups (Octet), and it has three fields, and meaning and full name are described below respectively:
The F Field Definition is for forbidding bit (forbidden_zero_bit), account for 1bit, be used to identify situations such as grammer mistake, if syntax clash arranged then be changed to 1, when having the bit mistake in Network Recognition this element, it can be made as 1,, be mainly used in and adapt to different types of network environment (environment that combines such as wire and wireless) so that the recipient loses this unit;
The NRI Field Definition is NAL reference identification (nal_ref_idc), account for 2bits, be used to indicate the significance level of NALU data, its value is that the content of 00 expression NALU is not used in the reference picture of rebuilding inter prediction, but not 00 current NALU of expression is band (slice) or sequence parameter set (the Sequence Parameter Set that belongs to reference frame, abbreviation " SPS "), picture parameter set (Picture ParameterSet, be called for short " PPS ") wait significant data, it is important more that this is worth the current NAL of big more expression;
The type field is defined as NALU type (Nal_unit_type), is total to 5bits, and the type of 32 kinds of NALU can be arranged, and the corresponding relation of its value and particular type provides in table 1 in detail.
The type field value and type mapping table in the table 1NALU header
| The Type value | The type of |
| 0 | Do not specify |
| 1 | The coding slice of |
| 2 | Coding slice data are divided A |
| 3 | Coding slice data are divided |
| 4 | Coding slice data are divided |
| 5 | Coding slice in the |
| 6 | SEI (supplemental enhancement information) |
| 7 | SPS (sequence parameter set) |
| 8 | PPS (picture parameter set) |
| 9 | The access unit delimiter |
| 10 | EOS |
| 11 | Code stream finishes |
| 12 | Padding data |
| 13-23 | Keep |
| 24-31 | Do not specify |
As seen, the information spinner that provides in the byte of the header of NALU will comprise validity, the importance rate of NALU, can determine RTP institute data carried by data importance according to these information.
In sum, the scheme of prior art can be summarized as follows: at first video bit stream is H.264 cut apart formation NALU stream according to certain rule at the NAL layer, in fact this step belongs to the category of H.264 realizing, such as can be a two field picture as a NALU, also can be a Slice as a NALU, the encapsulation packing strategy that basis is relevant with application is then packed the encapsulation of NALU stream and is formed the RTP data packet stream.In the RTP packet, it after header the NALU data field, if a plurality of NALU H.264 of RTP packet encapsulation, the end to end arrangement of these NALU so, each NALU occupies one section continuous bit, and first byte of each NALU is a NALU header byte, and last at the RTP packet, the padding data bit that may have as required, some washabilitys.Have any to it is noted that in transport process, the bottom Real-time Transport Protocol is not handled the specifying information of NALU.
In actual applications, there is following problem in such scheme: H.264 NALU header does not have can be embodied in the header of RTP bag in this scheme.And in the NALU header byte, contain a lot of important information in fact, the data that comprise such as the corresponding NALU of NRI indication be H.264 non-reference frame or reference frame or other important view data such as parameter set etc.
Because Real-time Transport Protocol itself does not provide any service quality (Quality of Service, be called for short " QoS ") mechanism, and do not provide information about carrying data importance priority etc., so RTP itself is without any at wrong fault-tolerant ability such as Network Packet Loss on IP and wireless network, or is called error elasticity (Error Resilience).
If can in the header of RTP packet, reflect H.264 some information of NALU, then can be by direct scanning RTP header packet information acquisition about the information of NALU attribute H.264.According to these information, the network equipment just might be done distinguishing processing for the RTP packet, thereby guarantees the priority of significant data in transport process.
In addition, this scheme also leaves some room for improvement on efficient, if encapsulated a plurality of H.264 NALU in the RTP packet, the type of general these NALU is all the same, and the header byte of these NALU is identical in fact so, if N NALU arranged in a RTP bag, this N NALU header byte can substitute with a byte in fact so, do not lose any information, but efficient has improved, because can reduce by N-1 redundancy bytes.
Cause the main cause of this situation to be, in the prior art scheme header of NALU is encapsulated in the middle of the payload fully, make Real-time Transport Protocol can't directly know attribute, rank, significance level of relevant payload etc., thereby can't realize QoS mechanism based on this.Secondly, such encapsulation format has also caused the NALU header to take the payload resource because each NALU all attach header, cause under many circumstances, because the header of the NALU of a plurality of same types all is the same among RTP, thereby has wasted RTP transmission bandwidth resource.
Summary of the invention
In view of this, main purpose of the present invention is to provide a kind of H.264 multi-medium data method for real-time transmitting, make Real-time Transport Protocol can efficiently carry H.264 multimedia video data, under the prerequisite of existing equipment that adopts Real-time Transport Protocol of compatibility and load mode, increase service quality and guarantee mechanism.
For achieving the above object, the invention provides a kind of H.264 multi-medium data method for real-time transmitting, described H.264 multi-medium data is divided into network abstraction layer unit stream at network abstract layer, and described network abstraction layer unit comprises header, and described network abstraction layer unit header comprises successively:
Forbid bit field, be used to indicate described network abstraction layer unit whether to make mistakes;
Network abstract layer reference identification field is used to indicate the importance of described network abstraction layer unit;
Type field is used to indicate the type of described network abstraction layer unit, comprises following steps:
The A transmit leg is encapsulated in the same improvement real time transport protocol bag by improving real time transport protocol encapsulation format at least one network abstraction layer unit that header is identical, and establishes in this improvement real time transport protocol header packet information and improve the real time transport protocol sign with difference real time transport protocol bag;
B recipient improves the real time transport protocol sign according to this and judges that this bag is to improve the real time transport protocol bag, and handles this improvement real time transport protocol bag according to improving the real time transport protocol encapsulation format, obtains the network abstraction layer unit of being carried;
Wherein, in described improvement real time transport protocol encapsulation format, with the identical header synthesis that network abstraction layer unit had that it carried now in the header of this improvement real time transport protocol bag, and the network abstraction layer unit of being carried removed in the payload that its header recharges this improvement real time transport protocol bag.
Wherein, in described improvement real time transport protocol encapsulation format, network abstract layer reference identification field in the described network abstraction layer unit header and type field are filled in the payload type field of described improvement real time transport protocol header packet information, and this payload type field is positioned at back 7 bits of the 2nd byte of described improvement real time transport protocol header packet information.
In this external described method, in described steps A, B, the version information field value that described improvement real time transport protocol is designated described improvement real time transport protocol header packet information is a binary value 11, and this version information field is positioned at preceding 2 bits of the 1st byte of described improvement real time transport protocol header packet information.
In this external described method, in described improvement real time transport protocol encapsulation format, the bit field of forbidding in the described network abstraction layer unit header is filled in the tag field of described improvement real time transport protocol header packet information, and this tag field is positioned at preceding 1 bit of the 2nd byte of described improvement real time transport protocol header packet information;
And in described step B, the recipient judges according to the tag field of described improvement real time transport protocol bag whether its network abstraction layer unit of carrying makes mistakes;
Wherein, described recipient comprises communication terminal and network intermediate equipment.
In this external described method, in described steps A, B, the tag field value that described improvement real time transport protocol is designated described improvement real time transport protocol header packet information is a binary value 1, and this tag field is positioned at preceding 1 bit of the 2nd byte of described improvement real time transport protocol header packet information.
In this external described method, in described improvement real time transport protocol encapsulation format, ignore the bit field of forbidding in the described network abstraction layer unit header;
In described steps A,, adopt real time transport protocol to seal dress for the described network abstraction layer unit of makeing mistakes of forbidding the bit field indication;
In described step B, handle this real time transport protocol bag by the real time transport protocol encapsulation format after judging this real time transport protocol bag.
In this external described method, described steps A comprises following substep:
Transmit leg at first judges to forbid whether bit field is effective in the header of at least one described network abstraction layer unit, in view of the above it is divided into proper network level of abstraction unit and the network abstraction layer unit of makeing mistakes;
By described improvement real time transport protocol encapsulation format described proper network level of abstraction unit package is become described improvement real time transport protocol bag then, and establish described improvement real time transport protocol sign;
By described real time transport protocol encapsulation format the described network abstraction layer unit of makeing mistakes is packaged into described real time transport protocol bag;
Described step B comprises following substep:
Whether the recipient at first contains described improvement real time transport protocol sign in the header according to the bag that receives, and it is divided into described improvement real time transport protocol bag and described real time transport protocol bag;
Handle described improvement real time transport protocol bag according to described improvement real time transport protocol encapsulation format then, seal the described real time transport protocol bag of dress format analysis processing according to described real time transport protocol.
In this external described method, in described improvement real time transport protocol encapsulation format, when all types of described network abstraction layer unit was less than 16 kinds, only low 4 bits with described type field characterized, and the higher bit of described type field is as the expansion reservation bit.
In this external described method, the multimedia transfer equipment is known the relevant information of the network abstraction layer unit that it carries according to described improvement real time transport protocol header, and implements the quality of service policy that described H.264 multi-medium data transmits in real time in view of the above.
By relatively finding, the main distinction of technical scheme of the present invention and prior art is, provide a kind of improved Real-time Transport Protocol (MRTP) and be used to carry the NALU data, be attached in its header by header byte all NALU in the same RTP bag, adopted a kind of combination to make neither influence have the running of Real-time Transport Protocol and equipment now, and the attribute of NALU payload can be embodied directly in the MRTP header, make MRTP improve greatly the packing bearing efficient of NALU on the one hand, making on the other hand provides the basis of QoS mechanism realization to the embodiment of payload NALU attribute by MRTP;
Pass through in addition relevant field in the existing RTP header such as the improvement of M, F field, provide the identification method of existing RTP of difference and MRTP, this makes the existing network media device support RTP and MRTP to carry out work simultaneously becomes possibility, has improved the compatibility of MRTP; And provide accordingly for the independent transfer approach of traditional RTP of the NALU that has syntax error (syntactical errors) or error code and the scheme of MRTP and RTP packet alternate treatment.
Difference on this technical scheme, brought comparatively significantly beneficial effect, promptly the header by the improved MRTP agreement of the present invention carries NALU header H.264, thereby under situation about need not decode for NALU, by promptly can determine the importance of MRTP packet carrying NALU for the quick scanning of MRTP header, thereby take appropriate measures, realize qos policy etc., further improve service quality;
Simultaneously,, reach and reduce redundant, as to improve transmission efficiency purpose, very good effect is arranged for IP network multimedia video communication raising video delivery quality and user experience by peeling off the header byte of similar H.264 NALU in the MRTP packet;
In addition, realized compatibility with prior art, provided the settling mode of alternate treatment MRTP and RTP packet for the difference of MRTP and RTP, and the independent transfer scheme of wrong NALU, these have all improved the robustness of this new method of MRTP.
Description of drawings
Fig. 1 is the header structural representation of RTP packet;
Fig. 2 is prior art encapsulation format schematic diagram to the NALU data in RTP bag payload;
Fig. 3 is the header structural representation of MRTP packet according to the embodiment of the present invention.
Embodiment
For making the purpose, technical solutions and advantages of the present invention clearer, the present invention is described in further detail below in conjunction with accompanying drawing.
The present invention aims to provide a kind of scheme can embody the H.264 header of NALU in the header of RTP.Its basic principle is the header that utilizes certain or some byte in the present RTP header or bit to embody NALU, and the purpose that these bytes or bit define in RTP for the concrete media protocol of being carried in conjunction with staying development space.Real-time Transport Protocol after the improvement also can not influence and support the interoperability between the equipment of former Real-time Transport Protocol, promptly some terminal adopts according to the improved Real-time Transport Protocol of the present invention in communication, other terminal adopts not improved Real-time Transport Protocol, fully can proper communication between these terminals.This point is to lean against in the MRTP header flag bit is set, and in order to distinguish traditional RTP packet, terminal also can be taked different treatment measures at different situations simultaneously, realizes that MRTP and RTP alternately transmit the scheme of handling.Here also comprised processing scheme, can solve its F flag bit with traditional RTP transfer syntax mistake NALU and be used to distinguish the problem that MRTP brings syntax error NALU.
MRTP is mainly concerned with redefining of payload type PT field in the RTP data packet head information and version information V field to the improvement of existing RTP.Two potential values of this scheme are: for the transmission of data H.264 provides certain QoS mechanism; Improve RTP and encapsulate the H.264 efficient of NALU.
This paper adopts improved RTP (Modified RTP, be called for short " MRTP ") form encapsulation NALU data, provide the description of embodiment below, but have any need to prove, given below all about will only mention in the description of MRTP its with existing RTP different place.The most basic difference of MRTP and RTP is that in the MRTP encapsulation process, the header that will have the NALU bag of identical header is comprehensively gone in the header of MRTP.
NALU header structure had been mentioned in the front, emphasized followingly here once more, and NALU information comprises successively:
Account for the F field of 1 bit, be used to indicate described NALU whether to make mistakes;
Account for the NRI field of 2 bits, the importance that is used to indicate described NALU;
Account for the type field of 5 bits, be used to indicate the type of described NALU.
The execution in step of receiving-transmitting sides is as described below in first execution mode of the present invention.
Transmit leg is encapsulated in the same MRTP bag by MRTP encapsulation format a plurality of NALU that header is identical, and establishes the MRTP sign with difference RTP bag in this MRTP header packet information.Here have any to merit attention: the reasonable precondition that the present invention requires is, only deposits same type H.264NALU in same MRTP packet, promptly has identical header.
According to practical engineering experience, in the ordinary course of things, because H.264 always there is identical this attribute of its corresponding NALU type of adjacent part in bit stream, this hypothesis is always satisfiable.Even can't satisfy in some cases, also can have several countermeasures can handle such situation: first kind can be with the NALU accumulation of same type, after satisfying certain number, be encapsulated among the MRTP, if the number of the NALU of another kind same type does not reach certain number, the method that adopts RTP to fill, though waste a point bandwidth, but this is insignificant, also have a kind of method to be if the different NALU of type is very many, then can adopt the RTP encapsulation, anyway can identify according to MRTP the recipient and discern, carry out corresponding processing.
The recipient judges that according to this MRTP sign this bag is the MRTP bag, and handles this MRTP bag according to the MRTP encapsulation format, obtains the NALU that is carried.Here the recipient can discern the MRTP bag according to the MRTP sign, mainly is to be different from the RTP bag, so makes and adopts the terminal of MRTP agreement not influence existing Real-time Transport Protocol proper communication, possesses downward compatibility.
Above-mentioned in described MRTP encapsulation format, the identical header that NALU had that it carried comprehensively in the header of this MRTP bag, and is removed the NALU that is carried in the payload that its header recharges this MRTP bag.Just MRTP is in the main distinction of RTP for this point, and the front was carried a lot, brings convenience the benefit of function expansion and conserve bandwidth like this.
So how with the NALU head comprehensively in the MRTP head, how about to know this bag at the MRTP leader be the MRTP bag? to specifically provide two sets of plan below to solve this several problems.
Second embodiment of the invention is on the basis of first execution mode, in the MRTP encapsulation format, NRI field in the NALU header and the type field are filled in the PT field of MRTP header packet information, and the front is narrated, and this PT field is positioned at back 7 bits of the 2nd byte of MRTP header packet information.Figure 3 illustrates the form of such MRTP head, wherein different with RTP places represent with bolded section that some place also can be explained in the back among the figure in addition.
Two other main points of this execution mode are: first, V field in the MRTP packet header is identified as MRTP, if the MRTP bag is 3 (binary values 11) with its V field value then, the front is mentioned, this V field is positioned at preceding 2 bits of the 1st byte of MRTP header packet information, i.e. version information field; Second, F field in the NALU header is filled in the M field of MRTP header packet information, this M field is positioned at preceding 1 bit of the 2nd byte of MRTP header packet information, then judge according to the M field of MRTP bag whether its NALU that carries makes mistakes the recipient, also just realized the bit function of forbidding of F field.
As seen in second execution mode of the present invention, making the current version V value 3 of MRTP, is the equal of the RTP of redaction, and existing RTP version V value is 2.By the difference of version, can tell the recipient of RTP packet, this Real-time Transport Protocol is to improve version MRTP, thereby in the processing of back, will be according to carrying out at the handling process of improving Real-time Transport Protocol.We also will describe a kind of replacement scheme the back, can not revise the purpose that V also can reach the difference between expression MRTP and the RTP.
In this embodiment, NALU header byte (8 bits) is replaced 1 bit of sign M field in the former RTP header and 7 bits of PT field totally 8 bits.Concrete replacement order is such as can being like this:
The F bit is replaced the M bit;
The highest 2 bits in PT7 bit of NRI2 bit replacement;
In fact, such alternative is to have it rational.PT7 bit can freely use originally, and the front is mentioned.The purposes of M field is stipulated as follows in RTP (RFC 3550): certain concrete aspect (Profile) can be stipulated not use the M bit, but it is incorporated into PT, and PT can have 8 bits at most like this, distinguishes 256 kinds of different types.Therefore, replace the M bit with the F bit and meet the RTP regulation fully, can not cause the problem of intercommunication between MRTP and the traditional RTP.
The encapsulation format of finding out MRTP of the present invention easily has tangible three advantages: the first, and overhead is few, when a plurality of NALU is especially arranged among RTP, obviously saves and transmits bit number; The second, need not just can differentiate the relative importance of these NALU to the H.264 NALU data decode in the RTP packet; The 3rd, need not just can discern owing to other bit drop-out the H.264 NALU data decode in the RTP packet and whether can cause this RTP bag to be correctly decoded.
For the ins and outs of second embodiment of the invention are described in further detail, the process prescription that provides a MRTP encapsulation below and go to encapsulate.After carrying out above-mentioned processing, a plurality of H.264 NALU types in same MRTP packet are identical, the header byte that is them is all identical, so when they are encapsulated in the MRTP packet, can peel off original header byte, if N NALU arranged like this, can reduce by N byte.When going to encapsulate, exactly NALU is extracted the original form that is reduced to from the MRTP packet, being about to this N NALU extracts from the MRTP packet at their place, then in minimum 7 bits of 7 bit-copy of the PT in the MRTP header in the byte H (8 bit), and the higher bit of H is set to 0 as the F bit.Then the H byte that generates is appended to the foremost of each NALU that extracts, so just reduced each NALU.Certainly if the F field in the MRTP packet header is 1, illustrate that the NALU in this MRTP bag makes mistakes, therefore directly abandon and get final product, saved the processing time.
The 3rd execution mode of the present invention provides second kind of solution on the basis of first execution mode, it is identical that this scheme has any with second execution mode, promptly also is the NRI in the NALU head and the type field are filled in 7 bits of PT field of MRTP head.There are 2 points in different places: no longer adopt V field identification MRTP, still value is V=2, but adopt M field identification MRTP, a problem of bringing like this is exactly that the F field does not have the place to fill, in this execution mode with F whether two class NALU of set treat respectively, still adopt original RTP to transmit for the NALU that makes mistakes of F set, for then adopting MRTP to transmit normally, but ignore this F bit.Detail is as described below.
In the 3rd execution mode, be 1 to identify MRTP bag with M field value, this M field is positioned at preceding 1 bit of the 2nd byte of described MRTP header packet information.And for the F bit, H.264 stipulating in the agreement: if syntax clash or mistake are arranged, then be 1.When having the bit mistake in Network Recognition this element, it can be made as 1, so that the recipient loses this unit.Be mainly used in and adapt to different types of network environment, the environment that combines such as wire and wireless.Concrete using priciple is: Tong Xin transmit leg and recipient do not carry out " writing " operation for this bit carrying out H.264 Code And Decode for video when generally speaking, and decoding end is carried out " reading " operation for this bit.If find F=1, then the recipient will abandon this NALU in decode procedure.According to present industry widespread usage situation, carry out " writing " operation for the F bit, mainly be on the gateway between two kinds of heterogeneous networks, to carry out, such as the situation of carrying out code conversion (H.264 H.263 MPEG-4 arrive and wait to H.264).
Therefore, the 3rd execution mode of the present invention is ignored the F bit, is not used in the original H.264 purpose of definition.Thereby making the M field originally be used to fill the F bit to keep, be used for following expansion and carry more information, is exactly to be used to identify the MRTP bag here.The benefit of doing like this is, need not make amendment for version information V=2, and MRTP still uses original version V value 2.This also is to have saved present only RTP version information resource.
Yet inevitably, the small probability situation that needs use the F bit may appear in actual applications, in the time of such as NALU grammer mistake, third embodiment of the invention is done following processing for this situation: in the MRTP encapsulation format, ignore the F field in the described NALU header; But at transmit leg,, still adopt RTP to seal dress, only normal NALU is adopted the MRTP packing for the F field NALU that effectively makes mistakes; Judge then that the recipient this bag still is that this bag is handled by corresponding encapsulation format in RTP bag back for MRTP.That is to say, when the F bit at some in particular cases, be used for the original H.264 purpose of definition, the situation of the H.264 NALU syntax error that exists promptly will be used to express possibility, if intermediate equipment such as gateway for video according to when H.264 agreement is carried out video coding, find that there is syntax error in certain NALU, will carry out encapsulation process separately for this NALU so.
The method flow of concluding above-mentioned MRTP and RTP alternate treatment is as follows:
Transmit leg judges at first whether the F field in the header of at least one NALU is effective, in view of the above it is divided into normal NALU and the NALU that makes mistakes;
By the MRTP encapsulation format normal NALU is packaged into the MRTP bag then, and establishes the MRTP sign; Be packaged into RTP bag by the RTP encapsulation format NALU that will make mistakes;
The recipient judges at first whether the header of the bag that receives establishes the MRTP sign, and it is divided into MRTP bag and RTP bag;
Handle the MRTP bag according to the MRTP encapsulation format then, seal dress format analysis processing RTP bag according to RTP.
As seen, in the 3rd execution mode of the present invention, gateway is for normal N ALU, according to previously described method, the H.264 NALU identical for type (determined by concrete application according to certain rule, mainly stipulate what similar NALU of encapsulation in each MRTP packet) carry out the MRTP encapsulation, there is syntax error in case find certain NALU, will adopt conventional RTP encapsulation for this NALU so.This time routine the RTP packet in perhaps just only contain a H.264 NALU.
The hypothesis of above method is in continuous H.264 NALU stream, occurs independent syntax error NALU once in a while, and take out wrong NALU with RTP separately and encapsulate this time.The recipient,, just carry out the encapsulation process of going of NALU H.264 by the rule of MRTP if receive the MRTP packet; If receive the packet of RTP, just carry out the encapsulation process of going of NALU H.264 by the rule of RTP.
Under opposite extreme situations more, H.264 code error appears in intermediate equipment, a plurality of H.264 NALU that syntax error is arranged continuously occur, occurs such as M continuous syntax error NALU, can still take this M NALU traditional RTP to encapsulate so.In addition, even the NALU that makes mistakes in the NALU stream is without cease successively, the NALU that these can be made mistakes so accumulation, after reaching the length that satisfies a RTP bag, pack with RTP again, like this can conserve bandwidth, do not influence the recipient simultaneously, because the recipient can learn which NALU loses according to sequence number.
Be not difficult to find out, transmit, can not influence the benefit that MRTP brings fully though this scheme has adopted with traditional RTP.Because normal N ALU can both encapsulate with MRTP, its benefit can be enjoyed, such as QoS mechanism that may adopt based on header etc.And for the NALU that makes mistakes, generally all abandon in recipient's processing, so they to be without access to the benefit that MRTP brings be rational.
What also need at last to illustrate a bit is, notice the type of the NALU that provides in the table 1 that preamble mentions and the value of corresponding the type field thereof, can find 16 kinds of existing type less thaies, 5 bits that is to say Type can be reduced to 4 fully, this does not influence existing H.264 transmission, therefore in the 4th execution mode kind of the present invention, in the MRTP encapsulation format, when all types of NALU is less than 16 kinds, only low 4 bits with the type field characterize, and the higher bit of Type is called the C field, as shown in Figure 3 as the expansion reservation bit.Use after this C bit waited until, proceed the function expansion.After bit C kept, the NALU type that provides in the table 1 will be done corresponding modify: totally 16 values, and value 0-12 is identical with table 1, and value 13-15 is for keeping.
Though present certainly NALU type H.264 has only 13 kinds, but H.264 back extended meeting development, may produce more NALU type,, need add that so still the C bit indicates as type with minimum 4 bits in 7 bits of PT if following NALU type is increased to more than 16 kinds.
Style of writing is last, it should be noted that largest benefit that MRTP of the present invention brings just, the multimedia transfer equipment can directly be known the relevant information of the NALU that it carried according to the MRTP header, and implements the H.264 real-time qos policy that transmits of multi-medium data in view of the above.This point can't realize that at existing RTP because for the RTP layer, NALU layer information is unconcerned, also just can't know the header of each NALU in the payload, thereby can't realize qos policy.
Though pass through with reference to some of the preferred embodiment of the invention, the present invention is illustrated and describes, but those of ordinary skill in the art should be understood that and can do various changes to it in the form and details, and without departing from the spirit and scope of the present invention.
Claims (9)
1. multi-medium data method for real-time transmitting H.264, described H.264 multi-medium data is divided into network abstraction layer unit stream at network abstract layer, and described network abstraction layer unit comprises header,
It is characterized in that, comprise following steps:
The A transmit leg is encapsulated in the same improvement real time transport protocol bag by improving real time transport protocol encapsulation format at least one network abstraction layer unit that header is identical, and establishes in this improvement real time transport protocol header packet information and improve the real time transport protocol sign with difference real time transport protocol bag;
B recipient improves the real time transport protocol sign according to this and judges that this bag is to improve the real time transport protocol bag, and handles this improvement real time transport protocol bag according to improving the real time transport protocol encapsulation format, obtains the network abstraction layer unit of being carried;
Wherein, in described improvement real time transport protocol encapsulation format, with the identical header synthesis that network abstraction layer unit had that it carried now in the header of this improvement real time transport protocol bag, and the network abstraction layer unit of being carried removed in the payload that its header recharges this improvement real time transport protocol bag.
2. H.264 multi-medium data method for real-time transmitting according to claim 1 is characterized in that, described network abstraction layer unit header comprises successively:
Forbid bit field, be used to indicate described network abstraction layer unit whether to make mistakes;
Network abstract layer reference identification field is used to indicate the importance of described network abstraction layer unit;
Type field is used to indicate the type of described network abstraction layer unit;
3. H.264 multi-medium data method for real-time transmitting according to claim 2, it is characterized in that, in described improvement real time transport protocol encapsulation format, network abstract layer reference identification field in the described network abstraction layer unit header and type field are filled in the payload type field of described improvement real time transport protocol header packet information, and this payload type field is positioned at back 7 bits of the 2nd byte of described improvement real time transport protocol header packet information.
4. H.264 multi-medium data method for real-time transmitting according to claim 3, it is characterized in that, in described steps A, B, described improvement real time transport protocol is designated the version information field of described improvement real time transport protocol header packet information, and this version information field is positioned at preceding 2 bits of the 1st byte of described improvement real time transport protocol header packet information.
5. H.264 multi-medium data method for real-time transmitting according to claim 4, it is characterized in that, in described improvement real time transport protocol encapsulation format, the bit field of forbidding in the described network abstraction layer unit header is filled in the tag field of described improvement real time transport protocol header packet information, and this tag field is positioned at preceding 1 bit of the 2nd byte of described improvement real time transport protocol header packet information;
And in described step B, the recipient judges according to the tag field of described improvement real time transport protocol bag whether its network abstraction layer unit of carrying makes mistakes.
Wherein, described recipient comprises communication terminal and network intermediate equipment.
6. H.264 multi-medium data method for real-time transmitting according to claim 3, it is characterized in that, in described steps A, B, described improvement real time transport protocol is designated the tag field of described improvement real time transport protocol header packet information, and this tag field is positioned at preceding 1 bit of the 2nd byte of described improvement real time transport protocol header packet information.
7. H.264 multi-medium data method for real-time transmitting according to claim 6 is characterized in that described steps A comprises following substep:
Transmit leg at first judges to forbid whether bit field is effective in the header of at least one described network abstraction layer unit, in view of the above it is divided into proper network level of abstraction unit and the network abstraction layer unit of makeing mistakes;
By described improvement real time transport protocol encapsulation format described proper network level of abstraction unit package is become described improvement real time transport protocol bag then, and establish described improvement real time transport protocol sign, in described improvement real time transport protocol encapsulation format, ignore the bit field of forbidding in the described network abstraction layer unit header;
By described real time transport protocol encapsulation format the described network abstraction layer unit of makeing mistakes is packaged into described real time transport protocol bag;
Described step B comprises following substep:
Whether the recipient at first contains described improvement real time transport protocol sign in the header according to the bag that receives, and it is divided into described improvement real time transport protocol bag and described real time transport protocol bag;
Handle described improvement real time transport protocol bag according to described improvement real time transport protocol encapsulation format then, seal the described real time transport protocol bag of dress format analysis processing according to described real time transport protocol.
8. according to any described H.264 multi-medium data method for real-time transmitting among the claim 3-7, it is characterized in that, in described improvement real time transport protocol encapsulation format, when all types of described network abstraction layer unit is less than 16 kinds, only low 4 bits with described type field characterize, and the higher bit of described type field is as the expansion reservation bit.
9. according to any described H.264 multi-medium data method for real-time transmitting among the claim 3-8, it is characterized in that, the multimedia transfer equipment is known the relevant information of the network abstraction layer unit that it carries according to described improvement real time transport protocol header, and implements the quality of service policy that described H.264 multi-medium data transmits in real time in view of the above.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2005101139421A CN100407726C (en) | 2005-10-17 | 2005-10-17 | Method for real-time transmitting H.264 multimedia data |
| PCT/CN2006/001845 WO2007045140A1 (en) | 2005-10-17 | 2006-07-25 | A real-time method for transporting multimedia data |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2005101139421A CN100407726C (en) | 2005-10-17 | 2005-10-17 | Method for real-time transmitting H.264 multimedia data |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1863314A true CN1863314A (en) | 2006-11-15 |
| CN100407726C CN100407726C (en) | 2008-07-30 |
Family
ID=37390618
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2005101139421A Active CN100407726C (en) | 2005-10-17 | 2005-10-17 | Method for real-time transmitting H.264 multimedia data |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN100407726C (en) |
| WO (1) | WO2007045140A1 (en) |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101873549A (en) * | 2010-05-26 | 2010-10-27 | 姜红志 | Point-to-point transmission method for mobile video information and transport protocol thereof |
| CN1972166B (en) * | 2006-11-30 | 2011-05-25 | 中兴通讯股份有限公司 | An audio stream transport method of mobile multimedia broadcast system |
| CN101355571B (en) * | 2007-07-26 | 2011-09-28 | 中国移动通信集团公司 | Method, apparatus and system for processing multimedia information |
| CN101488947B (en) * | 2008-01-16 | 2012-07-25 | 联想(北京)有限公司 | Data transmission method and device |
| CN103002353A (en) * | 2011-09-16 | 2013-03-27 | 杭州海康威视数字技术股份有限公司 | Method and device for packaging multimedia documents |
| CN103313045A (en) * | 2013-05-31 | 2013-09-18 | 哈尔滨工业大学 | H.264 video sub-packaging method of dispatching desk of wideband multimedia trunking system |
| CN104541516A (en) * | 2012-07-17 | 2015-04-22 | 三星电子株式会社 | Method and device for transferring transmission characteristic information of multimedia data |
| CN105323590A (en) * | 2014-06-23 | 2016-02-10 | 哈曼贝克自动系统股份有限公司 | Correcting errors in a digital media transport stream |
| CN105407351A (en) * | 2014-09-15 | 2016-03-16 | 杭州海康威视数字技术股份有限公司 | Method and apparatus for reconstructing encoding mode from real-time transport protocol packet |
| CN110719495A (en) * | 2018-07-13 | 2020-01-21 | 视联动力信息技术股份有限公司 | Video data processing method and system |
| CN112073822A (en) * | 2019-06-10 | 2020-12-11 | 成都鼎桥通信技术有限公司 | Media change method and system in broadband trunking communication |
| CN114449200A (en) * | 2020-10-30 | 2022-05-06 | 华为技术有限公司 | Audio and video call method and device and terminal equipment |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112839242B (en) * | 2020-12-31 | 2023-02-28 | 四川长虹网络科技有限责任公司 | Method for packaging audio/video media file |
| CN114979092B (en) * | 2022-05-13 | 2024-04-02 | 深圳智慧林网络科技有限公司 | RTP-based data transmission method, device, equipment and medium |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1148931C (en) * | 2002-09-29 | 2004-05-05 | 清华大学 | Method for implementing stream medium transmission based on real time transmission protocol and transmission control protocol |
| US7483532B2 (en) * | 2003-07-03 | 2009-01-27 | Microsoft Corporation | RTP payload format |
| US7436328B2 (en) * | 2003-07-09 | 2008-10-14 | Texas Instruments Incorporated | Video coding with start code emulation prevention |
-
2005
- 2005-10-17 CN CN2005101139421A patent/CN100407726C/en active Active
-
2006
- 2006-07-25 WO PCT/CN2006/001845 patent/WO2007045140A1/en active Application Filing
Cited By (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1972166B (en) * | 2006-11-30 | 2011-05-25 | 中兴通讯股份有限公司 | An audio stream transport method of mobile multimedia broadcast system |
| CN101355571B (en) * | 2007-07-26 | 2011-09-28 | 中国移动通信集团公司 | Method, apparatus and system for processing multimedia information |
| CN101488947B (en) * | 2008-01-16 | 2012-07-25 | 联想(北京)有限公司 | Data transmission method and device |
| CN101873549B (en) * | 2010-05-26 | 2013-08-21 | 姜红志 | Point-to-point transmission method for mobile video information adopting real-time flow transport protocol |
| CN101873549A (en) * | 2010-05-26 | 2010-10-27 | 姜红志 | Point-to-point transmission method for mobile video information and transport protocol thereof |
| CN103002353B (en) * | 2011-09-16 | 2015-09-02 | 杭州海康威视数字技术股份有限公司 | The method that multimedia file is encapsulated and device |
| CN103002353A (en) * | 2011-09-16 | 2013-03-27 | 杭州海康威视数字技术股份有限公司 | Method and device for packaging multimedia documents |
| US10728082B2 (en) | 2012-07-17 | 2020-07-28 | Samsung Electronics Co., Ltd. | Apparatus and method for delivering transport characteristics of multimedia data |
| CN104541516A (en) * | 2012-07-17 | 2015-04-22 | 三星电子株式会社 | Method and device for transferring transmission characteristic information of multimedia data |
| CN104541516B (en) * | 2012-07-17 | 2018-06-29 | 三星电子株式会社 | For the method and apparatus of the transmission characteristic information of transferring multimedia data |
| US10135666B2 (en) | 2012-07-17 | 2018-11-20 | Samsung Electronics Co., Ltd. | Apparatus and method for delivering transport characteristics of multimedia data |
| US11528315B2 (en) | 2012-07-17 | 2022-12-13 | Samsung Electronics Co., Ltd. | Apparatus and method for delivering transport characteristics of multimedia data |
| CN103313045A (en) * | 2013-05-31 | 2013-09-18 | 哈尔滨工业大学 | H.264 video sub-packaging method of dispatching desk of wideband multimedia trunking system |
| CN105323590A (en) * | 2014-06-23 | 2016-02-10 | 哈曼贝克自动系统股份有限公司 | Correcting errors in a digital media transport stream |
| CN105407351A (en) * | 2014-09-15 | 2016-03-16 | 杭州海康威视数字技术股份有限公司 | Method and apparatus for reconstructing encoding mode from real-time transport protocol packet |
| CN105407351B (en) * | 2014-09-15 | 2019-03-12 | 杭州海康威视数字技术股份有限公司 | A kind of method and apparatus for rebuilding coding mode from Realtime Transport Protocol data packet |
| CN110719495A (en) * | 2018-07-13 | 2020-01-21 | 视联动力信息技术股份有限公司 | Video data processing method and system |
| CN112073822A (en) * | 2019-06-10 | 2020-12-11 | 成都鼎桥通信技术有限公司 | Media change method and system in broadband trunking communication |
| CN114449200A (en) * | 2020-10-30 | 2022-05-06 | 华为技术有限公司 | Audio and video call method and device and terminal equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2007045140A1 (en) | 2007-04-26 |
| CN100407726C (en) | 2008-07-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1863314A (en) | Method for real-time transmitting H.264 multimedia data | |
| CN1863313A (en) | Method for monitoring service quality of H.264 multimedia communication | |
| CN1859580A (en) | Multimedia data network realtime transfer method for supporting error elasticity | |
| CN100466725C (en) | Multimedia communication method and terminal thereof | |
| Wenger et al. | Transport and signaling of SVC in IP networks | |
| KR101972951B1 (en) | Method of delivering media data based on packet with header minimizing delivery overhead | |
| CN108141455B (en) | Deadline signaling for streaming of media data | |
| CN110447234B (en) | Method, apparatus and storage medium for processing media data and generating bit stream | |
| EP4152730B1 (en) | Method for receiving media contents in a multimedia system | |
| Wenger et al. | RTP payload format for scalable video coding | |
| Wang et al. | RTP payload format for H. 264 video | |
| EP2880836B1 (en) | Replacing lost media data for network streaming | |
| JP4711681B2 (en) | Packetization of layered media bitstream | |
| JP6353120B2 (en) | Method and apparatus for transmitting multimedia data packets | |
| US20060291475A1 (en) | Selective forward error correction | |
| CN102860021A (en) | Interface apparatus and method for transmitting and receiving media data | |
| CN105122767A (en) | Methods for delivery of flows of objects over broadcast/multicast enabled networks | |
| CN104270594B (en) | The method and apparatus that data packet sends and receives | |
| US20150249835A1 (en) | Method for adaptively transmitting fec parity data using cross-layer optimization | |
| CN101646074B (en) | Real-time transmission method for video data | |
| CN1968211A (en) | Message header compression method, compressor and transmission system | |
| US9936266B2 (en) | Video encoding method and apparatus | |
| Westerlund | How to Write an RTP Payload Format | |
| CN106303537B (en) | A kind of more code stream transmission methods of openh264 | |
| CN1902884A (en) | Optimized transmission of text sample format descriptions for streaming timed text |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| ASS | Succession or assignment of patent right |
Owner name: HUAWEI SOFTWARE TECHNOLOGIES LTD. Free format text: FORMER OWNER: HUAWEI TECHNOLOGY CO., LTD. Effective date: 20090327 |
|
| C41 | Transfer of patent application or patent right or utility model | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20090327 Address after: No. 94 Ande gate, Yuhuatai District, Jiangsu, Nanjing Patentee after: HUAWEI SOFTWARE TECHNOLOGIES Co.,Ltd. Address before: Bantian HUAWEI headquarters office building, Longgang District, Shenzhen, Guangdong Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd. |
|
| TR01 | Transfer of patent right |
Effective date of registration: 20200319 Address after: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee after: HUAWEI TECHNOLOGIES Co.,Ltd. Address before: 210012 Ande Gate No. 94, Yuhuatai District, Jiangsu, Nanjing Patentee before: HUAWEI SOFTWARE TECHNOLOGIES Co.,Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20220223 Address after: 550025 Huawei cloud data center, jiaoxinggong Road, Qianzhong Avenue, Gui'an New District, Guiyang City, Guizhou Province Patentee after: Huawei Cloud Computing Technologies Co.,Ltd. Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd. |
|
| TR01 | Transfer of patent right |