* feat(aws-lambda): arm64 video function image from the handler ZIP
The image is the release handler ZIP with its x86 ffmpeg and Chrome swapped for
the native ffmpeg tree and the sha256-pinned Sparticuz arm64 Chrome pack, so the
x86 and arm64 functions run the same handler code. The image stage only copies,
so any host builds it. CI builds it and runs ffmpeg, a real Chrome render and the
Lambda runtime on an ARM runner.
* fix(aws-lambda): launch Chrome in the image smoke the way Lambda does
@sparticuz/chromium inflates its AL2023 libraries only when AWS_EXECUTION_ENV
names a Node runtime; Lambda sets it, a bare docker run does not. The workflow
also runs on @sparticuz/chromium bumps and handler ZIP layout changes, which
re-stage the image.
* fix(aws-lambda): smoke the arm64 image through its own Lambda runtime
The smoke is now a handler invoked through the image's entrypoint, whose
bootstrap sets AWS_EXECUTION_ENV the way Lambda does, so @sparticuz/chromium
takes its Lambda branch with nothing set by hand. It returns the value it saw.
* fix(aws-lambda): agree the move of the ffmpeg build workflow into the image workflow
* fix(aws-lambda): build the Chrome pack URL from the pin and hand the checked pack to tar in memory
* 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.
Miguel Ángel