EP2377277A2

EP2377277A2 - Method and system for deterministic packet drop

Info

Publication number: EP2377277A2
Application number: EP09832432A
Authority: EP
Inventors: Guntur Ravindra; Joseph Thaliath; Ian David Chakeres
Original assignee: Motorola Solutions Inc
Current assignee: Motorola Solutions Inc
Priority date: 2008-12-10
Filing date: 2009-12-08
Publication date: 2011-10-19
Also published as: KR20110105795A; KR101240808B1; WO2010068600A3; WO2010068600A2; EP2377277A4

Abstract

The present invention provides a method (200) and system (502) for managing a data stream in a communication network. The method includes receiving (204) a packetized data stream including one or more data segments. Each data segment corresponds to a frame type of a plurality of frame types. Further, the method includes determining (206) a number of data segments to be transmitted for each frame type in the communication network, based on at least one predefined parameter. Furthermore, the method includes dropping (208) at least one data segment for at least one frame type, based on the number of data segments to be transmitted for each frame type and the functional dependency between the one or more data segments and between the plurality of frame types. The method also includes re-packetizing (210) the received packetized data stream on the basis of the dropping of the data segments.

Description

CML07197

METHOD AND SYSTEM FOR DETERMINISTIC PACKET DROP

FIELD OF THE INVENTION

[0001] 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.

BACKGROUND OF THE INVENTION

[0002] With the advancement of the communication technology, the use of 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. With the increase in the popularity of video streaming, 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. [0003] 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). 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 B-frame, the past and future reference frames are needed. CML07197

[0004] Typically, whenever there is a bandwidth constraint, random packet loss occurs, regardless of the fact whether an I-frame is dropped or a P- or B-frame. As mentioned above, a P-frame is dependent on an I-frame and possibly other P-frames. Therefore, if packets containing I-frame data are dropped during random packet dropping, all the subsequent P-frames in that GoP will not be decoded properly. The same problem occurs if P-frames are randomly dropped, without considering their dependency on other P-frames.

[0005] 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.

[0006] 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.

[0007] In light of the foregoing, there is a need for a method and system for deterministically dropping packets in a video stream. The method and system should work well in situations of bandwidth constraints and the packets should not be dropped randomly.

BRIEF DESCRIPTION OF THE FIGURES

[0008] The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, and which, together with the detailed description below, are incorporated in and form part of the specification, serve to further illustrate various embodiments and explain various principles and advantages, all in accordance with the present invention.

[0009] FIG. 1 is a block diagram of an exemplary network router in accordance with an embodiment of the invention;

[0010] 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; CML07197

[0011] 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;

[0012] 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;

[0013] 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; and

[0014] 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.

[0015] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated, relative to other elements, to help in improving an understanding of the embodiments of the present invention.

DETAILED DESCRIPTION

[0016] For one embodiment, a method for managing a data stream in a communication network is provided. The method 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.

[0017] For another embodiment, a system for managing a data stream in a communication network is provided. The system 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. Further, 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.

[0018] Before describing in detail the method and system for managing a data stream in a communication network in accordance with various embodiments of the present invention, it should be observed that the present invention resides primarily in combinations of method steps related to the method for managing data streams in the communication network. Accordingly, the system components and method steps have been represented, where appropriate, by conventional symbols in the drawings, showing only those specific details that are pertinent for an understanding of the present invention, so as not to obscure the disclosure with details that will be readily apparent to those with ordinary skill in the art, having the benefit of the description herein.

[0019] In this document, 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. The term 'another,' as used in this document, is defined as at least a second or more. [0020] FIG. 1 illustrates an exemplary network router 102 in accordance with an embodiment of the invention. As shown in the figure, 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. [0021] As mentioned above, a GoP includes a number of data segments. Each data segment corresponds to a particular picture or frame type. Examples of picture or frame types include Intra coded pictures (I-frames), Predicted pictures (P-frames) and Bi-predictive pictures (B-frames). Those ordinarily skilled in the art know that these frames may be functionally interdependent on each other. For example, 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, and a B-frame may be dependent on past or future frames with respect to the B-frame. [0022] 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.

[0023] It should be noted that although the invention is described below in conjunction with an MPEG-2 transport stream or video semantics, the invention can also work with a Motion Picture Experts Group-4 (MPEG-4) transport stream or video semantics.

[0024] 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.

[0025] At step 202, the method for managing a data stream in a communication network is initiated. 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. At step 204, 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).

