US20100020865A1 - Data stream comprising RTP packets, and method and device for encoding/decoding such data stream - Google Patents

Data stream comprising RTP packets, and method and device for encoding/decoding such data stream Download PDF

Info

Publication number
US20100020865A1
US20100020865A1 US12/460,683 US46068309A US2010020865A1 US 20100020865 A1 US20100020865 A1 US 20100020865A1 US 46068309 A US46068309 A US 46068309A US 2010020865 A1 US2010020865 A1 US 2010020865A1
Authority
US
United States
Prior art keywords
layer
rtp packet
packet
data
application
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.)
Abandoned
Application number
US12/460,683
Other languages
English (en)
Inventor
Zhi Jin Xia
Zhi Bo Chen
Yu Wen Wu
Original Assignee
Thomson Licensing
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 Thomson Licensing filed Critical Thomson Licensing
Assigned to THOMSON LICENSING reassignment THOMSON LICENSING ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CHEN, ZHI BO, XIA, ZHI JIN, WU, YU WEN
Publication of US20100020865A1 publication Critical patent/US20100020865A1/en
Abandoned legal-status Critical Current

Links

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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • 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
    • 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
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/89—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving methods or arrangements for detection of transmission errors at the decoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440227—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • 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/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server

Definitions

  • This invention relates to packetized real-time protocol (RTP) data streams that comprise application data of a multi-layer application.
  • RTP real-time protocol
  • the invention relates to RTP-based scalable video transmission.
  • Scalable Video Coding (SVC) extension of H.264/AVC standard employs three types of scalability: temporal, spatial, and quality.
  • the temporal scalability is well supported in H.264/AVC, and the base layer of SVC is deliberately designed to comply with H.264/AVC.
  • RTP/IP Real-time video transmission over internet and mobile networks
  • IETF has proposed an RTP payload format for SVC video. Further improvements can however be made to facilitate the decoding and rendering of RTP-based SVC bitstreams, whereby the transmission scheme can be kept compliant with general standard decoders.
  • Decoders may need some initial information, e.g. the number of total spatial and quality scalability layers in the case of scalable video. This initial information may help the decoder e.g. to initialize the memory allocation and related parameter configuration. Other information like layer dependency or frame type may also help decoders to be more efficient and robust.
  • transmission channels are usually error-prone.
  • some decoders may perform an error concealment process.
  • decoders often rely on the format of the transport stream, such as RTP.
  • RTP transport stream
  • a standard RTP header contains timing information and the RTP packet number, which can be used to ensure that packets are decoded in the correct order.
  • a further protocol is necessary for detecting if a packet is lost. While for common internet applications TCP is used, TCP is too slow for real-time applications. Therefore, in real-time capable systems, an application decoder must handle the data loss situation and must find out alone which data are missing. This may disturb the application decoder, and in some cases it may even require its re-initialization.
  • the application decoder has different options for reacting on data loss, depending on the type of lost data packet and the application layer concerned. However, it is usually unknown to which application layer the missing packet belongs. A conventional multi-layer application decoder needs some processing time for recovering such situation. The quicker the type of lost data is known, the better a decoder can react.
  • One problem to be solved by the invention is to provide to a decoder earlier and more detailed information about the type of lost data in the case of transport packet loss, particularly in terms of the concerned application.
  • the present invention provides a special syntax within a packet-based framework which is based on identifying and indicating the relationship between RTP packets and the application layer/frame they carry, before the packets are fed to the multi-layer application decoder. This helps the decoder to employ proper error concealment techniques in time, and prevents unnecessary processing in the decoder.
  • the present invention provides a data stream format that solves the above-mentioned problems, a corresponding encoding method and device and decoding method and device.
  • a data stream comprises RTP packets containing application data of a multi-layer application, wherein at least one RTP packet contains first application layer information relating to the contents of the next RTP packet, and second application layer information relating to the contents of the previous RTP packet (in transmission order).
  • a method for encoding multi-layer application data using RTP packets comprises steps of
  • first, second and third portion of the multi-layer application data into a first, second and third RTP packet respectively, wherein the first, second and third portion of application data refers to a first, second and third layer of the application, adding in the second RTP packet at least first data defining the first layer of the application, to which the first packet refers, and second data defining the third layer of the application, to which the third packet refers, and transmitting the first, second and third RTP packet (in this transmission order).
  • a respective device for encoding multi-layer application data using RTP packets comprises insertion means for packing a first, second and third portion of the multi-layer application data into a first, second and third RTP packet respectively, wherein the first, second and third portion of application data refers to a first, second and third layer of the application, insertion means for adding in the second RTP packet at least first data defining the first layer of the application, to which the first packet refers, and second data defining the third layer of the application, to which the third packet refers, and transmitting means for transmitting the first, second and third RTP packet (in this transmission order).
  • the insertion means for packing a first, second and third portion of the multi-layer application data into a first, second and third RTP packet may process one, two or all three RTP packets sequentially or simultaneously.
  • the insertion means for adding data in the second RTP packet may process and insert the first data and the second data sequentially or simultaneously into the second packet.
  • a method for decoding (or in a way preparing the decoding) of RTP packets that comprise multi-layer application data comprises steps of
  • a respective device for (preparing the) decoding of RTP packets that comprise multi-layer application data comprises receiving means for receiving at least a first and a subsequent second RTP packet,
  • first extracting means for extracting from the body of the first RTP packet a first portion of the multi-layer application data and from padding bytes of the first RTP packet first neighbor information
  • second extracting means for extracting from the body of the second RTP packet a second portion of the multi-layer application data and from padding bytes of the second RTP packet second neighbor information
  • determining means for determining the type of multi-layer application data in the first RTP packet and in the second RTP packet
  • first comparing means for comparing the determined type of multi-layer application data in the second RTP packet with the first neighbor information extracted from the first RTP packet, or for comparing the determined type of multi-layer application data in the first RTP packet with the second neighbor information extracted from the second RTP packet, or both
  • second comparing means for comparing the first neighbor information extracted from the first RTP packet with the second neighbor information extracted from the second RTP packet, and providing means for providing the results of the first and second extracting means, and the first and second comparing means towards a decoder for said multi-layer application.
  • the multi-layer application data may be hierarchical data, with a base layer and one or more enhancement layers.
  • FIG. 1 the structure of a data stream according to the invention
  • FIG. 2 the format of RTP packets with padding bytes
  • FIG. 3 a block diagram of the encoding
  • FIG. 4 a block diagram of the decoding preparation
  • FIG. 5 the format of RTCP packets according to one aspect of the invention.
  • FIG. 1 shows the structure of a packetized data stream.
  • Successive packets p 1 ,p 2 ,p 3 in the data stream comprise application data of a multi-layer application: a first packet p 1 comprises application data of a first application layer VCL p , and subsequent second and third packets p 2 ,p 3 comprise application data of a second application layer VCL c and a third application layer VCL n respectively.
  • the packets are transmitted/received in immediate sequence. If e.g. the real-time protocol (RTP) is used as transport protocol, the packets have RTP packet numbers. Therefore, the receiver can bring the packets in their correct sequence order, but if e.g.
  • RTP real-time protocol
  • the decoder would not know to which application layer the missing data belong.
  • a scheme of adding more information to the overhead of transport packets is proposed, for improving the efficiency of decoding and error concealment.
  • This enables decoders to react in a more flexible manner.
  • the decoder can find out that a missing packet belongs to an enhancement layer of the multi-layer application, and consequently it can continue decoding the base layer.
  • the user may experience a temporal loss of quality, while conventionally the application would be interrupted. Instead, the application continues to run in a basic mode, e.g. a lower resolution.
  • the SVC decoder is sensitive to transmission errors.
  • the packet loss could be lethal to the decoder if no effective error concealment techniques are used.
  • a further aspect of the problem is that a solution is needed for existing systems, such as RTP, without requiring a change of the packet format.
  • some overhead information is inserted into the padding bytes of the RTP packets, in order to help the receiver getting the identity information of the lost packets before the data is fed to the SVC decoder. Consequently, the decoder can determine earlier than with conventional methods how to proceed with different solutions.
  • one possible reaction is to abandon the whole slice to which the lost packet is related, and instead use the co-located slice of a previous picture, e.g. copy it to the current picture buffer.
  • the scheme can be kept compliant with general standard SVC decoders, which disregard the padding bytes, and therefore the identity information, at all.
  • the proposed method can support the error concealment in multi-layer decoders. In principle, basic SVC information of the next and the previous RTP packet after and before a current RTP packet is saved in a current RTP packet. With this method, the SVC decoder can perform the error concealment processing earlier and easier.
  • FIG. 2 a shows an overview over the structure of an RTP packet according to the invention.
  • FIGS. 2 b ) and c ) show more details of the same packet.
  • Each line in FIG. 2 is one word of the packet having 32 bits.
  • the 1 st -5 th words contain general header information, as specified below.
  • NAL network abstraction layer
  • SPS sequence parameter set
  • PPS picture parameter set
  • M is a one bit flag indicating whether an RTP packet is special, e.g. the last RTP packet of the current slice.
  • RTP packet headers Other conventional fields in RTP packet headers are payload type, time stamp, synchronization source ID (SSRC) and contributing sources (CSRC) fields.
  • the payload contains the actual video data. While exemplarily two payload words are shown, the packets carry usually more payload. After the payload, the padding bytes as indicated by the P flag follow.
  • additional application-related information about the former and the next RTP packet is stored the padding bytes.
  • SVC defines the structure shown in Tab.1, and corresponding structure-related parameters.
  • Tab.1 The structure shown in Tab.1 is an example. There are in total seven layers: A-F.
  • the base layer is A,D,E. All the quality layers B,C,F have the same spatial resolution as their respective base layer.
  • the spatial layers D,E have different spatial resolution than their base layers.
  • quality layer is generated by quality scalability, which is one kind of scalability in SVC.
  • SVC demands that the quality layer has the same spatial resolution as its base layer.
  • the encoding type of quality scalability layer is different from the spatial scalability layer. So the decoding approach and the method to handle a NAL unit loss for quality layer data are different than those for spatial scalability data.
  • quality_id is the syntax element to indicate the ID of each quality layer in SVC bit streams.
  • the following information is contained in the padding bytes (indices n and f refer to the next or former packet respectively):
  • POCn 10 bit unsigned integer, indicates the POC number of the next NAL carried by the following RTP packet.
  • PIC_idxn 10 bits unsigned integer, indicates the IDR number of the next NAL carried by the following RTP packet.
  • Qf One bit flag.
  • Padding length This is the number of padding bytes, including itself. The padding bytes are not necessarily aligned on 32-bit border.
  • the decoder can easily know whether the NAL in the next/former RTP package belongs to a quality layer.
  • the flag Dx the spatial/CGS layer can be obtained easily.
  • the frame, to which the lost NAL belongs, can be determined according to POCn, and a simple and fast error concealment algorithm can be utilized in the SVC decoder.
  • FIG. 3 shows a block diagram for encoding, according to one aspect of the invention.
  • the encoding method comprises steps of packing or inserting 305 at least first, second and third consecutive portions of multi-layer application data into respective first, second and third RTP packets p 1 ,p 2 ,p 3 .
  • the different portions of application data refer to a first, second and third layer VCL f , VCL c , VCL n of the application.
  • the layers may be different, or any two or all three packets may refer to the same layer.
  • next step 320 at least first data Vf defining the first layer of the application (to which the former, first packet refers) and second data Vn defining the third layer of the application (to which the following, third packet refers) are added in the second RTP packet. Particularly, this information is added in padding bytes, as described above.
  • first, second and third RTP packets are transmitted 325 (in this order).
  • FIG. 3 can also be understood as showing the general structure of an encoder according to one aspect of the invention.
  • FIG. 4 shows a block diagram of the principle of the decoding preparation, to be performed before the actual application layer decoding. Actual implementations may be more sophisticated or e.g. integrated into a decoder.
  • the method is for preparing the decoding of RTP packets that comprise multi-layer application data, and comprises steps of receiving 401 at least a first and a subsequent second RTP packet, extracting 410 from the body of the first RTP packet a first portion of the multi-layer application data 415 and from padding bytes of the first RTP packet first neighbor information NB n , and in the same manner extracting 420 from the body of the second RTP packet a second portion of the multi-layer application data 425 and from padding bytes of the second RTP packet second neighbor information NB f .
  • the neighbor information comprises at least one of the Vn, Qn, Dn, POCn and PIC_idxn as far as the next packet is concerned, and at least one of Vf, Qf, Df, POCf and PIC_idxf as far as the previous packet is concerned.
  • the type of multi-layer application data in the first RTP packet typ n and in the second RTP packet typ n+1 is determined 430 , 440 .
  • the next step is comparing 450 the determined type typ n+1 of multi-layer application data in the second RTP packet with the first neighbor information NB n extracted from the first RTP packet, and/or comparing 460 the determined type typ n of multi-layer application data in the first RTP packet with the second neighbor information NB f extracted from the second RTP packet. If both comparisons are performed, they can bring three different results, as described below.
  • the first neighbor information NB n extracted from the first RTP packet and the second neighbor information NB f extracted from the second RTP packet are compared 470 . If both are equal and a packet is missing, it can be concluded that only one packet is missing. If both are different and a packet is missing, it can be concluded that more than one packet is missing.
  • One comparison result signal 455 indicates whether the type of a current packet is as indicated in the following packet.
  • One comparison result signal 465 indicates whether the packet type of a current packet is as indicated in the previous packet. These two 455 , 465 signals are regarded as first order comparison results, since they indicate whether data is missing.
  • One comparison result signal 475 indicates whether the packet type indicated as “next” in a previous packet and the packet type indicated as “previous” in a current packet are equal. This is a second order comparison result, since it is only relevant in the case that data is missing.
  • all these comparison result signals together with the expected next and previous packet types typ n , typ n+1 are delivered to the multi-layer application decoder.
  • the decoder can utilize the information as described below.
  • the “next” information in the 1st packet is equal to the packet type of the 2nd packet
  • the “previous” information in the 2nd packet is equal to the packet type of the 1st packet.
  • the first order comparison result signals 455 and 465 indicate that everything is ok and no packet is lost.
  • the “next” information in the 1st packet is different from the actual packet type of the 2nd packet (or the “previous” information in a 2 nd packet is different from the actual packet type of a 1 st packet), and further the “next” information in the 1st packet is equal to the “previous” information in the 2nd packet.
  • at least one of the first order signals 455 , 465 indicate that data is missing
  • the second order signal 475 indicates that both packets indicate the same type of missing data. In this case, it can be concluded that only one packet between the 1 st and the 2 nd packet is missing, and its type is known from the “next” and “previous” information.
  • the “next” information in the 1st packet is different from the actual packet type of the 2nd packet (or the “previous” information in a 2 nd packet is different from the actual packet type of a 1 st packet), and further the “previous” information in the 2 nd packet is different from the “next” information in the 1 st packet.
  • at least one of the first order signals 455 , 465 indicate that data is missing
  • the second order signal 475 indicates that both packets indicate different types of missing data. In this case, it can be concluded that at least two packets between the 1 st and the 2 nd packet are missing.
  • the multi-layer application decoder can react according to the current situation very fast.
  • RTCP packets can be used for this purpose.
  • FIG. 5 shows how to effectively utilize RTCP packets to transmit additional information to the decoder.
  • structural information can be transmitted that allows faster decoder initialization.
  • the number of (spatial and/or quality) layers is sent to the receiver within an application-defined RTCP packet. It is intended to facilitate the initialization of the decoder, and for the sake of random accessing, the information can be sent out periodically, e.g. as frequently as the IDR frame or SPS.
  • FIG. 5 shows a format of such RTCP packet, in which several fields are explained below.
  • “Length” gives the length of this RTCP packet in 32-bit words minus one, including the header. Default is 2.
  • “Name” is interpreted as a sequence of four ASCII characters, with uppercase and lowercase characters treated distinctly.
  • the “Name” can be used to indicate the SVC related RTP-based application.
  • the receiver may quickly get the holistic information of the received SVC bit-stream. Two kinds of methods are possible to insert the information for SVC decoder initialization in RTCP packets.
  • Case 1 The “Subtype” field is always used with the “Name” field to identify the content of the packet. If the “Name” field indicates that the payload in the RTP package is an SVC bit stream, then any three bits can be used to indicate the maximal value of syntax element “dependency_id” in the SVC bit stream. Exemplarily, we use the first three bits to save this value, as shown in FIG. 5 b ).
  • maxD_id is an unsigned three bit integer to indicate the maximal value of “dependency_id” in the SVC bit stream which will be sent.
  • the maximal value of “dependency_id” indicates the total layers of spatial/CGS in the SVC bit stream. This value is very important for SVC decoder basic initialization.
  • this value can be obtained by checking SVC bit stream dependency. But for error-prone (e.g. network based) SVC application, the maximal value of “dependency_id” obtained by checking the SVC bit stream dependency may be wrong due to packet loss.
  • the value of the maxD_id can be used by the receiver to initialize SVC decoder.
  • maxd_id is as described above.
  • maxT_id has three bits to indicate the maximal value of syntax element “temporal_id” in the SVC bit stream.
  • maxQ_id has four bits to indicate the maximal value of syntax element “quality_id” in the SVC bit stream.
  • the default value of “length” is two.
  • maxD_id can be used for the basic initialization of the SVC decoder
  • maxT_id and maxq_id can be used for enhanced SVC decoder initialization.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
