AUR AI Reviewer

Review Results

Version #2011 of ffmpeg-full · commit b42dedd1bccb · status Reviewed

Risk 0/5 · Safe .SRCINFO
Result #1576

Comment

The change is a routine version bump in .SRCINFO from ffmpeg 8.1.2 to 9.0, with corresponding checksum and dependency metadata updates. I do not see any new sources from untrusted locations, no build-time network behavior introduced by this metadata-only diff, and no install-script or unit-file changes. The added/removed makedepends/depends entries are consistent with the PKGBUILD’s current ffmpeg 9.0 configuration. Risk is therefore minimal.

@@ -1,7 +1,7 @@
 pkgbase = ffmpeg-full
 	pkgdesc = Complete solution to record, convert and stream audio and video (all possible features including libfdk-aac)
-	pkgver = 8.1.2
-	pkgrel = 2
+	pkgver = 9.0
+	pkgrel = 1
 	url = https://ffmpeg.org/
 	arch = x86_64
 	license = LicenseRef-nonfree-and-unredistributable
Risk 0/5 · Safe .SRCINFO
Result #1577

Comment

The change only adds two build-time dependencies in .SRCINFO: glslang and spirv-headers, and removes libomxil-bellagio from makedepends. This is a metadata-only update with no evidence of new network fetches, install-time scripts, privilege escalation, or suspicious sources. The added dependencies are standard upstream build inputs for FFmpeg GPU/Vulkan-related features and do not themselves indicate a security issue. No red flags are visible in the provided hunk.

@@ -12,12 +12,13 @@ pkgbase = ffmpeg-full
 	makedepends = decklink-sdk
 	makedepends = ffnvcodec-headers
 	makedepends = git
+	makedepends = glslang
 	makedepends = gmp
 	makedepends = libgl
-	makedepends = libomxil-bellagio
 	makedepends = lv2
 	makedepends = nasm
 	makedepends = opencl-headers
+	makedepends = spirv-headers
 	makedepends = vulkan-headers
 	depends = alsa-lib
 	depends = aom
Risk 0/5 · Safe .SRCINFO
Result #1578

Comment

The change only removes a dependency declaration (`celt`) from .SRCINFO. This is a metadata-only adjustment with no code execution, no new sources, no privilege changes, and no packaging/install-script behavior. The main impact is potential build/runtime dependency mismatch if PKGBUILD still requires celt, but that is a correctness issue rather than a security concern. No malicious indicators are present in the provided diff.

@@ -25,7 +26,6 @@ pkgbase = ffmpeg-full
 	depends = avisynthplus
 	depends = bzip2
 	depends = cairo
-	depends = celt
 	depends = chromaprint-fftw
 	depends = codec2
 	depends = dav1d
Risk 0/5 · Safe .SRCINFO
Result #1579

Comment

The change is limited to .SRCINFO metadata and does not introduce any executable code or packaging logic changes. The updated entries track a new upstream ffmpeg release, refreshed checksums, and dependency metadata adjustments (adding glslang/spirv-headers to makedepends and dropping glslang/celt/libomxil-bellagio from the recorded dependency set). I do not see any security red flags in this diff: sources remain HTTPS, no new unpinned VCS source was added, and there are no install-script or build-script changes in the reviewed hunk. Risk is therefore minimal.

@@ -37,7 +37,6 @@ pkgbase = ffmpeg-full
 	depends = fribidi
 	depends = glib2
 	depends = glibc
-	depends = glslang
 	depends = gnutls
 	depends = gsm
 	depends = harfbuzz
Risk 0/5 · Safe .SRCINFO
Result #1580

Comment

The change only bumps upstream source versions in .SRCINFO: ffmpeg from 8.1.2 to 9.0 and whisper.cpp from 1.9.1 to 1.9.2. The URLs remain HTTPS and point to the official upstream project locations, with no new build-time fetching, scripts, or privilege-related artifacts introduced by this diff. I don’t see any supply-chain red flags in the provided hunk itself. Note that .SRCINFO is metadata only; the actual PKGBUILD and any accompanying patches would need separate review for integrity or malicious behavior, but this specific change is low risk.

@@ -154,10 +153,10 @@ pkgbase = ffmpeg-full
 	provides = libswscale.so
 	provides = libswresample.so
 	conflicts = ffmpeg
-	source = https://ffmpeg.org/releases/ffmpeg-8.1.2.tar.xz
-	source = https://ffmpeg.org/releases/ffmpeg-8.1.2.tar.xz.asc
+	source = https://ffmpeg.org/releases/ffmpeg-9.0.tar.xz
+	source = https://ffmpeg.org/releases/ffmpeg-9.0.tar.xz.asc
 	source = git+https://github.com/lensfun/lensfun.git
