[FFmpeg-devel] [PATCH] [h264] Make slice header parse errors fatal under AV_EF_EXPLODE

2025-01-06 Thread Dale Curtis
This fixes timeout issues with https://crbug.com/383814043 and seems like it was intended since the line emits an error log. Signed-off-by: Dale Curtis slice_error_v0.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel

Re: [FFmpeg-devel] PATCH] Make H.274 film grain support optional for H.264. Saves ~779kb.

2024-10-25 Thread Dale Curtis
Here's the rebased version. Thanks! - dale On Wed, Oct 23, 2024 at 1:47 PM Niklas Haas wrote: > On Wed, 23 Oct 2024 10:34:31 -0700 Dale Curtis > wrote: > > Yes, please apply the dynamic version. Thanks! > > > > - dale > > > > On Wed, Oct 16, 2024 at 5:

Re: [FFmpeg-devel] PATCH] Make H.274 film grain support optional for H.264. Saves ~779kb.

2024-10-23 Thread Dale Curtis
Yes, please apply the dynamic version. Thanks! - dale On Wed, Oct 16, 2024 at 5:09 AM Lynne via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > On 16/10/2024 14:06, Niklas Haas wrote: > > On Mon, 14 Oct 2024 11:03:49 -0700 Dale Curtis > wrote: > >> Any issues remain

Re: [FFmpeg-devel] [PATCH] lavc/avcodec: fix global/private option precendence

2024-10-14 Thread Dale Curtis
Thanks for the fix! Sorry for the breakage. - dale On Sun, Oct 13, 2024 at 3:01 PM Cameron Gutman wrote: > On Sun, Oct 13, 2024 at 8:29 AM Anton Khirnov wrote: > > > > Broken after 7753a9d62725d5bd8313e2d249acbe1c8af79ab1. Apply only the > > whitelist early, and the rest with a single call to

Re: [FFmpeg-devel] PATCH] Make H.274 film grain support optional for H.264. Saves ~779kb.

2024-10-14 Thread Dale Curtis
Any issues remaining with this patch? Thanks in advance for applying. - dale On Sun, Sep 22, 2024 at 4:30 PM Michael Niedermayer wrote: > On Wed, Aug 14, 2024 at 08:29:37AM +0200, Christophe Gisquet wrote: > > Hi, > > > > Le mar. 13 août 2024 à 23:39, Dale Curtis a >

Re: [FFmpeg-devel] PATCH] Make H.274 film grain support optional for H.264. Saves ~779kb.

2024-09-20 Thread Dale Curtis
Were there any more comments for this patch? - dale On Tue, Aug 13, 2024 at 11:30 PM Christophe Gisquet < christophe.gisq...@gmail.com> wrote: > Hi, > > Le mar. 13 août 2024 à 23:39, Dale Curtis a > écrit : > > > > On Tue, Aug 13, 2024 at 1:11 PM Hendrik Leppkes

Re: [FFmpeg-devel] [PATCH] [h264] Use small padding with the checked bitstream reader.

2024-09-06 Thread Dale Curtis
Were there any more comments on this patch? Thanks! - dale On Mon, Aug 19, 2024 at 12:19 PM Dale Curtis wrote: > On Sat, Aug 17, 2024 at 12:25 PM James Almer wrote: > >> On 8/17/2024 3:04 PM, Michael Niedermayer wrote: >> > >> > >>

Re: [FFmpeg-devel] [PATCH] Check codec_whitelist before reinitializing AVCtx.priv_data.

2024-08-19 Thread Dale Curtis
On Sat, Aug 17, 2024 at 1:42 AM Anton Khirnov wrote: > I don't follow, why would any code outside of libavcodec care about > anything in private data? > Sorry I was imprecise. The issue is that ff_codec_close() is called during "free_and_end", which releases a bunch of fields on the AVCodecConte

Re: [FFmpeg-devel] [PATCH] [h264] Use small padding with the checked bitstream reader.

2024-08-19 Thread Dale Curtis
On Sat, Aug 17, 2024 at 12:25 PM James Almer wrote: > On 8/17/2024 3:04 PM, Michael Niedermayer wrote: > > > > > 20978/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5746381832847360 > sent privately > Thanks for the sample Michael. I've confirmed it does not reproduce with my cha

[FFmpeg-devel] [PATCH] [h264] Use small padding with the checked bitstream reader.

2024-08-14 Thread Dale Curtis
but please yell if I've done something silly. Signed-off-by: Dale Curtis no_padding.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link

Re: [FFmpeg-devel] [PATCH] Fix nullptr dereference with invalid encryption metadata.

2024-08-14 Thread Dale Curtis
Bump for this one. Thanks! - dale On Fri, Aug 2, 2024 at 3:08 PM Dale Curtis wrote: > Found by fuzzer. > > Bug: https://crbug.com/356720789 > Signed-off-by: Dale Curtis > --- > libavformat/mov.c | 8 ++-- > 1 file changed, 6 inser

Re: [FFmpeg-devel] [PATCH] Don't reallocate a AVCodecContext when closing a non-open codec.

2024-08-14 Thread Dale Curtis
Bump for this one. Thanks! - dale On Fri, Aug 2, 2024 at 9:54 AM Dale Curtis wrote: > This results in an unnecessary ~800k allocation with H.264. A > nearby callsite uses avcodec_is_open() to avoid this, so do the > same when exiting avformat_find_stream_info(). > > Signed-off-

