Video

“Зачем изоморфный JavaScript?”: видео

Денис Речкунов, ведущий разработчик сервиса отзывов Flamp.ru, рассказал “Энтерре” и другим заинтересованным разработчикам Барнаула о преимуществах изоморфоного JavaScript и фреймворке Catberry.js. По его собственным словам, это на сегодняшний день самый полный доклад на тему. К тому же доклад живой, убедительный и интересный – смотрите видео!

Презентацию можно забрать вот тут.

Барнаульские гастроли DevDay 2ГИС

Мы отошли от собственных впечатлений от встречи с коллегами из 2ГИС и теперь готовы поделиться с читателями нашего блога.

Как известно, 1 марта с официальным визитом из Новосибирска в Барнаул был направлен десант разработчиков компании 2ГИС с целью проведения на алтайской земле конференции разработчиков DevDay.

 

Под экспериментальный первый выездной DevDay мы совершенно безвозмездно предоставили наш уютный офис и с позволения ребят из 2ГИС разбавили программу выступления своим мобильным хитом.

Кинохронику “концерта” можно посмотреть и послушать в конце этого поста, а пока постараемся передать атмосферу встречи.

Для зрителей были уготовлены стендап-выступления от Алексея Устинова (Enterra), Павла Сташевского и Станислава Сальникова (2ГИС).

IMG

Пока собирались гости и угощались медом с алтайским бальзамом, на разогреве уже был наш коллега Алексей Устинов с разработкой мобильных приложений под HTML5.

IMG_4814

Дебют Алексея в рамках DevDay удался и перед основным выступлением гостей внимание слушателей было полностью завоевано.

IMG_4821

IMG_4825

Следующее выступление вызвало наиболее больший отклик среди слушателей, что закономерно –  выступал руководитель группы автоматизации тестировании компании 2ГИС Павел Сташевский с одноименным хитом “Как управлять автоматизацией тестирования”.

IMG_4820

Рано или поздно, но случается так, что на проекте (или в компании) нужно внедрять автоматизацию тестирования для его убыстрения, получения страховочной сетки в виде тестов и по разным другим причинам.  Как сделать так, чтобы эта практика прижилась “практически безболезненно”, что нужно делать с тестами, как их писать и поддерживать, нужно ли и как писать тесты со старта проекта – об этом был доклад Павла. Полный сет выступления, как и было обещано, будет ниже.

IMG_4831

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

IMG_4846

IMG_4847

IMG_4845

Заключительным номером гастролей ребят из 2ГИС была новая вещь в исполнении Станислава Сальникова о любви к Knockout.JS на примере взаимоотношений с 2ГИС-Онлайн.

IMG_4856

IMG_4857

IMG_4862

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

И на десерт обещанное видео выступлений на первом барнаульском DevDay. Смотрите, делитесь впечатлениями и подскажите в комментариях, кого бы нам пригласить еще и какие темы поднять.

Разработка мобильных приложений на HTML5 (Алексей Устинов, Enterra):

Как управлять автоматизацией тестирования (Павел Сташевский, 2ГИС):

Knockout.js на примере 2ГИС Онлайн (Станислав Сальников, 2ГИС):

Реализация системы конвертирования видео

 

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

В данной статье мы расскажем о нашей точке зрения на внедрение подобных систем, приведем примеры функций системы, используемые для существующих приложений. Демо-версия нашей системы написана на языке Java (Spring + Hibernate), в ней использованы FFmpeg в качестве конвертера, JMS для взаимодействия с внешней системой и для внутренних коммуникаций.

Цели системы

Система конвертации видео предназначена для выполнения следующих задач:

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

В дополнение ко всему вышеперечисленному, система видео конвертации должна соответствовать следующим техническим требованиям:

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

Архитектура

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

Компоненты системы

Система состоит из диспетчера по конвертации видео и нескольких клиентов для конвертации видео, непосредственно проводящих конвертацию.

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

Также диспетчер предусматривает необходимые опции для управления и мониторинга системы.

Клиент конвертирует видео, используя FFmpeg, запуская его как отдельный процесс операционной системы и затем в случае,если конвертация прошла успешно, сохраняет ее результаты в хранилище ресурсов.

