◂ База знанийRYA.AEОживление ката — обогащение исходниковобновлено 25 июн 2026
Системный метод, как сделать готовый кат живее — больше живых моментов, эмоций, движения, красивых кадров. Мы заранее превращаем все отснятые исходники в размеченный банк «живых» моментов с двойным таймкодом — пословным (речь) и покадровым (картинка), — и подставляем лучшее по ходу видео. Это подготовленная переиспользуемая система: один раз разложил → дальше любое видео собирается из неё. Работает для любого канала (YTCR, YTRF, …).
📌 Когда применять. Идеально — заранее, сразу после ингеста/транскрипции (стадия PreEditing): банк готов ещё до монтажа. Минимально — на Review, когда «говорящая голова провисает» и хочется жизни. Это не замена монтажному манифесту и не playbook'у структуры проекта — это слой подбора вставок поверх них: даёт монтажёру готовый список «что и в какую секунду исходника взять».
📸 экраны 🎙 word-tc 🧠 анализ 📚 индекс 🎬 подбор 🖥 UXP Review

Принцип

Готовый кат — это в основном интервью (говорящая голова). «Жизнь» лежит в исходниках, которые не вошли: смех на волейболе, golden-hour в пустыне, реакция в машине, объятие у костра. Мы их не помним поштучно — поэтому строим каталог каждого клипа с оценками и, главное, с точным таймкодом момента в клипе. Дальше любой живой/красивый кадр всегда резолвится в «клип @ секунда» и подставляется монтажёру ровно на этот момент — без пересмотра гигабайтов отснятого.
реальный шут в приоритетеинста — текстураDNA: настоящий Дубай, не глянецтайминг сохраняем везде

Структура папок — где живёт банк

Весь «банк живости» одного видео — отдельная стадия 00_Setup/06_Enrichment/ (бывш. _analysis/ внутри Review — теперь свой этап, рядом с 05_Review). Реальна с 25.06.2026 — YTCR01 переведён на эту раскладку (enrichment_build_v41.py), _analysis/ сохранён. Нумерация подпапок = порядок пайплайна (конвенция playbook §1). Важно: сам JSON для монтажа UXP читает не отсюда, а из 02_Assembly/parts/ (↓). Клик по имени папки — копирует его в буфер.

  • 📁 00_Setupслужебные под-стадии: 01_Ingest · 02_Assembly · 03_Pre-Edit · 04_ScreenCues · 05_Review — и рядом ↓
    • 02_Assembly/parts🖥 ЧТО ЧИТАЕТ UXP — вкладка Review («Build Review-Overlay») берёт {CODE}_part_Inserts_v{N}.json только отсюда. Стадия enrichment доставляет сюда готовый overlay-JSON
    • ⭐ 06_EnrichmentОТДЕЛЬНАЯ стадия — банк «живых» исходников (бывш. _analysis/). Строится с PreEditing, питает Review + Edit
      • 01_frames📸 ЭКРАНЫ — извлечённые кадры по сценам: <scene>/<clip>_<k>.jpg. derived — не правим руками, истинный tc — в frames.json
      • 02_transcripts🎙 WORD-level tc — указатель (README.txt): {stem}_en.json (words[]·{w,s,e}) канонически живут в 01_Source/Transcription/per_clip/<scene>/; банк линкует их по stem, не копирует
      • 03_catalog🧠 АНАЛИЗ ЭКРАНОВ — vision-оценки per-clip: live_catalog.json (entries{"scene/clip_id"} → emotion/liveliness/beauty/live_moment/best_tc/moments)
      • 04_picks🎬 подбор живых вставок под абзацы ката: inserts.json (src_in=best_tc)
      • _tools⚙️ переиспользуемый тулинг (frames · catalog_gen · merge · index_build · index_html · picks_gen · picks_merge · en_emit · build) — копипастится в новый проект
        • project.env🎯 единственный per-project файл: ROOT·CODE·SRC·TRANSCR·FPS·ENRICH. Цель: скрипты читают пути отсюда (донорские пока хардкодят ROOT — рефактор).
      • _archive🗄 старые версии vN — вне работы
      • frames.json🗺 КАРТА кадр → клип @ t_sec (frame-level tc); пути кадров относительные (01_frames/…)
      • full_source_index.json📚 МАСТЕР-индекс всех клипов (оценки + таймкоды + транскрипт)
      • {CODE}_source_index.html🪟 ВИТРИНА живых исходников — фильтр/сорт по эмоции/живости/красоте, превью на best_tc, 🕒
      • {CODE}_source_inserts.html📝 монтажный лист с живыми вставками + превью
      • {CODE}_part_Inserts.json🖥 мастер-зеркало overlay-JSON (схема ytai-part-v1). Рабочую копию стадия доставляет в 02_Assembly/parts/ ↑ — именно её читает UXP Review
