Commit Graph

13 Commits

Author SHA1 Message Date
Philip Langdale 98f02e33ef repack: add repacker for ccc16x16 formats
I'm adding support in ffmpeg for the XV36 format which will be used
by VAAPI for 12bit 4:4:4 content. It's an undefined-alpha channel
variant of Y412 which is itself a 12bit+4bits padding variant of Y416.

We currently have a repacker for full four channel cccc16, and for
three channel ccc16, but nothing for ccc16x16 with the undefined alpha
channel.

It's simple enough to add one using the existing macros.
2022-09-10 12:31:44 -07:00
Niklas Haas 8bd0dee531 osdep: rename MP_UNREACHABLE
It was pointed out on IRC that the name is misleading, since the actual
semantics of the macro is to assert first.
2021-11-03 15:15:20 +01:00
Niklas Haas c704824b45 osdep: add MP_UNREACHABLE
This seems to work on gcc, clang and mingw as-is, but I made it
conditional on __GNUC__ just in case, even though I can't figure out
which compilers we care about that don't export this define.

Also replace all instances of assert(0) in the code by MP_UNREACHABLE(),
which is a strict improvement.
2021-11-03 14:09:27 +01:00
wm4 b9069c9dbf repack: handle endian in a more general way
Instead of applying this only to "regular" formats, do it with all
formats.

For some reason, some repackers still have their own endian code. These
could probably be removed, but whatever.
2020-06-17 19:43:09 +02:00
wm4 320fa3bbe7 video: add AV_PIX_FMT_UYYVYY411 conversion support
It may be completely useless, and I can't verify it as no known samples
or other known/accessible software using it, but why not?

Putting this together with he 422 code requires making it slightly more
generic. I'm still staying with a "huge" if tree instead of a table to
select the scanline worker callback, because it's actually small and not
huge (although it not being generic still feels slightly painful).
2020-05-22 02:26:05 +02:00
wm4 756ae0321b repack: use new imgfmt metadata in more cases
Now everything is super generic and super undebuggable. Some awkwardness
because the new metadata is basically a transposed version of the
mp_regular_imgfmt metadata, which was used for component info before.
2020-05-21 02:51:54 +02:00
wm4 176f422213 video: shuffle imgfmt metadata code around
I guess I decided to stuff it all into mp_imgfmt_desc (the "old"
struct). This is probably a mistake. At first I was afraid that this
struct would get too fat (probably justified, and hereby happened), but
on the other hand mp_imgfmt_get_desc() (which builds the struct) calls
the former mp_imgfmt_get_layout(), and the separation doesn't make too
much sense anyway. Just merge them.

Still, try to keep out the extra info for packed YUV bullshit. I think
the result is OK, and there's as much information as there was before.

The test output changes a little. There's no independent bits[] array
anymore, so formats which did not previously have set this now show it.
(These formats are mpv-only and are still missing the metadata. To be
added later). Also, the output for the cursed packed formats changes.
2020-05-20 00:02:27 +02:00
wm4 bd911efdcd repack: make generic weird pixfmt shit even more generic and obfuscated
Use the new pixfmt metadata to replace the format tables with weird
generic code.

As you can see, this removes the tables that essentially duplicate
information (which is baaaaaaaaaad), in exchange for code which is
probably more fragile and has less of a chance of being understood by
someone new to the code (which is probably even worse from a maintenance
and robustness point of view, but LALALA I CAN'T HEAR YOU).

There are some more formats which can be handled like this (RGB30 and
packed YUV I guess), maybe later.
2020-05-18 20:15:03 +02:00
wm4 caee8748da video: clean up some imgfmt related stuff
Remove the vaguely defined plane_bits and component_bits fields from
struct mp_imgfmt_desc. Add weird replacements for existing uses. Remove
the bytes[] field, replace uses with bpp[].

Fix some potential alignment issues in existing code. As a compromise,
split mp_image_pixel_ptr() into 2 functions, because I think it's a bad
idea to implicitly round, but for some callers being slightly less
strict is convenient.

This shouldn't really change anything. In fact, it's a 100% useless
change. I'm just cleaning up what I started almost 8 years ago (see
commit 00653a3eb0). With this I've decided to keep mp_imgfmt_desc,
just removing the weird parts, and keeping the saner parts.
2020-05-18 01:54:59 +02:00
wm4 1e75f442b1 repack: fix incorrect assert()
Used the output of the first step instead of the input when checking the
real input.
2020-05-12 23:08:10 +02:00
wm4 9190b3c469 repack: add support for converting from/to float formats
Will be needed by draw_bmp.c. The tests cross-check this with zimg to
control whether we're getting it right.
2020-05-09 18:02:57 +02:00
wm4 4019c11314 video: fix rgb30 component order
Was broken with a zimg wrapper refucktor before the previous commit. In
addition, it seems this didn't match the vo_drm format, or the format
naming convention. So the order actually changes, and the format is
redefined. (The img_format.h comment was probably wrong.)

Change vo_gpu to the new format as well, so we can still test it.
2020-05-09 18:02:57 +02:00
wm4 d8002f1dde video: separate repacking code from zimg and make it independent
For whatever purpose. If anything, this makes the zimg wrapper cleaner.

The added tests are not particular exhaustive, but nice to have. This
also makes the scale_zimg.c test pretty useless, because it only tests
repacking (going through the zimg wrapper). In theory, the repack_tests
things could also be used on scalers, but I guess it doesn't matter.

Some things are added over the previous zimg wrapper code. For example,
some fringe formats can now be expanded to 8 bit per component for
convenience.
2020-05-09 18:02:57 +02:00