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
-sample_rate_fallba
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 packages w/ apt-get:
>
> apt-get
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
___
2017-03-07 7:37 GMT+01:00 wm4 :
> I still think that it's moronic bullshit to disable lavr by default.
> How about you don't take your moronic fork drama bullshit out on your
> API users?
How about you stop breaking development rules for once?
Carl Eugen
_
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
> merge conflict free.
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
> index eee322b..1d05fc1 100644
> --- a/
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 better and doesn't depend on
> >>> libav
./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 i
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 | 4 +---
On Tue, Mar 07, 2017 at 12:20:20AM +0200, Jan Ekström wrote:
> 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 d
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
>
> ibavcodec/allcodecs.c
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’:
libavcodec/allcodecs.c:68
Signed-off-by: Michael Niedermayer
---
libavcodec/vp8.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 8039e7817e..a3d057d62e 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -2504,8 +2504,6 @@ int vp78_decode_mb_row_sliced(AVCodecContext *av
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 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/pictor
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 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/wavpack.
Fixes: timeout in 730/clusterfuzz-testcase-5265113739165696
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vp5.c | 5 -
libavcodec/vp56.h| 2 +-
libavcodec/vp56rac.c | 5 -
l
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
> wrappe
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. What about the builds t
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?
>
You mean that libr
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
ffmpeg-devel@ffmpeg.org
http://ff
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 thi
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 @@ fo
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 fea
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
ind
---
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 quantization
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 -
libavfilter/Makefile|
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 Mon, Mar 6, 2017 at
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
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 dev
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 wou
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.
>>
>> ---
>> libavcodec/libvpxenc.c | 11 +++
>> 1 file chang
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
+++ b/libavfilter/allfilters.c
@@ -19,6 +19
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
+++ b/libavformat/allformats.c
@@ -19,6 +19,8
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 pr
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
@@ -24,6 +24,8 @@
*
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
--- a/libavdevice/alldevices.c
+++ b/lib
From: Aman Gupta
---
libavcodec/mpeg12dec.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 27db14c..8cafdb0 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2260,6 +2260,44 @@ s
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 fingerprint: 9FF2128B147EF6730BAD
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 detect and reconstruct missing lin
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 cod
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 curren
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 +
> libavfilter/vf_vmaf
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 this.
>>
>> The irr
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
>
> >>
> >> 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.
> ___
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 multiple layers. If there is any interest
>> > in
>> > this
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 punishment
> is most
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 t
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,
> > I can add support. Someone just needs
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 some
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 make it look like it
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
> ---
> libavcode
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 takes a comma separate
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
r
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 that again.
Actual
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 kep
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
0001-
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 0
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 deemed to be good
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 | 1
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 careles
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 in FFmpeg?
>
> This is offtopic and
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 a
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
>> ---
>> libswresample/resample.c
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 CPU, because no progress is
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 logical fallacy in
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
> kCVPixelBufferOpenGLESCompatibilityKey for iOS
>
> kCVPixelBufferIOS
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
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Tue, Feb 21, 2017 a
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. I
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 wrote:
> > > > Hi
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 soxr defaults.
__
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,
>> > >
>> > > On Sun, Mar 5, 2017 a
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, wrote:
> > >
> > > > On Mon, Feb
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
http://ffmpeg.org/mailman/listinfo/ffmpeg-d
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 remove the "aresample" filter that is men
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 list
ffmpeg-devel@ffmpeg.org
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 not support he 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 |
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@ffmpeg.o
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.
---
libavformat/matro
80 matches
Mail list logo