Каждый клиент обладает уникальным именем, назначаемым системным администратором. Схема 1:

Краткое описание работы

Рабочие процессы системы могут быть представлены в виде следующей схемы:

  • Внешняя система генерирует событие, в котором бы содержатся все необходимые для конвертации данные. Событие обрабатывается сервером конвертации видео
  • Во время обработки события, сервер создает задачу конвертации видео, сохраняет ее в базу данных, затем, если присутствуют свободные клиенты, задача перенаправляется к одному из клиентов для ее выполнения. Если свободных клиентов в данный момент нет, то задача ставится в режим ожидания. Сервер вернется к этой задаче тогда, когда появится свободный клиент. Внутренний JMS используется для передачи задач.
  • Клиент получает задачу, определяет, где находится искомый ресурс. Он выбирает подходящее соединение с хранилищем и загружает ресурс.
  • Клиент посылает сообщение, сообщающее серверу о том, что началась конвертация видео, запускает FFmpeg как отдельный процесс и ожидает его окончания. Если FFmpeg не выключается после некоторого времени, то клиент сам завершает его и сообщает об ошибке серверу, путем посылки JMS сообщения. Сообщение об ошибке также формируется, если FFmpeg завершил свою работу с ошибкой.
  • Если FFmpeg завершает свою работу корректно и итоговый файл содержит необходимую информацию, считается, что конвертация прошла успешно. Клиент загружает результат в хранилище ресурсов и уведомляет сервер, посылая ему JMS сообщение.
  • Сервер перенаправляет информацию о начале и завершении конвертации видео в основную систему.

Процессы коммуникации

Как уже было сказано выше, вся коммуникация осуществляются через JMS. Диспетчер сообщается с внешней системой, используя JMS topic. Для внутренней коммуникации мы также используем JMS topic.

Для того, чтобы облегчить процесс введения системы в действие, мы используем объектные сообщения и вся информация посылается как объект (событие-объект) внутри сообщения.

Подробнее о процессах коммуникации:

  • При запуске сервер посылает сообщения всем клиентам для того, чтобы определить их номера и статусы. Также сервер просматривает имеющиеся задачи, чтобы найти неотправленные, и если подобные задачи присутствуют – направляет их к клиентам.
  • Через определенный период времени (его можно настроить) сервер снова посылает сообщение всем клиентам, чтобы определить их номера и статусы. Это может быть полезно, когда новый клиент был запущен или остановлен уже после получения последнего запроса. Клиенты, которые не отвечают продолжительное время, помечаются как не отвечающие (подобные клиенты не участвуют в конвертации до тех пор, пока сервер не получит от них отклика, если задача назначается такому клиенту, то она перенаправляется другому). Клиент также может дать информацию о том, что в настоящий момент занят (с указанием задачи, которой он сейчас занят) или свободен.
  • Такой подход, когда клиент сообщает серверу о своем текущем статусе позволяет нам добавлять и удалять клиентов, не прерывая процесс, обеспечивая дополнительную возможность масштабировать систему.
  • Клиенты довольно пассивны в процессе коммуникации. Они только посылают сообщение в начале и завершении конвертации, и сообщение о своем статусе (свободен/занят).
  • Балансировка нагрузки в системе довольно проста. Поскольку мы используем FFmpeg для конвертации, мы совсем не можем повлиять на процесс конвертации, поэтому мы только выбираем первого свободного клиента и назначаем ему задачу. Если свободных серверов нет, задача ожидает до тех пор, пока новый клиент не запустится (клиент будет добавлен в сервер автоматически) или пока один из существующих серверов освободится.

