On 20 November 2016 at 17:05, Kieran Kunhya wrote:
> I object to this patch for the reasons Rostislav outlined..
>
> Kieran
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
I actually don't
On 17 November 2016 at 00:08, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> All the fields can be set via options read from the ffm file and thus
> have to be sanitized.
>
> A negative extradata size for example gets passed to memcpy in
> avcodec_parameters_from_context causing a
On Sun, Nov 20, 2016 at 08:40:24PM +0100, Andreas Cadhalpun wrote:
> On 20.11.2016 13:42, Carl Eugen Hoyos wrote:
> > 2016-11-19 17:30 GMT+01:00 Andreas Cadhalpun
> > :
> >
> >> A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
> >> convinced me that it should be avoided.
> >
> >
This reverts d300f5f6f570659e4b58567b35c9e8600c9f2956.
Further reference:
https://ffmpeg.org/pipermail/ffmpeg-devel/2013-October/149935.html
I can't reproduce ticket #2899 so I am not sure the original patch is still
needed. Reverting it fixes unknown channel layout support for trivial
resamples,
On Mon, Nov 21, 2016 at 1:10 AM, Carl Eugen Hoyos wrote:
> 2016-11-21 0:24 GMT+01:00 Hendrik Leppkes :
>> On Sun, Nov 20, 2016 at 9:06 PM, Carl Eugen Hoyos wrote:
>>> 2016-11-20 21:02 GMT+01:00 Timo Rothenpieler :
I don't really like outputting P016 as P010.
I'd prefer to add support fo
2016-11-21 0:24 GMT+01:00 Hendrik Leppkes :
> On Sun, Nov 20, 2016 at 9:06 PM, Carl Eugen Hoyos wrote:
>> 2016-11-20 21:02 GMT+01:00 Timo Rothenpieler :
>>> I don't really like outputting P016 as P010.
>>> I'd prefer to add support for P016 to ffmpeg and swscale, which
>>> shouldn't be too hard as
On Sun, Nov 20, 2016 at 9:06 PM, Carl Eugen Hoyos wrote:
> 2016-11-20 21:02 GMT+01:00 Timo Rothenpieler :
>> I don't really like outputting P016 as P010.
>> I'd prefer to add support for P016 to ffmpeg and swscale, which
>> shouldn't be too hard as most P010 code can be reused.
>
> Or change the e
On Thu, 17 Nov 2016, Josh de Kock wrote:
On 17/11/2016 21:18, Marton Balint wrote:
Signed-off-by: Marton Balint
---
ffplay.c | 4
1 file changed, 4 insertions(+)
diff --git a/ffplay.c b/ffplay.c
index 12502f2..63c0e19 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -1282,6 +1282,10 @@ static i
On Tue, 15 Nov 2016, Marton Balint wrote:
This fixes the crash reported in ticket #5947.
Signed-off-by: Marton Balint
---
ffplay.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
Applied.
Regards,
Marton
___
ffmpeg-devel mai
2016-11-19 17:37 GMT+01:00 Josh de Kock :
> I've mapped a fair amount of the CoreMedia FourCCs to their
> respective AVCodecIDs. The ones I didn't know or thought didn't
> exist in FFmpeg have been mapped to AV_CODEC_ID_NONE.
Could you explain the use-case for these mappings?
Carl Eugen
_
P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
two bytes per component.
It may, and in fact is most likely to, be used in situations where
there are less than 16 bits of data. It is the responsibility of
the writer to zero out any unused LSBs.
Signed-off-by: Philip Langdal
It's pretty much P010 with the low 6 bits explicitly allowed to contain
data. I did not attempt to implement any fast path conversion for P010.
Someone could obviously add that if desired.
Philip Langdale (2):
avutil: add P016 pixel format
swscale: add P016 input support
libavutil/pixdesc.c
Signed-off-by: Philip Langdale
---
libswscale/input.c | 32
libswscale/utils.c | 2 ++
2 files changed, 34 insertions(+)
diff --git a/libswscale/input.c b/libswscale/input.c
index 1f4ea18..8b5f348 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -719,
On 11/17/2016 3:52 PM, James Almer wrote:
> On 11/2/2016 4:58 PM, James Almer wrote:
>> This will allow us to write updated stream information not available
>> during write_header().
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/matroskaenc.c | 20 +++-
>> 1 file changed,
On Sun, 20 Nov 2016 17:13:01 -0500
"Ronald S. Bultje" wrote:
> Hi,
>
> On Sun, Nov 20, 2016 at 4:59 PM, Philip Langdale
> wrote:
>
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index 96860ce..4cd3a77 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -297,6
Hi,
On Sun, Nov 20, 2016 at 4:59 PM, Philip Langdale wrote:
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 96860ce..4cd3a77 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -297,6 +297,8 @@ enum AVPixelFormat {
>
> AV_PIX_FMT_P010LE, ///< like NV12, with 10b
P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
two bytes per component.
It may, and in fact is most likely to, be used in situations where
there are less than 16 bits of data. It is the responsibility of
the writer to zero out any unused LSBs.
Signed-off-by: Philip Langdal
2016-11-19 1:44 GMT+01:00 Michael Niedermayer :
> On Thu, Nov 17, 2016 at 01:09:53PM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch adds support for 12bit formats to ffv1.
>>
>> Please comment, Carl Eugen
>
>> ffv1dec.c |7 +++
>> ffv1enc.c | 11 +--
>> 2 files change
On Sun, Nov 20, 2016 at 08:55:44PM +0100, Andreas Cadhalpun wrote:
> On 20.11.2016 12:57, Michael Niedermayer wrote:
> > Requested-by: wm4 ([FFmpeg-devel] [PATCH] avutil/opt: Support max >
> > INT64_MAX in write_number() with AV_OPT_TYPE_INT64)
> > Requested-by: ronald ([FFmpeg-devel] [PATCH] avut
On Sun, Nov 20, 2016 at 08:53:19PM +0100, Andreas Cadhalpun wrote:
> On 20.11.2016 12:57, Michael Niedermayer wrote:
> > Found-by: Andreas
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavutil/opt.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib
2016-11-20 19:48 GMT+01:00 Andreas Cadhalpun :
> On 20.11.2016 13:38, Carl Eugen Hoyos wrote:
>> 2016-11-20 1:07 GMT+01:00 Andreas Cadhalpun
>> :
>>> gcc before gcc-5 reserves a register on x86_32 for the GOT, when PIE is
>>> enabled.
>>>
>>> This fixes build failures due to:
>>> error: 'asm' oper
2016-11-20 21:02 GMT+01:00 Timo Rothenpieler :
> I don't really like outputting P016 as P010.
> I'd prefer to add support for P016 to ffmpeg and swscale, which
> shouldn't be too hard as most P010 code can be reused.
Or change the existing P010 code to actually handle P016...
(And do a rename on t
2016-11-20 20:40 GMT+01:00 Andreas Cadhalpun :
> On 20.11.2016 13:42, Carl Eugen Hoyos wrote:
>> 2016-11-19 17:30 GMT+01:00 Andreas Cadhalpun
>> :
>>
>>> A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
>>> convinced me that it should be avoided.
>>
>> I believe that ffm should (or
I don't really like outputting P016 as P010.
I'd prefer to add support for P016 to ffmpeg and swscale, which
shouldn't be too hard as most P010 code can be reused.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ff
On 20.11.2016 12:57, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/options_table.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index 48de667..ee79859 100644
> --- a/lib
On 20.11.2016 12:57, Michael Niedermayer wrote:
> Requested-by: wm4 ([FFmpeg-devel] [PATCH] avutil/opt: Support max > INT64_MAX
> in write_number() with AV_OPT_TYPE_INT64)
> Requested-by: ronald ([FFmpeg-devel] [PATCH] avutil/opt: Support max >
> INT64_MAX in write_number() with AV_OPT_TYPE_INT64
On 20.11.2016 12:57, Michael Niedermayer wrote:
> Found-by: Andreas
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/opt.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index cd16bd1..6669356 100644
> --- a/libavutil/op
The nvidia 375.xx driver introduces support for P016 output surfaces,
for 10bit and 12bit HEVC content (it's also the first driver to support
hardware decoding of 12bit content).
Technically, we don't support P016, but in practice I don't think we
zero-out the extra bits in P010 so it can be used
On 20.11.2016 13:42, Carl Eugen Hoyos wrote:
> 2016-11-19 17:30 GMT+01:00 Andreas Cadhalpun
> :
>
>> A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
>> convinced me that it should be avoided.
>
> I believe that ffm should (or at least can) indeed be treated differently
> from al
On 20.11.2016 03:41, Michael Niedermayer wrote:
> On Sun, Nov 20, 2016 at 12:37:05AM +0100, Andreas Cadhalpun wrote:
>
>> ffmdec.c | 52 ++--
>> 1 file changed, 42 insertions(+), 10 deletions(-)
>> a565a670592ad6455e9f26e95edf9886b426dfb3
>> 000
On 11/21/16, Michael Niedermayer wrote:
> On Sun, Nov 20, 2016 at 03:56:28PM +0700, Muhammad Faiz wrote:
>> this allow to use phase_count_compensation on init (rather than
>> rebuild on swr_set_compensation) when options suggest that
>> soft compensation is enabled
>>
>> Signed-off-by: Muhammad Fa
ping
Will push in 2 days if nobody objects.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 20.11.2016 13:46, Nicolas George wrote:
> Debian has the habit of shipping -dbg versions of library packages with
> debug symbols included, to allow people to debug programs using these
> libraries. I suppose the Debian framework has provisions to create both
> the stripped and the debug package
On 20.11.2016 13:38, Carl Eugen Hoyos wrote:
> 2016-11-20 1:07 GMT+01:00 Andreas Cadhalpun
> :
>> gcc before gcc-5 reserves a register on x86_32 for the GOT, when PIE is
>> enabled.
>>
>> This fixes build failures due to:
>> error: 'asm' operand has impossible constraints
>
> Not reproducible wit
On Sun, Nov 20, 2016 at 12:00:49PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Nov 20, 2016 at 9:16 AM, Michael Niedermayer > wrote:
>
> > On Sun, Nov 20, 2016 at 08:56:15AM -0500, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Sun, Nov 20, 2016 at 6:57 AM, Michael Niedermayer
> > > > >
2016-11-20 18:05 GMT+01:00 Kieran Kunhya :
> I object to this patch for the reasons Rostislav outlined..
Since this version of the decoder does not only support
uncompressed images, I don't think the "reasons" are
still valid.
Iirc, FFmpeg does not support all features of practically
every standa
2016-11-20 18:04 GMT+01:00 Martin Vignali :
>>
>> > I doesn't find a planar, for YA, so there is now two way to store data
>> > one for YA, and one for Gray and GBR.
>>
>> Sorry, I don't understand this sentence...
>
> Not sure i understand what is your question.
> I use planar for RGB and Gray, bu
2016-11-20 17:50 GMT+01:00 Mark Thompson :
> On 20/11/16 16:16, Carl Eugen Hoyos wrote:
>> There is no API to read the version of the mesa driver?
>
> The one useful call is vaQueryVendorString(), which indeed returns useful
> results for i965. Unfortunately, all mesa returns here is a fixed str
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 20 Nov 2016 14:20:21 +0100
Michael Niedermayer wrote:
> On Sat, Nov 19, 2016 at 05:18:08PM -0800, Philip Langdale wrote:
> > The nvidia 375.xx driver introduces support for P016 output
> > surfaces, for 10bit and 12bit HEVC content (it's also
> However, all the rle samples seem to not decode entirely correct, instead
> containing blue/white rectangular areas.
>
>
> Sorry, forget to answer to that.
The white/blue rect have been add by me to the sample file, in order to
"enable" the rle compression of photoshop.
So i think, the conversion
On Sun, Nov 20, 2016 at 03:56:28PM +0700, Muhammad Faiz wrote:
> this allow to use phase_count_compensation on init (rather than
> rebuild on swr_set_compensation) when options suggest that
> soft compensation is enabled
>
> Signed-off-by: Muhammad Faiz
> ---
> libswresample/resample.c
Hello,
2016-11-20 18:05 GMT+01:00 Kieran Kunhya :
> I object to this patch for the reasons Rostislav outlined..
>
Thanks for saying this now.
I answer to Rotislav in July.
No answer from him from this moment,
and the answers from other people, doesn't seems to go in the same way.
Martin
>
> > I doesn't find a planar, for YA, so there is now two way to store data
> > one for YA, and one for Gray and GBR.
>
> Sorry, I don't understand this sentence...
>
Not sure i understand what is your question.
I use planar for RGB and Gray, bu for YA, i doesn't find a planar something
like YAP
Hi,
On Sun, Nov 20, 2016 at 9:16 AM, Michael Niedermayer wrote:
> On Sun, Nov 20, 2016 at 08:56:15AM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Nov 20, 2016 at 6:57 AM, Michael Niedermayer
> > > wrote:
> >
> > > @@ -131,6 +132,20 @@ static int write_number(void *obj, const AVOption
On Sun, Nov 20, 2016 at 5:16 PM, Carl Eugen Hoyos wrote:
> 2016-11-18 19:42 GMT+01:00 Hendrik Leppkes :
>> On Fri, Nov 18, 2016 at 6:40 PM, Michael Niedermayer
>> wrote:
>>> On Fri, Nov 18, 2016 at 03:18:27PM +0100, Hendrik Leppkes wrote:
>
- This does fix decoding of these samples on Intel
I object to this patch for the reasons Rostislav outlined..
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 20/11/16 16:16, Carl Eugen Hoyos wrote:
> 2016-11-18 19:42 GMT+01:00 Hendrik Leppkes :
>> On Fri, Nov 18, 2016 at 6:40 PM, Michael Niedermayer
>> wrote:
>>> On Fri, Nov 18, 2016 at 03:18:27PM +0100, Hendrik Leppkes wrote:
>
- This does fix decoding of these samples on Intel GPUs using VAA
> > Subject: [PATCH 1/2] libavcodec : add decoder for Photoshop PSD image
> file.
>
> ^
> image file*s* and no dot at the end
>
> > Decode the Image Data Section (who contain merge picture).
> ^
> (which contains merged pictures)
>
> > Support RGB/A and Grayscale/
2016-11-18 18:27 GMT+01:00 Martin Vignali :
>> Did you see AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP, AV_PIX_FMT_GBRP16
>> and AV_PIX_FMT_GBRAP16?
>>
>
> New patch in attach use AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
> AV_PIX_FMT_GBRP16BE
> and AV_PIX_FMT_GBRAP16BE for RGB mode
> I doesn't find a planar, for
2016-11-18 19:42 GMT+01:00 Hendrik Leppkes :
> On Fri, Nov 18, 2016 at 6:40 PM, Michael Niedermayer
> wrote:
>> On Fri, Nov 18, 2016 at 03:18:27PM +0100, Hendrik Leppkes wrote:
>>> - This does fix decoding of these samples on Intel GPUs using VAAPI,
>>> however it appears to break on AMD using VA
2016-11-18 15:18 GMT+01:00 Hendrik Leppkes :
> - This does fix decoding of these samples on Intel GPUs using VAAPI,
> however it appears to break on AMD using VAAPI.
Then it needs at least a Changelog entry.
Carl Eugen
___
ffmpeg-devel mailing list
ff
On 18/11/16 14:18, Hendrik Leppkes wrote:
> On Fri, Nov 18, 2016 at 3:11 PM, Hendrik Leppkes wrote:
>> Based on a patch by Jun Zhao
>> ---
>> libavcodec/vc1dec.c | 41 +++--
>> 1 file changed, 39 insertions(+), 2 deletions(-)
>>
>
> As a quick run down on the
On Sun, Nov 20, 2016 at 08:56:15AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Nov 20, 2016 at 6:57 AM, Michael Niedermayer > wrote:
>
> > @@ -131,6 +132,20 @@ static int write_number(void *obj, const AVOption *o,
> > void *dst, double num, int
> > if (intnum == 1 && d == (double)I
Hi,
On Sun, Nov 20, 2016 at 6:57 AM, Michael Niedermayer wrote:
> @@ -131,6 +132,20 @@ static int write_number(void *obj, const AVOption *o,
> void *dst, double num, int
> if (intnum == 1 && d == (double)INT64_MAX) *(int64_t *)dst =
> INT64_MAX;
> else
2016-11-20 13:55 GMT+01:00 Nicolas George :
> Le decadi 30 brumaire, an CCXXV, Carl Eugen Hoyos a écrit :
>> My point is that without "--disable-stripping", the libraries are still
>> not stripped except for the additional yasm symbols that no
>> debugger can read (iiuc).
>
> I think you are wrong:
2016-11-20 13:52 GMT+01:00 Clément Bœsch :
>> > +static const AVOption sbuffer_options[] = {
>> > +{ "time_base", NULL, OFFSET(time_base), AV_OPT_TYPE_RATIONAL, {
>> > .dbl = 0 }, 0, INT_MAX, S },
>> > +{ "format", NULL, OFFSET(sub_format), AV_OPT_TYPE_INT, {
>> > .i64
On Sat, Nov 19, 2016 at 05:18:08PM -0800, Philip Langdale wrote:
> The nvidia 375.xx driver introduces support for P016 output surfaces,
> for 10bit and 12bit HEVC content (it's also the first driver to support
> hardware decoding of 12bit content).
>
> Technically, we don't support P016, but in p
On Fri, Nov 11, 2016 at 12:45:03PM +0100, Nicolas George wrote:
> Le septidi 17 brumaire, an CCXXV, Clement Boesch a écrit :
> > I didn't. Duration is somehow broken currently for some reason. I did
> > nothing for sparseness: the reason I added basic support in lavfi is
> > because it was much sim
Le decadi 30 brumaire, an CCXXV, Carl Eugen Hoyos a écrit :
> My point is that without "--disable-stripping", the libraries are still
> not stripped except for the additional yasm symbols that no
> debugger can read (iiuc).
I think you are wrong:
/tmp/i/usr/local/lib/libavcodec.so.57.66.102: ELF
2016-11-20 13:46 GMT+01:00 Nicolas George :
> Le decadi 30 brumaire, an CCXXV, Carl Eugen Hoyos a écrit :
>> Is --disable-stripping really useful? Doesn't it only add symbols to
>> yasm-generated
>> files that cannot be read by gdb?
>> (Sorry if I misremember)
>
> Stripping means removing the stati
On Fri, Nov 11, 2016 at 04:46:51PM +0100, wm4 wrote:
[...]
> > +// TODO: delete this compatibility code when all subtitles encoders moved
> > +// to send_frame
> > +static int encode_subtitle_frame(AVCodecContext *avctx,
> > + AVPacket *avpkt,
> > +
2016-11-18 17:45 GMT+01:00 Josh de Kock :
> Can't currently test on macOS as libturing doesn't have macOS
> support (https://github.com/bbc/turingcodec/issues/5), but it is
> being worked on (supposedly), so it may make sense to wait until
> then before this is applied.
I don't know if we should
Le decadi 30 brumaire, an CCXXV, Carl Eugen Hoyos a écrit :
> Is --disable-stripping really useful? Doesn't it only add symbols to
> yasm-generated
> files that cannot be read by gdb?
> (Sorry if I misremember)
Stripping means removing the static symbol tables from all libraries and
binaries. It a
2016-11-19 17:30 GMT+01:00 Andreas Cadhalpun :
> A hard failure is unnecessary and Carl Eugen [1] and Hendrik [2]
> convinced me that it should be avoided.
I believe that ffm should (or at least can) indeed be treated differently
from all other containers.
> 1: https://ffmpeg.org/pipermail/ffmpe
2016-11-20 1:07 GMT+01:00 Andreas Cadhalpun :
> gcc before gcc-5 reserves a register on x86_32 for the GOT, when PIE is
> enabled.
>
> This fixes build failures due to:
> error: 'asm' operand has impossible constraints
Not reproducible with vanilla gcc 4.9.1 and gcc 4.4.6 so the patch is
not ok as
2016-11-20 12:57 GMT+01:00 Michael Niedermayer :
> -case AV_OPT_TYPE_INT64:
> -*(int64_t *)dst = llrint(num / den) * intnum;
> -break;
> +case AV_OPT_TYPE_INT64:{
> +double d = num / den;
> +if (intnum == 1 && d == (double)INT64_MAX) *(int64_t *)dst =
> INT
Found-by: Andreas
Signed-off-by: Michael Niedermayer
---
libavutil/opt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index cd16bd1..6669356 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -126,9 +126,11 @@ static int write_nu
Requested-by: wm4 ([FFmpeg-devel] [PATCH] avutil/opt: Support max > INT64_MAX
in write_number() with AV_OPT_TYPE_INT64)
Requested-by: ronald ([FFmpeg-devel] [PATCH] avutil/opt: Support max >
INT64_MAX in write_number() with AV_OPT_TYPE_INT64)
Signed-off-by: Michael Niedermayer
---
libavutil/opt
Signed-off-by: Michael Niedermayer
---
libavcodec/options_table.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 48de667..ee79859 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -447
On Sat, Nov 19, 2016 at 02:01:54PM +0100, Andreas Cadhalpun wrote:
> On 19.11.2016 01:39, Michael Niedermayer wrote:
> > On Fri, Nov 18, 2016 at 11:06:56PM +0100, Andreas Cadhalpun wrote:
> >> AVOption.max is a double, which has not enough precision for INT64_MAX.
> >>
> >> It gets interpreted as I
this allow to use phase_count_compensation on init (rather than
rebuild on swr_set_compensation) when options suggest that
soft compensation is enabled
Signed-off-by: Muhammad Faiz
---
libswresample/resample.c| 4 +++-
libswresample/soxr_resample.c | 2 +-
libswresample/swresam
71 matches
Mail list logo
