From: "Martin Storsjö" <martin@martin.st>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] lavc/aarch64: unify formatting
Date: Mon, 20 Jun 2022 23:29:54 +0300 (EEST)
Message-ID: <dfd5dc64-23f-731-44d9-b5743ea34c30@martin.st> (raw)
In-Reply-To: <20220614110957.10546-1-jdek@itanimul.li>
On Tue, 14 Jun 2022, J. Dekker wrote:
> Performs the following changes:
> - Lower case format specifiers
> - Lower case sxtw/uxtw
> - Numeric labels on same line as next instruction
Why do you feel the need to do that? I like the occasional extra spacing
that an empty line for such labels adds - at least I wouldn't go changing
how that's done in other places. Where there are empty lines and where
there aren't, is up to the author IMO, based on how they see their code.
> - Indentation to 9/25
>
> Signed-off-by: J. Dekker <jdek@itanimul.li>
> ---
>
> I initially started writing a full lexer to do this but ended up
> wasting too much time on it. Now using Mostly text editor macros. Still
> need to skim through again and make a few manual changes here and there
> but wondering if there's any other major automatable changes I missed.
>
> libavcodec/aarch64/aacpsdsp_neon.S | 208 +++----
> libavcodec/aarch64/fft_neon.S | 89 ++-
> libavcodec/aarch64/fmtconvert_neon.S | 12 +-
> libavcodec/aarch64/h264cmc_neon.S | 534 +++++++++---------
> libavcodec/aarch64/h264dsp_neon.S | 664 +++++++++++------------
> libavcodec/aarch64/h264idct_neon.S | 418 +++++++-------
> libavcodec/aarch64/h264pred_neon.S | 16 +-
> libavcodec/aarch64/h264qpel_neon.S | 644 +++++++++++-----------
> libavcodec/aarch64/hevcdsp_idct_neon.S | 323 ++++++-----
> libavcodec/aarch64/hevcdsp_sao_neon.S | 8 +-
> libavcodec/aarch64/hpeldsp_neon.S | 504 ++++++++---------
> libavcodec/aarch64/mdct_neon.S | 27 +-
> libavcodec/aarch64/mpegaudiodsp_neon.S | 26 +-
> libavcodec/aarch64/neon.S | 246 ++++-----
> libavcodec/aarch64/opusdsp_neon.S | 106 ++--
> libavcodec/aarch64/pixblockdsp_neon.S | 6 +-
> libavcodec/aarch64/sbrdsp_neon.S | 308 +++++------
> libavcodec/aarch64/simple_idct_neon.S | 410 +++++++-------
> libavcodec/aarch64/synth_filter_neon.S | 15 +-
> libavcodec/aarch64/vc1dsp_neon.S | 206 +++----
> libavcodec/aarch64/videodsp.S | 3 +-
> libavcodec/aarch64/vp8dsp_neon.S | 485 ++++++++---------
> libavcodec/aarch64/vp9itxfm_16bpp_neon.S | 64 +--
> libavcodec/aarch64/vp9itxfm_neon.S | 50 +-
> libavcodec/aarch64/vp9lpf_16bpp_neon.S | 24 +-
> libavcodec/aarch64/vp9lpf_neon.S | 78 +--
> libavcodec/aarch64/vp9mc_16bpp_neon.S | 30 +-
> libavcodec/aarch64/vp9mc_aarch64.S | 9 +-
> libavcodec/aarch64/vp9mc_neon.S | 39 +-
> 29 files changed, 2688 insertions(+), 2864 deletions(-)
>
> diff --git a/libavcodec/aarch64/aacpsdsp_neon.S b/libavcodec/aarch64/aacpsdsp_neon.S
> index ff4e6e244a..dfa6a9dc33 100644
> --- a/libavcodec/aarch64/aacpsdsp_neon.S
> +++ b/libavcodec/aarch64/aacpsdsp_neon.S
> @@ -19,130 +19,130 @@
> #include "libavutil/aarch64/asm.S"
>
> function ff_ps_add_squares_neon, export=1
> -1: ld1 {v0.4S,v1.4S}, [x1], #32
> - fmul v0.4S, v0.4S, v0.4S
> - fmul v1.4S, v1.4S, v1.4S
> - faddp v2.4S, v0.4S, v1.4S
> - ld1 {v3.4S}, [x0]
> - fadd v3.4S, v3.4S, v2.4S
> - st1 {v3.4S}, [x0], #16
> - subs w2, w2, #4
> +1: ld1 {v0.4s,v1.4s}, [x1], #32
> + fmul v0.4s, v0.4s, v0.4s
> + fmul v1.4s, v1.4s, v1.4s
> + faddp v2.4s, v0.4s, v1.4s
> + ld1 {v3.4s}, [x0]
> + fadd v3.4s, v3.4s, v2.4s
> + st1 {v3.4s}, [x0], #16
> + subs w2, w2, #4
> b.gt 1b
This leaves the b.gt parameter misaligned with the rest - same thing in
the whole rest of this file.
> @@ -295,8 +295,7 @@ function fft_pass_neon
> st1 {v21.4s}, [x1], #16 // {z[o1],z[o1+1]}
> st1 {v22.4s}, [x2], #16 // {z[o2],z[o2+1]}
> st1 {v23.4s}, [x3], #16 // {z[o3],z[o3+1]}
> -1:
> - ld1 {v20.4s},[x2] // {z[o2],z[o2+1]}
> +1: ld1 {v20.4s},[x2] // {z[o2],z[o2+1]}
> ld1 {v22.4s},[x3] // {z[o3],z[o3+1]}
I really don't think getting rid of the empty line here or anywhere else
adds anything - I think it worsens readability.
> @@ -359,18 +358,18 @@ function fft\n\()_neon, align=6
> endfunc
> .endm
>
> - def_fft 32, 16, 8
> - def_fft 64, 32, 16
> - def_fft 128, 64, 32
> - def_fft 256, 128, 64
> - def_fft 512, 256, 128
> - def_fft 1024, 512, 256
> - def_fft 2048, 1024, 512
> - def_fft 4096, 2048, 1024
> - def_fft 8192, 4096, 2048
> - def_fft 16384, 8192, 4096
> - def_fft 32768, 16384, 8192
> - def_fft 65536, 32768, 16384
> + def_fft 32, 16, 8
> + def_fft 64, 32, 16
> + def_fft 128, 64, 32
> + def_fft 256, 128, 64
> + def_fft 512, 256, 128
> + def_fft 1024, 512, 256
> + def_fft 2048, 1024, 512
> + def_fft 4096, 2048, 1024
> + def_fft 8192, 4096, 2048
> + def_fft 16384, 8192, 4096
> + def_fft 32768, 16384, 8192
> + def_fft 65536, 32768, 16384
Previously, the columns were right-aligned here. I don't think we gain
anything from changing that.
> -const pmmp, align=4
> +const pmmp, align=4
Changes like this are good indeed.
> diff --git a/libavcodec/aarch64/h264cmc_neon.S b/libavcodec/aarch64/h264cmc_neon.S
> index f8e9407854..0add73ffec 100644
> --- a/libavcodec/aarch64/h264cmc_neon.S
> +++ b/libavcodec/aarch64/h264cmc_neon.S
> @@ -26,24 +26,24 @@
> /* chroma_mc8(uint8_t *dst, uint8_t *src, ptrdiff_t stride, int h, int x, int y) */
> .macro h264_chroma_mc8 type, codec=h264
> function ff_\type\()_\codec\()_chroma_mc8_neon, export=1
> - .ifc \type,avg
> +.ifc \type,avg
> mov x8, x0
> - .endif
> +.endif
I didn't mind the indented .if/.endif, but I won't oppose making it
consistent with the rest either, i.e. making it unindented.
> diff --git a/libavcodec/aarch64/h264dsp_neon.S b/libavcodec/aarch64/h264dsp_neon.S
> index ea221e6862..926c6e8362 100644
> .macro h264_loop_filter_luma
> - dup v22.16B, w2 // alpha
> - uxtl v24.8H, v24.8B
> - uabd v21.16B, v16.16B, v0.16B // abs(p0 - q0)
> - uxtl v24.4S, v24.4H
> - uabd v28.16B, v18.16B, v16.16B // abs(p1 - p0)
> - sli v24.8H, v24.8H, #8
> - uabd v30.16B, v2.16B, v0.16B // abs(q1 - q0)
> - sli v24.4S, v24.4S, #16
> - cmhi v21.16B, v22.16B, v21.16B // < alpha
> - dup v22.16B, w3 // beta
> - cmlt v23.16B, v24.16B, #0
> - cmhi v28.16B, v22.16B, v28.16B // < beta
> - cmhi v30.16B, v22.16B, v30.16B // < beta
> - bic v21.16B, v21.16B, v23.16B
> - uabd v17.16B, v20.16B, v16.16B // abs(p2 - p0)
> - and v21.16B, v21.16B, v28.16B
> - uabd v19.16B, v4.16B, v0.16B // abs(q2 - q0)
> - and v21.16B, v21.16B, v30.16B // < beta
Here's a misaligned comment that could be fixed while touching this
> + dup v22.16b, w2 // alpha
> + uxtl v24.8h, v24.8b
> + uabd v21.16b, v16.16b, v0.16b // abs(p0 - q0)
> + uxtl v24.4s, v24.4h
> + uabd v28.16b, v18.16b, v16.16b // abs(p1 - p0)
> + sli v24.8h, v24.8h, #8
> + uabd v30.16b, v2.16b, v0.16b // abs(q1 - q0)
> + sli v24.4s, v24.4s, #16
> + cmhi v21.16b, v22.16b, v21.16b // < alpha
> + dup v22.16b, w3 // beta
> + cmlt v23.16b, v24.16b, #0
> + cmhi v28.16b, v22.16b, v28.16b // < beta
> + cmhi v30.16b, v22.16b, v30.16b // < beta
> + bic v21.16b, v21.16b, v23.16b
> + uabd v17.16b, v20.16b, v16.16b // abs(p2 - p0)
> + and v21.16b, v21.16b, v28.16b
> + uabd v19.16b, v4.16b, v0.16b // abs(q2 - q0)
> + and v21.16b, v21.16b, v30.16b // < beta
> shrn v30.8b, v21.8h, #4
> mov x7, v30.d[0]
> - cmhi v17.16B, v22.16B, v17.16B // < beta
> - cmhi v19.16B, v22.16B, v19.16B // < beta
> + cmhi v17.16b, v22.16b, v17.16b // < beta
> + cmhi v19.16b, v22.16b, v19.16b // < beta
> cbz x7, 9f
> - and v17.16B, v17.16B, v21.16B
> - and v19.16B, v19.16B, v21.16B
> - and v24.16B, v24.16B, v21.16B
> - urhadd v28.16B, v16.16B, v0.16B
> - sub v21.16B, v24.16B, v17.16B
> - uqadd v23.16B, v18.16B, v24.16B
> - uhadd v20.16B, v20.16B, v28.16B
> - sub v21.16B, v21.16B, v19.16B
> - uhadd v28.16B, v4.16B, v28.16B
> - umin v23.16B, v23.16B, v20.16B
> - uqsub v22.16B, v18.16B, v24.16B
> - uqadd v4.16B, v2.16B, v24.16B
> - umax v23.16B, v23.16B, v22.16B
> - uqsub v22.16B, v2.16B, v24.16B
> - umin v28.16B, v4.16B, v28.16B
> - uxtl v4.8H, v0.8B
> - umax v28.16B, v28.16B, v22.16B
> - uxtl2 v20.8H, v0.16B
> - usubw v4.8H, v4.8H, v16.8B
> - usubw2 v20.8H, v20.8H, v16.16B
> - shl v4.8H, v4.8H, #2
> - shl v20.8H, v20.8H, #2
> - uaddw v4.8H, v4.8H, v18.8B
> - uaddw2 v20.8H, v20.8H, v18.16B
> - usubw v4.8H, v4.8H, v2.8B
> - usubw2 v20.8H, v20.8H, v2.16B
> - rshrn v4.8B, v4.8H, #3
> - rshrn2 v4.16B, v20.8H, #3
> - bsl v17.16B, v23.16B, v18.16B
> - bsl v19.16B, v28.16B, v2.16B
> - neg v23.16B, v21.16B
> - uxtl v28.8H, v16.8B
> - smin v4.16B, v4.16B, v21.16B
> - uxtl2 v21.8H, v16.16B
> - smax v4.16B, v4.16B, v23.16B
> - uxtl v22.8H, v0.8B
> - uxtl2 v24.8H, v0.16B
> - saddw v28.8H, v28.8H, v4.8B
> - saddw2 v21.8H, v21.8H, v4.16B
> - ssubw v22.8H, v22.8H, v4.8B
> - ssubw2 v24.8H, v24.8H, v4.16B
> - sqxtun v16.8B, v28.8H
> - sqxtun2 v16.16B, v21.8H
> - sqxtun v0.8B, v22.8H
> - sqxtun2 v0.16B, v24.8H
> + and v17.16b, v17.16b, v21.16b
> + and v19.16b, v19.16b, v21.16b
> + and v24.16b, v24.16b, v21.16b
> + urhadd v28.16b, v16.16b, v0.16b
> + sub v21.16b, v24.16b, v17.16b
> + uqadd v23.16b, v18.16b, v24.16b
> + uhadd v20.16b, v20.16b, v28.16b
> + sub v21.16b, v21.16b, v19.16b
> + uhadd v28.16b, v4.16b, v28.16b
> + umin v23.16b, v23.16b, v20.16b
> + uqsub v22.16b, v18.16b, v24.16b
> + uqadd v4.16b, v2.16b, v24.16b
> + umax v23.16b, v23.16b, v22.16b
> + uqsub v22.16b, v2.16b, v24.16b
> + umin v28.16b, v4.16b, v28.16b
> + uxtl v4.8h, v0.8b
> + umax v28.16b, v28.16b, v22.16b
> + uxtl2 v20.8h, v0.16b
> + usubw v4.8h, v4.8h, v16.8b
> + usubw2 v20.8h, v20.8h, v16.16b
> + shl v4.8h, v4.8h, #2
> + shl v20.8h, v20.8h, #2
> + uaddw v4.8h, v4.8h, v18.8b
> + uaddw2 v20.8h, v20.8h, v18.16b
> + usubw v4.8h, v4.8h, v2.8b
> + usubw2 v20.8h, v20.8h, v2.16b
> + rshrn v4.8b, v4.8h, #3
> + rshrn2 v4.16b, v20.8h, #3
> + bsl v17.16b, v23.16b, v18.16b
> + bsl v19.16b, v28.16b, v2.16b
> + neg v23.16b, v21.16b
> + uxtl v28.8h, v16.8b
> + smin v4.16b, v4.16b, v21.16b
> + uxtl2 v21.8h, v16.16b
> + smax v4.16b, v4.16b, v23.16b
> + uxtl v22.8h, v0.8b
> + uxtl2 v24.8h, v0.16b
> + saddw v28.8h, v28.8h, v4.8b
> + saddw2 v21.8h, v21.8h, v4.16b
> + ssubw v22.8h, v22.8h, v4.8b
> + ssubw2 v24.8h, v24.8h, v4.16b
> + sqxtun v16.8b, v28.8h
> + sqxtun2 v16.16b, v21.8h
> + sqxtun v0.8b, v22.8h
> + sqxtun2 v0.16b, v24.8h
> .endm
>
> function ff_h264_v_loop_filter_luma_neon, export=1
> h264_loop_filter_start
>
> - ld1 {v0.16B}, [x0], x1
> - ld1 {v2.16B}, [x0], x1
> - ld1 {v4.16B}, [x0], x1
> + ld1 {v0.16b}, [x0], x1
> + ld1 {v2.16b}, [x0], x1
> + ld1 {v4.16b}, [x0], x1
> sub x0, x0, x1, lsl #2
> sub x0, x0, x1, lsl #1
> - ld1 {v20.16B}, [x0], x1
> - ld1 {v18.16B}, [x0], x1
> - ld1 {v16.16B}, [x0], x1
> + ld1 {v20.16b}, [x0], x1
> + ld1 {v18.16b}, [x0], x1
> + ld1 {v16.16b}, [x0], x1
>
> h264_loop_filter_luma
>
> sub x0, x0, x1, lsl #1
> - st1 {v17.16B}, [x0], x1
> - st1 {v16.16B}, [x0], x1
> - st1 {v0.16B}, [x0], x1
> - st1 {v19.16B}, [x0]
> -9:
> - ret
> + st1 {v17.16b}, [x0], x1
> + st1 {v16.16b}, [x0], x1
> + st1 {v0.16b}, [x0], x1
> + st1 {v19.16b}, [x0]
> +9: ret
> endfunc
>
> function ff_h264_h_loop_filter_luma_neon, export=1
> h264_loop_filter_start
>
> sub x0, x0, #4
> - ld1 {v6.8B}, [x0], x1
> - ld1 {v20.8B}, [x0], x1
> - ld1 {v18.8B}, [x0], x1
> - ld1 {v16.8B}, [x0], x1
> - ld1 {v0.8B}, [x0], x1
> - ld1 {v2.8B}, [x0], x1
> - ld1 {v4.8B}, [x0], x1
> - ld1 {v26.8B}, [x0], x1
> - ld1 {v6.D}[1], [x0], x1
> - ld1 {v20.D}[1], [x0], x1
> - ld1 {v18.D}[1], [x0], x1
> - ld1 {v16.D}[1], [x0], x1
> - ld1 {v0.D}[1], [x0], x1
> - ld1 {v2.D}[1], [x0], x1
> - ld1 {v4.D}[1], [x0], x1
> - ld1 {v26.D}[1], [x0], x1
> + ld1 {v6.8b}, [x0], x1
> + ld1 {v20.8b}, [x0], x1
> + ld1 {v18.8b}, [x0], x1
> + ld1 {v16.8b}, [x0], x1
> + ld1 {v0.8b}, [x0], x1
> + ld1 {v2.8b}, [x0], x1
> + ld1 {v4.8b}, [x0], x1
> + ld1 {v26.8b}, [x0], x1
> + ld1 {v6.d}[1], [x0], x1
> + ld1 {v20.d}[1], [x0], x1
> + ld1 {v18.d}[1], [x0], x1
> + ld1 {v16.d}[1], [x0], x1
> + ld1 {v0.d}[1], [x0], x1
> + ld1 {v2.d}[1], [x0], x1
> + ld1 {v4.d}[1], [x0], x1
> + ld1 {v26.d}[1], [x0], x1
>
> transpose_8x16B v6, v20, v18, v16, v0, v2, v4, v26, v21, v23
>
> @@ -160,24 +158,23 @@ function ff_h264_h_loop_filter_luma_neon, export=1
>
> sub x0, x0, x1, lsl #4
> add x0, x0, #2
> - st1 {v17.S}[0], [x0], x1
> - st1 {v16.S}[0], [x0], x1
> - st1 {v0.S}[0], [x0], x1
> - st1 {v19.S}[0], [x0], x1
> - st1 {v17.S}[1], [x0], x1
> - st1 {v16.S}[1], [x0], x1
> - st1 {v0.S}[1], [x0], x1
> - st1 {v19.S}[1], [x0], x1
> - st1 {v17.S}[2], [x0], x1
> - st1 {v16.S}[2], [x0], x1
> - st1 {v0.S}[2], [x0], x1
> - st1 {v19.S}[2], [x0], x1
> - st1 {v17.S}[3], [x0], x1
> - st1 {v16.S}[3], [x0], x1
> - st1 {v0.S}[3], [x0], x1
> - st1 {v19.S}[3], [x0], x1
> -9:
> - ret
> + st1 {v17.s}[0], [x0], x1
> + st1 {v16.s}[0], [x0], x1
> + st1 {v0.s}[0], [x0], x1
> + st1 {v19.s}[0], [x0], x1
> + st1 {v17.s}[1], [x0], x1
> + st1 {v16.s}[1], [x0], x1
> + st1 {v0.s}[1], [x0], x1
> + st1 {v19.s}[1], [x0], x1
> + st1 {v17.s}[2], [x0], x1
> + st1 {v16.s}[2], [x0], x1
> + st1 {v0.s}[2], [x0], x1
> + st1 {v19.s}[2], [x0], x1
> + st1 {v17.s}[3], [x0], x1
> + st1 {v16.s}[3], [x0], x1
> + st1 {v0.s}[3], [x0], x1
> + st1 {v19.s}[3], [x0], x1
Here, I'd love to align the righthand columns that are uneven (although I
guess such changes are a bit out of scope for what you do here).
> @@ -193,139 +193,139 @@ function ff_h264_idct_add8_neon, export=1
> endfunc
>
> .macro idct8x8_cols pass
> - .if \pass == 0
> - va .req v18
> - vb .req v30
I think the custom formatting of these lines is better to keep as is,
rather than forcing it into the formatting of the rest.
> diff --git a/libavcodec/aarch64/h264qpel_neon.S b/libavcodec/aarch64/h264qpel_neon.S
> index 451fd8af24..3829f17bd1 100644
> --- a/libavcodec/aarch64/h264qpel_neon.S
> +++ b/libavcodec/aarch64/h264qpel_neon.S
> @@ -24,130 +24,130 @@
>
> /* H.264 qpel MC */
>
> -.macro lowpass_const r
> +.macro lowpass_const r
Here you could get rid of the double spaces after .macro too
> @@ -580,12 +580,12 @@ function \type\()_h264_qpel16_hv_lowpass_l2_neon
> endfunc
> .endm
>
> - h264_qpel16_hv put
> - h264_qpel16_hv avg
> + h264_qpel16_hv put
> + h264_qpel16_hv avg
>
> .macro h264_qpel8 type
> function ff_\type\()_h264_qpel8_mc10_neon, export=1
> - lowpass_const w3
> + lowpass_const w3
The parameter to lowpass_const was properly aligned before, now it no
longer is
> .macro pixfunc pfx, name, suf, rnd=1, avg=0
> - .if \rnd
> - .macro avg rd, rn, rm
> +.if \rnd
> +.macro avg rd, rn, rm
> urhadd \rd, \rn, \rm
I think this looks much more like a mess than it was before, TBH
> diff --git a/libavcodec/aarch64/opusdsp_neon.S b/libavcodec/aarch64/opusdsp_neon.S
> index 46c2be0874..3b2b89d068 100644
> --- a/libavcodec/aarch64/opusdsp_neon.S
> +++ b/libavcodec/aarch64/opusdsp_neon.S
> @@ -20,93 +20,93 @@
>
> // 0.85..^1 0.85..^2 0.85..^3 0.85..^4
> const tab_st, align=4
> - .word 0x3f599a00, 0x3f38f671, 0x3f1d382a, 0x3f05a32f
> + .word 0x3f599a00, 0x3f38f671, 0x3f1d382a, 0x3f05a32f
These used to be aligned with the comments above, now the no longer are
aligned
> diff --git a/libavcodec/aarch64/vc1dsp_neon.S b/libavcodec/aarch64/vc1dsp_neon.S
> index 9a96c2523c..7df48ea000 100644
> --- a/libavcodec/aarch64/vc1dsp_neon.S
> +++ b/libavcodec/aarch64/vc1dsp_neon.S
> @@ -1391,35 +1391,35 @@ function ff_vc1_unescape_buffer_helper_neon, export=1
> tst w1, #32
> b.ne 1f
>
> - ld1 {v0.16b, v1.16b, v2.16b}, [x0], #48
> - ext v25.16b, v0.16b, v1.16b, #1
This function intentionally used a different indentation style, to
visualize how multiple iterations of the same algorithm are unrolled and
interleaved with each other. It was discussed during the review of this
patch. So for that, I'd kinda be inclined to keep it as is.
There's lots of changes that I agree with here, but also lots of things I
disagree with. I think it'd be better to split it up over individual
patches, fixing one issue at a time (starting with the least controversial
ones), because right now it's too big and there's too many style
regressions intermixed among with the good changes.
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
prev parent reply other threads:[~2022-06-20 20:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 11:09 J. Dekker
2022-06-20 20:29 ` Martin Storsjö [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dfd5dc64-23f-731-44d9-b5743ea34c30@martin.st \
--to=martin@martin.st \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git