DirectShow / Video-for-Windows fourcc <-> VideoPixelFormat. More...
Detailed Description
DirectShow / Video-for-Windows fourcc <-> VideoPixelFormat.
The YUV MEDIASUBTYPE_* GUIDs are all of the form {fourcc, 0x0000, 0x0010, {0x80,0x00,0x00,0xaa,0x00,0x38,0x9b,0x71}}, so the subtype reduces to the fourcc in Data1. Keeping the table in those terms makes it portable and unit-testable on any host, instead of hiding a mapping nobody can exercise inside Windows-only code. The RGB subtypes are genuine SDK GUIDs rather than fourccs and stay with the DirectShow enumeration.
Deliberately not platform-guarded: the point is that it builds and is tested everywhere.
Go to the source code of this file.
Namespaces | |
| namespace | score |
| Base toolkit upon which the software is built. | |
| namespace | score::gfx |
| Graphics rendering pipeline for ossia score. | |
Functions | |
| constexpr uint32_t | score::gfx::interop::directShowFourcc (char a, char b, char c, char d) noexcept |
| Build a fourcc the way DirectShow spells it, least-significant byte first. | |
| VideoPixelFormat | score::gfx::interop::fromDirectShowFourcc (uint32_t fourcc) noexcept |
| bool | score::gfx::interop::isDirectShowCompressedFourcc (uint32_t fourcc) noexcept |
Function Documentation
◆ fromDirectShowFourcc()
|
noexcept |
The layout behind a DirectShow YUV fourcc, or Unknown for compressed, RGB-GUID and unhandled subtypes.
◆ isDirectShowCompressedFourcc()
|
noexcept |
True when the fourcc names a compressed stream rather than a raw layout, so the caller reaches for a decoder instead of a pixel format.