923 lines
104 KiB
Plaintext
923 lines
104 KiB
Plaintext
Видеозвонки Android и ChatGUI
|
||
|
||
Контракт
|
||
Каждая сторона независимо включает видео. Автовыбор H.265 Main 8-bit, затем
|
||
H.264 Baseline/Constrained Baseline: пересечение encoder отправителя и decoder получателя.
|
||
Encode/decode проверяются независимо, профили AVC согласуются явной маской.
|
||
HEVC Main/Main tier, 8-bit 4:2:0, progressive, без reorder; DPB ограничен Annex A,
|
||
не фиксированным числом references. Общий call_video_bitstream проверяет VPS/SPS/PPS,
|
||
HRD при наличии, геометрию и независимый IDR. Фактический level проверяется после
|
||
открытия encoder. CAPS — 64 байта, header — 56 байт; старый формат не поддерживается.
|
||
VBV является локальной настройкой software encoder, в сетевом контракте его нет.
|
||
Результат запуска decoder (generation + accepted) передаётся отдельно от router ACK:
|
||
неподдержанный формат вызывает fallback в Auto, потеря references — запрос KEY.
|
||
Камера, разрешение, кодек и диапазон битрейта меняются во время звонка.
|
||
Автоматический диапазон по умолчанию 300–4000 кбит/с (десятичные единицы).
|
||
|
||
Время
|
||
Общая монотонная шкала захвата аудио и видео на каждом отправителе. PTS первого
|
||
аудиосэмпла/кадра сохраняется до вывода; время сетевой отправки учитывается отдельно.
|
||
Приёмное видео следует исходной позиции реально воспроизводимого аудио, включая
|
||
SoundTouch и очередь устройства. Алгоритм регулирования аудиобуфера сохраняется.
|
||
Показ имеет собственное абсолютное расписание 1.04x; audio clock ограничивает фазу
|
||
в диапазоне videoPTS-audioPTS = -50..+40мс при выдаче кадра на отображение.
|
||
Подробности и границы измерения — в разделе «Независимое расписание показа» ниже.
|
||
Искусственная тишина/тоны не продвигают исходную позицию. Формат видео меняется по PTS;
|
||
новое поколение не уничтожает старые кадры, соответствующие ещё не прозвучавшей речи.
|
||
|
||
Передача и регулирование
|
||
Одна шкала времени A/V, независимые логические каналы управления/аудио/видео.
|
||
Звук продолжает работу при отказе камеры. Ограничены ожидание encode, очереди,
|
||
размер сборки кадра и память получателя; ACK не равен успешному decode/render.
|
||
Роутер считает исходный payload и пакеты, видеомодуль вычитает фиксированный
|
||
заголовок фрагмента. Физические очереди повторно не суммируются с router inflight.
|
||
Окно ACK: 10 завершённых интервалов по 50мс, текущая ячейка отдельно.
|
||
Регулятор общий C, решения проверяются управляемым временем. Снижение учитывает
|
||
подтверждённую скорость и разгрузку задолженности; повышение — малыми пробами.
|
||
Нет отдельного неограниченного интегратора: задолженность уже интегрирует дефицит.
|
||
Учитываются прогрев, RTT, minrtt_probe, отсутствие маршрута, локальное удержание
|
||
планировщиком, применение encoder-команды и смена эпохи.
|
||
|
||
Владение
|
||
Состояние звонка/регулятора/роутера — uasync. Камера и encoder/decoder — платформенные
|
||
workers. Ограниченный mailbox, одно ожидающее уведомление. Команды bitrate имеют
|
||
call_id, video_generation и request_id; одно исполнение и последнее желаемое значение.
|
||
Принятая настройка не заменяет измерение фактического выхода. Shutdown отменяет
|
||
уведомления/таймеры, останавливает producers, затем освобождает очереди и codecs.
|
||
|
||
Применение bitrate на ключевом кадре (уточнение пользователя)
|
||
Worker хранит pending-команду и применяет её перед кодированием ближайшего
|
||
планового IDR. GOP ограничен одной секундой исходной шкалы capture PTS, а не
|
||
числом принятых сетью кадров: backpressure не должен блокировать переключение.
|
||
Для x265 используется новый encoder с нужным bitrate; обычный reconfigure даже
|
||
на IDR не обходит найденный дефект 4.1. Исправленная внешняя библиотека не нужна.
|
||
Первый выход нового encoder обязан содержать IDR и актуальные VPS/SPS/PPS.
|
||
Камера, audio epoch, capture PTS и последовательность frame_id не перезапускаются.
|
||
При неизменном формате bitrate не меняет video_generation; новые parameter sets
|
||
идут с KEY. Смена codec/разрешения/камеры сохраняет отдельный протокол generation.
|
||
Приём применяет конфигурацию перед декодированием соответствующего KEY, не удаляя
|
||
уже декодированные старые кадры, ожидающие своего времени по audio clock.
|
||
Подтверждение rate_applied отправляется после проверки первого нового IDR,
|
||
независимо от сетевого admission; иначе закрытый admission создаст взаимное ожидание.
|
||
Успех означает применение настройки, не гарантию бит-в-бит постоянного выхода.
|
||
До IDR регулятор видит старый applied bitrate и одну pending-команду; его текущий
|
||
таймаут 12с включает ожидание IDR, проверку hardware encoder (до 5с) и возможное
|
||
восстановление предыдущей конфигурации (до 5с). При отсутствии кадров/ошибке
|
||
команда завершается отказом; нельзя бесконечно продлевать её таймаут.
|
||
Ограничитель очереди работает и во время ожидания. Если новый IDR не принят,
|
||
producer запрашивает следующий IDR по существующему контракту send_frame.
|
||
Desktop готовит кандидата в отдельном потоке, продолжая кодирование старым encoder.
|
||
Готовый кандидат применяется только на IDR; при незавершённой подготовке текущий
|
||
GOP продолжается. Android сначала меняет bitrate через MediaCodec.setParameters
|
||
без остановки; подтверждает только проверенный KEY с PTS не раньше команды.
|
||
Уже закодированные P-кадры перед этим KEY сохраняются: runtime bitrate не разрушает references.
|
||
При отказе runtime API Android переоткрывает encoder последовательно (аппаратный
|
||
ресурс может быть единственным), при ошибке восстанавливает прежнюю конфигурацию
|
||
и подтверждает фактически восстановленный bitrate. В этой резервной ветке возможна
|
||
пауза картинки; аудио и capture timeline продолжаются.
|
||
|
||
Порядок реализации
|
||
[+] История первых ACK 500мс/50мс и снимок payload send_q/inflight отдельного сервиса.
|
||
[+] Unit счётчиков: повторные ACK, reset, отдельные сервисы; UDP/STCP регрессии пройдены.
|
||
[+] Дрейф feed/tempo устранён картой фактических участков SoundTouch; см. ниже.
|
||
[+] ChatGUI codec component: замена H.264/H.265 encoder на IDR, с непрерывными PTS.
|
||
[+] Android MediaCodec: применение bitrate на ближайшем IDR, проверка фактического формата.
|
||
[+] Общий регулятор с детерминированными сценариями и подключением к router/encoder-командам.
|
||
[+] Видеофрагменты, ограниченная сборка, обмен возможностями с подтверждением.
|
||
[+] Согласование profiles/level и целевого bitrate; проверка transport/encoder, независимый decoder probe.
|
||
[+] A/V scheduler с платформенными очередями захвата/encode.
|
||
[+] Общие capture PTS и отображение позиции аудиоустройства в исходное время.
|
||
[+] ChatGUI: движок, окно и настройки; Android: движок, JNI, сервис и экран.
|
||
[ ] Интеграционные проверки всех пар, перегрузки, смены формата и lifecycle.
|
||
|
||
Приёмка
|
||
Нет двойного учёта байтов: принято = подтверждено + отменено + задолженность.
|
||
Повторные ACK/передачи не увеличивают delivered. Reset не считается доставкой.
|
||
Свободный канал не вызывает снижение на статичной сцене; рост полосы обнаруживается
|
||
пробами. Очереди остаются ограниченными при отсутствии ACK и остановке decoder.
|
||
Видео следует аудио при догоне, underrun, смене устройства и формате видеотрека.
|
||
Завершение звонка безопасно во время переключения камеры, bitrate и decoder.
|
||
|
||
Далее журнал этапов разработки. Старые описания wire/profile/VBV ниже исторические;
|
||
актуальный контракт приведён в начале, последние проверки — в конце документа.
|
||
|
||
Проверка SoundTouch, 14.10.2026
|
||
test_soundtouch_clock сравнивает положение реальных четырёхсэмпловых фрагментов
|
||
в выходном сигнале с двумя вариантами временной шкалы. 60с входа, mono 48kHz,
|
||
sequence=20ms, seek=10ms, overlap=4ms — параметры существующего call_jitter.
|
||
Максимальная ошибка feed/tempo / consumed-input, мс:
|
||
постоянный темп 1.6: 14.208 / 14.271
|
||
плавный цикл 1.0..1.6 (шаг 0.012/20ms): 29.550 / 13.723
|
||
стресс, переключение 1.0/1.6 каждые 20ms: 938.104 / 14.462
|
||
Стресс не воспроизводит ограничение темпа звонка, а проверяет отсутствие накопления.
|
||
Проблема: setTempo меняет обработку ещё не потреблённого входа; номинальные интервалы
|
||
frames/tempo, записанные при feed, не описывают фактический выход. Поэтому копировать
|
||
этот способ из stream_playback_audio в звонки нельзя. Изменений звука/буфера нет.
|
||
|
||
Рассмотренные варианты (реализован вариант 2):
|
||
1. Минимальный: шкала по фактически потреблённому входу и произведённому выходу,
|
||
с поправкой на seek-window. Тест показал <15мс на трёх сценариях, но это ещё не
|
||
доказанная граница для речи/Opus/разных блоков. Нужны эти проверки и явный допуск.
|
||
2. Более строгий: SoundTouch публикует соответствие исходных участков выходным
|
||
непосредственно в TDStretch. Позволяет учитывать выбранный WSOLA offset без
|
||
вычисления по косвенным счётчикам; потребует небольшого расширения bundled API.
|
||
Overlap смешивает два участка, поэтому даже здесь нужно определить правило PTS.
|
||
Рекомендуется для общего A/V clock: не меняет звук, исключает накопительный дрейф.
|
||
Реализованная шкала
|
||
SoundTouch сообщает Copy/Mix с фактическими индексами входа/выхода после WSOLA.
|
||
Mix интерполирует PTS двумя теми же линейными весами, которыми смешивается PCM.
|
||
Это определение времени смешанного сигнала, а не утверждение, что у смеси один источник.
|
||
Поддержан профиль звонка: float PCM, mono/stereo, rate=pitch=1, AA выключен.
|
||
Неподдержанная смена профиля/flush отключает карту до reset, сохраняя обработку звука.
|
||
CallTimeline переносит участки через частичные receiveSamples и локальные тоны/тишину.
|
||
Кольца ограничены; переполнение или противоречивый progress запрещают valid до reset.
|
||
Краткое движение исходного PTS назад удерживается, held_back_us видно в диагностике.
|
||
Разрыв более 100мс и смешивание разных source_epoch не дают valid-PTS.
|
||
|
||
Аудиопакет несёт capture_pts_us, capture_epoch и codec_delay_samples (Opus lookahead).
|
||
Метка неизвестного источника — INT64_MIN. Старого формата протокола больше нет.
|
||
После разрыва захвата хвост прежнего Opus не получает вымышленную новую метку.
|
||
Desktop передаёт исходную метку callback захвата; playback использует позицию PCM
|
||
и время вывода backend. measured показывает аппаратную отметку либо оценку backend.
|
||
Android использует AudioRecord timestamp MONOTONIC; до появления timestamp оценка
|
||
привязана один раз к окончанию первого read и далее идёт по сэмплам. После исчезновения
|
||
timestamp продолжается последний якорь. Это ограничение точности, а не аппаратное измерение.
|
||
AudioTrack playbackHeadPosition разворачивается из unsigned32 и ограничивается реально
|
||
записанным PCM. Опрос head — estimated (measured=0), write не подтверждает воспроизведение.
|
||
Локальные часы API — MONOTONIC, не get_time_us ядра (на Linux он использует BOOTTIME).
|
||
Снимок без progress более 250мс недостоверен; экстраполяции за подтверждённый участок нет.
|
||
Логи call DEBUG показывают epoch/source/played/written/PTS/valid/measured/held раз в секунду.
|
||
Видеотранспорт подключён к ядру; codecs, полный scheduler и UI ещё не подключены. Проверка A/V на устройствах
|
||
остаётся следующим интеграционным этапом; unit-тесты не измеряют физическую задержку динамика.
|
||
|
||
Проверки текущего этапа
|
||
./build.sh --no-gui -j4 — успешно.
|
||
./check.sh — 153/153, proxy 9/9, burst и load успешно; /tmp/call-video-check.log.
|
||
test_etcp_router_unit — 36/36; /tmp/call-video-router-unit.log.
|
||
UDP и STCP — по 440 пакетов, 5 циклов backpressure, без потерь/дублей/повреждений;
|
||
/tmp/call-video-router-udp.log, /tmp/call-video-router-tcp.log.
|
||
Регулятор: модель 120с с полосой 1.5→3Mbps, max debt=118559 bytes;
|
||
статичная сцена — 0 ложных снижений. Pending, cap, no route, warmup, локальное
|
||
удержание, minrtt probe, RTT=600ms проверены. Интеграция encoder ещё отсутствует.
|
||
test_soundtouch_clock — три сценария проходят предел consumed-input <20ms;
|
||
этот предел теста не является гарантией для всех входных сигналов.
|
||
|
||
Проверки реализованного варианта 2
|
||
Сравнение SoundTouch с callback и без него: PCM побитно одинаков; Copy/Mix
|
||
восстанавливаются по фактическому входу, включая mono/stereo, partial read и clear.
|
||
CallTimeline: 200с реального SoundTouch, смена темпа, границы участков, переполнение,
|
||
неверная/устаревшая позиция устройства и восстановление через reset.
|
||
CallAudio: 40с реального Opus+jitter, burst/догон, тоны/тишина, эпоха устройства;
|
||
capture metadata проверены через очередь uasync и реальный сетевой звонок.
|
||
Desktop: шесть профильных + пять проверок общего аудиостека прошли, vibechat собран.
|
||
Android: assembleDebug и все 79 unit-тестов прошли (arm64-v8a и x86_64 native).
|
||
./check.sh: 153/153, proxy 9/9, burst/load PASS; /tmp/call-clock-check-final.log.
|
||
Логи: /tmp/call-clock-desktop-final-tests.log, /tmp/call-clock-shared-tests.log
|
||
(test_radio_member_mute повторён вне sandbox: /tmp/call-clock-radio-mute-test.log),
|
||
/tmp/call-clock-android-final.log. Физические устройства в этом этапе не проверялись.
|
||
|
||
Реализованный видеотранспорт, 14.10.2026
|
||
call_video.c задаёт общий wire и сборку; call_video_transport.c владеет состоянием
|
||
видеоканала внутри call_session. Сигнализация звонка, video control, audio и video
|
||
имеют отдельные router service IDs. Приёмная очередь видео не блокирует аудио.
|
||
CAPS повторяется до прикладного CAPS_ACK: получение транспортного ACK не гарантирует,
|
||
что получатель уже обработал ACCEPT и установил capabilities. Кодек выбирается
|
||
направленно: encoder отправителя пересекается с decoder получателя, H.265 перед H.264.
|
||
Текущие limits проверяют размеры, FPS и pixels/second; контракт профиля ещё неполон.
|
||
|
||
Заголовок фрагмента 52 байта, payload до 1200 байт; полный кадр до 2MiB.
|
||
KEY содержит config_length:4BE + AnnexB config + access unit. Ядро проверяет
|
||
границы envelope; содержимое NAL обязан проверять платформенный decoder.
|
||
frame_id и capture PTS возрастают на всём протяжении звонка, включая смену generation.
|
||
Новый формат требует нового generation и KEY. После пропуска кадра нужен KEY.
|
||
На TX ограниченная FIFO: до 32 кадров, 500мс по PTS и 2MiB суммарно; на RX одна ограниченная сборка.
|
||
Deadline головы TX и сборки RX — 2с. Каждый TX кадр ждёт соответствующего audio_end_pts;
|
||
следующие P-кадры сохраняются в FIFO, а не теряются на обычной задержке аудиообработки.
|
||
При потере головы отбрасывается вся зависимая цепочка и запрашивается KEY. В сетевой долг
|
||
входят только готовые к отправке кадры FIFO; ожидание аудио само по себе не перегружает канал.
|
||
receive_ready резервирует возможность принять целый кадр до ACK первого фрагмента.
|
||
Callback копирует данные до возврата; платформенная очередь также должна быть ограничена.
|
||
Старые кадры другого generation сохраняются до соответствующей позиции аудиоряда.
|
||
|
||
Видео пока удерживается до передачи соответствующего аудио в router. Аудио никогда
|
||
не ждёт камеру. Это первая часть scheduler: ограничение ожидания encode, pacing
|
||
на максимальном битрейте и политика остановки видеотрека остаются следующими задачами.
|
||
flush ограничен 16 фрагментами за вызов; пропускную способность этого бюджета нужно
|
||
проверить вместе с частотой вызовов от платформенного producer и аудио.
|
||
|
||
Регулятор получает endpoint ACK 500мс/50мс и queued+inflight отдельного видеосервиса.
|
||
Фиксированные заголовки вычитаются; добавляется ещё не переданный остаток кадра.
|
||
Удержание по аудио не трактуется как нехватка сети. Смена эпохи сбрасывает окно.
|
||
Ограничение admission: задолженность + новый кадр не превышают 2MiB.
|
||
Одна команда bitrate в работе, подтверждение проверяет generation/request;
|
||
устаревшее подтверждение отвергается. Timeout 2с или отказ encoder останавливает
|
||
admission до явной повторной настройки; аудиозвонок продолжает работу.
|
||
Платформенные callbacks вызываются в uasync и не меняют call API реентерабельно.
|
||
При hangup отменяются таймеры и освобождаются pending TX/RX, callbacks снимаются.
|
||
|
||
Проверки видеотранспорта
|
||
./check.sh: 154/154, proxy 9/9, burst/load PASS; /tmp/call-video-core-check.log.
|
||
test_call_video проверяет capabilities, wire, фрагментацию, replay, разрыв,
|
||
timeout, смену generation и некорректные размеры/config.
|
||
test_call через два реальных UDP-ядра проверяет обмен CAPS, удержание видео по аудио,
|
||
backpressure получателя без остановки аудио, H.265 -> H.264 с новым generation,
|
||
bitrate command/ACK, устаревшие ACK и hangup с ожидающим кадром.
|
||
Payload в этом тесте синтетический: тест не доказывает работу HEVC/AVC decoder.
|
||
Лог: /tmp/call-video-rate-integration.log.
|
||
ChatGUI vibechat собран; test_voice_tx и test_call_jitter прошли.
|
||
Android assembleDebug/testDebugUnitTest успешны; /tmp/call-video-android-core-build.log.
|
||
Камера, декодирование/показ и физическая A/V-синхронизация пока не проверены.
|
||
|
||
Выявленная нестыковка перед подключением codecs
|
||
Размеров/FPS/pixels-per-second недостаточно: допустимый битрейт зависит также от
|
||
profile/level/tier и ограничений конкретного decoder. Текущий StreamVideoEncoder
|
||
не умеет runtime bitrate для H.265, а прямой x265 требует дополнительной проверки.
|
||
В upstream x265_encoder_reconfig при смене profile/level/tier отменяет изменение
|
||
rate-control, но эта ветка не меняет ret=0. Успешный return не доказывает применение.
|
||
Источник: https://github.com/videolan/x265/blob/master/source/encoder/api.cpp
|
||
|
||
Предлагаемое продолжение:
|
||
1. Зафиксировать Main 8-bit / Constrained Baseline и согласовать level/tier,
|
||
верхний bitrate/VBV и ограничения reference frames для каждого направления.
|
||
Выбранный режим должен проверяться фактическим открытием encoder/decoder.
|
||
2. Открывать encoder в согласованных пределах. Автоадаптация работает внутри них
|
||
без пересоздания. ACK команды означает проверенное фактическое применение,
|
||
а не только возврат setter; отдельно измеряется реальный выход encoder.
|
||
3. Пользовательское изменение за пределами режима создаёт новый generation,
|
||
config и KEY после проверки возможностей получателя; звук продолжается.
|
||
4. Проверить установленный x265 и Android MediaCodec тестом encode/decode с
|
||
понижением/повышением битрейта и отказом настройки. Непригодный H.265 backend
|
||
не объявляется доступным; в auto используется H.264.
|
||
Подключение платформенных codecs остановлено на этой границе согласно AGENTS.md.
|
||
|
||
Настройка диапазона, 14.10.2026
|
||
ChatGUI: Настройки -> аудио, поля минимального/максимального битрейта видеозвонка.
|
||
Android: Настройки -> аудио, ползунок диапазона. По умолчанию 300–4000 кбит/с;
|
||
пользователь может сузить диапазон внутри этих границ, включая фиксированный bitrate.
|
||
Одна атомарная настройка call_video_bitrate_range_kbps=300:4000 хранится в конфиге
|
||
desktop / DataStore Android и передаётся в общий chat_setting. min > max отвергается
|
||
без частичного изменения. Android включает настройку в конфиг при каждом запуске.
|
||
Во время звонка transport читает диапазон каждые 50мс, не сбрасывая pending-команду.
|
||
Верхняя граница ограничена проверенным codec cap текущего generation. Если новый
|
||
минимум выше codec cap, admission приостановлен до совместимой настройки/режима;
|
||
это событие логируется. Смена диапазона сама по себе не расширяет возможности codec.
|
||
При сети слабее 300 кбит/с target не уходит ниже нижней границы; bounded admission
|
||
не позволяет очереди бесконечно расти. Аудиоканал продолжает работать отдельно.
|
||
Порог 5% при снижении не мешает достигнуть точной нижней границы диапазона.
|
||
|
||
Проверено: модель полосы 150 кбит/с -> 6 Мбит/с достигает target 300 кбит/с,
|
||
затем 4 Мбит/с, очередь остаётся ограниченной. Сетевой test_call меняет диапазон
|
||
при pending-команде, принимает прежний ACK и затем получает target нового диапазона;
|
||
также проверяет отказ несовместимого codec cap. Логи /tmp/call-range-rate-test.log
|
||
и /tmp/call-range-integration-test.log. ChatGUI собран; Android assembleDebug и
|
||
81 unit-тест прошли, /tmp/call-range-android-ui-final.log.
|
||
Полный ./check.sh вне sandbox: 154/154, proxy 9/9, burst/load PASS;
|
||
/tmp/call-range-check-final.log. Первый запуск в sandbox блокировался запретом сокетов.
|
||
Настройки и регулятор готовы; подключение камеры/codec/render остаётся отдельным этапом.
|
||
|
||
Проверка реального x265 перед подключением backend, 14.10.2026
|
||
Добавлена ручная цель probe_call_x265 (EXCLUDE_FROM_ALL, не входит в ctest), если
|
||
найден x265 через pkg-config. Сборка/запуск:
|
||
cmake --build tools/chatgui/build --target probe_call_x265 -j4
|
||
./tools/chatgui/build/probe_call_x265
|
||
./tools/chatgui/build/probe_call_x265 --frame-rc
|
||
Один encoder, 640x360@30, Main 8-bit/Main tier/level 3.1, reference=1,
|
||
B=0/lookahead=0, ABR+VBV, буфер 1000 кбит. Три участка по 120 кадров:
|
||
4 Мбит/с -> 300 кбит/с -> 4 Мбит/с. Детерминированная шумовая сцена требует полосы;
|
||
измерение каждого участка исключает первые 30 кадров переходного процесса.
|
||
Код 0 — измерение прошло; 1 — ошибка API/потеря PTS; 2 — непригодный rate control.
|
||
Допуск измерения 0.5..1.5 target — диагностический, не гарантия CBR для любой сцены.
|
||
|
||
Установленная библиотека 4.1+1-1d117be (пакет 4.1-4) не проходит пробу:
|
||
target 4000000: output 4016866 бит/с;
|
||
target 300000: output 4006669 бит/с, несмотря на getter bitrate=300/vbv=300 кбит/с;
|
||
target 4000000: output 3945016 бит/с.
|
||
Лог: /tmp/call-x265-system.log. Return reconfigure=0 и getter недостаточны.
|
||
frame-rc также непригоден для этого zerolatency-профиля: output около 40 кбит/с
|
||
на всех трёх участках; /tmp/call-x265-frame-rc.log.
|
||
|
||
Причина проверена по исходникам именно установленного выпуска:
|
||
https://deb.debian.org/debian/pool/main/x/x265/x265_4.1.orig.tar.xz
|
||
SHA256 85abb8a850000bf693947459c42a666a3ecd6de10a2ac6b3c6647554b14d3270
|
||
Encoder::configure(p) теперь присваивает this->m_param=p. Вызов из
|
||
x265_encoder_reconfig с m_latestParam переключает encoder на новый объект, но
|
||
RateControl::m_param остаётся прежним адресом. Последующий x265_copy_params
|
||
копирует latest в него самого; reconfigureRC читает старые параметры rate control.
|
||
Для frame-rc обнаружен отдельный дефект: tuneQscaleToUpdatedBitrate делит
|
||
frameBitsTotal на i=0 при пустом lookahead, что в этой пробе приводит к QP=69.
|
||
|
||
Проверенный минимальный патч сохраняет активный m_param до configure(latest)
|
||
и восстанавливает его после. Файл для дальнейшего подключения:
|
||
tools/chatgui/ffmpeg/patches/x265-4.1-reconfigure-param-owner.patch
|
||
Применён только к отдельной копии исходников в /tmp/call-x265-source;
|
||
библиотека собрана в /tmp/call-x265-build без установки в систему.
|
||
С тем же тестом и frame-rc=off output=4016866 / 298165 / 4213269 бит/с.
|
||
Логи: /tmp/call_x265_probe_fixed.log и /tmp/call-x265-fixed.log.
|
||
Дополнительная проверка ffprobe: 360/360 кадров декодируются, Main, level=93
|
||
(HEVC level 3.1), has_b_frames=0. Системная библиотека и приложение не заменены.
|
||
ChatGUI успешно собирается; /tmp/call-x265-desktop-build.log.
|
||
|
||
Первоначальное предложение (заменено решением переключать encoder на IDR ниже):
|
||
закрепить проверенную версию x265 и патч в локальной
|
||
сборке зависимости, повторить codec-пробу для рабочих разрешений и decoder,
|
||
затем подключить direct API к backend звонка. Непрошедший проверку backend
|
||
не объявлять в capabilities; H.264 остаётся альтернативой, когда H.265 недоступен.
|
||
Патч пока не подключён к build_ffmpeg.sh; изменение поставки зависимости и
|
||
интеграция backend остановлены по правилу AGENTS.md о выявленной нестыковке.
|
||
|
||
Проверка переключения на плановом IDR, 14.10.2026
|
||
По уточнению пользователя вместо поставки изменённой x265 проверено пересоздание
|
||
encoder на очередном IDR. Добавлены режимы probe_call_x265:
|
||
--keyframe-reconfig
|
||
--keyframe-reopen --output /tmp/call-x265-key-reopen.hevc
|
||
Запрос приходит на кадре 7 очередного участка; применение перед кадром 30,
|
||
через 23 кадра (767мс при 30fps). Плановый IDR задаётся каждые 30 кадров,
|
||
проверяются его NAL-тип и наличие VPS/SPS/PPS. PTS всех 360 кадров проверяются
|
||
на точное соответствие исходным, включая обе границы замены encoder.
|
||
Измеряются последние 60 кадров каждого 120-кадрового участка, после перехода.
|
||
На системной x265 4.1 без патча:
|
||
reconfigure перед IDR: 4008828 / 4001940 / 3977828 бит/с — отказ, код 2;
|
||
новый encoder на IDR: 4008828 / 309564 / 4019812 бит/с — PASS, код 0.
|
||
Логи: /tmp/call-x265-key-reconfig.log, /tmp/call-x265-key-reopen.log.
|
||
ffmpeg -v error -xerror декодирует объединённый поток без ошибок;
|
||
ffprobe подтверждает Main/level 3.1, B=0 и 360 кадров.
|
||
Это проверка 640x360@30 на синтетической сложной сцене, не готовый тракт звонка:
|
||
worker/camera/decoder UI и Android MediaCodec ещё предстоит подключить и проверить.
|
||
Патч x265 остаётся диагностическим материалом и не требуется выбранному способу.
|
||
|
||
Компонент кодирования ChatGUI, 14.10.2026
|
||
StreamVideoEncoder переименован в LiveVideoEncoder и выделен в chatgui_live_video;
|
||
трансляции используют тот же код, без дублирования захвата/конвертации/FFmpeg.
|
||
Явный профиль H.264 Constrained Baseline / H.265 Main задаёт level, reference=1,
|
||
VBV и 8-bit 4:2:0. Для этого режима пока проверены software libx264/libx265.
|
||
Открытие проверяет независимый IDR настоящим decoder: profile, level, Main tier,
|
||
pixel format, отсутствие B-кадров и размер. Проверка принятого option не заменяет
|
||
эту проверку bitstream. Automatic-профили трансляций сохраняют прежний выбор GPU/SW.
|
||
Опции encoder сверены с https://ffmpeg.org/ffmpeg-codecs.html#libx265 и разделом libx264.
|
||
|
||
CallVideoEncoder принадлежит video worker. Он хранит единственную pending
|
||
команду generation/request/bitrate, отклоняет replay, чужой generation и выход за
|
||
согласованный maximumBitrate. После команды кандидат открывается в фоне;
|
||
на ближайшем IDR после готовности проверяется полный KEY с точным исходным PTS.
|
||
Старый encoder сохраняется до успешной проверки; stop ждёт завершения подготовки.
|
||
При отказе кандидата возвращается completion с bitrate=0 и используется прежний
|
||
контекст. Неизменный target также подтверждается на KEY без пересоздания.
|
||
Completion отделён от отправки кадра: даже при закрытом admission его нужно
|
||
передать в call_video_rate_applied. Периодический IDR задаётся по capture PTS,
|
||
поэтому пропуски кадров/закрытая сеть не сдвигают применение на дополнительные GOP.
|
||
Физический захват камеры, audio origin и сетевые frame_id компонентом не меняются.
|
||
|
||
test_call_video_encoder прошёл: 5 QtTest cases (включая init/cleanup), без skip.
|
||
Для обоих codecs: 640x360@30, level 3.1, VBV 1 Мбит, шумовая сцена;
|
||
запрос на кадре 7, переход на кадре 30, один decoder на все 360 кадров.
|
||
Проверены PTS каждого decoded frame, профиль/level/размер/B=0 и средний bitrate:
|
||
H.264: 3996916 / 296904 / 3989748 бит/с;
|
||
H.265: 3993720 / 302956 / 3999788 бит/с.
|
||
Отдельно проверены отказ новой конфигурации с сохранением старого encoder,
|
||
предел bitrate, pending/replay/generation, force-key и разрыв capture PTS вперёд.
|
||
Логи: /tmp/call-live-video-test-final.log, /tmp/call-live-video-build-final.log.
|
||
test_stream_publish: 11 passed, 1 skip (capture под Xvfb), 0 failed;
|
||
/tmp/call-live-stream-regression.log. После уточнения VBV профильная проверка
|
||
liveSoftwareBitrateKeepsDecoder повторена успешно, /tmp/call-live-stream-bitrate-final.log.
|
||
ChatGUI собран; ./check.sh: 154/154, proxy 9/9, burst/load PASS за 118с;
|
||
/tmp/call-live-core-check.log. Android в этом этапе не менялся.
|
||
|
||
Граница этого этапа: рабочий codec component, ещё не камера/worker/видеозвонок.
|
||
Следующим этапом реализовано согласование ограничений, описанное ниже.
|
||
|
||
Согласование ограничений codec, 14.10.2026
|
||
Общий C-протокол фиксирует H.264 Constrained Baseline / H.265 Main, Main tier,
|
||
8-bit 4:2:0, progressive, reference=1, B=0. Другие профили этим протоколом не объявляются.
|
||
CAPS отдельно для encode/decode каждого codec передаёт width/height/FPS,
|
||
pixels_per_second, maximum_bps, maximum_vbv_bits и максимальный level.
|
||
Размер CAPS теперь 80 байт, заголовка фрагмента 60 байт; старый формат не поддерживается.
|
||
|
||
call_video_choose пересекает encode отправителя с decode получателя и выбирает
|
||
H.265, затем H.264. Явный codec запрещает автоматическую замену. Выбирается минимальный
|
||
level, вмещающий весь запрошенный режим, включая максимальный bitrate и VBV.
|
||
Неподходящий запрос не меняется и не сокращается молча; более узкий диапазон требует
|
||
нового явного выбора владельцем. Таблицы проверяют размер, частоту, геометрию и BR/CPB.
|
||
AVC учитывает дополнение до макроблоков 16x16; HEVC консервативно резервирует дополнение
|
||
до CTU 64x64 независимо от backend. Это может выбрать level выше минимального для
|
||
конкретного encoder. Пределы BR/CPB взяты консервативно для VCL без повышающих NAL-факторов.
|
||
Сверено с таблицами FFmpeg и исходниками x265 4.1:
|
||
https://raw.githubusercontent.com/FFmpeg/FFmpeg/master/libavcodec/h264_levels.c
|
||
https://raw.githubusercontent.com/FFmpeg/FFmpeg/master/libavcodec/h265_profile_level.c
|
||
|
||
CAPS задаёт независимые верхние границы: не гарантируется работоспособность всех
|
||
их сочетаний на конкретном устройстве. Перед объявлением и использованием нужны
|
||
платформенные пробы encoder/decoder. Проверка структуры формата не заменяет проверку
|
||
фактических parameter sets и кадров декодером.
|
||
|
||
call_video_format содержит level, maximum_bps и vbv_bits. Эти поля, codec и геометрия
|
||
неизменны внутри generation; изменение требует нового generation и KEY.
|
||
Текущий bitrate меняется на IDR в пределах этого формата без нового generation.
|
||
call_video_configure_rate получает весь формат, проверяет обе CAPS и сохраняет его;
|
||
TX обязан передавать именно этот формат, RX также проверяет согласованные ограничения.
|
||
Дополнительный потолок регулятора может быть ниже уже применённого bitrate, чтобы
|
||
дождаться его снижения, но applied не может превышать maximum_bps самого формата.
|
||
Изменение пользовательского диапазона не переписывает согласованный формат.
|
||
|
||
Если новые CAPS перестали вмещать текущий формат, admission закрывается, ожидающий
|
||
TX-кадр отбрасывается с причиной capabilities_changed и запрашивается новый KEY.
|
||
CallVideoEncoder открывается прямо из call_video_format; дублирующего описания
|
||
режима между общим протоколом и desktop encoder больше нет. Проверка кандидата
|
||
реальным decoder и сохранение старого контекста при отказе остаются обязательными.
|
||
Диагностика CAPS выводит level/bitrate/VBV каждой стороны; отклонённый TX показывает
|
||
frame_id/PTS относительно предыдущего кадра, размер/offset и валидность формата.
|
||
|
||
Проверки: test_call_video покрывает направленный выбор, fallback, границы level,
|
||
bitrate/VBV, атомарность отказа и смену generation. test_call: 2/2 PASS, включая
|
||
сужение CAPS при ожидающем кадре и завершение звонка; /tmp/call-envelope-network-fixed.log.
|
||
Реальный codec-тест: 5/5 QtTest cases PASS. Для 640x360@30 общий выбор даёт level 3.0
|
||
(AVC 30 / HEVC 90), максимум 4 Мбит/с, VBV 1 Мбит. На 360 кадрах с одним decoder:
|
||
H.264: 3996048 / 296904 / 3989748 бит/с;
|
||
H.265: 3993720 / 302956 / 3999788 бит/с.
|
||
PTS, профиль и level проверены на всех участках; /tmp/call-envelope-codec-test.log.
|
||
Итоговый ./check.sh: 154/154, proxy 9/9, burst/load PASS за 128с;
|
||
/tmp/call-envelope-full-check-final.log. ChatGUI и Android assembleDebug собраны:
|
||
/tmp/call-envelope-gui-build-verified.log, /tmp/call-envelope-android-build-final.log.
|
||
|
||
Интеграция платформ и аппаратная проверка, 14.10.2026
|
||
Добавлен общий call_video_port: один TX mailbox, RX до восьми кадров/4MiB,
|
||
команды формата/bitrate с ID звонка, отменяемый post, безопасный detach ядра.
|
||
Сетевой test_call проверяет обе стороны port, владение RX, backpressure TX,
|
||
изменение диапазона и отмену ожидающего post: 2/2 PASS; /tmp/call-video-port-network.log.
|
||
ChatGUI: отдельные TX/RX workers, Qt camera, FFmpeg decoder с проверкой выхода,
|
||
очередь показа по call_audio_get_clock. Окно содержит камеру, разрешение, codec,
|
||
диапазон bitrate и видео. Сборка успешна; production decoder проверен на прежних
|
||
360 кадрах каждого codec с переходами bitrate, 5/5 QtTest cases PASS:
|
||
/tmp/call-video-desktop-integration-build.log, /tmp/call-video-decoder-test.log.
|
||
|
||
Android: JNI к общему port, Camera2/ImageReader YUV, смена MediaCodec на IDR без
|
||
перезапуска камеры при смене bitrate, RX Surface decoder по аудиочасам с drain
|
||
старого generation. CallService владеет видео и camera foreground; CallScreen
|
||
содержит управление/разрешение камеры/Surface. AssembleDebug успешен, установлено
|
||
на D2AR10P3600820 и RZ8R72MG64B. Полный видеозвонок ещё НЕ принят и не проверен.
|
||
Фактический VBV аппаратного encoder также пока не подтверждён: MediaCodec не даёт
|
||
универсального управления CPB, принятие configure не доказывает этот предел.
|
||
|
||
Аппаратный блокер подтверждён явной debug instrumentation CallVideoProbe:
|
||
adb -s SERIAL shell am instrument -w com.utun.chat/com.utun.chat.data.CallVideoProbe
|
||
Samsung RZ8R72MG64B: c2.qti.avc.encoder проходит реальный encode/decode при явном
|
||
AVCProfileConstrainedBaseline. c2.qti.hevc.encoder/OMX.qcom.video.encoder.hevc:
|
||
SPS profile=1, tier=1, level=93 при запросе Main tier (первые байты 42 01 01 21).
|
||
D2AR10P3600820: c2.unisoc.avc.encoder/OMX.sprd.h264.encoder возвращают SPS
|
||
profile=66, constraints=128, level=31, а не Constrained Baseline; явный запрос
|
||
AVCProfileConstrainedBaseline этого не меняет. HEVC Main/Main tier/level=93
|
||
имеет sps_max_dec_pic_buffering_minus1=2 (три decoded pictures), reorder=0.
|
||
Текущий Android validator требует DPB<=2; это более жёсткое требование, чем
|
||
reference=1: размер DPB нельзя автоматически приравнивать числу активных references.
|
||
Логи: /tmp/call-video-probe2-D2AR10P3600820.log,
|
||
/tmp/call-video-probe2-RZ8R72MG64B.log. Первый телефон не объявляет ни одного codec,
|
||
Samsung объявляет только AVC. Нельзя считать такое состояние готовыми видеозвонками.
|
||
|
||
Дополнительно нужно разделить probe encode/decode: сейчас Android и desktop
|
||
консервативно объявляют decoder только после успешного собственного encoder.
|
||
Это лишает совместимого приёма устройства с неподходящим передатчиком.
|
||
Приёмный decoder следует проверять независимо эталонными потоками и общими limits.
|
||
Нужно проверить нормализацию HEVC tier по стандарту: High tier для level 3.1
|
||
нельзя просто разрешить как ещё один корректный режим.
|
||
|
||
Рекомендуемая доработка: H.264 Baseline (включая Constrained Baseline), HEVC Main,
|
||
отдельные проверенные encode/decode, DPB по уровню и фактическим SPS при reorder=0.
|
||
Сохранить проверку реального потока, ограниченные очереди и передачу bitrate на IDR;
|
||
не исправлять маркировку SPS без доказательства соответствия. Другой вариант —
|
||
поставлять на Android свои software codecs, сохранив прежний строгий контракт.
|
||
Дальнейшая реализация остановлена по правилу AGENTS.md о выявленной нестыковке.
|
||
После решения нужны проверки CPB/bitrate, камеры/смены Surface/lifecycle, полный
|
||
check.sh, Kotlin unit-тесты и реальные звонки Android↔Android↔ChatGUI.
|
||
|
||
Устранение аппаратных блокеров и проверка совместимости, 14.10.2026
|
||
Реализован согласованный план: Baseline/CB как отдельные AVC profiles, общий C-анализатор
|
||
VPS/SPS/PPS/HRD/IDR, нормативный DPB, независимые encode/decode probes с эталонными
|
||
потоками. Убрано неподтверждённое обещание VBV MediaCodec. Фактические profile/level
|
||
проверяются против CAPS после подготовки encoder; смена bitrate подтверждается
|
||
только настоящим IDR. Android допускает один экземпляр encoder и восстанавливает
|
||
прежний режим при отказе. Встречные направления выбирают codec независимо.
|
||
VIDEO_DECODE_OK/REJECT передают результат decoder; Auto исключает отвергнутый codec
|
||
для текущего выбора и пробует fallback. Старые generations не влияют на текущий.
|
||
Сетевой тест проверяет acceptance, rejection, stale result и сохранение запрета
|
||
отправки после очередного tick регулятора. При смене звонка очищаются pending команды port.
|
||
Сетевой долг ограничен полусекундой целевого потока плюс базовый RTT, с минимумом
|
||
64 KiB для IDR и абсолютным пределом 2 MiB. Частичная отправка по-прежнему ограничена
|
||
2с. На этом этапе предел отставания был 500мс; с 15.10.2026 заменён общим playout на 50мс (см. ниже).
|
||
|
||
Подтверждено на подключённых устройствах последней debug instrumentation:
|
||
- D2AR10P3600820: c2.unisoc.hevc.encoder Main/level 93/DPB=3; AVC Baseline/level 31.
|
||
Независимо работают c2.unisoc.hevc.decoder и AVC decoder (Baseline + CB).
|
||
- RZ8R72MG64B: c2.qti.avc.encoder CB/level 31. HEVC encoder отвергнут за tier=1,
|
||
level=93; независимо работает c2.qti.hevc.decoder и AVC decoder (Baseline + CB).
|
||
- На обоих телефонах последовательные открытия 4M -> 300k -> 4M прошли проверку
|
||
реального IDR/PTS; это проверка применения конфигурации, не измерение среднего CBR
|
||
на сложной сцене (синтетический серый кадр не требует целевой полосы).
|
||
- Фактический HEVC Unisoc декодирован Samsung; AVC Samsung декодирован Unisoc.
|
||
AVC Baseline Unisoc -> Samsung вернул 3/4 кадров: этот remote probe пока НЕ прошёл;
|
||
требуется диагностика задержанного выхода конечного потока. Каждый probe подаёт 4 IDR.
|
||
- Все три аппаратных потока декодированы production CallVideoDecoder ChatGUI.
|
||
Экспортные кадры синтетические, камера не включалась; /tmp/call-video-cross/.
|
||
|
||
Проверки: ./check.sh — 154/154, proxy 9/9, burst/load PASS (131с),
|
||
/tmp/call-profile-full-check.log. ChatGUI vibechat собран; codec QtTest 6/6 PASS,
|
||
/tmp/call-profile-codec-final.log. Перекрёстный production decode PASS,
|
||
/tmp/call-profile-cross-desktop.log. Android assembleDebug + 81/81 unit PASS,
|
||
/tmp/call-profile-cross-build.log; APK установлен на оба устройства.
|
||
Полная ручная приёмка звонка с реальными камерами/Surface, A/V и сменой режимов
|
||
остаётся отдельной проверкой; на рабочем Linux-хосте отсутствуют /dev/video*.
|
||
|
||
15.10.2026 — исправление desktop encoder при русской числовой локали
|
||
По логу звонка 23:58 USB-камера уже отдаёт кадры, но оба encoder probe отказали:
|
||
libx264 неверно разобрал level=3.1 и выдал level 30; libx265 отклонил level-idc=3.1.
|
||
Воспроизведено на production CallVideoEncoder: 1280x720/30, C — оба успешны,
|
||
ru_RU.UTF-8 — оба отказали. Параметры level теперь целочисленные (31 для уровня 3.1);
|
||
HEVC wire level 93 преобразуется делением на 3. Глобальная локаль приложения не меняется.
|
||
Строгая проверка фактического профиля/уровня сохранена; параметр encoder виден при video=debug.
|
||
Регрессия проверяет оба codec в C/ru_RU.UTF-8, декодирование 720p и смену 1M -> 300k -> 4M.
|
||
ChatGUI пересобран; test_call_video_encoder — 10/10 PASS в каждой локали, без skipped.
|
||
Логи: /tmp/call-camera-locale-test-c.log, /tmp/call-camera-locale-test-ru.log.
|
||
Работающий GUI автоматически не перезапускался; проверка полного звонка после исправления остаётся.
|
||
|
||
UI и периодические фризы (15.10.2026)
|
||
Android: принимаемое видео сначала занимает весь экран, своя камера — миниатюрой поверх него.
|
||
Назад возвращает к управлению звонком с двумя доступными миниатюрами (своей и собеседника).
|
||
Нажатие миниатюры открывает выбранное видео на весь экран; второе остаётся в углу и позволяет
|
||
поменять их местами. Выход в управление не выключает передачу/приём и не пересоздаёт TextureView/Surface.
|
||
Ориентация интерфейса фиксируется на время экрана звонка. Только большое видео дополнительно
|
||
поворачивается на 90 градусов, если так кадр занимает большую площадь; миниатюры не поворачиваются.
|
||
Весь кадр вписывается с исходными пропорциями, без crop и растяжения; при несовпадении пропорций остаются поля.
|
||
Выход с экрана звонка восстанавливает прежнюю политику ориентации Activity.
|
||
При видео экран остаётся включённым, proximity-overlay отключён. Если выбран EARPIECE,
|
||
переход на SPEAKER ждёт подтверждённого FAR; UNKNOWN/NEAR переключение запрещают.
|
||
Выключение видео, конец звонка и ручной выбор выхода отменяют ожидание. HEADSET не меняется,
|
||
автоследование за гарнитурой сохраняется. Отсутствующий датчик означает отсутствие proximity;
|
||
при отказе регистрации состояние остаётся UNKNOWN с предупреждением, автоматического переключения нет.
|
||
Без RX локальная камера сначала видна миниатюрой на экране аудиозвонка; без кадров
|
||
место под видео не резервируется. Касание показывает кнопки, через 5с они скрываются.
|
||
Имя/статус/диагностика не рисуются поверх видео; параметры вынесены в «Настройки звонка».
|
||
Кнопки и миниатюры учитывают вырез и systemBarsIgnoringVisibility, включая боковую панель
|
||
навигации и временно скрытые системные кнопки. Видео по-прежнему использует весь экран.
|
||
TextureView и Surface сохраняются при показе кнопок; decoder освобождает старый Surface
|
||
до его release. Запоздалый detach предыдущего Surface не отключает новый.
|
||
Preview получает прямой output той же Camera2 через общий StreamPreview/CameraPreviewView,
|
||
без Bitmap-конвертации и ограничения 5 fps. Surface удерживается до закрытия CameraCaptureSession/CameraDevice;
|
||
разворачивание/миниатюра меняют только геометрию TextureView. На SM подтверждено 29–30 fps.
|
||
Отказ preview output логируется и оставляет YUV-output передачи; encoder при attach/detach не перезапускается.
|
||
Desktop: первый RX кадр открывает отдельное изменяемое окно видео, без автоматического fullscreen.
|
||
Окно звонка с управлением и всеми настройками сохраняет свою геометрию и состояние настроек.
|
||
Видео сохраняет пропорции, своя миниатюра — в углу окна видео. F11/двойной щелчок переключают
|
||
fullscreen только для видео, Esc возвращает его обычную геометрию. Закрытие видеоокна
|
||
не завершает звонок; «Показать видео» открывает его повторно. Новые кадры сами не отменяют закрытие.
|
||
Preview берётся из того же QVideoFrame при появлении нового кадра, без прежнего ограничения 10 fps.
|
||
Только при отсутствии RX своя миниатюра
|
||
показывается в окне звонка; без кадров пустого видеоблока нет. После 5с без показанных кадров RX скрывается:
|
||
отдельного VIDEO_OFF в протоколе пока нет.
|
||
Desktop UI smoke: отдельные окна, сохранение геометрии/настроек звонка, resize видео,
|
||
F11/Esc, закрытие/повторное открытие без hangup, local-only и завершение — PASS
|
||
(/tmp/call-video-separate-preview.log). ChatGUI собран; Android assembleDebug и 81 unit-тест — PASS.
|
||
Автоматическое ожидание FAR и независимый поворот видео требуют проверки в следующем реальном звонке.
|
||
|
||
15.10.2026, диагностика низкого FPS desktop -> Samsung:
|
||
До исправления capture=30/s, encoded=20/s, paced=10/s; TX accepted=5/s, audio_busy=15/s,
|
||
audio_ahead=140–180ms. RX pulled/decoded/rendered=5/s, late=0: кадры терялись до отправки.
|
||
Вместо порога 33333мкс от прошлого кадра desktop использует бюджет 30 fps с запасом одного кадра
|
||
и минимальным интервалом 25мс. Бюджет сохраняет дробную часть при пропуске кадра; фиксированная сетка
|
||
теряла серии кадров при уходе фазы камеры. Тест охватывает 10 минут с дрожанием и квантованием PTS,
|
||
а также ограничение входных 40/60 fps. FIFO TX сохраняет кадры во время ожидания аудио.
|
||
test_call проверяет семь последовательных KEY/P кадров за audio barrier, порядок после release и предел PTS.
|
||
Диагностика: /tmp/call-fps-desktop-live.log, /tmp/call-fps-sm-live.log; unit/core/Qt проверки прошли.
|
||
|
||
Повторный звонок после FIFO: desktop offered/accepted около 30 fps, audio_busy=0;
|
||
Samsung pulled/decoded/rendered около 30 fps, late=0. Исчезновение обратного видео вызвано
|
||
тайм-аутом команды bitrate на SM: 03:07:05.899 timeout request=1, 03:07:05.992 запоздалый applied.
|
||
Автоматические IDR аппаратного кодека постоянно переносили программную границу следующего KEY.
|
||
Теперь период KEY отсчитывается от успешной подачи нашего запроса, а не от выходного IDR;
|
||
смена bitrate остаётся на границе KEY. Логи: /tmp/call-fps-sm-after.log, /tmp/call-fps-desktop-later.log.
|
||
|
||
Следующий живой звонок: RX desktop сохраняется несколько минут, около 30 fps. Остаточные 16–17 fps
|
||
desktop -> SM уже возникали в самой USB-камере: V4L2 interval=1/30, Exposure Dynamic Framerate=1.
|
||
Отключение этого флага во время звонка сразу дало capture/encode/accepted=30 fps, paced=0, audio_busy=0
|
||
(/tmp/call-video-fixed-camera-rate.log). На Linux звонок теперь отключает этот флаг после активации
|
||
QCamera и восстанавливает его после остановки; автоэкспозиция не меняется. Неподдерживаемый control
|
||
не мешает работе камеры. Лог video local preview отдельно показывает частоту и время обновления миниатюры.
|
||
Общий check.sh: 154/154, proxy 9/9, burst/load PASS; Qt codec/clock и Android 81 unit PASS.
|
||
|
||
Диагностика задержки desktop -> SM: локальный preview быстрый, но capture_age_us=-180000..-216000,
|
||
TX queue=6–8, queue_age_us=184000..248000, tail_ahead_us около 200000.
|
||
Первый запоздавший callback камеры привязывал относительный PTS к слишком позднему now;
|
||
следующие кадры оказывались в будущем и корректно ожидали audio barrier.
|
||
CallVideoCaptureClock теперь ограничивает mapping временем прихода каждого кадра и корректирует
|
||
offset только назад; поздний callback не увеличивает offset. Регрессия исходного PTS начинает новую привязку.
|
||
Тест моделирует 220мс задержки первого callback, её постепенное исчезновение, поздний callback и перезапуск PTS.
|
||
capture_age_us/clock_correction_us показывают привязку; queue_age_us использует только BOOTTIME,
|
||
tail_ahead_us сравнивает media PTS в MONOTONIC. Разность BOOTTIME и MONOTONIC не является задержкой.
|
||
Qt encoder/clock PASS; изменение требует повторного живого звонка после перезапуска ChatGUI.
|
||
Лог исходного дефекта: /tmp/call-latency-new-sample.log.
|
||
|
||
Подтверждённая причина фризов раз в 1–2с: коррекция capture timestamp меняла audio source_epoch,
|
||
а обе платформы сбрасывали video decoder и ждали KEY. Теперь source_epoch обновляет
|
||
аудиопривязку без потери video references, готовых кадров и последнего показанного PTS.
|
||
Отдельный production RX тест: 90/90 кадров, 32 смены аудиоэпохи, 0 дополнительных KEY,
|
||
0 decoder rejection (/tmp/call-video-clock-final.log).
|
||
Android больше не отбрасывает кадр из-за интервала чуть меньше 33333мкс: Camera2 уже
|
||
ограничивает FPS; повторная фильтрация превращала дрожание timestamps в падение до 15fps.
|
||
Desktop rate test: 10/10 PASS, непрерывные H.264/H.265 4M -> 300k -> 4M, оба decoder.
|
||
H.264 commit 5–7мс; H.265 51–76мс включая кодирование первого кадра, подготовка — в фоне.
|
||
Измерение /tmp/call-video-background-test.log; для H.265 стоимость кодирования остаётся существенной.
|
||
Android assembleDebug и 81 unit-тест проходят. Полный звонок с камерами после этих правок
|
||
требует ручной приёмки; автоматические проверки не подтверждают его целиком.
|
||
|
||
Аппаратная смена bitrate без перезапуска подтверждена на шумовом YUV с ограниченным контрастом:
|
||
Samsung AVC: 3.985M -> 306.8k -> 3.990M; Unisoc HEVC: 4.031M -> 291.9k -> 4.042M;
|
||
Unisoc AVC: 3.993M -> 29.3k -> 3.994M бит/с. В каждой пробе получены все 360 кадров
|
||
с точными PTS и проверенными KEY. При сильной квантизации шум пропадает; фактический
|
||
выход ниже target допустим. Проверяются верхняя граница low-rate и восстановление high-rate,
|
||
а не наличие filler до target. Полностью случайный 8-bit шум в первой пробе Samsung
|
||
превысил 4M: аппаратный CBR не является жёстким ограничителем выходного потока.
|
||
Сетевой admission/ограничитель очереди остаётся необходимым.
|
||
Логи: /tmp/call-video-dynamic-sm-detail2.log, /tmp/call-video-dynamic-sp-final.log,
|
||
/tmp/call-video-sp-rates-final.log. CallVideoProbe принимает -e codec 1/2 для отдельной пробы.
|
||
Итоговый 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 пересобран и перезапущен. Поведение кодеков, очередей, аудиосинхронизации не изменено.
|
||
|
||
Независимое расписание показа, 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-границы вслепую.
|
||
|
||
Проверка финальной сборки, звонок 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 для маскировки этой паузы. В этом диагностическом проходе код не менялся.
|
||
|
||
Продолжение TX после исчерпания budget, 15.10.2026
|
||
После успешной порции из 16 фрагментов flush ставит один uasync_call_soon, если остался кадр,
|
||
разрешённый audio_end_pts и подтверждёнными CAPS. Новый callback выдаёт следующую ограниченную порцию.
|
||
uasync обрабатывает только исходный batch очереди immediate, поэтому самопостановка не захватывает
|
||
цикл целиком; между batch остаётся обработка сокетов/таймеров. Новый поток или периодический таймер не нужен.
|
||
Каждый фрагмент по-прежнему проверяет capabilities, deadline, media debt и место в router send_q.
|
||
Выход по backpressure не ставит новое immediate-продолжение; возобновление остаётся за штатными событиями/tick.
|
||
Другой flush (например, новый audio block) отменяет прежнее ожидающее продолжение. Callback перед работой
|
||
снимает собственный handle; stop/discard отменяют pending до освобождения v/данных. Все операции в uasync-потоке.
|
||
|
||
Без новых покадровых логов: секундный video TX flow содержит flush_yields (постановки), flush_runs
|
||
(выполненные callback), flush_wait_max_us (наибольшее ожидание продолжения, включая опережающий audio flush),
|
||
flush_net_wait (выходы по debt/send_q), flush_audio_wait (выходы по audio/CAPS-барьеру).
|
||
Выборочный stage=send дополнен budget_yields текущего кадра; queue_age_us сохраняет полный срок в TX.
|
||
Эти счётчики различают исчерпание порции, задержку исполнения и ограничение транспорта; они не являются
|
||
отдельным измерением физической сети и не должны складываться с queue_age.
|
||
|
||
test_call_video_flush использует настоящий transport, сериализацию фрагментов и uasync, управляемый router.
|
||
45001 байт отправляются тремя порциями (16/16/6), без audio/50мс tick, с проверкой каждого байта и offset.
|
||
Проверены остановка при отсутствии места/большом inflight, возобновление без дублей, audio/CAPS-барьеры,
|
||
опережающий audio flush, stop/discard с pending callback, равенство alloc/free immediate handles.
|
||
Тест прошёл; test_call_video/rate/playout, сетевой test_call (2/2), Qt encoder (13/13), Qt clock
|
||
(90/90 ровный вход, 87/90 с задержками, ноль key requests/rejections) также прошли.
|
||
Ядро, ChatGUI, APK собраны; Gradle unit-задача актуальна, 103 теста без ошибок (up-to-date).
|
||
Артефакты проверки: /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 и не менять часы без подтверждающих измерений.
|
||
|
||
GPU-кодирование desktop-звонка, 18.10.2026
|
||
В основном пути CallVideoEncoder выбирает только hardware: NVENC, QSV, AMF, VAAPI.
|
||
Software доступен только при явно указанном backend в проверках; автоматического CPU fallback нет.
|
||
Общий LiveVideoEncoder задаёт минимальный настроенный конвейер, без B-кадров/lookahead,
|
||
проверяет профиль/level/первый IDR. QSV работает внутри в 90kHz, capture PTS восстанавливается
|
||
по точному соответствию codec PTS; порядок выходов проверяется. До восьми входов, без неограниченной очереди.
|
||
NVENC использует delay=0, QSV/VAAPI async_depth=1, AMF ultralowlatency и async_depth=1 при наличии опции.
|
||
В старом FFmpeg AMF не поддерживает forced_idr; общий путь сохраняет периодические IDR,
|
||
как в трансляции экрана. Это видно в forced_keys/forced_idr и не выдаётся за поддержку принудительного IDR.
|
||
|
||
Worker сразу отдаёт все готовые кадры. Видеопорт атомарно копирует готовую пачку до восьми кадров
|
||
с общим пределом 2MiB в один mailbox и ставит один post; ожидания накопления пачки нет.
|
||
Busy возвращается до принятия любого кадра. После отказа транспорта зависимый хвост освобождается,
|
||
запрашивается KEY. Stop/detach освобождают всю ожидающую пачку. Android передаёт count=1.
|
||
При смене bitrate новый GPU готовится в фоне; до его первого проверенного IDR продолжают выходить
|
||
старые кадры с PTS раньше границы замены. Applied выдаётся после IDR, при отказе сохраняется старый GPU.
|
||
|
||
Диагностика: debug=trace,video=trace,call=debug. call GPU probe показывает pipeline_frames,
|
||
video encoder flow — pending, bitrate committed — pipeline_frames/pipeline_pts_us/retire_us.
|
||
test_call_video_gpu проверяет шесть Windows backend/codec сочетаний на настоящих bitstream и decoder,
|
||
с подменой GPU-границы: задержка, пачка из трёх кадров, точные PTS и отказ замены; это не тест драйвера.
|
||
Сетевой test_call проверяет атомарную пачку, busy, неверную пачку и teardown.
|
||
Фактическую глубину, время GPU и задержку показа необходимо подтвердить живым звонком на Windows.
|
||
|
||
AMF HEVC PPS, исправление 18.10.2026
|
||
В Windows-логе GPU выдавал IDR, но call verifier отвергал разрешённые PPS-флаги
|
||
dependent_slice_segments_enabled_flag/output_flag_present_flag ещё до отправки. encode оставался нулевым.
|
||
Общий verifier поддерживает эти флаги: первый IDR-слайс независим, последующие segments
|
||
проверяются с учётом CTB геометрии SPS и optional dependent flag; явный pic_output_flag должен быть 1.
|
||
Обе стартовые KEY-пробы проходят тот же call_video_check_key, что и live-путь, затем FFmpeg decoder.
|
||
Несовместимый backend не попадает в capabilities; выбор продолжает перебор GPU, без CPU fallback.
|
||
test_call_video проверяет сочетания PPS flags/extra header bits, independent/dependent segments,
|
||
отказ при выходе адреса за CTB и при отключённом picture output. test_call_video_gpu меняет PPS
|
||
на настоящем HEVC IDR и проверяет полный pipeline с decoder, а также отказ несовместимой стартовой пробы.
|
||
Общий verifier используется и на Android: для HEVC обновить обе стороны звонка. Буферизация не меняется.
|
||
|
||
Аудит восстановления после коротких пауз, 19.10.2026
|
||
Новое требование: сохранять последовательность encoded кадров, быстро декодировать пришедший
|
||
burst и плавно догонять показом. Короткая пауза не должна вызывать пропуск входного P-кадра,
|
||
ожидание следующего KEY или перескок на более свежее изображение.
|
||
Текущая реализация этому требованию не соответствует; в этой итерации добавлена диагностика,
|
||
алгоритм буферизации/показа и действующие ограничения не изменены.
|
||
|
||
1. Router сохраняет порядок, при заполнении RX port приостанавливает доставку/ACK и возобновляет
|
||
её после pull. RX port имеет 8 кадров/4MiB; это предел ёмкости, не обязательный стартовый запас.
|
||
2. Desktop декодирует последовательно, держит до двух готовых изображений. Android ограничивает
|
||
decoder inputs + готовые outputs восемью кадрами, готовые outputs — двумя. Подача/декодирование
|
||
в итоге ограничиваются освобождением готовых кадров, отдельного быстрого drain всего burst нет.
|
||
3. Playout имеет номинальное расписание 1.04x. При срыве поставки срок двигается по received_us,
|
||
но позднее выполнение worker само по себе срок не переносит. DROP_LATE отбрасывает показ при
|
||
отставании от audio PTS больше 50мс; DROP_SCHEDULE пропускает изображение, если следующий
|
||
кадр тоже уже пора показать. Оба пути работают после decode, codec references сохраняются.
|
||
4. Desktop GUI хранит последнее выбранное изображение вместо FIFO. Пока queued notification
|
||
не исполнено, новые publishImage заменяют предыдущее. Это ещё один пропуск показа после
|
||
decode. Прежний ui_wait_us считался от последней замены, поэтому мог скрыть паузу GUI;
|
||
диагностика теперь отдельно считает ожидание notification, возраст последней замены и overwritten.
|
||
5. Потеря до decoder тоже возможна. TX mailbox освобождает всю пачку после попытки передачи,
|
||
включая кадр с результатом busy=0 и оставшийся хвост. Producer получает запрос KEY, а не retry.
|
||
Admission закрывается при receive_busy или достижении предела долга; transport также имеет
|
||
предел 32 кадров/500мс PTS/2MiB и deadline головы 2с. Отказ готовому encoded кадру разрывает
|
||
цепочку references; последующие P-кадры ждут KEY. Это отличается от DROP_LATE/SCHEDULE.
|
||
|
||
Контрольная симуляция настоящего call_video_playout (90 кадров, 30fps, пауза 200мс):
|
||
пауза доставки при непрерывном аудио — показано 86, late=4;
|
||
пауза CPU при непрерывном аудио — показано 84, late=5, schedule=1;
|
||
пауза CPU и удержание audio PTS с последующим догоном 1.1x — показано 77, late=12, schedule=1.
|
||
Шаг poll в этих сценариях 1мс; при шаге 15.625мс последний сценарий даёт 74 показа и 15 late.
|
||
Шаг 15.625мс — параметр модели, не утверждение о фактическом Windows timer resolution.
|
||
Даже при идеальном исполнении 1.04x убирает дополнительные 200мс примерно за 5с.
|
||
Существующий test_backlog явно требует DROP_LATE и DROP_SCHEDULE после паузы 102мс;
|
||
его успешность подтверждает старую политику, а не новое требование сохранения кадров.
|
||
|
||
Для нового поведения нужны согласованные изменения:
|
||
- encoded FIFO с переносом backpressure до producer и сохранением неотправленного хвоста;
|
||
- последовательная подача decoder без ожидания срока показа, пока хватает выходной ёмкости;
|
||
- упорядоченный показ с адаптивным ускорением по накопленной длительности, без late/schedule
|
||
пропусков при короткой паузе. Возобновление от первого сохранённого кадра, без мгновенного burst;
|
||
- сохранение выбранного кадра до фактического потребления GUI/render, вместо overwrite последним;
|
||
- временное A/V-отставание во время восстановления либо согласованная задержка аудио и видео.
|
||
Сохранить все кадры после 200мс паузы и одновременно требовать A/V <=50мс невозможно.
|
||
Предел короткой паузы, память и политика длительного переполнения должны задаваться явно.
|
||
Обычный догон не должен запрашивать KEY или сбрасывать decoder.
|
||
|
||
Windows-диагностика: AudioDiag теперь работает через тот же bounded reporter, что и Linux.
|
||
При call=debug WASAPI queue показывает padding и stream latency отдельно, callback/write —
|
||
время исполнения/интервалы; video RX worker показывает decode и опоздание пробуждения.
|
||
video late drop содержит точные PTS/AV/возраст первого позднего кадра за окно, playout —
|
||
диапазоны всех late кадров. Измерения не корректируют Windows callback-estimate аудиочасы.
|