Готовясь к событию, описанному в предыдущем сообщении, я подготовил несколько вариантов для захвата и передачи изображения при помощи ffmpeg, пригодных как для организации записи, так и для трансляции в сети. Думаю, будет полезно привести их, дабы потом не вспоминать снова.
Подробнее →

На днях попробовали с друзьями протестировать видео-конференции от Google. На редкость понравилось и поразило, а практически не ощущаемая задержка (трое были из Тулы, еще один участник — в Лондоне) вызвала глубокое инженерное уважение и преклонение. К тому же адаптивная подстройка чувствительности микрофона, качества видео, ну и смена основного участника беседы (примерно тоже я предлагал около года назад) — в общем, хорошо сделанное решение. Изначально я предположил, что малая задержка достигается из-за сети промежуточных ретрансляторов, которые выбираются исходя из минимальных задержек до каждого из участников разговоров, но на практике оказалось, что это все же P2P а-ля Skype. Кроме того, в сети встречаются мнения инженеров Гугла о том, что все это медленно и верно движется в направлении WebRTC, что, несомненно, полезно испробовать.

В процессе создания автоматизированного перекодировщика пришлось наступить в одну очень неприятную проблему. Беда в том, что Adobe Flash Player очень ревностно относится к наличию дополнительной мета-информации в mp4-файле. А именно — при наличии в ролике разбиения на главы проигрывание не начинается до тех пор, пока ролик не загрузится целиком в случае использования nginx + mod_h264_streaming, или начинает проигрывание, но показывает неверную продолжительность ролика и умирает при попытке проигрывания с произвольного места в случае erlyvideo.

Активные попытки выяснить как удалить из mp4 информацию о главах завершились неуспешно — было найдено куча решений «как добавить» а вот с удалением было сложно. В результате родилось наколенно-костыльное решение: сначала перепаковать видео в MKV-контейнер с удалением оглавления, а затем перепаковать обратно в MP4. Процесс занимает не более 15 секунд, что вполне терпимо.

В результате, все видео, обработанное нижеприведенным сценарием, спокойно проигрывается в Flash Player:

В процессе поиска этого бага были проведены следующие мероприятия:

• вдоль и поперек излазан код плеера
• проверены и отработаны различные настройки перекодирования
• менялся контейнер с ОС (с 64-хбитной на 32-х)
• был обновлен, проверен и перепроверен mod_h264_streaming
• были перепроверены настройки nginx
• был установлен и опробован erlyvideo
• с дебаггером внутрь Flash Plugin не лезли, но мысль была

Поиск бага длился почти рабочую неделю в фоновом режиме (2-3 часа в сутки).

Прежде чем начать пересказывать рецепты, определимся с терминами. Под защитой в данном контексте понимается не защита видео, предоставляемого пользователю, от сохранения и копирования. Это отдельная интересная в инженерном плане задача, включающая ассиметричную криптографию, методики препядствования декомпиляции и сохранения целостонсти, организация доверенной среды на уровне программно-аппаратных решений и ядра ОС, поистине безгранична, но так же уязвима, как и все остальные методы (на устройстве пользователя она в любом случае должна предстать в полностью декодированном виде во время воспроизведения). Поэтому цель такой защиты состоит в том, чтобы сделать легальное получение информации было более выгодным в экономическом и эмоциональном плане, нежели преодоление механизмов защиты.

В нашем случае речь пойдет о других аспектах. Допустим, у нас есть ресурс с видео-контентом, доступ к которому осуществляется по подписке. Соответственно, при проектировании такого ресурса с точки зрения безопасности есть два основных вопроса:

• как избежать публикации видео на других ресурсах с задействованием ресурсов нашего сервера, что будет создавать дополнительную нагрузку на сервер, но служить чужим коммерческим интересам (частным случаем данной задачи является запрещение на просмотр всем, кто не является пользователем ресурса)
• как избежать массового копирования видео с ресурса с целью создания клонов

Иными словами, препядствование всяческим инициативным гражданам получить выгоду с контента.
Подробнее →

Каким бы хорошим не был Wowza Media Server, но у него есть одно очень неприятное (но вполне справедливое) неудобство — версия для разработчика ограничена 10 одновременными подключениями, а финансирование некоторых проектов не позволяет приобретать полноценную версию. Поэтому с самого момента работы с RTMP мною рассматривались различные варианты использования открытых разработок. Увы, более-менее рабочим решением до недавнего момента был Red5 — медиа-сервер, сделанный на платформе J2EE, который оставлял впечатление тяжелого и неповоротливого монстра, а остальное и вовсе не выдерживало никакой критики.
Подробнее →