Comments 11
Спасибо за статью!
Задержку по видео измеряем с помощью уже отработанного приёма: снимаем секундомер, фотографируем вместе экран с исходящим видео и экран принимающего клиента, сравниваем.
Поделюсь идеей: если вывести время в виде QR-кода, задержку можно будет измерить программно, без участия человека. Такое решение даже позволит оформить этот эксперимент в виде юнит-теста: эмулятор сервера кодирует время в видеопоток QR-кодов, эмулятор клиента декодирует QR-коды и оценивает задержку.
Правильно понимаю, что при демонстрации экрана упор сделан больше на статический контент? И из-за ограничения qp теперь для не статического контента при демонстрации экрана траффика теперь потребуется больше? И если не пролезет в сеть то кадров выкинете ещё больше?
И тут же вопрос - а как меняете QP енкодера на Андроиде(в медиакодеке конечно же)? Официально это можно делать будет только с 12 Андроида(и то не уверен что все вендоры это сразу поддержат)
Да, упор на статический контент и читаемость текста. Динамический действительно упадёт в низкий фпс при нехватке сети (может быть 1 фрейм в несколько секунд). Для динамического контента вероятно сделаем в будущем автоопределение/рубильник для пользователя чтобы переключать кодек в другой режим.
Что касается MediaCodec - он действительно слишком непредсказуем в дикой природе чтобы получить надёжный результат по чёткости. Поэтому для кейса демонстрации экрана используем VP9 енкодер на CPU. Так как фреймрейт для этого случая относительно низкий - ресурсов устройства хватает.
А почему не используете H265? В последнее время качество аппаратных энкодеров выросло, особенно в устройствах Apple.
Это хороший вопрос на который не очень простой ответ. Если кратко: накладные расходы связанные с дополнительной фрагментацией из-за добавления ещё одного кодека превышают профит от внедрения H.265.
Чуть подробнее: представим сценарий в котором в одном звонке часть участников зашли с веб браузеров, часть с iOS. Если iOS отправляет только VP9/H.264 видео - его можно прозрачно пробрасывать в браузер и браузер его декодирует. Если же iOS отправляет H.265 - придётся для браузеров включать транскодирование на сервере, что неизбежно приведёт к понижению качества и большой нагрузке на сервера. С другой стороны есть VP9, который уже давным-давно живёт в Android и Chrome/Chromium, с недавнего времени нативно поддерживается и в iOS и в Safari. Поэтому VP9 для нас лучше отрабатывает кейс "смешанного" звонка.
По эффективности сжатия VP9 и H.265 близки к друг другу. Поэтому если внедрять новый кодек то скорее имеет смысл смотреть в сторону AV1 который даст получше эффективность сжатия и уже доступен в Chrome.
По-моему, кроме H.264 особо и нет больше вариантов сейчас. Хороший кодек имеет как аппаратную поддержку декодирования, так и поддержку кодирования (а как ещё можно 4к поток в реальном времени сжимать?)
Помимо H.264 есть альтернативы VP9, H.265, AV1:
- H.265, несмотря на хорошую поддержку железом как кодирования, так и декодирования, мало где доступен из коробки из-за особенностей лицензирования, так что убираем.
- С AV1 пока совсем всё грустно с аппаратной поддержкой: требуется Intel 11 серии, RTX 30xx или Radeon RX 60xx. Причём по большей части это только аппаратное декодирование, но не кодирование. Для видеохостинга норм, для видеозвонков — не норм.
- Остаётся VP9. С ним дела обстоят немного лучше. Правда, ни видеокарты NVIDIA, ни процессоры AMD в аппаратное ускорение кодирования пока не умеют.
Так что, увы, если хочется угодить всем, то пока только H.264.
Да, у разных кодеков свои сильные и слабые стороны. К примеру для кейса низкого битрейта и разрешения (плохая сеть) аппаратное ускорение уже не так актуально, потому что это более дешёвый кейс с точки зрения нагрузки на устройство. Можно кодировать более эффективным кодеком на CPU чтобы дать получше картинку юзеру. В платформе звонков в ВК мы изначально закладывали возможность переключать кодек на ходу, что даёт нам возможность включать оптимальный кодек по ситуации.
Мне кажется топология MCU для видео может работать.
Пусть все смотрят одинаковую картинку, разве проблема смотреть на себя?
А если кто-то хочет смотреть спикера, пусть запрашивает только спикера с сервера.
А где meet.jit.si? Очень полезный сервис так еще и родитель Google meet
А при трансляции экрана на Андроиде не сталкивались с проблемой общего доступа нескольких приложений к захвату микрофона девайса? Из-за политики Андроида в общем случае два обычных приложения не могут иметь доступ к микрофону одновременно и одно из приложений будет отправлять тишину. Может вы что-то делали с этим?
Видео в звонках ВКонтакте: 4К-скриншеринг и Quality on-demand для тысяч участников