Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Timothée <timothee.informatique@regaud-chapuy.fr>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/4] avutil: add generic side data for video coding info
Date: Sun, 20 Jul 2025 20:24:46 +0200
Message-ID: <c85ce775-a538-45a2-a0f3-c33fca832ee5@regaud-chapuy.fr> (raw)
In-Reply-To: <81146431-8734-4dd1-a46d-f45ad40dd484@lynne.ee>

On 18/07/2025 19:42, Lynne a wrote :
> On 18/07/2025 19:30, Timothée Regaud wrote:
>> From: Timothee Regaud <timothee.informatique@regaud-chapuy.fr>
>>
>> Adds the generic data structures to libavutil. The design is 
>> recursive to support other codecs, even though the implementation is 
>> only for H.264 for now.
>>
>> Signed-off-by: Timothee Regaud <timothee.informatique@regaud-chapuy.fr>
>> ---
>>   libavutil/Makefile            |   1 +
>>   libavutil/frame.h             |   7 ++
>>   libavutil/side_data.c         |   1 +
>>   libavutil/video_coding_info.h | 163 ++++++++++++++++++++++++++++++++++
>>   4 files changed, 172 insertions(+)
>>   create mode 100644 libavutil/video_coding_info.h
>>
>> diff --git a/libavutil/Makefile b/libavutil/Makefile
>> index 94a56bb72f..44e51ab7ae 100644
>> --- a/libavutil/Makefile
>> +++ b/libavutil/Makefile
>> @@ -93,6 +93,7 @@ HEADERS = 
>> adler32.h                                                     \
>> tree.h                                                        \
>> twofish.h                                                     \
>> uuid.h                                                        \
>> + video_coding_info.h                                           \
>> version.h                                                     \
>> video_enc_params.h                                            \
>> xtea.h                                                        \
>> diff --git a/libavutil/frame.h b/libavutil/frame.h
>> index c50cd263d9..f4404472a0 100644
>> --- a/libavutil/frame.h
>> +++ b/libavutil/frame.h
>> @@ -254,6 +254,13 @@ enum AVFrameSideDataType {
>>        * libavutil/tdrdi.h.
>>        */
>>       AV_FRAME_DATA_3D_REFERENCE_DISPLAYS,
>> +
>> +    /**
>> +     * Detailed block-level coding information. The data is an 
>> AVVideoCodingInfo
>> +     * structure. This is exported by video decoders and can be used 
>> by filters
>> +     * for analysis and visualization.
>> +     */
>> +    AV_FRAME_DATA_VIDEO_CODING_INFO,
>>   };
>>     enum AVActiveFormatDescription {
>> diff --git a/libavutil/side_data.c b/libavutil/side_data.c
>> index fa2a2c2a13..b938ef6f52 100644
>> --- a/libavutil/side_data.c
>> +++ b/libavutil/side_data.c
>> @@ -56,6 +56,7 @@ static const AVSideDataDescriptor sd_props[] = {
>>       [AV_FRAME_DATA_SEI_UNREGISTERED]            = { "H.26[45] User 
>> Data Unregistered SEI message",  AV_SIDE_DATA_PROP_MULTI },
>>       [AV_FRAME_DATA_VIDEO_HINT]                  = { "Encoding video 
>> hint", AV_SIDE_DATA_PROP_SIZE_DEPENDENT },
>>       [AV_FRAME_DATA_3D_REFERENCE_DISPLAYS]       = { "3D Reference 
>> Displays Information", AV_SIDE_DATA_PROP_GLOBAL },
>> +    [AV_FRAME_DATA_VIDEO_CODING_INFO]           = { "Video Coding 
>> Info", AV_SIDE_DATA_PROP_SIZE_DEPENDENT },
>>   };
>>     const AVSideDataDescriptor *av_frame_side_data_desc(enum 
>> AVFrameSideDataType type)
>> diff --git a/libavutil/video_coding_info.h 
>> b/libavutil/video_coding_info.h
>> new file mode 100644
>> index 0000000000..17e9345892
>> --- /dev/null
>> +++ b/libavutil/video_coding_info.h
>> @@ -0,0 +1,163 @@
>> +/*
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
>> 02110-1301 USA
>> + */
>> +
>> +#ifndef AVUTIL_VIDEO_CODING_INFO_H
>> +#define AVUTIL_VIDEO_CODING_INFO_H
>> +
>> +#include <stdint.h>
>> +#include <stddef.h>
>> +
>> +/**
>> + * @file
>> + * @ingroup lavu_frame
>> + * Structures for describing block-level video coding information.
>> + */
>> +
>> +/**
>> + * @defgroup lavu_video_coding_info Video Coding Info
>> + * @ingroup lavu_frame
>> + *
>> + * @{
>> + * Structures for describing block-level video coding information, 
>> to be
>> + * attached to an AVFrame as side data.
>> + *
>> + * All pointer-like members in these structures are offsets relative 
>> to the
>> + * start of the AVVideoCodingInfo struct to ensure the side data is
>> + * self-contained and relocatable. This is critical as the 
>> underlying buffer
>> + * may be moved in memory.
>> + */
>> +
>> +/**
>> + * Structure to hold inter-prediction information for a block.
>> + */
>> +typedef struct AVBlockInterInfo {
>> +    /**
>> +     * Offsets to motion vectors for list 0 and list 1, relative to the
>> +     * start of the AVVideoCodingInfo struct.
>> +     * The data for each list is an array of [x, y] pairs of int16_t.
>> +     * The number of vectors is given by num_mv.
>> +     * An offset of 0 indicates this data is not present.
>> +     */
>> +    size_t mv_offset[2];
>> +
>> +    /**
>> +     * Offsets to reference indices for list 0 and list 1, relative 
>> to the
>> +     * start of the AVVideoCodingInfo struct.
>> +     * The data is an array of int8_t. A value of -1 indicates the 
>> reference
>> +     * is not used for a specific partition.
>> +     * An offset of 0 indicates this data is not present.
>> +     */
>> +    size_t ref_idx_offset[2];
>> +    /**
>> +     * Number of motion vectors for list 0 and list 1.
>> +     */
>> +    uint8_t num_mv[2];
>> +} AVBlockInterInfo;
>> +
>> +/**
>> + * Structure to hold intra-prediction information for a block.
>> + */
>> +typedef struct AVBlockIntraInfo {
>> +    /**
>> +     * Offset to an array of intra prediction modes, relative to the
>> +     * start of the AVVideoCodingInfo struct.
>> +     * The number of modes is given by num_pred_modes.
>> +     */
>> +    size_t pred_mode_offset;
>> +
>> +    /**
>> +     * Number of intra prediction modes.
>> +     */
>> +    uint8_t num_pred_modes;
>> +
>> +    /**
>> +     * Chroma intra prediction mode.
>> +     */
>> +    uint8_t chroma_pred_mode;
>> +} AVBlockIntraInfo;
>> +
>> +/**
>> + * Main structure for a single coding block.
>> + * This structure can be recursive for codecs that use tree-based 
>> partitioning.
>> + */
>> +typedef struct AVVideoCodingInfoBlock {
>> +    /**
>> +     * Position (x, y) and size (w, h) of the block, in pixels,
>> +     * relative to the top-left corner of the frame.
>> +     */
>> +    int16_t x, y;
>> +    uint8_t w, h;
>> +
>> +    /**
>> +     * Flag indicating if the block is intra-coded.
>> +     * 1 if intra, 0 if inter.
>> +     */
>> +    uint8_t is_intra;
>> +
>> +    /**
>> +     * The original, codec-specific type of this block or macroblock.
>> +     * This allows a filter to have codec-specific logic for 
>> interpreting
>> +     * the generic prediction information based on the source codec.
>> +     * For example, for H.264, this would store the MB type flags 
>> (MB_TYPE_*).
>> +     */
>> +    uint32_t codec_specific_type;
>> +
>> +    union {
>> +        AVBlockIntraInfo intra;
>> +        AVBlockInterInfo inter;
>> +    };
>> +
>> +    /**
>> +     * Number of child blocks this block is partitioned into.
>> +     * If 0, this is a leaf node in the partition tree.
>> +     */
>> +    uint8_t num_children;
>> +
>> +    /**
>> +     * Offset to an array of child AVVideoCodingInfoBlock 
>> structures, relative
>> +     * to the start of the AVVideoCodingInfo struct.
>> +     * This allows for recursive representation of coding structures.
>> +     * An offset of 0 indicates there are no children.
>> +     */
>> +    size_t children_offset;
>> +} AVVideoCodingInfoBlock;
>> +
>> +/**
>> + * Top-level structure to be attached to an AVFrame as side data.
>> + * It contains an array of the highest-level coding blocks (e.g., 
>> CTUs or MBs).
>> + */
>> +typedef struct AVVideoCodingInfo {
>> +    /**
>> +     * Number of top-level blocks in the frame.
>> +     */
>> +    uint32_t nb_blocks;
>> +
>> +    /**
>> +     * Offset to an array of top-level blocks, relative to the start 
>> of the
>> +     * AVVideoCodingInfo struct.
>> +     * The actual data for these blocks, and any child blocks or 
>> sub-data,
>> +     * is stored contiguously in the AVBufferRef attached to the 
>> side data.
>> +     */
>> +    size_t blocks_offset;
>> +} AVVideoCodingInfo;
>> +
>> +/**
>> + * @}
>> + */
>> +
>> +#endif /* AVUTIL_VIDEO_CODING_INFO_H */
>
> Absolutely not.
> Use and extend libavutil/video_enc_params.h instead.
Adding it to `libavutil/video_enc_params.h` seemed counter-intuitive to 
me, as that header is for encoder-centric parameters, while my structs 
describe decoded data. However, I agree it is better for API 
consistency, so I will move them in v2.
>  And if at all possible, don't implement an inspection tool in ffmpeg 
> *just because you want to*. Parsing a bitstream and displaying it is 
> not a very complicated thing, but exposing an API very much is a very 
> complicated thing.

I completely understand your concern about exposing a new API just for a 
single inspection tool. My implementation in vf_codecview is intended as 
a proof-of-concept to demonstrate the utility of this exported data. 
This data has many potential uses, such as analysis, debugging new 
codecs, academic research, and more. But I can agree that my 
implementation in codecview isn't that useful. Therefore, it would be 
better to have a new flag, similar to the existing -flags2 +export_mvs.I 
will add a new flag, -flags2 +export_coding_info, so the data can be 
used by other tools.

Thanks,

Timothée

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

      reply	other threads:[~2025-07-20 18:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-18 10:30 Timothée Regaud
2025-07-18 10:30 ` [FFmpeg-devel] [PATCH 2/4] avcodec: add option to export " Timothée Regaud
2025-07-18 10:30 ` [FFmpeg-devel] [PATCH 3/4] avcodec/h264dec: implement export of video coding info for H.264 Timothée Regaud
2025-07-18 14:17   ` Michael Niedermayer
2025-07-18 10:30 ` [FFmpeg-devel] [PATCH 4/4] vf_codecview: add support for AV_FRAME_DATA_VIDEO_CODING_INFO Timothée Regaud
2025-07-18 15:48 ` [FFmpeg-devel] [PATCH 1/4] avutil: add generic side data for video coding info Michael Niedermayer
2025-07-20 18:24   ` Timothée
2025-07-18 17:42 ` Lynne
2025-07-20 18:24   ` Timothée [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c85ce775-a538-45a2-a0f3-c33fca832ee5@regaud-chapuy.fr \
    --to=timothee.informatique@regaud-chapuy.fr \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git