Reproducible recipe evidence¶

These are measured outputs, not screenshots or benchmark claims. On 2026-08-25 the commands below ran against deterministic first-party fixtures generated by tests/media/download_fixtures.py. The checked-in receipts preserve the exact plan, FFmpeg/Python versions, probes, elapsed result, and privacy policy without publishing local media paths.

Recipe	Before	After	Machine evidence
Web-compatible video	688,662-byte MOV, H.264	555,083-byte MP4-family output, H.264; 19.4% smaller	Receipt JSON
Exact-size upload	4,042,503-byte H.264/AAC MP4	248,417 bytes against a 262,144-byte limit; target passed	Receipt JSON
Podcast loudness	-22.0 LUFS WAV	-16.2 LUFS MP3 against a -16.0 LUFS target	Receipt JSON

The compact evidence index records the receipt SHA-256 values so changes are reviewable.

Replay on 19 September 2026¶

The installed 0.2.2 wheel was replayed on macOS 26.6 arm64, Python 3.14.6, and FFmpeg 9.0.1 using the same generated fixture set. All three outputs passed probe, receipt validation, and a complete FFmpeg decode to null. These are synthetic checks; no human picture or listening assessment was made.

Recipe	Generated input	Measured output	Receipt
Web MP4 from VP9 WebM	2,141,004 bytes	3,814,506 bytes, H.264/AAC; 78.2% larger	Receipt
256 KiB upload limit	4,042,503 bytes	248,417 bytes, H.264/AAC; limit passed	Receipt
Podcast loudness	370,518-byte WAV, −22.0 LUFS	101,996-byte MP3, −16.2 LUFS	Receipt

The VP9 example is a useful counterexample to a compression promise: the web profile targets wider playback compatibility, and re-encoding can increase file size. Its output has moov before mdat for progressive download. The replay index records the environment, receipt SHA-256 values, stream facts, and checks. Measurements on other FFmpeg builds may differ.

Exact-size replay on 24 September 2026¶

The 0.3.0 checkout reran the generated six-second H.264/AAC fixture (4,042,503 bytes) on macOS arm64, Python 3.14.6, and FFmpeg 9.0.1. --explain created no output. Two-pass compression targeting 262,144 bytes produced a 248,417-byte H.264/AAC MP4 (yuv420p); probe, schema 1.0 receipt validation, and full decode passed. The receipt has SHA-256 121a127b72cf15cccfc6b9aa5043f029d4437f2aaada8ff41ada32830b77d435. An independent rerun on the same host produced identical output bytes and matched the receipt's output SHA-256 6cd9a2a6a23a493e7fbd46e6095dc2e75bd32fa847421266695f84e9d8435566. FFmpeg's SSIM filter measured All:0.926144 on this generated fixture:

ffmpeg -v info \
  -i tests/media/downloads/sample_mp4_h264.mp4 \
  -i under-limit.mp4 \
  -lavfi ssim -f null -

That fixture-only metric does not establish perceptual quality for representative media; a real-media check was still open at that point.

Public-domain real-video check on 24 September 2026¶

Xiph's test-media collection labels the vidyo1 720p sample public domain. Its 8,147,493-byte, 10.017-second 1280×720 VP9 WebM was downloaded for a local check; SHA-256 a090e17dd2c781f16604b2a56989482db05249dd1ac92d36ec0050ea516e36c3. It has no audio or subtitle streams. The file and extracted frames stayed in /tmp.

On macOS arm64, Python 3.14.6, and FFmpeg/FFprobe 9.0.1, PyFFmpegCore 0.3.1 passed --explain preflight, then converted it with web/mp4-compatible to a 1,763,207-byte H.264 MP4 (yuv420p, 1280×720, 60 fps), 78.36% smaller than the input. FFprobe and the redacted schema 1.0 receipt validator passed; a full decode passed; moov precedes mdat; and the receipt contains no temporary path. Input/output comparison with FFmpeg's SSIM filter measured All:0.980900 (Y 0.977687, U 0.985978, V 0.988672). A visual spot-check of decoded frame pairs at 1 and 7 seconds, each scaled to 640×360, showed no obvious blocking or softness at that size. This is a narrow local check of one video recipe, not a broad quality study. It does not cover audio, exact-size compression, another FFmpeg build, or another platform.

Output SHA-256: 3fa464804b67062c856a08116704bd645d3707ffd25f4c77967c421d12483703. Receipt SHA-256: ef761c23f938d43cbaa6d11700cde8b7dc0414d11d1d61406ff6d424c619dafb.

Reproduce the web-profile check¶

Reproduce against the linked Xiph download with fresh output paths:

curl -fLsS \
  https://media.xiph.org/video/derf/webm/vidyo1_720p_60fps.webm \
  -o vidyo1_720p_60fps.webm

pyffmpegcore profile run web/mp4-compatible \
  --input vidyo1_720p_60fps.webm \
  --output vidyo1.mp4 \
  --explain

pyffmpegcore profile run web/mp4-compatible \
  --input vidyo1_720p_60fps.webm \
  --output vidyo1.mp4 \
  --receipt vidyo1.receipt.json

