What is a Codec?

Codec is a portmanteau of either "Compressor-Decompressor" or "Coder-Decoder," which describes a device or program capable of performing transformations on a data stream or signal.

Codecs encode a stream or signal for transmission, storage or encryption and decode it for viewing or editing. Codecs are often used in videoconferencing and streaming media solutions. A video codec converts analog video signals from a video camera into digital signals for transmission. It then converts the digital signals back to analog for display. An audio codec converts analog audio signals from a microphone into digital signals for transmission. It then converts the digital signals back to analog for playing.

The raw encoded form of audio and video data is often called essence, to distinguish it from the metadata information that together make up the information content of the stream and any "wrapper" data that is then added to aid access to or improve the robustness of the stream.

Most codecs are lossy, in order to get a reasonably small file size. There are lossless codecs as well, but for most purposes the almost imperceptible increase in quality is not worth the considerable increase in data size. The main exception is if the data will undergo more processing in the future, in which case the repeated lossy encoding would damage the eventual quality too much.

Many multimedia data streams need to contain both audio and video data, and often some form of metadata that permits synchronization of the audio and video. Each of these three streams may be handled by different programs, processes, or hardware; but for the multimedia data stream to be useful in stored or transmitted form, they must be encapsulated together in a container format.

An endec is a similar (but not identical) concept for hardware.

Transcoding

Transcoding is the direct digital-to-digital data conversion of one encoding to another,[1] such as for movie data files or audio files. This is usually done in cases where a target device (or workflow) does not support the format or has limited storage capacity that mandates a reduced file size, or to convert incompatible or obsolete data to a better- supported or modern format. Transcoding can be performed just while files are being searched, as well as for presentation. For example, Cineon and DPX files have been widely used as a common format for digital cinema, but the data size of a two-hour movie is about 8 terabytes (TB). That large size can increase the cost and difficulty of handling movie files. However, transcoding into a JPEG2000 lossless format has better compression performance than other lossless coding technologies, and in many cases, JPEG2000 can compress images to half-size.

Transcoding is commonly a lossy process, introducing generation loss; however, transcoding can be lossless if the input is losslessly compressed and the output is either losslessly compressed or uncompressed. The process of lossy-to-lossy transcoding introduces varying degrees of generation loss. In other cases, the transcoding of lossy to lossless or uncompressed is technically a lossless conversion because no information is lost, however the process is irreversible and is more suitably known as destructive.

Audio and Video Codecs (A/V codecs)

ABOUT RAW CODECS

Raw recording for motion pictures wasn't popular until the release of the RED ONE camera a few years ago. RED brought the idea of Raw recording to the masses, though they weren't the first. Both ARRI and DALSA had cameras that could output Raw sensor data. So what is Raw anyway? Simply put, it's just sensor data before any image processing. The upside to Raw recording is that no typical video processing (and minimal compression) has been baked in. The sensor outputs exactly what it sees -- no white balance, ISO or other color adjustments are there. This, along with a high bit rate, allows for a huge amount of adjustment in post. (note: the less compressed options in both Red One, and Sony F65 are often considered fairly lossless (limited quality loss). On the other hand, ALEXA outputs uncompressed Raw data, which can be recorded externally. This would be the closest thing to a true uncompressed signal.

REDCODE RAW (.R3D) RAW is a proprietary file format that efficiently encodes measurements from a camera’s digital sensor in a way that maximizes post-production capabilities. It achieves this in part by storing each of the sensor’s color channels separately, prior to conversion into a full color image. Similar to the advantages that RAW files brought to stills photography, this improves control over white balance, exposure and grading in post-production. Furthermore, since such settings are appended to the file as metadata only, grading is completely

ARRIRAW Arriraw is a raw codec similar to CinemaDNG that contains unaltered Bayer sensor information, the data stream from the camera can be recorded via T-link with certified recorders like those from Codex Digital or Cineflow.

The ArriRaw format (along with the other recordable formats) contains static and dynamic metadata. These are stored in the header of the file and can be extracted with the free web tool metavisor[12] or with the application Meta Extract provided by Arri. Of particular importance for visual effects are the lens metadata, which are stored only when Arri's lens data system (LDS) is supported by the lens used.

CinemaDNG CinemaDNG is the result of an Adobe-led initiative to define an industry-wide open file format for digital cinema files. CinemaDNG caters for sets of movie clips, each of which is a sequence of raw video images, accompanied by audio and metadata. CinemaDNG supports stereoscopic cameras and multiple audio channels. CinemaDNG specifies directory structures containing one or more video clips, and specifies requirements and constraints for the open format files, (DNG, TIFF, XMP, and/or MXF), within those directories, that contain the content of those clips.

CinemaDNG is different from the Adobe DNG (Digital Negative) format that is primarily used as a raw image format for still cameras. However, each CinemaDNG image is encoded using that DNG image format. The image stream can then be stored in one of two formats: either as video essence using frame-based wrapping in an MXF file, or as a sequence of DNG image files in a specified file directory. Each clip uses just one of these formats, but the set of clips in a movie may use both.

BRAW Blackmagic RAW is a visually lossless codec. They claim that their new RAW codec will offer equal or better image quality to any other codec on the market, but at file sizes similar to those you’ll find in lossy encoding techniques, such as h.264.

ABOUT LOG

New Sony, Canon and ARRI cameras all have a Log recording mode. When the Log modes are activated, the image becomes flat and desaturated, but you can still see it on a monitor. Log recording is just standard video recording in the sense that all pixels display color and brightness information. Log isn't Raw; it's video. However, it's a special way of capturing that maximizes the tonal range of a sensor.

The idea of Log recording came about with Kodak's Cineon system for scanning film. The system scanned film into a Log format that corresponded to the density of the original film. This maximized the information from the film that could be stored in the video format. Because this information has many shades of gray -- very low contrast -- it needs to be corrected for proper viewing on a monitor.

Sony, Canon and ARRI have all taken the idea of Log film scanning and applied it to their sensors. They map a "Log" gamma curve that pulls the most information off of their sensors. Sony calls their map S-Log, Canon's is Canon Log, and ARRI's is LogC. Each is designed for a specific camera, but all have a similar result. Because Log is a video image, manipulations like white balance and ISO are baked in. A transform of this video data, known as a lookup table (LUT), is required for proper viewing, which makes the video look more "normal" to us. A standard LUT converts the Log video to standard (Rec. 709) HD video. The ALEXA converts its Raw data into LogC video; this information can be recorded or sent out over HD-SDI. A LUT can be applied for viewing and also can be recorded if desired. Because of this, any step in the chain -- Raw, LogC video or standard video -- can be recorded. log is primarily designed to maximize dynamic range, it makes sense to shoot log in tricky lighting conditions where you expect there to be both extremely bright and dark parts in the image. However, in more controlled lighting situations, such as studio work and shooting green screens shooting in log is not really accomplishing much for you. In fact, it's just making more unnecessary work for you in post-production.

S-LOG, LogC and Cannon Log S- LOG (Sony Log) or Log-C (Arri, but Arri also can shoot S-log) S-Log, Log-C or Cannon Log mode to capture a cinema quality image and accomplish negative film quality latitude (as in negative film analog film stock). S- Log and Log-C mode captures an image with the greatest amount of range in tonal reproduction and the lowest noise floor and highest ceiling. What this means is you can shoot an image using S-Log or Log-C and have the greatest amount of flexibility when entering the digital intermediate phase of post- production. Using S-Log or Log-C shooting RAW files using 4:4:4 compression creates a digital image that emulates the latitude of negative film.

The image of negative film without color correction looks flat with only mid-tone colors and little black and white within it. This is what the image will look like with S-Log or Log-C applied because the greatest amount of tonal information is in the mid-tone range of an image.

RAW VS LOG

Raw is not Log because Log is in a video format, and Raw is not video. Raw data has no video processing baked in and has to be converted into video for viewing. Log is video and has things like white balance baked into it. They're very much not the same; however, they're both designed to get the most information out of the sensor. Raw is getting everything the sensor has to offer; likewise, Log curves are designed to get the most tonal range out of the sensor. While they're very different formats, they have the same general application. Both Raw and Log can be uncompressed, but that depends on the recording device.

Note: The ALEXA converts its Raw data into LogC video; this information can be recorded or sent out over HD-SDI. A LUT can be applied for viewing and also can be recorded if desired. Because of this, any step in the chain -- Raw, LogC video or standard video -- can be recorded.

LUTS That is where a Look Up Tables, or LUTs, come into play. An LUT is a digital process, either in the camera, in a mobile recording device, or in a digital intermediate phase that creates a desired image using different exposures charts and digital knees. Like an ENG or prosumer camera’s scene file, a LUT can change the look of an image instantaneously. However, scene files will embed into the image, and LUT acts as an overlay to an image where the raw S- Log/Log-C is recorded and not the altered imaged.

RECS or ITU-R RECOMMENDATIONS ITU-R are the names given to set of international technical standards developed by the Radiocommunication Sector (formerly CCIR) of the International Telecommunication Union (ITU). They are the result of studies undertaken by Radiocommunication study groups.

Rec 601 ITU-R Recommendation BT.601, more commonly known by the abbreviations Rec. 601 or BT.601 (or its former name, CCIR 601) is a standard originally issued in 1982 by the CCIR (an organization which has since been renamed as the International Telecommunication Union – Radiocommunication sector) for encoding interlaced analog video signals in digital video form.[1] It includes methods of encoding 525-line 60 Hz and 625-line 50 Hz signals, both with an active region covering 720 luminance samples and 360 chrominance samples per line. The color encoding system is known as YCbCr 4:2:2.

The Rec. 601 video raster format has been re-used in a number of later standards, including the ISO/IEC MPEG and ITU-T H.26x compressed formats – although compressed formats for consumer applications usually use chroma subsampling reduced from the 4:2:2 sampling specified in Rec. 601 to 4:2:0.

