Re: [FFmpeg-devel] [PATCH] ffprobe: add show_video_keyframes option

On Thu, 9 Mar 2017 15:43:21 +0800 Steven Liu wrote: > add a option for show video keyframes info only when use show_packets > or show_frames > > Signed-off-by: Steven Liu > --- > ffprobe.c | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/ffprobe.c b/ffprobe.c > index

[FFmpeg-devel] [PATCH] ffprobe: add show_video_keyframes option

add a option for show video keyframes info only when use show_packets or show_frames Signed-off-by: Steven Liu --- ffprobe.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/ffprobe.c b/ffprobe.c index c85c3a1..3beceb2 100644 --- a/ffprobe.c +++ b/ffprobe.c @@ -81,6 +81,7 @@ s

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: 2147483647 - -14133 cannot be represented in type 'int'

On Thu, 9 Mar 2017 04:07:34 +0100 Michael Niedermayer wrote: > Fixes: 755/clusterfuzz-testcase-5369072516595712 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/h264_direct.c | 2 +

Re: [FFmpeg-devel] [PATCH 2/6] avcodec/dca_xll: Fix runtime error: signed integer overflow: 2147286116 + 6298923 cannot be represented in type 'int'

On Wed, 8 Mar 2017 23:28:39 +0100 Michael Niedermayer wrote: > Fixes: 732/clusterfuzz-testcase-4872990070145024 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/dca_xll.c | 2 +- >

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 23:34:39 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 09:01:32PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 20:54:43 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 07:32:26PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 19:20:15 +0100 >

Re: [FFmpeg-devel] fate: Do not report side data size

On Thu, 9 Mar 2017 02:20:03 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote: > > On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje > > wrote: > > > Hi, > > > > > > On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote: > > > > > >> On Wed, 8 Mar 2017 1

Re: [FFmpeg-devel] fate: Do not report side data size

On Thu, 9 Mar 2017 01:45:29 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote: > > On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje > > wrote: > > > Hi, > > > > > > On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote: > > > > > >> On Wed, 8 Mar 2017 1

Re: [FFmpeg-devel] [PATCH] swresample/resample: do not allow odd filter_length

On Thu, Mar 9, 2017 at 7:33 AM, Michael Niedermayer wrote: > On Thu, Mar 09, 2017 at 02:16:10AM +0700, Muhammad Faiz wrote: >> On Thu, Mar 9, 2017 at 1:32 AM, Michael Niedermayer >> wrote: >> > On Wed, Mar 08, 2017 at 10:25:42PM +0700, Muhammad Faiz wrote: >> >> except filter_length == 1 >> >> >>

[FFmpeg-devel] [PATCH] lavf/movdec: downgrade "shifted frame pts" log line to trace

This gets pretty chatty in files that use edit lists, so it fits a bit better at the trace level with similar messages. --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index d5c3949050..06f84f9f8e 100644 --- a/libavfor