[0026] In accordance with one embodiment of the invention, the received packetized data stream is either multiplexed with audio frames or is multiplexed without audio frames. When the data stream is multiplexed with audio frames, then the mentioned data segments can also be audio frames, along with I-, P- and B-frames. [0027] At step 206, 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. For example, if the available bandwidth is 400 bytes and the received data stream has a size of 600 bytes, then only the data segments corresponding to the size of 400 bytes are selected to be transmitted. In this example, if each data segment has a size of 50 bytes, only 8 data segments are selected to be transmitted in the communication network. In accordance with one embodiment of the invention, the available bandwidth of the data stream is determined based on data size for each frame type in the previous data stream.

[0028] It should be noted that 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. [0029] 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.

[0030] 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.

[0031] Assuming that the available bandwidth is 400 bytes and the previously received data stream had one I-frame, four P-frames and seven B-frames, 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. [0032] In another instance, 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.

[0033] At step 208, at least one data segment for at least one frame type of the plurality of frame types is dropped from the received data stream. 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. In accordance with one embodiment of the invention, 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.

[0034] Step 208 becomes better understood with the help of the following example. Consider a situation where a data stream is received which has one I-frame, three P- frames and five B-frames, and the arrangement of the frames is 'IPBBPBPBB'. Now, also assume that at step 206, it is determined that the number of data segments to be transmitted is one I-frame, two P-frames and three B-frames. In this case, 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. It is known to those skilled in the art that a P-frame having more frames dependent on it has more 'importance' than those P-frames which have fewer frames dependent on them. Therefore, 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. In the case of 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. In particular, 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. Those ordinarily skilled in the art can appreciate that the present method is suitable for any embodiment where the constraints can be other than a bandwidth constraint.

[0036] In accordance with one embodiment of the invention, 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.

[0037] Let the number of frames in a data stream be N and the available bandwidth be B. Let the set C = {ci, C₂ , .... C_n }and P = { pi, p₂,.... p _n } be the cost and profit associated with the particular data stream. Let the normalized profit values be the set PC where Pc₁ = P₁Zc₁. Let the elements of PC be sorted in the descending order and arranged as a list of values A = {a-i, a₂ , _.... a_n }. Without loss of generality, let a, >= a_j if i < j and a, is in the set PC. Given the functions f : f (a,) = c _j and g : g (a,) = p, , the task of the algorithm is to find s such that: where,

s The optimal solution of the equation mentioned above is given by:

Z (C(KP)) = ∑ g(α,)+ g(a_s)x_s ι=l where s-l ι=l

Xs =

/K)

If integrity bounds are imposed, then the following relationships are achieved:

z' (C(KP))\ = Y S(Ci₁ ) + g(a_s )\x_s i=l Choosing would result in a profit which is less than the optimal by a value equal to x_sg(a_s). CML07197

[0038] At step 210, the received data stream is re-packetized on the basis of the dropping of the at least one data segment. In accordance with one embodiment of the invention, 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.

[0039] Another step (not shown) in the method for managing a data stream in a communication network is the storing of the count of data segments for each frame type received in the previous data stream and the current received data stream. The count is stored so that for the next data stream, the number of data streams to be transmitted may be determined, based on the previously received data stream. At step 212, the method for managing data stream in a communication network is terminated. [0040] 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. 1 and 2, 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. [0041] At step 302, the method for managing a data stream in the communication network is initiated. At step 304, a packetized data stream is received. As already mentioned in FIG. 2, the data stream includes one or more data segments corresponding to either audio frames or I-, P- or B-frames. In accordance with one embodiment of the invention, the received data stream is a GoP in an MPEG-2 transport stream.

[0042] At step 306, 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. At step 308, 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.

[0043] At step 310, 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. [0044] In accordance with one embodiment of the invention, the picture start codes may be split across two non-contiguous data streams and across two non-contiguous data segments. In this case, 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.

[0045] At step 312, 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. In accordance with one embodiment of the invention, a new GoP start code indicates the end of the last GoP. [0047] If it is determined that the current GoP has not ended, then step 310 is again performed. In other words, another picture code is detected and the entire method, as stated above, is repeated. In accordance with one embodiment of the invention, if it is determined that the current GoP has ended, then 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. At step 412, the method for managing a data stream in the communication network is terminated. CML07197

[0048] 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. Those skilled in the art will appreciate that 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.

[0049] As shown in FIG. 5, 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. As already mentioned in conjunction with previous figures, 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. For example, a data segment may be an I-frame, a P-frame or a B-frame of a GoP or an audio frame. [0050] Typically, the receiver 504 determines that a new GoP is received by determining a GoP start code of the GoP. As already mentioned, a GoP start code indicates the start of the GoP and is usually the first four bytes of the received GoP. After the receiver 504 receives the 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. As already explained in conjunction with FIG. 2, 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. CML07197

[0051] When 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.

[0052] 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. As already mentioned, 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. The process of dropping the data segments has already been explained in conjunction with FIG. 2. [0053] When the processor 506 forwards data segment to the re-packetizer 508, 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. In accordance with one embodiment of the invention, 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.

