✖


Jump to content

Расширенное кодирование видео

(Перенаправлено с H.264/MPEG-4 AVC )
«AVC1» перенаправляется сюда. Не путать с AV1 или VC-1 .

Расширенное кодирование видео / H.264 / MPEG-4, часть 10
Расширенное кодирование видео для общих аудиовизуальных услуг
Статус Действующий
Год начался 2003
Впервые опубликовано 17 августа 2004 г. ( 17 августа 2004 г. )
Последняя версия 14.0
22 августа 2021 г. ( 22 августа 2021 г. )
Организация МСЭ-Т , ИСО , МЭК
комитет SG16 ( ВКЭГ ), MPEG
Базовые стандарты H.261 , H.262 (он же MPEG-2 Video ), H.263 , ISO/IEC 14496-2 (он же MPEG-4, часть 2)
Related standardsH.265 (aka HEVC), H.266 (aka VVC)
DomainVideo compression
LicenseMPEG LA[1]
Websitewww.itu.int/rec/T-REC-H.264
Block diagram of video coding layer of H.264 encoder with perceptual quality score

Расширенное кодирование видео ( AVC ), также называемое H.264 или MPEG-4 Part 10 , представляет собой стандарт сжатия видео , основанный на блочно-ориентированном кодировании с компенсацией движения . [2] На сегодняшний день это наиболее часто используемый формат для записи, сжатия и распространения видеоконтента, который по состоянию на сентябрь 2019 года используют 91% разработчиков видеоиндустрии. . [3] [4] Он поддерживает максимальное разрешение 8K UHD . [5] [6]

The intent of the H.264/AVC project was to create a standard capable of providing good video quality at substantially lower bit rates than previous standards (i.e., half or less the bit rate of 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),[7] variable block-size segmentation, and multi-picture 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, broadcast, DVD storage, RTP/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 video – 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 области с кодированием без потерь в изображениях с кодированием с потерями или для поддержки редких случаев использования, для которых все кодирование выполняется без потерь.

H.264 was standardized by the ITU-T Video Coding Experts Group (VCEG) of 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.

H.264 is perhaps best known as being the most commonly used video encoding format on Blu-ray Discs. 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 (ATSC, ISDB-T, DVB-T or DVB-T2), cable (DVB-C), and satellite (DVB-S and DVB-S2) systems.

H.264 is restricted by patents owned by various parties. A license covering most (but not all[citation needed]) 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 Licensing Alliance.[8] 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 H.264 encoder openH264.

Naming[edit]

The H.264 name follows the ITU-T 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: Coding of moving video".[9] The MPEG-4 AVC name relates to the naming convention in ISO/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.[10]) Some software programs (such as VLC media player) internally identify this standard as AVC1.

History[edit]

Overall history[edit]

In early 1998, the Video Coding Experts Group (VCEG – 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 (Microsoft, formerly PictureTel, U.S.). The first draft design for that new standard was adopted in August 1999. In 2000, Thomas Wiegand (Heinrich Hertz Institute, Germany) became VCEG co-chair.

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.[11] Formal approval of the specification came in March 2003. The JVT was (is) chaired by Gary Sullivan, Thomas Wiegand, and Ajay Luthra (Motorola, U.S.: later 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 and wide color gamut video, additional VUI identifiers have been added to indicate them.

Fidelity range extensions and professional profiles[edit]

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 Y′CBCR 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?] indicated should have been designed differently.

Scalable video coding[edit]

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 access units 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[edit]

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 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[edit]

Additional extensions were later developed that included 3D video coding with joint coding of depth maps 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[edit]

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.[12]
  • Version 2 (Edition 1.1): (May 7, 2004) Corrigendum containing various minor corrections.[13]
  • 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.[14] 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.[15]
  • 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).[16]
  • 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).[16]
  • 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).[17]
  • 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.[18]
  • Version 9 (Edition 3.1): (January 13, 2009) Corrigendum containing minor corrections.[19]
  • 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.[20]
  • 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.[20]
  • 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.[21]
  • Version 13 (Edition 5): (March 9, 2010) Corrigendum containing minor corrections.[21]
  • 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.[22]
  • Version 15 (Edition 6): (June 29, 2011) Corrigendum containing minor corrections.[22]
  • 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.[23]
  • Version 17 (Edition 8): (April 13, 2013) Amendment with additional SEI message indicators.[24]
  • 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.[24]
  • Version 19 (Edition 8): (April 13, 2013) Corrigendum to correct an error in the sub-bitstream extraction process for multiview video.[24]
  • Version 20 (Edition 8): (April 13, 2013) Amendment to specify additional color space identifiers (including support of ITU-R Recommendation BT.2020 for UHDTV) and an additional model type in the tone mapping information SEI message.[24]
  • Version 21 (Edition 9): (February 13, 2014) Amendment to specify the Enhanced Multiview Depth High profile.[25]
  • 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.[25]
  • 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.[26]
  • 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.[27]
  • 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.[28]
  • 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.[29]
  • 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.[30]

Patent holders[edit]

Further information: MPEG LA
Part of this section is transcluded from MPEG LA. (edit | history)

The following organizations hold one or more patents in MPEG LA's H.264/AVC patent pool.

H.264/AVC patent holders (as of December 2022)[31]
Organization[32]Active patentsExpired patentsTotal patents[31]
Panasonic Corporation1,0544161,470
Godo Kaisha IP Bridge1,0332671,300
LG Electronics8711301001
Dolby Laboratories10144141428
Toshiba59336395
Microsoft95145240
Nippon Telegraph and Telephone (including NTT Docomo)2344238
Sony7777154
Fraunhofer Society20816224
Google5134139
GE Video Compression1360136
Fujitsu9214106
Mitsubishi Electric4456100
Tagivan II LLC82082
Samsung Electronics174663
Maxell54256
Philips64147
Vidyo41243
Ericsson13334
Electronics and Telecommunications Research Institute (ETRI) of Korea102535

Applications[edit]