[FFmpeg-devel] [PATCH 1/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: 2147483647 - -14133 cannot be represented in type 'int'

Fixes: 755/clusterfuzz-testcase-5369072516595712 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/h264_direct.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/h264

[FFmpeg-devel] [PATCH 2/2] avcodec/vp56: Require not any undamaged frame for concealment but one of comparable size

Fixes: timeout in 758/clusterfuzz-testcase-4720832028868608 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/vp56.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavco

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 8, 2017 at 8:15 PM, James Almer wrote: > On 3/8/2017 9:45 PM, Michael Niedermayer wrote: >> On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote: >>> On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje wrote: Hi, On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote:

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote: > On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje wrote: > > Hi, > > > > On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote: > > > >> On Wed, 8 Mar 2017 14:09:53 +0100 > >> Michael Niedermayer wrote: > >> > >> If the size printing is remov

Re: [FFmpeg-devel] fate: Do not report side data size

On 3/8/2017 1:27 PM, Nicolas George wrote: > L'octidi 18 ventôse, an CCXXV, Vittorio Giovara a écrit : >> I'm just going to say that for the case at hand >> sizeof(AVSphericalMapping) is not part of the ABI, and so it is >> allowed to have different sizes on different architectures. > > I am not s

Re: [FFmpeg-devel] fate: Do not report side data size

On 3/8/2017 9:45 PM, Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote: >> On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje wrote: >>> Hi, >>> >>> On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote: >>> On Wed, 8 Mar 2017 14:09:53 +0100 Michael Niederma

Re: [FFmpeg-devel] fate: Do not report side data size

On Thu, Mar 09, 2017 at 12:07:38AM +0100, Nicolas George wrote: > L'octidi 18 ventôse, an CCXXV, Hendrik Leppkes a écrit : > > So how do we fix fate now? Change the datatypes to uint32_t, remove > > the size print out? > > Shouldn't keep all 32-bit fate clients broken for much longer. > > Changing

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 08, 2017 at 11:54:59PM +0100, Hendrik Leppkes wrote: > On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje wrote: > > Hi, > > > > On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote: > > > >> On Wed, 8 Mar 2017 14:09:53 +0100 > >> Michael Niedermayer wrote: > >> > >> If the size printing is remov

Re: [FFmpeg-devel] [PATCH] swresample/resample: do not allow odd filter_length

On Thu, Mar 09, 2017 at 02:16:10AM +0700, Muhammad Faiz wrote: > On Thu, Mar 9, 2017 at 1:32 AM, Michael Niedermayer > wrote: > > On Wed, Mar 08, 2017 at 10:25:42PM +0700, Muhammad Faiz wrote: > >> except filter_length == 1 > >> > >> odd filter_length gives worse frequency response, > >> even when

Re: [FFmpeg-devel] [PATCH V2] vf_hwupload: Add missing return value check

On 2017/3/8 16:58, Mark Thompson wrote: > On 08/03/17 01:25, Jun Zhao wrote: >> ping ? >> >> On 2017/3/3 9:35, Jun Zhao wrote: >>> V2: Fix the potential memory leak.2 >>> >>> From eb283d277679b5dac9c43e8d3c98bcc9367b592f Mon Sep 17 00:00:00 2001 >>> From: Jun Zhao >>> Date: Fri, 3 Mar 2017 09:25

Re: [FFmpeg-devel] fate: Do not report side data size

L'octidi 18 ventôse, an CCXXV, Hendrik Leppkes a écrit : > So how do we fix fate now? Change the datatypes to uint32_t, remove > the size print out? > Shouldn't keep all 32-bit fate clients broken for much longer. Changing the types like that will not guarantee that all architectures have have the

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 8, 2017 at 3:42 PM, Ronald S. Bultje wrote: > Hi, > > On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote: > >> On Wed, 8 Mar 2017 14:09:53 +0100 >> Michael Niedermayer wrote: >> >> If the size printing is removed then other code should be added >> > to test for the size to match the correct v

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add support for Spherical Video elements

On 3/8/2017 7:09 PM, Vittorio Giovara wrote: > On Wed, Mar 8, 2017 at 4:05 PM, James Almer wrote: >> On 3/8/2017 5:08 PM, Vittorio Giovara wrote: >>> On Wed, Mar 8, 2017 at 2:46 PM, James Almer wrote: Signed-off-by: James Almer --- libavformat/matroskaenc.c | 69 +++

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 09:01:32PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 20:54:43 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 07:32:26PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 19:20:15 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 05:26

[FFmpeg-devel] [PATCH 3/6] avcodec/mjpegdec: Fix runtime error: left shift of negative value -127

Fixes: 733/clusterfuzz-testcase-4682158096515072 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/mjpegdec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/mjp

[FFmpeg-devel] [PATCH 6/6] avcodec/movtextdec: run mov_text_cleanup() before overwriting pointers

Fixes: memleak Fixes: 741/clusterfuzz-testcase-586996200452915 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/movtextdec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/movte

[FFmpeg-devel] [PATCH 4/6] avcodec/h264_mvpred: Fix runtime error: left shift of negative value -1

Fixes: 734/clusterfuzz-testcase-4821293192970240 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/h264_mvpred.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/h264

[FFmpeg-devel] [PATCH 5/6] avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: -135088512 * 16 cannot be represented in type 'int'

Fixes: 736/clusterfuzz-testcase-5580263943831552 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/mpeg4videodec.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/

[FFmpeg-devel] [PATCH 2/6] avcodec/dca_xll: Fix runtime error: signed integer overflow: 2147286116 + 6298923 cannot be represented in type 'int'

Fixes: 732/clusterfuzz-testcase-4872990070145024 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/dca_xll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/dca_xll.

[FFmpeg-devel] [PATCH 1/6] avcodec/mpegaudiodec_template: Check for negative e

Fixes: undefined shift Fixes: 631/clusterfuzz-testcase-6725491035734016 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/mpegaudiodec_template.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add support for Spherical Video elements

On Wed, Mar 8, 2017 at 4:05 PM, James Almer wrote: > On 3/8/2017 5:08 PM, Vittorio Giovara wrote: >> On Wed, Mar 8, 2017 at 2:46 PM, James Almer wrote: >>> Signed-off-by: James Almer >>> --- >>> libavformat/matroskaenc.c | 69 >>> +++ >>> 1 file chan

Re: [FFmpeg-devel] Point Cloud Compression

Am 08.03.17 um 22:40 schrieb Thilo Borgmann: > Am 08.03.17 um 21:35 schrieb Jan Ekstrom: >> On Wed, Mar 8, 2017 at 10:23 PM, Toepfer, Randall wrote: >>> Has anyone used FFMPEG for point cloud mpeg encoding and streaming? If not >>> does FFMPEG support this? >>> >>> http://mpeg.chiariglione.org/st

Re: [FFmpeg-devel] Point Cloud Compression

Am 08.03.17 um 21:35 schrieb Jan Ekstrom: > On Wed, Mar 8, 2017 at 10:23 PM, Toepfer, Randall wrote: >> Has anyone used FFMPEG for point cloud mpeg encoding and streaming? If not >> does FFMPEG support this? >> >> http://mpeg.chiariglione.org/standards/exploration/point-cloud-compression >> > >

[FFmpeg-devel] [PATCH v2] avformat/matroskaenc: add support for Spherical Video elements

Signed-off-by: James Almer --- libavformat/matroskaenc.c | 75 +++ 1 file changed, 75 insertions(+) diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index 1605f0cafe..70b0ced226 100644 --- a/libavformat/matroskaenc.c +++ b/libavformat

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add support for Spherical Video elements

On 3/8/2017 5:08 PM, Vittorio Giovara wrote: > On Wed, Mar 8, 2017 at 2:46 PM, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavformat/matroskaenc.c | 69 >> +++ >> 1 file changed, 69 insertions(+) >> >> diff --git a/libavformat/matrosk

[FFmpeg-devel] problem with block level audio decoding on a that is not streaming

I've tried to update my code from avcodec_decode_audio4 to the new avcodec_send_packet. I've got a block of data to decode, so this is not a streaming design. 1. When I pass a big block of data to the interface, the time required to process the buffer goes from 1.5s to 30s. 2. When I try and pa

Re: [FFmpeg-devel] Point Cloud Compression

On Wed, Mar 8, 2017 at 10:23 PM, Toepfer, Randall wrote: > Has anyone used FFMPEG for point cloud mpeg encoding and streaming? If not > does FFMPEG support this? > > http://mpeg.chiariglione.org/standards/exploration/point-cloud-compression > From the document "Call for Proposals for Point Cloud

[FFmpeg-devel] Point Cloud Compression

Has anyone used FFMPEG for point cloud mpeg encoding and streaming? If not does FFMPEG support this? http://mpeg.chiariglione.org/standards/exploration/point-cloud-compression Thanks, Randall Toepfer scandy.co ___ ffmpeg-devel mailing list ffmpeg-deve

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add support for Spherical Video elements

On Wed, Mar 8, 2017 at 2:46 PM, James Almer wrote: > Signed-off-by: James Almer > --- > libavformat/matroskaenc.c | 69 > +++ > 1 file changed, 69 insertions(+) > > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c > index 1605f0cafe.

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 20:54:43 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 07:32:26PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 19:20:15 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 17:11:12 +0100 >

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 20:42:17 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 08:23:26PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 20:15:24 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 07:35:50PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 19:20:15 +0100 >

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 07:32:26PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 19:20:15 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 17:11:12 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 04:06

[FFmpeg-devel] [PATCH] avformat/matroskaenc: add support for Spherical Video elements

Signed-off-by: James Almer --- libavformat/matroskaenc.c | 69 +++ 1 file changed, 69 insertions(+) diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index 1605f0cafe..0ee927d63e 100644 --- a/libavformat/matroskaenc.c +++ b/libavformat

Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

On Wed, 2017-03-08 at 20:35 +0100, Nicolas George wrote: > L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit : > > Hmm. Setting it to the same as the input value if all inputs match > > shouldn't be too hard, I think. > > > > In the actual case of inputs with different frame rates, would it be

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 08:23:26PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 20:15:24 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 07:35:50PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 19:20:15 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 05:26

Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit : > Hmm. Setting it to the same as the input value if all inputs match > shouldn't be too hard, I think. > > In the actual case of inputs with different frame rates, would it be > better to use the '1/0' value, or should it attempt to calculate

Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

On Wed, 08 Mar 2017 14:14:25 -0500 Calvin Walton wrote: > On Wed, 2017-03-08 at 19:27 +0100, Nicolas George wrote: > > L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit : > > > > > > If a later input is higher framerate, this results in dropped frames; if > > > a later input is lower framer

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 20:15:24 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 07:35:50PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 19:20:15 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 17:11:12 +0100 >

Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

On Wed, 2017-03-08 at 19:27 +0100, Nicolas George wrote: > L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit : > > > > If a later input is higher framerate, this results in dropped frames; if > > a later input is lower framerate it might cause judder. > > > > The simplest fix is to just set th

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 19:56:42 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 07:31:27PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 19:03:21 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 17:11:12 +0100 >

Re: [FFmpeg-devel] [PATCH] swresample/resample: do not allow odd filter_length

On Thu, Mar 9, 2017 at 1:32 AM, Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 10:25:42PM +0700, Muhammad Faiz wrote: >> except filter_length == 1 >> >> odd filter_length gives worse frequency response, >> even when compared with shorter filter_length >> >> also makes build_filter simpler >>

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 07:35:50PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 19:20:15 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 17:11:12 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 04:06

Re: [FFmpeg-devel] [PATCH] avfiltergraph: add -sample_rate_fallback

Le septidi 17 ventôse, an CCXXV, Takayuki 'January June' Suwa a écrit : > dedicated to all audiophiles :) > > examples: > -sample_rate_fallback closest -i 48ksps_source -af > "aformat=sample_rates=44100|88200|176400|352800" > => 44.1ksps (default behavior) > -sample_rate_fallback higher >

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 07:31:27PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 19:03:21 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 17:11:12 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 04:06

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On 3/8/2017 3:35 PM, wm4 wrote: > On Wed, 8 Mar 2017 19:20:15 +0100 > Michael Niedermayer wrote: > >> On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: >>> On Wed, 8 Mar 2017 17:11:12 +0100 >>> Michael Niedermayer wrote: >>> On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: >

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 19:20:15 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 17:11:12 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 15:36:25 +0100 >

