Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
index f520e72fc0..49b0d4b956 100644
--- a/libavcodec/ac3enc.c
+++ b/libavcodec/ac3enc.c
@@ -1942,7 +1942,7 @@
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/h264_slice.c | 1 -
> libavcodec/h264dec.h| 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 4b01c54147..f61af0d6d7 100644
> ---
Andreas Rheinhardt:
> Fixes ticket #10952.
>
> Discovered by: Zeng Yunxiang
> Signed-off-by: Andreas Rheinhardt
> ---
> I am pretty sure that a lot of other encoders don't handle this well
> either. Maybe we should handle this more generically in
> ff_encode_preinit?
>
>
On 4/7/2024 7:26 PM, Andreas Rheinhardt wrote:
James Almer:
On 4/7/2024 6:53 PM, Andreas Rheinhardt wrote:
James Almer:
On 4/7/2024 5:39 PM, Andreas Rheinhardt wrote:
It is perfectly legal for users to use a custom layout
that is equivalent to a supported native one.
Is that really the
Andreas Rheinhardt:
> current_picture is not changed after frame_start() at all
> and it therefore does not need to be updated (i.e. copied to the
> slice thread contexts) a second time.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/mpegvideo_enc.c | 1 -
> 1 file changed, 1
James Almer:
> On 4/7/2024 6:53 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 4/7/2024 5:39 PM, Andreas Rheinhardt wrote:
It is perfectly legal for users to use a custom layout
that is equivalent to a supported native one.
>>>
>>> Is that really the case? FFCodec.p.ch_layouts[]
On 4/7/2024 6:53 PM, Andreas Rheinhardt wrote:
James Almer:
On 4/7/2024 5:39 PM, Andreas Rheinhardt wrote:
It is perfectly legal for users to use a custom layout
that is equivalent to a supported native one.
Is that really the case? FFCodec.p.ch_layouts[] has a list of native
ones, and the
James Almer:
> On 4/7/2024 5:39 PM, Andreas Rheinhardt wrote:
>> It is perfectly legal for users to use a custom layout
>> that is equivalent to a supported native one.
>
> Is that really the case? FFCodec.p.ch_layouts[] has a list of native
> ones, and the generic encode.c code will reject
Implicitly disabled by 4679a474f06c229b10976d7f0b4eee0613c2715a.
Given that no one has ever complained about this, this commit
removes the now dead code.
Signed-off-by: Andreas Rheinhardt
---
doc/encoders.texi| 3 +--
libavcodec/ac3enc.c | 43 +--
The strings here are so short that using a pointer is wasteful
(the longest string takes nine bytes; on 64 bit systems,
the pointer+padding already take 12 bytes). So avoid them
and add asserts to ensure that no one ever tries to use a too
long tag.
Signed-off-by: Andreas Rheinhardt
---
Signed-off-by: Andreas Rheinhardt
---
libavcodec/flacenc.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index e29be5822b..3a9578f5cd 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -525,11 +525,10 @@
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 8 +---
libavcodec/eac3enc.c | 26 ++
libavcodec/eac3enc.h | 10 --
3 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
index
AVERROR(ENOMEM) is enough.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc_float.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavcodec/ac3enc_float.c b/libavcodec/ac3enc_float.c
index 77a7725f31..cbe87dc5fe 100644
--- a/libavcodec/ac3enc_float.c
+++
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 4
libavcodec/ac3enc.h | 3 ---
libavcodec/ac3enc_fixed.c | 12 +---
libavcodec/ac3enc_float.c | 7 ++-
4 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/libavcodec/ac3enc.c
These memcpy operands only depend upon sizeof(SampleType)
(and this size is actually the same for both the fixed-point
and the floating-point encoders for most (all supported?)
systems).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 25 -
encode_preinit_audio() already checks that the sample rate
is among AVCodec.supported_samplerates.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
index 272d2481d9..32aaf89ec1 100644
---
These allocations only depend upon sizeof(SampleType)
(and this size is actually the same for both the fixed-point
and the floating-point encoders for most (all supported?)
systems).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 16 +++-
libavcodec/ac3enc.h
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 19 +--
libavcodec/ac3enc.h | 5 +
libavcodec/ac3enc_template.c | 15 +--
3 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
Will avoid a forward declaration in the next commit.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 420 ++--
1 file changed, 209 insertions(+), 211 deletions(-)
diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
index
This is in preparation for sharing even more stuff
common to the fixed and floating-point encoders.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 8 ++--
libavcodec/ac3enc.h | 16 +---
libavcodec/ac3enc_fixed.c| 3 ++-
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 88 +
1 file changed, 50 insertions(+), 38 deletions(-)
diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
index 31b9474822..272d2481d9 100644
--- a/libavcodec/ac3enc.c
+++
Simply masking the LFE bit is more natural than subtracting
if set.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
index 1a65e35161..31b9474822 100644
---
These are all checked generically via AVCodec.ch_layouts
in encode_preinit_audio().
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 23 ++-
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/libavcodec/ac3enc.c b/libavcodec/ac3enc.c
index
This is unnecessary (the channel layout guessing code became
moot when the channel layouts were enforced generically)
and also dangerous, as a custom channel layout mapping
would leak in case one was used.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 3 ---
1 file changed, 3
On 4/7/2024 5:39 PM, Andreas Rheinhardt wrote:
It is perfectly legal for users to use a custom layout
that is equivalent to a supported native one.
Is that really the case? FFCodec.p.ch_layouts[] has a list of native
ones, and the generic encode.c code will reject anything not in it.
I
It is perfectly legal for users to use a custom layout
that is equivalent to a supported native one.
In this case the union in AVChannelLayout is not an uint64_t mask,
but a pointer to a custom map.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ac3enc.c | 6 +-
1 file changed, 1
On 4/7/2024 10:38 AM, Nuo Mi wrote:
On Sun, Apr 7, 2024 at 11:05 AM James Almer wrote:
Signed-off-by: James Almer
---
libavcodec/vvc/ps.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index 3c71c34bae..83ee75fb62 100644
---
Le dim. 7 avr. 2024 à 05:44, Steven Liu a écrit :
> Romain Beauxis 于2024年3月26日周二 08:58写道：
> >
> > This patch adds support for updating HLS metadata passed as ID3 frames.
> >
> > This seems like a pretty straight-forward improvement. Updating the
> > metadaata of the first stream seems to be the
---
libavcodec/vulkan_av1.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vulkan_av1.c b/libavcodec/vulkan_av1.c
index c9e398eaec..8cca97c005 100644
--- a/libavcodec/vulkan_av1.c
+++ b/libavcodec/vulkan_av1.c
@@ -242,7 +242,6 @@ static int
This is needed by Vulkan. Constructing this can't be delegated to CBS
because packets might contain multiple frames (when non-shown frames are
present) but we need separate snapshots immediately before each frame
for the decoder.
---
libavcodec/av1dec.c | 26 ++
On Sun, Apr 7, 2024 at 11:05 AM James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/vvc/ps.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
> index 3c71c34bae..83ee75fb62 100644
> --- a/libavcodec/vvc/ps.c
> +++
Henrik Gramner via ffmpeg-devel wrote on 07.04.2024 at 17:32:
> I believe most existing code uses WINAPI instead of __stdcall.
Thanks for correction. Here is a new patch:
diff --git a/libavfilter/vsrc_ddagrab.c b/libavfilter/vsrc_ddagrab.c
--- a/libavfilter/vsrc_ddagrab.c
+++
On Sun, Apr 7, 2024 at 8:16 PM Anton Khirnov wrote:
> Quoting Nuo Mi (2024-04-07 14:13:58)
> > On Sun, Apr 7, 2024 at 2:15 PM Anton Khirnov wrote:
> >
> > > Quoting Frank Plowman (2024-04-06 15:46:09)
> > > > Key line from the spec is:
> > > >
> > > > "All SPS NAL units with a particular value
Quoting Nuo Mi (2024-04-07 14:13:58)
> On Sun, Apr 7, 2024 at 2:15 PM Anton Khirnov wrote:
>
> > Quoting Frank Plowman (2024-04-06 15:46:09)
> > > Key line from the spec is:
> > >
> > > "All SPS NAL units with a particular value of sps_seq_parameter_set_id
> > > in a CVS shall have the same
On Sun, Apr 7, 2024 at 2:15 PM Anton Khirnov wrote:
> Quoting Frank Plowman (2024-04-06 15:46:09)
> > Key line from the spec is:
> >
> > "All SPS NAL units with a particular value of sps_seq_parameter_set_id
> > in a CVS shall have the same content."
> >
> > Prior to this patch, the VVC
Quoting Michael Niedermayer (2024-04-07 01:16:39)
> On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > This replaces the myriad of existing lists in AVCodec by a unified API
> > call, allowing us to (ultimately) trim down the sizeof(AVCodec) quite
> >
Romain Beauxis 于2024年3月26日周二 08:58写道：
>
> This patch adds support for updating HLS metadata passed as ID3 frames.
>
> This seems like a pretty straight-forward improvement. Updating the
> metadaata of the first stream seems to be the mechanism is other places
> in the code and works as expected.
On Sun, Apr 7, 2024 at 2:59 AM Vadim Guchenko wrote:
> +typedef DPI_AWARENESS_CONTEXT (__stdcall
> *set_thread_dpi_t)(DPI_AWARENESS_CONTEXT);
I believe most existing code uses WINAPI instead of __stdcall.
___
ffmpeg-devel mailing list
> On Apr 7, 2024, at 14:16, Anton Khirnov wrote:
>
> Quoting Andreas Rheinhardt (2024-04-06 13:25:49)
>> See https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/320849.html
>> Additionally I do not agree that sorting options by name is the best
>> way; it should be sorted by what are
Quoting Andreas Rheinhardt (2024-04-06 13:25:49)
> See https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/320849.html
> Additionally I do not agree that sorting options by name is the best
> way; it should be sorted by what are (believed to be) the most commonly
> used options.
+1
--
Anton
Quoting Frank Plowman (2024-04-06 15:46:09)
> Key line from the spec is:
>
> "All SPS NAL units with a particular value of sps_seq_parameter_set_id
> in a CVS shall have the same content."
>
> Prior to this patch, the VVC decoder's behaviour on encountering a
> duplicated SPS ID (within the
41 matches
Mail list logo
