[FFmpeg-devel] [PATCH v3] libavcodec/v4l2_buffers.c: set AVFrame interlaced flags

[Scott Theisen]

Originally from:
https://github.com/MythTV/mythtv/commit/669955c6cb29196b4b5120451b5b998d67a65749

---

v3:
remove unnecessary clearing of already 0 valued flags
use switch-case; I don't really think it is any simpler, but I do like the 
format better.
---
 libavcodec/v4l2_buffers.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index 23474ee143..19cc86334b 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -210,6 +210,24 @@ static enum AVColorTransferCharacteristic 
v4l2_get_color_trc(V4L2Buffer *buf)
 return AVCOL_TRC_UNSPECIFIED;
 }
 
+static void v4l2_get_interlacing(AVFrame *frame, V4L2Buffer *buf)
+{
+enum v4l2_field field;
+field = V4L2_TYPE_IS_MULTIPLANAR(buf->buf.type) ?
+buf->context->format.fmt.pix_mp.field :
+buf->context->format.fmt.pix.field;
+
+switch (field) {
+case V4L2_FIELD_INTERLACED:
+case V4L2_FIELD_INTERLACED_TB:
+frame->flags |=  AV_FRAME_FLAG_TOP_FIELD_FIRST;
+/* fallthrough */
+case V4L2_FIELD_INTERLACED_BT:
+frame->flags |=  AV_FRAME_FLAG_INTERLACED;
+break;
+}
+}
+
 static void v4l2_free_buffer(void *opaque, uint8_t *unused)
 {
 V4L2Buffer* avbuf = opaque;
@@ -434,6 +452,7 @@ int ff_v4l2_buffer_buf_to_avframe(AVFrame *frame, 
V4L2Buffer *avbuf)
 frame->color_trc = v4l2_get_color_trc(avbuf);
 frame->pts = v4l2_get_pts(avbuf);
 frame->pkt_dts = AV_NOPTS_VALUE;
+v4l2_get_interlacing(frame, avbuf);
 
 /* these values are updated also during re-init in 
v4l2_process_driver_event */
 frame->height = avbuf->context->height;
-- 
2.43.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 v2] libavcodec/v4l2_buffers.c: set AVFrame interlaced flags

[Scott Theisen]

Originally from:
https://github.com/MythTV/mythtv/commit/669955c6cb29196b4b5120451b5b998d67a65749
---
 libavcodec/v4l2_buffers.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index 23474ee143..85dfb40093 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -210,6 +210,25 @@ static enum AVColorTransferCharacteristic 
v4l2_get_color_trc(V4L2Buffer *buf)
 return AVCOL_TRC_UNSPECIFIED;
 }
 
+static void v4l2_get_interlacing(AVFrame *frame, V4L2Buffer *buf)
+{
+enum v4l2_field field;
+field = V4L2_TYPE_IS_MULTIPLANAR(buf->buf.type) ?
+buf->context->format.fmt.pix_mp.field :
+buf->context->format.fmt.pix.field;
+
+if (field == V4L2_FIELD_INTERLACED || field == V4L2_FIELD_INTERLACED_TB) {
+frame->flags |=  AV_FRAME_FLAG_INTERLACED;
+frame->flags |=  AV_FRAME_FLAG_TOP_FIELD_FIRST;
+} else if (field == V4L2_FIELD_INTERLACED_BT) {
+frame->flags |=  AV_FRAME_FLAG_INTERLACED;
+frame->flags &= ~AV_FRAME_FLAG_TOP_FIELD_FIRST;
+} else {
+frame->flags &= ~AV_FRAME_FLAG_INTERLACED;
+frame->flags &= ~AV_FRAME_FLAG_TOP_FIELD_FIRST;
+}
+}
+
 static void v4l2_free_buffer(void *opaque, uint8_t *unused)
 {
 V4L2Buffer* avbuf = opaque;
@@ -434,6 +453,7 @@ int ff_v4l2_buffer_buf_to_avframe(AVFrame *frame, 
V4L2Buffer *avbuf)
 frame->color_trc = v4l2_get_color_trc(avbuf);
 frame->pts = v4l2_get_pts(avbuf);
 frame->pkt_dts = AV_NOPTS_VALUE;
+v4l2_get_interlacing(frame, avbuf);
 
 /* these values are updated also during re-init in 
v4l2_process_driver_event */
 frame->height = avbuf->context->height;
-- 
2.43.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 v2] libavcodec/v4l2_buffers.c: set AVFrame interlaced flags

[James Almer]

On 12/18/2024 6:30 PM, Scott Theisen wrote:

Originally from:
https://github.com/MythTV/mythtv/commit/669955c6cb29196b4b5120451b5b998d67a65749
---
  libavcodec/v4l2_buffers.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index 23474ee143..85dfb40093 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -210,6 +210,25 @@ static enum AVColorTransferCharacteristic 
v4l2_get_color_trc(V4L2Buffer *buf)
  return AVCOL_TRC_UNSPECIFIED;
  }
  
+static void v4l2_get_interlacing(AVFrame *frame, V4L2Buffer *buf)

+{
+enum v4l2_field field;
+field = V4L2_TYPE_IS_MULTIPLANAR(buf->buf.type) ?
+buf->context->format.fmt.pix_mp.field :
+buf->context->format.fmt.pix.field;
+
+if (field == V4L2_FIELD_INTERLACED || field == V4L2_FIELD_INTERLACED_TB) {
+frame->flags |=  AV_FRAME_FLAG_INTERLACED;
+frame->flags |=  AV_FRAME_FLAG_TOP_FIELD_FIRST;
+} else if (field == V4L2_FIELD_INTERLACED_BT) {
+frame->flags |=  AV_FRAME_FLAG_INTERLACED;
+frame->flags &= ~AV_FRAME_FLAG_TOP_FIELD_FIRST;


The frame is clean at this point (av_frame_unref is called on it at the 
beginning of ff_v4l2_buffer_buf_to_avframe), so no need to clear any flags.

Also, you could use a switch case to slightly simplify this.


+} else {
+frame->flags &= ~AV_FRAME_FLAG_INTERLACED;
+frame->flags &= ~AV_FRAME_FLAG_TOP_FIELD_FIRST;
+}
+}
+
  static void v4l2_free_buffer(void *opaque, uint8_t *unused)
  {
  V4L2Buffer* avbuf = opaque;
@@ -434,6 +453,7 @@ int ff_v4l2_buffer_buf_to_avframe(AVFrame *frame, 
V4L2Buffer *avbuf)
  frame->color_trc = v4l2_get_color_trc(avbuf);
  frame->pts = v4l2_get_pts(avbuf);
  frame->pkt_dts = AV_NOPTS_VALUE;
+v4l2_get_interlacing(frame, avbuf);
  
  /* these values are updated also during re-init in v4l2_process_driver_event */

  frame->height = avbuf->context->height;




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

Re: [FFmpeg-devel] [PATCH] configure: add iso_writer golomb dependency

[James Almer]

On 12/16/2024 8:00 AM, Peter Ross wrote:

since commit fce0622d0b1f69a85fe8ce61e1189dd57a8b0fcc, libavformat/hevc.c
depends on golomb vlc tables.
---
i often build with --disable-all and only turn on the components
that i am working on. this dependency would otherwise go unnoticed since
many codecs drag in golomb.

  configure | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index bf55ba67fa..751506cd6a 100755
--- a/configure
+++ b/configure
@@ -2880,6 +2880,7 @@ h264parse_select="golomb"
  h264_sei_select="atsc_a53 golomb"
  hevcparse_select="golomb"
  hevc_sei_select="atsc_a53 golomb"
+iso_writer_select="golomb"
  frame_thread_encoder_deps="encoders threads"
  iamfdec_deps="iamf"
  iamfdec_select="iso_media mpeg4audio"


This doesn't work for shared builds. You need to add golomb_tab.c to 
OBJS-$(CONFIG_ISO_WRITER) in libavformat/Makefile.




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] swscale/unscaled: add pal8 -> gbr(a)p special converter

[Niklas Haas]

From: Niklas Haas 

Fixes: ticket #9520
Signed-off-by: Niklas Haas 
Sponsored-by: Sovereign Tech Fund
---
 libswscale/swscale.c  |  2 +
 libswscale/swscale_unscaled.c | 81 ++-
 2 files changed, 81 insertions(+), 2 deletions(-)

diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 96634acfd6..bd5b6370db 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -910,6 +910,8 @@ void ff_update_palette(SwsInternal *c, const uint32_t *pal)
 case AV_PIX_FMT_BGR32_1:
 #if HAVE_BIGENDIAN
 case AV_PIX_FMT_BGR24:
+case AV_PIX_FMT_BGRP:
+case AV_PIX_FMT_BGRAP:
 #endif
 c->pal_rgb[i]= a + (r<<8) + (g<<16) + ((unsigned)b<<24);
 break;
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index c7ad6b014a..973ffe0299 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -509,6 +509,34 @@ static void gray8aToPacked24(const uint8_t *src, uint8_t 
*dst, int num_pixels,
 }
 }
 
+static void gray8aToPlanar8(const uint8_t *src, uint8_t *dstG, uint8_t *dstB,
+uint8_t *dstR, uint8_t *dstA, int num_pixels,
+const uint8_t *palette)
+{
+for (int i = 0; i < num_pixels; i++) {
+const uint8_t *rgb = &palette[src[i << 1] * 4];
+dstB[i] = rgb[0];
+dstG[i] = rgb[1];
+dstR[i] = rgb[2];
+if (dstA)
+dstA[i] = src[(i << 1) + 1];
+}
+}
+
+static void pal8ToPlanar8(const uint8_t *src, uint8_t *dstG, uint8_t *dstB,
+  uint8_t *dstR, uint8_t *dstA, int num_pixels,
+  const uint8_t *palette)
+{
+for (int i = 0; i < num_pixels; i++) {
+const uint8_t *rgba = &palette[src[i] * 4];
+dstB[i] = rgba[0];
+dstG[i] = rgba[1];
+dstR[i] = rgba[2];
+if (dstA)
+dstA[i] = rgba[3];
+}
+}
+
 static int bswap_16bpc(SwsInternal *c, const uint8_t *const src[],
   const int srcStride[], int srcSliceY, int 
srcSliceH,
   uint8_t *const dst[], const int dstStride[])
@@ -610,6 +638,45 @@ static int palToRgbWrapper(SwsInternal *c, const uint8_t 
*const src[], const int
 return srcSliceH;
 }
 