В системе видео конвертации присутствует ряд объектов для передачи данных, событий и интерфейсов для использования во внешней системе. Ниже представлен перечень этих объектов:

  • Video Conversion Info. Этот объект для передачи данных содержит информацию о конвертации, включающую порядковый номер исходных и конвертированных видео ресурсов, а также тип хранения для того, чтобы система конвертирования могла правильно выбрать соединение с хранилищем. Данный объект создается внешней системой. Он распределяет все ресурсы и посылает их диспетчеру.
  • Перечень событий, включая Video Conversion Started Event (генерируется, когда клиент начинает конвертацию), Video Conversion Finished Event (запускается, когда клиент заканчивает конвертацию), Video Conversion Requested Event (запускается внешней системой, когда необходимо провести конвертацию) и Video Conversion Task Accepted Event (запускается диспетчером, когда задание получено и поставлено в очередь).
  • Также для конечных пользователей предлагается интерфейс Resource Storage Connector, необходимый для реализации различных вариантов хранения данных. В нашей системе мы используем Amazon S3.

Заключение

Описанная система конвертации видео использовалась в реальных проектах, включая архитектуру системы, использованные алгоритмы и подходы.

 

Бесплатный FLV-плеер

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

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

Таким образом, столкнувшись с необходимостью создания простого FLV-плеера с поддержкой прогрессивной загрузки видео для мультимедийного терминала, было решено создать плеер с поддержкой не только встроенного интерфейса, но и с наличием API для управления через Java-скрипт.

Естественно, разработчик должен иметь возможность скрывать стандартный интерфейс (т.к. скептицизм по отношению к интерфейсам по умолчанию распространяется также и на создаваемый нами интерфейс). С учётом всего вышеперечисленного, после нескольких дней программирования наш видеоплеер наконец появился на свет. Он был создан на Flash 8, AS 2.0.

Было принято решение полностью открыть исходный код и опубликовать список функций, которые на тот момент ещё не были реализованы, но планировались к реализации. В ближайших планах – портирование приложения на платформу 9 и ActionScript 3.0.

Ключевые функции:

  1. Возможность прогрессивной загрузки видео в формате FLV из локального файла или через потоковый сервер.
  2. Встроенный интерфейс (кнопки Вперёд/Назад, управление воспроизведением, прогрессбар и индикатор текущей позиции) с возможностью отключения.
  3. Внешний API для управления воспроизведением и приёма событий через Java-скрипт.
  4. Динамическое изменение размера с сохранением положения элементов управления.
  5. Гибкая система настроек.
  6. Открытый исходный код.

Запланировано:

  1. Позиционирование видео (с учётом прогрессивной загрузки).
  2. Масштабирование с учётом пропорций экрана./li>
  3. Плейлист.
  4. Скины на основе векторного Flash (библиотеки SWF).

Что можно делать с исходным кодом:

  1. Изменять встроенные элементы управления
  2. Создавать любые интересные и полезные функции (с сохранением нашего авторства на исходный код).

Чего нельзя делать с исходным кодом:

  1. Убирать ссылки на наше авторство.
  2. Распространять продукт без исходных кодов.

Скачать видеоплеер

Об авторе:

Михаил Пайсон, Магистр математики и информатики. Ведущий Flash-разработчик, эксперт в области Adobe Flash, Ruby on Rails и обработки изображений.

Вам понравилась статья, и Вы хотите заказать у нас разработку проекта? Свяжитесь с нами прямо сейчас!

Видео в Интернете: хранение, доступ, варианты развертывания системы

 

Постановка задачи

Основная задача заключается в создании системы для обеспечения работы с видеоподкастами (совокупность видео файлов, которые распространяются через Интернет, используя настройки RSS-потока для воспроизведения на переносимых медиа проигрывателях и персональных компьютерах), записанных пользователями и загруженных на сервер. Доступ к видео должен быть предоставлен по запросу пользователя или через подсоединение пользователя к широковещательному каналу в реальном времени. Ряд пользователей (привилегированных) должны иметь возможность создавать подкасты (например, загружать оцифрованное видео стандартных форматов (AVI, MPEG2), записанные на персональную видеокамеру). Все пользователи должны иметь возможность просматривать подкасты через веб-браузеры как часть веб-страницы.

Способы доступа к видео:

Загрузка

Чтобы воспроизвести видео на вашем компьютере, вам необходимо полностью его загрузить. Используется HTTP протокол.

Прогрессивная загрузка

Метод публикации видео, который позволяет начинать просмотр, когда небольшая часть видео файла загружена. Дальнейшая загрузка происходит одновременно с просмотром. Используя постепенную загрузку у вас нет возможности просматривать фрагмент, следующий за просматриваемым в данный момент. Используется HTTP протокол.

