July 2024 - ffmpeg-devel - lists.ffmpeg.org

RISC-V vector DSP functions: Motivation for commit 446b009
by Michael Platzer 06 Jul '24

06 Jul '24

Hi, Commit 446b0090cbb66ee614dcf6ca79c78dc8eb7f0e37 by Remi Denis-Courmont has replaced RISC-V vector loads and stores with negative stride with vrgather (generalized permutation within vector registers) instructions in order to reverse the elements in a vector register. The commit message explains that this change was done, but it does not explain why. I fail to see what could possibly have motivated this change. The RISC-V vector loads and stores support negative stride values for use cases such as this one. Using vrgather instead replaces the more specific operation with a more generic one, which is likely to be less performant on most HW architectures. In addition, it requires to setup an index vector, thus raising dynamic instruction count. Could someone familiar with this change (perhaps Remi himself) please explain the motivation for this change? Thanks, Michael

2 4

[PATCH 1/2] avutil/stereo3d add Monoscopic View enum value
by James Almer 06 Jul '24

06 Jul '24

We need a way to signal the frame has a single view that doesn't map to any particular eye, and it should be the default one. Signed-off-by: James Almer <jamrial(a)gmail.com> --- The Stereo spec from Apple, which was used to design this API, states "both has_left_eye_view and has_right_eye_view can be set to 0 to indicate that the frame is monoscopic". Since this API is barely two days old, we can change the enum maped to value 0 as an exception. libavutil/stereo3d.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h index 00a5c3900e..77340f72b2 100644 --- a/libavutil/stereo3d.h +++ b/libavutil/stereo3d.h @@ -143,9 +143,9 @@ enum AVStereo3DType { */ enum AVStereo3DView { /** - * Frame contains two packed views. + * Frame is monoscopic. */ - AV_STEREO3D_VIEW_PACKED, + AV_STEREO3D_VIEW_MONO, /** * Frame contains only the left view. @@ -156,6 +156,11 @@ enum AVStereo3DView { * Frame contains only the right view. */ AV_STEREO3D_VIEW_RIGHT, + + /** + * Frame contains two packed views. + */ + AV_STEREO3D_VIEW_PACKED, }; /** -- 2.45.2

4 13

[PATCH 1/3] doc: Explain what "context" means
by Andrew Sayers 06 Jul '24

06 Jul '24

Based largely on the explanation by Stefano Sabatini: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325854.html --- doc/jargon.md | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 doc/jargon.md diff --git a/doc/jargon.md b/doc/jargon.md new file mode 100644 index 0000000000..3b78ffb61f --- /dev/null +++ b/doc/jargon.md @@ -0,0 +1,96 @@ +# Jargon + +Terms used throughout the code that developers may need to know. + +@anchor context + +## Context + +A design pattern that stores the context (e.g. configuration) for a series +of operations in a "context" structure, and moves other information elsewhere. + +Consider a trivial program to print uppercase text: + +```c +/* + * Contextual information about where to print a series of messages + */ +struct UpperCasePrinterContext { + FILE* out; +}; + +/* + * Extra information about messages to print. + * This could be used multiple times in a single context, + * or reused several times across multiple contexts. + */ +struct PrintInfo { + char* str; +}; + +void print( + struct UpperCasePrinterContext * ctx, + struct PrintInfo * info +) { + for ( char* c = info->str; *c; ++c ) { + char C = toupper(*c); + fwrite( &C, 1, 1, ctx->out ); + } +} + +int main() +{ + struct PrintInfo hello, world; + struct UpperCasePrinterContext ctx; + + hello.str = "hello, "; + world.str = "world!\n"; + + ctx.out = stdout; + + print( &ctx, &hello ); + print( &ctx, &world ); + + return 0; +} +``` + +The `UpperCasePrinterContext` object contains the information that's about +the context of the current job (i.e. printing things to standard output). +Information with a lifetime different than that of the context is moved +to the `PrintInfo` object. + +FFmpeg's main context structures all happen to face some common problems: + +- querying, setting and getting options +- handling "private" internal context, including options for + a particular instance of the generic context +- configuring log message verbosity and content + +FFmpeg gradually converged on the AVClass struct to store this information, +then converged on the @ref avoptions "AVOptions" system to manipulate it, +so modern code often uses the terms "context", "AVClass context structure" +and "AVOptions-enabled struct" interchangeably. But it is occasionally +necessary to distinguish between them - for example, AVMediaCodecContext +is a context that does not use AVClass. + +To understand how this all works, consider some requirements for the +`libx264` encoder: + +- it has to support common encoder options like "bitrate" +- it has to support encoder-specific options like "profile" +- it has to provide useful feedback about unsupported options + +Common encoder options like "bitrate" are stored in the AVCodecContext class, +while encoder-specific options like "profile" are stored in an X264Context +instance in AVCodecContext::priv_data. These options are then exposed to +users through a tree of AVOption objects, which include user-visible help +text and machine-readable information about the memory location to read/write +each option. Common @ref avoptions "AVOptions" functionality lets you get +and set those values, and provides readable feedback about errors. Although +X264Context can be set by users, it is not part of the public interface, +so new releases can modify it without affecting the API version. + +FFmpeg itself uses context structures to handle FFmpeg-specific problems, +but the design pattern, as well as the AVClass and @ref avoptions "AVOptions" +implementations, are general solutions you can use for any purpose. -- 2.43.0

