[FFmpeg-devel] [PATCH] avcodec/proresdec2: Rename to proresdec
Once upon a time, there used to be a LGPL and a GPL ProRes decoder
in FFmpeg; the current decoder evolved from the second of these.
But given that it is now the only ProRes decoder we have, it's file
should simply be named proresdec.c (which also brings it in line with
its header).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/Makefile | 2 +-
libavcodec/{proresdec2.c => proresdec.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename libavcodec/{proresdec2.c => proresdec.c} (100%)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index eef936944d..8c8c2ce659 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -608,7 +608,7 @@ OBJS-$(CONFIG_PNG_DECODER) += png.o pngdec.o
pngdsp.o
OBJS-$(CONFIG_PNG_ENCODER) += png.o pngenc.o
OBJS-$(CONFIG_PPM_DECODER) += pnmdec.o pnm.o
OBJS-$(CONFIG_PPM_ENCODER) += pnmenc.o
-OBJS-$(CONFIG_PRORES_DECODER) += proresdec2.o proresdsp.o proresdata.o
+OBJS-$(CONFIG_PRORES_DECODER) += proresdec.o proresdsp.o proresdata.o
OBJS-$(CONFIG_PRORES_ENCODER) += proresenc_anatoliy.o proresdata.o
OBJS-$(CONFIG_PRORES_AW_ENCODER) += proresenc_anatoliy.o proresdata.o
OBJS-$(CONFIG_PRORES_KS_ENCODER) += proresenc_kostya.o proresdata.o
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec.c
similarity index 100%
rename from libavcodec/proresdec2.c
rename to libavcodec/proresdec.c
--
2.40.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] [PATCH] avformat/rtmpproto: Don't free AVOpt-strings manually, fix crash
Andreas Rheinhardt: > Besides being redundant, freeing manually is actually harmful here, > as rtmp_close() may call gen_fcunpublish_stream() which dereferences > rt->playpath. > > Reported-by: Armin Hasitzka > Signed-off-by: Andreas Rheinhardt > --- > libavformat/rtmpproto.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c > index 4b01b67d28..b1d73b3d75 100644 > --- a/libavformat/rtmpproto.c > +++ b/libavformat/rtmpproto.c > @@ -2917,9 +2917,6 @@ reconnect: > return 0; > > fail: > -av_freep(>playpath); > -av_freep(>tcurl); > -av_freep(>flashver); > av_dict_free(opts); > rtmp_close(s); > return ret; I am pinging this and explicitly cc'ing Steven Liu, whose commit 991cf95fdeebc3af added the av_freeps to be removed above. Steven, did you just feel that there was missing freeing code for the buffers above or was there an actually confirmed memleak (there shouldn't be)? - 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 v2 12/12] avcodec/vlc: Use union of uint8_t and uint16_t in VLC_MULTI_ELEM
It is more natural and simplifies writing these arrays.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/bitstream_template.h | 2 +-
libavcodec/vlc.c| 10 +-
libavcodec/vlc.h| 5 -
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/libavcodec/bitstream_template.h b/libavcodec/bitstream_template.h
index c8e4a5131e..bbb8dfa555 100644
--- a/libavcodec/bitstream_template.h
+++ b/libavcodec/bitstream_template.h
@@ -542,7 +542,7 @@ static inline int BS_FUNC(read_vlc_multi)(BSCTX *bc,
uint8_t dst[8],
unsigned idx = BS_FUNC(peek)(bc, bits);
int ret, nb_bits, code, n = Jtable[idx].len;
if (Jtable[idx].num) {
-AV_COPY64U(dst, Jtable[idx].val);
+AV_COPY64U(dst, Jtable[idx].val8);
ret = Jtable[idx].num;
} else {
code = table[idx].sym;
diff --git a/libavcodec/vlc.c b/libavcodec/vlc.c
index e01cc41689..ee09d96fd6 100644
--- a/libavcodec/vlc.c
+++ b/libavcodec/vlc.c
@@ -440,8 +440,8 @@ static void add_level(VLC_MULTI_ELEM *table, const int
is16bit,
code = curcode + (buf[t].code >> curlen);
newlimit = curlimit - l;
l += curlen;
-if (is16bit) AV_WN16(info.val+2*curlevel, sym);
-else info.val[curlevel] = sym&0xFF;
+if (is16bit) info.val16[curlevel] = sym;
+else info.val8[curlevel] = sym&0xFF;
if (curlevel) { // let's not add single entries
uint32_t val = code >> (32 - numbits);
@@ -468,7 +468,7 @@ static int vlc_multi_gen(VLC_MULTI_ELEM *table, const VLC
*single,
{
int minbits, maxbits, max;
unsigned count[VLC_MULTI_MAX_SYMBOLS-1] = { 0, };
-VLC_MULTI_ELEM info = { { 0, }, 0, 0, };
+VLC_MULTI_ELEM info = { 0 };
int count0 = 0;
for (int j = 0; j < 1table[j].len > 0 ? 1 : 0;
if (is16bit)
-AV_WN16(table[j].val, single->table[j].sym);
+table[j].val16[0] = single->table[j].sym;
else
-table[j].val[0] = single->table[j].sym;
+table[j].val8[0] = single->table[j].sym;
}
add_level(table, is16bit, nb_codes, numbits, buf,
diff --git a/libavcodec/vlc.h b/libavcodec/vlc.h
index 0cc106c499..bf7b0e65b4 100644
--- a/libavcodec/vlc.h
+++ b/libavcodec/vlc.h
@@ -40,7 +40,10 @@ typedef struct VLC {
} VLC;
typedef struct VLC_MULTI_ELEM {
-uint8_t val[VLC_MULTI_MAX_SYMBOLS];
+union {
+uint8_t val8[VLC_MULTI_MAX_SYMBOLS];
+uint16_t val16[VLC_MULTI_MAX_SYMBOLS / 2];
+};
int8_t len; // -31,32
uint8_t num;
} VLC_MULTI_ELEM;
--
2.40.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 12/12] avcodec/vlc: Use union of uint8_t and uint16_t in VLC_MULTI_ELEM
It is more natural and simplifies writing these arrays.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/bitstream_template.h | 2 +-
libavcodec/vlc.c| 8
libavcodec/vlc.h| 5 -
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavcodec/bitstream_template.h b/libavcodec/bitstream_template.h
index c8e4a5131e..bbb8dfa555 100644
--- a/libavcodec/bitstream_template.h
+++ b/libavcodec/bitstream_template.h
@@ -542,7 +542,7 @@ static inline int BS_FUNC(read_vlc_multi)(BSCTX *bc,
uint8_t dst[8],
unsigned idx = BS_FUNC(peek)(bc, bits);
int ret, nb_bits, code, n = Jtable[idx].len;
if (Jtable[idx].num) {
-AV_COPY64U(dst, Jtable[idx].val);
+AV_COPY64U(dst, Jtable[idx].val8);
ret = Jtable[idx].num;
} else {
code = table[idx].sym;
diff --git a/libavcodec/vlc.c b/libavcodec/vlc.c
index e01cc41689..e89866e869 100644
--- a/libavcodec/vlc.c
+++ b/libavcodec/vlc.c
@@ -440,8 +440,8 @@ static void add_level(VLC_MULTI_ELEM *table, const int
is16bit,
code = curcode + (buf[t].code >> curlen);
newlimit = curlimit - l;
l += curlen;
-if (is16bit) AV_WN16(info.val+2*curlevel, sym);
-else info.val[curlevel] = sym&0xFF;
+if (is16bit) info.val16[curlevel] = sym;
+else info.val8[curlevel] = sym&0xFF;
if (curlevel) { // let's not add single entries
uint32_t val = code >> (32 - numbits);
@@ -500,9 +500,9 @@ static int vlc_multi_gen(VLC_MULTI_ELEM *table, const VLC
*single,
table[j].len = single->table[j].len;
table[j].num = single->table[j].len > 0 ? 1 : 0;
if (is16bit)
-AV_WN16(table[j].val, single->table[j].sym);
+table[j].val16[0] = single->table[j].sym;
else
-table[j].val[0] = single->table[j].sym;
+table[j].val8[0] = single->table[j].sym;
}
add_level(table, is16bit, nb_codes, numbits, buf,
diff --git a/libavcodec/vlc.h b/libavcodec/vlc.h
index 0cc106c499..bf7b0e65b4 100644
--- a/libavcodec/vlc.h
+++ b/libavcodec/vlc.h
@@ -40,7 +40,10 @@ typedef struct VLC {
} VLC;
typedef struct VLC_MULTI_ELEM {
-uint8_t val[VLC_MULTI_MAX_SYMBOLS];
+union {
+uint8_t val8[VLC_MULTI_MAX_SYMBOLS];
+uint16_t val16[VLC_MULTI_MAX_SYMBOLS / 2];
+};
int8_t len; // -31,32
uint8_t num;
} VLC_MULTI_ELEM;
--
2.40.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 11/12] avcodec/vlc, bitstream: Fix multi VLC with uint8_t syms on BE
VLC_MULTI_ELEM contains an uint8_t array that is supposed
to be treated as an array of uint16_t when the used symbols
have a size of two; otherwise it should be treated as just
an array of uint8_t, but it was not always treated that way:
vlc_multi_gen() initialized the first entry of the array
by writing the symbol via AV_WN16; on big endian systems,
the intended value was instead written into the second entry
of the array (where it would likely be overwritten lateron
during initialization).
read_vlc_multi() also treated this case incorrectly: In case
the code is so long that it needs a classical multi-stage lookup,
the symbol has been written to the destination as if via AV_WN16.
On little endian systems, this sets the correct first symbol and
clobbers (zeroes) the next one, but the next one will be overwritten
lateron anyway, so it won't be recognized. But on big-endian systems,
the first symbol will be set to zero and the actually read symbol
will be put into the slot for the next one (where it will be overwritten
lateron).
This commit fixes this; this fixes the magicyuv and utvideo FATE-tests
on big endian arches.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/bitstream_template.h | 8 ++--
libavcodec/get_bits.h | 3 ++-
libavcodec/magicyuv.c | 2 +-
libavcodec/utvideodec.c | 2 +-
libavcodec/vlc.c| 5 -
5 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavcodec/bitstream_template.h b/libavcodec/bitstream_template.h
index 4f3d07275f..c8e4a5131e 100644
--- a/libavcodec/bitstream_template.h
+++ b/libavcodec/bitstream_template.h
@@ -536,7 +536,8 @@ static inline int BS_FUNC(read_vlc)(BSCTX *bc, const
VLCElem *table,
static inline int BS_FUNC(read_vlc_multi)(BSCTX *bc, uint8_t dst[8],
const VLC_MULTI_ELEM *const Jtable,
const VLCElem *const table,
- const int bits, const int max_depth)
+ const int bits, const int max_depth,
+ const int symbols_size)
{
unsigned idx = BS_FUNC(peek)(bc, bits);
int ret, nb_bits, code, n = Jtable[idx].len;
@@ -554,7 +555,10 @@ static inline int BS_FUNC(read_vlc_multi)(BSCTX *bc,
uint8_t dst[8],
code = BS_FUNC(priv_set_idx)(bc, code, , _bits, table);
}
}
-AV_WN16(dst, code);
+if (symbols_size == 1)
+*dst = code;
+else
+AV_WN16(dst, code);
ret = n > 0;
}
BS_FUNC(priv_skip_remaining)(bc, n);
diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index cfcf97c021..fe2f6378b4 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -667,7 +667,8 @@ static av_always_inline int get_vlc2(GetBitContext *s,
const VLCElem *table,
static inline int get_vlc_multi(GetBitContext *s, uint8_t *dst,
const VLC_MULTI_ELEM *const Jtable,
const VLCElem *const table,
-const int bits, const int max_depth)
+const int bits, const int max_depth,
+const int symbols_size)
{
dst[0] = get_vlc2(s, table, bits, max_depth);
return 1;
diff --git a/libavcodec/magicyuv.c b/libavcodec/magicyuv.c
index 3f6348b531..4f30493626 100644
--- a/libavcodec/magicyuv.c
+++ b/libavcodec/magicyuv.c
@@ -124,7 +124,7 @@ static void magicyuv_median_pred16(uint16_t *dst, const
uint16_t *src1,
x = 0; \
for (; CACHED_BITSTREAM_READER && x < width-c && get_bits_left() > 0;)
{\
ret = get_vlc_multi(, (uint8_t *)dst + x * b, multi, \
-vlc, vlc_bits, 3); \
+vlc, vlc_bits, 3, b); \
if (ret <= 0) \
return AVERROR_INVALIDDATA; \
x += ret; \
diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
index ce5d00f7af..0c2e67e282 100644
--- a/libavcodec/utvideodec.c
+++ b/libavcodec/utvideodec.c
@@ -120,7 +120,7 @@ static int build_huff(UtvideoContext *c, const uint8_t
*src, VLC *vlc,
i = 0; \
for (; CACHED_BITSTREAM_READER && i < width-end && get_bits_left() >
0;) {\
ret = get_vlc_multi(, (uint8_t *)buf + i * b, multi.table, \
-vlc.table, VLC_BITS, 3); \
+vlc.table, VLC_BITS, 3, b); \
if (ret > 0) \
i += ret; \
if (ret <= 0) \
diff --git a/libavcodec/vlc.c b/libavcodec/vlc.c
index 78510e30d6..e01cc41689 100644
--- a/libavcodec/vlc.c
+++ b/libavcodec/vlc.c
@@ -499,7 +499,10 @@ static int vlc_multi_gen(VLC_MULTI_ELEM *table, const VLC
*single,
for (int j = 0; j < 1table[j].len > 0 ? 1 : 0;
-AV_WN16(table[j].val, single->table[j].sym);
+if (is16bit)
+
[FFmpeg-devel] [PATCH 10/12] fate/fits: Fix tests on BE
The fits decoder decodes to native pixel formats; so the fitsdec-gbrap16be fate test failed on BE despite its name because the reference file is LE. This patch fixes this by forcing a pixel format; the forced pixel format is BE, causing a change in the reference file. The fitsdec-gbrp16be test was not affected, because its source file (lena-rgb48.png from tne FATE suite) is actually biendian (as if someone had multiplied 8bit content by 257...). Signed-off-by: Andreas Rheinhardt --- tests/fate/fits.mak | 2 +- tests/ref/fate/fitsdec-gbrap16be | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/fate/fits.mak b/tests/fate/fits.mak index d85946bc1a..b83900aaee 100644 --- a/tests/fate/fits.mak +++ b/tests/fate/fits.mak @@ -28,7 +28,7 @@ fate-fitsdec-multi: tests/data/fits-multi.fits fate-fitsdec-multi: CMD = framecrc -i $(TARGET_PATH)/tests/data/fits-multi.fits -pix_fmt gbrap fate-fitsdec%: PIXFMT = $(word 3, $(subst -, ,$(@))) -fate-fitsdec%: CMD = transcode image2 $(TARGET_SAMPLES)/png1/lena-$(fits-png-map-$(PIXFMT)).png fits "-vf scale -pix_fmt $(PIXFMT)" +fate-fitsdec%: CMD = transcode image2 $(TARGET_SAMPLES)/png1/lena-$(fits-png-map-$(PIXFMT)).png fits "-vf scale -pix_fmt $(PIXFMT)" "-vf scale -pix_fmt $(PIXFMT)" FATE_FITS_DEC_PIXFMT = gray gbrp gbrp16be gbrap16be FATE_FITS_DEC-$(call TRANSCODE, FITS, FITS, IMAGE2_DEMUXER PNG_DECODER SCALE_FILTER) += $(FATE_FITS_DEC_PIXFMT:%=fate-fitsdec-%) diff --git a/tests/ref/fate/fitsdec-gbrap16be b/tests/ref/fate/fitsdec-gbrap16be index 1174a0f1d8..e57a878845 100644 --- a/tests/ref/fate/fitsdec-gbrap16be +++ b/tests/ref/fate/fitsdec-gbrap16be @@ -5,4 +5,4 @@ #codec_id 0: rawvideo #dimensions 0: 128x128 #sar 0: 0/1 -0, 0, 0,1, 131072, 0x487894b2 +0, 0, 0,1, 131072, 0xebb194b2 -- 2.40.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] [PATCH] lavf/movenc: mark mov/mp4 as supporting VFR
On Fri, Mar 29, 2024 at 09:35:09AM +0100, Anton Khirnov wrote: > --- > libavformat/movenc.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) can you add a fate test for this ? its odd we have no single test that changes from this thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. 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".
Re: [FFmpeg-devel] [PATCH v10 2/5] avformat/rcwtdec: add RCWT Closed Captions demuxer
On Thu, Mar 28, 2024 at 03:11:29PM -0500, Marth64 wrote:
[...]
> +static int rcwt_probe(const AVProbeData *p)
> +{
> +return p->buf_size > RCWT_HEADER_SIZE &&
> + AV_RB16(p->buf) == 0x&&
> + AV_RB8(p->buf + 2) == 0xED &&
> + AV_RB16(p->buf + 6) == 0x0001? 50 : 0;
> +}
> +
> +const FFInputFormat ff_rcwt_demuxer = {
> +.p.name = "rcwt",
> +.p.long_name= NULL_IF_CONFIG_SMALL("RCWT (Raw Captions With Time)"),
> +.p.extensions = "bin",
this causes a mp3 i have to be misdetected
~/videos/sbQ9.bin
(this is a actual file i had not a file crafted for this)
i think the entry for extensions should be removed (which fixes this)
having a ".bin" is not a strong indication that its rcwt
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] [PATCH 1/2] lavf/subtitles: Add ff_text_peek_r16(), only accept \r, \n, \r\n and \r\r\n line endings
Here's an alternative first patch that rolls patch 1+3 into one. I'd
like some feedback on this before I continue hacking on patch 2. While
I don't like that we accept any old broken srt file, especially without
knowing what software made it, I'm not completely opposed to
compromising in this specific case. But I'd rather we didn't, and stuck
to \r, \n and \r\n. What I really don't want is runs of \r being eaten
without being "terminated" by a \n, because this messes up Mac support.
/Tomas
From 2ec68c51e4599b8493a2e103793f571451d872d3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 28 Mar 2024 20:30:37 +0100
Subject: [PATCH 1/2] lavf/subtitles: Add ff_text_peek_r16(), only accept \r,
\n, \r\n and \r\r\n line endings
---
libavformat/subtitles.c | 53 +
libavformat/subtitles.h | 5
2 files changed, 53 insertions(+), 5 deletions(-)
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index 3413763c7b..01187df6ab 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -22,6 +22,7 @@
#include "subtitles.h"
#include "avio_internal.h"
#include "libavutil/avstring.h"
+#include "libavutil/intreadwrite.h"
void ff_text_init_avio(void *s, FFTextReader *r, AVIOContext *pb)
{
@@ -106,6 +107,42 @@ int ff_text_peek_r8(FFTextReader *r)
return c;
}
+int ff_text_peek_r16(FFTextReader *r)
+{
+int c1, c2;
+if (r->buf_pos < r->buf_len - 1)
+return AV_RB16(>buf[r->buf_pos]);
+
+// missing one or two bytes
+c1 = ff_text_r8(r);
+if (avio_feof(r->pb))
+return 0;
+
+if (r->buf_pos == r->buf_len - 1) {
+// missing one byte
+r->buf[0] = r->buf[r->buf_pos];
+r->buf[1] = c1;
+r->buf_pos = 0;
+r->buf_len = 2;
+return AV_RB16(r->buf);
+}
+
+// missing two bytes
+c2 = ff_text_r8(r);
+if (avio_feof(r->pb)) {
+r->buf[0] = c1;
+r->buf_pos = 0;
+r->buf_len = 1;
+return 0;
+}
+
+r->buf[0] = c1;
+r->buf[1] = c2;
+r->buf_pos = 0;
+r->buf_len = 2;
+return AV_RB16(r->buf);
+}
+
AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue *q,
const uint8_t *event, size_t len, int merge)
{
@@ -446,11 +483,12 @@ int ff_subtitles_read_chunk(AVIOContext *pb, AVBPrint *buf)
ptrdiff_t ff_subtitles_read_line(FFTextReader *tr, char *buf, size_t size)
{
size_t cur = 0;
+unsigned char c;
if (!size)
return 0;
buf[0] = '\0';
while (cur + 1 < size) {
-unsigned char c = ff_text_r8(tr);
+c = ff_text_r8(tr);
if (!c)
return ff_text_eof(tr) ? cur : AVERROR_INVALIDDATA;
if (c == '\r' || c == '\n')
@@ -458,9 +496,14 @@ ptrdiff_t ff_subtitles_read_line(FFTextReader *tr, char *buf, size_t size)
buf[cur++] = c;
buf[cur] = '\0';
}
-while (ff_text_peek_r8(tr) == '\r')
-ff_text_r8(tr);
-if (ff_text_peek_r8(tr) == '\n')
-ff_text_r8(tr);
+if (c == '\r') {
+if (ff_text_peek_r8(tr) == '\n')
+ff_text_r8(tr);
+else if (ff_text_peek_r16(tr) == AV_RB16("\r\n")) {
+// ticket5032-rrn.srt has \r\r\n
+ff_text_r8(tr);
+ff_text_r8(tr);
+}
+}
return cur;
}
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index 88665663c5..2a92044976 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -94,6 +94,11 @@ int ff_text_eof(FFTextReader *r);
*/
int ff_text_peek_r8(FFTextReader *r);
+/**
+ * Like ff_text_peek_r8(), but peek two bytes and return them as a big-endian number.
+ */
+int ff_text_peek_r16(FFTextReader *r);
+
/**
* Read the given number of bytes (in UTF-8). On error or EOF, \0 bytes are
* written.
--
2.39.2
___
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 2/3] lavf/srtdec: Permit streaming input
lör 2024-03-30 klockan 00:35 +0100 skrev Michael Niedermayer: > On Thu, Mar 28, 2024 at 11:57:57PM +0100, Tomas Härdin wrote: > > Here as well > > > libavformat/srtdec.c | 211 -- > > - > > tests/ref/fate/sub-srt-rrn-remux | 4 > > 2 files changed, 116 insertions(+), 99 deletions(-) > > 699d8b957286e190de6d5ca5cd17e67bb59dab7c 0002-lavf-srtdec-Permit- > > streaming-input.patch > > From 6d0684ca6fe02d80fc07a622fb85445a6917c29f Mon Sep 17 00:00:00 > > 2001 > > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= > > Date: Thu, 28 Mar 2024 22:15:18 +0100 > > Subject: [PATCH 2/3] lavf/srtdec: Permit streaming input > > > > This is largely a rewrite. > > > > Read packets in srt_read_packet() rather than reading the entire > > file in srt_read_header(). > > Rely on AVFMT_GENERIC_INDEX for seeking. > > Allow zero-length packets (same as WebVTT). > > The implementation before this is broken in at least the following > > ways: > > > > Decimals like .99 are silently accepted and converted to > > 999.999 seconds. > > This is because no verification is done on the milliseconds part. > > This patch enforces that the minutes and seconds parts are 00-59, > > and the milliseconds 000-999. > > It's not perfect since FFmpeg doesn't have regex functionality or > > indeed any kind of parsing framework, > > but it's better than before. > > > > Segmenting cues by lines that consist of just a single integer is > > incredibly wrong, > > since the subtitle text itself may well contain lines that are just > > a lone integer. > > This means files written with CR line endings that have text with > > lone integers are > > parsed in a completely broken manner. Neither can we segment by > > lines containing --> > > since this is permissible in SubRip (as far as I can tell). WebVTT > > explicitly forbids it however. > > --- > > libavformat/srtdec.c | 211 --- > > > > tests/ref/fate/sub-srt-rrn-remux | 4 + > > 2 files changed, 116 insertions(+), 99 deletions(-) > > breaks fate here: > > --- ./tests/ref/fate/sub-srt-madness-timeshift 2024-03-29 > 20:43:34.617419731 +0100 > +++ tests/data/fate/sub-srt-madness-timeshift 2024-03-30 > 00:30:08.776949369 +0100 > @@ -3,34 +3,7 @@ > okay, let's make things easy > > 2 > -00:00:05,160 --> 00:00:05,263 > -31 i'm a number but the only payload so please keep me :) > - > -3 > 00:00:06,473 --> 00:00:07,584 > hello > 5 > -don't forget me. > - > -4 > -00:00:08,695 --> 00:00:09,806 > -no. > -let's add some fun > - > -5 > -00:00:10,917 --> 00:00:12,028 > -let's do it in reverse bc wtf not > -45 yes this is a number but i'm actually part of the sub > - > -6 > -00:00:12,028 --> 00:00:13,139 > -1 > -0 > -next is negative, not a chapnum ;) > --1 > - > -7 > -00:00:13,241 --> 00:00:13,263 > -credits > -2015 > > Test sub-srt-madness-timeshift failed. Look at tests/data/fate/sub- > srt-madness-timeshift.err for details. > tests/Makefile:309: recipe for target 'fate-sub-srt-madness- > timeshift' failed > make: *** [fate-sub-srt-madness-timeshift] Error 1 Can confirm. I was busy with fate-sub-srt-rrn-remux which popped up when running fate that I forgot to run a full fate after fixing it. Will submit a new patch series later /Tomas ___ 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] doc/muxers: add stub for iamf
On Fri, Mar 29, 2024 at 12:47:53PM +0100, Stefano Sabatini wrote:
> ---
> doc/muxers.texi | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index f300f8c45f..23506e2ab7 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -2515,6 +2515,22 @@ Ignore IO errors during open, write and delete. Useful
> for long-duration runs wi
> Set custom HTTP headers, can override built in default headers. Applicable
> only for HTTP output.
> @end table
>
> +@section{iamf}
> +
> +Immersive Audio Model and Formats (IAMF) muxer.
> +
> +IAMF is used to provide immersive audio content for presentation on a wide
> range
> +of devices in both streaming and offline applications. These applications
> +include internet audio streaming, multicasting/broadcasting services, file
> +download, gaming, communication, virtual and augmented reality, and others.
> In
> +these applications, audio may be played back on a wide range of devices,
> e.g.,
> +headphones, mobile phones, tablets, TVs, sound bars, home theater systems,
> and
> +big screens.
> +
> +This format was promoted and desgined by Alliance for Open Media.
> +
> +For more information about this format, see @url{https://aomedia.org/iamf/}.
> +
this seems to cause
*** '}' without opening '{' before:
*** '{' without macro. Before: iamf}
*** '}' without opening '{' before:
*** '{' without macro. Before: iamf}
*** '}' without opening '{' before:
*** '}' without opening '{' before:
*** '}' without opening '{' before:
*** '{' without macro. Before: iamf}
*** '}' without opening '{' before:
*** '}' without opening '{' before:
*** '{' without macro. Before: iamf}
*** '}' without opening '{' before:
*** '{' without macro. Before: iamf}
*** '}' without opening '{' before:
*** '}' without opening '{' before:
*** '}' without opening '{' before:
*** '{' without macro. Before: iamf}
*** '}' without opening '{' before:
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
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".
Re: [FFmpeg-devel] [PATCH 2/3] lavf/srtdec: Permit streaming input
On Thu, Mar 28, 2024 at 11:57:57PM +0100, Tomas Härdin wrote: > Here as well > libavformat/srtdec.c | 211 > --- > tests/ref/fate/sub-srt-rrn-remux |4 > 2 files changed, 116 insertions(+), 99 deletions(-) > 699d8b957286e190de6d5ca5cd17e67bb59dab7c > 0002-lavf-srtdec-Permit-streaming-input.patch > From 6d0684ca6fe02d80fc07a622fb85445a6917c29f Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= > Date: Thu, 28 Mar 2024 22:15:18 +0100 > Subject: [PATCH 2/3] lavf/srtdec: Permit streaming input > > This is largely a rewrite. > > Read packets in srt_read_packet() rather than reading the entire file in > srt_read_header(). > Rely on AVFMT_GENERIC_INDEX for seeking. > Allow zero-length packets (same as WebVTT). > The implementation before this is broken in at least the following ways: > > Decimals like .99 are silently accepted and converted to 999.999 seconds. > This is because no verification is done on the milliseconds part. > This patch enforces that the minutes and seconds parts are 00-59, and the > milliseconds 000-999. > It's not perfect since FFmpeg doesn't have regex functionality or indeed any > kind of parsing framework, > but it's better than before. > > Segmenting cues by lines that consist of just a single integer is incredibly > wrong, > since the subtitle text itself may well contain lines that are just a lone > integer. > This means files written with CR line endings that have text with lone > integers are > parsed in a completely broken manner. Neither can we segment by lines > containing --> > since this is permissible in SubRip (as far as I can tell). WebVTT explicitly > forbids it however. > --- > libavformat/srtdec.c | 211 --- > tests/ref/fate/sub-srt-rrn-remux | 4 + > 2 files changed, 116 insertions(+), 99 deletions(-) breaks fate here: --- ./tests/ref/fate/sub-srt-madness-timeshift 2024-03-29 20:43:34.617419731 +0100 +++ tests/data/fate/sub-srt-madness-timeshift 2024-03-30 00:30:08.776949369 +0100 @@ -3,34 +3,7 @@ okay, let's make things easy 2 -00:00:05,160 --> 00:00:05,263 -31 i'm a number but the only payload so please keep me :) - -3 00:00:06,473 --> 00:00:07,584 hello 5 -don't forget me. - -4 -00:00:08,695 --> 00:00:09,806 -no. -let's add some fun - -5 -00:00:10,917 --> 00:00:12,028 -let's do it in reverse bc wtf not -45 yes this is a number but i'm actually part of the sub - -6 -00:00:12,028 --> 00:00:13,139 -1 -0 -next is negative, not a chapnum ;) --1 - -7 -00:00:13,241 --> 00:00:13,263 -credits -2015 Test sub-srt-madness-timeshift failed. Look at tests/data/fate/sub-srt-madness-timeshift.err for details. tests/Makefile:309: recipe for target 'fate-sub-srt-madness-timeshift' failed make: *** [fate-sub-srt-madness-timeshift] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. 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".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: fix overriding unknown channel layouts with negotiated one
On Sat, 23 Mar 2024, Marton Balint wrote:
Fixes ffplay playback of unknown layouts, when SDL directly supports the audio
format, such as:
ffplay -f lavfi anullsrc=cl=2C,aformat=s16
Without the patch, "Channel layout change is not supported" errors are
generated because buffersrc (unknown 2 channel) and buffersink (stereo)
negotiated a stereo layout, but the stereo layout was never stored in the
BufferSourceContext.
This fixes a regression of 7251f909721a570726775acf61b2b9c28a950c76, but this
is more of a regression of the avfilter channel layout conversion
(1f96db959c1235bb7079d354e09914a0a2608f62).
Signed-off-by: Marton Balint
---
libavfilter/buffersrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index ddcd403785..fcae4f8e69 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -507,7 +507,7 @@ static int config_props(AVFilterLink *link)
}
break;
case AVMEDIA_TYPE_AUDIO:
-if (!c->ch_layout.nb_channels) {
+if (!c->ch_layout.nb_channels || c->ch_layout.order ==
AV_CHANNEL_ORDER_UNSPEC) {
int ret = av_channel_layout_copy(>ch_layout, >ch_layout);
if (ret < 0)
return ret;
Will apply and backport.
Regards,
Marton
___
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/6] avcodec/h264_refs: Rewrite code to make control flow clearer
Andreas Rheinhardt:
> While this change IMO makes the control flow clearer
> for the human reader, it is especially important for
> GCC: It erroneously believes that it is possible to
> enter the SHORT2(UNUSED|LONG) cases without having
> entered the preceding block that initializes pic,
> frame_num, structure and j; it would emit -Wmaybe-uninitialized
> warnings for these variables if they were not pseudo-
> initialized with av_uninit(). This patch allows to remove
> the latter.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/h264_refs.c | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> index 9bc7b20988..c2ba4b9b9e 100644
> --- a/libavcodec/h264_refs.c
> +++ b/libavcodec/h264_refs.c
> @@ -646,8 +646,9 @@ int ff_h264_execute_ref_pic_marking(H264Context *h)
> av_log(h->avctx, AV_LOG_DEBUG, "mmco:%d %d %d\n",
> h->mmco[i].opcode,
> h->mmco[i].short_pic_num, h->mmco[i].long_arg);
>
> -if (mmco[i].opcode == MMCO_SHORT2UNUSED ||
> -mmco[i].opcode == MMCO_SHORT2LONG) {
> +switch (mmco[i].opcode) {
> +case MMCO_SHORT2UNUSED:
> +case MMCO_SHORT2LONG:
> frame_num = pic_num_extract(h, mmco[i].short_pic_num,
> );
> pic = find_short(h, frame_num, );
> if (!pic) {
> @@ -659,16 +660,12 @@ int ff_h264_execute_ref_pic_marking(H264Context *h)
> }
> continue;
> }
> -}
> -
> -switch (mmco[i].opcode) {
> -case MMCO_SHORT2UNUSED:
> -if (h->avctx->debug & FF_DEBUG_MMCO)
> -av_log(h->avctx, AV_LOG_DEBUG, "mmco: unref short %d count
> %d\n",
> - h->mmco[i].short_pic_num, h->short_ref_count);
> -remove_short(h, frame_num, structure ^ PICT_FRAME);
> -break;
> -case MMCO_SHORT2LONG:
> +if (mmco[i].opcode == MMCO_SHORT2UNUSED) {
> +if (h->avctx->debug & FF_DEBUG_MMCO)
> +av_log(h->avctx, AV_LOG_DEBUG, "mmco: unref short %d
> count %d\n",
> + h->mmco[i].short_pic_num, h->short_ref_count);
> +remove_short(h, frame_num, structure ^ PICT_FRAME);
> +} else {
> if (h->long_ref[mmco[i].long_arg] != pic)
> remove_long(h, mmco[i].long_arg, 0);
>
> @@ -678,6 +675,7 @@ int ff_h264_execute_ref_pic_marking(H264Context *h)
> h->long_ref[mmco[i].long_arg]->long_ref = 1;
> h->long_ref_count++;
> }
> +}
> break;
> case MMCO_LONG2UNUSED:
> j = pic_num_extract(h, mmco[i].long_arg, );
Will apply the rest of 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] [RFC] clarifying the TC conflict of interest rule
On Fri, Mar 29, 2024 at 12:39:31PM +0100, Anton Khirnov wrote: > [...] if you have not voted yet please do so ASAP. +1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad 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] [PATCH 3/3] avformat/mxfdec: Check first case of offset_temp computation for overflow
This is kind of ugly
Fixes: signed integer overflow: 255 * 1157565362826411919 cannot be represented
in type 'long'
Fixes:
67313/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-6250434245230592
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index c9af4628555..fe86f516630 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1891,9 +1891,14 @@ static int mxf_edit_unit_absolute_offset(MXFContext
*mxf, MXFIndexTable *index_t
if (edit_unit < s->index_start_position + s->index_duration) {
int64_t index = edit_unit - s->index_start_position;
-if (s->edit_unit_byte_count)
+if (s->edit_unit_byte_count) {
+if (s->edit_unit_byte_count * (uint64_t)index /
s->edit_unit_byte_count != index ||
+s->edit_unit_byte_count * index > INT64_MAX - offset_temp
+)
+return AVERROR_INVALIDDATA;
+
offset_temp += s->edit_unit_byte_count * index;
-else {
+} else {
if (s->nb_index_entries == 2 * s->index_duration + 1)
index *= 2; /* Avid index */
--
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/jpeg2000htdec: warn about non zero roi shift
Suggested-by: Tomas Härdin Signed-off-by: Michael Niedermayer --- libavcodec/jpeg2000htdec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c index 6b9898d3ff2..4f0b10b4293 100644 --- a/libavcodec/jpeg2000htdec.c +++ b/libavcodec/jpeg2000htdec.c @@ -1198,6 +1198,9 @@ ff_jpeg2000_decode_htj2k(const Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c av_assert0(width * height <= 4096); av_assert0(width * height > 0); +if (roi_shift) +avpriv_report_missing_feature(s->avctx, "ROI shift"); + memset(t1->data, 0, t1->stride * height * sizeof(*t1->data)); memset(t1->flags, 0, t1->stride * (height + 2) * sizeof(*t1->flags)); -- 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] avcodec/jpeg2000htdec: Check magp before using it in a shift
Fixes: shift exponent -1 is negative
Fixes:
65378/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5457678193197056
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/jpeg2000dec.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index 1afc6b1e2dd..fe2afb05057 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1910,6 +1910,8 @@ static inline void tile_codeblocks(const
Jpeg2000DecoderContext *s, Jpeg2000Tile
int nb_precincts, precno;
Jpeg2000Band *band = rlevel->band + bandno;
int cblkno = 0, bandpos;
+/* See Rec. ITU-T T.800, Equation E-2 */
+int magp = quantsty->expn[subbandno] + quantsty->nguardbits -
1;
bandpos = bandno + (reslevelno > 0);
@@ -1917,6 +1919,9 @@ static inline void tile_codeblocks(const
Jpeg2000DecoderContext *s, Jpeg2000Tile
band->coord[1][0] == band->coord[1][1])
continue;
+if ((codsty->cblk_style & JPEG2000_CTSY_HTJ2K_F) && magp >= 31)
+return;
+
nb_precincts = rlevel->num_precincts_x *
rlevel->num_precincts_y;
/* Loop on precincts */
for (precno = 0; precno < nb_precincts; precno++) {
@@ -1927,8 +1932,6 @@ static inline void tile_codeblocks(const
Jpeg2000DecoderContext *s, Jpeg2000Tile
cblkno < prec->nb_codeblocks_width *
prec->nb_codeblocks_height;
cblkno++) {
int x, y, ret;
-/* See Rec. ITU-T T.800, Equation E-2 */
-int magp = quantsty->expn[subbandno] +
quantsty->nguardbits - 1;
Jpeg2000Cblk *cblk = prec->cblk + cblkno;
--
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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/liblc3: Add encoding/decoding support of LC3 audio codec
Antoine Soulier via ffmpeg-devel: > With free licensed code, I don't think that will happen; the core algorithm > is the same. > LC3 is like a subset of LC3plus, but also adds 7.5ms frame duration. > I acknowledged the use of only one Codec Id, because it makes sense to me > to distinguish both as different profiles / feature sets. > Moreover, LC3 and LC3plus declares both the 10ms frame duration. It's > impossible to distinguish such a stream as LC3 or LC3plus. > The main difference between the 2 codecs are licenses: > - LC3 will only be used, and is free to use, over Bluetooth on standard > profile claiming it. > - LC3plus can be used anywhere, but is under license fee. > > So it makes sense to me to cover both as LC3. Thanks for the convincing explanation. - 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 v2 9/9] fate/filter-video: Insert scale, format filters in filter-yadif, bwdif10
The format and the first scale filter ensures that the filter processing actually happens in high bit depth; the second scale filter is only necessary for big endian arches. Signed-off-by: Andreas Rheinhardt --- tests/fate/filter-video.mak | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index 681cddc33e..7f8dc3aa27 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -16,7 +16,7 @@ fate-filter-bwdif-mode0: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $( fate-filter-bwdif-mode1: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -frames:v 59 -vf bwdif=send_field FATE_BWDIF-$(call FILTERDEMDEC, BWDIF SCALE, MPEGTS, MPEG2VIDEO) += fate-filter-bwdif10 -fate-filter-bwdif10: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p10le -frames:v 30 -vf scale,bwdif=0 +fate-filter-bwdif10: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p10le -frames:v 30 -vf scale,format=yuv420p10,bwdif=0,scale FATE_FILTER_SAMPLES-yes += $(FATE_BWDIF-yes) @@ -25,8 +25,8 @@ fate-filter-yadif-mode0: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $( fate-filter-yadif-mode1: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -frames:v 59 -vf yadif=1 FATE_YADIF-$(call FILTERDEMDEC, YADIF SCALE, MPEGTS, MPEG2VIDEO) += fate-filter-yadif10 fate-filter-yadif16 -fate-filter-yadif10: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p10le -frames:v 30 -vf scale,yadif=0 -fate-filter-yadif16: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p16le -frames:v 30 -vf scale,yadif=0 +fate-filter-yadif10: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p10le -frames:v 30 -vf scale,format=yuv420p10,yadif=0,scale +fate-filter-yadif16: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p16le -frames:v 30 -vf scale,format=yuv420p16,yadif=0,scale FATE_FILTER_SAMPLES-yes += $(FATE_YADIF-yes) -- 2.40.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] [PATCH 1/2] avcodec/liblc3: Add encoding/decoding support of LC3 audio codec
With free licensed code, I don't think that will happen; the core algorithm is the same. LC3 is like a subset of LC3plus, but also adds 7.5ms frame duration. I acknowledged the use of only one Codec Id, because it makes sense to me to distinguish both as different profiles / feature sets. Moreover, LC3 and LC3plus declares both the 10ms frame duration. It's impossible to distinguish such a stream as LC3 or LC3plus. The main difference between the 2 codecs are licenses: - LC3 will only be used, and is free to use, over Bluetooth on standard profile claiming it. - LC3plus can be used anywhere, but is under license fee. So it makes sense to me to cover both as LC3. ___ 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/4] avutil/pix{desc, fmt}: add new matrix coefficients from H.273 v3
On Fri, Mar 29, 2024 at 2:33 AM Jan Ekström wrote:
>
> * SMPTE ST 2128 IPT-C2 defines the coefficients utilized in DoVi
> Profile 5. Profile 5 can thus now be represented in VUI as
> {AVCOL_RANGE_JPEG, AVCOL_PRI_BT2020, AVCOL_TRC_SMPTE2084,
>AVCOL_SPC_IPT_C2, AVCHROMA_LOC_LEFT} (although other chroma
> sample locations are allowed). AVCOL_TRC_SMPTE2084 should in
> this case be interpreted as 'PQ with reshaping'.
> * YCgCo-Re and YCgCo-Ro define the bitexact YCgCo-R, where the
> number of bits added to a source RGB bit depth is 2 (i.e., even)
> and 1 (i.e., odd), respectively.
> ---
> doc/APIchanges | 4
> libavutil/pixdesc.c | 3 +++
> libavutil/pixfmt.h | 3 +++
> libavutil/version.h | 2 +-
> 4 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index aa102b4925..296d87d8fb 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,10 @@ The last version increases of all libraries were on
> 2024-03-07
>
> API changes, most recent first:
>
> +2024-03-27 - xx - lavu 59.11.100 - pixfmt.h
> + Add AVCOL_SPC_IPT_C2, AVCOL_SPC_YCGCO_RE and AVCOL_SPC_YCGCO_RO
> + to map new matrix coefficients defined by H.273 v3.
> +
> 2024-03-27 - xx - lavu 59.10.100 - frame.h
>Add AVSideDataDescriptor, enum AVSideDataProps, and
>av_frame_side_data_desc().
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index 9c708520b1..1c0bcf2232 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -2854,6 +2854,9 @@ static const char * const color_space_names[] = {
> [AVCOL_SPC_CHROMA_DERIVED_NCL] = "chroma-derived-nc",
> [AVCOL_SPC_CHROMA_DERIVED_CL] = "chroma-derived-c",
> [AVCOL_SPC_ICTCP] = "ictcp",
> +[AVCOL_SPC_IPT_C2] = "ipt-c2",
> +[AVCOL_SPC_YCGCO_RE] = "ycgco-re",
> +[AVCOL_SPC_YCGCO_RO] = "ycgco-ro",
> };
>
> static const char * const chroma_location_names[] = {
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 4aa20e4e58..430118d3e1 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -623,6 +623,9 @@ enum AVColorSpace {
> AVCOL_SPC_CHROMA_DERIVED_NCL = 12, ///< Chromaticity-derived
> non-constant luminance system
> AVCOL_SPC_CHROMA_DERIVED_CL = 13, ///< Chromaticity-derived constant
> luminance system
> AVCOL_SPC_ICTCP = 14, ///< ITU-R BT.2100-0, ICtCp
> +AVCOL_SPC_IPT_C2 = 15, ///< SMPTE ST 2128
> +AVCOL_SPC_YCGCO_RE= 16, ///< YCgCo-R, even addition of bits
> +AVCOL_SPC_YCGCO_RO= 17, ///< YCgCo-R, odd addition of bits
> AVCOL_SPC_NB///< Not part of ABI
> };
To aid in review as for whatever reason the 2023-09 H.273 v3 is not
yet publicly available (even though H.274 is from the same September
period), you can first of all see the summary in
https://www.itu.int/itu-t/workprog/wp_item.aspx?isn=18689 .
The latest related drafts from JVET-Experts
(https://jvet-experts.org/doc_end_user/all_meeting.php being the
index) are:
- CICP/H.273: JVET-AD1003 v2 from
https://jvet-experts.org/doc_end_user/current_document.php?id=12970
- H.265: JVET-AF1006 from
https://jvet-experts.org/doc_end_user/current_document.php?id=13584
- H.264: JVET-AE1016 from
https://jvet-experts.org/doc_end_user/current_document.php?id=13269
Given that H.273 v3 got registered for AAP on 2023-07-21 and that the
H.265 text is clearly from after the last call period of 2023-09-01 to
2023-09-28, I would consider them all matching being a pretty good
indicator that the value 15 got utilized for IPT-C2, and 16+17 for
YCgCo-R.
Jan
___
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 9/9] fate/filter-video: Insert scale, format filters in filter-yadif tests
The format and the first scale filter ensures that the filter processing actually happens in high bit depth; the second scale filter is only necessary for big endian arches. Signed-off-by: Andreas Rheinhardt --- tests/fate/filter-video.mak | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index 681cddc33e..d8d29866b8 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -25,8 +25,8 @@ fate-filter-yadif-mode0: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $( fate-filter-yadif-mode1: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -frames:v 59 -vf yadif=1 FATE_YADIF-$(call FILTERDEMDEC, YADIF SCALE, MPEGTS, MPEG2VIDEO) += fate-filter-yadif10 fate-filter-yadif16 -fate-filter-yadif10: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p10le -frames:v 30 -vf scale,yadif=0 -fate-filter-yadif16: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p16le -frames:v 30 -vf scale,yadif=0 +fate-filter-yadif10: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p10le -frames:v 30 -vf scale,format=yuv420p10,yadif=0,scale +fate-filter-yadif16: CMD = framecrc -ec 0 -flags bitexact -idct simple -i $(TARGET_SAMPLES)/mpeg2/mpeg2_field_encoding.ts -flags bitexact -pix_fmt yuv420p16le -frames:v 30 -vf scale,format=yuv420p16,yadif=0,scale FATE_FILTER_SAMPLES-yes += $(FATE_YADIF-yes) -- 2.40.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 8/8] fate/filter-video: Always use little endian pixel format
Fixes filter-metadata-signalstats-yuv420p10 on BE arches. Signed-off-by: Andreas Rheinhardt --- tests/fate/filter-video.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index ee9f0f5e40..681cddc33e 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -692,7 +692,7 @@ fate-filter-metadata-freezedetect: CMD = run $(FILTER_METADATA_COMMAND) "sws_fla SIGNALSTATS_DEPS = LAVFI_INDEV COLOR_FILTER SCALE_FILTER SIGNALSTATS_FILTER FATE_METADATA_FILTER-$(call ALLYES, $(SIGNALSTATS_DEPS)) += fate-filter-metadata-signalstats-yuv420p fate-filter-metadata-signalstats-yuv420p10 fate-filter-metadata-signalstats-yuv420p: CMD = run $(FILTER_METADATA_COMMAND) "sws_flags=+accurate_rnd+bitexact;color=white:duration=1:r=1,signalstats" -fate-filter-metadata-signalstats-yuv420p10: CMD = run $(FILTER_METADATA_COMMAND) "sws_flags=+accurate_rnd+bitexact;color=white:duration=1:r=1,format=yuv420p10,signalstats" +fate-filter-metadata-signalstats-yuv420p10: CMD = run $(FILTER_METADATA_COMMAND) "sws_flags=+accurate_rnd+bitexact;color=white:duration=1:r=1,format=yuv420p10le,signalstats" SILENCEDETECT_DEPS = LAVFI_INDEV FILE_PROTOCOL AMOVIE_FILTER TTA_DEMUXER TTA_DECODER SILENCEDETECT_FILTER FATE_METADATA_FILTER-$(call ALLYES, $(SILENCEDETECT_DEPS)) += fate-filter-metadata-silencedetect -- 2.40.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 7/7] fate/video: Only use bitexact IDCT in avid meridian
Precludes the usage of the altivec IDCT which fixes the avid-meridian FATE test on ppc64be here. Signed-off-by: Andreas Rheinhardt --- tests/fate/video.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/video.mak b/tests/fate/video.mak index 8f51a42077..9ad39e21ee 100644 --- a/tests/fate/video.mak +++ b/tests/fate/video.mak @@ -48,7 +48,7 @@ FATE_VIDEO-$(call FRAMECRC, AVI, AVRN) += fate-avid-interlaced fate-avid-interlaced: CMD = framecrc -i $(TARGET_SAMPLES)/avid/avid_ntsc_interlaced.avi FATE_VIDEO-$(call FRAMECRC, MOV, MJPEG) += fate-avid-meridian -fate-avid-meridian: CMD = framecrc -i $(TARGET_SAMPLES)/avid/avidmeridianntsc.mov +fate-avid-meridian: CMD = framecrc -bitexact -i $(TARGET_SAMPLES)/avid/avidmeridianntsc.mov FATE_VIDEO-$(call FRAMECRC, BETHSOFTVID, BETHSOFTVID, ARESAMPLE_FILTER SCALE_FILTER) += fate-bethsoft-vid fate-bethsoft-vid: CMD = framecrc -i $(TARGET_SAMPLES)/bethsoft-vid/ANIM0001.VID -t 5 -pix_fmt rgb24 -vf scale -af aresample -- 2.40.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] [PATCH v10 2/5] avformat/rcwtdec: add RCWT Closed Captions demuxer
Tomas Härdin : > once I get my srtdec patchset through there will > be something to follow. I see the patch now. I agree, this looks like a good step. Thank you! > Nah it can be done at a later point as an enhancement if you prefer Yes, please. I am happy to do it, but I think will be smoother to do after an example is there (since it introduces a new pattern for subtitles). Thank you for understanding. ___ 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/2] avcodec/liblc3: Add encoding/decoding support of LC3 audio codec
Antoine Soulier via ffmpeg-devel:
> The LC3 audio codec is the default codec of Bluetooth LE audio.
> This is a wrapper over the liblc3 library (https://github.com/google/liblc3).
>
> Signed-off-by: Antoine Soulier
> ---
> Changelog | 4 +
> configure | 6 ++
> doc/encoders.texi | 57
> doc/general_contents.texi | 11 ++-
> libavcodec/Makefile | 2 +
> libavcodec/allcodecs.c| 2 +
> libavcodec/codec_desc.c | 7 ++
> libavcodec/codec_id.h | 1 +
> libavcodec/liblc3dec.c| 141
> libavcodec/liblc3enc.c| 190 ++
> 10 files changed, 420 insertions(+), 1 deletion(-)
> create mode 100644 libavcodec/liblc3dec.c
> create mode 100644 libavcodec/liblc3enc.c
>
> diff --git a/Changelog b/Changelog
> index e83a00e35c..83a4cf7888 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -1,6 +1,10 @@
> Entries are sorted chronologically from oldest to youngest within each
> release,
> releases are sorted from youngest to oldest.
>
> +version :
> +- LC3/LC3plus decoding/encoding using external library liblc3
> +
> +
> version 7.0:
> - DXV DXT1 encoder
> - LEAD MCMP decoder
> diff --git a/configure b/configure
> index 2d46ef0b9c..e5d9ba9f53 100755
> --- a/configure
> +++ b/configure
> @@ -244,6 +244,7 @@ External library support:
>--enable-libjxl enable JPEG XL de/encoding via libjxl [no]
>--enable-libklvanc enable Kernel Labs VANC processing [no]
>--enable-libkvazaar enable HEVC encoding via libkvazaar [no]
> + --enable-liblc3 enable LC3 de/encoding via liblc3 [no]
>--enable-liblensfun enable lensfun lens correction [no]
>--enable-libmodplug enable ModPlug via libmodplug [no]
>--enable-libmp3lame enable MP3 encoding via libmp3lame [no]
> @@ -1926,6 +1927,7 @@ EXTERNAL_LIBRARY_LIST="
> libjxl
> libklvanc
> libkvazaar
> +liblc3
> libmodplug
> libmp3lame
> libmysofa
> @@ -3499,6 +3501,9 @@ libilbc_encoder_deps="libilbc"
> libjxl_decoder_deps="libjxl libjxl_threads"
> libjxl_encoder_deps="libjxl libjxl_threads"
> libkvazaar_encoder_deps="libkvazaar"
> +liblc3_decoder_deps="liblc3"
> +liblc3_encoder_deps="liblc3"
> +liblc3_encoder_select="audio_frame_queue"
> libmodplug_demuxer_deps="libmodplug"
> libmp3lame_encoder_deps="libmp3lame"
> libmp3lame_encoder_select="audio_frame_queue mpegaudioheader"
> @@ -6869,6 +6874,7 @@ enabled libjxl&& require_pkg_config libjxl
> "libjxl >= 0.7.0" jxl/dec
> require_pkg_config libjxl_threads
> "libjxl_threads >= 0.7.0" jxl/thread_parallel_runner.h JxlThreadParallelRunner
> enabled libklvanc && require libklvanc libklvanc/vanc.h
> klvanc_context_create -lklvanc
> enabled libkvazaar&& require_pkg_config libkvazaar "kvazaar >=
> 2.0.0" kvazaar.h kvz_api_get
> +enabled liblc3&& require_pkg_config liblc3 "lc3 >= 1.1.0" lc3.h
> lc3_hr_setup_encoder
> enabled liblensfun&& require_pkg_config liblensfun lensfun lensfun.h
> lf_db_create
>
> if enabled libmfx && enabled libvpl; then
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 7c223ed74c..66847191e1 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -814,6 +814,63 @@ ffmpeg -i input.wav -c:a libfdk_aac -profile:a aac_he
> -b:a 64k output.m4a
> @end example
> @end itemize
>
> +@anchor{liblc3-enc}
> +@section liblc3
> +
> +liblc3 LC3 (Low Complexity Communication Codec) encoder wrapper.
> +
> +Requires the presence of the liblc3 headers and library during configuration.
> +You need to explicitly configure the build with @code{--enable-liblc3}.
> +
> +This encoder has support for the Bluetooth SIG LC3 codec for the LE Audio
> +protocol, and the following features of LC3plus:
> +@itemize
> +@item
> +Frame duration of 2.5 and 5ms.
> +@item
> +High-Resolution mode, 48 KHz, and 96 kHz sampling rates.
> +@end itemize
> +
> +For more information see the liblc3 project at
> +@url{https://github.com/google/liblc3}.
> +
> +@subsection Options
> +
> +The following options are mapped on the shared FFmpeg codec options.
> +
> +@table @option
> +@item b @var{bitrate}
> +Set the bit rate in bits/s. This will determine the fixed size of the encoded
> +frames, for a selected frame duration.
> +
> +@item ar @var{frequency}
> +Set the audio sampling rate (in Hz).
> +
> +@item channels
> +Set the number of audio channels.
> +
> +@item frame_duration
> +Set the audio frame duration in milliseconds. Default value is 10ms.
> +Allowed frame durations are 2.5ms, 5ms, 7.5ms and 10ms.
> +LC3 (Bluetooth LE Audio), allows 7.5ms and 10ms; and LC3plus 2.5ms, 5ms
> +and 10ms.
> +
> +The 10ms frame duration is available in LC3 and LC3 plus standard.
> +In this mode, the produced bitstream can be referenced either as LC3 or
> LC3plus.
> +
> +@item high_resolution @var{boolean}
> +Enable the
Re: [FFmpeg-devel] [PATCH v2] avocdec/hevc_ps: don't use a fixed sized buffer for parameter set raw data
On 3/29/2024 2:28 PM, Andreas Rheinhardt wrote:
James Almer:
Allocate it instead, and use it to compare sets instead of the parsed struct.
Signed-off-by: James Almer
---
libavcodec/hevc_ps.c | 127 +++
libavcodec/hevc_ps.h | 14 +++--
2 files changed, 77 insertions(+), 64 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 6475d86d7d..7f74553fc1 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -442,47 +442,42 @@ static int decode_hrd(GetBitContext *gb, int
common_inf_present,
return 0;
}
-static void uninit_vps(FFRefStructOpaque opaque, void *obj)
+static void hevc_vps_free(FFRefStructOpaque opaque, void *obj)
{
HEVCVPS *vps = obj;
av_freep(>hdr);
-}
-
-static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
-{
-if (!memcmp(vps1, vps2, offsetof(HEVCVPS, hdr)))
-return !vps1->vps_num_hrd_parameters ||
- !memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
sizeof(*vps1->hdr));
-
-return 0;
+av_freep(>data);
}
int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps)
{
int i,j;
-int vps_id = 0;
-ptrdiff_t nal_size;
-HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, uninit_vps);
+int vps_id = get_bits(gb, 4);
+int ret = AVERROR_INVALIDDATA;
+HEVCVPS *vps;
+if (ps->pps_list[vps_id]) {
+const HEVCVPS *vps1 = ps->vps_list[vps_id];
+if (vps1->data_size == gb->buffer_end - gb->buffer &&
+!memcmp(vps1->data, gb->buffer, vps1->data_size))
+return 0;
+}
+
+vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, hevc_vps_free);
if (!vps)
return AVERROR(ENOMEM);
av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
-nal_size = gb->buffer_end - gb->buffer;
-if (nal_size > sizeof(vps->data)) {
-av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized VPS "
- "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
- nal_size, sizeof(vps->data));
-vps->data_size = sizeof(vps->data);
-} else {
-vps->data_size = nal_size;
+vps->data_size = gb->buffer_end - gb->buffer;
+vps->data = av_memdup(gb->buffer, vps->data_size);
+if (!vps->data) {
+ret = AVERROR(ENOMEM);
+goto err;
}
-memcpy(vps->data, gb->buffer, vps->data_size);
-
-vps_id = vps->vps_id = get_bits(gb, 4);
+vps->vps_id = vps_id;
if (get_bits(gb, 2) != 3) { // vps_reserved_three_2bits
av_log(avctx, AV_LOG_ERROR, "vps_reserved_three_2bits is not
three\n");
@@ -579,19 +574,14 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
goto err;
}
-if (ps->vps_list[vps_id] &&
-compare_vps(ps->vps_list[vps_id], vps)) {
-ff_refstruct_unref();
-} else {
remove_vps(ps, vps_id);
ps->vps_list[vps_id] = vps;
-}
return 0;
err:
ff_refstruct_unref();
-return AVERROR_INVALIDDATA;
+return ret;
}
static void decode_vui(GetBitContext *gb, AVCodecContext *avctx,
@@ -1294,36 +1284,43 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
return 0;
}
+static void hevc_sps_free(FFRefStructOpaque opaque, void *obj)
+{
+HEVCSPS *sps = obj;
+
+av_freep(>data);
+}
+
+static int compare_sps(const HEVCSPS *sps1, const HEVCSPS *sps2)
+{
+return sps1->data_size == sps2->data_size &&
+ !memcmp(sps1->data, sps2->data, sps1->data_size);
+}
+
int ff_hevc_decode_nal_sps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps, int apply_defdispwin)
{
-HEVCSPS *sps = ff_refstruct_allocz(sizeof(*sps));
+HEVCSPS *sps = ff_refstruct_alloc_ext(sizeof(*sps), 0, NULL,
hevc_sps_free);
unsigned int sps_id;
int ret;
-ptrdiff_t nal_size;
if (!sps)
return AVERROR(ENOMEM);
av_log(avctx, AV_LOG_DEBUG, "Decoding SPS\n");
-nal_size = gb->buffer_end - gb->buffer;
-if (nal_size > sizeof(sps->data)) {
-av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized SPS "
- "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
- nal_size, sizeof(sps->data));
-sps->data_size = sizeof(sps->data);
-} else {
-sps->data_size = nal_size;
+sps->data_size = gb->buffer_end - gb->buffer;
+sps->data = av_memdup(gb->buffer, sps->data_size);
+if (!sps->data) {
+ret = AVERROR(ENOMEM);
+goto err;
}
-memcpy(sps->data, gb->buffer, sps->data_size);
ret = ff_hevc_parse_sps(sps, gb, _id,
apply_defdispwin,
ps->vps_list, avctx);
if (ret < 0) {
-ff_refstruct_unref();
-return ret;
+goto err;
}
if
Re: [FFmpeg-devel] [PATCH 3/4] avformat/lc3: Add file format for LC3/LC3plus transport
You're right, I was not aware at all. I have pushed a patch that does the job. PTAL, thanks. ___ 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/2] avformat/lc3: Add file format for LC3/LC3plus transport
A file format is described in Bluetooth SIG LC3 and ETSI TS 103 634, for
test purpose. This is the format implemented here.
Signed-off-by: Antoine Soulier
---
Changelog| 1 +
doc/muxers.texi | 6 ++
libavformat/Makefile | 2 +
libavformat/allformats.c | 2 +
libavformat/lc3dec.c | 164 +++
libavformat/lc3enc.c | 100
6 files changed, 275 insertions(+)
create mode 100644 libavformat/lc3dec.c
create mode 100644 libavformat/lc3enc.c
diff --git a/Changelog b/Changelog
index 83a4cf7888..08c200a41d 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest
within each release,
releases are sorted from youngest to oldest.
version :
+- LC3/LC3plus demuxer and muxer
- LC3/LC3plus decoding/encoding using external library liblc3
diff --git a/doc/muxers.texi b/doc/muxers.texi
index a10a8e216f..9687746c30 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2612,6 +2612,12 @@ WebDAV server every second:
ffmpeg -f x11grab -framerate 1 -i :0.0 -q:v 6 -update 1 -protocol_opts
method=PUT http://example.com/desktop.jpg
@end example
+@section lc3
+Bluetooth SIG Low Complexity Communication Codec audio (LC3), or
+ETSI TS 103 634 Low Complexity Communication Codec plus (LC3plus).
+
+This muxer accepts a single @code{lc3} audio stream.
+
@section matroska
Matroska container muxer.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 44aa485029..4961c42852 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -332,6 +332,8 @@ OBJS-$(CONFIG_KVAG_DEMUXER) += kvag.o
OBJS-$(CONFIG_KVAG_MUXER)+= kvag.o rawenc.o
OBJS-$(CONFIG_LAF_DEMUXER) += lafdec.o
OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
+OBJS-$(CONFIG_LC3_DEMUXER) += lc3dec.o
+OBJS-$(CONFIG_LC3_MUXER) += lc3enc.o
OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
OBJS-$(CONFIG_LOAS_DEMUXER) += loasdec.o rawdec.o
OBJS-$(CONFIG_LUODAT_DEMUXER)+= luodatdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 9df42bb87a..0b36a7c3eb 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -252,6 +252,8 @@ extern const FFInputFormat ff_kvag_demuxer;
extern const FFOutputFormat ff_kvag_muxer;
extern const FFInputFormat ff_laf_demuxer;
extern const FFOutputFormat ff_latm_muxer;
+extern const FFInputFormat ff_lc3_demuxer;
+extern const FFOutputFormat ff_lc3_muxer;
extern const FFInputFormat ff_lmlm4_demuxer;
extern const FFInputFormat ff_loas_demuxer;
extern const FFInputFormat ff_luodat_demuxer;
diff --git a/libavformat/lc3dec.c b/libavformat/lc3dec.c
new file mode 100644
index 00..74d6794d00
--- /dev/null
+++ b/libavformat/lc3dec.c
@@ -0,0 +1,164 @@
+/*
+ * LC3 demuxer
+ * Copyright (C) 2024 Antoine Soulier
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Based on the file format specified by :
+ *
+ * - Bluetooth SIG - Low Complexity Communication Codec Test Suite
+ * https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=502301
+ * 3.2.8.2 Reference LC3 Codec Bitstream Format
+ *
+ * - ETSI TI 103 634 V1.4.1 - Low Complexity Communication Codec plus
+ *
https://www.etsi.org/deliver/etsi_ts/103600_103699/103634/01.04.01_60/ts_103634v010401p.pdf
+ * LC3plus conformance script package
+ */
+
+#include "libavcodec/packet.h"
+#include "libavutil/intreadwrite.h"
+
+#include "avformat.h"
+#include "avio.h"
+#include "demux.h"
+#include "internal.h"
+
+typedef struct LC3DemuxContext {
+int dt, delay;
+int64_t timestamp;
+int64_t length;
+} LC3DemuxContext;
+
+static int lc3_read_header(AVFormatContext *s)
+{
+LC3DemuxContext *lc3 = s->priv_data;
+AVStream *st = NULL;
+uint16_t tag, hdr_size;
+uint16_t frame_10us;
+uint32_t length;
+int ep_mode, hr_mode;
+int srate_hz, channels, bit_rate;
+int num_extra_params, ret;
+
+tag = avio_rb16(s->pb);
+hdr_size = avio_rl16(s->pb);
+
+if (tag != 0x1ccc || hdr_size < 9 * sizeof(uint16_t))
+return AVERROR_INVALIDDATA;
+
+num_extra_params =
[FFmpeg-devel] [PATCH 1/2] avcodec/liblc3: Add encoding/decoding support of LC3 audio codec
The LC3 audio codec is the default codec of Bluetooth LE audio.
This is a wrapper over the liblc3 library (https://github.com/google/liblc3).
Signed-off-by: Antoine Soulier
---
Changelog | 4 +
configure | 6 ++
doc/encoders.texi | 57
doc/general_contents.texi | 11 ++-
libavcodec/Makefile | 2 +
libavcodec/allcodecs.c| 2 +
libavcodec/codec_desc.c | 7 ++
libavcodec/codec_id.h | 1 +
libavcodec/liblc3dec.c| 141
libavcodec/liblc3enc.c| 190 ++
10 files changed, 420 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/liblc3dec.c
create mode 100644 libavcodec/liblc3enc.c
diff --git a/Changelog b/Changelog
index e83a00e35c..83a4cf7888 100644
--- a/Changelog
+++ b/Changelog
@@ -1,6 +1,10 @@
Entries are sorted chronologically from oldest to youngest within each release,
releases are sorted from youngest to oldest.
+version :
+- LC3/LC3plus decoding/encoding using external library liblc3
+
+
version 7.0:
- DXV DXT1 encoder
- LEAD MCMP decoder
diff --git a/configure b/configure
index 2d46ef0b9c..e5d9ba9f53 100755
--- a/configure
+++ b/configure
@@ -244,6 +244,7 @@ External library support:
--enable-libjxl enable JPEG XL de/encoding via libjxl [no]
--enable-libklvanc enable Kernel Labs VANC processing [no]
--enable-libkvazaar enable HEVC encoding via libkvazaar [no]
+ --enable-liblc3 enable LC3 de/encoding via liblc3 [no]
--enable-liblensfun enable lensfun lens correction [no]
--enable-libmodplug enable ModPlug via libmodplug [no]
--enable-libmp3lame enable MP3 encoding via libmp3lame [no]
@@ -1926,6 +1927,7 @@ EXTERNAL_LIBRARY_LIST="
libjxl
libklvanc
libkvazaar
+liblc3
libmodplug
libmp3lame
libmysofa
@@ -3499,6 +3501,9 @@ libilbc_encoder_deps="libilbc"
libjxl_decoder_deps="libjxl libjxl_threads"
libjxl_encoder_deps="libjxl libjxl_threads"
libkvazaar_encoder_deps="libkvazaar"
+liblc3_decoder_deps="liblc3"
+liblc3_encoder_deps="liblc3"
+liblc3_encoder_select="audio_frame_queue"
libmodplug_demuxer_deps="libmodplug"
libmp3lame_encoder_deps="libmp3lame"
libmp3lame_encoder_select="audio_frame_queue mpegaudioheader"
@@ -6869,6 +6874,7 @@ enabled libjxl&& require_pkg_config libjxl
"libjxl >= 0.7.0" jxl/dec
require_pkg_config libjxl_threads "libjxl_threads
>= 0.7.0" jxl/thread_parallel_runner.h JxlThreadParallelRunner
enabled libklvanc && require libklvanc libklvanc/vanc.h
klvanc_context_create -lklvanc
enabled libkvazaar&& require_pkg_config libkvazaar "kvazaar >= 2.0.0"
kvazaar.h kvz_api_get
+enabled liblc3&& require_pkg_config liblc3 "lc3 >= 1.1.0" lc3.h
lc3_hr_setup_encoder
enabled liblensfun&& require_pkg_config liblensfun lensfun lensfun.h
lf_db_create
if enabled libmfx && enabled libvpl; then
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 7c223ed74c..66847191e1 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -814,6 +814,63 @@ ffmpeg -i input.wav -c:a libfdk_aac -profile:a aac_he -b:a
64k output.m4a
@end example
@end itemize
+@anchor{liblc3-enc}
+@section liblc3
+
+liblc3 LC3 (Low Complexity Communication Codec) encoder wrapper.
+
+Requires the presence of the liblc3 headers and library during configuration.
+You need to explicitly configure the build with @code{--enable-liblc3}.
+
+This encoder has support for the Bluetooth SIG LC3 codec for the LE Audio
+protocol, and the following features of LC3plus:
+@itemize
+@item
+Frame duration of 2.5 and 5ms.
+@item
+High-Resolution mode, 48 KHz, and 96 kHz sampling rates.
+@end itemize
+
+For more information see the liblc3 project at
+@url{https://github.com/google/liblc3}.
+
+@subsection Options
+
+The following options are mapped on the shared FFmpeg codec options.
+
+@table @option
+@item b @var{bitrate}
+Set the bit rate in bits/s. This will determine the fixed size of the encoded
+frames, for a selected frame duration.
+
+@item ar @var{frequency}
+Set the audio sampling rate (in Hz).
+
+@item channels
+Set the number of audio channels.
+
+@item frame_duration
+Set the audio frame duration in milliseconds. Default value is 10ms.
+Allowed frame durations are 2.5ms, 5ms, 7.5ms and 10ms.
+LC3 (Bluetooth LE Audio), allows 7.5ms and 10ms; and LC3plus 2.5ms, 5ms
+and 10ms.
+
+The 10ms frame duration is available in LC3 and LC3 plus standard.
+In this mode, the produced bitstream can be referenced either as LC3 or
LC3plus.
+
+@item high_resolution @var{boolean}
+Enable the high-resolution mode if set to 1. The high-resolution mode is
+available with all LC3plus frame durations and for a sampling rate of 48 KHz,
+and 96 KHz.
+
+The encoder automatically turns off this mode at lower sampling rates and
+activates it at 96 KHz.
+
+This mode should be preferred at high bitrates. In this
Re: [FFmpeg-devel] [PATCH v2] avocdec/hevc_ps: don't use a fixed sized buffer for parameter set raw data
James Almer:
> Allocate it instead, and use it to compare sets instead of the parsed struct.
>
> Signed-off-by: James Almer
> ---
> libavcodec/hevc_ps.c | 127 +++
> libavcodec/hevc_ps.h | 14 +++--
> 2 files changed, 77 insertions(+), 64 deletions(-)
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 6475d86d7d..7f74553fc1 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -442,47 +442,42 @@ static int decode_hrd(GetBitContext *gb, int
> common_inf_present,
> return 0;
> }
>
> -static void uninit_vps(FFRefStructOpaque opaque, void *obj)
> +static void hevc_vps_free(FFRefStructOpaque opaque, void *obj)
> {
> HEVCVPS *vps = obj;
>
> av_freep(>hdr);
> -}
> -
> -static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
> -{
> -if (!memcmp(vps1, vps2, offsetof(HEVCVPS, hdr)))
> -return !vps1->vps_num_hrd_parameters ||
> - !memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
> sizeof(*vps1->hdr));
> -
> -return 0;
> +av_freep(>data);
> }
>
> int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
> HEVCParamSets *ps)
> {
> int i,j;
> -int vps_id = 0;
> -ptrdiff_t nal_size;
> -HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, uninit_vps);
> +int vps_id = get_bits(gb, 4);
> +int ret = AVERROR_INVALIDDATA;
> +HEVCVPS *vps;
>
> +if (ps->pps_list[vps_id]) {
> +const HEVCVPS *vps1 = ps->vps_list[vps_id];
> +if (vps1->data_size == gb->buffer_end - gb->buffer &&
> +!memcmp(vps1->data, gb->buffer, vps1->data_size))
> +return 0;
> +}
> +
> +vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, hevc_vps_free);
> if (!vps)
> return AVERROR(ENOMEM);
>
> av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
>
> -nal_size = gb->buffer_end - gb->buffer;
> -if (nal_size > sizeof(vps->data)) {
> -av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized VPS "
> - "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
> - nal_size, sizeof(vps->data));
> -vps->data_size = sizeof(vps->data);
> -} else {
> -vps->data_size = nal_size;
> +vps->data_size = gb->buffer_end - gb->buffer;
> +vps->data = av_memdup(gb->buffer, vps->data_size);
> +if (!vps->data) {
> +ret = AVERROR(ENOMEM);
> +goto err;
> }
> -memcpy(vps->data, gb->buffer, vps->data_size);
> -
> -vps_id = vps->vps_id = get_bits(gb, 4);
> +vps->vps_id = vps_id;
>
> if (get_bits(gb, 2) != 3) { // vps_reserved_three_2bits
> av_log(avctx, AV_LOG_ERROR, "vps_reserved_three_2bits is not
> three\n");
> @@ -579,19 +574,14 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
> AVCodecContext *avctx,
> goto err;
> }
>
> -if (ps->vps_list[vps_id] &&
> -compare_vps(ps->vps_list[vps_id], vps)) {
> -ff_refstruct_unref();
> -} else {
> remove_vps(ps, vps_id);
> ps->vps_list[vps_id] = vps;
> -}
>
> return 0;
>
> err:
> ff_refstruct_unref();
> -return AVERROR_INVALIDDATA;
> +return ret;
> }
>
> static void decode_vui(GetBitContext *gb, AVCodecContext *avctx,
> @@ -1294,36 +1284,43 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext
> *gb, unsigned int *sps_id,
> return 0;
> }
>
> +static void hevc_sps_free(FFRefStructOpaque opaque, void *obj)
> +{
> +HEVCSPS *sps = obj;
> +
> +av_freep(>data);
> +}
> +
> +static int compare_sps(const HEVCSPS *sps1, const HEVCSPS *sps2)
> +{
> +return sps1->data_size == sps2->data_size &&
> + !memcmp(sps1->data, sps2->data, sps1->data_size);
> +}
> +
> int ff_hevc_decode_nal_sps(GetBitContext *gb, AVCodecContext *avctx,
> HEVCParamSets *ps, int apply_defdispwin)
> {
> -HEVCSPS *sps = ff_refstruct_allocz(sizeof(*sps));
> +HEVCSPS *sps = ff_refstruct_alloc_ext(sizeof(*sps), 0, NULL,
> hevc_sps_free);
> unsigned int sps_id;
> int ret;
> -ptrdiff_t nal_size;
>
> if (!sps)
> return AVERROR(ENOMEM);
>
> av_log(avctx, AV_LOG_DEBUG, "Decoding SPS\n");
>
> -nal_size = gb->buffer_end - gb->buffer;
> -if (nal_size > sizeof(sps->data)) {
> -av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized SPS "
> - "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
> - nal_size, sizeof(sps->data));
> -sps->data_size = sizeof(sps->data);
> -} else {
> -sps->data_size = nal_size;
> +sps->data_size = gb->buffer_end - gb->buffer;
> +sps->data = av_memdup(gb->buffer, sps->data_size);
> +if (!sps->data) {
> +ret = AVERROR(ENOMEM);
> +goto err;
> }
> -memcpy(sps->data, gb->buffer, sps->data_size);
>
> ret = ff_hevc_parse_sps(sps, gb, _id,
>
Re: [FFmpeg-devel] [PATCH v10 2/5] avformat/rcwtdec: add RCWT Closed Captions demuxer
fre 2024-03-29 klockan 09:28 -0500 skrev Marth64: > Tomas Härdin: > > Can we please get away from this way of reading subtitles? Every > > other > > type of media (audio, video) are capable of being streamed, but not > > subtitles, precisely because all of them do all parsing in the > > read_header() call. We have a perfectly good generic index and > > seeking > > functionality. My recent experiment with srt shows it's possible to > > read packets in read_packet() like every other demuxer.. > > Is there an example I can follow? Not yet, but perhaps once I get my srtdec patchset through there will be something to follow. Might follow it up with a similar patch for webvttdec > Is this something that can be fixed > in an enhancement patch or is it a deal-breaker to merge this? Nah it can be done at a later point as an enhancement if you prefer /Tomas ___ 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 v2] avocdec/hevc_ps: don't use a fixed sized buffer for parameter set raw data
Allocate it instead, and use it to compare sets instead of the parsed struct.
Signed-off-by: James Almer
---
libavcodec/hevc_ps.c | 127 +++
libavcodec/hevc_ps.h | 14 +++--
2 files changed, 77 insertions(+), 64 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 6475d86d7d..7f74553fc1 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -442,47 +442,42 @@ static int decode_hrd(GetBitContext *gb, int
common_inf_present,
return 0;
}
-static void uninit_vps(FFRefStructOpaque opaque, void *obj)
+static void hevc_vps_free(FFRefStructOpaque opaque, void *obj)
{
HEVCVPS *vps = obj;
av_freep(>hdr);
-}
-
-static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
-{
-if (!memcmp(vps1, vps2, offsetof(HEVCVPS, hdr)))
-return !vps1->vps_num_hrd_parameters ||
- !memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
sizeof(*vps1->hdr));
-
-return 0;
+av_freep(>data);
}
int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps)
{
int i,j;
-int vps_id = 0;
-ptrdiff_t nal_size;
-HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, uninit_vps);
+int vps_id = get_bits(gb, 4);
+int ret = AVERROR_INVALIDDATA;
+HEVCVPS *vps;
+if (ps->pps_list[vps_id]) {
+const HEVCVPS *vps1 = ps->vps_list[vps_id];
+if (vps1->data_size == gb->buffer_end - gb->buffer &&
+!memcmp(vps1->data, gb->buffer, vps1->data_size))
+return 0;
+}
+
+vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, hevc_vps_free);
if (!vps)
return AVERROR(ENOMEM);
av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
-nal_size = gb->buffer_end - gb->buffer;
-if (nal_size > sizeof(vps->data)) {
-av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized VPS "
- "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
- nal_size, sizeof(vps->data));
-vps->data_size = sizeof(vps->data);
-} else {
-vps->data_size = nal_size;
+vps->data_size = gb->buffer_end - gb->buffer;
+vps->data = av_memdup(gb->buffer, vps->data_size);
+if (!vps->data) {
+ret = AVERROR(ENOMEM);
+goto err;
}
-memcpy(vps->data, gb->buffer, vps->data_size);
-
-vps_id = vps->vps_id = get_bits(gb, 4);
+vps->vps_id = vps_id;
if (get_bits(gb, 2) != 3) { // vps_reserved_three_2bits
av_log(avctx, AV_LOG_ERROR, "vps_reserved_three_2bits is not three\n");
@@ -579,19 +574,14 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
goto err;
}
-if (ps->vps_list[vps_id] &&
-compare_vps(ps->vps_list[vps_id], vps)) {
-ff_refstruct_unref();
-} else {
remove_vps(ps, vps_id);
ps->vps_list[vps_id] = vps;
-}
return 0;
err:
ff_refstruct_unref();
-return AVERROR_INVALIDDATA;
+return ret;
}
static void decode_vui(GetBitContext *gb, AVCodecContext *avctx,
@@ -1294,36 +1284,43 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
return 0;
}
+static void hevc_sps_free(FFRefStructOpaque opaque, void *obj)
+{
+HEVCSPS *sps = obj;
+
+av_freep(>data);
+}
+
+static int compare_sps(const HEVCSPS *sps1, const HEVCSPS *sps2)
+{
+return sps1->data_size == sps2->data_size &&
+ !memcmp(sps1->data, sps2->data, sps1->data_size);
+}
+
int ff_hevc_decode_nal_sps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps, int apply_defdispwin)
{
-HEVCSPS *sps = ff_refstruct_allocz(sizeof(*sps));
+HEVCSPS *sps = ff_refstruct_alloc_ext(sizeof(*sps), 0, NULL,
hevc_sps_free);
unsigned int sps_id;
int ret;
-ptrdiff_t nal_size;
if (!sps)
return AVERROR(ENOMEM);
av_log(avctx, AV_LOG_DEBUG, "Decoding SPS\n");
-nal_size = gb->buffer_end - gb->buffer;
-if (nal_size > sizeof(sps->data)) {
-av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized SPS "
- "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
- nal_size, sizeof(sps->data));
-sps->data_size = sizeof(sps->data);
-} else {
-sps->data_size = nal_size;
+sps->data_size = gb->buffer_end - gb->buffer;
+sps->data = av_memdup(gb->buffer, sps->data_size);
+if (!sps->data) {
+ret = AVERROR(ENOMEM);
+goto err;
}
-memcpy(sps->data, gb->buffer, sps->data_size);
ret = ff_hevc_parse_sps(sps, gb, _id,
apply_defdispwin,
ps->vps_list, avctx);
if (ret < 0) {
-ff_refstruct_unref();
-return ret;
+goto err;
}
if (avctx->debug & FF_DEBUG_BITSTREAM) {
@@ -1340,7 +1337,7 @@ int ff_hevc_decode_nal_sps(GetBitContext *gb,
AVCodecContext *avctx,
*
[FFmpeg-devel] [PATCH 6/6] fate/image: Fix EXR tests on big endian
These tests need a scale filter to convert to the prescribed pixel format (the native format is endian-dependent). Signed-off-by: Andreas Rheinhardt --- And now I will deduplicate this mess... tests/fate/image.mak | 150 +-- 1 file changed, 75 insertions(+), 75 deletions(-) diff --git a/tests/fate/image.mak b/tests/fate/image.mak index 7c0e0fec08..753936ec20 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -104,229 +104,229 @@ FATE_IMAGE_PROBE-$(call DEMDEC, IMAGE2, DPX) += fate-dpx-probe fate-dpx-probe: CMD = probeframes -show_entries frame=color_transfer,color_range,color_space,color_primaries,sample_aspect_ratio $(TARGET_SAMPLES)/dpx/cyan.dpx FATE_EXR += fate-exr-slice-raw -fate-exr-slice-raw: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_slice_raw.exr -pix_fmt gbrapf32le +fate-exr-slice-raw: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_slice_raw.exr -vf scale -pix_fmt gbrapf32le FATE_EXR += fate-exr-slice-rle -fate-exr-slice-rle: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_slice_rle.exr -pix_fmt gbrapf32le +fate-exr-slice-rle: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_slice_rle.exr -vf scale -pix_fmt gbrapf32le FATE_EXR += fate-exr-slice-zip1 -fate-exr-slice-zip1: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_slice_zip1.exr -pix_fmt gbrapf32le +fate-exr-slice-zip1: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_slice_zip1.exr -vf scale -pix_fmt gbrapf32le FATE_EXR += fate-exr-slice-zip16 -fate-exr-slice-zip16: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_slice_zip16.exr -pix_fmt gbrapf32le +fate-exr-slice-zip16: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_slice_zip16.exr -vf scale -pix_fmt gbrapf32le FATE_EXR += fate-exr-slice-pxr24 -fate-exr-slice-pxr24: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_slice_pxr24.exr -pix_fmt gbrpf32le +fate-exr-slice-pxr24: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_slice_pxr24.exr -vf scale -pix_fmt gbrpf32le FATE_EXR += fate-exr-rgb-scanline-pxr24-float-12x8 -fate-exr-rgb-scanline-pxr24-float-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_pxr24_float_12x8.exr -pix_fmt gbrpf32le +fate-exr-rgb-scanline-pxr24-float-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_pxr24_float_12x8.exr -vf scale -pix_fmt gbrpf32le FATE_EXR += fate-exr-rgba-multiscanline-half-b44 -fate-exr-rgba-multiscanline-half-b44: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_multiscanline_half_b44.exr -pix_fmt gbrapf32le +fate-exr-rgba-multiscanline-half-b44: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_multiscanline_half_b44.exr -vf scale -pix_fmt gbrapf32le FATE_EXR += fate-exr-rgb-scanline-float-b44 -fate-exr-rgb-scanline-float-b44: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_float_b44.exr -pix_fmt gbrpf32le +fate-exr-rgb-scanline-float-b44: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_float_b44.exr -vf scale -pix_fmt gbrpf32le FATE_EXR += fate-exr-rgb-scanline-half-b44-12x8 -fate-exr-rgb-scanline-half-b44-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_half_b44_12x8.exr -pix_fmt gbrpf32le +fate-exr-rgb-scanline-half-b44-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_half_b44_12x8.exr -vf scale -pix_fmt gbrpf32le FATE_EXR += fate-exr-rgb-scanline-half-b44-13x9 -fate-exr-rgb-scanline-half-b44-13x9: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_half_b44_13x9.exr -pix_fmt gbrpf32le +fate-exr-rgb-scanline-half-b44-13x9: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_half_b44_13x9.exr -vf scale -pix_fmt gbrpf32le FATE_EXR += fate-exr-rgb-tile-float-raw-12x8 -fate-exr-rgb-tile-float-raw-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_tile_float_raw_12x8.exr -pix_fmt gbrpf32le +fate-exr-rgb-tile-float-raw-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_tile_float_raw_12x8.exr -vf scale -pix_fmt gbrpf32le FATE_EXR += fate-exr-rgb-tile-float-raw-150x130 -fate-exr-rgb-tile-float-raw-150x130: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_tile_float_raw_150x130.exr -pix_fmt gbrpf32le +fate-exr-rgb-tile-float-raw-150x130: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_tile_float_raw_150x130.exr -vf scale -pix_fmt gbrpf32le FATE_EXR += fate-exr-rgb-tile-half-raw-12x8 -fate-exr-rgb-tile-half-raw-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_tile_half_raw_12x8.exr -pix_fmt gbrpf32le +fate-exr-rgb-tile-half-raw-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_tile_half_raw_12x8.exr -vf scale -pix_fmt gbrpf32le FATE_EXR += fate-exr-rgba-scanline-float-half-b44-13x9-l1 -fate-exr-rgba-scanline-float-half-b44-13x9-l1: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_scanline_float_half_b44_13x9.exr -pix_fmt gbrapf32le +fate-exr-rgba-scanline-float-half-b44-13x9-l1: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_scanline_float_half_b44_13x9.exr -vf scale -pix_fmt gbrapf32le FATE_EXR += fate-exr-rgba-scanline-float-half-b44-13x9-l2 -fate-exr-rgba-scanline-float-half-b44-13x9-l2: CMD = framecrc -layer
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
On 29/03/2024 15:58, Andreas Rheinhardt wrote: Mark Thompson: On 29/03/2024 14:00, Andreas Rheinhardt wrote: James Almer: On 3/29/2024 10:10 AM, Mark Thompson wrote: On 28/03/2024 13:15, tong1.wu-at-intel@ffmpeg.org wrote: From: Tong Wu HEVCHdrParams* receives a pointer which points to a dynamically allocated memory block. It causes the memcmp always returning 1. Add a function to do the comparision. A condition is also added to avoid malloc(0). Signed-off-by: Tong Wu --- libavcodec/hevc_ps.c | 20 libavcodec/hevc_ps.h | 4 +++- 2 files changed, 19 insertions(+), 5 deletions(-) It doesn't seem like this method works at all, even before the recent change with the pointer. Structs can contain arbitrary padding, and any write to the struct makes the padding unspecified. memcmp() is therefore never valid as a method of comparing after writing some fields, as done here. (It could only be valid if the structs compared were made by memcpy() with no fields written directly.) The struct is zero allocated, so shouldn't the padding be exactly the same for two equal VPSs after parsing? In practice it is (and the current code already relied on this); yet as has already been said padding bytes take unspecified values at any store (to any member). In practice, if the compiler uses instructions that clobber the padding, the padding in both structs is clobbered in the same way. This seems like a strong assumption beyond that of the C specification which needs to be documented. Are you expecting that there is no case where ABI-undefined top bits of registers can leak into the padding fields, or that all functions called here will necessarily set those top bits to the same values, or something else? Yes, I am expecting that. That is also what the code already relied on before the addition of the allocated field and there have been no reports that this caused issues. Huh. Having just experimented a bit I find myself surprised by the lengths x86-64 gcc goes to with weird unaligned accesses to avoid this (e.g. to write to aligned uint8_t a[31] it may do aligned 16-byte write to a and unaligned 16-byte write to a+15, avoiding touching the padding for no clear reason). Are you aware of any documentation from gcc or llvm about on what they guarantee here? This does not change that I consider it crazy to remove the parameter sets referencing a parameter set that is removed. I agree, having now read the code more. My comment was purely driven by observing the use of memcmp() on structs (an operation well-known to be very difficult to use in standard C), not by looking carefully at the rest of the code involved. - Mark ___ 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] avocdec/hevc_ps: don't use a fixed sized buffer for parameter set raw data
James Almer:
> On 3/29/2024 1:10 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> Allocate it instead, and use it to compare sets instead of the parsed
>>> struct.
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavcodec/hevc_ps.c | 84 ++--
>>> libavcodec/hevc_ps.h | 14 +---
>>> 2 files changed, 51 insertions(+), 47 deletions(-)
>>>
>>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
>>> index 6475d86d7d..e417039d76 100644
>>> --- a/libavcodec/hevc_ps.c
>>> +++ b/libavcodec/hevc_ps.c
>>> @@ -442,20 +442,18 @@ static int decode_hrd(GetBitContext *gb, int
>>> common_inf_present,
>>> return 0;
>>> }
>>> -static void uninit_vps(FFRefStructOpaque opaque, void *obj)
>>> +static void hevc_vps_free(FFRefStructOpaque opaque, void *obj)
>>> {
>>> HEVCVPS *vps = obj;
>>> av_freep(>hdr);
>>> + av_freep(>data);
>>> }
>>> static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
>>> {
>>> - if (!memcmp(vps1, vps2, offsetof(HEVCVPS, hdr)))
>>> - return !vps1->vps_num_hrd_parameters ||
>>> - !memcmp(vps1->hdr, vps2->hdr,
>>> vps1->vps_num_hrd_parameters * sizeof(*vps1->hdr));
>>> -
>>> - return 0;
>>> + return vps1->data_size == vps2->data_size &&
>>> + !memcmp(vps1->data, vps2->data, vps1->data_size);
>>> }
>>> int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
>>> @@ -463,25 +461,20 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
>>> AVCodecContext *avctx,
>>> {
>>> int i,j;
>>> int vps_id = 0;
>>> - ptrdiff_t nal_size;
>>> - HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL,
>>> uninit_vps);
>>> + int ret = AVERROR_INVALIDDATA;
>>> + HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL,
>>> hevc_vps_free);
>>> if (!vps)
>>> return AVERROR(ENOMEM);
>>> av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
>>> - nal_size = gb->buffer_end - gb->buffer;
>>> - if (nal_size > sizeof(vps->data)) {
>>> - av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized
>>> VPS "
>>> - "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
>>> - nal_size, sizeof(vps->data));
>>> - vps->data_size = sizeof(vps->data);
>>> - } else {
>>> - vps->data_size = nal_size;
>>> + vps->data_size = gb->buffer_end - gb->buffer;
>>> + vps->data = av_memdup(gb->buffer, vps->data_size);
>>> + if (!vps->data) {
>>> + ret = AVERROR(ENOMEM);
>>> + goto err;
>>> }
>>> - memcpy(vps->data, gb->buffer, vps->data_size);
>>> -
>>> vps_id = vps->vps_id = get_bits(gb, 4);
>>> if (get_bits(gb, 2) != 3) { // vps_reserved_three_2bits
>>> @@ -591,7 +584,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
>>> AVCodecContext *avctx,
>>> err:
>>> ff_refstruct_unref();
>>> - return AVERROR_INVALIDDATA;
>>> + return ret;
>>> }
>>> static void decode_vui(GetBitContext *gb, AVCodecContext *avctx,
>>> @@ -1294,36 +1287,43 @@ int ff_hevc_parse_sps(HEVCSPS *sps,
>>> GetBitContext *gb, unsigned int *sps_id,
>>> return 0;
>>> }
>>> +static void hevc_sps_free(FFRefStructOpaque opaque, void *obj)
>>> +{
>>> + HEVCSPS *sps = obj;
>>> +
>>> + av_freep(>data);
>>> +}
>>> +
>>> +static int compare_sps(const HEVCSPS *sps1, const HEVCSPS *sps2)
>>> +{
>>> + return sps1->data_size == sps2->data_size &&
>>> + !memcmp(sps1->data, sps2->data, sps1->data_size);
>>> +}
>>> +
>>> int ff_hevc_decode_nal_sps(GetBitContext *gb, AVCodecContext *avctx,
>>> HEVCParamSets *ps, int apply_defdispwin)
>>> {
>>> - HEVCSPS *sps = ff_refstruct_allocz(sizeof(*sps));
>>> + HEVCSPS *sps = ff_refstruct_alloc_ext(sizeof(*sps), 0, NULL,
>>> hevc_sps_free);
>>> unsigned int sps_id;
>>> int ret;
>>> - ptrdiff_t nal_size;
>>> if (!sps)
>>> return AVERROR(ENOMEM);
>>> av_log(avctx, AV_LOG_DEBUG, "Decoding SPS\n");
>>> - nal_size = gb->buffer_end - gb->buffer;
>>> - if (nal_size > sizeof(sps->data)) {
>>> - av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized
>>> SPS "
>>> - "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
>>> - nal_size, sizeof(sps->data));
>>> - sps->data_size = sizeof(sps->data);
>>> - } else {
>>> - sps->data_size = nal_size;
>>> + sps->data_size = gb->buffer_end - gb->buffer;
>>> + sps->data = av_memdup(gb->buffer, sps->data_size);
>>> + if (!sps->data) {
>>> + ret = AVERROR(ENOMEM);
>>> + goto err;
>>> }
>>> - memcpy(sps->data, gb->buffer, sps->data_size);
>>> ret = ff_hevc_parse_sps(sps, gb, _id,
>>> apply_defdispwin,
>>> ps->vps_list, avctx);
>>> if (ret < 0) {
>>> - ff_refstruct_unref();
>>> - return ret;
>>> + goto err;
>>> }
>>> if
Re: [FFmpeg-devel] [PATCH] avocdec/hevc_ps: don't use a fixed sized buffer for parameter set raw data
On 3/29/2024 1:10 PM, Andreas Rheinhardt wrote:
James Almer:
Allocate it instead, and use it to compare sets instead of the parsed struct.
Signed-off-by: James Almer
---
libavcodec/hevc_ps.c | 84 ++--
libavcodec/hevc_ps.h | 14 +---
2 files changed, 51 insertions(+), 47 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 6475d86d7d..e417039d76 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -442,20 +442,18 @@ static int decode_hrd(GetBitContext *gb, int
common_inf_present,
return 0;
}
-static void uninit_vps(FFRefStructOpaque opaque, void *obj)
+static void hevc_vps_free(FFRefStructOpaque opaque, void *obj)
{
HEVCVPS *vps = obj;
av_freep(>hdr);
+av_freep(>data);
}
static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
{
-if (!memcmp(vps1, vps2, offsetof(HEVCVPS, hdr)))
-return !vps1->vps_num_hrd_parameters ||
- !memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
sizeof(*vps1->hdr));
-
-return 0;
+return vps1->data_size == vps2->data_size &&
+ !memcmp(vps1->data, vps2->data, vps1->data_size);
}
int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
@@ -463,25 +461,20 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
{
int i,j;
int vps_id = 0;
-ptrdiff_t nal_size;
-HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, uninit_vps);
+int ret = AVERROR_INVALIDDATA;
+HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL,
hevc_vps_free);
if (!vps)
return AVERROR(ENOMEM);
av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
-nal_size = gb->buffer_end - gb->buffer;
-if (nal_size > sizeof(vps->data)) {
-av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized VPS "
- "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
- nal_size, sizeof(vps->data));
-vps->data_size = sizeof(vps->data);
-} else {
-vps->data_size = nal_size;
+vps->data_size = gb->buffer_end - gb->buffer;
+vps->data = av_memdup(gb->buffer, vps->data_size);
+if (!vps->data) {
+ret = AVERROR(ENOMEM);
+goto err;
}
-memcpy(vps->data, gb->buffer, vps->data_size);
-
vps_id = vps->vps_id = get_bits(gb, 4);
if (get_bits(gb, 2) != 3) { // vps_reserved_three_2bits
@@ -591,7 +584,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
err:
ff_refstruct_unref();
-return AVERROR_INVALIDDATA;
+return ret;
}
static void decode_vui(GetBitContext *gb, AVCodecContext *avctx,
@@ -1294,36 +1287,43 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
return 0;
}
+static void hevc_sps_free(FFRefStructOpaque opaque, void *obj)
+{
+HEVCSPS *sps = obj;
+
+av_freep(>data);
+}
+
+static int compare_sps(const HEVCSPS *sps1, const HEVCSPS *sps2)
+{
+return sps1->data_size == sps2->data_size &&
+ !memcmp(sps1->data, sps2->data, sps1->data_size);
+}
+
int ff_hevc_decode_nal_sps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps, int apply_defdispwin)
{
-HEVCSPS *sps = ff_refstruct_allocz(sizeof(*sps));
+HEVCSPS *sps = ff_refstruct_alloc_ext(sizeof(*sps), 0, NULL,
hevc_sps_free);
unsigned int sps_id;
int ret;
-ptrdiff_t nal_size;
if (!sps)
return AVERROR(ENOMEM);
av_log(avctx, AV_LOG_DEBUG, "Decoding SPS\n");
-nal_size = gb->buffer_end - gb->buffer;
-if (nal_size > sizeof(sps->data)) {
-av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized SPS "
- "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
- nal_size, sizeof(sps->data));
-sps->data_size = sizeof(sps->data);
-} else {
-sps->data_size = nal_size;
+sps->data_size = gb->buffer_end - gb->buffer;
+sps->data = av_memdup(gb->buffer, sps->data_size);
+if (!sps->data) {
+ret = AVERROR(ENOMEM);
+goto err;
}
-memcpy(sps->data, gb->buffer, sps->data_size);
ret = ff_hevc_parse_sps(sps, gb, _id,
apply_defdispwin,
ps->vps_list, avctx);
if (ret < 0) {
-ff_refstruct_unref();
-return ret;
+goto err;
}
if (avctx->debug & FF_DEBUG_BITSTREAM) {
@@ -1340,7 +1340,7 @@ int ff_hevc_decode_nal_sps(GetBitContext *gb,
AVCodecContext *avctx,
* original one.
* otherwise drop all PPSes that depend on it */
if (ps->sps_list[sps_id] &&
-!memcmp(ps->sps_list[sps_id], sps, sizeof(*sps))) {
+compare_sps(ps->sps_list[sps_id], sps)) {
ff_refstruct_unref();
} else {
remove_sps(ps, sps_id);
@@ -1348,6 +1348,9 @@ int ff_hevc_decode_nal_sps(GetBitContext
Re: [FFmpeg-devel] [PATCH] avocdec/hevc_ps: don't use a fixed sized buffer for parameter set raw data
James Almer:
> Allocate it instead, and use it to compare sets instead of the parsed struct.
>
> Signed-off-by: James Almer
> ---
> libavcodec/hevc_ps.c | 84 ++--
> libavcodec/hevc_ps.h | 14 +---
> 2 files changed, 51 insertions(+), 47 deletions(-)
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 6475d86d7d..e417039d76 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -442,20 +442,18 @@ static int decode_hrd(GetBitContext *gb, int
> common_inf_present,
> return 0;
> }
>
> -static void uninit_vps(FFRefStructOpaque opaque, void *obj)
> +static void hevc_vps_free(FFRefStructOpaque opaque, void *obj)
> {
> HEVCVPS *vps = obj;
>
> av_freep(>hdr);
> +av_freep(>data);
> }
>
> static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
> {
> -if (!memcmp(vps1, vps2, offsetof(HEVCVPS, hdr)))
> -return !vps1->vps_num_hrd_parameters ||
> - !memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
> sizeof(*vps1->hdr));
> -
> -return 0;
> +return vps1->data_size == vps2->data_size &&
> + !memcmp(vps1->data, vps2->data, vps1->data_size);
> }
>
> int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
> @@ -463,25 +461,20 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
> AVCodecContext *avctx,
> {
> int i,j;
> int vps_id = 0;
> -ptrdiff_t nal_size;
> -HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, uninit_vps);
> +int ret = AVERROR_INVALIDDATA;
> +HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL,
> hevc_vps_free);
>
> if (!vps)
> return AVERROR(ENOMEM);
>
> av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
>
> -nal_size = gb->buffer_end - gb->buffer;
> -if (nal_size > sizeof(vps->data)) {
> -av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized VPS "
> - "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
> - nal_size, sizeof(vps->data));
> -vps->data_size = sizeof(vps->data);
> -} else {
> -vps->data_size = nal_size;
> +vps->data_size = gb->buffer_end - gb->buffer;
> +vps->data = av_memdup(gb->buffer, vps->data_size);
> +if (!vps->data) {
> +ret = AVERROR(ENOMEM);
> +goto err;
> }
> -memcpy(vps->data, gb->buffer, vps->data_size);
> -
> vps_id = vps->vps_id = get_bits(gb, 4);
>
> if (get_bits(gb, 2) != 3) { // vps_reserved_three_2bits
> @@ -591,7 +584,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
> AVCodecContext *avctx,
>
> err:
> ff_refstruct_unref();
> -return AVERROR_INVALIDDATA;
> +return ret;
> }
>
> static void decode_vui(GetBitContext *gb, AVCodecContext *avctx,
> @@ -1294,36 +1287,43 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext
> *gb, unsigned int *sps_id,
> return 0;
> }
>
> +static void hevc_sps_free(FFRefStructOpaque opaque, void *obj)
> +{
> +HEVCSPS *sps = obj;
> +
> +av_freep(>data);
> +}
> +
> +static int compare_sps(const HEVCSPS *sps1, const HEVCSPS *sps2)
> +{
> +return sps1->data_size == sps2->data_size &&
> + !memcmp(sps1->data, sps2->data, sps1->data_size);
> +}
> +
> int ff_hevc_decode_nal_sps(GetBitContext *gb, AVCodecContext *avctx,
> HEVCParamSets *ps, int apply_defdispwin)
> {
> -HEVCSPS *sps = ff_refstruct_allocz(sizeof(*sps));
> +HEVCSPS *sps = ff_refstruct_alloc_ext(sizeof(*sps), 0, NULL,
> hevc_sps_free);
> unsigned int sps_id;
> int ret;
> -ptrdiff_t nal_size;
>
> if (!sps)
> return AVERROR(ENOMEM);
>
> av_log(avctx, AV_LOG_DEBUG, "Decoding SPS\n");
>
> -nal_size = gb->buffer_end - gb->buffer;
> -if (nal_size > sizeof(sps->data)) {
> -av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized SPS "
> - "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
> - nal_size, sizeof(sps->data));
> -sps->data_size = sizeof(sps->data);
> -} else {
> -sps->data_size = nal_size;
> +sps->data_size = gb->buffer_end - gb->buffer;
> +sps->data = av_memdup(gb->buffer, sps->data_size);
> +if (!sps->data) {
> +ret = AVERROR(ENOMEM);
> +goto err;
> }
> -memcpy(sps->data, gb->buffer, sps->data_size);
>
> ret = ff_hevc_parse_sps(sps, gb, _id,
> apply_defdispwin,
> ps->vps_list, avctx);
> if (ret < 0) {
> -ff_refstruct_unref();
> -return ret;
> +goto err;
> }
>
> if (avctx->debug & FF_DEBUG_BITSTREAM) {
> @@ -1340,7 +1340,7 @@ int ff_hevc_decode_nal_sps(GetBitContext *gb,
> AVCodecContext *avctx,
> * original one.
> * otherwise drop all PPSes that depend on it */
> if (ps->sps_list[sps_id] &&
> -!memcmp(ps->sps_list[sps_id], sps, sizeof(*sps))) {
> +
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
Mark Thompson: > On 29/03/2024 14:00, Andreas Rheinhardt wrote: >> James Almer: >>> On 3/29/2024 10:10 AM, Mark Thompson wrote: On 28/03/2024 13:15, tong1.wu-at-intel@ffmpeg.org wrote: > From: Tong Wu > > HEVCHdrParams* receives a pointer which points to a dynamically > allocated memory block. It causes the memcmp always returning 1. > Add a function to do the comparision. A condition is also added to > avoid malloc(0). > > Signed-off-by: Tong Wu > --- > libavcodec/hevc_ps.c | 20 > libavcodec/hevc_ps.h | 4 +++- > 2 files changed, 19 insertions(+), 5 deletions(-) It doesn't seem like this method works at all, even before the recent change with the pointer. Structs can contain arbitrary padding, and any write to the struct makes the padding unspecified. memcmp() is therefore never valid as a method of comparing after writing some fields, as done here. (It could only be valid if the structs compared were made by memcpy() with no fields written directly.) >>> >>> The struct is zero allocated, so shouldn't the padding be exactly the >>> same for two equal VPSs after parsing? >>> >> >> In practice it is (and the current code already relied on this); yet as >> has already been said padding bytes take unspecified values at any store >> (to any member). In practice, if the compiler uses instructions that >> clobber the padding, the padding in both structs is clobbered in the >> same way. > > This seems like a strong assumption beyond that of the C specification > which needs to be documented. > > Are you expecting that there is no case where ABI-undefined top bits of > registers can leak into the padding fields, or that all functions called > here will necessarily set those top bits to the same values, or > something else? > Yes, I am expecting that. That is also what the code already relied on before the addition of the allocated field and there have been no reports that this caused issues. This does not change that I consider it crazy to remove the parameter sets referencing a parameter set that is removed. - 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] avocdec/hevc_ps: don't use a fixed sized buffer for parameter set raw data
Allocate it instead, and use it to compare sets instead of the parsed struct.
Signed-off-by: James Almer
---
libavcodec/hevc_ps.c | 84 ++--
libavcodec/hevc_ps.h | 14 +---
2 files changed, 51 insertions(+), 47 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 6475d86d7d..e417039d76 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -442,20 +442,18 @@ static int decode_hrd(GetBitContext *gb, int
common_inf_present,
return 0;
}
-static void uninit_vps(FFRefStructOpaque opaque, void *obj)
+static void hevc_vps_free(FFRefStructOpaque opaque, void *obj)
{
HEVCVPS *vps = obj;
av_freep(>hdr);
+av_freep(>data);
}
static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
{
-if (!memcmp(vps1, vps2, offsetof(HEVCVPS, hdr)))
-return !vps1->vps_num_hrd_parameters ||
- !memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
sizeof(*vps1->hdr));
-
-return 0;
+return vps1->data_size == vps2->data_size &&
+ !memcmp(vps1->data, vps2->data, vps1->data_size);
}
int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
@@ -463,25 +461,20 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
{
int i,j;
int vps_id = 0;
-ptrdiff_t nal_size;
-HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL, uninit_vps);
+int ret = AVERROR_INVALIDDATA;
+HEVCVPS *vps = ff_refstruct_alloc_ext(sizeof(*vps), 0, NULL,
hevc_vps_free);
if (!vps)
return AVERROR(ENOMEM);
av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
-nal_size = gb->buffer_end - gb->buffer;
-if (nal_size > sizeof(vps->data)) {
-av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized VPS "
- "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
- nal_size, sizeof(vps->data));
-vps->data_size = sizeof(vps->data);
-} else {
-vps->data_size = nal_size;
+vps->data_size = gb->buffer_end - gb->buffer;
+vps->data = av_memdup(gb->buffer, vps->data_size);
+if (!vps->data) {
+ret = AVERROR(ENOMEM);
+goto err;
}
-memcpy(vps->data, gb->buffer, vps->data_size);
-
vps_id = vps->vps_id = get_bits(gb, 4);
if (get_bits(gb, 2) != 3) { // vps_reserved_three_2bits
@@ -591,7 +584,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
err:
ff_refstruct_unref();
-return AVERROR_INVALIDDATA;
+return ret;
}
static void decode_vui(GetBitContext *gb, AVCodecContext *avctx,
@@ -1294,36 +1287,43 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
return 0;
}
+static void hevc_sps_free(FFRefStructOpaque opaque, void *obj)
+{
+HEVCSPS *sps = obj;
+
+av_freep(>data);
+}
+
+static int compare_sps(const HEVCSPS *sps1, const HEVCSPS *sps2)
+{
+return sps1->data_size == sps2->data_size &&
+ !memcmp(sps1->data, sps2->data, sps1->data_size);
+}
+
int ff_hevc_decode_nal_sps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps, int apply_defdispwin)
{
-HEVCSPS *sps = ff_refstruct_allocz(sizeof(*sps));
+HEVCSPS *sps = ff_refstruct_alloc_ext(sizeof(*sps), 0, NULL,
hevc_sps_free);
unsigned int sps_id;
int ret;
-ptrdiff_t nal_size;
if (!sps)
return AVERROR(ENOMEM);
av_log(avctx, AV_LOG_DEBUG, "Decoding SPS\n");
-nal_size = gb->buffer_end - gb->buffer;
-if (nal_size > sizeof(sps->data)) {
-av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized SPS "
- "(%"PTRDIFF_SPECIFIER" > %"SIZE_SPECIFIER")\n",
- nal_size, sizeof(sps->data));
-sps->data_size = sizeof(sps->data);
-} else {
-sps->data_size = nal_size;
+sps->data_size = gb->buffer_end - gb->buffer;
+sps->data = av_memdup(gb->buffer, sps->data_size);
+if (!sps->data) {
+ret = AVERROR(ENOMEM);
+goto err;
}
-memcpy(sps->data, gb->buffer, sps->data_size);
ret = ff_hevc_parse_sps(sps, gb, _id,
apply_defdispwin,
ps->vps_list, avctx);
if (ret < 0) {
-ff_refstruct_unref();
-return ret;
+goto err;
}
if (avctx->debug & FF_DEBUG_BITSTREAM) {
@@ -1340,7 +1340,7 @@ int ff_hevc_decode_nal_sps(GetBitContext *gb,
AVCodecContext *avctx,
* original one.
* otherwise drop all PPSes that depend on it */
if (ps->sps_list[sps_id] &&
-!memcmp(ps->sps_list[sps_id], sps, sizeof(*sps))) {
+compare_sps(ps->sps_list[sps_id], sps)) {
ff_refstruct_unref();
} else {
remove_sps(ps, sps_id);
@@ -1348,6 +1348,9 @@ int ff_hevc_decode_nal_sps(GetBitContext *gb,
AVCodecContext *avctx,
}
return 0;
+err:
+ff_refstruct_unref();
+return ret;
}
static void
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
On 29/03/2024 14:00, Andreas Rheinhardt wrote: James Almer: On 3/29/2024 10:10 AM, Mark Thompson wrote: On 28/03/2024 13:15, tong1.wu-at-intel@ffmpeg.org wrote: From: Tong Wu HEVCHdrParams* receives a pointer which points to a dynamically allocated memory block. It causes the memcmp always returning 1. Add a function to do the comparision. A condition is also added to avoid malloc(0). Signed-off-by: Tong Wu --- libavcodec/hevc_ps.c | 20 libavcodec/hevc_ps.h | 4 +++- 2 files changed, 19 insertions(+), 5 deletions(-) It doesn't seem like this method works at all, even before the recent change with the pointer. Structs can contain arbitrary padding, and any write to the struct makes the padding unspecified. memcmp() is therefore never valid as a method of comparing after writing some fields, as done here. (It could only be valid if the structs compared were made by memcpy() with no fields written directly.) The struct is zero allocated, so shouldn't the padding be exactly the same for two equal VPSs after parsing? In practice it is (and the current code already relied on this); yet as has already been said padding bytes take unspecified values at any store (to any member). In practice, if the compiler uses instructions that clobber the padding, the padding in both structs is clobbered in the same way. This seems like a strong assumption beyond that of the C specification which needs to be documented. Are you expecting that there is no case where ABI-undefined top bits of registers can leak into the padding fields, or that all functions called here will necessarily set those top bits to the same values, or something else? - Mark ___ 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 v2 1/2] avfilter/vf_setparams: Add timeline support
This is helpful at least for test purposes.
---
libavfilter/vf_setparams.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_setparams.c b/libavfilter/vf_setparams.c
index c96f4d314b..1b5eb70344 100644
--- a/libavfilter/vf_setparams.c
+++ b/libavfilter/vf_setparams.c
@@ -198,7 +198,7 @@ const AVFilter ff_vf_setparams = {
.description = NULL_IF_CONFIG_SMALL("Force field, or color property for
the output video frame."),
.priv_size = sizeof(SetParamsContext),
.priv_class = _class,
-.flags = AVFILTER_FLAG_METADATA_ONLY,
+.flags = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC |
AVFILTER_FLAG_METADATA_ONLY,
FILTER_INPUTS(inputs),
FILTER_OUTPUTS(ff_video_default_filterpad),
FILTER_QUERY_FUNC(query_formats),
--
2.30.2
___
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 v2 0/2] avfilter/vf_colorspace: Use colorspace negotiation API
I thought the issue was fixed with b89ee26539 but it is not. Note that I have introduced timeline support in vf_setparams in order to make testing easier. v2: fixed color_range pass-through Nicolas Gaullier (2): avfilter/vf_setparams: Add timeline support avfilter/vf_colorspace: Use colorspace negotiation API libavfilter/vf_colorspace.c | 64 + libavfilter/vf_setparams.c | 2 +- 2 files changed, 38 insertions(+), 28 deletions(-) -- 2.30.2 ___ 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 v2 2/2] avfilter/vf_colorspace: Use colorspace negotiation API
Fixes a regression due to the fact that the colorspace filter does
not use the new API introduced by 8c7934f73ab6c568acaa.
The scale filter uses it since 45e09a30419cc2a7251e, and the setparams
filter since 3bf80df3ccd32aed23f0.
Example 1 - color_range specified and chained with scale filter:
ffmpeg -f lavfi -i testsrc -vf setparams=color_primaries=bt470bg:
color_trc=smpte170m:colorspace=bt470bg,colorspace=bt709:range=tv,scale
,showinfo -f null -frames 1 -
Before:
color_range:unknown color_space:bt470bg ...
After:
color_range:tv color_space:bt709 ...
Example 2 - color_range pass-through:
ffmpeg -f lavfi -i testsrc -vf "setparams=color_primaries=bt470bg:
color_trc=smpte170m:colorspace=bt470bg:range=unknown,
setparams=range=pc:enable='between(n,1,2)',
setparams=range=tv:enable='between(n,2,3)',
colorspace=bt709,showinfo"
-f null -frames 3 - 2>&1|awk "/color_/ {print \$4}"
Before:
color_range:tv
color_range:tv
color_range:tv
After:
color_range:unknown
color_range:pc
color_range:tv
Signed-off-by: Nicolas Gaullier
---
libavfilter/vf_colorspace.c | 64 +
1 file changed, 37 insertions(+), 27 deletions(-)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index f367ce17c6..a006fd5aac 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -432,8 +432,7 @@ static int create_filtergraph(AVFilterContext *ctx,
if (out->color_trc != s->out_trc) s->out_txchr = NULL;
if (in->colorspace != s->in_csp ||
in->color_range != s->in_rng) s->in_lumacoef = NULL;
-if (out->colorspace != s->out_csp ||
-out->color_range != s->out_rng) s->out_lumacoef = NULL;
+if (out->color_range != s->out_rng) s->rgb2yuv = NULL;
if (!s->out_primaries || !s->in_primaries) {
s->in_prm = in->color_primaries;
@@ -562,26 +561,8 @@ static int create_filtergraph(AVFilterContext *ctx,
redo_yuv2rgb = 1;
}
-if (!s->out_lumacoef) {
-s->out_csp = out->colorspace;
+if (!s->rgb2yuv) {
s->out_rng = out->color_range;
-s->out_lumacoef = av_csp_luma_coeffs_from_avcsp(s->out_csp);
-if (!s->out_lumacoef) {
-if (s->out_csp == AVCOL_SPC_UNSPECIFIED) {
-if (s->user_all == CS_UNSPECIFIED) {
-av_log(ctx, AV_LOG_ERROR,
- "Please specify output colorspace\n");
-} else {
-av_log(ctx, AV_LOG_ERROR,
- "Unsupported output color property %d\n",
s->user_all);
-}
-} else {
-av_log(ctx, AV_LOG_ERROR,
- "Unsupported output colorspace %d (%s)\n", s->out_csp,
- av_color_space_name(s->out_csp));
-}
-return AVERROR(EINVAL);
-}
redo_rgb2yuv = 1;
}
@@ -686,6 +667,26 @@ static av_cold int init(AVFilterContext *ctx)
{
ColorSpaceContext *s = ctx->priv;
+s->out_csp = s->user_csp == AVCOL_SPC_UNSPECIFIED ?
+ default_csp[FFMIN(s->user_all, CS_NB)] : s->user_csp;
+s->out_lumacoef = av_csp_luma_coeffs_from_avcsp(s->out_csp);
+if (!s->out_lumacoef) {
+if (s->out_csp == AVCOL_SPC_UNSPECIFIED) {
+if (s->user_all == CS_UNSPECIFIED) {
+av_log(ctx, AV_LOG_ERROR,
+ "Please specify output colorspace\n");
+} else {
+av_log(ctx, AV_LOG_ERROR,
+ "Unsupported output color property %d\n", s->user_all);
+}
+} else {
+av_log(ctx, AV_LOG_ERROR,
+ "Unsupported output colorspace %d (%s)\n", s->out_csp,
+ av_color_space_name(s->out_csp));
+}
+return AVERROR(EINVAL);
+}
+
ff_colorspacedsp_init(>dsp);
return 0;
@@ -734,6 +735,10 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
return res;
}
+out->colorspace = outlink->colorspace;
+if (s->user_rng == AVCOL_RANGE_UNSPECIFIED)
+outlink->color_range = link->src->inputs[0]->color_range;
+out->color_range = outlink->color_range;
out->color_primaries = s->user_prm == AVCOL_PRI_UNSPECIFIED ?
default_prm[FFMIN(s->user_all, CS_NB)] :
s->user_prm;
if (s->user_trc == AVCOL_TRC_UNSPECIFIED) {
@@ -745,10 +750,6 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
} else {
out->color_trc = s->user_trc;
}
-out->colorspace = s->user_csp == AVCOL_SPC_UNSPECIFIED ?
- default_csp[FFMIN(s->user_all, CS_NB)] :
s->user_csp;
-out->color_range = s->user_rng == AVCOL_RANGE_UNSPECIFIED ?
- in->color_range : s->user_rng;
if (rgb_sz != s->rgb_sz) {
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(out->format);
int uvw = in->width >>
Re: [FFmpeg-devel] [PATCH v3] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
On 3/29/2024 12:31 PM, tong1...@intel.com wrote: From: Tong Wu HEVCHdrParams* receives a pointer which points to a dynamically allocated memory block. It causes the memcmp always returning 1. Add a function to do the comparision. A condition is also added to avoid malloc(0). Reviewed-by: James Almer Signed-off-by: Tong Wu --- libavcodec/hevc_ps.c | 19 +++ libavcodec/hevc_ps.h | 4 +++- 2 files changed, 18 insertions(+), 5 deletions(-) LGTM. Will apply. ___ 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 v2] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
>From: ffmpeg-devel On Behalf Of James
>Almer
>Sent: Friday, March 29, 2024 11:18 PM
>To: ffmpeg-devel@ffmpeg.org
>Subject: Re: [FFmpeg-devel] [PATCH v2] avcodec/hevc_ps: fix the problem of
>memcmp losing effectiveness
>
>On 3/29/2024 12:13 PM, tong1.wu-at-intel@ffmpeg.org wrote:
>> From: Tong Wu
>>
>> HEVCHdrParams* receives a pointer which points to a dynamically
>> allocated memory block. It causes the memcmp always returning 1.
>> Add a function to do the comparision. A condition is also added to
>> avoid malloc(0).
>>
>> Signed-off-by: Tong Wu
>> ---
>> libavcodec/hevc_ps.c | 22 ++
>> libavcodec/hevc_ps.h | 4 +++-
>> 2 files changed, 21 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
>> index cbef3ef4cd..d3c589ec24 100644
>> --- a/libavcodec/hevc_ps.c
>> +++ b/libavcodec/hevc_ps.c
>> @@ -449,6 +449,18 @@ static void uninit_vps(FFRefStructOpaque opaque,
>void *obj)
>> av_freep(>hdr);
>> }
>>
>> +static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
>> +{
>> +if (!vps1->hdr && !vps2->hdr && !memcmp(vps1, vps2, offsetof(HEVCVPS,
>hdr)))
>> +return 1;
>> +
>> +if (vps1->hdr && vps2->hdr && !memcmp(vps1, vps2, offsetof(HEVCVPS,
>hdr)) &&
>> +!memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
>sizeof(*vps1->hdr)))
>> +return 1;
>> +
>> +return 0;
>> +}
>
>Something like this should be simpler
>
>> +static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
>> +{
>> +if (!memcmp(vps1, vps2, offsetof(HEVCVPS, hdr)))
>> +return !vps1->vps_num_hrd_parameters ||
>> + !memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
>sizeof(*vps1->hdr));
>> +
>> +return 0;
>> +}
>
>If vps1 is equal to vps2 up to hdr, then vps_num_hrd_parameters will be
>the same in both and you can safely just go ahead with the memcmp for hdr.
That makes sense. Thank you.
>___
>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".
[FFmpeg-devel] [PATCH v3] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
From: Tong Wu
HEVCHdrParams* receives a pointer which points to a dynamically
allocated memory block. It causes the memcmp always returning 1.
Add a function to do the comparision. A condition is also added to
avoid malloc(0).
Reviewed-by: James Almer
Signed-off-by: Tong Wu
---
libavcodec/hevc_ps.c | 19 +++
libavcodec/hevc_ps.h | 4 +++-
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index cbef3ef4cd..6475d86d7d 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -449,6 +449,15 @@ static void uninit_vps(FFRefStructOpaque opaque, void *obj)
av_freep(>hdr);
}
+static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
+{
+if (!memcmp(vps1, vps2, offsetof(HEVCVPS, hdr)))
+return !vps1->vps_num_hrd_parameters ||
+ !memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
sizeof(*vps1->hdr));
+
+return 0;
+}
+
int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps)
{
@@ -545,9 +554,11 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
goto err;
}
-vps->hdr = av_calloc(vps->vps_num_hrd_parameters, sizeof(*vps->hdr));
-if (!vps->hdr)
-goto err;
+if (vps->vps_num_hrd_parameters) {
+vps->hdr = av_calloc(vps->vps_num_hrd_parameters,
sizeof(*vps->hdr));
+if (!vps->hdr)
+goto err;
+}
for (i = 0; i < vps->vps_num_hrd_parameters; i++) {
int common_inf_present = 1;
@@ -569,7 +580,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
}
if (ps->vps_list[vps_id] &&
-!memcmp(ps->vps_list[vps_id], vps, sizeof(*vps))) {
+compare_vps(ps->vps_list[vps_id], vps)) {
ff_refstruct_unref();
} else {
remove_vps(ps, vps_id);
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index cc75aeb8d3..0d8eaf2b3e 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -153,7 +153,6 @@ typedef struct PTL {
typedef struct HEVCVPS {
unsigned int vps_id;
-HEVCHdrParams *hdr;
uint8_t vps_temporal_id_nesting_flag;
int vps_max_layers;
@@ -175,6 +174,9 @@ typedef struct HEVCVPS {
uint8_t data[4096];
int data_size;
+/* Put this at the end of the structure to make it easier to calculate the
+ * size before this pointer, which is used for memcmp */
+HEVCHdrParams *hdr;
} HEVCVPS;
typedef struct ScalingList {
--
2.41.0.windows.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] [PATCH v2] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
On 3/29/2024 12:13 PM, tong1.wu-at-intel@ffmpeg.org wrote:
From: Tong Wu
HEVCHdrParams* receives a pointer which points to a dynamically
allocated memory block. It causes the memcmp always returning 1.
Add a function to do the comparision. A condition is also added to
avoid malloc(0).
Signed-off-by: Tong Wu
---
libavcodec/hevc_ps.c | 22 ++
libavcodec/hevc_ps.h | 4 +++-
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index cbef3ef4cd..d3c589ec24 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -449,6 +449,18 @@ static void uninit_vps(FFRefStructOpaque opaque, void *obj)
av_freep(>hdr);
}
+static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
+{
+if (!vps1->hdr && !vps2->hdr && !memcmp(vps1, vps2, offsetof(HEVCVPS,
hdr)))
+return 1;
+
+if (vps1->hdr && vps2->hdr && !memcmp(vps1, vps2, offsetof(HEVCVPS, hdr))
&&
+!memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
sizeof(*vps1->hdr)))
+return 1;
+
+return 0;
+}
Something like this should be simpler
+static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
+{
+if (!memcmp(vps1, vps2, offsetof(HEVCVPS, hdr)))
+return !vps1->vps_num_hrd_parameters ||
+ !memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
sizeof(*vps1->hdr));
+
+return 0;
+}
If vps1 is equal to vps2 up to hdr, then vps_num_hrd_parameters will be
the same in both and you can safely just go ahead with the memcmp for hdr.
___
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] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
>From: ffmpeg-devel On Behalf Of James
>Almer
>Sent: Friday, March 29, 2024 8:46 PM
>To: ffmpeg-devel@ffmpeg.org
>Subject: Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of
>memcmp losing effectiveness
>
>On 3/28/2024 10:15 AM, tong1.wu-at-intel@ffmpeg.org wrote:
>> From: Tong Wu
>>
>> HEVCHdrParams* receives a pointer which points to a dynamically
>> allocated memory block. It causes the memcmp always returning 1.
>> Add a function to do the comparision. A condition is also added to
>> avoid malloc(0).
>>
>> Signed-off-by: Tong Wu
>> ---
>> libavcodec/hevc_ps.c | 20
>> libavcodec/hevc_ps.h | 4 +++-
>> 2 files changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
>> index cbef3ef4cd..8b3a27a17c 100644
>> --- a/libavcodec/hevc_ps.c
>> +++ b/libavcodec/hevc_ps.c
>> @@ -449,6 +449,16 @@ static void uninit_vps(FFRefStructOpaque opaque,
>void *obj)
>> av_freep(>hdr);
>> }
>>
>> +static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
>> +{
>> +if ((!vps1->hdr && !vps2->hdr) ||
>> +(vps1->hdr && vps2->hdr && !memcmp(vps1->hdr, vps2->hdr,
>sizeof(*vps1->hdr {
>
>I think this should be vps1->vps_num_hrd_parameters *
>sizeof(*vps1->hdr), and done after the memcmp below to ensure
>vps_num_hrd_parameters is the same value in both structs.
Updated as suggested. Thanks.
Tong
>
>> +return !memcmp(vps1, vps2, offsetof(HEVCVPS, hdr));
>> +}
>> +
>> +return 0;
>> +}
>> +
>> int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
>> HEVCParamSets *ps)
>> {
>> @@ -545,9 +555,11 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
>AVCodecContext *avctx,
>> goto err;
>> }
>>
>> -vps->hdr = av_calloc(vps->vps_num_hrd_parameters, sizeof(*vps-
>>hdr));
>> -if (!vps->hdr)
>> -goto err;
>> +if (vps->vps_num_hrd_parameters) {
>> +vps->hdr = av_calloc(vps->vps_num_hrd_parameters, sizeof(*vps-
>>hdr));
>> +if (!vps->hdr)
>> +goto err;
>> +}
>>
>> for (i = 0; i < vps->vps_num_hrd_parameters; i++) {
>> int common_inf_present = 1;
>> @@ -569,7 +581,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
>AVCodecContext *avctx,
>> }
>>
>> if (ps->vps_list[vps_id] &&
>> -!memcmp(ps->vps_list[vps_id], vps, sizeof(*vps))) {
>> +compare_vps(ps->vps_list[vps_id], vps)) {
>> ff_refstruct_unref();
>> } else {
>> remove_vps(ps, vps_id);
>> diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
>> index cc75aeb8d3..0d8eaf2b3e 100644
>> --- a/libavcodec/hevc_ps.h
>> +++ b/libavcodec/hevc_ps.h
>> @@ -153,7 +153,6 @@ typedef struct PTL {
>>
>> typedef struct HEVCVPS {
>> unsigned int vps_id;
>> -HEVCHdrParams *hdr;
>>
>> uint8_t vps_temporal_id_nesting_flag;
>> int vps_max_layers;
>> @@ -175,6 +174,9 @@ typedef struct HEVCVPS {
>>
>> uint8_t data[4096];
>> int data_size;
>> +/* Put this at the end of the structure to make it easier to calculate
>> the
>> + * size before this pointer, which is used for memcmp */
>> +HEVCHdrParams *hdr;
>> } HEVCVPS;
>>
>> typedef struct ScalingList {
>___
>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".
[FFmpeg-devel] [PATCH v2] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
From: Tong Wu
HEVCHdrParams* receives a pointer which points to a dynamically
allocated memory block. It causes the memcmp always returning 1.
Add a function to do the comparision. A condition is also added to
avoid malloc(0).
Signed-off-by: Tong Wu
---
libavcodec/hevc_ps.c | 22 ++
libavcodec/hevc_ps.h | 4 +++-
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index cbef3ef4cd..d3c589ec24 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -449,6 +449,18 @@ static void uninit_vps(FFRefStructOpaque opaque, void *obj)
av_freep(>hdr);
}
+static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
+{
+if (!vps1->hdr && !vps2->hdr && !memcmp(vps1, vps2, offsetof(HEVCVPS,
hdr)))
+return 1;
+
+if (vps1->hdr && vps2->hdr && !memcmp(vps1, vps2, offsetof(HEVCVPS, hdr))
&&
+!memcmp(vps1->hdr, vps2->hdr, vps1->vps_num_hrd_parameters *
sizeof(*vps1->hdr)))
+return 1;
+
+return 0;
+}
+
int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps)
{
@@ -545,9 +557,11 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
goto err;
}
-vps->hdr = av_calloc(vps->vps_num_hrd_parameters, sizeof(*vps->hdr));
-if (!vps->hdr)
-goto err;
+if (vps->vps_num_hrd_parameters) {
+vps->hdr = av_calloc(vps->vps_num_hrd_parameters,
sizeof(*vps->hdr));
+if (!vps->hdr)
+goto err;
+}
for (i = 0; i < vps->vps_num_hrd_parameters; i++) {
int common_inf_present = 1;
@@ -569,7 +583,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
}
if (ps->vps_list[vps_id] &&
-!memcmp(ps->vps_list[vps_id], vps, sizeof(*vps))) {
+compare_vps(ps->vps_list[vps_id], vps)) {
ff_refstruct_unref();
} else {
remove_vps(ps, vps_id);
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index cc75aeb8d3..0d8eaf2b3e 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -153,7 +153,6 @@ typedef struct PTL {
typedef struct HEVCVPS {
unsigned int vps_id;
-HEVCHdrParams *hdr;
uint8_t vps_temporal_id_nesting_flag;
int vps_max_layers;
@@ -175,6 +174,9 @@ typedef struct HEVCVPS {
uint8_t data[4096];
int data_size;
+/* Put this at the end of the structure to make it easier to calculate the
+ * size before this pointer, which is used for memcmp */
+HEVCHdrParams *hdr;
} HEVCVPS;
typedef struct ScalingList {
--
2.41.0.windows.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] [PATCH 07/18] swscale/swscale_internal: Only include altivec header iff HAVE_ALTIVEC
Andreas: On Thu, Mar 28, 2024 at 7:11 PM Andreas Rheinhardt wrote: > > Signed-off-by: Andreas Rheinhardt > --- > libswscale/swscale_internal.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h > index abeebbb002..2f6cc70946 100644 > --- a/libswscale/swscale_internal.h > +++ b/libswscale/swscale_internal.h > @@ -34,7 +34,9 @@ > #include "libavutil/pixfmt.h" > #include "libavutil/pixdesc.h" > #include "libavutil/slicethread.h" > +#if HAVE_ALTIVEC > #include "libavutil/ppc/util_altivec.h" > +#endif > #include "libavutil/half2float.h" > > #define STR(s) AV_TOSTRING(s) // AV_STRINGIFY is too long > -- > 2.40.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". This also looks good to me. -- Sean McGovern ___ 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 06/18] postproc/postprocess: Don't generally include arch-specific headers
Andreas:
On Thu, Mar 28, 2024 at 7:11 PM Andreas Rheinhardt
wrote:
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libpostproc/postprocess.c | 3 ++-
> libpostproc/postprocess_template.c | 5 -
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libpostproc/postprocess.c b/libpostproc/postprocess.c
> index 0586e458b4..8f4de8b1e1 100644
> --- a/libpostproc/postprocess.c
> +++ b/libpostproc/postprocess.c
> @@ -88,7 +88,6 @@ try to unroll inner for(x=0 ... loop to avoid these damn
> if(x ... checks
> #include "postprocess.h"
> #include "postprocess_internal.h"
> #include "libavutil/avstring.h"
> -#include "libavutil/ppc/util_altivec.h"
>
> #define GET_MODE_BUFFER_SIZE 500
> #define OPTIONS_ARRAY_SIZE 10
> @@ -499,6 +498,8 @@ static av_always_inline void do_a_deblock_C(uint8_t *src,
> int step,
> #include "postprocess_template.c"
>
> #if HAVE_ALTIVEC
> +#include "libavutil/ppc/util_altivec.h"
> +
> # define TEMPLATE_PP_ALTIVEC 1
> # include "postprocess_altivec_template.c"
> # include "postprocess_template.c"
> diff --git a/libpostproc/postprocess_template.c
> b/libpostproc/postprocess_template.c
> index ade1d6ce2b..d56b45d3b4 100644
> --- a/libpostproc/postprocess_template.c
> +++ b/libpostproc/postprocess_template.c
> @@ -22,9 +22,12 @@
> * @file
> * mmx/mmx2/sse2 postprocess code.
> */
> +#include "config.h"
>
> #include "libavutil/mem_internal.h"
> +#if ARCH_X86
> #include "libavutil/x86/asm.h"
> +#endif
>
> /* A single TEMPLATE_PP_* should be defined (to 1) when this template is
> * included. The following macros will define its dependencies to 1 as well
> @@ -830,7 +833,7 @@ static inline void RENAME(doVertDefFilter)(uint8_t src[],
> int stride, PPContext
> #if !TEMPLATE_PP_ALTIVEC
> static inline void RENAME(dering)(uint8_t src[], int stride, PPContext *c)
> {
> -#if HAVE_7REGS && TEMPLATE_PP_MMXEXT
> +#if TEMPLATE_PP_MMXEXT && HAVE_7REGS
> DECLARE_ALIGNED(8, uint64_t, tmp)[3];
> __asm__ volatile(
> "pxor %%mm6, %%mm6 \n\t"
> --
> 2.40.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".
OK, looks good to me.
-- Sean McGovern
___
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] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
>From: ffmpeg-devel On Behalf Of >Andreas Rheinhardt >Sent: Friday, March 29, 2024 10:03 PM >To: ffmpeg-devel@ffmpeg.org >Subject: Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of >memcmp losing effectiveness > >Mark Thompson: >> On 28/03/2024 13:15, tong1.wu-at-intel@ffmpeg.org wrote: >>> From: Tong Wu >>> >>> HEVCHdrParams* receives a pointer which points to a dynamically >>> allocated memory block. It causes the memcmp always returning 1. >>> Add a function to do the comparision. A condition is also added to >>> avoid malloc(0). >>> >>> Signed-off-by: Tong Wu >>> --- >>> libavcodec/hevc_ps.c | 20 >>> libavcodec/hevc_ps.h | 4 +++- >>> 2 files changed, 19 insertions(+), 5 deletions(-) >> >> It doesn't seem like this method works at all, even before the recent >> change with the pointer. >> >> Structs can contain arbitrary padding, and any write to the struct makes >> the padding unspecified. memcmp() is therefore never valid as a method >> of comparing after writing some fields, as done here. (It could only be >> valid if the structs compared were made by memcpy() with no fields >> written directly.) >> >> The problem is mostly harmless because the nondeterministic replacement >> of structs which we were expecting to be equivalent doesn't actually >> change anything, so why don't we just remove the comparison and always >> replace? >> > >remove_vps() also removes any SPS referencing this VPS (and remove_sps() >does the same with PPS). Therefore if you simply repeat a VPS without >also repeating the other parameter sets directly after the new VPS and >before the first video NALU after the VPS, your extradata will have been >discarded. >This is not what the spec says. > > Yes and I observed for hevc decoder with hwaccel, get_format() is called multiple times which initializes the hwaccel context multiple times, as s->ps.sps is unexpectedly removed because of that. Hendrik also observed some playback glitches(see previous email) so it's not really harmless. >___ >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 2/5] fate/ffmpeg: Explicitly set pix fmt for sub2video tests
Sean McGovern: > Hi, > > > On Thu, Mar 28, 2024, 23:24 Andreas Rheinhardt < > andreas.rheinha...@outlook.com> wrote: > >> Otherwise the test would use bgra on little endian and argb >> on big endian. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> tests/fate/ffmpeg.mak | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak >> index 3c549b265e..fda3a29239 100644 >> --- a/tests/fate/ffmpeg.mak >> +++ b/tests/fate/ffmpeg.mak >> @@ -64,7 +64,7 @@ fate-sub2video_basic: CMD = framecrc >> -auto_conversion_filters \ >>-i $(TARGET_SAMPLES)/sub/vobsub.idx \ >>-fps_mode passthrough -copyts \ >>-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ >> - -c:v rawvideo -threads 1 >> + -c:v rawvideo -pix_fmt bgra -threads 1 >> >> # Time-limited run with a sample that doesn't require seeking and >> # contains samples within the initial period. >> @@ -74,7 +74,7 @@ fate-sub2video_time_limited: CMD = framecrc >> -auto_conversion_filters \ >>-fps_mode passthrough -copyts \ >>-t 15 \ >>-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ >> - -c:v rawvideo -threads 1 >> + -c:v rawvideo -threads 1 -pix_fmt bgra >> >> FATE_FFMPEG-$(call ENCDEC, PCM_S16LE, PCM_S16LE) += >> fate-unknown_layout-pcm >> fate-unknown_layout-pcm: $(AREF) >> -- >> 2.40.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". >> > > I already submitted this change a few weeks ago (March 6th to be precise) > and it has been left unreviewed. > Ok, will apply yours then. - 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 v10 2/5] avformat/rcwtdec: add RCWT Closed Captions demuxer
Tomas Härdin: > Can we please get away from this way of reading subtitles? Every other > type of media (audio, video) are capable of being streamed, but not > subtitles, precisely because all of them do all parsing in the > read_header() call. We have a perfectly good generic index and seeking > functionality. My recent experiment with srt shows it's possible to > read packets in read_packet() like every other demuxer.. Is there an example I can follow? Is this something that can be fixed in an enhancement patch or is it a deal-breaker to merge this? ___ 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 2/5] fate/ffmpeg: Explicitly set pix fmt for sub2video tests
Hi, On Thu, Mar 28, 2024, 23:24 Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Otherwise the test would use bgra on little endian and argb > on big endian. > > Signed-off-by: Andreas Rheinhardt > --- > tests/fate/ffmpeg.mak | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak > index 3c549b265e..fda3a29239 100644 > --- a/tests/fate/ffmpeg.mak > +++ b/tests/fate/ffmpeg.mak > @@ -64,7 +64,7 @@ fate-sub2video_basic: CMD = framecrc > -auto_conversion_filters \ >-i $(TARGET_SAMPLES)/sub/vobsub.idx \ >-fps_mode passthrough -copyts \ >-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ > - -c:v rawvideo -threads 1 > + -c:v rawvideo -pix_fmt bgra -threads 1 > > # Time-limited run with a sample that doesn't require seeking and > # contains samples within the initial period. > @@ -74,7 +74,7 @@ fate-sub2video_time_limited: CMD = framecrc > -auto_conversion_filters \ >-fps_mode passthrough -copyts \ >-t 15 \ >-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ > - -c:v rawvideo -threads 1 > + -c:v rawvideo -threads 1 -pix_fmt bgra > > FATE_FFMPEG-$(call ENCDEC, PCM_S16LE, PCM_S16LE) += > fate-unknown_layout-pcm > fate-unknown_layout-pcm: $(AREF) > -- > 2.40.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". > I already submitted this change a few weeks ago (March 6th to be precise) and it has been left unreviewed. -- Sean McGovern > ___ 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] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
Mark Thompson: > On 28/03/2024 13:15, tong1.wu-at-intel@ffmpeg.org wrote: >> From: Tong Wu >> >> HEVCHdrParams* receives a pointer which points to a dynamically >> allocated memory block. It causes the memcmp always returning 1. >> Add a function to do the comparision. A condition is also added to >> avoid malloc(0). >> >> Signed-off-by: Tong Wu >> --- >> libavcodec/hevc_ps.c | 20 >> libavcodec/hevc_ps.h | 4 +++- >> 2 files changed, 19 insertions(+), 5 deletions(-) > > It doesn't seem like this method works at all, even before the recent > change with the pointer. > > Structs can contain arbitrary padding, and any write to the struct makes > the padding unspecified. memcmp() is therefore never valid as a method > of comparing after writing some fields, as done here. (It could only be > valid if the structs compared were made by memcpy() with no fields > written directly.) > > The problem is mostly harmless because the nondeterministic replacement > of structs which we were expecting to be equivalent doesn't actually > change anything, so why don't we just remove the comparison and always > replace? > remove_vps() also removes any SPS referencing this VPS (and remove_sps() does the same with PPS). Therefore if you simply repeat a VPS without also repeating the other parameter sets directly after the new VPS and before the first video NALU after the VPS, your extradata will have been discarded. This is not what the spec says. - 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] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
James Almer: > On 3/29/2024 10:10 AM, Mark Thompson wrote: >> On 28/03/2024 13:15, tong1.wu-at-intel@ffmpeg.org wrote: >>> From: Tong Wu >>> >>> HEVCHdrParams* receives a pointer which points to a dynamically >>> allocated memory block. It causes the memcmp always returning 1. >>> Add a function to do the comparision. A condition is also added to >>> avoid malloc(0). >>> >>> Signed-off-by: Tong Wu >>> --- >>> libavcodec/hevc_ps.c | 20 >>> libavcodec/hevc_ps.h | 4 +++- >>> 2 files changed, 19 insertions(+), 5 deletions(-) >> >> It doesn't seem like this method works at all, even before the recent >> change with the pointer. >> >> Structs can contain arbitrary padding, and any write to the struct >> makes the padding unspecified. memcmp() is therefore never valid as a >> method of comparing after writing some fields, as done here. (It >> could only be valid if the structs compared were made by memcpy() with >> no fields written directly.) > > The struct is zero allocated, so shouldn't the padding be exactly the > same for two equal VPSs after parsing? > In practice it is (and the current code already relied on this); yet as has already been said padding bytes take unspecified values at any store (to any member). In practice, if the compiler uses instructions that clobber the padding, the padding in both structs is clobbered in the same way. - 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 v11 3/8] avcodec/bsf: Add awebp2webp bitstream filter
Thilo Borgmann via ffmpeg-devel: > Am 28.03.24 um 19:11 schrieb Stefano Sabatini: >> On date Thursday 2024-03-28 15:08:53 +0100, ffmpeg-devel Mailing List >> wrote: >>> Splits a packet containing a webp animations into >>> one non-compliant packet per frame of the animation. >>> Skips RIFF and WEBP chunks for those packets except >>> for the first. Copyies ICC, EXIF and XMP chunks first >>> into each of the packets except for the first. >>> --- >>> configure | 1 + >>> libavcodec/bitstream_filters.c | 1 + >>> libavcodec/bsf/Makefile | 1 + >>> libavcodec/bsf/awebp2webp.c | 350 + >>> 4 files changed, 353 insertions(+) >>> create mode 100644 libavcodec/bsf/awebp2webp.c >> >> missing doc/bitstreams.texi update? >> >> also you might mention in the Changelog, assuming this might be >> directly used by users > > Yes, adding docs next iteration. Also micro bump for a new bsf? (I'll > never get the rules of bumping...) > > It's yet a normal filter, Andreas wanted this to be non-public in the > end, requiring some additional changes before. > No need to add docs (or a version bump) for something that is not intended to be public; also you should probably have marked this patchset as WIP. - 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] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
On 3/29/2024 10:10 AM, Mark Thompson wrote: On 28/03/2024 13:15, tong1.wu-at-intel@ffmpeg.org wrote: From: Tong Wu HEVCHdrParams* receives a pointer which points to a dynamically allocated memory block. It causes the memcmp always returning 1. Add a function to do the comparision. A condition is also added to avoid malloc(0). Signed-off-by: Tong Wu --- libavcodec/hevc_ps.c | 20 libavcodec/hevc_ps.h | 4 +++- 2 files changed, 19 insertions(+), 5 deletions(-) It doesn't seem like this method works at all, even before the recent change with the pointer. Structs can contain arbitrary padding, and any write to the struct makes the padding unspecified. memcmp() is therefore never valid as a method of comparing after writing some fields, as done here. (It could only be valid if the structs compared were made by memcpy() with no fields written directly.) The struct is zero allocated, so shouldn't the padding be exactly the same for two equal VPSs after parsing? The problem is mostly harmless because the nondeterministic replacement of structs which we were expecting to be equivalent doesn't actually change anything, so why don't we just remove the comparison and always replace? Thanks, - Mark ___ 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".
[FFmpeg-devel] [PATCH] doc/muxers: add ircam
Most of the content copy from: http://fileformats.archiveteam.org/wiki/Berkeley/IRCAM/Carl_Sound_Format --- doc/muxers.texi | 18 ++ 1 file changed, 18 insertions(+) diff --git a/doc/muxers.texi b/doc/muxers.texi index 5cce26a43f..39597e000b 100644 --- a/doc/muxers.texi +++ b/doc/muxers.texi @@ -2682,6 +2682,24 @@ ffmpeg -f x11grab -framerate 1 -i :0.0 -q:v 6 -update 1 -protocol_opts method=PU @end example @end itemize +@section ircam +Berkeley / IRCAM / CARL Sound Filesystem (BICSF) format muxer. + +The Berkeley/IRCAM/CARL Sound Format, developed in the 1980s, is a result of the +merging of several different earlier sound file formats and systems including +the csound system developed by Dr Gareth Loy at the Computer Audio Research Lab +(CARL) at UC San Diego, the IRCAM sound file system developed by Rob Gross and +Dan Timis at the Institut de Recherche et Coordination Acoustique / Musique in +Paris and the Berkeley Fast Filesystem. + +It was developed initially as part of the Berkeley/IRCAM/CARL Sound Filesystem, +a suite of programs designed to implement a filesystem for audio applications +running under Berkeley UNIX. It was particularly popular in academic music +research centres, and was used a number of times in the creation of early +computer-generated compositions. + +This muxer accepts a single audio stream containing PCM data. + @section matroska Matroska container muxer. -- 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".
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
On 28/03/2024 13:15, tong1.wu-at-intel@ffmpeg.org wrote: From: Tong Wu HEVCHdrParams* receives a pointer which points to a dynamically allocated memory block. It causes the memcmp always returning 1. Add a function to do the comparision. A condition is also added to avoid malloc(0). Signed-off-by: Tong Wu --- libavcodec/hevc_ps.c | 20 libavcodec/hevc_ps.h | 4 +++- 2 files changed, 19 insertions(+), 5 deletions(-) It doesn't seem like this method works at all, even before the recent change with the pointer. Structs can contain arbitrary padding, and any write to the struct makes the padding unspecified. memcmp() is therefore never valid as a method of comparing after writing some fields, as done here. (It could only be valid if the structs compared were made by memcpy() with no fields written directly.) The problem is mostly harmless because the nondeterministic replacement of structs which we were expecting to be equivalent doesn't actually change anything, so why don't we just remove the comparison and always replace? Thanks, - Mark ___ 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] doc/muxers/image2: add mention to image2pipe
Clarify the difference with regards to the image2 muxer.
---
doc/muxers.texi | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 05a0c302cf..5cce26a43f 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2569,10 +2569,10 @@ Internet Low Bitrate Codec (iLBC) raw muxer.
It accepts a single @samp{ilbc} audio stream.
@anchor{image2}
-@section image2
+@section image2, image2pipe
Image file muxer.
-The image file muxer writes video frames to image files.
+The @samp{image2} muxer writes video frames to image files.
The output filenames are specified by a pattern, which can be used to
produce sequentially numbered series of files.
@@ -2603,6 +2603,10 @@ each of the YUV420P components. To read or write this
image file format,
specify the name of the '.Y' file. The muxer will automatically open the
'.U' and '.V' files as required.
+The @samp{image2pipe} muxer accepts the same options as the @samp{image2}
muxer,
+but ignores the pattern verification and expansion, as it is supposed to write
+to the command output rather than to an actual stored file.
+
@subsection Options
@table @option
@item frame_pts @var{bool}
--
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".
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix the problem of memcmp losing effectiveness
On 3/28/2024 10:15 AM, tong1.wu-at-intel@ffmpeg.org wrote:
From: Tong Wu
HEVCHdrParams* receives a pointer which points to a dynamically
allocated memory block. It causes the memcmp always returning 1.
Add a function to do the comparision. A condition is also added to
avoid malloc(0).
Signed-off-by: Tong Wu
---
libavcodec/hevc_ps.c | 20
libavcodec/hevc_ps.h | 4 +++-
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index cbef3ef4cd..8b3a27a17c 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -449,6 +449,16 @@ static void uninit_vps(FFRefStructOpaque opaque, void *obj)
av_freep(>hdr);
}
+static int compare_vps(const HEVCVPS *vps1, const HEVCVPS *vps2)
+{
+if ((!vps1->hdr && !vps2->hdr) ||
+(vps1->hdr && vps2->hdr && !memcmp(vps1->hdr, vps2->hdr,
sizeof(*vps1->hdr {
I think this should be vps1->vps_num_hrd_parameters *
sizeof(*vps1->hdr), and done after the memcmp below to ensure
vps_num_hrd_parameters is the same value in both structs.
+return !memcmp(vps1, vps2, offsetof(HEVCVPS, hdr));
+}
+
+return 0;
+}
+
int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps)
{
@@ -545,9 +555,11 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
goto err;
}
-vps->hdr = av_calloc(vps->vps_num_hrd_parameters, sizeof(*vps->hdr));
-if (!vps->hdr)
-goto err;
+if (vps->vps_num_hrd_parameters) {
+vps->hdr = av_calloc(vps->vps_num_hrd_parameters,
sizeof(*vps->hdr));
+if (!vps->hdr)
+goto err;
+}
for (i = 0; i < vps->vps_num_hrd_parameters; i++) {
int common_inf_present = 1;
@@ -569,7 +581,7 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb,
AVCodecContext *avctx,
}
if (ps->vps_list[vps_id] &&
-!memcmp(ps->vps_list[vps_id], vps, sizeof(*vps))) {
+compare_vps(ps->vps_list[vps_id], vps)) {
ff_refstruct_unref();
} else {
remove_vps(ps, vps_id);
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index cc75aeb8d3..0d8eaf2b3e 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -153,7 +153,6 @@ typedef struct PTL {
typedef struct HEVCVPS {
unsigned int vps_id;
-HEVCHdrParams *hdr;
uint8_t vps_temporal_id_nesting_flag;
int vps_max_layers;
@@ -175,6 +174,9 @@ typedef struct HEVCVPS {
uint8_t data[4096];
int data_size;
+/* Put this at the end of the structure to make it easier to calculate the
+ * size before this pointer, which is used for memcmp */
+HEVCHdrParams *hdr;
} HEVCVPS;
typedef struct ScalingList {
___
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] doc/muxers: add ilbc
---
doc/muxers.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 450f72a73c..b8404c274c 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2563,6 +2563,11 @@ If a BMP image is used, it must use the BITMAPINFOHEADER
DIB header
If a PNG image is used, it must use the rgba pixel format
@end itemize
+@section ilbc
+Internet Low Bitrate Codec (iLBC) raw muxer.
+
+It accepts a single @samp{ilbc} audio stream.
+
@anchor{image2}
@section image2
Image file muxer.
--
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".
Re: [FFmpeg-devel] [PATCH 3/3] lavf/subtitles: Unfix ticket #5032
Here's an alternative solution which maintains support for \r\r\n by
peeking two bytes into the future.
/Tomas
From ed6f0b2e6c8e52574fcfdac73fcfca560434c079 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Thu, 28 Mar 2024 23:30:06 +0100
Subject: [PATCH] lavf/subtitles: Add ff_text_peek_r16(), accept \r, \n, \r\n
and \r\r\n line endings
---
libavformat/subtitles.c | 46 +
libavformat/subtitles.h | 5 +
2 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c
index bda549abd0..01187df6ab 100644
--- a/libavformat/subtitles.c
+++ b/libavformat/subtitles.c
@@ -22,6 +22,7 @@
#include "subtitles.h"
#include "avio_internal.h"
#include "libavutil/avstring.h"
+#include "libavutil/intreadwrite.h"
void ff_text_init_avio(void *s, FFTextReader *r, AVIOContext *pb)
{
@@ -106,6 +107,42 @@ int ff_text_peek_r8(FFTextReader *r)
return c;
}
+int ff_text_peek_r16(FFTextReader *r)
+{
+int c1, c2;
+if (r->buf_pos < r->buf_len - 1)
+return AV_RB16(>buf[r->buf_pos]);
+
+// missing one or two bytes
+c1 = ff_text_r8(r);
+if (avio_feof(r->pb))
+return 0;
+
+if (r->buf_pos == r->buf_len - 1) {
+// missing one byte
+r->buf[0] = r->buf[r->buf_pos];
+r->buf[1] = c1;
+r->buf_pos = 0;
+r->buf_len = 2;
+return AV_RB16(r->buf);
+}
+
+// missing two bytes
+c2 = ff_text_r8(r);
+if (avio_feof(r->pb)) {
+r->buf[0] = c1;
+r->buf_pos = 0;
+r->buf_len = 1;
+return 0;
+}
+
+r->buf[0] = c1;
+r->buf[1] = c2;
+r->buf_pos = 0;
+r->buf_len = 2;
+return AV_RB16(r->buf);
+}
+
AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue *q,
const uint8_t *event, size_t len, int merge)
{
@@ -459,13 +496,14 @@ ptrdiff_t ff_subtitles_read_line(FFTextReader *tr, char *buf, size_t size)
buf[cur++] = c;
buf[cur] = '\0';
}
-// don't eat \n\n
if (c == '\r') {
-// sub/ticket5032-rrn.srt has \r\r\n
-while (ff_text_peek_r8(tr) == '\r')
-ff_text_r8(tr);
if (ff_text_peek_r8(tr) == '\n')
ff_text_r8(tr);
+else if (ff_text_peek_r16(tr) == AV_RB16("\r\n")) {
+// ticket5032-rrn.srt has \r\r\n
+ff_text_r8(tr);
+ff_text_r8(tr);
+}
}
return cur;
}
diff --git a/libavformat/subtitles.h b/libavformat/subtitles.h
index 88665663c5..2a92044976 100644
--- a/libavformat/subtitles.h
+++ b/libavformat/subtitles.h
@@ -94,6 +94,11 @@ int ff_text_eof(FFTextReader *r);
*/
int ff_text_peek_r8(FFTextReader *r);
+/**
+ * Like ff_text_peek_r8(), but peek two bytes and return them as a big-endian number.
+ */
+int ff_text_peek_r16(FFTextReader *r);
+
/**
* Read the given number of bytes (in UTF-8). On error or EOF, \0 bytes are
* written.
--
2.39.2
___
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 v10 2/5] avformat/rcwtdec: add RCWT Closed Captions demuxer
> + /* demux */
> + while (!avio_feof(avf->pb)) {
Can we please get away from this way of reading subtitles? Every other
type of media (audio, video) are capable of being streamed, but not
subtitles, precisely because all of them do all parsing in the
read_header() call. We have a perfectly good generic index and seeking
functionality. My recent experiment with srt shows it's possible to
read packets in read_packet() like every other demuxer..
/Tomas
___
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] doc/muxers: add stub for iamf
---
doc/muxers.texi | 16
1 file changed, 16 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index f300f8c45f..23506e2ab7 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2515,6 +2515,22 @@ Ignore IO errors during open, write and delete. Useful
for long-duration runs wi
Set custom HTTP headers, can override built in default headers. Applicable
only for HTTP output.
@end table
+@section{iamf}
+
+Immersive Audio Model and Formats (IAMF) muxer.
+
+IAMF is used to provide immersive audio content for presentation on a wide
range
+of devices in both streaming and offline applications. These applications
+include internet audio streaming, multicasting/broadcasting services, file
+download, gaming, communication, virtual and augmented reality, and others. In
+these applications, audio may be played back on a wide range of devices, e.g.,
+headphones, mobile phones, tablets, TVs, sound bars, home theater systems, and
+big screens.
+
+This format was promoted and desgined by Alliance for Open Media.
+
+For more information about this format, see @url{https://aomedia.org/iamf/}.
+
@anchor{ico}
@section ico
--
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".
Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule
This is a reminder that I'm planning to end the vote on Monday morning. We have 17 votes so far, if you have not voted yet please do so ASAP. -- Anton Khirnov ___ 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] doc/muxers/hls: review, apply consistency fixes
Apply misc typo fixes, consistency fixes, and reformat the layout to provide
more overall
internal and global consistency.
---
doc/muxers.texi | 404 +++-
1 file changed, 225 insertions(+), 179 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index a10a8e216f..f300f8c45f 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1900,9 +1900,6 @@ flexible implementation of a segmenter, and can be used
to perform HLS
segmentation.
@subsection Options
-
-This muxer supports the following options:
-
@table @option
@item hls_init_time @var{duration}
Set the initial target segment length. Default value is @var{0}.
@@ -1910,9 +1907,9 @@ Set the initial target segment length. Default value is
@var{0}.
@var{duration} must be a time duration specification,
see @ref{time duration syntax,,the Time duration section in the
ffmpeg-utils(1) manual,ffmpeg-utils}.
-Segment will be cut on the next key frame after this time has passed on the
first m3u8 list.
-After the initial playlist is filled @command{ffmpeg} will cut segments
-at duration equal to @code{hls_time}
+Segment will be cut on the next key frame after this time has passed on the
+first m3u8 list. After the initial playlist is filled, @command{ffmpeg} will
cut
+segments at duration equal to @option{hls_time}.
@item hls_time @var{duration}
Set the target segment length. Default value is 2.
@@ -1929,12 +1926,12 @@ will contain all the segments. Default value is 5.
Set the number of unreferenced segments to keep on disk before @code{hls_flags
delete_segments}
deletes them. Increase this to allow continue clients to download segments
which
were recently referenced in the playlist. Default value is 1, meaning segments
older than
-@code{hls_list_size+1} will be deleted.
+@option{hls_list_size+1} will be deleted.
-@item hls_start_number_source
+@item hls_start_number_source @var{source}
Start the playlist sequence number (@code{#EXT-X-MEDIA-SEQUENCE}) according to
the specified source.
-Unless @code{hls_flags single_file} is set, it also specifies source of
starting sequence numbers of
-segment and subtitle filenames. In any case, if @code{hls_flags append_list}
+Unless @option{hls_flags single_file} is set, it also specifies source of
starting sequence numbers of
+segment and subtitle filenames. In any case, if @option{hls_flags append_list}
is set and read playlist sequence number is greater than the specified start
sequence number,
then that value will be used as start value.
@@ -1943,26 +1940,25 @@ It accepts the following values:
@table @option
@item generic (default)
-Set the starting sequence numbers according to @var{start_number} option value.
+Set the start numbers according to the @option{start_number} option value.
@item epoch
-The start number will be the seconds since epoch (1970-01-01 00:00:00)
+Set the start number as the seconds since epoch (1970-01-01 00:00:00).
@item epoch_us
-The start number will be the microseconds since epoch (1970-01-01 00:00:00)
+Set the start number as the microseconds since epoch (1970-01-01 00:00:00).
@item datetime
-The start number will be based on the current date/time as mmddHHMMSS.
e.g. 20161231235759.
-
+Set the start number based on the current date/time as mmddHHMMSS. e.g.
20161231235759.
@end table
@item start_number @var{number}
Start the playlist sequence number (@code{#EXT-X-MEDIA-SEQUENCE}) from the
specified @var{number}
-when @var{hls_start_number_source} value is @var{generic}. (This is the
default case.)
-Unless @code{hls_flags single_file} is set, it also specifies starting
sequence numbers of segment and subtitle filenames.
+when @option{hls_start_number_source} value is @var{generic}. (This is the
default case.)
+Unless @option{hls_flags single_file} is set, it also specifies starting
sequence numbers of segment and subtitle filenames.
Default value is 0.
-@item hls_allow_cache @var{allowcache}
+@item hls_allow_cache @var{bool}
Explicitly set whether the client MAY (1) or MUST NOT (0) cache media segments.
@item hls_base_url @var{baseurl}
@@ -1975,29 +1971,37 @@ which can be cyclic, for example if the @option{wrap}
option is
specified.
@item hls_segment_filename @var{filename}
-Set the segment filename. Unless @code{hls_flags single_file} is set,
-@var{filename} is used as a string format with the segment number:
+Set the segment filename. Unless the @option{hls_flags} option is set with
+@samp{single_file}, @var{filename} is used as a string format with the
+segment number appended.
+
+For example:
@example
ffmpeg -i in.nut -hls_segment_filename 'file%03d.ts' out.m3u8
@end example
-This example will produce the playlist, @file{out.m3u8}, and segment files:
+
+will produce the playlist, @file{out.m3u8}, and segment files:
@file{file000.ts}, @file{file001.ts}, @file{file002.ts}, etc.
-@var{filename} may contain full path or relative path specification,
-but only the
Re: [FFmpeg-devel] [PATCH v11 3/8] avcodec/bsf: Add awebp2webp bitstream filter
Am 28.03.24 um 19:11 schrieb Stefano Sabatini: On date Thursday 2024-03-28 15:08:53 +0100, ffmpeg-devel Mailing List wrote: Splits a packet containing a webp animations into one non-compliant packet per frame of the animation. Skips RIFF and WEBP chunks for those packets except for the first. Copyies ICC, EXIF and XMP chunks first into each of the packets except for the first. --- configure | 1 + libavcodec/bitstream_filters.c | 1 + libavcodec/bsf/Makefile| 1 + libavcodec/bsf/awebp2webp.c| 350 + 4 files changed, 353 insertions(+) create mode 100644 libavcodec/bsf/awebp2webp.c missing doc/bitstreams.texi update? also you might mention in the Changelog, assuming this might be directly used by users Yes, adding docs next iteration. Also micro bump for a new bsf? (I'll never get the rules of bumping...) It's yet a normal filter, Andreas wanted this to be non-public in the end, requiring some additional changes before. -Thilo ___ 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 v6] avformat/demux: Add duration_probesize AVOption
On date Friday 2024-03-29 10:26:19 +0100, Nicolas Gaullier wrote: > Yet another probesize used to get the durations when > estimate_timings_from_pts is required. It is aimed at users interested > in better durations probing for itself, or because using > avformat_find_stream_info indirectly and requiring exact values: for > concatdec for example, especially if streamcopying above it. > The current code is a performance trade-off that can fail to get video > stream durations in a scenario with high bitrates and buffering for > files ending cleanly (as opposed to live captures): the physical gap > between the last video packet and the last audio packet is very high in > such a case. > > Default behaviour is unchanged: 250k up to 250k << 6 (step by step). > Setting this new option has two effects: > - override the maximum probesize (currently 250k << 6) > - reduce the number of steps to 1 instead of 6, this is to avoid > detecting the audio "too early" and failing to reach a video packet. > Even if a single audio stream duration is found but not the other > audio/video stream durations, there will be a retry, so at the end the > full user-overriden probesize will be used as expected by the user. > > Signed-off-by: Nicolas Gaullier > --- > doc/APIchanges | 3 +++ > doc/formats.texi| 19 ++- > libavformat/avformat.h | 16 ++-- > libavformat/demux.c | 13 - > libavformat/options_table.h | 1 + > libavformat/version.h | 2 +- > 6 files changed, 45 insertions(+), 9 deletions(-) Looks good to me, will apply in a few days if there are no further comments. Thanks. ___ 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 v10 0/5] RCWT Closed Captions demuxer (v10)
On date Thursday 2024-03-28 15:11:27 -0500, Marth64 wrote: > Since v7/8: > * Addresses last known feedback (about av_assert call) > * Changelog entry removed, since v7.0 is cut and there is no "next" space yet > (will make patch once available) > > Signed-off-by: Marth64 Will apply soon if I see no more comments, thanks. ___ 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 v6] avformat/demux: Add duration_probesize AVOption
Yet another probesize used to get the durations when
estimate_timings_from_pts is required. It is aimed at users interested
in better durations probing for itself, or because using
avformat_find_stream_info indirectly and requiring exact values: for
concatdec for example, especially if streamcopying above it.
The current code is a performance trade-off that can fail to get video
stream durations in a scenario with high bitrates and buffering for
files ending cleanly (as opposed to live captures): the physical gap
between the last video packet and the last audio packet is very high in
such a case.
Default behaviour is unchanged: 250k up to 250k << 6 (step by step).
Setting this new option has two effects:
- override the maximum probesize (currently 250k << 6)
- reduce the number of steps to 1 instead of 6, this is to avoid
detecting the audio "too early" and failing to reach a video packet.
Even if a single audio stream duration is found but not the other
audio/video stream durations, there will be a retry, so at the end the
full user-overriden probesize will be used as expected by the user.
Signed-off-by: Nicolas Gaullier
---
doc/APIchanges | 3 +++
doc/formats.texi| 19 ++-
libavformat/avformat.h | 16 ++--
libavformat/demux.c | 13 -
libavformat/options_table.h | 1 +
libavformat/version.h | 2 +-
6 files changed, 45 insertions(+), 9 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index aa102b4925..e7677658b1 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
API changes, most recent first:
+2024-03-29 - xx - lavf 61.3.100 - avformat.h
+ Add AVFormatContext.duration_probesize.
+
2024-03-27 - xx - lavu 59.10.100 - frame.h
Add AVSideDataDescriptor, enum AVSideDataProps, and
av_frame_side_data_desc().
diff --git a/doc/formats.texi b/doc/formats.texi
index 69fc1457a4..876a9e92b3 100644
--- a/doc/formats.texi
+++ b/doc/formats.texi
@@ -225,9 +225,26 @@ Specifies the maximum number of streams. This can be used
to reject files that
would require too many resources due to a large number of streams.
@item skip_estimate_duration_from_pts @var{bool} (@emph{input})
-Skip estimation of input duration when calculated using PTS.
+Skip estimation of input duration if it requires an additional probing for PTS
at end of file.
At present, applicable for MPEG-PS and MPEG-TS.
+@item duration_probesize @var{integer} (@emph{input})
+Set probing size, in bytes, for input duration estimation when it actually
requires
+an additional probing for PTS at end of file (at present: MPEG-PS and MPEG-TS).
+It is aimed at users interested in better durations probing for itself, or
indirectly
+because using the concat demuxer, for example.
+The typical use case is an MPEG-TS CBR with a high bitrate, high video
buffering and
+ending cleaning with similar PTS for video and audio: in such a scenario, the
large
+physical gap between the last video packet and the last audio packet makes it
necessary
+to read many bytes in order to get the video stream duration.
+Another use case is where the default probing behaviour only reaches a single
video frame which is
+not the last one of the stream due to frame reordering, so the duration is not
accurate.
+Setting this option has a performance impact even for small files because the
probing
+size is fixed.
+Default behaviour is a general purpose trade-off, largely adaptive, but the
probing size
+will not be extended to get streams durations at all costs.
+Must be an integer not lesser than 1, or 0 for default behaviour.
+
@item strict, f_strict @var{integer} (@emph{input/output})
Specify how strictly to follow the standards. @code{f_strict} is deprecated and
should be used only via the @command{ffmpeg} tool.
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index de40397676..8afdcd9fd0 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1439,7 +1439,7 @@ typedef struct AVFormatContext {
*
* @note this is \e not used for determining the \ref AVInputFormat
* "input format"
- * @sa format_probesize
+ * @see format_probesize
*/
int64_t probesize;
@@ -1667,6 +1667,8 @@ typedef struct AVFormatContext {
* Skip duration calcuation in estimate_timings_from_pts.
* - encoding: unused
* - decoding: set by user
+ *
+ * @see duration_probesize
*/
int skip_estimate_duration_from_pts;
@@ -1729,7 +1731,7 @@ typedef struct AVFormatContext {
*
* Demuxing only, set by the caller before avformat_open_input().
*
- * @sa probesize
+ * @see probesize
*/
int format_probesize;
@@ -1870,6 +1872,16 @@ typedef struct AVFormatContext {
* @return 0 on success, a negative AVERROR code on failure
*/
int (*io_close2)(struct AVFormatContext *s,
Re: [FFmpeg-devel] [PATCH] lavf/movenc: mark mov/mp4 as supporting VFR
Quoting Gyan Doshi (2024-03-29 10:19:15) > LGTM. Should have been done a long time ago. > What about the other muxers in movenc? I don't know what they are used for or what constraints they have, so I left them alone for now. Can also change them if people see no problem with it. -- Anton Khirnov ___ 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] lavf/movenc: mark mov/mp4 as supporting VFR
On 2024-03-29 02:05 pm, Anton Khirnov wrote:
---
libavformat/movenc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index b97c479cc4..30cfbf6e74 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -8230,11 +8230,11 @@ const FFOutputFormat ff_mov_muxer = {
.write_packet = mov_write_packet,
.write_trailer = mov_write_trailer,
.deinit= mov_free,
+.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE |
AVFMT_VARIABLE_FPS
#if FF_API_ALLOW_FLUSH
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH |
AVFMT_TS_NEGATIVE,
-#else
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE,
+ | AVFMT_ALLOW_FLUSH
#endif
+ ,
.p.codec_tag = (const AVCodecTag* const []){
ff_codec_movvideo_tags, ff_codec_movaudio_tags,
ff_codec_movsubtitle_tags, 0
},
@@ -8282,11 +8282,11 @@ const FFOutputFormat ff_mp4_muxer = {
.write_packet = mov_write_packet,
.write_trailer = mov_write_trailer,
.deinit= mov_free,
+.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE |
AVFMT_VARIABLE_FPS
#if FF_API_ALLOW_FLUSH
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH |
AVFMT_TS_NEGATIVE,
-#else
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE,
+ | AVFMT_ALLOW_FLUSH
#endif
+ ,
.p.codec_tag = mp4_codec_tags_list,
.check_bitstream = mov_check_bitstream,
.p.priv_class = _isobmff_muxer_class,
LGTM. Should have been done a long time ago.
What about the other muxers in movenc?
Regards,
Gyan
___
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/2] libavformat/hls.c: support in-stream ID3 metadata update.
> 在 2024年3月29日，06:51，Romain Beauxis 写道：
>
> On Mon, Mar 25, 2024, 19:58 Romain Beauxis wrote:
>
>> 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.
>>
>
>
> Hello!
>
> Any interest in reviewing this?
Let me test these patchset need some days, Thanks
>
>
> ---
>> libavformat/hls.c | 54 ---
>> 1 file changed, 32 insertions(+), 22 deletions(-)
>>
>> diff --git a/libavformat/hls.c b/libavformat/hls.c
>> index f6b44c2e35..ba6634d57a 100644
>> --- a/libavformat/hls.c
>> +++ b/libavformat/hls.c
>> @@ -93,6 +93,12 @@ enum PlaylistType {
>> PLS_TYPE_VOD
>> };
>>
>> +#define ID3_PRIV_OWNER_TS "com.apple.streaming.transportStreamTimestamp"
>> +#define ID3_PRIV_OWNER_AUDIO_SETUP "com.apple.streaming.audioDescription"
>> +
>> +#define ID3v2_PRIV_OWNER_TS ID3v2_PRIV_METADATA_PREFIX ID3_PRIV_OWNER_TS
>> +#define ID3v2_PRIV_OWNER_AUDIO_SETUP ID3v2_PRIV_METADATA_PREFIX
>> ID3_PRIV_OWNER_AUDIO_SETUP
>> +
>> /*
>> * Each playlist has its own demuxer. If it currently is active,
>> * it has an open AVIOContext too, and potentially an AVPacket
>> @@ -150,9 +156,7 @@ struct playlist {
>> int64_t id3_offset; /* in stream original tb */
>> uint8_t* id3_buf; /* temp buffer for id3 parsing */
>> unsigned int id3_buf_size;
>> -AVDictionary *id3_initial; /* data from first id3 tag */
>> -int id3_found; /* ID3 tag found at some point */
>> -int id3_changed; /* ID3 tag data has changed at some point */
>> +AVDictionary *last_id3; /* data from the last id3 tag */
>> ID3v2ExtraMeta *id3_deferred_extra; /* stored here until subdemuxer
>> is opened */
>>
>> HLSAudioSetupInfo audio_setup_info;
>> @@ -270,7 +274,7 @@ static void free_playlist_list(HLSContext *c)
>> av_freep(>main_streams);
>> av_freep(>renditions);
>> av_freep(>id3_buf);
>> -av_dict_free(>id3_initial);
>> +av_dict_free(>last_id3);
>> ff_id3v2_free_extra_meta(>id3_deferred_extra);
>> av_freep(>init_sec_buf);
>> av_packet_free(>pkt);
>> @@ -1083,15 +1087,13 @@ static void parse_id3(AVFormatContext *s,
>> AVIOContext *pb,
>> AVDictionary **metadata, int64_t *dts,
>> HLSAudioSetupInfo *audio_setup_info,
>> ID3v2ExtraMetaAPIC **apic, ID3v2ExtraMeta
>> **extra_meta)
>> {
>> -static const char id3_priv_owner_ts[] =
>> "com.apple.streaming.transportStreamTimestamp";
>> -static const char id3_priv_owner_audio_setup[] =
>> "com.apple.streaming.audioDescription";
>> ID3v2ExtraMeta *meta;
>>
>> ff_id3v2_read_dict(pb, metadata, ID3v2_DEFAULT_MAGIC, extra_meta);
>> for (meta = *extra_meta; meta; meta = meta->next) {
>> if (!strcmp(meta->tag, "PRIV")) {
>> ID3v2ExtraMetaPRIV *priv = >data.priv;
>> -if (priv->datasize == 8 && !av_strncasecmp(priv->owner,
>> id3_priv_owner_ts, 44)) {
>> +if (priv->datasize == 8 && !av_strncasecmp(priv->owner,
>> ID3_PRIV_OWNER_TS, strlen(ID3_PRIV_OWNER_TS))) {
>> /* 33-bit MPEG timestamp */
>> int64_t ts = AV_RB64(priv->data);
>> av_log(s, AV_LOG_DEBUG, "HLS ID3 audio timestamp
>> %"PRId64"\n", ts);
>> @@ -1099,7 +1101,9 @@ static void parse_id3(AVFormatContext *s,
>> AVIOContext *pb,
>> *dts = ts;
>> else
>> av_log(s, AV_LOG_ERROR, "Invalid HLS ID3 audio
>> timestamp %"PRId64"\n", ts);
>> -} else if (priv->datasize >= 8 &&
>> !av_strncasecmp(priv->owner, id3_priv_owner_audio_setup, 36)) {
>> +} else if (priv->datasize >= 8 &&
>> + !av_strncasecmp(priv->owner,
>> ID3_PRIV_OWNER_AUDIO_SETUP, 36) &&
>> + audio_setup_info) {
>> ff_hls_senc_read_audio_setup_info(audio_setup_info,
>> priv->data, priv->datasize);
>> }
>> } else if (!strcmp(meta->tag, "APIC") && apic)
>> @@ -1113,9 +1117,10 @@ static int id3_has_changed_values(struct playlist
>> *pls, AVDictionary *metadata,
>> {
>> const AVDictionaryEntry *entry = NULL;
>> const AVDictionaryEntry *oldentry;
>> +
>> /* check that no keys have changed values */
>> while ((entry = av_dict_iterate(metadata, entry))) {
>> -oldentry = av_dict_get(pls->id3_initial, entry->key, NULL,
>> AV_DICT_MATCH_CASE);
>> +oldentry = av_dict_get(pls->last_id3, entry->key, NULL,
>> AV_DICT_MATCH_CASE);
>> if (!oldentry || strcmp(oldentry->value, entry->value) != 0)
>> return 1;
>> }
>> @@ -1143,35 +1148,40 @@ static void handle_id3(AVIOContext *pb, struct
>> playlist *pls)
>> ID3v2ExtraMetaAPIC *apic = NULL;
>> ID3v2ExtraMeta *extra_meta = NULL;
>> int64_t timestamp = AV_NOPTS_VALUE;
>>
[FFmpeg-devel] [PATCH] lavf/movenc: mark mov/mp4 as supporting VFR
---
libavformat/movenc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index b97c479cc4..30cfbf6e74 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -8230,11 +8230,11 @@ const FFOutputFormat ff_mov_muxer = {
.write_packet = mov_write_packet,
.write_trailer = mov_write_trailer,
.deinit= mov_free,
+.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE |
AVFMT_VARIABLE_FPS
#if FF_API_ALLOW_FLUSH
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH |
AVFMT_TS_NEGATIVE,
-#else
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE,
+ | AVFMT_ALLOW_FLUSH
#endif
+ ,
.p.codec_tag = (const AVCodecTag* const []){
ff_codec_movvideo_tags, ff_codec_movaudio_tags,
ff_codec_movsubtitle_tags, 0
},
@@ -8282,11 +8282,11 @@ const FFOutputFormat ff_mp4_muxer = {
.write_packet = mov_write_packet,
.write_trailer = mov_write_trailer,
.deinit= mov_free,
+.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE |
AVFMT_VARIABLE_FPS
#if FF_API_ALLOW_FLUSH
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_ALLOW_FLUSH |
AVFMT_TS_NEGATIVE,
-#else
-.p.flags = AVFMT_GLOBALHEADER | AVFMT_TS_NEGATIVE,
+ | AVFMT_ALLOW_FLUSH
#endif
+ ,
.p.codec_tag = mp4_codec_tags_list,
.check_bitstream = mov_check_bitstream,
.p.priv_class = _isobmff_muxer_class,
--
2.43.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".
[FFmpeg-devel] [PATCH v2] lavc/libopenh264: Check for noopenh264
noopenh264 is a "fake implementation of the OpenH264 library we can link
from regardless of the actual library being available":
https://gitlab.com/freedesktop-sdk/noopenh264
A distributor may wish to link against openh264/noopenh264 and let
the decoder and encoder work only if the actual library is available.
On the other hand, an application may want to know if the decoder or
encoder is available beforehand so that it can determine what format to
download for decoding, or what format to advertise for the peer
receiving the encoded video.
Check the availability of the actual library at runtime initialization
and do not expose the encoder and decoder if they are not available.
The availability check is done by calling WelsCreateDecoder() or
WelsCreateSVCEncoder(). These functions do not perform initialization
tasks other than allocating objects and assigning function pointers;
these tasks are performed by calling the Initialize() function pointer
member of the object these functions return. By *not* calling
Initialize(), we can ensure that potentially expensive and failable
initialization tasks are not unconditionally performed and avoid
preparing decoding/encoding parameters it requires.
Signed-off-by: Akihiko Odaki
---
Changes in v2:
- Changed to filter codecs with av_codec_iterate().
- Clarified potentially expensive and failable initialization tasks are
not performed by WelsCreateDecoder() or WelsCreateSVCEncoder() but by
the Initialize() function pointer member of what they return.
- Link to v1:
https://lore.kernel.org/r/20240211-noopenh264-v1-1-e18090bdc...@gmail.com
---
libavcodec/allcodecs.c | 5 +
libavcodec/codec_internal.h | 4
libavcodec/libopenh264dec.c | 14 +-
libavcodec/libopenh264enc.c | 14 +-
4 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 2386b450a6..73dd4ebd52 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -924,6 +924,11 @@ const AVCodec *av_codec_iterate(void **opaque)
uintptr_t i = (uintptr_t)*opaque;
const FFCodec *c = codec_list[i];
+while (c && (c->caps_internal & FF_CODEC_CAP_DISABLED)) {
+i++;
+c = codec_list[i];
+}
+
ff_thread_once(_codec_static_init, av_codec_init_static);
if (c) {
diff --git a/libavcodec/codec_internal.h b/libavcodec/codec_internal.h
index d6757e2def..a7f833af72 100644
--- a/libavcodec/codec_internal.h
+++ b/libavcodec/codec_internal.h
@@ -88,6 +88,10 @@
* encoders do.
*/
#define FF_CODEC_CAP_EOF_FLUSH (1 << 10)
+/**
+ * Codec was disabled at runtime.
+ */
+#define FF_CODEC_CAP_DISABLED (1 << 11)
/**
* FFCodec.codec_tags termination value
diff --git a/libavcodec/libopenh264dec.c b/libavcodec/libopenh264dec.c
index b6a9bba2dc..8778f490bf 100644
--- a/libavcodec/libopenh264dec.c
+++ b/libavcodec/libopenh264dec.c
@@ -48,6 +48,17 @@ static av_cold int svc_decode_close(AVCodecContext *avctx)
return 0;
}
+static av_cold void svc_decode_init_static_data(FFCodec *codec)
+{
+ISVCDecoder *decoder;
+
+if (WelsCreateDecoder()) {
+codec->caps_internal |= FF_CODEC_CAP_DISABLED;
+} else {
+WelsDestroyDecoder(decoder);
+}
+}
+
static av_cold int svc_decode_init(AVCodecContext *avctx)
{
SVCContext *s = avctx->priv_data;
@@ -153,12 +164,13 @@ static int svc_decode_frame(AVCodecContext *avctx,
AVFrame *avframe,
return avpkt->size;
}
-const FFCodec ff_libopenh264_decoder = {
+FFCodec ff_libopenh264_decoder = {
.p.name = "libopenh264",
CODEC_LONG_NAME("OpenH264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10"),
.p.type = AVMEDIA_TYPE_VIDEO,
.p.id = AV_CODEC_ID_H264,
.priv_data_size = sizeof(SVCContext),
+.init_static_data = svc_decode_init_static_data,
.init = svc_decode_init,
FF_CODEC_DECODE_CB(svc_decode_frame),
.close = svc_decode_close,
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index eef769eed0..6203d1176e 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -106,6 +106,17 @@ static av_cold int svc_encode_close(AVCodecContext *avctx)
return 0;
}
+static av_cold void svc_encode_init_static_data(FFCodec *codec)
+{
+ISVCEncoder *encoder;
+
+if (WelsCreateSVCEncoder()) {
+codec->caps_internal |= FF_CODEC_CAP_DISABLED;
+} else {
+WelsDestroySVCEncoder(encoder);
+}
+}
+
static av_cold int svc_encode_init(AVCodecContext *avctx)
{
SVCContext *s = avctx->priv_data;
@@ -429,7 +440,7 @@ static const FFCodecDefault svc_enc_defaults[] = {
{ NULL },
};
-const FFCodec ff_libopenh264_encoder = {
+FFCodec ff_libopenh264_encoder = {
.p.name = "libopenh264",
CODEC_LONG_NAME("OpenH264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10"),
.p.type = AVMEDIA_TYPE_VIDEO,
@@ -437,6 +448,7 @@ const FFCodec
