On Thu, 20 Jan 2022, J. Dekker wrote:
Based on patch by: Rafal Dabrowa
---
libavcodec/aarch64/Makefile |1 +
libavcodec/aarch64/hevcdsp_init_aarch64.c | 69 +
libavcodec/aarch64/hevcdsp_qpel_neon.S| 2799 +
3 files changed, 2869 insertions(+)
Some
On Tue, 18 Jan 2022, Martin Storsjö wrote:
Clang warns about unused -D parameters when operating on .s
files (or if invoked with "-x assembler") while GCC doesn't.
---
As noobdy else than me essentially maintains gas-preprocessor, I'll
go ahead and push this after a couple days if nob
Hi,
On Sat, 22 Jan 2022, Kacper Michajłow wrote:
LLVM tools print installation path upon execution. If one uses LLVM
tools bundled with Microsoft Visual Studio installation, they would be
incorrectly detected as Microsoft's ones.
Signed-off-by: Kacper Michajłow
---
configure | 6 +++---
1
On Fri, 14 Jan 2022, lance.lmw...@gmail.com wrote:
From: Limin Wang
due to the limitations set in d3a7bdd4ac54349aea9150a234478635d50ebd87,
you weren't able to use main profile with OpenH264 1.8, or high profile
with older versions
Reviewed-by: Martin Storsjö
Signed-off-by: Limin Wang
On Tue, 12 Apr 2022, Andreas Rheinhardt wrote:
Tests using the transcode and stream_remux functions have some common
requirements (namely the file and pipe protocols as well as the framecrc
muxer) and also other commonalities: The create a file and read it
immediately afterwards, so that they
On Tue, 12 Apr 2022, Andreas Rheinhardt wrote:
It also adds the missing depenencies on the file and pipe protocols
and the framecrc muxer.
Signed-off-by: Andreas Rheinhardt
---
tests/fate/subtitles.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/subtitles.mak
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
---
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
On Tue, 12 Apr 2022, Andreas Rheinhardt wrote:
This also adds previously forgotten requirements. E.g. fate-jpg-icc
actually depends on the png decoder, so that it should not be run
when e.g. zlib is disabled, yet it happens, see
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 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
On Thu, 14 Sep 2023, Logan.Lyu wrote:
Hi Martin,
You can try the attached patchset. If that doesn't work, My code branch
address is https://github.com/myais2023/FFmpeg/tree/hevc-aarch64
Thanks for the patches. Functionally, they seem to work, and the issues i
saw in the code are relatively
On Thu, 31 Aug 2023, Andreas Rheinhardt wrote:
It includes various Windows-specific headers when compiling
for Windows and these sometimes cause issues: E.g. winbase.h
defines IGNORE, which clashes with a macro used in the Matroska
muxer (since 884653ee5be03ed38db957c14fad51b300611c8c) and
Hi,
Sorry for not tending to your patches sooner.
Unfortunately, this patchset is impossible to apply - there seems to be
garbled whitespace in the patch which would require me to manually apply
all the changes.
Can you try sending the patches again in a way that doesn't corrupt
On Mon, 28 Aug 2023, Martin Storsjö wrote:
On Mon, 28 Aug 2023, Steinar H. Gunderson wrote:
When the marker writing code was merged from libav to FFmpeg
in dc62016c, it failed to take into account that the meaning of
cluster_pos had changed in bda5b662; in particular, the special
value
Some functions have slightly different indentation styles; try
to match the surrounding code.
libavcodec/aarch64/vc1dsp_neon.S is skipped here, as it intentionally
uses a layered indentation style to visually show how different
unrolled/interleaved phases fit together.
---
Favour left aligned columns over right aligned columns.
In principle either style should be ok, but some of the cases
easily lead to incorrect indentation in the surrounding code (see
a couple of cases fixed up in the preceding patch), and show up in
automatic indentation correction attempts.
---
---
libavcodec/aarch64/h264cmc_neon.S | 4 +-
libavcodec/aarch64/h264idct_neon.S| 2 +-
libavfilter/aarch64/vf_bwdif_neon.S | 6 +-
libavfilter/aarch64/vf_nlmeans_neon.S | 8 +-
libswscale/aarch64/hscale.S | 176 +-
Hi,
Just following up on this - I'm sorry I haven't been able to look at the
proposed patchset myself quite in detail yet.
My prime concern is about the requests to have this merged into the
upcoming 6.1 release; that's way too soon IMO.
These patches do change aspects of how these things
On Sun, 29 Oct 2023, reimar.doeffin...@gmx.de wrote:
From: Reimar Döffinger
Fixes compilation with tcc, which does not have aarch64
inline asm support.
---
libavutil/aarch64/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/aarch64/cpu.c
On Tue, 24 Oct 2023, Sean McGovern wrote:
On Tue, Oct 24, 2023, 08:23 Martin Storsjö wrote:
Skip doing the whole getauxval(AT_HWCAP) if HWCAP_CPUID isn't
defined.
---
libavutil/aarch64/cpu.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libavutil/aarch64/cpu.c b
On Thu, 26 Oct 2023, Logan.Lyu wrote:
And I missed submitting a commit that was earlier than these four commits,
which caused the corrupted whitespace problem. Now I have recreated these
patches.
In addition, I rebased it to ensure that these patches can be successfully
applied on the
On Tue, 24 Oct 2023, Martin Storsjö wrote:
Clang versions before 17 (Xcode versions up to and including 15.0)
had a very annoying bug in its behaviour of the ".arch" directive
in assembly. If the directive only contained a level, such as
".arch armv8.2-a", it did validate t
When linking the main tools, the object files to link are set up
via the variable OBJS-, but for the tools, we've only
used the target's list of dependencies.
In most cases, this has been fine, but it has caused specifying
the libraries to link in a duplicate fashion; the linking command
has
On Thu, 28 Sep 2023, Martin Storsjö wrote:
When linking the main tools, the object files to link are set up
via the variable OBJS-, but for the tools, we've only
used the target's list of dependencies.
In most cases, this has been fine, but it has caused specifying
the libraries to link
On Tue, 26 Sep 2023, Andreas Rheinhardt wrote:
Martin Storsjö:
On Tue, 26 Sep 2023, Anton Khirnov wrote:
Quoting Andreas Rheinhardt (2023-09-26 01:54:30)
It is of no value to the user, because every muxer can always
be flushed with a NULL packet. As its documentation shows
("If no
On Wed, 27 Sep 2023, Rémi Denis-Courmont wrote:
It does not make much sense to me, but GCC somehow optimises the
inline assembler way even when the output are very obviously used.
This reverts commit 09731fbfc3a914ec4f6ffad60aa9062db6a8f6aa.
---
libavutil/riscv/timer.h | 4 ++--
1 file changed,
ase let me
know.
在 2023/9/17 5:46, Martin Storsjö 写道:
On Thu, 14 Sep 2023, Logan.Lyu wrote:
Hi Martin,
You can try the attached patchset. If that doesn't work, My code branch
address is https://github.com/myais2023/FFmpeg/tree/hevc-aarch64
Thanks for the patches. Functionally, they se
On Tue, 26 Sep 2023, Anton Khirnov wrote:
Quoting Andreas Rheinhardt (2023-09-26 01:54:30)
It is of no value to the user, because every muxer can always
be flushed with a NULL packet. As its documentation shows
("If not set, the muxer will not receive a NULL packet in
the write_packet
---
Some patches had inconsistent semicolons when invoking these macros.
By omitting the trailing semicolon in the macro, it requires the
callers to use it consistently.
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
This eases actual development of the assembly functions, by only
allowing extension instructions within the sections that explicitly
enable them, instead of having all extensions enabled everywhere.
---
libavcodec/aarch64/hevcdsp_epel_neon.S | 3 ++-
libavcodec/aarch64/hevcdsp_qpel_neon.S | 2
Including sys/auxv.h should be enough (it pulls in bits/hwcap.h,
which provides the same defines).
---
configure | 2 --
libavutil/aarch64/cpu.c | 3 +--
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/configure b/configure
index bc0c0bd4e4..4ab20c54ec 100755
---
GetStdHandle is unavailable outside of the desktop API subset.
This didn't use to be a problem with earlier WinSDKs, as kbhit also
used to be available only for desktop apps, and this whole section is
wrapped in #if HAVE_KBHIT. With newer WinSDKs, kbhit() is available also
for non-desktop apps,
On Sun, 22 Oct 2023, Logan.Lyu wrote:
Hi, Martin,
Could you please review these patches and let me know if there are any
changes needed.
Did you see the message from Michael on Oct 14th? Your patches have
corrupted whitespace and can't be applied. Earlier you've submitted some
patches as
On Tue, 17 Oct 2023, Martin Storsjö wrote:
Favour left aligned columns over right aligned columns.
In principle either style should be ok, but some of the cases
easily lead to incorrect indentation in the surrounding code (see
a couple of cases fixed up in the preceding patch), and show up
On Tue, 26 Sep 2023, Martin Storsjö wrote:
---
Some patches had inconsistent semicolons when invoking these macros.
By omitting the trailing semicolon in the macro, it requires the
callers to use it consistently.
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 6 +++---
1 file changed, 3
On Wed, 18 Oct 2023, Martin Storsjö wrote:
This eases actual development of the assembly functions, by only
allowing extension instructions within the sections that explicitly
enable them, instead of having all extensions enabled everywhere.
---
libavcodec/aarch64/hevcdsp_epel_neon.S | 3
Clang versions before 17 (Xcode versions up to and including 15.0)
had a very annoying bug in its behaviour of the ".arch" directive
in assembly. If the directive only contained a level, such as
".arch armv8.2-a", it did validate the name of the level, but it
didn't apply the level to what
Skip doing the whole getauxval(AT_HWCAP) if HWCAP_CPUID isn't
defined.
---
libavutil/aarch64/cpu.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c
index bd780e8591..2b50c426bc 100644
--- a/libavutil/aarch64/cpu.c
+++
.
That commit caused ole32 to no longer get detected, which caused
dxva2 to no longer be enabled. This gets fixed by this patch.
Signed-off-by: Martin Storsjö
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index ff6a5c3600..04bb9fe9dd 100755
On Sat, 19 Aug 2023, Gyan Doshi wrote:
ddc1cd5cdd breaks the checks for ole32 and thus prevents detection of DXVA2.
@
https://github.com/FFmpeg/FFmpeg/commit/ddc1cd5cdd2570bf3d6ab807ee0ecfacdf09431d
Thanks for noticing this, and sorry for the breakage. It seems like this
is fixable by
On Sun, 20 Aug 2023, Gyan Doshi wrote:
On 2023-08-20 02:42 am, Martin Storsjö wrote:
ddc1cd5cdd2570bf3d6ab807ee0ecfacdf09431d defined WIN32_LEAN_AND_MEAN
globally, which makes for much fewer transitive includes from
windows.h. With that define, CoTaskMemFree no longer gets
implicitly
The fate-run.sh shell script exports LC_ALL=C before invoking the
test executables; this is probably done for consistency.
When executing Windows binaries with Wine, it normally handles
UTF-8 command line parameters just fine - but with LC_ALL set to
C, it treats them as plain ASCII.
As the
On Mon, 21 Aug 2023, Martin Storsjö wrote:
The fate-run.sh shell script exports LC_ALL=C before invoking the
test executables; this is probably done for consistency.
When executing Windows binaries with Wine, it normally handles
UTF-8 command line parameters just fine - but with LC_ALL set
On Wed, 23 Aug 2023, Jean-Baptiste Kempf wrote:
Hello,
On Mon, 21 Aug 2023, at 03:35, Steven Liu wrote:
Jean-Baptiste Kempf 于2023年8月20日周日 16:29写道：
Hello,
Hi
On Sun, 20 Aug 2023, at 06:10, Steven Liu wrote:
> As the enhanced rtmp Extending NetConnection connect Command section
> said,
On Sat, 5 Aug 2023, L. E. Segovia wrote:
Including winsock2.h or windows.h without WIN32_LEAN_AND_MEAN cause
bzlib.h to parse as nonsense, due to an instance of #define char small
in rpcndr.h.
See:
https://stackoverflow.com/a/27794577
Signed-off-by: L. E. Segovia
---
On Mon, 28 Aug 2023, Steinar H. Gunderson wrote:
When the marker writing code was merged from libav to FFmpeg
in dc62016c, it failed to take into account that the meaning of
cluster_pos had changed in bda5b662; in particular, the special
value for “I'm not currently working on a cluster” had
On Fri, 25 Aug 2023, Steven Liu wrote:
> +list_len = (fourcc_str_len + 1) / 5;
> +// write the fourCcList field name
> +ff_amf_write_field_name(, "fourCcList");
> +
> +// write the fourcc array length
> +ff_amf_write_array_start(, list_len);
> +
> +
On Fri, 25 Aug 2023, Steven Liu wrote:
Martin Storsjö 于2023年8月25日周五 17:38写道：
On Fri, 25 Aug 2023, Steven Liu wrote:
>> > +list_len = (fourcc_str_len + 1) / 5;
>> > +// write the fourCcList field name
>> > +ff_amf_wri
On Fri, 25 Aug 2023, Steven Liu wrote:
Add option named rtmp_enhanced_codec,
it would support hvc1,av01,vp09 now,
the fourcc is using Array of strings.
Signed-off-by: Steven Liu
---
doc/protocols.texi | 6 ++
libavformat/rtmpproto.c | 35 +++
2 files
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
, 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 +++---
1
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,
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:
---
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
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, 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, 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
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
+++
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
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
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
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 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 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
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
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 Fri, 10 Nov 2023, Michael Niedermayer wrote:
If we imaginge every citizen in a country would have to publically demand
in front of the whole citizenship their vote right, explain why they should
have the right and then be voted on by all before receiving the right.
Nobody said that there
On Thu, 9 Nov 2023, Michael Niedermayer wrote:
On Thu, Nov 09, 2023 at 07:53:33PM +0200, Rémi Denis-Courmont wrote:
Le torstaina 9. marraskuuta 2023, 19.41.53 EET Michael Niedermayer a écrit :
[...]
If you think some people should be added, as far as I am concerned, you are of
course welcome
On Thu, 9 Nov 2023, Rémi Denis-Courmont wrote:
With a value of zero, the function is a glorified memory copy.
---
tests/checkasm/sbrdsp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/sbrdsp.c b/tests/checkasm/sbrdsp.c
index 2fb14d5bf8..5cc3b33215 100644
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
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
---
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
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 |
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
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
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, 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 */
+
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
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 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
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
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
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 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
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 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, 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
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, 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, 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, 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
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
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
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 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
701 - 800 of 1377 matches
Mail list logo
