|
|
|
|
@ -19,11 +19,14 @@ VBV является локальной настройкой software encoder,
|
|
|
|
|
аудиосэмпла/кадра сохраняется до вывода; время сетевой отправки учитывается отдельно. |
|
|
|
|
Приёмное видео следует исходной позиции реально воспроизводимого аудио, включая |
|
|
|
|
SoundTouch и очередь устройства. Алгоритм регулирования аудиобуфера сохраняется. |
|
|
|
|
Показ имеет собственное абсолютное расписание 1.04x; audio clock ограничивает фазу |
|
|
|
|
в диапазоне videoPTS-audioPTS = -50..+40мс при выдаче кадра на отображение. |
|
|
|
|
Подробности и границы измерения — в разделе «Независимое расписание показа» ниже. |
|
|
|
|
Искусственная тишина/тоны не продвигают исходную позицию. Формат видео меняется по PTS; |
|
|
|
|
новое поколение не уничтожает старые кадры, соответствующие ещё не прозвучавшей речи. |
|
|
|
|
|
|
|
|
|
Передача и регулирование |
|
|
|
|
Один A/V-планировщик, независимые логические каналы управления/аудио/видео. |
|
|
|
|
Одна шкала времени A/V, независимые логические каналы управления/аудио/видео. |
|
|
|
|
Звук продолжает работу при отказе камеры. Ограничены ожидание encode, очереди, |
|
|
|
|
размер сборки кадра и память получателя; ACK не равен успешному decode/render. |
|
|
|
|
Роутер считает исходный payload и пакеты, видеомодуль вычитает фиксированный |
|
|
|
|
@ -498,7 +501,7 @@ VIDEO_DECODE_OK/REJECT передают результат decoder; Auto иск
|
|
|
|
|
отправки после очередного tick регулятора. При смене звонка очищаются pending команды port. |
|
|
|
|
Сетевой долг ограничен полусекундой целевого потока плюс базовый RTT, с минимумом |
|
|
|
|
64 KiB для IDR и абсолютным пределом 2 MiB. Частичная отправка по-прежнему ограничена |
|
|
|
|
2с. Обе платформы отбрасывают показ кадров, отставших от аудио более чем на 500мс. |
|
|
|
|
2с. На этом этапе предел отставания был 500мс; с 15.10.2026 заменён общим playout на 50мс (см. ниже). |
|
|
|
|
|
|
|
|
|
Подтверждено на подключённых устройствах последней debug instrumentation: |
|
|
|
|
- D2AR10P3600820: c2.unisoc.hevc.encoder Main/level 93/DPB=3; AVC Baseline/level 31. |
|
|
|
|
@ -684,3 +687,57 @@ Samsung удерживает кадр/следующие encoded frames до н
|
|
|
|
|
Сборки /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 пересобран и перезапущен. Поведение кодеков, очередей, аудиосинхронизации не изменено. |
|
|
|
|
|
|
|
|
|
Независимое расписание показа, 15.10.2026 |
|
|
|
|
Общий C-модуль call_video_playout принадлежит RX worker, не владеет изображениями/decoder. |
|
|
|
|
Последовательные сроки: D[i] = D[i-1] + (PTS[i]-PTS[i-1])*25/26. |
|
|
|
|
Локальная received_us ставится на входе RX port в CLOCK_MONOTONIC до ожидания worker; |
|
|
|
|
это дополнительное локальное поле, wire format не изменён. Desktop использует тот же источник |
|
|
|
|
времени, Android System.nanoTime соответствует MONOTONIC. BOOTTIME из транспортных логов сюда не подмешивается. |
|
|
|
|
Если received_us > D[i], срок переносится на received_us. Поздний pull, decode или poll не переносят |
|
|
|
|
его на фактическое время показа. Поэтому ожидание данных постепенно съедается ускорением, |
|
|
|
|
а опоздание CPU не добавляется к последующим срокам. На полностью разгруженном входе скорость |
|
|
|
|
естественно ограничена поступлением кадров; дополнительных кадров и фиксированного запаса не создаём. |
|
|
|
|
|
|
|
|
|
Свежий audio clock ограничивает фазу: ранний кадр ждёт, поздний более 50мс не показывается. |
|
|
|
|
Проекция аудиометки на 1x ограничивает плановый срок, но решение SHOW всегда проверяет текущие часы; |
|
|
|
|
проверка не реже 5мс, поэтому изменение темпа аудио не требует отдельного rate estimator. |
|
|
|
|
При WAIT кадр не потребляется, следующая проверка не накапливает сдвиги. При длинной паузе CPU |
|
|
|
|
готовый следующий кадр с уже наступившим сроком вытесняет устаревший показ; codec references не удаляются. |
|
|
|
|
После невалидных аудиочасов снимается привязка расписания, но сохраняются decoder и монотонный порядок PTS. |
|
|
|
|
Изменение source_epoch само по себе не сбрасывает видео. Долг таймера после outage не отрабатывается пачкой. |
|
|
|
|
|
|
|
|
|
Обе платформы держат до двух готовых изображений для lookahead; ждать второго для показа первого не нужно. |
|
|
|
|
Android продолжает подачу input во время ожидания output, суммарно до восьми кадров в decoder/готовой очереди. |
|
|
|
|
Метка received_us переносится через input FIFO по PTS. EOS закрывает decoder лишь после показа/пропуска |
|
|
|
|
всех выходов, включая непустой последний EOS output. Переход формата сохраняет расписание. |
|
|
|
|
На desktop публикация remote image больше не зависит от UI-таймера 20мс: одно coalesced queued notification, |
|
|
|
|
последний выбранный кадр и проверка поколения публикации при stop/restart. Preview/status сохраняют свой таймер. |
|
|
|
|
|
|
|
|
|
Сводка call/debug раз в секунду: shown, drop_late/drop_schedule/drop_order, cadence_us, |
|
|
|
|
av_us, dispatch_max_us, data_shift_us, audio_wait/clock_wait. Для самого большого промежутка |
|
|
|
|
gap_pts_us/gap_rx_us/gap_dispatch_us различают нерегулярность исходных кадров, доступности входа и исполнения. |
|
|
|
|
data_shift_us — сумма сдвигов расписания по доступности входа, не накопленная задержка сети: |
|
|
|
|
даже ровный вход 30fps ограничивает 1.04x примерно на 40мс за секунду. |
|
|
|
|
Задержку uasync/его backpressure эта метка не отличает от задержки доставки; это не физический socket timestamp. |
|
|
|
|
Граница A/V относится к выдаче на отображение. UI/render/scanout измеряются отдельно, строгой аппаратной |
|
|
|
|
гарантии в условиях остановки CPU или отсутствия новых кадров нет. Для большой сетевой паузы одновременно |
|
|
|
|
сохранить все кадры, только плавно догнать и сразу соблюдать 50мс невозможно — действует drop_late. |
|
|
|
|
|
|
|
|
|
Проверки: test_call_video_playout — абсолютные сроки при CPU+9мс, задержка данных+20мс, |
|
|
|
|
пропуск backlog, верхняя граница A/V, outage/recovery, порядок PTS и 400 кадров с jitter/FPS/темпом аудио. |
|
|
|
|
Комбинированный сценарий: 389 показано, 11 пропущено, все SHOW внутри A/V-границ. |
|
|
|
|
Qt test_call_video_clock использует настоящий decoder: ровный вход 90/90; доставка+20мс, |
|
|
|
|
RX CPU+80мс и UI+60мс — 87/90, без key requests/rejections и без публикаций после stop. |
|
|
|
|
Повторный start того же call_id и 32 source_epoch за сценарий не разрывают декодирование. |
|
|
|
|
test_call_video, test_call_video_rate, test_call (2/2), Qt encoder (13/13), Android unit (103) прошли. |
|
|
|
|
Ядро, ChatGUI, APK собраны. Логи /tmp/video-playout-*-test.log и /tmp/video-playout-*-build.log. |
|
|
|
|
|
|
|
|
|
Пробный живой звонок 11342339676311998023: Samsung 3719 показов за 127.374с (~29.2fps), |
|
|
|
|
drop_late/drop_schedule=0, av=-43819..39982мкс. Desktop 5737 показов за 217.560с (~26.4fps), |
|
|
|
|
646 drop_late, 3 drop_schedule, av=-49934..39988мкс. Окна выборок различаются, это не парный glass-to-glass замер. |
|
|
|
|
На Samsung остаются отдельные промежутки 50–70мс; на desktop обратное направление теряет около 10% |
|
|
|
|
кадров по строгой границе отставания. Полностью ровный живой показ пока не подтверждён. |
|
|
|
|
Снимки /tmp/video-playout-live-{desktop,sm}.log. После этого замера добавлен контекст максимального |
|
|
|
|
промежутка и уточнён абсолютный срок сна Android; финальная сборка установлена на Samsung и Q8. |
|
|
|
|
Следующая проверка: по gap_* установить источник остаточных пауз и late drops, не расширяя A/V-границы вслепую. |
|
|
|
|
|
evgeny
5 days ago