[FFmpeg-devel] [PATCH] libavfilter/dnn/openvino: Reduce redundant memory allocation
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/dnn_backend_openvino.c
b/libavfilter/dnn/dnn_backend_openvino.c
index 10520cd765..d3af8c34ce 100644
--- a/libavfilter/dnn/dnn_backend_openvino.c
+++ b/libavfilter/dnn/dnn_backend_openvino.c
@@ -204,7 +204,6 @@ static int fill_model_input_ov(OVModel *ov_model,
OVRequestItem *request)
ov_tensor_t* tensor = NULL;
ov_shape_t input_shape = {0};
ov_element_type_e precision;
-void *input_data_ptr = NULL;
#else
dimensions_t dims;
precision_e precision;
@@ -249,12 +248,6 @@ static int fill_model_input_ov(OVModel *ov_model,
OVRequestItem *request)
input.width = dims[2];
input.channels = dims[3];
input.dt = precision_to_datatype(precision);
-input.data = av_malloc(input.height * input.width * input.channels *
get_datatype_size(input.dt));
-if (!input.data) {
-ov_shape_free(&input_shape);
-return AVERROR(ENOMEM);
-}
-input_data_ptr = input.data;
#else
status = ie_infer_request_get_blob(request->infer_request,
task->input_name, &input_blob);
if (status != OK) {
@@ -297,6 +290,26 @@ static int fill_model_input_ov(OVModel *ov_model,
OVRequestItem *request)
request->lltasks[i] = lltask;
request->lltask_count = i + 1;
task = lltask->task;
+#if HAVE_OPENVINO2
+if (tensor)
+ov_tensor_free(tensor);
+status = ov_tensor_create(precision, input_shape, &tensor);
+ov_shape_free(&input_shape);
+if (status != OK) {
+av_log(ctx, AV_LOG_ERROR, "Failed to create tensor from host
prt.\n");
+return ov2_map_error(status, NULL);
+}
+status = ov_tensor_data(tensor, &input.data);
+if (status != OK) {
+av_log(ctx, AV_LOG_ERROR, "Failed to get input data.\n");
+return ov2_map_error(status, NULL);
+}
+status = ov_infer_request_set_input_tensor(request->infer_request,
tensor);
+if (status != OK) {
+av_log(ctx, AV_LOG_ERROR, "Failed to Set an input tensor for the
model.\n");
+return ov2_map_error(status, NULL);
+}
+#endif
switch (ov_model->model->func_type) {
case DFT_PROCESS_FRAME:
if (task->do_ioproc) {
@@ -317,24 +330,11 @@ static int fill_model_input_ov(OVModel *ov_model,
OVRequestItem *request)
av_assert0(!"should not reach here");
break;
}
-#if HAVE_OPENVINO2
-status = ov_tensor_create_from_host_ptr(precision, input_shape,
input.data, &tensor);
-ov_shape_free(&input_shape);
-if (status != OK) {
-av_log(ctx, AV_LOG_ERROR, "Failed to create tensor from host
prt.\n");
-return ov2_map_error(status, NULL);
-}
-status = ov_infer_request_set_input_tensor(request->infer_request,
tensor);
-if (status != OK) {
-av_log(ctx, AV_LOG_ERROR, "Failed to Set an input tensor for the
model.\n");
-return ov2_map_error(status, NULL);
-}
-#endif
input.data = (uint8_t *)input.data
+ input.width * input.height * input.channels *
get_datatype_size(input.dt);
}
#if HAVE_OPENVINO2
-av_freep(&input_data_ptr);
+ov_tensor_free(tensor);
#else
ie_blob_free(&input_blob);
#endif
--
2.34.1
___
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".
Re: [FFmpeg-devel] [RFC] Release 6.1
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 +0200, Lynne wrote: > >> It's been a while since we've had a release, and we've had >> a lot of new features in. >> We did say we would make releases more often, and I think >> it's about time we have a new release. >> >> Anything anyone wants to have merged or should we branch >> off 6.1 in a few days? >> > > Whats the status of this ? > I can branch 6.1 anytime > > It was just that jb told me > "6.1 opportunity is gone. > We're too late on the schedule, and noone had time to work on it, so it > is wiser to target 7.0 in January" > > but now i see on IRC > make a damn release already > j-b: drop MiNi from release maintership and nominate > Lynne > I pledge to bring back /slap IRC messages to those who fail to > push the patches they want for release! > durandal_1707: good point, we should look at doing another 5.1.x > release and a 6.0.x release. > > noone mentioned 5.1.x and 6.0.x to me before > > anyway, ill try to make releases from all maintained branches, > > and will branch 6.1 as soon as Lynne or others say everything is ready. > > thx > It's never too late to make a release. If we do a release now, nothing's stopping us from doing a 7.0 and getting back on track with releases every two months or so, like the plan was. 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec, Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to have a release before all this lands. I think the tree is in a pretty good state ATM, you should go ahead and branch if you're comfortable with it as well. >>> >>> branch made >>> >> >> Thanks. I'll get a blog post ready for the transform work, as kierank wanted >> to post something, >> and if users can know to who to point fingers to in case it degrades >> performance on RPI1 devices. >> >> Let's aim for a release by Sunday next week. That should give everyone enough time to backport fixes they want in. >>> >>> I would aim for 1-3 weeks (when code and developers are ready) >>> dont want to aim for a specific day, better pick a day when everything is >>> fine >>> not too many distractions, ... >>> >>> Or is there something that favors us to be before a specific date ? >>> >> >> Not really a reason, Sunday is just an optimistic date to aim for. >> If there are no big fixes to backport to the branch, I think we can target >> it. >> > > The nlmeans_vulkan patch I just sent is the last patch I'd like to have in > 6.1. > Does anyone else have any patches they would like in 6.1? > Pushed the 2 patches. Michael, do you think you can tag the release late tonight? No one has said anything yet. I'll write release notes for the website by then as well. ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/evc_parse: Check num_remaining_tiles_in_slice_minus1
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 On Behalf Of
> Michael Niedermayer
> Sent: piątek, 27 października 2023 21:43
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] avcodec/evc_parse: Check
> num_remaining_tiles_in_slice_minus1
>
> On Fri, Oct 27, 2023 at 10:07:38AM +0200, Dawid Kozinski/Multimedia (PLT)
> /SRPOL/Staff Engineer/Samsung Electronics wrote:
> >
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Michael Niedermayer
> > > Sent: czwartek, 5 października 2023 00:59
> > > To: FFmpeg development discussions and patches
> > >
> > > Subject: [FFmpeg-devel] [PATCH 2/4] avcodec/evc_parse: Check
> > > num_remaining_tiles_in_slice_minus1
> > >
> > > Fixes: out of array access
> > > Fixes: 62467/clusterfuzz-testcase-minimized-
> > > ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-6092990982258688
> > >
> > > Found-by: continuous fuzzing process
> > > https://protect2.fireeye.com/v1/url?k=10fdc12a-701f5c77-10fc4a65-
> > > 000babd9f1ba-c93ee30773aca891&q=1&e=409cddd0-bda7-445c-b76b-
> > > 1caf069ec3f8&u=https%3A%2F%2Fgithub.com%2Fgoogle%2Foss-
> > > fuzz%2Ftree%2Fmaster%2Fprojects%2Fffmpeg
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavcodec/evc_parse.c | 8 ++--
> > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c index
> > > bd3a4416f2d..5ab33166cf3 100644
> > > --- a/libavcodec/evc_parse.c
> > > +++ b/libavcodec/evc_parse.c
> > > @@ -58,8 +58,12 @@ int ff_evc_parse_slice_header(GetBitContext *gb,
> > > EVCParserSliceHeader *sh,
> > > if (!sh->arbitrary_slice_flag)
> > > sh->last_tile_id = get_bits(gb, pps->tile_id_len_minus1 + 1);
> > > else {
> > > -sh->num_remaining_tiles_in_slice_minus1 =
> > get_ue_golomb_long(gb);
> > > -num_tiles_in_slice = sh->num_remaining_tiles_in_slice_minus1
> > + 2;
> > > +unsigned num_remaining_tiles_in_slice_minus1 =
> > > get_ue_golomb_long(gb);
> > > +if (num_remaining_tiles_in_slice_minus1 >
> > > + EVC_MAX_TILE_ROWS *
> > > EVC_MAX_TILE_COLUMNS - 2)
> > > +return AVERROR_INVALIDDATA;
> > > +
> > > +num_tiles_in_slice = num_remaining_tiles_in_slice_minus1 + 2;
> > > +sh->num_remaining_tiles_in_slice_minus1 =
> > > + num_remaining_tiles_in_slice_minus1;
> > > for (int i = 0; i < num_tiles_in_slice - 1; ++i)
> > > sh->delta_tile_id_minus1[i] = get_ue_golomb_long(gb);
> > > }
> > > --
> > > 2.17.1
> > >
> >
> > Reviewed and tested. It can be merged.
>
> will apply
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Homeopathy is like voting while filling the ballot out with transparent ink.
> Sometimes the outcome one wanted occurs. Rarely its worse than filling out a
> ballot properly.
___
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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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, -- 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".
Re: [FFmpeg-devel] [RFC] Release 6.1
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 Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: >> >>> It's been a while since we've had a release, and we've had >>> a lot of new features in. >>> We did say we would make releases more often, and I think >>> it's about time we have a new release. >>> >>> Anything anyone wants to have merged or should we branch >>> off 6.1 in a few days? >>> >> >> Whats the status of this ? >> I can branch 6.1 anytime >> >> It was just that jb told me >> "6.1 opportunity is gone. >> We're too late on the schedule, and noone had time to work on it, so it >> is wiser to target 7.0 in January" >> >> but now i see on IRC >> make a damn release already >> j-b: drop MiNi from release maintership and nominate >> Lynne >> I pledge to bring back /slap IRC messages to those who fail to >> push the patches they want for release! >> durandal_1707: good point, we should look at doing another 5.1.x >> release and a 6.0.x release. >> >> noone mentioned 5.1.x and 6.0.x to me before >> >> anyway, ill try to make releases from all maintained branches, >> >> and will branch 6.1 as soon as Lynne or others say everything is ready. >> >> thx >> > > It's never too late to make a release. If we do a release now, nothing's > stopping > us from doing a 7.0 and getting back on track with releases every two > months or so, > like the plan was. > > 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) > AAC+fixes, D3D12 hwdec, > Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a > good idea to > have a release before all this lands. > > I think the tree is in a pretty good state ATM, you should go ahead and > branch if you're > comfortable with it as well. > branch made >>> >>> Thanks. I'll get a blog post ready for the transform work, as kierank >>> wanted to post something, >>> and if users can know to who to point fingers to in case it degrades >>> performance on RPI1 devices. >>> >>> > Let's aim for a release by Sunday next week. That should give everyone > enough time to > backport fixes they want in. > I would aim for 1-3 weeks (when code and developers are ready) dont want to aim for a specific day, better pick a day when everything is fine not too many distractions, ... Or is there something that favors us to be before a specific date ? >>> >>> Not really a reason, Sunday is just an optimistic date to aim for. >>> If there are no big fixes to backport to the branch, I think we can target >>> it. >>> >> >> The nlmeans_vulkan patch I just sent is the last patch I'd like to have in >> 6.1. >> Does anyone else have any patches they would like in 6.1? 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. >> > > Pushed the 2 patches. > > Michael, do you think you can tag the release late tonight? > No one has said anything yet. > I'll write release notes for the website by then as well. > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [RFC] Release 6.1
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 ___ 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".
Re: [FFmpeg-devel] [PATCH 40/42] avcodec/hevcdec: Switch to ProgressFrames
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 | 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 deletions(-) Looks 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".
Re: [FFmpeg-devel] [PATCH 41/42] avcodec/pngdec: Switch to ProgressFrames
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 +++-- > 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-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 42/42] avcodec/ffv1dec: Switch to ProgressFrames
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 - > libavcodec/ffv1.h| 4 +-- > libavcodec/ffv1dec.c | 83 +++- > 3 files changed, 37 insertions(+), 51 deletions(-) Looks 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".
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_tpad: fix check for drawing initialization
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 well and for better > readability and maintainability break the check out into its own > helper. > > Fixes a regression from 86b252ea9dee18006910e30646ad1067f2d1323f > Fix #10621 > --- > libavfilter/vf_tpad.c | 13 + > 1 file changed, 9 insertions(+), 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".
Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: Remove spec-incompliant inverse quantisation
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 > > > > last bit of the last coefficient be toggled so that the sum > > > > of all coefficients is odd; both our decoder and encoder > > > > did this only if the bitexact flag has been set (although > > > > stuff like this should be behind AV_CODEC_FLAG2_FAST). > > > > This patch changes this by removing the spec-incompliant > > > > functions. > > > > > > This commit message should include benchamarks documenting the speed loss > > > (of the unquantize, the IDCT and overall) > > > It is expected that the speed of some IDCTs will be impacted negativly > > > as the non zero terms will prevent the skiping of some significant code > > > > > > as well as information about how much PSNR improves (to the encoder input) > > > > > > Also the change is a +-1 in one spot before the IDCT, the IDCT is not > > > bitexactly > > > specified in MPEG-2 so one could think of this as a > > > correct implementation followed by a IDCT that was sometimes +-1 off > > > instead of spec non compliance > > > > > > 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. > > There was an argument presented. I see no argument for why the code in question is useful, can you point to the exact text? > That argument could be challenged or otherwise explained why it more > important to have this always behave like with bitexact. > > This could lead to "OK, I think removal is better" or if not benchmarks > could lead to one or the other decision. > > Saying the burden is on whoever wants to keep the code sounds like a way > for arbitrary code removal. While I agree getting rid of code can be a good > thing, this would definitely take it too far. All code is a maintenance burden, therefore all code should have a reason for its presence in the codebase, otherwise it should be removed. -- 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".
Re: [FFmpeg-devel] [PATCH v28 1/2] avcodec/evc_encoder: Provided support for EVC encoder
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 Profile" and the "Main Profile".
For the encoder and decoder, libraries can be built for both main and baseline
profiles as follows:
cmake .. -DSET_PROF=BASE && make && make install
cmake .. -DSET_PROF=MAIN && make && make install
If you like, you can build RPM or DEB packages for both profiles:
cmake .. -DSET_PROF=BASE && make -j8 && cpack -G RPM
cmake .. -DSET_PROF=MAIN && make -j8 && cpack -G RPM
Links to the external libraries:
https://github.com/mpeg5/xeve
https://github.com/mpeg5/xevd
Could you please clarify what exactly you need?
What changes do you expect on the FFmpeg implementation side?
Best regards
Dawid Koziński
> -Original Message-
> From: ffmpeg-devel On Behalf Of Neal
> Gompa
> Sent: środa, 18 października 2023 15:16
> To: FFmpeg development discussions and patches
> Cc: Dawid Kozinski ; d.frankie...@samsung.com
> Subject: Re: [FFmpeg-devel] [PATCH v28 1/2] avcodec/evc_encoder: Provided
> support for EVC encoder
>
> On Tue, Sep 19, 2023 at 7:34 AM Dawid Kozinski
> wrote:
> >
> > - Added EVC encoder wrapper
> > - Changes in project configuration file and libavcodec Makefile
> > - Added documentation for xeve wrapper
> >
>
> Can you make this work with just the baseline library too? For Fedora and
> EPEL,
> we can only ship the xev{e,d} baseline libraries.
>
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://protect2.fireeye.com/v1/url?k=4d63ea49-2c1e0235-4d626106-
> 74fe485cc33c-e991741fdaee2af8&q=1&e=66f2f6aa-977c-4a9e-be0a-
> 8a9453d9bf19&u=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp
> eg-devel
>
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".
___
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".
Re: [FFmpeg-devel] [PATCH 4/4] lavu/log: do not assume AVClass.item_name is always set
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://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 08/24] fftools/ffmpeg_filter: remove an unnecessary sub2video_push_ref() call
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 next sub2video frame. 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). -- 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".
Re: [FFmpeg-devel] [PATCH 08/24] fftools/ffmpeg_filter: remove an unnecessary sub2video_push_ref() call
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 a solution, won't we? (I hope you do not consider removing a feature that people have been using for years an option.) I can suggest this: have demuxer code emit virtual subtitles packets to trigger the sending of the heartbeat frames. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 18/24] fftools/ffmpeg: add thread-aware transcode scheduling infrastructure
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_arg);
> > +if (ret < 0)
> > +av_log(task->func_arg, AV_LOG_ERROR,
> > + "Task finished with error code: %d (%s)\n", ret,
> > av_err2str(ret));
> > +
> > +switch (task->node.type) {
> > +case SCH_NODE_TYPE_DEMUX: err = demux_done (sch,
> > task->node.idx); break;
> > +case SCH_NODE_TYPE_MUX: err = mux_done (sch,
> > task->node.idx); break;
> > +case SCH_NODE_TYPE_DEC: err = dec_done (sch,
> > task->node.idx); break;
> > +case SCH_NODE_TYPE_ENC: err = enc_done (sch,
> > task->node.idx); break;
> > +case SCH_NODE_TYPE_FILTER_IN: err = filter_done(sch,
> > task->node.idx); break;
>
> task->node.type seems to be constant, so wouldn't it be faster,
This is only called once per node, so I don't think performance
considerations make sense.
> or at least cleaner looking here, to use a function pointer assigned
> in task_init()?
That just moves the switch to a different place, adds an extra function
pointer, and makes it less clear what is being called, so I don't see
how it's an improvement.
That said, I do have some vague thoughts about abstracting away some
node-type specific things, but I'd rather leave that for later.
--
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".
[FFmpeg-devel] [PATCH v2 18/24] fftools/ffmpeg: add thread-aware transcode scheduling infrastructure
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 order to register the
individual components (demuxers/decoders/filtergraphs/encoders/muxers)
with the scheduler
The scheduler is not actually used as of this commit, so it should not
result in any change in behavior. That will change in future commits.
---
fftools/Makefile |1 +
fftools/ffmpeg.c | 18 +-
fftools/ffmpeg.h | 24 +-
fftools/ffmpeg_dec.c | 10 +-
fftools/ffmpeg_demux.c| 46 +-
fftools/ffmpeg_enc.c | 13 +-
fftools/ffmpeg_filter.c | 37 +-
fftools/ffmpeg_mux.c | 17 +-
fftools/ffmpeg_mux.h | 11 +
fftools/ffmpeg_mux_init.c | 85 +-
fftools/ffmpeg_opt.c | 22 +-
fftools/ffmpeg_sched.c| 2072 +
fftools/ffmpeg_sched.h| 461 +
13 files changed, 2761 insertions(+), 56 deletions(-)
create mode 100644 fftools/ffmpeg_sched.c
create mode 100644 fftools/ffmpeg_sched.h
diff --git a/fftools/Makefile b/fftools/Makefile
index 56820e6bc8..d6a8913a7f 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -18,6 +18,7 @@ OBJS-ffmpeg += \
fftools/ffmpeg_mux.o\
fftools/ffmpeg_mux_init.o \
fftools/ffmpeg_opt.o\
+fftools/ffmpeg_sched.o \
fftools/objpool.o \
fftools/sync_queue.o\
fftools/thread_queue.o \
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index f2293e0250..1a58bf98cf 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -99,6 +99,7 @@
#include "cmdutils.h"
#include "ffmpeg.h"
+#include "ffmpeg_sched.h"
#include "ffmpeg_utils.h"
#include "sync_queue.h"
@@ -1123,7 +1124,7 @@ static int transcode_step(OutputStream *ost, AVPacket
*demux_pkt)
/*
* The following code is the main loop of the file converter
*/
-static int transcode(int *err_rate_exceeded)
+static int transcode(Scheduler *sch, int *err_rate_exceeded)
{
int ret = 0, i;
InputStream *ist;
@@ -1261,6 +1262,8 @@ static int64_t getmaxrss(void)
int main(int argc, char **argv)
{
+Scheduler *sch = NULL;
+
int ret, err_rate_exceeded;
BenchmarkTimeStamps ti;
@@ -1278,8 +1281,14 @@ int main(int argc, char **argv)
show_banner(argc, argv, options);
+sch = sch_alloc();
+if (!sch) {
+ret = AVERROR(ENOMEM);
+goto finish;
+}
+
/* parse options and open all input/output files */
-ret = ffmpeg_parse_options(argc, argv);
+ret = ffmpeg_parse_options(argc, argv, sch);
if (ret < 0)
goto finish;
@@ -1297,7 +1306,7 @@ int main(int argc, char **argv)
}
current_time = ti = get_benchmark_time_stamps();
-ret = transcode(&err_rate_exceeded);
+ret = transcode(sch, &err_rate_exceeded);
if (ret >= 0 && do_benchmark) {
int64_t utime, stime, rtime;
current_time = get_benchmark_time_stamps();
@@ -1317,5 +1326,8 @@ finish:
ret = 0;
ffmpeg_cleanup(ret);
+
+sch_free(&sch);
+
return ret;
}
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index c954ed5ebf..5833f85ab5 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -27,6 +27,7 @@
#include
#include "cmdutils.h"
+#include "ffmpeg_sched.h"
#include "sync_queue.h"
#include "libavformat/avformat.h"
@@ -713,7 +714,8 @@ int parse_and_set_vsync(const char *arg, int *vsync_var,
int file_idx, int st_id
int check_filter_outputs(void);
int filtergraph_is_simple(const FilterGraph *fg);
int init_simple_filtergraph(InputStream *ist, OutputStream *ost,
-char *graph_desc);
+char *graph_desc,
+Scheduler *sch, unsigned sch_idx_enc);
int init_complex_filtergraph(FilterGraph *fg);
int copy_av_subtitle(AVSubtitle *dst, const AVSubtitle *src);
@@ -736,7 +738,8 @@ void ifilter_sub2video_heartbeat(InputFilter *ifilter,
int64_t pts, AVRational t
*/
int ifilter_parameters_from_dec(InputFilter *ifilter, const AVCodecContext
*dec);
-int ofilter_bind_ost(OutputFilter *ofilter, OutputStream *ost);
+int ofilter_bind_ost(OutputFilter *ofilter, OutputStream *ost,
+ unsigned sched_idx_enc);
/**
* Create a new filtergraph in the global filtergraph list.
@@ -744,7 +747,7 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost);
* @param graph_desc Graph description; an av_malloc()ed string, filtergraph
* takes ownership of it.
*/
-int fg_create(FilterGraph **pfg, char *graph_desc);
+int fg_create(FilterGraph **pfg, char *graph_desc, Scheduler *sch);
void fg_free(FilterGraph **pfg);
@@ -768,7 +771,7 @@ void fg_send_command(FilterGraph *fg, double time, const
char *target,
*/
int reap_filte
Re: [FFmpeg-devel] [PATCH 18/24] fftools/ffmpeg: add thread-aware transcode scheduling infrastructure
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 minimal > > integration with the rest of the program: > > * allocating and freeing the scheduler > > * passing it throughout the call stack in order to register the > > individual components (demuxers/decoders/filtergraphs/encoders/muxers) > > with the scheduler > > > > The scheduler is not actually used as of this commit, so it should not > > result in any change in behavior. That will change in future commits. > > --- > > fftools/Makefile |1 + > > fftools/ffmpeg.c | 18 +- > > fftools/ffmpeg.h | 24 +- > > fftools/ffmpeg_dec.c | 10 +- > > fftools/ffmpeg_demux.c| 46 +- > > fftools/ffmpeg_enc.c | 13 +- > > fftools/ffmpeg_filter.c | 37 +- > > fftools/ffmpeg_mux.c | 17 +- > > fftools/ffmpeg_mux.h | 11 + > > fftools/ffmpeg_mux_init.c | 82 +- > > fftools/ffmpeg_opt.c | 22 +- > > fftools/ffmpeg_sched.c| 2072 + > > fftools/ffmpeg_sched.h| 461 + > > 13 files changed, 2758 insertions(+), 56 deletions(-) > > create mode 100644 fftools/ffmpeg_sched.c > > create mode 100644 fftools/ffmpeg_sched.h > > Is fate intended to pass for each point in the patchset ? 19-24 will be squashed on push, so 19-23 are not supposed to pass fate, work at all, or even build. All other points are supposed to pass fate. > > make -j32 fate-h264-skip-nointra > seems to fail after this fixed Thanks, -- 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".
Re: [FFmpeg-devel] [PATCH 14/24] fftools/ffmpeg_mux: move bitstream filtering to the muxer thread
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 file changed, 67 insertions(+), 45 deletions(-)
> >
> > diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
> > index 82352b7981..57fb8a8413 100644
> > --- a/fftools/ffmpeg_mux.c
> > +++ b/fftools/ffmpeg_mux.c
> > @@ -207,6 +207,67 @@ static int sync_queue_process(Muxer *mux, OutputStream
> > *ost, AVPacket *pkt, int
> > return 0;
> > }
> >
> > +/* apply the output bitstream filters */
> > +static int mux_packet_filter(Muxer *mux, OutputStream *ost,
> > + AVPacket *pkt, int *stream_eof)
> > +{
> > +MuxStream *ms = ms_from_ost(ost);
> > +const char *err_msg;
> > +int ret = 0;
> > +
> > +if (ms->bsf_ctx) {
> > +int bsf_eof = 0;
> > +
> > +if (pkt)
> > +av_packet_rescale_ts(pkt, pkt->time_base,
> > ms->bsf_ctx->time_base_in);
> > +
> > +ret = av_bsf_send_packet(ms->bsf_ctx, pkt);
> > +if (ret < 0) {
>
> Unrelated to this patch, but this should probably include a comment
> about the reason we're not checking for EAGAIN, like we do for
> avcodec_send_packet().
Isn't the situation pretty much the same here - seeing EAGAIN would be a
bug?
--
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".
[FFmpeg-devel] [PATCH v2 10/24] fftools/ffmpeg_filter: move filtering to a separate thread
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 are also moved to threads and a thread-aware scheduler is
added.
---
Thanks for the report, fixed.
---
fftools/ffmpeg.h| 9 +-
fftools/ffmpeg_dec.c| 39 +-
fftools/ffmpeg_filter.c | 825 ++--
3 files changed, 730 insertions(+), 143 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 41935d39d5..9852df8320 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -80,6 +80,14 @@ enum HWAccelID {
HWACCEL_GENERIC,
};
+enum FrameOpaque {
+FRAME_OPAQUE_REAP_FILTERS = 1,
+FRAME_OPAQUE_CHOOSE_INPUT,
+FRAME_OPAQUE_SUB_HEARTBEAT,
+FRAME_OPAQUE_EOF,
+FRAME_OPAQUE_SEND_COMMAND,
+};
+
typedef struct HWDevice {
const char *name;
enum AVHWDeviceType type;
@@ -728,7 +736,6 @@ FrameData *frame_data(AVFrame *frame);
int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame, int
keep_reference);
int ifilter_send_eof(InputFilter *ifilter, int64_t pts, AVRational tb);
-int ifilter_sub2video(InputFilter *ifilter, const AVFrame *frame);
void ifilter_sub2video_heartbeat(InputFilter *ifilter, int64_t pts, AVRational
tb);
/**
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index 517d6b3ced..b60bad1220 100644
--- a/fftools/ffmpeg_dec.c
+++ b/fftools/ffmpeg_dec.c
@@ -147,11 +147,12 @@ fail:
static int send_frame_to_filters(InputStream *ist, AVFrame *decoded_frame)
{
-int i, ret;
+int i, ret = 0;
-av_assert1(ist->nb_filters > 0); /* ensure ret is initialized */
for (i = 0; i < ist->nb_filters; i++) {
-ret = ifilter_send_frame(ist->filters[i], decoded_frame, i <
ist->nb_filters - 1);
+ret = ifilter_send_frame(ist->filters[i], decoded_frame,
+ i < ist->nb_filters - 1 ||
+ ist->dec->type == AVMEDIA_TYPE_SUBTITLE);
if (ret == AVERROR_EOF)
ret = 0; /* ignore */
if (ret < 0) {
@@ -380,15 +381,6 @@ static int video_frame_process(InputStream *ist, AVFrame
*frame)
return 0;
}
-static void sub2video_flush(InputStream *ist)
-{
-for (int i = 0; i < ist->nb_filters; i++) {
-int ret = ifilter_sub2video(ist->filters[i], NULL);
-if (ret != AVERROR_EOF && ret < 0)
-av_log(NULL, AV_LOG_WARNING, "Flush the frame error.\n");
-}
-}
-
static int process_subtitle(InputStream *ist, AVFrame *frame)
{
Decoder *d = ist->decoder;
@@ -426,14 +418,9 @@ static int process_subtitle(InputStream *ist, AVFrame
*frame)
if (!subtitle)
return 0;
-for (int i = 0; i < ist->nb_filters; i++) {
-ret = ifilter_sub2video(ist->filters[i], frame);
-if (ret < 0) {
-av_log(ist, AV_LOG_ERROR, "Error sending a subtitle for filtering:
%s\n",
- av_err2str(ret));
-return ret;
-}
-}
+ret = send_frame_to_filters(ist, frame);
+if (ret < 0)
+return ret;
subtitle = (AVSubtitle*)frame->buf[0]->data;
if (!subtitle->num_rects)
@@ -824,14 +811,10 @@ finish:
return ret;
// signal EOF to our downstreams
-if (ist->dec->type == AVMEDIA_TYPE_SUBTITLE)
-sub2video_flush(ist);
-else {
-ret = send_filter_eof(ist);
-if (ret < 0) {
-av_log(NULL, AV_LOG_FATAL, "Error marking filters as finished\n");
-return ret;
-}
+ret = send_filter_eof(ist);
+if (ret < 0) {
+av_log(NULL, AV_LOG_FATAL, "Error marking filters as finished\n");
+return ret;
}
return AVERROR_EOF;
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index f0b8e01f5c..9030cc656e 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -21,6 +21,8 @@
#include
#include "ffmpeg.h"
+#include "ffmpeg_utils.h"
+#include "thread_queue.h"
#include "libavfilter/avfilter.h"
#include "libavfilter/buffersink.h"
@@ -53,12 +55,50 @@ typedef struct FilterGraphPriv {
int is_meta;
int disable_conversions;
+int nb_inputs_bound;
+int nb_outputs_bound;
+
const char *graph_desc;
// frame for temporarily holding output from the filtergraph
AVFrame *frame;
// frame for sending output to the encoder
AVFrame *frame_enc;
+
+pthread_tthread;
+/**
+ * Queue for sending frames from the main thread to the filtergraph. Has
+ * nb_inputs+1 streams - the first nb_inputs stream correspond to
+ * filtergraph inputs. Frames on those streams may have their opaque set to
+ * - FRAME_OPAQUE_EOF: frame contains no data, but pts+timebase of the
+ * EOF event for the correspondint stream. Will be immediately followed
by
+ * this str
Re: [FFmpeg-devel] [PATCH] ffmpeg CLI multithreading
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 subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 14/24] fftools/ffmpeg_mux: move bitstream filtering to the muxer thread
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 ++-
1 file changed, 67 insertions(+), 45 deletions(-)
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 82352b7981..57fb8a8413 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -207,6 +207,67 @@ static int sync_queue_process(Muxer *mux, OutputStream
*ost, AVPacket *pkt, int
return 0;
}
+/* apply the output bitstream filters */
+static int mux_packet_filter(Muxer *mux, OutputStream *ost,
+ AVPacket *pkt, int *stream_eof)
+{
+MuxStream *ms = ms_from_ost(ost);
+const char *err_msg;
+int ret = 0;
+
+if (ms->bsf_ctx) {
+int bsf_eof = 0;
+
+if (pkt)
+av_packet_rescale_ts(pkt, pkt->time_base,
ms->bsf_ctx->time_base_in);
+
+ret = av_bsf_send_packet(ms->bsf_ctx, pkt);
+if (ret < 0) {
Unrelated to this patch, but this should probably include a comment
about the reason we're not checking for EAGAIN, like we do for
avcodec_send_packet().
Isn't the situation pretty much the same here - seeing EAGAIN would be a
bug?
Yes, and a similar comment here is a good idea as people may use
ffmpeg.c as a reference implementation for our APIs.
___
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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 to suggest further people, please do so in this thread ASAP. IMHO the question of the relation of the list of people who could vote in the last GA vote and the people who where in the general assembly in 2020 should be awnsered before further votes. https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html 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 important to you!) The presumed 2020 General assembly as well as people who have subtantial contributions over the lifetime of the project where the source of this list 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 since forever, maintains 15 things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits in FFmpeg) Moritz Barsnick(Member of the 2020 GA but was not on jbs list) Lauri Kasanen (Linux / PowerPC maintainer) Dale Curtis(14 commits in 2020 was in the 2020-GA) Alexander Strasser (Root admin, just recently reported that he could not vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) Huiwen Ren (8 matches in the codebase of his name, avs2* and related things maintainer) Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of hostility) Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the 2020-GA but not on jbs list) Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 entries in MAINTAINERs, 25 in copyrights) Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to various bits of code, last active in git in 2020) John Stebbins (over 100 commits in FFmpeg, last active in git in 2020, 1 copyright match) Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 commits in FFmpeg) Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name in the source, last commit May 2023) Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last commit in Oct 2023, 49 matches for his name in the codebase) Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in MAINTAINERs, 70 copyright line matches) Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, 4 copyrights, last commit in Jul 2023) Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, 22 copyright matches) Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 14/24] fftools/ffmpeg_mux: move bitstream filtering to the muxer thread
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 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
> >>> index 82352b7981..57fb8a8413 100644
> >>> --- a/fftools/ffmpeg_mux.c
> >>> +++ b/fftools/ffmpeg_mux.c
> >>> @@ -207,6 +207,67 @@ static int sync_queue_process(Muxer *mux,
> >>> OutputStream *ost, AVPacket *pkt, int
> >>>return 0;
> >>>}
> >>>
> >>> +/* apply the output bitstream filters */
> >>> +static int mux_packet_filter(Muxer *mux, OutputStream *ost,
> >>> + AVPacket *pkt, int *stream_eof)
> >>> +{
> >>> +MuxStream *ms = ms_from_ost(ost);
> >>> +const char *err_msg;
> >>> +int ret = 0;
> >>> +
> >>> +if (ms->bsf_ctx) {
> >>> +int bsf_eof = 0;
> >>> +
> >>> +if (pkt)
> >>> +av_packet_rescale_ts(pkt, pkt->time_base,
> >>> ms->bsf_ctx->time_base_in);
> >>> +
> >>> +ret = av_bsf_send_packet(ms->bsf_ctx, pkt);
> >>> +if (ret < 0) {
> >>
> >> Unrelated to this patch, but this should probably include a comment
> >> about the reason we're not checking for EAGAIN, like we do for
> >> avcodec_send_packet().
> >
> > Isn't the situation pretty much the same here - seeing EAGAIN would be a
> > bug?
>
> Yes, and a similar comment here is a good idea as people may use
> ffmpeg.c as a reference implementation for our APIs.
Right, then certainly there should be a comment or maybe even a check
like for decoding.
--
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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 since forever, maintains 15 > things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits > in FFmpeg) > Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > Lauri Kasanen (Linux / PowerPC maintainer) > Dale Curtis(14 commits in 2020 was in the 2020-GA) > Alexander Strasser (Root admin, just recently reported that he could not > vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) > foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) > Huiwen Ren (8 matches in the codebase of his name, avs2* and > related things maintainer) > Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > hostility) > Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the > 2020-GA but not on jbs list) > Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 > entries in MAINTAINERs, 25 in copyrights) > Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to > various bits of code, last active in git in 2020) > John Stebbins (over 100 commits in FFmpeg, last active in git in > 2020, 1 copyright match) > Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) > Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > commits in FFmpeg) > Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name > in the source, last commit May 2023) > Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last > commit in Oct 2023, 49 matches for his name in the codebase) > Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in > MAINTAINERs, 70 copyright line matches) > Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, > 4 copyrights, last commit in Jul 2023) > Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, > 22 copyright matches) > Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) > just noting some people in the list have cut ties with this project and would much rather not be involved in anything related to ffmpeg - as a rule of thumb it's probably safe to omit inactive developers and inactive founders from the list, in my opinion -- Vittorio ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 are part of the infra teams and packaging; seem sane to add to the ballot. But the others seem totally inactive in this community, even if they were added to MAINTAINERS file a long time ago. And there are people who don't contribute, because their corporate sponsor is not employing them anymore. Best, -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [ANN] Poll Results: GA voters list updates
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? > > I'm pretty sure I could vote in 2020. Or am I just missing something? As per the rules: > Additional members are added to the General Assembly through a vote > after proposal by a member of the General Assembly. They are part of > the 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/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 GA candidate I see proposed so far is Ronald. If anyone > > wants to suggest further people, please do so in this thread ASAP. > > IMHO the question of the relation of the list of people who could vote > in the last GA vote and the people who where in the general assembly > in 2020 should be awnsered before further votes. > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html 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. Do you dispute that? > 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 important to you!) > > The presumed 2020 General assembly as well as people who have subtantial > contributions over the lifetime of the project where the source of this list > Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) He actually is in the GA, but his Intel mailbox bounces. > 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 since forever, maintains 15 > things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits in > FFmpeg) > Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > Lauri Kasanen (Linux / PowerPC maintainer) > Dale Curtis(14 commits in 2020 was in the 2020-GA) > Alexander Strasser (Root admin, just recently reported that he could not vote > even though he was in teh 2020-GA, 3 things in MAINTAINERs) > foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) > Huiwen Ren (8 matches in the codebase of his name, avs2* and related > things maintainer) > Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > hostility) > Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the > 2020-GA but not on jbs list) > Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 > entries in MAINTAINERs, 25 in copyrights) > Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to various > bits of code, last active in git in 2020) > John Stebbins (over 100 commits in FFmpeg, last active in git in 2020, 1 > copyright match) > Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > commits in FFmpeg) > Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name in > the source, last commit May 2023) > Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last commit > in Oct 2023, 49 matches for his name in the codebase) > Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in MAINTAINERs, > 70 copyright line matches) > Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, 4 > copyrights, last commit in Jul 2023) > Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, 22 > copyright matches) > Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) Sending voting emails to people who have not had any contact with the project for years, can be regarded as spamming. I think there should be some confirmation that these people are actually interested in having voting rights. -- 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 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. IMHO the question of the relation of the list of people who could vote in the last GA vote and the people who where in the general assembly in 2020 should be awnsered before further votes. https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html 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. Do you dispute that? 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 important to you!) The presumed 2020 General assembly as well as people who have subtantial contributions over the lifetime of the project where the source of this list Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) He actually is in the GA, but his Intel mailbox bounces. 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 since forever, maintains 15 things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits in FFmpeg) Moritz Barsnick(Member of the 2020 GA but was not on jbs list) Lauri Kasanen (Linux / PowerPC maintainer) Dale Curtis(14 commits in 2020 was in the 2020-GA) Alexander Strasser (Root admin, just recently reported that he could not vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) Huiwen Ren (8 matches in the codebase of his name, avs2* and related things maintainer) Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of hostility) Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the 2020-GA but not on jbs list) Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 entries in MAINTAINERs, 25 in copyrights) Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to various bits of code, last active in git in 2020) John Stebbins (over 100 commits in FFmpeg, last active in git in 2020, 1 copyright match) Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 commits in FFmpeg) Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name in the source, last commit May 2023) Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last commit in Oct 2023, 49 matches for his name in the codebase) Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in MAINTAINERs, 70 copyright line matches) Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, 4 copyrights, last commit in Jul 2023) Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, 22 copyright matches) Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) Sending voting emails to people who have not had any contact with the project for years, can be regarded as spamming. I think there should be some confirmation that these people are actually interested in having voting rights. Hendrik Leppkes and Reimar Döffinger are active, at least. I agree they should be in the GA. ___ 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".
[FFmpeg-devel] [PATCH 01/25] avfilter/formats: document ff_default_query_formats
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 index 4dce2d..d44890109e 100644 --- a/libavfilter/formats.h +++ b/libavfilter/formats.h @@ -198,6 +198,10 @@ void ff_channel_layouts_unref(AVFilterChannelLayouts **ref); void ff_channel_layouts_changeref(AVFilterChannelLayouts **oldref, AVFilterChannelLayouts **newref); +/** + * Sets all remaining unset filter lists for all inputs/outputs to their + * corresponding `ff_all_*()` lists. + */ av_warn_unused_result int ff_default_query_formats(AVFilterContext *ctx); -- 2.42.0 ___ 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".
[FFmpeg-devel] [RFC PATCH 00/25] YUVJ removal + filter negotiation
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 good, though, so please feel free to review them with scrutiny. I decided to combine YUV range negotiation with YUV colorspace negotiation. Several important points: 1. We now explicitly ignore YUV metadata for non-YUV (RGB/XYZ/PAL) formats, as these have no hope of being useful. In particular, we force the colorspace to AVCOL_SPC_RGB, mostly for sanity/consistency. 2. We currently continue treating GRAY formats as forced full range, which is the swscale status quo. I have a separate series that adds full range negotiation to grayscale formats, but it is out of scope of this already ominous series. It was a delicate balancing act to get the new filter negotiation API integrated into all core filters (in particular vf_scale and vf_buffersrc) while maintaining forward and backward compatibility and not breaking FATE, but I managed to find an order that works, by first adding support to vf_buffersrc to make sure accurate metadata is available downstream _before_ we insert any conversion filters. ___ 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".
[FFmpeg-devel] [PATCH 02/25] avfilter: always call ff_default_query_formats
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 filter in existence.
An alternative implementation of this commit would be to explicitly add
a `ff_default_query_formats` call at the end of every query_formats
function, but that would end up functionally equivalent to this change
while touching a whole lot more code paths for no reason.
As a bonus, eliminates some code/logic duplication from this function.
---
libavfilter/avfiltergraph.c | 39 -
1 file changed, 12 insertions(+), 27 deletions(-)
diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index 68daa93e61..625cbc022e 100644
--- a/libavfilter/avfiltergraph.c
+++ b/libavfilter/avfiltergraph.c
@@ -341,33 +341,21 @@ static int filter_check_formats(AVFilterContext *ctx)
static int filter_query_formats(AVFilterContext *ctx)
{
int ret;
-AVFilterFormats *formats;
-AVFilterChannelLayouts *chlayouts;
-enum AVMediaType type = ctx->inputs && ctx->inputs [0] ? ctx->inputs
[0]->type :
-ctx->outputs && ctx->outputs[0] ?
ctx->outputs[0]->type :
-AVMEDIA_TYPE_VIDEO;
-
-if ((ret = ctx->filter->formats.query_func(ctx)) < 0) {
-if (ret != AVERROR(EAGAIN))
-av_log(ctx, AV_LOG_ERROR, "Query format failed for '%s': %s\n",
- ctx->name, av_err2str(ret));
-return ret;
-}
-ret = filter_check_formats(ctx);
-if (ret < 0)
-return ret;
-formats = ff_all_formats(type);
-if ((ret = ff_set_common_formats(ctx, formats)) < 0)
-return ret;
-if (type == AVMEDIA_TYPE_AUDIO) {
-if ((ret = ff_set_common_all_samplerates(ctx)) < 0)
+if (ctx->filter->formats_state == FF_FILTER_FORMATS_QUERY_FUNC) {
+if ((ret = ctx->filter->formats.query_func(ctx)) < 0) {
+if (ret != AVERROR(EAGAIN))
+av_log(ctx, AV_LOG_ERROR, "Query format failed for '%s': %s\n",
+ ctx->name, av_err2str(ret));
return ret;
-chlayouts = ff_all_channel_layouts();
-if ((ret = ff_set_common_channel_layouts(ctx, chlayouts)) < 0)
+}
+
+ret = filter_check_formats(ctx);
+if (ret < 0)
return ret;
}
-return 0;
+
+return ff_default_query_formats(ctx);
}
static int formats_declared(AVFilterContext *f)
@@ -416,10 +404,7 @@ static int query_formats(AVFilterGraph *graph, void
*log_ctx)
AVFilterContext *f = graph->filters[i];
if (formats_declared(f))
continue;
-if (f->filter->formats_state == FF_FILTER_FORMATS_QUERY_FUNC)
-ret = filter_query_formats(f);
-else
-ret = ff_default_query_formats(f);
+ret = filter_query_formats(f);
if (ret < 0 && ret != AVERROR(EAGAIN))
return ret;
/* note: EAGAIN could indicate a partial success, not counted yet */
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 03/25] avfilter: add negotiation API for color space/range
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 full-range by swscale), we exclude them
from negotiation altogether for the time being, to get this API merged.
After filter negotiation is available, we can relax the
grayscale-is-forced-jpeg restriction again, when it will be more
feasible to do so without breaking a million test cases.
Note that this commit updates one FATE test as a consequence of the
sanity fallback for non-YUV formats. In particular, the test case now
writes rgb24(pc, gbr/unspecified/unspecified) to the matroska file,
instead of rgb24(unspecified/unspecified/unspecified) as before.
---
doc/APIchanges | 8 ++
libavfilter/avfilter.c | 19 -
libavfilter/avfilter.h | 28 ++
libavfilter/avfiltergraph.c | 166 +++-
libavfilter/formats.c | 122 +-
libavfilter/formats.h | 54
libavfilter/internal.h | 6 ++
libavfilter/vaapi_vpp.c | 4 +
libavfilter/version.h | 2 +-
libavfilter/video.c | 2 +
tests/ref/fate/shortest-sub | 4 +-
11 files changed, 405 insertions(+), 10 deletions(-)
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:
+2023-11-xx - xx - lavf 58.14.100 - avfilter.h formats.h
+ Add AVFilterFormatsConfig.color_spaces, AVFilterFormatsConfig.color_ranges,
+ AVFilterLink.colorspace, AVFilterLink.color_range, ff_all_color_spaces,
+ ff_all_color_ranges, ff_set_common_color_spaces, ff_set_common_color_ranges,
+ ff_set_common_color_spaces_from_list, ff_set_common_color_ranges_from_list,
+ ff_set_common_all_color_spaces, ff_set_common_all_color_ranges,
+ ff_formats_check_color_spaces, ff_formats_check_color_ranges.
+
2023-11-08 - xx - lavu 58.32.100 - channel_layout.h
Add AV_CH_LAYOUT_7POINT2POINT3 and AV_CHANNEL_LAYOUT_7POINT2POINT3.
Add AV_CH_LAYOUT_9POINT1POINT4_BACK and AV_CHANNEL_LAYOUT_9POINT1POINT4_BACK.
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index ab7782862a..77bfec00c5 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -185,6 +185,7 @@ int avfilter_link(AVFilterContext *src, unsigned srcpad,
link->type= src->output_pads[srcpad].type;
av_assert0(AV_PIX_FMT_NONE == -1 && AV_SAMPLE_FMT_NONE == -1);
link->format = -1;
+link->colorspace = AVCOL_SPC_UNSPECIFIED;
ff_framequeue_init(&link->fifo, &src->graph->internal->frame_queues);
return 0;
@@ -286,6 +287,12 @@ int avfilter_insert_filter(AVFilterLink *link,
AVFilterContext *filt,
if (link->outcfg.formats)
ff_formats_changeref(&link->outcfg.formats,
&filt->outputs[filt_dstpad_idx]->outcfg.formats);
+if (link->outcfg.color_spaces)
+ff_formats_changeref(&link->outcfg.color_spaces,
+
&filt->outputs[filt_dstpad_idx]->outcfg.color_spaces);
+if (link->outcfg.color_ranges)
+ff_formats_changeref(&link->outcfg.color_ranges,
+
&filt->outputs[filt_dstpad_idx]->outcfg.color_ranges);
if (link->outcfg.samplerates)
ff_formats_changeref(&link->outcfg.samplerates,
&filt->outputs[filt_dstpad_idx]->outcfg.samplerates);
@@ -730,6 +737,10 @@ static void free_link(AVFilterLink *link)
ff_formats_unref(&link->incfg.formats);
ff_formats_unref(&link->outcfg.formats);
+ff_formats_unref(&link->incfg.color_spaces);
+ff_formats_unref(&link->outcfg.color_spaces);
+ff_formats_unref(&link->incfg.color_ranges);
+ff_formats_unref(&link->outcfg.color_ranges);
ff_formats_unref(&link->incfg.samplerates);
ff_formats_unref(&link->outcfg.samplerates);
ff_channel_layouts_unref(&link->incfg.channel_layouts);
@@ -987,9 +998,11 @@ int ff_filter_frame(AVFilterLink *link, AVFrame *frame)
strcmp(link->dst->filter->name, "idet") &&
strcmp(link->dst->filter->name, "null") &&
strcmp(link->dst->filter->name, "scale")) {
-av_assert1(frame->format == link->format);
-av_assert1(frame->width == link->w);
-av_assert1(frame->height == link->h);
+av_assert1(frame->format== link->format);
+av_assert1(frame->width == link->w);
+av_assert1(frame->height== link->h);
+av_assert1(frame->colorspace== link->color_space);
+av_assert1(frame->color_range == link->color_range);
}
frame->sam
[FFmpeg-devel] [PATCH 04/25] fftools/ffmpeg_filter: don't clear buffersrc params
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 b7da105141..e699798897 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1400,11 +1400,8 @@ static int configure_input_video_filter(FilterGraph *fg,
InputFilter *ifilter,
int ret, pad_idx = 0;
int64_t tsoffset = 0;
AVBufferSrcParameters *par = av_buffersrc_parameters_alloc();
-
if (!par)
return AVERROR(ENOMEM);
-memset(par, 0, sizeof(*par));
-par->format = AV_PIX_FMT_NONE;
if (ist->dec_ctx->codec_type == AVMEDIA_TYPE_AUDIO) {
av_log(fg, AV_LOG_ERROR, "Cannot connect video filter to audio
input\n");
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 12/25] avfilter/vf_libplacebo: switch to colorspace negotiation API
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_libplacebo.c
@@ -882,6 +882,8 @@ static int output_frame(AVFilterContext *ctx, int64_t pts)
out->pts = pts;
out->width = outlink->w;
out->height = outlink->h;
+out->colorspace = outlink->colorspace;
+out->color_range = outlink->color_range;
if (s->fps.num)
out->duration = 1;
@@ -892,22 +894,11 @@ static int output_frame(AVFilterContext *ctx, int64_t pts)
out->color_trc = AVCOL_TRC_SMPTE2084;
}
-if (s->colorspace >= 0)
-out->colorspace = s->colorspace;
-if (s->color_range >= 0)
-out->color_range = s->color_range;
if (s->color_trc >= 0)
out->color_trc = s->color_trc;
if (s->color_primaries >= 0)
out->color_primaries = s->color_primaries;
-/* Sanity colorspace overrides */
-if (outdesc->flags & AV_PIX_FMT_FLAG_RGB) {
-out->colorspace = AVCOL_SPC_RGB;
-} else if (out->colorspace == AVCOL_SPC_RGB) {
-out->colorspace = AVCOL_SPC_UNSPECIFIED;
-}
-
changed_csp = ref->colorspace != out->colorspace ||
ref->color_range != out->color_range||
ref->color_trc != out->color_trc ||
@@ -1203,6 +1194,18 @@ static int libplacebo_query_format(AVFilterContext *ctx)
for (int i = 0; i < s->nb_inputs; i++)
RET(ff_formats_ref(infmts, &ctx->inputs[i]->outcfg.formats));
RET(ff_formats_ref(outfmts, &ctx->outputs[0]->incfg.formats));
+
+/* Set colorspace properties */
+RET(ff_formats_ref(ff_all_color_spaces(),
&ctx->inputs[0]->outcfg.color_spaces));
+RET(ff_formats_ref(ff_all_color_ranges(),
&ctx->inputs[0]->outcfg.color_ranges));
+
+outfmts = s->colorspace > 0 ? ff_make_formats_list_singleton(s->colorspace)
+: ff_all_color_spaces();
+RET(ff_formats_ref(outfmts, &ctx->outputs[0]->incfg.color_spaces));
+
+outfmts = s->color_range > 0 ?
ff_make_formats_list_singleton(s->color_range)
+ : ff_all_color_ranges();
+RET(ff_formats_ref(outfmts, &ctx->outputs[0]->incfg.color_ranges));
return 0;
fail:
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 14/25] avfilter/vf_format: re-use AVFilterList for pix_fmt parsing
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 several malloc
(ff_add_format) instead of a single malloc.
---
libavfilter/vf_format.c | 103 +---
1 file changed, 43 insertions(+), 60 deletions(-)
diff --git a/libavfilter/vf_format.c b/libavfilter/vf_format.c
index 1189bd61c2..b137e3075e 100644
--- a/libavfilter/vf_format.c
+++ b/libavfilter/vf_format.c
@@ -41,25 +41,48 @@ typedef struct FormatContext {
const AVClass *class;
char *pix_fmts;
-/**
- * pix_fmts parsed into AVPixelFormats and terminated with
- * AV_PIX_FMT_NONE
- */
-enum AVPixelFormat *formats;
+AVFilterFormats *formats; ///< parsed from `pix_fmts`
} FormatContext;
static av_cold void uninit(AVFilterContext *ctx)
{
FormatContext *s = ctx->priv;
-av_freep(&s->formats);
+ff_formats_unref(&s->formats);
+}
+
+static av_cold int invert_formats(AVFilterFormats **fmts,
+ AVFilterFormats *allfmts)
+{
+if (!allfmts)
+return AVERROR(ENOMEM);
+if (!*fmts) {
+/* empty fmt list means no restriction, regardless of filter type */
+ff_formats_unref(&allfmts);
+return 0;
+}
+
+for (int i = 0; i < allfmts->nb_formats; i++) {
+for (int j = 0; j < (*fmts)->nb_formats; j++) {
+if (allfmts->formats[i] == (*fmts)->formats[j]) {
+/* format is forbidden, remove it from allfmts list */
+memmove(&allfmts->formats[i], &allfmts->formats[i+1],
+(allfmts->nb_formats - (i+1)) *
sizeof(*allfmts->formats));
+allfmts->nb_formats--;
+i--; /* repeat loop with same idx */
+break;
+}
+}
+}
+
+ff_formats_unref(fmts);
+*fmts = allfmts;
+return 0;
}
static av_cold int init(AVFilterContext *ctx)
{
FormatContext *s = ctx->priv;
-char *cur, *sep;
-int nb_formats = 1;
-int i;
+enum AVPixelFormat pix_fmt;
int ret;
if (!s->pix_fmts) {
@@ -67,64 +90,24 @@ static av_cold int init(AVFilterContext *ctx)
return AVERROR(EINVAL);
}
-/* count the formats */
-cur = s->pix_fmts;
-while ((cur = strchr(cur, '|'))) {
-nb_formats++;
-if (*cur)
-cur++;
-}
-
-s->formats = av_malloc_array(nb_formats + 1, sizeof(*s->formats));
-if (!s->formats)
-return AVERROR(ENOMEM);
-
-/* parse the list of formats */
-cur = s->pix_fmts;
-for (i = 0; i < nb_formats; i++) {
+for (char *sep, *cur = s->pix_fmts; cur; cur = sep) {
sep = strchr(cur, '|');
-if (sep)
+if (sep && *sep)
*sep++ = 0;
-
-if ((ret = ff_parse_pixel_format(&s->formats[i], cur, ctx)) < 0)
+if ((ret = ff_parse_pixel_format(&pix_fmt, cur, ctx)) < 0 ||
+(ret = ff_add_format(&s->formats, pix_fmt)) < 0)
return ret;
-
-cur = sep;
}
-s->formats[nb_formats] = AV_PIX_FMT_NONE;
if (!strcmp(ctx->filter->name, "noformat")) {
-const AVPixFmtDescriptor *desc = NULL;
-enum AVPixelFormat *formats_allowed;
-int nb_formats_lavu = 0, nb_formats_allowed = 0;
-
-/* count the formats known to lavu */
-while ((desc = av_pix_fmt_desc_next(desc)))
-nb_formats_lavu++;
-
-formats_allowed = av_malloc_array(nb_formats_lavu + 1,
sizeof(*formats_allowed));
-if (!formats_allowed)
-return AVERROR(ENOMEM);
-
-/* for each format known to lavu, check if it's in the list of
- * forbidden formats */
-while ((desc = av_pix_fmt_desc_next(desc))) {
-enum AVPixelFormat pix_fmt = av_pix_fmt_desc_get_id(desc);
-
-for (i = 0; i < nb_formats; i++) {
-if (s->formats[i] == pix_fmt)
-break;
-}
-if (i < nb_formats)
-continue;
-
-formats_allowed[nb_formats_allowed++] = pix_fmt;
-}
-formats_allowed[nb_formats_allowed] = AV_PIX_FMT_NONE;
-av_freep(&s->formats);
-s->formats = formats_allowed;
+if ((ret = invert_formats(&s->formats,
ff_all_formats(AVMEDIA_TYPE_VIDEO))) < 0)
+return ret;
}
+/* hold on to a ref for the lifetime of the filter */
+if ((ret = ff_formats_ref(s->formats, &s->formats)) < 0)
+return ret;
+
return 0;
}
@@ -132,7 +115,7 @@ static int query_formats(AVFilterContext *ctx)
{
FormatContext *s = ctx->priv;
-return ff_set_common_formats_from_list(ctx, s->formats);
+return ff_set_common_formats(ctx, s->formats);
}
--
2.42.0
___
ffmpe
[FFmpeg-devel] [PATCH 13/25] avfilter/buffersink: add color space/range accessors
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..97b6de8276 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09 API changes, most recent first: +2023-11-xx - xx - lavf 58.15.100 - buffersink.h + Add av_buffersink_get_colorspace and av_buffersink_get_color_range. + 2023-11-xx - xx - lavf 58.14.100 - avfilter.h formats.h Add AVFilterFormatsConfig.color_spaces, AVFilterFormatsConfig.color_ranges, AVFilterLink.colorspace, AVFilterLink.color_range, ff_all_color_spaces, diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c index ca2af1bc07..8fb9ba0fa4 100644 --- a/libavfilter/buffersink.c +++ b/libavfilter/buffersink.c @@ -202,6 +202,8 @@ MAKE_AVFILTERLINK_ACCESSOR(AVRational , frame_rate ) MAKE_AVFILTERLINK_ACCESSOR(int , w ) MAKE_AVFILTERLINK_ACCESSOR(int , h ) MAKE_AVFILTERLINK_ACCESSOR(AVRational , sample_aspect_ratio) +MAKE_AVFILTERLINK_ACCESSOR(enum AVColorSpace, colorspace) +MAKE_AVFILTERLINK_ACCESSOR(enum AVColorRange, color_range) #if FF_API_OLD_CHANNEL_LAYOUT FF_DISABLE_DEPRECATION_WARNINGS diff --git a/libavfilter/buffersink.h b/libavfilter/buffersink.h index 64e08de53e..a9374b8b4f 100644 --- a/libavfilter/buffersink.h +++ b/libavfilter/buffersink.h @@ -117,6 +117,8 @@ AVRational av_buffersink_get_frame_rate (const AVFilterContext *c int av_buffersink_get_w (const AVFilterContext *ctx); int av_buffersink_get_h (const AVFilterContext *ctx); AVRational av_buffersink_get_sample_aspect_ratio (const AVFilterContext *ctx); +enum AVColorSpace av_buffersink_get_colorspace (const AVFilterContext *ctx); +enum AVColorRange av_buffersink_get_color_range(const AVFilterContext *ctx); int av_buffersink_get_channels(const AVFilterContext *ctx); #if FF_API_OLD_CHANNEL_LAYOUT diff --git a/libavfilter/version.h b/libavfilter/version.h index 7642b670d1..59330858bd 100644 --- a/libavfilter/version.h +++ b/libavfilter/version.h @@ -31,7 +31,7 @@ #include "version_major.h" -#define LIBAVFILTER_VERSION_MINOR 14 +#define LIBAVFILTER_VERSION_MINOR 15 #define LIBAVFILTER_VERSION_MICRO 100 -- 2.42.0 ___ 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".
[FFmpeg-devel] [PATCH 16/25] avfilter/vf_format: allow empty pix_fmts list
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.c b/libavfilter/vf_format.c
index d1bb9daa97..3a353bbb0d 100644
--- a/libavfilter/vf_format.c
+++ b/libavfilter/vf_format.c
@@ -91,11 +91,6 @@ static av_cold int init(AVFilterContext *ctx)
enum AVPixelFormat pix_fmt;
int ret;
-if (!s->pix_fmts) {
-av_log(ctx, AV_LOG_ERROR, "Empty output format string.\n");
-return AVERROR(EINVAL);
-}
-
for (char *sep, *cur = s->pix_fmts; cur; cur = sep) {
sep = strchr(cur, '|');
if (sep && *sep)
@@ -131,7 +126,7 @@ static av_cold int init(AVFilterContext *ctx)
}
/* hold on to a ref for the lifetime of the filter */
-if ((ret = ff_formats_ref(s->formats, &s->formats)) < 0 ||
+if (s->formats && (ret = ff_formats_ref(s->formats,
&s->formats)) < 0 ||
s->color_spaces && (ret = ff_formats_ref(s->color_spaces,
&s->color_spaces)) < 0 ||
s->color_ranges && (ret = ff_formats_ref(s->color_ranges,
&s->color_ranges)) < 0)
return ret;
@@ -144,7 +139,7 @@ static int query_formats(AVFilterContext *ctx)
FormatContext *s = ctx->priv;
int ret;
-if ((ret = ff_set_common_formats(ctx, s->formats)) < 0 ||
+if (s->formats && (ret = ff_set_common_formats(ctx, s->formats))
< 0 ||
s->color_spaces && (ret = ff_set_common_color_spaces(ctx,
s->color_spaces)) < 0 ||
s->color_ranges && (ret = ff_set_common_color_ranges(ctx,
s->color_ranges)) < 0)
return ret;
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 15/25] avfilter/vf_format: add color_ranges/spaces
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/doc/filters.texi b/doc/filters.texi
index 55a333680c..4599d575a6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14241,6 +14241,14 @@ It accepts the following parameters:
A '|'-separated list of pixel format names, such as
"pix_fmts=yuv420p|monow|rgb24".
+@item color_spaces
+A '|'-separated list of color space names, such as
+"color_spaces=bt709|bt470bg|bt2020nc".
+
+@item color_ranges
+A '|'-separated list of color rangee names, such as
+"color_spaces=tv|pc".
+
@end table
@subsection Examples
diff --git a/libavfilter/vf_format.c b/libavfilter/vf_format.c
index b137e3075e..d1bb9daa97 100644
--- a/libavfilter/vf_format.c
+++ b/libavfilter/vf_format.c
@@ -40,18 +40,24 @@
typedef struct FormatContext {
const AVClass *class;
char *pix_fmts;
+char *csps;
+char *ranges;
AVFilterFormats *formats; ///< parsed from `pix_fmts`
+AVFilterFormats *color_spaces; ///< parsed from `csps`
+AVFilterFormats *color_ranges; ///< parsed from `ranges`
} FormatContext;
static av_cold void uninit(AVFilterContext *ctx)
{
FormatContext *s = ctx->priv;
ff_formats_unref(&s->formats);
+ff_formats_unref(&s->color_spaces);
+ff_formats_unref(&s->color_ranges);
}
static av_cold int invert_formats(AVFilterFormats **fmts,
- AVFilterFormats *allfmts)
+ AVFilterFormats *allfmts)
{
if (!allfmts)
return AVERROR(ENOMEM);
@@ -99,13 +105,35 @@ static av_cold int init(AVFilterContext *ctx)
return ret;
}
+for (char *sep, *cur = s->csps; cur; cur = sep) {
+sep = strchr(cur, '|');
+if (sep && *sep)
+*sep++ = 0;
+if ((ret = av_color_space_from_name(cur)) < 0 ||
+(ret = ff_add_format(&s->color_spaces, ret)) < 0)
+return ret;
+}
+
+for (char *sep, *cur = s->ranges; cur; cur = sep) {
+sep = strchr(cur, '|');
+if (sep && *sep)
+*sep++ = 0;
+if ((ret = av_color_range_from_name(cur)) < 0 ||
+(ret = ff_add_format(&s->color_ranges, ret)) < 0)
+return ret;
+}
+
if (!strcmp(ctx->filter->name, "noformat")) {
-if ((ret = invert_formats(&s->formats,
ff_all_formats(AVMEDIA_TYPE_VIDEO))) < 0)
+if ((ret = invert_formats(&s->formats,
ff_all_formats(AVMEDIA_TYPE_VIDEO))) < 0 ||
+(ret = invert_formats(&s->color_spaces, ff_all_color_spaces())) <
0 ||
+(ret = invert_formats(&s->color_ranges, ff_all_color_ranges())) <
0)
return ret;
}
/* hold on to a ref for the lifetime of the filter */
-if ((ret = ff_formats_ref(s->formats, &s->formats)) < 0)
+if ((ret = ff_formats_ref(s->formats, &s->formats)) < 0 ||
+s->color_spaces && (ret = ff_formats_ref(s->color_spaces,
&s->color_spaces)) < 0 ||
+s->color_ranges && (ret = ff_formats_ref(s->color_ranges,
&s->color_ranges)) < 0)
return ret;
return 0;
@@ -114,14 +142,22 @@ static av_cold int init(AVFilterContext *ctx)
static int query_formats(AVFilterContext *ctx)
{
FormatContext *s = ctx->priv;
+int ret;
+
+if ((ret = ff_set_common_formats(ctx, s->formats)) < 0 ||
+s->color_spaces && (ret = ff_set_common_color_spaces(ctx,
s->color_spaces)) < 0 ||
+s->color_ranges && (ret = ff_set_common_color_ranges(ctx,
s->color_ranges)) < 0)
+return ret;
-return ff_set_common_formats(ctx, s->formats);
+return 0;
}
#define OFFSET(x) offsetof(FormatContext, x)
static const AVOption options[] = {
{ "pix_fmts", "A '|'-separated list of pixel formats", OFFSET(pix_fmts),
AV_OPT_TYPE_STRING, .flags = AV_OPT_FLAG_VIDEO_PARAM |
AV_OPT_FLAG_FILTERING_PARAM },
+{ "color_spaces", "A '|'-separated list of color spaces", OFFSET(csps),
AV_OPT_TYPE_STRING, .flags = AV_OPT_FLAG_VIDEO_PARAM |
AV_OPT_FLAG_FILTERING_PARAM },
+{ "color_ranges", "A '|'-separated list of color ranges", OFFSET(ranges),
AV_OPT_TYPE_STRING, .flags = AV_OPT_FLAG_VIDEO_PARAM |
AV_OPT_FLAG_FILTERING_PARAM },
{ NULL }
};
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 19/25] (WIP) lavc: set color_ranges for MPEG-only codecs
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/libavcodec/mpeg4videoenc.c
index d1e50612dd..bb98c84eab 100644
--- a/libavcodec/mpeg4videoenc.c
+++ b/libavcodec/mpeg4videoenc.c
@@ -1403,6 +1403,9 @@ const FFCodec ff_mpeg4_encoder = {
FF_CODEC_ENCODE_CB(ff_mpv_encode_picture),
.close = ff_mpv_encode_end,
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE },
+.p.color_ranges = (const enum AVColorRange[]) {
+AVCOL_RANGE_MPEG, AVCOL_RANGE_UNSPECIFIED
+},
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_SLICE_THREADS |
AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 17/25] avcodec: add YUV color space metadata to AVCodec
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
support certain values.
I decided to preserve the ambiguous and misleading "color_spaces" name,
for symmetry with AVFrame.colorspace. (Though this would IMO be better
called "color_matrix" or "color_system")
I also decided to omit the other AVColor* fields for now, because
vf_scale cannot handle auto-conversion between primaries/transfer/etc.
There is little value in adding metadata we cannot do anything with, and
no harm in extending the API again in the future. In theory, vf_scale
can handle conversion between chroma locations, but also the signalling
for this is annoying, so I'll defer it to a future commit.
---
doc/APIchanges | 3 +++
libavcodec/codec.h | 6 ++
libavcodec/version.h | 2 +-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 97b6de8276..87f4368e03 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2023-11-xx - xx - lavc 60.34.100 - avcodec.h
+ Add AVCodec.color_ranges and AVCodec.color_spaces.
+
2023-11-xx - xx - lavf 58.15.100 - buffersink.h
Add av_buffersink_get_colorspace and av_buffersink_get_color_range.
diff --git a/libavcodec/codec.h b/libavcodec/codec.h
index 8034f1a53c..8bd678de7a 100644
--- a/libavcodec/codec.h
+++ b/libavcodec/codec.h
@@ -235,6 +235,12 @@ typedef struct AVCodec {
* Array of supported channel layouts, terminated with a zeroed layout.
*/
const AVChannelLayout *ch_layouts;
+
+/**
+ * Array of supported YUV color formats. Ignored for RGB/Gray formats.
+ */
+const enum AVColorRange *color_ranges; ///< terminated by
AVCOL_RANGE_UNSPECIFIED
+const enum AVColorSpace *color_spaces; ///< terminated by
AVCOL_SPC_UNSPECIFIED
} AVCodec;
/**
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 2a08e42d7e..0ef6c991f3 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include "version_major.h"
-#define LIBAVCODEC_VERSION_MINOR 33
+#define LIBAVCODEC_VERSION_MINOR 34
#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 18/25] lavc: set color_ranges for YUVJ-only codecs
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/libavcodec/mjpegenc.c
+++ b/libavcodec/mjpegenc.c
@@ -685,6 +685,9 @@ const FFCodec ff_amv_encoder = {
.p.pix_fmts = (const enum AVPixelFormat[]) {
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE
},
+.p.color_ranges = (const enum AVColorRange[]) {
+AVCOL_RANGE_JPEG, AVCOL_RANGE_UNSPECIFIED
+},
.p.priv_class = &amv_class,
.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
};
diff --git a/libavcodec/roqvideoenc.c b/libavcodec/roqvideoenc.c
index 0933abf4f9..b584ee1142 100644
--- a/libavcodec/roqvideoenc.c
+++ b/libavcodec/roqvideoenc.c
@@ -1127,6 +1127,8 @@ const FFCodec ff_roq_encoder = {
.close= roq_encode_end,
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUVJ444P,
AV_PIX_FMT_NONE },
+.p.color_ranges = (const enum AVColorRange[]){ AVCOL_RANGE_JPEG,
+
AVCOL_RANGE_UNSPECIFIED },
.p.priv_class = &roq_class,
.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
};
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 20/25] fftools/ffmpeg_filter: simplify choose_pix_fmts
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 set:
2. Print an empty format list
Both of these goals can be accomplished by simply moving the decision
logic to ofilter_bind_ost, to avoid setting any format list when
keep_pix_fmt is enabled. This is arguably cleaner as it moves format
selection logic to a single function. In the case of branch 1, nothing
else needs to be done as we already force the format provided in
ofp->format, if any is set. Add an assertion to verify this assumption
just in case.
(Side note: The "choose_*" family of functions are arguably misnomers,
as they should really be called "print_*" - their current behavior is to
print the relevant format lists to the `vf/af_format` filter arguments)
---
fftools/ffmpeg_filter.c | 49 -
1 file changed, 9 insertions(+), 40 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index dd5cfe4481..5b99c4ba40 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -313,36 +313,6 @@ static void sub2video_update(InputFilterPriv *ifp, int64_t
heartbeat_pts,
ifp->sub2video.initialize = 0;
}
-/* *dst may return be set to NULL (no pixel format found), a static string or a
- * string backed by the bprint. Nothing has been written to the AVBPrint in
case
- * NULL is returned. The AVBPrint provided should be clean. */
-static int choose_pix_fmts(OutputFilter *ofilter, AVBPrint *bprint,
- const char **dst)
-{
-OutputFilterPriv *ofp = ofp_from_ofilter(ofilter);
-OutputStream *ost = ofilter->ost;
-
-*dst = NULL;
-
-if (ost->keep_pix_fmt || ofp->format != AV_PIX_FMT_NONE) {
-*dst = ofp->format == AV_PIX_FMT_NONE ? NULL :
- av_get_pix_fmt_name(ofp->format);
-} else if (ofp->formats) {
-const enum AVPixelFormat *p = ofp->formats;
-
-for (; *p != AV_PIX_FMT_NONE; p++) {
-const char *name = av_get_pix_fmt_name(*p);
-av_bprintf(bprint, "%s%c", name, p[1] == AV_PIX_FMT_NONE ? '\0' :
'|');
-}
-if (!av_bprint_is_complete(bprint))
-return AVERROR(ENOMEM);
-
-*dst = bprint->str;
-}
-
-return 0;
-}
-
/* Define a function for appending a list of allowed formats
* to an AVBPrint. If nonempty, the list will have a header. */
#define DEF_CHOOSE_FORMAT(name, type, var, supported_list, none,
printf_format, get_name) \
@@ -365,8 +335,8 @@ static void choose_ ## name (OutputFilterPriv *ofp,
AVBPrint *bprint) \
av_bprint_chars(bprint, ':', 1);
\
}
-//DEF_CHOOSE_FORMAT(pix_fmts, enum AVPixelFormat, format, formats,
AV_PIX_FMT_NONE,
-// GET_PIX_FMT_NAME)
+DEF_CHOOSE_FORMAT(pix_fmts, enum AVPixelFormat, format, formats,
+ AV_PIX_FMT_NONE, "%s", av_get_pix_fmt_name)
DEF_CHOOSE_FORMAT(sample_fmts, enum AVSampleFormat, format, formats,
AV_SAMPLE_FMT_NONE, "%s", av_get_sample_fmt_name)
@@ -690,7 +660,7 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost)
ofp->height = ost->enc_ctx->height;
if (ost->enc_ctx->pix_fmt != AV_PIX_FMT_NONE) {
ofp->format = ost->enc_ctx->pix_fmt;
-} else {
+} else if (!ost->keep_pix_fmt) {
ofp->formats = c->pix_fmts;
// MJPEG encoder exports a full list of supported pixel formats,
@@ -1169,7 +1139,6 @@ static int configure_output_video_filter(FilterGraph *fg,
OutputFilter *ofilter,
AVBPrint bprint;
int pad_idx = out->pad_idx;
int ret;
-const char *pix_fmts;
char name[255];
snprintf(name, sizeof(name), "out_%d_%d", ost->file_index, ost->index);
@@ -1204,17 +1173,17 @@ static int configure_output_video_filter(FilterGraph
*fg, OutputFilter *ofilter,
pad_idx = 0;
}
+av_assert0(!ost->keep_pix_fmt || (!ofp->format && !ofp->formats));
av_bprint_init(&bprint, 0, AV_BPRINT_SIZE_UNLIMITED);
-ret = choose_pix_fmts(ofilter, &bprint, &pix_fmts);
-if (ret < 0)
-return ret;
-
-if (pix_fmts) {
+choose_pix_fmts(ofp, &bprint);
+if (!av_bprint_is_complete(&bprint))
+return AVERROR(ENOMEM);
+if (bprint.len) {
AVFilterContext *filter;
ret = avfilter_graph_create_filter(&filter,
avfilter_get_by_name("format"),
- "format", pix_fmts, NULL,
fg->graph);
+ "format", bprint.str, NULL,
fg->graph);
av_bprint_finalize(&bprint, NULL);
if (ret < 0)
return ret;
--
2.42.0
___
ffmpe
[FFmpeg-devel] [PATCH 21/25] fftools/ffmpeg_filter: propagate codec yuv metadata to filters
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 to
look up the eventual encoder options from the options dictionary
directly, following the same design as the "strict" option.
---
fftools/ffmpeg_filter.c | 55 +
1 file changed, 55 insertions(+)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 5b99c4ba40..da770ef650 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -173,6 +173,8 @@ typedef struct OutputFilterPriv {
int width, height;
int sample_rate;
AVChannelLayout ch_layout;
+enum AVColorSpace color_space;
+enum AVColorRange color_range;
// time base in which the output is sent to our downstream
// does not need to match the filtersink's timebase
@@ -188,6 +190,8 @@ typedef struct OutputFilterPriv {
const int *formats;
const AVChannelLayout *ch_layouts;
const int *sample_rates;
+const enum AVColorSpace *color_spaces;
+const enum AVColorRange *color_ranges;
AVRational enc_timebase;
// offset for output timestamps, in AV_TIME_BASE_Q
@@ -344,6 +348,12 @@ DEF_CHOOSE_FORMAT(sample_fmts, enum AVSampleFormat,
format, formats,
DEF_CHOOSE_FORMAT(sample_rates, int, sample_rate, sample_rates, 0,
"%d", )
+DEF_CHOOSE_FORMAT(color_spaces, enum AVColorSpace, color_space, color_spaces,
+ AVCOL_SPC_UNSPECIFIED, "%s", av_color_space_name);
+
+DEF_CHOOSE_FORMAT(color_ranges, enum AVColorRange, color_range, color_ranges,
+ AVCOL_RANGE_UNSPECIFIED, "%s", av_color_range_name);
+
static void choose_channel_layouts(OutputFilterPriv *ofp, AVBPrint *bprint)
{
if (av_channel_layout_check(&ofp->ch_layout)) {
@@ -570,6 +580,8 @@ static OutputFilter *ofilter_alloc(FilterGraph *fg)
ofilter = &ofp->ofilter;
ofilter->graph= fg;
ofp->format = -1;
+ofp->color_space = AVCOL_SPC_UNSPECIFIED;
+ofp->color_range = AVCOL_RANGE_UNSPECIFIED;
ofilter->last_pts = AV_NOPTS_VALUE;
return ofilter;
@@ -638,6 +650,17 @@ static int set_channel_layout(OutputFilterPriv *f,
OutputStream *ost)
return 0;
}
+static int ost_opt_int(OutputStream *ost, const char *name, int defval)
+{
+const AVDictionaryEntry *e = av_dict_get(ost->encoder_opts, name, NULL, 0);
+if (e) {
+const AVOption *o = av_opt_find(ost->enc_ctx, e->key, NULL, 0, 0);
+av_assert0(o);
+av_opt_eval_int(ost->enc_ctx, o, e->value, &defval);
+}
+return defval;
+}
+
int ofilter_bind_ost(OutputFilter *ofilter, OutputStream *ost)
{
const OutputFile *of = output_files[ost->file_index];
@@ -645,6 +668,8 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost)
FilterGraph *fg = ofilter->graph;
FilterGraphPriv *fgp = fgp_from_fg(fg);
const AVCodec *c = ost->enc_ctx->codec;
+enum AVColorSpace color_space;
+enum AVColorRange color_range;
av_assert0(!ofilter->ost);
@@ -658,6 +683,8 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost)
case AVMEDIA_TYPE_VIDEO:
ofp->width = ost->enc_ctx->width;
ofp->height = ost->enc_ctx->height;
+color_space = ost_opt_int(ost, "color_space",
ost->enc_ctx->colorspace);
+color_range = ost_opt_int(ost, "color_range",
ost->enc_ctx->color_range);
if (ost->enc_ctx->pix_fmt != AV_PIX_FMT_NONE) {
ofp->format = ost->enc_ctx->pix_fmt;
} else if (!ost->keep_pix_fmt) {
@@ -687,6 +714,30 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost)
ofp->formats = mjpeg_formats;
}
}
+if (color_space != AVCOL_SPC_UNSPECIFIED) {
+ofp->color_space = color_space;
+} else {
+ofp->color_spaces = c->color_spaces;
+}
+if (color_range != AVCOL_RANGE_UNSPECIFIED) {
+ofp->color_range = color_range;
+} else {
+ofp->color_ranges = c->color_ranges;
+
+// MJPEG encoder exports a full list of supported pixel formats,
+// but the full-range ones are experimental-only.
+// Restrict the auto-conversion list unless -strict experimental
+// has been specified.
+if (!strcmp(c->name, "mjpeg")) {
+static const enum AVColorRange mjpeg_ranges[] =
+{ AVCOL_RANGE_JPEG, AVCOL_RANGE_UNSPECIFIED };
+
+int strict_val = ost->enc_ctx->strict_std_compliance;
+strict_val = ost_opt_int(ost, "strict", strict_val);
+if (strict_val > FF_COMPLIANCE_UNOFFICIAL)
+ofp->color_ranges = mjpeg_ranges;
+}
+}
[FFmpeg-devel] [PATCH 22/25] tests/fate: force MPEG range for rawvideo tests
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 need to explicitly specify that we want MPEG
range, since rawvideo does not care (or signal) if the output is JPEG or
MPEG range.
Affects both vsynth and owdenoise.
---
tests/fate/filter-video.mak | 2 +-
tests/fate/vcodec.mak | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 58edc70f46..2a9c5c682e 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -2,7 +2,7 @@
VIDEO_FILTER = $(call ALLYES, $(1:%=%_FILTER) $(2) FILE_PROTOCOL
IMAGE2_DEMUXER PGMYUV_DECODER RAWVIDEO_ENCODER NUT_MUXER MD5_PROTOCOL)
FATE_FILTER_SAMPLES-$(call FILTERDEMDECENCMUX, PERMS OWDENOISE TRIM SCALE,
SMJPEG, MJPEG, RAWVIDEO, RAWVIDEO, PIPE_PROTOCOL) +=
fate-filter-owdenoise-sample
-fate-filter-owdenoise-sample: CMD = ffmpeg -auto_conversion_filters -idct
simple -i $(TARGET_SAMPLES)/smjpeg/scenwin.mjpg -vf
"trim=duration=0.5,perms=random,owdenoise=10:20:20:enable=not(between(t\,0.2\,1.2))"
-an -f rawvideo -
+fate-filter-owdenoise-sample: CMD = ffmpeg -auto_conversion_filters -idct
simple -i $(TARGET_SAMPLES)/smjpeg/scenwin.mjpg -vf
"trim=duration=0.5,perms=random,owdenoise=10:20:20:enable=not(between(t\,0.2\,1.2))"
-an -f rawvideo -color_range mpeg -
fate-filter-owdenoise-sample: REF =
$(SAMPLES)/filter-reference/owdenoise-scenwin.raw
fate-filter-owdenoise-sample: CMP_TARGET = 1
fate-filter-owdenoise-sample: FUZZ = 3539
diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
index 45ed88da96..e3205127ff 100644
--- a/tests/fate/vcodec.mak
+++ b/tests/fate/vcodec.mak
@@ -6,7 +6,7 @@ fate-vsynth%: CODEC = $(word 3, $(subst -, ,$(@)))
fate-vsynth%: FMT = avi
fate-vsynth%: DEFAULT_SIZE = -s 352x288
fate-vsynth3-%: DEFAULT_SIZE = -s $(FATEW)x$(FATEH)
-fate-vsynth%: CMD = enc_dec "rawvideo $(DEFAULT_SIZE) -pix_fmt yuv420p
$(RAWDECOPTS)" $(SRC) $(FMT) "-c $(CODEC) $(ENCOPTS)" rawvideo "-pix_fmt
yuv420p -vsync passthrough $(DECOPTS)" "" "" ${TWOPASS}
+fate-vsynth%: CMD = enc_dec "rawvideo $(DEFAULT_SIZE) -color_range mpeg
-pix_fmt yuv420p $(RAWDECOPTS)" $(SRC) $(FMT) "-c $(CODEC) $(ENCOPTS)" rawvideo
"-pix_fmt yuv420p -color_range mpeg -vsync passthrough $(DECOPTS)" "" ""
${TWOPASS}
fate-vsynth%: CMP_UNIT = 1
fate-vsynth%: REF = $(SRC_PATH)/tests/ref/vsynth/$(@:fate-%=%)
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 24/25] avutil/pixdesc: remove old yuvj pixel format check
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 @@ enum AVPixelFormat av_pix_fmt_swap_endianness(enum
AVPixelFormat pix_fmt)
#define FF_COLOR_NA -1
#define FF_COLOR_RGB 0 /**< RGB color space */
#define FF_COLOR_GRAY 1 /**< gray color space */
-#define FF_COLOR_YUV 2 /**< YUV color space. 16 <= Y <= 235, 16 <= U, V
<= 240 */
-#define FF_COLOR_YUV_JPEG 3 /**< YUV color space. 0 <= Y <= 255, 0 <= U, V <=
255 */
+#define FF_COLOR_YUV 2 /**< YUV color space */
#define FF_COLOR_XYZ 4
#define pixdesc_has_alpha(pixdesc) \
@@ -2992,11 +2991,6 @@ static int get_color_type(const AVPixFmtDescriptor
*desc) {
if(desc->nb_components == 1 || desc->nb_components == 2)
return FF_COLOR_GRAY;
-if (desc->name) {
-if (av_strstart(desc->name, "yuvj", NULL))
-return FF_COLOR_YUV_JPEG;
-}
-
if(desc->flags & AV_PIX_FMT_FLAG_RGB)
return FF_COLOR_RGB;
@@ -3135,12 +3129,6 @@ static int get_pix_fmt_score(enum AVPixelFormat
dst_pix_fmt,
if (src_color != FF_COLOR_YUV)
loss |= FF_LOSS_COLORSPACE;
break;
-case FF_COLOR_YUV_JPEG:
-if (src_color != FF_COLOR_YUV_JPEG &&
-src_color != FF_COLOR_YUV &&
-src_color != FF_COLOR_GRAY)
-loss |= FF_LOSS_COLORSPACE;
-break;
default:
/* fail safe test */
if (src_color != dst_color)
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 25/25] avcodec/encode: enforce AVCodec capabilities at encode time
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 consider 'AVCOL_*_UNSPECIFIED' a valid
value. That way, we will only throw an error if the user explicitly set
a color value that we explicitly know is unsupported.
---
libavcodec/encode.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 31565638fa..73c3c4cd41 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -605,6 +605,45 @@ static int encode_preinit_video(AVCodecContext *avctx)
}
}
+if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED && c->color_spaces) {
+for (i = 0; c->color_spaces[i] != AVCOL_SPC_UNSPECIFIED; i++)
+if (avctx->colorspace == c->color_spaces[i])
+break;
+if (c->color_spaces[i] == AVCOL_SPC_UNSPECIFIED) {
+av_log(avctx, AV_LOG_ERROR,
+ "Specified color space %s is not supported by the %s
encoder.\n",
+ av_color_space_name(avctx->colorspace), c->name);
+av_log(avctx, AV_LOG_ERROR, "Supported color spaces:\n");
+for (int p = 0; c->color_spaces[p] != AVCOL_SPC_UNSPECIFIED; p++) {
+av_log(avctx, AV_LOG_ERROR, " %s\n",
+ av_color_space_name(c->color_spaces[p]));
+}
+return AVERROR(EINVAL);
+}
+}
+
+if (avctx->color_range != AVCOL_RANGE_UNSPECIFIED && c->color_ranges) {
+for (i = 0; c->color_ranges[i] != AVCOL_RANGE_UNSPECIFIED; i++) {
+if (avctx->color_range == c->color_ranges[i])
+break;
+}
+if (c->color_ranges[i] == AVCOL_RANGE_UNSPECIFIED) {
+if (i == 1 && !avctx->color_range) {
+avctx->color_range = c->color_ranges[0];
+} else if (avctx->color_range) {
+av_log(avctx, AV_LOG_ERROR,
+ "Specified color range %s is not supported by the %s
encoder.\n",
+ av_color_range_name(avctx->color_range), c->name);
+av_log(avctx, AV_LOG_ERROR, "Supported color ranges:\n");
+for (int p = 0; c->color_ranges[p] != AVCOL_RANGE_UNSPECIFIED;
p++) {
+av_log(avctx, AV_LOG_ERROR, " %s\n",
+ av_color_range_name(c->color_ranges[p]));
+}
+return AVERROR(EINVAL);
+}
+}
+}
+
if (avctx->bits_per_raw_sample < 0
|| (avctx->bits_per_raw_sample > 8 && pixdesc->comp[0].depth <= 8)) {
av_log(avctx, AV_LOG_WARNING, "Specified bit depth %d not possible
with the specified pixel formats depth %d\n",
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 06/25] fftools/ffmpeg_filter: configure buffersrc with csp/range
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/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -98,6 +98,8 @@ typedef struct InputFilterPriv {
int width, height;
AVRational sample_aspect_ratio;
+enum AVColorSpace color_space;
+enum AVColorRange color_range;
int sample_rate;
AVChannelLayout ch_layout;
@@ -118,6 +120,8 @@ typedef struct InputFilterPriv {
int width;
int height;
AVRational sample_aspect_ratio;
+enum AVColorSpace color_space;
+enum AVColorRange color_range;
int sample_rate;
AVChannelLayout ch_layout;
@@ -212,6 +216,8 @@ static int sub2video_get_blank_frame(InputFilterPriv *ifp)
frame->width = ifp->width;
frame->height = ifp->height;
frame->format = ifp->format;
+frame->colorspace = ifp->color_space;
+frame->color_range = ifp->color_range;
ret = av_frame_get_buffer(frame, 0);
if (ret < 0)
@@ -789,6 +795,8 @@ static InputFilter *ifilter_alloc(FilterGraph *fg)
ifp->format = -1;
ifp->fallback.format = -1;
+ifp->color_space = ifp->fallback.color_space = AVCOL_SPC_UNSPECIFIED;
+ifp->color_range = ifp->fallback.color_range = AVCOL_RANGE_UNSPECIFIED;
ifp->frame_queue = av_fifo_alloc2(8, sizeof(AVFrame*),
AV_FIFO_FLAG_AUTO_GROW);
if (!ifp->frame_queue)
@@ -1424,9 +1432,11 @@ static int configure_input_video_filter(FilterGraph *fg,
InputFilter *ifilter,
av_bprint_init(&args, 0, AV_BPRINT_SIZE_AUTOMATIC);
av_bprintf(&args,
"video_size=%dx%d:pix_fmt=%d:time_base=%d/%d:"
- "pixel_aspect=%d/%d",
+ "pixel_aspect=%d/%d:colorspace=%s:range=%s",
ifp->width, ifp->height, ifp->format,
- ifp->time_base.num, ifp->time_base.den, sar.num, sar.den);
+ ifp->time_base.num, ifp->time_base.den, sar.num, sar.den,
+ av_color_space_name(ifp->color_space),
+ av_color_range_name(ifp->color_range));
if (fr.num && fr.den)
av_bprintf(&args, ":frame_rate=%d/%d", fr.num, fr.den);
snprintf(name, sizeof(name), "graph %d input from stream %d:%d", fg->index,
@@ -1760,6 +1770,8 @@ int ifilter_parameters_from_dec(InputFilter *ifilter,
const AVCodecContext *dec)
ifp->fallback.width = dec->width;
ifp->fallback.height = dec->height;
ifp->fallback.sample_aspect_ratio= dec->sample_aspect_ratio;
+ifp->fallback.color_space= dec->colorspace;
+ifp->fallback.color_range= dec->color_range;
} else if (dec->codec_type == AVMEDIA_TYPE_AUDIO) {
int ret;
@@ -1800,6 +1812,8 @@ static int ifilter_parameters_from_frame(InputFilter
*ifilter, const AVFrame *fr
ifp->width = frame->width;
ifp->height = frame->height;
ifp->sample_aspect_ratio = frame->sample_aspect_ratio;
+ifp->color_space = frame->colorspace;
+ifp->color_range = frame->color_range;
ifp->sample_rate = frame->sample_rate;
ret = av_channel_layout_copy(&ifp->ch_layout, &frame->ch_layout);
@@ -2331,6 +2345,8 @@ int ifilter_send_eof(InputFilter *ifilter, int64_t pts,
AVRational tb)
ifp->width = ifp->fallback.width;
ifp->height = ifp->fallback.height;
ifp->sample_aspect_ratio= ifp->fallback.sample_aspect_ratio;
+ifp->color_space= ifp->fallback.color_space;
+ifp->color_range= ifp->fallback.color_range;
ret = av_channel_layout_copy(&ifp->ch_layout,
&ifp->fallback.ch_layout);
@@ -2374,7 +2390,9 @@ int ifilter_send_frame(InputFilter *ifilter, AVFrame
*frame, int keep_reference)
break;
case AVMEDIA_TYPE_VIDEO:
need_reinit |= ifp->width != frame->width ||
- ifp->height != frame->height;
+ ifp->height != frame->height ||
+ ifp->color_space != frame->colorspace ||
+ ifp->color_range != frame->color_range;
break;
}
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 05/25] avfilter/buffersrc: add color_space/range parameters
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 -
libavfilter/buffersrc.h | 6
3 files changed, 71 insertions(+), 7 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 12113d7802..55a333680c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -27939,6 +27939,16 @@ Specify the timebase assumed by the timestamps of the
buffered frames.
@item frame_rate
Specify the frame rate expected for the video stream.
+@item colorspace
+A string representing the color space of the buffered video frames.
+It may be a number corresponding to a color space, or a color space
+name.
+
+@item range
+A string representing the color range of the buffered video frames.
+It may be a number corresponding to a color range, or a color range
+name.
+
@item pixel_aspect, sar
The sample (pixel) aspect ratio of the input video.
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index 453fc0fd5c..76f3f1d7a5 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -49,6 +49,8 @@ typedef struct BufferSourceContext {
/* video only */
int w, h;
enum AVPixelFormat pix_fmt;
+enum AVColorSpace color_space;
+enum AVColorRange color_range;
AVRationalpixel_aspect;
AVBufferRef *hw_frames_ctx;
@@ -64,10 +66,13 @@ typedef struct BufferSourceContext {
int64_t last_pts;
} BufferSourceContext;
-#define CHECK_VIDEO_PARAM_CHANGE(s, c, width, height, format, pts)\
-if (c->w != width || c->h != height || c->pix_fmt != format) {\
-av_log(s, AV_LOG_INFO, "filter context - w: %d h: %d fmt: %d, incoming
frame - w: %d h: %d fmt: %d pts_time: %s\n",\
- c->w, c->h, c->pix_fmt, width, height, format,
av_ts2timestr(pts, &s->outputs[0]->time_base));\
+#define CHECK_VIDEO_PARAM_CHANGE(s, c, width, height, format, csp, range, pts)\
+if (c->w != width || c->h != height || c->pix_fmt != format ||\
+c->color_space != csp || c->color_range != range) {\
+av_log(s, AV_LOG_INFO, "filter context - w: %d h: %d fmt: %d csp: %s
range: %s, incoming frame - w: %d h: %d fmt: %d csp: %s range: %s pts_time:
%s\n",\
+ c->w, c->h, c->pix_fmt, av_color_space_name(c->color_space),
av_color_range_name(c->color_range),\
+ width, height, format, av_color_space_name(csp),
av_color_range_name(range),\
+ av_ts2timestr(pts, &s->outputs[0]->time_base));\
av_log(s, AV_LOG_WARNING, "Changing video frame properties on the fly
is not supported by all filters.\n");\
}
@@ -88,6 +93,8 @@ AVBufferSrcParameters *av_buffersrc_parameters_alloc(void)
return NULL;
par->format = -1;
+par->color_range = AVCOL_RANGE_UNSPECIFIED;
+par->color_space = AVCOL_SPC_UNSPECIFIED;
return par;
}
@@ -118,6 +125,10 @@ int av_buffersrc_parameters_set(AVFilterContext *ctx,
AVBufferSrcParameters *par
if (!s->hw_frames_ctx)
return AVERROR(ENOMEM);
}
+if (param->color_space != AVCOL_SPC_UNSPECIFIED)
+s->color_space = param->color_space;
+if (param->color_range != AVCOL_RANGE_UNSPECIFIED)
+s->color_range = param->color_range;
break;
case AVMEDIA_TYPE_AUDIO:
if (param->format != AV_SAMPLE_FMT_NONE) {
@@ -205,7 +216,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
switch (ctx->outputs[0]->type) {
case AVMEDIA_TYPE_VIDEO:
CHECK_VIDEO_PARAM_CHANGE(ctx, s, frame->width, frame->height,
- frame->format, frame->pts);
+ frame->format, frame->colorspace,
+ frame->color_range, frame->pts);
break;
case AVMEDIA_TYPE_AUDIO:
/* For layouts unknown on input but known on link after
negotiation. */
@@ -302,10 +314,11 @@ static av_cold int init_video(AVFilterContext *ctx)
return AVERROR(EINVAL);
}
-av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d pixfmt:%s tb:%d/%d fr:%d/%d
sar:%d/%d\n",
+av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d pixfmt:%s tb:%d/%d fr:%d/%d
sar:%d/%d csp:%s range:%s\n",
c->w, c->h, av_get_pix_fmt_name(c->pix_fmt),
c->time_base.num, c->time_base.den, c->frame_rate.num,
c->frame_rate.den,
- c->pixel_aspect.num, c->pixel_aspect.den);
+ c->pixel_aspect.num, c->pixel_aspect.den,
+ av_color_space_name(c->color_space),
av_color_range_name(c->color_range));
return 0;
}
@@ -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,
[FFmpeg-devel] [PATCH 08/25] avfilter/vf_scale: remove YCgCo check
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.c @@ -771,9 +771,6 @@ static int scale_frame(AVFilterLink *link, AVFrame *in, AVFrame **frame_out) int frame_changed; *frame_out = NULL; -if (in->colorspace == AVCOL_SPC_YCGCO) -av_log(link->dst, AV_LOG_WARNING, "Detected unsupported YCgCo colorspace.\n"); - frame_changed = in->width != link->w || in->height != link->h || in->format != link->format || -- 2.42.0 ___ 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".
[FFmpeg-devel] [PATCH 07/25] vf_scale: use colorspace negotiation API
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
a specific input range)
Because changing colorspace and color_range now requires reconfiguring
the link, we can lift sws_setColorspaceDetails out of scale_frame and
into config_props. (This will also get re-called if the input frame
properties change)
---
libavfilter/vf_scale.c | 188 ++---
1 file changed, 103 insertions(+), 85 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index b45035907b..44dc1f2bf8 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -143,7 +143,6 @@ typedef struct ScaleContext {
int out_color_matrix;
int in_range;
-int in_frame_range;
int out_range;
int out_h_chr_pos;
@@ -292,6 +291,18 @@ static av_cold int preinit(AVFilterContext *ctx)
return 0;
}
+static const int sws_colorspaces[] = {
+AVCOL_SPC_UNSPECIFIED,
+AVCOL_SPC_RGB,
+AVCOL_SPC_BT709,
+AVCOL_SPC_BT470BG,
+AVCOL_SPC_SMPTE170M,
+AVCOL_SPC_FCC,
+AVCOL_SPC_SMPTE240M,
+AVCOL_SPC_BT2020_NCL,
+-1
+};
+
static av_cold int init(AVFilterContext *ctx)
{
ScaleContext *scale = ctx->priv;
@@ -332,6 +343,19 @@ static av_cold int init(AVFilterContext *ctx)
if (ret < 0)
return ret;
+if (scale->in_color_matrix != -1 &&
+!ff_fmt_is_in(scale->in_color_matrix, sws_colorspaces)) {
+av_log(ctx, AV_LOG_ERROR, "Unsupported input color matrix '%s'\n",
+ av_color_space_name(scale->in_color_matrix));
+return AVERROR(EINVAL);
+}
+
+if (!ff_fmt_is_in(scale->out_color_matrix, sws_colorspaces)) {
+av_log(ctx, AV_LOG_ERROR, "Unsupported output color matrix '%s'\n",
+ av_color_space_name(scale->out_color_matrix));
+return AVERROR(EINVAL);
+}
+
av_log(ctx, AV_LOG_VERBOSE, "w:%s h:%s flags:'%s' interl:%d\n",
scale->w_expr, scale->h_expr, (char
*)av_x_if_null(scale->flags_str, ""), scale->interlaced);
@@ -356,8 +380,6 @@ static av_cold int init(AVFilterContext *ctx)
if (!threads)
av_opt_set_int(scale->sws_opts, "threads",
ff_filter_get_nb_threads(ctx), 0);
-scale->in_frame_range = AVCOL_RANGE_UNSPECIFIED;
-
return 0;
}
@@ -376,6 +398,7 @@ static av_cold void uninit(AVFilterContext *ctx)
static int query_formats(AVFilterContext *ctx)
{
+ScaleContext *scale = ctx->priv;
AVFilterFormats *formats;
const AVPixFmtDescriptor *desc;
enum AVPixelFormat pix_fmt;
@@ -407,6 +430,28 @@ static int query_formats(AVFilterContext *ctx)
if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.formats)) < 0)
return ret;
+/* accept all supported inputs, even if user overrides their properties */
+if ((ret = ff_formats_ref(ff_make_format_list(sws_colorspaces),
+ &ctx->inputs[0]->outcfg.color_spaces)) < 0)
+return ret;
+
+if ((ret = ff_formats_ref(ff_all_color_ranges(),
+ &ctx->inputs[0]->outcfg.color_ranges)) < 0)
+return ret;
+
+/* propagate output properties if overridden */
+formats = scale->out_color_matrix != AVCOL_SPC_UNSPECIFIED
+? ff_make_formats_list_singleton(scale->out_color_matrix)
+: ff_make_format_list(sws_colorspaces);
+if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.color_spaces))
< 0)
+return ret;
+
+formats = scale->out_range != AVCOL_RANGE_UNSPECIFIED
+? ff_make_formats_list_singleton(scale->out_range)
+: ff_all_color_ranges();
+if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.color_ranges))
< 0)
+return ret;
+
return 0;
}
@@ -497,6 +542,7 @@ static int config_props(AVFilterLink *outlink)
const AVPixFmtDescriptor *outdesc = av_pix_fmt_desc_get(outfmt);
ScaleContext *scale = ctx->priv;
uint8_t *flags_val = NULL;
+int in_range, in_colorspace;
int ret;
if ((ret = scale_eval_dimensions(ctx)) < 0)
@@ -521,6 +567,14 @@ static int config_props(AVFilterLink *outlink)
if (outfmt == AV_PIX_FMT_PAL8) outfmt = AV_PIX_FMT_BGR8;
scale->output_is_pal = av_pix_fmt_desc_get(outfmt)->flags &
AV_PIX_FMT_FLAG_PAL;
+in_range = scale->in_range;
+if (in_range == AVCOL_RANGE_UNSPECIFIED)
+in_range = inlink0->color_range;
+
+in_colorspace = scale->in_color_matrix;
+if (in_colorspace == -1 /* auto */)
+in_colorspace = inlink0->colorspace;
+
if (scale->sws)
sws_freeContext(scale->sws);
if (scale->isws[0])
@@ -530,8 +584,8 @@ static int config_props(AVFilterLink *outlink)
scale->isws[0] = scale->isws[1] = scale->sws = NULL;
if (inlink0->w
[FFmpeg-devel] [PATCH 10/25] avfilter/vf_zscale: switch to colorspace negotiation API
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/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -187,8 +187,12 @@ static av_cold int init(AVFilterContext *ctx)
return 0;
}
+static enum AVColorRange convert_range_from_zimg(enum zimg_pixel_range_e
color_range);
+
static int query_formats(AVFilterContext *ctx)
{
+ZScaleContext *s = ctx->priv;
+AVFilterFormats *formats;
static const enum AVPixelFormat pixel_fmts[] = {
AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P,
AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P,
@@ -217,7 +221,27 @@ static int query_formats(AVFilterContext *ctx)
ret = ff_formats_ref(ff_make_format_list(pixel_fmts),
&ctx->inputs[0]->outcfg.formats);
if (ret < 0)
return ret;
-return ff_formats_ref(ff_make_format_list(pixel_fmts),
&ctx->outputs[0]->incfg.formats);
+ret = ff_formats_ref(ff_make_format_list(pixel_fmts),
&ctx->outputs[0]->incfg.formats);
+if (ret < 0)
+return ret;
+
+if ((ret = ff_formats_ref(ff_all_color_spaces(),
&ctx->inputs[0]->outcfg.formats)) < 0 ||
+(ret = ff_formats_ref(ff_all_color_ranges(),
&ctx->inputs[0]->outcfg.formats)) < 0)
+return ret;
+
+formats = s->colorspace != ZIMG_MATRIX_UNSPECIFIED && s->colorspace > 0
+? ff_make_formats_list_singleton(s->colorspace)
+: ff_all_color_spaces();
+if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.formats)) < 0)
+return ret;
+
+formats = s->range != -1
+? ff_make_formats_list_singleton(convert_range_from_zimg(s->range))
+: ff_all_color_ranges();
+if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.formats)) < 0)
+return ret;
+
+return 0;
}
static void slice_params(ZScaleContext *s, int out_h, int in_h)
@@ -678,15 +702,9 @@ fail:
static void update_output_color_information(ZScaleContext *s, AVFrame *frame)
{
-if (s->colorspace != -1)
-frame->colorspace = (int)s->dst_format.matrix_coefficients;
-
if (s->primaries != -1)
frame->color_primaries = (int)s->dst_format.color_primaries;
-if (s->range != -1)
-frame->color_range =
convert_range_from_zimg(s->dst_format.pixel_range);
-
if (s->trc != -1)
frame->color_trc = (int)s->dst_format.transfer_characteristics;
@@ -775,6 +793,8 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
if ((link->format != outlink->format) ||
(link->w != outlink->w) ||
(link->h != outlink->h) ||
+(link->colorspace != outlink->colorspace) ||
+(link->color_range != outlink->color_range) ||
s->first_time ||
(s->src_format.chroma_location != s->dst_format.chroma_location) ||
(s->src_format.color_family !=s->dst_format.color_family) ||
@@ -796,6 +816,8 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
goto fail;
av_frame_copy_props(out, in);
+out->colorspace = outlink->colorspace;
+out->color_range = outlink->color_range;
if ((ret = realign_frame(desc, &in, 1)) < 0)
goto fail;
@@ -805,9 +827,11 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
snprintf(buf, sizeof(buf)-1, "%d", outlink->h);
av_opt_set(s, "h", buf, 0);
-link->dst->inputs[0]->format = in->format;
-link->dst->inputs[0]->w = in->width;
-link->dst->inputs[0]->h = in->height;
+link->dst->inputs[0]->format = in->format;
+link->dst->inputs[0]->w = in->width;
+link->dst->inputs[0]->h = in->height;
+link->dst->inputs[0]->colorspace = in->colorspace;
+link->dst->inputs[0]->color_range = in->color_range;
s->nb_threads = av_clip(FFMIN(ff_filter_get_nb_threads(ctx),
FFMIN(link->h, outlink->h) / MIN_TILESIZE), 1, MAX_THREADS);
slice_params(s, out->height, in->height);
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 09/25] avfilter/vf_zscale: remove unused variables
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,12 +132,6 @@ typedef struct ZScaleContext {
zimg_graph_builder_params alpha_params, params;
zimg_graph_builder_params alpha_params_tmp, params_tmp;
zimg_filter_graph *alpha_graph[MAX_THREADS], *graph[MAX_THREADS];
-
-enum AVColorSpace in_colorspace, out_colorspace;
-enum AVColorTransferCharacteristic in_trc, out_trc;
-enum AVColorPrimaries in_primaries, out_primaries;
-enum AVColorRange in_range, out_range;
-enum AVChromaLocation in_chromal, out_chromal;
} ZScaleContext;
typedef struct ThreadData {
@@ -816,15 +810,6 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
link->dst->inputs[0]->h = in->height;
s->nb_threads = av_clip(FFMIN(ff_filter_get_nb_threads(ctx),
FFMIN(link->h, outlink->h) / MIN_TILESIZE), 1, MAX_THREADS);
-s->in_colorspace = in->colorspace;
-s->in_trc = in->color_trc;
-s->in_primaries = in->color_primaries;
-s->in_range = in->color_range;
-s->out_colorspace = out->colorspace;
-s->out_trc = out->color_trc;
-s->out_primaries = out->color_primaries;
-s->out_range = out->color_range;
-
slice_params(s, out->height, in->height);
zimg_image_format_default(&s->src_format, ZIMG_API_VERSION);
--
2.42.0
___
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".
[FFmpeg-devel] [PATCH 11/25] avfilter/vf_libplacebo: don't force dovi frames to bt.2020-ncl
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
Dolby Vision decoding process.
---
libavfilter/vf_libplacebo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
index 8534945ba6..b6e82a61e0 100644
--- a/libavfilter/vf_libplacebo.c
+++ b/libavfilter/vf_libplacebo.c
@@ -888,7 +888,6 @@ static int output_frame(AVFilterContext *ctx, int64_t pts)
if (s->apply_dovi && av_frame_get_side_data(ref,
AV_FRAME_DATA_DOVI_METADATA)) {
/* Output of dovi reshaping is always BT.2020+PQ, so infer the correct
* output colorspace defaults */
-out->colorspace = AVCOL_SPC_BT2020_NCL;
out->color_primaries = AVCOL_PRI_BT2020;
out->color_trc = AVCOL_TRC_SMPTE2084;
}
--
2.42.0
___
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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 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. > > IMHO the question of the relation of the list of people who could vote > in the last GA vote and the people who where in the general assembly > in 2020 should be awnsered before further votes. > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html > > 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 important to you!) > > The presumed 2020 General assembly as well as people who have subtantial > contributions over the lifetime of the project where the source of this > list > > 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 since forever, maintains 15 > things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits > in FFmpeg) > Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > Lauri Kasanen (Linux / PowerPC maintainer) > Dale Curtis(14 commits in 2020 was in the 2020-GA) > Alexander Strasser (Root admin, just recently reported that he could not > vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) > foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) > Huiwen Ren (8 matches in the codebase of his name, avs2* and > related things maintainer) > Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > hostility) > Was hostile very much, even pushed extremely hostile commit in codebase that is still kept. > Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the > 2020-GA but not on jbs list) > Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 > entries in MAINTAINERs, 25 in copyrights) > Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to > various bits of code, last active in git in 2020) > John Stebbins (over 100 commits in FFmpeg, last active in git in > 2020, 1 copyright match) > Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) > Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > commits in FFmpeg) > Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name > in the source, last commit May 2023) > Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last > commit in Oct 2023, 49 matches for his name in the codebase) > Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in > MAINTAINERs, 70 copyright line matches) > Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, > 4 copyrights, last commit in Jul 2023) > Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, > 22 copyright matches) > Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I know you won't believe me, but the highest form of Human Excellence is > to question oneself and others. -- Socrates > ___ > 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". > ___ 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".
Re: [FFmpeg-devel] [PATCH] ffmpeg CLI multithreading
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/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ 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".
Re: [FFmpeg-devel] [PATCH v6] fftools/ffplay: add hwaccel decoding support
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 by libplacebo, and enable debug:
> $ ffplay -hwaccel vulkan \
> -vulkan_params create_by_placebo=1:debug=1 foo.mp4
> ---
> v6:
>1. check PL_API_VER >= 278
>2. check hwctx->get_proc_addr against SDL_Vulkan_GetVkGetInstanceProcAddr()
>
> v5:
>1. add vulkan_params option.
>2. vulkan instance can be create by hwcontext or libplacebo.
>
> v4: add more optional extensions
> v3: shared vulkan instance between libplacebo and hwcontext
>
> configure | 2 +-
> doc/ffplay.texi | 12 +
> fftools/Makefile | 2 +
> fftools/ffplay.c | 96 -
> fftools/ffplay_renderer.c | 824 ++
> fftools/ffplay_renderer.h | 41 ++
> 6 files changed, 971 insertions(+), 6 deletions(-)
> create mode 100644 fftools/ffplay_renderer.c
> create mode 100644 fftools/ffplay_renderer.h
>
> diff --git a/configure b/configure
> index 8ab658f730..80bfa8557c 100755
> --- a/configure
> +++ b/configure
> @@ -3903,7 +3903,7 @@ ffmpeg_select="aformat_filter anull_filter atrim_filter
> format_filter
> ffmpeg_suggest="ole32 psapi shell32"
> ffplay_deps="avcodec avformat avfilter swscale swresample sdl2"
> ffplay_select="crop_filter transpose_filter hflip_filter vflip_filter
> rotate_filter"
> -ffplay_suggest="shell32"
> +ffplay_suggest="shell32 libplacebo vulkan"
> ffprobe_deps="avcodec avformat"
> ffprobe_suggest="shell32"
>
> diff --git a/doc/ffplay.texi b/doc/ffplay.texi
> index 5dd860b846..93f77eeece 100644
> --- a/doc/ffplay.texi
> +++ b/doc/ffplay.texi
> @@ -196,6 +196,18 @@ will produce a thread pool with this many threads
> available for parallel
> processing. The default is 0 which means that the thread count will be
> determined by the number of available CPUs.
>
> +@item -enable_vulkan
> +Use vulkan renderer rather than SDL builtin renderer. Depends on libplacebo.
> +
> +@item -vulkan_params
> +
> +Vulkan configuration using a list of @var{key}=@var{value} pairs separated by
> +":".
> +
> +@item -hwaccel
> +Use HW accelerated decoding. Enable this option will enable vulkan renderer
> +automatically.
> +
> @end table
>
> @section While playing
> diff --git a/fftools/Makefile b/fftools/Makefile
> index 56820e6bc8..3c763e3db9 100644
> --- a/fftools/Makefile
> +++ b/fftools/Makefile
> @@ -22,6 +22,8 @@ OBJS-ffmpeg += \
> fftools/sync_queue.o\
> fftools/thread_queue.o \
>
> +OBJS-ffplay += fftools/ffplay_renderer.o
> +
> define DOFFTOOL
> OBJS-$(1) += fftools/cmdutils.o fftools/opt_common.o fftools/$(1).o
> $(OBJS-$(1)-yes)
> ifdef HAVE_GNU_WINDRES
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index d8c69e10bc..873ee8cc74 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -58,6 +58,7 @@
> #include
>
> #include "cmdutils.h"
> +#include "ffplay_renderer.h"
> #include "opt_common.h"
>
> const char program_name[] = "ffplay";
> @@ -350,6 +351,9 @@ static char *afilters = NULL;
> static int autorotate = 1;
> static int find_stream_info = 1;
> static int filter_nbthreads = 0;
> +static int enable_vulkan = 0;
> +static char *vulkan_params = NULL;
> +static const char *hwaccel = NULL;
>
> /* current context */
> static int is_full_screen;
> @@ -362,6 +366,8 @@ static SDL_Renderer *renderer;
> static SDL_RendererInfo renderer_info = {0};
> static SDL_AudioDeviceID audio_dev;
>
> +static VkRenderer *vk_renderer;
> +
> static const struct TextureFormatEntry {
> enum AVPixelFormat format;
> int texture_fmt;
> @@ -954,6 +960,11 @@ static void video_image_display(VideoState *is)
> SDL_Rect rect;
>
> vp = frame_queue_peek_last(&is->pictq);
> +if (vk_renderer) {
> +vk_renderer_display(vk_renderer, vp->frame);
> +return;
> +}
> +
> if (is->subtitle_st) {
> if (frame_queue_nb_remaining(&is->subpq) > 0) {
> sp = frame_queue_peek(&is->subpq);
> @@ -1289,6 +1300,8 @@ static void do_exit(VideoState *is)
> }
> if (renderer)
> SDL_DestroyRenderer(renderer);
> +if (vk_renderer)
> +vk_renderer_destroy(vk_renderer);
> if (window)
> SDL_DestroyWindow(window);
> uninit_opts();
> @@ -2546,6 +2559,37 @@ static int audio_open(void *opaque, AVChannelLayout
> *wanted_channel_layout, int
> return spec.size;
> }
>
> +static int create_hwaccel(AVBufferRef **device_ctx)
> +{
> +enum AVHWDeviceType type;
> +int ret;
> +AVBufferRef *vk_dev;
> +
> +*device_ctx = NULL;
> +
> +if (!hwaccel)
> +return 0;
> +
> +type = av_hwdevice_find_type_by_name(hwaccel);
> +if (type == AV_HWDEVICE_TYPE_NONE)
> +return AVERROR(ENOTSUP);
> +
> +ret = vk_renderer_get_hw_dev(vk_rende
Re: [FFmpeg-devel] [PATCH v28 1/2] avcodec/evc_encoder: Provided support for EVC encoder
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 >libraries, namely libxeve (encoder implementation) and libxevd (decoder >implementation). > >The EVC defines two profiles: the "Baseline Profile" and the "Main Profile". >For the encoder and decoder, libraries can be built for both main and baseline >profiles as follows: >cmake .. -DSET_PROF=BASE && make && make install >cmake .. -DSET_PROF=MAIN && make && make install I guess that the point is that Linux distributions want a single library for all profiles. You can't have two libraries with the same name, obviously. And you also don't want two libraries with different SO names, but the same/conflicting exported symbols and same header and function names. You make it sound like you have to choose a profile at compilation time, which sounds lazy to stay polite. Br, ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 and work all over the codebase) > > Baptiste Coudurier (Pays for our fate server since forever, maintains 15 > > things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits > > in FFmpeg) > > Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > > Lauri Kasanen (Linux / PowerPC maintainer) > > Dale Curtis(14 commits in 2020 was in the 2020-GA) > > Alexander Strasser (Root admin, just recently reported that he could not > > vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) > > foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) > > Huiwen Ren (8 matches in the codebase of his name, avs2* and > > related things maintainer) > > Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > > hostility) > > Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the > > 2020-GA but not on jbs list) > > Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 > > entries in MAINTAINERs, 25 in copyrights) > > Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to > > various bits of code, last active in git in 2020) > > John Stebbins (over 100 commits in FFmpeg, last active in git in > > 2020, 1 copyright match) > > Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) > > Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > > commits in FFmpeg) > > Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name > > in the source, last commit May 2023) > > Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last > > commit in Oct 2023, 49 matches for his name in the codebase) > > Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in > > MAINTAINERs, 70 copyright line matches) > > Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, > > 4 copyrights, last commit in Jul 2023) > > Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > > Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > > Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, > > 22 copyright matches) > > Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > > Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > > Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) > > > > just noting some people in the list have cut ties with this project and > would much rather not be involved in anything related to ffmpeg - People who do not want to be in the GA should be ommitted, thats obvious i agree with that of course. > as a rule > of thumb it's probably safe to omit inactive developers and inactive > founders from the list, in my opinion That i do not agree with. For example iam inactive in SPI and i do NOT vote in SPI but i very much want to maintain my ability to vote if a situation arises that matters. Why ? FFmpeg has alot of money with SPI so I want to maintain my ability to cast a vote if a special situation arrises. if you flip this around. Some inactive contributors are very dependant on FFmpeg in their jobs. I do not belive they want to have no say in major decissions in FFmpeg. Why did i include people who left due to hostility? It was a simple thought. If you form a group of people who oppose hostility thats more likely to reduce hostility than if you form a group of people who have a thick enough skin to stay. Thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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, 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. > > > > IMHO the question of the relation of the list of people who could vote > > in the last GA vote and the people who where in the general assembly > > in 2020 should be awnsered before further votes. > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html > > 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. > > Do you dispute that? There are at least 3 issues here * The first and maybe the biggest, is that our vote superviser can reply to mails within 20min (like in this thread here) but is not replying to a simple question within days where the list of voters comes from he used and how it relates to the 2020 GA. It gives one the feeling he has some sort of difficulty with awnsering that question you took a guess here and replied, and i appreciate that. But really JB choose this list and also the one in 2020. Only he can explain where these lists come from and how they relate. * The 2nd issue is that there are rules how to change the GA over time like that after 2 years there needs to a confirmation AND that the other members represent the "active" developers in the last 36 months. I can see an argument to leave the 2020 GA untouched and use it as is I can also see an argument to update it, and exactly this was done in a vote in 2021 by JB. Now we are here trying the 3rd variant of applying only half the rules. But whats more so, we actually are not. What you are doing here is looking at what happened and trying to rationalize it, trying to find an explanation for the list. Not stating upfront what this list is IMO this is not acceptable for a vote. Uhm we found this list, lets see where that might have come from * I know for a fact that at least zane was not in the 2020 GA as i talked with him and i know he did cast a vote in 2023 because again he told me. So even if you partially apply the rules these lists do not match will write a seperate reply to the 2nd part of your mail [...] thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 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. >> > >> > IMHO the question of the relation of the list of people who could vote >> > in the last GA vote and the people who where in the general assembly >> > in 2020 should be awnsered before further votes. >> > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html >> >> 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. >> >> Do you dispute that? > > There are at least 3 issues here > > * The first and maybe the biggest, is that our vote superviser can reply to > mails within 20min (like in this thread here) but is not replying to a > simple > question within days where the list of voters comes from he used and how it WTF are you talking about ? WTF are you attacking me on my email response time? > relates to the 2020 GA. It gives one the feeling he has some sort of > difficulty with awnsering that question > you took a guess here and replied, and i appreciate that. But really JB > choose this list and also the one in 2020. Only he can explain where these I choose nothing. I got the list that was provided to me for the first vote, after the script was written. I did not write the script, I did not run the script. Would you stop smearing me? This is absolutely unacceptable. A contrario from you, I am not part of the GA and I don’t have voting rights… > * The 2nd issue is that there are rules how to change the GA over time No they don’t. We discussed and voted a way, and after years it seems it was not clear enough for some people. > Now we are here trying the 3rd variant of applying > only half the rules. So what? The previous way was not clear enough for people, so we vote for a new way. And it was accepted quite largely against the other options. > Not stating upfront what this list is > IMO this is not acceptable for a vote. How so? Do you go to and see the list of all the voters in Austria before doing a vote ? Especially, here, it is to bootstrap a new way of voting. If the vote was close, maybe there could be discussion, but here, this is not the case. And stop smearing me in the mud. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 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 since forever, maintains > 15 > > > things in MAINTAINERs, is the the copyright of 56 files, over 1900 > commits > > > in FFmpeg) > > > Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > > > Lauri Kasanen (Linux / PowerPC maintainer) > > > Dale Curtis(14 commits in 2020 was in the 2020-GA) > > > Alexander Strasser (Root admin, just recently reported that he could > not > > > vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) > > > foo86 (maintainer and author of dca*, dolby_e*, dtsdec, > s337m) > > > Huiwen Ren (8 matches in the codebase of his name, avs2* and > > > related things maintainer) > > > Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > > > hostility) > > > Lou Logan (over 100 commits in FFmpeg, left in 2020, also in > the > > > 2020-GA but not on jbs list) > > > Matthieu Bouron(over 200 commits in FFmpeg, recently active in > 2022, 5 > > > entries in MAINTAINERs, 25 in copyrights) > > > Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to > > > various bits of code, last active in git in 2020) > > > John Stebbins (over 100 commits in FFmpeg, last active in git in > > > 2020, 1 copyright match) > > > Ting Fu(last active in April 2023, 24 commits in > 2021-2023, ) > > > Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > > > commits in FFmpeg) > > > Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his > name > > > in the source, last commit May 2023) > > > Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last > > > commit in Oct 2023, 49 matches for his name in the codebase) > > > Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in > > > MAINTAINERs, 70 copyright line matches) > > > Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in > MAINTAINERs, > > > 4 copyrights, last commit in Jul 2023) > > > Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > > > Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > > > Ramiro Polla (over 600 commits in FFmpeg, 5 matches in > MAINTAINERs, > > > 22 copyright matches) > > > Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > > > Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > > > Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) > > > > > > > just noting some people in the list have cut ties with this project and > > would much rather not be involved in anything related to ffmpeg - > > People who do not want to be in the GA should be ommitted, thats obvious > i agree with that of course. > > > > as a rule > > of thumb it's probably safe to omit inactive developers and inactive > > founders from the list, in my opinion > > That i do not agree with. > For example iam inactive in SPI and i do NOT vote in SPI but i very > much want to maintain my ability to vote if a situation arises that > matters. > Why ? FFmpeg has alot of money with SPI so I want to maintain my ability to > cast a vote if a special situation arrises. > Right but you *are* maintaining an active interest in SPI because it matters to you and the project, but your situation doesn't directly translate to the people listed, who might consider being included automatically as spam in the best case and offensive in the worst case. if you flip this around. Some inactive contributors are very dependant > on FFmpeg in their jobs. I do not belive they want to have no say in > major decissions in FFmpeg. > I mean if they are "very dependent" maybe they should spend a minimum time of "volunteer service" if they want to have a stake in voting matters. Voting is a right but it has obligations too, and just diluting the GA with inactive people (who might not even vote) won't do the project any good > Why did i include people who left due to hostility? > It was a simple thought. If you form a group of people who oppose > hostility thats more likely to reduce hostility than if you form a > group of people who have a thick enough skin to stay. > Sorry I cannot parse this sentence As mentioned, in general we shouldn't just assume that people want the extra baggage and responsibility of being part of the GA without the direct involvement and candidacy, in my opinion. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-deve
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 important to you!) > > > > The presumed 2020 General assembly as well as people who have subtantial > > contributions over the lifetime of the project where the source of this list > > > Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) > > He actually is in the GA, but his Intel mailbox bounces. i couldnt find another address either after a quick look :( [...] > > 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 since forever, maintains 15 > > things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits > > in FFmpeg) > > Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > > Lauri Kasanen (Linux / PowerPC maintainer) > > Dale Curtis(14 commits in 2020 was in the 2020-GA) > > Alexander Strasser (Root admin, just recently reported that he could not > > vote even though he was in teh 2020-GA, 3 things in MAINTAINERs) > > foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) > > Huiwen Ren (8 matches in the codebase of his name, avs2* and > > related things maintainer) > > Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > > hostility) > > Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the > > 2020-GA but not on jbs list) > > Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 > > entries in MAINTAINERs, 25 in copyrights) > > Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to > > various bits of code, last active in git in 2020) > > John Stebbins (over 100 commits in FFmpeg, last active in git in 2020, > > 1 copyright match) > > Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > > commits in FFmpeg) > > Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name in > > the source, last commit May 2023) > > Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last commit > > in Oct 2023, 49 matches for his name in the codebase) > > Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in MAINTAINERs, > > 70 copyright line matches) > > Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, 4 > > copyrights, last commit in Jul 2023) > > Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > > Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > > Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, > > 22 copyright matches) > > Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > > Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > > Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) > > Sending voting emails to people who have not had any contact with the > project for years, can be regarded as spamming. someone who made hundreads of contributions can expect some occasional feedback until he indicates that he wants to hear no more after which of course he should not receive any further communication. 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) > I think there should be > some confirmation that these people are actually interested in having > voting rights. Yes, i guess so If people want that. I volunteer and will contact them all and ask. It was my suggestion to add these people so iam ready to do the work. But we should give them a week at least to reply. Should i ask all or limit to the ones who are not subscribed to the ML with a identifyable address ? thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 they are subscribed and still don't ask to be added to the GA, I don't think they should be "volunteered" by someone else. They are of course welcome to apply. And if they are not subscribed, then they should not be added to the GA, not only because they presumably don't want to hear about FFmpeg at the moment, but also because they are probably totally out of the loop about it, so to speak. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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. > > > > Do you dispute that? > > There are at least 3 issues here > > * The first and maybe the biggest, is that our vote superviser can reply to > mails within 20min (like in this thread here) but is not replying to a > simple > question within days where the list of voters comes from he used and how it > relates to the 2020 GA. It gives one the feeling he has some sort of > difficulty with awnsering that question > you took a guess here and replied, and i appreciate that. But really JB > choose this list and also the one in 2020. Only he can explain where these > lists come from and how they relate. JB did explain where the list comes from [1] - it was generated by the script that is now in our tree. Nobody disputed it in 2020. > * I know for a fact that at least zane was not in the 2020 GA as i talked > with him and i know he did cast a vote in 2023 because again he told me. > So even if you partially apply the rules these lists do not match Zane had 30 commits in July 2020, so he SHOULD have been on the list. If he wasn't, then it was a mistake in 2020. > * The 2nd issue is that there are rules how to change the GA over time > like that after 2 years there needs to a confirmation AND that the > other members represent the "active" developers in the last 36 months. > I can see an argument to leave the 2020 GA untouched and use it as is > I can also see an argument to update it, and exactly this was done in a > vote in 2021 by JB. Now we are here trying the 3rd variant of applying > only half the rules. > But whats more so, we actually are not. What you are doing here is > looking at what happened and trying to rationalize it, trying to find > an explanation for the list. Not stating upfront what this list is > IMO this is not acceptable for a vote. Uhm we found this list, lets see > where that might have come from To be honest, it very much seems to me that you are trying to bikeshed the process to death. Yes, it is imperfect, but that is to be expected given we've only used it a few times so far, and the last time was over 2 years ago. What we are doing here is trying to clarify the rules so that we actually can vote with some regularity. In the vote we just had, option A won its contests against B/C/D by 17/7, 23/1, and 17/7, respectively. While it is possible that the list used was not entirely correct (also depending on the intepretation of the rules), I see no reason to think it was incorrect in 10 people, which is what you'd need to have a chance of getting a different result. [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264732.html -- 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 +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 to suggest further people, please do so in this thread ASAP. > >> > > >> > IMHO the question of the relation of the list of people who could vote > >> > in the last GA vote and the people who where in the general assembly > >> > in 2020 should be awnsered before further votes. > >> > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html > >> > >> 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. > >> > >> Do you dispute that? > > > > There are at least 3 issues here > > > > * The first and maybe the biggest, is that our vote superviser can reply to > > mails within 20min (like in this thread here) but is not replying to a > > simple > > question within days where the list of voters comes from he used and how > > it > > WTF are you talking about ? > WTF are you attacking me on my email response time? > > > relates to the 2020 GA. It gives one the feeling he has some sort of > > difficulty with awnsering that question > > you took a guess here and replied, and i appreciate that. But really JB > > choose this list and also the one in 2020. Only he can explain where these > > I choose nothing. I got the list that was provided to me for the first vote, > after the script was written. > > I did not write the script, I did not run the script. > > Would you stop smearing me? > > This is absolutely unacceptable. As the vote superviser you are responsible for the vote. your reaction is IMHO unacceptable. theres a list of voters in 2020 and 2023 iam asking for how these 2 lists relate and instead of awnsering that you are talking about everything else i will seperately reply to your question about voting in austria as its off topic here thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 the new list was written by Anton with the new script. Whatever the old script was, and how wrong it was, I don't think it would change the result of the re-bootstrapping vote. And now we have a clean list for the extra members of the GA. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 the extra members whose voting rights > > > expire after 2 years. > > > > > > Do you dispute that? > > > > There are at least 3 issues here > > > > * The first and maybe the biggest, is that our vote superviser can reply to > > mails within 20min (like in this thread here) but is not replying to a > > simple > > question within days where the list of voters comes from he used and how > > it > > relates to the 2020 GA. It gives one the feeling he has some sort of > > difficulty with awnsering that question > > you took a guess here and replied, and i appreciate that. But really JB > > choose this list and also the one in 2020. Only he can explain where these > > lists come from and how they relate. > > JB did explain where the list comes from [1] - it was generated by the > script that is now in our tree. Nobody disputed it in 2020. > > > * I know for a fact that at least zane was not in the 2020 GA as i talked > > with him and i know he did cast a vote in 2023 because again he told me. > > So even if you partially apply the rules these lists do not match > > Zane had 30 commits in July 2020, so he SHOULD have been on the list. If > he wasn't, then it was a mistake in 2020. the 2020 GA list cannot have been created in July 2020 because there where votes prior that used it. > > > * The 2nd issue is that there are rules how to change the GA over time > > like that after 2 years there needs to a confirmation AND that the > > other members represent the "active" developers in the last 36 months. > > I can see an argument to leave the 2020 GA untouched and use it as is > > I can also see an argument to update it, and exactly this was done in a > > vote in 2021 by JB. Now we are here trying the 3rd variant of applying > > only half the rules. > > But whats more so, we actually are not. What you are doing here is > > looking at what happened and trying to rationalize it, trying to find > > an explanation for the list. Not stating upfront what this list is > > IMO this is not acceptable for a vote. Uhm we found this list, lets see > > where that might have come from > > To be honest, it very much seems to me that you are trying to bikeshed > the process to death. Yes, it is imperfect, but that is to be expected > given we've only used it a few times so far, and the last time was over > 2 years ago. What we are doing here is trying to clarify the rules so > that we actually can vote with some regularity. Is it bikesheding if 2 lists that are supposed to be the same differ in multiple entries ? these are lists with roughly 50 entries, now we _know_ 2 people differ but there where 3 on the extra voters list so really 4 differ almost certainly thats roughly 10% of the voters are wrong. Thats not bikesheding IMO. We arent talking about 1 voter in hundreads. I do want to know what happened here and want to have this not happen again. if i offend people with that investigation then so be it > > In the vote we just had, option A won its contests against B/C/D by > 17/7, 23/1, and 17/7, respectively. While it is possible that the list > used was not entirely correct (also depending on > the intepretation of the rules), I see no reason to think it was > incorrect in 10 people, which is what you'd need to have a chance of > getting a different result. Its not just this vote, its that we need to understand what happened here so we can prevent this from happening again thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 extra members whose voting rights > > > expire after 2 years. > > > > > > Do you dispute that? > > > > There are at least 3 issues here > > > > * The first and maybe the biggest, is that our vote superviser can reply to > > mails within 20min (like in this thread here) but is not replying to a > > simple > > question within days where the list of voters comes from he used and how > > it > > relates to the 2020 GA. It gives one the feeling he has some sort of > > difficulty with awnsering that question > > you took a guess here and replied, and i appreciate that. But really JB > > choose this list and also the one in 2020. Only he can explain where these > > lists come from and how they relate. > > JB did explain where the list comes from [1] - it was generated by the > script that is now in our tree. Nobody disputed it in 2020. > > > * I know for a fact that at least zane was not in the 2020 GA as i talked > > with him and i know he did cast a vote in 2023 because again he told me. > > So even if you partially apply the rules these lists do not match > > Zane had 30 commits in July 2020, so he SHOULD have been on the list. If > he wasn't, then it was a mistake in 2020. > > > * The 2nd issue is that there are rules how to change the GA over time > > like that after 2 years there needs to a confirmation AND that the > > other members represent the "active" developers in the last 36 months. > > I can see an argument to leave the 2020 GA untouched and use it as is > > I can also see an argument to update it, and exactly this was done in a > > vote in 2021 by JB. Now we are here trying the 3rd variant of applying > > only half the rules. > > But whats more so, we actually are not. What you are doing here is > > looking at what happened and trying to rationalize it, trying to find > > an explanation for the list. Not stating upfront what this list is > > IMO this is not acceptable for a vote. Uhm we found this list, lets see > > where that might have come from > > To be honest, it very much seems to me that you are trying to bikeshed > the process to death. Yes, it is imperfect, but that is to be expected > given we've only used it a few times so far, and the last time was over > 2 years ago. What we are doing here is trying to clarify the rules so > that we actually can vote with some regularity. > > In the vote we just had, option A won its contests against B/C/D by > 17/7, 23/1, and 17/7, respectively. While it is possible that the list > used was not entirely correct (also depending on > the intepretation of the rules), I see no reason to think it was > incorrect in 10 people, which is what you'd need to have a chance of > getting a different result. > > [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264732.html > > -- > Anton Khirnov Organizations and Conferences Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions. Make “speeches.” Talk as frequently as possible and at great length. Illustrate your “points” by long anecdotes and accounts of personal experiences. When possible, refer all matters to committees, for “further study and consideration.” Attempt to make the committee as large as possible — never less than five. Bring up irrelevant issues as frequently as possible. Haggle over precise wordings of communications, minutes, resolutions. Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision. Advocate “caution.” Be “reasonable” and urge your fellow-conferees to be “reasonable” and avoid haste which might result in embarrassments or difficulties later on. source: https://www.forbes.com/sites/eriklarson/2023/08/15/a-spys-guide-to-making-bad-decisions/ Presented without comment. Regards, Kieran Kunhya ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 greping their name. (not posting the list due to privacy > > concerns) > > Thing is, if they are subscribed and still don't ask to be added to the GA, I > don't think they should be "volunteered" by someone else. They are of course > welcome to apply. > > And if they are not subscribed, then they should not be added to the GA, not > only because they presumably don't want to hear about FFmpeg at the moment, > but also because they are probably totally out of the loop about it, so to > speak. While i can find 16 who are subscribed. I have no way to find people who are not subscribed, they can be subcribed using some email addess that doesnt include their name in either domain or user thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is a danger to trust the dream we wish for rather than the science we have, -- Dr. Kenneth Brown signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 installed CIVS. > It quite matches the gitlog. > > The list was reused for the vote, Thats not possible multiple people on this list did not have 20 commits at the time the list must have been made Example: Gautam Ramakrishnan has 20 commits after 2020 Jul 16 but the TC/CC votes in 2020 where prior to that (and i already mentioned zane) So I do not see how the list of names you posted can be the same list as the one used in 2020 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 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 they are subscribed and still don't ask to be added to the > > GA, I don't think they should be "volunteered" by someone else. They are > > of course welcome to apply. > > > > And if they are not subscribed, then they should not be added to the GA, > > not only because they presumably don't want to hear about FFmpeg at the > > moment, but also because they are probably totally out of the loop about > > it, so to speak. > > While i can find 16 who are subscribed. I have no way to find people who > are not subscribed, they can be subcribed using some email addess that > doesnt include their name in either domain or user 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 the end result is the same: don't nominate people like that. It's rude. (In fact, they are also potentially people on the mailing list but with Mailman delivery turned off, as well as people who don't read the email account through which they are subscribed.) 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 friendly remind them that they can nominate themselves. -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 run by Thilo (?) IIRC when Thilo installed CIVS. It quite matches the gitlog. The list was reused for the vote, Thats not possible multiple people on this list did not have 20 commits at the time the list must have been made Example: Gautam Ramakrishnan has 20 commits after 2020 Jul 16 but the TC/CC votes in 2020 where prior to that (and i already mentioned zane) So I do not see how the list of names you posted can be the same list as the one used in 2020 The script came in by Josh [1]. The vote was run by JB [2]. In [2] the CIVS reported 49 authorized voters as JB mentioned in the mail. Therefore, it cannot be the list of 51 voters JB provided in the corresponding thread [3]. Did the original list survive? Josh? If not, we can go back in time and run the script again. -Thilo [1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261323.html [2] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-June/265075.html [3] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316594.html ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 should be the same > > > > as the GA from 2020, except for the extra members whose voting rights > > > > expire after 2 years. > > > > > > > > Do you dispute that? > > > > > > There are at least 3 issues here > > > > > > * The first and maybe the biggest, is that our vote superviser can reply > > > to > > > mails within 20min (like in this thread here) but is not replying to a > > > simple > > > question within days where the list of voters comes from he used and > > > how it > > > relates to the 2020 GA. It gives one the feeling he has some sort of > > > difficulty with awnsering that question > > > you took a guess here and replied, and i appreciate that. But really JB > > > choose this list and also the one in 2020. Only he can explain where > > > these > > > lists come from and how they relate. > > > > JB did explain where the list comes from [1] - it was generated by the > > script that is now in our tree. Nobody disputed it in 2020. > > > > > * I know for a fact that at least zane was not in the 2020 GA as i talked > > > with him and i know he did cast a vote in 2023 because again he told me. > > > So even if you partially apply the rules these lists do not match > > > > Zane had 30 commits in July 2020, so he SHOULD have been on the list. If > > he wasn't, then it was a mistake in 2020. > > the 2020 GA list cannot have been created in July 2020 because there where > votes prior that used it. According to my mailbox, the vote on extra members was started on 2020-06-18. TC/CC election vote was started on 2020-07-12. Zane had 29 commits as of the former, and 30 as of the latter. In either case he should have been on the list. With what you told us so far, it is entirely possible he was on the original list, but * misremembered about not receiving the vote link, or * did not get the email because of delivery issues (we had them even now during the first attempt to initiate the vote). > > > > > * The 2nd issue is that there are rules how to change the GA over time > > > like that after 2 years there needs to a confirmation AND that the > > > other members represent the "active" developers in the last 36 months. > > > I can see an argument to leave the 2020 GA untouched and use it as is > > > I can also see an argument to update it, and exactly this was done in a > > > vote in 2021 by JB. Now we are here trying the 3rd variant of applying > > > only half the rules. > > > But whats more so, we actually are not. What you are doing here is > > > looking at what happened and trying to rationalize it, trying to find > > > an explanation for the list. Not stating upfront what this list is > > > IMO this is not acceptable for a vote. Uhm we found this list, lets see > > > where that might have come from > > > > To be honest, it very much seems to me that you are trying to bikeshed > > the process to death. Yes, it is imperfect, but that is to be expected > > given we've only used it a few times so far, and the last time was over > > 2 years ago. What we are doing here is trying to clarify the rules so > > that we actually can vote with some regularity. > > Is it bikesheding if 2 lists that are supposed to be the same differ in > multiple entries ? It is the way you are doing it, with all these "just asking questions" and vague accusations of impropriety. > 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? > but there where 3 on the extra voters list so really 4 differ almost certainly I do not understand this math. > thats roughly 10% of the voters are wrong. > Thats not bikesheding IMO. We arent talking about 1 voter in hundreads. Even if this was true (which I don't think is supported by evidence so far), it's still less than half of the minimum needed to change the result. > I do want to know what happened here and want to have this not happen > again. if i offend people with that investigation then so be it > > > > > > In the vote we just had, option A won its contests against B/C/D by > > 17/7, 23/1, and 17/7, respectively. While it is possible that the list > > used was not entirely correct (also depending on > > the intepretation of the rules), I see no reason to think it was > > incorrect in 10 people, which is what you'd need to have a chance of > > getting a different result. > > Its not just this vote, its that we need to understand what happened here > so we can prevent this from happening again What happened is very clear to me. The process was bikeshod to death by endless discussions and concerns, the script for generating the list was
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
> 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 > the end result is the same: don't nominate people like that. It's rude. I don't think nominating others for the GA is rude, assuming they accept the nomination. I do agree they shouldn't be automatically be put on the GA because of a nomination they did not accept, but it seems reasonable to ask them if they want to accept the nomination. I do think that being subscribed to the mailing list should be a prerequisite however. - Cosmin ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 friendly remind them that > they can nominate themselves. so what i will do then is If a developer was in the GA before || are just under the threshold but active || are part of the infra teams and packaging i will leave them in the list to be added (that is also what jb suggested) otherwise I will contact them and ask if they want to be in the GA and update the list accordingly, removing everyone who does not reply [I will not reveal wo said 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) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 > > course welcome to nudge them via private message to friendly remind them > > that > > they can nominate themselves. > > so what i will do then is > If a developer was in the GA before || are just under the threshold but > active || are part of the infra teams and packaging > i will leave them in the list to be added (that is also what jb suggested) > otherwise > I will contact them and ask if they want to be in the GA and > update the list accordingly, removing everyone who does not reply > [I will not reveal wo said 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 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".
[FFmpeg-devel] [PATCH 1/2] sws/rgb2rgb: rework R-V V YUY2 to 4:2:2 planar
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 --git a/libswscale/riscv/rgb2rgb_rvv.S b/libswscale/riscv/rgb2rgb_rvv.S index 671089c842..172f5918dc 100644 --- a/libswscale/riscv/rgb2rgb_rvv.S +++ b/libswscale/riscv/rgb2rgb_rvv.S @@ -127,31 +127,30 @@ func ff_deinterleave_bytes_rvv, zve32x endfunc .macro yuy2_to_i422p y_shift -addia4, a4, 1 +sllit4, a4, 1 // pixel width -> (source) byte width lw t6, (sp) +sub a6, a6, a4 sraia4, a4, 1 // pixel width -> chroma width +sub a7, a7, a4 +sub t6, t6, t4 1: mv t4, a4 -mv t3, a3 -mv t0, a0 -mv t1, a1 -mv t2, a2 addia5, a5, -1 2: vsetvlit5, t4, e8, m2, ta, ma -vlseg2e16.v v16, (t3) +vlseg2e16.v v16, (a3) subt4, t4, t5 vnsrl.wi v24, v16, \y_shift // Y0 -sh2add t3, t5, t3 +sh2add a3, t5, a3 vnsrl.wi v26, v20, \y_shift // Y1 vnsrl.wi v28, v16, 8 - \y_shift // U vnsrl.wi v30, v20, 8 - \y_shift // V -vsseg2e8.v v24, (t0) -sh1add t0, t5, t0 -vse8.v v28, (t1) -addt1, t5, t1 -vse8.v v30, (t2) -addt2, t5, t2 +vsseg2e8.v v24, (a0) +sh1add a0, t5, a0 +vse8.v v28, (a1) +adda1, t5, a1 +vse8.v v30, (a2) +adda2, t5, a2 bnez t4, 2b add a3, a3, t6 -- 2.42.0 ___ 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".
[FFmpeg-devel] [PATCH 2/2] sws/rgb2rgb: fix unaligned accesses in R-V V YUYV to I422p
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 case, we can at the same time improve performance and handle unaligned inputs, so do just that. uyvytoyuv422_c: 104060.0 uyvytoyuv422_rvv_i32: 25284.0 (before) uyvytoyuv422_rvv_i32: 20148.2 (after) --- libswscale/riscv/rgb2rgb_rvv.S | 45 +- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/libswscale/riscv/rgb2rgb_rvv.S b/libswscale/riscv/rgb2rgb_rvv.S index 172f5918dc..716948dc82 100644 --- a/libswscale/riscv/rgb2rgb_rvv.S +++ b/libswscale/riscv/rgb2rgb_rvv.S @@ -126,32 +126,33 @@ func ff_deinterleave_bytes_rvv, zve32x ret endfunc -.macro yuy2_to_i422p y_shift -sllit4, a4, 1 // pixel width -> (source) byte width +.macro yuy2_to_i422p luma, chroma +srait4, a4, 1 // pixel width -> chroma width lw t6, (sp) +sllit5, a4, 1 // pixel width -> (source) byte width sub a6, a6, a4 -sraia4, a4, 1 // pixel width -> chroma width -sub a7, a7, a4 -sub t6, t6, t4 +sub a7, a7, t4 +sub t6, t6, t5 1: mv t4, a4 addia5, a5, -1 2: -vsetvlit5, t4, e8, m2, ta, ma -vlseg2e16.v v16, (a3) -subt4, t4, t5 -vnsrl.wi v24, v16, \y_shift // Y0 -sh2add a3, t5, a3 -vnsrl.wi v26, v20, \y_shift // Y1 -vnsrl.wi v28, v16, 8 - \y_shift // U -vnsrl.wi v30, v20, 8 - \y_shift // V -vsseg2e8.v v24, (a0) -sh1add a0, t5, a0 -vse8.v v28, (a1) -adda1, t5, a1 -vse8.v v30, (a2) -adda2, t5, a2 -bnez t4, 2b +vsetvli t5, t4, e8, m4, ta, ma +vlseg2e8.v v16, (a3) +srlit1, t5, 1 +vsetvli zero, t1, e8, m2, ta, ma +vnsrl.wi v24, \chroma, 0 // U +sub t4, t4, t5 +vnsrl.wi v28, \chroma, 8 // V +sh1add a3, t5, a3 +vse8.v v24, (a1) +add a1, t1, a1 +vse8.v v28, (a2) +add a2, t1, a2 +vsetvli zero, t5, e8, m4, ta, ma +vse8.v \luma, (a0) +add a0, t5, a0 +bnezt4, 2b add a3, a3, t6 add a0, a0, a6 @@ -163,9 +164,9 @@ endfunc .endm func ff_uyvytoyuv422_rvv, zve32x -yuy2_to_i422p 8 +yuy2_to_i422p v20, v16 endfunc func ff_yuyvtoyuv422_rvv, zve32x -yuy2_to_i422p 0 +yuy2_to_i422p v16, v20 endfunc -- 2.42.0 ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 their own > > volition. The circumstances are different for those on the mailing list > > and those not, but the end result is the same: don't nominate people like > > that. It's rude. > > I don't think nominating others for the GA is rude, assuming they accept the > nomination. Ok, fair enough, it varies. Shy or modest people may find it rude. Others may be proud of being nominated. But either way, I find it rude to put people on the ballot without their express request to do so. > I do agree they shouldn't be automatically be put on the GA > because of a nomination they did not accept, but it seems reasonable to ask > them if they want to accept the nomination. Yes. -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 to nudge them via private message to friendly remind them that they can nominate themselves. so what i will do then is If a developer was in the GA before || are just under the threshold but active || are part of the infra teams and packaging i will leave them in the list to be added (that is also what jb suggested) otherwise I will contact them and ask if they want to be in the GA and update the list accordingly, removing everyone who does not reply Those who you contact and wish to be part of the GA, can they reply publicly on the mailing list as well and acknowledge this? // Martin ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 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. > > > > > > > > > > Do you dispute that? > > > > > > > > There are at least 3 issues here > > > > > > > > * The first and maybe the biggest, is that our vote superviser can > > > > reply to > > > > mails within 20min (like in this thread here) but is not replying to > > > > a simple > > > > question within days where the list of voters comes from he used and > > > > how it > > > > relates to the 2020 GA. It gives one the feeling he has some sort of > > > > difficulty with awnsering that question > > > > you took a guess here and replied, and i appreciate that. But really > > > > JB > > > > choose this list and also the one in 2020. Only he can explain where > > > > these > > > > lists come from and how they relate. > > > > > > JB did explain where the list comes from [1] - it was generated by the > > > script that is now in our tree. Nobody disputed it in 2020. > > > > > > > * I know for a fact that at least zane was not in the 2020 GA as i > > > > talked > > > > with him and i know he did cast a vote in 2023 because again he told > > > > me. > > > > So even if you partially apply the rules these lists do not match > > > > > > Zane had 30 commits in July 2020, so he SHOULD have been on the list. If > > > he wasn't, then it was a mistake in 2020. > > > > the 2020 GA list cannot have been created in July 2020 because there where > > votes prior that used it. > > According to my mailbox, the vote on extra members was started on > 2020-06-18. TC/CC election vote was started on 2020-07-12. Zane had 29 > commits as of the former, and 30 as of the latter. In either case he > should have been on the list. > > With what you told us so far, it is entirely possible he was on the > original list, but > * misremembered about not receiving the vote link, or > * did not get the email because of delivery issues (we had them even now > during the first attempt to initiate the vote). And thats why iam asking questions If jb says zane was on the original list, then * did the mail bounce / fail to deliver ? * did jb see that ? * there where 3 votes i would think it would be corrected after the first bounce If jb says zane was not on the original list then thats what the current evidence suggests IMHO > > > > > > > > * The 2nd issue is that there are rules how to change the GA over time > > > > like that after 2 years there needs to a confirmation AND that the > > > > other members represent the "active" developers in the last 36 months. > > > > I can see an argument to leave the 2020 GA untouched and use it as is > > > > I can also see an argument to update it, and exactly this was done in > > > > a > > > > vote in 2021 by JB. Now we are here trying the 3rd variant of applying > > > > only half the rules. > > > > But whats more so, we actually are not. What you are doing here is > > > > looking at what happened and trying to rationalize it, trying to find > > > > an explanation for the list. Not stating upfront what this list is > > > > IMO this is not acceptable for a vote. Uhm we found this list, lets > > > > see > > > > where that might have come from > > > > > > To be honest, it very much seems to me that you are trying to bikeshed > > > the process to death. Yes, it is imperfect, but that is to be expected > > > given we've only used it a few times so far, and the last time was over > > > 2 years ago. What we are doing here is trying to clarify the rules so > > > that we actually can vote with some regularity. > > > > Is it bikesheding if 2 lists that are supposed to be the same differ in > > multiple entries ? > > It is the way you are doing it, with all these "just asking questions" > and vague accusations of impropriety. I have incomplete information so i need to ask questions. > > > 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 > > > but there where 3 on the extra voters list so really 4 differ almost > > certainly > > I do not understand this math. There where 3 extra developer voted onto the GA and there is zane. that makes 4 there is also Gautam Ramakrishnan on the posted list who simply did not have 20 commits at the time of the votes in 2020 thats 5. You cannot explain this away. Also Thilo mentioned that the number of voters was 49 without the 3 extra members in the results while the lis
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 on the list used now. In my opinion that is correct, as their voting rights expired a year ago. > > > > > but there where 3 on the extra voters list so really 4 differ almost > > > certainly > > > > I do not understand this math. > > There where 3 extra developer voted onto the GA and there is zane. > that makes 4 > there is also Gautam Ramakrishnan on the posted list who simply did not > have 20 commits at the time of the votes in 2020 > thats 5. > > You cannot explain this away. > Also Thilo mentioned that the number of voters was 49 without the 3 extra > members > in the results while the list jb posted had 51 > > These things really dont match no matter how you turn it > > And again thats why iam asking questions. The problem is, there is nothing meaningful you can do with the answers. Yes, mistakes were made in 2020. The rules were not defined clearly enough. The process for generating the list was not formalized. The lists themselves were not preserved unambiguously, apparently. Now all that is being rectified. The rules have been clarified. The list of voters has been published for the last vote, and the intent is to publish it for all future votes. I intend to update the script after the next vote, so that the extra GA members are in there and it generates the actually correct result. > > We don't need to "understand what happened", > > We do need to understand what happened. The whole project depends on the > decissions > of teh GA. This is not a joke, this is not something where we can be not sure > who was on the voter list But we are sure who was on the list, it was published. Not to mention you 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 ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 >> of >> course welcome to nudge them via private message to friendly remind them >> that >> they can nominate themselves. > > so what i will do then is > If a developer was in the GA before || are just under the threshold but > active || are part of the infra teams and packaging > i will leave them in the list to be added (that is also what jb suggested) Of course, this seems reasonable. > I will contact them and ask if they want to be in the GA and You should contact who you want, or think is necessary. But they should step forward and say so publicly that they are candidates. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] sws/rgb2rgb: fix unaligned accesses in R-V V YUYV to I422p
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 > unaligned input bitmaps. QEMU accepts it, but real hardware dose not. > > In this particular case, we can at the same time improve performance and > handle unaligned inputs, so do just that. > > uyvytoyuv422_c: 104060.0 > uyvytoyuv422_rvv_i32: 25284.0 (before) > uyvytoyuv422_rvv_i32: 20148.2 (after) > --- > libswscale/riscv/rgb2rgb_rvv.S | 45 +- > 1 file changed, 23 insertions(+), 22 deletions(-) > > diff --git a/libswscale/riscv/rgb2rgb_rvv.S b/libswscale/riscv/rgb2rgb_rvv.S > index 172f5918dc..716948dc82 100644 > --- a/libswscale/riscv/rgb2rgb_rvv.S > +++ b/libswscale/riscv/rgb2rgb_rvv.S > @@ -126,32 +126,33 @@ func ff_deinterleave_bytes_rvv, zve32x > ret > endfunc > > -.macro yuy2_to_i422p y_shift > -sllit4, a4, 1 // pixel width -> (source) byte width > +.macro yuy2_to_i422p luma, chroma > +srait4, a4, 1 // pixel width -> chroma width > lw t6, (sp) > +sllit5, a4, 1 // pixel width -> (source) byte width > sub a6, a6, a4 > -sraia4, a4, 1 // pixel width -> chroma width > -sub a7, a7, a4 > -sub t6, t6, t4 > +sub a7, a7, t4 > +sub t6, t6, t5 > 1: > mv t4, a4 > addia5, a5, -1 > 2: > -vsetvlit5, t4, e8, m2, ta, ma > -vlseg2e16.v v16, (a3) > -subt4, t4, t5 > -vnsrl.wi v24, v16, \y_shift // Y0 > -sh2add a3, t5, a3 > -vnsrl.wi v26, v20, \y_shift // Y1 > -vnsrl.wi v28, v16, 8 - \y_shift // U > -vnsrl.wi v30, v20, 8 - \y_shift // V > -vsseg2e8.v v24, (a0) > -sh1add a0, t5, a0 > -vse8.v v28, (a1) > -adda1, t5, a1 > -vse8.v v30, (a2) > -adda2, t5, a2 > -bnez t4, 2b > +vsetvli t5, t4, e8, m4, ta, ma > +vlseg2e8.v v16, (a3) > +srlit1, t5, 1 Due to the specifications of RVV, we cannot assume that on the penultimate loop iteration, the selected vector length (t5) will be even. If it is odd, then this won't work. The test hardware always picks the maximum possible, which is always even, but... This needs special handling :( > +vsetvli zero, t1, e8, m2, ta, ma > +vnsrl.wi v24, \chroma, 0 // U > +sub t4, t4, t5 > +vnsrl.wi v28, \chroma, 8 // V > +sh1add a3, t5, a3 > +vse8.v v24, (a1) > +add a1, t1, a1 > +vse8.v v28, (a2) > +add a2, t1, a2 > +vsetvli zero, t5, e8, m4, ta, ma > +vse8.v \luma, (a0) > +add a0, t5, a0 > +bnezt4, 2b > > add a3, a3, t6 > add a0, a0, a6 > @@ -163,9 +164,9 @@ endfunc > .endm > > func ff_uyvytoyuv422_rvv, zve32x > -yuy2_to_i422p 8 > +yuy2_to_i422p v20, v16 > endfunc > > func ff_yuyvtoyuv422_rvv, zve32x > -yuy2_to_i422p 0 > +yuy2_to_i422p v16, v20 > endfunc -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 > >> : > > [...] > >> 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 friendly remind them > >> that > >> they can nominate themselves. > > > > so what i will do then is > > If a developer was in the GA before || are just under the threshold but > > active || are part of the infra teams and packaging > > i will leave them in the list to be added (that is also what jb suggested) > > Of course, this seems reasonable. > > > I will contact them and ask if they want to be in the GA and > > You should contact who you want, or think is necessary. > But they should step forward and say so publicly that they are candidates. I think this is asking too much and it is unfair. We are not in any other case demanding that people announce themselfs infront of everyone for anything. Not for joining the mailing list, Not for anything else. Especially not for having vote rights. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ 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".
[FFmpeg-devel] [PATCH] checkasm: test with random bw value
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/checkasm/sbrdsp.c
@@ -190,8 +190,8 @@ static void test_hf_gen(void)
for (i = 2; i < 64; i += 2) {
memset(dst0, 0, 128 * 2 * sizeof(INTFLOAT));
memset(dst1, 0, 128 * 2 * sizeof(INTFLOAT));
-call_ref(dst0, low, alpha0, alpha1, 0.0, i, 128);
-call_new(dst1, low, alpha0, alpha1, 0.0, i, 128);
+call_ref(dst0, low, alpha0, alpha1, bw, i, 128);
+call_new(dst1, low, alpha0, alpha1, bw, i, 128);
if (!float_near_abs_eps_array((INTFLOAT *)dst0, (INTFLOAT *)dst1, EPS,
128 * 2))
fail();
bench_new(dst1, low, alpha0, alpha1, bw, i, 128);
--
2.42.0
___
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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: Remove spec-incompliant inverse quantisation
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: > > > > > Section 7.4.4 of the MPEG-2 specifications requires that the > > > > > last bit of the last coefficient be toggled so that the sum > > > > > of all coefficients is odd; both our decoder and encoder > > > > > did this only if the bitexact flag has been set (although > > > > > stuff like this should be behind AV_CODEC_FLAG2_FAST). > > > > > This patch changes this by removing the spec-incompliant > > > > > functions. > > > > > > > > This commit message should include benchamarks documenting the speed > > > > loss > > > > (of the unquantize, the IDCT and overall) > > > > It is expected that the speed of some IDCTs will be impacted negativly > > > > as the non zero terms will prevent the skiping of some significant code > > > > > > > > as well as information about how much PSNR improves (to the encoder > > > > input) > > > > > > > > Also the change is a +-1 in one spot before the IDCT, the IDCT is not > > > > bitexactly > > > > specified in MPEG-2 so one could think of this as a > > > > correct implementation followed by a IDCT that was sometimes +-1 off > > > > instead of spec non compliance > > > > > > > > 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. > > > > There was an argument presented. > > I see no argument for why the code in question is useful, can you point > to the exact text? First this: > > > > It is expected that the speed of some IDCTs will be impacted negativly > > > > as the non zero terms will prevent the skiping of some significant code Second there was an argument for compliance: > > > > Also the change is a +-1 in one spot before the IDCT, the IDCT is not > > > > bitexactly > > > > specified in MPEG-2 so one could think of this as a > > > > correct implementation followed by a IDCT that was sometimes +-1 off > > > > instead of spec non compliance Third there was no rejection of the change, but a request for measurement of the effect. I would expect an approval of the patch if the measurement leads to insignificant enough results. > > That argument could be challenged or otherwise explained why it more > > important to have this always behave like with bitexact. > > > > This could lead to "OK, I think removal is better" or if not benchmarks > > could lead to one or the other decision. > > > > Saying the burden is on whoever wants to keep the code sounds like a way > > for arbitrary code removal. While I agree getting rid of code can be a good > > thing, this would definitely take it too far. > > All code is a maintenance burden, therefore all code should have a > reason for its presence in the codebase, otherwise it should be removed. I can't see how the reason for the presence of code can be ultimately defined objectively and non-arbitrary. Alexander ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: Remove spec-incompliant inverse quantisation
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: > > > > > Section 7.4.4 of the MPEG-2 specifications requires that the > > > > > last bit of the last coefficient be toggled so that the sum > > > > > of all coefficients is odd; both our decoder and encoder > > > > > did this only if the bitexact flag has been set (although > > > > > stuff like this should be behind AV_CODEC_FLAG2_FAST). > > > > > This patch changes this by removing the spec-incompliant > > > > > functions. > > > > > > > > This commit message should include benchamarks documenting the speed > > loss > > > > (of the unquantize, the IDCT and overall) > > > > It is expected that the speed of some IDCTs will be impacted negativly > > > > as the non zero terms will prevent the skiping of some significant code > > > > > > > > as well as information about how much PSNR improves (to the encoder > > input) > > > > > > > > Also the change is a +-1 in one spot before the IDCT, the IDCT is not > > bitexactly > > > > specified in MPEG-2 so one could think of this as a > > > > correct implementation followed by a IDCT that was sometimes +-1 off > > > > instead of spec non compliance > > > > > > > > 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. > > > > There was an argument presented. > > > > That argument could be challenged or otherwise explained why it more > > important to have this always behave like with bitexact. > > > > This could lead to "OK, I think removal is better" or if not benchmarks > > could lead to one or the other decision. > > > > Saying the burden is on whoever wants to keep the code sounds like a way > > for arbitrary code removal. While I agree getting rid of code can be a good > > thing, this would definitely take it too far. > > > > To be fair, this is noncompliant spec code, it shouldn't be present at all > since it produces inconsistent results (with the spec) and there is no > device particularly needing this functionality.It's not arbitrary code > removal, it's removing something that is not needed any more since the > speed impact (pro or against) is negligible on modern computers. Please see the reply to Anton. I hope it's clearer now what I meant. > I'm of the opinion that presenting an argument against such a targeted and > specific code removal with no supportive use case should be noted but not > acted upon, until relevant proof is brought over. Yes sadly that burden > should fall on whoever is presenting the argument. I wouid disagree in general. Maybe this case is more special (targeted and specific?) then my current understanding of the matter. IIUC the leading reason for this patch is removing the code because of spec incompliance which I think is not so clear and could be argued both ways. Alexander ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: Remove spec-incompliant inverse quantisation
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 which meeting notes were published. That being the case, I don't see why Andreas should have to perform extensive testing and write extensive justification. He could have done and that would have been nice, but that is all. In this situation, it is up to whoever disagrees (and presumably was not in the meeting) to provide extensive justification why the decision should be reversed. And I'm not seeing any such thing. Also anything to shrink the amount of MMX code Looks Good To Me. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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".
[FFmpeg-devel] [PATCH] lavc/sbrdsp: R-V V hf_gen
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..e5736452ec 100644
--- a/libavcodec/riscv/sbrdsp_init.c
+++ b/libavcodec/riscv/sbrdsp_init.c
@@ -27,6 +27,9 @@ void ff_sbr_sum64x5_rvv(float *z);
float ff_sbr_sum_square_rvv(float (*x)[2], int n);
void ff_sbr_neg_odd_64_rvv(float *x);
void ff_sbr_autocorrelate_rvv(const float x[40][2], float phi[3][2][2]);
+void ff_sbr_hf_gen_rvv(float (*X_high)[2], const float (*X_low)[2],
+ const float alpha0[2], const float alpha1[2],
+ float bw, int start, int end);
void ff_sbr_hf_g_filt_rvv(float (*Y)[2], const float (*X_high)[40][2],
const float *g_filt, int m_max, intptr_t ixh);
@@ -39,6 +42,7 @@ av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
if (flags & AV_CPU_FLAG_RVB_ADDR) {
c->sum64x5 = ff_sbr_sum64x5_rvv;
c->sum_square = ff_sbr_sum_square_rvv;
+c->hf_gen = ff_sbr_hf_gen_rvv;
c->hf_g_filt = ff_sbr_hf_g_filt_rvv;
}
c->autocorrelate = ff_sbr_autocorrelate_rvv;
diff --git a/libavcodec/riscv/sbrdsp_rvv.S b/libavcodec/riscv/sbrdsp_rvv.S
index 2f3a0969d7..43fab1f65f 100644
--- a/libavcodec/riscv/sbrdsp_rvv.S
+++ b/libavcodec/riscv/sbrdsp_rvv.S
@@ -174,6 +174,56 @@ func ff_sbr_autocorrelate_rvv, zve32f
ret
endfunc
+func ff_sbr_hf_gen_rvv, zve32f
+NOHWF fmv.w.x fa0, a4
+NOHWF mv a4, a5
+NOHWF mv a5, a6
+flw ft2, 0(a2)
+fmul.s fa1, fa0, fa0 // bw * bw
+sh3add a1, a5, a1
+flw ft3, 4(a2)
+fmul.s fa2, ft2, fa0 // alpha[2]
+sh3add a0, a5, a0
+flw ft0, 0(a3)
+fmul.s fa3, ft3, fa0 // alpha[3]
+sub a5, a5, a4
+flw ft1, 4(a3)
+fmul.s fa0, ft0, fa1 // alpha[0]
+flw ft0, -16(a1) // X_low[end - 2][0]
+fmul.s fa1, ft1, fa1 // alpha[1]
+flw ft1, -12(a1) // X_low[end - 2][1]
+flw ft2, -8(a1) // X_low[end - 1][0]
+flw ft3, -4(a1) // X_low[end - 1][1]
+addia1, a1, -16
+1:
+vsetvli t0, a5, e32, m4, ta, ma
+sllit1, t0, 3
+sub a1, a1, t1
+vlseg2e32.v v0, (a1) // X_low[i - 2]
+sub a0, a0, t1
+vfslide1down.vf v8, v0, ft0 // X_low[i - 1][0]
+sub a5, a5, t0
+vfslide1down.vf v12, v4, ft1 // X_low[i - 1][1]
+vfslide1down.vf v16, v8, ft2 // X_low[i][0]
+vfslide1down.vf v20, v12, ft3 // X_low[i][1]
+vfmacc.vf v16, fa0, v0
+vfmacc.vf v20, fa0, v4
+vfmv.f.s ft0, v0
+vfnmsac.vf v16, fa1, v4
+vfmacc.vf v20, fa1, v0
+vfmv.f.s ft1, v4
+vfmacc.vf v16, fa2, v8
+vfmacc.vf v20, fa2, v12
+vfmv.f.s ft2, v8
+vfnmsac.vf v16, fa3, v12
+vfmacc.vf v20, fa3, v8
+vfmv.f.s ft3, v12
+vsseg2e32.v v16, (a0)
+bneza5, 1b
+
+ret
+endfunc
+
func ff_sbr_hf_g_filt_rvv, zve32f
li t1, 40 * 2 * 4
sh3add a1, a4, a1
--
2.42.0
___
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".
Re: [FFmpeg-devel] [ANN] Poll Results: GA voters list updates
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 > > > > Should I have been mailed about this vote? > > > > I'm pretty sure I could vote in 2020. Or am I just missing something? > > As per the rules: > > Additional members are added to the General Assembly through a vote > > after proposal by a member of the General Assembly. They are part of > > the 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. Interesting. That could be the reason why I was left out. Not sure it completely fits to the information so far. In any way it's worth pointing out. Thanks. What I don't understand: > after which they need a confirmation by the GA 1. Does that mean all additional members drop out and need a confirmation by the remaining GA? 2. What does it exactly mean to need an confirmation? Does each additional member need to ask for a confirmation after 2 years? Or should there be a GA vote, every 2 years, for all additional members that would be dropped (after asking them if they want to stay in the GA)? 3. In which way is point 2 to be co-ordinated with new votes after 2 years? The text you quoted (according to my Git archaeology it wasn't changed; only reformatted) is unfortunately a bit ambiguous and unclear :( Best regards, Alexander ___ 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".
Re: [FFmpeg-devel] [PATCH 08/24] fftools/ffmpeg_filter: remove an unnecessary sub2video_push_ref() call
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 > > threading). > > I can understand that. We will have to find a solution, won't we? (I > hope you do not consider removing a feature that people have been using > for years an option.) I am obviously not proposing that, given the amount of patches I sent so far to keep sub2video working. > I can suggest this: have demuxer code emit virtual subtitles packets to > trigger the sending of the heartbeat frames. That's what already happens, unless I misunderstand what you mean. Another possibility is to make the call independently of the state of the graph, like this --- a/fftools/ffmpeg_filter.c +++ b/fftools/ffmpeg_filter.c @@ -2274,8 +2274,7 @@ void ifilter_sub2video_heartbeat(InputFilter *ifilter, int64_t pts, AVRational t or if we need to initialize the system, update the overlayed subpicture and its start/end times */ sub2video_update(ifp, pts2 + 1, NULL); - -if (av_buffersrc_get_nb_failed_requests(ifp->filter)) +else sub2video_push_ref(ifp, pts2); } This actually seems to improve filter-overlay-dvdsub-2397, where the first subtitle appears two frames later, which more closely matches the subtitles timestamp stored in the file. -- 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".
Re: [FFmpeg-devel] [PATCH] checkasm: test with random bw value
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
--- a/tests/checkasm/sbrdsp.c
+++ b/tests/checkasm/sbrdsp.c
@@ -190,8 +190,8 @@ static void test_hf_gen(void)
for (i = 2; i < 64; i += 2) {
memset(dst0, 0, 128 * 2 * sizeof(INTFLOAT));
memset(dst1, 0, 128 * 2 * sizeof(INTFLOAT));
-call_ref(dst0, low, alpha0, alpha1, 0.0, i, 128);
-call_new(dst1, low, alpha0, alpha1, 0.0, i, 128);
+call_ref(dst0, low, alpha0, alpha1, bw, i, 128);
+call_new(dst1, low, alpha0, alpha1, bw, i, 128);
if (!float_near_abs_eps_array((INTFLOAT *)dst0, (INTFLOAT *)dst1, EPS,
128 * 2))
fail();
bench_new(dst1, low, alpha0, alpha1, bw, i, 128);
--
2.42.0
LGTM, also tested on i386, x86_64, armv7 and aarch64.
// Martin
___
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".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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 extra GA candidate I see proposed so far is Ronald. If anyone > > wants to suggest further people, please do so in this thread ASAP. > > IMHO the question of the relation of the list of people who could vote > in the last GA vote and the people who where in the general assembly > in 2020 should be awnsered before further votes. > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2023-November/316609.html > > 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 important to you!) > > The presumed 2020 General assembly as well as people who have subtantial > contributions over the lifetime of the project where the source of this list > > 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 since forever, maintains 15 > things in MAINTAINERs, is the the copyright of 56 files, over 1900 commits in > FFmpeg) > Moritz Barsnick(Member of the 2020 GA but was not on jbs list) > Lauri Kasanen (Linux / PowerPC maintainer) > Dale Curtis(14 commits in 2020 was in the 2020-GA) > Alexander Strasser (Root admin, just recently reported that he could not vote > even though he was in teh 2020-GA, 3 things in MAINTAINERs) I want to be an additional (extra) member in the GA. I have * commits in FFmpeg and reviewed patches (authored myself and applied for others) * spent time and effort in discussions on the mailing lists, issue trackers and IRC channels * admin rights to some infra structure of the project I also took part and helped organize FFmpeg representation in quite some FOSS conferences in Germany. Also was a few times at VDD. My first contact to the general multimedia community was around 2000. The first interaction with open source multimedia projects was around 2004. In the recent times I have not participated on the MLs (and IRC) much as I don't have much spare time after work. I'm hoping to continue supporting the project and help it stay alive and as awesome as it has been already over the many years since it took off. Thanks for your consideration, Alexander Strasser > foo86 (maintainer and author of dca*, dolby_e*, dtsdec, s337m) > Huiwen Ren (8 matches in the codebase of his name, avs2* and related > things maintainer) > Martin Vignali (over 200 commits in FFmpeg, left in 2019 because of > hostility) > Lou Logan (over 100 commits in FFmpeg, left in 2020, also in the > 2020-GA but not on jbs list) > Matthieu Bouron(over 200 commits in FFmpeg, recently active in 2022, 5 > entries in MAINTAINERs, 25 in copyrights) > Ruiling Song (vf_tonemap_opencl maintainer, added SIMD code to various > bits of code, last active in git in 2020) > John Stebbins (over 100 commits in FFmpeg, last active in git in 2020, 1 > copyright match) > Ting Fu(last active in April 2023, 24 commits in 2021-2023, ) > Tobias Rapp(vf_readvitc mainatiner, last commit in Jul 2023, 88 > commits in FFmpeg) > Shiyou Yin (MIPS & LoongArch maintainer, 24 matches for his name in > the source, last commit May 2023) > Reimar Döffinger (over 1400 commits in FFmpeg, root admin and last commit > in Oct 2023, 49 matches for his name in the codebase) > Aurelien Jacobs(over 1000 commits in FFmpeg, 13 entries in MAINTAINERs, > 70 copyright line matches) > Hendrik Leppkes(over 900 commits in FFmpeg, 2 entries in MAINTAINERs, 4 > copyrights, last commit in Jul 2023) > Vitor Sessak (over 900 commits in FFmpeg, 28 copyright matches) > Kostya Shishkov(over 900 commits in FFmpeg, 162 copyright matches) > Ramiro Polla (over 600 commits in FFmpeg, 5 matches in MAINTAINERs, 22 > copyright matches) > Alex Converse (over 500 commits in FFmpeg, 32 copyright matches) > Janne Grunau (over 500 commits in FFmpeg, 24 copyright matches) > Andreas Cadhalpun (over 400 commits in FFmpeg, 2 copyright matches) ___ 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".
[FFmpeg-devel] [PATCH] web: add release notes for version 6.1
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 + afireqsrc audio source filter + arls filter + ffmpeg CLI new option: -readrate_initial_burst + zoneplate video source filter + command support in the setpts and asetpts filters + Vulkan decode hwaccel, supporting H264, HEVC and AV1 + color_vulkan filter + bwdif_vulkan filter + nlmeans_vulkan filter + RivaTuner video decoder + xfade_vulkan filter + vMix video decoder + Essential Video Coding parser, muxer and demuxer + Essential Video Coding frame merge bsf + bwdif_cuda filter + Microsoft RLE video encoder + Raw AC-4 muxer and demuxer + Raw VVC bitstream parser, muxer and demuxer + Bitstream filter for editing metadata in VVC streams + Bitstream filter for converting VVC from MP4 to Annex B + scale_vt filter for videotoolbox + transpose_vt filter for videotoolbox + support for the P_SKIP hinting to speed up libx264 encoding + Support HEVC,VP9,AV1 codec in enhanced flv format + apsnr and asisdr audio filters + OSQ demuxer and decoder + Support HEVC,VP9,AV1 codec fourcclist in enhanced rtmp protocol + CRI USM demuxer + ffmpeg CLI '-top' option deprecated in favor of the setfield filter + VAAPI AV1 encoder + ffprobe XML output schema changed to account for multiple variable-fields elements within the same parent element + ffprobe -output_format option added as an alias of -of + + + This release had been overdue for at least half a year, but due to constant activity in the repository, + had to be delayed, and we were finally able to branch off the release recently, before some of the large + changes scheduled for 7.0 were merged. + + + Internally, we have had a number of changes too. The FFT, MDCT, DCT and DST implementation used for codecs + and filters has been fully replaced with the faster libavutil/tx (full article about it coming soon). + This also led to a reduction in the the size of the compiled binary, which can be noticeable in small builds. + There was a very large reduction in the total amount of allocations being done on each frame throughout video decoders, + reducing overhead. + RISC-V optimizations for many parts of our DSP code have been merged, with mainly the large decoders being left. + There was an effort to improve the correctness of timestamps and frame durations of each packet, increasing the + accurracy of variable frame rate video. + + + Next major release will be version 7.0, scheduled to be released in February. We will attempt to better stick + to the new release schedule we announced at the start of this year. + + + We strongly recommend users, distributors, and system integrators to upgrade unless they use current git master. + I hope I didn't forget to mention anything else that was notable. Attached. >From 6c00a9f3294d40b0c254ca484e171fce3e5a07fe Mon Sep 17 00:00:00 2001 From: Lynne Date: Thu, 9 Nov 2023 22:50:47 +0100 Subject: [PATCH] web: add release notes for version 6.1 --- src/index | 65 +++ 1 file changed, 65 insertions(+) diff --git a/src/index b/src/index index 5d469e0..0d68db5 100644 --- a/src/index +++ b/src/index @@ -35,6 +35,71 @@ News + 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 +afireqsrc audio source filter +arls filter +ffmpeg CLI new option: -readrate_initial_burst +zoneplate video source filter +command support in the setpts and asetpts filters +Vulkan decode hwaccel, supporting H264, HEVC and AV1 +color_vulkan filter +bwdif_vulkan filter +nlmeans_vulkan filter +RivaTuner video decoder +xfade_vulkan filter +vMix video decoder +Essential Video Coding parser, muxer and demuxer +Essential Video Coding frame merge bsf +bwdif_cuda filter +Microsoft RLE video encoder +Raw AC-4 muxer and demuxer +Raw VVC bitstream parser, muxer and demuxer +Bitstream filter for editing metadata in VVC streams +Bitstream filter for converting VVC from MP4 to Annex B +scale_vt filter for videotoolbox +transpose_vt filter for videotoolbox +support for the P_SKIP hinting to speed up libx264 encoding +Support HEVC,VP9,AV1 codec in enhanced flv format +apsnr and asisdr audio filters +OSQ demuxer and decoder +Support HEVC,VP9,AV1 codec fourcclist in enhanced rtmp protocol +CRI USM demuxer +ffmpeg CLI '-top' option deprecated in fav
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: extra members for GA
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? > > > > Alexander Strasser > > It seems clear that none of the three extra GA members were on the list > used now. In my opinion that is correct, as their voting rights expired > a year ago. > > > > > > > > but there where 3 on the extra voters list so really 4 differ almost > > > > certainly > > > > > > I do not understand this math. > > > > There where 3 extra developer voted onto the GA and there is zane. > > that makes 4 > > there is also Gautam Ramakrishnan on the posted list who simply did not > > have 20 commits at the time of the votes in 2020 > > thats 5. > > > > You cannot explain this away. > > Also Thilo mentioned that the number of voters was 49 without the 3 extra > > members > > in the results while the list jb posted had 51 > > > > These things really dont match no matter how you turn it > > > > And again thats why iam asking questions. > > The problem is, there is nothing meaningful you can do with the answers. > Yes, mistakes were made in 2020. The rules were not defined clearly > enough. The process for generating the list was not formalized. The > lists themselves were not preserved unambiguously, apparently. > > Now all that is being rectified. The rules have been clarified. The list > of voters has been published for the last vote, and the intent is to > publish it for all future votes. I intend to update the script after the > next vote, so that the extra GA members are in there and it generates > the actually correct result. for all i can tell all the votes in 2020 used consistantly the same list (which may or may not be the correct list) first without the extra members and then with teh 3 extra members. exactly how one would expect. and there where test votes prior to ensure everything worked the problem was not 2020 (from what i can know/see ATM, the problem began in 2023 First the vote just started unexpectedly with no prior test, no announcement. People didnt receive the mails, the options where not discussed. The vote had to be repeated, you wrote the announcemnt we added an option we fixed some issues in the options we tested the infrastructure and then the vote started to my surprise not by you and with a different list of voters. If the rules are ambigous and one dont know who should be on the vote list. One would post a "[RFC] Vote rules are ambigous" or "[RFC] I lost the original list of voters from 2020" and find a consensus first. Make sure things are transparent and everyone understands whats going on. None of this happened. Instead the information only slowly and after alot of questions and increasing inconsitances where found, came out. Fixing the rules, does not fix the lack of transparency. What i suggest is that in the future the vote superviser is not one person who can be overworked, stressed and forget things, but at least 2 who work together and who must agree on every step before doing it. The 2 people can be one member of the TC and one member of the CC and for each vote a different pair would be selected. (with 5 members in each committee there are 25 combinations minus anyone who doesnt volunteer and also any pair who are friends (or the same person) should be excluded) That is for the official votes like GA/TC/CC votes Anyone can of course still start their own vote Above mail is just a suggestion, if people want to keep the current system. Iam not opposed. I was just thinking about what the alternatives are and because few people i think have broad support and trust picking a always changing pair seemed a interresting option to propose. Now please flame me to death for suggesting this! I need to look into releases (which i almost certainly wont be able to finish today) Also the question about the vote supervisor was raised before in 2020 by paul 0702 12:58 Paul B Mahol(1,6K) [FFmpeg-devel] RfP Candidates Why and how you are picked to do this stuff? Can't we vote for someone else? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: Remove spec-incompliant inverse quantisation
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 and decided in a meeting, which Michael > attended (albeit remotely) and for which meeting notes were published. maybe i misremember as i was a bit sick that day but there are 2 pieces of code there was the "fast mode code" that i thought was discussed this is disabled by default and we aggreed to remove it the change here is about the default code path so this is very different it will affect users with default options. I do not remember this was discussed but its quite possible people had a different interpretation what the words meant that where said. This definitly should be tested before its applied. Whoever the burden falls on is not my argument but ATM i have many things to do so i will not be able to test this in the next days > > That being the case, I don't see why Andreas should have to perform extensive > testing and write extensive justification. He could have done and that would > have been nice, but that is all. I never meant that there should be extensive testing but teh removal of a optimization from the default codepath should be tested. Also about spec non compliance, if this was so bad, being in the default path there would be bug reports so iam a bit sceptic. not saying it shouldnt be removed just saying we should look before removing it thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: PGP signature ___ 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".