The standard has been revised several times in its history. Its edition 7, referred to as BT.601-7, was approved in March 2011 and was formally published in October 2011.

Signal format The Rec. 601 signal can be regarded as if it is a digitally encoded analog component video signal, and thus the sampling includes data for the horizontal and vertical sync and blanking intervals. Regardless of the frame rate, the luminance sampling frequency is 13.5 MHz. The samples are uniformly quantized using 8 or 10 bit PCM codes in the YCbCr domain.

For each 8 bit luminance sample, the nominal value to represent black is 16 and the value for white is 235. Eight-bit code values from 1 through 15 provide footroom, and can be used to accommodate transient signal content such as filter undershoots. Similarly, code values 236 through 254 provide headroom and can be used to accommodate transient signal content such as filter overshoots. The values 0 and 255 are used to encode the sync pulses and are forbidden within the visible picture area. The Cb and Cr samples are unsigned and use the value 128 to encode the neutral color difference value, as used when encoding a white, grey or black area.

Rec. 709 is an ITU Recommendation, first introduced in 1990, that sets out the standards for HDTV. Included in these standards is the Rec. 709 Color Space which is an RGB color space that is identical to the sRGB color space.

Pixel count

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (June 2016) (Learn how and when to remove this template message) Rec. 709 refers to HDTV systems having roughly two million luma samples per frame. Rec. 709 has two parts:

Part 2 codifies current and prospective 1080i and 1080p systems with square sampling. In an attempt to unify 1080-line HDTV standards, part 2 defines a common image format (CIF) with picture parameters independent of the picture rate.

Part 1 codifies what are now referred to as 1035i30 and 1152i25 HDTV systems. The 1035i30 system is now obsolete, having been superseded by 1080i and 1080p square-sampled ("square-pixel") systems. The 1152i25 system was used for experimental equipment in Europe and was never commercially deployed.

Frame rate

Rec. 709 specifies the following picture rates: 60 Hz, 50 Hz, 30 Hz, 25 Hz and 24 Hz. "Fractional" rates having the above values divided by 1.001 are also permitted.

Initial acquisition is possible in either progressive or interlaced form. Video captured as progressive can be transported with either progressive transport or progressive segmented frame (PsF) transport. Video captured as interlaced can be transported with interlace transport. In cases where a progressive captured image is transported as a segmented frame, segment/field frequency must be twice the frame rate.

In practice, the above requirements result in the following frame rates ("fractional" rates are specified in commonly used "decimal" form): 25i, 25PsF, 25p, 50p for 50 Hz systems; 23.976p, 23.976PsF, 24p, 24PsF, 29.97i, 29.97p, 29.97PsF, 30PsF, 30p, 59.94p, 60p for 60 Hz systems.

Digital representation Rec. 709 defines an R’G’B’ encoding and a Y’CBCR encoding, each with either 8 bits or 10 bits per sample in each color channel. In the 8-bit encoding, the R’, B’, G’, and Y’ channels have a nominal range of {\displaystyle [16..235]} [16..235], and the CB and CR channels have a nominal range of {\displaystyle [16..240]} [16..240] with 128 as the neutral value. So in R’G’B’, reference black is (16, 16, 16) and reference white is (235, 235, 235), and in Y’CBCR, reference black is (16, 128, 128), and reference white is (235, 128, 128). Values outside the nominal ranges are allowed, but typically they would be clamped for broadcast or for display. Values 0 and 255 are reserved as timing references, and may not contain color data. Rec. 709's 10-bit encoding uses nominal values four times those of the 8-bit encoding. Rec. 709's nominal ranges are the same as those defined in ITU Rec. 601.

Rec. 2020 ITU-R Recommendation BT.2020, more commonly known by the abbreviations Rec. 2020 or BT.2020, defines various aspects of ultra-high-definition television (UHDTV) with standard dynamic range (SDR) and wide color gamut (WCG), including picture resolutions, frame rates with progressive scan, bit depths, color primaries, RGB and luma-chroma color representations, chroma subsamplings, and an opto-electronic transfer function. The first version of Rec. 2020 was posted on the International Telecommunication Union (ITU) website on August 23, 2012, and two further editions have been published since then.

Resolution Rec. 2020 defines two resolutions of 3840 × 2160 ("4K") and 7680 × 4320 ("8K").These resolutions have an aspect ratio of 16:9 and use square pixels.

Frame rate Rec. 2020 specifies the following frame rates: 120p, 119.88p, 100p, 60p, 59.94p, 50p, 30p, 29.97p, 25p, 24p, 23.976p. Only progressive scan frame rates are allowed.

Digital representation Rec. 2020 defines a bit depth of either 10-bits per sample or 12-bits per sample.

10-bits per sample Rec. 2020 uses video levels where the black level is defined as code 64 and the nominal peak is defined as code 940. Codes 0–3 and 1,020– 1,023 are used for the timing reference. Codes 4 through 63 provide video data below the black level while codes 941 through 1,019 provide video data above the nominal peak.

12-bits per sample Rec. 2020 uses video levels where the black level is defined as code 256 and the nominal peak is defined as code 3760. Codes 0–15 and 4,080–4,095 are used for the timing reference. Codes 16 through 255 provide video data below the black level while codes 3,761 through 4,079 provide video data above the nominal peak.

Rec. 2100

CIE 1931 chromaticity diagram showing the Rec. 2100 color space in the triangle and the location of the primary colors. Rec. 2100 uses Illuminant D65 for the white point. ITU-R Recommendation BT.2100, more commonly known by the abbreviations Rec. 2100 or BT.2100, defines various aspects of high dynamic range (HDR) video such as display resolution (HDTV and UHDTV), frame rate, chroma subsampling, bit depth, color space, and optical transfer function. It was posted on the International Telecommunication Union (ITU) website on July 4, 2016. Rec. 2100 expands on several aspects of Rec. 2020.

Resolution Rec. 2100 defines three resolutions of 1080p, 3840 × 2160 ("4K"), and 7680 × 4320 ("8K"). These resolutions have an aspect ratio of 16:9 and use square pixels.

Frame rate Rec. 2100 specifies the following frame rates: 120p, 119.88p, 100p, 60p, 59.94p, 50p, 30p, 29.97p, 25p, 24p, 23.976p.[1] Only progressive scan frame rates are allowed.

Digital representation Rec. 2100 defines a bit depth of either 10-bits per sample or 12-bits per sample, with either narrow range or full range color values.[1]

For narrow range color, 10-bits per sample use video levels where the black level is defined as 64, achromatic gray level as 512 and the nominal peak as 940 in RGB encoding and 960 in YCbCr encoding. Codes 0–3 and 1,020–1,023 can be used for the timing reference and should be avoided.[1] 12-bits per sample use 256 as the black level, 2048 as the achromatic gray level and the nominal peak is 3760 in RGB encoding and 3840 in YCbCr encoding.[1] Codes 0–15 and 4,080– 4,095 can be used for the timing reference and should be avoided.[1]

For full range color, 10-bit levels are 0 for the black level, 512 for the grey level and 1023 for the nominal peak, and 12-bit levels are 0, 2048 and 4092 (values 4093-4095 are avoided to exclude clipping errors on 10-bit ADC/DAC circuits which have 1023 steps).

Standard Codecs

AVI Older codec, an acronym for Audio Video Interleave, is a multimedia container format introduced by Microsoft in November 1992, as part of the Video for Windows technology. AVI files contain both audio and video data in a standard container that allows simultaneous playback. Most AVI files also use the file format extensions developed by the Matrox OpenDML group in February 1996. These files are supported by Microsoft, and are known unofficially as "AVI 2.0".

It is a special case of the Resource Interchange File Format (RIFF), which divides the file's data up into data blocks called "chunks". Each "chunk" is identified by a FourCC tag. An AVI file takes the form of a single chunk in an RIFF formatted file, which is then subdivided into two mandatory "chunks" and one optional "chunk".

The first sub-chunk is identified by the "hdrl" tag. This chunk is the file header and contains metadata about the video such as the width, height and the number of frames. The second sub-chunk is identified by the "movi" tag. This chunk contains the actual audio/visual data that makes up the AVI movie. The third optional sub-chunk is identified by the "idx1" tag and indexes the location of the data chunks within the file.

By way of the RIFF format, the audio/visual data contained in the "movi" chunk can be encoded or decoded by a software module called a codec. The codec translates between raw data and the data format inside the chunk. An AVI file may therefore carry audio/visual data inside the chunks in almost any compression scheme, including: Full Frames (Uncompressed), Intel Real Time Video, Indeo, Cinepak, Motion JPEG, Editable MPEG, VDOWave, ClearVideo / RealVideo, QPEG, MPEG-4, XviD, DivX and others.

Cinepak Cinepak is a video codec, developed by Radius Inc to accommodate 1x (150 kbyte/s) CD-ROM transfer rates.

It was the primary video codec of early versions of QuickTime and Microsoft Video for Windows, but was later superseded by Sorenson Video, Intel Indeo, and most recently MPEG-4 and h.264. However, movies compressed with Cinepak are generally still playable in most media players.

Cinepak is based on vector quantization, which is a significantly different algorithm from the discrete cosine transform (DCT) algorithm used by most current codecs (in particular the MPEG family, as well as JPEG). This permitted implementation on relatively slow CPUs, but tended to result in blocky artifacting at low bitrates.

DivX®

DivX is a video codec created by DivX, Inc. (formerly DivXNetworks, Inc.), regarded for its ability to compress lengthy video segments into small sizes while maintaining relatively high visual quality. DivX uses lossy MPEG-4 Part 2 compression, where quality is balanced against file size for utility. It is one of several codecs commonly associated with ripping, where audio and video multimedia are transferred to a hard disk and transcoded. As a result, DivX has been a center of controversy because of its use in the replication and distribution of copyrighted DVDs.

