Прокси — это копия того же самого, только легче. Не «уменьшенная версия», не «черновик», не «превью».

• →
  Монтажёр режет по прокси, а финал рендерится по оригиналу. Подмена — это смена одной корневой папки: 01_Source_Proxy/ → 01_Source/. Внутренние пути идентичны, Premiere подхватывает всё пакетно.
• →
  Уменьшенное прокси (1080p) этого не гарантирует: оно ломает кадрирование и стабилизацию, оценённые по 4K, и заставляет пересчитывать позиции.
• →
  Любое расхождение по кадрам, звуку или таймкоду вылезет в конце, на финальной сборке, когда переделывать дороже всего. Поэтому проверка идёт на каждом клипе, а не на выборке.

Прокси-комплект живёт внутри проекта — {PROJECT}/01_Source_Proxy/, а не папкой-соседкой {PROJECT}_Proxy рядом. Стандарт с 17.08.2026: папка-соседка ломает каноническую структуру, плодит вторую точку правды и путает монтажёра.

Главная таблица этапа. Слева — что измеряем, справа — какое значение считается нормой и чем это проверить. Сверяется на каждом клипе: не сошлось — клип не уезжает в комплект и попадает в отчёт.

Отличаться имеет право только это: кодек с битрейтом (строка 6) и субдискретизация 4:2:2 → 4:2:0 (строка 5). Всё остальное обязано совпасть, потому что подмена прокси на оригинал — это смена одной корневой папки, а не пересчёт таймлайна.

Лог-профили (S-Log3 у Sony, D-Log2 у DJI) держат всю картинку в узком диапазоне. LUT растягивает его обратно — и вот тут 8 бит рассыпаются бандами в небе, на коже и в градиентах.

Замер на живом клипе. RYA-FX3-0983, 32 секунды со съёмки, реальное движение. PSNR после наложения рабочего 02_normal_scene.cube — сравниваются прокси старого и нового рецепта с оригиналом:

+1.97 дБ в среднем и +2.77 дБ на худшем кадре при одинаковом весе. Худший кадр важнее среднего: это и есть те кадры с движением и градиентом, где 8 бит видно глазом. Десять бит не стоили ни байта и ни секунды кодирования — старый дефолт был не компромиссом, а чистой потерей.

⚠️ Повышать так же неправильно, как понижать. 8-битный айфон в main10 — это лишние биты, которые нечем заполнить. Битность берётся с источника, а не ставится константой.

А вот субдискретизация 4:2:2 → 4:2:0 — единственная настоящая потеря в контракте. Насколько она критична, отвечаем замером, а не рассуждением.

PSNR по плоскостям в YUV (15 секунд, оба варианта разогнаны до 4:4:4 для честного сравнения). Y — яркость, U и V — цветоразностные:

• →
  Цветовые плоскости у 4:2:0 и 4:2:2 совпадают до сотых. 55.35 против 55.28 и 52.37 против 52.40 — разница в пределах шума, местами 4:2:0 даже впереди.
• →
  Цвет и так на 10 дБ точнее яркости. Узкое место — квантование на 8 Мбит/с, а не цветовое разрешение: ту дополнительную детализацию, которую сохраняет 4:2:2, рейт-контрол всё равно выбрасывает.
• →
  4:2:0 на 4K — это цветовая картинка 1920×1080. Полноценный HD по цвету. Правило «4:2:2 обязательно» родом из времён, когда мастер был 1920×1080 и цвет падал до 960×540.

⚠️ Старое объяснение было неверным. В тикете значилось «аппаратный кодер 4:2:2 не умеет». Проверено: ffmpeg 8.1.1 принимает -profile:v main42210 -pix_fmt p210le, кодирует за то же время и в тот же вес. Вопрос не «можем ли», а «нужно ли» — и ответ выше. Канон остаётся main10/p010le, а --chroma 422 оставлен дверью: понадобится кеить по прокси или появится цветная бахрома на титрах — переключается одним аргументом.

