summaryrefslogtreecommitdiff
path: root/fftools/ffplay.c
diff options
context:
space:
mode:
authorNiklas Haas <git@haasn.dev>2022-06-21 21:39:25 +0200
committerNiklas Haas <git@haasn.dev>2022-06-27 12:17:59 +0200
commita526f0cc3ac938364afe8ce62c4bc47d3b9bb2af (patch)
treefa47a85a37eadcae419d00fb458df5c640c99dc1 /fftools/ffplay.c
parent49027e7612ac3f349f5fa8b6d8cc0c6a4036d05c (diff)
downloadffmpeg-a526f0cc3ac938364afe8ce62c4bc47d3b9bb2af.tar.gz
fftools/ffplay: fix YUV conversion mode
GL and Metal cache the state at time of texture creation. GLES2 and Direct3D 11 use the state at time of the render copy call. So the only way we can get the correct behavior consistently is by making sure the state is set for both the upload *and* the draw call. This probably isn't our bug to fix (upstream should make itself behave consistently and also document its functions), but as it stands, `ffplay` is misrendering BT.709 as BT.601 on my stock Linux system, and that leaves a bad taste in my mouth. Signed-off-by: Niklas Haas <git@haasn.dev>
Diffstat (limited to 'fftools/ffplay.c')
-rw-r--r--fftools/ffplay.c6
1 files changed, 4 insertions, 2 deletions
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 040afa0189..9242047f5c 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1011,15 +1011,17 @@ static void video_image_display(VideoState *is)
}
calculate_display_rect(&rect, is->xleft, is->ytop, is->width, is->height, vp->width, vp->height, vp->sar);
+ set_sdl_yuv_conversion_mode(vp->frame);
if (!vp->uploaded) {
- if (upload_texture(&is->vid_texture, vp->frame, &is->img_convert_ctx) < 0)
+ if (upload_texture(&is->vid_texture, vp->frame, &is->img_convert_ctx) < 0) {
+ set_sdl_yuv_conversion_mode(NULL);
return;
+ }
vp->uploaded = 1;
vp->flip_v = vp->frame->linesize[0] < 0;
}
- set_sdl_yuv_conversion_mode(vp->frame);
SDL_RenderCopyEx(renderer, is->vid_texture, NULL, &rect, 0, NULL, vp->flip_v ? SDL_FLIP_VERTICAL : 0);
set_sdl_yuv_conversion_mode(NULL);
if (sp) {