Sustainability of Digital Formats
 Planning for Library of Congress Collections

Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact
Format Description Categories >> Browse Alphabetical List

UYVY Video Picture Encoding

>> Back
Table of Contents
Format Description Properties Explanation of format description terms

Identification and description Explanation of format description terms

Full name UYVY Video Picture Encoding
Description

A digital, color-difference component video picture format identified by the FOURCC code UYVY. This format employs 4:2:2 chroma subsampling with each sample represented by 8 bits of data. It is essentially the same as YUY2 but with different component ordering packed within the two-pixel macropixel: Byte 0=8-bit Cb; Byte 1=8-bit Y'0; Byte 2=8-bit Cr; Byte 3=8-bit Y'1. The FOURCC YUV pixel format page provides additional information and a helpful diagram.

The structure appears to be the same as that of a format that Apple tags as 2vuy, the designation also referenced by SMPTE in the MXF standard (ST 377-1:2009, annex G). Note, however, that the same Apple developer page warns, "Despite the name, this pixel format is not a simple byte-reversal of 'yuv2' [Apple's designation for FOURCC YUY2]." Comments welcome.

The FOURCC Web page cited above states that "UYVY is probably the most popular of the various YUV 4:2:2 formats." Using their own four-character code to identify this format, the Apple developer page cited above states, "'2vuy' is the format long used by professional video tape formats, transmission protocols, processing equipment (both computer-based and not), and compression schemes. It . . . discards no information from a digital video link. Its component order also matches that transmitted over a digital video link."

UYVY encoding (like all uncompressed formats identified by FOURCC codes) allows for variation in features like picture size, aspect ratio (square or non-square pixels), component levels (i.e., levels for Y, Cb, and Cr in either video range or wide range), and a given instance may contain video from interlaced or progressive sources. (See comment about interlacing and field order in the Notes below.) In order for an application to play the video back correctly or, say, to hand it off for successful inclusion in a video production side by side with other footage, all of these facts ought to be declared in metadata embedded in the file wrapper or associated with the file. The need for such metadata (and a way to compensate if it is missing) is suggested by the "Appendix: Backwards Compatibility" section of an Apple developer page that provides "best assumptions" to support playback for 2vuy video when the metadata is absent.

Production phase Employed in post-production or editing (middle phase) and dissemination (final phase).
Relationship to other formats
    Used by AVI_UYVY, AVI File Format with UYVY Video Encoding
    Used by QT_UYVY, Quicktime File Format with UYVY (2vuy) Video Encoding
    Used by MXF_GC_UNC_UYVY, MXF Generic Container with Uncompressed Video Essence UYVY (2vuy)
    Used by Matroska_UYVY, Matroska File Format with UYVY Video Encoding
    Used by Other video file wrappers not described at this Web site at this time.

Local use Explanation of format description terms

LC experience or existing holdings No extensive experience.
LC preference None. For preservation reformatting, the Library of Congress' Packard Campus for Audio-Visual Conservation has chosen MXF_OP1a_JP2_LL (lossless JPEG 2000 wrapped in MXF operational pattern 1a).

Sustainability factors Explanation of format description terms

Disclosure UYVY structure is described at an open Web site managed by FOURCC.org. The identical 2vuy format is documented by Apple at an open Web page. Also documented by SMPTE in annex G of standard ST 377-1:2011.
    Documentation Segment on FOURCC.org YUV documentation page. Segment on Apple developer documentation, page titled Uncompressed Y´CbCr Video in QuickTime Files. See also SMPTE ST 377:2011, annex G.
Adoption Widely adopted.
    Licensing and patents None.
Transparency Relatively transparent; requires tools to write and read.
Self-documentation Not applicable; provided by the file wrapper.
External dependencies None.
Technical protection considerations None.

Quality and functionality factors Explanation of format description terms

Moving Image
Normal rendering Supported
Clarity (high image resolution) Very good; this 8-bit sampling is, however, surpassed by the 10-bit sampling found in V210 and other encodings. See also Notes below.
Functionality beyond normal rendering Not applicable.

File type signifiers Explanation of format description terms

Tag Value Note
Microsoft FOURCC UYVY
From the FOURCC YUV page. This identifier will be found in files like AVI_UYVY.
Other 2vuy
Apple Video Codec four-character code. From an Apple developer page. This identifier will be found in files like QT_UYVY. Note that the same Apple developer page provides this Apple codec name: Component Y'CbCr 8-bit 4:2:2.
Apple Video Sample Description kCVPixelFormatType_422YpCbCr8
From an Apple developer page, using the term Apple Core Video pixel format description. The compiler of this resource is uncertain as to whether this identifier is found in file headers or elsewhere in the file; comments welcome. It may appear in applications that handle the picture data.
Other AV_PIX_FMT_UYVY422
FFmpeg AV_PIX_FMT. From this FFmpeg page and this FFmpeg page (line 310). The compiler of this resource is uncertain as to whether this identifier is found in file headers or elsewhere in the file; comments welcome. It may appear in applications that handle the picture data.
Other Registry: 06.0E.2B.34.04.01.01.0A
Item: 04.01.02.01.01.02.01.01
SMPTE Universal Label, as found in ST 377-1:2009, annex G, also in SMPTE Labels Registry as specified in RP224v12-2012. This identifier will be found in files like MXF_GC_UNC_UYVY.

Notes Explanation of format description terms

General

Interlacing and field order. This writer's understanding is that, when the source footage is interlaced, UYVY encoding does not group together all the odd and even lines as they would be grouped in the two fields that make up a video frame on, say, a videotape. All UYVY pixel data is presented in a left-right, top-down order that could be called progressive. To put it another way, for interlaced picture data, the tape presents alternate lines in the two fields that make up a frame: line 1, line 3, line 5, etc., and then line 2, line 4, line 6, etc. In contrast, UYVY encodes the data as line 1, line 2, line 3, line 4, line 5, line 6, etc.

In fact, on a tape, which comes first (1, 3, 5 or 2, 4, 6) represents what is called field order or field cadence. There are two options for field order: upper (field 2 is dominant, so the second field is drawn first) and lower (field 1 is dominant, so the first field is drawn first). Generally, upper is used by 640 x 480 systems, while lower is most common in professional 720 x 486 and DV 720 x 480 systems.

As noted in the Description section above, even though UYVY's serialization of the data is progressive, and many players will work well without help, it may be the case that a user will wish to "restore" footage archived as UYVY in a manner that will, say, intercut with other footage. Such restoration may require the decoding system to be aware that this footage was originally interlaced and to know the original field order. That's a job for metadata.

8- and 10-bit sampling. In principle, 10-bit encoding is superior in clarity to 8-bit, due to the reduction in tonal contouring and other artifacts. Some specialists argue, however, that there is no benefit for certain classes of material. One university expert wrote, "We digitize Betacam SX tape to 8-bit UYVY but Digibeta to 10-bit V210 because these selections align with the nature of the data that is actually sent out over SDI from these tapes. . . . SDI is 10-bit data, but when I piped the SDI video data from an SX tape to a binary display I could see the 9th and 10th bits were always zero. Thus by taking only the first 8 bits I could get all meaningful data . . . . I have about 3,000 SX hours to preserve and choosing 8-bit instead of 10 saves me about 90 TB of storage" (private communication).

History  

Format specifications Explanation of format description terms


Useful references

URLs


Last Updated: Friday, 24-Oct-2014 14:02:38 EDT