+static int palToGbrpWrapper(SwsInternal *c, const uint8_t *const src[],
+const int srcStride[], int srcSliceY, int 
srcSliceH,
+uint8_t *const dst[], const int dstStride[])
+{
+const enum AVPixelFormat srcFormat = c->opts.src_format;
+const enum AVPixelFormat dstFormat = c->opts.dst_format;
+void (*conv)(const uint8_t *src, uint8_t *dstG, uint8_t *dstB, uint8_t 
*dstR,
+ uint8_t *dstA, int num_pixels, const uint8_t *palette) = NULL;
+
+const int num_planes = isALPHA(dstFormat) ? 4 : 3;
+const uint8_t *srcPtr = src[0];
+uint8_t *dstPtr[4] = {0};
+for (int i = 0; i < num_planes; i++)
+dstPtr[i] = dst[i] + dstStride[i] * srcSliceY;
+
+if (srcFormat == AV_PIX_FMT_YA8) {
+switch (dstFormat) {
+case AV_PIX_FMT_GBRP:  conv = gray8aToPlanar8; break;
+case AV_PIX_FMT_GBRAP: conv = gray8aToPlanar8; break;
+}
+} else if (usePal(srcFormat)) {
+switch (dstFormat) {
+case AV_PIX_FMT_GBRP:  conv = pal8ToPlanar8; break;
+case AV_PIX_FMT_GBRAP: conv = pal8ToPlanar8; break;
+}
+}
+
+av_assert1(conv);
+for (int y = 0; y < srcSliceH; y++) {
+conv(srcPtr, dstPtr[0], dstPtr[1], dstPtr[2], dstPtr[3], c->opts.src_w,
+(uint8_t *) c->pal_rgb);
+srcPtr += srcStride[0];
+for (int i = 0; i < num_planes; i++)
+dstPtr[i] += dstStride[i];
+}
+
+return srcSliceH;
+}
+
 static void packed16togbra16(const uint8_t *src, int srcStride,
  uint16_t *dst[], const int dstStride[], int 
srcSliceH,
  int src_alpha, int swap, int shift, int width)
@@ -2529,8 +2596,18 @@ void ff_get_unscaled_swscale(SwsInternal *c)
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAPF32))
 c->convert_unscaled = bswap_32bpc;
 
-if (usePal(srcFormat) && isByteRGB(dstFormat))
-c->convert_unscaled = palToRgbWrapper;
+if (usePal(srcFormat)) {
+switch (dstFormat) {
+case AV_PIX_FMT_GBRP:
+case AV_PIX_FMT_GBRAP:
+c->convert_unscaled = palToGbrpWrapper;
+break;
+default:
+if (isByteRGB(dstFormat))
+c->convert_unscaled = palToRgbWrapper;
+break;
+}
+}
 
 if (srcFormat == AV_PIX_FMT_YUV422P) {
 if (dstFormat == AV_PIX_FMT_YUYV422)
-- 
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...@ff

Re: [FFmpeg-devel] [PATCH v3] libavcodec/v4l2_buffers.c: set AVFrame interlaced flags

[James Almer]

On 12/18/2024 6:59 PM, Scott Theisen wrote:

Originally from:
https://github.com/MythTV/mythtv/commit/669955c6cb29196b4b5120451b5b998d67a65749

---

v3:
remove unnecessary clearing of already 0 valued flags
use switch-case; I don't really think it is any simpler, but I do like the 
format better.
---
  libavcodec/v4l2_buffers.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index 23474ee143..19cc86334b 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -210,6 +210,24 @@ static enum AVColorTransferCharacteristic 
v4l2_get_color_trc(V4L2Buffer *buf)
  return AVCOL_TRC_UNSPECIFIED;
  }
  
+static void v4l2_get_interlacing(AVFrame *frame, V4L2Buffer *buf)

+{
+enum v4l2_field field;
+field = V4L2_TYPE_IS_MULTIPLANAR(buf->buf.type) ?
+buf->context->format.fmt.pix_mp.field :
+buf->context->format.fmt.pix.field;
+
+switch (field) {
+case V4L2_FIELD_INTERLACED:
+case V4L2_FIELD_INTERLACED_TB:
+frame->flags |=  AV_FRAME_FLAG_TOP_FIELD_FIRST;
+/* fallthrough */
+case V4L2_FIELD_INTERLACED_BT:
+frame->flags |=  AV_FRAME_FLAG_INTERLACED;
+break;
+}
+}
+
  static void v4l2_free_buffer(void *opaque, uint8_t *unused)
  {
  V4L2Buffer* avbuf = opaque;
@@ -434,6 +452,7 @@ int ff_v4l2_buffer_buf_to_avframe(AVFrame *frame, 
V4L2Buffer *avbuf)
  frame->color_trc = v4l2_get_color_trc(avbuf);
  frame->pts = v4l2_get_pts(avbuf);
  frame->pkt_dts = AV_NOPTS_VALUE;
+v4l2_get_interlacing(frame, avbuf);
  
  /* these values are updated also during re-init in v4l2_process_driver_event */

  frame->height = avbuf->context->height;


Should be ok, but i don't maintain (nor can test) v4l2. So if nobody 
reviews it or pushes it in a few days, I'll.




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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: remove systematic PAL8 hack

[Vittorio Giovara]

On Wed, Dec 18, 2024 at 12:48 PM Ronald S. Bultje 
wrote:

> >
> > It is worth pointing out that *libswscale* does not directly output PAL8;
> > this rather is (and always was) handled by vf_scale. So in some sense,
> this
> > functionality already depends on libavfilter.
> >
> > That said, I do agree that simply regressing existing use cases should
> not
> > be done without some sort of mechanism for automatically invoking the
> > proper
> > replacement.
> >
> > I will retract this patch for now, then, and put the corresponding issue
> on
> > hold. I think that a full discussion of how to handle this better will
> have
> > to wait until we have a better dither handling inside swscale.
> >
>
> I would commit it, but instead of failing, emit a warning (recommending to
> use the palettegen filter instead) and continue the old behaviour (as a
> fallback).
>
> Upon the next major bump, the warning will become an error and the fallback
> is removed.
>

+1
-- 
Vittorio
___
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] avfilter/vf_scale: remove systematic PAL8 hack

[Ronald S. Bultje]

Hi,

On Wed, Dec 18, 2024 at 5:29 AM Niklas Haas  wrote:

> On Wed, 18 Dec 2024 02:32:07 +0100 Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
> > Hi
> >
> > On Tue, Dec 17, 2024 at 10:31:42AM +0100, Niklas Haas wrote:
> > > On Tue, 17 Dec 2024 01:48:02 +0100 Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
> > > > Hi
> > > >
> > > > On Mon, Dec 16, 2024 at 02:57:53PM +0100, Niklas Haas wrote:
> > > > > From: Niklas Haas 
> > > > >
> > > > > This is not a good way of generating a PAL8 output.
> > > >
> > > > of course not
> > > >
> > > > but this breaks fate and features
> > >
> > > It doesn't really break a feature because we have a better replacement
> already
> > > included in libavfilter, IMO.
> >
> > swscale could convert to pal8 before, it cant after the patch.
> > So it lost a feature and breaks users code unless iam missing
> > something ?
>
> It is worth pointing out that *libswscale* does not directly output PAL8;
> this rather is (and always was) handled by vf_scale. So in some sense, this
> functionality already depends on libavfilter.
>
> That said, I do agree that simply regressing existing use cases should not
> be done without some sort of mechanism for automatically invoking the
> proper
> replacement.
>
> I will retract this patch for now, then, and put the corresponding issue on
> hold. I think that a full discussion of how to handle this better will have
> to wait until we have a better dither handling inside swscale.
>

I would commit it, but instead of failing, emit a warning (recommending to
use the palettegen filter instead) and continue the old behaviour (as a
fallback).

Upon the next major bump, the warning will become an error and the fallback
is removed.

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] [PATCH] avformat/Makefile: add iso_writer golomb_tab from shared library dependency

[Peter Ross]

---
 libavformat/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index dd96bf7ba8..a6935ad244 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -728,7 +728,7 @@ OBJS-$(CONFIG_LIBZMQ_PROTOCOL)   += libzmq.o
 
 # Objects duplicated from other libraries for shared builds
 SHLIBOBJS+= log2_tab.o to_upper4.o
-SHLIBOBJS-$(CONFIG_ISO_MEDIA)+= mpegaudiotabs.o
+SHLIBOBJS-$(CONFIG_ISO_WRITER)   += golomb_tab.o mpegaudiotabs.o
 SHLIBOBJS-$(CONFIG_FLV_MUXER)+= mpeg4audio_sample_rates.o
 SHLIBOBJS-$(CONFIG_HLS_DEMUXER)  += ac3_channel_layout_tab.o
 SHLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER)+= jpegxl_parse.o
-- 
2.45.2

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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] vulkan_decode: support software-defined decoders

[Lynne via ffmpeg-devel]

---
 libavcodec/vulkan_decode.c | 118 +++--
 libavcodec/vulkan_decode.h |   8 +++
 2 files changed, 83 insertions(+), 43 deletions(-)

