So I am resending still with that comment and a typo fixed to "ffplay". I
also found this:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20180501194013.9552-8-one...@gmail.com/
It way be nice to apply that too, but then again my problem is not that.
AVFrame->color_range? But even if I were using full range file (I do not)
that would force BT.601 full range matrix (that is JPEG matrix) and I have
the opposite here, BT.709 is forced.
I suppose the problem can be checked with simple printf
of frame->colorspace with that sample that uses BT.601.
On Sun, 6 Jun 2021, Valerii Zapodovnikov wrote:
I am sorry, what? It converts to 420 always? Wow? But you are right.
Yes, because ffplay uses the default SDL renderer (may it be
opengl/directx or anything else), and ffplay queries the hardware
acccelerated pixel formats supported by that
I am sorry, what? It converts to 420 always? Wow? But you are right. This
is a problem that colors are wrong after YUV444 - > YUV420 -> RGB. It
selects BT.709 matrix even if BT.601 matrix is requested, this can be fixed
by "ffplay -vf scale=in_color_matrix=auto,format=gbrp" or just by using
mpv. Ma
patch subject has a type (ffplay v.s. ffprobe)
On Wed, 26 May 2021, Valerii Zapodovnikov wrote:
---
fftools/ffplay.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 0be1d90bf9..53bd9362fa 100644
--- a/fftools/ffplay.c
+++ b/ff
---
fftools/ffplay.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 0be1d90bf9..53bd9362fa 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -963,12 +963,12 @@ static void set_sdl_yuv_conversion_mode(AVFrame *frame)
if
