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] [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] [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(&s->coeff_partition[i], buf, buf_size); > > -return 0; > +return ff_vpx_init_range_decoder(&s->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: > +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 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 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 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 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 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] 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(&s->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] 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] 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 1/3] avcodec/x86/vvc/vvc_alf: fix integer overflow
Hi, On Wed, May 29, 2024 at 11:38 AM wrote: > +%else > +vpunpcklqdq m11, m2, m2 > +vpunpckhqdq m12, m2, m2 > +vpunpcklwd m11, m11, m14 > +vpunpcklwd m12, m12, m14 > +paddd m0, m11 > +paddd m1, m12 > +packssdw m0, m0, m1 > +%endif > punpcklqdq a, src, src punpckhqdq b, src, src punpcklwd a, a, zero punpcklwd b, b, zero is the same as punpcklwd a, src, zero punpckhwd b, src, zero Also, the whole thing just emulates a saturated add. Can't you use paddsw instead of paddw and be done with it? To add to Andreas' question: is saturating here normatively required? 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/3] avcodec/x86/vvc/vvc_alf: fix integer overflow
Hi, On Wed, May 29, 2024 at 3:44 PM Wu Jianhua wrote: > Ronald S. Bultje: > > On Wed, May 29, 2024 at 11:38 AM toq...@outlook.com>> wrote: > > +%else > > +vpunpcklqdq m11, m2, m2 > > +vpunpckhqdq m12, m2, m2 > > +vpunpcklwd m11, m11, m14 > > +vpunpcklwd m12, m12, m14 > > +paddd m0, m11 > > +paddd m1, m12 > > +packssdw m0, m0, m1 > > +%endif > > > [..] > > Also, the whole thing just emulates a saturated add. Can't you use paddsw > instead of paddw and be done with it? To add to Andreas' question: is > saturating here normatively required? > > We didn't have any sample that failed for this issue except for the > checksum with specific seeds. I think we can keep not changing it until a > real sample has something wrong. > > @Nuomi to get more details. > I think "just" replacing paddw with paddsw is correct, since the input pixels are 12bit (so they could be either unsigned or signed), the filtered output is the result of packssdw (so signed words), and the desired output is 12bit pixels anyway, anything greater than that is clipped to 12bit range. So to me, it seems paddsw is a cheaper way to accomplish the same 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 1/3] avcodec/x86/vvc/vvc_alf: fix integer overflow
Hi, On Thu, May 30, 2024 at 12:28 PM wrote: > From: Wu Jianhua > > Some tests fails with certain seeds > > tests/checkasm/checkasm 2325607578 --test=vvc_alf > checkasm: using random seed 2325607578 > AVX2: > vvc_alf_filter_luma_120x20_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x24_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x28_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x32_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x36_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x40_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x44_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x48_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x52_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x56_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x60_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x64_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x68_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x72_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x76_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x80_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x84_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x88_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x92_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x96_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x100_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x104_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x108_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x112_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x116_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x120_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x124_12_avx2 (vvc_alf.c:104) > vvc_alf_filter_luma_120x128_12_avx2 (vvc_alf.c:104) > - vvc_alf.alf_filter [FAILED] > - vvc_alf.alf_classify [OK] > checkasm: 28 of 9216 tests have failed > > Reported-by: James Almer > Signed-off-by: Wu Jianhua > --- > libavcodec/x86/vvc/vvc_alf.asm | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/x86/vvc/vvc_alf.asm > b/libavcodec/x86/vvc/vvc_alf.asm > index 71e821c27b..f7b3e2a6cc 100644 > --- a/libavcodec/x86/vvc/vvc_alf.asm > +++ b/libavcodec/x86/vvc/vvc_alf.asm > @@ -356,7 +356,8 @@ SECTION .text > > FILTER_VB xq > > -paddw m0, m2 > +; sum += curr > +paddsw m0, m2 > > ; clip to pixel > CLIPW m0, m14, m15 > -- > 2.44.0.windows.1 > 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 v2 1/3] avcodec/x86/vvc/vvc_alf: fix integer overflow
Hi Andreas, On Thu, May 30, 2024 at 2:33 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > toq...@outlook.com: > > From: Wu Jianhua > > > > Some tests fails with certain seeds > > > > tests/checkasm/checkasm 2325607578 --test=vvc_alf > > checkasm: using random seed 2325607578 > > AVX2: > > vvc_alf_filter_luma_120x20_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x24_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x28_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x32_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x36_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x40_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x44_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x48_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x52_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x56_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x60_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x64_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x68_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x72_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x76_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x80_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x84_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x88_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x92_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x96_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x100_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x104_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x108_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x112_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x116_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x120_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x124_12_avx2 (vvc_alf.c:104) > > vvc_alf_filter_luma_120x128_12_avx2 (vvc_alf.c:104) > > - vvc_alf.alf_filter [FAILED] > > - vvc_alf.alf_classify [OK] > > checkasm: 28 of 9216 tests have failed > > > > Reported-by: James Almer > > Signed-off-by: Wu Jianhua > > --- > > libavcodec/x86/vvc/vvc_alf.asm | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/libavcodec/x86/vvc/vvc_alf.asm > b/libavcodec/x86/vvc/vvc_alf.asm > > index 71e821c27b..f7b3e2a6cc 100644 > > --- a/libavcodec/x86/vvc/vvc_alf.asm > > +++ b/libavcodec/x86/vvc/vvc_alf.asm > > @@ -356,7 +356,8 @@ SECTION .text > > > > FILTER_VB xq > > > > -paddw m0, m2 > > +; sum += curr > > +paddsw m0, m2 > > > > ; clip to pixel > > CLIPW m0, m14, m15 > > And can I get an answer to the question of whether the issue is present > when used by the actual decoder and not only the checkasm test? > From my reading of the source code, this could happen in a crafted (e.g. fuzzed) stream. 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 4/5] lavu/intmath.h: Fix UB in ff_ctz_c() and ff_ctzll_c()
Hi, On Thu, May 30, 2024 at 10:03 AM Tomas Härdin wrote: > tor 2024-05-30 klockan 16:06 +0300 skrev Rémi Denis-Courmont: > > > > > > Le 30 mai 2024 12:50:05 GMT+03:00, "Tomas Härdin" a > > écrit : > > > tor 2024-05-30 klockan 10:54 +0300 skrev Rémi Denis-Courmont: > > > > Can't we just use the compiler built-ins here? AFAIK, they (GCC, > > > > LLVM) use the same algorithm if the CPU doesn't support native > > > > CTZ. > > > > And they will pick the right instruction if CPU does have CTZ. > > > > > > > > I get it that maybe it wasn't working so well 20 years ago, but > > > > we've > > > > increased compiler version requirements since then. > > > > > > I think we still support MSVC, but maybe we shouldn't? It's > > > possible to > > > cross-compile for Windows either way. > > > > I don't get how that prevents using the GCC and Clang builtins (on > > GCC and Clang). > > Does MSVC have builtins for these? Do all compilers we support? > I think what Remi is suggesting is that someone (maybe Remi himself, maybe you, maybe me, maybe someone else) should send a patch to use the built-ins when available. Where not, we would continue using the C versions. All of this is unrelated to this patch, which would continue to be useful for the C fallback. 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/vp9mvs: fix misaligned access when clearing VP9mv
Hi,
On Sun, Jun 2, 2024 at 9:12 AM James Almer wrote:
> On 6/2/2024 10:06 AM, James Almer wrote:
> > On 6/2/2024 9:14 AM, Kacper Michajłow wrote:
> >> Fixes runtime error: member access within misaligned address
> >> for type 'av_alias64', which requires 8 byte alignment.
> >>
> >> VP9mv is aligned to 4 bytes, so instead doing 8 bytes clear, let's do
> >> 2 times 4 bytes.
> >>
> >> Signed-off-by: Kacper Michajłow
> >> ---
> >> libavcodec/vp9mvs.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/vp9mvs.c b/libavcodec/vp9mvs.c
> >> index b706d1660f..790cf629a6 100644
> >> --- a/libavcodec/vp9mvs.c
> >> +++ b/libavcodec/vp9mvs.c
> >> @@ -294,7 +294,8 @@ void ff_vp9_fill_mv(VP9TileData *td, VP9mv *mv,
> >> int mode, int sb)
> >> VP9Block *b = td->b;
> >> if (mode == ZEROMV) {
> >> -AV_ZERO64(mv);
> >> +AV_ZERO32(&mv[0]);
> >> +AV_ZERO32(&mv[1]);
> >> } else {
> >> int hp;
> >
> > IMO just move mv in VP9Block to the top of the struct. That will make
> > sure it's aligned to at the very least 16 byte (Since it's av_malloc'd).
>
> Actually nevermind, VP9mv has two int16_t and given what's passed to
> ff_vp9_fill_mv() it's not enough.
>
Do compilers on relevant platforms convert this to a single 64bit
(unaligned) zero-move? Otherwise, we may want an unaligned AV_ZERO64() so
as to not slow down platforms supporting unaligned writes.
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/vp9mvs: fix misaligned access when clearing VP9mv
Hi,
On Sun, Jun 2, 2024 at 6:43 PM Kacper Michajlow wrote:
> On Sun, 2 Jun 2024 at 23:17, Ronald S. Bultje wrote:
> >
> > Hi,
> >
> > On Sun, Jun 2, 2024 at 9:12 AM James Almer wrote:
> >
> > > On 6/2/2024 10:06 AM, James Almer wrote:
> > > > On 6/2/2024 9:14 AM, Kacper Michajłow wrote:
> > > >> Fixes runtime error: member access within misaligned address
> > > >> for type 'av_alias64', which requires 8 byte alignment.
> > > >>
> > > >> VP9mv is aligned to 4 bytes, so instead doing 8 bytes clear, let's
> do
> > > >> 2 times 4 bytes.
> > > >>
> > > >> Signed-off-by: Kacper Michajłow
> > > >> ---
> > > >> libavcodec/vp9mvs.c | 3 ++-
> > > >> 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/libavcodec/vp9mvs.c b/libavcodec/vp9mvs.c
> > > >> index b706d1660f..790cf629a6 100644
> > > >> --- a/libavcodec/vp9mvs.c
> > > >> +++ b/libavcodec/vp9mvs.c
> > > >> @@ -294,7 +294,8 @@ void ff_vp9_fill_mv(VP9TileData *td, VP9mv *mv,
> > > >> int mode, int sb)
> > > >> VP9Block *b = td->b;
> > > >> if (mode == ZEROMV) {
> > > >> -AV_ZERO64(mv);
> > > >> +AV_ZERO32(&mv[0]);
> > > >> +AV_ZERO32(&mv[1]);
> > > >> } else {
> > > >> int hp;
> > > >
> > > > IMO just move mv in VP9Block to the top of the struct. That will make
> > > > sure it's aligned to at the very least 16 byte (Since it's
> av_malloc'd).
> > >
> > > Actually nevermind, VP9mv has two int16_t and given what's passed to
> > > ff_vp9_fill_mv() it's not enough.
> > >
> >
> > Do compilers on relevant platforms convert this to a single 64bit
> > (unaligned) zero-move? Otherwise, we may want an unaligned AV_ZERO64() so
> > as to not slow down platforms supporting unaligned writes.
>
> Yes, exactly, compilers do that. I've checked before sending this
> patch if it doesn't do something overly silly.
>
> You can play around here to see, I've extracted relevant part
> https://godbolt.org/z/K4d7Ejb1P
>
Thanks for checking, patch is fine with 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 2/2] swscale/aarch64: Add rgb24 to yuv implementation
Hi, On Mon, Jun 3, 2024 at 12:14 PM Zhao Zhili wrote: > > > > On Jun 3, 2024, at 22:17, Rémi Denis-Courmont wrote: > > > > Le maanantaina 3. kesäkuuta 2024, 16.11.15 EEST Zhao Zhili a écrit : > >>> See https://github.com/mstorsjo/FFmpeg/actions/runs/9346228714 for one > >>> example run of these actions with your patches. > >> Wow, it’s very helpful. This is the action result of the updated patch: > >> > >> https://github.com/quink-black/FFmpeg/actions/runs/9350348848 > >> > >> https://ffmpeg.org/pipermail/ffmpeg-devel/2024-June/328786.html > >> > >> The test still failed on x86, but success on all arm64 platform and > >> longarch. I have tried to call rgb24ToY_c and ff_rgb24ToY_avx > >> directly and compare the results, they don't match. I’m confused. > > > > As Martin write, some x86 code is imprecise, or even wrong. > > On x86: > > With the following command: > ./ffmpeg -bitexact -cpuflags 0 -f lavfi -i testsrc -frames 1 -pix_fmt > yuv420p -f framemd5 - > 0, 0, 0,1, 115200, > d6b3abfc5280311c2758d5e4028c07b5 > > Without “-cpuflags 0” > ./ffmpeg -bitexact -f lavfi -i testsrc -frames 1 -pix_fmt yuv420p -f > framemd5 - > 0, 0, 0,1, 115200, > 1d302ce90bd5b6eec681730cc0868be4 > > It's indeed non bitexact. > > On aarch64 with the neon implementation I can get the same result as > "-cpuflags 0": > ./ffmpeg -bitexact -f lavfi -i testsrc -frames 1 -pix_fmt yuv420p -f > framemd5 - > 0, 0, 0,1, 115200, > d6b3abfc5280311c2758d5e4028c07b5 > > Now I can disable the test for x86 and continue the work on aarch64. > Uhm, that's a bit hacky. I think things like -sws_flags +bitexact need to be after the -i argument and then it might work? 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] New CC member: Steven Liu
Hi all, Anton resigned from the CC [1], leaving an empty spot. The remaining members of the CC agreed it would be best to fill the spot with the next runner-up from the last CC Elections. The last CC election results [2] had Steven Liu as next runner-up, so we've asked him to fill Anton's spot for the remainder of our term, and he accepted. Thanks & welcome, Steven! Ronald [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-April/325638.html [2] https://vote.ffmpeg.org/cgi-bin/civs/results.pl?num_winners=6&id=E_332f7f39709b8211&algorithm=cschulze ___ 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] lavu/opt: Mention that AVOptions is not reentrant
Hi, On Wed, Jun 5, 2024 at 9:44 AM Andrew Sayers wrote: > On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote: > > On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers < > ffmpeg-de...@pileofstuff.org> > > wrote: > > > > > An external API developer might think they can use AVOptions to modify > > > values > > > during playback (e.g. putting a playback quality slider next to the > volume > > > slider). Make it clear that behaviour is not recommended. > > > > > > > There are options that can be changed at runtime, > > And it works just fine. > > How would an external developer know which options can be safely changed > (preferably including in future versions of FFmpeg) vs. ones where their > tests > got lucky and happened not to trigger a read during a non-atomic write? > If you see that happening, it would be good to submit a bug report. Right now it's very abstract. 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/vc1dsp: match C block layout in inv_trans_4x8_rvv
Hi, On Mon, Jun 10, 2024 at 3:20 PM Rémi Denis-Courmont wrote: > Although checkasm does not verify this, the decoder requires that the > transform updates the input block exactly like the C code does. > Would it be possible to update the checkasm test to verify 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] avfilter: add wpsnr video filter
Hi Thomas, On Fri, Oct 29, 2021 at 9:12 AM Tomas Härdin wrote: > tor 2021-10-28 klockan 21:09 +0200 skrev Paul B Mahol: > > +const uint16_t *src = (const uint16_t *)ssrc; > > This is not -fstrict-aliasing safe > I don't believe that is correct. It's true we're not allowed to cast between two clashing types to access the same pointer (memory location), but the C standard would appear to make an exception for byte types. Quoted from https://stackoverflow.com/a/99010/4726410 because I'm too lazy to dig through the standard: "The types that C 2011 6.5 7 allows an lvalue to access are: - a type compatible with the effective type of the object, - a qualified version of a type compatible with the effective type of the object, - a type that is the signed or unsigned type corresponding to the effective type of the object, - a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object, - an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or - a character type." uint8_t is a variant of the character (aka byte) type, and so the cast would not seem to violate strict aliasing 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] [PATCH] avfilter: add wpsnr video filter
Hi, On Sat, Oct 30, 2021 at 4:57 AM Tomas Härdin wrote: > Maybe we should upgrade to C11 then? This gives us access to more > useful language features. Type-generic expressions look very useful > https://stackoverflow.com/a/7005988 (same thread, further down) appears to suggest the exact same literal wording exists in C99. No upgrade is necessary. 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 0/2]
Hi, On Fri, Nov 26, 2021 at 4:52 PM John-Paul Stewart < jpstew...@personalprojects.net> wrote: > There were no single channel examples and no 8 bit > examples. > > I have created four clips with SGI's original 'moviemaker' utility (so > they are guaranteed to be correctly formatted) to reverse engineer those > two pieces of metadata since the format is largely undocumented. They > are under 1MB each and available at: > To prevent this from breaking in the future, it would be great if "as-small-as-possible" versions of these could be integrated into FATE (our automated test system). How small can you make these so they still test the bits-per-sample / channels features? 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 0/2]
Hi John-Paul, On Sat, Nov 27, 2021 at 8:22 PM John-Paul Stewart < jpstew...@personalprojects.net> wrote: > On 2021-11-27 8:51 a.m., Ronald S. Bultje wrote: > > Hi, > > > > On Fri, Nov 26, 2021 at 4:52 PM John-Paul Stewart < > > jpstew...@personalprojects.net> wrote: > > > >> There were no single channel examples and no 8 bit > >> examples. > >> > >> I have created four clips with SGI's original 'moviemaker' utility (so > >> they are guaranteed to be correctly formatted) to reverse engineer those > >> two pieces of metadata since the format is largely undocumented. They > >> are under 1MB each and available at: > >> > > > > To prevent this from breaking in the future, it would be great if > > "as-small-as-possible" versions of these could be integrated into FATE > (our > > automated test system). How small can you make these so they still test > the > > bits-per-sample / channels features? > > I think they're already as small as I can practically make them. The > biggest is only 600 KiloBytes. In fact, my whole set of four is smaller > (2.0 MB) than the smallest existing test file (2.3 MB for 12345.mv) in > FATE's mv directory. > > In fact, the stereo16bit.movie example is redundant since there are > already samples with that combination. So you'd really only need about > 1.4 MB of new test files. > Alright. Would it be possible for you to submit a patch adding these other 3 samples to FATE 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] [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 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] [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] [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 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)
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] [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] [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] [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] [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 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 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 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 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 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] [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] [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] [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] [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] [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] [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] [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] [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] [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] 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".
[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] [CLT2019] FFmpeg at Chemnitzer Linux-Tage
Hi, On Sat, Mar 30, 2019 at 11:04 AM Thilo Borgmann wrote: > Am 23.03.19 um 16:11 schrieb Thilo Borgmann: > > Hi, > > > >> FFmpeg has been accepted for CLT 2019 in Chemnitz, Germany! > >> This "Chemnitzer Linux Tage" will take place on 16th and 17th of March. > >> You can find more details on their homepage: > >> > >> https://chemnitzer.linux-tage.de/2019/en/ > > > > we returned from last weekends CLT. We again had a great time there with > a lot of interested users and even some involvement in the capturing and > streaming of the talks. > > > > We presented the usual demos showing filters and capturing. We could > acquire new hardware for the project during the fair, so we'll be ablte to > significantly update our presentation for the next conference to run on > that hardware. > > > > Hotel and transportation has been handled like in the years before, so > there will be some requests about that soon. > > For me I ask to reimburse me 62,29 - for gas bringing Carl Eugen and me > from Berlin to Chemnitz. > Lost 1/2 receipts, which makes it cheaper this year. Can't the foundation just reimburse you anyway for the expense-with-no-receipt? This feels kind of silly. (I don't know if this is a foundation rule or not.) 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 for supporting m264 on h.264 decoding and encoding.
Hi, On Fri, Mar 29, 2019 at 12:15 PM Yufei He wrote: > Hi > > This is the fixed version of this patch that follows the way other > companies do on supporting FFmpeg. I would like to propose that we delay further consideration of this patch until Thilo has organized the vote [1] on whether we want to allow closed-source software integration in FFmpeg. Ronald [1] http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241450.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]
Hi, On Sat, Apr 6, 2019 at 12:42 PM Balint Marton wrote: > Hi All > > Here is a call for the people in the voting committee [1] on the decision > of extending it. > > Using the same guidelines as in the second extension [2], the following > candidates were found: > > git log libav/master..master --no-merges --since=2018-03-30T00:00:00Z > --until 2019-03-30T00:00:00Z --pretty=fuller | grep '^Commit:' | sed > 's/<.*//' |sort | uniq -c | sort -nr > > 662 Commit: Michael Niedermayer > 528 Commit: Paul B Mahol > 227 Commit: James Almer > 194 Commit: Carl Eugen Hoyos > 183 Commit: Mark Thompson > 141 Commit: Marton Balint > 99 Commit: Jun Zhao > 84 Commit: Steven Liu > 73 Commit: Martin Vignali > 64 Commit: Gyan Doshi > 55 Commit: Aman Gupta > 42 Commit: Timo Rothenpieler > 35 Commit: Zhong Li > 31 Commit: Karthick Jeyapal > 31 Commit: Karthick J > 23 Commit: Rostislav Pehlivanov > 22 Commit: Peter Ross > 22 Commit: Clément Bœsch > 21 Commit: Lou Logan > 21 Commit: Jan Ekström > > Some of these developers are already in the voting committee, the new ones > would be: > > Aman Gupta > Gyan Doshi > Jan Ekström > Jun Zhao > Karthick Jeyapal > Mark Thompson > Martin Vignali > Peter Ross > Steven Liu > Timo Rothenpieler > Zhong Li > > Question: Do you support extending the voting committte with the people > above Yes. (Didn't we use to do anonymous voting? I personally have no issue with this approach, but I can imagine that someone who wanted to vote against a particular person might prefer to do so privately... This is obviously more important for the actual vote, not the extension of the voting roll...) 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] [DECISION] Project policy on closed source components
Hi, On Sun, Apr 28, 2019 at 8:14 PM Marton Balint wrote: > On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote: > > On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote: > >> >> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: > >> >>> 2) Should patches using closed source libraries which are not > considered > >> >>> "System Libraries" according to the GPL be rejected? > >> >> > >> >> You mean "major components"? > >> >> (at no point does the GPLv2 mention "System Libraries". > >> > > >> > I meant the sytem libraries as in GPL v3. > >> > >> Okay, now I am really confused, I thought the GPLv3 refers to the > system > >> libraries as the drivers interfaces, but that might not be a case, > because > >> that is also the major component? > >> > >> If that is the case, then my intention was obvisouly major component, > but > >> I wonder what the system library means then in GPL v3? > > > > As to that, I have no clue. I feel that the GPLv3 did not help on that > part, and makes it more confusing (and many other parts). > > > > My understanding of major components of the OS, in GPLv2sense, is > kernel+libc+compiler+init/shell+drivers+libraries-installed-with-the-previous. > > Ok, I just revoked the vote request on the 2nd question. Sorry for the > mess. > > It looks like people prefer if GPL is not referenced at all in the > question, so please propose a (preferably short, but still precise) > wording for the vote about this. Should decklink be removed? (Even if the headers are BSD, the end-user functionality depends on closed-source libraries.) Should future patches depending on any closed-source component be approved of by a vote from this committee before being merged? We could even do a vote on the nvidia stuffies, just so we've had that too. 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] libavcodec/vp9: fix ref-frame size judging method
Hi, On Mon, Apr 29, 2019 at 10:03 PM Yan Cen wrote: > From: Yan Cen > > There is no need all reference frame demension is valid in libvpx. I think you're touching on a bigger issue here: libvpx allows having invalid (or even missing) references, and we don't. Note that this means we lack per-block reference validity checks in the block reconstruction code, and your patch is not adding them, thus exposing us to potential security issues there. 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] [DECISION] Project policy on closed source components
Hi, On Sun, Apr 28, 2019 at 4:02 PM Marton Balint wrote: > Hi All, > > There has been discussion on the mailing list several times about the > inclusion of support for closed source components (codecs, formats, > filters, etc) in the main ffmpeg codebase. > > Also the removal of libNDI happened without general consensus, so a vote > is necessary to justify the removal. > > So here is a call to the voting committee [1] to decide on the following > two questions: > > 1) Should libNDI support be removed from the ffmpeg codebase? Yes. 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] libavcodec/vp9: fix ref-frame size judging method
Hi, On Sun, May 19, 2019 at 7:05 PM Yan Cen wrote: > From: yancen > > There is no need all reference frame demension is valid in libvpx. > > So this change contains three part: > 1. Change each judgement's loglevel from "ERROR" to "WARNING" > 2. Make sure at least one of frames that this frame references has valid > dimension. > 3. All judgements fail would report "ERROR". Please refer to past comments here: https://patchwork.ffmpeg.org/patch/12945/ If any of my comment was addressed, please indicate how. 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] libavcodec/vp9: fix ref-frame size judging method
Hi, On Wed, May 22, 2019 at 2:12 AM Yan, CenX wrote: > Hi, Ronald > > > > Sorry to reply late. > > > > For you question, “we lack per-block reference validity checks in the > block reconstruction code”, would you mean encode process need validity > checks? > No. The decoder needs validity checks. I understand you're modifying libavcodec/vp9.c because of how its intertwined with the vp9 hw deoders, but it is primarily a software decoder. 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] libavcodec/vp9: fix ref-frame size judging method
Hi guys, On Wed, May 22, 2019 at 11:14 PM 严小复 wrote: > code”, I'm little confused about the red word,would you mean encode process > need validity checks or there need to check the reference id of each frame? > > And this patch will act on decode process, all references have already been > appointed by the stream. No. As said before, the *decode* process needs such checks. But since you don't seem to understand, let me try to be more helpful. If you have an array of references, and we refer to that as s->s.refs[8], in which some reference is missing, e.g. s->s.refs[5] is NULL (but the rest is fine). Now let's also say that we have a header in s->s.h in which there is an array of reference indices s->s.h.refidx[7] assigned as per the "spec". Let's imagine that we encounter a frame in which s->s.refs[5] is used as an active reference in this frame, for example s->s.h.refidx[0] = 5. Right now, with the code in git/master, we abort decoding. Your patch will make it continue decoding. So now, imagine that we encounter, in this frame, an inter block in which we use this reference (so b->ref[0] = 0, which means s->s.h.refidx[b->ref[0]] = 5), and have prediction code that does something like vp9_mc_template.c line 39: ThreadFrame *tref1 = &s->s.refs[s->s.h.refidx[b->ref[0]]]; Then later on this code will call a function which may in some cases be called mc_luma_dir() as per vp9_mc_template.c line 413, which is implemented in vp9recon.c line 298 in the function called mc_luma_unscaled() (see #define on line 383 of same file). This function now calls a DSP function in line 331: mc[!!mx][!!my](dst, dst_stride, ref, ref_stride, bh, mx << 1, my << 1); which directly accesses the reference pixels (see e.g. vp9dsp_template.c line 2044). Note how especially *none of these functions* check anywhere whether s->s.refs[s->s.h.refidx[b->ref[0]]] (or tref1) is NULL. They don't do that, because ... the header check already did that, so the check was redundant. But! You are *removing* that header check, so in this brave new world which will exist after applying your patch, what will happen is that I can craft a special stream where s->s.refs[5] becomes NULL, then send a subsequent frame using refs[5] by having s->s.h.refidx[0] = 5, then have a frame in which the block uses inter coding and uses reference 0 so that this causes access into s->s.refs[s->s.h.refidx[b->ref[0, which is a NULL pointer, which is undefined behaviour by the C standard, which means a bad person could craft such a stream that would allow this bad person to break into your computer and steal all your data. In more straightforward cases, it might also crash Firefox and VLC, which use the FFmpeg VP9 decoder. Note also that having your data stolen or your application crashing is considered *bad*. We *don't want that*. Therefore, as I've tried to say a few times already, if you remove the header check, you need to add a per-block check instead, so that Firefox/VLC don't crash and so that bad persons cannot steal your data. Please add such a check and test using a fuzzer that the check prevents crashes as described above. Similar checks may be needed in other places also, since there's multiple places where the software decoder does MC and accesses references. Good luck finding these places by reading the code and fuzzing away. HTH, and please ask more questions (on IRC please, #ffmpeg-devel on Freenode) if this is still unclear. 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] libavcodec/vp9: fix ref-frame size judging method
Hi,
On Mon, Jul 8, 2019 at 6:23 PM Yan Cen wrote:
> From: yancen
>
> There is no need all reference frame demension is valid in libvpx.
>
Haven't we discussed this before? Anyway, it seems you're really eager to
get this in, so I'll drop my objection. (I still think this could cause
issues in HW decoders.)
-if (!s->s.refs[s->s.h.refidx[0]].f->buf[0] ||
> -!s->s.refs[s->s.h.refidx[1]].f->buf[0] ||
> -!s->s.refs[s->s.h.refidx[2]].f->buf[0]) {
> -av_log(avctx, AV_LOG_ERROR, "Not all references are
> available\n");
> -return AVERROR_INVALIDDATA;
> +if (0 == sizeof(s->s.refs[s->s.h.refidx[0]])) {
> +if (0 == sizeof(s->s.refs[s->s.h.refidx[1]].f->buf[0])) {
> +if (0 == s->s.refs[s->s.h.refidx[2]].f->buf[0]) {
> +av_log(avctx, AV_LOG_ERROR, "All references are
> unavailable\n");
> +return AVERROR_INVALIDDATA;
> +} else {
> +
> av_frame_copy(s->s.refs[s->s.h.refidx[1]].f,s->s.refs[s->s.h.refidx[2]].f);
> +
> av_frame_copy(s->s.refs[s->s.h.refidx[0]].f,s->s.refs[s->s.h.refidx[2]].f);
> +}
>
[..]
This is concealment code for missing references and is unrelated to the ref
frame size judgement patch. Could you please split this off in a separate
patch? Also, we don't use 0 == sizeof(..) or 0 == .. in ffmpeg, we just use
!.., please adjust that style.
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] libavcodec/vp9: fix ref-frame size judging method
Hi, On Tue, Jul 9, 2019 at 7:22 AM Ronald S. Bultje wrote: > Hi, > > On Mon, Jul 8, 2019 at 6:23 PM Yan Cen wrote: > >> From: yancen >> >> There is no need all reference frame demension is valid in libvpx. >> > > Haven't we discussed this before? Anyway, it seems you're really eager to > get this in, so I'll drop my objection. (I still think this could cause > issues in HW decoders.) > I want to take this discussion one step further though. So, obviously, the central goal of this patch is to allow streams that can be decoded with libvpx to be decoded with ffvp9, specifically these that have frame size vs. ref size discrepancies that go beyond the limits formally allowed. We used to say that all refs have to comply with the limits, and you're changing it so that only one ref has to comply with the limits. I understand that so far. Now, what does libvpx do with the "invalid" refs? And what do hardware decoders do? What does the spec formally require? Is this mandated? Or optional? I can imagine several things happening in libvpx: - it just allows using invalid references like this; - it conceals as if the ref were missing and uses another one; - something else?? What does libvpx do, and what are we formally mandated to do, if anything? Are these streams considered proper? If so, isn't this an hardware exploit? Else, why have ref size limits at all? 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]lavd: Remove libndi newtek
Hi, On Tue, Dec 4, 2018 at 4:56 PM Martin Vignali wrote: > Le mar. 4 déc. 2018 à 16:12, Jean-Baptiste Kempf a > écrit : > > > But then, you will get absolutely all the integration from ALL the > various > > non-open source multimedia libraries, because it is useful to someone. > > Including shims for Adobe, Dolby and others. > > I'm probably disagree with you on this subject ! :-) > https://patchwork.ffmpeg.org/patch/7329/ (see also my response to that [1]) Or just on IRC today (!) " JVET VVC just got ready to be built with MSYS/MinGW too ... so I guess it is not yet in a stage to be considered to be linked into ffmpeg. What would be your criteria to consider this encoder? How would we get to know that you start considering it? Looking for a thread in the mailing list?" I'm surprised this patch made it in, I've always assumed we were uncomfortable with closed-source software and that the hardware-support was a corner-case. Can I submit a wrapper for my closed-source VP9 encoder? Ronald [1] https://ffmpeg-devel.ffmpeg.narkive.com/Ok5y3HXO/patch-0-3-codec-wrapper-for-librv11-and-rmhd-muxer-demuxer#post35 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, v4] lavc/vp9: fix reference frame dimensions check for SINGLE_REFERENCE mode
Hi, On Tue, Mar 17, 2020 at 10:59 AM Linjie Fu wrote: > With the description in frame size with refs semantics (SPEC 7.2.5), > it is a requirement of bitstream conformance that for at least one > reference frame has the valid dimensions. > > Modify the check to make sure the decoder works well in SINGLE_REFERENCE > mode that not all reference frames have valid dimensions. > > Check and error out if invalid reference frame is used in inter_recon. > > One of the failure case is a 480x272 inter frame (SINGLE_REFERENCE mode) > with following reference pool: > > 0. 960x544LASTvalid > 1. 1920x1088 GOLDEN invalid, but not used in single reference mode > 2. 1920x1088 ALTREF invalid, but not used in single reference mode > 3~7 ... Unused > > Identical logic in libvpx: > < > https://github.com/webmproject/libvpx/blob/master/vp9/decoder/vp9_decodeframe.c#L736 > > > > Signed-off-by: Linjie Fu > --- > [v3]: replace assert with check/return, tested in both multi frame/slice > mode > [v4]: clear error_info to make decoding still work for other frames in > this stream > > libavcodec/vp9.c | 20 ++-- > libavcodec/vp9dec.h | 5 + > libavcodec/vp9recon.c | 10 ++ > 3 files changed, 33 insertions(+), 2 deletions(-) LGTM, thanks for the revisions. (We have been discussing this on IRC.) 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] vp9dec: factorise freeing per-tile allocated data
Hi, On Sat, Apr 18, 2020 at 6:15 AM Anton Khirnov wrote: > --- > libavcodec/vp9.c | 36 > 1 file changed, 16 insertions(+), 20 deletions(-) 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".
[FFmpeg-devel] [PATCH] ivfenc: write duration for frame_cnt=1.
---
libavformat/ivfenc.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 0951f56..e22625b 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -23,7 +23,7 @@
typedef struct IVFEncContext {
unsigned frame_cnt;
-uint64_t last_pts, sum_delta_pts;
+uint64_t last_pts, sum_delta_pts, first_duration;
} IVFEncContext;
static int ivf_init(AVFormatContext *s)
@@ -86,6 +86,8 @@ static int ivf_write_packet(AVFormatContext *s, AVPacket *pkt)
avio_write(pb, pkt->data, pkt->size);
if (ctx->frame_cnt)
ctx->sum_delta_pts += pkt->pts - ctx->last_pts;
+else
+ctx->first_duration = pkt->duration;
ctx->frame_cnt++;
ctx->last_pts = pkt->pts;
@@ -97,12 +99,15 @@ static int ivf_write_trailer(AVFormatContext *s)
AVIOContext *pb = s->pb;
IVFEncContext *ctx = s->priv_data;
-if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && ctx->frame_cnt > 1) {
+if ((pb->seekable & AVIO_SEEKABLE_NORMAL) &&
+(ctx->frame_cnt > 1 || (ctx->frame_cnt == 1 && ctx->first_duration))) {
int64_t end = avio_tell(pb);
avio_seek(pb, 24, SEEK_SET);
// overwrite the "length" field (duration)
-avio_wl32(pb, ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt -
1));
+avio_wl32(pb, ctx->frame_cnt > 1 ?
+ ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt - 1) :
+ ctx->first_duration);
avio_wl32(pb, 0); // zero out unused bytes
avio_seek(pb, end, SEEK_SET);
}
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ivfenc: write duration for frame_cnt=1.
Hi,
On Tue, Mar 2, 2021 at 11:20 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Ronald S. Bultje:
> > ---
> > libavformat/ivfenc.c | 11 ---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> > index 0951f56..e22625b 100644
> > --- a/libavformat/ivfenc.c
> > +++ b/libavformat/ivfenc.c
> > @@ -23,7 +23,7 @@
> >
> > typedef struct IVFEncContext {
> > unsigned frame_cnt;
> > -uint64_t last_pts, sum_delta_pts;
> > +uint64_t last_pts, sum_delta_pts, first_duration;
> > } IVFEncContext;
> >
> > static int ivf_init(AVFormatContext *s)
> > @@ -86,6 +86,8 @@ static int ivf_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> > avio_write(pb, pkt->data, pkt->size);
> > if (ctx->frame_cnt)
> > ctx->sum_delta_pts += pkt->pts - ctx->last_pts;
> > +else
> > +ctx->first_duration = pkt->duration;
> > ctx->frame_cnt++;
> > ctx->last_pts = pkt->pts;
> >
> > @@ -97,12 +99,15 @@ static int ivf_write_trailer(AVFormatContext *s)
> > AVIOContext *pb = s->pb;
> > IVFEncContext *ctx = s->priv_data;
> >
> > -if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && ctx->frame_cnt > 1) {
> > +if ((pb->seekable & AVIO_SEEKABLE_NORMAL) &&
> > +(ctx->frame_cnt > 1 || (ctx->frame_cnt == 1 &&
> ctx->first_duration))) {
> > int64_t end = avio_tell(pb);
> >
> > avio_seek(pb, 24, SEEK_SET);
> > // overwrite the "length" field (duration)
> > -avio_wl32(pb, ctx->frame_cnt * ctx->sum_delta_pts /
> (ctx->frame_cnt - 1));
> > +avio_wl32(pb, ctx->frame_cnt > 1 ?
> > + ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt
> - 1) :
> > + ctx->first_duration);
> > avio_wl32(pb, 0); // zero out unused bytes
> > avio_seek(pb, end, SEEK_SET);
> > }
> >
> Shouldn't we not always use the duration of the last packet for the
> duration and not only when it is the only packet?
That assumes the duration is always set, which according to the
documentation is not guaranteed.
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] [PATCH] ivfenc: write duration for frame_cnt=1.
---
libavformat/ivfenc.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 0951f56..889c004 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -23,7 +23,7 @@
typedef struct IVFEncContext {
unsigned frame_cnt;
-uint64_t last_pts, sum_delta_pts;
+uint64_t last_pts, sum_delta_pts, last_pkt_duration;
} IVFEncContext;
static int ivf_init(AVFormatContext *s)
@@ -86,6 +86,7 @@ static int ivf_write_packet(AVFormatContext *s, AVPacket *pkt)
avio_write(pb, pkt->data, pkt->size);
if (ctx->frame_cnt)
ctx->sum_delta_pts += pkt->pts - ctx->last_pts;
+ctx->last_pkt_duration = pkt->duration;
ctx->frame_cnt++;
ctx->last_pts = pkt->pts;
@@ -97,12 +98,15 @@ static int ivf_write_trailer(AVFormatContext *s)
AVIOContext *pb = s->pb;
IVFEncContext *ctx = s->priv_data;
-if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && ctx->frame_cnt > 1) {
+if ((pb->seekable & AVIO_SEEKABLE_NORMAL) &&
+(ctx->frame_cnt > 1 || (ctx->frame_cnt == 1 &&
ctx->last_pkt_duration))) {
int64_t end = avio_tell(pb);
avio_seek(pb, 24, SEEK_SET);
// overwrite the "length" field (duration)
-avio_wl32(pb, ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt -
1));
+avio_wl32(pb, ctx->last_pkt_duration ?
+ ctx->sum_delta_pts + ctx->last_pkt_duration :
+ ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt - 1));
avio_wl32(pb, 0); // zero out unused bytes
avio_seek(pb, end, SEEK_SET);
}
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ivfenc: write duration for frame_cnt=1.
Hi,
On Tue, Mar 2, 2021 at 1:59 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Ronald S. Bultje:
> > ---
> > libavformat/ivfenc.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
> > index 0951f56..889c004 100644
> > --- a/libavformat/ivfenc.c
> > +++ b/libavformat/ivfenc.c
> > @@ -23,7 +23,7 @@
> >
> > typedef struct IVFEncContext {
> > unsigned frame_cnt;
> > -uint64_t last_pts, sum_delta_pts;
> > +uint64_t last_pts, sum_delta_pts, last_pkt_duration;
> > } IVFEncContext;
> >
> > static int ivf_init(AVFormatContext *s)
> > @@ -86,6 +86,7 @@ static int ivf_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> > avio_write(pb, pkt->data, pkt->size);
> > if (ctx->frame_cnt)
> > ctx->sum_delta_pts += pkt->pts - ctx->last_pts;
> > +ctx->last_pkt_duration = pkt->duration;
> > ctx->frame_cnt++;
> > ctx->last_pts = pkt->pts;
> >
> > @@ -97,12 +98,15 @@ static int ivf_write_trailer(AVFormatContext *s)
> > AVIOContext *pb = s->pb;
> > IVFEncContext *ctx = s->priv_data;
> >
> > -if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && ctx->frame_cnt > 1) {
> > +if ((pb->seekable & AVIO_SEEKABLE_NORMAL) &&
> > +(ctx->frame_cnt > 1 || (ctx->frame_cnt == 1 &&
> ctx->last_pkt_duration))) {
> > int64_t end = avio_tell(pb);
> >
> > avio_seek(pb, 24, SEEK_SET);
> > // overwrite the "length" field (duration)
> > -avio_wl32(pb, ctx->frame_cnt * ctx->sum_delta_pts /
> (ctx->frame_cnt - 1));
> > +avio_wl32(pb, ctx->last_pkt_duration ?
> > + ctx->sum_delta_pts + ctx->last_pkt_duration :
> > + ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt
> - 1));
> > avio_wl32(pb, 0); // zero out unused bytes
> > avio_seek(pb, end, SEEK_SET);
> > }
> >
> Yes, that's what I had in mind. LGTM.
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, v4] lavc/vp9: fix reference frame dimensions check for SINGLE_REFERENCE mode
Hi, On Wed, Apr 29, 2020 at 8:08 AM Fu, Linjie wrote: > > From: ffmpeg-devel On Behalf Of Fu, > > Linjie > > Sent: Friday, March 20, 2020 09:49 > > To: Ronald S. Bultje ; FFmpeg development > > discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH, v4] lavc/vp9: fix reference frame > > dimensions check for SINGLE_REFERENCE mode > > > > > From: Ronald S. Bultje > > > Sent: Thursday, March 19, 2020 20:10 > > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > > Cc: Fu, Linjie > > > Subject: Re: [FFmpeg-devel] [PATCH, v4] lavc/vp9: fix reference frame > > dimensions check for SINGLE_REFERENCE mode > > > > > > Hi, > > > > > > On Tue, Mar 17, 2020 at 10:59 AM Linjie Fu > > mailto:linjie...@intel.com>> wrote: > > > With the description in frame size with refs semantics (SPEC 7.2.5), > > > it is a requirement of bitstream conformance that for at least one > > > reference frame has the valid dimensions. > > > > > > Modify the check to make sure the decoder works well in > > SINGLE_REFERENCE > > > mode that not all reference frames have valid dimensions. > > > > > > Check and error out if invalid reference frame is used in inter_recon. > > > > > > One of the failure case is a 480x272 inter frame (SINGLE_REFERENCE > mode) > > > with following reference pool: > > > > > > 0. 960x544LASTvalid > > > 1. 1920x1088 GOLDEN invalid, but not used in single reference mode > > > 2. 1920x1088 ALTREF invalid, but not used in single reference mode > > > 3~7 ... Unused > > > > > > Identical logic in libvpx: > > > > > <https://github.com/webmproject/libvpx/blob/master/vp9/decoder/vp9_d > > ecodeframe.c#L736> > > > > > > Signed-off-by: Linjie Fu linjie...@intel.com>> > > > --- > > > [v3]: replace assert with check/return, tested in both multi > frame/slice > > mode > > > [v4]: clear error_info to make decoding still work for other frames in > this > > stream > > > > > > libavcodec/vp9.c | 20 ++-- > > > libavcodec/vp9dec.h | 5 + > > > libavcodec/vp9recon.c | 10 ++ > > > 3 files changed, 33 insertions(+), 2 deletions(-) > > > > > > LGTM, thanks for the revisions. (We have been discussing this on IRC.) > > > > Thanks for the review and valuable suggestions. > > > Ping for merge, thx. Applied. 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] MPEG-2 FLAGS2_FAST benchmarks
Hi,
On Sat, Jun 13, 2020 at 12:11 PM Kieran Kunhya wrote:
> Hello,
>
> I have run the following commands on the following CPU which is 7 years
> old:
> Intel(R) Xeon(R) CPU E3-1265L v3
>
> ffmpeg_g -i matrixbench_mpeg2.mpg -f null -
> and
> ffmpeg_g -flags2 fast -i matrixbench_mpeg2.mpg -f null -
>
> Here are the results:
>
> Normal Fast
> 2202 2168
> 2155 2057
> 2210 2128
> 2104 2051
> 2132 2053
> 2035 2014
> 2021 2037
> 2247 1999
> 2095 2015
> 2232 2119
> Mean 2143.3 2064.1
> Stdev 79.82209385 55.9075626
>
> It can therefore be shown that the difference is statistically
> insignificant.
I'm all for removing -flags2 fast, but I do think we should do science
correctly.
The one-tailed (we are not considering whether "fast" is slower than
"normal") homoscedastic ("equal variance sampled, not paired") student t
test has a p value of 0.009638597, which for a typical p value threshold of
0.05 would reject the null hypothesis ("they are the same speed") and
accept that "Fast" is faster than "Normal". Why do you think the difference
is statistically insignificant?
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] Is it ok to add G.722.1 decoder as external lib?
Hi, On Sat, Sep 21, 2019 at 10:07 AM Nicolas George wrote: > Carl Eugen Hoyos (12019-09-21): > > I now wonder if this isn't much nicer than "You may use this FDK AAC > > Codec software or modifications thereto only for purposes that are > > authorized by appropriate patent licenses." > > (In the sense that it doesn't try to conceal the true terms) > > It is not "nicer", it is incompetent. If you read the whole COPYING file > from libg722_1: > > > https://github.com/traviscross/freeswitch/blob/master/libs/libg722_1/COPYING > > you realize is is not actually a license: is does not contain anything > that gives the authorization to use their code. > > Compare to the license of fdk-aac, which is proper legalese, gives > explicitly the right to use the code, and has been vetted by Debian. OK, hold on guys, wait. I had to read this 3x and it took me a while to get to this point (in my head). Others may be similarly confused. So it appears, from the discussion (..), that although there is source code, it is not actually "open" in the sense that it's not redistributable (at least not explicitly so) or modifiable? If I were hosting a copy on, say, github (or Debian), I'd be in legal trouble with this Freeswitch company? That's a serious issue, and I'd tend to agree with Nicolas we then probably don't want to link to such code... Or do I misunderstand? 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] Is it ok to add G.722.1 decoder as external lib?
Hi, On Sat, Sep 21, 2019 at 11:05 AM Carl Eugen Hoyos wrote: > Am Sa., 21. Sept. 2019 um 16:51 Uhr schrieb Ronald S. Bultje > : > > > So it appears, from the discussion (..), that although there is source > > code, it is not actually "open" in the sense that it's not > redistributable > > (at least not explicitly so) or modifiable? If I were hosting a copy on, > > say, github (or Debian), I'd be in legal trouble with this Freeswitch > > company? > > (Afaik) Freeswitch is a distributor of binaries based on FFmpeg's and > Polycom's source code. Freeswitch also hosts Polycom's source code. > > It appears to me that Freeswitch claims that while libg7221 is not a > Free library (and has a license incompatible with the GPL), it is > "open source" and can be distributed. Hm... Right, OK, so the question is indeed going to hinge on whether that is true or not. I suggest we open a github issue/request with exactly that question. :-). 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] Is it ok to add G.722.1 decoder as external lib?
Hi, On Sat, Sep 21, 2019 at 11:53 AM Ronald S. Bultje wrote: > Hi, > > On Sat, Sep 21, 2019 at 11:05 AM Carl Eugen Hoyos > wrote: > >> Am Sa., 21. Sept. 2019 um 16:51 Uhr schrieb Ronald S. Bultje >> : >> >> > So it appears, from the discussion (..), that although there is source >> > code, it is not actually "open" in the sense that it's not >> redistributable >> > (at least not explicitly so) or modifiable? If I were hosting a copy on, >> > say, github (or Debian), I'd be in legal trouble with this Freeswitch >> > company? >> >> (Afaik) Freeswitch is a distributor of binaries based on FFmpeg's and >> Polycom's source code. Freeswitch also hosts Polycom's source code. >> >> It appears to me that Freeswitch claims that while libg7221 is not a >> Free library (and has a license incompatible with the GPL), it is >> "open source" and can be distributed. > > > Hm... Right, OK, so the question is indeed going to hinge on whether that > is true or not. I suggest we open a github issue/request with exactly that > question. :-). > I take that back, there's a COPYING that addresses this: https://github.com/traviscross/freeswitch/blob/master/docs/COPYING Seems relatively sane 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 5/5 v2] avformat: add an AV1 Annex B demuxer
Hi,
On Mon, Nov 11, 2019 at 9:17 PM James Almer wrote:
> +static int leb(AVIOContext *pb, uint32_t *len) {
>
this can overflow, should be uint64_t.
> +unsigned bits;
>
Same.
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 5/5 v2] avformat: add an AV1 Annex B demuxer
Hi,
On Tue, Nov 12, 2019 at 8:09 AM James Almer wrote:
> On 11/12/2019 2:52 AM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Mon, Nov 11, 2019 at 9:17 PM James Almer wrote:
> >
> >> +static int leb(AVIOContext *pb, uint32_t *len) {
> >>
> >
> > this can overflow, should be uint64_t.
> >
> >
> >> +unsigned bits;
> >>
> >
> > Same.
> >
> > Ronald
>
> I used the same method as in dav1d, it will not overflow as it will not
> try to load more than five bytes worth leb128 data, ensuring to only
> accept up to 4 bits from the last, resulting in assembled values up to
> UINT32_MAX.
Oh, you are right, I was looking at "if (++i == 8 && more)", but the line
above it ("if (i <= 3 || (i == 4 && bits < (1 << 4)))") demonstrates
quickly that this is different. It's OK here, although a bit confusing, but
I should probably fix that in dav1d first.
Rest of patchset lgtm, and thanks for adding this feature, this is
genuinely very useful for AV1 users in more complex AV1 processing
pipelines. Section5 would be nice 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] [PATCH] avcodec/vp8: fix multiple ff_thread_finish_setup() calls
Hi, On Wed, Nov 13, 2019 at 2:00 AM wrote: > From: Zhao Zhili > > vp7 decoder doesn't set update_thread_context field > --- > libavcodec/vp8.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c > index eb51d1f3c9..b4deb3ed67 100644 > --- a/libavcodec/vp8.c > +++ b/libavcodec/vp8.c > @@ -2715,7 +2715,8 @@ int vp78_decode_frame(AVCodecContext *avctx, void > *data, int *got_frame, > > s->next_framep[VP56_FRAME_CURRENT] = curframe; > > -ff_thread_finish_setup(avctx); > +if (avctx->codec->update_thread_context) > +ff_thread_finish_setup(avctx); > OK, I guess. What's the actual problem solved by this patch (e.g. some commandline invocation with particular settings)? Does it cause some assertion with frame-multithreaded VP7 decoding? Maybe add that to the commit message so we know how to test this change. 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] [libdav1d.c]: Add option to output all the spatial layers.
Hi, On Thu, Nov 14, 2019 at 2:12 PM Andrey Semashev wrote: > I think there needs to be some consistency across different lavc > decoders. If we consider that lavc should produce one decoded frame per > one encoded one, even if the encoded one contains multiple layers, then > that should be true for all decoders. > Yes. I think one thing that would help is if we had access to more samples with an expected behaviour. Right now we may have samples, but if all we do is check md5 without caring what it means, then it's kind of pointless. > Also, I think having decoded frames from all layers would also be > useful, but there should be a way to know which layer they belong to. > AFAIK, lavc currently doesn't provide that information. This mode of > operation (producing frames for all layers) should be optional. I agree. 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/cbs_av1: fix reading reference order hint in skip_mode_params()
Hi,
On Fri, Nov 15, 2019 at 1:44 PM James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_av1_syntax_template.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/cbs_av1_syntax_template.c
> b/libavcodec/cbs_av1_syntax_template.c
> index 806b302de6..c843cfa02b 100644
> --- a/libavcodec/cbs_av1_syntax_template.c
> +++ b/libavcodec/cbs_av1_syntax_template.c
> @@ -882,7 +882,7 @@ static int
> FUNC(skip_mode_params)(CodedBitstreamContext *ctx, RWContext *rw,
> forward_idx = -1;
> backward_idx = -1;
> for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
> -ref_hint = priv->ref[i].order_hint;
> +ref_hint = priv->ref[current->ref_frame_idx[i]].order_hint;
> dist = cbs_av1_get_relative_dist(seq, ref_hint,
> current->order_hint);
> if (dist < 0) {
> @@ -913,7 +913,7 @@ static int
> FUNC(skip_mode_params)(CodedBitstreamContext *ctx, RWContext *rw,
>
> second_forward_idx = -1;
> for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
> -ref_hint = priv->ref[i].order_hint;
> +ref_hint =
> priv->ref[current->ref_frame_idx[i]].order_hint;
> if (cbs_av1_get_relative_dist(seq, ref_hint,
>forward_hint) < 0) {
> if (second_forward_idx < 0 ||
LGTM, 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] [aarch64] improve performance of ff_hscale_8_to_15_neon
Hi,
On Wed, Nov 27, 2019 at 3:28 PM Sebastian Pop wrote:
> On Wed, Nov 27, 2019 at 2:13 PM Clément Bœsch wrote:
> > Yeah I will by the end of the week. I wrote that a few years ago so I
> need
> > to take some time to get back in the context.
>
> Thanks Clément for your help.
>
> >
> > BTW, that's quite a huge speed improvement you're bringing in, are you
> > sure you are always allowed to read up to filter[3]?
>
> I will check.
> Otherwise we can version the code and keep the existing code along for
> vector factor 2.
utils.c allocates h{Chr,Lum}Filter and they appear to be padded.
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] [aarch64] improve performance of ff_hscale_8_to_15_neon
Hi,
On Thu, Nov 28, 2019 at 2:08 AM Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Nov 27, 2019 at 3:28 PM Sebastian Pop wrote:
>
>> On Wed, Nov 27, 2019 at 2:13 PM Clément Bœsch wrote:
>> > Yeah I will by the end of the week. I wrote that a few years ago so I
>> need
>> > to take some time to get back in the context.
>>
>> Thanks Clément for your help.
>>
>> >
>> > BTW, that's quite a huge speed improvement you're bringing in, are you
>> > sure you are always allowed to read up to filter[3]?
>>
>> I will check.
>> Otherwise we can version the code and keep the existing code along for
>> vector factor 2.
>
>
> utils.c allocates h{Chr,Lum}Filter and they appear to be padded.
>
Figure I should be more specific heresince there's multiple allocation
paths. I mean this one:
// NOTE: the +3 is for the MMX(+1) / SSE(+3) scaler which reads over
the end
FF_ALLOC_ARRAY_OR_GOTO(NULL, *filterPos, (dstW + 3),
sizeof(**filterPos), fail);
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] FFmpeg developer meeting 2019/12/9 notes
Dear all, below are the notes I took of the 2019/12/9 FFmpeg developer meeting. The meeting was held on a Google Meet, and there was an IRC proxy channel (#ffmpeg-meeting) also. Kind regards, Ronald - jb opens, agenda for this meeting o what happened at last meeting (at VDD) o various next steps, technical committee, community committee o any votes that we might want to have for next time o time/date for next meeting - jb, summary of vdd: o who can vote o temp committees to bootstrap function o final committees will be during fosdem o long email about decision was mailed to ffmpeg-list o most feedback was positive, except from durandal - jb asks cehoyos for feedback on whether 20 commits is still ok to be considered participatory in voting o cehoyos says (on IRC) that he thinks 3 years is long, but other people (michael, ronald, jdarnley) appear fine with 3 years. o cehoyos also says non-coding contributors should be recognized (packages, server admins, mailing list admins), e.g. moritz or alexander strasser, and multiple people appear to agree, no disagreement is raised o j-b proposes to add them to the voting list for now, under the rule of "limited number of other non-coding contributors" o jamrial also thinks nevcariel should be added, thilo agrees o we decide to exclude kurosu and kierank for now, since they are not very active ATM o the same (for now) will go for libav contributions (anton, martin, janne) o should packagers get a vote? cehoyos thinks they should in some cases, e.g. gentoo, osx, windows, debian o several people raise various objections. ronald thinks they are not part of a core group. lynne proposes we only include people that contribute back. cehoyos says he specifically intends to bring in the pkg maintainers of debian, osx, windows (zeranoe) and gentoo since they do valuable work in "spreading our work" and contribute back. however, cehoyos suggests they should get one vote per package. j-b proposes we vote on each packager individually. the general consensus appears to be we want this, but limited o should people on technical committee also get voting right regardless of whether they meet the 20 vote threshold or not? o we understand that this is excluding people like kurosu and kierank, but as soon as they are active again, they will get in :) - jb brings up whether rodger's proposed voting mechanism is generally agreed upon (or even if anyone cares) o michael says on IRC: i suggested "Schulze STV" (to rodger) o nobody else seems to care much, primarily what matters is who gets to vote, not how we vote (jamrial) o [11:38am] BBB: I wonder if the reason nobody comments is that nobody is aware that this does have "consequences"... [11:38am] (I suspect it has consequences but still don't know what is "good" and what "not") o iilya (on IRC) says "all the condorcet methods should produce almost the same results anyway" - jb: next topic, technical conflict resolution committee o TC right now is: michael, james almer, ronald, martin, anton o jb will write down process as a markdown document o ronald says "we'll see how it works the first time, right?" o on IRC, anton, james almer, thilo agree to just see how it works out - jb: next topic, community committee o jb: "code of conduct?" o "what does videolan do?" o videolan has very specific rules about what you can not do in terms of behaviour on IRC etc., and how long you get kicked (escalation process) if you violate the rules o cehoyos on irc: using the one from videolan as basis could be done but is difficult to agree with or not since it is very non-specific o cehoyos and ronald: the CC should probably be tasked with updating the CoC to be more specific than the one we currently have. o michael on irc: the problem with the coC was primarily that we didn't enforce it. steven liu agrees o kierank and jamrial on irc think the current coc is not fit (kierank: "not fit for purpose", jamrial: "has no defined rules") o lydia proposes one round of feedback so people can say what works for them and what does not o most people agree with CC proposing changes to CoC, then all people voting on the result from that. jb/lydia will help with that. - cehoyos asks about reimbursement limits for conferences from the ffmpeg funds. o there appears no disagreement that the amounts he's quoting (EUR 320 for hotel, EUR hotel for flight) is fine o jb thinks this should not be done on list to protect people's private information re: reimbursements because it includes details like where you went or where from o michael and cehoyos think the general requesting of reimbursements should be public so people can comment/object, but there is agreement some more personal information should be allowed to be kept private o jb: videolan has travel policy with how much is ok for going where etc. - Lynne asks about non-conference expenses, since we have funds but no clear process to "
Re: [FFmpeg-devel] [PATCH] avcodec/cbs_av1: fix array size for ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128
Hi,
On Wed, Dec 11, 2019 at 5:00 PM James Almer wrote:
> Taking into account the code
>
> fb(2, ar_coeff_lag);
> num_pos_luma = 2 * current->ar_coeff_lag * (current->ar_coeff_lag + 1);
> if (current->num_y_points)
> num_pos_chroma = num_pos_luma + 1;
> else
> num_pos_chroma = num_pos_luma;
>
> Max value for ar_coeff_lag is 3 (two bits), for num_pos_luma 24, and for
> num_pos_chroma 25.
>
> Both ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128 may have up to
> num_pos_chroma values.
>
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_av1.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
> index 50a05d2168..643e76793f 100644
> --- a/libavcodec/cbs_av1.h
> +++ b/libavcodec/cbs_av1.h
> @@ -268,8 +268,8 @@ typedef struct AV1RawFrameHeader {
> uint8_t grain_scaling_minus_8;
> uint8_t ar_coeff_lag;
> uint8_t ar_coeffs_y_plus_128[24];
> -uint8_t ar_coeffs_cb_plus_128[24];
> -uint8_t ar_coeffs_cr_plus_128[24];
> +uint8_t ar_coeffs_cb_plus_128[25];
> +uint8_t ar_coeffs_cr_plus_128[25];
> uint8_t ar_coeff_shift_minus_6;
> uint8_t grain_scale_shift;
> uint8_t cb_mult;
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 V7 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code
Hi, On Sat, Jan 18, 2020 at 9:49 PM Fu, Ting wrote: > Since NASM function will get only the address of SwsConext c ( in order to > be compatible with yuv2rgb_c function in parameters), not the address of > c->redDither nor the c->dstW. I have no way to get the value of c->dstW by > using address offset. Nasm and related variants have "struc" (like "struct" in C) for this. See for example this code: https://code.videolan.org/videolan/dav1d/blob/master/src/x86/film_grain.asm#L64 Hope this helps, 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/3] avutil/frame: add use_last_roi
Hi, On Thu, Feb 13, 2020 at 10:41 PM Guo, Yejun wrote: > For some cases, the regions of interest do not change, it is not > convenient to always prepare the roi data for every frame. Since side-data is refcounted, can't you just keep the "last" one in memory and refcount it? That way, if you wanted to know if it's the same, you can compare pointers, or if you want to access the ROI data directly, you can do that, but it doesn't require a copy. 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/3] checkasm/vp9dsp: rename the iszero function to is_zero
Hi,
On Sun, Jun 6, 2021 at 10:42 PM James Almer wrote:
> From: Matthieu Patou
>
> The function name iszero() may collide with a function in glibc.
>
> Suggested-by: ffm...@fb.com
> Signed-off-by: James Almer
> ---
> tests/checkasm/vp9dsp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tests/checkasm/vp9dsp.c b/tests/checkasm/vp9dsp.c
> index 99c023899f..44b02d60a2 100644
> --- a/tests/checkasm/vp9dsp.c
> +++ b/tests/checkasm/vp9dsp.c
> @@ -294,7 +294,7 @@ static int copy_subcoefs(int16_t *out, const int16_t
> *in, enum TxfmMode tx,
> return eob;
> }
>
> -static int iszero(const int16_t *c, int sz)
> +static int is_zero(const int16_t *c, int sz)
> {
> int n;
>
> @@ -362,8 +362,8 @@ static void check_itxfm(void)
> call_ref(dst0, sz * SIZEOF_PIXEL, subcoef0, eob);
> call_new(dst1, sz * SIZEOF_PIXEL, subcoef1, eob);
> if (memcmp(dst0, dst1, sz * sz * SIZEOF_PIXEL) ||
> -!iszero(subcoef0, sz * sz * SIZEOF_COEF) ||
> -!iszero(subcoef1, sz * sz * SIZEOF_COEF))
> +!is_zero(subcoef0, sz * sz * SIZEOF_COEF) ||
> +!is_zero(subcoef1, sz * sz * SIZEOF_COEF))
> fail();
>
> bench_new(dst, sz * SIZEOF_PIXEL, coef, eob);
> --
> 2.31.1
>
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 1/2] libavutil/cpu: Adds av_cpu_has_fast_gather to detect cpus with avx fast gather instruction
Hi Alan, On Mon, Jun 14, 2021 at 7:20 AM Alan Kelly < alankelly-at-google@ffmpeg.org> wrote: > Broadwell and later have fast gather instructions. > --- > This is so that the avx2 version of ff_hscale8to15X which uses gather > instructions is only selected on machines where it will actually be > faster. > We've in the past typically done this with a bit in the cpuflags return value. Can this be added there instead of being its own function? Also, what is the cycle count of ssse3/avx2 implementation for this specific function on Haswell? It would be good to note that in the respective patch so that we understand why the check was added. 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] libswscale: Adds ff_hscale8to15_4_avx2 and ff_hscale8to15_X4_avx2 for all filter sizes.
Hi Alan, On Fri, Jun 25, 2021 at 3:59 AM Alan Kelly < alankelly-at-google@ffmpeg.org> wrote: > These functions replace all ff_hscale8to15_*_ssse3 when avx2 is available. > Re-asking a question I asked before in the other thread: Also, what is the cycle count of ssse3/avx2 implementation for this specific function on Haswell? It would be good to note that in the respective patch so that we understand why the check was added. You should be able to find this in the checkasm --bench --test=X numbers for this relevant function. 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] libswscale: Adds ff_hscale8to15_4_avx2 and ff_hscale8to15_X4_avx2 for all filter sizes.
Hi Alan, On Fri, Jun 25, 2021 at 7:53 AM Alan Kelly wrote: > > > On Fri, Jun 25, 2021 at 1:26 PM Ronald S. Bultje > wrote: > >> Hi Alan, >> >> On Fri, Jun 25, 2021 at 3:59 AM Alan Kelly < >> alankelly-at-google@ffmpeg.org> wrote: >> >>> These functions replace all ff_hscale8to15_*_ssse3 when avx2 is >>> available. >>> >> >> Re-asking a question I asked before in the other thread: >> >> Also, what is the cycle count of ssse3/avx2 implementation for this >> specific function on Haswell? It would be good to note that in the >> respective patch so that we understand why the check was added. >> >> You should be able to find this in the checkasm --bench --test=X numbers >> for this relevant function. >> >> Ronald >> > > Hi Ronald, > > Skylake Haswell > hscale_8_to_15_width4_ssse3 761.2 760 > hscale_8_to_15_width4_avx2 468.7 957 > hscale_8_to_15_width8_ssse3 1170.7 1032 > hscale_8_to_15_width8_avx2 865.7 1979 > hscale_8_to_15_width12_ssse3 2172.2 2472 > hscale_8_to_15_width12_avx2 1245.7 2901 > hscale_8_to_15_width16_ssse3 2244.2 2400 > hscale_8_to_15_width16_avx2 1647.2 3681 > > As you can see, it is catastrophic on Haswell. In the next iteration of > the patch, I will update the description with these numbers. > Thanks, that's very helpful. No further comments from 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] Video codec design for very low-end decoder
Hi Lauri, On Mon, Jan 7, 2019 at 3:15 AM Lauri Kasanen wrote: > If you were to design a video codec for a very low-end decoder, what > would it look like? > Have you considered vp8? It may sound weird but this is basically what vp8 was great at: being really simple to decode. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
Hi, On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: > On Mon, 7 Jan 2019 12:02:58 -0500 > "Ronald S. Bultje" wrote: > > > Have you considered vp8? It may sound weird but this is basically what > vp8 > > was great at: being really simple to decode. > > VP8 has a reputation of being slow, so I didn't consider it. Benchmarks > show it as decoding slower than h264. > It is faster than h264 when comparing ffh264 vs. ffvp8: https://blogs.gnome.org/rbultje/files/2014/02/sintel_decspeed.png Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Video codec design for very low-end decoder
Hi, On Thu, Jan 10, 2019 at 2:41 PM Carl Eugen Hoyos wrote: > 2019-01-07 18:37 GMT+01:00, Ronald S. Bultje : > > Hi, > > > > On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen wrote: > > > >> On Mon, 7 Jan 2019 12:02:58 -0500 > >> "Ronald S. Bultje" wrote: > >> > >> > Have you considered vp8? It may sound weird but this is basically what > >> vp8 > >> > was great at: being really simple to decode. > >> > >> VP8 has a reputation of being slow, so I didn't consider it. Benchmarks > >> show it as decoding slower than h264. > >> > > > > It is faster than h264 when comparing ffh264 vs. ffvp8: > > > > https://blogs.gnome.org/rbultje/files/2014/02/sintel_decspeed.png > > Are the relations identical without asm optimizations? > I believe so, yes. The theory behind it would be that lack of per-symbol probability adaptations in CABAC and bidirectional prediction were missing in VP8, both of which incur a significant runtime overhead. Then, if you start disabling tools (e.g. CABAC -> CAVLC) this difference would probably diminish quite quickly. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
Hi, On Sun, Jan 13, 2019 at 4:39 AM Gyan wrote: > When someone submits a patch, it is implicit, unless stated otherwise, > that it is of their own initiative (and their own work), and thus they > are free to assign copyright. When work is performed for hire, the > copyright may belong to the employer. Such sponsored work cannot be > 'donated' to the project > But we don't do copyright assignment. Anyway, like several others, I'm against this proposal. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
On Sun, Jan 13, 2019 at 9:38 AM Nicolas George wrote: > Derek Buitenhuis (12019-01-13): > > This is a policy change, not a techncal change. > > Policy changes need to be motivated too. > Wait, what? *You* are suggesting a policy change, not me/us. There is no burden of proof on me. You have to convince me (and us) that your problem is important and your proposal solves the problem. I am not convinced. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
Hi, On Mon, Jan 14, 2019 at 11:13 AM Nicolas George wrote: > Ronald S. Bultje (12019-01-13): > > Wait, what? *You* are suggesting a policy change, not me/us. There is no > > burden of proof on me. You have to convince me (and us) that your problem > > is important and your proposal solves the problem. I am not convinced. > > I gave arguments in the commit message. Tell me what exactly you find > unconvincing in them, and I can elaborate. But just "I am not > convinced" is not how debating works. > You have seen a few bad-quality patches, and you now assume that there is (1) a correlation between bad patch quality and sponsorship and (2) that disclosure of sponsorship details will somehow address this constructively. I am unconvinced of both. For (1), specifically, you have only given anecdotical evidence, and you have not used any anecdotical evidence to the contrary, even though it exists in plain sight. For example, some of my patches have been sponsored. Are they bad quality? Which ones (I'd like to see if you can point out my sponsored vs. unsponsored patches based on your metric of poor patch quality)? I would like to see evidence that goes beyond anecdotes and holds up when applied to the full git tree. For (2), I am not convinced in particular that requiring people to disclose how much money they earn will make patches better. Quite the contrary, some cultures consider finance a private affair and so I think you'll just chase away valued contributors who have in the past provided very high-quality patches. This goes beyond the mere issue as privacy - which is also important, but is not what I'm talking about here. You claim that requiring people to disclose how much money they make *in particular* will significantly impact patch quality. But you provide no evidence for this claim, not even any anecdotical evidence. It is also not self-evident to me. I think it is merely punitive. Could you provide evidence that requiring people ti disclose how much money they make will improve patch quality? Or is it merely meant to discourage such patch submissions altogether? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Changes to configure for NDI SDK 3 on macOS
Hi Pranap, On Sat, Feb 16, 2019 at 11:43 AM Pranav Nutalapati < pranavnutalap...@gmail.com> wrote: > I’ve been trying to compile ffmpeg with NDI support on macOS and kept on > running into the error > > ld: library not found for -lndi > > when compiling. Having no experience with compiling things or C in > general, I poked around and tried various different things. However, the > issue turned out to be that under the configure file, both > libndi_newtek_indev_extralibs and libndi_newtek_outdev_extralibs had the > option “-lndi” when in fact, this library didn’t exist! > > Under /usr/local, I did find libndi.3.dylib. > Most systems automatically create symlinks from the unversioned to the versioned dylib (ln -s libndi.3.dylib libndi.dylib), which is how this is normally dealt with. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Changes to configure for NDI SDK 3 on macOS
Hi Pranav, On Sat, Feb 16, 2019 at 9:14 PM Pranav Nutalapati < pranavnutalap...@gmail.com> wrote: > Okay, so it’s a problem with my personal installation of NDI? > Yes. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] lavd: Remove libndi_newtek
Hi, On Sat, Mar 9, 2019 at 4:02 PM Martin Vignali wrote: > They have not responded to any communications: > > https://trac.ffmpeg.org/ticket/7589 > > > > > I still do not understand the link between the ticket and the removal of > lib ndi. > Is it plan to remove all features used by people who doesn't respect the > licence ? > I would not be against removing all closed-source support. I have voiced this before in the realvideo discussion: https://ffmpeg-devel.ffmpeg.narkive.com/Ok5y3HXO/patch-0-3-codec-wrapper-for-librv11-and-rmhd-muxer-demuxer Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
