On Fri, 17 Jun 2022, Nil Admirari wrote:
1. getenv() is replaced with getenv_utf8() across libavformat.
2. New versions of AviSynth+ are now called with UTF-8 filenames.
3. Old versions of AviSynth are still using ANSI strings,
but MAX_PATH limit on filename is removed.
---
libavformat/avisynt
On Fri, 17 Jun 2022, Nil Admirari wrote:
wchartoutf8() converts strings returned by WinAPI into UTF-8,
which is FFmpeg's preffered encoding.
Some external dependencies, such as AviSynth, are still
not Unicode-enabled. utf8toansi() converts UTF-8 strings
into ANSI in two steps: UTF-8 -> wchar_t
On Thu, 16 Jun 2022, Thilo Borgmann wrote:
Hi,
movdqa in ff_yuv2yuvX_sse3() expects a 16-byte alignment according to its
documentation causing segfaults in fate-checkasm-sw_scale.
LGTM, thanks!
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel
On Mon, 13 Jun 2022, softworkz wrote:
From: softworkz
Signed-off-by: softworkz
---
fftools/fopen_utf8: support long paths on Windows for fftools
After Nil's patchset, this is probably the final missing bit.
Signed-off-by: softworkz softwo...@hotmail.com
Published-As:
https://gith
On Mon, 13 Jun 2022, Nil Admirari wrote:
wchartoutf8() converts strings returned by WinAPI into UTF-8,
which is FFmpeg's preffered encoding.
Some external dependencies, such as AviSynth, are still
not Unicode-enabled. utf8toansi() converts UTF-8 strings
into ANSI in two steps: UTF-8 -> wchar_t
On Sun, 12 Jun 2022, Martin Storsjö wrote:
On Sun, 12 Jun 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Andreas Rheinhardt
Sent: Sunday, June 12, 2022 7:28 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Andreas Rheinhardt
Subject: [FFmpeg-devel] [PATCH] all
On Sun, 12 Jun 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Andreas Rheinhardt
Sent: Sunday, June 12, 2022 7:28 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Andreas Rheinhardt
Subject: [FFmpeg-devel] [PATCH] all: Replace if (ARCH_FOO) checks by
#if ARCH_FOO
This
On Sat, 11 Jun 2022, Christopher Degawa wrote:
On Thu, Jun 9, 2022 at 6:22 PM softworkz wrote:
From: softworkz
Signed-off-by: softworkz
---
avformat/os_support: use windows stat structs with 64bit time_t
Signed-off-by: softworkz softwo...@hotmail.com
Ping on this patch, this f
On Thu, 9 Jun 2022, nil-admir...@mailo.com wrote:
Right, I wasn't aware that the -A version would return a
guaranteed-ansi-compatible version of the filename. If that's really the
case, this patch would indeed be a minor step backwards.
Two options are available:
1. fopen() is replaced with av
On Thu, 9 Jun 2022, nil-admir...@mailo.com wrote:
This error isn't reproducible in git master - it's triggered by your
yet-unmerged patches (that include wchar_filename.h in w32dlfcn.h).
Ok. It can be fixed by either
- defining NO_DSHOW_STRSAFE in libavcodec/mf_utils.h
- or by migrating os_sup
On Thu, 9 Jun 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Martin
Storsjö
Sent: Thursday, June 9, 2022 9:09 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH v12 1/4] libavutil/wchar_filename.h: Add
whcartoutf8
On Thu, 9 Jun 2022, nil-admir...@mailo.com wrote:
This looks fine to me, and the discussion seems to have converged, so I'll
go ahead and push this.
Build is now failing:
https://github.com/yt-dlp/FFmpeg-Builds/runs/6819319105?check_suite_focus=true.
In file included from
/opt/ct-ng/i686-w6
On Thu, 9 Jun 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Martin
Storsjö
Sent: Thursday, June 9, 2022 12:10 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH v12 1/4] libavutil/wchar_filename.h: Add
whcartoutf8
On Sun, 5 Jun 2022, Nil Admirari wrote:
These functions are going to be used in libavformat/avisynth.c
and fftools/cmdutils.c to remove MAX_PATH limit.
---
libavutil/wchar_filename.h | 51 ++
1 file changed, 51 insertions(+)
This patchset looks good to me too
On Thu, 26 May 2022, ffmpegagent wrote:
This patchset adds support for long file and directory paths on Windows. The
implementation follows the same logic that .NET is using internally, with
the only exception that it doesn't expand short path components in 8.3
format. .NET does this as the same
On Mon, 30 May 2022, Anton Khirnov wrote:
Quoting Michael Niedermayer (2022-05-27 20:52:09)
log2() remains, this can either be replaced by a integer implementation or the
table
hardcoded if needed
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1enc.c| 25 ++
On Wed, 25 May 2022, Martin Storsjö wrote:
This fixes handling of cases like ".ifc \foo, bar // comment", where
there was trailing whitespace after the condition (before the comment
which already was stripped out at this point).
---
Will apply after a couple days.
This fixes the &qu
On Thu, 26 May 2022, Martin Storsjö wrote:
The dlopen wrapper contains code to make loading libraries safer,
to avoid loading a potentially malicious DLL with the same name.
Signed-off-by: Martin Storsjö
---
v2: Use dlsym too, for consistency.
---
libavcodec/mfenc.c | 7 ---
1 file changed
On Fri, 27 May 2022, Swinney, Jonathan wrote:
Thanks! If I don't see it merged in a few days, I will submit it again
with the final touch up.
Pushed now, thanks!
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mai
On Thu, 26 May 2022, ffmpegagent wrote:
This patchset adds support for long file and directory paths on Windows. The
implementation follows the same logic that .NET is using internally, with
the only exception that it doesn't expand short path components in 8.3
format. .NET does this as the same
On Thu, 26 May 2022, Swinney, Jonathan wrote:
I have fixed the test to work correctly on x86 and addressed the other small
issues. Thanks for reviewing!
Thanks - this iteration seems fine to me! (I can touch up minor details
like changing "add #-32" into "sub #32" before pushing.) I'll push
On Thu, 26 May 2022, J. Dekker wrote:
+
+// gather random access data from src into contiguous memory
+ldr w8, [x3, w8, UXTW] // src[filterPos[idx +
0]][0..3]
Current asm code has lowercase uxtw, would prefer to keep it consistent.
+ldr
The dlopen wrapper contains code to make loading libraries safer,
to avoid loading a potentially malicious DLL with the same name.
Signed-off-by: Martin Storsjö
---
v2: Use dlsym too, for consistency.
---
libavcodec/mfenc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff
On Wed, 25 May 2022, Timo Rothenpieler wrote:
On 25/05/2022 23:35, Martin Storsjö wrote:
The dlopen wrapper contains code to make loading libraries safer,
to avoid loading a potentially malicious DLL with the same name.
Signed-off-by: Martin Storsjö
---
libavcodec/mfenc.c | 5 +++--
1
The dlopen wrapper contains code to make loading libraries safer,
to avoid loading a potentially malicious DLL with the same name.
Signed-off-by: Martin Storsjö
---
libavcodec/mfenc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mfenc.c b/libavcodec
On Wed, 25 May 2022, Timo Rothenpieler wrote:
On 25/05/2022 22:51, Martin Storsjö wrote:
On Wed, 25 May 2022, Trystan Mata wrote:
Changes since the v5:
- Library handle and function pointer are back in MFContext.
- MFTEnumEx has been move to it too.
- dlopen and dlclose are preferred
On Wed, 25 May 2022, Trystan Mata wrote:
Changes since the v5:
- Library handle and function pointer are back in MFContext.
- MFTEnumEx has been move to it too.
- dlopen and dlclose are preferred.
This will avoid multiple look up on one context. And each context will
have his own library h
On Wed, 25 May 2022, nil-admir...@mailo.com wrote:
+ struct win32_stat
+ {
+ _dev_t st_dev; /* ID of device containing file */
+ _ino_t st_ino; /* inode number */
+ unsigned short st_mode; /* protection */
+ short st_nlink; /* number of hard links */
+ short st_uid; /* user ID of owner */
+ shor
On Wed, 25 May 2022, J. Dekker wrote:
Signed-off-by: J. Dekker
---
libavcodec/aarch64/hevcdsp_sao_neon.S | 30 +++
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S
b/libavcodec/aarch64/hevcdsp_sao_neon.S
index efd8112a
On Tue, 24 May 2022, J. Dekker wrote:
libavcodec/aarch64/Makefile | 1 +
libavcodec/aarch64/hevcdsp_init_aarch64.c | 43 +-
libavcodec/aarch64/hevcdsp_qpel_neon.S| 520 ++
3 files changed, 563 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch6
This fixes handling of cases like ".ifc \foo, bar // comment", where
there was trailing whitespace after the condition (before the comment
which already was stripped out at this point).
---
Will apply after a couple days.
This fixes the "lavc/aarch64: add hevc horizontal qpel/uni/bi" patch
when bu
On Wed, 25 May 2022, Martin Storsjö wrote:
On Wed, 25 May 2022, Swinney, Jonathan wrote:
This patch adds code to support specializations of the hscale function and
adds
a specialization for filterSize == 4.
ff_hscale8to15_4_neon is a complete rewrite. Since the main bottleneck here
is
On Wed, 25 May 2022, Swinney, Jonathan wrote:
This patch adds code to support specializations of the hscale function and adds
a specialization for filterSize == 4.
ff_hscale8to15_4_neon is a complete rewrite. Since the main bottleneck here is
loading the data from src, this data is loaded a who
On Wed, 25 May 2022, Swinney, Jonathan wrote:
This patch adds code to support specializations of the hscale function and adds
a specialization for filterSize == 4.
ff_hscale8to15_4_neon is a complete rewrite. Since the main bottleneck here is
loading the data from src, this data is loaded a who
On Wed, 25 May 2022, Swinney, Jonathan wrote:
Signed-off-by: Jonathan Swinney
---
tests/checkasm/sw_scale.c | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/tests/checkasm/sw_scale.c b/tests/checkasm/sw_scale.c
index 3c0a083b42..6c223c4
On Wed, 25 May 2022, Swinney, Jonathan wrote:
This is a resubmission of changes to the hscale function for aarch64. I
added a test as a separate patch so that it would be easier to get
consistent before and after performance data. After Martin already
submitted the improvement to the final sec
This codepath is enabled by default on arm, if the linux perf API
is available, unless disabled with --disable-linux-perf.
---
tests/checkasm/checkasm.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index a86db140e3..7f
On Wed, 25 May 2022, J. Dekker wrote:
On 24 May 2022, at 22:27, Martin Storsjö wrote:
On Tue, 17 May 2022, J. Dekker wrote:
The HEVC decoder can call these functions with smaller widths than the
functions themselves are designed to operate on so we should only check
the relevant output
On Tue, 24 May 2022, ffmpegagent wrote:
This patchset adds support for long file and directory paths on Windows. The
implementation follows the same logic that .NET is using internally, with
the only exception that it doesn't expand short path components in 8.3
format. .NET does this as the same
On Tue, 24 May 2022, Soft Works wrote:
-Original Message-
From: Martin Storsjö
Sent: Tuesday, May 24, 2022 10:59 PM
To: softworkz
Cc: ffmpeg-devel@ffmpeg.org; Soft Works ; Hendrik
Leppkes
Subject: Re: [PATCH v6 2/2] avformat/os_support: Support long file names
on Windows
On Tue, 24 May 2022, softworkz wrote:
From: softworkz
Signed-off-by: softworkz
---
libavformat/os_support.h | 87 +---
1 file changed, 63 insertions(+), 24 deletions(-)
diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index 5e6b32d2dc..179b9
On Tue, 24 May 2022, softworkz wrote:
From: softworkz
Signed-off-by: softworkz
---
libavutil/file_open.c | 2 +-
libavutil/wchar_filename.h | 180 +
2 files changed, 181 insertions(+), 1 deletion(-)
This looks ok to me now, thanks!
// Martin
__
On Tue, 24 May 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Martin
Storsjö
Sent: Tuesday, May 24, 2022 10:22 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8
On Tue, 24 May 2022
On Tue, 17 May 2022, J. Dekker wrote:
The HEVC decoder can call these functions with smaller widths than the
functions themselves are designed to operate on so we should only check
the relevant output
Signed-off-by: J. Dekker
---
tests/checkasm/hevc_sao.c | 51 -
On Tue, 24 May 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Martin
Storsjö
Sent: Tuesday, May 24, 2022 11:29 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8
On Mon, 23 May 2022
On Tue, 24 May 2022, Soft Works wrote:
-Original Message-
From: Martin Storsjö
Sent: Tuesday, May 24, 2022 1:26 PM
To: Soft Works
Cc: FFmpeg development discussions and patches ;
Hendrik Leppkes
Subject: RE: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support
long file names
On Tue, 24 May 2022, Soft Works wrote:
-Original Message-
From: Martin Storsjö
Sent: Tuesday, May 24, 2022 12:26 PM
To: Soft Works
Cc: FFmpeg development discussions and patches ;
Hendrik Leppkes
Subject: RE: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support
long file names
On Tue, 24 May 2022, Soft Works wrote:
-Original Message-
From: Martin Storsjö
Sent: Tuesday, May 24, 2022 11:23 AM
To: FFmpeg development discussions and patches
Cc: softworkz ; Hendrik Leppkes
Subject: Re: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support
long file names
On Mon, 23 May 2022, Soft Works wrote:
Great. I rebased and resubmitted both patchsets. The primary long-path
patchset didn't need any change.
Considerations for the latter were:
- Should the file wchar_filename.h be renamed as it is now containing
the path prefixing code?
I guess we could
On Tue, 24 May 2022, softworkz wrote:
From: softworkz
Signed-off-by: softworkz
---
libavformat/os_support.h | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/libavformat/os_support.h b/libavformat/os_support.h
index 5e6b32d2dc..d4c07803a5 100644
--- a/libavf
On Tue, 24 May 2022, softworkz wrote:
From: softworkz
Signed-off-by: softworkz
---
libavutil/file_open.c | 2 +-
libavutil/wchar_filename.h | 166 +
2 files changed, 167 insertions(+), 1 deletion(-)
diff --git a/libavutil/file_open.c b/libavutil/file_
On Mon, 23 May 2022, ffmpegagent wrote:
Unify file access operations by replacing usages of direct calls to posix
fopen()
v2: Remove changes to fftools for now
v3: Add some additional replacements
v4: Fix and improve commit messages
v5: Add patch to remap ff_open in libavfilter for MSVC on Wind
, avcodec will be linked directly against MFPlat.DLL.
- MediaFoundation functions are now called like MFTEnumEx, like Martin
Storsjö suggested in his review of the v3.
I forgot to mention it on earlier versions, this patch addresses
https://trac.ffmpeg.org/ticket/9788.
diff --git a/libavcodec
On Mon, 23 May 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Martin
Storsjö
Sent: Monday, May 23, 2022 12:58 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8
On Mon, 23 May 2022
On Mon, 23 May 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Martin
Storsjö
Sent: Monday, May 23, 2022 12:53 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8
On Sat, 21 May 2022
On Sat, 21 May 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Martin
Storsjö
Sent: Friday, May 20, 2022 11:13 PM
To: ffmpeg-devel@ffmpeg.org
Subject: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8
Provide a header based inline reimplementation
---
libavfilter/af_arnndn.c | 2 +-
libavfilter/opencl.c | 2 +-
libavfilter/vf_curves.c | 2 +-
libavfilter/vf_dnn_classify.c | 2 +-
libavfilter/vf_dnn_detect.c | 2 +-
libavfilter/vf_fieldhint.c| 2 +-
libavfilter/vf_lut3d.c| 4 ++--
libavfilter/vf_nnedi.c
Since every DLL can use an individual CRT on Windows, having
an exported function that opens a FILE* won't work if that
FILE* is going to be used from a different DLL (or from user
application code).
Internally within the libraries, the issue can be worked around
by duplicating the function in all
Provide a header based inline reimplementation of it.
Using av_fopen_utf8 doesn't work outside of the libraries when built
with MSVC as shared libraries (in the default configuration, where
each DLL gets a separate statically linked CRT).
---
fftools/ffmpeg_opt.c | 3 +-
fftools/fopen_utf8.h | 7
On Fri, 20 May 2022, Trystan Mata wrote:
From 2bdef1bdb93efa40b7d3fe21270f9f23465bee90 Mon Sep 17 00:00:00 2001
From: Trystan Mata
Date: Fri, 20 May 2022 14:26:49 +0200
Subject: [PATCH] avcodec/mfenc: Dynamically load MFPlat.DLL
Allow builds of FFmpeg with MediaFoundation to work under N editi
On Fri, 20 May 2022, Derek Buitenhuis wrote:
On 5/20/2022 5:37 PM, Soft Works wrote:
But if Matt's patch would be agreeable, then that would surely be
the best outcome.
I can rebase and resubmit his patch if you would find it agreeable.
Ah - that was not clear to me.
If Ubuntu LTS does inde
On Mon, 9 May 2022, softworkz wrote:
From: softworkz
Signed-off-by: softworkz
---
use av_fopen_utf8() instead of plain fopen()
Unify file access operations by replacing usages of direct calls to
posix fopen()
v2: Remove changes to fftools for now
Published-As:
https://github.c
On Mon, 9 May 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Martin Storsjö
Sent: Monday, May 9, 2022 11:42 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object
sharing issue on Windows
On Mon
On Mon, 9 May 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Martin Storsjö
Sent: Sunday, May 8, 2022 10:12 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object
sharing issue on Windows
On
On Mon, 9 May 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Martin Storsjö
Sent: Sunday, May 8, 2022 10:02 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object
sharing issue on Windows
On Sat
On Sat, 7 May 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Andreas Rheinhardt
Sent: Saturday, May 7, 2022 6:32 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object
sharing issue on Windows
Soft Works:
-O
On Sat, 7 May 2022, softworkz wrote:
From: softworkz
Signed-off-by: softworkz
---
fftools/cmdutils.c | 6 +++---
fftools/ffmpeg.c | 4 ++--
fftools/opt_common.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
Just for clarity (for someone looking at this individual mail thread o
On Sat, 7 May 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Martin Storsjö
Sent: Wednesday, April 20, 2022 2:48 PM
To: ffmpeg-devel@ffmpeg.org
Subject: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object sharing
issue on Windows
Hi,
I just became aware
On Sat, 7 May 2022, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of nil-
admir...@mailo.com
Sent: Friday, May 6, 2022 6:08 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v11 1/6]
libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and
utf8toa
On Fri, 6 May 2022, Andreas Rheinhardt wrote:
This avoids having to rebuild big files every time FFMPEG_VERSION
changes (which it does with every commit).
Signed-off-by: Andreas Rheinhardt
---
Makefile | 4 ++-
ffbuild/common.mak | 2 --
libavcodec/Makefile|
On Mon, 2 May 2022, David Fletcher wrote:
On 2/5/2022, "Nicolas George" wrote:
Is there a trac ticket? If not, please fill one: we would not want to
keep that bug.
Regards,
--
Nicolas George
Hi Nicolas,
I'll prepare a test case to demonstrate the issue and fill in a ticket.
As far as I c
On Thu, 28 Apr 2022, J. Dekker wrote:
bench on AWS Graviton:
hevc_sao_edge_8x8_8_c: 516.0
hevc_sao_edge_8x8_8_neon: 81.0
Signed-off-by: J. Dekker
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 3 ++
libavcodec/aarch64/hevcdsp_sao_neon.S | 51 +++
2 files changed, 54 in
On Wed, 20 Apr 2022, Martin Storsjö wrote:
On Fri, 18 Feb 2022, Andreas Schneider wrote:
Signed-off-by: Andreas Schneider
---
libavcodec/libopenh264dec.c | 2 +-
libavcodec/libopenh264enc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libopenh264dec.c b
On Mon, 25 Apr 2022, Andre Kempe wrote:
This patch fixes a wrong type of BTI landing pad when branching to
functions instantiated via the fft*_neon macro.
Although the previously employed paciasp instruction serves as a landing
pad, for the ways that this function is invoked it is the wrong typ
On Mon, 25 Apr 2022, Hendrik Leppkes wrote:
On Mon, Apr 25, 2022 at 1:12 PM Soft Works wrote:
From my point of view:
ffmpeg is already working pretty well in handling long file paths (also with
Unicode characters) when pre-fixing paths with \\?\, and this is working
on all Windows versions wi
On Thu, 21 Apr 2022, Swinney, Jonathan wrote:
Thanks for making this improvement. I will rebase my patches on your change. I
also measured the performance on AWS Graviton 2 and 3. I added the numbers to
your table.
Before: Cortex A53 A72 A73 Graviton 2 Graviton
Hi,
I just became aware of the av_fopen_utf8 function - which was introduced
to fix path name translations on Windows - actually has a notable design
flaw.
Background:
On Windows, a process can contain more than one C runtime (CRT); the
system comes with two shared ones (UCRT and msvcrt.dl
On Fri, 18 Feb 2022, Andreas Schneider wrote:
Signed-off-by: Andreas Schneider
---
libavcodec/libopenh264dec.c | 2 +-
libavcodec/libopenh264enc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libopenh264dec.c b/libavcodec/libopenh264dec.c
index 7f5e85402a..97d
On Fri, 15 Apr 2022, Nil Admirari wrote:
---
fftools/fftools.manifest | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fftools/fftools.manifest b/fftools/fftools.manifest
index 30b7d8fe..d1ac1e4e 100644
--- a/fftools/fftools.manifest
+++ b/fftools/fftools.manifest
@@ -3,8 +3
On Fri, 15 Apr 2022, Nil Admirari wrote:
---
fftools/Makefile | 5 +
fftools/fftools.manifest | 10 ++
fftools/manifest.rc | 3 +++
3 files changed, 18 insertions(+)
create mode 100644 fftools/fftools.manifest
create mode 100644 fftools/manifest.rc
I think the change he
On Fri, 15 Apr 2022, Nil Admirari wrote:
---
fftools/cmdutils.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 5d7cdc3e..a66dbb22 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@
On Fri, 15 Apr 2022, Nil Admirari wrote:
---
compat/w32dlfcn.h | 78 ++-
1 file changed, 64 insertions(+), 14 deletions(-)
diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 52a94efa..0f41f50b 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.
On Fri, 15 Apr 2022, Nil Admirari wrote:
---
libavformat/avisynth.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/avisynth.c b/libavformat/avisynth.c
index 8ba2bdea..f7bea8c3 100644
--- a/libavformat/avisynth.c
+++ b/libavformat/avisynth.c
@@ -34,6 +
On Fri, 15 Apr 2022, Nil Admirari wrote:
These functions are going to be used in libavformat/avisynth.c
and fftools/cmdutils.c remove MAX_PATH limit.
---
libavutil/wchar_filename.h | 51 ++
1 file changed, 51 insertions(+)
I looked through this patchset now,
, around 3-8% for the smaller filter sizes.
Inspired by a patch by Jonathan Swinney .
Signed-off-by: Martin Storsjö
---
I'll go ahead and apply this patch within a few days if there's no
opposition, as it should be a fairly uncontroversial change.
---
libswscale/aarch64/hscale.S | 14 +++
On Sun, 17 Apr 2022, Martin Storsjö wrote:
On Fri, 15 Apr 2022, Swinney, Jonathan wrote:
This patch adds specializations for hscale for filterSize == 4 and 8 and
converts the existing implementation for the X8 version. For the old code,
now
used for the X8 version, it improves the efficiency
On Fri, 15 Apr 2022, Swinney, Jonathan wrote:
This commit adds new code paths for vscale when filterSize is 2, 4, or 8. By
using specialized code with unrolling to match the filterSize we can improve
performance.
| (seconds) | c6g | | |
| | - | - | - |
|
On Tue, 19 Apr 2022, Marton Balint wrote:
On Sat, 16 Apr 2022, Martin Storsjö wrote:
On Fri, 15 Apr 2022, Tristan Matthews wrote:
This avoids having to do one pass to calculate the full length to
allocate
followed by a second pass to actually append values.
---
libavformat/librtmp.c
On Mon, 18 Apr 2022, Timo Rothenpieler wrote:
ffmpeg | branch: master | Timo Rothenpieler | Thu Apr
7 20:11:24 2022 +0200| [d5687236aba6fd31dd4369c290df9a5b1192e43e] | committer: Timo
Rothenpieler
doc: install css files along html docs
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=comm
On Fri, 15 Apr 2022, Swinney, Jonathan wrote:
This commit adds new code paths for vscale when filterSize is 2, 4, or 8. By
using specialized code with unrolling to match the filterSize we can improve
performance.
| (seconds) | c6g | | |
| | - | - | - |
|
On Fri, 15 Apr 2022, Swinney, Jonathan wrote:
This patch adds specializations for hscale for filterSize == 4 and 8 and
converts the existing implementation for the X8 version. For the old code, now
used for the X8 version, it improves the efficiency of the final summations by
reducing 11 instruc
On Fri, 15 Apr 2022, Martin Storsjö wrote:
On Thu, 14 Apr 2022, Swinney, Jonathan wrote:
Thanks Martin for the review. I made some updates according to the
suggestions you made.
I added a checkasm function, but I'm new to the test framework, so it may
need some work still.
Thank
On Fri, 15 Apr 2022, Tristan Matthews wrote:
This avoids having to do one pass to calculate the full length to allocate
followed by a second pass to actually append values.
---
libavformat/librtmp.c | 124 +++---
1 file changed, 33 insertions(+), 91 deletions(-
On Thu, 14 Apr 2022, Swinney, Jonathan wrote:
- ff_pix_abs16_neon
- ff_pix_abs16_xy2_neon
In direct micro benchmarks of these ff functions verses their C implementations,
these functions performed as follows on AWS Graviton 2:
ff_pix_abs16_neon:
c: benchmark ran 10 iterations in 0.955383
On Thu, 14 Apr 2022, Swinney, Jonathan wrote:
Thanks Martin for the review. I made some updates according to the
suggestions you made.
I added a checkasm function, but I'm new to the test framework, so it
may need some work still.
Thanks for putting in the effort to make a test - that adds
On Thu, 14 Apr 2022, Mark Gaiser wrote:
On Thu, Apr 14, 2022 at 10:25 AM Martin Storsjö wrote:
On Wed, 13 Apr 2022, Mark Gaiser wrote:
> On Wed, Apr 13, 2022 at 5:21 PM Mark Gaiser wrote:
>
>> PATH_MAX is posix. Some compilers (MSVC) don't define this
>> thus
On Wed, 13 Apr 2022, Mark Gaiser wrote:
On Wed, Apr 13, 2022 at 5:21 PM Mark Gaiser wrote:
PATH_MAX is posix. Some compilers (MSVC) don't define this
thus failing to compile the ipfsgateway file.
Defining it fixes the compile.
Signed-off-by: Mark Gaiser
---
libavformat/ipfsgateway.c | 6 ++
On Wed, 13 Apr 2022, Marton Balint wrote:
On Wed, 13 Apr 2022, Martin Storsjö wrote:
On Mon, 11 Apr 2022, Tristan Matthews wrote:
This avoids having to do one pass to calculate the full length to
allocate
followed by a second pass to actually append values.
---
libavformat/librtmp.c
On Mon, 11 Apr 2022, Tristan Matthews wrote:
This avoids having to do one pass to calculate the full length to allocate
followed by a second pass to actually append values.
---
libavformat/librtmp.c | 123 +++---
1 file changed, 32 insertions(+), 91 deletions(-
On Tue, 12 Apr 2022, Andreas Rheinhardt wrote:
Simplifies the checks.
Signed-off-by: Andreas Rheinhardt
---
tests/fate/oma.mak | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/tests/fate/oma.mak b/tests/fate/oma.mak
index a088feff21..7e2020b7d0 100644
--- a/tests/f
701 - 800 of 1507 matches
Mail list logo