Further information: 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 Mbit/s and H.264 at only 1.5 Mbit/s.[33] Sony claims that 9 Mbit/s AVC recording mode is equivalent to the image quality of the HDV format, which uses approximately 18–25 Mbit/s.[34]

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 (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.[35][36] 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.[37]

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

Many common DSLRs use H.264 video wrapped in QuickTime MOV containers as the native recording format.

Derived formats[edit]

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 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.[38][39] XAVC can support 4K resolution (4096 × 2160 and 3840 × 2160) at up to 60 frames per second (fps).[38][39] Sony has announced that cameras that support XAVC include two CineAlta cameras—the Sony PMW-F55 and Sony PMW-F5.[40] The Sony PMW-F55 can record XAVC with 4K resolution at 30 fps at 300 Mbit/s and 2K resolution at 30 fps at 100 Mbit/s.[41] XAVC can record 4K resolution at 60 fps with 4:2:2 chroma sampling at 600 Mbit/s.[42][43]

Design[edit]

Features[edit]

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:

  • нескольких изображений, Межкадровое предсказание включая следующие функции:
    • 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-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 "B 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 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 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.
    • Quarter-pixel precision for motion compensation, enabling precise description of the displacements of moving areas. For 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.
    • Взвешенное прогнозирование, позволяющее кодировщику указать использование масштабирования и смещения при выполнении компенсации движения и обеспечивающее значительный выигрыш в производительности в особых случаях, таких как переход к затемнению, плавное появление и перекрестное затухание. Сюда входит неявное взвешенное предсказание для B-кадров и явное взвешенное предсказание для P-кадров.
  • Пространственное предсказание по краям соседних блоков для «внутреннего» кодирования, а не предсказание только «DC», найденное в MPEG-2, часть 2, и предсказание коэффициента преобразования, найденное в H.263v2 и MPEG-4, часть 2. Сюда входит яркость размеры блоков прогнозирования 16×16, 8×8 и 4×4 (из которых в каждом макроблоке можно использовать только один тип ).
  • Целочисленное дискретное косинусное преобразование (целочисленное ДКП), [6] [44] [45] тип дискретного косинусного преобразования (DCT) [44] где преобразование представляет собой целочисленную аппроксимацию стандартного ДКП. [46] Имеет выбираемые размеры блоков. [7] и целочисленные вычисления с точным совпадением для уменьшения сложности, в том числе:
    • Пространственное блочное преобразование 4×4 с точным совпадением, позволяющее точно размещать остаточные сигналы с небольшим количеством « звона », часто встречавшегося в предыдущих конструкциях кодеков. Он похож на стандартный DCT, использовавшийся в предыдущих стандартах, но использует меньший размер блока и простую целочисленную обработку. В отличие от косинусных формул и допусков, выраженных в более ранних стандартах (таких как H.261 и MPEG-2), целочисленная обработка обеспечивает точно заданный декодированный результат.
    • Целочисленное пространственное блочное преобразование 8×8 с точным совпадением, позволяющее более эффективно сжимать сильно коррелированные области, чем при преобразовании 4×4. Эта конструкция основана на стандартном DCT, но упрощена и создана для обеспечения точно заданного декодирования.
    • Адаптивный выбор кодировщика между размерами блоков преобразования 4×4 и 8×8 для операции целочисленного преобразования.
    • Вторичное преобразование Адамара, выполняемое с коэффициентами «DC» первичного пространственного преобразования, применяется к коэффициентам DC цветности (а также к яркости в одном особом случае), чтобы получить еще большее сжатие в гладких областях.
  • без потерь, Функции кодирования макроблоков включая:
    • Режим представления «макроблока PCM» без потерь, в котором образцы видеоданных представляются напрямую. [47] обеспечивая идеальное представление определенных регионов и позволяя налагать строгие ограничения на количество закодированных данных для каждого макроблока.
    • Усовершенствованный режим представления макроблоков без потерь, обеспечивающий идеальное представление определенных областей, при этом обычно используется значительно меньше битов, чем в режиме PCM.
  • Гибкие функции кодирования видео с чересстрочной разверткой, в том числе:
    • Макроблок-адаптивное кодирование поля кадра (MBAFF), использующее структуру пары макроблоков для изображений, закодированных как кадры, что позволяет использовать макроблоки 16×16 в режиме поля (по сравнению с MPEG-2, где обработка в режиме поля в изображении, которое закодировано как кадр) приводит к обработке полумакроблоков 16×8).
    • Адаптивное к изображению кодирование полей кадра (PAFF или PicAFF), позволяющее свободно выбирать смесь изображений, кодированных либо как полные кадры, где оба поля объединены для кодирования, либо как отдельные отдельные поля.
  • Схема квантования, включающая:
    • Логарифмическое управление размером шага для упрощения управления скоростью передачи данных кодировщиками и упрощенного масштабирования обратного квантования.
    • Матрицы масштабирования квантования с настройкой частоты, выбранные кодировщиком для оптимизации квантования на основе восприятия
  • Внутриконтурный фильтр деблокировки , который помогает предотвратить артефакты блокировки, характерные для других методов сжатия изображений на основе DCT, что приводит к улучшению внешнего вида и эффективности сжатия.
  • Схема энтропийного кодирования, включающая:
  • Характеристики устойчивости к потерям, включая:
    • Определение уровня сетевой абстракции (NAL), позволяющее использовать один и тот же синтаксис видео во многих сетевых средах. Одна из фундаментальных концепций проектирования H.264 заключается в создании автономных пакетов для устранения дублирования заголовков, как в коде расширения заголовка (HEC) MPEG-4. [48] Это было достигнуто за счет отделения информации, относящейся к более чем одному фрагменту, от медиапотока. Комбинация параметров более высокого уровня называется набором параметров. [48] Спецификация H.264 включает два типа наборов параметров: набор параметров последовательности (SPS) и набор параметров изображения (PPS). Набор параметров активной последовательности остается неизменным на протяжении всей кодированной видеопоследовательности, а набор параметров активного изображения остается неизменным в пределах кодированного изображения. Структуры набора параметров последовательности и изображения содержат такую ​​информацию, как размер изображения, дополнительные используемые режимы кодирования и карту группы макроблоков для слайсов. [48]
    • Гибкое упорядочение макроблоков (FMO), также известное как группы срезов, и произвольное упорядочение срезов (ASO), которые представляют собой методы реструктуризации порядка представления фундаментальных областей ( макроблоков ) в изображениях. FMO и ASO, которые обычно считаются функцией устойчивости к ошибкам/потерям, также могут использоваться для других целей.
    • Разделение данных (DP) — функция, обеспечивающая возможность разделения более важных и менее важных элементов синтаксиса на разные пакеты данных, что позволяет применять защиту от неравных ошибок (UEP) и другие типы повышения устойчивости к ошибкам/потерям.
    • Избыточные фрагменты (RS), функция устойчивости к ошибкам/потерям, которая позволяет кодировщику отправлять дополнительное представление области изображения (обычно с более низкой точностью), которое можно использовать, если первичное представление повреждено или потеряно.
    • Нумерация кадров - функция, которая позволяет создавать «подпоследовательности», обеспечивая временную масштабируемость за счет дополнительного включения дополнительных изображений между другими изображениями, а также обнаружение и сокрытие потерь целых изображений, которые могут возникнуть из-за потерь сетевых пакетов или каналов. ошибки.
  • Слайсы переключения, называемые слайсами SP и SI, позволяют кодеру направить декодер на переход к текущему видеопотоку для таких целей, как переключение скорости передачи видеопотока и работа в «хитром режиме». Когда декодер переходит в середину видеопотока с помощью функции SP/SI, он может получить точное совпадение с декодированными изображениями в этом месте видеопотока, несмотря на использование других изображений или отсутствие изображений вообще в качестве эталонов до переключатель.
  • Простой автоматический процесс предотвращения случайной эмуляции стартовых кодов , представляющих собой специальные последовательности битов в закодированных данных, обеспечивающие произвольный доступ к битовому потоку и восстановление выравнивания байтов в системах, которые могут потерять синхронизацию байтов.
  • Дополнительная информация улучшения (SEI) и информация об удобстве использования видео (VUI), которые представляют собой дополнительную информацию, которую можно вставлять в битовый поток для различных целей, например, для указания цветового пространства, используемого видеоконтентом, или различных ограничений, применимых к кодированию. Сообщения SEI могут содержать произвольные пользовательские полезные данные метаданных или другие сообщения с синтаксисом и семантикой, определенными в стандарте.
  • Вспомогательные картинки, которые можно использовать для таких целей, как альфа-композитинг .
  • Поддержка монохромной (4:0:0), 4:2:0, 4:2:2 и 4:4:4 выборки цветности (в зависимости от выбранного профиля).
  • Поддержка точности разрядности выборки от 8 до 14 бит на выборку (в зависимости от выбранного профиля).
  • Возможность кодирования отдельных цветовых плоскостей как отдельных изображений с их собственными структурами срезов, режимами макроблоков, векторами движения и т. д., что позволяет разрабатывать кодеры с простой структурой распараллеливания (поддерживается только в трех профилях с поддержкой формата 4:4:4). .
  • Подсчет порядка изображений - функция, которая служит для сохранения порядка изображений и значений выборок в декодированных изображениях, изолированных от информации о синхронизации, позволяя системе передавать и контролировать/изменять информацию о синхронизации отдельно, не затрагивая содержимое декодированного изображения.

