Yes, RGB is signalled by Identity matrix if and only if XYZ is not
in transfer. XYZ primaries 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
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
Diederick C. Niehorster:
> On Sat, Jun 5, 2021 at 2:25 PM Andreas Rheinhardt
> wrote:
>> Diederick Niehorster:
>>> This implements avdevice_capabilities_create and avdevice_capabilities_free
>>> for the dshow device.> > +
>>> +if (ranges) {
>>> +if (query_type ==
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.
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!
Before, seeking in hls streams would always seek to the next keyframe after the
given timestamp.
With this fix, if AVSEEK_FLAG_BACKWARD is set, seeking will be to the first
keyframe of the
segment containing the given timestamp. This fixes #7485.
Signed-off-by: Gustav Grusell
---
When implementing the avdevice capabilities API, I have run into three
things regarding the AVOptionRange fields (libavutil/opt.h, lines
310-328)
1. an enum AVOptionType field "type" should be added. Else user cannot
know how to interpret the returned value(s), which are all doubles.
NB: for the
On Sat, Jun 5, 2021 at 2:25 PM Andreas Rheinhardt
wrote:
> Diederick Niehorster:
> > This implements avdevice_capabilities_create and avdevice_capabilities_free
> > for the dshow device.> > +
> > +if (ranges) {
> > +if (query_type == CAP_QUERY_FRAME_SIZE) {
> > +
On Sat, Jun 5, 2021 at 6:30 PM Valerii Zapodovnikov
wrote:
> BTW, what about #7359?
>
> #7359 is not fixed by my patch, but I thought I would look into that after
I get this patch done. I tried the old patch for #7359 but as far as I
could tell it didn't completely solve the problem.
Regarding
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
+++
On Sat, 5 Jun 2021, Marton Balint wrote:
On Sat, 5 Jun 2021, Valerii Zapodovnikov wrote:
-static const uint8_t mxf_jp2k_rsiz[] = {
0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x01,0x00
};
+static const uint8_t mxf_jp2k_rsiz[]
On Sat, 5 Jun 2021, Valerii Zapodovnikov wrote:
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
Add nb_output property to TaskItem for use in TensorFlow backend
and Native backend.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_common.h | 1 +
libavfilter/dnn/dnn_backend_openvino.c | 3 +++
2 files changed, 4 insertions(+)
diff --git
Extract TaskItem and InferenceItem from OpenVino backend and convert
ov_model to void in TaskItem.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_common.h | 19 +
libavfilter/dnn/dnn_backend_openvino.c | 58 ++
2 files changed, 40
пн, 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/libavfilter/signature_lookup.c
>
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
Un-hardcode the 200ms minimum latency between emitting subtitle events
so that those that wish to receive a subtitle event for every screen
change could do so.
The problem with delaying realtime output by any amount is that it is
unknown when the next byte pair that would trigger output will
This commit adds a common function for filling the TaskItems
in all three backends.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_common.c | 20
libavfilter/dnn/dnn_backend_common.h | 15 +++
libavfilter/dnn/dnn_backend_openvino.c | 23
These properties have values either 0 or 1, so using uint8_t
is a better option as compared to int.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_common.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_common.h
Convert output_name to char **output_names in TaskItem and use it as
a pointer to array of output names in the DNN backend.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_common.h | 2 +-
libavfilter/dnn/dnn_backend_openvino.c | 10 +-
2 files changed, 6
Un-hardcode the 200ms minimum latency between emitting subtitle events
so that those that wish to receive a subtitle event for every screen
change could do so.
The problem with delaying realtime output by any amount is that it is
unknown when the next byte pair that would trigger output will
Quoting James Almer (2021-06-05 16:46:01)
> On 6/5/2021 11:27 AM, Anton Khirnov wrote:
> > Memory ordering constraints other than the default (sequentially
> > consistent) can behave in very unintuitive and unexpected ways, and so
> > should be avoided unless there is a strong (typically
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".
Quoting Michael Niedermayer (2021-06-05 16:14:24)
> On Sat, Jun 05, 2021 at 03:44:49PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2021-06-01 09:33:13)
> > > Fixes: floating point division by 0
> > > Fixes: Ticket8213
> > >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> >
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.
AV_OPT_TYPE_VIDEO_RATE AVOption types are parsed as expressions, but in a
limited way. For example, name constants can only be parsed alone and not as
part of a longer expression.
This change allows usage like
ffmpeg -i IN -vf fps="if(eq(source_fps\,film)\,ntsc_film\,source_fps)" OUT
Attempt nr three to get patchwork to see this patch; sorry for the spam.
From ed84960978fe87772c304402e204c5e37742d235 Mon Sep 17 00:00:00 2001
From: Dennis Fleurbaaij
Date: Sat, 5 Jun 2021 13:44:21 +0200
Subject: [PATCH] libavcodec: r12b decoder added
R12B is a format used by BlackMagic
They are private fields, no reason to have them exposed in a public header.
Signed-off-by: James Almer
---
libavformat/avformat.h | 11
libavformat/concatdec.c | 4 +-
libavformat/fifo.c | 2 +-
libavformat/hdsenc.c | 6 +--
On 6/5/2021 11:27 AM, Anton Khirnov wrote:
Memory ordering constraints other than the default (sequentially
consistent) can behave in very unintuitive and unexpected ways, and so
should be avoided unless there is a strong (typically performance)
reason for using them. This holds especially for
They are private fields, no reason to have them exposed in a public header.
Signed-off-by: James Almer
---
libavformat/avformat.h | 11
libavformat/concatdec.c | 4 +-
libavformat/fifo.c | 2 +-
libavformat/hdsenc.c | 6 +--
It should not be accessed from outside of libavformat.
Signed-off-by: James Almer
---
Untested.
I'm removing the cur_dts usage from read_packet() because i don't want to add
another avpriv function just to read it, and cdio_paranoia_read() should return
NULL when there's no more data, so it's
libavdevice needs it.
Signed-off-by: James Almer
---
libavformat/aadec.c | 4 ++--
libavformat/brstm.c | 2 +-
libavformat/idcin.c | 2 +-
libavformat/internal.h| 2 +-
libavformat/matroskadec.c | 2 +-
libavformat/mca.c | 2 +-
libavformat/mp3dec.c | 2 +-
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 +-
1 file
On Sat, Jun 5, 2021 at 4:36 PM Anton Khirnov wrote:
> Sorry to rain on your parade, but I don't think we should go ahead with
> this before deciding what is to be done with libavdevice. The last
> discussion about it died without being resolved, but the issues are
> still present.
I understand.
Fixes: Infinite loop
Fixes:
34751/clusterfuzz-testcase-minimized-ffmpeg_dem_RPL_fuzzer-5439330800762880
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/rpl.c | 2 +-
1 file changed, 1
Quoting Diederick Niehorster (2021-06-04 00:45:48)
> ** Resending as it seems they didn't all make it..**
>
> Undeprecating the avdevice capabilities API and implementing it for the
> dshow device. Much needed. Together with the other patches i sent, a
> dshow device can now be properly used
Quoting Thilo Borgmann (2021-06-05 14:29:05)
> Hi,
>
> add an option to override auto-detection of cpu count. Defaults to
> auto-detection, of course.
>
> -Thilo
>
> From 38612f3e1339354dbaa6be4f36072320ff71c707 Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann
> Date: Sat, 5 Jun 2021 14:26:23
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an
unsigned type to negate this value to itself
Fixes:
34651/clusterfuzz-testcase-minimized-ffmpeg_dem_JACOSUB_fuzzer-5157941012463616
Found-by: continuous fuzzing process
Memory ordering constraints other than the default (sequentially
consistent) can behave in very unintuitive and unexpected ways, and so
should be avoided unless there is a strong (typically performance)
reason for using them. This holds especially for memory_order_relaxed,
which imposes no
On Mon, May 24, 2021 at 06:42:32AM +0300, Valerii Zapodovnikov wrote:
> ---
> libavfilter/vf_hqdn3d.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Gyan Doshi
> Sent: Wednesday, May 26, 2021 6:06 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH]avfilter: add Intel IPP library based x86
> optimized video scaling filter
>
>
>
> On 2021-05-25 20:17,
On Sat, Jun 05, 2021 at 03:44:49PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-06-01 09:33:13)
> > Fixes: floating point division by 0
> > Fixes: Ticket8213
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/lpc.h | 3 ++-
> > 1 file changed, 2 insertions(+),
On Fri, Jun 04, 2021 at 02:43:43PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libswscale/swscale_unscaled.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint:
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
Quoting Michael Niedermayer (2021-06-01 09:33:13)
> Fixes: floating point division by 0
> Fixes: Ticket8213
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/lpc.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/lpc.h b/libavcodec/lpc.h
> index
On Sat, Jun 5, 2021 at 2:41 PM Andreas Rheinhardt
wrote:
>
> Have you looked at
> 2ff40b98ecbd9befadddc8fe665a391f99bfca32/0a071f7124beaf0929f772a8618ac1b6c17b0222?
I have, but didn't know what to do with it. Are you suggesting
reverting part of those two commits? The bit of documentation of the
Diederick C. Niehorster:
> On Sat, Jun 5, 2021 at 8:51 AM Andreas Rheinhardt
> wrote:
>>
>> Diederick Niehorster:
>>> +
>>> +// since there is no equivalent of avformat_alloc_output_context2 for
>>> an input context,
>>> +// so we get this dirty code that users shouldn't have to
Hi,
add an option to override auto-detection of cpu count. Defaults to
auto-detection, of course.
-Thilo
From 38612f3e1339354dbaa6be4f36072320ff71c707 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Sat, 5 Jun 2021 14:26:23 +0200
Subject: [PATCH] fftools/cmdutils.c: Add cmd line option to
Diederick Niehorster:
> This implements avdevice_capabilities_create and avdevice_capabilities_free
> for the dshow device.
>
> Signed-off-by: Diederick Niehorster
> ---
> libavdevice/dshow.c | 498
> 1 file changed, 462 insertions(+), 36
Den lör 5 juni 2021 10:14Valerii Zapodovnikov
skrev:
> 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.
>
Thanks, I will take care of this.
___
ffmpeg-devel mailing
Alright thanks for the pointers. Attempt #2, hopefully this one will be
picked up.
Kind regards,
Dennis Fleurbaaij
+31 (0) 6 54 21 5365
On Fri, Jun 4, 2021 at 1:17 AM Valerii Zapodovnikov
wrote:
> You patch did not apply on patchwork and thus did not make fate tests.
> Please use .txt
Ping.
Thanks,
Shiwang.Xie
On Sat, 29 May 2021, Shiwang.Xie wrote:
Hi, any updates for this?
Thanks,
Shiwang.Xie
On Wed, 19 May 2021, Shiwang.Xie wrote:
Hi, is there objection?
Thanks,
Shiwang.Xie
On Sat, 15 May 2021, Shiwang.Xie wrote:
if input start time is not 0 -t is inaccurate
On Sat, Jun 5, 2021 at 8:51 AM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > +
> > +// since there is no equivalent of avformat_alloc_output_context2 for
> > an input context,
> > +// so we get this dirty code that users shouldn't have to write
> > +fmt_ctx =
---
libavcodec/libx265.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 90658d3d9e..35547a5a69 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -51,6 +51,9 @@ typedef struct libx265Context {
MISB ST 0604 and ST 2101 require user data unregistered SEI messages
(precision timestamps and sensor identifiers) to be included. That
currently isn't supported for libx265. This patch adds support
for user data unregistered SEI messages in accordance with
ISO/IEC 23008-2:2020 Section D.2.7
On Fri, 4 Jun 2021, Zhao Zhili wrote:
From: Zhao Zhili
---
v2: update doc
LGTM for the set.
Thanks,
Marton
doc/protocols.texi | 5 +
libavformat/libsrt.c | 5 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index
On Thu, 3 Jun 2021, Sergey Ilinykh wrote:
Default streamid is some numeric value and not used by SRT code. Instead
SRT has its own string streamid. Current code has the same option name for
both and this causes a conflict when ffmpeg is started from a terminal.
The attached patch fixes it
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,
On Sat, Jun 05, 2021 at 11:29:24AM +0300, Valerii Zapodovnikov wrote:
> 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?
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
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
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,
On Tue, May 25, 2021 at 2:52 PM Gustav Grusell
wrote:
> Before, seeking in hls streams would always seek to the next keyframe
> after the given timestamp.
> With this fix, if AVSEEK_FLAG_BACKWARD is set, seeking will be to the
> first keyframe of the
> segment containing the given timestamp.
Diederick Niehorster:
> Signed-off-by: Diederick Niehorster
> ---
> configure | 2 +
> doc/examples/.gitignore| 1 +
> doc/examples/Makefile | 47
> doc/examples/Makefile.example | 1 +
>
66 matches
Mail list logo