Re: [FFmpeg-devel] [PATCH] Check codec_whitelist before reinitializing AVCtx.priv_data.

2024-08-14 Thread Dale Curtis
Bump for this one. Thanks! - dale On Wed, Jul 31, 2024 at 4:18 PM Dale Curtis wrote: > On Wed, Jul 31, 2024 at 2:29 PM Dale Curtis > wrote: > >> On Wed, Jul 31, 2024 at 2:10 PM Dale Curtis >> wrote: >> >>> On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov

Re: [FFmpeg-devel] PATCH] Make H.274 film grain support optional for H.264. Saves ~779kb.

2024-08-13 Thread Dale Curtis
On Tue, Aug 13, 2024 at 1:11 PM Hendrik Leppkes wrote: > Disabling random codec features seems like an anti-feature to me, in > the future it'll make every feature be questioned and compile-time > conditional, and make everything terrible. > If the context size is the major concern, maybe large s

Re: [FFmpeg-devel] PATCH] Make H.274 film grain support optional for H.264. Saves ~779kb.

2024-08-13 Thread Dale Curtis
Thanks, disable-h274-film-grain and applying it to hevc too sgtm. I'll wait to see what Niklas says before updating though. - dale On Tue, Aug 13, 2024 at 12:47 PM James Almer wrote: > On 8/13/2024 4:31 PM, Dale Curtis wrote: > > Film grain support adds a huge amount of o

[FFmpeg-devel] PATCH] Make H.274 film grain support optional for H.264. Saves ~779kb.

2024-08-13 Thread Dale Curtis
the H264Context size from 851808 bytes to 53444 bytes. Bug: https://crbug.com/359358875 Signed-off-by: Dale Curtis Note: I'm not sure this is the right way to go about making this optional, please let me know if there's a better way. - dale optional_film_grain_v1.patch Description: B

[FFmpeg-devel] [PATCH] Fix nullptr dereference with invalid encryption metadata.

2024-08-02 Thread Dale Curtis
Found by fuzzer. Bug: https://crbug.com/356720789 Signed-off-by: Dale Curtis --- libavformat/mov.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) mov_fuzz_fix_v1.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg

[FFmpeg-devel] [PATCH] Don't reallocate a AVCodecContext when closing a non-open codec.

2024-08-02 Thread Dale Curtis
This results in an unnecessary ~800k allocation with H.264. A nearby callsite uses avcodec_is_open() to avoid this, so do the same when exiting avformat_find_stream_info(). Signed-off-by: Dale Curtis --- libavformat/demux.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions

Re: [FFmpeg-devel] [PATCH] Check codec_whitelist before reinitializing AVCtx.priv_data.

2024-07-31 Thread Dale Curtis
On Wed, Jul 31, 2024 at 2:29 PM Dale Curtis wrote: > On Wed, Jul 31, 2024 at 2:10 PM Dale Curtis > wrote: > >> On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov wrote: >> >>> Quoting Dale Curtis (2024-07-31 01:14:13) >>> > I realized there are a couple

Re: [FFmpeg-devel] [PATCH] Check codec_whitelist before reinitializing AVCtx.priv_data.

2024-07-31 Thread Dale Curtis
On Wed, Jul 31, 2024 at 2:10 PM Dale Curtis wrote: > On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov wrote: > >> Quoting Dale Curtis (2024-07-31 01:14:13) >> > I realized there are a couple more allocations that can be skipped here >> > when a codec is not on the

Re: [FFmpeg-devel] [PATCH] Check codec_whitelist before reinitializing AVCtx.priv_data.

2024-07-31 Thread Dale Curtis
On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov wrote: > Quoting Dale Curtis (2024-07-31 01:14:13) > > I realized there are a couple more allocations that can be skipped here > > when a codec is not on the allow list. Here's the updated patch. > > > > - dale &g

Re: [FFmpeg-devel] [PATCH] Check codec_whitelist before reinitializing AVCtx.priv_data.

2024-07-30 Thread Dale Curtis
I realized there are a couple more allocations that can be skipped here when a codec is not on the allow list. Here's the updated patch. - dale On Mon, Jul 29, 2024 at 10:19 AM Dale Curtis wrote: > This ensures that if a codec isn't on codec_whitelist, its VUI > informat

[FFmpeg-devel] [PATCH] Check codec_whitelist before reinitializing AVCtx.priv_data.

2024-07-29 Thread Dale Curtis
This ensures that if a codec isn't on codec_whitelist, its VUI information can still be populated during find_stream_info() via parsers. Signed-off-by: Dale Curtis --- libavcodec/avcodec.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) no_reinit.patch Description: B

Re: [FFmpeg-devel] [PATCH] libavformat/flac_picture: Don't return AVERROR_INVALIDDATA for errors with flac picture mimetype

2024-03-27 Thread Dale Curtis
Bump on this patch -- it still applies cleanly. We're still seeing files in the wild like this. - dale On Mon, Apr 10, 2023 at 10:54 AM Dale Curtis wrote: > Will left Google, but I've updated the patch to only skip errors when the > type is unrecognized. > > On Wed, S

