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
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:
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
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
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
>
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
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:
>> >
>> >
>>
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
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
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
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
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-
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
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
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
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
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
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
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
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
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
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
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
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
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
___
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
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
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.
>
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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(+)
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
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
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
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
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
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
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
>
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
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
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
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
.
> > 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
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:
>> >
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(-)
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
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
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
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
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
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:
>
>>
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:
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
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
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
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
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
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
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
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
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
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 |
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
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
_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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>>
>>
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
+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
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
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
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
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 - 100 of 211 matches
Mail list logo