Record measured desktop Android video latency and presentation timing limits

doc/call_video.txt

@@ -636,3 +636,51 @@ Unisoc AVC: 3.993M -> 29.3k -> 3.994M бит/с. В каждой пробе по
 Итоговый APK установлен на оба телефона. check.sh: 154/154, proxy 9/9, burst/load PASS (119с),
 /tmp/call-video-core-final-check-unsandboxed.log. Первый запуск в sandbox не мог открыть сокеты;
 успешный полный прогон выполнен с разрешённым сетевым доступом.
+
+15.10.2026, повторная диагностика задержки desktop -> Samsung после внедрения AAudio
+Звонок 14610053360084326214 (Kotlin Long: -3836690713625225402), Samsung на громкой связи,
+AAudio output ~23мс, очередь устройства 20мс, стабильный JB reserve=20мс. Оба направления около 30fps.
+Выборка всех этапов по pts % 1000000 < 34000: примерно один кадр/сек, категории debug=debug.
+Desktop: encode (включая select/convert), send, receive, decode, select, publish.
+Android: receive, pull (MONOTONIC+BOOTTIME), queue, decode, release, surface, texture_update, commit.
+Поля pts принадлежат отправителю; mono_us — локальному CLOCK_MONOTONIC, boot_us — CLOCK_BOOTTIME.
+Сравнение разных устройств напрямую запрещено. Для анализа использовано ограничение send <= receive
+в обоих направлениях, по совпадающим PTS: phone_boot-host_boot в [-796330256933, -796330252177]мкс.
+Погрешность межмашинных оценок в этой выборке +/-2.378мс; локальные интервалы этой ошибки не имеют.
+
+Первый замер ошибочно считал texture_update временем готовности текущего кадра: по исходникам Android
+TextureView.applyUpdate() передаёт работу RenderThread, а callback вызывается до фактического dequeue.
+Чтение SurfaceTexture.timestamp здесь часто показывает предыдущий кадр и добавляет ложные ~33мс.
+MediaCodec.OnFrameRenderedListener на этом backend возвращает исходный PTS в nanoTime, что также
+не является измерением локального времени показа. В логе поле переименовано в reported_us.
+Контроль commit читает timestamp после registerFrameCommitCallback (API29+): кадр уже обработан
+RenderThread и передан в swapchain. Callback может опоздать; физический scanout не измерен.
+Эти данные не обосновывают компенсацию постоянными 40мс или замену TextureView.
+
+51 полная выборка desktop -> Samsung: медиана encode 25.72мс, от mapped capture PTS до выхода
+encoder 46.19мс, сеть 4.09мс, ожидание в RX-порту 32.05мс, decode 6.47мс,
+ожидание audio clock после decode 24.19мс, release -> commit 19.50мс.
+Медиана mapped PTS -> release 115.88мс, -> commit 137.90мс.
+В последних 20 выборках без большого сетевого выброса: PTS -> release 100.4мс,
+PTS -> commit 133.8мс; сеть 4.4мс, decode 5.7мс. Медианы отдельных этапов не складываются
+в точную медиану полного пути. В общей записи были сетевые выбросы и увеличение ожидания JB;
+на стабильном участке резерв вернулся к 20мс, аппаратных underrun нет.
+
+Обратный путь, последние 20 выборок: sensor PTS -> send 124.7мс (камера и encoder вместе),
+сеть 5.2мс, software decode 2.1мс, ожидание audio clock <0.1мс, select -> Qt publish 12.0мс.
+От sensor PTS до publish 147.5мс; publish ещё не означает физический показ на мониторе.
+Desktop capture PTS привязан к arrival-upper-bound Qt, Android PTS — к аппаратному sensor timestamp:
+сравнивать эти числа как точное glass-to-glass измерение разных камер нельзя.
+Тем не менее асимметрия после получения кадра ясна: быстрый desktop encoder обгоняет аудиопозицию,
+Samsung удерживает кадр/следующие encoded frames до неё. Видео телефона приходит к desktop уже позже
+соответствующей аудиопозиции и показывается практически сразу. Локальный desktop preview аудио не ждёт.
+Ускорение только encoder освободит CPU, но при раннем приходе увеличит ожидание аудио на столько же.
+Для дальнейшего снижения общей A/V-задержки нужно оптимизировать аудиотракт и отдельно проверять
+планирование презентации с учётом измеренного render latency; JB20/адаптация и привязка к звуку сохранены.
+
+Снимки: /tmp/video-timing-committed-desktop.log, /tmp/video-timing-committed-sm.log;
+расчёт: /tmp/video-timing-committed-analysis.json. Исходники Android для проверки порядка callbacks:
+/tmp/video-TextureView.java, /tmp/video-DeferredLayerUpdater.cpp, /tmp/video-ImageConsumer.cpp.
+Сборки /tmp/video-timing-*-build.log и /tmp/video-commit-*-build.log; 103 Android unit PASS,
+test_call_video_clock exit=0, test_call_video_encoder 13/13 PASS. Диагностика установлена на Samsung,
+ChatGUI пересобран и перезапущен. Поведение кодеков, очередей, аудиосинхронизации не изменено.

doc/tasks.md

@@ -4,6 +4,19 @@
 
 ## Текущие задачи
 
+[+] **Измерить задержку видео desktop -> Samsung по этапам** — 15.10.2026:
+    Добавлена выборочная трассировка по одному окну исходного PTS в секунду: encode/send/receive,
+    pull/queue/decode/release, Android frame commit и desktop select/publish. Протокол и A/V-планировщик не менялись.
+    Проверка показала две ловушки диагностики: MediaCodec callback на Samsung возвращает source PTS в поле времени,
+    а TextureView.onSurfaceTextureUpdated может читать timestamp предыдущего кадра до работы RenderThread.
+    Для Android используется registerFrameCommitCallback; это завершение UI-рендера, ещё не физическое появление пикселей.
+    Звонок 14610053360084326214; полные замеры в doc/call_video.txt, раздел диагностики 15.10.2026.
+    На стабильном участке сеть ~4–5мс, decoder SM ~6мс. RX ждёт audio clock; в обратном направлении
+    камера/кодер телефона уже задерживают кадр ~125мс, поэтому desktop почти не ждёт аудио перед показом.
+    Уменьшение только времени encoder не убирает ожидание audio clock; произвольного сдвига видео не добавлено.
+    Ядро, desktop и APK собраны, 103 Android unit-теста, test_call_video_clock и 13 Qt encoder-проверок прошли.
+    Диагностический APK установлен на Samsung, ChatGUI перезапущен; непрерывные логи и снимки сохранены в /tmp/video-timing-*.
+
 [ ] **Снижение минимального запаса JB звонка до 20мс** — 15.10.2026:
     Нижняя граница общего call_jitter изменена с 60 до 20мс; адаптация по 10-секундному окну сохранена.
     Добавлен общий модуль src/call/call_delay.h/.cpp: direct PCM с удалением одиночных сэмплов (<=2%)