Re: [FFmpeg-devel] Graphprint Patches Overview

[softworkz .]

> > From: Kieran Kunhya  
> > Sent: Donnerstag, 22. Mai 2025 16:07
> > To: softworkz . 
> > Cc: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> > 
> > 
> > On Thu, 22 May 2025, 15:03 softworkz .,  
> > wrote:
> > 
> > 
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of 
> > > Kieran
> > > Kunhya via ffmpeg-devel
> > > Sent: Donnerstag, 22. Mai 2025 14:46
> > > To: FFmpeg development discussions and patches 
> > > 
> > > Cc: Kieran Kunhya 
> > > Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> > > 
> > > > I really wonder how Kieran can't be embarrassed trying such maneuvers 
> > > > which
> > > > are so obvious to everybody.
> > > 
> > > I really wonder how you can't be embarrassed sending what imo is the
> > > worst patchset in the history of the project.
> > > Instead of acknowledging that, it's deflecting and playing the victim
> > > you want to do.
> > > 
> > > Kieran
> > > ___
> > 
> > I like that! Keep going. Was that all you got?
> > 
> > sw
> 
> A patchset so bad, people who quit the project like Derek came back to clean 
> up your mess.
> 
> Kieran 
> 
> people who quit the project like Derek came back

That'd be too much of an honour - but really, it doesn't work like that. 
You need to keep focusing on saying bad and defaming things.

Try again, I'm sure you can do better...

sw



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

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: add scale_d3d11 filter

[Timo Rothenpieler]

On 22/05/2025 15:20, Dash Santosh Sathyanarayanan wrote:

This commit introduces a new hardware-accelerated video filter, scale_d3d11,
which performs scaling and format conversion using Direct3D 11. The filter 
enables
efficient GPU-based scaling and pixel format conversion (p010 to nv12), reducing
CPU overhead and latency in video pipelines.
---
  Changelog |   1 +
  libavcodec/decode.c   |   2 +-
  libavcodec/dxva2.c|   3 +
  libavfilter/Makefile  |   1 +
  libavfilter/allfilters.c  |   1 +
  libavfilter/vf_scale_d3d11.c  | 480 ++
  libavutil/hwcontext_d3d11va.c |  40 ++-
  7 files changed, 514 insertions(+), 14 deletions(-)
  create mode 100644 libavfilter/vf_scale_d3d11.c

diff --git a/Changelog b/Changelog
index 4217449438..68610a63d0 100644
--- a/Changelog
+++ b/Changelog
@@ -18,6 +18,7 @@ version :
  - APV encoding support through a libopenapv wrapper
  - VVC decoder supports all content of SCC (Screen Content Coding):
