On Wed, Sep 18, 2019 at 12:03 PM James Zern wrote:
>
> On Wed, Sep 18, 2019 at 7:54 AM Guo, Yejun wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Guo, Yejun
> > > Sent: Thursday, September 12, 2019 6:25 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Guo, Yejun
> > > Subject: [PAT
On Wed, Sep 18, 2019 at 11:42 AM James Zern wrote:
>
> On Sun, Sep 15, 2019 at 2:03 PM Elliott Karpilovsky
> wrote:
> >
> > ---
> > libavcodec/libaomenc.c | 14 +-
> > 1 file changed, 5 insertions(+), 9 deletions(-)
> >
>
> lgtm. This is leftover from libvpxenc, only vp8 can hit the
this conflicts with the current contributing guidance:
http://ffmpeg.org/developer.html#Contributing
FFmpeg is programmed in the ISO C90 language with a few additional
features from ISO C99, namely:
...
for loops with variable definition (‘for (int i = 0; i < 8; i++)’);
Signed-off-by: James Zern
LGTM
On 9/20/19, James Zern wrote:
> this conflicts with the current contributing guidance:
> http://ffmpeg.org/developer.html#Contributing
> FFmpeg is programmed in the ISO C90 language with a few additional
> features from ISO C99, namely:
> ...
> for loops with variable definition (‘for (int i
I have some aiff files in my music production library that I'd like to
convert to flac. However they aren't recognized by ffmpeg:
$ ffmpeg -i Raylon-190-Full.aif
...
[aiff @ 0x7fc3ce80] unknown or unsupported codec tag: able is not
implemented. Update your FFmpeg version to the newest one from
On Fri, 20 Sep 2019, 08:58 Adam Johnson, wrote:
> I have some aiff files in my music production library that I'd like to
> convert to flac. However they aren't recognized by ffmpeg:
>
> $ ffmpeg -i Raylon-190-Full.aif
> ...
> [aiff @ 0x7fc3ce80] unknown or unsupported codec tag: able is not
>
Am Fr., 20. Sept. 2019 um 09:58 Uhr schrieb Adam Johnson :
>
> I have some aiff files in my music production library that I'd like to
> convert to flac. However they aren't recognized by ffmpeg:
>
> $ ffmpeg -i Raylon-190-Full.aif
> ...
> [aiff @ 0x7fc3ce80] unknown or unsupported codec tag: ab
Kieran O Leary:
> On Fri, 20 Sep 2019, 08:58 Adam Johnson, wrote:
>
>> I have some aiff files in my music production library that I'd like to
>> convert to flac. However they aren't recognized by ffmpeg:
>>
>> $ ffmpeg -i Raylon-190-Full.aif
>> ...
>> [aiff @ 0x7fc3ce80] unknown or unsupporte
Am Fr., 20. Sept. 2019 um 10:30 Uhr schrieb Carl Eugen Hoyos
:
> > https://files-adamj-eu.s3.amazonaws.com/ffmpeg-devel/Raylon-190-Full.aif
> > https://files-adamj-eu.s3.amazonaws.com/ffmpeg-devel/Raylon-190-Full.wav
> Thank you for posting the samples!
> They are "encrypted", I doubt it is a str
Signed-off-by: Michael Niedermayer
---
libavcodec/utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 729c10a8ed..c48ada599a 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -678,8 +678,8 @@ int attribute_align_a
This should increase coverage over more audio decoders.
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 8b1ad1f8da..b131a5f2b6 100644
--- a/tools/target_dec_fuz
>
> I wasn't clear from your post of the aiff file was an export from Ableton,
> or raw capture files stores in a working directory.
>
These are aif files from a partner distributed by Ableton. Ableton's aiff
export gives a normal pcm_s24be aiff that ffmpeg happily decodes.
Presumably they have an
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/libsrt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 2fc6328c4e..2105317545 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -493,6 +493,7 @@ static int libsrt_ope
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/libsrt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index b5568089fa..2fc6328c4e 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -111,8 +111,8 @@
On Wed, Sep 18, 2019 at 09:42:14PM +0100, phunkyfish wrote:
> ---
> libavformat/rtsp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index c153cac88b..5e8adfaf3c 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -1318,6 +1318
> On 16 Sep 2019, at 11:55, Liu Steven wrote:
>
>
>
>> 在 2019年9月16日，下午6:44，vectronic 写道：
>>
>> prevent attempt to call xmlFree if val was not allocated
>>
>> fixes: 8135
>> Signed-off-by: vectronic
>> ---
>> libavformat/dashdec.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a
Makes sense. Latest version of patch v4 should reflect this.
> On 18 Sep 2019, at 21:42, phunkyfish wrote:
>
> ---
> libavformat/rtsp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index c153cac88b..5e8adfaf3c 100644
> --- a/libavformat/rt
On Thu, Sep 19, 2019 at 4:10 PM Tomas Härdin wrote:
>
> tor 2019-09-19 klockan 13:58 +0900 skrev Hyun Yoo:
> > On Thu, Sep 19, 2019 at 7:28 AM Carl Eugen Hoyos wrote:
> > > Am Di., 17. Sept. 2019 um 02:37 Uhr schrieb Hyun Yoo
> > > :
> > > > I implemented a g.722.1 decoder by linking FreeSwitch'
Hyun Yoo (12019-09-20):
> So non-free codec should be in ffmpeg internally/externally
> and fdk-aac is an exception. got it.
No, you did not get it. fdk-aac is not an exception, it is open-source.
> I don't know about relicense thing...but I did contacted FreeSwitch/Polycom.
> I sent email to Ste
Hi,
Em sex, 20 de set de 2019 às 01:00, Guo, Yejun escreveu:
>
> The reason to add this layer is that it is used by srcnn in vf_sr.
> This layer is currently ignored in native mode. After this patch,
> we can add multiple outputs support for native mode.
>
I did not quite understand the commit me
On Thu, 19. Sep 02:16, Fu, Linjie wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Andriy Gelman
> > Sent: Thursday, September 19, 2019 03:32
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Andriy Gelman
> > Subject: [FFmpeg-devel] [PAT
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Pedro Arthur
> Sent: Friday, September 20, 2019 10:17 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH 1/4] libavfilter/dnn: add layer maximum for
> n
Em sex, 20 de set de 2019 às 11:50, Guo, Yejun escreveu:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Pedro Arthur
> > Sent: Friday, September 20, 2019 10:17 PM
> > To: FFmpeg development discussions and patches
> > Subject:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/v210_template.c | 20
libavcodec/v210enc.c | 8 +---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/libavcodec/v210_template.c b/libavcodec/v210_template.c
index 9e1d9f9..083a9f1 100644
--
On Fri, Sep 20, 2019 at 11:55:17PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/v210_template.c | 20
> libavcodec/v210enc.c | 8 +---
> 2 files changed, 25 insertions(+), 3 deletions(-)
Adding a neares
On Fri, Sep 06, 2019 at 11:28:29PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> The multithread is avoid one core cpu is full with other filter like scale
> etc.
> About the performance, the gain is very small, below is my testing for
> performance.
> In order to avoid the disk bo
Em sex, 20 de set de 2019 às 01:01, Guo, Yejun escreveu:
>
> Signed-off-by: Guo, Yejun
> ---
> tests/dnn/Makefile | 1 +
> tests/dnn/dnn-layer-maximum-test.c | 71
> ++
> tests/fate/dnn.mak | 5 +++
> 3 files changed, 77 inse
Em sex, 20 de set de 2019 às 01:01, Guo, Yejun escreveu:
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/dnn/dnn_backend_native.c | 43
> +++-
> libavfilter/dnn/dnn_backend_native.h | 2 ++
> 2 files changed, 34 insertions(+), 11 deletions(-)
>
> diff --git a/
Em sex, 20 de set de 2019 às 01:01, Guo, Yejun escreveu:
>
> Signed-off-by: Guo, Yejun
> ---
> libavfilter/dnn/dnn_backend_native.c | 39
> +---
> 1 file changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_native.c
> b/libavfi
This avoids some invalid shifts
Signed-off-by: Michael Niedermayer
---
libavcodec/truespeech.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/truespeech.c b/libavcodec/truespeech.c
index d4ddfcbf9c..54352851b3 100644
--- a/libavcodec/truespeech.c
+++ b/liba
Hello Michael,
> On Sep 20, 2019, at 12:10 PM, Michael Niedermayer
> wrote:
>
> On Fri, Sep 20, 2019 at 11:55:17PM +0800, lance.lmw...@gmail.com wrote:
>> From: Limin Wang
>>
>> Signed-off-by: Limin Wang
>> ---
>> libavcodec/v210_template.c | 20
>> libavcodec/v210enc.c
This is an updated and extended version of my earlier patchset [1] that
was made necessary because it conflicts with a recently proposed patch
by James [2]. I have incorporated his patch here and have also added
a few patches regarding parse_packets.
- Andreas
[1]: https://ffmpeg.org/pipermail/ff
When AVFMT_FLAG_GENPTS is set, av_read_frame would put a reference to a
packet in the packet list (via av_packet_ref) and then immediately
thereafter unreference the original packet. This has been changed to
move the reference instead. Given that the packet originated from
read_frame_internal, it i
Up until now, read_frame_internal always initialized the packet it
received. But since the recent changes to ff_read_packet, this is no
longer needed: If the parsing queue is initially empty upon entering
read_frame_internal, the packet will now either contain content upon
success or be blank upon
Up until now, ff_packet_list_put had a flaw: When it moved a packet to
the list (meaning, when it ought to move the reference to the packet
list instead of creating a new one via av_packet_ref), it did not reset
the original packet, confusing the ownership of the data in the packet.
This has been d
Up until now, parse_packet() used a stack packet in case the stream is
flushed. But using such a packet is unnecessary as there is an AVPacket
readily available, it just needs to be used. Whether flushing is intended
or not will now be signalled by an explicit parameter rather than by
whether the p
From: James Almer
Demuxers may have allocated a packet before encountering an error and aborting.
Fixes ticket #8150
Signed-off-by: James Almer
---
Earlier versions of this patchset used av_init_packet() together with
setting the size and data to zero/NULL. This would have caused memleaks
when
Up until now, read_frame_internal in avformat/utils.c uses a spare
packet on the stack that serves no real purpose: At no point in this
function is there a need for another packet besides the packet destined
for output:
1. If the packet doesn't need a parser, but is output as is, the content
of the
ff_read_packet had several potential memleaks:
1. If av_packet_make_refcounted fails, it means that the packet is not
refcounted, but it could nevertheless carry side data and therefore
needs to be unreferenced.
2. If a packet happens to have an illegal stream index (i.e. one that
does not correspo
Up until now, avformat_find_stream_info had a potential for memleaks:
When everything was fine, it read packets and (depending upon whether
AVFMT_FLAG_NOBUFFER was set) put them in a packet list or unreferenced
them when they were no longer needed. But upon failure, said packets
would leak if they
Since the recent changes to ff_packet_list_put, the source packet will
be automatically reset when the reference is moved to the packet list,
so that it is unnecessary to reinitialize the packet in the loops in
parse_packet and ff_read_packet; initializing once at the beginning is
enough.
This als
On Fri, Sep 20, 2019 at 12:16:59AM +0200, Andreas Rheinhardt wrote:
> Fixes the tdsc FATE-test.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/tdsc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF67
On Fri, Sep 20, 2019 at 12:17:04AM +0200, Andreas Rheinhardt wrote:
> Fixes the FATE-tests g723_1-dec-1, g723_1-dec-2 and g723_1-dec-4.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/g723_1dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
will apply
thx
[...]
--
Michael
On Fri, Sep 20, 2019 at 12:17:06AM +0200, Andreas Rheinhardt wrote:
> Fixes the FATE-tests unknown_layout-ac3, ac3-fixed-encode, ac3-encode
> and eac3-encode. It furthermore fixes the ac3-encoder bugs mentioned in
> tickets #7994, #8144 and #8159.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> li
On Wed, Sep 18, 2019 at 09:01:37PM +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: Wednesday, September 18, 2019 10:28 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-d
On Thu, Sep 19, 2019 at 04:17:20PM +0200, Moritz Barsnick wrote:
> On Mon, Mar 18, 2019 at 11:01:21 +0100, Paul B Mahol wrote:
> > On 3/18/19, Moritz Barsnick wrote:
> > >> Tested against sample provided here:
> > >> https://ffmpeg.org/pipermail/ffmpeg-user/2019-March/043717.html
> > >>
> > >> li
On Thu, Sep 19, 2019 at 04:23:15PM +0200, Moritz Barsnick wrote:
> On Fri, Sep 07, 2018 at 21:32:02 +0200, Moritz Barsnick wrote:
> > On Mon, Jul 02, 2018 at 13:38:04 +0200, Moritz Barsnick wrote:
> > > Fixes #7293.
> >
> > Ping.
>
> Another friendly ping.
will apply
thx
[...]
--
Michael G
On Fri, Sep 20, 2019 at 11:09:48AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/utils.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
will apply patchset so the fuzzer coverage improves
[...]
--
Michael GnuPG fingerprint: 9FF2128
On Wed, Sep 18, 2019 at 08:20:10PM +0200, Tomas Härdin wrote:
> ons 2019-09-18 klockan 02:03 +0200 skrev Andreas Rheinhardt:
> > The pointer arguments to memcpy (and several other functions of the
> > C standard library) are not allowed to be NULL, not even when the number
> > of bytes to copy is z
On Wed, Sep 18, 2019 at 04:02:55PM -0300, James Almer wrote:
> On 9/18/2019 10:47 AM, Moritz Barsnick wrote:
> > On Thu, Sep 12, 2019 at 11:23:03 +0200, Moritz Barsnick wrote:
> >> Moritz Barsnick (3):
> >> avformat/hashenc: rearrange options definition
> >> avformat/hashenc: use an array of ha
hello. I didn't see any comments about this patch - does that mean it is
ready to be merged?
On Thu, Aug 29, 2019 at 3:54 PM William Martin
wrote:
> From: Will Martin
>
> Some rtmp streamers (i.e. AWS Elemental Encoder, Wirecast) send C0 and C1
> together and expect S0 and S1 returned together.
On Fri, Sep 20, 2019 at 07:57:10PM +0200, Michael Niedermayer wrote:
> On Fri, Sep 06, 2019 at 11:28:29PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > The multithread is avoid one core cpu is full with other filter like scale
> > etc.
> > About the performance, the gain is v
On Fri, Sep 20, 2019 at 06:10:59PM +0200, Michael Niedermayer wrote:
> On Fri, Sep 20, 2019 at 11:55:17PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/v210_template.c | 20
> > libavcodec/v210enc.c
From: Andriy Gelman
Since reading 4 bits always returns a value in the range [0, 15], the
check for vps_id >= HEVC_MAX_VPS_COUNT, where HEVC_MAX_VPS_COUNT = 16, is
redudant.
---
libavcodec/hevc_ps.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/libavcodec/hev
From: Jun Zhao
avpriv_mpeg4audio_get_config will use MPEG4AudioConfig.chan_config to get
the MPEG4AudioConfig.channels, but if we use a uninitialized variable,
we will get an indeterminate channels, add an explicit initialization
for this case.
Signed-off-by: Jun Zhao
---
libavformat/matroskae
From: Jun Zhao
avpriv_mpeg4audio_get_config will use MPEG4AudioConfig.chan_config to get
the MPEG4AudioConfig.channels, but if we use a uninitialized variable,
we will get an indeterminate channels, add an explicit initialization
for this case.
Signed-off-by: Jun Zhao
---
libavcodec/aac_adtsto
From: Jun Zhao
avpriv_mpeg4audio_get_config will use MPEG4AudioConfig.chan_config to get
the MPEG4AudioConfig.channels, but if we use a uninitialized variable,
we will get an indeterminate channels, add an explicit initialization
for this case.
Signed-off-by: Jun Zhao
---
libavformat/adtsenc.c
From: Jun Zhao
avpriv_mpeg4audio_get_config will use MPEG4AudioConfig.chan_config to get
the MPEG4AudioConfig.channels, but if we use a uninitialized variable,
we will get an indeterminate channels, add an explicit initialization
for this case.
Signed-off-by: Jun Zhao
---
libavformat/latmenc.c
From: Jun Zhao
avpriv_mpeg4audio_get_config will use MPEG4AudioConfig.chan_config to get
the MPEG4AudioConfig.channels, but if we use a uninitialized variable,
we will get an indeterminate channels, add an explicit initialization
for this case.
Signed-off-by: Jun Zhao
---
libavcodec/mpegaudiod
On 9/20/2019 11:12 PM, Jun Zhao wrote:
> From: Jun Zhao
>
> avpriv_mpeg4audio_get_config will use MPEG4AudioConfig.chan_config to get
> the MPEG4AudioConfig.channels, but if we use a uninitialized variable,
> we will get an indeterminate channels, add an explicit initialization
> for this case.
From: Jun Zhao
need to free the header in error path
Signed-off-by: Jun Zhao
---
libavformat/4xm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/4xm.c b/libavformat/4xm.c
index a984fc9..8054980 100644
--- a/libavformat/4xm.c
+++ b/libavformat/4xm.c
@@ -24
2019년 9월 20일 (금) 오후 10:49, Nicolas George 님이 작성:
> Hyun Yoo (12019-09-20):
> > So non-free codec should be in ffmpeg internally/externally
> > and fdk-aac is an exception. got it.
>
> No, you did not get it. fdk-aac is not an exception, it is open-source.
>
Sorry for typo. 'non-free should NOT be
On 9/20/2019 11:17 PM, James Almer wrote:
> On 9/20/2019 11:12 PM, Jun Zhao wrote:
>> From: Jun Zhao
>>
>> avpriv_mpeg4audio_get_config will use MPEG4AudioConfig.chan_config to get
>> the MPEG4AudioConfig.channels, but if we use a uninitialized variable,
>> we will get an indeterminate channels, a
From: Limin Wang
The multithread is avoid one core cpu is full with other filter like scale etc.
About the performance, the gain is very small, below is my testing for
performance.
In order to avoid the disk bottleneck, I'll use stream_loop mode for 10 frame
only.
./ffmpeg -y -i ~/Movies/4k_Rec7
ignore the patch please, will send the right version again.
On Sat, Sep 21, 2019 at 11:18:38AM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> The multithread is avoid one core cpu is full with other filter like scale
> etc.
> About the performance, the gain is very small, below is
From: Limin Wang
The multithread is avoid one core cpu is full with other filter like scale etc.
About the performance, the gain is very small, below is my testing for
performance.
In order to avoid the disk bottleneck, I'll use stream_loop mode for 10 frame
only.
./ffmpeg -y -i ~/Movies/4k_Rec7
On 21-09-2019 03:01 AM, Michael Niedermayer wrote:
On Wed, Sep 18, 2019 at 04:02:55PM -0300, James Almer wrote:
On 9/18/2019 10:47 AM, Moritz Barsnick wrote:
On Thu, Sep 12, 2019 at 11:23:03 +0200, Moritz Barsnick wrote:
Moritz Barsnick (3):
avformat/hashenc: rearrange options definition
On Sat, Sep 14, 2019 at 2:06 PM Jun Li wrote:
>
>
> On Tue, Sep 10, 2019 at 12:16 PM Jun Li wrote:
>
>>
>>
>> On Tue, Sep 10, 2019 at 12:12 PM Jun Li wrote:
>>
>>> Fix #7637
>>> One empty/end sample is created and inserted between two caption lines
>>> when there is a gap.
>>> This patch is to
68 matches
Mail list logo
