Re: [libav-devel] [GASPP PATCH] Comment out "it" instructions for armasm

On Thu, 3 Oct 2019, Martin Storsjö wrote: On Thu, 3 Oct 2019, Janne Grunau wrote: On 2019-10-02 11:53:28 +0300, Martin Storsjö wrote: Armasm implicitly adds it instructions as needed. In VS 2019 16.3, there's a bug [1] in armasm making it fail to parse these it instructions (but it can still

Re: [libav-devel] [GASPP PATCH] Comment out "it" instructions for armasm

On Thu, 3 Oct 2019, Martin Storsjö wrote: On Thu, 3 Oct 2019, Janne Grunau wrote: On 2019-10-02 11:53:28 +0300, Martin Storsjö wrote: Armasm implicitly adds it instructions as needed. In VS 2019 16.3, there's a bug [1] in armasm making it fail to parse these it instructions (but it can still

Re: [libav-devel] [GASPP PATCH] Comment out "it" instructions for armasm

On Thu, 3 Oct 2019, Janne Grunau wrote: On 2019-10-02 11:53:28 +0300, Martin Storsjö wrote: Armasm implicitly adds it instructions as needed. In VS 2019 16.3, there's a bug [1] in armasm making it fail to parse these it instructions (but it can still add them implicitly just fine). I'm

[libav-devel] [PATCH] aarch64: Add assembly support for -fsanitize=hwaddress tagged globals.

it is needed when compiling with -fsanitize=hwaddress. Signed-off-by: Peter Collingbourne Signed-off-by: Martin Storsjö --- libavutil/aarch64/asm.S | 8 1 file changed, 8 insertions(+) diff --git a/libavutil/aarch64/asm.S b/libavutil/aarch64/asm.S index bf5c1b7ee1..81d723b9b3 100644

Re: [libav-devel] [PATCH] Add a fd protocol

On Thu, 25 Apr 2019, Luca Barbato wrote: --- Sometimes you receive a seekable fd from the outside. libavformat/file.c | 32 libavformat/protocols.c | 1 + 2 files changed, 33 insertions(+) diff --git a/libavformat/file.c b/libavformat/file.c index

[libav-devel] [PATCH] arm: vp9lpf: Fix a typo in a comment about the register layout

--- libavcodec/aarch64/vp9lpf_neon.S | 2 +- libavcodec/arm/vp9lpf_neon.S | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/aarch64/vp9lpf_neon.S b/libavcodec/aarch64/vp9lpf_neon.S index e9c497096b..f68b54a2ee 100644 --- a/libavcodec/aarch64/vp9lpf_neon.S +++

Re: [libav-devel] [PATCH 1/2] configure: Try adding -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 for mingw as well

On Tue, 16 Apr 2019, Martin Storsjö wrote: On Tue, 16 Apr 2019, Diego Biurrun wrote: On Sun, Apr 14, 2019 at 09:33:40PM +0300, Martin Storsjö wrote: On Sun, 14 Apr 2019, Diego Biurrun wrote: > On Sat, Apr 13, 2019 at 12:58:40AM +0300, Martin Storsjö wrote: > > On Fri, 12 Apr 2

Re: [libav-devel] [PATCH 1/2] configure: Try adding -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 for mingw as well

On Tue, 16 Apr 2019, Diego Biurrun wrote: On Sun, Apr 14, 2019 at 09:33:40PM +0300, Martin Storsjö wrote: On Sun, 14 Apr 2019, Diego Biurrun wrote: > On Sat, Apr 13, 2019 at 12:58:40AM +0300, Martin Storsjö wrote: > > On Fri, 12 Apr 2019, Luca Barbato wrote: > > > On 11/04/

Re: [libav-devel] [PATCH] rtsp: add pkt_size option

On Mon, 15 Apr 2019, Tristan Matthews wrote: On Thu, Apr 11, 2019 at 1:41 AM Martin Storsjö wrote: On Thu, 11 Apr 2019, Tristan Matthews wrote: This allows users to specify an upper limit on the size of outgoing packets when publishing via RTSP. --- libavformat/rtsp.c | 5

Re: [libav-devel] [PATCH 1/2] configure: Try adding -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 for mingw as well

On Sun, 14 Apr 2019, Diego Biurrun wrote: On Sat, Apr 13, 2019 at 12:58:40AM +0300, Martin Storsjö wrote: On Fri, 12 Apr 2019, Luca Barbato wrote: > On 11/04/2019 15:35, Martin Storsjö wrote: > > On Wed, 10 Apr 2019, Luca Barbato wrote: > > > On 10/04/2019 10:48, Ma

Re: [libav-devel] [PATCH 1/2] configure: Try adding -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 for mingw as well

On Fri, 12 Apr 2019, Luca Barbato wrote: On 11/04/2019 15:35, Martin Storsjö wrote: On Wed, 10 Apr 2019, Luca Barbato wrote: On 10/04/2019 10:48, Martin Storsjö wrote: Mingw headers have got header inline implementations of localtime_r and gmtime_r, but only visible if certain posix thread

