Re: [FFmpeg-devel] [PATCH 2/2] fate: add a monoscopic spherical matroska test

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/udp: Enable FIFO when using windows sockets.

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

Re: [FFmpeg-devel] [PATCH 1/2] Avoid using the term "file" and prefer "url" in some docs and comments

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

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: Add FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

Re: [FFmpeg-devel] [PATCH] avcodec/flac: check frame header crc only if requested

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

Re: [FFmpeg-devel] [PATCH] aacdec: Allow SBR after DRC.

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

Re: [FFmpeg-devel] [PATCH] Support limiting the number of pixels per image

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

Re: [FFmpeg-devel] [PATCH] aacdec: Rename elem_type_prev to che_prev_type.

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: Add FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

Re: [FFmpeg-devel] [PATCH] doc/filters: drawtext: add example of printing texts on same baseline

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

Re: [FFmpeg-devel] [PATCH] Support limiting the number of pixels per image

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:

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

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

[FFmpeg-devel] [PATCH 1/2] opus_parser: fix leaking channel_maps on error

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

[FFmpeg-devel] [PATCH 2/2] opus_parser: replace ff_parse_close with opus_parse_close

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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 =

[FFmpeg-devel] [PATCH] avcodec/mpeg12dec: Add FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/matroskadec: allocate Colour related fields only if the file contains the relevant master

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

[FFmpeg-devel] [PATCHv4] iTunes gapless info parsing, hopefully correct this time

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

Re: [FFmpeg-devel] [PATCH] aacdec: Rename elem_type_prev to che_prev_type.

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

Re: [FFmpeg-devel] [PATCH 1/2] Avoid using the term "file" and prefer "url" in some docs and comments

> 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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

[FFmpeg-devel] [PATCH] aacdec: Rename elem_type_prev to che_prev_type.

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

Re: [FFmpeg-devel] [PATCH 1/2] Avoid using the term "file" and prefer "url" in some docs and comments

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

Re: [FFmpeg-devel] [PATCH] aacdec: Allow SBR after DRC.

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

Re: [FFmpeg-devel] [PATCH] avcodec/flac: check frame header crc only if requested

> 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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

[FFmpeg-devel] [PATCH] Support limiting the number of pixels per image

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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(+),

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

[FFmpeg-devel] [PATCH 2/2] fate: add a monoscopic spherical matroska test

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

[FFmpeg-devel] [PATCH 1/2] fate: improve fate-mov dependencies

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

Re: [FFmpeg-devel] [PATCH] avcodec/flac: check frame header crc only if requested

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

Re: [FFmpeg-devel] [PATCH] aarch64: h264idct: Use the offset parameter to movrel

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

Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

[FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100

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

Re: [FFmpeg-devel] [PATCH] avformat: Add max_streams option

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

Re: [FFmpeg-devel] [PATCH] aarch64: h264idct: Use the offset parameter to movrel

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

[FFmpeg-devel] [PATCH] aarch64: h264idct: Use the offset parameter to movrel

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

[FFmpeg-devel] [PATCH v3] h264_slice: Wait for refs to be available before we use them in error concealment

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

[FFmpeg-devel] [PATCH] configure: Require bit_depth field for VAAPI VP9 decode hwaccel

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] aarch64: Add an offset parameter to the movrel macro

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 >

Re: [FFmpeg-devel] [PATCH] vaapi_vp9: Do not set bit_depth on old versions

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

Re: [FFmpeg-devel] [PATCH] vaapi_vp9: Do not set bit_depth on old versions

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

Re: [FFmpeg-devel] [PATCH 1/2] h264_slice: Add forgotten progress update for the 2nd field in a slice

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

Re: [FFmpeg-devel] [PATCH 1/2] h264_slice: Add forgotten progress update for the 2nd field in a slice

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

[FFmpeg-devel] [PATCH] vaapi_vp9: Do not set bit_depth on old versions

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

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

[FFmpeg-devel] [PATCH 1/2] h264_slice: Add forgotten progress update for the 2nd field in a slice

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

Re: [FFmpeg-devel] [PATCH] remove news entry about ffserver

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

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

Re: [FFmpeg-devel] [PATCH] remove news entry about ffserver

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'

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

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 >

[FFmpeg-devel] [PATCH 0/2 v2] h264_slice race condition fixes

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

[FFmpeg-devel] [PATCH 2/2] h264_slice: Wait for refs to be available before we use them in error concealment

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/vaapi-vp9: add support for profile 2 (bpp > 8)

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/vaapi-vp9: add support for profile 2 (bpp > 8)

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

Re: [FFmpeg-devel] [PATCH] remove news entry about ffserver

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

Re: [FFmpeg-devel] [PATCH] remove news entry about ffserver

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

Re: [FFmpeg-devel] [PATCH] remove news entry about ffserver

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

Re: [FFmpeg-devel] [PATCH] remove news entry about ffserver

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

Re: [FFmpeg-devel] [PATCH] remove news entry about ffserver

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

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

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.

Re: [FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

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

Re: [FFmpeg-devel] [PATCH 3/4] avcodec/h264: mmx2, sse2, avx 10-bit h chroma deblock/loop filter

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

Re: [FFmpeg-devel] [PATCH] remove news entry about ffserver

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

[FFmpeg-devel] [PATCH] remove news entry about ffserver

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

Re: [FFmpeg-devel] [PATCH] avcodec/flac: check frame header crc only if requested

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_hwupload_cuda: Add min/max limits for device option

Applied and backported to 3.2 and 3.1. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aacdec: Allow SBR after DRC.

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

[FFmpeg-devel] [PATCH] avfilter/vf_hwupload_cuda: Add min/max limits for device option

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