Re: [FFmpeg-devel] [PATCH v3] avformat/mov: add interleaved_read option
> On Sep 14, 2023, at 09:41, Steven Liu wrote:
>
> Zhao Zhili 于2023年9月12日周二 01:10写道：
>>
>> From: Zhao Zhili
>>
>> For bad interleaved files, manually interleave multiple tracks at the
>> demuxer level can trigger seeking back and forth, which can be
>> dramatically slow depending on the protocol. Demuxer level interleave
>> can be useless sometimes, e.g., reading mp4 via http and then
>> transcoding/remux to DASH. Disable this option when you don't need the
>> demuxer level interleave, and want to avoid the IO penalizes.
>>
>> Co-authored-by: Derek Buitenhuis
>> Signed-off-by: Zhao Zhili
>> ---
>> v3: update doc
>> v2: rename option
>>
>> This issue is well known. Two samples can be found at here
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2022-December/304951.html
>>
>> doc/demuxers.texi | 7 +++
>> libavformat/isom.h| 1 +
>> libavformat/mov.c | 5 -
>> libavformat/version.h | 2 +-
>> 4 files changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
>> index 2d33b47a56..ca1563abb0 100644
>> --- a/doc/demuxers.texi
>> +++ b/doc/demuxers.texi
>> @@ -779,6 +779,13 @@ cast to int32 are used to adjust onward dts.
>>
>> Unit is the track time scale. Range is 0 to UINT_MAX. Default is
>> @code{UINT_MAX - 48000*10} which allows upto
>> a 10 second dts correction for 48 kHz audio streams while accommodating
>> 99.9% of @code{uint32} range.
>> +
>> +@item interleaved_read
>> +Interleave packets from multiple tracks at demuxer level. For badly
>> interleaved files, this prevents playback issues
>> +caused by large gaps between packets in different tracks, as MOV/MP4 do not
>> have packet placement requirements.
>> +However, this can cause excessive seeking on very badly interleaved files,
>> due to seeking between tracks, so disabling
>> +it may prevent I/O issues, at the expense of playback.
>> +
>> @end table
>>
>> @subsection Audible AAX
>> diff --git a/libavformat/isom.h b/libavformat/isom.h
>> index 4b1cd42f0f..3d375d7a46 100644
>> --- a/libavformat/isom.h
>> +++ b/libavformat/isom.h
>> @@ -327,6 +327,7 @@ typedef struct MOVContext {
>> int64_t extent_offset;
>> } *avif_info;
>> int avif_info_size;
>> +int interleaved_read;
>> } MOVContext;
>>
>> int ff_mp4_read_descr_len(AVIOContext *pb);
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index aa1d9e4ccc..8ad5f0b646 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -8780,6 +8780,8 @@ static AVIndexEntry
>> *mov_find_next_sample(AVFormatContext *s, AVStream **st)
>> AVIndexEntry *sample = NULL;
>> int64_t best_dts = INT64_MAX;
>> int i;
>> +MOVContext *mov = s->priv_data;
>> +int no_interleave = !mov->interleaved_read || !(s->pb->seekable &
>> AVIO_SEEKABLE_NORMAL);
>> for (i = 0; i < s->nb_streams; i++) {
>> AVStream *avst = s->streams[i];
>> FFStream *const avsti = ffstream(avst);
>> @@ -8788,7 +8790,7 @@ static AVIndexEntry
>> *mov_find_next_sample(AVFormatContext *s, AVStream **st)
>> AVIndexEntry *current_sample =
>> >index_entries[msc->current_sample];
>> int64_t dts = av_rescale(current_sample->timestamp,
>> AV_TIME_BASE, msc->time_scale);
>> av_log(s, AV_LOG_TRACE, "stream %d, sample %d, dts %"PRId64"\n",
>> i, msc->current_sample, dts);
>> -if (!sample || (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
>> current_sample->pos < sample->pos) ||
>> +if (!sample || (no_interleave && current_sample->pos <
>> sample->pos) ||
>> ((s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
>> ((msc->pb != s->pb && dts < best_dts) || (msc->pb == s->pb
>> && dts != AV_NOPTS_VALUE &&
>> ((FFABS(best_dts - dts) <= AV_TIME_BASE &&
>> current_sample->pos < sample->pos) ||
>> @@ -9282,6 +9284,7 @@ static const AVOption mov_options[] = {
>> { "enable_drefs", "Enable external track support.",
>> OFFSET(enable_drefs), AV_OPT_TYPE_BOOL,
>> {.i64 = 0}, 0, 1, FLAGS },
>> { "max_stts_delta", "treat offsets above this value as invalid",
>> OFFSET(max_stts_delta), AV_OPT_TYPE_INT, {.i64 = UINT_MAX-48000*10 }, 0,
>> UINT_MAX, .flags = AV_OPT_FLAG_DECODING_PARAM },
>> +{ "interleaved_read", "Manually interleave between multiple tracks",
>> OFFSET(interleaved_read), AV_OPT_TYPE_BOOL, {.i64 = 1 }, 0, 1, .flags =
>> AV_OPT_FLAG_DECODING_PARAM },
>>
>> { NULL },
>> };
>> diff --git a/libavformat/version.h b/libavformat/version.h
>> index cb67e0a1f8..e41362ac9d 100644
>> --- a/libavformat/version.h
>> +++ b/libavformat/version.h
>> @@ -32,7 +32,7 @@
>> #include "version_major.h"
>>
>> #define LIBAVFORMAT_VERSION_MINOR 12
>> -#define LIBAVFORMAT_VERSION_MICRO 100
>> +#define LIBAVFORMAT_VERSION_MICRO 101
>>
>> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
>>LIBAVFORMAT_VERSION_MINOR, \
>> --
>> 2.34.1
>>
>>
Re: [FFmpeg-devel] [PATCH 1/4] lavc/aarch64: new optimization for 8-bit hevc_epel_uni_v
Hi Martin,
You can try the attached patchset. If that doesn't work, My code branch
address is https://github.com/myais2023/FFmpeg/tree/hevc-aarch64
Please try it again.
Thanks
在 2023/9/12 19:48, Martin Storsjö 写道:
Hi,
Sorry for not tending to your patches sooner.
Unfortunately, this patchset is impossible to apply - there seems to
be garbled whitespace in the patch which would require me to manually
apply all the changes.
Can you try sending the patches again in a way that doesn't corrupt
whitespace? If not, can you push the branch somewhere where I can
fetch it?
// Martin
___
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".From 022535be4fc50e807870e5e8d1f6449f466d061d Mon Sep 17 00:00:00 2001
From: Logan Lyu
Date: Tue, 15 Aug 2023 15:24:32 +0800
Subject: [PATCH 1/9] lavc/aarch64: new optimization for 8-bit hevc_epel_uni_v
checkasm bench:
put_hevc_epel_uni_hv64_8_i8mm: 6568.7
put_hevc_epel_uni_v4_8_c: 88.7
put_hevc_epel_uni_v4_8_neon: 32.7
put_hevc_epel_uni_v6_8_c: 185.4
put_hevc_epel_uni_v6_8_neon: 44.9
put_hevc_epel_uni_v8_8_c: 333.9
put_hevc_epel_uni_v8_8_neon: 44.4
put_hevc_epel_uni_v12_8_c: 728.7
put_hevc_epel_uni_v12_8_neon: 119.7
put_hevc_epel_uni_v16_8_c: 1224.2
put_hevc_epel_uni_v16_8_neon: 139.7
put_hevc_epel_uni_v24_8_c: 2531.2
put_hevc_epel_uni_v24_8_neon: 329.9
put_hevc_epel_uni_v32_8_c: 4739.9
put_hevc_epel_uni_v32_8_neon: 562.7
put_hevc_epel_uni_v48_8_c: 10618.7
put_hevc_epel_uni_v48_8_neon: 1256.2
put_hevc_epel_uni_v64_8_c: 19169.9
put_hevc_epel_uni_v64_8_neon: 2179.2
Co-Authored-By: J. Dekker
---
libavcodec/aarch64/hevcdsp_epel_neon.S| 320 ++
libavcodec/aarch64/hevcdsp_init_aarch64.c | 5 +
2 files changed, 325 insertions(+)
diff --git a/libavcodec/aarch64/hevcdsp_epel_neon.S
b/libavcodec/aarch64/hevcdsp_epel_neon.S
index a8d694639b..7ce7eec829 100644
--- a/libavcodec/aarch64/hevcdsp_epel_neon.S
+++ b/libavcodec/aarch64/hevcdsp_epel_neon.S
@@ -32,6 +32,326 @@ const epel_filters, align=4
.byte -2, 10, 58, -2
endconst
+.macro load_epel_filterb freg, xreg
+movrel \xreg, epel_filters
+add \xreg, \xreg, \freg, lsl #2
+ld4r{v0.16b, v1.16b, v2.16b, v3.16b}, [\xreg] // filter
+neg v0.16b, v0.16b
+neg v3.16b, v3.16b
+.endm
+
+.macro calc_epelb dst, src0, src1, src2, src3
+umlsl \dst\().8h, \src0\().8b, v0.8b
+umlal \dst\().8h, \src1\().8b, v1.8b
+umlal \dst\().8h, \src2\().8b, v2.8b
+umlsl \dst\().8h, \src3\().8b, v3.8b
+.endm
+
+.macro calc_epelb2 dst, src0, src1, src2, src3
+umlsl2 \dst\().8h, \src0\().16b, v0.16b
+umlal2 \dst\().8h, \src1\().16b, v1.16b
+umlal2 \dst\().8h, \src2\().16b, v2.16b
+umlsl2 \dst\().8h, \src3\().16b, v3.16b
+.endm
+
+.macro calc_all4
+calcv16, v17, v18, v19
+b.eq2f
+calcv17, v18, v19, v16
+b.eq2f
+calcv18, v19, v16, v17
+b.eq2f
+calcv19, v16, v17, v18
+b.ne1b
+.endm
+
+.macro calc_all8
+calcv16, v17, v18, v19, v20, v21, v22, v23
+b.eq2f
+calcv18, v19, v20, v21, v22, v23, v16, v17
+b.eq2f
+calcv20, v21, v22, v23, v16, v17, v18, v19
+b.eq2f
+calcv22, v23, v16, v17, v18, v19, v20, v21
+b.ne1b
+.endm
+
+.macro calc_all12
+calcv16, v17, v18, v19, v20, v21, v22, v23, v24, v25, v26,
v27
+b.eq2f
+calcv19, v20, v21, v22, v23, v24, v25, v26, v27, v16, v17,
v18
+b.eq2f
+calcv22, v23, v24, v25, v26, v27, v16, v17, v18, v19, v20,
v21
+b.eq2f
+calcv25, v26, v27, v16, v17, v18, v19, v20, v21, v22, v23,
v24
+b.ne1b
+.endm
+
+.macro calc_all16
+calcv16, v17, v18, v19, v20, v21, v22, v23, v24, v25, v26,
v27, v28, v29, v30, v31
+b.eq2f
+calcv20, v21, v22, v23, v24, v25, v26, v27, v28, v29, v30,
v31, v16, v17, v18, v19
+b.eq2f
+calcv24, v25, v26, v27, v28, v29, v30, v31, v16, v17, v18,
v19, v20, v21, v22, v23
+b.eq2f
+calcv28, v29, v30, v31, v16, v17, v18, v19, v20, v21, v22,
v23, v24, v25, v26, v27
+b.ne1b
+.endm
+
+function ff_hevc_put_hevc_epel_uni_v4_8_neon, export=1
+load_epel_filterb x6, x5
+sxtwx3, w3
+sxtw
Re: [FFmpeg-devel] [PATCH v3] avformat/mov: add interleaved_read option
Zhao Zhili 于2023年9月12日周二 01:10写道：
>
> From: Zhao Zhili
>
> For bad interleaved files, manually interleave multiple tracks at the
> demuxer level can trigger seeking back and forth, which can be
> dramatically slow depending on the protocol. Demuxer level interleave
> can be useless sometimes, e.g., reading mp4 via http and then
> transcoding/remux to DASH. Disable this option when you don't need the
> demuxer level interleave, and want to avoid the IO penalizes.
>
> Co-authored-by: Derek Buitenhuis
> Signed-off-by: Zhao Zhili
> ---
> v3: update doc
> v2: rename option
>
> This issue is well known. Two samples can be found at here
> http://ffmpeg.org/pipermail/ffmpeg-devel/2022-December/304951.html
>
> doc/demuxers.texi | 7 +++
> libavformat/isom.h| 1 +
> libavformat/mov.c | 5 -
> libavformat/version.h | 2 +-
> 4 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index 2d33b47a56..ca1563abb0 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -779,6 +779,13 @@ cast to int32 are used to adjust onward dts.
>
> Unit is the track time scale. Range is 0 to UINT_MAX. Default is
> @code{UINT_MAX - 48000*10} which allows upto
> a 10 second dts correction for 48 kHz audio streams while accommodating
> 99.9% of @code{uint32} range.
> +
> +@item interleaved_read
> +Interleave packets from multiple tracks at demuxer level. For badly
> interleaved files, this prevents playback issues
> +caused by large gaps between packets in different tracks, as MOV/MP4 do not
> have packet placement requirements.
> +However, this can cause excessive seeking on very badly interleaved files,
> due to seeking between tracks, so disabling
> +it may prevent I/O issues, at the expense of playback.
> +
> @end table
>
> @subsection Audible AAX
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index 4b1cd42f0f..3d375d7a46 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -327,6 +327,7 @@ typedef struct MOVContext {
> int64_t extent_offset;
> } *avif_info;
> int avif_info_size;
> +int interleaved_read;
> } MOVContext;
>
> int ff_mp4_read_descr_len(AVIOContext *pb);
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index aa1d9e4ccc..8ad5f0b646 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -8780,6 +8780,8 @@ static AVIndexEntry
> *mov_find_next_sample(AVFormatContext *s, AVStream **st)
> AVIndexEntry *sample = NULL;
> int64_t best_dts = INT64_MAX;
> int i;
> +MOVContext *mov = s->priv_data;
> +int no_interleave = !mov->interleaved_read || !(s->pb->seekable &
> AVIO_SEEKABLE_NORMAL);
> for (i = 0; i < s->nb_streams; i++) {
> AVStream *avst = s->streams[i];
> FFStream *const avsti = ffstream(avst);
> @@ -8788,7 +8790,7 @@ static AVIndexEntry
> *mov_find_next_sample(AVFormatContext *s, AVStream **st)
> AVIndexEntry *current_sample =
> >index_entries[msc->current_sample];
> int64_t dts = av_rescale(current_sample->timestamp,
> AV_TIME_BASE, msc->time_scale);
> av_log(s, AV_LOG_TRACE, "stream %d, sample %d, dts %"PRId64"\n",
> i, msc->current_sample, dts);
> -if (!sample || (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
> current_sample->pos < sample->pos) ||
> +if (!sample || (no_interleave && current_sample->pos <
> sample->pos) ||
> ((s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
> ((msc->pb != s->pb && dts < best_dts) || (msc->pb == s->pb
> && dts != AV_NOPTS_VALUE &&
> ((FFABS(best_dts - dts) <= AV_TIME_BASE &&
> current_sample->pos < sample->pos) ||
> @@ -9282,6 +9284,7 @@ static const AVOption mov_options[] = {
> { "enable_drefs", "Enable external track support.",
> OFFSET(enable_drefs), AV_OPT_TYPE_BOOL,
> {.i64 = 0}, 0, 1, FLAGS },
> { "max_stts_delta", "treat offsets above this value as invalid",
> OFFSET(max_stts_delta), AV_OPT_TYPE_INT, {.i64 = UINT_MAX-48000*10 }, 0,
> UINT_MAX, .flags = AV_OPT_FLAG_DECODING_PARAM },
> +{ "interleaved_read", "Manually interleave between multiple tracks",
> OFFSET(interleaved_read), AV_OPT_TYPE_BOOL, {.i64 = 1 }, 0, 1, .flags =
> AV_OPT_FLAG_DECODING_PARAM },
>
> { NULL },
> };
> diff --git a/libavformat/version.h b/libavformat/version.h
> index cb67e0a1f8..e41362ac9d 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -32,7 +32,7 @@
> #include "version_major.h"
>
> #define LIBAVFORMAT_VERSION_MINOR 12
> -#define LIBAVFORMAT_VERSION_MICRO 100
> +#define LIBAVFORMAT_VERSION_MICRO 101
>
> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> LIBAVFORMAT_VERSION_MINOR, \
> --
> 2.34.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Re: [FFmpeg-devel] [PATCH] avcodec/lagarith: use VLC for probe code length
Paul B Mahol:
>
> +#include "libavutil/mem_internal.h"
I don't get what this header is needed for. You are not adding anything
ALIGNED and this file does not require it.
> +#define VLC_BITS 11
> +
> enum LagarithFrameType {
> FRAME_RAW = 1,/**< uncompressed */
> FRAME_U_RGB24 = 2,/**< unaligned RGB24 */
> @@ -56,6 +61,35 @@ typedef struct LagarithContext {
> int zeros_rem; /**< number of zero bytes remaining to
> output */
> } LagarithContext;
>
> +static VLC lag_tab;
> +
> +static const uint8_t lag_bits[] = {
> +7, 7, 7, 2, 7, 3, 4, 5, 6, 7, 7, 7, 7, 7, 6, 7, 4, 5, 7, 7, 7, 7,
> +5, 6, 7, 7, 7, 7, 7, 7, 6, 7, 7, 7, 7, 7, 6, 7, 7, 7, 7, 7, 7, 7,
> +7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
> +};
> +
> +static const uint8_t lag_codes[] = {
> +0x00, 0x01, 0x02, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x04, 0x05,
> +0x08, 0x09, 0x0A, 0x0B, 0x0B, 0x0B, 0x0B, 0x10, 0x11, 0x12, 0x13,
> +0x13, 0x13, 0x14, 0x15, 0x20, 0x21, 0x22, 0x23, 0x23, 0x24, 0x25,
> +0x28, 0x29, 0x2A, 0x2B, 0x2B, 0x40, 0x41, 0x42, 0x43, 0x44, 0x45,
> +0x48, 0x49, 0x4A, 0x4B, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55,
> +};
> +
> +static const uint8_t lag_symbols[] = {
> +-1, 20, 12, 0, 12, 1, 2, 4, 7, 7, 28, 4, 25, 17,
> +10, 17, 3, 6, 2, 23, 15, 15, 5, 9, 10, 31, 1, 22,
> +14, 14, 8, 9, 30, 6, 27, 19, 11, 19, 0, 21, 13, 13,
> +8, 29, 5, 26, 18, 18, 3, 24, 16, 16, 11, 32,
> +};
> +
> +static av_cold void lag_init_static_data(void)
> +{
> +VLC_INIT_SPARSE_STATIC(_tab, VLC_BITS, FF_ARRAY_ELEMS(lag_bits),
> + lag_bits, 1, 1, lag_codes, 1, 1, lag_symbols, 1,
> 1, 2048);
> +}
> +
If the longest code has seven bits, why are you using 11 bits for the
VLC? This just wastes cache/memory.
Apart from that:
Your first entry will be converted to an uint8_t of 255 (and give a
-Woverflow warning when said warning is enabled) and this is what
get_vlc2() will return for it, i.e. it will trigger the bits > 31 check
and error out, which is probably what you intend it to do given that
this behaviour coincides with the current behaviour.
But the more natural way for VLCs to achieve this is to actually not add
invalid codes. get_vlc2() will then return -1 for them; this means that
the check for invalid values becomes "bits < 0" (in which case the flags
from this comparison can be reused for the "bits == 0" check).
In contrast to the current code and your proposed patch no bits would be
consumed upon encountering such an invalid code though. But it seems to
me that the we error out anyway and the state of the GetBitContext
afterwards doesn't matter.
If you were to use the init_from_lengths variants, you would have to use
negative bitlengths for the invalid values.
- Andreas
___
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".
[FFmpeg-devel] [PATCH 3/3] avcodec/aacdec_template: Better avoidance of signed integer overflow in imdct_and_windowing_eld()
Fixes:
62171/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5644657180409856
Fixes: signed integer overflow: 2 * 1079352273 cannot be represented in type
'int'
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/aacdec_template.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 51a4cb2b66f..954399f86bb 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -2856,8 +2856,8 @@ static void imdct_and_windowing_eld(AACContext *ac,
SingleChannelElement *sce)
ac->mdct512_fn(ac->mdct512, buf, in, sizeof(INTFLOAT));
for (i = 0; i < n; i+=2) {
-buf[i + 0] = -(int)(USE_FIXED + 1U)*buf[i + 0];
-buf[i + 1] = (int)(USE_FIXED + 1U)*buf[i + 1];
+buf[i + 0] = -(UINTFLOAT)(USE_FIXED + 1)*buf[i + 0];
+buf[i + 1] = (UINTFLOAT)(USE_FIXED + 1)*buf[i + 1];
}
// Like with the regular IMDCT at this point we still have the middle half
// of a transform but with even symmetry on the left and odd symmetry on
--
2.17.1
___
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".
[FFmpeg-devel] [PATCH 2/3] avcodec/vlc: Attempt to free buf after use in ff_vlc_init_multi_from_lengths()
Fixes: use after free Fixes: 62153/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_fuzzer-4702814909366272 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/vlc.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/libavcodec/vlc.c b/libavcodec/vlc.c index b353d2e86c2..f4bab0ae529 100644 --- a/libavcodec/vlc.c +++ b/libavcodec/vlc.c @@ -471,10 +471,13 @@ int ff_vlc_init_multi_from_lengths(VLC *vlc, VLC_MULTI *multi, int nb_bits, int goto fail; } } -ret = vlc_common_end(vlc, nb_bits, j, buf, flags, localbuf); +ret = vlc_common_end(vlc, nb_bits, j, buf, flags, buf); if (ret < 0) goto fail; -return vlc_multi_gen(multi->table, vlc, nb_elems, j, nb_bits, buf, logctx); +ret = vlc_multi_gen(multi->table, vlc, nb_elems, j, nb_bits, buf, logctx); +if (buf != localbuf) +av_free(buf); +return ret; fail: if (buf != localbuf) av_free(buf); -- 2.17.1 ___ 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".
[FFmpeg-devel] [PATCH 1/3] tools/target_dec_fuzzer: Adjust threshold for MVHA
Fixes: Timeout
Fixes:
62120/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MVHA_fuzzer-5647877768347648
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index c3f88ef49f6..8e66f378462 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -261,6 +261,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_MSZH:maxpixels /= 128; break;
case AV_CODEC_ID_MTS2:maxpixels /= 4096; break;
case AV_CODEC_ID_MVC2:maxpixels /= 128; break;
+case AV_CODEC_ID_MVHA:maxpixels /= 16384; break;
case AV_CODEC_ID_MVDV:maxpixels /= 1024; break;
case AV_CODEC_ID_MWSC:maxpixels /= 256; break;
case AV_CODEC_ID_MXPEG: maxpixels /= 128; break;
--
2.17.1
___
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".
[FFmpeg-devel] [PATCH] avcodec/lagarith: use VLC for probe code length
Patch Attached.
From cd774229dcf32cb44455031663b4357f0597b4c0 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 12 Sep 2023 01:29:55 +0200
Subject: [PATCH] avcodec/lagarith: use VLC for prob code length
Signed-off-by: Paul B Mahol
---
libavcodec/lagarith.c | 57 ++-
1 file changed, 40 insertions(+), 17 deletions(-)
diff --git a/libavcodec/lagarith.c b/libavcodec/lagarith.c
index ebc1f7613a..31cad907c0 100644
--- a/libavcodec/lagarith.c
+++ b/libavcodec/lagarith.c
@@ -27,6 +27,9 @@
#include
+#include "libavutil/mem_internal.h"
+#include "libavutil/thread.h"
+
#include "avcodec.h"
#include "codec_internal.h"
#include "get_bits.h"
@@ -35,6 +38,8 @@
#include "lossless_videodsp.h"
#include "thread.h"
+#define VLC_BITS 11
+
enum LagarithFrameType {
FRAME_RAW = 1,/**< uncompressed */
FRAME_U_RGB24 = 2,/**< unaligned RGB24 */
@@ -56,6 +61,35 @@ typedef struct LagarithContext {
int zeros_rem; /**< number of zero bytes remaining to output */
} LagarithContext;
+static VLC lag_tab;
+
+static const uint8_t lag_bits[] = {
+7, 7, 7, 2, 7, 3, 4, 5, 6, 7, 7, 7, 7, 7, 6, 7, 4, 5, 7, 7, 7, 7,
+5, 6, 7, 7, 7, 7, 7, 7, 6, 7, 7, 7, 7, 7, 6, 7, 7, 7, 7, 7, 7, 7,
+7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
+};
+
+static const uint8_t lag_codes[] = {
+0x00, 0x01, 0x02, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x04, 0x05,
+0x08, 0x09, 0x0A, 0x0B, 0x0B, 0x0B, 0x0B, 0x10, 0x11, 0x12, 0x13,
+0x13, 0x13, 0x14, 0x15, 0x20, 0x21, 0x22, 0x23, 0x23, 0x24, 0x25,
+0x28, 0x29, 0x2A, 0x2B, 0x2B, 0x40, 0x41, 0x42, 0x43, 0x44, 0x45,
+0x48, 0x49, 0x4A, 0x4B, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55,
+};
+
+static const uint8_t lag_symbols[] = {
+-1, 20, 12, 0, 12, 1, 2, 4, 7, 7, 28, 4, 25, 17,
+10, 17, 3, 6, 2, 23, 15, 15, 5, 9, 10, 31, 1, 22,
+14, 14, 8, 9, 30, 6, 27, 19, 11, 19, 0, 21, 13, 13,
+8, 29, 5, 26, 18, 18, 3, 24, 16, 16, 11, 32,
+};
+
+static av_cold void lag_init_static_data(void)
+{
+VLC_INIT_SPARSE_STATIC(_tab, VLC_BITS, FF_ARRAY_ELEMS(lag_bits),
+ lag_bits, 1, 1, lag_codes, 1, 1, lag_symbols, 1, 1, 2048);
+}
+
/**
* Compute the 52-bit mantissa of 1/(double)denom.
* This crazy format uses floats in an entropy coder and we have to match x86
@@ -101,23 +135,10 @@ static uint8_t lag_calc_zero_run(int8_t x)
static int lag_decode_prob(GetBitContext *gb, uint32_t *value)
{
-static const uint8_t series[] = { 1, 2, 3, 5, 8, 13, 21 };
-int i;
-int bit = 0;
-int bits= 0;
-int prevbit = 0;
-unsigned val;
-
-for (i = 0; i < 7; i++) {
-if (prevbit && bit)
-break;
-prevbit = bit;
-bit = get_bits1(gb);
-if (bit && !prevbit)
-bits += series[i];
-}
-bits--;
-if (bits < 0 || bits > 31) {
+unsigned val, bits;
+
+bits = get_vlc2(gb, lag_tab.table, VLC_BITS, 3);
+if (bits > 31) {
*value = 0;
return AVERROR_INVALIDDATA;
} else if (bits == 0) {
@@ -720,10 +741,12 @@ static int lag_decode_frame(AVCodecContext *avctx, AVFrame *p,
static av_cold int lag_decode_init(AVCodecContext *avctx)
{
+static AVOnce init_static_once = AV_ONCE_INIT;
LagarithContext *l = avctx->priv_data;
l->avctx = avctx;
ff_llviddsp_init(>llviddsp);
+ff_thread_once(_static_once, lag_init_static_data);
return 0;
}
--
2.39.1
___
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".
Re: [FFmpeg-devel] J2K in HEIF was: [RFC]avformat: introduce AVStreamGroup
ons 2023-09-13 klockan 07:33 -0700 skrev Pierre-Anthony Lemieux:
> On Wed, Sep 13, 2023 at 2:35 AM Tomas Härdin wrote:
> >
> > ons 2023-09-06 klockan 16:16 -0300 skrev James Almer:
> > > On 9/6/2023 2:53 PM, Tomas Härdin wrote:
> > > > ons 2023-09-06 klockan 11:38 -0300 skrev James Almer:
> > > > > Signed-off-by: James Almer
> > > > > ---
> > > > > This is an initial proof of concept for AVStream groups,
> > > > > something
> > > > > that's
> > > > > needed for quite a few existing and upcoming formats that
> > > > > lavf
> > > > > has no
> > > > > way to
> > > > > currently export. Said formats define a single video or audio
> > > > > stream
> > > > > composed
> > > > > by merging several individualy multiplexed streams within a
> > > > > media
> > > > > file.
> > > > > This is the case of HEIF, a format defining a tiled image
> > > > > where
> > > > > each
> > > > > tile is a
> > > > > separate image (either hevc, av1, etc) all of which need to
> > > > > be
> > > > > decoded
> > > > > individualy and then stitched together for presentation using
> > > > > container level
> > > > > information;
> > > >
> > > > I remember this blocking HEIF as a GSoC project. Honestly the
> > > > way
> > > > that
> > > > format is designed is immensely horrible.
> > > >
> > > > > MPEG-TS programs, currently exported as
> > > > > AVProgram, which this new general purpose API would replace.
> > > >
> > > > I can foresee this being a nuisance for users accustomed to
> > > > AVProgram.
> > > > Also this feature borders on NLE territory. Not necessarily a
> > > > bad
> > > > thing, but FFmpeg is overall poorly architectured for NLE
> > > > stuff. I
> > > > believe I raised this issue back when lavfi was proposed, it
> > > > being
> > > > wholly unsuitable for NLE work.
> > > >
> > > >
> > > > > +typedef struct AVStreamGroup {
> > > > > + /**
> > > > > + * A class for @ref avoptions. Set on stream creation.
> > > > > + */
> > > > > + const AVClass *av_class;
> > > > > +
> > > > > + /**
> > > > > + * Group index in AVFormatContext.
> > > > > + */
> > > > > + int index;
> > > > > +
> > > > > + /**
> > > > > + * Format-specific group ID.
> > > > > + * decoding: set by libavformat
> > > > > + * encoding: set by the user, replaced by libavformat if
> > > > > left
> > > > > unset
> > > > > + */
> > > > > + int id;
> > > > > +
> > > > > + /**
> > > > > + * Codec parameters associated with this stream group.
> > > > > Allocated
> > > > > and freed
> > > > > + * by libavformat in avformat_new_stream_group() and
> > > > > avformat_free_context()
> > > > > + * respectively.
> > > > > + *
> > > > > + * - demuxing: filled by libavformat on stream group
> > > > > creation or
> > > > > in
> > > > > + * avformat_find_stream_info()
> > > > > + * - muxing: filled by the caller before
> > > > > avformat_write_header()
> > > > > + */
> > > > > + AVCodecParameters *codecpar;
> > > > > +
> > > > > + void *priv_data;
> > > > > +
> > > > > + /**
> > > > > + * Number of elements in AVStreamGroup.stream_index.
> > > > > + *
> > > > > + * Set by av_stream_group_add_stream() and
> > > > > av_stream_group_new_stream(), must not
> > > > > + * be modified by any other code.
> > > > > + */
> > > > > + int nb_stream_indexes;
> > > > > +
> > > > > + /**
> > > > > + * A list of indexes of streams in the group. New
> > > > > entries
> > > > > are
> > > > > created with
> > > > > + * av_stream_group_add_stream() and
> > > > > av_stream_group_new_stream().
> > > > > + *
> > > > > + * - demuxing: entries are created by libavformat in
> > > > > avformat_open_input().
> > > > > + * If AVFMTCTX_NOHEADER is set in ctx_flags,
> > > > > then
> > > > > new entries may also
> > > > > + * appear in av_read_frame().
> > > > > + * - muxing: entries are created by the user before
> > > > > avformat_write_header().
> > > > > + *
> > > > > + * Freed by libavformat in avformat_free_context().
> > > > > + */
> > > > > + int *stream_index;
> > > > > +} AVStreamGroup;
> > > >
> > > > I see no provisions for attaching metadata, for example HEIF
> > > > stitching.
> > > > Putting it in coderpar seems wrong, since it is container-level
> > > > metadata. We could just have an HEIF specific struct as
> > > > container
> > > > metadata.
> > >
> > > The doxy for AVCodecParameters says "This struct describes the
> > > properties of an encoded stream.", so It's not about container
> > > level
> > > props.
> >
> > It *is* container level props. The underlying codecs have no
> > concept of
> > this kind of stitching. The closest you're going to get is tiles in
> > JPEG2000, but I doubt HEIF support JPEG2000.
>
> Just an FYI.
>
> HEIF supports JPEG 2000:
>
> https://www.itu.int/rec/T-REC-T.815/en
>
> One implementation:
>
> https://github.com/strukturag/libheif/pull/874
Cursed
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/libaribb24, ttmlenc, avutil/tx: Remove redundant init of AVBPrint
Andreas Rheinhardt:
> An AVBPrint is initialized via av_bprint_init() (or
> av_bprint_init_for_buffer()) which expects uninitialized
> AVBPrints; it is therefore not necessary to zero them before
> the actual initialization.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/libaribb24.c | 2 +-
> libavcodec/ttmlenc.c| 2 +-
> libavutil/tx.c | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/libaribb24.c b/libavcodec/libaribb24.c
> index 8032536b22..551be89ffd 100644
> --- a/libavcodec/libaribb24.c
> +++ b/libavcodec/libaribb24.c
> @@ -227,7 +227,7 @@ static int libaribb24_handle_regions(AVCodecContext
> *avctx, AVSubtitle *sub)
> Libaribb24Context *b24 = avctx->priv_data;
> const arib_buf_region_t *region = arib_decoder_get_regions(b24->decoder);
> unsigned int profile_font_size = get_profile_font_size(avctx);
> -AVBPrint buf = { 0 };
> +AVBPrint buf;
> int ret = 0;
>
> av_bprint_init(, 0, AV_BPRINT_SIZE_UNLIMITED);
> diff --git a/libavcodec/ttmlenc.c b/libavcodec/ttmlenc.c
> index fb05c38968..6a2ab23cab 100644
> --- a/libavcodec/ttmlenc.c
> +++ b/libavcodec/ttmlenc.c
> @@ -45,7 +45,7 @@ typedef struct {
> static void ttml_text_cb(void *priv, const char *text, int len)
> {
> TTMLContext *s = priv;
> -AVBPrint cur_line = { 0 };
> +AVBPrint cur_line;
> AVBPrint *buffer = >buffer;
>
> av_bprint_init(_line, len, AV_BPRINT_SIZE_UNLIMITED);
> diff --git a/libavutil/tx.c b/libavutil/tx.c
> index 24b2015b44..d6740071b9 100644
> --- a/libavutil/tx.c
> +++ b/libavutil/tx.c
> @@ -595,7 +595,7 @@ static void print_type(AVBPrint *bp, enum AVTXType type)
>
> static void print_cd_info(const FFTXCodelet *cd, int prio, int len, int
> print_prio)
> {
> -AVBPrint bp = { 0 };
> +AVBPrint bp;
> av_bprint_init(, 0, AV_BPRINT_SIZE_AUTOMATIC);
>
> av_bprintf(, "%s - type: ", cd->name);
> @@ -718,7 +718,7 @@ av_cold int ff_tx_init_subtx(AVTXContext *s, enum
> AVTXType type,
> int codelet_list_idx = codelet_list_num;
> int nb_cd_matches = 0;
> #if !CONFIG_SMALL
> -AVBPrint bp = { 0 };
> +AVBPrint bp;
> #endif
>
> /* We still accept functions marked with SLOW, even if the CPU is
Will apply this patchset tomorrow unless there are objections.
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH] avformat: Inline raw_codec_id where known
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/aacdec.c | 2 +-
> libavformat/adxdec.c | 2 +-
> libavformat/dfpwmdec.c | 2 +-
> libavformat/gsmdec.c | 2 +-
> libavformat/loasdec.c | 2 +-
> libavformat/serdec.c | 2 +-
> libavformat/wsddec.c | 2 +-
> 7 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
> index 41c9a36239..4da98a6884 100644
> --- a/libavformat/aacdec.c
> +++ b/libavformat/aacdec.c
> @@ -113,7 +113,7 @@ static int adts_aac_read_header(AVFormatContext *s)
> return AVERROR(ENOMEM);
>
> st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
> -st->codecpar->codec_id = s->iformat->raw_codec_id;
> +st->codecpar->codec_id = AV_CODEC_ID_AAC;
> ffstream(st)->need_parsing = AVSTREAM_PARSE_FULL_RAW;
>
> ff_id3v1_read(s);
> diff --git a/libavformat/adxdec.c b/libavformat/adxdec.c
> index d808adbf3b..b6bd3303a7 100644
> --- a/libavformat/adxdec.c
> +++ b/libavformat/adxdec.c
> @@ -120,7 +120,7 @@ static int adx_read_header(AVFormatContext *s)
>
> par->ch_layout.nb_channels = channels;
> par->codec_type = AVMEDIA_TYPE_AUDIO;
> -par->codec_id= s->iformat->raw_codec_id;
> +par->codec_id= AV_CODEC_ID_ADPCM_ADX;
> par->bit_rate= (int64_t)par->sample_rate *
> par->ch_layout.nb_channels * BLOCK_SIZE * 8LL / BLOCK_SAMPLES;
>
> avpriv_set_pts_info(st, 64, BLOCK_SAMPLES, par->sample_rate);
> diff --git a/libavformat/dfpwmdec.c b/libavformat/dfpwmdec.c
> index 685b95148c..b92b00f13a 100644
> --- a/libavformat/dfpwmdec.c
> +++ b/libavformat/dfpwmdec.c
> @@ -50,7 +50,7 @@ static int dfpwm_read_header(AVFormatContext *s)
> par = st->codecpar;
>
> par->codec_type = AVMEDIA_TYPE_AUDIO;
> -par->codec_id= s->iformat->raw_codec_id;
> +par->codec_id= AV_CODEC_ID_DFPWM;
> par->sample_rate = s1->sample_rate;
> #if FF_API_OLD_CHANNEL_LAYOUT
> if (s1->ch_layout.nb_channels) {
> diff --git a/libavformat/gsmdec.c b/libavformat/gsmdec.c
> index 09dc0e0fb3..7150daa510 100644
> --- a/libavformat/gsmdec.c
> +++ b/libavformat/gsmdec.c
> @@ -78,7 +78,7 @@ static int gsm_read_header(AVFormatContext *s)
> return AVERROR(ENOMEM);
>
> st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
> -st->codecpar->codec_id= s->iformat->raw_codec_id;
> +st->codecpar->codec_id= AV_CODEC_ID_GSM;
> st->codecpar->ch_layout = (AVChannelLayout)AV_CHANNEL_LAYOUT_MONO;
> st->codecpar->sample_rate = c->sample_rate;
> st->codecpar->bit_rate= GSM_BLOCK_SIZE * 8 * c->sample_rate /
> GSM_BLOCK_SAMPLES;
> diff --git a/libavformat/loasdec.c b/libavformat/loasdec.c
> index e739b6c196..7b8b2ea4bc 100644
> --- a/libavformat/loasdec.c
> +++ b/libavformat/loasdec.c
> @@ -74,7 +74,7 @@ static int loas_read_header(AVFormatContext *s)
> return AVERROR(ENOMEM);
>
> st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
> -st->codecpar->codec_id = s->iformat->raw_codec_id;
> +st->codecpar->codec_id = AV_CODEC_ID_AAC_LATM;
> ffstream(st)->need_parsing = AVSTREAM_PARSE_FULL_RAW;
>
> //LCM of all possible AAC sample rates
> diff --git a/libavformat/serdec.c b/libavformat/serdec.c
> index 11add35b32..639c899249 100644
> --- a/libavformat/serdec.c
> +++ b/libavformat/serdec.c
> @@ -80,7 +80,7 @@ static int ser_read_header(AVFormatContext *s)
> }
>
> st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
> -st->codecpar->codec_id = s->iformat->raw_codec_id;
> +st->codecpar->codec_id = AV_CODEC_ID_RAWVIDEO;
>
> avpriv_set_pts_info(st, 64, ser->framerate.den, ser->framerate.num);
>
> diff --git a/libavformat/wsddec.c b/libavformat/wsddec.c
> index 9bee4d51bb..8153d898dd 100644
> --- a/libavformat/wsddec.c
> +++ b/libavformat/wsddec.c
> @@ -125,7 +125,7 @@ static int wsd_read_header(AVFormatContext *s)
> av_dict_set(>metadata, "playback_time", playback_time, 0);
>
> st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
> -st->codecpar->codec_id= s->iformat->raw_codec_id;
> +st->codecpar->codec_id= AV_CODEC_ID_DSD_MSBF;
> st->codecpar->sample_rate = avio_rb32(pb) / 8;
> avio_skip(pb, 4);
> st->codecpar->ch_layout.nb_channels = avio_r8(pb) & 0xF;
Will apply this tomorrow unless there are objections.
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH] avfilter/avfilter: Don't report deprecated pkt_pos
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/avfilter.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 23bf8685e9..ab7782862a 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -49,10 +49,10 @@ static void tlog_ref(void *ctx, AVFrame *ref, int end)
> {
> #ifdef TRACE
> ff_tlog(ctx,
> -"ref[%p buf:%p data:%p linesize[%d, %d, %d, %d] pts:%"PRId64"
> pos:%"PRId64,
> +"ref[%p buf:%p data:%p linesize[%d, %d, %d, %d] pts:%"PRId64,
> ref, ref->buf, ref->data[0],
> ref->linesize[0], ref->linesize[1], ref->linesize[2],
> ref->linesize[3],
> -ref->pts, ref->pkt_pos);
> +ref->pts);
>
> if (ref->width) {
> ff_tlog(ctx, " a:%d/%d s:%dx%d i:%c iskey:%d type:%c",
Will apply this tomorrow unless there are objections.
- Andreas
___
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".
Re: [FFmpeg-devel] trac backups
On Wed, Sep 13, 2023 at 11:05:23AM +0200, Jean-Baptiste Kempf wrote: > On Wed, 13 Sep 2023, at 01:33, Michael Niedermayer wrote: > >> Who else other than you has access to the infrastructure? > > > > all the root admins do > > but that isnt the problem, even if 100 more people had access > > the only way that was noticable it seems was if someone looked > > I disagree. The infrastructure is un-documented, and the people accessing it > are un-documented. Your reply isnt really related to the statment it follows Also it maybe sounds a little accusational. I just spoted the issue and fixed it and documented the issue here in public. So i get a "thanks for fixing the backups and thanks for the transparency" no, this is open source, so i get a mildly accusational reply Not even a "Where is the list of root admins" but a "the people accessing it are un-documented" are they ? the MAINTAINERS file lists teh admins, yes ubitux removed himself from it in MAINTAINERS and still has access which i think is good in case of an emergency and also thresh has access and is not listed in MAINTAINERS (he is more a last resort emergency and less a day to day admin). send a patch for MAINTAINERS if you feel the list is not good and what do you mean by infrastructure ? its a trac issue tracker in a VM, trac backup scripts written by beastd and a 2nd backup system setup by raz for all the ffmpeg infrastructure. what is missing and what do you want ? config files ? cronjobs ? making all that public is possible, if its a good idea for security and all i dont know. May i make a blunt suggestion, anyone who doesnt take the information in this mail and start writing/documenting the infrastructure should not complain its undocumented again in the future. > > This is a big problem. this really sounds more like a populistic statement than anything with the intend to improve a real problem. i mean you know, this is not a list of questions with the intend behind to document anything, its more finger-pointing. And somehow it feels like that pointing is going my way even though i havent writen or setup either backup system but it also would be deeply unfair to point to beastd or other admins here. Everyone did their best with the time they had available. So again if people want better documentation. First step i would suggest someone should volunteer to write that documentation. And then that person should start asking specific questions. Documentation does not write itself yet. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: PGP signature ___ 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".
[FFmpeg-devel] J2K in HEIF was: [RFC]avformat: introduce AVStreamGroup
On Wed, Sep 13, 2023 at 2:35 AM Tomas Härdin wrote:
>
> ons 2023-09-06 klockan 16:16 -0300 skrev James Almer:
> > On 9/6/2023 2:53 PM, Tomas Härdin wrote:
> > > ons 2023-09-06 klockan 11:38 -0300 skrev James Almer:
> > > > Signed-off-by: James Almer
> > > > ---
> > > > This is an initial proof of concept for AVStream groups,
> > > > something
> > > > that's
> > > > needed for quite a few existing and upcoming formats that lavf
> > > > has no
> > > > way to
> > > > currently export. Said formats define a single video or audio
> > > > stream
> > > > composed
> > > > by merging several individualy multiplexed streams within a media
> > > > file.
> > > > This is the case of HEIF, a format defining a tiled image where
> > > > each
> > > > tile is a
> > > > separate image (either hevc, av1, etc) all of which need to be
> > > > decoded
> > > > individualy and then stitched together for presentation using
> > > > container level
> > > > information;
> > >
> > > I remember this blocking HEIF as a GSoC project. Honestly the way
> > > that
> > > format is designed is immensely horrible.
> > >
> > > > MPEG-TS programs, currently exported as
> > > > AVProgram, which this new general purpose API would replace.
> > >
> > > I can foresee this being a nuisance for users accustomed to
> > > AVProgram.
> > > Also this feature borders on NLE territory. Not necessarily a bad
> > > thing, but FFmpeg is overall poorly architectured for NLE stuff. I
> > > believe I raised this issue back when lavfi was proposed, it being
> > > wholly unsuitable for NLE work.
> > >
> > >
> > > > +typedef struct AVStreamGroup {
> > > > +/**
> > > > + * A class for @ref avoptions. Set on stream creation.
> > > > + */
> > > > +const AVClass *av_class;
> > > > +
> > > > +/**
> > > > + * Group index in AVFormatContext.
> > > > + */
> > > > +int index;
> > > > +
> > > > +/**
> > > > + * Format-specific group ID.
> > > > + * decoding: set by libavformat
> > > > + * encoding: set by the user, replaced by libavformat if
> > > > left
> > > > unset
> > > > + */
> > > > +int id;
> > > > +
> > > > +/**
> > > > + * Codec parameters associated with this stream group.
> > > > Allocated
> > > > and freed
> > > > + * by libavformat in avformat_new_stream_group() and
> > > > avformat_free_context()
> > > > + * respectively.
> > > > + *
> > > > + * - demuxing: filled by libavformat on stream group
> > > > creation or
> > > > in
> > > > + * avformat_find_stream_info()
> > > > + * - muxing: filled by the caller before
> > > > avformat_write_header()
> > > > + */
> > > > +AVCodecParameters *codecpar;
> > > > +
> > > > +void *priv_data;
> > > > +
> > > > +/**
> > > > + * Number of elements in AVStreamGroup.stream_index.
> > > > + *
> > > > + * Set by av_stream_group_add_stream() and
> > > > av_stream_group_new_stream(), must not
> > > > + * be modified by any other code.
> > > > + */
> > > > +int nb_stream_indexes;
> > > > +
> > > > +/**
> > > > + * A list of indexes of streams in the group. New entries
> > > > are
> > > > created with
> > > > + * av_stream_group_add_stream() and
> > > > av_stream_group_new_stream().
> > > > + *
> > > > + * - demuxing: entries are created by libavformat in
> > > > avformat_open_input().
> > > > + * If AVFMTCTX_NOHEADER is set in ctx_flags,
> > > > then
> > > > new entries may also
> > > > + * appear in av_read_frame().
> > > > + * - muxing: entries are created by the user before
> > > > avformat_write_header().
> > > > + *
> > > > + * Freed by libavformat in avformat_free_context().
> > > > + */
> > > > +int *stream_index;
> > > > +} AVStreamGroup;
> > >
> > > I see no provisions for attaching metadata, for example HEIF
> > > stitching.
> > > Putting it in coderpar seems wrong, since it is container-level
> > > metadata. We could just have an HEIF specific struct as container
> > > metadata.
> >
> > The doxy for AVCodecParameters says "This struct describes the
> > properties of an encoded stream.", so It's not about container level
> > props.
>
> It *is* container level props. The underlying codecs have no concept of
> this kind of stitching. The closest you're going to get is tiles in
> JPEG2000, but I doubt HEIF support JPEG2000.
Just an FYI.
HEIF supports JPEG 2000:
https://www.itu.int/rec/T-REC-T.815/en
One implementation:
https://github.com/strukturag/libheif/pull/874
>
> We might say "well the resulting stream group has resolution so it's
> like a codec" but see below.
>
> > Although codecpar will be used to export the merged/stitched stream
> > props like dimensions and channel layout, maybe you're right about
> > the
> > metadata because there would be a clash between actual
> > HEVC/Opus/AAC/AV1
> > extradata and the HEIF/IAMF/etc specific info if both use
> > codecpar.extradata, even if one will be in AVStream
[FFmpeg-devel] [PATCH 3/3] avcodec/vp3: Use range-based loop variables
Motivated by:
#if CONFIG_VP4_DECODER
int j;
#endif
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp3.c | 264 +--
1 file changed, 120 insertions(+), 144 deletions(-)
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index f27e9cd1cd..33c120a58e 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -347,7 +347,6 @@ static void vp3_decode_flush(AVCodecContext *avctx)
static av_cold int vp3_decode_end(AVCodecContext *avctx)
{
Vp3DecodeContext *s = avctx->priv_data;
-int i, j;
free_tables(avctx);
av_freep(>edge_emu_buffer);
@@ -360,7 +359,7 @@ static av_cold int vp3_decode_end(AVCodecContext *avctx)
av_frame_free(>last_frame.f);
av_frame_free(>golden_frame.f);
-for (i = 0; i < FF_ARRAY_ELEMS(s->coeff_vlc); i++)
+for (int i = 0; i < FF_ARRAY_ELEMS(s->coeff_vlc); i++)
ff_vlc_free(>coeff_vlc[i]);
ff_vlc_free(>superblock_run_length_vlc);
@@ -368,11 +367,11 @@ static av_cold int vp3_decode_end(AVCodecContext *avctx)
ff_vlc_free(>mode_code_vlc);
ff_vlc_free(>motion_vector_vlc);
-for (j = 0; j < 2; j++)
-for (i = 0; i < 7; i++)
+for (int j = 0; j < 2; j++)
+for (int i = 0; i < 7; i++)
ff_vlc_free(>vp4_mv_vlc[j][i]);
-for (i = 0; i < 2; i++)
+for (int i = 0; i < 2; i++)
ff_vlc_free(>block_pattern_vlc[i]);
return 0;
}
@@ -386,10 +385,9 @@ static av_cold int vp3_decode_end(AVCodecContext *avctx)
*/
static int init_block_mapping(Vp3DecodeContext *s)
{
-int sb_x, sb_y, plane;
-int x, y, i, j = 0;
+int j = 0;
-for (plane = 0; plane < 3; plane++) {
+for (int plane = 0; plane < 3; plane++) {
int sb_width= plane ? s->c_superblock_width
: s->y_superblock_width;
int sb_height = plane ? s->c_superblock_height
@@ -397,11 +395,11 @@ static int init_block_mapping(Vp3DecodeContext *s)
int frag_width = s->fragment_width[!!plane];
int frag_height = s->fragment_height[!!plane];
-for (sb_y = 0; sb_y < sb_height; sb_y++)
-for (sb_x = 0; sb_x < sb_width; sb_x++)
-for (i = 0; i < 16; i++) {
-x = 4 * sb_x + hilbert_offset[i][0];
-y = 4 * sb_y + hilbert_offset[i][1];
+for (int sb_y = 0; sb_y < sb_height; sb_y++)
+for (int sb_x = 0; sb_x < sb_width; sb_x++)
+for (int i = 0; i < 16; i++) {
+int x = 4 * sb_x + hilbert_offset[i][0];
+int y = 4 * sb_y + hilbert_offset[i][1];
if (x < frag_width && y < frag_height)
s->superblock_fragments[j++] =
s->fragment_start[plane] +
@@ -421,12 +419,11 @@ static int init_block_mapping(Vp3DecodeContext *s)
static void init_dequantizer(Vp3DecodeContext *s, int qpi)
{
int ac_scale_factor = s->coded_ac_scale_factor[s->qps[qpi]];
-int i, plane, inter, qri, bmi, bmj, qistart;
-for (inter = 0; inter < 2; inter++) {
-for (plane = 0; plane < 3; plane++) {
+for (int inter = 0; inter < 2; inter++) {
+for (int plane = 0; plane < 3; plane++) {
int dc_scale_factor =
s->coded_dc_scale_factor[!!plane][s->qps[qpi]];
-int sum = 0;
+int sum = 0, bmi, bmj, qistart, qri;
for (qri = 0; qri < s->qr_count[inter][plane]; qri++) {
sum += s->qr_size[inter][plane][qri];
if (s->qps[qpi] <= sum)
@@ -435,7 +432,7 @@ static void init_dequantizer(Vp3DecodeContext *s, int qpi)
qistart = sum - s->qr_size[inter][plane][qri];
bmi = s->qr_base[inter][plane][qri];
bmj = s->qr_base[inter][plane][qri + 1];
-for (i = 0; i < 64; i++) {
+for (int i = 0; i < 64; i++) {
int coeff = (2 * (sum - s->qps[qpi]) *
s->base_matrix[bmi][i] -
2 * (qistart - s->qps[qpi]) *
s->base_matrix[bmj][i] +
s->qr_size[inter][plane][qri]) /
@@ -480,9 +477,7 @@ static int unpack_superblocks(Vp3DecodeContext *s,
GetBitContext *gb)
int current_run = 0;
int num_partial_superblocks = 0;
-int i, j;
int current_fragment;
-int plane;
int plane0_num_coded_frags = 0;
if (s->keyframe) {
@@ -537,7 +532,7 @@ static int unpack_superblocks(Vp3DecodeContext *s,
GetBitContext *gb)
if (current_run == 34)
current_run += get_bits(gb, 12);
-for (j = 0; j < current_run; current_superblock++) {
+for (int j = 0; j < current_run; current_superblock++) {
if (current_superblock >= s->superblock_count) {
av_log(s->avctx, AV_LOG_ERROR,
"Invalid fully coded superblock run length\n");
@@ -573,7 +568,7 @@ static int unpack_superblocks(Vp3DecodeContext *s,
[FFmpeg-devel] [PATCH 2/3] avcodec/vp3: Add const where appropriate
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp3.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index 272dd89117..f27e9cd1cd 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -472,7 +472,7 @@ static void init_loop_filter(Vp3DecodeContext *s)
*/
static int unpack_superblocks(Vp3DecodeContext *s, GetBitContext *gb)
{
-int superblock_starts[3] = {
+const int superblock_starts[3] = {
0, s->u_superblock_start, s->v_superblock_start
};
int bit = 0;
@@ -1182,7 +1182,7 @@ static inline int get_coeff(GetBitContext *gb, int token,
int16_t *coeff)
* be passed into the next call to this same function.
*/
static int unpack_vlcs(Vp3DecodeContext *s, GetBitContext *gb,
- VLC *table, int coeff_index,
+ const VLC *table, int coeff_index,
int plane,
int eob_run)
{
@@ -1196,7 +1196,7 @@ static int unpack_vlcs(Vp3DecodeContext *s, GetBitContext
*gb,
int16_t *dct_tokens = s->dct_tokens[plane][coeff_index];
/* local references to structure members to avoid repeated dereferences */
-int *coded_fragment_list = s->coded_fragment_list[plane];
+const int *coded_fragment_list = s->coded_fragment_list[plane];
Vp3Fragment *all_fragments = s->all_fragments;
const VLCElem *vlc_table = table->table;
@@ -1407,7 +1407,7 @@ static int unpack_dct_coeffs(Vp3DecodeContext *s,
GetBitContext *gb)
* @return < 0 on error
*/
static int vp4_unpack_vlcs(Vp3DecodeContext *s, GetBitContext *gb,
- VLC *vlc_tables[64],
+ const VLC *vlc_tables[64],
int plane, int eob_tracker[64], int fragment)
{
int token;
@@ -1537,7 +1537,7 @@ static int vp4_unpack_dct_coeffs(Vp3DecodeContext *s,
GetBitContext *gb)
int dc_c_table;
int ac_y_table;
int ac_c_table;
-VLC *tables[2][64];
+const VLC *tables[2][64];
int plane, sb_y, sb_x;
int eob_tracker[64];
VP4Predictor dc_pred[6][6];
@@ -1861,11 +1861,11 @@ static void apply_loop_filter(Vp3DecodeContext *s, int
plane,
* Pull DCT tokens from the 64 levels to decode and dequant the coefficients
* for the next block in coding order
*/
-static inline int vp3_dequant(Vp3DecodeContext *s, Vp3Fragment *frag,
+static inline int vp3_dequant(Vp3DecodeContext *s, const Vp3Fragment *frag,
int plane, int inter, int16_t block[64])
{
-int16_t *dequantizer = s->qmat[frag->qpi][inter][plane];
-uint8_t *perm = s->idct_scantable;
+const int16_t *dequantizer = s->qmat[frag->qpi][inter][plane];
+const uint8_t *perm = s->idct_scantable;
int i = 0;
do {
@@ -1948,7 +1948,7 @@ static void vp3_draw_horiz_band(Vp3DecodeContext *s, int
y)
* Wait for the reference frame of the current fragment.
* The progress value is in luma pixel rows.
*/
-static void await_reference_row(Vp3DecodeContext *s, Vp3Fragment *fragment,
+static void await_reference_row(Vp3DecodeContext *s, const Vp3Fragment
*fragment,
int motion_y, int y)
{
const ThreadFrame *ref_frame;
@@ -1972,7 +1972,8 @@ static void await_reference_row(Vp3DecodeContext *s,
Vp3Fragment *fragment,
* @return non-zero if temp (edge_emu_buffer) was populated
*/
static int vp4_mc_loop_filter(Vp3DecodeContext *s, int plane, int motion_x,
int motion_y, int bx, int by,
- uint8_t * motion_source, int stride, int src_x, int src_y, uint8_t
*temp)
+ const uint8_t *motion_source, int stride,
+ int src_x, int src_y, uint8_t *temp)
{
int motion_shift = plane ? 4 : 2;
int subpel_mask = plane ? 3 : 1;
@@ -2076,7 +2077,6 @@ static void render_slice(Vp3DecodeContext *s, int slice)
int16_t *block = s->block;
int motion_x = 0xdeadbeef, motion_y = 0xdeadbeef;
int motion_halfpel_index;
-uint8_t *motion_source;
int plane, first_pixel;
if (slice >= s->c_superblock_height)
@@ -2085,14 +2085,14 @@ static void render_slice(Vp3DecodeContext *s, int slice)
for (plane = 0; plane < 3; plane++) {
uint8_t *output_plane = s->current_frame.f->data[plane] +
s->data_offset[plane];
-uint8_t *last_plane = s->last_frame.f->data[plane] +
+const uint8_t *last_plane = s->last_frame.f->data[plane] +
s->data_offset[plane];
-uint8_t *golden_plane = s->golden_frame.f->data[plane] +
+const uint8_t *golden_plane = s->golden_frame.f->data[plane] +
s->data_offset[plane];
ptrdiff_t stride = s->current_frame.f->linesize[plane];
int plane_width = s->width >> (plane && s->chroma_x_shift);
int plane_height = s->height >> (plane && s->chroma_y_shift);
-
[FFmpeg-devel] [PATCH 1/3] avcodec/vp3: Move work after ff_thread_finish_setup
all_fragments is not synced between threads; resetting it can wait.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vp3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index 5002800ef2..272dd89117 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -2757,9 +2757,9 @@ static int vp3_decode_frame(AVCodecContext *avctx,
AVFrame *frame,
ff_thread_report_progress(>last_frame, INT_MAX, 0);
}
}
+ff_thread_finish_setup(avctx);
memset(s->all_fragments, 0, s->fragment_count * sizeof(Vp3Fragment));
-ff_thread_finish_setup(avctx);
if (s->version < 2) {
if ((ret = unpack_superblocks(s, )) < 0) {
--
2.34.1
___
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".
[FFmpeg-devel] [PATCH] avformat/libssh: avoid deprecated functions
Avoid using the deprecated functions ssh_try_publickey_from_file among
others in favor of symbols introduced in libssh 0.6.0 (Jan 2014) and
update configure to require this version.
Signed-off-by: Leo Izen
---
configure| 2 +-
libavformat/libssh.c | 11 ---
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index bd7f7697c8..48fee07f81 100755
--- a/configure
+++ b/configure
@@ -6796,7 +6796,7 @@ enabled libsmbclient && { check_pkg_config
libsmbclient smbclient libsmbcli
require libsmbclient libsmbclient.h smbc_init
-lsmbclient; }
enabled libsnappy && require libsnappy snappy-c.h snappy_compress
-lsnappy -lstdc++
enabled libsoxr && require libsoxr soxr.h soxr_create -lsoxr
-enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h
sftp_init
+enabled libssh&& require_pkg_config libssh "libssh >= 0.6.0"
libssh/sftp.h sftp_init
enabled libspeex && require_pkg_config libspeex speex speex/speex.h
speex_decoder_init
enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0"
srt/srt.h srt_socket
enabled libsvtav1 && require_pkg_config libsvtav1 "SvtAv1Enc >= 0.9.0"
EbSvtAv1Enc.h svt_av1_enc_init_handle
diff --git a/libavformat/libssh.c b/libavformat/libssh.c
index 21474f0f0a..127faaabd3 100644
--- a/libavformat/libssh.c
+++ b/libavformat/libssh.c
@@ -84,12 +84,9 @@ static av_cold int libssh_authentication(LIBSSHContext
*libssh, const char *user
if (auth_methods & SSH_AUTH_METHOD_PUBLICKEY) {
if (libssh->priv_key) {
-ssh_string pub_key;
-ssh_private_key priv_key;
-int type;
-if (!ssh_try_publickey_from_file(libssh->session,
libssh->priv_key, _key, )) {
-priv_key = privatekey_from_file(libssh->session,
libssh->priv_key, type, password);
-if (ssh_userauth_pubkey(libssh->session, NULL, pub_key,
priv_key) == SSH_AUTH_SUCCESS) {
+ssh_key priv_key;
+if (ssh_pki_import_privkey_file(libssh->priv_key, password, NULL,
NULL, _key) == SSH_OK) {
+if (ssh_userauth_publickey(libssh->session, NULL, priv_key) ==
SSH_AUTH_SUCCESS) {
av_log(libssh, AV_LOG_DEBUG, "Authentication successful
with selected private key.\n");
authorized = 1;
}
@@ -97,7 +94,7 @@ static av_cold int libssh_authentication(LIBSSHContext
*libssh, const char *user
av_log(libssh, AV_LOG_DEBUG, "Invalid key is provided.\n");
return AVERROR(EACCES);
}
-} else if (ssh_userauth_autopubkey(libssh->session, password) ==
SSH_AUTH_SUCCESS) {
+} else if (ssh_userauth_publickey_auto(libssh->session, NULL,
password) == SSH_AUTH_SUCCESS) {
av_log(libssh, AV_LOG_DEBUG, "Authentication successful with auto
selected key.\n");
authorized = 1;
}
--
2.42.0
___
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".
Re: [FFmpeg-devel] trac backups
On Wed, Sep 13, 2023 at 11:05 AM Jean-Baptiste Kempf wrote: > On Wed, 13 Sep 2023, at 01:33, Michael Niedermayer wrote: > >> Who else other than you has access to the infrastructure? > > > > all the root admins do > > but that isnt the problem, even if 100 more people had access > > the only way that was noticable it seems was if someone looked > > I disagree. The infrastructure is un-documented, and the people accessing > it are un-documented. > > This is a big problem. > +1 > > jb > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > ___ > 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". > ___ 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".
Re: [FFmpeg-devel] [PATCH] [RFC]avformat: introduce AVStreamGroup
ons 2023-09-06 klockan 16:16 -0300 skrev James Almer:
> On 9/6/2023 2:53 PM, Tomas Härdin wrote:
> > ons 2023-09-06 klockan 11:38 -0300 skrev James Almer:
> > > Signed-off-by: James Almer
> > > ---
> > > This is an initial proof of concept for AVStream groups,
> > > something
> > > that's
> > > needed for quite a few existing and upcoming formats that lavf
> > > has no
> > > way to
> > > currently export. Said formats define a single video or audio
> > > stream
> > > composed
> > > by merging several individualy multiplexed streams within a media
> > > file.
> > > This is the case of HEIF, a format defining a tiled image where
> > > each
> > > tile is a
> > > separate image (either hevc, av1, etc) all of which need to be
> > > decoded
> > > individualy and then stitched together for presentation using
> > > container level
> > > information;
> >
> > I remember this blocking HEIF as a GSoC project. Honestly the way
> > that
> > format is designed is immensely horrible.
> >
> > > MPEG-TS programs, currently exported as
> > > AVProgram, which this new general purpose API would replace.
> >
> > I can foresee this being a nuisance for users accustomed to
> > AVProgram.
> > Also this feature borders on NLE territory. Not necessarily a bad
> > thing, but FFmpeg is overall poorly architectured for NLE stuff. I
> > believe I raised this issue back when lavfi was proposed, it being
> > wholly unsuitable for NLE work.
> >
> >
> > > +typedef struct AVStreamGroup {
> > > + /**
> > > + * A class for @ref avoptions. Set on stream creation.
> > > + */
> > > + const AVClass *av_class;
> > > +
> > > + /**
> > > + * Group index in AVFormatContext.
> > > + */
> > > + int index;
> > > +
> > > + /**
> > > + * Format-specific group ID.
> > > + * decoding: set by libavformat
> > > + * encoding: set by the user, replaced by libavformat if
> > > left
> > > unset
> > > + */
> > > + int id;
> > > +
> > > + /**
> > > + * Codec parameters associated with this stream group.
> > > Allocated
> > > and freed
> > > + * by libavformat in avformat_new_stream_group() and
> > > avformat_free_context()
> > > + * respectively.
> > > + *
> > > + * - demuxing: filled by libavformat on stream group
> > > creation or
> > > in
> > > + * avformat_find_stream_info()
> > > + * - muxing: filled by the caller before
> > > avformat_write_header()
> > > + */
> > > + AVCodecParameters *codecpar;
> > > +
> > > + void *priv_data;
> > > +
> > > + /**
> > > + * Number of elements in AVStreamGroup.stream_index.
> > > + *
> > > + * Set by av_stream_group_add_stream() and
> > > av_stream_group_new_stream(), must not
> > > + * be modified by any other code.
> > > + */
> > > + int nb_stream_indexes;
> > > +
> > > + /**
> > > + * A list of indexes of streams in the group. New entries
> > > are
> > > created with
> > > + * av_stream_group_add_stream() and
> > > av_stream_group_new_stream().
> > > + *
> > > + * - demuxing: entries are created by libavformat in
> > > avformat_open_input().
> > > + * If AVFMTCTX_NOHEADER is set in ctx_flags,
> > > then
> > > new entries may also
> > > + * appear in av_read_frame().
> > > + * - muxing: entries are created by the user before
> > > avformat_write_header().
> > > + *
> > > + * Freed by libavformat in avformat_free_context().
> > > + */
> > > + int *stream_index;
> > > +} AVStreamGroup;
> >
> > I see no provisions for attaching metadata, for example HEIF
> > stitching.
> > Putting it in coderpar seems wrong, since it is container-level
> > metadata. We could just have an HEIF specific struct as container
> > metadata.
>
> The doxy for AVCodecParameters says "This struct describes the
> properties of an encoded stream.", so It's not about container level
> props.
It *is* container level props. The underlying codecs have no concept of
this kind of stitching. The closest you're going to get is tiles in
JPEG2000, but I doubt HEIF support JPEG2000.
We might say "well the resulting stream group has resolution so it's
like a codec" but see below.
> Although codecpar will be used to export the merged/stitched stream
> props like dimensions and channel layout, maybe you're right about
> the
> metadata because there would be a clash between actual
> HEVC/Opus/AAC/AV1
> extradata and the HEIF/IAMF/etc specific info if both use
> codecpar.extradata, even if one will be in AVStream and the other in
> AVStreamGroup.
Yes, pretty much. But it's more that codecpar is pressed into service
where it probably doesn't belong. It might be more appropriate to call
these "essence parameters". I'm going to stick my neck out further and
say that picture and sound essence should be handled with different
structs, not smushed together into one struct like AVCodecParameters.
/Tomas
___
ffmpeg-devel
Re: [FFmpeg-devel] trac backups
On Wed, 13 Sep 2023, at 01:33, Michael Niedermayer wrote: >> Who else other than you has access to the infrastructure? > > all the root admins do > but that isnt the problem, even if 100 more people had access > the only way that was noticable it seems was if someone looked I disagree. The infrastructure is un-documented, and the people accessing it are un-documented. This is a big problem. jb -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/av1dec: Pass AVCodecContext* as logctx in get_sw_pixel_format()
James Almer:
> On 9/12/2023 9:22 PM, Andreas Rheinhardt wrote:
>> Andreas Rheinhardt:
>>> It indicates to the reader that said function does not modify
>>> any state.
>>>
>>> Signed-off-by: Andreas Rheinhardt
>>> ---
>>> libavcodec/av1dec.c | 12 ++--
>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
>>> index 8f9c2dfefb..8f6c4f732e 100644
>>> --- a/libavcodec/av1dec.c
>>> +++ b/libavcodec/av1dec.c
>>> @@ -440,7 +440,7 @@ static int get_tiles_info(AVCodecContext *avctx,
>>> const AV1RawTileGroup *tile_gro
>>> }
>>> -static enum AVPixelFormat get_sw_pixel_format(AVCodecContext *avctx,
>>> +static enum AVPixelFormat get_sw_pixel_format(void *logctx,
>>> const
>>> AV1RawSequenceHeader *seq)
>>> {
>>> uint8_t bit_depth;
>>> @@ -451,7 +451,7 @@ static enum AVPixelFormat
>>> get_sw_pixel_format(AVCodecContext *avctx,
>>> else if (seq->seq_profile <= 2)
>>> bit_depth = seq->color_config.high_bitdepth ? 10 : 8;
>>> else {
>>> - av_log(avctx, AV_LOG_ERROR,
>>> + av_log(logctx, AV_LOG_ERROR,
>>> "Unknown AV1 profile %d.\n", seq->seq_profile);
>>> return -1;
>>> }
>>> @@ -467,7 +467,7 @@ static enum AVPixelFormat
>>> get_sw_pixel_format(AVCodecContext *avctx,
>>> else if (bit_depth == 12)
>>> pix_fmt = AV_PIX_FMT_YUV444P12;
>>> else
>>> - av_log(avctx, AV_LOG_WARNING, "Unknown AV1 pixel
>>> format.\n");
>>> + av_log(logctx, AV_LOG_WARNING, "Unknown AV1 pixel
>>> format.\n");
>>> } else if (seq->color_config.subsampling_x == 1 &&
>>> seq->color_config.subsampling_y == 0) {
>>> if (bit_depth == 8)
>>> @@ -477,7 +477,7 @@ static enum AVPixelFormat
>>> get_sw_pixel_format(AVCodecContext *avctx,
>>> else if (bit_depth == 12)
>>> pix_fmt = AV_PIX_FMT_YUV422P12;
>>> else
>>> - av_log(avctx, AV_LOG_WARNING, "Unknown AV1 pixel
>>> format.\n");
>>> + av_log(logctx, AV_LOG_WARNING, "Unknown AV1 pixel
>>> format.\n");
>>> } else if (seq->color_config.subsampling_x == 1 &&
>>> seq->color_config.subsampling_y == 1) {
>>> if (bit_depth == 8)
>>> @@ -487,7 +487,7 @@ static enum AVPixelFormat
>>> get_sw_pixel_format(AVCodecContext *avctx,
>>> else if (bit_depth == 12)
>>> pix_fmt = AV_PIX_FMT_YUV420P12;
>>> else
>>> - av_log(avctx, AV_LOG_WARNING, "Unknown AV1 pixel
>>> format.\n");
>>> + av_log(logctx, AV_LOG_WARNING, "Unknown AV1 pixel
>>> format.\n");
>>> }
>>> } else {
>>> if (bit_depth == 8)
>>> @@ -497,7 +497,7 @@ static enum AVPixelFormat
>>> get_sw_pixel_format(AVCodecContext *avctx,
>>> else if (bit_depth == 12)
>>> pix_fmt = AV_PIX_FMT_GRAY12;
>>> else
>>> - av_log(avctx, AV_LOG_WARNING, "Unknown AV1 pixel
>>> format.\n");
>>> + av_log(logctx, AV_LOG_WARNING, "Unknown AV1 pixel
>>> format.\n");
>>> }
>>> return pix_fmt;
>>
>> Will apply this patchset tonight unless there are objections.
>
> Not against it, but this reminds me I'd really like a way to pass a
> const pointer to av_log().
In this case you should take a look at bsf.c whose item_name callback
modifies the underlying AVClass-enabled context. (It also does not
bother with error checks.)
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH 3/3] h264: fix data-race with FF_DECODE_ERROR_DECODE_SLICES
On Tue, Sep 12, 2023, at 15:11, Andreas Rheinhardt wrote:
> Thomas Guillem via ffmpeg-devel:
>> Same than the previous commit but with FF_DECODE_ERROR_DECODE_SLICES
>>
>> Fix the following data-race:
>>
>> WARNING: ThreadSanitizer: data race (pid=55935)
>> Write of size 4 at 0x7b509378 by thread T1 (mutexes: write M608):
>> #0 decode_nal_units src/libavcodec/h264dec.c:742 (ffmpeg+0xb19dd6)
>> #1 h264_decode_frame src/libavcodec/h264dec.c:1016 (ffmpeg+0xb19dd6)
>> #2 frame_worker_thread src/libavcodec/pthread_frame.c:228
>> (ffmpeg+0xdeea7e)
>>
>> Previous read of size 4 at 0x7b509378 by thread T14 (mutexes: write
>> M610):
>> #0 frame_copy_props src/libavutil/frame.c:321 (ffmpeg+0x1793759)
>> #1 av_frame_replace src/libavutil/frame.c:530 (ffmpeg+0x1794714)
>> #2 ff_thread_replace_frame src/libavcodec/utils.c:898 (ffmpeg+0xfb1d0f)
>> #3 ff_h264_replace_picture src/libavcodec/h264_picture.c:159
>> (ffmpeg+0x149cd3d)
>> #4 ff_h264_update_thread_context src/libavcodec/h264_slice.c:413
>> (ffmpeg+0x14abf04)
>> #5 update_context_from_thread src/libavcodec/pthread_frame.c:355
>> (ffmpeg+0xdec39c)
>> #6 submit_packet src/libavcodec/pthread_frame.c:494 (ffmpeg+0xdecee3)
>> #7 ff_thread_decode_frame src/libavcodec/pthread_frame.c:545
>> (ffmpeg+0xdecee3)
>> #8 decode_simple_internal src/libavcodec/decode.c:431 (ffmpeg+0x9e1e20)
>> #9 decode_simple_receive_frame src/libavcodec/decode.c:607
>> (ffmpeg+0x9e1e20)
>> #10 decode_receive_frame_internal src/libavcodec/decode.c:635
>> (ffmpeg+0x9e1e20)
>> #11 avcodec_send_packet src/libavcodec/decode.c:732 (ffmpeg+0x9e28fa)
>> #12 packet_decode src/fftools/ffmpeg_dec.c:555 (ffmpeg+0x229888)
>> #13 decoder_thread src/fftools/ffmpeg_dec.c:702 (ffmpeg+0x229888)
>> ---
>> libavcodec/h264dec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
>> index 24e849fc5b..b82ca8f14f 100644
>> --- a/libavcodec/h264dec.c
>> +++ b/libavcodec/h264dec.c
>> @@ -739,7 +739,7 @@ static int decode_nal_units(H264Context *h, const
>> uint8_t *buf, int buf_size)
>>
>> // set decode_error_flags to allow users to detect concealed decoding
>> errors
>> if ((ret < 0 || h->er.error_occurred) && h->cur_pic_ptr) {
>> -h->cur_pic_ptr->f->decode_error_flags |=
>> FF_DECODE_ERROR_DECODE_SLICES;
>> +h->cur_pic_ptr->decode_error_flags |= FF_DECODE_ERROR_DECODE_SLICES;
>> }
>>
>> ret = 0;
>
> IIRC this does not work: The thread that decodes a frame is typically
> not the same thread that outputs said frame. The H264Picture srcp in
> output_frame() points to one of the H264Picture in the H264Context.DBP
> of the outputting thread, not the decoding thread. The outputting
> threads decode_error_flags will therefore always be zero.
>
> My preferred way to fix this is to allocate the H264Pictures (or at
> least the stuff needed by later decoding threads) separately and make
> them shared between decoder threads (with the caveat that only the
> actual decoding threads may modify them; and they may only do so in a
> controlled manner (i.e. no changes after having signalled to finish the
> picture etc.). But this would be a major rewrite which will probably
> never happen.
>
> In the meantime i will send an alternative patch for this.
Thanks for your patches and your clear explanations !
>
> - Andreas
>
> ___
> 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".
___
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".
