Quoting Michael Niedermayer (2024-02-11 21:39:17)
> some of these have formatting issues:
> (havent really reviewd just saw when applying locally)
Yes, Coccinelle unfortunately does that, as mentioned in the commit
message.
I've fixed those I noticed, which was not all apparently.
Fixed the two
Changes from v2:
- rebased ontop of the recently pushed eol normalisation.
As a result no more CRLFs in here and Patchwork should be happy
- added a fourth cosmetic commit adjusting
explicit linebreaks to the new normalisation
Changes from v1:
- ff_ass_bprint_text_event now only inserts
Backslashes cannot be escaped by a backslash in any ASS renderer,
but unless followed by specific characters it is just printed out.
Insert a word-joiner character after a backslash to break up
active sequences without changing the visual output.
---
libavcodec/ass.c | 9 -
Unlike what the old comment suggested, standard ASS has no character
escape mechanism, but a closing curly bracket doesn't even need one.
For manual authored sub files using a full-width variant of an apropiate
font and with scaling and psacing modifiers is a common workaround.
This is not an
---
libavcodec/webvttdec.c | 2 +-
tests/ref/fate/sub-webvtt2 | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
index 690f00dc47..990d150f16 100644
--- a/libavcodec/webvttdec.c
+++ b/libavcodec/webvttdec.c
@@ -39,7 +39,7 @@
ff_ass_subtitle_header_* still used explicit CRLF linebreaks
eventhough they will get normalised to LF later since commit
7bf1b9b35769b37684dd2f18a54f01d852a540c8. Just directly use LF.
---
libavcodec/ass.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff
I apologize for not having responded earlier.
I've attached the updated patch.
>From 68c77320954e44a7f02e95537fc9a6436da7549c Mon Sep 17 00:00:00 2001
From: asivery
Date: Sun, 11 Feb 2024 23:13:07 +0100
Subject: [PATCH] avformat/matroska: Add support for A_ATRAC/AT1
Signed-off-by: asivery
---
On Sun, Feb 11, 2024 at 9:41 AM James Almer wrote:
> This set broke fate when using slice threading:
>
> https://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-threads-misc=20240211015448
>
https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321317.html
contains a fix.
--
Connor
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to OpenCLDeviceContext as one no longer has to
go through AVHWDeviceInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_opencl.c | 50
This change decouples the frame dimensions from avctx, which is useful
for DXV decoding, and fixes incorrect behavior in the existing
implementation.
Tested with `make fate THREADS=7` and
`make fate THREADS=7 THREAD_TYPE=slice`.
Signed-off-by: Connor Worley
---
libavcodec/dds.c
This is possible because the lifetime of these structures coincide.
It has the advantage of allowing to remove AVHWFramesInternal
from the public header; given that AVHWFramesInternal.priv is no more,
most accesses to AVHWFramesInternal are no more; indeed, the only
field accessed of it outside of
It is no longer used by any hwcontext, as they all allocate
their private data together with their public data and access
it via AVHWFramesContext.hwctx.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext.c | 9 -
libavutil/hwcontext_internal.h | 6 --
2 files
Use AVHWFramesContext.hwctx instead.
This simplifies accesses to VDPAUFramesContext as one no longer has
to go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_cuda.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Use AVHWFramesContext.hwctx instead.
This simplifies access to VDPAUFramesContext as one no longer has
to go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_vdpau.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
Correct the names of the format-specific headers (not hwframe_*.h)
and clarify that the user shall ignore this field if there is no
public context associated with it.
In particular, this allows to use this field for the private context
alone if there is no public context. This can't break
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to D3D12VAFramesContext as one no longer has to
go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_d3d12va.c | 20
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to D3D11VAFramesContext as one no longer has to
go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_d3d11va.c | 34
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to DXVA2FramesContext as one no longer has to
go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_dxva2.c | 24
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to QSVFramesContext as one no longer has to
go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_qsv.c | 46
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to OpenCLFramesContext as one no longer has to
go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_opencl.c | 38
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VTFramesContext as one no longer has to
go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_videotoolbox.c | 15 +--
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VulkanFramesPriv as one no longer has to
go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_vulkan.c | 30
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VAAPIFramesContext as one no longer has to
go through AVHWFramesInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_vaapi.c | 24
This is possible because the lifetime of these structures coincide.
It has the advantage of allowing to remove the AVHWDeviceInternal
from the public header; given that AVHWDeviceInternal.priv is no more,
all accesses to it happen in hwcontext.c, so that this commit moves
the joint structure
It is no longer used by any hwcontext, as they all allocate
their private data together with their public data and access
it via AVHWDeviceContext.hwctx.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext.c | 9 -
libavutil/hwcontext_internal.h | 6 --
2 files
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to D3D12VADevicePriv as one no longer has to
go through AVHWDeviceInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_d3d12va.c | 17 ++---
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VDPAUDeviceContext as one no longer has to
go through AVHWDeviceInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_vdpau.c | 28
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to QSVDeviceContext as one no longer has to
go through AVHWDeviceInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_qsv.c | 18 +++---
1
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VulkanDevicePriv as one no longer has to
go through AVHWDeviceInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_vulkan.c | 109
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VAAPIDeviceContext as one no longer has to
go through AVHWDeviceInternal.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext_vaapi.c | 22
av_buffer_unref() can handle AVBufferRef** that point
to a NULL AVBufferRef*.
Signed-off-by: Andreas Rheinhardt
---
libavutil/hwcontext.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index e23bad230f..63fc1a6a22 100644
---
The currently used pointer when unmapping DXVA2 and D3D11
actually points to an OpenCLDeviceContext.
Signed-off-by: Andreas Rheinhardt
---
1. I'd appreciate testing of this.
2. Most of the patches in this patchset can be applied immediately;
only those two patches that remove AVHWDeviceInternal
On Sat, Feb 03, 2024 at 08:29:31PM +0100, Michael Niedermayer wrote:
> Fixes: Ticket6581
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/indeo3.c | 3 +++
> 1 file changed, 3 insertions(+)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
On Mon, Feb 05, 2024 at 03:58:22AM +0100, Michael Niedermayer wrote:
> fbw_channels must be > 0 as teh code is only run if cpl_enabled is set and
> that requires mode >= AC3_CHMODE_STEREO
>
> CID 718138 Uninitialized scalar variable
> assumes this assert to be false
>
> Signed-off-by:
On Sun, 11 Feb 2024, James Almer wrote:
On 2/4/2024 4:28 PM, Marton Balint wrote:
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 ++
libavutil/channel_layout.c | 106 +
libavutil/channel_layout.h | 40 ++
On Sun, Feb 11, 2024 at 9:41 AM James Almer wrote:
> On 2/11/2024 9:41 AM, Connor Worley wrote:
> > "or less than" is wrong -- rather tex_step seems to have been larger than
> > necessary in some cases. With the minimal tex_step in those cases, the
> new
> > tex_size should be equal to the LHS.
On Mon, Feb 05, 2024 at 12:44:59PM +0100, Michael Niedermayer wrote:
> Fixes: CID 1403229 Dereference after null check
>
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/signature_lookup.c | 6 ++
> 1 file changed, 6 insertions(+)
will apply
[...]
--
Michael GnuPG
On 2/4/2024 4:28 PM, Marton Balint wrote:
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 ++
libavutil/channel_layout.c | 106 +
libavutil/channel_layout.h | 40 ++
libavutil/version.h| 2 +-
4 files changed,
$subj
0001-x86-h264_pred-Convert-ff_pred8x8_vertical_8_mmx-to-f.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
On 2/11/2024 7:34 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/11/2024 6:24 PM, Kieran Kunhya wrote:
$subj, now with forward declaration also removed.
This function is trivial to convert to SSE2, so better do that than
removing it. Attached.
If other functions are harder to port to SSE2,
On Sun, 11 Feb 2024 at 22:33, Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> James Almer:
> > On 2/11/2024 6:24 PM, Kieran Kunhya wrote:
> >> $subj, now with forward declaration also removed.
> >
> > This function is trivial to convert to SSE2, so better do that than
> > removing
On Fri, 9 Feb 2024, Anton Khirnov wrote:
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
James Almer:
> On 2/11/2024 6:24 PM, Kieran Kunhya wrote:
>> $subj, now with forward declaration also removed.
>
> This function is trivial to convert to SSE2, so better do that than
> removing it. Attached.
> If other functions are harder to port to SSE2, then sure, they can be
> removed.
>
On Sun, 11 Feb 2024 at 21:36, James Almer wrote:
> On 2/11/2024 6:24 PM, Kieran Kunhya wrote:
> > $subj, now with forward declaration also removed.
>
> This function is trivial to convert to SSE2, so better do that than
> removing it. Attached.
> If other functions are harder to port to SSE2,
On Sun, Feb 11, 2024 at 06:10:06PM -0300, James Almer wrote:
> On 2/11/2024 6:08 PM, James Almer wrote:
> > On 2/11/2024 5:41 PM, Michael Niedermayer wrote:
> > > On Sun, Feb 11, 2024 at 03:56:59PM -0300, James Almer wrote:
> > > > Export tiles as streams, and the grid information as a Stream
> >
Le dim. 11 févr. 2024 à 12:37, Nuo Mi a écrit :
> > -DECLARE_ALIGNED(16, const int8_t, ff_hevc_qpel_filters)[3][16] = {
> > +DECLARE_ALIGNED(16, const int8_t, ff_hevc_qpel_filters)[4][16] = {
> >
> Do you know why this is [4][16]? [4][8] should suffice.
Probably so that all coefficient banks are
On 2/11/2024 6:24 PM, Kieran Kunhya wrote:
$subj, now with forward declaration also removed.
This function is trivial to convert to SSE2, so better do that than
removing it. Attached.
If other functions are harder to port to SSE2, then sure, they can be
removed.From
$subj, now with forward declaration also removed.
0001-h264_intrapred-Remove-ff_pred16x16_horizontal_8_mmxe.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
On 2/11/2024 6:08 PM, James Almer wrote:
On 2/11/2024 5:41 PM, Michael Niedermayer wrote:
On Sun, Feb 11, 2024 at 03:56:59PM -0300, James Almer wrote:
Export tiles as streams, and the grid information as a Stream Group
of type
TILE_GRID.
This also enables exporting other stream items like
On 2/11/2024 5:41 PM, Michael Niedermayer wrote:
On Sun, Feb 11, 2024 at 03:56:59PM -0300, James Almer wrote:
Export tiles as streams, 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
$subj
0001-h264_intrapred-Remove-ff_pred16x16_horizontal_8_mmxe.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
Ping, last call for objections.
___
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 subject "unsubscribe".
$subj
0001-vp6dsp-Remove-MMX-code.patch
Description: Binary data
___
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 Sat, 10 Feb 2024 11:56:29 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> When this filter overrides frame properties, the outgoing frames have
> a different YUV colorspace than the incoming ones. This requires
> signalling the new colorspace on the outlink, and in particular, making
> sure
On Sun, Feb 11, 2024 at 03:56:59PM -0300, James Almer wrote:
> Export tiles as streams, 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.
>
> Based on a patch by
On Sun, Feb 11, 2024 at 06:08:28PM +0100, Anton Khirnov wrote:
> Makes it robust against adding fields before it, which will be useful in
> following commits.
>
> Majority of the patch generated by the following Coccinelle script:
>
> @@
> typedef AVOption;
> identifier arr_name;
> initializer
Hello,
I would like to know if fate-suite.ffmpeg.org is very slow to sync for
anyone else?
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
Hi all
just got this today, and to avoid anyone being upset of not knowing
about something again.
I dont know if this applies to us but posting it here
Also iam not doing gsoc admin (iam just really the last resort backup
i dont have time for gsoc) but it seemes
someone fillled everything out
Signed-off-by: James Almer
---
tests/fate/mov.mak| 8 +
.../ref/fate/mov-heic-demux-still-image-grid | 32 +++
.../ref/fate/mov-heic-demux-still-image-iovl | 18 +++
3 files changed, 58 insertions(+)
create mode 100644
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
Export tiles as streams, 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.
Based on a patch by Swaraj Hota
Signed-off-by: James Almer
---
libavformat/avformat.c | 8
This will be used to support tiled image formats like HEIF.
Signed-off-by: James Almer
---
There can be more tiles than streams in the group now, which makes it possible
to parse C021.heic
libavformat/avformat.c | 5 ++
libavformat/avformat.h | 147 +
Signed-off-by: Marth64
---
doc/demuxers.texi | 5 +++
libavformat/Makefile | 2 +-
libavformat/dvdclut.c | 76 +++
libavformat/dvdclut.h | 37 +++
libavformat/dvdvideodec.c | 14
5 files changed, 133
No critical changes since v12.
- Removes unused context variable
- Removes unnecessary if statement
- Whitespace cleanup
- Rebase with master
Signed-off-by: Marth64
---
Changelog |2 +
configure |8 +
doc/demuxers.texi | 130
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 is also 32 byte aligned.
This might make the
On 2/11/2024 9:41 AM, Connor Worley wrote:
"or less than" is wrong -- rather tex_step seems to have been larger than
necessary in some cases. With the minimal tex_step in those cases, the new
tex_size should be equal to the LHS.
This set broke fate when using slice threading:
Add an AVOption to the libjxl encoder wrapper, which exposes the flag
uses_original_profile in libjxl. For highly unusual ICC profiles where
the target needs to stay in the original space, this can be useful.
Signed-off-by: Leo Izen
---
libavcodec/libjxlenc.c | 5 -
libavcodec/version.h |
Changes since v1:
- bump micro version, per policy
- rebase onto master
Leo Izen (1):
avcodec/libjxlenc: add option to disable xyb encoding
libavcodec/libjxlenc.c | 5 -
libavcodec/version.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
--
2.43.0
The currently used pointer when unmapping DXVA2 and D3D11
actually points to an OpenCLDeviceContext.
Signed-off-by: Andreas Rheinhardt
---
Untested. Both of these structures have command queues at the start
which is probably why this seems to work.
libavutil/hwcontext_opencl.c | 4 ++--
1 file
On 11.02.2024 15:00, Andreas Rheinhardt wrote:
Timo Rothenpieler:
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
On 11.02.2024 15:22, Rémi Denis-Courmont wrote:
Le perjantaina 9. helmikuuta 2024, 21.22.17 EET Timo Rothenpieler a écrit :
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
Most of this patch was written by Dave Airlie ,
with some additions by me.
>From 4a0c01046e36cff48100d09565f5ef8d8185907a Mon Sep 17 00:00:00 2001
From: Lynne
Date: Fri, 19 Jan 2024 10:49:02 +1000
Subject: [PATCH v4 2/2] lavc/vulkan_av1: port to the new stable API
Most of this patch was written
Needed for Vulkan AV1.
>From 67beae754b839398287499d51134cc40d7cf8ad4 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Fri, 2 Feb 2024 03:54:06 +0100
Subject: [PATCH v4 1/2] lavc/cbs_av1: fill in ref_frame_sign_bias and
order_hints
Needed for Vulkan AV1.
---
libavcodec/cbs_av1.h |
Feb 11, 2024, 12:58 by s...@jkqxz.net:
> On 10/02/2024 22:39, Lynne wrote:
>
>> 11 files changed, 303 insertions(+), 669 deletions(-)
>> delete mode 100644 libavcodec/vulkan_video_codec_av1std.h
>> delete mode 100644 libavcodec/vulkan_video_codec_av1std_decode.h
>>
>
> You need something in
On Sat, Feb 10, 2024 at 6:57 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Nuo Mi:
> > On Fri, Feb 9, 2024 at 7:40 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Nuo Mi:
> >>> Fixes: fuzzer timeout
> >>> Fixes:
> >>
>
Le perjantaina 9. helmikuuta 2024, 21.22.17 EET Timo Rothenpieler a écrit :
> 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,
Timo Rothenpieler writes:
> 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
Forgotten in 268062fa15e1c05310f9c3977e0b95ac07eca274.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_bwdif_cuda.c | 1 -
libavfilter/vf_yadif_cuda.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/libavfilter/vf_bwdif_cuda.c b/libavfilter/vf_bwdif_cuda.c
index 7585d1fe25..8c37dc8800
Timo Rothenpieler:
> 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 is also 32 byte
"or less than" is wrong -- rather tex_step seems to have been larger than
necessary in some cases. With the minimal tex_step in those cases, the new
tex_size should be equal to the LHS.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Sun, Feb 04, 2024 at 01:42:31AM +0100, Michael Niedermayer wrote:
> On Sat, Feb 03, 2024 at 04:37:54AM +0100, Michael Niedermayer wrote:
> > On Thu, Feb 01, 2024 at 05:29:26AM +0100, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > To do the STF/SPI thing properly, and make sure we do what
On Sun, Feb 11, 2024 at 1:03 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Connor Worley:
> > -{
> > -int w_block = avctx->coded_width / ctx->texture_block_w;
> > -int h_block = avctx->coded_height / ctx->texture_block_h;
> > -if (w_block * h_block *
On 10/02/2024 22:39, Lynne wrote:
Most of this patch was written by Dave Airlie ,
with some additions by me.
> From be1b73147c92a8f74e5cdf30e5325382a6f77799 Mon Sep 17 00:00:00 2001
> From: Lynne
> Date: Fri, 19 Jan 2024 10:49:02 +1000
> Subject: [PATCH v3 2/2] lavc/vulkan_av1: port to the
On Sun, Feb 11, 2024 at 4:21 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Besides simplifying address computations (it saves 432B of .text
> in hevcdsp.o alone here) it also fixes undefined behaviour that
>
We can save more if we change
void (*put_hevc_epel[10][2][2])(int16_t
I generated a DXV2 file with an interesting alpha channel using
Adobe Media Encoder 2015 and compared decoding it using Resolume Alley
and ffmpeg. Similarly to DXV3 files, Alley expects premultiplied alpha
and ffmpeg matches its decoding more closely when it does the same.
Reference file:
On Sun, Feb 11, 2024 at 4:21 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Besides simplifying address computations (it saves 432B of .text
> in hevcdsp.o alone here) it also fixes undefined behaviour that
> occurs if mx or my are 0 (happens when the filters are unused)
>
On Sun, Feb 11, 2024 at 5:00 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Nuo Mi:
> > It's a false positive. We use -1 to index an array, but it's not
> actually used.
> > This patch will make the "GCC UndefinedBehaviorSanitizer" happy.
> >
> > Found by: checkasm-hevc_pel in
>
It is unused for decoders.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cri.c | 1 -
libavcodec/tdsc.c | 1 -
libavcodec/tiff.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/libavcodec/cri.c b/libavcodec/cri.c
index 0380a0c665..c4eb468610 100644
--- a/libavcodec/cri.c
+++
Akihiko Odaki:
> noopenh264 is a "fake implementation of the OpenH264 library we can link
> from regardless of the actual library being available":
> https://gitlab.com/freedesktop-sdk/noopenh264
>
> A distributor may wish to link against openh264/noopenh264 and let
> the decoder and encoder work
Removed in 704017d91ec8fbade0de072d222018c1a6013b70.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avformat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 5d0fe82250..1e98970b89 100644
--- a/libavformat/avformat.h
Connor Worley:
> Signed-off-by: Connor Worley
> ---
> libavcodec/dxv.c | 53
> 1 file changed, 9 insertions(+), 44 deletions(-)
>
> diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
> index cd78de3e0d..82c493f1de 100644
> --- a/libavcodec/dxv.c
>
Nuo Mi:
> It's a false positive. We use -1 to index an array, but it's not actually
> used.
> This patch will make the "GCC UndefinedBehaviorSanitizer" happy.
>
> Found by: checkasm-hevc_pel in
> https://fate.ffmpeg.org/report.cgi?time=20240211011905=x86_64-archlinux-gcc-ubsan
> Reported-by:
Besides simplifying address computations (it saves 432B of .text
in hevcdsp.o alone here) it also fixes undefined behaviour that
occurs if mx or my are 0 (happens when the filters are unused)
because they lead to an array index of -1 in the old code.
This happens in the checkasm-hevc_pel
93 matches
Mail list logo
