Re: [FFmpeg-devel] [PATCH] avutil/thread: fix pthread_setname_np parameters for NetBSD and Apple
Can confirm this fixes the build on my Mac. -- Connor Worley ___ 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] avutil/thread: fix pthread_setname_np parameters for NetBSD and Apple
On Mon, 5 Feb 2024, Connor Worley wrote: Can confirm this fixes the build on my Mac. Thanks, will apply. Regards, Marton -- Connor Worley ___ 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] Sovereign Tech Fund
On Wed, Jan 31, 2024 at 09:55:00PM +, Kieran Kunhya wrote: > On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis > wrote: > > > On 1/30/2024 1:48 AM, Michael Niedermayer wrote: > > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 > > > > Not to derail this fine thread, but what forks does the Merge Forks > > project refer to? > > > > - Derek > > > > I also added a note that 70 USD for coverity is way too much. I picked a > random issue 1503073 and within a minute saw that it was a false positive. > I don't deserve 70USD for that. I fixed 2 coverity issues yesterday and it took me over 3 hours I cant do this for 70USD per issue (you can see the ML for the 2 patches) In the first, the issue depended on fbw_channels to be 0. If you look at its initialization that is possible if you have a mono LFE channel but is that possible and can the code be reached in that case. For someone who hasnt worked at that specific code it takes some time to build an argument that this should not be possible The second issue, its obvious a bug but how do we even reach that code? No fate tests luckily there are examples in the docs but it took me several tries to get the code to execute with similar testcases. now looking at it, i suspect the patch i posted probably should be split so we need a 2nd iteration and looking at the clock when i posted this and when i started yesterday fact is it was 3-4h work for these 2 issues did i pick these randomly? no, i started frm the top and skiped a few i really did not want to work on like the flac parser. Some coverity isssues are dead easy and need seconds to categorize or even fix. But for others its difficult Also to categorize coverity issues one needs to understand the affectd code. coverity telling you that after 355 conditions theres a out of array access, you need to know if the 355 conditions are inconsistant and contradicting. If they contradict its a false positive otherwise its a bug. similar when you check the return code of a function most of the time coverity will create an issue for cases where its not checked. Thats trivial to fix IF you know the code. But IF you do not know the code that can some decent time too. And i think noone knows all code. Either way, iam interrested in helping with coverity work while at the same time this environment where peole finger point and say "is way too much" is something i dont feel comfortable to work in. maybe doing it per hour instead of per issue is a safer way thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle 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/2] avfilter/signature_lookup: Do not dereference NULL pointers after malloc failure
Michael Niedermayer:
> Fixes: CID 1403229 Dereference after null check
>
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/signature_lookup.c | 25 ++---
> 1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
> index 86dd0c66754..6e45fde1b5a 100644
> --- a/libavfilter/signature_lookup.c
> +++ b/libavfilter/signature_lookup.c
> @@ -37,6 +37,14 @@
> #define STATUS_END_REACHED 1
> #define STATUS_BEGIN_REACHED 2
>
> +static void sll_free(MatchingInfo **sll)
> +{
> +while (*sll) {
> +sll = &(*sll)->next;
> +av_freep(sll);
> +}
> +}
> +
This will leak every element except the second (if existing) of the
linked list.
> static void fill_l1distlut(uint8_t lut[])
> {
> int i, j, tmp_i, tmp_j,count;
> @@ -290,6 +298,10 @@ static MatchingInfo*
> get_matching_parameters(AVFilterContext *ctx, SignatureCont
> av_log(ctx, AV_LOG_FATAL, "Could not allocate
> memory");
> c = c->next;
> }
> +if (!c) {
> +sll_free(&cands);
> +goto error;
> +}
> c->framerateratio = (i+1.0) / 30;
> c->score = hspace[i][j].score;
> c->offset = j-90;
> @@ -305,6 +317,7 @@ static MatchingInfo*
> get_matching_parameters(AVFilterContext *ctx, SignatureCont
> }
> }
> }
> +error:
> for (i = 0; i < MAX_FRAMERATE; i++) {
> av_freep(&hspace[i]);
> }
> @@ -520,16 +533,6 @@ static MatchingInfo evaluate_parameters(AVFilterContext
> *ctx, SignatureContext *
> return bestmatch;
> }
>
> -static void sll_free(MatchingInfo *sll)
> -{
> -void *tmp;
> -while (sll) {
> -tmp = sll;
> -sll = sll->next;
> -av_freep(&tmp);
> -}
> -}
> -
> static MatchingInfo lookup_signatures(AVFilterContext *ctx, SignatureContext
> *sc, StreamContext *first, StreamContext *second, int mode)
> {
> CoarseSignature *cs, *cs2;
> @@ -572,7 +575,7 @@ static MatchingInfo lookup_signatures(AVFilterContext
> *ctx, SignatureContext *sc
> "ratio %f, offset %d, score %d, %d frames matching\n",
> bestmatch.first->index, bestmatch.second->index,
> bestmatch.framerateratio, bestmatch.offset,
> bestmatch.score, bestmatch.matchframes);
> -sll_free(infos);
> +sll_free(&infos);
> }
> } while (find_next_coarsecandidate(sc, second->coarsesiglist, &cs, &cs2,
> 0) && !bestmatch.whole);
> return bestmatch;
___
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/2] avfilter/signature_lookup: Do not dereference NULL pointers after malloc failure
On Mon, Feb 05, 2024 at 11:35:54AM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: CID 1403229 Dereference after null check
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavfilter/signature_lookup.c | 25 ++---
> > 1 file changed, 14 insertions(+), 11 deletions(-)
> >
> > diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
> > index 86dd0c66754..6e45fde1b5a 100644
> > --- a/libavfilter/signature_lookup.c
> > +++ b/libavfilter/signature_lookup.c
> > @@ -37,6 +37,14 @@
> > #define STATUS_END_REACHED 1
> > #define STATUS_BEGIN_REACHED 2
> >
> > +static void sll_free(MatchingInfo **sll)
> > +{
> > +while (*sll) {
> > +sll = &(*sll)->next;
> > +av_freep(sll);
> > +}
> > +}
> > +
>
> This will leak every element except the second (if existing) of the
> linked list.
ill post a better and split patch
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
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] avfilter/signature_lookup: dont leave uncleared pointers in sll_free()
Signed-off-by: Michael Niedermayer
---
libavfilter/signature_lookup.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index 86dd0c66754..52a97e1bc7e 100644
--- a/libavfilter/signature_lookup.c
+++ b/libavfilter/signature_lookup.c
@@ -37,6 +37,15 @@
#define STATUS_END_REACHED 1
#define STATUS_BEGIN_REACHED 2
+static void sll_free(MatchingInfo **sll)
+{
+while (*sll) {
+MatchingInfo *tmp = *sll;
+*sll = (*sll)->next;
+av_free(tmp);
+}
+}
+
static void fill_l1distlut(uint8_t lut[])
{
int i, j, tmp_i, tmp_j,count;
@@ -520,16 +529,6 @@ static MatchingInfo evaluate_parameters(AVFilterContext
*ctx, SignatureContext *
return bestmatch;
}
-static void sll_free(MatchingInfo *sll)
-{
-void *tmp;
-while (sll) {
-tmp = sll;
-sll = sll->next;
-av_freep(&tmp);
-}
-}
-
static MatchingInfo lookup_signatures(AVFilterContext *ctx, SignatureContext
*sc, StreamContext *first, StreamContext *second, int mode)
{
CoarseSignature *cs, *cs2;
@@ -572,7 +571,7 @@ static MatchingInfo lookup_signatures(AVFilterContext *ctx,
SignatureContext *sc
"ratio %f, offset %d, score %d, %d frames matching\n",
bestmatch.first->index, bestmatch.second->index,
bestmatch.framerateratio, bestmatch.offset,
bestmatch.score, bestmatch.matchframes);
-sll_free(infos);
+sll_free(&infos);
}
} while (find_next_coarsecandidate(sc, second->coarsesiglist, &cs, &cs2,
0) && !bestmatch.whole);
return bestmatch;
--
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/2] avfilter/signature_lookup: Do not dereference NULL pointers after malloc failure
Fixes: CID 1403229 Dereference after null check
Signed-off-by: Michael Niedermayer
---
libavfilter/signature_lookup.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index 52a97e1bc7e..0c724456e24 100644
--- a/libavfilter/signature_lookup.c
+++ b/libavfilter/signature_lookup.c
@@ -298,6 +298,11 @@ static MatchingInfo*
get_matching_parameters(AVFilterContext *ctx, SignatureCont
if (!c->next)
av_log(ctx, AV_LOG_FATAL, "Could not allocate
memory");
c = c->next;
+
+}
+if (!c) {
+sll_free(&cands);
+goto error;
}
c->framerateratio = (i+1.0) / 30;
c->score = hspace[i][j].score;
@@ -314,6 +319,7 @@ static MatchingInfo*
get_matching_parameters(AVFilterContext *ctx, SignatureCont
}
}
}
+error:
for (i = 0; i < MAX_FRAMERATE; i++) {
av_freep(&hspace[i]);
}
--
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] avfilter/signature_lookup: dont leave uncleared pointers in sll_free()
Michael Niedermayer:
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/signature_lookup.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
> index 86dd0c66754..52a97e1bc7e 100644
> --- a/libavfilter/signature_lookup.c
> +++ b/libavfilter/signature_lookup.c
> @@ -37,6 +37,15 @@
> #define STATUS_END_REACHED 1
> #define STATUS_BEGIN_REACHED 2
>
> +static void sll_free(MatchingInfo **sll)
> +{
> +while (*sll) {
> +MatchingInfo *tmp = *sll;
> +*sll = (*sll)->next;
> +av_free(tmp);
> +}
This does not clear the pointers at all. This does (and avoids
indirections).
static void sll_free(MatchingInfo **sllp)
{
MatchingInfo *sll = *sllp;
*sllp = NULL;
while (sll) {
MatchingInfo *tmp = sll;
sll = sll->next;
av_free(tmp);
}
}
> +}
> +
> static void fill_l1distlut(uint8_t lut[])
> {
> int i, j, tmp_i, tmp_j,count;
> @@ -520,16 +529,6 @@ static MatchingInfo evaluate_parameters(AVFilterContext
> *ctx, SignatureContext *
> return bestmatch;
> }
>
> -static void sll_free(MatchingInfo *sll)
> -{
> -void *tmp;
> -while (sll) {
> -tmp = sll;
> -sll = sll->next;
> -av_freep(&tmp);
> -}
> -}
> -
> static MatchingInfo lookup_signatures(AVFilterContext *ctx, SignatureContext
> *sc, StreamContext *first, StreamContext *second, int mode)
> {
> CoarseSignature *cs, *cs2;
> @@ -572,7 +571,7 @@ static MatchingInfo lookup_signatures(AVFilterContext
> *ctx, SignatureContext *sc
> "ratio %f, offset %d, score %d, %d frames matching\n",
> bestmatch.first->index, bestmatch.second->index,
> bestmatch.framerateratio, bestmatch.offset,
> bestmatch.score, bestmatch.matchframes);
> -sll_free(infos);
> +sll_free(&infos);
> }
> } while (find_next_coarsecandidate(sc, second->coarsesiglist, &cs, &cs2,
> 0) && !bestmatch.whole);
> return bestmatch;
___
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] Sovereign Tech Fund
> Either way, iam interrested in helping with coverity work while > at the same time this environment where peole finger point and say > "is way too much" is something i dont feel comfortable to work in. > So you make an RFC but you only want comments that agree with you? > maybe doing it per hour instead of per issue is a safer way > I see the penny is finally starting to drop. Kieran ___ 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] avcodec/audiotoolboxenc: Ensure frame_size isn't zero
From: Zhao Zhili
---
libavcodec/audiotoolboxenc.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 35dd4c553d..08cd3d5d27 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -92,7 +92,7 @@ static UInt32 ffat_get_format_id(enum AVCodecID codec, int
profile)
}
}
-static void ffat_update_ctx(AVCodecContext *avctx)
+static int ffat_update_ctx(AVCodecContext *avctx)
{
ATDecodeContext *at = avctx->priv_data;
UInt32 size = sizeof(unsigned);
@@ -118,10 +118,20 @@ static void ffat_update_ctx(AVCodecContext *avctx)
if (!AudioConverterGetProperty(at->converter,
kAudioConverterCurrentOutputStreamDescription,
&size, &out_format)) {
-if (out_format.mFramesPerPacket)
+if (out_format.mFramesPerPacket) {
avctx->frame_size = out_format.mFramesPerPacket;
+} else {
+// Looks like it means for decoding. There is no known case that
+// mFramesPerPacket is zero for encoding. Use a default value for
+// safety.
+avctx->frame_size = 1024;
+av_log(avctx, AV_LOG_WARNING, "Missing mFramesPerPacket\n");
+}
if (out_format.mBytesPerPacket && avctx->codec_id == AV_CODEC_ID_ILBC)
avctx->block_align = out_format.mBytesPerPacket;
+} else {
+av_log(avctx, AV_LOG_ERROR, "Get OutputStreamDescription failed\n");
+return AVERROR_EXTERNAL;
}
at->frame_size = avctx->frame_size;
@@ -130,6 +140,8 @@ static void ffat_update_ctx(AVCodecContext *avctx)
at->pkt_size *= 1024;
avctx->frame_size *= 1024;
}
+
+return 0;
}
static int read_descr(GetByteContext *gb, int *tag)
@@ -236,6 +248,7 @@ static av_cold int ffat_init_encoder(AVCodecContext *avctx)
{
ATDecodeContext *at = avctx->priv_data;
OSStatus status;
+int ret;
AudioStreamBasicDescription in_format = {
.mSampleRate = avctx->sample_rate,
@@ -432,7 +445,9 @@ static av_cold int ffat_init_encoder(AVCodecContext *avctx)
}
}
-ffat_update_ctx(avctx);
+ret = ffat_update_ctx(avctx);
+if (ret < 0)
+return ret;
#if !TARGET_OS_IPHONE && defined(__MAC_10_9)
if (at->mode == kAudioCodecBitRateControlMode_Variable &&
avctx->rc_max_rate) {
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/audiotoolboxenc: remove CAP_VARIABLE_FRAME_SIZE from alac
From: Zhao Zhili
AV_CODEC_CAP_VARIABLE_FRAME_SIZE has been set for alac_at encoder,
which means avctx->frame_size should be zero. However, alac_at
encoder also set avctx->frame_size. This leading to assert failure
in ffmpeg_sched.c
av_assert0(enc->sq_idx[0] >= 0);
Actually, the implementation of audiotoolboxenc.c doesn't support
frame_size been zero.
Fix #10720.
---
libavcodec/audiotoolboxenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 42ab7ae6e4..35dd4c553d 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -676,7 +676,7 @@ static const uint64_t aac_at_channel_layouts[] = {
FFAT_ENC(aac, AV_CODEC_ID_AAC, aac_profiles, ,
aac_at_channel_layouts, aac_at_ch_layouts)
//FFAT_ENC(adpcm_ima_qt, AV_CODEC_ID_ADPCM_IMA_QT, NULL)
-FFAT_ENC(alac, AV_CODEC_ID_ALAC, NULL, |
AV_CODEC_CAP_VARIABLE_FRAME_SIZE, NULL, NULL)
+FFAT_ENC(alac, AV_CODEC_ID_ALAC, NULL, , NULL, NULL)
FFAT_ENC(ilbc, AV_CODEC_ID_ILBC, NULL, , NULL, NULL)
FFAT_ENC(pcm_alaw, AV_CODEC_ID_PCM_ALAW, NULL, , NULL, NULL)
FFAT_ENC(pcm_mulaw,AV_CODEC_ID_PCM_MULAW,NULL, , NULL, NULL)
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavu/hashtable: create generic robin hood hash table
Connor Worley:
> Signed-off-by: Connor Worley
> ---
> libavutil/Makefile | 2 +
> libavutil/hashtable.c | 172
> libavutil/hashtable.h | 62 +
> libavutil/tests/hashtable.c | 104 ++
> 4 files changed, 340 insertions(+)
> create mode 100644 libavutil/hashtable.c
> create mode 100644 libavutil/hashtable.h
> create mode 100644 libavutil/tests/hashtable.c
>
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index e7709b97d0..be75d464fc 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -138,6 +138,7 @@ OBJS = adler32.o
> \
> fixed_dsp.o \
> frame.o \
> hash.o \
> + hashtable.o \
> hdr_dynamic_metadata.o \
> hdr_dynamic_vivid_metadata.o \
> hmac.o \
> @@ -251,6 +252,7 @@ TESTPROGS = adler32
> \
> file\
> fifo\
> hash\
> +hashtable \
> hmac\
> hwdevice\
> integer \
> diff --git a/libavutil/hashtable.c b/libavutil/hashtable.c
> new file mode 100644
> index 00..fb0f0aae99
> --- /dev/null
> +++ b/libavutil/hashtable.c
> @@ -0,0 +1,172 @@
> +/*
> + * Generic hashtable
> + * Copyright (C) 2024 Connor Worley
> + *
> + * 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
> + */
> +
> +#include
> +
> +#include "error.h"
> +#include "mem.h"
> +#include "hashtable.h"
> +#include "string.h"
We don't have a string.h header; the string.h from the C stdlib should
of course be included via <>.
> +
> +#define ENTRY_OCC(entry) (entry)
> +#define ENTRY_KEY(entry) (ENTRY_OCC(entry) + 1)
> +#define ENTRY_VAL(entry) (ENTRY_KEY(entry) + ctx->key_size)
> +#define ENTRY_PSL(entry) (size_t*) (ENTRY_VAL(entry) + ctx->val_size)
Unaligned access. You need to align entry_size to the required alignment
of size_t and put this at the start of it the entry to avoid this.
Apart from that: The layout of your entries implies that only two
members are at a fixed offset from the start, so that accessing val and
psl requires actual additions. If you make it psl, occ, key, val, then
only val has a variable offset. This should be beneficial given that it
is the less accessed of key and val (in particular if you combine
several memcpy calls as I outline below).
(This is of course a good reason not to make the layout of the entries
public.)
> +
> +#define KEYS_EQUAL(k1, k2) !memcmp(k1, k2, ctx->key_size)
> +
> +int av_hashtable_init(AVHashtableContext* ctx, size_t key_size, size_t
> val_size, size_t max_entries)
> +{
> +ctx->key_size = key_size;
> +ctx->val_size = val_size;
> +ctx->entry_size = 1 + key_size + val_size + sizeof(size_t);
> +ctx->max_entries = max_entries;
> +ctx->utilization = 0;
> +ctx->crc = av_crc_get_table(AV_CRC_32_IEEE);
> +if (!ctx->crc)
> +return AVERROR_BUG;
> +ctx->table = av_mallocz(ctx->entry_size * max_entries);
av_calloc()
> +if (!ctx->table)
> +return AVERROR(ENOMEM);
> +ctx->set_key = av_malloc(key_size);
> +if (!ctx->set_key)
> +return AVERROR(ENOMEM);
> +ctx->set_val = av_malloc(key_size);
Should be val_size. Your test should test scenarios with key_size !=
val_size to uncover this.
> +if (!ctx->set_val)
> +return AVERROR(ENOMEM);
> +ctx->tmp_key = av_malloc(key_size
[FFmpeg-devel] [PATCH] avcodec/x86/vvc/vvcdsp_init: fix unresolved external symbol on ARCH_X86_32
From: Wu Jianhua
Signed-off-by: Wu Jianhua
---
libavcodec/x86/vvc/vvcdsp_init.c | 78
1 file changed, 40 insertions(+), 38 deletions(-)
diff --git a/libavcodec/x86/vvc/vvcdsp_init.c b/libavcodec/x86/vvc/vvcdsp_init.c
index 909ef9f56b..8ee4074350 100644
--- a/libavcodec/x86/vvc/vvcdsp_init.c
+++ b/libavcodec/x86/vvc/vvcdsp_init.c
@@ -31,6 +31,7 @@
#include "libavcodec/vvc/vvcdsp.h"
#include "libavcodec/x86/h26x/h2656dsp.h"
+#if ARCH_X86_64
#define FW_PUT(name, depth, opt) \
static void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst, const
uint8_t *src, ptrdiff_t srcstride, \
int height, const int8_t *hf,
const int8_t *vf, int width)\
@@ -204,51 +205,52 @@ AVG_FUNCS(16, 12, avx2)
c->inter.avg= bf(avg, bd, opt); \
c->inter.w_avg = bf(w_avg, bd, opt); \
} while (0)
+#endif
void ff_vvc_dsp_init_x86(VVCDSPContext *const c, const int bd)
{
+#if ARCH_X86_64
const int cpu_flags = av_get_cpu_flags();
-if (ARCH_X86_64) {
-if (bd == 8) {
-if (EXTERNAL_SSE4(cpu_flags)) {
-MC_LINK_SSE4(8);
-}
-if (EXTERNAL_AVX2_FAST(cpu_flags)) {
-MC_LINKS_AVX2(8);
-}
-} else if (bd == 10) {
-if (EXTERNAL_SSE4(cpu_flags)) {
-MC_LINK_SSE4(10);
-}
-if (EXTERNAL_AVX2_FAST(cpu_flags)) {
-MC_LINKS_AVX2(10);
-MC_LINKS_16BPC_AVX2(10);
-}
-} else if (bd == 12) {
-if (EXTERNAL_SSE4(cpu_flags)) {
-MC_LINK_SSE4(12);
-}
-if (EXTERNAL_AVX2_FAST(cpu_flags)) {
-MC_LINKS_AVX2(12);
-MC_LINKS_16BPC_AVX2(12);
-}
+if (bd == 8) {
+if (EXTERNAL_SSE4(cpu_flags)) {
+MC_LINK_SSE4(8);
}
+if (EXTERNAL_AVX2_FAST(cpu_flags)) {
+MC_LINKS_AVX2(8);
+}
+} else if (bd == 10) {
+if (EXTERNAL_SSE4(cpu_flags)) {
+MC_LINK_SSE4(10);
+}
+if (EXTERNAL_AVX2_FAST(cpu_flags)) {
+MC_LINKS_AVX2(10);
+MC_LINKS_16BPC_AVX2(10);
+}
+} else if (bd == 12) {
+if (EXTERNAL_SSE4(cpu_flags)) {
+MC_LINK_SSE4(12);
+}
+if (EXTERNAL_AVX2_FAST(cpu_flags)) {
+MC_LINKS_AVX2(12);
+MC_LINKS_16BPC_AVX2(12);
+}
+}
-if (EXTERNAL_AVX2(cpu_flags)) {
-switch (bd) {
-case 8:
-AVG_INIT(8, avx2);
-break;
-case 10:
-AVG_INIT(10, avx2);
-break;
-case 12:
-AVG_INIT(12, avx2);
-break;
-default:
-break;
-}
+if (EXTERNAL_AVX2(cpu_flags)) {
+switch (bd) {
+case 8:
+AVG_INIT(8, avx2);
+break;
+case 10:
+AVG_INIT(10, avx2);
+break;
+case 12:
+AVG_INIT(12, avx2);
+break;
+default:
+break;
}
}
+#endif
}
--
2.43.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".
[FFmpeg-devel] [PATCH v2 2/2] avcodec/audiotoolboxenc: Ensure frame_size isn't zero
From: Zhao Zhili
---
libavcodec/audiotoolboxenc.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/libavcodec/audiotoolboxenc.c b/libavcodec/audiotoolboxenc.c
index 35dd4c553d..392e3fa11a 100644
--- a/libavcodec/audiotoolboxenc.c
+++ b/libavcodec/audiotoolboxenc.c
@@ -92,7 +92,7 @@ static UInt32 ffat_get_format_id(enum AVCodecID codec, int
profile)
}
}
-static void ffat_update_ctx(AVCodecContext *avctx)
+static int ffat_update_ctx(AVCodecContext *avctx)
{
ATDecodeContext *at = avctx->priv_data;
UInt32 size = sizeof(unsigned);
@@ -118,10 +118,23 @@ static void ffat_update_ctx(AVCodecContext *avctx)
if (!AudioConverterGetProperty(at->converter,
kAudioConverterCurrentOutputStreamDescription,
&size, &out_format)) {
-if (out_format.mFramesPerPacket)
+if (out_format.mFramesPerPacket) {
avctx->frame_size = out_format.mFramesPerPacket;
+} else {
+/* The doc on mFramesPerPacket says:
+ * For formats with a variable number of frames per packet, such
as
+ * Ogg Vorbis, set this field to 0.
+ * Looks like it means for decoding. There is no known case that
+ * mFramesPerPacket is zero for encoding. Use a default value for
safety.
+ */
+avctx->frame_size = 1024;
+av_log(avctx, AV_LOG_WARNING, "Missing mFramesPerPacket\n");
+}
if (out_format.mBytesPerPacket && avctx->codec_id == AV_CODEC_ID_ILBC)
avctx->block_align = out_format.mBytesPerPacket;
+} else {
+av_log(avctx, AV_LOG_ERROR, "Get OutputStreamDescription failed\n");
+return AVERROR_EXTERNAL;
}
at->frame_size = avctx->frame_size;
@@ -130,6 +143,8 @@ static void ffat_update_ctx(AVCodecContext *avctx)
at->pkt_size *= 1024;
avctx->frame_size *= 1024;
}
+
+return 0;
}
static int read_descr(GetByteContext *gb, int *tag)
@@ -236,6 +251,7 @@ static av_cold int ffat_init_encoder(AVCodecContext *avctx)
{
ATDecodeContext *at = avctx->priv_data;
OSStatus status;
+int ret;
AudioStreamBasicDescription in_format = {
.mSampleRate = avctx->sample_rate,
@@ -432,7 +448,9 @@ static av_cold int ffat_init_encoder(AVCodecContext *avctx)
}
}
-ffat_update_ctx(avctx);
+ret = ffat_update_ctx(avctx);
+if (ret < 0)
+return ret;
#if !TARGET_OS_IPHONE && defined(__MAC_10_9)
if (at->mode == kAudioCodecBitRateControlMode_Variable &&
avctx->rc_max_rate) {
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] lavc/dxvenc: migrate DXT1 encoder to lavu hashtable
Connor Worley:
> Offers a modest performance gain due to the switch from naive linear
> probling to robin hood.
How much would one gain if the hash function knew that key_size and
val_size are four?
>
> Signed-off-by: Connor Worley
> ---
> libavcodec/dxvenc.c | 121 +---
> 1 file changed, 35 insertions(+), 86 deletions(-)
>
> diff --git a/libavcodec/dxvenc.c b/libavcodec/dxvenc.c
> index b274175689..e17b3b2c36 100644
> --- a/libavcodec/dxvenc.c
> +++ b/libavcodec/dxvenc.c
> @@ -21,7 +21,7 @@
>
> #include
>
> -#include "libavutil/crc.h"
> +#include "libavutil/hashtable.h"
> #include "libavutil/imgutils.h"
> #include "libavutil/opt.h"
>
> @@ -44,69 +44,6 @@ enum DXVTextureFormat {
> DXV_FMT_DXT1 = MKBETAG('D', 'X', 'T', '1'),
> };
>
> -typedef struct HTEntry {
> -uint32_t key;
> -uint32_t pos;
> -} HTEntry;
> -
> -static void ht_init(HTEntry *ht)
> -{
> -for (size_t i = 0; i < LOOKBACK_HT_ELEMS; i++) {
> -ht[i].pos = -1;
> -}
> -}
> -
> -static uint32_t ht_lookup_and_upsert(HTEntry *ht, const AVCRC *hash_ctx,
> -uint32_t key, uint32_t pos)
> -{
> -uint32_t ret = -1;
> -size_t hash = av_crc(hash_ctx, 0, (uint8_t*)&key, 4) % LOOKBACK_HT_ELEMS;
> -for (size_t i = hash; i < hash + LOOKBACK_HT_ELEMS; i++) {
> -size_t wrapped_index = i % LOOKBACK_HT_ELEMS;
> -HTEntry *entry = &ht[wrapped_index];
> -if (entry->key == key || entry->pos == -1) {
> -ret = entry->pos;
> -entry->key = key;
> -entry->pos = pos;
> -break;
> -}
> -}
> -return ret;
> -}
> -
> -static void ht_delete(HTEntry *ht, const AVCRC *hash_ctx,
> - uint32_t key, uint32_t pos)
> -{
> -HTEntry *removed_entry = NULL;
> -size_t removed_hash;
> -size_t hash = av_crc(hash_ctx, 0, (uint8_t*)&key, 4) % LOOKBACK_HT_ELEMS;
> -
> -for (size_t i = hash; i < hash + LOOKBACK_HT_ELEMS; i++) {
> -size_t wrapped_index = i % LOOKBACK_HT_ELEMS;
> -HTEntry *entry = &ht[wrapped_index];
> -if (entry->pos == -1)
> -return;
> -if (removed_entry) {
> -size_t candidate_hash = av_crc(hash_ctx, 0,
> (uint8_t*)&entry->key, 4) % LOOKBACK_HT_ELEMS;
> -if ((wrapped_index > removed_hash && (candidate_hash <=
> removed_hash || candidate_hash > wrapped_index)) ||
> -(wrapped_index < removed_hash && (candidate_hash <=
> removed_hash && candidate_hash > wrapped_index))) {
> -*removed_entry = *entry;
> -entry->pos = -1;
> -removed_entry = entry;
> -removed_hash = wrapped_index;
> -}
> -} else if (entry->key == key) {
> -if (entry->pos <= pos) {
> -entry->pos = -1;
> -removed_entry = entry;
> -removed_hash = wrapped_index;
> -} else {
> -return;
> -}
> -}
> -}
> -}
> -
> typedef struct DXVEncContext {
> AVClass *class;
>
> @@ -123,10 +60,8 @@ typedef struct DXVEncContext {
> enum DXVTextureFormat tex_fmt;
> int (*compress_tex)(AVCodecContext *avctx);
>
> -const AVCRC *crc_ctx;
> -
> -HTEntry color_lookback_ht[LOOKBACK_HT_ELEMS];
> -HTEntry lut_lookback_ht[LOOKBACK_HT_ELEMS];
> +AVHashtableContext color_ht;
> +AVHashtableContext lut_ht;
> } DXVEncContext;
>
> /* Converts an index offset value to a 2-bit opcode and pushes it to a
> stream.
> @@ -161,27 +96,32 @@ static int dxv_compress_dxt1(AVCodecContext *avctx)
> DXVEncContext *ctx = avctx->priv_data;
> PutByteContext *pbc = &ctx->pbc;
> uint32_t *value;
> -uint32_t color, lut, idx, color_idx, lut_idx, prev_pos, state = 16, pos
> = 2, op = 0;
> +uint32_t color, lut, idx, color_idx, lut_idx, prev_pos, state = 16, pos
> = 0, op = 0;
>
> -ht_init(ctx->color_lookback_ht);
> -ht_init(ctx->lut_lookback_ht);
> +av_hashtable_clear(&ctx->color_ht);
> +av_hashtable_clear(&ctx->lut_ht);
>
> bytestream2_put_le32(pbc, AV_RL32(ctx->tex_data));
> +av_hashtable_set(&ctx->color_ht, ctx->tex_data, &pos);
> +pos++;
> bytestream2_put_le32(pbc, AV_RL32(ctx->tex_data + 4));
> -
> -ht_lookup_and_upsert(ctx->color_lookback_ht, ctx->crc_ctx,
> AV_RL32(ctx->tex_data), 0);
> -ht_lookup_and_upsert(ctx->lut_lookback_ht, ctx->crc_ctx,
> AV_RL32(ctx->tex_data + 4), 1);
> +av_hashtable_set(&ctx->lut_ht, ctx->tex_data + 4, &pos);
> +pos++;
>
> while (pos + 2 <= ctx->tex_size / 4) {
> idx = 0;
> +color_idx = 0;
> +lut_idx = 0;
>
> color = AV_RL32(ctx->tex_data + pos * 4);
> -prev_pos = ht_lookup_and_upsert(ctx->color_lookback_ht,
> ctx->crc_ctx, color, pos);
> -color_idx = prev_pos != -1 ? pos - prev_pos : 0;
> +if (av_hashtable_get(&ctx->color_ht,
Re: [FFmpeg-devel] [PATCH] avcodec/x86/vvc/vvcdsp_init: fix unresolved external symbol on ARCH_X86_32
toq...@outlook.com:
> From: Wu Jianhua
>
> Signed-off-by: Wu Jianhua
> ---
> libavcodec/x86/vvc/vvcdsp_init.c | 78
> 1 file changed, 40 insertions(+), 38 deletions(-)
>
> diff --git a/libavcodec/x86/vvc/vvcdsp_init.c
> b/libavcodec/x86/vvc/vvcdsp_init.c
> index 909ef9f56b..8ee4074350 100644
> --- a/libavcodec/x86/vvc/vvcdsp_init.c
> +++ b/libavcodec/x86/vvc/vvcdsp_init.c
> @@ -31,6 +31,7 @@
> #include "libavcodec/vvc/vvcdsp.h"
> #include "libavcodec/x86/h26x/h2656dsp.h"
>
> +#if ARCH_X86_64
> #define FW_PUT(name, depth, opt) \
> static void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst, const
> uint8_t *src, ptrdiff_t srcstride, \
> int height, const int8_t
> *hf, const int8_t *vf, int width)\
> @@ -204,51 +205,52 @@ AVG_FUNCS(16, 12, avx2)
> c->inter.avg= bf(avg, bd, opt); \
> c->inter.w_avg = bf(w_avg, bd, opt); \
> } while (0)
> +#endif
>
> void ff_vvc_dsp_init_x86(VVCDSPContext *const c, const int bd)
> {
> +#if ARCH_X86_64
> const int cpu_flags = av_get_cpu_flags();
>
> -if (ARCH_X86_64) {
> -if (bd == 8) {
> -if (EXTERNAL_SSE4(cpu_flags)) {
> -MC_LINK_SSE4(8);
> -}
> -if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> -MC_LINKS_AVX2(8);
> -}
> -} else if (bd == 10) {
> -if (EXTERNAL_SSE4(cpu_flags)) {
> -MC_LINK_SSE4(10);
> -}
> -if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> -MC_LINKS_AVX2(10);
> -MC_LINKS_16BPC_AVX2(10);
> -}
> -} else if (bd == 12) {
> -if (EXTERNAL_SSE4(cpu_flags)) {
> -MC_LINK_SSE4(12);
> -}
> -if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> -MC_LINKS_AVX2(12);
> -MC_LINKS_16BPC_AVX2(12);
> -}
> +if (bd == 8) {
> +if (EXTERNAL_SSE4(cpu_flags)) {
> +MC_LINK_SSE4(8);
> }
> +if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> +MC_LINKS_AVX2(8);
> +}
> +} else if (bd == 10) {
> +if (EXTERNAL_SSE4(cpu_flags)) {
> +MC_LINK_SSE4(10);
> +}
> +if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> +MC_LINKS_AVX2(10);
> +MC_LINKS_16BPC_AVX2(10);
> +}
> +} else if (bd == 12) {
> +if (EXTERNAL_SSE4(cpu_flags)) {
> +MC_LINK_SSE4(12);
> +}
> +if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> +MC_LINKS_AVX2(12);
> +MC_LINKS_16BPC_AVX2(12);
> +}
> +}
>
> -if (EXTERNAL_AVX2(cpu_flags)) {
> -switch (bd) {
> -case 8:
> -AVG_INIT(8, avx2);
> -break;
> -case 10:
> -AVG_INIT(10, avx2);
> -break;
> -case 12:
> -AVG_INIT(12, avx2);
> -break;
> -default:
> -break;
> -}
> +if (EXTERNAL_AVX2(cpu_flags)) {
> +switch (bd) {
> +case 8:
> +AVG_INIT(8, avx2);
> +break;
> +case 10:
> +AVG_INIT(10, avx2);
> +break;
> +case 12:
> +AVG_INIT(12, avx2);
> +break;
> +default:
> +break;
> }
> }
> +#endif
> }
Are really all of these functions unavailable for 32bit?
- 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] avdevice/caca: Allow to list multiple dither option types at once
Stefano Sabatini:
> On date Sunday 2024-02-04 18:36:45 +0100, Andreas Rheinhardt wrote:
>> This can be achieved by using AV_OPT_TYPE_FLAGS instead of
>> AV_OPT_TYPE_STRING. It also avoids strcmp() when accessing
>> the option.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavdevice/caca.c | 34 +-
>> 1 file changed, 17 insertions(+), 17 deletions(-)
>>
>> diff --git a/libavdevice/caca.c b/libavdevice/caca.c
>> index 6af1649137..c0e09cf6f7 100644
>> --- a/libavdevice/caca.c
>> +++ b/libavdevice/caca.c
>> @@ -24,6 +24,13 @@
>> #include "libavformat/mux.h"
>> #include "avdevice.h"
>>
>
>> +enum {
>> +SHOW_ALGORITHMS = 1 << 0,
>> +SHOW_ANTIALIASES = 1 << 1,
>> +SHOW_CHARSETS= 1 << 2,
>> +SHOW_COLORS = 1 << 3,
>> +};
>
> nit: LIST_ for consistency?
>
Will make the change and apply.
>> +
>> typedef struct CACAContext {
>> AVClass *class;
>> AVFormatContext *ctx;
>> @@ -38,7 +45,7 @@ typedef struct CACAContext {
>> char*charset, *color;
>> char*driver;
>>
>> -char*list_dither;
>> +int list_dither;
>> int list_drivers;
>> } CACAContext;
>>
>> @@ -99,21 +106,14 @@ static int caca_write_header(AVFormatContext *s)
>> return AVERROR_EXIT;
>> }
>> if (c->list_dither) {
>> -if (!strcmp(c->list_dither, "colors")) {
>> +if (c->list_dither & SHOW_COLORS)
>> list_dither_color(c);
>> -} else if (!strcmp(c->list_dither, "charsets")) {
>> +if (c->list_dither & SHOW_CHARSETS)
>> list_dither_charset(c);
>> -} else if (!strcmp(c->list_dither, "algorithms")) {
>> +if (c->list_dither & SHOW_ALGORITHMS)
>> list_dither_algorithm(c);
>> -} else if (!strcmp(c->list_dither, "antialiases")) {
>> +if (c->list_dither & SHOW_ANTIALIASES)
>> list_dither_antialias(c);
>> -} else {
>> -av_log(s, AV_LOG_ERROR,
>> - "Invalid argument '%s', for 'list_dither' option\n"
>> - "Argument must be one of 'algorithms, 'antialiases',
>> 'charsets', 'colors'\n",
>> - c->list_dither);
>> -return AVERROR(EINVAL);
>> -}
>> return AVERROR_EXIT;
>> }
>>
>> @@ -205,11 +205,11 @@ static const AVOption options[] = {
>> { "charset", "set charset used to render output", OFFSET(charset),
>> AV_OPT_TYPE_STRING, {.str = "default" }, 0, 0, ENC },
>> { "color","set color used to render output", OFFSET(color),
>> AV_OPT_TYPE_STRING, {.str = "default" }, 0, 0, ENC },
>> { "list_drivers", "list available drivers", OFFSET(list_drivers),
>> AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, ENC },
>> -{ "list_dither", "list available dither options", OFFSET(list_dither),
>> AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1, ENC, "list_dither" },
>> -{ "algorithms", NULL, 0, AV_OPT_TYPE_CONST, {.str = "algorithms"}, 0,
>> 0, ENC, "list_dither" },
>> -{ "antialiases", NULL, 0, AV_OPT_TYPE_CONST, {.str = "antialiases"},0,
>> 0, ENC, "list_dither" },
>> -{ "charsets", NULL, 0, AV_OPT_TYPE_CONST, {.str = "charsets"}, 0,
>> 0, ENC, "list_dither" },
>> -{ "colors", NULL, 0, AV_OPT_TYPE_CONST, {.str = "colors"}, 0,
>> 0, ENC, "list_dither" },
>> +{ "list_dither", "list available dither options", OFFSET(list_dither),
>> AV_OPT_TYPE_FLAGS, { .i64 = 0 }, 0, INT_MAX, ENC, "list_dither" },
>> +{ "algorithms", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = SHOW_ALGORITHMS
>> }, 0, 0, ENC, "list_dither" },
>> +{ "antialiases", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = SHOW_ANTIALIASES
>> }, 0, 0, ENC, "list_dither" },
>> +{ "charsets", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = SHOW_CHARSETS },
>> 0, 0, ENC, "list_dither" },
>> +{ "colors", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = SHOW_COLORS },
>> 0, 0, ENC, "list_dither" },
>> { NULL },
>> };
>
> LGTM otherwise, 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] avcodec/x86/vvc/vvcdsp_init: fix unresolved external symbol on ARCH_X86_32
> 发件人: ffmpeg-devel 代表 Andreas Rheinhardt > > 发送时间: 2024年2月5日 4:06 > 收件人: ffmpeg-devel@ffmpeg.org > 主题: Re: [FFmpeg-devel] [PATCH] avcodec/x86/vvc/vvcdsp_init: fix unresolved > external symbol on ARCH_X86_32 > > toq...@outlook.com: >> From: Wu Jianhua >> >> Signed-off-by: Wu Jianhua >> --- >> libavcodec/x86/vvc/vvcdsp_init.c | 78 >> 1 file changed, 40 insertions(+), 38 deletions(-) >> >> diff --git a/libavcodec/x86/vvc/vvcdsp_init.c >> b/libavcodec/x86/vvc/vvcdsp_init.c >> index 909ef9f56b..8ee4074350 100644 >> --- a/libavcodec/x86/vvc/vvcdsp_init.c >> +++ b/libavcodec/x86/vvc/vvcdsp_init.c >> @@ -31,6 +31,7 @@ >> #include "libavcodec/vvc/vvcdsp.h" >> #include "libavcodec/x86/h26x/h2656dsp.h" >> > > Are really all of these functions unavailable for 32bit? > > - Andreas Yes. Both libavcodec\x86\vvc\vvc_mc.asm and libavcodec\x86\h26x\h2656_inter.asm are wrapped in ARCH_X86_64. ___ 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] libavformat/matroskaenc: reformat options table indentation and descriptions
Marth64:
> matroskaenc options table has grown packed over time, and is now challenging
> to read. The purpose of this patch is to reformat the table, indentation-wise,
> and to make the capitalization/endings of each description at least
> consistent.
>
> I intend to sort the options in a follow-up patch, but wanted to phase
> this out to be easier to validate.
>
> Signed-off-by: Marth64
> ---
> libavformat/matroskaenc.c | 42 ++-
> 1 file changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 1457a6890c..2668d1e009 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -3497,20 +3497,34 @@ static const AVCodecTag additional_subtitle_tags[] = {
> #define OFFSET(x) offsetof(MatroskaMuxContext, x)
> #define FLAGS AV_OPT_FLAG_ENCODING_PARAM
> static const AVOption options[] = {
> -{ "reserve_index_space", "Reserve a given amount of space (in bytes) at
> the beginning of the file for the index (cues).", OFFSET(reserve_cues_space),
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, FLAGS },
> -{ "cues_to_front", "Move Cues (the index) to the front by shifting data
> if necessary", OFFSET(move_cues_to_front), AV_OPT_TYPE_BOOL, { .i64 = 0}, 0,
> 1, FLAGS },
> -{ "cluster_size_limit", "Store at most the provided amount of bytes in
> a cluster. ", OFFSET(cluster_size_limit),
> AV_OPT_TYPE_INT , { .i64 = -1 }, -1, INT_MAX, FLAGS },
> -{ "cluster_time_limit", "Store at most the provided number of
> milliseconds in a cluster.",
> OFFSET(cluster_time_limit), AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX,
> FLAGS },
> -{ "dash", "Create a WebM file conforming to WebM DASH specification",
> OFFSET(is_dash), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
> -{ "dash_track_number", "Track number for the DASH stream",
> OFFSET(dash_track_number), AV_OPT_TYPE_INT, { .i64 = 1 }, 1, INT_MAX, FLAGS },
> -{ "live", "Write files assuming it is a live stream.", OFFSET(is_live),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
> -{ "allow_raw_vfw", "allow RAW VFW mode", OFFSET(allow_raw_vfw),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
> -{ "flipped_raw_rgb", "Raw RGB bitmaps in VFW mode are stored bottom-up",
> OFFSET(flipped_raw_rgb), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
> -{ "write_crc32", "write a CRC32 element inside every Level 1 element",
> OFFSET(write_crc), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, FLAGS },
> -{ "default_mode", "Controls how a track's FlagDefault is inferred",
> OFFSET(default_mode), AV_OPT_TYPE_INT, { .i64 = DEFAULT_MODE_PASSTHROUGH },
> DEFAULT_MODE_INFER, DEFAULT_MODE_PASSTHROUGH, FLAGS, "default_mode" },
> -{ "infer", "For each track type, mark each track of disposition default
> as default; if none exists, mark the first track as default.", 0,
> AV_OPT_TYPE_CONST, { .i64 = DEFAULT_MODE_INFER }, 0, 0, FLAGS, "default_mode"
> },
> -{ "infer_no_subs", "For each track type, mark each track of disposition
> default as default; for audio and video: if none exists, mark the first track
> as default.", 0, AV_OPT_TYPE_CONST, { .i64 = DEFAULT_MODE_INFER_NO_SUBS }, 0,
> 0, FLAGS, "default_mode" },
> -{ "passthrough", "Use the disposition flag as-is", 0, AV_OPT_TYPE_CONST,
> { .i64 = DEFAULT_MODE_PASSTHROUGH }, 0, 0, FLAGS, "default_mode" },
> +{ "reserve_index_space", "Reserve a given amount of space (in bytes) at
> the beginning of the file for the index (cues)",
> + OFFSET(reserve_cues_space), AV_OPT_TYPE_INT,
> { .i64 = 0 }, 0, INT_MAX,FLAGS },
> +{ "cues_to_front", "Move Cues (the index) to the front by shifting
> data if necessary",
> + OFFSET(move_cues_to_front), AV_OPT_TYPE_BOOL,
> { .i64 = 0 }, 0, 1, FLAGS },
> +{ "cluster_size_limit", "Store at most the provided amount of bytes in
> a cluster",
> + OFFSET(cluster_size_limit), AV_OPT_TYPE_INT,
> { .i64 = -1 }, -1, INT_MAX,FLAGS },
> +{ "cluster_time_limit", "Store at most the provided number of
> milliseconds in a cluster",
> + OFFSET(cluster_time_limit), AV_OPT_TYPE_INT64,
> { .i64 = -1 }, -1, INT64_MAX, FLAGS },
> +{ "dash","Create a WebM file conforming to WebM DASH
> specification",
> + OFFSET(is_dash),AV_OPT_TYPE_BOOL,
> { .i64 = 0 }, 0, 1, FLAGS },
> +{ "dash_track_number", "Track number for the DASH stream",
> + OFFSET(dash_track_number), AV_OPT_TYPE_INT,
> { .i64 = 1 }, 1, INT_MAX,FLAGS },
> +{ "live","Write files assuming it is a live stream",
> + OFFSET(is_live),AV_OPT_TYPE_BOO
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: pass link YUV colorspace to ff_draw_init2
On Wed, 31 Jan 2024 12:47:59 +0100 "Diederick C. Niehorster" wrote: > On Wed, Jan 31, 2024 at 12:17 PM Niklas Haas wrote: > > > > From: Niklas Haas > > > > diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c > > index fe7e6ace27..37110bc32f 100644 > > --- a/libavfilter/vf_drawtext.c > > +++ b/libavfilter/vf_drawtext.c > > @@ -1152,7 +1152,7 @@ static int config_input(AVFilterLink *inlink) > > char *expr; > > int ret; > > > > -ff_draw_init(&s->dc, inlink->format, FF_DRAW_PROCESS_ALPHA); > > +ff_draw_init(&s->dc, inlink->format, inlink->colorspace, > > inlink->color_range, FF_DRAW_PROCESS_ALPHA); > > Should this be ff_draw_init2? Yes, fixed. Will merge in 24h without further feedback. ___ 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] lavc/vvc: Validate alf_list indexes
On Sun, Feb 4, 2024 at 1:22 AM wrote:
> From: Frank Plowman
>
> Fixes crashes when decoding illegal bitstreams found by fuzzing.
>
> Signed-off-by: Frank Plowman
> ---
> libavcodec/vvc/vvc_ctu.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vvc/vvc_ctu.c b/libavcodec/vvc/vvc_ctu.c
> index d166b16a19..f601c6c95e 100644
> --- a/libavcodec/vvc/vvc_ctu.c
> +++ b/libavcodec/vvc/vvc_ctu.c
> @@ -2207,7 +2207,7 @@ static void hls_sao(VVCLocalContext *lc, const int
> rx, const int ry)
> }
> }
>
> -static void alf_params(VVCLocalContext *lc, const int rx, const int ry)
> +static int alf_params(VVCLocalContext *lc, const int rx, const int ry)
> {
> const VVCFrameContext *fc = lc->fc;
> const H266RawSliceHeader *sh = lc->sc->sh.r;
> @@ -2233,6 +2233,11 @@ static void alf_params(VVCLocalContext *lc, const
> int rx, const int ry)
> c_idx == CB ? sh->sh_alf_cb_enabled_flag :
> sh->sh_alf_cr_enabled_flag;
> if (alf_enabled_flag) {
> const VVCALF *aps =
> fc->ps.alf_list[sh->sh_alf_aps_id_chroma];
> +if (!aps) {
> +// Slice header refers to an APS which does not exist
> +return AVERROR_INVALIDDATA;
> +}
> +
>
Thank you Frank.
Since all "if conditions" are related to slices, could we perform the check
at sh_derive()?
> alf->ctb_flag[c_idx] = ff_vvc_alf_ctb_flag(lc, rx, ry,
> c_idx);
> alf->alf_ctb_filter_alt_idx[c_idx - 1] = 0;
> if (alf->ctb_flag[c_idx] && aps->num_chroma_filters > 1)
> @@ -2247,10 +2252,16 @@ static void alf_params(VVCLocalContext *lc, const
> int rx, const int ry)
> alf->ctb_cc_idc[i] = 0;
> if (cc_enabled[i]) {
> const VVCALF *aps = fc->ps.alf_list[cc_aps_id[i]];
> +if (!aps) {
> +// Slice header refers to an APS which does not exist
> +return AVERROR_INVALIDDATA;
> +}
> alf->ctb_cc_idc[i] = ff_vvc_alf_ctb_cc_idc(lc, rx, ry, i,
> aps->num_cc_filters[i]);
> }
> }
> }
> +
> +return 0;
> }
>
> static void deblock_params(VVCLocalContext *lc, const int rx, const int
> ry)
> @@ -2274,7 +2285,9 @@ static int hls_coding_tree_unit(VVCLocalContext *lc,
> memset(lc->parse.chroma_qp_offset, 0,
> sizeof(lc->parse.chroma_qp_offset));
>
> hls_sao(lc, x0 >> sps->ctb_log2_size_y, y0 >> sps->ctb_log2_size_y);
> -alf_params(lc, x0 >> sps->ctb_log2_size_y, y0 >>
> sps->ctb_log2_size_y);
> +ret = alf_params(lc, x0 >> sps->ctb_log2_size_y, y0 >>
> sps->ctb_log2_size_y);
> +if (ret < 0)
> +return ret;
> deblock_params(lc, x0 >> sps->ctb_log2_size_y, y0 >>
> sps->ctb_log2_size_y);
>
> if (IS_I(rsh) && sps->r->sps_qtbtt_dual_tree_intra_flag)
> --
> 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/cafenc: fixed packet_size calculation
the problem is the very last packet
can be shorter than default packet_size
so it's required to exclude it from
packet_size calculations.
fixes #10465
---
libavformat/cafenc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavformat/cafenc.c b/libavformat/cafenc.c
index 67be59806c..fcc4838392 100644
--- a/libavformat/cafenc.c
+++ b/libavformat/cafenc.c
@@ -34,6 +34,8 @@ typedef struct {
int size_buffer_size;
int size_entries_used;
int packets;
+int64_t duration;
+int64_t last_packet_duration;
} CAFContext;
static uint32_t codec_flags(enum AVCodecID codec_id) {
@@ -238,6 +240,8 @@ static int caf_write_packet(AVFormatContext *s, AVPacket
*pkt)
pkt_sizes[caf->size_entries_used++] = 128 | top;
}
pkt_sizes[caf->size_entries_used++] = pkt->size & 127;
+caf->duration += pkt->duration;
+caf->last_packet_duration = pkt->duration;
caf->packets++;
}
avio_write(s->pb, pkt->data, pkt->size);
@@ -259,7 +263,11 @@ static int caf_write_trailer(AVFormatContext *s)
if (!par->block_align) {
int packet_size = samples_per_packet(par);
if (!packet_size) {
-packet_size = st->duration / (caf->packets - 1);
+if (caf->duration) {
+packet_size = (caf->duration - caf->last_packet_duration)
/ (caf->packets - 1);
+} else {
+packet_size = st->duration / (caf->packets - 1);
+}
avio_seek(pb, FRAME_SIZE_OFFSET, SEEK_SET);
avio_wb32(pb, packet_size);
}
--
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] Sovereign Tech Fund
> On Feb 5, 2024, at 18:21, Michael Niedermayer wrote: > > On Wed, Jan 31, 2024 at 09:55:00PM +, Kieran Kunhya wrote: >> On Wed, 31 Jan 2024 at 21:45, Derek Buitenhuis >> wrote: >> >>> On 1/30/2024 1:48 AM, Michael Niedermayer wrote: https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024 >>> >>> Not to derail this fine thread, but what forks does the Merge Forks >>> project refer to? >>> >>> - Derek >>> >> >> I also added a note that 70 USD for coverity is way too much. I picked a >> random issue 1503073 and within a minute saw that it was a false positive. >> I don't deserve 70USD for that. > > I fixed 2 coverity issues yesterday and it took me over 3 hours > I cant do this for 70USD per issue > (you can see the ML for the 2 patches) > > In the first, the issue depended on fbw_channels to be 0. > If you look at its initialization that is possible if you have a > mono LFE channel but is that possible and can the code be reached > in that case. > For someone who hasnt worked at that specific code it takes some time > to build an argument that this should not be possible > > The second issue, its obvious a bug but how do we even reach that code? > No fate tests > luckily there are examples in the docs but it took me several tries to > get the code to execute with similar testcases. > now looking at it, i suspect the patch i posted probably should be split > so we need a 2nd iteration > and looking at the clock when i posted this and when i started yesterday > fact is it was 3-4h work for these 2 issues I think work on two to three issues in spare time per day is a rough but reasonable number, with one to two being easy and one from medium to hard. 210$ isn’t that much, especially for overtime pay. Many people have working on open source for free (as in beer) for many years, but it doesn’t mean that their work not worth like 70 $. > > did i pick these randomly? no, i started frm the top and skiped a few > i really did not want to work on like the flac parser. > > Some coverity isssues are dead easy and need seconds to categorize > or even fix. But for others its difficult > > Also to categorize coverity issues one needs to understand the affectd > code. coverity telling you that after 355 conditions theres a out of > array access, you need to know if the 355 conditions are inconsistant > and contradicting. If they contradict its a false positive otherwise > its a bug. > similar when you check the return code of a function most of the time > coverity will create an issue for cases where its not checked. Thats > trivial to fix IF you know the code. But IF you do not know the code > that can some decent time too. And i think noone knows all code. > > Either way, iam interrested in helping with coverity work while > at the same time this environment where peole finger point and say > "is way too much" is something i dont feel comfortable to work in. > > maybe doing it per hour instead of per issue is a safer way > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Republics decline into democracies and democracies degenerate into > despotisms. -- Aristotle > ___ > 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 8/9] avcodec: add D3D12VA hardware HEVC encoder
> 发件人: ffmpeg-devel 代表
> tong1.wu-at-intel@ffmpeg.org
> 发送时间: 2024年2月2日 2:16
> 收件人: ffmpeg-devel@ffmpeg.org
> 抄送: Tong Wu
> 主题: [FFmpeg-devel] [PATCH v3 8/9] avcodec: add D3D12VA hardware HEVC encoder
>
> From: Tong Wu
>
> This implementation is based on D3D12 Video Encoding Spec:
> https://microsoft.github.io/DirectX-Specs/d3d/D3D12VideoEncoding.html
>
> Sample command line for transcoding:
> ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4
> -c:v hevc_d3d12va output.mp4
>
> Signed-off-by: Tong Wu
> ---
> configure|6 +
> libavcodec/Makefile |4 +-
> libavcodec/allcodecs.c |1 +
> libavcodec/d3d12va_encode.c | 1441 ++
> libavcodec/d3d12va_encode.h | 275 ++
> libavcodec/d3d12va_encode_hevc.c | 1011 +
> libavcodec/hw_base_encode.h |2 +-
> 7 files changed, 2738 insertions(+), 2 deletions(-)
> create mode 100644 libavcodec/d3d12va_encode.c
> create mode 100644 libavcodec/d3d12va_encode.h
> create mode 100644 libavcodec/d3d12va_encode_hevc.c
>
>
>+min_cu_size =
>d3d12va_encode_hevc_map_cusize(ctx->codec_conf.pHEVCConfig->MinLumaCodingUnitSize);
>+max_cu_size =
>d3d12va_encode_hevc_map_cusize(ctx->codec_conf.pHEVCConfig->MaxLumaCodingUnitSize);
>+min_tu_size =
>d3d12va_encode_hevc_map_tusize(ctx->codec_conf.pHEVCConfig->MinLumaTransformUnitSize);
>+max_tu_size =
>d3d12va_encode_hevc_map_tusize(ctx->codec_conf.pHEVCConfig->MaxLumaTransformUnitSize);
>+
>+// VPS
>+
>+vps->nal_unit_header = (H265RawNALUnitHeader) {
Should this blank line be removed, because the comment is for the codes below?
> +vps->vps_timing_info_present_flag = 0;
> +
> +// SPS
> +
> +sps->nal_unit_header = (H265RawNALUnitHeader) {
> +.nal_unit_type = HEVC_NAL_SPS,
> +.nuh_layer_id = 0,
> +.nuh_temporal_id_plus1 = 1,
> +};
The same as above.
> +static uint8_t
> d3d12va_encode_hevc_map_cusize(D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_CUSIZE
> cusize)
> +{
> +switch (cusize) {
> +case D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_CUSIZE_8x8:
> return 8;
> +case D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_CUSIZE_16x16:
> return 16;
> +case D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_CUSIZE_32x32:
> return 32;
> +case D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_CUSIZE_64x64:
> return 64;
> +}
> +return 0;
> +}
> +
> +static uint8_t
> d3d12va_encode_hevc_map_tusize(D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_TUSIZE
> tusize)
> +{
> +switch (tusize) {
> +case D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_TUSIZE_4x4:
> return 4;
> +case D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_TUSIZE_8x8:
> return 8;
> +case D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_TUSIZE_16x16:
> return 16;
> +case D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_TUSIZE_32x32:
> return 32;
> +}
> +return 0;
> +}
A default branch is needed or we can use 8 << cusize and 4 << tusize for
simplification.
> +hr = ID3D12Device3_QueryInterface(ctx->device3, &IID_ID3D12VideoDevice3,
> (void **)&ctx->video_device3);
> +if (FAILED(hr)) {
> +err = AVERROR_UNKNOWN;
> +goto fail;
> +}
> +
> +if (FAILED(ID3D12VideoDevice3_CheckFeatureSupport(ctx->video_device3,
> D3D12_FEATURE_VIDEO_FEATURE_AREA_SUPPORT,
> + &support,
> sizeof(support))) && !support.VideoEncodeSupport) {
> +av_log(avctx, AV_LOG_ERROR, "D3D12 video device has no video encoder
> support");
> +err = AVERROR(EINVAL);
> +goto fail;
> +}
We need to output the log for the ID3D12Device3_QueryInterface call, or the
user will not know the error is resulting from that,
the OS and the driver don't support the ID3D12VideoDevice3 interface.
___
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] lavc/vvc: Validate alf_list indexes
On 05/02/2024 13:45, Nuo Mi wrote:
On Sun, Feb 4, 2024 at 1:22 AM wrote:
From: Frank Plowman
Fixes crashes when decoding illegal bitstreams found by fuzzing.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/vvc_ctu.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc/vvc_ctu.c b/libavcodec/vvc/vvc_ctu.c
index d166b16a19..f601c6c95e 100644
--- a/libavcodec/vvc/vvc_ctu.c
+++ b/libavcodec/vvc/vvc_ctu.c
@@ -2207,7 +2207,7 @@ static void hls_sao(VVCLocalContext *lc, const int
rx, const int ry)
}
}
-static void alf_params(VVCLocalContext *lc, const int rx, const int ry)
+static int alf_params(VVCLocalContext *lc, const int rx, const int ry)
{
const VVCFrameContext *fc = lc->fc;
const H266RawSliceHeader *sh = lc->sc->sh.r;
@@ -2233,6 +2233,11 @@ static void alf_params(VVCLocalContext *lc, const
int rx, const int ry)
c_idx == CB ? sh->sh_alf_cb_enabled_flag :
sh->sh_alf_cr_enabled_flag;
if (alf_enabled_flag) {
const VVCALF *aps =
fc->ps.alf_list[sh->sh_alf_aps_id_chroma];
+if (!aps) {
+// Slice header refers to an APS which does not exist
+return AVERROR_INVALIDDATA;
+}
+
Thank you Frank.
Since all "if conditions" are related to slices, could we perform the check
at sh_derive()?
Yes, I had another look at this yesterday and came to the same
conclusion. Do you think it's better to derive pointers to the relevant
APSs or just to validate the indices into fps->aps_list?
alf->ctb_flag[c_idx] = ff_vvc_alf_ctb_flag(lc, rx, ry,
c_idx);
alf->alf_ctb_filter_alt_idx[c_idx - 1] = 0;
if (alf->ctb_flag[c_idx] && aps->num_chroma_filters > 1)
@@ -2247,10 +2252,16 @@ static void alf_params(VVCLocalContext *lc, const
int rx, const int ry)
alf->ctb_cc_idc[i] = 0;
if (cc_enabled[i]) {
const VVCALF *aps = fc->ps.alf_list[cc_aps_id[i]];
+if (!aps) {
+// Slice header refers to an APS which does not exist
+return AVERROR_INVALIDDATA;
+}
alf->ctb_cc_idc[i] = ff_vvc_alf_ctb_cc_idc(lc, rx, ry, i,
aps->num_cc_filters[i]);
}
}
}
+
+return 0;
}
static void deblock_params(VVCLocalContext *lc, const int rx, const int
ry)
@@ -2274,7 +2285,9 @@ static int hls_coding_tree_unit(VVCLocalContext *lc,
memset(lc->parse.chroma_qp_offset, 0,
sizeof(lc->parse.chroma_qp_offset));
hls_sao(lc, x0 >> sps->ctb_log2_size_y, y0 >> sps->ctb_log2_size_y);
-alf_params(lc, x0 >> sps->ctb_log2_size_y, y0 >>
sps->ctb_log2_size_y);
+ret = alf_params(lc, x0 >> sps->ctb_log2_size_y, y0 >>
sps->ctb_log2_size_y);
+if (ret < 0)
+return ret;
deblock_params(lc, x0 >> sps->ctb_log2_size_y, y0 >>
sps->ctb_log2_size_y);
if (IS_I(rsh) && sps->r->sps_qtbtt_dual_tree_intra_flag)
--
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 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] avcodec/vvcdec: fix seeking for open GOP
On Sat, Feb 3, 2024 at 6:35 PM Nuo Mi wrote:
> how to reproduce:
> wget https://media.xiph.org/video/derf/y4m/students_cif.y4m
> vvencapp --input students_cif.y4m --preset faster --output students.266
> MP4Box -add students.266:fps=3/1001:par=12:11 -new students.mp4
> ffplay students.mp4
Applied, thanks James for the review
> ---
> libavcodec/vvc/vvc_refs.c | 6 ++
> libavcodec/vvc/vvc_refs.h | 1 +
> libavcodec/vvc/vvcdec.c | 6 ++
> 3 files changed, 13 insertions(+)
>
> diff --git a/libavcodec/vvc/vvc_refs.c b/libavcodec/vvc/vvc_refs.c
> index bf503e429e..e1895d1cca 100644
> --- a/libavcodec/vvc/vvc_refs.c
> +++ b/libavcodec/vvc/vvc_refs.c
> @@ -80,6 +80,12 @@ void ff_vvc_clear_refs(VVCFrameContext *fc)
> VVC_FRAME_FLAG_SHORT_REF | VVC_FRAME_FLAG_LONG_REF);
> }
>
> +void ff_vvc_flush_dpb(VVCFrameContext *fc)
> +{
> +for (int i = 0; i < FF_ARRAY_ELEMS(fc->DPB); i++)
> +ff_vvc_unref_frame(fc, &fc->DPB[i], ~0);
> +}
> +
> static void free_progress(FFRefStructOpaque unused, void *obj)
> {
> FrameProgress *p = (FrameProgress *)obj;
> diff --git a/libavcodec/vvc/vvc_refs.h b/libavcodec/vvc/vvc_refs.h
> index cd3b5f5632..eba4422fb4 100644
> --- a/libavcodec/vvc/vvc_refs.h
> +++ b/libavcodec/vvc/vvc_refs.h
> @@ -33,6 +33,7 @@ int ff_vvc_frame_rpl(VVCContext *s, VVCFrameContext *fc,
> SliceContext *sc);
> int ff_vvc_slice_rpl(VVCContext *s, VVCFrameContext *fc, SliceContext
> *sc);
> void ff_vvc_unref_frame(VVCFrameContext *fc, VVCFrame *frame, int flags);
> void ff_vvc_clear_refs(VVCFrameContext *fc);
> +void ff_vvc_flush_dpb(VVCFrameContext *fc);
>
> typedef enum VVCProgress {
> VVC_PROGRESS_MV,
> diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c
> index 83ee472ce6..1a050600eb 100644
> --- a/libavcodec/vvc/vvcdec.c
> +++ b/libavcodec/vvc/vvcdec.c
> @@ -922,9 +922,15 @@ static av_cold void vvc_decode_flush(AVCodecContext
> *avctx)
> {
> VVCContext *s = avctx->priv_data;
> int got_output = 0;
> +VVCFrameContext *last;
>
> while (s->nb_delayed)
> wait_delayed_frame(s, NULL, &got_output);
> +
> +last = get_frame_context(s, s->fcs, s->nb_frames - 1);
> +ff_vvc_flush_dpb(last);
> +
> +s->eos = 1;
> }
>
> static av_cold int vvc_decode_free(AVCodecContext *avctx)
> --
> 2.25.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/jpeg2000dec: support of 2 fields in 1 AVPacket
sön 2024-02-04 klockan 23:25 -0300 skrev James Almer: > On 2/3/2024 7:00 AM, Tomas Härdin wrote: > > fre 2024-02-02 klockan 16:55 +0100 skrev Jerome Martinez: > > > Before this patch, the FFmpeg MXF parser correctly detects > > > content > > > with > > > 2 fields in 1 AVPacket as e.g. interlaced 720x486 but the FFmpeg > > > JPEG > > > 2000 decoder reads the JPEG 2000 SIZ header without understanding > > > that > > > the indicated height is the height of 1 field only so overwrites > > > the > > > frame size info with e.g. 720x243, and also completely discards > > > the > > > second frame, which lead to the decoding of only half of the > > > stored > > > content as "progressive" 720x243 flagged interlaced. > > > > Is the decoder really the right place to do this? Surely this > > happens > > with more codecs than just j2k. Isnt it also a parser's job to do > > this > > kind of stuff? > > An AVParser must not split (or assemble) a packet in a form that is > not > meant to be encapsulated in a container. This is two independent packets that are concatenated. A bsf changes the bits, right? Whereas in this case no changes in the actual data is necessary. Parsers are typically used to split raw essence into packets, right? This is a similar case. A use-case for this kind of splitting could be upping EditRate to 6/1001 (SampleRate still being 6/1001), allowing for field- level editing. The resulting MXF would still be SEPARATE_FIELDS. This is mode F1 in the table that pal posted. This ties into the work Anton is doing on interlacing I suspect. /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 1/2] avfilter/buffersrc: promote unspecified color metadata
From: Niklas Haas Currently, this only affects untagged RGB/XYZ/Gray, which get forced to their corresponding metadata before entering the filter graph. The main justification for this change, however, is the planned ability to add automatic promotion of unspecified yuv to mpeg range yuv. Notably, this change will never allow accidentally cross-promoting unspecified to jpeg or to a specific YUV matrix, since that is still bound by the constraints of YUV range negotiation as set up by query_formats. --- libavfilter/buffersrc.c | 5 + tests/ref/fate/rgb24-mkv | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c index 6e450ff6b7..93fadab65f 100644 --- a/libavfilter/buffersrc.c +++ b/libavfilter/buffersrc.c @@ -291,6 +291,11 @@ FF_DISABLE_DEPRECATION_WARNINGS FF_ENABLE_DEPRECATION_WARNINGS #endif +if (copy->colorspace == AVCOL_SPC_UNSPECIFIED) +copy->colorspace = ctx->outputs[0]->colorspace; +if (copy->color_range == AVCOL_RANGE_UNSPECIFIED) +copy->color_range = ctx->outputs[0]->color_range; + ret = ff_filter_frame(ctx->outputs[0], copy); if (ret < 0) return ret; diff --git a/tests/ref/fate/rgb24-mkv b/tests/ref/fate/rgb24-mkv index 99234f1052..1cbed136dd 100644 --- a/tests/ref/fate/rgb24-mkv +++ b/tests/ref/fate/rgb24-mkv @@ -1,5 +1,5 @@ -e181dc84058c3584598333dabd110123 *tests/data/fate/rgb24-mkv.matroska -58225 tests/data/fate/rgb24-mkv.matroska +7d767e8238c674ecfa80458cb281c09e *tests/data/fate/rgb24-mkv.matroska +58236 tests/data/fate/rgb24-mkv.matroska #tb 0: 1/10 #media_type 0: video #codec_id 0: rawvideo -- 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 2/2] avfilter/buffersrc: allow promoting color range to MPEG
From: Niklas Haas
Otherwise, passing an UNSPECIFIED frame to am MPEG-only filter graph
would trigger insertion of an unnecessary vf_scale filter, which would
perform a memcpy to convert between the two.
This is safe to do because unspecified YUV frames are already
universally assumed to be MPEG range, in particular by swscale.
---
libavfilter/buffersrc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index 93fadab65f..a6a000df1e 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -506,8 +506,14 @@ static int query_formats(AVFilterContext *ctx)
if ((ret = ff_add_format(&color_spaces, c->color_space)) < 0 ||
(ret = ff_set_common_color_spaces(ctx, color_spaces)) < 0)
return ret;
-if ((ret = ff_add_format(&color_ranges, c->color_range)) < 0 ||
-(ret = ff_set_common_color_ranges(ctx, color_ranges)) < 0)
+if ((ret = ff_add_format(&color_ranges, c->color_range)) < 0)
+return ret;
+if (c->color_range == AVCOL_RANGE_UNSPECIFIED) {
+/* allow implicitly promoting unspecified to mpeg */
+if ((ret = ff_add_format(&color_ranges, AVCOL_RANGE_MPEG)) < 0)
+return ret;
+}
+if ((ret = ff_set_common_color_ranges(ctx, color_ranges)) < 0)
return ret;
}
break;
--
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".
Re: [FFmpeg-devel] [PATCH] lavc/vvc: Validate alf_list indexes
On Mon, Feb 5, 2024 at 10:04 PM Frank Plowman wrote:
> On 05/02/2024 13:45, Nuo Mi wrote:
> > On Sun, Feb 4, 2024 at 1:22 AM wrote:
> >
> >> From: Frank Plowman
> >>
> >> Fixes crashes when decoding illegal bitstreams found by fuzzing.
> >>
> >> Signed-off-by: Frank Plowman
> >> ---
> >> libavcodec/vvc/vvc_ctu.c | 17 +++--
> >> 1 file changed, 15 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/libavcodec/vvc/vvc_ctu.c b/libavcodec/vvc/vvc_ctu.c
> >> index d166b16a19..f601c6c95e 100644
> >> --- a/libavcodec/vvc/vvc_ctu.c
> >> +++ b/libavcodec/vvc/vvc_ctu.c
> >> @@ -2207,7 +2207,7 @@ static void hls_sao(VVCLocalContext *lc, const int
> >> rx, const int ry)
> >> }
> >> }
> >>
> >> -static void alf_params(VVCLocalContext *lc, const int rx, const int ry)
> >> +static int alf_params(VVCLocalContext *lc, const int rx, const int ry)
> >> {
> >> const VVCFrameContext *fc = lc->fc;
> >> const H266RawSliceHeader *sh = lc->sc->sh.r;
> >> @@ -2233,6 +2233,11 @@ static void alf_params(VVCLocalContext *lc, const
> >> int rx, const int ry)
> >> c_idx == CB ? sh->sh_alf_cb_enabled_flag :
> >> sh->sh_alf_cr_enabled_flag;
> >> if (alf_enabled_flag) {
> >> const VVCALF *aps =
> >> fc->ps.alf_list[sh->sh_alf_aps_id_chroma];
> >> +if (!aps) {
> >> +// Slice header refers to an APS which does not
> exist
> >> +return AVERROR_INVALIDDATA;
> >> +}
> >> +
> >>
> > Thank you Frank.
> > Since all "if conditions" are related to slices, could we perform the
> check
> > at sh_derive()?
>
> Yes, I had another look at this yesterday and came to the same
> conclusion. Do you think it's better to derive pointers to the relevant
> APSs or just to validate the indices into fps->aps_list?
>
> Check the fps->aps_list[i] should be enough.
Make sure you run all the conformance tests, only conformance tests know
what change is right :)
___
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] libavformat/matroskaenc: reformat options table indentation and descriptions
Clear and consistent formatting enhances code comprehension and reduces the
likelihood of misinterpretation or errors. As is now, it’s challenging to
read. But I digress
Thanks,
On Mon, Feb 5, 2024 at 06:19 Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Marth64:
> > matroskaenc options table has grown packed over time, and is now
> challenging
> > to read. The purpose of this patch is to reformat the table,
> indentation-wise,
> > and to make the capitalization/endings of each description at least
> consistent.
> >
> > I intend to sort the options in a follow-up patch, but wanted to phase
> > this out to be easier to validate.
> >
> > Signed-off-by: Marth64
> > ---
> > libavformat/matroskaenc.c | 42 ++-
> > 1 file changed, 28 insertions(+), 14 deletions(-)
> >
> > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> > index 1457a6890c..2668d1e009 100644
> > --- a/libavformat/matroskaenc.c
> > +++ b/libavformat/matroskaenc.c
> > @@ -3497,20 +3497,34 @@ static const AVCodecTag
> additional_subtitle_tags[] = {
> > #define OFFSET(x) offsetof(MatroskaMuxContext, x)
> > #define FLAGS AV_OPT_FLAG_ENCODING_PARAM
> > static const AVOption options[] = {
> > -{ "reserve_index_space", "Reserve a given amount of space (in
> bytes) at the beginning of the file for the index (cues).",
> OFFSET(reserve_cues_space), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX,
> FLAGS },
> > -{ "cues_to_front", "Move Cues (the index) to the front by shifting
> data if necessary", OFFSET(move_cues_to_front), AV_OPT_TYPE_BOOL, { .i64 =
> 0}, 0, 1, FLAGS },
> > -{ "cluster_size_limit", "Store at most the provided amount of
> bytes in a cluster. ",
> OFFSET(cluster_size_limit), AV_OPT_TYPE_INT , { .i64 = -1 }, -1,
> INT_MAX, FLAGS },
> > -{ "cluster_time_limit", "Store at most the provided number of
> milliseconds in a cluster.",
> OFFSET(cluster_time_limit), AV_OPT_TYPE_INT64, { .i64 = -1 }, -1,
> INT64_MAX, FLAGS },
> > -{ "dash", "Create a WebM file conforming to WebM DASH
> specification", OFFSET(is_dash), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1,
> FLAGS },
> > -{ "dash_track_number", "Track number for the DASH stream",
> OFFSET(dash_track_number), AV_OPT_TYPE_INT, { .i64 = 1 }, 1, INT_MAX, FLAGS
> },
> > -{ "live", "Write files assuming it is a live stream.",
> OFFSET(is_live), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
> > -{ "allow_raw_vfw", "allow RAW VFW mode", OFFSET(allow_raw_vfw),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
> > -{ "flipped_raw_rgb", "Raw RGB bitmaps in VFW mode are stored
> bottom-up", OFFSET(flipped_raw_rgb), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1,
> FLAGS },
> > -{ "write_crc32", "write a CRC32 element inside every Level 1
> element", OFFSET(write_crc), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, FLAGS },
> > -{ "default_mode", "Controls how a track's FlagDefault is inferred",
> OFFSET(default_mode), AV_OPT_TYPE_INT, { .i64 = DEFAULT_MODE_PASSTHROUGH },
> DEFAULT_MODE_INFER, DEFAULT_MODE_PASSTHROUGH, FLAGS, "default_mode" },
> > -{ "infer", "For each track type, mark each track of disposition
> default as default; if none exists, mark the first track as default.", 0,
> AV_OPT_TYPE_CONST, { .i64 = DEFAULT_MODE_INFER }, 0, 0, FLAGS,
> "default_mode" },
> > -{ "infer_no_subs", "For each track type, mark each track of
> disposition default as default; for audio and video: if none exists, mark
> the first track as default.", 0, AV_OPT_TYPE_CONST, { .i64 =
> DEFAULT_MODE_INFER_NO_SUBS }, 0, 0, FLAGS, "default_mode" },
> > -{ "passthrough", "Use the disposition flag as-is", 0,
> AV_OPT_TYPE_CONST, { .i64 = DEFAULT_MODE_PASSTHROUGH }, 0, 0, FLAGS,
> "default_mode" },
> > +{ "reserve_index_space", "Reserve a given amount of space (in
> bytes) at the beginning of the file for the index (cues)",
> > + OFFSET(reserve_cues_space),
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX,FLAGS },
> > +{ "cues_to_front", "Move Cues (the index) to the front by
> shifting data if necessary",
> > + OFFSET(move_cues_to_front),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
> > +{ "cluster_size_limit", "Store at most the provided amount of
> bytes in a cluster",
> > + OFFSET(cluster_size_limit),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,FLAGS },
> > +{ "cluster_time_limit", "Store at most the provided number of
> milliseconds in a cluster",
> > + OFFSET(cluster_time_limit),
> AV_OPT_TYPE_INT64, { .i64 = -1 }, -1, INT64_MAX, FLAGS },
> > +{ "dash","Create a WebM file conforming to WebM
> DASH specification",
> > + OFFSET(is_dash),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
> > +{ "dash_track_number", "Track number for the DASH stream",
> > +
Re: [FFmpeg-devel] [PATCH 6/6 v2] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF
On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote: diff --git a/libavformat/movenc.h b/libavformat/movenc.h index 60363198c9..fee3e759e0 100644 --- a/libavformat/movenc.h +++ b/libavformat/movenc.h @@ -25,7 +25,9 @@ #define AVFORMAT_MOVENC_H #include "avformat.h" +#include "iamf.h" #include "movenccenc.h" +#include "libavcodec/bsf.h" There is no need to include these here, as you don't need complete types. This has the added benefit of forcing you to actually include the files where you are using them (namely in movenc.c, where you forgot to include bsf.h). Ok, fixed locally. Will push the set soon. ___ 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 6/6 v2] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF
James Almer: > On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote: >>> diff --git a/libavformat/movenc.h b/libavformat/movenc.h >>> index 60363198c9..fee3e759e0 100644 >>> --- a/libavformat/movenc.h >>> +++ b/libavformat/movenc.h >>> @@ -25,7 +25,9 @@ >>> #define AVFORMAT_MOVENC_H >>> #include "avformat.h" >>> +#include "iamf.h" >>> #include "movenccenc.h" >>> +#include "libavcodec/bsf.h" >> >> There is no need to include these here, as you don't need complete >> types. This has the added benefit of forcing you to actually include the >> files where you are using them (namely in movenc.c, where you forgot to >> include bsf.h). > > Ok, fixed locally. > > Will push the set soon. It seems you have not noticed my objection to the first version of your set. - 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 6/6 v2] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF
On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote: James Almer: On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote: diff --git a/libavformat/movenc.h b/libavformat/movenc.h index 60363198c9..fee3e759e0 100644 --- a/libavformat/movenc.h +++ b/libavformat/movenc.h @@ -25,7 +25,9 @@ #define AVFORMAT_MOVENC_H #include "avformat.h" +#include "iamf.h" #include "movenccenc.h" +#include "libavcodec/bsf.h" There is no need to include these here, as you don't need complete types. This has the added benefit of forcing you to actually include the files where you are using them (namely in movenc.c, where you forgot to include bsf.h). Ok, fixed locally. Will push the set soon. It seems you have not noticed my objection to the first version of your set. - Andreas Can you link to it? ___ 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/vvc: Validate alf_list indexes
From: Frank Plowman
Signed-off-by: Frank Plowman
---
libavcodec/vvc/vvc_ps.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
index 4ef8f9f9b9..9c4a74fc9c 100644
--- a/libavcodec/vvc/vvc_ps.c
+++ b/libavcodec/vvc/vvc_ps.c
@@ -1005,6 +1005,39 @@ int ff_vvc_decode_aps(VVCParamSets *ps, const
CodedBitstreamUnit *unit)
return ret;
}
+static int sh_alf_aps(VVCSH *sh, const VVCFrameParamSets *fps)
+{
+if (!sh->r->sh_alf_enabled_flag)
+return 0;
+
+for (int i = 0; i < sh->r->sh_num_alf_aps_ids_luma; i++) {
+const VVCALF * alf_aps_luma =
fps->alf_list[sh->r->sh_alf_aps_id_luma[i]];
+if (!alf_aps_luma)
+return AVERROR_INVALIDDATA;
+}
+
+if (sh->r->sh_alf_cb_enabled_flag || sh->r->sh_alf_cr_enabled_flag) {
+const VVCALF* alf_aps_chroma =
fps->alf_list[sh->r->sh_alf_aps_id_chroma];
+if (!alf_aps_chroma)
+return AVERROR_INVALIDDATA;
+}
+
+if (fps->sps->r->sps_ccalf_enabled_flag) {
+if (sh->r->sh_alf_cc_cb_enabled_flag) {
+const VVCALF *alf_aps_cc_cr =
fps->alf_list[sh->r->sh_alf_cc_cb_aps_id];
+if (!alf_aps_cc_cr)
+return AVERROR_INVALIDDATA;
+}
+if (sh->r->sh_alf_cc_cr_enabled_flag) {
+const VVCALF *alf_aps_cc_cr =
fps->alf_list[sh->r->sh_alf_cc_cr_aps_id];
+if (!alf_aps_cc_cr)
+return AVERROR_INVALIDDATA;
+}
+}
+
+return 0;
+}
+
static void sh_slice_address(VVCSH *sh, const H266RawSPS *sps, const VVCPPS
*pps)
{
const int slice_address = sh->r->sh_slice_address;
@@ -1123,8 +1156,12 @@ static int sh_derive(VVCSH *sh, const VVCFrameParamSets
*fps)
const H266RawSPS *sps = fps->sps->r;
const H266RawPPS *pps = fps->pps->r;
const H266RawPictureHeader *ph = fps->ph.r;
+int ret;
sh_slice_address(sh, sps, fps->pps);
+ret = sh_alf_aps(sh, fps);
+if (ret < 0)
+return ret;
sh_inter(sh, sps, pps);
sh_qp_y(sh, pps, ph);
sh_deblock_offsets(sh);
--
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".
Re: [FFmpeg-devel] [PATCH 6/6 v2] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF
James Almer: > On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote: >> James Almer: >>> On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote: > diff --git a/libavformat/movenc.h b/libavformat/movenc.h > index 60363198c9..fee3e759e0 100644 > --- a/libavformat/movenc.h > +++ b/libavformat/movenc.h > @@ -25,7 +25,9 @@ > #define AVFORMAT_MOVENC_H > #include "avformat.h" > +#include "iamf.h" > #include "movenccenc.h" > +#include "libavcodec/bsf.h" There is no need to include these here, as you don't need complete types. This has the added benefit of forcing you to actually include the files where you are using them (namely in movenc.c, where you forgot to include bsf.h). >>> >>> Ok, fixed locally. >>> >>> Will push the set soon. >> >> It seems you have not noticed my objection to the first version of >> your set. >> >> - Andreas > > Can you link to it? Sorry, it was v2: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/320722.html - 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 6/6 v2] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF
On 2/5/2024 12:28 PM, Andreas Rheinhardt wrote: James Almer: On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote: James Almer: On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote: diff --git a/libavformat/movenc.h b/libavformat/movenc.h index 60363198c9..fee3e759e0 100644 --- a/libavformat/movenc.h +++ b/libavformat/movenc.h @@ -25,7 +25,9 @@ #define AVFORMAT_MOVENC_H #include "avformat.h" +#include "iamf.h" #include "movenccenc.h" +#include "libavcodec/bsf.h" There is no need to include these here, as you don't need complete types. This has the added benefit of forcing you to actually include the files where you are using them (namely in movenc.c, where you forgot to include bsf.h). Ok, fixed locally. Will push the set soon. It seems you have not noticed my objection to the first version of your set. - Andreas Can you link to it? Sorry, it was v2: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/320722.html - Andreas I removed the codec list from the split bsf like you asked, and explained what the bsfs do in the documentation. ___ 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] lavc/vvc: Error pps_single_slice_per_subpic_flag
On 03/02/2024 16:56, Nuo Mi wrote:
On Sat, Feb 3, 2024 at 11:51 PM Frank Plowman wrote:
On 03/02/2024 15:46, Nuo Mi wrote:
On Sat, Feb 3, 2024 at 9:54 PM Frank Plowman
wrote:
On 02/02/2024 14:39, Nuo Mi wrote:
On Thu, Feb 1, 2024 at 10:01 PM wrote:
From: Frank Plowman
pps_single_slice_per_subpic_flag is not yet supported. Support is
WIP,
but in the meantime throw an error when trying to decode a bitstream
with it set, avoiding an out-of-bounds array access.
Fixes: out-of-bounds array access for conformance bitstreams
SUBPIC_C_ERICSSON_1, SUBPIC_D_ERICSSON_1, MNUT_A_Nokia_4 and
MNUT_B_Nokia_3.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/vvc_ps.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
index 2cf156b323..bd81d70e71 100644
--- a/libavcodec/vvc/vvc_ps.c
+++ b/libavcodec/vvc/vvc_ps.c
@@ -381,11 +381,16 @@ static void pps_multi_tiles_slice(VVCPPS *pps,
const
int tile_idx, const int i,
}
}
-static void pps_rect_slice(VVCPPS* pps)
+static int pps_rect_slice(VVCPPS* pps)
{
const H266RawPPS* r = pps->r;
int tile_idx = 0, off = 0;
+if (r->pps_single_slice_per_subpic_flag) {
+avpriv_report_missing_feature(NULL,
"pps_single_slice_per_subpic_flag");
+return AVERROR_PATCHWELCOME;
+}
+
for (int i = 0; i < r->pps_num_slices_in_pic_minus1 + 1; i++) {
if (!r->pps_slice_width_in_tiles_minus1[i] &&
!r->pps_slice_height_in_tiles_minus1[i]) {
@@ -396,9 +401,11 @@ static void pps_rect_slice(VVCPPS* pps)
}
tile_idx = next_tile_idx(tile_idx, i, r);
}
+
+return 0;
}
-static void pps_no_rect_slice(VVCPPS* pps)
+static int pps_no_rect_slice(VVCPPS* pps)
{
const H266RawPPS* r = pps->r;
int ctu_x, ctu_y, off = 0;
@@ -409,20 +416,24 @@ static void pps_no_rect_slice(VVCPPS* pps)
pps_add_ctus(pps, &off, ctu_x, ctu_y,
r->col_width_val[tile_x], r->row_height_val[tile_y]);
}
}
+
+return 0;
}
static int pps_slice_map(VVCPPS *pps)
{
+int ret;
+
pps->ctb_addr_in_slice = av_calloc(pps->ctb_count,
sizeof(*pps->ctb_addr_in_slice));
if (!pps->ctb_addr_in_slice)
return AVERROR(ENOMEM);
if (pps->r->pps_rect_slice_flag)
-pps_rect_slice(pps);
+ret = pps_rect_slice(pps);
else
-pps_no_rect_slice(pps);
+ret = pps_no_rect_slice(pps);
-return 0;
+return ret;
}
Thank you Frank. This changed too much code.
How about we only check the sps_num_subpics_minus1 in decode_sps.
I wrote it like this so that the avpriv_report_missing_feature is where
the feature would need to be, helping readability and searchability.
We need to make changes to both the cbs and the decoder for subpic
support.
pps_slice_map is not the first place.
There is nothing strictly missing in the CBS, only the derivation of
NumSlicesInSub needs to be moved which is quite subtle; I think the
putting the error in the parameter set parser is clearer.
How is the patch below as an alternative?
This fixes the single_slice_per_subpic_flag.
But fuzzer may find another subpic-related issue. Highly possible they will
crash too. :)
check sub picture number is a safer way
This issue can cause a crash even with the minimum
{s,p}ps_num_subpics_minus1 = 0 I believe, so this check is needed
regardless. We can add a PATCHWELCOME error if
{s,p}ps_num_subpics_minus1 > 0, but this should be a separate commit.
___
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 6/6 v2] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF
James Almer: > On 2/5/2024 12:28 PM, Andreas Rheinhardt wrote: >> James Almer: >>> On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote: James Almer: > On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote: >>> diff --git a/libavformat/movenc.h b/libavformat/movenc.h >>> index 60363198c9..fee3e759e0 100644 >>> --- a/libavformat/movenc.h >>> +++ b/libavformat/movenc.h >>> @@ -25,7 +25,9 @@ >>> #define AVFORMAT_MOVENC_H >>> #include "avformat.h" >>> +#include "iamf.h" >>> #include "movenccenc.h" >>> +#include "libavcodec/bsf.h" >> >> There is no need to include these here, as you don't need complete >> types. This has the added benefit of forcing you to actually include >> the >> files where you are using them (namely in movenc.c, where you >> forgot to >> include bsf.h). > > Ok, fixed locally. > > Will push the set soon. It seems you have not noticed my objection to the first version of your set. - Andreas >>> >>> Can you link to it? >> >> Sorry, it was v2: >> https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/320722.html >> >> - Andreas > > I removed the codec list from the split bsf like you asked, and > explained what the bsfs do in the documentation. For those few codecs where different framings are common and supported by us, the muxers convert the given framing to the needs of the output format; decoders also support the various framings. This of course only works if they can decide which packetization the input uses; it is possible for the cases we support. If you allow that packets can contain OBU encapsulated data for arbitrary codec ids (even if only intended for a few of them), then this packetization would become officially allowed and we would have to adapt our muxers and decoders accordingly. Which is just not possible, because there is just no information available to base this decision on. There is a second complication with iamf_frame_split_bsf: Up until now, BSFs only passed the stream index value through. But with this BSF the output may have multiple ids even when the input only had one. I am pretty sure that this will surprise and break many users. I don't know whether ffmpeg is among them (if a user inserts the BSF manually). In fact, for this BSF the stream_index that the output packet gets is determined by the offset as well as the packet data alone. The only way for the demuxer to know these numbers is if it has already parsed the packet data before and added streams according to this. Looking at 3/6 it seems that this is indeed what's happening (which is wasteful). But only partially: The iamf_descriptors data is checked and streams are created according to it, but the data read via av_append_packet() is not checked at all. What guarantees that it can't contain IAMF_OBU_IA_AUDIO_ELEMENT elements (which trigger adding new ids and therefore lead to an increment in the potential output stream_index)? Also notice that your 3/6 uses the pkt's stream_index coming out of the BSF without any check. - 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 6/6 v2] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF
On 2/5/2024 1:18 PM, Andreas Rheinhardt wrote: James Almer: On 2/5/2024 12:28 PM, Andreas Rheinhardt wrote: James Almer: On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote: James Almer: On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote: diff --git a/libavformat/movenc.h b/libavformat/movenc.h index 60363198c9..fee3e759e0 100644 --- a/libavformat/movenc.h +++ b/libavformat/movenc.h @@ -25,7 +25,9 @@ #define AVFORMAT_MOVENC_H #include "avformat.h" +#include "iamf.h" #include "movenccenc.h" +#include "libavcodec/bsf.h" There is no need to include these here, as you don't need complete types. This has the added benefit of forcing you to actually include the files where you are using them (namely in movenc.c, where you forgot to include bsf.h). Ok, fixed locally. Will push the set soon. It seems you have not noticed my objection to the first version of your set. - Andreas Can you link to it? Sorry, it was v2: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/320722.html - Andreas I removed the codec list from the split bsf like you asked, and explained what the bsfs do in the documentation. For those few codecs where different framings are common and supported by us, the muxers convert the given framing to the needs of the output format; decoders also support the various framings. This of course only works if they can decide which packetization the input uses; it is possible for the cases we support. If you allow that packets can contain OBU encapsulated data for arbitrary codec ids (even if only intended for a few of them), then this packetization would become officially allowed and we would have to adapt our muxers and decoders accordingly. Which is just not possible, because there is just no information available to base this decision on. So you want me to state that these bsfs should not be used at all by library users, and that they are meant exclusively to be inserted by the mov muxer and demuxer? There is a second complication with iamf_frame_split_bsf: Up until now, BSFs only passed the stream index value through. But with this BSF the output may have multiple ids even when the input only had one. I am pretty sure that this will surprise and break many users. I don't know whether ffmpeg is among them (if a user inserts the BSF manually). This would be addressed by forbidding (or declaring unsupported) the usage of the filters by external callers. In fact, for this BSF the stream_index that the output packet gets is determined by the offset as well as the packet data alone. The only way for the demuxer to know these numbers is if it has already parsed the packet data before and added streams according to this. Looking at 3/6 I think you mean 4/6. it seems that this is indeed what's happening (which is wasteful). But Packets are not being parsed, only the descriptors in the relevant mp4 sample entry. only partially: The iamf_descriptors data is checked and streams are created according to it, but the data read via av_append_packet() is not checked at all. What guarantees that it can't contain IAMF_OBU_IA_AUDIO_ELEMENT elements (which trigger adding new ids and therefore lead to an increment in the potential output stream_index)? Also notice that your 3/6 uses the pkt's stream_index coming out of the BSF without any check. Again 4/6. And i can add a check for stream_index. I could make the split filter only parse descriptors once, and passing them to it immediately after av_bfs_init(), so if packets have descriptors, an error will be returned (The spec disallows descriptors in samples). There's also the bsf's input codecpar extradata. I could use that instead. ___ 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/4] lavf/demux: stop calling avcodec_close()
Quoting Leo Izen (2024-02-03 03:35:45)
> On 2/1/24 03:29, Anton Khirnov wrote:
> > Replace it with recreating the codec context.
> >
> > This is the last remaining blocker for deprecating avcodec_close().
> > ---
> > libavformat/demux.c | 53 -
> > 1 file changed, 48 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavformat/demux.c b/libavformat/demux.c
> > index 6f640b92b1..c1640c459c 100644
> > --- a/libavformat/demux.c
> > +++ b/libavformat/demux.c
> > @@ -1250,6 +1250,52 @@ static int64_t ts_to_samples(AVStream *st, int64_t
> > ts)
> > return av_rescale(ts, st->time_base.num * st->codecpar->sample_rate,
> > st->time_base.den);
> > }
> >
> > +static int codec_close(FFStream *sti)
> > +{
> > +AVCodecContext *avctx_new = NULL;
> > +AVCodecParameters *par_tmp = NULL;
> > +int ret = 0;
> > +
>
> I believe we can drop the initialization from avctx_new and from ret,
> because avctx_new is assigned immediately, and ret is assigned before
> each goto before it's assigned properly.
It's safer wrt future modifications of the code, e.g. if someone would
insert something that could fail before allocating avctx.
--
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 v2 3/4] lavf/demux: stop calling avcodec_close()
Replace it with recreating the codec context.
This is the last remaining blocker for deprecating avcodec_close().
---
Applied review comments.
---
libavformat/demux.c | 61 +
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 6f640b92b1..b70979c520 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -1250,6 +1250,53 @@ static int64_t ts_to_samples(AVStream *st, int64_t ts)
return av_rescale(ts, st->time_base.num * st->codecpar->sample_rate,
st->time_base.den);
}
+static int codec_close(FFStream *sti)
+{
+AVCodecContext *avctx_new = NULL;
+AVCodecParameters *par_tmp = NULL;
+int ret;
+
+avctx_new = avcodec_alloc_context3(sti->avctx->codec);
+if (!avctx_new) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+par_tmp = avcodec_parameters_alloc();
+if (!par_tmp) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+ret = avcodec_parameters_from_context(par_tmp, sti->avctx);
+if (ret < 0)
+goto fail;
+
+ret = avcodec_parameters_to_context(avctx_new, par_tmp);
+if (ret < 0)
+goto fail;
+
+avctx_new->pkt_timebase = sti->avctx->pkt_timebase;
+
+#if FF_API_TICKS_PER_FRAME
+FF_DISABLE_DEPRECATION_WARNINGS
+avctx_new->ticks_per_frame = sti->avctx->ticks_per_frame;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+
+avcodec_free_context(&sti->avctx);
+sti->avctx = avctx_new;
+
+avctx_new = NULL;
+ret = 0;
+
+fail:
+avcodec_free_context(&avctx_new);
+avcodec_parameters_free(&par_tmp);
+
+return ret;
+}
+
static int read_frame_internal(AVFormatContext *s, AVPacket *pkt)
{
FFFormatContext *const si = ffformatcontext(s);
@@ -1286,8 +1333,10 @@ static int read_frame_internal(AVFormatContext *s,
AVPacket *pkt)
if (sti->need_context_update) {
if (avcodec_is_open(sti->avctx)) {
av_log(s, AV_LOG_DEBUG, "Demuxer context update while decoder
is open, closing and trying to re-open\n");
-avcodec_close(sti->avctx);
+ret = codec_close(sti);
sti->info->found_decoder = 0;
+if (ret < 0)
+return ret;
}
/* close parser, because it depends on the codec */
@@ -3013,14 +3062,16 @@ find_stream_info_err:
for (unsigned i = 0; i < ic->nb_streams; i++) {
AVStream *const st = ic->streams[i];
FFStream *const sti = ffstream(st);
+int err;
+
if (sti->info) {
av_freep(&sti->info->duration_error);
av_freep(&sti->info);
}
-avcodec_close(sti->avctx);
-// FIXME: avcodec_close() frees AVOption settable fields which
includes ch_layout,
-//so we need to restore it.
-av_channel_layout_copy(&sti->avctx->ch_layout,
&st->codecpar->ch_layout);
+
+err = codec_close(sti);
+if (err < 0 && ret >= 0)
+ret = err;
av_bsf_free(&sti->extract_extradata.bsf);
}
if (ic->pb) {
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 6/6 v2] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF
James Almer: > On 2/5/2024 1:18 PM, Andreas Rheinhardt wrote: >> James Almer: >>> On 2/5/2024 12:28 PM, Andreas Rheinhardt wrote: James Almer: > On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote: >> James Almer: >>> On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote: > diff --git a/libavformat/movenc.h b/libavformat/movenc.h > index 60363198c9..fee3e759e0 100644 > --- a/libavformat/movenc.h > +++ b/libavformat/movenc.h > @@ -25,7 +25,9 @@ > #define AVFORMAT_MOVENC_H > #include "avformat.h" > +#include "iamf.h" > #include "movenccenc.h" > +#include "libavcodec/bsf.h" There is no need to include these here, as you don't need complete types. This has the added benefit of forcing you to actually include the files where you are using them (namely in movenc.c, where you forgot to include bsf.h). >>> >>> Ok, fixed locally. >>> >>> Will push the set soon. >> >> It seems you have not noticed my objection to the first version of >> your set. >> >> - Andreas > > Can you link to it? Sorry, it was v2: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/320722.html - Andreas >>> >>> I removed the codec list from the split bsf like you asked, and >>> explained what the bsfs do in the documentation. >> >> For those few codecs where different framings are common and supported >> by us, the muxers convert the given framing to the needs of the output >> format; decoders also support the various framings. This of course only >> works if they can decide which packetization the input uses; it is >> possible for the cases we support. >> >> If you allow that packets can contain OBU encapsulated data for >> arbitrary codec ids (even if only intended for a few of them), then this >> packetization would become officially allowed and we would have to adapt >> our muxers and decoders accordingly. Which is just not possible, because >> there is just no information available to base this decision on. > > So you want me to state that these bsfs should not be used at all by > library users, and that they are meant exclusively to be inserted by the > mov muxer and demuxer? > Actually, I don't think that this should be done in a BSF at all. For the reasons outlined above. >> >> There is a second complication with iamf_frame_split_bsf: Up until now, >> BSFs only passed the stream index value through. But with this BSF the >> output may have multiple ids even when the input only had one. I am >> pretty sure that this will surprise and break many users. I don't know >> whether ffmpeg is among them (if a user inserts the BSF manually). > > This would be addressed by forbidding (or declaring unsupported) the > usage of the filters by external callers. > So a BSF for only one caller (lavf)? >> >> In fact, for this BSF the stream_index that the output packet gets is >> determined by the offset as well as the packet data alone. The only way >> for the demuxer to know these numbers is if it has already parsed the >> packet data before and added streams according to this. Looking at 3/6 > > I think you mean 4/6. > >> it seems that this is indeed what's happening (which is wasteful). But > > Packets are not being parsed, only the descriptors in the relevant mp4 > sample entry. > And it happens twice, which is wasteful. >> only partially: The iamf_descriptors data is checked and streams are >> created according to it, but the data read via av_append_packet() is not >> checked at all. What guarantees that it can't contain >> IAMF_OBU_IA_AUDIO_ELEMENT elements (which trigger adding new ids and >> therefore lead to an increment in the potential output stream_index)? >> Also notice that your 3/6 uses the pkt's stream_index coming out of the >> BSF without any check. > > Again 4/6. And i can add a check for stream_index. > I think we should never come in a scenario where this can happen. > I could make the split filter only parse descriptors once, and passing > them to it immediately after av_bfs_init(), so if packets have > descriptors, an error will be returned (The spec disallows descriptors > in samples). > There's also the bsf's input codecpar extradata. I could use that instead. If one were to use a BSF for this, then sending the descriptor via extradata would be the way to go. - 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] fftools/ffmpeg_demux: set stream index right before sending packet to scheduler
This avoids assuming that it survives unchanged through bitstream
filters, if present.
---
fftools/ffmpeg_demux.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 60dc9620c2..3bf95e2c3f 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -475,8 +475,6 @@ static int input_packet_process(Demuxer *d, AVPacket *pkt,
unsigned *send_flags)
av_ts2str(f->ts_offset), av_ts2timestr(f->ts_offset,
&AV_TIME_BASE_Q));
}
-pkt->stream_index = ds->sch_idx_stream;
-
return 0;
}
@@ -505,6 +503,8 @@ static int do_send(Demuxer *d, DemuxStream *ds, AVPacket
*pkt, unsigned flags,
{
int ret;
+pkt->stream_index = ds->sch_idx_stream;
+
ret = sch_demux_send(d->sch, d->f.index, pkt, flags);
if (ret == AVERROR_EOF) {
av_packet_unref(pkt);
@@ -546,7 +546,6 @@ static int demux_send(Demuxer *d, DemuxThreadContext *dt,
DemuxStream *ds,
d->pkt_heartbeat->pts = pkt->pts;
d->pkt_heartbeat->time_base= pkt->time_base;
-d->pkt_heartbeat->stream_index = ds1->sch_idx_stream;
d->pkt_heartbeat->opaque =
(void*)(intptr_t)PKT_OPAQUE_SUB_HEARTBEAT;
ret = do_send(d, ds1, d->pkt_heartbeat, 0, "heartbeat");
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 06/11] fftools/ffmpeg_filter: simplify choose_pix_fmts
On Fri, 12 Jan 2024 22:10:46 +0100 Michael Niedermayer wrote: > On Fri, Jan 12, 2024 at 09:26:03AM +0100, Niklas Haas wrote: > > From: Niklas Haas > > > > The only meaningful difference between choose_pix_fmts and the default > > code was the inclusion of an extra branch for `keep_pix_fmt` being true. > > > > However, in this case, we either: > > 1. Force the specific `ofp->format` that we inherited from > >ofilter_bind_ost, or if no format was set: > > 2. Print an empty format list > > > > Both of these goals can be accomplished by simply moving the decision > > logic to ofilter_bind_ost, to avoid setting any format list when > > keep_pix_fmt is enabled. This is arguably cleaner as it moves format > > selection logic to a single function. In the case of branch 1, nothing > > else needs to be done as we already force the format provided in > > ofp->format, if any is set. Add an assertion to verify this assumption > > just in case. > > > > (Side note: The "choose_*" family of functions are arguably misnomers, > > as they should really be called "print_*" - their current behavior is to > > print the relevant format lists to the `vf/af_format` filter arguments) > > --- > > fftools/ffmpeg_filter.c | 49 - > > 1 file changed, 9 insertions(+), 40 deletions(-) > > > ./ffmpeg -y -i fate-suite/lena.pnm -pix_fmt +yuv444p -vf scale -strict -1 > -bitexact -threads 2 -thread_type slice file-2s-444.jpg > > Assertion !ost->keep_pix_fmt || (!ofp->format && !ofp->formats) failed at > fftools/ffmpeg_filter.c:1240 > Aborted (core dumped) Wrong logic on the assertion, should be: !ost->keep_pix_fmt || ofp->format != AV_PIX_FMT_NONE || !ofp->formats The explanation here is that before this patch, keep_pix_fmt made the filter disregard `ofp->formats` and always choose what was set in `ofp->format` - even if it was NULL. This assertion guarantees that the simplified choose_pix_fmts still does the same thing, since it will hit either the ofp->format being set branch or the ofp->formats being NULL branch. Fixed locally. ___ 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 6/6 v2] avformat/movenc: add support for Immersive Audio Model and Formats in ISOBMFF
On 2/5/2024 2:06 PM, Andreas Rheinhardt wrote: James Almer: On 2/5/2024 1:18 PM, Andreas Rheinhardt wrote: James Almer: On 2/5/2024 12:28 PM, Andreas Rheinhardt wrote: James Almer: On 2/5/2024 12:12 PM, Andreas Rheinhardt wrote: James Almer: On 2/3/2024 11:50 AM, Andreas Rheinhardt wrote: diff --git a/libavformat/movenc.h b/libavformat/movenc.h index 60363198c9..fee3e759e0 100644 --- a/libavformat/movenc.h +++ b/libavformat/movenc.h @@ -25,7 +25,9 @@ #define AVFORMAT_MOVENC_H #include "avformat.h" +#include "iamf.h" #include "movenccenc.h" +#include "libavcodec/bsf.h" There is no need to include these here, as you don't need complete types. This has the added benefit of forcing you to actually include the files where you are using them (namely in movenc.c, where you forgot to include bsf.h). Ok, fixed locally. Will push the set soon. It seems you have not noticed my objection to the first version of your set. - Andreas Can you link to it? Sorry, it was v2: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/320722.html - Andreas I removed the codec list from the split bsf like you asked, and explained what the bsfs do in the documentation. For those few codecs where different framings are common and supported by us, the muxers convert the given framing to the needs of the output format; decoders also support the various framings. This of course only works if they can decide which packetization the input uses; it is possible for the cases we support. If you allow that packets can contain OBU encapsulated data for arbitrary codec ids (even if only intended for a few of them), then this packetization would become officially allowed and we would have to adapt our muxers and decoders accordingly. Which is just not possible, because there is just no information available to base this decision on. So you want me to state that these bsfs should not be used at all by library users, and that they are meant exclusively to be inserted by the mov muxer and demuxer? Actually, I don't think that this should be done in a BSF at all. For the reasons outlined above. I have to disagree. I'm using the packet filtering API to filter packets. Saying that it shouldn't be a bsf because it's mainly useful for internal libav* modules is not a good argument. External users can use it too if they want to, seeing there are lavc users other than lavf, and other mp4 demuxers could benefit from it. And we have bsfs, like vp9_superframe_split, that have virtually no use whatsoever for callers other than our native decoders (even though other decoders could benefit from it too). These are packetizer and depacketizer filters. We're not standardizing any kind of encapsulation for specific codecs other modules will have too look for. There is a second complication with iamf_frame_split_bsf: Up until now, BSFs only passed the stream index value through. But with this BSF the output may have multiple ids even when the input only had one. I am pretty sure that this will surprise and break many users. I don't know whether ffmpeg is among them (if a user inserts the BSF manually). This would be addressed by forbidding (or declaring unsupported) the usage of the filters by external callers. So a BSF for only one caller (lavf)? In fact, for this BSF the stream_index that the output packet gets is determined by the offset as well as the packet data alone. The only way for the demuxer to know these numbers is if it has already parsed the packet data before and added streams according to this. Looking at 3/6 I think you mean 4/6. it seems that this is indeed what's happening (which is wasteful). But Packets are not being parsed, only the descriptors in the relevant mp4 sample entry. And it happens twice, which is wasteful. Muxer and bsf are separate independent modules. It's expected to be the case. only partially: The iamf_descriptors data is checked and streams are created according to it, but the data read via av_append_packet() is not checked at all. What guarantees that it can't contain IAMF_OBU_IA_AUDIO_ELEMENT elements (which trigger adding new ids and therefore lead to an increment in the potential output stream_index)? Also notice that your 3/6 uses the pkt's stream_index coming out of the BSF without any check. Again 4/6. And i can add a check for stream_index. I think we should never come in a scenario where this can happen. I could make the split filter only parse descriptors once, and passing them to it immediately after av_bfs_init(), so if packets have descriptors, an error will be returned (The spec disallows descriptors in samples). There's also the bsf's input codecpar extradata. I could use that instead. If one were to use a BSF for this, then sending the descriptor via extradata would be the way to go. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.
[FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
From: Niklas Haas
This is motivated primarily by a desire for YUVJ removal, which will
require signalling the supported color ranges as part of the codec
capabilities. But since we're adding YUV range, we might as well add the
YUV color matrix as well - since some codecs (e.g. VP8, JPEG) only
support certain values.
I decided to preserve the ambiguous and misleading "color_spaces" name,
for symmetry with AVFrame.colorspace. (Though this would IMO be better
called "color_matrix" or "color_system")
I also decided to omit the other AVColor* fields for now, because
vf_scale cannot handle auto-conversion between primaries/transfer/etc.
There is little value in adding metadata we cannot do anything with, and
no harm in extending the API again in the future. In theory, vf_scale
can handle conversion between chroma locations, but also the signalling
for this is annoying, so I'll defer it to a future commit.
---
doc/APIchanges | 3 +++
libavcodec/codec.h | 6 ++
libavcodec/version.h | 2 +-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 1f5724324a..7849ce47d9 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2024-02-xx - xx - lavc 60.40.100 - avcodec.h
+ Add AVCodec.color_ranges and AVCodec.color_spaces.
+
2024-02-04 - xx - lavc 60.39.100 - packet.h
Add AV_PKT_DATA_AMBIENT_VIEWING_ENVIRONMENT.
diff --git a/libavcodec/codec.h b/libavcodec/codec.h
index 8034f1a53c..8bd678de7a 100644
--- a/libavcodec/codec.h
+++ b/libavcodec/codec.h
@@ -235,6 +235,12 @@ typedef struct AVCodec {
* Array of supported channel layouts, terminated with a zeroed layout.
*/
const AVChannelLayout *ch_layouts;
+
+/**
+ * Array of supported YUV color formats. Ignored for RGB/Gray formats.
+ */
+const enum AVColorRange *color_ranges; ///< terminated by
AVCOL_RANGE_UNSPECIFIED
+const enum AVColorSpace *color_spaces; ///< terminated by
AVCOL_SPC_UNSPECIFIED
} AVCodec;
/**
diff --git a/libavcodec/version.h b/libavcodec/version.h
index f2f14eaed1..19f3f4a272 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include "version_major.h"
-#define LIBAVCODEC_VERSION_MINOR 39
+#define LIBAVCODEC_VERSION_MINOR 40
#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
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 2/2] avcodec: set color_ranges for all video encoders
From: Niklas Haas
I went through all codecs and put them into five basic categories:
1. JPEG range only
2. MPEG range only
3. Explicitly tagged
4. Broken (codec supports both but encoder ignores tags)
5. N/A (headerless or pseudo-formats)
Filters in category 5 remain untouched. The rest gain an explicit
assignment of their supported color ranges, with codecs in category
4 being set to MPEG-only for safety.
It might be considered redundant to assign a list of all possible color
ranges to codecs in category 3, but in doing so we effectively
communicate that we can guarantee that these tags will be encoded, which
is distinct from the situation where there are some codecs that simply
don't have tagging or implied semantics (e.g. rawvideo).
A full list of codecs follows:
JPEG range only:
- amv
- roqvideo
MPEG range only:
- asv1, asv2
- avui
- cfhd
- cljr
- dnxhd
- dvvideo
- ffv1
- flv
- h261, h263, h263p
- {h263,vp8}_v4l2m2m
- huffyuv, ffvhuff
- jpeg2000
- libopenjpeg
- libtheora
- libwebp, libwebp_anim
- libx262
- libxavs, libxavs2
- libxvid
- mpeg1video, mpeg2video
- mpeg2_qsv
- mpeg2_vaapi
- mpeg4, msmpeg4, msmpeg4v2, wmv1, wmv2
- mpeg4_omx
- rv10, rv20
- snow
- speedhq
- svq1
- tiff
- utvideo
Explicitly tagged (MPEG/JPEG):
- {av1,h264,hevc}_nvenc
- {av1,h264,hevc}_vaapi
- {av1,h264,hevc,vp8,vp9,mpeg4}_mediacodec
- {av1,h264,hevc,vp9}_qsv
- h264_amf
- {h264,hevc,prores}_videotoolbox
- libaom-av1
- libkvazaar
- libopenh264
- librav1e
- libsvtav1
- libvpx, libvpx-vp9
- libx264
- libx265
- ljpeg
- mjpeg
- vc2
Broken (encoder ignores tags):
- {av1,hevc}_amf
- {h264,hevc,mpeg4}_v4l2m2m
- h264_omx
- libxeve
- magicyuv
- {vp8,vp9,mjpeg}_vaapi
N/A:
- ayuv, yuv4, y41p, v308, v210, v410, v408 (headerless)
- pgmyuv (headerless)
- prores, prores_aw, prores_ks (?)
- rawvideo, bitpacked (headerless)
- vnull, wrapped_avframe (pseudocodecs)
---
libavcodec/amfenc_av1.c | 1 +
libavcodec/amfenc_h264.c| 1 +
libavcodec/amfenc_hevc.c| 1 +
libavcodec/asvenc.c | 2 ++
libavcodec/avuienc.c| 1 +
libavcodec/cfhdenc.c| 1 +
libavcodec/cljrenc.c| 1 +
libavcodec/codec_internal.h | 4
libavcodec/dnxhdenc.c | 1 +
libavcodec/dvenc.c | 1 +
libavcodec/ffv1enc.c| 1 +
libavcodec/flvenc.c | 1 +
libavcodec/h261enc.c| 1 +
libavcodec/huffyuvenc.c | 2 ++
libavcodec/ituh263enc.c | 2 ++
libavcodec/j2kenc.c | 1 +
libavcodec/libaomenc.c | 1 +
libavcodec/libkvazaar.c | 1 +
libavcodec/libopenh264enc.c | 1 +
libavcodec/libopenjpegenc.c | 1 +
libavcodec/librav1e.c | 1 +
libavcodec/libsvtav1.c | 1 +
libavcodec/libtheoraenc.c | 1 +
libavcodec/libvpxenc.c | 2 ++
libavcodec/libwebpenc.c | 1 +
libavcodec/libwebpenc_animencoder.c | 1 +
libavcodec/libx264.c| 2 ++
libavcodec/libx265.c| 1 +
libavcodec/libxavs.c| 1 +
libavcodec/libxavs2.c | 1 +
libavcodec/libxeve.c| 1 +
libavcodec/libxvid.c| 1 +
libavcodec/ljpegenc.c | 1 +
libavcodec/magicyuvenc.c| 1 +
libavcodec/mediacodecenc.c | 1 +
libavcodec/mjpegenc.c | 2 ++
libavcodec/mpeg12enc.c | 2 ++
libavcodec/mpeg4videoenc.c | 1 +
libavcodec/msmpeg4enc.c | 3 +++
libavcodec/nvenc_av1.c | 1 +
libavcodec/nvenc_h264.c | 1 +
libavcodec/nvenc_hevc.c | 1 +
libavcodec/omx.c| 2 ++
libavcodec/qsvenc_av1.c | 1 +
libavcodec/qsvenc_h264.c| 1 +
libavcodec/qsvenc_hevc.c| 1 +
libavcodec/qsvenc_jpeg.c| 1 +
libavcodec/qsvenc_mpeg2.c | 1 +
libavcodec/qsvenc_vp9.c | 1 +
libavcodec/roqvideoenc.c| 1 +
libavcodec/rv10enc.c| 1 +
libavcodec/rv20enc.c| 1 +
libavcodec/snowenc.c| 1 +
libavcodec/speedhqenc.c | 1 +
libavcodec/svq1enc.c| 1 +
libavcodec/tiffenc.c| 1 +
libavcodec/utils.c | 12
libavcodec/utvideoenc.c | 1 +
libavcodec/v4l2_m2m_enc.c | 1 +
libavcodec/vaapi_encode_av1.c | 1 +
libavcodec/vaapi_encode_h264.c | 1 +
libavcodec/vaapi_encode_h265.c | 1 +
libavcodec/vaapi_encode_mjpeg.c | 1 +
libavcodec/vaapi_encode_mpeg2.c | 1 +
libavcodec/vaapi_encode_vp8.c | 1 +
libavcodec/vaapi_encode_vp9.c | 1 +
libavcodec/vc2enc.c | 3 ++-
libavcodec/videotoolboxenc.c| 2 ++
libavcodec/wmv2enc.c| 1 +
69 fil
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
It would make me happy if we could get this API addition in before 7.0, even though it's non-functional on its own, as it sets the groundwork to be able to start properly deprecating YUVJ. After this series, the next steps are: 1. Make decoders stop outputting YUVJ frames 2. Mark the actual YUVJ pixel formats as deprecated, add a removal API define, and guard internal usages by AV_NOWARN_DEPRECATED 3. After sufficient time passes, remove YUVJ formats fully I have a branch prepared for each. ___ 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] lavc/vvc: Fix slice_idx out-of-bounds memset
From: Frank Plowman
If the number of CTUs reduces between one picture and the next, the
slice_idx table is reduced in size in the frame_context_for_each_tl call
on vvcdec.c:321. When initialising the slice_idx table on vvcdec.c:325,
the old code uses fc->tab.sz.ctu_count when calculating the table size.
fc->tab.sz.ctu_count holds the old ctu count at this point however, not
being updated to hold the new ctu count until vvcdec.c:342. This causes
an out-of-bounds write.
Patch fixes the problem by using pps->ctb_count, which was just used
when allocating the table, in place of fc->tab.sz.ctu_count when
initialising the table.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/vvcdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c
index 1a050600eb..8163b5ecb6 100644
--- a/libavcodec/vvc/vvcdec.c
+++ b/libavcodec/vvc/vvcdec.c
@@ -322,7 +322,7 @@ static int pic_arrays_init(VVCContext *s, VVCFrameContext
*fc)
if (ret < 0)
return ret;
-memset(fc->tab.slice_idx, -1, sizeof(*fc->tab.slice_idx) *
fc->tab.sz.ctu_count);
+memset(fc->tab.slice_idx, -1, sizeof(*fc->tab.slice_idx) * ctu_count);
if (fc->tab.sz.ctu_count != ctu_count) {
ff_refstruct_pool_uninit(&fc->rpl_tab_pool);
--
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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt wrote: > This presumes the relevant states to be a cartesian product. Which need > not be true. A callback would be better; this would also allow to base > the list on other values already set in an AVCodecContext. And if this > were extended, it would also allow to remove init_static_data one day. > It is furthermore quite wasteful to store color_ranges in a list, > although there are only very few states for it. What signature would you propose for such a callback? I disagree with using a list for the range being wasteful. In terms of binary size, they are shared (see ff_color_range_mpeg/jpeg definition). At best you are saving a few bits from using an int bitmask instead of a pointer. The main reason to use a list is API simplicity and consistency. Working with a bitmask is more awkward and would require more specialized code as opposed to the current design which allows simply re-using macros like DEF_CHOOSE_FORMATS in fftools, which is designed to handle lists. Not to mention the equivalent libavfilter API also being list-based. ___ 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] avfilter/buffersink: add color_spaces, color_ranges params
From: Niklas Haas
An oversight in my previous series. This omission slipped under the
radar because fftools/ffmpeg_filter.c did not use these options, instead
preferring to insert an explicit format filter.
---
libavfilter/buffersink.c | 29 ++---
libavfilter/buffersink.h | 2 ++
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 6ba2970dd5..af7f8ab58a 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -48,6 +48,10 @@ typedef struct BufferSinkContext {
/* only used for video */
enum AVPixelFormat *pixel_fmts; ///< list of accepted pixel formats
int pixel_fmts_size;
+enum AVColorSpace *color_spaces;///< list of accepted color spaces
+int color_spaces_size;
+enum AVColorRange *color_ranges;///< list of accepted color ranges
+int color_ranges_size;
/* only used for audio */
enum AVSampleFormat *sample_fmts; ///< list of accepted sample formats
@@ -250,19 +254,36 @@ int av_buffersink_get_ch_layout(const AVFilterContext
*ctx, AVChannelLayout *out
static int vsink_query_formats(AVFilterContext *ctx)
{
BufferSinkContext *buf = ctx->priv;
-AVFilterFormats *formats = NULL;
unsigned i;
int ret;
CHECK_LIST_SIZE(pixel_fmts)
+CHECK_LIST_SIZE(color_spaces)
+CHECK_LIST_SIZE(color_ranges)
if (buf->pixel_fmts_size) {
+AVFilterFormats *formats = NULL;
for (i = 0; i < NB_ITEMS(buf->pixel_fmts); i++)
if ((ret = ff_add_format(&formats, buf->pixel_fmts[i])) < 0)
return ret;
if ((ret = ff_set_common_formats(ctx, formats)) < 0)
return ret;
-} else {
-if ((ret = ff_default_query_formats(ctx)) < 0)
+}
+
+if (buf->color_spaces_size) {
+AVFilterFormats *formats = NULL;
+for (i = 0; i < NB_ITEMS(buf->color_spaces); i++)
+if ((ret = ff_add_format(&formats, buf->color_spaces[i])) < 0)
+return ret;
+if ((ret = ff_set_common_color_spaces(ctx, formats)) < 0)
+return ret;
+}
+
+if (buf->color_ranges_size) {
+AVFilterFormats *formats = NULL;
+for (i = 0; i < NB_ITEMS(buf->color_ranges); i++)
+if ((ret = ff_add_format(&formats, buf->color_ranges[i])) < 0)
+return ret;
+if ((ret = ff_set_common_color_ranges(ctx, formats)) < 0)
return ret;
}
@@ -365,6 +386,8 @@ static int asink_query_formats(AVFilterContext *ctx)
#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
static const AVOption buffersink_options[] = {
{ "pix_fmts", "set the supported pixel formats", OFFSET(pixel_fmts),
AV_OPT_TYPE_BINARY, .flags = FLAGS },
+{ "color_spaces", "set the supported color spaces", OFFSET(color_spaces),
AV_OPT_TYPE_BINARY, .flags = FLAGS },
+{ "color_ranges", "set the supported color ranges", OFFSET(color_ranges),
AV_OPT_TYPE_BINARY, .flags = FLAGS },
{ NULL },
};
#undef FLAGS
diff --git a/libavfilter/buffersink.h b/libavfilter/buffersink.h
index a9374b8b4f..5f7172028d 100644
--- a/libavfilter/buffersink.h
+++ b/libavfilter/buffersink.h
@@ -55,6 +55,8 @@
* The format can be constrained by setting options, using av_opt_set() and
* related functions with the AV_OPT_SEARCH_CHILDREN flag.
* - pix_fmts (int list),
+ * - color_spaces (int list),
+ * - color_ranges (int list),
* - sample_fmts (int list),
* - sample_rates (int list),
* - ch_layouts (string),
--
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 2/2] fftools/ffplay: constrain supported YUV color spaces
From: Niklas Haas
SDL supports only these three matrices. Actually, it only supports these
three combinations: BT.601+JPEG, BT.601+MPEG, BT.709+MPEG, but we have
no way to restrict the specific *combination* of YUV range and YUV
colorspace with the current filter design.
See-Also: https://trac.ffmpeg.org/ticket/10839
Instead of an incorrect conversion result, trying to play a YCgCo file
with ffplay will simply error out with a "No conversion possible" error.
---
fftools/ffplay.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 132f50a5a1..53e6fc0514 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -940,6 +940,13 @@ static int upload_texture(SDL_Texture **tex, AVFrame
*frame)
return ret;
}
+static enum AVColorSpace sdl_supported_color_spaces[] = {
+AVCOL_SPC_BT709,
+AVCOL_SPC_BT470BG,
+AVCOL_SPC_SMPTE170M,
+AVCOL_SPC_UNSPECIFIED,
+};
+
static void set_sdl_yuv_conversion_mode(AVFrame *frame)
{
#if SDL_VERSION_ATLEAST(2,0,8)
@@ -1921,6 +1928,8 @@ static int configure_video_filters(AVFilterGraph *graph,
VideoState *is, const c
if ((ret = av_opt_set_int_list(filt_out, "pix_fmts", pix_fmts,
AV_PIX_FMT_NONE, AV_OPT_SEARCH_CHILDREN)) < 0)
goto fail;
+if ((ret = av_opt_set_int_list(filt_out, "color_spaces",
sdl_supported_color_spaces, AVCOL_SPC_UNSPECIFIED, AV_OPT_SEARCH_CHILDREN)) <
0)
+goto fail;
last_filter = filt_out;
--
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 v10 0/5] webp: add support for animated WebP decoding
From: Thilo Borgmann Still images fixed, includes FATE tests, VP8 decoder not decoupled, fixed more asserts, fixed ffprobe regression, removed unnecessary parser changes, put the whole animated sequence into one packet. Patch 4/6 is still there for making changes in lavc/webp reviewable but shall be stashed when pushing. -Thilo Josef Zlomek (2): libavcodec/webp: add support for animated WebP libavformat/webp: add WebP demuxer Thilo Borgmann (3): avcodec/webp: remove unused definitions avcodec/webp: make init_canvas_frame static fate: add test for animated WebP Changelog | 2 + doc/demuxers.texi | 28 + libavcodec/codec_desc.c | 3 +- libavcodec/version.h| 2 +- libavcodec/webp.c | 698 ++-- libavformat/Makefile| 1 + libavformat/allformats.c| 1 + libavformat/version.h | 2 +- libavformat/webpdec.c | 383 +++ tests/fate/image.mak| 3 + tests/ref/fate/exif-image-webp | 8 +- tests/ref/fate/webp-anim| 22 + tests/ref/fate/webp-rgb-lena-lossless | 2 +- tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- tests/ref/fate/webp-rgb-lossless| 2 +- tests/ref/fate/webp-rgb-lossy-q80 | 2 +- tests/ref/fate/webp-rgba-lossless | 2 +- tests/ref/fate/webp-rgba-lossy-q80 | 2 +- 18 files changed, 1099 insertions(+), 66 deletions(-) create mode 100644 libavformat/webpdec.c create mode 100644 tests/ref/fate/webp-anim -- 2.39.3 (Apple Git-145) ___ 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 v10 1/5] avcodec/webp: remove unused definitions
From: Thilo Borgmann --- libavcodec/webp.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/libavcodec/webp.c b/libavcodec/webp.c index 54b3fde6dc..4fd107aa0c 100644 --- a/libavcodec/webp.c +++ b/libavcodec/webp.c @@ -59,8 +59,6 @@ #define VP8X_FLAG_ALPHA 0x10 #define VP8X_FLAG_ICC 0x20 -#define MAX_PALETTE_SIZE256 -#define MAX_CACHE_BITS 11 #define NUM_CODE_LENGTH_CODES 19 #define HUFFMAN_CODES_PER_META_CODE 5 #define NUM_LITERAL_CODES 256 -- 2.39.3 (Apple Git-145) ___ 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 v10 2/5] libavcodec/webp: add support for animated WebP
From: Josef Zlomek
Fixes: 4907
Adds support for decoding of animated WebP.
The WebP decoder adds the animation related features according to the specs:
https://developers.google.com/speed/webp/docs/riff_container#animation
The frames of the animation may be smaller than the image canvas.
Therefore, the frame is decoded to a temporary frame,
then it is blended into the canvas, the canvas is copied to the output frame,
and finally the frame is disposed from the canvas.
The output to AV_PIX_FMT_YUVA420P/AV_PIX_FMT_YUV420P is still supported.
The background color is specified only as BGRA in the WebP file
so it is converted to YUVA if YUV formats are output.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
libavcodec/codec_desc.c | 3 +-
libavcodec/version.h| 2 +-
libavcodec/webp.c | 704 +---
4 files changed, 654 insertions(+), 56 deletions(-)
diff --git a/Changelog b/Changelog
index c5fb21d198..87f4dbdef4 100644
--- a/Changelog
+++ b/Changelog
@@ -62,6 +62,7 @@ version 6.1:
- ffprobe XML output schema changed to account for multiple
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
+- animated WebP decoder
version 6.0:
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 033344304c..0f72769093 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1259,8 +1259,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
.type = AVMEDIA_TYPE_VIDEO,
.name = "webp",
.long_name = NULL_IF_CONFIG_SMALL("WebP"),
-.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
- AV_CODEC_PROP_LOSSLESS,
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
.mime_types= MT("image/webp"),
},
{
diff --git a/libavcodec/version.h b/libavcodec/version.h
index f2f14eaed1..ecdbc51c74 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -30,7 +30,7 @@
#include "version_major.h"
#define LIBAVCODEC_VERSION_MINOR 39
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 4fd107aa0c..4119ae679d 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -35,12 +35,15 @@
* Exif metadata
* ICC profile
*
+ * @author Josef Zlomek, Pexeso Inc.
+ * Animation
+ *
* Unimplemented:
- * - Animation
* - XMP metadata
*/
#include "libavutil/imgutils.h"
+#include "libavutil/colorspace.h"
#define BITSTREAM_READER_LE
#include "avcodec.h"
@@ -67,6 +70,14 @@
#define NUM_SHORT_DISTANCES 120
#define MAX_HUFFMAN_CODE_LENGTH 15
+#define ANMF_DISPOSAL_METHOD0x01
+#define ANMF_DISPOSAL_METHOD_UNCHANGED 0x00
+#define ANMF_DISPOSAL_METHOD_BACKGROUND 0x01
+
+#define ANMF_BLENDING_METHOD0x02
+#define ANMF_BLENDING_METHOD_ALPHA 0x00
+#define ANMF_BLENDING_METHOD_OVERWRITE 0x02
+
static const uint16_t alphabet_sizes[HUFFMAN_CODES_PER_META_CODE] = {
NUM_LITERAL_CODES + NUM_LENGTH_CODES,
NUM_LITERAL_CODES, NUM_LITERAL_CODES, NUM_LITERAL_CODES,
@@ -191,6 +202,8 @@ typedef struct ImageContext {
typedef struct WebPContext {
VP8Context v; /* VP8 Context used for lossy decoding
*/
GetBitContext gb; /* bitstream reader for main image
chunk */
+ThreadFrame canvas_frame; /* ThreadFrame for canvas */
+AVFrame *frame; /* AVFrame for decoded frame */
AVFrame *alpha_frame; /* AVFrame for alpha data decompressed
from VP8L */
AVPacket *pkt; /* AVPacket to be passed to the
underlying VP8 decoder */
AVCodecContext *avctx; /* parent AVCodecContext */
@@ -204,7 +217,22 @@ typedef struct WebPContext {
int has_iccp; /* set after an ICCP chunk has been
processed */
int width; /* image width */
int height; /* image height */
-int lossless; /* indicates lossless or lossy */
+int vp8x_flags; /* global flags from VP8X chunk */
+int canvas_width; /* canvas width */
+int canvas_height; /* canvas height */
+int anmf_flags; /* frame flags from ANMF chunk */
+int pos_x; /* frame position X */
+int pos_y; /* frame position Y */
+int prev_anmf_flags;/* previous frame flags from ANMF
chunk */
+int prev_width; /* previous frame width */
+int prev_height;/* previous frame height */
+int prev_pos_x;
[FFmpeg-devel] [PATCH v10 4/5] libavformat/webp: add WebP demuxer
From: Josef Zlomek
Adds the demuxer of animated WebP files.
It supports non-animated, animated, truncated, and concatenated files.
Reading from a pipe (and other non-seekable inputs) is also supported.
The WebP demuxer splits the input stream into packets containing one frame.
It also marks the key frames properly.
The loop count is ignored by default (same behaviour as animated PNG and GIF),
it may be enabled by the option '-ignore_loop 0'.
The frame rate is set according to the frame delay in the ANMF chunk.
If the delay is too low, or the image is not animated, the default frame rate
is set to 10 fps, similarly to other WebP libraries and browsers.
The fate suite was updated accordingly.
Signed-off-by: Josef Zlomek
---
Changelog | 1 +
doc/demuxers.texi | 28 ++
libavformat/Makefile| 1 +
libavformat/allformats.c| 1 +
libavformat/version.h | 2 +-
libavformat/webpdec.c | 383
tests/ref/fate/exif-image-webp | 8 +-
tests/ref/fate/webp-rgb-lena-lossless | 2 +-
tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +-
tests/ref/fate/webp-rgb-lossless| 2 +-
tests/ref/fate/webp-rgb-lossy-q80 | 2 +-
tests/ref/fate/webp-rgba-lossless | 2 +-
tests/ref/fate/webp-rgba-lossy-q80 | 2 +-
13 files changed, 425 insertions(+), 11 deletions(-)
create mode 100644 libavformat/webpdec.c
diff --git a/Changelog b/Changelog
index 87f4dbdef4..cbf15f028a 100644
--- a/Changelog
+++ b/Changelog
@@ -63,6 +63,7 @@ version 6.1:
variable-fields elements within the same parent element
- ffprobe -output_format option added as an alias of -of
- animated WebP decoder
+- animated WebP demuxer
version 6.0:
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e4c5b560a6..fcb9f9ee3c 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -943,4 +943,32 @@ which in turn, acts as a ceiling for the size of scripts
that can be read.
Default is 1 MiB.
@end table
+@section webp
+
+Animated WebP demuxer.
+
+It accepts the following options:
+
+@table @option
+@item -min_delay @var{int}
+Set the minimum valid delay between frames in milliseconds.
+Range is 0 to 6. Default value is 10.
+
+@item -max_webp_delay @var{int}
+Set the maximum valid delay between frames in milliseconds.
+Range is 0 to 16777215. Default value is 16777215 (over four hours),
+the maximum value allowed by the specification.
+
+@item -default_delay @var{int}
+Set the default delay between frames in milliseconds.
+Range is 0 to 6. Default value is 100.
+
+@item -ignore_loop @var{bool}
+WebP files can contain information to loop a certain number of times
+(or infinitely). If @option{ignore_loop} is set to true, then the loop
+setting from the input will be ignored and looping will not occur.
+If set to false, then looping will occur and will cycle the number
+of times according to the WebP. Default value is true.
+@end table
+
@c man end DEMUXERS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 05b9b8a115..78ed0977c6 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -622,6 +622,7 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o
matroska.o \
av1.o avlanguage.o
OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o
OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o
+OBJS-$(CONFIG_WEBP_DEMUXER) += webpdec.o
OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index b04b43cab3..c6a2308591 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -506,6 +506,7 @@ extern const AVInputFormat ff_webm_dash_manifest_demuxer;
extern const FFOutputFormat ff_webm_dash_manifest_muxer;
extern const FFOutputFormat ff_webm_chunk_muxer;
extern const FFOutputFormat ff_webp_muxer;
+extern const AVInputFormat ff_webp_demuxer;
extern const AVInputFormat ff_webvtt_demuxer;
extern const FFOutputFormat ff_webvtt_muxer;
extern const AVInputFormat ff_wsaud_demuxer;
diff --git a/libavformat/version.h b/libavformat/version.h
index de9cc8e31d..f4a26c2870 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
#include "version_major.h"
#define LIBAVFORMAT_VERSION_MINOR 20
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
diff --git a/libavformat/webpdec.c b/libavformat/webpdec.c
new file mode 100644
index 00..73c55ee585
--- /dev/null
+++ b/libavformat/webpdec.c
@@ -0,0 +1,383 @@
+/*
+ *
[FFmpeg-devel] [PATCH v10 5/5] fate: add test for animated WebP
From: Thilo Borgmann --- tests/fate/image.mak | 3 +++ tests/ref/fate/webp-anim | 22 ++ 2 files changed, 25 insertions(+) create mode 100644 tests/ref/fate/webp-anim diff --git a/tests/fate/image.mak b/tests/fate/image.mak index 400199c28a..2e0d1e8e3f 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -567,6 +567,9 @@ fate-webp-rgb-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgb_q80.webp FATE_WEBP += fate-webp-rgba-lossy-q80 fate-webp-rgba-lossy-q80: CMD = framecrc -i $(TARGET_SAMPLES)/webp/rgba_q80.webp +FATE_WEBP += fate-webp-anim +fate-webp-anim: CMD = framecrc -i $(TARGET_SAMPLES)/webp/130227-100431-6817p.webp + FATE_WEBP-$(call DEMDEC, IMAGE2, WEBP) += $(FATE_WEBP) FATE_IMAGE_FRAMECRC += $(FATE_WEBP-yes) fate-webp: $(FATE_WEBP-yes) diff --git a/tests/ref/fate/webp-anim b/tests/ref/fate/webp-anim new file mode 100644 index 00..fe7a53a235 --- /dev/null +++ b/tests/ref/fate/webp-anim @@ -0,0 +1,22 @@ +#tb 0: 2/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 100x70 +#sar 0: 0/1 +0, 0, 0,1,28000, 0x2023ba6e +0, 1, 1,1,28000, 0x4292b778 +0, 2, 2,1,28000, 0x9772a187 +0, 3, 3,1,28000, 0x9599bb3b +0, 4, 4,1,28000, 0xa1d6b949 +0, 5, 5,1,28000, 0x153bb9fc +0, 6, 6,1,28000, 0x6ba8d83b +0, 7, 7,1,28000, 0xed2a4316 +0, 8, 8, 12,28000, 0xe7994c44 +0, 21, 21,1,28000, 0x15ec2f76 +0, 22, 22,1,28000, 0x96522a6b +0, 23, 23,1,28000, 0xbbae1e30 +0, 24, 24,1,28000, 0xa2baab83 +0, 25, 25,1,28000, 0x09f1aba0 +0, 26, 26,1,28000, 0x09f1aba0 +0, 27, 27,1,28000, 0xe761bbc0 +0, 28, 28, 125,28000, 0xe761bbc0 -- 2.39.3 (Apple Git-145) ___ 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 v10 3/5] avcodec/webp: make init_canvas_frame static
From: Thilo Borgmann
---
libavcodec/webp.c | 142 +++---
1 file changed, 70 insertions(+), 72 deletions(-)
diff --git a/libavcodec/webp.c b/libavcodec/webp.c
index 4119ae679d..0931112546 100644
--- a/libavcodec/webp.c
+++ b/libavcodec/webp.c
@@ -1358,7 +1358,76 @@ static int vp8_lossy_decode_frame(AVCodecContext *avctx,
AVFrame *p,
return ret;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame);
+static int init_canvas_frame(WebPContext *s, int format, int key_frame)
+{
+AVFrame *canvas = s->canvas_frame.f;
+int height;
+int ret;
+
+// canvas is needed only for animation
+if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
+return 0;
+
+// avoid init for non-key frames whose format and size did not change
+if (!key_frame &&
+canvas->data[0] &&
+canvas->format == format &&
+canvas->width == s->canvas_width &&
+canvas->height == s->canvas_height)
+return 0;
+
+// canvas changes within IPPP sequences will lose thread sync
+// because of the ThreadFrame reallocation and will wait forever
+// so if frame-threading is used, forbid canvas changes and unlock
+// previous frames
+if (!key_frame && canvas->data[0]) {
+if (s->avctx->thread_count > 1) {
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
+// unlock previous frames that have sent an _await() call
+ff_thread_report_progress(&s->canvas_frame, INT_MAX, 0);
+return AVERROR_PATCHWELCOME;
+} else {
+// warn for damaged frames
+av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
+}
+}
+
+s->avctx->pix_fmt = format;
+canvas->format= format;
+canvas->width = s->canvas_width;
+canvas->height= s->canvas_height;
+
+// VP8 decoder changed the width and height in AVCodecContext.
+// Change it back to the canvas size.
+ret = ff_set_dimensions(s->avctx, s->canvas_width, s->canvas_height);
+if (ret < 0)
+return ret;
+
+ff_thread_release_ext_buffer(&s->canvas_frame);
+ret = ff_thread_get_ext_buffer(s->avctx, &s->canvas_frame,
AV_GET_BUFFER_FLAG_REF);
+if (ret < 0)
+return ret;
+
+if (canvas->format == AV_PIX_FMT_ARGB) {
+height = canvas->height;
+memset(canvas->data[0], 0, height * canvas->linesize[0]);
+} else /* if (canvas->format == AV_PIX_FMT_YUVA420P) */ {
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(canvas->format);
+for (int comp = 0; comp < desc->nb_components; comp++) {
+int plane = desc->comp[comp].plane;
+
+if (comp == 1 || comp == 2)
+height = AV_CEIL_RSHIFT(canvas->height, desc->log2_chroma_h);
+else
+height = FFALIGN(canvas->height, 1 << desc->log2_chroma_h);
+
+memset(canvas->data[plane], s->transparent_yuva[plane],
+ height * canvas->linesize[plane]);
+}
+}
+
+return 0;
+}
static int webp_decode_frame_common(AVCodecContext *avctx, uint8_t *data, int
size,
int *got_frame, int key_frame)
@@ -1597,77 +1666,6 @@ exif_end:
return size;
}
-int init_canvas_frame(WebPContext *s, int format, int key_frame)
-{
-AVFrame *canvas = s->canvas_frame.f;
-int height;
-int ret;
-
-// canvas is needed only for animation
-if (!(s->vp8x_flags & VP8X_FLAG_ANIMATION))
-return 0;
-
-// avoid init for non-key frames whose format and size did not change
-if (!key_frame &&
-canvas->data[0] &&
-canvas->format == format &&
-canvas->width == s->canvas_width &&
-canvas->height == s->canvas_height)
-return 0;
-
-// canvas changes within IPPP sequences will loose thread sync
-// because of the ThreadFrame reallocation and will wait forever
-// so if frame-threading is used, forbid canvas changes and unlock
-// previous frames
-if (!key_frame && canvas->data[0]) {
-if (s->avctx->thread_count > 1) {
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged. Use -threads 1 to try decoding with best effort.\n");
-// unlock previous frames that have sent an _await() call
-ff_thread_report_progress(&s->canvas_frame, INT_MAX, 0);
-return AVERROR_PATCHWELCOME;
-} else {
-// warn for damaged frames
-av_log(s->avctx, AV_LOG_WARNING, "Canvas change detected. The
output will be damaged.\n");
-}
-}
-
-s->avctx->pix_fmt = format;
-canvas->format= format;
-canvas->width = s->canvas_width;
-canvas->height= s->canvas_height;
-
-// VP8 decoder changed the width and height in AVCodecContext.
Re: [FFmpeg-devel] [PATCH 2/2] lavc/dxvenc: migrate DXT1 encoder to lavu hashtable
> > How much would one gain if the hash function knew that key_size and > val_size are four? > That yields a nice 10-20% speedup on my machine. Are you thinking of macros to parametrize key/val size, or possibly optimized versions for common sizes? -- Connor Worley ___ 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] Require compilers to support C17.
It should be available in all relevant modern compilers and will allow
us to use features like anonymous unions.
Note that stdatomic.h is still emulated on MSVC, as current versions
require the /experimental:c11atomics, and do not support
ATOMIC_VAR_INIT() anyway.
---
Now moving to C17 rather than C11, as the former contains important
fixes and its support across the compilers we care about should be
similar.
Now also tested with MSVC in wine, thanks to Martin for pointing me at
https://github.com/mstorsjo/msvc-wine
---
configure | 23 +++
doc/developer.texi | 10 ++
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/configure b/configure
index f72533b7d2..1bb9e23f19 100755
--- a/configure
+++ b/configure
@@ -4705,7 +4705,7 @@ msvc_common_flags(){
# generic catch all at the bottom will print the original flag.
-Wall);;
-Wextra) ;;
--std=c*) ;;
+-std=c*) echo /std:${flag#-std=};;
# Common flags
-fomit-frame-pointer) ;;
-g) echo -Z7 ;;
@@ -4750,7 +4750,7 @@ icl_flags(){
# Despite what Intel's documentation says -Wall, which is supported
# on Windows, does enable remarks so disable them here.
-Wall)echo $flag -Qdiag-disable:remark ;;
--std=c99) echo -Qstd=c99 ;;
+-std=c17) echo -Qstd=c17 ;;
-flto*) echo -ipo ;;
esac
done
@@ -4798,7 +4798,7 @@ suncc_flags(){
athlon*) echo -xarch=pentium_proa ;;
esac
;;
--std=c99) echo -xc99 ;;
+-std=c17) echo -xc17 ;;
-fomit-frame-pointer) echo -xregs=frameptr;;
-fPIC)echo -KPIC -xcode=pic32 ;;
-W*,*)echo $flag ;;
@@ -4887,8 +4887,8 @@ probe_cc(){
_type=suncc
_ident=$($_cc -V 2>&1 | head -n1 | cut -d' ' -f 2-)
_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< | sed -e
"1s,^.*: ,$@: ," -e "\$$!s,\$$, \\\," -e "1!s,^.*: , ," > $(@:.o=.d)'
-_DEPFLAGS='-xM1 -xc99'
-_ldflags='-std=c99'
+_DEPFLAGS='-xM1 -xc17'
+_ldflags='-std=c17'
_cflags_speed='-O5'
_cflags_size='-O5 -xspace'
_flags_filter=suncc_flags
@@ -5517,21 +5517,20 @@ if test "$?" != 0; then
die "C compiler test failed."
fi
-add_cppflags -D_ISOC99_SOURCE
+add_cppflags -D_ISOC11_SOURCE
add_cxxflags -D__STDC_CONSTANT_MACROS
check_cxxflags -std=c++11 || check_cxxflags -std=c++0x
-# some compilers silently accept -std=c11, so we also need to check that the
+# some compilers silently accept -std=c17, so we also need to check that the
# version macro is defined properly
-test_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
-add_cflags -std=c11 ||
-check_cflags -std=c99
+test_cflags_cc -std=c17 ctype.h "__STDC_VERSION__ >= 201710L" &&
+add_cflags -std=c17 || die "Compiler lacks C17 support"
check_cppflags -D_FILE_OFFSET_BITS=64
check_cppflags -D_LARGEFILE_SOURCE
-add_host_cppflags -D_ISOC99_SOURCE
-check_host_cflags -std=c99
+add_host_cppflags -D_ISOC11_SOURCE
+check_host_cflags -std=c17
check_host_cflags -Wall
check_host_cflags $host_cflags_speed
diff --git a/doc/developer.texi b/doc/developer.texi
index eed0ee4915..6e9807aa06 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -56,14 +56,8 @@ and should try to fix issues their commit causes.
@section Language
-FFmpeg is mainly programmed in the ISO C99 language, extended with:
-@itemize @bullet
-@item
-Atomic operations from C11 @file{stdatomic.h}. They are emulated on
-architectures/compilers that do not support them, so all FFmpeg-internal code
-may use atomics without any extra checks. However, @file{stdatomic.h} must not
-be included in public headers, so they stay C99-compatible.
-@end itemize
+FFmpeg is mainly programmed in the ISO C17 language, except for the public
+headers which must stay C99 compatible.
Compiler-specific extensions may be used with good reason, but must not be
depended on, i.e. the code must still compile and work with compilers lacking
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] lavc/refstruct: do not use max_align_t on MSVC
From: James Almer
It is not available there, even when C11/17 is requested.
Signed-off-by: Anton Khirnov
---
libavcodec/refstruct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/refstruct.c b/libavcodec/refstruct.c
index 7597f6d0ee..81e8c9795c 100644
--- a/libavcodec/refstruct.c
+++ b/libavcodec/refstruct.c
@@ -45,7 +45,7 @@
#define REFSTRUCT_COOKIE AV_NE((uint64_t)MKBETAG('R', 'e', 'f', 'S') << 32 |
MKBETAG('t', 'r', 'u', 'c'), \
MKTAG('R', 'e', 'f', 'S') |
(uint64_t)MKTAG('t', 'r', 'u', 'c') << 32)
-#if __STDC_VERSION__ >= 201112L
+#if __STDC_VERSION__ >= 201112L && !defined(_MSC_VER)
#define REFCOUNT_OFFSET FFALIGN(sizeof(RefCount), FFMAX3(STRIDE_ALIGN, 16,
_Alignof(max_align_t)))
#else
#define REFCOUNT_OFFSET FFALIGN(sizeof(RefCount), FFMAX(STRIDE_ALIGN, 16))
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] .mailmap: update my mailmap entry
From: Cosmin Stejerean --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 7546cf0caf..cbe6b3ff99 100644 --- a/.mailmap +++ b/.mailmap @@ -22,3 +22,4 @@ rcombs +Cosmin Stejerean Cosmin Stejerean via ffmpeg-devel -- 2.42.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 2/2] lavc/dxvenc: migrate DXT1 encoder to lavu hashtable
Connor Worley: >> >> How much would one gain if the hash function knew that key_size and >> val_size are four? >> > > That yields a nice 10-20% speedup on my machine. Are you thinking of macros > to parametrize key/val size, or possibly optimized versions for common > sizes? I am thinking about it not being public at all; as long as we have only one user... - Andreas PS: Is the speedup only for the hashing part or for overall decoding? Is the comparison the current version of your patch or something that already has my comments incorporated? ___ 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] [mov] Avoid OOM for invalid STCO / CO64 constructions.
On Fri, Feb 02, 2024 at 03:45:24PM -0800, Dale Curtis wrote:
> On Fri, Feb 2, 2024 at 3:42 PM Dale Curtis wrote:
>
> > On Fri, Feb 2, 2024 at 3:20 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Dale Curtis:
> >> > +// Clamp allocation size for `chunk_offsets` -- don't throw an
> >> error for an
> >> > +// invalid count since the EOF path doesn't throw either.
> >> > +entries =
> >> > +FFMIN(entries, FFMIN(atom.size - 8, avio_size(pb) -
> >> avio_tell(pb)) /
> >> > + (atom.type == MKTAG('s', 't', 'c', 'o') ? 4
> >> : 8));
> >> > +
> >>
> >> This may call avio_size() and avio_tell() multiple times. Furthermore,
> >> is it even certain that avio_size() returns a sane value?
> >>
> >
> > I hope so since there are other usages of avio_size() throughout the file
> > in a similar manner. I guess you're saying it may be invalid when
> > !AVIO_SEEKABLE_NORMAL? Sticking to just atom.size is also fine.
> >
>
> Here's a version of the patch which does just that.
> mov.c |7 +++
> 1 file changed, 7 insertions(+)
> d5ba3836202adc762f38f03cbb5e30921e6073b4 stco-clamp-entries-v2.patch
> From b76f526a01788a11e625eb1d7d7005a1959df75c Mon Sep 17 00:00:00 2001
> From: Dale Curtis
> Date: Fri, 2 Feb 2024 20:49:44 +
> Subject: [PATCH] [mov] Avoid OOM for invalid STCO / CO64 constructions.
>
> The `entries` value is read directly from the stream and used to
> allocate memory. This change clamps `entries` to however many are
> possible in the remaining atom or file size (whichever is smallest).
>
> Fixes https://crbug.com/1429357
>
> Signed-off-by: Dale Curtis
> ---
> libavformat/mov.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index af95e1f662..25e5beadcf 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2237,6 +2237,13 @@ static int mov_read_stco(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> av_log(c->fc, AV_LOG_WARNING, "Ignoring duplicated STCO atom\n");
> return 0;
> }
> +
> +// Clamp allocation size for `chunk_offsets` -- don't throw an error for
> an
> +// invalid count since the EOF path doesn't throw either.
> +entries =
> +FFMIN(entries, (atom.size - 8) /
> + (atom.type == MKTAG('s', 't', 'c', 'o') ? 4 : 8));
assuming atom.size is an arbitrary 64bit value
then the value of FFMIN() is also 64bit but entries is unsigned 32bit, this
truncation
would allow setting entries to values outside whats expected from FFMIN()
also we seem to disalllow entries == 0 before this
and its maybe possible to set entries = 0 here, bypassing the == 0 check before
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
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/2] Require compilers to support C17.
On 2/5/2024 4:54 PM, Anton Khirnov wrote:
It should be available in all relevant modern compilers and will allow
us to use features like anonymous unions.
Note that stdatomic.h is still emulated on MSVC, as current versions
require the /experimental:c11atomics, and do not support
ATOMIC_VAR_INIT() anyway.
---
Now moving to C17 rather than C11, as the former contains important
fixes and its support across the compilers we care about should be
similar.
Now also tested with MSVC in wine, thanks to Martin for pointing me at
https://github.com/mstorsjo/msvc-wine
---
configure | 23 +++
doc/developer.texi | 10 ++
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/configure b/configure
index f72533b7d2..1bb9e23f19 100755
--- a/configure
+++ b/configure
@@ -4705,7 +4705,7 @@ msvc_common_flags(){
# generic catch all at the bottom will print the original flag.
-Wall);;
-Wextra) ;;
--std=c*) ;;
+-std=c*) echo /std:${flag#-std=};;
# Common flags
-fomit-frame-pointer) ;;
-g) echo -Z7 ;;
@@ -4750,7 +4750,7 @@ icl_flags(){
# Despite what Intel's documentation says -Wall, which is
supported
# on Windows, does enable remarks so disable them here.
-Wall)echo $flag -Qdiag-disable:remark ;;
--std=c99) echo -Qstd=c99 ;;
+-std=c17) echo -Qstd=c17 ;;
-flto*) echo -ipo ;;
esac
done
@@ -4798,7 +4798,7 @@ suncc_flags(){
athlon*) echo -xarch=pentium_proa ;;
esac
;;
--std=c99) echo -xc99 ;;
+-std=c17) echo -xc17 ;;
Does SunCC support this? Does anyone use SunCC at all?
-fomit-frame-pointer) echo -xregs=frameptr;;
-fPIC)echo -KPIC -xcode=pic32 ;;
-W*,*)echo $flag ;;
@@ -4887,8 +4887,8 @@ probe_cc(){
_type=suncc
_ident=$($_cc -V 2>&1 | head -n1 | cut -d' ' -f 2-)
_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< | sed -e "1s,^.*: ,$@: ," -e
"\$$!s,\$$, \\\," -e "1!s,^.*: , ," > $(@:.o=.d)'
-_DEPFLAGS='-xM1 -xc99'
-_ldflags='-std=c99'
+_DEPFLAGS='-xM1 -xc17'
+_ldflags='-std=c17'
_cflags_speed='-O5'
_cflags_size='-O5 -xspace'
_flags_filter=suncc_flags
@@ -5517,21 +5517,20 @@ if test "$?" != 0; then
die "C compiler test failed."
fi
-add_cppflags -D_ISOC99_SOURCE
+add_cppflags -D_ISOC11_SOURCE
add_cxxflags -D__STDC_CONSTANT_MACROS
check_cxxflags -std=c++11 || check_cxxflags -std=c++0x
-# some compilers silently accept -std=c11, so we also need to check that the
+# some compilers silently accept -std=c17, so we also need to check that the
# version macro is defined properly
-test_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
-add_cflags -std=c11 ||
-check_cflags -std=c99
+test_cflags_cc -std=c17 ctype.h "__STDC_VERSION__ >= 201710L" &&
+add_cflags -std=c17 || die "Compiler lacks C17 support"
check_cppflags -D_FILE_OFFSET_BITS=64
check_cppflags -D_LARGEFILE_SOURCE
-add_host_cppflags -D_ISOC99_SOURCE
-check_host_cflags -std=c99
+add_host_cppflags -D_ISOC11_SOURCE
+check_host_cflags -std=c17
check_host_cflags -Wall
check_host_cflags $host_cflags_speed
diff --git a/doc/developer.texi b/doc/developer.texi
index eed0ee4915..6e9807aa06 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -56,14 +56,8 @@ and should try to fix issues their commit causes.
@section Language
-FFmpeg is mainly programmed in the ISO C99 language, extended with:
-@itemize @bullet
-@item
-Atomic operations from C11 @file{stdatomic.h}. They are emulated on
-architectures/compilers that do not support them, so all FFmpeg-internal code
-may use atomics without any extra checks. However, @file{stdatomic.h} must not
-be included in public headers, so they stay C99-compatible.
-@end itemize
+FFmpeg is mainly programmed in the ISO C17 language, except for the public
+headers which must stay C99 compatible.
Compiler-specific extensions may be used with good reason, but must not be
depended on, i.e. the code must still compile and work with compilers lacking
___
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/2] Require compilers to support C17.
Quoting James Almer (2024-02-05 21:12:00) > Does SunCC support this? Does anyone use SunCC at all? I do not know, but if it doesn't then we can drop 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 2/2] Require compilers to support C17.
On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov wrote: > > It should be available in all relevant modern compilers and will allow > us to use features like anonymous unions. Is everybody on board with the implications for this patch in terms of platforms we allow building on? For example, the gcc on Centos7 doesn't support C17, and that isn't *that* old of a platform. If all the developers agree that we won't support less than Centos8, then so be it. But I think this should be a conscious decision, and we might want to reflect it in the documentation somewhere on what major platforms/versions we expect to be able to build on. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ 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/2] Require compilers to support C17.
Feb 5, 2024, 20:59 by an...@khirnov.net:
> It should be available in all relevant modern compilers and will allow
> us to use features like anonymous unions.
>
> Note that stdatomic.h is still emulated on MSVC, as current versions
> require the /experimental:c11atomics, and do not support
> ATOMIC_VAR_INIT() anyway.
> ---
> Now moving to C17 rather than C11, as the former contains important
> fixes and its support across the compilers we care about should be
> similar.
>
> Now also tested with MSVC in wine, thanks to Martin for pointing me at
> https://github.com/mstorsjo/msvc-wine
> ---
> configure | 23 +++
> doc/developer.texi | 10 ++
> 2 files changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/configure b/configure
> index f72533b7d2..1bb9e23f19 100755
> --- a/configure
> +++ b/configure
> @@ -4705,7 +4705,7 @@ msvc_common_flags(){
> # generic catch all at the bottom will print the original flag.
> -Wall);;
> -Wextra) ;;
> --std=c*) ;;
> +-std=c*) echo /std:${flag#-std=};;
> # Common flags
> -fomit-frame-pointer) ;;
> -g) echo -Z7 ;;
> @@ -4750,7 +4750,7 @@ icl_flags(){
> # Despite what Intel's documentation says -Wall, which is supported
> # on Windows, does enable remarks so disable them here.
> -Wall)echo $flag -Qdiag-disable:remark ;;
> --std=c99) echo -Qstd=c99 ;;
> +-std=c17) echo -Qstd=c17 ;;
> -flto*) echo -ipo ;;
> esac
> done
> @@ -4798,7 +4798,7 @@ suncc_flags(){
> athlon*) echo -xarch=pentium_proa ;;
> esac
> ;;
> --std=c99) echo -xc99 ;;
> +-std=c17) echo -xc17 ;;
> -fomit-frame-pointer) echo -xregs=frameptr;;
> -fPIC)echo -KPIC -xcode=pic32 ;;
> -W*,*)echo $flag ;;
> @@ -4887,8 +4887,8 @@ probe_cc(){
> _type=suncc
> _ident=$($_cc -V 2>&1 | head -n1 | cut -d' ' -f 2-)
> _DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< | sed -e "1s,^.*:
> ,$@: ," -e "\$$!s,\$$, \\\," -e "1!s,^.*: , ," > $(@:.o=.d)'
> -_DEPFLAGS='-xM1 -xc99'
> -_ldflags='-std=c99'
> +_DEPFLAGS='-xM1 -xc17'
> +_ldflags='-std=c17'
> _cflags_speed='-O5'
> _cflags_size='-O5 -xspace'
> _flags_filter=suncc_flags
> @@ -5517,21 +5517,20 @@ if test "$?" != 0; then
> die "C compiler test failed."
> fi
>
> -add_cppflags -D_ISOC99_SOURCE
> +add_cppflags -D_ISOC11_SOURCE
> add_cxxflags -D__STDC_CONSTANT_MACROS
> check_cxxflags -std=c++11 || check_cxxflags -std=c++0x
>
> -# some compilers silently accept -std=c11, so we also need to check that the
> +# some compilers silently accept -std=c17, so we also need to check that the
> # version macro is defined properly
> -test_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" &&
> -add_cflags -std=c11 ||
> -check_cflags -std=c99
> +test_cflags_cc -std=c17 ctype.h "__STDC_VERSION__ >= 201710L" &&
> +add_cflags -std=c17 || die "Compiler lacks C17 support"
>
> check_cppflags -D_FILE_OFFSET_BITS=64
> check_cppflags -D_LARGEFILE_SOURCE
>
> -add_host_cppflags -D_ISOC99_SOURCE
> -check_host_cflags -std=c99
> +add_host_cppflags -D_ISOC11_SOURCE
> +check_host_cflags -std=c17
> check_host_cflags -Wall
> check_host_cflags $host_cflags_speed
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index eed0ee4915..6e9807aa06 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -56,14 +56,8 @@ and should try to fix issues their commit causes.
>
> @section Language
>
> -FFmpeg is mainly programmed in the ISO C99 language, extended with:
> -@itemize @bullet
> -@item
> -Atomic operations from C11 @file{stdatomic.h}. They are emulated on
> -architectures/compilers that do not support them, so all FFmpeg-internal code
> -may use atomics without any extra checks. However, @file{stdatomic.h} must
> not
> -be included in public headers, so they stay C99-compatible.
> -@end itemize
> +FFmpeg is mainly programmed in the ISO C17 language, except for the public
> +headers which must stay C99 compatible.
>
> Compiler-specific extensions may be used with good reason, but must not be
> depended on, i.e. the code must still compile and work with compilers lacking
>
Looks good to me.
___
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/2] Require compilers to support C17.
On Mon, Feb 05, 2024 at 08:54:40PM +0100, Anton Khirnov wrote: > It should be available in all relevant modern compilers and will allow > us to use features like anonymous unions. > > Note that stdatomic.h is still emulated on MSVC, as current versions > require the /experimental:c11atomics, and do not support > ATOMIC_VAR_INIT() anyway. > --- > Now moving to C17 rather than C11, as the former contains important > fixes and its support across the compilers we care about should be > similar. > > Now also tested with MSVC in wine, thanks to Martin for pointing me at > https://github.com/mstorsjo/msvc-wine > --- > configure | 23 +++ > doc/developer.texi | 10 ++ > 2 files changed, 13 insertions(+), 20 deletions(-) please wait a bit with applying this so we understand better what it affects 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/2] Require compilers to support C17.
Quoting Devin Heitmueller (2024-02-05 21:13:22) > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov wrote: > > > > It should be available in all relevant modern compilers and will allow > > us to use features like anonymous unions. > > Is everybody on board with the implications for this patch in terms of > platforms we allow building on? For example, the gcc on Centos7 > doesn't support C17, and that isn't *that* old of a platform. According to Wikipedia, it's almost 10 years old. That counts as *that* old in my book. If someone really needs current ffmpeg on such a platform, they can still build their own compiler or cross-compile. -- 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 2/2] Require compilers to support C17.
Quoting Michael Niedermayer (2024-02-05 21:27:27) > please wait a bit with applying this so we understand better what it affects Sure, but I'd like it to go in before 7.0. -- 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 2/2] Require compilers to support C17.
On 2/5/2024 5:30 PM, Anton Khirnov wrote: Quoting Devin Heitmueller (2024-02-05 21:13:22) On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov wrote: It should be available in all relevant modern compilers and will allow us to use features like anonymous unions. Is everybody on board with the implications for this patch in terms of platforms we allow building on? For example, the gcc on Centos7 doesn't support C17, and that isn't *that* old of a platform. According to Wikipedia, it's almost 10 years old. That counts as *that* old in my book. If someone really needs current ffmpeg on such a platform, they can still build their own compiler or cross-compile. Not to mention EOLd and will stop being maintained in a couple months. ___ 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/2] Require compilers to support C17.
On Mon, Feb 5, 2024 at 3:31 PM Anton Khirnov wrote: > > Quoting Devin Heitmueller (2024-02-05 21:13:22) > > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov wrote: > > > > > > It should be available in all relevant modern compilers and will allow > > > us to use features like anonymous unions. > > > > Is everybody on board with the implications for this patch in terms of > > platforms we allow building on? For example, the gcc on Centos7 > > doesn't support C17, and that isn't *that* old of a platform. > > According to Wikipedia, it's almost 10 years old. That counts as *that* > old in my book. If someone really needs current ffmpeg on such a > platform, they can still build their own compiler or cross-compile. Another way to look at it is that it's what all Centos users used until Centos8 was shipped in September 2019 (i.e. less than five years ago). Now I know that developers *LOVE* to use the latest whizbang language features, but there's a reason that many projects choose to have relatively old minimum language versions. Now, again, if the developer community all agree that it makes sense to stop supporting an operating system that was shipping as recently as five years ago, then so be it. But this sort of deprecation shouldn't simply be the result of a single developer deciding he wants to use anonymous unions (or some other C17 feature) and thus we drop support for a bunch of operating system versions. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ 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/2] Require compilers to support C17.
On Mon, Feb 05, 2024 at 09:31:45PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-02-05 21:27:27) > > please wait a bit with applying this so we understand better what it affects > > Sure, but I'd like it to go in before 7.0. This seems to break my stuff I will upgarde my stuff but that will take time and there are many things ATM like STF deadline and teh release, i have 0 free time IMO you should announce droping support of compilers one release before doing it so people have time to upgrade. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. 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/2] lavc/dxvenc: migrate DXT1 encoder to lavu hashtable
On Mon, Feb 5, 2024 at 12:06 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Connor Worley: > >> > >> How much would one gain if the hash function knew that key_size and > >> val_size are four? > >> > > > > That yields a nice 10-20% speedup on my machine. Are you thinking of > macros > > to parametrize key/val size, or possibly optimized versions for common > > sizes? > > I am thinking about it not being public at all; as long as we have only > one user... > That's fair. I will need some variants for future DXV work, but they can also be private if this doesn't seem generally useful. PS: Is the speedup only for the hashing part or for overall decoding? Is > the comparison the current version of your patch or something that > already has my comments incorporated? > Overall encoding -- current version of my patch with ctx->key/val_size vs hardcoded sizes. -- Connor Worley ___ 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/2] Require compilers to support C17.
On Mon, 05 Feb 2024 15:13:22 -0500 Devin Heitmueller wrote: > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov wrote: > > > > It should be available in all relevant modern compilers and will allow > > us to use features like anonymous unions. > > Is everybody on board with the implications for this patch in terms of > platforms we allow building on? For example, the gcc on Centos7 > doesn't support C17, and that isn't *that* old of a platform. > > If all the developers agree that we won't support less than Centos8, > then so be it. But I think this should be a conscious decision, and > we might want to reflect it in the documentation somewhere on what > major platforms/versions we expect to be able to build on. > > Devin Note that CentOS 7 stopped receiving package updates 4 years ago, and will stop receiving security fixes in a couple of months. So this discussion has an expiry date. I think that having this change negatively affect somebody would require an extremely specific set of circumstances. Most systems running such old distros tend to be headless servers, not generally the type of environment you'd expect somebody to be cloning the latest version of ffmpeg and compiling it from source. And if somebody is committed enough to attempt this anyway, they might as well also compile/download a more up-to-date toolchain. Many of our not-mandatory-but-typically-desirable dependencies are already required at significantly newer versions. (For example, OpenSSL 3.0.0, required for HTTPS, is from 2021) ___ 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/2] Require compilers to support C17.
On Mon, 05 Feb 2024 21:31:45 +0100 Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-02-05 21:27:27) > > please wait a bit with applying this so we understand better what it affects > > Sure, but I'd like it to go in before 7.0. What is the advantage to having it in 7.0? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On date Monday 2024-02-05 21:55:04 +0100, Niklas Haas wrote: > On Mon, 05 Feb 2024 21:31:45 +0100 Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-02-05 21:27:27) > > > please wait a bit with applying this so we understand better what it > > > affects > > > > Sure, but I'd like it to go in before 7.0. > > What is the advantage to having it in 7.0? This would impact negatively many users stucked with older platforms, so I suggest to make this just *after* the next major release to minimize the impact (and I don't see any strong reason to make it happen before). ___ 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] libavformat/matroskaenc: reformat options table indentation and descriptions
On date Monday 2024-02-05 08:32:04 -0600, Marth64 wrote: > Clear and consistent formatting enhances code comprehension and reduces the > likelihood of misinterpretation or errors. As is now, it’s challenging to > read. But I digress +1 > > I do not really see the point of this. It will just interfere with git > > blame when searching for the commit that introduced an option. git blame would still be two keystrokes far rather than one, but most of the times you read the code, not git blame ___ 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/6] avcodec: Remove redundant pix_fmts from decoders
AVCodec.pix_fmts is only intended for encoders (decoders use
the get_format callback to let the user choose a pix fmt).
So remove them for the decoders for which this is possible
without further complications; keep them for now in the codecs
that actually use them (by passing avctx->codec->pix_fmts to
ff_get_formatt()).
Also notice that some of these lists were wrong; e.g.
317b7b06fd97cd39feac7df57db22a30550351ff added support for YUV444P16
for cuviddec, but forgot to add it to pix_fmts.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/crystalhd.c | 1 -
libavcodec/cuviddec.c | 5 -
libavcodec/flashsv.c | 2 --
libavcodec/libdavs2.c | 2 --
libavcodec/libuavs3d.c | 3 ---
libavcodec/qsvdec.c| 11 ---
libavcodec/rkmppdec.c | 2 --
libavcodec/rv10.c | 8
libavcodec/rv30.c | 4
libavcodec/rv40.c | 4
libavcodec/svq1dec.c | 2 --
libavcodec/svq3.c | 2 --
libavcodec/xfacedec.c | 1 -
13 files changed, 47 deletions(-)
diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index 86f6cfa6c1..fb190436f5 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -797,7 +797,6 @@ static int crystalhd_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
AV_CODEC_CAP_HARDWARE, \
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE | \
FF_CODEC_CAP_SETS_FRAME_PROPS, \
-.p.pix_fmts = (const enum AVPixelFormat[]){AV_PIX_FMT_YUYV422,
AV_PIX_FMT_NONE}, \
.p.wrapper_name = "crystalhd", \
};
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index da37207cf2..84edf5c209 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -1174,11 +1174,6 @@ static const AVCodecHWConfigInternal *const
cuvid_hw_configs[] = {
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
AV_CODEC_CAP_HARDWARE, \
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE | \
FF_CODEC_CAP_SETS_FRAME_PROPS, \
-.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_CUDA, \
-AV_PIX_FMT_NV12, \
-AV_PIX_FMT_P010, \
-AV_PIX_FMT_P016, \
-AV_PIX_FMT_NONE }, \
.hw_configs = cuvid_hw_configs, \
.p.wrapper_name = "cuvid", \
};
diff --git a/libavcodec/flashsv.c b/libavcodec/flashsv.c
index 8a01e3a4b6..fe00e529a5 100644
--- a/libavcodec/flashsv.c
+++ b/libavcodec/flashsv.c
@@ -511,7 +511,6 @@ const FFCodec ff_flashsv_decoder = {
FF_CODEC_DECODE_CB(flashsv_decode_frame),
.p.capabilities = AV_CODEC_CAP_DR1,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
-.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_BGR24,
AV_PIX_FMT_NONE },
};
#endif /* CONFIG_FLASHSV_DECODER */
@@ -579,6 +578,5 @@ const FFCodec ff_flashsv2_decoder = {
FF_CODEC_DECODE_CB(flashsv_decode_frame),
.p.capabilities = AV_CODEC_CAP_DR1,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
-.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_BGR24,
AV_PIX_FMT_NONE },
};
#endif /* CONFIG_FLASHSV2_DECODER */
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 179d2f4e4b..5a605c36f6 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -234,7 +234,5 @@ const FFCodec ff_libdavs2_decoder = {
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS,
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
FF_CODEC_CAP_AUTO_THREADS,
-.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
- AV_PIX_FMT_NONE },
.p.wrapper_name = "libdavs2",
};
diff --git a/libavcodec/libuavs3d.c b/libavcodec/libuavs3d.c
index 66e8d31001..f5d47f28ed 100644
--- a/libavcodec/libuavs3d.c
+++ b/libavcodec/libuavs3d.c
@@ -274,8 +274,5 @@ const FFCodec ff_libuavs3d_decoder = {
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
FF_CODEC_CAP_AUTO_THREADS,
.flush = libuavs3d_flush,
-.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
- AV_PIX_FMT_YUV420P10LE,
- AV_PIX_FMT_NONE },
.p.wrapper_name = "libuavs3d",
};
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 559f63698a..812bfd8830 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -1127,17 +1127,6 @@ const FFCodec ff_##x##_qsv_decoder = { \
.bsfs = bsf_name, \
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_DR1 |
AV_CODEC_CAP_AVOID_PROBING | AV_CODEC_CAP_HYBRID, \
.p.priv_class = &x##_qsv_class, \
-.p.pix_f
[FFmpeg-devel] [PATCH 4/6] avcodec/vc1dec: Don't call ff_get_format() twice
It is currently called once in the codecs' init function
and once when (re)initializing the VC-1 decode context
(which happens upon frame size changes as well as before
decoding the first frame). The first one is unnecessary
now that vc1_decode_frame() no longer requires avctx->hwaccel
to be already set for hwaccel to work properly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vc1dec.c | 8
1 file changed, 8 deletions(-)
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 6462a40fd3..4f4aa8aa07 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -691,14 +691,6 @@ static av_cold int vc1_decode_init(AVCodecContext *avctx)
if (v->profile == PROFILE_ADVANCED)
avctx->level = v->level;
-if (!CONFIG_GRAY || !(avctx->flags & AV_CODEC_FLAG_GRAY))
-avctx->pix_fmt = ff_get_format(avctx, avctx->codec->pix_fmts);
-else {
-avctx->pix_fmt = AV_PIX_FMT_GRAY8;
-if (avctx->color_range == AVCOL_RANGE_UNSPECIFIED)
-avctx->color_range = AVCOL_RANGE_MPEG;
-}
-
ff_blockdsp_init(&s->bdsp);
ff_h264chroma_init(&v->h264chroma, 8);
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/6] avcodec/vc1dec: Remove AVCodec.pix_fmts arrays
They are not intended for decoders (for which there is the get_format
callback in case the user has a choice).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vc1dec.c | 64 -
1 file changed, 29 insertions(+), 35 deletions(-)
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 4f4aa8aa07..e71b92eef8 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -72,6 +72,30 @@ typedef struct SpriteData {
int effect_params1[15], effect_params2[10]; ///< effect parameters in
16.16 fixed point format
} SpriteData;
+static const enum AVPixelFormat vc1_hwaccel_pixfmt_list_420[] = {
+#if CONFIG_VC1_DXVA2_HWACCEL
+AV_PIX_FMT_DXVA2_VLD,
+#endif
+#if CONFIG_VC1_D3D11VA_HWACCEL
+AV_PIX_FMT_D3D11VA_VLD,
+AV_PIX_FMT_D3D11,
+#endif
+#if CONFIG_VC1_D3D12VA_HWACCEL
+AV_PIX_FMT_D3D12,
+#endif
+#if CONFIG_VC1_NVDEC_HWACCEL
+AV_PIX_FMT_CUDA,
+#endif
+#if CONFIG_VC1_VAAPI_HWACCEL
+AV_PIX_FMT_VAAPI,
+#endif
+#if CONFIG_VC1_VDPAU_HWACCEL
+AV_PIX_FMT_VDPAU,
+#endif
+AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_NONE
+};
+
static inline int get_fp_val(GetBitContext* gb)
{
return (get_bits_long(gb, 30) - (1 << 29)) << 1;
@@ -417,7 +441,11 @@ static enum AVPixelFormat vc1_get_format(AVCodecContext
*avctx)
return AV_PIX_FMT_GRAY8;
}
-return ff_get_format(avctx, avctx->codec->pix_fmts);
+if (avctx->codec_id == AV_CODEC_ID_VC1IMAGE ||
+avctx->codec_id == AV_CODEC_ID_WMV3IMAGE)
+return AV_PIX_FMT_YUV420P;
+
+return ff_get_format(avctx, vc1_hwaccel_pixfmt_list_420);
}
av_cold int ff_vc1_decode_init(AVCodecContext *avctx)
@@ -1354,30 +1382,6 @@ err:
}
-static const enum AVPixelFormat vc1_hwaccel_pixfmt_list_420[] = {
-#if CONFIG_VC1_DXVA2_HWACCEL
-AV_PIX_FMT_DXVA2_VLD,
-#endif
-#if CONFIG_VC1_D3D11VA_HWACCEL
-AV_PIX_FMT_D3D11VA_VLD,
-AV_PIX_FMT_D3D11,
-#endif
-#if CONFIG_VC1_D3D12VA_HWACCEL
-AV_PIX_FMT_D3D12,
-#endif
-#if CONFIG_VC1_NVDEC_HWACCEL
-AV_PIX_FMT_CUDA,
-#endif
-#if CONFIG_VC1_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI,
-#endif
-#if CONFIG_VC1_VDPAU_HWACCEL
-AV_PIX_FMT_VDPAU,
-#endif
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_NONE
-};
-
const FFCodec ff_vc1_decoder = {
.p.name = "vc1",
CODEC_LONG_NAME("SMPTE VC-1"),
@@ -1389,7 +1393,6 @@ const FFCodec ff_vc1_decoder = {
FF_CODEC_DECODE_CB(vc1_decode_frame),
.flush = ff_mpeg_flush,
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,
-.p.pix_fmts = vc1_hwaccel_pixfmt_list_420,
.hw_configs = (const AVCodecHWConfigInternal *const []) {
#if CONFIG_VC1_DXVA2_HWACCEL
HWACCEL_DXVA2(vc1),
@@ -1429,7 +1432,6 @@ const FFCodec ff_wmv3_decoder = {
FF_CODEC_DECODE_CB(vc1_decode_frame),
.flush = ff_mpeg_flush,
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,
-.p.pix_fmts = vc1_hwaccel_pixfmt_list_420,
.hw_configs = (const AVCodecHWConfigInternal *const []) {
#if CONFIG_WMV3_DXVA2_HWACCEL
HWACCEL_DXVA2(wmv3),
@@ -1470,10 +1472,6 @@ const FFCodec ff_wmv3image_decoder = {
FF_CODEC_DECODE_CB(vc1_decode_frame),
.p.capabilities = AV_CODEC_CAP_DR1,
.flush = vc1_sprite_flush,
-.p.pix_fmts = (const enum AVPixelFormat[]) {
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_NONE
-},
};
#endif
@@ -1489,9 +1487,5 @@ const FFCodec ff_vc1image_decoder = {
FF_CODEC_DECODE_CB(vc1_decode_frame),
.p.capabilities = AV_CODEC_CAP_DR1,
.flush = vc1_sprite_flush,
-.p.pix_fmts = (const enum AVPixelFormat[]) {
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_NONE
-},
};
#endif
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/6] avcodec/h263dec: Remove AVCodec.pix_fmts arrays
They are not intended for decoders (for which there is the get_format
callback in case the user has a choice).
Also note that the list was wrong for MPEG4, because it did not contain
the high bit depth pixel formats used for studio profiles.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/flvdec.c| 2 --
libavcodec/h263dec.c | 43 --
libavcodec/h263dec.h | 2 --
libavcodec/intelh263dec.c | 4
libavcodec/mpeg4videodec.c | 1 -
libavcodec/msmpeg4dec.c| 16 --
libavcodec/wmv2dec.c | 2 --
7 files changed, 23 insertions(+), 47 deletions(-)
diff --git a/libavcodec/flvdec.c b/libavcodec/flvdec.c
index 09fefd3d1c..8baaed06a8 100644
--- a/libavcodec/flvdec.c
+++ b/libavcodec/flvdec.c
@@ -123,6 +123,4 @@ const FFCodec ff_flv_decoder = {
.p.capabilities = AV_CODEC_CAP_DRAW_HORIZ_BAND | AV_CODEC_CAP_DR1,
.caps_internal = FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM,
.p.max_lowres = 3,
-.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
- AV_PIX_FMT_NONE },
};
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index eb1d87a2fe..910df7585f 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -49,6 +49,23 @@
#include "thread.h"
#include "wmv2dec.h"
+static const enum AVPixelFormat h263_hwaccel_pixfmt_list_420[] = {
+#if CONFIG_H263_VAAPI_HWACCEL || CONFIG_MPEG4_VAAPI_HWACCEL
+AV_PIX_FMT_VAAPI,
+#endif
+#if CONFIG_MPEG4_NVDEC_HWACCEL
+AV_PIX_FMT_CUDA,
+#endif
+#if CONFIG_MPEG4_VDPAU_HWACCEL
+AV_PIX_FMT_VDPAU,
+#endif
+#if CONFIG_H263_VIDEOTOOLBOX_HWACCEL || CONFIG_MPEG4_VIDEOTOOLBOX_HWACCEL
+AV_PIX_FMT_VIDEOTOOLBOX,
+#endif
+AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_NONE
+};
+
static enum AVPixelFormat h263_get_format(AVCodecContext *avctx)
{
/* MPEG-4 Studio Profile only, not supported by hardware */
@@ -63,7 +80,12 @@ static enum AVPixelFormat h263_get_format(AVCodecContext
*avctx)
return AV_PIX_FMT_GRAY8;
}
-return avctx->pix_fmt = ff_get_format(avctx, avctx->codec->pix_fmts);
+if (avctx->codec_id == AV_CODEC_ID_H263 ||
+avctx->codec_id == AV_CODEC_ID_H263P ||
+avctx->codec_id == AV_CODEC_ID_MPEG4)
+return avctx->pix_fmt = ff_get_format(avctx,
h263_hwaccel_pixfmt_list_420);
+
+return AV_PIX_FMT_YUV420P;
}
av_cold int ff_h263_decode_init(AVCodecContext *avctx)
@@ -659,23 +681,6 @@ frame_end:
return get_consumed_bytes(s, buf_size);
}
-const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[] = {
-#if CONFIG_H263_VAAPI_HWACCEL || CONFIG_MPEG4_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI,
-#endif
-#if CONFIG_MPEG4_NVDEC_HWACCEL
-AV_PIX_FMT_CUDA,
-#endif
-#if CONFIG_MPEG4_VDPAU_HWACCEL
-AV_PIX_FMT_VDPAU,
-#endif
-#if CONFIG_H263_VIDEOTOOLBOX_HWACCEL || CONFIG_MPEG4_VIDEOTOOLBOX_HWACCEL
-AV_PIX_FMT_VIDEOTOOLBOX,
-#endif
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_NONE
-};
-
static const AVCodecHWConfigInternal *const h263_hw_config_list[] = {
#if CONFIG_H263_VAAPI_HWACCEL
HWACCEL_VAAPI(h263),
@@ -706,7 +711,6 @@ const FFCodec ff_h263_decoder = {
.caps_internal = FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM,
.flush = ff_mpeg_flush,
.p.max_lowres = 3,
-.p.pix_fmts = ff_h263_hwaccel_pixfmt_list_420,
.hw_configs = h263_hw_config_list,
};
@@ -724,6 +728,5 @@ const FFCodec ff_h263p_decoder = {
.caps_internal = FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM,
.flush = ff_mpeg_flush,
.p.max_lowres = 3,
-.p.pix_fmts = ff_h263_hwaccel_pixfmt_list_420,
.hw_configs = h263_hw_config_list,
};
diff --git a/libavcodec/h263dec.h b/libavcodec/h263dec.h
index 06ff7c1c48..89c5fcf58f 100644
--- a/libavcodec/h263dec.h
+++ b/libavcodec/h263dec.h
@@ -38,8 +38,6 @@ extern VLCElem ff_h263_inter_MCBPC_vlc[];
extern VLCElem ff_h263_cbpy_vlc[];
extern VLCElem ff_h263_mv_vlc[];
-extern const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[];
-
int ff_h263_decode_motion(MpegEncContext * s, int pred, int f_code);
int ff_h263_decode_init(AVCodecContext *avctx);
int ff_h263_decode_frame(AVCodecContext *avctx, AVFrame *frame,
diff --git a/libavcodec/intelh263dec.c b/libavcodec/intelh263dec.c
index 2c216b00a6..f8eeb6b44e 100644
--- a/libavcodec/intelh263dec.c
+++ b/libavcodec/intelh263dec.c
@@ -138,8 +138,4 @@ const FFCodec ff_h263i_decoder = {
FF_CODEC_DECODE_CB(ff_h263_decode_frame),
.p.capabilities = AV_CODEC_CAP_DRAW_HORIZ_BAND | AV_CODEC_CAP_DR1,
.caps_internal = FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM,
-.p.pix_fmts = (const enum AVPixelFormat[]) {
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_NONE
-},
};
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 65d4bf429b..07de5d6d91 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -3865,7 +3865,6 @@ const FFCodec ff_mpeg4_decoder = {
[FFmpeg-devel] [PATCH 3/6] avcodec/vc1dec: Set pointers for hwaccel even without hwaccel
VC-1 uses a 0x03 escaping scheme like H.26x and our decoder
unescapes data for this purpose, but hardware accelerations
just want the data as-is and therefore get fed the original
data. The pointers to the actual data are only setcorrectly
if avctx->hwaccel is set (after all, they are only used in
this case).
There are two problems with this: The first is that the branch
is pointless; the second is that it is harmful, because
a hardware acceleration may be added after the packet has been
parsed (in case there is a reconfiguration e.g. due to frame
size changes) in which case decoding the first few frames
won't work.
So delete these branches.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vc1dec.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 6eff2ec04c..6462a40fd3 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -846,14 +846,12 @@ static int vc1_decode_frame(AVCodecContext *avctx,
AVFrame *pict,
if (size <= 0) continue;
switch (AV_RB32(start)) {
case VC1_CODE_FRAME:
-if (avctx->hwaccel)
-buf_start = start;
+buf_start = start;
buf_size2 = v->vc1dsp.vc1_unescape_buffer(start + 4, size,
buf2);
break;
case VC1_CODE_FIELD: {
int buf_size3;
-if (avctx->hwaccel)
-buf_start_second_field = start;
+buf_start_second_field = start;
av_size_mult(sizeof(*slices), n_slices+1, &next_allocated);
tmp = next_allocated ? av_fast_realloc(slices,
&slices_allocated, next_allocated) : NULL;
if (!tmp) {
@@ -918,8 +916,7 @@ static int vc1_decode_frame(AVCodecContext *avctx, AVFrame
*pict,
ret = AVERROR_INVALIDDATA;
goto err;
} else { // found field marker, unescape second field
-if (avctx->hwaccel)
-buf_start_second_field = divider;
+buf_start_second_field = divider;
av_size_mult(sizeof(*slices), n_slices+1, &next_allocated);
tmp = next_allocated ? av_fast_realloc(slices,
&slices_allocated, next_allocated) : NULL;
if (!tmp) {
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/6] avcodec/mmaldec: Avoid using AVCodec.pix_fmts
It is entirely unnecessary to use it given that all decoders
here share the same set of supported pixel formats. So just
hardcode this list.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mmaldec.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 2dc7bbee04..a8cda27570 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -101,6 +101,10 @@ typedef struct MMALDecodeContext {
// packets (where each packet contains 1 frame).
#define MAX_DELAYED_FRAMES 16
+static const enum AVPixelFormat mmal_pixfmts[] = {
+AV_PIX_FMT_MMAL, AV_PIX_FMT_YUV420P, AV_PIX_FMT_NONE
+};
+
static void ffmmal_poolref_unref(FFPoolRef *ref)
{
if (ref &&
@@ -367,7 +371,7 @@ static av_cold int ffmmal_init_decoder(AVCodecContext
*avctx)
return AVERROR(ENOSYS);
}
-if ((ret = ff_get_format(avctx, avctx->codec->pix_fmts)) < 0)
+if ((ret = ff_get_format(avctx, mmal_pixfmts)) < 0)
return ret;
avctx->pix_fmt = ret;
@@ -844,9 +848,6 @@ static const AVClass ffmmal_dec_class = {
.p.priv_class = &ffmmal_dec_class, \
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_HARDWARE, \
.caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE, \
-.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_MMAL, \
- AV_PIX_FMT_YUV420P, \
- AV_PIX_FMT_NONE}, \
.hw_configs = mmal_hw_configs, \
.p.wrapper_name = "mmal", \
};
--
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] Sovereign Tech Fund
This is the courtesy reminder we've agreed on, to remember there's a week left to finish the Scope of Work if FFmpeg wishes to deliver it by February 12th as requested by STF. Att., Jonatas L. Nogueira (“Jesusalva”) SPI Board of Directors On Wed, Jan 31, 2024, 21:16 Stefano Sabatini wrote: > On date Thursday 2024-02-01 00:15:03 +0100, Stefano Sabatini wrote: > > José already provided and excellent summary from his side. On my side > > I meant Jonatas, sorry. > ___ 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] lavc/cbs_av1: fill in ref_frame_sign_bias
Feb 4, 2024, 17:06 by s...@jkqxz.net:
> On 02/02/2024 02:57, Lynne wrote:
>
>> Needed for AV1.
>>
>> From 81be215060a718fdc3d043847e8155ba56fcb431 Mon Sep 17 00:00:00 2001
>> From: Lynne
>> Date: Fri, 2 Feb 2024 03:54:06 +0100
>> Subject: [PATCH 1/2] lavc/cbs_av1: fill in ref_frame_sign_bias
>>
>> Needed for AV1.
>> ---
>> libavcodec/cbs_av1.h | 1 +
>> libavcodec/cbs_av1_syntax_template.c | 10 ++
>> 2 files changed, 11 insertions(+)
>>
>> diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
>> index a5402f069d..cbb43ac810 100644
>> --- a/libavcodec/cbs_av1.h
>> +++ b/libavcodec/cbs_av1.h
>> @@ -198,6 +198,7 @@ typedef struct AV1RawFrameHeader {
>> uint8_t refresh_frame_flags;
>> uint8_t allow_intrabc;
>> uint8_t ref_order_hint[AV1_NUM_REF_FRAMES];
>> +uint8_t ref_frame_sign_bias[AV1_NUM_REF_FRAMES];
>>
>
> This isn't a syntax element so it shouldn't go in the syntax structure. Put
> it in the context structure with other derived fields (the pointer is already
> available as priv where you want it).
>
>> uint8_t frame_refs_short_signaling;
>> uint8_t last_frame_idx;
>> uint8_t golden_frame_idx;
>> diff --git a/libavcodec/cbs_av1_syntax_template.c
>> b/libavcodec/cbs_av1_syntax_template.c
>> index 3be1f2d30f..00e9a6d030 100644
>> --- a/libavcodec/cbs_av1_syntax_template.c
>> +++ b/libavcodec/cbs_av1_syntax_template.c
>> @@ -1572,6 +1572,16 @@ static int
>> FUNC(uncompressed_header)(CodedBitstreamContext *ctx, RWContext *rw,
>> }
>>
>> if (!frame_is_intra) {
>> +for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
>> +if (seq->enable_order_hint) {
>> +int idx = current->ref_frame_idx[i];
>> +int hint = current->ref_order_hint[idx];
>> +current->ref_frame_sign_bias[i] =
>> cbs_av1_get_relative_dist(seq, hint,
>> +
>> priv->order_hint) > 0;
>> +} else {
>> +infer(ref_frame_sign_bias[i], 0);
>> +}
>> +}
>> // Derive reference frame sign biases.
>> }
>>
>> --
>> 2.43.0.381.gb435a96ce8
>>
>
> Please exactly follow the layout of the specification as far as possible,
> since that makes it much easier to assess whether it is correct. It looks
> like the indexing is wrong? (Note that LAST_FRAME == 1.)
>
It is the layout of the specifications. I just skip filling in the reorder hints
since they're not really needed (it's just a lookup after all).
___
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] avfilter/signature_lookup: dont leave uncleared pointers in sll_free()
On Mon, Feb 05, 2024 at 12:51:57PM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavfilter/signature_lookup.c | 21 ++---
> > 1 file changed, 10 insertions(+), 11 deletions(-)
> >
> > diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
> > index 86dd0c66754..52a97e1bc7e 100644
> > --- a/libavfilter/signature_lookup.c
> > +++ b/libavfilter/signature_lookup.c
> > @@ -37,6 +37,15 @@
> > #define STATUS_END_REACHED 1
> > #define STATUS_BEGIN_REACHED 2
> >
> > +static void sll_free(MatchingInfo **sll)
> > +{
> > +while (*sll) {
> > +MatchingInfo *tmp = *sll;
> > +*sll = (*sll)->next;
> > +av_free(tmp);
> > +}
>
> This does not clear the pointers at all. This does (and avoids
> indirections).
>
> static void sll_free(MatchingInfo **sllp)
> {
> MatchingInfo *sll = *sllp;
>
> *sllp = NULL;
> while (sll) {
> MatchingInfo *tmp = sll;
> sll = sll->next;
> av_free(tmp);
> }
> }
I tried it with code below, but your code is not different from mine in
behavior just more complex
output:
(nil) 0x560e8daad2c0 (nil)
vs.
(nil) 0x557ae6e472c0 (nil)
sll_free_n2() is simpler and will clear all, the reason i did not
propose it, is its recursive and can hit stack space limits in principle
sll_free_n3() and sll_free_n4() are other options that will clear all
but maybe every choice contains bugs, i didnt really test them with more than
one testcase
---
#include
#include
#include
#define FFSWAP(type,a,b) do{type SWAP_tmp= b; b= a; a= SWAP_tmp;}while(0)
static void av_free(void *ptr)
{
free(ptr);
}
static void av_freep(void *arg)
{
void *val;
memcpy(&val, arg, sizeof(val));
memcpy(arg, &(void *){ NULL }, sizeof(val));
av_free(val);
}
typedef struct MatchingInfo {
struct MatchingInfo *next;
} MatchingInfo;
static void sll_free_n(MatchingInfo **sll)
{
while (*sll) {
MatchingInfo *tmp = *sll;
*sll = (*sll)->next;
av_free(tmp);
}
}
static void sll_free_n2(MatchingInfo **sll)
{
if (*sll)
sll_free_n(&(*sll)->next);
av_freep(sll);
}
static void sll_free_n3(MatchingInfo **sll)
{
while (*sll) {
MatchingInfo *tmp = *sll;
*sll = tmp->next;
tmp->next = NULL;
av_free(tmp);
}
}
static void sll_free_n4(MatchingInfo **sll)
{
MatchingInfo *tmp = NULL;
while (*sll) {
FFSWAP(MatchingInfo *, tmp, (*sll)->next);
av_freep(sll);
FFSWAP(MatchingInfo *, tmp, *sll);
}
}
static void sll_free_r(MatchingInfo **sllp)
{
MatchingInfo *sll = *sllp;
*sllp = NULL;
while (sll) {
MatchingInfo *tmp = sll;
sll = sll->next;
av_free(tmp);
}
}
main() {
MatchingInfo *mi, *m1, *m2;
m1 = mi = malloc(sizeof(MatchingInfo));
m2 = mi->next = malloc(sizeof(MatchingInfo));
m2->next= NULL;
sll_free_r(&mi);
printf("%p %p %p\n", mi, m1->next, m2->next);
}
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
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] STF SoWs
Hi all As Jonatan reminded the ML we need to provide SoWs if we want to participate in STF-SPI We need one for each project (they do not need to list a person ATM) but obviously we do need someone who will do the work I do belive they do need to list the money amount. Thanks go to Pierre for helping me write template/example. (converted from google docs and with some last minute edits) @Jonatan, is this below what SPI needs for each project ? STF SOW template 1. One line summary of the proposed work Classify and fix outstanding issues identified by Coverity 2. Description of the work Coverity is a static code analysis system that is used to analyze FFmpeg code to find bugs with an emphasis on quality and security issues. There are currently 677 outstanding issues identified by Coverity (https://scan.coverity.com/projects/ffmpeg?tab=overview). Some of these issues are false positives while others could open the door to security vulnerabilities. The objective of this work is to identify the Coverity issues that are not false positives, and fix as many as possible. 3. Milestones 1. Milestone 1 1. Description Review all outstanding Coverity issues and, for each one, determine whether it is a false positive. 2. Deliverables List of both false positive and potentially real issues posted to the FFMPEG dev mailing list. 3. Compensation X euros 2. Milestone 2 1. Description Fix 50% of the outstanding real issues 2. Deliverables Patches submitted for review to the FFMPEG dev mailing list. 3. Compensation X euros 3. Milestone 3 1. Description Fix 45% of the remaining outstanding real issues. The total number of issues addressed by Milestones 2 and 3 do not total 100% to account for issues that are not practical to fix within the scope of this SOW and are deferred to future work. 2. Deliverables Patches submitted for review to the FFMPEG dev mailing list. 3. Compensation X euros 4. Developer(s) Michael Niedermayer I work in Austria, and have been an active contributor to FFmpeg since 2001 – 22308 commits so far. My work on FFMPEG is regularly supported by third parties and I am one of the founders of fflabs. I am also familiar with Coverity: I have fixed 563 issues out of 896 Coverity issues fixed in the past (according to gitlog *1). I fixed over 2000 issues found by ossfuzz. (*) git shortlog -s -n -i --no-merges --first-parent --grep 'fix.*\(CID\|coverity\)' -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes 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 1/2] lavu/hashtable: create generic robin hood hash table
On Mon, Feb 5, 2024 at 3:58 AM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Connor Worley: > > +memcpy(ctx->tmp_key, ctx->set_key, ctx->key_size); > > +memcpy(ctx->tmp_val, ctx->set_val, ctx->val_size); > > Given that set_key/val are overwritten below, these two can be done via > pointerswaps. I don't quite follow, can you elaborate on this part? -- Connor Worley ___ 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 v8 1/2] libavformat: add DVD-Video demuxer, powered by libdvdnav and libdvdread
Hopefully, this is the last one.
- All prior documentation fixes and feedback addressed (AFAIK)
- Prevents demuxing of empty titles and informs the user
- Fixes does not add chapter markers if only one chapter
- Fixes logic for chapter selection on certain titles
Signed-off-by: Marth64
---
Changelog |2 +
configure |8 +
doc/demuxers.texi | 129
libavformat/Makefile |1 +
libavformat/allformats.c |1 +
libavformat/dvdvideodec.c | 1424 +
6 files changed, 1565 insertions(+)
create mode 100644 libavformat/dvdvideodec.c
diff --git a/Changelog b/Changelog
index c5fb21d198..88653bc6d3 100644
--- a/Changelog
+++ b/Changelog
@@ -24,6 +24,8 @@ version :
- ffmpeg CLI options may now be used as -/opt , which is equivalent
to -opt >
- showinfo bitstream filter
+- DVD-Video demuxer, powered by libdvdnav and libdvdread
+
version 6.1:
- libaribcaption decoder
diff --git a/configure b/configure
index f72533b7d2..831b9f6cb6 100755
--- a/configure
+++ b/configure
@@ -227,6 +227,8 @@ External library support:
--enable-libdavs2enable AVS2 decoding via libdavs2 [no]
--enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
and libraw1394 [no]
+ --enable-libdvdnav enable libdvdnav, needed for DVD demuxing [no]
+ --enable-libdvdread enable libdvdread, needed for DVD demuxing [no]
--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
--enable-libfliteenable flite (voice synthesis) support via libflite
[no]
--enable-libfontconfig enable libfontconfig, useful for drawtext filter
[no]
@@ -1806,6 +1808,8 @@ EXTERNAL_LIBRARY_GPL_LIST="
frei0r
libcdio
libdavs2
+libdvdnav
+libdvdread
librubberband
libvidstab
libx264
@@ -3523,6 +3527,8 @@ dts_demuxer_select="dca_parser"
dtshd_demuxer_select="dca_parser"
dv_demuxer_select="dvprofile"
dv_muxer_select="dvprofile"
+dvdvideo_demuxer_select="mpegps_demuxer"
+dvdvideo_demuxer_deps="libdvdnav libdvdread"
dxa_demuxer_select="riffdec"
eac3_demuxer_select="ac3_parser"
evc_demuxer_select="evc_frame_merge_bsf evc_parser"
@@ -6771,6 +6777,8 @@ enabled libdav1d && require_pkg_config libdav1d
"dav1d >= 0.5.0" "dav1d
enabled libdavs2 && require_pkg_config libdavs2 "davs2 >= 1.6.0"
davs2.h davs2_decoder_open
enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2
dc1394/dc1394.h dc1394_new
enabled libdrm&& check_pkg_config libdrm libdrm xf86drm.h
drmGetVersion
+enabled libdvdnav && require_pkg_config libdvdnav "dvdnav >= 6.1.1"
dvdnav/dvdnav.h dvdnav_open2
+enabled libdvdread&& require_pkg_config libdvdread "dvdread >= 6.1.2"
dvdread/dvd_reader.h DVDOpen2 -ldvdread
enabled libfdk_aac&& { check_pkg_config libfdk_aac fdk-aac
"fdk-aac/aacenc_lib.h" aacEncOpen ||
{ require libfdk_aac fdk-aac/aacenc_lib.h
aacEncOpen -lfdk-aac &&
warn "using libfdk without pkg-config"; } }
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e4c5b560a6..ad0906f6ec 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -285,6 +285,135 @@ This demuxer accepts the following option:
@end table
+@section dvdvideo
+
+DVD-Video demuxer, powered by libdvdnav and libdvdread.
+
+Can directly ingest DVD titles, specifically sequential PGCs,
+into a conversion pipeline. Menus and seeking are not supported at this time.
+
+Block devices (DVD drives), ISO files, and directory structures are accepted.
+Activate with @code{-f dvdvideo} in front of one of these inputs.
+
+Underlying playback is fully handled by libdvdnav, and structure parsing by
libdvdread.
+ffmpeg must be built with GPL library support available as well as the switches
+@code{--enable-libdvdnav} and @code{--enable-libdvdread}.
+
+You will need to provide either the desired "title number" or exact PGC/PG
coordinates.
+Many open-source DVD players and tools can aid in providing this information.
+If not specified, the demuxer will default to title 1 which works for many
discs.
+However, due to the flexibility of DVD-Video, it is recommended to check
manually.
+There are many discs that are authored strangely or with invalid headers.
+
+If the input is a real DVD drive, please note that there are some drives which
may
+silently fail on reading bad sectors from the disc, returning random bits
instead
+which is effectively corrupt data. This is especially prominent on aging or
rotting discs.
+A second pass and integrity checks would be needed to detect the corruption.
+This is not an ffmpeg issue.
+
+@subsection Background
+
+DVD-Video is not a directly accessible, linear container format in the
+traditional sense. Instead, it allows for complex and programmatic playback of
+carefully muxed MPEG-PS streams that are stored in headerless VOB files.
+To the end-us
[FFmpeg-devel] [PATCH v8 2/2] libavformat/dvdvideo: add DVD CLUT utilities and enable palette support
DVD subtitle palettes, which are natively YUV, are currently carried as
a hex string in their respective subtitle streams and have
no concept of colorspace tagging. In fact, the convention is to convert
them to RGB prior to storage. Common players will only render
the palettes properly if they are stored as RGB. Even ffmpeg itself
expects this, and already does -in libavformat- the YUV-RGB conversions,
specifically in mov.c and movenc.c.
The point of this patch is to provide a consolidation of the code
that deals with creating the extradata as well as the RGB conversion.
That can then (1) enable usable palette support for DVD demuxer if it is merged
and (2) start the process of consolidating the related conversions in
MOV muxer/demuxer and eventually find a way to properly tag
the colorspace.
Signed-off-by: Marth64
---
doc/demuxers.texi | 5 ++
libavformat/Makefile | 2 +-
libavformat/dvdclut.c | 104 ++
libavformat/dvdclut.h | 37 ++
libavformat/dvdvideodec.c | 16 ++
5 files changed, 163 insertions(+), 1 deletion(-)
create mode 100644 libavformat/dvdclut.c
create mode 100644 libavformat/dvdclut.h
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index ad0906f6ec..9c666a29c1 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -390,6 +390,11 @@ often with junk data intended for controlling a real DVD
player's
buffering speed and with no other material data value.
Default is 1, true.
+@item clut_rgb
+Output subtitle palettes (CLUTs) as RGB, required for Matroska and MP4.
+Disable to output the palette in its original YUV colorspace.
+Default is 1, true.
+
@end table
@subsection Examples
diff --git a/libavformat/Makefile b/libavformat/Makefile
index df69734877..8f17e43e49 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -192,7 +192,7 @@ OBJS-$(CONFIG_DTS_MUXER) += rawenc.o
OBJS-$(CONFIG_DV_MUXER) += dvenc.o
OBJS-$(CONFIG_DVBSUB_DEMUXER)+= dvbsub.o rawdec.o
OBJS-$(CONFIG_DVBTXT_DEMUXER)+= dvbtxt.o rawdec.o
-OBJS-$(CONFIG_DVDVIDEO_DEMUXER) += dvdvideodec.o
+OBJS-$(CONFIG_DVDVIDEO_DEMUXER) += dvdvideodec.o dvdclut.o
OBJS-$(CONFIG_DXA_DEMUXER) += dxa.o
OBJS-$(CONFIG_EA_CDATA_DEMUXER) += eacdata.o
OBJS-$(CONFIG_EA_DEMUXER)+= electronicarts.o
diff --git a/libavformat/dvdclut.c b/libavformat/dvdclut.c
new file mode 100644
index 00..71fdda7925
--- /dev/null
+++ b/libavformat/dvdclut.c
@@ -0,0 +1,104 @@
+/*
+ * DVD-Video subpicture CLUT (Color Lookup Table) utilities
+ *
+ * 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
+ */
+
+#include "libavutil/bprint.h"
+#include "libavutil/colorspace.h"
+#include "libavutil/intreadwrite.h"
+
+#include "avformat.h"
+#include "dvdclut.h"
+#include "internal.h"
+
+/* crop table for YUV to RGB subpicture palette conversion */
+#define FF_DVDCLUT_YUV_NEG_CROP_MAX1024
+#define times4(x) x, x, x, x
+#define times256(x)
times4(times4(times4(times4(times4(x)
+
+const uint8_t ff_dvdclut_yuv_crop_tab[256 + 2 * FF_DVDCLUT_YUV_NEG_CROP_MAX] =
{
+times256(0x00),
+0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,
+0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x1C,0x1D,0x1E,0x1F,
+0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x29,0x2A,0x2B,0x2C,0x2D,0x2E,0x2F,
+0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x3A,0x3B,0x3C,0x3D,0x3E,0x3F,
+0x40,0x41,0x42,0x43,0x44,0x45,0x46,0x47,0x48,0x49,0x4A,0x4B,0x4C,0x4D,0x4E,0x4F,
+0x50,0x51,0x52,0x53,0x54,0x55,0x56,0x57,0x58,0x59,0x5A,0x5B,0x5C,0x5D,0x5E,0x5F,
+0x60,0x61,0x62,0x63,0x64,0x65,0x66,0x67,0x68,0x69,0x6A,0x6B,0x6C,0x6D,0x6E,0x6F,
+0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x77,0x78,0x79,0x7A,0x7B,0x7C,0x7D,0x7E,0x7F,
+0x80,0x81,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8A,0x8B,0x8C,0x8D,0x8E,0x8F,
+0x90,0x91,0x92,0x93,0x94,0x95,0x96,0x97,0x98,0x99,0x9A,0x9B,0x9C,0x9D,0x9E,0x9F,
+0xA0,0xA1,0xA2,0xA3,0xA4,0xA5,0xA6,0xA7,0xA8,0xA9,0xAA,0xAB,0xAC,0xAD,0xAE,0xAF,
+0xB0,0xB1,0xB2,0xB3,0xB4,0xB5,0xB6,0xB7,0xB8,0xB9,0xBA,0xBB,0xBC,0xBD,0xBE,0xBF,
+0xC0,0xC1,0xC2,0xC3,0xC4,0xC5,0xC6,0xC7,0xC8,0xC9,0xCA,0xCB,0xCC,0xCD
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
On Mon, Feb 5, 2024 at 8:59 PM Anton Khirnov wrote: > diff --git a/configure b/configure > index f72533b7d2..1bb9e23f19 100755 > --- a/configure > +++ b/configure > @@ -5517,21 +5517,20 @@ if test "$?" != 0; then > die "C compiler test failed." > fi > > -add_cppflags -D_ISOC99_SOURCE > +add_cppflags -D_ISOC11_SOURCE Not an expert, should this be D_ISOC17_SOURCE? A google shows this doesn't exist, so i guess i'm wrong. Some comment may be helpful here > add_cxxflags -D__STDC_CONSTANT_MACROS > check_cxxflags -std=c++11 || check_cxxflags -std=c++0x > > -# some compilers silently accept -std=c11, so we also need to check that the > +# some compilers silently accept -std=c17, so we also need to check that the > # version macro is defined properly > -test_cflags_cc -std=c11 ctype.h "__STDC_VERSION__ >= 201112L" && > -add_cflags -std=c11 || > -check_cflags -std=c99 > +test_cflags_cc -std=c17 ctype.h "__STDC_VERSION__ >= 201710L" && > +add_cflags -std=c17 || die "Compiler lacks C17 support" > > check_cppflags -D_FILE_OFFSET_BITS=64 > check_cppflags -D_LARGEFILE_SOURCE > > -add_host_cppflags -D_ISOC99_SOURCE > -check_host_cflags -std=c99 > +add_host_cppflags -D_ISOC11_SOURCE > +check_host_cflags -std=c17 idem ___ 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".