И главное: прокси никогда не становится финалом. Цвет крутится на оригинале, где 4:2:2 и 10 бит целы. Там, где 4:2:2 действительно решает — кеинг, тонкая вторичная коррекция, насыщенные контрастные края, — на прокси не работают.

Оригинал FX3 несёт таймкод, прокси обязана нести тот же. Без него рассыпается всё, что опирается на TC: синхрон мультикама, сверка с рекордером, монтажный лист.

• ⚠️
  Sony держит TC на data-дорожке (rtmd), а не в контейнере. format_tags=timecode у оригинала вернёт пусто — и легко решить, что таймкода нет вовсе.
• →
  Читать так: ffprobe -select_streams d -show_entries stream_tags=timecode. Отдавать в -timecode.
• →
  У готовой прокси ffmpeg кладёт TC в tmcd и дублирует в format_tags — при сверке смотреть оба места.

Комплект YTCH спринта 3 (441 прокси, собраны 17.08.2026) не нёс таймкода ни в одном файле — ровно по этой причине.

Клип перекодируется, только если он тяжёлый материал с камеры. Всё остальное идёт в комплект байт-в-байт — копия проходит контракт по построению. Правила в contract.decide() идут по порядку, срабатывает первое совпавшее.

• ⚠️
  С телефона прокси не делаем никогда — правило Романа 25.09.2026. Пороги по битрейту дважды вставали ровно в рабочий диапазон айфона (48 → 64 Мбит/с), а 25.09 на ALL BTS вылетели 11 клипов iPhone 14 Pro Max: HEVC 31–82 Мбит/с, семь из них 10 бит HLG, все с переменной частотой кадров. Проверено сверкой размеров: IMG_0393.MOV 106 383 193 Б локально = 106 383 193 Б в комплекте.
• ⚠️
  Лёгкий h264 — тоже копией. Правила про HEVC пропускали целый класс: замерено 24.09.2026 на YTCG Saudi (5 клипов подряд из 01_Project_Files и YTCG36 Screen), на YTFP YTFP01_web.mp4 вырос с 97 МБ до 2572 МБ. Смысл прокси — лёгкость: если источник уже легче цели, жать нечего.
• ⚠️
  Мина: Apple spatial audio. IMG_0578.MOV несёт 8 дорожек — видео, aac 2ch, apac 4ch и пять mebx-метадорожек. ffmpeg apac не декодирует: попытка пережать такой клип либо упадёт, либо молча потеряет дорожку и метаданные.
• ⚠️
  Судить по имени кодека нельзя. У ffmpeg 8.1.1 есть декодер с именем apac — но это другой кодек с тем же четырёхбуквенным тегом. Честный ответ даёт только попытка декодировать одну секунду дорожки.
• ⚠️
  Поворот живёт в Display Matrix, а не в размерах кадра. Портретное видео с айфона лежит как 3840×2160 с матрицей −90°, и ffmpeg при перекодировании поворот применяет — на выходе 2160×3840, и пункт 1 контракта разъезжается.

Правило: клип перекодируется, только если он тяжёлый материал с камеры, снят не на телефон, его геометрию не надо переписывать и он тяжелее цели. Скринкасты студийного дня в прокси не идут вовсе: папка Screencast исключается по имени (--exclude).

Ничего не хардкодится: перед каждым клипом снимаются его параметры, и команда собирается под них.

# 1. снять параметры источника
TC=$(ffprobe -v error -select_streams d -show_entries stream_tags=timecode \
     -of csv=p=0 "$SRC" | head -1 | tr -d ',\r')
PIX=$(ffprobe -v error -select_streams v:0 -show_entries stream=pix_fmt \
     -of csv=p=0 "$SRC")

# 2. битность — по источнику, не константой
case "$PIX" in
  *10le|*10be|*12le) PROF=main10; OPIX=p010le ;;
  *)                 PROF=main;   OPIX=yuv420p ;;
esac