Re: [FFmpeg-devel] [PATCH] swresample/resample: do not allow odd filter_length

On Wed, Mar 08, 2017 at 10:25:42PM +0700, Muhammad Faiz wrote: > except filter_length == 1 > > odd filter_length gives worse frequency response, > even when compared with shorter filter_length > > also makes build_filter simpler > > Signed-off-by: Muhammad Faiz > --- > libswresample/resample.c

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 19:20:15 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 17:11:12 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 15:36:25 +0100 >

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 19:03:21 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 17:11:12 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 15:36:25 +0100 >

Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit : > Right now, the concat filter does not set the frame_rate value on any of > the out links. As a result, the default ffmpeg behaviour kicks in - to > copy the framerate from the first input to the outputs. > > If a later input is higher framer

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 17:11:12 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 15:36:25 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 01:40

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 17:11:12 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 15:36:25 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 01:40

[FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

Right now, the concat filter does not set the frame_rate value on any of the out links. As a result, the default ffmpeg behaviour kicks in - to copy the framerate from the first input to the outputs. If a later input is higher framerate, this results in dropped frames; if a later input is lower fr

Re: [FFmpeg-devel] [PATCH 2/4] avcodec/wavpack: Fix runtime error: left shift of negative value -5

On Tue, Mar 07, 2017 at 02:41:41AM +0100, Michael Niedermayer wrote: > Fixes: 729/clusterfuzz-testcase-5154831595470848 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/wavpack.c | 2

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/pictordec: Fix runtime error: left shift of 64 by 25 places cannot be represented in type 'int'

On Tue, Mar 07, 2017 at 02:41:40AM +0100, Michael Niedermayer wrote: > Fixes: 724/clusterfuzz-testcase-6738249571631104 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/pictordec.c |

[FFmpeg-devel] [PATCH] avfilter/vf_interlace: add complex vertcal lowpassfilter

Hi, attached patch adds a complex (-1 2 6 2 -1) vertcal lowpassfilter to vf_interlace. This will better retain detail and reduce blurring compared to the existing (1 2 1) filter. Please comment. 0001-avfilter-vf_interlace-add-complex-vertcal-lowpassfil.patch Description: Binary data __

Re: [FFmpeg-devel] fate: Do not report side data size

L'octidi 18 ventôse, an CCXXV, Vittorio Giovara a écrit : > I'm just going to say that for the case at hand > sizeof(AVSphericalMapping) is not part of the ABI, and so it is > allowed to have different sizes on different architectures. I am not sure exactly what you are asserting here, but just fo

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 17:11:12 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 15:36:25 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote: > > > > It looks like this could lead to se

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 15:36:25 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote: > > > It looks like this could lead to security issues, as side data readers [...] > > also size checks are needed for

[FFmpeg-devel] [PATCH] swresample/resample: do not allow odd filter_length

except filter_length == 1 odd filter_length gives worse frequency response, even when compared with shorter filter_length also makes build_filter simpler Signed-off-by: Muhammad Faiz --- libswresample/resample.c | 56 +++- tests/fate/libswresample.mak | 76 +

Re: [FFmpeg-devel] [PATCH 3/3] avformat: don't "merge" side data into packet data by default

On Wed, 8 Mar 2017 15:44:36 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 01:40:12PM +0100, wm4 wrote: > > Side data are separate AVPacket fields for a reason. Merging side data > > requires reallocating all packets, is complex, potentially clashes with > > "actual" packet data (you

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 15:36:25 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote: > > It looks like this could lead to security issues, as side data readers > > anything could, but side data wasnt excluded from fuzzing, in fact > ive seen fuzzers find and trig

Re: [FFmpeg-devel] [PATCH] swresample/resample: use uniform normalization

On Wed, Mar 8, 2017 at 7:15 PM, Hendrik Leppkes wrote: > On Wed, Mar 8, 2017 at 10:16 AM, Muhammad Faiz wrote: >> On Tue, Mar 7, 2017 at 4:04 PM, Muhammad Faiz wrote: >>> On Mon, Mar 6, 2017 at 5:06 PM, Muhammad Faiz wrote: On Fri, Mar 3, 2017 at 3:58 PM, Muhammad Faiz wrote: > On Wed

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 8, 2017 at 6:51 AM, Michael Niedermayer wrote: >> Removing the side_data_size from output should be fine, as its a >> implementation detail and as seen here can even vary between >> architecture or possibly even compiler. >> Maybe someone that uses that ffprobe output more often can co

Re: [FFmpeg-devel] [PATCH 01/34] arm: vp9itxfm: Avoid .irp when it doesn't save any lines

On Wed, Mar 08, 2017 at 12:00:41PM +0200, Martin Storsjö wrote: > This makes it more readable. > > This is cherrypicked from libav commit > 3bc5b28d5a191864c54bba60646933a63da31656. > --- > libavcodec/arm/vp9itxfm_neon.S | 24 > 1 file changed, 12 insertions(+), 12 deleti

Re: [FFmpeg-devel] [PATCH 3/3] avformat: don't "merge" side data into packet data by default

On Wed, Mar 08, 2017 at 01:40:12PM +0100, wm4 wrote: > Side data are separate AVPacket fields for a reason. Merging side data > requires reallocating all packets, is complex, potentially clashes with > "actual" packet data (you could probably come up with PCM data that > looks like merged side dat

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote: > It looks like this could lead to security issues, as side data readers anything could, but side data wasnt excluded from fuzzing, in fact ive seen fuzzers find and trigger the split code also a demuxer and user app could always set side data t

Re: [FFmpeg-devel] fate: Do not report side data size

Hi, On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote: > On Wed, 8 Mar 2017 14:09:53 +0100 > Michael Niedermayer wrote: > > If the size printing is removed then other code should be added > > to test for the size to match the correct value > > Then it would be more reasonable to make av_packet_add_side

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, 8 Mar 2017 14:09:53 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 01:12:04PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 13:04:11 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 12:51:06 +0100 >

Re: [FFmpeg-devel] [PATCH] avutil/tests/lfg.c: added proper normality test

On Tue, Mar 07, 2017 at 04:36:15PM -0800, Thomas Turner wrote: > The Chen-Shapiro(CS) test was used to test normality for > Lagged Fibonacci PRNG. > > Normality Hypothesis Test: > > The null hypothesis formally tests if the population > the sample represents is normally-distributed. For > CS, whe

Re: [FFmpeg-devel] [PATCH 1/3] aacdec: do not mutate input packet metadata

On Wed, Mar 08, 2017 at 01:40:10PM +0100, wm4 wrote: > Apparently the demuxer outputs the wrong padding for HE-AAC (based on > the raw sample rate, or so). aacdec contains a hack to adjust the muxer > padding accordingly before it's used to trim the decoder output. This > modified the packet side d

[FFmpeg-devel] [PATCH] libavcodec/libopenjpegenc.c

Final version of simple patch to : limit encoder to single layer add lossless option set better defaults for a few encoding parameters. Cheers, Aaron 0001-1.-limit-to-single-layer-as-there-is-no-current-supp.patch Description: Binary data ___ ffmpeg-d

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 08, 2017 at 01:12:04PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 13:04:11 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 12:51:06 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 12:28

[FFmpeg-devel] [PATCH] avfilter/allfilters: Prefer s32 format over float

Because float actually int24 in the range [-1, 1] Signed-off-by: Aleksey Vasenev --- libavfilter/avfiltergraph.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c index 534c6701a8..61c10eeecd 100644 --- a/libavfilter

[FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

It looks like this could lead to security issues, as side data readers will for example rely on side data allocation sizes to be as large as needed for correct operation. If such files exist at all, they also should be brought out of circulation, so fully reject them. Under normal circumstances, no

[FFmpeg-devel] [PATCH 1/3] aacdec: do not mutate input packet metadata

Apparently the demuxer outputs the wrong padding for HE-AAC (based on the raw sample rate, or so). aacdec contains a hack to adjust the muxer padding accordingly before it's used to trim the decoder output. This modified the packet side data, which in combination with the old decoding API would cha

[FFmpeg-devel] [PATCH 3/3] avformat: don't "merge" side data into packet data by default

Side data are separate AVPacket fields for a reason. Merging side data requires reallocating all packets, is complex, potentially clashes with "actual" packet data (you could probably come up with PCM data that looks like merged side data, or such), and could for example cause trouble to people try

Re: [FFmpeg-devel] [PATCH] swresample/resample: use uniform normalization

On Wed, Mar 8, 2017 at 10:16 AM, Muhammad Faiz wrote: > On Tue, Mar 7, 2017 at 4:04 PM, Muhammad Faiz wrote: >> On Mon, Mar 6, 2017 at 5:06 PM, Muhammad Faiz wrote: >>> On Fri, Mar 3, 2017 at 3:58 PM, Muhammad Faiz wrote: On Wed, Mar 1, 2017 at 10:24 PM, Muhammad Faiz wrote: > this gi

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, 8 Mar 2017 13:04:11 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 12:51:06 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote: > > > > On Wed, Mar 8, 2017 at

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 12:51:06 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote: > > > On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara > > > wrote: > > > > This should address the misma

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, 8 Mar 2017 12:51:06 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote: > > On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara > > wrote: > > > This should address the mismatch between different archs > > iam not in favor of this solutio

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote: > On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara > wrote: > > This should address the mismatch between different archs iam not in favor of this solution > > Removing the side_data_size from output should be fine, as its a > imp

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara wrote: > This should address the mismatch between different archs Removing the side_data_size from output should be fine, as its a implementation detail and as seen here can even vary between architecture or possibly even compiler. Maybe someone th

[FFmpeg-devel] [PATCH 20/34] arm/aarch64: vp9lpf: Calculate !hev directly

Previously we first calculated hev, and then negated it. Since we were able to schedule the negation in the middle of another calculation, we don't see any gain in all cases. Before: Cortex A7 A8 A9 A53 A53/AArch64 vp9_loop_filter_v_4_8_neon: 147.0 129.0

[FFmpeg-devel] [PATCH 12/34] aarch64: vp9itxfm: Use the right lane sizes in 8x8 for improved readability

This is cherrypicked from libav commit 3dd7827258ddaa2e51085d0c677d6f3b1be3572f. --- libavcodec/aarch64/vp9itxfm_neon.S | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/libavcodec/aarch64/vp9itxfm_neon.S b/libavcodec/aarch64/vp9itxfm_neon.S index e42cc2d..3b347

[FFmpeg-devel] [PATCH 09/34] arm: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function

This is cherrypicked from libav commit 3933b86bb93aca47f29fbd493075b0f110c1e3f5. --- libavcodec/arm/vp9itxfm_neon.S | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavcodec/arm/vp9itxfm_neon.S b/libavcodec/arm/vp9itxfm_neon.S index 33a7af1..78fdae6 100644 --- a/libavcodec/a

[FFmpeg-devel] [PATCH 11/34] aarch64: vp9itxfm: Use a single lane ld1 instead of ld1r where possible

The ld1r is a leftover from the arm version, where this trick is beneficial on some cores. Use a single-lane load where we don't need the semantics of ld1r. This is cherrypicked from libav commit ed8d293306e12c9b79022d37d39f48825ce7f2fa. --- libavcodec/aarch64/vp9itxfm_neon.S | 16 --

[FFmpeg-devel] [PATCH 10/34] aarch64: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function

This is cherrypicked from libav commit 4da4b2b87f08a1331650c7e36eb7d4029a160776. --- libavcodec/aarch64/vp9itxfm_neon.S | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavcodec/aarch64/vp9itxfm_neon.S b/libavcodec/aarch64/vp9itxfm_neon.S index 3eb999a..df178d2 100644 --- a

[FFmpeg-devel] [PATCH 19/34] aarch64: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling

This work is sponsored by, and copyright, Google. Before: Cortex A53 vp9_inv_dct_dct_16x16_sub1_add_neon: 235.3 vp9_inv_dct_dct_32x32_sub1_add_neon: 555.1 After: vp9_inv_dct_dct_16x16_sub1_add_neon: 180.2 vp9_inv_dct_dct_32x32_sub1_add_neon: 475.3 This is cherryp

[FFmpeg-devel] [PATCH 13/34] aarch64: vp9itxfm: Update a comment to refer to a register with a different name

This is cherrypicked from libav commit 8476eb0d3ab1f7a52317b23346646389c08fb57a. --- libavcodec/aarch64/vp9itxfm_neon.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/aarch64/vp9itxfm_neon.S b/libavcodec/aarch64/vp9itxfm_neon.S index 3b34749..5219d6e 100644 ---

[FFmpeg-devel] [PATCH 18/34] arm: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling

This work is sponsored by, and copyright, Google. Before:Cortex A7 A8 A9 A53 vp9_inv_dct_dct_16x16_sub1_add_neon: 273.0 189.5 211.7 235.8 vp9_inv_dct_dct_32x32_sub1_add_neon: 752.0 459.2 862.2 553.9 After: vp9_inv_dct_dct_16x16_sub1_add_neo

  1   2   >