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

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 => 88.2ksps -sample_rate_fallback higher2x => 176.4ksps

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

2017-03-07 6:36 GMT+01:00 Thomas Turner : > ./configure command worked without ccache: > > ./configure --enable-debug=3 --arch=x86_32 --target-os=linux > --extra-cflags=-m32 --extra-ldflags=-m32 --enable-cross-compile > > but after installing the following software

Re: [FFmpeg-devel] [PATCH 1/2] libx264: remove the "x264opts" AVOption

2017-03-06 23:20 GMT+01:00 Jan Ekström : > x264-params does the same thing and this leaves us with a single > option that is name-matched with x265-params available in the > libx265 wrapper. (Why?) You have to deprecate an option before removing it. Carl Eugen

Re: [FFmpeg-devel] [PATCH] Revert "lavu/atomic: add support for the new memory model aware gcc built-ins"

On Tue, 7 Mar 2017 00:29:53 -0300 James Almer wrote: > This reverts commit faa9d2982969c999ab0e443a226eff116f7f8e4b. > > This change became superfluous when support for C11 atomics was introduced. > Reverting it will make the removal of this implementation in an upcoming >

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/allcodecs: make avcodec_register_all thread safe

On Tue, 7 Mar 2017 02:47:36 +0700 Muhammad Faiz wrote: > Signed-off-by: Muhammad Faiz > --- > libavcodec/allcodecs.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c >

Re: [FFmpeg-devel] [PATCH 1/4] lavfi: remove af_resample

On Mon, 6 Mar 2017 20:58:53 -0300 James Almer wrote: > On 3/6/2017 8:20 PM, Rostislav Pehlivanov wrote: > > On 6 March 2017 at 22:45, James Almer wrote: > > > >> On 3/5/2017 11:46 PM, Rostislav Pehlivanov wrote: > >>> af_aresample does the same thing

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

./configure command worked without ccache: ./configure --enable-debug=3 --arch=x86_32 --target-os=linux --extra-cflags=-m32 --extra-ldflags=-m32 --enable-cross-compile but after installing the following software packages w/ apt-get: apt-get install gcc-multilib g++-mult after recompiling and

[FFmpeg-devel] [PATCH] Revert "lavu/atomic: add support for the new memory model aware gcc built-ins"

This reverts commit faa9d2982969c999ab0e443a226eff116f7f8e4b. This change became superfluous when support for C11 atomics was introduced. Reverting it will make the removal of this implementation in an upcoming merge conflict free. Signed-off-by: James Almer --- configure

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/allcodecs: make avcodec_register_all thread safe

On 3/6/2017 11:55 PM, Michael Niedermayer wrote: > On Tue, Mar 07, 2017 at 02:47:36AM +0700, Muhammad Faiz wrote: >> Signed-off-by: Muhammad Faiz >> --- >> libavcodec/allcodecs.c | 13 ++--- >> 1 file changed, 10 insertions(+), 3 deletions(-) > > fails to build > >

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/allcodecs: make avcodec_register_all thread safe

On Tue, Mar 07, 2017 at 02:47:36AM +0700, Muhammad Faiz wrote: > Signed-off-by: Muhammad Faiz > --- > libavcodec/allcodecs.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) fails to build ibavcodec/allcodecs.c: In function ‘avcodec_register_all’:

Re: [FFmpeg-devel] [RFC] Removal of the "x264opts" libx264 wrapper AVOption

On Tue, 7 Mar 2017 00:20:19 +0200, Jan Ekström wrote: > Hi, > > I am not sure what the correct order of things to remove an AVOption is, > but I would like to propose that the "x264opts" AVOption be removed, as it > duplicates "x264-params", which has a matching pair over at the libx265 >

Re: [FFmpeg-devel] [PATCH 1/4] lavfi: remove af_resample

On 3/6/2017 8:20 PM, Rostislav Pehlivanov wrote: > On 6 March 2017 at 22:45, James Almer wrote: > >> On 3/5/2017 11:46 PM, Rostislav Pehlivanov wrote: >>> af_aresample does the same thing better and doesn't depend on >>> libavresample >> >> But it depends on libswresample.

