Quoting Alexander Strasser (2023-11-26 16:08:42)
> On 2023-11-26 10:18 +0100, Anton Khirnov wrote:
> > Set pushed.
> >
> > The general_assembly.pl script should now be usable as the authoritative
> > source for GA members.
>
> The patches mostly LGTM.
>
>
Hi all,
the vote has ended, with the result that ALL proposed candidates are
added to GA. See [1] for more details.
Raw votes in CSV format are attached for posterity (also downloadable
from [1]).
[1] https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_d0b225b9aa8d45d5
Cheers,
--
Anton
(+), 27 deletions(-)
Looks ok.
I'm also wondering whether we could/should now remove all
ff_default_query_formats() calls from the filters and make that function
filtergraph-only.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
ons(-)
Looks very ok.
--
Anton Khirnov
___
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".
don't object to the message, I mean just that
if (foo) {
continue;
} else
bar;
is equivalent to
if (foo) {
continue;
}
bar;
The latter saves you one level of indentation and I find it more
readable.
--
Anton Khirnov
___
ffmpeg-deve
Would be nice to have tests for these.
--
Anton Khirnov
___
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
"No render device %s, try next device for
> "
> + "DRM render node.\n", path);
> +continue;
> +} else
> + av_log(ctx, AV_LOG_VERBOSE, "No avaialbe render
> device
@@ -2200,6 +2200,12 @@ static int qsv_device_create(AVHWDeviceContext *ctx,
> const char *device,
> #endif
> #if CONFIG_D3D11VA
> case AV_HWDEVICE_TYPE_D3D11VA:
> +{
Useless braces.
--
Anton Khirnov
___
ffmpeg-devel mailing list
D11CreateDevice(adapter, D3D_DRIVER_TYPE_UNKNOWN, NULL,
> flags, NULL, 0, D3D11_SDK_VERSION, , NULL, NULL);
> +if (FAILED(hr)) {
> +av_log(ctx, AV_LOG_ERROR, "D3D11CreateDevice returned error\n");
This should not be AV_LOG_ERROR, since it does
Quoting Xiang, Haihao (2023-11-24 08:38:52)
> From: Haihao Xiang
>
> This fixed the issue mentioned in [1]
>
> [1] http://ffmpeg.org/pipermail/ffmpeg-user/2023-October/056983.html
Commit messages should be meaningful on their own, without referring to
external sources.
--
Quoting Dmitrii Ovchinnikov (2023-11-24 09:45:14)
> If there are no objections, I would like to merge it in 2-3 days
The code looks significantly duplicated.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.
/mips/ac3dsp_mips.o' failed
> > make: *** [libavcodec/mips/ac3dsp_mips.o] Error 1
> > make: *** Waiting for unfinished jobs
> > mips FAIL
>
> Do you know where is size_t defined for this target? stddef.h?
size_t should _always_ be defined in stddef.h, as per
Set pushed.
The general_assembly.pl script should now be usable as the authoritative
source for GA members.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
Reminder that the vote will close on Tuesday morning. We have 28/45
votes so far, and no reported bounces. If you have not voted yet please
do so ASAP.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman
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
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
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
s file %s.\n",
@@ -1296,7 +1300,7 @@ static int open_files(OptionGroupList *l, const char
*inout,
return 0;
}
-int ffmpeg_parse_options(int argc, char **argv)
+int ffmpeg_parse_options(int argc, char **argv, Scheduler *sch)
{
OptionParseContext octx;
const char *errmsg
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 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
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
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
---
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 3bafef9717..cd4b55dd40 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -2526,17 +2526,17 @@ static int
of the set should work in isolation. If you want to review
conversions of individual components, see branch 'ffmpeg_threading' in
git://git.khirnov.net/libav
Cheers,
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
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
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 b6fbc5b195..f942c97c40 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -74,6 +74,8 @@ static
Also, add a function that returns const FrameData* for cases that only
read from it.
---
fftools/ffmpeg.c| 21 +
fftools/ffmpeg.h| 2 ++
fftools/ffmpeg_filter.c | 4 ++--
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/fftools/ffmpeg.c
---
libavfilter/buffersink.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index ca2af1bc07..3da3331159 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -164,6 +164,13 @@ static av_cold int
---
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
--- a/tools/general_assembly.pl
+++ b/tools/general_assembly.pl
@@ -13,6 +13,12 @@ use
---
tools/general_assembly.pl | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl
index 3bf65f3405..13c13bb28f 100755
--- a/tools/general_assembly.pl
+++ b/tools/general_assembly.pl
@@ -139,5 +139,7 @@ foreach my $name
Hi,
this is a reminder that this vote will be started next Monday
(2023-11-27).
The candidates so far are:
* TC:
- Jan Ekström
- Anton Khirnov
- Lynne
- Martin Storsjö
- Niklas Haas
- Michael Niedermayer
- Mark Thompson
* CC:
- Dave Rice
- James
the instructions carefully and vote as soon as you can.
Cheers,
--
Anton Khirnov
___
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
Quoting Michael Niedermayer (2023-11-19 11:35:20)
> On Sun, Nov 19, 2023 at 08:48:19AM +0100, Anton Khirnov wrote:
> > Reminder that the vote starts tomorrow.
> >
> > Quoting Anton Khirnov (2023-11-17 10:40:06)
> > > The list of candidates I have so far is:
> >
---
doc/filters.texi | 15 +++
libavfilter/vsrc_ddagrab.c | 7 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index bd4e4ca8f7..30b7c73826 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -28165,10
---
doc/filters.texi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 38615e4f18..bd4e4ca8f7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -28163,7 +28163,12 @@ Only affects hardware cursors. If a game or
application
Reminder that the vote starts tomorrow.
Quoting Anton Khirnov (2023-11-17 10:40:06)
> The list of candidates I have so far is:
> * Ronald Bultje
> * Alexander Strasser
> * Hendrik Leppkes
> * Reimar Döffinger
> * Baptiste Coudurier
> (hope I haven't missed anyone, pl
Quoting Nicolas George (2023-11-17 10:44:22)
> Anton Khirnov (12023-11-09):
> > I am obviously not proposing that, given the amount of patches I sent so
> > far to keep sub2video working.
>
> Ok, sorry.
>
> >
> > > I can suggest this: have demu
Quoting Michael Niedermayer (2023-11-11 21:10:34)
> On Sat, Nov 04, 2023 at 08:56:09AM +0100, Anton Khirnov wrote:
> > Hi,
> > after ~2 years of work and ~700+ preparatory commits, here is finally
> > the first "fully functional" version of multithreaded ffmpeg
Will push the set soon if nobody objects.
--
Anton Khirnov
___
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
...@lain.khirnov.net
Cheers,
--
Anton Khirnov
___
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".
---
tools/general_assembly.pl | 0
1 file changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 tools/general_assembly.pl
diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl
old mode 100644
new mode 100755
--
2.42.0
---
tools/general_assembly.pl | 64 ++-
1 file changed, 57 insertions(+), 7 deletions(-)
diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl
index e59ce0f350..4c3208ccac 100755
--- a/tools/general_assembly.pl
+++ b/tools/general_assembly.pl
@@
Pushed.
And sorry, I didn't notice that the ML mangled your email :/
--
Anton Khirnov
___
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
vote infra we soon will have ;)
The only reason to have our own vote server in the first place was that
the one run by its author [2] did not implement proportional
representation at the time. That has now changed, so I propose we simply
switch to it.
[1] http://lists.ffmpeg.org/pipermail/ff
Quoting Michael Niedermayer (2023-11-12 18:14:09)
> On Sat, Nov 11, 2023 at 07:25:13PM +0100, Anton Khirnov wrote:
> > In other words, you are deliberately trying to subvert the
> > intent of the rules.
>
> no, the GA can change the rules entirely if it wants.
> I can chan
reply to any arguments in the ML thread.
In my eyes, this disqualifies you from running the vote server. Somebody
else should do it.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
eaction to that?
Also, you have just implied that people disagreeing with you are
unthinking zombies driven by their subconscious insticts. That is a VERY
rude thing to say about someone.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@f
Quoting Michael Niedermayer (2023-11-04 19:30:39)
> 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 ++---
t char
*inout,
return 0;
}
-int ffmpeg_parse_options(int argc, char **argv)
+int ffmpeg_parse_options(int argc, char **argv, Scheduler *sch)
{
OptionParseContext octx;
const char *errmsg = NULL;
@@ -1319,7 +1323,7 @@ int ffmpeg_parse_options(int argc, char **argv)
}
easily found by inspection.
This gives me zero confidence that any hypothetical new vote would be
any more reliable than the old one.
Also as I said before, option A won its contests against options B/C/D
by 17/7, 23/1, and 17/7, respectively. You would thus need to change 10
votes to have any cha
Quoting Nicolas George (2023-11-09 11:47:23)
> Anton Khirnov (12023-11-09):
> > The problem with that code (and the reason this patch exists), is that
> > it depends on the order in which the frames arrive on filtergraph
> > inputs, which is not meaningful (and beco
Quoting Michael Niedermayer (2023-11-09 21:17:34)
> Not for anything else. Especially not for having vote rights.
Getting vote rights requires one to submit patches publicly.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
u have root access to the server, you can just look at the email logs
if you have any doubts.
So what is the point of all this? Besides creating a situation where
voting is too hard, so we never do it, as was the case for the past 2
years.
--
Anton Khirnov
_
aid no vs who did not reply just remove if either
> applies]
>
> PS: and i will wait a bit for the current dust to settle first (maybe a day
> or 2)
Okay, then we will postpone the vote until Monday 2023-11-20. I will
expect you to submit a list of candidates before then.
--
Anton
Quoting Michael Niedermayer (2023-11-09 18:39:23)
> On Thu, Nov 09, 2023 at 06:06:16PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-11-09 17:21:12)
> > > On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> > > > As far as I can te
Quoting Michael Niedermayer (2023-11-09 17:21:12)
> On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> > As far as I can tell, the voter list in the last vote should be the same
> > as the GA from 2020, except for the extra members whose voting rights
> >
Quoting James Almer (2023-11-09 13:24:45)
> Hendrik Leppkes and Reimar Döffinger are active, at least. I agree they
> should be in the GA.
Right, I did not mean to imply ALL the people in the above list are
inactive. But many are.
--
Anton K
Quoting Michael Niedermayer (2023-11-09 12:55:25)
> On Thu, Nov 09, 2023 at 10:44:12AM +0100, Anton Khirnov wrote:
> > As nobody expressed a preference, the vote will start next Monday
> > (2023-11-13). It should run for a week, and will be followed by TC/CC
> > elections.
&g
he GA for two years, after which they need a confirmation by the GA.
your voting rights expired after 2 years and were not renewed, since
nobody organized a new vote.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/
Quoting James Almer (2023-11-09 12:47:56)
> On 11/9/2023 8:41 AM, Anton Khirnov wrote:
> > Quoting James Almer (2023-11-04 14:39:44)
> >> On 11/4/2023 4:56 AM, Anton Khirnov wrote:
> >>> This will be the appropriate place for it after the rest of transcoding
&
If nobody objects, I will push 01-07/24 soonish.
--
Anton Khirnov
___
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
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
Quoting James Almer (2023-11-04 14:39:44)
> 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.
> > ---
> >
Quoting Michael Niedermayer (2023-11-04 19:44:09)
> 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 sc
9,7 +1323,7 @@ int ffmpeg_parse_options(int argc, char **argv)
}
/* apply global options */
-ret = parse_optgroup(NULL, _opts);
+ret = parse_optgroup(sch, _opts);
if (ret < 0) {
errmsg = "parsing global options";
goto fail;
@@ -1329,7 +1333,7 @@
Quoting James Almer (2023-11-04 14:53:25)
> 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;
>
Quoting Nicolas George (2023-11-04 15:19:00)
> 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
>
Quoting James Almer (2023-11-07 21:52:11)
> What can probably be dropped however are the checks in log.c for
> runtime major version 50 and 51.
Right. Patches welcome?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Quoting Alexander Strasser (2023-11-08 21:55:10)
> On 2023-11-08 12:40 +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-10-31 09:40:44)
> > > On Mon, Oct 30, 2023 at 02:11:27PM +0100, Andreas Rheinhardt wrote:
> > > > Section 7.4.4 of the
sertions(+), 4 deletions(-)
Set pushed
--
Anton Khirnov
___
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".
vcodec/ffv1.c| 1 -
> libavcodec/ffv1.h| 4 +--
> libavcodec/ffv1dec.c | 83 +++-
> 3 files changed, 37 insertions(+), 51 deletions(-)
Looks ok
--
Anton Khirnov
___
ffmpeg-devel mailing list
avcodec/pngdec.c | 64 +++--
> 1 file changed, 27 insertions(+), 37 deletions(-)
Looks ok
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-deve
avcodec/hevc_filter.c | 8
> libavcodec/hevc_mvs.c| 6 +++---
> libavcodec/hevc_refs.c | 22 ++
> libavcodec/hevcdec.c | 24 ++--
> libavcodec/hevcdec.h | 4 ++--
> 5 files changed, 29 insertions(+), 35 delet
,
--
Anton Khirnov
___
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".
B on its own.
> The current MAX_URL_SIZE will trim the URL with no any errors or
> warnings and the request will fail with a http 400 error.
Why do we have a static limit in the first place? Wouldn't it be better
to make the relevant strings dynamically allocated?
Quoting Henrik Gramner via ffmpeg-devel (2023-10-01 19:55:57)
> On Fri, Sep 29, 2023 at 1:38 PM Frank Plowman wrote:
> > libavutil/x86/x86inc.asm | 10 ++
> > 1 file changed, 10 insertions(+)
>
> LGTM.
pushed
--
Anton Khirnov
_
Only after the benchmarks and PSNR is presented should we decide if this
> is a change we want
I disagree that the burden of proof should be on Andreas here. It should
be up to whoever wants to keep this code to show that it is useful.
--
Anton Khirnov
Quoting Vittorio Giovara (2023-11-06 21:06:50)
> Could I volunteer as well for CC?
Certainly, anyone willing to do the work is welcome.
Cheers,
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listi
---
libavutil/log.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavutil/log.c b/libavutil/log.c
index 2d358b7ab9..46662f3db0 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -291,6 +291,11 @@ static const char *get_level_str(int level)
}
}
+static
---
fftools/cmdutils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 156c13801a..86cd3bddb4 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -665,10 +665,10 @@ static int init_parse_context(OptionParseContext
---
fftools/ffmpeg_filter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index c8920d9234..b7da105141 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -928,8 +928,10 @@ int fg_create(FilterGraph
---
fftools/ffmpeg_filter.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index c738fc3397..c8920d9234 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -905,8 +905,14 @@ int fg_create(FilterGraph
tream *st);
>
> +/**
> + * Frees a stream group without modifying the corresponding AVFormatContext.
> + * Must only be called if the latter doesn't matter or if the stream
> + * is not yet attached to an AVFormatContext.
> + */
> +void ff_free_stream_group(AVStreamGroup **pstg);
Quoting Anton Khirnov (2023-11-06 10:57:45)
> Follows the updated voter list that will be used from today until
> 2024-01-01.
Just realized this wording is too strict, as the list may be extended
with extra members after the next vote. So the final list will be a
superset of the abo
Quoting Gyan Doshi (2023-11-06 11:08:02)
>
>
> On 2023-11-06 02:03 pm, Anton Khirnov wrote:
> > By intent, and in practice, the "active contributor" criterium applies
> > to the person authoring the commits, not the one pushing them into the
> > repository.
raise them
here.
Andreas Rheinhardt
Andriy Gelman
Anton Khirnov
Carl Eugen Hoyos
Clément Bœsch
Derek Buitenhuis
Devin Heitmueller
Diederick Niehorster
Fei Wang
Guo, Yejun
Gyan Doshi
Haihao Xiang
James Almer
Jan Ekström
J. Dekker
Jun Zhao
Leo Izen
Limin Wang
Linjie
possible but its not a standard feature of trac that
> i know of.
>
> you would have to change trac, do a trac plugin or something else
> i guess
I'd expect it to be doable rather easily on the gateway webserver (seems
to be Apache for trac.ffmpeg.org).
--
Anton Khirnov
_
Cf.:
* http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-October/316054.html
* http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316618.html
---
doc/community.texi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/doc/community.texi b/doc/community.texi
index
By intent, and in practice, the "active contributor" criterium applies
to the person authoring the commits, not the one pushing them into the
repository.
---
doc/community.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/community.texi b/doc/community.texi
index
Quoting Zhao Zhili (2023-11-03 10:32:07)
> From: Zhao Zhili
>
> Signed-off-by: Zhao Zhili
> ---
> libavdevice/android_camera.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Looks trivially ok
--
Anton Khirnov
___
ff
or three weeks for discussion and proposing candidates.
The candidates so far are:
* TC:
- Jan Ekström
- Anton Khirnov
- Lynne
- Martin Storsjö
- Niklas Haas
- Michael Niedermayer
- Mark Thompson
* CC:
- Dave Rice (IIUC it was somebody else who suggested him, so he'd
description of how they contribute to the project.
Other constructive comments also welcome.
Cheers,
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
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 activ
ss_correct_pts(AVCodecContext *ctx,
> return pts;
> }
>
> +int ff_decode_skip_samples(AVCodecContext *avctx, AVFrame *frame, uint32_t
> base_skip, uint32_t additional)
avctx seems unused.
--
Anton Khirnov
___
ffmpeg-devel maili
---
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
801 - 900 of 4242 matches
Mail list logo
