Signed-off-by: Connor Worley
---
libavcodec/dxvenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dxvenc.c b/libavcodec/dxvenc.c
index ebc48aace3..b92d99981c 100644
--- a/libavcodec/dxvenc.c
+++ b/libavcodec/dxvenc.c
@@ -234,7 +234,7 @@ static av_cold int dxv_ini
Prevents access to uninitialized parts of ctx->tex_data, which were
causing FATE tets to fail under valgrind with --malloc-fill set.
Signed-off-by: Connor Worley
---
libavcodec/dxvenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dxvenc.c b/libavcodec/dxvenc.c
Prevents access to uninitialized parts of ctx->tex_data, which were
causing FATE tets to fail under valgrind with --malloc-fill set.
Signed-off-by: Connor Worley
---
libavcodec/dxvenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dxvenc.c b/libavcodec/dxvenc.c
The previous assumption that DXV needs to be aligned to 16x16 was
erroneous. 4x4 works just as well, and FATE decoder tests pass for all
texture formats.
On the encoder side, we should reject input that isn't 4x4 aligned,
like the HAP encoder does, and stop aligning to 16x16. This both solves
the
Connor Worley:
> The previous assumption that DXV needs to be aligned to 16x16 was
> erroneous. 4x4 works just as well, and FATE decoder tests pass for all
> texture formats.
>
> On the encoder side, we should reject input that isn't 4x4 aligned,
> like the HAP encoder does, and stop aligning to 1
Andreas Rheinhardt:
> test -z is a binary operator.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> tests/fate-run.sh | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index 8efb1586b8..9257fb368b 100755
> --- a/tests/fate-run.s
Le 9 février 2024 00:39:38 GMT+02:00, flow gg a écrit :
>From my understanding, to use larger group multipliers, one needs to
>utilize vlse64 (8x8) vlse128 (16x16).
>
>However, due to the use in tests of
>
>ptr = img2 + y * WIDTH + x;
>d2 = call_ref(NULL, img1, ptr, WIDTH, h);
>d1 = call_new(NUL
Marth64:
> Please ignore v9, I screwed up the email subject (contents are the same).
> Sorry folks.
>
> Addresses all prior feedback to my knowledge. Hopefully this has a chance for
> 7.0,
> as I am starting to believe there are not great alternatives to this demuxer
> out there.
>
> Thank you
Add "footer_with_hmd" option: this option activates the writing of the
header metadata in the footer partition.
Cédric
--- Begin Message ---
Signed-off-by: Cedric Le Barz
---
ffmpeg/libavformat/mxfenc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/ffmpeg/libavfo
By default the option "flv_metadata" (internally using the field
name "trust_metadata") is set to 0, meaning that we don't allocate
streams based on information in the metadata, only based on
actual streams we encounter. However the "datastream" metadata field
still would allocate a subtitle stream
On Fri, 26 Jan 2024, Martin Storsjö wrote:
On Fri, 26 Jan 2024, Martin Storsjö wrote:
These inline implementations of AV_COPY64, AV_SWAP64 and AV_ZERO64
are known to clobber the FPU state - which has to be restored
with the 'emms' instruction afterwards.
This was known and signaled with the F
Fixes: fuzzer timeout
Fixes:
65253/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_MP4TOANNEXB_fuzzer-4972412487467008
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
Signed-off-by: Andreas Rheinhardt
---
lib
similar issue as in the previous commit
---
libavcodec/bsf/hevc_mp4toannexb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/bsf/hevc_mp4toannexb.c
b/libavcodec/bsf/hevc_mp4toannexb.c
index d91229a895..8eec18f31e 100644
--- a/libavcodec/bsf/hevc_mp4toannexb.c
Signed-off-by: Andreas Rheinhardt
---
fftools/cmdutils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index daf7673adb..5e181a0d85 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1121,7 +1121,7 @@ double get_rotation(cons
On Thu, Feb 8, 2024 at 11:50 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Nuo Mi:
> > Fixes: fuzzer timeout
> > Fixes:
> 65253/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_MP4TOANNEXB_fuzzer-4972412487467008
> >
> > Found-by: continuous fuzzing process
> https://github.com/goo
Quoting Andreas Rheinhardt (2024-02-09 12:18:51)
> Signed-off-by: Andreas Rheinhardt
> ---
> fftools/cmdutils.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index daf7673adb..5e181a0d85 100644
> --- a/fftools/cmdutils.c
> +++
On Monday, 05 February 2024 at 21:53, Niklas Haas wrote:
> On Mon, 05 Feb 2024 15:13:22 -0500 Devin Heitmueller
> wrote:
> > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov wrote:
> > >
> > > It should be available in all relevant modern compilers and will
> > > allow us to use features like anonymo
The previous assumption that DXV needs to be aligned to 16x16 was
erroneous. 4x4 works just as well, and FATE decoder tests pass for all
texture formats.
On the encoder side, we should reject input that isn't 4x4 aligned,
like the HAP encoder does, and stop aligning to 16x16. This both solves
the
Nuo Mi:
> Fixes: fuzzer timeout
> Fixes:
> 65253/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_MP4TOANNEXB_fuzzer-4972412487467008
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> Signed-off-by: Andr
On Fri, 9 Feb 2024, Nuo Mi wrote:
similar issue as in the previous commit
---
libavcodec/bsf/hevc_mp4toannexb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Keep in mind, that while the patches are posted together, they can end up
at different places further in review, and in co
On Fri, Feb 9, 2024 at 11:22 AM Dominik 'Rathann' Mierzejewski
wrote:
> Even so, a C17-supporting compiler (gcc 11.2.1) is available for CentOS 7
> in the devtoolset-11-gcc package (from
> http://mirror.centos.org/centos/7/sclo/x86_64/rh/).
As a 'User' of the FFmpeg project, we have a lot of Cent
On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt
wrote:
> This presumes the relevant states to be a cartesian product. Which need
> not be true. A callback would be better; this would also allow to base
> the list on other values already set in an AVCodecContext. And if this
> were extended,
From: Niklas Haas
Currently, such filters defer hardware device initialization to
query_formats(), which is not really the correct place to have it. It
would be far more logical for these filters to create the hardware
context at init time, and error out otherwise.
By contrast, filters which mer
From: Niklas Haas
Otherwise, filters that depend on a hw_device_ctx being present at
init() time would fail configuring under the semantics outlined in the
previous commit.
---
fftools/ffmpeg_filter.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_filter.c
From: Niklas Haas
---
libavfilter/vf_hwupload.c | 49 ++-
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/libavfilter/vf_hwupload.c b/libavfilter/vf_hwupload.c
index ef61bb4137..bc1e32af1a 100644
--- a/libavfilter/vf_hwupload.c
+++ b/libavfilte
From: Niklas Haas
---
libavfilter/vf_libplacebo.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
index a9a3d884ce..f41d8be0c0 100644
--- a/libavfilter/vf_libplacebo.c
+++ b/libavfilter/vf_li
From: Niklas Haas
Not as strongly motivated as the previous commits, but there's still no
reason to do this from config_props if we can avoid it.
---
libavfilter/vsrc_ddagrab.c | 99 ++
1 file changed, 48 insertions(+), 51 deletions(-)
diff --git a/libavfilte
Quoting Marton Balint (2024-02-04 20:28:11)
> +/**
> + * Change the AVChannelOrder of a channel layout.
> + *
> + * Change of AVChannelOrder can be either lossless or lossy. In case of a
> + * lossless conversion all the channel designations and the associated
> channel
> + * names (if any) are ke
Quoting Martin Storsjö (2024-02-09 12:06:56)
> If there are no better suggestions here, I would like to go ahead and push
> this.
🎉
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
The issue here is that any load greater than e8 will fail the test(Bus
error), so it cannot use vlse64 or similar methods...
Rémi Denis-Courmont 于2024年2月9日周五 18:32写道：
>
>
> Le 9 février 2024 00:39:38 GMT+02:00, flow gg a
> écrit :
> >From my understanding, to use larger group multipliers, one n
Quoting Niklas Haas (2024-02-09 15:53:45)
> From: Niklas Haas
>
> Currently, such filters defer hardware device initialization to
> query_formats(), which is not really the correct place to have it. It
> would be far more logical for these filters to create the hardware
> context at init time, an
It should be available in all relevant modern compilers and will allow
us to use features like anonymous unions.
Note that stdatomic.h is still emulated on MSVC, as current versions
require the /experimental:c11atomics, and do not support
ATOMIC_VAR_INIT() anyway.
---
The general consensus seems t
Quoting Niklas Haas (2024-02-09 15:53:46)
> From: Niklas Haas
>
> Otherwise, filters that depend on a hw_device_ctx being present at
> init() time would fail configuring under the semantics outlined in the
> previous commit.
> ---
> fftools/ffmpeg_filter.c | 5 -
> 1 file changed, 4 insertio
Quoting Niklas Haas (2024-02-09 15:53:47)
> From: Niklas Haas
>
> ---
> libavfilter/vf_hwupload.c | 49 ++-
> 1 file changed, 28 insertions(+), 21 deletions(-)
LGTM
--
Anton Khirnov
___
ffmpeg-devel mailing list
f
The new API requires an extra array member at the very end,
which old API users did not do.
This disables in-place RDFT transforms and instead
does the transform out of place by copying once, there shouldn't
be a significant loss of speed as our in-place FFT requires a reorder
which is likely more
> On Feb 1, 2024, at 11:26 PM, wenbin.chen-at-intel@ffmpeg.org wrote:
>
> From: Wenbin Chen
>
> PyTorch is an open source machine learning framework that accelerates
> the path from research prototyping to production deployment. Official
> websit: https://pytorch.org/. We call the C++ libr
Solution is on the way. Thanks!
On Fri, Feb 9, 2024 at 4:43 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Marth64:
> > Please ignore v9, I screwed up the email subject (contents are the
> same). Sorry folks.
> >
> > Addresses all prior feedback to my knowledge. Hopefully this h
On Thu, Feb 8, 2024 at 1:58 PM Dariusz Marcinkiewicz via ffmpeg-devel
wrote:
>
> This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx and makes
> us retry encode if screen_content_mode == 2 and no output was produced
> by encoder.
>
> Co-authored-by: Erik Språng
> Signed-off-by: Dariusz M
On Fri, Feb 09, 2024 at 06:27:50PM +0100, Lynne wrote:
> The new API requires an extra array member at the very end,
> which old API users did not do.
>
> This disables in-place RDFT transforms and instead
> does the transform out of place by copying once, there shouldn't
> be a significant loss o
On 13.01.2024 16:46, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself
Feb 9, 2024, 20:19 by matthieu.bou...@gmail.com:
> On Fri, Feb 09, 2024 at 06:27:50PM +0100, Lynne wrote:
>
>> The new API requires an extra array member at the very end,
>> which old API users did not do.
>>
>> This disables in-place RDFT transforms and instead
>> does the transform out of place
DVD subtitle palettes, which are natively YUV, are
currently carried as a hex string in their respective subtitle streams and
have no concept of colorspace tagging. In fact, the convention is to convert
them to RGB prior to storage. Common players will only render the palettes
properly if they are
Addresses the last round of feedback.
Fingers crossed.
- Resolves maintainability concern
- Some more formatting nits
- Removes the YUV-RGB lookup table
Signed-off-by: Marth64
---
Changelog |2 +
configure |8 +
doc/demuxers.texi | 130
liba
On Fri, 9 Feb 2024, Connor Worley wrote:
The previous assumption that DXV needs to be aligned to 16x16 was
erroneous. 4x4 works just as well, and FATE decoder tests pass for all
texture formats.
On the encoder side, we should reject input that isn't 4x4 aligned,
like the HAP encoder does, and s
On 2/4/24 04:35, Leo Izen wrote:
This adds support for cLLi and mDVc chunks in the PNG specification[1].
[1]: https://www.w3.org/TR/png-3/
Changes from v1:
- fix regression in cHRM writing, causing fate failure
Leo Izen (2):
avcodec/pngdec: read cLLi and mDVc chunks
avcodec/pngenc: write
On 1/31/24 14:37, Leo Izen wrote:
The function signature for bytestream2_seek is (gb, offset, whence);
Before this patch, the code passed (gb, SEEK_SET, offset), which is
incorrect.
Siged-off-by: Leo Izen
---
libavcodec/tiff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Le keskiviikkona 7. helmikuuta 2024, 2.12.22 EET flow gg a écrit :
> My carelessness.. fixed it in the reply.
I know I said to avoid scalar multiplications, but this may be taking it a
little too far. Either this works:
slli t1, t0, 9
sh2add t0, t0, t0
sub t0, t1, t0
or just:
li t1, 1
Possible since 7ec2354c38978b918dc079b611393becb6c80bf7.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dca_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/dca_core.c b/libavcodec/dca_core.c
index 5dd727fc72..697fc74295 100644
--- a/libavcodec/dca_core.c
+++ b/libavcodec/d
Signed-off-by: Marth64
---
libavformat/avformat.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 5d0fe82250..070ed7023d 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2175,7 +2175,7 @@ int av_pro
On Fri, 9 Feb 2024, Andreas Rheinhardt wrote:
Possible since 7ec2354c38978b918dc079b611393becb6c80bf7.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/dca_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/dca_core.c b/libavcodec/dca_core.c
index 5dd727fc72..697fc74295 100644
This will be used to support tiled image formats like HEIF.
Signed-off-by: James Almer
---
Changed the API to support overlaping tiles, as well as leaving pixels
unfilled. This allows us to implement Image Overlay HEIF support.
libavformat/avformat.c | 5 ++
libavformat/avformat.h | 127 +
Export each tile as its own stream, and the grid information as a Stream Group
of type TILE_GRID.
This also enables exporting other stream items like thumbnails, which may be
present in non tiled HEIF images too. For those, the primary stream will be
tagged with the default disposition.
Based on a
Signed-off-by: James Almer
---
tests/fate/mov.mak | 2 +-
tests/ref/fate/mov-heic-demux-still-image-multiple-items | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 4850c8aa94..1be7a0d15a
- Fixes anticipated feedback about bprint_finalize()
- Fixes anticipated documentation typo
- Removes unnecessary constant
Signed-off-by: Marth64
---
Changelog |2 +
configure |8 +
doc/demuxers.texi | 130
libavformat/Makefile |1 +
DVD subtitle palettes, which are natively YUV, are
currently carried as a hex string in their respective subtitle streams and
have no concept of colorspace tagging. In fact, the convention is to convert
them to RGB prior to storage. Common players will only render the palettes
properly if they are
Okay, I have updated them in the response
Rémi Denis-Courmont 于2024年2月10日周六 05:14写道：
> Le keskiviikkona 7. helmikuuta 2024, 2.12.22 EET flow gg a écrit :
> > My carelessness.. fixed it in the reply.
>
> I know I said to avoid scalar multiplications, but this may be taking it a
> little too far.
56 matches
Mail list logo
