[FFmpeg-devel] [PATCH] avformat/aacdec: add a custom read_packet function

Atempt to read and propagate only full ADTS frames and not other data, like id3v1 or APETags at the end of the file. Fixes ticket #6439. Signed-off-by: James Almer --- libavformat/aacdec.c | 42 -- 1 file changed, 40 insertions(+), 2

Re: [FFmpeg-devel] [PATCH] avformat/aacdec: add a custom read_packet function

On Fri, Jun 02, 2017 at 08:41:58PM -0300, James Almer wrote: > Atempt to read and propagate only full ADTS frames and not other data, > like id3v1 or APETags at the end of the file. > > Fixes ticket #6439. > > Signed-off-by: James Almer > --- > libavformat/aacdec.c | 31

Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF

On Fri, Jun 02, 2017 at 04:55:30PM +0200, Daniel Kucera wrote: > Signed-off-by: Daniel Kucera > --- > libavformat/avio.c| 2 +- > libavformat/aviobuf.c | 18 ++ > libavformat/cache.c | 2 +- > libavformat/file.c| 2 ++ > libavformat/wtvdec.c

[FFmpeg-devel] [PATCH] lavf/mov.c: Offset index timestamps by the minimum pts to make first pts zero.

Fixes t/6421 Signed-off-by: Sasi Inguva --- libavformat/mov.c| 57 -- tests/ref/fate/h264-twofields-packet | 60 ++-- 2 files changed, 70 insertions(+), 47 deletions(-) diff --git

Re: [FFmpeg-devel] [PATCH] libavfilter/scale2ref: Add constants for the primary input

On Fri, Jun 2, 2017 at 9:16 PM, James Almer wrote: > This broke 820 tests with Valgrind. All of them seem to point to > > ==1253== Invalid read of size 8 > ==1253==at 0x697ECA: ff_scale_eval_dimensions (scale.c:118) scale.c:118: const char scale2ref =

Re: [FFmpeg-devel] [PATCH] libavfilter/scale2ref: Add constants for the primary input

On 6/1/2017 6:37 PM, Michael Niedermayer wrote: > On Tue, May 30, 2017 at 01:34:29PM -0400, Kevin Mark wrote: >> Variables pertaining to the main video are now available when >> using the scale2ref filter. This allows, as an example, scaling a >> video with another as a reference point while

Re: [FFmpeg-devel] [PATCH] avformat/hls: Check file extensions

On Fri, Jun 02, 2017 at 09:27:16PM +0200, Hendrik Leppkes wrote: > On Fri, Jun 2, 2017 at 9:19 PM, Michael Niedermayer > wrote: > > This reduces the attack surface of local file-system and local network > > information leaking. > > > > It prevents the existing exploit

[FFmpeg-devel] [PATCH 5/6] add x86_64 8-bit simple_idct function

--- libavcodec/tests/x86/dct.c | 2 ++ libavcodec/x86/idctdsp_init.c| 10 ++ libavcodec/x86/simple_idct.h | 3 +++ libavcodec/x86/simple_idct10.asm | 6 ++ 4 files changed, 21 insertions(+) diff --git a/libavcodec/tests/x86/dct.c b/libavcodec/tests/x86/dct.c index

[FFmpeg-devel] [PATCH 4/6] avcodec/x86: cleanup simple_idct10

Use named arguments for the functions so we can remove a define. The stride/linesize argument is now ptrdiff_t type so we no longer need to sign extend the register. --- libavcodec/x86/proresdsp.asm | 2 +- libavcodec/x86/simple_idct10.asm | 8 ++--

[FFmpeg-devel] [PATCH 6/6] change coeffs

--- libavcodec/x86/simple_idct10.asm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm index b4b47afcee..ae848b7faf 100644 --- a/libavcodec/x86/simple_idct10.asm +++ b/libavcodec/x86/simple_idct10.asm @@

[FFmpeg-devel] [PATCH 3/6] add and fix xmm version of simple_idct

