В ffmpeg не самой старой версии обнаружилась неприятная проблема — в случае попытки получить из звуковой дорожки в шесть каналов (5+1) стереозвук программа отказывалась работать с ошибкой Can not resample 6 channels @ 48000 Hz to 2 channels @ 44100 Hz. Беглый поиск показал, что ошибка достаточно распространенная, но в списке рассылки была только одна рекомендация — обновить ffmpeg. Т.н.м. и самая последняя версия из репозитария благополучно отказывалась работать, плюс еще появились дополнительные ошибки (например, попробованная ревизия «разучилась» читать параметр -ab для кодека aac, в результате в структуре шло значение по умолчанию, которое вызывала ошибку, поскольку было слишком большим).

Дальнейшее расследование показало интересную вещь. Например, было найдено решение с промежуточным перекодированием звука в ac3, что неудобно и просто нерационально, хоть и позволяло решить указанную задачу. Окончательный вариант был найден в виде простого патча, найденного на странице блога muzso.hu (оттуда же и можно скачать этот патч, он называется 6to2channel-resample.patch), который якобы эту проблему решает, что я сейчас и проверяю боевым тестированием.

Примечательно, что в исправляемом файле libavcodec/resample.c присутствует функция ac3_5p1_mux, которая, по всей видимости, и дала возможность для первого ранее упомянутого трюка. Вопрос, почему 6to2channel-resample.patch еще не в мейнстриме, остается загадкой.

На днях попробовали с друзьями протестировать видео-конференции от 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 часа в сутки).

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

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

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

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

В процессе разработки видео-чата ViCo столкнулся с одной очень интересной проблемой. Было необходимо реализовать элемент на Flash/Flex, захватывающий камеру пользователя и отсылающий поток на RTMP-сервер erlyvideo.

Подробнее »»