Re: [FFmpeg-devel] [PATCH] [mov] Avoid OOM for invalid STCO / CO64 constructions.

2024-02-16 Thread Dale Curtis
On Thu, Feb 15, 2024 at 2:35 PM Michael Niedermayer wrote: > FFMIN/MAX can evaluate their arguments multiple times so avio_rb32() might > be executed more than once > Thanks. Good catch. Fixed. stco-clamp-entries-v4.patch Description: Binary data ___

Re: [FFmpeg-devel] [PATCH] [mov] Avoid OOM for invalid STCO / CO64 constructions.

2024-02-15 Thread Dale Curtis
s possible, but I've added a FFMAX(0,) there too. - dale From db3e9ffc364cc94cb3a72696d4d4858af6abcc42 Mon Sep 17 00:00:00 2001 From: Dale Curtis Date: Fri, 2 Feb 2024 20:49:44 + Subject: [PATCH] [mov] Avoid OOM for invalid STCO / CO64 constructions. The `entries` value is read direct

Re: [FFmpeg-devel] [PATCH] [mov] Avoid OOM for invalid STCO / CO64 constructions.

2024-02-02 Thread Dale Curtis
On Fri, Feb 2, 2024 at 3:42 PM Dale Curtis wrote: > On Fri, Feb 2, 2024 at 3:20 PM Andreas Rheinhardt < > andreas.rheinha...@outlook.com> wrote: > >> Dale Curtis: >> > +// Clamp allocation size for `chunk_offsets` -- don't throw an >> error for an

Re: [FFmpeg-devel] [PATCH] [mov] Avoid OOM for invalid STCO / CO64 constructions.

2024-02-02 Thread Dale Curtis
On Fri, Feb 2, 2024 at 3:20 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Dale Curtis: > > +// Clamp allocation size for `chunk_offsets` -- don't throw an > error for an > > +// invalid count since the EOF path doesn't throw either. >

[FFmpeg-devel] [PATCH] [mov] Avoid OOM for invalid STCO / CO64 constructions.

2024-02-02 Thread Dale Curtis
The `entries` value is read directly from the stream and used to allocate memory. This change clamps `entries` to however many are possible in the remaining atom or file size (whichever is smallest). Fixes https://crbug.com/1429357 Signed-off-by: Dale Curtis --- libavformat/mov.c | 7

Re: [FFmpeg-devel] [PATCH] avformat/mov: Ignore duplicate ftyp

2023-12-04 Thread Dale Curtis
Thanks! lgtm, defer to you on FF_COMPLIANCE_STRICT. On Fri, Dec 1, 2023 at 3:59 PM wrote: > > > On 2 Dec 2023, at 0:26, Michael Niedermayer wrote: > > > Fixes: switch_1080p_720p.mp4 > > Found-by: Dale Curtis > > Signed-off-by: Michael Niedermayer >

Re: [FFmpeg-devel] [PATCH] Fix integer overflow in mov_read_packet().

2023-12-01 Thread Dale Curtis
On Fri, Nov 24, 2023 at 3:38 PM Michael Niedermayer wrote: > On Wed, Nov 22, 2023 at 02:20:59PM -0800, Dale Curtis wrote: > > Fixes https://crbug.com/1499669: > > > runtime error: signed integer overflow: 9223372036853334272 + 1375731456 > > this looks a bit close to AV

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: Disallow FTYP after streams

2023-12-01 Thread Dale Curtis
FWIW, this ends up breaking files which are basically just concatenated fragmented mp4 files -- which is pretty sketchy, but we had some test content doing that: https://storage.googleapis.com/chromiumos-test-assets-public/Shaka-Dash/switch_1080p_720p.mp4 Is that intentional? Or should an alternat

[FFmpeg-devel] [PATCH] Fix integer overflow in mov_read_packet().

2023-11-22 Thread Dale Curtis
Fixes https://crbug.com/1499669: runtime error: signed integer overflow: 9223372036853334272 + 1375731456 cannot be represented in type 'int64_t' (aka 'long') Signed-off-by: Dale Curtis --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a

Re: [FFmpeg-devel] Question about HEIF/HEIC support

2020-09-29 Thread Dale Curtis
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/252827.html was the last discussion on this. At the time I found it broke some mp4 files. - dale On Sat, Sep 26, 2020 at 4:37 AM Tom Needham <06needh...@gmail.com> wrote: > Hello > > I have spent some time researching the possibility of addi

Re: [FFmpeg-devel] [mov] See if mfra makes up the difference for an incomplete sidx.

2020-08-27 Thread Dale Curtis
Bump to get this applied. Thanks! - dale On Wed, Aug 19, 2020 at 6:13 AM Michael Niedermayer wrote: > On Tue, Aug 18, 2020 at 02:04:04PM +0100, Derek Buitenhuis wrote: > > On 18/08/2020 04:57, Dale Curtis wrote: > > > Can't be an else statement since the prior clau

Re: [FFmpeg-devel] [mov] See if mfra makes up the difference for an incomplete sidx.

2020-08-17 Thread Dale Curtis
On Mon, Aug 17, 2020 at 12:12 PM Derek Buitenhuis < derek.buitenh...@gmail.com> wrote: > Patch lacks the context for stream_size here - will it always be > correct? Only asking since the check for the coede below this will > have changed from avio_size(pb) to stream_size. > stream_size == avio_si

