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 @@ s
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
> --- a/libavcodec/h264_slice
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?
>
> libavcodec/mpegvideo_en
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 case
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 deletion(
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[] has
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 ge
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 anythi
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 +--
li
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
---
libavfor
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 @@ stati
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 8ad89b6a84..f520e7
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
+++ b/libavc
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 b/libavcodec/ac3
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 -
libavcodec
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
--- a/
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
index
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 c19837e88f..1f05436
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 ++-
libavcodec/ac3enc_float
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
+++ b/libavcodec/ac
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
--- a/libavcodec/ac3e
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 f6456b2a22..1
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 delet
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 guess
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 insertion
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
--- a/libavcodec/vvc/p
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 vk_av1_start_frame(
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 ++
libavcode
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
> +++ b/libavcodec/vvc
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
+++ b/libavfilter/vsrc_
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 o
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 conte
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 decoder's
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
> > subst
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
ffmpeg-devel@
> 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 (belie
39 matches
Mail list logo
