В предыдущая статья Пролил немного света на вопрос доступных способов организации голосового общения в браузере.
На этот раз задача будет посложнее: мы хотим совершать видеозвонки из браузера удаленному абоненту, сидящему за софтфоном или устройством с поддержкой SIP. Это может быть необходимо, например, вот почему:
- Мы хотим создать систему онлайн-консультаций для интернет-магазинов, которая позволит посетителям сайта вести видеоразговор с консультантом, сидя перед знакомым мессенджером.
- Мы хотим дополнить систему телеконференций на базе Polycom возможностью подключения участников, у которых нет ничего, кроме браузера.
Технологии
Я не буду полностью повторять все расчеты из предыдущей статьи, а сразу перейду к выводам.Если мы хотим:
- Поддерживаются все настольные браузеры
- нет необходимости устанавливать дополнительное программное обеспечение
- система была устойчива к сетевым помехам
- задержки были минимальными
Светлое будущее не за горами: Google обещал Chrome скоро включит поддержку очень интересной технологии ВебRTC , о чем я обязательно напишу в отдельной статье.
Ну а пока используем то, что уже есть у пользователей.
Поддержка видео в Adobe Flash Player
Flash в настоящее время может воспроизводить потоки, сжатые несколькими кодеками:- H264
- Соренсон Спарк H263
- Он2ВП6
- Видео с флэш-экрана
Когда дело доходит до захвата и кодирования видео с камеры, дела обстоят гораздо хуже.
Поддержка кодировки H264 появилась только в недавно вышедшей версии FP11, а до этого единственной опцией был Sorenson Spark. К сожалению, подавляющее большинство пользователей еще не установили 11 версию, поэтому приходится учитывать тех, у кого только FP10. 
Мы также не должны забывать, с кем имеем дело.
Adobe удалось «сломать» воспроизведение некоторых типов потоков H264 в Flash Player версий 11.0 — 11.2. Проблема заключается в воспроизведении потоков, пакетированных в режиме пакетирования: 0, который используется большинством программных телефонов.
Подробности об ошибке можно найти в баг трекер компании.
В результате получается следующая картина.
Для успешного подключения к SIP-клиенту через H264 нам необходимо:
- выполнить перекодирование Sorenson -> H264 в одном направлении, если у пользователя версия FP ниже 11
- выполнить перекодирование H264 -> H264 (изменить пакетизацию) в одну сторону, если у пользователя FP 11 с вышеуказанным багом
- разрешить трафик, как и во всех остальных случаях.
Для производительности транскодирования крайне важно, чтобы сервер поддерживал MMX, SSE и подобные технологии в последних возможных версиях.
Видеокодеки могут использовать их, что значительно ускоряет работу.
Видео не является голосом
На первый взгляд может показаться, что единственная разница между передачей видео и голоса – это ширина используемого канала.Это, безусловно, так, но существует ряд существенных отличий.
Аудиопоток обычно разбивается на кадры по 10-20 мс, каждый из которых кодируется и декодируется отдельно от остальных.
Для видео это было бы слишком расточительно, поэтому для большинства кадров кодируется не само изображение, а его отличие от предыдущего кадра.
Для еще лучшего сжатия разница берется с предыдущим кадром, слегка «сдвинутым» для компенсации движения объектов.
В общем, о сжатии видео можно написать отдельный цикл статей, и я не буду здесь на этом останавливаться.
Важно другое.
Если мы потеряли один кадр аудиопотока, то мы можем просто маскировка , например, проиграв предыдущий кадр еще раз, и это мало кто заметит. А вот в видео такой трюк не пройдет, потому что последующие кадры необходимо накладывать на потерянный.
Здесь появляются артефакты, которые не исчезнут сами по себе, если вы не попросите удаленную сторону отправить независимо сжатый кадр (ключевой кадр).
В SIP это можно сделать двумя способами: на уровне сигнализации через SIP INFO и на уровне среды через RTCP. Далее нужно учитывать ограничение на MTU канала между участниками разговора, которое обычно составляет примерно 1500 байт (в случае NAT на фрагментацию IP рассчитывать нельзя).
Под это ограничение попадает любой аудиокадр, а вот видеокадр чаще всего — нет. Вот тут-то и возникает необходимость разделения кадров на части, что называется пакетированием, именно с этим и связан баг в некоторых версиях Flash Player.
Результат
В результате, если тщательно пройтись по всем граблям и разложить повсюду необходимое количество сена, можно получить вполне рабочий раствор.Нам удалось интегрировать поддержку видеозвонков из браузера в нашу облачную платформу.
РТККит , что, в свою очередь, позволяет за считанные часы интегрировать этот функционал в любой веб-сервис, сэкономив массу времени.
Все это вы можете протестировать без регистрации на нашем сайте.
Разрешение видео там ограничено 352х288. Мы протестировали софтфоны Джитси И ЛинФон , было бы интересно услышать отзывы о других клиентах, поддерживающих H264. Мы постараемся выдержать нагрузку от эффекта ступицы! Важное замечание: если вы звоните по RTCKit из браузера в браузер, и при этом у вас достаточно дружелюбный NAT, то вместо всего описанного используется технология RTMFP Peer-2-Peer. В будущих статьях мы затронем тему голосовых и видеоконференций, маршрутизации вызовов и взаимодействия с мобильными устройствами.
Следите за обновлениями.
Теги: #rtmfp #rtckit #webrtc #H.264 #видео #Разработка систем связи
-
Будьте Осторожны С Blackberry Native Sdk.
19 Oct, 24 -
Полностью Случайные Числа Без Повторений
19 Oct, 24
