# VIDEO-004: скорость программного приёмника и защита видео от потери пакетов

16 сентября 2026 года. Worktree `SDR_Rover_Video`, ветка `video-development`,
исходный HEAD `af7c05f`. Все опыты программные: `RF TX = 0`, SDR не открывался.
Файлы VIDEO-001/002/003 и производственный BPSK не заменялись. Коммит и push
не выполнялись.

## Вывод и граница опыта

`VIDEO-004 STATUS = PARTIAL`. Прогретый доступный программный путь выполнил
порог скорости: фактор реального времени **0,130** на исходном 32-пакетном
сигнале и **0,131** на 40-пакетном пути с внешним FEC. Порог `≤0,67` и
предпочтительный `≤0,50` пройдены на этом ПК. Восстановлены четыре стёртых
пакета и четыре видеокадра побайтно. Существующий H.264 SHORT_GOP проверен
отдельной моделью доставки.

Это **AVAILABLE SOFTWARE PATH REALTIME FACTOR**, а не скорость полного SDR RX.
В потоковом замере сигнал уже дан с известными символьными отсчётами.
`TIMING RECOVERY = NOT_IMPLEMENTED_IN_THIS_BENCHMARK` и
`CARRIER TRACKING FROM RAW IQ = NOT_IMPLEMENTED_IN_THIS_BENCHMARK`.
RRC-проверка с известными тактами существует отдельно. Её время не включено
в число 0,130. Модель не оценивает операторское качество и не доказывает
устойчивость через эфир.

При пяти затравках и двух шестисекундных окнах NORMAL 640×360/10 лучший
проверенный для 1–5% потерь вариант `QPSK 500 / inner FEC 2/3 / outer 8+1`
с дополнительным проверочным пакетом для блока опорного кадра показал
**591/600 кадров при 1%** и **498/600 при 5%**. Потеря 102 кадров из 600
при 5% вместе с малым запасом пропускной способности не позволяет объявить
этот режим надёжно поддерживаемым. `NORMAL SUPPORTED IN SOFTWARE MODEL = NO`
для всего диапазона 1–5% с принятым в VIDEO-003 запасом 20% к пику.
Это не отрицание отдельных
успешных прогонов.

## Скорость: одинаковый вход до и после

Канонический вход содержит 32 полных PHY-пакета QPSK 500 ксимв/с, inner FEC
2/3, 9 dB `Eb/N0`, сдвиг несущей 73 Гц и 42 переходных символа на пакет.
Затравка `20260916`; файл `data/processed/video004/canonical_symbols.npy`
проверяется по SHA-256 из `canonical_manifest.json`. Приёмник узнаёт размер
пакета из принятого PHY-заголовка. Эталонные SHA передаются только проверке
после CRC. Длительность 32-пакетного сигнала: **0,48736 с**.

`cProfile` использован для поиска затрат. Числа скорости ниже получены
отдельно через `time.perf_counter()` без профилировщика. Для каждого прохода
записаны повторные измерения; указан средний по порядку из повторов.

| Замер | Исходный декодер | Прогретый Numba | Ускорение |
|---|---:|---:|---:|
| 32 пакета, приём и видеозаголовок | 2,690 с; фактор **5,520** | 0,0635 с; фактор **0,130** | **42,36×** |
| Только Витерби, те же 32 мягких слова | 2,125 с; фактор **4,360** | 0,0270 с; фактор **0,055** | **78,68×** |
| 256 пакетов, длинный контроль | фактор **4,518** | фактор **0,133** | 34,1× |
| 40 пакетов, CRC → внешний FEC → сборка видеокадра | фактор **4,446** | фактор **0,131** | **33,90×** |

Первый полный проход с компиляцией Numba занял **0,929 с**; это отдельная
стоимость запуска, не включённая в прогретый фактор. Numba 0.61.2 и
llvmlite 0.44.0 взяты из уже существующего локального набора проекта.
Компиляция работает с `fastmath=False`, а отсутствие Numba даёт явную ошибку
выбранного JIT-режима. После отказа CRC другой декодер не запускается.
Эталонные битовые выходы, решения QPSK, CRC, пакеты и SHA видеоданных до и
после совпали. Длинный поток также совпал на всех 256 пакетах.

