US9516330B2 - Virtual field buffer based decoding - Google Patents
Virtual field buffer based decoding Download PDFInfo
- Publication number
- US9516330B2 US9516330B2 US13/782,425 US201313782425A US9516330B2 US 9516330 B2 US9516330 B2 US 9516330B2 US 201313782425 A US201313782425 A US 201313782425A US 9516330 B2 US9516330 B2 US 9516330B2
- Authority
- US
- United States
- Prior art keywords
- field
- picture
- frame
- virtual
- buffer
- 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.)
- Active, expires
Links
- 239000000872 buffer Substances 0.000 title claims abstract description 187
- 238000000034 method Methods 0.000 claims description 144
- 230000000694 effects Effects 0.000 claims description 4
- 230000008569 process Effects 0.000 description 107
- 230000000295 complement effect Effects 0.000 description 20
- 230000006835 compression Effects 0.000 description 12
- 238000007906 compression Methods 0.000 description 12
- 230000000750 progressive effect Effects 0.000 description 10
- 238000012545 processing Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 101150098958 CMD1 gene Proteins 0.000 description 3
- 101100382321 Caenorhabditis elegans cal-1 gene Proteins 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000003139 buffering effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 230000002123 temporal effect Effects 0.000 description 2
- 230000001174 ascending effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Images
Classifications
-
- 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/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
- H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
-
- 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/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
-
- 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/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
- H04N19/16—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter for a given display mode, e.g. for interlaced or progressive display mode
Definitions
- Video compression techniques generally rely on data coding to reduce an amount of data in a video bitstream by removing redundancy in the video bitstream. Some compression techniques rely upon spatial and temporal compression and compensation.
- video signals are commonly composed as either progressive or interlaced scan signals.
- Interlaced signals have been relied upon for some time and were the primary means for transmitting signals to analog televisions.
- An interlaced frame comprises two fields in a sequence, each sequentially scanned at odd and even lines of an image sensor.
- HEVC High Efficiency Video Coding
- ITU International Telecommunication Union
- MPEG Moving Picture Experts Group
- FIG. 1 illustrates an example virtual field buffer decoder according to various embodiments described herein.
- FIG. 2A illustrates various data metrics stored in and accounted for by a virtual field decoded picture buffer manager of the decoder of FIG. 1 .
- FIG. 2B illustrates various data metrics stored in and accounted for by a virtual display queue of the decoder of FIG. 1 .
- FIG. 2C illustrates various data metrics stored in and accounted for by a picture command queue of the decoder of FIG. 1 .
- FIG. 3A illustrates example complementary field sequences, in output and decoding sequence orders, according to various embodiments described herein.
- FIG. 3B illustrates an example picture sequence with example decoding order, example picture output order, and example reference picture sets.
- FIG. 4A illustrates an example process flow of a virtual field buffer based decoding process performed by the decoder of FIG. 1 according to an example embodiment.
- FIG. 4B further illustrates the example process flow of the virtual field buffer based decoding process performed by the decoder of FIG. 1 according to an example embodiment.
- FIG. 4C illustrates example field and frame map assignments determined by the process illustrated in FIGS. 4A and 4B , for the example picture sequence illustrated in FIG. 3B .
- FIG. 5A further illustrates the example process flow of the virtual field buffer based decoding process performed by the decoder of FIG. 1 according to an example embodiment.
- FIG. 5B illustrates example frame map assignments determined by the process illustrated in FIG. 5A , for the example picture sequence illustrated in FIG. 3B .
- FIG. 6 illustrates an example process flow of a display output process performed by the decoder of FIG. 1 according to an example embodiment.
- FIG. 7 illustrates an example virtual field buffer decoder that incorporates a unified decoded picture buffer according to another embodiment described herein.
- FIG. 8 illustrates elements of a stream analyzer and a virtual field DPB manager of the virtual field buffer decoder of FIG. 7 , with example working field values according one embodiment described herein.
- FIG. 9A illustrates an example field IBBP GOP structure sequence for the decoder of FIG. 7 according to an example embodiment.
- FIG. 9B illustrates an example decoding process for the IBBP GOP structure sequence of FIG. 9A , performed by the decoder of FIG. 7 , according to an example embodiment.
- FIG. 10 illustrates an example process flow of a virtual field buffer based decoding process performed by the decoder of FIG. 7 according to an example embodiment.
- FIG. 11 illustrates an example schematic block diagram of a computing device that may be employed by decoders of various embodiments described herein.
- Video compression techniques generally rely on data coding to reduce an amount of data in a video bitstream by removing redundancy in the video bitstream. Some compression techniques rely upon spatial and temporal compression and compensation. Some video compression techniques rely upon lossy compression algorithms. In such a case, the original video bitstream cannot be reconstructed entirely when decoded. In return, the lossy MPEG-4 compression standard, for example, may reduce a volume of video data by a significant factor. It is noted that most lossy compression standards require a tradeoff between video quality and processing requirements.
- video signals are commonly composed as either progressive or interlaced scan signals, although progressive scan signals are becoming more common.
- Interlaced signals have been relied upon for some time and were the primary means for transmitting signals to analog televisions.
- An Interlaced frame comprises two fields in a sequence, each sequentially scanned at odd and even lines of an image sensor, for example.
- progressive signals send an entire frame at once, while interlaced signals send a first half of an image and, afterwards, a second half of the image.
- every other line of an image is scanned when the first half is transmitted, and the remaining lines are scanned when the second half is transmitted.
- Each half of an interlaced image is typically referred to as a field.
- Interlaced signals are commonly used in standard (i.e., analog) television and 1080i broadcasts.
- interlaced signals must be reproduced in an interlaced format to avoid the generation of video artifacts.
- movement artifacts may be generated.
- deinterlacing can reduce artifacts associated with the change in formats. To perform deinterlacing, two corresponding fields need to be combined into a single frame.
- High Efficiency Video Coding is being considered as a new video coding standard of the International Telecommunication Union (ITU) Video Coding Experts Group and the Moving Picture Experts Group (MPEG).
- ITU International Telecommunication Union
- MPEG Moving Picture Experts Group
- HEVC seeks to improve compression performance by about 50% as compared to current standards.
- the HEVC coding technique is generally expected to be used for coding progressive scan imagery, because interlaced scanning is not used in new displays. Thus, interlaced scanning is becoming less common as a means for distribution. As such, the HEVC coding technique does not include any explicit coding features to support interlaced scan imagery. Still, HEVC provides a metadata syntax to indicate whether interlaced scan video has been coded. If interlaced scan video has been coded, each picture may be coded as an HEVC coded picture field having a field polarity. In this manner, interlaced video coding can be supported by HEVC coders and decoders without any specific HEVC decoding processes. In certain aspects, however, new techniques must be employed to further support interlaced video coding and decoding when relying upon the HEVC standard.
- a current picture field is read from a coded picture buffer comprising coded pictures of video, for example.
- the current picture may be associated with a top or bottom field polarity.
- the current picture field is assigned to an available field entry of a virtual field buffer, and an available frame index of a virtual frame map is assigned to the current picture field.
- the assignment of the available frame index to the current picture field is indicated to a decoder that decodes the current picture field with reference to the assigned frame index.
- the assignment of complimentary picture fields to frames before decoding provides certain efficiencies and further supports interlaced video coding and decoding when relying upon certain standards such as HEVC.
- FIG. 1 illustrates an example virtual field buffer decoder 10 according to various embodiments described herein.
- the virtual field buffer decoder 10 comprises a coded picture buffer 110 , a picture command generator 112 , a picture command queue 114 , a decoder 116 , a frame-based decoded picture buffer (DPB) 118 , a display queue 120 , and a display 122 .
- the virtual field buffer decoder 10 may comprise an element of a larger video communication system. Generally, in such a video communication system, pictures or images are captured for transmission as a video sequence. The pictures are encoded, encapsulated into packets according to a transmission protocol, and sent to a receiver through a transmission channel. At the receiver, the received packets are decapsulated, and the coded pictures are stored in a buffer for decoding and display.
- a received coded bitstream is stored in the coded picture buffer 110 , as illustrated in FIG. 1 .
- the coded bitstream of FIG. 1 comprises a video bitstream encoded by the HEVC standard (i.e., H.265). In various embodiments, however, the coded bitstream may be encoded by other encoding formats or standards.
- the coded picture buffer 110 stores the coded video bitstream for further processing by the picture command generator 112 and the decoder 116 .
- the coded video bitstream may comprise coded picture fields, where each picture field comprises or is associated with a field polarity.
- picture frames may be composed from certain pairs of the picture fields stored in the coded picture buffer.
- the picture command generator 112 determines the pairs, as described below.
- the picture command generator 112 maintains virtual field and frame maps, and generates picture commands for the picture command queue 114 .
- the virtual field and frame maps are relied upon by the picture command generator 112 to determine complementary pairs of picture fields for picture frames.
- the decoder 116 retrieves coded picture fields from the coded picture buffer 110 , decodes them, and stores them in the frame-based DPB 118 .
- the frame-based DPB 118 stores decoded pictures. It is noted that, in various embodiments, the frame-based DPB 118 stores pairs of decoded picture fields, in association with each other, as picture frames. In certain embodiments, the frame-based DPB 118 may store decoded frames, where each frame comprises a combination of picture fields.
- the display queue 120 stores references to pictures frames (e.g., Frame 0 , Frame 1 , Frame 2 , . . . , and Frame N, etc.) for output by the display 122 .
- the references stored in the display queue 120 may refer to storage locations in the frame-based DPB 118 .
- the display 122 retrieves and displays picture frames from the frame-based DPB 118 .
- the picture command generator 112 comprises a syntax decoder 200 , a virtual field DPB manager 210 , a picture command manager 220 , and a virtual display queue 230 .
- the syntax decoder 200 accesses the coded picture buffer 110 and parses header and/or syntax layer elements of one or more pictures of the coded picture bitstream.
- the syntax decoder 200 may ascertain or determine one or more of the following: the start and end of coded video slices; a picture order count (POC) of a sequence of pictures; a sequence of pictures for output; a decoding order of a sequence of pictures; a first field (i.e., top or bottom field polarity) in output order; the identification of reference and non-reference pictures; instantaneous decoding refresh (IDR) pictures; system timestamps; and a size of a decoding buffer required for decoding (e.g., a maximum decoded picture buffer size, maxDPBSize).
- the syntax decoder 200 may ascertain or determine other header and/or syntax layer elements.
- the virtual field DPB manager 210 maintains virtual field and frame maps 212 and 214 , as illustrated in FIG. 1 .
- the virtual field map 212 refers to fields of the virtual display queue 230 , in various embodiments, as further described below.
- the virtual field DPB manager 210 assigns picture fields stored in the coded picture buffer 110 to available field entries of the virtual field map 212 and/or the virtual display queue 230 . Further, the virtual field DPB manager 210 assigns available frame indexes of the virtual frame map 214 to assigned picture fields of the virtual field map 212 and/or the virtual display queue 230 .
- the virtual field map 212 and virtual display queue 230 may include field information for several fields (e.g., Field 0 , Field 1 , Field 2 , . . . , Field N, etc.).
- the virtual frame map 214 may include frame information for several frames.
- the size of one or more of the virtual field map 212 , the virtual display queue 230 , and the virtual frame map 214 may depend, in part, on the maximum decoded picture buffer size maxDPBSize.
- the virtual field and frame maps 212 and 214 and the virtual display queue 230 are relied upon by the picture command generator 112 as a type of memory scratch space for determining an assignment of interlaced scan imagery fields to frames, in connection with the decoding of those fields by the decoder 116 .
- complementary picture fields are generally paired before being displayed.
- the pairing of complementary picture fields to picture frames is performed at the direction of the picture command generator 112 .
- the pairing of complementary picture fields to frames before decoding may be more efficient in certain aspects than pairing complementary picture fields to frames after decoding.
- pairing before decoding may be more efficient because more coded-bitstream information is generally available before decoding than after decoding.
- the pairing of complementary picture fields to frames before decoding allows the reuse of circuitry designed for frame-based or progressive scan imagery.
- the reuse of certain frame-based decoding circuitry and/or buffers may be achieved—even when operating with coded interlaced scan imagery.
- the picture command manager 220 generates picture commands for processing by the decoder 116 .
- the picture commands are stored in the picture command queue 114 , and it is noted that several picture commands (e.g., CMD 0 , CMD 1 , CMD 2 , . . . , and CMD N, etc.) may be stored in the queue 114 .
- the decoder 116 examines the picture commands stored in the picture command queue 114 , to determine which coded picture fields have been assigned to virtual frames by the picture command generator 112 . In other words, before decoding picture fields, the decoder 116 references field-to-frame pairings identified by the picture command generator 112 .
- the decoder 116 may output decoded picture fields in terms of complimentary fields or frames for storage.
- complimentary fields may be stored in the frame-based DPB 118 in association with each other, for example, or in the form of a combination of fields.
- the virtual field map 212 of the virtual field DPB manager 210 maintains, for each field Field 0 , Field 1 , Field 2 , . . . , and Field N of the virtual display queue 230 , an entry available flag, a corresponding frame DPB index (FrameIDX), a reference picture flag, and reference picture data.
- the data metrics and fields described above as being stored by the field map 212 are provided by way of example only and should not be considered limiting, as additional or fewer data metrics or fields may be stored by the virtual field map 212 .
- the virtual frame map 214 of the virtual field DPB manager 210 maintains, for each frame in sequence of pictures, a FrameIDX and corresponding address for the FrameIDX in the frame-based DPB 118 .
- the data fields described above as being stored by the virtual frame map 214 are provided by way of example only and should not be considered limiting, as additional or fewer data metrics or fields be stored by the virtual frame map 214 .
- the virtual field DPB manager 210 also maintains counters of unpaired field pictures. In one embodiment, the virtual field DPB manager 210 maintains a counter of unpaired pictures of a first or top polarity and a counter of unpaired pictures of a second or bottom polarity. Additionally, the virtual field DPB manager 210 maintains a picture order count and decoding order for a slice of pictures in the coded picture buffer 110 , as described in further detail below.
- FIG. 2B illustrates various data metrics stored in and accounted for by the virtual display queue 230 of the decoder 10 of FIG. 1 .
- the virtual field DPB manager 210 maintains, for each field Field 0 , Field 1 , Field 2 , . . . , and Field N in the virtual display queue 230 , a field polarity, a corresponding FrameIDX, a needed for decoding flag, and a needed for output flag for the field.
- the picture fields Field 0 , Field 1 , Field 2 , . . . , and Field N in the virtual display queue 230 are stored or ordered in the picture output order, as further described below.
- the data metrics and fields described above as being stored by the virtual display queue 230 are provided by way of example only and should not be considered limiting, as additional or fewer data metrics or fields may be stored by the virtual display queue 230 .
- FIG. 2C illustrates various data metrics stored in and accounted for by the picture command queue 114 of the decoder 10 of FIG. 1 .
- the picture command queue 114 maintains, for each picture command CMD 0 , CMD 1 , CMD 2 , . . . , and CMD N, picture and/or slice header data, picture and/or slice address data, a reference picture list, a field polarity, and a FrameIDX for the command.
- the data described above as being stored for each command is provided by way of example only and should not be considered limiting, as additional or fewer data metrics may be stored by the picture command queue 114 .
- FIG. 3A illustrates example complementary field sequences 30 and 32 in output and decoding sequence orders, respectively, according to various embodiments described herein.
- the field sequence 30 represents an example sequence of picture fields in order for output.
- the sequence comprises a top picture field T 0 and a bottom picture field B 0 , among other picture fields.
- the fields T 0 and T 1 may be output together as a frame by the display 122 .
- the fields in the sequence 30 have been encoded using a coding scheme that does not rely upon any particular specification or syntax for interlaced imagery.
- each field is treated as a full frame or picture for decoding—without any particular processing for interlaced imagery.
- the fields in the field sequence 30 may be stored in the coded picture buffer 110 in various orders, based upon a received packet sequence or other factors, for example.
- the field sequence 32 is alternatively arranged or ordered for decoding. As illustrated, the field sequence 32 comprises the fields T 0 , T 4 , T 2 , and T 1 , in order, among other picture fields. It is noted that the difference between output and decoding orders may be attributable, in part, to the use of certain references pictures when encoding, as should be appreciated according to the specification of HEVC and other encoding techniques.
- FIG. 3B illustrates an example picture sequence 34 , example decoding order, example picture output order, and example reference picture sets.
- the picture sequence 34 comprises a picture sequence ordered in a display picture output order.
- Each picture in the picture sequence 34 may be identified by an index in the picture order count (POC).
- POC picture order count
- the POC and indexes of the POC may be determined by the syntax decoder 200 , based on syntax layer data in the coded picture buffer 110 .
- the decoding order comprises a series of picture indexes in an order for decoding.
- a picture is decoded with reference to its reference picture set (RPS).
- RPS reference picture set
- pictures 0 and 2 are reference pictures for decoding picture 1 .
- pictures 0 and 4 are reference pictures for decoding picture 2 .
- the picture order for decoding is picture 0 , picture 4 , picture 2 , picture 1 , and picture 3 , as illustrated.
- the syntax decoder 200 may determine which field polarity (e.g., top or bottom) is first in the display output order. In the case of the picture sequence 34 , top polarity fields are first for output.
- the decoder does not know which picture fields comprise complimentary fields of a frame.
- the coded bitstream does not include any data that identifies complimentary fields of a frame for interlaced imagery.
- the picture command generator 112 determines complimentary picture field pairs among picture sequences, such as the picture sequence 34 , before the picture sequences are decoded.
- FIGS. 4A, 4B, 5A, and 6 flowcharts illustrating example operations of the decoder 10 are provided.
- the flowcharts of FIGS. 4A, 4B, 5A, and 6 may be viewed as depicting example steps of a method of virtual field buffer based decoding 400 .
- FIGS. 4A, 4B, 5A, and 6 are described in connection with the decoder 10 of FIG. 1 , other decoders may operate according to the processes illustrated.
- FIGS. 4A, 4B, 5A, and 6 provide only examples of different functional or process arrangements that may be employed according to the embodiments described herein.
- FIG. 4A illustrates an example process flow of a virtual field buffer based decoding process 400 performed by the decoder 10 of FIG. 1 according to an example embodiment.
- FIG. 4A is first described with reference to the first picture field T 0 in the picture sequence 34 of FIG. 3B .
- the picture command generator 112 may be initialized in certain aspects.
- the initialization includes initializing the virtual field and frame maps 212 and 214 and, in some aspects and embodiments, the virtual display queue 230 and the picture command queue 114 .
- the associated frame index, FrameIDX, of each entry in the virtual field map 212 and/or the virtual display queue 230 is set to an unassigned value of “ ⁇ 1”.
- the counters of unpaired top and bottom field pictures are set to zero, the field entry available flags in the field map 212 are set to “true” (i.e., empty) values, the addresses of the frame map 214 are initialized, and all needed for decoding and needed for output flags are set to “true” values.
- the syntax decoder 200 of the picture command generator 112 reads a next picture field (as the current picture) from the coded picture buffer 110 .
- the next picture field may be read from the coded picture buffer 110 according to an order for decoding pictures stored within the coded picture buffer 110 .
- the syntax decoder 200 reads picture fields from the coded picture buffer 110 in the decoding order 0, 4, 2, 1, 3, with reference to the POC and display picture output order.
- the syntax decoder 200 reads the picture having the picture index 0 from the coded picture buffer 110 .
- the syntax decoder 200 parses a header of the current picture field. Additionally, at reference 406 , the syntax decoder 200 updates a state of the virtual field DPB manager 210 according to the header of the current picture field. For example, at references 404 and 406 , the syntax decoder 200 may determine a maximum size of a decoded picture buffer, reference pictures for the current picture field being decoded, and other information related to decoding.
- the virtual field DPB manager 210 determines whether the virtual field map 212 is full.
- the virtual field DPB manager 210 may determine whether the virtual field map 212 is full according to or based on syntax layer data associated with the coded bitstream stored in the coded data buffer 110 , for example.
- the virtual field DPB manager 210 may determine whether the virtual field map 212 is full based on the maximum decoded picture buffer size maxDPBSize. In this case, the virtual field DPB manager 210 determines at reference 408 whether the current picture field read from the coded picture buffer 110 fills or exceeds the maximum size, maxDPBSize, of a “virtual” decoded picture buffer.
- a full virtual field map signifies that frame pairs in the virtual field and frame maps 212 and 214 and the virtual display queue 230 may be refreshed, flushed, or bumped out according to the process illustrated in FIG. 5A , described below.
- the virtual field DPB manager 210 determines that the virtual field map 212 is full at reference numeral 408 , the process proceeds to reference numeral 428 of FIG. 5A , as described below.
- the process proceeds to reference numeral 410 , where the virtual field DPB manager 210 determines whether the current picture field is an instantaneous decoder refresh (IDR) picture.
- IDR pictures are generally found at the beginning of a sequence of coded pictures. An IDR picture can be decoded without decoding any previous pictures in a picture stream. Thus, an IDR picture signifies to the virtual field DPB manager 210 that the frame pairs in the virtual field and frame maps 212 and 214 may be refreshed, flushed, or bumped out according to the process steps illustrated in FIG. 5A .
- the virtual field DPB manager 210 determines that the current picture field is an IDR picture field at reference numeral 410 , then the process proceeds to reference numeral 428 of FIG. 5A , as described below.
- the process proceeds to reference numeral 412 .
- the virtual field DPB manager 210 assigns the current picture field to an available field entry in the virtual field map 212 and the virtual display queue 230 .
- the virtual field DPB manager 210 sets the needed for decoding flag of the current picture field to “true” in the virtual display queue 230 . Additional use of the decoding flag is described below with reference to FIG. 6 , for example.
- the picture field T 0 is initially read from the coded picture buffer 110 by the picture command generator 112 , according to the illustrated decoding order, at reference numeral 402 . Because the picture field T 0 is the first picture field in the picture sequence 34 and is not an IDR picture, the process proceeds to reference numeral 412 , where the picture field T 0 is assigned to an available field entry in the virtual field map 212 . For example, the picture field T 0 may be assigned to the available field entry “A” in the virtual field map 212 . Further, at reference numeral 414 , the needed for decoding flag of the picture field T 0 is set to “true” in the virtual display queue 230 .
- the virtual field DPB manager 210 determines the polarity of the current picture field and whether the counter of unpaired pictures of the opposite field polarity as the current picture field is non-zero. If the counter of unpaired pictures of the opposite field polarity as the current picture field is non-zero, the process proceeds to reference numeral 418 .
- the FrameIDX of the virtual field map entry assigned to the current picture at reference numeral 412 is not already initialized to the value of “ ⁇ 1”, the FrameIDX value for the current picture is set to “ ⁇ 1”.
- the assignment of “ ⁇ 1” to the FrameIDX value for the current picture specifies that the current picture is not assigned or paired to any particular frame index. Additionally, at reference numeral 420 , the counter of unpaired pictures of the opposite field polarity as the current picture is incremented.
- the process proceeds to reference numeral 422 .
- the virtual field DPB manager 210 determines that the polarity of the picture field T 0 is “top” at reference numeral 416 .
- the virtual field DPB manager 210 determines whether the counter of top field pictures is non-zero at reference numeral 416 . Because the picture command generator 112 was initialized before the process 400 began, the counter of top field pictures is determined to be zero at reference numeral 416 , and the process proceeds to reference numeral 422 .
- the virtual field DPB manager 210 assigns the current picture field to an available frame index of the virtual frame map 214 . That is, the FrameIDX of the field map entry assigned to the current picture field at reference numeral 412 is assigned to an available frame index at reference numeral 422 .
- the value of FrameIDX for T 0 may be assigned to any available frame index. As one example, the value of FrameIDX for the picture field T 0 may be assigned to frame index “1”.
- the value assigned to FrameIDX corresponds to an address location in the frame-based DPB 118 , and may be referenced by any pointer value corresponding to an address location in the frame-based DPB 118 . Additionally, at reference numeral 424 , the counter of unpaired pictures of the same field polarity as the picture field T 0 is incremented.
- a picture command for the current picture field is generated by the picture command manager 220 at reference numeral 426 .
- Each picture command generated by the picture command generator 220 comprises picture and/or slice header data, picture and/or slice address data, a reference picture list, a field polarity, and a FrameIDX for the current picture, as illustrated in FIG. 2C .
- the picture commands, after being generated, are loaded to the picture command queue 114 by the picture command manager 220 .
- the process 400 proceeds back to reference numeral 402 of FIG. 4A , where the next picture in the decoding order is read from the coded picture buffer 110 .
- FIG. 4C illustrates example virtual field and frame map assignments for the picture fields of the picture sequence 34 illustrated in FIG. 3B , as determined by the process 400 illustrated in FIGS. 4A and 4B .
- each picture field in the example picture sequence 34 is illustrated in the decoding order of FIG. 3B , from top to bottom.
- the picture field T 0 is assigned to the field entry “A” and the FrameIDX “1”.
- the picture fields T 2 , T 1 , B 0 , and B 1 are assigned field entries “B”, “C”, “D”, and “E”, respectively, at reference numeral 412 .
- the picture fields T 2 and T 1 are assigned FrameIDX values of “2” and “3”, respectively, at reference numeral 422 .
- the picture fields B 0 and B 1 are left with initialized or unassigned “ ⁇ 1” FrameIDX values. This is due to the fact that the virtual field DPB manager 210 determines that the counter of unpaired pictures of the opposite field polarity as the picture fields B 0 and B 1 is non-zero at reference numeral 416 of FIG. 4B . Particularly, the counter of unpaired pictures of the opposite field polarity as the picture fields B 0 and B 1 is non-zero because it was incremented at reference numeral 424 of FIG.
- the virtual field DPB manager 210 determines, at reference numeral 410 , that the next picture after the picture field B 1 is an IDR picture.
- the virtual field DPB manager 210 may determine that the virtual field map 212 is full at reference numeral 410 , based on the maximum decoded picture buffer size maxDPBSize, as described above. In either case, the process 400 proceeds to reference numeral 428 of FIG. 5A to refresh, flush, or bump out any complementary picture field pairs from the virtual field and frame maps 212 and 214 , according to the remaining elements of the process 400 illustrated in FIG. 5A .
- FIG. 5A further illustrates the example process flow of the virtual field buffer based decoding process 400 performed by the decoder 10 of FIG. 1 according to an example embodiment.
- the flow of the process illustrated in FIG. 5A is first described below without reference to any particular example sequence of pictures. Afterwards, the flow of the process illustrated in FIG. 5A is described in the context of the example picture sequence 34 of FIG. 3B , with reference to FIG. 5B .
- the virtual field DPB manager 210 selects, in the picture output order of the example picture sequence 34 of FIG. 3B , a next picture field (as the instant picture) from the virtual field map 212 .
- the virtual field DPB manager 210 determines at reference numeral 430 whether the FrameIDX of the instant picture field is unassigned or “ ⁇ 1”. If the FrameIDX of the instant picture field is assigned, then the process proceeds back to reference numeral 428 to select the next picture field from the virtual field map 212 in the picture output order. Alternatively, if the FrameIDX of the instant picture field is determined to be unassigned at reference numeral 430 , the process proceeds to reference numeral 432 .
- the virtual field DPB manager 210 determines whether the field polarity of the instant picture field is first in the output order.
- the syntax decoder 200 may determine which field polarity (e.g., top or bottom) is first in the picture display output order, according to or based on syntax layer data associated with the coded bitstream stored in the coded data buffer 110 , for example. If the field polarity of the instant picture field is first in the output order, then the process 400 proceeds to reference numeral 434 . Alternatively, if the field polarity of the instant picture field is not first in the output order, the process 400 proceeds to reference numeral 438 .
- the virtual field DPB manager 210 determines whether the field polarity of the previous picture field in the output order was first in the output order. If the field polarity of the previous picture field was first in the output order, then the process 400 proceeds to reference numeral 436 . Alternatively, if the field polarity of the previous picture field was not first in the output order, the process 400 proceeds back to reference numeral 428 . At reference numeral 436 , the virtual field DPB manager 210 assigns an available FrameIDX of the virtual frame map 214 to the previous picture field in the picture output order.
- the virtual field DPB manager 210 has determined that the previous picture field was a dangling picture field in the output order.
- a dangling picture field is one that has no complimentary picture field for a frame. That is, some picture fields stored in the coded picture buffer 110 may not have a complimentary picture field for frame pairing. In that case, the process 400 identifies these fields and assigns them to available frame entries.
- the process 400 proceeds to reference numeral 437 , where the virtual field DPB manager 210 decrements the counter of unpaired pictures of the same polarity as the previous picture in the output order, and the process 400 proceeds back to reference numeral 428 .
- the process 400 proceeds to reference numeral 438 .
- the virtual field DPB manager 210 determines whether the field polarity of the previous picture field in the output order was first in the output order. If the field polarity of the previous picture field was first in the output order, the process 400 proceeds to reference numeral 442 . Alternatively, if the field polarity of the previous picture field was not first in the output order, the process 400 proceeds to reference numeral 440 .
- the virtual field DPB manager 210 assigns an available FrameIDX of the virtual frame map 214 to the instant picture field in the picture output order.
- the virtual field DPB manager 210 has determined that the instant picture field is a dangling picture field in the output order. After reference numeral 440 , the process 400 proceeds to reference numeral 441 , where the virtual field DPB manager 210 decrements the counter of unpaired pictures of the same polarity as the instant picture, and the process 400 proceeds back to reference numeral 428 .
- the process 400 proceeds to reference numeral 442 .
- the virtual field manager 210 determines whether the FrameIDX of the previous picture field in the output order was unassigned or “ ⁇ 1”. If the FrameIDX of the previous picture field was assigned, the process 400 proceeds to reference numeral 444 . Alternatively, if the FrameIDX of the previous picture field was unassigned, the process 400 proceeds to reference numeral 448 .
- the virtual field DPB manager 210 assigns the FrameIDX of the instant picture field to the FrameIDX value of the previous picture in the picture output order. Further, at reference numeral 446 , the virtual field DPB manager 210 decrements the unpaired picture counter of the same polarity as the instant picture. At reference numeral 448 , the virtual field DPB manager 210 assigns the FrameIDX of the previous and instant picture fields to respective available FrameIDX values of the virtual frame map 214 . Further, at reference numeral 450 , the virtual field DPB manager 210 decrements both the top and bottom unpaired picture counters. After either reference numerals 450 or 446 , the process proceeds back to reference numeral 428 .
- any unassigned FrameIDX values will be assigned.
- the process 400 may proceed, in some embodiments, back to the process flow of FIGS. 4A and 4B , to begin assigning virtual field and frame values for other pictures stored in the coded data buffer 110 .
- some values in the virtual field and frame maps 212 and 214 may be initialized again before being associated with new pictures.
- the decoder 116 continues to decode picture fields based on picture commands in the picture command queue 114 , as further described below.
- the flow of the process elements illustrated in FIG. 5A is described in connection with the example picture sequence 34 of FIG. 3B , with reference to FIG. 5B .
- the first picture in the picture output order is picture field T 0 .
- the virtual field DPB manager 210 determines that the FrameIDX of the picture field T 0 is assigned to “1”. As such, the process 400 returns to reference numeral 428 to select the next picture field from the virtual field map 212 . Following the picture output order illustrated in FIG. 5B , the next picture is picture field B 0 .
- the virtual field DPB manager 210 determines that the FrameIDX of the picture field B 0 is unassigned or “ ⁇ 1”. The process 400 then proceeds to reference numeral 432 , where the virtual field DPB manager 210 determines that the field polarity of the picture field B 0 is not first in the output order, because top field polarity is first in the example picture sequence 34 . Thus, the process 400 proceeds to reference numeral 438 , where the virtual field DPB manager 210 determines whether the field polarity of the previous picture field, T 0 , was first in the output order. Because the field polarity of the picture field T 0 , as a top polarity field, is first in the output order, the process 400 proceeds to reference numeral 442 .
- the virtual field DPB manager 210 determines whether the FrameIDX of the previous picture T 0 was unassigned or “ ⁇ 1”. In this case, the FrameIDX of the previous picture T 0 is assigned to “1”, as illustrated in FIG. 5B . Thus, the process 400 proceeds to reference numeral 444 .
- the virtual field DPB manager 210 assigns the FrameIDX of the picture field B 0 to the FrameIDX value of the previous picture, T 0 , in the picture output order. That is, the virtual field DPB manager 210 assigns the FrameIDX of the picture field B 0 to the FrameIDX value “1”, because “1” is the FrameIDX value of the previous picture field T 0 .
- the virtual field DPB manager 210 decrements the unpaired picture counter of bottom pictures.
- the process 400 proceeds back to reference numeral 428 of FIG. 5A , where the next picture field in the picture output order, T 1 , is selected. Because the FrameIDX of the picture field T 1 is determined to be assigned at reference numeral 430 , the process 400 then selects B 1 as the next picture field in the picture output order.
- the assignment of the FrameIDX of the picture field B 1 follows a similar path in FIG. 5A as compared to the picture field B 0 described above.
- the virtual field DPB manager 210 assigns the FrameIDX of the picture field B 1 to the FrameIDX value of the previous picture, T 1 , in the picture output order. That is, the virtual field DPB manager 210 assigns the FrameIDX of the picture field B 1 to the FrameIDX value “3”, because “3” is the FrameIDX value of the previous picture field T 1 .
- picture fields T 0 and B 0 have been assigned to the same FrameIDX value of “1” and the picture fields T 1 and B 1 have been assigned to the same FrameIDX value of “3”.
- picture fields T 0 and B 0 have been identified as a pair of complimentary fields
- the picture fields T 1 and B 1 have been identified as a pair of complimentary fields.
- Each of the pairs may be output as a frame on the display 122 , for example, as a progressive scan image in connection with a deinterlacing operation, for example.
- the decoder 116 may proceed to decode the picture fields B 0 and B 1 , and store the picture fields T 0 and B 0 and T 1 and B 1 in the frame-based DPB 118 .
- the decoder 116 decodes any picture having a picture command associated with an assigned FrameIDX value.
- the decoder 116 selects one of the picture commands CMD 0 , CMD 1 , CMD 2 , . . . , and CMD N, etc. from the picture command queue 114 .
- the picture commands may be selected by the decoder 116 in the sequence the commands were generated by the picture command manager 220 , for example, or in any other suitable sequence.
- the decoder 116 first determines if the FrameIDX value of the selected picture command is assigned. That is, because each picture command is assigned or associated with a field of the virtual field map 212 and the virtual display queue 230 , the decoder 116 determines whether the FrameIDX of that picture field has been assigned to a frame index value.
- the decoder decodes the picture field associated with the selected picture command, according to the addressing and other parameters of the picture command.
- the needed for decoding flag of the decoded picture field is set to “false” in the virtual field map 212 and the virtual display queue 230 .
- the needed for decoding flags are relied upon by the display output process 600 of FIG. 6 , described below.
- FIG. 6 an example process flow of a display output process 600 performed by the decoder 10 of FIG. 1 is illustrated according to an example embodiment.
- the process 600 is relied upon by the decoder 10 to output complimentary pairs of picture fields that have been identified as being associated with a same picture frame.
- the virtual field DPB manager 210 outputs complimentary picture fields from the virtual display queue 230 to the display queue 120 .
- the display queue 120 stores references to picture frames for output by the display 122 .
- the references stored in the display queue 120 may refer to storage locations in the frame-based DPB 118 .
- the display 122 retrieves and displays picture frames from the frame-based DPB 118 .
- the process 600 may be invoked or started at various points in the flow of the process 400 , or at other suitable times, as determined by the decoder 10 .
- the process 600 may be invoked or started each time a picture field stored in the coded picture buffer 110 is decoded by the decoder 116 .
- the process 600 may be invoked or started each time the virtual display queue 230 is loaded with another picture field in the picture output order.
- the virtual field DPB manager 210 selects the next picture from the virtual display queue 230 .
- the picture fields Field 0 , Field 1 , Field 2 , . . . , and Field N in the virtual display queue 230 are stored or ordered in the picture output order by the virtual field DPB manager 210 .
- the virtual field DPB manager 210 determines whether the needed for decoding flag of the selected picture is “false”. In other words, the virtual field DPB manager 210 determines whether picture field selected at reference numeral 602 has been decoded by the decoder 116 . If not, the process ends. On other hand, if the picture field selected at reference numeral 602 has been decoded, the process 600 proceeds to reference numeral 606 .
- the virtual field DPB manager 210 determines whether the field polarity of the selected picture field is first in the picture output order. As described above, the syntax decoder 200 may determine which field polarity (e.g., top or bottom) is first in output order according to or based on syntax layer data associated with the coded bitstream stored in the coded data buffer 110 , for example. If the field polarity of the selected picture field is not first in the picture output order, the process 600 proceeds to reference numeral 610 . At reference numeral 610 , the picture field selected at reference numeral 602 is output to the display queue 120 as a dangling field. In other words, the picture field selected at reference numeral 602 is one that has no complimentary picture field for a frame.
- the syntax decoder 200 may determine which field polarity (e.g., top or bottom) is first in output order according to or based on syntax layer data associated with the coded bitstream stored in the coded data buffer 110 , for example. If the field polarity of the selected picture field is
- the process 600 proceeds to reference numeral 608 .
- the virtual field DPB manager 210 selects the next picture in the picture output order from the virtual display queue 230 .
- the virtual field DPB manager 210 determines whether the needed for decoding flag of the selected picture is “false”. In other words, the virtual field DPB manager 210 determines whether picture field selected at reference numeral 608 has been decoded by the decoder 116 . If not, the process ends. On other hand, if the picture field selected at reference numeral 608 has been decoded, the process 600 proceeds to reference numeral 614 .
- the virtual field DPB manager 210 determines whether field polarity of the selected picture field is second in the picture output order. If the field polarity of the selected picture field is not second in the picture output order, the process 600 proceeds to reference numeral 618 .
- the previous picture field i.e., the picture field previously selected at reference numeral 602
- the display queue 120 is a dangling field.
- the picture field selected at reference numeral 602 is one that has no complimentary picture field for a frame.
- the process 600 proceeds to reference numeral 616 .
- the virtual field DPB manager 210 outputs the picture fields selected at reference numerals 602 and 608 to the display queue 120 as a complimentary field pair.
- the process 600 proceeds back to reference numeral 602 to determine whether additional fields are available in the virtual display queue.
- complimentary picture fields identified by the picture command generator 112 are output in terms of frame pairs to the display queue 120 , after they have been decoded by the decoder 116 .
- the picture command generator 112 operates as a type of virtual decoded picture buffer, by assigning picture fields to frames and ordering the picture fields and frames into the picture output order, while the decoder 116 works to decode the picture fields from the coded picture buffer.
- the assignment of complimentary picture fields to frames before and/or during decoding provides certain efficiencies and further supports interlaced video coding and decoding when relying upon certain standards such as HEVC.
- FIG. 7 illustrates an example virtual field buffer decoder 70 that incorporates a unified DPB.
- the virtual field buffer decoder 70 is based on a unified DPB and comprises a coded picture buffer 710 , a stream analyzer 720 , a virtual field DPB manager 730 , a decoder 740 , a unified frame-based DPB 750 , and a display 760 .
- the stream analyzer 720 comprises a reordering buffer 722 , a pairing buffer 724 , and a working queue 726 .
- the virtual field DPB manager 730 comprises a virtual field DPB 732 and a frame DPB map 734 .
- the virtual field buffer decoder 70 pairs fields before decoding and stores decoded field pairs (i.e., as frames) in the unified frame-based DPB 750 .
- the unified frame-based DPB 750 is similar to a DPB in an MPEG-4 AVC/H.264 decoder that contains frame buffers.
- two decoded complementary field pictures are stored together in the unified frame-based DPB 750 .
- the stream analyzer 720 performs a process to pair picture fields and allocate frame buffers of the unified frame-based DPB 750 to store decoded pictures in pairs.
- FIG. 8 illustrates the elements of the stream analyzer 720 and the virtual field DPB manager 730 of FIG. 7 , with example working field values according one embodiment described herein.
- the stream analyzer 720 scans the coded bitstream in the coded picture buffer 710 , detects complementary field pairs, assigns a frame number to the complementary field pairs, and sends field entries to the decoder 740 for decoding.
- the stream analyzer 720 maintains the reordering buffer 722 , the pairing buffer 724 , and the working queue 726 .
- the sizes of the reordering buffer 722 , the pairing buffer 724 , and the working queue 726 illustrated in FIG. 8 are provided by way of example only and may vary among embodiments depending upon parameters of a GOP or coded bitstream of pictures, for example.
- Tn represents a top field with POC n
- Bn represents a bottom field with POC n
- the bottom row of the working queue 726 is associated with assigned frame numbers
- “head” and “tail” ends of the working queue 726 are illustrated.
- each of the reordering buffer 722 , the pairing buffer 724 , and the working queue 726 includes a pointer to a field entry.
- Each field entry includes parameters such as a field parity flag, a POC, a frame number, and a starting address of a corresponding field in the coded picture buffer 710 , for example.
- the stream analyzer 720 When the stream analyzer 720 detects a new field in the coded picture buffer 710 , the stream analyzer 720 inserts a new field entry in both the reordering buffer 722 and the tail end of the working queue 726 .
- a field parity and POC number for the new detected field may be parsed from a slice header of the new field by the stream analyzer 720 and stored in the parameters for the field.
- the stream analyzer 720 uses the reordering buffer 722 to reorder fields from a decoding order of pictures in the coded picture buffer 710 to a picture output order for display to the display 760 ( FIG. 7 ). It may be assumed that all fields are to be output.
- HEVC provides a sequence layer parameter, max_num_reorder_pics, to indicate a maximum allowed number of pictures preceding any picture in decoding order and succeeding that picture in output order.
- the field with a lowest POC in the reordering buffer 722 is output from the reordering buffer 722 to the pairing buffer 724 when a new field is added to the reordering buffer 722 .
- the stream analyzer 720 uses the pairing buffer 724 to pair two complementary fields. When two fields are present in the pairing buffer 724 , these two fields are regarded as a complementary field pair. The stream analyzer 720 assigns a frame buffer index to either one or both of the two fields in the pairing buffer 724 , according to the rules described below, and the two fields may then be output from the pairing buffer 724 together.
- the working queue 726 is a first-in-first-out queue that tracks all fields to be decoded. Each time a frame number is assigned to a field in the working queue 726 or a field in the working queue 726 is decoded, the stream analyzer 720 checks the first field entry (i.e., at the head end) of the working queue 726 . If the first field entry at the head end of the working queue 726 contains a valid (e.g., assigned) frame number, the field associated with the entry will be removed from the working queue 726 and sent to the decoder 740 for decoding.
- Decoded complementary field pair pictures are stored into a frame buffer of the unified frame-based DPB 750 , in association with an assigned frame number for the complementary field pair.
- a frame number is assigned to a current field according to one or more rules of the stream analyzer 720 .
- the current field is considered to be a first field of a field pair in decoding order.
- a new frame number is assigned to the current field by the stream analyzer 720 .
- the virtual field DPB manager 730 receives field DPB operations from the decoder 740 and performs mapping operations to the unified frame DPB 750 .
- the virtual field DPB manager 730 maintains the virtual field DPB 732 and the frame DPB map 734 .
- the sizes of the virtual field DPB 732 and the frame DPB map 734 illustrated in FIG. 8 are provided by way of example only and may vary among embodiments depending upon parameters of a GOP or coded bitstream of pictures, for example.
- the bottom row of the virtual field DPB 732 and the top row of the frame DPB map 734 are associated with assigned frame numbers.
- each field entry is associated with or points to a frame buffer index (i.e., the assigned frame numbers) of the unified frame-based DPB 750 .
- the assigned frame numbers are also used as pointers for lookup in the frame DPB map 734 .
- each frame entry in the frame DPB map 734 includes, for example, an available flag, a frame number, a pair of field entries, and an address of a frame buffer.
- Each field entry includes a field parity flag, a POC, an output flag and a removed flag.
- three types of DPB operations including insertion, output, and removal operations are mapped from the virtual field DPB 732 to the unified frame-based DPB 750 through the frame DPB map 734 .
- a field is decoded by the decoder 740 , it is inserted into the virtual field DPB 732 .
- the current field is a complementary field of that frame entry and is associated with that frame entry.
- the current field is inserted into a new frame entry and the frame number of that frame entry is set equal to the frame number of the current field.
- the frame buffer index of the current field is set equal to the index of the frame entry.
- an output flag of the corresponding field entry in the frame DPB map 734 is set as “true”. If the output flag of its complementary field in the same frame entry is also “true”, then the field pair will be output together and sent to the display 760 .
- a removed flag of the frame DPB map 734 for the current field will be set as “true”. If the removed flag of the complementary field to the current field is also “true”, the frame entry will be emptied and the available flag is set to be “true”.
- fields may be decoded while frame numbers are assigned, although the assignment of frame numbers to respective fields by the stream analyzer 720 may require the detection and/or analysis of more than one field to detect the resulting frame pair.
- the stream analyzer 720 may look ahead to detect field pairs, and latency may be ignored in certain aspects.
- coded pictures may not be locally-stored in an entire sequence or group of pictures (GOP)
- the stream analyzer 720 may need to wait for several fields to arrive in the coded picture buffer 710 before resulting frame pairs can be detected.
- an increase in an initial buffering delay may occur for a decoding system.
- latency in the above-noted streaming mode is described below in connection with FIGS. 9A and 9B . The discussion starts with a latency analysis of an IBBP GOP structure of intra-coded I fields, and inter-coded B- and P-fields, and then suggests a more general case of latency for GOP structures.
- FIG. 9A illustrates an example field IBBP GOP structure sequence.
- the decoding order and picture type of each example field is also illustrated.
- one reference field is used for decoding.
- two reference fields are used for decoding.
- FIG. 9B illustrates an example decoding process for the IBBP GOP structure sequence of FIG. 9A , performed by the decoder 70 of FIG. 7 .
- the value of max_num_reorder_pics is equal to 1.
- T 0 the first field in the decoding order
- a frame number “ 0 ” is assigned to it as it arrives in the coded picture buffer 710 .
- T 0 enters the tail end of the reordering buffer 722 and is sent to the decoder 740 .
- the second field in the decoding order bottom field B 3 .
- B 3 since there is an unpaired top field T 0 in the reordering buffer 722 , a frame number is not assigned to the field B 3 by the stream analyzer 720 .
- B 3 enters the reordering buffer 722 and the tail end of the working queue 726 . Since max_num_reorder_pics is equal to 1, the field with the lowest POC, T 0 , is output from the reordering buffer 722 to the pairing buffer 724 .
- the bottom field B 1 arrives next in the decoding order. Because there is an unpaired top field T 0 in the reordering buffer 722 , a frame number is not assigned to the field B 1 by the stream analyzer 720 .
- the field B 1 enters the reordering buffer 722 and the tail end of the working queue 726 , following B 3 . Again, the field with the lowest POC, B 1 , is output from the reordering buffer 722 to the pairing buffer 724 .
- the pairing buffer now has two fields, T 0 and B 1 , and a field pair is detected.
- the frame number “ 0 ” of the field T 0 is assigned to the field B 1 , according to the processes of the stream analyzer 720 discussed above, and both the T 0 and B 1 fields are output from the pairing buffer 724 .
- B 3 becomes the only unpaired field in the reordering buffer 722 , a new frame number “ 1 ” is assigned to B 3 . Since both B 3 and B 1 now have a frame number, they are removed from the working queue 726 and sent to the decoder 740 sequentially.
- the decoded results of T 0 and B 1 are saved in a single frame buffer since both of them are assigned to the frame number “ 0 ”.
- T 0 and B 1 are output from the virtual field DPB buffer 732 . Since both fields of the frame “ 0 ” are output from the virtual field DPB 732 , frame “ 0 ” is output for display to the display 760 . As compared with a decoding system that combines two fields in a frame after decoding, the decoder 70 does not incur an extra delay or any extra combining process.
- field pairing latency depends not only on a maximum allowed number of pictures preceding any picture in decoding order and succeeding that picture in output order, but also on the maximum number of pictures that can precede any picture in output order and follow that picture in decoding order.
- the first number is specified by max_num_reorder_pics and the second is specified by MaxLatencyPictures in the HEVC specification.
- max_num_reorder_pics the second is specified by MaxLatencyPictures in the HEVC specification.
- max_num_reorder_pics is specified by MaxLatencyPictures in the HEVC specification.
- max_num_reorder_pics is specified by MaxLatencyPictures in the HEVC specification.
- max_num_reorder_pics+MaxLatencyPictures fields between two complementary fields.
- the maximum decoding latency is max_num_reorder_pics+2 ⁇ MaxLatencyPictures+1.
- An extra latency compared with the decoding system in FIG. 2 is 2 ⁇ MaxLatencyPictures. Note that the latency can be combined with the initial buffering delay to reduce the total decoding system latency.
- FIG. 10 a flowchart illustrating example operations of the decoder 70 of FIG. 7 are provided.
- the flowchart of FIG. 10 may be viewed as depicting example steps of a method of virtual field buffer based decoding 1000 .
- the processes of FIG. 10 are described in connection with the decoder 70 of FIG. 7 , other decoders may operate according to the processes illustrated. Further, it should be understood that the flowchart of FIG. 10 provide only one example of different functional or process arrangements that may be employed according to the embodiments described herein.
- FIG. 10 illustrates an example process flow of a virtual field buffer based decoding process 1000 performed by the decoder 70 of FIG. 7 according to an example embodiment.
- a next picture in a decoding order is read from a coded picture buffer. For example, when the first field T 0 (and other later fields) is identified in the coded picture buffer 710 by the stream analyzer 720 , it may be read from the coded picture buffer 710 .
- the picture fields read from the coded picture buffer 710 are reordered.
- fields read from the coded picture buffer 710 may be reordered in the reordering buffer 722 and the working queue 726 , as discussed above in connection with FIGS. 8, 9A, and 9B .
- picture fields read from the coded picture buffer 710 are assigned frame numbers and assigned to frames.
- fields read from the coded picture buffer 710 may be assigned frame numbers and assigned to frames in the pairing buffer 724 , the virtual field DPB 732 , and the frame DPB map 734 , as discussed above in connection with FIGS. 8, 9A, and 9B .
- picture fields read from the coded picture buffer 710 are decoded. With reference to the decoder 70 of FIG. 7 , picture fields read from the coded picture buffer 710 may be decoded by the decoder 740 .
- decoded picture fields may be stored in pairs as frames.
- the picture fields may be stored in the unified frame-based DPB 750 .
- the decoded picture fields may be output to a display as a frame.
- the display 760 of the decoder 70 of FIG. 7 may be relied upon in this context, to display decoded pictured from the unified frame-based DPB 750 .
- an explicit frame number may be provided, per picture field in a coded bitstream, at the side of an encoder. This explicit frame number may be provided for each field picture so that a decoder can use the number to pair two fields together.
- the frame assignments of the individually-decoded fields may be tracked in a virtual field DPB, such as the virtual field DPB manager 730 of the decoder 70 of FIG. 1 .
- fields may be paired before (and during) decoding of pictures, and a frame-based DPB may be used to store pairs of picture fields as frames, for later display.
- frame numbers for each picture field in the coded picture buffer 710 are assigned by an encoder and the decoder 70 of FIG. 7 may determine frame numbers for each picture field by referring to assignments of frame numbers provided by the encoder.
- the above-described aspects of field pairing and the assignment of frame numbers for field pairs may be applied to various operations performed in connection with decoding.
- the aspects of field pairing and frame number assignment described above may be applied to trick modes, such as fast forward and reverse mode operations.
- trick modes such as fast forward and reverse mode operations.
- algorithms rely upon manipulation of video streams at picture boundaries.
- frame numbers of fields of pictures should be known at the side of the decoder.
- a certain count i.e., a skip count
- the skip count represents a number of frames to be decoded but not displayed as part of a trick play effect.
- certain initial pictures may be required to be decoded, if they are predictive frames for a final frame to be displayed, for example, even if the initial pictures are not ultimately displayed.
- the aspects of field pairing and the assignment of frame numbers for field pairs may be applied to determine field pairs of frames that are decoded and displayed, or decoded but not displayed.
- FIG. 11 illustrates an example schematic block diagram of a computing device 1100 that may be employed by the decoder 10 of FIG. 1 or the decoder 70 of FIG. 7 , according to various embodiments described herein.
- the computing device 1100 may be embodied, in part, using one or more elements of a general purpose computer.
- the computing device 1100 includes a processor 1110 , a Random Access Memory (“RAM”) 1120 , a Read Only Memory (“ROM”) 1130 , a memory device 1140 , a network interface 1150 , and an Input Output (“I/O”) interface 1160 .
- the elements of computing device 1100 are communicatively coupled via a bus 1102 .
- the elements of the computing device 1100 are not intended to be limiting in nature, as the device may further include other elements.
- the processor 1110 may comprise any well-known general purpose arithmetic processor, state machine, or Application Specific Integrated Circuit (“ASIC”), for example.
- the decoder 10 of FIG. 1 or the decoder 70 of FIG. 7 may be implemented, in part, by the processor 1110 .
- the processor 1110 may include one or more circuits, one or more microprocessors, ASICs, dedicated hardware, or any combination thereof.
- the processor 1110 is configured to execute one or more software modules.
- the processor 1110 may further include memory configured to store instructions and/or code to various functions, as further described herein.
- the processor 1110 may comprise a state machine or ASIC, and the processes described in FIGS. 4A, 4B, 5A, 6, and 10 may be implemented or executed by the state machine or ASIC according to a specialized or embedded circuitry design, by firmware, or a combination of a circuitry and firmware.
- the RAM and ROM 1120 and 1130 comprise any well-known random access and read only memory devices that store computer-readable instructions to be executed by the processor 1110 .
- the memory device 1140 stores computer-readable instructions thereon that, when executed by the processor 1110 , direct the processor 1110 to execute various aspects of the embodiments described herein.
- the memory device 1140 comprises one or more of an optical disc, a magnetic disc, a semiconductor memory (i.e., a semiconductor, floating gate, or similar flash based memory), a magnetic tape memory, a removable memory, combinations thereof, or any other known non-transitory memory means for storing computer-readable instructions.
- the network interface 1150 comprises hardware interfaces to communicate over data networks.
- the I/O interface 1160 comprises device input and output interfaces, such as keyboard, pointing device, display, communication, and/or other interfaces.
- the bus 1102 electrically and communicatively couples the processor 1110 , the RAM 1120 , the ROM 1130 , the memory device 1140 , the network interface 1150 , and the I/O interface 1160 , so that data and instructions may be communicated among them.
- the processor 1110 is configured to retrieve computer-readable instructions and data stored on the memory device 1140 , the RAM 1120 , the ROM 1130 , and/or other storage means, and copy the computer-readable instructions to the RAM 1120 or the ROM 1130 for execution, for example.
- the processor 1110 is further configured to execute the computer-readable instructions to implement various aspects and features of the embodiments described herein.
- the processor 1110 may be adapted or configured to execute the processes described above with reference to FIGS. 4A, 4B, 5A, 6 , and 10 .
- the processor 1110 may include internal memory and registers for maintenance of data being processed.
- each block may represent one or a combination of steps or executions in a process.
- each block may represent a module, segment, or portion of code that comprises program instructions to implement the specified logical function(s).
- the program instructions may be embodied in the form of source code that comprises human-readable statements written in a programming language or machine code that comprises numerical instructions recognizable by a suitable execution system such as the processor 1110 .
- the machine code may be converted from the source code, etc.
- each block may represent, or be connected with, a circuit or a number of interconnected circuits to implement a certain logical function or process step.
- FIGS. 4A, 4B, 5A, 6, and 10 illustrate an order
- the order may differ from that which is depicted.
- an order of execution of two or more blocks may be scrambled relative to the order shown.
- two or more blocks shown in succession in FIGS. 4A, 4B, 5A, 6, and 10 may be executed concurrently or with partial concurrence.
- one or more of the blocks shown in FIGS. 4A, 4B, 5A, 6, and 10 may be skipped or omitted.
- any number of counters, state variables, warning semaphores, or messages might be added to the logical flow described herein, for purposes of enhanced utility, accounting, performance measurement, or providing troubleshooting aids, etc. It is understood that all such variations are within the scope of the present disclosure.
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
Abstract
Description
Claims (23)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/782,425 US9516330B2 (en) | 2013-02-06 | 2013-03-01 | Virtual field buffer based decoding |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201361761489P | 2013-02-06 | 2013-02-06 | |
US13/782,425 US9516330B2 (en) | 2013-02-06 | 2013-03-01 | Virtual field buffer based decoding |
Publications (2)
Publication Number | Publication Date |
---|---|
US20140219332A1 US20140219332A1 (en) | 2014-08-07 |
US9516330B2 true US9516330B2 (en) | 2016-12-06 |
Family
ID=51259187
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/782,425 Active 2034-03-03 US9516330B2 (en) | 2013-02-06 | 2013-03-01 | Virtual field buffer based decoding |
Country Status (1)
Country | Link |
---|---|
US (1) | US9516330B2 (en) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6365924B2 (en) * | 2013-05-09 | 2018-08-01 | サン パテント トラスト | Image decoding method and image decoding apparatus |
US9565454B2 (en) * | 2013-06-24 | 2017-02-07 | Microsoft Technology Licensing, Llc | Picture referencing control for video decoding using a graphics processor |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5495294A (en) * | 1992-07-03 | 1996-02-27 | British Broadcasting Corporation | Synchronising signal generator |
US20050201471A1 (en) * | 2004-02-13 | 2005-09-15 | Nokia Corporation | Picture decoding method |
US20050207490A1 (en) * | 2004-03-18 | 2005-09-22 | Wang Jason N | Stored picture index for AVC coding |
US20070280358A1 (en) * | 2002-01-22 | 2007-12-06 | Broadcom Corporation | System and method of transmission and reception of progressive content with isolated fields for conversion to interlaced display |
US20090002379A1 (en) * | 2007-06-30 | 2009-01-01 | Microsoft Corporation | Video decoding implementations for a graphics processing unit |
US20090238482A1 (en) * | 2008-03-18 | 2009-09-24 | Samsung Electronics Co., Ltd. | Method and apparatus for field picture coding and decoding |
US20130229548A1 (en) * | 2011-06-24 | 2013-09-05 | Rakuten, Inc. | Image providing device, image processing method, image processing program, and recording medium |
-
2013
- 2013-03-01 US US13/782,425 patent/US9516330B2/en active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5495294A (en) * | 1992-07-03 | 1996-02-27 | British Broadcasting Corporation | Synchronising signal generator |
US20070280358A1 (en) * | 2002-01-22 | 2007-12-06 | Broadcom Corporation | System and method of transmission and reception of progressive content with isolated fields for conversion to interlaced display |
US20050201471A1 (en) * | 2004-02-13 | 2005-09-15 | Nokia Corporation | Picture decoding method |
US20050207490A1 (en) * | 2004-03-18 | 2005-09-22 | Wang Jason N | Stored picture index for AVC coding |
US20090002379A1 (en) * | 2007-06-30 | 2009-01-01 | Microsoft Corporation | Video decoding implementations for a graphics processing unit |
US20090238482A1 (en) * | 2008-03-18 | 2009-09-24 | Samsung Electronics Co., Ltd. | Method and apparatus for field picture coding and decoding |
US20130229548A1 (en) * | 2011-06-24 | 2013-09-05 | Rakuten, Inc. | Image providing device, image processing method, image processing program, and recording medium |
Non-Patent Citations (1)
Title |
---|
Bross et al., "High Efficiency Video Coding (HEVC) text specification draft 10 (for FDIS & Consent)," Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1 SC 29/WG 11 12th Meeting: Geneva, CH (Jan. 2013). |
Also Published As
Publication number | Publication date |
---|---|
US20140219332A1 (en) | 2014-08-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11553198B2 (en) | Removal delay parameters for video coding | |
KR102135966B1 (en) | Method and apparatus for encoding image, and method and apparatus for decoding image to manage buffer of decoder | |
US11044487B2 (en) | Signaling change in output layer sets | |
US10701401B2 (en) | Syntax structures indicating completion of coded regions | |
US11076160B2 (en) | Devices and methods for identifying a leading picture | |
KR102058759B1 (en) | Signaling of state information for a decoded picture buffer and reference picture lists | |
KR101944565B1 (en) | Reducing latency in video encoding and decoding | |
KR102117723B1 (en) | Constraints and unit types to simplify video random access | |
US9473790B2 (en) | Inter-prediction method and video encoding/decoding method using the inter-prediction method | |
KR20090040287A (en) | Methods and apparatus for use in multi-view video coding | |
US20050105883A1 (en) | Signaling valid entry points in a video stream | |
JP2007507128A (en) | Video picture encoding and decoding with delayed reference picture refresh | |
US9516330B2 (en) | Virtual field buffer based decoding | |
US9491483B2 (en) | Inter-prediction method and video encoding/decoding method using the inter-prediction method | |
Yang | Fast field pairing in HEVC |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: BROADCOM CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:YANG, ZHIJIE;REEL/FRAME:030257/0968 Effective date: 20130228 |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:037806/0001 Effective date: 20160201 Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:037806/0001 Effective date: 20160201 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD., SINGAPORE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:041706/0001 Effective date: 20170120 Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BROADCOM CORPORATION;REEL/FRAME:041706/0001 Effective date: 20170120 |
|
AS | Assignment |
Owner name: BROADCOM CORPORATION, CALIFORNIA Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:041712/0001 Effective date: 20170119 |
|
AS | Assignment |
Owner name: AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE. LIMITE Free format text: MERGER;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:047422/0464 Effective date: 20180509 |
|
AS | Assignment |
Owner name: AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE. LIMITE Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE PREVIOUSLY RECORDED AT REEL: 047422 FRAME: 0464. ASSIGNOR(S) HEREBY CONFIRMS THE MERGER;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:048883/0702 Effective date: 20180905 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |