diff options
author | wm4 <wm4@nowhere> | 2019-10-26 00:02:51 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-10-26 00:02:55 +0200 |
commit | a908101258bc5c8d33ded6a1e750fb65df8cf640 (patch) | |
tree | 6738989e00cb21e84504d473982396fd8ae2294d /video/out/cocoa/video_view.m | |
parent | d3f8d822791618cd7033b756a3d40ab475373817 (diff) | |
download | mpv-a908101258bc5c8d33ded6a1e750fb65df8cf640.tar.bz2 mpv-a908101258bc5c8d33ded6a1e750fb65df8cf640.tar.xz |
vo_gpu: attempt to fix 0bgr format
Using e.g. --vf=format=0bgr showed obviously wrong colors with --vo=gpu.
The reason is that leading padding wasn't handled correctly.
Try to hack fix it. While the code in copy_image() is somewhat
reasonable, I can't tell what the fuck is going on with that HOOKED
shit. For some reason this HOOKED shit doesn't use copy_image() (???),
or uses it incorrectly. It affects debanding. --deband=no works
correctly. If it's enabled, the crap in hook_prelude() is needed.
I bet there are many more bugs with this. For example, the deband shader
will try to deband the alpha channel if the format abgr is used (because
the correct component order is only established later). This can be
tested by inserting a "color.x = 0;" at the end of the deband shader,
and using --vf=format=rgba vs. abgr.
I cannot comprehend why it doesn't just store explicitly which
components a texture contains, and why it doesn't just read the
components always in an uniform way.
There's a big chance this fix works only by coincidence. This shouldn't
have been so hard either. Time for a complete rewrite?
Diffstat (limited to 'video/out/cocoa/video_view.m')
0 files changed, 0 insertions, 0 deletions