Many newer "DivX Certified" DVD players are able to play DivX encoded movies, however, "DivX" is not to be confused with "DIVX", an unrelated attempt at a new DVD rental system employed by the US retailer Circuit City. Early versions of DivX included only a codec, and were named "DivX ;-)", where the winking emoticon was a tongue-in-cheek reference to the failed DIVX system.

DivX, XviD and 3ivx: Video codec packages basically using MPEG-4 Part 2 video codec, with the *.avi, *.mp4, *.ogm or *.mkv file container formats.

DV Digital Video (DV) is a video format launched in 1996, and, in its smaller tape form factor MiniDV, has since become one of the standards for consumer and semiprofessional video production. The DV specification (originally known as the Blue Book, current official name IEC 61834) defines both the codec and the tape format. Features include intraframe compression for uncomplicated editing, a standard interface for transfer to non-linear editing systems (FireWire also known as IEEE 1394), and good video quality, especially compared to earlier consumer analog formats such as 8 mm, Hi-8 and VHS- C. DV now enables filmmakers to produce movies inexpensively, associated with no- budget cinema.

There have been some variants on the DV standard, most notably the more professional DVCAM and DVCPRO standards by Sony and Panasonic, respectively. Also, there is a recent high-definition version called HDV, which is rather different on a technical level since it only uses the DV and MiniDV tape form factor, but MPEG-2 for compression.

Video compression- DV uses DCT intraframe compression at a fixed bitrate of 25 megabits per second (25.146 Mbit/s), which, when added to the sound data (1.536 Mbit/s), the subcode data, error detection, and error correction (approx 8.7 Mbit/s) amounts in all to roughly 3.6 megabytes per second (approx 35.382 Mbit/s) or one Gigabyte every four minutes. At equal bitrates, DV performs somewhat better than the older MJPEG codec, and is comparable to intraframe MPEG-2. (Note that many MPEG- 2 encoders for real-time acquisition applications do not use intraframe compression.)

Chroma subsampling - The chroma subsampling is 4:1:1 for NTSC or 4:2:0 for PAL, which reduces the amount of color resolution stored. Therefore, not all analog formats are outperformed by DV. The Betacam SP format, for example, can still be desirable because it has similar color fidelity and no digital artifacts. The lower sampling of the color space is also a reason why DV is sometimes avoided in applications where chroma-key will be used. However, a large contingent feel the benefits (no generation loss, small format, digital audio) are an acceptable tradeoff given the compromise in color sampling rate.

Audio - DV allows either 2 digital audio channels (usually stereo) at 16 bit resolution and 48 kHz sampling rate, or 4 digital audio channels at 12 bit resolution and 32 kHz sampling rate. For professional or broadcast applications, 48 kHz is used almost exclusively. In addition, the DV spec includes the ability to record audio at 44.1 kHz (the same sampling rate used for CD audio), although in practice this option is rarely used. DVCAM and DVCPRO both use locked audio while standard DV does not. This means that at any one point on a DV tape the audio may be +/- 1/3 frame out of sync with the video. This is the maximum drift of the audio/video sync though it is not compounded throughout the recording. In DVCAM and DVCPRO recordings the audio sync is permanently linked to the video sync.

DVCAM Sony's DVCAM is a semiprofessional variant of the DV standard that uses the same cassettes as DV and MiniDV, but transports the tape 50% faster, leading to a higher track width of 15 micrometres. The codec used is the same as DV, but because of the greater track width available to the recorder the data are much more robust, producing 50% less errors known as dropouts. The LP mode of DV is not supported. All DVCAM recorders and cameras can play back DV material, but DVCPRO support was only recently added to some models. DVCAM tapes (or DV tapes recorded in DVCAM mode) have their recording time reduced by one third. DVCAM is now also available in HD mode.

DVCPRO Panasonic specifically created the DVCPRO family for ENG use (NBC's newsgathering division was a major customer), with better linear editing capabilities and robustness. It has an even greater track width of 18 micrometres and uses another tape type (Metal Particle instead of Metal Evaporated). Additionally, the tape has a longitudinal analog audio cue track. Audio is only available in the 16 bit/48 kHz variant, there is no EP mode, and DVCPRO always uses 4:1:1 color subsampling (even in PAL mode). Apart from that, standard DVCPRO (also known as DVCPRO25) is otherwise identical to DV at a bitstream level. However, unlike Sony, Panasonic chose to promote its DV variant for professional high-end applications.

DVCPRO50 is often described as two DV-codecs in parallel. The DVCPRO50 standard doubles the coded video bitrate from 25 Mbit/s to 50 Mbit/s, and improves color- sampling resolution by using a 4:2:2 structure. DVCPRO50 was created for high-value ENG compatibility. The higher datarate cuts recording-time in half (compared to DVCPRO25), but the resulting picture-quality is reputed to rival Digital Betacam, a more expensive studio format.

DVCPRO HD, also known as DVCPRO100, uses four parallel codecs and a coded video bitrate of 100 Mbit/s. Despite HD in its name, DVCPROHD downsamples native 720p/1080i signals to a lower resolution. 720p is downsampled from 1280x720 to 960x720, and 1080i is downsampled from 1920x1080 to 1280x1080 for 59.94i and 1440x1080 for 50i. Compression ratio is approximately 7:1. To maintain compatibility with HDSDI, DVCPRO100 equipment internally downsamples video during recording, and subsequently upsamples video during playback. A camcorder using as special variable-framerate (from 4 to 60 frame/s) variant of DVCPRO HD called VariCam is also available. All these variants are backward compatible but not forward compatible.

Other variants

Sony's XDCAM format allows recording of MPEG IMX, DVCAM and low resolution streams in an MXF wrapper on an optical medium similar to a Blu-Ray Disc, while Panasonic's P2 system uses recording of DV/ DVCPRO/ DVCPRO50/ DVCPROHD streams in an MXF wrapper on PCMCIA-compatible flash memory cards. Ikegami's Editcam System can record in DVCPRO or DVCPRO50 format on a removable hard disk. Note that most of these distinctions are for marketing purposes only - since DVCPRO and DVCAM only differ in the method in which they write the DV stream to tape, all these non-tape formats are virtually identical in regard to the video data.

JVC's D-9 format (also known as Digital-S) is very similar to DVCPRO50, but records on videocassettes in the S-VHS form factor. (NOTE: D-9 is not to be confused with D-VHS, which uses MPEG-2 compression at a significantly lower bitrate)

Digital8 standard uses the DV codec, but replaces the recording medium with the venerable Hi8 videocassette. Digital8 offers DV's digital quality, without sacrificing playback of existing analog Video8/Hi8 recordings.

H.261: Used primarily in older videoconferencing and videotelephony products. H.261, developed by the ITU-T, was the first practical digital video compression standard. Essentially all subsequent standard video codec designs are based on it. It included such well-established concepts as YCbCr color representation, the 4:2:0 sampling format, 8-bit sample precision, 16x16 macroblocks, block-wise motion compensation, 8x8 block-wise discrete cosine transformation, zig-zag coefficient scanning, scalar quantization, run+value symbol mapping, and variable-length coding. H.261 supported only progressive scan video.

H.263: Used primarily for videoconferencing, videotelephony, and internet video. H.263 represented a significant step forward in standardized compression capability for progressive scan video. Especially at low bit rates, it could provide a substantial improvement in the bit rate needed to reach a given level of fidelity. H.264/MPEG-4 Part 10 or AVC (Advanced Video Coding) is a standard for video compression, and is currently one of the most commonly used formats for the recording, compression, and distribution of high definition video. The final drafting work on the first version of the standard was completed in May 2003.

H.264/MPEG-4 AVC is a block-oriented motion-compensation-based codec standard developed by the ITU-T Video Coding Experts Group (VCEG) together with the International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) Moving Picture Experts Group (MPEG). It was the product of a partnership effort known as the Joint Video Team (JVT). The ITU-T H.264 standard and the ISO/IEC MPEG-4 AVC standard (formally, ISO/IEC 14496-10 – MPEG-4 Part 10, Advanced Video Coding) are jointly maintained so that they have identical technical content.

H.264 is perhaps best known as being one of the codec standards for Blu-ray Discs; all Blu-ray Disc players must be able to decode H.264. It is also widely used by streaming internet sources, such as videos from Vimeo, YouTube, and the iTunes Store, web software such as the Adobe Flash Player and Microsoft Silverlight, broadcast services for DVB and SBTVD, direct-broadcast satellite television services, cable television services, and real-time videoconferencing.

Applications

The H.264 video format has a very broad application range that covers all forms of digital compressed video from low bit-rate Internet streaming applications to HDTV broadcast and Digital Cinema applications with nearly lossless coding. With the use of H.264, bit rate savings of 50%[2] or more are reported. For example, H.264 has been reported to give the same Digital Satellite TV quality as current MPEG-2 implementations with less than half the bitrate, with current MPEG-2 implementations working at around 3.5 Mbit/s and H.264 at only 1.5 Mbit/s.[3] To ensure compatibility and problem-free adoption of H.264/AVC, many standards bodies have amended or added to their video-related standards so that users of these standards can employ H.264/AVC.

Both the Blu-ray Disc format and the now-discontinued HD DVD format include the H.264/AVC High Profile as one of 3 mandatory video compression formats.

The Digital Video Broadcast project (DVB) approved the use of H.264/AVC for broadcast television in late 2004.

The Canon DSLR's use the H.264 QuickTime MOV as the native recording.

The Advanced Television Systems Committee (ATSC) standards body in the United States approved the use of H.264/AVC for broadcast television in July 2008, although the standard is not yet used for fixed ATSC broadcasts within the United States. It has also been approved for use with the more recent ATSC-M/H (Mobile/Handheld) standard, using the AVC and SVC portions of H.264.