diff --git a/libavcodec/vulkan_decode.c b/libavcodec/vulkan_decode.c
index 4665a330ef..60ffdf7b38 100644
--- a/libavcodec/vulkan_decode.c
+++ b/libavcodec/vulkan_decode.c
@@ -63,7 +63,9 @@ static const VkVideoProfileInfoKHR 
*get_video_profile(FFVulkanDecodeShared *ctx,
 codec_id == AV_CODEC_ID_H264 ? 
VK_STRUCTURE_TYPE_VIDEO_DECODE_H264_PROFILE_INFO_KHR :
 codec_id == AV_CODEC_ID_HEVC ? 
VK_STRUCTURE_TYPE_VIDEO_DECODE_H265_PROFILE_INFO_KHR :
 codec_id == AV_CODEC_ID_AV1  ? 
VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_PROFILE_INFO_KHR :
-0;
+   VK_STRUCTURE_TYPE_MAX_ENUM;
+if (profile_struct_type == VK_STRUCTURE_TYPE_MAX_ENUM)
+return NULL;
 
 profile_list = ff_vk_find_struct(ctx->s.hwfc->create_pnext,
  
VK_STRUCTURE_TYPE_VIDEO_PROFILE_LIST_INFO_KHR);
@@ -277,6 +279,10 @@ void ff_vk_decode_flush(AVCodecContext *avctx)
 FFVkExecContext *exec;
 int had_submission;
 
+/* Non-video queues do not need to be reset */
+if (!(get_codecdesc(avctx->codec_id)->decode_op))
+return;
+
 exec = ff_vk_exec_get(&ctx->s, &ctx->exec_pool);
 had_submission = exec->had_submission;
 ff_vk_exec_start(&ctx->s, exec);
@@ -564,6 +570,16 @@ static void free_common(AVRefStructOpaque unused, void 
*obj)
 /* Wait on and free execution pool */
 ff_vk_exec_pool_free(&ctx->s, &ctx->exec_pool);
 
+/* Software defined decoder parts */
+ff_vk_shader_free(&ctx->s, &ctx->shd_start);
+ff_vk_shader_free(&ctx->s, &ctx->shd_decode);
+ff_vk_shader_free(&ctx->s, &ctx->shd_end);
+
+for (int i = 0; i < FF_ARRAY_ELEMS(ctx->static_buf); i++)
+ff_vk_free_buf(&ctx->s, &ctx->static_buf[i]);
+for (int i = 0; i < FF_ARRAY_ELEMS(ctx->dynamic_pool); i++)
+av_buffer_pool_uninit(&ctx->dynamic_pool[i]);
+
 /* This also frees all references from this pool */
 av_frame_free(&ctx->common.layered_frame);
 
@@ -584,6 +600,7 @@ static int vulkan_decode_bootstrap(AVCodecContext *avctx, 
AVBufferRef *frames_re
 {
 int err;
 FFVulkanDecodeContext *dec = avctx->internal->hwaccel_priv_data;
+const FFVulkanDecodeDescriptor *vk_desc = get_codecdesc(avctx->codec_id);
 AVHWFramesContext *frames = (AVHWFramesContext *)frames_ref->data;
 AVHWDeviceContext *device = (AVHWDeviceContext *)frames->device_ref->data;
 AVVulkanDeviceContext *hwctx = device->hwctx;
@@ -602,11 +619,13 @@ static int vulkan_decode_bootstrap(AVCodecContext *avctx, 
AVBufferRef *frames_re
 ctx->s.extensions = ff_vk_extensions_to_mask(hwctx->enabled_dev_extensions,
  
hwctx->nb_enabled_dev_extensions);
 
-if (!(ctx->s.extensions & FF_VK_EXT_VIDEO_DECODE_QUEUE)) {
-av_log(avctx, AV_LOG_ERROR, "Device does not support the %s 
extension!\n",
-   VK_KHR_VIDEO_DECODE_QUEUE_EXTENSION_NAME);
-av_refstruct_unref(&dec->shared_ctx);
-return AVERROR(ENOSYS);
+if (vk_desc->queue_flags & VK_QUEUE_VIDEO_DECODE_BIT_KHR) {
+if (!(ctx->s.extensions & FF_VK_EXT_VIDEO_DECODE_QUEUE)) {
+av_log(avctx, AV_LOG_ERROR, "Device does not support the %s 
extension!\n",
+   VK_KHR_VIDEO_DECODE_QUEUE_EXTENSION_NAME);
+av_refstruct_unref(&dec->shared_ctx);
+return AVERROR(ENOSYS);
+}
 }
 
 err = ff_vk_load_functions(device, &ctx->s.vkfn, ctx->s.extensions, 1, 1);
@@ -960,53 +979,59 @@ static void free_profile_data(AVHWFramesContext *hwfc)
 
 int ff_vk_frame_params(AVCodecContext *avctx, AVBufferRef *hw_frames_ctx)
 {
-VkFormat vkfmt;
+VkFormat vkfmt = VK_FORMAT_UNDEFINED;
 int err, dedicated_dpb;
 AVHWFramesContext *frames_ctx = (AVHWFramesContext*)hw_frames_ctx->data;
 AVVulkanFramesContext *hwfc = frames_ctx->hwctx;
 FFVulkanDecodeContext *dec = avctx->internal->hwaccel_priv_data;
-FFVulkanDecodeProfileData *prof;
-FFVulkanDecodeShared *ctx;
-
-frames_ctx->sw_format = AV_PIX_FMT_NONE;
+FFVulkanDecodeProfileData *prof = NULL;
 
 err = vulkan_decode_bootstrap(avctx, hw_frames_ctx);
 if (err < 0)
 return err;
 
-prof = av_mallocz(sizeof(FFVulkanDecodeProfileData));
-if (!prof)
-return AVERROR(ENOMEM);
+frames_ctx->sw_format = avctx->sw_pix_fmt;
 
-err = vulkan_decode_get_profile(avctx, hw_frames_ctx,
-&frames_ctx->sw_format, &vkfmt,
-prof, &dedicated_dpb);
-if (err < 0) {
-av_free(prof);
-return err;
-}
+if (avctx->codec_id != AV_CODEC_ID_FFV1) {
+prof = av_mallocz(sizeof(FFVulkanDecodeProfileData));
+if (!prof)
+return AVERROR(ENOMEM);
 
-frames_ctx->user_opaque = prof;
-f

Re: [FFmpeg-devel] [PATCH] vulkan_decode: support software-defined decoders

[Anton Khirnov]

Quoting Lynne via ffmpeg-devel (2024-12-18 10:07:51)
> vulkan_decode: support software-defined decoders
> ---
>  libavcodec/vulkan_decode.c | 118 +++--
>  libavcodec/vulkan_decode.h |   8 +++
>  2 files changed, 83 insertions(+), 43 deletions(-)

This could really use some more explanation.


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

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

Re: [FFmpeg-devel] [PATCH] configure: add option to statically link to libvulkan

[Leo Izen]

On 12/18/24 3:46 AM, Lynne via ffmpeg-devel wrote:

This may be useful in weird setups and on platforms where
static linking to libvulkan is supported.

libplacebo also has this fallback.
---


I'm going to ask the classic "Why would you want to do this?"

More specifically, I mean, can you give an example of a weird setup 
where this would solve a problem?


- 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] [PATCH] configure: add option to statically link to libvulkan

[Lynne via ffmpeg-devel]

On 19/12/2024 00:05, Leo Izen wrote:

On 12/18/24 3:46 AM, Lynne via ffmpeg-devel wrote:

This may be useful in weird setups and on platforms where
static linking to libvulkan is supported.

libplacebo also has this fallback.
---


I'm going to ask the classic "Why would you want to do this?"

More specifically, I mean, can you give an example of a weird setup 
where this would solve a problem?


Mainly SoCs building with a very specific locally built libvulkan from 
the lunarg SDK.


But really, its because the person who maintains much of the validation 
layer has a weird setup that doesn't work with our dynamic linking 
setup, and it may be useful for others.


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

Re: [FFmpeg-devel] [PATCH v2] swscale/unscaled: correctly round yuv2yuv when not dithering

[Niklas Haas]

On Tue, 17 Dec 2024 15:35:22 +0100 Niklas Haas  wrote:
> From: Niklas Haas 
>
> We should at least bias towards the nearest integer, instead of always
> rounding down, when not dithering. This is a bit more correct.
>
> Signed-off-by: Niklas Haas 
> Sponsored-by: Sovereign Tech Fund

Ignore this one, it's wrong. I forgot to amend my local changes before sending
the patch. Will send a v3.

> ---
>  libswscale/swscale_unscaled.c | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
> index c7ad6b014a..ea6fb038bc 100644
> --- a/libswscale/swscale_unscaled.c
> +++ b/libswscale/swscale_unscaled.c
> @@ -2075,17 +2075,18 @@ static int packedCopyWrapper(SwsInternal *c, const 
> uint8_t *const src[],
>
>  #define DITHER_COPY(dst, dstStride, src, srcStride, bswap, dbswap)\
>  unsigned shift= src_depth-dst_depth, tmp;\
> +unsigned bias = 1 << (shift - 1);\
>  if (c->opts.dither == SWS_DITHER_NONE) {\
>  for (i = 0; i < height; i++) {\
>  for (j = 0; j < length-7; j+=8) {\
> -dst[j+0] = dbswap(bswap(src[j+0])>>shift);\
> -dst[j+1] = dbswap(bswap(src[j+1])>>shift);\
> -dst[j+2] = dbswap(bswap(src[j+2])>>shift);\
> -dst[j+3] = dbswap(bswap(src[j+3])>>shift);\
> -dst[j+4] = dbswap(bswap(src[j+4])>>shift);\
> -dst[j+5] = dbswap(bswap(src[j+5])>>shift);\
> -dst[j+6] = dbswap(bswap(src[j+6])>>shift);\
> -dst[j+7] = dbswap(bswap(src[j+7])>>shift);\
> +dst[j+0] = dbswap(bswap(src[j+0] + bias))>>shift);\
> +dst[j+1] = dbswap(bswap(src[j+1] + bias))>>shift);\
> +dst[j+2] = dbswap(bswap(src[j+2] + bias))>>shift);\
> +dst[j+3] = dbswap(bswap(src[j+3] + bias))>>shift);\
> +dst[j+4] = dbswap(bswap(src[j+4] + bias))>>shift);\
> +dst[j+5] = dbswap(bswap(src[j+5] + bias))>>shift);\
> +dst[j+6] = dbswap(bswap(src[j+6] + bias))>>shift);\
> +dst[j+7] = dbswap(bswap(src[j+7] + bias))>>shift);\
>  }\
>  for (; j < length; j++) {\
>  dst[j] = dbswap(bswap(src[j])>>shift);\
> @@ -2169,6 +2170,7 @@ static int planarCopyWrapper(SwsInternal *c, const 
> uint8_t *const src[],
>  uint16_t *dstPtr2 = (uint16_t*)dstPtr;
>
>  if (dst_depth == 8) {
> +av_assert1(src_depth > 8);
>  if(isBE(c->opts.src_format) == HAVE_BIGENDIAN){
>  DITHER_COPY(dstPtr, dstStride[plane], srcPtr2, 
> srcStride[plane]/2, , )
>  } else {
> @@ -2248,7 +2250,7 @@ static int planarCopyWrapper(SwsInternal *c, const 
> uint8_t *const src[],
>  dstPtr2 += dstStride[plane]/2;
>  srcPtr2 += srcStride[plane]/2;
>  }
> -} else {
> +} else { /* src_depth > dst_depth */
>  if(isBE(c->opts.src_format) == HAVE_BIGENDIAN){
>  if(isBE(c->opts.dst_format) == HAVE_BIGENDIAN){
>  DITHER_COPY(dstPtr2, dstStride[plane]/2, 
> srcPtr2, srcStride[plane]/2, , )
> --
> 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".

[FFmpeg-devel] [PATCH 4/5] vulkan: do not NIH a queue context

[Lynne via ffmpeg-devel]

We recently introduced a public field which was a superset
of the queue context we used to have.
Switch to using it entirely.

This also allows us to get rid of the NIH function just for
video implementations.
---
 libavcodec/ffv1enc_vulkan.c   | 18 
 libavcodec/vulkan_decode.c| 16 +++
 libavcodec/vulkan_decode.h|  2 +-
 libavcodec/vulkan_encode.c| 10 -
 libavcodec/vulkan_encode.h|  2 +-
 libavcodec/vulkan_video.c | 14 -
 libavcodec/vulkan_video.h |  6 --
 libavfilter/vf_avgblur_vulkan.c   | 12 ---
 libavfilter/vf_blend_vulkan.c | 12 ---
 libavfilter/vf_bwdif_vulkan.c | 12 ---
 libavfilter/vf_chromaber_vulkan.c | 12 ---
 libavfilter/vf_flip_vulkan.c  | 12 ---
 libavfilter/vf_gblur_vulkan.c | 12 ---
 libavfilter/vf_nlmeans_vulkan.c   | 12 ---
 libavfilter/vf_overlay_vulkan.c   | 12 ---
 libavfilter/vf_scale_vulkan.c | 12 ---
 libavfilter/vf_transpose_vulkan.c | 12 ---
 libavfilter/vf_xfade_vulkan.c | 12 ---
 libavfilter/vsrc_testsrc_vulkan.c | 12 ---
 libavutil/hwcontext_vulkan.c  | 20 +-
 libavutil/vulkan.c| 34 +++
 libavutil/vulkan.h| 14 +
 22 files changed, 157 insertions(+), 123 deletions(-)

diff --git a/libavcodec/ffv1enc_vulkan.c b/libavcodec/ffv1enc_vulkan.c
index 41d396fb32..1874a3f42b 100644
--- a/libavcodec/ffv1enc_vulkan.c
+++ b/libavcodec/ffv1enc_vulkan.c
@@ -58,10 +58,10 @@ typedef struct VulkanEncodeFFv1Context {
 AVFrame *frame;
 
 FFVulkanContext s;
-FFVkQueueFamilyCtx qf;
+AVVulkanDeviceQueueFamily *qf;
 FFVkExecPool exec_pool;
 
-FFVkQueueFamilyCtx transfer_qf;
+AVVulkanDeviceQueueFamily *transfer_qf;
 FFVkExecPool transfer_exec_pool;
 
 VkBufferCopy *buf_regions;
@@ -1586,8 +1586,8 @@ static av_cold int vulkan_encode_ffv1_init(AVCodecContext 
*avctx)
 if (err < 0)
 return err;
 
-err = ff_vk_qf_init(&fv->s, &fv->qf, VK_QUEUE_COMPUTE_BIT);
-if (err < 0) {
+fv->qf = ff_vk_qf_find(&fv->s, VK_QUEUE_COMPUTE_BIT, 0);
+if (!fv->qf) {
 av_log(avctx, AV_LOG_ERROR, "Device has no compute queues!\n");
 return err;
 }
@@ -1626,7 +1626,7 @@ static av_cold int vulkan_encode_ffv1_init(AVCodecContext 
*avctx)
 }
 
 if (!fv->async_depth) {
-fv->async_depth = FFMIN(fv->qf.nb_queues, FFMAX(max_heap_size / 
maxsize, 1));
+fv->async_depth = FFMIN(fv->qf->num, FFMAX(max_heap_size / maxsize, 
1));
 fv->async_depth = FFMAX(fv->async_depth, 1);
 }
 
@@ -1635,19 +1635,19 @@ static av_cold int 
vulkan_encode_ffv1_init(AVCodecContext *avctx)
(fv->async_depth * maxsize) / (1024*1024),
fv->async_depth);
 
-err = ff_vk_exec_pool_init(&fv->s, &fv->qf, &fv->exec_pool,
+err = ff_vk_exec_pool_init(&fv->s, fv->qf, &fv->exec_pool,
fv->async_depth,
0, 0, 0, NULL);
 if (err < 0)
 return err;
 
-err = ff_vk_qf_init(&fv->s, &fv->transfer_qf, VK_QUEUE_TRANSFER_BIT);
-if (err < 0) {
+fv->transfer_qf = ff_vk_qf_find(&fv->s, VK_QUEUE_TRANSFER_BIT, 0);
+if (!fv->transfer_qf) {
 av_log(avctx, AV_LOG_ERROR, "Device has no transfer queues!\n");
 return err;
 }
 
-err = ff_vk_exec_pool_init(&fv->s, &fv->transfer_qf, 
&fv->transfer_exec_pool,
+err = ff_vk_exec_pool_init(&fv->s, fv->transfer_qf, 
&fv->transfer_exec_pool,
1,
0, 0, 0, NULL);
 if (err < 0)
diff --git a/libavcodec/vulkan_decode.c b/libavcodec/vulkan_decode.c
index 1a5e70b2d6..8fd97a6dea 100644
--- a/libavcodec/vulkan_decode.c
+++ b/libavcodec/vulkan_decode.c
@@ -1116,21 +1116,19 @@ int ff_vk_decode_init(AVCodecContext *avctx)
 
 /* Create queue context */
 vk_desc = get_codecdesc(avctx->codec_id);
-err = ff_vk_video_qf_init(s, &ctx->qf,
-  VK_QUEUE_VIDEO_DECODE_BIT_KHR,
-  vk_desc->decode_op);
-if (err < 0) {
+ctx->qf = ff_vk_qf_find(s, VK_QUEUE_VIDEO_DECODE_BIT_KHR, 
vk_desc->decode_op);
+if (!ctx->qf) {
 av_log(avctx, AV_LOG_ERROR, "Decoding of %s is not supported by this 
device\n",
avcodec_get_name(avctx->codec_id));
 return err;
 }
 
-/* Enable queries if supported */
-if (s->query_props[ctx->qf.queue_family].queryResultStatusSupport)
+/* Enable queries if supported and usable */
+if (s->query_props[ctx->qf->idx].queryResultStatusSupport)
 nb_q = 1;
 
 session_create.flags = 0x0;
-session_create.queueFamilyIndex = ctx->qf.queue_family;
+session_create.queueFamilyIndex = ctx->qf->idx;
 session_create.maxCodedExtent = ctx->caps.maxCodedExtent;
 session_create.maxDpbSlots =

[FFmpeg-devel] [PATCH 2/5] vulkan_decode: use a single execution pool

[Lynne via ffmpeg-devel]

Originally, the decoder had a single execution pool, with one
execution context per thread. Execution pools were always intended
to be thread-safe, as long as there were enough execution contexts
in the pool to satisfy all threads.

Due to synchronization issues, the threading part was removed at some
point, and, for decoding, each thread had its own execution pool.
Having a single execution pool per context is hacky, not to mention
wasteful.
Most importantly, we *cannot* associate single shaders across multiple
execution pools for a single application. This means that we cannot
use shaders to either apply film grain, or use this framework for
software-defined decoders.

The recent commits added threading capabilities back to the execution
pool, and the number of contexts in each pool was increased. This was
done with the assumption that the execution pool was singular, which
it was not. This led to increased parallelism and number of frames
in flight, which is taxing on memory.

This commit finally restores proper threading behaviour.
The validation layer has isses that are reported and addressed in the
earlier commit.
---
 libavcodec/vulkan_decode.c | 47 --
 libavcodec/vulkan_decode.h |  2 +-
 2 files changed, 16 insertions(+), 33 deletions(-)

diff --git a/libavcodec/vulkan_decode.c b/libavcodec/vulkan_decode.c
index 5936c0bc4a..1a5e70b2d6 100644
--- a/libavcodec/vulkan_decode.c
+++ b/libavcodec/vulkan_decode.c
@@ -83,25 +83,6 @@ int ff_vk_update_thread_context(AVCodecContext *dst, const 
AVCodecContext *src)
 FFVulkanDecodeContext *src_ctx = src->internal->hwaccel_priv_data;
 FFVulkanDecodeContext *dst_ctx = dst->internal->hwaccel_priv_data;
 
-if (!dst_ctx->exec_pool.cmd_bufs) {
-FFVulkanDecodeShared *ctx = src_ctx->shared_ctx;
-
-const VkVideoProfileInfoKHR *profile = get_video_profile(ctx, 
dst->codec_id);
-if (!profile) {
-av_log(dst, AV_LOG_ERROR, "Video profile missing from frames 
context!\n");
-return AVERROR(EINVAL);
-}
-
-err = ff_vk_exec_pool_init(&ctx->s, &ctx->qf,
-   &dst_ctx->exec_pool,
-   src_ctx->exec_pool.pool_size,
-   src_ctx->exec_pool.nb_queries,
-   VK_QUERY_TYPE_RESULT_STATUS_ONLY_KHR, 0,
-   profile);
-if (err < 0)
-return err;
-}
-
 av_refstruct_replace(&dst_ctx->shared_ctx, src_ctx->shared_ctx);
 
 if (src_ctx->session_params) {
@@ -293,8 +274,11 @@ void ff_vk_decode_flush(AVCodecContext *avctx)
 };
 
 VkCommandBuffer cmd_buf;
-FFVkExecContext *exec = ff_vk_exec_get(&ctx->s, &dec->exec_pool);
-int had_submission = exec->had_submission;
+FFVkExecContext *exec;
+int had_submission;
+
+exec = ff_vk_exec_get(&ctx->s, &ctx->exec_pool);
+had_submission = exec->had_submission;
 ff_vk_exec_start(&ctx->s, exec);
 cmd_buf = exec->buf;
 
@@ -345,7 +329,7 @@ int ff_vk_decode_frame(AVCodecContext *avctx,
 size_t data_size = FFALIGN(vp->slices_size,
ctx->caps.minBitstreamBufferSizeAlignment);
 
-FFVkExecContext *exec = ff_vk_exec_get(&ctx->s, &dec->exec_pool);
+FFVkExecContext *exec = ff_vk_exec_get(&ctx->s, &ctx->exec_pool);
 
 /* The current decoding reference has to be bound as an inactive reference 
*/
 VkVideoReferenceSlotInfoKHR *cur_vk_ref;
@@ -354,7 +338,7 @@ int ff_vk_decode_frame(AVCodecContext *avctx,
 cur_vk_ref[0].slotIndex = -1;
 decode_start.referenceSlotCount++;
 
-if (dec->exec_pool.nb_queries && exec->had_submission) {
+if (ctx->exec_pool.nb_queries && exec->had_submission) {
 uint32_t *result;
 ret = ff_vk_exec_get_query(&ctx->s, exec, (void **)&result,
VK_QUERY_RESULT_WAIT_BIT);
@@ -525,14 +509,14 @@ int ff_vk_decode_frame(AVCodecContext *avctx,
 vk->CmdBeginVideoCodingKHR(cmd_buf, &decode_start);
 
 /* Start status query */
-if (dec->exec_pool.nb_queries)
-vk->CmdBeginQuery(cmd_buf, dec->exec_pool.query_pool, exec->query_idx 
+ 0, 0);
+if (ctx->exec_pool.nb_queries)
+vk->CmdBeginQuery(cmd_buf, ctx->exec_pool.query_pool, exec->query_idx 
+ 0, 0);
 
 vk->CmdDecodeVideoKHR(cmd_buf, &vp->decode_info);
 
 /* End status query */
-if (dec->exec_pool.nb_queries)
-vk->CmdEndQuery(cmd_buf, dec->exec_pool.query_pool, exec->query_idx + 
0);
+if (ctx->exec_pool.nb_queries)
+vk->CmdEndQuery(cmd_buf, ctx->exec_pool.query_pool, exec->query_idx + 
0);
 
 vk->CmdEndVideoCodingKHR(cmd_buf, &decode_end);
 
@@ -577,6 +561,9 @@ static void free_common(AVRefStructOpaque unused, void *obj)
 FFVulkanContext *s = &ctx->s;
 FFVulkanFunctions *vk = &ctx->s.vkfn;
 
+/* Wait on and free execution pool */
+ff_vk_exec_pool_free(&ctx->s, &ctx->exec_pool);
+
 

[FFmpeg-devel] [PATCH 1/5] hwcontext_vulkan: disable validation layer threading warnings

[Lynne via ffmpeg-devel]

The layer is buggy currently:
https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/9045
---
 libavutil/hwcontext_vulkan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 5601ef4d9e..6eca097ea3 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -626,6 +626,7 @@ static VkBool32 VKAPI_CALL 
vk_dbg_callback(VkDebugUtilsMessageSeverityFlagBitsEX
 case 0xfd92477a: /* BestPractices-vkAllocateMemory-small-allocation */
 case 0x618ab1e7: /* VUID-VkImageViewCreateInfo-usage-02275 */
 case 0x30f4ac70: /* VUID-VkImageCreateInfo-pNext-06811 */
+case 0xa05b236e: /* UNASSIGNED-Threading-MultipleThreads-Write */
 return VK_FALSE;
 default:
 break;
-- 
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 3/5] vulkan: remove pointless mutex locks

[Lynne via ffmpeg-devel]

This code was simply incorrect through and through. It did not
protect what actually has to be protected in a multi-threaded setup.
Perhaps it was used to silence threading errors?

Either way, remove it, and document the correct way to use execution
pools in a threaded environment.
---
 libavutil/vulkan.c | 12 
 libavutil/vulkan.h |  2 ++
 2 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
index dc30539115..55b039d5ef 100644
--- a/libavutil/vulkan.c
+++ b/libavutil/vulkan.c
@@ -251,7 +251,6 @@ void ff_vk_exec_pool_free(FFVulkanContext *s, FFVkExecPool 
*pool)
 vk->WaitForFences(s->hwctx->act_dev, 1, &e->fence, VK_TRUE, 
UINT64_MAX);
 vk->DestroyFence(s->hwctx->act_dev, e->fence, s->hwctx->alloc);
 }
-pthread_mutex_destroy(&e->lock);
 
 ff_vk_exec_discard_deps(s, e);
 
@@ -424,11 +423,6 @@ int ff_vk_exec_pool_init(FFVulkanContext *s, 
FFVkQueueFamilyCtx *qf,
 .flags = VK_FENCE_CREATE_SIGNALED_BIT,
 };
 
-/* Mutex */
-err = pthread_mutex_init(&e->lock, NULL);
-if (err != 0)
-return AVERROR(err);
-
 /* Fence */
 ret = vk->CreateFence(s->hwctx->act_dev, &fence_create, 
s->hwctx->alloc,
   &e->fence);
@@ -498,10 +492,8 @@ FFVkExecContext *ff_vk_exec_get(FFVulkanContext *s, 
FFVkExecPool *pool)
 void ff_vk_exec_wait(FFVulkanContext *s, FFVkExecContext *e)
 {
 FFVulkanFunctions *vk = &s->vkfn;
-pthread_mutex_lock(&e->lock);
 vk->WaitForFences(s->hwctx->act_dev, 1, &e->fence, VK_TRUE, UINT64_MAX);
 ff_vk_exec_discard_deps(s, e);
-pthread_mutex_unlock(&e->lock);
 }
 
 int ff_vk_exec_start(FFVulkanContext *s, FFVkExecContext *e)
@@ -517,11 +509,7 @@ int ff_vk_exec_start(FFVulkanContext *s, FFVkExecContext 
*e)
 
 /* Wait for the fence to be signalled */
 vk->WaitForFences(s->hwctx->act_dev, 1, &e->fence, VK_TRUE, UINT64_MAX);
-
-/* vkResetFences is defined as being host-synchronized */
-pthread_mutex_lock(&e->lock);
 vk->ResetFences(s->hwctx->act_dev, 1, &e->fence);
-pthread_mutex_unlock(&e->lock);
 
 /* Discard queue dependencies */
 ff_vk_exec_discard_deps(s, e);
diff --git a/libavutil/vulkan.h b/libavutil/vulkan.h
index ef39f76675..0a166da9eb 100644
--- a/libavutil/vulkan.h
+++ b/libavutil/vulkan.h
@@ -400,6 +400,8 @@ int ff_vk_qf_init(FFVulkanContext *s, FFVkQueueFamilyCtx 
*qf,
 
 /**
  * Allocates/frees an execution pool.
+ * If used in a multi-threaded context, there must be at least as many contexts
+ * as there are threads.
  * ff_vk_exec_pool_init_desc() MUST be called if 
ff_vk_exec_descriptor_set_add()
  * has been called.
  */
-- 
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 5/5] vulkan_decode: add queue_flags field to specify queue used

[Lynne via ffmpeg-devel]

---
 libavcodec/vulkan_av1.c| 1 +
 libavcodec/vulkan_decode.c | 2 +-
 libavcodec/vulkan_decode.h | 1 +
 libavcodec/vulkan_h264.c   | 1 +
 libavcodec/vulkan_hevc.c   | 1 +
 5 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vulkan_av1.c b/libavcodec/vulkan_av1.c
index 290607d24c..6659f9d812 100644
--- a/libavcodec/vulkan_av1.c
+++ b/libavcodec/vulkan_av1.c
@@ -26,6 +26,7 @@
 const FFVulkanDecodeDescriptor ff_vk_dec_av1_desc = {
 .codec_id = AV_CODEC_ID_AV1,
 .decode_extension = FF_VK_EXT_VIDEO_DECODE_AV1,
+.queue_flags  = VK_QUEUE_VIDEO_DECODE_BIT_KHR,
 .decode_op= VK_VIDEO_CODEC_OPERATION_DECODE_AV1_BIT_KHR,
 .ext_props = {
 .extensionName = VK_STD_VULKAN_VIDEO_CODEC_AV1_DECODE_EXTENSION_NAME,
diff --git a/libavcodec/vulkan_decode.c b/libavcodec/vulkan_decode.c
index 8fd97a6dea..4665a330ef 100644
--- a/libavcodec/vulkan_decode.c
+++ b/libavcodec/vulkan_decode.c
@@ -1116,7 +1116,7 @@ int ff_vk_decode_init(AVCodecContext *avctx)
 
 /* Create queue context */
 vk_desc = get_codecdesc(avctx->codec_id);
-ctx->qf = ff_vk_qf_find(s, VK_QUEUE_VIDEO_DECODE_BIT_KHR, 
vk_desc->decode_op);
+ctx->qf = ff_vk_qf_find(s, vk_desc->queue_flags, vk_desc->decode_op);
 if (!ctx->qf) {
 av_log(avctx, AV_LOG_ERROR, "Decoding of %s is not supported by this 
device\n",
avcodec_get_name(avctx->codec_id));
diff --git a/libavcodec/vulkan_decode.h b/libavcodec/vulkan_decode.h
index 60f21372c2..1d89db323f 100644
--- a/libavcodec/vulkan_decode.h
+++ b/libavcodec/vulkan_decode.h
@@ -29,6 +29,7 @@
 typedef struct FFVulkanDecodeDescriptor {
 enum AVCodecID   codec_id;
 FFVulkanExtensions   decode_extension;
+VkQueueFlagBits  queue_flags;
 VkVideoCodecOperationFlagBitsKHR decode_op;
 
 VkExtensionProperties ext_props;
diff --git a/libavcodec/vulkan_h264.c b/libavcodec/vulkan_h264.c
index 79447dbb39..1df8f0a208 100644
--- a/libavcodec/vulkan_h264.c
+++ b/libavcodec/vulkan_h264.c
@@ -24,6 +24,7 @@
 const FFVulkanDecodeDescriptor ff_vk_dec_h264_desc = {
 .codec_id = AV_CODEC_ID_H264,
 .decode_extension = FF_VK_EXT_VIDEO_DECODE_H264,
+.queue_flags  = VK_QUEUE_VIDEO_DECODE_BIT_KHR,
 .decode_op= VK_VIDEO_CODEC_OPERATION_DECODE_H264_BIT_KHR,
 .ext_props = {
 .extensionName = VK_STD_VULKAN_VIDEO_CODEC_H264_DECODE_EXTENSION_NAME,
diff --git a/libavcodec/vulkan_hevc.c b/libavcodec/vulkan_hevc.c
index e31e0fc8c5..589c3de83d 100644
--- a/libavcodec/vulkan_hevc.c
+++ b/libavcodec/vulkan_hevc.c
@@ -26,6 +26,7 @@
 const FFVulkanDecodeDescriptor ff_vk_dec_hevc_desc = {
 .codec_id = AV_CODEC_ID_HEVC,
 .decode_extension = FF_VK_EXT_VIDEO_DECODE_H265,
+.queue_flags  = VK_QUEUE_VIDEO_DECODE_BIT_KHR,
 .decode_op= VK_VIDEO_CODEC_OPERATION_DECODE_H265_BIT_KHR,
 .ext_props = {
 .extensionName = VK_STD_VULKAN_VIDEO_CODEC_H265_DECODE_EXTENSION_NAME,
-- 
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] configure: add option to statically link to libvulkan

[Lynne via ffmpeg-devel]

This may be useful in weird setups and on platforms where
static linking to libvulkan is supported.

libplacebo also has this fallback.
---
 configure| 7 ++-
 libavutil/hwcontext_vulkan.c | 9 +
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index ec99890f3d..0e599050c7 100755
--- a/configure
+++ b/configure
@@ -363,6 +363,7 @@ External library support:
   --disable-vdpau  disable Nvidia Video Decode and Presentation API 
for Unix code [autodetect]
   --disable-videotoolbox   disable VideoToolbox code [autodetect]
   --disable-vulkan disable Vulkan code [autodetect]
+  --enable-vulkan-static   statically link to libvulkan [no]
 
 Toolchain options:
   --arch=ARCH  select architecture [$arch]
@@ -1987,6 +1988,7 @@ EXTERNAL_LIBRARY_LIST="
 openssl
 pocketsphinx
 vapoursynth
+vulkan_static
 "
 
 HWACCEL_AUTODETECT_LIBRARY_LIST="
@@ -7381,7 +7383,10 @@ enabled vdpau &&
 enabled vdpau &&
 check_lib vdpau_x11 "vdpau/vdpau.h vdpau/vdpau_x11.h" 
vdp_device_create_x11 -lvdpau -lX11
 
-if enabled vulkan; then
+if enabled_all vulkan vulkan_static; then
+check_pkg_config vulkan "vulkan >= 1.3.277" "vulkan/vulkan.h" "defined 
VK_VERSION_1_3" ||
+check_lib vulkan "vulkan/vulkan.h" vkGetInstanceProcAddr -lvulkan
+elif enabled vulkan; then
 check_pkg_config_header_only vulkan "vulkan >= 1.3.277" "vulkan/vulkan.h" 
"defined VK_VERSION_1_3" ||
 check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) 
|| (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 277)"
 fi
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index d32a685383..bc7c258ebb 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -533,11 +533,19 @@ static int vkfmt_from_pixfmt2(AVHWDeviceContext *dev_ctx, 
enum AVPixelFormat p,
 return AVERROR(EINVAL);
 }
 
+#if CONFIG_VULKAN_STATIC
+VKAPI_ATTR PFN_vkVoidFunction VKAPI_CALL vkGetInstanceProcAddr(VkInstance 
instance,
+   const char 
*pName);
+#endif
+
 static int load_libvulkan(AVHWDeviceContext *ctx)
 {
 VulkanDevicePriv *p = ctx->hwctx;
 AVVulkanDeviceContext *hwctx = &p->p;
 
+#if CONFIG_VULKAN_STATIC
+hwctx->get_proc_addr = vkGetInstanceProcAddr;
+#else
 static const char *lib_names[] = {
 #if defined(_WIN32)
 "vulkan-1.dll",
@@ -563,6 +571,7 @@ static int load_libvulkan(AVHWDeviceContext *ctx)
 }
 
 hwctx->get_proc_addr = (PFN_vkGetInstanceProcAddr)dlsym(p->libvulkan, 
"vkGetInstanceProcAddr");
+#endif /* CONFIG_VULKAN_STATIC */
 
 return 0;
 }
-- 
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] [PATCH] avfilter/vf_scale: remove systematic PAL8 hack

[Niklas Haas]

On Wed, 18 Dec 2024 02:32:07 +0100 Michael Niedermayer  
wrote:
> Hi
>
> On Tue, Dec 17, 2024 at 10:31:42AM +0100, Niklas Haas wrote:
> > On Tue, 17 Dec 2024 01:48:02 +0100 Michael Niedermayer 
> >  wrote:
> > > Hi
> > >
> > > On Mon, Dec 16, 2024 at 02:57:53PM +0100, Niklas Haas wrote:
> > > > From: Niklas Haas 
> > > >
> > > > This is not a good way of generating a PAL8 output.
> > >
> > > of course not
> > >
> > > but this breaks fate and features
> >
> > It doesn't really break a feature because we have a better replacement 
> > already
> > included in libavfilter, IMO.
>
> swscale could convert to pal8 before, it cant after the patch.
> So it lost a feature and breaks users code unless iam missing
> something ?

It is worth pointing out that *libswscale* does not directly output PAL8;
this rather is (and always was) handled by vf_scale. So in some sense, this
functionality already depends on libavfilter.

That said, I do agree that simply regressing existing use cases should not
be done without some sort of mechanism for automatically invoking the proper
replacement.

I will retract this patch for now, then, and put the corresponding issue on
hold. I think that a full discussion of how to handle this better will have
to wait until we have a better dither handling inside swscale.

>
> swscale is not using libavfilter to provide this
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you think the mosad wants you dead since a long time then you are either
> wrong or dead since a long time.
> ___
> 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] vulkan_decode: support software-defined decoders

[Lynne via ffmpeg-devel]

On 18/12/2024 20:13, Anton Khirnov wrote:

Quoting Lynne via ffmpeg-devel (2024-12-18 10:07:51)

vulkan_decode: support software-defined decoders
---
  libavcodec/vulkan_decode.c | 118 +++--
  libavcodec/vulkan_decode.h |   8 +++
  2 files changed, 83 insertions(+), 43 deletions(-)


This could really use some more explanation.


Forgot to write the commit message. Amended with the following:

> This commit allows the existing decode infrastructure to be used by
> non-native Vulkan hwaccels, such as purely compute-based
> implementations, or hybrid CPU-GPU implementations.
> Using the existing infrastructure allows to deduplicate large chunks
> of management, initialization, and thread context synchronization
> code.

The code using it is still largely untested, so it may change with the 
next version I post, but nothing major - this mostly if()s out any 
native Vulkan decode calls from init.
Posting this because the changes to frame_params+init were too obtrusive 
to rebase this piece of code on top.


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/iamf_writer: fix setting num_samples_per_frame for OPUS

[James Almer]

As per section 3.11.1 of the IAMF spec, the sample rate used in Codec Config
for Opus shall be 48kHz, regardless of the original sample rate used during
encoding.

Signed-off-by: James Almer 
---
 libavformat/iamf_writer.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/libavformat/iamf_writer.c b/libavformat/iamf_writer.c
index f15dabcb3e..467f839baf 100644
--- a/libavformat/iamf_writer.c
+++ b/libavformat/iamf_writer.c
@@ -112,9 +112,17 @@ static int fill_codec_config(IAMFContext *iamf, const 
AVStreamGroup *stg,
 int j, ret = 0;
 
 codec_config->codec_id = st->codecpar->codec_id;
-codec_config->sample_rate = st->codecpar->sample_rate;
 codec_config->codec_tag = st->codecpar->codec_tag;
-codec_config->nb_samples = st->codecpar->frame_size;
+switch (codec_config->codec_id) {
+case AV_CODEC_ID_OPUS:
+codec_config->sample_rate = 48000;
+codec_config->nb_samples = av_rescale(st->codecpar->frame_size, 48000, 
st->codecpar->sample_rate);
+break;
+default:
+codec_config->sample_rate = st->codecpar->sample_rate;
+codec_config->nb_samples = st->codecpar->frame_size;
+break;
+}
 populate_audio_roll_distance(codec_config);
 if (st->codecpar->extradata_size) {
 codec_config->extradata = av_memdup(st->codecpar->extradata, 
st->codecpar->extradata_size);
@@ -183,9 +191,9 @@ static int add_param_definition(IAMFContext *iamf, 
AVIAMFParamDefinition *param,
 }
 if (codec_config) {
 if (!param->duration)
-param->duration = codec_config->nb_samples;
+param->duration = av_rescale(codec_config->nb_samples, 
param->parameter_rate, codec_config->sample_rate);
 if (!param->constant_subblock_duration)
-param->constant_subblock_duration = codec_config->nb_samples;
+param->constant_subblock_duration = 
av_rescale(codec_config->nb_samples, param->parameter_rate, 
codec_config->sample_rate);
 }
 
 param_definition = av_mallocz(sizeof(*param_definition));
-- 
2.47.1

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

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

Re: [FFmpeg-devel] [PATCH 3/4] checkasm/sw_rgb: add tests for yuv2packed{1, 2, X}

[Michael Niedermayer]

On Mon, Dec 16, 2024 at 12:48:19PM +0100, Niklas Haas wrote:
> From: Niklas Haas 
> 
> ---
>  tests/checkasm/sw_rgb.c | 316 
>  1 file changed, 316 insertions(+)

seems breaking fate unless i forgot some patch

checkasm: using random seed 3108170821
Assertion (((r[Y1] + g[Y1] + b[Y1]) >> sh) & 0xFF) == 0xFF failed at 
libswscale/output.c:1615
Aborted (core dumped)
threads=1

thx

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

It is what and why we do it that matters, not just one of them.


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 1/4] checkasm/sw_scale: add assertion for hscale assumption

[Michael Niedermayer]

On Mon, Dec 16, 2024 at 12:48:17PM +0100, Niklas Haas wrote:
> From: Niklas Haas 
> 
> This code only checks hcScale. In practice this is not an issue because
> the function pointers should always be identical to hyScale for the same
> filter size.
> 
> Add an assertion just to make sure this assumption never regresses.
> 
> Signed-off-by: Niklas Haas 
> Sponsored-by: Sovereign Tech Fund
> ---
>  tests/checkasm/sw_scale.c | 1 +
>  1 file changed, 1 insertion(+)

should be ok

thx

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

There will always be a question for which you do not know the correct answer.


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

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

Re: [FFmpeg-devel] [PATCH 17/17] swscale: remove primaries/trc change warning

[Michael Niedermayer]

Hi

On Thu, Dec 05, 2024 at 12:30:26PM +0100, Niklas Haas wrote:
> From: Niklas Haas 
> 
> This is now supported when using the new API.
> ---
>  libswscale/swscale.c | 11 ---
>  1 file changed, 11 deletions(-)

ok

thx

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

The difference between a dictatorship and a democracy is that every 4 years
the population together is allowed to provide 1 bit of input to the government.


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 16/17] swscale/graph: allow dynamically updating HDR metadata

[Michael Niedermayer]

On Mon, Dec 16, 2024 at 12:17:37PM +0100, Niklas Haas wrote:
> From: Niklas Haas 
> 
> Without triggering a full graph reinit.
> ---
>  libswscale/graph.c | 21 -
>  libswscale/graph.h | 12 +---
>  libswscale/utils.h |  6 ++
>  3 files changed, 35 insertions(+), 4 deletions(-)

should be ok

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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 17/17] swscale: remove primaries/trc change warning

[Michael Niedermayer]

On Thu, Dec 19, 2024 at 04:58:05AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Thu, Dec 05, 2024 at 12:30:26PM +0100, Niklas Haas wrote:
> > From: Niklas Haas 
> > 
> > This is now supported when using the new API.
> > ---
> >  libswscale/swscale.c | 11 ---
> >  1 file changed, 11 deletions(-)
> 
> ok

that was supposed to be a reply to v2 :)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.


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] avcodec/cbs_av1: fix variable shadowing in cbs_av1_split_fragment()

[Marth64]

header is previously declared as an int argument then
shadowed in the scope of the loop as a AV1RawOBUHeader.

Signed-off-by: Marth64 
---
 libavcodec/cbs_av1.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index be086b81cb..fea079379b 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -728,16 +728,16 @@ static int cbs_av1_split_fragment(CodedBitstreamContext 
*ctx,
 }
 
 while (size > 0) {
-AV1RawOBUHeader header;
+AV1RawOBUHeader obu_header;
 uint64_t obu_size;
 
 init_get_bits(&gbc, data, 8 * size);
 
-err = cbs_av1_read_obu_header(ctx, &gbc, &header);
+err = cbs_av1_read_obu_header(ctx, &gbc, &obu_header);
 if (err < 0)
 goto fail;
 
-if (header.obu_has_size_field) {
+if (obu_header.obu_has_size_field) {
 if (get_bits_left(&gbc) < 8) {
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid OBU: fragment "
"too short (%"SIZE_SPECIFIER" bytes).\n", size);
@@ -748,7 +748,7 @@ static int cbs_av1_split_fragment(CodedBitstreamContext 
*ctx,
 if (err < 0)
 goto fail;
 } else
-obu_size = size - 1 - header.obu_extension_flag;
+obu_size = size - 1 - obu_header.obu_extension_flag;
 
 pos = get_bits_count(&gbc);
 av_assert0(pos % 8 == 0 && pos / 8 <= size);
@@ -763,7 +763,7 @@ static int cbs_av1_split_fragment(CodedBitstreamContext 
*ctx,
 goto fail;
 }
 
-err = ff_cbs_append_unit_data(frag, header.obu_type,
+err = ff_cbs_append_unit_data(frag, obu_header.obu_type,
   data, obu_length, frag->data_ref);
 if (err < 0)
 goto fail;
-- 
2.34.1

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

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

Re: [FFmpeg-devel] [PATCH] Fix crash when trying to get a fragment time for a non-existing fragment

[Marth64]

Will push in a few days
___
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] [ANNOUNCE] upcoming vote: CC election

[Michael Niedermayer]

Hi Marth64

On Thu, Dec 05, 2024 at 12:39:49PM -0600, Marth64 wrote:
> I volunteer. I have no revolutionary agenda or financial skin in this game,
> and my current career does not intersect with A/V. I have been generally
> reading the mailing list since March 2023. I can provide the following
> services,
> 
> 1) Being an effective de-escalator and diplomat. There are bursts of
> tension I notice that can hurt morale. Most but not all of the tension can
> probably be talked through, socialized better, or worked out over some
> other medium such as slides or voice calls. I am recognized for this
> ability by my peers in other experiences.
> 
> 2) Fostering teamwork and collaboration by pushing broken conversations
> toward a solution or middle ground and providing feedback to help improve
> habits of bad or emotional communication. Sometimes that means being a
> sounding board and absorbing the heat and I am able to handle that.
> 
> 3) Welcoming and encouraging new contributors and professional/polite
> constructive criticisms. Conversely, identifying sources of toxicity (which
> exist in any team) and helping understand their root cause. If
> uncomfortable calls need to be made, advocating for the appropriate voting
> and action so that something is done and things can be “unstuck.”

can you maybe provide a few more details so I and people know better
how you would handle concrete examples, here are some:

1a. Prior context:
For a long time FFmpeg booths where organized by various FFmpeg developers
like Thilo but also others. They where always announced publically, they
surely had a touch of hobbyists and a "non professional" community

On NAB 2023 theres a booth paid by VideoLabs, with VideoLabs money to promote 
consulting on open source projects.
it used the FFmpeg name and logo. Without the FFmpeg community knowing about it 
or approving it.
They gave out videolabs buisness cards
Kieran and jb where the 2 people from FFmpeg associated with this booth.

Thilo organizes a FFmpeg booth on NAB 2024 (with GPAC)
He announces it in november 2023 see "FFmpeg at NAB 2024"

1b. The issues:
Since the booth was announced, thilo has been attacked by various people.
(but see the thread from back then yourself)
After the NAB 2024, more attacks rain down claiming the booth was not 
continously
manned by FFmpeg developers. Privately i also hear attacks against GPAC

Kieran later doxes Thilo by pointing to his street address related to the NAB 
2024 booth registration

The CC is informed about this but no action is taken that i remember.

I can also say that from personal communication, that other FFmpeg
developers associated with prior FFmpeg community boothes do not like
or support these hostilities, and it seems they are distancing themselfs
more from FFmpeg (which really could become a loss to the project)

I belive various complaints about the NAB 2024 booth are also raised on
VDD 2024 while not mentioning the NAB 2023 booth. Also nothing of this
is recorded.

While above is in the past, this situation is not resolved, what do you intend
to do about this ?
I belive community members should be able to announce and setup a FFmpeg
booth without fear that they are attacked or doxed.

(also one might say we need a set of clear rules for booths but i think this
 misses the problem entirely, this was not a disasgreement on rules. It was
 a commercial entity using FFmpeg IP behind the communities back. That started
 all this. It was not some community booth.)


2. and the most recent case
Nicolas was banned twice from FFmpeg by the CC, Kieran was never banned by
the CC

If you look at the thread "RFC: complete rework of s337m support"
Kieran provocates Nicolas,
Nicolas replies quite offensively to Kieran
Kieran reports this to the CC
and jb and ronald vote for a third ban of Nicolas,
ronald states that he would not have voted for a ban if Nicolas apologized.

Various people have been offensive, few have appologized, some people have been
banned repeatedly, many have never been banned.
Bans are often a bad solution but they should be used consistently.

I see a bias in the CCs decissions.
Some people say there is no bias. My first question, do you see a bias in
the CCs decissions ? (as a whole not based on what i write here)
And if so what do you plan to do about it ?

personally i think its really not good that the CC is made of people that
have close ties to thouse they "judge".

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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] [ANNOUNCE] upcoming vote: CC election

[Marth64]

PS - I am analyzing this as if I was an outsider.
I hold no grudges or negative feelings of anyone here,
I am thankful for being welcomed into this community.

My general philosophy is simple:

We can do better than this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: CC election

[Marth64]

Hi Michael,

> 2. and the most recent case
Continuing where I left off.

Let us analyze the s337m situation.
* Contributor shares significant work, as an RFC, in good faith
* A back and forth exchange happens with technical feedback and history
* Then, two senior contributors exchange inflammatory remarks,
presumably fueled by damaged relations
* Conversation was reported to CC but outcome could not be reconciled
with consistent enforcement

The s337 thread actually is irrelevant to the broader issue, but let
us pick it apart for a minute.
This particular thread should have been handled in two angles,

(1) The technical debate between the senior engineers should have been
weighed in on by TC
Yes, TC wasn't directly "summoned", but I imagine we can employ some
proactivity if we see a tense
technical discussion. The point of the TC, in my eyes, is to settle
deadlocked technical debates.
That is, as a collective response from the TC. Even if that is, "We
already talked about this once, case closed."

(2) The inflammatory remarks weren't moderated. This is the broader issue.
These types of interactions are different from some random person
coming on say, IRC, and offending people.
These are senior contributors in a deeply fueled discussion. No ban
will fix this.

In fact, saying the word ban, voting for a ban, or applying a ban
doesn't seem to do anything.
Based on the example you provided, even after 3 attempts some people don't care.
I'm not saying we jump to ban people. This is not a PHP video games forum.
But, waving the word "ban" should be used judiciously and may need to
be redefined, so that it is taken seriously.
Likewise, exercising and applying the ban should be taken seriously
too, especially when considering senior contributors.
Rubber voting/stamping bans and ignoring similar offenses is not
effective. I would hope a CC of 5 can work through this.

So we need to be more clear with a nudge of improvement and push: get
this toxicity off the ML.
Take it offline or refine your communication approach.

Folks should be encouraged to think,
(1) Is what you're saying adding value and even relevant to the conversation?
(2) If we're stuck in a bitter technical debate, can the TC help? (yes probably)
(3) Did I buffer my thoughts or react on impulse?
(4) Could I have ignored the "igniting" remark and focused on the
technical part of the discussion?

We have a Code of Conduct, does it need to be improved?
Do we need a pre-canned message to respond with when CoC is starting
to break in a conversation?

If people can't articulate with some basic guidelines of cordiality,
they shouldn't be emailing.
If a CC group of 5 can't see this without bias, then something is
wrong with the elected CC
or there should be an explanation. *Everyone* is biased subliminally,
whether we like it or not.
But we should put our best effort here to do better.

That said, I believe in forgiveness and second chances.
If the folks involved have had some legacy or current significant
contribution to the project,
IMO the CC should work with them collectively and, if it makes sense
in the situation, privately.
I am not saying CC should be a therapy group, but it hurts
productivity if talent leaves.
___
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/Makefile: include object files for image_vbn_pipe demuxer

[Peter Ross]

---
found to be missing as the result of exhaustive configure options
search. if image_vbn_pipe is selected on its own, build fails.

 libavformat/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 691738eb4b..074efc118a 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -310,6 +310,7 @@ OBJS-$(CONFIG_IMAGE_SGI_PIPE_DEMUXER) += img2dec.o 
img2.o
 OBJS-$(CONFIG_IMAGE_SVG_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_SUNRAST_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_TIFF_PIPE_DEMUXER)+= img2dec.o img2.o
+OBJS-$(CONFIG_IMAGE_VBN_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_WEBP_PIPE_DEMUXER)+= img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_XBM_PIPE_DEMUXER) += img2dec.o img2.o
 OBJS-$(CONFIG_IMAGE_XPM_PIPE_DEMUXER) += img2dec.o img2.o
-- 
2.45.2

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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 2/2] avcodec/Makefile: include aom_film_grain.o file for h264_sei component

[Peter Ross]

h264_sei depends on h2645_sei, which in turn depends on aom_film_grain for
ff_aom_uninit_film_grain_params()
---
 libavcodec/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index fd8e312fc8..350f50108a 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -110,7 +110,7 @@ OBJS-$(CONFIG_H264PARSE)   += h264_parse.o 
h264_ps.o h264data.o \
   h2645data.o h2645_parse.o h2645_vui.o
 OBJS-$(CONFIG_H264PRED)+= h264pred.o
 OBJS-$(CONFIG_H264QPEL)+= h264qpel.o
-OBJS-$(CONFIG_H264_SEI)+= h264_sei.o h2645_sei.o
+OBJS-$(CONFIG_H264_SEI)+= h264_sei.o h2645_sei.o 
aom_film_grain.o
 OBJS-$(CONFIG_HEVCPARSE)   += h2645data.o h2645_parse.o h2645_vui.o
 OBJS-$(CONFIG_HEVC_SEI)+= h2645_sei.o aom_film_grain.o \
   dynamic_hdr_vivid.o
-- 
2.45.2

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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] [ANNOUNCE] upcoming vote: CC election

[Kieran Kunhya via ffmpeg-devel]

> 1a. Prior context:
> For a long time FFmpeg booths where organized by various FFmpeg developers
> like Thilo but also others. They where always announced publically, they
> surely had a touch of hobbyists and a "non professional" community
>
> On NAB 2023 theres a booth paid by VideoLabs, with VideoLabs money to promote 
> consulting on open source projects.
> it used the FFmpeg name and logo. Without the FFmpeg community knowing about 
> it or approving it.
> They gave out videolabs buisness cards
> Kieran and jb where the 2 people from FFmpeg associated with this booth.

I was not associated with this booth, I merely carried some items to
assist those constructing. Thilo was present on this booth too.

> Thilo organizes a FFmpeg booth on NAB 2024 (with GPAC)
> He announces it in november 2023 see "FFmpeg at NAB 2024"

The fact the booth was with GPAC was not announced.

> 1b. The issues:
> Since the booth was announced, thilo has been attacked by various people.
> (but see the thread from back then yourself)
> After the NAB 2024, more attacks rain down claiming the booth was not 
> continously
> manned by FFmpeg developers. Privately i also hear attacks against GPAC
>
> Kieran later doxes Thilo by pointing to his street address related to the NAB 
> 2024 booth registration

This is public information on the NAB website:
https://nab24.mapyourshow.com/8_0/floorplan/?hallID=W&selectedBooth=W4232

It's important for the community to know what address is associated
with the booth.

> 2. and the most recent case
> Nicolas was banned twice from FFmpeg by the CC, Kieran was never banned by
> the CC
>
> If you look at the thread "RFC: complete rework of s337m support"
> Kieran provocates Nicolas,
> Nicolas replies quite offensively to Kieran
> Kieran reports this to the CC
> and jb and ronald vote for a third ban of Nicolas,
> ronald states that he would not have voted for a ban if Nicolas apologized.
>
> Various people have been offensive, few have appologized, some people have 
> been
> banned repeatedly, many have never been banned.
> Bans are often a bad solution but they should be used consistently.
>
> I see a bias in the CCs decissions.
> Some people say there is no bias. My first question, do you see a bias in
> the CCs decissions ? (as a whole not based on what i write here)
> And if so what do you plan to do about it ?

But your opinions in this thread are not biased and are factual?

Reporting this thread to CC.

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] [ANNOUNCE] upcoming vote: CC election

[Marth64]

Hi Michael,

> can you maybe provide a few more details so I and people know better
> how you would handle concrete examples, here are some:
Yes, sure.

Let us start with the booths.

Unpacking this one based on information provided above and what I
found in archives,

Statement #1 (NAB 2023)

* Trademarked FFmpeg branding was used by a different organization
without clear authorization.
* There was no visible process with the FFmpeg community (GA)
approving the IP use.
* Two or more contributors were present at the booth, resulting in a
mixed image of brand ownership.

Statement #2 (NAB 2024)

* Booth announced in Nov 2023 with "anonymous corporate sponsorship"
and vague expense process.
* There was a brief, heated exchange on the ML about the source of
funding, but the booth was opened anyway.
* FFmpeg contributors who passed by the booth questioned its
legitimacy due to seeing nobody.
* Ultimately the booth was revealed to be staffed but the thread
exploded due to the initial disagreement.

There are two problems in both situations.

*** Problem 1 ***
First of all, there is a logistics issue. There needs to be a
conference/booth registry of sorts
with a crystal clear approval workflow. This project appears to have
outgrown the casualty
of simply email dropping "a booth will occur" and likewise deserves
better than to have
an unauthorized/unsocialized booth occurs. We need a registry process.

Practically I am talking about a simple registration process here.
This can literally be a word processing document or spreadsheet. I
don't really care.
We do not need to go write code or build bespoke solutions for this.
But it needs to be a more material artifact than an email chain. It is
two steps:

(1) Initiate request with a documented form:
- Owner of this registration request?
- Date/time of booth?
- Location?
- Justification?
- Source of booth expenses?
- Source of travel expenses?
- Who from the community will staff the booth?
- ...

(2) Get approvals from whoever the GA delegates to approve booths
We can and need to figure out who can give this authoritative
signature, AKA "approvers".
This can be a majority GA vote, CC+TC combined, trademark owner, fund
managers, or all of the above.
And if these options don't find a majority liking then we need an RFC
to decide who.
Ideally it would be a frictionless process and not have too many hands
on the pot.

I would expect these approvers to apply prudent judgement when
evaluating the requests.
Then they sign the form with a yes/no.

People can still steal the IP and go use it in an unauthorized way.
But now, we can at least build an authoritative written data record of
what IS authorized.
By drying this out to a form and elected group of approvers, we lift
the emotion out of it,
and we have formal documentation.

More importantly, we also build a process rather than melt down in
emails. Which leads me to...

*** Problem 2 ***

The second issue is professionalism. Yes, this is an open source
community. Speak free and have fun.
But I imagine we are all adults and should apply constructive candor
to our responses.
If we look back at the aforementioned two NAB 2024 ML threads, it is
obvious they fell apart quickly.
Some of the responses there have zero business value and are
inappropriate to share on a public ML.

There could have been more proactive moderation in these emails.

For the trolling/inappropriate responses,
CC should have and in one instance did respond. But CC consequential
responses should be consistent
and could have been applied more broadly. There should be zero
tolerance for these types of responses.
Adverse action needs to be declared or people will keep doing it. Examples:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325781.html
(redirection/joke)
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325795.html
(hungover comment)
I have nothing against the engineers who wrote this.
But what value did these add really?

CC should have been empowered to step up and say, "we've got a toxic
discussion here,"
and really email is a painful way to resolve it. There could have been
virtual IRC meetings
or even phone calls to hash out the root issue. Instead it was left to
drag on and on.
This is fine for code reviews. This is BAD for building positively
thinking communities.

I will write in a following email about the banning/bias (most recent case)
shortly, after I read the threads again.
___
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] [ANNOUNCE] upcoming vote: CC election

[compn]

On Thu, 19 Dec 2024 03:22:46 +0100, Michael Niedermayer wrote:

i think we need to have a separate mailing list to talk about non
development stuff.

i think there are a lot of people who wish to contribute to ffmpeg and
develop on ffmpeg but they dont care about booths or which dev said
what to what other dev.

> For a long time FFmpeg booths

as for booth discussion i think no one is ever going to apologize one
way or the other. so just ignore it and move on.

-compn
___
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/Makefile: add iso_writer golomb_tab from shared library dependency

[James Almer]

On 12/18/2024 5:17 PM, Peter Ross wrote:

---
  libavformat/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index dd96bf7ba8..a6935ad244 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -728,7 +728,7 @@ OBJS-$(CONFIG_LIBZMQ_PROTOCOL)   += libzmq.o
  
  # Objects duplicated from other libraries for shared builds

  SHLIBOBJS+= log2_tab.o to_upper4.o
-SHLIBOBJS-$(CONFIG_ISO_MEDIA)+= mpegaudiotabs.o
+SHLIBOBJS-$(CONFIG_ISO_WRITER)   += golomb_tab.o mpegaudiotabs.o


Why are you changing the module? mpegaudiotabs.o should remain for 
CONFIG_ISO_MEDIA, seeing it's used by a demuxer function in isom.c


LGTM otherwise.


  SHLIBOBJS-$(CONFIG_FLV_MUXER)+= mpeg4audio_sample_rates.o
  SHLIBOBJS-$(CONFIG_HLS_DEMUXER)  += ac3_channel_layout_tab.o
  SHLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER)+= jpegxl_parse.o


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




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

Re: [FFmpeg-devel] [PATCH] avformat/Makefile: add iso_writer golomb_tab from shared library dependency

[Peter Ross]

On Wed, Dec 18, 2024 at 05:21:33PM -0300, James Almer wrote:
> On 12/18/2024 5:17 PM, Peter Ross wrote:
> > ---
> >   libavformat/Makefile | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > index dd96bf7ba8..a6935ad244 100644
> > --- a/libavformat/Makefile
> > +++ b/libavformat/Makefile
> > @@ -728,7 +728,7 @@ OBJS-$(CONFIG_LIBZMQ_PROTOCOL)   += libzmq.o
> >   # Objects duplicated from other libraries for shared builds
> >   SHLIBOBJS+= log2_tab.o to_upper4.o
> > -SHLIBOBJS-$(CONFIG_ISO_MEDIA)+= mpegaudiotabs.o
> > +SHLIBOBJS-$(CONFIG_ISO_WRITER)   += golomb_tab.o mpegaudiotabs.o
> 
> Why are you changing the module? mpegaudiotabs.o should remain for
> CONFIG_ISO_MEDIA, seeing it's used by a demuxer function in isom.c

it should just be:

+SHLIBOBJS-$(CONFIG_ISO_WRITER)   += golomb_tab.o

> LGTM otherwise.

fixed locally. i will push shortly.

also just ran an exhaustive search with `./configure --disable-all 
--enable-$x=$y`
and found a few similar issues.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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 03/17] swscale/utils: set static/implied HDR metadata

[Michael Niedermayer]

Hi

On Mon, Dec 16, 2024 at 12:17:24PM +0100, Niklas Haas wrote:
> From: Niklas Haas 
> 
> Provide default values for the fields added in the previous commit.
> ---
>  libswscale/utils.c | 17 +
>  1 file changed, 17 insertions(+)

LGTM

thx

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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 02/17] swscale/utils: add HDR metadata to SwsFormat

[Michael Niedermayer]

Hi


On Mon, Dec 16, 2024 at 12:17:23PM +0100, Niklas Haas wrote:
[...]
> diff --git a/libswscale/utils.h b/libswscale/utils.h
> index 4d204ef6cc..52b1e67644 100644
> --- a/libswscale/utils.h
> +++ b/libswscale/utils.h
> @@ -21,26 +21,55 @@
>  #ifndef SWSCALE_UTILS_H
>  #define SWSCALE_UTILS_H
>  
> +#include "libavutil/csp.h"
>  #include "libavutil/pixdesc.h"
>  
>  #include "swscale.h"
>  
> +/* Like av_cmp_q but considers x/0 == y/0 */
> +static inline int ff_q_equal(const AVRational a, const AVRational b)
> +{
> +return (!a.den && !b.den) || !av_cmp_q(a, b);
> +}

if thats true for all cases then ok

feels a little odd to me that -inf == NaN == +inf

thx

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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