|
|
|
|
@ -799,3 +799,35 @@ test_call_video_flush использует настоящий transport, сер
|
|
|
|
|
Артефакты проверки: /tmp/video-flush-*-build.log, /tmp/video-flush-*-test.log, |
|
|
|
|
/tmp/video-flush-regression.log. APK установлен на Samsung и Q8, ChatGUI перезапущен. |
|
|
|
|
Непрерывные журналы пишутся; эффект на живой queue_age/равномерность ещё требует повторного звонка. |
|
|
|
|
|
|
|
|
|
Живая проверка продолжения TX, звонок 12694689407894286842 |
|
|
|
|
Снимки /tmp/video-flush-live-{desktop,sm}.log; /tmp/video-flush-live-summary.json и -stages.json. |
|
|
|
|
На Samsung два выборочных крупных кадра 42429/43309 байт: budget_yields=2, queue_age=600/500мкс. |
|
|
|
|
В предыдущем звонке кадр 46333 байт ждал 39900мкс. Это разные кадры/звонки, но текущие выборки |
|
|
|
|
и счётчики подтверждают работу немедленного продолжения. Desktop крупных кадров в выборочной трассе |
|
|
|
|
не было; секундные счётчики показывают 26 постановок/26 callback за последние 20 окон. |
|
|
|
|
На SM 83 постановки/78 callback: оставшиеся продолжения опережены обычными вызовами flush. |
|
|
|
|
flush_net_wait=0, непустых TX-очередей в этих снимках нет. Максимальное ожидание продолжения: |
|
|
|
|
desktop 201мкс, SM 5877мкс. Ожидание исполнения не считается задержкой сети. |
|
|
|
|
|
|
|
|
|
Последние 20 отчётов playout: SM 599 показов/20.052998с=29.87fps, ноль drops, |
|
|
|
|
videoPTS-audioPTS -1287..39997мкс; промежутки показа 6931..63810мкс. |
|
|
|
|
Desktop 600/20.057555с=29.91fps, 3 late drops, ноль schedule drops, A/V -49290..1469мкс; |
|
|
|
|
промежутки 22672..83153мкс. Полностью ровного cadence ещё нет. |
|
|
|
|
Медиана gap_rx для самого длинного секундного промежутка: SM 51560.5мкс, desktop 56718.5мкс; |
|
|
|
|
соответствующая медиана gap_pts 32046/33308мкс. Максимальный dispatch SM 24404мкс, desktop 9044мкс. |
|
|
|
|
|
|
|
|
|
Парные выборки только этого call_id дают phone_boot-host_boot [-796330272225,-796330268949]мкс |
|
|
|
|
(+/-1638мкс). Send->complete receive: медиана desktop->SM 3469мкс (47), SM->desktop 3948мкс (46). |
|
|
|
|
В последних 20сек выборочного SM timing: receive->decode 11661мкс, queue->decode 7424.5мкс, |
|
|
|
|
decode->release 4199.5мкс; release->commit 23007мкс (15 совпавших выборок). |
|
|
|
|
Медианы не складываются в точный end-to-end; commit по-прежнему не является физическим scanout. |
|
|
|
|
|
|
|
|
|
Есть краткие переходы audio clock valid=0->1. В последних 20сек именно clock-трассы 37 пар, |
|
|
|
|
медиана длительности 2173мкс, максимум 6540мкс. Это не количество потерянных кадров: |
|
|
|
|
poll работает и без готового изображения. При invalid общий playout сбрасывает anchored. |
|
|
|
|
CallTimeline::clock имеет несколько причин отказа (в том числе nowUs<anchorReceived), но логирует |
|
|
|
|
только итоговый valid. nowUs передаётся в call_audio_get_clock до захвата mutex; это потенциальная |
|
|
|
|
гонка времени снимка с progress, ещё не доказанная причина текущих переходов. |
|
|
|
|
Следующий шаг: агрегировать причины invalid и длительность получения снимка/возраст anchor, |
|
|
|
|
с контекстом максимального gap; не ослаблять valid и не менять часы без подтверждающих измерений. |
|
|
|
|
|