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
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
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 +
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 +-
>
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
>
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
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
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
>> >>
>>
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
+++
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
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
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
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
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/
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.
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
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
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
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
>>
>
>
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
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
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
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
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
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.
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
>
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
>
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
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
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
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
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
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
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
>
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
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
>
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
>>
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
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
>
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
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:
>
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
>
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
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
>
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
>
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
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
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
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
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
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 |
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
__
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
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
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
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 +
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 --
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
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
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
---
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 - 100 of 132 matches
Mail list logo