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, Sep 28, 202
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
, 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 directly from the str
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 t
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
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/libavformat/mov.c b
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
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 clause mo
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 ==
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
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 link
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
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-off-by:
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
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:
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
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
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
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(-)
From
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
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-off
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
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 with
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, Da
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.
>>
uiltin() 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 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
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
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 to be av_saturat
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 few pla
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
s 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 changed,
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 error
recogn
+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
> re
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 -
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
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 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
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.,
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
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:
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
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
/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 for specific
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
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
+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:
>
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
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:
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
> itself
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
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 };
^
{}
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.
-
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
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
Subject: [PATCH
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://crbug.com
to 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
This field is a uint16_t, see docs:
http://opus-codec.org/docs/opus_in_isobmff.html#4.3.2
Signed-off-by: Dale Curtis
From 7f1588bc92ef4a70025aa140a8e660a36875c89c Mon Sep 17 00:00:00 2001
From: Dale Curtis
Date: Tue, 21 Aug 2018 15:42:31 -0700
Subject: [PATCH] Correct opus-in-mp4 pre-skip
On Tue, Apr 17, 2018 at 6:00 AM Derek Buitenhuis <derek.buitenh...@gmail.com>
wrote:
> On 4/17/2018 12:28 AM, Dale Curtis wrote:
> > Necessary for clang-cl cross compiling builds to work on Linux.
>
> Looks fairly reasonable, I think.
>
> Are you manually ov
1 - 100 of 187 matches
Mail list logo
