[FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section (v2)

Previously, the Developer Documentation contained a single chapter, 1. Developer Guide, with all content under that single chapter. Thus the document structure was one level deeper and more complicated than it needed to be. It differed from similar documents such as /faq.html, which have multiple

Re: [FFmpeg-devel] How to preserve @subheading directives, and styling, when compiling doc/developer.texi ?

On 2017-11-21 01:20, Jim DeLaHunt wrote: Hello, doc maintainers: Could I get some help with the Texinfo compilation which produces /developer.html, please? Page is a document which has some section headings displayed in green text, and some subheadings di

[FFmpeg-devel] [PATCH] hls demuxer: add option to defer parsing of variants

fixed mem leak poined out by Steven --- doc/demuxers.texi | 5 + libavformat/hls.c | 304 -- 2 files changed, 209 insertions(+), 100 deletions(-) diff --git a/doc/demuxers.texi b/doc/demuxers.texi index 73dc0feec1..634b122e10 100644 --- a/do

Re: [FFmpeg-devel] [PATCH] hls demuxer: add option to defer parsing of variants

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 it memleak. If that is memleak, maybe use goto m

Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section (v2)

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 prefer if people send their patches wi

Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section (v2)

On 11/26/17, 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 m

Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section (v2)

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 conduct. -- Nicolas George signature.asc Description: Digital signature ___

Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section (v2)

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 conduct. Please stop being extremly r

Re: [FFmpeg-devel] [PATCH 0/1][TOOL][HACK] Allocation NULL check fuzzer

2017-11-26 2:05 GMT+01:00 Derek Buitenhuis : > On 11/26/2017 12:14 AM, Carl Eugen Hoyos wrote: >> I am of course in favour of such checks but is there an allocator we support >> that actually returns NULL on oom? > > Anything that doesn't use overcommit. Windows is the big obvious one here. > Also

Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

OK, the experimental -opencl_bench option has been removed by recent commits. Thank you for the updates to OpenCL. It cross-compiles OK, however I'm not sure about the replacement functionality. So, 2 things. 1. may I enquire how one ascertains the numbers to use like this ? -opencl_option

Re: [FFmpeg-devel] [PATCH 2/2] vorbisenc: Check the return value of av_frame_clone

On 11/24/2017 7:27 PM, Derek Buitenhuis wrote: > Prevents a segfault when alloc fails. > > Signed-off-by: Derek Buitenhuis > --- > libavcodec/vorbisenc.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) If there are no objections, I'll push this today after a FATE run. - Derek

Re: [FFmpeg-devel] [PATCH 3/3] udp: Actually fail when we're missing required options, like the "warning" says.

On 11/22/2017 3:28 PM, Derek Buitenhuis wrote: > Signed-off-by: Derek Buitenhuis > --- > There was no reasoning in the commit that added this, so maybe someone on > the list has some insights. > --- > libavformat/udp.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Ping. - Derek __

[FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

Hi! Attached patch adds a missing dependency to libvmaf, I don't know if other threads also work. Please comment, Carl Eugen From 4ee0fe8778c67a0f623b352a257e68485dd1d559 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Sun, 26 Nov 2017 14:29:27 +0100 Subject: [PATCH] configure: libvmaf dep

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

On 11/26/2017 1:35 PM, Carl Eugen Hoyos wrote: > Attached patch adds a missing dependency to libvmaf, I don't know if > other threads also work. This should also be filed as a bug against libvmaf, since its pkg-config file isn't complete, then. - Derek

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 14:40 GMT+01:00 Derek Buitenhuis : > On 11/26/2017 1:35 PM, Carl Eugen Hoyos wrote: >> Attached patch adds a missing dependency to libvmaf, I don't know if >> other threads also work. > > This should also be filed as a bug against libvmaf, since its pkg-config > file isn't complete, then

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

On 11/26/2017 1:50 PM, Carl Eugen Hoyos wrote: > Sorry, I don't understand how pkg-config is related to the missing > dependency of our configure script: Please explain. Because pthreads is a dependency of libvmaf. Looking at libvmaf, it does list pthreads as a dependency: https://github.com

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 14:53 GMT+01:00 Derek Buitenhuis : > On 11/26/2017 1:50 PM, Carl Eugen Hoyos wrote: >> Sorry, I don't understand how pkg-config is related to the missing >> dependency of our configure script: Please explain. > > Because pthreads is a dependency of libvmaf. > > Looking at libvmaf, it doe

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

Carl Eugen Hoyos (2017-11-26): > The following produces an ffmpeg binary that loads pthreads > at start-time: > $ ./configure --enable-libvmaf --disable-pthreads That is not a problem. The fact that it produces a binary with pthreads symbols in it is. Regards, -- Nicolas George signature.as

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 14:59 GMT+01:00 Nicolas George : > Carl Eugen Hoyos (2017-11-26): >> The following produces an ffmpeg binary that loads pthreads >> at start-time: >> $ ./configure --enable-libvmaf --disable-pthreads > > That is not a problem. The fact that it produces a binary with > pthreads symbols in

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

Carl Eugen Hoyos (2017-11-26): > The way I understand (Linux) dynamic libraries, one implies > the other. Yes, but not the other way around. If a library uses threads internally but provides an interface that can be used without threads, then it is not our problem. If a library does not use thre

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

On 11/26/2017 2:02 PM, Carl Eugen Hoyos wrote: > The way I understand (Linux) dynamic libraries, one implies > the other. The problem is that libvmaf's .pc file put all of its deps in Libs instead of splitting them out into Libs.private, which is used only when static linking. Stuff like -lpthread

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 15:05 GMT+01:00 Nicolas George : > Carl Eugen Hoyos (2017-11-26): >> The way I understand (Linux) dynamic libraries, one implies >> the other. > > Yes, but not the other way around. > > If a library uses threads internally but provides an interface that can > be used without threads, the

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

On 11/26/2017 2:05 PM, Nicolas George wrote: > If a library does not use threads but our calls to the library require > threads, then we must consider it a dependency. Netflix made their pkg-config file incorrectly, which causes this. It should be fixed there, but do we want to work around that in

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 15:06 GMT+01:00 Derek Buitenhuis : > On 11/26/2017 2:02 PM, Carl Eugen Hoyos wrote: >> The way I understand (Linux) dynamic libraries, one implies >> the other. > > The problem is that libvmaf's .pc file put all of its deps in > Libs instead of splitting them out into Libs.private, which

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

On 11/26/2017 2:06 PM, Carl Eugen Hoyos wrote: > In this case the library and our interface both depend on pthreads > but configure ignores this. Sorry, I wasn't aware our own wrapper code use pthreads too. Patch should be OK then. Upstream pkg-config file is still broken, though. :) - Derek ___

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

Derek Buitenhuis (2017-11-26): > The problem is that libvmaf's .pc file put all of its deps in > Libs instead of splitting them out into Libs.private, which > is used only when static linking. Stuff like -lpthreads is > only needed if static linking, and stuff like -lstdc++ is > just wrong on any s

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

On 11/26/2017 2:09 PM, Carl Eugen Hoyos wrote: > As said before, it is non-trivial to find such a system > (it worked fine here on osx when I tested last). OS X does not ship with libstdc++, IIRC. You must have been using a ports-build toolchain? Using clang-cl or MSVC on windows will also not use

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

On 11/26/2017 2:10 PM, Nicolas George wrote: > -> our code depends on pthreads for this filters, it must be expressed > in configure: Carl Eugen's patch is right, there is no need to bugreport > anything. His explanations later were wrong, but it may only be caused > by the confusion you brought.

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 15:11 GMT+01:00 Derek Buitenhuis : > On 11/26/2017 2:09 PM, Carl Eugen Hoyos wrote: >> As said before, it is non-trivial to find such a system >> (it worked fine here on osx when I tested last). > > OS X does not ship with libstdc++, IIRC. You must > have been using a ports-build toolcha

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

On 11/26/2017 2:15 PM, Carl Eugen Hoyos wrote: > I believe I have explained before that I always only use > vanilla toolchains because that's the only thing users > typically have access to. It's possible the OS X version was outdated then, since the system clang has used libc++ as default since O

Re: [FFmpeg-devel] [PATCH]configure: libvmaf depends on pthreads

2017-11-26 15:10 GMT+01:00 Nicolas George : > $ grep -c pthread libavfilter/*vmaf* > libavfilter/vf_libvmaf.c:22 > libavfilter/vf_vmafmotion.c:0 > libavfilter/vmaf_motion.h:0 > > -> our code depends on pthreads for this filters, it must be expressed > in configure: Carl Eugen's patch is right Is

Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

On Tue, Nov 21, 2017 at 10:48:19PM +0100, 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: > >>>In commit 061a0c14bb57 ("decode: restructure the core decoding co

Re: [FFmpeg-devel] [PATCH 0/1][TOOL][HACK] Allocation NULL check fuzzer

On 11/25/2017 12:07 AM, Michael Niedermayer wrote: > I do not know that but i would be surprised if null dereferences tests > where unwelcome > > oss-fuzz will already report null derferences and OOM conditions, as > well as undefined behavior. So in some sense various points on the map > surround

Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

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: In commit 061a0c14bb57 ("decode: restructure the core decoding code"), the >

Re: [FFmpeg-devel] [PATCH] lavf/mov: fix huge alloc in mov_read_ctts

On 11/25/2017 05:03 PM, James Almer wrote: > On 11/25/2017 10:00 PM, John Stebbins wrote: >> On 11/25/2017 04:03 PM, Carl Eugen Hoyos wrote: >>> 2017-11-25 21:11 GMT+01:00 John Stebbins : An invalid file may cause huge alloc. Delay expansion of ctts entries until the number of samples is

Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

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 the discussion. There are two interfaces worth considering in this discussion: the applicat

Re: [FFmpeg-devel] [PATCH] lavf/mov: fix huge alloc in mov_read_ctts

On 11/26/2017 3:10 PM, John Stebbins wrote: > Is there some git magic for this, or is this just something you add manually > to the bottom of the commit message? It's just manual. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffm

[FFmpeg-devel] [PATCH] lavf/mov: fix huge alloc in mov_read_ctts

An invalid file may cause huge alloc. Delay expansion of ctts entries until the number of samples is known in mov_build_index. Found-by: zhao dongzhuo, AD-lab of Venustech --- libavformat/mov.c | 31 +++ 1 file changed, 27 insertions(+), 4 deletions(-) diff --git a/l

Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

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 the > discussion. > > There are two i

Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

-Original Message- From: hydra3...@gmail.com Sent: Sunday, November 26, 2017 11:37 PM To: ffmpeg-devel@ffmpeg.org Cc: hydra Subject: Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters OK, the experimental -opencl_bench option has been removed by recent commits. Thank you

Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

On 26/11/17 13:07, hydra3...@gmail.com wrote: > OK, the experimental -opencl_bench option has been removed by recent commits. > Thank you for the updates to OpenCL. > > It cross-compiles OK, however I'm not sure about the replacement > functionality.  So, 2 things. > > 1. may I enquire how one a

Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

Most systems have a "clinfo" program which will list all the queryable properties of the available devices. From docs: -init_hw_device type[=name][:device[,key=value...]] Initialise a new hardware device of type type called name, using the given device parameters. If no name is specified

[FFmpeg-devel] [PATCH] avformat/matroskaenc: actually enforce the stream limit

Prevents out of array accesses. Adressess ticket #6873 Signed-off-by: James Almer --- libavformat/matroskaenc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index dad6d6c93f..06126781f8 100644 --- a/libavformat/matroskaenc.c +++

[FFmpeg-devel] fate/hap : add test for hap encoding

Hello, Patch in attach, add test for hap encoding (currently not cover) (patch 002) and move decoding tests to a separate file (patch 001) decoding can be test with make fate-hap SAMPLES=fate-suite/ and encoding can be test with make fate-hapenc SAMPLES=fate-suite/ Hap encoding need ffmpeg comp

Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

On 26/11/17 16:14, hydra3...@gmail.com wrote: > Most systems have a "clinfo" program which will list all the queryable > properties of the available devices. > >> From docs: > > -init_hw_device type[=name][:device[,key=value...]] >    Initialise a new hardware device of type type called name, us

[FFmpeg-devel] avcodec/huffyuvenc : try to call dsp with aligned data, and remove code duplication

Hello, in attach patchs 0001-avcodec-huffyuvenc-increase-scalar-loop-count and 0003-avcodec-huffyuvenc-sub_left_prediction_bgr32-call-ds like diff_bytes and diff_bytes16, have AVX2 version, increase the scalar loop to call the aligned version in most case 0002-avcodec-huffyuvenc-remove-code-d

[FFmpeg-devel] avcodec/utvideodec : use dsp add_median_pred for second line

Hello, Patch in attach dsp func need align16 data make only the start of the line in scalar, and call the dsp for the rest instead of process the entire line in scalar pass make fate-utvideo for me Martin 0001-avcodec-utvideodec-use-dsp-add_median_pred-for-secon.patch Description: Binary dat

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tile: add init_padding option

Paul B Mahol (2017-11-24): > Signed-off-by: Paul B Mahol > --- > doc/filters.texi | 4 > libavfilter/vf_tile.c | 12 +++- > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/doc/filters.texi b/doc/filters.texi > index 76929e4db5..11ce0482c2 100644 > --- a/doc/f

Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

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

Re: [FFmpeg-devel] [PATCH] lavc: reset codec on receiving packet after EOF in compat_decode

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

Re: [FFmpeg-devel] [PATCH] hls demuxer: add option to defer parsing of variants

>> +/* >> + * 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

Re: [FFmpeg-devel] [PATCH] avfilter: add normalize filter

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-

Re: [FFmpeg-devel] [PATCH] hls demuxer: add option to defer parsing of variants

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

Re: [FFmpeg-devel] [PATCH] hls demuxer: add option to defer parsing of variants

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

[FFmpeg-devel] [PATCH 1/3] ffmpeg: use avformat_init_output to initialize output files

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

[FFmpeg-devel] [PATCH 3/3] avformat: deprecate AVFMT_FLAG_AUTO_BSF

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

[FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

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 -

[FFmpeg-devel] avcodec/utvideodec : add x86 SIMD (SSSE3) for gradient prediction

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat: deprecate AVFMT_FLAG_AUTO_BSFr

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 _

Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section (v2)

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

Re: [FFmpeg-devel] [PATCH] Refactor Developer Docs, update dev list section (v2)

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

[FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat: deprecate AVFMT_FLAG_AUTO_BSFr

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

[FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

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

Re: [FFmpeg-devel] [PATCH 12/17] vaapi_decode: Ignore the profile when not useful

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

[FFmpeg-devel] [PATCH] avcodec: Implement vp8 nvdec hwaccel

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 |

Re: [FFmpeg-devel] [PATCH v3 3/3] error_resilience: remove avpriv_atomic usage

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/

[FFmpeg-devel] [PATCH] avcodec/error_resilience: Use atomic set on writing error_occurred per slice

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 +

Re: [FFmpeg-devel] [PATCH] avcodec: Implement vp8 nvdec hwaccel

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 >

[FFmpeg-devel] [PATCH 5/8] lavc/x86/flac_dsp_gpl: cosmetic whitespace alignment

--- 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

[FFmpeg-devel] [PATCH 0/8] left-overs of an ancient patch set for the flac encoder

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

[FFmpeg-devel] [PATCH 4/8] avcodec/flac: partially unroll loop in flac_enc_lpc_32

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

[FFmpeg-devel] [PATCH 2/8] avcodec/flac: add AVX2 version of the 16-bit LPC encoder

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

[FFmpeg-devel] [PATCH 8/8] checkasm: add tests for flacenc lpc coder

--- 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

[FFmpeg-devel] [PATCH 3/8] avcodec/flac: add SSE4.2 version of the 32-bit lpc encoder

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

[FFmpeg-devel] [PATCH 1/8] avcodec/flac: document limitations of the LPC encoder

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

[FFmpeg-devel] [PATCH 6/8] lavc/x86/flac_dsp_gpl: partially unroll 32-bit LPC encoder

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

[FFmpeg-devel] [PATCH 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: actually enforce the stream limit

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

Re: [FFmpeg-devel] [PATCH 5/8] lavc/x86/flac_dsp_gpl: cosmetic whitespace alignment

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

Re: [FFmpeg-devel] [PATCH 3/8] avcodec/flac: add SSE4.2 version of the 32-bit lpc encoder

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

Re: [FFmpeg-devel] [PATCH] tests/checkasm/float_dsp: Increase allowed difference for float_dsp.vector_dmul

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

Re: [FFmpeg-devel] [PATCH 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

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

Re: [FFmpeg-devel] [PATCH] tests/checkasm/float_dsp: Increase allowed difference for float_dsp.vector_dmul

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

Re: [FFmpeg-devel] [PATCH 6/8] lavc/x86/flac_dsp_gpl: partially unroll 32-bit LPC encoder

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

Re: [FFmpeg-devel] [PATCH 1/8] avcodec/flac: document limitations of the LPC encoder

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

Re: [FFmpeg-devel] [PATCH 2/8] avcodec/flac: add AVX2 version of the 16-bit LPC encoder

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

Re: [FFmpeg-devel] [PATCH 4/8] avcodec/flac: partially unroll loop in flac_enc_lpc_32

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

Re: [FFmpeg-devel] [PATCH 3/8] avcodec/flac: add SSE4.2 version of the 32-bit lpc encoder

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

Re: [FFmpeg-devel] [PATCH 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

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

Re: [FFmpeg-devel] [PATCH 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

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 +++-

Re: [FFmpeg-devel] [PATCH 6/8] lavc/x86/flac_dsp_gpl: partially unroll 32-bit LPC encoder

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,

Re: [FFmpeg-devel] [PATCH 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

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 +

Re: [FFmpeg-devel] [PATCH] avcodec: Implement vp8 nvdec hwaccel

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/kgv1dec: Check that there is enough input for maximum RLE compression

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

Re: [FFmpeg-devel] [PATCH] libavformat/mov: Replace duplicate stream_nb check by assert

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264idct_template: Fix integer overflow in ff_h264_idct8_add

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/

Re: [FFmpeg-devel] [PATCH] avcodec/mlpdsp: Fix signed integer overflow, 2nd try

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

Re: [FFmpeg-devel] [PATCH 3/3] tests/fate-run: Use -bitexact

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

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

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

  1   2   >