Re: [libav-devel] [PATCH 1/2] configure: Try adding -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 for mingw as well

On Wed, 10 Apr 2019, Luca Barbato wrote: On 10/04/2019 10:48, Martin Storsjö wrote: Mingw headers have got header inline implementations of localtime_r and gmtime_r, but only visible if certain posix thread safe functions have been requested. This is a preparatory step for improving

Re: [libav-devel] [PATCH] rtsp: add pkt_size option

On Thu, 11 Apr 2019, Tristan Matthews wrote: This allows users to specify an upper limit on the size of outgoing packets when publishing via RTSP. --- libavformat/rtsp.c | 5 - libavformat/rtsp.h | 1 + 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/libavformat/rtsp.c

[libav-devel] [PATCH 2/2] time_internal: Prefix fallback versions of gmtime_r/localtime_r with ff_

Use a macro to redirect calling code from the official name to the ff_ prefixed one. Detecting these functions in configure can be tricky (on mingw, they are conditionally available depending on posix feature defines). If configure didn't detect them, but they still are visible at compile time

[libav-devel] [PATCH 1/2] configure: Try adding -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 for mingw as well

Mingw headers have got header inline implementations of localtime_r and gmtime_r, but only visible if certain posix thread safe functions have been requested. This is a preparatory step for improving the detection of those functions. --- An alternative fix is also provided in a different patch

[libav-devel] [PATCH 1/2] time_internal: Do not attempt to override *time_r() macros

From: Michael Niedermayer This allegedly fixed build on odd mingw setups, and generally seems like a safe thing to do (in case configure failed to detect them while they still are available in headers). --- libavutil/time_internal.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[libav-devel] [PATCH 2/2] configure: Include time.h when checking for gmtime_r and localtime_r

These functions are available in time.h (conditional on posix thread safe functions) on mingw. Previously, these functions weren't detected by configure, and libavutil/time_internal.h provided replacements, even if time.h actually contained definitions of them. Previously, these mingw inline

[libav-devel] [PATCH] arm: Implement a NEON version of 422 h264_h_loop_filter_chroma

Previously, the 420 version was used even for 422. This fixes occasional checkasm failures. --- libavcodec/arm/h264dsp_init_arm.c | 8 +++- libavcodec/arm/h264dsp_neon.S | 19 +++ 2 files changed, 26 insertions(+), 1 deletion(-) diff --git

Re: [libav-devel] [PATCH 2/2] checkasm/h264: test 4:2:2 chroma loop filter functions

On Wed, 27 Feb 2019, Janne Grunau wrote: --- tests/checkasm/h264dsp.c | 44 1 file changed, 26 insertions(+), 18 deletions(-) LGTM // Martin ___ libav-devel mailing list libav-devel@libav.org

Re: [libav-devel] [PATCH 1/2] h264/arm64: implement missing 4:2:2 chroma loop filter neon functions

On Wed, 27 Feb 2019, Janne Grunau wrote: --- libavcodec/aarch64/h264dsp_init_aarch64.c | 18 ++-- libavcodec/aarch64/h264dsp_neon.S | 36 +++ 2 files changed, 46 insertions(+), 8 deletions(-) LGTM // Martin ___

Re: [libav-devel] [PATCHv3] avio: Do not flush the buffer if a constant packet size is requested

On Fri, 22 Feb 2019, Luca Barbato wrote: --- Now with a separate option to be explicit on what is the behaviour wanted. libavformat/aviobuf.c | 9 +++-- libavformat/udp.c | 8 libavformat/url.h | 1 + 3 files changed, 16 insertions(+), 2 deletions(-) diff --git

Re: [libav-devel] [PATCH 19/19] aarch64: vp8: Optimize vp8_idct_add_neon for aarch64

On Fri, 1 Feb 2019, Martin Storsjö wrote: The previous version was a pretty exact translation of the arm version. This version does do some unnecessary arithemetic (it does more operations on vectors that are only half filled; it does 4 uaddw and 4 sqxtun instead of 2 of each), but it reduces

[libav-devel] [PATCH 04/19] aarch64: vp8: Fix assembling with armasm64

--- libavcodec/aarch64/vp8dsp_neon.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/aarch64/vp8dsp_neon.S b/libavcodec/aarch64/vp8dsp_neon.S index f371ea7..14a9d11 100644 --- a/libavcodec/aarch64/vp8dsp_neon.S +++ b/libavcodec/aarch64/vp8dsp_neon.S @@ -28,7 +28,7

[libav-devel] [PATCH 19/19] aarch64: vp8: Optimize vp8_idct_add_neon for aarch64

