From: Alex Smith
The appropriate flag for HEASLR (--high-entropy-va) was added in
binutils 2.25.
Also set the image base >4GB so higher entropy gets applied to image
base randomization when used with HEASLR (8 -> 17 bits of
randomization). Windows does this for compatibility because of "latent
Hi,
2015-09-26 1:52 GMT+02:00 Michael Niedermayer :
> This segfaults with
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2125/DNxHDtest2.mov
Can't reproduce with frame or slice threading or no threading. What
was the command-line?
> #3 0x00af53fd in avcodec_default_execute2 (c=0x1c
They were added to binutils in the same version so it's safe to combine.
Signed-off-by: Alex Smith
---
configure | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/configure b/configure
index 3339126..b572d59 100755
--- a/configure
+++ b/configure
@@ -4367,8 +4367,6 @@ case $t
> ffmpeg | branch: master | Claudio Freire | Fri
> Sep 25 03:56:32 2015 -0300| [9458a62decfcaa1313b1ba69276466de536d0768] |
> committer: Claudio Freire
>
> AAC encoder: tweak PNS usage to be more aggressive
>
> This patch tweaks search_for_pns to be both more
> aggressive and more careful when a
On Tue, Sep 22, 2015 at 03:45:59PM +0200, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Sep 21, 2015 at 4:55 AM, Rodger Combs
> wrote:
>
> > ---
> > tests/checkasm/vp9dsp.c | 108
> > +---
> > 1 file changed, 57 insertions(+), 51 deletions(-)
>
>
> LGTM
Signed-off-by: James Almer
---
libswresample/x86/audio_convert.asm | 122 ++--
1 file changed, 61 insertions(+), 61 deletions(-)
diff --git a/libswresample/x86/audio_convert.asm
b/libswresample/x86/audio_convert.asm
index e9a9acf..d441636 100644
--- a/libswresamp
On Mon, Sep 21, 2015 at 01:25:15PM -0500, Rodger Combs wrote:
> ---
> libavutil/opt.c | 12 ++--
> libavutil/opt.h | 10 ++
> libavutil/version.h | 2 +-
> 3 files changed, 21 insertions(+), 3 deletions(-)
LGTM
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147
Assumes 'GA94' format (ATSC standard)
Signed-off-by: DHE
---
doc/encoders.texi| 5 +
libavcodec/libx264.c | 37 +
2 files changed, 42 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 3550bcc..bb16dea 100644
--- a/doc/encoders.te
On 09/25/2015 07:45 PM, Carl Eugen Hoyos wrote:
> DeHackEd dehacked.net> writes:
>
>> + item a53cc
>> +Import closed captions (which must be ATSC compatible format) into output.
>> +At this time only the mpeg2 decoder provides these.
>
> I thought the h264 decoder also provides them, no?
Indee
This patch completes the removal of all uses of av_set_cpu_flags_mask, so the
deprecated function can be removed in a future version bump.
Signed-off-by: Ganesh Ajjanagadde
---
tests/checkasm/checkasm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/checkasm/checkasm
On Fri, Sep 25, 2015 at 11:25:06PM +0200, Christophe Gisquet wrote:
> Around 3x speedup with 4 threads. Maybe more mb lines should be
> batched per thread, but that's good enough for a first try.
> ---
> libavcodec/dnxhddec.c | 221
> ++
> 1 file ch
DeHackEd dehacked.net> writes:
> + item a53cc
> +Import closed captions (which must be ATSC compatible format) into output.
> +At this time only the mpeg2 decoder provides these.
I thought the h264 decoder also provides them, no?
Carl Eugen
___
ffmp
On Fri, Sep 25, 2015 at 11:25:07PM +0200, Christophe Gisquet wrote:
> It is supposed to only old BT.709 colorspaces.
> ---
> libavcodec/dnxhddec.c | 1 +
> 1 file changed, 1 insertion(+)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a bli
Assumes 'GA94' format (ATSC standard)
Signed-off-by: DHE
---
doc/encoders.texi| 5 +
libavcodec/libx264.c | 37 +
2 files changed, 42 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 3550bcc..8e3770b 100644
--- a/doc/encoders.te
Hi,
On Fri, Sep 25, 2015 at 6:42 PM, Henrik Gramner wrote:
> On Fri, Sep 25, 2015 at 5:25 PM, Ronald S. Bultje
> wrote:
> > ---
> > tests/checkasm/vp9dsp.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Ok as long as it doesn't skew the range distribution so much that
> you'
On Fri, Sep 25, 2015 at 5:25 PM, Ronald S. Bultje wrote:
> ---
> tests/checkasm/vp9dsp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Ok as long as it doesn't skew the range distribution so much that
you'll end up with the same max clipped value all the time.
_
On Fri, Sep 25, 2015 at 10:06:41PM +0200, Henrik Gramner wrote:
> On Fri, Sep 25, 2015 at 9:57 PM, Michael Niedermayer wrote:
> > is there any reason why this doesnt use
> > libavutil/tree.* ?
>
> Two reasons basically.
>
> First, the glue code required to use a generic tree implementation
> ins
On Fri, Sep 25, 2015 at 4:04 PM, Kyle Swanson wrote:
> Signed-off-by: Kyle Swanson
> ---
> doc/filters.texi| 9 +
> libavfilter/f_ebur128.c | 22 ++
> 2 files changed, 31 insertions(+)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 044876c..e633
Indicates a YCbCr->RGB transform at the block level. Although nothing
explicitly states it, this would assume the actual content is planar
RGB.
Currently unsupported, but the one sequence I found using it flagged
every mb that way, actually meaning the content was YCbCr, and thus
best left to the
It currently only applies to CID 1260, but this flag is dependent on
a higher-level flag located in the header.
---
libavcodec/dnxhddec.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 0722aa0..82a0d3c 100644
--- a/liba
It is supposed to only old BT.709 colorspaces.
---
libavcodec/dnxhddec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index d9762e4..0722aa0 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -82,6 +82,7 @@ static av_cold int dnxh
Around 3x speedup with 4 threads. Maybe more mb lines should be
batched per thread, but that's good enough for a first try.
---
libavcodec/dnxhddec.c | 221 ++
1 file changed, 133 insertions(+), 88 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/l
The ones I'm not very pleased with are the first and last ones.
I don't understand in the first one why I have to special case
frame-threading to not run execute2. But I'm discovering the API.
The last one feels like incomplete work. I do have a working patch to
implement the feature, but until t
---
libavcodec/x86/Makefile | 1 +
libavcodec/x86/constants.c | 6 +
libavcodec/x86/constants.h | 3 +
libavcodec/x86/h264_idct_10bit.asm | 5 +-
libavcodec/x86/h264_intrapred_10bit.asm | 2 +-
libavcodec/x86/vp9dsp_init.
Hi,
On Fri, Sep 25, 2015 at 5:09 PM, Christophe Gisquet <
christophe.gisq...@gmail.com> wrote:
> Hi,
>
> 2015-09-25 22:36 GMT+02:00 Ronald S. Bultje :
> > +pd_16: times 8 dd 16
>
> In h264_intrapred_10bit.asm
>
> > +pd_32: times 8 dd 32
>
> In h264_idct_10bit.asm
>
> And that's about anything rem
Hi,
2015-09-25 22:36 GMT+02:00 Ronald S. Bultje :
> +pd_16: times 8 dd 16
In h264_intrapred_10bit.asm
> +pd_32: times 8 dd 32
In h264_idct_10bit.asm
And that's about anything remotely useful I have to say, as you were
careful about those duplications.
> +pmaxsw m0, m4
> +
Signed-off-by: Kyle Swanson
---
doc/filters.texi| 9 +
libavfilter/f_ebur128.c | 22 ++
2 files changed, 31 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index 044876c..e63311a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12642,6
---
libavcodec/x86/Makefile | 1 +
libavcodec/x86/constants.c | 2 +
libavcodec/x86/constants.h | 1 +
libavcodec/x86/vp9dsp_init.h| 23 +
libavcodec/x86/vp9dsp_init_16bpp.c | 15 +
libavcodec/x86/vp9dsp_init_16
On Fri, Sep 25, 2015 at 9:57 PM, Michael Niedermayer wrote:
> is there any reason why this doesnt use
> libavutil/tree.* ?
Two reasons basically.
First, the glue code required to use a generic tree implementation
instead of one customized for this use case would be as large as the
implementation
On Fri, Sep 25, 2015 at 09:28:26PM +0200, Henrik Gramner wrote:
> Tested functions are internally kept in a binary search tree for efficient
> lookups. The downside of the current implementation is that the tree quickly
> becomes unbalanced which causes an unneccessary amount of comparisons between
Tested functions are internally kept in a binary search tree for efficient
lookups. The downside of the current implementation is that the tree quickly
becomes unbalanced which causes an unneccessary amount of comparisons between
nodes. Improve this by changing the tree into a self-balancing left-l
On Fri, Sep 25, 2015 at 06:57:18PM +0200, Christophe Gisquet wrote:
> From: Jeremy James
>
> CID 1260 (as evidenced by incorrect decoding of a sample from ticket
> 4876) seems to use incorrect weight tables. It appears those tables
> were not zigzag-scanned.
>
> Apply zigzag on weight tables for
On Fri, Sep 25, 2015 at 06:57:17PM +0200, Christophe Gisquet wrote:
> This bit is 1 in some samples, and seems to coincide with interlaced
> mbs and CID1260. 2008 specs do not know about it, and maintain qscale
> is 11 bits. This looks oversized, but may help larger bitdepths.
>
> Currently, it le
On Fri, Sep 25, 2015 at 09:41:59PM +1000, Matt Oliver wrote:
> On 25 September 2015 at 17:58, Matt Oliver wrote:
>
> > Allows the decklink device to be used with native win32/os2 threads
> > instead of just pthreads.
> >
> > Note: I dont have a decklink device to test this but It just allows the
On Fri, Sep 18, 2015 at 5:15 PM, Ganesh Ajjanagadde
wrote:
> This patch results in identical behavior of movenc, and suppresses
> -Wstrict-overflow
> warnings observed in GCC 5.2.
> I have manually checked that all usages are safe, and overflow possibility
> does
> not exist with this expression
On Sat, Sep 19, 2015 at 10:18 PM, Ganesh Ajjanagadde
wrote:
> This fixes -Wshift-negative-value reported with clang 3.7+, e.g
> http://fate.ffmpeg.org/log.cgi?time=20150919172459&log=compile&slot=x86_64-darwin-clang-polly-notiling-3.7.
> Note that the patch crucially depends on int >= 32 bits,
> a
On Fri, 25 Sep 2015 19:08:57 +0200
Hendrik Leppkes wrote:
> On Fri, Sep 25, 2015 at 7:06 PM, compn wrote:
> > On Fri, 25 Sep 2015 10:42:18 +0200
> > Clément Bœsch wrote:
> >
> >> On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote:
> >> > Hi Voting Committee
> >> >
> >> > This mail is
Hi All,
currently, select option of tee pseudo muxer may contain only one stream
specifier. Sometimes I need to use more than one stream specifier.
So I made the following patch. It makes possible to put multiple stream
specifier into select option separated by comma.
eg. select=\'a:0,v\'
(I c
On Fri, Sep 25, 2015 at 7:06 PM, compn wrote:
> On Fri, 25 Sep 2015 10:42:18 +0200
> Clément Bœsch wrote:
>
>> On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote:
>> > Hi Voting Committee
>> >
>> > This mail is an attempt to try out the process described on
>> > http://lists.ffmpeg.org
On Fri, 25 Sep 2015 10:42:18 +0200
Clément Bœsch wrote:
> On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote:
> > Hi Voting Committee
> >
> > This mail is an attempt to try out the process described on
> > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html
> >
From: Jeremy James
CID 1260 (as evidenced by incorrect decoding of a sample from ticket
4876) seems to use incorrect weight tables. It appears those tables
were not zigzag-scanned.
Apply zigzag on weight tables for new CIDs 1258, 1259, and 1260, and
fix an incorrect chroma table for CID 1256.
F
This bit is 1 in some samples, and seems to coincide with interlaced
mbs and CID1260. 2008 specs do not know about it, and maintain qscale
is 11 bits. This looks oversized, but may help larger bitdepths.
Currently, it leads to an obviously incorrect qscale value, meaning
its syntax is shifted by 1
There are 2 issues, listed in ticket #4876:
- new mb header syntax, where the firt bit indicates mbaff-like handling
- incorrectly scanned weight tables
Christophe Gisquet (1):
dnxhddec: decode and use interlace mb flag
Jeremy James (1):
dnxhddata: correct weight tables
libavcodec/dnxhddata
On 2015-09-24 20:37, Nicolas George wrote:
> Le tridi 3 vendémiaire, an CCXXIV, James Darnley a écrit :
>> I don't know what to say here. I know the encodings needed for iconv
>> because I arrived at them by brute force. I wrote a short Lua script to
>> iterate over a list of encodings supported
---
tests/checkasm/vp9dsp.c | 275
1 file changed, 275 insertions(+)
diff --git a/tests/checkasm/vp9dsp.c b/tests/checkasm/vp9dsp.c
index eb9228a..b091905 100644
--- a/tests/checkasm/vp9dsp.c
+++ b/tests/checkasm/vp9dsp.c
@@ -18,12 +18,15 @@
* 51
As much as I find it gratifying for my ego to see you all welcome us back
like that, I must say all your votes are both invalid, and, fortunately,
unnecessary. :) Well, this is an unimportant technicality for now, but if we
are to use this system, we better understand it correctly.
The votes are
On Fri, Sep 25, 2015 at 11:23 AM, wm4 wrote:
> On Fri, 25 Sep 2015 15:16:34 +
> Lucas Andrade wrote:
>
>> Ok, I know I did it wrong with the PR. I've used the PR to create the
>> patch. Sorry for trying to help.
>> Anyway, here it is the all-in-one patch.
>
> Thanks! I applied and pushed it.
---
libavcodec/x86/Makefile | 1 +
libavcodec/x86/vp9dsp_init_16bpp_template.c | 88 +++
libavcodec/x86/vp9lpf_16bpp.asm | 832
3 files changed, 921 insertions(+)
create mode 100644 libavcodec/x86/vp9lpf_16bpp.asm
diff --git a/libav
---
tests/checkasm/vp9dsp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/vp9dsp.c b/tests/checkasm/vp9dsp.c
index 43fa3a4..692376f 100644
--- a/tests/checkasm/vp9dsp.c
+++ b/tests/checkasm/vp9dsp.c
@@ -370,9 +370,9 @@ static void check_itxfm(void)
#define
On Fri, 25 Sep 2015 15:16:34 +
Lucas Andrade wrote:
> Ok, I know I did it wrong with the PR. I've used the PR to create the
> patch. Sorry for trying to help.
> Anyway, here it is the all-in-one patch.
Thanks! I applied and pushed it. Sorry for the back and forth.
___
Ok, I know I did it wrong with the PR. I've used the PR to create the
patch. Sorry for trying to help.
Anyway, here it is the all-in-one patch.
Update Cookies response with Setcookie.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-de
On Fri, Sep 25, 2015 at 12:36 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 5:15 AM, wm4 wrote:
>
>> On Fri, 25 Sep 2015 10:42:18 +0200
>> Clément Bœsch wrote:
>>
>> > On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote:
>> > > Hi Voting Committee
>> > >
>> > > This mai
On Fri, Sep 25, 2015 at 2:46 PM, Ståle Kristoffersen
wrote:
> On 2015-09-01 at 16:27, Rainer Hochecker wrote:
>>
>> fix splitting extradata from ts
>
> Hi,
> this commit introduces a regression for me.
> I'm trying to extract a thumb from the middle of a live TS, containing one
> HEVC-stream.
> Un
On Fri, Sep 25, 2015 at 9:50 AM, Lucas Andrade wrote:
> Here it is. Also sent as PR on github.
FYI, we don't do pull requests on github:
See "Contributing" at https://github.com/FFmpeg/FFmpeg.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.o
On Fri, 25 Sep 2015 14:23:27 +
Lucas Andrade wrote:
> Ok, I'll try to merge all those patches at a single one.
Should be simple enough... the reason why I want a git format-patch is
that you can set your commit message, author name, and email properly.
Sorry for not clarifying this earlier.
Ok, I'll try to merge all those patches at a single one.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Fri, 25 Sep 2015 13:50:28 +
Lucas Andrade wrote:
> From 1fd6d3c584678917bd0a262bfbbbfaa7181add08 Mon Sep 17 00:00:00 2001
> From: Lucas de Andrade
> Date: Tue, 22 Sep 2015 00:58:03 -0300
> Subject: [PATCH 1/8] Update Cookies Setcookie response
>
> Update Cookies Setcookie response
> ---
Here it is. Also sent as PR on github.
Update Cookies Setcookie response.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Fri, 25 Sep 2015 13:38:20 +
Lucas Andrade wrote:
> I did test with a similar command posted on the tracker, cookies were
> updated correctly.
Wanted to apply, but it's only a .diff. Can you send a patch produced
with git format-patch?
Also, stop https://en.wikipedia.org/wiki/Posting_styl
I did test with a similar command posted on the tracker, cookies were
updated correctly.
Em sex, 25 de set de 2015 às 10:26, wm4 escreveu:
> On Fri, 25 Sep 2015 02:00:29 +
> Lucas Andrade wrote:
>
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index adaa33a..f9f86af 100644
> > -
> If anyone has a suggestion for a free & simple online poll, I'm listening.
> A poll system where people can pick the importance of each entry would be
> perfect.
I've used this successfully in the past: https://www.surveymonkey.com/
___
ffmpeg-devel ma
On Fri, 25 Sep 2015 02:00:29 +
Lucas Andrade wrote:
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index adaa33a..f9f86af 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -525,6 +525,14 @@ static int url_connect(struct playlist *pls,
> AVDictionary *opts, AVDictionary
On Fri, 25 Sep 2015 14:43:37 +0200
Alexis Ballier wrote:
> On Fri, 25 Sep 2015 12:22:51 +0200
> Clément Bœsch wrote:
>
> > Hi,
> >
> > With the increasing number of hardware accelerated API, the need for a
> > proper M:N asynchronous API is growing. We've observed that with MMAL
> > and VideoT
On Fri, 25 Sep 2015 10:41:44 +0200
Clément Bœsch wrote:
> Hi,
>
> I'd like to suggest a poll for the community in order to define some more
> clear directions for the project. I plan to post the poll on the mailing
> lists and IRC, people are free to forward them elsewhere.
>
> If anyone has a
On Fri, Sep 25, 2015 at 10:41:44AM +0200, Clément Bœsch wrote:
> Hi,
>
> I'd like to suggest a poll for the community in order to define some more
> clear directions for the project. I plan to post the poll on the mailing
> lists and IRC, people are free to forward them elsewhere.
>
> If anyone h
Le quartidi 4 vendémiaire, an CCXXIV, Alexis Ballier a écrit :
> - Why not merging AVPacket into AVFrame ? This would restore the
> symmetry between encoding and decoding. This is actually what V4L
> does.
I would gladly support that.
> - This could go one step further with a lavfi wrapper: d
On 2015-09-01 at 16:27, Rainer Hochecker wrote:
>
> fix splitting extradata from ts
Hi,
this commit introduces a regression for me.
I'm trying to extract a thumb from the middle of a live TS, containing one
HEVC-stream.
Unfortunately I'm not sure if I can provide a sample, but before this patch
I
On Fri, 25 Sep 2015 12:22:51 +0200
Clément Bœsch wrote:
> Hi,
>
> With the increasing number of hardware accelerated API, the need for a
> proper M:N asynchronous API is growing. We've observed that with MMAL
> and VideoToolBox accelerations typically. Similarly, the incoming
> MediaCodec hwacce
On Fri, Sep 25, 2015 at 4:41 AM, Clément Bœsch wrote:
> Hi,
>
> I'd like to suggest a poll for the community in order to define some more
> clear directions for the project. I plan to post the poll on the mailing
> lists and IRC, people are free to forward them elsewhere.
>
> If anyone has a sugge
On 25 September 2015 at 17:58, Matt Oliver wrote:
> Allows the decklink device to be used with native win32/os2 threads
> instead of just pthreads.
>
> Note: I dont have a decklink device to test this but It just allows the
> use of the already tested win32/os2 pthread simulation functions so the
Hi,
On Fri, Sep 25, 2015 at 6:22 AM, Clément Bœsch wrote:
> Hi,
>
> With the increasing number of hardware accelerated API, the need for a
> proper M:N asynchronous API is growing. We've observed that with MMAL and
> VideoToolBox accelerations typically. Similarly, the incoming MediaCodec
> hwac
Hi,
On Fri, Sep 25, 2015 at 5:15 AM, wm4 wrote:
> On Fri, 25 Sep 2015 10:42:18 +0200
> Clément Bœsch wrote:
>
> > On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote:
> > > Hi Voting Committee
> > >
> > > This mail is an attempt to try out the process described on
> > >
> http://lists
2015-09-25 15:56 GMT+08:00 Matt Oliver :
> Allows async to be compiled and used when using native win32/os2 threads
> aswell as pthreads.
LGTM about async.
BTW:
Attachment of "[PATCH 3/3]" seems missing.
Regards.
___
ffmpeg-devel mailing list
ffmpeg-de
Hi,
With the increasing number of hardware accelerated API, the need for a
proper M:N asynchronous API is growing. We've observed that with MMAL and
VideoToolBox accelerations typically. Similarly, the incoming MediaCodec
hwaccel is going to suffer from the same limitations.
Some Libav developers
On 9/25/15, wm4 wrote:
> On Fri, 25 Sep 2015 10:42:18 +0200
> Clément Bœsch wrote:
>
>> On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote:
>> > Hi Voting Committee
>> >
>> > This mail is an attempt to try out the process described on
>> > http://lists.ffmpeg.org/pipermail/ffmpeg-devel
On Fri, Sep 25, 2015 at 11:15:20AM +0200, wm4 wrote:
> On Fri, 25 Sep 2015 10:42:18 +0200
> Clément Bœsch wrote:
>
> > On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote:
> > > Hi Voting Committee
> > >
> > > This mail is an attempt to try out the process described on
> > > http://lis
On Fri, 25 Sep 2015 10:42:18 +0200
Clément Bœsch wrote:
> On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote:
> > Hi Voting Committee
> >
> > This mail is an attempt to try out the process described on
> > http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html
> >
On Sun, Sep 20, 2015 at 12:55:11PM +0200, Clément Bœsch wrote:
> Hi Voting Committee
>
> This mail is an attempt to try out the process described on
> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178858.html
>
> This thread is a call for the following people:
> Michael Nieder
Hi,
I'd like to suggest a poll for the community in order to define some more
clear directions for the project. I plan to post the poll on the mailing
lists and IRC, people are free to forward them elsewhere.
If anyone has a suggestion for a free & simple online poll, I'm listening.
A poll system
Allows the decklink device to be used with native win32/os2 threads instead
of just pthreads.
Note: I dont have a decklink device to test this but It just allows the use
of the already tested win32/os2 pthread simulation functions so there
shouldnt be any issues.
__
Allows async to be compiled and used when using native win32/os2 threads
aswell as pthreads.
0002-avformat-async-Allow-compilation-with-native-threads.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org
Some functions in the native win32 thread wrappers dont return a value.
Since the pthread functions they are simulating do return a value (aswell
as the equivalent os2 version) this patch updates them accordingly. This
makes the win32 variants more compatible with the pthread functions they
are emu
Paul B Mahol gmail.com> writes:
> > Attached patch makes the ICO demuxer return EOF instead
> > of EIO when the end of the file is reached. Currently,
> > if you try to parse an ICO file, it will always result
> > in ffmpeg outputting an error because of this.
>
> lgtm
Patch applied.
Thank
83 matches
Mail list logo