Эти методы, наряду с некоторыми другими, помогают H.264 работать значительно лучше, чем любой предыдущий стандарт, в самых разных обстоятельствах и в самых разных прикладных средах. H.264 часто может работать радикально лучше, чем видео MPEG-2, обычно получая то же качество при половине скорости передачи данных или меньше, особенно для видеоконтента с высокой скоростью передачи данных и высоким разрешением. [49]

Как и другие видеостандарты ISO/IEC MPEG, H.264/AVC имеет эталонную программную реализацию, которую можно бесплатно загрузить. [50] Его основная цель — предоставить примеры функций H.264/AVC, а не быть полезным приложением как таковым . Некоторые работы по проектированию эталонного аппаратного обеспечения также проводились в группе экспертов по движущимся изображениям .Вышеупомянутые аспекты включают в себя функции всех профилей H.264. Профиль кодека — это набор характеристик этого кодека, определенных для соответствия определенному набору спецификаций предполагаемых приложений. Это означает, что многие из перечисленных функций не поддерживаются в некоторых профилях. Различные профили H.264/AVC обсуждаются в следующем разделе.

Профили [ править ]

Стандарт определяет несколько наборов возможностей, которые называются профилями и ориентированы на определенные классы приложений. Они объявляются с использованием кода профиля (profile_idc), а иногда и набора дополнительных ограничений, применяемых в кодировщике. Код профиля и указанные ограничения позволяют декодеру распознавать требования для декодирования этого конкретного потока битов. (И во многих системных средах разрешено использовать только один или два профиля, поэтому декодерам в этих средах не нужно беспокоиться о распознавании менее часто используемых профилей.) Безусловно, наиболее часто используемым профилем является высокий профиль.

Профили для немасштабируемых 2D-видеоприложений включают следующее:

Ограниченный базовый профиль (CBP, 66 с набором ограничений 1)
В первую очередь для недорогих приложений этот профиль чаще всего используется в видеоконференциях и мобильных приложениях. Он соответствует подмножеству функций, которые являются общими для базового, основного и высокого профилей.
Базовый профиль (BP, 66)
В первую очередь для недорогих приложений, требующих дополнительной защиты от потери данных, этот профиль используется в некоторых приложениях для видеоконференций и мобильных приложениях. Этот профиль включает в себя все функции, которые поддерживаются в ограниченном базовом профиле, а также три дополнительные функции, которые можно использовать для обеспечения устойчивости к потерям (или для других целей, таких как композиция многоточечного видеопотока с малой задержкой). Важность этого профиля несколько снизилась после определения ограниченного базового профиля в 2009 году. Все битовые потоки ограниченного базового профиля также считаются битовыми потоками базового профиля, поскольку эти два профиля имеют одно и то же значение кода идентификатора профиля.
Расширенный профиль (XP, 88)
Задуманный как профиль потокового видео, этот профиль имеет относительно высокую степень сжатия и некоторые дополнительные возможности, обеспечивающие устойчивость к потерям данных и переключению потоков сервера.
Основной профиль (МП, 77)
Этот профиль используется для цифрового телевещания стандартной четкости, в котором используется формат MPEG-4, определенный в стандарте DVB. [51] Однако он не используется для телевещания высокой четкости, поскольку важность этого профиля исчезла, когда в 2004 году для этого приложения был разработан High Profile.
Высокий профиль (HiP, 100)
Основной профиль для приложений вещания и хранения дисков, особенно для приложений телевидения высокой четкости (например, это профиль, принятый в формате хранения дисков Blu-ray и службе вещания DVB HDTV).
Прогрессивный высокий профиль (PHiP, 100 с набором ограничений 4)
Аналогичен профилю High, но без поддержки функций кодирования полей.
Ограниченный высокий профиль (100 с набором ограничений 4 и 5)
Аналогичен профилю Progressive High, но без поддержки срезов B (би-предсказания).
Профиль Высокий 10 (Hi10P, 110)
Выходя за рамки типичных возможностей потребительских продуктов, этот профиль построен на основе High Profile, добавляя поддержку до 10 бит на выборку точности декодированного изображения.
Высокий профиль 4:2:2 (Hi422P, 122)
В первую очередь ориентированный на профессиональные приложения, использующие чересстрочное видео, этот профиль создан на основе профиля High 10, добавляя поддержку формата выборки цветности 4:2:2 с использованием до 10 бит на выборку точности декодированного изображения.
Прогнозирующий профиль High 4:4:4 (Hi444PP, 244)
Этот профиль создан на основе профиля High 4:2:2 и поддерживает выборку цветности до 4:4:4, до 14 бит на выборку, а также поддерживает эффективное кодирование областей без потерь и кодирование каждого изображения как три отдельных цвета. самолеты.

Для видеокамер, монтажных и профессиональных приложений стандарт содержит четыре дополнительных профиля, предназначенных только для внутрикадра , которые определяются как простые подмножества других соответствующих профилей. В основном они предназначены для профессиональных приложений (например, для камер и систем редактирования):

Высокий 10 Внутрипрофиль (110 с набором ограничений 3)
Профиль High 10 предназначен только для внутреннего использования.
Высокий внутренний профиль 4:2:2 (122 с набором ограничений 3)
Профиль High 4:2:2 предназначен только для внутреннего использования.
Высокий внутренний профиль 4:4:4 (244 с набором ограничений 3)
Профиль High 4:4:4 предназначен только для внутреннего использования.
CAVLC 4:4:4 Внутренний профиль (44)
Профиль High 4:4:4 ограничен использованием all-Intra и энтропийным кодированием CAVLC (т. е. не поддерживает CABAC).

В результате расширения Scalable Video Coding (SVC) стандарт содержит пять дополнительных масштабируемых профилей , которые определяются как комбинация профиля H.264/AVC для базового уровня (определяемого вторым словом в имени масштабируемого профиля). ) и инструменты, обеспечивающие масштабируемое расширение:

