| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Now these are like x2ccc10_pack: MSB to LSB, with bit width following
each component (except for components with the same bit width).
|
| |
|
|
| |
This may be used later elsewhere.
|
| | |
|
| |
|
|
|
|
| |
Works for RGB (e.g. rgb48le) and XYZ.
It's unsure whether XYZ is really correctly converted.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The RGB pack/unpack code in theory supports packed, non-subsampled YUV,
although in practice FFmpeg defines no such formats. (Only one with
alpha, but all alpha input is rejected by the current code.)
This would in theory have failed, because we would have selected a GBRP
format (instead of YUV), which makes no sense and would either have been
rejected by zimg (inconsistent parameters), or lead to broken output
(wrong permutation of planes).
Select the correct format and don't permute the planes in the YUV case.
|
| |
|
|
|
|
|
| |
As suggested by the zimg author. This is mostly related to XYZ support.
It's unclear whether this works. Using the only XYZ test sample we know,
and the next commits to consume the pixfmt, it looks wrong.
|
|
|
This provides a very similar API to sws_utils.h, which can be used to
convert and scale from one mp_image to another.
This commit adds only the code, but does not use it anywhere.
The code is quite preliminary and barely tested. It supports only a few
pixel formats, and will return failure for many others. (Unlike
libswscale, which tries to support anything that FFmpeg knows.)
zimg itself accepts only planar formats. Supporting other formats
requires manual packing/unpacking. (Compared to libswscale, the zimg API
is generally lower level, but allows for more flexibility.) Only BGR0
output was actually tested. It appears to work.
|
