2018-01-01 16:17 GMT+01:00 Michael Niedermayer :
> On Sun, Dec 31, 2017 at 10:35:28PM +0100, Carl Eugen Hoyos wrote:
>> 2017-12-31 22:26 GMT+01:00 Carl Eugen Hoyos :
>> > 2017-12-31 22:17 GMT+01:00 Michael Niedermayer :
>> >> On Sat, Dec 30, 2017 at 02:36:39PM +0100, Carl Eugen Hoyos wrote:
>> >>>
On Sun, Dec 31, 2017 at 10:35:28PM +0100, Carl Eugen Hoyos wrote:
> 2017-12-31 22:26 GMT+01:00 Carl Eugen Hoyos :
> > 2017-12-31 22:17 GMT+01:00 Michael Niedermayer :
> >> On Sat, Dec 30, 2017 at 02:36:39PM +0100, Carl Eugen Hoyos wrote:
> >>> 2017-12-29 23:37 GMT+01:00 Carl Eugen Hoyos :
> >>> > 2
2017-12-31 22:26 GMT+01:00 Carl Eugen Hoyos :
> 2017-12-31 22:17 GMT+01:00 Michael Niedermayer :
>> On Sat, Dec 30, 2017 at 02:36:39PM +0100, Carl Eugen Hoyos wrote:
>>> 2017-12-29 23:37 GMT+01:00 Carl Eugen Hoyos :
>>> > 2017-11-28 21:32 GMT+01:00 Michael Niedermayer :
>>> >> On Mon, Nov 27, 2017
2017-12-31 22:17 GMT+01:00 Michael Niedermayer :
> On Sat, Dec 30, 2017 at 02:36:39PM +0100, Carl Eugen Hoyos wrote:
>> 2017-12-29 23:37 GMT+01:00 Carl Eugen Hoyos :
>> > 2017-11-28 21:32 GMT+01:00 Michael Niedermayer :
>> >> On Mon, Nov 27, 2017 at 05:24:14AM +0100, Carl Eugen Hoyos wrote:
>> >
>>
On Sat, Dec 30, 2017 at 02:36:39PM +0100, Carl Eugen Hoyos wrote:
> 2017-12-29 23:37 GMT+01:00 Carl Eugen Hoyos :
> > 2017-11-28 21:32 GMT+01:00 Michael Niedermayer :
> >> On Mon, Nov 27, 2017 at 05:24:14AM +0100, Carl Eugen Hoyos wrote:
> >
> >>> for (i = 0; i < entries && !pb->eof_reached; i
2017-12-29 23:37 GMT+01:00 Carl Eugen Hoyos :
> 2017-11-28 21:32 GMT+01:00 Michael Niedermayer :
>> On Mon, Nov 27, 2017 at 05:24:14AM +0100, Carl Eugen Hoyos wrote:
>
>>> for (i = 0; i < entries && !pb->eof_reached; i++) {
>>> -int sample_duration;
>>> +int sample_duration, re
2017-11-28 21:32 GMT+01:00 Michael Niedermayer :
> On Mon, Nov 27, 2017 at 05:24:14AM +0100, Carl Eugen Hoyos wrote:
>> for (i = 0; i < entries && !pb->eof_reached; i++) {
>> -int sample_duration;
>> +int sample_duration, ret;
>> unsigned int sample_count;
>> +
2017-12-29 22:32 GMT+01:00 Derek Buitenhuis :
> Completely Unrelated: Multiple types of atoms are similar to the stts atom,
> in that they contain a coded number of entries we allocate - maybe we should
> consistently apply this sort of allocation strategy to them, too (out of
> scope of this patc
On 12/29/2017 9:32 PM, Derek Buitenhuis wrote:
> Because the buffer is now grown exponentially (by a factor of 2 every
> time it is resizes), it's possible that it ends up with almost double
> the size of 'entries' after resizes.
>
> For example, consider a valid MP4 file with (1024 * 1024 + 1) en
On 12/29/2017 8:42 PM, Carl Eugen Hoyos wrote:
> Sorry, I don't understand this sentence - could you try with
> other words?
Because the buffer is now grown exponentially (by a factor of 2 every
time it is resizes), it's possible that it ends up with almost double
the size of 'entries' after resiz
2017-12-29 21:35 GMT+01:00 Derek Buitenhuis :
> FFMIN(sc->stts_count * 2, entries) could in theory end up using
> more memory for legitimate large files though, due to exponential
> buffer growth. Is that something worth caring about?
Sorry, I don't understand this sentence - could you try with
o
On 12/29/2017 8:25 PM, Carl Eugen Hoyos wrote:
> 2017-12-29 20:47 GMT+01:00 Derek Buitenhuis :
>> On 12/29/2017 1:10 AM, Carl Eugen Hoyos wrote:
>>> New patch attached, only tested with fate.
>>
>>> +if (INT_MAX / sizeof(*sc->stts_data) <= entries)
>
> This is an arbitrary limit...
Yeah, true
2017-12-29 20:47 GMT+01:00 Derek Buitenhuis :
> On 12/29/2017 1:10 AM, Carl Eugen Hoyos wrote:
>> New patch attached, only tested with fate.
>
>> +if (INT_MAX / sizeof(*sc->stts_data) <= entries)
This is an arbitrary limit...
>> return AVERROR(ENOMEM);
>
> Should probably be somethin
On 12/29/2017 1:10 AM, Carl Eugen Hoyos wrote:
> New patch attached, only tested with fate.
> +if (INT_MAX / sizeof(*sc->stts_data) <= entries)
> return AVERROR(ENOMEM);
Should probably be something thing AVERROR(EINVAL), I think.
> +sc->stts_count = FFMIN(1024 * 1024, entries);
2017-11-28 21:32 GMT+01:00 Michael Niedermayer :
> On Mon, Nov 27, 2017 at 05:24:14AM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch avoids allocations >1GB for (short and) invalid mov
>> files with only reasonable speed impact.
>>
>> Please review, Carl Eugen
>
>> mov.c | 16 +++
On Mon, Nov 27, 2017 at 05:24:14AM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch avoids allocations >1GB for (short and) invalid mov
> files with only reasonable speed impact.
>
> Please review, Carl Eugen
> mov.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletion
Hi!
Attached patch avoids allocations >1GB for (short and) invalid mov
files with only reasonable speed impact.
Please review, Carl Eugen
From 0d243bad5fdd9850ff41d49a32a06274a3cd9756 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 27 Nov 2017 05:13:25 +0100
Subject: [PATCH] lavf/mov:
17 matches
Mail list logo
