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
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
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
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
>
atom.size / 8.
Signed-off-by: Dale Curtis
From 3e1663d84068ff7615f7e84fa1c1122729a531da Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Thu, 30 Aug 2018 15:18:25 -0700
Subject: [PATCH] Error on too large stsd entry counts.
Entries are always at least 8 bytes per the parsing code, so if we
see an
Found by ClusterFuzz, https://crbug.com/879852
From 68614e9a099ee4ae754da5fa36fbb6a570f4aa73 Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Fri, 7 Sep 2018 15:37:09 -0700
Subject: [PATCH] Don't calculate duration using AV_NOPTS_VALUE for start_time.
Found by ClusterFuzz, https://crbu
These tables represent ~70k so moving the allocation to when
they're actually used reduces memory usage in cases where the
h264 decoder isn't used.
From e1cbe52a1f41a39698136efb4695d8d019117853 Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Fri, 31 Aug 2018 16:50:23 -0700
Subje
On Sat, Sep 8, 2018 at 5:49 PM Michael Niedermayer
wrote:
> dont all modern OS assign physical memory only once something is stored
> in these tables?
>
This seems to be correct. I was misreading the tooling which indicated
these were taking up size. So this patch can be abandoned. Sorry for the
On Fri, Oct 19, 2018 at 4:50 PM James Almer wrote:
> +s.n_tile_threads = dav1d->tile_threads;
> +s.n_frame_threads = dav1d->frame_threads;
>
Did you consider using the AVCodecContext.threads value along
AVCodecContext.thread_type flags? That seems to be how this is handled
elsewhere.
-
The following warnings show up when compiling with clang:
../../third_party/ffmpeg/libavcodec/libdav1d.c:92:24: error: suggest braces
around initialization of subobject [-Werror,-Wmissing-braces]
Dav1dPicture p = { 0 };
^
{}
../../third_party/ffmpeg
One more piece of feedback, this is not obeying the
AVCodecContext.get_buffer2 API.
- dale
On Fri, Oct 26, 2018 at 3:31 PM Dale Curtis wrote:
> The following warnings show up when compiling with clang:
> ../../third_party/ffmpeg/libavcodec/libdav1d.c:92:24: error: suggest
> brac
On Fri, Oct 26, 2018 at 4:00 PM James Almer wrote:
> On 10/26/2018 7:50 PM, Dale Curtis wrote:
> > One more piece of feedback, this is not obeying the
> > AVCodecContext.get_buffer2 API.
>
> It's not using it on purpose, wrapping the buffers dav1d allocated
> itse
Yes, all your suggestions silence the errors. Thanks!
- dale
On Fri, Oct 26, 2018 at 4:05 PM James Almer wrote:
> On 10/26/2018 7:31 PM, Dale Curtis wrote:
> > The following warnings show up when compiling with clang:
> > ../../third_party/ffmpeg/libavcodec/libdav1d.c:92:24:
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
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
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
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
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
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
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
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
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
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 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
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: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
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
_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 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
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
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 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
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
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
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
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 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
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 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 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 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:
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 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
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
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
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
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(-)
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:
>> >
.
> > 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
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
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
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 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
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 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
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 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 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
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
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/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:
> Avoids overflow from fuzzed skip_samples values.
>
> Signed-off-by: Dale Curtis
> ---
> libavformat/utils.c | 4 ++--
> 1 file changed, 2 insertio
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
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
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
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 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
Was there a reason this never landed? I sympathize with the complexity of
the format, but since AVIF has adopted it as well, it'd be nice to have
ffmpeg support.
- dale
On Sat, Aug 19, 2017 at 2:40 AM Carl Eugen Hoyos wrote:
> 2017-08-19 9:24 GMT+02:00 Rodger Combs :
>
> > AVInputFormat ff_mov
On Wed, Oct 30, 2019 at 1:17 PM Carl Eugen Hoyos wrote:
> https://github.com/Swaraj1998/FFmpeg
>
> (Roger's patch sadly did not work with real-world files)
Thanks Carl! That patch looks good. I'll test it out. Is Swaraj still
planning to send that for review later?
- dale
_
On Thu, Oct 31, 2019 at 1:32 AM Swaraj Hota wrote:
> Yes I will send the patch soon for review. Still a few things left to do.
>
> Swaraj
>
Great! Let me know if there's anything I can help with. If you need some
AVIF samples they can be found here:
https://github.com/AOMediaCodec/av1-avif/tree/
On Fri, Nov 1, 2019 at 4:14 AM Swaraj Hota wrote:
> Sure. Thanks for the samples!
> I have not currently tested the patch with avif format, was only focused on
> heif. But as the only difference is the decoder (?), this support could be
> easily added. I'll try to add it but as I have been workin
On Fri, Nov 1, 2019 at 4:46 PM Carl Eugen Hoyos wrote:
> Testing would be helpful.
>
>
Works for AVIF after adding the line I proposed as well as setting
codecpar->width/height for the stream based on ispe. Breaks AVIFS files
that were previously demuxing as mp4 w/ video track, i.e.,
https://gith
On Tue, Nov 12, 2019 at 1:27 AM Carl Eugen Hoyos wrote:
> > Breaks AVIFS files
> > that were previously demuxing as mp4 w/ video track,
>
> Does it only break them once above change was made or also in the existing
> patch?
> (Sorry, I am still travelling in Japan without computer.)
>
Only after
When e2_pts == INT64_MIN and e1_pts >= 0 the calculation of
e2_pts - e1_pts will overflow an int64_t. So instead check
for overflow and default to |time_tolerance| if the value
is too large for an int64_t.
Signed-off-by: Dale Curtis
From 412751f4747faf34e3dba088dc55290783eb6bd5 Mon Sep 17 00
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
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
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 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
+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
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
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.
>>
>>
One of our test clips is behaving differently after this patch:
https://cs.chromium.org/chromium/src/media/test/data/bear-320x240-live.webm
The printed log message is:
[matroska,webm @ 0x1516c84f4e00] Invalid length 0xff >
0x12f in parent
Looking through the code I'm unsur
+steve who submitted the original patch.
- dale
On Thu, Feb 21, 2019 at 2:30 PM Dale Curtis wrote:
> One of our test clips is behaving differently after this patch:
> https://cs.chromium.org/chromium/src/media/test/data/bear-320x240-live.webm
>
> The printed log message is:
>
Unknown length has a special encoding which is not uint64_t(-1).
Signed-off-by: Dale Curtis
---
libavformat/matroskadec.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
From 2bf28a1edb54297f44021771b4c3d847c1f923f4 Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Fri, 22
Sent http://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/240418.html -
which passes fate and fixes the issue with our test clip.
- dale
On Fri, Feb 22, 2019 at 12:31 PM Dale Curtis
wrote:
> +steve who submitted the original patch.
>
> - dale
>
>
> On Thu, Feb 21, 2019 at 2
ernal/wpt/webaudio/resources/4ch-440.wav
Signed-off-by: Dale Curtis
From 14c2244631e7d02d6f66a6d5a678125002b89675 Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Thu, 28 Feb 2019 13:51:30 -0800
Subject: [PATCH] Don't trigger errors for multiple id3 tags.
Such errors may make sense fo
with FF_ENABLE_DEPRECATION_WARNINGS.
Signed-off-by: Dale Curtis
From 73a488e07a328d05aa2b507a551b0c1e4b8a81c8 Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Fri, 3 Nov 2017 17:10:55 -0700
Subject: [PATCH] Avoid corrupting diagnostic state with _Pragma changes.
The macros for ICC and MSVC correctly push an
Ping?
On Fri, Nov 3, 2017 at 5:13 PM, Dale Curtis wrote:
> The macros for ICC and MSVC correctly push and pop the diagnostic
> state of the compiler when disabling deprecation warnings. The
> ones for clang/gcc should do the same. Without this, if a blanket
> deprecation warning i
lgtm, fixes the crash and doesn't regress any of our tests.
- dale
On Fri, Nov 17, 2017 at 8:21 AM, John Stebbins
wrote:
> Potentially fixes:
> https://bugs.chromium.org/p/chromium/issues/detail?id=786269#c1
>
> In theory, the crash can be triggered by an invalid stream that has
> either tfdt o
2 << (wrap_bits=64 - 1) does not fit in int64_t; apply the check
used in other places that handle wrap bits to ensure the values
are <= 63.
Signed-off-by: Dale Curtis
From c566067623760a24f729ac5197c20531b9e518ae Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Fri, 17 Nov 2017 13:35
Derp, actually, 2 << 63 doesn't fit in int64_t either, this check should be
< 63. Fixed.
On Fri, Nov 17, 2017 at 1:38 PM, Dale Curtis
wrote:
> 2 << (wrap_bits=64 - 1) does not fit in int64_t; apply the check
> used in other places that handle wrap bits to ens
These tables are static so they should only be initialized once
instead of on every call to ff_mpadsp_init().
Signed-off-by: Dale Curtis
From 70ffbeb41f0432c72701f6147385e9aa47bf8419 Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Fri, 17 Nov 2017 14:51:09 -0800
Subject: [PATCH] [mpegaudio
Should be unconditionally freed at the end of mov_fix_index() in case it
hasn't been used during the fix up.
Signed-off-by: Dale Curtis
From bbdf90542a98bb297d4143949e3281500815d0b1 Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Fri, 17 Nov 2017 14:53:25 -0800
Subject: [PATCH] [mov] Fix
Curtis
From 0373fed23fb495161267607230e99c8ed36e444a Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Fri, 17 Nov 2017 16:05:30 -0800
Subject: [PATCH] [mpeg4video] Fix undefined shift on assumed 8-bit input.
decode_user_data() attempts to create an integer |build|
value with 8 bits of spacing
On Fri, Nov 17, 2017 at 6:22 PM, Michael Niedermayer wrote:
>
> Not sure what is best but
> throwing part of the version silently away is not correct
> most likely erroring out and asking for a sample video to be uploaded
> would make sense if such a file is encountered
I'm using the same workar
Derp, that's the wrong comment for this; I meant that for another thread.
Returning an error for optional user data seems a bit harsh, but if that's
what you want, I'm happy to change it. Please let me know if this is the
route you want to take.
- dale
On Mon, Nov 20, 2017 at
On Sat, Nov 18, 2017 at 2:44 AM, Michael Niedermayer wrote:
>
> this would skip the code for wrap_bits >= 63, this does not look
> correct
>
Why do you think that's incorrect? The max int64_t value is 1 << 63 and 2
<< 63 == 1 << 64 ?
- dale
___
ffmpeg-
Without this there can be multiple memory leaks with unknown ogg streams.
- dale
From 4fc9d288c50891a9740facc549c895da066af71b Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Mon, 20 Nov 2017 12:07:57 -0800
Subject: [PATCH] [ogg] Close ogg stream upon error when using AV_EF_EXPLODE.
Without
On Mon, Nov 20, 2017 at 12:40 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:
> On Mon, Nov 20, 2017 at 12:05:05PM -0800, Dale Curtis wrote:
> > On Sat, Nov 18, 2017 at 2:44 AM, Michael Niedermayer
> > > wrote:
> > >
> > > this would skip the co
1 - 100 of 217 matches
Mail list logo
