Re: [FFmpeg-devel] [PATCH 14/42] avcodec/hevcdec: Use RefStruct API for RefPicListTap buffer
Quoting Andreas Rheinhardt (2023-10-02 13:07:14) > Anton Khirnov: > > Quoting Andreas Rheinhardt (2023-09-19 21:57:06) > >> avcodec/hevcdec: Use RefStruct API for RefPicListTap buffer > > ^ > > b > > > >> Given that the RefStruct API relies on the user to know > >> the size of the objects and does not provide a way to get it, > > > > Is there a reason you decided not to provide it, or there just wasn't > > any code that would be improved by it? > > > > In this example, there would be no improvement if RefStruct recorded the > size (in bytes) and provided a getter for it. > > In general, the philosophy of the RefStruct API is that the user and not > the API knows what is in the user data. So the user has to keep track of > stuff like this in cases where the user doesn't know it. > > The only scenario where keeping track of the size would be advantageous > would be for using arrays-of-whatever if the callbacks provided the size > as a parameter (to be ignored by most users), because one could then > derive the number of elements from it. I pondered this, but given that > the AVBuffer API doesn't do so either, I didn't do it. Shall I change this? I'm leaning towards no, it's overly specific and the advantage probably small. -- 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 17/42] avcodec/refstruct: Add RefStruct pool API
Quoting Andreas Rheinhardt (2023-09-19 21:57:09) > Very similar to the AVBufferPool API, but with some differences: > 1. Reusing an already existing entry does not incur an allocation > at all any more (the AVBufferPool API needs to allocate an AVBufferRef). > 2. The tasks done while holding the lock are smaller; e.g. > allocating new entries is now performed without holding the lock. > The same goes for freeing. > 3. The entries are freed as soon as possible (the AVBufferPool API > frees them in two batches: The first in av_buffer_pool_uninit() and > the second immediately before the pool is freed when the last > outstanding entry is returned to the pool). > 4. The API is designed for objects and not naked buffers and > therefore has a reset callback. This is called whenever an object > is returned to the pool. > 5. Just like with the RefStruct API, custom allocators are not > supported. > > (If desired, the FFRefStructPool struct itself could be made > reference counted via the RefStruct API; an FFRefStructPool > would then be freed via ff_refstruct_unref().) Considering that it's intended to be used from multiple threads, that seems like the better option. Though I have not seen the following patches yet, so maybe the advantage is not as big as I'd think. > +/** > + * If this flag is not set, every object in the pool will be zeroed before > + * the init callback is called or before it is turned over to the user > + * for the first time if no init callback has been provided. > + */ > +#define FF_REFSTRUCT_POOL_FLAG_NO_ZEROING > FF_REFSTRUCT_FLAG_NO_ZEROING Do you think using the same namespace really improves things? It does not seem so to 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 17/42] avcodec/refstruct: Add RefStruct pool API
Anton Khirnov: > Quoting Andreas Rheinhardt (2023-09-19 21:57:09) >> Very similar to the AVBufferPool API, but with some differences: >> 1. Reusing an already existing entry does not incur an allocation >> at all any more (the AVBufferPool API needs to allocate an AVBufferRef). >> 2. The tasks done while holding the lock are smaller; e.g. >> allocating new entries is now performed without holding the lock. >> The same goes for freeing. >> 3. The entries are freed as soon as possible (the AVBufferPool API >> frees them in two batches: The first in av_buffer_pool_uninit() and >> the second immediately before the pool is freed when the last >> outstanding entry is returned to the pool). >> 4. The API is designed for objects and not naked buffers and >> therefore has a reset callback. This is called whenever an object >> is returned to the pool. >> 5. Just like with the RefStruct API, custom allocators are not >> supported. >> >> (If desired, the FFRefStructPool struct itself could be made >> reference counted via the RefStruct API; an FFRefStructPool >> would then be freed via ff_refstruct_unref().) > > Considering that it's intended to be used from multiple threads, that > seems like the better option. Though I have not seen the following > patches yet, so maybe the advantage is not as big as I'd think. > It is implemented in patch #24. >> +/** >> + * If this flag is not set, every object in the pool will be zeroed before >> + * the init callback is called or before it is turned over to the user >> + * for the first time if no init callback has been provided. >> + */ >> +#define FF_REFSTRUCT_POOL_FLAG_NO_ZEROING >> FF_REFSTRUCT_FLAG_NO_ZEROING > > Do you think using the same namespace really improves things? It does > not seem so to me. > Actually, the namespaces are separate. The pool API uses FF_REFSTRUCT_POOL_FLAG_*, the ordinary RefStruct API uses FF_REFSTRUCT_FLAG_*. That some pool flags are simply mapped to non-pool flags is an implementation detail and does not join the namespaces. - 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 00/11 v6] AVCodecContext and AVCodecParameters side data
Changes since the previous version:
- Zeroed padding to side data allocated by av_packet_side_data_new() (Patch 1).
- Renamed AVCodecParameters.{nb,}side_data to {nb,}coded_side_data, to both
match the name in AVCodecContext and keep the side_data name free for future
use (Patch 2).
- Rewritten documentation to AVPacketSideData (Patch 4)
- Display Matrix global side data is now propagated to output frames (Patch 9).
Will add version bumps and APIChanges entries and push the set later this week
unless there are objections.
James Almer (11):
avcodec/packet: add generic side data helpers
avcodec/codec_par: add side data to AVCodecParameters
avformat/avformat: use the side data from AVStream.codecpar
avcodec/packet: add some documentation for AVPacketSideData
fftools/ffmpeg: stop using AVStream.side_data
fftools/ffplay: stop using AVStream.side_data
fftools/ffprobe: stop using AVStream.side_data
avcodec/hevcdec: check for DOVI configuration record in AVCodecContext
side data
avcodec/decode: propagate global side data to frames
fftools/ffmpeg: stop injecting stream side data in packets
fftools/ffplay: stop injecting stream side data in packets
fftools/ffmpeg_demux.c| 31 +--
fftools/ffmpeg_enc.c | 32 +--
fftools/ffmpeg_filter.c | 7 +-
fftools/ffmpeg_mux_init.c | 24 ++-
fftools/ffplay.c | 11 +-
fftools/ffprobe.c | 30 ++-
libavcodec/avcodec.h | 2 +-
libavcodec/avpacket.c | 101 +
libavcodec/codec_par.c| 48 +
libavcodec/codec_par.h| 11 +
libavcodec/decode.c | 60 +-
libavcodec/decode.h | 6 +
libavcodec/hevcdec.c | 15 +-
libavcodec/packet.h | 115 ++-
libavdevice/android_camera.c | 10 +-
libavformat/avformat.c| 42 +---
libavformat/avformat.h| 28 ++-
libavformat/concatdec.c | 1 -
libavformat/dashdec.c | 11 -
libavformat/demux.c | 53 +++--
libavformat/demux_utils.c | 4 +
libavformat/dovi_isom.c | 8 +-
libavformat/dump.c| 6 +-
libavformat/hls.c | 11 -
libavformat/hlsenc.c | 11 +-
libavformat/internal.h| 4 +
libavformat/matroskadec.c | 47 +++--
libavformat/matroskaenc.c | 55 +++--
libavformat/mov.c | 92 +
libavformat/movenc.c | 94 +
libavformat/mp3enc.c | 10 +-
libavformat/mpegenc.c | 22 +-
libavformat/mpegts.c | 10 +-
libavformat/mux.c | 21 ++
libavformat/mxfdec.c | 25 ++-
libavformat/mxfenc.c | 12 +-
libavformat/options.c | 2 +
libavformat/replaygain.c | 10 +-
libavformat/seek.c| 2 +
libavformat/version_major.h | 1 +
tests/ref/fate/autorotate | 4 +-
tests/ref/fate/copy-trac3074 | 2 +-
tests/ref/fate/hevc-dv-rpu| 18 ++
tests/ref/fate/matroska-avoid-negative-ts | 2 +-
tests/ref/fate/matroska-dovi-write-config7| 2 +-
tests/ref/fate/matroska-dovi-write-config8| 2 +-
tests/ref/fate/matroska-encoding-delay| 2 +-
.../fate/matroska-mastering-display-metadata | 4 +-
tests/ref/fate/matroska-spherical-mono-remux | 4 +-
tests/ref/fate/matroska-stereo_mode | 8 +-
tests/ref/fate/matroska-vp8-alpha-remux | 2 +-
.../ref/fate/mov-mp4-disposition-mpegts-remux | 4 +-
tests/ref/fate/mov-zombie | 195 --
tests/ref/fate/mxf-d10-user-comments | 2 +-
tests/ref/fate/mxf-remux-applehdr10 | 2 +-
tests/ref/fate/vp9-superframe-bsf | 2 +-
56 files changed, 909 insertions(+), 431 deletions(-)
--
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 01/11] avcodec/packet: add generic side data helpers
Handling AVPacketSideData directly, which can used on structs other than
AVPacket.
This will be useful in the following commits.
Signed-off-by: James Almer
---
libavcodec/avpacket.c | 101 ++
libavcodec/packet.h | 96 +--
2 files changed, 193 insertions(+), 4 deletions(-)
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 9ec1feb068..f29a205af2 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -646,3 +646,104 @@ int ff_side_data_set_prft(AVPacket *pkt, int64_t
timestamp)
return 0;
}
+
+const AVPacketSideData *av_packet_side_data_get(const AVPacketSideData *sd,
int nb_sd,
+enum AVPacketSideDataType type)
+{
+for (int i = 0; i < nb_sd; i++)
+if (sd[i].type == type)
+return &sd[i];
+
+return NULL;
+}
+
+static AVPacketSideData *packet_side_data_add(AVPacketSideData **psd, int
*pnb_sd,
+ enum AVPacketSideDataType type,
+ void *data, size_t size)
+{
+AVPacketSideData *sd = *psd, *tmp;
+int nb_sd = *pnb_sd;
+
+for (int i = 0; i < nb_sd; i++) {
+if (sd[i].type != type)
+continue;
+
+av_free(sd[i].data);
+sd[i].data = data;
+sd[i].size = size;
+return &sd[i];
+}
+
+if (nb_sd == INT_MAX)
+return NULL;
+
+tmp = av_realloc_array(sd, nb_sd + 1, sizeof(*tmp));
+if (!tmp)
+return NULL;
+
+*psd = sd = tmp;
+sd[nb_sd].type = type;
+sd[nb_sd].data = data;
+sd[nb_sd].size = size;
+*pnb_sd = nb_sd + 1;
+
+return &sd[nb_sd];
+}
+
+AVPacketSideData *av_packet_side_data_add(AVPacketSideData **psd, int *pnb_sd,
+ enum AVPacketSideDataType type,
+ void *data, size_t size, int flags)
+{
+return packet_side_data_add(psd, pnb_sd, type, data, size);
+}
+
+AVPacketSideData *av_packet_side_data_new(AVPacketSideData **psd, int *pnb_sd,
+ enum AVPacketSideDataType type,
+ size_t size, int flags)
+{
+AVPacketSideData *sd = NULL;
+uint8_t *data;
+
+if (size > SIZE_MAX - AV_INPUT_BUFFER_PADDING_SIZE)
+return NULL;
+
+data = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!data)
+return NULL;
+
+memset(data + size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
+sd = packet_side_data_add(psd, pnb_sd, type, data, size);
+if (!sd)
+av_freep(&data);
+
+return sd;
+}
+
+void av_packet_side_data_remove(AVPacketSideData *sd, int *pnb_sd,
+enum AVPacketSideDataType type)
+{
+int nb_sd = *pnb_sd;
+
+for (int i = nb_sd - 1; i >= 0; i--) {
+if (sd[i].type != type)
+continue;
+av_free(sd[i].data);
+sd[i] = sd[--nb_sd];
+break;
+}
+
+*pnb_sd = nb_sd;
+}
+
+void av_packet_side_data_free(AVPacketSideData **psd, int *pnb_sd)
+{
+AVPacketSideData *sd = *psd;
+int nb_sd = *pnb_sd;
+
+for (int i = 0; i < nb_sd; i++)
+av_free(sd[i].data);
+
+av_freep(psd);
+*pnb_sd = 0;
+}
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index f28e7e7011..96fc0084d6 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -33,9 +33,9 @@
#include "libavcodec/version_major.h"
/**
- * @defgroup lavc_packet AVPacket
+ * @defgroup lavc_packet_side_data AVPacketSideData
*
- * Types and functions for working with AVPacket.
+ * Types and functions for working with AVPacketSideData.
* @{
*/
enum AVPacketSideDataType {
@@ -318,6 +318,96 @@ typedef struct AVPacketSideData {
enum AVPacketSideDataType type;
} AVPacketSideData;
+/**
+ * Allocate a new packet side data.
+ *
+ * @param sdpointer to an array of side data to which the side data should
+ * be added. *sd may be NULL, in which case the array will be
+ * initialized.
+ * @param nb_sd pointer to an integer containing the number of entries in
+ * the array. The integer value will be increased by 1 on success.
+ * @param type side data type
+ * @param size desired side data size
+ * @param flags currently unused. Must be zero
+ *
+ * @return pointer to freshly allocated side data on success, or NULL
otherwise.
+ */
+AVPacketSideData *av_packet_side_data_new(AVPacketSideData **psd, int *pnb_sd,
+ enum AVPacketSideDataType type,
+ size_t size, int flags);
+
+/**
+ * Wrap existing data as packet side data.
+ *
+ * @param sdpointer to an array of side data to which the side data should
+ * be added. *sd may be NULL, in which case the array will be
+ * initialized
+ * @param nb_sd pointer to an integer containing the
[FFmpeg-devel] [PATCH 02/11] avcodec/codec_par: add side data to AVCodecParameters
This will simplify the propagation of side data to decoders and from encoders.
Global side data will now reside in the AVCodecContext, thus be available
during init(), removing the need to propagate it inside packets.
Global and frame specific side data will therefore be distinct.
Signed-off-by: James Almer
---
libavcodec/codec_par.c | 48 ++
libavcodec/codec_par.h | 11 ++
2 files changed, 59 insertions(+)
diff --git a/libavcodec/codec_par.c b/libavcodec/codec_par.c
index e4e4cd48d3..abaac63841 100644
--- a/libavcodec/codec_par.c
+++ b/libavcodec/codec_par.c
@@ -27,11 +27,13 @@
#include "libavutil/mem.h"
#include "avcodec.h"
#include "codec_par.h"
+#include "packet.h"
static void codec_parameters_reset(AVCodecParameters *par)
{
av_freep(&par->extradata);
av_channel_layout_uninit(&par->ch_layout);
+av_packet_side_data_free(&par->coded_side_data, &par->nb_coded_side_data);
memset(par, 0, sizeof(*par));
@@ -72,6 +74,35 @@ void avcodec_parameters_free(AVCodecParameters **ppar)
av_freep(ppar);
}
+static int codec_parameters_copy_side_data(AVPacketSideData **pdst, int
*pnb_dst,
+ const AVPacketSideData *src, int
nb_src)
+{
+AVPacketSideData *dst;
+int nb_dst = *pnb_dst;
+
+if (!src)
+return 0;
+
+*pdst = dst = av_calloc(nb_src, sizeof(*dst));
+if (!dst)
+return AVERROR(ENOMEM);
+
+for (int i = 0; i < nb_src; i++) {
+const AVPacketSideData *src_sd = &src[i];
+AVPacketSideData *dst_sd = &dst[i];
+
+dst_sd->data = av_memdup(src_sd->data, src_sd->size);
+if (!dst_sd->data)
+return AVERROR(ENOMEM);
+
+dst_sd->type = src_sd->type;
+dst_sd->size = src_sd->size;
+*pnb_dst = ++nb_dst;
+}
+
+return 0;
+}
+
int avcodec_parameters_copy(AVCodecParameters *dst, const AVCodecParameters
*src)
{
int ret;
@@ -82,6 +113,8 @@ int avcodec_parameters_copy(AVCodecParameters *dst, const
AVCodecParameters *src
dst->ch_layout = (AVChannelLayout){0};
dst->extradata = NULL;
dst->extradata_size = 0;
+dst->coded_side_data = NULL;
+dst->nb_coded_side_data = 0;
if (src->extradata) {
dst->extradata = av_mallocz(src->extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
if (!dst->extradata)
@@ -89,6 +122,10 @@ int avcodec_parameters_copy(AVCodecParameters *dst, const
AVCodecParameters *src
memcpy(dst->extradata, src->extradata, src->extradata_size);
dst->extradata_size = src->extradata_size;
}
+ret = codec_parameters_copy_side_data(&dst->coded_side_data,
&dst->nb_coded_side_data,
+ src->coded_side_data,
src->nb_coded_side_data);
+if (ret < 0)
+return ret;
ret = av_channel_layout_copy(&dst->ch_layout, &src->ch_layout);
if (ret < 0)
@@ -178,6 +215,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
par->extradata_size = codec->extradata_size;
}
+ret = codec_parameters_copy_side_data(&par->coded_side_data,
&par->nb_coded_side_data,
+ codec->coded_side_data,
codec->nb_coded_side_data);
+if (ret < 0)
+return ret;
+
return 0;
}
@@ -262,5 +304,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
codec->extradata_size = par->extradata_size;
}
+av_packet_side_data_free(&codec->coded_side_data,
&codec->nb_coded_side_data);
+ret = codec_parameters_copy_side_data(&codec->coded_side_data,
&codec->nb_coded_side_data,
+ par->coded_side_data,
par->nb_coded_side_data);
+if (ret < 0)
+return ret;
+
return 0;
}
diff --git a/libavcodec/codec_par.h b/libavcodec/codec_par.h
index c1679ea042..64882a9726 100644
--- a/libavcodec/codec_par.h
+++ b/libavcodec/codec_par.h
@@ -30,6 +30,7 @@
#include "codec_id.h"
#include "defs.h"
+#include "packet.h"
/**
* @addtogroup lavc_core
@@ -215,6 +216,16 @@ typedef struct AVCodecParameters {
* when no higher-level timing information is available.
*/
AVRational framerate;
+
+/**
+ * Additional data associated with the entire stream.
+ */
+AVPacketSideData *coded_side_data;
+
+/**
+ * Amount of entries in @ref coded_side_data.
+ */
+int nb_coded_side_data;
} AVCodecParameters;
/**
--
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 04/11] avcodec/packet: add some documentation for AVPacketSideData
Explaining what or who may use it, and in what scenarios.
Signed-off-by: James Almer
---
libavcodec/packet.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index 96fc0084d6..85b3eeb728 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -312,6 +312,25 @@ enum AVPacketSideDataType {
#define AV_PKT_DATA_QUALITY_FACTOR AV_PKT_DATA_QUALITY_STATS //DEPRECATED
+/**
+ * This structure stores information for decoding, presenting, or otherwise
+ * processing the coded stream. It is typically exported by demuxers and
+ * encoders and can be fed to decoders and muxers in a per packet basis, or as
+ * global side data (applying to the entire coded stream) as follows:
+ * - During demuxing, it will be exported through global side data in
+ * @ref AVStream.codecpar.side_data "AVStream's codec parameters", which can
+ * then be passed as input to decoders through the
+ * @ref AVCodecContext.coded_side_data "decoder context's side data", for
+ * initialization.
+ * - For muxing, it can be fed through global side data in
+ * @ref AVStream.codecpar.side_data "AVStream's codec parameters", typically
+ * the output of encoders through the @ref AVCodecContext.coded_side_data
+ * "encoder context's side data", for initialization.
+ *
+ * Different modules may accept or export different types of side data
+ * depending on media type and codec. Refer to @ref AVPacketSideDataType for a
+ * list of defined types and where they may be found or used.
+ */
typedef struct AVPacketSideData {
uint8_t *data;
size_t size;
--
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 03/11] avformat/avformat: use the side data from AVStream.codecpar
Deprecate AVStream.side_data and its helpers in favor of the AVStream's
codecpar.side_data.
This will considerably simplify the propagation of global side data to decoders
and from encoders. Instead of having to do it inside packets, it will be
available during init().
Global and frame specific side data will therefore be distinct.
Signed-off-by: James Almer
---
libavdevice/android_camera.c | 10 ++--
libavformat/avformat.c | 42 +++-
libavformat/avformat.h | 28 ++-
libavformat/concatdec.c | 1 -
libavformat/dashdec.c| 11 -
libavformat/demux.c | 53
libavformat/demux_utils.c| 4 ++
libavformat/dovi_isom.c | 8 ++-
libavformat/dump.c | 6 +--
libavformat/hls.c| 11 -
libavformat/hlsenc.c | 11 +++--
libavformat/internal.h | 4 ++
libavformat/matroskadec.c| 47 +-
libavformat/matroskaenc.c| 55 +
libavformat/mov.c| 92 +++
libavformat/movenc.c | 94
libavformat/mp3enc.c | 10 ++--
libavformat/mpegenc.c| 22 ++---
libavformat/mpegts.c | 10 ++--
libavformat/mux.c| 21
libavformat/mxfdec.c | 25 ++
libavformat/mxfenc.c | 12 +++--
libavformat/options.c| 2 +
libavformat/replaygain.c | 10 ++--
libavformat/seek.c | 2 +
libavformat/version_major.h | 1 +
26 files changed, 339 insertions(+), 253 deletions(-)
diff --git a/libavdevice/android_camera.c b/libavdevice/android_camera.c
index 0425b27518..602b59047d 100644
--- a/libavdevice/android_camera.c
+++ b/libavdevice/android_camera.c
@@ -639,7 +639,7 @@ static int wait_for_image_format(AVFormatContext *avctx)
static int add_display_matrix(AVFormatContext *avctx, AVStream *st)
{
AndroidCameraCtx *ctx = avctx->priv_data;
-uint8_t *side_data;
+AVPacketSideData *side_data;
int32_t display_matrix[9];
av_display_rotation_set(display_matrix, ctx->sensor_orientation);
@@ -648,14 +648,16 @@ static int add_display_matrix(AVFormatContext *avctx,
AVStream *st)
av_display_matrix_flip(display_matrix, 1, 0);
}
-side_data = av_stream_new_side_data(st,
-AV_PKT_DATA_DISPLAYMATRIX, sizeof(display_matrix));
+side_data = av_packet_side_data_new(&st->codecpar->side_data,
+&st->codecpar->nb_side_data,
+AV_PKT_DATA_DISPLAYMATRIX,
+sizeof(display_matrix), 0);
if (!side_data) {
return AVERROR(ENOMEM);
}
-memcpy(side_data, display_matrix, sizeof(display_matrix));
+memcpy(side_data->data, display_matrix, sizeof(display_matrix));
return 0;
}
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 7ff0cf3429..5b8bb7879e 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -48,9 +48,13 @@ void ff_free_stream(AVStream **pst)
if (!st)
return;
+#if FF_API_AVSTREAM_SIDE_DATA
+FF_DISABLE_DEPRECATION_WARNINGS
for (int i = 0; i < st->nb_side_data; i++)
av_freep(&st->side_data[i].data);
av_freep(&st->side_data);
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
if (st->attached_pic.data)
av_packet_unref(&st->attached_pic);
@@ -140,6 +144,8 @@ void avformat_free_context(AVFormatContext *s)
av_free(s);
}
+#if FF_API_AVSTREAM_SIDE_DATA
+FF_DISABLE_DEPRECATION_WARNINGS
uint8_t *av_stream_get_side_data(const AVStream *st,
enum AVPacketSideDataType type, size_t *size)
{
@@ -207,36 +213,8 @@ uint8_t *av_stream_new_side_data(AVStream *st, enum
AVPacketSideDataType type,
return data;
}
-
-int ff_stream_side_data_copy(AVStream *dst, const AVStream *src)
-{
-/* Free existing side data*/
-for (int i = 0; i < dst->nb_side_data; i++)
-av_free(dst->side_data[i].data);
-av_freep(&dst->side_data);
-dst->nb_side_data = 0;
-
-/* Copy side data if present */
-if (src->nb_side_data) {
-dst->side_data = av_calloc(src->nb_side_data,
- sizeof(*dst->side_data));
-if (!dst->side_data)
-return AVERROR(ENOMEM);
-dst->nb_side_data = src->nb_side_data;
-
-for (int i = 0; i < src->nb_side_data; i++) {
-uint8_t *data = av_memdup(src->side_data[i].data,
- src->side_data[i].size);
-if (!data)
-return AVERROR(ENOMEM);
-dst->side_data[i].type = src->side_data[i].type;
-dst->side_data[i].size = src->side_data[i].size;
-dst->side_data[i].data = data;
-}
-}
-
-return 0;
-}
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
/**
* Copy all stream parameters from source to destination stream, with the
@@ -272,10
[FFmpeg-devel] [PATCH 05/11] fftools/ffmpeg: stop using AVStream.side_data
Signed-off-by: James Almer
---
fftools/ffmpeg_demux.c| 13 +
fftools/ffmpeg_enc.c | 32 ++--
fftools/ffmpeg_filter.c | 7 ++-
fftools/ffmpeg_mux_init.c | 24 ++--
4 files changed, 39 insertions(+), 37 deletions(-)
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index c01852d4cf..296a66cd11 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -482,8 +482,8 @@ static int input_packet_process(Demuxer *d, DemuxMsg *msg,
AVPacket *src)
/* add the stream-global side data to the first packet */
if (ds->nb_packets == 1) {
-for (int i = 0; i < ist->st->nb_side_data; i++) {
-AVPacketSideData *src_sd = &ist->st->side_data[i];
+for (int i = 0; i < ist->st->codecpar->nb_coded_side_data; i++) {
+AVPacketSideData *src_sd = &ist->st->codecpar->coded_side_data[i];
uint8_t *dst_data;
if (src_sd->type == AV_PKT_DATA_DISPLAYMATRIX)
@@ -979,6 +979,7 @@ static int add_display_matrix_to_stream(const
OptionsContext *o,
AVFormatContext *ctx, InputStream *ist)
{
AVStream *st = ist->st;
+AVPacketSideData *sd;
double rotation = DBL_MAX;
int hflip = -1, vflip = -1;
int hflip_set = 0, vflip_set = 0, rotation_set = 0;
@@ -995,12 +996,16 @@ static int add_display_matrix_to_stream(const
OptionsContext *o,
if (!rotation_set && !hflip_set && !vflip_set)
return 0;
-buf = (int32_t *)av_stream_new_side_data(st, AV_PKT_DATA_DISPLAYMATRIX,
sizeof(int32_t) * 9);
-if (!buf) {
+sd = av_packet_side_data_new(&st->codecpar->coded_side_data,
+ &st->codecpar->nb_coded_side_data,
+ AV_PKT_DATA_DISPLAYMATRIX,
+ sizeof(int32_t) * 9, 0);
+if (!sd) {
av_log(ist, AV_LOG_FATAL, "Failed to generate a display matrix!\n");
return AVERROR(ENOMEM);
}
+buf = (int32_t *)sd->data;
av_display_rotation_set(buf,
rotation_set ? -(rotation) : -0.0f);
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index ec9cebbd96..be35465c28 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -457,20 +457,6 @@ int enc_open(OutputStream *ost, AVFrame *frame)
return ret;
}
-if (ost->enc_ctx->nb_coded_side_data) {
-int i;
-
-for (i = 0; i < ost->enc_ctx->nb_coded_side_data; i++) {
-const AVPacketSideData *sd_src = &ost->enc_ctx->coded_side_data[i];
-uint8_t *dst_data;
-
-dst_data = av_stream_new_side_data(ost->st, sd_src->type,
sd_src->size);
-if (!dst_data)
-return AVERROR(ENOMEM);
-memcpy(dst_data, sd_src->data, sd_src->size);
-}
-}
-
/*
* Add global input side data. For now this is naive, and copies it
* from the input stream's global side data. All side data should
@@ -480,15 +466,17 @@ int enc_open(OutputStream *ost, AVFrame *frame)
*/
if (ist) {
int i;
-for (i = 0; i < ist->st->nb_side_data; i++) {
-AVPacketSideData *sd = &ist->st->side_data[i];
-if (sd->type != AV_PKT_DATA_CPB_PROPERTIES) {
-uint8_t *dst = av_stream_new_side_data(ost->st, sd->type,
sd->size);
-if (!dst)
+for (i = 0; i < ist->st->codecpar->nb_coded_side_data; i++) {
+AVPacketSideData *sd_src = &ist->st->codecpar->coded_side_data[i];
+if (sd_src->type != AV_PKT_DATA_CPB_PROPERTIES) {
+AVPacketSideData *sd_dst =
av_packet_side_data_new(&ost->par_in->coded_side_data,
+
&ost->par_in->nb_coded_side_data,
+
sd_src->type, sd_src->size, 0);
+if (!sd_dst)
return AVERROR(ENOMEM);
-memcpy(dst, sd->data, sd->size);
-if (ist->autorotate && sd->type == AV_PKT_DATA_DISPLAYMATRIX)
-av_display_rotation_set((int32_t *)dst, 0);
+memcpy(sd_dst->data, sd_src->data, sd_src->size);
+if (ist->autorotate && sd_src->type ==
AV_PKT_DATA_DISPLAYMATRIX)
+av_display_rotation_set((int32_t *)sd_dst->data, 0);
}
}
}
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index b6348d7f87..b71a84185a 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1383,11 +1383,16 @@ static int configure_input_video_filter(FilterGraph
*fg, InputFilter *ifilter,
// TODO: insert hwaccel enabled filters like transpose_vaapi into the graph
if (ist->autorotate && !(desc->flags & AV_PIX_FMT_FLAG_HWACCEL)) {
+const AVPacketSideData *sd = NULL;
int32_t *displaymatrix = ifp->displaymatrix;
[FFmpeg-devel] [PATCH 06/11] fftools/ffplay: stop using AVStream.side_data
Signed-off-by: James Almer
---
fftools/ffplay.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 006da7ab57..f5354575c9 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1916,8 +1916,13 @@ static int configure_video_filters(AVFilterGraph *graph,
VideoState *is, const c
AVFrameSideData *sd = av_frame_get_side_data(frame,
AV_FRAME_DATA_DISPLAYMATRIX);
if (sd)
displaymatrix = (int32_t *)sd->data;
-if (!displaymatrix)
-displaymatrix = (int32_t *)av_stream_get_side_data(is->video_st,
AV_PKT_DATA_DISPLAYMATRIX, NULL);
+if (!displaymatrix) {
+const AVPacketSideData *sd =
av_packet_side_data_get(is->video_st->codecpar->coded_side_data,
+
is->video_st->codecpar->nb_coded_side_data,
+
AV_PKT_DATA_DISPLAYMATRIX);
+if (sd)
+displaymatrix = (int32_t *)sd->data;
+}
theta = get_rotation(displaymatrix);
if (fabs(theta - 90) < 1.0) {
--
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 07/11] fftools/ffprobe: stop using AVStream.side_data
Signed-off-by: James Almer
---
fftools/ffprobe.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index c20f464623..dc3250e3a2 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2279,16 +2279,9 @@ static void
print_ambient_viewing_environment(WriterContext *w,
static void print_pkt_side_data(WriterContext *w,
AVCodecParameters *par,
-const AVPacketSideData *side_data,
-int nb_side_data,
-SectionID id_data_list,
+const AVPacketSideData *sd,
SectionID id_data)
{
-int i;
-
-writer_print_section_header(w, id_data_list);
-for (i = 0; i < nb_side_data; i++) {
-const AVPacketSideData *sd = &side_data[i];
const char *name = av_packet_side_data_name(sd->type);
writer_print_section_header(w, id_data);
@@ -2382,9 +2375,6 @@ static void print_pkt_side_data(WriterContext *w,
} else if (sd->type == AV_PKT_DATA_AFD && sd->size > 0) {
print_int("active_format", *sd->data);
}
-writer_print_section_footer(w);
-}
-writer_print_section_footer(w);
}
static void print_private_data(WriterContext *w, void *priv_data)
@@ -2544,9 +2534,13 @@ static void show_packet(WriterContext *w, InputFile
*ifile, AVPacket *pkt, int p
av_dict_free(&dict);
}
-print_pkt_side_data(w, st->codecpar, pkt->side_data,
pkt->side_data_elems,
-SECTION_ID_PACKET_SIDE_DATA_LIST,
+writer_print_section_header(w, SECTION_ID_PACKET_SIDE_DATA_LIST);
+for (int i = 0; i < pkt->side_data_elems; i++) {
+print_pkt_side_data(w, st->codecpar, &pkt->side_data[i],
SECTION_ID_PACKET_SIDE_DATA);
+writer_print_section_footer(w);
+}
+writer_print_section_footer(w);
}
writer_print_section_footer(w);
@@ -3188,10 +3182,14 @@ static int show_stream(WriterContext *w,
AVFormatContext *fmt_ctx, int stream_id
if (do_show_stream_tags)
ret = show_tags(w, stream->metadata, in_program ?
SECTION_ID_PROGRAM_STREAM_TAGS : SECTION_ID_STREAM_TAGS);
-if (stream->nb_side_data) {
-print_pkt_side_data(w, stream->codecpar, stream->side_data,
stream->nb_side_data,
-SECTION_ID_STREAM_SIDE_DATA_LIST,
+if (stream->codecpar->nb_coded_side_data) {
+writer_print_section_header(w, SECTION_ID_STREAM_SIDE_DATA_LIST);
+for (int i = 0; i < stream->codecpar->nb_coded_side_data; i++) {
+print_pkt_side_data(w, stream->codecpar,
&stream->codecpar->coded_side_data[i],
SECTION_ID_STREAM_SIDE_DATA);
+writer_print_section_footer(w);
+}
+writer_print_section_footer(w);
}
writer_print_section_footer(w);
--
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 10/11] fftools/ffmpeg: stop injecting stream side data in packets
This is no longer needed as the side data is available for decoders in the
AVCodecContext.
The tests affected reflect the removal of useless CPB and Stereo 3D side
data in packets.
Signed-off-by: James Almer
---
fftools/ffmpeg_demux.c| 22 ---
tests/ref/fate/autorotate | 4 ++--
tests/ref/fate/copy-trac3074 | 2 +-
tests/ref/fate/matroska-avoid-negative-ts | 2 +-
tests/ref/fate/matroska-dovi-write-config7| 2 +-
tests/ref/fate/matroska-dovi-write-config8| 2 +-
tests/ref/fate/matroska-encoding-delay| 2 +-
.../fate/matroska-mastering-display-metadata | 4 ++--
tests/ref/fate/matroska-spherical-mono-remux | 4 ++--
tests/ref/fate/matroska-stereo_mode | 8 +++
tests/ref/fate/matroska-vp8-alpha-remux | 2 +-
.../ref/fate/mov-mp4-disposition-mpegts-remux | 4 ++--
tests/ref/fate/mxf-d10-user-comments | 2 +-
tests/ref/fate/mxf-remux-applehdr10 | 2 +-
tests/ref/fate/vp9-superframe-bsf | 2 +-
15 files changed, 21 insertions(+), 43 deletions(-)
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 296a66cd11..c71edf01a5 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -480,28 +480,6 @@ static int input_packet_process(Demuxer *d, DemuxMsg *msg,
AVPacket *src)
ds->data_size += pkt->size;
ds->nb_packets++;
-/* add the stream-global side data to the first packet */
-if (ds->nb_packets == 1) {
-for (int i = 0; i < ist->st->codecpar->nb_coded_side_data; i++) {
-AVPacketSideData *src_sd = &ist->st->codecpar->coded_side_data[i];
-uint8_t *dst_data;
-
-if (src_sd->type == AV_PKT_DATA_DISPLAYMATRIX)
-continue;
-
-if (av_packet_get_side_data(pkt, src_sd->type, NULL))
-continue;
-
-dst_data = av_packet_new_side_data(pkt, src_sd->type,
src_sd->size);
-if (!dst_data) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-
-memcpy(dst_data, src_sd->data, src_sd->size);
-}
-}
-
if (debug_ts) {
av_log(NULL, AV_LOG_INFO, "demuxer+ffmpeg -> ist_index:%d:%d type:%s
pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s duration:%s
duration_time:%s off:%s off_time:%s\n",
f->index, pkt->stream_index,
diff --git a/tests/ref/fate/autorotate b/tests/ref/fate/autorotate
index dff628bbff..2aa29fafa7 100644
--- a/tests/ref/fate/autorotate
+++ b/tests/ref/fate/autorotate
@@ -11,8 +11,8 @@
#codec_id 1: ac3
#sample_rate 1: 44100
#channel_layout_name 1: mono
-0, -512, 0, 512, 6997, 0x55c700f6, S=1, 40
-1, -256, -256, 1536, 416, 0x92ddc529, S=2, 10,
4
+0, -512, 0, 512, 6997, 0x55c700f6
+1, -256, -256, 1536, 416, 0x92ddc529, S=1, 10
0, 0,512, 512, 4847, 0xe74f522e, F=0x0
1, 1280, 1280, 1536, 418, 0x0a7fcd2d
0,512, 1024, 512, 5281, 0xbd4a5dac, F=0x0
diff --git a/tests/ref/fate/copy-trac3074 b/tests/ref/fate/copy-trac3074
index b6d23f8c1c..53ba27e920 100644
--- a/tests/ref/fate/copy-trac3074
+++ b/tests/ref/fate/copy-trac3074
@@ -5,7 +5,7 @@
#codec_id 0: eac3
#sample_rate 0: 48000
#channel_layout_name 0: stereo
-0, 0, 0, 1536, 512, 0x2beaf79f, S=1,4
+0, 0, 0, 1536, 512, 0x2beaf79f
0, 1536, 1536, 1536, 512, 0x29ddf9d6
0, 3072, 3072, 1536, 512, 0xba0afa79
0, 4608, 4608, 1536, 512, 0xe019f394
diff --git a/tests/ref/fate/matroska-avoid-negative-ts
b/tests/ref/fate/matroska-avoid-negative-ts
index 880d53e1b0..22959695ec 100644
--- a/tests/ref/fate/matroska-avoid-negative-ts
+++ b/tests/ref/fate/matroska-avoid-negative-ts
@@ -11,7 +11,7 @@ fb4e7a969ef65f61c4c45d5976188aa2
*tests/data/fate/matroska-avoid-negative-ts.mat
#codec_id 1: mp3
#sample_rate 1: 44100
#channel_layout_name 1: mono
-0,-37, 43, 40, 9156, 0xe5bd034a, S=1, 40
+0,-37, 43, 40, 9156, 0xe5bd034a
1, 0, 0, 26, 417, 0x7198c15e
0, 3, 3, 40, 1740, 0x29ac4480, F=0x0
1, 26, 26, 26, 417, 0x3c67c32d
diff --git a/tests/ref/fate/matroska-dovi-write-config7
b/tests/ref/fate/matroska-dovi-write-config7
index aaeeb34751..dc5b73a44e 100644
--- a/tests/ref/fate/matroska-dovi-write-config7
+++ b/tests/ref/fate/matroska-dovi-write-config7
@@ -13,7 +13,7 @@
#dimensions 1: 1920x1080
#sar 1: 0/1
0,-83, 0, 41, 699, 0x728548f1
-1,-83, 0, 41, 1085, 0xfb2dba82, S=1,8
+1,-83, 0, 41, 1085, 0xfb2dba82
0,-42,167, 41, 95
[FFmpeg-devel] [PATCH 09/11] avcodec/decode: propagate global side data to frames
The changed references for fate-hevc-dv-rpu fate-mov-zombie happen because,
unlike ffmpeg and ffplay, ffprobe never injected packet side data, so the
display matrix side data at the container level is now present in the output
frames.
Signed-off-by: James Almer
---
libavcodec/decode.c| 50 --
tests/ref/fate/hevc-dv-rpu | 18
tests/ref/fate/mov-zombie | 195 -
3 files changed, 189 insertions(+), 74 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index d81c418e10..0dfa061255 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1425,6 +1425,21 @@ static int add_metadata_from_side_data(const AVPacket
*avpkt, AVFrame *frame)
return av_packet_unpack_dictionary(side_metadata, size, frame_md);
}
+static const struct {
+enum AVPacketSideDataType packet;
+enum AVFrameSideDataType frame;
+} sd_global_map[] = {
+{ AV_PKT_DATA_REPLAYGAIN ,AV_FRAME_DATA_REPLAYGAIN },
+{ AV_PKT_DATA_DISPLAYMATRIX, AV_FRAME_DATA_DISPLAYMATRIX },
+{ AV_PKT_DATA_SPHERICAL, AV_FRAME_DATA_SPHERICAL },
+{ AV_PKT_DATA_STEREO3D, AV_FRAME_DATA_STEREO3D },
+{ AV_PKT_DATA_AUDIO_SERVICE_TYPE, AV_FRAME_DATA_AUDIO_SERVICE_TYPE
},
+{ AV_PKT_DATA_MASTERING_DISPLAY_METADATA,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA },
+{ AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
+{ AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE },
+{ AV_PKT_DATA_DYNAMIC_HDR10_PLUS, AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
+};
+
int ff_decode_frame_props_from_pkt(const AVCodecContext *avctx,
AVFrame *frame, const AVPacket *pkt)
{
@@ -1432,18 +1447,9 @@ int ff_decode_frame_props_from_pkt(const AVCodecContext
*avctx,
enum AVPacketSideDataType packet;
enum AVFrameSideDataType frame;
} sd[] = {
-{ AV_PKT_DATA_REPLAYGAIN ,AV_FRAME_DATA_REPLAYGAIN },
-{ AV_PKT_DATA_DISPLAYMATRIX, AV_FRAME_DATA_DISPLAYMATRIX
},
-{ AV_PKT_DATA_SPHERICAL, AV_FRAME_DATA_SPHERICAL },
-{ AV_PKT_DATA_STEREO3D, AV_FRAME_DATA_STEREO3D },
-{ AV_PKT_DATA_AUDIO_SERVICE_TYPE,
AV_FRAME_DATA_AUDIO_SERVICE_TYPE },
-{ AV_PKT_DATA_MASTERING_DISPLAY_METADATA,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA },
-{ AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
{ AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
{ AV_PKT_DATA_AFD,AV_FRAME_DATA_AFD },
-{ AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE },
{ AV_PKT_DATA_S12M_TIMECODE, AV_FRAME_DATA_S12M_TIMECODE
},
-{ AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
{ AV_PKT_DATA_SKIP_SAMPLES, AV_FRAME_DATA_SKIP_SAMPLES },
};
@@ -1456,6 +1462,18 @@ FF_DISABLE_DEPRECATION_WARNINGS
FF_ENABLE_DEPRECATION_WARNINGS
#endif
+for (int i = 0; i < FF_ARRAY_ELEMS(sd_global_map); i++) {
+size_t size;
+const uint8_t *packet_sd = av_packet_get_side_data(pkt,
sd_global_map[i].packet, &size);
+if (packet_sd) {
+AVFrameSideData *frame_sd;
+
+frame_sd = av_frame_new_side_data(frame, sd_global_map[i].frame,
size);
+if (!frame_sd)
+return AVERROR(ENOMEM);
+memcpy(frame_sd->data, packet_sd, size);
+}
+}
for (int i = 0; i < FF_ARRAY_ELEMS(sd); i++) {
size_t size;
uint8_t *packet_sd = av_packet_get_side_data(pkt, sd[i].packet, &size);
@@ -1491,6 +1509,20 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame
*frame)
{
int ret;
+for (int i = 0; i < FF_ARRAY_ELEMS(sd_global_map); i++) {
+const AVPacketSideData *packet_sd = ff_get_coded_side_data(avctx,
+
sd_global_map[i].packet);
+if (packet_sd) {
+AVFrameSideData *frame_sd = av_frame_new_side_data(frame,
+
sd_global_map[i].frame,
+
packet_sd->size);
+if (!frame_sd)
+return AVERROR(ENOMEM);
+
+memcpy(frame_sd->data, packet_sd->data, packet_sd->size);
+}
+}
+
if (!(ffcodec(avctx->codec)->caps_internal &
FF_CODEC_CAP_SETS_FRAME_PROPS)) {
const AVPacket *pkt = avctx->internal->last_pkt_props;
diff --git a/tests/ref/fate/hevc-dv-rpu b/tests/ref/fate/hevc-dv-rpu
index aaf0223eab..74dfc243f8 100644
--- a/tests/ref/fate/hevc-dv-rpu
+++ b/tests/ref/fate/hevc-dv-rpu
@@ -1,5 +1,14 @@
[FRAME]
[SIDE_DATA]
+side_data_type=3x3 displaymatrix
+displaymatrix=
+:0 655
[FFmpeg-devel] [PATCH 11/11] fftools/ffplay: stop injecting stream side data in packets
This is no longer needed as the side data is available for decoders in the
AVCodecContext.
Signed-off-by: James Almer
---
fftools/ffplay.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index f5354575c9..d8c69e10bc 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -2794,8 +2794,6 @@ static int read_thread(void *arg)
if (genpts)
ic->flags |= AVFMT_FLAG_GENPTS;
-av_format_inject_global_side_data(ic);
-
if (find_stream_info) {
AVDictionary **opts;
int orig_nb_streams = ic->nb_streams;
--
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 08/11] avcodec/hevcdec: check for DOVI configuration record in AVCodecContext side data
Signed-off-by: James Almer
---
libavcodec/avcodec.h | 2 +-
libavcodec/decode.c | 10 ++
libavcodec/decode.h | 6 ++
libavcodec/hevcdec.c | 15 ++-
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 09400b97b0..42b34ee89a 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1907,7 +1907,7 @@ typedef struct AVCodecContext {
/**
* Additional data associated with the entire coded stream.
*
- * - decoding: unused
+ * - decoding: may be set by user before calling avcodec_open2().
* - encoding: may be set by libavcodec after avcodec_open2().
*/
AVPacketSideData *coded_side_data;
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 8f94678e9b..d81c418e10 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1403,6 +1403,16 @@ int ff_get_format(AVCodecContext *avctx, const enum
AVPixelFormat *fmt)
return ret;
}
+const AVPacketSideData *ff_get_coded_side_data(const AVCodecContext *avctx,
+ enum AVPacketSideDataType type)
+{
+for (int i = 0; i < avctx->nb_coded_side_data; i++)
+if (avctx->coded_side_data[i].type == type)
+return &avctx->coded_side_data[i];
+
+return NULL;
+}
+
static int add_metadata_from_side_data(const AVPacket *avpkt, AVFrame *frame)
{
size_t size;
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index a52152e4a7..be03c136e7 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -153,4 +153,10 @@ int ff_side_data_update_matrix_encoding(AVFrame *frame,
int ff_hwaccel_frame_priv_alloc(AVCodecContext *avctx, void
**hwaccel_picture_private,
AVBufferRef **hwaccel_priv_buf);
+/**
+ * Get side data of the given type from a decoding context.
+ */
+const AVPacketSideData *ff_get_coded_side_data(const AVCodecContext *avctx,
+ enum AVPacketSideDataType type);
+
#endif /* AVCODEC_DECODE_H */
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 2be62ddfb2..5acaa407dd 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -3343,8 +3343,15 @@ static int hevc_decode_frame(AVCodecContext *avctx,
AVFrame *rframe,
}
sd = av_packet_get_side_data(avpkt, AV_PKT_DATA_DOVI_CONF, &sd_size);
-if (sd && sd_size > 0)
+if (sd && sd_size > 0) {
+int old = s->dovi_ctx.dv_profile;
+
ff_dovi_update_cfg(&s->dovi_ctx, (AVDOVIDecoderConfigurationRecord *)
sd);
+if (old)
+av_log(avctx, AV_LOG_DEBUG,
+ "New DOVI configuration record from input packet (profile
%d -> %u).\n",
+ old, s->dovi_ctx.dv_profile);
+}
s->ref = NULL;
ret= decode_nal_units(s, avpkt->data, avpkt->size);
@@ -3649,12 +3656,18 @@ static av_cold int hevc_decode_init(AVCodecContext
*avctx)
atomic_init(&s->wpp_err, 0);
if (!avctx->internal->is_copy) {
+const AVPacketSideData *sd;
+
if (avctx->extradata_size > 0 && avctx->extradata) {
ret = hevc_decode_extradata(s, avctx->extradata,
avctx->extradata_size, 1);
if (ret < 0) {
return ret;
}
}
+
+sd = ff_get_coded_side_data(avctx, AV_PKT_DATA_DOVI_CONF);
+if (sd && sd->size > 0)
+ff_dovi_update_cfg(&s->dovi_ctx, (AVDOVIDecoderConfigurationRecord
*) sd->data);
}
return 0;
--
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 18/42] avcodec/h264dec: Use RefStruct-pool API instead of AVBufferPool API
Quoting Andreas Rheinhardt (2023-09-19 21:57:10) > It involves less allocations and therefore has the nice property > that deriving a reference from a reference can't fail. > This allows for considerable simplifications in > ff_h264_(ref|replace)_picture(). > Switching to the RefStruct API also allows to make H264Picture > smaller, because some AVBufferRef* pointers could be removed > without replacement. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/h264_picture.c | 72 +++ > libavcodec/h264_slice.c | 44 > libavcodec/h264dec.c | 19 ++- > libavcodec/h264dec.h | 23 ++--- > 4 files changed, 62 insertions(+), 96 deletions(-) LGTM -- 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 19/42] avcodec/hevcdec: Use RefStruct-pool API instead of AVBufferPool API
Quoting Andreas Rheinhardt (2023-09-19 21:57:11) > It involves less allocations and therefore has the nice property > that deriving a reference from a reference can't fail, > simplifying hevc_ref_frame(). > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/hevc_refs.c | 16 ++-- > libavcodec/hevcdec.c | 25 ++--- > libavcodec/hevcdec.h | 10 -- > 3 files changed, 16 insertions(+), 35 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] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Hi Kieran i didnt really want to get drawn into this discussion but there is one point i have to make On Tue, Oct 03, 2023 at 08:29:23PM +0100, Kieran Kunhya via ffmpeg-devel wrote: > On Tue, Oct 3, 2023 at 7:50 PM Nicolas George wrote: > > More precisely, I now strongly believe that democracy is a terrible way > > to run a project like FFmpeg. > > Why are you part of a community project if you don't believe the > community is capable of running a project? Questioning why some developer is part of FFmpeg is IMHO a violation of the Code of Conduct. No matter how it is worded > Why not start your own project like TempleOS where you can do what you want? are you suggesting that we all move to a system where every developer has her/his own fork and they get merged ? Iam sure this was not meant to be directed at a single developer only Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data 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 20/42] avcodec/nvdec: Use RefStruct-pool API for decoder pool
Quoting Andreas Rheinhardt (2023-09-19 21:57:12) > It involves less allocations, in particular no allocations > after the entry has been created. Therefore creating a new > reference from an existing one can't fail and therefore > need not be checked. It also avoids indirections and casts. > > Also note that nvdec_decoder_frame_init() (the callback > to initialize new entries from the pool) does not use > atomics to read and replace the number of entries > currently used by the pool. This relies on nvdec (like > most other hwaccels) not being run in a truely frame-threaded > way. > > Signed-off-by: Andreas Rheinhardt > --- > Notice that the AVBufferPool API serializes creating new entries > as well as getting an already existing entry from the pool, > so not using atomics here would be fine for it even if nvdec > were run in a truely multithreaded way. AFAIK the API does not allow it, so there's nothing we can do about it. Patch LGTM -- 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 09/11] avcodec/decode: check for global side data in AVCodecContext side data
Quoting James Almer (2023-10-04 05:22:38) > > Actually, both tests use ffprobe, which never injected stream side data > into packets before this set, so the ffmpeg code removed in 10/11 makes > no difference. > > Adding DISPLAYMATRIX to the global map here will still mean ffmpeg.c > will pass stream side data to decoded frames, though, even if no test > covers it. So it would be nice to know why was it being skipped. Honestly I doubt there's a good reason, the handling of displaymatrix in ffmpeg CLI is a convoluted mess. -- 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 04/11] avcodec/packet: add some documentation for AVPacketSideData
Quoting James Almer (2023-10-04 14:28:42)
> Explaining what or who may use it, and in what scenarios.
>
> Signed-off-by: James Almer
> ---
> libavcodec/packet.h | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/libavcodec/packet.h b/libavcodec/packet.h
> index 96fc0084d6..85b3eeb728 100644
> --- a/libavcodec/packet.h
> +++ b/libavcodec/packet.h
> @@ -312,6 +312,25 @@ enum AVPacketSideDataType {
>
> #define AV_PKT_DATA_QUALITY_FACTOR AV_PKT_DATA_QUALITY_STATS //DEPRECATED
>
> +/**
> + * This structure stores information for decoding, presenting, or otherwise
^
I didn't mean for you to drop the 'auxiliary' that used to be here - it
(or some other equivalent wording) should be here to make it clear that
side data applies in additon/on top of the main coded bitstream.
> + * processing the coded stream. It is typically exported by demuxers and
> + * encoders and can be fed to decoders and muxers in a per packet basis, or
> as
^
/ \
either
> + * global side data (applying to the entire coded stream) as follows:
The following bullet points apply only to the global side data, so you
should start a new sentence that makes that explicit.
> + * - During demuxing, it will be exported through global side data in
> + * @ref AVStream.codecpar.side_data "AVStream's codec parameters", which
> can
> + * then be passed as input to decoders through the
> + * @ref AVCodecContext.coded_side_data "decoder context's side data", for
> + * initialization.
> + * - For muxing, it can be fed through global side data in
> + * @ref AVStream.codecpar.side_data "AVStream's codec parameters",
> typically
> + * the output of encoders through the @ref AVCodecContext.coded_side_data
> + * "encoder context's side data", for initialization.
> + *
> + * Different modules may accept or export different types of side data
> + * depending on media type and codec. Refer to @ref AVPacketSideDataType for
> a
> + * list of defined types and where they may be found or used.
> + */
--
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 00/11 v6] AVCodecContext and AVCodecParameters side data
Quoting James Almer (2023-10-04 14:28:38)
> Changes since the previous version:
> - Zeroed padding to side data allocated by av_packet_side_data_new() (Patch
> 1).
> - Renamed AVCodecParameters.{nb,}side_data to {nb,}coded_side_data, to both
> match the name in AVCodecContext and keep the side_data name free for future
> use (Patch 2).
> - Rewritten documentation to AVPacketSideData (Patch 4)
> - Display Matrix global side data is now propagated to output frames (Patch
> 9).
>
> Will add version bumps and APIChanges entries and push the set later this week
> unless there are objections.
\o/
Very nice
--
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] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Quoting Michael Niedermayer (2023-09-27 20:03:12) > > again IMO any change to what SW we use needs more discussion than a > > "who likes gitlab, who likes gitwhatever" vote > > I think its very important that we do not loose independance and run > our own infrastructure. > > That said. > > I think we should make a detailed list of what people actually want > closing bugs with git commits ? > creating new tickets with mails ? > controlling the whole infrastructure from the command line ? > ... > > then with sw/implementation options then > (maybe some of the wanted things can be easily added even to some > infrastructure options > that otherwise lack them) > > expected costs (admin time) of each and > expected benefits (developer time saved) One highly important potential benefit you're not considering is how many people fail to become developers because the barrier to entry is too high or because the project gives off the air of obsolescence. I do share many of your concerns though, and this should definitely be considered in detail. -- 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] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Quoting Michael Niedermayer (2023-10-04 16:23:12) > Hi Kieran > > i didnt really want to get drawn into this discussion but there is one > point i have to make > > On Tue, Oct 03, 2023 at 08:29:23PM +0100, Kieran Kunhya via ffmpeg-devel > wrote: > > On Tue, Oct 3, 2023 at 7:50 PM Nicolas George wrote: > > > More precisely, I now strongly believe that democracy is a terrible way > > > to run a project like FFmpeg. > > > > Why are you part of a community project if you don't believe the > > community is capable of running a project? > > Questioning why some developer is part of FFmpeg is IMHO a violation of > the Code of Conduct. No matter how it is worded The development community has agreed on the following fundamental rules some years ago: > The FFmpeg project is organized through a community working on global > consensus. > [...] > The General Assembly is sovereign and legitimate for all its decisions > regarding the FFmpeg project. It is IMO perfectly reasonable to wonder why does someone who does not agree with the basic rules participate in the project. -- 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] VDD 2023, FFmpeg meeting notes, (23-11-2023, 4pm, Dublin)
Le keskiviikkona 4. lokakuuta 2023, 17.23.12 EEST Michael Niedermayer a écrit : > > Why are you part of a community project if you don't believe the > > community is capable of running a project? > > Questioning why some developer is part of FFmpeg is IMHO a violation of > the Code of Conduct. No matter how it is worded Kieran was asking a very valid *question*. NG has been vocally adamant (to put it mildly) about turning FFmpeg into (or back into) a place for fun experimentation and innovation, without the burden of reverse dependencies, down-stream packagers, users, and contributors with business interests. In the past year, I have not noticed anybody else support those directions. Your own (in)actions have been in direct contradiction with his stated views, for instance: - You keep making tons of "boring" fixes from OSS fuzz findings and other sources (I am thankful for your continued efforts on the first point, by the way; this is not meant as negative criticism). - You are listed as a prominent member of FFlabs (and you have not denounced that in any way). Admittedly, Kieran's question could be taken as loaded, but TBH the question seems valid, and calling it a violation of the CoC is too much of a stretch for me. > > Why not start your own project like TempleOS where you can do what you > > want? > are you suggesting that we all move to a system where every developer has > her/his own fork and they get merged ? He is suggesting that if one person *appears* to be alone in wanting to take (or take back) FFmpeg in the given directions that they advocate, they should consider starting their own project or fork. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Quoting Michael Niedermayer (2023-10-03 21:22:58) > On Tue, Sep 26, 2023 at 08:14:37PM +0200, Anton Khirnov wrote: > > You keep framing this as some kind of a personal campaign against you. > > It is not. From my perspective, the objections to SDR have been largely > > technical, and most of the "heat" comes from your refusal to accept that > > many active developers are against it. > > Technical arguments ? > Yes, several people had technical arguments, I remember Tomas and Remi and > some > others. But at least subjectively i felt that the bulk of people where alot > more > emotional than technical > > But let me list a few observations, from memory > First objection was because processing is done in an external library. > Then it was found out that was wrong and actually processing is done in the > new code > so the objection flipped and people demanded it to be moved into an external > library. > > If you object to pink and want blue and when you find out its actually blue > you have > to be happy and become a supporter but what happened was the opposit, the > objection > was simply adjusted to object to whatever was the case and demand whatever > was not. > > Ok so thats at least one developers "Technical objection" down here, maybe > more > i dont know if anyone else expressed that same initial objection. but lets > move on > > In all cases we prefer not to have external dependancies, this is the > Technical position of FFmpeg > no, there is no technical argument in this. > Also personal preferrances of people is not a technical argument. Noone > explained why a > avdevice module with more external depandancies would be ok but a avdevice > module with > fewer external depandancies was not. <-- This last sentance is a technical > argument > I could go as far as call this a proof by contradiction. > > If people are happy with a avdevice module and FFmpeg prefers fewer external > dependancies > then my suggestion of first starting with a plain simple self contained > avdevice/avformat > module, would have to be fine too. > We can always move this to an external library once there is a technical > reason for that > like for example some other software wants to use it > > About the attack/rallying/compaign stuff. Ill keep it very brief as its not > useful i think. > Also this is my own personal and subjective view. In fact the whole mail is > There was alot of (negative) emotion from 1-2 people about SDR. This emotion > was what spread > slash rallied other developers. That came before any technical arguments. > Now people have picked their flag and march to war. > > Everyone will deny it, same as every patriot will fight to the death for the > colors of > the flag of the country and religion they where born into. > > My claim, sorry to be stubborn, is that had this started a slight bit > different there > would be little opposition to SDR. Iam not denying that now there are several > people > against it. These are largely unfalsifiable claims, so I don't see how they can productively contribute to this discussion. But dismissing people's concerns as "patriotic" or "religious" isn't helping your case IMO. -- 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 v3] avformat/mov: Add support for demuxing still HEIC images
They are similar to AVIF images (both use the HEIF container).
The only additional work needed is to parse the hvcC box and put
it in the extradata.
With this patch applied, ffmpeg (when built with an HEVC decoder)
is able to decode the files in
https://github.com/nokiatech/heif/tree/gh-pages/content/images
Also add a couple of fate tests with samples from
https://github.com/nokiatech/heif_conformance/tree/master/conformance_files
Partially fixes trac ticket #6521.
Signed-off-by: Vignesh Venkatasubramanian
---
libavformat/isom.h| 2 +
libavformat/mov.c | 41 ++-
tests/fate/mov.mak| 6 +++
.../fate/mov-heic-demux-still-image-1-item| 11 +
.../mov-heic-demux-still-image-multiple-items | 11 +
5 files changed, 70 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/mov-heic-demux-still-image-1-item
create mode 100644 tests/ref/fate/mov-heic-demux-still-image-multiple-items
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 3d375d7a46..b30b9da65e 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -327,6 +327,8 @@ typedef struct MOVContext {
int64_t extent_offset;
} *avif_info;
int avif_info_size;
+int64_t hvcC_offset;
+int hvcC_size;
int interleaved_read;
} MOVContext;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 294c864fbd..d3747022bd 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1218,7 +1218,8 @@ static int mov_read_ftyp(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
c->isom = 1;
av_log(c->fc, AV_LOG_DEBUG, "ISO: File Type Major Brand: %.4s\n",(char
*)&type);
av_dict_set(&c->fc->metadata, "major_brand", type, 0);
-c->is_still_picture_avif = !strncmp(type, "avif", 4);
+c->is_still_picture_avif = !strncmp(type, "avif", 4) ||
+ !strncmp(type, "mif1", 4);
minor_ver = avio_rb32(pb); /* minor version */
av_dict_set_int(&c->fc->metadata, "minor_version", minor_ver, 0);
@@ -4911,6 +4912,19 @@ static int avif_add_stream(MOVContext *c, int item_id)
st->priv_data = sc;
st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
st->codecpar->codec_id = AV_CODEC_ID_AV1;
+if (c->hvcC_offset >= 0) {
+int ret;
+int64_t pos = avio_tell(c->fc->pb);
+st->codecpar->codec_id = AV_CODEC_ID_HEVC;
+if (avio_seek(c->fc->pb, c->hvcC_offset, SEEK_SET) != c->hvcC_offset) {
+av_log(c->fc, AV_LOG_ERROR, "Failed to seek to hvcC data.\n");
+return AVERROR_UNKNOWN;
+}
+ret = ff_get_extradata(c->fc, st->codecpar, c->fc->pb, c->hvcC_size);
+if (ret < 0)
+return ret;
+avio_seek(c->fc->pb, pos, SEEK_SET);
+}
sc->ffindex = st->index;
c->trak_index = st->index;
st->avg_frame_rate.num = st->avg_frame_rate.den = 1;
@@ -4953,6 +4967,8 @@ static int avif_add_stream(MOVContext *c, int item_id)
static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom)
{
+c->hvcC_offset = -1;
+c->hvcC_size = 0;
while (atom.size > 8) {
uint32_t tag;
if (avio_feof(pb))
@@ -7827,6 +7843,28 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return atom.size;
}
+static int mov_read_iprp(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+int size = avio_rb32(pb);
+if (avio_rl32(pb) != MKTAG('i','p','c','o'))
+return AVERROR_INVALIDDATA;
+size -= 8;
+while (size > 0) {
+int sub_size, sub_type;
+sub_size = avio_rb32(pb);
+sub_type = avio_rl32(pb);
+sub_size -= 8;
+size -= sub_size + 8;
+if (sub_type == MKTAG('h','v','c','C')) {
+c->hvcC_offset = avio_tell(pb);
+c->hvcC_size = sub_size;
+break;
+}
+avio_skip(pb, sub_size);
+}
+return atom.size;
+}
+
static const MOVParseTableEntry mov_default_parse_table[] = {
{ MKTAG('A','C','L','R'), mov_read_aclr },
{ MKTAG('A','P','R','G'), mov_read_avid },
@@ -7934,6 +7972,7 @@ static const MOVParseTableEntry mov_default_parse_table[]
= {
{ MKTAG('p','c','m','C'), mov_read_pcmc }, /* PCM configuration box */
{ MKTAG('p','i','t','m'), mov_read_pitm },
{ MKTAG('e','v','c','C'), mov_read_glbl },
+{ MKTAG('i','p','r','p'), mov_read_iprp },
{ 0, NULL }
};
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 6cb493ceab..a2d3cc8013 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -18,6 +18,8 @@ FATE_MOV = fate-mov-3elist \
fate-mov-neg-firstpts-discard-frames \
fate-mov-stream-shorter-than-movie \
fate-mov-pcm-remux \
+ fate-mov-heic-demux-still-image-1-item \
+ fate-mov-heic-demux-still-image-multiple-items \
# FIXME: Uncomment these two lines once the test files are uploaded to the fate
# server.
# fate-mov-avif-demux-still-image-1-item \
@@ -15
Re: [FFmpeg-devel] [RFC] Release 6.1
This discussion has drifted far away from any topic set upfront. It's gotten to the point where there's no way for anyone outside to join and give their own opinion, as it's not possible to know the entire discussion that's happened up to this point. Hence, spin this off in multiple threads. Maybe the one summarizing a discussion will find it's pointless and we could focus on a smaller set of things to worry about for 6.1's release. ___ 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] [FFmpeg-cvslog] avcodec/hcadec: support decoding with extradata provided in first packet
On Mon, Oct 02, 2023 at 10:56:20PM -0300, James Almer wrote: > On 10/2/2023 7:23 PM, Michael Niedermayer wrote: > > Hi > > > > On Tue, Sep 05, 2023 at 09:25:45PM +, Paul B Mahol wrote: > > > ffmpeg | branch: master | Paul B Mahol | Tue Sep 5 > > > 23:14:58 2023 +0200| [d464a687c9dd03246795d62151809167e8381932] | > > > committer: Paul B Mahol > > > > > > avcodec/hcadec: support decoding with extradata provided in first packet > > > > I cannot find this patch on the mailing list > > > > Also this adds null pointer writes > > The init_hca() function which previously was only called once and failure > > ended all further processing now is called optionally per frame and its > > failure does not stop further processing so half initialized contexts > > can be created by an attacker > > > > Note, this sort of stuff delays the release > > > > thx > > Does the following fix it? the testcase no longer crashes with this thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- 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] avcodec/svt-av1: Set force_key_frames only when gop_size == 1
Hi,
On Tue, Oct 3, 2023 at 6:53 PM Vignesh Venkatasubramanian via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> SVT-AV1 does not support requesting keyframes at arbitrary points
> by setting pic_type to EB_AV1_KEY_PICTURE. So set force_key_frames
> to 1 only when gop_size == 1.
>
> Please see the comments in
> https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 for a bit more
> details.
>
> Signed-off-by: Vignesh Venkatasubramanian
> ---
> libavcodec/libsvtav1.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> index 5015169244..8d2c7f3be4 100644
> --- a/libavcodec/libsvtav1.c
> +++ b/libavcodec/libsvtav1.c
> @@ -253,8 +253,13 @@ static int config_enc_params(EbSvtAv1EncConfiguration
> *param,
> // In order for SVT-AV1 to force keyframes by setting pic_type to
> // EB_AV1_KEY_PICTURE on any frame, force_key_frames has to be set.
> Note
> // that this does not force all frames to be keyframes (it only
> forces a
> -// keyframe with pic_type is set to EB_AV1_KEY_PICTURE).
> -param->force_key_frames = 1;
> +// keyframe with pic_type is set to EB_AV1_KEY_PICTURE). As of now,
> SVT-AV1
> +// does not support arbitrary keyframe requests by setting pic_type to
> +// EB_AV1_KEY_PICTURE, so it is done only when gop_size == 1.
> +// FIXME: When SVT-AV1 supports arbitrary keyframe requests, this
> code needs
> +// to be updated to set force_key_frames accordingly.
> +if (avctx->gop_size == 1)
> +param->force_key_frames = 1;
>
> if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
> param->frame_rate_numerator = avctx->framerate.num;
> --
> 2.42.0.582.g8ccd20d70d-goog
>
Seems reasonable to me.
Can you merge, or should I merge for you?
Ronald
___
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 11/12] avcodec/h261dec, mpeg12dec, vc1dec: Remove setting write-only flags
On Tue, Oct 03, 2023 at 06:04:03PM +0200, Andreas Rheinhardt wrote: > These flags will be overwritten later in ff_mpv_frame_start(). > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/h261dec.c | 7 --- > libavcodec/mpeg12dec.c | 10 -- > libavcodec/vc1dec.c| 7 --- > 3 files changed, 24 deletions(-) probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn 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 10/12] avcodec/rv10: Replace switch by LUT
On Tue, Oct 03, 2023 at 06:04:02PM +0200, Andreas Rheinhardt wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/rv10.c | 21 + > 1 file changed, 5 insertions(+), 16 deletions(-) ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 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 09/12] avcodec/rv10: Remove dead code
On Tue, Oct 03, 2023 at 06:04:01PM +0200, Andreas Rheinhardt wrote: > Dead since 248a1aa54c08b14e8bd49147f59d954c41b5b3a3. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/rv10.c | 3 --- > 1 file changed, 3 deletions(-) ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- 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] [RFC] Release 6.1
On Wed, Oct 04, 2023 at 05:19:17PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-10-03 21:22:58) > > On Tue, Sep 26, 2023 at 08:14:37PM +0200, Anton Khirnov wrote: > > > You keep framing this as some kind of a personal campaign against you. > > > It is not. From my perspective, the objections to SDR have been largely > > > technical, and most of the "heat" comes from your refusal to accept that > > > many active developers are against it. > > > > Technical arguments ? > > Yes, several people had technical arguments, I remember Tomas and Remi and > > some > > others. But at least subjectively i felt that the bulk of people where alot > > more > > emotional than technical > > > > But let me list a few observations, from memory > > First objection was because processing is done in an external library. > > Then it was found out that was wrong and actually processing is done in the > > new code > > so the objection flipped and people demanded it to be moved into an > > external library. > > > > If you object to pink and want blue and when you find out its actually blue > > you have > > to be happy and become a supporter but what happened was the opposit, the > > objection > > was simply adjusted to object to whatever was the case and demand whatever > > was not. > > > > Ok so thats at least one developers "Technical objection" down here, maybe > > more > > i dont know if anyone else expressed that same initial objection. but lets > > move on > > > > In all cases we prefer not to have external dependancies, this is the > > Technical position of FFmpeg > > no, there is no technical argument in this. > > Also personal preferrances of people is not a technical argument. Noone > > explained why a > > avdevice module with more external depandancies would be ok but a avdevice > > module with > > fewer external depandancies was not. <-- This last sentance is a technical > > argument > > I could go as far as call this a proof by contradiction. > > > > If people are happy with a avdevice module and FFmpeg prefers fewer > > external dependancies > > then my suggestion of first starting with a plain simple self contained > > avdevice/avformat > > module, would have to be fine too. > > We can always move this to an external library once there is a technical > > reason for that > > like for example some other software wants to use it > > > > About the attack/rallying/compaign stuff. Ill keep it very brief as its not > > useful i think. > > Also this is my own personal and subjective view. In fact the whole mail is > > There was alot of (negative) emotion from 1-2 people about SDR. This > > emotion was what spread > > slash rallied other developers. That came before any technical arguments. > > Now people have picked their flag and march to war. > > > > Everyone will deny it, same as every patriot will fight to the death for > > the colors of > > the flag of the country and religion they where born into. > > > > My claim, sorry to be stubborn, is that had this started a slight bit > > different there > > would be little opposition to SDR. Iam not denying that now there are > > several people > > against it. > > These are largely unfalsifiable claims, so I don't see how they can > productively contribute to this discussion. > > But dismissing people's concerns as "patriotic" or "religious" isn't > helping your case IMO. That was not my intend i had not intended to dismiss anyones concern What i was trying to do with this 2nd part of the mail was to document a subjective observation. The reason was simply _IF_ this observation is somewhat correct, then awareness of this could help people next time. As i stated i expect noone to change their position here. But maybe next time we have a similar growing disagreement being aware of the possible effects of emotional statements from fellow developers could be helpfull. thx, and ill try to end this debate in this thread, this minor comment just felt it fits better here [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway 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] lavu/float_dsp: adjust multipler in R-V V fmul_window
The gather index vector is only used as double-length (due to register pressure), so no need to initialise it for quad-length. Basically this matches the multiplier in the prologue to the the multipler in the loop. --- libavutil/riscv/float_dsp_rvv.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/riscv/float_dsp_rvv.S b/libavutil/riscv/float_dsp_rvv.S index 91b70bf148..a2f9488249 100644 --- a/libavutil/riscv/float_dsp_rvv.S +++ b/libavutil/riscv/float_dsp_rvv.S @@ -75,7 +75,7 @@ endfunc func ff_vector_fmul_window_rvv, zve32f // a0: dst, a1: src0, a2: src1, a3: window, a4: length -vsetvlit0, zero, e16, m4, ta, ma +vsetvlit0, zero, e16, m2, ta, ma sh2add a2, a4, a2 vid.v v0 sh3add t3, a4, a3 -- 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] [FFmpeg-cvslog] avcodec/hcadec: support decoding with extradata provided in first packet
On 10/4/2023 2:22 PM, Michael Niedermayer wrote: On Mon, Oct 02, 2023 at 10:56:20PM -0300, James Almer wrote: On 10/2/2023 7:23 PM, Michael Niedermayer wrote: Hi On Tue, Sep 05, 2023 at 09:25:45PM +, Paul B Mahol wrote: ffmpeg | branch: master | Paul B Mahol | Tue Sep 5 23:14:58 2023 +0200| [d464a687c9dd03246795d62151809167e8381932] | committer: Paul B Mahol avcodec/hcadec: support decoding with extradata provided in first packet I cannot find this patch on the mailing list Also this adds null pointer writes The init_hca() function which previously was only called once and failure ended all further processing now is called optionally per frame and its failure does not stop further processing so half initialized contexts can be created by an attacker Note, this sort of stuff delays the release thx Does the following fix it? the testcase no longer crashes with this thx Will apply 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 1/4] lavu/fixed_dsp: R-V V vector_fmul_add
vector_fmul_add_fixed_c: 2.2
vector_fmul_add_fixed_rvv_i64: 0.5
---
libavutil/riscv/fixed_dsp_init.c | 5 +
libavutil/riscv/fixed_dsp_rvv.S | 21 +
2 files changed, 26 insertions(+)
diff --git a/libavutil/riscv/fixed_dsp_init.c b/libavutil/riscv/fixed_dsp_init.c
index 409b6d7b55..4b239829f5 100644
--- a/libavutil/riscv/fixed_dsp_init.c
+++ b/libavutil/riscv/fixed_dsp_init.c
@@ -25,6 +25,8 @@
#include "libavutil/cpu.h"
#include "libavutil/fixed_dsp.h"
+void ff_vector_fmul_add_fixed_rvv(int *dst, const int *src0, const int *src1,
+ const int *src2, int len);
int ff_scalarproduct_fixed_rvv(const int *v1, const int *v2, int len);
void ff_butterflies_fixed_rvv(int *v1, int *v2, int len);
@@ -34,8 +36,11 @@ av_cold void ff_fixed_dsp_init_riscv(AVFixedDSPContext *fdsp)
int flags = av_get_cpu_flags();
if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+fdsp->vector_fmul_add = ff_vector_fmul_add_fixed_rvv;
+
if (flags & AV_CPU_FLAG_RVV_I64)
fdsp->scalarproduct_fixed = ff_scalarproduct_fixed_rvv;
+
fdsp->butterflies_fixed = ff_butterflies_fixed_rvv;
}
#endif
diff --git a/libavutil/riscv/fixed_dsp_rvv.S b/libavutil/riscv/fixed_dsp_rvv.S
index 83cad4bde3..1022a401d3 100644
--- a/libavutil/riscv/fixed_dsp_rvv.S
+++ b/libavutil/riscv/fixed_dsp_rvv.S
@@ -20,6 +20,27 @@
#include "asm.S"
+
+func ff_vector_fmul_add_fixed_rvv, zve32x
+csrwi vxrm, 0
+1:
+vsetvli t0, a4, e32, m8, ta, ma
+vle32.v v16, (a1)
+sub a4, a4, t0
+vle32.v v24, (a2)
+sh2add a1, t0, a1
+vsmul.vv v8, v16, v24
+sh2add a2, t0, a2
+vle32.v v0,(a3)
+sh2add a3, t0, a3
+vadd.vv v8, v8, v0
+vse32.v v8, (a0)
+sh2add a0, t0, a0
+bneza4, 1b
+
+ret
+endfunc
+
func ff_scalarproduct_fixed_rvv, zve64x
li t1, 1 << 30
vsetvli t0, zero, e64, m8, ta, ma
--
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 2/4] lavu/fixed_dsp: R-V V vector_fmul_reverse
---
libavutil/riscv/fixed_dsp_init.c | 3 +++
libavutil/riscv/fixed_dsp_rvv.S | 24
2 files changed, 27 insertions(+)
diff --git a/libavutil/riscv/fixed_dsp_init.c b/libavutil/riscv/fixed_dsp_init.c
index 4b239829f5..470b35fb63 100644
--- a/libavutil/riscv/fixed_dsp_init.c
+++ b/libavutil/riscv/fixed_dsp_init.c
@@ -25,6 +25,8 @@
#include "libavutil/cpu.h"
#include "libavutil/fixed_dsp.h"
+void ff_vector_fmul_reverse_fixed_rvv(int *dst, const int *src0,
+ const int *src1, int len);
void ff_vector_fmul_add_fixed_rvv(int *dst, const int *src0, const int *src1,
const int *src2, int len);
int ff_scalarproduct_fixed_rvv(const int *v1, const int *v2, int len);
@@ -36,6 +38,7 @@ av_cold void ff_fixed_dsp_init_riscv(AVFixedDSPContext *fdsp)
int flags = av_get_cpu_flags();
if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+fdsp->vector_fmul_reverse = ff_vector_fmul_reverse_fixed_rvv;
fdsp->vector_fmul_add = ff_vector_fmul_add_fixed_rvv;
if (flags & AV_CPU_FLAG_RVV_I64)
diff --git a/libavutil/riscv/fixed_dsp_rvv.S b/libavutil/riscv/fixed_dsp_rvv.S
index 1022a401d3..8a5d1853c5 100644
--- a/libavutil/riscv/fixed_dsp_rvv.S
+++ b/libavutil/riscv/fixed_dsp_rvv.S
@@ -20,6 +20,30 @@
#include "asm.S"
+func ff_vector_fmul_reverse_fixed_rvv, zve32x
+csrwi vxrm, 0
+vsetvli t0, zero, e16, m4, ta, ma
+sh2add a2, a3, a2
+vid.v v0
+vadd.vi v0, v0, 1
+1:
+vsetvli t0, a3, e16, m4, ta, ma
+sllit1, t0, 2
+vrsub.vx v4, v0, t0 // v4[i] = [VL-1, VL-2... 1, 0]
+sub a2, a2, t1
+vsetvli zero, zero, e32, m8, ta, ma
+vle32.v v8, (a2)
+sub a3, a3, t0
+vle32.v v16, (a1)
+add a1, a1, t1
+vrgatherei16.vv v24, v8, v4 // v24 = reverse(v8)
+vsmul.vv v16, v16, v24
+vse32.v v16, (a0)
+add a0, a0, t1
+bneza3, 1b
+
+ret
+endfunc
func ff_vector_fmul_add_fixed_rvv, zve32x
csrwi vxrm, 0
--
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 3/4] lavu/fixed_dsp: R-V V vector_fmul
vector_fmul_fixed_c: 4.0
vector_fmul_fixed_rvv_i64: 0.5
---
libavutil/riscv/fixed_dsp_init.c | 3 +++
libavutil/riscv/fixed_dsp_rvv.S | 17 +
2 files changed, 20 insertions(+)
diff --git a/libavutil/riscv/fixed_dsp_init.c b/libavutil/riscv/fixed_dsp_init.c
index 470b35fb63..02883b31d4 100644
--- a/libavutil/riscv/fixed_dsp_init.c
+++ b/libavutil/riscv/fixed_dsp_init.c
@@ -25,6 +25,8 @@
#include "libavutil/cpu.h"
#include "libavutil/fixed_dsp.h"
+void ff_vector_fmul_fixed_rvv(int *dst, const int *src0, const int *src1,
+ int len);
void ff_vector_fmul_reverse_fixed_rvv(int *dst, const int *src0,
const int *src1, int len);
void ff_vector_fmul_add_fixed_rvv(int *dst, const int *src0, const int *src1,
@@ -38,6 +40,7 @@ av_cold void ff_fixed_dsp_init_riscv(AVFixedDSPContext *fdsp)
int flags = av_get_cpu_flags();
if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+fdsp->vector_fmul = ff_vector_fmul_fixed_rvv;
fdsp->vector_fmul_reverse = ff_vector_fmul_reverse_fixed_rvv;
fdsp->vector_fmul_add = ff_vector_fmul_add_fixed_rvv;
diff --git a/libavutil/riscv/fixed_dsp_rvv.S b/libavutil/riscv/fixed_dsp_rvv.S
index 8a5d1853c5..d5d538239f 100644
--- a/libavutil/riscv/fixed_dsp_rvv.S
+++ b/libavutil/riscv/fixed_dsp_rvv.S
@@ -20,6 +20,23 @@
#include "asm.S"
+func ff_vector_fmul_fixed_rvv, zve32x
+csrwi vxrm, 0
+1:
+vsetvli t0, a3, e32, m4, ta, ma
+vle32.v v16, (a1)
+sub a3, a3, t0
+vle32.v v24, (a2)
+sh2add a1, t0, a1
+vsmul.vv v8, v16, v24
+sh2add a2, t0, a2
+vse32.v v8, (a0)
+sh2add a0, t0, a0
+bneza3, 1b
+
+ret
+endfunc
+
func ff_vector_fmul_reverse_fixed_rvv, zve32x
csrwi vxrm, 0
vsetvli t0, zero, e16, m4, ta, ma
--
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 4/4] lavu/fixed_dsp: R-V V vector_fmul_window
---
libavutil/riscv/fixed_dsp_init.c | 6 +
libavutil/riscv/fixed_dsp_rvv.S | 44
2 files changed, 50 insertions(+)
diff --git a/libavutil/riscv/fixed_dsp_init.c b/libavutil/riscv/fixed_dsp_init.c
index 02883b31d4..6469b45374 100644
--- a/libavutil/riscv/fixed_dsp_init.c
+++ b/libavutil/riscv/fixed_dsp_init.c
@@ -25,6 +25,9 @@
#include "libavutil/cpu.h"
#include "libavutil/fixed_dsp.h"
+void ff_vector_fmul_window_fixed_rvv(int32_t *dst, const int32_t *src0,
+ const int32_t *src1, const int32_t *win,
+ int len);
void ff_vector_fmul_fixed_rvv(int *dst, const int *src0, const int *src1,
int len);
void ff_vector_fmul_reverse_fixed_rvv(int *dst, const int *src0,
@@ -40,6 +43,9 @@ av_cold void ff_fixed_dsp_init_riscv(AVFixedDSPContext *fdsp)
int flags = av_get_cpu_flags();
if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+if (flags & AV_CPU_FLAG_RVV_I64)
+fdsp->vector_fmul_window = ff_vector_fmul_window_fixed_rvv;
+
fdsp->vector_fmul = ff_vector_fmul_fixed_rvv;
fdsp->vector_fmul_reverse = ff_vector_fmul_reverse_fixed_rvv;
fdsp->vector_fmul_add = ff_vector_fmul_add_fixed_rvv;
diff --git a/libavutil/riscv/fixed_dsp_rvv.S b/libavutil/riscv/fixed_dsp_rvv.S
index d5d538239f..5b666016a0 100644
--- a/libavutil/riscv/fixed_dsp_rvv.S
+++ b/libavutil/riscv/fixed_dsp_rvv.S
@@ -20,6 +20,50 @@
#include "asm.S"
+func ff_vector_fmul_window_fixed_rvv, zve64x
+csrwi vxrm, 0
+vsetvli t0, zero, e16, m1, ta, ma
+sh2add a2, a4, a2
+vid.v v0
+sh3add t3, a4, a3
+vadd.vi v0, v0, 1
+sh3add t0, a4, a0
+1:
+vsetvli t2, a4, e16, m1, ta, ma
+sllit4, t2, 2
+vrsub.vx v2, v0, t2
+sub t3, t3, t4
+vsetvli zero, zero, e32, m2, ta, ma
+sub a2, a2, t4
+vle32.v v8, (t3)
+sub t0, t0, t4
+vle32.v v4, (a2)
+sub a4, a4, t2
+vrgatherei16.vv v28, v8, v2
+vle32.v v16, (a1)
+add a1, a1, t4
+vrgatherei16.vv v20, v4, v2
+vle32.v v24, (a3)
+add a3, a3, t4
+vwmul.vv v12, v16, v28
+vwmul.vv v8, v16, v24
+// vwnmsac.vv does _not_ exist so multiply & subtract separately
+vwmul.vv v4, v20, v24
+vwmacc.vv v8, v20, v28
+vsetvli zero, zero, e64, m4, ta, ma
+vsub.vv v12, v12, v4
+vsetvli zero, zero, e32, m2, ta, ma
+vnclip.wi v16, v8, 31
+vnclip.wi v20, v12, 31
+vrgatherei16.vv v8, v16, v2
+vse32.v v20, (a0)
+add a0, a0, t4
+vse32.v v8, (t0)
+bneza4, 1b
+
+ret
+endfunc
+
func ff_vector_fmul_fixed_rvv, zve32x
csrwi vxrm, 0
1:
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/svt-av1: Set force_key_frames only when gop_size == 1
On Wed, Oct 4, 2023 at 10:23 AM Ronald S. Bultje wrote:
>
> Hi,
>
> On Tue, Oct 3, 2023 at 6:53 PM Vignesh Venkatasubramanian via ffmpeg-devel
> wrote:
>>
>> SVT-AV1 does not support requesting keyframes at arbitrary points
>> by setting pic_type to EB_AV1_KEY_PICTURE. So set force_key_frames
>> to 1 only when gop_size == 1.
>>
>> Please see the comments in
>> https://gitlab.com/AOMediaCodec/SVT-AV1/-/issues/2076 for a bit more
>> details.
>>
>> Signed-off-by: Vignesh Venkatasubramanian
>> ---
>> libavcodec/libsvtav1.c | 9 +++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
>> index 5015169244..8d2c7f3be4 100644
>> --- a/libavcodec/libsvtav1.c
>> +++ b/libavcodec/libsvtav1.c
>> @@ -253,8 +253,13 @@ static int config_enc_params(EbSvtAv1EncConfiguration
>> *param,
>> // In order for SVT-AV1 to force keyframes by setting pic_type to
>> // EB_AV1_KEY_PICTURE on any frame, force_key_frames has to be set. Note
>> // that this does not force all frames to be keyframes (it only forces a
>> -// keyframe with pic_type is set to EB_AV1_KEY_PICTURE).
>> -param->force_key_frames = 1;
>> +// keyframe with pic_type is set to EB_AV1_KEY_PICTURE). As of now,
>> SVT-AV1
>> +// does not support arbitrary keyframe requests by setting pic_type to
>> +// EB_AV1_KEY_PICTURE, so it is done only when gop_size == 1.
>> +// FIXME: When SVT-AV1 supports arbitrary keyframe requests, this code
>> needs
>> +// to be updated to set force_key_frames accordingly.
>> +if (avctx->gop_size == 1)
>> +param->force_key_frames = 1;
>>
>> if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
>> param->frame_rate_numerator = avctx->framerate.num;
>> --
>> 2.42.0.582.g8ccd20d70d-goog
>
>
> Seems reasonable to me.
>
> Can you merge, or should I merge for you?
>
Thanks Ronald. I don't have commit access. Can you please merge it?
> Ronald
--
Vignesh
___
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/jpegxl_parser: fix various memory issues
On 10/3/23 11:00, Leo Izen wrote: The spec caps the prefix alphabet size to 32768 (i.e. 1 << 15) so we should check for that and reject alphabets that are too large, in order to prevent over-allocating. Additionally, there's no need to allocate buffers that are as large as the maximum alphabet size as these aren't stack-allocated, they're heap allocated and thus can be variable size. Added an overflow check as well, which fixes leaking the buffer, and capping the alphabet size fixes two potential overruns as well. Fixes: out of array access Fixes: 62089/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer- 5437089094959104.fuzz Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Found-by: Hardik Shah of Vehere (Dawn Treaders team) Co-authored-by: Michael Niedermayer Signed-off-by: Leo Izen --- libavcodec/jpegxl_parser.c | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-) Will merge soon as it fixes a clusterfuzz case. - Leo Izen ___ 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/jpegxl_parser: add some icc profile checks
On 10/3/23 13:38, Leo Izen wrote: This patch will cause the parser to abort if it detects an icc profile with an invalid size. This is particularly important if the icc profile is entropy-encoded with zero bits per symbol, as it can prevent a seemingly infinite loop during parsing. Fixes: infinite loop Fixes: 62374/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer -5551878085410816 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Reported-by: Michael Niedermayer Signed-off-by: Leo Izen --- libavcodec/jpegxl_parser.c | 44 ++ 1 file changed, 35 insertions(+), 9 deletions(-) Will merge soon as it fixes a clusterfuzz case. - Leo Izen ___ 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/4] avcodec/jpeg2000dec: Check image offset
Fixes: left shift of negative value -538967841
Fixes:
62447/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6427134337613824
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/jpeg2000dec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index eda959e558d..691cfbd8915 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -238,6 +238,11 @@ static int get_siz(Jpeg2000DecoderContext *s)
return AVERROR_INVALIDDATA;
}
+if (s->image_offset_x >= s->width || s->image_offset_y >= s->height) {
+av_log(s->avctx, AV_LOG_ERROR, "image offsets outside image");
+return AVERROR_INVALIDDATA;
+}
+
if (s->reduction_factor && (s->image_offset_x || s->image_offset_y) ){
av_log(s->avctx, AV_LOG_ERROR, "reduction factor with image offsets is
not fully implemented");
return AVERROR_PATCHWELCOME;
--
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/4] avcodec/evc_parse: Check num_remaining_tiles_in_slice_minus1
Fixes: out of array access
Fixes:
62467/clusterfuzz-testcase-minimized-ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-6092990982258688
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/evc_parse.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c
index bd3a4416f2d..5ab33166cf3 100644
--- a/libavcodec/evc_parse.c
+++ b/libavcodec/evc_parse.c
@@ -58,8 +58,12 @@ int ff_evc_parse_slice_header(GetBitContext *gb,
EVCParserSliceHeader *sh,
if (!sh->arbitrary_slice_flag)
sh->last_tile_id = get_bits(gb, pps->tile_id_len_minus1 + 1);
else {
-sh->num_remaining_tiles_in_slice_minus1 = get_ue_golomb_long(gb);
-num_tiles_in_slice = sh->num_remaining_tiles_in_slice_minus1 + 2;
+unsigned num_remaining_tiles_in_slice_minus1 =
get_ue_golomb_long(gb);
+if (num_remaining_tiles_in_slice_minus1 > EVC_MAX_TILE_ROWS *
EVC_MAX_TILE_COLUMNS - 2)
+return AVERROR_INVALIDDATA;
+
+num_tiles_in_slice = num_remaining_tiles_in_slice_minus1 + 2;
+sh->num_remaining_tiles_in_slice_minus1 =
num_remaining_tiles_in_slice_minus1;
for (int i = 0; i < num_tiles_in_slice - 1; ++i)
sh->delta_tile_id_minus1[i] = get_ue_golomb_long(gb);
}
--
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 3/4] avcodec/evc_parse: remove pow() and log2()
The use of float based functions is both unneeded and wrong due to
unpredictable rounding
Signed-off-by: Michael Niedermayer
---
libavcodec/evc_parse.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c
index 5ab33166cf3..20b6849041a 100644
--- a/libavcodec/evc_parse.c
+++ b/libavcodec/evc_parse.c
@@ -176,7 +176,8 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
EVCParserSliceHeader *sh,
poc->PicOrderCntVal = 0;
poc->DocOffset = -1;
} else {
-int SubGopLength = (int)pow(2.0, sps->log2_sub_gop_length);
+int SubGopLength = 1 << sps->log2_sub_gop_length;
+
if (tid == 0) {
poc->PicOrderCntVal = poc->prevPicOrderCntVal + SubGopLength;
poc->DocOffset = 0;
@@ -191,15 +192,16 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
EVCParserSliceHeader *sh,
poc->prevPicOrderCntVal += SubGopLength;
ExpectedTemporalId = 0;
} else
-ExpectedTemporalId = 1 + (int)log2(poc->DocOffset);
+ExpectedTemporalId = 1 + av_log2(poc->DocOffset);
+
while (tid != ExpectedTemporalId) {
poc->DocOffset = (poc->DocOffset + 1) % SubGopLength;
if (poc->DocOffset == 0)
ExpectedTemporalId = 0;
else
-ExpectedTemporalId = 1 + (int)log2(poc->DocOffset);
+ExpectedTemporalId = 1 + av_log2(poc->DocOffset);
}
-PocOffset = (int)(SubGopLength * ((2.0 * poc->DocOffset + 1) /
(int)pow(2.0, tid) - 2));
+PocOffset = (int)(SubGopLength * ((2.0 * poc->DocOffset + 1) /
(1 << tid) - 2));
poc->PicOrderCntVal = poc->prevPicOrderCntVal + PocOffset;
}
}
--
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 4/4] avcodec/evc_parse: Check tid
The check is based on not infinite looping. It is likely
a more strict check can be done
Fixes: Infinite loop
Fixes:
62473/clusterfuzz-testcase-minimized-ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-5719883750703104
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/evc_parse.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/evc_parse.c b/libavcodec/evc_parse.c
index 20b6849041a..8c0ef16f3ad 100644
--- a/libavcodec/evc_parse.c
+++ b/libavcodec/evc_parse.c
@@ -178,6 +178,9 @@ int ff_evc_derive_poc(const EVCParamSets *ps, const
EVCParserSliceHeader *sh,
} else {
int SubGopLength = 1 << sps->log2_sub_gop_length;
+if (tid > 1 + av_log2(SubGopLength - 1))
+return AVERROR_INVALIDDATA;
+
if (tid == 0) {
poc->PicOrderCntVal = poc->prevPicOrderCntVal + SubGopLength;
poc->DocOffset = 0;
--
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] aacdec: padding skip improvements
Oct 3, 2023, 18:39 by andreas.rheinha...@outlook.com:
> Lynne:
>
>> The FFmpeg encoder will be modified to also output 2048 samples of
>> padding at the start, to make it in line with other encoders.
>>
>
> Once again: What is the advantage? Doing what lots of other codecs do is
> not a real advantage.
>
>>
>> +{ "padding", "Override the padding at the start of a stream.\n",
>> +offsetof(AACContext, override_padding), AV_OPT_TYPE_INT, { .i64 =
>> 2048 }, 1024, 8192, AACDEC_FLAGS },
>> +
>>
>
> A decoder is supposed to decode and output what is given to it by
> default and not trim it according to what you expect to be normal for
> encoders for a given format. It is not even clear that there are any
> padding samples at the start: The first packet to be fed to the decoder
> could be from the middle of a file. In other words, the default value of
> samples to discard should be zero.
>
There are always at least 1024 samples padded in all AAC files,
this is how an MDCT operates.
Currently, we let that bit of padding through, so absolutely no
streams are gapless when played through our AAC decoder.
2048 is just more widely encountered. I'm posting these patches
to get an opinion:
- do we cut nothing at all (currently)
- do we cut 1024 (required by the standard/algorithm, and currently what our
AAC ENcoder outputs)
- do we cut 2048 (what is most widely expected)
My preference would be 1024. Note: this is only for raw AAC
streams outside of a container. Streams inside of a container are currently
correctly cut, with this value being overridden.
There is also the issue of HE-AAC streams having a lot more padding,
with a lot more variation, but that's for another patch to attempt
to solve (which it probably couldn't).
___
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".