-	source = https://github.com/ggml-org/whisper.cpp/archive/v1.9.1/whisper.cpp-1.9.1.tar.gz
+	source = https://github.com/ggml-org/whisper.cpp/archive/v1.9.2/whisper.cpp-1.9.2.tar.gz
 	source = 010-ffmpeg-add-svt-hevc.patch
 	source = 020-ffmpeg-add-svt-hevc-docs-g4181c9e.patch::https://raw.githubusercontent.com/OpenVisualCloud/SVT-HEVC/4181c9ee0611baefb40b4c0ed10023cfd837d522/ffmpeg_plugin/0002-doc-Add-libsvt_hevc-encoder-docs.patch
 	source = 030-ffmpeg-add-svt-vp9.patch
Risk 0/5 · Safe .SRCINFO
Result #1581

Comment

The change only updates several SHA256 checksums in .SRCINFO for existing source entries. There is no evidence of new sources, URL changes, build-script execution, privilege escalation, or packaging behavior changes in this diff hunk. On its face this is an integrity-metadata refresh, not a security-relevant code change. I did not see any indication that the package is now pulling from a different location or introducing an untrusted artifact based on this hunk alone.

@@ -166,15 +165,15 @@ pkgbase = ffmpeg-full
 	source = 060-ffmpeg-whisper.cpp-fix-pkgconfig.patch
 	source = LICENSE
 	validpgpkeys = FCF986EA15E6E293A5644F10B4322F04D67658D8
-	sha256sums = 464beb5e7bf0c311e68b45ae2f04e9cc2af88851abb4082231742a74d97b524c
+	sha256sums = 7f607a00dd0d28a729d5a4811205812eef01cf6ef6155025febb6f36a9062d52
 	sha256sums = SKIP
 	sha256sums = SKIP
-	sha256sums = 147267177eef7b22ec3d2476dd514d1b12e160e176230b740e3d1bd600118447
-	sha256sums = ff6dabc3cbef98d22cc8f081343d5c66b2564b3a898c2dbcc88baa5017d80232
+	sha256sums = a6abd064fcca8b85e794d205abf328c522e9451db43a3eadc178b883b7d0e9cd
+	sha256sums = e6fdcb8446b0a0c0967f125d2de5084a5bdb418a1a6608f808cff2c97fc9bd6a
 	sha256sums = a164ebdc4d281352bf7ad1b179aae4aeb33f1191c444bed96cb8ab333c046f81
-	sha256sums = 73e516bd771024f100983d0b7a5d43b49fd1e992c83e6caec445b7338e79e8c2
-	sha256sums = 95223dda645c15b3daf79cd4d55df5d4ac46207f749973396bb761b743586ed6
-	sha256sums = 1bbd783da8483e2cffe99715125dddbd88c81ae36f28eee5ae7df5705c448077
+	sha256sums = cc80568f7dab2094f4f3bede6d0f068f217161f924915b067b0d287cf53b0849
+	sha256sums = cd1aa93e78800247b4516a01ef391106acb362957bd1e56f85d64906343cddac
+	sha256sums = 4a9a672f67cc0e5dd63bd7659f5a5198cd981e60bbbc1b9a63277758be6a7fdf
 	sha256sums = 98b3d28cbd13bb575c602785f6b8cb0b66ea3128ab5a3a82fc1645822320c136
 	sha256sums = 04a7176400907fd7db0d69116b99de49e582a6e176b3bfb36a03e50a4cb26a36
Risk 0/5 · Safe 010-ffmpeg-add-svt-hevc.patch
Result #1582

Comment

The change is a straightforward FFmpeg patch adding libsvthevc support and updating configure/Makefile glue. I do not see any supply-chain red flags: no new external downloads, no embedded binaries, no privilege changes, and the added source is a normal upstream-style C codec wrapper. The only notable edit is a context-line shift in the patch hunk and a small refactor to CODEC_PIXFMTS, which does not introduce new behavior beyond codec registration. Risk is low.

@@ -1,6 +1,6 @@
 --- a/configure
 +++ b/configure
-@@ -346,6 +346,7 @@ External library support:
+@@ -345,6 +345,7 @@ External library support:
    --enable-whisper         enable whisper filter [no]
    --disable-xlib           disable xlib [autodetect]
    --disable-zlib           disable zlib [autodetect]
Risk 0/5 · Safe 010-ffmpeg-add-svt-hevc.patch
Result #1583

Comment

The patch adds SVT-HEVC support to FFmpeg by wiring a new external library check, Makefile object, codec registration, and a new encoder wrapper source file. Based on the diff shown, this is a straightforward feature addition with no signs of network access, privilege escalation, persistence, or suspicious packaging behavior. The only notable change is the new libsvthevc dependency probe and codec implementation, which appears consistent with adding a legitimate upstream encoder wrapper. No obvious supply-chain or integrity red flags are present in the reviewed hunk.

