|Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact|
|Full name||Information technology -- Coding of audio-visual objects (formal name); MPEG-4, Advanced Video Coding (part 10), High 4:4:4 Profile|
The High 4:4:4 Profile MPEG-4_AVC (from ITU-T H.264) supports 4:4:4 chroma at 12 bits per channel, adaptive macroblock-level switching between 8x8 and 4x4 transform block size, encoder-specified quantization scaling matrices, encoder-specified separate control of the quantization parameter for each chroma component, and monochrome sequences. It also supports residual color transform and predictive lossless coding (see Notes regarding lossless-ness). The Overview and Introduction to the Fidelity Range Extensions does not separately discuss the High 4:4:4 Profile but states that "High 4:2:2 is expected to be used frequently in studio environments."
NOTE: this Web page drafted prior to the amendment of the standard to add the four High profiles.Comments welcome.
|Production phase||Generally a final-state (end-user delivery) format.|
|Relationship to other formats|
|Subtype of||MPEG-4_AVC, MPEG-4, Advanced Video Coding (Part 10) (H.264)|
|Used by||MP4_FF_2_AVC_H444P, MPEG-4 File Format, V.2, with AVC, High 4:4:4 Profile|
|LC experience or existing holdings|
|Disclosure||Open standard. See MPEG-4_AVC.|
|Documentation||See MPEG-4_AVC. This profile is not yet in the formal specification; information may be found in Overview and Introduction to the Fidelity Range Extensions.|
|Adoption||See MPEG-4_AVC_HP and MPEG-4_AVC.|
|Licensing and patents||See MP4_FF_2.|
|External dependencies||See MP4_FF_2.|
|Technical protection considerations||See MP4_FF_2.|
|Normal rendering||Good support.|
|Clarity (high image resolution)||See MPEG-4_AVC. Depends in part on the level and encoding algorithm selected. The High 4:4:4 Profile has the potential to produce greater clarity than MPEG-4_AVC_BP, MPEG-4_AVC_MP, MPEG-4_AVC_EP, MPEG-4_AVC_HP, MPEG-4_AVC_H10P, and MPEG-4_AVC_H422P. The greatest clarity will result from lossless coding; see Notes, below.|
|Functionality beyond normal rendering||See MP4_FF_2.|
|Filename extension||Not applicable.||Pertains to the file format; see MP4_FF_2|
|Internet Media Type||Not applicable.||Pertains to the file format; see MP4_FF_2|
|Magic numbers||Not applicable.||Pertains to the file format; see MP4_FF_2|
|File type brand (ISO Base Media File Format)||See note.||Indicated in file wrapper and relates to "brands" defined in ISO_BMFF. Wrapping MPEG-4_AVC bitstreams in MP4_FF_1 (unlikely) would occasion the use of mp41; in MP4_FF_2 (more likely), use mp42.|
|Indicator for profile, level, version, etc.||244
||profile_idc; described as a part of Annex A of Part 10 of the standard, pp. 204-05.|
How lossless might the High 4:4:4 profile be? Detlev Marpe and Thomas Weigand's article H.264/MPEG4-AVC Fidelity Range Extensions: Tools, Profiles, Performance, and Application Areas reports that important tools contained within the FRExt amendment include the following pair, which seem to have to do with lossless coding: (1) "A residual color transform consisting in a reversible integer-based color conversion from (4:4:4) RGB to the YCgCo color space applied to residual data only," and (2) "A lossless coding capability requiring only a relatively simple bypass of transform and quantization." A similar statement is made in Jens-Rainer Ohm and Gary Sullivan's "Introduction to MPEG-4 Advanced Video Coding,"which describes the High 4:4:4 as "supporting a residual color transform in the decoding process, and defining a transform bypass mode which allows efficient lossless coding."
Ian Gilmour, a preservation officer with the National Screen and Sound Archive of Australia, offers this commentary:
"The lossless bits? The short answer on MPEG-4 is that you can have compressed video which will be lossy, or, under certain very narrow constraints, you can retain discrete parts of the picture area, but with no compression. You cannot losslessly encode a normal, real-life video stream using MPEG-4 to achieve any significant data reduction."
"There are two specific tools amongst the hundreds in the entire MPEG-4 kit that refer to lossless compression: (1) intra PCM raw sample-value macroblocks, and (2) entropy-coded transform-bypass lossless macroblocks (FRExt-only). These are designed to be applied to macroblocks, and to slices. As far as I've been able to ascertain, they would not apply at the partition level, and they would not be used in interframe modes. They essentially have complementary or in fact diametrically opposing roles. One way to compare them is to 'picture' the kinds of content on which they may be used."
"Intra PCM. The first routine, I-PCM, appears to be applicable to most profiles and levels, and is not constrained to 4:4:4 only. It would be useful, presumably, if every pixel within a macroblock had widely differing values, or highly randomised sets of values for luminance and chroma. In such instances the possible gains of using sufficiently complex transforms to accurately characterise all possible types of picture content in order to reduce entropy to virtually non-existent levels, would be far outweighed by the overheads of simply passing through the original pixel values. In other words, these macroblocks or slices would be uncompressed, and no savings in data or file size would be achieved (in fact, a slight coding overhead is added). What I read between the lines is "don't get too excited about having tiny parts of an image uncompressed, when you're only starting with 4:2:0 in the first place". If you think this through a bit more carefully, it could mean, in addition, that if a given bit stream was constrained to a certain data rate, and even a small number of macroblocks in an I frame were set to I-PCM, there would be less data space available to encode the rest of the frame, leading to a more lossy outcome for the other macroblocks. It will be interesting to see how such rules and trade-offs are actually programmed into real-world encoders when they come on-line."
"Transform-bypass. This second mode would probably work best on exactly the opposite kind of image content. Let's say you had a frame of colour bars, and they all had boundaries or hard transitions from one colour to the next which exactly coincided with 16x16 macroblock boundaries. (I'm not sure how you'd do this in 720 x 480 with eight bars unless you had something like extra red space around the edges). It would be possible in this mode, theoretically, to process each macroblock straight through to the entropy coder, and to reconstruct the same sample values at the other end, since no DC transformation or inverse transform would be needed. This functionality has been available for at 20 years, with LZW, and even a .gif file would achieve the same effect; you wouldn't need an MPEG-4 CODEC if pictures were all that simple. The only catch is that real-world television has all this other stuff after the colour-bars, and it's not all neatly arranged into 16 x 16 squares, and the colours and luminance vary all over the shop, and . . . .
"Let's also look at the practical ramifications of tools which only apply to 4:4:4 colour space. Film archives would only get 4:4:4 or RGB data from scanning film at high resolution on a 2k or 4k scanner such as Cintel, Dalsa, Imagica, Kinton, Northlight, Thompson, etc. What this means is that the more advanced Fidelity Range Extensions would only be useful on film scans or possibly other true-colour material such as CG. They would not be deployable on our tens/hundreds of thousands of PAL/NTSC videos which are the real preservation reformatting challenge right now. You would need the FRExt functionality to encode 4:2:2, from a good analog composite to digital component encoder, although it would still be lossy MPEG-4. The lower modes and profiles, including 8-bit 4:2:0 would not really be much use, because in common broadcast space, these levels are already compressed in MPEG-2 (Beta SX and IMX) or DV family DCT compression. For comparison, Motion JPEG 2000 is the only application designed for lossless end-to-end compression of standard definition 4:2:2 component video from older VTRs." (Personal communication, October 7, 2005)