diff options
author | wm4 <wm4@nowhere> | 2015-01-27 18:08:42 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2015-01-27 18:09:03 +0100 |
commit | acb40644db08ca7a781583666deffab7beaba10a (patch) | |
tree | 41892390689ca66708be67a1f3bbcbb7f1732757 /sub/ass_mp.c | |
parent | f6e05b14b26549c4beaaf754149c99fa20b11bd3 (diff) | |
download | mpv-acb40644db08ca7a781583666deffab7beaba10a.tar.bz2 mpv-acb40644db08ca7a781583666deffab7beaba10a.tar.xz |
vo_opengl: change the way unaligned chroma size is handled
This deals with subsampled YUV video that has odd sizes, for example a
5x5 image with 4:2:0 subsampling.
It would be easy to handle if we actually passed separate texture
coordinates for each plane to the shader, but as of now the luma
coordinates are implicitly rescaled to chroma one. If luma and chroma
sizes don't match up, and this is not handled, you'd get a chroma shift
by 1 pixel.
The existing hack worked, but broke separable scaling. This was exposed
by a recent commit which switched to GL_NEAREST sampling for FBOs. The
rendering was accidentally scaled by 1 pixel, because the FBO size used
the original video size, while textures_sizes[0] was set to the padded
texture size (i.e. one pixel larger).
It could be fixed by setting the padded texture size only on the first
shader. But somehow that is annoying, so do something else. Don't pad
textures anymore, and rescale the chroma coordinates in the shader
instead.
Seems like this somehow doesn't work with rectangle textures (and
introduces a chroma shift), but since it's only used when doing VDA
hardware decoding, and the bug occurs only with unaligned video sizes, I
don't care much.
Fixes #1523.
Diffstat (limited to 'sub/ass_mp.c')
0 files changed, 0 insertions, 0 deletions