Re: [FFmpeg-devel] VS 2015 patch

On Wed, 25 Nov 2015 11:21:55 -0800 Bruce Dawson wrote: > I'm mentioning this just in case some other lost soul shows up trying > to contribute a patch to a Chromium only file. I'll get my patch > landed in the right place. > > Thanks for the help. hope we did not scare

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

Hi, On Thu, Nov 26, 2015 at 3:08 PM, wm4 wrote: > On Thu, 26 Nov 2015 20:46:25 +0100 > Nicolas George wrote: > > > Le sextidi 6 frimaire, an CCXXIV, wm4 a écrit : > > > Better do the looping internal in flvdec.c (if there's no huge number > > > of other

[FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

This speeds up aac_tablegen to a ludicruous degree (~97%), i.e to the point where it can be argued that runtime initialization can always be done instead of hard-coded tables. The only cost is essentially a trivial increase in the stack size. Even if one does not care about this, the patch also

Re: [FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization

On Thu, Nov 26, 2015 at 4:31 PM, Ganesh Ajjanagadde wrote: > This speeds up aac_tablegen to a ludicruous degree (~97%), i.e to the point > where it can be argued that runtime initialization can always be done instead > of > hard-coded tables. The only cost is essentially

Re: [FFmpeg-devel] [PATCH 2/4] lavf/utils: avoid decoding a frame to get the codec parameters

On Thu, Nov 26, 2015 at 08:08:25PM +0100, Michael Niedermayer wrote: > On Thu, Nov 26, 2015 at 05:16:32PM +0100, Matthieu Bouron wrote: > > On Thu, Nov 19, 2015 at 12:10:20PM +0100, Matthieu Bouron wrote: > > > On Mon, Nov 16, 2015 at 11:16:42AM -0500, Ronald S. Bultje wrote: > > > > Hi, > > > >

Re: [FFmpeg-devel] [PATCH] qsvenc: write a53 caption data to SEI

On Thu, Nov 12, 2015 at 02:13:08PM +0300, Ivan Uskov wrote: > Hello Will, > > Thursday, November 12, 2015, 12:53:46 AM, you wrote: > > WK> On 11/07, Ivan Uskov wrote: > >> Although the code looks ok by itself, I believe it is bad idea to > >> place > >> H.264-specific codeto the

Re: [FFmpeg-devel] [PATCH] qsvenc: Add adaptive_i and adaptive_b toggles

On Thu, Nov 12, 2015 at 05:10:33PM -0600, Will Kelleher wrote: > > Scene change detection ? > > and > > Content dependant B frame insertion > > > > And if people agree then please someone submit a patch with it > > ill apply it > > > > New patch. > > qsvenc.c |2 ++ > qsvenc.h

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

On Thu, 26 Nov 2015 20:46:25 +0100 Nicolas George wrote: > Le sextidi 6 frimaire, an CCXXIV, wm4 a écrit : > > Better do the looping internal in flvdec.c (if there's no huge number > > of other demuxers which need this), instead of adding a new error code > > that is also part

[FFmpeg-devel] QSV

Hi are there any QSV patches which have been reviewed and have no objections raised against them ? that is patches i should apply/push for qsv ... ivan, also it might make sense if you would be on IRC, so you and others could discuss any QSV issues or questions or patches or ... iam asking as it

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

Le sextidi 6 frimaire, an CCXXIV, wm4 a écrit : > I fail to see how letting such a workaround (required for flv) leak to ... and a few other demuxers... > common code is more elegant. You fail to see, but I do, and I am not alone:

Re: [FFmpeg-devel] VS 2015 patch

I don't scare that easily. :-) On Thu, Nov 26, 2015 at 12:39 PM, compn wrote: > On Wed, 25 Nov 2015 11:21:55 -0800 > Bruce Dawson wrote: > > I'm mentioning this just in case some other lost soul shows up trying > > to contribute a patch to a Chromium

Re: [FFmpeg-devel] [PATCH 2/3] lavf/utils: handle AVERROR_REDO.

On Thu, Nov 26, 2015 at 07:47:53PM +0100, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > libavformat/utils.c | 2 ++ > 1 file changed, 2 insertions(+) > > > An option can be added later to grant applications fine-grained control on > the looping, but it can not

Re: [FFmpeg-devel] [PATCH] avfilter: add acompressor filter

Paul, you do have some excellent filter additions! On Wed, Nov 25, 2015 at 16:32:13 +0100, Paul B Mahol wrote: > +@section acompressor Very good description, few remarks only: > +A compressor is mainly used to reduce the dynamic of a signal. > +Especially modern music is mostly compressed at a

Re: [FFmpeg-devel] [PATCH 2/3] lavf/utils: handle AVERROR_REDO.

Le sextidi 6 frimaire, an CCXXIV, Clement Boesch a écrit : > > An option can be added later to grant applications fine-grained control on > > the looping, but it can not be the default as it would be an API change, and > > it probably should not be the default anyway. > > +if (ret ==

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

Le sextidi 6 frimaire, an CCXXIV, Ronald S. Bultje a écrit : > I +1 this design comment, I have some (...) reservations about adding > EAGAIN2 (which is really what this is) to our public API (which is really > what this is). Would you care to address my arguments in your own words? Note that

Re: [FFmpeg-devel] [PATCH 1/3] lavu/error: add AVERROR_REDO.

Le sextidi 6 frimaire, an CCXXIV, Marton Balint a écrit : > Maybe I am missing something, but the existing error AVERROR(EINTR) cannot > be used for this? It would be less broken than EAGAIN, since it is almost always treated like that by Unix code. But without the loop in utils.c (patch 2/3 in

Re: [FFmpeg-devel] [PATCH 1/3] lavu/error: add AVERROR_REDO.

On Fri, 27 Nov 2015, Nicolas George wrote: Le sextidi 6 frimaire, an CCXXIV, Marton Balint a écrit : Maybe I am missing something, but the existing error AVERROR(EINTR) cannot be used for this? It would be less broken than EAGAIN, since it is almost always treated like that by Unix code.

Re: [FFmpeg-devel] [PATCH 1/3] lavu/error: add AVERROR_REDO.

On Thu, 26 Nov 2015, Nicolas George wrote: It is meant for demuxers to signal that they consumed data but did not return a packet; the framework is then supposed to loop. Maybe I am missing something, but the existing error AVERROR(EINTR) cannot be used for this? Thanks, Marton

Re: [FFmpeg-devel] [PATCH] avfilter: add acompressor filter

On Thu, Nov 26, 2015 at 5:17 PM, Moritz Barsnick wrote: > Paul, you do have some excellent filter additions! > > On Wed, Nov 25, 2015 at 16:32:13 +0100, Paul B Mahol wrote: >> +@section acompressor > > Very good description, few remarks only: > >> +A compressor is mainly used to

Re: [FFmpeg-devel] [PATCH 1/3] lavu/error: add AVERROR_REDO.

Le septidi 7 frimaire, an CCXXIV, Marton Balint a écrit : > I agree that a loop is necessary if a demuxer can return an error with such > semantics to maintain compatibility. So basically, the question boils down to what people consider the better design: adding a loop in every demuxer that needs

Re: [FFmpeg-devel] Intel QuickSync Video

Thanks to Sven Dueking I have finally solved it. Centos 7.1 works like charm :) 2015-11-09 15:28 GMT+01:00 Sven Dueking : > > > > -Ursprüngliche Nachricht- > > Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag > > von Sevan Gelici > > Gesendet:

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/vf_stack: make it possible to stop with shortest stream

Le sextidi 6 frimaire, an CCXXIV, Paul B Mahol a écrit : > avfilter/vf_stack: make it possible to stop with shortest stream > +in[i].after = s->shortest ? EXT_STOP : EXT_INFINITY; > +{ "shortest", "force termination when the shortest input terminates", > OFFSET(shortest),

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/vf_stack: make it possible to stop with shortest stream

On 11/26/15, Nicolas George wrote: > Le sextidi 6 frimaire, an CCXXIV, Paul B Mahol a ecrit : >> avfilter/vf_stack: make it possible to stop with shortest stream > >> +in[i].after = s->shortest ? EXT_STOP : EXT_INFINITY; > >> +{ "shortest", "force termination when

Re: [FFmpeg-devel] [PATCH 0/4] more accurate constants

On Fri, Nov 13, 2015 at 4:42 PM, Ganesh Ajjanagadde wrote: > > 4/4 is a "best effort" patch that maximizes accuracy on all platforms for > avcodec/faandct. It results in concrete accuracy benefits on the "default" > x86-64 > GNU/Linux platform. > > Patches tested with

Re: [FFmpeg-devel] [PATCH] fate: add FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM tests

On Thu, Nov 26, 2015 at 01:12:44AM +0100, Michael Niedermayer wrote: > On Wed, Nov 25, 2015 at 09:14:48PM +0100, Matthieu Bouron wrote: > > On Wed, Nov 25, 2015 at 06:36:03PM +0100, Michael Niedermayer wrote: > > > On Wed, Nov 25, 2015 at 03:40:15PM +0100, Matthieu Bouron wrote: > > > > From:

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/vf_stack: make it possible to stop with shortest stream

Le sextidi 6 frimaire, an CCXXIV, Paul B Mahol a écrit : > Yes, child object will do. But what options to give? > The number of inputs can differ. True, this is tricky. I had not thought of that. I consider the options system to be too limited for many cases: escaping hell, clumsy syntax. This

Re: [FFmpeg-devel] [PATCH] configure: add host libm capability detection

On 11/26/2015 7:49 AM, Hendrik Leppkes wrote: > I'm really not a fan of this change. configure is slow and complex > enough as it is, and host tools don't need to be micro-optimized, > since they are never run by a user. I agree. It's opening an endless can complexity for essentially no gain. We

Re: [FFmpeg-devel] [PATCH 0/4] more accurate constants

On Thu, Nov 26, 2015 at 5:23 AM, John Warburton wrote: > On Fri, Nov 13, 2015 at 4:42 PM, Ganesh Ajjanagadde > wrote: >> >> 4/4 is a "best effort" patch that maximizes accuracy on all platforms for >> avcodec/faandct. It results in concrete

Re: [FFmpeg-devel] [PATCH] configure: add host libm capability detection

On Thu, Nov 26, 2015 at 2:49 AM, Hendrik Leppkes wrote: > On Thu, Nov 26, 2015 at 6:04 AM, Ganesh Ajjanagadde > wrote: >> This is needed in order to obtain what is available for hardcoded >> table generation. >> >> A minimal avutil/host_libm.h is also

Re: [FFmpeg-devel] [PATCH] configure: add host libm capability detection

On Thu, Nov 26, 2015 at 6:52 AM, Derek Buitenhuis wrote: > On 11/26/2015 7:49 AM, Hendrik Leppkes wrote: >> I'm really not a fan of this change. configure is slow and complex >> enough as it is, and host tools don't need to be micro-optimized, >> since they are never

Re: [FFmpeg-devel] [PATCH 0/4] more accurate constants

On Thu, Nov 26, 2015 at 8:07 AM, Ganesh Ajjanagadde wrote: > On Thu, Nov 26, 2015 at 5:23 AM, John Warburton > wrote: >> On Fri, Nov 13, 2015 at 4:42 PM, Ganesh Ajjanagadde >> wrote: >>> >>> 4/4 is a "best effort" patch that

Re: [FFmpeg-devel] [PATCH] avcodec/cbrt_tablegen: avoid pow and speed up cbrt_tableinit

Hi, On Wed, Nov 25, 2015 at 10:46 PM, Ganesh Ajjanagadde wrote: > On Wed, Nov 25, 2015 at 10:13 PM, Ronald S. Bultje > wrote: > > Hi, > > > > On Wed, Nov 25, 2015 at 8:48 PM, Ganesh Ajjanagadde > > wrote: > >> > >> On Wed, Nov 25, 2015

Re: [FFmpeg-devel] [PATCH] avcodec/cbrt_tablegen: avoid pow and speed up cbrt_tableinit

Hi, On Wed, Nov 25, 2015 at 8:29 PM, Ganesh Ajjanagadde wrote: > On Wed, Nov 25, 2015 at 8:19 PM, Ronald S. Bultje > wrote: > > Hi, > > > > On Wed, Nov 25, 2015 at 7:36 PM, Ganesh Ajjanagadde > > wrote: > > > >> On Wed, Nov 25, 2015 at

Re: [FFmpeg-devel] [PATCH] avfilter/af_afade: improve accuracy and speed of gain computation

You gonna apply this? or? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/af_afade: improve accuracy and speed of gain computation

On Thu, Nov 26, 2015 at 9:05 AM, Paul B Mahol wrote: > You gonna apply this? or? I am, later today (pushing with some other stuff). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/cbrt_tablegen: avoid pow and speed up cbrt_tableinit

On Thu, Nov 26, 2015 at 8:47 AM, Ronald S. Bultje wrote: > Hi, > > On Wed, Nov 25, 2015 at 8:29 PM, Ganesh Ajjanagadde > wrote: > >> On Wed, Nov 25, 2015 at 8:19 PM, Ronald S. Bultje >> wrote: >> > Hi, >> > >> > On Wed, Nov 25, 2015 at

Re: [FFmpeg-devel] [PATCH 2/2] fate/concatdec: Use -bitexact

On Wed, Nov 25, 2015 at 09:35:07PM -0800, Timothy Gu wrote: > Fixes FATE failures on --enable-small builds. > --- > tests/fate-run.sh | 4 ++-- > tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +- > tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 | 2

Re: [FFmpeg-devel] [PATCH] avfilter/af_afade: improve accuracy and speed of gain computation

On Thu, Nov 26, 2015 at 9:10 AM, Ganesh Ajjanagadde wrote: > On Thu, Nov 26, 2015 at 9:05 AM, Paul B Mahol wrote: >> You gonna apply this? or? > > I am, later today (pushing with some other stuff). pushed, thanks.

Re: [FFmpeg-devel] [PATCHv2] avutil/lls: speed up performance of solve_lls

On Wed, Nov 25, 2015 at 6:29 AM, Michael Niedermayer wrote: > On Tue, Nov 24, 2015 at 10:13:22PM -0500, Ganesh Ajjanagadde wrote: >> This is a trivial rewrite of the loops that results in better >> prefetching and associated cache efficiency. Essentially, the problem is >> that

Re: [FFmpeg-devel] [PATCH 10/10] avfilter/vsrc_mptestsrc: use hypot()

On Wed, Nov 25, 2015 at 12:54 PM, Michael Niedermayer wrote: > On Sun, Nov 22, 2015 at 12:05:50PM -0500, Ganesh Ajjanagadde wrote: >> Signed-off-by: Ganesh Ajjanagadde >> --- >> libavfilter/vsrc_mptestsrc.c | 2 +- >> 1 file changed, 1 insertion(+), 1

Re: [FFmpeg-devel] [PATCH] avfilter/af_dynaudnorm: remove wasteful pow

On Wed, Nov 25, 2015 at 4:16 AM, Paul B Mahol wrote: > On 11/25/15, Ganesh Ajjanagadde wrote: >> This removes wasteful pow(x, 2.0) that although not terribly important >> for speed, is still useless. >> >> Signed-off-by: Ganesh Ajjanagadde

Re: [FFmpeg-devel] [PATCH] configure: add host libm capability detection

On Thu, Nov 26, 2015 at 8:50 AM, Hendrik Leppkes wrote: > On Thu, Nov 26, 2015 at 2:10 PM, Ganesh Ajjanagadde wrote: >> On Thu, Nov 26, 2015 at 2:49 AM, Hendrik Leppkes wrote: >>> On Thu, Nov 26, 2015 at 6:04 AM, Ganesh Ajjanagadde >>>

Re: [FFmpeg-devel] [PATCH] fate: add FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM tests

On Thu, Nov 26, 2015 at 11:57:46AM +0100, Matthieu Bouron wrote: > On Thu, Nov 26, 2015 at 01:12:44AM +0100, Michael Niedermayer wrote: > > On Wed, Nov 25, 2015 at 09:14:48PM +0100, Matthieu Bouron wrote: > > > On Wed, Nov 25, 2015 at 06:36:03PM +0100, Michael Niedermayer wrote: > > > > On Wed,

[FFmpeg-devel] [PATCHv2 1/3] avutil/tablegen: add tablegen compatibility hacks

Based on a suggestion by Ronald S. Bultje. Signed-off-by: Ganesh Ajjanagadde --- libavutil/tablegen.h | 32 1 file changed, 32 insertions(+) create mode 100644 libavutil/tablegen.h diff --git a/libavutil/tablegen.h

[FFmpeg-devel] [PATCHv2 2/3] avcodec/mpegaudio_tablegen: speed up table generation

This does some miscellaneous stuff mainly avoiding the usage of pow to achieve significant speedups. This is not speed critical, but is unnecessary latency and cycles wasted for a user. All tables tested and are identical to the old ones (bit-exact even in floating point case). Sample benchmark

[FFmpeg-devel] [PATCHv3 3/3] avcodec/cbrt_tablegen: avoid pow and speed up cbrt_tableinit

On systems having cbrt, there is no reason to use the slow pow function. Sample benchmark (x86-64, Haswell, GNU/Linux): new: 5124920 decicycles in cbrt_tableinit, 1 runs, 0 skips old: 12321680 decicycles in cbrt_tableinit, 1 runs, 0 skips Signed-off-by: Ganesh Ajjanagadde

Re: [FFmpeg-devel] [PATCHv2 2/3] avcodec/mpegaudio_tablegen: speed up table generation

Hi, On Thu, Nov 26, 2015 at 10:23 AM, Ganesh Ajjanagadde wrote: > This does some miscellaneous stuff mainly avoiding the usage of pow to > achieve significant speedups. This is not speed critical, but is > unnecessary latency and cycles wasted for a user. > > All tables

Re: [FFmpeg-devel] [PATCHv3 3/3] avcodec/cbrt_tablegen: avoid pow and speed up cbrt_tableinit

Hi, On Thu, Nov 26, 2015 at 10:23 AM, Ganesh Ajjanagadde wrote: > #if CONFIG_HARDCODED_TABLES > +#include "libavutil/tablegen.h" > #if USE_FIXED > #define cbrt_tableinit_fixed() > #include "libavcodec/cbrt_fixed_tables.h" > @@ -43,19 +45,19 @@ > #include

Re: [FFmpeg-devel] [PATCHv2 2/3] avcodec/mpegaudio_tablegen: speed up table generation

On Thu, Nov 26, 2015 at 10:37 AM, Ronald S. Bultje wrote: > Hi, > > On Thu, Nov 26, 2015 at 10:23 AM, Ganesh Ajjanagadde > wrote: >> >> This does some miscellaneous stuff mainly avoiding the usage of pow to >> achieve significant speedups. This is not

Re: [FFmpeg-devel] [PATCH] fate: add FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM tests

On Thu, Nov 26, 2015 at 04:07:00PM +0100, Michael Niedermayer wrote: > On Thu, Nov 26, 2015 at 11:57:46AM +0100, Matthieu Bouron wrote: > > On Thu, Nov 26, 2015 at 01:12:44AM +0100, Michael Niedermayer wrote: > > > On Wed, Nov 25, 2015 at 09:14:48PM +0100, Matthieu Bouron wrote: > > > > On Wed,

Re: [FFmpeg-devel] [PATCH 0/4] more accurate constants

On Thu, Nov 26, 2015 at 1:26 PM, Ganesh Ajjanagadde wrote: >> Does removing the L fix it? > Read up a bit and suspect it should, and more generally long double is > a can of worms on ppc with bugs on some compilers: > https://gcc.gnu.org/wiki/Ieee128PowerPC, ABI in transition,

Re: [FFmpeg-devel] [PATCH 2/4] lavf/utils: avoid decoding a frame to get the codec parameters

On Thu, Nov 19, 2015 at 12:10:20PM +0100, Matthieu Bouron wrote: > On Mon, Nov 16, 2015 at 11:16:42AM -0500, Ronald S. Bultje wrote: > > Hi, > > > > On Mon, Nov 16, 2015 at 11:06 AM, Matthieu Bouron > > wrote: > > > > > On Sun, Nov 15, 2015 at 08:12:57AM -0500,

Re: [FFmpeg-devel] [PATCH 0/4] more accurate constants

On Thu, Nov 26, 2015 at 11:15 AM, John Warburton wrote: > On Thu, Nov 26, 2015 at 1:26 PM, Ganesh Ajjanagadde wrote: > >>> Does removing the L fix it? > >> Read up a bit and suspect it should, and more generally long double is >> a can of worms on ppc

[FFmpeg-devel] [PATCHv3 1/3] avutil/tablegen: add tablegen compatibility hacks

Reviewed-by: Ronald S. Bultje Signed-off-by: Ganesh Ajjanagadde --- libavutil/tablegen.h | 33 + 1 file changed, 33 insertions(+) create mode 100644 libavutil/tablegen.h diff --git a/libavutil/tablegen.h

[FFmpeg-devel] [PATCHv3 3/3] avcodec/cbrt_tablegen: avoid pow and speed up cbrt_tableinit

On systems having cbrt, there is no reason to use the slow pow function. Sample benchmark (x86-64, Haswell, GNU/Linux): new: 5124920 decicycles in cbrt_tableinit, 1 runs, 0 skips old: 12321680 decicycles in cbrt_tableinit, 1 runs, 0 skips Reviewed-by: Ronald S. Bultje

Re: [FFmpeg-devel] [PATCHv2 2/3] avcodec/mpegaudio_tablegen: speed up table generation

On Thu, Nov 26, 2015 at 10:44 AM, Ganesh Ajjanagadde wrote: > On Thu, Nov 26, 2015 at 10:37 AM, Ronald S. Bultje wrote: >> Hi, >> >> On Thu, Nov 26, 2015 at 10:23 AM, Ganesh Ajjanagadde >> wrote: >>> >>> This does some

Re: [FFmpeg-devel] [PATCHv3 3/3] avcodec/cbrt_tablegen: avoid pow and speed up cbrt_tableinit

On Thu, Nov 26, 2015 at 10:39 AM, Ronald S. Bultje wrote: > Hi, > > On Thu, Nov 26, 2015 at 10:23 AM, Ganesh Ajjanagadde > wrote: >> >> #if CONFIG_HARDCODED_TABLES >> +#include "libavutil/tablegen.h" >> #if USE_FIXED >> #define

[FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

Signed-off-by: Nicolas George --- libavformat/flvdec.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c index ca73969..96fff68 100644 --- a/libavformat/flvdec.c +++ b/libavformat/flvdec.c @@ -882,7

[FFmpeg-devel] [PATCH 1/3] lavu/error: add AVERROR_REDO.

It is meant for demuxers to signal that they consumed data but did not return a packet; the framework is then supposed to loop. Signed-off-by: Nicolas George --- libavutil/error.c | 1 + libavutil/error.h | 2 +- libavutil/version.h | 2 +- 3 files changed, 3 insertions(+),

[FFmpeg-devel] [PATCH 2/3] lavf/utils: handle AVERROR_REDO.

Signed-off-by: Nicolas George --- libavformat/utils.c | 2 ++ 1 file changed, 2 insertions(+) An option can be added later to grant applications fine-grained control on the looping, but it can not be the default as it would be an API change, and it probably should not be the

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

On Thu, 26 Nov 2015 19:47:54 +0100 Nicolas George wrote: > Signed-off-by: Nicolas George > --- > libavformat/flvdec.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c > index

Re: [FFmpeg-devel] [PATCH 2/4] lavf/utils: avoid decoding a frame to get the codec parameters

On Thu, Nov 26, 2015 at 05:16:32PM +0100, Matthieu Bouron wrote: > On Thu, Nov 19, 2015 at 12:10:20PM +0100, Matthieu Bouron wrote: > > On Mon, Nov 16, 2015 at 11:16:42AM -0500, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Mon, Nov 16, 2015 at 11:06 AM, Matthieu Bouron > > >

Re: [FFmpeg-devel] [PATCH 2/3] lavf/utils: handle AVERROR_REDO.

On Thu, Nov 26, 2015 at 07:47:53PM +0100, Nicolas George wrote: > Signed-off-by: Nicolas George > --- > libavformat/utils.c | 2 ++ > 1 file changed, 2 insertions(+) > > > An option can be added later to grant applications fine-grained control on > the looping, but it can not

Re: [FFmpeg-devel] [PATCH 1/3] lavu/error: add AVERROR_REDO.

On Thu, Nov 26, 2015 at 07:47:52PM +0100, Nicolas George wrote: > It is meant for demuxers to signal that they consumed data > but did not return a packet; the framework is then supposed > to loop. > > Signed-off-by: Nicolas George > --- > libavutil/error.c | 1 + >

Re: [FFmpeg-devel] [PATCH 2/4] lavf/utils: avoid decoding a frame to get the codec parameters

Hi, On Thu, Nov 26, 2015 at 11:16 AM, Matthieu Bouron wrote: > On Thu, Nov 19, 2015 at 12:10:20PM +0100, Matthieu Bouron wrote: > > On Mon, Nov 16, 2015 at 11:16:42AM -0500, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Mon, Nov 16, 2015 at 11:06 AM, Matthieu

Re: [FFmpeg-devel] [PATCH 3/3] lavf/flvdec: use AVERROR_REDO instead of AVERROR(EAGAIN).

Le sextidi 6 frimaire, an CCXXIV, wm4 a écrit : > Better do the looping internal in flvdec.c (if there's no huge number > of other demuxers which need this), instead of adding a new error code > that is also part of the public API. There are a few, but not many. This was my first intent, but