[0054] 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. [0055] 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. CML07197

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.

[0056] In accordance with one embodiment of the invention, when a data stream is received, 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.

[0057] As shown in the figure, 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.

[0058] 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. To describe the method illustrated in FIGs. 7 and 8, 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.

[0059] At step 702, the method for storing information during the processing of a data stream is initiated. At step 704, 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. At step 706, 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. At step 708, it is checked whether the current data segment is an I-frame. CML07197

[0060] If the current data segment is determined to be an I-frame, then at step 710, the state variable that stores the current frame state is set to I-frame. After the state variable 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.

[0061] If the current data segment is not an I-frame, then at 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.

[0062] If, at step 714, it is determined that the current data segment is not a P-frame, then at 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.

[0063] From step 712, the flow diagram proceeds to step 802, where 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.

[0064] Various embodiments, as describes above, 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.

[0065] It will be appreciated that 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. Alternatively, 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. In situations for which functions of the embodiments of the invention can be implemented using a processor and stored program instructions, it will be appreciated that 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. Further, it is expected that a person of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein, will be readily capable of generating such stored program instructions and ICs with minimal experimentation.

[0066] In the foregoing specification, the invention and its benefits and advantages have been described with reference to specific embodiments. However, persons with ordinary skill in the art would appreciate that various modifications and changes can be made, without departing from the scope of the present invention, as set forth in the claims below. Accordingly, the specification and the figures are to be regarded in an CML07197 illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage or solution to occur or become more pronounced are not to be construed as critical, required or essential features or elements of any or all the claims. The invention is defined solely by the appended claims, including any amendments made during the pendency of this application, and all equivalents of those claims, as issued.

[0067] The Abstract of the Disclosure is provided to comply with 37 CF. R. § 1.72(b), requiring an abstract that will enable the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Therefore, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.

Claims

CML07197 What is claimed is:

1. A method for managing a data stream in a communication network, the method comprising: receiving a packetized data stream comprising one or more data segments, wherein each data segment of the one or more data segments corresponds to a frame type of a plurality of frame types; 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; dropping at least one data segment for at least one frame type of the plurality of frame types based on: a 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; and re-packetizing the received packetized data stream based on the dropping of the at least one data segment.

2. The method as recited in claim 1, wherein the at least one predefined parameter is based on one or more of: an available bandwidth for transmission of the data stream in the communication network; a type of the received packetized data stream; and a number of data segments for each frame type received in a previous data stream.

3. The method as recited in claim 1, wherein the packetized data stream is a Group of Pictures (GOP) in at least one of a Motion Picture Experts Group-2 (MPEG-2) and a Motion Picture Experts Group-4 (MPEG-4) transport stream. CML07197

4. The method as recited in claim 1, wherein the functional dependency between the one or more data segments and the plurality of frame types is based on at least one of a Motion Pictures Experts Group-2 (MPEG-2) and a Motion Pictures Experts Group-4 (MPEG-4) video semantics.

5. The method as recited in claim 1 further comprising identifying a frame type of a data segment before dropping the data segment.

6. The method as recited in claim 5, wherein the frame type is identified across at least one of non-contiguous data segments and non-contiguous data streams.

7. The method as recited in claim 1 further comprising storing at least one of 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.

8. A system for managing a data stream in a communication network, the system comprising: a receiver configured to receive a packetized data stream comprising one or more data segments, wherein each data segment of the one or more data segments corresponds to a frame type of a plurality of frame types; a processor 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; drop at least one data segment for at least one frame type of the plurality of frame types based on: a number of data segments to be transmitted for each frame type; a functional dependency between the one or more data segments; and CML07197 a functional dependency between the plurality of frame types; and a re-packetizer configured to re-packetize the received packetized data stream based on the dropping of the at least one data segment.

9. The system as recited in claim 8, wherein the at least one predefined parameter is based on one or more of: an available bandwidth for a transmission of the data stream in the communication network; a type of the received packetized data stream; and a number of data segments for each frame type received in a previous data stream.

10. The system as recited in claim 8, wherein the packetized data stream is a Group of Pictures (GOP) in at least one of a Motion Picture Experts Group-2 (MPEG-2) and a Motion Picture Experts Group-4 (MPEG-4) transport stream.

11. The system as recited in claim 8 further comprising a memory to store at least one of 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.

12. The system as recited in claim 8, wherein the functional dependency is based on at least one of a Motion Pictures Experts Group-2 (MPEG-2) and a Motion Pictures Experts Group-4 (MPEG-4) video semantics.

13. The system as recited in claim 8, wherein the processor is further configured to identify a frame type of a data segment before dropping the data segment.