IBC (Inter Block Copy), Palette Mode and ACT (Adaptive Color Transform
+- vf_scale_d3d11 filter


Bit of a nit, this could at last say "Added".

  
  
  version 7.1:

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index c2b2dd6e3b..a796ae7930 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1079,7 +1079,7 @@ int ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
  if (frames_ctx->initial_pool_size) {
  // We guarantee 4 base work surfaces. The function above guarantees 1
  // (the absolute minimum), so add the missing count.
-frames_ctx->initial_pool_size += 3;
+frames_ctx->initial_pool_size += 33;


This seems a bit extreme, and can potentially drastically increase VRAM 
usage of anything using d3d11va.



  }
  
  ret = av_hwframe_ctx_init(avctx->hw_frames_ctx);

diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 22ecd5acaf..37dab6cd68 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -647,6 +647,9 @@ int ff_dxva2_common_frame_params(AVCodecContext *avctx,
  AVD3D11VAFramesContext *frames_hwctx = frames_ctx->hwctx;
  
  frames_hwctx->BindFlags |= D3D11_BIND_DECODER;

+if (frames_ctx->sw_format == AV_PIX_FMT_NV12) {
+frames_hwctx->BindFlags |= D3D11_BIND_VIDEO_ENCODER;
+}


This change also seems a bit random here. Using NV12 does not 
automatically mean you'll encode with it.



Did not look at the rest yet.

+return AVERROR_EXTERNAL;
+}
+
+///< Set up output frame
+ret = av_frame_copy_props(out, in);
+if (ret < 0) {
+av_log(ctx, AV_LOG_ERROR, "Failed to copy frame properties\n");
+videoContext->lpVtbl->Release(videoContext);
+inputView->lpVtbl->Release(inputView);
+av_frame_free(&in);
+av_frame_free(&out);
+return ret;
+}
+
+out->data[0] = (uint8_t *)output_texture;
+out->data[1] = (uint8_t *)(intptr_t)0;
+out->width = s->width;
+out->height = s->height;
+out->format = AV_PIX_FMT_D3D11;
+
+///< Clean up resources
+inputView->lpVtbl->Release(inputView);
+videoContext->lpVtbl->Release(videoContext);
+if (s->outputView) {
+s->outputView->lpVtbl->Release(s->outputView);
+s->outputView = NULL;
+}
+av_frame_free(&in);
+
+///< Forward the frame
+return ff_filter_frame(outlink, out);
+}
+
+static int scale_d3d11_config_props(AVFilterLink *outlink)
+{
+AVFilterContext *ctx = outlink->src;
+ScaleD3D11Context *s = ctx->priv;
+AVFilterLink *inlink = ctx->inputs[0];
+FilterLink *inl = ff_filter_link(inlink);
+FilterLink *outl = ff_filter_link(outlink);
+int ret;
+
+///< Clean up any previous resources
+release_d3d11_resources(s);
+
+///< Evaluate output dimensions
+ret = ff_scale_eval_dimensions(s, s->w_expr, s->h_expr, inlink, outlink, 
&s->width, &s->height);
+if (ret < 0) {
+av_log(ctx, AV_LOG_ERROR, "Failed to evaluate dimensions\n");
+return ret;
+}
+
+outlink->w = s->width;
+outlink->h = s->height;
+
+///< Validate input hw_frames_ctx
+if (!inl->hw_frames_ctx) {
+av_log(ctx, AV_LOG_ERROR, "No hw_frames_ctx available on input 
link\n");
+return AVERROR(EINVAL);
+}
+
+///< Propagate hw_frames_ctx to output
+outl->hw_frames_ctx = av_buffer_ref(inl->hw_frames_ctx);
+if (!outl->hw_frames_ctx) {
+av_log(ctx, AV_LOG_ERROR, "Failed to propagate hw_frames_ctx to 
output\n");
+return AVERROR(ENOMEM);
+}
+
+///< Initialize filter's hardware device context
+if (!s->hw_device_ctx) {
+AVHWFramesContext *in_frames_ctx = (AVHWFramesContext 
*)inl->hw_frames_ctx->data;
+s->hw_device_ctx = av_buffer_ref(in_frames_ctx->device_ref);
+if (!s->hw_device_ctx) {
+av_log(ctx, AV_LOG_ERROR, "Failed to initialize filter hardware device 
context\n");
+return AVERROR(ENOMEM);
+ 

Re: [FFmpeg-devel] Graphprint Patches Overview

[Kieran Kunhya via ffmpeg-devel]

> I really wonder how Kieran can't be embarrassed trying such maneuvers which
> are so obvious to everybody.

I really wonder how you can't be embarrassed sending what imo is the
worst patchset in the history of the project.
Instead of acknowledging that, it's deflecting and playing the victim
you want to do.

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

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

[FFmpeg-devel] [PATCH 2/2] avcodec/mfenc: add support for D3D11 input surfaces

[Dash Santosh Sathyanarayanan]

Adds D3D11 input surface support to the MediaFoundation encoder (mfenc),
allowing direct encoding of GPU frames without readback to system memory.
This improves performance and compatibility when used alongside scale_d3d11.
---
 Changelog |   1 +
 libavcodec/mf_utils.h |   7 ++
 libavcodec/mfenc.c| 204 --
 3 files changed, 183 insertions(+), 29 deletions(-)

diff --git a/Changelog b/Changelog
index 68610a63d0..194f09121f 100644
--- a/Changelog
+++ b/Changelog
@@ -19,6 +19,7 @@ version :
 - VVC decoder supports all content of SCC (Screen Content Coding):
   IBC (Inter Block Copy), Palette Mode and ACT (Adaptive Color Transform
 - vf_scale_d3d11 filter
+- mfenc supports d3d11 input surfaces
 
 
 version 7.1:
diff --git a/libavcodec/mf_utils.h b/libavcodec/mf_utils.h
index a59b36d015..ecebb6fcdf 100644
--- a/libavcodec/mf_utils.h
+++ b/libavcodec/mf_utils.h
@@ -53,6 +53,13 @@ typedef struct MFFunctions {
IMFMediaBuffer **ppBuffer);
 HRESULT (WINAPI *MFCreateSample) (IMFSample **ppIMFSample);
 HRESULT (WINAPI *MFCreateMediaType) (IMFMediaType **ppMFType);
+HRESULT (WINAPI *MFCreateDXGISurfaceBuffer) (REFIID riid,
+IUnknown* punkSurface,
+UINT uSubresourceIndex,
+BOOL fBottomUpWhenLinear,
+IMFMediaBuffer** ppBuffer);
+HRESULT (WINAPI *MFCreateDXGIDeviceManager) (UINT* resetToken,
+IMFDXGIDeviceManager** 
ppDeviceManager);
 // MFTEnumEx is missing in Windows Vista's mfplat.dll.
 HRESULT (WINAPI *MFTEnumEx)(GUID guidCategory, UINT32 Flags,
 const MFT_REGISTER_TYPE_INFO *pInputType,
diff --git a/libavcodec/mfenc.c b/libavcodec/mfenc.c
index c9e2191fde..7ddf918c9a 100644
--- a/libavcodec/mfenc.c
+++ b/libavcodec/mfenc.c
@@ -31,10 +31,17 @@
 #include "codec_internal.h"
 #include "internal.h"
 #include "compat/w32dlfcn.h"
+#if CONFIG_D3D11VA
+#include "libavutil/hwcontext_d3d11va.h"
+#endif
 
 typedef struct MFContext {
 AVClass *av_class;
 HMODULE library;
+HMODULE d3d_dll;
+IMFDXGIDeviceManager *dxgiManager;
+int resetToken;
+
 MFFunctions functions;
 AVFrame *frame;
 int is_video, is_audio;
@@ -47,6 +54,7 @@ typedef struct MFContext {
 int out_stream_provides_samples;
 int draining, draining_done;
 int sample_sent;
+int stream_started;
 int async_need_input, async_have_output, async_marker;
 int64_t reorder_delay;
 ICodecAPI *codec_api;
@@ -55,6 +63,7 @@ typedef struct MFContext {
 int opt_enc_quality;
 int opt_enc_scenario;
 int opt_enc_hw;
+AVD3D11VADeviceContext* device_hwctx;
 } MFContext;
 
 static int mf_choose_output_type(AVCodecContext *avctx);
@@ -303,36 +312,118 @@ static IMFSample *mf_a_avframe_to_sample(AVCodecContext 
*avctx, const AVFrame *f
 return sample;
 }
 
-static IMFSample *mf_v_avframe_to_sample(AVCodecContext *avctx, const AVFrame 
*frame)
+static int initialize_dxgi_manager(AVCodecContext *avctx)
 {
 MFContext *c = avctx->priv_data;
-IMFSample *sample;
-IMFMediaBuffer *buffer;
-BYTE *data;
+MFFunctions *func = &c->functions;
 HRESULT hr;
-int ret;
-int size;
+
+hr = func->MFCreateDXGIDeviceManager(&c->resetToken, &c->dxgiManager);
+if (FAILED(hr)) {
+av_log(avctx, AV_LOG_ERROR, "Failed to create DXGI device manager: 
%s\n", ff_hr_str(hr));
+return AVERROR_EXTERNAL;
+}
+
+hr = IMFDXGIDeviceManager_ResetDevice(c->dxgiManager, 
c->device_hwctx->device, c->resetToken);
+if (FAILED(hr)) {
+av_log(avctx, AV_LOG_ERROR, "Failed to reset device: %s\n", 
ff_hr_str(hr));
+return AVERROR_EXTERNAL;
+}
+
+hr = IMFTransform_ProcessMessage(c->mft, MFT_MESSAGE_SET_D3D_MANAGER, 
(ULONG_PTR)c->dxgiManager);
+if (FAILED(hr)) {
+av_log(avctx, AV_LOG_ERROR, "Failed to set D3D manager: %s\n", 
ff_hr_str(hr));
+return AVERROR_EXTERNAL;
+}
+
+return 0;
+}
+
+static int process_d3d11_frame(AVCodecContext *avctx, const AVFrame *frame, 
IMFSample **out_sample)
+{
+MFContext *c = avctx->priv_data;
+MFFunctions *func = &c->functions;
+AVHWFramesContext *frames_ctx = NULL;
+ID3D11Texture2D *d3d11_texture = NULL;
+IMFSample *sample = NULL;
+IMFMediaBuffer *buffer = NULL;
+int subIdx = 0;
+HRESULT hr;
+
+frames_ctx = (AVHWFramesContext*)frame->hw_frames_ctx->data;
+c->device_hwctx = (AVD3D11VADeviceContext*)frames_ctx->device_ctx->hwctx;
+
+if (!c->dxgiManager) {
+hr = initialize_dxgi_manager(avctx);
+if (FAILED(hr)) {
+return AVERROR_EXTERNAL;
+}
+}
+
+d3d11_texture = (ID3D11Texture2D*)frame->data[0];
+subIdx = (int)(intptr_t)frame->data[1];
+
+if (!d3d11_texture) {
+av_log(avctx, AV_LOG_ER

[FFmpeg-devel] [PATCH] swscale/output: Implement neon intrinsics for yuv2nv12cX_c()

[Harshitha Sarangu Suresh]

This optimization provides 6x improvement for the module. The boost in 
performance was calculated by adding C timers inside the C function and the 
optimized neon intrinsic function.



>From 1deceb0394a5acdf70677870dc252fd66a91dd9f Mon Sep 17 00:00:00 2001
From: Harshitha Suresh 
Date: Mon, 19 May 2025 22:37:20 +0530
Subject: [PATCH] swscale/output: Implement neon intrinsics for yuv2nv12cX_c()

---
 libswscale/aarch64/swscale.c | 151 +++
 1 file changed, 151 insertions(+)

diff --git a/libswscale/aarch64/swscale.c b/libswscale/aarch64/swscale.c
index 6e5a721c1f..fb59c3f1b0 100644
--- a/libswscale/aarch64/swscale.c
+++ b/libswscale/aarch64/swscale.c
@@ -21,6 +21,9 @@
 #include "libswscale/swscale.h"
 #include "libswscale/swscale_internal.h"
 #include "libavutil/aarch64/cpu.h"
+#if defined (__aarch64__)
+#include 
+#endif

 void ff_hscale16to15_4_neon_asm(int shift, int16_t *_dst, int dstW,
   const uint8_t *_src, const int16_t *filter,
@@ -142,6 +145,153 @@ static void ff_hscale16to19_X4_neon(SwsInternal *c, 
int16_t *_dst, int dstW,

 }

+static void ff_yuv2nv12cX_neon(enum AVPixelFormat dstFormat, const uint8_t 
*chrDither,
+const int16_t *chrFilter, int chrFilterSize,
+const int16_t **chrUSrc, const int16_t **chrVSrc,
+uint8_t *dest, int chrDstW)
+{
+
+int i;
+int u_dither[8], v_dither[8];
+for (i = 0; i < 8; i++) {
+u_dither[i] = chrDither[i & 7] << 12;
+v_dither[i] = chrDither[(i + 3) & 7] << 12;
+}
+int32x4_t u0 = vld1q_s32(&u_dither[0]);
+int32x4_t u1 = vld1q_s32(&u_dither[4]);
+int32x4_t v0 = vld1q_s32(&v_dither[0]);
+int32x4_t v1 = vld1q_s32(&v_dither[4]);
+
+if (!isSwappedChroma(dstFormat))
+{
+for (i = 0; i <= chrDstW - 8; i += 8)
+{
+int32x4_t udst0 = u0;
+int32x4_t udst1 = u1;
+int32x4_t vdst0 = v0;
+int32x4_t vdst1 = v1;
+
+for (int j = 0; j < chrFilterSize; j++)
+{
+int16x8_t usrc0 = vld1q_s16(&chrUSrc[j][i]);
+int16x8_t vsrc0 = vld1q_s16(&chrVSrc[j][i]);
+
+int32x4_t usrc0_low = vmovl_s16(vget_low_s16(usrc0));
+int32x4_t usrc0_high = vmovl_s16(vget_high_s16(usrc0));
+int32x4_t vsrc0_low = vmovl_s16(vget_low_s16(vsrc0));
+int32x4_t vsrc0_high = vmovl_s16(vget_high_s16(vsrc0));
+
+udst0 = vmlaq_n_s32(udst0, usrc0_low, chrFilter[j]);
+udst1 = vmlaq_n_s32(udst1, usrc0_high, chrFilter[j]);
+vdst0 = vmlaq_n_s32(vdst0, vsrc0_low, chrFilter[j]);
+vdst1 = vmlaq_n_s32(vdst1, vsrc0_high, chrFilter[j]);
+
+}
+// Right shift by 19
+udst0 = vshrq_n_s32(udst0, 19);
+udst1 = vshrq_n_s32(udst1, 19);
+vdst0 = vshrq_n_s32(vdst0, 19);
+vdst1 = vshrq_n_s32(vdst1, 19);
+
+// Convert to 16-bit and then to uint8, with saturation
+int16x8_t u16 = vcombine_s16(vqmovn_s32(udst0), vqmovn_s32(udst1));
+int16x8_t v16 = vcombine_s16(vqmovn_s32(vdst0), vqmovn_s32(vdst1));
+
+uint8x8_t u8 = vqmovun_s16(u16);
+uint8x8_t v8 = vqmovun_s16(v16);
+
+// Store interleaved u/v as UV UV UV...
+uint8x8x2_t uv;
+uv.val[0] = u8;
+uv.val[1] = v8;
+vst2_u8(dest + 2 * i, uv);
+}
+
+// Handle remaining pixels with scalar fallback
+for (; i < chrDstW; i++)
+{
+int u = chrDither[i & 7] << 12;
+int v = chrDither[(i + 3) & 7] << 12;
+
+for (int j = 0; j < chrFilterSize; j++)
+{
+u += chrUSrc[j][i] * chrFilter[j];
+v += chrVSrc[j][i] * chrFilter[j];
+}
+
+uint8_t uu = av_clip_uint8(u >> 19);
+uint8_t vv = av_clip_uint8(v >> 19);
+dest[2 * i] = uu;
+dest[2 * i + 1] = vv;
+}
+}
+else
+{
+if (!isSwappedChroma(dstFormat))
+{
+for (i = 0; i <= chrDstW - 8; i += 8)
+{
+int32x4_t udst0 = u0;
+int32x4_t udst1 = u1;
+int32x4_t vdst0 = v0;
+int32x4_t vdst1 = v1;
+
+for (int j = 0; j < chrFilterSize; j++)
+{
+int16x8_t usrc = vld1q_s16(&chrUSrc[j][i]);
+int16x8_t vsrc = vld1q_s16(&chrVSrc[j][i]);
+
+int32x4_t usrc_low = vmovl_s16(vget_low_s16(usrc));
+int32x4_t usrc_high = vmovl_s16(vget_high_s16(usrc));
+int32x4_t vsrc_low = vmovl_s16(vget_low_s16(vsrc));
+int32x4_t vsrc_high = vmovl_s16(vget_high_s16(vsrc));
+
+udst0 = vmlaq_n_s32(udst0, usrc_low, chrFilter[j]);
+udst1 = vmlaq_n_s32(udst1, usrc_high, chrFilter[j]);
+   

[FFmpeg-devel] [PATCH] swscale/output: Implement neon intrinsics for yuv2planeX_10_c_template()

[Harshitha Sarangu Suresh]

This optimization provides 5x improvement for the module. The boost in 
performance was calculated by adding C timers inside the C function and the 
optimized neon intrinsic function.


>From 904144c2db9e5e72d56360c4c2eb38d426852901 Mon Sep 17 00:00:00 2001
From: Harshitha Suresh 
Date: Thu, 22 May 2025 10:23:55 +0530
Subject: [PATCH] swscale/output: Implement neon intrinsics for
 yuv2planeX_10_c_template()

---
 libswscale/output.c | 76 -
 1 file changed, 75 insertions(+), 1 deletion(-)

diff --git a/libswscale/output.c b/libswscale/output.c
index c37649e7ce..345df5ce59 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -22,7 +22,9 @@
 #include 
 #include 
 #include 
-
+#if defined (__aarch64__)
+#include 
+#endif
 #include "libavutil/attributes.h"
 #include "libavutil/avutil.h"
 #include "libavutil/avassert.h"
@@ -337,6 +339,77 @@ yuv2plane1_10_c_template(const int16_t *src, uint16_t 
*dest, int dstW,
 }
 }

+
+#if defined (__aarch64__) && !defined(__APPLE__)
+static av_always_inline void
+yuv2planeX_10_c_template(const int16_t *filter, int filterSize,
+ const int16_t **src, uint16_t *dest, int dstW,
+ int big_endian, int output_bits)
+{
+const int shift = 11 + 16 - output_bits;
+const int bias = 1 << (shift - 1);
+const int clip_max = (1 << output_bits) - 1;
+int i;
+
+for (i = 0; i < dstW; i += 16) {
+int32x4_t sum0_lo = vdupq_n_s32(bias);
+int32x4_t sum0_hi = vdupq_n_s32(bias);
+int32x4_t sum1_lo = vdupq_n_s32(bias);
+int32x4_t sum1_hi = vdupq_n_s32(bias);
+
+for (int j = 0; j < filterSize; j++) {
+int16x8_t src_vec0 = vld1q_s16(&src[j][i]);
+int16x8_t src_vec1 = vld1q_s16(&src[j][i + 8]);
+int16x8_t filter_val = vdupq_n_s16(filter[j]);
+
+sum0_lo = vmlal_s16(sum0_lo, vget_low_s16(src_vec0), 
vget_low_s16(filter_val));
+sum0_hi = vmlal_s16(sum0_hi, vget_high_s16(src_vec0), 
vget_high_s16(filter_val));
+sum1_lo = vmlal_s16(sum1_lo, vget_low_s16(src_vec1), 
vget_low_s16(filter_val));
+sum1_hi = vmlal_s16(sum1_hi, vget_high_s16(src_vec1), 
vget_high_s16(filter_val));
+}
+
+// Right shift with rounding
+int32x4_t shift_vec = vdupq_n_s32(-shift);
+sum0_lo = vshlq_s32(sum0_lo, shift_vec);
+sum0_hi = vshlq_s32(sum0_hi, shift_vec);
+sum1_lo = vshlq_s32(sum1_lo, shift_vec);
+sum1_hi = vshlq_s32(sum1_hi, shift_vec);
+
+// Clip to output_bits range
+sum0_lo = vmaxq_s32(vminq_s32(sum0_lo, vdupq_n_s32(clip_max)), 
vdupq_n_s32(0));
+sum0_hi = vmaxq_s32(vminq_s32(sum0_hi, vdupq_n_s32(clip_max)), 
vdupq_n_s32(0));
+sum1_lo = vmaxq_s32(vminq_s32(sum1_lo, vdupq_n_s32(clip_max)), 
vdupq_n_s32(0));
+sum1_hi = vmaxq_s32(vminq_s32(sum1_hi, vdupq_n_s32(clip_max)), 
vdupq_n_s32(0));
+
+// Convert to 16-bit
+uint16x8_t result0 = vcombine_u16(
+vreinterpret_u16_s16(vmovn_s32(sum0_lo)),
+vreinterpret_u16_s16(vmovn_s32(sum0_hi))
+);
+uint16x8_t result1 = vcombine_u16(
+vreinterpret_u16_s16(vmovn_s32(sum1_lo)),
+vreinterpret_u16_s16(vmovn_s32(sum1_hi))
+);
+
+// Store with proper endianness
+if (big_endian) {
+result0 = 
vreinterpretq_u16_u8(vrev16q_u8(vreinterpretq_u8_u16(result0)));
+result1 = 
vreinterpretq_u16_u8(vrev16q_u8(vreinterpretq_u8_u16(result1)));
+}
+vst1q_u16(&dest[i], result0);
+vst1q_u16(&dest[i + 8], result1);
+}
+
+// Handle remaining pixels
+for (; i < dstW; i++) {
+int val = bias;
+for (int j = 0; j < filterSize; j++) {
+val += src[j][i] * filter[j];
+}
+output_pixel(&dest[i], val);
+}
+}
+#else
 static av_always_inline void
 yuv2planeX_10_c_template(const int16_t *filter, int filterSize,
  const int16_t **src, uint16_t *dest, int dstW,
@@ -355,6 +428,7 @@ yuv2planeX_10_c_template(const int16_t *filter, int 
filterSize,
 output_pixel(&dest[i], val);
 }
 }
+#endif

 #undef output_pixel

--
2.36.0.windows.1





0001-swscale-output-Implement-neon-intrinsics-for-yuv2pla.patch
Description: 0001-swscale-output-Implement-neon-intrinsics-for-yuv2pla.patch
___
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] Graphprint Patches Overview

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of softworkz .
> Sent: Donnerstag, 22. Mai 2025 16:14
> To: Kieran Kunhya 
> Cc: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> 
> 
> 
> > > From: Kieran Kunhya 
> > > Sent: Donnerstag, 22. Mai 2025 16:07
> > > To: softworkz . 
> > > Cc: FFmpeg development discussions and patches 
> > > Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> > >
> > >
> > > On Thu, 22 May 2025, 15:03 softworkz ., 
> wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel  On Behalf Of
> Kieran
> > > > Kunhya via ffmpeg-devel
> > > > Sent: Donnerstag, 22. Mai 2025 14:46
> > > > To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> > > > Cc: Kieran Kunhya 
> > > > Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> > > >
> > > > > I really wonder how Kieran can't be embarrassed trying such maneuvers
> which
> > > > > are so obvious to everybody.
> > > >
> > > > I really wonder how you can't be embarrassed sending what imo is the
> > > > worst patchset in the history of the project.
> > > > Instead of acknowledging that, it's deflecting and playing the victim
> > > > you want to do.
> > > >
> > > > Kieran
> > > > ___
> > >
> > > I like that! Keep going. Was that all you got?
> > >
> > > sw
> >
> > A patchset so bad, people who quit the project like Derek came back to clean
> up your mess.
> >
> > Kieran
> >
> > people who quit the project like Derek came back
> 
> That'd be too much of an honour - but really, it doesn't work like that.
> You need to keep focusing on saying bad and defaming things.
> 
> Try again, I'm sure you can do better...
> 
> sw
> ___

What's up, running out of ideas?

Maybe get even more dirty - that's always a good idea when your points
have no substance, it emphasizes your dedication and makes it more credible
for everybody.

How about this: 

Softworkz also ruined Christmas this year because he stole Santa's reindeer!

sw




___
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] [FEATURE PROPOSAL] Extracting codec-level data to binary files

[Ramiro Polla]

Hi,

On Thu, May 22, 2025 at 1:59 PM Ronald S. Bultje  wrote:
> On Wed, May 21, 2025 at 9:34 AM Timothée <
> timothee.informati...@regaud-chapuy.fr> wrote:
> > I am interested in expanding ffmpeg's capabilities to extract
> > low-level data from video codecs. Specifically, I'd like to implement
> > functionality that would allow exporting frame data, macroblock
> > information, quantization tables, and similar codec-specific elements
> > to binary files for further analysis.
> >
> > After searching through the documentation and existing features, I
> > haven't found similar functionality, though I may have missed
> > something. Has this been implemented before, or are there related
> > features I should examine?
>
> Some older codecs implement minor variants for this, e.g. grep
> for AV_FRAME_DATA_MOTION_VECTORS, which attaches a frame's motion vectors
> to the picture data. I believe there's an example app and possibly a filter
> to overlay MVs on top of the video frame based on this concept. You could
> extend this to cover other (macro)block info. There used to be a variant of
> this for quant-tables also but I can't find it, maybe it was removed.

If I recall correctly, we wanted to move away from exporting more of
this kind of codec-specific information as picture data.

Timothée, this kind of feature depends a lot on the codec that you
want to work with. It will also depend on which syntax elements you
need from the codec. In FFmpeg, there is the CBS code which describes
the bitstream for a few codecs, which might help you.

I have a separate project (called FFglitch), which lets you export
some elements (such as quantization tables, dct coefficients, and
motion vectors) from some codecs (jpeg, mpeg2, mpeg4) to JSON format,
and even modify them in the bitstream.

In the end, it will depend on what you want to do with the extracted
low-level data, and for which codecs.

Ramiro
___
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 v3] avformat/dhav: fix backward scanning for get_duration and optimize seeking

[Derek Buitenhuis]

On 5/21/2025 2:23 PM, Derek Buitenhuis wrote:
> ---
>  libavformat/dhav.c | 54 +-
>  1 file changed, 39 insertions(+), 15 deletions(-)

Will push later today or tomorrow, with fixed commit message, if there
are no further comments.

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

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

[FFmpeg-devel] [PATCH 1/2] doc/examples/filter_audio: use av_err2str

[Tristan Matthews]

---
 doc/examples/filter_audio.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/doc/examples/filter_audio.c b/doc/examples/filter_audio.c
index 8b237e2adf..0f5914 100644
--- a/doc/examples/filter_audio.c
+++ b/doc/examples/filter_audio.c
@@ -270,7 +270,6 @@ int main(int argc, char *argv[])
 AVFilterGraph *graph;
 AVFilterContext *src, *sink;
 AVFrame *frame;
-uint8_t errstr[1024];
 float duration;
 int err, nb_frames, i;
 
@@ -354,7 +353,6 @@ int main(int argc, char *argv[])
 return 0;
 
 fail:
-av_strerror(err, errstr, sizeof(errstr));
-fprintf(stderr, "%s\n", errstr);
+fprintf(stderr, "%s\n", av_err2str(err));
 return 1;
 }
-- 
2.45.2

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

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

[FFmpeg-devel] [PATCH 2/2] doc/examples/qsv_decode: use av_err2str

[Tristan Matthews]

---
 doc/examples/qsv_decode.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/doc/examples/qsv_decode.c b/doc/examples/qsv_decode.c
index 5a6f3625aa..ec91109480 100644
--- a/doc/examples/qsv_decode.c
+++ b/doc/examples/qsv_decode.c
@@ -219,11 +219,8 @@ int main(int argc, char **argv)
 ret = decode_packet(decoder_ctx, frame, sw_frame, NULL, output_ctx);
 
 finish:
-if (ret < 0) {
-char buf[1024];
-av_strerror(ret, buf, sizeof(buf));
-fprintf(stderr, "%s\n", buf);
-}
+if (ret < 0)
+fprintf(stderr, "%s\n", av_err2str(ret));
 
 avformat_close_input(&input_ctx);
 
-- 
2.45.2

___
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] [FEATURE PROPOSAL] Extracting codec-level data to binary files

[Timothée]

The 2025-05-22T14:33:22.000+02:00, Ramiro Polla
 wrote :

> Hi,
> 
> On Thu, May 22, 2025 at 1:59 PM Ronald S. Bultje  wrote:
> 
>>  On Wed, May 21, 2025 at 9:34 AM Timothée <
>>  timothee.informati...@regaud-chapuy.fr> wrote: 
>>  
>>>   I am interested in expanding ffmpeg's capabilities to extract
>>>   low-level data from video codecs. Specifically, I'd like to
>>>   implement functionality that would allow exporting frame data,
>>>   macroblock information, quantization tables, and similar
>>>   codec-specific elements to binary files for further analysis.
>>>   After searching through the documentation and existing features,
>>>   I haven't found similar functionality, though I may have missed
>>>   something. Has this been implemented before, or are there
>>>   related features I should examine?
>>  
>>   Some older codecs implement minor variants for this, e.g. grep
>>  for AV_FRAME_DATA_MOTION_VECTORS, which attaches a frame's motion
>>  vectors to the picture data. I believe there's an example app and
>>  possibly a filter to overlay MVs on top of the video frame based
>>  on this concept. You could extend this to cover other (macro)block
>>  info. There used to be a variant of this for quant-tables also but
>>  I can't find it, maybe it was removed.
> 
>  If I recall correctly, we wanted to move away from exporting more
> of this kind of codec-specific information as picture data.
> Timothée, this kind of feature depends a lot on the codec that you
> want to work with. It will also depend on which syntax elements you
> need from the codec. In FFmpeg, there is the CBS code which
> describes the bitstream for a few codecs, which might help you. I
> have a separate project (called FFglitch), which lets you export
> some elements (such as quantization tables, dct coefficients, and
> motion vectors) from some codecs (jpeg, mpeg2, mpeg4) to JSON
> format, and even modify them in the bitstream. In the end, it will
> depend on what you want to do with the extracted low-level data, and
> for which codecs. Ramiro

Thank you for your response and for mentioning FFglitch - it looks
like an excellent project that's very relevant to what I'm trying to
accomplish.

I have a question about FFglitch's capabilities: is it possible to
extract quantization parameter (QP) tables using ffedit? I've reviewed
the documentation but may have missed this functionality if it exists.

Ideally I would want to extract data for all existing codecs, but I
know this is impossible. My current focus is on implementing this
feature for H.264, with plans to extend support to H.265 and AVI
formats as well. I want to extract this data for scientific use.

Thank you again for your time and suggestions.

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-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/http: Handle IPv6 Zone ID in hostname

[Marvin Scholz]

When using a literal IPv6 address as hostname, it can contain a Zone ID
especially in the case of link-local addresses. Sending this to the
server in the Host header is not useful to the server and in some cases
servers refuse such requests.

To prevent any such issues, strip the Zone ID from the address if it's
an IPv6 address. This also removes it for the Cookies lookup.

Based on a patch by: Daniel N Pettersson 
---
 libavformat/http.c | 60 +-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index f7b2a8a029..3bde616b43 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -24,6 +24,7 @@
 #include "config.h"
 #include "config_components.h"
 
+#include 
 #include 
 #if CONFIG_ZLIB
 #include 
@@ -209,6 +210,63 @@ void ff_http_init_auth_state(URLContext *dest, const 
URLContext *src)
sizeof(HTTPAuthState));
 }
 
+static bool host_is_numeric_ipv6(const char *host)
+{
+bool res = false;
+#if defined(AF_INET6)
+struct addrinfo hints = { .ai_flags = AI_NUMERICHOST }, *ai;
+if (getaddrinfo(host, NULL, &hints, &ai) == 0) {
+if (ai->ai_family == AF_INET6)
+res = true;
+freeaddrinfo(ai);
+}
+#else
+// Just guess based on if the host contains a ':'
+if (strchr(host, ':') != NULL)
+res = true;
+#endif
+return res;
+}
+
+/**
+ * Copy the normalized host to the given buffer
+ *
+ * If the host is a normal hostname, this just returns
+ * host:port. However in case of an IPv6 address, it
+ * ensures proper escaping with [] and removes the
+ * zone identifier, if any, making the return suitable
+ * for example for use in the HTTP Host header.
+ */
+static unsigned copy_normalized_host(char *out, unsigned size,
+   const char *host, const int port)
+{
+AVBPrint bp;
+av_bprint_init_for_buffer(&bp, out, size);
+
+if (host_is_numeric_ipv6(host)) {
+// This is an IPv6 address, so we need to strip the Zone ID,
+// if any.
+// While technically we could have percent encoding even in
+// the Zone ID, this doesn't seem to be a relevant case in
+// the real world on any platform.
+char *percent = strrchr(host, '%');
+if (percent) {
+int len = (percent - host);
+av_bprintf(&bp, "[%.*s]", len, host);
+} else {
+av_bprintf(&bp, "[%s]", host);
+}
+} else {
+// Host is not an IPv6 address, so just use as-is
+av_bprintf(&bp, "%s", host);
+}
+
+if (port >= 0)
+av_bprintf(&bp, ":%d", port);
+
+return bp.len;
+}
+
 static int http_open_cnx_internal(URLContext *h, AVDictionary **options)
 {
 const char *path, *proxy_path, *lower_proto = "tcp", *local_path;
@@ -224,7 +282,7 @@ static int http_open_cnx_internal(URLContext *h, 
AVDictionary **options)
 av_url_split(proto, sizeof(proto), auth, sizeof(auth),
  hostname, sizeof(hostname), &port,
  path1, sizeof(path1), s->location);
-ff_url_join(hoststr, sizeof(hoststr), NULL, NULL, hostname, port, NULL);
+copy_normalized_host(hoststr, sizeof(hoststr), hostname, port);
 
 env_http_proxy = getenv_utf8("http_proxy");
 proxy_path = s->http_proxy ? s->http_proxy : env_http_proxy;
-- 
2.39.5 (Apple Git-154)

___
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] Graphprint Patches Overview

[Kieran Kunhya via ffmpeg-devel]

On Thu, May 22, 2025 at 12:24 PM Michael Niedermayer
 wrote:
> 4. "seeing the scale of memory leaks." try to compare this to
>IAMF "git log --grep IAMF --oneline", IAMF is after a year still receiving
>frequent security fixes. This is just as a comparission

This is completely different, one is taking untrusted data and one is
creating it.

> What you are doing is trying to gain from somewhat popular oppinions
> at the expense of the project and team.
>
> many disliked the "opening of a browser" and thats now resolved
> and reverted, but instead of letting the wounds heal you throw salt in them.
> And while people are working and improving the code you push another
> round of animosity

No, I am expressing my opinion (which several people share) and I am
entitled to do so in the same way you are.

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

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

[FFmpeg-devel] [PATCH 1/2] avfilter: add scale_d3d11 filter

[Dash Santosh Sathyanarayanan]

This commit introduces a new hardware-accelerated video filter, scale_d3d11,
which performs scaling and format conversion using Direct3D 11. The filter 
enables
efficient GPU-based scaling and pixel format conversion (p010 to nv12), reducing
CPU overhead and latency in video pipelines.
---
 Changelog |   1 +
 libavcodec/decode.c   |   2 +-
 libavcodec/dxva2.c|   3 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_scale_d3d11.c  | 480 ++
 libavutil/hwcontext_d3d11va.c |  40 ++-
 7 files changed, 514 insertions(+), 14 deletions(-)
 create mode 100644 libavfilter/vf_scale_d3d11.c

diff --git a/Changelog b/Changelog
index 4217449438..68610a63d0 100644
--- a/Changelog
+++ b/Changelog
@@ -18,6 +18,7 @@ version :
 - APV encoding support through a libopenapv wrapper
 - VVC decoder supports all content of SCC (Screen Content Coding):
   IBC (Inter Block Copy), Palette Mode and ACT (Adaptive Color Transform
+- vf_scale_d3d11 filter
 
 
 version 7.1:
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index c2b2dd6e3b..a796ae7930 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1079,7 +1079,7 @@ int ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
 if (frames_ctx->initial_pool_size) {
 // We guarantee 4 base work surfaces. The function above guarantees 1
 // (the absolute minimum), so add the missing count.
-frames_ctx->initial_pool_size += 3;
+frames_ctx->initial_pool_size += 33;
 }
 
 ret = av_hwframe_ctx_init(avctx->hw_frames_ctx);
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 22ecd5acaf..37dab6cd68 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -647,6 +647,9 @@ int ff_dxva2_common_frame_params(AVCodecContext *avctx,
 AVD3D11VAFramesContext *frames_hwctx = frames_ctx->hwctx;
 
 frames_hwctx->BindFlags |= D3D11_BIND_DECODER;
+if (frames_ctx->sw_format == AV_PIX_FMT_NV12) {
+frames_hwctx->BindFlags |= D3D11_BIND_VIDEO_ENCODER;
+}
 }
 #endif
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 0effe4127f..dc46e946f2 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -461,6 +461,7 @@ OBJS-$(CONFIG_ROBERTS_OPENCL_FILTER) += 
vf_convolution_opencl.o opencl.o
 OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
 OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
 OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale_eval.o 
framesync.o
+OBJS-$(CONFIG_SCALE_D3D11_FILTER)+= vf_scale_d3d11.o scale_eval.o
 OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o scale_eval.o \
 vf_scale_cuda.ptx.o 
cuda/load_helper.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale_eval.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 5ea33cdf01..a20fff57e7 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -435,6 +435,7 @@ extern const FFFilter ff_vf_scale;
 extern const FFFilter ff_vf_vpp_amf;
 extern const FFFilter ff_vf_sr_amf;
 extern const FFFilter ff_vf_scale_cuda;
+extern const FFFilter ff_vf_scale_d3d11;
 extern const FFFilter ff_vf_scale_npp;
 extern const FFFilter ff_vf_scale_qsv;
 extern const FFFilter ff_vf_scale_vaapi;
diff --git a/libavfilter/vf_scale_d3d11.c b/libavfilter/vf_scale_d3d11.c
new file mode 100644
index 00..e079424002
--- /dev/null
+++ b/libavfilter/vf_scale_d3d11.c
@@ -0,0 +1,480 @@
+/*
+ * Copyright (C) 2025 MulticorewWare, Inc.
+ *
+ * Authors: Dash Santosh 
+ *  Sachin 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "compat/w32dlfcn.h"
+
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_d3d11va.h"
+
+#include "filters.h"
+#include "scale_eval.h"
+#include "video.h"
+
+enum OutputFormat {
+OUTPUT_NV12 = 0,
+OUTPUT_P010 = 1,
+};
+
+typedef struct ScaleD3D11Context {
+const AVClass *classCtx;
+char *w_expr;
+char *h_expr;
+int output_format_opt;
+
+///< D3D11 objects
+ID3D11Device *device;
+ID3D11DeviceContext *context;

Re: [FFmpeg-devel] Graphprint Patches Overview

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Kieran
> Kunhya via ffmpeg-devel
> Sent: Donnerstag, 22. Mai 2025 14:46
> To: FFmpeg development discussions and patches 
> Cc: Kieran Kunhya 
> Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> 
> > I really wonder how Kieran can't be embarrassed trying such maneuvers which
> > are so obvious to everybody.
> 
> I really wonder how you can't be embarrassed sending what imo is the
> worst patchset in the history of the project.
> Instead of acknowledging that, it's deflecting and playing the victim
> you want to do.
> 
> Kieran
> ___

I like that! Keep going. Was that all you got?

sw
___
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] Graphprint Patches Overview

[Kieran Kunhya via ffmpeg-devel]

On Thu, 22 May 2025, 15:03 softworkz .,  wrote:

>
>
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Kieran
> > Kunhya via ffmpeg-devel
> > Sent: Donnerstag, 22. Mai 2025 14:46
> > To: FFmpeg development discussions and patches 
> > Cc: Kieran Kunhya 
> > Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> >
> > > I really wonder how Kieran can't be embarrassed trying such maneuvers
> which
> > > are so obvious to everybody.
> >
> > I really wonder how you can't be embarrassed sending what imo is the
> > worst patchset in the history of the project.
> > Instead of acknowledging that, it's deflecting and playing the victim
> > you want to do.
> >
> > Kieran
> > ___
>
> I like that! Keep going. Was that all you got?
>
> sw
>

A patchset so bad, people who quit the project like Derek came back to
clean up your mess.

Kieran

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

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

Re: [FFmpeg-devel] [FEATURE PROPOSAL] Extracting codec-level data to binary files

[Ramiro Polla]

On Thu, May 22, 2025 at 7:03 PM Timothée
 wrote:
> The 2025-05-22T14:33:22.000+02:00, Ramiro Polla
>  wrote :
> > On Thu, May 22, 2025 at 1:59 PM Ronald S. Bultje  wrote:
> >>  On Wed, May 21, 2025 at 9:34 AM Timothée <
> >>  timothee.informati...@regaud-chapuy.fr> wrote:
> >>>   I am interested in expanding ffmpeg's capabilities to extract
> >>>   low-level data from video codecs. Specifically, I'd like to
> >>>   implement functionality that would allow exporting frame data,
> >>>   macroblock information, quantization tables, and similar
> >>>   codec-specific elements to binary files for further analysis.
> >>>   After searching through the documentation and existing features,
> >>>   I haven't found similar functionality, though I may have missed
> >>>   something. Has this been implemented before, or are there
> >>>   related features I should examine?
> >>
> >>   Some older codecs implement minor variants for this, e.g. grep
> >>  for AV_FRAME_DATA_MOTION_VECTORS, which attaches a frame's motion
> >>  vectors to the picture data. I believe there's an example app and
> >>  possibly a filter to overlay MVs on top of the video frame based
> >>  on this concept. You could extend this to cover other (macro)block
> >>  info. There used to be a variant of this for quant-tables also but
> >>  I can't find it, maybe it was removed.
> >
> >  If I recall correctly, we wanted to move away from exporting more
> > of this kind of codec-specific information as picture data.
> > Timothée, this kind of feature depends a lot on the codec that you
> > want to work with. It will also depend on which syntax elements you
> > need from the codec. In FFmpeg, there is the CBS code which
> > describes the bitstream for a few codecs, which might help you. I
> > have a separate project (called FFglitch), which lets you export
> > some elements (such as quantization tables, dct coefficients, and
> > motion vectors) from some codecs (jpeg, mpeg2, mpeg4) to JSON
> > format, and even modify them in the bitstream. In the end, it will
> > depend on what you want to do with the extracted low-level data, and
> > for which codecs. Ramiro
>
> Thank you for your response and for mentioning FFglitch - it looks
> like an excellent project that's very relevant to what I'm trying to
> accomplish.
>
> I have a question about FFglitch's capabilities: is it possible to
> extract quantization parameter (QP) tables using ffedit? I've reviewed
> the documentation but may have missed this functionality if it exists.

You can get the dqt for jpeg and qscale for mpeg-2, but that's about
it for the moment.

> Ideally I would want to extract data for all existing codecs, but I
> know this is impossible. My current focus is on implementing this
> feature for H.264, with plans to extend support to H.265 and AVI
> formats as well. I want to extract this data for scientific use.

I see a few qp fields in libavcodec/cbs_h264.h and
libavcodec/cbs_h265.h. I've never used this functionality before, but
it might help you.

OTOH, if you want to add h264 support to FFglitch I would be very happy :)

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

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

Re: [FFmpeg-devel] [PATCH 1/2] doc/examples/filter_audio: use av_err2str

[Marvin Scholz]

On 22 May 2025, at 18:57, Tristan Matthews wrote:

> ---
>  doc/examples/filter_audio.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/doc/examples/filter_audio.c b/doc/examples/filter_audio.c
> index 8b237e2adf..0f5914 100644
> --- a/doc/examples/filter_audio.c
> +++ b/doc/examples/filter_audio.c
> @@ -270,7 +270,6 @@ int main(int argc, char *argv[])
>  AVFilterGraph *graph;
>  AVFilterContext *src, *sink;
>  AVFrame *frame;
> -uint8_t errstr[1024];
>  float duration;
>  int err, nb_frames, i;
>
> @@ -354,7 +353,6 @@ int main(int argc, char *argv[])
>  return 0;
>
>  fail:
> -av_strerror(err, errstr, sizeof(errstr));
> -fprintf(stderr, "%s\n", errstr);
> +fprintf(stderr, "%s\n", av_err2str(err));
>  return 1;
>  }
> -- 
> 2.45.2

Patchset LGTM

>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] lavc/h2645_parse: More descriptive NALU header error

[Frank Plowman]

Signed-off-by: Frank Plowman 
---
 libavcodec/h2645_parse.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 82816999e8..4b9a9e0891 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -22,6 +22,7 @@
 
 #include "config.h"
 
+#include "libavutil/error.h"
 #include "libavutil/intmath.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/mem.h"
@@ -588,8 +589,11 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 } else
 ret = h264_parse_nal_header(nal, logctx);
 if (ret < 0) {
-av_log(logctx, AV_LOG_WARNING, "Invalid NAL unit %d, skipping.\n",
-   nal->type);
+char err_str[AV_ERROR_MAX_STRING_SIZE];
+av_strerror(ret, err_str, AV_ERROR_MAX_STRING_SIZE);
+av_log(logctx, AV_LOG_WARNING,
+   "Failed to parse header of NALU (type %d): \"%s\". Skipping 
NALU.\n",
+   nal->type, err_str);
 continue;
 }
 
-- 
2.47.0

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: add scale_d3d11 filter

[Dash Santosh Sathyanarayanan]

On 22-05-2025 20:55, Timo Rothenpieler wrote:
> On 22/05/2025 15:20, Dash Santosh Sathyanarayanan wrote:
>> This commit introduces a new hardware-accelerated video filter, 
>> scale_d3d11,
>> which performs scaling and format conversion using Direct3D 11. The 
>> filter enables
>> efficient GPU-based scaling and pixel format conversion (p010 to 
>> nv12), reducing
>> CPU overhead and latency in video pipelines.
>> ---
>>   Changelog |   1 +
>>   libavcodec/decode.c   |   2 +-
>>   libavcodec/dxva2.c    |   3 +
>>   libavfilter/Makefile  |   1 +
>>   libavfilter/allfilters.c  |   1 +
>>   libavfilter/vf_scale_d3d11.c  | 480 ++
>>   libavutil/hwcontext_d3d11va.c |  40 ++-
>>   7 files changed, 514 insertions(+), 14 deletions(-)
>>   create mode 100644 libavfilter/vf_scale_d3d11.c
>>
>> diff --git a/Changelog b/Changelog
>> index 4217449438..68610a63d0 100644
>> --- a/Changelog
>> +++ b/Changelog
>> @@ -18,6 +18,7 @@ version :
>>   - APV encoding support through a libopenapv wrapper
>>   - VVC decoder supports all content of SCC (Screen Content Coding):
>>     IBC (Inter Block Copy), Palette Mode and ACT (Adaptive Color 
>> Transform
>> +- vf_scale_d3d11 filter
>
> Bit of a nit, this could at last say "Added".
Oops, sorry. My bad.
>
>>       version 7.1:
>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>> index c2b2dd6e3b..a796ae7930 100644
>> --- a/libavcodec/decode.c
>> +++ b/libavcodec/decode.c
>> @@ -1079,7 +1079,7 @@ int ff_decode_get_hw_frames_ctx(AVCodecContext 
>> *avctx,
>>   if (frames_ctx->initial_pool_size) {
>>   // We guarantee 4 base work surfaces. The function above 
>> guarantees 1
>>   // (the absolute minimum), so add the missing count.
>> -    frames_ctx->initial_pool_size += 3;
>> +    frames_ctx->initial_pool_size += 33;
>
> This seems a bit extreme, and can potentially drastically increase 
> VRAM usage of anything using d3d11va.
In full hardware pipeline, when all surfaces are in use, we hit pool 
exhaustion and 'static pool size exceeded' error occurs. Hence the 
change. The increase in memory footprint was about ~100mb with this change.
>
>>   }
>>     ret = av_hwframe_ctx_init(avctx->hw_frames_ctx);
>> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
>> index 22ecd5acaf..37dab6cd68 100644
>> --- a/libavcodec/dxva2.c
>> +++ b/libavcodec/dxva2.c
>> @@ -647,6 +647,9 @@ int ff_dxva2_common_frame_params(AVCodecContext 
>> *avctx,
>>   AVD3D11VAFramesContext *frames_hwctx = frames_ctx->hwctx;
>>     frames_hwctx->BindFlags |= D3D11_BIND_DECODER;
>> +    if (frames_ctx->sw_format == AV_PIX_FMT_NV12) {
>> +    frames_hwctx->BindFlags |= D3D11_BIND_VIDEO_ENCODER;
>> +    }
>
> This change also seems a bit random here. Using NV12 does not 
> automatically mean you'll encode with it.
The encoder requires D3D11_BIND_VIDEO_ENCODER to be set in the input 
surface, when sending the D3D11 surface directly to MF encoder. 
Currently MF encoder supports only 8bit (NV12). Hence the change. If the 
input is 10bit (P010), scale_d3d11 can be configured to output 8bit NV12 
frames.
>
>
> Did not look at the rest yet.
>> +    return AVERROR_EXTERNAL;
>> +    }
>> +
>> +    ///< Set up output frame
>> +    ret = av_frame_copy_props(out, in);
>> +    if (ret < 0) {
>> +    av_log(ctx, AV_LOG_ERROR, "Failed to copy frame properties\n");
>> +    videoContext->lpVtbl->Release(videoContext);
>> +    inputView->lpVtbl->Release(inputView);
>> +    av_frame_free(&in);
>> +    av_frame_free(&out);
>> +    return ret;
>> +    }
>> +
>> +    out->data[0] = (uint8_t *)output_texture;
>> +    out->data[1] = (uint8_t *)(intptr_t)0;
>> +    out->width = s->width;
>> +    out->height = s->height;
>> +    out->format = AV_PIX_FMT_D3D11;
>> +
>> +    ///< Clean up resources
>> +    inputView->lpVtbl->Release(inputView);
>> +    videoContext->lpVtbl->Release(videoContext);
>> +    if (s->outputView) {
>> + s->outputView->lpVtbl->Release(s->outputView);
>> +    s->outputView = NULL;
>> +    }
>> +    av_frame_free(&in);
>> +
>> +    ///< Forward the frame
>> +    return ff_filter_frame(outlink, out);
>> +}
>> +
>> +static int scale_d3d11_config_props(AVFilterLink *outlink)
>> +{
>> +    AVFilterContext *ctx = outlink->src;
>> +    ScaleD3D11Context *s = ctx->priv;
>> +    AVFilterLink *inlink = ctx->inputs[0];
>> +    FilterLink *inl = ff_filter_link(inlink);
>> +    FilterLink *outl = ff_filter_link(outlink);
>> +    int ret;
>> +
>> +    ///< Clean up any previous resources
>> +    release_d3d11_resources(s);
>> +
>> +    ///< Evaluate output dimensions
>> +    ret = ff_scale_eval_dimensions(s, s->w_expr, s->h_expr, inlink, 
>> outlink, &s->width, &s->height);
>> +    if (ret < 0) {
>> +    av_log(ctx, AV_LOG_ERROR, "Failed to evaluate dimensions\n");
>> +    return ret;
>> +    }
>> +
>> +    outlink->w = s->width;
>> +    outl

Re: [FFmpeg-devel] [PATCH 1/2] doc/examples/filter_audio: use av_err2str

[Tristan Matthews]

On Thu, May 22, 2025 at 1:42 PM Marvin Scholz  wrote:
>
> On 22 May 2025, at 18:57, Tristan Matthews wrote:
>
> > ---
> >  doc/examples/filter_audio.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/doc/examples/filter_audio.c b/doc/examples/filter_audio.c
> > index 8b237e2adf..0f5914 100644
> > --- a/doc/examples/filter_audio.c
> > +++ b/doc/examples/filter_audio.c
> > @@ -270,7 +270,6 @@ int main(int argc, char *argv[])
> >  AVFilterGraph *graph;
> >  AVFilterContext *src, *sink;
> >  AVFrame *frame;
> > -uint8_t errstr[1024];
> >  float duration;
> >  int err, nb_frames, i;
> >
> > @@ -354,7 +353,6 @@ int main(int argc, char *argv[])
> >  return 0;
> >
> >  fail:
> > -av_strerror(err, errstr, sizeof(errstr));
> > -fprintf(stderr, "%s\n", errstr);
> > +fprintf(stderr, "%s\n", av_err2str(err));
> >  return 1;
> >  }
> > --
> > 2.45.2
>
> Patchset LGTM

Thanks, BTW thanks to your earlier patches that did the same, after
this there will no longer be any calls to av_strerror in the codebase
(aside from being called by av_err2str).

Best,
Tristan

>
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: add scale_d3d11 filter

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Dash Santosh
> Sathyanarayanan
> Sent: Donnerstag, 22. Mai 2025 19:58
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avfilter: add scale_d3d11 filter
> 
> On 22-05-2025 20:55, Timo Rothenpieler wrote:
> > On 22/05/2025 15:20, Dash Santosh Sathyanarayanan wrote:
> >> This commit introduces a new hardware-accelerated video filter,
> >> scale_d3d11,
> >> which performs scaling and format conversion using Direct3D 11. The
> >> filter enables
> >> efficient GPU-based scaling and pixel format conversion (p010 to
> >> nv12), reducing
> >> CPU overhead and latency in video pipelines.
> >> ---
> >>   Changelog |   1 +
> >>   libavcodec/decode.c   |   2 +-
> >>   libavcodec/dxva2.c    |   3 +
> >>   libavfilter/Makefile  |   1 +
> >>   libavfilter/allfilters.c  |   1 +
> >>   libavfilter/vf_scale_d3d11.c  | 480 ++
> >>   libavutil/hwcontext_d3d11va.c |  40 ++-
> >>   7 files changed, 514 insertions(+), 14 deletions(-)
> >>   create mode 100644 libavfilter/vf_scale_d3d11.c
> >>
> >> diff --git a/Changelog b/Changelog
> >> index 4217449438..68610a63d0 100644
> >> --- a/Changelog
> >> +++ b/Changelog
> >> @@ -18,6 +18,7 @@ version :
> >>   - APV encoding support through a libopenapv wrapper
> >>   - VVC decoder supports all content of SCC (Screen Content Coding):
> >>     IBC (Inter Block Copy), Palette Mode and ACT (Adaptive Color
> >> Transform
> >> +- vf_scale_d3d11 filter
> >
> > Bit of a nit, this could at last say "Added".
> Oops, sorry. My bad.
> >
> >>       version 7.1:
> >> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> >> index c2b2dd6e3b..a796ae7930 100644
> >> --- a/libavcodec/decode.c
> >> +++ b/libavcodec/decode.c
> >> @@ -1079,7 +1079,7 @@ int ff_decode_get_hw_frames_ctx(AVCodecContext
> >> *avctx,
> >>   if (frames_ctx->initial_pool_size) {
> >>   // We guarantee 4 base work surfaces. The function above
> >> guarantees 1
> >>   // (the absolute minimum), so add the missing count.
> >> -    frames_ctx->initial_pool_size += 3;
> >> +    frames_ctx->initial_pool_size += 33;
> >
> > This seems a bit extreme, and can potentially drastically increase
> > VRAM usage of anything using d3d11va.
> In full hardware pipeline, when all surfaces are in use, we hit pool
> exhaustion and 'static pool size exceeded' error occurs. Hence the
> change. The increase in memory footprint was about ~100mb with this change.

Hi, 

this is not the right place for this change as it affects all hw accelerations.
Also, it sets it unconditionally, even when no filter is in play.
Since there is no direct relation between the decoder and the filter,
it's hard for the decoder to "know" whether its output will be connected
to a filter. The current way to handle this is to specify the 
extra_hw_frames parameter on the command line in cases where more frames 
are needed. 

Note that there's a extra_hw_frames decoder parameter and a extra_hw_frames
filter parameter. Here's an example where it is used:
https://trac.ffmpeg.org/wiki/Hardware/AMF



> >>     ret = av_hwframe_ctx_init(avctx->hw_frames_ctx);
> >> diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
> >> index 22ecd5acaf..37dab6cd68 100644
> >> --- a/libavcodec/dxva2.c
> >> +++ b/libavcodec/dxva2.c
> >> @@ -647,6 +647,9 @@ int ff_dxva2_common_frame_params(AVCodecContext
> >> *avctx,
> >>   AVD3D11VAFramesContext *frames_hwctx = frames_ctx->hwctx;
> >>     frames_hwctx->BindFlags |= D3D11_BIND_DECODER;
> >> +    if (frames_ctx->sw_format == AV_PIX_FMT_NV12) {
> >> +    frames_hwctx->BindFlags |= D3D11_BIND_VIDEO_ENCODER;
> >> +    }
> >
> > This change also seems a bit random here. Using NV12 does not
> > automatically mean you'll encode with it.
> The encoder requires D3D11_BIND_VIDEO_ENCODER to be set in the input
> surface, when sending the D3D11 surface directly to MF encoder.
> Currently MF encoder supports only 8bit (NV12). Hence the change. If the
> input is 10bit (P010), scale_d3d11 can be configured to output 8bit NV12
> frames.

The filter should be designed universally rather than expecting to be connected
to something specific at its output. Whether or not the bind_encoder bindflag
should be set, needs to be determined during negotiation of the output 
connection.

In case you wonder, what else could come after this filter:

- another instance of this filter
- a hwmap filter to derive to a QSV context (followed by QSV filters or a QSV 
encoder)
- a hwmap filter to other contexts (maybe AMF)
- the Nvidia NVENC encoders are said to be able to take D3D11 frames as input 
directly
  (without hwmap), I've never tried that, but if it works, it might also work 
to 
  connect them to this filter (given that the D3D11 context is an Nvidia GPU)

I don't mean to say that you should get all this working - just illustrate 
the scope of pos

[FFmpeg-devel] [PATCH v2] lavc/h2645_parse: More descriptive NALU header error

[Frank Plowman]

Signed-off-by: Frank Plowman 
---
Changes since v1: Spotted just after sending this that there was ongoing
effort to remove av_strerror calls in favour of av_err2str, so made that
substitution here.
---
 libavcodec/h2645_parse.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 82816999e8..fa57911c08 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -22,6 +22,7 @@
 
 #include "config.h"
 
+#include "libavutil/error.h"
 #include "libavutil/intmath.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/mem.h"
@@ -588,8 +589,9 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 } else
 ret = h264_parse_nal_header(nal, logctx);
 if (ret < 0) {
-av_log(logctx, AV_LOG_WARNING, "Invalid NAL unit %d, skipping.\n",
-   nal->type);
+av_log(logctx, AV_LOG_WARNING,
+   "Failed to parse header of NALU (type %d): \"%s\". Skipping 
NALU.\n",
+   nal->type, av_err2str(ret));
 continue;
 }
 
-- 
2.47.0

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

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

Re: [FFmpeg-devel] [PATCH 1/2] rtpdec: add fmtp parsing of sprop-maxcapturerate for opus

[Tristan Matthews via ffmpeg-devel]

Hi,

On Monday, May 5th, 2025 at 4:07 PM, Marvin Scholz  wrote:

> From: Erik Linge eri...@axis.com
> 
> 
> Co-authored-by: Marvin Scholz epira...@gmail.com
> 
> Signed-off-by: Marvin Scholz epira...@gmail.com
> 
> ---
> libavformat/Makefile | 1 +
> libavformat/rtpdec.c | 8 +
> libavformat/rtpdec_formats.h | 1 +
> libavformat/rtpdec_opus.c | 62 
> 4 files changed, 65 insertions(+), 7 deletions(-)
> create mode 100644 libavformat/rtpdec_opus.c
> 
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 6c9992adab..ee68345858 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -62,6 +62,7 @@ OBJS-$(CONFIG_RTPDEC) += rdt.o \
> rtpdec_mpeg12.o \
> rtpdec_mpeg4.o \
> rtpdec_mpegts.o \
> + rtpdec_opus.o \
> rtpdec_qcelp.o \
> rtpdec_qdm2.o \
> rtpdec_qt.o \
> diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
> index a7d5a79a83..10e9502ae2 100644
> --- a/libavformat/rtpdec.c
> +++ b/libavformat/rtpdec.c
> @@ -61,12 +61,6 @@ static const RTPDynamicProtocolHandler 
> speex_dynamic_handler = {
> .codec_id = AV_CODEC_ID_SPEEX,
> };
> 
> -static const RTPDynamicProtocolHandler opus_dynamic_handler = {
> - .enc_name = "opus",
> - .codec_type = AVMEDIA_TYPE_AUDIO,
> - .codec_id = AV_CODEC_ID_OPUS,
> -};
> -
> static const RTPDynamicProtocolHandler t140_dynamic_handler = { /* RFC 4103 */
> .enc_name = "t140",
> .codec_type = AVMEDIA_TYPE_SUBTITLE,
> @@ -110,6 +104,7 @@ static const RTPDynamicProtocolHandler *const 
> rtp_dynamic_protocol_handler_list[
> &ff_mpegts_dynamic_handler,
> &ff_ms_rtp_asf_pfa_handler,
> &ff_ms_rtp_asf_pfv_handler,
> + &ff_opus_dynamic_handler,
> &ff_qcelp_dynamic_handler,
> &ff_qdm2_dynamic_handler,
> &ff_qt_rtp_aud_handler,
> @@ -125,7 +120,6 @@ static const RTPDynamicProtocolHandler const 
> rtp_dynamic_protocol_handler_list[
> &ff_vp9_dynamic_handler,
> &gsm_dynamic_handler,
> &l24_dynamic_handler,
> - &opus_dynamic_handler,
> &realmedia_mp3_dynamic_handler,
> &speex_dynamic_handler,
> &t140_dynamic_handler,
> diff --git a/libavformat/rtpdec_formats.h b/libavformat/rtpdec_formats.h
> index 72a8f16a90..1ff2a72d2a 100644
> --- a/libavformat/rtpdec_formats.h
> +++ b/libavformat/rtpdec_formats.h
> @@ -77,6 +77,7 @@ extern const RTPDynamicProtocolHandler 
> ff_mpeg4_generic_dynamic_handler;
> extern const RTPDynamicProtocolHandler ff_mpegts_dynamic_handler;
> extern const RTPDynamicProtocolHandler ff_ms_rtp_asf_pfa_handler;
> extern const RTPDynamicProtocolHandler ff_ms_rtp_asf_pfv_handler;
> +extern const RTPDynamicProtocolHandler ff_opus_dynamic_handler;
> extern const RTPDynamicProtocolHandler ff_qcelp_dynamic_handler;
> extern const RTPDynamicProtocolHandler ff_qdm2_dynamic_handler;
> extern const RTPDynamicProtocolHandler ff_qt_rtp_aud_handler;
> diff --git a/libavformat/rtpdec_opus.c b/libavformat/rtpdec_opus.c
> new file mode 100644
> index 00..60ff2244b6
> --- /dev/null
> +++ b/libavformat/rtpdec_opus.c
> @@ -0,0 +1,62 @@
> +/
> + * RTP OPUS Depacketizer, RFC 7587
> + * Copyright (c) 2022 Erik Linge
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "avformat.h"
> +#include "rtpdec_formats.h"
> +#include "libavutil/avstring.h"
> +
> +static int parse_fmtp(AVFormatContext *s,
> + AVStream *stream, PayloadContext *data,
> + const char *attr, const char *value)
> +{
> + if (!strcmp(attr, "sprop-maxcapturerate")) {
> + int rate = atoi(value);
> + if (rate < 8000 || rate > 48000) {
> 
> + av_log(s, AV_LOG_ERROR,
> + "fmtp field 'sprop-maxcapturerate' must be between 8000 to 48000 (provided 
> value: %s)",
> + value);
> + return AVERROR_INVALIDDATA;
> + }
> + stream->codecpar->sample_rate = rate;
> 
> + }
> + return 0;
> +}
> +
> +static int opus_parse_sdp_line(AVFormatContext *s, int st_index,
> + PayloadContext *data, const char *line)
> +{
> + const char *p;
> +
> + if (st_index < 0)
> + return 0;
> +
> + if (av_strstart(line, "fmtp:", &p)) {
> + return ff_parse_fmtp(s, s->streams[st_index], data, p, parse_fmtp);
> 
> + }
> + return 0;
> +}
> +
> +const RTPDynamicProtocolHandler ff_opus_dynamic_handler = {
> + .enc_name = "opus",
> + .codec_type = AVMEDIA_TYPE_AUDIO,
> + .codec_id = AV_CODEC_ID_OPUS,
> + .parse_sdp_a_line = opus_parse_sdp_line,

Re: [FFmpeg-devel] [FEATURE PROPOSAL] Extracting codec-level data to binary files

[Ronald S. Bultje]

Hi,

On Thu, May 22, 2025 at 8:33 AM Ramiro Polla  wrote:

> On Thu, May 22, 2025 at 1:59 PM Ronald S. Bultje 
> wrote:
> > On Wed, May 21, 2025 at 9:34 AM Timothée <
> > timothee.informati...@regaud-chapuy.fr> wrote:
> > > I am interested in expanding ffmpeg's capabilities to extract
> > > low-level data from video codecs. Specifically, I'd like to implement
> > > functionality that would allow exporting frame data, macroblock
> > > information, quantization tables, and similar codec-specific elements
> > > to binary files for further analysis.
> > >
> > > After searching through the documentation and existing features, I
> > > haven't found similar functionality, though I may have missed
> > > something. Has this been implemented before, or are there related
> > > features I should examine?
> >
> > Some older codecs implement minor variants for this, e.g. grep
> > for AV_FRAME_DATA_MOTION_VECTORS, which attaches a frame's motion vectors
> > to the picture data. I believe there's an example app and possibly a
> filter
> > to overlay MVs on top of the video frame based on this concept. You could
> > extend this to cover other (macro)block info. There used to be a variant
> of
> > this for quant-tables also but I can't find it, maybe it was removed.
>
> If I recall correctly, we wanted to move away from exporting more of
> this kind of codec-specific information as picture data.
>
> Timothée, this kind of feature depends a lot on the codec that you
> want to work with. It will also depend on which syntax elements you
> need from the codec. In FFmpeg, there is the CBS code which describes
> the bitstream for a few codecs, which might help you.


I believe CBS only describes headers, not block data?

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".

[FFmpeg-devel] Defamation

[softworkz .]

Defamation is a false statement of fact that harms a person's reputation.
It can be either libel (written) or slander (spoken). In essence, 
defamation is a civil wrong (a tort) that provides a remedy for individuals
who have suffered harm to their reputation due to false statements made
about them to a third party.


Key Elements of Defamation
==

- False Statement of Fact
  The statement must be untrue and presented as a fact. 

- Harm to Reputation
  The statement must cause actual damage to the person's reputation or
  cause them to suffer special damages.

- Publication
  The statement must be communicated to a third party (someone other
  than the person defamed).

- Fault
  The defendant must have been negligent or malicious in publishing
  the statement. 


-

You can argue with me, you can criticize me specifically, you can annoy
me, you can disagree with me, you can bore me, you can legitimately 
blame me, you can laugh about me, you can talk about me, you can offend
me, you can even insult me and a lot more. But nobody shall make untrue
statements about me and my work.

-

Today, I've moved the situation to a point where it has become so
clearly visible like never before on this mailing list.

There's a point where Opinion ends and Defamation begins.

Some people should take a moment and think about this.

softworkz

___
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] aacdec_ac: fix signed overflow in ff_aac_ac_update_context()

[Lynne]

The issue is that state->cur[] is 8-bits, but a+b+1 can overflow
before being clipped to 0xF in the following line, causing an incorrect
state to be saved for the next symbol.

This solves numerous bitstream desyncs, particularly when coefficients
with magnitude greater than 127 are sent.
---
 libavcodec/aac/aacdec_ac.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/libavcodec/aac/aacdec_ac.c b/libavcodec/aac/aacdec_ac.c
index 7e5077cd19..5104604fa5 100644
--- a/libavcodec/aac/aacdec_ac.c
+++ b/libavcodec/aac/aacdec_ac.c
@@ -91,10 +91,7 @@ uint32_t ff_aac_ac_get_pk(uint32_t c)
 void ff_aac_ac_update_context(AACArithState *state, int idx,
   uint16_t a, uint16_t b)
 {
-state->cur[0] = a + b + 1;
-if (state->cur[0] > 0xF)
-state->cur[0] = 0xF;
-
+state->cur[0] = FFMIN(a + b + 1, 0xF);
 state->cur[3] = state->cur[2];
 state->cur[2] = state->cur[1];
 state->cur[1] = state->cur[0];
-- 
2.49.0.395.g12beb8f557c
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avformat/movenc: Fix flush fragment

[Zhao Zhili]

From: Zhao Zhili 

The follow cmd output corrupted file before the patch:

ffmpeg -f lavfi -i color=blue,trim=duration=0.04 \
-f lavfi -i anullsrc,atrim=duration=2 \
-movflags +empty_moov+hybrid_fragmented \
-frag_duration 100 \
-frag_interleave 1 \
output.mp4

1. first_track is the first track with track->entry != 0. As in the
command above, video track (track index 0) has a single frame. When
flush the second fragment, first_track is 1, the audio track.

2. write_moof = i == first_track, so write_moof is false for i = 0.

3. When mov->frag_interleave != 0, mov->mdat_buf != NULL, because
it contains audio data. So avio_write is called before write_moof,
that is, the data write before moof, and mov_finish_fragment
executed with wrong mdat_start.

4. With normal fmp4 output, the error isn't obvious. With
hybrid_fragmented, ffplay output.mp4 shows a lot of error messages.
---
 libavformat/movenc.c | 4 ++--
 tests/fate/mov.mak   | 5 +
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 4bc8bd1b2a..844a371808 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6509,9 +6509,9 @@ static int mov_flush_fragment(AVFormatContext *s, int 
force)
 int buf_size, write_moof = 1, moof_tracks = -1;
 uint8_t *buf;
 
+if (!track->entry)
+continue;
 if (mov->flags & FF_MOV_FLAG_SEPARATE_MOOF) {
-if (!track->entry)
-continue;
 mdat_size = avio_tell(track->mdat_buf);
 moof_tracks = i;
 } else {
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index f7e5e52217..6ab61e9f00 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -84,6 +84,11 @@ fate-mov-ibi-elst-starts-b: CMD = framemd5 -flags +bitexact 
-i $(TARGET_SAMPLES)
 # Makes sure that we handle overlapping framgments
 fate-mov-frag-overlap: CMD = framemd5 -i $(TARGET_SAMPLES)/mov/frag_overlap.mp4
 
+fate-mov-mp4-frag-flush: CMD = md5 -f lavfi -i 
color=blue,format=rgb24,trim=duration=0.04 -f lavfi -i 
anullsrc,aformat=s16,atrim=duration=2 -c:v png -c:a pcm_s16le -movflags 
+empty_moov+hybrid_fragmented -frag_duration 100 -frag_interleave 1 -f mp4
+fate-mov-mp4-frag-flush: CMP = oneline
+fate-mov-mp4-frag-flush: REF = a10c0e2e2dfc120f31ca5e59e0e4392a
+FATE_MOV-$(call ALLYES, LAVFI_INDEV, COLOR_FILTER, FORMAT_FILTER, TRIM_FILTER, 
ANULL_FILTER, AFORMAT_FILTER, ATRIM_FILTER, PNG_ENCODER, PCM_S16LE_ENCODER, 
MOV_MUXER) += fate-mov-mp4-frag-flush
+
 # Makes sure that we pick the right frames according to edit list when there 
is no keyframe with PTS < edit list start.
 # For example, when video starts on a B-frame, and edit list starts on that 
B-frame too.
 # GOP structure : B B I in presentation order.
-- 
2.46.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] Graphprint Patches Overview

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of softworkz .
> Sent: Donnerstag, 22. Mai 2025 10:13
> To: FFmpeg development discussions and patches 
> Cc: Kieran Kunhya ; t...@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Kieran
> > Kunhya via ffmpeg-devel
> > Sent: Donnerstag, 22. Mai 2025 09:22
> > To: FFmpeg development discussions and patches 
> > Cc: Kieran Kunhya ; t...@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> >
> > It's obvious basic testing was not done on this patchset seeing the scale
> > of memory leaks.
> 
> 
> Which scale are you talking about? Did you test it? How much memory growth
> did you observe due to those leaks?
> 
> 
> Did you test and compare with the submitted fixes? Are you still seeing any
> leaks with those applied?
> 
> 
> Which functionality is affected exactly? Under which conditions did you
> observe those leaks.
> 
> 
> Did you identify any regressions in other FFmpeg functionality?
> 
> 
> Which specific parts of the implementation need more work?
> 
> 
> 
> > I would like the TC to decide on reverting and proper resubmission later.
> >
> > Kieran
> 
> Sure, I'm good with that.
> 
> But what you are requesting gives also testimony for that you don't even
> have the slightest clue about that patchset's contents, which somewhat
> disqualifies you for making such request. That's a bit funny, tbh.
> 
> ___

The reason why I'm saying that is because if somebody would have looked
a bit at the patchset and the history over those 15 revisions, then they
would have realized that 10 of the patches have been actively reviewed
(*) two are trivial (T) and for the remain 2 patches, I had no other
choice than to assume they have been seen.

That's why I think that it's kind of a joke when someone asks to 
revert the whole patchset. 


*  1:  Formatting and whitespace changes
*  2:  Apply quality improvements
*  3:  Remove unused print_rational() pointer from 
*  4:  Rename name param to key for API consistency
*  5:  Re-use BPrint in loop  
*  6:  Introduce AVTextFormatOptions for avtext_context_open()
*  7:  Introduce common header and deduplicate code
*  8:  Use av_default_item_name
*  9:  Add flags param to function avtext_print_integer()
* 10:  Move some declaration to new header file
T 11:  Add avfilter_link_get_hw_frames_ctx()
  12:  Add resource manager files with build-time compression
T 13:  Make ms_from_ost() inline
  14:  Add execution graph printing

All fixes were targeting 14 only (and the Makefile from 12).
Looking just a tiny bit at the subject would have made this
clear.

In turn, anybody asking to revert "the patchset" is implicitly
admitting that he doesn't have the slightest idea about what
he's talking.

sw

___
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 2/3] tests/source-check: Fix make inclusion-guard check EOL-agnostic

[Andreas Rheinhardt]

softworkz:
> From: softworkz 
> 
> ..to make it work when checked out with autocrlf=on,
> which is Git default on Windows.
> 
> Signed-off-by: softworkz 
> ---
>  tests/fate/source-check.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/fate/source-check.sh b/tests/fate/source-check.sh
> index 4d7e175784..99e869e869 100755
> --- a/tests/fate/source-check.sh
> +++ b/tests/fate/source-check.sh
> @@ -28,7 +28,7 @@ for f in `git ls-files | grep '\.h$'` ; do
>  -e 's/_vaf_/_/' \
>  | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
>  
> -git grep -L "^#define $macro$" $f
> +git grep -L "^#define $macro\>" $f

This makes the test less strict. Why don't we instead just specify that
the repo should be checked out with lf only? Would this break something?

>  done
>  
>  echo "Use of av_clip() where av_clip_uintp2() could be used:"

___
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] swscale: rgb_to_yuv neon optimizations

[Ramiro Polla]

On Thu, May 22, 2025 at 8:55 AM Dmitriy Kovalenko
 wrote:
> Bumping on the review for this one

Michael already replied:
https://ffmpeg.org/pipermail/ffmpeg-devel/2025-May/343826.html

The patch is corrupted and can't be applied.
___
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] Graphprint Patches Overview

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Kieran
> Kunhya via ffmpeg-devel
> Sent: Donnerstag, 22. Mai 2025 09:22
> To: FFmpeg development discussions and patches 
> Cc: Kieran Kunhya ; t...@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> 
> It's obvious basic testing was not done on this patchset seeing the scale
> of memory leaks.


Which scale are you talking about? Did you test it? How much memory growth
did you observe due to those leaks?


Did you test and compare with the submitted fixes? Are you still seeing any
leaks with those applied?


Which functionality is affected exactly? Under which conditions did you 
observe those leaks.


Did you identify any regressions in other FFmpeg functionality?


Which specific parts of the implementation need more work?



> I would like the TC to decide on reverting and proper resubmission later.
> 
> Kieran

Sure, I'm good with that.

But what you are requesting gives also testimony for that you don't even 
have the slightest clue about that patchset's contents, which somewhat 
disqualifies you for making such request. That's a bit funny, tbh.

Best regards
sw
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: fix VVC encoding with leading pictures

[Gabriel Hege]

On 17.05.25 04:26, Nuo Mi wrote:

On Fri, May 16, 2025 at 7:05 PM Gabriel Hege  wrote:


This is a resubmission with a corrected commit message.


The default behavior for VVenC (since v1.10.0) is to create an IDR with
leading pictures for the first picture in decoding order (POC 32). This
leads to FFmpeg generating an edit list with an empty entry, skipping
the leading pictures.

This patch fixes the calculation for the start_pts, while the DTS is
negative (as produced by libvvenc).


How to reproduce the issue (needs --enable-libvvenc and a recent
libvvenc, e.g. v1.13):


Hi Gabriel,
Thank you for your patch. It addresses the MP4 issue, but it looks like MKV
has the same problem as well.


Hi Nuo Mi,

I'm sorry I don't really have an understanding of the MKV format. I had 
a quick look at the code, but the processing seems quite different and I 
didn't really find the corresponding code locations to fix the problem 
there.




Hi @James Almer  ,
Could you please take a look at the patch when you have a moment? You've
been the most active contributor to this file recently.



Encode VVC directly into MP4 container:
./ffmpeg -i /data/YUV/foreman_352x288_30Hz_i420_8.y4m -an -preset faster
-vcodec vvc test.mp4

-> encodes 300 frames.

Decode to YUV (or play back using ffplay):
./ffmpeg -i test.mp4 test.yuv

-> outputs 271 frames

When dumping the mp4-structure using 'MP4Box -diso test.mp4', I see the
following EditListBox, which skips the first couple of
frames:





With the fix applied 300 frames are decoded as expected and the
EditListBox looks like this:



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

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


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

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


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

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

Re: [FFmpeg-devel] Graphprint Patches Overview

[Nicolas George]

Kieran Kunhya via ffmpeg-devel (HE12025-05-22):
> It's obvious basic testing was not done on this patchset seeing the scale
> of memory leaks.
> 
> I would like the TC to decide on reverting and proper resubmission later.

For once, I agree with that assessment. I think giving softworkz the
authority to decide if his own patches are ready for inclusion was
premature.

Regards,

-- 
  Nicolas George
___
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] Graphprint Patches Overview

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Nicolas
> George
> Sent: Donnerstag, 22. Mai 2025 10:50
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> 
> Kieran Kunhya via ffmpeg-devel (HE12025-05-22):
> > It's obvious basic testing was not done on this patchset seeing the scale
> > of memory leaks.
> >
> > I would like the TC to decide on reverting and proper resubmission later.
> 
> For once, I agree with that assessment. I think giving softworkz the
> authority to decide if his own patches are ready for inclusion was
> premature.
> 
> Regards,
> 
> --

I precisely followed the instructions I was given.

sw
___
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] Graphprint Patches Overview

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Nicolas
> George
> Sent: Donnerstag, 22. Mai 2025 10:50
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> 
> Kieran Kunhya via ffmpeg-devel (HE12025-05-22):
> > It's obvious basic testing was not done on this patchset seeing the scale
> > of memory leaks.
> >
> > I would like the TC to decide on reverting and proper resubmission later.
> 
> For once, I agree with that assessment. I think giving softworkz the
> authority to decide if his own patches are ready for inclusion was
> premature.
> 
> Regards,
> 
> --
>   Nicolas George


And why didn't you review it actually? You have definitely followed the
progress - more than anybody else and made a lot of comments.

That's why I also took it for granted that you've seen it.

sw





___
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] Graphprint Patches Overview

[Kieran Kunhya via ffmpeg-devel]

It's obvious basic testing was not done on this patchset seeing the scale
of memory leaks.

I would like the TC to decide on reverting and proper resubmission later.

Kieran

On Wed, 21 May 2025, 21:37 softworkz ., 
wrote:

>
>
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> softworkz .
> > Sent: Mittwoch, 21. Mai 2025 22:20
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of Kyle
> > Swanson
> > > Sent: Mittwoch, 21. Mai 2025 22:11
> > > To: FFmpeg development discussions and patches <
> ffmpeg-devel@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> > >
> > > Hi,
> > >
> > > On Wed, May 21, 2025 at 4:00 AM Kieran Kunhya via ffmpeg-devel
> > >  wrote:
> > > > Can we just revert the whole set until it's cleaned up properly?
> > > >
> > > > There are more patches to fix issues than the set itself. This is
> > > > understandable if it's a bit architectural change like threading but
> it's
> > > > not.
> > >
> > > I agree with Kieran, revert. This was not ready to be pushed IMO.
> > >
> > > Thanks,
> > > Kyle
> > > ___
> >
> > I think the least that can be expected from somebody making such a
> > request is that they provide specific reasoning after having taken
> > a closer look - which the two of you apparently haven't.
> >
> > Thanks
> > sw
> >
> > ___
>
> Here's a branch with the pending fixes included:
>
> https://github.com/softworkz/FFmpeg/tree/submit_graphprint_allfixes
>
> Please explain specifically what you want to have reverted and why.
>
> Thanks
> sw
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Graphprint Patches Overview

[Michael Niedermayer]

Hi Kieran

On Thu, May 22, 2025 at 08:21:48AM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> It's obvious basic testing was not done on this patchset seeing the scale
> of memory leaks.
> 
> I would like the TC to decide on reverting and proper resubmission later.

Iam not speaking for the TC here

1. The graphprint code was on the ML for a month and resumbitted for review
12 times, basically noone reviewed it (going back to that will not help it)
2. The graphprint code is very actively worked on (thats normal and good
and what git master is for and thats how it improves quickly)
3. The statement that the graphprint code wasnt tested is obviously false
softworkz tested it. I tested at least build on multiply platforms
4. "seeing the scale of memory leaks." try to compare this to
   IAMF "git log --grep IAMF --oneline", IAMF is after a year still receiving
   frequent security fixes. This is just as a comparission

What you are doing is trying to gain from somewhat popular oppinions
at the expense of the project and team.

many disliked the "opening of a browser" and thats now resolved
and reverted, but instead of letting the wounds heal you throw salt in them.
And while people are working and improving the code you push another
round of animosity

I dont really care if the code is all reverted or not. (it seems though
wiser to let people work on it as they already do)
What i do not agree with is this seeding of animosity you do.

This very much reminds me of
Simple Sabotage Field Manual
https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/SimpleSabotage.pdf

Also there is IMO nothing for the TC at this point. Its actively worked on code,
there is NO disagreement that any bugs or leaks need to be fixed.
And reverting this is not going to accelerate any fixes (if any bugs even 
remain).
Nor is it affecting anyone not using this new feature.
Your mails look like they are just for some sozial media buzz.

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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 v2 2/3] tests/source-check: Fix make inclusion-guard check EOL-agnostic

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Andreas
> Rheinhardt
> Sent: Donnerstag, 22. Mai 2025 12:42
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 2/3] tests/source-check: Fix make
> inclusion-guard check EOL-agnostic
> 
> softworkz:
> > From: softworkz 
> >
> > ..to make it work when checked out with autocrlf=on,
> > which is Git default on Windows.
> >
> > Signed-off-by: softworkz 
> > ---
> >  tests/fate/source-check.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tests/fate/source-check.sh b/tests/fate/source-check.sh
> > index 4d7e175784..99e869e869 100755
> > --- a/tests/fate/source-check.sh
> > +++ b/tests/fate/source-check.sh
> > @@ -28,7 +28,7 @@ for f in `git ls-files | grep '\.h$'` ; do
> >  -e 's/_vaf_/_/' \
> >  | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
> >
> > -git grep -L "^#define $macro$" $f
> > +git grep -L "^#define $macro\>" $f
> 
> This makes the test less strict. 

Yea, that's correct, but does that defeat the intention of the test?
It might allow whitespace at the end of the but this is something
that can happen for any line in any file, not just the guard definitions
in header files. Eventually this is guarded against by the hooks of
the Git repo when pushing. 
It might also allow more text after some whitespace, but that would 
file compilation, I think.

Do you know some regex Kung-Fu to ignore EOL and still use an end 
marker? I had found a way but that requires switching to Perl matching
(-E), but from what I've read, we cannot assume this to be available
on all platforms.


> Why don't we instead just specify that
> the repo should be checked out with lf only? Would this break something?

>From my experience it can cause a lot of trouble. The following 
discussions from last year may give you an idea of these pitfalls,
even though not everything might apply to FFmpeg:

https://github.com/ffmpeginteropx/FFmpegInteropX/pull/433
https://github.com/ffmpeginteropx/FFmpegInteropX/pull/431
https://github.com/ffmpeginteropx/FFmpegInteropX/pull/430

The risk is that it causes more trouble than the problems it might
solve.
What stands on the other side is that these two patches is all that
is needed to successfully run FATE tests on Windows.

When a new subtitle test is added, the entry in .gitattributes may
be forgotten, but with the new CI builds on Windows it would also
be discovered immediately.


Thanks a lot for looking at this,
sw





___
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 2/3] tests/source-check: Fix make inclusion-guard check EOL-agnostic

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of softworkz .
> Sent: Donnerstag, 22. Mai 2025 13:12
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH v2 2/3] tests/source-check: Fix make
> inclusion-guard check EOL-agnostic
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Andreas
> > Rheinhardt
> > Sent: Donnerstag, 22. Mai 2025 12:42
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2 2/3] tests/source-check: Fix make
> > inclusion-guard check EOL-agnostic
> >
> > softworkz:
> > > From: softworkz 
> > >
> > > ..to make it work when checked out with autocrlf=on,
> > > which is Git default on Windows.
> > >
> > > Signed-off-by: softworkz 
> > > ---
> > >  tests/fate/source-check.sh | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tests/fate/source-check.sh b/tests/fate/source-check.sh
> > > index 4d7e175784..99e869e869 100755
> > > --- a/tests/fate/source-check.sh
> > > +++ b/tests/fate/source-check.sh
> > > @@ -28,7 +28,7 @@ for f in `git ls-files | grep '\.h$'` ; do
> > >  -e 's/_vaf_/_/' \
> > >  | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`"
> > >
> > > -git grep -L "^#define $macro$" $f
> > > +git grep -L "^#define $macro\>" $f
> >
> > This makes the test less strict.
> 
> Yea, that's correct, but does that defeat the intention of the test?
> It might allow whitespace at the end of the but this is something
> that can happen for any line in any file, not just the guard definitions
> in header files. Eventually this is guarded against by the hooks of
> the Git repo when pushing.
> It might also allow more text after some whitespace, but that would
> file compilation, I think.
> 
> Do you know some regex Kung-Fu to ignore EOL and still use an end
> marker? I had found a way but that requires switching to Perl matching
> (-E), but from what I've read, we cannot assume this to be available
> on all platforms.
> 
> 
> > Why don't we instead just specify that
> > the repo should be checked out with lf only? Would this break something?
> 
> From my experience it can cause a lot of trouble. The following
> discussions from last year may give you an idea of these pitfalls,
> even though not everything might apply to FFmpeg:
> 
> https://github.com/ffmpeginteropx/FFmpegInteropX/pull/433
> https://github.com/ffmpeginteropx/FFmpegInteropX/pull/431
> https://github.com/ffmpeginteropx/FFmpegInteropX/pull/430
> 
> The risk is that it causes more trouble than the problems it might
> solve.
> What stands on the other side is that these two patches is all that
> is needed to successfully run FATE tests on Windows.
> 
> When a new subtitle test is added, the entry in .gitattributes may
> be forgotten, but with the new CI builds on Windows it would also
> be discovered immediately.
> ___

Oh, and I totally forgot this: There are other tests which are 
failing when declaring EOL=LF in .gitattributes - even a few
subtitle tests, that's why I haven't added all of them.

sw


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

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

Re: [FFmpeg-devel] [PATCH] avutil/refstruct: Remove redundant check

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Patch attached.
> 
> - Andreas
> 
Will apply.

- Andreas

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

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

Re: [FFmpeg-devel] [FEATURE PROPOSAL] Extracting codec-level data to binary files

[Ronald S. Bultje]

Hi,

On Wed, May 21, 2025 at 9:34 AM Timothée <
timothee.informati...@regaud-chapuy.fr> wrote:

> Hello,
>
> I am interested in expanding ffmpeg's capabilities to extract
> low-level data from video codecs. Specifically, I'd like to implement
> functionality that would allow exporting frame data, macroblock
> information, quantization tables, and similar codec-specific elements
> to binary files for further analysis.
>
> After searching through the documentation and existing features, I
> haven't found similar functionality, though I may have missed
> something. Has this been implemented before, or are there related
> features I should examine?


Some older codecs implement minor variants for this, e.g. grep
for AV_FRAME_DATA_MOTION_VECTORS, which attaches a frame's motion vectors
to the picture data. I believe there's an example app and possibly a filter
to overlay MVs on top of the video frame based on this concept. You could
extend this to cover other (macro)block info. There used to be a variant of
this for quant-tables also but I can't find it, maybe it was removed.

Placing the side-data in binary files is probably not really something that
libavcodec would do, but rather something that would exist at the
application level.

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] Graphprint Patches Overview

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Michael
> Niedermayer
> Sent: Donnerstag, 22. Mai 2025 13:24
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> 
> Hi Kieran
> 
> On Thu, May 22, 2025 at 08:21:48AM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> > It's obvious basic testing was not done on this patchset seeing the scale
> > of memory leaks.
> >
> > I would like the TC to decide on reverting and proper resubmission later.
> 
> Iam not speaking for the TC here
> 
> 1. The graphprint code was on the ML for a month and resumbitted for review
> 12 times, basically noone reviewed it (going back to that will not help
> it)
> 2. The graphprint code is very actively worked on (thats normal and good
> and what git master is for and thats how it improves quickly)
> 3. The statement that the graphprint code wasnt tested is obviously false
> softworkz tested it. I tested at least build on multiply platforms
> 4. "seeing the scale of memory leaks." try to compare this to
>IAMF "git log --grep IAMF --oneline", IAMF is after a year still receiving
>frequent security fixes. This is just as a comparission
> 
> What you are doing is trying to gain from somewhat popular oppinions
> at the expense of the project and team.
> 
> many disliked the "opening of a browser" and thats now resolved
> and reverted, but instead of letting the wounds heal you throw salt in them.
> And while people are working and improving the code you push another
> round of animosity
> 
> I dont really care if the code is all reverted or not. (it seems though
> wiser to let people work on it as they already do)
> What i do not agree with is this seeding of animosity you do.
> 
> This very much reminds me of
> Simple Sabotage Field Manual
> https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/SimpleSabotage.pdf
> 
> Also there is IMO nothing for the TC at this point. Its actively worked on
> code,
> there is NO disagreement that any bugs or leaks need to be fixed.
> And reverting this is not going to accelerate any fixes (if any bugs even
> remain).

Just one more note on the status: This is not a work in progress, it's done
and complete, otherwise I wouldn't have submitted.
I did not check for memory leaks - yes, I should have done that! Albeit
it's not library code, no large amounts, not constantly growing and most of 
it allocated only a few milliseconds before the FFmpeg process exits.

Given the attention that some are paying to those few Kilobytes, I have to
wonder why nobody seems to be aware of the existing memory leaks with 
QSV hardware acceleration. These _do_ appear to be growing over time.


> many disliked the "opening of a browser" and thats now resolved
> and reverted, but instead of letting the wounds heal you throw salt in them.

At that time, I haven't had a chance to say anything. I will follow-up
to it shortly, but I wanted everybody incl. myself to cool down before.

What I can tell though in advance: That narrative of "inexperienced 
developer accidentally used a 'bad' API" doesn't fly. It was a 
deliberate decision under awareness of the potential risks when
not done right.

I really wonder how Kieran can't be embarrassed trying such maneuvers which
are so obvious to everybody.

Best
sw


___
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] STF RaptorQ

[Devin Heitmueller]

On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
 wrote:
> I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> maintenance of FFmpeg.
>
> It's adding an obscure FEC protocol to FFmpeg, which is not going to be
> implemented well without an event loop anyway.
>
> I do not think it's a suitable STF project.

I see the task on the TRAC page for STF 2025, and while intellectually
interesting to a nerd like me who does lots of work with reliable
protocols, I'm not confident this particular protocol makes much sense
to work on, especially for 24,000 EUR.

I'm not sure I've seen any commercial gear that does RaptorQ for FEC,
so it's not clear what the use cases are if the goal is
interoperability.  If somebody really wants to be paid to work on
reliable transport protocols, the time would be better spent improving
the RIST or SRT integration, which is where most of the industry is
putting their energy.

I agree with Kieran that this seems to largely be outside the STF
objectives (i.e. sustainability for open source projects).

Devin

(1) https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2025

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 2/2] avformat/rtpdec_jpeg: Set width and heigh codec parameters

[Marvin Scholz]

From: Erik Linge 

---
 libavformat/rtpdec_jpeg.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/rtpdec_jpeg.c b/libavformat/rtpdec_jpeg.c
index 81036247c1..4d9ee0d754 100644
--- a/libavformat/rtpdec_jpeg.c
+++ b/libavformat/rtpdec_jpeg.c
@@ -233,6 +233,8 @@ static int jpeg_parse_packet(AVFormatContext *ctx, 
PayloadContext *jpeg,
 q  = AV_RB8(buf + 5);   /* quantization factor (or table id) */
 width  = AV_RB8(buf + 6);   /* frame width in 8 pixel blocks */
 height = AV_RB8(buf + 7);   /* frame height in 8 pixel blocks */
+st->codecpar->width = width*8;
+st->codecpar->height = height*8;
 buf += 8;
 len -= 8;
 
-- 
2.39.5 (Apple Git-154)

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

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

[FFmpeg-devel] [PATCH 1/2] avformat/rtsp: parse framerate in sdp

[Marvin Scholz]

From: Erik Linge 

Co-authored-by: Marvin Scholz 
---
 libavformat/rtsp.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 5ea471b40c..6807e1d6b5 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -618,6 +618,13 @@ static void sdp_parse_line(AVFormatContext *s, 
SDPParseState *s1,
 s1->seen_fmtp = 1;
 av_strlcpy(s1->delayed_fmtp, buf, sizeof(s1->delayed_fmtp));
 }
+} else if (av_strstart(p, "framerate:", &p) && s->nb_streams > 0) {
+// RFC 8866
+double framerate;
+if (av_sscanf(p, "%lf%c", &framerate, &(char){}) == 1) {
+st = s->streams[s->nb_streams - 1];
+st->avg_frame_rate = av_d2q(framerate, INT_MAX);
+}
 } else if (av_strstart(p, "ssrc:", &p) && s->nb_streams > 0) {
 rtsp_st = rt->rtsp_streams[rt->nb_rtsp_streams - 1];
 get_word(buf1, sizeof(buf1), &p);
-- 
2.39.5 (Apple Git-154)

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

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

[FFmpeg-devel] [PATCH] avformat/sdp: add framerate entry

[Marvin Scholz]

---
 libavformat/sdp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 215e38f8fc..21ada5d1ce 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -867,6 +867,9 @@ int ff_sdp_write_media(char *buff, int size, const AVStream 
*st, int idx,
 if (p->bit_rate) {
 av_strlcatf(buff, size, "b=AS:%"PRId64"\r\n", p->bit_rate / 1000);
 }
+if (p->framerate.num > 0 && p->framerate.den > 0) {
+av_strlcatf(buff, size, "a=framerate:%g\r\n", av_q2d(p->framerate));
+}
 
 return sdp_write_media_attributes(buff, size, st, payload_type, fmt);
 }
-- 
2.39.5 (Apple Git-154)

___
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] Funding Proposals

[Leo Izen]

I'm actually quite out of the loop on how to request funding. I've been
meaning to do it since I'm putting a lot of hours into my EXIF work, and
still got a bunch more. A lot of code is written but much of it is not
tested, and that's important.

Can someone explain the process, in a nutshell, along with reasonable
numbers for requests?

- Leo Izen (Traneptora)
___
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] [FEATURE PROPOSAL] Extracting codec-level data to binary files

[Michael Niedermayer]

Hi Ronald

On Thu, May 22, 2025 at 07:59:06AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, May 21, 2025 at 9:34 AM Timothée <
> timothee.informati...@regaud-chapuy.fr> wrote:
> 
> > Hello,
> >
> > I am interested in expanding ffmpeg's capabilities to extract
> > low-level data from video codecs. Specifically, I'd like to implement
> > functionality that would allow exporting frame data, macroblock
> > information, quantization tables, and similar codec-specific elements
> > to binary files for further analysis.
> >
> > After searching through the documentation and existing features, I
> > haven't found similar functionality, though I may have missed
> > something. Has this been implemented before, or are there related
> > features I should examine?
> 
> 
> Some older codecs implement minor variants for this, e.g. grep
> for AV_FRAME_DATA_MOTION_VECTORS, which attaches a frame's motion vectors
> to the picture data. I believe there's an example app and possibly a filter
> to overlay MVs on top of the video frame based on this concept. You could
> extend this to cover other (macro)block info. There used to be a variant of
> this for quant-tables also but I can't find it, maybe it was removed.

For motion vectors:
./ffplay -flags2 +export_mvs -i matrixbench_mpeg2.mpg  -vf codecview=mv=pf+bf+bb

For macroblock segmentation and type vissualization + also motion vectors:
ffplay-3.4.13 -debug vis_mb_type matrixbench_mpeg2.mpg  -vf 
codecview=mv=pf+bf+bb

For QP vissualization + also motion vectors:
ffplay-3.4.13 -debug vis_qp matrixbench_mpeg2.mpg  -vf codecview=mv=pf+bf+bb

For qp values dumped on the console
./ffplay  -debug qp  -i matrixbench_mpeg2.mpg

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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] [FEATURE PROPOSAL] Extracting codec-level data to binary files

[Michael Niedermayer]

On Fri, May 23, 2025 at 02:45:59AM +0200, Michael Niedermayer wrote:
> Hi Ronald
> 
> On Thu, May 22, 2025 at 07:59:06AM -0400, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Wed, May 21, 2025 at 9:34 AM Timothée <
> > timothee.informati...@regaud-chapuy.fr> wrote:
> > 
> > > Hello,
> > >
> > > I am interested in expanding ffmpeg's capabilities to extract
> > > low-level data from video codecs. Specifically, I'd like to implement
> > > functionality that would allow exporting frame data, macroblock
> > > information, quantization tables, and similar codec-specific elements
> > > to binary files for further analysis.
> > >
> > > After searching through the documentation and existing features, I
> > > haven't found similar functionality, though I may have missed
> > > something. Has this been implemented before, or are there related
> > > features I should examine?
> > 
> > 
> > Some older codecs implement minor variants for this, e.g. grep
> > for AV_FRAME_DATA_MOTION_VECTORS, which attaches a frame's motion vectors
> > to the picture data. I believe there's an example app and possibly a filter
> > to overlay MVs on top of the video frame based on this concept. You could
> > extend this to cover other (macro)block info. There used to be a variant of
> > this for quant-tables also but I can't find it, maybe it was removed.
> 
> For motion vectors:
> ./ffplay -flags2 +export_mvs -i matrixbench_mpeg2.mpg  -vf 
> codecview=mv=pf+bf+bb
> 
> For macroblock segmentation and type vissualization + also motion vectors:
> ffplay-3.4.13 -debug vis_mb_type matrixbench_mpeg2.mpg  -vf 
> codecview=mv=pf+bf+bb
> 
> For QP vissualization + also motion vectors:
> ffplay-3.4.13 -debug vis_qp matrixbench_mpeg2.mpg  -vf codecview=mv=pf+bf+bb
> 
> For qp values dumped on the console
> ./ffplay  -debug qp  -i matrixbench_mpeg2.mpg

And this can easily be extended to other codecs, ATM it should work with
all 16x16 MB based codecs like msmpeg4*/wmv*/mpeg1/2/4/h263/h264

mbtype and qp vissualization need codecview to be extended or versions around 
3.4
which implemented it differently

Implementing vissualization as done currently with sidedata and codecview
is simple and efficient. It also would allow exporting the data to json
by writing a codec2json filter in place of codecview

Also all decoders already have all this data parsed and available so
its simpler than trying to do it in a decoder independant way

I would thus suggest implementations of this for modern codecs to
follow the same path as the existing code.

thx

[...]

-- 
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".

[FFmpeg-devel] [PATCH 1/3] avcodec/cbs: add a new init function

[James Almer]

And rename the existing one to ff_cbs_alloc().
This will allow for more versatility when setting options in a module, allowing
them to be taken into account when calling module specific init functions.

Signed-off-by: James Almer 
---
 libavcodec/apv_decode.c  |  6 +-
 libavcodec/apv_parser.c  |  6 +-
 libavcodec/av1_parser.c  |  6 +-
 libavcodec/av1dec.c  | 14 +++---
 libavcodec/bsf/av1_frame_merge.c | 16 ++--
 libavcodec/bsf/av1_frame_split.c |  6 +-
 libavcodec/bsf/dts2pts.c |  6 +-
 libavcodec/bsf/filter_units.c|  6 +-
 libavcodec/bsf/trace_headers.c   |  2 +-
 libavcodec/cbs.c | 28 +++-
 libavcodec/cbs.h | 10 --
 libavcodec/cbs_bsf.c | 12 ++--
 libavcodec/cbs_internal.h|  3 +++
 libavcodec/d3d12va_encode_hevc.c |  6 +-
 libavcodec/vaapi_encode_av1.c|  6 +-
 libavcodec/vaapi_encode_h264.c   |  6 +-
 libavcodec/vaapi_encode_h265.c   |  6 +-
 libavcodec/vaapi_encode_mjpeg.c  |  6 +-
 libavcodec/vaapi_encode_mpeg2.c  |  6 +-
 libavcodec/vulkan_encode_h264.c  | 12 ++--
 libavcodec/vulkan_encode_h265.c  | 12 ++--
 libavcodec/vvc/dec.c |  6 +-
 libavcodec/vvc_parser.c  |  5 -
 libavformat/movenccenc.c |  6 +-
 24 files changed, 168 insertions(+), 30 deletions(-)

diff --git a/libavcodec/apv_decode.c b/libavcodec/apv_decode.c
index eb47298e2e..3667933df6 100644
--- a/libavcodec/apv_decode.c
+++ b/libavcodec/apv_decode.c
@@ -119,7 +119,11 @@ static av_cold int apv_decode_init(AVCodecContext *avctx)
 
 ff_thread_once(&apv_entropy_once, apv_entropy_build_decode_lut);
 
-err = ff_cbs_init(&apv->cbc, AV_CODEC_ID_APV, avctx);
+err = ff_cbs_alloc(&apv->cbc, AV_CODEC_ID_APV, avctx);
+if (err < 0)
+return err;
+
+err = ff_cbs_init(apv->cbc, NULL);
 if (err < 0)
 return err;
 
diff --git a/libavcodec/apv_parser.c b/libavcodec/apv_parser.c
index fdd575339b..e0aa152ca8 100644
--- a/libavcodec/apv_parser.c
+++ b/libavcodec/apv_parser.c
@@ -122,7 +122,11 @@ static av_cold int init(AVCodecParserContext *s)
 APVParseContext *p = s->priv_data;
 int ret;
 
-ret = ff_cbs_init(&p->cbc, AV_CODEC_ID_APV, NULL);
+ret = ff_cbs_alloc(&p->cbc, AV_CODEC_ID_APV, NULL);
+if (ret < 0)
+return ret;
+
+ret = ff_cbs_init(p->cbc, NULL);
 if (ret < 0)
 return ret;
 
diff --git a/libavcodec/av1_parser.c b/libavcodec/av1_parser.c
index 1792e813f4..77906d0c91 100644
--- a/libavcodec/av1_parser.c
+++ b/libavcodec/av1_parser.c
@@ -190,13 +190,17 @@ static av_cold int av1_parser_init(AVCodecParserContext 
*ctx)
 AV1ParseContext *s = ctx->priv_data;
 int ret;
 
-ret = ff_cbs_init(&s->cbc, AV_CODEC_ID_AV1, NULL);
+ret = ff_cbs_alloc(&s->cbc, AV_CODEC_ID_AV1, NULL);
 if (ret < 0)
 return ret;
 
 s->cbc->decompose_unit_types= decompose_unit_types;
 s->cbc->nb_decompose_unit_types = FF_ARRAY_ELEMS(decompose_unit_types);
 
+ret = ff_cbs_init(s->cbc, NULL);
+if (ret < 0)
+return ret;
+
 return 0;
 }
 
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 8ff1bf394c..3130364534 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -858,6 +858,7 @@ static av_cold int av1_decode_init(AVCodecContext *avctx)
 {
 AV1DecContext *s = avctx->priv_data;
 AV1RawSequenceHeader *seq;
+AVDictionary *options = NULL;
 const AVPacketSideData *sd;
 int ret;
 
@@ -865,20 +866,27 @@ static av_cold int av1_decode_init(AVCodecContext *avctx)
 s->pkt = avctx->internal->in_pkt;
 s->pix_fmt = AV_PIX_FMT_NONE;
 
-ret = ff_cbs_init(&s->cbc, AV_CODEC_ID_AV1, avctx);
+ret = ff_cbs_alloc(&s->cbc, AV_CODEC_ID_AV1, avctx);
 if (ret < 0)
 return ret;
 
 s->cbc->decompose_unit_types= decompose_unit_types;
 s->cbc->nb_decompose_unit_types = FF_ARRAY_ELEMS(decompose_unit_types);
 
+ret = av_dict_set_int(&options, "operating_point", s->operating_point, 0);
+if (ret < 0)
+return ret;
+
+ret = ff_cbs_init(s->cbc, &options);
+av_dict_free(&options);
+if (ret < 0)
+return ret;
+
 s->itut_t35_fifo = av_fifo_alloc2(1, sizeof(AV1RawMetadataITUTT35),
   AV_FIFO_FLAG_AUTO_GROW);
 if (!s->itut_t35_fifo)
 return AVERROR(ENOMEM);
 
-av_opt_set_int(s->cbc->priv_data, "operating_point", s->operating_point, 
0);
-
 if (avctx->extradata && avctx->extradata_size) {
 ret = ff_cbs_read_extradata_from_codec(s->cbc,
&s->current_obu,
diff --git a/libavcodec/bsf/av1_frame_merge.c b/libavcodec/bsf/av1_frame_merge.c
index 4c54f2167e..530688be49 100644
--- a/libavcodec/bsf/av1_frame_merge.c
+++ b/libavcodec/bsf/av1_frame_merge.c
@@ -133,11 +133,23 @@ static int av1_frame_merge_init(AVBSFCont

[FFmpeg-devel] [PATCH 2/3] avcodec/cbs_av1: don't store a reference to the unit data if it's not needed

[James Almer]

If a module using CBS-AV1 doesn't bother to decompose redundant frame header
OBUs, then there's no need to keep a reference to the previous frame header
around.

Signed-off-by: James Almer 
---
 libavcodec/cbs_av1.c | 23 +++
 libavcodec/cbs_av1.h |  3 +++
 libavcodec/cbs_av1_syntax_template.c |  2 ++
 3 files changed, 28 insertions(+)

diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index 4edb6ecd50..1938c5acff 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -1104,6 +1104,7 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
 {
 err = cbs_av1_write_frame_header_obu(ctx, pbc,
  &obu->obu.frame_header,
+ priv->redundant &&
  obu->header.obu_type ==
  
AV1_OBU_REDUNDANT_FRAME_HEADER,
  NULL);
@@ -1265,6 +1266,27 @@ static int 
cbs_av1_assemble_fragment(CodedBitstreamContext *ctx,
 #endif
 }
 
+static int cbs_av1_init(CodedBitstreamContext *ctx)
+{
+CodedBitstreamAV1Context *priv = ctx->priv_data;
+
+if (ctx->decompose_unit_types) {
+for (int i = 0; i < ctx->nb_decompose_unit_types; i++) {
+switch (ctx->decompose_unit_types[i]) {
+case AV1_OBU_REDUNDANT_FRAME_HEADER:
+priv->redundant = 1;
+break;
+default:
+break;
+}
+}
+} else {
+priv->redundant = 1;
+}
+
+return 0;
+}
+
 static void cbs_av1_flush(CodedBitstreamContext *ctx)
 {
 CodedBitstreamAV1Context *priv = ctx->priv_data;
@@ -1385,6 +1407,7 @@ const CodedBitstreamType CBS_FUNC(type_av1) = {
 .write_unit= &cbs_av1_write_obu,
 .assemble_fragment = &cbs_av1_assemble_fragment,
 
+.init  = &cbs_av1_init,
 .flush = &cbs_av1_flush,
 .close = &cbs_av1_close,
 };
diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
index 874f64561f..e79e90c6eb 100644
--- a/libavcodec/cbs_av1.h
+++ b/libavcodec/cbs_av1.h
@@ -490,6 +490,9 @@ typedef struct CodedBitstreamAV1Context {
 
 AV1ReferenceFrameState ref[AV1_NUM_REF_FRAMES];
 
+// Init values
+int redundant;
+
 // AVOptions
 int operating_point;
 // When writing, fix the length in bytes of the obu_size field.
diff --git a/libavcodec/cbs_av1_syntax_template.c 
b/libavcodec/cbs_av1_syntax_template.c
index 5518544a4d..701f474ce4 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -1795,6 +1795,7 @@ static int FUNC(frame_header_obu)(CodedBitstreamContext 
*ctx, RWContext *rw,
 #endif
 fh_bytes = (fh_bits + 7) / 8;
 
+if (priv->redundant) {
 priv->frame_header_size = fh_bits;
 
 if (rw_buffer_ref) {
@@ -1810,6 +1811,7 @@ static int FUNC(frame_header_obu)(CodedBitstreamContext 
*ctx, RWContext *rw,
 priv->frame_header = priv->frame_header_ref->data;
 memcpy(priv->frame_header, fh_start, fh_bytes);
 }
+}
 }
 }
 
-- 
2.49.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/3] avcodec/av1_parser: use an AVBufferRef to avoid data copying

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/av1_parser.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libavcodec/av1_parser.c b/libavcodec/av1_parser.c
index 77906d0c91..b9a96ad59a 100644
--- a/libavcodec/av1_parser.c
+++ b/libavcodec/av1_parser.c
@@ -50,6 +50,11 @@ static const enum AVPixelFormat pix_fmts_rgb[3] = {
 AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12,
 };
 
+static void dummy_free(void *opaque, uint8_t *data)
+{
+av_assert0(opaque == data);
+}
+
 static int av1_parser_parse(AVCodecParserContext *ctx,
 AVCodecContext *avctx,
 const uint8_t **out_data, int *out_size,
@@ -60,6 +65,7 @@ static int av1_parser_parse(AVCodecParserContext *ctx,
 const CodedBitstreamAV1Context *av1 = s->cbc->priv_data;
 const AV1RawSequenceHeader *seq;
 const AV1RawColorConfig *color;
+AVBufferRef *ref = NULL;
 int ret;
 
 *out_data = data;
@@ -69,6 +75,11 @@ static int av1_parser_parse(AVCodecParserContext *ctx,
 ctx->pict_type = AV_PICTURE_TYPE_NONE;
 ctx->picture_structure = AV_PICTURE_STRUCTURE_UNKNOWN;
 
+ref = av_buffer_create((uint8_t *)data, size, dummy_free,
+   (void *)data, AV_BUFFER_FLAG_READONLY);
+if (!ref)
+return size;
+
 s->cbc->log_ctx = avctx;
 
 if (avctx->extradata_size && !s->parsed_extradata) {
@@ -171,6 +182,8 @@ static int av1_parser_parse(AVCodecParserContext *ctx,
 
 end:
 ff_cbs_fragment_reset(td);
+av_assert1(av_buffer_get_ref_count(ref) == 1);
+av_buffer_unref(&ref);
 
 s->cbc->log_ctx = NULL;
 
-- 
2.49.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] Makefile: Split ALLFFLIBS

[Michael Niedermayer]

This matches other lists and reduces conflicts between patches

Signed-off-by: Michael Niedermayer 
---
 Makefile | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 2759e40b773..877b0071f6c 100644
--- a/Makefile
+++ b/Makefile
@@ -19,7 +19,14 @@ vpath %/fate_config.sh.template $(SRC_PATH)
 TESTTOOLS   = audiogen videogen rotozoom tiny_psnr tiny_ssim base64 audiomatch
 HOSTPROGS  := $(TESTTOOLS:%=tests/%) doc/print_options
 
-ALLFFLIBS = avcodec avdevice avfilter avformat avutil swscale swresample
+ALLFFLIBS =\
+avcodec\
+avdevice   \
+avfilter   \
+avformat   \
+avutil \
+swscale\
+swresample \
 
 # $(FFLIBS-yes) needs to be in linking order
 FFLIBS-$(CONFIG_AVDEVICE)   += avdevice
-- 
2.49.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] STF RaptorQ

[Lynne]

On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote:

Hello,

I wanted to put on the record that adding RaptorQ to FFmpeg isn't
maintenance of FFmpeg.


It isn't -- it's research.

It's adding an obscure FEC protocol to FFmpeg, which is not going to be
implemented well without an event loop anyway.


You're mixing up FEC implementation details that don't matter for a library.
It works much like a decoder - you put N blocks of Y bytes data in, and 
you get X blocks of Z byes out.

I do not think it's a suitable STF project.
STF is not maintenance-only from what I understand, but also for 
innovation, in this case, research.


I have no strong opinions on including this into STF. It's just work I'm 
interested in doing, which is currently obscure, but that's because it's 
still young and recently standardized. It will likely be used in future 
multimedia work, or so I'd like to think.


I'd like to ask for you to judge this without prejudice, however. When 
we spoke on IRC, you had (and still have, in the case of the event loop 
point), inaccurate understanding of the algorithm, and resorted to 
asking very technical questions about a recent algorithm to AI chatbots.


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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] [RFC] Error handing with CBS

[Zhao Zhili]

I have created a ticket on trac and uploaded a sample.

https://trac.ffmpeg.org/ticket/11603

The issue is CBS can detect invalid data in the bitstream, and report error.
How to handle these error is a problem.

With a single error in SEI, it can break the decoding/transcoding process.

ffmpeg -bsf:v h264_metadata -i input.mp4 -f null -

[h264_metadata @ 0x6392c0f0] Invalid SEI user data unregistered payload.
[h264_metadata @ 0x6392c0f0] Failed to read unit 0 (type 6).
[h264_metadata @ 0x6392c0f0] Failed to read access unit from packet.
[vist#0:0/h264 @ 0x14c704ba0] Error applying bitstream filters to a packet: 
Invalid data found when processing input
[in#0/mov,mp4,m4a,3gp,3g2,mj2 @ 0x14c6062c0] Task finished with error code: 
-1094995529 (Invalid data found when processing input)
[in#0/mov,mp4,m4a,3gp,3g2,mj2 @ 0x14c6062c0] Terminating thread with return 
code -1094995529 (Invalid data found when processing input)

Part of the problem is ffmpeg_demux.c doesn’t respect exit_on_error with
bsf error.

Another problem is CBS drops whole packet with a single error in SEI, and
the user of CBS doesn’t have the context where the error happened.

I don’t know how to fine-tuning the error handing and without breaking the
layered design.
___
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] STF RaptorQ

[Lynne]

On 23/05/2025 08:55, Devin Heitmueller wrote:

On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
 wrote:

I wanted to put on the record that adding RaptorQ to FFmpeg isn't
maintenance of FFmpeg.

It's adding an obscure FEC protocol to FFmpeg, which is not going to be
implemented well without an event loop anyway.

I do not think it's a suitable STF project.


I see the task on the TRAC page for STF 2025, and while intellectually
interesting to a nerd like me who does lots of work with reliable
protocols, I'm not confident this particular protocol makes much sense
to work on, especially for 24,000 EUR.


It's not a protocol.


I'm not sure I've seen any commercial gear that does RaptorQ for FEC,
so it's not clear what the use cases are if the goal is
interoperability.  If somebody really wants to be paid to work on
reliable transport protocols, the time would be better spent improving
the RIST or SRT integration, which is where most of the industry is
putting their energy.


Again, it's not a protocol. It's an FEC algorithm. No current mainstream 
protocol specifies using it. It will take decades, at least, and it 
definitely cannot fit into existing protocols.


Custom closed-source video transmission protocols are using it.
But, I do believe it's the future for open-source protocols too.

I agree with Kieran that this seems to largely be outside the STF
objectives (i.e. sustainability for open source projects).Like I mentioned, I 
believe the STF is not maintenance-only, or so I gather.


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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] avformat/movenc: Reduce loop iterations in mov_flush_fragment

[Zhao Zhili]

From: Zhao Zhili 

---
 libavformat/movenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 844a371808..5a9e34993f 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6504,7 +6504,7 @@ static int mov_flush_fragment(AVFormatContext *s, int 
force)
   av_rescale(mov->tracks[first_track].cluster[0].dts, 
AV_TIME_BASE, mov->tracks[first_track].timescale),
   (has_video ? starts_with_key : 
mov->tracks[first_track].cluster[0].flags & MOV_SYNC_SAMPLE) ? 
AVIO_DATA_MARKER_SYNC_POINT : AVIO_DATA_MARKER_BOUNDARY_POINT);
 
-for (i = 0; i < mov->nb_tracks; i++) {
+for (i = first_track; i < mov->nb_tracks; i++) {
 MOVTrack *track = &mov->tracks[i];
 int buf_size, write_moof = 1, moof_tracks = -1;
 uint8_t *buf;
-- 
2.46.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] avformat/matroskadec: Accept WebVTT subtitles with empty cues

[Michael Niedermayer]

On Tue, May 20, 2025 at 11:26:21AM +0200, Marcos Del Sol Vives via ffmpeg-devel 
wrote:
> Fixes: #11493
> ---
>  libavformat/matroskadec.c | 3 ---
>  1 file changed, 3 deletions(-)

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/imfdec: inherit opaque from parent AVFormatContext

[Michael Niedermayer]

Hi Pierre

On Fri, May 16, 2025 at 09:15:58PM -0700, Pierre-Anthony Lemieux wrote:
> On Fri, May 16, 2025 at 8:51 PM Kacper Michajłow  wrote:
> >
> > io_open and io_close2 callbacks may use opaque pointer stored in the
> > context. They are already inherited, so opaque should also be passed
> > through.
> >
> > Fixes IMF playback in mpv.
> >
> > Signed-off-by: Kacper Michajłow 
> > ---
> >  libavformat/imfdec.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> > index a86b4763ff..b4df37daa3 100644
> > --- a/libavformat/imfdec.c
> > +++ b/libavformat/imfdec.c
> > @@ -380,6 +380,7 @@ static int open_track_resource_context(AVFormatContext 
> > *s,
> >
> >  track_resource->ctx->io_open = s->io_open;
> >  track_resource->ctx->io_close2 = s->io_close2;
> > +track_resource->ctx->opaque = s->opaque;
> 
> LGTM.

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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 v3] avformat/dhav: fix backward scanning for get_duration and optimize seeking

[Michael Niedermayer]

Hi

On Wed, May 21, 2025 at 02:23:00PM +0100, Derek Buitenhuis wrote:
> From: Justin Ruggles 
> 
> The backwards scanning done for incomplete final packets should not
> assume a specific alignment at the end of the file. Truncated files
> result in hundreds of thousands of seeks if the final packet does not
> fall on a specific byte boundary, which can be extremely slow.
> For example, with HTTP, each backwards seek results in a separate
> HTTP request.
> 
> This changes the scanning to check for the end tag 1 byte at a time
> and buffers the last 1 MiB using ffio_ensure_seekback to avoid additional
> seek operations.
> 
> Co-authored-by: Derek Buitenhuis 
> Signed-off-by: Justin Ruggles 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavformat/dhav.c | 54 +-
>  1 file changed, 39 insertions(+), 15 deletions(-)
> 
> diff --git a/libavformat/dhav.c b/libavformat/dhav.c
> index b2ead99609..d9db775802 100644
> --- a/libavformat/dhav.c
> +++ b/libavformat/dhav.c
> @@ -22,6 +22,7 @@
>  
>  #include 
>  
> +#include "libavutil/intreadwrite.h"
>  #include "libavutil/mem.h"
>  #include "libavutil/parseutils.h"
>  #include "avio_internal.h"
> @@ -232,37 +233,60 @@ static void get_timeinfo(unsigned date, struct tm 
> *timeinfo)
>  timeinfo->tm_sec  = sec;
>  }
>  
> +#define MAX_DURATION_BUFFER_SIZE (1024*1024)
> +
>  static int64_t get_duration(AVFormatContext *s)
>  {
>  int64_t start_pos = avio_tell(s->pb);
> +int64_t end_pos = -1;
>  int64_t start = 0, end = 0;
>  struct tm timeinfo;
> -int max_interations = 10;
> +uint8_t *end_buffer;
> +int64_t end_buffer_size;
> +int64_t end_buffer_pos;
> +int64_t offset;
> +unsigned date;
>  
>  if (!s->pb->seekable)
>  return 0;
>  
> +if (start_pos + 16 > avio_size(s->pb))
> +return 0;
>  
> +avio_skip(s->pb, 16);
> +date = avio_rl32(s->pb);
> +get_timeinfo(date, &timeinfo);
> +start = av_timegm(&timeinfo) * 1000LL;
> +
> +end_buffer_size = FFMIN(MAX_DURATION_BUFFER_SIZE, avio_size(s->pb));
> +end_buffer = av_malloc(end_buffer_size);
> +if (!end_buffer) {
> +avio_seek(s->pb, start_pos, SEEK_SET);
> +return 0;
> +}
> +end_buffer_pos = avio_size(s->pb) - end_buffer_size;

calling avio_size() multiple times and assuming its always teh same value
feels risky to me

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".

[FFmpeg-devel] [PATCH 1/3] avcodec/asvenc: Don't waste bits encoding non-visible part

[Andreas Rheinhardt]

Patches attached.

- Andreas
From 1105cb797c67d05bf4666e2e33140debcfec12a7 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt 
Date: Thu, 22 May 2025 15:57:13 +0200
Subject: [PATCH 1/3] avcodec/asvenc: Don't waste bits encoding non-visible
 part

Up until now, the encoder replicated all the border pixels
for incomplete 16x16 macroblocks. In case the available width
or height is <= 8, some of the luma blocks of the MB
do not correspond to actual input, so that we should encode
them using the least amount of bits. Zeroing the block coefficients
(as this commit does) achieves this, replicating the pixels
and performing an FDCT does not.

This commit also removes the frame copying code for insufficiently
aligned dimensions.

The vsynth3-asv[12] FATE tests use a 34x34 input file and are
therefore affected by this. As the ref updates show, the size
and checksum of the encoded changes, yet the decoded output
stays the same.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/asvenc.c   | 131 +-
 tests/ref/vsynth/vsynth3-asv1 |   4 +-
 tests/ref/vsynth/vsynth3-asv2 |   4 +-
 3 files changed, 84 insertions(+), 55 deletions(-)

diff --git a/libavcodec/asvenc.c b/libavcodec/asvenc.c
index 52666ee547..a53dc7c670 100644
--- a/libavcodec/asvenc.c
+++ b/libavcodec/asvenc.c
@@ -26,6 +26,7 @@
 #include "config_components.h"
 
 #include "libavutil/attributes.h"
+#include "libavutil/intreadwrite.h"
 #include "libavutil/mem.h"
 #include "libavutil/mem_internal.h"
 
@@ -228,55 +229,65 @@ static inline void dct_get(ASVEncContext *a, const AVFrame *frame,
 }
 }
 
-static int encode_frame(AVCodecContext *avctx, AVPacket *pkt,
-const AVFrame *pict, int *got_packet)
+static void handle_partial_mb(ASVEncContext *a, const uint8_t *const data[3],
+  const int linesizes[3],
+  int valid_width, int valid_height)
 {
-ASVEncContext *const a = avctx->priv_data;
-const ASVCommonContext *const c = &a->c;
-int size, ret;
-
-if (pict->width % 16 || pict->height % 16) {
-AVFrame *clone = av_frame_alloc();
-int i;
-
-if (!clone)
-return AVERROR(ENOMEM);
-clone->format = pict->format;
-clone->width  = FFALIGN(pict->width, 16);
-clone->height = FFALIGN(pict->height, 16);
-ret = av_frame_get_buffer(clone, 0);
-if (ret < 0) {
-av_frame_free(&clone);
-return ret;
+const int nb_blocks = a->c.avctx->flags & AV_CODEC_FLAG_GRAY ? 4 : 6;
+static const struct Descriptor {
+uint8_t x_offset, y_offset;
+uint8_t component, subsampling;
+} block_descriptor[] = {
+{ 0, 0, 0, 0 }, { 8, 0, 0, 0 }, { 0, 8, 0, 0 }, { 8, 8, 0, 0 },
+{ 0, 0, 1, 1 }, { 0, 0, 2, 1 },
+};
+
+for (int i = 0; i < nb_blocks; ++i) {
+const struct Descriptor *const desc = block_descriptor + i;
+int width_avail  = AV_CEIL_RSHIFT(valid_width,  desc->subsampling) - desc->x_offset;
+int height_avail = AV_CEIL_RSHIFT(valid_height, desc->subsampling) - desc->y_offset;
+
+if (width_avail <= 0 || height_avail <= 0) {
+// This block is outside of the visible part; don't replicate pixels,
+// just zero the block, so that only the dc value will be coded.
+memset(a->block[i], 0, sizeof(a->block[i]));
+continue;
 }
-
-ret = av_frame_copy(clone, pict);
-if (ret < 0) {
-av_frame_free(&clone);
-return ret;
+width_avail  = FFMIN(width_avail,  8);
+height_avail = FFMIN(height_avail, 8);
+
+ptrdiff_t linesize = linesizes[desc->component];
+const uint8_t *src = data[desc->component] + desc->y_offset * linesize + desc->x_offset;
+int16_t *block = a->block[i];
+
+for (int h = 0;; block += 8, src += linesize) {
+int16_t last;
+for (int w = 0; w < width_avail; ++w)
+last = block[w] = src[w];
+for (int w = width_avail; w < 8; ++w)
+block[w] = last;
+if (++h == height_avail)
+break;
 }
-
-for (i = 0; i<3; i++) {
-int x, y;
-int w  = AV_CEIL_RSHIFT(pict->width, !!i);
-int h  = AV_CEIL_RSHIFT(pict->height, !!i);
-int w2 = AV_CEIL_RSHIFT(clone->width, !!i);
-int h2 = AV_CEIL_RSHIFT(clone->height, !!i);
-for (y=0; ydata[i][x + y*clone->linesize[i]] =
-clone->data[i][w - 1 + y*clone->linesize[i]];
-for (y=h; ydata[i][x + y*clone->linesize[i]] =
-clone->data[i][x + (h-1)*clone->linesize[i]];
+const int16_t *const last_row = block;
+for (int h = height_avail; h < 8; ++h) {
+block += 8;
+AV_COPY128(block, last_row);
 }
-ret = encode_frame(avctx, pkt, clone, got_packet);
 

[FFmpeg-devel] [RFC] "Additional Emails for New Defect Notifications" from coverity

[Michael Niedermayer]

Hi all

Coverity screwed up the mails they send out about new defects.

It seems they now have a "Additional Emails for New Defect Notifications"
if someone wants to be added to that list, reply here and say so

or should we do something more fancy like just adding ffmpeg-devel ?
(would need timo to ensure that any unsubscribe links/mails dont end
 up on the list)
or everyone who used their coverity account in the last 2 years ?
People do need to confirm the subscription

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

Hello,

I wanted to put on the record that adding RaptorQ to FFmpeg isn't
maintenance of FFmpeg.

It's adding an obscure FEC protocol to FFmpeg, which is not going to be
implemented well without an event loop anyway.

I do not think it's a suitable STF project.

Regards,
Kieran Kunhya
___
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] tests/fate/ac3: add a second ac3_fixed encoder test

[Martin Storsjö]

On Thu, 22 May 2025, James Almer wrote:


ffmpeg | branch: master | James Almer  | Thu May 22 19:23:35 
2025 -0300| [622a72b5ea5f2022b173355d65d513df2d75000b] | committer: James Almer

tests/fate/ac3: add a second ac3_fixed encoder test

Exercising the lavfi filtergraph codepath to choose the best output layout.

Signed-off-by: James Almer 


http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=622a72b5ea5f2022b173355d65d513df2d75000b

---

tests/fate/ac3.mak | 5 +
1 file changed, 5 insertions(+)

diff --git a/tests/fate/ac3.mak b/tests/fate/ac3.mak
index 1ecb5a3f54..b23a9e4dcc 100644
--- a/tests/fate/ac3.mak
+++ b/tests/fate/ac3.mak
@@ -91,6 +91,11 @@ fate-ac3-fixed-encode: CMD = md5 -i $(SRC) -c ac3_fixed -ab 
128k -f ac3 -flags +
fate-ac3-fixed-encode: CMP = oneline
fate-ac3-fixed-encode: REF = e9d78bca187b4bbafc4512bcea8efd3e

+FATE_AC3-$(call ALLYES, EAC3_DEMUXER AC3_FIXED_ENCODER AC3_MUXER 
ARESAMPLE_FILTER) += fate-ac3-fixed-encode-2
+fate-ac3-fixed-encode-2: CMD = md5pipe -i 
$(TARGET_SAMPLES)/eac3/the_great_wall_7.1.eac3 -c:a ac3_fixed -ab 256k -f ac3 
-flags +bitexact -af aresample
+fate-ac3-fixed-encode-2: CMP = oneline
+fate-ac3-fixed-encode-2: REF = 1b92b037b23b231c9523f334ccfb11da
+
FATE_EAC3-$(call ALLYES, EAC3_DEMUXER EAC3_MUXER EAC3_CORE_BSF) += 
fate-eac3-core-bsf
fate-eac3-core-bsf: CMD = md5pipe -i 
$(TARGET_SAMPLES)/eac3/the_great_wall_7.1.eac3 -c:a copy -bsf:a eac3_core 
-fflags +bitexact -f eac3
fate-eac3-core-bsf: CMP = oneline


This test seems to fail in a large number of configurations; see fate.

// Martin

___
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] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

On Fri, 23 May 2025, 04:44 Lynne,  wrote:

> On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote:
> > Hello,
> >
> > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > maintenance of FFmpeg.
>
> It isn't -- it's research.
> > It's adding an obscure FEC protocol to FFmpeg, which is not going to be
> > implemented well without an event loop anyway.
>
> You're mixing up FEC implementation details that don't matter for a
> library.
> It works much like a decoder - you put N blocks of Y bytes data in, and
> you get X blocks of Z byes out.
> > I do not think it's a suitable STF project.
> STF is not maintenance-only from what I understand, but also for
> innovation, in this case, research.
>

I point you to the previous thread on FEC where I explained that's a flawed
design as it causes bursting in a practical protocol.

You've basically answered the question that your implementation will be
theoretical and not usable in a real protocol.

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

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