Предварительный `cProfile` исходного 32-пакетного пути относил 2,743 из
3,196 с профилируемого времени к Витерби; внутри было 262 336 вызовов
`argmin`. После JIT основными расходами стали поиск преамбулы и оценка
несущей. Для нового 40-пакетного пути профиль приведён отдельно:

| Этап | Время `cProfile`, мс | Доля 91,4 мс | Вызовы | Основной массив или копия |
|---|---:|---:|---:|---|
| Витерби вместе с вызовом декодера | 34,8 | 38,1% | 40 | `choices`: 524 672 байта на полный пакет внутри Numba |
| Поиск преамбулы | 27,1 | 29,7% | 40 | короткие срезы по 1280 символам |
| Коррекция фазы/частоты | 11,3 | 12,4% | 120 | копия только текущего заголовка или тела |
| Оценка фазы/частоты | 9,3 | 10,2% | 80 | временные массивы пилота и заголовка |
| Снятие прокалывания | 1,59 | 1,7% | 40 | 16 396 `float64`, около 131 Кбайт на пакет |
| Решения QPSK | 0,56 | 0,6% | 40 | около 98 Кбайт мягких значений |
| Разбор `protocol.packet` и CRC | 0,33 | 0,4% | 40 | до 1024 байт пакета |
| Сборщик внешнего FEC | 1,61 | 1,8% | 36 | буфер максимум 8 блоков; четыре матричных восстановления |
| Выдача фрагмента видеосборщику | 0,36 | 0,4% | 32 | повторная упаковка в байты не выполняется |
| RRC | отдельно | вне пути | один контроль | 11,09 мс на один пакет при известных тактах |
| Восстановление тактов и слежение из IQ | `NOT_IMPLEMENTED` | вне пути | 0 | не измерялись |

Строки со вложенными вызовами нельзя складывать: например, снятие
прокалывания входит во время декодера. Одиночный RRC-контроль с 16 выборками
на символ прошёл CRC, но его 11,09 мс нельзя прибавлять к потоку как
доказательство готового IQ-приёмника. `tracemalloc` показал пик Python-памяти
13,69 Мбайт до правок и 1,07 Мбайт после на 32 пакетах. Он не учитывает всю
нативную память NumPy и Numba.

## Защита от стирания пакета

Внешний систематический код использует уже существующую в проекте
арифметику GF(256) из `protocol/packet_erasure_fec.py`. Упаковка Lab028 не
используется. Новый символ содержит 16 байт метаданных блока, 2 байта длины,
4 байта времени создания кадра и проверенный 13-байтный видеозаголовок.
Максимум данных видео: **977 байт** в полном payload PHY 1012 байт.
Все внешние символы имеют одинаковую длину для точного восстановления
последнего короткого фрагмента. Внешний код восстанавливает стирания после
строгого CRC; он не исправляет неизвестные ошибочные биты внутри пакета.

Систематический фрагмент сразу передаётся сборщику. При потерях декодирование
блока начинается после получения любых `K` различных символов. Полученный
после 300 мс фрагмент отвергается по времени создания кадра. Буфер
ограничен восемью блоками; дубли и противоречивые метаданные проверяются.
Тесты подтвердили одну потерю, потери до `R`, отказ при числе потерь больше
`R`, точное восстановление байтов и короткого последнего фрагмента.

Для полных пакетов расчётный бюджет без пауз:

| K+R | Доля проверочных пакетов | 2/3: чистое видео, кбит/с | 3/4: чистое видео, кбит/с | Время полного блока 2/3, мс |
|---|---:|---:|---:|---:|
| 8+1 | 11,11% | 456,176 | 501,122 | 137,07 |
| 8+2 | 20,00% | 410,558 | 451,010 | 152,30 |
| 12+2 | 14,29% | 439,884 | 483,225 | 213,22 |
| 12+3 | 20,00% | 410,558 | 451,010 | 228,45 |
| 16+2 | 11,11% | 456,176 | 501,122 | 274,14 |
| 16+4 | 20,00% | 410,558 | 451,010 | 304,60 |

