Files
hyperframes/packages/aws-lambda/image/Dockerfile
T
Miguel Ángel bb19f342d3 build(aws-lambda): pinned native ffmpeg build for an arm64 Lambda image (#6062)
* build(aws-lambda): pinned native ffmpeg build for an arm64 Lambda image

One recipe, run per architecture on the Lambda Node 22 base it ships on. Codec
libraries link statically; glibc and GnuTLS stay dynamic, with the two libraries
the bare base lacks bundled beside the binaries. A check stage on the bare base
proves every encoder, decoder, filter and protocol the engine calls, and the
artifact cannot be produced without it. CI builds it on two ARM runners and
requires byte-identical tarballs.

* fix(aws-lambda): link GnuTLS dynamically in the arm64 ffmpeg build

With --static pkg-config flags, gnutls.pc names a libgmp.a from its own RPM build
tree and configure rejected GnuTLS. The codec libraries exist only as static
archives, so they still link statically. The recipe moves to image/, which will
also hold the video function image stage.

* fix(aws-lambda): build x265 for arm64 with the base image compiler

x265 builds its SVE2 kernels with -march=armv9-a, which gcc 11 rejects. Turn
them off, and stop a failed x265 build from reaching ffmpeg configure as a
misleading "x265 not found".

* fix(aws-lambda): pin x264 to the revision the x86 ffmpeg uses

The x86 ffmpeg-static 7.0.2 encodes with x264 r3191 (4613ac3); match it.

* fix(aws-lambda): 10-bit x265 in the arm64 ffmpeg, checked by output format

x265 now builds the 10-bit library and links it into the 8-bit one, so HDR
renders get yuv420p10le instead of a silent 8-bit fallback. The check asserts
the encoded pixel format rather than a successful command, and its ffprobe calls
terminate options with -- like every other caller.
2026-10-23 00:13:50 +00:00

35 lines
2.0 KiB
Docker

# The arm64 Lambda video function's native ffmpeg, built on the Lambda Node 22 base it runs on:
# docker buildx build --platform linux/arm64 --target artifact --output type=local,dest=out packages/aws-lambda/image
# The artifact stage depends on the check stage, so no tarball comes out of a build whose codecs fail.
ARG BASE=public.ecr.aws/lambda/nodejs:22@sha256:d138eff445f6ea04c51091d8e6cbb064d5663e850cddfa62396061586f98b126
FROM ${BASE} AS build
ENV SOURCE_DATE_EPOCH=1722643200
RUN rpm -qa --qf '%{NAME}\n' | sort >/build-base-rpms.txt && \
microdnf install -y --nodocs --setopt=install_weak_deps=0 --releasever=2023.12.20260914 \
gcc gcc-c++ make cmake meson ninja-build autoconf automake libtool pkgconf-pkg-config diffutils \
git xz bzip2 tar gzip which patchelf gnutls-devel zlib-devel $([ "$(uname -m)" = x86_64 ] && echo nasm) && \
microdnf clean all && mkdir /build && mv /build-base-rpms.txt /build/base-rpms.txt
COPY sources.txt build-ffmpeg.sh /build/
RUN bash /build/build-ffmpeg.sh
FROM ${BASE} AS certs
# certtool, not openssl: the base's openssl-libs cannot run the repo's openssl CLI.
RUN microdnf install -y --nodocs --releasever=2023.12.20260914 gnutls-utils && mkdir /certs && cd /certs && \
printf 'cn = check-ca\nca\ncert_signing_key\nexpiration_days = 2\n' >ca.tmpl && \
printf 'cn = localhost\ndns_name = localhost\ntls_www_server\nexpiration_days = 2\n' >server.tmpl && \
certtool -p --outfile ca.key && certtool -s --load-privkey ca.key --template ca.tmpl --outfile ca.crt && \
certtool -p --outfile server.key && \
certtool -c --load-privkey server.key --load-ca-certificate ca.crt --load-ca-privkey ca.key \
--template server.tmpl --outfile server.crt
FROM ${BASE} AS check
COPY --from=build /opt/hf-media /opt/hf-media
COPY --from=certs /certs /certs
COPY check-ffmpeg.sh /check-ffmpeg.sh
RUN cp /certs/ca.crt /etc/pki/ca-trust/source/anchors/ && update-ca-trust && bash /check-ffmpeg.sh >/check.txt
FROM scratch AS artifact
COPY --from=build /out/ /
COPY --from=check /check.txt /hf-media-check.txt