View source for Advanced Video Coding

{{Short description|Widely used standard for video compression}}
{{Redirect-confused|AVC1|AV1|VC-1}}
{{Lead too long|date=May 2023}}
{{Use mdy dates|date=February 2015}}

{{Infobox technology standard
| title = Advanced Video Coding / H.264 / MPEG-4 Part 10
| long_name = Advanced video coding for generic audiovisual services
| status = In force
| year_started = {{Start date and age|2003|p=y}}
| first_published = {{Start date|2004|08|17|df=y}}
| version = 15.0
| version_date = {{Start date|2024|08|13|df=y}}
| organization = [[ITU-T]], [[ISO]], [[International Electrotechnical Commission|IEC]]
| committee = [[ITU-T Study Group 16|SG16]] ([[VCEG]]), [[MPEG]]
| base_standards = [[H.261]], [[H.262]] (aka [[MPEG-2 Video]]), [[H.263]], [[ISO/IEC 14496-2]] (aka MPEG-4 Part 2)
| related_standards = [[H.265]] (aka HEVC), [[H.266]] (aka VVC)
| predecessor       = [[H.263]]
| successor         = [[H.265]]
| abbreviation = 
| domain = [[Video compression]]
| license = [[MPEG LA]]<ref>{{cite tech report |publisher=Library of Congress |location=Washington, D.C. |series=Sustainability of Digital Formats |type=Full draft |title=MPEG-4, Advanced Video Coding (Part 10) (H.264) |date=5 December 2011 |url=https://www.loc.gov/preservation/digital/formats/fdd/fdd000081.shtml |access-date=1 December 2021}}</ref>
| website = {{URL|https://www.itu.int/rec/T-REC-H.264}}
}}

[[File:H.264 block diagram with quality score.jpg|thumb|Block diagram of video coding layer of H.264 encoder with perceptual quality score]]

'''Advanced Video Coding''' ('''AVC'''), also referred to as '''H.264''' or '''MPEG-4 Part 10''', is a [[video compression standard]] based on block-oriented, [[motion compensation|motion-compensated]] coding.<ref>{{Cite web|url=https://www.itu.int/rec/T-REC-H.264|title=H.264 : Advanced video coding for generic audiovisual services|website=www.itu.int|url-status=live|archive-url=https://web.archive.org/web/20191031100750/https://www.itu.int/rec/T-REC-H.264|archive-date=2019-10-31|access-date=2019-11-22}}</ref> It is by far the most commonly used format for the recording, compression, and distribution of video content, used by 84–86% of video industry developers {{as of|November 2023|lc=on}}.<ref>{{cite web|url=https://bitmovin.com/downloads/bitmovin-7th-video-developer-report-2023-2024.pdf|title=Video Developer Report 2023/2024 |website=[[Bitmovin]] |date=November 2023}}</ref> It supports a maximum resolution of [[8K resolution|8K UHD]].<ref>{{Cite news|url=http://www.mysterybox.us/blog/2017/2/21/delivering-8k-using-avch264|archive-url=https://web.archive.org/web/20210325084239/https://www.mysterybox.us/blog/2017/2/21/delivering-8k-using-avch264 | archive-date=March 25, 2021|title=Delivering 8K using AVC/H.264|work=Mystery Box|access-date=2017-08-23|language=en-US}}</ref><ref name="Wang" />

The intent of the H.264/AVC project was to create a standard capable of providing good video quality at substantially lower [[bit rate]]s than previous standards (i.e., half or less the bit rate of [[H.262/MPEG-2 Part 2|MPEG-2]], [[H.263]], or [[MPEG-4 Part 2]]), without increasing the complexity of design so much that it would be impractical or excessively expensive to implement. This was achieved with features such as a reduced-complexity integer [[discrete cosine transform]] (integer DCT),<ref name="apple"/> variable block-size segmentation, and multi-picture [[inter frame|inter-picture prediction]]. An additional goal was to provide enough flexibility to allow the standard to be applied to a wide variety of applications on a wide variety of networks and systems, including low and high bit rates, low and high resolution video, [[Broadcasting|broadcast]], [[DVD]] storage, [[Real-time Transport Protocol|RTP]]/[[Internet Protocol|IP]] packet networks, and [[ITU-T]] multimedia [[telephony]] systems. The H.264 standard can be viewed as a "family of standards" composed of a number of different profiles, although its "High profile" is by far the most commonly used format. A specific decoder decodes at least one, but not necessarily all profiles. The standard describes the format of the encoded data and how the data is decoded, but it does not specify algorithms for encoding—that is left open as a matter for encoder designers to select for themselves, and a wide variety of encoding schemes have been developed. H.264 is typically used for [[lossy compression]], although it is also possible to create truly [[lossless compression|lossless-coded]] regions within lossy-coded pictures or to support rare use cases for which the entire encoding is lossless.

H.264 was standardized by the [[ITU-T]] [[Video Coding Experts Group]] (VCEG) of [[ITU-T Study Group 16|Study Group 16]] together with the [[ISO/IEC JTC 1]] [[Moving Picture Experts Group]] (MPEG). The project partnership effort is known as the Joint Video Team (JVT). The ITU-T H.264 standard and the ISO/IEC [[MPEG-4]]&nbsp;AVC standard (formally, ISO/IEC&nbsp;14496-10&nbsp;– MPEG-4 Part 10, Advanced Video Coding) are jointly maintained so that they have identical technical content. The final drafting work on the first version of the standard was completed in May 2003, and various extensions of its capabilities have been added in subsequent editions. [[High Efficiency Video Coding]] (HEVC), a.k.a. H.265 and MPEG-H Part 2 is a successor to H.264/MPEG-4&nbsp;AVC developed by the same organizations, while earlier standards are still in common use.

H.264 is perhaps best known as being the most commonly used video encoding format on [[Blu-ray Disc]]s. It is also widely used by streaming Internet sources, such as videos from [[Netflix]], [[Hulu]], [[Amazon Prime Video]], [[Vimeo]], [[YouTube]], and the [[iTunes Store]], Web software such as the [[Adobe Flash Player]] and [[Microsoft Silverlight]], and also various [[HDTV]] broadcasts over terrestrial ([[Advanced Television Systems Committee standards|ATSC]], [[ISDB-T]], [[DVB-T]] or [[DVB-T2]]), cable ([[DVB-C]]), and satellite ([[DVB-S]] and [[DVB-S2]]) systems.

H.264 is restricted by [[patent]]s owned by various parties. A license covering most (but not all{{cn|date=February 2024}}) patents essential to H.264 is administered by a [[patent pool]] formerly administered by [[MPEG LA]]. Via Licensing Corp acquired MPEG LA in April 2023 and formed a new patent pool administration company called [[Via-LA|Via Licensing Alliance]].<ref>{{citation |url=https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=158547 |title=Via LA's Heath Hoglund Talks MPEG LA/Via Licensing Patent Pool Merger |first=Jan |last=Ozer |date=2023-05-08 |publisher=StreamingMedia.com}}</ref>  The commercial use of patented H.264 technologies requires the payment of royalties to Via and other patent owners. MPEG LA has allowed the free use of H.264 technologies for streaming Internet video that is free to end users, and [[Cisco]] paid royalties to MPEG LA on behalf of the users of binaries for its [[Open-source software|open source]] H.264 encoder [[openH264]].

== Naming ==
The H.264 name follows the [[ITU-T]] [[ITU-T#Recommendation categorization|naming convention]], where Recommendations are given a letter corresponding to their series and a recommendation number within the series. H.264 is part of "H-Series Recommendations: Audiovisual and multimedia systems". H.264 is further categorized into "H.200-H.499: Infrastructure of audiovisual services" and "H.260-H.279: [[Video encoding|Coding]] of moving video".<ref>{{Cite web |title=ITU-T Recommendations |url=https://www.itu.int:443/en/ITU-T/publications/Pages/recs.aspx |access-date=2022-11-01 |website=ITU |language=en-US}}</ref> The MPEG-4 AVC name relates to the naming convention in [[International Organization for Standardization|ISO]]/[[International Electrotechnical Commission|IEC]] [[MPEG]], where the standard is part 10 of ISO/IEC 14496, which is the suite of standards known as MPEG-4. The standard was developed jointly in a partnership of VCEG and MPEG, after earlier development work in the ITU-T as a VCEG project called H.26L. It is thus common to refer to the standard with names such as H.264/AVC, AVC/H.264, H.264/MPEG-4 AVC, or MPEG-4/H.264 AVC, to emphasize the common heritage. Occasionally, it is also referred to as "the JVT codec", in reference to the Joint Video Team (JVT) organization that developed it. (Such partnership and multiple naming is not uncommon. For example, the video compression standard known as MPEG-2 also arose from the partnership between [[MPEG]] and the ITU-T, where MPEG-2 video is known to the ITU-T community as H.262.<ref>{{cite web|url=http://itu.int/rec/T-REC-H.262|title=H.262 : Information technology&nbsp;— Generic coding of moving pictures and associated audio information: Video|access-date=2007-04-15}}</ref>) Some software programs (such as [[VLC media player]]) internally identify this standard as AVC1.

== History ==
=== Overall history ===
In early 1998, the [[Video Coding Experts Group]] (VCEG&nbsp;– ITU-T SG16 Q.6) issued a call for proposals on a project called H.26L, with the target to double the coding efficiency (which means halving the bit rate necessary for a given level of fidelity) in comparison to any other existing video coding standards for a broad variety of applications. [[VCEG]] was chaired by [[Gary Sullivan (engineer)|Gary Sullivan]] ([[Microsoft]], formerly [[PictureTel]], U.S.). The first draft design for that new standard was adopted in August 1999. In 2000, [[Thomas Wiegand]] ([[Fraunhofer Institute for Telecommunications|Heinrich Hertz Institute]], Germany) became VCEG co-chair.

In December 2001, VCEG and the Moving Picture Experts Group ([[MPEG]]&nbsp;– [[ISO/IEC JTC 1/SC 29]]/WG 11) formed a Joint Video Team (JVT), with the charter to finalize the video coding standard.<ref name=JVTsite>[http://www.itu.int/en/ITU-T/studygroups/com16/video/Pages/jvt.aspx Joint Video Team], [[ITU-T]] Web site.</ref> Formal approval of the specification came in March 2003. The JVT was (is) chaired by [[Gary Sullivan (engineer)|Gary Sullivan]], [[Thomas Wiegand]], and Ajay Luthra ([[Motorola]], U.S.: later [[Arris Group|Arris]], U.S.). In July 2004, the Fidelity Range Extensions (FRExt) project was finalized. From January 2005 to November 2007, the JVT was working on an extension of H.264/AVC towards scalability by an Annex (G) called [[Scalable Video Coding]] (SVC). The JVT management team was extended by [[Jens-Rainer Ohm]] ([[RWTH Aachen University]], Germany). From July 2006 to November 2009, the JVT worked on [[Multiview Video Coding]] (MVC), an extension of H.264/AVC towards [[3D television]] and limited-range [[free-viewpoint television]]. That work included the development of two new profiles of the standard: the Multiview High Profile and the Stereo High Profile.

Throughout the development of the standard, additional messages for containing supplemental enhancement information (SEI) have been developed. SEI messages can contain various types of data that indicate the timing of the video pictures or describe various properties of the coded video or how it can be used or enhanced. SEI messages are also defined that can contain arbitrary user-defined data. SEI messages do not affect the core decoding process, but can indicate how the video is recommended to be post-processed or displayed. Some other high-level properties of the video content are conveyed in video usability information (VUI), such as the indication of the [[color space]] for interpretation of the video content. As new color spaces have been developed, such as for [[High-dynamic-range video|high dynamic range]] and [[wide color gamut]] video, additional VUI identifiers have been added to indicate them.

=== Fidelity range extensions and professional profiles ===
The standardization of the first version of H.264/AVC was completed in May 2003. In the first project to extend the original standard, the JVT then developed what was called the Fidelity Range Extensions (FRExt). These extensions enabled higher quality video coding by supporting increased sample bit depth precision and higher-resolution color information, including the sampling structures known as [[YCbCr|Y′C<sub>B</sub>C<sub>R</sub>]] 4:2:2 (a.k.a. [[YUV 4:2:2]]) and 4:4:4. Several other features were also included in the FRExt project, such as adding an 8×8 integer [[discrete cosine transform]] (integer DCT) with adaptive switching between the 4×4 and 8×8 transforms, encoder-specified perceptual-based quantization weighting matrices, efficient inter-picture lossless coding, and support of additional color spaces. The design work on the FRExt project was completed in July 2004, and the drafting work on them was completed in September 2004.

Five other new profiles (see version 7 below) intended primarily for professional applications were then developed, adding extended-gamut color space support, defining additional aspect ratio indicators, defining two additional types of "supplemental enhancement information" (post-filter hint and tone mapping), and deprecating one of the prior FRExt profiles (the High 4:4:4 profile) that industry feedback{{By whom|date=December 2016}} indicated should have been designed differently.

=== Scalable video coding ===
The next major feature added to the standard was [[Scalable Video Coding]] (SVC). Specified in Annex G of H.264/AVC, SVC allows the construction of bitstreams that contain ''layers'' of sub-bitstreams that also conform to the standard, including one such bitstream known as the "base layer" that can be decoded by a H.264/AVC [[codec]] that does not support SVC. For temporal bitstream scalability (i.e., the presence of a sub-bitstream with a smaller temporal sampling rate than the main bitstream), complete [[Network Abstraction Layer#Access Units|access unit]]s are removed from the bitstream when deriving the sub-bitstream. In this case, high-level syntax and inter-prediction reference pictures in the bitstream are constructed accordingly. On the other hand, for spatial and quality bitstream scalability (i.e. the presence of a sub-bitstream with lower spatial resolution/quality than the main bitstream), the NAL ([[Network Abstraction Layer]]) is removed from the bitstream when deriving the sub-bitstream. In this case, inter-layer prediction (i.e., the prediction of the higher spatial resolution/quality signal from the data of the lower spatial resolution/quality signal) is typically used for efficient coding. The [[Scalable Video Coding]] extensions were completed in November 2007.

=== Multiview video coding ===
The next major feature added to the standard was [[Multiview Video Coding]] (MVC). Specified in Annex H of H.264/AVC, MVC enables the construction of bitstreams that represent more than one view of a video scene. An important example of this functionality is [[stereoscopy|stereoscopic 3D]] video coding. Two profiles were developed in the MVC work: Multiview High profile supports an arbitrary number of views, and Stereo High profile is designed specifically for two-view stereoscopic video. The Multiview Video Coding extensions were completed in November 2009.

=== 3D-AVC and MFC stereoscopic coding ===
Additional extensions were later developed that included 3D video coding with joint coding of [[depth map]]s and texture (termed 3D-AVC), multi-resolution frame-compatible (MFC) stereoscopic and 3D-MFC coding, various additional combinations of features, and higher frame sizes and frame rates.

=== Versions ===
Versions of the H.264/AVC standard include the following completed revisions, corrigenda, and amendments (dates are final approval dates in ITU-T, while final "International Standard" approval dates in ISO/IEC are somewhat different and slightly later in most cases). Each version represents changes relative to the next lower version that is integrated into the text.

* Version 1 (Edition 1): (May 30, 2003) First approved version of H.264/AVC containing Baseline, Main, and Extended profiles.<ref name=AVCV1March2003ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (05/2003) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=6312 |date=2003-05-30 |access-date=2013-04-18}}</ref>
* Version 2 (Edition 1.1): (May 7, 2004) Corrigendum containing various minor corrections.<ref name=AVCV1CorMay2004ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (05/2003) Cor. 1 (05/2004) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=7255 |date=2004-05-07 |access-date=2013-04-18}}</ref>
* Version 3 (Edition 2): (March 1, 2005) Major addition containing the first amendment, establishing the Fidelity Range Extensions (FRExt). This version added the High, High 10, High 4:2:2, and High 4:4:4 profiles.<ref name=AVCV2March2005ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (03/2005) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=7825 |date=2005-03-01 |access-date=2013-04-18}}</ref> After a few years, the High profile became the most commonly used profile of the standard.
* Version 4 (Edition 2.1): (September 13, 2005) Corrigendum containing various minor corrections and adding three aspect ratio indicators.<ref name=AVCV2September2005ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (2005) Cor. 1 (09/2005) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=8572 |date=2005-09-13 |access-date=2013-04-18}}</ref>
* Version 5 (Edition 2.2): (June 13, 2006) Amendment consisting of removal of prior High 4:4:4 profile (processed as a corrigendum in ISO/IEC).<ref name=AVCV2June2006ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (2005) Amd. 1 (06/2006) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=8811 |date=2006-06-13 |access-date=2013-04-18}}</ref>
* Version 6 (Edition 2.2): (June 13, 2006) Amendment consisting of minor extensions like extended-gamut color space support (bundled with above-mentioned aspect ratio indicators in ISO/IEC).<ref name=AVCV2June2006ITURecommendations/>
* Version 7 (Edition 2.3): (April 6, 2007) Amendment containing the addition of the High 4:4:4 Predictive profile and four Intra-only profiles (High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra, and CAVLC 4:4:4 Intra).<ref name=AVCV2April2007ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (2005) Amd. 2 (04/2007) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=9036 |date=2007-04-06 |access-date=2013-04-18}}</ref>
* Version 8 (Edition 3): (November 22, 2007) Major addition to H.264/AVC containing the amendment for [[Scalable Video Coding]] (SVC) containing Scalable Baseline, Scalable High, and Scalable High Intra profiles.<ref name=AVCV3November2007ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (11/2007) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=9226 |date=2007-11-22 |access-date=2013-04-18}}</ref>
* Version 9 (Edition 3.1): (January 13, 2009) Corrigendum containing minor corrections.<ref name=AVCV3January2009ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (2007) Cor. 1 (01/2009) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=9519 |date=2009-01-13 |access-date=2013-04-18}}</ref>
* Version 10 (Edition 4): (March 16, 2009) Amendment containing definition of a new profile (the Constrained Baseline profile) with only the common subset of capabilities supported in various previously specified profiles.<ref name=AVCV4March2009ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (03/2009) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=9710 |date=2009-03-16 |access-date=2013-04-18}}</ref>
* Version 11 (Edition 4): (March 16, 2009) Major addition to H.264/AVC containing the amendment for [[Multiview Video Coding]] (MVC) extension, including the Multiview High profile.<ref name=AVCV4March2009ITURecommendations/>
* Version 12 (Edition 5): (March 9, 2010) Amendment containing definition of a new MVC profile (the Stereo High profile) for two-view video coding with support of interlaced coding tools and specifying an additional supplemental enhancement information (SEI) message termed the frame packing arrangement SEI message.<ref name=AVCV5March2010ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (03/2010) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=10635 |date=2010-03-09 |access-date=2013-04-18}}</ref>
* Version 13 (Edition 5): (March 9, 2010) Corrigendum containing minor corrections.<ref name=AVCV5March2010ITURecommendations/>
* Version 14 (Edition 6): (June 29, 2011) Amendment specifying a new level (Level 5.2) supporting higher processing rates in terms of maximum macroblocks per second, and a new profile (the Progressive High profile) supporting only the frame coding tools of the previously specified High profile.<ref name=AVCV6June2011ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (06/2011) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11293 |date=2011-06-29 |access-date=2013-04-18}}</ref>
* Version 15 (Edition 6): (June 29, 2011) Corrigendum containing minor corrections.<ref name=AVCV6June2011ITURecommendations/>
* Version 16 (Edition 7): (January 13, 2012) Amendment containing definition of three new profiles intended primarily for real-time communication applications: the Constrained High, Scalable Constrained Baseline, and Scalable Constrained High profiles.<ref name=AVCV7January2012ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (01/2012) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11466 |date=2012-01-13 |access-date=2013-04-18}}</ref>
* Version 17 (Edition 8): (April 13, 2013) Amendment with additional SEI message indicators.<ref name=AVC8June2013ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (04/2013) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11830 |date=2013-06-12 |access-date=2013-06-16}}</ref>
* Version 18 (Edition 8): (April 13, 2013) Amendment to specify the coding of depth map data for 3D stereoscopic video, including a Multiview Depth High profile.<ref name=AVC8June2013ITURecommendations/>
* Version 19 (Edition 8): (April 13, 2013) Corrigendum to correct an error in the sub-bitstream extraction process for multiview video.<ref name=AVC8June2013ITURecommendations/>
* Version 20 (Edition 8): (April 13, 2013) Amendment to specify additional [[color space]] identifiers (including support of [[Rec. 2020|ITU-R Recommendation BT.2020]] for [[Ultra-high-definition television|UHDTV]]) and an additional model type in the tone mapping information SEI message.<ref name=AVC8June2013ITURecommendations/>
* Version 21 (Edition 9): (February 13, 2014) Amendment to specify the Enhanced Multiview Depth High profile.<ref name=AVC9February2014ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (02/2014) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12063 |date=2014-11-28 |access-date=2016-02-28}}</ref>
* Version 22 (Edition 9): (February 13, 2014) Amendment to specify the multi-resolution frame compatible (MFC) enhancement for 3D stereoscopic video, the MFC High profile, and minor corrections.<ref name=AVC9February2014ITURecommendations/>
* Version 23 (Edition 10): (February 13, 2016) Amendment to specify MFC stereoscopic video with depth maps, the MFC Depth High profile, the mastering display color volume SEI message, and additional color-related VUI codepoint identifiers.<ref name=AVC13February2016ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (02/2016) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12641 |date=2016-02-13 |access-date=2017-06-14}}</ref>
* Version 24 (Edition 11): (October 14, 2016) Amendment to specify additional levels of decoder capability supporting larger picture sizes (Levels 6, 6.1, and 6.2), the green metadata SEI message, the alternative depth information SEI message, and additional color-related VUI codepoint identifiers.<ref name=AVC14October2016ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (10/2016) |publisher=ITU |url=http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12904 |date=2016-10-14 |access-date=2017-06-14}}</ref>
* Version 25 (Edition 12): (April 13, 2017) Amendment to specify the Progressive High 10 profile, [[hybrid log–gamma]] (HLG), and additional color-related VUI code points and SEI messages.<ref name=AVC13April2017ITURecommendations>{{cite news |title=ITU-T Recommendation H.264 (04/2017) |publisher=ITU |url=https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=13189 |date=2017-04-13 |access-date=2017-06-14 |at=See Tables A-1, A-6 and A-7 for the tabulated level-dependent capabilities.}}</ref>
* Version 26 (Edition 13): (June 13, 2019) Amendment to specify additional SEI messages for ambient viewing environment, content light level information, content color volume, equirectangular projection, cubemap projection, sphere rotation, region-wise packing, omnidirectional viewport, SEI manifest, and SEI prefix.<ref>{{Cite web|date=June 13, 2019|title=H.264: Advanced video coding for generic audiovisual services - Version 26 (Edition 13)|url=https://handle.itu.int/11.1002/1000/13903|url-status=live|archive-url=https://web.archive.org/web/20211104102930/https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=13903&lang=en|archive-date=2021-11-04|access-date=2021-11-03|website=www.itu.int}}</ref>
*Version 27 (Edition 14): (August 22, 2021) Amendment to specify additional SEI messages for annotated regions and shutter interval information, and miscellaneous minor corrections and clarifications.<ref>{{Cite web|date=August 22, 2021|title=H.264: Advanced video coding for generic audiovisual services - Version 27 (Edition 14)|url=https://handle.itu.int/11.1002/1000/14659|url-status=live|archive-url=https://web.archive.org/web/20211104103832/https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=14659&lang=en|archive-date=2021-11-04|access-date=2021-11-03|website=www.itu.int}}</ref>
*Version 28 (Edition 15): (August 13, 2024) Amendment to specify additional SEI messages for neural-network postfilter characteristics, neural-network post-filter activation, and phase indication, additional colour type identifiers, and miscellaneous minor corrections and clarifications.<ref>{{Cite web|date=August 13, 2024|title=H.264: Advanced video coding for generic audiovisual services - Version 28 (Edition 15)|url=https://handle.itu.int/11.1002/1000/15935|access-date=2025-02-12|website=www.itu.int}}</ref>

== Applications ==
{{Further|List of video services using H.264/MPEG-4 AVC}}
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% or more compared to [[MPEG-2 Part 2]] 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&nbsp;Mbit/s and H.264 at only 1.5&nbsp;Mbit/s.<ref>{{cite journal |author=Wenger|title=RFC 3984 : RTP Payload Format for H.264 Video |newspaper=Ietf Datatracker |date=February 2005 |url=http://tools.ietf.org/html/rfc3984#page-2 |page=2|doi=10.17487/RFC3984 |display-authors=etal|url-access=subscription }}</ref> Sony claims that 9&nbsp;Mbit/s AVC recording mode is equivalent to the image quality of the [[HDV]] format, which uses approximately 18–25&nbsp;Mbit/s.<ref>{{cite web|title=Which recording mode is equivalent to the image quality of the High Definition Video (HDV) format?|website=Sony eSupport|url=https://ca.en.kb.sony.com/app/answers/detail/a_id/41994|access-date=December 8, 2018|archive-url=https://web.archive.org/web/20171109054553/https://ca.en.kb.sony.com/app/answers/detail/a_id/41994|archive-date=November 9, 2017|url-status=dead|df=mdy-all}}</ref>

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 three mandatory video compression formats. The Digital Video Broadcast project ([[Digital Video Broadcasting|DVB]]) approved the use of H.264/AVC for broadcast television in late 2004.

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.<ref>{{cite web |url=http://www.atsc.org/cms/standards/a_72_part_1.pdf |title=ATSC Standard A/72 Part 1: Video System Characteristics of AVC in the ATSC Digital Television System |access-date=2011-07-30 |url-status=dead |archive-url=https://web.archive.org/web/20110807103348/http://www.atsc.org/cms/standards/a_72_part_1.pdf |archive-date=August 7, 2011 |df=mdy-all }}</ref><ref>{{cite web |url=http://www.atsc.org/cms/standards/a_72_part_2.pdf |title=ATSC Standard A/72 Part 2: AVC Video Transport Subsystem Characteristics |access-date=2011-07-30 |archive-url=https://web.archive.org/web/20110807103411/http://www.atsc.org/cms/standards/a_72_part_2.pdf |archive-date=August 7, 2011 |url-status=dead |df=mdy-all }}</ref> 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.<ref>{{cite web |url=http://atsc.org/cms/standards/a153/a_153-Part-7-2009.pdf |title=ATSC Standard A/153 Part 7: AVC and SVC Video System Characteristics |access-date=2011-07-30 |url-status=dead |archive-url=https://web.archive.org/web/20110726151422/http://atsc.org/cms/standards/a153/a_153-Part-7-2009.pdf |archive-date=July 26, 2011 |df=mdy-all }}</ref>

The [[closed-circuit television|closed-circuit-television and video-surveillance]] markets have included the technology in many products.

Many common [[DSLR]]s use H.264 video wrapped in QuickTime MOV containers as the native recording format.

=== Derived formats ===
[[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).

[[AVC-Intra]] is an [[Video compression#Encoding theory|intraframe]]-only compression format, developed by [[Panasonic]].

[[XAVC]] is a recording format designed by Sony that uses level 5.2 of H.264/MPEG-4 AVC, which is the highest level supported by that video standard.<ref name=SonyXAVCrecordingformat>{{cite news |title=Sony introduces new XAVC recording format to accelerate 4K development in the professional and consumer markets |publisher=Sony |url=http://www.sony.co.uk/pro/article/broadcast-xavc-codec-1012 |date=2012-10-30 |access-date=2012-11-01}}</ref><ref name=SonyXAVCrecordingformatpdf>{{cite news |title=Sony introduces new XAVC recording format to accelerate 4K development in the professional and consumer markets |publisher=Sony |url=http://www.xavc-info.org/resource/1351573070000/xavcsite/share/data/XAVC_30-Oct-2012_NewsRelease.pdf |archive-url=https://web.archive.org/web/20230323100304/http://www.xavc-info.org/resource/1351573070000/xavcsite/share/data/XAVC_30-Oct-2012_NewsRelease.pdf |url-status=dead |archive-date=March 23, 2023 |date=2012-10-30 |access-date=2012-11-01 }}</ref> XAVC can support [[4K resolution]] (4096 × 2160 and 3840 × 2160) at up to 60&nbsp;[[frames per second]] (fps).<ref name=SonyXAVCrecordingformat/><ref name=SonyXAVCrecordingformatpdf/> Sony has announced that cameras that support XAVC include two [[CineAlta]] cameras—the Sony PMW-F55 and Sony PMW-F5.<ref name=Engadget4KCineAltaF55F5>{{cite news |title=Sony goes Red-hunting with PMW-F55 and PMW-F5 pro CineAlta 4K Super 35mm sensor camcorders |publisher=Engadget |url=https://www.engadget.com/2012/10/30/sony-goes-red-hunting-with-pmw-f55-and-pmw-f5-pro-cinealta-4k/ |author=Steve Dent |date=2012-10-30 |access-date=2012-11-05}}</ref> The Sony PMW-F55 can record XAVC with 4K resolution at 30&nbsp;fps at 300 [[Mbit/s]] and 2K resolution at 30&nbsp;fps at 100&nbsp;Mbit/s.<ref name=SonyPMW-F55datasheet>{{cite news |title=F55 CineAlta 4K the future, ahead of schedule |publisher=Sony |url=http://pro.sony.com/bbsccms/assets/files/show/highend/pdf/F55_Camera.pdf |date=2012-10-30 |access-date=2012-11-01 |url-status=dead |archive-url=https://web.archive.org/web/20121119001306/http://pro.sony.com/bbsccms/assets/files/show/highend/pdf/F55_Camera.pdf |archive-date=November 19, 2012 |df=mdy-all }}</ref> XAVC can record 4K resolution at 60&nbsp;fps with 4:2:2 chroma sampling at 600&nbsp;Mbit/s.<ref name=SonySxSPro4Kvideo>{{cite news |title=Ultra-fast "SxS PRO+" memory cards transform 4K video capture |publisher=Sony |url=http://www.sony.co.uk/pro/article/km-rme-sxspro+-launch |access-date=2012-11-05 |url-status=dead |archive-url=https://web.archive.org/web/20130308090520/http://www.sony.co.uk/pro/article/km-rme-sxspro+-launch |archive-date=March 8, 2013 |df=mdy-all }}</ref><ref name=SonySxSPro4Kvideopdf>{{cite news |title=Ultra-fast "SxS PRO+" memory cards transform 4K video capture |publisher=Sony |url=http://www.sony.co.uk/res/attachment/file/60/1237488996260.pdf |access-date=2012-11-05 |url-status=dead |archive-url=https://web.archive.org/web/20150402123222/http://www.sony.co.uk/res/attachment/file/60/1237488996260.pdf |archive-date=April 2, 2015 |df=mdy-all }}</ref>

== Design ==

=== Features ===
[[File:H.264 block diagram with quality score.jpg|thumb|150px|Block diagram of H.264]]
H.264/AVC/MPEG-4 Part 10 contains a number of new features that allow it to compress video much more efficiently than older standards and to provide more flexibility for application to a wide variety of network environments. In particular, some such key features include:

* Multi-picture [[inter frame|inter-picture prediction]] including the following features:
** Using previously encoded pictures as references in a much more flexible way than in past standards, allowing up to 16 reference frames (or 32 reference fields, in the case of interlaced encoding) to be used in some cases. In profiles that support non-[[Network Abstraction Layer#Coded Video Sequences|IDR]] frames, most levels specify that sufficient buffering should be available to allow for at least 4 or 5 reference frames at maximum resolution. This is in contrast to prior standards, where the limit was typically one; or, in the case of conventional "[[Video compression picture types#Bi-directional predicted frames/slices (B-frames/slices)|B&nbsp;pictures]]" (B-frames), two.
** Variable block-size [[motion compensation]] (VBSMC) with block sizes as large as 16×16 and as small as 4×4, enabling precise segmentation of moving regions. The supported [[Luma (video)|luma]] prediction block sizes include 16×16, 16×8, 8×16, 8×8, 8×4, 4×8, and 4×4, many of which can be used together in a single macroblock. Chroma prediction block sizes are correspondingly smaller when [[chroma subsampling]] is used.
** The ability to use multiple motion vectors per macroblock (one or two per partition) with a maximum of 32 in the case of a B macroblock constructed of 16 4×4 partitions. The motion vectors for each 8×8 or larger partition region can point to different reference pictures.
** The ability to use any macroblock type in [[Video compression picture types#Bi-directional predicted frames/slices (B-frames/slices)|B-frames]], including I-macroblocks, resulting in much more efficient encoding when using B-frames. This feature was notably left out from [[MPEG-4 ASP]].
** Six-tap filtering for derivation of half-pel luma sample predictions, for sharper subpixel motion-compensation. Quarter-pixel motion is derived by linear interpolation of the halfpixel values, to save processing power.
** [[Qpel|Quarter-pixel]] precision for motion compensation, enabling precise description of the displacements of moving areas. For [[Chrominance|chroma]] the resolution is typically halved both vertically and horizontally (see [[4:2:0]]) therefore the motion compensation of chroma uses one-eighth chroma pixel grid units.
** Weighted prediction, allowing an encoder to specify the use of a scaling and offset when performing motion compensation, and providing a significant benefit in performance in special cases—such as fade-to-black, fade-in, and cross-fade transitions. This includes implicit weighted prediction for B-frames, and explicit weighted prediction for P-frames.
* Spatial prediction from the edges of neighboring blocks for [[Intra-frame|"intra"]] coding, rather than the "DC"-only prediction found in MPEG-2 Part 2 and the transform coefficient prediction found in H.263v2 and MPEG-4 Part 2. This includes luma prediction block sizes of 16×16, 8×8, and 4×4 (of which only one type can be used within each [[macroblock]]).
* Integer [[discrete cosine transform]] (integer DCT),<ref name="Wang">{{cite journal |last1=Wang |first1=Hanli |last2=Kwong |first2=S. |last3=Kok |first3=C. |s2cid=2060937 |title=Efficient prediction algorithm of integer DCT coefficients for H.264/AVC optimization |journal=IEEE Transactions on Circuits and Systems for Video Technology |date=2006 |volume=16 |issue=4 |pages=547–552 |doi=10.1109/TCSVT.2006.871390}}</ref><ref name="Stankovic">{{cite journal |last1=Stanković |first1=Radomir S. |last2=Astola |first2=Jaakko T. |title=Reminiscences of the Early Work in DCT: Interview with K.R. Rao |journal=Reprints from the Early Days of Information Sciences |date=2012 |volume=60 |page=17 |url=http://ticsp.cs.tut.fi/reports/ticsp-report-60-reprint-rao-corrected.pdf#page=18 |access-date=13 October 2019}}</ref><ref>{{cite book |last1=Kwon |first1=Soon-young |last2=Lee |first2=Joo-kyong |last3=Chung |first3=Ki-dong |title=Image Analysis and Processing – ICIAP 2005 |chapter=Half-Pixel Correction for MPEG-2/H.264 Transcoding |series=Lecture Notes in Computer Science |date=2005 |volume=3617 |pages=576–583 |doi=10.1007/11553595_71 |publisher=Springer Berlin Heidelberg|isbn=978-3-540-28869-5 |doi-access=free }}</ref> a type of discrete cosine transform (DCT)<ref name="Stankovic"/> where the transform is an integer approximation of the standard DCT.<ref name="Britanak2010">{{cite book |last1=Britanak |first1=Vladimir |last2=Yip |first2=Patrick C. |last3=Rao |first3=K. R. |author3-link=K. R. Rao |title=Discrete Cosine and Sine Transforms: General Properties, Fast Algorithms and Integer Approximations |date=2010 |publisher=[[Elsevier]] |isbn=9780080464640 |pages=ix, xiii, 1, 141–304 |url=https://books.google.com/books?id=iRlQHcK-r_kC&pg=PA141}}</ref> It has selectable block sizes<ref name="apple">{{cite web |last1=Thomson |first1=Gavin |last2=Shah |first2=Athar |title=Introducing HEIF and HEVC |url=https://devstreaming-cdn.apple.com/videos/wwdc/2017/503i6plfvfi7o3222/503/503_introducing_heif_and_hevc.pdf |publisher=[[Apple Inc.]] |year=2017 |access-date=5 August 2019}}</ref> and exact-match integer computation to reduce complexity, including:
** An exact-match integer 4×4 spatial block transform, allowing precise placement of [[residual frame|residual]] signals with little of the "[[ringing artifact|ringing]]" often found with prior codec designs. It is similar to the standard DCT used in previous standards, but uses a smaller block size and simple integer processing. Unlike the cosine-based formulas and tolerances expressed in earlier standards (such as H.261 and MPEG-2), integer processing provides an exactly specified decoded result.
** An exact-match integer 8×8 spatial block transform, allowing highly correlated regions to be compressed more efficiently than with the 4×4 transform. This design is based on the standard DCT, but simplified and made to provide exactly specified decoding.
** Adaptive encoder selection between the 4×4 and 8×8 transform block sizes for the integer transform operation.
** A secondary [[Hadamard transform]] performed on "DC" coefficients of the primary spatial transform applied to chroma DC coefficients (and also luma in one special case) to obtain even more compression in smooth regions.
* [[Lossless]] macroblock coding features including:
** A lossless "PCM macroblock" representation mode in which video data samples are represented directly,<ref>{{cite web|url=http://www.fastvdo.com/spie04/spie04-h264OverviewPaper.pdf |title=The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions |access-date=2011-07-30}}</ref> allowing perfect representation of specific regions and allowing a strict limit to be placed on the quantity of coded data for each macroblock.
** An enhanced lossless macroblock representation mode allowing perfect representation of specific regions while ordinarily using substantially fewer bits than the PCM mode.
* Flexible [[Interlaced video|interlace]]d-scan video coding features, including:
** Macroblock-adaptive frame-field (MBAFF) coding, using a macroblock pair structure for pictures coded as frames, allowing 16×16 macroblocks in field mode (compared with MPEG-2, where field mode processing in a picture that is coded as a frame results in the processing of 16×8 half-macroblocks).
** Picture-adaptive frame-field coding (PAFF or PicAFF) allowing a freely selected mixture of pictures coded either as complete frames where both fields are combined for encoding or as individual single fields.
* A quantization design including:
** Logarithmic step size control for easier bit rate management by encoders and simplified inverse-quantization scaling
** Frequency-customized quantization scaling matrices selected by the encoder for perceptual-based quantization optimization
* An in-loop [[Deblocking filter (video)|deblocking filter]] that helps prevent the blocking artifacts common to other DCT-based image compression techniques, resulting in better visual appearance and compression efficiency
* An [[entropy encoding|entropy coding]] design including:
** [[Context-adaptive binary arithmetic coding]] (CABAC), an algorithm to losslessly compress syntax elements in the video stream knowing the probabilities of syntax elements in a given context. CABAC compresses data more efficiently than CAVLC but requires considerably more processing to decode.
** [[Context-adaptive variable-length coding]] (CAVLC), which is a lower-complexity alternative to CABAC for the coding of quantized transform coefficient values. Although lower complexity than CABAC, CAVLC is more elaborate and more efficient than the methods typically used to code coefficients in other prior designs.
** A common simple and highly structured [[Variable-length code|variable length coding]] (VLC) technique for many of the syntax elements not coded by CABAC or CAVLC, referred to as [[Exponential-Golomb coding]] (or Exp-Golomb).
* Loss resilience features including:
** A [[Network Abstraction Layer]] (NAL) definition allowing the same video syntax to be used in many network environments. One very fundamental design concept of H.264 is to generate self-contained packets, to remove the header duplication as in MPEG-4's Header Extension Code (HEC).<ref name="rfc3984_3"/> This was achieved by decoupling information relevant to more than one slice from the media stream. The combination of the higher-level parameters is called a parameter set.<ref name="rfc3984_3"/> The H.264 specification includes two types of parameter sets: Sequence Parameter Set (SPS) and Picture Parameter Set (PPS). An active sequence parameter set remains unchanged throughout a coded video sequence, and an active picture parameter set remains unchanged within a coded picture. The sequence and picture parameter set structures contain information such as picture size, optional coding modes employed, and macroblock to slice group map.<ref name="rfc3984_3">RFC 3984, p.3</ref>
** [[Flexible macroblock ordering]] (FMO), also known as slice groups, and arbitrary slice ordering (ASO), which are techniques for restructuring the ordering of the representation of the fundamental regions (''macroblocks'') in pictures. Typically considered an error/loss robustness feature, FMO and ASO can also be used for other purposes.
** Data partitioning (DP), a feature providing the ability to separate more important and less important syntax elements into different packets of data, enabling the application of unequal error protection (UEP) and other types of improvement of error/loss robustness.
** Redundant slices (RS), an error/loss robustness feature that lets an encoder send an extra representation of a picture region (typically at lower fidelity) that can be used if the primary representation is corrupted or lost.
** Frame numbering, a feature that allows the creation of "sub-sequences", enabling temporal scalability by optional inclusion of extra pictures between other pictures, and the detection and concealment of losses of entire pictures, which can occur due to network packet losses or channel errors.
* Switching slices, called SP and SI slices, allowing an encoder to direct a decoder to jump into an ongoing video stream for such purposes as video streaming bit rate switching and "trick mode" operation. When a decoder jumps into the middle of a video stream using the SP/SI feature, it can get an exact match to the decoded pictures at that location in the video stream despite using different pictures, or no pictures at all, as references prior to the switch.
* A simple automatic process for preventing the accidental emulation of [[start code]]s, which are special sequences of bits in the coded data that allow random access into the bitstream and recovery of byte alignment in systems that can lose byte synchronization.
* Supplemental enhancement information (SEI) and video usability information (VUI), which are extra information that can be inserted into the bitstream for various purposes such as indicating the color space used the video content or various constraints that apply to the encoding. SEI messages can contain arbitrary user-defined metadata payloads or other messages with syntax and semantics defined in the standard.
* Auxiliary pictures, which can be used for such purposes as [[alpha compositing]].
* Support of monochrome (4:0:0), 4:2:0, 4:2:2, and 4:4:4 [[chroma sampling]] (depending on the selected profile).
* Support of sample bit depth precision ranging from 8 to 14 bits per sample (depending on the selected profile).
* The ability to encode individual color planes as distinct pictures with their own slice structures, macroblock modes, motion vectors, etc., allowing encoders to be designed with a simple parallelization structure (supported only in the three 4:4:4-capable profiles).
* Picture order count, a feature that serves to keep the ordering of the pictures and the values of samples in the decoded pictures isolated from timing information, allowing timing information to be carried and controlled/changed separately by a system without affecting decoded picture content.

These techniques, along with several others, help H.264 to perform significantly better than any prior standard under a wide variety of circumstances in a wide variety of application environments. H.264 can often perform radically better than MPEG-2 video—typically obtaining the same quality at half of the bit rate or less, especially on high bit rate and high resolution video content.<ref>{{cite web|author=Apple Inc. |url=https://www.apple.com/quicktime/technologies/h264/faq.html |title=H.264 FAQ |publisher=Apple |date=1999-03-26 |access-date=2010-05-17 |url-status=dead |archive-url=https://web.archive.org/web/20100307022217/http://www.apple.com/quicktime/technologies/h264/faq.html |archive-date=March 7, 2010 }}</ref>

Like other ISO/IEC MPEG video standards, H.264/AVC has a reference software implementation that can be freely downloaded.<ref>{{cite web|author=Karsten Suehring |url=http://iphome.hhi.de/suehring/tml/download/ |title=H.264/AVC JM Reference Software Download |publisher=Iphome.hhi.de |access-date=2010-05-17}}</ref> Its main purpose is to give examples of H.264/AVC features, rather than being a useful application ''per se''. Some reference hardware design work has also been conducted in the [[Moving Picture Experts Group]].
The above-mentioned aspects include features in all profiles of H.264. A profile for a codec is a set of features of that codec identified to meet a certain set of specifications of intended applications. This means that many of the features listed are not supported in some profiles. Various profiles of H.264/AVC are discussed in next section.

=== Profiles ===
The standard defines several sets of capabilities, which are referred to as ''profiles'', targeting specific classes of applications. These are declared using a profile code (profile_idc) and sometimes a set of additional constraints applied in the encoder. The profile code and indicated constraints allow a decoder to recognize the requirements for decoding that specific bitstream. (And in many system environments, only one or two profiles are allowed to be used, so decoders in those environments do not need to be concerned with recognizing the less commonly used profiles.) By far the most commonly used profile is the High Profile.

Profiles for non-scalable 2D video applications include the following:

;Constrained Baseline Profile (CBP, 66 with constraint set 1): Primarily for low-cost applications, this profile is most typically used in videoconferencing and mobile applications. It corresponds to the subset of features that are in common between the Baseline, Main, and High Profiles.
;Baseline Profile (BP, 66): Primarily for low-cost applications that require additional data loss robustness, this profile is used in some videoconferencing and mobile applications. This profile includes all features that are supported in the Constrained Baseline Profile, plus three additional features that can be used for loss robustness (or for other purposes such as low-delay multi-point video stream compositing). The importance of this profile has faded somewhat since the definition of the Constrained Baseline Profile in 2009. All Constrained Baseline Profile bitstreams are also considered to be Baseline Profile bitstreams, as these two profiles share the same profile identifier code value.
;Extended Profile (XP, 88): Intended as the streaming video profile, this profile has relatively high compression capability and some extra tricks for robustness to data losses and server stream switching.
;Main Profile (MP, 77): This profile is used for standard-definition digital TV broadcasts that use the MPEG-4 format as defined in the DVB standard.<ref>{{cite web|url=http://www.etsi.org/deliver/etsi_ts/101100_101199/101154/01.09.01_60/ts_101154v010901p.pdf |title=TS 101 154&nbsp;– V1.9.1&nbsp;– Digital Video Broadcasting (DVB); Specification for the use of Video and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream |access-date=2010-05-17}}</ref> It is not, however, used for high-definition television broadcasts, as the importance of this profile faded when the High Profile was developed in 2004 for that application.
;High Profile (HiP, 100): The primary profile for broadcast and disc storage applications, particularly for high-definition television applications (for example, this is the profile adopted by the [[Blu-ray Disc]] storage format and the [[Digital Video Broadcasting|DVB]] HDTV broadcast service).
;Progressive High Profile (PHiP, 100 with constraint set 4): Similar to the High profile, but without support of field coding features.
;Constrained High Profile (100 with constraint set 4 and 5): Similar to the Progressive High profile, but without support of B (bi-predictive) slices.
;High 10 Profile (Hi10P, 110): Going beyond typical mainstream consumer product capabilities, this profile builds on top of the High Profile, adding support for up to 10 bits per sample of decoded picture precision.
;High 4{{!:}}2{{!:}}2 Profile (Hi422P, 122): Primarily targeting professional applications that use interlaced video, this profile builds on top of the High 10 Profile, adding support for the 4:2:2 [[chroma sampling]] format while using up to 10 bits per sample of decoded picture precision.
;High 4{{!:}}4{{!:}}4 Predictive Profile (Hi444PP, 244): This profile builds on top of the High 4:2:2 Profile, supporting up to 4:4:4 chroma sampling, up to 14 bits per sample, and additionally supporting efficient lossless region coding and the coding of each picture as three separate color planes.

For camcorders, editing, and professional applications, the standard contains four additional [[Intra-frame]]-only profiles, which are defined as simple subsets of other corresponding profiles. These are mostly for professional (e.g., camera and editing system) applications:

;High 10 Intra Profile (110 with constraint set 3): The High 10 Profile constrained to all-Intra use.
;High 4{{!:}}2{{!:}}2 Intra Profile (122 with constraint set 3): The High 4:2:2 Profile constrained to all-Intra use.
;High 4{{!:}}4{{!:}}4 Intra Profile (244 with constraint set 3): The High 4:4:4 Profile constrained to all-Intra use.
;CAVLC 4{{!:}}4{{!:}}4 Intra Profile (44): The High 4:4:4 Profile constrained to all-Intra use and to CAVLC entropy coding (i.e., not supporting CABAC).

As a result of the [[Scalable Video Coding]] (SVC) extension, the standard contains five additional ''scalable profiles'', which are defined as a combination of a H.264/AVC profile for the base layer (identified by the second word in the scalable profile name) and tools that achieve the scalable extension:

;Scalable Baseline Profile (83): Primarily targeting video conferencing, mobile, and surveillance applications, this profile builds on top of the Constrained Baseline profile to which the base layer (a subset of the bitstream) must conform. For the scalability tools, a subset of the available tools is enabled.
;Scalable Constrained Baseline Profile (83 with constraint set 5): A subset of the Scalable Baseline Profile intended primarily for real-time communication applications.
;Scalable High Profile (86): Primarily targeting broadcast and streaming applications, this profile builds on top of the H.264/AVC High Profile to which the base layer must conform.
;Scalable Constrained High Profile (86 with constraint set 5): A subset of the Scalable High Profile intended primarily for real-time communication applications.
;Scalable High Intra Profile (86 with constraint set 3): Primarily targeting production applications, this profile is the Scalable High Profile constrained to all-Intra use.

As a result of the [[Multiview Video Coding]] (MVC) extension, the standard contains two ''multiview profiles'':

;Stereo High Profile (128): This profile targets two-view [[stereoscopic]] 3D video and combines the tools of the High profile with the inter-view prediction capabilities of the MVC extension.
;Multiview High Profile (118): This profile supports two or more views using both inter-picture (temporal) and MVC inter-view prediction, but does not support field pictures and macroblock-adaptive frame-field coding.

The Multi-resolution Frame-Compatible (MFC) extension added two more profiles:

;MFC High Profile (134): A profile for stereoscopic coding with two-layer resolution enhancement.
;MFC Depth High Profile (135):

The 3D-AVC extension added two more profiles:

;Multiview Depth High Profile (138): This profile supports joint coding of depth map and video texture information for improved compression of 3D video content.
;Enhanced Multiview Depth High Profile (139): An enhanced profile for combined multiview coding with depth information.

==== Feature support in particular profiles ====
{| class="wikitable"
|-
! Feature
! title="Constrained Baseline Profile" | CBP
! title="Baseline Profile" | BP
! title="Extended Profile" | XP
! title="Main Profile" | MP
! title="Progressive High Profile" | ProHiP
! title="High Profile" | HiP
! title="High 10 Profile" | Hi10P
! title="High 4:2:2 Profile" | Hi422P
! title="High 4:4:4 Predictive Profile" | Hi444PP
|- style="display:none"
! I and P slices
| {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! [[Color depth|Bit depth]] (per sample)
| {{Yes|8}} || {{Yes|8}} || {{Yes|8}} || {{Yes|8}} || {{Yes|8}} || {{Yes|8}} || {{yes|8 to 10}} || {{yes|8 to 10}} || {{yes|8 to 14}}
|-
! [[Chroma subsampling|Chroma]] formats
| {{Yes|4:2:0<br /><br />&nbsp;}} || {{Yes|4:2:0<br /><br />&nbsp;}} || {{Yes|4:2:0<br /><br />&nbsp;}} || {{Yes|4:2:0<br /><br />&nbsp;}} || {{Yes|4:2:0<br /><br />&nbsp;}} || {{Yes|4:2:0<br /><br />&nbsp;}} || {{Yes|4:2:0<br /><br />&nbsp;}} || {{yes|4:2:0/<br />4:2:2<br />&nbsp;}} || {{yes|4:2:0/<br />4:2:2/<br />4:4:4}}
|-
! [[Flexible macroblock ordering|Flexible macroblock ordering (FMO)]]
| {{no}} || {{yes}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! [[Arbitrary slice ordering|Arbitrary slice ordering (ASO)]]
| {{no}} || {{yes}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! Redundant slices (RS)
| {{no}} || {{yes}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! Data Partitioning
| {{no}} || {{no}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! SI and SP slices
| {{no}} || {{no}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! Interlaced coding (PicAFF, MBAFF)
| {{no}} || {{no}} || {{yes}} || {{yes}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! B slices
| {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|- style="display:none"
! Multiple reference frames
| {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|- style="display:none"
! [[Deblocking filter (video)|In-loop deblocking filter]]
| {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|- style="display:none"
! [[CAVLC|CAVLC entropy coding]]
| {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! [[CABAC|CABAC entropy coding]]
| {{no}} || {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! 4:0:0 ([[Monochrome]])
| {{no}} || {{no}} || {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! 8×8 vs. 4×4 transform adaptivity
| {{no}} || {{no}} || {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! Quantization scaling matrices
| {{no}} || {{no}} || {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! Separate C<sub>B</sub> and C<sub>R</sub> QP control
| {{no}} || {{no}} || {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}}
|-
! Separate color plane coding
| {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{yes}}
|-
! Predictive lossless coding
| {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{yes}}
|}

=== Levels ===
As the term is used in the standard, a "''level''" is a specified set of constraints that indicate a degree of required decoder performance for a profile. For example, a level of support within a profile specifies the maximum picture resolution, frame rate, and bit rate that a decoder may use. A decoder that conforms to a given level must be able to decode all bitstreams encoded for that level and all lower levels.
<!-- Please don't change the default state of the table to collapsed using the mw-collapsed option since that causes problems with some web browsers, such as making the customtoggle in the table not work when the page is refreshed or revisited. -->
{| class="wikitable" style="text-align:right;"
|+ Levels with maximum property values<ref name=AVC13April2017ITURecommendations/>
|-
! Level<br>
! Maximum<br>decoding speed<br>(macroblocks/s)
! Maximum<br>frame size<br />(macroblocks)
! Maximum video<br>bit rate for video<br>coding layer (VCL)<br /> (Constrained Baseline,<br>Baseline, Extended<br>and Main Profiles)<br>(kbits/s)
! Examples for high resolution<br>@ highest frame rate<br>(maximum stored frames) <div class="mw-customtoggle-H264MPEG4AVC" style="color:#0B0080; cursor: pointer; border: 1px solid #aaa; border-radius: 10px; padding: 2px; margin-bottom: 5px;">Toggle additional details</div><br>
|-
! 1
| 1,485
| 99
| 64 
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 128×96@30.9 (8)</div>176×144@15.0 (4)
|-
! 1b
| 1,485
| 99
| 128
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 128×96@30.9 (8)</div>176×144@15.0 (4)
|-
! 1.1
| 3,000
| 396
| 192
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 176×144@30.3 (9)<br>320×240@10.0 (3)</div>352×288@7.5 (2)
|-
! 1.2
| 6,000
| 396
| 384
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 320×240@20.0 (7)</div>352×288@15.2 (6)
|-
! 1.3
| 11,880
| 396
| 768
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 320×240@36.0 (7)</div>352×288@30.0 (6)
|-
! 2
| 11,880
| 396
| 2,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 320×240@36.0 (7)</div>352×288@30.0 (6)
|-
! 2.1
| 19,800
| 792
| 4,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 352×480@30.0 (7)</div>352×576@25.0 (6)
|-
! 2.2
| 20,250
| 1,620
| 4,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 352×480@30.7 (12)<br>352×576@25.6 (10)<br>720×480@15.0 (6)</div>720×576@12.5 (5)
|-
! 3
| 40,500
| 1,620
| 10,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 352×480@61.4 (12)<br>352×576@51.1 (10)<br>720×480@30.0 (6)</div>720×576@25.0 (5)
|-
! 3.1
| 108,000
| 3,600
| 14,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 720×480@80.0 (13)<br>720×576@66.7 (11)</div>1,280×720@30.0 (5)
|-
! 3.2
| 216,000
| 5,120
| 20,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 1,280×720@60.0 (5)</div>1,280×1,024@42.2 (4)
|-
! 4
| 245,760
| 8,192
| 20,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 1,280×720@68.3 (9)<br>1,920×1,080@30.1 (4)</div>2,048×1,024@30.0 (4)
|-
! 4.1
| 245,760
| 8,192
| 50,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 1,280×720@68.3 (9)<br>1,920×1,080@30.1 (4)</div>2,048×1,024@30.0 (4)
|-
! 4.2
| 522,240
| 8,704
| 50,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 1,280×720@145.1 (9)<br>1,920×1,080@64.0 (4)</div>2,048×1,080@60.0 (4)
|-
! 5
| 589,824
| 22,080
| 135,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 1,920×1,080@72.3 (13)<br>2,048×1,024@72.0 (13)<br>2,048×1,080@67.8 (12)<br>2,560×1,920@30.7 (5)</div>3,672×1,536@26.7 (5)
|-
! 5.1
| 983,040
| 36,864
| 240,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 1,920×1,080@120.5 (16)<br>2,560×1,920@51.2 (9)<br>3,840×2,160@31.7 (5)<br>4,096×2,048@30.0 (5)<br>4,096×2,160@28.5 (5)</div>4,096×2,304@26.7 (5)
|-
! 5.2
| 2,073,600
| 36,864
| 240,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 1,920×1,080@172.0 (16)<br>2,560×1,920@108.0 (9)<br>3,840×2,160@66.8 (5)<br>4,096×2,048@63.3 (5)<br>4,096×2,160@60.0 (5)</div>4,096×2,304@56.3 (5)
|-
! 6
| 4,177,920
| 139,264
| 240,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 3,840×2,160@128.9 (16)<br />7,680×4,320@32.2 (5)</div>8,192×4,320@30.2 (5)
|-
! 6.1
| 8,355,840
| 139,264
| 480,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 3,840×2,160@257.9 (16)<br />7,680×4,320@64.5 (5)</div>8,192×4,320@60.4 (5)
|-
! 6.2
| 16,711,680
| 139,264
| 800,000
| <div class="mw-collapsible" id="mw-customcollapsible-H264MPEG4AVC"> 3,840×2,160@300.0 (16)<br />7,680×4,320@128.9 (5)</div>8,192×4,320@120.9 (5)
|}

The maximum bit rate for the High Profile is 1.25 times that of the Constrained Baseline, Baseline, Extended and Main Profiles; 3 times for Hi10P, and 4 times for Hi422P/Hi444PP.

The number of luma samples is 16×16=256 times the number of macroblocks (and the number of luma samples per second is 256 times the number of macroblocks per second).

=== Decoded picture buffering ===
Previously encoded pictures are used by H.264/AVC encoders to provide predictions of the values of samples in other pictures. This allows the encoder to make efficient decisions on the best way to encode a given picture. At the decoder, such pictures are stored in a virtual ''decoded picture buffer'' (DPB). The maximum capacity of the DPB, in units of frames (or pairs of fields), as shown in parentheses in the right column of the table above, can be computed as follows:

: {{mono|''DpbCapacity'' {{=}} min(floor(''MaxDpbMbs'' / (''PicWidthInMbs'' * ''FrameHeightInMbs'')), 16)}}

Where {{mono|''MaxDpbMbs''}} is a constant value provided in the table below as a function of level number, and {{mono|''PicWidthInMbs''}} and {{mono|''FrameHeightInMbs''}} are the picture width and frame height for the coded video data, expressed in units of macroblocks (rounded up to integer values and accounting for cropping and macroblock pairing when applicable). This formula is specified in sections A.3.1.h and A.3.2.f of the 2017 edition of the standard.<ref name=AVC13April2017ITURecommendations/>

<div style="overflow-x:auto">
{| class="wikitable" style="text-align:center;width:800px;"
|-
! Level
| '''1'''
| '''1b'''
| '''1.1'''
| '''1.2'''
| '''1.3'''
| '''2'''
| '''2.1'''
| '''2.2'''
| '''3'''
| '''3.1'''
| '''3.2'''
| '''4'''
| '''4.1'''
| '''4.2'''
| '''5'''
| '''5.1'''
| '''5.2'''
| '''6'''
| '''6.1'''
| '''6.2'''
|-
! {{mono|MaxDpbMbs}}
| 396
| 396
| 900
| 2,376
| 2,376
| 2,376
| 4,752
| 8,100
| 8,100
| 18,000
| 20,480
| 32,768
| 32,768
| 34,816
| 110,400
| 184,320
| 184,320
| 696,320
| 696,320
| 696,320
|}</div>

For example, for an HDTV picture that is 1,920 samples wide ({{samp|1=PicWidthInMbs = 120}}) and 1,080 samples high ({{samp|1=FrameHeightInMbs = 68}}), a Level 4 decoder has a maximum DPB storage capacity of {{samp|floor(32768/(120*68))}} = 4 frames (or 8 fields). Thus, the value 4 is shown in parentheses in the table above in the right column of the row for Level 4 with the frame size 1920×1080.

The current picture being decoded is ''not included'' in the computation of DPB fullness (unless the encoder has indicated for it to be stored for use as a reference for decoding other pictures or for delayed output timing). Thus, a decoder needs to actually have sufficient memory to handle (at least) one frame ''more'' than the maximum capacity of the DPB as calculated above.

== Implementations ==
[[File:YouTube H264 video with Opus audio stat screenshot.png|upright=1.2|thumb|A YouTube video statistics with AVC (H.264) video codec and [[Opus (audio format)|Opus]] audio format]]
In 2009, the [[WHATWG|HTML5 working group]] was split between supporters of Ogg [[Theora]], a free video format which is thought to be unencumbered by patents, and H.264, which contains patented technology. As late as July 2009, Google and Apple were said to support H.264, while Mozilla and Opera support Ogg Theora (now Google, Mozilla and Opera all support Theora and [[WebM]] with [[VP8]]).<ref>{{cite web|url=https://arstechnica.com/open-source/news/2009/07/decoding-the-html-5-video-codec-debate.ars |title=Decoding the HTML 5 video codec debate |website=Ars Technica |date=2009-07-06 |access-date=2011-01-12}}</ref> Microsoft, with the release of Internet Explorer 9, has added support for HTML 5 video encoded using H.264. At the Gartner Symposium/ITXpo in November 2010, Microsoft CEO Steve Ballmer answered the question "HTML 5 or [[Silverlight]]?" by saying "If you want to do something that is universal, there is no question the world is going HTML5."<ref>{{cite web|url=https://www.youtube.com/watch?v=iI47b3a9cEI | archive-url=https://ghostarchive.org/varchive/youtube/20211030/iI47b3a9cEI| archive-date=2021-10-30|title= Steve Ballmer, CEO Microsoft, interviewed at Gartner Symposium/ITxpo Orlando 2010 |publisher=Gartnervideo |date=November 2010|access-date=2011-01-12}}{{cbignore}}</ref> In January 2011, Google announced that they were pulling support for H.264 from their Chrome browser and supporting both Theora and WebM/VP8 to use only open formats.<ref>{{cite web|url=https://blog.chromium.org/2011/01/html-video-codec-support-in-chrome.html |title=HTML Video Codec Support in Chrome |date=2011-01-11 |access-date=2011-01-12}}</ref>

On March 18, 2012, [[Mozilla]] announced support for H.264 in Firefox on mobile devices, due to prevalence of H.264-encoded video and the increased power-efficiency of using dedicated H.264 decoder hardware common on such devices.<ref>{{cite web|url=https://hacks.mozilla.org/2012/03/video-mobile-and-the-open-web/ | title=Video, Mobile, and the Open Web|date=2012-03-18|access-date=2012-03-20}}</ref> On February 20, 2013, Mozilla implemented support in Firefox for decoding H.264 on Windows 7 and above. This feature relies on Windows' built in decoding libraries.<ref>{{cite web|title=WebRTC enabled, H.264/MP3 support in Win 7 on by default, Metro UI for Windows 8 + more&nbsp;– Firefox Development Highlights|url=https://hacks.mozilla.org/2013/02/webrtc-enabled-h-264mp3-support-in-win-7-on-by-default-metro-ui-for-windows-8-more-firefox-development-highlights/|work=hacks.mozilla.org|publisher=mozilla|access-date=2013-03-15|date=2013-02-20}}</ref> Firefox 35.0, released on January 13, 2015, supports H.264 on OS X 10.6 and higher.<ref>{{cite web|url=https://www.mozilla.org/en-US/firefox/35.0/releasenotes/|title=Firefox — Notes (35.0)|website=Mozilla}}</ref>

On October 30, 2013, [[Rowan Trollope]] from [[Cisco Systems]] announced that Cisco would release both binaries and source code of an H.264 video codec called [[OpenH264]] under the [[Simplified BSD license]], and pay all royalties for its use to MPEG LA for any software projects that use Cisco's precompiled binaries, thus making Cisco's OpenH264 ''binaries'' free to use. However, any software projects that use Cisco's source code instead of its binaries would be legally responsible for paying all royalties to MPEG LA. Target CPU architectures include x86 and ARM, and target operating systems include Linux, Windows XP and later, Mac OS X, and Android; iOS was notably absent from this list, because it does not allow applications to fetch and install binary modules from the Internet.<ref>{{cite web |url=http://blogs.cisco.com/collaboration/open-source-h-264-removes-barriers-webrtc |title=Open-Sourced H.264 Removes Barriers to WebRTC |date=2013-10-30 |access-date=2013-11-01 |archive-url=https://web.archive.org/web/20150706222941/http://blogs.cisco.com/collaboration/open-source-h-264-removes-barriers-webrtc |archive-date=July 6, 2015 |url-status=dead }}</ref><ref name=OpenH264faq>{{cite web|url=http://www.openh264.org/faq.html |title=Cisco OpenH264 project FAQ |access-date=2021-09-26}}</ref><ref>{{cite web|url=https://github.com/cisco/openh264/blob/master/LICENSE |title=OpenH264 Simplified BSD License |website=[[GitHub]] |date=2013-10-27 |access-date=2013-11-21}}</ref> Also on October 30, 2013, [[Brendan Eich]] from Mozilla wrote that it would use Cisco's binaries in future versions of Firefox to add support for H.264 to Firefox where platform codecs are not available.<ref>{{cite web|url=https://blog.mozilla.org/blog/2013/10/30/video-interoperability-on-the-web-gets-a-boost-from-ciscos-h-264-codec/ |title=Video Interoperability on the Web Gets a Boost From Cisco's H.264 Codec |date=2013-10-30 |access-date=2013-11-01}}</ref> Cisco published the source code to OpenH264 on December 9, 2013.<ref>{{cite web|url=https://github.com/cisco/openh264/commit/59dae50b1069dbd532226ea024a3ba3982ab4386|title=Updated README · cisco/openh264@59dae50|website=GitHub}}</ref>

Although iOS was not supported by the 2013 Cisco software release, Apple updated its Video Toolbox Framework with [[iOS 8]] (released in September 2014) to provide direct access to hardware-based H.264/AVC video encoding and decoding.<ref name=OpenH264faq/>

=== Software encoders ===
{| class="wikitable"
|+ AVC software implementations
! Feature
! [[QuickTime]]
! [[Nero Digital|Nero]]
! [[OpenH264]]
! [[x264]]
! [[MainConcept|Main-<br />Concept]]
! Elecard
! [[Telestream Episode|&nbsp;TSE&nbsp;]]
! [[ProCoder|Pro-<br />Coder]]
! [[Avivo]]
! [[Elemental Technologies|Elemental]]
! [[Integrated Performance Primitives|&nbsp;IPP&nbsp;]]
|-
! B slices
| {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{no}} || {{yes}} || {{yes}}
|-
! Multiple reference frames
| {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{no}} || {{yes}} || {{yes}}
|-
! Interlaced coding (PicAFF, MBAFF)
| {{no}} || {{Yes-No|MBAFF}} || {{Yes-No|MBAFF}} || {{Yes-No|MBAFF}} || {{yes}} || {{yes}} || {{no}} || {{yes}} || {{Yes-No|MBAFF}} ||{{yes}} || {{no}}
|-
! CABAC entropy coding
| {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{no}} || {{yes}} || {{yes}}
|-
! 8×8 vs. 4×4 transform adaptivity
| {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{no}} || {{yes}} || {{yes}}
|-
! Quantization scaling matrices
| {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! Separate C<sub>B</sub> and C<sub>R</sub> QP control
| {{no}} || {{no}} || {{yes}} || {{yes}} || {{yes}} || {{yes}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}
|-
! Extended chroma formats
| {{no|No}} || {{no|No}} || {{no|No}} || {{yes|4:0:0<ref>[http://code.videolan.org/videolan/x264/commit/698c5a32e63a3ed6b976ed196abe479efd78530b "x264 4:0:0 (monochrome) encoding support"], Retrieved 2019-06-05.</ref><br />4:2:0<br />4:2:2<ref>[http://code.videolan.org/videolan/x264/commit/5b0cb86f27ba0c5433c404bed51c06a5124dfb49 "x264 4:2:2 encoding support"], Retrieved 2019-06-05.</ref><br />4:4:4<ref>[http://code.videolan.org/videolan/x264/commit/a93e4c4a75d05e7bf379cb9a39caad57f615eeb0 "x264 4:4:4 encoding support"], Retrieved 2019-06-05.</ref>&nbsp;&nbsp;}} || {{Yes-No|4:2:2}} || {{Yes-No|4:2:2}} || {{Yes-No|4:2:2}} || {{no|No}} || {{no|No}} || {{yes-no|4:2:0<br />4:2:2}} || {{no|No}}
|-
! Largest sample depth (bit)
| {{Yes-No|8}} || {{Yes-No|8}} || {{Yes-No|8}} || {{yes|10<ref>[http://code.videolan.org/videolan/x264/commit/c91f43a4b09dab84953f417e6d6662ec0fa7acb1 "x264 support for 9 and 10-bit encoding"], Retrieved 2011-06-22.</ref>}} || {{yes|10}} || {{Yes-No|8}} || {{Yes-No|8}} || {{Yes-No|8}} || {{Yes-No|8}} || {{Yes|10}} || {{yes|12}}

|-
! Predictive lossless coding
| {{no}} || {{no}} || {{no}} || {{yes|Yes<ref>[http://code.videolan.org/videolan/x264/commit/a9e86d248d8d5f1e892159a7d86dcea2f884a859 "x264 replace High 4:4:4 profile lossless with High 4:4:4 Predictive"], Retrieved 2011-06-22.</ref>}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}} || {{no}}

|}

=== Hardware <span class="anchor" id="HW-BASED"></span>===
{{See also|H.264/MPEG-4 AVC products and implementations}}
Because H.264 encoding and decoding requires significant computing power in specific types of arithmetic operations, software implementations that run on general-purpose CPUs are typically less power efficient. However, the latest{{when|date=January 2020}} quad-core general-purpose x86 CPUs have sufficient computation power to perform real-time SD and HD encoding. Compression efficiency depends on video algorithmic implementations, not on whether hardware or software implementation is used. Therefore, the difference between hardware and software based implementation is more on power-efficiency, flexibility and cost. To improve the power efficiency and reduce hardware form-factor, special-purpose hardware may be employed, either for the complete encoding or decoding process, or for acceleration assistance within a CPU-controlled environment.

CPU based solutions are known to be much more flexible, particularly when encoding must be done concurrently in multiple formats, multiple bit rates and resolutions ([[multi-screen video]]), and possibly with additional features on container format support, advanced integrated advertising features, etc. CPU based software solution generally makes it much easier to load balance multiple concurrent encoding sessions within the same CPU.

The 2nd generation [[Intel]] "[[Sandy Bridge]]" [[Intel Core|Core i3/i5/i7]] processors introduced at the January 2011 CES ([[Consumer Electronics Show]]) offer an on-chip hardware full HD H.264 encoder, known as [[Intel Quick Sync Video]].<ref>{{cite web |url=http://software.intel.com/en-us/articles/quick-reference-guide-to-intel-integrated-graphics/ |title=Quick Reference Guide to generation Intel Core Processor Built-in Visuals |publisher=Intel Software Network |date=2010-10-01 |access-date=2011-01-19}}</ref><ref>{{cite web |url=http://www.intel.com/content/www/us/en/architecture-and-technology/quick-sync-video/quick-sync-video-general.html |title=Intel Quick Sync Video|publisher=www.intel.com |date=2010-10-01 |access-date=2011-01-19}}</ref>

A hardware H.264 encoder can be an [[Application-specific integrated circuit|ASIC]] or an [[Field-programmable gate array|FPGA]].

ASIC encoders with H.264 encoder functionality are available from many different semiconductor companies, but the core design used in the ASIC is typically licensed from one of a few companies such as [[Chips&Media]], Allegro DVT, [[On2]] (formerly Hantro, acquired by Google), [[Imagination Technologies]], NGCodec. Some companies have both FPGA and ASIC product offerings.<ref>{{cite web |url=http://www.design-reuse.com/sip/?q=H.264+encoder |title=Design-reuse.com |publisher=Design-reuse.com |date=1990-01-01 |access-date=2010-05-17}}</ref>

Texas Instruments manufactures a line of ARM + DSP cores that perform DSP H.264 BP encoding 1080p at 30&nbsp;fps.<ref>{{cite web |url=http://processors.wiki.ti.com/index.php/Category:DM6467 |title=Category:DM6467 - Texas Instruments Embedded Processors Wiki |publisher=Processors.wiki.ti.com |date=2011-07-12 |access-date=2011-07-30 |archive-date=July 17, 2011 |archive-url=https://web.archive.org/web/20110717053351/http://processors.wiki.ti.com/index.php/Category:DM6467 |url-status=dead }}</ref> This permits flexibility with respect to codecs (which are implemented as highly optimized DSP code) while being more efficient than software on a generic CPU.

== Licensing ==
{{see also|Microsoft Corp. v. Motorola Inc.|Qualcomm Inc. v. Broadcom Corp.}}
In countries where [[software patent|patents on software algorithms]] are upheld, vendors and commercial users of products that use H.264/AVC are expected to pay patent licensing royalties for the patented technology that their products use.<ref>{{cite web|url=http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf |title=Briefing portfolio |website=www.mpegla.com }}</ref> This applies to the Baseline Profile as well.<ref>{{cite web|url=http://blogs.sun.com/openmediacommons/entry/oms_video_a_project_of|title=OMS Video, A Project of Sun's Open Media Commons Initiative|access-date=2008-08-26|archive-url=https://web.archive.org/web/20100511060302/http://blogs.sun.com/openmediacommons/entry/oms_video_a_project_of|archive-date=May 11, 2010|url-status=dead|df=mdy-all}}</ref>

A private organization known as [[MPEG LA]], which is not affiliated in any way with the MPEG standardization organization, administers the licenses for patents applying to this standard, as well as other [[patent pool]]s, such as for MPEG-4 Part 2 Video, HEVC and MPEG-DASH. The patent holders include [[Fujitsu]], [[Panasonic]], [[Sony]], [[Mitsubishi]], [[Apple Inc.|Apple]], [[Columbia University]], [[KAIST]], [[Dolby Laboratories|Dolby]], [[Google]], [[JVC Kenwood]], [[LG Electronics]], [[Microsoft]], [[NTT Docomo]], [[Philips]], [[Samsung]], [[Sharp Corporation|Sharp]], [[Toshiba]] and [[ZTE]],<ref>{{cite web |title=Licensors Included in the AVC/H.264 Patent Portfolio License |url=https://www.mpegla.com/programs/avc-h-264/licensors/ |website=[[MPEG LA]] |access-date=18 June 2019}}</ref> although the majority of patents in the pool are held by Panasonic ({{formatnum:{{#expr:1137+60}}|}} patents), [[Gōdō gaisha|Godo Kaisha]] IP Bridge ({{formatnum:{{#expr:1111+19}}|}} patents) and LG Electronics ({{#expr:949+(40+1)}} patents).<ref name="patents">{{cite web |title=AVC/H.264 {{ndash}} Patent List |url=https://www.via-la.com/licensing-2/avc-h-264/avc-h-264-patent-list/ |website=Via Licensing Alliance |access-date=28 April 2024}}</ref>

On August 26, 2010, MPEG LA announced that royalties would not be charged for H.264 encoded Internet video that is free to end users.<ref>{{cite web|url=http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/74/n-10-08-26.pdf|title=MPEG LA's AVC License Will Not Charge Royalties for Internet Video that is Free to End Users through Life of License|publisher=MPEG LA|date=2010-08-26|access-date=2010-08-26|archive-date=November 7, 2013|archive-url=https://web.archive.org/web/20131107135621/http://www.mpegla.com/Lists/MPEG%20LA%20News%20List/Attachments/74/n-10-08-26.pdf|url-status=dead}}</ref> All other royalties remain in place, such as royalties for products that decode and encode H.264 video as well as to operators of free television and subscription channels.<ref>{{cite news|url=https://www.pcmag.com/article2/0,2817,2368359,00.asp |title=MPEG LA Cuts Royalties from Free Web Video, Forever |publisher=pcmag.com |date=2010-08-26 |access-date=2010-08-26 |first=Mark |last=Hachman}}</ref> The license terms are updated in 5-year blocks.<ref>{{cite web |url=http://www.mpegla.com/main/programs/AVC/Pages/FAQ.aspx |title=AVC FAQ |publisher=MPEG LA |date=2002-08-01 |access-date=2010-05-17 |archive-url=https://web.archive.org/web/20100507102710/http://www.mpegla.com/main/programs/AVC/Pages/FAQ.aspx |archive-date=May 7, 2010 |url-status=dead }}</ref>

Since the first version of the standard was completed in May 2003 ({{age|month=May|year=2003}} years ago) and the most commonly used profile (the High profile) was completed in June 2004{{Citation needed|date=December 2023}} ({{age|month=June|year=2004}} years ago), some of the relevant patents are expired by now, <ref name="patents" /> while others are still in force in jurisdictions around the world and one of the US patents in the MPEG LA H.264 pool (granted in 2016, priority from 2001) lasts at least until November 2030.<ref>{{cite web |url=https://patents.google.com/patent/US9356620B2/ |title=United States Patent 9,356,620 Baese, et al. |access-date=August 1, 2022}} with an earliest priority date of September 14, 2001 has a 2,998 day term extension.</ref>

In 2005, Qualcomm sued Broadcom in US District Court, alleging that Broadcom infringed on two of its patents by making products that were compliant with the H.264 video compression standard.<ref name="case">See [http://caselaw.lp.findlaw.com/data2/circs/fed/071545p.pdf Qualcomm Inc. v. Broadcom Corp.], No. 2007-1545, 2008-1162 (Fed. Cir. December 1, 2008). For articles in the popular press, see signonsandiego.com, [http://www.signonsandiego.com/news/business/20070127-9999-1b27verdict.html "Qualcomm loses its patent-rights case"] and [http://www.signonsandiego.com/news/business/20070126-9999-1b26qualcomm.html "Qualcomm's patent case goes to jury"]; and bloomberg.com [https://www.bloomberg.com/apps/news?pid=20601204&sid=aLX_DFMCEYWU&refer=technology "Broadcom Wins First Trial in Qualcomm Patent Dispute"]</ref> In 2007, the District Court found that the patents were unenforceable because Qualcomm had failed to disclose them to the JVT prior to the release of the H.264 standard in May 2003.<ref name="case" /> In December 2008, the US Court of Appeals for the Federal Circuit affirmed the District Court's order that the patents be unenforceable but remanded to the District Court with instructions to limit the scope of unenforceability to H.264 compliant products.<ref name="case" />

In October 2023 [[Nokia]] sued [[HP Inc.|HP]] and [[Amazon (company)|Amazon]] for H.264/H.265 patent infringement in USA, UK and other locations.<ref>{{Cite web |title=nokia h264 |url=https://www.nokia.com/blog/nokia-seeks-compensation-for-amazons-use-of-our-patented-multimedia-inventions/}}</ref>

== See also ==
* [[VC-1]], a standard designed by [[Microsoft]] and approved as a [[SMPTE]] standard in 2006
** [[Comparison of H.264 and VC-1]]
* [[Dirac (video compression format)]], a video coding design by [[BBC Research & Development]], released in 2008
* [[VP8]], a video coding design by [[On2 Technologies]] (later purchased by [[Google]]), released in 2008
* [[VP9]], a video coding design by [[Google]], released in 2013
* [[High Efficiency Video Coding]] (ITU-T H.265 or ISO/IEC 23008-2), an ITU/ISO/IEC standard, released in 2013
* [[AV1]], a video coding design by the [[Alliance for Open Media]], released in 2018
* [[Versatile Video Coding]] (ITU-T H.266 or ISO/IEC 23091-3), an ITU/ISO/IEC standard, released in 2020
* [[Internet Protocol television]]
* [[Group of pictures]]
* [[Intra-frame coding]]
* [[Inter frame]]

== References ==
{{reflist|30em}}

== Further reading ==
{{Refbegin}}
* {{Cite journal |url = http://ip.hhi.de/imagecom_G1/assets/pdfs/csvt_overview_0305.pdf |first1 = Thomas |last1 = Wiegand |first2 = Gary J. |last2 = Sullivan |first3 = Gisle |last3 = Bjøntegaard |first4 = Ajay |last4 = Luthra |title = Overview of the H.264/AVC Video Coding Standard |journal = IEEE Transactions on Circuits and Systems for Video Technology |date = July 2003 |volume = 13 |issue = 7 |pages = 560–576 |doi = 10.1109/TCSVT.2003.815165 |access-date = January 31, 2011 }}
* {{Cite journal |url = http://www.fastvdo.com/spie04/spie04-h264OverviewPaper.pdf |first1 = Pankaj |last1 = Topiwala |first2 = Gary J. |last2 = Sullivan |first3 = Ajay |last3 = Luthra |editor1-first = Andrew G |editor1-last = Tescher |s2cid = 2308860 |title = The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions |journal = SPIE Applications of Digital Image Processing XXVII |series = Applications of Digital Image Processing XXVII |date = August 2004 |volume = 5558 |page = 454 |doi = 10.1117/12.564457 |bibcode = 2004SPIE.5558..454S |access-date = January 31, 2011 }}
* {{Cite FTP |url = ftp://ftp.tnt.uni-hannover.de/pub/papers/2004/CASM_2004_MN.pdf |first1 = J. |last1 = Ostermann |first2 = J. |last2 = Bormans |first3 = P. |last3 = List |first4 = D. |last4 = Marpe |first5 = M. |last5 = Narroschke |first6 = F. |last6 = Pereira |first7 = T. |last7 = Stockhammer |first8 = T. |last8 = Wedi |s2cid = 11105089 |title = Video coding with H.264/AVC: Tools, Performance, and Complexity |date = 2004 |volume = 4 |issue = 1 |pages = 7–28 |doi = 10.1109/MCAS.2004.1286980 |server = IEEE Circuits and Systems Magazine |url-status = dead |access-date = January 31, 2011 }}
* {{Cite journal |url = https://archive.org/download/video-coding-using-the-h.-264-mpeg-4-avc-compression-standard/Video%20coding%20using%20the%20H.264%3AMPEG-4%20AVC%20compression%20standard.pdf |first1 = Atul |last1 = Puri |first2 = Xuemin |last2 = Chen |first3 = Ajay |last3 = Luthra |title = Video coding using the H.264/MPEG-4 AVC compression standard |journal = Signal Processing: Image Communication |date = October 2004 |volume = 19 |issue = 9 |pages = 793–849 |access-date = March 30, 2011 |doi = 10.1016/j.image.2004.06.003 }}
* {{Cite journal |url = http://ip.hhi.de/imagecom_G1/assets/pdfs/pieee_sullivan_wiegand_2005.pdf |first1 = Gary J. |last1 = Sullivan |first2 = Thomas |last2 = Wiegand |s2cid = 1362034 |title = Video Compression—From Concepts to the H.264/AVC Standard |journal = Proceedings of the IEEE |date = January 2005 |volume = 93 |issue = 1 |pages = 18–31 |access-date = January 31, 2011 |doi = 10.1109/jproc.2004.839617 }}
* {{cite web |url=http://www.vcodex.com/h264.html |title=Learn about video compression and H.264 |work=VCODEX |publisher=Vcodex Limited |first1=Iain E. G. |last1=Richardson |access-date=January 31, 2011 |date=January 2011 }}
{{Refend}}

== External links ==
* {{Official website|http://www.itu.int/rec/T-REC-H.264|ITU-T publication page: H.264: Advanced video coding for generic audiovisual services}}
* [https://forum.doom9.org/showthread.php?t=96059 MPEG-4 AVC/H.264 Information] Doom9's Forum
* [https://web.archive.org/web/20040603025720/http://www.vcodex.com/h264.html H.264/MPEG-4 Part 10 Tutorials (Richardson)]
* {{cite web|url=http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=56538|work=ISO publication page: ISO/IEC 14496-10:2010&nbsp;– Information technology&nbsp;— Coding of audio-visual objects | title = Part 10: Advanced Video Coding}}
* {{cite web|url=http://iphome.hhi.de/suehring/tml/|work=IP Homepage | title = H.264/AVC JM Reference Software|access-date=2007-04-15}}
* {{cite web|url=http://ftp3.itu.ch/av-arch/jvt-site|title=JVT document archive site|access-date=2007-05-06|archive-url=https://web.archive.org/web/20100808114705/http://ftp3.itu.ch/av-arch/jvt-site/|archive-date=August 8, 2010|url-status=dead}}
* {{cite web|url=http://iphome.hhi.de/wiegand/pubs.htm|title=Publications | publisher = Thomas Wiegand|access-date=2007-06-23}}
* {{cite web|url=http://iphome.hhi.de/marpe/pub.htm|title=Publications | publisher = Detlev Marpe|access-date=2007-04-15}}
* {{cite web|url=http://www.compression.ru/video/codec_comparison/mpeg-4_avc_h264_2007_en.html| title=Fourth Annual H.264 video codecs comparison | publisher = Moscow State University}} (dated December 2007)
* {{cite web|url=http://www.networkwebcams.com/ip-camera-learning-center/2009/04/03/using-h264-video-compression-in-ip-video-surveillance-systems/| title=Discussion on H.264 with respect to IP cameras in use within the security and surveillance industries| date=April 3, 2009}} (dated April 2009)
* {{cite web|url=http://compression.ru/video/codec_comparison/h264_2010/| title=Sixth Annual H.264 video codecs comparison | publisher = [[Moscow State University]]}} (dated May 2010)
* {{cite web|url=https://support.etcconnect.com/ETC/FAQ/SMPTE_QuickGuide/ | title= SMPTE QuickGuide | date= May 14, 2018 | publisher = ETC}}

{{Compression formats}}
{{MPEG}}
{{High-definition}}
{{ISO standards}}
{{ITU standards}}

{{DEFAULTSORT:H.264 MPEG-4 AVC}}
[[Category:High-definition television]]
[[Category:Open standards covered by patents]]
[[Category:Video codecs]]
[[Category:Video compression]]
[[Category:Videotelephony]]
[[Category:ITU-T recommendations]]
[[Category:ITU-T H Series Recommendations|H.264]]
[[Category:H.26x]]
[[Category:ISO standards]]
[[Category:MPEG-4|MPEG-4 Part 10]]
[[Category:IEC standards]]