Масштабируемый базовый профиль (83)
Этот профиль, предназначенный в первую очередь для приложений видеоконференций, мобильных устройств и наблюдения, создан на основе профиля Constrained Baseline, которому должен соответствовать базовый уровень (подмножество битового потока). Для инструментов масштабирования включено подмножество доступных инструментов.
Масштабируемый ограниченный базовый профиль (83 с набором ограничений 5)
Подмножество масштабируемого базового профиля, предназначенное в первую очередь для приложений связи в реальном времени.
Масштабируемый высокий профиль (86)
Этот профиль, ориентированный в первую очередь на приложения вещания и потоковой передачи, построен на основе высокого профиля H.264/AVC, которому должен соответствовать базовый уровень.
Масштабируемый высокий профиль с ограничениями (86 с набором ограничений 5)
Подмножество масштабируемого высокого профиля, предназначенное в первую очередь для приложений связи в реальном времени.
Масштабируемый высокий внутренний профиль (86 с набором ограничений 3)
Этот профиль, ориентированный в первую очередь на производственные приложения, представляет собой масштабируемый высокий профиль, предназначенный только для внутреннего использования.

В результате расширения Multiview Video Coding (MVC) стандарт содержит два многовидовых профиля :

Стерео высокий профиль (128)
3D-видео с двумя представлениями Этот профиль предназначен для стереоскопического и сочетает в себе инструменты профиля High с возможностями межпросмотрового прогнозирования расширения MVC.
Многовидовой высокий профиль (118)
Этот профиль поддерживает два или более представлений с использованием как межкадрового (временного) предсказания, так и межвидового предсказания MVC, но не поддерживает изображения полей и адаптивное к макроблокам кодирование полей кадров.

Расширение Multi-Resolve Frame-Compatible (MFC) добавило еще два профиля:

Высокий профиль МФЦ (134)
Профиль для стереоскопического кодирования с двухуровневым повышением разрешения.
Глубина MFC, высокий профиль (135)

Расширение 3D-AVC добавило еще два профиля:

Многовидовая глубина, высокий профиль (138)
Этот профиль поддерживает совместное кодирование карты глубины и информации о видеотекстуре для улучшения сжатия 3D-видеоконтента.
Улучшенный многовидовый, глубина, высокий профиль (139)
Расширенный профиль для комбинированного многовидового кодирования с информацией о глубине.

Поддержка функций в определенных профилях [ править ]

Особенность таможенно-пограничная служба БП XP член парламента ПроХиП Бедро Привет10P Привет422P Привет444PP
I and P slicesYesYesYesYesYesYesYesYesYes
Разрядность (на выборку) 8 8 8 8 8 8 с 8 до 10 с 8 до 10 с 8 до 14
Цветовые форматы 4:2:0

 		4:2:0

 		4:2:0

 		4:2:0

 		4:2:0

 		4:2:0

 		4:2:0

 		4:2:0/
4:2:2
 		4:2:0/
4:2:2/
4:4:4
Гибкий порядок макроблоков (FMO) Нет Да Да Нет Нет Нет Нет Нет Нет
Произвольный порядок срезов (ASO) Нет Да Да Нет Нет Нет Нет Нет Нет
Резервные срезы (RS) Нет Да Да Нет Нет Нет Нет Нет Нет
Разделение данных Нет Нет Да Нет Нет Нет Нет Нет Нет
Срезы SI и SP Нет Нет Да Нет Нет Нет Нет Нет Нет
Чересстрочное кодирование (PicAFF, MBAFF) Нет Нет Да Да Нет Да Да Да Да
Б-ломтики Нет Нет Да Да Да Да Да Да Да
Multiple reference framesYesYesYesYesYesYesYesYesYes
In-loop deblocking filterYesYesYesYesYesYesYesYesYes
CAVLC entropy codingYesYesYesYesYesYesYesYesYes
Энтропийное кодирование CABAC Нет Нет Нет Да Да Да Да Да Да
4:0:0 ( Монохромный ) Нет Нет Нет Нет Да Да Да Да Да
Адаптивность преобразования 8×8 против 4×4 Нет Нет Нет Нет Да Да Да Да Да
Матрицы масштабирования квантования Нет Нет Нет Нет Да Да Да Да Да
Раздельное управление C B и C R QP Нет Нет Нет Нет Да Да Да Да Да
Отдельное кодирование цветовой плоскости Нет Нет Нет Нет Нет Нет Нет Нет Да
Прогнозирующее кодирование без потерь Нет Нет Нет Нет Нет Нет Нет Нет Да

Уровни [ править ]

Поскольку этот термин используется в стандарте, « уровень » представляет собой определенный набор ограничений, которые указывают степень требуемой производительности декодера для профиля. Например, уровень поддержки в профиле определяет максимальное разрешение изображения, частоту кадров и скорость передачи данных, которые может использовать декодер. Декодер, соответствующий данному уровню, должен иметь возможность декодировать все потоки битов, закодированные для этого уровня и всех нижних уровней.

Уровни с максимальными значениями свойств [28]
Уровень
Максимум
скорость декодирования
(макроблоков/с) 		Максимум
размер кадра
(макроблоки) 		Максимум видео
битрейт для видео
уровень кодирования (VCL)
(Ограниченная базовая линия,
Базовый, расширенный
и основные профили)
(кбит/с) 		Примеры для высокого разрешения
@ самая высокая частота кадров
(максимальное количество сохраненных кадров)
Переключить дополнительные сведения

1 1,485 99 64 176× [электронная почта защищена] (4)
1б 1,485 99 128 176× [электронная почта защищена] (4)
1.1 3,000 396 192 352× [электронная почта защищена] (2)
1.2 6,000 396 384 352× [адрес электронной почты защищен] (6)
1.3 11,880 396 768 352× [адрес электронной почты защищен] (6)
2 11,880 396 2,000 352× [адрес электронной почты защищен] (6)
2.1 19,800 792 4,000 352× [адрес электронной почты защищен] (6)
2.2 20,250 1,620 4,000 720× [электронная почта защищена] (5)
3 40,500 1,620 10,000 720× [электронная почта защищена] (5)
3.1 108,000 3,600 14,000 1280× [электронная почта защищена] (5)
3.2 216,000 5,120 20,000 1280×1, [электронная почта защищена] (4)
4 245,760 8,192 20,000 2048×1, [электронная почта защищена] (4)
4.1 245,760 8,192 50,000 2048×1, [электронная почта защищена] (4)
4.2 522,240 8,704 50,000 2048×1, [электронная почта защищена] (4)
5 589,824 22,080 135,000 3,672×1, [электронная почта защищена] (5)
5.1 983,040 36,864 240,000 4096×2, [электронная почта защищена] (5)
5.2 2,073,600 36,864 240,000 4096×2, [электронная почта защищена] (5)
6 4,177,920 139,264 240,000 8,192×4, [адрес электронной почты защищен] (5)
6.1 8,355,840 139,264 480,000 8,192×4, [адрес электронной почты защищен] (5)
6.2 16,711,680 139,264 800,000 8,192×4, [адрес электронной почты защищен] (5)

Максимальная скорость передачи данных для высокого профиля в 1,25 раза выше, чем для ограниченного базового, базового, расширенного и основного профилей; 3 раза для Hi10P и 4 раза для Hi422P/Hi444PP.

Количество выборок яркости в 16×16=256 раз превышает количество макроблоков (а количество выборок яркости в секунду в 256 раз превышает количество макроблоков в секунду).

Буферизация декодированного изображения [ править ]

