Le jeudi 28 mai 2015, 18:23:27 wm4 a écrit :
OSX does not know MSG_NOSIGNAL, and provides its own non-standard
mechanism instead. I guess Apple hates standards.
Actually, SO_NOSIGPIPE is a BSD thing. It just happens to be so old that
Darwin inherited it. (And it was made redundant by
On Thu, 28 May 2015 11:30:57 +0300
Martin Storsjö mar...@martin.st wrote:
This fixes building with gcrypt-backed gnutls versions, broken
in 57cde2b180.
---
libavformat/tls_gnutls.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/tls_gnutls.c
There was a misunderstanding betewen bits and bytes for the parameter
value for generating random big numbers.
---
libavformat/rtmpdh.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
index f2deecd..e24725d 100644
---
---
libavformat/rtmpdh.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
index 211f4f1..f2deecd 100644
--- a/libavformat/rtmpdh.c
+++ b/libavformat/rtmpdh.c
@@ -147,11 +147,6 @@ static int dh_compute_key(FF_DH *dh, FFBigNum pub_key_bn,
On Thu, 28 May 2015, wm4 wrote:
On Thu, 28 May 2015 11:30:57 +0300
Martin Storsjö mar...@martin.st wrote:
This fixes building with gcrypt-backed gnutls versions, broken
in 57cde2b180.
---
libavformat/tls_gnutls.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
This fixes building with gcrypt-backed gnutls versions, broken
in 57cde2b180.
---
libavformat/tls_gnutls.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index 1d3f57c..4fe3b39 100644
--- a/libavformat/tls_gnutls.c
+++
---
libavformat/rtmpcrypt.c | 2 +-
libavformat/rtmpdh.c| 5 +++--
libavformat/rtmpdh.h| 6 --
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavformat/rtmpcrypt.c b/libavformat/rtmpcrypt.c
index dfdd029..887427d 100644
--- a/libavformat/rtmpcrypt.c
+++
This helps if these functions need to be implemented using another
crypto API.
---
libavformat/Makefile | 1 +
libavformat/rtmpdh.c | 142 +
tests/fate/libavformat.mak | 4 ++
tests/ref/fate/rtmpdh | 3 +
4 files changed, 150
---
libavformat/rtmpdh.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
index bd9813d..80cced9 100644
--- a/libavformat/rtmpdh.c
+++ b/libavformat/rtmpdh.c
@@ -189,7 +189,14 @@ void ff_dh_free(FF_DH *dh)
#define dh_new()
---
libavformat/rtmpdh.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
index ddb2a46..bd9813d 100644
--- a/libavformat/rtmpdh.c
+++ b/libavformat/rtmpdh.c
@@ -134,7 +134,7 @@ static FFBigNum dh_generate_key(FF_DH *dh)
}
---
libavformat/rtmpdh.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
index 38c2f3d..ddb2a46 100644
--- a/libavformat/rtmpdh.c
+++ b/libavformat/rtmpdh.c
@@ -77,6 +77,8 @@
bn_new(bn); \
if (bn)
On Thu, 28 May 2015 11:48:49 +0300 (EEST)
Martin Storsjö mar...@martin.st wrote:
On Thu, 28 May 2015, wm4 wrote:
On Thu, 28 May 2015 11:30:57 +0300
Martin Storsjö mar...@martin.st wrote:
This fixes building with gcrypt-backed gnutls versions, broken
in 57cde2b180.
---
On 28/05/15 10:32, Martin Storsjö wrote:
---
libavformat/rtmpdh.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
index bd9813d..80cced9 100644
--- a/libavformat/rtmpdh.c
+++ b/libavformat/rtmpdh.c
@@ -189,7 +189,14
On 28/05/15 10:32, Martin Storsjö wrote:
---
Seems ok
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 28/05/15 10:32, Martin Storsjö wrote:
---
libavformat/rtmpdh.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
index ddb2a46..bd9813d 100644
--- a/libavformat/rtmpdh.c
+++ b/libavformat/rtmpdh.c
@@ -134,7 +134,7 @@
On 28/05/15 10:32, Martin Storsjö wrote:
---
libavformat/rtmpdh.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
index 38c2f3d..ddb2a46 100644
--- a/libavformat/rtmpdh.c
+++ b/libavformat/rtmpdh.c
@@ -77,6 +77,8 @@
bn_new(bn);
On Thu, 28 May 2015, Luca Barbato wrote:
On 28/05/15 10:32, Martin Storsjö wrote:
---
libavformat/rtmpdh.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
index bd9813d..80cced9 100644
--- a/libavformat/rtmpdh.c
+++
From: Michael Niedermayer michae...@gmx.at
Simplifies the code and makes it build on certain compilers
running out of registers on x86.
CC: libav-sta...@libav.org
Reported-By: mudler
---
libavcodec/x86/cavsdsp.c | 28 +---
1 file changed, 13 insertions(+), 15
On 28/05/15 10:32, Martin Storsjö wrote:
This helps if these functions need to be implemented using another
crypto API.
---
libavformat/Makefile | 1 +
libavformat/rtmpdh.c | 142
+
tests/fate/libavformat.mak | 4 ++
On 28/05/15 10:43, Martin Storsjö wrote:
There was a misunderstanding betewen bits and bytes for the parameter
value for generating random big numbers.
---
libavformat/rtmpdh.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Ok.
On Thu, May 28, 2015 at 12:15 PM, Luca Barbato lu_z...@gentoo.org wrote:
From: Michael Niedermayer michae...@gmx.at
Simplifies the code and makes it build on certain compilers
running out of registers on x86.
CC: libav-sta...@libav.org
Reported-By: mudler
---
libavcodec/x86/cavsdsp.c |
On Thu, May 28, 2015 at 9:43 AM, Martin Storsjö mar...@martin.st wrote:
---
libavformat/rtmpdh.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavformat/rtmpdh.c b/libavformat/rtmpdh.c
index 211f4f1..f2deecd 100644
--- a/libavformat/rtmpdh.c
+++ b/libavformat/rtmpdh.c
@@
This was probably broken some time ago. The breakage is now part of the
ABI. For example, we have:
AV_PIX_FMT_XYZ12BE
AV_PIX_FMT_NV16
AV_PIX_FMT_NV20LE
AV_PIX_FMT_NV20LE is wrong. It has the value 113, but as little-endian
format it should be even. This must have been quite obvious
On Thu, May 28, 2015 at 3:00 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 28/05/15 15:58, Vittorio Giovara wrote:
ok'd by Luca
Not the FFSWAP with void * but the original one, just in case.
whoops, misinterpreted it, i'll just push the original then, given
that void* risks of aliasing and
On Tue, May 26, 2015 at 3:10 PM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
On Tue, May 26, 2015 at 2:53 PM, Vittorio Giovara
vittorio.giov...@gmail.com wrote:
On Tue, May 26, 2015 at 2:49 PM, Hendrik Leppkes h.lepp...@gmail.com wrote:
On Mon, May 25, 2015 at 9:46 PM, Vittorio Giovara
On 28/05/15 14:28, Vittorio Giovara wrote:
ok if tested and works
Fate stays happy and some strange gcc gets much happier.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 28/05/15 15:58, Vittorio Giovara wrote:
ok'd by Luca
Not the FFSWAP with void * but the original one, just in case.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
AV_PIX_FMT_NV20LE is wrong. It has the value 113, but as little-endian
format it should be even. This must have been quite obvious when these
formats were added (because of the AV_PIX_FMT_XYZ12BE entry), but
nobody cared or knew about this.
I introduced these pixfmts and iirc I patched
OSX does not know MSG_NOSIGNAL, and provides its own non-standard
mechanism instead. I guess Apple hates standards.
---
Haven't really checked whether this really prevents SIGPIPE (too
bothersome to test), only that the function call succeeds. I don't
think there's a reason to check the success
The old logic required an explicit clearing of the lists first and was
prone to overflow the DXVA2 struct in some circumstances.
---
libavcodec/dxva2_hevc.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/libavcodec/dxva2_hevc.c
On Thu, 28 May 2015 18:09:44 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 28/05/15 16:26, wm4 wrote:
This was probably broken some time ago. The breakage is now part of the
ABI. For example, we have:
Fine by me, this kind of thing is too brittle, do we have a macro
relying on it?
I
---
libavcodec/dxva2_hevc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dxva2_hevc.c b/libavcodec/dxva2_hevc.c
index 9d130d9..a2abb97 100644
--- a/libavcodec/dxva2_hevc.c
+++ b/libavcodec/dxva2_hevc.c
@@ -209,12 +209,12 @@ static void
On 26/05/15 2:29 PM, James Almer wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
No changes from last revision.
doc/APIchanges | 3 +++
libavutil/cpu.c | 3 +++
libavutil/cpu.h | 1 +
libavutil/version.h | 4 ++--
libavutil/x86/cpu.c | 17 ++---
5
On 28/05/15 18:23, wm4 wrote:
Haven't really checked whether this really prevents SIGPIPE (too
bothersome to test), only that the function call succeeds. I don't
think there's a reason to check the success normally, though, so
this patch comes without a check.
Probably shouldn't hurt.
On 28/05/15 18:32, James Almer wrote:
On 26/05/15 2:29 PM, James Almer wrote:
Signed-off-by: James Almer jamr...@gmail.com
---
No changes from last revision.
doc/APIchanges | 3 +++
libavutil/cpu.c | 3 +++
libavutil/cpu.h | 1 +
libavutil/version.h | 4 ++--
On 28/05/15 16:26, wm4 wrote:
This was probably broken some time ago. The breakage is now part of the
ABI. For example, we have:
Fine by me, this kind of thing is too brittle, do we have a macro
relying on it?
lu
___
libav-devel mailing list
On 28/05/15 9:11 AM, Vittorio Giovara wrote:
On Wed, May 27, 2015 at 7:24 PM, James Almer jamr...@gmail.com wrote:
As Luca said, require_pkg_config. If you use require, vpx = 1.4.0 is just
used as a name
to report a failure. It does not check for that version.
I swear I couldn't get it
On Thu, May 28, 2015 at 5:09 PM, James Almer jamr...@gmail.com wrote:
On 28/05/15 9:11 AM, Vittorio Giovara wrote:
On Wed, May 27, 2015 at 7:24 PM, James Almer jamr...@gmail.com wrote:
As Luca said, require_pkg_config. If you use require, vpx = 1.4.0 is
just used as a name
to report a
On Thu, 28 May 2015 18:37:00 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 28/05/15 18:23, wm4 wrote:
Haven't really checked whether this really prevents SIGPIPE (too
bothersome to test), only that the function call succeeds. I don't
think there's a reason to check the success normally,
On 28/05/15 18:56, wm4 wrote:
On Thu, 28 May 2015 18:37:00 +0200
Luca Barbato lu_z...@gentoo.org wrote:
On 28/05/15 18:23, wm4 wrote:
Haven't really checked whether this really prevents SIGPIPE (too
bothersome to test), only that the function call succeeds. I don't
think there's a reason
40 matches
Mail list logo
