Chiebot-Mirror/FFmpeg - FFmpeg - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
James Almer	1f9424e0b1	avutil/pixfmt: add VYU444 pixel format 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>	3 months ago
James Almer	dc3ef53819	avutil/pixfmt: add UYVA pixel format 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>	3 months ago
James Almer	263108a504	avutil/pixfmt: add AYUV pixel format 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>	3 months ago
Philip Langdale	ed83a3a5bd	lavu/pixdesc: favour formats where depth and subsampling exactly match 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.	2 years ago
Philip Langdale	cc5a5c9860	lavu/pixfmt: Introduce VUYX format 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	2 years ago
James Almer	85c59bd6de	avutil/test/pixfmt_best: test the VUYA pixel format Signed-off-by: James Almer <jamrial@gmail.com>	2 years ago
Philip Langdale	5de4f1d871	avutil: Add NV24 and NV42 pixel formats 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.	6 years ago
Tobias Rapp	60008c0fe9	fate: update pixfmt_best test to check for endianness Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>	8 years ago
Mark Thompson	3192821237	pixdesc: Add a test for av_find_best_pix_fmt_of_2()	8 years ago