The device option for hwupload_cuda filter does not have max and min limits
defined right now.
Hence the min/max values are 0 by default, so anything outside the range [0,0]
is not allowed.
This is causing problems in case of setup with multiple devices.
Please review the patch which adds these
On 7 December 2016 at 01:08, Alex Converse wrote:
> Fixes https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader_v2_rtb.mp4
>
> Reported-by: rcombs on IRC
> ---
> libavcodec/aacdec_template.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/aacdec_templa
Applied and backported to 3.2 and 3.1.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Thu, Dec 08, 2016 at 12:33:56AM -0300, James Almer wrote:
> It's more consistent with other similar checks in the decoder, and should
> help with fuzzing.
>
> Signed-off-by: James Almer
> ---
> I could also add an AV_EF_EXPLODE check before aborting, but i figured
> that with a frame header cr
yeah.
-compndiff --git a/src/index b/src/index
index c203676..f6c925f 100644
--- a/src/index
+++ b/src/index
@@ -86,15 +86,6 @@
We recommend users, distributors, and system integrators, to upgrade
unless they use current git master.
- July 10th, 2016, ffserver program being dropped
2016-12-08 14:36 GMT+01:00 compn :
> yeah.
Instead I would suggest to clarify / correct the entry or write a new one.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2016-12-07 14:07 GMT+01:00 James Darnley :
> On 2016-12-07 11:07, Carl Eugen Hoyos wrote:
>> 2016-12-05 19:32 GMT+01:00 James Darnley :
>>
>>> - sse2: 2.47x (170 vs. 69 cycles)
>>> - avx: 2.47x (170 vs. 69 cycles)
>>
>> Please elaborate on why this was committed.
>
> Because writing it cost al
On Wed, 7 Dec 2016 19:29:58 +0100
Nicolas George wrote:
> Le quintidi 15 frimaire, an CCXXV, Rostislav Pehlivanov a écrit :
> > I need more time to decide.
>
> You supported dropping ffserver since before the vote started, and now
> you are hesitating? Seriously?
>
> Arriving at the last minu
L'octidi 18 frimaire, an CCXXV, wm4 a écrit :
> 3. It's entangled with the rest of the project and stops people from
> doing useful work.
If it does not prevent build failures and is not present in the normal
execution path, what does it even MEANS? Nothing!
> Proof: Libav.
W
Hi,
On Thu, Dec 8, 2016 at 8:42 AM, Carl Eugen Hoyos wrote:
> 2016-12-08 14:36 GMT+01:00 compn :
> > yeah.
>
> Instead I would suggest to clarify / correct the entry or write a new one.
I agree with CE here, let's not rewrite history.
My reading of the vote is that we, as a project, are now p
2016-12-08 16:02 GMT+01:00 Ronald S. Bultje :
> Hi,
>
> On Thu, Dec 8, 2016 at 8:42 AM, Carl Eugen Hoyos wrote:
>
>> 2016-12-08 14:36 GMT+01:00 compn :
>> > yeah.
>>
>> Instead I would suggest to clarify / correct the entry or write a new one.
>
>
> I agree with CE here, let's not rewrite history.
L'octidi 18 frimaire, an CCXXV, Ronald S. Bultje a écrit :
> My reading of the vote is that we, as a project, are now promising to
> update, maintain and improve ffserver and that if this succeeds (see
> Nicolas' original post for official definition of this), ffserver can stay.
Your reading is wr
On Thu, Dec 08, 2016 at 10:02:13AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Dec 8, 2016 at 8:42 AM, Carl Eugen Hoyos wrote:
>
> > 2016-12-08 14:36 GMT+01:00 compn :
> > > yeah.
> >
> > Instead I would suggest to clarify / correct the entry or write a new one.
>
>
> I agree with CE here
Hi,
On Thu, Dec 8, 2016 at 10:04 AM, Carl Eugen Hoyos
wrote:
> 2016-12-08 16:02 GMT+01:00 Ronald S. Bultje :
> > Hi,
> >
> > On Thu, Dec 8, 2016 at 8:42 AM, Carl Eugen Hoyos
> wrote:
> >
> >> 2016-12-08 14:36 GMT+01:00 compn :
> >> > yeah.
> >>
> >> Instead I would suggest to clarify / correct
2016-12-05 21:32 GMT+01:00 Mathieu Velten :
> ---
> libavcodec/vaapi_vp9.c | 1 +
> libavcodec/vp9.c | 10 +-
> 2 files changed, 10 insertions(+), 1 deletion(-)
(This is missing a review here but I guess it's just me
who can't work with gmail.)
May I suggest to revert this?
> +
2016-12-08 16:16 GMT+01:00 Carl Eugen Hoyos :
>> +pp->bit_depth = h->h.bpp;
>
> Google doesn't easily find a version of va_dec_vp9.h
> with _VADecPictureParameterBufferVP9->bit_depth.
In any case, please mention ticket #6003 when
fixing the issue.
Thank you, Carl Eugen
__
I am almost entirely certain the first patch in this series is
wrong in some or many ways. Someone who knows the h264 code needs
to check over it before anything is pushed.
I am not sure of:
* The thread progress update is in the correct place
* The field number is set properly (via !=).
The
This could happen when there was a frame number gap and frame threading was
used.
This fixes #5458.
Debugging-by: Ronald S. Bultje
Debugging-by: Justin Ruggles
Signed-off-by: Derek Buitenhuis
---
libavcodec/h264_slice.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/h264_s
On Thu, 8 Dec 2016 16:02:18 +0100
Nicolas George wrote:
> L'octidi 18 frimaire, an CCXXV, wm4 a écrit :
> > 3. It's entangled with the rest of the project and stops people from
> > doing useful work.
>
> If it does not prevent build failures and is not present in the normal
> execution path, w
On Thu, 8 Dec 2016 16:07:02 +0100
Nicolas George wrote:
> L'octidi 18 frimaire, an CCXXV, Ronald S. Bultje a écrit :
> > My reading of the vote is that we, as a project, are now promising to
> > update, maintain and improve ffserver and that if this succeeds (see
> > Nicolas' original post for of
L'octidi 18 frimaire, an CCXXV, wm4 a écrit :
> I explained it. Read it.
It prooves you still do not understand the principle.
Fortunately, the others do.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
On Thu, 8 Dec 2016 08:36:15 -0500
compn wrote:
> yeah.
>
> -compn
-1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Signed-off-by: Derek Buitenhuis
---
libavcodec/h264_slice.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 1f2c06521e..a8a8731138 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1538,6 +1538,8 @@ static int h264
On Thu, 8 Dec 2016 16:33:20 +0100
Nicolas George wrote:
> L'octidi 18 frimaire, an CCXXV, wm4 a écrit :
> > I explained it. Read it.
>
> It prooves you still do not understand the principle.
You've demonstrated the complete inability to counter my arguments.
Maybe you didn't even understand t
Fixes ticket #6003.
---
On 08/12/16 15:16, Carl Eugen Hoyos wrote:
> 2016-12-05 21:32 GMT+01:00 Mathieu Velten :
>> ---
>> libavcodec/vaapi_vp9.c | 1 +
>> libavcodec/vp9.c | 10 +-
>> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> (This is missing a review here but I guess i
2016-12-08 16:24 GMT+01:00 Derek Buitenhuis :
> Signed-off-by: Derek Buitenhuis
> ---
> libavcodec/h264_slice.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 1f2c06521e..a8a8731138 100644
> --- a/libavcodec/h264_slice.c
> +++
On 12/8/2016 3:46 PM, Carl Eugen Hoyos wrote:
> Does this have a speed impact for valid h264 streams?
Nope.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 08/12/16 15:51, Mark Thompson wrote:
> Hacky fix enclosing, only compile tested.
>
> A configure test for this might be better, because we could then check it
> sensibly in the generic code and bail out earlier? (Which would permit
> software decode, this will attempt hardware decode and fai
On 12/8/2016 12:55 PM, Mark Thompson wrote:
> On 08/12/16 15:51, Mark Thompson wrote:
>> Hacky fix enclosing, only compile tested.
>>
>> A configure test for this might be better, because we could then check it
>> sensibly in the generic code and bail out earlier? (Which would permit
>> software
On Tue, Nov 15, 2016 at 09:14:06PM +0100, Martin Storsjö wrote:
> ffmpeg | branch: master | Martin Storsjö | Mon Nov 14
> 12:32:24 2016 +0200| [7fe898dbb949f0e31665d716f671e2428d50bb29] | committer:
> Ronald S. Bultje
>
> aarch64: Add an offset parameter to the movrel macro
>
> With apple tool
libva versions from 1.6.0 to 1.6.2 do not include it, and therefore
cannot work with VP9 profile >= 2.
---
On 08/12/16 16:13, James Almer wrote:
> On 12/8/2016 12:55 PM, Mark Thompson wrote:
>> On 08/12/16 15:51, Mark Thompson wrote:
>>> Hacky fix enclosing, only compile tested.
>>>
>>> A configure
This could happen when there was a frame number gap and frame threading was
used.
This fixes #5458.
Debugging-by: Ronald S. Bultje
Debugging-by: Justin Ruggles
Signed-off-by: Derek Buitenhuis
---
Extra help from Ronald enlightened me to the fact that there
is actually this field.
Patch 1/2 i
From: Martin Storsjö
Signed-off-by: Martin Storsjö
Signed-off-by: Ronald S. Bultje
---
libavcodec/aarch64/h264idct_neon.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/aarch64/h264idct_neon.S
b/libavcodec/aarch64/h264idct_neon.S
index fa414f7..e9f5b18 100644
-
On Thu, Dec 08, 2016 at 12:01:33PM -0500, Ronald S. Bultje wrote:
> From: Martin Storsjö
>
> Signed-off-by: Martin Storsjö
> Signed-off-by: Ronald S. Bultje
> ---
> libavcodec/aarch64/h264idct_neon.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
didnt see this
martin pinged me priva
On Fri, Nov 18, 2016 at 06:35:01PM +0100, Michael Niedermayer wrote:
> On Fri, Nov 18, 2016 at 06:22:06PM +0100, Alexander Strasser wrote:
> > Hi Michael!
> >
> > On 2016-11-18 17:03 +0100, Michael Niedermayer wrote:
> > > This allows user apps to stop OOM due to excessive number of streams
> > >
Suggested-by: Andreas Cadhalpun
Signed-off-by: Michael Niedermayer
---
libavformat/options_table.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index d5448e503f..19cb87ae4e 100644
--- a/libavformat/options_table.h
+
Hi,
On Thu, Dec 8, 2016 at 12:37 PM, Michael Niedermayer wrote:
> Suggested-by: Andreas Cadhalpun
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/options_table.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/options_table.h b/libavformat/options
Hi,
On Thu, Dec 8, 2016 at 12:14 PM, Michael Niedermayer wrote:
> On Thu, Dec 08, 2016 at 12:01:33PM -0500, Ronald S. Bultje wrote:
> > From: Martin Storsjö
> >
> > Signed-off-by: Martin Storsjö
> > Signed-off-by: Ronald S. Bultje
> > ---
> > libavcodec/aarch64/h264idct_neon.S | 2 +-
> > 1
On 12/8/2016 9:31 AM, Michael Niedermayer wrote:
> FFmpeg decoders primary usecase is to decode for human consumption
> for this producing the best quality possible and doing so fast is
> the goal.
> The default thus should be to do checks that improve quality
> its probably better if fuzzers disab
Signed-off-by: James Almer
---
tests/fate/mov.mak | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 138b6b9..9660793 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -5,15 +5,18 @@ FATE_MOV = fate-mov
Signed-off-by: James Almer
---
Sample can be found in http://0x0.st/Lpj.mkv
tests/fate/matroska.mak| 4
tests/ref/fate/matroska-spherical-mono | 16
2 files changed, 20 insertions(+)
create mode 100644 tests/ref/fate/matroska-spherical-mono
diff --git a/t
On 12/8/2016 2:44 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Dec 8, 2016 at 12:37 PM, Michael Niedermayer > wrote:
>
>> Suggested-by: Andreas Cadhalpun
>> Signed-off-by: Michael Niedermayer
>> ---
>> libavformat/options_table.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>
On Thu, 8 Dec 2016 18:37:42 +0100
Michael Niedermayer wrote:
> Suggested-by: Andreas Cadhalpun
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/options_table.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/options_table.h b/libavformat/options_t
TODO: split into 2 patches (one per lib), docs & bump
This allows preventing some OOM and "slow decoding" cases by limiting the
maximum resolution
this may be useful to avoid fuzzers getting stuck in boring cases
Signed-off-by: Michael Niedermayer
---
libavcodec/avcodec.h | 8
On Thu, Dec 08, 2016 at 07:25:59PM +0100, wm4 wrote:
> On Thu, 8 Dec 2016 18:37:42 +0100
> Michael Niedermayer wrote:
>
> > Suggested-by: Andreas Cadhalpun
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/options_table.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
On Thu, 8 Dec 2016 19:36:20 +0100
Michael Niedermayer wrote:
> On Thu, Dec 08, 2016 at 07:25:59PM +0100, wm4 wrote:
> > On Thu, 8 Dec 2016 18:37:42 +0100
> > Michael Niedermayer wrote:
> >
> > > Suggested-by: Andreas Cadhalpun
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libav
Hi,
On Thu, Dec 8, 2016 at 1:25 PM, James Almer wrote:
> On 12/8/2016 2:44 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Thu, Dec 8, 2016 at 12:37 PM, Michael Niedermayer
> >> wrote:
> >
> >> Suggested-by: Andreas Cadhalpun
> >> Signed-off-by: Michael Niedermayer
> >> ---
> >> libavformat/o
> On Dec 8, 2016, at 12:45 PM, James Almer wrote:
>
> On 12/8/2016 9:31 AM, Michael Niedermayer wrote:
>> FFmpeg decoders primary usecase is to decode for human consumption
>> for this producing the best quality possible and doing so fast is
>> the goal.
>> The default thus should be to do check
On Thu, Dec 8, 2016 at 2:14 AM, Rostislav Pehlivanov
wrote:
> On 7 December 2016 at 01:08, Alex Converse wrote:
>
>> Fixes https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader_v2_rtb.mp4
>>
>> Reported-by: rcombs on IRC
>> ---
>> libavcodec/aacdec_template.c | 6 --
>> 1 file changed, 4 i
On Thu, Dec 08, 2016 at 07:48:46PM +0100, wm4 wrote:
> On Thu, 8 Dec 2016 19:36:20 +0100
> Michael Niedermayer wrote:
>
> > On Thu, Dec 08, 2016 at 07:25:59PM +0100, wm4 wrote:
> > > On Thu, 8 Dec 2016 18:37:42 +0100
> > > Michael Niedermayer wrote:
> > >
> > > > Suggested-by: Andreas Cadhal
On Thu, Dec 08, 2016 at 02:05:19PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Dec 8, 2016 at 1:25 PM, James Almer wrote:
>
> > On 12/8/2016 2:44 PM, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Thu, Dec 8, 2016 at 12:37 PM, Michael Niedermayer
> > > >> wrote:
> > >
> > >> Suggested-by
2016.12.08. 19:36 keltezéssel, Michael Niedermayer írta:
On Thu, Dec 08, 2016 at 07:25:59PM +0100, wm4 wrote:
On Thu, 8 Dec 2016 18:37:42 +0100
Michael Niedermayer wrote:
Suggested-by: Andreas Cadhalpun
Signed-off-by: Michael Niedermayer
---
libavformat/options_table.h | 2 +-
1 file
On Mon, 5 Dec 2016 13:52:50 +0100, Michael Niedermayer wrote:
> This should make it less ambigous that these are URLs
>
> Signed-off-by: Michael Niedermayer
> ---
> doc/ffmpeg.texi | 18 +-
> doc/ffplay.texi | 6 +++---
> doc/ffprobe.texi | 10 +-
> ffmpeg_opt.c
It describes the type of the previous che element (SCE, CPE, CCE, or
LFE) and does not reflect non-che elements.
---
libavcodec/aacdec_template.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 64d46e3..8
L'octidi 18 frimaire, an CCXXV, Michael Niedermayer a écrit :
> A. Is a heap limit for av_*alloc*() acceptable ?
> B. Are case based limits acceptable ?
No. This is the task of the operating system.
> also even if C is choosen, a small set of limits on the main parameters
> still is needed to all
> Although this is a trivial patch, approximately 7 hours between sending
> a patch and applying without feedback isn't enough time. At least 24
> hours would be preferrable.
>
> This patch seems unnecessary and I prefer the previous syntax. "URL"
> has a strong networking connotation. This change
On 8 December 2016 at 19:55, Alex Converse wrote:
> It describes the type of the previous che element (SCE, CPE, CCE, or
> LFE) and does not reflect non-che elements.
> ---
> libavcodec/aacdec_template.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/
This hopefully fixes all of the shortcomings that were still
present in the patch I last submitted. Unfortunately, I don't
track the mailing list as closely as I should, so I missed
the responses to my last round of patches. The first one made
it in, though.
There are reasonable limits applied to
---
libavformat/mp3dec.c | 70 +++-
1 file changed, 69 insertions(+), 1 deletion(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 56c7f8c..47f4028 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -295,6 +295,59 @@ sta
On 12/4/2016 11:36 PM, James Almer wrote:
> The demuxer doesn't fill the defaults if the master isn't present.
> This results in codecpar->color_space being set with a value of
> zero (RGB) on such files.
>
> Signed-off-by: James Almer
> ---
> libavformat/matroskadec.c | 54
> ++
This decreases the amount of computations and memory needed for analysing
mpeg1/2 streams
Signed-off-by: Michael Niedermayer
---
libavcodec/mpeg12dec.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index ac8160daff..6397
2016-12-08 18:37 GMT+01:00 Michael Niedermayer :
> -{"max_streams", "maximum number of streams", OFFSET(max_streams),
> AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 0, INT_MAX, D },
> +{"max_streams", "maximum number of streams", OFFSET(max_streams),
> AV_OPT_TYPE_INT, { .i64 = 100 }, 0, INT_MAX, D },
2016-12-08 18:44 GMT+01:00 Ronald S. Bultje :
>> -{"max_streams", "maximum number of streams", OFFSET(max_streams),
>> AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 0, INT_MAX, D },
>> +{"max_streams", "maximum number of streams", OFFSET(max_streams),
>> AV_OPT_TYPE_INT, { .i64 = 100 }, 0, INT_MAX, D },
>>
The former expects priv_data to be the ParseContext directly, so using
it does not work.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/opus_parser.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/opus_parser.c b/libavcodec/opus_parser.c
index 21a73ee..95
Signed-off-by: Andreas Cadhalpun
---
libavcodec/opus_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/opus_parser.c b/libavcodec/opus_parser.c
index c30fd7b..21a73ee 100644
--- a/libavcodec/opus_parser.c
+++ b/libavcodec/opus_parser.c
@@ -116,11 +116,11 @@ s
On 08.12.2016 15:53, wm4 wrote:
> (I'm still waiting for related work to be merged from Libav).
Why don't you merge it yourself instead of waiting for others?
> So yes, removing things can mean progress.
However, removing ffserver now doesn't, because the libraries
have to keep backwards-compati
On 08.12.2016 19:30, Michael Niedermayer wrote:
> TODO: split into 2 patches (one per lib), docs & bump
>
> This allows preventing some OOM and "slow decoding" cases by limiting the
> maximum resolution
> this may be useful to avoid fuzzers getting stuck in boring cases
>
> Signed-off-by: Michae
On Wed, 30 Nov 2016 09:24:52 +, Andrey Utkin wrote:
> Thanks for your comments.
>
> It's hard for me to stress the point of the approach further.
>
> I wonder if it becomes clearer if we use
>
> TEXT1="one"
> TEXT2="two"
> X2=100
>
> in discussed scripts.
>
> Maybe a paragraph describing
On 08.12.2016 20:57, Michael Niedermayer wrote:
> This is something the community must decide.
> A. Is a heap limit for av_*alloc*() acceptable ?
I'm not sure that's a good idea, because it can't limit what other
libraries called by libavcodec etc. allocate.
> B. Are case based limits acceptable
On 08.12.2016 22:53, Michael Niedermayer wrote:
> This decreases the amount of computations and memory needed for analysing
> mpeg1/2 streams
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/mpeg12dec.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/liba
On 08.12.2016 22:59, Carl Eugen Hoyos wrote:
> 2016-12-08 18:37 GMT+01:00 Michael Niedermayer :
>
>> -{"max_streams", "maximum number of streams", OFFSET(max_streams),
>> AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 0, INT_MAX, D },
>> +{"max_streams", "maximum number of streams", OFFSET(max_streams),
>
On Thu, Dec 8, 2016 at 12:56 PM, Rostislav Pehlivanov
wrote:
> On 8 December 2016 at 19:55, Alex Converse wrote:
>
>> It describes the type of the previous che element (SCE, CPE, CCE, or
>> LFE) and does not reflect non-che elements.
>> ---
>> libavcodec/aacdec_template.c | 8
>> 1 file
On Fri, Dec 9, 2016 at 12:45 AM, Andreas Cadhalpun
wrote:
> On 08.12.2016 19:30, Michael Niedermayer wrote:
>> TODO: split into 2 patches (one per lib), docs & bump
>>
>> This allows preventing some OOM and "slow decoding" cases by limiting the
>> maximum resolution
>> this may be useful to avoid
On Thu, Dec 8, 2016 at 12:36 PM, Rostislav Pehlivanov
wrote:
>
> On 8 December 2016 at 19:42, Alex Converse wrote:
>>
>> On Thu, Dec 8, 2016 at 2:14 AM, Rostislav Pehlivanov
>> wrote:
>> > On 7 December 2016 at 01:08, Alex Converse
>> > wrote:
>> >
>> >> Fixes
>> >> https://www2.iis.fraunhofer.
On Thu, Dec 08, 2016 at 02:45:42PM -0300, James Almer wrote:
> On 12/8/2016 9:31 AM, Michael Niedermayer wrote:
> > FFmpeg decoders primary usecase is to decode for human consumption
> > for this producing the best quality possible and doing so fast is
> > the goal.
> > The default thus should be t
On Thu, Dec 08, 2016 at 09:47:53PM +0100, Nicolas George wrote:
> L'octidi 18 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > A. Is a heap limit for av_*alloc*() acceptable ?
> > B. Are case based limits acceptable ?
>
> No. This is the task of the operating system.
>
> > also even if C is
On Fri, Dec 09, 2016 at 01:02:08AM +0100, Andreas Cadhalpun wrote:
> On 08.12.2016 22:53, Michael Niedermayer wrote:
> > This decreases the amount of computations and memory needed for analysing
> > mpeg1/2 streams
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/mpeg12dec.c |
On Thu, Dec 08, 2016 at 11:13:16AM -0900, Lou Logan wrote:
> On Mon, 5 Dec 2016 13:52:50 +0100, Michael Niedermayer wrote:
>
> > This should make it less ambigous that these are URLs
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/ffmpeg.texi | 18 +-
> > doc/ffplay
On 8 December 2016 at 04:49, Nicolas George wrote:
> Le septidi 17 frimaire, an CCXXV, Hendrik Leppkes a écrit :
> > I'm not sure you can safely avoid that in this design when dealing
> > with a fully generic library and no information or control whats going
> > on in other threads.
>
> You are r
On Thu, Dec 08, 2016 at 03:11:04PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> Sample can be found in http://0x0.st/Lpj.mkv
sample uploaded
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you drop bombs on a foreign country and kill a hun
80 matches
Mail list logo
