[FFmpeg-devel] [PATCH 6/6] avformat/mxfdec: Check body_offset
Fixes: signed integer overflow: 538976288 - -9223372036315799520 cannot be
represented in type 'long'
Fixes:
68060/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5523457266745344
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 233d614f783..e65cec74c23 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -791,6 +791,9 @@ static int mxf_read_partition_pack(void *arg, AVIOContext
*pb, int tag, int size
partition->index_sid = avio_rb32(pb);
partition->body_offset = avio_rb64(pb);
partition->body_sid = avio_rb32(pb);
+if (partition->body_offset < 0)
+return AVERROR_INVALIDDATA;
+
if (avio_read(pb, op, sizeof(UID)) != sizeof(UID)) {
av_log(mxf->fc, AV_LOG_ERROR, "Failed reading UID\n");
return AVERROR_INVALIDDATA;
--
2.43.2
___
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/wavarc: fix integer overflow in decode_5elp() block type 2
Fixes: signed integer overflow: 2097152000 + 107142979 cannot be represented in type 'int' Fixes: 67919/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-5955101769400320 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/wavarc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/wavarc.c b/libavcodec/wavarc.c index b4b26958e6f..93b76c43e8a 100644 --- a/libavcodec/wavarc.c +++ b/libavcodec/wavarc.c @@ -689,7 +689,7 @@ static int decode_5elp(AVCodecContext *avctx, for (int o = 0; o < order; o++) sum += s->filter[ch][o] * (unsigned)samples[n + 70 - o - 1]; -samples[n + 70] += ac_out[n] + (sum >> 4); +samples[n + 70] += ac_out[n] + (unsigned)(sum >> 4); } for (int n = 0; n < 70; n++) -- 2.43.2 ___ 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] avformat/iamfdec: Files without streams cannot have packets
Fixes: Assertion pkt->stream_index < (unsigned)s->nb_streams && "Invalid stream index.\n" failed at libavformat/demux.c:572 Fixes: 67890/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-5166340789829632.fuzz Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/iamfdec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/iamfdec.c b/libavformat/iamfdec.c index e34d13e74c5..67ff7e8f01a 100644 --- a/libavformat/iamfdec.c +++ b/libavformat/iamfdec.c @@ -162,6 +162,9 @@ static int iamf_read_packet(AVFormatContext *s, AVPacket *pkt) IAMFDemuxContext *const c = s->priv_data; int ret; +if (!s->nb_streams) +return AVERROR_EOF; + ret = ff_iamf_read_packet(s, c, s->pb, INT_MAX, pkt); if (ret < 0) return ret; -- 2.43.2 ___ 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] swscale/output: Fix integer overflow in yuv2rgba64_full_1_c_template()
Fixes: signed integer overflow: -1082982400 + -1079364728 cannot be represented
in type 'int'
Fixes: 67910/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-5329011971522560
The input is 9bit in 16bit, the fuzzer fills all 16bit thus generating
"invalid" input
No overflow should happen with valid input.
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libswscale/output.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libswscale/output.c b/libswscale/output.c
index 0b6c77e167d..b234f9c6b9a 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -1429,7 +1429,7 @@ yuv2rgba64_full_1_c_template(SwsContext *c, const int32_t
*buf0,
if (uvalpha < 2048) {
for (i = 0; i < dstW; i++) {
-int Y = (buf0[i]) >> 2;
+SUINT Y = (buf0[i]) >> 2;
int U = (ubuf0[i] - (128 << 11)) >> 2;
int V = (vbuf0[i] - (128 << 11)) >> 2;
int R, G, B;
@@ -1448,9 +1448,9 @@ yuv2rgba64_full_1_c_template(SwsContext *c, const int32_t
*buf0,
G = V * c->yuv2rgb_v2g_coeff + U * c->yuv2rgb_u2g_coeff;
B =U * c->yuv2rgb_u2b_coeff;
-output_pixel(&dest[0], av_clip_uintp2(((R_B + Y) >> 14) + (1<<15),
16));
-output_pixel(&dest[1], av_clip_uintp2((( G + Y) >> 14) + (1<<15),
16));
-output_pixel(&dest[2], av_clip_uintp2(((B_R + Y) >> 14) + (1<<15),
16));
+output_pixel(&dest[0], av_clip_uintp2(((int)(R_B + Y) >> 14) +
(1<<15), 16));
+output_pixel(&dest[1], av_clip_uintp2(((int)( G + Y) >> 14) +
(1<<15), 16));
+output_pixel(&dest[2], av_clip_uintp2(((int)(B_R + Y) >> 14) +
(1<<15), 16));
if (eightbytes) {
output_pixel(&dest[3], av_clip_uintp2(A, 30) >> 14);
dest += 4;
@@ -1462,7 +1462,7 @@ yuv2rgba64_full_1_c_template(SwsContext *c, const int32_t
*buf0,
const int32_t *ubuf1 = ubuf[1], *vbuf1 = vbuf[1];
int A = 0x<<14;
for (i = 0; i < dstW; i++) {
-int Y = (buf0[i]) >> 2;
+SUINT Y = (buf0[i]) >> 2;
int U = (ubuf0[i] + ubuf1[i] - (128 << 12)) >> 3;
int V = (vbuf0[i] + vbuf1[i] - (128 << 12)) >> 3;
int R, G, B;
@@ -1481,9 +1481,9 @@ yuv2rgba64_full_1_c_template(SwsContext *c, const int32_t
*buf0,
G = V * c->yuv2rgb_v2g_coeff + U * c->yuv2rgb_u2g_coeff;
B =U * c->yuv2rgb_u2b_coeff;
-output_pixel(&dest[0], av_clip_uintp2(((R_B + Y) >> 14) + (1<<15),
16));
-output_pixel(&dest[1], av_clip_uintp2((( G + Y) >> 14) + (1<<15),
16));
-output_pixel(&dest[2], av_clip_uintp2(((B_R + Y) >> 14) + (1<<15),
16));
+output_pixel(&dest[0], av_clip_uintp2(((int)(R_B + Y) >> 14) +
(1<<15), 16));
+output_pixel(&dest[1], av_clip_uintp2(((int)( G + Y) >> 14) +
(1<<15), 16));
+output_pixel(&dest[2], av_clip_uintp2(((int)(B_R + Y) >> 14) +
(1<<15), 16));
if (eightbytes) {
output_pixel(&dest[3], av_clip_uintp2(A, 30) >> 14);
dest += 4;
--
2.43.2
___
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] swscale/output: Fix integer overflow in yuv2rgba64_1_c_template
Fixes: signed integer overflow: -831176 * 9539 cannot be represented in type
'int'
Fixes: 67869/clusterfuzz-testcase-minimized-ffmpeg_SWS_fuzzer-5117342091640832
The input is 9bit in 16bit, the fuzzer fills all 16bit thus generating
"invalid" input
No overflow should happen with valid input.
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libswscale/output.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/libswscale/output.c b/libswscale/output.c
index 8849a3201a6..0b6c77e167d 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -1207,8 +1207,8 @@ yuv2rgba64_1_c_template(SwsContext *c, const int32_t
*buf0,
if (uvalpha < 2048) {
for (i = 0; i < ((dstW + 1) >> 1); i++) {
-int Y1 = (buf0[i * 2]) >> 2;
-int Y2 = (buf0[i * 2 + 1]) >> 2;
+SUINT Y1 = (buf0[i * 2]) >> 2;
+SUINT Y2 = (buf0[i * 2 + 1]) >> 2;
int U = (ubuf0[i] - (128 << 11)) >> 2;
int V = (vbuf0[i] - (128 << 11)) >> 2;
int R, G, B;
@@ -1232,20 +1232,20 @@ yuv2rgba64_1_c_template(SwsContext *c, const int32_t
*buf0,
G = V * c->yuv2rgb_v2g_coeff + U * c->yuv2rgb_u2g_coeff;
B =U * c->yuv2rgb_u2b_coeff;
-output_pixel(&dest[0], av_clip_uintp2(((R_B + Y1) >> 14) +
(1<<15), 16));
-output_pixel(&dest[1], av_clip_uintp2((( G + Y1) >> 14) +
(1<<15), 16));
-output_pixel(&dest[2], av_clip_uintp2(((B_R + Y1) >> 14) +
(1<<15), 16));
+output_pixel(&dest[0], av_clip_uintp2(((int)(R_B + Y1) >> 14) +
(1<<15), 16));
+output_pixel(&dest[1], av_clip_uintp2(((int)( G + Y1) >> 14) +
(1<<15), 16));
+output_pixel(&dest[2], av_clip_uintp2(((int)(B_R + Y1) >> 14) +
(1<<15), 16));
if (eightbytes) {
output_pixel(&dest[3], av_clip_uintp2(A1 , 30) >> 14);
-output_pixel(&dest[4], av_clip_uintp2(((R_B + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[5], av_clip_uintp2((( G + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[6], av_clip_uintp2(((B_R + Y2) >> 14) +
(1<<15), 16));
+output_pixel(&dest[4], av_clip_uintp2(((int)(R_B + Y2) >> 14)
+ (1<<15), 16));
+output_pixel(&dest[5], av_clip_uintp2(((int)( G + Y2) >> 14)
+ (1<<15), 16));
+output_pixel(&dest[6], av_clip_uintp2(((int)(B_R + Y2) >> 14)
+ (1<<15), 16));
output_pixel(&dest[7], av_clip_uintp2(A2 , 30) >> 14);
dest += 8;
} else {
-output_pixel(&dest[3], av_clip_uintp2(((R_B + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[4], av_clip_uintp2((( G + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[5], av_clip_uintp2(((B_R + Y2) >> 14) +
(1<<15), 16));
+output_pixel(&dest[3], av_clip_uintp2(((int)(R_B + Y2) >> 14)
+ (1<<15), 16));
+output_pixel(&dest[4], av_clip_uintp2(((int)( G + Y2) >> 14)
+ (1<<15), 16));
+output_pixel(&dest[5], av_clip_uintp2(((int)(B_R + Y2) >> 14)
+ (1<<15), 16));
dest += 6;
}
}
@@ -1253,8 +1253,8 @@ yuv2rgba64_1_c_template(SwsContext *c, const int32_t
*buf0,
const int32_t *ubuf1 = ubuf[1], *vbuf1 = vbuf[1];
int A1 = 0x<<14, A2 = 0x<<14;
for (i = 0; i < ((dstW + 1) >> 1); i++) {
-int Y1 = (buf0[i * 2]) >> 2;
-int Y2 = (buf0[i * 2 + 1]) >> 2;
+SUINT Y1 = (buf0[i * 2]) >> 2;
+SUINT Y2 = (buf0[i * 2 + 1]) >> 2;
int U = (ubuf0[i] + ubuf1[i] - (128 << 12)) >> 3;
int V = (vbuf0[i] + vbuf1[i] - (128 << 12)) >> 3;
int R, G, B;
@@ -1278,20 +1278,20 @@ yuv2rgba64_1_c_template(SwsContext *c, const int32_t
*buf0,
G = V * c->yuv2rgb_v2g_coeff + U * c->yuv2rgb_u2g_coeff;
B =U * c->yuv2rgb_u2b_coeff;
-output_pixel(&dest[0], av_clip_uintp2(((R_B + Y1) >> 14) +
(1<<15), 16));
-output_pixel(&dest[1], av_clip_uintp2((( G + Y1) >> 14) +
(1<<15), 16));
-output_pixel(&dest[2], av_clip_uintp2(((B_R + Y1) >> 14) +
(1<<15), 16));
+output_pixel(&dest[0], av_clip_uintp2(((int)(R_B + Y1) >> 14) +
(1<<15), 16));
+output_pixel(&dest[1], av_clip_uintp2(((int)( G + Y1) >> 14) +
(1<<15), 16));
+output_pixel(&dest[2], av_clip_uintp2(((int)(B_R + Y1) >> 14) +
(1<<15), 16));
if (eightbytes) {
output_pixel(&dest[3], av_clip_uintp2(A1 , 30) >> 14);
-output_pixel(&dest[4], av_clip_uintp2(((R_B + Y2) >> 14) +
(1<<15), 16));
-output_pixel(&dest[5], av_clip_uintp2((( G + Y2
[FFmpeg-devel] [PATCH 1/6] avformat/mov: Check tile_item_list
Fixes: Null pointer dereference Fixes: 67861/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5352628142800896 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/mov.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/mov.c b/libavformat/mov.c index ecd29a7d08b..97a24e6737e 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -9289,6 +9289,9 @@ static int read_image_grid(AVFormatContext *s, const HEIFGrid *grid, if (tile_grid->nb_tiles != size) return AVERROR_INVALIDDATA; +for (int i = 0; i < size; i++) +if (!grid->tile_item_list[i]) +return AVERROR_INVALIDDATA; for (int i = 0; i < tile_cols; i++) tile_grid->coded_width += grid->tile_item_list[i]->width; for (int i = 0; i < size; i += tile_cols) -- 2.43.2 ___ 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] [EXTERNAL] Request for Official GitHub Mirror of rtmpdump for Enhanced Security
Hi, Replies inline. On 4/26/2024 12:10 AM, Javier Matos Denizac via ffmpeg-devel wrote: > Actually, I noticed that you publish release tarballs -> > http://rtmpdump.mplayerhq.hu/download/, but I don’t see a release tarball for > 2.4. Would y’all be willing to publish a release for 2.4 and maybe mint and > publish a release tarball for 2.6? As far as I can tell, the rtmpdump author has, move away from tarballs and only uses git tags, now, as per https://rtmpdump.mplayerhq.hu/, which itself seems outdated. You may have better luck contacting its main contributor (Howard Chu), on rtmpdump's own mailing list (https://lists.mplayerhq.hu/mailman/listinfo/rtmpdump) or directly. FFmpeg only provides infrastructure for it, to my knowledge. > As for why SHA-512, we use SHA-512 checksums to verify the integrity of the > file and as an identifier for our asset caching mechanism. That way we can > identify if we have already downloaded the tarball and avoid downloading it > again. It was unclear you were talking about tarballs as you only referred to GitHub and the FFmpeg-run git server... That said, I am unsure why git is not considered secure / verifiable enough, compared to a tarball. I would actually argue the opposite is true for autogenerated tarballs like GitHub provides. - Derek ___ 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] [EXTERNAL] Request for Official GitHub Mirror of rtmpdump for Enhanced Security
Actually, I noticed that you publish release tarballs -> http://rtmpdump.mplayerhq.hu/download/, but I don’t see a release tarball for 2.4. Would y’all be willing to publish a release for 2.4 and maybe mint and publish a release tarball for 2.6? As for why SHA-512, we use SHA-512 checksums to verify the integrity of the file and as an identifier for our asset caching mechanism. That way we can identify if we have already downloaded the tarball and avoid downloading it again. - Javier On Apr 25, 2024, at 8:38 AM, Derek Buitenhuis wrote: [You don't often get email from derek.buitenh...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On 4/23/2024 10:46 PM, Michael Niedermayer wrote: Can you elaborate what the problem is ? I would have thought https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ffmpeg.org%2Frtmpdump.git&data=05%7C02%7Cjaviermat%40microsoft.com%7Cbbe1b884618b4d02416408dc6524b486%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638496455534699942%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Bz%2B00fGNCFNTtC24dDlwpDcwcsr87YPxRhusNhBsm5A%3D&reserved=0 is secure I have to assume he means SHA-256, and not SHA-512. git apparently supports using SHA-256 instead of SHA-1 hashes, but support does not seem to be very mainstream. I am not even sure GitHub supports it (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Forgs%2Fcommunity%2Fdiscussions%2F12490&data=05%7C02%7Cjaviermat%40microsoft.com%7Cbbe1b884618b4d02416408dc6524b486%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638496455534707598%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ywZOz2L6tmpAfk%2FoPnGgUlqjH441jGUMPh4TcVFN8KA%3D&reserved=0 seems to indicate not yet). So either this is vcpkg trying to be vey aggressive in requiring git features, or there is some clarification neeed. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel&data=05%7C02%7Cjaviermat%40microsoft.com%7Cbbe1b884618b4d02416408dc6524b486%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638496455534712191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=s6m5uKpOetHmePYbl%2BpSOCGGCk6GYoFU4A2cwk%2BpMzQ%3D&reserved=0 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".
[FFmpeg-devel] [PATCH] fix av_log format specifier
Signed-off-by: Marcus B Spencer
---
libavcodec/bsf/noise.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/bsf/noise.c b/libavcodec/bsf/noise.c
index a622855717..d36be5fab4 100644
--- a/libavcodec/bsf/noise.c
+++ b/libavcodec/bsf/noise.c
@@ -173,7 +173,7 @@ static int noise(AVBSFContext *ctx, AVPacket *pkt)
drop = !(s->state % s->dropamount);
}
-av_log(ctx, AV_LOG_VERBOSE, "Stream #%d packet %d pts %"PRId64" - amount
%d drop %d\n",
+av_log(ctx, AV_LOG_VERBOSE, "Stream #%d packet %u pts %"PRId64" - amount
%d drop %d\n",
pkt->stream_index, (unsigned int)s->var_values[VAR_N], pkt->pts,
amount, drop);
if (drop) {
--
2.44.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 v3 0/2] HTTP Retry-After Support
On Thu, 25 Apr 2024, Derek Buitenhuis wrote: Changes since last set: * Updated commit message with RFC references. * Properly support Retry-After as both a date and integer number of seconds. I have tested this against both an HTTP-Date and seconds, and confirmed it to work. Derek Buitenhuis (2): avformat/http: Rename parse_set_cookie_expiry_time to parse_http_date avformat/http: Add support for Retry-After header doc/protocols.texi| 5 libavformat/http.c| 62 ++- libavformat/version.h | 2 +- 3 files changed, 49 insertions(+), 20 deletions(-) Thanks, these patches LGTM. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Wed, Apr 24, 2024 at 3:00 PM Michael Niedermayer wrote: > > Microsoft expanded into new fields with Xbox and Azure, yes. But Windows > is still an OS, and Office is still a (un)productivity suite. > > > > Accordingly, maybe you can innovate with a new project within the same > legal entity as FFmpeg (be it SPI, FFlabs or whatever). > > > > But FFmpeg as a software project is not a suitable venue for radical new > innovation. > > Microsofts OS does not limit what can be installed to whats in MS main > repository, FFmpeg does > > Microsoft windows from a user POV includes internet explorer IIRC. Its not > a seperate > product from just the legal entity. It was not in the first OS from > microsoft > > microsofts first OS MS-DOS 1.0 ? looks slightly different than the current > latest OS. > There was radical innovation, if one likes MS or hate them. > > > > > > >You can do the same with apple, google, or others. > > > > Sure but you can't do the same with iPhone or Google Search. > > of course you can, googles search inovated. Theres a image search a audio > search > news, travel, shoping. > These did not exist in the initial google search. And while i dont know, i > suspect > google search is very good at finding google products. > Google didnt became that big by simply "not being evil" > > But lets not assume, lets try, if i search for maps i get > Google Maps as first entry. > > or finance, 2nd entry is https://www.google.com/finance/ > > > And the iphone uses apples operating system and their app store, with > many apple apps. Check the first iphone and compare it to the latest > there is huge inovation with what you can do with all the software > that comes preinstalled and also what you can install later. > Thats in stark contrast to > "FFmpeg as a software project is not a suitable venue for radical new > innovation" > when did you last use siri with your iphone ? siri was added in > iphone 4s IIUC. Thats a big change. > > I can ultimately only repeat my oppinion. FFmpeg will innovate or FFmpeg > will stagnate and eventually be replaced by some other project that doesnt > have an opposition to innovation. > > IMHO we need to find out what direction (of innovation or lack thereof) > people want. This RFC thread is kind of the first step. > 2nd step would be a vote. You are kinda comparing apples and oranges, a platform like an OS or a service like google Maps are different products than the software that runs them like FFmpeg. While for sure there can be innovation and radical new design ideas in our project, the space for innovation is limited by the intrinsic nature of the software, which is basically "multimedia in/multimedia out". In other words you cannot make something like a social network or a crypto exchange or a browser based on ffmpeg.exe, and not because it's impossible but because it's the wrong tool for the job - likewise you can't make internet explorer a good multimedia low level framework - there are other places to innovate with more freedom and fewer requirements. Most of the innovations I see the community ask for our project are mostly non-technical, aka switching to a more user friendly patch system, have stronger meaningful actions from the CC, and secure funding for larger projects. These are all hard to do, even more so when the leadership stalls any action out of fear of losing contributors. I hope we can find a good compromise in the upcoming months. -- 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".
[FFmpeg-devel] [PATCH] avformat/framecrcenc: allow setting which side data parameters are printed
For some side data types, the size is dependent on the arch at runtime, which
is not good for FATE tests.
Add an option to set which parameters may be printed, starting with size.
Signed-off-by: James Almer
---
libavformat/framecrcenc.c | 28
1 file changed, 28 insertions(+)
diff --git a/libavformat/framecrcenc.c b/libavformat/framecrcenc.c
index ce306a6c49..7d0e3978f2 100644
--- a/libavformat/framecrcenc.c
+++ b/libavformat/framecrcenc.c
@@ -23,6 +23,7 @@
#include "libavutil/adler32.h"
#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
#include "libavcodec/codec_id.h"
#include "libavcodec/codec_par.h"
@@ -32,6 +33,11 @@
#include "internal.h"
#include "mux.h"
+struct FrameCRCContext {
+const AVClass *avclass;
+int flags;
+};
+
static int framecrc_write_header(struct AVFormatContext *s)
{
int i;
@@ -48,8 +54,11 @@ static int framecrc_write_header(struct AVFormatContext *s)
return ff_framehash_write_header(s);
}
+#define SD_SIZE 1
+
static int framecrc_write_packet(struct AVFormatContext *s, AVPacket *pkt)
{
+struct FrameCRCContext *c = s->priv_data;
uint32_t crc = av_adler32_update(0, pkt->data, pkt->size);
char buf[256];
@@ -61,6 +70,7 @@ static int framecrc_write_packet(struct AVFormatContext *s,
AVPacket *pkt)
av_strlcatf(buf, sizeof(buf), ", S=%d", pkt->side_data_elems);
for (int i = 0; i < pkt->side_data_elems; i++) {
+if (c->flags & SD_SIZE)
av_strlcatf(buf, sizeof(buf), ", %8"SIZE_SPECIFIER,
pkt->side_data[i].size);
}
@@ -70,11 +80,29 @@ static int framecrc_write_packet(struct AVFormatContext *s,
AVPacket *pkt)
return 0;
}
+#define OFFSET(x) offsetof(struct FrameCRCContext, x)
+#define ENC AV_OPT_FLAG_ENCODING_PARAM
+static const AVOption framecrc_options[] = {
+{ "print_side_data", "set which side data parameters to print",
OFFSET(flags),
+AV_OPT_TYPE_FLAGS, { .i64 = SD_SIZE }, INT_MIN, INT_MAX, ENC, .unit =
"flags"},
+{ "size", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = SD_SIZE }, INT_MIN,
INT_MAX, ENC, .unit = "flags"},
+{ NULL },
+};
+
+static const AVClass framecrc_class = {
+.class_name = "framecrc muxer",
+.item_name = av_default_item_name,
+.option = framecrc_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
const FFOutputFormat ff_framecrc_muxer = {
.p.name= "framecrc",
.p.long_name = NULL_IF_CONFIG_SMALL("framecrc testing"),
+.p.priv_class = &framecrc_class,
.p.audio_codec = AV_CODEC_ID_PCM_S16LE,
.p.video_codec = AV_CODEC_ID_RAWVIDEO,
+.priv_data_size= sizeof(struct FrameCRCContext),
.write_header = framecrc_write_header,
.write_packet = framecrc_write_packet,
.p.flags = AVFMT_VARIABLE_FPS | AVFMT_TS_NONSTRICT |
--
2.44.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 v3 2/2] avformat/http: Add support for Retry-After header
429 and 503 codes can, and often do (e.g. all Google Cloud
Storage URLs can), return a Retry-After header with the error,
indicating how long to wait, asd either a date, or in seconds,
before retrying again. If it is not respected by, for example,
using our default backoff stratetgy instead, chances of success
are very unlikely.
Some references:
* https://datatracker.ietf.org/doc/html/rfc6585
* https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.3
This adds an AVOption to respect that header.
Signed-off-by: Derek Buitenhuis
---
doc/protocols.texi| 5 +
libavformat/http.c| 24
libavformat/version.h | 2 +-
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 571d78ec43..ed70af4b33 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -569,6 +569,11 @@ Set the maximum number of times to retry a connection.
Default unset.
@item reconnect_delay_total_max
Set the maximum total delay in seconds after which to give up reconnecting.
+@item respect_retry_after
+If enabled, and a Retry-After header is encountered, its requested reconnection
+delay will be honored, rather than using exponential backoff. Useful for 429
and
+503 errors. Default enabled.
+
@item listen
If set to 1 enables experimental HTTP server. This can be used to send data
when
used as an output option, or read data from a client with HTTP POST when used
as
diff --git a/libavformat/http.c b/libavformat/http.c
index d324674e97..1a67068a44 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -31,6 +31,7 @@
#include "libavutil/avstring.h"
#include "libavutil/bprint.h"
#include "libavutil/getenv_utf8.h"
+#include "libavutil/macros.h"
#include "libavutil/mem.h"
#include "libavutil/opt.h"
#include "libavutil/time.h"
@@ -138,6 +139,8 @@ typedef struct HTTPContext {
char *new_location;
AVDictionary *redirect_cache;
uint64_t filesize_from_content_range;
+int respect_retry_after;
+unsigned int retry_after;
int reconnect_max_retries;
int reconnect_delay_total_max;
} HTTPContext;
@@ -180,6 +183,7 @@ static const AVOption options[] = {
{ "reconnect_delay_max", "max reconnect delay in seconds after which to
give up", OFFSET(reconnect_delay_max), AV_OPT_TYPE_INT, { .i64 = 120 }, 0,
UINT_MAX/1000/1000, D },
{ "reconnect_max_retries", "the max number of times to retry a
connection", OFFSET(reconnect_max_retries), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
INT_MAX, D },
{ "reconnect_delay_total_max", "max total reconnect delay in seconds after
which to give up", OFFSET(reconnect_delay_total_max), AV_OPT_TYPE_INT, { .i64 =
256 }, 0, UINT_MAX/1000/1000, D },
+{ "respect_retry_after", "respect the Retry-After header when retrying
connections", OFFSET(respect_retry_after), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0,
1, D },
{ "listen", "listen on HTTP", OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 0
}, 0, 2, D | E },
{ "resource", "The resource requested by a client", OFFSET(resource),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, E },
{ "reply_code", "The http status code to return to a client",
OFFSET(reply_code), AV_OPT_TYPE_INT, { .i64 = 200}, INT_MIN, 599, E},
@@ -393,6 +397,14 @@ redo:
reconnect_delay_total > s->reconnect_delay_total_max)
goto fail;
+/* Both fields here are in seconds. */
+if (s->respect_retry_after && s->retry_after > 0) {
+reconnect_delay = s->retry_after;
+if (reconnect_delay > s->reconnect_delay_max)
+goto fail;
+s->retry_after = 0;
+}
+
av_log(h, AV_LOG_WARNING, "Will reconnect at %"PRIu64" in %d
second(s).\n", off, reconnect_delay);
ret = ff_network_sleep_interruptible(1000U * 1000 * reconnect_delay,
&h->interrupt_callback);
if (ret != AVERROR(ETIMEDOUT))
@@ -1241,6 +1253,18 @@ static int process_line(URLContext *h, char *line, int
line_count, int *parsed_h
parse_expires(s, p);
} else if (!av_strcasecmp(tag, "Cache-Control")) {
parse_cache_control(s, p);
+} else if (!av_strcasecmp(tag, "Retry-After")) {
+/* The header can be either an integer that represents seconds, or
a date. */
+struct tm tm;
+int date_ret = parse_http_date(p, &tm);
+if (!date_ret) {
+time_t retry = av_timegm(&tm);
+int64_t now= av_gettime() / 100;
+int64_t diff = ((int64_t) retry) - now;
+s->retry_after = (unsigned int) FFMAX(0, diff);
+} else {
+s->retry_after = strtoul(p, NULL, 10);
+}
}
}
return 1;
diff --git a/libavformat/version.h b/libavformat/version.h
index 41dbd4ad01..5310326bda 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
#include "version_major.h"
#define LIBAVFORMAT_VER
[FFmpeg-devel] [PATCH v3 1/2] avformat/http: Rename parse_set_cookie_expiry_time to parse_http_date
That is what it actually does, and it will be needed for more
than the Expiry header soon.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index eecc4fd357..d324674e97 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -56,7 +56,7 @@
#define MAX_CACHED_REDIRECTS 32
#define HTTP_SINGLE 1
#define HTTP_MUTLI2
-#define MAX_EXPIRY19
+#define MAX_DATE_LEN 19
#define WHITESPACES " \n\t\r"
typedef enum {
LOWER_PROTO,
@@ -913,29 +913,29 @@ static int parse_icy(HTTPContext *s, const char *tag,
const char *p)
return 0;
}
-static int parse_set_cookie_expiry_time(const char *exp_str, struct tm *buf)
+static int parse_http_date(const char *date_str, struct tm *buf)
{
-char exp_buf[MAX_EXPIRY];
-int i, j, exp_buf_len = MAX_EXPIRY-1;
-char *expiry;
+char date_buf[MAX_DATE_LEN];
+int i, j, date_buf_len = MAX_DATE_LEN-1;
+char *date;
// strip off any punctuation or whitespace
-for (i = 0, j = 0; exp_str[i] != '\0' && j < exp_buf_len; i++) {
-if ((exp_str[i] >= '0' && exp_str[i] <= '9') ||
-(exp_str[i] >= 'A' && exp_str[i] <= 'Z') ||
-(exp_str[i] >= 'a' && exp_str[i] <= 'z')) {
-exp_buf[j] = exp_str[i];
+for (i = 0, j = 0; date_str[i] != '\0' && j < date_buf_len; i++) {
+if ((date_str[i] >= '0' && date_str[i] <= '9') ||
+(date_str[i] >= 'A' && date_str[i] <= 'Z') ||
+(date_str[i] >= 'a' && date_str[i] <= 'z')) {
+date_buf[j] = date_str[i];
j++;
}
}
-exp_buf[j] = '\0';
-expiry = exp_buf;
+date_buf[j] = '\0';
+date = date_buf;
// move the string beyond the day of week
-while ((*expiry < '0' || *expiry > '9') && *expiry != '\0')
-expiry++;
+while ((*date < '0' || *date > '9') && *date != '\0')
+date++;
-return av_small_strptime(expiry, "%d%b%Y%H%M%S", buf) ? 0 :
AVERROR(EINVAL);
+return av_small_strptime(date, "%d%b%Y%H%M%S", buf) ? 0 : AVERROR(EINVAL);
}
static int parse_set_cookie(const char *set_cookie, AVDictionary **dict)
@@ -995,7 +995,7 @@ static int parse_cookie(HTTPContext *s, const char *p,
AVDictionary **cookies)
// ensure the cookie is not expired or older than an existing value
if ((e = av_dict_get(new_params, "expires", NULL, 0)) && e->value) {
struct tm new_tm = {0};
-if (!parse_set_cookie_expiry_time(e->value, &new_tm)) {
+if (!parse_http_date(e->value, &new_tm)) {
AVDictionaryEntry *e2;
// if the cookie has already expired ignore it
@@ -1012,7 +1012,7 @@ static int parse_cookie(HTTPContext *s, const char *p,
AVDictionary **cookies)
e2 = av_dict_get(old_params, "expires", NULL, 0);
if (e2 && e2->value) {
struct tm old_tm = {0};
-if (!parse_set_cookie_expiry_time(e->value, &old_tm)) {
+if (!parse_http_date(e->value, &old_tm)) {
if (av_timegm(&new_tm) < av_timegm(&old_tm)) {
av_dict_free(&new_params);
av_dict_free(&old_params);
@@ -1064,7 +1064,7 @@ static void parse_expires(HTTPContext *s, const char *p)
{
struct tm tm;
-if (!parse_set_cookie_expiry_time(p, &tm)) {
+if (!parse_http_date(p, &tm)) {
s->expires = av_timegm(&tm);
}
}
@@ -1295,7 +1295,7 @@ static int get_cookies(HTTPContext *s, char **cookies,
const char *path,
// if the cookie has expired, don't add it
if ((e = av_dict_get(cookie_params, "expires", NULL, 0)) && e->value) {
struct tm tm_buf = {0};
-if (!parse_set_cookie_expiry_time(e->value, &tm_buf)) {
+if (!parse_http_date(e->value, &tm_buf)) {
if (av_timegm(&tm_buf) < av_gettime() / 100)
goto skip_cookie;
}
--
2.43.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 v3 0/2] HTTP Retry-After Support
Changes since last set: * Updated commit message with RFC references. * Properly support Retry-After as both a date and integer number of seconds. I have tested this against both an HTTP-Date and seconds, and confirmed it to work. Derek Buitenhuis (2): avformat/http: Rename parse_set_cookie_expiry_time to parse_http_date avformat/http: Add support for Retry-After header doc/protocols.texi| 5 libavformat/http.c| 62 ++- libavformat/version.h | 2 +- 3 files changed, 49 insertions(+), 20 deletions(-) -- 2.43.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] avcodec/vvcdec: ff_vvc_frame_submit, avoid initializing task twice.
Thank you, Frank
Fixed by v2
On Mon, Apr 22, 2024 at 12:34 AM Frank Plowman
wrote:
> On 21/04/2024 15:52, Nuo Mi wrote:
> > For some error bitstreams, a CTU belongs to two slices/entry points.
> > If the decoder initializes and submmits the CTU task twice, it may crash
> the program
> > or cause it to enter an infinite loop.
> >
> > Reported-by: Frank Plowman
> > ---
> > libavcodec/vvc/dec.c| 7 +--
> > libavcodec/vvc/thread.c | 43 -
> > libavcodec/vvc/thread.h | 2 +-
> > 3 files changed, 36 insertions(+), 16 deletions(-)
> >
> > diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
> > index 6aeec27eaf..4f7d184e43 100644
> > --- a/libavcodec/vvc/dec.c
> > +++ b/libavcodec/vvc/dec.c
> > @@ -893,10 +893,13 @@ static int wait_delayed_frame(VVCContext *s,
> AVFrame *output, int *got_output)
> >
> > static int submit_frame(VVCContext *s, VVCFrameContext *fc, AVFrame
> *output, int *got_output)
> > {
> > -int ret;
> > +int ret = ff_vvc_frame_submit(s, fc);
> > +if (ret < 0)
> > +return ret;
> > +
> > s->nb_frames++;
> > s->nb_delayed++;
> > -ff_vvc_frame_submit(s, fc);
> > +
> > if (s->nb_delayed >= s->nb_fcs) {
> > if ((ret = wait_delayed_frame(s, output, got_output)) < 0)
> > return ret;
> > diff --git a/libavcodec/vvc/thread.c b/libavcodec/vvc/thread.c
> > index 01c3ff75b1..3b27811db2 100644
> > --- a/libavcodec/vvc/thread.c
> > +++ b/libavcodec/vvc/thread.c
> > @@ -124,11 +124,17 @@ static void task_init(VVCTask *t, VVCTaskStage
> stage, VVCFrameContext *fc, const
> > atomic_store(&t->target_inter_score, 0);
> > }
> >
> > -static void task_init_parse(VVCTask *t, SliceContext *sc, EntryPoint
> *ep, const int ctu_idx)
> > +static int task_init_parse(VVCTask *t, SliceContext *sc, EntryPoint
> *ep, const int ctu_idx)
> > {
> > +if (t->sc) {
> > +// the task already inited, error bitstream
> > +return AVERROR_INVALIDDATA;
> > +}
> > t->sc = sc;
> > t->ep = ep;
> > t->ctu_idx = ctu_idx;
> > +
> > +return 0;
> > }
> >
> > static uint8_t task_add_score(VVCTask *t, const VVCTaskStage stage)
> > @@ -758,24 +764,35 @@ static void submit_entry_point(VVCContext *s,
> VVCFrameThread *ft, SliceContext *
> > frame_thread_add_score(s, ft, t->rx, t->ry, VVC_TASK_STAGE_PARSE);
> > }
> >
> > -void ff_vvc_frame_submit(VVCContext *s, VVCFrameContext *fc)
> > +int ff_vvc_frame_submit(VVCContext *s, VVCFrameContext *fc)
> > {
> > VVCFrameThread *ft = fc->ft;
> >
> > -for (int i = 0; i < fc->nb_slices; i++) {
> > -SliceContext *sc = fc->slices[i];
> > -for (int j = 0; j < sc->nb_eps; j++) {
> > -EntryPoint *ep = sc->eps + j;
> > -for (int k = ep->ctu_start; k < ep->ctu_end; k++) {
> > -const int rs = sc->sh.ctb_addr_in_curr_slice[k];
> > -VVCTask *t = ft->tasks + rs;
> > -
> > -task_init_parse(t, sc, ep, k);
> > -check_colocation(s, t);
> > +// We'll handle this in two passes:
> > +// Pass 0 to initialize tasks with parser, this will help detect
> bit stream error
> > +// Pass 1 to shedule location check and submit the entry point
> > +for (int pass = 0; pass < 2; pass++) {
> > +for (int i = 0; i < fc->nb_slices; i++) {
> > +SliceContext *sc = fc->slices[i];
> > +for (int j = 0; j < sc->nb_eps; j++) {
> > +EntryPoint *ep = sc->eps + j;
> > +for (int k = ep->ctu_start; k < ep->ctu_end; k++) {
> > +const int rs = sc->sh.ctb_addr_in_curr_slice[k];
> > +VVCTask *t = ft->tasks + rs;
> > +if (pass) {
> > +check_colocation(s, t);
> > +} else {
> > +const int ret = task_init_parse(t, sc, ep, k);
> > +if (ret < 0)
> > +return ret;
> > +}
> > +}
> > +if (pass)
> > +submit_entry_point(s, ft, sc, ep);
> > }
> > -submit_entry_point(s, ft, sc, ep);
> > }
> > }
> > +return 0;
> > }
> >
> > int ff_vvc_frame_wait(VVCContext *s, VVCFrameContext *fc)
> > diff --git a/libavcodec/vvc/thread.h b/libavcodec/vvc/thread.h
> > index 55bb4ea244..8ac59b2ecf 100644
> > --- a/libavcodec/vvc/thread.h
> > +++ b/libavcodec/vvc/thread.h
> > @@ -30,7 +30,7 @@ void ff_vvc_executor_free(struct AVExecutor **e);
> >
> > int ff_vvc_frame_thread_init(VVCFrameContext *fc);
> > void ff_vvc_frame_thread_free(VVCFrameContext *fc);
> > -void ff_vvc_frame_submit(VVCContext *s, VVCFrameContext *fc);
> > +int ff_vvc_frame_submit(VVCContext *s, VVCFrameContext *fc);
> > int ff_vvc_frame_wait(VVCContext *s, VVCFrameContext *fc);
> >
> > #endif // AVCODEC_VVC_THREAD_H
>
> This patch fixes most of the fuz
[FFmpeg-devel] [PATCH v2 2/2] avcodec/vvcdec: ff_vvc_frame_submit, avoid initializing task twice.
For some error bitstreams, a CTU belongs to two slices/entry points.
If the decoder initializes and submmits the CTU task twice, it may crash the
program
or cause it to enter an infinite loop.
Reported-by: Frank Plowman
---
libavcodec/vvc/dec.c| 10 --
libavcodec/vvc/thread.c | 43 -
libavcodec/vvc/thread.h | 2 +-
3 files changed, 39 insertions(+), 16 deletions(-)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index 92999a3ce3..1b62f6199f 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -900,10 +900,16 @@ static int wait_delayed_frame(VVCContext *s, AVFrame
*output, int *got_output)
static int submit_frame(VVCContext *s, VVCFrameContext *fc, AVFrame *output,
int *got_output)
{
-int ret;
+int ret = ff_vvc_frame_submit(s, fc);
+
+if (ret < 0) {
+ff_vvc_report_frame_finished(fc->ref);
+return ret;
+}
+
s->nb_frames++;
s->nb_delayed++;
-ff_vvc_frame_submit(s, fc);
+
if (s->nb_delayed >= s->nb_fcs) {
if ((ret = wait_delayed_frame(s, output, got_output)) < 0)
return ret;
diff --git a/libavcodec/vvc/thread.c b/libavcodec/vvc/thread.c
index 01c3ff75b1..3b27811db2 100644
--- a/libavcodec/vvc/thread.c
+++ b/libavcodec/vvc/thread.c
@@ -124,11 +124,17 @@ static void task_init(VVCTask *t, VVCTaskStage stage,
VVCFrameContext *fc, const
atomic_store(&t->target_inter_score, 0);
}
-static void task_init_parse(VVCTask *t, SliceContext *sc, EntryPoint *ep,
const int ctu_idx)
+static int task_init_parse(VVCTask *t, SliceContext *sc, EntryPoint *ep, const
int ctu_idx)
{
+if (t->sc) {
+// the task already inited, error bitstream
+return AVERROR_INVALIDDATA;
+}
t->sc = sc;
t->ep = ep;
t->ctu_idx = ctu_idx;
+
+return 0;
}
static uint8_t task_add_score(VVCTask *t, const VVCTaskStage stage)
@@ -758,24 +764,35 @@ static void submit_entry_point(VVCContext *s,
VVCFrameThread *ft, SliceContext *
frame_thread_add_score(s, ft, t->rx, t->ry, VVC_TASK_STAGE_PARSE);
}
-void ff_vvc_frame_submit(VVCContext *s, VVCFrameContext *fc)
+int ff_vvc_frame_submit(VVCContext *s, VVCFrameContext *fc)
{
VVCFrameThread *ft = fc->ft;
-for (int i = 0; i < fc->nb_slices; i++) {
-SliceContext *sc = fc->slices[i];
-for (int j = 0; j < sc->nb_eps; j++) {
-EntryPoint *ep = sc->eps + j;
-for (int k = ep->ctu_start; k < ep->ctu_end; k++) {
-const int rs = sc->sh.ctb_addr_in_curr_slice[k];
-VVCTask *t = ft->tasks + rs;
-
-task_init_parse(t, sc, ep, k);
-check_colocation(s, t);
+// We'll handle this in two passes:
+// Pass 0 to initialize tasks with parser, this will help detect bit
stream error
+// Pass 1 to shedule location check and submit the entry point
+for (int pass = 0; pass < 2; pass++) {
+for (int i = 0; i < fc->nb_slices; i++) {
+SliceContext *sc = fc->slices[i];
+for (int j = 0; j < sc->nb_eps; j++) {
+EntryPoint *ep = sc->eps + j;
+for (int k = ep->ctu_start; k < ep->ctu_end; k++) {
+const int rs = sc->sh.ctb_addr_in_curr_slice[k];
+VVCTask *t = ft->tasks + rs;
+if (pass) {
+check_colocation(s, t);
+} else {
+const int ret = task_init_parse(t, sc, ep, k);
+if (ret < 0)
+return ret;
+}
+}
+if (pass)
+submit_entry_point(s, ft, sc, ep);
}
-submit_entry_point(s, ft, sc, ep);
}
}
+return 0;
}
int ff_vvc_frame_wait(VVCContext *s, VVCFrameContext *fc)
diff --git a/libavcodec/vvc/thread.h b/libavcodec/vvc/thread.h
index 55bb4ea244..8ac59b2ecf 100644
--- a/libavcodec/vvc/thread.h
+++ b/libavcodec/vvc/thread.h
@@ -30,7 +30,7 @@ void ff_vvc_executor_free(struct AVExecutor **e);
int ff_vvc_frame_thread_init(VVCFrameContext *fc);
void ff_vvc_frame_thread_free(VVCFrameContext *fc);
-void ff_vvc_frame_submit(VVCContext *s, VVCFrameContext *fc);
+int ff_vvc_frame_submit(VVCContext *s, VVCFrameContext *fc);
int ff_vvc_frame_wait(VVCContext *s, VVCFrameContext *fc);
#endif // AVCODEC_VVC_THREAD_H
--
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".
[FFmpeg-devel] [PATCH v2 1/2] avcodec/vvcdec: we need error handling if fc->ft is NULL
Another inter frame may be waiting on this frame.
We must finish it to avoid infinite waiting.
---
libavcodec/vvc/dec.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index 6aeec27eaf..92999a3ce3 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -854,6 +854,13 @@ static int decode_nal_units(VVCContext *s, VVCFrameContext
*fc, AVPacket *avpkt)
}
}
}
+
+if (!fc->ft) {
+av_log(s->avctx, AV_LOG_ERROR, "No frame in the packet.\n");
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
return 0;
fail:
@@ -948,9 +955,6 @@ static int vvc_decode_frame(AVCodecContext *avctx, AVFrame
*output,
if (ret < 0)
return ret;
-if (!fc->ft)
-return avpkt->size;
-
ret = submit_frame(s, fc, output, got_output);
if (ret < 0)
return ret;
--
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 v2 0/9] HTTP rate limiting and retry improvements
On 4/24/2024 8:43 PM, Derek Buitenhuis wrote: > Applied all your comments. > > Will wait a day and then push if no others appear. Pushed all except Retry-After support, which I need to change. While adding RFC references I noticed it can be in seconds, *or* a date... fun. Sending an updated patch for that in a bit in a new thread. - Derek ___ 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] Request for Official GitHub Mirror of rtmpdump for Enhanced Security
On 4/23/2024 10:46 PM, Michael Niedermayer wrote: > Can you elaborate what the problem is ? > I would have thought https://git.ffmpeg.org/rtmpdump.git > is secure I have to assume he means SHA-256, and not SHA-512. git apparently supports using SHA-256 instead of SHA-1 hashes, but support does not seem to be very mainstream. I am not even sure GitHub supports it (https://github.com/orgs/community/discussions/12490 seems to indicate not yet). So either this is vcpkg trying to be vey aggressive in requiring git features, or there is some clarification neeed. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
tor 2024-04-25 klockan 02:07 +0200 skrev Michael Niedermayer: > On Thu, Apr 25, 2024 at 12:50:02AM +0200, Tomas Härdin wrote: > > ons 2024-04-17 klockan 15:58 +0200 skrev Michael Niedermayer: > > > > > * ffchat > > > (expand into realtime chat / zoom) this would > > > bring in more users and developers, and we basically have > > > almost > > > all parts for it already but some people where against it > > > > You mean inventing a new chat protocol? If so then please don't. We > > If theres an existing protocol that serves the purpose then theres no > need to invent a new one > > I think at a minimum it should have "secure and private by default > and always" > (there are many solutions already when one is willing to give up > security/privacy) "Security" and "privacy" are relative terms. If you want end-to-end encryption in a federated system then XMPP+OMEMO is the way to go. Or Matrix I guess, but it isn't standardized last time I checked. If you want metadata resistance then Briar is the way to go. It's a peer-to-peer store-and-forward network that tunnels all its internet traffic through Tor, and also supports synchronizing messages over WiFi Direct and Bluetooth. There's also GNUnet and its associated protocols like psyc. Short of using some complicated thing involving data diodes you're not likely to do better than what's already out there. And nothing beats not using computers at 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] [RFC] 5 year plan & Inovation
On Sun, Apr 21, 2024 at 01:05:13AM +0200, Michael Niedermayer wrote: > On Fri, Apr 19, 2024 at 08:00:28PM +0200, Diederick C. Niehorster wrote: > > On Fri, Apr 19, 2024, 19:35 Zhao Zhili wrote: > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > Niklas Haas > > > > Sent: 2024年4月19日 22:50 > > > > To: FFmpeg development discussions and patches > > > > Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation > > > > > > > > On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer < > > > mich...@niedermayer.cc> wrote: > > > > > A plugin system moves this patch-management to people who actually > > > > > care, that is the authors of the codecs and (de)muxers. > > > > > > > > A plugin system will only solve this insomuch as plugin authors will > > > > just host their plugin code on GitHub instead of bothering with the > > > > mailing list. > > > > > > > > I think it runs a good risk of basically killing the project. > > > > > > VLC is plugin based, gstreamer is plugin based too (which went t far > > > 😝), > > > I don't think plugin is that dangerous. > > > > > > Firstly, we can enable plugin interface only with enable-gpl. > > > > > > Secondly, we can have a less stable plugin interface than public API, for > > > our > > > development convenience, and encourage plugin authors to contribute to > > > upstream. > > > > > > > > > > > > Our productivity as is, is not good, many patches are ignored. > > > > > The people caring about these patches are their Authors and yet they > > > > > are powerless as they must sometimes wait many months for reviews > > > > > > > > So, rather than all of the above, what I think we should do is contract > > > > somebody to set up, manage, host and maintain a GitLab instance for us. > > > > > > > > This would probably be the single most cost effective boost to both > > > > community growth and innovation I can think of, as it will remove > > > > several of the major grievances and barriers to entry with the > > > > ML+pingspam model. > > > > > > +1. > > > > > > I can't remember how many patches I have ping. It's really frustration. > > > I ask for permission to commit mostly due to this. > > > > > > Now I can keep track of my own patches, but it's still not easy to filter > > > out > > > patches I'm interested to review (I can blame the email client, but blame > > > it > > > doesn't help). I'm sure I can review more patches with a new workflow. > > > > > > > If i recall correctly, there was a conversation not too long ago about what > > to do with all the SPI money. This seems to be a perfect use for it. > > > 1. Set up and manage a gitlab instance > > I think we first need to understand what exact problem there is with the > ML/Patchwork workflow. Write this down. See if we all agree on that > > Look at what workflow* people use > Look at what alternatives to ML/Patchwork there are > I think others than gitlab where suggested like gittea and forgejo > > And then carefully evaluate each for cost vs benefit. > > If we agree on one then its probably best to setup a small test environment > and have the whole team try to use that before we consider a switch > > > > 2. Move tickets from trac to there (possibly) > > why ? > > > > 3. Move fate running to there > > why ? > > > workflow* > For example, i go through patches on the ML with mutt and i have one key > to apply a patch and another to open an editor and write a reply. Also i > have > my muttrc setup so it colorizes diffs nicely so patches are easy to review > I do test close to every patch posted on ffmpeg-devel, so being able > to quickly apply patches matters. If i had to use a GUI based browser > and click around with the mouse it would probably mean an end for me > testing all patches, simply as it would be too inconvenient and slow. It seems like this is splitting into two slightly different questions: One is "there's a bunch of jobs that could be interesting to someone, but nobody here wants to do. How do we attract people who'd want to do them?". For example, bindings in other languages are only interesting to people who use those languages, and people here are generally happy with C. The other is "there's a bunch of jobs nobody will ever want to do, how do we automate them away?". For example, it sounds like keeping the website updated is a boring routine you've found yourself stuck with. Moving away from the ML has to mean answering the first question with a trade-off. For example, I've got several patches outstanding, and I would *love* an interface that said "assigned: so-and-so" for the ones that just need a ping, and "unassigned" for the ones I shouldn't waste my limited energy on. But from your point-of-view, that would mean being chased through your day by a page of jobs people expect you to get done. On the other hand, there are many win/win answers to the automation question. For example, most platforms have some kind o
Re: [FFmpeg-devel] [PATCH v2] opusdsp: add ability to modify deemphasis constant
Apr 25, 2024, 02:08 by mich...@niedermayer.cc:
> On Wed, Apr 24, 2024 at 12:58:54PM +0200, Lynne wrote:
>
>> Apr 24, 2024, 10:54 by d...@lynne.ee:
>>
>> > xHE-AAC relies on the same postfilter mechanism
>> > that Opus uses to improve clarity (albeit with a steeper
>> > deemphasis filter).
>> >
>> > The code to apply it is identical, it's still just a
>> > simple IIR low-pass filter. This commit makes it possible
>> > to use alternative constants.
>> >
>> > Version 2 changes:
>> > Move the deemphasis constant table to opustab.c and
>> > document its values better.
>> >
>>
>> v3 attached, forgot to port the native opus encoder.
>>
>
> make V=2 fate-checkasm-opusdsp
> TESTcheckasm-opusdsp
> ./tests/fate-run.sh fate-checkasm-opusdsp
> "/home/michael/fatesamples/fate/fate-suite/" ""
> "/home/michael/ffmpeg-git/ffmpeg" 'run tests/checkasm/checkasm
> --test=opusdsp' 'null' '' '' '1' '' '' '' '' '' '' '' '' '' ''
> /home/michael/ffmpeg-git/ffmpeg/tests/checkasm/checkasm --test=opusdsp
> Test checkasm-opusdsp failed. Look at tests/data/fate/checkasm-opusdsp.err
> for details.
> checkasm: using random seed 4190264620
> FMA3:
> - opusdsp.postfilter_15 [OK]
> - opusdsp.postfilter_512 [OK]
> - opusdsp.postfilter_1022 [OK]
> deemphasis_fma3 (fatal signal 11: Segmentation fault)
> - opusdsp.deemphasis [FAILED]
> checkasm: 1 of 4 tests have failed
> threads=1
> make: *** [tests/Makefile:311: fate-checkasm-opusdsp] Error 1
>
Forgot that I disabled asm to test with asan.
Fixed checkasm.
Patch attached.
>From 6e956fc31ce487516bc4576facbd540baddb8a7b Mon Sep 17 00:00:00 2001
From: Lynne
Date: Mon, 29 Jan 2024 04:31:43 +0100
Subject: [PATCH v4] opusdsp: add ability to modify deemphasis constant
xHE-AAC relies on the same postfilter mechanism
that Opus uses to improve clarity (albeit with a steeper
deemphasis filter).
The code to apply it is identical, it's still just a
simple IIR low-pass filter. This commit makes it possible
to use alternative constants.
---
libavcodec/aarch64/opusdsp_init.c | 2 +-
libavcodec/aarch64/opusdsp_neon.S | 28 +---
libavcodec/opusdec_celt.c | 6 --
libavcodec/opusdsp.c | 6 --
libavcodec/opusdsp.h | 4 +---
libavcodec/opusenc.c | 5 +++--
libavcodec/opustab.c | 28
libavcodec/opustab.h | 2 ++
libavcodec/x86/opusdsp.asm| 9 +++--
libavcodec/x86/opusdsp_init.c | 2 +-
tests/checkasm/opusdsp.c | 9 +
11 files changed, 57 insertions(+), 44 deletions(-)
diff --git a/libavcodec/aarch64/opusdsp_init.c b/libavcodec/aarch64/opusdsp_init.c
index bb6d71b66b..a727006593 100644
--- a/libavcodec/aarch64/opusdsp_init.c
+++ b/libavcodec/aarch64/opusdsp_init.c
@@ -23,7 +23,7 @@
#include "libavcodec/opusdsp.h"
void ff_opus_postfilter_neon(float *data, int period, float *gains, int len);
-float ff_opus_deemphasis_neon(float *out, float *in, float coeff, int len);
+float ff_opus_deemphasis_neon(float *out, float *in, float coeff, const float *weights, int len);
av_cold void ff_opus_dsp_init_aarch64(OpusDSP *ctx)
{
diff --git a/libavcodec/aarch64/opusdsp_neon.S b/libavcodec/aarch64/opusdsp_neon.S
index e933151ab4..253825aa61 100644
--- a/libavcodec/aarch64/opusdsp_neon.S
+++ b/libavcodec/aarch64/opusdsp_neon.S
@@ -18,29 +18,11 @@
#include "libavutil/aarch64/asm.S"
- // 0.85..^10.85..^20.85..^30.85..^4
-const tab_st, align=4
-.word 0x3f599a00, 0x3f38f671, 0x3f1d382a, 0x3f05a32f
-endconst
-const tab_x0, align=4
-.word 0x0,0x3f599a00, 0x3f38f671, 0x3f1d382a
-endconst
-const tab_x1, align=4
-.word 0x0,0x0,0x3f599a00, 0x3f38f671
-endconst
-const tab_x2, align=4
-.word 0x0,0x0,0x0,0x3f599a00
-endconst
-
function ff_opus_deemphasis_neon, export=1
-movrel x4, tab_st
-ld1 {v4.4s}, [x4]
-movrel x4, tab_x0
-ld1 {v5.4s}, [x4]
-movrel x4, tab_x1
-ld1 {v6.4s}, [x4]
-movrel x4, tab_x2
-ld1 {v7.4s}, [x4]
+ld1 {v4.4s}, [x2], #16
+ld1 {v5.4s}, [x2], #16
+ld1 {v6.4s}, [x2], #16
+ld1 {v7.4s}, [x2]
fmulv0.4s, v4.4s, v0.s[0]
@@ -63,7 +45,7 @@ function ff_opus_deemphasis_neon, export=1
st1 {v1.4s, v2.4s}, [x0], #32
fmulv0.4s, v4.4s, v2.s[3]
-subsw2, w2, #8
+subsw3, w3, #8
b.gt1b
mov s0, v2.s[3]
diff --git a/libavcodec/opusdec_celt.c b/libavcodec/opusdec_celt.c
index fd8e9929e9..b19342337d 100644
--- a/libavcodec/opusdec_celt.c
+++ b/libavcodec/opusdec_celt.c
@@ -460,7 +460,9 @@ int ff_celt_decode_frame(CeltFrame *f, OpusRangeCoder *rc,
/* de
Re: [FFmpeg-devel] [PATCH v4] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
On Fri, Nov 24, 2023 at 8:27 AM Xiang, Haihao wrote:
>
> On Vr, 2023-10-27 at 22:25 +0200, David Rosca wrote:
> > This allows some optimizations in driver, such as not having to read
> > back the data if write-only mapping is requested.
> > ---
> > v4: overwrite + note about vaMapBuffer libva fallback
> >
> > libavutil/hwcontext_vaapi.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index 558fed94c6..435f10a7f3 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > VAStatus vas;
> > void *address = NULL;
> > int err, i;
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +uint32_t vaflags = 0;
> > +#endif
> >
> > surface_id = (VASurfaceID)(uintptr_t)src->data[3];
> > av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
> > @@ -882,7 +885,16 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > }
> > }
> >
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +if (flags & AV_HWFRAME_MAP_READ)
> > +vaflags |= VA_MAPBUFFER_FLAG_READ;
> > +if (flags & AV_HWFRAME_MAP_WRITE)
> > +vaflags |= VA_MAPBUFFER_FLAG_WRITE;
> > +// On drivers not implementing vaMapBuffer2 libva calls vaMapBuffer
> > instead.
> > +vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
> > +#else
> > vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
> > +#endif
> > if (vas != VA_STATUS_SUCCESS) {
> > av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
> > "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
>
> LGTM, and will apply it when the official libva 2.21 is released.
Ping, libva 2.21 has now been released.
Thanks,
David
>
> Thanks
> Haihao
>
>
___
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".