# 3. кодировать во временный файл
ffmpeg -y -v error -i "$SRC" \
  -map 0:v:0 -map "0:a?" \
  -c:v hevc_videotoolbox -b:v 8M -tag:v hvc1 \
  -profile:v "$PROF" -pix_fmt "$OPIX" \
  -c:a aac -b:a 256k \
  ${TC:+-timecode "$TC"} \
  -movflags +faststart \
  -f mp4 "$DST.part.mp4"

mv "$DST.part.mp4" "$DST"

Битрейт — --bitrate auto, по частоте кадров: 25p и 30p — 8 Мбит/с, 50p и 60p — 12 Мбит/с (вдвое больше кадров требуют больше), прочее — 10 Мбит/с. Таблица FPS_BITRATE живёт в contract.py. HEVC на 8 Мбит/с примерно равен H.264 на 15–16, артефакты видны только в быстром движении, где прокси всё равно не финал.

⚠️ У proxy.py и rebuild.py дефолт — 8M, и явное значение таблицу отключает целиком. Без --bitrate auto 50p-клипы YTEVO03 (109 штук) уехали бы на 8 Мбит/с вместо 12, и гейт бы промолчал: его коридор 0.35–2.5× это пропускает. Ночные прогоны (0121_studio_day/night.py, ферма) передают auto всегда.

Комплект принят, когда по каждому клипу сошлось всё перечисленное. Не сошлось → один ретрай; не сошлось снова → клип не уезжает и попадает в отчёт.

• 1
  число кадров прокси == число кадров оригинала
• 2
  разрешение и r_frame_rate совпали строкой
• 3
  битность прокси соответствует битности источника
• 4
  число аудиодорожек и каналов в каждой совпало
• 5
  таймкод в прокси есть, если он был в источнике, и равен ему
• 6
  цветовые теги совпали — включая случай «пусто на обеих сторонах»
• 7
  относительный путь и имя файла совпали 1:1
• 8
  битрейт прокси около заказанного (коридор 0.35–2.5× от цели), и она легче оригинала. Клипы короче 4 секунд от этой проверки освобождены — см. ниже

⚠️ Ловушка сверки битности. -pix_fmt p010le на входе кодера даёт файл, который ffprobe читает как yuv420p10le. Сверять pix_fmt строкой нельзя — завернёт каждый правильный клип. Сверяется класс глубины.

⚠️ Почему не «сжатие в 12–25 раз». Такой коридор зашит под исходник ~140 Мбит/с и врёт на коротких клипах. Живой случай 22.09.2026: RYA-FX3-0868 длиной 0.96 секунды — Sony пишет такой обрубок на 563 Мбит/с в контейнере, честная прокси даёт сжатие ×63, и гейт браковал исправный файл. Проверять надо то, что обещали: битрейт прокси. У того же клипа он вышел 8.9 Мбит/с при заказанных 8 — всё в порядке.

Отчёт proxy_report.json несёт по каждому клипу пару источник→прокси по всем восьми параметрам, а не одни кадры: когда что-то разойдётся, должно быть видно, что именно.

Гейт выше говорит, что проверяется. Здесь — чем. Все проверки читают файлы и ничего не переделывают: запускать можно в любой момент, в том числе по уже отданному монтажёру комплекту.

python3 ~/YTAI/scripts/16_proxy/1601_build/proxy.py \
  --src "$СЦЕНА" --dst "$КУДА" --only "RYA-FX3-1107.MP4" --gate-report

Как читать proxy_report.json

Быстрый взгляд на весь отчёт одной строкой:

python3 -c "import json,sys; r=json.load(open(sys.argv[1]));
print(r['counts'], 'провалов:', r['fails']);
[print(' ✗', c['rel'], c['err']) for c in r['clips'] if c['status']=='FAIL']" \
  "$PROJ/00_Setup/logs/proxy_report.json"

Один и тот же клип RYA-FX3-0983 (YTCH10, 32 с) в трёх видах: оригинал, прокси старого рецепта от 17.08.2026 и прокси нового контракта от 23.09.2026. Это не правило, а то, что именно чинили.

