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 uns
Forgotten in 02220b88fc38ef9dd4f2d519f5d3e4151258b60c.
Signed-off-by: Andreas Rheinhardt
---
Sorry. Will apply this soon.
libavcodec/pthread_frame.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index a54d16fee4..
On 2022-08-10 05:46 pm, James Almer wrote:
ffmpeg | branch: master | James Almer | Tue Aug 2 08:28:48
2022 -0300| [0c3e3fd1b478e14692f3b02bb8bf42262ee18af0] | committer: James Almer
avfilter/framesync: add a new option to set how to sync streams based on
secondary input timestamps
Needs
Redundant since 5e03eea673a9da2253ed15152e46b1422b35d145.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp9.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index db06acd748..621627ddc5 100644
--- a/libavcodec/vp9.c
+++ b/libavc
Signed-off-by: Michael Riedl
---
libavfilter/vf_showinfo.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 2c8514fc80..1953f777c7 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -43,6 +43,7 @@
---
fftools/ffmpeg.c | 37 +++--
1 file changed, 15 insertions(+), 22 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0332528d57..cacbde27db 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3743,7 +3743,22 @@ static void ts_discontinuity
---
fftools/ffmpeg_mux.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 08a76f0066..b424ef0021 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -97,8 +97,10 @@ static int write_packet(OutputFi
Currently this code is located in the discontinuity handling block,
where it does not belong.
---
fftools/ffmpeg.c | 39 +--
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 16b1ba8af7..6f822de97d 100644
-
---
fftools/ffmpeg.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0682a6fcc5..16b1ba8af7 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1780,6 +1780,13 @@ static void flush_encoders(void)
{
int i, ret;
+for (i = 0; i < n
InputFile.ts_offset can change during transcoding, due to discontinuity
correction. This should not affect the streamcopy starting timestamp.
Cf. bf2590aed3e64d44a5e2430fdbe89f91f5e55bfe
---
fftools/ffmpeg.c | 17 -
fftools/ffmpeg.h | 6 ++
2 files changed, 18 insertions(+),
This will allow to move normal offset handling to demuxer thread, since
discontinuities currently have to be processed in the main thread, as
the code uses some decoder-produced values.
---
fftools/ffmpeg.c | 39 ---
fftools/ffmpeg.h | 4
2 files changed,
---
fftools/ffmpeg.c | 103 ++-
1 file changed, 56 insertions(+), 47 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index b895f85e75..0332528d57 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3693,6 +3693,59 @@ static void decod
---
fftools/ffmpeg.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index cacbde27db..dd45cb4516 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3713,8 +3713,7 @@ static void ts_discontinuity_process(InputFile *ifile,
Discontinuity detection/correction is left in the main thread, as it is
entangled with InputStream.next_dts and related variables, which may be
set by decoding code.
Fixes races e.g. in fate-ffmpeg-streamloop after
aae9de0cb2887e6e0bbfda6ffdf85ab77d3390f0.
---
fftools/ffmpeg.c | 52
---
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 ++--
tests/re
---
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 +
---
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 f
---
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 st
_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 softwa
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
---
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
---
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 b/libswscale
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 fol
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 --
lib
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
http
Timo Rothenpieler:
> _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
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 to 1 if the mantissa is != 0, and to 0 if
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 to
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, \
+
Timo Rothenpieler:
> 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
On 10.08.2022 23:43, Andreas Rheinhardt wrote:
Timo Rothenpieler:
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 har
Timo Rothenpieler:
> ---
> 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
On 10.08.2022 23:03, Andreas Rheinhardt wrote:
Timo Rothenpieler:
_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 th
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
On 8/10/2022 6:58 PM, Timo Rothenpieler wrote:
On 10.08.2022 23:03, Andreas Rheinhardt wrote:
Timo Rothenpieler:
_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 eff
On Wed, Aug 10, 2022 at 2:53 PM Timo Rothenpieler
wrote:
> On 10.08.2022 23:43, Andreas Rheinhardt wrote:
> > Timo Rothenpieler:
> >> On 10.08.2022 23:24, Andreas Rheinhardt wrote:
> >>> Timo Rothenpieler:
> IEEE-754 differentiates two different kind of NaNs.
> Quiet and Signaling ones.
On 8/10/2022 7:14 PM, Mark Reid wrote:
On Wed, Aug 10, 2022 at 2:53 PM Timo Rothenpieler
wrote:
On 10.08.2022 23:43, Andreas Rheinhardt wrote:
Timo Rothenpieler:
On 10.08.2022 23:24, Andreas Rheinhardt wrote:
Timo Rothenpieler:
IEEE-754 differentiates two different kind of NaNs.
Quiet and
A gateway can see everything, and we should not be shipping a hardcoded
default from a third party company; it's a security risk.
Signed-off-by: Derek Buitenhuis
---
libavformat/ipfsgateway.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/libavformat/ipfsgateway.
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
On Wed, Aug 10, 2022 at 06:25:39PM +0200, Anton Khirnov wrote:
> Currently this code is located in the discontinuity handling block,
> where it does not belong.
> ---
> fftools/ffmpeg.c | 39 +--
> 1 file changed, 21 insertions(+), 18 deletions(-)
this seems to
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 match the existing hardware imple
_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.
Same goes on arm, which has native flo
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 match
On 8/10/2022 7:51 PM, Timo Rothenpieler wrote:
_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
On Wed, Aug 10, 2022 at 3:56 PM Timo Rothenpieler
wrote:
> 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
> >>> u
On Mon, 2022-08-01 at 15:27 +0200, Anton Khirnov wrote:
> Quoting Xiang, Haihao (2022-07-25 06:11:51)
> > +elif enabled libvpl; then
> > +# Consider pkg-config only. The name of libmfx is still passed to
> > check_pkg_config function for --enable-libvpl option
> > +# because QSV has dependency on l
From: Pierre-Anthony Lemieux
Further code style improvements.
---
libavformat/avformat.c | 66
libavformat/fifo.c | 10 ++
libavformat/internal.h | 11 +++
libavformat/mux.h| 9 --
libavformat/mux_utils.c | 28
From: Pierre-Anthony Lemieux
---
libavformat/imfdec.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index 71dfb26958..5bbe7a53f8 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -573,18 +573,14 @@ stati
Hi James Almer,
Thank you for your last code review.
I did a lot of changes to our EVC wrapper implementation following your
comments from the last code review and I'm looking forward to receiving your
feedback.
We would like to start getting closer to the point where we can be able to
merge our
50 matches
Mail list logo