8 83

[PATCH] avformat/dvdvideodec: Remove redundant ret initializations
by Marth64 06 Jul '24

06 Jul '24

Remove initializing ret = 0, in areas where ret is only used to hold an error value, immediately returned, and the function would otherwise return a literal 0. Signed-off-by: Marth64 <marth64(a)proxyid.net> --- libavformat/dvdvideodec.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c index f5b7dd33e5..a825e4c0bd 100644 --- a/libavformat/dvdvideodec.c +++ b/libavformat/dvdvideodec.c @@ -1056,7 +1056,7 @@ static int dvdvideo_video_stream_setup(AVFormatContext *s) { DVDVideoDemuxContext *c = s->priv_data; - int ret = 0; + int ret; DVDVideoVTSVideoStreamEntry entry = {0}; video_attr_t video_attr; @@ -1217,7 +1217,7 @@ static int dvdvideo_audio_stream_add_all(AVFormatContext *s) { DVDVideoDemuxContext *c = s->priv_data; - int ret = 0; + int ret; int nb_streams; if (c->opt_menu) @@ -1324,7 +1324,7 @@ static int dvdvideo_subp_stream_add_internal(AVFormatContext *s, uint32_t offset subp_attr_t subp_attr, enum DVDVideoSubpictureViewport viewport) { - int ret = 0; + int ret; DVDVideoPGCSubtitleStreamEntry entry = {0}; entry.viewport = viewport; @@ -1361,7 +1361,7 @@ static int dvdvideo_subp_stream_add_all(AVFormatContext *s) for (int i = 0; i < nb_streams; i++) { - int ret = 0; + int ret; uint32_t subp_control; subp_attr_t subp_attr; video_attr_t video_attr; @@ -1469,7 +1469,7 @@ static int dvdvideo_subdemux_open(AVFormatContext *s) { DVDVideoDemuxContext *c = s->priv_data; extern const FFInputFormat ff_mpegps_demuxer; - int ret = 0; + int ret; if (!(c->mpeg_buf = av_mallocz(DVDVIDEO_BLOCK_SIZE))) return AVERROR(ENOMEM); @@ -1504,7 +1504,7 @@ static int dvdvideo_read_header(AVFormatContext *s) { DVDVideoDemuxContext *c = s->priv_data; - int ret = 0; + int ret; if (c->opt_menu) { if (c->opt_region || -- 2.34.1

2 1

[PATCH] avformat/dvdvideodec: Don't add chapter markers for empty/dummy PTTs
by Marth64 06 Jul '24

06 Jul '24

Some discs (usually same ones with padding cells), also have empty padding PTTs / chapters to accompany them. This results, for example, in an extra chapter marker that starts and ends at 0 (no duration). Don't add these empty chapter markers. Signed-off-by: Marth64 <marth64(a)proxyid.net> --- libavformat/dvdvideodec.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c index f5b7dd33e5..0bf1a82ef9 100644 --- a/libavformat/dvdvideodec.c +++ b/libavformat/dvdvideodec.c @@ -874,6 +874,9 @@ static int dvdvideo_chapters_setup_simple(AVFormatContext *s) for (int i = chapter_start - 1; i < chapter_end; i++) { uint64_t time_effective = c->play_state.pgc_pg_times_est[i] - c->play_state.nav_pts; + if (time_effective - time_prev == 0) + continue; + if (chapter_start != chapter_end && !avpriv_new_chapter(s, i, DVDVIDEO_TIME_BASE_Q, time_prev, time_effective, NULL)) { @@ -934,13 +937,16 @@ static int dvdvideo_chapters_setup_preindex(AVFormatContext *s) continue; } - if (!avpriv_new_chapter(s, nb_chapters, DVDVIDEO_TIME_BASE_Q, cur_chapter_offset, - cur_chapter_offset + cur_chapter_duration, NULL)) { - ret = AVERROR(ENOMEM); - goto end_close; + if (cur_chapter_duration > 0) { + if (!avpriv_new_chapter(s, nb_chapters, DVDVIDEO_TIME_BASE_Q, cur_chapter_offset, + cur_chapter_offset + cur_chapter_duration, NULL)) { + ret = AVERROR(ENOMEM); + goto end_close; + } + + nb_chapters++; } - nb_chapters++; cur_chapter_offset += cur_chapter_duration; cur_chapter_duration = state.vobu_duration; last_ptt = state.ptt; -- 2.34.1

2 1

[PATCH] lavc/h264dsp: R-V V 8-bit h264_weight_pixels
by Rémi Denis-Courmont 06 Jul '24

06 Jul '24

There are two implementations here: - a generic scalable one processing one column at a time, - a specialised processing one (fixed-size) row at a time. Unsurprisingly, the generic one works out better with smaller widths. With larger widths, the gains from filling vectors are outweighed by the extra cost of strided loads and stores. In other words, memory accesses become the bottleneck. T-Head C908: h264_weight2_8_c: 54.2 h264_weight2_8_rvv_i32: 17.5 h264_weight4_8_c: 102.0 h264_weight4_8_rvv_i32: 34.7 h264_weight8_8_c: 213.7 h264_weight8_8_rvv_i32: 79.7 h264_weight16_8_c: 401.0 h264_weight16_8_rvv_i32: 74.2 SpacemiT X60: h264_weight2_8_c: 48.5 h264_weight2_8_rvv_i32: 11.7 h264_weight4_8_c: 90.5 h264_weight4_8_rvv_i32: 23.7 h264_weight8_8_c: 175.0 h264_weight8_8_rvv_i32: 58.0 h264_weight16_8_c: 342.2 h264_weight16_8_rvv_i32: 66.0 --- libavcodec/riscv/h264dsp_init.c | 7 +++ libavcodec/riscv/h264dsp_rvv.S | 77 +++++++++++++++++++++++++++++++++ 2 files changed, 84 insertions(+) diff --git a/libavcodec/riscv/h264dsp_init.c b/libavcodec/riscv/h264dsp_init.c index bf9743eb6b..e1b725dcbb 100644 --- a/libavcodec/riscv/h264dsp_init.c +++ b/libavcodec/riscv/h264dsp_init.c @@ -21,12 +21,15 @@ #include "config.h" #include <stdint.h> +#include <string.h> #include "libavutil/attributes.h" #include "libavutil/cpu.h" #include "libavutil/riscv/cpu.h" #include "libavcodec/h264dsp.h" +extern const h264_weight_func ff_h264_weight_funcs_8_rvv[]; + void ff_h264_v_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride, int alpha, int beta, int8_t *tc0); void ff_h264_h_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride, @@ -60,6 +63,10 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp, const int bit_depth, # if HAVE_RVV if (flags & AV_CPU_FLAG_RVV_I32) { if (bit_depth == 8 && ff_rv_vlen_least(128)) { + memcpy(dsp->weight_h264_pixels_tab, + ff_h264_weight_funcs_8_rvv, + sizeof (dsp->weight_h264_pixels_tab)); + dsp->h264_v_loop_filter_luma = ff_h264_v_loop_filter_luma_8_rvv; dsp->h264_h_loop_filter_luma = ff_h264_h_loop_filter_luma_8_rvv; dsp->h264_h_loop_filter_luma_mbaff = diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S index 96a8a0a8a3..ab85bfbd69 100644 --- a/libavcodec/riscv/h264dsp_rvv.S +++ b/libavcodec/riscv/h264dsp_rvv.S @@ -26,6 +26,83 @@ #include "libavutil/riscv/asm.S" +func ff_h264_weight_pixels_simple_8_rvv, zve32x + csrwi vxrm, 0 + sll a5, a5, a3 +1: + vsetvli zero, a6, e32, m4, ta, ma + vle8.v v8, (a0) + addi a2, a2, -1 + vmv.v.x v16, a5 + vsetvli zero, zero, e16, m2, ta, ma + vzext.vf2 v24, v8 + vwmaccsu.vx v16, a4, v24 + vnclip.wi v16, v16, 0 + vmax.vx v16, v16, zero + vsetvli zero, zero, e8, m1, ta, ma + vnclipu.wx v8, v16, a3 + vse8.v v8, (a0) + add a0, a0, a1 + bnez a2, 1b + + ret +endfunc + +func ff_h264_weight_pixels_8_rvv, zve32x + csrwi vxrm, 0 + sll a5, a5, a3 +1: + mv t0, a0 + mv t6, a6 +2: + vsetvli t2, a2, e32, m8, ta, ma + vlse8.v v8, (t0), a1 + addi t6, t6, -1 + vmv.v.x v16, a5 + vsetvli zero, zero, e16, m4, ta, ma + vzext.vf2 v24, v8 + vwmaccsu.vx v16, a4, v24 + vnclip.wi v16, v16, 0 + vmax.vx v16, v16, zero + vsetvli zero, zero, e8, m2, ta, ma + vnclipu.wx v8, v16, a3 + vsse8.v v8, (t0), a1 + addi t0, t0, 1 + bnez t6, 2b + + mul t3, a1, t2 + sub a2, a2, t2 + add a0, a0, t3 + bnez a2, 1b + + ret +endfunc + +.irp w, 16, 8, 4, 2 +func ff_h264_weight_pixels\w\()_8_rvv, zve32x + li a6, \w + .if \w == 16 + j ff_h264_weight_pixels_simple_8_rvv + .else + j ff_h264_weight_pixels_8_rvv + .endif +endfunc +.endr + + .global ff_h264_weight_funcs_8_rvv + .hidden ff_h264_weight_funcs_8_rvv +const ff_h264_weight_funcs_8_rvv + .irp w, 16, 8, 4, 2 +#if __riscv_xlen == 32 + .word ff_h264_weight_pixels\w\()_8_rvv +#elif __riscv_xlen == 64 + .dword ff_h264_weight_pixels\w\()_8_rvv +#else + .qword ff_h264_weight_pixels\w\()_8_rvv +#endif + .endr +endconst + .variant_cc ff_h264_loop_filter_luma_8_rvv func ff_h264_loop_filter_luma_8_rvv, zve32x # p2: v8, p1: v9, p0: v10, q0: v11, q1: v12, q2: v13 -- 2.45.2

1 2

[PATCHv2 1/2] lavc/h264dsp: R-V V 8-bit h264_weight_pixels
by Rémi Denis-Courmont 06 Jul '24

06 Jul '24

There are two implementations here: - a generic scalable one processing two columns at a time, - a specialised processing one (fixed-size) row at a time. Unsurprisingly, the generic one works out better with smaller widths. With larger widths, the gains from filling vectors are outweighed by the extra cost of strided loads and stores. In other words, memory accesses become the bottleneck. T-Head C908: h264_weight2_8_c: 54.5 h264_weight2_8_rvv_i32: 13.7 h264_weight4_8_c: 101.7 h264_weight4_8_rvv_i32: 27.5 h264_weight8_8_c: 197.0 h264_weight8_8_rvv_i32: 75.5 h264_weight16_8_c: 385.0 h264_weight16_8_rvv_i32: 74.2 SpacemiT X60: h264_weight2_8_c: 48.5 h264_weight2_8_rvv_i32: 8.2 h264_weight4_8_c: 90.7 h264_weight4_8_rvv_i32: 16.5 h264_weight8_8_c: 175.0 h264_weight8_8_rvv_i32: 37.7 h264_weight16_8_c: 342.2 h264_weight16_8_rvv_i32: 66.0 --- Changes since version 1: - Fix arithmetic overflows in bi-weight. - Process two columns rather than one per iteration to fill vectors. --- libavcodec/riscv/h264dsp_init.c | 7 +++ libavcodec/riscv/h264dsp_rvv.S | 83 +++++++++++++++++++++++++++++++++ 2 files changed, 90 insertions(+) diff --git a/libavcodec/riscv/h264dsp_init.c b/libavcodec/riscv/h264dsp_init.c index bf9743eb6b..e1b725dcbb 100644 --- a/libavcodec/riscv/h264dsp_init.c +++ b/libavcodec/riscv/h264dsp_init.c @@ -21,12 +21,15 @@ #include "config.h" #include <stdint.h> +#include <string.h> #include "libavutil/attributes.h" #include "libavutil/cpu.h" #include "libavutil/riscv/cpu.h" #include "libavcodec/h264dsp.h" +extern const h264_weight_func ff_h264_weight_funcs_8_rvv[]; + void ff_h264_v_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride, int alpha, int beta, int8_t *tc0); void ff_h264_h_loop_filter_luma_8_rvv(uint8_t *pix, ptrdiff_t stride, @@ -60,6 +63,10 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp, const int bit_depth, # if HAVE_RVV if (flags & AV_CPU_FLAG_RVV_I32) { if (bit_depth == 8 && ff_rv_vlen_least(128)) { + memcpy(dsp->weight_h264_pixels_tab, + ff_h264_weight_funcs_8_rvv, + sizeof (dsp->weight_h264_pixels_tab)); + dsp->h264_v_loop_filter_luma = ff_h264_v_loop_filter_luma_8_rvv; dsp->h264_h_loop_filter_luma = ff_h264_h_loop_filter_luma_8_rvv; dsp->h264_h_loop_filter_luma_mbaff = diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S index 96a8a0a8a3..bbcbf2e4de 100644 --- a/libavcodec/riscv/h264dsp_rvv.S +++ b/libavcodec/riscv/h264dsp_rvv.S @@ -26,6 +26,89 @@ #include "libavutil/riscv/asm.S" +func ff_h264_weight_pixels_simple_8_rvv, zve32x + csrwi vxrm, 0 + sll a5, a5, a3 +1: + vsetvli zero, a6, e32, m4, ta, ma + vle8.v v8, (a0) + addi a2, a2, -1 + vmv.v.x v16, a5 + vsetvli zero, zero, e16, m2, ta, ma + vzext.vf2 v24, v8 + vwmaccsu.vx v16, a4, v24 + vnclip.wx v16, v16, a3 + vmax.vx v16, v16, zero + vsetvli zero, zero, e8, m1, ta, ma + vnclipu.wi v8, v16, 0 + vse8.v v8, (a0) + add a0, a0, a1 + bnez a2, 1b + + ret +endfunc + +func ff_h264_weight_pixels_8_rvv, zve32x + csrwi vxrm, 0 + sll a5, a5, a3 +1: + mv t0, a0 + mv t6, a6 +2: + vsetvli t2, a2, e32, m8, ta, ma + vlsseg2e8.v v0, (t0), a1 + addi t6, t6, -2 + vmv.v.x v16, a5 + vmv.v.x v24, a5 + vsetvli zero, zero, e16, m4, ta, ma + vzext.vf2 v8, v0 + vzext.vf2 v12, v2 + vwmaccsu.vx v16, a4, v8 + vwmaccsu.vx v24, a4, v12 + vnclip.wx v8, v16, a3 + vnclip.wx v12, v24, a3 + vmax.vx v8, v8, zero + vmax.vx v12, v12, zero + vsetvli zero, zero, e8, m2, ta, ma + vnclipu.wi v0, v8, 0 + vnclipu.wi v2, v12, 0 + vssseg2e8.v v0, (t0), a1 + addi t0, t0, 2 + bnez t6, 2b + + mul t3, a1, t2 + sub a2, a2, t2 + add a0, a0, t3 + bnez a2, 1b + + ret +endfunc + +.irp w, 16, 8, 4, 2 +func ff_h264_weight_pixels\w\()_8_rvv, zve32x + li a6, \w + .if \w == 16 + j ff_h264_weight_pixels_simple_8_rvv + .else + j ff_h264_weight_pixels_8_rvv + .endif +endfunc +.endr + + .global ff_h264_weight_funcs_8_rvv + .hidden ff_h264_weight_funcs_8_rvv +const ff_h264_weight_funcs_8_rvv + .irp w, 16, 8, 4, 2 +#if __riscv_xlen == 32 + .word ff_h264_weight_pixels\w\()_8_rvv +#elif __riscv_xlen == 64 + .dword ff_h264_weight_pixels\w\()_8_rvv +#else + .qword ff_h264_weight_pixels\w\()_8_rvv +#endif + .endr +endconst + .variant_cc ff_h264_loop_filter_luma_8_rvv func ff_h264_loop_filter_luma_8_rvv, zve32x # p2: v8, p1: v9, p0: v10, q0: v11, q1: v12, q2: v13 -- 2.45.2

1 1

[PATCH 1/6] avcodec/packet: add a decoded frame cropping side data type
by James Almer 05 Jul '24

05 Jul '24

Signed-off-by: James Almer <jamrial(a)gmail.com> --- libavcodec/packet.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/libavcodec/packet.h b/libavcodec/packet.h index a9a41576da..9dee035690 100644 --- a/libavcodec/packet.h +++ b/libavcodec/packet.h @@ -330,6 +330,20 @@ enum AVPacketSideDataType { */ AV_PKT_DATA_AMBIENT_VIEWING_ENVIRONMENT, + /** + * The number of pixels to discard from the + * top/bottom/left/right border of the decoded frame to obtain the sub-rectangle + * intended for presentation. + * + * @code + * u32le crop_top + * u32le crop_bottom + * u32le crop_left + * u32le crop_right + * @endcode + */ + AV_PKT_DATA_FRAME_CROPPING, + /** * The number of side data types. * This is not part of the public API/ABI in the sense that it may -- 2.45.1

7 26

Sorry state of AVOptions
by Paul B Mahol 05 Jul '24

05 Jul '24

The AVOptions state is extremely ugly. It is insane to request from library users to convert non-strings option values from/to strings to be able to read/change them, it is ugly, inefficient, and slow. This becomes more relevant for recent array options extension for which av_opt_ptr() hack does not work at all. Get this fix ASAP!

4 14

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavu/opt: add array options
by Michael Niedermayer 05 Jul '24

05 Jul '24

On Fri, Mar 08, 2024 at 07:06:17AM +0000, Anton Khirnov wrote: > ffmpeg | branch: master | Anton Khirnov <anton(a)khirnov.net> | Thu Feb 8 08:50:18 2024 +0100| [efe447877811f2f14f814e80ce71383e2f056f36] | committer: Anton Khirnov > > lavu/opt: add array options > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=efe447877811f2f14… > --- > > doc/APIchanges | 3 + > libavutil/opt.c | 360 ++++++++++++++++++++++++++++++++++++++++++++------ > libavutil/opt.h | 56 +++++++- > libavutil/tests/opt.c | 49 +++++++ > libavutil/version.h | 2 +- > tests/ref/fate/opt | 35 ++++- > 6 files changed, 459 insertions(+), 46 deletions(-) [...] > --- a/libavutil/opt.h > +++ b/libavutil/opt.h > @@ -250,6 +250,17 @@ enum AVOptionType{ > AV_OPT_TYPE_COLOR, > AV_OPT_TYPE_BOOL, > AV_OPT_TYPE_CHLAYOUT, > + > + /** > + * May be combined with another regular option type to declare an array > + * option. > + * > + * For array options, @ref AVOption.offset should refer to a pointer > + * corresponding to the option type. The pointer should be immediately > + * followed by an unsigned int that will store the number of elements in the > + * array. > + */ > + AV_OPT_TYPE_FLAG_ARRAY = (1 << 16), This sounds like it suggests undefined behavior taking a pointer to a pointer of lets say a array of float and adding 1 and then dereferencing this as int is undefined behavior A pointer created that way may not be aligned correctly. This just happens to work on the major platforms ... Or said differently a int *array ; int array_len in a struct arent guranteed to have the same distance between each other each time. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu

2 1