On Thu, 2011-12-22 at 17:18 +0100, Luca Barbato wrote:
> On 22/12/11 13:45, Tomas Härdin wrote:
> > It's also hard to define "crazy" when it comes to MXF. After all, we're
> > talking about a format that allows indexing individual scanlines in raw
> > footage..
>
> So we should accept 64bit/sizeof
On 2011-12-22 16:20:55 +, Måns Rullgård wrote:
> Luca Barbato writes:
>
> > On 22/12/11 13:45, Tomas Härdin wrote:
> >> It's also hard to define "crazy" when it comes to MXF. After all, we're
> >> talking about a format that allows indexing individual scanlines in raw
> >> footage..
> >
> > S
Luca Barbato writes:
> On 22/12/11 13:45, Tomas Härdin wrote:
>> It's also hard to define "crazy" when it comes to MXF. After all, we're
>> talking about a format that allows indexing individual scanlines in raw
>> footage..
>
> So we should accept 64bit/sizeof(the thing) values on 64bit architec
On 22/12/11 13:45, Tomas Härdin wrote:
It's also hard to define "crazy" when it comes to MXF. After all, we're
talking about a format that allows indexing individual scanlines in raw
footage..
So we should accept 64bit/sizeof(the thing) values on 64bit architectures?
lu
--
Luca Barbato
Gento
On Thu, 2011-12-22 at 11:52 +, Måns Rullgård wrote:
> Tomas Härdin writes:
>
> > On Wed, 2011-12-21 at 17:56 +0100, Janne Grunau wrote:
> >> On 2011-12-21 15:47:24 +0100, Tomas Härdin wrote:
> >> > On Wed, 2011-12-21 at 15:28 +0100, Luca Barbato wrote:
> >> > > On 21/12/11 14:58, Tomas Härdin
Tomas Härdin writes:
> On Wed, 2011-12-21 at 17:56 +0100, Janne Grunau wrote:
>> On 2011-12-21 15:47:24 +0100, Tomas Härdin wrote:
>> > On Wed, 2011-12-21 at 15:28 +0100, Luca Barbato wrote:
>> > > On 21/12/11 14:58, Tomas Härdin wrote:
>> > > > I hope you made sure the code still work fine on 32
On Wed, 2011-12-21 at 17:56 +0100, Janne Grunau wrote:
> On 2011-12-21 15:47:24 +0100, Tomas Härdin wrote:
> > On Wed, 2011-12-21 at 15:28 +0100, Luca Barbato wrote:
> > > On 21/12/11 14:58, Tomas Härdin wrote:
> > > > I hope you made sure the code still work fine on 32-bit systems,
> > > > especia
On 2011-12-21 15:47:24 +0100, Tomas Härdin wrote:
> On Wed, 2011-12-21 at 15:28 +0100, Luca Barbato wrote:
> > On 21/12/11 14:58, Tomas Härdin wrote:
> > > I hope you made sure the code still work fine on 32-bit systems,
> > > especially when entry counts are ~10^9.
> >
> > Do you have a sample fo
On 12/20/2011 05:43 PM, Janne Grunau wrote:
> changed memory alloction from the pointless av_calloc
> to av_mallocz
I hope you made sure the code still work fine on 32-bit systems,
especially when entry counts are ~10^9.
On Wed, 2011-12-21 at 11:56 +0100, Benjamin Larsson wrote:
> On 12/20/2011 0
On Wed, 2011-12-21 at 15:28 +0100, Luca Barbato wrote:
> On 21/12/11 14:58, Tomas Härdin wrote:
> > I hope you made sure the code still work fine on 32-bit systems,
> > especially when entry counts are ~10^9.
>
> Do you have a sample for that?
FATE sample with a single bit flipped at 0x1e9d, turn
On 21 December 2011 15:28, Luca Barbato wrote:
> On 21/12/11 14:58, Tomas Härdin wrote:
>>
>> I hope you made sure the code still work fine on 32-bit systems,
>> especially when entry counts are ~10^9.
>
>
> Do you have a sample for that?
Preferably one that doesn't require a freight ship with ha
On 21/12/11 14:58, Tomas Härdin wrote:
I hope you made sure the code still work fine on 32-bit systems,
especially when entry counts are ~10^9.
Do you have a sample for that?
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
___
libav
Benjamin Larsson writes:
>> You could have this entire series as a topic branch then git merge
>> --no-ff so future bisects are less likely to end up in the middle of it.
>> I'm assuming git-bisect is clever about such things.
>>
>> /Tomas
>
> Lets say you actually want to bisect it. Then it woul
On 12/21/2011 03:07 PM, Måns Rullgård wrote:
I'm slightly more in
favor of committing as is to preserve history.
What's the point in preserving history that doesn't work?
That is not the case here.
By extension,
we should preserve every save of every file by any developer. After
all, tho
On 2011-12-21 14:07:43 +, Måns Rullgård wrote:
> Benjamin Larsson writes:
>
> > On 12/20/2011 05:43 PM, Janne Grunau wrote:
> >> Hi,
> >>
> >> applied mostly as they are in FFmpeg. I've cleaned some commit
> >> messages, changed memory alloction from the pointless av_calloc
> >> to av_mallocz
Benjamin Larsson writes:
> On 12/20/2011 05:43 PM, Janne Grunau wrote:
>> Hi,
>>
>> applied mostly as they are in FFmpeg. I've cleaned some commit
>> messages, changed memory alloction from the pointless av_calloc
>> to av_mallocz, fixed potential memleaks on allocation errors.
>>
>> Janne
>
> Al
You could have this entire series as a topic branch then git merge
--no-ff so future bisects are less likely to end up in the middle of it.
I'm assuming git-bisect is clever about such things.
/Tomas
Lets say you actually want to bisect it. Then it would make much more
sense to have it. I'm
On 12/20/2011 05:43 PM, Janne Grunau wrote:
> changed memory alloction from the pointless av_calloc
> to av_mallocz
I hope you made sure the code still work fine on 32-bit systems,
especially when entry counts are ~10^9.
On Wed, 2011-12-21 at 11:56 +0100, Benjamin Larsson wrote:
> On 12/20/2011 0
On 12/20/2011 05:43 PM, Janne Grunau wrote:
Hi,
applied mostly as they are in FFmpeg. I've cleaned some commit
messages, changed memory alloction from the pointless av_calloc
to av_mallocz, fixed potential memleaks on allocation errors.
Janne
All in all the set looks good. But lots of index c
Hi,
applied mostly as they are in FFmpeg. I've cleaned some commit
messages, changed memory alloction from the pointless av_calloc
to av_mallocz, fixed potential memleaks on allocation errors.
Janne
___
libav-devel mailing list
libav-devel@libav.org
ht
20 matches
Mail list logo
