From ff51e30a557525c843ccb784ad782b5553d929f2 Mon Sep 17 00:00:00 2001 From: evgeny Date: Thu, 15 Oct 2026 16:30:13 +0200 Subject: [PATCH] Record final video timing measurements and identify fragment budget continuation gap --- doc/call_video.txt | 30 ++++++++++++++++++++++++++++++ doc/tasks.md | 5 +++++ 2 files changed, 35 insertions(+) diff --git a/doc/call_video.txt b/doc/call_video.txt index 3ae6d6d2..253c2ae0 100644 --- a/doc/call_video.txt +++ b/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 для маскировки этой паузы. В этом диагностическом проходе код не менялся. diff --git a/doc/tasks.md b/doc/tasks.md index 28613441..ebc1aa52 100644 --- a/doc/tasks.md +++ b/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,