вт, 8 июн. 2021 г., 19:57 Thilo Borgmann :
> Am 08.06.21 um 18:52 schrieb Valerii Zapodovnikov:
> > Oh, so it worked on patchwork? Strnge, okay then. No need to.
>
> Please read [1] and [2]. Please keep all old text and do inline-commenting.
>
> -Thilo
>
No.
&
Oh, so it worked on patchwork? Strnge, okay then. No need to.
___
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 "
Plese resend it in new thread but rename it to .txt. thanks.
___
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 "u
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.
___
BTW, who knows how to show warnings on make job on patchwork? Only if make
fate fails you can see it, but not otherwise. Also, md5 warnings, when you
are going to fix those??
https://patchwork.ffmpeg.org/project/ffmpeg/patch/CAPUCmECSxQwMtttmRqTC-JtOpcfUB9SVQ8ZPZOHULFL9=2d...@mail.gmail.com/
_
вт, 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
Just resend them (without any -v2).
___
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 "unsubscribe".
Actually I do not know how well will this work. Did you ever play any
stream? Even if you play it without forcing seeking you are allowed to
search forth due to how latency works. That problem with latency was only
fixed in CMAF. ONE must to accelerate decoding forward in time to get low
latency.
Ah, yes, that is AVColorRange, sorry. :( Haha.
___
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 "unsubscribe".
Actually it is commonly understood all over the world that limited range is
the default when not present. All video in the world except Dolby Vision
profile 5 (if using IPTPQc2) is limited range.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https
Who knows what BS code "TODO figure out math. For now just drop them."
means? Is PTS of the mentioned there can be even theoretically valid or not?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
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
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
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
Do you know what command to use with
http://fate-suite.ffmpeg.org/dolby_e/16-11.pcm? I used -ac 6, but I dunno
everything else I used was not giving perfect sound (-f s16le -ac 6 was
most important to at least get something playable). Sigh. Also I suppose
sample rate will not be 48000 since it is
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
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.
In my case
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210607063205.180031-1-val.zapod...@gmail.com/
v1 failed to apply due to
https://github.com/FFmpeg/FFmpeg/commit/575e52272d42f4278c6620f1a999c41425db2094
I suppose in your case it is
https://github.com/FFmpeg/FFmpeg/commit/8bcce5673a267
This reverts commit d6d407d2d758b404af0ce6a8ff46bf164db020a1.
Hack not needed after a2b1dd0ce301450a47c972745a6b33c4c273aa5d.
Will fix #7480 and #8904.
This will include e.g. CODECS="hvc1.2.4.L123.B0" into m3u8.
Signed-off-by: Valerii Zapodovnikov
---
libavformat/dashenc.c | 6 +---
So there are 4 formats two for le and 2 for be? Oogh. Do you know which one
is used for dshow?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-
вс, 6 июн. 2021 г., 18:35 Michael Niedermayer :
> On Sun, Jun 06, 2021 at 04:50:41PM +0300, Valerii Zapodovnikov wrote:
> > I am sorry, what???
>
> If that is intended as a review comment, please compose
> a english sentance which represents what you are trying to convey.
>
So did you fix your gmail account? Also, what happened to FATE? Broken?
BTW, I just logged in my nvidia account through apple id and that email was
marked as spam too, but because of my filter it was not send into spam!
Cool :)
___
ffmpeg-devel mailing l
I hope it is the case since there was a problem with Intel P010 in Intel.
#8055, comment 1, sample_YUV_intel10bits(P010LE).7z
I still do not know what pixel format to force to decode that sample :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
Actually it is not my patch (as should be obvious as From: is not me) and
*NO* changes in API/ABI of openjpeg are happening with upsream patch. As
for your ABI... There is only one correct way to manipulate openjpeg API,
if you did that wrong, it is your problem.
Standard thing: "unexpected that u
Did you even read the commit message? You need to apply a patch to openjpeg
itself. Sigh.
___
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.
I am sorry, what???
___
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 "unsubscribe".
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.
From: Rémi Achard
Patch should be applied to decode XYZ samples with not native
decoder in ffmpeg (-c:v libopenjpeg, not -c:v jpeg2000). jpeg2000
works already.
Now, this is AFAIK a patch that should be applied after upstream's
patch: https://github.com/uclouvain/openjpeg/pull/1200
Please note th
: Valerii Zapodovnikov
---
libavcodec/libaomdec.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 6e7324a832..156e644263 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -134,15 +134,27
Forgot git commit -s, since it is more than 10 lines and not documentation
changes it should be required. Sorry, also I will not add Co-authored-by:
Carl <> since his patch was too flawed. Like really!? Oogh.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
Again. 240M matrix is different from BT.601! And 170M is the same
as BT.601. It is primaries that are the same in 240M and 170M, as
for jp2k_rsiz see page 17 of ST 422:2019. IT WAS THERE since 2006.
This wrong jp2k_rsiz is a copy-paste of header_open_partition_key.
---
libavformat/mxf.c| 2 +-
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
Of course it is a PeRfEct copy paste, I should have mentioned that (and I
asked Rémi to send the patch about RSIZ for XYZ, BTW). Also what this patch
actually fixes is encoding 170M, not 240M. Will fix that too.
Also should note that SMPTE ST 422:2019 is now free of charge. Yeah!
__
пн, 24 мая 2021 г., 4:00 Valerii Zapodovnikov :
> Otherwise since "==" has higher precedence, mode is never checked.
> ---
> libavfilter/signature_lookup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/signature_lookup.c
> b
Again. 240M matrix is different from BT.601! And 170M is the same
as BT.601. It is primaries that are the same in 240M and 170M, as
for jp2k_rsiz see page 10 of S422M-2006. Yes, IT IS THERE.
---
libavformat/mxf.c| 2 +-
libavformat/mxfdec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions
BTW, what about #7359?
___
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 "unsubscribe".
That did work, cool.
https://patchwork.ffmpeg.org/project/ffmpeg/patch/capucmebbw-rkt3mw5berkg3cqa+-akryfahclfc36mh2ybn...@mail.gmail.com/
BTW, will have to look into patchwork's patchwork (D:)) whether they fixed
.patch extensions. Apparently not. Also everything in "Re:" cannot contain
a patch.
This reverts commit d6d407d2d758b404af0ce6a8ff46bf164db020a1.
Hack not needed after a2b1dd0ce301450a47c972745a6b33c4c273aa5d.
Will fix #7480 and #8904.
This will include e.g. CODECS="hvc1.2.4.L123.B0" into m3u8.
Signed-off-by: Valerii Zapodovnikov
---
libavformat/dashenc.c | 6 +---
Just like for stss atom.
Suggested-By: Nick Ryan
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index c088c9f515..1be2783556 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4936,11 +4936,11 @@ static int
Nope, still is not seen. Try to send .txt in new thread. Thanks.
___
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 subjec
GEN=1 is nice, but why diff is no longer working on patchwork itself? See:
https://patchwork.ffmpeg.org/check/18368/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
Okay, I will send a patch to just raw.c to check it out, if it will not
work I will send against
http://lists.mplayerhq.hu/pipermail/nut-devel/2020-December/thread.html
Again, who can do FATE hashes for me? Please?
___
ffmpeg-devel mailing list
ffmpeg-de
Sure, please resend and change status on your old patch as superseeded on
patchwork. Sigh. As for maintainer, LGTM from me (interesting, is just
saying those 4 latters enough to get patchwork flag of it?). So if you can
push while not being the mainteiner, please do it, the coding acceptions
here a
You forgot to mention #6850. Also you patch was not seen by patchwork.
Please use "git send-email -v2 -1" to send v2 patch. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vis
v2 is done by "git send-email -v2 -1" not what you did here.
___
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 "u
Yes, RGB is signalled by Identity matrix if and only if XYZ is not
in transfer. XYZ primaires are just normal primaries that can be
used for normal RGB, no problem, so I do not check for them.
No need to test for sRGB primaries (that is AVCOL_PRI_BT709), as
ffplay does not know what that is (is not
пн, 24 мая 2021 г., 6:42 Valerii Zapodovnikov :
> ---
> libavfilter/vf_hqdn3d.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_hqdn3d.c b/libavfilter/vf_hqdn3d.c
> index 8d71ae316d..bd3eb2d01c 100644
> --- a/libavfilter/vf_hqdn3d.
Yeah, 0 to 3, but this is 4. We are counting from 0, not from 1. So that
would be some kind of fifth profile.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or emai
You may want to wait for at least some review and then of course, Andreas,
for example, sometimes sends 200 patch series.
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201203003628.778278-6-andreas.rheinha...@gmail.com/
___
ffmpeg-devel mailing list
Always true expression: we would have returned on line 265,
if whence were SEEK_END we would've already returned.
Because of short circuiting force will never be checked.
Was broken since 7a6fe01f99cb95797ba59134f44bb1a5e792.
That is 11 years! Also fixed other commit that did confuse
ORing / pa
It is not going to work. His email is marked as spam here in gmail for
android, so it looks like it is globally banned in google and because you
clever guys use gmail for patchwork, i.e. ffmpegpatchwo...@gmail.com but
you did not set to send all spam into main folder, like I always do, see
https://
You patch did not apply on patchwork and thus did not make fate tests.
Please use .txt extension on the patch (BTW, what a joke) or use git
send-email. It is also very funny that gmail for android recognises patch
as video. Wht?
___
ffmpeg-devel maili
The bigger problem are FATE hashes. I am not able to fill them here. As to
send patches against another repo, I can do that, no problem with
--subject-prefix="PATCH
nut".
Also, I do not see a problem with the spec, the spec says that it has
priority, not the code. I am not doing this patch for nut
HDR10+ test bitstream https://www.webmproject.org/vp9/levels/
BTW, who knows what is Profile 4 VP9 (i.e. VP9.4)?
https://stackoverflow.com/questions/61413665
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg
I don't really care about your nut container, FATE just complains that
something in raw.c is not in nut.c.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
f
Updated FATE hashes and added gamma 2.8. Also please note that FATE
samples are useless. I also fixed gamma 2.2 to System M.
Also this does not do YCbCr stuff, so no matrices are here.
Fixes more or less #6023, except for printing density stuff.
Co-authored-by: Paul B Mahol
---
libavcodec/dpxenc
This is used for dshow, though may be swapped endianness there.
Fixes #8454. fate-pixdesc-p010le and be will have to be updated.
---
libavcodec/raw.c | 3 +++
libavformat/nut.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index 079d5c5d10..7efc0156ca
"avctx->bits_per_raw_sample" always returns 0.
Tested with 24 Bit ALAC. The result is bit-perfect.
Fix #7287.
Co-authored-by: Davis
---
libavcodec/audiotoolboxdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
ind
Co-authored-by: Davis
---
libavcodec/audiotoolboxdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index cbd381ef12..c7e1760645 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -303,
This mostly reverts 785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b.
But I also added some clarifications so that nobody mixes primaries
with matrix again. SMPTE 240 and 170 primaires are the same, while
matrix coeff. are different, because 240 is derived from 170's new
primaries and white point while 170
This mostly reverts 785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b.
But I also added some clarifications so that nobody mixes primaries
with matrix again. SMPTE 240 and 170 primaires are the same, while
matrix coeff. are different, because 240 is derived from 170's new
primaries and white point while 170
---
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
This mostly reverts 785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b.
But I also added some clarifications so that nobody mixes primaries
with matrix again. SMPTE 240 and 170 primaires are the same, while
matrix coeff. are different, because 240 is derived from 170's new
primaries and white point while 170
Now with cosmetics and two new defines.
---
libavcodec/j2kenc.c | 16
libavcodec/jpeg2000.h | 4
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 82ad3284b5..4d5022db26 100644
--- a/libavcodec/j2kenc.c
+++ b/li
Always true expression: we would have returned on line 265.
Because of short curcuiting force will never be checked.
---
libavformat/avio.h| 1 -
libavformat/aviobuf.c | 3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/avio.h b/libavformat/avio.h
index d022820a6
---
libavfilter/vf_hqdn3d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_hqdn3d.c b/libavfilter/vf_hqdn3d.c
index 8d71ae316d..bd3eb2d01c 100644
--- a/libavfilter/vf_hqdn3d.c
+++ b/libavfilter/vf_hqdn3d.c
@@ -179,7 +179,7 @@ static void precalc_coefs(double dis
Introduced in c1f9734f977f59bc0034096afbe8e43e40d93a5d.
We are in if (movie->seek_point > 0) but seek_point is timestamp.
---
libavfilter/src_movie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
index 54f6738f9a..105d1b7b54 1
Otherwise since "==" has higher precedence, mode is never checked.
---
libavfilter/signature_lookup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index 272c717c77..85e879d224 100644
--- a/libavfilter/signature_
Otherwise since "==" has higher precedence, mode is never checked.
---
libavfilter/signature_lookup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index 272c717c77..85e879d224 100644
--- a/libavfilter/signature_
---
libavformat/hlsenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5db7a744b4..151ef6ec8f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -178,7 +178,7 @@ typedef struct VariantStream {
unsigned in
---
libavcodec/j2kenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
index 82ad3284b5..0b27f9adf5 100644
--- a/libavcodec/j2kenc.c
+++ b/libavcodec/j2kenc.c
@@ -1813,7 +1813,7 @@ static const AVOption options[] = {
{ "tile_heigh
---
libavcodec/dpxenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index fa8b7d5ddc..db5ed4e328 100644
--- a/libavcodec/dpxenc.c
+++ b/libavcodec/dpxenc.c
@@ -219,8 +219,8 @@ static int encode_frame(AVCodecContext *avctx, AVPac
---
libavformat/pmpdec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/pmpdec.c b/libavformat/pmpdec.c
index ce8e89515a..a327f7f6de 100644
--- a/libavformat/pmpdec.c
+++ b/libavformat/pmpdec.c
@@ -82,7 +82,6 @@ static int pmp_header(AVFormatContext *s)
audio_codec_id = AV
73 matches
Mail list logo
