# VIDEO-002: транспорт H.264 и расчёт радиоканала

16 сентября 2026 года. Ветка `video-development`. Выполнен только программный прогон:
`RF TX = 0`. Модуляция, FEC, PHY-заголовок, RRC и рабочий приёмник SDR не менялись.
Коммит и отправка в удалённый репозиторий не выполнялись.

## Исходные данные и предел проверки

Тот же ролик и те же окна движения, что в [VIDEO-001](VIDEO_001.md):
`data/raw/video001/udacity_project_video.mp4`, SHA-256
`651949922042c223375d40bf8929def97dbb62c6ade651d1f5b08eea47127d5f`;
белая машина на 7–13 с и чёрная на 33–39 с. Кодировщик PyAV/libx264 повторно
создал пакеты H.264 с настройками VIDEO-001. Размер *каждого* кадра сверен с
`comparison_traffic_160k.json` или `comparison_traffic_320k.json`.
Исходные окна имеют по 6 с: 30 кадров ROBUST и 60 кадров NORMAL/HIGH QUALITY.
Сырые видеоданные в Git не включены. Результат 198 прогонов находится в
`data/processed/video002/results.json`; запуск:

```powershell
python -m tools.video002_simulation
python -m pytest tests/test_video002_transport.py tests/test_video002_codec.py -q -p no:cacheprovider
```

Прогон моделирует длительность пакета и паузу, подаёт фрагменты на сборщик и
декодирует полные кадры настоящим декодером H.264. Он **не моделирует** ошибки
синхронизации, шум, вероятность CRC-успеха, работу независимого SDR-приёмника и
время CPU для FEC. Контрольная программная линия `SOFTWARE_2MBPS` передаёт
нагрузку 1024 байта за 4,096 мс без RF и нужна для отдельной проверки потерь.

## Формат и правило свежести

`protocol/video_stream_transport.py` добавляет 17-байтный заголовок *внутри*
полезной нагрузки проверенного пакета. Он не заменяет штатные 8 байт заголовка
`protocol.packet` и 4 байта CRC:

| Поле | Байты | Назначение |
|---|---:|---|
| Версия и тип кадра | 1 | Старшие 4 бита — версия 1; младшие — `KEYFRAME=1` или `DELTA_FRAME=2` |
| `stream_id` | 4 | Выбор сеанса сборщика |
| `frame_id` | 4 | Номер с последовательным сравнением и переходом через `2³²` |
| `fragment_index`, `fragment_count` | 2 + 2 | Порядок и общее число, максимум 256 |
| `age_ms` | 2 | Возраст кадра на расчётном конце передачи пакета |
| `payload_length` | 2 | Проверяемая длина части H.264 |

При нагрузке PHY 256 байт остаётся 239 байт изображения; при 512 — 495, при
1024 — 1007. На стороне передатчика очередь ограничена двумя кадрами и 300 мс:
старый кадр сбрасывается даже после частичной отправки, если к округлённому
моменту конца следующего пакета он станет просроченным. Сборщик держит максимум
два незавершённых кадра,
принимает части в произвольном порядке, проверяет длины и противоречивые дубликаты,
не выдаёт неполный кадр и по истечении срока освобождает место. Потеря одного
фрагмента не останавливает приём следующих кадров. Сборщик получает данные только
после внешнего решения PHY/FEC/CRC; `stream_id` сам по себе не аутентифицирует
отправителя. Номер последнего принятого к сборке кадра не позволяет старому
пакету снова стать новым даже после вытеснения 1024 номеров из журнала закрытых
кадров. После перезапуска нужен новый контекст сборщика/сеанса.

Декодер показывает кадр только один раз. После пропуска номера он ждёт полный
опорный кадр и открывает новый контекст H.264. Это осторожное правило: некоторые
P-кадры кодек мог бы восстановить и раньше, но подменять потерянные данные или
показывать повреждённую картинку оператору здесь не разрешено. Показанные
опорные кадры побайтно совпали по SHA-256 с чистым декодированием соответствующего
окна, включая случаи восстановления после потери.

## Чистый прогон при возрасте не более 300 мс

Показаны результаты окон «белая / чёрная машина». Возраст — от захвата исходного
кадра до завершения последнего пакета, без времени кодирования, декодирования и
экрана. `drop` — сброс отправителем по возрасту / по переполнению. Все эти строки
имеют **0% искусственных потерь пакетов**.