H.265 - High Efficiency Video Coding (HEVC), also known as H.265 and MPEG-H Part 2, is a video compression standard, one of several potential successors to the widely used AVC (H.264 or MPEG-4 Part 10). In comparison to AVC, HEVC offers about double the data compression ratio at the same level of video quality, or substantially improved video quality at the same bit rate. It supports resolutions up to 8192×4320, including 8K UHD.

In most ways, HEVC is an extension of the concepts in H.264/MPEG-4 AVC. Both work by comparing different parts of a frame of video to find areas that are redundant, both within a single frame as well as subsequent frames. These redundant areas are then replaced with a short description instead of the original pixels. The primary changes for HEVC include the expansion of the pattern comparison and difference-coding areas from 16×16 pixel to sizes up to 64×64, improved variable-block-size segmentation, improved "intra" prediction within the same picture, improved motion vector prediction and motion region merging, improved motion compensation filtering, and an additional filtering step called sample-adaptive offset filtering. Effective use of these improvements requires much more signal processing capability for compressing the video, but has less impact on the amount of computation needed for decompression.

Coding efficiency

The design of most video coding standards is primarily aimed at having the highest coding efficiency. Coding efficiency is the ability to encode video at the lowest possible bit rate while maintaining a certain level of video quality. There are two standard ways to measure the coding efficiency of a video coding standard, which are to use an objective metric, such as peak signal-to-noise ratio (PSNR), or to use subjective assessment of video quality. Subjective assessment of video quality is considered to be the most important way to measure a video coding standard since humans perceive video quality subjectively.

AV1 AOMedia Video 1 (AV1) is an open, royalty-free video coding format designed for video transmissions over the Internet. It was developed by the Alliance for Open Media (AOMedia), a consortium of firms from the semiconductor industry, video on demand providers, video content producers, software development companies and web browser vendors, founded in 2015. The AV1 bitstream specification includes a reference video codec. It succeeds VP9. It can have 20% higher data compression than VP9 or HEVC/H.265 from the Moving Picture Experts Group and about 50% higher than the widely used AVC.

AV1 was announced with the creation of the Alliance for Open Media on 1 September 2015.This was to combine its members' technology and expertise to create a better royalty-free video format with qualities that are, in short, suitable for web use.[5] In particular, Google, Mozilla and Cisco already had ongoing research projects into royalty- free video at this time, namely VP10, Daala and Thor.

