From: Wenbin Chen
We can directly get data ptr from tensor, so that extral memory
allocation can be removed.
Signed-off-by: Wenbin Chen
---
libavfilter/dnn/dnn_backend_openvino.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/libavfilter/dnn/dn
Nov 7, 2023, 08:36 by d...@lynne.ee:
> Oct 29, 2023, 06:57 by d...@lynne.ee:
>
>> Oct 29, 2023, 05:51 by mich...@niedermayer.cc:
>>
>>> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
>>>
Oct 28, 2023, 18:49 by mich...@niedermayer.cc:
> On Thu, Jul 06, 2023 at 06:04:41PM +020
Michael
Could you please apply the following patch
[FFmpeg-devel] [PATCH 2/4] avcodec/evc_parse: Check
num_remaining_tiles_in_slice_minus1
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231004225921.30287-2-mich...@niedermayer.cc/
Dawid
> -Original Message-
> From: ffmpeg-devel
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.
The only extra GA candidate I see proposed so far is Ronald. If anyone
wants to suggest further people, please do so in this thread ASAP.
Cheers,
--
On 9 Nov 2023, at 9:20, Lynne wrote:
> Nov 7, 2023, 08:36 by d...@lynne.ee:
>
>> Oct 29, 2023, 06:57 by d...@lynne.ee:
>>
>>> Oct 29, 2023, 05:51 by mich...@niedermayer.cc:
>>>
On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
> Oct 28, 2023, 18:49 by mich...@niedermayer.cc:
On 2023-11-09 03:16 pm, epira...@gmail.com wrote:
If 6.1 will be cut from master, my tpad fix I sent yesterday should probably be
applied first
to prevent having a release with broken tpad.
The branch is already cut. Will need to be cherry-picked.
Regards,
Gyan
Quoting Andreas Rheinhardt (2023-09-19 21:57:32)
> Avoids implicit av_frame_ref() and therefore allocations
> and error checks. It also avoids explicitly allocating
> the AVFrames (done implicitly when getting the buffer).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/hevc_filter.c |
Quoting Andreas Rheinhardt (2023-09-19 21:57:33)
> Avoids implicit av_frame_ref() and therefore allocations
> and error checks. It also avoids explicitly allocating
> the AVFrames (done implicitly when getting the buffer).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/pngdec.c | 64 ++
Quoting Andreas Rheinhardt (2023-09-19 21:57:34)
> Avoids implicit av_frame_ref() and therefore allocations
> and error checks. It also avoids explicitly allocating
> the AVFrames (done implicitly when getting the buffer).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ffv1.c| 1 -
Quoting Marvin Scholz (2023-11-07 23:21:17)
> The check if drawing needs to be initialized and supported formats
> should be drawable ones was flawed, as pad_stop/pad_start is only
> populated from stop_duration/start_duration after these checks.
>
> To fix that, check the _duration variants as we
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 MPEG-2 specifications requires that the
> >
Hi,
Both, the implementation of the EVC encoder and decoder for FFmpeg depend on
external libraries (at least for now). They are just wrappers using external
libraries, namely libxeve (encoder implementation) and libxevd (decoder
implementation).
The EVC defines two profiles: the "Baseline Pr
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
https://ffmpe
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
> frames while waiting for the
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 becomes non-deterministic with
> threading).
I can understand that. We will have to find
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;
> > +
> > +ret = (intptr_t)task->func(task->func
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 orde
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 scheduling code itself, along with mini
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.
> > ---
> > fftools/ffmpeg_mux.c | 112 ++-
> > 1
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
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 with sub
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
is switched to a threaded architecture.
---
fftools/ffmpeg_mux.c | 112 +
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.
>
> The only extra GA candidate I see proposed so far is Ronald. If anyone
> wants
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
> >>> is switched to a threaded architec
On Thu, Nov 9, 2023 at 6:55 AM Michael Niedermayer
wrote:
> Fabrice Bellard(Founder of the project over 600 commits in FFmpeg)
> Aman Karmani (17 authored commits in 2020-2023, recently active in
> 2023-June and work all over the codebase)
> Baptiste Coudurier (Pays for our fate server
On Thu, 9 Nov 2023, at 12:55, Michael Niedermayer wrote:
> If the current GA stays as it is, then i propose the following people
Most of those people have not been active for years.
Adding the people who were part of the GA before;
or are just under the threshold, but were active before;
or a
Quoting Alexander Strasser (2023-11-06 16:56:55)
> Hi all,
> hi J-B!
>
> On 2023-11-06 07:10 +0100, Jean-Baptiste Kempf wrote:
> > Yo,
> >
> > Time is up, results are here:
> > https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_029f7195fed7aadf
>
> Should I have been mailed about this vote?
>
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.
> >
> > The only extra G
On 11/9/2023 9:21 AM, Anton Khirnov wrote:
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
ele
From: Niklas Haas
In particular, make it clear that this function will not touch format
lists which were already set by the caller before calling into this
function.
---
libavfilter/formats.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavfilter/formats.h b/libavfilter/formats.h
in
Following up on the previous attempts at YUVJ removal, this series
implements full filter negotiation. It is WIP because I still need to go
through the remaining AVCodec (which are not covered by FATE) and
properly tag their colorspace and color range support. (See patch 19/25)
The rest should be
From: Niklas Haas
Even if a query func is set. This is safe to do, because
ff_default_query_formats is documented not to touch any filter lists
that were already set by the query func.
The reason to do this is because it allows us to extend
AVFilterFormatsConfig without having to touch every fil
From: Niklas Haas
Motivated by YUVJ removal. This change will allow full negotiation
between color ranges and matrices as needed. By default, all ranges and
matrices are marked as supported.
Because grayscale formats are currently handled very inconsistently (and
in particular, assumed as forced
From: Niklas Haas
This memset is bogus, it accomplishes nothing in the best case and
regresses future additions to AVBufferSrcParameters in the worst case.
---
fftools/ffmpeg_filter.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index b7
From: Niklas Haas
---
libavfilter/vf_libplacebo.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
index b6e82a61e0..a9a3d884ce 100644
--- a/libavfilter/vf_libplacebo.c
+++ b/libavfilter/vf_l
From: Niklas Haas
Rewrite the format parsing code to make it more easily generalizable. In
particular, `invert_formats` does not depend on the type of format list
passed to it, which allows me to re-use this helper in an upcoming
commit.
Slightly shortens the code, at the sole cost of doing seve
From: Niklas Haas
Needed for fftools.
---
doc/APIchanges | 3 +++
libavfilter/buffersink.c | 2 ++
libavfilter/buffersink.h | 2 ++
libavfilter/version.h| 2 +-
4 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index ce3f90a674..97b6de827
From: Niklas Haas
Which will impose no restriction. This makes sense when using e.g.
`color_ranges=pc` to limit the color range, without also limiting the
pixel format.
---
libavfilter/vf_format.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_format.
From: Niklas Haas
Needed for fftools/ffmpeg_filter to be able to force specific output
formats via the filter chain.
---
doc/filters.texi| 8
libavfilter/vf_format.c | 44 +
2 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/
From: Niklas Haas
Mirroring the previous commit, all codecs which previously never
accepted YUVJ now need to be labelled as MPEG range only.
TODO:
- add the rest of the codecs
---
libavcodec/mpeg4videoenc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/mpeg4videoenc.c b/liba
From: Niklas Haas
This is motivated primarily by a desire for YUVJ removal, which will
require signalling the supported color ranges as part of the codec
capabilities. But since we're adding YUV range, we might as well add the
YUV color matrix as well - since some codecs (e.g. VP8, JPEG) only
sup
From: Niklas Haas
Only affects amv and roqvideo. (mjpeg is handled separately by fftools)
---
libavcodec/mjpegenc.c| 3 +++
libavcodec/roqvideoenc.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index 508772987f..c827a47e59 100644
--- a/
From: Niklas Haas
The only meaningful difference between choose_pix_fmts and the default
code was the inclusion of an extra branch for `keep_pix_fmt` being true.
However, in this case, we either:
1. Force the specific `ofp->format` that we inherited from
ofilter_bind_ost, or if no format was
From: Niklas Haas
To convert between color spaces/ranges, if needed by the codec
properties. We momentarily duplicate the mjpeg strictness logic to also
enfoce full range. This duplication will be cleaned up in an upcoming
commit.
Due to avcodec_open2 being called after ofilter_bind_ost, we need
From: Niklas Haas
The input file is MPEG range, so we should also encode to MPEG range
before comparing against it. This bug was avoided in the past because
JPEG range YUV inputs were tagged as YUVJ, which resulted in an
automatic conversion to PC range by default.
After YUVJ removal, we will ne
From: Niklas Haas
These no longer exist.
---
libavutil/pixdesc.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 2886c9e0f5..9244b9d7a8 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2977,8 +2977,7
From: Niklas Haas
In general, the logic is always the same: if the codec supports only a
single format, enforce it if possible. Otherwise, throw an error when
an incompatible format is thrown.
To preserve backwards compatibility and make this check less pedantic
than it needs to be, always consi
From: Niklas Haas
Propagates input metadata to the input filter graph.
---
fftools/ffmpeg_filter.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index e699798897..dd5cfe4481 100644
--- a/fftools/ffm
From: Niklas Haas
To allow adding proper negotiation, in particular, to fftools.
These values will simply be negotiated downstream for YUV formats, and
ignored otherwise.
---
doc/filters.texi| 10 +++
libavfilter/buffersrc.c | 62 -
libavfilte
From: Niklas Haas
This is never avertised as supported to upstream filters.
---
libavfilter/vf_scale.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 44dc1f2bf8..dbe380d4c0 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale
From: Niklas Haas
This filter will always accept any input format, even if the user sets
a specific in_range/in_color_matrix. This is to preserve status quo with
current behavior, where passing a specific in_color_matrix merely
overrides the incoming frames' attributes. (Use `vf_format` to force
From: Niklas Haas
Following the same design as vf_scale.
---
libavfilter/vf_zscale.c | 44 +++--
1 file changed, 34 insertions(+), 10 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index f76c9954cd..3b14ce4f33 100644
--- a/libavfi
From: Niklas Haas
Only assigned, never read.
---
libavfilter/vf_zscale.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 788870ffaf..f76c9954cd 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -132,1
From: Niklas Haas
This is at odds with the YUV matrix negotiation API, in which such
dynamic changes in YUV encoding are no longer easily possible. There is
also no really strong motivating reason to do this, since the choice of
YUV matrix is essentially arbitrary and not actually related to the
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 Khirnov
___
On Thu, Nov 9, 2023 at 12:55 PM Michael Niedermayer
wrote:
> 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.
> >
> > The on
On Thu, Nov 9, 2023 at 12:46 PM Anton Khirnov wrote:
> If nobody objects, I will push 01-07/24 soonish.
>
Only after Nicolas properly reviews this.
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/
Ping. v6 didn’t changed much compare to v5.
> On Nov 8, 2023, at 00:45, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> Add vulkan renderer via libplacebo.
>
> Simple usage:
> $ ffplay -hwaccel vulkan foo.mp4
>
> Use cuda to vulkan map:
> $ ffplay -hwaccel cuda foo.mp4
>
> Create vulkan instance
Hi,
Le 9 novembre 2023 12:16:28 GMT+02:00, "Dawid Kozinski/Multimedia (PLT)
/SRPOL/Staff Engineer/Samsung Electronics" a écrit :
>Hi,
>
>Both, the implementation of the EVC encoder and decoder for FFmpeg depend on
>external libraries (at least for now). They are just wrappers using external
>
On Thu, Nov 09, 2023 at 07:11:37AM -0500, Vittorio Giovara wrote:
> On Thu, Nov 9, 2023 at 6:55 AM Michael Niedermayer
> wrote:
>
> > Fabrice Bellard(Founder of the project over 600 commits in FFmpeg)
> > Aman Karmani (17 authored commits in 2020-2023, recently active in
> > 2023-June a
On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> 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,
On Thu, 9 Nov 2023, at 17:21, Michael Niedermayer wrote:
> On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
>> 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
On Thu, Nov 9, 2023 at 10:40 AM Michael Niedermayer
wrote:
> On Thu, Nov 09, 2023 at 07:11:37AM -0500, Vittorio Giovara wrote:
> > On Thu, Nov 9, 2023 at 6:55 AM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > Fabrice Bellard(Founder of the project over 600 commits in FFm
On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-11-09 12:55:25)
[...]
> > If the current GA stays as it is, then i propose the following people
> > (this list was quickly made and certainly has omisions and possibly errors,
> > check anything thats
Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit :
> that said, i checked ML subscribers and found
> 16 of the people above to be currently subscribed with email addresses
> that i found by greping their name. (not posting the list due to privacy
> concerns)
Thing is, if
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
> > expire after 2 years.
> >
>
On Thu, Nov 09, 2023 at 05:36:10PM +0100, Jean-Baptiste Kempf wrote:
>
>
> On Thu, 9 Nov 2023, at 17:21, Michael Niedermayer wrote:
> > On Thu, Nov 09, 2023 at 01:21:13PM +0100, Anton Khirnov wrote:
> >> Quoting Michael Niedermayer (2023-11-09 12:55:25)
> >> > On Thu, Nov 09, 2023 at 10:44:12AM +
On Thu, 9 Nov 2023, at 18:24, Michael Niedermayer wrote:
> theres a list of voters in 2020 and 2023
The list of voters in 2020 comes from the script written by Josh (IIRC?) and
run by Thilo (?) IIRC when Thilo installed CIVS.
It quite matches the gitlog.
The list was reused for the vote, and now
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 tell, the voter list in the last vote should be the same
> > > as the GA from 2020, except for
On Thu, Nov 9, 2023 at 5:06 PM 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 tell, the voter list in the last vote should be the same
> > > as the GA from 2020, except for the extr
On Thu, Nov 09, 2023 at 07:04:00PM +0200, Rémi Denis-Courmont wrote:
> Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit :
> > that said, i checked ML subscribers and found
> > 16 of the people above to be currently subscribed with email addresses
> > that i found by grepin
On Thu, Nov 09, 2023 at 06:31:13PM +0100, Jean-Baptiste Kempf wrote:
> On Thu, 9 Nov 2023, at 18:24, Michael Niedermayer wrote:
> > theres a list of voters in 2020 and 2023
>
> The list of voters in 2020 comes from the script written by Josh (IIRC?) and
> run by Thilo (?) IIRC when Thilo installe
Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit :
> On Thu, Nov 09, 2023 at 07:04:00PM +0200, Rémi Denis-Courmont wrote:
> > Le torstaina 9. marraskuuta 2023, 18.50.52 EET Michael Niedermayer a écrit
:
> > > that said, i checked ML subscribers and found
> > > 16 of the p
Am 09.11.23 um 18:50 schrieb Michael Niedermayer:
On Thu, Nov 09, 2023 at 06:31:13PM +0100, Jean-Baptiste Kempf wrote:
On Thu, 9 Nov 2023, at 18:24, Michael Niedermayer wrote:
theres a list of voters in 2020 and 2023
The list of voters in 2020 comes from the script written by Josh (IIRC?) and
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 tell, the voter list in the last vote
> On Nov 9, 2023, at 9:53 AM, Rémi Denis-Courmont wrote:
>
> The point is that, whether or not they are on the mailing list, people should
> not be volunteered to the GA by others, but on their own volition. The
> circumstances are different for those on the mailing list and those not, but
>
On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
> Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit :
[...]
> If you think some people should be added, as far as I am concerned, you are
> of
> course welcome to nudge them via private message to friend
Quoting Michael Niedermayer (2023-11-09 19:15:35)
> On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
> > Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit :
> [...]
> > If you think some people should be added, as far as I am concerned, you are
> > of
This saves three scratch registers and three instructions per line. The
performance gains are mostly negligible. The main point is to free up
registers for further rework.
---
libswscale/riscv/rgb2rgb_rvv.S | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --g
In my personal opinion, we should not need to support unaligned YUY2
pixel maps. They should always be aligned to at least 32 bits, and the
current code assumes just 16 bits. However checkasm does test for
unaligned input bitmaps. QEMU accepts it, but real hardware dose not.
In this particular cas
Le torstaina 9. marraskuuta 2023, 20.11.12 EET Cosmin Stejerean via ffmpeg-
devel a écrit :
> > On Nov 9, 2023, at 9:53 AM, Rémi Denis-Courmont wrote:
> >
> > The point is that, whether or not they are on the mailing list, people
> > should
> > not be volunteered to the GA by others, but on thei
On Thu, 9 Nov 2023, Michael Niedermayer wrote:
On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit :
[...]
If you think some people should be added, as far as I am concerned, you are of
course welcome
On Thu, Nov 09, 2023 at 07:12:24PM +0100, Anton Khirnov wrote:
> 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 Khirn
Quoting Michael Niedermayer (2023-11-09 19:50:16)
> >
> > > these are lists with roughly 50 entries, now we _know_ 2 people differ
> >
> > We don't. You only mention one, whom I adress above. Who is the second?
>
> Alexander Strasser
It seems clear that none of the three extra GA members were o
On Thu, 9 Nov 2023, at 19:15, Michael Niedermayer wrote:
> On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
>> Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit :
> [...]
>> If you think some people should be added, as far as I am concerned, you are
>
Le torstaina 9. marraskuuta 2023, 20.34.53 EET Rémi Denis-Courmont a écrit :
> In my personal opinion, we should not need to support unaligned YUY2
> pixel maps. They should always be aligned to at least 32 bits, and the
> current code assumes just 16 bits. However checkasm does test for
> unaligne
On Thu, Nov 09, 2023 at 08:30:15PM +0100, Jean-Baptiste Kempf wrote:
>
>
> On Thu, 9 Nov 2023, at 19:15, Michael Niedermayer wrote:
> > On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
> >> Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit
> >> :
> >
With a value of zero, the function is a glorified memory copy.
---
tests/checkasm/sbrdsp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/sbrdsp.c b/tests/checkasm/sbrdsp.c
index 2fb14d5bf8..5cc3b33215 100644
--- a/tests/checkasm/sbrdsp.c
+++ b/tests/checkas
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
https:
On 2023-11-09 11:13 +0100, Anton Khirnov wrote:
> 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:
> > > > > Sectio
On 2023-11-08 17:58 -0500, Vittorio Giovara wrote:
> On Wed, Nov 8, 2023 at 3:46 PM Alexander Strasser wrote:
>
> > 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:
>
Le torstaina 9. marraskuuta 2023, 22.45.35 EET Alexander Strasser a écrit :
> I can't see how the reason for the presence of code can be ultimately
> defined objectively and non-arbitrary.
Ultimately, this was discussed and decided in a meeting, which Michael
attended (albeit remotely) and for wh
hf_gen_c: 2922.7
hf_gen_rvv_f32: 731.5
---
libavcodec/riscv/sbrdsp_init.c | 4 +++
libavcodec/riscv/sbrdsp_rvv.S | 50 ++
2 files changed, 54 insertions(+)
diff --git a/libavcodec/riscv/sbrdsp_init.c b/libavcodec/riscv/sbrdsp_init.c
index c1ed5b639c..e573645
Hi Anton!
On 2023-11-09 13:15 +0100, Anton Khirnov wrote:
> Quoting Alexander Strasser (2023-11-06 16:56:55)
> > On 2023-11-06 07:10 +0100, Jean-Baptiste Kempf wrote:
> > > Yo,
> > >
> > > Time is up, results are here:
> > > https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_029f7195fed7aadf
> >
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 becomes non-deterministic with
> > th
On Thu, 9 Nov 2023, Rémi Denis-Courmont wrote:
With a value of zero, the function is a glorified memory copy.
---
tests/checkasm/sbrdsp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/sbrdsp.c b/tests/checkasm/sbrdsp.c
index 2fb14d5bf8..5cc3b33215 100644
-
On 2023-11-09 12:55 +0100, Michael Niedermayer wrote:
> 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.
> >
> > The only extr
Contents:
+ November 10th, 2023, FFmpeg 6.1 "Heaviside"
+
+ FFmpeg 6.1 "Heaviside", a new
+ major release, is now available! Some of the highlights:
+
+
+ libaribcaption decoder
+ Playdate video decoder and demuxer
+ Extend VAAPI support for libva-win32 on Windows
+ afireq
On Thu, Nov 09, 2023 at 08:15:33PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-11-09 19:50:16)
> > >
> > > > these are lists with roughly 50 entries, now we _know_ 2 people differ
> > >
> > > We don't. You only mention one, whom I adress above. Who is the second?
> >
> > Alex
On Thu, Nov 09, 2023 at 10:52:19PM +0200, Rémi Denis-Courmont wrote:
> Le torstaina 9. marraskuuta 2023, 22.45.35 EET Alexander Strasser a écrit :
> > I can't see how the reason for the presence of code can be ultimately
> > defined objectively and non-arbitrary.
>
> Ultimately, this was discussed
1 - 100 of 113 matches
Mail list logo
