Re: [FFmpeg-devel] Flushing while decoding , but need already decoded frames
Hi, On Fri, May 24, 2024 at 7:39 AM Andrey Turkin wrote: > Have to say, this issue has been a long grievance of mine. There is no > reason to delay frames when the decoder is set up to ignore B frames > as there is no reordering to be done > Frame threading? Ronald ___ 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] lavc/vp9: set update_map to 0 when segmentation.enabled is 0
Hi, On Wed, May 22, 2024 at 1:28 PM Hendrik Leppkes wrote: > On Wed, May 22, 2024 at 7:16 PM Lynne via ffmpeg-devel > wrote: > > I'd hate to apply fixes with no information in shared code. This can get > > removed with no information about what relies on it. > > Changing 5 different hwaccel modules to avoid one line here seems > rather silly, doesn't it? > We can add a comment, if that helps. > Comment is a good idea, I think Lynne is right there's a risk we accidentally remove it. Generally, I'd like to see more hwaccel fate coverage, e.g. a vaapi (or whatever) fate machine that runs relevant tests using hw decoder instead of sw decoder. That would protect against the same risk. Ronald ___ 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] lavc/vp9: set update_map to 0 when segmentation.enabled is 0
Hi,
On Wed, May 22, 2024 at 10:36 AM Hendrik Leppkes
wrote:
> On Thu, Feb 29, 2024 at 7:19 AM llyyr wrote:
> >
> > segmentation.update_map is never reset to 0 on a new frame, and retains
> > the value from the previous frame. This bugs out a bunch of hwaccel
> > drivers when segmentation.enabled is 0 but update_map isn't because
> > they don't ignore values behind switches. We also do this for vp8* so
> > this commit is just mirroring the vp8 logic.
> >
> > This fixes an issue with certain samples** that causes blocky
> > artifacts with vaapi and d3d11va (as far as known hwaccel drivers go).
> > Mesa worked around*** this by ignoring this field if
> > segmentation.enabled is 0, but d3d11va still doesn't work.
> >
> > *
> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/vp8.c#l811
> > ** https://github.com/mpv-player/mpv/issues/13533
> > *** https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816
> >
> > Signed-off-by: llyyr
> > ---
> > libavcodec/vp9.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index 855936cdc1c7..4a628625131e 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -717,6 +717,8 @@ static int decode_frame_header(AVCodecContext *avctx,
> > s->s.h.segmentation.feat[i].skip_enabled =
> get_bits1(>gb);
> > }
> > }
> > +} else {
> > +s->s.h.segmentation.update_map = 0;
> > }
> >
> > // set qmul[] based on Y/UV, AC/DC and segmentation Q idx deltas
> >
> > base-commit: d263fce2b209e86a5a1e8f1b6aa33430ecc2c187
> > --
>
> Change LGTM.
> I was debugging the same issue today, and found the same problem with
> some hwaccels not properly ignoring update_map when segmentation is
> disabled.
>
> Will apply soon if there are no further comments.
>
Is fine, please apply.
Ronald
___
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 v5 2/2][GSoC 2024] tests/checkasm: Add check_vvc_sad to vvc_mc.c
Hi, On Tue, May 21, 2024 at 8:01 PM Stone Chen wrote: > Adds checkasm for DMVR SAD AVX2 implementation. > > Benchmarks ( AMD 7940HS ) > vvc_sad_8x8_c: 50.3 > vvc_sad_8x8_avx2: 0.3 > vvc_sad_16x16_c: 250.3 > vvc_sad_16x16_avx2: 10.3 > vvc_sad_32x32_c: 1020.3 > vvc_sad_32x32_avx2: 60.3 > vvc_sad_64x64_c: 3850.3 > vvc_sad_64x64_avx2: 220.3 > vvc_sad_128x128_c: 14100.3 > vvc_sad_128x128_avx2: 840.3 > --- > tests/checkasm/vvc_mc.c | 38 ++ > 1 file changed, 38 insertions(+) > LGTM. Ronald ___ 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 v5 1/2][GSoC 2024] libavcodec/x86/vvc: Add AVX2 DMVR SAD functions for VVC
Hi, On Tue, May 21, 2024 at 8:01 PM Stone Chen wrote: > Implements AVX2 DMVR (decoder-side motion vector refinement) SAD > functions. DMVR SAD is only calculated if w >= 8, h >= 8, and w * h > 128. > To reduce complexity, SAD is only calculated on even rows. This is > calculated for all video bitdepths, but the values passed to the function > are always 16bit (even if the original video bitdepth is 8). The AVX2 > implementation uses min/max/sub. > > Additionally this changes parameters dx and dy from int to intptr_t. This > allows dx & dy to be used as pointer offsets without needing to use movsxd. > > Benchmarks ( AMD 7940HS ) > Before: > BQTerrace_1920x1080_60_10_420_22_RA.vvc | 106.0 | > Chimera_8bit_1080P_1000_frames.vvc | 204.3 | > NovosobornayaSquare_1920x1080.bin | 197.3 | > RitualDance_1920x1080_60_10_420_37_RA.266 | 174.0 | > > After: > BQTerrace_1920x1080_60_10_420_22_RA.vvc | 109.3 | > Chimera_8bit_1080P_1000_frames.vvc | 216.0 | > NovosobornayaSquare_1920x1080.bin | 204.0| > RitualDance_1920x1080_60_10_420_37_RA.266 | 181.7 | > --- > libavcodec/vvc/dsp.c | 2 +- > libavcodec/vvc/dsp.h | 2 +- > libavcodec/x86/vvc/Makefile | 3 +- > libavcodec/x86/vvc/vvc_sad.asm | 130 +++ > libavcodec/x86/vvc/vvcdsp_init.c | 6 ++ > 5 files changed, 140 insertions(+), 3 deletions(-) > create mode 100644 libavcodec/x86/vvc/vvc_sad.asm > LGTM. Ronald ___ 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 v4 2/2][GSoC 2024] tests/checkasm: Add check_vvc_sad to vvc_mc.c
Hi, On Sun, May 19, 2024 at 8:55 PM Stone Chen wrote: > Adds checkasm for DMVR SAD AVX2 implementation. > > Benchmarks ( AMD 7940HS ) > vvc_sad_8x8_c: 70.0 > vvc_sad_8x8_avx2: 10.0 > vvc_sad_16x16_c: 280.0 > vvc_sad_16x16_avx2: 20.0 > vvc_sad_32x32_c: 1020.0 > vvc_sad_32x32_avx2: 70.0 > vvc_sad_64x64_c: 3560.0 > vvc_sad_64x64_avx2: 270.0 > vvc_sad_128x128_c: 13760.0 > vvc_sad_128x128_avx2: 1070.0 > --- > tests/checkasm/vvc_mc.c | 38 ++ > 1 file changed, 38 insertions(+) > It appears Remi's performance concerns have been addressed separately, so this patch is good to go. Ronald ___ 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 v4 1/2][GSoC 2024] libavcodec/x86/vvc: Add AVX2 DMVR SAD functions for VVC
Hi, one more, I forgot. On Sun, May 19, 2024 at 8:46 PM Stone Chen wrote: > +pw_1: dw 1 > [..] > +vpbroadcastw m4, [pw_1] > We typically suggest to use vpbroadcastd, not w (and then pw_1: times 2 dw 1). agner shows that on e.g. Haswell, the former (d) is 1 uops with 5 cycles latency, whereas the latter (w) is 3 uops with 7 cycles latency, or more generally d is faster then w. Ronald ___ 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 v4 1/2][GSoC 2024] libavcodec/x86/vvc: Add AVX2 DMVR SAD functions for VVC
Hi, This is mostly good, the following is tiny nitpicks. On Sun, May 19, 2024 at 8:46 PM Stone Chen wrote: > +%macro INIT_OFFSET 6 ; src1, src2, dxq, dyq, off1, off2 > The macro is only used once, so you could inline it in the calling function. > > +imul%5, 128 > +imul%6, 128 > I believe shl is typically preferred over imul for powers of two. > +add %5, 2 > +add %6, 2 > And these can be integrated as a constant offset in the lea below (lea %1, [%1 + %5 * 2 + 2 * 2], same for %2). > +add %5, %3 > +sub %6, %3 > + > +lea %1, [%1 + %5 * 2] > +lea %2, [%2 + %6 * 2] [..] > +cglobal vvc_sad, 6, 11, 5, src1, src2, dx, dy, block_w, block_h, off1, > off2, row_idx, dx2, dy2 > +movsxd dx2q, dxd > +movsxd dy2q, dyd > If you change the argument type from int to intptr_t, this is not necessary anymore. > +vvc_sad_16_128: > +.loop_height: > +mov off1q, src1q > +mov off2q, src2q > +mov row_idxd, block_wd > +sar row_idxd, 4 > You could right-shift block_wd by 4 outside the loop (before .loop_height). Ronald ___ 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 v3 1/2][GSoC 2024] libavcodec/x86/vvc: Add AVX2 DMVR SAD functions for VVC
Hi, On Tue, May 14, 2024 at 4:40 PM Stone Chen wrote: > +vvc_sad_8: > +.loop_height: > +movu xm0, [src1q] > +movu xm1, [src2q] > +MIN_MAX_SAD xm2, xm0, xm1 > +vpmovzxwd m1, xm1 > +vpaddd m3, m1 > [..] > +vvc_sad_16_128: > +.loop_height: > [..] > +.loop_width: > +movu xm0, [src1q] > +movu xm1, [src2q] > +MIN_MAX_SAD xm2, xm0, xm1 > +vpmovzxwd m1, xm1 > +vpaddd m3, m1 > Wouldn't it be more efficient if the main loops did a full register worth at a time? vpbroadcastd m4, [pw_1] loop: movu m0, [src1q] movu m1, [src2q] MIN_MAX_SAD m2, m0, m1 pmaddwd m1, m4 paddd m3, m1 (And then for w8, load 2 rows per iteration using movu xmN, [row0] and vinserti128 mN, [row1], 1.) Ronald ___ 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 8/9] avcodec/vp8: Forward return of ff_vpx_init_range_decoder()
Hi, On Fri, May 17, 2024 at 11:59 PM Michael Niedermayer wrote: > Fixes: CID1507483 Unchecked return value > > Sponsored-by: Sovereign Tech Fund > Signed-off-by: Michael Niedermayer > --- > libavcodec/vp8.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c > index 19f32b34006..8e91613068a 100644 > --- a/libavcodec/vp8.c > +++ b/libavcodec/vp8.c > @@ -341,9 +341,8 @@ static int setup_partitions(VP8Context *s, const > uint8_t *buf, int buf_size) > } > > s->coeff_partition_size[i] = buf_size; > -ff_vpx_init_range_decoder(>coeff_partition[i], buf, buf_size); > > -return 0; > +return ff_vpx_init_range_decoder(>coeff_partition[i], buf, > buf_size); > } > > static void vp7_get_quants(VP8Context *s) > -- > 2.45.1 > OK. Ronald ___ 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 v3 1/2][GSoC 2024] libavcodec/x86/vvc: Add AVX2 DMVR SAD functions for VVC
Hi, On Tue, May 14, 2024 at 4:40 PM Stone Chen wrote: > Implements AVX2 DMVR (decoder-side motion vector refinement) SAD > functions. DMVR SAD is only calculated if w >= 8, h >= 8, and w * h > 128. > To reduce complexity, SAD is only calculated on even rows. This is > calculated for all video bitdepths, but the values passed to the function > are always 16bit (even if the original video bitdepth is 8). The AVX2 > implementation uses min/max/sub. > > Benchmarks ( AMD 7940HS ) > Before: > BQTerrace_1920x1080_60_10_420_22_RA.vvc | 80.7 | > Chimera_8bit_1080P_1000_frames.vvc | 158.0 | > NovosobornayaSquare_1920x1080.bin | 159.7 | > RitualDance_1920x1080_60_10_420_37_RA.266 | 146.3 | > > After: > BQTerrace_1920x1080_60_10_420_22_RA.vvc | 82.7 | > Chimera_8bit_1080P_1000_frames.vvc | 167.0 | > NovosobornayaSquare_1920x1080.bin | 166.3 | > RitualDance_1920x1080_60_10_420_37_RA.266 | 154.0 | > I assume these are FPS benchmarks? Can you provide checkasm --bench output for these functions also? Ronald ___ 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] STF 2025
Hi, On Fri, May 17, 2024 at 9:50 AM Michael Niedermayer wrote: > * Fund professional real live presence on multimedia / FOSS / buisness > related > events. we already refund individuals but i think we are lacking on the > organizational > side. We should also have on these events at least one person who can > awnser developer/user > questions and someone who can awnser buisness questions (on buisness > related events). > Maybe not 100% the same thing, but ... As you say, there's several of us (including me) that attend some of these events. In addition to sponsoring more people to go, I'd be very excited to wear FFmpeg gear and at least make the FFmpeg brand more visible. (Right now I wear videolan gear at most events.) Make some nice-looking hoodies etc. that we'd like to wear and find an efficient way to distribute them. Ronald ___ 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] 5 year plan & Inovation
Hi, On Fri, May 3, 2024 at 7:33 AM Rémi Denis-Courmont wrote: > > > Le 3 mai 2024 14:28:59 GMT+03:00, "Ronald S. Bultje" > a écrit : > >Hi, > > > >On Fri, May 3, 2024 at 1:53 AM Rémi Denis-Courmont > wrote: > > > >> Le 2 mai 2024 21:38:13 GMT+03:00, "Ronald S. Bultje" < > rsbul...@gmail.com> > >> a écrit : > >> >On Thu, May 2, 2024 at 1:44 PM Vittorio Giovara < > >> vittorio.giov...@gmail.com> > >> >wrote: > >> >> I believe the path forward would be designing a system that can > >> accommodate > >> >> both workflows > >> > > >> >I agree with this. > >> > >> I vehemently disagree with this. > >> > >> Unless you are volunteering to write such a tool, this is wishful > thinking > >> and the result is that we stick to the mailing list workflow. > >> > > > >Can you explain your disapproval? Is it that it needs work? Or money? Or > do > >you just think it's a bad idea? Or something else? > > There is no technical plan how that would actually work in practice, and I > don't think it is even feasible. Not to speak of a realistic plan who would > actually implement it and in what time frame. > To clarify: I myself much prefer gitlab's workflow and would use that if it was available. I think providing a CLI-based workflow (which Anton and some others have requested) is feasible and fair. If an email variant thereof can be made and someone wants to fund it, I think that's reasonable. But it shouldn't block allowing more people to convert to a gitlab-style workflow, which I consider far superior over what we have now. End of clarification. Ronald ___ 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] 5 year plan & Inovation
Hi, On Fri, May 3, 2024 at 1:53 AM Rémi Denis-Courmont wrote: > Le 2 mai 2024 21:38:13 GMT+03:00, "Ronald S. Bultje" > a écrit : > >On Thu, May 2, 2024 at 1:44 PM Vittorio Giovara < > vittorio.giov...@gmail.com> > >wrote: > >> I believe the path forward would be designing a system that can > accommodate > >> both workflows > > > >I agree with this. > > I vehemently disagree with this. > > Unless you are volunteering to write such a tool, this is wishful thinking > and the result is that we stick to the mailing list workflow. > Can you explain your disapproval? Is it that it needs work? Or money? Or do you just think it's a bad idea? Or something else? Ronald ___ 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] 5 year plan & Inovation
Hi, On Thu, May 2, 2024 at 1:44 PM Vittorio Giovara wrote: > I believe the path forward would be designing a system that can accommodate > both workflows > I agree with this. Ronald ___ 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] vulkan_av1: Set force_integer_mv on intra frames
Hi, On Sat, Apr 27, 2024 at 9:40 AM Mark Thompson wrote: > The flag in CBS is the value read from the bitstream (as required for > passthrough), but the specification overrides that by setting it > immediately after reading if the frame is intra. > --- > This is already done for DXVA and VDPAU. Also wondering whether this > should be done for VAAPI? > > libavcodec/vulkan_av1.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/vulkan_av1.c b/libavcodec/vulkan_av1.c > index 25ab4ecc70..694e643954 100644 > --- a/libavcodec/vulkan_av1.c > +++ b/libavcodec/vulkan_av1.c > @@ -435,7 +435,7 @@ static int vk_av1_start_frame(AVCodecContext > *avctx, > .render_and_frame_size_different = > frame_header->render_and_frame_size_different, > .allow_screen_content_tools = > frame_header->allow_screen_content_tools, > .is_filter_switchable = frame_header->is_filter_switchable, > -.force_integer_mv = frame_header->force_integer_mv, > +.force_integer_mv = frame_header->force_integer_mv || > !(frame_header->frame_type & 1), > .frame_size_override_flag = > frame_header->frame_size_override_flag, > .buffer_removal_time_present_flag = > frame_header->buffer_removal_time_present_flag, > .allow_intrabc = frame_header->allow_intrabc, > -- > 2.43.0 > Wouldn't it be better to adjust the CBS reader then? Prevents us from having to re-do this in every hw wrapper. Ronald ___ 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/vp8: Return error on error
Hi,
On Sat, Apr 27, 2024 at 7:47 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Regression since e1ba00ac8f755f37ebc8448d3dbea906d7b79da2.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/vp8.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> index f37938ad27..19f32b3400 100644
> --- a/libavcodec/vp8.c
> +++ b/libavcodec/vp8.c
> @@ -107,8 +107,11 @@ static int vp8_alloc_frame(VP8Context *s, VP8Frame
> *f, int ref)
> ref ? AV_GET_BUFFER_FLAG_REF :
> 0);
> if (ret < 0)
> return ret;
> -if (!(f->seg_map = ff_refstruct_allocz(s->mb_width * s->mb_height)))
> +f->seg_map = ff_refstruct_allocz(s->mb_width * s->mb_height);
> +if (!f->seg_map) {
> +ret = AVERROR(ENOMEM);
> goto fail;
> +}
> ret = ff_hwaccel_frame_priv_alloc(s->avctx,
> >hwaccel_picture_private);
> if (ret < 0)
> goto fail;
> --
> 2.40.1
>
OK.
Ronald
___
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] 5 year plan & Inovation
Hi, On Fri, Apr 19, 2024 at 5:58 PM Vittorio Giovara wrote: > On Fri, Apr 19, 2024 at 12:48 PM Ronald S. Bultje > wrote: > > > Hi, > > > > On Fri, Apr 19, 2024 at 2:06 PM Vittorio Giovara < > > vittorio.giov...@gmail.com> > > wrote: > > > > > On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster < > > > dcni...@gmail.com> > > > wrote: > > > > > > > If i recall correctly, there was a conversation not too long ago > about > > > what > > > > to do with all the SPI money. This seems to be a perfect use for it. > > > > 1. Set up and manage a gitlab instance > > > > 2. Move tickets from trac to there (possibly) > > > > 3. Move fate running to there > > > > > > > > > > +1 > > > > > > Another good idea would be to show negative influences the door, and > not > > > being afraid to ban them when needed. > > > Currently the CC is supposed to decide that but idk how many and which > > > people have access to the mailing list control panel. > > > > > > > The CC does not have authority to permanently ban people. See ( > > https://ffmpeg.org/community.html#Community-Committee-1): "The CC can > > remove privileges of offending members, including [..] temporary ban from > > the community. [..] Indefinite bans from the community must be confirmed > by > > the General Assembly, in a majority vote." > > > > Enough of us have access to the ML admin interface to assume this will > not > > be an issue. > > > > Thanks for the clarification, it's good to know. So correct me if I'm > wrong, the theoretical banning process is that a repeated offender is > reported enough times, the CC notices that the temporary bans have had no > effects and decides to invoke the GA to confirm a ban? > Yes. But anyone else, even you, could start a GA permaban vote also. (I'm not suggesting you do this, I'm just saying it so it's clear that it doesn't have to be initiated by a CC member.) Ronald ___ 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] 5 year plan & Inovation
Hi, On Fri, Apr 19, 2024 at 2:06 PM Vittorio Giovara wrote: > On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster < > dcni...@gmail.com> > wrote: > > > If i recall correctly, there was a conversation not too long ago about > what > > to do with all the SPI money. This seems to be a perfect use for it. > > 1. Set up and manage a gitlab instance > > 2. Move tickets from trac to there (possibly) > > 3. Move fate running to there > > > > +1 > > Another good idea would be to show negative influences the door, and not > being afraid to ban them when needed. > Currently the CC is supposed to decide that but idk how many and which > people have access to the mailing list control panel. > The CC does not have authority to permanently ban people. See ( https://ffmpeg.org/community.html#Community-Committee-1): "The CC can remove privileges of offending members, including [..] temporary ban from the community. [..] Indefinite bans from the community must be confirmed by the General Assembly, in a majority vote." Enough of us have access to the ML admin interface to assume this will not be an issue. Ronald ___ 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] Mailinglist conduct (was: [EXT] Re: Query from Reuters on XZ, open source, and Microsoft)
Nicolas, On Mon, Apr 8, 2024 at 10:41 AM Nicolas George wrote: > This, sadly, your ilk has the power to enforce. > Some CC members believe it would be helpful for you (and maybe to others) if we explicitly laid out some ground rules more explicitly, so let us try: - you are entitled to any opinion or belief you wish to hold. We are no thought police. - you are allowed to express non-defamatory versions of these opinions when it is relevant to the discussion, or in new discussions, on our mailinglist. - you are explicitly asked to *not* derail ongoing (e.g. technical) discussions with these opinions where they are not relevant; do not bring up Libav-vs-FFmpeg history or other us-vs-them conspiracies. The CC has previously requested that you refrain from such conduct [1]. Therefore, we have decided to remove your mailinglist participation privilege for 2 weeks. Yours, the CC [Ronald, JB & James supporting the decision and Michael dissenting] (Michael mentioned that he is in favor of pointing out the "negative interactions" but only for a ban if a further "negative interaction" occurs after that.) [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2023-December/318316.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".
[FFmpeg-devel] Mailinglist conduct (was: FFmpeg table at NAB)
Derek, On Wed, Apr 17, 2024 at 9:50 AM Derek Buitenhuis wrote: > I assume Thilo was hung over, and thus not on the booth. > > It is a disgrace. > This was an unnecessary personal attack, please don't do that again. Repeat offense may result in temporary bans on the mailinglist and/or IRC. Please keep it civil. Signed unanimously, your CC (Ronald, Michael, JB, James) ___ 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] Query from Reuters on XZ, open source, and Microsoft
Hi Paul, On Tue, Apr 9, 2024 at 7:47 PM Paul B Mahol wrote: > Kieran's criticism is unfounded one. As I, originally 'volunteered' in that > now 'famous' ticket about Certain Big Corpo bug report and kindly replied > in friendly manner to bug reporter and give reporter free support, me still > see no issues in that mine action. > I don't think anyone thinks that your action was bad. Quite the opposite, you were generous in donating your free time to help a company in need. They owe you thanks & more. Ronald ___ 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 v1] avcodec/cbs_vp8: Use little endian in fixed()
Hi,
On Wed, Jan 24, 2024 at 7:54 PM Dai, Jianhui J <
jianhui.j.dai-at-intel@ffmpeg.org> wrote:
> This commit adds value range checks to cbs_vp8_read_unsigned_le,
> migrates fixed() to use it, and enforces little-endian consistency for
> all read methods.
>
> Signed-off-by: Jianhui Dai
> ---
> libavcodec/cbs_vp8.c | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/cbs_vp8.c b/libavcodec/cbs_vp8.c
> index 065156c248..7a0752019b 100644
> --- a/libavcodec/cbs_vp8.c
> +++ b/libavcodec/cbs_vp8.c
> @@ -181,9 +181,11 @@ static int cbs_vp8_bool_decoder_read_signed(
> return 0;
> }
>
> -static int cbs_vp8_read_unsigned_le(CodedBitstreamContext *ctx,
> GetBitContext *gbc,
> - int width, const char *name,
> - const int *subscripts, uint32_t
> *write_to)
> +static int cbs_vp8_read_unsigned_le(CodedBitstreamContext *ctx,
> +GetBitContext *gbc, int width,
> +const char *name, const int
> *subscripts,
> +uint32_t *write_to, uint32_t
> range_min,
> +uint32_t range_max)
> {
> int32_t value;
>
> @@ -200,6 +202,14 @@ static int
> cbs_vp8_read_unsigned_le(CodedBitstreamContext *ctx, GetBitContext *g
>
> CBS_TRACE_READ_END();
>
> +if (value < range_min || value > range_max) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR,
> + "%s out of range: "
> + "%" PRIu32 ", but must be in [%" PRIu32 ",%" PRIu32 "].\n",
> + name, value, range_min, range_max);
> +return AVERROR_INVALIDDATA;
> +}
> +
> *write_to = value;
> return 0;
> }
> @@ -246,15 +256,16 @@ static int
> cbs_vp8_read_unsigned_le(CodedBitstreamContext *ctx, GetBitContext *g
> do { \
> uint32_t value; \
> CHECK(cbs_vp8_read_unsigned_le(ctx, rw, width, #name, \
> -SUBSCRIPTS(subs, __VA_ARGS__),
> )); \
> + SUBSCRIPTS(subs, __VA_ARGS__),
> , \
> + 0, MAX_UINT_BITS(width))); \
> current->name = value; \
> } while (0)
>
> #define fixed(width, name, value) \
> do { \
> uint32_t fixed_value; \
> -CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, 0,
> _value, \
> - value, value)); \
> +CHECK(cbs_vp8_read_unsigned_le(ctx, rw, width, #name, 0,
> _value, \
> + value, value)); \
> } while (0)
>
> #define bc_unsigned_subs(width, prob, enable_trace, name, subs, ...) \
> --
> 2.25.1
>
Merged.
Ronald
___
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 v2] avcodec/cbs_vp8: Improve the bitstream position check
Hi, On Tue, Mar 19, 2024 at 2:05 AM Dai, Jianhui J < jianhui.j.dai-at-intel@ffmpeg.org> wrote: > The VP8 compressed header may not be byte-aligned due to boolean > coding. Round up byte count for accurate data positioning. > > Signed-off-by: Jianhui Dai > --- > libavcodec/cbs_vp8.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/cbs_vp8.c b/libavcodec/cbs_vp8.c > index 1f7e81cfe6..bb441b7187 100644 > --- a/libavcodec/cbs_vp8.c > +++ b/libavcodec/cbs_vp8.c > @@ -328,7 +328,9 @@ static int cbs_vp8_read_unit(CodedBitstreamContext > *ctx, > return err; > > pos = get_bits_count(); > -pos /= 8; > +// Position may not be byte-aligned after compressed header; Round up > byte > +// count for accurate data positioning. > +pos = (pos + 7) / 8; > av_assert0(pos <= unit->data_size); > > frame->data_ref = av_buffer_ref(unit->data_ref); > -- > 2.34.1 > Merged. Ronald ___ 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] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
Hello, On Sat, Mar 9, 2024 at 8:25 PM Michael Niedermayer wrote: > Some members of the CC want to indefinitely ban Balling > from trac. And as our doc/community.texi says: > "Indefinite bans from the community must be confirmed by the General > Assembly, in a majority vote." > > Thus some CC member wishes to involve the public here > (really theres no other option, the GA cannot discuss/vote on what it > doesnt know) > > Also people have asked for more transparency and i strongly agree with > transparency. > For reference, Anton and I banned "balling" from IRC in November. We (FFmpeg's CC) have since then received a request to ban him from trac as well. The ban on IRC was following what happened in #ffmpeg-devel on 11/23/2023 ( https://libera.irclog.whitequark.org/ffmpeg-devel/2023-11-23) I've copied the logs from that link between 14:43 and 18:53 below here for reference. My nick is "BBB", and Anton's nick is "elenril". We also received help from jess, one of Libera's admins. 14:43 is Valerii Zapodovnikov the same person that was trolling here earlier? 14:44 yes 14:44 valzapod is his other nickname 14:57 okay so he's active in VLC and placebo too 14:57 yea 14:57 and many other projects which haven't banned him yet 15:56 and you will not be able to ban me 15:56 You want the Moscow trollfarm? 15:57 You will get it 15:57 Just do not forget I own copyright in ffmpeg too. 15:58 implying someone here asked for it. you're the one behaving how you are. maybe you feel you're completely OK, but alas that is not a view shared by many. maybe you're much better IRL, but no-one here has had the chance of experiencing that. 15:59 BTW, I really am surprised. I helped you trac progress as Balling and now that is what I get? LOL, maybe start with trac then, Biden libtard voters. Is the Russian collusion in the room with right now? 15:59 *with us 16:00 courmisch I am active also on wireshark, libtorrent 16:00 gnuradio (was), rtl-sdr project, all Intel libraries, clang now too. 16:01 Are you going and try to ban be there too? You will lose. Just like Biden lost the election, admit it 16:03 BTW, banning all VPNs is nice. Are you using same filter as wikipedia? Cool. But again, github servers do no use VPNs, they are real. And so are all different virtual machines. 16:03 Oh, and I web.archived that discussion on github 16:05 on vlc's gitlab, I mean 16:06 Biden lost the election, can you LOL??? 16:06 another maroon 16:07 JEEB: I am the same in real life, BTW. You just cannot ban a person in real life, only kill. Like that woman that said All lives matter in USA. 16:09 zadedfqul was kicked from #ffmpeg-devel by elenril [zadedfqul] 16:09 pls do NOT engage the troll 16:10 I blame TypX this time, but he did not "know" 16:13 Banning is also engaging, Anton 16:14 Just like your knowledge in top posting. 16:14 https://i.imgur.com/3tv4c5x.jpg 16:15 wsqacadq was kicked from #ffmpeg-devel by elenril [wsqacadq] 16:19 man that dude is persistent :) 16:19 does he not have something better to do with his life 16:19 takes commitment to contract a VPN just for trolling opensoars 16:20 or maybe it's provided for official Mordor public service use 16:20 :) 16:20 we'll keep banning the balling 16:20 every time I saw that, I hear the dwarfs from the hobbit 16:20 courmisch: to be honest the location from which a person is does not matter at all 16:21 s/is/comes/ 16:21 untrue 16:21 were he from a civilized country, we could use their law enforcement services 16:21 yea, but someone being an asshole or troll is not is a person problem 16:21 asdf 16:21 I was alluding to troll farms. Not every country has them, especially not on the scale of the Russian federation 16:21 *is* a person problem 16:22 obviously some devs over there are reasonable people 16:26 BTW, Trump just needed 44000 votes to win 16:27 i thought you said he won? be consistent 16:27 And so as there are up to a million ballot that were not observed he really did win. 16:27 ukrainesucks was banned on #ffmpeg-devel by BBB [*!~ ukrainesu@195.189.226.40] 16:27 ukrainesucks was kicked from #ffmpeg-devel by BBB [Your behavior is not conducive to the desired environment.] 16:27 psykose: i mean it 16:27 do NOT engage the troll 16:28 Also, Clinton was fined for Steele dossier 16:28 ukrainesuccxxks was banned on #ffmpeg-devel by BBB [*!~ ukrainesu@91.193.19.147] 16:28 ukrainesuccxxks was kicked from #ffmpeg-devel by BBB [Your behavior is not conducive to the desired environment.] 16:29 +r already 16:29 nah 16:29 I'm personally fine with +r 16:29 but if others object I won't insist on it 16:30 I don't think it's anywhere bad enough to require +r 16:30 (yet?) 16:30 Clinton was found to be using gmail 16:30 bsbsvsvsv was banned on #ffmpeg-devel by BBB [*!~ bsbsvsvsv@205.185.127.86] 16:30 bsbsvsvsv was kicked from #ffmpeg-devel by BBB [Your behavior is not conducive to the desired environment.] 16:30 dbbsbsbs was banned on #ffmpeg-devel by
Re: [FFmpeg-devel] [PATCH 2/3] lavc: replace ff_thread_get_buffer() with ff_get_buffer()
Hi Nicolas, On Fri, Mar 8, 2024 at 10:46 AM Nicolas George wrote: > [..] you can see they have in the recent years gained a > lot of influence in FFmpeg [..] > I hope you realize that is what reconciliation looks like. In other words: this was always the goal - from both "sides". You seem to be the only one disagreeing with this goal. Everyone else seems to like having experts from both "sides" work together with - not against - each other. Or in plainer terms: you're gonna have to get used to this new normal. This is it. Welcome to the new & better FFmpeg. I genuinely hope you like it. Ronald ___ 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] clarifying the TC conflict of interest rule
Hi, On Sat, Mar 2, 2024 at 12:37 AM Gyan Doshi wrote: > [..] > This recusal may be effected either directly by >the TC member, or by a vote of the Community Committee (CC) > The CC is for enforcement of behavioural guidelines (CoC), not for technical matters, so this strikes me as a bit of a stretch of the CC mandate. Ronald ___ 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] clarifying the TC conflict of interest rule
Hi, On Mon, Feb 26, 2024 at 2:17 PM Anton Khirnov wrote: > Quoting Ronald S. Bultje (2024-02-26 19:12:45) > > That's essentially what I was suggesting: run a GA vote on your proposed > > amendment, and then run a separate GA vote on Nicolas' proposed > amendment. > > They don't seem orthogonal to me though, they both replace the same > disputed line and seem pretty much mutually exclusive. > Yes. But I don't think we exclude votes based on that criteria. We both appear to agree Nicolas should not be able to prevent a vote on your suggestion, but that is also true the other way around. Ronald ___ 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] clarifying the TC conflict of interest rule
Hi, On Mon, Feb 26, 2024 at 11:34 AM Anton Khirnov wrote: > Quoting Ronald S. Bultje (2024-02-23 20:36:11) > > Hi Nicolas > > > > On Fri, Feb 23, 2024 at 2:56 AM Nicolas George wrote: > > > > > Anton Khirnov (12024-02-22): > > > > In my updated proposal, based on comments by Niklas and Rémi, I'm > > > > leaving it up to the TC member in question, based on the assumption > that > > > > TC members are honest. > > > > > > > > A "stronger" version could conceivably leave it to CC to decide > > > > ambiguous cases. Feel free to propose such a version if you prefer > it. > > > > > > Your version does nothing to address the issue of the current > situation, > > > where the contributor who has to raise an issue in front of the TC does > > > not trust one member of the TC to be unbiased on this issue. > > > > > > I therefore maintain my alternate proposition as is. > > > > > > > I think you and Anton are trying to fix different issues. I would propose > > to run independent votes over Anton's proposal and your proposal, in no > > particular order. > > I would propose people stop proposing fundamental changes to other > people's proposals and propose something of their own instead, if they > care. Otherwise we'll never get anywhere. > That's essentially what I was suggesting: run a GA vote on your proposed amendment, and then run a separate GA vote on Nicolas' proposed amendment. Ronald ___ 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/x86/hevc: fix luma 12b overflow
Hi, On Sun, Feb 25, 2024 at 5:30 PM Henrik Gramner via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > On Sun, Feb 25, 2024 at 5:42 PM Ronald S. Bultje > wrote: > > +movam13, [pw_8] > > +paddw m10, m12, m12 > > +paddw m12, m10 ; 9 * (q0 - p0) - 3 * ( q1 - p1 ) > > paddw m12, m13; + 8 > > Memory operand > > > +paddw m10, m13, m13 > > +paddw m13, m10 ; abs(9 * (q0 - p0) - 3 * ( q1 - p1 )) > > +paddw m13, [pw_8] > [...] > > +paddw m13, m12, m12 > > +paddw m13, m12 ; 3*abs(m12) > > +paddw m13, [pw_8] > > Another minor improvement would be to reorder the adds like (x + x) + > (x + 8) instead of ((x + x) + x) + 8 to allow for more > instruction-level parallelism. > New version attached. Ronald 0001-hevc-x86-deblock-fix-12bit-overflow.patch Description: Binary data ___ 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/x86/hevc: fix luma 12b overflow
Hi, On Sun, Feb 25, 2024 at 11:28 AM James Almer wrote: > On 2/25/2024 1:22 PM, Ronald S. Bultje wrote: > > On Sun, Feb 25, 2024 at 10:56 AM Ronald S. Bultje > > wrote: > > > >> Hi, > >> > >> On Sun, Feb 25, 2024 at 3:28 AM J. Dekker wrote: > >> > >>> Weak filter can overflow in delta0 calculation before >> 4 in int16. > >>> > >>> Signed-off-by: J. Dekker > >>> --- > >>> > >>> I do not know x86 simd at all, so this is just an attempt to fix > >>> the implementation rather than write extremely performant code. > >>> > >>> Suggestions welcome. > >>> > >> > >> https://pastebin.com/KvcbQ2nK > >> > > > > Attached a slightly adjusted version which does sse2 in 16bit also. > > > > Ronald > > > diff --git a/libavcodec/x86/hevc_deblock.asm > b/libavcodec/x86/hevc_deblock.asm > > index 85ee4800bb..869301caff 100644 > > --- a/libavcodec/x86/hevc_deblock.asm > > +++ b/libavcodec/x86/hevc_deblock.asm > > @@ -31,6 +31,7 @@ cextern pw_1023 > > pw_pixel_max_12: times 8 dw ((1 << 12)-1) > > pw_m2: times 8 dw -2 > > pd_1 : times 4 dd 1 > > +pd_8 : times 8 dd 8 > > This is unused. > Fixed. Ronald 0001-hevc-x86-deblock-fix-12bit-overflow.patch Description: Binary data ___ 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/x86/hevc: fix luma 12b overflow
Hi, On Sun, Feb 25, 2024 at 11:22 AM Ronald S. Bultje wrote: > > > On Sun, Feb 25, 2024 at 10:56 AM Ronald S. Bultje > wrote: > >> Hi, >> >> On Sun, Feb 25, 2024 at 3:28 AM J. Dekker wrote: >> >>> Weak filter can overflow in delta0 calculation before >> 4 in int16. >>> >>> Signed-off-by: J. Dekker >>> --- >>> >>> I do not know x86 simd at all, so this is just an attempt to fix >>> the implementation rather than write extremely performant code. >>> >>> Suggestions welcome. >>> >> >> https://pastebin.com/KvcbQ2nK >> > > Attached a slightly adjusted version which does sse2 in 16bit also. > And now without typos and whitespace changes. Ronald 0001-hevc-x86-deblock-fix-12bit-overflow.patch Description: Binary data ___ 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/x86/hevc: fix luma 12b overflow
On Sun, Feb 25, 2024 at 10:56 AM Ronald S. Bultje wrote: > Hi, > > On Sun, Feb 25, 2024 at 3:28 AM J. Dekker wrote: > >> Weak filter can overflow in delta0 calculation before >> 4 in int16. >> >> Signed-off-by: J. Dekker >> --- >> >> I do not know x86 simd at all, so this is just an attempt to fix >> the implementation rather than write extremely performant code. >> >> Suggestions welcome. >> > > https://pastebin.com/KvcbQ2nK > Attached a slightly adjusted version which does sse2 in 16bit also. Ronald 0001-hevx-x86-deblock-fix-12bit-overflow.patch Description: Binary data ___ 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/x86/hevc: fix luma 12b overflow
Hi, On Sun, Feb 25, 2024 at 3:28 AM J. Dekker wrote: > Weak filter can overflow in delta0 calculation before >> 4 in int16. > > Signed-off-by: J. Dekker > --- > > I do not know x86 simd at all, so this is just an attempt to fix > the implementation rather than write extremely performant code. > > Suggestions welcome. > https://pastebin.com/KvcbQ2nK Most of this can remain in 16bits when doing pabsw before the add. The odd thing is that if I break (intentionally) the sse2 version, the ssse3/avx checkams tests start failing occasionally also. I'm not sure why that is the case. Not sure how to measure perf impact, I don't think there is any for the non-12bit case (same number of instructions) but I didn't test very hard and the perf is not very stable... Ronald ___ 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] doc: Add infra.txt
Hi, On Sat, Feb 24, 2024 at 1:28 PM Michael Niedermayer wrote: > so if i had to maintain a public list, that list would never be reliable > I can continue updating it. The current list is: $ ssh ffmpeg.org cat /etc/group|grep samples|tr ':' '\n'|grep ,|tr ',' ' ' compn cehoyos reimar beastd llogan ubitux durandal nevcairiel daemon404 jamrial martinvignali thilo atomnuker pross elenril rsbultje lynne jdek andriy rathann rtogni reynaldo I volunteer to run that script once a year and update doc/infra.txt accordingly. Ronald ___ 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] doc: Add infra.txt
Hi, On Thu, Feb 22, 2024 at 3:54 PM Michael Niedermayer wrote: > +Fate: +~ > +fatesamples are provided via rsync. Every FFmpeg developer who has a > shell account in ffmepg.org > +should be in the samples group and be able to upload samples. > +See > https://www.ffmpeg.org/fate.html#Uploading-new-samples-to-the-fate-suite > Is there a public list of "who has a shell account on ffmpeg.org" that can be linked to here? The goal here is to help people on IRC who ask "I'd like to add a sample to fate, how do I do that?" in some other way than "ask Michael". (I know the list, but I'd like a public place so everyone can find it, not just me.) It would be useful to also add info on who the roots are. This regularly comes up and having public disclosure means we don't have to argue about it or resort to "ask Michael" :) Thanks for working on this! Ronald ___ 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 11/11] avcodec/vvcdec: add Intra Block Copy decoder
Hi, On Thu, Feb 22, 2024 at 2:15 AM Nuo Mi wrote: > +static void ibc_fill_vir_buf(const VVCLocalContext *lc, const CodingUnit > *cu) > [..] > +av_image_copy_plane(ibc_buf, ibc_stride, src, src_stride, > cu->cb_width >> hs << ps , cu->cb_height >> vs); > I'm admittedly not super-familiar with VVC, but I wonder why we need the double buffering here (from ref_pos in pic to ibc_buf, and then back from ibc_buf back to cur block in pic)? In AV1, this is done with just a single copy. Why is this done this way? Ronald ___ 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] clarifying the TC conflict of interest rule
Hi Nicolas On Fri, Feb 23, 2024 at 2:56 AM Nicolas George wrote: > Anton Khirnov (12024-02-22): > > In my updated proposal, based on comments by Niklas and Rémi, I'm > > leaving it up to the TC member in question, based on the assumption that > > TC members are honest. > > > > A "stronger" version could conceivably leave it to CC to decide > > ambiguous cases. Feel free to propose such a version if you prefer it. > > Your version does nothing to address the issue of the current situation, > where the contributor who has to raise an issue in front of the TC does > not trust one member of the TC to be unbiased on this issue. > > I therefore maintain my alternate proposition as is. > I think you and Anton are trying to fix different issues. I would propose to run independent votes over Anton's proposal and your proposal, in no particular order. For your proposal, if you want the GA to vote on it, would it be possible to please more specifically define "soon"? Does it mean "ever"? Or within what time period? Or is the period irrelevant and is the intention of desiring to work at the company at the point the conflict takes place more relevant? Thanks, Ronald ___ 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] avcodec/s302m: enable non-PCM decoding
Hi, On Sun, Feb 18, 2024 at 5:34 PM Michael Niedermayer wrote: > More formally, you could define a "party to a disagreement" as > all minimal sets of people whos non existence would resolve the > disagreement > I think I agree with this interpretation of the rules. Ronald ___ 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] STF SoWs
Hi, On Wed, Feb 7, 2024 at 9:44 AM Michael Niedermayer wrote: > [..] i see as only options left to either do a quick vote on > the finished Coverity bug fixing SoW, so a simple "is this text ok", and if > yes nothing anyone says later can create another problem. > That seems reasonable. Ronald ___ 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] STF SoWs
Hi Michael,
On Wed, Feb 7, 2024 at 7:58 AM Michael Niedermayer
wrote:
> Theres the person writing a SoW for work he wants to do.
> Theres the person who accepts the SoW in FFmpeg
> Theres the person who passes accepted SoW on to SPI/STF
>
> Iam sadly involved in more than one role here.
>
I think this is what Vittorio was referring to when he said this might be
problematic. This is essentially what conflict-of-interest means. It
doesn't mean that you're a bad person or doing something wrong, it simply
means that there's overlapping goals. For example, in this case, there
might be your personal goals ("get paid for work") vs the project goals
("get money for maintenance"). They're (partially) overlapping but not
equal, because they're different angles of the same situation.
Sometimes there is no ideal solution that satisfies everyone. As I said
before, that's normal and that's OK.
Ronald
___
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] STF SoWs
Hi, On Tue, Feb 6, 2024 at 6:04 PM Michael Niedermayer wrote: > I think you should sign a SoW that has "Merged in git master" as a > Deliverable > I already did. It was fine. > PS: do you have a single person willing to sign this Deliverable you > want ? > If not, how will the STF thing work ? > You're asking for community input for your proposal, I gave comments as requested. It's OK to disagree on things, happens all the time. You can A) ignore my suggestions and submit the proposal to STF anyway, B) submit a proposal to STF as yourself rather than as FFmpeg (but for the same tasks, on FFmpeg), C) submit a proposal using another company/non-profit (e.g. fflabs), D) not submit a proposal to STF, or E) something else ??? Ronald ___ 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] STF SoWs
Hi, On Tue, Feb 6, 2024 at 4:23 PM Michael Niedermayer wrote: > What i can and did and do suggest is > "Patches submitted for review to the FFMPEG dev mailing list. As well as > taking care of all reasonable review comments." > > If "all reasonable review comments" is not enough then what are other > review comments ? Obviously it must be UNreasonable review comments > That's again a strawman. Who decides what is reasonable? Assuming this is some community-approved process - e.g. the TC, then how is this different from going through TC to get the patch merged? Ronald ___ 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] STF SoWs
Hi, On Tue, Feb 6, 2024 at 1:17 PM Michael Niedermayer wrote: > I wont work for months to > then be at the mercy of not a single of 2000 subscribers posting some > "i object" and all 2000 know in this situation it would cause an > inconvenience to me. > That's a strawman version of how our review process works. I don't know why you're bringing this up. Ronald ___ 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] STF SoWs
Hi, On Tue, Feb 6, 2024 at 11:05 AM Niklas Haas wrote: > On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" > wrote: > > Hi, > > > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote: > > > > Hi, > > > > > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer < > > > mich...@niedermayer.cc> > > > > wrote: > > > > > > > > > 2. Deliverables > > > > > Patches submitted for review to the FFMPEG dev mailing list. > > > > > > > > > > > > > I think the goal is to get patches merged, not submitted. > > > > > > Yes but the individual developer cannot gurantee that. > > > > > > > In a bad situation, someone could send unmergeable patches and they will > > satisfy the legal requirement above for being paid out. I'm suggesting to > > protect the project against that situation. > > Unless I misunderstood you, what you are proposing protects the > Sovereign Tech Fund (aka German government), not the FFmpeg project. > This would only be a concern if we were funding work directly from the > (non-existant) FFmpeg treasury. > It was more about project reputation and the goals being pro-project rather than pro-developer. Look at it this way: if patches get submitted but not merged, is FFmpeg helped? Probably not. But money was spent using FFmpeg's reputation to secure the funding. Subsequent funding rounds will be more difficult. Requiring a merge protects the project against this bad situation. I understand that, hypothetically, if STF had funded SDR, this would be problematic, because no payment is possible for work a majority of the project's constituents doesn't want in. But maybe that ensures project funding is requested for conservative sets of tasks that everyone agrees are good for FFmpeg. So I don't see it as all bad. I don't think anyone is realistically planning to find a GA or TC majority to block patches that fix problems found by a static analyzer from going in, purely because it is known that work was paid for? That doesn't sound realistic to me. We've historically approved such patches without knowing it being declared whether they were paid for or not. But look at it from a higher level: you guys are asking for review of the STF task proposals, and I'm trying to find problems where they exist. I don't think the problem I find - or solution I propose (s/submit/merge/) - is crazy. I'm OK with different "fixes" for this problem I'm pointing out. But saying that it's not a problem... I disagree with that. Ronald ___ 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] STF SoWs
Hi, On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer wrote: > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote: > > Hi, > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer < > mich...@niedermayer.cc> > > wrote: > > > > > 2. Deliverables > > > Patches submitted for review to the FFMPEG dev mailing list. > > > > > > > I think the goal is to get patches merged, not submitted. > > Yes but the individual developer cannot gurantee that. > In a bad situation, someone could send unmergeable patches and they will satisfy the legal requirement above for being paid out. I'm suggesting to protect the project against that situation. It's the difference between a goal of "a developer getting paid for work done" or "ffmpeg maintenance being paid for". They are very closely related but have slightly different finishes. Ronald ___ 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] STF SoWs
Hi, On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer wrote: > 2. Deliverables > Patches submitted for review to the FFMPEG dev mailing list. > I think the goal is to get patches merged, not submitted. Ronald ___ 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 v2 4/4] vvcdec: reuse h26x/h2656_deblock_template.c
Hi, On Mon, Jan 8, 2024 at 10:05 PM Nuo Mi wrote: > On Tue, Jan 9, 2024 at 9:23 AM Ronald S. Bultje > wrote: > > > Hi, > > > > On Mon, Jan 8, 2024 at 8:03 PM Nuo Mi wrote: > > > > > On Sat, Jan 6, 2024 at 6:52 PM Nuo Mi wrote: > > > > > > > --- > > > > libavcodec/vvc/vvc_filter_template.c | 82 > +--- > > > > 1 file changed, 3 insertions(+), 79 deletions(-) > > > > > > > > diff --git a/libavcodec/vvc/vvc_filter_template.c > > > > b/libavcodec/vvc/vvc_filter_template.c > > > > index 9418980c33..671ed7de4e 100644 > > > > --- a/libavcodec/vvc/vvc_filter_template.c > > > > +++ b/libavcodec/vvc/vvc_filter_template.c > > > > @@ -461,6 +461,8 @@ static void > FUNC(alf_recon_coeff_and_clip)(int16_t > > > > *coeff, int16_t *clip, > > > > #define FQ2 pix[2 * xstride + 1 * ystride] > > > > #define FQ3 pix[3 * xstride + 1 * ystride] > > > > > > > > +#include "libavcodec/h26x/h2656_deblock_template.c" > > > > > > > Will merge this in two days if there are no objections to the file and > > > directory names. > > > > > > > Are there options to share the actual generated binary code? The C code > > admittedly is not so important, but it would be great if there was some > way > > to ensure that optimizations written for HEVC in some instruction set, > work > > for VVC also - or vice versa. > > > Yes. After we merge this, we will send out the mc x86 asm code for review. > It will share the same binary with HEVC. > For SAO/Deblock, we will follow a similar approach, but it needs to be a > little later than mc. > For C code, we can share the binary as well, but it involves some interface > changes, better to do it after all asm is ready. > OK, that sounds reasonable to me. Ronald ___ 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 v2 4/4] vvcdec: reuse h26x/h2656_deblock_template.c
Hi, On Mon, Jan 8, 2024 at 8:03 PM Nuo Mi wrote: > On Sat, Jan 6, 2024 at 6:52 PM Nuo Mi wrote: > > > --- > > libavcodec/vvc/vvc_filter_template.c | 82 +--- > > 1 file changed, 3 insertions(+), 79 deletions(-) > > > > diff --git a/libavcodec/vvc/vvc_filter_template.c > > b/libavcodec/vvc/vvc_filter_template.c > > index 9418980c33..671ed7de4e 100644 > > --- a/libavcodec/vvc/vvc_filter_template.c > > +++ b/libavcodec/vvc/vvc_filter_template.c > > @@ -461,6 +461,8 @@ static void FUNC(alf_recon_coeff_and_clip)(int16_t > > *coeff, int16_t *clip, > > #define FQ2 pix[2 * xstride + 1 * ystride] > > #define FQ3 pix[3 * xstride + 1 * ystride] > > > > +#include "libavcodec/h26x/h2656_deblock_template.c" > > > Will merge this in two days if there are no objections to the file and > directory names. > Are there options to share the actual generated binary code? The C code admittedly is not so important, but it would be great if there was some way to ensure that optimizations written for HEVC in some instruction set, work for VVC also - or vice versa. Ronald ___ 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] Mailinglist conduct [was: Re: [PATCH] lavc: remove the QOA decoder]
Paul,
On Thu, Dec 21, 2023 at 3:05 PM Paul B Mahol wrote:
> Say what serious feature you contributed ? - Nothing.
>
the CC requests that you please refrain from attacking fellow FFmpeg
contributors ("what serious feature [have] you contributed? - Nothing") on
the mailinglist.
Signed unanimously,
the CC illuminati (Anton, James, Jean-Baptiste, Michael, Ronald)
___
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] Mailinglist conduct [was: Re: [PATCH] lavc: remove the QOA decoder]
Hi Nicolas, On Thu, Dec 21, 2023 at 3:31 PM Nicolas George wrote: > Paul B Mahol (12023-12-21): > > Say what serious feature you contributed ? - Nothing. > > I did not want to say it, but since it is now in the open: Not nothing: > negative. His naysaying discouraged me from working further on the > built-in documentation system. > The CC deems some of your statements in this thread (here: "Not nothing: negative", and later on: "Then you need to find a different project.") to be personal attacks, in violation of our code of conduct. The CC requests that you stop such behaviour at once and refrain from it in the future. Remember that the CC has the option to take away mailinglist privileges. Unanimously signed, The CC illuminati (Anton, James, Jean-Baptiste, Michael, Ronald) ___ 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] Add new vf_tiltandshift filter
Hi Paul, On Fri, Dec 22, 2023 at 10:33 AM Paul B Mahol wrote: > There are some serious issues in this code. > While already very insightful, it would be enormously helpful if you could expand on this statement with more detail, such as a list of issues as they exist in this code. Ronald ___ 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] Mailinglist conduct [was: [RFC] fftools/ffmpeg and libavdevice/sdl issue]
Hi Nicolas,
On Tue, Dec 12, 2023 at 1:04 PM Nicolas George wrote:
> But do not expect it to be fixed, they have hated lavd for ever and now
> they have all the control.
>
Your message promotes conspiracy theories ("they have all control", "they
have hated lavd for ever", etc.) and suggests that individual members are
part of this conspiracy to destroy FFmpeg (ad hominem attack). This is not
appropriate conduct on any of our project's mailing lists; there are plenty
better ways to bring up your technical concerns. Your CC requests that in
your messages to the FFmpeg developer list, you will not engage in ad
hominem attacks or conspiracy theories. Your CC also suggests trying to
assume good faith even during disagreements.
Unanimously signed,
your CC [Anton, James, Jean-Baptiste, Michael, Ronald, The Illuminati :-)]
___
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] MAINTAINERS: remove myself from FFmpeg
Hi, On Thu, Dec 7, 2023 at 7:33 AM Michael Niedermayer wrote: > On Thu, Dec 07, 2023 at 08:29:14AM +0100, Paul B Mahol wrote: > > Attached. > > > MAINTAINERS | 55 > --- > > 1 file changed, 55 deletions(-) > > 57486b662b3460fe6704e2ec236b0cd65cfe75f9 > 0001-MAINTAINERS-remove-myself-from-FFmpeg.patch > > From b249499fccb49705ade14362875ebf4d22628fa4 Mon Sep 17 00:00:00 2001 > > From: Paul B Mahol > > Date: Thu, 7 Dec 2023 08:27:14 +0100 > > Subject: [PATCH] MAINTAINERS: remove myself from FFmpeg > > > > Signed-off-by: Paul B Mahol > > --- > > MAINTAINERS | 55 - > > 1 file changed, 55 deletions(-) > > Is there anything i can do for you to reconsider ? > > I dont think i understand the reason behind this > I think many of us don't. Paul, want to elaborate or point to a log of what happened? Ronald ___ 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 v2 7/7] avcodec: add AV_CODEC_FLAG_CLEAR
Hi, On Wed, Dec 6, 2023 at 3:23 AM Marton Balint wrote: > Signed-off-by: Marton Balint > --- > doc/APIchanges | 3 +++ > doc/codecs.texi| 14 ++ > libavcodec/avcodec.h | 4 > libavcodec/decode.c| 6 ++ > libavcodec/options_table.h | 1 + > libavcodec/version.h | 2 +- > 6 files changed, 29 insertions(+), 1 deletion(-) > > diff --git a/doc/APIchanges b/doc/APIchanges > index 416e2bec5e..f839504a64 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-12-xx - xxx - lavc 60.36.100 - avcodec.h > + Add AV_CODEC_FLAG_CLEAR. > + > 2023-12-xx - xxx - lavu 58.33.100 - imgutils.h >Add av_image_fill_color() > > diff --git a/doc/codecs.texi b/doc/codecs.texi > index 5b950b4560..0504a535f2 100644 > --- a/doc/codecs.texi > +++ b/doc/codecs.texi > @@ -76,6 +76,20 @@ Apply interlaced motion estimation. > Use closed gop. > @item output_corrupt > Output even potentially corrupted frames. > +@item clear > +Clear the contents of the video buffer before decoding the next picture > to it. > + > +Usually if only a part of a picture is affected by a decode error then the > +decoder (if it implements error concealment) tries to hide it by > interpolating > +pixels from neighbouring areas or in some cases from the previous frame. > Even > +without error concealment it is quite likely that the affected area will > +contain pixels from an earlier frame, due to frame pooling. > No comment on the patch itself, but wouldn't our users (and the C standard itself) consider it a security issue to return stale (or worse: uninitialized) data while pretending that it's safe to access? I thought touching uninitialized data was UB. Ronald ___ 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] avutil/mem: always align by at least 32 bytes
Hi, On Sun, Dec 3, 2023 at 3:10 PM Timo Rothenpieler wrote: > So if the compiler does a copy > in decode_cpe() with avx instructions, but ffmpeg is built with > --disable-avx > Ehm... What? That seems like the core bug then? Ronald ___ ffmpeg-devel 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: TC/CC elections
Hi, On Wed, Nov 29, 2023 at 7:01 PM Cosmin Stejerean via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > > On Nov 29, 2023, at 3:14 PM, Michael Niedermayer > wrote: > > > > If you give Jerry a weight of 10 and give Tom a weight of 9, that means > > you prefer Jerry over Tom because 10 > 9 > > If you give Spike a weight of 20 that would mean you not only prefer > Spike > > over Tom OR Jerry but also over Tom AND Jerry. Because 20 > 10 + 9 > > > > OTOH if you give Spike a weight of 18 that would mean you prefer Spike > over > > Tom OR Jerry but you prefer Tom AND Jerry over Spike. > > Because: 9 < 10< 18 < 9 + 10 > > Tom < Jerry < Spike < Tom and Jerry > > Is this last example the kind of preference that people are likely to want > to express in practice? It seems much harder to reason about and much more > likely to lead to mistakes. > > Given a list of say 7 candidates running for 5 positions that's 21 > possible combinations and in theory weights would have to be assigned such > that the sum for each one of those 21 combinations is correctly ranked by > order of preference. > > I think the simplicity of the simpler ranked choice voting might outweigh > the benefit of expressing complex preferences with the sum of weights. > Does ranked voting allow expressing equal weight to multiple candidates? For example, I prefer Jerry and Tom equally, but I prefer either one over Spike. Ronald ___ 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: TC/CC elections
Hi, On Tue, Nov 28, 2023 at 6:58 AM Anton Khirnov wrote: > There are reports from people on IRC that they got confused by the > change and voted the reverse of what they meant. Sadly there is no way > to change your vote after it's been case, so if there is a nontrivial > number of such people, we may want to redo the vote. > Serious suggestion: maybe the vote invitation email (or something similar) should explain in more detail how the voting is to be done if it is non-trivial? Ronald ___ 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] [IMPORTANT] banned on irc
Hi, On Fri, Nov 24, 2023 at 4:39 AM Paul B Mahol wrote: > Can not access irc anymore. > If my understanding is correct, this was caused by the +r channel mode, which means your nick needs to be registered with channel services before you can join the channel. We (me & Anton, mostly) decided to temporarily set +r yesterday because the #ffmpeg-devel channel was repeatedly being spammed with abusive (political) content. I don't think we intend this mode to be enabled permanently. We did not intend to ban Paul. Apologies to Paul for the temporary nick registration requirement. Ronald ___ 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] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi, On Sun, Nov 12, 2023 at 8:53 PM Dai, Jianhui J < jianhui.j.dai-at-intel@ffmpeg.org> wrote: > TESTS: ffmpeg -i fate-suite/vp8/frame_size_change.webm -vcodec copy > -bsf:v trace_headers -f null - > (I've merged this already.) I don't think a fate test was added to prevent regressions. Would that be useful? (I didn't see one for the other trace_headers like vp9 or av1, so it's possible the answer is "no".) Ronald ___ 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 v3] avcodec/vp8: Export `vp8_token_update_probs` variable
Hi, On Mon, Nov 13, 2023 at 8:43 AM Ronald S. Bultje wrote: > Hi, > > On Mon, Nov 13, 2023 at 2:55 AM Dai, Jianhui J < > jianhui.j.dai-at-intel@ffmpeg.org> wrote: > >> Oh, this is the preceding patch of: >> `[FFmpeg-devel,v6] avcodec/cbs_vp8: Add support for VP8 codec bitstream` >> >> Probably, I need merge these two together. >> > > It's ok like this, for me. I'll let this sit for 48 hours for others to > comment. After that, I will merge (both patches) for you later this week if > no other review comments come in. > Both patches pushed. Ronald ___ 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] Repeat vote: GA voters list updates
On Tue, Nov 14, 2023 at 2:28 PM Nicolas George wrote: > but nobody here knows > Unsubstantiated FUD. Move on. Ronald ___ 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] Repeat vote: GA voters list updates
Hi, On Tue, Nov 14, 2023 at 1:44 PM Nicolas George wrote: > Nothing prevents their boss from telling them how to vote, even if the > ballots are secret. > How is this not just unsubstantiated FUD? We're discussing concerns that are randomly thrown in without evidence that they're relevant or real. I think that we should protect FFmpeg's GA from alien invasions. And I want a pony. Ronald ___ 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 v3] avcodec/vp8: Export `vp8_token_update_probs` variable
Hi, On Mon, Nov 13, 2023 at 2:55 AM Dai, Jianhui J < jianhui.j.dai-at-intel@ffmpeg.org> wrote: > Oh, this is the preceding patch of: > `[FFmpeg-devel,v6] avcodec/cbs_vp8: Add support for VP8 codec bitstream` > > Probably, I need merge these two together. > It's ok like this, for me. I'll let this sit for 48 hours for others to comment. After that, I will merge (both patches) for you later this week if no other review comments come in. Ronald ___ 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 v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi, On Wed, Nov 8, 2023 at 10:55 AM Ronald S. Bultje wrote: > Hi Jianhui, > > On Tue, Nov 7, 2023 at 8:52 PM Dai, Jianhui J < > jianhui.j.dai-at-intel@ffmpeg.org> wrote: > >> The smaller delta patch to export the variable: >> https://patchwork.ffmpeg.org/project/ffmpeg/patch/dm6pr11mb268186349e600824e1577dfdb1...@dm6pr11mb2681.namprd11.prod.outlook.com/ >> Personally, I prefer to limit the static data only in vp8.c. >> > > Understood. It's going to be a dice-roll either way, and since I'm the > maintainer, I get to pick :-). I prefer continuing with what we have in > this version, but I'll leave it open for the majority opinion to overrule > me for a few days before we merge this. > Actually, I realize that sounds quite rude, so let me elaborate: I prefer external data tables (in a separate source file from the rest of the code) because they tend to be big and clunky and you can't really change them anyway. They are essentially binary blob in numerical form. We use external data tables in quite a few parts of ffmpeg and I've grown accustomed to that design. For now, for old codecs where nothing much changes over time, I prefer to keep it as it is. Small diffs means easy to trace back when stuff breaks, as a general rule. But I admit that all this is personal preference. There's nothing wrong with a different approach, it's just that: different. Let's agree on a color (green!) and move on to shiny new objects. Ronald ___ 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 v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi Jianhui, On Tue, Nov 7, 2023 at 8:52 PM Dai, Jianhui J < jianhui.j.dai-at-intel@ffmpeg.org> wrote: > The smaller delta patch to export the variable: > https://patchwork.ffmpeg.org/project/ffmpeg/patch/dm6pr11mb268186349e600824e1577dfdb1...@dm6pr11mb2681.namprd11.prod.outlook.com/ > Personally, I prefer to limit the static data only in vp8.c. > Understood. It's going to be a dice-roll either way, and since I'm the maintainer, I get to pick :-). I prefer continuing with what we have in this version, but I'll leave it open for the majority opinion to overrule me for a few days before we merge this. Do you need me to merge or do you have commit access? If you adapt the cbs patch to use this (newly) exported table, I have no further review comments. Ronald ___ 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 v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi,
On Tue, Nov 7, 2023 at 12:01 AM Dai, Jianhui J <
jianhui.j.dai-at-intel@ffmpeg.org> wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Ronald S. Bultje
> > Sent: Monday, November 6, 2023 8:08 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for
> > VP8 codec bitstream
> >
> > Hi,
> >
> > On Mon, Nov 6, 2023 at 7:07 AM Ronald S. Bultje
> > wrote:
> >
> > > On Sun, Nov 5, 2023 at 11:13 PM Dai, Jianhui J <
> > > jianhui.j.dai-at-intel@ffmpeg.org> wrote:
> > >
> > >> > > +static const uint8_t vp8_token_update_probs[4][8][3][11] = {
> > >> >
> > >> > It would be nice if these symbols could be re-used from the
> > >> > existing vp8 native decoder, instead of duplicating them? Both
> > >> > source + binary size
> > >> are
> > >> > relevant here.
> > >>
> > >> Including vp8data.h would introduce many unwanted static tables other
> > >> than vp8_token_update_probs and increase the binary size.
> > >> As suggested in patch v3, it is better to use local defined
> > >> vp8_token_update_probs.
> > >>
> > >
> > > I didn't mean to include vp8data.h. I mean to include a new *.h that
> > > declares extern const uint8_t vp8_token_update_probs[][][][] and move
> > > said table into a new *.c file. The point is to prevent symbol
> duplication.
> > >
> >
> > And to elaborate further, in case it's unclear: the symbol move means the
> > native VP8 decoder would include this probability table using the same
> new
> > mechanism also. It would no longer exist in vp8data.h.
>
> Right.
> I made another change to reorganize the vp8data.[c|h] and only export `
> ff_vp8_dct_cat_prob` and `ff_vp8_token_default_probs`.
> Please take a look.
>
I'm not sure it's a good idea to move all tables back into vp8.c. There's a
reason we added it in a separate header file, so that "large random tables
with numbers" don't obfuscate the actual source code file. Or to say it
diffrently: you could probably have accomplished the same effect with a
much smaller diff... That's just my opinion though. Anyone else care about
any of this?
Ronald
___
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 v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi,
On Mon, Nov 6, 2023 at 7:07 AM Ronald S. Bultje wrote:
> On Sun, Nov 5, 2023 at 11:13 PM Dai, Jianhui J <
> jianhui.j.dai-at-intel@ffmpeg.org> wrote:
>
>> > > +static const uint8_t vp8_token_update_probs[4][8][3][11] = {
>> >
>> > It would be nice if these symbols could be re-used from the existing vp8
>> > native decoder, instead of duplicating them? Both source + binary size
>> are
>> > relevant here.
>>
>> Including vp8data.h would introduce many unwanted static tables other
>> than vp8_token_update_probs and increase the binary size.
>> As suggested in patch v3, it is better to use local defined
>> vp8_token_update_probs.
>>
>
> I didn't mean to include vp8data.h. I mean to include a new *.h that
> declares extern const uint8_t vp8_token_update_probs[][][][] and move said
> table into a new *.c file. The point is to prevent symbol duplication.
>
And to elaborate further, in case it's unclear: the symbol move means the
native VP8 decoder would include this probability table using the same new
mechanism also. It would no longer exist in vp8data.h.
Ronald
___
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 v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi,
On Sun, Nov 5, 2023 at 11:13 PM Dai, Jianhui J <
jianhui.j.dai-at-intel@ffmpeg.org> wrote:
> > > +static const uint8_t vp8_token_update_probs[4][8][3][11] = {
> >
> > It would be nice if these symbols could be re-used from the existing vp8
> > native decoder, instead of duplicating them? Both source + binary size
> are
> > relevant here.
>
> Including vp8data.h would introduce many unwanted static tables other than
> vp8_token_update_probs and increase the binary size.
> As suggested in patch v3, it is better to use local defined
> vp8_token_update_probs.
>
I didn't mean to include vp8data.h. I mean to include a new *.h that
declares extern const uint8_t vp8_token_update_probs[][][][] and move said
table into a new *.c file. The point is to prevent symbol duplication.
Ronald
___
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 v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi,
On Sun, Nov 5, 2023 at 7:56 PM Dai, Jianhui J <
jianhui.j.dai-at-intel@ffmpeg.org> wrote:
> This commit adds support for VP8 bitstream read methods to the cbs
> codec. This enables the trace_headers bitstream filter to support VP8,
> in addition to AV1, H.264, H.265, and VP9. This can be useful for
> debugging VP8 stream issues.
>
> The CBS VP8 implements a simple VP8 boolean decoder using GetBitContext
> to read the bitstream.
>
Is it possible to re-use the existing vp56rac decoder for this? Having two
arithmetic bool decoders that do the same thing is a bit weird.
> +static const uint8_t vp8_token_update_probs[4][8][3][11] = {
>
It would be nice if these symbols could be re-used from the existing vp8
native decoder, instead of duplicating them? Both source + binary size are
relevant here.
I'm also wondering if - longer-term - it makes sense to try to merge some
of these concepts back into the native decoders, objects like
Vp8RawFameHeader, but I'm guessing that's not super-urgent...
Ronald
___
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
Hi, On Sun, Nov 5, 2023 at 6:25 PM James Almer wrote: > On 11/5/2023 4:57 PM, Ronald S. Bultje wrote: > > Hi, > > > > On Sun, Nov 5, 2023 at 4:24 AM Anton Khirnov wrote: > > > >> Please suggest candidates in replies to this email, with a short > >> description of how they contribute to the project. > >> > > > > Myself, please. I currently maintain the VP8/VP9 decoders and sometimes > > review AV1-related work also, although James is the author/maintainer of > > most of that stuff. Plus I've been nominated for CC somehow. I've > > You can reject the nomination for CC if you don't want to be part of it, > and only ask to be in the GA. > It's OK, JB asked nicely and I can do it. Ronald ___ 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
Hi, On Sun, Nov 5, 2023 at 4:24 AM Anton Khirnov wrote: > Please suggest candidates in replies to this email, with a short > description of how they contribute to the project. > Myself, please. I currently maintain the VP8/VP9 decoders and sometimes review AV1-related work also, although James is the author/maintainer of most of that stuff. Plus I've been nominated for CC somehow. I've historically also done other work about wmavoice or http or matroskadec or rtsp, but am not really active in those areas anymore. Outside FFmpeg, I also contribute to dav1d. Ronald ___ 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] financial sustainability Plan A (SPI)
On Sun, Oct 29, 2023 at 3:46 PM Nicolas George wrote: > Ronald S. Bultje (12023-10-29): > > *You* may well end up not accepting their offered help, and that's your > > call to make. But if others in our community end up accepting their > offered > > help, there's nothing you can do against it. > > Other in the community are free to do as they choose on their own, of > course. > > But the project itself should never accept obligations to a corporate > entity. Never. > "The project" is not a legal entity, how could it? It's not even possible. Ronald ___ 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] financial sustainability Plan A (SPI)
Hi Nicolas, On Sun, Oct 29, 2023 at 12:47 PM Nicolas George wrote: > Rémi Denis-Courmont (12023-10-29): > > And unfortunately, I do believe that Ronald is correct in pointing out > > that big companies will want oversight in exchange for money. > > And this is why the only acceptable answer is: to hell with them and > anybody who supports them. > No. *You* may well end up not accepting their offered help, and that's your call to make. But if others in our community end up accepting their offered help, there's nothing you can do against it. Ronald ___ 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] financial sustainability Plan A (SPI)
Hi Thilo, On Sat, Oct 28, 2023 at 11:31 AM Thilo Borgmann via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > What this is about, is to set up a way to properly spend the SPI money > aside > from travel & hw. Why we should not do it because some companies > beurocracy, I > cannot see. > I sincerely don't think the above description is what Kieran meant when he talked about sustainability at Demuxed, which this thread seems to be a response to. I'm happy to elaborate, but I think we're talking about two completely different things at this point. Spending SPI money is great. But Kieran talked about *raising* donations from the very companies you (seem to?) prefer to ignore because of their bureaucracy. If we're talking about distinct things, we'll likely end up with distinct (and multiple) solutions. Ronald ___ 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] financial sustainability Plan A (SPI)
Hi,
On Thu, Oct 26, 2023 at 11:45 AM Michael Niedermayer
wrote:
> This is financial sustainability Plan A (SPI)
> ATM SPI has like 150k $, we do not activly seek donations, we do not
> currently
> use SPI money to fund any development. SPI money is ultimately controlled
> by
> the FFmpeg community and everything is transparent and public.
>
> 1. We should fund some FFmpeg development with SPI-FFmpeg money
> 2. We should activly seek more donations for SPI-FFmpeg
>
> To help 2. we should favor flashy, cool development that can bring in more
> donations
>
Hm... There's a lot going in the above. I'd like to dissect. With 2, are
you looking for end user donations, or corporate contributions? Without
trying to be too picky, I believe they are different. Users like flashy new
features. My impression from discussions is that corporations are asking
for a lot of things, but flashy new features aren't the ones I've heard
them ask for.
With his Demuxed lightning talk, Kieran was aiming for corporate
contributions, not end user donations. I'd like to play advocate for the
devil for a second. Why would they do that? What might their desired
outcomes be?
- a more stable, polite, professional community (community sustainability)
- continued codebase maintenance, support, bugfixing (codebase
sustainability)
- so that devs who write features important to them might stay around and
maintain said features and possibly even become friendly mentors /
reviewers for future contributors - maybe even develop more features
(developer sustainability)
I also think they'd like safeguards in place. If they are willing to set
aside non-trivial amounts of *their* (not ours) money that can pay for the
annual lifelihood of a fulltime developer ("salary"), then this can no
longer be carried with community votes of an often hostile community. I
agree with Michael's point earlier that 501c3 donations are tax-deductible
for US-based corporations, which might be helpful. Maybe that can be done
with EU-based non-profits also (not an expert there). More importantly,
though, is that I doubt they would just "give" the money and sit on the
sidelines. They'd ask for a seat at the table in return - it is *their*
money, after all. In US non-profits, this is called an advisory board.
Also, these non-profits are usually run by an executive director which has
the support of that board & community. This guarantees some professional
accountability, e.g. to ensure the donations are used for useful purposes
in a somewhat-professional/accountable fashion (not just parties).
Some of this probably sounds scary to some of you. But the idea that they'd
just throw us some money and see what happens is equally scary to them. Our
community's track record (professionalism, politeness, self-sustainability)
is not good enough for that.
Ronald
___
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 v2 00/13] YUVJ removal
Hi, On Fri, Oct 20, 2023 at 12:14 PM Vittorio Giovara < vittorio.giov...@gmail.com> wrote: > tbh while it's great that this functionality exists *somewhere* in ffmpeg, > this is really something that should belong to the scaler filter (whichever > implementation) > I agree. The reason this was done separately was to be able to have it at all. I considered doing it in sws and realized I probably wouldn't finish it. This was a path of less resistance. Thanks for the difficult-to-add feature list. (I may have some more questions later on - need to do some research for understanding.) Ronald ___ 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 v2 00/13] YUVJ removal
Hi, On Sat, Oct 14, 2023 at 11:16 AM Vittorio Giovara < vittorio.giov...@gmail.com> wrote: > On Sat, Oct 14, 2023 at 9:11 AM Lynne wrote: > > colorspace doesn't make it impossible to introduce all that is needed. > > It's a cleaner codebase that we can extend. > > * that only works on a subset of colorspaces. > Last time I checked, it would have required a massive lift to support > anything with constant luminance or the icpct formats. > Not at all related to the patchset anymore... But I'm curious what's missing here, could you elaborate? It would be nice to have that documented somewhere. Ronald ___ 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/svt-av1: Set force_key_frames only when gop_size == 1
Hi,
On Wed, Oct 4, 2023 at 5:05 PM Vignesh Venkat wrote:
> On Wed, Oct 4, 2023 at 10:23 AM Ronald S. Bultje
> wrote:
> >
> > Hi,
> >
> > On Tue, Oct 3, 2023 at 6:53 PM Vignesh Venkatasubramanian via
> ffmpeg-devel wrote:
> >>
> >> SVT-AV1 does not support requesting keyframes at arbitrary points
> >> by setting pic_type to EB_AV1_KEY_PICTURE. So set force_key_frames
> >> to 1 only when gop_size == 1.
> >>
> >> Please see the comments in
> >> https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 for a bit more
> >> details.
> >>
> >> Signed-off-by: Vignesh Venkatasubramanian
> >> ---
> >> libavcodec/libsvtav1.c | 9 +++--
> >> 1 file changed, 7 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> >> index 5015169244..8d2c7f3be4 100644
> >> --- a/libavcodec/libsvtav1.c
> >> +++ b/libavcodec/libsvtav1.c
> >> @@ -253,8 +253,13 @@ static int
> config_enc_params(EbSvtAv1EncConfiguration *param,
> >> // In order for SVT-AV1 to force keyframes by setting pic_type to
> >> // EB_AV1_KEY_PICTURE on any frame, force_key_frames has to be
> set. Note
> >> // that this does not force all frames to be keyframes (it only
> forces a
> >> -// keyframe with pic_type is set to EB_AV1_KEY_PICTURE).
> >> -param->force_key_frames = 1;
> >> +// keyframe with pic_type is set to EB_AV1_KEY_PICTURE). As of
> now, SVT-AV1
> >> +// does not support arbitrary keyframe requests by setting
> pic_type to
> >> +// EB_AV1_KEY_PICTURE, so it is done only when gop_size == 1.
> >> +// FIXME: When SVT-AV1 supports arbitrary keyframe requests, this
> code needs
> >> +// to be updated to set force_key_frames accordingly.
> >> +if (avctx->gop_size == 1)
> >> +param->force_key_frames = 1;
> >>
> >> if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
> >> param->frame_rate_numerator = avctx->framerate.num;
> >> --
> >> 2.42.0.582.g8ccd20d70d-goog
> >
> >
> > Seems reasonable to me.
> >
> > Can you merge, or should I merge for you?
> >
>
> Thanks Ronald. I don't have commit access. Can you please merge it?
>
Done.
Ronald
___
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/svt-av1: Set force_key_frames only when gop_size == 1
Hi,
On Tue, Oct 3, 2023 at 6:53 PM Vignesh Venkatasubramanian via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> SVT-AV1 does not support requesting keyframes at arbitrary points
> by setting pic_type to EB_AV1_KEY_PICTURE. So set force_key_frames
> to 1 only when gop_size == 1.
>
> Please see the comments in
> https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 for a bit more
> details.
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> libavcodec/libsvtav1.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> index 5015169244..8d2c7f3be4 100644
> --- a/libavcodec/libsvtav1.c
> +++ b/libavcodec/libsvtav1.c
> @@ -253,8 +253,13 @@ static int config_enc_params(EbSvtAv1EncConfiguration
> *param,
> // In order for SVT-AV1 to force keyframes by setting pic_type to
> // EB_AV1_KEY_PICTURE on any frame, force_key_frames has to be set.
> Note
> // that this does not force all frames to be keyframes (it only
> forces a
> -// keyframe with pic_type is set to EB_AV1_KEY_PICTURE).
> -param->force_key_frames = 1;
> +// keyframe with pic_type is set to EB_AV1_KEY_PICTURE). As of now,
> SVT-AV1
> +// does not support arbitrary keyframe requests by setting pic_type to
> +// EB_AV1_KEY_PICTURE, so it is done only when gop_size == 1.
> +// FIXME: When SVT-AV1 supports arbitrary keyframe requests, this
> code needs
> +// to be updated to set force_key_frames accordingly.
> +if (avctx->gop_size == 1)
> +param->force_key_frames = 1;
>
> if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
> param->frame_rate_numerator = avctx->framerate.num;
> --
> 2.42.0.582.g8ccd20d70d-goog
>
Seems reasonable to me.
Can you merge, or should I merge for you?
Ronald
___
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 v1] avcodec/hevcpred_template: Removed unreachable code
Hi,
On Tue, Oct 3, 2023 at 4:15 AM Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff
Engineer/Samsung Electronics wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Ronald
> > S. Bultje
> > Sent: poniedziałek, 2 października 2023 15:49
> > To: FFmpeg development discussions and patches
> > Cc: Dawid Kozinski ; d.frankie...@samsung.com
> > Subject: Re: [FFmpeg-devel] [PATCH v1] avcodec/hevcpred_template: Removed
> > unreachable code
> >
> > Hi,
> >
> > On Fri, Sep 29, 2023 at 4:32 AM Dawid Kozinski
> > wrote:
> >
> > > Signed-off-by: Dawid Kozinski
> > > ---
> > > libavcodec/hevcpred_template.c | 11 ---
> > > 1 file changed, 4 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/libavcodec/hevcpred_template.c
> > > b/libavcodec/hevcpred_template.c index 16d1c7f35f..46bd806523 100644
> > > --- a/libavcodec/hevcpred_template.c
> > > +++ b/libavcodec/hevcpred_template.c
> > > @@ -213,13 +213,10 @@ do { \
> > > j = 0;
> > > while (j < size_max_x && !IS_INTRA(j, -1))
> > > j++;
> > > -if (j > 0)
> > > -if (cand_up_left) {
> > > -EXTEND_LEFT_CIP(top, j, j + 1);
> > > -} else {
> > > -EXTEND_LEFT_CIP(top, j, j);
> > > -top[-1] = top[0];
> > > -}
> > > +if (j > 0) {
> > > +EXTEND_LEFT_CIP(top, j, j);
> > > +top[-1] = top[0];
> > > +}
> > > left[-1] = top[-1];
> > > }
> > > left[-1] = top[-1];
> > > --
> > > 2.25.1
> > >
> >
> > LGTM.
> >
> > Can you merge yourself, or do you need me to merge for you?
>
> Thank you for review.
> If you can, merge it, please.
>
Done.
Ronald
___
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 v1] avcodec/hevcpred_template: Removed unreachable code
Hi,
On Fri, Sep 29, 2023 at 4:32 AM Dawid Kozinski
wrote:
> Signed-off-by: Dawid Kozinski
> ---
> libavcodec/hevcpred_template.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/hevcpred_template.c
> b/libavcodec/hevcpred_template.c
> index 16d1c7f35f..46bd806523 100644
> --- a/libavcodec/hevcpred_template.c
> +++ b/libavcodec/hevcpred_template.c
> @@ -213,13 +213,10 @@ do { \
> j = 0;
> while (j < size_max_x && !IS_INTRA(j, -1))
> j++;
> -if (j > 0)
> -if (cand_up_left) {
> -EXTEND_LEFT_CIP(top, j, j + 1);
> -} else {
> -EXTEND_LEFT_CIP(top, j, j);
> -top[-1] = top[0];
> -}
> +if (j > 0) {
> +EXTEND_LEFT_CIP(top, j, j);
> +top[-1] = top[0];
> +}
> left[-1] = top[-1];
> }
> left[-1] = top[-1];
> --
> 2.25.1
>
LGTM.
Can you merge yourself, or do you need me to merge for you?
Ronald
___
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/svt-av1: Set pic_type only when gop_size == 1
Hi Vignesh, On Thu, Sep 28, 2023 at 12:14 AM Vignesh Venkatasubramanian via ffmpeg-devel wrote: > SVT-AV1 does not support requesting keyframes at arbitrary points > by setting pic_type to EB_AV1_KEY_PICTURE. > > This patch changes the following: > * Set pic_type to EB_AV1_KEY_PICTURE only when gop_size == 1. This >only has an effect in this case (combined with force_key_frames). >In all other cases, setting this has no effect. > * Set force_key_frames to 1 only when gop_size == 1, this is >needed for pic_type request above to work. > > Please see the comments in > https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 for a bit more > details. > Right. So, if I put my archeologist hat on, is it fair to say that what probably happened is that force_key_frames used to not exist, and pic_type worked as per above code. Then force_key_frames was required (because of quality implications), breaking the above code. And now we're removing the broken code because otherwise there's a quality penalty. Is that fair? I agree it's probably unfair to ask you to fix the broken use case that was previously possible (I suppose this comes down to exposing an option to set force_key_frames by having the user indicate s/he'll be using pic_type). However, maybe we should not remove the dead code, because it's functionally OK. Maybe we even need a FIXME above the line where we set force_key_frames only if gop_size==1, explaining this is a bug. WDYT? (It feels a bit weird to remove it because it's broken, is what I'm trying to say, especially because we know how to fix it.) Ronald ___ 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
Hi, On Wed, Sep 27, 2023 at 10:27 PM Nicolas George wrote: > Michael Niedermayer (12023-09-27): > > With SDR they do ask for a seperate library. > > And they are being dishonest in that. Nothing successful starts as a > library > Didn't dav1d start as a library? (Or maybe it's not very successful by your standards.) x264/5 are external libs, also. I don't think we have to be absolutist about these things. Nothing's quite so black/white. Ronald ___ 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
Hi Michael, On Tue, Sep 26, 2023 at 7:16 PM Michael Niedermayer wrote: > Should i ask the counter-question ? > are the developers who have less than 10 commits since 2017 abusing > something > by organizing and rallying the people against SDR, against the domain owner > and against me ? > Hm... That's not very nice of you. I hope this is not targeted at me. That's honestly under the belt, if it is. Ronald ___ 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] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Hi Michael, On Sun, Sep 24, 2023 at 6:45 PM Michael Niedermayer wrote: > I disagree > * Who is and is not a member of the GA is in flux, there can be disputes > even on GA membership. > * You cannot have something owned by a group like that. There needs to be > an individual like a treassurer who has the actual key. > So you again trust one person, this is not different from what it is > now. > > Also democracies can make really bad decissions. Which iam sure you have > never seen occur ;) > > And last but not least, this is attackable even unintentionally > you just need for a single moment a majority in the GA that is > bad. This is not hard to reach, a group can easily pose as enough > active developers to achieve 51% and if the domain then really is > legally controlled by the GA. yeah goodby domain > this is not a scenario possible with fabrice having theretical veto > power. > So Yes, i strongly favor fabrice keeping this veto power. > Yes, these are good points / concerns, and I share most of this. (I think it's important to state this explicitly.) So, the question is: do you think we can find a middle ground here where you and I (and other GA members, obviously) might agree on what legal entity could be the holder of this "certificate of ownership"? And do you think it would make sense that in practice, one person elected by (for example) the TC or GA actually practically "has" that key, in the role of executing the "will of the assembly" (similar to treasurer, indeed)? I think we're essentially trying to define a democratic governance model here. Or do you explicitly think that Fabrice owning it is the only good way forward? (More like a benevolent king model.) And sure i can probably word above mail more convincingly if i go > over it 3 times and send it tomorrow but i belive you understand > my point even with it just roughly worded > Thumbs-up-emoji. Ronald ___ 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] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Hi Michael, On Sun, Sep 24, 2023 at 11:09 AM Michael Niedermayer wrote: > On Sun, Sep 24, 2023 at 09:37:03AM +0100, Kyle Swanson wrote: > > Gitlab (or something like Gitlab) > > - > > > > - Ronald is proposing that we move to Gitlab, or something similar > > (gitea). > > - Michael says "i don't like Gitlab"; Ronald says the exact tool is not > > important and we can work together to make sure that the new tool suits > > other styles of work, such as command line tools. > > > - No strong dissent in the room, acceptable to most. > > strong dissent by me against any move making FFmpeg more dependant on > other projects. (videolan or gitlhub or whatevr) > > also IMO major changes cannot be done with just 51% majority, thats not > really > normal. > > iam not fundamentally against moving to better software (hell, why would i) > but trac and git work fine > and fate well, some fate clients are down since i moved one of my > boxes and forgot to restart them. And of course noone reminded me > (ill look into restarting them after this conference reminded me) > No SW is going to safe you of this sort of issue > > Also SW must be easy maintainable, everything i hear of gitlab is saying > the opposit. > It must be possible that when something happens to our servers no matter > if videolan or micosoft or our own. That everything can be recovered > and quickly put back in action without too much server admins cooperation > (they could be sick or arrested or joined the wrong FOSS cult) > plain git allows easy recovery, trac has backups in the hands > of multiple people (these backups are the drop it in a directory and start > it more or less kind IIRC) > > again IMO any change to what SW we use needs more discussion than a > "who likes gitlab, who likes gitwhatever" vote > Briefly: don't expect any quick activity here that affects anyone. My goal here was to see if we (as a GA) can find some kind of consensus to look into alternatives to our current trac/patchwork/fate/git workflow. That doesn't mean everything is bad: git is great. I find the "integrated developer experience" very lacking, though. We use a different system in dav1d and it is by far superior. (Please voice your +1/-1 here.) There are many important details to be worked out and kinks to be resolved. Michael named some. I agree with most of what Michael says. Own control is critical, and we should not rely on outside parties. Anton had a whole bunch also, for example about commandline accessibility of the full feature set of a developer workflow, including efficient patch review that does not require a web browser. I agree with that also. I don't mean to take your workflow away from you. Ronald ___ 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] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Hi, On Sun, Sep 24, 2023 at 1:40 PM Marton Balint wrote: > On Sun, 24 Sep 2023, Kyle Swanson wrote: > > DNS > > --- > > > > - Currently the DNS of ffmpeg.org is managed by Fabrice > > - Michael was asked if he has control over the ffmpeg.org DNS > register. > > - Michael says he thinks he has some. > > - Ronald would be curious to know what "some" means. > > - Ronald proposes current project owners should have control over DNS > and > > trademark. > > - Ronald: Fabrice is not active, DNS and trademark should be in the > > control of project members. > > - Michael: "i think fabrice should stay in ultimate control", "he has > > always acted in the best interests of the people". > > - Ronald took a poll in the room, most agreed current project > developers > > should have control of this. > > I think you should define what you are aiming for exactly. Having more > people control the domain zone, or asking Fabrice to transfer domain > ownership to someone else or some legal entity. > > I doubt anybody has problem with the former, but for the latter, knowing > history, it will certainly raise eyebrows. IMHO having Fabrice ultimate > control over the domain ensures that everybody plays nice. > I disagree. Fabrice has theoretical veto power over anything this community does because he can change the IP ffmpeg.org points to. That is not right. He is not a participant anymore. I understand he conceived of the project and its name, but he is no longer part of the developer community in this project. Most participants (basically everyone) agreed with this. I don't mean to threaten and I don't mean to own rights to anything myself. If you don't like me asking to be part of the GA even though I don't meet the commit count threshold, you can express that by denying me membership in the "other people" vote that will be up at some point in the near future. I will respect this process regardless of outcome. I believe the GA should have sole control and ownership over the domain and trademark. I suggested to kindly ask Fabrice to transfer ownership and/or legal control permanently to a non-profit controlled by and composed of only our GA. I believe this can be amicably worked out. If you believe Fabrice should continue to have *some* (although not *sole*) say over FFmpeg and ffmpeg.org, then we could propose for him to be a GA member, too. I think that makes a lot of sense - he historically has a ton more work in FFmpeg than me. Ronald ___ 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] VDD conference invitation - Dublin 22-24 Sept 2023
Hi, On Fri, Sep 8, 2023 at 9:10 AM Michael Niedermayer wrote: > On Thu, Aug 17, 2023 at 07:42:17PM +0200, Jean-Baptiste Kempf wrote: > [...] > > Propose a talk, from 5min to 30min. > > As i will not be at the conference, here are some quick words > I really think you should reconsider this position. It would be extremely valuable if you could attend, even just for one day or part of a day. We are not scary or creepy and will not do bad things to you (or anyone). Please join us. You can skip dinner/drinks if that's not your thing. But please attend the technical discussion. Ronald ___ 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] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML
Hi, On Fri, Aug 25, 2023 at 1:42 PM Nicolas George wrote: > James Almer (12023-08-25): > > As i said on IRC, > > A medium that can only be accessed by a small fraction of the > contributors due to timeliness constraints. > I suspect you misunderstand IRC. With matrix, a bouncer or a 24/7 client, most of us are online with 24/7 history. Chat logs even provide google searchability. I prefer IRC over mailinglist for most technical discussions. Ronald ___ 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] libswresample: Prevent out of bounds.
Hi,
On Wed, Aug 2, 2023 at 7:31 AM kobrineli wrote:
> From: Eli Kobrin
>
> We've been fuzzing torchvision with [sydr-fuzz](
> https://github.com/ispras/oss-sydr-fuzz)
> and found out of bounds error in ffmpeg project at audioconvert.c:51.
> To prevent error we need to insert corresponding check and fix checks
> for in and out fmt in swr_init.
>
> Signed-off-by: Eli Kobrin
> ---
> libswresample/audioconvert.c | 7 ++-
> libswresample/swresample.c | 4 ++--
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/libswresample/audioconvert.c b/libswresample/audioconvert.c
> index 1d75ba1495..701f4808a0 100644
> --- a/libswresample/audioconvert.c
> +++ b/libswresample/audioconvert.c
> @@ -148,7 +148,12 @@ AudioConvert *swri_audio_convert_alloc(enum
> AVSampleFormat out_fmt,
> int flags)
> {
> AudioConvert *ctx;
> -conv_func_type *f =
> fmt_pair_to_conv_functions[av_get_packed_sample_fmt(out_fmt) +
> AV_SAMPLE_FMT_NB*av_get_packed_sample_fmt(in_fmt)];
> +
> +size_t idx = av_get_packed_sample_fmt(out_fmt) + AV_SAMPLE_FMT_NB *
> av_get_packed_sample_fmt(in_fmt);
> +if (idx >= AV_SAMPLE_FMT_NB * AV_SAMPLE_FMT_NB)
> +return NULL;
> +
> +conv_func_type *f = fmt_pair_to_conv_functions[idx];
>
This is not necessary anymore, please remove this portion.
> diff --git a/libswresample/swresample.c b/libswresample/swresample.c
> index 6dc329a9d0..b7cab36710 100644
> --- a/libswresample/swresample.c
> +++ b/libswresample/swresample.c
> @@ -196,11 +196,11 @@ av_cold int swr_init(struct SwrContext *s){
>
> clear_context(s);
>
> -if(s-> in_sample_fmt >= AV_SAMPLE_FMT_NB){
> +if(s-> in_sample_fmt >= AV_SAMPLE_FMT_NB || s-> in_sample_fmt < 0){
> av_log(s, AV_LOG_ERROR, "Requested input sample format %d is
> invalid\n", s->in_sample_fmt);
> return AVERROR(EINVAL);
> }
> -if(s->out_sample_fmt >= AV_SAMPLE_FMT_NB){
> +if(s->out_sample_fmt >= AV_SAMPLE_FMT_NB || s->out_sample_fmt < 0){
> av_log(s, AV_LOG_ERROR, "Requested output sample format %d is
> invalid\n", s->out_sample_fmt);
> return AVERROR(EINVAL);
> }
> --
> 2.25.1
>
You can simplify this to "if ((unsigned) s->in/out_sample_fmt >=
AV_SAMPLE_FMT_NB)".
Ronald
___
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] libsvtav1: Add workaround for gop_size == 1
Hi, On Thu, Jul 13, 2023 at 5:13 PM Vignesh Venkat < vigneshv-at-google@ffmpeg.org> wrote: > On Wed, Jun 28, 2023 at 4:27 PM James Almer wrote: > > > > On 6/28/2023 8:25 PM, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Wed, Jun 28, 2023 at 12:48 PM Vignesh Venkat < > > > vigneshv-at-google@ffmpeg.org> wrote: > > > > > >> i will update the upstream bug to clarify this part. but in the > > >> meantime, i think this patch is reasonable to replicate the behavior > > >> of other AV1 encoders with -g 1. > > >> > > > > > > Sounds reasonable, I think. James, objections? > > > > > > Ronald > > > > No, fine by me. > > ___ > > 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". > > Ronald or James, would you be able to merge this please? :) > Done. Ronald ___ 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 v5] avformat/ivfenc: Set the "number of frames" in IVF header
Hi, On Thu, Jul 6, 2023 at 9:10 PM Dai, Jianhui J < jianhui.j.dai-at-intel@ffmpeg.org> wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of Dai, > > Jianhui J > > Sent: Monday, July 3, 2023 12:26 PM > > To: ffmpeg-devel@ffmpeg.org > > Subject: [FFmpeg-devel] [PATCH v5] avformat/ivfenc: Set the "number of > > frames" in IVF header > > > > Should set "number of frames" to bytes 24-27 of IVF header, not duration. > > It is described by [1], and confirmed by parsing all IVF files in [2]. > > > > This commit also updates the md5sum of refs to pass fate-cbs. > > > > [1] Duck IVF - MultimediaWiki > > https://wiki.multimedia.cx/index.php/Duck_IVF > > > > [2] webm/vp8-test-vectors > > https://chromium.googlesource.com/webm/vp8-test-vectors > [..] > Another friendly ping reviewers to apply. > Some decoders will strictly check this field in IVF header, and it causes > failures for those decoders. > Merged. Ronald ___ 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 v2] avformat/ivfenc: Set the "number of frames" in IVF header
Hi, On Sun, Jul 2, 2023 at 8:59 AM Anton Khirnov wrote: > Quoting Ronald S. Bultje (2023-07-02 14:44:42) > > Hi, > > > > On Sun, Jul 2, 2023 at 5:35 AM Anton Khirnov wrote: > > > > > Quoting Ronald S. Bultje (2023-07-02 02:03:11) > > > > I see this discussion now... > > > > > > > > I don't think I agree with the above. First of all, IVF has two > fields > > > > there (it seems): duration, and n_frames. > > > > > > Got any source for that? I only see one field in > > > https://wiki.multimedia.cx/index.php/Duck_IVF > > > > > > > This somewhat-widely used tool called "ffmpeg" has used it like that for > > the past, say, 10 years. I've heard some projects or companies around the > > world use this tool, and backwards compatibility is supposedly a thing. > > Yeah yeah very funny. > > You claimed there are two fields. My question was where is this second > field supposed to be. > I'm not joking. It's literally introduced by ffmpeg. If you look at the originators of the ivf format, they write a 32bit field at header_offset+24 called nb_frames, and an "unused" entry at header_offset+28. FFmpeg adds nothing at header_offset+24 and duration at header_offset+28. We essentially added that field, in the same way that we extended the y4m format, or support unofficial B-frames in AVI etc. You may not like it, neither do I, but these files exist, and I don't think we should break them. Ronald ___ 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 v2] avformat/ivfenc: Set the "number of frames" in IVF header
Hi, On Sun, Jul 2, 2023 at 5:35 AM Anton Khirnov wrote: > Quoting Ronald S. Bultje (2023-07-02 02:03:11) > > I see this discussion now... > > > > I don't think I agree with the above. First of all, IVF has two fields > > there (it seems): duration, and n_frames. > > Got any source for that? I only see one field in > https://wiki.multimedia.cx/index.php/Duck_IVF > This somewhat-widely used tool called "ffmpeg" has used it like that for the past, say, 10 years. I've heard some projects or companies around the world use this tool, and backwards compatibility is supposedly a thing. Ronald ___ 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 v2] avformat/ivfenc: Set the "number of frames" in IVF header
Hi, On Thu, Jun 29, 2023 at 5:44 AM Anton Khirnov wrote: > Quoting Dai, Jianhui J (2023-06-29 08:03:18) > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Anton Khirnov > > > Sent: Wednesday, June 28, 2023 11:25 PM > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH v2] avformat/ivfenc: Set the > "number of > > > frames" in IVF header > > > > > > Quoting Dai, Jianhui J (2023-06-05 02:53:35) > > > > diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c index > > > > 511f2387ed..01012db948 100644 > > > > --- a/libavformat/ivfdec.c > > > > +++ b/libavformat/ivfdec.c > > > > @@ -53,6 +53,7 @@ static int read_header(AVFormatContext *s) > > > > st->codecpar->height = avio_rl16(s->pb); > > > > time_base.den = avio_rl32(s->pb); > > > > time_base.num = avio_rl32(s->pb); > > > > +// Infer duration from "number of frames". > > > > st->duration = avio_rl32(s->pb); > > > > > > This should be setting st->nb_frames then rather than duration. > > > And the muxer should be using that field as well instead of its custom > version. > > > > ACK. > > Do you suggest letting `duration` unset? > > It is interesting that the 'duration' is often right in this way, if > > the time_base.den/time_base.num == fps which is the popular > > configuration. > > Yes, but AFAIU there is no way to tell whether the file is CFR, so then > the value would be unreliable. So I'd prefer to leave it unset. > I see this discussion now... I don't think I agree with the above. First of all, IVF has two fields there (it seems): duration, and n_frames. We have the ability to set both in the muxer, and therefore should set both. Setting only once was silly, but changing it to set only the other is not better. Similarly, the demuxer should set both. I think it's particularly bad that we change a muxer that has been setting a particular field for years (and the accompanying demuxer code to the the AVStream member) to suddenly not set that field/member anymore. This is technically a regression. Ronald ___ 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 v3] avformat/ivfenc: Set the "number of frames" in IVF header
Hi, On Thu, Jun 29, 2023 at 8:54 AM Dai, Jianhui J < jianhui.j.dai-at-intel@ffmpeg.org> wrote: > Should set "number of frames" to bytes 24-27 of IVF header, not > duration. > It is described by [1], and confirmed by parsing all IVF files in [2]. > > This commit also updates the md5sum of refs to pass fate-cbs. > > [1] Duck IVF - MultimediaWiki > https://wiki.multimedia.cx/index.php/Duck_IVF > > [2] webm/vp8-test-vectors > https://chromium.googlesource.com/webm/vp8-test-vectors > > Signed-off-by: Jianhui Dai > --- > libavformat/ivfdec.c| 6 +++--- > libavformat/ivfenc.c| 13 + > tests/ref/fate/cbs-vp9-vp90-2-03-deltaq | 2 +- > tests/ref/fate/cbs-vp9-vp90-2-06-bilinear | 2 +- > tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas | 2 +- > .../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame | 2 +- > .../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame2 | 2 +- > tests/ref/fate/cbs-vp9-vp90-2-segmentation-aq-akiyo | 2 +- > tests/ref/fate/cbs-vp9-vp90-2-segmentation-sf-akiyo | 2 +- > tests/ref/fate/cbs-vp9-vp90-2-tiling-pedestrian | 2 +- > tests/ref/fate/cbs-vp9-vp91-2-04-yuv440 | 2 +- > tests/ref/fate/cbs-vp9-vp91-2-04-yuv444 | 2 +- > tests/ref/fate/cbs-vp9-vp92-2-20-10bit-yuv420 | 2 +- > tests/ref/fate/cbs-vp9-vp93-2-20-10bit-yuv422 | 2 +- > tests/ref/fate/cbs-vp9-vp93-2-20-12bit-yuv444 | 2 +- > 15 files changed, 21 insertions(+), 24 deletions(-) > > diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c > index 511f2387ed..c71a28e0d3 100644 > --- a/libavformat/ivfdec.c > +++ b/libavformat/ivfdec.c > @@ -51,9 +51,9 @@ static int read_header(AVFormatContext *s) > st->codecpar->codec_id = ff_codec_get_id(ff_codec_bmp_tags, > st->codecpar->codec_tag); > st->codecpar->width = avio_rl16(s->pb); > st->codecpar->height = avio_rl16(s->pb); > -time_base.den = avio_rl32(s->pb); > -time_base.num = avio_rl32(s->pb); > -st->duration = avio_rl32(s->pb); > +time_base.den= avio_rl32(s->pb); > +time_base.num= avio_rl32(s->pb); > +st->nb_frames= avio_rl32(s->pb); > avio_skip(s->pb, 4); // unused > > ffstream(st)->need_parsing = AVSTREAM_PARSE_HEADERS; > Is the removal of the st->duration assignment necessary? Applications using this field will now see a regression. Ronald ___ 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] libsvtav1: Add workaround for gop_size == 1
Hi, On Wed, Jun 28, 2023 at 12:48 PM Vignesh Venkat < vigneshv-at-google@ffmpeg.org> wrote: > i will update the upstream bug to clarify this part. but in the > meantime, i think this patch is reasonable to replicate the behavior > of other AV1 encoders with -g 1. > Sounds reasonable, I think. James, objections? Ronald ___ 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] libsvtav1: Add workaround for gop_size == 1
Hi Vignesh, On Tue, Jun 27, 2023 at 1:55 PM Vignesh Venkat < vigneshv-at-google@ffmpeg.org> wrote: > > >>> In some versions of libsvtav1, setting intra_period_length to 0 > [..] > > >>> SVT-AV1 Bug: https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 > > >>> > > >>> Example command: ffmpeg -f lavfi -i > testsrc=duration=1:size=64x64:rate=30 -c:v libsvtav1 -g 1 -y test.webm > > >>> > > >>> Before: Only first frame is keyframe. > > >>> After: All frames are keyframes. > [..] > From what i tested, it seems to be there on the tip of tree SVT-AV1 as > well. So we can't guard it with macros until the issue is fixed. > Isn't this the expected behaviour, btw? See https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Parameters.md "Keyint --keyint [-2-(2^31)-1] -2 GOP size (frames), use s suffix for seconds (SvtAv1EncApp only) [-2: ~5 seconds, -1: "infinite" only for CRF, 0: == -1] " note the final parts: 0=-1, and -1 means "infinite" keyint (i.e. never insert a new KF). Since FFmpeg's wrapper sets keyint to "gopsize value minus 1", "-g 1" seems to become equivalent to "--keyint 0" on the SVT-AV1 commandline, unless there's some discrepancy between API and CLI interface. (I admit that if I set it to 1, I don't actually get keyframes, but rather intraonly frames for all except the first frame. --keyint 2 correctly uses key - inter pairs. But your "before" statement above appeared to suggest that the first keyframe is followed by inter frames, not intraonly frames. If you meant "intraonly after key" instead of "inter after key", you should probably note that more explicitly. This may also help upstream reproduce in #2076 so they can fix it going forward.) Ronald ___ 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] libsvtav1: Add workaround for gop_size == 1
Hi, On Mon, Jun 26, 2023 at 1:47 PM Vignesh Venkatasubramanian < vigneshv-at-google@ffmpeg.org> wrote: > In some versions of libsvtav1, setting intra_period_length to 0 > does not produce the intended result (i.e.) all frames produced > are not keyframes. > > Instead handle the gop_size == 1 as a special case by setting > the pic_type to EB_AV1_KEY_PICTURE when encoding each frame so > that all the output frames are keyframes. > > SVT-AV1 Bug: https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 > > Example command: ffmpeg -f lavfi -i testsrc=duration=1:size=64x64:rate=30 > -c:v libsvtav1 -g 1 -y test.webm > > Before: Only first frame is keyframe. > After: All frames are keyframes. > > Signed-off-by: Vignesh Venkatasubramanian > --- > libavcodec/libsvtav1.c | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) > It feels a bit dirty to add workarounds in ffmpeg library wrappers for bugs in these libraries. Not 100% against it, but it's not particularly great. Ronald ___ 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".