| Режим | Канал модели | Показано кадров | Возраст, среднее, мс | Макс. очередь | `drop` |
|---|---|---:|---:|---:|---:|
| ROBUST 320×240/5 | BPSK 256/5 мс | 0/30 · 0/30 | — | 2 | 6/0 · 9/0 |
| NORMAL 640×360/10 | BPSK 256/5 мс | 0/60 · 0/60 | — | 2 | 2/58 · 2/57 |
| HIGH QUALITY 854×480/10 | BPSK 256/5 мс | 0/60 · 0/60 | — | 2 | 2/58 · 2/58 |
| ROBUST | QPSK 500k, 1024/0 мс, расчёт | 30/30 · 30/30 | 53,4 · 65,7 | 1 | 0/0 · 0/0 |
| NORMAL | QPSK 500k, 1024/0 мс, расчёт | 0/60 · 20/60 | — · 115,8 | 2 | 0/6 · 0/4 |
| HIGH QUALITY | QPSK 500k, 1024/0 мс, расчёт | 40/60 · 40/60 | 96,0 · 98,7 | 2 | 0/4 · 0/4 |
| ROBUST | Программные 2 Мбит/с | 30/30 · 30/30 | 11,2 · 13,8 | 1 | 0/0 · 0/0 |
| NORMAL | Программные 2 Мбит/с | 60/60 · 60/60 | 19,2 · 20,0 | 1 | 0/0 · 0/0 |
| HIGH QUALITY | Программные 2 Мбит/с | 60/60 · 60/60 | 19,7 · 20,2 | 1 | 0/0 · 0/0 |

При нынешнем BPSK крупнейшие опорные кадры ROBUST занимают 397 и 479 мс
(`ceil(размер/239) × (11,532+5)`), NORMAL — 926 и 975 мс, HIGH QUALITY — 909 и
893 мс. Поэтому чистая модель с пределом 300 мс не декодирует их. Отказ
NORMAL на расчётной QPSK в одном окне также показывает, что запас по среднему
потоку нельзя считать гарантией прохождения опорных кадров.

## Потери пакетов и восстановление

Затравка генератора `20260916`; вероятность относится к *передаваемому пакету*.
Ниже число показанных кадров на контрольной программной линии в окнах
«белая / чёрная машина» из 30 или 60 исходных. `burst` удаляет первые 2/5/10
пакетов потока. JSON содержит каждую из 198 комбинаций, в том числе те же
потери на двух расчётных радиопрофилях, номера показанных кадров, потери кадров,
время восстановления, возраст, глубину очереди и сбросы.

| Потеря | ROBUST | NORMAL | HIGH QUALITY |
|---|---:|---:|---:|
| Случайная 0% | 30/30 · 30/30 | 60/60 · 60/60 | 60/60 · 60/60 |
| Случайная 1% | 30/30 · 30/30 | 55/60 · 51/60 | 48/60 · 47/60 |
| Случайная 2% | 26/30 · 25/30 | 39/60 · 33/60 | 39/60 · 38/60 |
| Случайная 5% | 21/30 · 19/30 | 6/60 · 5/60 | 18/60 · 27/60 |
| Случайная 10% | 15/30 · 19/30 | 5/60 · 5/60 | 12/60 · 11/60 |
| Случайная 20% | 0/30 · 0/30 | 0/60 · 0/60 | 0/60 · 0/60 |
| `burst` 2/5/10 пакетов | 25/30 · 25/30 | 50/60 · 50/60 | 50/60 · 50/60 |

Отдельные сценарии с потерей первого фрагмента опорного кадра №5/10 и P-кадра
№6/11 подтвердили восстановление на следующем полном опорном кадре №10/20.
На программной линии после потери опорного кадра это заняло от 1025 до 1057 мс,
после потери P-кадра — от 825 до 957 мс. Значения включают ожидание следующего
GOP длиной 1 с и доставку его первого кадра. При случайной потере 20% ни один
полный опорный кадр в этих коротких окнах не прошёл: время восстановления
не определено. Скрытых повторов старого `frame_id` нет; число разных изображений
и их SHA-256 записаны в результате.

## Расчёт радиопакета