Re: [FFmpeg-devel] [mov] See if mfra makes up the difference for an incomplete sidx.

2020-08-17 Thread Dale Curtis
Bump. Thanks for consideration! - dale On Thu, Aug 13, 2020 at 3:03 PM Dale Curtis wrote: > A few popular sites have started generating MP4 files which have a > sidx plus an mfra. The sidx accounts for all size except the mfra, > so the old code did not mark the fragment index as

[FFmpeg-devel] [mov] See if mfra makes up the difference for an incomplete sidx.

2020-08-13 Thread Dale Curtis
k the index as complete. Fixes: https://crbug.com/1107130 Signed-off-by: Dale Curtis sidx_fix_v0.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit

Re: [FFmpeg-devel] [PATCH 3/5] [mov] Check if DTS is AV_NOPTS_VALUE in mov_find_next_sample().

2020-06-11 Thread Dale Curtis
Bump again. Thanks. - dale On Fri, Jun 5, 2020 at 11:48 AM Dale Curtis wrote: > Bump for this one again. Thanks in advance. > > - dale > > On Thu, May 28, 2020 at 12:37 PM Dale Curtis > wrote: > >> Bump now that the saturated math operations have landed. Thanks

Re: [FFmpeg-devel] [PATCH 3/5] [mov] Check if DTS is AV_NOPTS_VALUE in mov_find_next_sample().

2020-06-05 Thread Dale Curtis
Bump for this one again. Thanks in advance. - dale On Thu, May 28, 2020 at 12:37 PM Dale Curtis wrote: > Bump now that the saturated math operations have landed. Thanks! > > - dale > > On Thu, May 14, 2020 at 3:31 PM Dale Curtis > wrote: > >> &g

Re: [FFmpeg-devel] [PATCH 4/5] [utils, mathematics] Fix overflow in compute_pkt_fields().

2020-06-05 Thread Dale Curtis
Bump for this one again. Thanks in advance. - dale On Thu, May 28, 2020 at 12:37 PM Dale Curtis wrote: > Bump now that the saturated math operations have landed. Thanks! > > - dale > > On Thu, May 14, 2020 at 3:31 PM Dale Curtis > wrote: > >> Fixes one issue in

Re: [FFmpeg-devel] [PATCH] Don't adjust start time for MP3 files; packets are not adjusted.

2020-05-29 Thread Dale Curtis
On Thu, May 28, 2020 at 1:33 PM Michael Niedermayer wrote: > I dont really have an oppinion about start_time, its more the change in > timestamps & duratiion on the output side which is whats user vissible > and that looked worse for the testcase > The difference is due to the decode stage apply

[FFmpeg-devel] [PATCH] Don't update start time when lastpts is AV_NOPTS_VALUE.

2020-05-29 Thread Dale Curtis
Signed-off-by: Dale Curtis --- libavformat/oggparsetheora.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) no_start_time_update_v0.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman

Re: [FFmpeg-devel] [PATCH 1/5] Use av_sat_add64() when updating start_time by skip_samples.

2020-05-28 Thread Dale Curtis
Bump now that the saturated math operations have landed. Thanks! - dale On Thu, May 14, 2020 at 3:31 PM Dale Curtis wrote: > Avoids overflow from fuzzed skip_samples values. > > Signed-off-by: Dale Curtis > --- > libavformat/utils.c | 4 ++-- > 1 file changed, 2 insertio

Re: [FFmpeg-devel] [PATCH 2/5] [oggparsetheora] Use av_sat_sub64() when updating pts by duration.

2020-05-28 Thread Dale Curtis
Bump now that the saturated math operations have landed. Thanks! - dale On Thu, May 14, 2020 at 3:31 PM Dale Curtis wrote: > Signed-off-by: Dale Curtis > --- > libavformat/oggparsetheora.c | 2 +- > 1 file changed, 1 insertion(+)

Re: [FFmpeg-devel] [PATCH 4/5] [utils, mathematics] Fix overflow in compute_pkt_fields().

2020-05-28 Thread Dale Curtis
Bump now that the saturated math operations have landed. Thanks! - dale On Thu, May 14, 2020 at 3:31 PM Dale Curtis wrote: > Fixes one issue in the function itself and one in the dependent > function av_add_stable() which wasn't checking for NaN. > > Signed-of

Re: [FFmpeg-devel] [PATCH 3/5] [mov] Check if DTS is AV_NOPTS_VALUE in mov_find_next_sample().

2020-05-28 Thread Dale Curtis
Bump now that the saturated math operations have landed. Thanks! - dale On Thu, May 14, 2020 at 3:31 PM Dale Curtis wrote: > > Signed-off-by: Dale Curtis > --- > libavformat/mov.c | 2 +- > 1 file changed, 1 insertion

Re: [FFmpeg-devel] [PATCH] Don't adjust start time for MP3 files; packets are not adjusted.

2020-05-27 Thread Dale Curtis
On Wed, May 27, 2020 at 8:29 AM Michael Niedermayer wrote: > what id like to point out here is that the audio stream no > longer starts at the same time as the video > also the duration from adding the durations before is > exact but not afterwards > I'm not sure about the duration issue, I'd as

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-27 Thread Dale Curtis
On Wed, May 27, 2020 at 11:10 AM Michael Niedermayer wrote: > so the builtin does better and both locally do better than clang on the web > tool > Ah, sorry I forgot godbolt is compiling without any options, if you type -O9 in the compiler options fields you get: clang: https://godbolt.org/z/CAM