The timely announcement of AV1 was welcomed by industry observers as an escape hatch from the licensing of HEVC;[6][7] the first sign that HEVC pricing was going to be in a different ballpark than AVC had come with HEVC Advance's initial licensing offer on 21 July 2015, 42 days before.[8] Cisco's Thor development was started in response to HEVC being perceived as unviable for use in open source and freely distributed products,[9] but the work of Google and Mozilla (previously under Xiph) on royalty-free video predates this event (by a decade in Xiph's case), and is not attributable to HEVC's licensing woes, although it definitely also is seen as a problem by Mozilla.

AV1 is intended for use in HTML5 web video and WebRTC together with the Opus audio format.

AVCHD is a high-definition recording format designed by Sony and Panasonic that uses H.264 (conforming to H.264 while adding additional application-specific features and constraints). is a file-based format for the digital recording and playback of high-definition video. It is H.264 and Dolby AC-3 packaged into the MPEG transport stream, with a set of constraints designed around the camcorders.

Developed jointly by Sony and Panasonic, the format was introduced in 2006 primarily for use in high definition consumer camcorders.[2] Related specifications include the professional variants AVCCAM and NXCAM. n 2011 the AVCHD specification was amended to include 1080-line 50-frame/s and 60- frame/s modes (AVCHD Progressive) and stereoscopic video (AVCHD 3D). The new video modes require double the data rate of previous modes.

AVCHD and its logo are trademarks of Sony and Panasonic.[6]

AVC-Intra is an intraframe-only compression format, developed by Panasonic.

The CCTV (Closed Circuit TV) and Video Surveillance markets have included the technology in many products.

Branding

Panasonic and Sony developed several brand names for their professional as well as simplified versions of AVCHD.

AVCHD Lite AVCHD Lite is a subset of AVCHD format announced in January 2009,[20] which is limited to 720p60, 720p50 and 720p24 and does not employ Multiview Video Coding.[21] AVCHD Lite cameras duplicate each frame of 25fps/30fps video acquired by camera sensor,[22] producing 720p50/720p60 bitstream compliant with AVCHD and Blu-ray Disc specifications. As of 2013, AVCHD Lite seems to have been all but replaced with other formats. For example, the Panasonic DMC FZ-200 offers AVCHD Progressive recording mode (50fps/60fps acquisition and stream rate) as well as MP4 mode (25fps/30fps acquisition and stream rate).[23]

AVCCAM Formerly known as "AVCHD with professional features,"[24] AVCCAM is the name of professional AVCHD camcorders from Panasonic's Broadcast division. Some of these professional features listed in early Panasonic advertising materials included 1/3-inch progressive 3CCD sensor, XLR microphone input, solid-state media and capability of recording at the maximum AVCHD bitrate - 24 Mbit/s. The aforementioned features are not exclusive to AVCCAM. Moreover, some of these features like CCD sensor technology have been dropped by Panasonic, while 24 Mbit/s recording rate is widely available from rival manufacturers even on consumer models.

AVCHD Pro Panasonic uses "AVCHD Pro" moniker to describe camcorders like the HDC- MDH1, which combines consumer internal parts and controls with shoulder- mount type body. Panasonic touts that the camcorder is "shaped for Pro-Style shooting in Full-HD" with shoulder-mount type body being "preferred by professionals".[11]

NXCAM NXCAM is the name of Sony's professional video lineup employing the AVCHD format.[25] NXCAM camcorders offer 1080i, 1080p and 720p recording modes. Unlike AVCCAM, not all NXCAM camcorders offer film-like frame rates — 24p, 25p, 30p — in 720p mode.

XAVC is a recording format that was introduced by Sony on October 30, 2012. XAVC is a format that will be licensed to companies that want to make XAVC products.

Technical details

XAVC uses level 5.2 of H.264/MPEG-4 AVC, which is the highest level supported by that video standard. XAVC can support 4K resolution (4096 × 2160 and 3840 × 2160) at up to 60 frames per second (fps).[1][2] XAVC supports color depths of 8, 10, and 12 bits.Chroma subsampling can be 4:2:0, 4:2:2, or 4:4:4.[1][2] The Material Exchange Format (MXF) can be used for the digital container format.

XAVC allows for a wide range of content production including intra frame recording and long group of pictures (GOP) recording.

XAVC S - On April 7, 2013, Sony announced that it had expanded XAVC to the consumer market with the release of XAVC S.[3][4] XAVC S supports resolutions up to 3840 × 2160, uses MP4 as the container format, and uses either AAC or LPCM for the audio.[3][4] As example used in the Sony FDR-AX100 4K Ultra HD consumer camcorder[5] and Sony HDR-AS100V action camera.[6] The Sony α7S as well as some consumer stills cameras with movie support (e.g. the Sony RX10) also offer XAVC-S.

Hardware - Sony has announced that cameras that will support XAVC include two CineAlta cameras which are the Sony PMW-F55 and Sony PMW-F5.[7][8] Both cameras record XAVC with a color depth of 10-bits and 4:2:2 chroma subsampling.[9][10] The Sony PMW-F55 can record XAVC with 4K resolution at 60 fps at 600 Mbit/s and 2K resolution at 120 fps at 400 Mbit/s.The Sony PMW-F5 can record XAVC with 2K resolution at 120 fps at 400 Mbit/s.

XAVC can record 4K resolution at 60 fps with 4:2:2 chroma subsampling at 600 Mbit/s. A 128 Gigabyte SxS PRO+ media card can record up to 20 minutes of 4K resolution XAVC video at 60 fps, up to 40 minutes of 4K resolution XAVC video at 30 fps, and up to 120 minutes of 2K resolution XAVC video at 30 fps.[9][10][11][12]

The PXW-Z100 is a 7 lbs handheld camcorder with an integrated 20x 4K-compatible zoom lens. The PXW-Z100 is the first "prosumer" camera that uses Sony’s XAVC recording format. MPEG-4 AVC/H.264 compression is used for HD (1920×1080), QFHD (3840×2160) and 4K (4096×2160) content. Image sampling is 4:2:2 10-bit, with an intra- frame system that compresses each frame individually at a maximum bit rate of 500 Mbit/s or 600 Mbit/s during 4K 50fps or 60fps recording, respectively, and 223 Mbit/s during HD 50fps or 60fps recording.

On November 14, 2012, Sony stated that it might release consumer products that use XAVC.

In March 2014, Sony launched the consumer video camera, FDR-AX100, which uses XAVC S. It provides a maximum resolution of 3840 x 2160 with a 60 Mbit/s bit rate. It provides 12X optical zoom and records to a SDXC memory card.[15]

In February 2015, Sony launched the consumer video camera, FDR-AX33, which uses XAVC S. It provides a maximum resolution of 3840 x 2160 and increased the bit rate to 100 Mbit/s. It provides 10X optical zoom and records to a SDXC memory card.

In late fall, 2015, Sony released a firmware update (Version 2.0) for the HXR-NX3 camcorder which gives the camcorder the option of recording in XAVC S format in addition to AVCHD.

Software that supports XAVC include Sony Vegas Pro, Adobe Creative Suite 6, Avid, Blackmagic Design's DaVinci Resolve, Grass Valley's EDIUS Pro 7, Quantel, Rovi and MainConcept SDK.Sony announced that XAVC licensing information and a software development kit (SDK) would be released in November 2012.[13][14] Sony offers the free XAVC plugin PDZK-LT2 for Apples Final Cut Pro X downloadable at http://www.sonycreativesoftware.com. Version 10.2 of Final Cut Pro X supports XAVC-S natively.

For XAVC S, CyberLink PowerDirector, Adobe Premiere Elements, Apple's iMovie 10, Pinnacle Studio 18 Ultimate and Sony Movie Studio Platinum support it for editing and production.

See also

H.264/MPEG-4 AVC - The video standard that is used by XAVC

SxS - A flash memory standard used by Sony AVCHD - A recording format that uses a lower level of H.264/MPEG-4 AVC

AVC-Intra - A recording format that uses a lower level of H.264/MPEG-4 AVC

XF-AVC

XF-AVC employs the MPEG-4 AVC/H.264 video compression format, supports the efficient recording on memory cards of high-image-quality 4K, 2K and HD video content captured on video camcorders. As a result, not only can external storage and other equipment required during shooting be kept compact, because it enables the recording of high-image-quality video data, the format also facilitates color grading and other high- precision editing processes.

For the last few years, Sony has been shipping cameras with a new format, XAVC. XAVC encompasses a lot of different elements, and it’s created some confusion about what XAVC is, and what it isn’t. We’d like to help unravel the confusion, both from the official uses of XAVC, and some of the colloquial uses we’ve seen.

The basics

There are a few things that are constant about XAVC. XAVC is always going to involve some form of H.264 video, along with uncompressed LPCM audio. So, if you’ve got MPEG2 video or AC3 audio or any other permutation, it’s not XAVC.

We’ll get into some of the particulars of how H.264 is used within XAVC a little later. First, let’s cover the wrappers.

Wrappers

A “wrapper” is the container that holds your audio and video. One wrapper most people are familiar with is the QuickTime .MOV format. An MOV file might contain many different types of video and audio, but the MOV part stays the same. Other wrappers include M2T, MXF, AVI, etc.

XAVC generally uses the MXF wrapper, with the audio and video in a single file. (Other vendors use separate MXF files for audio and video.) However, there’s one flavor of XAVC, called XAVC-S, that uses the MP4 wrapper format. This format is found in the popular Sony A7s camera. Whether it’s MXF or MP4, the data inside the file is still H.264 and LPCM audio.

One common area for misunderstanding is the overlap between XAVC and AVCHD. AVCHD is a popular HD format, which normally uses the “MTS” wrapper. AVCHD is usually H.264 with AC3 audio, though some cameras have extended it to use LPCM audio as well. Some of Sony’s XAVC cameras are also capable of recording the AVCHD format, but at that point, they’re just recording AVCHD. It’s not “XAVC inside AVCHD” or anything like that.

Codecs

The XAVC family ranges from very affordable pocket-friendly cameras, to very expensive shoulder-mount cameras. It’s a very capable format, which means there are many variations in use. Most of these variations appear as different “profiles” of the H.264 codec, which have different capabilities. For a primer on these types of compression, check out our blog posts on intraframe and interframe compression.

The H.264 format within XAVC can be either 4:2:0, 4:2:2, or 4:4:4 color sampling. It can have either 8, 10 or 12 bits per sample (4:4:4 and 12bit have been announced, but aren’t included in any current camera models). And it can scale all the way from “proxy” sizes (480p for example) to full 4K, and potentially beyond, at very high frame rates.

XAVC can also be either intra-frame or inter-frame. In the video community, these have come to be known as XAVC-I and XAVC-L (for long-GOP or inter-frame). The different modes offer different capabilities, and these vary from camera to camera.

Compatibility

While Sony is making use of well-known standards like H.264 and MXF, there have been some compatibility issues with XAVC in a variety of applications. In large part, this is because they’re using components of the H.264 specification that haven’t been widely adopted in the past. In particular, they’re using the “high” profile, levels 5.1 and 5.2. Many of the H.264 decoding tools on the market don’t properly handle these. In addition, a number of H.264 decoders, including the one built into Mac OS X, don’t deal well with the mix of inter-frame compression and higher bit depths.

Confused?

We’ve created a chart, below, which maps out how all these factors relate. For a full rundown, check out Sony’s profiles and operating points guide.

XAVC and EditReady

We’ve been working to stay ahead of the curve with EditReady, by adding support for formats like XAVC-S, XAVC-L, and XAVC-I as the cameras have shipped. For both compatibility reasons, and performance reasons, we strongly recommend using EditReady to transcode these formats to an intermediate format like ProRes for editing.

MPEG - The Moving Picture Experts Group or MPEG is a working group of ISO/IEC charged with the development of video and audio encoding standards. Its first meeting was in 1988 in Hanover. As of late 2005, MPEG has grown to include approximately 350 members from various industries and universities. MPEG's official designation is ISO/IEC JTC1/SC29 WG11. the "new" XF-AVC is so similar to Sony XAVC that it takes some effort to distinguish them: Like Sony, Canon proposes a H.264/AVC based format wrapped in MXF files, and rebrands it as: Canon XF-AVC

MPEG (pronounced EM-peg) has standardized the following compression formats and ancillary standards:

* MPEG-1: Initial video and audio compression standard. Later used as the standard for Video CD, and includes the popular Layer 3 (MP3) audio compression format. * MPEG-2: Transport, video and audio standards for broadcast-quality television. Used for over-the-air digital television ATSC, DVB and ISDB, digital satellite TV services like DirecTV, digital cable television signals, and (with slight modifications) for DVD video discs. * MPEG-3: Originally designed for HDTV, but abandoned when it was discovered that MPEG-2 was sufficient for HDTV. * MPEG-4: Expands MPEG-1 to support video/audio "objects", 3D content, low bitrate encoding and support for Digital Rights Management. Several new (newer than MPEG-2 Video) higher efficiency video standards are included (an alternative to MPEG-2 Video), notably, Advanced Simple Profile and H.264/MPEG-4 AVC. * MPEG-7: A formal system for describing multimedia content. * MPEG-21: MPEG describes this future standard as a multimedia framework.

MPEG-1 Part 2: Used for Video CDs, and also sometimes for online video. The quality is roughly comparable to that of VHS. If the source video quality is good and the bitrate is high enough, VCD can look better than VHS, and all in all very good, but VCD requires high bitrates for this. However, to get a fully compliant VCD file, bitrates higher than 1150 kbit/s and resolutions higher than 352 x 288 should not be used. Includes the *.mp3 standard. When it comes to compatibility, VCD has the highest compatibility of any digital video/audio system. Almost every computer in the world can play this codec, and very few DVD players do not support it. In terms of technical design, the most significant enhancements in MPEG-1 relative to H.261 were half-pel and bi-predictive motion compensation support. MPEG-1 supported only progressive scan video.

MPEG-2 Part 2 (a common-text standard with H.262): Used on DVD and in another form for SVCD and used in most digital video broadcasting and cable distribution systems. When used on a standard DVD, it offers good picture quality and supports widescreen. When used on SVCD, it is not as good but is certainly better than VCD. Unfortunately, SVCD will only fit around 40 minutes of video on a CD, whereas VCD can fit an hour. Will also be used on HD-DVD and Blu-Ray. In terms of technical design, the most significant enhancement in MPEG-2 relative to MPEG-1 was the addition of support for interlaced video. MPEG-2 is now considered an aging codec, but has tremendous market acceptance and a very large installed base.

MPEG-4 Part 2: An MPEG standard that can be used for internet, broadcast, and on storage media. It offers improved quality relative to MPEG-2 and the first version of H.263. Its major technical features beyond prior codec standards consisted of object- oriented coding features and a variety of other such features not necessarily intended for improvement of ordinary video coding compression capability. It also included some enhancements of compression capability, both by embracing capabilities developed in H.263 and by adding new ones such as quarter-pel motion compensation. Like MPEG-2, it supports both progressive scan and interlaced video.

MPEG-4 Part 10 (a technically aligned standard with the ITU-T's H.264 and often also referred to as AVC). This emerging new standard is the current state of the art of ITU-T and MPEG standardized compression technology, and is rapidly gaining adoption into a wide variety of applications. It contains a number of significant advances in compression capability, and it has recently been adopted into a number of company products, including for example the PlayStation Portable, the Nero Digital product suite, Mac OS X v10.4, as well as HD-DVD/Blu-Ray.

Theora: Developed by the Xiph.org Foundation as part of their Ogg project, based upon On2 Technologies' VP3 codec, and christened by On2 as the successor in VP3's lineage, Theora is targeted at competing with MPEG-4 video and similar lower-bitrate video compression schemes.

WMV (Windows Media Video): Microsoft's family of video codec designs including WMV 7, WMV 8, and WMV 9. It can do anything from low resolution video for dial up internet users to HDTV. Files can be burnt to CD and DVD or output to any number of devices. It is also useful for Media Centre PCs. WMV can be viewed as a version of the MPEG-4 codec design. The latest generation of WMV is now in the process of being standardized in SMPTE as the draft VC-1 standard.

QuickTime

QuickTime is a multimedia technology developed by Apple Computer, capable of handling various formats of digital video, sound, text, animation, music, and immersive panoramic (and sphere panoramic) images.

The most recent versions are available for the Macintosh and Windows platforms.

QuickTime file format

A QuickTime file (*.mov) functions as a multimedia container file that contains one or more tracks, each of which store a particular type of data, such as audio, video, effects, or text (for subtitles, for example). Each track in turn contains track media, either the digitally encoded media stream (using a specific codec such as Cinepak, Sorenson codec, MP3, JPEG, DivX, or PNG) or a data reference to the media stored in another file or elsewhere on a network. It also has an "edit list" that indicates what parts of the media to use.

Internally, QuickTime files maintain this format as a tree-structure of "atoms", each of which uses a 4-byte OSType identifier to determine its structure. An atom can be a parent to other atoms or it can contain data, but it cannot do both.

The ability to contain abstract data references for the media data, and the separation of the media data from the media offsets and the track edit lists means that QuickTime is particularly suited for editing, as it is capable of importing and editing in place (without data copying) other formats such as AIFF DV, MP3, MPEG-1, and AVI. Other later- developed media container formats such as Microsoft's Advanced Streaming Format or the open source Ogg and Matroska containers lack this abstraction, and require all media data to be rewritten after editing.

QuickTime and MPEG-4

On February 11, 1998 the ISO approved the QuickTime file format as the basis of the MPEG-4 *.mp4 container standard. Supporters of the move noted that QuickTime provided a good "life-cycle" format, well suited to capture, editing, archiving, distribution, and playback (as opposed to the simple file-as-stream approach of MPEG-1 and MPEG- 2, which does not mesh well with editing). Developers added MPEG-4 compatibility to QuickTime 6 in 2002. However, Apple delayed the release of this version for months in a dispute with the MPEG-4 licensing body, claiming that proposed license fees would constrain many users and content providers. Following a compromise, Apple released QuickTime 6 on 15 July 2002.

Apple Pro Res Family

Pro Res 422 422 is a standard-definition and high-definition lossy video compression format developed by Apple Inc. for use in post production. It was introduced in 2007 with Final Cut Studio 2 [1] and is comparable to Avid's DNxHD codec which has the same purpose and uses similar bit rates. Both are DCT based[2] intra-frame-only codecs, and are therefore simpler to decode than distribution oriented formats like H.264. Target data rate of approximately 145 Mbps (1920 x 1080 at 60i) Higher quality than Apple ProRes 422 (LT)

Full-width 1920x1080 and 1280x720 4:2:2 chroma sampling 10-bit sample depth I frame-only encoding Variable bit-rate (VBR) encoding Normal 147 Mbit/s and High-Quality 220 Mbit/s for HD resolution at 60i Normal 42 Mbit/s and High-Quality 63 Mbit/s for SD resolution at 29.97 Fast encoding and decoding (both at full size and half size)

Pro Res 422 (HQ) The Apple ProRes 422 (HQ) codec offers the utmost possible quality for 4:2:2 or 4:2:0 sources (without an alpha channel) and provides the following: Target data rate of approximately 220 Mbps (1920 x 1080 at 60i) Higher quality than Apple ProRes 422

ProRes 4444 4444 is a lossy video compression format developed by Apple Inc. for use in post production that can handle standard definition, high definition, and 2K material. It was introduced with Final Cut Studio Pro 7 [1] as another in their line of intermediate codecs for editing material but not for final delivery. It shares many features with Apple's ProRes family of codecs but provides better quality than its predecessors particularly in the area of color.[2] ProRes 4444. For compositing and digital workflows that require the highest- possible image fidelity.

Full-resolution, mastering-quality 4:4:4:4 RGBA color (an online-quality codec for editing and finishing 4:4:4 material, such as that originating from Sony HDCAM SR or digital cinema cameras such as RED ONE, Thomson Viper FilmStream, and Panavision Genesis cameras). The R, G, and B channels are lightly compressed, with an emphasis on being perceptually indistinguishable from the original material. Lossless alpha channel with real-time playback High-quality solution for storing and exchanging motion graphics and composites For 4:4:4 sources, a data rate that is roughly 50 percent higher than the data rate of Apple ProRes 422 (HQ) Direct encoding of, and decoding to, RGB pixel formats Support for any resolution, including SD, HD, 2K, 4K, and other resolutions A Gamma Correction setting in the codec’s advanced compression settings pane, which allows you to disable the 1.8 to 2.2 gamma adjustment that can occur if RGB material at 2.2 gamma is misinterpreted as 1.8. This setting is also available with the Apple ProRes 422 codec.

2K, HD (up to 1920x1080), & SD resoultions 4:4:4 chroma sampling up to 12-bit pixel depth Variable Bit Rate (VBR) Alpha Channel Support

ProRes 422 (Proxy) For craft editing or offline editing on a MacBook or MacBook Pro. The Apple ProRes 422 (Proxy) codec is intended for use in offline workflows and provides the following: Roughly 30 percent of the data rate of Apple ProRes 422 High-quality offline editing at the original frame size, frame rate, and aspect ratio High-quality edit proxy for Final Cut Server

ProRes 422 (LT) For projects such as news, sports, and multicam events that require reduced file sizes at broadcast quality. Roughly 70 percent of the data rate of Apple ProRes 422 (thus, smaller file sizes than Apple ProRes 422) Higher quality than Apple ProRes 422 (Proxy)

Avid DNxHD codec (Family) Avid DNxHD, which stands for "Digital Nonlinear Extensible High Definition", is a lossy high-definition video post-production codec engineered for multi-generation compositing with reduced storage and bandwidth requirements. It is an implementation of SMPTE VC-3 standard. DNxHD codec was developed by Avid Technology, Inc. It is comparable with Apple's ProRes 422 which uses similar bit rates and has the same purpose.

Uncompressed high definition digital video has a substantially higher bitrate than standard definition and can require powerful computers to process and edit. Other codecs such as HDV, DVCPRO HD, AVC-Intra, AVCHD, and HDCAM use compression techniques that limit the spatial and temporal resolution of the image. While suitable for acquisition, these codecs will tend to degrade the image over the multiple encode- decode cycles that are typically required during the post-production of complex layered imagery. DNxHD offers a choice of three user-selectable bit rates: 220 Mbit/s with a bit depth of 10 or 8 bits, and 145 or 36 Mbit/s with a bit depth of 8 bits.

DNxHD is a video codec intended to be usable as both an intermediate format suitable for use while editing and as a presentation format. DNxHD data is typically stored in an MXF container, although it can also be stored in a QuickTime container.

On February 13, 2008, Avid reported that DNxHD was approved as compliant with the SMPTE VC-3 standard.

DNxHD is intended to be an open standard, but as of March 2008, has remained effectively a proprietary Avid format. The source code for the Avid DNxHD codec is freely available from Avid for internal evaluation and review, although commercial use requires Avid licensing approval. It has been commercially licensed to a number of companies including Ikegami, FilmLight, Harris Corporation, JVC, Seachange, EVS Broadcast Equipment.

On September 14, 2014, at the Avid Connect event in Amsterdam, Netherlands, Avid announced the DNxHR codec to support resolutions greater than 1080p, such as 2K and 4K.

On December 22, 2014, Avid Technology released an update for Media Composer that added support for 4K resolution, the Rec. 2020 color space, and a bit rate of up to 3,730 Mbit/s with the DNxHR codec.[5][6]

DNxHD data is typically stored in an MXF container, although it can also be stored in a Quicktime container. A standalone Quicktime codec for both Windows XP and Mac OS X is available to create and play Quicktime files containing DNxHD material. There is also an experimental support for DNxHD in open source FFMPEG project.

DNxHD is intended to be an open standard, but as of March 2008, has remained effectively a proprietary Avid format. Ikegami's Editcam camera system is unique in its support for DNxHD, and records directly to DNxHD encoded video. Such material is immediately accessible by editing platforms that directly support the DNxHD codec. The source code for the Avid DNxHD codec is freely available from Avid for internal evaluation and review, although commercial use requires Avid licensing approval. It has been commercially licensed to a number of companies including Ikegami, FilmLight, Harris, JVC, Seachange and EVS.

DNxHD was first supported in Avid DS Nitris (Sept 2004), then Avid Media Composer Adrenaline with the DNxcel option (Dec 2004) and finally by Avid Symphony Nitris (Dec 2005). Xpress Pro is limited to using DNxHD 8-bit compression, which is either imported from file or captured using a Media Composer with Adrenaline hardware. Media Composer 2.5 also allows editing of fully uncompressed HD material that was either imported or captured on a Symphony Nitris or DS Nitris system. On February 13, 2008 Avid reported that DNxHD was approved as compliant with the SMPTE VC3 standard.[1] In 2007, Apple unveiled ProRes 422, a codec matching many of the features of DNxHD. ProRes lacked a low bandwidth offline resolution like DNxHD 36 until the 2009 release of Final Cut Pro 7. With that release Apple added Pro Res 422 (Proxy) which runs around 45 Mbps, among other additions to ProRes. ProRes is supported for playback on Apple Macintosh and Windows computers, and is supplied and licensed for use when purchased as part of Apple's professional video editing software package, Final Cut Studio, (version 2 or later). DNxHD is available in 8 and 10 bit formats on any system which supports Quicktime. Unlike DNxHD, ProRes 422 provides full functionality at advanced resolutions (2K and 4K cinema) and SD.

Since September 2007 FFmpeg is providing 8-bit (but not 10-bit) VC-3/DNxHD encoding and decoding features thanks to BBC Research who sponsored the project and Baptiste Coudurier who implemented it. It is included in stable version 0.5 of FFmpeg, released on March 10, 2009.[3][4] (ffmpeg -i -vcodec dnxhd -b -an output.mov). This allows Linux non-linear video editors Cinelerra and Kdenlive to use DNxHD.

DNxHD is very similar to JPEG. Every frame is independent and consists of VLC-coded DCT coefficients.

Header consists of many parts and may include quantization tables and 2048 bits of user data. Also each frame has two GUIDs and timestamp. The frame header is packed into big-endian dwords. Actual frame data consists of packed macroblocks using a technique almost identical to JPEG: DC prediction and variable-length codes with run length encoding for other 63 coefficients. DC coefficient is not quantized. The codec supports alpha channel information.

AVIC DNxHR - which stands for "Digital Nonlinear Extensible High Resolution", is a lossy UHDTV post-production codec engineered for multi-generation compositing with reduced storage and bandwidth requirements. The codec was specifically developed for resolutions considered above FHD/1080p, including 2K, 4K and 8K resolution. DNxHD will continue to be used for HD resolutions.[1]

On September 12, 2014, Avid Technology, Inc. announced the DNxHR codec as part of a broader "Avid Resolution Independence" announcement at their Fall 2014 Avid Connect event, which was held during the IBC 2014 conference in Amsterdam, Netherlands.[1]

On December 22, 2014, Avid released Media Composer 8.3 which included support for 4K project formats and the DNxHR codec. Further details for the DNxHR codec were outlined in the "Avid High-Resolution Workflows Guide - December 2014"

Preliminary Specifications DNxHR is available in the following flavors:

DNxHR LB - Low Bandwidth (8-bit 4:2:2) Offline Quality DNxHR SQ - Standard Quality (8-bit 4:2:2) (suitable for delivery format) DNxHR HQ - High Quality (8-bit 4:2:2) DNxHR HQX - High Quality (12-bit 4:2:2) (UHD/4K Broadcast-quality delivery) DNxHR 444 - Finishing Quality (12-bit 4:4:4) (Cinema-quality delivery)

Bandwidth requirements for the codec and its different flavors have been announced in the "Avid High Resolution Workflows Guide - December 2014" on page 111.

Updated August 2015 avid.force.com "DNxHR Codec Bandwidth Specifications".[3]

DNxUncompressed DNxUncompressed is the newest format under the DNx brand. Following the IEEE standard 754-2008, it provides full 32-bit float support for effects and color processing, creating visually lossless images.

Q: What software supports it? DNxUncompressed is currently supported in Media Composer, Media Composer | First, and Media Composer | Ultimate 2018.9 and can be used for render, mixdown, consolidate and import functions. It is not currently supported for use in creating Titles or exports, and cannot be used outside of Media Composer.

Q: What is it used for? Uncompressed formats are typically used for high quality color and FX work. DNxUncompressed lets you work with other uncompressed (or 16bit or higher) formats in your timeline and maintain fully quality when rendering FX, doing color correction, or anytime you need to create new media with Media Composer.

Q: If I work with DNxUncompressed in Media Composer, what do I export? For exporting at highest quality, we recommend exporting DPX 16bit files. DPX exporting has been optimized to be 6-8 times faster than in previous versions.

Q: Is it SMPTE recognized? Not yet, but we are going through that process now so that other applications and tools will be able to read and encode DNxUncompressed media.

Q: What operating points are supported? Currently DNxUncompressed can be created at 4:2:2 32bit float and RGB 32bit float

Q: Will other operating points be supported? The full table of planned operating points is below. Note that while we intend to support them all, this work has not been formally scheduled or committed. For example - Media Composer today does not support YUV 4:4:4; in the future, this will be supported in the DNxUncompressed specification, but it is still to be determined if and when Media Composer supports it.

User-added image

Q: What software supports it? DNxUncompressed is currently supported in Media Composer, Media Composer | First, and Media Composer | Ultimate 2018.9 and can be used for render, mixdown, consolidate and import functions. It is not currently supported for use in creating Titles or exports, and cannot be used outside of Media Composer.

Q: What is it used for? Uncompressed formats are typically used for high quality color and FX work. DNxUncompressed lets you work with other uncompressed (or 16bit or higher) formats in your timeline and maintain fully quality when rendering FX, doing color correction, or anytime you need to create new media with Media Composer.

Q: If I work with DNxUncompressed in Media Composer, what do I export? For exporting at highest quality, we recommend exporting DPX 16bit files. DPX exporting has been optimized to be 6-8 times faster than in previous versions.

Q: Is it SMPTE recognized? Not yet, but we are going through that process now so that other applications and tools will be able to read and encode DNxUncompressed media.

Q: What operating points are supported? Currently DNxUncompressed can be created at 4:2:2 32bit float and RGB 32bit float

Q: Will other operating points be supported? The full table of planned operating points is below. Note that while we intend to support them all, this work has not been formally scheduled or committed. For example - Media Composer today does not support YUV 4:4:4; in the future, this will be supported in the DNxUncompressed specification, but it is still to be determined if and when Media Composer supports it.

MXF Container Material eXchange Format (MXF) is a container format for professional digital video and audio media defined by a set of SMPTE standards. A typical example of its use is for delivering adverts to TV stations.

XF is a "container" or "wrapper" format which supports a number of different streams of coded "essence", encoded in any of a variety of video and audio compression formats, together with a metadata wrapper which describes the material contained within the MXF file.

MXF has been designed to address a number of problems with non-professional formats. MXF has full timecode and metadata support, and is intended as a platform- agnostic stable standard for future professional video and audio applications.

MXF was developed to carry a subset of the Advanced Authoring Format (AAF) data model, under a policy known as the Zero Divergence Directive (ZDD). This theoretically enables MXF/AAF workflows between non-linear editing (NLE) systems using AAF and cameras, servers, and other devices using MXF.

MXF Usage MXF is in the process of evolving from standard to deployment. The breadth of the standard can lead to interoperability problems as vendors implement different parts of the standard.

MXF is fairly effective at the interchange of D10 (IMX) material, mainly because of the success of the Sony eVTR and Sony's eVTR RDD to SMPTE. Workflows combining the eVTR, Avid NLE systems, and broadcast servers using MXF in coordination with AAF are now possible.

Long-GOP MPEG-2 material interchange between video servers is possible, as broadcasters develop application specifications they expect their vendors to implement.

As of Autumn 2005, there were major interoperability problems with MXF in broadcast post-production use. The two data-recording camera systems which produced MXF at that time, Sony's XDCAM and Panasonic's DVCPRO P2, produced mutually incompatible files due to opaque subformat options obscured behind the MXF file extension. Without advanced tools, it was impossible to distinguish these incompatible formats.

Additionally, many MXF systems produce split-file A/V (that is, the video and audio stored in separate files), and use a file naming convention which relies on randomly generated filenames to link them. Not only does this exacerbate the issue of knowing exactly what is in an MXF file without specialized tools, but it breaks the functionality of standard desktop computer techniques which are generally used to manipulate data on a level as fundamental as moving, copying, renaming, and deleting. Using a randomly generated filename is uninformative to the user, but changing the name breaks the loose database structure between files.

Furthermore, the currently popular MXF export tools (i.e. the ones that are free or cost the least) will not allow the user to create a stereo AES file within the MXF wrapper, nor will they allow the user to add free-text annotation to the MXF file so created (in order, for instance, that the next user of the file be able to interpret his or her intentions). Thus, an MXF file received & unwrapped may reveal SMPTE D10 compliant essence with eight mono AES audio components; the recipient has no way of knowing whether these components are multiple stereo pairs, 5.1 or serve some other purpose.

Most of the incompatibilities were addressed and ratified in the 2009 version of the standard.

Sony's XDCAM MXF is supported by Adobe After Effects, Adobe Premiere Pro, Apple Final Cut Pro X, Autodesk Smoke, Avid, Capella systems, Dalet, EVS, Imagine Communications Corp., Omneon, Quantel, Rhozet, Sony Vegas Pro, Sorenson Squeeze, Telestream FlipFactory, GrassValley EDIUS, Grass Valley K2, and Merging Technologies VCube.

Panasonic's P2 MXF is supported by Adobe After Effects, Adobe Premiere Pro, Apple Final Cut Pro X, Autodesk Smoke, Avid, Dalet, EVS, GrassValley EDIUS, and Grass Valley K2.

Ikegami offers camcorders capable of recording in MXF wrapper using Avid DNxHD video encoding at 145 Mbit/s, as well as MPEG-2 video encoding at 50 Mbit/s 4:2:2 long- GOP and 100 Mbit/s I-frame.

In 2010 Canon released its new lineup of professional file-based camcorders. The recording format used in these camcorders incorporates MPEG-2 video with bitrates up to 50 Mbit/s and 16-bit linear PCM audio in what Canon has called XF codec. Canon claims that its flavor of MXF is fully supported by major NLE systems including Adobe Premiere, Apple Final Cut Pro X, Avid Media Composer, and Grass Valley EDIUS.

MXF is used as the audio and video packaging format for Digital Cinema Package (DCP). It is also used in the STANAG specification documents.

The file extension for MXF files is ".mxf". The Macintosh File Type Code registered with Apple for MXF files is "mxf ", including a trailing space.

CinemaDNG (intended by Adobe and others to be an open file format for digital cinema files) exploits MXF as one of its options for holding a sequence of raw video images. (The other option is to store a sequence of DNG files in a specified directory).

Matroska (MKV) file extensions .mkv .mk3d .mka .mks

The Matroska Multimedia Container is a free, open-standard container format, a file format that can hold an unlimited number of video, audio, picture, or subtitle tracks in one file.[1] It is a universal format for storing common multimedia content, like movies or TV shows. Matroska is similar in concept to other containers like AVI, MP4, or Advanced Systems Format (ASF), but is entirely open in specification, with implementations consisting mostly of open source software. Matroska file extensions are .MKV for video (which may or may not include subtitles and audio), .MK3D for stereoscopic video, .MKA for audio-only files, and .MKS for subtitles only.[2]

"Matroska" is derived from matryoshka (Russian: матрёшка [mɐˈtrʲɵʂkə]), which refers to the hollow wooden Russian matryoshka doll which opens to expose another doll that in turn opens to expose another doll, and so on. That may be confusing for Russian speakers, as the Russian word "matroska" (Russian: матроска) actually refers to a sailor suit. The logo uses "Matroška", with the caron over the "s", as the letter š represents the "sh" sound (/ʂ/) in various languages.

RealVideo is a proprietary video codec developed by RealNetworks. It was first released in 1997 and as of 2004 is at version 10. RealVideo is widely used by content owners because of its reach to desktops (Windows, Mac, Linux, Solaris) and mobile phones (Nokia Series 60, Motorola Linux, Samsung, Sony-Ericcson, and LG). RealVideo has historically been used to deliver streaming video across IP networks at low bit rates to desktop personal computers. Today's prevalence of broadband and use of bigger pipes allow video to be encoded at higher bitrates resulting in increased quality and clarity. With mobile carriers, such as Cingular Wireless, starting to offer data services to customers with enabled handsets, video streaming enables consumers to watch video on their mobile phones, be it today's news highlights or even live television.

RealVideo differs from standard video codecs in that it is a proprietory codec that is optimized only for streaming via the proprietary PNA protocol or the Real Time Streaming Protocol. It can be used for download and play (dubbed on-demand) or for live streaming.

RealVideo is often paired with RealAudio and packaged in a RealMedia (.rm) container. The only licensed desktop media player for RealMedia content is RealNetworks' RealPlayer, currently at version 10.5. Unofficial players include MPlayer and Real Alternative.

RealPlayer does not record RealVideo streams, and RealNetworks has advertised this feature to content owners such as broadcasters, film studios, and music labels, as a means of discouraging users from illegally copying content. However, due to the open nature of the Real Time Streaming Protocol, other software exists which can save the streams to files for later viewing.

Sorenson Codec - The Sorenson codec (also known as Sorenson Video Codec, Sorenson Video Quantizer or SVQ) is a digital video codec devised by the company Sorenson Media and used by Apple's QuickTime and, in the newest version of Macromedia Flash, a special version called Sorenson Spark.

The Sorenson codec first appeared in QuickTime 3. With QuickTime 4 it was widely used for the first time at the release of the teaser trailer for Star Wars Episode I: The Phantom Menace on March 11, 1999.

The specifications of the codec were not public, and for a long time the only way to play back Sorenson video was to use Apple's QuickTime player, or the MPlayer for Unix/Linux, which in turn piggy-backed Microsoft Windows DLL-files extracted from Apple's player.

According to an anonymous developer1 of FFmpeg, reverse engineering of the SVQ3 codec revealed it as a tweaked version of H.264. The same developer also added support for this codec to FFmpeg, making native playback on all platforms supported by FFmpeg possible.

Sorenson 3: A codec that is popularly used by Apple's QuickTime, basically the ancestor of H.264. Many of the Quicktime Movie trailers found on the web use this codec.

Audio Codecs

AIFF Audio Interchange File Format (AIFF) is an audio file format standard used for storing sound data on personal computers. The format was co-developed by Apple Computer based on Electronic Arts Interchange File Format (IFF) and is most commonly used on Apple Macintosh computer systems. AIFF is also used by Silicon Graphics Incorporated.

The audio data in an AIFF file is uncompressed big-endian pulse-code modulation (PCM) so the files tend to be much larger than files that use lossless or lossy compression formats such as Ogg and MP3. The AIFF-Compressed (AIFF-C or AIFC) format supports compression ratios as high as 6:1.

WAV (BWAV) WAV (or WAVE), short for WAVE form audio format, is a Microsoft and IBM audio file format standard for storing audio on PCs. It is a variant of the RIFF bitstream format method for storing data in "chunks", and thus also close to the IFF and the AIFF format used on Macintosh computers. It takes into account some differences of the Intel CPU such as little-endian byte order. The RIFF format acts as a "wrapper" for various audio compression codecs. It is the main format used on Windows systems for raw audio.

Though a WAV file can hold audio compressed with any codec, by far the most common format is pulse-code modulation (PCM) audio data. Since PCM uses an uncompressed, lossless storage method, which keeps all the samples of an audio track, professional users or audio experts may use the WAV format for maximum audio quality. WAV audio can also be edited and manipulated with relative ease using software.

Popularity

As file sharing over the Internet has become popular, the WAV format has declined in popularity, primarily because uncompressed WAV files are quite large in size. More frequently, compressed but lossy formats such as MP3, Ogg Vorbis and AAC are used to store and transfer audio, since their smaller file sizes allow for faster transfers over the Internet, and large collections of files consume only a conservative amount of disk space. There are also more efficient, lossless codecs available, such as Monkey's Audio, TTA, WavPack, FLAC, Shorten, Apple Lossless and WMA Lossless.

Limitations

The WAV format is limited to files that are less than 2 gigabytes in size, due to the way its 32-bit file size header is read by most programs. Although this is equivalent to more than 3 hours of CD-quality audio (44.1 kHz, 16-bit stereo), it is sometimes necessary to go over this limit. The W64 format was created for use in Sound Forge. Its 64-bit header allows for much longer recording times. This format can be converted using the libsndfile library.

Audio CDs

Audio CDs do not use WAV as their storage format. The commonality is that both audio CDs and WAV files have the audio data encoded in PCM. WAV is a data file format for computer use. If one were to transfer an audio CD bit stream to WAV files and record them onto a CD-R as a data disc (in ISO format), the CD could not be played in a player that was only designed to play audio CDs.

Μ-law algorithm

In telecommunication, a mu-law algorithm (μ-law) is a standard analog signal compression or companding algorithm, used in digital communications systems of the North American and Japanese digital hierarchies, to optimize (in other words, modify) the dynamic range of an audio analog signal prior to digitizing. It is similar to the A-law algorithm used in Europe.

For a given input x, the equation for μ-law encoding is as follows,

, where μ = 255 (8 bits) in the North American and Japanese standards.

μ-law expansion is then given by the inverse equation:

This encoding is used because speech has a wide dynamic range that does not lend itself well to efficient linear digital encoding. Moreover, perceived intensity (loudness) is logarithmic. Mu-law encoding effectively reduces the dynamic range of the signal, thereby increasing the coding efficiency and resulting in a signal-to-distortion ratio that is greater than that obtained by linear encoding for a given number of bits.

The mu-law algorithm is also used in some rather standard programming language approaches for storing and creating sound (such as the classes in the sun.audio package in Java 1.1, in the .au format, and in some C# methods).

Pulse-code modulation (Encoding)

Pulse-code modulation (PCM) is a digital representation of an analog signal where the magnitude of the signal is sampled regularly at uniform intervals, then quantized to a series of symbols in a digital (usually binary) code. PCM is used in digital telephone systems and is also the standard form for digital audio in computers and various compact disc formats. It is also standard in digital video.

Several Pulse Code Modulation streams may be multiplexed into a larger aggregate data stream. This technique is called time-division multiplexing, or TDM. Digitization as part of the PCM process

In conventional PCM, the analog signal may be processed (e.g. by amplitude compression) before being digitized. Once the signal is digitized, the PCM signal is not subjected to further processing (e.g. digital data compression).

Some forms of PCM combine signal processing with coding. Older versions of these systems applied the processing in the analog domain as part of the A/D process, newer implementations do so in the digital domain. These simple techniques have been largely rendered obsolete by modern transform-based signal compression techniques.

• Differential (or Delta) pulse-code modulation (DPCM) encodes the PCM values as differences between the current and the previous value. For audio this type of encoding reduces the number of bits required per sample by about 25% compared to PCM. • Adaptive DPCM (ADPCM) is a variant of DPCM that varies the size of the quantization step, to allow further reduction of the required bandwidth for a given signal-to-noise ratio (SNR or S/N).

In telephony, a standard audio signal for a single phone call is encoded as 8000 analog samples per second, of 8 bits each, giving a 64 kbit/s digital signal known as DS0. The default encoding on a DS0 is either μ-law (mu-law) PCM (North America) or a-law PCM (Europe and most of the rest of the world). These are logarithmic compression systems where a 12 or 13 bit linear PCM sample number is mapped into an 8 bit value. This system is described by international standard G.711.

Where circuit costs are high and loss of voice quality is acceptable, it sometimes makes sense to compress the voice signal even further. An ADPCM algorithm is used to map a series of 8 bit PCM samples into a series of 4 bit ADPCM samples. In this way, the capacity of the line is doubled. The technique is detailed in the G.726 standard.

Later it was found that even further compression was possible and additional standards were published. Some of these international standards describe systems and ideas which are covered by privately owned patents and thus use of these standards requires payments to the patent holders.

Some ADPCM techniques are used in Voice over IP communications.

Encoding the bitstream as a signal

Pulse-code modulation can be either return-to-zero (RZ) or non-return-to-zero (NRZ). For a NRZ system to be synchronized using in-band information, there must not be long sequences of identical symbols, such as ones or zeroes. For binary PCM systems, the density of 1-symbols is called 'ones-density'.

Ones-density is often controlled using precoding techniques such as Run Length Limited encoding, where the PCM code is expanded into a slightly longer code with a guaranteed bound on ones-density before modulation into the channel. In other cases, extra 'framing' bits are added into the stream which guarantee at least occasional symbol transitions. Another technique used to control ones-density is the use of a 'scrambler' polynomial on the raw data which will tend to turn the raw data stream into a stream that looks pseudo- random, but where the raw stream can be recovered exactly by reversing the effect of the polynomial. In this case, long runs of zeroes or ones are still possible on the output, but are considered unlikely enough to be within normal engineering tolerance.

In other cases, the long term DC value of the modulated signal is important, as building up a DC offset will tend to bias detector circuits out of their operating range. In this case special measures are taken to keep a count of the cumulative DC offset, and to modify the codes if necessary to make the DC offset always tend back to zero.

Many of these codes are bipolar codes, where the pulses can be positive, negative or absent. Typically, non-zero pulses alternate between being positive and negative. These rules may be violated to generate special symbols used for framing or other special purposes.

History of PCM

PCM was invented by the British engineer Alec Reeves in 1937 while working for the International Telephone and Telegraph in France.

The first transmission of speech by pulse code modulation was the SIGSALY voice encryption equipment used for high-level Allied communications during World War II from 1943.