Основа Lab045/VIDEO-001: 1280 символов преамбулы, 144 символа трёхкратного
PHY-заголовка, 42 интервала защитных областей и RRC; `protocol.packet` добавляет
12 байт (заголовок и CRC), свёрточный FEC 1/2 кодирует также 6 хвостовых бит.
Для нагрузки PHY `P` байт тело содержит `2 × ((P+12) × 8 + 6)` кодовых бит.
BPSK передаёт один бит на символ. Расчётная QPSK оставляет преамбулу и
PHY-заголовок двоичными и передаёт тело по два бита на символ; такой смешанный
пакет **не реализован и не проверен**. Все строки считают полный пакет даже для
последнего неполного фрагмента, поэтому оценка задержки консервативна.
Накладная доля — `1 − полезные биты изображения / (сырая скорость × период
пакета с паузой)`; она включает паузу, служебные поля и FEC.

| Модуляция, ксимв/с | Сырая скорость, кбит/с | Символ, мкс | Оценка ширины при RRC 0,35, кГц |
|---|---:|---:|---:|
| BPSK 500 | 500 | 2 | 675 |
| QPSK 250 | 500 | 4 | 337,5 |
| QPSK 500 | 1000 | 2 | 675 |

В каждой ячейке ниже: **эфирное время пакета, мс / полезная скорость видео,
кбит/с / накладная доля, %**. Пауза в заголовке столбца дана в миллисекундах.

| Модуляция | PHY, байт | 5 мс | 2 мс | 1 мс | 0 мс |
|---|---:|---:|---:|---:|---:|
| BPSK 500 | 256 | 11,532 / 115,7 / 76,9 | 11,532 / 141,3 / 71,7 | 11,532 / 152,6 / 69,5 | 11,532 / 165,8 / 66,8 |
| BPSK 500 | 512 | 19,724 / 160,2 / 68,0 | 19,724 / 182,3 / 63,5 | 19,724 / 191,1 / 61,8 | 19,724 / 200,8 / 59,8 |
| BPSK 500 | 1024 | 36,108 / 196,0 / 60,8 | 36,108 / 211,4 / 57,7 | 36,108 / 217,1 / 56,6 | 36,108 / 223,1 / 55,4 |
| QPSK 250 | 256 | 14,464 / 98,2 / 80,4 | 14,464 / 116,1 / 76,8 | 14,464 / 123,6 / 75,3 | 14,464 / 132,2 / 73,6 |
| QPSK 250 | 512 | 22,656 / 143,2 / 71,4 | 22,656 / 160,6 / 67,9 | 22,656 / 167,4 / 66,5 | 22,656 / 174,8 / 65,0 |
| QPSK 250 | 1024 | 39,040 / 182,9 / 63,4 | 39,040 / 196,3 / 60,7 | 39,040 / 201,2 / 59,8 | 39,040 / 206,4 / 58,7 |
| QPSK 500 | 256 | 7,232 / 156,3 / 84,4 | 7,232 / 207,1 / 79,3 | 7,232 / 232,3 / 76,8 | 7,232 / 264,4 / 73,6 |
| QPSK 500 | 512 | 11,328 / 242,5 / 75,7 | 11,328 / 297,1 / 70,3 | 11,328 / 321,2 / 67,9 | 11,328 / 349,6 / 65,0 |
| QPSK 500 | 1024 | 19,520 / 328,5 / 67,1 | 19,520 / 374,3 / 62,6 | 19,520 / 392,6 / 60,7 | 19,520 / 412,7 / 58,7 |

Текущая конфигурация — первая ячейка: 115,7 кбит/с видео **при 100% доставке**.
В VIDEO-001 фигурировали 118,1 кбит/с JPEG, поскольку его фрагментный
заголовок занимает 12, а новый H.264 — 17 байт. Один сеанс Lab066 доставил
10/16 пакетов; это наблюдение не является постоянной вероятностью доставки и
не подставлено в расчёт. Предельный размер *всего* пакета PHY сейчас 1024 байта:
нагрузка 1024 плюс 12 байт `protocol.packet` его превышает. Lab045 в действующем
плане формирует нагрузку ровно 256 байт; строки 512/1024 потребуют разработки и
проверки даже при арифметическом соблюдении размера. Уменьшение паузы также
не проверялось через радио.

## Запас относительно реальных пиков VIDEO-001

Максимум односекундного видеопотока среди двух окон приведён в таблице.
Здесь «запас 20%» определён как
`полезная скорость ≥ пик × 1,2`, «запас 50%» — как `≥ пик × 1,5`.

