From 2ff14519fadea9147d895d14bb2bfab3e12c15c6 Mon Sep 17 00:00:00 2001 From: evgeny Date: Thu, 15 Oct 2026 15:25:07 +0200 Subject: [PATCH] Record measured desktop Android video latency and presentation timing limits --- doc/call_video.txt | 48 ++++++++++++++++++++++++++++++++++++++++++++++ doc/tasks.md | 13 +++++++++++++ 2 files changed, 61 insertions(+) diff --git a/doc/call_video.txt b/doc/call_video.txt index 08e105ff..384194bf 100644 --- a/doc/call_video.txt +++ b/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 пересобран и перезапущен. Поведение кодеков, очередей, аудиосинхронизации не изменено. diff --git a/doc/tasks.md b/doc/tasks.md index f52c39ed..fcbc092b 100644 --- a/doc/tasks.md +++ b/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%)