summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2012-10-21 17:12:42 +0200
committerwm4 <wm4@nowhere>2012-10-24 21:56:34 +0200
commit6bea013e27c705ad0bc39f7da22b4ac4eabd7890 (patch)
tree86b7b907dc908e64211fbe6efdc2d0f5010e11e2
parent4b4e4b56909a07f1738d75c0f3fc1739990adfc9 (diff)
downloadmpv-6bea013e27c705ad0bc39f7da22b4ac4eabd7890.tar.bz2
mpv-6bea013e27c705ad0bc39f7da22b4ac4eabd7890.tar.xz
screenshot: hack against w/width confusion
struct mp_image has two sets of size members: width/height and w/h. It's not even sure which one of these is the ACTUAL dimension, and which is the "stored" or "visible" dimension. vf_get_image() (a core function for video filters) does something confusing with the sizes, and often sets up cropped versions of other filter's image buffers. The screenshot code uses w/h to store the display size for anamorphic video, while width/height is the size of the pixel data. The draw_bmp.c code, as well as sws_utils.c, always use w/h for the size of the pixel data. It's an unholy mess, and the screenshot code potentially breaks it even more. Work that around with a hack, until we hopefully clean up mp_image and the video filter code.
-rw-r--r--screenshot.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/screenshot.c b/screenshot.c
index bfc86d5dce..c1709fb9b5 100644
--- a/screenshot.c
+++ b/screenshot.c
@@ -255,8 +255,12 @@ static struct mp_image *add_subs(struct MPContext *mpctx,
.display_par = sar / dar,
.video_par = dar / sar,
};
+ // It's not really clear what's the difference between w and width
+ struct mp_image hack = *image;
+ hack.w = hack.width;
+ hack.h = hack.height;
osd_draw_on_image(mpctx->osd, res, mpctx->osd->vo_pts,
- OSD_DRAW_SUB_ONLY, image, csp);
+ OSD_DRAW_SUB_ONLY, &hack, csp);
return image;
}