Ранее закодированные изображения используются кодировщиками H.264/AVC для прогнозирования значений выборок в других изображениях. Это позволяет кодировщику принимать эффективные решения о наилучшем способе кодирования данного изображения. В декодере такие изображения сохраняются в виртуальном буфере декодированных изображений (DPB). Максимальная емкость DPB в единицах кадров (или парах полей), как показано в скобках в правом столбце таблицы выше, может быть рассчитана следующим образом:

DpbCapacity = min(floor( MaxDpbMbs / ( PicWidthInMbs * FrameHeightInMbs )), 16)

Где MaxDpbMbs — это постоянное значение, представленное в таблице ниже как функция номера уровня, и ПикВидсИнМбс и FrameHeightInMbs — это ширина изображения и высота кадра для кодированных видеоданных, выраженные в единицах макроблоков (округленные до целых значений и учитывающие обрезку и спаривание макроблоков, когда это применимо). Эта формула указана в разделах A.3.1.h и A.3.2.f редакции стандарта 2017 года. [28]

Уровень 1 1б 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
МаксДпбМбс 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

Например, для изображения HDTV шириной 1920 отсчетов ( ПикВидсИнМбс = 120 ) и высотой 1080 семплов ( ФреймХайтИнМбс = 68 ), декодер уровня 4 имеет максимальную емкость памяти DPB пол(32768/(120*68)) = 4 кадра (или 8 полей). Так, в таблице выше в правом столбце строки для Уровня 4 с размером кадра 1920×1080 в скобках показано значение 4.

Важно отметить, что текущее декодируемое изображение не включается в вычисление наполненности DPB (если только кодер не указал его для сохранения для использования в качестве эталона для декодирования других изображений или для задержки вывода по времени). Таким образом, декодеру необходимо фактически иметь достаточно памяти для обработки (по крайней мере) на один кадр больше максимальной емкости DPB, рассчитанной выше.

Реализации [ править ]

Статистика видео YouTube с видеокодеком AVC (H.264) и Opus . аудиоформатом

В 2009 году рабочая группа HTML5 разделилась на сторонников Ogg Theora , бесплатного видеоформата, который, как считается, не обременен патентами, и H.264, содержащего запатентованную технологию. Еще в июле 2009 года сообщалось, что Google и Apple поддерживают H.264, а Mozilla и Opera поддерживают Ogg Theora (теперь Google, Mozilla и Opera поддерживают Theora и WebM с VP8 ). [52] Microsoft с выпуском Internet Explorer 9 добавила поддержку видео HTML 5, закодированного с использованием H.264. На симпозиуме Gartner/ITXpo в ноябре 2010 года генеральный директор Microsoft Стив Балмер ответил на вопрос «HTML 5 или Silverlight ?» сказав: «Если вы хотите сделать что-то универсальное, нет никаких сомнений в том, что мир переходит на HTML5». [53] В январе 2011 года Google объявила, что прекращает поддержку H.264 в своем браузере Chrome и поддерживает Theora и WebM / VP8 для использования только открытых форматов. [54]

18 марта 2012 года Mozilla объявила о поддержке H.264 в Firefox на мобильных устройствах из-за преобладания видео в кодировке H.264 и повышенной энергоэффективности за счет использования специального аппаратного декодера H.264, обычного для таких устройств. [55] 20 февраля 2013 г. Mozilla реализовала в Firefox поддержку декодирования H.264 в Windows 7 и более поздних версиях. Эта функция опирается на встроенные библиотеки декодирования Windows. [56] Firefox 35.0, выпущенный 13 января 2015 г., поддерживает H.264 в OS X 10.6 и выше. [57]

30 октября 2013 года Роуэн Троллоп из Cisco Systems объявил, что Cisco выпустит как двоичные файлы, так и исходный код видеокодека H.264 под названием OpenH264 под лицензией Simplified BSD , а также выплатит все гонорары за его использование MPEG LA для любых программных проектов. которые используют предварительно скомпилированные двоичные файлы Cisco, что делает двоичные файлы Cisco OpenH264 бесплатными для использования. Однако любые программные проекты, использующие исходный код Cisco вместо ее двоичных файлов, будут нести юридическую ответственность за выплату всех гонораров MPEG LA. Целевые архитектуры ЦП включают x86 и ARM, а целевые операционные системы включают Linux, Windows XP и более поздние версии, Mac OS X и Android; iOS в этом списке отсутствовала, поскольку она не позволяет приложениям получать и устанавливать бинарные модули из Интернета. [58] [59] [60] Также 30 октября 2013 г. Брендан Эйх из Mozilla написал, что он будет использовать двоичные файлы Cisco в будущих версиях Firefox, чтобы добавить поддержку H.264 в Firefox, где кодеки платформы недоступны. [61] Cisco опубликовала исходный код OpenH264 9 декабря 2013 г. [62]

Хотя iOS не поддерживалась выпуском программного обеспечения Cisco 2013 года, Apple обновила свою платформу Video Toolbox Framework до iOS 8 (выпущенной в сентябре 2014 года), чтобы обеспечить прямой доступ к аппаратному кодированию и декодированию видео H.264/AVC. [59]

Программные кодеры [ править ]

Реализации программного обеспечения AVC
Особенность QuickTime Черный OpenH264 х264 Основной-
Концепция 		Элекард ТСЕ Про-
Кодер 		Авива Элементаль ИПП
Б-ломтики Да Да Да Да Да Да Да Да Нет Да Да
Несколько опорных систем Да Да Да Да Да Да Да Да Нет Да Да
Чересстрочное кодирование (PicAFF, MBAFF) Нет МБАФФ МБАФФ МБАФФ Да Да Нет Да МБАФФ Да Нет
Энтропийное кодирование CABAC Да Да Да Да Да Да Да Да Нет Да Да
Адаптивность преобразования 8×8 против 4×4 Нет Да Да Да Да Да Да Да Нет Да Да
Матрицы масштабирования квантования Нет Нет Да Да Да Нет Нет Нет Нет Нет Нет
Раздельное управление C B и C R QP Нет Нет Да Да Да Да Нет Нет Нет Нет Нет
Расширенные форматы цветности Нет Нет Нет 4:0:0 [63]
4:2:0
4:2:2 [64]
4:4:4 [65]   		4:2:2 4:2:2 4:2:2 Нет Нет 4:2:0
4:2:2 		Нет
Наибольшая глубина выборки (бит) 8 8 8 10 [66] 10 8 8 8 8 10 12
Прогнозирующее кодирование без потерь Нет Нет Нет Да [67] Нет Нет Нет Нет Нет Нет Нет

Аппаратное обеспечение [ править ]

См. также: Продукты и реализации H.264/MPEG-4 AVC.

Поскольку кодирование и декодирование H.264 требует значительной вычислительной мощности для определенных типов арифметических операций, программные реализации, работающие на процессорах общего назначения, обычно менее энергоэффективны. Однако последние [ когда? ] Четырехъядерные процессоры общего назначения x86 обладают достаточной вычислительной мощностью для выполнения кодирования SD и HD в реальном времени. Эффективность сжатия зависит от реализации алгоритмов видео, а не от того, используется ли аппаратная или программная реализация. Таким образом, разница между аппаратной и программной реализацией больше заключается в энергоэффективности, гибкости и стоимости. Чтобы повысить энергоэффективность и уменьшить форм-фактор аппаратного обеспечения, можно использовать специальное оборудование либо для полного процесса кодирования или декодирования, либо для помощи в ускорении в среде, управляемой ЦП.

