Quoting Andreas Rheinhardt (2023-10-02 13:07:14)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2023-09-19 21:57:06)
> >> avcodec/hevcdec: Use RefStruct API for RefPicListTap buffer
> > ^
> > b
Quoting Andreas Rheinhardt (2023-09-19 21:57:09)
> Very similar to the AVBufferPool API, but with some differences:
> 1. Reusing an already existing entry does not incur an allocation
> at all any more (the AVBufferPool API needs to allocate an AVBufferRef).
> 2. The tasks done while holding the lo
Anton Khirnov:
> Quoting Andreas Rheinhardt (2023-09-19 21:57:09)
>> Very similar to the AVBufferPool API, but with some differences:
>> 1. Reusing an already existing entry does not incur an allocation
>> at all any more (the AVBufferPool API needs to allocate an AVBufferRef).
>> 2. The tasks done
Changes since the previous version:
- Zeroed padding to side data allocated by av_packet_side_data_new() (Patch 1).
- Renamed AVCodecParameters.{nb,}side_data to {nb,}coded_side_data, to both
match the name in AVCodecContext and keep the side_data name free for future
use (Patch 2).
- Rewritten
Handling AVPacketSideData directly, which can used on structs other than
AVPacket.
This will be useful in the following commits.
Signed-off-by: James Almer
---
libavcodec/avpacket.c | 101 ++
libavcodec/packet.h | 96
This will simplify the propagation of side data to decoders and from encoders.
Global side data will now reside in the AVCodecContext, thus be available
during init(), removing the need to propagate it inside packets.
Global and frame specific side data will therefore be distinct.
Signed-off-by:
Explaining what or who may use it, and in what scenarios.
Signed-off-by: James Almer
---
libavcodec/packet.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index 96fc0084d6..85b3eeb728 100644
--- a/libavcodec/packet.h
+++ b/liba
Deprecate AVStream.side_data and its helpers in favor of the AVStream's
codecpar.side_data.
This will considerably simplify the propagation of global side data to decoders
and from encoders. Instead of having to do it inside packets, it will be
available during init().
Global and frame specific si
Signed-off-by: James Almer
---
fftools/ffmpeg_demux.c| 13 +
fftools/ffmpeg_enc.c | 32 ++--
fftools/ffmpeg_filter.c | 7 ++-
fftools/ffmpeg_mux_init.c | 24 ++--
4 files changed, 39 insertions(+), 37 deletions(-)
diff -
Signed-off-by: James Almer
---
fftools/ffplay.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 006da7ab57..f5354575c9 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1916,8 +1916,13 @@ static int configure_video_filt
Signed-off-by: James Almer
---
fftools/ffprobe.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index c20f464623..dc3250e3a2 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2279,16 +2279,9 @@ st
This is no longer needed as the side data is available for decoders in the
AVCodecContext.
The tests affected reflect the removal of useless CPB and Stereo 3D side
data in packets.
Signed-off-by: James Almer
---
fftools/ffmpeg_demux.c| 22 ---
tests/ref/fa
The changed references for fate-hevc-dv-rpu fate-mov-zombie happen because,
unlike ffmpeg and ffplay, ffprobe never injected packet side data, so the
display matrix side data at the container level is now present in the output
frames.
Signed-off-by: James Almer
---
libavcodec/decode.c|
This is no longer needed as the side data is available for decoders in the
AVCodecContext.
Signed-off-by: James Almer
---
fftools/ffplay.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index f5354575c9..d8c69e10bc 100644
--- a/fftools/ffplay.c
+++ b/fft
Signed-off-by: James Almer
---
libavcodec/avcodec.h | 2 +-
libavcodec/decode.c | 10 ++
libavcodec/decode.h | 6 ++
libavcodec/hevcdec.c | 15 ++-
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 09400b9
Quoting Andreas Rheinhardt (2023-09-19 21:57:10)
> It involves less allocations and therefore has the nice property
> that deriving a reference from a reference can't fail.
> This allows for considerable simplifications in
> ff_h264_(ref|replace)_picture().
> Switching to the RefStruct API also all
Quoting Andreas Rheinhardt (2023-09-19 21:57:11)
> It involves less allocations and therefore has the nice property
> that deriving a reference from a reference can't fail,
> simplifying hevc_ref_frame().
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/hevc_refs.c | 16 ++--
Hi Kieran
i didnt really want to get drawn into this discussion but there is one
point i have to make
On Tue, Oct 03, 2023 at 08:29:23PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> On Tue, Oct 3, 2023 at 7:50 PM Nicolas George wrote:
> > More precisely, I now strongly believe that democracy i
Quoting Andreas Rheinhardt (2023-09-19 21:57:12)
> It involves less allocations, in particular no allocations
> after the entry has been created. Therefore creating a new
> reference from an existing one can't fail and therefore
> need not be checked. It also avoids indirections and casts.
>
> Als
Quoting James Almer (2023-10-04 05:22:38)
>
> Actually, both tests use ffprobe, which never injected stream side data
> into packets before this set, so the ffmpeg code removed in 10/11 makes
> no difference.
>
> Adding DISPLAYMATRIX to the global map here will still mean ffmpeg.c
> will pass
Quoting James Almer (2023-10-04 14:28:42)
> Explaining what or who may use it, and in what scenarios.
>
> Signed-off-by: James Almer
> ---
> libavcodec/packet.h | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/libavcodec/packet.h b/libavcodec/packet.h
> index 96fc00
Quoting James Almer (2023-10-04 14:28:38)
> Changes since the previous version:
> - Zeroed padding to side data allocated by av_packet_side_data_new() (Patch
> 1).
> - Renamed AVCodecParameters.{nb,}side_data to {nb,}coded_side_data, to both
> match the name in AVCodecContext and keep the side_d
Quoting Michael Niedermayer (2023-09-27 20:03:12)
> > again IMO any change to what SW we use needs more discussion than a
> > "who likes gitlab, who likes gitwhatever" vote
>
> I think its very important that we do not loose independance and run
> our own infrastructure.
>
> That said.
>
> I thi
Quoting Michael Niedermayer (2023-10-04 16:23:12)
> Hi Kieran
>
> i didnt really want to get drawn into this discussion but there is one
> point i have to make
>
> On Tue, Oct 03, 2023 at 08:29:23PM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> > On Tue, Oct 3, 2023 at 7:50 PM Nicolas George
Le keskiviikkona 4. lokakuuta 2023, 17.23.12 EEST Michael Niedermayer a écrit
:
> > Why are you part of a community project if you don't believe the
> > community is capable of running a project?
>
> Questioning why some developer is part of FFmpeg is IMHO a violation of
> the Code of Conduct. No
Quoting Michael Niedermayer (2023-10-03 21:22:58)
> On Tue, Sep 26, 2023 at 08:14:37PM +0200, Anton Khirnov wrote:
> > You keep framing this as some kind of a personal campaign against you.
> > It is not. From my perspective, the objections to SDR have been largely
> > technical, and most of the "h
They are similar to AVIF images (both use the HEIF container).
The only additional work needed is to parse the hvcC box and put
it in the extradata.
With this patch applied, ffmpeg (when built with an HEVC decoder)
is able to decode the files in
https://github.com/nokiatech/heif/tree/gh-pages/cont
This discussion has drifted far away from any topic set upfront.
It's gotten to the point where there's no way for anyone outside
to join and give their own opinion, as it's not possible to know the
entire discussion that's happened up to this point.
Hence, spin this off in multiple threads. Mayb
On Mon, Oct 02, 2023 at 10:56:20PM -0300, James Almer wrote:
> On 10/2/2023 7:23 PM, Michael Niedermayer wrote:
> > Hi
> >
> > On Tue, Sep 05, 2023 at 09:25:45PM +, Paul B Mahol wrote:
> > > ffmpeg | branch: master | Paul B Mahol | Tue Sep 5
> > > 23:14:58 2023 +0200| [d464a687c9dd03246795d
Hi,
On Tue, Oct 3, 2023 at 6:53 PM Vignesh Venkatasubramanian via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> SVT-AV1 does not support requesting keyframes at arbitrary points
> by setting pic_type to EB_AV1_KEY_PICTURE. So set force_key_frames
> to 1 only when gop_size == 1.
>
> Please see
On Tue, Oct 03, 2023 at 06:04:03PM +0200, Andreas Rheinhardt wrote:
> These flags will be overwritten later in ff_mpv_frame_start().
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/h261dec.c | 7 ---
> libavcodec/mpeg12dec.c | 10 --
> libavcodec/vc1dec.c| 7 ---
On Tue, Oct 03, 2023 at 06:04:02PM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/rv10.c | 21 +
> 1 file changed, 5 insertions(+), 16 deletions(-)
ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
On Tue, Oct 03, 2023 at 06:04:01PM +0200, Andreas Rheinhardt wrote:
> Dead since 248a1aa54c08b14e8bd49147f59d954c41b5b3a3.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/rv10.c | 3 ---
> 1 file changed, 3 deletions(-)
ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF
On Wed, Oct 04, 2023 at 05:19:17PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-10-03 21:22:58)
> > On Tue, Sep 26, 2023 at 08:14:37PM +0200, Anton Khirnov wrote:
> > > You keep framing this as some kind of a personal campaign against you.
> > > It is not. From my perspective, th
The gather index vector is only used as double-length (due to register
pressure), so no need to initialise it for quad-length. Basically this
matches the multiplier in the prologue to the the multipler in the loop.
---
libavutil/riscv/float_dsp_rvv.S | 2 +-
1 file changed, 1 insertion(+), 1 delet
On 10/4/2023 2:22 PM, Michael Niedermayer wrote:
On Mon, Oct 02, 2023 at 10:56:20PM -0300, James Almer wrote:
On 10/2/2023 7:23 PM, Michael Niedermayer wrote:
Hi
On Tue, Sep 05, 2023 at 09:25:45PM +, Paul B Mahol wrote:
ffmpeg | branch: master | Paul B Mahol | Tue Sep 5 23:14:58
2023 +
vector_fmul_add_fixed_c: 2.2
vector_fmul_add_fixed_rvv_i64: 0.5
---
libavutil/riscv/fixed_dsp_init.c | 5 +
libavutil/riscv/fixed_dsp_rvv.S | 21 +
2 files changed, 26 insertions(+)
diff --git a/libavutil/riscv/fixed_dsp_init.c b/libavutil/riscv/fixed_dsp_init.c
index 40
---
libavutil/riscv/fixed_dsp_init.c | 3 +++
libavutil/riscv/fixed_dsp_rvv.S | 24
2 files changed, 27 insertions(+)
diff --git a/libavutil/riscv/fixed_dsp_init.c b/libavutil/riscv/fixed_dsp_init.c
index 4b239829f5..470b35fb63 100644
--- a/libavutil/riscv/fixed_dsp_ini
vector_fmul_fixed_c: 4.0
vector_fmul_fixed_rvv_i64: 0.5
---
libavutil/riscv/fixed_dsp_init.c | 3 +++
libavutil/riscv/fixed_dsp_rvv.S | 17 +
2 files changed, 20 insertions(+)
diff --git a/libavutil/riscv/fixed_dsp_init.c b/libavutil/riscv/fixed_dsp_init.c
index 470b35fb63..0288
---
libavutil/riscv/fixed_dsp_init.c | 6 +
libavutil/riscv/fixed_dsp_rvv.S | 44
2 files changed, 50 insertions(+)
diff --git a/libavutil/riscv/fixed_dsp_init.c b/libavutil/riscv/fixed_dsp_init.c
index 02883b31d4..6469b45374 100644
--- a/libavutil/riscv/fix
On Wed, Oct 4, 2023 at 10:23 AM Ronald S. Bultje wrote:
>
> Hi,
>
> On Tue, Oct 3, 2023 at 6:53 PM Vignesh Venkatasubramanian via ffmpeg-devel
> wrote:
>>
>> SVT-AV1 does not support requesting keyframes at arbitrary points
>> by setting pic_type to EB_AV1_KEY_PICTURE. So set force_key_frames
>>
On 10/3/23 11:00, Leo Izen wrote:
The spec caps the prefix alphabet size to 32768 (i.e. 1 << 15) so we
should check for that and reject alphabets that are too large, in order
to prevent over-allocating.
Additionally, there's no need to allocate buffers that are as large as
the maximum alphabet s
On 10/3/23 13:38, Leo Izen wrote:
This patch will cause the parser to abort if it detects an icc profile
with an invalid size. This is particularly important if the icc profile
is entropy-encoded with zero bits per symbol, as it can prevent a
seemingly infinite loop during parsing.
Fixes: inf
Fixes: left shift of negative value -538967841
Fixes:
62447/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6427134337613824
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/j
Fixes: out of array access
Fixes:
62467/clusterfuzz-testcase-minimized-ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-6092990982258688
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/evc_parse.c | 8 ++
The use of float based functions is both unneeded and wrong due to
unpredictable rounding
Signed-off-by: Michael Niedermayer
---
libavcodec/evc_parse.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c
index 5ab33166cf
The check is based on not infinite looping. It is likely
a more strict check can be done
Fixes: Infinite loop
Fixes:
62473/clusterfuzz-testcase-minimized-ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-5719883750703104
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projec
Oct 3, 2023, 18:39 by andreas.rheinha...@outlook.com:
> Lynne:
>
>> The FFmpeg encoder will be modified to also output 2048 samples of
>> padding at the start, to make it in line with other encoders.
>>
>
> Once again: What is the advantage? Doing what lots of other codecs do is
> not a real advan
48 matches
Mail list logo