Re: [FFmpeg-devel] [PATCH] Don't adjust start time for MP3 files; packets are not adjusted.

2020-05-26 Thread Dale Curtis
On Wed, May 20, 2020 at 5:22 AM Anton Khirnov wrote: > > Looks reasonable, will push. > Thanks! I don't see this in the commit log. Did it end up getting pushed? - dale ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/l

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-26 Thread Dale Curtis
On Fri, May 22, 2020 at 1:34 PM Michael Niedermayer wrote: > > does this produce faster / better code ? > that is do compilers actually fail to optimize this from plain > clean C code ? > Here's the difference: clang trunk: https://godbolt.org/z/6SHmEo gcc trunk: https://godbolt.org/z/iKb9jZ I

Re: [FFmpeg-devel] [PATCH] [libavformat] Avoid integer overflow on start_time with skip_samples.

2020-05-26 Thread Dale Curtis
This patch can be abandoned in favor of the other one which uses av_sat_add64(). - dale On Thu, Apr 30, 2020 at 3:20 PM Dale Curtis wrote: > I've sent a follow up patch set implementing saturating operations if > that's something folks are interested in. > > - dale >

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-21 Thread Dale Curtis
On Thu, May 21, 2020 at 12:37 AM Michael Niedermayer wrote: > gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 > used with ccache on a x86-64 > Huh, I guess there's no early abort for conditionals in a preprocessor statement with __has_builtin for some reason. I've added a AV_HAS_BUILTIN macro to workaro

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-20 Thread Dale Curtis
On Wed, May 20, 2020 at 1:17 AM Michael Niedermayer wrote: > > In file included from ./libavutil/avutil.h:296:0, > from ./libavutil/log.h:25, > from ./libavutil/thread.h:34, > from libavdevice/alldevices.c:22: > ./libavutil/common.h: In function

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-18 Thread Dale Curtis
On Mon, May 18, 2020 at 3:24 PM Dale Curtis wrote: > On Mon, May 18, 2020 at 2:22 PM Michael Niedermayer > wrote: > >> >> > 38cfdcfc9d4fa1c1239dc01a766e369b20a0232a sat_math_builtin_v5.patch >> > > Latest upload is sat_math_builtin_v6.patch -- is that not

[FFmpeg-devel] [PATCH] [mov] Free temp buffer upon negative sample_size error.

2020-05-18 Thread Dale Curtis
2d8d554f15a7a27cfeca81467cc9341a86f784e2 added a new error condition to mov_read_stsz() but forgot to free a temporary buffer when it occurs. Signed-off-by: Dale Curtis --- libavformat/mov.c | 1 + 1 file changed, 1 insertion(+) free_temp_v0.patch Description: Binary data

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-18 Thread Dale Curtis
. > > From 8ac3c2cea0d00c4aec2d1c6278462e6b0f1015b3 Mon Sep 17 00:00:00 2001 > > From: Dale Curtis > > Date: Fri, 1 May 2020 10:20:43 -0700 > > Subject: [PATCH] Use gcc/clang builtins for av_sat_(add|sub)_64_c if > > available. > > doesnt apply cleanly > > Applying: Use gcc

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-18 Thread Dale Curtis
The C versions of these functions have landed. Michael, did you intend to land this one too? - dale On Thu, May 14, 2020 at 12:47 PM Dale Curtis wrote: > Rebased. > > On Mon, May 4, 2020 at 11:47 AM James Almer wrote: > >> On 5/4/2020 3:40 PM, Dale Curtis wrote: >> >

[FFmpeg-devel] [PATCH 4/5] [utils, mathematics] Fix overflow in compute_pkt_fields().

2020-05-14 Thread Dale Curtis
Fixes one issue in the function itself and one in the dependent function av_add_stable() which wasn't checking for NaN. Signed-off-by: Dale Curtis --- libavformat/utils.c | 2 +- libavutil/mathematics.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)

[FFmpeg-devel] [PATCH 3/5] [mov] Check if DTS is AV_NOPTS_VALUE in mov_find_next_sample().

2020-05-14 Thread Dale Curtis
Signed-off-by: Dale Curtis --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) From e4b963f890ae37e2a06276a3067daab75013c8f9 Mon Sep 17 00:00:00 2001 From: Dale Curtis Date: Thu, 14 May 2020 14:38:07 -0700 Subject: [PATCH 3/5] [mov] Check if DTS is AV_NOPTS_VALUE in

[FFmpeg-devel] [PATCH 5/5] [mov] Don't allow negative sample sizes.

2020-05-14 Thread Dale Curtis
Signed-off-by: Dale Curtis --- libavformat/mov.c | 4 1 file changed, 4 insertions(+) From 3cd1ecb83c4b100bef99d9cd23d0066f0ad3cc5c Mon Sep 17 00:00:00 2001 From: Dale Curtis Date: Thu, 14 May 2020 14:57:08 -0700 Subject: [PATCH 5/5] [mov] Don't allow negative sample sizes. Signed-o