• →
  Вес одинаковый. 34.3 МБ против 34.0 — новая даже чуть легче. Десять бит не стоили ничего: ни байта, ни секунды кодирования.
• ⚠️
  Старая прокси врала в метаданных. У неё проставлен bt709, хотя исходник снят в S-Log3 и цветовых тегов не несёт вовсе. Premiere читает этот тег и применяет не ту кривую.
• ⚠️
  Старая потеряла дорожку целиком. У исходника три потока, у неё два: таймкодовая не доехала.

Итог пересборки комплекта YTCH в ночь 22→23.09.2026. Кодирование и заливка внахлёст, девять часов. Цифры сняты 23.09 в 11:00. Три проекта закрыты; YTCH10 занял 5ч 46м. Недобор клипов — это те, что гейт справедливо не пустил: повёрнутые айфонные, см. §5.

У YTCH12 «116 из 115» — лишний файл это спаннер RYA-FX3-1071__S10, второй экземпляр клипа, живущего в двух сценах: он сделан на Drive копированием, без повторной заливки. Один клип YTCH11 остался от 17.08 — это повёрнутый айфон IMG_0406 2.MOV, который гейт справедливо завернул, см. §5.

Скорость, замеренная на прогоне: кодирование ×4 реалтайма суммарно и от числа потоков почти не зависит — hevc_videotoolbox это один аппаратный блок, а не ядра. Один поток даёт ×3.7, три потока ×4.0: три купили 8 % и стоили втрое больше места в стейджинге.

• 1
  .part ломает ffmpeg. Временное имя без известного расширения → «Invalid argument» при инициализации муксера. Лечится явным -f mp4.
• 2
  В zsh 0:a? нужно в кавычках — иначе шелл съедает ? как глоб. В коде команда собирается списком, где этой проблемы нет структурно.
• 3
  Не форсить bt709 на логе. FX3 и ZV-E1 не несут цветовых тегов вообще — значит отсутствие тега это значение, и прокси обязана остаться такой же пустой. Прокси, вдруг отрапортовавшая bt709, — это регрессия, а не починка.
• 4
  Спаннер-клипы. Клип, живущий симлинком в двух сценах, кодируется один раз; вторая копия делается на Drive server-side — один файл не льём дважды.
• 5
  Server-side на Drive. rclone moveto/copy в пределах одного remote не тратит трафик. Держать --tpslimit 6–8, иначе 403.
• 6
  exFAT плодит ._*. AppleDouble-файлы на каждый файл и папку; в rclone copy обязателен --exclude "._*", иначе мусор уезжает на Drive.
• 7
  Медиа не удаляем никогда. Удаляется только собранный прокси из стейджинга и только после подтверждённой заливки. Дубли при слиянии сцен переезжают в архивную папку — не rm.
• 8
  Заливка обгоняется кодированием примерно вдвое. Без потолка на стейджинг очередь вырастет быстрее, чем место на диске. Кодировщик обязан ждать заливку, а не наоборот.

Проверено VMAF-калибровкой: для Source Light аппаратный hevc_videotoolbox дал файл больше при худшем качестве — программный x265 там обязателен. Для прокси наоборот: скорость решает, потому что финал всё равно на оригиналах.

Роман 16.10.2026: «синхрон и нарезка исходных аудиофайлов без их сжатия под видео (32 бит флоат)… фрейм в фрейм». Под каждый видеоклип 01_Source — WAV из оригинала передатчика DJI: float 32, 48 кГц, моно, сэмплы копией — ни уровня, ни лимитера, ни пересэмплирования. Файл начинается на первом кадре клипа и длится ровно кадры / fps, до сэмпла. Монтаж берёт эти файлы; исходное качество потом возвращается заменой файла. Шаг E2 Pre-edit (/map/speed/).

