On 12.05.2022 04:22, Srihari Sridhar wrote:
Hi,
I was building ffmpeg through windows. While I was able to successfully
able to build for smaller number of threads, for larger number of threads I
faced an issue
The commands I used were
bash ./configure --arch=x86 --target-os=mingw32
On 22/05/2022 14:19, Haihao Xiang wrote:
libmfx 1.28 was released 3 years ago, it is easy to get a greater
version than 1.28. We may remove lots of compile-time checks if adding
the requirement for the minimal version in the configure script.
---
configure | 7 +-
On 23/06/2022 11:10, Zhao Zhili wrote:
From: Zhao Zhili
Regression from 45e3b6a68. cuvidParseVideoData report unknown
error with AV1CodecConfigurationRecord.
---
libavcodec/cuviddec.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavcodec/cuviddec.c
On 02.07.2022 10:54, Michael Niedermayer wrote:
seems to get this stuck:
./ffmpeg -f lavfi -i
'amovie=fate-suite/wavpack/num_channels/eva_2.22_6.1_16bit-partial.wv,asplit=3[out1][a][b];
[a]showwaves=s=340x240,pad=iw:ih*2[waves];
[b]showspectrum=s=340x240[spectrum]; [waves][spectrum]
This avoids an extra copy of potentially quite big video frames.
Instead of copying the entire frames data into a rawvideo packet it
packs the frame into a wrapped avframe packet and passes it through
as-is.
Unfortunately, wrapped avframes are set up to be video frames, so the
audio frames
---
libavdevice/lavfi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index 1b282a70cb..246f7dff3b 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -287,6 +287,7 @@ av_cold static int lavfi_read_header(AVFormatContext *avctx)
This avoids an extra copy of potentially quite big video frames.
Instead of copying the entire frames data into a rawvideo packet it
packs the frame into a wrapped avframe packet and passes it through
as-is.
Unfortunately, wrapped avframes are set up to be video frames, so the
audio frames
Desktop duplication outputs those
---
libavutil/hwcontext_d3d11va.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 904d14bbc8..1f3d1b7755 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@
---
fftools/ffmpeg.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e7384f052a..6ec28f3019 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -766,6 +766,7 @@ static double adjust_frame_pts_to_encoder_tb(OutputFile
*of,
On 07.07.2022 22:47, Michael Niedermayer wrote:
On Tue, Jun 07, 2022 at 01:35:00PM +0200, Michael Niedermayer wrote:
Hi all
As was discussed previously the 5.1 release should be in june/july
That means in the next weeks probably!
If you know of any regressions, security issues or other major
On 08/07/2022 12:17, Timo Rothenpieler wrote:
The lavfi changes, more specifically wrapped_avframe, still rely on
sizeof(AVFrame) being used outside lavu. We really need to stop
spreading its use and find a way to change this behavior.
I have tried like two different solutions and both were
The lavfi changes, more specifically wrapped_avframe, still rely on
sizeof(AVFrame) being used outside lavu. We really need to stop
spreading its use and find a way to change this behavior.
I have tried like two different solutions and both were rejected, so
it's not going to be me.
On 30.06.2022 02:01, mohamed Elhadidy wrote:
GSoC'22 GPU accelerated video filters
Added CUDA chromakeyfilter
libavfilter/vf_chromakey_cuda.cu:the CUDA kernel for the filter
libavfilter/vf_chromakey_cuda.c: the C side that calls the kernel and gets user
input
libavfilter/allfilters.c: added the
On 03.07.2022 15:19, Nicolas George wrote:
Timo Rothenpieler (12022-06-29):
The lavfi avdevice as it is right now can't output "special frames"
like hardware frames.
This patch makes the lavfi avdevice output wrapped AVFrames instead
of copying the actual data, greatly s
On 02.07.2022 19:26, Nicolas George wrote:
It is already possible.
Yeah, I noticed that shortly after.
Never before thought to run ffmpeg.c without any inputs, but as long as
you stick to -filter_complex instead of plain -filter, it works great.
But this device is not meant for ffmpeg.c
On 09.07.2022 01:46, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Timo Rothenpieler
Sent: Saturday, July 9, 2022 12:54 AM
To: ffmpeg-devel@ffmpeg.org
Cc: Timo Rothenpieler
Subject: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter, lavfi.c
wrapped_avframe
On 09.07.2022 02:01, Soft Works wrote:
I can submit the missing bit of differences as a patch. I thought
it was no longer needed. The requirements have also changed over
MSDK versions. The 8bit file mapping that I've shown recently exists
in fact because an earlier MSDK version was requesting
This avoids an extra copy of potentially quite big video frames.
Instead of copying the entire frames data into a rawvideo packet it
packs the frame into a wrapped avframe packet and passes it through
as-is.
Unfortunately, wrapped avframes are set up to be video frames, so the
audio frames
---
libavutil/hwcontext_d3d11va.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 904d14bbc8..e5afcb2a9d 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -397,6 +397,7 @@
---
libavutil/hwcontext_d3d11va.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index e5afcb2a9d..6355bd1e29 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -166,6
Since a bunch small stuff has changed since the last time I sent these
one by one, here's the whole collection again.
I intend to push the whole lot within the next 48h, so they all make it
in before 5.1 gets branched.
Timo Rothenpieler (8):
fftools/ffmpeg: make debug_ts print raw filter output
At least QSV relies on those being set correctly when deriving a hwctx.
---
libavutil/hwcontext_d3d11va.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 6355bd1e29..d492489b79 100644
--- a/libavutil/hwcontext_d3d11va.c
---
fftools/ffmpeg.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e7384f052a..a69364c0d4 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -765,7 +765,9 @@ static double adjust_frame_pts_to_encoder_tb(OutputFile
---
Changelog | 1 +
configure | 7 +
doc/filters.texi | 68 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vsrc_ddagrab.c
---
libavdevice/lavfi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index 1b282a70cb..246f7dff3b 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -287,6 +287,7 @@ av_cold static int lavfi_read_header(AVFormatContext *avctx)
Desktop duplication outputs those
---
libavutil/hwcontext_d3d11va.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index d492489b79..27c0c80413 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@
On 09.07.2022 02:28, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Timo Rothenpieler
Sent: Saturday, July 9, 2022 2:15 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v2 0/8] ddagrab source filter,
lavfi.c wrapped_avframe and dependent changes
On 09.07.2022 07:01, Gyan Doshi wrote:
On 2022-07-09 04:24 am, Timo Rothenpieler wrote:
---
Changelog | 1 +
configure | 7 +
doc/filters.texi | 68 ++
libavfilter/Makefile | 1 +
libavfilter
Applied with some minor stylistic changes and cleanups
Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with
On 11.07.2022 16:26, Andreas Rheinhardt wrote:
Henrik Gramner:
On Mon, Jul 11, 2022 at 11:19 AM Martin Storsjö wrote:
+#if (AV_GCC_VERSION_AT_LEAST(4,0) || defined(__clang__)) && (defined(__ELF__)
|| defined(__MACH__))
+#define av_visibility_hidden __attribute__((visibility("hidden")))
On 12.07.2022 18:28, Marco Vianini wrote:
Hi all
I'm using Libav libraries (version 4.1.6) to make operations on audio/video
AVFrame: conversions, decoding, encoding, etc.
That is a really old version, and you should desperately update.
To improve performances I'd like to use framepool.
So
On 30.06.2022 10:46, Anton Khirnov wrote:
Hardware frames wrapped in frames pretending to be packets. Hacks upon
hacks upon hacks. Why do we need this "device" again?
Why not just use lavfi directly?
It should be definitely possible to make ffmpeg.c directly use a source
filter, but it's a
This avoids an extra copy of potentially quite big video frames.
Instead of copying the entire frames data into a rawvideo packet it
packs the frame into a wrapped avframe packet and passes it through
as-is.
Unfortunately, wrapped avframes are set up to be video frames, so the
audio frames
On 30.06.2022 00:42, mohamed Elhadidy wrote:
From: Mohamed Khaled Mohamed
<56936494+mohamedelhadidy0...@users.noreply.github.com>
GSoC'22
Added CUDA chromakeyfilter
libavfilter/vf_chromakey_cuda.cu:the CUDA kernel for the filter
libavfilter/vf_chromakey_cuda.c: the C side that calls the kernel
The lavfi avdevice as it is right now can't output "special frames"
like hardware frames.
This patch makes the lavfi avdevice output wrapped AVFrames instead
of copying the actual data, greatly simplifying it in the process.
---
I am not at all sure if this has some unexpected consequences.
It
---
libavutil/hwcontext_d3d11va.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index e5afcb2a9d..6355bd1e29 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -166,6
---
libavutil/hwcontext_d3d11va.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 904d14bbc8..e5afcb2a9d 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -397,6 +397,7 @@
---
Changelog | 1 +
configure | 7 +
doc/filters.texi | 68 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vsrc_ddagrab.c
On 17.06.2022 10:41, Carotti, Elias wrote:
Hi all,
any chance someone could possibly have a look at this patch, please?
Thanks in advance
On Fri, 2022-06-10 at 10:11 +, Carotti, Elias wrote:
Hi,
patch attached to add support for passing down to libx264 information
about which macroblock
On 17.06.2022 12:15, Carotti, Elias wrote:
Hi,
thanks for pointing out the printf. That's a left over which I removed.
I am not clear on the possible leak you are hinting at.
The new side information only passes two pointers to libx264, the first
one being a buffer with the flags and a pointer
On 17.06.2022 12:59, Carotti, Elias wrote:
Yes, exactly. It relies on x264 to free it.
Not really. It can rely on x264 if you explicitly want that behavior.
If you do not set a deallocator, it remains the caller responsibility.
What happens if x264 is not involved, but some other encoder,
On 17.06.2022 18:46, dvhh wrote:
pkg_config fallback for SDL2 use 2.1.0 as max (excluded) version
where the pkg_config specify 3.0.0
Correcting fallback version to be in line with the pkg_config version
Why? Any version the new versioning scheme will have a pkg-config file.
On 20/07/2022 10:21, Mark Himsley wrote:
On Tue, 19 Jul 2022 at 13:20, Timo Rothenpieler wrote:
I added an explicit configure check for that type.
Definitely odd, IDXGIOutput5 and it are both Windows 10 APIs, so I'd
have expected them to always exist in tandem.
Thank you - that fixed
On 16.07.2022 12:50, Paul B Mahol wrote:
Please fix native decoder instead.
Both decoders should be fixed if they have issues decoding valid files.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 09.07.2022 00:53, Timo Rothenpieler wrote:
Since a bunch small stuff has changed since the last time I sent these
one by one, here's the whole collection again.
I intend to push the whole lot within the next 48h, so they all make it
in before 5.1 gets branched.
Timo Rothenpieler (8
On 19.07.2022 13:34, Timo Rothenpieler wrote:
On 19.07.2022 09:25, Mark Himsley wrote:
On Sun, 17 Jul 2022 at 12:37, Timo Rothenpieler
wrote:
I will push this series tonight, in about 8 hours from now.
Last chance to delay this by reviewing or raising related concerns.
Just FYI
On 19.07.2022 09:25, Mark Himsley wrote:
On Sun, 17 Jul 2022 at 12:37, Timo Rothenpieler wrote:
I will push this series tonight, in about 8 hours from now.
Last chance to delay this by reviewing or raising related concerns.
Just FYI - this broke my nightly automated builds - which
cross
On 14/07/2022 15:56, Gyan Doshi wrote:
On 2022-07-14 07:21 pm, Timo Rothenpieler wrote:
Seems like the release was missed, and the heap overflow is still
unfixed.
The release hasn't been tagged yet.
It's been branched though, and this isn't a patchset I'd feel
comfortable porting
Seems like the release was missed, and the heap overflow is still unfixed.
In any case, I plan to push this within the next couple days if no
objections are raised.
The changes in the d3d11 hwcontext are minimal and otherwise entirely
unrelated to the QSV hwcontext (if at all, it makes the
On 13.07.2022 11:38, Marco Vianini wrote:
You can get a very big improvement of performances in the special (but very likely) case of:
"(dst_linesize == bytewidth && src_linesize == bytewidth)"
Isn't all that matters dst_linesize == src_linesize, and then you can
memcpy() the whole plane?
On 27/07/2022 21:51, Emil Velikov wrote:
On Thu, 21 Jul 2022 at 21:47, Mark Thompson wrote:
On 20/07/2022 17:41, Emil Velikov wrote:
On Tue, 19 Jul 2022 at 19:16, Nicolas George wrote:
Emil Velikov (12022-07-19):
As you may know the libva* set of libraries share an internal ABI
between
On 02.05.2022 01:04, David Fletcher wrote:
Please find attached a patch adding support for wolfSSL as a TLS backend.
This is against release ffmpeg-5.0.1, and is working well with wolfSSL
5.1.1 (January 2022 release).
Only patches against master can be accepted.
New stuff like this does not
On 27.04.2022 16:07, MCC CS wrote:
The default for AAC_AT is to produce highest quality audio, which I'll keep
undoubtedly
in the same direction. However, the question is this:
Should the one who explicitly set `-aac_at_quality 0` (highest quality
available) be moved from HIGH to MAX,
HOWEVER
You need to keep API and ABI compatibility, cause otherwise it's a
breaking change which can only happen at a major bump.
Any and all existing applications and commandline need to keep working
as they do right now.
What you could do is convert the option into a OPT_TYPE_CONST one, and
offer
Any existing commandline should produce the exact same output after the
change.
Not sure if the encoder is bitexact, but if it is, the output should match.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 02.05.2022 19:45, 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
On 19.08.2022 20:30, Michael Niedermayer wrote:
ok
but just to clarify what i meant / was thinking of was a simple
key / value style parser no features beyond that. just enough so we can
use it to read our own generated xml from some object serialization.
One can hardly call that XML then.
For
On 18.08.2022 17:37, Timo Rothenpieler wrote:
I plan to push this soon.
The half2float.o entry has been moved to the correct Makefile, otherwise
nothing else changed in the meantime.
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
I plan to push this soon.
The half2float.o entry has been moved to the correct Makefile, otherwise
nothing else changed in the meantime.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
On 20.08.2022 13:21, Brendan Hack wrote:
Hi,
I reported https://trac.ffmpeg.org/ticket/9873 last week and have since
been digging into the code to see if I can get a patch together. I've
found the underlying issue in ff_frame_pool_video_init at line 77 of
libavfilter/framepool.c:
On 20.08.2022 14:27, Brendan Hack wrote:
Oh, I think I've got the wrong end of the stick here in regards to what
align does in ff_frame_pool_video_init. Frei0r only needs the start of
the buffer to be aligned to 16 bytes. It doesn't need each _line_ to be
explicitly aligned to 16 bytes since
On 02.09.2022 01:32, Michael Niedermayer wrote:
Hi all
Theres a use after free issue in H.264 Decoding on d3d11va with multiple threads
I dont have the hardware/platform nor do i know the hw decoding code so i made
no attempt to fix this beyond asking others to ...
hwaccel with multiple
On 30.08.2022 21:13, Mohamed Khaled Mohamed wrote:
avfilter: add bilateral_cuda filter
GSoC'22
libavfilter/vf_bilateral_cuda.cu:the CUDA kernel for the filter
libavfilter/vf_bilateral_cuda.c: the C side that calls the kernel and gets user
input
libavfilter/allfilters.c: added the filter to it
On 22.08.2022 22:03, Mohamed Khaled Mohamed wrote:
avfilter: add bilateral_cuda filter
GSoC'22
libavfilter/vf_bilateral_cuda.cu:the CUDA kernel for the filter
libavfilter/vf_bilateral_cuda.c: the C side that calls the kernel and gets user
input
libavfilter/allfilters.c: added the filter to it
On 26.09.2022 16:26, Andriy Gelman wrote:
On Mon, 26. Sep 14:46, Marvin Scholz wrote:
As I am not sure who else to email about this, I'll just post it here.
I tried to register for Patchwork, however I got an error when registering.
I tried again and was told the account already exists, I
On 29.10.2022 14:36, * Neustradamus * wrote:
Hello all,
It is possible to remove all releases from GitHub?
Because at right, we can see and it is not good promotion for this active
project:
- https://github.com/FFmpeg/FFmpeg
Releases 11
FFmpeg 3.0 Release
Latest on 15 Feb 2016
+ 10 releases
-
---
configure | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 70c9e41dcc..30f0ce4e26 100755
--- a/configure
+++ b/configure
@@ -6757,7 +6757,8 @@ enabled mmal && { check_lib mmal
interface/mmal/mmal.h mmal_port_co
On 29.10.2022 20:29, Neal Gompa wrote:
On Fri, Oct 28, 2022 at 2:23 PM Michael Niedermayer
wrote:
Hi
According to our
https://trac.ffmpeg.org/wiki/Downstreams
Noone and nothing is using 5.0
should i make another release of 5.0 ?
should i move 5.0 to olddownloads ?
does anyone use it ? plan
On 28.10.2022 20:23, Michael Niedermayer wrote:
Hi
According to our
https://trac.ffmpeg.org/wiki/Downstreams
Noone and nothing is using 5.0
should i make another release of 5.0 ?
should i move 5.0 to olddownloads ?
does anyone use it ? plan to use it or know of someone using it ?
thx
I see
On 11.09.2022 09:28, Roman Arzumanyan wrote:
Thanks for the detailed review, Timo.
Please find fixed patch in attachement.
I've renamed the filter to colorspace_cuda, did some super minor
stylistic fixes and applied the patch.
Works as I would expect. Obviously it's super limited in what
On 10.09.2022 10:16, Roman Arzumanyan wrote:
From 2b15d8a609a12d97b1ba7500c7f8771b336e2fdf Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan
Date: Sat, 10 Sep 2022 11:05:56 +0300
Subject: [PATCH] libavfilter/vf_colorrange_cuda CUDA-accelerated color range
conversion filter
We could also call
On 01.10.2022 08:13, OvchinnikovDmitrii wrote:
---
libavcodec/avcodec.h | 8
libavcodec/codec_par.h | 8
2 files changed, 16 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7365eb5cc0..66df571afc 100644
--- a/libavcodec/avcodec.h
+++
On 07/10/2022 16:59, OvchinnikovDmitrii wrote:
---
libavcodec/avcodec.h | 35 +++
libavcodec/codec_par.h | 8
libavcodec/options_table.h | 4
3 files changed, 47 insertions(+)
diff --git a/libavcodec/avcodec.h
On 03.10.2022 01:47, Julio C. Rocha wrote:
---
configure | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 6712d045d9..f5f5eb29dd 100755
--- a/configure
+++ b/configure
@@ -4847,7 +4847,12 @@ probe_cc(){
else
On 06.08.2022 08:01, Andreas Rheinhardt wrote:
Fixes Coverity issues #1442912, #1442913, #1442916 and #1442917.
Signed-off-by: Andreas Rheinhardt
---
Given that hevc_ps.c checks these values, it is actually impossible
for this error to be triggered.
libavcodec/nvdec_hevc.c | 4 ++--
1 file
Use the appropiate Makefile variable to ensure it's only built into
shared libraries instead.
---
configure | 4 ++--
libavdevice/Makefile | 2 +-
libavfilter/Makefile | 2 +-
libavformat/Makefile | 2 +-
libavutil/Makefile | 2 +-
libpostproc/Makefile | 2 +-
Some filters, like gdigrab, rely on this to be set to see and report
proper dimensions.
---
fftools/Makefile | 3 +++
fftools/fftools.manifest | 9 +
fftools/fftoolsres.rc| 2 ++
3 files changed, 14 insertions(+)
create mode 100644 fftools/fftools.manifest
create mode 100644
This is by no means a complete wrapper. It's only designed to fit the
usecase ffmpegs build system has.
---
compat/windows/mswindres | 32
configure| 2 ++
2 files changed, 34 insertions(+)
create mode 100755 compat/windows/mswindres
diff --git
On 07.08.2022 18:04, Andreas Rheinhardt wrote:
Timo Rothenpieler:
Use the appropiate Makefile variable to ensure it's only built into
shared libraries instead.
---
configure | 4 ++--
libavdevice/Makefile | 2 +-
libavfilter/Makefile | 2 +-
libavformat/Makefile | 2
On 07.08.2022 17:51, Andreas Rheinhardt wrote:
If the resource files are only for dlls, you can remove SLIBOBJS,
because it is now empty.
I wasn't sure what those 3 variables are for, compared to the other OBJS
variables.
In any case I'd be inclined to leave it in, just in case it turns
This is the default format of the Windows compositor and what DXGI
Desktop Duplication will give you for any kind of HDR output.
---
libavutil/pixdesc.c | 28
libavutil/pixfmt.h | 5 +
libavutil/version.h | 4 ++--
On 08.08.2022 00:25, Thomas Volkert wrote:
Hi Timo,
Am 07.08.2022 um 22:14 schrieb Timo Rothenpieler:
This is the default format of the Windows compositor and what DXGI
Desktop Duplication will give you for any kind of HDR output.
---
libavutil/pixdesc.c | 28
I'd like to push this series within the week or so.
Some additional review, specially on the POSIX-Shell-Script, would be
highly appreciated.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
On 11.08.2022 00:37, Mark Reid wrote:
On Wed, Aug 10, 2022 at 3:28 PM Timo Rothenpieler
wrote:
On 11.08.2022 00:18, James Almer wrote:
Then maybe the current implementation should be moved back to exr (it
used to be internal to exr until Paul made it standalone), so this lavu
module can
On 10.08.2022 23:55, Andreas Rheinhardt wrote:
Don't you need to update the assembly, too? (Do we support anything x86
where the callee has to clean up the stack?)
We concluded on IRC that that's not neccesary.
The assembly is pretty hard written to be cdecl, in which the caller
cleans up the
---
libavfilter/vsrc_ddagrab.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vsrc_ddagrab.c b/libavfilter/vsrc_ddagrab.c
index 252505b96d..00c72187ea 100644
--- a/libavfilter/vsrc_ddagrab.c
+++ b/libavfilter/vsrc_ddagrab.c
@@ -98,6 +98,8 @@ typedef
---
libavcodec/exr.c | 2 +-
libavcodec/exrenc.c| 2 +-
libavcodec/pnmdec.c| 3 ++-
libavcodec/pnmenc.c| 2 +-
{libavcodec => libavutil}/float2half.h | 6 +++---
{libavcodec => libavutil}/half2float.h | 6 +++---
6
---
libavutil/hwcontext_d3d11va.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 27c0c80413..363ec6a47d 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -88,6 +88,7 @@ static const struct {
This is the default format of the Windows compositor and what DXGI
Desktop Duplication will give you for any kind of HDR output.
---
libavutil/pixdesc.c | 28
libavutil/pixfmt.h | 5 +
libavutil/version.h | 4 ++--
---
libavfilter/version.h | 2 +-
libavfilter/vsrc_ddagrab.c | 13 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 19a009c110..fa67606495 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -32,7
On 10.08.2022 23:24, Andreas Rheinhardt wrote:
Timo Rothenpieler:
IEEE-754 differentiates two different kind of NaNs.
Quiet and Signaling ones. They are differentiated by the MSB of the
mantissa.
For whatever reason, actual hardware conversion of half to single always
sets the signaling bit
On 10.08.2022 22:47, Timo Rothenpieler wrote:
...
+#define rgbaf16_funcs_endian(endian_name, endian)
\
+static void rgbaf16##endian_name##ToUV_half_c(uint8_t *_dstU, uint8_t *_dstV,
const uint8_t *unused
On 11.08.2022 00:18, James Almer wrote:
Then maybe the current implementation should be moved back to exr (it
used to be internal to exr until Paul made it standalone), so this lavu
module can match the existing hardware implementations of IEEE-734 half
floats for the purpose of relevant pixel
---
libswscale/hscale.c | 12 +--
libswscale/input.c| 149 ++
libswscale/swscale_internal.h | 17 ++--
libswscale/x86/swscale.c | 13 +--
4 files changed, 106 insertions(+), 85 deletions(-)
diff --git a/libswscale/hscale.c
_Float16 support was available on arm/aarch64 for a while, and with gcc
12 was enabled on x86 as long as SSE2 is supported.
If the target arch supports f16c, gcc emits fairly efficient assembly,
taking advantage of it. This is the case on x86-64-v3 or higher.
Without f16c, it emulates it in
---
libavcodec/Makefile | 8 +++---
libavcodec/exr.c| 2 +-
libavcodec/exrenc.c | 2 +-
libavcodec/float2half.c | 19 +
libavcodec/half2float.c | 19 +
libavcodec/pnmdec.c | 2 +-
libavcodec/pnmenc.c | 2 +-
libavutil/float2half.c | 53
This is by no means perfect, since at least ddagrab will return scRGB
data with values outside of 0.0f to 1.0f for HDR values.
Its primary purpose is to be able to work with the format at all.
---
libavutil/Makefile| 1 +
libswscale/half2float.c | 19 +
libswscale/input.c
Having to put the knowledge of the size of those arrays into a multitude
of places is rather smelly.
---
libavcodec/exr.c | 27 --
libavcodec/exrenc.c| 11 +
libavcodec/pnm.h | 5 ++---
libavcodec/pnmdec.c| 42 --
IEEE-754 differentiates two different kind of NaNs.
Quiet and Signaling ones. They are differentiated by the MSB of the
mantissa.
For whatever reason, actual hardware conversion of half to single always
sets the signaling bit to 1 if the mantissa is != 0, and to 0 if it's 0.
So our code has to
Forgot to update the commit message.
It no longer adds the SwsContext, but an opaque pointer which is easier
to deal with from assembly, should any future code have a use for it.
Fixed locally
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
1001 - 1100 of 1298 matches
Mail list logo