[FFmpeg-devel] [PATCH 2/5] [oggparsetheora] Use av_sat_sub64() when updating pts by duration.

2020-05-14 Thread Dale Curtis
Signed-off-by: Dale Curtis --- libavformat/oggparsetheora.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) From 6ae2834612ddc47e4ce40c87a9cc7e76e402bbdc Mon Sep 17 00:00:00 2001 From: Dale Curtis Date: Thu, 14 May 2020 14:33:55 -0700 Subject: [PATCH 2/5] [oggparsetheora] Use av_sat_sub64

[FFmpeg-devel] [PATCH 1/5] Use av_sat_add64() when updating start_time by skip_samples.

2020-05-14 Thread Dale Curtis
Avoids overflow from fuzzed skip_samples values. Signed-off-by: Dale Curtis --- libavformat/utils.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) From 7482aaef44fa4c6c43efd16b2ed8eb474b1283b0 Mon Sep 17 00:00:00 2001 From: Dale Curtis Date: Thu, 14 May 2020 14:29:15 -0700 Subject

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-14 Thread Dale Curtis
On Thu, May 14, 2020 at 11:47 AM Michael Niedermayer wrote: > On Fri, May 01, 2020 at 11:42:43AM -0700, Dale Curtis wrote: > > On Fri, May 1, 2020 at 10:57 AM Carl Eugen Hoyos > wrote: > > > > > Could you confirm that you attached the wrong patch? > > > &g

Re: [FFmpeg-devel] [PATCH] Don't adjust start time for MP3 files; packets are not adjusted.

2020-05-14 Thread Dale Curtis
Bump again for this one too. Thanks. The Arch Linux distro is awaiting resolution of this issue. - dale On Mon, May 4, 2020 at 11:10 AM Dale Curtis wrote: > Any comments on this? Thanks. > > - dale > > On Thu, Apr 30, 2020 at 12:42 PM Dale Curtis > wrote: > >>

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-13 Thread Dale Curtis
On Wed, May 13, 2020 at 3:55 PM Michael Niedermayer wrote: > On Fri, May 08, 2020 at 05:21:06PM -0700, Dale Curtis wrote: > > On Wed, May 6, 2020 at 7:03 AM Michael Niedermayer > > > wrote: > > > > > On Mon, May 04, 2020 at 04:06:56PM -0700, Dale Curtis wrote:

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-12 Thread Dale Curtis
On Fri, May 8, 2020 at 5:21 PM Dale Curtis wrote: > On Wed, May 6, 2020 at 7:03 AM Michael Niedermayer > wrote: > >> On Mon, May 04, 2020 at 04:06:56PM -0700, Dale Curtis wrote: >> > On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer >> >> > wrote: &g

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-08 Thread Dale Curtis
On Wed, May 6, 2020 at 7:03 AM Michael Niedermayer wrote: > On Mon, May 04, 2020 at 04:06:56PM -0700, Dale Curtis wrote: > > On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer > > > wrote: > > > > > On Mon, May 04, 2020 at 02:19:47PM -0700, Dale Curtis wrote: &g

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-04 Thread Dale Curtis
On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer wrote: > On Mon, May 04, 2020 at 02:19:47PM -0700, Dale Curtis wrote: > > On Mon, May 4, 2020 at 1:48 PM Michael Niedermayer > > [...] > You snipped out the example I provided, but did you have an opinion on which approach lo

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-04 Thread Dale Curtis
On Mon, May 4, 2020 at 1:48 PM Michael Niedermayer wrote: > this could be done, but iam unsure this API is optimal > > Maybe its best to show an example, why iam unsure about the API > Thanks, but maybe a more concrete case to look at would be the patch I sent for fixing skip samples: "Avoid int

Re: [FFmpeg-devel] [PATCH] Don't adjust start time for MP3 files; packets are not adjusted.

