On Sun, 29 Oct 2023 07:22:46 +0100 (CET)
Lynne wrote:
> Due to making the decode frames context use the coded size, the
> filter started to display those artifacts as it reused the input
> frame's size.
>
> Change it to instead output the real image size for images, not the
> input.
>
> Patch
Nov 5, 2023, 00:02 by mar...@martin.st:
> Hi,
>
> Just following up on this - I'm sorry I haven't been able to look at the
> proposed patchset myself quite in detail yet.
>
> My prime concern is about the requests to have this merged into the upcoming
> 6.1 release; that's way too soon IMO.
>
>
Hi,
Just following up on this - I'm sorry I haven't been able to look at the
proposed patchset myself quite in detail yet.
My prime concern is about the requests to have this merged into the
upcoming 6.1 release; that's way too soon IMO.
These patches do change aspects of how these things
Yo,
On Fri, 3 Nov 2023, at 18:33, Michael Niedermayer wrote:
>> It will take a bit of time, but I'll do it.
Aman
Andreas
Andriy
Anton
Lynne
Baptiste
Jun Zhao
Lauri Kasanen
Carl
Marton
Dale
Derek
Diego
Gyan
foo86
Gautam Ramakrishnan
Nicolas
hwrenx
James
Jeeb
Jerome Borsboom
Josh
Kaustubh Raste
On date Wednesday 2023-09-06 13:13:25 +0200, Anton Khirnov wrote:
> Quoting Stefano Sabatini (2023-09-06 00:59:44)
[...]
> A simple rename is a trivial API change. Almost everything else is not.
>
> > and therefore should not be committed.
>
> Yes, the baseline for every API change is that it is
On date Wednesday 2023-09-06 11:04:49 +0530, Gyan Doshi wrote:
[...]
Sorry for the slow reply.
> > -Argument is a list of @var{key}=@var{value} couples separated by
> > -":". In @var{filter} and @var{psy-rd} options that use ":" as a separator
> > -themselves, use "," instead. They accept it as
On Tue, Oct 31, 2023 at 03:54:49PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> When using vf_scale to force a specific output color space, also tag
> this on the AVFrame. (Mirroring existing logic for output range)
> ---
> libavfilter/vf_scale.c | 3 +++
> 1 file changed, 3 insertions(+)
On Tue, Oct 31, 2023 at 03:54:50PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> PGMYUV seems to be always limited range. This was a format originally
> invented by FFmpeg at a time when YUVJ distinguished limited from full
> range YUV, and this codec never appeared to output YUVJ in any
>
Nov 4, 2023, 17:22 by derek.buitenh...@gmail.com:
> Hi,
>
> I'm going to opine a bit here, and also comment on the mov/MP4 patch[0] that
> accompanies
> this set.
>
> This is for both historical purposes, and to distill IRC logs into something
> more
> digestible for others on the list to gain
On Sat, Nov 4, 2023 at 8:07 PM Nicolas George wrote:
> Paul B Mahol (12023-11-04):
> > From 31a6a78ebc3a3f8785ec7c8e5ffd4257c7eadec3 Mon Sep 17 00:00:00 2001
> > From: Paul B Mahol
> > Date: Fri, 27 Oct 2023 14:26:50 +0200
> > Subject: [PATCH] avfilter/buffersrc: switch to activate
> >
> >
On Sat, Nov 04, 2023 at 08:56:19AM +0100, Anton Khirnov wrote:
> 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
Paul B Mahol (12023-11-04):
> From 31a6a78ebc3a3f8785ec7c8e5ffd4257c7eadec3 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Fri, 27 Oct 2023 14:26:50 +0200
> Subject: [PATCH] avfilter/buffersrc: switch to activate
>
> Fixes error when caller keeps adding frames into filtergraph
> that
Paul B Mahol (12023-11-03):
> Also I think that forward and/or backward EOF direction status checking is
> not correctly handled at all for any filters not using .activate(), and I'm
> not aware that it was ever working correctly in all cases.
Could you not start with that?!?
If you are right,
Attached.
From 31a6a78ebc3a3f8785ec7c8e5ffd4257c7eadec3 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Fri, 27 Oct 2023 14:26:50 +0200
Subject: [PATCH] avfilter/buffersrc: switch to activate
Fixes error when caller keeps adding frames into filtergraph
that reached EOF by other means, for
On Sat, Nov 04, 2023 at 08:56:27AM +0100, Anton Khirnov wrote:
> 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:
> *
On Sat, Nov 04, 2023 at 08:56:29AM +0100, Anton Khirnov wrote:
> ---
> fftools/ffmpeg.c | 22 ---
> fftools/ffmpeg.h | 13 +-
> fftools/ffmpeg_dec.c | 315 ++-
> 3 files changed, 70 insertions(+), 280 deletions(-)
This or the previous commit
A reminder to everyone who has not voted yet that the vote will close
tomorrow around midnight UTC. Please vote as soon as possible.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Quoting Michael Niedermayer (2023-11-02 20:53:46)
> On Sun, Oct 29, 2023 at 10:33:12AM +0100, Anton Khirnov wrote:
> > Hi all,
> > updating the answers according to received comments:
> >
> > vote question (unchanged):
> > How do we update the list of active members of the general assembly?
>
On Sat, Nov 04, 2023 at 04:22:11PM +, Derek Buitenhuis wrote:
[...]
> I am almost certain I missed even more nuance, and hopefully Martin or Anton
> can chime in, or I remember more.
>
> But also, given all of this, I think we need to deeply consider how we
> approach this, so we don't end
On 11/4/2023 4:22 PM, Derek Buitenhuis wrote:
> the sample duration of the last packet in the stts box. Pre-roll is
> store in the sgpb
Bah. Please try and ignore my various typos of 'sgpd'.
- Derek
___
ffmpeg-devel mailing list
Hi,
I'm going to opine a bit here, and also comment on the mov/MP4 patch[0] that
accompanies
this set.
This is for both historical purposes, and to distill IRC logs into something
more
digestible for others on the list to gain context on the issue, so apologies for
re-treading ground.
On
Anton Khirnov (12023-11-04):
> It only seems to produce duplicate frames.
Yes it does, that is the point of it. Without the duplicated frame, a
filter with synchronized inputs (like overlay) will accumulate video
frames while waiting for the next sub2video frame.
It is actually super easy to
On 11/4/2023 4:56 AM, Anton Khirnov wrote:
+static void *task_wrapper(void *arg)
+{
+SchTask *task = arg;
+Scheduler *sch = task->parent;
+int ret;
+int err = 0;
+
+ret = (intptr_t)task->func(task->func_arg);
+if (ret < 0)
+av_log(task->func_arg, AV_LOG_ERROR,
+
On 11/4/2023 4:56 AM, Anton Khirnov wrote:
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
Quoting Lynne (2023-10-30 06:09:28)
> This is a convenience function, which is required to be called by decoders
> needing to skip samples every time.
> It automatically creates and increments side data.
>
> The idea is to get rid of skip_samples eventually and replace it with this
> function.
>
---
fftools/ffmpeg.c| 44 +--
fftools/ffmpeg.h| 32 +-
fftools/ffmpeg_filter.c | 720 +++-
3 files changed, 204 insertions(+), 592 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index bd783fe674..1f21008588 100644
---
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
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
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
As it causes subtitle packets processed by encoders/muxers to signal
back to decoding, it depends on packets being processed in a specific
order and is thus in its current form fundamentally incompatible with
threading architecture.
---
fftools/ffmpeg.c | 31
This ensures that tq_receive() will always return EOF after all streams
were receive-finished, even though the sending side might not have
closed them yet. This may allow the receiver to avoid manually tracking
which streams it has already closed.
---
fftools/thread_queue.c | 2 +-
1 file
---
fftools/ffmpeg.c | 12 +-
fftools/ffmpeg.h | 21 +---
fftools/ffmpeg_demux.c | 268 -
3 files changed, 134 insertions(+), 167 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 1a58bf98cf..611ac4621d 100644
---
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
---
fftools/ffmpeg.c | 30 +---
fftools/ffmpeg.h | 11 +-
fftools/ffmpeg_mux.c | 290 ++
fftools/ffmpeg_mux.h | 24 +---
fftools/ffmpeg_mux_init.c | 40 ++
fftools/ffmpeg_opt.c | 6 +-
6 files changed, 61
---
fftools/ffmpeg.c | 236 +--
fftools/ffmpeg.h | 10 +-
2 files changed, 25 insertions(+), 221 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 5d1560b891..aae680f052 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -462,23
---
fftools/ffmpeg.c | 3 +-
fftools/ffmpeg.h | 7 +-
fftools/ffmpeg_enc.c | 361 ++
fftools/ffmpeg_mux_init.c | 43 +
4 files changed, 66 insertions(+), 348 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index
---
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 9d86c29ebd..e288ea4b80 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -2516,17 +2516,17 @@ static int
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
---
fftools/ffmpeg.c | 22 ---
fftools/ffmpeg.h | 13 +-
fftools/ffmpeg_dec.c | 315 ++-
3 files changed, 70 insertions(+), 280 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 611ac4621d..bd783fe674 100644
---
* 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
Current code tracks min/max pts for each stream separately; then when
the file ends it combines them with last frame's duration to compute the
total duration of each stream; finally it selects the longest of those
durations as the file duration.
This is incorrect - the total file duration is the
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
Will be useful in following commits.
---
fftools/ffmpeg_filter.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index d48974581b..4edf634b26 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -74,6 +74,8 @@ static
Hi,
after ~2 years of work and ~700+ preparatory commits, here is finally
the first "fully functional" version of multithreaded ffmpeg CLI. In
quotes because due to the scale of the changes I'm sure some things got
broken and I didn't notice - more testing very much welcome.
One thing which is
It only seems to produce duplicate frames.
---
fftools/ffmpeg_filter.c | 3 ---
tests/ref/fate/sub2video_basic| 3 ---
tests/ref/fate/sub2video_time_limited | 1 -
3 files changed, 7 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index
It does not cause any issues in current callers, but still should not
happen.
---
fftools/thread_queue.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/fftools/thread_queue.c b/fftools/thread_queue.c
index a1ab4ce92e..feac6a7748 100644
---
It is common for subtitle streams to have large gaps between packets.
When the caller is interleaving packets from multiple files, it can
easily happen that two successive subtitle packets trigger this limit,
even though no excessive buffering is happening.
---
libavformat/mux.c | 2 +-
1 file
It would be left empty on each frame whose packet does not come with
palette attached.
---
libavcodec/8bps.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/8bps.c b/libavcodec/8bps.c
index 0becaa9320..11b9f526b7 100644
--- a/libavcodec/8bps.c
+++
Will allow to use them in future commits without including the whole
ffmpeg.h.
---
fftools/ffmpeg.c | 1 +
fftools/ffmpeg.h | 21 --
fftools/ffmpeg_dec.c | 1 +
fftools/ffmpeg_demux.c | 1 +
fftools/ffmpeg_mux.c | 1 +
fftools/ffmpeg_utils.h | 50
From: Paul B Mahol
Signed-off-by: Anton Khirnov
---
libavfilter/af_amix.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavfilter/af_amix.c b/libavfilter/af_amix.c
index aa42514106..120a97f48c 100644
--- a/libavfilter/af_amix.c
+++ b/libavfilter/af_amix.c
50 matches
Mail list logo
