Да, у разных кодеков свои сильные и слабые стороны. К примеру для кейса низкого битрейта и разрешения (плохая сеть) аппаратное ускорение уже не так актуально, потому что это более дешёвый кейс с точки зрения нагрузки на устройство. Можно кодировать более эффективным кодеком на CPU чтобы дать получше картинку юзеру. В платформе звонков в ВК мы изначально закладывали возможность переключать кодек на ходу, что даёт нам возможность включать оптимальный кодек по ситуации.
Это хороший вопрос на который не очень простой ответ. Если кратко: накладные расходы связанные с дополнительной фрагментацией из-за добавления ещё одного кодека превышают профит от внедрения H.265.
Чуть подробнее: представим сценарий в котором в одном звонке часть участников зашли с веб браузеров, часть с iOS. Если iOS отправляет только VP9/H.264 видео - его можно прозрачно пробрасывать в браузер и браузер его декодирует. Если же iOS отправляет H.265 - придётся для браузеров включать транскодирование на сервере, что неизбежно приведёт к понижению качества и большой нагрузке на сервера. С другой стороны есть VP9, который уже давным-давно живёт в Android и Chrome/Chromium, с недавнего времени нативно поддерживается и в iOS и в Safari. Поэтому VP9 для нас лучше отрабатывает кейс "смешанного" звонка.
По эффективности сжатия VP9 и H.265 близки к друг другу. Поэтому если внедрять новый кодек то скорее имеет смысл смотреть в сторону AV1 который даст получше эффективность сжатия и уже доступен в Chrome.
Да, упор на статический контент и читаемость текста. Динамический действительно упадёт в низкий фпс при нехватке сети (может быть 1 фрейм в несколько секунд). Для динамического контента вероятно сделаем в будущем автоопределение/рубильник для пользователя чтобы переключать кодек в другой режим.
Что касается MediaCodec - он действительно слишком непредсказуем в дикой природе чтобы получить надёжный результат по чёткости. Поэтому для кейса демонстрации экрана используем VP9 енкодер на CPU. Так как фреймрейт для этого случая относительно низкий - ресурсов устройства хватает.
Дополню насчёт решения использовать своё решение вместо webrtc
WebRTC — технология основанная на открытых стандартах которым >20 лет. RFC для RTP был опубликован в 1996, SDP в 1998. Для современных приложений конечно «базовые» варианты протоколов не годятся поэтому было добавлено много расширений, какие-то обязательные, другие опциональные. Со списком расширений можно ознакомиться здесь tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26.
В результате наслоений расширений получился протокол, который не совместим со старыми приложениями но при этом тянет много legacy.
Вот пример эволюции webrtc:
RFC 6464: добавлен заголовок в аудио пакеты который указывает уровень звука
RFC 6904: оказалось что этот заголовок передавать в открытом виде несекьюрно, добавили расширение для шифрования предыдущего расширения.
Клиентский код теперь должен поддерживать все возможные комбинации этих расширений, чтобы правильно работать и со старыми и с новыми пирами.
В OK Live нет необходимости поддерживать легаси, поэтому мы решили не использовать этот бутерброд расширений а сделать свой протокол с учётом опыта webrtc.
Но ещё более важным барьером было то что при реализации лайф стриминга нужно решать ещё такой компромис:
задержка <=> заполнение сети
WebRTC настроен под то чтобы уменьшить задержку любой ценой в то время как для OK Live допустим буферинг 1-2 секунды в условиях плохой сети. OKMP позволяет задавать максимальную желаемую задержку, чтобы позволяет добиться оптимальных параметров для текущего сценария/состояния сети.
Для иллюстрации: на некоторых андроид устройствах RTT на wifi плавает от 10 до 1500 мс во время стриминга, при этом процент потерь низкий. WebRTC в таком сценарии понижает качество до самого дна и проталкивает 50-100 kbps, тогда как OK Live выдаёт 1100 kbps.
Вы правы, с шифрованием нужно быть осторожным чтобы не наделать уязвимостей.
В случае OKMP считается хеш от данных, в том числе тех заголовков которые не шифруются. Сам хеш затем шифруется.
Для защиты от «пингвина» используется CTR и Initialization Vector. IV уникален для каждого пакета.
Более подробную статью с техническими деталями мы писать скорее всего не соберемся, так как это большой объем работы и для большинства читателей будет неинтересно. А вот если есть более конкретные вопросы — с удовольствием ответим.
Да, у разных кодеков свои сильные и слабые стороны. К примеру для кейса низкого битрейта и разрешения (плохая сеть) аппаратное ускорение уже не так актуально, потому что это более дешёвый кейс с точки зрения нагрузки на устройство. Можно кодировать более эффективным кодеком на CPU чтобы дать получше картинку юзеру. В платформе звонков в ВК мы изначально закладывали возможность переключать кодек на ходу, что даёт нам возможность включать оптимальный кодек по ситуации.
Это хороший вопрос на который не очень простой ответ. Если кратко: накладные расходы связанные с дополнительной фрагментацией из-за добавления ещё одного кодека превышают профит от внедрения H.265.
Чуть подробнее: представим сценарий в котором в одном звонке часть участников зашли с веб браузеров, часть с iOS. Если iOS отправляет только VP9/H.264 видео - его можно прозрачно пробрасывать в браузер и браузер его декодирует. Если же iOS отправляет H.265 - придётся для браузеров включать транскодирование на сервере, что неизбежно приведёт к понижению качества и большой нагрузке на сервера. С другой стороны есть VP9, который уже давным-давно живёт в Android и Chrome/Chromium, с недавнего времени нативно поддерживается и в iOS и в Safari. Поэтому VP9 для нас лучше отрабатывает кейс "смешанного" звонка.
По эффективности сжатия VP9 и H.265 близки к друг другу. Поэтому если внедрять новый кодек то скорее имеет смысл смотреть в сторону AV1 который даст получше эффективность сжатия и уже доступен в Chrome.
Да, упор на статический контент и читаемость текста. Динамический действительно упадёт в низкий фпс при нехватке сети (может быть 1 фрейм в несколько секунд). Для динамического контента вероятно сделаем в будущем автоопределение/рубильник для пользователя чтобы переключать кодек в другой режим.
Что касается MediaCodec - он действительно слишком непредсказуем в дикой природе чтобы получить надёжный результат по чёткости. Поэтому для кейса демонстрации экрана используем VP9 енкодер на CPU. Так как фреймрейт для этого случая относительно низкий - ресурсов устройства хватает.
Аудио/видео процесинг на c++ на всех платформах, остальное (юи, бизнес логика) - по разному на разных платформах
WebRTC — технология основанная на открытых стандартах которым >20 лет. RFC для RTP был опубликован в 1996, SDP в 1998. Для современных приложений конечно «базовые» варианты протоколов не годятся поэтому было добавлено много расширений, какие-то обязательные, другие опциональные. Со списком расширений можно ознакомиться здесь tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26.
В результате наслоений расширений получился протокол, который не совместим со старыми приложениями но при этом тянет много legacy.
Вот пример эволюции webrtc:
RFC 6464: добавлен заголовок в аудио пакеты который указывает уровень звука
RFC 6904: оказалось что этот заголовок передавать в открытом виде несекьюрно, добавили расширение для шифрования предыдущего расширения.
Клиентский код теперь должен поддерживать все возможные комбинации этих расширений, чтобы правильно работать и со старыми и с новыми пирами.
В OK Live нет необходимости поддерживать легаси, поэтому мы решили не использовать этот бутерброд расширений а сделать свой протокол с учётом опыта webrtc.
Но ещё более важным барьером было то что при реализации лайф стриминга нужно решать ещё такой компромис:
задержка <=> заполнение сети
WebRTC настроен под то чтобы уменьшить задержку любой ценой в то время как для OK Live допустим буферинг 1-2 секунды в условиях плохой сети. OKMP позволяет задавать максимальную желаемую задержку, чтобы позволяет добиться оптимальных параметров для текущего сценария/состояния сети.
Для иллюстрации: на некоторых андроид устройствах RTT на wifi плавает от 10 до 1500 мс во время стриминга, при этом процент потерь низкий. WebRTC в таком сценарии понижает качество до самого дна и проталкивает 50-100 kbps, тогда как OK Live выдаёт 1100 kbps.
В случае OKMP считается хеш от данных, в том числе тех заголовков которые не шифруются. Сам хеш затем шифруется.
Для защиты от «пингвина» используется CTR и Initialization Vector. IV уникален для каждого пакета.