summaryrefslogtreecommitdiffstats
path: root/video/img_format.c
diff options
context:
space:
mode:
authorNiklas Haas <git@nand.wakku.to>2016-03-05 11:29:19 +0100
committerwm4 <wm4@nowhere>2016-03-05 13:08:38 +0100
commit93546f0c2f8e4df211eb907e1247aa6f2b97721d (patch)
tree5b91ce6f8248d46630162f1eb8500a68fa871b19 /video/img_format.c
parentfb2f8abaaab604595474e932ff888d73f6f86fc7 (diff)
downloadmpv-93546f0c2f8e4df211eb907e1247aa6f2b97721d.tar.bz2
mpv-93546f0c2f8e4df211eb907e1247aa6f2b97721d.tar.xz
vo_opengl: refactor pass_read_video and texture binding
This is a pretty major rewrite of the internal texture binding mechanic, which makes it more flexible. In general, the difference between the old and current approaches is that now, all texture description is held in a struct img_tex and only explicitly bound with pass_bind. (Once bound, a texture unit is assumed to be set in stone and no longer tied to the img_tex) This approach makes the code inside pass_read_video significantly more flexible and cuts down on the number of weird special cases and spaghetti logic. It also has some improvements, e.g. cutting down greatly on the number of unnecessary conversion passes inside pass_read_video (which was previously mostly done to cope with the fact that the alternative would have resulted in a combinatorial explosion of code complexity). Some other notable changes (and potential improvements): - texture expansion is now *always* handled in pass_read_video, and the colormatrix never does this anymore. (Which means the code could probably be removed from the colormatrix generation logic, modulo some other VOs) - struct fbo_tex now stores both its "physical" and "logical" (configured) size, which cuts down on the amount of width/height baggage on some function calls - vo_opengl can now technically support textures with different bit depths (e.g. 10 bit luma, 8 bit chroma) - but the APIs it queries inside img_format.c doesn't export this (nor does ffmpeg support it, really) so the status quo of using the same tex_mul for all planes is kept. - dumb_mode is now only needed because of the indirect_fbo being in the main rendering pipeline. If we reintroduce p->use_indirect and thread a transform through the entire program this could be skipped where unnecessary, allowing for the removal of dumb_mode. But I'm not sure how to do this in a clean way. (Which is part of why it got introduced to begin with) - It would be trivial to resurrect source-shader now (it would just be one extra 'if' inside pass_read_video).
Diffstat (limited to 'video/img_format.c')
-rw-r--r--video/img_format.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/video/img_format.c b/video/img_format.c
index 82136b5192..fe2ca14bf4 100644
--- a/video/img_format.c
+++ b/video/img_format.c
@@ -171,6 +171,7 @@ struct mp_imgfmt_desc mp_imgfmt_get_desc(int mpfmt)
shift = d.shift;
if (shift != d.shift)
shift = -1;
+ desc.components[d.plane] += 1;
}
for (int p = 0; p < 4; p++) {