Решения на базе ЦП, как известно, гораздо более гибкие, особенно когда кодирование должно выполняться одновременно в нескольких форматах, с разными скоростями передачи данных и разрешениями ( многоэкранное видео ) и, возможно, с дополнительными функциями по поддержке форматов контейнеров, расширенными интегрированными рекламными функциями и т. д. Программное решение на базе ЦП обычно значительно упрощает балансировку нагрузки нескольких одновременных сеансов кодирования в пределах одного ЦП.

второго поколения Процессоры Intel Sandy Bridge Core i3/i5/i7 , представленные на выставке CES ( Consumer Electronics Show ) в январе 2011 года, оснащены встроенным аппаратным кодировщиком Full HD H.264, известным как Intel Quick Sync Video . [68] [69]

Аппаратный кодер H.264 может представлять собой ASIC или FPGA .

Кодеры ASIC с функциональностью кодировщика H.264 доступны от многих различных полупроводниковых компаний, но основная конструкция, используемая в ASIC, обычно лицензируется у одной из немногих компаний, таких как Chips&Media , Allegro DVT, On2 (ранее Hantro, приобретенная Google), Imagination Technologies , NGCodec. Некоторые компании предлагают продукты как FPGA, так и ASIC. [70]

Texas Instruments производит линейку ядер ARM + DSP, которые выполняют кодирование DSP H.264 BP 1080p со скоростью 30 кадров в секунду. [71] Это обеспечивает гибкость в отношении кодеков (которые реализованы в виде высокооптимизированного кода DSP), будучи более эффективными, чем программное обеспечение на обычном ЦП.

Лицензирование [ править ]

См. также: Microsoft Corp. против Motorola Inc. и Qualcomm Inc. против Broadcom Corp.

В странах, где патенты на программные алгоритмы сохраняются, ожидается, что поставщики и коммерческие пользователи продуктов, использующих H.264/AVC, будут платить лицензионные отчисления за патенты на запатентованную технологию, которую используют их продукты. [72] Это относится и к базовому профилю. [73]

Частная организация, известная как MPEG LA , которая никоим образом не связана с организацией по стандартизации MPEG, управляет лицензиями на патенты, применимые к этому стандарту, а также другие патентные пулы , такие как MPEG-4 Part 2 Video, HEVC и MPEG-ДАШ. В число патентообладателей входят Fujitsu , Panasonic , Sony , Mitsubishi , Apple , Колумбийский университет , KAIST , Dolby , Google , JVC Kenwood , LG Electronics , Microsoft , NTT Docomo , Philips , Samsung , Sharp , Toshiba и ZTE . [74] хотя большинство патентов в пуле принадлежат Panasonic (1197 патентов), Godo Kaisha IP Bridge (1130 патентов) и LG Electronics (990 патентов). [75]

26 августа 2010 года MPEG LA объявил, что гонорары не будут взиматься за интернет-видео в формате H.264, которое бесплатно для конечных пользователей. [76] Все остальные роялти остаются в силе, например, роялти за продукты, декодирующие и кодирующие видео H.264, а также операторам бесплатного телевидения и каналов по подписке. [77] Условия лицензии обновляются блоками по 5 лет. [78]

Поскольку первая версия стандарта была завершена в мае 2003 г. ( 21 год назад), а наиболее часто используемый профиль (Высокий профиль) был завершен в июне 2004 г. [ нужна ссылка ] ( 19–20 лет назад), срок действия всех оригинальных патентов к настоящему времени истек, [75] хотя один из патентов США в пуле MPEG LA H.264 (выданный в 2016 году) действует как минимум до ноября 2030 года. [79]

В 2005 году Qualcomm подала иск против Broadcom в окружной суд США, утверждая, что Broadcom нарушила два ее патента, создав продукты, соответствующие стандарту сжатия видео H.264. [80] В 2007 году окружной суд установил, что патенты не имеют юридической силы, поскольку Qualcomm не раскрыла их JVT до выпуска стандарта H.264 в мае 2003 года. [80] В декабре 2008 года Апелляционный суд Федерального округа США подтвердил постановление Окружного суда о признании патентов лишенными исковой силы, но был возвращен в Окружной суд с инструкциями ограничить сферу неисполнимости продуктами, совместимыми с H.264. [80]

В октябре 2023 года Nokia подала в суд на HP и Amazon за нарушение патентных прав H.264/H.265 в США, Великобритании и других странах. [81]

См. также [ править ]

