Can confirm this fixes the build on my Mac.
--
Connor Worley
___
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
On Mon, 5 Feb 2024, Connor Worley wrote:
Can confirm this fixes the build on my Mac.
Thanks, will apply.
Regards,
Marton
--
Connor Worley
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Connor Worley:
> Offers a modest performance gain due to the switch from naive linear
> probling to robin hood.
How much would one gain if the hash function knew that key_size and
val_size are four?
>
> Signed-off-by: Connor Worley
> ---
> libavcodec/dxvenc.c | 121
From: Zhao Zhili
---
libavcodec/audiotoolboxenc.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 35dd4c553d..392e3fa11a 100644
--- a/libavcodec/audiotoolboxenc.c
+++
> 发件人: ffmpeg-devel 代表 Andreas Rheinhardt
>
> 发送时间: 2024年2月5日 4:06
> 收件人: ffmpeg-devel@ffmpeg.org
> 主题: Re: [FFmpeg-devel] [PATCH] avcodec/x86/vvc/vvcdsp_init: fix unresolved
> external symbol on ARCH_X86_32
>
> toq...@outlook.com:
>> From: Wu Jianhua
>>
>> Signed-off-by: Wu Jianhua
>> ---
On Wed, 31 Jan 2024 12:47:59 +0100 "Diederick C. Niehorster"
wrote:
> On Wed, Jan 31, 2024 at 12:17 PM Niklas Haas wrote:
> >
> > From: Niklas Haas
> >
> > diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> > index fe7e6ace27..37110bc32f 100644
> > ---
> On Feb 5, 2024, at 18:21, Michael Niedermayer wrote:
>
> On Wed, Jan 31, 2024 at 09:55:00PM +, Kieran Kunhya wrote:
>> On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis
>> wrote:
>>
>>> On 1/30/2024 1:48 AM, Michael Niedermayer wrote:
> 发件人: ffmpeg-devel 代表
> tong1.wu-at-intel@ffmpeg.org
> 发送时间: 2024年2月2日 2:16
> 收件人: ffmpeg-devel@ffmpeg.org
> 抄送: Tong Wu
> 主题: [FFmpeg-devel] [PATCH v3 8/9] avcodec: add D3D12VA hardware HEVC encoder
>
> From: Tong Wu
>
> This implementation is based on D3D12 Video Encoding Spec:
>
On Mon, Feb 05, 2024 at 11:35:54AM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: CID 1403229 Dereference after null check
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavfilter/signature_lookup.c | 25 ++---
> > 1 file changed, 14
> Either way, iam interrested in helping with coverity work while
> at the same time this environment where peole finger point and say
> "is way too much" is something i dont feel comfortable to work in.
>
So you make an RFC but you only want comments that agree with you?
> maybe doing it per
toq...@outlook.com:
> From: Wu Jianhua
>
> Signed-off-by: Wu Jianhua
> ---
> libavcodec/x86/vvc/vvcdsp_init.c | 78
> 1 file changed, 40 insertions(+), 38 deletions(-)
>
> diff --git a/libavcodec/x86/vvc/vvcdsp_init.c
> b/libavcodec/x86/vvc/vvcdsp_init.c
>
From: Wu Jianhua
Signed-off-by: Wu Jianhua
---
libavcodec/x86/vvc/vvcdsp_init.c | 78
1 file changed, 40 insertions(+), 38 deletions(-)
diff --git a/libavcodec/x86/vvc/vvcdsp_init.c b/libavcodec/x86/vvc/vvcdsp_init.c
index 909ef9f56b..8ee4074350 100644
---
Stefano Sabatini:
> On date Sunday 2024-02-04 18:36:45 +0100, Andreas Rheinhardt wrote:
>> This can be achieved by using AV_OPT_TYPE_FLAGS instead of
>> AV_OPT_TYPE_STRING. It also avoids strcmp() when accessing
>> the option.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavdevice/caca.c
On Wed, Jan 31, 2024 at 09:55:00PM +, Kieran Kunhya wrote:
> On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis
> wrote:
>
> > On 1/30/2024 1:48 AM, Michael Niedermayer wrote:
> > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
> >
> > Not to derail this fine thread, but what forks
Marth64:
> matroskaenc options table has grown packed over time, and is now challenging
> to read. The purpose of this patch is to reformat the table, indentation-wise,
> and to make the capitalization/endings of each description at least
> consistent.
>
> I intend to sort the options in a
Michael Niedermayer:
> Fixes: CID 1403229 Dereference after null check
>
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/signature_lookup.c | 25 ++---
> 1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/libavfilter/signature_lookup.c
Signed-off-by: Michael Niedermayer
---
libavfilter/signature_lookup.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index 86dd0c66754..52a97e1bc7e 100644
---
Fixes: CID 1403229 Dereference after null check
Signed-off-by: Michael Niedermayer
---
libavfilter/signature_lookup.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index 52a97e1bc7e..0c724456e24 100644
---
Michael Niedermayer:
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/signature_lookup.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
> index 86dd0c66754..52a97e1bc7e
Connor Worley:
> Signed-off-by: Connor Worley
> ---
> libavutil/Makefile | 2 +
> libavutil/hashtable.c | 172
> libavutil/hashtable.h | 62 +
> libavutil/tests/hashtable.c | 104 ++
> 4 files changed,
From: Zhao Zhili
---
libavcodec/audiotoolboxenc.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 35dd4c553d..08cd3d5d27 100644
--- a/libavcodec/audiotoolboxenc.c
+++
From: Zhao Zhili
AV_CODEC_CAP_VARIABLE_FRAME_SIZE has been set for alac_at encoder,
which means avctx->frame_size should be zero. However, alac_at
encoder also set avctx->frame_size. This leading to assert failure
in ffmpeg_sched.c
av_assert0(enc->sq_idx[0] >= 0);
Actually, the
On Sun, Feb 4, 2024 at 1:22 AM wrote:
> From: Frank Plowman
>
> Fixes crashes when decoding illegal bitstreams found by fuzzing.
>
> Signed-off-by: Frank Plowman
> ---
> libavcodec/vvc/vvc_ctu.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git
the problem is the very last packet
can be shorter than default packet_size
so it's required to exclude it from
packet_size calculations.
fixes #10465
---
libavformat/cafenc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavformat/cafenc.c b/libavformat/cafenc.c
James Almer:
> On 2/5/2024 1:18 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 2/5/2024 12:28 PM, Andreas Rheinhardt wrote:
James Almer:
> On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote:
> diff --git
It would make me happy if we could get this API addition in before 7.0,
even though it's non-functional on its own, as it sets the groundwork to
be able to start properly deprecating YUVJ.
After this series, the next steps are:
1. Make decoders stop outputting YUVJ frames
2. Mark the actual YUVJ
From: Niklas Haas
An oversight in my previous series. This omission slipped under the
radar because fftools/ffmpeg_filter.c did not use these options, instead
preferring to insert an explicit format filter.
---
libavfilter/buffersink.c | 29 ++---
From: Niklas Haas
SDL supports only these three matrices. Actually, it only supports these
three combinations: BT.601+JPEG, BT.601+MPEG, BT.709+MPEG, but we have
no way to restrict the specific *combination* of YUV range and YUV
colorspace with the current filter design.
See-Also:
On Fri, 12 Jan 2024 22:10:46 +0100 Michael Niedermayer
wrote:
> On Fri, Jan 12, 2024 at 09:26:03AM +0100, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > The only meaningful difference between choose_pix_fmts and the default
> > code was the inclusion of an extra branch for `keep_pix_fmt`
From: Niklas Haas
I went through all codecs and put them into five basic categories:
1. JPEG range only
2. MPEG range only
3. Explicitly tagged
4. Broken (codec supports both but encoder ignores tags)
5. N/A (headerless or pseudo-formats)
Filters in category 5 remain untouched. The rest gain
From: Niklas Haas
This is motivated primarily by a desire for YUVJ removal, which will
require signalling the supported color ranges as part of the codec
capabilities. But since we're adding YUV range, we might as well add the
YUV color matrix as well - since some codecs (e.g. VP8, JPEG) only
From: Thilo Borgmann
---
libavcodec/webp.c | 142 +++---
1 file changed, 70 insertions(+), 72 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 4119ae679d..0931112546 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1358,7
From: Josef Zlomek
Adds the demuxer of animated WebP files.
It supports non-animated, animated, truncated, and concatenated files.
Reading from a pipe (and other non-seekable inputs) is also supported.
The WebP demuxer splits the input stream into packets containing one frame.
It also marks the
From: Thilo Borgmann
---
tests/fate/image.mak | 3 +++
tests/ref/fate/webp-anim | 22 ++
2 files changed, 25 insertions(+)
create mode 100644 tests/ref/fate/webp-anim
diff --git a/tests/fate/image.mak b/tests/fate/image.mak
index 400199c28a..2e0d1e8e3f 100644
---
From: Josef Zlomek
Fixes: 4907
Adds support for decoding of animated WebP.
The WebP decoder adds the animation related features according to the specs:
https://developers.google.com/speed/webp/docs/riff_container#animation
The frames of the animation may be smaller than the image canvas.
From: Thilo Borgmann
Still images fixed, includes FATE tests, VP8 decoder not decoupled, fixed more
asserts, fixed ffprobe regression, removed unnecessary parser changes, put the
whole animated sequence into one packet.
Patch 4/6 is still there for making changes in lavc/webp reviewable but
From: Thilo Borgmann
---
libavcodec/webp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 54b3fde6dc..4fd107aa0c 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -59,8 +59,6 @@
#define VP8X_FLAG_ALPHA 0x10
#define
On 05/02/2024 13:45, Nuo Mi wrote:
On Sun, Feb 4, 2024 at 1:22 AM wrote:
From: Frank Plowman
Fixes crashes when decoding illegal bitstreams found by fuzzing.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/vvc_ctu.c | 17 +++--
1 file changed, 15 insertions(+), 2
James Almer:
> On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote:
> diff --git a/libavformat/movenc.h b/libavformat/movenc.h
> index 60363198c9..fee3e759e0 100644
> --- a/libavformat/movenc.h
> +++
Replace it with recreating the codec context.
This is the last remaining blocker for deprecating avcodec_close().
---
Applied review comments.
---
libavformat/demux.c | 61 +
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git
This avoids assuming that it survives unchanged through bitstream
filters, if present.
---
fftools/ffmpeg_demux.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 60dc9620c2..3bf95e2c3f 100644
---
On 2/5/2024 2:06 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/5/2024 1:18 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/5/2024 12:28 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote:
From: Frank Plowman
If the number of CTUs reduces between one picture and the next, the
slice_idx table is reduced in size in the frame_context_for_each_tl call
on vvcdec.c:321. When initialising the slice_idx table on vvcdec.c:325,
the old code uses fc->tab.sz.ctu_count when calculating the
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
On Sat, Feb 3, 2024 at 6:35 PM Nuo Mi wrote:
> how to reproduce:
> wget https://media.xiph.org/video/derf/y4m/students_cif.y4m
> vvencapp --input students_cif.y4m --preset faster --output students.266
> MP4Box -add students.266:fps=3/1001:par=12:11 -new students.mp4
> ffplay students.mp4
sön 2024-02-04 klockan 23:25 -0300 skrev James Almer:
> On 2/3/2024 7:00 AM, Tomas Härdin wrote:
> > fre 2024-02-02 klockan 16:55 +0100 skrev Jerome Martinez:
> > > Before this patch, the FFmpeg MXF parser correctly detects
> > > content
> > > with
> > > 2 fields in 1 AVPacket as e.g. interlaced
From: Frank Plowman
Signed-off-by: Frank Plowman
---
libavcodec/vvc/vvc_ps.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
index 4ef8f9f9b9..9c4a74fc9c 100644
--- a/libavcodec/vvc/vvc_ps.c
+++
James Almer:
> On 2/5/2024 12:28 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote:
James Almer:
> On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote:
>>> diff --git a/libavformat/movenc.h b/libavformat/movenc.h
>>> index
From: Niklas Haas
Currently, this only affects untagged RGB/XYZ/Gray, which get forced to
their corresponding metadata before entering the filter graph. The main
justification for this change, however, is the planned ability to add
automatic promotion of unspecified yuv to mpeg range yuv.
From: Niklas Haas
Otherwise, passing an UNSPECIFIED frame to am MPEG-only filter graph
would trigger insertion of an unnecessary vf_scale filter, which would
perform a memcpy to convert between the two.
This is safe to do because unspecified YUV frames are already
universally assumed to be MPEG
On Mon, Feb 5, 2024 at 10:04 PM Frank Plowman wrote:
> On 05/02/2024 13:45, Nuo Mi wrote:
> > On Sun, Feb 4, 2024 at 1:22 AM wrote:
> >
> >> From: Frank Plowman
> >>
> >> Fixes crashes when decoding illegal bitstreams found by fuzzing.
> >>
> >> Signed-off-by: Frank Plowman
> >> ---
> >>
On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote:
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index 60363198c9..fee3e759e0 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -25,7 +25,9 @@
#define AVFORMAT_MOVENC_H
#include "avformat.h"
+#include "iamf.h"
On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote:
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index 60363198c9..fee3e759e0 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -25,7 +25,9 @@
#define
On 2/5/2024 12:28 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote:
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index 60363198c9..fee3e759e0 100644
--- a/libavformat/movenc.h
On 2/5/2024 1:18 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/5/2024 12:28 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote:
James Almer:
On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote:
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
Clear and consistent formatting enhances code comprehension and reduces the
likelihood of misinterpretation or errors. As is now, it’s challenging to
read. But I digress
Thanks,
On Mon, Feb 5, 2024 at 06:19 Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Marth64:
> > matroskaenc
James Almer:
> On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote:
>>> diff --git a/libavformat/movenc.h b/libavformat/movenc.h
>>> index 60363198c9..fee3e759e0 100644
>>> --- a/libavformat/movenc.h
>>> +++ b/libavformat/movenc.h
>>> @@ -25,7 +25,9 @@
>>> #define AVFORMAT_MOVENC_H
>>> #include
On 03/02/2024 16:56, Nuo Mi wrote:
On Sat, Feb 3, 2024 at 11:51 PM Frank Plowman wrote:
On 03/02/2024 15:46, Nuo Mi wrote:
On Sat, Feb 3, 2024 at 9:54 PM Frank Plowman
wrote:
On 02/02/2024 14:39, Nuo Mi wrote:
On Thu, Feb 1, 2024 at 10:01 PM wrote:
From: Frank Plowman
Quoting Leo Izen (2024-02-03 03:35:45)
> On 2/1/24 03:29, Anton Khirnov wrote:
> > Replace it with recreating the codec context.
> >
> > This is the last remaining blocker for deprecating avcodec_close().
> > ---
> > libavformat/demux.c | 53 -
> > 1
VC-1 uses a 0x03 escaping scheme like H.26x and our decoder
unescapes data for this purpose, but hardware accelerations
just want the data as-is and therefore get fed the original
data. The pointers to the actual data are only setcorrectly
if avctx->hwaccel is set (after all, they are only used in
It is entirely unnecessary to use it given that all decoders
here share the same set of supported pixel formats. So just
hardcode this list.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mmaldec.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
Feb 4, 2024, 17:06 by s...@jkqxz.net:
> On 02/02/2024 02:57, Lynne wrote:
>
>> Needed for AV1.
>>
>> From 81be215060a718fdc3d043847e8155ba56fcb431 Mon Sep 17 00:00:00 2001
>> From: Lynne
>> Date: Fri, 2 Feb 2024 03:54:06 +0100
>> Subject: [PATCH 1/2] lavc/cbs_av1: fill in ref_frame_sign_bias
>>
It is currently called once in the codecs' init function
and once when (re)initializing the VC-1 decode context
(which happens upon frame size changes as well as before
decoding the first frame). The first one is unnecessary
now that vc1_decode_frame() no longer requires avctx->hwaccel
to be
They are not intended for decoders (for which there is the get_format
callback in case the user has a choice).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vc1dec.c | 64 -
1 file changed, 29 insertions(+), 35 deletions(-)
diff --git
They are not intended for decoders (for which there is the get_format
callback in case the user has a choice).
Also note that the list was wrong for MPEG4, because it did not contain
the high bit depth pixel formats used for studio profiles.
Signed-off-by: Andreas Rheinhardt
---
On Mon, Feb 05, 2024 at 12:51:57PM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavfilter/signature_lookup.c | 21 ++---
> > 1 file changed, 10 insertions(+), 11 deletions(-)
> >
> > diff --git
AVCodec.pix_fmts is only intended for encoders (decoders use
the get_format callback to let the user choose a pix fmt).
So remove them for the decoders for which this is possible
without further complications; keep them for now in the codecs
that actually use them (by passing
This is the courtesy reminder we've agreed on, to remember there's a week
left to finish the Scope of Work if FFmpeg wishes to deliver it by February
12th as requested by STF.
Att.,
Jonatas L. Nogueira (“Jesusalva”)
SPI Board of Directors
On Wed, Jan 31, 2024, 21:16 Stefano Sabatini wrote:
>
Hi all
As Jonatan reminded the ML we need to provide SoWs if we want to
participate in STF-SPI
We need one for each project (they do not need to list a person ATM)
but obviously we do need someone who will do the work
I do belive they do need to list the money amount.
Thanks go to Pierre for
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.
---
Now moving to C17 rather
From: James Almer
It is not available there, even when C11/17 is requested.
Signed-off-by: Anton Khirnov
---
libavcodec/refstruct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/refstruct.c b/libavcodec/refstruct.c
index 7597f6d0ee..81e8c9795c 100644
---
Connor Worley:
>>
>> How much would one gain if the hash function knew that key_size and
>> val_size are four?
>>
>
> That yields a nice 10-20% speedup on my machine. Are you thinking of macros
> to parametrize key/val size, or possibly optimized versions for common
> sizes?
I am thinking about
Feb 5, 2024, 20:59 by an...@khirnov.net:
> 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
>
Quoting Michael Niedermayer (2024-02-05 21:27:27)
> please wait a bit with applying this so we understand better what it affects
Sure, but I'd like it to go in before 7.0.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Quoting Devin Heitmueller (2024-02-05 21:13:22)
> 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 anonymous unions.
>
> Is everybody on board with the implications for this patch in
On Mon, Feb 5, 2024 at 3:31 PM Anton Khirnov wrote:
>
> Quoting Devin Heitmueller (2024-02-05 21:13:22)
> > 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 anonymous unions.
> >
>
On date Monday 2024-02-05 21:55:04 +0100, Niklas Haas wrote:
> On Mon, 05 Feb 2024 21:31:45 +0100 Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-02-05 21:27:27)
> > > please wait a bit with applying this so we understand better what it
> > > affects
> >
> > Sure, but I'd like it to
On date Monday 2024-02-05 08:32:04 -0600, Marth64 wrote:
> Clear and consistent formatting enhances code comprehension and reduces the
> likelihood of misinterpretation or errors. As is now, it’s challenging to
> read. But I digress
+1
> > I do not really see the point of this. It will just
>
> How much would one gain if the hash function knew that key_size and
> val_size are four?
>
That yields a nice 10-20% speedup on my machine. Are you thinking of macros
to parametrize key/val size, or possibly optimized versions for common
sizes?
--
Connor Worley
On Fri, Feb 02, 2024 at 03:45:24PM -0800, Dale Curtis wrote:
> On Fri, Feb 2, 2024 at 3:42 PM Dale Curtis wrote:
>
> > On Fri, Feb 2, 2024 at 3:20 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Dale Curtis:
> >> > +// Clamp allocation size for `chunk_offsets` --
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 anonymous unions.
Is everybody on board with the implications for this patch in terms of
platforms we allow building on? For example, the gcc
Quoting James Almer (2024-02-05 21:12:00)
> Does SunCC support this? Does anyone use SunCC at all?
I do not know, but if it doesn't then we can drop it.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Mon, Feb 05, 2024 at 09:31:45PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-05 21:27:27)
> > please wait a bit with applying this so we understand better what it affects
>
> Sure, but I'd like it to go in before 7.0.
This seems to break my stuff
I will upgarde my stuff
From: Cosmin Stejerean
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index 7546cf0caf..cbe6b3ff99 100644
--- a/.mailmap
+++ b/.mailmap
@@ -22,3 +22,4 @@ rcombs
+Cosmin Stejerean Cosmin Stejerean via ffmpeg-devel
--
2.42.1
On 2/5/2024 4:54 PM, Anton Khirnov wrote:
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
On 2/5/2024 5:30 PM, Anton Khirnov wrote:
Quoting Devin Heitmueller (2024-02-05 21:13:22)
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 anonymous unions.
Is everybody on board with the
On Mon, 05 Feb 2024 21:31:45 +0100 Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-05 21:27:27)
> > please wait a bit with applying this so we understand better what it affects
>
> Sure, but I'd like it to go in before 7.0.
What is the advantage to having it in 7.0?
On Mon, Feb 05, 2024 at 08:54:40PM +0100, Anton Khirnov wrote:
> 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
On Mon, Feb 5, 2024 at 12:06 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Connor Worley:
> >>
> >> How much would one gain if the hash function knew that key_size and
> >> val_size are four?
> >>
> >
> > That yields a nice 10-20% speedup on my machine. Are you thinking of
>
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 anonymous unions.
>
> Is everybody on board with the implications for
On Mon, Feb 5, 2024 at 3:58 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Connor Worley:
> > +memcpy(ctx->tmp_key, ctx->set_key, ctx->key_size);
> > +memcpy(ctx->tmp_val, ctx->set_val, ctx->val_size);
>
> Given that set_key/val are overwritten below,
On Mon, Feb 5, 2024 at 8:59 PM Anton Khirnov wrote:
> diff --git a/configure b/configure
> index f72533b7d2..1bb9e23f19 100755
> --- a/configure
> +++ b/configure
> @@ -5517,21 +5517,20 @@ if test "$?" != 0; then
> die "C compiler test failed."
> fi
>
> -add_cppflags -D_ISOC99_SOURCE
>
Hopefully, this is the last one.
- All prior documentation fixes and feedback addressed (AFAIK)
- Prevents demuxing of empty titles and informs the user
- Fixes does not add chapter markers if only one chapter
- Fixes logic for chapter selection on certain titles
Signed-off-by: Marth64
---
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
94 matches
Mail list logo