@@ -8,7 +8,7 @@
  
    The following libraries provide various hardware acceleration features:
    --disable-amf            disable AMF video encoding code [autodetect]
-@@ -2090,6 +2091,7 @@ EXTERNAL_LIBRARY_LIST="
+@@ -2129,6 +2130,7 @@ EXTERNAL_LIBRARY_LIST="
      libssh
      libsvtav1
      libsvtjpegxs
Risk 0/5 · Safe 010-ffmpeg-add-svt-hevc.patch
Result #1584

Comment

The patch adds FFmpeg support for the SVT-HEVC encoder and updates build glue accordingly. I do not see any supply-chain red flags in this change: it only adds a new optional external-library integration, with no network access, no installer/persistence logic, no privilege changes, and no suspicious embedded binaries or scripts. The diff is limited to FFmpeg source/configuration and a new codec wrapper; the only notable change is a refactor to use CODEC_PIXFMTS, which is a normal internal API style update. Overall this looks low risk.

@@ -16,7 +16,7 @@
      libtensorflow
      libtesseract
      libtheora
-@@ -3845,6 +3847,7 @@ vapoursynth_demuxer_deps="vapoursynth"
+@@ -3903,6 +3905,7 @@ vapoursynth_demuxer_deps="vapoursynth"
  videotoolbox_suggest="coreservices"
  videotoolbox_deps="corefoundation coremedia corevideo VTDecompressionSessionDecodeFrame"
  videotoolbox_encoder_deps="videotoolbox VTCompressionSessionPrepareToEncodeFrames"
Risk 0/5 · Safe 010-ffmpeg-add-svt-hevc.patch
Result #1585

Comment

The patch adds support for the SVT-HEVC encoder in FFmpeg by wiring a new optional external library (`libsvthevc`) into configure, Makefile, and codec registration, plus adding the new upstream source file `libsvt_hevc.c`. I did not find any supply-chain red flags in the change itself: no network fetches, no shell execution, no privilege changes, and no suspicious install-time behavior. The new code is a straightforward codec wrapper around an external library and the patch only broadens build-time feature support. The only notable risk is the usual one for enabling an additional third-party codec dependency, but that is not inherently malicious and there is no evidence here of backdoor or persistence behavior.

@@ -24,17 +24,17 @@
  
  # demuxers / muxers
  ac3_demuxer_select="ac3_parser"
-@@ -7376,6 +7379,7 @@ enabled libspeex          && require_pkg_config libspeex speex speex/speex.h spe
+@@ -7442,6 +7445,7 @@ enabled libspeex          && require_pkg
  enabled libsrt            && require_pkg_config libsrt "srt >= 1.3.0" srt/srt.h srt_socket
  enabled libsvtav1         && require_pkg_config libsvtav1 "SvtAv1Enc >= 0.9.0" EbSvtAv1Enc.h svt_av1_enc_init_handle
  enabled libsvtjpegxs      && require_pkg_config libsvtjpegxs "SvtJpegxs >= 0.10.0" SvtJpegxsEnc.h svt_jpeg_xs_encoder_init
 +enabled libsvthevc        && require_pkg_config libsvthevc SvtHevcEnc EbApi.h EbInitHandle
  enabled libtensorflow     && require libtensorflow tensorflow/c/c_api.h TF_Version -ltensorflow
  enabled libtesseract      && require_pkg_config libtesseract tesseract tesseract/capi.h TessBaseAPICreate
- enabled libtheora         && require libtheora theora/theoraenc.h th_info_init -ltheoraenc -ltheoradec -logg
+ enabled libtheora         && { check_pkg_config libtheora theoraenc theora/theoraenc.h th_info_init ||
 --- a/libavcodec/Makefile
 +++ b/libavcodec/Makefile
-@@ -1227,6 +1227,7 @@ OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)       += libwebpenc_common.o libwebpenc_anim
+@@ -1224,6 +1224,7 @@ OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)
  OBJS-$(CONFIG_LIBX262_ENCODER)            += libx264.o
  OBJS-$(CONFIG_LIBX264_ENCODER)            += libx264.o
  OBJS-$(CONFIG_LIBX265_ENCODER)            += libx265.o
Risk 0/5 · Safe 010-ffmpeg-add-svt-hevc.patch
Result #1586

Comment

The patch adds SVT-HEVC support to FFmpeg by wiring a new external library dependency and a new encoder wrapper source file. The change is limited to build-system integration and codec registration; there are no signs of network access, privilege escalation, persistence, or bundled binaries. The only notable change is replacing an inline pixel-format array with CODEC_PIXFMTS in the new encoder definition, which is a normal FFmpeg API usage change. Based on the provided diff, this looks like a straightforward feature addition with low security risk.