Статус: YTCR01 — на каноне (06_Enrichment построен 25.06.2026 из ytcr01_v12_*, что лежали плоско в 01_Media/Source/Setup/Review/_analysis/; APFS-clonefile, _analysis/ цел, операция обратима). Тулинг: scripts/999_extra/enrichment_build_v41.py. Новые проекты заводим сразу по этой структуре; v4.1-донор YTCR04 пока в 00_Setup/05_Review/_analysis/.

Где экраны · где их анализ · какой таймкод

слойчто этогде (путь от 06_Enrichment/)таймкод
📸 экраныстиллы исходников по сценам, ~3–8/клип01_frames/<scene>/<clip>_<k>.jpgframe (в карте)
🗺 карта кадровкадр → клип @ секундаframes.jsonframe t_sec
🎙 транскриптыпословный тайминг речи01_Source/Transcription/per_clip/<scene>/{stem}_en.jsonword s/e
🧠 анализ экрановvision-оценки + точечные моменты03_catalog/live_catalog.jsonframe best_tc·moments[]
📚 мастер-индексвсе клипы: оценки + транскрипт + tcfull_source_index.jsonword + frame
🎬 подбор вставокживые перебивки под абзацы ката04_picks/inserts.jsonframe src_in=best_tc
🖥 вход UXPoverlay-JSON, что читает вкладка Review00_Setup/02_Assembly/parts/{CODE}_part_Inserts_v{N}.jsonframe source_in_sec
Идея: экраны и их анализ разнесены — кадры можно перегенерить (дёшево), анализ копится поверх (дорого). Карта frames.json склеивает их: любой кадр из анализа всегда резолвится в исходник @ секунду.

Двойной таймкод — почему это главное

Сцена ценна не «клипом целиком», а конкретным моментом. Поэтому каждый слой несёт оба таймкода, и они сквозными.

🎙 WORD-level — где сказано слово
Пословный тайминг речи: {stem}_en.json → words[]·{w,s,e}. Для точного премонтажа фраз — где именно произнесена реплика, чтобы резать ровно по слову.
📸 FRAME-level — где красивый кадр
Покадровый тайминг картинки: frames.json → frames[].t_sec. Кадр назван {clip}_{k}.jpg (k — порядковый, не tc), истинная секунда — в карте. Сильнейший момент — best_tc: в коде clamp[0,dur], а попадание в реальный сэмпл-кадр обеспечивает vision-промпт («возьми один из ДАННЫХ таймкодов кадров») — ~99% на практике, не отдельным snap-шагом.
Сквозной поток в сборку:
frame.t_secbest_tc / moments[].t_secinsert.src_inparts source_in_sec → UXP кладёт overlay ровно на момент
Ключевое: src_in берётся из best_tc каталога (тайминг от vision), а не от LLM — момент всегда точный.

Перенос данных · точность · Premiere

Два вопроса, которые решает раскладка: не теряются ли точные данные при переносе стадии и как таймкод доходит до Premiere без потерь.

🔗 Перенос не теряет точные данные
Банк привязан к source_path (→ 01_Source/Video, не двигается) и числовым таймкодам — не к своему месту. При переносе стадии / смене диска сохраняется точно: все t_sec · s/e · best_tc · moments[], оценки, транскрипты, clip_id/scene. К месту привязан лишь путь к jpg-кадрам — а это derived-кэш: перегенерится или правится prefix-replace'ом (у YTCR01 уже отработано — _path_fix_backup_*). Канон: пути кадров относительные → перенос = ноль правок.
🎯 Точность и как её ест Premiere
Истина = float-секунды макс. точности (мс/μс), не округляем рано (ошибка копится). μs (6 знаков) — потолок осмысленного, больше — пусто. Но Premiere кладёт по КАДРАМ (HH:MM:SS:FF), не по долям: на границе с Premiere/UXP frame = round(sec × fps) — frame-accurate; fps из project.env (YTCR = 25, per-scene dominant, не форсить 50). Точность сверх кадра нужна для выбора кадра, не для укладки.
Правильный подход: макс. точность ВНУТРИ (lossless секунды) → frame-accurate НА ВЫХОДЕ в Premiere.
float sec · μs истина, везде сквознаяMM:SS.mmm дисплей (тоньше любого fps)TickTime.createWithSeconds(sec) Premiere квантует к сетке кадров
parts ytai-part-v1 уже несёт оба: source_in_sec (float-сек, истина) + tc_in:"MM:SS.mmm" (мс-строка) → UXP конвертит в кадры по fps. Так Premiere получает точный кадр, а данные остаются lossless. Сравни с DNA-памятью DJI-sync: μs-точность + frame-correction на границе монтажа.