2020-05-04 Thread Dale Curtis
Any comments on this? Thanks. - dale On Thu, Apr 30, 2020 at 12:42 PM Dale Curtis wrote: > Ping for this patch. Thanks > > - dale > > On Thu, Apr 23, 2020 at 4:33 PM Dale Curtis > wrote: > >> This is a patch Chromium has carried for a while, we forgot to send it &g

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-04 Thread Dale Curtis
On Mon, May 4, 2020 at 11:19 AM James Almer wrote: > On 5/4/2020 3:09 PM, Dale Curtis wrote: > > Bump. I have 5 integer overflow fuzzing issues awaiting our resolution of > > this discussion. Thanks. > > > > - dale > > What's the first version of clang

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-04 Thread Dale Curtis
Bump. I have 5 integer overflow fuzzing issues awaiting our resolution of this discussion. Thanks. - dale On Fri, May 1, 2020 at 1:13 PM Dale Curtis wrote: > On Fri, May 1, 2020 at 12:53 PM Michael Niedermayer > wrote: > >> On Thu, Apr 30, 2020 at 05:39:43PM -0700, Dale Curtis

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-04 Thread Dale Curtis
Bump. I have 5 integer overflow fuzzing issues awaiting our resolution of this discussion. Thanks. - dale On Fri, May 1, 2020 at 2:53 PM Dale Curtis wrote: > On Fri, May 1, 2020 at 2:00 PM Carl Eugen Hoyos > wrote: > >> Am Fr., 1. Mai 2020 um 22:16 Uhr schrieb Dale Curt

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-01 Thread Dale Curtis
On Fri, May 1, 2020 at 2:00 PM Carl Eugen Hoyos wrote: > Am Fr., 1. Mai 2020 um 22:16 Uhr schrieb Dale Curtis < > dalecur...@chromium.org>: > > > > On Fri, May 1, 2020 at 1:12 PM Carl Eugen Hoyos > wrote: > > > > > Am Fr., 1. Mai 2020 um 22:06 Uhr

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-01 Thread Dale Curtis
conditions. > Thanks. Done. - dale From 84a19373b4aa2bd01bdd239263c585b957a7b713 Mon Sep 17 00:00:00 2001 From: Dale Curtis Date: Fri, 1 May 2020 10:20:43 -0700 Subject: [PATCH] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available. Signed-off-by: Dale Curtis --- libavutil/common.h |

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-01 Thread Dale Curtis
On Fri, May 1, 2020 at 12:53 PM Michael Niedermayer wrote: > On Thu, Apr 30, 2020 at 05:39:43PM -0700, Dale Curtis wrote: > > On Thu, Apr 30, 2020 at 5:21 PM James Almer wrote: > > > > > On 4/30/2020 7:19 PM, Dale Curtis wrote: > > > > Many places are usin

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-01 Thread Dale Curtis
On Fri, May 1, 2020 at 12:50 PM Dale Curtis wrote: > On Fri, May 1, 2020 at 12:37 PM Carl Eugen Hoyos > wrote: > >> > >> > So ICC on Linux defines __GNUC__ >= 5 yet doesn't support these >> builtins? >> >> No, but yes, this is the effect. &g

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-01 Thread Dale Curtis
_builtin() which shouldn't be masqueraded by the ICC. - dale From b52049eea61e602382684534c18fd1e301b13d46 Mon Sep 17 00:00:00 2001 From: Dale Curtis Date: Fri, 1 May 2020 10:20:43 -0700 Subject: [PATCH] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available. Signed-off-by: Dale Cu

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-01 Thread Dale Curtis
On Fri, May 1, 2020 at 11:22 AM James Almer wrote: > On 5/1/2020 3:07 PM, Carl Eugen Hoyos wrote: > > Am Fr., 1. Mai 2020 um 19:24 Uhr schrieb Dale Curtis < > dalecur...@chromium.org>: > >> > >> Signed-off-by: Dale Curtis > >> --- > >> l

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-01 Thread Dale Curtis
On Fri, May 1, 2020 at 10:57 AM Carl Eugen Hoyos wrote: > Could you confirm that you attached the wrong patch? > No, I sent the patches without completing the rebase. Sorry. - dale sat_math_v4.patch Description: Binary data ___ ffmpeg-devel mailing

