On Tue, 8 Jun 2021, Valerii Zapodovnikov wrote:
Can you merge my mxfdec patch? Thank you.
I'd give at least a week for the mxf maintainer to respond before
pushing.
Listen, it is commonly known that ffplay is broken, Carl agrees. MPV is not
broken and is perfect according to reference c
On Tue, 8 Jun 2021, Valerii Zapodovnikov wrote:
Wait a second. SDL_SetYUVConversionMode does not support 444? You are
setting it to mode = SDL_YUV_CONVERSION_AUTOMATIC if it is 444, which I
suppose works on just the size of frame?
SDL itself does not support YUV444 pixel format, by the time
Wait a second. SDL_SetYUVConversionMode does not support 444? You are
setting it to mode = SDL_YUV_CONVERSION_AUTOMATIC if it is 444, which I
suppose works on just the size of frame? Then this cannot be fixed, I
suppose? There is a workround above, as I said.
___
вт, 8 июн. 2021 г., 5:28 Michael Bradshaw :
> I'll just chime in and say:
>
> FIXME comments aren't that helpful. It would be more helpful to av_log when
> you detect you've hit an unsupported situation.
>
How should I know what are unsupported situations? I mean sure, sYCC
(BT.709 primaries with
I'll just chime in and say:
FIXME comments aren't that helpful. It would be more helpful to av_log when
you detect you've hit an unsupported situation.
As for SMPTE 240M vs BT.601 Y'CbCr matrices: yes, they're different. But
SDL doesn't support SMPTE 240M. It only supports:
SDL_YUV_CONVERSION_JP
Can you merge my mxfdec patch? Thank you. Maybe all my oldest patches too,
except XYZ patch to libopenjpeg, that is WIP, since openjpeg did not even
merge yet or did a release to support that wrapper option.
Listen, it is commonly known that ffplay is broken, Carl agrees. MPV is not
broken and is
On Tue, 8 Jun 2021, Valerii Zapodovnikov wrote:
You are **very** wrong. This is YCbCr 101: 420 has all the same colors as
444 does. Just if one pixel is fixated the entagled pixels have less than
all possible colors. This is also not corners issues, it is reproducable on
one color all over th
You are **very** wrong. This is YCbCr 101: 420 has all the same colors as
444 does. Just if one pixel is fixated the entagled pixels have less than
all possible colors. This is also not corners issues, it is reproducable on
one color all over the plane. Again, the workaround is to use ffplay -vf
s
On Mon, 7 Jun 2021, Valerii Zapodovnikov wrote:
I cannot clarify it further, the issue is there on trac.
And that ticket is bogus, because comparison is made between 4:2:0 and
4:4:4. And when the reporter says the colors are muddy, he means the pixel
format diffrerence, not the color spac
I cannot clarify it further, the issue is there on trac.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsub
On Mon, 7 Jun 2021, Valerii Zapodovnikov wrote:
Signed-off-by: Valerii Zapodovnikov
---
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/ffpla
Signed-off-by: Valerii Zapodovnikov
---
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_co
12 matches
Mail list logo