Re: [FFmpeg-devel] [PATCH 1/4] lavfi: remove af_resample

On 6 March 2017 at 22:45, James Almer wrote: > On 3/5/2017 11:46 PM, Rostislav Pehlivanov wrote: > > af_aresample does the same thing better and doesn't depend on > > libavresample > > But it depends on libswresample. What about the builds that are using > lavr but nor lswr? >

Re: [FFmpeg-devel] [PATCH 2/2] doc/encoders: remove mentions of the x264opts AVOption

On Tue, Mar 7, 2017 at 12:44 AM, Marton Balint wrote: > I guess you meant to convert this to -x264-params as well, no? > > Thanks, > Marton Yup, welcome to doing things after midnight. Jan ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH 1/4] lavfi: remove af_resample

On 3/5/2017 11:46 PM, Rostislav Pehlivanov wrote: > af_aresample does the same thing better and doesn't depend on > libavresample But it depends on libswresample. What about the builds that are using lavr but nor lswr? Is the purpose of this set to pave the way for a lavr removal? Because one

Re: [FFmpeg-devel] [PATCH 2/2] doc/encoders: remove mentions of the x264opts AVOption

On Tue, 7 Mar 2017, Jan Ekström wrote: --- doc/encoders.texi | 25 ++--- 1 file changed, 6 insertions(+), 19 deletions(-) diff --git a/doc/encoders.texi b/doc/encoders.texi index 594c612..ee28b9b 100644 --- a/doc/encoders.texi +++ b/doc/encoders.texi @@ -1762,9 +1762,9 @@

[FFmpeg-devel] [RFC] Removal of the "x264opts" libx264 wrapper AVOption

Hi, I am not sure what the correct order of things to remove an AVOption is, but I would like to propose that the "x264opts" AVOption be removed, as it duplicates "x264-params", which has a matching pair over at the libx265 wrapper. Also, this way we would get rid of one in a group of similar

[FFmpeg-devel] [PATCH 2/2] doc/encoders: remove mentions of the x264opts AVOption

