| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
|
|
|
|
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.
|
|
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
|
|
This is the default format of the Windows compositor and what DXGI
Desktop Duplication will give you for any kind of HDR output.
|
|
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).
|
|
It is no longer used for anything.
|
|
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
|
|
These are used by VideoToolbox hardware decoders.
|
|
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>
|
|
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>
|
|
Deprecated in 9f8e57efe4400ca86352277873792792279c3b15.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
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.
|
|
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>
|
|
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>
|
|
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.
|
|
|
|
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>
|
|
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.
|
|
|
|
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
Signed-off-by: Paul B Mahol <onemda@gmail.com>
|
|
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>
|
|
|
|
* commit 'dd343fd986459f467a2d1d70c26101dff1d47d68':
lavu: Drop deprecated VDPAU pixel formats
Merged-by: James Almer <jamrial@gmail.com>
|
|
* commit 'dcc39ee10e82833ce24aa57926c00ffeb1948198':
lavc: Remove deprecated XvMC support hacks
Merged-by: James Almer <jamrial@gmail.com>
|
|
Deprecated (aka removed) in OSX 10.11, and we have a replacement for it
(VideoToolbox).
|
|
|
|
Add a pixel format flag to identify this family.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
To be used with the new d3d11 hwaccel decode API.
With the new hwaccel API, we don't want surfaces to depend on the
decoder (other than the required dimension and format). The old D3D11VA
pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the
decoder configuration, and thus is incompatible with the new hwaccel
API. This patch introduces AV_PIX_FMT_D3D11, which uses ID3D11Texture2D
and an index. It's simpler and compatible with the new hwaccel API.
The introduced hwcontext supports only the new pixfmt.
Frame upload code untested.
Significantly based on work by Steve Lhomme <robux4@gmail.com>, but with
heavy changes/rewrites.
Merges Libav commit fff90422d181744cd75dbf011687ee7095f02875.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
It's an AVColorSpace value since 82ad9cbd32c873bced9adf4a2bb67dcda7294c61.
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
* commit '706af9227b58657c73e3a4df3689da734f010500':
lavu: Document the color properties enumeration values origin
Merged-by: Clément Bœsch <u@pkh.me>
|
|
* commit '17dac56b8fdd80c594c39b76de3f27a7949afbde':
lavu: Rename ycgco color space appropriately
Merged-by: Clément Bœsch <cboesch@gopro.com>
|
|
* commit '0d9b9bd37f43ee29ad9f709d85c8f3be9db71104':
lavu: Add JEDEC P22 color primaries
Merged-by: Clément Bœsch <u@pkh.me>
|
|
Mistake introduced in a1f6b1d9d816ad7e6a8f071b0efa2638bc80e65e.
|
|
* commit '310c55f1799deab395319471a75c528d0fa7b30d':
pixfmt: Document alternative names for smpte 431 and 432
Merged-by: Clément Bœsch <u@pkh.me>
|
|
Deprecated in 07/2013.
|
|
Deprecated in 11/2013.
|
|
|
|
P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
two bytes per component.
It may, and in fact is most likely to, be used in situations where
there are less than 16 bits of data. It is the responsibility of
the writer to zero out any unused LSBs.
|
|
Based on 7471352f by Luca Barbato.
|
|
* commit 'f172e22d6aed0bff36e975bafb0183b6779f9444':
pixdesc: Add aliases to SMPTE color properties
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
Planes are ordered as the name suggests now.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
|