Это предел для полного блока с заполненными пакетами. Последний частичный
блок и защита опорного кадра меняют фактическую долю чётности. Например,
для NORMAL 8+1 с усилением опорных блоков расчёт по числу реально созданных
символов в двух окнах даёт **424,922 / 425,142 кбит/с**. Пик SHORT_GOP 400k
за одну секунду, худший из двух окон: **408,8 кбит/с**. Запас в этой паре
всего около 1,04, без учёта ошибок внутреннего PHY. Блок 16+4 из 20 полных
пакетов занимает 304,6 мс, уже больше срока кадра без ожидания накопления
данных. Для каждого прогона модель учитывает готовность исходных фрагментов,
момент появления чётности и истечение срока.

## Потери, перемежение и опорные кадры

В модели использованы настоящие H.264 пакеты, короткий GOP, ограниченный
сборщик VIDEO-002 и декодер PyAV. Случайные потери применяются независимо
к передаваемым радиопакетам; 1440 основных прогонов покрывают ROBUST,
NORMAL и HIGH QUALITY, два окна, обе скорости внутреннего FEC, шесть схем,
равномерную и усиленную защиту, уровни 0/1/2/5/10/20% и серии 2/5/10.
Для выбора NORMAL дополнительно выполнены 180 прогонов на пяти фиксированных
затравках `20260916…20260920`. Числа ниже относятся к 10 окнам по 60 кадров.

| Внешняя защита, inner 2/3 | 1%: показано / 600 | 5%: показано / 600 | 10%: показано / 600 | 5%: кадр/с | 5%: доля потерь кадров |
|---|---:|---:|---:|---:|---:|
| 8+1 одинаковая | 594 | 452 | 264 | 7,53 | 24,7% |
| 8+1, опорный блок +1 parity | 591 | **498** | 330 | **8,30** | **17,0%** |
| 8+2 одинаковая | 580 | 484 | **363** | 8,07 | 19,3% |

При 1% лучшая доля в этой выборке у одинаковой 8+1; при 5% у усиленной
8+1; при 10% у одинаковой 8+2. Эти короткие реализации не дают оценки
длительного канала. В варианте 8+1 с усилением среднее время от первого
непоказанного кадра до следующего показанного опорного кадра при 5%
составило **535 мс** против **665 мс** у одинаковой 8+1. Это показатель
данной модели и затравок, а не обещание восстановления при любой серии.

В отдельном контроле две потери источников **одного блока опорного кадра**
дали 55/60 показанных кадров в каждом окне при 8+1 без усиления; следующий
опорный кадр появился через 652/668 мс. При усилении блока до двух parity
получено 60/60, два фрагмента восстановлены до срока и провала изображения
не было. Одну потерю восстанавливали оба варианта.

Проверка перемежения глубины 2 отклонена. Даже при 0% потерь она показала
лишь 24/120 кадров для 8+1, 21/120 для 8+2 и 3/120 для 12+2 в NORMAL:
ожидание фрагментов следующего блока нарушило срок 300 мс. Без перемежения
при 0% эти схемы показали 120/120. Серии 2/5/10 сохранены отдельно в JSON;
уменьшение влияния серии не окупило задержку в этом способе чередования.

При одинаковых заданных стираниях пакетов inner FEC 2/3 и 3/4 дали одинаковые
числа показанных кадров для трёх сравниваемых схем NORMAL на пяти затравках;
3/4 даёт больше расчётной ёмкости. Эта модель не создаёт битовых ошибок.
Контроль VIDEO-003 при 3 dB `Eb/N0` на пакетах меньшей длины дал 13/32 CRC
для 2/3 против 3/32 для 3/4. Его нельзя переносить как точную вероятность
для максимальных пакетов, но оснований заменить первый диагностический
кандидат на 3/4 пока нет.

## CODE QUALITY AUDIT

Исходная инвентаризация восьми модулей: 1967 строк, 70 функций. Сейчас те же
восемь модулей содержат 2008 строк и 72 функции; новые модули Витерби и
внешнего FEC содержат ещё 309 строк и 11 функций. Размер кода здесь не
критерий качества. Рабочая цепочка: символы → преамбула/PHY → QPSK → снятие
прокалывания → Витерби → CRC → внешний FEC → свежий видеофрагмент.

