|
|
|
|
@ -66,7 +66,7 @@ producer запрашивает следующий IDR по существующ
|
|
|
|
|
[ ] Android MediaCodec: применение bitrate на ближайшем IDR и проверка фактического выхода. |
|
|
|
|
[+] Общий регулятор с детерминированными сценариями и подключением к router/encoder-командам. |
|
|
|
|
[+] Видеофрагменты, ограниченная сборка, обмен возможностями с подтверждением. |
|
|
|
|
[ ] Дополнить возможности ограничениями profile/level/tier и диапазоном битрейта. |
|
|
|
|
[+] Согласование фиксированных profile/tier, level и пределов bitrate/VBV; проверка transport/encoder. |
|
|
|
|
[ ] Завершить A/V scheduler с платформенными очередями захвата/encode. |
|
|
|
|
[+] Общие capture PTS и отображение позиции аудиоустройства в исходное время. |
|
|
|
|
[ ] ChatGUI: движок, окно и настройки; Android: движок, JNI, сервис и экран. |
|
|
|
|
@ -356,10 +356,60 @@ liveSoftwareBitrateKeepsDecoder повторена успешно, /tmp/call-liv
|
|
|
|
|
ChatGUI собран; ./check.sh: 154/154, proxy 9/9, burst/load PASS за 118с; |
|
|
|
|
/tmp/call-live-core-check.log. Android в этом этапе не менялся. |
|
|
|
|
|
|
|
|
|
Граница готовности: это рабочий codec component, ещё не камера/worker/видеозвонок. |
|
|
|
|
В CAPS пока нет согласования level/tier/bitrate/VBV: до его реализации компонент |
|
|
|
|
не объявляется доступным в реальном звонке. Владелец обязан проверять соответствие |
|
|
|
|
размера/FPS согласованному envelope, а не считать маркировку level доказательством |
|
|
|
|
всех ограничений стандарта. Другие режимы, hardware codecs и Android требуют |
|
|
|
|
отдельных проверок. Следующий этап — CAPS envelope и подключение capture/bridge, |
|
|
|
|
затем decoder/render по audio clock и UI на обеих платформах. |
|
|
|
|
Граница этого этапа: рабочий 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. |
|
|
|
|
|
|
|
|
|
Текущая граница готовности: согласование и desktop codec готовы как компоненты. |
|
|
|
|
Далее нужны платформенные пробы CAPS, capture/worker/bridge, decoder/render по audio |
|
|
|
|
clock, Android MediaCodec и управление камерой/разрешением/кодеком в окне звонка. |
|
|
|
|
Реальные звонки между платформами и аппаратные codecs ещё не проверены. |
|
|
|
|
|