--- libavcodec/tests/x86/dct.c | 3 +++ libavcodec/x86/idctdsp_init.c | 1 + libavcodec/x86/simple_idct.asm | 45 ++ libavcodec/x86/simple_idct.h | 1 + 4 files changed, 50 insertions(+) diff --git a/libavcodec/tests/x86/dct.c

[FFmpeg-devel] [PATCH 1/6] initial alignment corrections for xmm registers

--- libavcodec/x86/simple_idct.asm | 47 ++ 1 file changed, 34 insertions(+), 13 deletions(-) diff --git a/libavcodec/x86/simple_idct.asm b/libavcodec/x86/simple_idct.asm index 6fedbb5784..b5d05ca653 100644 --- a/libavcodec/x86/simple_idct.asm +++

[FFmpeg-devel] [PATCH 2/6] change explicit mmx register use to x264asm style

--- libavcodec/x86/simple_idct.asm | 1172 1 file changed, 586 insertions(+), 586 deletions(-) Picture s/mm([0-7])/m\1/g here for 1229 lines and 64695 bytes. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] [WIP] [PATCH 0/6] sse2/xmm version of 8-bit simple_idct

Two ideas here. The first 3 patches alter the old mmx code so that it can use xmm registers. It still only uses half the available width and adds a few shuffles meaning it isn't an ideal solution. Though it is exact compared with the mmx version. Seems to be moderately faster of Skylake despite

[FFmpeg-devel] [PATCH] avformat/aacdec: add a custom read_packet function

Atempt to read and propagate only full ADTS frames and not other data, like id3v1 or APETags at the end of the file. Fixes ticket #6439. Signed-off-by: James Almer --- libavformat/aacdec.c | 31 +-- 1 file changed, 29 insertions(+), 2 deletions(-)

Re: [FFmpeg-devel] [PATCH] Disable MSA optimization for big endian arch

On Thu, Jun 01, 2017 at 02:07:19PM +0530, shivraj.pa...@imgtec.com wrote: > From: Shivraj Patil > > The current upstreamed code has been written and tested for Little Endian > systems. > We do have plans to add the Big Endian support in near future, but till that >

[FFmpeg-devel] [PATCH 2/2] avformat/utils: change bitrate to int64_t in av_find_best_stream

Signed-off-by: Marton Balint --- libavformat/utils.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index b544b6f9c5..aa2a00552e 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -4098,8 +4098,10 @@

[FFmpeg-devel] [PATCH 1/2] avformat/utils: return impaired streams in av_find_best_stream if only those exist

Fixes ticket #6397. Signed-off-by: Marton Balint --- libavformat/utils.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index fbd8b58ac2..b544b6f9c5 100644 --- a/libavformat/utils.c +++

[FFmpeg-devel] [PATCH 1/3] avcodec: add Gremlin DPCM decoder

Signed-off-by: Paul B Mahol --- libavcodec/Makefile | 1 + libavcodec/allcodecs.c | 1 + libavcodec/avcodec.h| 1 + libavcodec/codec_desc.c | 7 +++ libavcodec/dpcm.c | 44 ++-- 5 files changed, 48 insertions(+), 6

[FFmpeg-devel] [PATCH 3/3] avformat: add Gremlin Digital Video demuxer

Signed-off-by: Paul B Mahol --- libavformat/Makefile | 1 + libavformat/allformats.c | 1 + libavformat/gdv.c| 161 +++ 3 files changed, 163 insertions(+) create mode 100644 libavformat/gdv.c diff --git

[FFmpeg-devel] [PATCH 2/3] avcodec: add Gremlin Digital Video decoder

Signed-off-by: Paul B Mahol --- libavcodec/Makefile | 1 + libavcodec/allcodecs.c | 1 + libavcodec/avcodec.h| 1 + libavcodec/codec_desc.c | 7 + libavcodec/gdv.c| 404 5 files changed, 414 insertions(+)

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc : fix hw accelerated transcode with bframes