--- doc/encoders.texi | 25 ++--- 1 file changed, 6 insertions(+), 19 deletions(-) diff --git a/doc/encoders.texi b/doc/encoders.texi index 594c612..ee28b9b 100644 --- a/doc/encoders.texi +++ b/doc/encoders.texi @@ -1762,9 +1762,9 @@ for detail retention (adaptive

[FFmpeg-devel] [PATCH 1/2] libx264: remove the "x264opts" AVOption

x264-params does the same thing and this leaves us with a single option that is name-matched with x265-params available in the libx265 wrapper. --- libavcodec/libx264.c | 29 - 1 file changed, 29 deletions(-) diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c

Re: [FFmpeg-devel] [PATCH 4/4] lavfi: remove af_asynts filter

On Mon, 6 Mar 2017, Rostislav Pehlivanov wrote: Long overdue for removal, af_aresample should be used instead. Signed-off-by: Rostislav Pehlivanov --- Changelog | 1 + configure | 2 - doc/filters.texi| 33 -

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

Sorry, another change: switched irreversible default to 0, which matches the OpenJPEG default (i.e. lossless is the default) On Mon, Mar 6, 2017 at 11:10 AM, Aaron Boxer wrote: > One last change: numresolution default setting changed to 6, to match > OpenJPEG default. > > On

Re: [FFmpeg-devel] [PATCH 1/2] (was Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold...) formats.

Hello Karl, I appreciate your interest and comments. Keeping on topic, to the patch decision makers: I actually complied with all real suggestions heard during the discussion, even with those I find being misdirected, i.e. virtually everything except dropping the patch as a whole. Now I am

[FFmpeg-devel] opencl on osx

all, i have compiled ffmpeg with opencl on osx 10.12 but.. when i run the benchmark ffmpeg -opencl_bench i get this error clEnqueueNDRangeKernel error 'INVALID WORK GROUP SIZE' [opencl @ 0x10ad10ea8] Benchmark failed with OpenCL device Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz platform_idx   

Re: [FFmpeg-devel] [PATCH] lswr: remove support for libsoxr resampling

On Mon, Mar 06, 2017 at 03:19:48AM +, Rostislav Pehlivanov wrote: > The soxr resampler is slower and worse than the swr resampler, > hence drop the former. With git master of ffmpeg and libsoxr 0.1.1, using default parameters, on x86, soxr is indeed a little slower than swr; however many

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add -row-mt option

On Fri, Mar 3, 2017 at 4:52 PM, James Zern wrote: > On Fri, Mar 3, 2017 at 2:20 AM, Kagami Hiiragi wrote: >> [...] >> >> Updated. I don't think -slices would fit logically because -row-mt is >> boolean and -slices is integer. >> >> --- >>

[FFmpeg-devel] [PATCH 3/4] avfilter/allfilters: make avfilter_register_all thread safe

Signed-off-by: Muhammad Faiz --- libavfilter/allfilters.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index 15a74c4..2042b35 100644 --- a/libavfilter/allfilters.c +++

[FFmpeg-devel] [PATCH 2/4] avformat/allformats: make av_register_all thread safe

Signed-off-by: Muhammad Faiz --- libavformat/allformats.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/libavformat/allformats.c b/libavformat/allformats.c index 35869e3..e91a59b 100644 --- a/libavformat/allformats.c +++

Re: [FFmpeg-devel] [PATCH] Fix off-by-few crasher in ff_h2645_extract_rbsp function

On Mon, Mar 06, 2017 at 03:51:51PM +0100, Michał Krasowski wrote: > It seems that the loop tried to access the memory regions > beyond allocation, what caused crashes in not-so-rare cases, when > the memory read did not belong to current process. > > This change is fixing the out-of-bounds read

[FFmpeg-devel] [PATCH 1/4] avcodec/allcodecs: make avcodec_register_all thread safe

Signed-off-by: Muhammad Faiz --- libavcodec/allcodecs.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index eee322b..1d05fc1 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@

[FFmpeg-devel] [PATCH 4/4] avdevice/alldevice: make avdevice_register_all thread safe

Signed-off-by: Muhammad Faiz --- libavdevice/alldevices.c | 13 ++--- libavdevice/avdevice.h | 1 - 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c index a761be4..cc8b8ce 100644 ---

Re: [FFmpeg-devel] [PATCH 2/4] ffmpeg: don't use resample_lavr_opts

On Mon, Mar 06, 2017 at 02:46:49AM +, Rostislav Pehlivanov wrote: > That pointer isn't used by absolutely anything. > > Signed-off-by: Rostislav Pehlivanov > --- > ffmpeg_filter.c | 1 - > 1 file changed, 1 deletion(-) LGTM thx [...] -- Michael GnuPG

Re: [FFmpeg-devel] [PATCH] avcodec/exr

On 3/6/17, Dzung Hoang wrote: > The EXR decoder cannot handle the image files included in NVidia's HDR SDK. > After debugging, I found that the line offset table in the image files > contained 0's. Other EXR decoders, including the official OpenEXR decoder, > can

[FFmpeg-devel] [PATCH] avcodec/exr

The EXR decoder cannot handle the image files included in NVidia's HDR SDK. After debugging, I found that the line offset table in the image files contained 0's. Other EXR decoders, including the official OpenEXR decoder, can detect and reconstruct missing line offset tables, so I added some

Re: [FFmpeg-devel] [PATCH 1/2] (was Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold...) formats.

On 2017-03-06 15:12, u-9...@aetey.se wrote: Karl, I wish to thank you for the effort to make the "opposite" parties to better understand each other. As you say, indeed the patch makes a move which looks in line with ffmpeg's former traditions but which at least formally collides with the

Re: [FFmpeg-devel] [PATCH] Added vmaf filter linking to netflix's vmaf repo. It may not necessarily be suitable for adding into mainline since it uses fork/pipe and exec for calling vmaf scripts. It i

On Sun, Mar 05, 2017 at 02:25:03AM +0530, Ashish Singh wrote: > From: ashk43712 > > Compiled Netflix's vmaf repo needs to be present inside libavfilter directory > for it to run successfully. > > --- > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 +

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

One last change: numresolution default setting changed to 6, to match OpenJPEG default. On Mon, Mar 6, 2017 at 10:49 AM, Aaron Boxer wrote: > >> >> >> This was vertically algined. Now its not any more. >> >> >> > >> > >> > How is this? Feels like doing ASCII artwork to format

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, Mar 06, 2017 at 04:31:32PM +0100, wm4 wrote: > On Mon, 6 Mar 2017 16:23:15 +0100 > u-9...@aetey.se wrote: > > > Did the project (who?) ever make a general decision about Cinepak > > or delegate to wm4 to represent the project's stance? > > > > I question her/his tone, not the policy, but

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

> > >> > >> This was vertically algined. Now its not any more. > >> > > > > > > How is this? Feels like doing ASCII artwork to format this. > > The irreversible thing is not used at all, its just blank option. > Yes, quite right. Here is an updated patch. >

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

On 3/6/17, Aaron Boxer wrote: > On Mon, Mar 6, 2017 at 10:04 AM, Paul B Mahol wrote: > >> On 3/6/17, Aaron Boxer wrote: >> > I limited encoder to single quality layer, since there is currently no >> way >> > of specifying distortion for

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

Hi, On Mon, Mar 6, 2017 at 9:52 AM, wrote: > I am sorry for misrepresentation of the statements of wm4! > No problem. Now Ronald where were you with your policing > when the person in question (wm4) repeatedly violated CoC? > > I point out that your behaviour of selective

Re: [FFmpeg-devel] [PATCH] avcodec/proresdec2: Do not discard frames with bad slices

On Sat, Mar 04, 2017 at 03:59:50AM +0100, Marton Balint wrote: > > On Sat, 4 Mar 2017, Michael Niedermayer wrote: > > >The code previously completely discarded frames that had any error in a slice > > Could you set either AVFrame->flags to AV_FRAME_FLAG_CORRUPT or > AVFrame->decode_error_flags

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

On Mon, Mar 6, 2017 at 10:04 AM, Paul B Mahol wrote: > On 3/6/17, Aaron Boxer wrote: > > I limited encoder to single quality layer, since there is currently no > way > > of specifying distortion for multiple layers. If there is any interest in > > this, > >

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, 6 Mar 2017 16:23:15 +0100 u-9...@aetey.se wrote: > Did the project (who?) ever make a general decision about Cinepak > or delegate to wm4 to represent the project's stance? > > I question her/his tone, not the policy, but what is the latter > when not refracted through your, wm4's or

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, Mar 06, 2017 at 08:19:06AM -0500, Ronald S. Bultje wrote: > On Mon, Mar 6, 2017 at 7:08 AM, wrote: > > > It is clear that you personally do not want the Cinepak decoder to be able > > to output multiple pixel formats, for unspecified reasons ("by choice"). > > > > You

Re: [FFmpeg-devel] [PATCH] avcodec/movtextdec: Call mov_text_cleanup() on close

On Sat, Mar 04, 2017 at 08:58:48PM +0100, Michael Niedermayer wrote: > Fixes memleak > Fixes: 548/clusterfuzz-testcase-5511470875934720 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

On 3/6/17, Aaron Boxer wrote: > I limited encoder to single quality layer, since there is currently no way > of specifying distortion for multiple layers. If there is any interest in > this, > I can add support. Someone just needs to tell me how to create an > AVOption which

[FFmpeg-devel] [PATCH] Fix off-by-few crasher in ff_h2645_extract_rbsp function

It seems that the loop tried to access the memory regions beyond allocation, what caused crashes in not-so-rare cases, when the memory read did not belong to current process. This change is fixing the out-of-bounds read problem. Compiling this function with -fsanitize=address and running doesn't

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, Mar 06, 2017 at 08:19:06AM -0500, Ronald S. Bultje wrote: > Hi, > > On Mon, Mar 6, 2017 at 7:08 AM, wrote: > > > You did not have to pay attention to the patch, given your limited > > understanding of the matter > > > And this is a CoC [1] violation, please don't do

Re: [FFmpeg-devel] lavc/aarch64: add simple idct neon functions

On Thu, Feb 23, 2017 at 04:59:16PM +0100, Matthieu Bouron wrote: > Hello, > > The following patchset add the ff_simple_idct function neon functions for the > aarch64 platform. It's ported from armv7 simple_idct_neon with some > improvements: > * the source idct blocks are now loaded once and

[FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

I limited encoder to single quality layer, since there is currently no way of specifying distortion for multiple layers. If there is any interest in this, I can add support. Someone just needs to tell me how to create an AVOption which takes a comma separated list of doubles. Cheers, Aaron

Re: [FFmpeg-devel] [PATCH 1/2] (was Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold...) formats.

Karl, I wish to thank you for the effort to make the "opposite" parties to better understand each other. As you say, indeed the patch makes a move which looks in line with ffmpeg's former traditions but which at least formally collides with the currently percepted "best practices". On Mon, Mar

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

Hi, On Mon, Mar 6, 2017 at 7:08 AM, wrote: > It is clear that you personally do not want the Cinepak decoder to be able > to output multiple pixel formats, for unspecified reasons ("by choice"). > > You make it look like it is your discretion who decides whether something > is

Re: [FFmpeg-devel] [PATCH] lswr: remove support for libsoxr resampling

On Mon, Mar 06, 2017 at 03:19:48AM +, Rostislav Pehlivanov wrote: > The soxr resampler is slower and worse than the swr resampler, > hence drop the former. > > Signed-off-by: Rostislav Pehlivanov > --- > Changelog | 1 + > MAINTAINERS

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

To everyone: I am really sorry for having to react to this kind of irrational arguments. OTOH keeping silence could be interpreted as accepting them. As far as my common sense goes, I can not count these as "pending comments". TL;DR: trying to reason, given the arbitrary statements and

Re: [FFmpeg-devel] OT: Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On 3/6/17, u-9...@aetey.se wrote: > On Mon, Mar 06, 2017 at 10:19:33AM +0100, Paul B Mahol wrote: >> On 3/6/17, u-9...@aetey.se wrote: >> > I do have respect for your work and competence. >> > Please do the same to others. >> >> What is your Work and Competence

Re: [FFmpeg-devel] [PATCH 1/2] (was Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold...) formats.

Hi, It is regrettable that the positions are so entrenched here, but I agree with the majority opinion that pushing this really isn't a good idea, nor do I understand the reasons it's even desirable in the first place. The core issue here, I think, is fundamentally different views of software

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

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 gives better frequency response >> >> update swresample fate and other fates >> that depend on resampling >> >> Signed-off-by: Muhammad Faiz

Re: [FFmpeg-devel] [PATCH v2 1/2] lavc: consider an error during decoder draining as EOF

On Thu, 2 Mar 2017 10:45:23 +0100 wm4 wrote: > There is no reason that draining couldn't return an error or two. But > some decoders don't handle this very well, and might always return an > error. This can lead to API users getting into an infinite loop and > burning

[FFmpeg-devel] OT: Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, Mar 06, 2017 at 10:19:33AM +0100, Paul B Mahol wrote: > On 3/6/17, u-9...@aetey.se wrote: > > I do have respect for your work and competence. > > Please do the same to others. > > What is your Work and Competence in FFmpeg? This is offtopic and looks like ad hominem "a

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey

On Fri, 3 Mar 2017 18:16:18 +0800 Wang Bin wrote: > From 011d03c4d2b6b138de539dcf5019169781ee7fb2 Mon Sep 17 00:00:00 2001 > From: wang-bin > Date: Fri, 3 Mar 2017 18:10:54 +0800 > Subject: [PATCH] avcodec/videotoolbox: set >

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264, videotoolbox: fix crash after VT decoder fails

On Thu, 2 Mar 2017 09:58:28 -0800 Aman Gupta wrote: > On Thu, Mar 2, 2017 at 1:34 AM, wm4 wrote: > > > On Tue, 21 Feb 2017 13:40:08 -0800 > > Aman Gupta wrote: > > > > > On Tue, Feb 21, 2017 at 1:04 PM, Ronald S. Bultje

[FFmpeg-devel] [PATCH] avcodec: clarify some decoding/encoding API details

Make it clear that there is no timing-dependent behavior. In particular, there is no state in which both input and output are denied, and where you have to wait for a while yourself to make progress (apparently some hardware decoders like to do this). Avoid wording that makes references to time.

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Mon, 6 Mar 2017 10:15:44 +0100 u-9...@aetey.se wrote: > On Sun, Mar 05, 2017 at 06:20:34PM -0500, Ronald S. Bultje wrote: > > Hi Rune, > > > > On Sun, Mar 5, 2017 at 4:26 PM, wrote: > > > > > Ronald, > > > > > > On Sun, Mar 05, 2017 at 02:38:31PM -0500, Ronald S. Bultje

Re: [FFmpeg-devel] [PATCH] lswr: remove support for libsoxr resampling

On 3/6/17, Rostislav Pehlivanov wrote: > The soxr resampler is slower and worse than the swr resampler, > hence drop the former. Why you think its worse? There are some popular tests with all resampleres being tested and I can confirm that swr defaults are hardly better than

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On 3/6/17, u-9...@aetey.se wrote: > On Sun, Mar 05, 2017 at 06:20:34PM -0500, Ronald S. Bultje wrote: >> Hi Rune, >> >> On Sun, Mar 5, 2017 at 4:26 PM, wrote: >> >> > Ronald, >> > >> > On Sun, Mar 05, 2017 at 02:38:31PM -0500, Ronald S. Bultje wrote: >> > > Hi,

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

On Sun, Mar 05, 2017 at 06:20:34PM -0500, Ronald S. Bultje wrote: > Hi Rune, > > On Sun, Mar 5, 2017 at 4:26 PM, wrote: > > > Ronald, > > > > On Sun, Mar 05, 2017 at 02:38:31PM -0500, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Sun, Mar 5, 2017 at 2:22 PM,

Re: [FFmpeg-devel] libopenjpegenc initialization

2017-03-06 3:19 GMT+01:00 Aaron Boxer : > Also, there doesn't seem to be any way of setting lossy vs. lossless > encoding. Please send a patch. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] lavfi: rename af_aresample to af_resample

On 6 March 2017 at 09:00, Carl Eugen Hoyos wrote: > 2017-03-06 9:48 GMT+01:00 Rostislav Pehlivanov : > > > +AVFilter ff_af_resample = { > > +.name = "resample", > > Why? Do we really need two identical filters with similar name? > > We cannot

Re: [FFmpeg-devel] [PATCH] matroska: add DSD support

2017-03-06 9:00 GMT+01:00 Takayuki 'January June' Suwa : > +{"A_PDM/DSD/LSBF" , AV_CODEC_ID_DSD_LSBF}, > +{"A_PDM/DSD/MSBF" , AV_CODEC_ID_DSD_MSBF}, Where are they specified? Carl Eugen ___ ffmpeg-devel mailing

Re: [FFmpeg-devel] [PATCH] lavfi: rename af_aresample to af_resample

2017-03-06 9:48 GMT+01:00 Rostislav Pehlivanov : > +AVFilter ff_af_resample = { > +.name = "resample", Why? Do we really need two identical filters with similar name? We cannot remove the "aresample" filter that is mentioned all over our documentation. We did

[FFmpeg-devel] [PATCH] lavfi: rename af_aresample to af_resample

Meant to be applied on top of the patch which removes af_resample Registers both af_aresample and af_resample as valid filters to mainain compatibility. Signed-off-by: Rostislav Pehlivanov --- MAINTAINERS | 2 +- libavfilter/Makefile

Re: [FFmpeg-devel] [PATCH 1/4] lavfi: remove af_resample

On 6 March 2017 at 07:51, wm4 wrote: > > I'd rather remove af_aresample.c (and port af_resample.c to > libswsresample or whatever if you want), because af_resample.c has the > better filter name. > ___ > ffmpeg-devel mailing list

[FFmpeg-devel] [PATCH] matroska: add DSD support

this patch makes transporting several (low-bitrate to hi-res) music data more simpler. almost major/defacto-std lossy/lossless audio codecs such as MP3, AAC, FLAC, etc. and now DSD can be muxed by the single way :) global/per-stream metadata seems to be exported correctly. ---