EP2377277A2 - Procédé et système d'abandon de paquets déterministe - Google Patents

Procédé et système d'abandon de paquets déterministe

Info

Publication number
EP2377277A2
EP2377277A2 EP09832432A EP09832432A EP2377277A2 EP 2377277 A2 EP2377277 A2 EP 2377277A2 EP 09832432 A EP09832432 A EP 09832432A EP 09832432 A EP09832432 A EP 09832432A EP 2377277 A2 EP2377277 A2 EP 2377277A2
Authority
EP
European Patent Office
Prior art keywords
data
frame
data stream
frame type
data segments
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.)
Withdrawn
Application number
EP09832432A
Other languages
German (de)
English (en)
Other versions
EP2377277A4 (fr
Inventor
Guntur Ravindra
Joseph Thaliath
Ian David Chakeres
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Motorola Solutions Inc
Original Assignee
Motorola Solutions Inc
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 Motorola Solutions Inc filed Critical Motorola Solutions Inc
Publication of EP2377277A2 publication Critical patent/EP2377277A2/fr
Publication of EP2377277A4 publication Critical patent/EP2377277A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • 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/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • 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/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64784—Data processing by the network
    • H04N21/64792—Controlling the complexity of the content stream, e.g. by dropping packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/24—Systems for the transmission of television signals using pulse code modulation
    • 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
    • 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/80—Responding to QoS

Definitions

  • the present invention relates, in general, to processing of video streams, and more particularly to a method and system for processing a video stream by intelligently dropping data packets to be transmitted, based on bandwidth constraints and video semantics.
  • Video streaming has become an integral part of the lives of day-to-day Internet users.
  • Video streaming has also gained popularity in real-time surveillance, video conferencing, etc.
  • various performance related issues have arisen, mainly as a result of bandwidth constraints.
  • a typical example of these performance related issues can be a user watching a streaming video on the Internet and not getting the required audio or video quality.
  • One of the reasons for poor video quality in MPEG video is random packet loss in the streamed video Group of Pictures (GoP).
  • a GoP is a logical partitioning of a sequence of video frames.
  • a typical GoP includes three types of pictures or frames, namely, Intra coded pictures (I-frames), Predicted pictures (P-frames) and Bi- predictive pictures (B-frames).
  • I-frame Intra coded pictures
  • P-frames Predicted pictures
  • B-frames Bi- predictive pictures
  • a GoP starts with an I-frame, which is also referred to as a key or reference frame.
  • An I-frame is intra-coded, which means that the discrete cosine transform (DCT) co-efficients of pixel blocks are encoded without reference to pixel blocks of other frames.
  • a P-frame is encoded using motion compensation and prediction. It consists of motion vectors which specify the extent to which a particular pixel block has spatially moved relative to its position in the previous reference frame.
  • the reference for a P-frame could be an I-frame or a previous P- frame.
  • B-frames unlike I-frames and P-frames, contain bi-directionally predicted blocks. Therefore, to decode a
  • One method to avoid random packet dropping is to reserve enough network level resources so that packet dropping does not happen. This method does not work when the demand for streaming videos fluctuates, since the reserved network level resources may not be adequate when the demand surges.
  • Another approach is to tag packets in a video stream, using which the network decides on the priorities of the packets. Only packets with high priority are allowed to be transmitted in this case.
  • the fundamental issue with this approach is the need for a device which automatically tags a flow of video frames in a video stream. Also, this approach does not work when there is a bandwidth constraint and the demand for streaming videos changes dynamically.
  • FIG. 1 is a block diagram of an exemplary network router in accordance with an embodiment of the invention.
  • FIG. 2 is a flow diagram illustrating a method for managing a data stream in a communication network, in accordance with an embodiment of the present invention
  • FIGs. 3 and 4 depict a flow diagram illustrating a method for managing a data stream in a communication network in accordance with another embodiment of the present invention
  • FIG. 5 is a block diagram of a data stream manager for managing a data stream in a communication network in accordance with an embodiment of the invention
  • FIG. 6 is a block diagram of an exemplary state machine for storing information during the processing of a data stream in accordance with an embodiment of the present invention.
  • FIGs. 7 and 8 depict a flow diagram illustrating a method for storing information during the processing of a data stream in accordance with an embodiment of the present invention.
  • a method for managing a data stream in a communication network includes receiving a packetized data stream including one or more data segments. Each data segment of the one or more data segments corresponds to a frame type of a plurality of frame types. Further, the method includes determining a number of data segments to be transmitted for each frame type of the plurality of frame types in the communication network, based on at least one predefined parameter. Furthermore, the method includes dropping at least one data segment for at least one frame type of the plurality of frame types, based on the number of data segments to be transmitted for each frame type, a functional dependency between the one or more data segments, and a functional dependency between the plurality of frame types. The method also includes re- CML07197 packetizing the received packetized data stream based on the dropping of the at least one data segment.
  • a system for managing a data stream in a communication network includes a receiver, a processor and a re-packetizer.
  • the receiver is configured to receive a packetized data stream including one or more data segments. Each data segment of the one or more data segments corresponds to a frame type of a plurality of frame types.
  • the processor is configured to determine a number of data segments to be transmitted for each frame type of the plurality of frame types in the communication network based on at least one predefined parameter, and to drop at least one data segment for at least one frame type of the plurality of frame types.
  • the dropping of the at least one data segment is based on the number of data segments to be transmitted for each frame type, a functional dependency between the one or more data segments, and a functional dependency between the plurality of frame types. Furthermore, the re- packetizer is configured to re-packetize the received packetized data stream based on the dropping of the at least one data segment.
  • the terms 'comprises,' 'comprising,' or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article or apparatus that comprises a list of elements does not include only those elements but may include other elements that are not expressly listed or inherent in such a process, method, article or apparatus.
  • An element proceeded by 'comprises... a' does not, without more constraints, preclude the existence of additional identical CML07197 elements in the process, method, article or apparatus that comprises the element.
  • the term 'another,' as used in this document, is defined as at least a second or more.
  • the terms 'includes' and/or 'having', as used herein, are defined as comprising.
  • FIG. 1 illustrates an exemplary network router 102 in accordance with an embodiment of the invention.
  • the network router 102 receives a packetized data stream, which includes one or more data segments.
  • the packetized data stream can be, for example, a Group of Pictures (GoP) in a Motion Picture Experts Group-2 (MPEG-2) or MPEG-4 transport stream.
  • the GoP may be multiplexed with audio frames or it may be multiplexed without audio frames.
  • a GoP includes a number of data segments. Each data segment corresponds to a particular picture or frame type.
  • I-frames Intra coded pictures
  • P-frames Predicted pictures
  • B-frames Bi-predictive pictures
  • these frames may be functionally interdependent on each other.
  • an I-frame is intra coded and is not dependent on any of the other frames
  • a particular P-frame may be dependent on the I-frame or any P-frame preceding the particular P-frame
  • a B-frame may be dependent on past or future frames with respect to the B-frame.
  • the network router 102 When the GoP is received by the network router 102, the network router selectively drops certain data segments in the GoP and transmits the rest of the data segments of the GoP. Before transmitting the GoP, the network router 102 re- packetizes the GoP on the basis of the selective dropping of the data segments. The entire method and system for selectively dropping data segments is explained in detail in conjunction with the rest of the figures.
  • FIG. 2 is a flow diagram illustrating a method for managing data stream in a communication network in accordance with an embodiment of the present invention. To describe the method illustrated in FIG. 2, references will be made to FIG. 1, CML07197 although, it will be apparent to those skilled in the art that the method can be applicable to any other embodiment of the present invention.
  • a data stream can be, for example, a Group of Pictures (GoP) in a Motion Picture Experts Group-2 (MPEG-2) transport stream or a Motion Picture Experts Group-4 (MPEG-4) transport stream.
  • GoP Group of Pictures
  • MPEG-2 Motion Picture Experts Group-2
  • MPEG-4 Motion Picture Experts Group-4
  • a packetized data stream including one or more data segments is received. As already mentioned in FIG. 1, each data segment is either an Intra coded frame (I-frame), a Predicted frame (P- frame) or a Bi-predictive frame (B-frame).
  • I-frame Intra coded frame
  • P- frame Predicted frame
  • B-frame Bi-predictive frame
  • the received packetized data stream is either multiplexed with audio frames or is multiplexed without audio frames.
  • the mentioned data segments can also be audio frames, along with I-, P- and B-frames.
  • a number of data segments to be transmitted for each frame type of the plurality of frame types in the communication network is determined.
  • the number of data segments to be transmitted is determined on the basis of at least one predefined parameter.
  • An example of the predefined parameter can be an available bandwidth for the transmission of the received data stream in the communication network.
  • the available bandwidth of the data stream is determined based on data size for each frame type in the previous data stream.
  • the data size is dependent on the type of data segment in the data stream, and the data size decreases with I-frame to P-frame to B-frame.
  • the size of '50 bytes' is chosen above as an example to facilitate the description of this figure and does not illustrate an actual size of a data segment.
  • Another example of the predefined parameter above can be the type of the received data stream. For example, if a data stream is received which includes audio frames as well as video frames, then there may be a situation where all the video CML07197 frames are transmitted and all the audio frames are not allowed to be transmitted.
  • a typical example can be a video streaming of a football match on the Internet. In this case, if there is a bandwidth constraint, all the audio frames may not be transmitted and only the video frames may be transmitted. This may be because the user watching the streaming video may be more interested in watching the match, rather than listening to the commentary.
  • Yet another example of the predefined parameter can be the number of data segments received for each frame type in a previously received data stream. While using this parameter, it is assumed that the number of data segments for each frame type received in a data stream remains almost the same across various data streams. For example, if a previously received data stream had one I-frame, four P-frame and seven B-frames, then it is assumed that the next data stream will have the same number and arrangement of data segments. The use of this parameter becomes better understood with the help of the following example.
  • the number of data segments to be transmitted for the current data stream is calculated. If the average size of an I-frame is 100 bytes, of an P-frame is 50 bytes, and of an B-frame is 40 bytes, then the number of I-frames to be transmitted may be calculated to be one I-frame, four P-frames and two B-frames. It should be noted that an I-frame is always transmitted in the communication network, irrespective of its size.
  • the MPEG video might contain only I-frames. The present invention can work in this scenario also. In case I-frames are dropped, then all the P- and B-frames until the next I-frame are also dropped. Hence the invention allows for dropping I-frames also. In another instance, the invention can also allow for dropping of integral number of GoPs as well.
  • the data segment to be dropped is decided on the basis of the determined number of data segments to be transmitted for each frame type, the functional dependency between the one or more data segments, and the functional dependency between the plurality of frame types.
  • the functional dependency CML07197 between the one or more data segments and the plurality of frame types is based on either one of Motion Pictures Experts Group-2 (MPEG-2) or Motion Pictures Experts Group-4 (MPEG-4) video semantics.
  • Step 208 becomes better understood with the help of the following example.
  • a data stream which has one I-frame, three P- frames and five B-frames, and the arrangement of the frames is 'IPBBPBPBB'.
  • the number of data segments to be transmitted is one I-frame, two P-frames and three B-frames.
  • one P- frame is to be dropped and two B-frames are to be dropped.
  • Which of the three P frames is to be dropped and which two of the B-frames are to be dropped are determined on the basis of the functional dependency of the data segments and the frame types.
  • the last P-frame in the data stream has less importance in the data stream than the first P-frame. Therefore, in this case, the last P-frame may be chosen to be dropped.
  • the B-frames since there is no dependency, the B-frames are dropped on the basis of a preset condition. For example, it may be set that every alternate B-frame is dropped from the received data stream. [0035] A typical example for determining which data segment of which frame type is to be dropped is described now. It should be noted that the described algorithm is exemplary in nature and the invention can also work with the use of any other algorithm also.
  • the described algorithm is an implementation of the 0/1 knapsack solution for the determination of an optimum number of data segments to be transmitted constrained by the bandwidth parameter.
  • the constraints can be other than a bandwidth constraint.
  • a profit value may be associated with each of the frame types and a cost (bytes per second) incurred while transmitting a particular frame type is determined. It is assumed that the cost is the same for all the frames of a particular type. This can be achieved by assigning the average frame bandwidth as the cost to each frame type. The profit assigned to each frame is based on the frame dependency, as described above. Hence, I-frames are CML07197 assigned the highest profit value. All B-frames are assigned the same profit value, as no frame depends on a B-frame. And P-frames are assigned a profit value which decreases with the position of the P-frame in the data stream.
  • the received data stream is re-packetized on the basis of the dropping of the at least one data segment.
  • the received packetized data stream is re-packetized, after the dropping of data segments, according to the User Datagram Protocol (UDP) format. Subsequently, the re-packetized data stream is transmitted in the communication network.
  • UDP User Datagram Protocol
  • FIGs. 3 and 4 depict a flow diagram illustrating a method for managing a data stream in a communication network in accordance with another embodiment of the present invention. To describe the method illustrated in FIGs. 3 and 4, references will be made to FIGs.
  • the method for managing a data stream in the communication network is initiated.
  • a packetized data stream is received.
  • the data stream includes one or more data segments corresponding to either audio frames or I-, P- or B-frames.
  • the received data stream is a GoP in an MPEG-2 transport stream.
  • a GoP start code is determined in the received data stream.
  • a GoP start code indicates the start of a new GoP. Typically, the first four bytes of the data stream indicates the GoP start code.
  • the number of data segments to be transmitted for each frame is determined for the new GoP. The entire method for determining the number of data segments to be transmitted has already been explained in conjunction with FIG. 2.
  • a picture code of the received data segments within the data stream is identified to determine the frame type of the received data segment. For example, after the GoP start code is determined, an I-frame is received as the first CML07197 frame. Typically, the next four bytes after the four bytes of the GoP start code indicate the picture code for an I-frame. When the reception of the I-frame is finished, another picture is code is determined. The next data segment, after the I- frame, may be a B-frame or a P-frame. Typically, a new picture code indicates the end of the last data segment and the start of a new data segment.
  • the picture start codes may be split across two non-contiguous data streams and across two non-contiguous data segments.
  • the last three bytes of the data segment are buffered and attached to the first byte of the next data segment. This way, a valid 4-byte identifier is formed. This approach helps in identifying frame types across data segments and data streams.
  • a check is performed to determine whether the maximum number of data segments to be transmitted for the particular frame type has already been transmitted. For example, if the picture code suggests that the received data segment is of the P-frame type, then it is checked whether the maximum number of P-frames to be transmitted has already been transmitted or not. Referring now to FIG. 4, if the maximum number of data segments has not been transmitted for the particular frame type then, at step 402, the received data segment is forwarded for re-packetization. [0046] If the maximum number of data segments has been transmitted for the particular frame type then, at step 404, the received data segment is dropped. Thereafter, steps 402 and 406 each proceeds to step 406, where it is determined whether the current GoP has ended or not.
  • a new GoP start code indicates the end of the last GoP.
  • step 310 is again performed. In other words, another picture code is detected and the entire method, as stated above, is repeated.
  • the average frame statistics is calculated at step 408. Thereafter, at step 410 it is determined that how many I-, P-, and B-frames can be transmitted in the next GoP duration using an optimization algorithm.
  • step 412 the method for managing a data stream in the communication network is terminated.
  • FIG. 5 illustrates a block diagram of a data stream manager 502 for managing a data stream in a communication network in accordance with an embodiment of the invention.
  • the data stream manager 502 may include all or a few of the components shown in FIG. 5. Further, those ordinarily skilled in the art will understand that the data stream manager 502 may include additional components that are not shown here and are not germane to the operation of the data stream manager 502 in accordance with the inventive arrangements.
  • Data stream manager 502 executes the methods described with reference to To describe the data stream manager 502, reference will be made to FIGs. 2, 3 and 4 and preferably is implemented in the network router 102, although it is understood that the data stream manager 502 can be used in any other suitable environment or network.
  • the data stream manager 502 includes a receiver 504, a processor 506, a re-packetizer 508 and a memory 510.
  • the receiver 504 receives a packetized data stream including one or more data segments.
  • the packetized data stream is a GoP in an MPEG-2 transport stream multiplexed with or without audio frames and each data segment corresponds to a frame type of a plurality of frame types.
  • a data segment may be an I-frame, a P-frame or a B-frame of a GoP or an audio frame.
  • the receiver 504 determines that a new GoP is received by determining a GoP start code of the GoP.
  • a GoP start code indicates the start of the GoP and is usually the first four bytes of the received GoP.
  • the processor 506 determines the number of data segments to be transmitted for each frame type in the communication network based on one or more predefined parameters.
  • the predefined parameters can be, for example, an available bandwidth for the transmission of a data stream in the communication network, a type of the received packetized data stream, or a number of data segments for each frame type received in a previous data stream. The entire process of determining the number of data segments to be transmitted in the communication network using the mentioned parameters has already been explained in conjunction with FIG. 2.
  • the processor 506 determines the number of data segments to be transmitted for each frame type, the processor 506 identifies the frame type of the received data segment. Typically, the processor 506 identifies the frame type of the data segment by determining the picture code of the data segment. The picture code is usually of 4 bytes size and is received before the data segment is received. In accordance with one embodiment of the invention, the processor 506 can also identify the frame type of the data segments across non-contiguous data segments and across non-contiguous data streams.
  • the processor 506 When the processor 506 identifies the frame type of the received data segment, the processor 506 either drops the data segment or sends the data segment to the re-packetizer 508 to for re-packetizing.
  • the decision to drop the packet is based on the determined number of data segments to be transmitted for each frame, the functional dependency between the data segments, and the functional dependency between the frame types.
  • the functional dependency is based on either the Moving Picture Experts Group-2 (MPEG-2) video semantics or the Moving Picture Experts Group-4 (MPEG-4) video semantics.
  • MPEG-2 Moving Picture Experts Group-2
  • MPEG-4 Moving Picture Experts Group-4
  • the re-packetizer 508 re-packetizes the data stream on the basis of the dropping of the data segments and in such a way that the semantics of the data stream does not alter.
  • the re-packetizer 508 re- packetizes the data stream on the basis of the User Datagram Protocol (UDP) format, such that the data stream is coded in the MPEG-2 transport stream format and an UDP header is attached to it.
  • UDP User Datagram Protocol
  • the data stream manager 502 also includes the memory 510 for storing a count of data segments for each frame type in a previous data stream and a count of data segments for each frame type in the received packetized data stream.
  • the memory 510 uses a state machine to store the above mentioned count of data segments.
  • An exemplary embodiment of the state machine is explained in FIG. 6.
  • FIG. 6 illustrates an exemplary state machine for storing information during the processing of a data stream in accordance with an embodiment of the present invention. The figure shows a data stream having a packet header field and the data.
  • the packet header field is usually a UDP header and the data includes the various data segments such as I-frames, P-frames and B-frames.
  • a check is performed to determine whether the data stream belongs to a priority flow. Only if the data stream belongs to a priority flow, the data stream is forwarded for processing in the state machine. Typically, to determine whether a data stream belongs to a priority flow or not, the address contained in the UDP header of the data stream is checked against a look up table, which contains the addresses for all priority flow videos.
  • the packet header field is hashed into an active flow Content Addressable Memory (CAM) table. Thereafter, the source address, the destination address, the source port and the destination port act as a 'key' to this table. If the flow table entry to a particular key is not found, it is assumed that the data stream does not belong to the priority flow. When a data stream does belong to the priority flow, its data parsing begins. Thereafter, the state variables corresponding to the current data stream, audio or video statistics for the current and previous data streams are stored in the state machine.
  • CAM Active flow Content Addressable Memory
  • FIGs. 7 and 8 depict a flow diagram illustrating a method performed by data stream manager 502 for storing information during the processing of a data stream in accordance with an embodiment of the present invention.
  • FIGs. 7 and 8 depict a flow diagram illustrating a method performed by data stream manager 502 for storing information during the processing of a data stream in accordance with an embodiment of the present invention.
  • FIGs. 1, 2, 3 and 4 references will be made to FIGs. 1, 2, 3 and 4, although it will be apparent to those skilled in the art that the method can be applicable to any other embodiment of the present invention.
  • the method for storing information during the processing of a data stream is initiated.
  • the start code of the data stream is detected. As already mentioned earlier, detection of the start code indicates starting of a new data stream.
  • a picture start code of the data stream is detected.
  • the picture start code of a data stream indicates the start of a new data segment.
  • the picture start code may also contain the information of the frame type of the current data segment.
  • the data segment can be an I-frame, a P-frame or a B-frame.
  • the state variable that stores the current frame state is set to I-frame.
  • the previous frame statistics are updated at step 712. For example, suppose that a P-frame was being transmitted and then a picture start code is detected and the data segment for that picture start code is determined to be an I- frame. In this case, the count of P-frame (previous frame) that are transmitted is decremented by one.
  • step 714 it is checked whether the current data segment is a P-frame. If the current data segment is determined to be a P-frame, then at step 716, the state variable that stores the current frame type is set to P-frame. After the state variable is set to P-frame the previous frame statistics are updated at step 712, as explained earlier.
  • step 718 the state variable that stores the current frame type is set to B-frame. After the state variable is set to B-frame, the previous frame statistics is updated at step 712, as explained earlier.
  • step 802 it is determined whether the GoP reception has ended. If the GoP reception has not ended, then the steps 706 onwards are repeated. In accordance with one embodiment of the invention, if it is determined that the current GoP has ended, then an average frame statistic is calculated at step 804. Thereafter, at step 806 it is determined that how many I-, P-, B-frames can be transmitted in the next GoP duration using an optimization algorithm. At step 808, the method for storing information during the processing of a data stream is terminated.
  • Various embodiments provide a method and system for managing data stream in a communication network.
  • the described invention has an advantage that it overcomes the drawbacks of random packet loss to achieve a desired quality in situations of bandwidth constraints. Since MPEG has a functional dependency on the sequence of its frames in the data stream, random loss can spoil the video semantics.
  • the invention implements a method for computing the number of packets for each type of frames to be transmitted in the communication network. Thereafter, based on the functional dependency between different frames, selected CML07197 frames are dropped and are not transmitted. This ensures that the video or audio quality of the streaming video received by the user is not deteriorated significantly. Also, the present invention ensures that the MPEG video semantics are kept intact as different frames are dropped.
  • the embodiments of the invention described herein may comprise one or more conventional processors and unique stored program instructions that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the embodiments of the invention described herein.
  • the non-processor circuits may include, but are not limited to, a radio receiver, a radio transmitter, signal drivers, clock circuits, power source circuits, and user input devices. As such, these functions may be interpreted as steps of a method for responding to an emergency situation from a communication device.
  • some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or various combinations of some of the functions are implemented as custom logic.
  • a combination of these approaches can also be used. Therefore, methods and means for these functions have been described herein.
  • one of the means for implementing such functions is the media that stores the program instructions, be it magnetic storage or a signal conveying a file.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un procédé (200) et un système (502) destinés à la gestion d'un flux de données dans un réseau de communication. Le procédé consiste à recevoir (204) un flux de données qui est en paquets et qui comprend un ou plusieurs segments de données. Chaque segment de données correspond à un type de trame d'une pluralité de types de trames. Le procédé consiste alors, sur la base d'au moins un paramètre prédéfini, à déterminer (206), pour chaque type de trame, un nombre de segments de données à transmettre dans le réseau de communication. Le procédé consiste ensuite à abandonner (208) au moins un segment de données pour au moins un type de trame, et ce, en se basant, d'une part sur le nombre de segments de données à transmettre pour chaque type de trame, et d'autre part sur les relations de dépendances fonctionnelles entre les différents segments de données ainsi qu'entre les types de trames de la pluralité de trames. Le procédé consiste également à remettre en paquets (210) les flux de données en paquets reçus en se basant sur l'abandon des segments de données.
EP09832432.0A 2008-12-10 2009-12-08 Procédé et système d'abandon de paquets déterministe Withdrawn EP2377277A4 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN2787DE2008 2008-12-10
PCT/US2009/067045 WO2010068600A2 (fr) 2008-12-10 2009-12-08 Procédé et système d'abandon de paquets déterministe

Publications (2)

Publication Number Publication Date
EP2377277A2 true EP2377277A2 (fr) 2011-10-19
EP2377277A4 EP2377277A4 (fr) 2013-08-28

Family

ID=42243290

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09832432.0A Withdrawn EP2377277A4 (fr) 2008-12-10 2009-12-08 Procédé et système d'abandon de paquets déterministe

Country Status (3)

Country Link
EP (1) EP2377277A4 (fr)
KR (1) KR101240808B1 (fr)
WO (1) WO2010068600A2 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8649339B2 (en) 2010-10-22 2014-02-11 Motorola Solutions, Inc. Method and apparatus for distributing video packets over multiple bearers for providing unequal packet loss protection
US8428023B2 (en) * 2010-10-22 2013-04-23 Motorola Solutions, Inc. Method and apparatus for distributing video packets over multiple bearers for providing unequal packet loss protection
KR101858695B1 (ko) * 2012-04-09 2018-05-16 엘지전자 주식회사 데이터 관리 방법
US11736406B2 (en) * 2017-11-30 2023-08-22 Comcast Cable Communications, Llc Assured related packet transmission, delivery and processing
US10841645B1 (en) * 2019-12-09 2020-11-17 Western Digital Technologies, Inc. Storage system and method for video frame segregation to optimize storage

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050169312A1 (en) * 2004-01-30 2005-08-04 Jakov Cakareski Methods and systems that use information about a frame of video data to make a decision about sending the frame
WO2006061801A1 (fr) * 2004-12-10 2006-06-15 Koninklijke Philips Electronics, N.V. Diffusion en temps reel sans fil par codage monocouche et priorisation de diffusion
US20070204320A1 (en) * 2006-02-27 2007-08-30 Fang Wu Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network
US20080259799A1 (en) * 2007-04-20 2008-10-23 Van Beek Petrus J L Packet Scheduling with Quality-Aware Frame Dropping for Video Streaming

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW518844B (en) * 2001-03-21 2003-01-21 Ind Tech Res Inst Transmission method of multimedia data packet in network system
US20070147314A1 (en) * 2005-12-22 2007-06-28 Telefonaktiebolaget Lm Ericsson (Publ) Network processing node and method for manipulating packets
US20070276954A1 (en) * 2006-05-19 2007-11-29 Hong Kong University Of Science And Technology Low-Delay High Quality Video Streaming Using TCP
US7898950B2 (en) * 2006-08-18 2011-03-01 Microsoft Corporation Techniques to perform rate matching for multimedia conference calls

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050169312A1 (en) * 2004-01-30 2005-08-04 Jakov Cakareski Methods and systems that use information about a frame of video data to make a decision about sending the frame
WO2006061801A1 (fr) * 2004-12-10 2006-06-15 Koninklijke Philips Electronics, N.V. Diffusion en temps reel sans fil par codage monocouche et priorisation de diffusion
US20070204320A1 (en) * 2006-02-27 2007-08-30 Fang Wu Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network
US20080259799A1 (en) * 2007-04-20 2008-10-23 Van Beek Petrus J L Packet Scheduling with Quality-Aware Frame Dropping for Video Streaming

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2010068600A3 (fr) 2010-10-14
KR20110105795A (ko) 2011-09-27
KR101240808B1 (ko) 2013-03-11
EP2377277A4 (fr) 2013-08-28
WO2010068600A2 (fr) 2010-06-17

Similar Documents

Publication Publication Date Title
US8270425B2 (en) Method and system for multicast video streaming over a wireless local area network (WLAN)
US9900363B2 (en) Network streaming of coded video data
JP4874343B2 (ja) スケーラブルビデオ符号化における、下位互換性のあるピクチャの集約
US8843979B2 (en) Predictive frame dropping to enhance quality of service in streaming data
AU2005242601B2 (en) Multiple interoperability points for scalable media coding and transmission
US8290036B2 (en) Method, apparatus and system for concurrent processing of multiple video streams
US9894381B1 (en) Managing multi-reference picture buffers for video data coding
US8416859B2 (en) Signalling and extraction in compressed video of pictures belonging to interdependency tiers
US10491964B2 (en) Assisted acceleration for video streaming clients
CA2936164C (fr) Appareil de communication, procede de generation de donnees de communication et procede de traitement de donnees de communication
KR101240808B1 (ko) 결정론적 패킷 누락에 대한 방법 및 시스템
US9264737B2 (en) Error resilient transmission of random access frames and global coding parameters
US9215396B2 (en) Faster access to television channels
US20100132007A1 (en) Accelerating channel change time with external picture property markings
Burza et al. Adaptive streaming of MPEG-based audio/video content over wireless networks
US10536708B2 (en) Efficient frame loss recovery and reconstruction in dyadic hierarchy based coding
US20150149593A1 (en) Virtual desktop infrastructure server, computer implemented video streaming method, and non-transitory computer readable storage medium thereof
Go et al. A systematic reallocation and prioritization scheme for error-resilient transmission of video packets
WO2023078048A1 (fr) Procédé et appareil d'encapsulation de flux binaire vidéo, procédé et appareil de décodage de flux binaire vidéo, et procédé et appareil d'accès à un flux binaire vidéo
Sinky et al. Dynamic Retry Adaptation Scheme to Improve Transmission of H. 264 HD Video over 802.11 Peer‐to‐Peer Networks
Leung et al. A Video Reconstruction Approach Supporting Frame Skipping in H. 264
KR20050023429A (ko) 우선 순위화 송신 패킷의 적응성 드롭핑

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20110711

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20130729

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 28/02 20090101AFI20130723BHEP

Ipc: H04L 12/823 20130101ALI20130723BHEP

Ipc: H04L 12/853 20130101ALI20130723BHEP

Ipc: H04L 12/801 20130101ALI20130723BHEP

Ipc: H04N 21/647 20110101ALI20130723BHEP

Ipc: H04L 29/06 20060101ALI20130723BHEP

17Q First examination report despatched

Effective date: 20140403

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160609