Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
Quoting Gyan Doshi (2024-02-15 17:47:49) > This patch facilitates a certain productive use of ffmpeg with respect > to processing of live inputs that wasn't possible earlier, > and which currently is being used successfully by multiple people over > the past few weeks. > It applies a processing model already implemented in multiple other > decoders for a number of years. I haven't seen many reports > of issues with them. And surely something being 'a constant source of > issues' would be a lot more than 'subtly broken' as you describe > them. This reads very much like "I can't be bothered to do it properly and would rather someone else fix it in the future". Given past experience, that someone is highly likely to be me, and fixing past architectural decisions requires a lot more effort than doing things properly in the first place.. > You're the only one who has objected on architectural grounds and Not true, Andreas has objected as well. > If you are blocking this patch, do acknowledge here within 24 hours and > we can send this to the TC else I'll push it after that period. I must say I rather dislike this "my way or the highway" attitude. So yes, I am objecting to the patch in its current form. -- 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] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket
Quoting Tomas Härdin (2024-02-03 20:58:20) > I think people with knowledge how interlacing is handled in other > formats and codecs might want to chime in. For MPEG codecs our decoders always output (properly signalled) interlaced content as two interleaved fields in a single AVFrame flagged with AV_FRAME_FLAG_INTERLACED. Its height is the height of the whole frame, so double the number of lines in each field. So IIUC this patch is taking the correct approach. -- 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] avformat/libsrt: Remove manually free AV_OPT_TYPE_STRING
Quoting Zhao Zhili (2024-02-15 03:15:08) > From: Zhao Zhili > > Signed-off-by: Zhao Zhili > --- > libavformat/libsrt.c | 3 --- > 1 file changed, 3 deletions(-) Looks ok -- 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 v2] avcodec/h2645_parse: Don't treat 0x000002 as a start code and truncate
Quoting Mattias Wadman (2024-02-13 11:17:46) > According to ITU-T H.265 7.4.2.1 this byte sequence should not appear in a > NAL unit but in practice in rare cases it seems it does, possibly due to buggy > encoders. Other players like VLC and Quicktime seem to be fine with it. > > Currently when this sequence is found it is treated as if the next start code > has been found and the NAL unit gets truncated. > > This change limits the code to only look for first start code 0x001 or > first escape 0x03. > > Sadly i can't share the original source file with the issue but the first > 80 bytes of the NAL unit looks like this: > >│00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f│0123456789abcdef│ > 0x0│00 00 00 01 02 01 d0 bc 57 a1 b8 44 70 01 00 0b│W..Dp...│ > 0x00010│80 2e 00 c2 6c ec 3e b9 e3 03 fb 91 2e d2 43 cb│l.>...C.│ > 0x00020│1d 2c 00 00 02 00 02 00 5c 93 72 6f 31 76 18 00│.,..\.ro1v..│ > 0x00030│08 38 aa b1 4c 33 3f fd 08 cb 77 9b d4 3c db 02│.8..L3?...w..<..│ > 0x00040│a2 04 73 15 75 de 3b c4 67 c0 8f ca ad 31 f1 99│..s.u.;.g1..│ > --- > libavcodec/h2645_parse.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Will push if nobody sees a problem with it. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/vvc: Check fc->ref contains valid reference
Quoting Nuo Mi (2024-02-13 04:03:11) > HI Lynee, > the name is from hevc. I do not like it either, but so many functions > copied from hevc will use it. ... The naming in hevcdec is really schizophrenic, I wish somebody did something about it. Certainly do not feel compelled to use it as a model. -- 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 v13 1/2] libavformat: add DVD-Video demuxer, powered by libdvdnav and libdvdread
Quoting Marth64 (2024-02-11 19:09:16)
> +static int dvdvideo_video_stream_add(AVFormatContext *s,
> + DVDVideoVTSVideoStreamEntry *entry,
> + enum AVStreamParseType need_parsing)
> +{
> +AVStream *st;
> +FFStream *sti;
> +
> +st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
> +
> +st->id = entry->startcode;
> +st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
> +st->codecpar->codec_id = entry->codec_id;
> +st->codecpar->width = entry->width;
> +st->codecpar->height = entry->height;
> +st->codecpar->format = AV_PIX_FMT_YUV420P;
> +st->codecpar->color_range = AVCOL_RANGE_MPEG;
> +
> +st->codecpar->framerate = entry->framerate;
Demuxers are not supposed to set this, it's for the codec-layer
framerate information.
> +#if FF_API_R_FRAME_RATE
> +st->r_frame_rate = entry->framerate;
> +#endif
> +st->avg_frame_rate = entry->framerate;
> +
> +sti = ffstream(st);
> +sti->request_probe = 0;
> +sti->need_parsing = need_parsing;
> +sti->display_aspect_ratio = entry->dar;
> +sti->avctx->framerate = entry->framerate;
This neither.
--
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/4 v8] avformat/mov: add support for tile HEIF still images
Quoting James Almer (2024-02-11 19:56:59) > +/** > + * The video stream is intended to be merged with another stream before > + * presentation. > + * Used for example to signal the stream contains a tile from a HEIF grid. > + */ > +#define AV_DISPOSITION_TILE (1 << 21) The notion of "this stream needs to be combined with another one for presentation" seems more general than just tiling video, could just as well describe a set of audio tracks to be mixed together. And since we're running out of easily usable disposition bits, we shouldn't waste them. How about AV_DISPOSITION_SUBSTREAM? -- 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 1/2] avutil/pixfmt: Add AV_PIX_MAX_PLANES
Quoting Michael Niedermayer (2024-02-08 13:57:57) > It seems we do not have a named identifier for the maximum planes of pixel > formats > > Signed-off-by: Michael Niedermayer > --- > libavutil/pixfmt.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h > index 9c87571f49e..67422f02d02 100644 > --- a/libavutil/pixfmt.h > +++ b/libavutil/pixfmt.h > @@ -32,6 +32,8 @@ > #define AVPALETTE_SIZE 1024 > #define AVPALETTE_COUNT 256 > > +#define AV_PIX_MAX_PLANES 4 I'd call it AV_VIDEO_MAX_PLANES. Also, needs doxy,APIchanges, and minor bump. -- 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] avcodec/speexdec: check for sane s->frame_size values
Fixes heap buffer overflows Reported-by: sploitem Signed-off-by: James Almer --- libavcodec/speexdec.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libavcodec/speexdec.c b/libavcodec/speexdec.c index 51c5834769..4d8052d585 100644 --- a/libavcodec/speexdec.c +++ b/libavcodec/speexdec.c @@ -1420,7 +1420,10 @@ static int parse_speex_extradata(AVCodecContext *avctx, if (s->nb_channels <= 0 || s->nb_channels > 2) return AVERROR_INVALIDDATA; s->bitrate = bytestream_get_le32(&buf); -s->frame_size = (1 + (s->mode > 0)) * bytestream_get_le32(&buf); +s->frame_size = bytestream_get_le32(&buf); +if (s->frame_size < NB_FRAME_SIZE << (s->mode > 0)) +return AVERROR_INVALIDDATA; +s->frame_size *= 1 + (s->mode > 0); s->vbr = bytestream_get_le32(&buf); s->frames_per_packet = bytestream_get_le32(&buf); if (s->frames_per_packet <= 0 || -- 2.43.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 v13 1/2] libavformat: add DVD-Video demuxer, powered by libdvdnav and libdvdread
I will take care of it, thanks
On Fri, Feb 16, 2024 at 05:38 Anton Khirnov wrote:
> Quoting Marth64 (2024-02-11 19:09:16)
> > +static int dvdvideo_video_stream_add(AVFormatContext *s,
> > + DVDVideoVTSVideoStreamEntry *entry,
> > + enum AVStreamParseType
> need_parsing)
> > +{
> > +AVStream *st;
> > +FFStream *sti;
> > +
> > +st = avformat_new_stream(s, NULL);
> > +if (!st)
> > +return AVERROR(ENOMEM);
> > +
> > +st->id = entry->startcode;
> > +st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
> > +st->codecpar->codec_id = entry->codec_id;
> > +st->codecpar->width = entry->width;
> > +st->codecpar->height = entry->height;
> > +st->codecpar->format = AV_PIX_FMT_YUV420P;
> > +st->codecpar->color_range = AVCOL_RANGE_MPEG;
> > +
> > +st->codecpar->framerate = entry->framerate;
>
> Demuxers are not supposed to set this, it's for the codec-layer
> framerate information.
>
> > +#if FF_API_R_FRAME_RATE
> > +st->r_frame_rate = entry->framerate;
> > +#endif
> > +st->avg_frame_rate = entry->framerate;
> > +
> > +sti = ffstream(st);
> > +sti->request_probe = 0;
> > +sti->need_parsing = need_parsing;
> > +sti->display_aspect_ratio = entry->dar;
> > +sti->avctx->framerate = entry->framerate;
>
> This neither.
>
> --
> 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/4 v8] avformat/mov: add support for tile HEIF still images
On 2/16/2024 9:50 AM, Anton Khirnov wrote: Quoting James Almer (2024-02-11 19:56:59) +/** + * The video stream is intended to be merged with another stream before + * presentation. + * Used for example to signal the stream contains a tile from a HEIF grid. + */ +#define AV_DISPOSITION_TILE (1 << 21) The notion of "this stream needs to be combined with another one for presentation" seems more general than just tiling video, could just as well describe a set of audio tracks to be mixed together. That's why i stated it's for video. For audio there's AV_DISPOSITION_DEPENDENT. And since we're running out of easily usable disposition bits, we shouldn't waste them. How about AV_DISPOSITION_SUBSTREAM? Maybe we could redefine and reuse AV_DISPOSITION_DEPENDENT for this? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avutil/pixfmt: Add AV_PIX_MAX_PLANES
On Fri, Feb 16, 2024 at 02:39:33PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-02-08 13:57:57) > > It seems we do not have a named identifier for the maximum planes of pixel > > formats > > > > Signed-off-by: Michael Niedermayer > > --- > > libavutil/pixfmt.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h > > index 9c87571f49e..67422f02d02 100644 > > --- a/libavutil/pixfmt.h > > +++ b/libavutil/pixfmt.h > > @@ -32,6 +32,8 @@ > > #define AVPALETTE_SIZE 1024 > > #define AVPALETTE_COUNT 256 > > > > +#define AV_PIX_MAX_PLANES 4 > > I'd call it AV_VIDEO_MAX_PLANES. > > Also, needs doxy,APIchanges, and minor bump. ok, will apply with all that [...] thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. 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/4 v8] avformat/mov: add support for tile HEIF still images
Quoting James Almer (2024-02-16 17:35:13) > > > > And since we're running out of easily usable disposition bits, we > > shouldn't waste them. How about AV_DISPOSITION_SUBSTREAM? > > Maybe we could redefine and reuse AV_DISPOSITION_DEPENDENT for this? Works for me. -- 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] avcodec/speexdec: check for sane s->frame_size values
On Fri, Feb 16, 2024 at 11:19:25AM -0300, James Almer wrote: > Fixes heap buffer overflows > > Reported-by: sploitem > Signed-off-by: James Almer > --- > libavcodec/speexdec.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) ok, though note that i do not know speexdec.c well enough to say that this is or is not sufficient thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/x86/fpel: Remove declarations of inexistent functions
Forgotten in 50a8cbb23e9a982292bf7737004c97eba776c00e and a51279bbdea0d6db920d71980262bccd0ce78226. Signed-off-by: Andreas Rheinhardt --- libavcodec/x86/fpel.h | 4 1 file changed, 4 deletions(-) diff --git a/libavcodec/x86/fpel.h b/libavcodec/x86/fpel.h index 4e83cf71c3..90f7051a48 100644 --- a/libavcodec/x86/fpel.h +++ b/libavcodec/x86/fpel.h @@ -22,12 +22,8 @@ #include #include -void ff_avg_pixels4_mmx(uint8_t *block, const uint8_t *pixels, -ptrdiff_t line_size, int h); void ff_avg_pixels4_mmxext(uint8_t *block, const uint8_t *pixels, ptrdiff_t line_size, int h); -void ff_avg_pixels8_mmx(uint8_t *block, const uint8_t *pixels, -ptrdiff_t line_size, int h); void ff_avg_pixels8_mmxext(uint8_t *block, const uint8_t *pixels, ptrdiff_t line_size, int h); void ff_avg_pixels16_mmx(uint8_t *block, const uint8_t *pixels, -- 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/2] avcodec/x86/hpeldsp_init: Avoid using ff_avg_pixels16_mmx
Use ff_avg_pixels16_mmxext or ff_avg_pixels16_sse2
(for users with SSE2_FAST) instead.
This also allows to remove ff_avg_pixels16_mmx,
as this was its last remaining user.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/x86/fpel.asm | 1 -
libavcodec/x86/fpel.h | 2 --
libavcodec/x86/hpeldsp_init.c | 15 +++
3 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/libavcodec/x86/fpel.asm b/libavcodec/x86/fpel.asm
index ebe8e43750..ecaca3c080 100644
--- a/libavcodec/x86/fpel.asm
+++ b/libavcodec/x86/fpel.asm
@@ -92,7 +92,6 @@ INIT_MMX mmx
OP_PIXELS put, 4
OP_PIXELS put, 8
OP_PIXELS put, 16
-OP_PIXELS avg, 16
INIT_MMX mmxext
OP_PIXELS avg, 4
diff --git a/libavcodec/x86/fpel.h b/libavcodec/x86/fpel.h
index 90f7051a48..c533ca40b2 100644
--- a/libavcodec/x86/fpel.h
+++ b/libavcodec/x86/fpel.h
@@ -26,8 +26,6 @@ void ff_avg_pixels4_mmxext(uint8_t *block, const uint8_t
*pixels,
ptrdiff_t line_size, int h);
void ff_avg_pixels8_mmxext(uint8_t *block, const uint8_t *pixels,
ptrdiff_t line_size, int h);
-void ff_avg_pixels16_mmx(uint8_t *block, const uint8_t *pixels,
- ptrdiff_t line_size, int h);
void ff_avg_pixels16_mmxext(uint8_t *block, const uint8_t *pixels,
ptrdiff_t line_size, int h);
void ff_avg_pixels16_sse2(uint8_t *block, const uint8_t *pixels,
diff --git a/libavcodec/x86/hpeldsp_init.c b/libavcodec/x86/hpeldsp_init.c
index f08c66f5c8..4a0513d06d 100644
--- a/libavcodec/x86/hpeldsp_init.c
+++ b/libavcodec/x86/hpeldsp_init.c
@@ -62,11 +62,9 @@ void ff_avg_pixels8_y2_mmxext(uint8_t *block, const uint8_t
*pixels,
void ff_avg_approx_pixels8_xy2_mmxext(uint8_t *block, const uint8_t *pixels,
ptrdiff_t line_size, int h);
-#define avg_pixels16_mmxff_avg_pixels16_mmx
#define put_pixels8_mmx ff_put_pixels8_mmx
#define put_pixels16_mmxff_put_pixels16_mmx
#define put_pixels8_xy2_mmx ff_put_pixels8_xy2_mmx
-#define avg_no_rnd_pixels16_mmx ff_avg_pixels16_mmx
#define put_no_rnd_pixels8_mmx ff_put_pixels8_mmx
#define put_no_rnd_pixels16_mmx ff_put_pixels16_mmx
@@ -138,7 +136,6 @@ HPELDSP_AVG_PIXELS16(_mmxext)
if (HAVE_MMX_EXTERNAL) \
c->PFX ## _pixels_tab IDX [0] = PFX ## _pixels ## SIZE ## _ ## CPU
-#if HAVE_MMX_INLINE
#define SET_HPEL_FUNCS03(PFX, IDX, SIZE, CPU)
\
do {
\
SET_HPEL_FUNCS_EXT(PFX, IDX, SIZE, CPU);
\
@@ -149,10 +146,6 @@ HPELDSP_AVG_PIXELS16(_mmxext)
c->PFX ## _pixels_tab IDX [1] = PFX ## _pixels ## SIZE ## _x2_ ##
CPU; \
c->PFX ## _pixels_tab IDX [2] = PFX ## _pixels ## SIZE ## _y2_ ##
CPU; \
} while (0)
-#else
-#define SET_HPEL_FUNCS03(PFX, IDX, SIZE, CPU) SET_HPEL_FUNCS_EXT(PFX, IDX,
SIZE, CPU)
-#define SET_HPEL_FUNCS12(PFX, IDX, SIZE, CPU) ((void)0)
-#endif
#define SET_HPEL_FUNCS(PFX, IDX, SIZE, CPU)
\
do {
\
SET_HPEL_FUNCS03(PFX, IDX, SIZE, CPU);
\
@@ -161,11 +154,14 @@ HPELDSP_AVG_PIXELS16(_mmxext)
static void hpeldsp_init_mmx(HpelDSPContext *c, int flags)
{
+#if HAVE_MMX_INLINE
SET_HPEL_FUNCS03(put, [0], 16, mmx);
SET_HPEL_FUNCS(put_no_rnd, [0], 16, mmx);
-SET_HPEL_FUNCS(avg_no_rnd,, 16, mmx);
+SET_HPEL_FUNCS12(avg_no_rnd, , 16, mmx);
+c->avg_no_rnd_pixels_tab[3] = avg_no_rnd_pixels16_xy2_mmx;
SET_HPEL_FUNCS03(put, [1], 8, mmx);
SET_HPEL_FUNCS(put_no_rnd, [1], 8, mmx);
+#endif
}
static void hpeldsp_init_mmxext(HpelDSPContext *c, int flags)
@@ -190,6 +186,8 @@ static void hpeldsp_init_mmxext(HpelDSPContext *c, int
flags)
c->put_no_rnd_pixels_tab[1][1] = ff_put_no_rnd_pixels8_x2_exact_mmxext;
c->put_no_rnd_pixels_tab[1][2] = ff_put_no_rnd_pixels8_y2_exact_mmxext;
+c->avg_no_rnd_pixels_tab[0] = ff_avg_pixels16_mmxext;
+
if (!(flags & AV_CODEC_FLAG_BITEXACT)) {
c->put_no_rnd_pixels_tab[0][1] = put_no_rnd_pixels16_x2_mmxext;
c->put_no_rnd_pixels_tab[0][2] = put_no_rnd_pixels16_y2_mmxext;
@@ -214,6 +212,7 @@ static void hpeldsp_init_sse2_fast(HpelDSPContext *c, int
flags)
c->avg_pixels_tab[0][1]= ff_avg_pixels16_x2_sse2;
c->avg_pixels_tab[0][2]= ff_avg_pixels16_y2_sse2;
c->avg_pixels_tab[0][3]= ff_avg_pixels16_xy2_sse2;
+c->avg_no_rnd_pixels_tab[0]= ff_avg_pixels16_sse2;
#endif /* HAVE_SSE2_EXTERNAL */
}
--
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...@ffmp
[FFmpeg-devel] [PATCH 1/2] avformat/mxfdec: move resolving Descriptors to the multi descriptor resolve function
Also remove unused descriptor member from MXFPackage.
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index e42975e7fd..4e4e3e7a84 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -266,7 +266,6 @@ typedef struct MXFPackage {
UID package_ul;
UID *tracks_refs;
int tracks_count;
-MXFDescriptor *descriptor; /* only one */
UID descriptor_ref;
char *name;
UID *comment_refs;
@@ -2257,11 +2256,12 @@ static MXFPackage*
mxf_resolve_source_package(MXFContext *mxf, UID package_ul, U
return NULL;
}
-static MXFDescriptor* mxf_resolve_multidescriptor(MXFContext *mxf,
MXFDescriptor *descriptor, int track_id)
+static MXFDescriptor* mxf_resolve_descriptor(MXFContext *mxf, UID *strong_ref,
int track_id)
{
-MXFDescriptor *file_descriptor = NULL;
+MXFDescriptor *descriptor, *file_descriptor = NULL;
int i;
+descriptor = mxf_resolve_strong_ref(mxf, strong_ref, AnyType);
if (!descriptor)
return NULL;
@@ -2782,8 +2782,7 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
st->id = material_track->track_id;
st->priv_data = source_track;
-source_package->descriptor = mxf_resolve_strong_ref(mxf,
&source_package->descriptor_ref, AnyType);
-descriptor = mxf_resolve_multidescriptor(mxf,
source_package->descriptor, source_track->track_id);
+descriptor = mxf_resolve_descriptor(mxf,
&source_package->descriptor_ref, source_track->track_id);
/* A SourceClip from a EssenceGroup may only be a single frame of
essence data. The clips duration is then how many
* frames its suppose to repeat for. Descriptor->duration, if present,
contains the real duration of the essence data */
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avformat/mxfdec: do not use AnyType when resolving Descriptors and MultipleDescriptors
Using AnyType should not be a problem for proper MXF files because UIDs are
supposed to be unique themselves. Unfortunately that is not the case for some
broken files, so let's check the type more strictly.
Fixes ticket #10865.
Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 4e4e3e7a84..446bcf3276 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2258,16 +2258,14 @@ static MXFPackage*
mxf_resolve_source_package(MXFContext *mxf, UID package_ul, U
static MXFDescriptor* mxf_resolve_descriptor(MXFContext *mxf, UID *strong_ref,
int track_id)
{
-MXFDescriptor *descriptor, *file_descriptor = NULL;
-int i;
-
-descriptor = mxf_resolve_strong_ref(mxf, strong_ref, AnyType);
-if (!descriptor)
-return NULL;
+MXFDescriptor *descriptor = mxf_resolve_strong_ref(mxf, strong_ref,
Descriptor);
+if (descriptor)
+return descriptor;
-if (descriptor->meta.type == MultipleDescriptor) {
-for (i = 0; i < descriptor->file_descriptors_count; i++) {
-file_descriptor = mxf_resolve_strong_ref(mxf,
&descriptor->file_descriptors_refs[i], Descriptor);
+descriptor = mxf_resolve_strong_ref(mxf, strong_ref, MultipleDescriptor);
+if (descriptor) {
+for (int i = 0; i < descriptor->file_descriptors_count; i++) {
+MXFDescriptor *file_descriptor = mxf_resolve_strong_ref(mxf,
&descriptor->file_descriptors_refs[i], Descriptor);
if (!file_descriptor) {
av_log(mxf->fc, AV_LOG_ERROR, "could not resolve file
descriptor strong ref\n");
@@ -2277,8 +2275,7 @@ static MXFDescriptor* mxf_resolve_descriptor(MXFContext
*mxf, UID *strong_ref, i
return file_descriptor;
}
}
-} else if (descriptor->meta.type == Descriptor)
-return descriptor;
+}
return NULL;
}
--
2.35.3
___
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 Thu, Feb 15, 2024 at 2:35 PM Michael Niedermayer wrote: > FFMIN/MAX can evaluate their arguments multiple times so avio_rb32() might > be executed more than once > Thanks. Good catch. Fixed. stco-clamp-entries-v4.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] avutil/channel_layout: add AV_CHANNEL_ORDER_NB
On Thu, 15 Feb 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-02-13 21:27:34)
On Tue, 13 Feb 2024, James Almer wrote:
On 2/12/2024 6:15 PM, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavutil/channel_layout.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index b8bff6f365..db0c005e87 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -146,6 +146,10 @@ enum AVChannelOrder {
* as defined in AmbiX format $ 2.1.
*/
AV_CHANNEL_ORDER_AMBISONIC,
+/**
+ * Number of channel orders, not part of ABI/API
+ */
+AV_CHANNEL_ORDER_NB
};
Is it worth adding this to a public header just to limit a loop in a test? A
loop that fwiw still depends on an array that needs to be updated with more
names if you add new orders.
Several other enums also have this. So API consistency can be considered
a more important factor.
I'd be concerned that many callers don't undertand the implications of
"not part of the ABI".
Maybe we should rename all of them to FF_ prefix to make it more clear
callers should not use these?
I think this is a good idea. So is it OK to apply this if I change the
prefix to FF?
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] avutil/channel_layout: add AV_CHANNEL_ORDER_NB
On 2/16/2024 7:42 PM, Marton Balint wrote:
On Thu, 15 Feb 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-02-13 21:27:34)
On Tue, 13 Feb 2024, James Almer wrote:
On 2/12/2024 6:15 PM, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavutil/channel_layout.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index b8bff6f365..db0c005e87 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -146,6 +146,10 @@ enum AVChannelOrder {
* as defined in AmbiX format $ 2.1.
*/
AV_CHANNEL_ORDER_AMBISONIC,
+ /**
+ * Number of channel orders, not part of ABI/API
+ */
+ AV_CHANNEL_ORDER_NB
};
Is it worth adding this to a public header just to limit a loop in a
test? A
loop that fwiw still depends on an array that needs to be updated
with more
names if you add new orders.
Several other enums also have this. So API consistency can be considered
a more important factor.
I'd be concerned that many callers don't undertand the implications of
"not part of the ABI".
Maybe we should rename all of them to FF_ prefix to make it more clear
callers should not use these?
I think this is a good idea. So is it OK to apply this if I change the
prefix to FF?
I wont oppose 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 3/4] avcodec/h264qpel_template: Mark pointers as non-aliasing
It allows the compiler to combine two reads and writes of adjacent
32bit memory locations into 64bit read-writes.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264qpel_template.c | 93 +++---
1 file changed, 52 insertions(+), 41 deletions(-)
diff --git a/libavcodec/h264qpel_template.c b/libavcodec/h264qpel_template.c
index 27c5b8f17f..61fa55c689 100644
--- a/libavcodec/h264qpel_template.c
+++ b/libavcodec/h264qpel_template.c
@@ -26,7 +26,7 @@
#include "hpel_template.c"
#include "pel_template.c"
-static inline void FUNC(copy_block2)(uint8_t *dst, const uint8_t *src, int
dstStride, int srcStride, int h)
+static inline void FUNC(copy_block2)(uint8_t *dst, const uint8_t *av_restrict
src, int dstStride, int srcStride, int h)
{
int i;
for(i=0; i>= sizeof(pixel)-1;\
srcStride >>= sizeof(pixel)-1;\
for(i=0; i>= sizeof(pixel)-1;\
srcStride >>= sizeof(pixel)-1;\
for(i=0; i>= sizeof(pixel)-1;\
srcStride >>= sizeof(pixel)-1;\
src -= 2*srcStride;\
@@ -150,12 +153,13 @@ static av_unused void FUNC(OPNAME ##
h264_qpel2_hv_lowpass)(uint8_t *_dst, pixel
tmp++;\
}\
}\
-static void FUNC(OPNAME ## h264_qpel4_h_lowpass)(uint8_t *_dst, const uint8_t
*_src, int dstStride, int srcStride){\
+static void FUNC(OPNAME ## h264_qpel4_h_lowpass)(uint8_t *_dst, const uint8_t
*av_restrict _src, int dstStride, int srcStride)\
+{\
const int h=4;\
INIT_CLIP\
int i;\
pixel *dst = (pixel*)_dst;\
-const pixel *src = (const pixel*)_src;\
+const pixel *av_restrict src = (const pixel*)_src;\
dstStride >>= sizeof(pixel)-1;\
srcStride >>= sizeof(pixel)-1;\
for(i=0; i>= sizeof(pixel)-1;\
srcStride >>= sizeof(pixel)-1;\
for(i=0; i>= sizeof(pixel)-1;\
srcStride >>= sizeof(pixel)-1;\
src -= 2*srcStride;\
@@ -238,12 +244,13 @@ static void FUNC(OPNAME ## h264_qpel4_hv_lowpass)(uint8_t
*_dst, pixeltmp *tmp,
}\
}\
\
-static void FUNC(OPNAME ## h264_qpel8_h_lowpass)(uint8_t *_dst, const uint8_t
*_src, int dstStride, int srcStride){\
+static void FUNC(OPNAME ## h264_qpel8_h_lowpass)(uint8_t *_dst, const uint8_t
*av_restrict _src, int dstStride, int srcStride)\
+{\
const int h=8;\
INIT_CLIP\
int i;\
pixel *dst = (pixel*)_dst;\
-const pixel *src = (const pixel*)_src;\
+const pixel *av_restrict src = (const pixel*)_src;\
dstStride >>= sizeof(pixel)-1;\
srcStride >>= sizeof(pixel)-1;\
for(i=0; i>= sizeof(pixel)-1;\
srcStride >>= sizeof(pixel)-1;\
for(i=0; i>= sizeof(pixel)-1;\
srcStride >>= sizeof(pixel)-1;\
src -= 2*srcStride;\
@@ -350,7 +359,8 @@ static void FUNC(OPNAME ## h264_qpel8_hv_lowpass)(uint8_t
*_dst, pixeltmp *tmp,
}\
}\
\
-static void FUNC(OPNAME ## h264_qpel16_v_lowpass)(uint8_t *dst, const uint8_t
*src, int dstStride, int srcStride){\
+static void FUNC(OPNAME ## h264_qpel16_v_lowpass)(uint8_t *dst, const uint8_t
*av_restrict src, int dstStride, int srcStride)\
+{\
FUNC(OPNAME ## h264_qpel8_v_lowpass)(dst, src
, dstStride, srcStride);\
FUNC(OPNAME ## h264_qpel8_v_lowpass)(dst+8*sizeof(pixel),
src+8*sizeof(pixel), dstStride, srcStride);\
src += 8*srcStride;\
@@ -359,7 +369,8 @@ static void FUNC(OPNAME ## h264_qpel16_v_lowpass)(uint8_t
*dst, const uint8_t *s
FUNC(OPNAME ## h264_qpel8_v_lowpass)(dst+8*sizeof(pixel),
src+8*sizeof(pixel), dstStride, srcStride);\
}\
\
-static void FUNC(OPNAME ## h264_qpel16_h_lowpass)(uint8_t *dst, const uint8_t
*src, int dstStride, int srcStride){\
+static void FUNC(OPNAME ## h264_qpel16_h_lowpass)(uint8_t *dst, const uint8_t
*av_restrict src, int dstStride, int srcStride)\
+{\
FUNC(OPNAME ## h264_qpel8_h_lowpass)(dst, src
, dstStride, srcStride);\
FUNC(OPNAME ## h264_qpel8_h_lowpass)(dst+8*sizeof(pixel),
src+8*sizeof(pixel), dstStride, srcStride);\
src += 8*srcStride;\
@@ -368,7 +379,7 @@ static void FUNC(OPNAME ## h264_qpel16_h_lowpass)(uint8_t
*dst, const uint8_t *s
FUNC(OPNAME ## h264_qpel8_h_lowpass)(dst+8*sizeof(pixel),
src+8*sizeof(pixel), dstStride, srcStride);\
}\
\
-static void FUNC(OPNAME ## h264_qpel16_hv_lowpass)(uint8_t *dst, pixeltmp
*tmp, const uint8_t *src, int dstStride, int tmpStride, int srcStride){\
+static void FUNC(OPNAME ## h264_qpel16_hv_lowpass)(uint8_t *dst, pixeltmp
*tmp, const uint8_t *av_restrict src, int dstStride, int tmpStride, int
srcStride){\
FUNC(OPNAME ## h264_qpel8_hv_lowpass)(dst, tmp , src
, dstStride, tmpStride, srcStride);\
FUNC(OPNAME ## h264_qpel8_hv_lowpass)(dst+8*sizeof(pixel), tmp+8,
src+8*sizeof(pixel), dstStride, tmpStride, srcStride);\
src += 8*srcStride;\
@@ -378,31 +389,31 @@ static void FUNC(OPNAME ##
h264_qpel16_hv_lowpass)(uint8_t *dst, pixeltmp *tmp,
}\
#define H264_MC(OPNAME, SIZE) \
-static void FUNCC(OPNAME ## h264_qpel ## SIZE ## _mc00)(uint8_t *dst,
[FFmpeg-devel] [PATCH 4/4] avcodec/x86/h264_qpel: Remove put_h264_qpel[48]_mmxext
These functions are not faster than the C versions.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/x86/fpel.asm| 1 -
libavcodec/x86/fpel.h | 2 --
libavcodec/x86/h264_qpel.c | 32 +---
3 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/libavcodec/x86/fpel.asm b/libavcodec/x86/fpel.asm
index ecaca3c080..278d1410fc 100644
--- a/libavcodec/x86/fpel.asm
+++ b/libavcodec/x86/fpel.asm
@@ -89,7 +89,6 @@ cglobal %1_pixels%2, 4,5,4
%endmacro
INIT_MMX mmx
-OP_PIXELS put, 4
OP_PIXELS put, 8
OP_PIXELS put, 16
diff --git a/libavcodec/x86/fpel.h b/libavcodec/x86/fpel.h
index c533ca40b2..47ffc8eec7 100644
--- a/libavcodec/x86/fpel.h
+++ b/libavcodec/x86/fpel.h
@@ -30,8 +30,6 @@ void ff_avg_pixels16_mmxext(uint8_t *block, const uint8_t
*pixels,
ptrdiff_t line_size, int h);
void ff_avg_pixels16_sse2(uint8_t *block, const uint8_t *pixels,
ptrdiff_t line_size, int h);
-void ff_put_pixels4_mmx(uint8_t *block, const uint8_t *pixels,
-ptrdiff_t line_size, int h);
void ff_put_pixels8_mmx(uint8_t *block, const uint8_t *pixels,
ptrdiff_t line_size, int h);
void ff_put_pixels16_mmx(uint8_t *block, const uint8_t *pixels,
diff --git a/libavcodec/x86/h264_qpel.c b/libavcodec/x86/h264_qpel.c
index 2df4c11f82..d69ccda89c 100644
--- a/libavcodec/x86/h264_qpel.c
+++ b/libavcodec/x86/h264_qpel.c
@@ -47,8 +47,8 @@ void ff_avg_pixels16_l2_mmxext(uint8_t *dst, const uint8_t
*src1, const uint8_t
#define ff_put_pixels16_l2_sse2 ff_put_pixels16_l2_mmxext
#define ff_avg_pixels16_l2_sse2 ff_avg_pixels16_l2_mmxext
#define ff_put_pixels16_mmxext ff_put_pixels16_mmx
-#define ff_put_pixels8_mmxext ff_put_pixels8_mmx
-#define ff_put_pixels4_mmxext ff_put_pixels4_mmx
+#define ff_put_pixels8_mmxext(...)
+#define ff_put_pixels4_mmxext(...)
#define DEF_QPEL(OPNAME)\
void ff_ ## OPNAME ## _h264_qpel4_h_lowpass_mmxext(uint8_t *dst, const uint8_t
*src, int dstStride, int srcStride);\
@@ -217,11 +217,10 @@ static void avg_h264_qpel16_mc00_sse2 (uint8_t *dst,
const uint8_t *src,
{
ff_avg_pixels16_sse2(dst, src, stride, 16);
}
-#define put_h264_qpel8_mc00_sse2 put_h264_qpel8_mc00_mmxext
#define avg_h264_qpel8_mc00_sse2 avg_h264_qpel8_mc00_mmxext
#define H264_MC_C(OPNAME, SIZE, MMX, ALIGN) \
-static void OPNAME ## h264_qpel ## SIZE ## _mc00_ ## MMX (uint8_t *dst, const
uint8_t *src, ptrdiff_t stride)\
+static void av_unused OPNAME ## h264_qpel ## SIZE ## _mc00_ ## MMX (uint8_t
*dst, const uint8_t *src, ptrdiff_t stride)\
{\
ff_ ## OPNAME ## pixels ## SIZE ## _ ## MMX(dst, src, stride, SIZE);\
}\
@@ -424,16 +423,20 @@ LUMA_MC_816(10, mc33, sse2)
#endif /* HAVE_X86ASM */
-#define SET_QPEL_FUNCS0123(PFX, IDX, SIZE, CPU, PREFIX) \
+#define SET_QPEL_FUNCS123(PFX, IDX, SIZE, CPU, PREFIX) \
do { \
-c->PFX ## _pixels_tab[IDX][ 0] = PREFIX ## PFX ## SIZE ## _mc00_ ## CPU; \
c->PFX ## _pixels_tab[IDX][ 1] = PREFIX ## PFX ## SIZE ## _mc10_ ## CPU; \
c->PFX ## _pixels_tab[IDX][ 2] = PREFIX ## PFX ## SIZE ## _mc20_ ## CPU; \
c->PFX ## _pixels_tab[IDX][ 3] = PREFIX ## PFX ## SIZE ## _mc30_ ## CPU; \
} while (0)
-#define SET_QPEL_FUNCS(PFX, IDX, SIZE, CPU, PREFIX) \
+#define SET_QPEL_FUNCS0123(PFX, IDX, SIZE, CPU, PREFIX) \
do { \
-SET_QPEL_FUNCS0123(PFX, IDX, SIZE, CPU, PREFIX); \
+c->PFX ## _pixels_tab[IDX][ 0] = PREFIX ## PFX ## SIZE ## _mc00_ ## CPU; \
+SET_QPEL_FUNCS123(PFX, IDX, SIZE, CPU, PREFIX); \
+} while (0)
+#define SET_QPEL_FUNCS_1PP(PFX, IDX, SIZE, CPU, PREFIX) \
+do { \
+SET_QPEL_FUNCS123(PFX, IDX, SIZE, CPU, PREFIX); \
c->PFX ## _pixels_tab[IDX][ 4] = PREFIX ## PFX ## SIZE ## _mc01_ ## CPU; \
c->PFX ## _pixels_tab[IDX][ 5] = PREFIX ## PFX ## SIZE ## _mc11_ ## CPU; \
c->PFX ## _pixels_tab[IDX][ 6] = PREFIX ## PFX ## SIZE ## _mc21_ ## CPU; \
@@ -447,6 +450,11 @@ LUMA_MC_816(10, mc33, sse2)
c->PFX ## _pixels_tab[IDX][14] = PREFIX ## PFX ## SIZE ## _mc23_ ## CPU; \
c->PFX ## _pixels_tab[IDX][15] = PREFIX ## PFX ## SIZE ## _mc33_ ## CPU; \
} while (0)
+#define SET_QPEL_FUNCS(PFX, IDX, SIZE, CPU, PREFIX) \
+do { \
+c->PFX ## _pixels_tab[IDX][ 0] = PREFIX ## PFX ## SIZE ## _mc00_ ## CPU; \
+SET_QPEL_FUNCS_1PP(PFX, IDX, SIZE, CPU, PREFIX); \
+} while (0)
#define H264_QPEL_FUNCS(x, y, CPU)
\
do
