The function avformat_new_stream() returns a NULL pointer on failure.
However, in function rtp_mpegts_write_header(), its return value is not
validated before it is dereferenced. Check the return value against NULL
to avoid potential NULL dereference.
Signed-off-by: Pan Bian
---
V2: fix patcheck
The function avformat_new_stream() returns a NULL pointer on failure.
However, in function rtp_mpegts_write_header(), its return value is not
validated before it is dereferenced. Check the return value against NULL
to avoid potential NULL dereference.
Signed-off-by: Pan Bian
---
V2: fix patcheck
In function sami_paragraph_to_ass(), the return value of av_strdup() is
not checked. To avoid potential NULL dereference, the return value
should be checked against NULL.
Signed-off-by: Pan Bian
---
V2: fix patcheck warnings
---
libavcodec/samidec.c | 3 +++
1 file changed, 3 insertions(+)
diff
---
libavformat/mxf.h | 1 -
libavformat/mxfenc.c| 45 +
tests/ref/fate/copy-trac4914| 2 +-
tests/ref/fate/time_base| 2 +-
tests/ref/lavf/mxf | 6 +++---
tests/ref/lavf/mxf_d10 | 2 +-
tests/
---
libavformat/mxf.h| 1 +
libavformat/mxfenc.c | 52 ++--
2 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index 2d5b44943b..ffcc429a8b 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
---
libavformat/mxfenc.c | 99 +---
1 file changed, 55 insertions(+), 44 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 035e65ed43..ed6ecbf541 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -101,6 +101,1
---
tests/fate/mxf.mak | 8 ++--
tests/ref/fate/mxf-reel_name | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
create mode 100644 tests/ref/fate/mxf-reel_name
diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak
index 7714b61569..dce23d522e 100644
--- a/tests/fate/mxf.mak
++
Hi,
The following patch series adds support for writing reel names to mxf files.
The extra metadata is only written if the metadata key "reel_name" is present.
The mxf fate tests needed to be updated because I slightly change to the way
internal uuids for tracks and component metadata are calculat
2017-11-27 13:03 GMT+08:00 Karthick J :
> This patch fixes Bug #6868
> Sometimes end_pts is getting initialized to audio stream's
> first pts, while the duration is calculated based on video stream's pts.
> In this patch the end_pts is initialized with the correct stream's first pts.
> ---
> libav
This patch fixes Bug #6868
Sometimes end_pts is getting initialized to audio stream's
first pts, while the duration is calculated based on video stream's pts.
In this patch the end_pts is initialized with the correct stream's first pts.
---
libavformat/hlsenc.c | 4 +++-
1 file changed, 3 insertio
Again, totally unneded use of the atomic function to set/NULL a local variable.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/utils.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index de2dcea54d..17388ef637 100644
--- a
OK and thank you, these do work fine and produce handy results and the
documentation you linked works.
".\ffmpeg_3.latest_master.exe" -v verbose -init_hw_device list
".\ffmpeg_3.latest_master.exe" -v verbose -init_hw_device opencl
I'll head over to ffmpeg-user (and do some reading) to find out
On 11/23/2017 7:12 PM, Gyan Doshi wrote:
On 11/20/2017 3:59 PM, Gyan Doshi wrote:
At present, the value name 'max' for maximum thickness in drawbox (and
drawgrid) filter leads to a parse error if the thickness expression
contains 'max(val1,val2)' i.e.
[Eval @ ...] Invalid chars '(20,30
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/parser.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index 670680ea7c..baf1de4d88 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -23,30 +23,32 @@
#in
Same as last 2 commits.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/utils.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index baf09119fe..de2dcea54d 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -185,8 +1
Atomics were entirely pointless and did nothing but slow and complicate
the process down. This could be improved further still but the main
objective of this commit is to simplify.
Signed-off-by: Rostislav Pehlivanov
---
libavfilter/avfilter.c | 8 +---
1 file changed, 5 insertions(+), 3 del
Same as previous commit, unneded use of atomics.
Signed-off-by: Rostislav Pehlivanov
---
libavformat/format.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/libavformat/format.c b/libavformat/format.c
index 38ca2a3465..6ac7349ec5 100644
--- a/libavformat/f
Hi!
Attached patch avoids allocations >1GB for (short and) invalid mov
files with only reasonable speed impact.
Please review, Carl Eugen
From 0d243bad5fdd9850ff41d49a32a06274a3cd9756 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 27 Nov 2017 05:13:25 +0100
Subject: [PATCH] lavf/mov:
2017-11-27 4:22 GMT+01:00 Pan Bian :
> When the call to get_bits_left() fails, the return value is not an
> negative error code. This patch explicitly assignes an error
> code to the return variable ret.
Can't this break decoding of damaged streams that could be
decoded so far?
Carl Eugen
___
2017-11-27 4:24 GMT+01:00 James Almer :
> On 11/27/2017 12:17 AM, Carl Eugen Hoyos wrote:
>> That's completely apart from the fact that this header file does
>> not comply with any style guide while Nvidia's does (from a
>> very quick look at both files).
>
> That would be because the Nvidia one w
2017-11-27 4:00 GMT+01:00 Mironov, Mikhail :
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Sent: November 26, 2017 9:36 PM
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg
On 11/27/2017 12:17 AM, Carl Eugen Hoyos wrote:
> 2017-11-27 4:00 GMT+01:00 James Almer :
>> On 11/26/2017 11:57 PM, Carl Eugen Hoyos wrote:
>>> 2017-11-27 3:42 GMT+01:00 James Almer :
>>>
No comments about the code, but given this patchset has started a policy
controversy I'll state I'm
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: November 26, 2017 10:20 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
>
>
> Nobody is against adding AMD specific encoders and hwaccels. The issue for
> some seems to be the inclusion of external headers.
>
> Currently, nothing in our policy is against it, and as I and Philip already
> stated, your additions shouldn't be gated on a potential future policy change
> ab
When the call to get_bits_left() fails, the return value is not an
negative error code. This patch explicitly assignes an error code to the
return variable ret.
Signed-off-by: Pan Bian
---
libavcodec/hevc_ps.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/
2017-11-27 4:06 GMT+01:00 Mironov, Mikhail :
> I think as a side affect we can help integrate Vulkan acceleration to FFmpeg.
> It is much better then OpenCL for multimedia from performance perspective.
Why did I so strongly expect this argument?
(I have neither ever used OpenCL nor Vulkan.)
Othe
2017-11-27 4:00 GMT+01:00 James Almer :
> On 11/26/2017 11:57 PM, Carl Eugen Hoyos wrote:
>> 2017-11-27 3:42 GMT+01:00 James Almer :
>>
>>> No comments about the code, but given this patchset has started a policy
>>> controversy I'll state I'm in favor of including this external header.
>>
>> Will
On some failure paths, the error code is not correctly set.
Signed-off-by: Pan Bian
---
libavformat/mov.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index d25071b..bbf550f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4895,6 +4895,7 @@
In function mov_read_custom(), it returns 0 on the path that av_malloc()
returns a NULL pointer. 0 indicates success. An error code should be
assigned to ret.
Signed-off-by: Pan Bian
---
libavformat/mov.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/
On 11/27/2017 12:00 AM, Mironov, Mikhail wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Sent: November 26, 2017 9:36 PM
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFm
On Sun, Nov 26, 2017 at 12:09:35PM -0300, James Almer wrote:
> On 11/21/2017 6:48 PM, Marton Balint wrote:
> >
> >
> > On Thu, 9 Nov 2017, James Cowgill wrote:
> >
> >> Hi,
> >>
> >> On 09/11/17 14:02, Hendrik Leppkes wrote:
> >>> On Thu, Nov 9, 2017 at 1:21 PM, James Cowgill
> >>> wrote:
> >>>
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: November 26, 2017 9:57 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> G
2017-11-27 3:48 GMT+01:00 Philip Langdale :
[...]
Unrelated to this topic:
Please cut your quotes, I believe this is not the first message
where your content is very difficult to find.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ff
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: November 26, 2017 9:36 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
>
> 2017-11-27 3:32 GMT
On 11/26/2017 11:57 PM, Carl Eugen Hoyos wrote:
> 2017-11-27 3:42 GMT+01:00 James Almer :
>
>> No comments about the code, but given this patchset has started a policy
>> controversy I'll state I'm in favor of including this external header.
>
> Will the header work for operating systems other th
2017-11-27 3:42 GMT+01:00 James Almer :
> No comments about the code, but given this patchset has started a policy
> controversy I'll state I'm in favor of including this external header.
Will the header work for operating systems other than Windows?
Carl Eugen
__
On 11/26/2017 11:36 PM, mmironov wrote:
> From 21d99252fad543d3d27a015912c0458b6ae11e08 Mon Sep 17 00:00:00 2001
> From: mmironov
> Date: Tue, 14 Nov 2017 17:54:24 -0500
> Subject: [PATCH] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF
> SDK
>
> Signed-off-by: mmironov
> ---
> Chan
2017-11-27 3:32 GMT+01:00 Mironov, Mikhail :
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Also, imo you have not really explained which users would have an
>> advantage if FFmpeg includes the AMD header.
>
> It is
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: November 26, 2017 9:25 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
>
> 2017-11-27 3:15 GMT
2017-11-27 3:15 GMT+01:00 Mironov, Mikhail :
> I will skip all arguments, you already read them.
That's great, but I believe you forgot to add the fourth option.
Also, imo you have not really explained which users
would have an advantage if FFmpeg includes the AMD header.
Carl Eugen
(who has ne
>
> A few minor fixups below. I would be happy to apply this if it didn't contain
> the external header.
>
> Thanks,
>
> - Mark
>
>
I will resubmit the changes you mentioned.
As of header inclusion issue I've sent a separate email.
Thanks,
Mikhail
_
Hi,
I would like to summarize thoughts on several threads on this forum related
to the issue of including AMD/AMF header file into FFmpeg source tree.
It looks like they reflect some policies formal or informal.
Mark tried to create some policy regarding this issue but wasn't successful.
I belie
Hi!
Attached patch fixes ticket #6874 for me.
I don't think it makes much sense to discuss what the specification
means with "logical screen size" and "raster screen size" and
"physical display": Not only do other decoders accept such files, our
decoder already contains the necessary code to crop
In function process_output_surface(), the return value is 0 on the path
that av_mallocz() returns a NULL pointer. 0 indicates success, which
deviates from the fact. Return "AVERROR(ENOMEM)" instead of "0".
Signed-off-by: Pan Bian
---
libavcodec/nvenc.c | 4 +++-
1 file changed, 3 insertions(+),
The function avformat_new_stream() returns a NULL pointer on failure.
However, in function rtp_mpegts_write_header(), its return value is not
validated before it is dereferenced. Check the return value against NULL
to avoid potential NULL dereference.
Signed-off-by: Pan Bian
---
libavformat/rtpe
On 27 November 2017 at 01:12, Pan Bian wrote:
> The function avformat_alloc_context() will return a NULL pointer on
> failure. However, in function read_ffserver_streams(), its return value
> is not validated and the subsequent dereference may result in a bad
> memory access bug. Check its return
The function avformat_alloc_context() will return a NULL pointer on
failure. However, in function read_ffserver_streams(), its return value
is not validated and the subsequent dereference may result in a bad
memory access bug. Check its return value against NULL and avoid
potential NULL dereference
From: Pan Bian
In function sami_paragraph_to_ass(), the return value of av_strdup() is
not checked. To avoid potential NULL dereference, the return value
should be checked against NULL.
Signed-off-by: Pan Bian
---
libavcodec/samidec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/liba
On 22/11/17 23:28, mmironov wrote:
> From c669277afd764903d3da09d92a263d0fb58e24b1 Mon Sep 17 00:00:00 2001
> From: mmironov
> Date: Tue, 14 Nov 2017 17:54:24 -0500
> Subject: [PATCH] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF
> SDK
>
> Signed-off-by: mmironov
> ---
> Changelog
On Sun, Oct 22, 2017 at 01:41:58AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> tests/fate-run.sh | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611
On Mon, Nov 20, 2017 at 09:26:48PM +0100, Michael Niedermayer wrote:
> The outputted bits should match what is used in the lossless check
>
> Fixes: runtime error: signed integer overflow: -538697856 * 256 cannot be
> represented in type 'int'
> Fixes: 4326/clusterfuzz-testcase-minimized-56894496
On Mon, Nov 20, 2017 at 02:58:15PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 452986184 - -2113885312 cannot be represented
> in type 'int'
> Fixes: 4196/clusterfuzz-testcase-minimized-5580648594014208
>
> Found-by: continuous fuzzing process
> https://github.com/google/
On Wed, Nov 22, 2017 at 08:19:45PM +, Derek Buitenhuis wrote:
> On 11/22/2017 8:09 PM, Michael Niedermayer wrote:
> > not much, no
> > its a non static function tough
> > i can remove the check completely if thats preferred ?
>
> I guess leave it since it's non-static.
>
> LGTM.
ok, will app
On Wed, Nov 22, 2017 at 09:00:57PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 4271/clusterfuzz-testcase-4676667768307712
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavc
On Sun, 26 Nov 2017 22:35:58 +
Mark Thompson wrote:
> On 26/11/17 22:04, Philip Langdale wrote:
> > Signed-off-by: Philip Langdale
> > ---
> > Changelog | 2 +-
> > configure | 2 ++
> > libavcodec/Makefile| 1 +
> > libavcodec/hwaccels.h | 1 +
> > libavc
On 11/26/2017 8:13 PM, Rostislav Pehlivanov wrote:
> On 26 November 2017 at 22:51, James Darnley wrote:
>
>> When compared to the SSE4.2 version runtime, is reduced by 1 to 26%. The
>> function itself is around 2 times faster.
>> ---
>> libavcodec/x86/flac_dsp_gpl.asm | 56 +
On 2017-11-27 00:17, Rostislav Pehlivanov wrote:
> On 26 November 2017 at 22:51, James Darnley wrote:
>> @@ -152,13 +152,13 @@ RET
>> %macro FUNCTION_BODY_32 0
>>
>> %if ARCH_X86_64
>> -cglobal flac_enc_lpc_32, 5, 7, 8, mmsize, res, smp, len, order, coefs
>> +cglobal flac_enc_lpc_32, 5,
On 11/26/2017 7:51 PM, James Darnley wrote:
> When compared to the SSE4.2 version runtime, is reduced by 1 to 26%. The
> function itself is around 2 times faster.
> ---
> libavcodec/x86/flac_dsp_gpl.asm | 56
> +++--
> libavcodec/x86/flacdsp_init.c | 5 +++-
On 2017-11-27 00:13, Rostislav Pehlivanov wrote:
> On 26 November 2017 at 22:51, James Darnley wrote:
>> @@ -123,7 +123,10 @@ RET
>> %endmacro
>>
>> %macro PMINSQ 3
>> -pcmpgtq %3, %2, %1
>> +mova%3, %2
>> +; We cannot use the 3-operand format because the memory location
>> canno
On 11/26/2017 8:07 PM, Carl Eugen Hoyos wrote:
> 2017-11-26 23:51 GMT+01:00 James Darnley :
>
>> +if (EXTERNAL_SSE42(cpu_flags)) {
>> +if (CONFIG_GPL)
>> +c->lpc32_encode = ff_flac_enc_lpc_32_sse42;
>> +}
>
> Any objections over "if (CONFIG_GPL && EXTERNAL_..)"?
>
> C
On 26 November 2017 at 22:51, James Darnley wrote:
> Now does 6 samples per iteration, up from 2.
>
> From 1.6 to 2.1 times faster again. 2.5 to 3.9 times faster overall.
> Runtime is reduced by a further 4 to 17%. Reduced by 9 to 65% overall.
>
> Same conditions as previously.
> ---
> libavco
On 26 November 2017 at 22:51, James Darnley wrote:
> When compared to the SSE4 version, runtime is reduced by 0.5 to 20%.
> After a bug fix log, long ago in e609cfd697 the 16-bit lpc encoder is
> used so little that the runtime reduction is no longer correct. The
> function itself is around 2 ti
On 26 November 2017 at 22:51, James Darnley wrote:
> State that the maximum value of order is 32. This limit is used in both
> C and x86 assebly code.
> ---
> libavcodec/flacdsp.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
> inde
On 26 November 2017 at 22:51, James Darnley wrote:
> Around 1.1 times faster and reduces runtime by up to 6%.
> ---
> libavcodec/x86/flac_dsp_gpl.asm | 91 ++
> ++-
> 1 file changed, 72 insertions(+), 19 deletions(-)
>
> diff --git a/libavcodec/x86/flac_dsp_gp
On 11/26/2017 8:09 PM, Michael Niedermayer wrote:
> On Sun, Nov 26, 2017 at 12:47:22AM +0100, Michael Niedermayer wrote:
>> On Sun, Nov 26, 2017 at 12:10:38AM +0100, Michael Niedermayer wrote:
>>> On Fri, Nov 24, 2017 at 11:37:36PM -0300, James Almer wrote:
On 10/29/2017 11:57 AM, Michael Nied
On 26 November 2017 at 22:51, James Darnley wrote:
> When compared to the SSE4.2 version runtime, is reduced by 1 to 26%. The
> function itself is around 2 times faster.
> ---
> libavcodec/x86/flac_dsp_gpl.asm | 56 ++
> +--
> libavcodec/x86/flacdsp_init.c
On Sun, Nov 26, 2017 at 12:47:22AM +0100, Michael Niedermayer wrote:
> On Sun, Nov 26, 2017 at 12:10:38AM +0100, Michael Niedermayer wrote:
> > On Fri, Nov 24, 2017 at 11:37:36PM -0300, James Almer wrote:
> > > On 10/29/2017 11:57 AM, Michael Niedermayer wrote:
> > > > The choosen value is the lowe
2017-11-26 23:51 GMT+01:00 James Darnley :
> +if (EXTERNAL_SSE42(cpu_flags)) {
> +if (CONFIG_GPL)
> +c->lpc32_encode = ff_flac_enc_lpc_32_sse42;
> +}
Any objections over "if (CONFIG_GPL && EXTERNAL_..)"?
Carl Eugen
___
ffmpe
On 26 November 2017 at 22:51, James Darnley wrote:
> ---
> libavcodec/x86/flac_dsp_gpl.asm | 40 --
> --
> 1 file changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/libavcodec/x86/flac_dsp_gpl.asm
> b/libavcodec/x86/flac_dsp_gpl.asm
> index 4d212ed212
On Sun, Nov 26, 2017 at 02:03:09PM -0300, James Almer wrote:
> Prevents out of array accesses. Adressess ticket #6873
>
> Signed-off-by: James Almer
> ---
> libavformat/matroskaenc.c | 7 +++
> 1 file changed, 7 insertions(+)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF
When compared to the SSE4.2 version runtime, is reduced by 1 to 26%. The
function itself is around 2 times faster.
---
libavcodec/x86/flac_dsp_gpl.asm | 56 +++--
libavcodec/x86/flacdsp_init.c | 5 +++-
2 files changed, 47 insertions(+), 14 deletions(-)
dif
Around 1.1 times faster and reduces runtime by up to 6%.
---
libavcodec/x86/flac_dsp_gpl.asm | 91 -
1 file changed, 72 insertions(+), 19 deletions(-)
diff --git a/libavcodec/x86/flac_dsp_gpl.asm b/libavcodec/x86/flac_dsp_gpl.asm
index 952fc8b86b..91989ce56
From 1.3 to 2.5 times faster. Runtime reduced by 4 to 58%. As with the
16-bit version the speed-up generally increases with compression_level.
Also like the 16-bit version, it is not used with levels less than 3.
After this bug fix in long, long ago in e609cfd697 this 32-bit lpc
encoder is heav
State that the maximum value of order is 32. This limit is used in both
C and x86 assebly code.
---
libavcodec/flacdsp.h | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
index 7bb0dd0e9a..90fd3f04b5 100644
--- a/libavcodec/flacdsp.h
+++ b/lib
---
tests/checkasm/flacdsp.c | 72
1 file changed, 72 insertions(+)
diff --git a/tests/checkasm/flacdsp.c b/tests/checkasm/flacdsp.c
index dccb54d672..08e5e264ea 100644
--- a/tests/checkasm/flacdsp.c
+++ b/tests/checkasm/flacdsp.c
@@ -20,13 +20,16
Now does 6 samples per iteration, up from 2.
From 1.6 to 2.1 times faster again. 2.5 to 3.9 times faster overall.
Runtime is reduced by a further 4 to 17%. Reduced by 9 to 65% overall.
Same conditions as previously.
---
libavcodec/x86/flac_dsp_gpl.asm | 30 +-
1 fil
Three years ago I was writing some assembly to speed-up the flac encoder. I got
part of the set committed at that time. Since then the encoder had a small
overhaul and a major bugfix. That all meant this set needed a little work to
bring it back on top of master. I did most of that work in Augu
When compared to the SSE4 version, runtime is reduced by 0.5 to 20%.
After a bug fix log, long ago in e609cfd697 the 16-bit lpc encoder is
used so little that the runtime reduction is no longer correct. The
function itself is around 2 times faster. (As one might expect for
doing twice as many sam
---
libavcodec/x86/flac_dsp_gpl.asm | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/libavcodec/x86/flac_dsp_gpl.asm b/libavcodec/x86/flac_dsp_gpl.asm
index 4d212ed212..952fc8b86b 100644
--- a/libavcodec/x86/flac_dsp_gpl.asm
+++ b/libav
On 26/11/17 22:04, Philip Langdale wrote:
> Signed-off-by: Philip Langdale
> ---
> Changelog | 2 +-
> configure | 2 ++
> libavcodec/Makefile| 1 +
> libavcodec/hwaccels.h | 1 +
> libavcodec/nvdec.c | 1 +
> libavcodec/nvdec_vp8.c | 97
>
This is more correct if multiple slices are handled in parallel
Signed-off-by: Michael Niedermayer
---
libavcodec/error_resilience.c | 6 +++---
libavcodec/error_resilience.h | 2 +-
libavcodec/h263dec.c | 2 +-
libavcodec/h264_slice.c | 4 ++--
libavcodec/mpegvideo.c| 3 +
On Sat, Nov 25, 2017 at 05:01:57PM +, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov
> ---
> libavcodec/error_resilience.c | 20 ++--
> libavcodec/error_resilience.h | 3 ++-
> 2 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/
Signed-off-by: Philip Langdale
---
Changelog | 2 +-
configure | 2 ++
libavcodec/Makefile| 1 +
libavcodec/hwaccels.h | 1 +
libavcodec/nvdec.c | 1 +
libavcodec/nvdec_vp8.c | 97 ++
libavcodec/version.h |
On 24/11/17 16:50, Philip Langdale wrote:
> On Fri, 24 Nov 2017 00:51:29 +
> Mark Thompson wrote:
>
>> Enables VP8 decoding - the decoder places the the bitstream version
>> in the profile field, which we want to ignore.
>> ---
>> libavcodec/vaapi_decode.c | 3 ++-
>> 1 file changed, 2 inser
On 2017-11-26 03:42, Carl Eugen Hoyos wrote:
2017-11-26 9:31 GMT+01:00 Jim DeLaHunt :
[...]
+
@subheading Subscribe to the ffmpeg-cvslog mailing list.
-It is important to do this as the diffs of all commits are sent there and
-reviewed by all the other developers. Bugs and possible improvemen
On 11/26/2017 6:16 PM, Clément Bœsch wrote:
> On Sun, Nov 26, 2017 at 05:51:04PM -0300, James Almer wrote:
>> The bitstream filters inserted by this option should not be optional.
>
> Will ffmpeg error out if it's built without the required bsf? (or is there
> a hard dep in the configure?)
Mmh, n
On 2017-11-26 03:42, Carl Eugen Hoyos wrote:
2017-11-26 9:31 GMT+01:00 Jim DeLaHunt :
-@subsection Documentation/Other
+@section Documentation/Other
+@subheading Subscribe to the ffmpeg-devel mailing list.
+It is important to be subscribed to the
Of course it is important but I would much, much
On 11/26/17, Jim DeLaHunt wrote:
> On 2017-11-26 04:38, Paul B Mahol wrote:
>> On 11/26/17, Nicolas George wrote:
>>> Paul B Mahol (2017-11-26):
Your opinions are irrelevant.
>>> # Be friendly and respectful towards others and third parties.
>>> # Treat others the way you yourself want to be
On 2017-11-26 04:38, Paul B Mahol wrote:
On 11/26/17, Nicolas George wrote:
Paul B Mahol (2017-11-26):
Your opinions are irrelevant.
# Be friendly and respectful towards others and third parties.
# Treat others the way you yourself want to be treated.
Please stop trampling the code of conduc
On Sun, Nov 26, 2017 at 05:51:04PM -0300, James Almer wrote:
> The bitstream filters inserted by this option should not be optional.
Will ffmpeg error out if it's built without the required bsf? (or is there
a hard dep in the configure?)
--
Clément B.
signature.asc
Description: PGP signature
_
Hello,
Patch in attach add SIMD (SSSE 3) for gradient prediction
and a checkasm test
Checkasm result (width = 1024) (kaby lake, macos 10.12)
add_gradient_pred_c: 1708.8
add_gradient_pred_ssse3: 533.0
Benchmark on a 3 min HD File in gradient (422)
without SIMD :
bench: utime=102.695s
bench: maxrs
The bitstream filters inserted by this option should not be optional.
They are needed to succesfully mux files in some cases, and to prevent
muxing broken files in others.
This is more in line with AVCodec.bsfs()
Signed-off-by: James Almer
---
libavformat/avformat.h | 4 +++-
libavformat/m
Every bitstream filter behaves as intended now, so there's no need to
wait for the first packet of every stream.
Signed-off-by: James Almer
---
libavformat/avformat.h | 2 +-
libavformat/internal.h | 6 -
libavformat/mux.c | 52 -
Postpone writing the header until the first output packet is ready to be
written.
This makes sure any stream parameter change that could take place while
processing an input frame will be taken into account when writing the
output file header.
Signed-off-by: James Almer
---
fftools/ffmpeg.c | 31
Variants are presented as programs and can be loaded later by
setting discard flags on the program. Currently Kodi chooses the
program that best matches the desired bit rate.
Rainer
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org
Thanks Paul.
Thanks also to all reviewers for your comments! It's very helpful to have
extra sets of eyes to find my bugs.
Moritz is right, there is an unused #define, I will try to find time to
patch. Or maybe Paul can remove it
Regards
R.
___
ffmpeg-
2017-11-26 12:04 GMT+01:00 Steven Liu :
> 2017-11-26 18:46 GMT+08:00 Rainer Hochecker :
>> fixed mem leak poined out by Steven
> Hi Rainer,
>
> I'm not sure that is memleak, but looks like memleak when reading
> the code, i see the code always in hls.c before this patch, but no
> people report
>> +/*
>> + * If this is a live stream and this playlist looks like it is one
>> segment
>> + * behind, try to sync it up so that every substream starts at the same
>> + * time position (so e.g. avformat_find_stream_info() will see packets
>> from
>> + * all active streams wit
Marton Balint (2017-11-26):
> Okay, I am exagarating a bit, but unconditionally returning AVERROR(ENOSYS)
> would be an even better incentive, no? :)
For invalid uses of the API that can be easily avoided by the
application (like not explicitly passing NULL to a function), a hard
crash is even bet
On Sun, 26 Nov 2017, James Almer wrote:
On 11/26/2017 12:19 PM, Nicolas George wrote:
James Almer (2017-11-26):
The old decode API is not scheduled for removal right now probably
because 99% of decoders need to be ported.
I think this statement contains some confusion that is harmful to th
1 - 100 of 148 matches
Mail list logo
