aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/pixfmt.h
Commit message (Collapse)AuthorAgeFilesLines
* avutil/hwcontext: Add ohcodec device and pixel formatZhao Zhili2025-07-181-0/+2
| | | | Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
* avutils/pixfmt: add YUV444/GBRP 10 and 12 bit MSB formatsTimo Rothenpieler2025-07-111-0/+15
|
* pixfmt: add AV_PIX_FMT_GBRAP32Lynne2025-03-171-0/+4
| | | | | | This commit adds a 32-bit *integer* planar RGBA format. Vulkan FFv1 decoding is best performed on separate planes, rather than packed RGBA (i.e. RGBA128), hence this is useful as an intermediate format.
* avutil/pixfmt: add YAF16 and YAF32 pixel formatsJames Almer2025-03-101-0/+9
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* pixfmt: add AV_PIX_FMT_GRAY32Lynne2025-03-011-0/+4
| | | | This is a useful format for high-precision intermediates.
* avutil: add hwcontext_amf.Dmitrii Ovchinnikov2025-02-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds hwcontext_amf, enabling a shared AMF context for encoders, decoders, and AMF-based filters, without copy to the host memory. Code also was tested in HandBrake. Benefits: - Optimizations for direct video memory access from CPU - Significant performance boost in full AMF pipelines with filters - Integration of GPU filters like VPP, Super Resolution, and Compression Artefact Removal(in future plans) - VCN power management control for decoders. - Ability to specify which VCN instance to use for decoding (like for encoder) - AMD will soon introduce full AMF API for multimedia accelerator MA35D - With AMF API, integration will be much easier: GPU and the accelerator will have the same API - including encoder, decoder, scaler, color converter, Windows and Linux. Learn more: https://www.amd.com/en/products/accelerators/alveo/ma35d.html Changes by versions: v2: Header file cleanup. v3: Removed an unnecessary class. v4: code cleanup and improved error handling v5: Fixes related to HandBrake integration. v6: Sequential filters error and memory leak have been fixed.
* libavutil/pixfmt: 16bit float supportMichael Niedermayer2025-01-211-0/+11
| | | | | Sponsored-by: Sovereign Tech Fund Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avutil/pixfmt: add XV48 pixel formatJames Almer2024-10-261-0/+4
| | | | | | | Much like XV30 and XV36 in d75c4693fef51e8f0a1b88798530f4c5147ea906, XV48 is added to support 16bit 4:4:4 as defined by Microsoft. Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixfmt: add Y216 pixel formatJames Almer2024-10-231-0/+4
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* lavu/pixfmt: add AV_PIX_FMT_RGB96Lynne2024-10-151-0/+4
|
* lavu/pixfmt: add AV_PIX_FMT_RGBA128Lynne2024-10-151-0/+5
| | | | | | | | This format is useful for doing certain lossless transforms on images, RCT in particular, which require you to escalate the size from 16 to 32 bits to avoid overflows. APIchanges will be done alongside when comitting.
* avutil: add RGBF16 pix_fmtMartin Schitter2024-10-141-0/+4
| | | | Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avutil/pixfmt: add V30X pixel formatJames Almer2024-10-081-0/+4
| | | | | | This maps to the 444YpCbCr10 pixel format as defined by Apple. Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixfmt: add VYU444 pixel formatJames Almer2024-10-081-0/+2
| | | | | | | This maps to the 444YpCbCr8 pixel format as defined by Apple, which is ordered Cr Y' Cb. Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixfmt: add UYVA pixel formatJames Almer2024-10-081-0/+2
| | | | | | | This maps to the 4444YpCbCrA8 pixel format as defined by Apple, which is ordered Cb Y' Cr A. Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixfmt: add AYUV pixel formatJames Almer2024-10-081-0/+2
| | | | | | | This maps to the 4444AYpCbCr8 pixel format as defined by Apple, which is ordered A Y’ Cb Cr. Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixfmt: extend the VUY{A,X} descriptionJames Almer2024-10-081-2/+2
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pix{desc,fmt}: add new matrix coefficients from H.273 v3Jan Ekström2024-04-031-0/+3
| | | | | | | | | | | | * SMPTE ST 2128 IPT-C2 defines the coefficients utilized in DoVi Profile 5. Profile 5 can thus now be represented in VUI as {AVCOL_RANGE_JPEG, AVCOL_PRI_BT2020, AVCOL_TRC_SMPTE2084, AVCOL_SPC_IPT_C2, AVCHROMA_LOC_LEFT} (although other chroma sample locations are allowed). AVCOL_TRC_SMPTE2084 should in this case be interpreted as 'PQ with reshaping'. * YCgCo-Re and YCgCo-Ro define the bitexact YCgCo-R, where the number of bits added to a source RGB bit depth is 2 (i.e., even) and 1 (i.e., odd), respectively.
* avutil: remove deprecated FF_API_XVMCJames Almer2024-03-071-4/+0
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixfmt: Add AV_VIDEO_MAX_PLANESMichael Niedermayer2024-02-161-0/+7
| | | | | | It seems we do not have a named identifier for the maximum planes of pixel formats Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avutil/pixfmt: fix AV_PIX_FMT_RGB8 descriptionJeffrey Knockel2024-01-161-1/+1
| | | | | | | | | | | Previously AV_PIX_FMT_RGB8 was documented as "RGB 3:3:2, (msb)2R 3G 3B(lsb)". While the RGB 3:3:2 part is correct, the latter part should be: (msb)3R 3G 2B(lsb). This commit also updates the format's pixdesc description to be (msb)3R 3G 2B(lsb). Signed-off-by: Jeffrey Knockel <jeff@jeffreyknockel.com> Reviewed-by: "Diederick C. Niehorster" <dcnieho@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* libavutil: add hwcontext_d3d12va and AV_PIX_FMT_D3D12Wu Jianhua2023-12-211-0/+7
| | | | | Signed-off-by: Wu Jianhua <toqsxw@outlook.com> Signed-off-by: Tong Wu <tong1.wu@intel.com>
* avutil: add GBRAP14 format supportPaul B Mahol2023-09-281-0/+4
|
* lavu: add 12-bit 2-plane 422 and 444 pixel formatsLynne2023-05-291-0/+8
|
* lavu/pixfmt: Update the description for AV_PIX_FMT_QSVHaihao Xiang2022-11-221-2/+30
| | | | | | | | | | Since D3D11 was introduced for QSV in FFmpeg 5.0, there is an implied API/ABI change for user-supplied frames [1], hence update the description for AV_PIX_FMT_QSV. [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/290444.html Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
* avutil/pixfmt.h: add native-endian RGB32F and RGBA32F formatsLeo Izen2022-10-111-0/+3
| | | | | | | | | Add an AV_PIX_FMT_NE macro for RGB32FBE/RGB32FLE and also one for RGBA32FBE/RGBA32FLE for packed 32-bit float RGB samples, and also packed 32-bit float RGBA samples, respectively. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Leo Izen <leo.izen@gmail.com>
* avutil: add RGBA single-float precision packed formatsPaul B Mahol2022-09-251-0/+3
|
* avutil: add RGB single-precision float formatsPaul B Mahol2022-09-251-0/+3
|
* lavu/pixfmt: Add P012, Y212, XV30, and XV36 formatsPhilip Langdale2022-09-031-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These are the formats we want/need to use when dealing with the Intel VAAPI decoder for 12bit 4:2:0, 12bit 4:2:2, 10bit 4:4:4 and 12bit 4:4:4 respectively. As with the already supported Y210 and YUVX (XVUY) formats, they are based on formats Microsoft picked as their preferred 4:2:2 and 4:4:4 video formats, and Intel ran with it. P12 and Y212 are simply an extension of 10 bit formats to say 12 bits will be used, with 4 unused bits instead of 6. XV30, and XV36, as exotic as they sound, are variants of Y410 and Y412 where the alpha channel is left formally undefined. We prefer these over the alpha versions because the hardware cannot actually do anything with the alpha channel and respecting it is just overhead. Y412/XV46 is a normal looking packed 4 channel format where each channel is 16bits wide but only the 12msb are used (like P012). Y410/XV30 packs three 10bit channels in 32bits with 2bits of alpha, like A/X2RGB10 style formats. This annoying layout forced me to define the BE version as a bitstream format. It seems like our pixdesc infrastructure can handle the LE version being byte-defined, but not when it's reversed. If there's a better way to handle this, please let me know. Our existing X2 formats all have the 2 bits at the MSB end, but this format places them at the LSB end and that seems to be the root of the problem.
* lavu/pixfmt: Introduce VUYX formatPhilip Langdale2022-08-251-0/+2
| | | | | | | | | | | | | | This is the alphaless version of VUYA that I introduced recently. After further discussion and noting that the Intel vaapi driver explicitly lists XYUV as a support format for encoding and decoding 8bit 444 content, we decided to switch our usage and avoid the overhead of having a declared alpha channel around. Note that I am not removing VUYA, as this turned out to have another use, which was to replace the need for v408enc/dec when dealing with the format. The vaapi switching will happen in the next change
* lavu/pixfmt: add packed RGBA float16 formatTimo Rothenpieler2022-08-131-0/+5
| | | | | This is the default format of the Windows compositor and what DXGI Desktop Duplication will give you for any kind of HDR output.
* lavu/pixfmt: Add packed 4:4:4 formatPhilip Langdale2022-08-031-0/+2
| | | | | | | | | The "AYUV" format is defined by Microsoft as their preferred format for 4:4:4 content, and so it is the format used by Intel VAAPI and QSV. As Microsoft like to define their byte ordering in little-endian fashion, the memory order is reversed, and so our pix_fmt, which follows memory order, has a reversed name (VUYA).
* lavu/pixfmt: deprecate AV_PIX_FMT_XVMCAnton Khirnov2022-02-151-0/+2
| | | | It is no longer used for anything.
* avutil/pixfmt.h: typoDiederick Niehorster2022-01-211-1/+1
| | | | | Signed-off-by: Diederick Niehorster <dcnieho@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* lavu/pixfmt: add high-bit-depth semi-planar 4:2:2/4:4:4 formatsrcombs2021-11-281-0/+18
| | | | These are used by VideoToolbox hardware decoders.
* lavu/pix_fmt: add pixel format for x2bgr10Manuel Stoeckl2021-09-261-0/+3
| | | | | | | | | | | The new format (given in big/little endian forms) matches the existing X2RGB10 format, except with B and R channels switched. AV_PIX_FMT_X2BGR10 data often is created by OpenGL programs whose buffers use the GL_RGB10 internal format. Signed-off-by: Manuel Stoeckl <code@mstoeckl.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* pixfmt: fixed wrong fix of commentValerii Zapodovnikov2021-06-021-18/+18
| | | | | | | | | | | | This mostly reverts 785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b. But I also added some clarifications so that nobody mixes primaries with matrix again. SMPTE 240 and 170 primaires are the same, while matrix coeff. are different, because 240 is derived from 170's new primaries and white point while 170 uses BT.601 derived from BT.470 System M (yes, with Illuminant C) a.k.a. NTSC 1953. Some nits too. Reviewed-by: Reto Kromer <lists@reto.ch> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avutil/pixfmt: Remove deprecated VAAPI pixel formatsAndreas Rheinhardt2021-04-271-10/+0
| | | | | | | Deprecated in 9f8e57efe4400ca86352277873792792279c3b15. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixfmt: improve definition of AVColorRangeJan Ekström2020-09-231-3/+51
| | | | | | | | | | | | As it was brought up that the current documentation leaves things as specific to YCbCr only, ICtCp and RGB are now mentioned. Additionally, the specifications on which these definitions of narrow and full range are defined are mentioned. This way, the documentation of AVColorRange should now match how most people seem to read interpret it at this point, and thus flagging RGB AVFrames as full range is valid not only according to common sense, but also the enum definition.
* lavu/pix_fmt: add new pixel format x2rgb10Fei Wang2020-06-121-0/+3
| | | | | | | The format is packed RGB with each channel 10 bits available and include 2 bits unused. Signed-off-by: Fei Wang <fei.w.wang@intel.com>
* lavu/pix_fmt: add new pixel format y210Linjie Fu2020-02-241-0/+5
| | | | | | | Add some packed 4:2:2 10-bit pixel formats for hardware decode support in VAAPI and QSV. Signed-off-by: Linjie Fu <linjie.fu@intel.com>
* lavu: add Vulkan hwcontext codeLynne2020-02-041-0/+7
| | | | | | | | | | This commit adds the necessary code to initialize and use a Vulkan device within the hwcontext libavutil framework. Currently direct mapping to VAAPI and DRM frames is functional, and transfers to CUDA and native frames are supported. Lets hope the future Vulkan video decode extension fits well within this framework.
* lavu/pixfmt: Cosmetics, remove wrong end-of-comment markers.Carl Eugen Hoyos2019-12-141-12/+12
|
* avutil/pixfmt: Add EBU Tech. 3213-E AVColorPrimaries valueRaphaël Zumer2019-09-011-1/+2
| | | | | | | | | | This is an alias for JEDEC P22. The name associated with the value is also changed from jedec-p22 to ebu3213 to match ITU-T H.273. Signed-off-by: Raphaël Zumer <rzumer@tebako.net> Signed-off-by: James Almer <jamrial@gmail.com>
* avutil: Add NV24 and NV42 pixel formatsPhilip Langdale2019-05-121-0/+3
| | | | | | | | | | | | | These are the 4:4:4 variants of the semi-planar NV12/NV21 formats. These formats are not used much, so we've never had a reason to add them until now. VDPAU recently added support HEVC 4:4:4 content and when you use the OpenGL interop, the returned surfaces are in NV24 format, so we need the pixel format for media players, even if there's no direct use within ffmpeg. Separately, there are apparently webcams that use NV24, but I've never seen one.
* avutil : add YUVA444P12 and YUVA422P12Martin Vignali2018-11-241-0/+7
|
* libavutil: Adds gray floating-point pixel formats.Sergey Lavrushkin2018-08-111-0/+5
| | | | Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avutil/pixfmt: Document chroma plane size for odd resolutionsMichael Niedermayer2018-07-201-0/+4
| | | | Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avutil: add gray14 pixel formatPaul B Mahol2018-05-051-0/+4
| | | | Signed-off-by: Paul B Mahol <onemda@gmail.com>
* lavu/pixfmt: Remove gap in the middle of enum AVPixelFormatMark Thompson2017-11-251-1/+1
| | | | | | | | This was added for compatibility with libav, by leaving a space for formats added in libav to be merged. Since that feature has been removed, we don't need a gap here. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-07 15:35:44 +0000