On Thu, Nov 23, 2017 at 3:54 PM, Carl Eugen Hoyos
wrote:
>
> @Dale:
> Could you do that?
>
Thanks to John for putting out a patch for this.
- dale
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2017-11-23 19:45 GMT+01:00 John Stebbins :
> On 11/22/2017 05:26 PM, Carl Eugen Hoyos wrote:
>> 2017-11-23 1:30 GMT+01:00 John Stebbins :
>>> On 11/22/2017 02:36 PM, Carl Eugen Hoyos wrote:
2017-08-24 0:39 GMT+02:00 Dale Curtis :
> -sc->ctts_data[ctts_count].count= count;
On 11/22/2017 05:26 PM, Carl Eugen Hoyos wrote:
> 2017-11-23 1:30 GMT+01:00 John Stebbins :
>> On 11/22/2017 02:36 PM, Carl Eugen Hoyos wrote:
>>> 2017-08-24 0:39 GMT+02:00 Dale Curtis :
>>>
-sc->ctts_data[ctts_count].count= count;
-sc->ctts_data[ctts_count].duration =
2017-11-23 1:30 GMT+01:00 John Stebbins :
> On 11/22/2017 02:36 PM, Carl Eugen Hoyos wrote:
>> 2017-08-24 0:39 GMT+02:00 Dale Curtis :
>>
>>> -sc->ctts_data[ctts_count].count= count;
>>> -sc->ctts_data[ctts_count].duration = duration;
>>> -ctts_count++;
>>> +/* E
On 11/22/2017 02:36 PM, Carl Eugen Hoyos wrote:
> 2017-08-24 0:39 GMT+02:00 Dale Curtis :
>
>> -sc->ctts_data[ctts_count].count= count;
>> -sc->ctts_data[ctts_count].duration = duration;
>> -ctts_count++;
>> +/* Expand entries such that we have a 1-1 mapping with
2017-08-24 0:39 GMT+02:00 Dale Curtis :
> -sc->ctts_data[ctts_count].count= count;
> -sc->ctts_data[ctts_count].duration = duration;
> -ctts_count++;
> +/* Expand entries such that we have a 1-1 mapping with samples. */
> +for (j = 0; j < count; j++)
> +
On Fri, Aug 25, 2017 at 10:18 AM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:
>
> hmm
>
> maybe i misunderstand but assuming we insert a block of dummy blank
> entries (without breaking monotonicity) and keep a pointer to that
> block
>
> then add entries with a av_add_index_entry()
> and
On Thu, Aug 24, 2017 at 10:57:43AM +0200, Michael Niedermayer wrote:
> > From b4b49b6b584b33e1da95a5d72b05fd9134ab28f9 Mon Sep 17 00:00:00 2001
> > From: Dale Curtis
> > Date: Mon, 17 Jul 2017 17:38:09 -0700
> > Subject: [PATCH] Fix trampling of ctts during seeks when sidx support is
> > enabled.
On Thu, Aug 24, 2017 at 05:06:16PM -0700, Dale Curtis wrote:
> On Thu, Aug 24, 2017 at 2:27 AM, Michael Niedermayer > wrote:
>
> >
> > can the insertions be done in groups instead of one at a time ?
> > so that it basically merges 2 lists (O(n)) instead of inserting
> > one at a time O(n^2)
> > ?
On Thu, Aug 24, 2017 at 2:27 AM, Michael Niedermayer wrote:
>
> can the insertions be done in groups instead of one at a time ?
> so that it basically merges 2 lists (O(n)) instead of inserting
> one at a time O(n^2)
> ?
> This would significantly improve the worst case while not needing
> to cha
On Wed, Aug 23, 2017 at 03:39:01PM -0700, Dale Curtis wrote:
> On Sat, Aug 19, 2017 at 3:50 PM, Michael Niedermayer > wrote:
>
> > On Sun, Aug 20, 2017 at 12:48:30AM +0200, Michael Niedermayer wrote:
> > > On Fri, Aug 18, 2017 at 03:57:45PM -0700, Dale Curtis wrote:
> > > > Anything else here? It
On Wed, Aug 23, 2017 at 03:39:01PM -0700, Dale Curtis wrote:
> On Sat, Aug 19, 2017 at 3:50 PM, Michael Niedermayer > wrote:
>
> > On Sun, Aug 20, 2017 at 12:48:30AM +0200, Michael Niedermayer wrote:
> > > On Fri, Aug 18, 2017 at 03:57:45PM -0700, Dale Curtis wrote:
> > > > Anything else here? It
On Mon, Aug 07, 2017 at 12:32:16PM -0700, Dale Curtis wrote:
> On Fri, Aug 4, 2017 at 4:38 PM, Michael Niedermayer
> wrote:
>
> > so theres no easy way to create a smaller file then 64mb ?
> >
>
> Ah no, I didn't realize you had a size limit; I just meant none of the
> existing clips were large
On Sat, Aug 19, 2017 at 3:50 PM, Michael Niedermayer wrote:
> On Sun, Aug 20, 2017 at 12:48:30AM +0200, Michael Niedermayer wrote:
> > On Fri, Aug 18, 2017 at 03:57:45PM -0700, Dale Curtis wrote:
> > > Anything else here? It'd be nice to get this landed soon if no one has
> any
> > > other commen
On Sun, Aug 20, 2017 at 12:48:30AM +0200, Michael Niedermayer wrote:
> On Fri, Aug 18, 2017 at 03:57:45PM -0700, Dale Curtis wrote:
> > Anything else here? It'd be nice to get this landed soon if no one has any
> > other comments.
>
> it appears to not apply cleanly anymore
seems caused by f45441
On Fri, Aug 18, 2017 at 03:57:45PM -0700, Dale Curtis wrote:
> Anything else here? It'd be nice to get this landed soon if no one has any
> other comments.
it appears to not apply cleanly anymore
>
> - dale
>
> On Thu, Aug 10, 2017 at 1:02 PM, Dale Curtis
> wrote:
>
> > On Tue, Aug 8, 2017 a
Anything else here? It'd be nice to get this landed soon if no one has any
other comments.
- dale
On Thu, Aug 10, 2017 at 1:02 PM, Dale Curtis
wrote:
> On Tue, Aug 8, 2017 at 6:48 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>>
>> the fate test seems to fail:
>>
>> did i do some
On Tue, Aug 8, 2017 at 6:48 PM, Michael Niedermayer
wrote:
>
> the fate test seems to fail:
>
> did i do something silly ?
>
Ah no, I did when I remuxed the test file. Updated expectations and test
clip at http://storage.googleapis.com/dalecurtis/buck480p30_na.mp4
- dale
From 6e77ff3deaa6e0ac04
On Mon, Aug 07, 2017 at 12:31:01PM -0700, Dale Curtis wrote:
> On Fri, Aug 4, 2017 at 4:40 PM, Rodger Combs wrote:
>
> > +sc->ctts_data = av_fast_realloc(sc->ctts_data,
> > &sc->ctts_allocated_size, request_size);
> > ^ this line is incorrect; setting realloc's first arg to its return
On Fri, Aug 4, 2017 at 4:40 PM, Rodger Combs wrote:
> +sc->ctts_data = av_fast_realloc(sc->ctts_data,
> &sc->ctts_allocated_size, request_size);
> ^ this line is incorrect; setting realloc's first arg to its return value
> leaks the existing allocation in the OOM case. Since you're do
On Fri, Aug 4, 2017 at 4:38 PM, Michael Niedermayer
wrote:
> so theres no easy way to create a smaller file then 64mb ?
>
Ah no, I didn't realize you had a size limit; I just meant none of the
existing clips were large enough / worked. I've truncated the clip at
http://storage.googleapis.com/dal
+sc->ctts_data = av_fast_realloc(sc->ctts_data,
&sc->ctts_allocated_size, request_size);
^ this line is incorrect; setting realloc's first arg to its return value leaks
the existing allocation in the OOM case. Since you're doing your own
calculation for the desired new size here, you
On Mon, Jul 31, 2017 at 02:29:29PM -0700, Dale Curtis wrote:
> Here's an updated patch with a fate test attached. You'll need to add
> http://storage.googleapis.com/dalecurtis/buck480p30_na.mp4 to the
> fate-suite/mov for this test. This is licensed under creative commons
> attribution, so it shoul
Any comments here? +rodger who wrote the original sidx processing for
review.
- dale
On Mon, Jul 31, 2017 at 3:01 PM, Dale Curtis
wrote:
> Whoops, that patch accidentally reverted to an earlier version. Here's the
> fixed one that works with the mpg sample mentioned above.
>
> - dale
>
> On Mon
Whoops, that patch accidentally reverted to an earlier version. Here's the
fixed one that works with the mpg sample mentioned above.
- dale
On Mon, Jul 31, 2017 at 2:29 PM, Dale Curtis
wrote:
> Here's an updated patch with a fate test attached. You'll need to add
> http://storage.googleapis.com
Here's an updated patch with a fate test attached. You'll need to add
http://storage.googleapis.com/dalecurtis/buck480p30_na.mp4 to the
fate-suite/mov for this test. This is licensed under creative commons
attribution, so it should be fine for tests:
https://peach.blender.org/about/ I tried to use
On Mon, Jul 24, 2017 at 02:32:41PM -0700, Dale Curtis wrote:
> On Thu, Jul 20, 2017 at 5:00 AM, Michael Niedermayer > wrote:
>
> > Hi
> >
> > On Wed, Jul 19, 2017 at 07:30:01PM -0700, Dale Curtis wrote:
> > > Thanks will take a look. Is this test not part of fate? make fate passed
> >
> > no, we
On Thu, Jul 20, 2017 at 5:00 AM, Michael Niedermayer wrote:
> Hi
>
> On Wed, Jul 19, 2017 at 07:30:01PM -0700, Dale Curtis wrote:
> > Thanks will take a look. Is this test not part of fate? make fate passed
>
> no, we should have tests for all (fixed) tickets in fate ideally
> but in reality most
Hi
On Wed, Jul 19, 2017 at 07:30:01PM -0700, Dale Curtis wrote:
> Thanks will take a look. Is this test not part of fate? make fate passed
no, we should have tests for all (fixed) tickets in fate ideally
but in reality most tickets lack a corresponding test
I tried both in outreachy and as well i
I found some samples with ctts and trun boxes, so I've updated the patch to
handle these cases since I don't know how common they are in the wild and
it's an easy fix. I'll send a followup patch if this one is accepted to
remove support for > 1 count ctts entries.
- dale
On Wed, Jul 19, 2017 at 7
Thanks will take a look. Is this test not part of fate? make fate passed
for me. The attached patch fixes this; the issue was that the index entries
are 1 to 1 with ctts values. When samples are added without ctts entries
we'd just initialize a single ctts entry with a count of 5. This left a gap
i
On Tue, Jul 18, 2017 at 11:49:26AM -0700, Dale Curtis wrote:
> Updated patch that fixes other ctts modification code to use the new
> ctts_allocated_size value; I've verified this passes fate.
>
> - dale
>
> On Tue, Jul 18, 2017 at 9:53 AM, Dale Curtis
> wrote:
>
> > Resending as it's own messa
Updated patch that fixes other ctts modification code to use the new
ctts_allocated_size value; I've verified this passes fate.
- dale
On Tue, Jul 18, 2017 at 9:53 AM, Dale Curtis
wrote:
> Resending as it's own message per contribution rules. I've also attached
> the patch in case the formattin
Resending as it's own message per contribution rules. I've also attached
the patch in case the formatting gets trashed.
When sidx box support is enabled, the code will skip reading all
trun boxes (each containing ctts entries for samples inthat box).
If seeks are attempted before all ctts values
34 matches
Mail list logo
