Мы использовали от самых маленьких ($5) до весьма приличных. Я уточню подробности у инженеров в понедельник. Самой критичной проблемой было то, что в DO последнее время есть проблемы со связностью.
На данный момент платформа работает в качестве хранилища пользовательского видео контента в проекте Together и в качестве хранилища фотографий в анонимном фото чате PhotoSuerte.
Только что в блог закинул статью про реализацию поддержки аудио дорожек. Реализация не самая технически продвинутая, но зато простая и эффективная. Статья в нашем блоге
Microsoft сможет заявлять о многих часах браузинга. Но под браузингом будет пониматься посещение сайтов с текстами и картинками, без особой анимации. По опыту портирования Flash приложений на HTML5 можно сказать, что постоянно приходится оптимизировать приложения под конкретные устройства, вечно что-то тормозит и лагает. Теперь к HTML5 анимации под iOS, добавится оптимизация HTML5 под Windows. На Android'е Flash постепенно разгоняется.
Она решена в последней версии OSMF — 1.6 (т.е. на стороне видео плеера), но требует использования HTTP DS на уровне сервера. Позволяет в плеере переключаться между разными аудио дорожками и не нужно хранить видео под каждую дорожку. Думаю дня через три в нашем блоге будет подробный отчет как это сделать с примерами кода видео плеера.
Я в последнее время стараюсь использовать Strobe Media Playback. В него Adobe добавляет самые последние фичи и относительно оперативно баги правит.
Хотя конечно JW и другие тоже очень даже хороши и действительно поддерживают всякие варианты переключения. Началось это все после того, как Adobe в AS3 опубликовала возможность добавлять байты в мультимедиа поток (NetStream). Теперь видео можно хоть по сокету получать, хоть по P2P сети. Flash Player все отобразит.
По идее ничего не мешает. Просто в стандартных Framework'ах для Flash Player'а не реализована работа с динамическими потоками при передаче через HTTP PD. OSMF — который продвигается Adobe как основное средство для создания видео плееров, да и Strobe Media Playback — видео плеер Adobe на базе OSMF, поддерживают переключение качества лишь при HTTP DS.
Хотя никто не мешает сделать свой фреймворк и реализовать работу с переключением качества и при HTTP PD передаче.
А это как раз и сделано для HTTP Dynamic Streaming. Где то даже на хабре была статья на эту тему. Прежде всего это дает возможность динамически переключать качество при переходе на следующий кусок. Ну и кусками управлять в кешах легко. В кеше оседают самые популярные куски только.
Просто NGINX отдает файл лишь после полной загрузки / считывания. Могу ошибаться, но насколько я помню около года назад было именно так.
Apache модуль решает эту проблему и отдает кусок файла без его полного считывания.
Но это даже не самая главная причина. HTTP DS формат видео опубликованный Adobe — F4V — разбирается лишь их модулем для Apache. Поэтому все его и используют.
PS
Куски делают по несколько мегабайт. Если у Вас 100 Тб видео, то для эффективного кеширования и доставки не с системы хранения данных, а из кешей, Вам нужно много NGINX серверов с суммарным объемом жестких дисков 100 Тб.
Они отлично кешируются в NGINX. Творение Сысоева очень хорошо кеширует все, что через него проходит :-) По сути это HTTP payload размеров в пару мегабайт.
Такая связка тянет десятки гигабит (не на одном сервере конечно). Adobe опубликовала бесплатный HTTP Dynamic Streaming модуль лишь для Apache. Такую архитектуру используют очень многие проекты. Например, BBC в своем блоге описывает процесс тестирования HD трансляций на основе HTTP DS доставки. Они используют Apache.
Кстати, Apache вовсе не обязательно высовывать наружу. Он может висеть на внутреннем порту или вообще во внутренней подсети.
На мой взгляд с выходом HTTP Dynamic Streaming больше года назад для Flash проблема подбора медиа сервера отпала. Можно собрать схему для отдачи видео контента при помощи Apache (получение сегментов из файла) и NGINX (кеширующий proxy) — в итоге получается надежное и бесплатное решение с неограниченными возможностями масштабирования. Apache вытягивает чанки, а NGINX их очень быстро раздает из своих кешей.
Вот если бы Adobe для NGINX написала такой модуль :-) Можно было бы обойтись одним веб сервером.
Сегодня весь день тестировал разные возможности по воспроизведению видео в Android девайсах (HTC Flyer, Motorola Xoom). Делал VideoView, MediaPlayer, WebView + Flash, чистый Flash. Все можно заставить работать на девайсе, но везде много граблей. Некоторые подробности здесь. Больше всего понравилось воспроизвести то, что уже есть на сайте Flash видео плеером, хотя эстетического удовольствия больше от разработки MediaPlayer плеера.
Вот в нашем блоге.
На данный момент платформа работает в качестве хранилища пользовательского видео контента в проекте Together и в качестве хранилища фотографий в анонимном фото чате PhotoSuerte.
Всегда будем рады поделиться нашим опытом :-)
Она решена в последней версии OSMF — 1.6 (т.е. на стороне видео плеера), но требует использования HTTP DS на уровне сервера. Позволяет в плеере переключаться между разными аудио дорожками и не нужно хранить видео под каждую дорожку. Думаю дня через три в нашем блоге будет подробный отчет как это сделать с примерами кода видео плеера.
Если нужно решить срочно, то поищите на тему late binding audio.
sourceforge.net/apps/mediawiki/osmf.adobe/index.php?title=Late-Binding_Audio
Хотя конечно JW и другие тоже очень даже хороши и действительно поддерживают всякие варианты переключения. Началось это все после того, как Adobe в AS3 опубликовала возможность добавлять байты в мультимедиа поток (NetStream). Теперь видео можно хоть по сокету получать, хоть по P2P сети. Flash Player все отобразит.
Хотя никто не мешает сделать свой фреймворк и реализовать работу с переключением качества и при HTTP PD передаче.
Тут есть подробное описание как работает в NGINX эта схема: goo.gl/01oH9
Apache модуль решает эту проблему и отдает кусок файла без его полного считывания.
Но это даже не самая главная причина. HTTP DS формат видео опубликованный Adobe — F4V — разбирается лишь их модулем для Apache. Поэтому все его и используют.
PS
Куски делают по несколько мегабайт. Если у Вас 100 Тб видео, то для эффективного кеширования и доставки не с системы хранения данных, а из кешей, Вам нужно много NGINX серверов с суммарным объемом жестких дисков 100 Тб.
Кстати, Apache вовсе не обязательно высовывать наружу. Он может висеть на внутреннем порту или вообще во внутренней подсети.
Вот если бы Adobe для NGINX написала такой модуль :-) Можно было бы обойтись одним веб сервером.