Attached.
From dbee6548020b42f4559042fd6a50fa4fa35121ff Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Thu, 7 Dec 2023 08:45:23 +0100
Subject: [PATCH] remove myself from FFmpeg consulting page
---
src/consulting | 12
1 file changed, 12 deletions(-)
diff --git a/src/consulting
On Do, 2023-12-07 at 06:44 +, hung kuishing wrote:
> Signed-off-by: clarkh
> ---
> doc/examples/qsv_transcode.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
> index 48128b200c..972126800b 100644
Attached.
From b249499fccb49705ade14362875ebf4d22628fa4 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Thu, 7 Dec 2023 08:27:14 +0100
Subject: [PATCH] MAINTAINERS: remove myself from FFmpeg
Signed-off-by: Paul B Mahol
---
MAINTAINERS | 55
Quoting James Almer (2023-12-06 21:49:45)
> On 12/2/2023 12:53 PM, Anton Khirnov wrote:
> > Its author not only failed to add any tests, as is required by the
> > development rules, but continues to actively refuse to do so.
> >
> > Untested decoders are worse than useless, so remove it.
> > ---
Signed-off-by: clarkh
---
doc/examples/qsv_transcode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
index 48128b200c..972126800b 100644
--- a/doc/examples/qsv_transcode.c
+++ b/doc/examples/qsv_transcode.c
Evgeniy Pantyuhin via ffmpeg-devel
于2023年12月7日周四 04:32写道：
>
> Signed-off-by: Evgeniy
> ---
> libavformat/dashdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 29d4680..36e4719 100644
> --- a/libavformat/dashdec.c
On Wed, Dec 6, 2023 at 3:23 AM Marton Balint wrote:
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 2cfb3fcf97..f9b18a2c35 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1675,6 +1675,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
>
>
On Di, 2023-12-05 at 08:18 +, Xiang, Haihao wrote:
> On Di, 2023-11-28 at 12:42 +0800, Xiang, Haihao wrote:
> > From: Artem Galin
> >
> > User may choose the hardware via option vendor_id when multiple
> > hardwares are available.
> >
> > Signed-off-by: Artem Galin
> > Signed-off-by:
On Wed, Dec 06, 2023 at 11:20:06AM +0100, Paul B Mahol wrote:
> Attached.
> fate/filter-video.mak|9 +
> ref/fate/filter-pixelize-avg |1 +
> ref/fate/filter-pixelize-max |1 +
> ref/fate/filter-pixelize-min |1 +
> 4 files changed, 12 insertions(+)
>
On Wed, Dec 06, 2023 at 12:21:02PM +0100, Paul B Mahol wrote:
> Attached.
> fate/filter-video.mak |3 +++
> ref/fate/filter-median |1 +
> 2 files changed, 4 insertions(+)
> 13f347a427b22bbb5ea4959ad092435d6f10c8d9
> 0001-tests-fate-add-median-filter-test.patch
> From
Hi,
On Wed, Dec 6, 2023 at 3:23 AM Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> doc/APIchanges | 3 +++
> doc/codecs.texi| 14 ++
> libavcodec/avcodec.h | 4
> libavcodec/decode.c| 6 ++
> libavcodec/options_table.h
On date Wednesday 2023-12-06 09:22:20 +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> doc/APIchanges | 3 +++
> doc/codecs.texi| 14 ++
> libavcodec/avcodec.h | 4
> libavcodec/decode.c| 6 ++
>
On date Wednesday 2023-12-06 09:22:19 +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> doc/APIchanges | 3 +++
> libavutil/imgutils.c | 4 ++--
> libavutil/imgutils.h | 30 ++
> libavutil/version.h | 2 +-
> 4 files changed, 36
On date Wednesday 2023-12-06 09:22:18 +0100, Marton Balint wrote:
> In preparation for making it public.
>
> Signed-off-by: Marton Balint
> ---
> libavutil/imgutils.c | 103 +++
> 1 file changed, 64 insertions(+), 39 deletions(-)
LGTM, thanks.
On 12/5/2023 11:45 AM, Nuo Mi wrote:
---
configure | 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/vvc/Makefile | 4 +
libavcodec/vvc/vvcdec.c | 62
libavcodec/vvc/vvcdec.h | 204
On date Wednesday 2023-12-06 09:22:17 +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> libavutil/imgutils.c| 33 +++--
> tests/ref/fate/imgutils | 24
> 2 files changed, 35 insertions(+), 22 deletions(-)
LGTM, thanks.
On date Wednesday 2023-12-06 09:22:16 +0100, Marton Balint wrote:
> - Fixes YA formats, because previous code always assumed alpha as the 4th
> component.
> - Fixes PAL format (as long as 0 is black, as in a systematic palette),
> because
> previous code assumed it as limited Y.
> - Fixes XYZ
On date Wednesday 2023-12-06 09:22:15 +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> libavutil/tests/imgutils.c | 61 +--
> tests/ref/fate/imgutils| 217 +
> 2 files changed, 269 insertions(+), 9 deletions(-)
LGTM, thanks.
On date Wednesday 2023-12-06 09:22:14 +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> libavutil/tests/imgutils.c | 68 ++
> 1 file changed, 39 insertions(+), 29 deletions(-)
LGTM, thanks.
___
On Wed, Dec 06, 2023 at 02:34:58AM +0100, Thilo Borgmann via ffmpeg-devel wrote:
> Still images fixed, includes FATE tests, VP8 decoder decoupled so there are
> no more data races, fixed more asserts, fixed ffprobe regression.
>
> Patch 5/7 is still there for making changes in lavc/webp
Quoting Cosmin Stejerean via ffmpeg-devel (2023-12-06 21:29:11)
> There is still a penalty as you could do asetnsamples without multi-threading
> and get even higher performance,
> but given the general benefits of multi-threading and the fact that it's
> possible to increase the performance of
I ain't reading all of that
Happy for you
Or sorry that happened
On Wed, Dec 6, 2023 at 3:47 PM Nicolas George wrote:
> Vittorio Giovara (12023-12-05):
> > Your attitude for "omgfeatures" is also pretty toxic, there are heaps of
> > literature about feature creep and how important it is to
On Wed, Dec 6, 2023 at 3:14 PM Nicolas George wrote:
> Lie.
>
A summary of your proposal or a link to your suggestion would be
appreciated.
Without reference we're all shouting in the void.
> I guess now that your side holds most of the power the mask is off.
>
> This mail you just sent
On 12/2/2023 12:53 PM, Anton Khirnov wrote:
Its author not only failed to add any tests, as is required by the
development rules, but continues to actively refuse to do so.
Untested decoders are worse than useless, so remove it.
---
Changelog | 2 +-
libavcodec/Makefile|
Vittorio Giovara (12023-12-05):
> Your attitude for "omgfeatures" is also pretty toxic, there are heaps of
> literature about feature creep and how important it is to remove dead code.
You should read said literature before quoting it, you would learn the
difference between more features and
Signed-off-by: Evgeniy
---
libavformat/dashdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 29d4680..36e4719 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -768,7 +768,7 @@ static int
Also, the numbers I'm seeing on my 16-core Ryzen 9 5950X are quite
different:
* 5.0, your command:speed=3.25e+03x
* 5.0, filter_complex: speed=5.29e+03x
* 5.1, your command:speed=3.2e+03x
* 5.1, filter_complex: speed=5.2e+03x
* 6.0, your command:speed=2.44e+03x
* 6.0, filter_complex:
> On Dec 6, 2023, at 11:36 AM, Anton Khirnov wrote:
>
>> In some cases the performance penalty because of threading is quite
>> significant:
>>
>> Example command line:
>>
>> ffmpeg -f lavfi -i sine -af volume=6dB -f null none
>>
>> After latest threading changes: speed=810x
>> Before
Today, effectively immediately, I officially Ieft the FFmpeg project.
For new
decoders/encoders/muxers/demuxers/filters/fixes/speedups/tests/cleanups
etc. look at Librempeg project on github, source code will appear soon
there.
See you there.
___
On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote:
> Hi,
> this should hopefully be the last version of this set. If nobody has new
> comments, I will push it in a few days.
I have a case that becomes really non deterministic
for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i
Stefano Sabatini (12023-11-30):
> Generalize drawtext utilities to make them usable in other filters.
> This will be needed to introduce the QR code source and filter without
> duplicating functionality.
> ---
> libavfilter/Makefile | 2 +-
> libavfilter/textutils.c | 379
Anton Khirnov (12023-12-06):
> Would guess this is caused by overhead from tons of tiny frames. So
> 1) generate larger frames
> 2) use -filter_complex with no inputs instead of -f lavfi to eliminate
>all overhead from demuxing, decoding, and demux-decode/decode-filter
>inter-thread
Anton Khirnov (12023-12-06):
> As usual when someone disagrees with him, Nicolas converged to being
> utterly unreasonable and deaf to all arguments. I see no point in
Ad-hominem attack.
> discussing this with him any further and intend to push the set
> tomorrow, unless somebody else has
On Wed, Dec 6, 2023 at 5:30 AM Anton Khirnov wrote:
> Hi,
> this should hopefully be the last version of this set. If nobody has new
> comments, I will push it in a few days.
>
LGTM
--
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Thu, Nov 23, 2023 at 10:14:23AM +0100, Anton Khirnov wrote:
> ---
> tools/general_assembly.pl | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl
> index 4c3208ccac..3bf65f3405 100755
> ---
Quoting Marton Balint (2023-12-06 20:29:01)
>
>
> On Wed, 6 Dec 2023, Anton Khirnov wrote:
>
> > Hi,
> > this should hopefully be the last version of this set. If nobody has new
> > comments, I will push it in a few days.
>
> In some cases the performance penalty because of threading is quite
On Wed, 6 Dec 2023, Anton Khirnov wrote:
Hi,
this should hopefully be the last version of this set. If nobody has new
comments, I will push it in a few days.
In some cases the performance penalty because of threading is quite
significant:
Example command line:
ffmpeg -f lavfi -i sine
On Wed, Dec 06, 2023 at 09:25:43AM +0100, Anton Khirnov wrote:
> Quoting Niklas Haas (2023-12-05 12:01:48)
> > On Tue, 05 Dec 2023 11:07:33 +0100 Anton Khirnov wrote:
> > > Hi all,
> > > Both elections have now concluded.
> > >
> > > We have 36 votes for the CC election (70% turnout) and 38
Hi,
On Mon, Dec 4, 2023 at 7:59 AM Nil Fons Miret via ffmpeg-devel
wrote:
>
> The libvmaf filter was doing substring checks in place of string
> equality comparisons. This led to a bug when the user specified the
> pooling method "harmonic_mean", since "mean" was checked first and the
>
Am 06.12.23 um 13:03 schrieb xufuji456 via ffmpeg-devel:
Building with iOS platform, the compiler has a warning: "'devicesWithMediaType:' is
deprecated: first deprecated in iOS 10.0 - Use AVCaptureDeviceDiscoverySession
instead"
Signed-off-by: xufuji456 <839789...@qq.com>
---
Hi all,
As usual when someone disagrees with him, Nicolas converged to being
utterly unreasonable and deaf to all arguments. I see no point in
discussing this with him any further and intend to push the set
tomorrow, unless somebody else has substantial objections.
I've considered asking for a
> On Dec 6, 2023, at 02:44, Philip Langdale via ffmpeg-devel
> wrote:
>
> On Sat, 2 Dec 2023 23:02:36 +0100
> Thomas Mundt wrote:
>
>>
>> LGTM, thanks.
>>
>
> I am going to squash the three commits and push. There's no real need
> to put each filter in a separate diff when the logical
Quoting Niklas Haas (2023-11-09 13:19:38)
> From: Niklas Haas
>
> Propagates input metadata to the input filter graph.
> ---
> fftools/ffmpeg_filter.c | 24 +---
> 1 file changed, 21 insertions(+), 3 deletions(-)
Looks ok
--
Anton Khirnov
Quoting Niklas Haas (2023-11-09 13:19:37)
> @@ -328,6 +341,30 @@ static const AVOption buffer_options[] = {
> { "pixel_aspect", "sample aspect ratio",OFFSET(pixel_aspect),
> AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
> { "time_base", NULL,
Quoting Niklas Haas (2023-11-09 13:19:35)
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 12383a28d3..ce3f90a674 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,14 @@ The last version increases of all libraries were on
> 2023-02-09
>
> API changes, most recent first:
>
James Almer (12023-12-06):
> I honestly can't believe you're arguing this.
Yet I do, so I suggest you think a little harder to understand why I do.
> And being condescending will not help your case.
Can you tell that to Anton too please?
> If i request -bitexact, i want bitexact output,
On Wed, 6 Dec 2023, Timo Rothenpieler wrote:
On 06/12/2023 14:25, Martin Storsjö wrote:
On Sun, 3 Dec 2023, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of
On 06/12/2023 14:25, Martin Storsjö wrote:
On Sun, 3 Dec 2023, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the
On Sun, 3 Dec 2023, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself
On 12/6/2023 9:55 AM, Nicolas George wrote:
Anton Khirnov (12023-12-04):
Which of these are you saying is correct?
I do not know? Do you think I am able to reverse MD5 mentally? I am
flattered, but I am sorry to confess I am not.
Why do you not look at the resulting videos to judge for
Paul B Mahol (12023-12-01):
> From 2ea2a0df61cbd5519a1c1e88be27a3f8eb883aac Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Fri, 1 Dec 2023 16:59:07 +0100
> Subject: [PATCH] avfilter/avfilter: fix OOM case for default activate
>
> Fixes OOM when caller keeps adding frames into filtergraph
> On Dec 6, 2023, at 20:26, Timo Rothenpieler wrote:
>
> On 06/12/2023 07:51, Xiang, Haihao wrote:
>> On Di, 2023-12-05 at 12:47 +0100, Timo Rothenpieler wrote:
>>> On 05.12.2023 09:15, Xiang, Haihao wrote:
From: Haihao Xiang
2M is suitable for more cases, e.g. 4K video.
Anton Khirnov (12023-12-06):
> After weeks of discussion, you have NOT suggested any workable
> alternative.
Indeed. And the reason for that is that all the time I have available on
this is spent debunking your libel about the current logic.
> Producing unpredictable output generally means
On 06/12/2023 13:31, James Almer wrote:
On 12/3/2023 5:10 PM, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler
Anton Khirnov (12023-12-04):
> Which of these are you saying is correct?
I do not know? Do you think I am able to reverse MD5 mentally? I am
flattered, but I am sorry to confess I am not.
Why do you not look at the resulting videos to judge for yourself? But
to do that, you will need to remember
On 12/6/2023 9:50 AM, Ronald S. Bultje wrote:
Hi,
On Sun, Dec 3, 2023 at 3:10 PM Timo Rothenpieler
wrote:
So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx
Ehm... What? That seems like the core bug then?
--disable-avx will
Hi,
On Sun, Dec 3, 2023 at 3:10 PM Timo Rothenpieler
wrote:
> So if the compiler does a copy
> in decode_cpe() with avx instructions, but ffmpeg is built with
> --disable-avx
>
Ehm... What? That seems like the core bug then?
Ronald
___
ffmpeg-devel
On 12/3/2023 5:10 PM, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
Quoting Nicolas George (2023-12-06 13:10:41)
> I have offered Anton my help.
After weeks of discussion, you have NOT suggested any workable
alternative. The single suggestion I did see from you
* was already implemented
* did not address the issues at all
> But first he needs to acknowledge
On 03/12/2023 21:10, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself
On 06/12/2023 07:51, Xiang, Haihao wrote:
On Di, 2023-12-05 at 12:47 +0100, Timo Rothenpieler wrote:
On 05.12.2023 09:15, Xiang, Haihao wrote:
From: Haihao Xiang
2M is suitable for more cases, e.g. 4K video.
Signed-off-by: Haihao Xiang
---
libavcodec/qsvenc_av1.c | 2 +-
Zhao Zhili (12023-12-06):
> For such large patch set, it’s almost impossible to not break any corner case.
Yes, that is what review is for.
> Considering the improvements the patch set brings into fftools, those corner
> cases can be fixed after merge.
That means never. No.
> And any body can
> On Dec 6, 2023, at 18:55, Nicolas George wrote:
>
> Anton Khirnov (12023-12-06):
>> this should hopefully be the last version of this set. If nobody has new
>> comments, I will push it in a few days.
>
> Absolutely not: you cannot push until consensus is reached, and
> consensus is not
Building with iOS platform, the compiler has a warning:
"'devicesWithMediaType:' is deprecated: first deprecated in iOS 10.0 - Use
AVCaptureDeviceDiscoverySession instead"
Signed-off-by: xufuji456 <839789...@qq.com>
---
libavdevice/avfoundation.m | 23 ++-
1 file changed,
Quoting Paul B Mahol (2023-12-06 12:22:48)
> On Wed, Dec 6, 2023 at 11:32 AM Anton Khirnov wrote:
>
> > Change the main loop and every component (demuxers, decoders, filters,
> > encoders, muxers) to use the previously added transcode scheduler. Every
> > instance of every such component was
Attached.
From 2c54553b83f2b67f781c67cb72deb4a5f267a8f1 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Wed, 6 Dec 2023 12:17:54 +0100
Subject: [PATCH] tests/fate: add median filter test
Signed-off-by: Paul B Mahol
---
tests/fate/filter-video.mak | 3 +++
tests/ref/fate/filter-median | 1 +
Anton Khirnov (12023-12-06):
> this should hopefully be the last version of this set. If nobody has new
> comments, I will push it in a few days.
Absolutely not: you cannot push until consensus is reached, and
consensus is not reached since you are still breaking the sparseness of
sub2video
---
src/index | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/index b/src/index
index 0d68db5..22f6844 100644
--- a/src/index
+++ b/src/index
@@ -35,6 +35,20 @@
News
+ December xxth, 2023, multi-threaded
ffmpeg CLI tool
+
+ Thanks to a major refactoring of
On Sat, 2 Dec 2023 23:02:36 +0100
Thomas Mundt wrote:
>
> LGTM, thanks.
>
I am going to squash the three commits and push. There's no real need
to put each filter in a separate diff when the logical change is
identical in all three.
Thanks,
--phil
Change the main loop and every component (demuxers, decoders, filters,
encoders, muxers) to use the previously added transcode scheduler. Every
instance of every such component was already running in a separate
thread, but now they can actually run in parallel.
Changes the results of
See the comment block at the top of fftools/ffmpeg_sched.h for more
details on what this scheduler is for.
This commit adds the scheduling code itself, along with minimal
integration with the rest of the program:
* allocating and freeing the scheduler
* passing it throughout the call stack in
As for the analogous decoding change, this is only a preparatory step to
a fully threaded architecture and does not yet make encoding truly
parallel. The main thread will currently submit a frame and wait until
it has been fully processed by the encoder before moving on. That will
change in future
* the code is made shorter and simpler
* avoids constantly allocating and freeing AVPackets, thanks to
ThreadQueue integration with ObjPool
* is consistent with decoding/filtering/muxing
* reduces the diff in the future switch to thread-aware scheduling
This makes ifile_get_packet() always
This will be the appropriate place for it after the rest of transcoding
is switched to a threaded architecture.
---
fftools/ffmpeg_mux.c | 112 ++-
1 file changed, 67 insertions(+), 45 deletions(-)
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
---
fftools/ffmpeg_filter.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 1800296aa4..1df1212442 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -2526,17 +2526,17 @@ static int
To be used for data that never needs to be visible outside of the muxer
thread. Start by moving the muxed AVPacket in there.
---
fftools/ffmpeg_mux.c | 44 +++-
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/fftools/ffmpeg_mux.c
As previously for decoding, this is merely "scaffolding" for moving to a
fully threaded architecture and does not yet make filtering truly
parallel - the main thread will currently wait for the filtering thread
to finish its work before continuing. That will change in future commits
after encoders
Hi,
this should hopefully be the last version of this set. If nobody has new
comments, I will push it in a few days.
Cheers,
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
Avoid making decisions based on current graph input state, which makes
the output dependent on the order in which the frames from different
inputs are interleaved.
Makes the output of fate-filter-overlay-dvdsub-2397 more correct - the
subtitle appears two frames later, which is closer to its PTS
Otherwise they'd be silently ignored if received by the filtering thread
before the filtergraph can be initialized, which would make the output
dependent on the order in which frames from different inputs arrive.
---
fftools/ffmpeg_filter.c | 43 -
1 file
Attached.
From c17589e4fc6b38013d6b0b14feeac50e00bb3305 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Wed, 6 Dec 2023 11:18:35 +0100
Subject: [PATCH] tests/fate: add pixelize filter tests
Signed-off-by: Paul B Mahol
---
tests/fate/filter-video.mak| 9 +
Quoting Niklas Haas (2023-12-05 12:01:48)
> On Tue, 05 Dec 2023 11:07:33 +0100 Anton Khirnov wrote:
> > Hi all,
> > Both elections have now concluded.
> >
> > We have 36 votes for the CC election (70% turnout) and 38 votes for TC
> > (75% turnout); raw votes in CSV format are attached.
> >
> >
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 +++
doc/codecs.texi| 14 ++
libavcodec/avcodec.h | 4
libavcodec/decode.c| 6 ++
libavcodec/options_table.h | 1 +
libavcodec/version.h | 2 +-
6 files changed, 29
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 +++
libavutil/imgutils.c | 4 ++--
libavutil/imgutils.h | 30 ++
libavutil/version.h | 2 +-
4 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index
In preparation for making it public.
Signed-off-by: Marton Balint
---
libavutil/imgutils.c | 103 +++
1 file changed, 64 insertions(+), 39 deletions(-)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index 67119b0870..278e30ee0f 100644
---
Signed-off-by: Marton Balint
---
libavutil/imgutils.c| 33 +++--
tests/ref/fate/imgutils | 24
2 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index 5e401139c8..67119b0870 100644
- Fixes YA formats, because previous code always assumed alpha as the 4th
component.
- Fixes PAL format (as long as 0 is black, as in a systematic palette), because
previous code assumed it as limited Y.
- Fixes XYZ format because it does not need nonzero chroma components
- Fixes xv30be as
Signed-off-by: Marton Balint
---
libavutil/tests/imgutils.c | 61 +--
tests/ref/fate/imgutils| 217 +
2 files changed, 269 insertions(+), 9 deletions(-)
diff --git a/libavutil/tests/imgutils.c b/libavutil/tests/imgutils.c
index
Signed-off-by: Marton Balint
---
libavutil/tests/imgutils.c | 68 ++
1 file changed, 39 insertions(+), 29 deletions(-)
diff --git a/libavutil/tests/imgutils.c b/libavutil/tests/imgutils.c
index 748bd6c9d2..1e2bb3fa01 100644
--- a/libavutil/tests/imgutils.c
89 matches
Mail list logo