| ITEM | BEFORE | ACTION | AFTER | EFFECT |
|---|---|---|---|---|
| Витерби | Python-цикл, 262 336 `argmin` за 32 пакета | JIT со скалярным выбором ветви и `fastmath=False` | те же биты | 78,68× для Витерби |
| Коррекция несущей | два прохода по всему оставшемуся потоку на пакет | ограничена заголовком и текущим телом | те же пакеты/CRC | фактор пути 5,520 → 0,130 вместе с JIT |
| Проверка конечности | сканирование всего суффикса на каждом пакете | проверяется кандидат и его тело | повреждение текущего пакета отвергается | 256 пакетов: фактор 0,288 → 0,133 |
| Маска FEC и преамбула | повторные массивы и PRBS7 | точный арифметический счёт, ограниченный кеш неизменяемых масок | те же кодовые длины и биты | меньше выделений |
| Сборщик блоков | состояние росло с числом блоков | ограничен восемью блоками, поздние повторы игнорируются | строгие кадры и счётчики без изменений | ограничена память |
| Подача v2-фрагмента | требовала бы повторной упаковки под v1 | отдельный проверяемый вход `offer_fragment` | v1 сохранён | меньше копий в горячем пути |

Классификация существенных проверок: **A, production safety**: длины PHY и
FEC, конечность текущих символов, метаданные блока, возраст, границы буфера,
CRC и отказ от старого кадра оставлены. **B, development assertion**:
сравнение SHA, точных битов и ожидаемого числа кадров живёт в тестах и
инструментах опыта. **C, offline diagnostic**: `cProfile`, `tracemalloc`,
JSON и исходные H.264 сравнения находятся в `tools/`, вне приёмника.
**D, duplicated check**: повторный проход по всему суффиксу убран;
проверка полей на публичном входе `offer_fragment` оставлена, хотя текущий
вызывающий код уже разобрал заголовок. **E, hot-loop check**: проверка
конечности вынесена из полного потока в границу текущего пакета, а
Numba-цикл Витерби не строит NumPy-массивы на каждом шаге.

| Существенная runtime-проверка | Место | Категория | Решение |
|---|---|---|---|
| PHY-длина, версия и CRC пакета | `video003_modem`, `packet` | A | Оставить до выдачи данных внешнему FEC |
| Длина и конечность мягких значений | `punctured_fec` | A/E | Оставить один раз перед решёткой |
| Диапазоны K/R, индекс, поток и длина символа | `video004_erasure` | A | Оставить перед накоплением блока |
| Время создания и возраст фрагмента | `video004_erasure`, `video_stream_transport` | A | Оставить; после 300 мс не выдавать |
| Предел буфера и повтор старого кадра | оба сборщика | A | Оставить с ограничением 8 блоков и 2 кадров |
| SHA эталона, точные биты и ожидаемые счётчики | `tests/`, `tools/video004_*` | B/C | Держать вне приёмника |
| Повторная проверка полей на публичном входе | `FrameReassembler.offer_fragment` | D → A | Оставить как защиту от другого вызывающего кода |
| Сканирование всего хвоста потока | прежний `receive_frame` | E | Заменить проверкой текущего кандидата и тела |

| ITEM | LOCATION | WHY SUSPICIOUS | ACTION |
|---|---|---|---|
| Сборка `np.concatenate` и SHA эталона | `tools/video004_benchmark.py` | массивы и знание исходного пакета | **KEEP** только в генераторе и проверке после CRC |
| RRC roundtrip | `protocol/video003_modem.py` | не является поточным IQ-приёмом | **KEEP** как отдельный контроль; вне горячего пути |
| Упаковка Lab028 | `protocol/packet_erasure_fec.py` | лишний заголовок и иной формат пакета | **KEEP** для старых лаб; новый видеоформат её не вызывает |
| `_linear_combine` | `protocol/packet_erasure_fec.py` | внутренний API другого модуля | **KEEP** проверенную арифметику; публичный общий API отложить |
| Преобразования в решётке | прежний `convolutional_fec.py` | массивы на каждом шаге | **REWRITE** в отдельном JIT-варианте; старый код сохранён как эталон |
| Большая функция `simulate` | `tools/video004_transport.py` | смешивает график передачи, потери и H.264 | **KEEP** как автономную модель с фиксированными входами; не импортируется рабочим приёмником |