pyffmpegcore receipt validate vidyo1.receipt.json --json
ffmpeg -v error -i vidyo1.mp4 -f null -

Public-domain exact-size check on 24 September 2026¶

The same Xiph vidyo1 VP9 clip was tested with two-pass compression on macOS arm64, Python 3.14.6, and FFmpeg/FFprobe 9.0.1. The input has one video stream and no audio. The corrected planner now budgets that target as video-only: it does not reserve an audio bitrate or require an AAC encoder. --explain wrote no output.

With a 1 MiB target and an explicit 7% container reserve, the run produced a 1,035,870-byte H.264 MP4 (yuv420p, 1280×720) against the 1,048,576-byte limit. The receipt records target_met: true; receipt validation, FFprobe, and full decode passed. The measured output SHA-256 is 66773993cac83b0310fbe606cfe30514a11a538af8cb894cf67cfdc1ca1c83ba. The privacy-redacted receipt has SHA-256 0d808ebfd1d3f7758fdef04a6be497698ecb879fecf891746556ac11d8865b7a.

The default 5% reserve produced 1,056,379 bytes, 7,803 bytes over the limit. FFmpeg's two-pass rate estimate can miss a byte ceiling; the receipt reports target_met: false for that run. The 7% reserve passed on this sample with 12,706 bytes to spare. This is one clip and one FFmpeg build, not a universal reserve recommendation.

The source/output SSIM filter measured All:0.976039 (Y 0.971474, U 0.983743, V 0.986591). Frame pairs at 1 and 7 seconds were inspected at 640×360; no obvious blocking or softness appeared at that size. This narrows the exact-size review gap to this video-only sample. It does not cover speech, audio, other FFmpeg builds, or other platforms.

Reproduce the exact-size check¶

curl -fLsS https://media.xiph.org/video/derf/webm/vidyo1_720p_60fps.webm -o vidyo1_720p_60fps.webm
pyffmpegcore compress --input vidyo1_720p_60fps.webm --output vidyo1-exact-size.mp4 --target-size 1MiB --two-pass --container-overhead-percent 7 --explain
pyffmpegcore compress --input vidyo1_720p_60fps.webm --output vidyo1-exact-size.mp4 --target-size 1MiB --two-pass --container-overhead-percent 7 --receipt vidyo1-exact-size.receipt.json --hash-content
pyffmpegcore receipt validate vidyo1-exact-size.receipt.json --json
ffmpeg -v error -i vidyo1-exact-size.mp4 -f null -

Generated audio-video exact-size check on 24 September 2026¶

The repository's six-second, 1920×1080 testsrc2/440 Hz fixture contains H.264 video and AAC audio. On macOS arm64, Python 3.14.6, and FFmpeg/FFprobe 9.0.1, the two-pass planner selected both streams, required libx264 and AAC, and reserved 128 kb/s for audio plus 7% for the container.

The 4,042,503-byte source produced a 1,984,802-byte H.264/AAC MP4 under a 2 MiB (2,097,152-byte) limit. Its receipt reports target_met: true; receipt validation and full decode passed. The privacy-redacted receipt has SHA-256 56615d07744a2d86e7852acecb6d06659b591d29856083421bfbc9694ed7c68e. The existing focused CLI two-pass real-media test also passed against this fixture. This generated pattern and tone verify the audio-present execution path, not perceptual quality on representative footage or speech.

Reproduce the audio-video check¶

python tests/media/download_fixtures.py
pyffmpegcore compress \
  --input tests/media/downloads/sample_mp4_h264.mp4 \
  --output sample-target.mp4 \
  --target-size 2MiB \
  --two-pass \
  --container-overhead-percent 7 \
  --receipt sample-target.receipt.json \
  --hash-content
pyffmpegcore receipt validate sample-target.receipt.json --json
ffmpeg -v error -i sample-target.mp4 -f null -

Reproduce¶

Generate the same inputs, then run:

python tests/media/download_fixtures.py --force

pyffmpegcore profile run web/mp4-compatible \
  --input tests/media/downloads/sample_video_mov.mov \
  --output web.mp4 \
  --receipt web-video.receipt.json

# Replay the VP9 counterexample separately, using a new output path.
pyffmpegcore profile run web/mp4-compatible \
  --input tests/media/downloads/sample_webm_vp9.webm \
  --output web-from-vp9.mp4 \
  --receipt web-from-vp9.receipt.json

pyffmpegcore compress \
  --input tests/media/downloads/sample_mp4_h264.mp4 \
  --output under-limit.mp4 \
  --target-size 256KiB \
  --two-pass \
  --receipt exact-size.receipt.json

pyffmpegcore normalize-audio \
  --input tests/media/downloads/sample_audio_wav.wav \
  --output podcast.mp3 \
  --method loudnorm \
  --receipt podcast.receipt.json

The loudness figures use FFmpeg's ebur128=peak=true analysis before and after normalization. File sizes and stream facts come from the receipt probes. Exact bytes and timings vary when the FFmpeg build changes, so these artifacts are a dated reproducibility baseline, not a universal performance promise.