aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/pixdesc.c
Commit message (Collapse)AuthorAgeFilesLines
* avutil/hwcontext: Add ohcodec device and pixel formatZhao Zhili2025-07-181-0/+4
| | | | Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
* avutils/pixfmt: add YUV444/GBRP 10 and 12 bit MSB formatsTimo Rothenpieler2025-07-111-0/+96
|
* pixfmt: add AV_PIX_FMT_GBRAP32Lynne2025-03-171-0/+28
| | | | | | 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/+44
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* pixfmt: add AV_PIX_FMT_GRAY32Lynne2025-03-011-0/+21
| | | | This is a useful format for high-precision intermediates.
* avutil: add hwcontext_amf.Dmitrii Ovchinnikov2025-02-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+74
| | | | | Sponsored-by: Sovereign Tech Fund Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avutil/pixfmt: add XV48 pixel formatJames Almer2024-10-261-0/+25
| | | | | | | 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/+23
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixdesc: fix alpha offset for X2{RGB,BGR}10BEJames Almer2024-10-211-2/+2
| | | | | | fixes fate-pixelutils Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixdesc: add alpha component information to pixfmts with reserved but ↵James Almer2024-10-211-2/+17
| | | | | | | | | | | | undefined alpha bits This can be useful to simplify certain processes that need to know how many reserved bits there are and where they are placed, even if they are ultimately unused, as will be shown in the next commit. For any other case where the user simply looks at nb_components components, it will make no difference. Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixdesc: ensure the component being read or writen to is validJames Almer2024-10-211-0/+6
| | | | | | If depth is 0, then the component is invalid/unset. Signed-off-by: James Almer <jamrial@gmail.com>
* lavu/pixfmt: add AV_PIX_FMT_RGB96Lynne2024-10-151-0/+24
|
* lavu/pixfmt: add AV_PIX_FMT_RGBA128Lynne2024-10-151-0/+27
| | | | | | | | 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/+25
| | | | Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* avutil/pixdesc: use a bigger variable type when writing bitstream formatsJames Almer2024-10-101-1/+1
| | | | | | | Fixes fate-imgutils and fate-pixelutils under gcc-usan after 29ea34728f1064877a0ab9b8dee0f3de69a2d750. Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixfmt: add V30X pixel formatJames Almer2024-10-081-0/+23
| | | | | | 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/+11
| | | | | | | 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/+13
| | | | | | | 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/+13
| | | | | | | 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/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-6/+0
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixfmt: fix AV_PIX_FMT_RGB8 descriptionJeffrey Knockel2024-01-161-3/+3
| | | | | | | | | | | 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/+4
| | | | | Signed-off-by: Wu Jianhua <toqsxw@outlook.com> Signed-off-by: Tong Wu <tong1.wu@intel.com>
* avutil/pixdesc: simplify xyz pixfmt checkNiklas Haas2023-10-311-4/+4
|
* avutil/pixdesc: add AV_PIX_FMT_FLAG_XYZNiklas Haas2023-10-311-3/+3
| | | | | | | | | There are already several places in the codebase that match desc->name against "xyz", and many downstream clients replicate this behavior. I have no idea why this is not just a flag. Motivated by my desire to add yet another check for XYZ to the codebase, and I'd rather not keep copy/pasting a string comparison hack.
* avutil: add GBRAP14 format supportPaul B Mahol2023-09-281-0/+28
|
* lavu: add 12-bit 2-plane 422 and 444 pixel formatsLynne2023-05-291-0/+48
|
* lavu/pixdesc: handle xv30be in av_[read|write]_image_linePhilip Langdale2022-12-081-20/+50
| | | | | | | | | | | | | | | | | | | | xv30be is an obnoxious format that I shouldn't have included in the first place. xv30 packs 3 10bit channels into 32bits and while our byte-oriented logic can handle Little Endian correctly, it cannot handle Big Endian. To avoid that, I marked xv30be as a bitstream format, but while that didn't produce FATE errors, it turns out that the existing read/write code silently produces incorrect results, which can be revealed via ubsan. In all likelyhood, the correct fix here is to remove the format. As this format is only used by Intel vaapi, it's only going to show up in LE form, so we could just drop the BE version. But I don't want to deal with creating a hole in the pixfmt list and all the weirdness that comes from that. Instead, I decided to write the correct read/write code for it. And that code isn't too bad, as long as it's specialised for this format, as the channels are all bit-aligned inside a 32bit word.
* avutil/pixdesc: Move ff_check_pixfmt_descriptors() to its only userAndreas Rheinhardt2022-09-301-49/+0
| | | | | | | Namely to lavu/tests/pixelutils.c. This way, this function will not be included into actual binaries any more. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/pixdesc: Avoid direct access to pix fmt desc arrayAndreas Rheinhardt2022-09-301-5/+13
| | | | | | | | | Instead use av_pix_fmt_desc_next(). It is still possible to check its return values by comparing it with the (currently) expected values and the code does so. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/pixdesc: Remove always-false checksAndreas Rheinhardt2022-09-301-3/+1
| | | | | | | | | | | | | | | | | | | | | ff_check_pixfmt_descriptors() was added in commit 20e99a9c10cdbe9ad659dce5bdec569d744f8219. At this time, the values of enum AVPixelFormat were not contiguous; instead there was a jump from 111 to 291 (or from 115 to 295 depending upon AV_PIX_FMT_ABI_GIT_MASTER). ff_check_pixfmt_descriptors() accounts for this by skipping empty descriptors. Yet this issue no longer exists: There are no holes. The check for said holes makes GCC believe that the name can be NULL; because it is used as argument corresponding to %s in a log statement, it therefore emits a warning (since d75c4693fef51e8f0a1b88798530f4c5147ea906). Therefore this commit simply removes these checks. Also move the checks for name before the log statement. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/pixdesc: Add av_chroma_location_(enum_to_pos|pos_to_enum)Andreas Rheinhardt2022-09-261-0/+23
| | | | | | | They are intended as replacements for avcodec_enum_to_chroma_pos() and avcodec_chroma_pos_to_enum(). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil: add RGBA single-float precision packed formatsPaul B Mahol2022-09-251-0/+28
|
* avutil: add RGB single-precision float formatsPaul B Mahol2022-09-251-0/+25
|
* lavu/pixdesc: favour formats where depth and subsampling exactly matchPhilip Langdale2022-09-171-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since introducing the various packed formats used by VAAPI (and p012), we've noticed that there's actually a gap in how av_find_best_pix_fmt_of_2 works. It doesn't actually assign any value to having the same bit depth as the source format, when comparing against formats with a higher bit depth. This usually doesn't matter, because av_get_padded_bits_per_pixel() will account for it. However, as many of these formats use padding internally, we find that av_get_padded_bits_per_pixel() actually returns the same value for the 10 bit, 12 bit, 16 bit flavours, etc. In these tied situations, we end up just picking the first of the two provided formats, even if the second one should be preferred because it matches the actual bit depth. This bug already existed if you tried to compare yuv420p10 against p016 and p010, for example, but it simply hadn't come up before so we never noticed. But now, we actually got a situation in the VAAPI VP9 decoder where it offers both p010 and p012 because Profile 3 could be either depth and ends up picking p012 for 10 bit content due to the ordering of the testing. In addition, in the process of testing the fix, I realised we have the same gap when it comes to chroma subsampling - we do not favour a format that has exactly the same subsampling vs one with less subsampling when all else is equal. To fix this, I'm introducing a small score penalty if the bit depth or subsampling doesn't exactly match the source format. This will break the tie in favour of the format with the exact match, but not offset any of the other scoring penalties we already have. I have added a set of tests around these formats which will fail without this fix.
* lavu/pixfmt: Add P012, Y212, XV30, and XV36 formatsPhilip Langdale2022-09-031-1/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+11
| | | | | | | | | | | | | | 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/+28
| | | | | 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/+13
| | | | | | | | | 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.
* lavu/pixfmt: add high-bit-depth semi-planar 4:2:2/4:4:4 formatsrcombs2021-11-281-0/+96
| | | | These are used by VideoToolbox hardware decoders.
* lavu/pix_fmt: add pixel format for x2bgr10Manuel Stoeckl2021-09-261-0/+24
| | | | | | | | | | | 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>
* Remove obsolete version.h inclusionsAndreas Rheinhardt2021-07-221-1/+0
| | | | | | | These have mostly been added because of FF_API_*; yet when these were removed, removing the header has been forgotten. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/pixdesc: Remove deprecated AV_PIX_FMT_FLAG_PSEUDOPALAndreas Rheinhardt2021-04-271-5/+4
| | | | | | | Deprecated in d6fc031caf64eed921bbdef86d79d56bfc2633b0. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixdesc: Remove deprecated off-by-one fields from pix fmt descsAndreas Rheinhardt2021-04-271-531/+525
| | | | | | | Deprecated in 2268db2cd052674fde55c7d48b7a5098ce89b4ba. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixfmt: Remove deprecated VAAPI pixel formatsAndreas Rheinhardt2021-04-271-25/+0
| | | | | | | Deprecated in 9f8e57efe4400ca86352277873792792279c3b15. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/pixdesc: Fix 1 << 32Andreas Rheinhardt2021-04-011-1/+1
| | | | Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* avutil/pixdesc: Use av_strstart where appropriateAndreas Rheinhardt2021-02-281-22/+11
| | | | | | | It makes the intent clearer and allows to avoid calculating the strlen separately. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
* lavu/pix_fmt: add new pixel format x2rgb10Fei Wang2020-06-121-0/+24
| | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-08 08:41:25 +0000