Генерация сигнала, `np.concatenate`, SHA и сравнение с эталоном остались в
`tools/` как диагностика. В критическом пути нет
графиков, исторических Lab-проверок, verifier, подробного JSON и сравнения с
исходными пакетами. Нужные проверки повреждённых данных не удалялись.

После правок повторены модемные векторы, FEC/CRC, тесты стираний,
1440 моделей потерь, 48 случаев перемежения, 180 случаев пяти затравок и
оба замера производительности. Сравнение копии 1440 результатов до и после
аудита: показанные кадры, возраст и восстановления совпали; изменилось
лишь исправленное диагностическое поле числа неполных блоков в 480 строках.
`BEHAVIOR EQUIVALENT = YES` для строгого приёма и показа кадров.

`RUFF = NOT_RUN — TOOL NOT INSTALLED`.
`coverage`, `mypy`, `pyright`, `vulture`, `radon` также `NOT_RUN — TOOL NOT INSTALLED`.
Постоянные новые зависимости не устанавливались. Правило полного обзора после
крупного этапа сохраняется для CONTROL-001/002; мелким правкам достаточно
`pytest`, доступного `ruff` и `git diff --check`.

## Машинные результаты и повторение

Все файлы находятся в `data/processed/video004/`: канонический 32-пакетный
сигнал и его manifest, `benchmark_before.json`, `benchmark_after.json`,
`viterbi_benchmark.json`, 256-пакетный сигнал и `benchmark_256.json`,
40-пакетный `pipeline_benchmark.json`, `transport_results.json`,
`interleaving_results.json`, `normal_seed_sweep.json` и
`keyframe_recovery.json`. Эталонные пакеты не передаются декодеру.

Из корня VIDEO worktree, с доступной Numba 0.61.2:

```powershell
python -B -X utf8 -m tools.video004_benchmark --phase after --numba-packages C:\Users\user\Desktop\projects\SDR_Rover\.lab053_cpu_runtime\packages
python -B -X utf8 -m tools.video004_viterbi_benchmark --numba-packages C:\Users\user\Desktop\projects\SDR_Rover\.lab053_cpu_runtime\packages
python -B -X utf8 -m tools.video004_longrun --numba-packages C:\Users\user\Desktop\projects\SDR_Rover\.lab053_cpu_runtime\packages
python -B -X utf8 -m tools.video004_pipeline_benchmark --numba-packages C:\Users\user\Desktop\projects\SDR_Rover\.lab053_cpu_runtime\packages
python -B -X utf8 -m tools.video004_transport
python -B -X utf8 -m tools.video004_interleaving
python -B -X utf8 -m tools.video004_seed_sweep
python -B -X utf8 -m tools.video004_keyframe
python -B -X utf8 -m tools.video_gate --numba-packages C:\Users\user\Desktop\projects\SDR_Rover\.lab053_cpu_runtime\packages
```

Старый `benchmark_before.json` повторно не создаётся после правок: он
фиксирует исходный код VIDEO-003 на том же сигнале. На другой машине нужно
установить зависимости из `requirements-video.txt`; абсолютный путь локальных
пакетов Numba в командах относится только к этому ПК. Замер скорости следует
повторять на целевом Raspberry/Jetson отдельно.

## Обязательные поля результата