Am 02.06.2017 um 19:47 schrieb Ganapathy Raman Kasi: Hi, HW accelerated transcode (h264_cuvid -> h264_nvenc with -hwaccel cuvid) was broken after the filtergraph initialization was changed to intialize decoder first followed by encoder (commit af1761f7b5b1b72197dc40934953b775c2d951cc). During

Re: [FFmpeg-devel] [PATCH] avformat/hls: Check file extensions

On Fri, Jun 2, 2017 at 9:19 PM, Michael Niedermayer wrote: > This reduces the attack surface of local file-system and local network > information leaking. > > It prevents the existing exploit leading to an information leak. As > well as similar hypothetical attacks. > >

[FFmpeg-devel] [PATCH] avformat/hls: Check file extensions

This reduces the attack surface of local file-system and local network information leaking. It prevents the existing exploit leading to an information leak. As well as similar hypothetical attacks. Leaks of information from files and symlinks ending in common multimedia extensions are still

[FFmpeg-devel] [PATCH] avcodec/nvenc : fix hw accelerated transcode with bframes

Hi, HW accelerated transcode (h264_cuvid -> h264_nvenc with -hwaccel cuvid) was broken after the filtergraph initialization was changed to intialize decoder first followed by encoder (commit af1761f7b5b1b72197dc40934953b775c2d951cc). During initialzing encoder with bframes, local buffers are

Re: [FFmpeg-devel] [PATCH] cmdutils: add log time info into report log file

Le quintidi 15 prairial, an CCXXV, Steven Liu a écrit : > add time info into every line of log report > the time info can be used to find out error message occur time. > > Signed-off-by: Steven Liu > --- > cmdutils.c | 8 +++- > 1 file changed, 7 insertions(+), 1

[FFmpeg-devel] [PATCH] cmdutils: add log time info into report log file

add time info into every line of log report the time info can be used to find out error message occur time. Signed-off-by: Steven Liu --- cmdutils.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/cmdutils.c b/cmdutils.c index

[FFmpeg-devel] [PATCH] cmdutils: add log time info into report log file

add time info into every line of log report the time info can be used to find out error message occur time. Signed-off-by: Steven Liu --- cmdutils.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/cmdutils.c b/cmdutils.c index

[FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF

Signed-off-by: Daniel Kucera --- libavformat/avio.c| 2 +- libavformat/aviobuf.c | 18 ++ libavformat/cache.c | 2 +- libavformat/file.c| 2 ++ libavformat/wtvdec.c | 4 ++-- 5 files changed, 16 insertions(+), 12 deletions(-) diff --git

Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF

2017-06-02 15:43 GMT+02:00 Daniel Kučera : > 2017-06-02 15:08 GMT+02:00 Daniel Kučera : >> 2017-06-02 15:02 GMT+02:00 Nicolas George : >>> Le quartidi 14 prairial, an CCXXV, Daniel Kučera a écrit : Now I'm trying to pass fate.

Re: [FFmpeg-devel] [PATCH 2/2] x86/aacps: add ff_ps_stereo_interpolate_ipdopd_sse3()

On 5/23/2017 4:01 PM, James Almer wrote: > About 2x faster than the c version. > > Signed-off-by: James Almer > --- > libavcodec/x86/aacpsdsp.asm| 51 > ++ > libavcodec/x86/aacpsdsp_init.c | 4 > 2 files changed, 55

Re: [FFmpeg-devel] [PATCH] compat: LoadLibrary isn't available on UWP/WinRT

On Fri, 2 Jun 2017 15:29:07 +0200 Hugo Beauzée-Luyssen wrote: > --- > compat/w32dlfcn.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h > index bc9bb8c9f5..308763be53 100644 > --- a/compat/w32dlfcn.h > +++ b/compat/w32dlfcn.h

Re: [FFmpeg-devel] [PATCH] avformat/options: log filename on open

On Fri, 2 Jun 2017 15:05:27 +0200 Michael Niedermayer wrote: > The loglevel is choosen so that the main filename and any images of > multi image sequences are shown only at debug level to avoid > clutter. > > This makes exploits in playlists more visible. As they would

Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF

2017-06-02 15:08 GMT+02:00 Daniel Kučera : > 2017-06-02 15:02 GMT+02:00 Nicolas George : >> Le quartidi 14 prairial, an CCXXV, Daniel Kučera a écrit : >>> Now I'm trying to pass fate. I've fixed some problems but don't have >>> an idea why it won't pass

[FFmpeg-devel] [PATCH] compat: LoadLibrary isn't available on UWP/WinRT

--- compat/w32dlfcn.h | 4 1 file changed, 4 insertions(+) diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h index bc9bb8c9f5..308763be53 100644 --- a/compat/w32dlfcn.h +++ b/compat/w32dlfcn.h @@ -71,7 +71,11 @@ exit: #ifndef LOAD_LIBRARY_SEARCH_SYSTEM32 # define

[FFmpeg-devel] [PATCH 1/1] avcodec: NVENC improve debug and print hw capabilities

Hi, This patch focus in improved debug for NVENC. Capabilities added: - Prints HW capabilities of the device. *** Note: based on work done by Jean-Paul Saman *** http://mailman.videolan.org/pipermail/vlc-devel/2016-April/107005.html *** However this updated version doesn’t crash if unknown

Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF

2017-06-02 15:02 GMT+02:00 Nicolas George : > Le quartidi 14 prairial, an CCXXV, Daniel Kučera a écrit : >> Now I'm trying to pass fate. I've fixed some problems but don't have >> an idea why it won't pass following test. Does anyone have idea? > > I suspect you need to fix

[FFmpeg-devel] [PATCH] avformat/options: log filename on open

The loglevel is choosen so that the main filename and any images of multi image sequences are shown only at debug level to avoid clutter. This makes exploits in playlists more visible. As they would show accesses to private/sensitive files Signed-off-by: Michael Niedermayer

Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF

Le quartidi 14 prairial, an CCXXV, Daniel Kučera a écrit : > Now I'm trying to pass fate. I've fixed some problems but don't have > an idea why it won't pass following test. Does anyone have idea? I suspect you need to fix lavf/file.c to actually return AVERROR_EOF. Regards, -- Nicolas

Re: [FFmpeg-devel] [PATCH] libavformat/aviobuf.c: don't treat 0 from read_packet as EOF

2017-06-02 3:31 GMT+02:00 Michael Niedermayer : > On Thu, Jun 01, 2017 at 01:12:13PM +0200, Daniel Kucera wrote: >> Signed-off-by: Daniel Kucera >> --- >> libavformat/aviobuf.c | 18 ++ >> 1 file changed, 10 insertions(+), 8

[FFmpeg-devel] [PATCH] configure: support static libnpp [v3]

Hi, This is an updated version of my previous patch. Sorry! The previous one doesn’t work with the last version of the configure. This version is tested with both parameters: “--enable-libnpp-static” and “--disable-libnpp-static”. To summarize the info about this patch: - This is a simple

Re: [FFmpeg-devel] [PATCH 3/3] avformat: set the default whitelist to disable hls

On Fri, Jun 02, 2017 at 09:15:25AM +0200, Nicolas George wrote: > Le tridi 13 prairial, an CCXXV, Michael Niedermayer a écrit : > > This prevents an exploit leading to an information leak > > > > The existing exploit depends on a specific decoder as well. > > It does appear though that the

Re: [FFmpeg-devel] [PATCH] configure: support static libnpp [v2]

Hi Henry, (repost without quotes... sorry!) > I don't dispute that static linking might be useful, but I'm still not > liking needing a separate configure option, if perhaps another > solution can be found. I'm glad if you point me in to another solution. Meanwhile this solution is simple and

Re: [FFmpeg-devel] [PATCH] configure: support static libnpp [v2]

Hi, Sorry, but ProtonMail has troubles with "non-top" replies... Original Message Subject: Re: [FFmpeg-devel] [PATCH] configure: support static libnpp [v2] Local Time: June 2, 2017 12:03 PM UTC Time: June 2, 2017 10:03 AM From: h.lepp...@gmail.com To: FFmpeg development

Re: [FFmpeg-devel] [PATCH] minterpolate: added codec_me_mode

On Fri, May 26, 2017 at 2:49 PM Paul B Mahol wrote: > On 5/26/17, Michael Niedermayer wrote: > > On Mon, May 08, 2017 at 07:40:25PM +, Davinder Singh wrote: > >> hi, > >> > >> On Mon, Apr 24, 2017 at 9:43 PM Paul B Mahol wrote: >

Re: [FFmpeg-devel] [PATCH] configure: support static libnpp [v2]

Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Message Subject: Re: [FFmpeg-devel] [PATCH] configure: support static libnpp [v2] Local Time: June 2, 2017 12:03 PM UTC Time: June 2, 2017 10:03 AM From: h.lepp...@gmail.com To: FFmpeg development discussions

Re: [FFmpeg-devel] [PATCH] lavc: add mpeg2 decoder/hwaccel to mediacodec

Hi, On Fri, Jun 02, 2017 at 04:23:41AM -0400, Aman Gupta wrote: > From: Aman Gupta > > Android TV and FireOS hardware supports mpeg2 hardware decoding via > MediaCodec. > --- > configure | 2 ++ > libavcodec/Makefile| 1 + > libavcodec/allcodecs.c

[FFmpeg-devel] [PATCH] lavc/aarch64: add sbrdsp neon implementation

--- Hello, The following patch adds an aarch64 neon implementation of the sbrdsp (tested on an Odroid-C2). It hasn't been benchmarked yet and it lacks the hf_apply_noise{0,1,2,3} functions (which will be added later). --- libavcodec/aarch64/Makefile | 2 +

Re: [FFmpeg-devel] [PATCH] configure: support static libnpp [v2]

On Fri, Jun 2, 2017 at 11:56 AM, Andreas Håkon wrote: > Hi Hendrik, > > I don't like that there is a separate configure option. We can link to > other libraries dynamically or statically depending on what is found, > without needing two configure options per library.

Re: [FFmpeg-devel] [PATCH] configure: support static libnpp [v2]

Hi Hendrik, I don't like that there is a separate configure option. We can link to other libraries dynamically or statically depending on what is found, without needing two configure options per library. I understand. However, this is not really true for libnpp*. Let me to explain about this

Re: [FFmpeg-devel] [PATCH] configure: support static libnpp [v2]

On Fri, Jun 2, 2017 at 10:56 AM, Andreas Håkon wrote: > Hi, > > This patch is based on the original work done by Timo Rothenpieler, and his > patch for static linking with libnpp: >

[FFmpeg-devel] [PATCH] configure: support static libnpp [v2]

Hi, This patch is based on the original work done by Timo Rothenpieler, and his patch for static linking with libnpp: [http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195078.html](https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195078.html) Based in my recomendations now it's possible to

[FFmpeg-devel] [PATCH] lavc: add mpeg2 decoder/hwaccel to mediacodec

From: Aman Gupta Android TV and FireOS hardware supports mpeg2 hardware decoding via MediaCodec. --- configure | 2 ++ libavcodec/Makefile| 1 + libavcodec/allcodecs.c | 2 ++ libavcodec/mediacodecdec.c | 23 ++- 4 files

[FFmpeg-devel] [PATCH] avfilter: add skipblend filter

--- Changelog | 1 + doc/filters.texi | 30 libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/version.h | 2 +- libavfilter/vf_skipblend.c | 272

[FFmpeg-devel] [PATCH] avfilter: add skipblend filter

Attached a patch which adds a "skipblend" filter, which is similar to the framestep filter, but additionally blends frames together at each step, for a motion blur effect. The number of frames that are blended (i.e. the exposure time, in frames) can be set, allowing control over the strength of

Re: [FFmpeg-devel] [PATCH 3/3] avformat: set the default whitelist to disable hls

Le tridi 13 prairial, an CCXXV, Michael Niedermayer a écrit : > This prevents an exploit leading to an information leak > > The existing exploit depends on a specific decoder as well. > It does appear though that the exploit should be possible with any decoder. > The problem is that as long as