US12/460,683 2008-07-28 2009-07-23 Data stream comprising RTP packets, and method and device for encoding/decoding such data stream Abandoned US20100020865A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP08305424A EP2150022A1 (de) 2008-07-28 2008-07-28 Datenstrom mit RTP-Paketen sowie Verfahren und Vorrichtung zur Kodierung/Dekodierung eines solchen Datenstroms
EP08305424.7 2008-07-28

Publications (1)

Publication Number Publication Date
US20100020865A1 true US20100020865A1 (en) 2010-01-28

Family

ID=40220088

Family Applications (1)

Application Number Title Priority Date Filing Date
US12/460,683 Abandoned US20100020865A1 (en) 2008-07-28 2009-07-23 Data stream comprising RTP packets, and method and device for encoding/decoding such data stream

Country Status (6)

Country Link
US (1) US20100020865A1 (de)
EP (2) EP2150022A1 (de)
JP (1) JP5686506B2 (de)
KR (1) KR101650571B1 (de)
CN (1) CN101640640B (de)
TW (1) TWI497982B (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090161762A1 (en) * 2005-11-15 2009-06-25 Dong-San Jun Method of scalable video coding for varying spatial scalability of bitstream in real time and a codec using the same
CN102752670A (zh) * 2012-06-13 2012-10-24 广东威创视讯科技股份有限公司 减少网络视频传输中马赛克现象的方法、装置及系统
US20140372828A1 (en) * 2013-06-13 2014-12-18 Lsi Corporation Systems and Methods for Hybrid Layer Data Decoding
CN104838649A (zh) * 2012-09-28 2015-08-12 三星电子株式会社 针对随机访问的用于对视频进行编码的方法和设备以及用于对视频进行解码的方法和设备

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105141961B (zh) * 2015-08-03 2017-12-22 中国人民解放军信息工程大学 一种基于视频隐写的空间数据双协议传输方法

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6522665B1 (en) * 1997-08-01 2003-02-18 Ntt Docomo, Inc. Data sequence generator, transmitter, information data decoder, receiver, transmitter-receiver, data sequence generating method, information data decoding method, and recording medium
US20030177011A1 (en) * 2001-03-06 2003-09-18 Yasuyo Yasuda Audio data interpolation apparatus and method, audio data-related information creation apparatus and method, audio data interpolation information transmission apparatus and method, program and recording medium thereof
US20030223466A1 (en) * 2002-05-31 2003-12-04 Noronha Ciro Aloisio Apparatus for redundant multiplexing and remultiplexing of program streams and best effort data
US20050011365A1 (en) * 2001-12-11 2005-01-20 Catherine Lamy System for transmitting additional information via a network
US20060282737A1 (en) * 2005-03-10 2006-12-14 Qualcomm Incorporated Decoder architecture for optimized error management in streaming multimedia
US20080008439A1 (en) * 2006-06-06 2008-01-10 Guangqun Liu Method and System For Dynamic Management Of Multiple Media Data Streams
US20080040498A1 (en) * 2006-08-10 2008-02-14 Nokia Corporation System and method of XML based content fragmentation for rich media streaming
US20080065965A1 (en) * 2004-11-16 2008-03-13 Miska Hannuksela Buffering packets of a media stream
US20080133517A1 (en) * 2005-07-01 2008-06-05 Harsh Kapoor Systems and methods for processing data flows
US20080214176A1 (en) * 2005-01-11 2008-09-04 Peter Amon Methods and Devices for the Transmission of Scalable Data
US20090177949A1 (en) * 2006-03-17 2009-07-09 Thales Method for protecting multimedia data using additional network abstraction layers (nal)
US20100049865A1 (en) * 2008-04-16 2010-02-25 Nokia Corporation Decoding Order Recovery in Session Multiplexing

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09247131A (ja) * 1996-03-07 1997-09-19 Toshiba Corp データ通信装置
JP2004056169A (ja) * 2002-07-16 2004-02-19 Matsushita Electric Ind Co Ltd 画像データ受信装置、画像データ送信装置
US20050275752A1 (en) * 2002-10-15 2005-12-15 Koninklijke Philips Electronics N.V. System and method for transmitting scalable coded video over an ip network
JP4336792B2 (ja) * 2003-03-13 2009-09-30 日本電気株式会社 パケット送信方法および無線アクセスネットワーク
JP4078544B2 (ja) * 2003-03-31 2008-04-23 サクサ株式会社 音声データの伝送装置および音声データの受信装置
EP1773063A1 (de) * 2005-06-14 2007-04-11 Thomson Licensing Verfahren und Vorrichtung zur Kodierung und Dekodierung von Videodaten
EP1742476A1 (de) * 2005-07-06 2007-01-10 Thomson Licensing System und Verfahren zur skalierbaren Kodierung und Übertragung von Video
WO2008013528A1 (en) * 2006-07-25 2008-01-31 Thomson Licensing Recovery from burst packet loss in internet protocol based wireless networks using staggercasting and cross-packet forward error correction
JP2009065259A (ja) * 2007-09-04 2009-03-26 Sanyo Electric Co Ltd 受信装置
JP2009118151A (ja) * 2007-11-06 2009-05-28 Fujitsu Ltd 通信システム、送信装置、中継装置、受信装置及び送信プログラム

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6522665B1 (en) * 1997-08-01 2003-02-18 Ntt Docomo, Inc. Data sequence generator, transmitter, information data decoder, receiver, transmitter-receiver, data sequence generating method, information data decoding method, and recording medium
US20030177011A1 (en) * 2001-03-06 2003-09-18 Yasuyo Yasuda Audio data interpolation apparatus and method, audio data-related information creation apparatus and method, audio data interpolation information transmission apparatus and method, program and recording medium thereof
US20050011365A1 (en) * 2001-12-11 2005-01-20 Catherine Lamy System for transmitting additional information via a network
US20030223466A1 (en) * 2002-05-31 2003-12-04 Noronha Ciro Aloisio Apparatus for redundant multiplexing and remultiplexing of program streams and best effort data
US20080065965A1 (en) * 2004-11-16 2008-03-13 Miska Hannuksela Buffering packets of a media stream
US20080214176A1 (en) * 2005-01-11 2008-09-04 Peter Amon Methods and Devices for the Transmission of Scalable Data
US20060282737A1 (en) * 2005-03-10 2006-12-14 Qualcomm Incorporated Decoder architecture for optimized error management in streaming multimedia
US20080133517A1 (en) * 2005-07-01 2008-06-05 Harsh Kapoor Systems and methods for processing data flows
US20090177949A1 (en) * 2006-03-17 2009-07-09 Thales Method for protecting multimedia data using additional network abstraction layers (nal)
US20080008439A1 (en) * 2006-06-06 2008-01-10 Guangqun Liu Method and System For Dynamic Management Of Multiple Media Data Streams
US20080040498A1 (en) * 2006-08-10 2008-02-14 Nokia Corporation System and method of XML based content fragmentation for rich media streaming
US20100049865A1 (en) * 2008-04-16 2010-02-25 Nokia Corporation Decoding Order Recovery in Session Multiplexing

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090161762A1 (en) * 2005-11-15 2009-06-25 Dong-San Jun Method of scalable video coding for varying spatial scalability of bitstream in real time and a codec using the same
CN102752670A (zh) * 2012-06-13 2012-10-24 广东威创视讯科技股份有限公司 减少网络视频传输中马赛克现象的方法、装置及系统
CN104838649A (zh) * 2012-09-28 2015-08-12 三星电子株式会社 针对随机访问的用于对视频进行编码的方法和设备以及用于对视频进行解码的方法和设备
US20140372828A1 (en) * 2013-06-13 2014-12-18 Lsi Corporation Systems and Methods for Hybrid Layer Data Decoding
US8959414B2 (en) * 2013-06-13 2015-02-17 Lsi Corporation Systems and methods for hybrid layer data decoding

Also Published As

Publication number Publication date
KR20100012830A (ko) 2010-02-08
TWI497982B (zh) 2015-08-21
TW201006255A (en) 2010-02-01
CN101640640A (zh) 2010-02-03
CN101640640B (zh) 2014-01-29
EP2150022A1 (de) 2010-02-03
EP2150024B1 (de) 2016-05-18
EP2150024A1 (de) 2010-02-03
JP2010045775A (ja) 2010-02-25
JP5686506B2 (ja) 2015-03-18
KR101650571B1 (ko) 2016-08-23

Similar Documents

Publication Publication Date Title
EP2086237B1 (de) Verfahren und Vorrichtung zur Umordnung und Multiplexierung von Multimediapaketen aus Multimediaströmen in Bezug auf zusammenhängende Sitzungen
US8432937B2 (en) System and method for recovering the decoding order of layered media in packet-based communication
Wang et al. RTP payload format for H. 264 video
van der Meer et al. RTP payload format for transport of MPEG-4 elementary streams
US7447978B2 (en) Buffering packets of a media stream
US8767818B2 (en) Backward-compatible aggregation of pictures in scalable video coding
EP1936868B1 (de) Verfahren zur Beobachtung der Dienstgüte von Multimedia Kommunikation
US20100049865A1 (en) Decoding Order Recovery in Session Multiplexing
EP1773063A1 (de) Verfahren und Vorrichtung zur Kodierung und Dekodierung von Videodaten
WO2007045140A1 (fr) Methode en temps reel pour transferer des donnees multimedia
EP2150024B1 (de) Datenstrom mit RTP-Paketen sowie Verfahren und Vorrichtung zur Kodierung/Dekodierung eines solchen Datenstroms
EP2363972A1 (de) Zuordnung von Diensten zu Pipelines der Bitübertragungsschicht
Westin et al. RTP payload format for vp8 video
EP4424008A1 (de) Verfahren, vorrichtung und computerprogrammprodukt zur videocodierung und videodecodierung
Zhu Rfc2190: Rtp payload format for h. 263 video streams
Meer et al. RFC3640: RTP Payload Format for Transport of MPEG-4 Elementary Streams
Even RTP payload format for H. 261 video streams
Wang et al. RFC 6184: RTP Payload Format for H. 264 Video
Westin et al. RFC 7741: RTP Payload Format for VP8 Video
Flodman et al. RTP Payload Format for VP9 Video
Weaver RTP Payload Format for VC-2 High Quality (HQ) Profile
Eleftheriadis RTP Payload Format for SVC Video draft-ietf-avt-rtp-svc-15. txt
Schierl et al. Decoding order recovery for multi flow transmission of scalable video coding (SVC) over mobile IP channels
Even RFC 4587: RTP Payload Format for H. 261 Video Streams
Galligan RTP Payload Format for VP8 Video draft-ietf-payload-vp8-01

Legal Events

Date Code Title Description
AS Assignment

Owner name: THOMSON LICENSING, FRANCE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:XIA, ZHI JIN;CHEN, ZHI BO;WU, YU WEN;REEL/FRAME:023031/0231;SIGNING DATES FROM 20090518 TO 20090519

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION