Фреймворк Jitsi

Глава 10 из книги "Архитектура приложений с открытым исходным кодом", том 1.

Оригинал: "Jitsi", глава 10 из 1 тома книги "The Architecture of Open Source Applications"
Автор: Emil Ivov
Перевод: Н.Ромоданов

10.7. Усвоенные уроки

Когда мы начали работу над SIP Communicator, одним из наиболее распространенных критических замечаний или вопросом, который мы слышали, был следующий: «Почему вы используете язык Java? Разве вы не знаете, что он медленный? Вы никогда не сможете получить достойное качество аудио/видео звонков!». Миф «язык Java - медленный» даже был повторен потенциальными пользователями в качестве причины того, почему они придерживаются Skype вместо Jitsi. Но первый урок, который мы усвоили из нашей работы над проектом, состоит в том, что с эффективностью на языке Java проблем не больше, чем их бы было с языком C++ или другими нативными альтернативами.

Мы не будем делать вид, что решение о выборе языка Java стало результатом тщательного анализа всех возможных вариантов. Нам просто нужен был простой способ создать нечто, что бы работало на Windows, и Linux, а Java и Java Media Framework, как нам показалось, предлагают один из относительно простых способов добиться этого.

На протяжении многих лет у нас было мало причин, чтобы сожалеть об этом решении. Совсем наоборот: даже хотя язык Java не сделал проект полностью прозрачным, он помогает обеспечивать переносимость и 90% кода в Communicator SIP не меняется от одной операционной системы к другой. Сюда относятся все реализации стека протоколов (например, SIP, XMPP, RTP, и т.д.), т. к. они достаточно сложны. Возможность не беспокоиться о специфике OS в таких частях кода оказывается весьма полезной.

Кроме того, популярность языка Java, оказалось очень важной при создании нашего сообщества. Авторы, как таковые, являются дефицитным ресурсом. Людям должно нравиться приложение, они должны найти время и мотивацию - все это трудно объединить вместе. Им не требуется учить новый язык и, таким образом, это - преимущество.

В отличие от большинства ожиданий, недостаточная скорость работы при использовании языка Java редко была причиной перехода на нативный код. Большинство решений, связанных с использованием нативного кода, обуславливались интеграцией с ОС и тем, насколько язык Java давал нам возможность получать доступ к утилитам конкретной OS. Ниже мы обсудим три наиболее важных области, в которых язык Java себя не оправдал.

10.7.1. Звук Java Sound и звук PortAudio

Java Sound является интерфейсом API, используемым в Java по умолчанию для записи и воспроизведения звука. Он является частью среды времени выполнения и, следовательно, работает на всех платформах, где есть виртуальная машина Java. В первые годы Jitsi, когда это был проект SIP Communicator, использовался исключительно интерфейс JavaSound и из-за это у нас было немало неудобств.

Прежде всего, интерфейс API не предоставил нам возможность выбирать, какие аудио устройства используются. Это большая проблема. Кода люди используют свои компьютеры для аудио и видео звонков, они для того, чтобы получить максимально возможное качество, часто применяют улучшенные гарнитуры USB или другие звуковые устройства. Когда в компьютере есть несколько таких устройств, JavaSound выбирает среди всех аудио устройств то, которое в операционной системе рассматривается как используемое по умолчанию, и это во многих случаях не всегда хорошо. Многие пользователи хотели бы сохранить настройки всех других приложений, работающих по умолчанию с их звуковой картой, так, чтобы, например, они могли продолжать прослушивать музыку через колонки. Еще более важно то, что во многих случаях для SIP Communicator лучше передавать аудио уведомление о вызове на одно устройство, а фактический звук вызова на другое, что позволяет пользователю, даже если он не находиться перед компьютером, слышать сигнал вызова через колонки, а затем, когда он примет вызов, перейти к использованию гарнитуры.

Все это невозможно с Java Sound. Более того, в реализации для Linux используется OSS, что сегодня не рекомендуется использовать на большинстве дистрибутивов Linux.

Мы решили использовать альтернативную аудиосистему. Мы не хотели идти на компромисс с нашей мультиплатформенным решением и, если возможно, мы не хотели возиться со всем этим самостоятельно. Это та ситуация, когда чрезвычайно удобной оказалась система PortAudio [2].

Если Java самостоятельно не позволяет что-то делать, то следующим лучшим решением является использование кросс-платформенных проектов с открытым исходным кодом. Переход на проект PortAudio позволил нам реализовать поддержку лучшей настройки аудиопотоков так, как мы это описывали выше. Он также работает на Windows, Linux, Mac OS X, FreeBSD и других системах, для которых у нас не было времени создавать пакеты.

10.7.2. Захват и рендеринг видео

Видео для нас так же важно, как звук. Однако, это оказалось не так для создателей Java, поэтому по умолчанию в JRE нет интерфеса API, который позволяет выполнять захват или рендеринг видео. Некоторое время казалось, что таким API суждено было стать фреймворку Java Media Framework, до тех пор, пока фирма Sun не остановила его поддержку.

Естественно, мы начали искать альтернативу видео в стиле PortAudio, но на этот раз нам не так повезло. Сначала мы решили перейти на фреймворк LTI-CIVIL Кена Ларсона (Ken Larson) [3]. Это замечательный проект, и мы некоторое время его использовали [4]. Однако он оказался не слишком оптимальным при использовании в контексте коммуникаций реального времени.

Таким образом, мы пришли к выводу, что единственный способ обеспечить безупречную видеосвязь для Jitsi будет создание нативных грабберов и модулей рендеринга, которые мы должны были сделать самостоятельно. Это было не простое решение, поскольку оно подразумевало существенное увеличение сложности проекта и значительную нагрузку его поддержки, но у нас просто не было выбора: мы действительно хотели иметь качественную видеосвязь. И сейчас мы это делаем!

Наши нативные грабберы и модули рендеринга напрямую используют Video4Linux 2, QTKit и DirectShow/Direct3D на Linux, Mac OS X и Windows, соответственно.

10.7.3. Кодирование и декодирование видео

SIP Communicator, и, следовательно, Jitsi, с первых дней поддерживает видео-звонки. Это потому, что Java Media Framework позволял кодировать видео с использованием кодека H.263 и формата 176х144 (CIF). Те из вас, кто знает, как выглядит H.263 CIF, вероятно, сразу улыбнулись; мало кто из нас будет сегодня пользоваться приложением видео-чата в случае, если это все, что это приложение может предложить.

Для того чтобы обеспечить достойное качество, нам нужно было использовать другие библиотеки, например, FFmpeg. Кодирование видео, на самом деле, является одним из немногих мест, где производительности языка Java оказывается действительно недостаточно. То же самое касается других языков, о чем свидетельствует тот факт, что для того, чтобы обрабатывать видео наиболее эффективным способом, разработчики FFmpeg на самом деле в нескольких местах использовали Assembler.

10.7.4. Прочее

Есть много других мест, где мы решили, что для получения лучших результатов нам нужно перейти на нативный код. Одним из таких примеров являются уведомления системного трея Systray с Growl - на Mac OS X и с libnotify — на Linux. К числу других примеров относятся базы данных запросов контактов из Microsoft Outlook и Apple Address Book, определяющие IP-адрес источника в зависимости от назначения, в которых использовались существующие реализации кодеков для Speex и G.722, позволяющие захватывать скриншоты рабочего стола и транслирующие символы char в коды нажатия клавиш.

Важно то, что всякий раз, когда нам нужно было выбрать нативное решение, мы могли это сделать и мы это делали. Это подводит нас к следующему: С тех пор, как мы запустили проект Jitsi, мы исправили, добавили, или даже полностью переписывали различные его части, поскольку мы хотели, чтобы они выглядели, воспринимались и работали лучше. Тем не менее, мы никогда не пожалели ни о чем, что не было первоначально написано правильно. Когда мы сомневались, мы просто выбрали один из имеющихся вариантов и использовали его. Мы могли бы подождать, пока мы не узнали лучше, что мы делаем, но если бы мы так поступали, то сегодня не было никакого проекта Jitsi.

10.8. Благодарности

Огромное спасибо Яне Стамчевой (Yana Stamcheva) за создание всех схем для этой главы.

Примечания

Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.

---

К началу статьи.

---

---