Подготовленная система — пайплайн 6 шагов

шаги 1–4 можно гнать заранее на PreEditing (банк готов до монтажа) · шаги 5–6 — на Review. Стадия 06_Enrichment одинаковая, где бы ни собиралась.

1
Экраны исходниковPreEditing

ffmpeg-граб кадров адаптивно по времени (видео: ~2.5с шаг, 3–8 кадров; <6с → 3 кадра; stills → 1 кадр без -ss). У каждого кадра — точный t_sec. Идемпотентно.

in 01_Source/Video/<scene>tool _tools/frames.pyout 01_frames/ + frames.jsontc frame-level
2
Word-level транскриптыPreEditing

Каждый клип со спичем получает пословный тайминг. Один mlx-джоб за раз (RAM/OOM), фоном. Немые сцены (офис/волейбол/B-roll) пропускаем.

in клипы со спичем + аудиоtool mlx_whisper → en_emit.pyout 01_Source/Transcription/per_clip/<scene>/{stem}_en.jsontc word-level
3
Анализ экранов — vision-каталогPreEditing

Кадры из 01_frames чанкуются по сценам и идут в vision-агентов (через Workflow). На клип — описание + оценки «под лайв» и точечные моменты с их таймкодами. Честно отсеивают мусор (репост-баннеры, плоские инфографики, блюр) → usable=false.

in 01_frames + frames.jsontool _tools/catalog_gen.py → Workflowout 03_catalog/live_catalog.jsontc best_tc + moments[]
4
Мастер-индекс + витринаPreEditing

Сводим ВСЕ клипы (каталог + карта + транскрипты) в один индекс и строим браузерную витрину в стиле портала — фильтр/сортировка по эмоции/живости/красоте/live_moment, превью на best_tc, 🕒.

in catalog + frames + transcriptstool index_build.py + index_html.pyout full_source_index.json + source_index.htmltc word + frame
5
Подбор живых вставокReview

Vision-ранкер по приоритету live_moment → beauty → emotion предлагает живые перебивки под абзацы ката. src_in не у LLM — берётся из best_tc на merge (тайминг от vision). Реальный шут в приоритете, инста — текстура.

in live_catalog + cut_sourced (озвучка ката)tool picks_gen.py + picks_merge.pyout 04_picks/inserts.jsontc src_in=best_tc
6
Сборка листа + UXP ReviewReview

Пересобираем монтажный лист (полный текст + вставки + превью) и overlay-JSON, который доставляем в 02_Assembly/parts/ — оттуда вкладка Review («Build Review-Overlay») кладёт рендер на V1, вставки сверху на V2/V3. Каждая вставка — на свой track/audio_track, keep_audio, in/out в секундах и в таймлайне. Это тот же движок, что у вкладки Parts (buildPartSequence + ytai-part-v1); Review = режим build_model:"overlay_on_base", Parts = absolute-сборка куска.

in 04_picks/inserts.jsontool _tools/build.pyout source_inserts.html + part_Inserts.json→ 02_Assembly/parts/ → UXP Review

Шкала оценок («лайв»-рубрика)

полезначение0 → 5
emotionсила эмоции в кадре0 = нет · 5 = смех/радость/драма
livelinessдвижение / действие / спонтанность0 = статика · 5 = много движения
beautyкинематографичность0 = невзрачно · 5 = golden hour / скайлайн / композиция
live_momentживой момент (bool)смех · реакция · объятие · спонтанный жест
onbrandпо DNA канала (bool)реальный Дубай / жизнь героя ≠ инста-глянец
usableгоден ли вообще (bool)false = репост-баннер / инфографика / блюр
best_tc / moments[]точный таймингсекунда сильнейшего кадра + точечные моменты
Приоритет подстановки: live_moment → beauty → emotion. Один длинный клип отдаёт несколько точечных зацепок (разные moments[].t_sec), а не одну оценку на весь клип. Сводная метрика — live_score = beauty + emotion + liveliness (+3 если live_moment).

Схемы данных

