[FFmpeg-devel] [PATCH v2] libavutil/hwcontext_{d3d11va, dxva2}: Support Y212/XV36 pixel format
From: Fei Wang
Use DXGI/D3DFMT 16bit pixel format to compatible with 12bit Y212/XV36
since there is no 12bit pixel defined in D3D11/D3D9.
Fix cmdline on Windows:
$ ffmpeg.exe -hwaccel qsv -init_hw_device qsv:hw,child_device_type=
{d3d11, dxva2} -i input_12bit.bin -f null -
Signed-off-by: Fei Wang
---
1. Add the same change to dxva2.
libavutil/hwcontext_d3d11va.c | 4
libavutil/hwcontext_dxva2.c | 4
2 files changed, 8 insertions(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 9d81effe5e..1a047ce57b 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -104,6 +104,10 @@ static const struct {
{ DXGI_FORMAT_P016, AV_PIX_FMT_P012 },
{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y216 },
{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV48 },
+// There is no 12bit pixel format defined in DXGI_FORMAT*, use 16bit to
compatible
+// with 12 bit AV_PIX_FMT* formats.
+{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y212 },
+{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV36 },
// Special opaque formats. The pix_fmt is merely a place holder, as the
// opaque format cannot be accessed directly.
{ DXGI_FORMAT_420_OPAQUE, AV_PIX_FMT_YUV420P },
diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index b6eb13439d..f697690e19 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -95,6 +95,10 @@ static const struct {
{ MKTAG('P', '0', '1', '6'), AV_PIX_FMT_P012 },
{ MKTAG('Y', '2', '1', '6'), AV_PIX_FMT_Y216 },
{ MKTAG('Y', '4', '1', '6'), AV_PIX_FMT_XV48 },
+// There is no 12bit pixel format defined in D3DFMT*, use 16bit to
compatible
+// with 12 bit AV_PIX_FMT* formats.
+{ MKTAG('Y', '2', '1', '6'), AV_PIX_FMT_Y212 },
+{ MKTAG('Y', '4', '1', '6'), AV_PIX_FMT_XV36 },
{ D3DFMT_P8, AV_PIX_FMT_PAL8 },
{ D3DFMT_A8R8G8B8, AV_PIX_FMT_BGRA },
};
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavutil/hwcontext_d3d11va: Support Y212/XV36 pixel format
On Thu, 2024-10-31 at 11:33 -0300, James Almer wrote:
> > On 10/31/2024 9:45 AM, fei.w.wang-at-intel@ffmpeg.org wrote:
> > > > From: Fei Wang
> > > >
> > > > Use DXGI 16bit pixel format to compatible with 12bit Y212/XV36
> > > > > > since
> > > > there is no 12bit pixel defined in D3D11.
> > > >
> > > > Fix cmdline on Windows:
> > > >
> > > > $ ffmpeg.exe -hwaccel qsv -i input_12bit.bin -f null -
> > > >
> > > > Signed-off-by: Fei Wang
> > > > ---
> > > > libavutil/hwcontext_d3d11va.c | 4
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/libavutil/hwcontext_d3d11va.c > >
> > > > b/libavutil/hwcontext_d3d11va.c
> > > > index 9d81effe5e..2cde44af8e 100644
> > > > --- a/libavutil/hwcontext_d3d11va.c
> > > > +++ b/libavutil/hwcontext_d3d11va.c
> > > > @@ -104,6 +104,10 @@ static const struct {
> > > > { DXGI_FORMAT_P016, AV_PIX_FMT_P012 },
> > > > { DXGI_FORMAT_Y216, AV_PIX_FMT_Y216 },
> > > > { DXGI_FORMAT_Y416, AV_PIX_FMT_XV48 },
> > > > + // There is no 12bit pixel format defined in D3D11, use
> > > > 16bit > > to compatible
> > > > + // with 12 bit AV_PIX_FMT* formats.
> > > > + { DXGI_FORMAT_Y216, AV_PIX_FMT_Y212 },
> > > > + { DXGI_FORMAT_Y416, AV_PIX_FMT_XV36 },
> >
> > Should the same be added to dxva2?
Yes, it should be. Added in V2.
Thanks
Fei
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@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] [FFmpeg-cvslog] fate/vvc: Add a sample which lose frames before 5c66a3
On 03/11/2024 03:37, Zhao Zhili wrote:>> -Original Message- >> From: Frank Plowman >> Sent: 2024年11月3日 2:03 >> To: Nuo Mi ; Zhao Zhili ; Michael Niedermayer >> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fate/vvc: Add a sample which lose frames before 5c66a3 >> >> Hi, >> >> No, it doesn't seem so. I tried decoding the file with combinations of: >> >> * Reverting 5c66a3ab51807b0f471822ae261dd6b09030a439 >> * My AV_CEIL_RSHIFT patch >> * My subpicture validation patch >> * Your fuzz fixes >> >> and only those combinations where I did not revert 5c66a3a worked, so it >> seems that is the correct fix. > > You mean AV_CEIL_RSHIFT patch, subpicture validation patch and fuzz patch > together fixed the issue? No sorry, I mean the only change which has any effect on the issue appears to be yours. If 5c66a3a is reverted, the sample breaks and if it is not reverted then the sample works. The other patch(set)s do not appear to have any effect on this particular issue. > >> I do not have an x86-32 machine >> available to test the issue, but 5c66a3a seems to work fine on x86-64 >> and AArch64. > > It's easy to build a x86-32 version of ffmpeg on x86-64. For example, after > install gcc-multilib g++-multilib, configure with > ./configure --arch=x86 --extra-cflags="-m32" --extra-ldflags="-m32" > Thank you for this. Here are some further findings related to the issue which may be of interest: * The test only fails when FFmpeg is compiled with GCC and not when FFmpeg is compiled with Clang. * The test produces an AddressSanitizer error: = ==18690==ERROR: AddressSanitizer: stack-use-after-return on address 0xea8cd0ae at pc 0x08497395 bp 0xecc9a658 sp 0xecc9a64c READ of size 1 at 0xea8cd0ae thread T3 (dec0:0:vvc) #0 0x8497394 in prepare_intra_edge_params_8 libavcodec/vvc/intra_template.c:570 #1 0x8497394 in intra_pred_8 libavcodec/vvc/intra_template.c:627 #2 0x85506e7 in predict_intra libavcodec/vvc/intra.c:259 #3 0x85506e7 in reconstruct libavcodec/vvc/intra.c:578 #4 0x85506e7 in ff_vvc_reconstruct libavcodec/vvc/intra.c:682 #5 0x84f6ed8 in run_recon libavcodec/vvc/thread.c:518 #6 0x84fe6c6 in task_run_stage libavcodec/vvc/thread.c:648 #7 0x84fe6c6 in task_run libavcodec/vvc/thread.c:675 #8 0x8504f62 in run_one_task libavcodec/executor.c:103 #9 0x8504f62 in ff_executor_execute libavcodec/executor.c:229 #10 0x84f7dd6 in add_task libavcodec/vvc/thread.c:129 #11 0x84f7dd6 in frame_thread_add_score libavcodec/vvc/thread.c:230 #12 0x8500e7b in ff_vvc_frame_submit libavcodec/vvc/thread.c:825 #13 0x842a17c in submit_frame libavcodec/vvc/dec.c:1007 #14 0x842a17c in vvc_decode_frame libavcodec/vvc/dec.c:1070 #15 0x83e5cee in decode_simple_internal libavcodec/decode.c:443 #16 0x83e5cee in decode_simple_receive_frame libavcodec/decode.c:613 #17 0x83e5cee in ff_decode_receive_frame_internal libavcodec/decode.c:649 #18 0x83e72cd in decode_receive_frame_internal libavcodec/decode.c:666 #19 0x83e83a7 in avcodec_send_packet libavcodec/decode.c:753 #20 0x807c2cc in packet_decode fftools/ffmpeg_dec.c:724 #21 0x807c2cc in decoder_thread fftools/ffmpeg_dec.c:953 #22 0x80f5a25 in task_wrapper fftools/ffmpeg_sched.c:2544 #23 0xf67199bd in asan_thread_start(void*) (/nix/store/f2hj98sdr409g70wibawhsq4hmv6pxx7-gcc-13.2.0-lib/lib/libasan.so.8+0x419bd) #24 0xf6291b46 in start_thread (/nix/store/9rr99432z1cmxk6m81i8qi6g8h8rcr8x-glibc-multi-2.39-5/lib/32/libc.so.6+0x8ab46) (BuildId: a24160f576613cfe4a2f5da8344c83a3882052be) #25 0xf6325d57 in __GI___clone3 (/nix/store/9rr99432z1cmxk6m81i8qi6g8h8rcr8x-glibc-multi-2.39-5/lib/32/libc.so.6+0x11ed57) (BuildId: a24160f576613cfe4a2f5da8344c83a3882052be) Address 0xea8cd0ae is located in stack of thread T3 (dec0:0:vvc) at offset 174 in frame #0 0x8576b4f in abs_get_rice_param libavcodec/vvc/cabac.c:1845 This frame has 1 object(s): [32, 160) 'rice_params' (line 1848) <== Memory access at offset 174 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) Thread T3 (dec0:0:vvc) created by T0 here: #0 0xf67198c4 in pthread_create (/nix/store/f2hj98sdr409g70wibawhsq4hmv6pxx7-gcc-13.2.0-lib/lib/libasan.so.8+0x418c4) #1 0x80f0672 in task_start fftools/ffmpeg_sched.c:422 SUMMARY: AddressSanitizer: stack-use-after-return libavcodec/vvc/intra_template.c:570 in prepare_intra_edge_params_8 Shadow bytes around the buggy address: 0xea8cce00: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 0xea8cce80: f5 f5 f5 f5 f5 f5 f5 f5 00 00 00 00 00 00 00 00 0xea8ccf00: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 0xea8ccf80: f5 f5 f5 f5 f5 f5 f5 f5 00 00 00 00 00 00 00 00 0xea8cd000: f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 f5 =>0xea8cd080: f5 f5 f5 f5 f5[f5]f5 f5 00 00 00 00 00 00 00 0
[FFmpeg-devel] [PATCH 1/5] avformat/rpl: check channels
Fixes: 42537199/clusterfuzz-testcase-minimized-fuzzer_loadfile_direct-5447162658357248 Fixes: runtime error: signed integer overflow: -3330498059201358222 * 4 cannot be represented in type 'int64_t' (aka 'long') Found-by: ossfuzz Reported-by: Kacper Michajlow Signed-off-by: Michael Niedermayer --- libavformat/rpl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/rpl.c b/libavformat/rpl.c index 32a762b60a9..e971d0588f3 100644 --- a/libavformat/rpl.c +++ b/libavformat/rpl.c @@ -205,6 +205,8 @@ static int rpl_read_header(AVFormatContext *s) if (ast->codecpar->sample_rate < 0) return AVERROR_INVALIDDATA; channels = read_line_and_int(pb, &error); // number of audio channels +if (channels <= 0) +return AVERROR_INVALIDDATA; error |= read_line(pb, line, sizeof(line)); ast->codecpar->bits_per_coded_sample = read_int(line, &endptr, &error); // audio bits per sample av_strlcpy(audio_type, endptr, RPL_LINE_LENGTH); -- 2.47.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/5] avformat/mccdec: Initialize and check rate.den
Fixes: Assertion c > 0 failed at libavutil/mathematics.c:61
Fixes: use-of-uninitialized-value
Fixes:
42537627/clusterfuzz-testcase-minimized-fuzzer_protocol_memory-5939605805793280
Found-by: ossfuzz
Reported-by: Kacper Michajlow
Signed-off-by: Michael Niedermayer
---
libavformat/mccdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/mccdec.c b/libavformat/mccdec.c
index 85bf93cd3b1..8c0ea09b6be 100644
--- a/libavformat/mccdec.c
+++ b/libavformat/mccdec.c
@@ -93,7 +93,7 @@ static int mcc_read_header(AVFormatContext *s)
{
MCCContext *mcc = s->priv_data;
AVStream *st = avformat_new_stream(s, NULL);
-AVRational rate;
+AVRational rate = {0};
int64_t ts, pos;
uint8_t out[4096];
char line[4096];
@@ -139,7 +139,7 @@ static int mcc_read_header(AVFormatContext *s)
continue;
}
-if (av_sscanf(line, "%d:%d:%d:%d", &hh, &mm, &ss, &fs) != 4)
+if (av_sscanf(line, "%d:%d:%d:%d", &hh, &mm, &ss, &fs) != 4 ||
rate.den <= 0)
continue;
ts = av_sat_add64(av_rescale(hh * 3600LL + mm * 60LL + ss, rate.num,
rate.den), fs);
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/5] avformat/vividas: Check avio_read() for failure
Fixes: use of uninitialized value (untested) Fixes: 42537627/clusterfuzz-testcase-minimized-fuzzer_loadfile_direct-5505802505355264 Found-by: ossfuzz Reported-by: Kacper Michajlow Signed-off-by: Michael Niedermayer --- libavformat/vividas.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/vividas.c b/libavformat/vividas.c index 130b81ebbe1..bec4ad7cec0 100644 --- a/libavformat/vividas.c +++ b/libavformat/vividas.c @@ -567,7 +567,8 @@ static int viv_read_header(AVFormatContext *s) v = avio_r8(pb); avio_seek(pb, v, SEEK_CUR); -avio_read(pb, keybuffer, 187); +if (avio_read(pb, keybuffer, 187) != 187) +return AVERROR_INVALIDDATA; key = decode_key(keybuffer); viv->sb_key = key; -- 2.47.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/5] avformat/nistspheredec: Clear buffer
Fixes: use-of-uninitialized-value
Fixes:
42537627/clusterfuzz-testcase-minimized-fuzzer_protocol_memory-6515855798632448-cut
Found-by: ossfuzz
Reported-by: Kacper Michajlow
Signed-off-by: Michael Niedermayer
---
libavformat/nistspheredec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/nistspheredec.c b/libavformat/nistspheredec.c
index 1e6c567e011..e6240361490 100644
--- a/libavformat/nistspheredec.c
+++ b/libavformat/nistspheredec.c
@@ -35,7 +35,7 @@ static int nist_probe(const AVProbeData *p)
static int nist_read_header(AVFormatContext *s)
{
-char buffer[256], coding[32] = "pcm", format[32] = "01";
+char buffer[256]= {0}, coding[32] = "pcm", format[32] = "01";
int bps = 0, be = 0;
int32_t header_size = -1;
AVStream *st;
--
2.47.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/5] avformat/ilbc: Check avio_read() for failure
Fixes: use of uninitialized value Fixes: 42537627/clusterfuzz-testcase-minimized-fuzzer_protocol_memory-6656646223298560-cut Found-by: ossfuzz Reported-by: Kacper Michajlow Signed-off-by: Michael Niedermayer --- libavformat/ilbc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/ilbc.c b/libavformat/ilbc.c index a24aa3da9d3..6c441c21bf1 100644 --- a/libavformat/ilbc.c +++ b/libavformat/ilbc.c @@ -61,7 +61,8 @@ static int ilbc_read_header(AVFormatContext *s) AVStream *st; uint8_t header[9]; -avio_read(pb, header, 9); +if (avio_read(pb, header, 9) != 9) +return AVERROR_INVALIDDATA; st = avformat_new_stream(s, NULL); if (!st) -- 2.47.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Add support for LJ92 compressed MLV files, attempt 02
Hi all - what do I need to do to progress this? I'm not sure, but it sounds like Tomas thought patch 1 might need someone with experience with Bayer taking a look. Thanks On Wed, 30 Oct 2024 at 04:27, South East <8billion.peo...@gmail.com> wrote: > > Thanks for taking a look! > > On Tue, 29 Oct 2024 at 15:25, Tomas Härdin wrote: > > > -#define MLV_CLASS_FLAG_DELTA 0x40 > > > #define MLV_CLASS_FLAG_LZMA 0x80 > > > +#define MLV_CLASS_FLAG_DELTA 0x40 > > > +#define MLV_CLASS_FLAG_LJ92 0x20 > > > > This hunk could be simpler if you didn't move MLV_CLASS_FLAG_DELTA > > This preserves the order of flags in the code that creates MLV files: > https://github.com/reticulatedpines/magiclantern_simplified/blob/f7a1df28c52eb7e1725b078a5fd2c4dedb3bac85/modules/raw_video/mlv_rec/mlv.h#L32 > I don't care a large amount, and can change it, but being consistent > has some value. > > > Not sure how Bayer in JPEG works so can't really comment more on patch > > 1. > > I don't know how Bayer in JPEG works either. I'm not sure if you mean > the file format, or the data compression standards. While MLV can use LJ92 > compression applied to Bayer data, there are no JPEG files involved. > > The existing mjpeg LJ92 support, that I'm building on, came from this work: > https://velocityra.github.io/gsoc-2019/ > > > Patch 2 looks simple enough. > > Good, I was hoping that one would be. ___ ffmpeg-devel mailing list ffmpeg-devel@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] avformat/icodec: fix integer overflow with nb_pal
Fixes: runtime error: signed integer overflow Fixes: 42536949/clusterfuzz-testcase-minimized-fuzzer_loadfile-6199846684393472 Found-by: ossfuzz Reported-by: Kacper Michajlow Tested-by: Kacper Michajlow Signed-off-by: Michael Niedermayer --- libavformat/icodec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/icodec.c b/libavformat/icodec.c index afd0c71b1f9..b09d0060a65 100644 --- a/libavformat/icodec.c +++ b/libavformat/icodec.c @@ -198,7 +198,7 @@ static int read_packet(AVFormatContext *s, AVPacket *pkt) AV_WL32(buf + 32, image->nb_pal); } -if (image->nb_pal > INT_MAX / 4 - 14 - 40) +if (image->nb_pal > INT_MAX / 4 - 14 - 40U) return AVERROR_INVALIDDATA; AV_WL32(buf - 4, 14 + 40 + image->nb_pal * 4); -- 2.47.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] INSTALL: explain the circular dependency issue and solution
On Sat, Nov 02, 2024 at 02:45:39PM -0300, James Almer wrote: > On 11/2/2024 2:24 PM, Michael Niedermayer wrote: > > Signed-off-by: Michael Niedermayer > > --- > > INSTALL.md | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/INSTALL.md b/INSTALL.md > > index 3b220bc6ff2..4398ca12fa1 100644 > > --- a/INSTALL.md > > +++ b/INSTALL.md > > @@ -15,3 +15,11 @@ NOTICE > > -- > >- Non system dependencies (e.g. libx264, libvpx) are disabled by default. > > + > > +NOTICE for Package Maintainers > > +-- > > + > > + - It is recommanded to build FFmpeg twice, first with minimal external > > depandancies so > > Recommended, dependencies (this one repeated below). > > > + that 3rd party packages, which depend on FFmpegs > > libavutil/libavfilter/libavcodec/libavformat > > + can then be build. And last build FFmpeg with full depandancies (which > > may in turn depen on > > "be built", depend. > > > + some of these 3rd party packages). This avoids circular depandancies > > during build. > > LGTM otherwise. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" 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/ffv1enc: Tighter maxsize
On Sun, Oct 27, 2024 at 12:46:17AM +0200, Michael Niedermayer wrote: > This allows using smaller buffers > > Sponsored-by: Sovereign Tech Fund > Signed-off-by: Michael Niedermayer > --- > libavcodec/ffv1enc.c | 17 + > 1 file changed, 13 insertions(+), 4 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. 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] root access voting
Hi Remi On Sun, Nov 03, 2024 at 08:56:36PM +0900, Rémi Denis-Courmont wrote: > Hi, > > Le 2 novembre 2024 20:34:30 GMT+09:00, Michael Niedermayer > a écrit : > >At teh current videolan developer days there where several surprise votes on > >FFmpegs > >infractructure. > > There were obviously no formal votes on anything since no GA meetings were > held. To be honest, you are being awfully misleading and disparaging of the > VDD (and it's not the first time) and its attendees, including a lot of > community members. The only information remotely made available was the page attached (iam not posting the link itself as iam not sure thats read only) and this contains multiple votes "Should we? 9 vs 3 vs 20 (yes, no, abstain)" "19 vs 0 vs 9 (yes, no, abstain)" I very strongly object to you calling me "misleading and disparagin" There was a meeting with no way to remotely participate and there where multiple votes in that meeting The attached text was the ONLY thing the members of the meeting published at the time If thats misleading, then the members of the meeting published misleading information [...] > >So let me try to reply to the idea of the general assembly choosing who has > >root access. > > The same argument was brought during the meeting. > > >We have seen a raise of increasingly sophisticated attacks in recent times. > >For example thx xz backdoor, where the maintainer was pressured by many > >people > >to add jia tan as maintainer who then eventually added a sophisticated hidden > >backdoor. Compromising xz and ssh. (Which almost was not even detected) > > > >We have seen batteries being exchanged by explosives by the mosad injuring > >members of a terrorist organization and probably a few innocent people. > >You may agree with fighting terror but do you agree with explosives, > >in maybe the phone someone of your familiy bought on ebay ? > > Comparing FFmpeg developers or their relatives with members of the Hezbollah > is not a very effective way to convey your point This is slander. I have never made such a comparission I pointed out that there are groups which perform supply chain attacks. And that the GA is vulnerable to it. These where simply examples of supply chain attacks ill reply to the rest of your mail seprately as it becomes too convoluted in one mail. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire vdd-ffmpeg-aawv _ Framapad mensuel-10:00.pdf Description: Adobe PDF document 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] root access voting
Hi, Le 2 novembre 2024 20:34:30 GMT+09:00, Michael Niedermayer a écrit : >At teh current videolan developer days there where several surprise votes on >FFmpegs >infractructure. There were obviously no formal votes on anything since no GA meetings were held. To be honest, you are being awfully misleading and disparaging of the VDD (and it's not the first time) and its attendees, including a lot of community members. > And to the best of my knowledge no remote participation >and no recording. Again, there were only informal discussions in the first place. You can't expect that other members of a community won't meet and hold face-to-face meetings, as Anton already pointed out beforehand. And FWIW notes were taken. Presumably you got the info from those notes... >So let me try to reply to the idea of the general assembly choosing who has >root access. The same argument was brought during the meeting. >We have seen a raise of increasingly sophisticated attacks in recent times. >For example thx xz backdoor, where the maintainer was pressured by many people >to add jia tan as maintainer who then eventually added a sophisticated hidden >backdoor. Compromising xz and ssh. (Which almost was not even detected) > >We have seen batteries being exchanged by explosives by the mosad injuring >members of a terrorist organization and probably a few innocent people. >You may agree with fighting terror but do you agree with explosives, >in maybe the phone someone of your familiy bought on ebay ? Comparing FFmpeg developers or their relatives with members of the Hezbollah is not a very effective way to convey your point >Our GA is build of everyone who has >"authored more than 20 patches in the last 36 months in the main FFmpeg >repository" Then have them designated by the TC and/or the CC. If even a sovereign state tries to take over the GA to take over the committees, we will notice and have plenty of time to expose it. If that doesn't work, we'll still have time to fork. Either way, that's way better than current state where effectively unknown or former mplayer (not even FFmpeg) developers are the admins, and single person fallible subjectivity (yours) decides who gets or doesn't to be admin. >Thats besides the root admins should generally be professional admins and not >"popular politicans". You have blocked Josh and Marvin, neither of whom strike me as popular politicians (sorry, no offence intended). They're not JB, Ronald or Kieran (again, no offence intended). >Also the root team has to get along with each other and trust each other, >obviously. How do you trust the ghost mplayer/FFmpeg people? How do you trust the Bulgarian hosting company? It doesn't help that Bulgaria is statistically the most corrupt country in the EU. Germany, Austria or Switzerland seem a lot more trustworthy places to host than Bulgaria. How do you even trust the physical access to hosting? Did you visit and see the servers? Otherwise your point about trusting admins is completely moot, plain and simple. >And last, where is that professional admin who wants to do work and who has >no root access ? Marvin? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] root access voting
Hi On Sun, Nov 03, 2024 at 08:56:36PM +0900, Rémi Denis-Courmont wrote: [...] > >Thats besides the root admins should generally be professional admins and not > >"popular politicans". > > You have blocked Josh and Marvin, neither of whom strike me as popular > politicians (sorry, no offence intended). They're not JB, Ronald or Kieran > (again, no offence intended). Thats not true in that way. Josh asked for admin access I asked if josh is a professional admin and what he does for a living. He did refuse to say what he does for a living. which is 100% his right but, for me raised a small red flag I asked some other people why josh is asking for root access, because it seemed a odd request. And was told that theres may be a connection to FFlabs I don t remember Marvin asking for root, maybe he did and i forgot, i do get a awfull lot of mail and a lot but less chat. Also i did not conciously know/remember Marvin is a professional admin. But given that this would be the 2nd request from a FFlabs member, it certainly is a little odd after i have already been told theres may be a connection to FFlabs And to be clear here, i have no problem with josh or marvin its the context, the lack of a clear reason why they want admin access and also the lack of a clear "iam a professional admin thats my day job" > > >Also the root team has to get along with each other and trust each other, > >obviously. > > How do you trust the ghost mplayer/FFmpeg people? How do you trust the > Bulgarian hosting company? It doesn't help that Bulgaria is statistically the > most corrupt country in the EU. seriously ? the mplayer developers who in some cases risked their job to protect the server and the company in Bulgaria gave us a free, and for our purposes powerfull and new server, free hosting, unlimited bandwidth IIRC and some admin in Bulgaria who had physical access if needed. noone else did make a comparable offer, i wanted a backup server, i wanted another box in case something went wrong with this. Something hosted in a different country different jurisdiction, different hosting company. For redundancy. For a short time i think we had one or 2 other offers but noone wants to provide a "backup" thats just sitting there unused until a disaster happens it seems I do take free things if they are offered instead of rejecteing them and paying for something else > > Germany, Austria or Switzerland seem a lot more trustworthy places to host > than Bulgaria. How do you even trust the physical access to hosting? Did you > visit and see the servers? Otherwise your point about trusting admins is > completely moot, plain and simple. I live in Austria, we have corruption here. with germany, i remember hetzner, just recently had police shutdown tons of illegal servers that said, i have no idea how one can even create a statistic for corruption or why it would even matter for us. > > >And last, where is that professional admin who wants to do work and who has > >no root access ? > > Marvin? marvin ? did you ask for root and i missed it ? if yes, are you a professional admin ? and why do you want/need root ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. 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".