Ссылки [ править ]

  1. ^ MPEG-4, Расширенное кодирование видео (Часть 10) (H.264) (Полный проект). Устойчивость цифровых форматов. Вашингтон, округ Колумбия: Библиотека Конгресса. 5 декабря 2011 года . Проверено 1 декабря 2021 г.
  2. ^ «H.264: Расширенное кодирование видео для общих аудиовизуальных услуг» . www.itu.int . Архивировано из оригинала 31 октября 2019 года . Проверено 22 ноября 2019 г.
  3. ^ «Отчет разработчиков видео за 2018 год» (PDF) . Битмовин . Сентябрь 2019.
  4. ^ «Отчет разработчиков видео 2019» . Битмовин . Сентябрь 2019.
  5. ^ «Передача 8K с использованием AVC/H.264» . Таинственный ящик . Архивировано из оригинала 25 марта 2021 года . Проверено 23 августа 2017 г.
  6. ↑ Перейти обратно: Перейти обратно: а б Ван, Ханли; Квонг, С.; Кок, К. (2006). «Эффективный алгоритм прогнозирования целочисленных коэффициентов DCT для оптимизации H.264/AVC». Транзакции IEEE по схемам и системам видеотехнологий . 16 (4): 547–552. дои : 10.1109/TCSVT.2006.871390 . S2CID   2060937 .
  7. ↑ Перейти обратно: Перейти обратно: а б Томсон, Гэвин; Шах, Атар (2017). «Представляем HEIF и HEVC» (PDF) . Apple Inc. Проверено 5 августа 2019 г ..
  8. ^ Озер, январь (8 мая 2023 г.), через переговоры Хита Хоглунда из Лос-Анджелеса о MPEG LA/через слияние лицензионного патентного пула , StreamingMedia.com
  9. ^ «Рекомендации МСЭ-Т» . МСЭ . Проверено 1 ноября 2022 г.
  10. ^ «H.262: Информационные технологии. Общее кодирование движущихся изображений и связанной с ними аудиоинформации: Видео» . Проверено 15 апреля 2007 г.
  11. ^ Объединенная видеогруппа , веб-сайт ITU-T .
  12. ^ «Рекомендация МСЭ-Т H.264 (05/2003)» . МСЭ. 30 мая 2003 года . Проверено 18 апреля 2013 г.
  13. ^ «Рекомендация МСЭ-Т H.264 (05/2003) Кор. 1 (05/2004)» . МСЭ. 7 мая 2004 года . Проверено 18 апреля 2013 г.
  14. ^ «Рекомендация МСЭ-Т H.264 (03/2005)» . МСЭ. 1 марта 2005 года . Проверено 18 апреля 2013 г.
  15. ^ «Рекомендация МСЭ-Т H.264 (2005 г.), Кор. 1 (09/2005 г.)» . МСЭ. 13 сентября 2005 года . Проверено 18 апреля 2013 г.
  16. ↑ Перейти обратно: Перейти обратно: а б «Рекомендация МСЭ-Т H.264 (2005 г.), поправка 1 (06/2006 г.)» . МСЭ. 13 июня 2006 года . Проверено 18 апреля 2013 г.
  17. ^ «Рекомендация МСЭ-Т H.264 (2005 г.), поправка 2 (04/2007 г.)» . МСЭ. 6 апреля 2007 года . Проверено 18 апреля 2013 г.
  18. ^ «Рекомендация МСЭ-Т H.264 (11/2007)» . МСЭ. 22 ноября 2007 года . Проверено 18 апреля 2013 г.
  19. ^ «Рекомендация МСЭ-Т H.264 (2007 г.), Кор. 1 (01/2009 г.)» . МСЭ. 13 января 2009 года . Проверено 18 апреля 2013 г.
  20. ↑ Перейти обратно: Перейти обратно: а б «Рекомендация МСЭ-Т H.264 (03/2009)» . МСЭ. 16 марта 2009 года . Проверено 18 апреля 2013 г.
  21. ↑ Перейти обратно: Перейти обратно: а б «Рекомендация МСЭ-Т H.264 (03/2010)» . МСЭ. 9 марта 2010 года . Проверено 18 апреля 2013 г.
  22. ↑ Перейти обратно: Перейти обратно: а б «Рекомендация МСЭ-Т H.264 (06/2011)» . МСЭ. 29 июня 2011 года . Проверено 18 апреля 2013 г.
  23. ^ «Рекомендация МСЭ-Т H.264 (01/2012)» . МСЭ. 13 января 2012 года . Проверено 18 апреля 2013 г.
  24. ↑ Перейти обратно: Перейти обратно: а б с д «Рекомендация МСЭ-Т H.264 (04/2013)» . МСЭ. 12 июня 2013 года . Проверено 16 июня 2013 г.
  25. ↑ Перейти обратно: Перейти обратно: а б «Рекомендация МСЭ-Т H.264 (02/2014)» . МСЭ. 28 ноября 2014 года . Проверено 28 февраля 2016 г.
  26. ^ «Рекомендация МСЭ-Т H.264 (02/2016)» . МСЭ. 13 февраля 2016 года . Проверено 14 июня 2017 г.
  27. ^ «Рекомендация МСЭ-Т H.264 (10/2016)» . МСЭ. 14 октября 2016 года . Проверено 14 июня 2017 г.
  28. ↑ Перейти обратно: Перейти обратно: а б с «Рекомендация МСЭ-Т H.264 (04/2017)» . МСЭ. 13 апреля 2017 г. Таблицы возможностей, зависящих от уровня, см. в таблицах A-1, A-6 и A-7 . Проверено 14 июня 2017 г.
  29. ^ «H.264: Расширенное кодирование видео для общих аудиовизуальных услуг - Версия 26 (Редакция 13)» . www.itu.int . 13 июня 2019 года. Архивировано из оригинала 4 ноября 2021 года . Проверено 3 ноября 2021 г.
  30. ^ «H.264: Расширенное кодирование видео для общих аудиовизуальных услуг - Версия 27 (Редакция 14)» . www.itu.int . 22 августа 2021 года. Архивировано из оригинала 4 ноября 2021 года . Проверено 3 ноября 2021 г.
  31. ↑ Перейти обратно: Перейти обратно: а б «AVC/H.264 – Список патентов» (PDF) . MPEG Лос-Анджелес . Проверено 22 декабря 2022 г.
  32. ^ «Лицензиары AVC/H.264» . MPEG-LA. Архивировано из оригинала 30 мая 2015 года . Проверено 19 мая 2013 г.
  33. ^ Венгер; и др. (февраль 2005 г.). «RFC 3984: Формат полезной нагрузки RTP для видео H.264» . Ietf Datatracker : 2. doi : 10.17487/RFC3984 .
  34. ^ «Какой режим записи эквивалентен качеству изображения формата видео высокой четкости (HDV)?» . Электронная поддержка Sony . Архивировано из оригинала 9 ноября 2017 года . Проверено 8 декабря 2018 г.
  35. ^ «Стандарт ATSC A/72, часть 1: Характеристики видеосистемы AVC в системе цифрового телевидения ATSC» (PDF) . Архивировано из оригинала (PDF) 7 августа 2011 года . Проверено 30 июля 2011 г.
  36. ^ «Стандарт ATSC A/72, часть 2: Характеристики подсистемы передачи видео AVC» (PDF) . Архивировано из оригинала (PDF) 7 августа 2011 года . Проверено 30 июля 2011 г.
  37. ^ «Стандарт ATSC A/153, часть 7: Характеристики видеосистем AVC и SVC» (PDF) . Архивировано из оригинала (PDF) 26 июля 2011 года . Проверено 30 июля 2011 г.
  38. ↑ Перейти обратно: Перейти обратно: а б «Sony представляет новый формат записи XAVC для ускорения развития 4K на профессиональном и потребительском рынках» . Сони. 30 октября 2012 года . Проверено 1 ноября 2012 г.
  39. ↑ Перейти обратно: Перейти обратно: а б «Sony представляет новый формат записи XAVC для ускорения развития 4K на профессиональном и потребительском рынках» (PDF) . Сони. 30 октября 2012 года . Проверено 1 ноября 2012 г. [ постоянная мертвая ссылка ]
  40. ^ Стив Дент (30 октября 2012 г.). «Sony выходит на «красную охоту» с камкордерами PMW-F55 и PMW-F5 pro CineAlta с сенсором Super 35 мм 4K» . Engadget . Проверено 5 ноября 2012 г.
  41. ^ «F55 CineAlta 4K — будущее, опережающее график» (PDF) . Сони. 30 октября 2012 г. Архивировано из оригинала (PDF) 19 ноября 2012 г. . Проверено 1 ноября 2012 г.
  42. ^ «Сверхбыстрые карты памяти SxS PRO+ преобразуют захват видео 4K» . Сони. Архивировано из оригинала 8 марта 2013 года . Проверено 5 ноября 2012 г.
  43. ^ «Сверхбыстрые карты памяти SxS PRO+ преобразуют захват видео 4K» (PDF) . Сони. Архивировано из оригинала (PDF) 2 апреля 2015 г. Проверено 5 ноября 2012 г.
  44. ↑ Перейти обратно: Перейти обратно: а б Станкович, Радомир С.; Астола, Яакко Т. (2012). «Воспоминания о ранней работе в DCT: интервью с К.Р. Рао» (PDF) . Отпечатки первых дней информационных наук . 60:17 ​ . Проверено 13 октября 2019 г.
  45. ^ Квон, Сун-Ён; Ли, Джу Кён; Чунг, Ки-дон (2005). «Полупиксельная коррекция для транскодирования MPEG-2/H.264». Анализ и обработка изображений – ICIAP 2005 . Конспекты лекций по информатике. Том. 3617. Шпрингер Берлин Гейдельберг. стр. 576–583. дои : 10.1007/11553595_71 . ISBN  978-3-540-28869-5 .
  46. ^ Британак, Владимир; Да, Патрик С.; Рао, КР (2010). Дискретные косинусные и синусоидальные преобразования: общие свойства, быстрые алгоритмы и целочисленные аппроксимации . Эльзевир . стр. ix, xiii, 1, 141–304. ISBN  9780080464640 .
  47. ^ «Стандарт расширенного кодирования видео H.264/AVC: обзор и введение в расширения диапазона точности» (PDF) . Проверено 30 июля 2011 г.
  48. ↑ Перейти обратно: Перейти обратно: а б с RFC 3984, стр. 3
  49. ^ Apple Inc. (26 марта 1999 г.). «Часто задаваемые вопросы по H.264» . Яблоко. Архивировано из оригинала 7 марта 2010 года . Проверено 17 мая 2010 г.
  50. ^ Карстен Зюринг. «Загрузка эталонного программного обеспечения H.264/AVC JM» . Iphome.hhi.de . Проверено 17 мая 2010 г.
  51. ^ «TS 101 154 – V1.9.1 – Цифровое видеовещание (DVB); Спецификация использования кодирования видео и аудио в приложениях вещания на основе транспортного потока MPEG-2» (PDF) . Проверено 17 мая 2010 г.
  52. ^ «Расшифровка дебатов о видеокодеке HTML 5» . Арс Техника . 6 июля 2009 года . Проверено 12 января 2011 г.
  53. ^ «Стив Балмер, генеральный директор Microsoft, дал интервью на симпозиуме Gartner/ITxpo в Орландо 2010» . Гартнервидео. Ноябрь 2010 г. Архивировано из оригинала 30 октября 2021 г. Проверено 12 января 2011 г.
  54. ^ «Поддержка видеокодеков HTML в Chrome» . 11 января 2011 года . Проверено 12 января 2011 г.
  55. ^ «Видео, мобильные устройства и открытая сеть» . 18 марта 2012 года . Проверено 20 марта 2012 г.
  56. ^ «WebRTC включен, поддержка H.264/MP3 в Win 7 включена по умолчанию, пользовательский интерфейс Metro для Windows 8 и многое другое – основные моменты разработки Firefox» . hacks.mozilla.org . Мозилла. 20 февраля 2013 года . Проверено 15 марта 2013 г.
  57. ^ «Firefox — Заметки (35.0)» . Мозилла .
  58. ^ «H.264 с открытым исходным кодом устраняет барьеры для WebRTC» . 30 октября 2013. Архивировано из оригинала 6 июля 2015 года . Проверено 1 ноября 2013 г.
  59. ↑ Перейти обратно: Перейти обратно: а б «Часто задаваемые вопросы по проекту Cisco OpenH264» . Проверено 26 сентября 2021 г.
  60. ^ «Упрощенная лицензия BSD OpenH264» . Гитхаб . 27 октября 2013 года . Проверено 21 ноября 2013 г.
  61. ^ «Взаимодействие видео в Интернете улучшается благодаря кодеку Cisco H.264» . 30 октября 2013 года . Проверено 1 ноября 2013 г.
  62. ^ «Обновленный README · cisco/openh264@59dae50» . Гитхаб .
  63. ^ «Поддержка кодирования x264 4:0:0 (монохромное)» , дата обращения 05.06.2019.
  64. ^ «Поддержка кодирования x264 4:2:2» , дата обращения 05 июня 2019 г.
  65. ^ «Поддержка кодирования x264 4:4:4» , дата обращения 05 июня 2019 г.
  66. ^ «Поддержка x264 для 9- и 10-битного кодирования» , дата обращения 22 июня 2011 г.
  67. ^ «x264 заменяет профиль High 4:4:4 без потерь на High 4:4:4 Predictive» , дата обращения 22 июня 2011 г.
  68. ^ «Краткое справочное руководство по созданию встроенных визуальных элементов процессора Intel Core» . Сеть программного обеспечения Intel. 1 октября 2010 года . Проверено 19 января 2011 г.
  69. ^ «Intel Quick Sync Video» . www.intel.com. 1 октября 2010 года . Проверено 19 января 2011 г.
  70. ^ «Design-reuse.com» . Design-reuse.com. 1 января 1990 года . Проверено 17 мая 2010 г.
  71. ^ «Категория: DM6467 — Wiki по встраиваемым процессорам Texas Instruments» . Processors.wiki.ti.com. 12 июля 2011. Архивировано из оригинала 17 июля 2011 года . Проверено 30 июля 2011 г.
  72. ^ «Портфолио брифингов» (PDF) . www.mpegla.com .
  73. ^ «OMS Video, проект Sun Open Media Commons Initiative» . Архивировано из оригинала 11 мая 2010 года . Проверено 26 августа 2008 г.
  74. ^ «Лицензиары, включенные в лицензию на портфель патентов AVC/H.264» . MPEG Лос-Анджелес . Проверено 18 июня 2019 г.
  75. ↑ Перейти обратно: Перейти обратно: а б «AVC/H.264 – Список патентов» . Через Лицензионный Альянс . Проверено 28 апреля 2024 г.
  76. ^ «Лицензия AVC MPEG LA не взимает роялти за интернет-видео, которое бесплатно предоставляется конечным пользователям в течение всего срока действия лицензии» (PDF) . MPEG Лос-Анджелес. 26 августа 2010 г. Архивировано из оригинала (PDF) 7 ноября 2013 г. . Проверено 26 августа 2010 г.
  77. ^ Хачман, Марк (26 августа 2010 г.). «MPEG LA навсегда сокращает гонорары за бесплатное веб-видео» . pcmag.com . Проверено 26 августа 2010 г.
  78. ^ «Часто задаваемые вопросы по АВК» . MPEG Лос-Анджелес. 1 августа 2002 года. Архивировано из оригинала 7 мая 2010 года . Проверено 17 мая 2010 г.
  79. ^ «Патент США 9 356 620 Бэезе и др.» . Проверено 1 августа 2022 г. с самой ранней датой приоритета 14 сентября 2001 г., срок продлен на 2998 дней.
  80. ↑ Перейти обратно: Перейти обратно: а б с См . Qualcomm Inc. против Broadcom Corp. , № 2007-1545, 2008-1162 (Федеральный суд от 1 декабря 2008 г.). Статьи в популярной прессе см. на сайте Signonsandiego.com, «Qualcomm проигрывает дело о патентных правах» и «Патентное дело Qualcomm передается на рассмотрение присяжных» ; и Bloomberg.com «Broadcom выигрывает первое судебное разбирательство по патентному спору Qualcomm»
  81. ^ «Нокиа h264» .

Дальнейшее чтение [ править ]

Внешние ссылки [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Advanced_Video_Coding&oldid=1227369315"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 30c0692c50f19f43e82a35c152b85104__1717568940
URL1:https://arc.ask3.ru/arc/aa/30/04/30c0692c50f19f43e82a35c152b85104.html
Заголовок, (Title) документа по адресу, URL1:
Advanced Video Coding - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)