Re: [FFmpeg-devel] Need to reduce ffmpeg.exe size in n6.0
Le 15 novembre 2023 00:27:29 GMT+02:00, "Kumar, Rahul via ffmpeg-devel" a écrit : >Hi All, > >I am trying to reduce the size of ffmpeg.exe for using it to convert RTSP >streams to HLS. That is a complex matter that requires professional support. So please consider hiring a consultant. You can't reasonably expect volunteers to assist with that sort of problem, especially not whilst undersigning as a large commercial electronic vendor. Br, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/hevcdsp_qpel_neon: using movi.16b instead of movi.2d
Building iOS platform with arm64, the compiler has a warning: "instruction
movi.2d with immediate #0 may not function correctly on this CPU, converting to
movi.16b"
Signed-off-by: xufuji456 <839789...@qq.com>
---
libavcodec/aarch64/hevcdsp_epel_neon.S | 136 -
libavcodec/aarch64/hevcdsp_qpel_neon.S | 52 +-
libavcodec/aarch64/mpegaudiodsp_neon.S | 8 +-
libswscale/aarch64/hscale.S| 72 ++---
4 files changed, 134 insertions(+), 134 deletions(-)
diff --git a/libavcodec/aarch64/hevcdsp_epel_neon.S
b/libavcodec/aarch64/hevcdsp_epel_neon.S
index a2a051210f..c077c204cc 100644
--- a/libavcodec/aarch64/hevcdsp_epel_neon.S
+++ b/libavcodec/aarch64/hevcdsp_epel_neon.S
@@ -694,7 +694,7 @@ function ff_hevc_put_hevc_epel_h4_8_neon_i8mm, export=1
trn1v4.2s, v4.2s, v5.2s
trn1v6.2s, v6.2s, v7.2s
trn1v4.2d, v4.2d, v6.2d
-moviv16.2d, #0
+moviv16.16b, #0
usdot v16.4s, v4.16b, v30.16b
xtn v16.4h, v16.4s
st1 {v16.4h}, [x0], x10
@@ -714,8 +714,8 @@ function ff_hevc_put_hevc_epel_h6_8_neon_i8mm, export=1
trn2v17.2s, v4.2s, v5.2s
trn1v6.2s, v6.2s, v7.2s
trn1v16.2d, v16.2d, v6.2d
-moviv18.2d, #0
-moviv19.2d, #0
+moviv18.16b, #0
+moviv19.16b, #0
usdot v18.4s, v16.16b, v30.16b
usdot v19.2s, v17.8b, v30.8b
xtn v18.4h, v18.4s
@@ -736,8 +736,8 @@ function ff_hevc_put_hevc_epel_h8_8_neon_i8mm, export=1
ext v7.16b, v4.16b, v4.16b, #3
zip1v20.4s, v4.4s, v6.4s
zip1v21.4s, v5.4s, v7.4s
-moviv16.2d, #0
-moviv17.2d, #0
+moviv16.16b, #0
+moviv17.16b, #0
usdot v16.4s, v20.16b, v30.16b
usdot v17.4s, v21.16b, v30.16b
xtn v16.4h, v16.4s
@@ -761,9 +761,9 @@ function ff_hevc_put_hevc_epel_h12_8_neon_i8mm, export=1
trn1v4.4s, v20.4s, v21.4s
trn2v5.4s, v20.4s, v21.4s
trn1v6.4s, v22.4s, v23.4s
-moviv16.2d, #0
-moviv17.2d, #0
-moviv18.2d, #0
+moviv16.16b, #0
+moviv17.16b, #0
+moviv18.16b, #0
usdot v16.4s, v4.16b, v30.16b
usdot v17.4s, v5.16b, v30.16b
usdot v18.4s, v6.16b, v30.16b
@@ -788,10 +788,10 @@ function ff_hevc_put_hevc_epel_h16_8_neon_i8mm, export=1
zip2v22.4s, v0.4s, v6.4s
zip1v21.4s, v5.4s, v7.4s
zip2v23.4s, v5.4s, v7.4s
-moviv16.2d, #0
-moviv17.2d, #0
-moviv18.2d, #0
-moviv19.2d, #0
+moviv16.16b, #0
+moviv17.16b, #0
+moviv18.16b, #0
+moviv19.16b, #0
usdot v16.4s, v20.16b, v30.16b
usdot v17.4s, v21.16b, v30.16b
usdot v18.4s, v22.16b, v30.16b
@@ -815,14 +815,14 @@ function ff_hevc_put_hevc_epel_h24_8_neon_i8mm, export=1
ext v26.16b, v1.16b, v1.16b, #1
ext v27.16b, v1.16b, v1.16b, #2
ext v28.16b, v1.16b, v1.16b, #3
-moviv16.2d, #0
-moviv17.2d, #0
-moviv18.2d, #0
-moviv19.2d, #0
-moviv20.2d, #0
-moviv21.2d, #0
-moviv22.2d, #0
-moviv23.2d, #0
+moviv16.16b, #0
+moviv17.16b, #0
+moviv18.16b, #0
+moviv19.16b, #0
+moviv20.16b, #0
+moviv21.16b, #0
+moviv22.16b, #0
+moviv23.16b, #0
usdot v16.4s, v0.16b, v30.16b
usdot v17.4s, v5.16b, v30.16b
usdot v18.4s, v6.16b, v30.16b
@@ -861,14 +861,14 @@ function ff_hevc_put_hevc_epel_h32_8_neon_i8mm, export=1
ext v26.16b, v1.16b, v2.16b, #1
ext v27.16b, v1.16b, v2.16b, #2
ext v28.16b, v1.16b, v2.16b, #3
-moviv16.2d, #0
-moviv17.2d, #0
-moviv18.2d, #0
-moviv19.2d, #0
-moviv20.2d, #0
-moviv21.2d, #0
-moviv22.2d, #0
-moviv23.2d, #0
+moviv16.16b, #0
+moviv17.16b, #0
+moviv18.16b,
Re: [FFmpeg-devel] [PATCH v2 2/6] libavformat/sdp: remove whitespaces in fmtp
Le mar. 14 nov. 2023 à 09:47, Tomas Härdin a écrit : > > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > Whitespaces after semicolon breaks some servers > > Which servers? If the spec allows whitespace then the onus is on them > to fix their implementations. The logic could be inverted: if the specs allow for both but a majority of users do not accept white space, it would make sense to change the implementation to maximize compatibility. > /Tomas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] swscale/utils: correctly return from sws_init_single_context
Hi On Tue, Nov 14, 2023 at 02:14:37PM +0100, Niklas Haas wrote: > On Mon, 13 Nov 2023 19:30:08 +0100 Michael Niedermayer > wrote: > > but i dont feel like i fully understand the issue here so maybe iam missing > > the goal of this patchset somewhat > > So, to summarize the main problem: > > 1. sws_init_single_context() previously hard-coded decisions based on >c->srcRange and c->dstRange. This is fundamentally broken, as >srcRange/dstRange can change at any time with >sws_setColorspaceDetails. > > 2. To fix this, this function was made to not early-return, and instead >run the rest of the init code just in case range conversion is needed >later. (With the check for whether or not the special converter can >be used being moved to the callsite instead of the setup site) > > 3. This caused problems for non-YUV inputs, because previously these >would always early return, but now they run the rest of the code, >which triggers at least one assertion for float32 formats. > > 4. To fix this, this commit restores the early-return for non-YUV, >preserving the status quo of existing behavior w.r.t not hitting the >rest of the init function. > > 5. Separately, this commit fixes an error in previous condition (2) at >the callsite, which relied on c->lumConvertRange being unset when no >range conversion is needed. However, that condition did not match the >condition used in the setup check before. > > > * convert_unscaled should only be set when used > > OR > > * if these are set "always" if not alphablend and convert_unscaled should be > > two seperate fields. But i have not at all looked at what consequences > > that > > would have so maybe that has issues > > convert_unscaled cannot be set only when used because we don't yet know > if it will be used or not. There is also no advantage I see to splitting > the fields, as they have basically the same logic attached to them > - being dependent only on whether or not range conversion is needed. > > > Also if some range convert should not be used/set for some cases then > > the check should maybe be where the range convert is setup not far away > > from it. I mean a check close to the related code is easier to understand > > > > One alternative that would make this possible would be to re-run whole > context init from sws_setColorspaceDetails, if the srcRange/dstRange > change. would this result in overall cleaner code or do you see some problems with this ? Given the messi-ness that the always setting results in i would maybe suggest to explore this and see if this is cleaner. Its conceptually not wrong that if parameters change that init should be redone. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart than the original author, trying to rewrite it will not make it better. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Need to reduce ffmpeg.exe size in n6.0
Hi, On Tue, Nov 14, 2023, 17:27 Kumar, Rahul via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > Hi All, > > I am trying to reduce the size of ffmpeg.exe for using it to convert RTSP > streams to HLS. > > I used the below command to configure : > > ./configure --prefix=ffmpeg_64/ --enable-shared --disable-everything > --enable-protocol=rtsp --enable-protocol=http --enable-demuxer=rtsp > --enable-muxer=hls --enable-muxer=segment --enable-muxer=mpegts > --enable-encoder=mpeg2video --enable-encoder=aac --enable-decoder=h264 > --enable-decoder=aac --enable-parser=h264 --enable-parser=aac > --enable-filter=copy --enable-filter=aformat --enable-filter=aresample > --enable-bsf=h264_mp4toannexb --enable-bsf=aac_adtstoasc --enable-gpl > --enable-version3 --enable-nonfree --enable-small > --yasmexe='C:/c99/yasm-1.3.0-win64.exe' --target-os=win64 --arch=x86_64 > --toolchain=msvc > > > After this I ran "make" and "make install" command which created 1.2 mb > ffmpeg.exe in bin folder. This ffmpeg.exe is not working for me. Can > somebody guide me if I am missing anything here? > > > Regards, > Rahul > Honeywell > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > Saying it doesn't work is decidedly nebulous. Also, ffmpeg-devel is a development-centered list and not the correct forum for CLI usage help. -- Sean McGovern > ___ ffmpeg-devel mailing list ffmpeg-devel@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] Need to reduce ffmpeg.exe size in n6.0
Hi All, I am trying to reduce the size of ffmpeg.exe for using it to convert RTSP streams to HLS. I used the below command to configure : ./configure --prefix=ffmpeg_64/ --enable-shared --disable-everything --enable-protocol=rtsp --enable-protocol=http --enable-demuxer=rtsp --enable-muxer=hls --enable-muxer=segment --enable-muxer=mpegts --enable-encoder=mpeg2video --enable-encoder=aac --enable-decoder=h264 --enable-decoder=aac --enable-parser=h264 --enable-parser=aac --enable-filter=copy --enable-filter=aformat --enable-filter=aresample --enable-bsf=h264_mp4toannexb --enable-bsf=aac_adtstoasc --enable-gpl --enable-version3 --enable-nonfree --enable-small --yasmexe='C:/c99/yasm-1.3.0-win64.exe' --target-os=win64 --arch=x86_64 --toolchain=msvc After this I ran "make" and "make install" command which created 1.2 mb ffmpeg.exe in bin folder. This ffmpeg.exe is not working for me. Can somebody guide me if I am missing anything here? Regards, Rahul Honeywell ___ ffmpeg-devel mailing list ffmpeg-devel@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 2/6] libavformat/sdp: remove whitespaces in fmtp
On Tue, 14 Nov 2023, 21:54 Tomas Härdin, wrote: > tis 2023-11-14 klockan 17:14 +0100 skrev Kieran Kunhya: > > On Tue, 14 Nov 2023 at 16:47, Tomas Härdin wrote: > > > > > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > > > Whitespaces after semicolon breaks some servers > > > > > > Which servers? If the spec allows whitespace then the onus is on > > > them > > > to fix their implementations. > > > > > > /Tomas > > > > > > > Poor Tomas, you are not versed in SDP witchcraft where a single > > character > > breaks dozens of devices but fixes dozens of others. > > I have in fact had some contact with SDP, much to my chagrin. This is > also why we should be very strict with it, and be very clear what the > spec says, and/or have the spec changed to reflect reality. With MXF, > being strict has already paid dividends. > > /Tomas > Not comparable IMO, these are embedded IoT devices that will never be fixed. I have spent months of my life debugging a single character issue in SDP. I kid you not. Kieran > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/flacdsp: R-V V decorrelate_indep 16-bit packed
flac_decorrelate_indep2_16_c:981.7
flac_decorrelate_indep2_16_rvv_i32: 199.2
flac_decorrelate_indep4_16_c: 1749.7
flac_decorrelate_indep4_16_rvv_i32: 401.2
flac_decorrelate_indep6_16_c: 2517.7
flac_decorrelate_indep6_16_rvv_i32: 858.0
flac_decorrelate_indep8_16_c: 3285.7
flac_decorrelate_indep8_16_rvv_i32: 1123.5
---
libavcodec/riscv/flacdsp_init.c | 22 +
libavcodec/riscv/flacdsp_rvv.S | 157
2 files changed, 179 insertions(+)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp_init.c
index 5bfaad7ca8..d44a92cd35 100644
--- a/libavcodec/riscv/flacdsp_init.c
+++ b/libavcodec/riscv/flacdsp_init.c
@@ -24,6 +24,14 @@
#include "libavutil/cpu.h"
#include "libavcodec/flacdsp.h"
+void ff_flac_decorrelate_indep2_16_rvv(uint8_t **out, int32_t **in,
+ int channels, int len, int shift);
+void ff_flac_decorrelate_indep4_16_rvv(uint8_t **out, int32_t **in,
+ int channels, int len, int shift);
+void ff_flac_decorrelate_indep6_16_rvv(uint8_t **out, int32_t **in,
+ int channels, int len, int shift);
+void ff_flac_decorrelate_indep8_16_rvv(uint8_t **out, int32_t **in,
+ int channels, int len, int shift);
void ff_flac_decorrelate_ls_16_rvv(uint8_t **out, int32_t **in,
int channels, int len, int shift);
void ff_flac_decorrelate_rs_16_rvv(uint8_t **out, int32_t **in,
@@ -54,6 +62,20 @@ av_cold void ff_flacdsp_init_riscv(FLACDSPContext *c, enum
AVSampleFormat fmt,
if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
switch (fmt) {
case AV_SAMPLE_FMT_S16:
+switch (channels) {
+case 2:
+c->decorrelate[0] = ff_flac_decorrelate_indep2_16_rvv;
+break;
+case 4:
+c->decorrelate[0] = ff_flac_decorrelate_indep4_16_rvv;
+break;
+case 6:
+c->decorrelate[0] = ff_flac_decorrelate_indep6_16_rvv;
+break;
+case 8:
+c->decorrelate[0] = ff_flac_decorrelate_indep8_16_rvv;
+break;
+}
c->decorrelate[1] = ff_flac_decorrelate_ls_16_rvv;
c->decorrelate[2] = ff_flac_decorrelate_rs_16_rvv;
c->decorrelate[3] = ff_flac_decorrelate_ms_16_rvv;
diff --git a/libavcodec/riscv/flacdsp_rvv.S b/libavcodec/riscv/flacdsp_rvv.S
index 5a0607e044..12b456f7da 100644
--- a/libavcodec/riscv/flacdsp_rvv.S
+++ b/libavcodec/riscv/flacdsp_rvv.S
@@ -21,6 +21,163 @@
#include "libavutil/riscv/asm.S"
#if (__riscv_xlen == 64)
+func ff_flac_decorrelate_indep2_16_rvv, zve32x
+ld a0, (a0)
+ld a2, 8(a1)
+ld a1, (a1)
+1:
+vsetvli t0, a3, e32, m8, ta, ma
+vle32.v v0, (a1)
+sub a3, a3, t0
+vle32.v v8, (a2)
+sh2add a1, t0, a1
+vsll.vx v0, v0, a4
+sh2add a2, t0, a2
+vsll.vx v8, v8, a4
+vsetvli zero, zero, e16, m4, ta, ma
+vncvt.x.x.w v16, v0
+vncvt.x.x.w v20, v8
+vsseg2e16.v v16, (a0)
+sh2add a0, t0, a0
+bneza3, 1b
+
+ret
+endfunc
+
+func ff_flac_decorrelate_indep4_16_rvv, zve32x
+ld a0, (a0)
+ld a2, 8(a1)
+ld t1, 16(a1)
+ld t2, 24(a1)
+ld a1, (a1)
+1:
+vsetvli t0, a3, e32, m4, ta, ma
+vle32.v v0, (a1)
+sub a3, a3, t0
+vle32.v v4, (a2)
+sh2add a1, t0, a1
+vsll.vx v0, v0, a4
+sh2add a2, t0, a2
+vle32.v v8, (t1)
+sh2add t1, t0, t1
+vsll.vx v4, v4, a4
+vle32.v v12, (t2)
+sh2add t2, t0, t2
+vsll.vx v8, v8, a4
+vsll.vx v12, v12, a4
+vsetvli zero, zero, e16, m2, ta, ma
+vncvt.x.x.w v16, v0
+vncvt.x.x.w v18, v4
+vncvt.x.x.w v20, v8
+vncvt.x.x.w v22, v12
+vsseg4e16.v v16, (a0)
+sh3add a0, t0, a0
+bneza3, 1b
+
+ret
+endfunc
+
+func ff_flac_decorrelate_indep6_16_rvv, zve32x
+ld a0, (a0)
+ld a2, 8(a1)
+ld t1, 16(a1)
+ld t2, 24(a1)
+ld t3, 32(a1)
+ld t4, 40(a1)
+ld a1, (a1)
+1:
+vsetvli t0, a3, e32, m2, ta, ma
+vle32.v v0, (a1)
+sub a3, a3, t0
+vle32.v v2, (a2)
+sh2add a1, t0, a1
+vsll.vx v0, v0, a4
+sh2add a2, t0, a2
+vle32.v v4, (t1)
+sh2add t1, t0, t1
+vsll.vx v2, v2, a4
+vle32.v v6, (t2)
+sh2add t2, t0, t2
+vsll.vx v4, v4, a4
+vle32.v v8, (t3)
+sh2add t3, t0, t3
+vsll.vx v6, v6, a4
+vle32.v v10, (t4)
+sh2add t4, t0, t4
+vsll.vx v8, v8, a4
+slli
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
tis 2023-11-14 klockan 18:46 +0200 skrev Rémi Denis-Courmont: > Le tiistaina 14. marraskuuta 2023, 17.56.24 EET Tomas Härdin a écrit > : > > Ballots should be public IMO, secret voting is cowardice. > > The French (XIXth century) Empire used notoriously public ballots, > and the > results were skewed to say the least. There is a good reason why > ballots are > supposed to be confidential. > > And I don't think FFmpeg is immune to the same sort of issues. > Consider the > case of developers with any kind of corporate affiliation or > financial > dependency. What's to prevent their boss from telling them how to > vote if the > ballots are public? Secret ballots do not prevent this. The only method we know that works is voting in person with pen and paper. It's honestly surprising how much trust is given to e-voting by people of which I assume a majority have CS degrees. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@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 2/6] libavformat/sdp: remove whitespaces in fmtp
tis 2023-11-14 klockan 17:14 +0100 skrev Kieran Kunhya: > On Tue, 14 Nov 2023 at 16:47, Tomas Härdin wrote: > > > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > > Whitespaces after semicolon breaks some servers > > > > Which servers? If the spec allows whitespace then the onus is on > > them > > to fix their implementations. > > > > /Tomas > > > > Poor Tomas, you are not versed in SDP witchcraft where a single > character > breaks dozens of devices but fixes dozens of others. I have in fact had some contact with SDP, much to my chagrin. This is also why we should be very strict with it, and be very clear what the spec says, and/or have the spec changed to reflect reality. With MXF, being strict has already paid dividends. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@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 2/6] libavformat/sdp: remove whitespaces in fmtp
tis 2023-11-14 klockan 18:51 +0200 skrev Rémi Denis-Courmont: > Le tiistaina 14. marraskuuta 2023, 17.47.07 EET Tomas Härdin a écrit > : > > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > > Whitespaces after semicolon breaks some servers > > > > Which servers? If the spec allows whitespace then the onus is on > > them > > to fix their implementations. > > I couldn't find any note to the effect that white spaces are allowed > to separate > format parameters in RFC4566, but maybe I didn't look hard enough. > > I think that most implementations just happen to ignore white-spaces, > either > *because* some broken implementations like FFmpeg do send them, or > just by > implementation accident. It wouldn't be the first time FFmpeg did something wrong Anyway I'm not formally against this patch, especially since it's not something I maintain :) /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@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
Rémi Denis-Courmont (12023-11-14): > Like for example, people could give votes to associates of the leading > contracting company of FFmpeg at the given time in hope of looking good to > get > subcontracted later. Or all legal VideoLAN members feeling morally obliged to > vote for other VideoLAN members (and they are quite of us in the FFmpeg GA). Hum. This is an angle I had neglected, thanks for bringing it up. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On 14 Nov 2023, at 20:32, Ronald S. Bultje wrote: > On Tue, Nov 14, 2023 at 2:28 PM Nicolas George wrote: > >> but nobody here knows >> > > Unsubstantiated FUD. > > Move on. +1 There is no good in even more discussions right now. If really many people think public ballots are a great idea, this can be brought up later in the GA again, after all the other votes that need to be done right now are over… > > 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 mailing list ffmpeg-devel@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: > I hope you can grasp the difference between CAN and WOULD. That would be > better than calling somebody's logical arguments “FUD”. > You're right, we should call things by their name, these arguments are illogical. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Tue, Nov 14, 2023 at 2:28 PM Nicolas George wrote: > but nobody here knows > Unsubstantiated FUD. Move on. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Ronald S. Bultje (12023-11-14): > > Nothing prevents their boss from telling them how to vote, even if the > > ballots are secret. > How is this not just unsubstantiated FUD? Because it is just plain logical truth: somebody's boss CAN do what I described in the part of my mail that you just snipped. That is a simple fact. (Try arguing against it…) Whether any particular somebody's WOULD actually do it… depends on the boss. Some are definitely not above that at all, but nobody here knows if they are around the FFmpeg project. I hope you can grasp the difference between CAN and WOULD. That would be better than calling somebody's logical arguments “FUD”. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [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".
[FFmpeg-devel] [PATCH v2] avcodec/decode: guard against NULL hw_frames_ctx
Guard against segfault running VLC decoding under msys2 [1]:
Thread 33 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 37728.0xadd0]
ff_hwaccel_frame_priv_alloc (avctx=0x6447b00, hwaccel_picture_private=0x65dfd00)
at libavcodec/decode.c:1848
1848frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
(gdb) bt
at libavcodec/decode.c:1848
at libavcodec/h264_slice.c:208
first_slice=1) at libavcodec/h264_slice.c:1599
at libavcodec/h264_slice.c:2130
at libavcodec/h264dec.c:652
got_frame=0x646e4b0, avpkt=0x64522c0) at libavcodec/h264dec.c:1048
(gdb) p avctx
$1 = (AVCodecContext *) 0x6447b00
(gdb) p avctx->hw_frames_ctx
$2 = (AVBufferRef *) 0x0
v2: check for free_frame_priv (Hendrik)
See[1]: https://github.com/msys2/MINGW-packages/pull/19050
Fixes: be07145109 ("avcodec: add AVHWAccel.free_frame_priv callback")
CC: Lynne
CC: Christoph Reiter
Signed-off-by: Dmitry Rogozhkin
---
libavcodec/decode.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index ad39021..58f887d 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1838,17 +1838,29 @@ int ff_copy_palette(void *dst, const AVPacket *src,
void *logctx)
int ff_hwaccel_frame_priv_alloc(AVCodecContext *avctx, void
**hwaccel_picture_private)
{
const FFHWAccel *hwaccel = ffhwaccel(avctx->hwaccel);
-AVHWFramesContext *frames_ctx;
if (!hwaccel || !hwaccel->frame_priv_data_size)
return 0;
av_assert0(!*hwaccel_picture_private);
-frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
-*hwaccel_picture_private =
ff_refstruct_alloc_ext(hwaccel->frame_priv_data_size, 0,
- frames_ctx->device_ctx,
-
hwaccel->free_frame_priv);
+if (hwaccel->free_frame_priv) {
+AVHWFramesContext *frames_ctx;
+
+if (!avctx->hw_frames_ctx)
+return AVERROR(ENOMEM);
+
+frames_ctx = (AVHWFramesContext *) avctx->hw_frames_ctx->data;
+if (!frames_ctx)
+return AVERROR(ENOMEM);
+
+*hwaccel_picture_private =
ff_refstruct_alloc_ext(hwaccel->frame_priv_data_size, 0,
+
frames_ctx->device_ctx,
+
hwaccel->free_frame_priv);
+} else {
+*hwaccel_picture_private =
ff_refstruct_allocz(hwaccel->frame_priv_data_size);
+}
+
if (!*hwaccel_picture_private)
return AVERROR(ENOMEM);
--
1.8.3.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] [ANNOUNCE] Repeat vote: GA voters list updates
Le tiistaina 14. marraskuuta 2023, 20.44.18 EET Nicolas George a écrit : > Nothing prevents their boss from telling them how to vote, even if the > ballots are secret. Ultimately, nothing prevents their boss from literally telling them how to vote. But obviously unless the boss is actively monitoring their screen whilst they vote, they won't know what they voted for. That's a huge difference from public ballot. And the literal boss is just the "extreme" case. But if ballots are public, some people will naturally be inclined to vote for those that they want to cure favour from, rather than whom they think is best fit for the role. Like for example, people could give votes to associates of the leading contracting company of FFmpeg at the given time in hope of looking good to get subcontracted later. Or all legal VideoLAN members feeling morally obliged to vote for other VideoLAN members (and they are quite of us in the FFmpeg GA). I know you would be the last to do that sort of thing, but you are not the only voter. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/flacdsp: R-V V decorrelate_indep 32-bit
flac_decorrelate_indep2_32_c: 981.7
flac_decorrelate_indep2_32_rvv_i32: 183.7
flac_decorrelate_indep4_32_c: 1749.7
flac_decorrelate_indep4_32_rvv_i32: 362.5
flac_decorrelate_indep6_32_c: 2517.7
flac_decorrelate_indep6_32_rvv_i32: 715.2
flac_decorrelate_indep8_32_c: 3285.7
flac_decorrelate_indep8_32_rvv_i32: 909.0
---
libavcodec/riscv/flacdsp_init.c | 22 ++
libavcodec/riscv/flacdsp_rvv.S | 132
2 files changed, 154 insertions(+)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp_init.c
index 0e7be25d98..5bfaad7ca8 100644
--- a/libavcodec/riscv/flacdsp_init.c
+++ b/libavcodec/riscv/flacdsp_init.c
@@ -30,6 +30,14 @@ void ff_flac_decorrelate_rs_16_rvv(uint8_t **out, int32_t
**in,
int channels, int len, int shift);
void ff_flac_decorrelate_ms_16_rvv(uint8_t **out, int32_t **in,
int channels, int len, int shift);
+void ff_flac_decorrelate_indep2_32_rvv(uint8_t **out, int32_t **in,
+ int channels, int len, int shift);
+void ff_flac_decorrelate_indep4_32_rvv(uint8_t **out, int32_t **in,
+ int channels, int len, int shift);
+void ff_flac_decorrelate_indep6_32_rvv(uint8_t **out, int32_t **in,
+ int channels, int len, int shift);
+void ff_flac_decorrelate_indep8_32_rvv(uint8_t **out, int32_t **in,
+ int channels, int len, int shift);
void ff_flac_decorrelate_ls_32_rvv(uint8_t **out, int32_t **in,
int channels, int len, int shift);
void ff_flac_decorrelate_rs_32_rvv(uint8_t **out, int32_t **in,
@@ -51,6 +59,20 @@ av_cold void ff_flacdsp_init_riscv(FLACDSPContext *c, enum
AVSampleFormat fmt,
c->decorrelate[3] = ff_flac_decorrelate_ms_16_rvv;
break;
case AV_SAMPLE_FMT_S32:
+switch (channels) {
+case 2:
+c->decorrelate[0] = ff_flac_decorrelate_indep2_32_rvv;
+break;
+case 4:
+c->decorrelate[0] = ff_flac_decorrelate_indep4_32_rvv;
+break;
+case 6:
+c->decorrelate[0] = ff_flac_decorrelate_indep6_32_rvv;
+break;
+case 8:
+c->decorrelate[0] = ff_flac_decorrelate_indep8_32_rvv;
+break;
+}
c->decorrelate[1] = ff_flac_decorrelate_ls_32_rvv;
c->decorrelate[2] = ff_flac_decorrelate_rs_32_rvv;
c->decorrelate[3] = ff_flac_decorrelate_ms_32_rvv;
diff --git a/libavcodec/riscv/flacdsp_rvv.S b/libavcodec/riscv/flacdsp_rvv.S
index 616565ed7e..5a0607e044 100644
--- a/libavcodec/riscv/flacdsp_rvv.S
+++ b/libavcodec/riscv/flacdsp_rvv.S
@@ -95,6 +95,138 @@ func ff_flac_decorrelate_ms_16_rvv, zve32x
ret
endfunc
+func ff_flac_decorrelate_indep2_32_rvv, zve32x
+ld a0, (a0)
+ld a2, 8(a1)
+ld a1, (a1)
+1:
+vsetvli t0, a3, e32, m4, ta, ma
+vle32.v v0, (a1)
+sub a3, a3, t0
+vle32.v v4, (a2)
+sh2add a1, t0, a1
+vsll.vx v0, v0, a4
+sh2add a2, t0, a2
+vsll.vx v4, v4, a4
+vsseg2e32.v v0, (a0)
+sh3add a0, t0, a0
+bneza3, 1b
+
+ret
+endfunc
+
+func ff_flac_decorrelate_indep4_32_rvv, zve32x
+ld a0, (a0)
+ld a2, 8(a1)
+ld t1, 16(a1)
+ld t2, 24(a1)
+ld a1, (a1)
+1:
+vsetvli t0, a3, e32, m2, ta, ma
+vle32.v v0, (a1)
+sub a3, a3, t0
+vle32.v v2, (a2)
+sh2add a1, t0, a1
+vsll.vx v0, v0, a4
+sh2add a2, t0, a2
+vle32.v v4, (t1)
+sh2add t1, t0, t1
+vsll.vx v2, v2, a4
+vle32.v v6, (t2)
+sh2add t2, t0, t2
+vsll.vx v4, v4, a4
+sllit0, t0, 4
+vsll.vx v6, v6, a4
+vsseg4e32.v v0, (a0)
+add a0, t0, a0
+bneza3, 1b
+
+ret
+endfunc
+
+func ff_flac_decorrelate_indep6_32_rvv, zve32x
+ld a0, (a0)
+ld a2, 8(a1)
+ld t1, 16(a1)
+ld t2, 24(a1)
+ld t3, 32(a1)
+ld t4, 40(a1)
+ld a1, (a1)
+1:
+vsetvli t0, a3, e32, m1, ta, ma
+vle32.v v0, (a1)
+sub a3, a3, t0
+vle32.v v1, (a2)
+sh2add a1, t0, a1
+vsll.vx v0, v0, a4
+sh2add a2, t0, a2
+vle32.v v2, (t1)
+sh2add t1, t0, t1
+vsll.vx v1, v1, a4
+vle32.v v3, (t2)
+sh2add t2, t0, t2
+vsll.vx v2, v2, a4
+vle32.v v4, (t3)
+sh2add t3, t0, t3
+vsll.vx v3, v3, a4
+vle32.v v5, (t4)
+sh2add t4, t0, t4
+vsll.vx v4, v4, a4
+sllit0, t0, 3
+vsll.vx v5, v5, a4
+
Re: [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references
On Tue, Nov 14, 2023 at 06:32:19PM +0100, Hendrik Leppkes wrote:
> On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
> wrote:
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/h264_picture.c | 1 +
> > libavcodec/h264_slice.c | 19 ++-
> > libavcodec/h264dec.c | 1 +
> > libavcodec/h264dec.h | 4
> > 4 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> > index 691c61eea23..3234141dbd6 100644
> > --- a/libavcodec/h264_picture.c
> > +++ b/libavcodec/h264_picture.c
> > @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture *dst,
> > const H264Picture *src)
> > dst->field_picture = src->field_picture;
> > dst->reference = src->reference;
> > dst->recovered = src->recovered;
> > +dst->gray = src->gray;
> > dst->invalid_gap = src->invalid_gap;
> > dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> > dst->mb_width = src->mb_width;
> > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > index 4861a2cabba..2c4ab89dae1 100644
> > --- a/libavcodec/h264_slice.c
> > +++ b/libavcodec/h264_slice.c
> > @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
> > h->poc.prev_frame_num= h->poc.frame_num;
> >
> > h->recovery_frame= h1->recovery_frame;
> > +h->non_gray = h1->non_gray;
> >
> > return err;
> > }
> > @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h, const
> > H264SliceContext *sl,
> > if (ret < 0)
> > return ret;
> > h->short_ref[0]->poc = prev->poc + 2U;
> > +h->short_ref[0]->gray = prev->gray;
> > ff_thread_report_progress(>short_ref[0]->tf, INT_MAX,
> > 0);
> > if (h->short_ref[0]->field_picture)
> > ff_thread_report_progress(>short_ref[0]->tf,
> > INT_MAX, 1);
> > -} else if (!h->frame_recovered && !h->avctx->hwaccel)
> > +} else if (!h->frame_recovered && !h->avctx->hwaccel) {
> > color_frame(h->short_ref[0]->f, c);
> > +h->short_ref[0]->gray = 1;
> > +}
>
> While we can't color invalid frames for hwaccels easily, the flag
> should perhaps still be applied, as they are equally invalid.
ok
> Thinking about this, maybe the name should be less the color we
> happened to use for it, and more like "placeholder" or "invalid" or
> anything like that?
"invalid" is a quite generic term that covers more than this case.
and iam not sure if "placeholder" is really good description of them.
I picked "gray" because i had no better idea and they are gray
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Rémi Denis-Courmont (12023-11-14): > The French (XIXth century) Empire used notoriously public ballots, and the > results were skewed to say the least. There is a good reason why ballots are > supposed to be confidential. > > And I don't think FFmpeg is immune to the same sort of issues. Consider the > case of developers with any kind of corporate affiliation or financial > dependency. What's to prevent their boss from telling them how to vote if the > ballots are public? Nothing prevents their boss from telling them how to vote, even if the ballots are secret. The kind of secrecy a remote voting software can give us is “urn-style” secrecy: once the ballot is in the box, now way of knowing whose ballot it is. But to prevent bosses from interfering, we would need “voting-booth-style” secrecy: secrecy as the ballot is being cast and no way for the person who cast it to prove what they voted for. Vote-from-home systems cannot provide voting-booth-style secrecy: somebody can hover behind your back while you cast your ballot, or even demand you surrender your secret token. Urn-style secrecy, the only kind we can have, only protects from casual interference, like a kind in a conservative family not daring vote liberal, or an elected official voting against the interests of their biggest campaign donors. This is obviously not a problem for a libre software projects where contributors are all over the world and barely know each others. Now that the question has been raised and I had a chance to reflect on it, I think votes should probably be public. For votes about technical questions, it seems to me quite obvious. For votes about people, like the one now, it is more doubtful because it can lead to more personal polarization, but I am rather in favor too. Also, I will say it here instead of sending a separate mail: I find the strategy of legal intimidation about the GDPR disgusting. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/decode: guard against NULL hw_frames_ctx
On Tue, Nov 14, 2023 at 7:23 PM Dmitry Rogozhkin
wrote:
>
> Gurd against segfault running VLC decoding under msys2 [1]:
>
> Thread 33 received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 37728.0xadd0]
> ff_hwaccel_frame_priv_alloc (avctx=0x6447b00,
> hwaccel_picture_private=0x65dfd00)
> at libavcodec/decode.c:1848
> 1848frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
> (gdb) bt
> at libavcodec/decode.c:1848
> at libavcodec/h264_slice.c:208
> first_slice=1) at libavcodec/h264_slice.c:1599
> at libavcodec/h264_slice.c:2130
> at libavcodec/h264dec.c:652
> got_frame=0x646e4b0, avpkt=0x64522c0) at libavcodec/h264dec.c:1048
>
> (gdb) p avctx
> $1 = (AVCodecContext *) 0x6447b00
> (gdb) p avctx->hw_frames_ctx
> $2 = (AVBufferRef *) 0x0
>
> See[1]: https://github.com/msys2/MINGW-packages/pull/19050
> Fixes: be07145109 ("avcodec: add AVHWAccel.free_frame_priv callback")
> CC: Lynne
> CC: Christoph Reiter
> Signed-off-by: Dmitry Rogozhkin
> ---
> libavcodec/decode.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index ad39021..3caaeec 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1845,9 +1845,9 @@ int ff_hwaccel_frame_priv_alloc(AVCodecContext *avctx,
> void **hwaccel_picture_pr
>
> av_assert0(!*hwaccel_picture_private);
>
> -frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
> +frames_ctx = (AVHWFramesContext *) avctx->hw_frames_ctx ?
> avctx->hw_frames_ctx->data : NULL;
> *hwaccel_picture_private =
> ff_refstruct_alloc_ext(hwaccel->frame_priv_data_size, 0,
> - frames_ctx->device_ctx,
> + frames_ctx ?
> frames_ctx->device_ctx : NULL,
>
> hwaccel->free_frame_priv);
The free_frame_priv callback is not usable when no context is
available. The code should be updated to check if the hwaccel has a
free_frame_priv callback and then require a frames_ctx to be set and
otherwise error out (instead of crashing), and if free_frame_priv is
not set, then it can allocate a buffer without these requirements.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/decode: guard against NULL hw_frames_ctx
Gurd against segfault running VLC decoding under msys2 [1]:
Thread 33 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 37728.0xadd0]
ff_hwaccel_frame_priv_alloc (avctx=0x6447b00, hwaccel_picture_private=0x65dfd00)
at libavcodec/decode.c:1848
1848frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
(gdb) bt
at libavcodec/decode.c:1848
at libavcodec/h264_slice.c:208
first_slice=1) at libavcodec/h264_slice.c:1599
at libavcodec/h264_slice.c:2130
at libavcodec/h264dec.c:652
got_frame=0x646e4b0, avpkt=0x64522c0) at libavcodec/h264dec.c:1048
(gdb) p avctx
$1 = (AVCodecContext *) 0x6447b00
(gdb) p avctx->hw_frames_ctx
$2 = (AVBufferRef *) 0x0
See[1]: https://github.com/msys2/MINGW-packages/pull/19050
Fixes: be07145109 ("avcodec: add AVHWAccel.free_frame_priv callback")
CC: Lynne
CC: Christoph Reiter
Signed-off-by: Dmitry Rogozhkin
---
libavcodec/decode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index ad39021..3caaeec 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1845,9 +1845,9 @@ int ff_hwaccel_frame_priv_alloc(AVCodecContext *avctx,
void **hwaccel_picture_pr
av_assert0(!*hwaccel_picture_private);
-frames_ctx = (AVHWFramesContext *)avctx->hw_frames_ctx->data;
+frames_ctx = (AVHWFramesContext *) avctx->hw_frames_ctx ?
avctx->hw_frames_ctx->data : NULL;
*hwaccel_picture_private =
ff_refstruct_alloc_ext(hwaccel->frame_priv_data_size, 0,
- frames_ctx->device_ctx,
+ frames_ctx ?
frames_ctx->device_ctx : NULL,
hwaccel->free_frame_priv);
if (!*hwaccel_picture_private)
return AVERROR(ENOMEM);
--
1.8.3.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 v2 1/1] tools/general_assembly.pl - add options to print names, emails or both
Pushed. And sorry, I didn't notice that the ML mangled your email :/ -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references
On Tue, Nov 14, 2023 at 6:21 PM Michael Niedermayer
wrote:
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264_picture.c | 1 +
> libavcodec/h264_slice.c | 19 ++-
> libavcodec/h264dec.c | 1 +
> libavcodec/h264dec.h | 4
> 4 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> index 691c61eea23..3234141dbd6 100644
> --- a/libavcodec/h264_picture.c
> +++ b/libavcodec/h264_picture.c
> @@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture *dst,
> const H264Picture *src)
> dst->field_picture = src->field_picture;
> dst->reference = src->reference;
> dst->recovered = src->recovered;
> +dst->gray = src->gray;
> dst->invalid_gap = src->invalid_gap;
> dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
> dst->mb_width = src->mb_width;
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 4861a2cabba..2c4ab89dae1 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
> h->poc.prev_frame_num= h->poc.frame_num;
>
> h->recovery_frame= h1->recovery_frame;
> +h->non_gray = h1->non_gray;
>
> return err;
> }
> @@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h, const
> H264SliceContext *sl,
> if (ret < 0)
> return ret;
> h->short_ref[0]->poc = prev->poc + 2U;
> +h->short_ref[0]->gray = prev->gray;
> ff_thread_report_progress(>short_ref[0]->tf, INT_MAX, 0);
> if (h->short_ref[0]->field_picture)
> ff_thread_report_progress(>short_ref[0]->tf, INT_MAX,
> 1);
> -} else if (!h->frame_recovered && !h->avctx->hwaccel)
> +} else if (!h->frame_recovered && !h->avctx->hwaccel) {
> color_frame(h->short_ref[0]->f, c);
> +h->short_ref[0]->gray = 1;
> +}
While we can't color invalid frames for hwaccels easily, the flag
should perhaps still be applied, as they are equally invalid.
Thinking about this, maybe the name should be less the color we
happened to use for it, and more like "placeholder" or "invalid" or
anything like that?
> h->short_ref[0]->frame_num = h->poc.prev_frame_num;
> }
> }
> @@ -2007,6 +2011,19 @@ static int h264_slice_init(H264Context *h,
> H264SliceContext *sl,
> (sl->ref_list[j][i].reference & 3);
> }
>
> +if (sl->slice_type_nos == AV_PICTURE_TYPE_I) {
> +h->cur_pic_ptr->gray = 0;
> +h->non_gray = 1;
> +} else {
> +int gray = 0;
> +for (j = 0; j < sl->list_count; j++) {
> +for (i = 0; i < sl->ref_count[j]; i++) {
> +gray |= sl->ref_list[j][i].parent->gray;
> +}
> +}
> +h->cur_pic_ptr->gray = gray;
> +}
> +
> if (h->avctx->debug & FF_DEBUG_PICT_INFO) {
> av_log(h->avctx, AV_LOG_DEBUG,
> "slice:%d %c mb:%d %c%s%s frame:%d poc:%d/%d ref:%d/%d qp:%d
> loop:%d:%d:%d weight:%d%s %s\n",
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index ef9e60bbf33..7ea55db75dd 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -492,6 +492,7 @@ static void h264_decode_flush(AVCodecContext *avctx)
> ff_h264_unref_picture(>cur_pic);
>
> h->mb_y = 0;
> +h->non_gray = 0;
>
> ff_h264_free_tables(h);
> h->context_initialized = 0;
> diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
> index ede51951727..366626c056c 100644
> --- a/libavcodec/h264dec.h
> +++ b/libavcodec/h264dec.h
> @@ -154,6 +154,8 @@ typedef struct H264Picture {
>
> /// RefStruct reference; its pointee is shared between decoding threads.
> atomic_int *decode_error_flags;
> +
> +int gray;
> } H264Picture;
>
> typedef struct H264Ref {
> @@ -567,6 +569,8 @@ typedef struct H264Context {
> struct FFRefStructPool *ref_index_pool;
> struct FFRefStructPool *decode_error_flags_pool;
> int ref2frm[MAX_SLICES][2][64]; ///< reference to frame number
> lists, used in the loop filter, the first 2 are for -2,-1
> +
> +int non_gray; ///< Did we encounter a intra frame
> after a gray gap frame
> } H264Context;
>
> extern const uint16_t ff_h264_mb_sizes[4];
> --
> 2.17.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".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or
Re: [FFmpeg-devel] [PATCH v6] fftools/ffplay: add hwaccel decoding support
On 2023/11/12 23:25, Zhao Zhili wrote: -Original Message- From: Zhao Zhili Sent: 2023年11月9日 21:06 To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH v6] fftools/ffplay: add hwaccel decoding support Ping. v6 didn’t changed much compare to v5. I'm planning to push this week if no objection. Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@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 6/6] avcodec/h264dec: Support skipping frames that used gray gap frames
Signed-off-by: Michael Niedermayer
---
libavcodec/h264dec.c | 7 +++
libavcodec/h264dec.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index b48821db244..aa0022a3aba 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -939,6 +939,12 @@ static int finalize_frame(H264Context *h, AVFrame *dst,
H264Picture *out, int *g
(h->avctx->flags2 & AV_CODEC_FLAG2_SHOW_ALL) ||
out->recovered)) {
+if (h->skip_gray > 0 &&
+h->non_gray && out->gray &&
+!(h->avctx->flags2 & AV_CODEC_FLAG2_SHOW_ALL)
+)
+return 0;
+
if (!h->avctx->hwaccel &&
(out->field_poc[0] == INT_MAX ||
out->field_poc[1] == INT_MAX)
@@ -1091,6 +1097,7 @@ static const AVOption h264_options[] = {
{ "nal_length_size", "nal_length_size", OFFSET(nal_length_size),
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VDX },
{ "enable_er", "Enable error resilience on damaged frames (unsafe)",
OFFSET(enable_er), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
{ "x264_build", "Assume this x264 version if no x264 version found in any
SEI", OFFSET(x264_build), AV_OPT_TYPE_INT, {.i64 = -1}, -1, INT_MAX, VD },
+{ "skip_gray", "Do not return gray gap frames", OFFSET(skip_gray),
AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VD },
{ "noref_gray", "Avoid using gray gap frames as references",
OFFSET(noref_gray), AV_OPT_TYPE_INT, {.i64 = 1}, -1, 1, VD },
{ NULL },
};
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index 591769ab258..447c2499d97 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -572,6 +572,7 @@ typedef struct H264Context {
int non_gray; ///< Did we encounter a intra frame
after a gray gap frame
int noref_gray;
+int skip_gray;
} H264Context;
extern const uint16_t ff_h264_mb_sizes[4];
--
2.17.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".
[FFmpeg-devel] [PATCH 5/6] avcodec/h264: Avoid using gray gap frames as references
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_refs.c | 11 +++
libavcodec/h264dec.c | 1 +
libavcodec/h264dec.h | 1 +
3 files changed, 13 insertions(+)
diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index 92778e737a5..9bc7b20988f 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -410,6 +410,17 @@ int ff_h264_build_ref_list(H264Context *h,
H264SliceContext *sl)
else
return -1;
}
+if (h->noref_gray>0 && sl->ref_list[list][index].parent->gray &&
h->non_gray) {
+for (int j=0; jlist_count; j++) {
+int list2 = (list+j)&1;
+if (h->default_ref[list2].parent &&
!h->default_ref[list2].parent->gray
+&& !(!FIELD_PICTURE(h) &&
(h->default_ref[list2].reference&3) != 3)) {
+sl->ref_list[list][index] = h->default_ref[list2];
+av_log(h, AV_LOG_DEBUG, "replacement of gray gap
frame\n");
+break;
+}
+}
+}
av_assert0(av_buffer_get_ref_count(sl->ref_list[list][index].parent->f->buf[0])
> 0);
}
}
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 7ea55db75dd..b48821db244 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -1091,6 +1091,7 @@ static const AVOption h264_options[] = {
{ "nal_length_size", "nal_length_size", OFFSET(nal_length_size),
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VDX },
{ "enable_er", "Enable error resilience on damaged frames (unsafe)",
OFFSET(enable_er), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
{ "x264_build", "Assume this x264 version if no x264 version found in any
SEI", OFFSET(x264_build), AV_OPT_TYPE_INT, {.i64 = -1}, -1, INT_MAX, VD },
+{ "noref_gray", "Avoid using gray gap frames as references",
OFFSET(noref_gray), AV_OPT_TYPE_INT, {.i64 = 1}, -1, 1, VD },
{ NULL },
};
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index 366626c056c..591769ab258 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -571,6 +571,7 @@ typedef struct H264Context {
int ref2frm[MAX_SLICES][2][64]; ///< reference to frame number lists,
used in the loop filter, the first 2 are for -2,-1
int non_gray; ///< Did we encounter a intra frame
after a gray gap frame
+int noref_gray;
} H264Context;
extern const uint16_t ff_h264_mb_sizes[4];
--
2.17.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".
[FFmpeg-devel] [PATCH 4/6] avcodec/h264: keep track of which frames used gray references
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_picture.c | 1 +
libavcodec/h264_slice.c | 19 ++-
libavcodec/h264dec.c | 1 +
libavcodec/h264dec.h | 4
4 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
index 691c61eea23..3234141dbd6 100644
--- a/libavcodec/h264_picture.c
+++ b/libavcodec/h264_picture.c
@@ -96,6 +96,7 @@ static void h264_copy_picture_params(H264Picture *dst, const
H264Picture *src)
dst->field_picture = src->field_picture;
dst->reference = src->reference;
dst->recovered = src->recovered;
+dst->gray = src->gray;
dst->invalid_gap = src->invalid_gap;
dst->sei_recovery_frame_cnt = src->sei_recovery_frame_cnt;
dst->mb_width = src->mb_width;
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 4861a2cabba..2c4ab89dae1 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -457,6 +457,7 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
h->poc.prev_frame_num= h->poc.frame_num;
h->recovery_frame= h1->recovery_frame;
+h->non_gray = h1->non_gray;
return err;
}
@@ -1544,11 +1545,14 @@ static int h264_field_start(H264Context *h, const
H264SliceContext *sl,
if (ret < 0)
return ret;
h->short_ref[0]->poc = prev->poc + 2U;
+h->short_ref[0]->gray = prev->gray;
ff_thread_report_progress(>short_ref[0]->tf, INT_MAX, 0);
if (h->short_ref[0]->field_picture)
ff_thread_report_progress(>short_ref[0]->tf, INT_MAX,
1);
-} else if (!h->frame_recovered && !h->avctx->hwaccel)
+} else if (!h->frame_recovered && !h->avctx->hwaccel) {
color_frame(h->short_ref[0]->f, c);
+h->short_ref[0]->gray = 1;
+}
h->short_ref[0]->frame_num = h->poc.prev_frame_num;
}
}
@@ -2007,6 +2011,19 @@ static int h264_slice_init(H264Context *h,
H264SliceContext *sl,
(sl->ref_list[j][i].reference & 3);
}
+if (sl->slice_type_nos == AV_PICTURE_TYPE_I) {
+h->cur_pic_ptr->gray = 0;
+h->non_gray = 1;
+} else {
+int gray = 0;
+for (j = 0; j < sl->list_count; j++) {
+for (i = 0; i < sl->ref_count[j]; i++) {
+gray |= sl->ref_list[j][i].parent->gray;
+}
+}
+h->cur_pic_ptr->gray = gray;
+}
+
if (h->avctx->debug & FF_DEBUG_PICT_INFO) {
av_log(h->avctx, AV_LOG_DEBUG,
"slice:%d %c mb:%d %c%s%s frame:%d poc:%d/%d ref:%d/%d qp:%d
loop:%d:%d:%d weight:%d%s %s\n",
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index ef9e60bbf33..7ea55db75dd 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -492,6 +492,7 @@ static void h264_decode_flush(AVCodecContext *avctx)
ff_h264_unref_picture(>cur_pic);
h->mb_y = 0;
+h->non_gray = 0;
ff_h264_free_tables(h);
h->context_initialized = 0;
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index ede51951727..366626c056c 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -154,6 +154,8 @@ typedef struct H264Picture {
/// RefStruct reference; its pointee is shared between decoding threads.
atomic_int *decode_error_flags;
+
+int gray;
} H264Picture;
typedef struct H264Ref {
@@ -567,6 +569,8 @@ typedef struct H264Context {
struct FFRefStructPool *ref_index_pool;
struct FFRefStructPool *decode_error_flags_pool;
int ref2frm[MAX_SLICES][2][64]; ///< reference to frame number lists,
used in the loop filter, the first 2 are for -2,-1
+
+int non_gray; ///< Did we encounter a intra frame
after a gray gap frame
} H264Context;
extern const uint16_t ff_h264_mb_sizes[4];
--
2.17.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".
[FFmpeg-devel] [PATCH 3/6] avcodec/h264dec: More elaborate documentation for frame_recovered
Signed-off-by: Michael Niedermayer
---
libavcodec/h264dec.h | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index b0c54ad82fb..ede51951727 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -524,7 +524,17 @@ typedef struct H264Context {
*/
#define FRAME_RECOVERED_HEURISTIC (1 << 2)
-int frame_recovered;///< Initial frame has been completely recovered
+/**
+ * Initial frame has been completely recovered.
+ *
+ * Once this is set, all following decoded as well as displayed frames
will be marked as recovered
+ * If a frame is marked as recovered frame_recovered will be set once this
frame is output and thus
+ * all subsequently output fraames are also marked as recovered
+ *
+ * In effect, if you want all subsequent DECODED frames marked as
recovered, set frame_recovered
+ * If you want all subsequent DISPAYED frames marked as recovered, set the
frame->recovered
+ */
+int frame_recovered;
int has_recovery_point;
--
2.17.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".
[FFmpeg-devel] [PATCH 2/6] avcodec/h264: Use FRAME_RECOVERED_HEURISTIC instead of IDR/SEI
This keeps IDR/SEI and heuristically detected recovery points cleaner seperated
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_refs.c | 4 ++--
libavcodec/h264dec.h | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index 25e521dafc0..92778e737a5 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -822,9 +822,9 @@ int ff_h264_execute_ref_pic_marking(H264Context *h)
|| pps_ref_count[0] <= 1 + (h->picture_structure != PICT_FRAME) &&
pps_ref_count[1] <= 1)
&& pps_ref_count[0]<=2 + (h->picture_structure != PICT_FRAME) +
(2*!h->has_recovery_point)
&& h->cur_pic_ptr->f->pict_type == AV_PICTURE_TYPE_I){
-h->cur_pic_ptr->recovered |= FRAME_RECOVERED_IDR;
+h->cur_pic_ptr->recovered |= FRAME_RECOVERED_HEURISTIC;
if(!h->avctx->has_b_frames)
-h->frame_recovered |= FRAME_RECOVERED_SEI;
+h->frame_recovered |= FRAME_RECOVERED_HEURISTIC;
}
out:
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index 5ce3a6be735..b0c54ad82fb 100644
--- a/libavcodec/h264dec.h
+++ b/libavcodec/h264dec.h
@@ -519,6 +519,10 @@ typedef struct H264Context {
* so all the following frames in presentation order are correct.
*/
#define FRAME_RECOVERED_SEI (1 << 1)
+/**
+ * Recovery point detected by heuristic
+ */
+#define FRAME_RECOVERED_HEURISTIC (1 << 2)
int frame_recovered;///< Initial frame has been completely recovered
--
2.17.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".
[FFmpeg-devel] [PATCH 1/6] avcodec/h264: Seperate SEI and IDR recovery handling
This avoids SEI and IDR recovery flags affecting each other
Also eliminate litteral numbers from recovery handling
This should make the code clearer
Improves: tickets/4738/tickets_cut.ts
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_refs.c | 2 +-
libavcodec/h264_slice.c | 30 --
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index a11597745c8..25e521dafc0 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -822,7 +822,7 @@ int ff_h264_execute_ref_pic_marking(H264Context *h)
|| pps_ref_count[0] <= 1 + (h->picture_structure != PICT_FRAME) &&
pps_ref_count[1] <= 1)
&& pps_ref_count[0]<=2 + (h->picture_structure != PICT_FRAME) +
(2*!h->has_recovery_point)
&& h->cur_pic_ptr->f->pict_type == AV_PICTURE_TYPE_I){
-h->cur_pic_ptr->recovered |= 1;
+h->cur_pic_ptr->recovered |= FRAME_RECOVERED_IDR;
if(!h->avctx->has_b_frames)
h->frame_recovered |= FRAME_RECOVERED_SEI;
}
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 07cc1b094f9..4861a2cabba 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1356,12 +1356,11 @@ static int h264_select_output_frame(H264Context *h)
} else
h->next_outputed_poc = out->poc;
-if (out->recovered) {
-// We have reached an recovery point and all frames after it in
-// display order are "recovered".
-h->frame_recovered |= FRAME_RECOVERED_SEI;
-}
-out->recovered |= !!(h->frame_recovered & FRAME_RECOVERED_SEI);
+// We have reached an recovery point and all frames after it in
+// display order are "recovered".
+h->frame_recovered |= out->recovered;
+
+out->recovered |= h->frame_recovered & FRAME_RECOVERED_SEI;
if (!out->recovered) {
if (!(h->avctx->flags & AV_CODEC_FLAG_OUTPUT_CORRUPT) &&
@@ -1643,15 +1642,18 @@ static int h264_field_start(H264Context *h, const
H264SliceContext *sl,
h->cur_pic_ptr->f->flags |= AV_FRAME_FLAG_KEY * !!(nal->type ==
H264_NAL_IDR_SLICE);
-if (nal->type == H264_NAL_IDR_SLICE ||
-(h->recovery_frame == h->poc.frame_num && nal->ref_idc)) {
-h->recovery_frame = -1;
-h->cur_pic_ptr->recovered = 1;
-}
-// If we have an IDR, all frames after it in decoded order are
-// "recovered".
-if (nal->type == H264_NAL_IDR_SLICE)
+if (nal->type == H264_NAL_IDR_SLICE) {
+h->cur_pic_ptr->recovered |= FRAME_RECOVERED_IDR;
+// If we have an IDR, all frames after it in decoded order are
+// "recovered".
h->frame_recovered |= FRAME_RECOVERED_IDR;
+}
+
+if (h->recovery_frame == h->poc.frame_num && nal->ref_idc) {
+h->recovery_frame = -1;
+h->cur_pic_ptr->recovered |= FRAME_RECOVERED_SEI;
+}
+
#if 1
h->cur_pic_ptr->recovered |= h->frame_recovered;
#else
--
2.17.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 v2 2/6] libavformat/sdp: remove whitespaces in fmtp
Le tiistaina 14. marraskuuta 2023, 17.47.07 EET Tomas Härdin a écrit : > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > Whitespaces after semicolon breaks some servers > > Which servers? If the spec allows whitespace then the onus is on them > to fix their implementations. I couldn't find any note to the effect that white spaces are allowed to separate format parameters in RFC4566, but maybe I didn't look hard enough. I think that most implementations just happen to ignore white-spaces, either *because* some broken implementations like FFmpeg do send them, or just by implementation accident. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
Le tiistaina 14. marraskuuta 2023, 17.56.24 EET Tomas Härdin a écrit : > Ballots should be public IMO, secret voting is cowardice. The French (XIXth century) Empire used notoriously public ballots, and the results were skewed to say the least. There is a good reason why ballots are supposed to be confidential. And I don't think FFmpeg is immune to the same sort of issues. Consider the case of developers with any kind of corporate affiliation or financial dependency. What's to prevent their boss from telling them how to vote if the ballots are public? -- レミ・デニ-クールモン http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] Repeat vote: GA voters list updates
On Tue, Nov 14, 2023 at 10:56 AM Tomas Härdin wrote: > Ballot secrecy cannot actually be guaranteed. While I'm not versed in > the specifics of CIVS, I doubt it has solved problems like evil > sysadmin. Ballots should be public IMO, secret voting is cowardice. > That way duplicate ballots are easily filtered out ex-post and > scrutable to all. > Absolutely not, you're mixing cowardice for safety and privacy, especially in a community that is prone to toxic language and harassment. Further reading https://www.rochester.edu/newscenter/should-secret-voting-be-mandatory-yes-say-political-scientists-459082/ https://www.quora.com/Should-voting-be-public-so-that-everyone-one-knows-what-everyone-else-voted-for-instead-of-secret https://daily.jstor.org/why-do-we-vote-by-secret-ballot/ https://campaignlegal.org/update/voters-have-right-secret-ballot https://www.quora.com/Why-is-it-important-for-votes-to-be-secret What really matters is records for every vote, and automatic random audits, so that results can be reproduced. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/6] libavformat/sdp: remove whitespaces in fmtp
On Tue, 14 Nov 2023 at 16:47, Tomas Härdin wrote: > tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > > Whitespaces after semicolon breaks some servers > > Which servers? If the spec allows whitespace then the onus is on them > to fix their implementations. > > /Tomas > Poor Tomas, you are not versed in SDP witchcraft where a single character breaks dozens of devices but fixes dozens of others. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@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
tis 2023-11-14 klockan 13:49 +0100 skrev Thilo Borgmann via ffmpeg- devel: > Am 14.11.23 um 10:28 schrieb Tomas Härdin: > > lör 2023-11-11 klockan 10:42 +0100 skrev Jean-Baptiste Kempf: > > > > > > You have been told, now, several times, that a list of email is a > > > collection of Private Information, according to a GDPR and that > > > you > > > are a process of this PI, and therefore liable to the law. > > > > Everyone with a copy of the git repository already has this > > information, and it has been willingly given by all contributors. > > Is > > further processing of already extant PI really not permissible > > according to the GDPR? Do we have to seek permission from all > > contributors to publish our git repositories containing PI that > > they > > have already given implicit permission to publish? > > +1 that it is no problem to reshare public information. > A problem would arise if we connect this information with other > information - new unknown information or an unknown link between the > two. Makes sense to me. > > That said, this part strikes me as far more relevant wrt the GDPR: > > > > > I patched the voting system to log all authorized voters in the > > > future to prevent this situation in the future. > > The logfile before: > > Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll > E_af2d343f39602862 > Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll > E_af2d343f39602862 > > The logfile afterwards: > > Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll > E_af2d343f39602862 someth...@somewhere.com > Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll > E_af2d343f39602862 somethinge...@somewhereelse.com > > The other outputs are unchanged. > This does not break any privacy about the ballots - it is still > unknown what ballots voted if at all neither what that ballot > eventually voted for. Ballot secrecy cannot actually be guaranteed. While I'm not versed in the specifics of CIVS, I doubt it has solved problems like evil sysadmin. Ballots should be public IMO, secret voting is cowardice. That way duplicate ballots are easily filtered out ex-post and scrutable to all. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@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 2/6] libavformat/sdp: remove whitespaces in fmtp
tis 2023-11-07 klockan 15:12 +0100 skrev Michael Riedl: > Whitespaces after semicolon breaks some servers Which servers? If the spec allows whitespace then the onus is on them to fix their implementations. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@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 0/6] WebRTC sub-second live streaming support
tis 2023-11-14 klockan 13:59 +0100 skrev Michael Riedl: > Another option is an external project for WebRTC testing, but the > challenge is > keeping it maintained and compatible with changes in implementations. Perhaps there are funds to raise for such an effort? I can imagine Google et al have an interest in this. > External services might update their software, causing issues with > tests. We > would need a plan for dealing with that. Just making sure various free software implementations interoperate would be more than enough work, and provides some confidence. Surveying what features are supported by each implementation would also be of interest I imagine. For example a client of mine uses aiortc which is lacking FEC and rate control. A local company that sometimes contributes to FFmpeg is also involved in various streaming stuff (though not WebRTC so far, I think). > For paid services like Millicast, we need to figure out who pays for > the tests. > Understanding the costs is essential if we want to use paid services > for > testing. > > I'd like to hear your thoughts on these points and how you would > propose to > proceed with adding tests for protocols like WebRTC. The way I've been testing this stuff so far is by hand via Firefox and Chromium. Both can be automated, though frontend isn't really my area. As it stands at the moment, we let users be guinea pigs for our protocols. While not great, this at least means we get bug reports. But there's no way to ensure old bugs don't resurface. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@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/codecpar: mention how to allocate coded_side_data
On 11/13/2023 1:29 PM, James Almer wrote:
Signed-off-by: James Almer
---
libavcodec/codec_par.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/codec_par.h b/libavcodec/codec_par.h
index 64882a9726..f42dd3b1d5 100644
--- a/libavcodec/codec_par.h
+++ b/libavcodec/codec_par.h
@@ -219,6 +219,9 @@ typedef struct AVCodecParameters {
/**
* Additional data associated with the entire stream.
+ *
+ * Should be allocated with av_packet_side_data_new() or
+ * av_packet_side_data_add(), and will be freed by
avcodec_parameters_free().
*/
AVPacketSideData *coded_side_data;
Will apply.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/hevcdec: don't store stale HDR10+ values
This metadata is signaled per frame. If not present in an AU, then the previous
values should not be used.
Should fix ticket #10541.
Signed-off-by: James Almer
---
libavcodec/hevcdec.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 3ce845dddb..13c37e1e3b 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2805,14 +2805,12 @@ static int set_side_data(HEVCContext *s)
}
if (s->sei.common.dynamic_hdr_plus.info) {
-AVBufferRef *info_ref =
av_buffer_ref(s->sei.common.dynamic_hdr_plus.info);
-if (!info_ref)
-return AVERROR(ENOMEM);
-
-if (!av_frame_new_side_data_from_buf(out,
AV_FRAME_DATA_DYNAMIC_HDR_PLUS, info_ref)) {
-av_buffer_unref(_ref);
+if (!av_frame_new_side_data_from_buf(out,
AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
+
s->sei.common.dynamic_hdr_plus.info)) {
+av_buffer_unref(>sei.common.dynamic_hdr_plus.info);
return AVERROR(ENOMEM);
}
+s->sei.common.dynamic_hdr_plus.info = NULL;
}
if (s->rpu_buf) {
--
2.42.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".
[FFmpeg-devel] [PATCH] swscale/x86/rgb_2_rgb: Add opaque pointer to missed definitions of ff_nv12ToUV
Opaque parameters were previously added to the original definition of
ff_nv12ToUV, leading to gcc noticing a type mismatch with -Wlto-type-mismatch.
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/f2de911818fbd7e73343803626b697fd0c968121
https://bugs.gentoo.org/907484
Signed-off-by: Alfred Wingate
---
libswscale/x86/rgb2rgb_template.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libswscale/x86/rgb2rgb_template.c
b/libswscale/x86/rgb2rgb_template.c
index 4aba25dd51..edbacea784 100644
--- a/libswscale/x86/rgb2rgb_template.c
+++ b/libswscale/x86/rgb2rgb_template.c
@@ -1823,7 +1823,8 @@ void RENAME(ff_nv12ToUV)(uint8_t *dstU, uint8_t *dstV,
const uint8_t *src1,
const uint8_t *src2,
int w,
- uint32_t *unused2);
+ uint32_t *unused2,
+ void *opq);
static void RENAME(deinterleaveBytes)(const uint8_t *src, uint8_t *dst1,
uint8_t *dst2,
int width, int height, int srcStride,
int dst1Stride, int dst2Stride)
@@ -1831,7 +1832,7 @@ static void RENAME(deinterleaveBytes)(const uint8_t *src,
uint8_t *dst1, uint8_t
int h;
for (h = 0; h < height; h++) {
-RENAME(ff_nv12ToUV)(dst1, dst2, NULL, src, NULL, width, NULL);
+RENAME(ff_nv12ToUV)(dst1, dst2, NULL, src, NULL, width, NULL, NULL);
src += srcStride;
dst1 += dst1Stride;
dst2 += dst2Stride;
--
2.42.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 2/3] swscale/utils: correctly return from sws_init_single_context
On Mon, 13 Nov 2023 19:30:08 +0100 Michael Niedermayer wrote: > but i dont feel like i fully understand the issue here so maybe iam missing > the goal of this patchset somewhat So, to summarize the main problem: 1. sws_init_single_context() previously hard-coded decisions based on c->srcRange and c->dstRange. This is fundamentally broken, as srcRange/dstRange can change at any time with sws_setColorspaceDetails. 2. To fix this, this function was made to not early-return, and instead run the rest of the init code just in case range conversion is needed later. (With the check for whether or not the special converter can be used being moved to the callsite instead of the setup site) 3. This caused problems for non-YUV inputs, because previously these would always early return, but now they run the rest of the code, which triggers at least one assertion for float32 formats. 4. To fix this, this commit restores the early-return for non-YUV, preserving the status quo of existing behavior w.r.t not hitting the rest of the init function. 5. Separately, this commit fixes an error in previous condition (2) at the callsite, which relied on c->lumConvertRange being unset when no range conversion is needed. However, that condition did not match the condition used in the setup check before. > * convert_unscaled should only be set when used > OR > * if these are set "always" if not alphablend and convert_unscaled should be > two seperate fields. But i have not at all looked at what consequences that > would have so maybe that has issues convert_unscaled cannot be set only when used because we don't yet know if it will be used or not. There is also no advantage I see to splitting the fields, as they have basically the same logic attached to them - being dependent only on whether or not range conversion is needed. > Also if some range convert should not be used/set for some cases then > the check should maybe be where the range convert is setup not far away > from it. I mean a check close to the related code is easier to understand > One alternative that would make this possible would be to re-run whole context init from sws_setColorspaceDetails, if the srcRange/dstRange change. ___ ffmpeg-devel mailing list ffmpeg-devel@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 0/6] WebRTC sub-second live streaming support
On 11/14/23 11:05, Tomas Härdin wrote: > This patchset is missing tests. I know that we for some reason don't > really have tests for protocols, but I feel the issue is worthwhile to > bring up. I've worked a bit with WebRTC recently and it's fiddly, so > it'd be nice to have some automated thing that keeps track of which > WebRTC implementations this works with. Or maybe this is better handled > with an external project, testing which implementations interoperate? I agree that having automated tests would be useful for stability in the future. I tested the patchset with both SRS and Millicast, and it worked well. For automated testing, we could use FATE, but it needs an extra server with protection and someone to keep it updated. Testing with paid services like Millicast is tricky. Another option is an external project for WebRTC testing, but the challenge is keeping it maintained and compatible with changes in implementations. External services might update their software, causing issues with tests. We would need a plan for dealing with that. For paid services like Millicast, we need to figure out who pays for the tests. Understanding the costs is essential if we want to use paid services for testing. I'd like to hear your thoughts on these points and how you would propose to proceed with adding tests for protocols like WebRTC. ___ ffmpeg-devel mailing list ffmpeg-devel@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
Am 14.11.23 um 10:28 schrieb Tomas Härdin: lör 2023-11-11 klockan 10:42 +0100 skrev Jean-Baptiste Kempf: You have been told, now, several times, that a list of email is a collection of Private Information, according to a GDPR and that you are a process of this PI, and therefore liable to the law. Everyone with a copy of the git repository already has this information, and it has been willingly given by all contributors. Is further processing of already extant PI really not permissible according to the GDPR? Do we have to seek permission from all contributors to publish our git repositories containing PI that they have already given implicit permission to publish? +1 that it is no problem to reshare public information. A problem would arise if we connect this information with other information - new unknown information or an unknown link between the two. That said, this part strikes me as far more relevant wrt the GDPR: I patched the voting system to log all authorized voters in the future to prevent this situation in the future. The logfile before: Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 The logfile afterwards: Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 someth...@somewhere.com Sun Nov 5 11:04:32 2023 127.0.0.1 Sending mail to a voter for poll E_af2d343f39602862 somethinge...@somewhereelse.com The other outputs are unchanged. This does not break any privacy about the ballots - it is still unknown what ballots voted if at all neither what that ballot eventually voted for. This only adds the information which mail addresses are connected to the poll ID E_* (in other words, who was an authorized voter). -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@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 0/6] WebRTC sub-second live streaming support
This patchset is missing tests. I know that we for some reason don't really have tests for protocols, but I feel the issue is worthwhile to bring up. I've worked a bit with WebRTC recently and it's fiddly, so it'd be nice to have some automated thing that keeps track of which WebRTC implementations this works with. Or maybe this is better handled with an external project, testing which implementations interoperate? /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@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
lör 2023-11-11 klockan 10:42 +0100 skrev Jean-Baptiste Kempf: > > You have been told, now, several times, that a list of email is a > collection of Private Information, according to a GDPR and that you > are a process of this PI, and therefore liable to the law. Everyone with a copy of the git repository already has this information, and it has been willingly given by all contributors. Is further processing of already extant PI really not permissible according to the GDPR? Do we have to seek permission from all contributors to publish our git repositories containing PI that they have already given implicit permission to publish? That said, this part strikes me as far more relevant wrt the GDPR: > I patched the voting system to log all authorized voters in the > future to prevent this situation in the future. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