| Поле | Значение |
|---|---|
| `VIDEO-004 STATUS` | `PARTIAL` |
| `QPSK 500K FEC 2/3 INITIAL REALTIME FACTOR` | **5,520**, 32 пакета, доступный путь VIDEO-003 |
| `OPTIMIZED REALTIME FACTOR` | **0,130**, тот же 32-пакетный сигнал, прогретый путь |
| `REALTIME TARGET >=1.5X` | `PASS` для доступного пути; также пройден предпочтительный фактор ≤0,50 |
| `MAIN BOTTLENECK BEFORE OPTIMIZATION` | Витерби, 2,743/3,196 с по `cProfile` |
| `MAIN OPTIMIZATIONS` | JIT без `fastmath`; обработка только текущего пакета; ограниченная проверка конечности; кеш преамбулы и маски |
| `JIT FIRST RUN TIME` | 0,929 с для первого полного 32-пакетного прохода |
| `WARM RUN TIME` | медиана 0,0635 с на 32 пакета |
| `STEADY-STATE REALTIME FACTOR` | **0,130** |
| `VITERBI REALTIME FACTOR BEFORE / AFTER` | **4,360 / 0,055** |
| `AVAILABLE PIPELINE REALTIME FACTOR BEFORE / AFTER` | **4,446 / 0,131** на 40 пакетах с четырьмя стираниями |
| `VITERBI SPEEDUP` | **78,68×** |
| `FULL AVAILABLE PIPELINE SPEEDUP` | **33,90×** |
| `TRANSPORT ERASURE CODE` | Систематический GF(256), отдельная видеооболочка |
| `BEST DATA/PARITY CONFIGURATION` | 8+1 с дополнительным parity для опорного блока в диапазоне 1–5% данной модели; 8+2 одинаковая лучше при 10% |
| `PACKET LOSS 1%: DISPLAYED FPS / FRAME LOSS` | 8+1 с усилением: **9,85 кадр/с; 1,5%**, 591/600 |
| `PACKET LOSS 5%: DISPLAYED FPS / FRAME LOSS` | **8,30 кадр/с; 17,0%**, 498/600 |
| `PACKET LOSS 10%: DISPLAYED FPS / FRAME LOSS` | 8+1 с усилением: **5,50 кадр/с; 45,0%**; 8+2 одинаковая: 6,05 кадр/с; 39,5% |
| `BURST LOSS RESULT` | Глубина перемежения 2 непригодна при сроке 300 мс: даже при 0% потерь лишь 24/120 кадров для 8+1 |
| `KEYFRAME RECOVERY` | Две потери в одном блоке: 55/60 без усиления, 60/60 с усилением, в обоих окнах |
| `NET VIDEO RATE AFTER OUTER FEC` | 8+1 с усилением NORMAL: **424,922 / 425,142 кбит/с**; равномерная 8+2: около 409,4 / 409,8 кбит/с с учётом частичного блока |
| `NORMAL 640x360/10 SUPPORTED IN SOFTWARE MODEL` | `NO` для устойчивой работы на всём интервале 1–5% с инженерным запасом |
| `INNER FEC 2/3 VS 3/4 RESULT` | При заданных стираниях кадры одинаковы в сравниваемых схемах; более слабый внутренний код 3/4 не подтвердил общего выигрыша с учётом AWGN-контроля VIDEO-003 |
| `BEST NEXT RF CANDIDATE` | Отложен; диагностический программный кандидат: QPSK 500 ксимв/с, inner 2/3, outer 8+1 с усилением опорного блока, SHORT_GOP 400k |
| `WHY` | Порог CPU выполнен, но при 5% потерь не показаны 102/600 кадров, запас скорости около 1,04 и нет проверки полного IQ/RF-приёмника |
| `TESTS BEFORE / AFTER` | VIDEO-003: 123; до заключительного обзора VIDEO-004: 143; после: **145 passed** |
| `BEHAVIOR EQUIVALENT` | `YES` для битов, CRC, пакетов и кадров на фиксированных входах |
| `HOT PATH REMAINING BOTTLENECK` | По `cProfile`: Витерби 34,8 мс, поиск преамбулы 27,1 мс на 40 пакетов; отсутствуют timing recovery и IQ carrier tracking |
| `VIDEO-SPECIFIC GATE` | **PASS: 145 тестов**, сверка артефактов и повторный замер |
| `RF TX` | `0` |
| `SDR HARDWARE` | `NOT ACCESSED` |
| `COMMIT / PUSH` | `NOT PERFORMED / NOT PERFORMED` |

Отдельный общий `python tools/quick_gate.py` дал 1070 passed, 2 skipped и
1 failed: в этом worktree отсутствует исторический
`data/raw/lab064/tx_metadata.json`, нужный проверке Lab065. Целевой VIDEO-шлюз
прошёл: 145 passed. Это разные наборы проверок.

Следующий RF-опыт требует отдельного прямого разрешения. VIDEO-005 в этой
работе не начинается.