Hi Derek,
On Wed, 16 Dec 2015 17:16:26 +, Derek Buitenhuis wrote:
> On 12/15/2015 10:39 PM, Jean Delvare wrote:
> > I see two completely different things.
> >
> > The change I proposed is specific to one function, only changes const
> > vs non-const, and the object under discussion is being a
On 12/16/15, Derek Buitenhuis wrote:
> On 12/15/2015 10:39 PM, Jean Delvare wrote:
>> I see two completely different things.
>>
>> The change I proposed is specific to one function, only changes const
>> vs non-const, and the object under discussion is being accessed for
>> reading only (thus the
On 12/15/2015 10:39 PM, Jean Delvare wrote:
> I see two completely different things.
>
> The change I proposed is specific to one function, only changes const
> vs non-const, and the object under discussion is being accessed for
> reading only (thus the const pointer.) It would remove a memcpy but
Hi Derek,
On Tue, 15 Dec 2015 17:39:23 +, Derek Buitenhuis wrote:
> On 12/15/2015 5:23 PM, Jean Delvare wrote:
> > Looks like something different from what we were discussing here.
>
> In which way?
>
> That patch fixes pointer aliasing in the same way yours breaks it, AFAICT?
I see two com
On 12/15/2015 5:23 PM, Jean Delvare wrote:
> Looks like something different from what we were discussing here.
In which way?
That patch fixes pointer aliasing in the same way yours breaks it, AFAICT?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@f
On Tue, 15 Dec 2015 16:56:02 +, Derek Buitenhuis wrote:
> On 12/15/2015 10:44 AM, Jean Delvare wrote:
> > Originally I proposed this patch for performance reasons and also
> > because I think it makes the code more readable. But seeing how the
> > same cast is already present everywhere in the
On 12/15/2015 10:44 AM, Jean Delvare wrote:
> Originally I proposed this patch for performance reasons and also
> because I think it makes the code more readable. But seeing how the
> same cast is already present everywhere in the ffmpeg code, I would now
> also invoke consistency. There's no ratio
Hi Hendrik,
On Tue, 15 Dec 2015 11:31:57 +0100, Hendrik Leppkes wrote:
> On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer
> wrote:
> > On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
> >> Also I can see 12 occurrences of the same cast for this parameter of
> >> function av_ima
On Tue, 15 Dec 2015 11:20:40 +0100, Michael Niedermayer wrote:
> yes, I have no real oppinion on this except that C is insane or I am
C is insane, who would dare to argue otherwise? ;-)
More than the language itself, the fact that the compilers think they
can reorder instructions the way they lik
On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer wrote:
> On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
>> Hallo Michael,
>>
>> On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote:
>> > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
>> > > As I underst
On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
> Hallo Michael,
>
> On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote:
> > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
> > > As I understand it, the temporary stack buffer "src_data" was
> > > introduced s
Hallo Michael,
On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote:
> On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
> > As I understand it, the temporary stack buffer "src_data" was
> > introduced solely to avoid a compiler warning. I believe that a better
> > way to solv
On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
> As I understand it, the temporary stack buffer "src_data" was
> introduced solely to avoid a compiler warning. I believe that a better
> way to solve this warning it to explicitly cast src->data. This
> should be somewhat faster, and j
As I understand it, the temporary stack buffer "src_data" was
introduced solely to avoid a compiler warning. I believe that a better
way to solve this warning it to explicitly cast src->data. This
should be somewhat faster, and just as safe.
Signed-off-by: Jean Delvare
Cc: Anton Khirnov
---
lib
14 matches
Mail list logo