| Режим | Пик, кбит/с | Нужно при 20%, кбит/с | Нужно при 50%, кбит/с | Вывод для предела 500 кбит/с |
|---|---:|---:|---:|---|
| ROBUST 320×240/5 | 171,7 | 206,0 | 257,5 | Оба запаса возможны только в ещё не проверенных вариантах |
| NORMAL 640×360/10 | 375,8 | 451,0 | 563,7 | 20% да, 50% нет |
| 640×480/10 | 380,9 | 457,1 | 571,4 | 20% да, 50% нет |
| HIGH QUALITY 854×480/10 | 455,6 | 546,7 | 683,3 | Даже 20% нет |
| 1280×720/5 | 440,6 | 528,8 | 661,0 | Даже 20% нет |

Из рассчитанных пакетов 20% запаса для ROBUST дают, например, BPSK
500/1024/0 (223,1 кбит/с) или QPSK 500/256/0 (264,4 кбит/с); 50% — только
некоторые QPSK 500. Все эти варианты требуют разработки и проверки. Максимум
всей таблицы, QPSK 500/1024/0, равен 412,7 кбит/с и не покрывает 20% запас
для NORMAL, 640×480, HIGH QUALITY или 1280×720. Сам инженерный диапазон
400–500 кбит/с покрывает 20% лишь для NORMAL и 640×480 в своей верхней части.
Расчёт не разрешает называть ни один из режимов прошедшим по текущему радиоканалу.

## Итог VIDEO-002

| Требуемое поле | Результат |
|---|---|
| `VIDEO TRANSPORT` | **PARTIAL**: формат, очередь, сборка и H.264 работают в программной модели; на текущем радиобюджете чистый 300-мс прогон не показывает кадров |
| `BOUNDED QUEUE` | **YES**, максимум 2 кадра |
| `STALE FRAME DROP` | **YES**, срок 300 мс, метрики в JSON |
| `KEYFRAME RECOVERY` | На контрольной линии после потери IDR кадр №10/20, 1025–1057 мс; SHA-256 совпал с чистым декодированием |
| `LOSS TESTS` | 0/1/2/5/10/20% и серии 2/5/10 пакетов, фиксированная затравка, два окна, три видеорежима, три канала модели |
| `CURRENT PHY USEFUL RATE` | 115,7 кбит/с H.264 при 256 байтах, 5 мс, без потерь; измеренной устойчивой скорости H.264 нет |
| `BEST BPSK PACKETIZATION CANDIDATE` | 1024 байта / 0 мс: расчёт 223,1 кбит/с, но полный пакет 1036 байт превышает действующий предел; среди допустимых по размеру 512/0 даёт 200,8 кбит/с |
| `QPSK 250K CALCULATED RATE` | Максимум 206,4 кбит/с при 1024/0; пакет сверх действующего предела |
| `QPSK 500K CALCULATED RATE` | Максимум 412,7 кбит/с при 1024/0; пакет сверх предела, пик NORMAL без 20% запаса |
| `TARGET VIDEO RADIO BUDGET` | 400–500 кбит/с как инженерная цель, не достигнутый результат; для HIGH QUALITY с 20% требуется ≥546,7 кбит/с, для 1280×720/5 — ≥528,8 кбит/с |
| `NEXT RF DEVELOPMENT CANDIDATE` | BPSK 500 ксимв/с, нагрузка 512 байт, пауза 0 мс: один конкретный следующий предмет отдельной разработки и *последующей* проверки независимого приёма. Теоретический предел 200,8 кбит/с, робастный пик с 20% запасом не покрыт. VIDEO-002 не разрешает RF TX |
| `RF TX` | **0** |
| `COMMIT` / `PUSH` | **NOT PERFORMED** / **NOT PERFORMED** |

Проверка после исправлений: 11 целевых тестов VIDEO-002 и 4 теста VIDEO-001
прошли. Независимый проверяющий повторил все 198 симуляций и все 36 расчётных
строк; результат совпал с сохранённым JSON. Общий `tools/quick_gate.py` в этом
рабочем дереве не прошёл: у исторических аппаратных лабораторий нет
`data/raw/lab064/tx_metadata.json` и других исходных файлов, а системный
временный каталог pytest недоступен для части тестов. Целевые тесты запускались
с `-p no:cacheprovider`; для тестов VIDEO-001 временный каталог pytest был
явно направлен в это рабочее дерево. Никакая из этих проверок не запускала RF.