Am Mi., 1. Apr. 2020 um 21:30 Uhr schrieb Carl Eugen Hoyos :
> It seems to me that this was forgotten when the codec was originally ported.
Patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listi
Am Do., 2. Apr. 2020 um 20:52 Uhr schrieb Nicolas George :
>
> Derek Buitenhuis (12020-04-02):
> > Interesting... Altivec isn't standards compliant? TIL.
>
> What I read is Apple isn't standards compliant. I knew that.
"Apple" as in the people who launched ppc64el Linux?
Can we stop this?
Carl E
On 02/04/2020 19:52, Nicolas George wrote:
> What I read is Apple isn't standards compliant. I knew that.
>
> This fix seems harmless enough.
The fix in the linked archive? I agree.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
Derek Buitenhuis (12020-04-02):
> Interesting... Altivec isn't standards compliant? TIL.
What I read is Apple isn't standards compliant. I knew that.
This fix seems harmless enough.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
On 02/04/2020 19:23, Thierry Foucu wrote:
> And here is the patch they used to fix it:
> https://mails.dpdk.org/archives/dev/2018-August/110485.html
Interesting... Altivec isn't standards compliant? TIL.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-deve
On Thu, Apr 2, 2020 at 11:18 AM Thierry Foucu wrote:
>
>
> On Thu, Apr 2, 2020 at 11:11 AM Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
>
>> On 02/04/2020 17:47, Moritz Barsnick wrote:
>> > I though this was the practical argument?:
>> >
>> > http://ffmpeg.org/pipermail/ffmpeg-devel/20
Am Do., 2. Apr. 2020 um 20:11 Uhr schrieb Derek Buitenhuis
:
>
> On 02/04/2020 17:47, Moritz Barsnick wrote:
> > I though this was the practical argument?:
> >
> > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html
> > http://trac.ffmpeg.org/ticket/8591
>
> It isn't really clear to me
On Thu, Apr 2, 2020 at 11:11 AM Derek Buitenhuis
wrote:
> On 02/04/2020 17:47, Moritz Barsnick wrote:
> > I though this was the practical argument?:
> >
> > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html
> > http://trac.ffmpeg.org/ticket/8591
>
> It isn't really clear to me what
On 02/04/2020 17:47, Moritz Barsnick wrote:
> I though this was the practical argument?:
>
> http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259430.html
> http://trac.ffmpeg.org/ticket/8591
It isn't really clear to me what the actual problem is from the
description - how is bool fundementally
Am Do., 2. Apr. 2020 um 18:53 Uhr schrieb Moritz Barsnick :
>
> On Thu, Apr 02, 2020 at 15:33:02 +0200, Nicolas George wrote:
> > If there are no actual practical arguments against bool, from either you
> > or somebody else, then I suggest we leave this one as it is and no
> > longer reject patches
On Thu, Apr 02, 2020 at 15:33:02 +0200, Nicolas George wrote:
> If there are no actual practical arguments against bool, from either you
> or somebody else, then I suggest we leave this one as it is and no
> longer reject patches based on this.
I though this was the practical argument?:
http://ff
On 4/2/20, Nicolas George wrote:
> Paul B Mahol (12020-04-02):
>> No code in FFmpeg use it.
>> And it was disallowed before and should be now.
>
> There are many features that were not used and have become used when the
> need happened. Named initializers, for example. Compound literals.
>
> If th
On Thu, 2 Apr 2020 at 14:24, Paul B Mahol wrote:
> On 4/2/20, Derek Buitenhuis wrote:
> > On 02/04/2020 10:41, Paul B Mahol wrote:
> >> I do not care, bool is evil and should never be used.
> >
> > Why? 'We don't like it' isn't a technical reason.
> >
> > Also, FFmpeg already uses plenty of C99
On 02/04/2020 14:24, Paul B Mahol wrote:
> No code in FFmpeg use it.
> And it was disallowed before and should be now.
'Because we've always done it that way' is not a valid technical argument.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
Paul B Mahol (12020-04-02):
> No code in FFmpeg use it.
> And it was disallowed before and should be now.
There are many features that were not used and have become used when the
need happened. Named initializers, for example. Compound literals.
If there are no actual practical arguments against
On 4/2/20, Derek Buitenhuis wrote:
> On 02/04/2020 10:41, Paul B Mahol wrote:
>> I do not care, bool is evil and should never be used.
>
> Why? 'We don't like it' isn't a technical reason.
>
> Also, FFmpeg already uses plenty of C99 features and thus
> requires a C99 compiler. What is so inherentl
On 02/04/2020 10:41, Paul B Mahol wrote:
> I do not care, bool is evil and should never be used.
Why? 'We don't like it' isn't a technical reason.
Also, FFmpeg already uses plenty of C99 features and thus
requires a C99 compiler. What is so inherently evil about a boolean
type that it must not be
On 4/2/20, Kieran Kunhya wrote:
> On Thu, 2 Apr 2020 at 08:53, Paul B Mahol wrote:
>
>> On 4/1/20, Thierry Foucu wrote:
>> > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos
>> wrote:
>> >
>> >> Hi!
>> >>
>> >> It seems to me that this was forgotten when the codec was originally
>> >> ported.
>
On Thu, 2 Apr 2020 at 08:53, Paul B Mahol wrote:
> On 4/1/20, Thierry Foucu wrote:
> > On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos
> wrote:
> >
> >> Hi!
> >>
> >> It seems to me that this was forgotten when the codec was originally
> >> ported.
> >>
> >
> > why removing "stdbool.h"?
> > it
Am Mi., 1. Apr. 2020 um 23:23 Uhr schrieb Thierry Foucu :
>
> On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos wrote:
>
> > Hi!
> >
> > It seems to me that this was forgotten when the codec was originally
> > ported.
> >
>
> why removing "stdbool.h"?
We never liked it (and I am sure there are exa
On 4/1/20, Thierry Foucu wrote:
> On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos wrote:
>
>> Hi!
>>
>> It seems to me that this was forgotten when the codec was originally
>> ported.
>>
>
> why removing "stdbool.h"?
> it was defined in 2001? so, most compiler should support it..
> Should we not
On Wed, Apr 1, 2020 at 12:31 PM Carl Eugen Hoyos wrote:
> Hi!
>
> It seems to me that this was forgotten when the codec was originally
> ported.
>
why removing "stdbool.h"?
it was defined in 2001? so, most compiler should support it..
Should we not check for the compiler support of it and if not
Hi!
It seems to me that this was forgotten when the codec was originally ported.
Please comment, Carl Eugen
From 3077d14fed1c19afbcdfd8282fac2a7f1bf3492d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Wed, 1 Apr 2020 21:28:09 +0200
Subject: [PATCH] lavc/sbc: Remove bool usage.
---
libav
23 matches
Mail list logo