Пилот YTEVO03, 16.10.2026: 209 клипов, с петличкой 128 — 213 файлов (7,1 ГБ) за 23 с на Memex, приёмка 213 из 213 бит в бит, начала совпали с дорожками лайта до сэмпла. У 81 клипа петлички нет, в описи почему: 74 — записей передатчиков на это время нет нигде (сцены 03, 06, 09, 12, съёмка 17.09 «Лисий Нос»), 2 — записи DJI-2 и DJI-3 по часам под клипами, но звук камеры с ними не сходится (передатчики были не у камеры), 3 — осечки Pocket 0,5–0,7 с, короче окна сверки звуком.

# план: место на ленте, доли _orig, сдвиг GCC, поиск для сцен без полос (лёгкий, любая машина)
PY=~/YTAI/environment/.venv_transcribe/bin/python; S=~/YTAI/scripts/16_proxy/1605_sound/sound.py
$PY $S plan --project "$PROJ"

# нарезка и приёмка — на машине, где диск проекта свой (T9-Black-2 — Memex)
ssh memex-tb 'export RYA_STEP=E2 RYA_PROJECT=CODE; ~/.local/bin/rya-res run sound-cut-CODE --kind light --where here -- \
  ~/YTAI/environment/.venv_transcribe/bin/python ~/YTAI/scripts/16_proxy/1605_sound/sound.py cut --project "$PROJ"'
$PY $S check --project "$PROJ"     # или так же на Memex
$PY $S status --project "$PROJ"    # клипов N, с петличкой M, без — K и почему

# комплект проекту
python3 ~/YTAI/scripts/16_proxy/1601_build/proxy.py \
  --src "$PROJ/01_Source" --dst "$PROJ/01_Source_Proxy" \
  --bitrate auto --jobs 2 --report "$PROJ/00_Setup/logs/proxy_report.json"

# доложить WAV, транскрипты и луты сцен
python3 ~/YTAI/scripts/16_proxy/1601_build/kit.py --src "$PROJ/01_Source" --dst "$PROJ/01_Source_Proxy"

# проверить один клип по всем восьми пунктам
python3 ~/YTAI/scripts/16_proxy/1601_build/proxy.py \
  --src "$SCENE" --dst "$OUT" --only "RYA-FX3-1107.MP4" --gate-report

Три драйвера — один контракт. Решение, команда и гейт у всех берутся из contract.py; различается только логистика.

# там, где смонтированы диски: манифест «сцена → файл на Drive», каждый источник по точному размеру
python3 ~/YTAI/scripts/16_proxy/1603_farm/plan.py --unit YTEVO03 --publish
# где угодно
python3 ~/YTAI/scripts/16_proxy/1603_farm/farm.py run --unit YTEVO03 --dry-run
python3 ~/YTAI/scripts/16_proxy/1603_farm/farm.py run --unit YTEVO03
python3 ~/YTAI/scripts/16_proxy/1603_farm/farm.py status --unit YTEVO03
python3 ~/YTAI/scripts/16_proxy/1603_farm/farm.py selftest   # регрессия до любой правки

• →
  Истина о сделанном — на Drive: клип сделан, если прокси лежит на месте и проходит контракт. Очередь — дописываемый журнал journal.jsonl; взятый клип держит лизу 3 часа и сам возвращается в очередь, если воркер упал.
• →
  Место — обратное давление: резерв на оригинал (у FX3 до 52 ГБ) и прокси сразу, кодировщик ждёт, пока есть куда класть. Залитое подтверждается размером с Drive.
• ⚠️
  Заливка только copyto/copy, никогда sync: в комплекте на Drive живут и транскрипты — у YTEVO03 их 277, единственная копия вне _work. Квота Drive 750 ГБ/сутки лечится ожиданием, а не повтором.
• →
  Выключатели файлами: ~/.cache/ytai/proxy_farm/STOP · PAUSE_UPLOAD. Развёртывание на Мемекс — deploy_memex.sh, launchd в 01:00. Как комплект едет на Drive — 3.8 Project Drive Sync.