On 4/2/20 2:13 AM, Anton Khirnov wrote:
> Quoting David Bryant (2020-04-01 23:35:13)
>> On 3/31/20 2:47 AM, Anton Khirnov wrote:
> Looking at wavpack, the code looks suspicious to me. You allocate one
> dsdctx per channel at init, but AFAIU the number of channels can change
> at each
> -Original Message-
> From: Fu, Linjie
> Sent: Thursday, April 02, 2020 12:16 PM
> To: FFmpeg development discussions and patches
> Cc: Guo, Yejun
> Subject: RE: [FFmpeg-devel] [PATCH] configure: fix build issue of
> vf_dnn_processing.c when --disable-swscale
>
> > From: ffmpeg-devel
On Thu, Apr 2, 2020 at 5:38 PM Michael Niedermayer
wrote:
> On Wed, Apr 01, 2020 at 12:07:55AM -0400, David Michael wrote:
> > Using a compiler with a different host triplet is considered
> > cross-compiling, even when it is for the same architecture as the
> > build system. With such a
On Wed, Apr 01, 2020 at 03:32:15PM +0800, Ruiling Song wrote:
> Signed-off-by: Ruiling Song
> ---
> libswscale/swscale.c | 16 +---
> libswscale/swscale_internal.h | 5 +
> libswscale/x86/swscale.c | 3 +--
> 3 files changed, 3 insertions(+), 21 deletions(-)
On Wed, Apr 01, 2020 at 12:07:55AM -0400, David Michael wrote:
> Using a compiler with a different host triplet is considered
> cross-compiling, even when it is for the same architecture as the
> build system. With such a cross-compiler, it is still valid to
> optimize builds with --cpu=host.
On Thu, Apr 02, 2020 at 08:24:13AM +0530, Gautam Ramakrishnan wrote:
> On Thu, Apr 2, 2020 at 12:58 AM Michael Niedermayer
> wrote:
> >
> > On Wed, Apr 01, 2020 at 08:01:48AM +0530, Gautam Ramakrishnan wrote:
> > > On Wed, Apr 1, 2020 at 6:17 AM Michael Niedermayer
> > > wrote:
> > > >
> > > >
On Wed, Apr 01, 2020 at 01:55:12PM -0700, John Rummell wrote:
> Updated to return AVERROR_INVALIDDATA.
>
> On Wed, Apr 1, 2020 at 12:33 PM Michael Niedermayer
> wrote:
>
> > On Mon, Mar 30, 2020 at 09:48:13PM -0700, John Rummell wrote:
> > > Hit send too soon. Patch attached.
> > >
> > > On
Output is identical
Signed-off-by: Michael Niedermayer
---
libswscale/tests/swscale.c | 41 --
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c
index 19878a7877..82eb135824 100644
---
Signed-off-by: Michael Niedermayer
---
libswscale/yuv2rgb.c | 43 ++-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/libswscale/yuv2rgb.c b/libswscale/yuv2rgb.c
index d0df061e4d..588462504e 100644
--- a/libswscale/yuv2rgb.c
+++
Am Do., 2. Apr. 2020 um 04:21 Uhr schrieb Fu, Linjie :
>
> > From: ffmpeg-devel On Behalf Of
> > Carl Eugen Hoyos
> > Sent: Thursday, April 2, 2020 03:22
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: fix the
Am Do., 2. Apr. 2020 um 07:39 Uhr schrieb Vesselin Bontchev
:
> +c->aes_decrypt = av_aes_alloc();
Don't you have to free this in the fail path?
An alternative is to allocate this after the length check...
If the alloc function returns NULL, you should return
ENOMEM.
Carl Eugen
On Thu, 2 Apr 2020, James Almer wrote:
On 4/2/2020 3:49 PM, Marton Balint wrote:
On Thu, 2 Apr 2020, James Almer wrote:
On 4/2/2020 3:27 PM, Marton Balint wrote:
On Thu, 2 Apr 2020, Marton Balint wrote:
On Thu, 2 Apr 2020, James Almer wrote:
On 3/29/2020 6:07 PM, James Almer
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
On 4/2/2020 3:49 PM, Marton Balint wrote:
>
>
> On Thu, 2 Apr 2020, James Almer wrote:
>
>> On 4/2/2020 3:27 PM, Marton Balint wrote:
>>>
>>>
>>> On Thu, 2 Apr 2020, Marton Balint wrote:
>>>
On Thu, 2 Apr 2020, James Almer wrote:
> On 3/29/2020 6:07 PM, James Almer
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
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
On Thu, 2 Apr 2020, James Almer wrote:
On 4/2/2020 3:27 PM, Marton Balint wrote:
On Thu, 2 Apr 2020, Marton Balint wrote:
On Thu, 2 Apr 2020, James Almer wrote:
On 3/29/2020 6:07 PM, James Almer wrote:
This produces a small speed up in demuxing
Signed-off-by: James Almer
---
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?:
>> >
>> >
On 4/2/2020 3:27 PM, Marton Balint wrote:
>
>
> On Thu, 2 Apr 2020, Marton Balint wrote:
>
>>
>>
>> On Thu, 2 Apr 2020, James Almer wrote:
>>
>>> On 3/29/2020 6:07 PM, James Almer wrote:
This produces a small speed up in demuxing
Signed-off-by: James Almer
---
On Thu, 2 Apr 2020, Marton Balint wrote:
On Thu, 2 Apr 2020, James Almer wrote:
On 3/29/2020 6:07 PM, James Almer wrote:
This produces a small speed up in demuxing
Signed-off-by: James Almer
---
libavformat/mpegts.c | 20
1 file changed, 16 insertions(+), 4
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 Thu, 2 Apr 2020, James Almer wrote:
On 3/29/2020 6:07 PM, James Almer wrote:
This produces a small speed up in demuxing
Signed-off-by: James Almer
---
libavformat/mpegts.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpegts.c
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
Put a buffer with a known fixed size into the demuxer's context instead
of allocating it separately. This also allows to remove the demuxer's
read_close()-function.
Signed-off-by: Andreas Rheinhardt
---
libavformat/dss.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
Currently Musepack allocates an array that needs to be freed later in
the demuxer's read_close-function; it is the sole reason for said
function's existence. But it is unnecessary, because one can store this
array in the stream's priv_data pointer, so that it will be freed
generically.
On 3/29/2020 6:07 PM, James Almer wrote:
> This produces a small speed up in demuxing
>
> Signed-off-by: James Almer
> ---
> libavformat/mpegts.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index
Signed-off-by: Andreas Rheinhardt
---
libavformat/ilbc.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/libavformat/ilbc.c b/libavformat/ilbc.c
index d41027174d..c778f5a5af 100644
--- a/libavformat/ilbc.c
+++ b/libavformat/ilbc.c
@@ -21,6 +21,7 @@
#include
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
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?:
On 4/2/20, Gyan Doshi wrote:
>
> When is 4.3 due? 4.2 was cut on 5th August 2019, almost 8 months ago.
>
When some things of uttermost importance are finished, polished and committed.
> Regards,
> Gyan
> ___
> ffmpeg-devel mailing list
>
When is 4.3 due? 4.2 was cut on 5th August 2019, almost 8 months ago.
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
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
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
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
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
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"?
> >
Quoting David Bryant (2020-04-01 23:35:13)
> On 3/31/20 2:47 AM, Anton Khirnov wrote:
> >>> Looking at wavpack, the code looks suspicious to me. You allocate one
> >>> dsdctx per channel at init, but AFAIU the number of channels can change
> >>> at each frame.
> >>>
> >> Multichannel WavPack
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
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
44 matches
Mail list logo
