Record final video timing measurements and identify fragment budget continuation gap

doc/call_video.txt

@@ -741,3 +741,33 @@ drop_late/drop_schedule=0, av=-43819..39982мкс. Desktop 5737 показов
 Снимки /tmp/video-playout-live-{desktop,sm}.log. После этого замера добавлен контекст максимального
 промежутка и уточнён абсолютный срок сна Android; финальная сборка установлена на Samsung и Q8.
 Следующая проверка: по gap_* установить источник остаточных пауз и late drops, не расширяя A/V-границы вслепую.
+
+Проверка финальной сборки, звонок 9002196988226353494, 15.10.2026
+Снимки /tmp/video-playout-final-live-{desktop,sm}.log, сводка /tmp/video-playout-final-live-summary.json.
+Последние 20 секунд: Samsung 29.94fps, ноль drop_late/drop_schedule; videoPTS-audioPTS на release
++14.664..+40.000мс. Медиана секундных максимумов интервала 43.14мс; отдельные длинные интервалы остаются.
+Desktop 29.61fps, 8 drop_late за это окно, без drop_schedule; A/V -49.740..+2.763мс.
+Исходный период Android-камеры около 33.308мс, но для самых длинных промежутков на desktop
+медианный gap_rx=52.91мс при gap_dispatch=3.95мс. Нерегулярность видна уже на входе RX port.
+На Samsung: gap_pts обычно ~36мс, gap_rx медиана 56.34мс, gap_dispatch 7.06мс;
+был исходный промежуток 68мс. Поэтому все остаточные паузы нельзя приписать приёмному таймеру.
+
+По согласованным send/receive PTS двух направлений phone_boot-host_boot ограничен
+[-796330268513,-796330265026]мкс: погрешность оценки +/-1.744мс.
+После завершения постановки кадра отправителем до полной сборки получателем: медианы
+3.03мс desktop->SM (42 выборки) и 3.37мс SM->desktop (33). Это не включает queue_age отправителя.
+На SM sensorPTS->send медиана 124.08мс, максимум 163.26мс. Для desktop mappedPTS->send
+медиана 30.28мс, encode 23.11мс. Разные способы получения capture PTS не дают точного
+сравнения стекло-стекло. На SM receive->decode 11.78мс, decode->release 20.68мс,
+release->commit 23.29мс по имеющимся совпавшим выборкам; commit не означает физический scanout.
+
+Выявлен отдельный механизм искусственного ожидания TX: flush выдаёт до 16 фрагментов по 1200 байт,
+затем продолжение вызывается лишь новым видео, отправкой audio или таймером 50мс.
+Это граница 19200 байт на один вызов, хотя канал может быть свободен. В выборке Samsung:
+31 кадр <=19200 байт имел queue_age 0..0.2мс; кадры 45309/46333 байт — 1.9/39.9мс.
+Снимки непустой TX-очереди показывают held=0, audio_busy=transport_busy=0, то есть ожидания
+аудиопозиции в этих снимках нет. Покадрового счётчика выхода по budget/debt сейчас нет;
+39.9мс нельзя целиком объявить только budget, но само ожидание внешнего события после budget
+подтверждено кодом. Следующее исправление: ограниченное отменяемое продолжение отправки при
+исчерпании budget и готовых данных, с сохранением проверок аудиопозиции, сетевого долга и fairness uasync.
+Не увеличивать очереди/допуск A/V для маскировки этой паузы. В этом диагностическом проходе код не менялся.

doc/tasks.md

@@ -13,6 +13,11 @@
     Живой звонок 11342339676311998023: SM ~29.2fps без drops, desktop ~26.4fps с ~10% late drops.
     Остаточные паузы и обратное направление ещё требуют проверки. В финальную сводку добавлены
     gap_pts_us/gap_rx_us/gap_dispatch_us для точного разделения причин; подробности в doc/call_video.txt.
+    Финальная сборка, звонок 9002196988226353494: последнее окно SM 29.94fps без drops,
+    desktop 29.61fps и 8 late drops/20с. Длинные интервалы видны уже при поступлении кадров.
+    Обнаружено ожидание внешнего события после лимита TX flush 16x1200 байт; крупный SM-кадр
+    имел queue_age=39.9мс. Следующий шаг — отменяемое продолжение bounded flush без ожидания audio/tick,
+    с сохранением сетевого backpressure и A/V-барьера; полностью ровный показ пока не подтверждён.
 
 [+] **Измерить задержку видео desktop -> Samsung по этапам** — 15.10.2026:
     Добавлена выборочная трассировка по одному окну исходного PTS в секунду: encode/send/receive,