The previous version was a pretty exact translation of the arm version. This version does do some unnecessary arithemetic (it does more operations on vectors that are only half filled; it does 4 uaddw and 4 sqxtun instead of 2 of each), but it reduces the overhead of packing data together (which

[libav-devel] [PATCH 01/19] libavcodec: vp8 neon optimizations for aarch64

From: Magnus Röös Partial port of the ARM Neon for aarch64. Benchmarks from fate: benchmarking with Linux Perf Monitoring API nop: 58.6 checkasm: using random seed 1760970128 NEON: - vp8dsp.idct [OK] - vp8dsp.mc [OK] - vp8dsp.loopfilter [OK] checkasm: all 21 tests passed

[libav-devel] [PATCH 03/19] aarch64: vp8: Fix assembling with clang

This also partially fixes assembling with MS armasm64 (via gas-preprocessor). --- libavcodec/aarch64/vp8dsp_neon.S | 124 +++ 1 file changed, 62 insertions(+), 62 deletions(-) diff --git a/libavcodec/aarch64/vp8dsp_neon.S b/libavcodec/aarch64/vp8dsp_neon.S

[libav-devel] [PATCH 18/19] aarch64: vp8: Skip saturating in shrn in ff_vp8_idct_add_neon

The original arm version didn't do saturation here. This probably doesn't make any difference for performance, but reduces the differences. --- libavcodec/aarch64/vp8dsp_neon.S | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/aarch64/vp8dsp_neon.S

[libav-devel] [PATCH 12/19] aarch64: vp8: Port vp8_luma_dc_wht and vp8_idct_dc_add4uv from arm version

Cortex A53A72A73 vp8_luma_dc_wht_c:115.7 75.7 90.7 vp8_luma_dc_wht_neon: 60.7 41.2 45.7 vp8_idct_dc_add4uv_c: 376.1 262.9 282.5 vp8_idct_dc_add4uv_neon: 52.0 29.0 37.0 --- libavcodec/aarch64/vp8dsp_init_aarch64.c | 3 +

[libav-devel] [PATCH 11/19] aarch64: vp8: Fix a typo in a comment

--- libavcodec/aarch64/vp8dsp_neon.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/aarch64/vp8dsp_neon.S b/libavcodec/aarch64/vp8dsp_neon.S index c19ab0d..2b5b049 100644 --- a/libavcodec/aarch64/vp8dsp_neon.S +++ b/libavcodec/aarch64/vp8dsp_neon.S @@ -743,7 +743,7

[libav-devel] [PATCH 13/19] aarch64: vp8: Port missing epel8 functions from arm version

Cortex A53 A72 A73 vp8_put_epel8_h4_c: 2594.8 1159.6 1374.8 vp8_put_epel8_h4_neon: 506.4 244.2 314.0 vp8_put_epel8_h6_c: 3445.8 1677.1 1811.3 vp8_put_epel8_h6_neon: 634.4 371.7 433.0 vp8_put_epel8_v4_c: 2614.0 1174.8 1378.0

[libav-devel] [PATCH 15/19] aarch64: vp8: Port bilin functions from arm version

Cortex A53 A72 A73 vp8_put_bilin4_h_c:303.8 102.2 161.8 vp8_put_bilin4_h_neon: 100.040.941.2 vp8_put_bilin4_hv_c: 322.8 201.0 305.9 vp8_put_bilin4_hv_neon:156.872.677.0 vp8_put_bilin4_v_c:304.7 101.7 166.5

[libav-devel] [PATCH 10/19] aarch64: vp8: Reorder the function pointer inits to match the arm original

--- libavcodec/aarch64/vp8dsp_init_aarch64.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/aarch64/vp8dsp_init_aarch64.c b/libavcodec/aarch64/vp8dsp_init_aarch64.c index 3fb254a..da54efd 100644 --- a/libavcodec/aarch64/vp8dsp_init_aarch64.c +++

[libav-devel] [PATCH 05/19] aarch64: vp8: Fix linking for iOS

The mach-o relocations don't allow a negative offset to a symbol; use the third movrel parameter to handle this issue transparently. --- libavcodec/aarch64/vp8dsp_neon.S | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/libavcodec/aarch64/vp8dsp_neon.S

[libav-devel] [PATCH 02/19] aarch64: vp8: Fix the include guard

From: Carl Eugen Hoyos --- libavcodec/aarch64/vp8dsp.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/aarch64/vp8dsp.h b/libavcodec/aarch64/vp8dsp.h index 8a0c8fb..40d0cae 100644 --- a/libavcodec/aarch64/vp8dsp.h +++ b/libavcodec/aarch64/vp8dsp.h @@ -16,8

[libav-devel] [PATCH 09/19] aarch64: vp8: Move the vp8dsp makefile entries to the right places

Even if NEON would be disabled, the init functions should be built as they are called as long as ARCH_AARCH64 is set. These functions are part of a generic DSP subsytem, not tied directly to one decoder. (They should be built if the vp7 decoder is enabled, even if the vp8 decoder is disabled.)

[libav-devel] [PATCH 06/19] aarch64: vp8: Use the proper aarch64 form for conditional branches

The previous form also does seem to assemble on current tools, but I think it might fail on some older aarch64 tools. --- libavcodec/aarch64/vp8dsp_neon.S | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/libavcodec/aarch64/vp8dsp_neon.S

[libav-devel] [PATCH 08/19] aarch64: vp8: Remove superfluous includes

--- libavcodec/aarch64/vp8dsp_init_aarch64.c | 4 1 file changed, 4 deletions(-) diff --git a/libavcodec/aarch64/vp8dsp_init_aarch64.c b/libavcodec/aarch64/vp8dsp_init_aarch64.c index f93bcfa..3fb254a 100644 --- a/libavcodec/aarch64/vp8dsp_init_aarch64.c +++

[libav-devel] [PATCH 16/19] arm: vp8: Optimize put_epel16_h6v6 with vp8_epel8_v6_y2

This makes it similar to put_epel16_v6, and gives a 10-25% speedup of this function. Before: Cortex A7 A8 A9 A53 A72 vp8_put_epel16_h6v6_neon:3058.0 2218.5 2459.8 2183.0 1572.2 After: vp8_put_epel16_h6v6_neon:2670.8 1934.2 2244.4 1729.4

[libav-devel] [PATCH 17/19] aarch64: vp8: Optimize put_epel16_h6v6 with vp8_epel8_v6_y2

This makes it similar to put_epel16_v6, and gives a large speedup on Cortex A53, a minor speedup on A72 and a very minor slowdown on A73. Before: Cortex A53 A72 A73 vp8_put_epel16_h6v6_neon: 2211.4 1586.5 1431.7 After: vp8_put_epel16_h6v6_neon: 1736.9 1522.0 1448.1

[libav-devel] [PATCH 14/19] aarch64: vp8: Port epel4 functions from arm version

Cortex A53A72A73 vp8_put_epel4_h4_c:631.4 291.7 367.8 vp8_put_epel4_h4_neon: 241.0 131.0 155.7 vp8_put_epel4_h4v4_c: 967.5 529.3 667.7 vp8_put_epel4_h4v4_neon: 429.3 241.8 279.7 vp8_put_epel4_h4v6_c: 1374.7 657.5 864.5

[libav-devel] [PATCH 07/19] vp8dsp: Move the aarch64 dsp init call into alphabetical order

--- libavcodec/vp8dsp.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/vp8dsp.c b/libavcodec/vp8dsp.c index 3c8d1c8..ac9a6af 100644 --- a/libavcodec/vp8dsp.c +++ b/libavcodec/vp8dsp.c @@ -679,14 +679,14 @@ av_cold void ff_vp78dsp_init(VP8DSPContext *dsp)

Re: [libav-devel] [PATCH] avio: Do not flush the buffer if a constant packet size is requested

On Thu, 31 Jan 2019, Luca Barbato wrote: --- libavformat/aviobuf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c index 98e35f776c..3c882d6bdb 100644 --- a/libavformat/aviobuf.c +++ b/libavformat/aviobuf.c @@ -244,7 +244,8 @@

Re: [libav-devel] [PATCH 1/1] h264/x86: sign extend int stride in deblock functions

On Sun, 27 Jan 2019, Janne Grunau wrote: Fixes checkasm errors after adding the h264 deblock tests. --- libavcodec/x86/h264_deblock.asm | 8 libavcodec/x86/h264_deblock_10bit.asm | 9 + 2 files changed, 17 insertions(+) Ok with me. Yes, changing the prototypes to use

Re: [libav-devel] [PATCH 2/4] checkasm/h264: add loop filter tests

On Tue, 1 Jan 2019, Janne Grunau wrote: --- tests/checkasm/h264dsp.c | 124 +++ 1 file changed, 124 insertions(+) This newly added test seems to fail on macOS. I haven't debugged through it properly yet, but disabling the use of checkasm_checked_call seems

Re: [libav-devel] [PATCH] libopenh264dec: Use a newer decoding entry point function

On Sat, 26 Jan 2019, Janne Grunau wrote: On 2019-01-25 10:39:13 +0200, Martin Storsjö wrote: The "new" entry point actually has existed since OpenH264 1.4 in 2015, but with B-frames, this entry point is essential for actually getting the right frames returned and reordered.

[libav-devel] [PATCH] libopenh264dec: Use a newer decoding entry point function

The "new" entry point actually has existed since OpenH264 1.4 in 2015, but with B-frames, this entry point is essential for actually getting the right frames returned and reordered. The name of this function, DecodeFrameNoDelay, is rather backwards considering that it doesn't return the latest

[libav-devel] [PATCH] arm: Create proper .rdata sections for COFF

As .rodata isn't one of the default created sections for COFF, it was created as a read-write data section. By using the default .rdata section name for COFF, it automatically becomes a read-only data section. The existing ".section .rodata" works as intended for ELF though. This is based on an

[libav-devel] [PATCH] arm: Mark .rodata section as read only in COFF object file

From: Tom Tan .rodata directive from GAS assembly produces .rodata as read/write for COFF object file by default (object file format for Windows), but read only for ELF. This change marks it as read only explicitly for COFF. Signed-off-by: Martin Storsjö --- libavutil/aarch64/asm.S | 2

Re: [libav-devel] Using Co-authored-by instead of Signed-off-by

On Wed, 9 Jan 2019, Luca Barbato wrote: Since the start of the project we used Signed-off-by to signal that a patch had been edited. I'd like to point out that you might have had this interpretation of it and used it in this way, but it hasn't been a written project wide rule that this is

Re: [libav-devel] [PATCH 4/4] h264/aarch64: add intra loop filter neon asm

On Tue, 1 Jan 2019, Janne Grunau wrote: Add my neon asm from x264 relicensed under the LGPL 2.1 or later. Ported (x264 uses nv12 chroma) and optimized. Cycle count for checkasm --bench on a Snapdragon 820e: h264_h_loop_filter_luma_intra_8bpp_c: 60.0 h264_h_loop_filter_luma_intra_8bpp_neon:

Re: [libav-devel] [PATCH 3/4] h264/aarch64: optimize neon loop filter

On Tue, 1 Jan 2019, Janne Grunau wrote: Exit as soon as possible if no filtering will be done. Improves the checkasm --bench cycle count on a Snapdragon 820e: h264_h_loop_filter_luma_8bpp_c: 72.4 -> 72.5 h264_h_loop_filter_luma_8bpp_neon: 97.1 -> 56.3 h264_v_loop_filter_luma_8bpp_c:

Re: [libav-devel] [PATCH 2/4] checkasm/h264: add loop filter tests

On Tue, 1 Jan 2019, Janne Grunau wrote: --- tests/checkasm/h264dsp.c | 124 +++ 1 file changed, 124 insertions(+) Looks ok to me // Martin ___ libav-devel mailing list libav-devel@libav.org

Re: [libav-devel] [PATCH 1/4] h264/aarch64: sign extend int stride in loop filter asm

On Tue, 1 Jan 2019, Janne Grunau wrote: --- libavcodec/aarch64/h264dsp_neon.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/aarch64/h264dsp_neon.S b/libavcodec/aarch64/h264dsp_neon.S index 9b4610a4d4..60ffa24500 100644 --- a/libavcodec/aarch64/h264dsp_neon.S +++

Re: [libav-devel] [PATCH 1/2] libavutil: Undeprecate the AVFrame reordered_opaque field

On Fri, 26 Oct 2018, Luca Barbato wrote: On 25/10/2018 14:45, Martin Storsjö wrote: This was marked as deprecated (but only in the doxygen, not with an actual deprecation attribute) in 81c623fae05 in 2011, but was undeprecated in ad1ee5fa7. --- libavutil/frame.h | 1 - libavutil/version.h

Re: [libav-devel] [PATCH 2/2] libx264: Pass the reordered_opaque field through the encoder

On Thu, 25 Oct 2018, Martin Storsjö wrote: libx264 does have a field for opaque data to pass along with frames through the encoder, but it is a pointer, while the libavcodec reordered_opaque field is an int64_t. Therefore, allocate an array within the libx264 wrapper, where reordered_opaque

[libav-devel] [PATCH 2/2] libx264: Pass the reordered_opaque field through the encoder

libx264 does have a field for opaque data to pass along with frames through the encoder, but it is a pointer, while the libavcodec reordered_opaque field is an int64_t. Therefore, allocate an array within the libx264 wrapper, where reordered_opaque values in flight are stored, and pass a pointer

[libav-devel] [PATCH 1/2] libavutil: Undeprecate the AVFrame reordered_opaque field

This was marked as deprecated (but only in the doxygen, not with an actual deprecation attribute) in 81c623fae05 in 2011, but was undeprecated in ad1ee5fa7. --- libavutil/frame.h | 1 - libavutil/version.h | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/libavutil/frame.h

[libav-devel] [PATCH] arm: Emit .thumb_func directives

Prior to Xcode 9.3, the clang built-in assembler didn't support altmacro, and gas-preprocessor was used for assembling for arm/darwin. For thumb functions, gas-preprocessor took care of adding the .thumb_func directives, but when now being able to assemble without gas-preprocessor, we need to add

Re: [libav-devel] [PATCH] libfdk-aac: Don't use defined() in a #define

On Wed, 12 Sep 2018, Martin Storsjö wrote: MSVC expands the preprocessor directives differently, making the version check fail in the previous form. --- I'm pretty sure I've seen a better description of this issue somewhere, I don't remember off-hand right now where that was. But I think

[libav-devel] [PATCH] libfdk-aac: Don't use defined() in a #define

MSVC expands the preprocessor directives differently, making the version check fail in the previous form. --- I'm pretty sure I've seen a better description of this issue somewhere, I don't remember off-hand right now where that was. But I think the gist of it was that the previous form was

[libav-devel] [PATCH 2/3] libfdk-aacdec: Allow setting the new dynamic range control effect setting

This is a new setting in FDK v2. --- libavcodec/libfdk-aacdec.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/libavcodec/libfdk-aacdec.c b/libavcodec/libfdk-aacdec.c index c3d3b70fc9..ca70a49ad4 100644 --- a/libavcodec/libfdk-aacdec.c +++ b/libavcodec/libfdk-aacdec.c @@

[libav-devel] [PATCH 1/3] libfdk-aac: Consistently use a proper version check macro for detecting features

The previous version checks checked explicitly for the version where the version define was added to the installed headers, making an "#ifdef AACDECODER_LIB_VL0" enough. Now that we have a need for more diverse version checks than this, convert all checks to such checks. ---

[libav-devel] [PATCH 3/3] libfdk-aacenc: Allow enabling the ELDv2 profile

This is a new feature in FDK v2. --- libavcodec/libfdk-aacenc.c | 27 ++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c index 92ad1762ae..f71a276403 100644 --- a/libavcodec/libfdk-aacenc.c +++

[libav-devel] [PATCH] libfdk-aacenc: Fix building with libfdk-aac v2

When flushing the encoder, we now need to provide non-null buffer parameters for everything, even if they are unused. The encoderDelay parameter has been replaced by two, nDelay and nDelayCore. --- libfdk-aac v2 also has a bunch of other new, yet untested features, like support for xHE-AAC. ---

Re: [libav-devel] [PATCH] libopenh264dec: Export the decoded profile and level in AVCodecContext

On Fri, 31 Aug 2018, Vittorio Giovara wrote: On Fri, Aug 31, 2018 at 11:25 AM, Martin Storsjö wrote: --- libavcodec/libopenh264dec.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavcodec/libopenh264dec.c b/libavcodec/libopenh264dec.c index 5990a72ff9..7e9e66743a 100644

Re: [libav-devel] [PATCH 1/2] network: Add RFC 8305 style "Happy Eyeballs"/"Fast Fallback" helper function

On Wed, 22 Aug 2018, Luca Barbato wrote: On 21/08/2018 09:29, Martin Storsjö wrote: For cases with dual stack (IPv4 + IPv6) connectivity, but where one stack potentially is less reliable, strive to trying to connect over both protocols in parallel, using whichever address connected first

[libav-devel] [PATCH] libopenh264dec: Export the decoded profile and level in AVCodecContext

--- libavcodec/libopenh264dec.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavcodec/libopenh264dec.c b/libavcodec/libopenh264dec.c index 5990a72ff9..7e9e66743a 100644 --- a/libavcodec/libopenh264dec.c +++ b/libavcodec/libopenh264dec.c @@ -95,6 +95,7 @@ static int

[libav-devel] [PATCH 1/2] network: Add RFC 8305 style "Happy Eyeballs"/"Fast Fallback" helper function

For cases with dual stack (IPv4 + IPv6) connectivity, but where one stack potentially is less reliable, strive to trying to connect over both protocols in parallel, using whichever address connected first. In cases with a hostname resolving to multiple IPv4 and IPv6 addresses, the current

[libav-devel] [PATCH 2/2] tcp: Use ff_connect_parallel for RFC 8305 style connecting

--- libavformat/tcp.c | 41 +++-- 1 file changed, 15 insertions(+), 26 deletions(-) diff --git a/libavformat/tcp.c b/libavformat/tcp.c index 1498c26fbe..7044d44f06 100644 --- a/libavformat/tcp.c +++ b/libavformat/tcp.c @@ -108,30 +108,28 @@ static int

[libav-devel] [PATCH] tls_openssl: Fix checks for SSL_ERROR_WANT_WRITE in nonblocking operation

This was a typo in 0671eb2346c, spotted by Chris Carroux. --- libavformat/tls_openssl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c index f0b325ae98..4a2fcfd771 100644 --- a/libavformat/tls_openssl.c +++

[libav-devel] [PATCH 2/3] network: Use ff_neterrno instead of AVERROR(errno) for poll errors

From: Simon Thelen This makes sure to pick up the actual error codes on windows. --- libavformat/network.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/network.c b/libavformat/network.c index 86d79553f7..1e02668ecf 100644 --- a/libavformat/network.c +++

[libav-devel] [PATCH 1/3] http: pass return code from http_open_cnx_internal() on its failure

From: Andrey Utkin Previously, AVERROR(EIO) was returned on failure of http_open_cnx_internal(). Now the value is passed to upper level, thus it is possible to distinguish ECONNREFUSED, ETIMEDOUT, ENETUNREACH etc. --- libavformat/http.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[libav-devel] [PATCH 3/3] network: Check for EINTR in ff_poll_interrupt

--- libavformat/network.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/libavformat/network.c b/libavformat/network.c index 1e02668ecf..24fcf20539 100644 --- a/libavformat/network.c +++ b/libavformat/network.c @@ -131,14 +131,17 @@ static int

[libav-devel] [PATCH] libopenh264: Add support for decoding of b-frames

The current git master version of libopenh264 supports decoding of b-frames. --- libavcodec/libopenh264dec.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/libavcodec/libopenh264dec.c b/libavcodec/libopenh264dec.c index cdb8d527cf..5990a72ff9 100644 ---

[libav-devel] [PATCH] avconv: make sure packets put into the muxing FIFO are refcounted

From: wm4 Some callers (like do_subtitle_out(), or do_streamcopy()) call this with an AVPacket that is not refcounted. This can cause undefined behavior. Calling av_packet_move_ref() does not make a packet refcounted if it isn't yet. (And it can't be made to, because it always succeeds, and

[libav-devel] [PATCH] libfdk-aac: Use enum names instead of literal numbers for the output format

--- libavcodec/libfdk-aacenc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c index 26dfb6dc0b..c340a1e3e0 100644 --- a/libavcodec/libfdk-aacenc.c +++ b/libavcodec/libfdk-aacenc.c @@ -227,7 +227,8 @@ static av_cold int

Re: [libav-devel] [PATCH] configure: fix inline asm checks

On Fri, 8 Jun 2018, Diego Biurrun wrote: On Thu, Jun 07, 2018 at 11:05:26PM -0300, James Almer wrote: On 6/7/2018 6:01 PM, Diego Biurrun wrote: > On Thu, Jun 07, 2018 at 03:03:21PM +0300, Martin Storsjö wrote: >> Commit 8c893aa3cd5 removed quotes that were required to detect >

[libav-devel] [PATCH] configure: fix inline asm checks

From: John Cox Commit 8c893aa3cd5 removed quotes that were required to detect inline asm: check_insn armv5te qadd r0, r0, r0 .../test.c:1:34: error: expected string literal in 'asm' void foo(void){ __asm__ volatile(qadd r0, r0, r0); } The correct code is: void foo(void){ __asm__

Re: [libav-devel] [PATCH] random_seed: use bcrypt instead of the old wincrypt API

On Tue, 17 Apr 2018, Diego Biurrun wrote: On Mon, Apr 16, 2018 at 05:50:04PM +0300, Martin Storsjö wrote: From: Steve Lhomme <rob...@ycbcr.xyz> Remove the wincrypt API calls since we don't support XP anymore and bcrypt is available since Vista, even on Windows Store builds. -

[libav-devel] [PATCH] random_seed: use bcrypt instead of the old wincrypt API

From: Steve Lhomme Remove the wincrypt API calls since we don't support XP anymore and bcrypt is available since Vista, even on Windows Store builds. --- Now with avutil_extralibs sorted alphabetically, and James' extended configure check included. --- configure

[libav-devel] [PATCH] random_seed: use bcrypt instead of the old wincrypt API

From: Steve Lhomme Remove the wincrypt API calls since we don't support XP anymore and bcrypt is available since Vista, even on Windows Store builds. --- configure | 6 +++--- libavutil/random_seed.c | 19 ++- 2 files changed, 13 insertions(+),

Re: [libav-devel] [PATCH] [v2] use bcrypt instead of the old wincrypt API

On Sun, 15 Apr 2018, Martin Storsjö wrote: On Tue, 3 Apr 2018, Steve Lhomme wrote: When targeting Windows Vista and above The wincrypt API is deprecated and not allowed for Windows Store apps. Wincrypt can be removed after XP support is dropped. --- configure | 4

Re: [libav-devel] [PATCH] [v2] use bcrypt instead of the old wincrypt API

On Tue, 3 Apr 2018, Steve Lhomme wrote: When targeting Windows Vista and above The wincrypt API is deprecated and not allowed for Windows Store apps. Wincrypt can be removed after XP support is dropped. --- configure | 4 +++- libavutil/random_seed.c | 17 +++-- 2

[libav-devel] [PATCH] x86: Don't declare a non-static function as inline

This fixes building with clang in msvc mode, which does support gcc style inline assembly. --- libavcodec/x86/xvididct_sse2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/x86/xvididct_sse2.c b/libavcodec/x86/xvididct_sse2.c index f318e95..0de59a5 100644 ---

Re: [libav-devel] [PATCH] x86: Don't declare a non-static function as inline

On Sat, 14 Apr 2018, Diego Biurrun wrote: On Sat, Apr 14, 2018 at 01:38:30PM +0300, Martin Storsjö wrote: Make the actual implementation static inline, but add a non-static non-inline frontend for it. This fixes building with clang in msvc mode, which does support gcc style inline assembly

[libav-devel] [PATCH] x86: Don't declare a non-static function as inline

Make the actual implementation static inline, but add a non-static non-inline frontend for it. This fixes building with clang in msvc mode, which does support gcc style inline assembly. --- libavcodec/x86/xvididct_sse2.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff

Re: [libav-devel] [PATCH 2/2] Drop Windows XP support remnants

On Thu, 5 Apr 2018, Diego Biurrun wrote: --- libavcodec/dxva2_h264.c | 6 +- libavcodec/dxva2_hevc.c | 6 +- libavcodec/dxva2_mpeg2.c | 7 ++- libavcodec/dxva2_vc1.c| 6 +- libavutil/hwcontext_d3d11va.c | 9 + libavutil/hwcontext_dxva2.c | 4 6

Re: [libav-devel] [PATCH 1/2] w32pthreads: always use Vista+ API, drop XP support

On Thu, 5 Apr 2018, Diego Biurrun wrote: From: wm4 This removes the XP compatibility code, and switches entirely to SRW locks, which are available starting at Windows Vista. This removes CRITICAL_SECTION use, which allows us to add PTHREAD_MUTEX_INITIALIZER, which will

Re: [libav-devel] [PATCH] use bcrypt instead of the old wincrypt API

On Fri, 30 Mar 2018, James Almer wrote: On 3/30/2018 3:13 PM, Martin Storsjö wrote: On Fri, 30 Mar 2018, James Almer wrote: On 3/30/2018 10:57 AM, Martin Storsjö wrote: On Fri, 30 Mar 2018, Diego Biurrun wrote: On Fri, Mar 30, 2018 at 10:43:27AM -0300, James Almer wrote: On 3/30/2018 10

Re: [libav-devel] [PATCH] use bcrypt instead of the old wincrypt API

On Fri, 30 Mar 2018, Diego Biurrun wrote: On Fri, Mar 30, 2018 at 04:58:29PM +0300, Martin Storsjö wrote: On Fri, 30 Mar 2018, Diego Biurrun wrote: > On Fri, Mar 30, 2018 at 12:38:05PM +0200, Steve Lhomme wrote: > > Le 30/03/2018 à 10:46, Diego Biurrun a écrit : > > > On

Re: [libav-devel] [PATCH] use bcrypt instead of the old wincrypt API

On Fri, 30 Mar 2018, James Almer wrote: On 3/30/2018 10:57 AM, Martin Storsjö wrote: On Fri, 30 Mar 2018, Diego Biurrun wrote: On Fri, Mar 30, 2018 at 10:43:27AM -0300, James Almer wrote: On 3/30/2018 10:38 AM, Diego Biurrun wrote: > On Fri, Mar 30, 2018 at 12:38:05PM +0200, Steve Lho

Re: [libav-devel] [PATCH] use bcrypt instead of the old wincrypt API

On Fri, 30 Mar 2018, Diego Biurrun wrote: On Fri, Mar 30, 2018 at 12:38:05PM +0200, Steve Lhomme wrote: Le 30/03/2018 à 10:46, Diego Biurrun a écrit : > On Fri, Mar 30, 2018 at 09:36:05AM +0200, Steve Lhomme wrote: > > --- a/configure > > +++ b/configure > > @@ -4581,6 +4582,7 @@ check_lib

Re: [libav-devel] [PATCH] use bcrypt instead of the old wincrypt API

On Fri, 30 Mar 2018, Diego Biurrun wrote: On Fri, Mar 30, 2018 at 10:43:27AM -0300, James Almer wrote: On 3/30/2018 10:38 AM, Diego Biurrun wrote: > On Fri, Mar 30, 2018 at 12:38:05PM +0200, Steve Lhomme wrote: >> Le 30/03/2018 à 10:46, Diego Biurrun a écrit : >>> On Fri, Mar 30, 2018 at

[libav-devel] [PATCH 2/2] arm: Produce .const_data instead of .section .rodata for Mach-O

This is the same combination of .section directives as used in aarch64/asm.S. Since Xcode 9.3, the bundled clang supports altmacro and doesn't require using gas-preprocessor any longer. --- libavutil/arm/asm.S | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git

[libav-devel] [PATCH 1/2] arm: vc1dsp: Add commas between macro arguments

When targeting darwin, clang requires commas between arguments, while the no-comma form is allowed for other targets. Since Xcode 9.3, the bundled clang supports altmacro and doesn't require using gas-preprocessor any longer. --- libavcodec/arm/vc1dsp_neon.S | 94

[libav-devel] [PATCH] configure: Don't assume a 16 byte aligned stack on BSDs on i386

With GCC, request it to maintain 16 byte alignment, and the existing entry points already align it via attribute_align_arg. With clang, do the same as for mingw; disable the aligned stack and let the assembly functions that require it do the alignment instead. --- configure | 22

[libav-devel] [PATCH] configure: Don't assume an aligned stack on clang on windows

If we'd enable a 16 byte aligned stack, clang/llvm would also assume that alignment everywhere and produce code that strictly requires it. That would require adding realignment (via attribute_align_arg) on every single public library function or enable -mstackrealign (which does the same on every

Re: [libav-devel] [PATCH] configure: Restore original endianness test

On Thu, 8 Mar 2018, Diego Biurrun wrote: Previously the bit pattern for the endianness test was declared as a global, instead of a local, variable. This ensures that the pattern appears unchanged in the object file and is not optimized out. --- configure | 4 +++- 1 file changed, 3

[libav-devel] [PATCH 1/2] Revert "configure: Stop using dlltool to create an import library"

This reverts commit 67c72f08a4707c18a67a4734660e3a23cc9488b6. While the linker produced import libraries might work with MSVC in simple test cases, they don't if e.g. linking to multiple GNU ld produced import libraries at the same time. The ones produced by dlltool work fine though. This issue

[libav-devel] [PATCH 2/2] configure: Pass the right machine types to dlltool for arm and arm64 mingw

These are supported by llvm-dlltool. --- configure | 4 1 file changed, 4 insertions(+) diff --git a/configure b/configure index 06fb839a18..1c35f9dc64 100755 --- a/configure +++ b/configure @@ -3894,6 +3894,10 @@ case $target_os in LIBTARGET=i386 if enabled x86_64; then

  1   2   3   4   5   6   7   8   9   10   >