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: Freitag, 6. November 20
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), AV_OPT_TYP
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 the shortest input t
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 FATE. ppc untested.
Sorry t
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: Matth
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 is
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
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 accuracy benefits on the "default"
>> x86-64
>> GNU/Lin
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 created.
>>
>
> I'm really not a fan of this
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 run by a user.
>
> I agree. It
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 maximizes accuracy on all platforms for
>>> avcodec/faandct. It result
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 at 8:29 PM, Ganesh Ajjanagadde
> >> wrote:
> >> > On Wed,
On Thu, Nov 26, 2015 at 8:27 AM, Ronald S. Bultje wrote:
> 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 W
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 6:49 PM, James Almer wrote:
> >> > On 11/25/2015 8:32 PM,
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
>> wrote:
>>> This is needed in order to obtain what is available for hardcoded
>>> table generation.
>>>
>>> A minimal avut
You gonna apply this? or?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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
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 7:36 PM, Ganesh Ajjanagadde
>> > wrote:
>> >
>> >> On Wed,
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
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.
___
ffmpeg-devel mailing list
ffmpeg-d
On Wed, Nov 25, 2015 at 09:35:06PM -0800, Timothy Gu wrote:
> ---
> ffprobe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
should be ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Avoid a single point of failure, be that a person or equipment.
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 modern prefetching
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 deletion(-)
>
> should be ok
>
> thx
pushed
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
>> -
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
>>> wrote:
This is needed in order to obtain what is avail
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, Nov
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 b/libavutil/tablegen.h
new file mode 100644
in
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 (
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
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 tested and are identical
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 "libavcodec/cbrt_tables.h"
> #endif
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 speed critical, but is
>> unnecessary latency
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, Nov
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,
> https://llvm.org
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, Ronald S. Bultje wrote:
> > > > Hi
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 with bugs on some compilers:
>> https://gcc.g
Le quintidi 5 frimaire, an CCXXIV, Timothy Gu a écrit :
> ---
> ffprobe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
According to the other patch, it prints "unknown". It would be better to
print it numerically or something. Although, if this is consistent with
other places, I have n
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 b/libavutil/tablegen.h
new file mode 100644
index 000.
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 (
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
Sign
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 miscellaneous stuff mainly avoiding the usage of pow to
>>> achieve significa
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 cbrt_tableinit_fixed()
>> #include "libavcodec/cbrt_fixed_tables.
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 +882,7 @@ retry:
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(+), 2 deletions(-)
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 default anyway.
d
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 ca73969..96fff68 100644
> --- a/liba
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
> > > > > > wrote:
> >
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 be the default as
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 +
> libavutil/error.h | 2 +-
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 Bouron <
> matthieu.bou...@gmail.
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 loopi
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
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 |
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 of the public API.
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
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:
http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-October/18068
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 you off.
-compn
_
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,
> > > >
>
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 only file. I'll get my patch
> > landed in
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 demuxers which need this), instead of add
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 im
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 a trivial increase in
> t
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 h
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 be the default as
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 == A
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 the
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
___
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 reduce the dynamic
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 t
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.
Bu
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
71 matches
Mail list logo
