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
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
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 consis
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
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 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, 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
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 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
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
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
ffmpeg-devel-requ...@
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
> ffmpeg-devel@f
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
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
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 "avform
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 7f
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.
Signed-off-
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(-)
dif
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
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 b/li
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
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, 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 deletio
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
---
libavfor
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
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
---
libav
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
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: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://
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 wrote:
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 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 wrot
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
__
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 build
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
+++ b/libswscale
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
--- a/libs
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 Mon,
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
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. Mak
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(-)
seems
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 cross-com
> -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 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 fr
Quoting David Bryant (2020-04-03 07:14:21)
> 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 AFA
Hey,
is someone up to review this patch?
It's an attempt to fix rtsp streams that use udp multicasts as the
underlying
transmission protocol.
The idea was taken from live555 as the said stream worked in VLC.
It still applies cleanly on current master.
Best Regards,
Wolfgang
On 18.10.19 18:
46 matches
Mail list logo