Re: [FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-01 Thread Dale Curtis
Rebased. On Fri, May 1, 2020 at 10:24 AM Dale Curtis wrote: > Signed-off-by: Dale Curtis > --- > libavutil/common.h | 10 ++ > 1 file changed, 10 insertions(+) > sat_math_builtin_v1.patch Description: Binary data ___ ffmpe

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-01 Thread Dale Curtis
On Fri, May 1, 2020 at 10:32 AM James Almer wrote: > On 5/1/2020 2:23 PM, Dale Curtis wrote: > > On Fri, May 1, 2020 at 6:12 AM James Almer wrote: > > > >> On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote: > >>> > >>> The macro exists to avoid separate

[FFmpeg-devel] [PATCH 2/2] Use gcc/clang builtins for av_sat_(add|sub)_64_c if available.

2020-05-01 Thread Dale Curtis
Signed-off-by: Dale Curtis --- libavutil/common.h | 10 ++ 1 file changed, 10 insertions(+) sat_math_builtin_v0.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-01 Thread Dale Curtis
On Fri, May 1, 2020 at 6:12 AM James Almer wrote: > On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote: > > > > The macro exists to avoid separate patches? > > No, it exists to not require configure checks just to enable a path for > gcc/clang and another for other compilers. > Since consensus seems to

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-04-30 Thread Dale Curtis
On Thu, Apr 30, 2020 at 5:21 PM James Almer wrote: > On 4/30/2020 7:19 PM, Dale Curtis wrote: > > Many places are using their own custom code for handling overflow > > around timestamps or other int64_t values. There are enough of these > > now that having some common sat

Re: [FFmpeg-devel] [PATCH] [libavformat] Avoid integer overflow on start_time with skip_samples.

2020-04-30 Thread Dale Curtis
I've sent a follow up patch set implementing saturating operations if that's something folks are interested in. - dale On Thu, Apr 30, 2020 at 2:18 PM Dale Curtis wrote: > That said, instead of aborting the operation, perhaps it'd make more sense > for library functions t

[FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-04-30 Thread Dale Curtis
available or implements its own version for older compilers. Signed-off-by: Dale Curtis --- libavutil/mathematics.c | 26 ++ libavutil/mathematics.h | 19 +++ 2 files changed, 45 insertions(+) sat_math_v0.patch Description: Binary data

Re: [FFmpeg-devel] [PATCH] [libavformat] Avoid integer overflow on start_time with skip_samples.

2020-04-30 Thread Dale Curtis
That said, instead of aborting the operation, perhaps it'd make more sense for library functions to be av_saturated_add(), av_saturated_sub() which saturate to INT64_MIN/MAX. - dale On Thu, Apr 30, 2020 at 1:26 PM Dale Curtis wrote: > Aside: This overflow check is used in quite a fe

Re: [FFmpeg-devel] [PATCH] Don't adjust start time for MP3 files; packets are not adjusted.

2020-04-30 Thread Dale Curtis
Ping for this patch. Thanks - dale On Thu, Apr 23, 2020 at 4:33 PM Dale Curtis wrote: > This is a patch Chromium has carried for a while, we forgot to send it > upstream. 7546ac2fee4 made it so that the start_time for mp3 files is > adjusted for skip_samples. However, this appears

Re: [FFmpeg-devel] [PATCH] [libavformat] Avoid integer overflow on start_time with skip_samples.

2020-04-30 Thread Dale Curtis
stions welcome... av_maybe_add_ts? On Thu, Apr 30, 2020 at 1:17 PM Dale Curtis wrote: > This applies the same workaround used elsewhere in the file for handling > overflow of addition. > > Signed-off-by: Dale Curtis > --- > libavformat/utils.c | 15 +++ > 1 file cha

[FFmpeg-devel] [PATCH] [libavformat] Avoid integer overflow on start_time with skip_samples.

2020-04-30 Thread Dale Curtis
This applies the same workaround used elsewhere in the file for handling overflow of addition. Signed-off-by: Dale Curtis --- libavformat/utils.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) no_start_time_overflow.patch Description: Binary data

[FFmpeg-devel] [PATCH] Don't adjust start time for MP3 files; packets are not adjusted.

2020-04-23 Thread Dale Curtis
officially start. Since the samples were deleted without adjusting timestamps though, the true start_time is still 0. Other formats like MP4 with edit lists will adjust both the start time and the timestamps of subsequent packets to avoid this issue. Signed-off-by: Dale Curtis

Re: [FFmpeg-devel] [PATCH] Don't trigger errors for multiple id3 tags.

2020-02-21 Thread Dale Curtis
On Fri, Feb 21, 2020 at 12:54 PM Dale Curtis wrote: > On Fri, Feb 21, 2020 at 11:26 AM Andreas Rheinhardt < > andreas.rheinha...@gmail.com> wrote: > >> I doubt that this patch still applies as-is because of >> e2307f4ff197646a7feee0edbcdd2d3262932676. >> >>

Re: [FFmpeg-devel] [PATCH] Don't trigger errors for multiple id3 tags.

2020-02-21 Thread Dale Curtis
84e95470dc Mon Sep 17 00:00:00 2001 From: Dale Curtis Date: Fri, 21 Feb 2020 12:53:30 -0800 Subject: [PATCH] Don't trigger errors for multiple id3 tags. Such errors may make sense for specific formats, but general parsing logic shouldn't be treating these as errors regardless of the er

Re: [FFmpeg-devel] [PATCH] Don't trigger errors for multiple id3 tags.

2020-02-21 Thread Dale Curtis
+John Rummell just noticed this patch never landed upstream. Can this be landed? - dale On Thu, Feb 28, 2019 at 1:58 PM Dale Curtis wrote: > Such errors may make sense for specific formats, but general parsing > logic shouldn't be treating these as errors regardless of the error &g

Re: [FFmpeg-devel] Fix undefined behavior in ff_configure_buffers_for_index()

2020-02-10 Thread Dale Curtis
On Thu, Feb 6, 2020 at 3:38 PM Michael Niedermayer wrote: > On Thu, Jan 30, 2020 at 11:23:07AM -0800, Dale Curtis wrote: > > On Wed, Jan 29, 2020 at 10:23 PM Michael Niedermayer > > > wrote: > > > > > so i think it works but maybe ive missed something, for wh

Re: [FFmpeg-devel] Fix undefined behavior in ff_configure_buffers_for_index()

2020-02-06 Thread Dale Curtis
Bump to apply? - dale On Thu, Jan 30, 2020 at 3:21 PM Dale Curtis wrote: > On Thu, Jan 30, 2020 at 11:23 AM Dale Curtis > wrote: > >> On Wed, Jan 29, 2020 at 10:23 PM Michael Niedermayer >> wrote: >> >>> so i think it works but maybe ive missed somethin

Re: [FFmpeg-devel] Fix undefined behavior in ff_configure_buffers_for_index()

2020-01-30 Thread Dale Curtis
On Wed, Jan 29, 2020 at 10:23 PM Michael Niedermayer wrote: > so i think it works but maybe ive missed something, for which values > of e2_pts do you see a problem with e1_pts = INT64_MIN? > For e1_pts = INT64_MIN and e2_pts >= 0 you end up with a negative int64_t result for e2_pts - (uint64_t)e

Re: [FFmpeg-devel] Fix undefined behavior in ff_configure_buffers_for_index()

2020-01-29 Thread Dale Curtis
On Wed, Jan 29, 2020 at 4:55 AM Michael Niedermayer wrote: > simpler solution, and also behaves arithmetically more correct when the > overflow happens in the othert direction: > > av_assert0(time_tolerance >= 0); > > if (e2_pts < e1_pts || e2_pts - (uint64_t)e1_pts < time_tolerance) > Does that

  1   2   3   >