frames.json — карта кадров (frame-level tc)
{
 "C5285": {                              // ключ = clip_id
  "scene": "dubai_driving",            // keys: scene·d·dur·is_still·source_path·frames·n
  "d": "01_frames/dubai_driving",        // папка кадров (относительная)
  "dur": 31.4, "is_still": false,
  "source_path": ".../01_Source/Video/dubai_driving/C5285.MP4", // абсолютный (реальное медиа)
  "frames": [
    { "k": 0, "file": "01_frames/dubai_driving/C5285_0.jpg", "t_sec": 1.47 },  // k = порядковый, НЕ tc
    { "k": 1, "file": "01_frames/dubai_driving/C5285_1.jpg", "t_sec": 4.10 }
  ],
  "n": 2
 }
}
full_source_index.json — запись клипа (оценки + tc)
{ "generated":"…", "project":"…", "cut":"YTCR1_v9_Arty_Dzis.mp4", // рендер, под который индекс
  "n":1129, "n_live_moments":207, "n_with_transcript":216, "scenes":{…},
  "clips": [ {
    "scene":"07_new_office", "clip_id":"C7770", "source_file":"C7770.MP4", "source_path":"…", "dur":29.76,
    "usable":true, "visual_type":"talking_head", "desc":"…", "energy":"high",
    "emotion":null, "liveliness":3, "beauty":null, "broll_quality":2,
    "live_moment":false, "onbrand":true, "tags":["hero_arty","office_work"],
    "best_tc":0, "moments":[],            // frame-level
    "has_transcript":false, "n_words":0, "transcript_text":"", // word-level
    "live_score":3.0, "src":"v12"                 // провенанс прохода
  } ] }
part_Inserts.json → 02_Assembly/parts/ — вход UXP Review (схема ytai-part-v1, src_in = best_tc)
{ "schema":"ytai-part-v1",
  "part": {                              // ⚠ part — ОБЪЕКТ, не строка
    "code":"YTCR01", "name":"Review_v9_live_inserts", "stage":"Review", "fps":25,
    "build_model":"overlay_on_base",     // ⚠ ОБЯЗАТЕЛЬНО — иначе скоринг Review-Overlay не выберет файл
    "base_clip":"YTCR1_v9_Arty_Dzis.mp4", "base_clip_path":".../03_Exports/…mp4", // рендер → V1
    "sequence_name":"YTCR01_5_Review_v9_overlay", "color":"Mango"
  },
  "tracks":{…}, "audio_policy":"…", "counts":{…}, "changelog":[…],
  "segments": [ {
    "role":"shown", "track":"V3", "audio_track":"A3", "keep_audio":true,
    "scene":"dubai_driving", "clip_id":"C5285", "source_file":"C5285.MP4", "source_path":"…", "is_still":false,
    "source_in_sec":0.0, "source_out_sec":3.0,   // in = best_tc (vision)
    "timeline_in":"00:00.000", "timeline_out":"00:03.000", "timeline_in_sec":0.0, "segment_id":"…"
  } ] }
Файл лежит в 02_Assembly/parts/ — вкладка Review («Build Review-Overlay») выбирает лучший по build_model==='overlay_on_base' × версия × число сегментов, кладёт base_clip на V1, вставки сверху на V2/V3. Тот же движок buildPartSequence, что у вкладки Parts — разница лишь build_model (overlay_on_base ↔ absolute). keep_audio сохраняет аудио вставки (VO-над-B-roll), source_in_sec = момент из каталога. (Обратная сортировка по одинаковому tc — в отдельном «recommended»-пути UXP, не в этом overlay-билдере.)

Применить к новому видео

Эталон — донор YTCR01: набор ytcr01_v12_* (frames · catalog_gen→workflow · merge · index_build/html · picks_gen/merge · build + en_emit). С 25.06.2026 собран в 06_Enrichment/_tools/ (см. enrichment_build_v41.py). Для нового видео — скопировать _tools/ и заполнить project.env. Оговорка: донорские скрипты пока хардкодят ROOT на старте модуля — чтение из project.env это запланированный рефактор.

  • A
    Прочитать 00_Setup/05_Review/HANDOFF_source_video_enrichment.md в проекте — самодостаточный бриф (что готово, что добить).
  • B
    Скопировать тулинг донора в 06_Enrichment/_tools/ и заполнить только project.env (ROOT·CODE·SRC·TRANSCR·FPS) — скрипты читают пути оттуда, сам код не трогаем.
  • C
    Сверить путь до стадии: канон — 00_Setup/06_Enrichment/ (нумерованные подпапки + _tools/project.env); донор-исток плоский: v4.0 — 01_Media/Source/Setup/Review/_analysis/, v4.1 — 00_Setup/05_Review/_analysis/ (имена {code}_v12_* без подпапок). Привести к канону: enrichment_build_v41.py --project <path> --execute.
  • D
    Гнать через Workflow (vision-каталог фан-аутом), долгие mlx — фоном по одному. НЕ перекаталогизировать уже сделанное — только добавить «лайв»-слой.
⚙️ scriptPath глотает внешний args → запекать входы в .js 🖼 stills: ffmpeg-граб без -ss 🎙 один mlx за раз (OOM) 🧹 vision: usable=false на мусор 🔢 планировщик даёт clip_id с префиксом scene/ → стрипать
RYA.AE · Оживление ката — обогащение исходников · метод поверх манифеста монтажа и playbook'а проектов
скопировано ✓