Потоковая передача данных

Данный метод публикации требует дополнительного ПО: необходим сервер потоковой передачи данных. Видео информация подается пользователю в форме потока, для просмотра необходим видео проигрыватель потоковой передачи данных. Несмотря на то, что сервер потоковой передачи данных имеет свой собственный формат для потоковых медиа, некоторые из них поддерживают формат MPEG-4 (Darwin Streaming Server/QuickTime Streaming Server, Helix Server, например).

Потоковая передача данных в режиме реального времени

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

Основные задачи сети потоковой передачи видео

Реализация потоковой передачи видео

На текущий момент существует четыре крупные компании, занимающиеся широковещательной потоковой передачей видео. Это такие компании, как: Apple, Real Networks, Adobe и Microsoft. Apple представлена коммерческим QuickTime Streaming Server и его аналогом с открытым исходным кодом – Darwin Streaming Server. Компания Adobe усовершенствовала Macromedia Flash Communication Server и выпустила его под брендом Flash Media Server. Кроме этого, они имеют FLV сервер Red5 с открытым исходным кодом. Real Networks поддерживает сервер Helix. Пользователи Microsoft Windows Server 2003 могут использовать бесплатный Microsoft Video Server, который может транслировать потоковое видео и аудио в специальном формате Microsoft: Windows Media Format.

Конвертация форматов

Не все видео форматы имеют возможность потоковой передачи. Поэтому необходимы специальные инструменты для конвертации видео файлов из формата пользователя в формат, подходящий для потоковой передачи данных. Существует несколько приложений, которые могут выполнить данную задачу весьма эффективно. Одно из них – это ffmpeg – приложение, которое может конвертировать видео файлы в различные форматы. У данного приложения есть еще одно несомненное преимущество – возможность запуска в режиме пакетной обработки для автоматической конвертации форматов. Основным недостатком приложения является некоторая сложность регулирования, дополнительных преобразований и установки библиотек. Данное приложение также может быть скомпилировано в форме статической или динамической библиотеки для дальнейшего использования в проектах C/C++. Также необходимо упомянуть Windows Media Encoder для систем Windows, т.к. данный продукт принадлежит Windows Media Series и позволяет конвертировать видео в несколько форматов. Существует возможность разрабатывать свои собственные компоненты на базе Microsoft Windows Media 9 Series благодаря возможностям совершенствования Windows Media SDK. Этот пакет программ для Windows 2003 Server абсолютно бесплатен.

Adobe Flash Media Encoder представляет собой другой инструмент для кодирования видео, позволяющий конвертировать файлы в формат FLV (Sorenson or кодеки on2). Он может быть запущен из командной строки или в режиме GUI.

Встраивание видео в веб-страницу

Встраивание видео реализуется с помощью объектов ActiveX (для IE) или плагинов. Для каждого из представленных серверов реализуется отдельный вариант встраивания видео в веб-страницу. Потоковая передача видео с помощью серверов Apple (Darwin/QuickTime Streaming Server), также как и посредством сервера Helix совместимого с Apple формата (RealNetworks) транслируется с помощью встроенной стандартной панели инструментов, которую можно скрыть, и своего рода API, чтобы контролировать воспроизведение и текущее состояние видео. Широчайший спектр различных проигрывателей используется с FLV (Flash Media Server, Red5) из-за легкости разработки Flash приложений для взаимодействия FMS/Red5 и широких возможностей среды разработки Flash (фактически, существует только один Flash FLV проигрыватель, но он «завернут» в различные Flash приложения). Но высокая цена сервера Flash Media является безусловным недостатком (особенно для большого количества соединений). Одной из особенностей формата FLV (Flash Live Video) является возможность постепенной загрузки видео с сервера без использования FMS. В таком случае видео не будет передаваться поточно. Воспроизведение потоковой видео трансляции с сервера Windows Media возможно посредством плагинов ActiveX или Windows Media Player. Другие платформы используют сторонние проигрыватели, такие как, например, Starbak Embedded Streaming для Линукса. Также требуется встроенный компонент VBrick для проигрывания потокового видео в форматах Windows Media. Необходимо также встроить RealPlayer или схожий сторонний проигрыватель в страницу, чтобы проигрывать видео в формате RealVideo с сервера Helix.

Варианты развертывания системы

Система потокового видео, базирующаяся на Apple Darwin Server

Сервер: бесплатный сервер Darwin 5.5.1 с открытым исходным кодом для потокового вещания.

Проигрыватель:QuickTime 6 встроенный в веб-страницу.

Конвертер видео: ffmpeg (реализация для Windows или Linux).

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно).

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для перекодировки подкастов в формат MP4 или HINTED MOV для потоковой передачи данных. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализуется в потоковом режиме внутри определенной веб-страницы.

Преимущества:бесплатный сервер потокового вещания, готовый использовать встроенный в веб-страницу проигрыватель.

Недостатки: отсутствие возможности изменять дизайн проигрывателя, необходимость ресурсоемкого конвертирования формата файлов подкаста после добавления.

Система потокового видео, базирующаяся на Flash Media Server 2

Сервер:Flash Media Server 2.

Проигрыватель: Flash-приложение, поддерживающее воспроизведение содержимого файла.

Конвертер видео: ffmpeg (реализация для Windows или Linux) или Flash Media Encoder.

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно).

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для декодирования подкастов в формат FLV для потоковой передачи данных. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализуется в потоковом режиме внутри определенной веб-страницы, содержащей Flash-приложение.

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

Недостатки: цена Flash Media Server.

Система потокового видео, базирующаяся на Red5 Server

Сервер: сервер Red5 с открытым исходным кодом.
Проигрыватель: Flash-приложение, поддерживающее воспроизведение содержимого файлов.

Конвертер видео: ffmpeg (реализация для Windows or Linux) или Flash Media Encoder.

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно).

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для перекодирования подкастов в формат FLV для потоковой передачи данных. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализуется в потоковом режиме внутри определенной веб-страницы, содержащей Flash-приложение.

Преимущества: бесплатный FLV сервер, возможность использования собственного проигрывателя пользователя, гибкость разработки приложения благодаря Flash-технологии.

Недостатки: небольшое количество одновременных подключений (не более 15 для стабильности работы), требуется Java SDK, возможные изменения спецификации RTMP протокола компанией Adobe.

Система прогрессивной загрузки, базирующаяся на FLV

Сервер: Web сервер. Потоковый сервер не требуется.

Проигрыватель: Flash-приложение, поддерживающее проигрывание файлов.

Конвертер видео: ffmpeg (реализация для Windows или Linux) или Flash Media Encoder.

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно).

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для перекодирования подкастов в формат FLV для вещания. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализован в режиме постепенной загрузки внутри определенной веб-страницы, содержащей Flash-приложение.

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

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

Система потокового видео, базирующаяся на Windows Media 9 Series

Сервер: Windows Media Server для потоковой передачи данных.

Проигрыватель: Проигрыватель Windows Media Player 9/10, встроенный в веб-страницу, или в сторонний проигрыватель.

Конвертер видео: Microsoft Video Encoder.

Дополнительные требования: выделенный сервер для конвертирования видео форматов (желательно). Операционная система – Windows 2003 Server.

Добавление подкастов: пользователь загружает подкасты на сервер. Формируется очередь для декодирования подкастов в формат WMV для потокового широковещания. Пользователи могут просматривать подкасты спустя некоторое время.

Просмотр подкастов: реализован в потоковом режиме внутри определенной веб-страницы.

Преимущества: бесплатный потоковый сервер, если установлена операционная система Windows 2003 Server, готовая к использованию встроенного проигрывателя в веб-страницу.

Недостатки: отсутствие возможности изменять дизайн проигрывателя, необходимость ресурсоемкого конвертирования формата файлов подкаста после добавления, необходимость установки Microsoft Windows 2003 Server, возможные проблемы с просмотром видео на персональном компьютере с другой операционной системой.

Вам понравилась статья, и вы бы хотели отдать нам свой проект на разработку? Вы можете связаться с нами здесь!