@@ -44,7 +44,7 @@
  OBJS-$(CONFIG_LIBXEVD_DECODER)            += libxevd.o
 --- a/libavcodec/allcodecs.c
 +++ b/libavcodec/allcodecs.c
-@@ -844,6 +844,7 @@ extern const FFCodec ff_libxavs_encoder;
+@@ -830,6 +830,7 @@ extern const FFCodec ff_libxavs_encoder;
  extern const FFCodec ff_libxavs2_encoder;
  extern const FFCodec ff_libxvid_encoder;
  extern const FFCodec ff_libzvbi_teletext_decoder;
Risk 0/5 · Safe 010-ffmpeg-add-svt-hevc.patch
Result #1587

Comment

The change is a straightforward FFmpeg integration patch for SVT-HEVC. The only substantive code change in the hunk is replacing a manually constructed pixel-format array terminated with AV_PIX_FMT_NONE by the CODEC_PIXFMTS helper, which is a normal refactor and does not introduce new execution paths, network access, privilege changes, or packaging concerns. The rest of the diff is build-system wiring to enable the external library and add the new codec source file. I do not see any suspicious sources, embedded binaries, or post-install behavior in this change.

@@ -54,7 +54,7 @@
  extern const FFCodec ff_bintext_decoder;
 --- /dev/null
 +++ b/libavcodec/libsvt_hevc.c
