Content deleted Content added
Removed a link to a website for an H264 encoder. |
No edit summary Tag: Reverted |
||
Line 26:
'''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 91% of video industry developers {{as of|September 2019|lc=on}}.<ref>{{cite web|url=https://go.bitmovin.com/hubfs/Bitmovin-Video-Developer-Report-2018.pdf|title=Video Developer Report 2018 |website=[[Bitmovin]] |date=September 2019}}</ref><ref>{{cite web |url=https://go.bitmovin.com/video-developer-report-2019 |title=Video Developer Report 2019 |website=[[Bitmovin]] |date=September 2019}}</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
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]] AVC standard (formally, ISO/IEC 14496-10 – 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 AVC developed by the same organizations, while earlier standards are still in common use.
Line 35:
== 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
== History ==
Line 43:
In December 2001, VCEG and the Moving Picture Experts Group ([[MPEG]] – [[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
=== 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
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
=== Multiview video coding ===
Line 71:
* 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 a 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 a 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 a 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/>
Line 87:
* 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,
*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>
Line 121:
=== 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
* Multi-picture [[inter frame|inter-picture prediction]] including the following features:
Line 128:
** 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 the derivation of half-pel luma sample predictions, for sharper subpixel motion
** [[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
* 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
** 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.
Line 139:
* [[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
* 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)
* A quantization design including:
** Logarithmic step size control for easier bit rate management by encoders and simplified inverse-quantization scaling
Line 152:
** 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
** [[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,
* 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.
Line 163:
* 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
* 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
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 the next section.
=== Profiles ===
Line 182:
;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
;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.
Line 189:
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 is 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 is constrained to all-Intra use.
;CAVLC 4{{!:}}4{{!:}}4 Intra Profile (44): The High 4:4:4 Profile is 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
;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.
Line 425:
|}
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).
Line 486:
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.
It is important to note that 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
== 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
On March 18, 2012, [[Mozilla]] announced support for H.264 in Firefox on mobile devices, due to the prevalence of H.264-encoded video and the increased power
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
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/>
Line 549:
=== 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
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>
Line 559:
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 30fps.<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
== Licensing ==
Line 565:
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.mpegla.com/wp-content/uploads/avc-att1.pdf |website=MPEG LA |access-date=6 July 2019}}</ref>
On August 26, 2010, MPEG LA announced that royalties won't 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), a number of the relevant patents that apply to the standard expires every year,<ref>{{Cite web |url=https://www.mpegla.com/wp-content/uploads/avc-att1.pdf |title=AVC Attachment 1 |website=mpegla.com |access-date=August 1, 2022}}</ref> although one of the US patents in the MPEG LA H.264 pool 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
In 2005, Qualcomm sued Broadcom in the 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
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>
| |||