-@@ -0,0 +1,586 @@
+@@ -0,0 +1,585 @@
 +/*
 +* Scalable Video Technology for HEVC encoder library plugin
 +*
Risk 0/5 · Safe 010-ffmpeg-add-svt-hevc.patch
Result #1588

Comment

The change is a small mechanical refactor in the ffmpeg patch for libsvt_hevc: it replaces an inline pixel-format array terminated with AV_PIX_FMT_NONE by the CODEC_PIXFMTS helper. The surrounding diff only adds SVT-HEVC support wiring in configure/Makefile/allcodecs and does not introduce any network access, privilege escalation, persistence, or suspicious packaging behavior. No malicious payload or integrity issue is evident in this hunk.

@@ -629,18 +629,14 @@
 +    FF_CODEC_ENCODE_CB(eb_encode_frame),
 +    .close          = eb_enc_close,
 +    .p.capabilities = AV_CODEC_CAP_DELAY,
-+    .p.pix_fmts     = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
-+                                                    AV_PIX_FMT_YUV420P10,
-+                                                    AV_PIX_FMT_YUV422P,
-+                                                    AV_PIX_FMT_YUV422P10,
-+                                                    AV_PIX_FMT_YUV444P,
-+                                                    AV_PIX_FMT_YUV444P10,
-+                                                    AV_PIX_FMT_NONE },
++    CODEC_PIXFMTS(AV_PIX_FMT_YUV420P,
++                  AV_PIX_FMT_YUV420P10,
++                  AV_PIX_FMT_YUV422P,
++                  AV_PIX_FMT_YUV422P10,
++                  AV_PIX_FMT_YUV444P,
++                  AV_PIX_FMT_YUV444P10),
 +    .p.priv_class   = &class,
 +    .defaults       = eb_enc_defaults,
 +    .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
 +    .p.wrapper_name = "libsvt_hevc",
 +};
--- 
-2.44.0
-
Risk 0/5 · Safe 030-ffmpeg-add-svt-vp9.patch
Result #1589

Comment

The change is a small patch-context adjustment plus a one-line refactor in the SVT-VP9 codec registration from an inline pixel-format array to the standard CODEC_PIXFMTS helper. I do not see any security-relevant behavior changes: no new sources, no network access, no privilege changes, no install-script or systemd impact, and no suspicious code paths introduced in the patch content shown. This appears to be a mechanical compatibility/maintenance edit only.

@@ -1,6 +1,6 @@
 --- a/configure
 +++ b/configure
-@@ -299,6 +299,7 @@ External library support:
+@@ -298,6 +298,7 @@ External library support:
    --enable-libvorbis       enable Vorbis en/decoding via libvorbis,
                             native implementation exists [no]
    --enable-libvpx          enable VP8 and VP9 de/encoding via libvpx [no]
Risk 0/5 · Safe 030-ffmpeg-add-svt-vp9.patch
Result #1590

Comment

The patch only updates line numbers in an existing ffmpeg configure/Makefile patch and changes the libsvt_vp9 codec registration from an inline pixel-format array to the standard CODEC_PIXFMTS(AV_PIX_FMT_YUV420P) macro. This is a mechanical refactor with no new sources, no build-time network access, no privilege changes, and no packaging/install-script impact. I did not see any security-relevant behavior introduced by this diff.

@@ -8,7 +8,7 @@
    --enable-libvvenc        enable H.266/VVC encoding via vvenc [no]
    --enable-libwebp         enable WebP encoding via libwebp [no]
    --enable-libx264         enable H.264 encoding via x264 [no]
-@@ -2103,6 +2104,7 @@ EXTERNAL_LIBRARY_LIST="
+@@ -2142,6 +2143,7 @@ EXTERNAL_LIBRARY_LIST="
      libvmaf
      libvorbis
      libvpx
Risk 0/5 · Safe 030-ffmpeg-add-svt-vp9.patch
Result #1591

Comment

The change is a straightforward patch update for FFmpeg’s SVT-VP9 integration: it adjusts line offsets, updates an extern declaration to match the codec definition style, and replaces an inline pixel-format array with the existing CODEC_PIXFMTS helper. I don’t see any added network access, privilege escalation, persistence, or other security-relevant behavior in this diff. The new source file content is the same feature implementation already present in the patch; this hunk only changes build-time plumbing and a minor API/style detail.

@@ -16,7 +16,7 @@
      libvvenc
      libwebp
      libxevd
-@@ -3827,6 +3829,7 @@ libvpx_vp8_decoder_deps="libvpx"
+@@ -3885,6 +3887,7 @@ libvpx_vp8_decoder_deps="libvpx"
  libvpx_vp8_encoder_deps="libvpx"
  libvpx_vp9_decoder_deps="libvpx"
  libvpx_vp9_encoder_deps="libvpx"
Risk 0/5 · Safe 030-ffmpeg-add-svt-vp9.patch
Result #1592

Comment

The change adds SVT-VP9 support to FFmpeg by introducing a new codec wrapper and wiring it into configure/Makefile/allcodecs. I do not see any supply-chain red flags in this patch: no network access, no embedded binaries, no privilege changes, and no install-script or systemd persistence behavior. The only substantive code change shown is a minor refactor from an explicit pixel-format array to the CODEC_PIXFMTS helper, which is not security-relevant. Overall this appears low risk.

@@ -24,7 +24,7 @@
  libvvenc_encoder_deps="libvvenc"
  libwebp_encoder_deps="libwebp"
  libwebp_anim_encoder_deps="libwebp"
-@@ -7423,6 +7426,7 @@ enabled libvpx            && {
+@@ -7490,6 +7493,7 @@ enabled libvpx            && {
      fi
  }
Risk 0/5 · Safe 030-ffmpeg-add-svt-vp9.patch
Result #1593

Comment

The provided hunk is a trivial context-line offset change in a patch file, with no functional code, build logic, or packaging behavior altered. It does not introduce network access, privilege escalation, persistence, or integrity risks. Based on this diff alone, the change is safe.

@@ -34,7 +34,7 @@
      enabled libwebp_encoder      && require_pkg_config libwebp "libwebp >= 0.2.0" webp/encode.h WebPGetEncoderVersion
 --- a/libavcodec/Makefile
 +++ b/libavcodec/Makefile
-@@ -1221,6 +1221,7 @@ OBJS-$(CONFIG_LIBVPX_VP8_DECODER)         += libvpxdec.o
+@@ -1218,6 +1218,7 @@ OBJS-$(CONFIG_LIBVPX_VP8_DECODER)         += libvpxdec.o
  OBJS-$(CONFIG_LIBVPX_VP8_ENCODER)         += libvpxenc.o
  OBJS-$(CONFIG_LIBVPX_VP9_DECODER)         += libvpxdec.o
  OBJS-$(CONFIG_LIBVPX_VP9_ENCODER)         += libvpxenc.o
Risk 0/5 · Safe 030-ffmpeg-add-svt-vp9.patch
Result #1594

Comment

The patch is a minimal build-time fix in an FFmpeg codec registration file: it changes the libvpx VP9 encoder declaration from non-const to const and adds the libsvt_vp9 encoder declaration. There are no signs of network access, privilege escalation, persistence, embedded binaries, or other supply-chain red flags in this hunk. The change is consistent with a type-correctness/ABI cleanup needed for the added SVT-VP9 support and does not alter runtime behavior beyond symbol declaration consistency.

@@ -44,9 +44,9 @@
  OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)       += libwebpenc_common.o libwebpenc_animencoder.o
 --- a/libavcodec/allcodecs.c
 +++ b/libavcodec/allcodecs.c
-@@ -830,6 +830,7 @@ extern const FFCodec ff_libvpx_vp8_encoder;
+@@ -816,6 +816,7 @@ extern const FFCodec ff_libvpx_vp8_encoder;
  extern const FFCodec ff_libvpx_vp8_decoder;
- extern FFCodec ff_libvpx_vp9_encoder;
+ extern const FFCodec ff_libvpx_vp9_encoder;
  extern const FFCodec ff_libvpx_vp9_decoder;
 +extern const FFCodec ff_libsvt_vp9_encoder;
  extern const FFCodec ff_libvvenc_encoder;
Risk 0/5 · Safe 030-ffmpeg-add-svt-vp9.patch
Result #1595

Comment

The change is a small FFmpeg integration patch for SVT-VP9. It adds a new external-library codec wrapper, updates configure/Makefile registration, and switches the pixel-format declaration to the standard CODEC_PIXFMTS helper. I do not see any supply-chain red flags: no network fetches, no embedded binaries, no privilege changes, and no install-script or systemd behavior. The diff is limited to build-time codec plumbing and a minor API-style cleanup in the new source file. Risk is therefore very low.

@@ -54,7 +54,7 @@
  extern const FFCodec ff_libwebp_anim_encoder;
 --- /dev/null
 +++ b/libavcodec/libsvt_vp9.c
-@@ -0,0 +1,701 @@
+@@ -0,0 +1,700 @@
 +/*
 +* Scalable Video Technology for VP9 encoder library plugin
 +*
Risk 0/5 · Safe 030-ffmpeg-add-svt-vp9.patch
Result #1596

Comment

The change is a small upstream-style code adjustment in the FFmpeg SVT-VP9 encoder wrapper: it replaces an inline pixel-format array with the CODEC_PIXFMTS helper macro. This does not introduce new sources, network access, privilege changes, persistence, or packaging/install-script behavior. The surrounding patch content is otherwise a straightforward feature addition for libsvt_vp9 integration. No security-relevant regression is evident from this hunk alone.

@@ -750,12 +750,8 @@
 +    .p.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS,
 +    .caps_internal    = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
 +                        FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP,
-+    .p.pix_fmts       = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
-+                                                    AV_PIX_FMT_NONE },
++    CODEC_PIXFMTS(AV_PIX_FMT_YUV420P),
 +    .p.priv_class     = &class,
 +    .defaults         = eb_enc_defaults,
 +    .p.wrapper_name   = "libsvt_vp9",
 +};
--- 
-2.50.1
-
Risk 0/5 · Safe 040-ffmpeg-add-av_stream_get_first_dts-for-chromium.patch
Result #1597

Comment

The patch only adds a small Chromium-specific accessor that exposes FFmpeg's internal `first_dts` field via a new public function and declaration. There are no signs of network access, privilege escalation, persistence, or other supply-chain red flags in this change. The implementation is a direct field getter and does not introduce executable build-time or install-time behavior. Risk is low, though the change does widen the public API surface slightly.

@@ -1,6 +1,6 @@
 --- a/libavformat/avformat.h
 +++ b/libavformat/avformat.h
-@@ -1178,6 +1178,10 @@ typedef struct AVStreamGroup {
+@@ -1229,6 +1229,10 @@ typedef struct AVStreamGroup {
  
  struct AVCodecParserContext *av_stream_get_parser(const AVStream *s);
Risk 0/5 · Safe 050-ffmpeg-fix-cuda-nvcc-with-gcc14.patch
Result #1598

Comment

The change only updates the line-number context in an existing patch file for ffmpeg's configure script; no payload, commands, URLs, or build logic changed. I see no security-relevant behavior introduced by this diff hunk itself. Risk is effectively nil for this change alone.

@@ -1,6 +1,6 @@
 --- a/configure
 +++ b/configure
-@@ -7112,7 +7112,7 @@ if [ -z "$nvccflags" ]; then
+@@ -7200,7 +7200,7 @@ if [ -z "$nvccflags" ]; then
      nvccflags=$nvccflags_default
  fi
Risk 0/5 · Safe PKGBUILD
Result #1599

Comment

The change is a routine version bump of ffmpeg-full (8.1.2 -> 9.0) plus a whisper.cpp update and dependency list adjustments. I do not see any new supply-chain red flags in the diff: sources remain HTTPS and pinned, no new build-time network fetches or shell execution patterns were introduced, and the package still builds from declared sources/patches. The dependency changes remove some runtime deps and move glslang/spirv-headers into makedepends, which is consistent with the removed ffmpeg feature flags. The only notable change is '-Wno-dev' -> '-Wno-author', which is unusual but not itself a security issue in this context. Overall this looks like a normal maintenance update with low risk.

@@ -2,10 +2,10 @@
 # Contributor: Iacopo Isimbaldi <isiachi@rhye.it>
 
 pkgname=ffmpeg-full
-pkgver=8.1.2
-pkgrel=2
+pkgver=9.0
+pkgrel=1
 _svt_hevc_ver='4181c9ee0611baefb40b4c0ed10023cfd837d522'
-_whispercpp_ver='1.9.1'
+_whispercpp_ver='1.9.2'
 pkgdesc='Complete solution to record, convert and stream audio and video (all possible features including libfdk-aac)'
 arch=('x86_64')
 url='https://ffmpeg.org/'
Risk 0/5 · Safe PKGBUILD
Result #1600

Comment

The diff only removes `celt` from `depends` and does not introduce any new code execution, network access, privilege escalation, or packaging-path changes. In the full PKGBUILD context, the package still builds from upstream tarballs and existing patches; this hunk merely drops a dependency and is not itself a security concern. No evidence of malicious behavior in this change.

@@ -17,7 +17,6 @@ depends=(
     'avisynthplus' # loaded on-demand by dlopen()
     'bzip2'
     'cairo'
-    'celt'
     'chromaprint-fftw'
     'codec2'
     'dav1d'
Risk 0/5 · Safe PKGBUILD
Result #1601

Comment

The change only removes `glslang` from the runtime depends list in PKGBUILD. This does not introduce any new code execution, network access, privilege escalation, or packaging integrity issue. It may affect optional FFmpeg functionality related to Vulkan/GLSL shader support, but that is a functional dependency change rather than a security concern. No suspicious sources, scripts, or install-time behavior are involved in this diff.

@@ -29,7 +28,6 @@ depends=(
     'fribidi'
     'glib2'
     'glibc'
-    'glslang'
     'gnutls'
     'gsm'
     'harfbuzz'
Risk 0/5 · Safe PKGBUILD
Result #1602

Comment

The change is low risk. It updates ffmpeg to a new upstream release and refreshes checksums, while adjusting build dependencies and configure flags to match the new feature set. I did not see any added network fetches, shell execution, privilege escalation, install-script changes, or suspicious external sources. The removed/added dependencies and flags (glslang/spirv-headers, dropping celt/libomxil-bellagio/omx-related options) look like ordinary packaging maintenance for upstream compatibility. No obvious supply-chain or persistence concerns in this diff hunk.

@@ -146,12 +144,13 @@ makedepends=(
     'decklink-sdk'
     'ffnvcodec-headers'
     'git'
+    'glslang'
     'gmp'
     'libgl'
-    'libomxil-bellagio'
     'lv2'
     'nasm'
     'opencl-headers'
+    'spirv-headers'
     'vulkan-headers')
 provides=(
     'ffmpeg'
Risk 0/5 · Safe PKGBUILD
Result #1603

Comment

The change only updates sha256 checksums for existing upstream source and patch files in PKGBUILD. I did not see any new sources, build steps, network fetches, privilege changes, or packaging logic changes in the provided hunk. The security impact is limited to integrity metadata for already-declared files, so there is no evident malicious behavior in this diff alone.

@@ -173,15 +172,15 @@ source=("https://ffmpeg.org/releases/ffmpeg-${pkgver}.tar.xz"{,.asc}
         '050-ffmpeg-fix-cuda-nvcc-with-gcc14.patch'
         '060-ffmpeg-whisper.cpp-fix-pkgconfig.patch'
         'LICENSE')
-sha256sums=('464beb5e7bf0c311e68b45ae2f04e9cc2af88851abb4082231742a74d97b524c'
+sha256sums=('7f607a00dd0d28a729d5a4811205812eef01cf6ef6155025febb6f36a9062d52'
             'SKIP'
             'SKIP'
-            '147267177eef7b22ec3d2476dd514d1b12e160e176230b740e3d1bd600118447'
-            'ff6dabc3cbef98d22cc8f081343d5c66b2564b3a898c2dbcc88baa5017d80232'
+            'a6abd064fcca8b85e794d205abf328c522e9451db43a3eadc178b883b7d0e9cd'
+            'e6fdcb8446b0a0c0967f125d2de5084a5bdb418a1a6608f808cff2c97fc9bd6a'
             'a164ebdc4d281352bf7ad1b179aae4aeb33f1191c444bed96cb8ab333c046f81'
-            '73e516bd771024f100983d0b7a5d43b49fd1e992c83e6caec445b7338e79e8c2'
-            '95223dda645c15b3daf79cd4d55df5d4ac46207f749973396bb761b743586ed6'
-            '1bbd783da8483e2cffe99715125dddbd88c81ae36f28eee5ae7df5705c448077'
+            'cc80568f7dab2094f4f3bede6d0f068f217161f924915b067b0d287cf53b0849'
+            'cd1aa93e78800247b4516a01ef391106acb362957bd1e56f85d64906343cddac'
+            '4a9a672f67cc0e5dd63bd7659f5a5198cd981e60bbbc1b9a63277758be6a7fdf'
             '98b3d28cbd13bb575c602785f6b8cb0b66ea3128ab5a3a82fc1645822320c136'
             '04a7176400907fd7db0d69116b99de49e582a6e176b3bfb36a03e50a4cb26a36')
 validpgpkeys=('FCF986EA15E6E293A5644F10B4322F04D67658D8')
Risk 0/5 · Safe PKGBUILD
Result #1604

Comment

The change is low risk. It only replaces a CMake warning suppression flag (-Wno-dev to -Wno-author) and updates package version/dependency metadata plus checksum values for the new upstream release. I do not see any new code execution, network access, privilege escalation, or packaging-path changes introduced by this diff hunk. The surrounding PKGBUILD still uses pinned HTTPS sources and local build/install steps under $pkgdir. No security-relevant behavior is added by this specific change.

@@ -206,7 +205,7 @@ build() {
         '-DBUILD_SHARED_LIBS:BOOL=OFF'
         '-DCMAKE_BUILD_TYPE:STRING=None'
         "-DCMAKE_INSTALL_PREFIX:PATH=${_stagingdir}"
-        '-Wno-dev')
+        '-Wno-author')
     
     # ffmpeg requires lensfun git master, but lensfun-git package wrongly installs its files to non-standard locations:
     # https://aur.archlinux.org/cgit/aur.git/commit/?h=lensfun-git&id=7b7a2d4890df59cde62c7dbfde3cefd7868a2707
Risk 0/5 · Safe PKGBUILD
Result #1605

Comment

The change only updates a comment explaining why whisper.cpp is built locally as a static library. It does not alter build commands, sources, dependencies, permissions, or install behavior. No security-relevant behavior is introduced by this diff hunk.

@@ -222,8 +221,8 @@ build() {
         -e 's/\(-llensfun\)/\1 -lglib-2.0 -lstdc++/' \
         -e '/Cflags: /s/$/ -DCONF_LENSFUN_STATIC/' "${_pkgconfigdir}/lensfun.pc"
     
-    # whisper.cpp AUR package conflicts with imagemagick at the time of writing
-    # building it locally as a static library for the time being, as imagemagick is a commonly used package (high usage in pkgstats)
+    # using whisper-cpp package from the official repositories will cause a circular dependency with ffmpeg,
+    # building it locally as a static library for the time being
     cmake -B build/whisper.cpp -S "whisper.cpp-${_whispercpp_ver}" \
         "${_cmake_opts[@]}" \
         -DWHISPER_BUILD_EXAMPLES:BOOL='OFF' \
Risk 0/5 · Safe PKGBUILD
Result #1606

Comment

The change is a one-line removal of `--enable-libcelt` from the FFmpeg build configuration. This reduces functionality but does not introduce any new code execution, network access, privilege escalation, persistence, or integrity risks. I found no security-relevant behavior in the diff itself.

@@ -272,7 +271,6 @@ build() {
         --enable-libbluray \
         --enable-libbs2b \
         --enable-libcaca \
-        --enable-libcelt \
         --enable-libcdio \
         --enable-libcodec2 \
         --enable-libdav1d \
Risk 0/5 · Safe PKGBUILD
Result #1607

Comment

The change only removes the `--enable-libglslang` configure flag from the FFmpeg build. This reduces functionality (Vulkan/GLSL shader support) but does not introduce any new code execution, network access, privilege escalation, persistence, or packaging integrity concerns. No suspicious sources, scripts, or install-time behavior are affected by this diff hunk.

@@ -285,7 +283,6 @@ build() {
         --enable-libfontconfig \
         --enable-libfreetype \
         --enable-libfribidi \
-        --enable-libglslang \
         --enable-libgme \
         --enable-libgsm \
         --enable-libharfbuzz \
Risk 0/5 · Safe PKGBUILD
Result #1608

Comment

The change only removes `--disable-libshaderc` from the FFmpeg configure flags, which means the package will now attempt to build with libshaderc support if the dependency is present. This is a build-time feature toggle, not an obvious supply-chain or persistence issue. I don't see any added network fetches, privilege changes, install-script behavior, or embedded binaries in this diff. The main impact is a broader dependency surface and potentially different codec support, but nothing here suggests malicious behavior or a security regression by itself.

@@ -322,7 +319,6 @@ build() {
         --enable-librsvg \
         --enable-librubberband \
         --enable-librtmp  \
-        --disable-libshaderc \
         --enable-libshine \
         --enable-libsmbclient \
         --enable-libsnappy \
Risk 0/5 · Safe PKGBUILD
Result #1609

Comment

The change only removes `--enable-omx` from the FFmpeg configure flags. This reduces functionality and does not introduce any new sources, build-time downloads, privilege changes, install-script behavior, or packaging-side persistence mechanisms. I found no security-relevant regression in this diff hunk.

@@ -390,7 +386,6 @@ build() {
         --enable-nvdec \
         --enable-nvenc \
         --disable-ohcodec \
-        --enable-omx \
         --enable-opencl \
         --enable-opengl \
         --enable-rkmpp \