Построение систем доставки видео на основе HTTP Dynamic Streaming от Adobe и OpenSource

    В рамках проекта для одного из наших заказчиков в очередной раз встала задача построить систему конвертации/ хранения/ доставки видео в интернет. Типичная такая задача создания своего маленького (или не очень маленького) “Тьюба” только с профессиональным, а не UGC-контентом.

    С момента создания первых “Тьюбов” технологии видео в интернете прошли некоторый путь развития, позволяют сейчас делать намного больше, да и требования к современному видео-сайту стали несколько иными.

    Наиболее интересными трендами последнего времени, на наш взгляд, являются:
    • возможность смотреть один видео-сайт с разных устройств,
    • технология адаптивного HTTP стриминга


    В результате появления и бурного распространения в последнее время мобильных устройств, реально удобных для потребления интернета с них, а также развития беспроводных технологий передачи данных, становится ясным, что нужно иметь вторую версию сайта, оптимизированную для мобильных iOS, Android и др. платформ. Третья версия сайта, оптимизированная под “10-ти футовый интерфейс”, скоро понадобится, когда станет популярной какая-либо технология WebTV, например GoogleTV.

    Все это вписывается в т.н. концепцию “трех экранов”, с которого люди будут потреблять видео (и вообще интернет-контент) в ближайшем будущем — мобильник(планшет) в дороге, PC в офисе на работе, TV в гостиной дома.

    Про технологию адаптивного HTTP стриминга хотелось бы поговорить поподробнее, что и является предметом данной статьи.

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

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

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

    На практике это означает, что мы можем значительно улучшить восприятие сервиса не только пользователям с нестабильным/слабым каналом, где-нибудь глубоко в регионах, но и пользователям wifi-сетей, пользователям, у которых одно соединение является общим для нескольких пользователей в домохозяйстве и т.д. Для пользователей с выделенным качественным каналом данная технология просто автоматически определит скорость его канала и будет отдавать видео в подходящем битрейте — т.е. конечному пользователю больше не нужно знать о том, что такое 360p, 240p или SD, HD и т.д. — все происходит автоматически.

    Расплачиваться за все эти преимущества приходится 3-мя вещами —
    • усложнением процедуры стриминга,
    • дополнительными затратами на кодирование,
    • дополнительными затратами на хранение.

    Первая причина на данный момент уже не должна приниматься во внимание, поскольку уже есть готовые opensource — кирпичики для строительства таких систем, о чем я дальше и расскажу.

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

    На данный момент существует, как минимум, три известные мне реализации технологии адаптивного мультибитрейтного стриминга:
    • Apple HTTP Adaptive Streaming for iPhone/iPad,
    • Microsoft Smooth Streaming for Silverlight,
    • Adobe Dynamic Streaming for Flash.

    Для практики разработки видео-сайтов наиболее важным, конечно, является реализация от Adobe, поскольку Apple HTTP Adaptive Streaming работает только для iOS устройств и Safari под MacOS X (хотя мне на днях показали один STB, в котором данный протокол реализован), а Silverlight, скажем так, пока не получил такой популярности как Flash.

    Adobe реализовала Dynamic Streaming в рамках rtmp протокола уже довольно давно и только относительно недавно (с появлением flash 10.1) стало возможным использовать HTTP стриминг. Это очень важный шаг, поскольку раньше для использования динамического стриминга нужен был специализированный стриминговый сервер, теперь же бОльшая часть работы перенесена на клиент, а серверная поддержка упрощается вплоть до отдачи обычной HTTP статики.

    Фактически нам нужно закодировать ролик в нескольких битрейтах, а дальше, либо нарезать на фрагменты, например, секунд по 5 и положить под быстрый сервер отдачи статики (см. рисунок ниже), либо, если существует сервер или стриминг-модуль, который из mp4 файликов может вырезать нужные фрагменты на лету, тогда на storage-уровень ставим его, а запросы маршрутизируем через какой-либо эффективный кешер. Более того, данный кешер может быть у провайдера CDN услуги. Одним из основных достоинств технологии адаптивного HTTP стриминга и является простота использования внешних CDN и кешеров — можно не заботится о преднаполнении кеша — в случае “cache miss” запрос проксируется на origin-server, одновременно сохраняясь в кеше.



    Кеширование получается очень эффективным, поскольку в кеше прокси кусочками “оседает” востребованный контент. Причем эти кусочки относительно небольшие и можно придумывать различные стратегии управления кешем — когда “сохранять” кусочек, когда его удалять и т.д. Это дает большую свободу для разработки механизмов оптимизации разработчикам CDN сервисов. В свое время для первых версий системы доставки рутюба мы разрабатывали похожий механизм “кусочного” кеширования, позволивший долгое время проекту эффективно доставлять видео при минимуме оборудования.

    С точки зрения программирования для поддержки HTTP Dynamic Streaming ребята из Adobe сделали одну простую вещь — у объекта NetStream появился метод appendBytes. Формат входного массива — байтпоток в FLV-формате. Фактически это дает возможность проигрывать байтпоток, а вопросы его доставки — отдельная задача. Например, можно доставлять эти байты посредством HTTP — кусочков и получится HTTP стриминг.

    Системы от Apple и Microsoft реализуют систему доставки и проигрывания внутри своего “черного ящика”, а Adobe дает возможность программировать систему самостоятельно. Сделали они и открытую реализацию такой системы в рамках своего Open Source Media Framework. OSMF — это набор базовых классов, упрощающих написание видео-плейеров на ActionScript3, который, в том числе, включает реализацию поддержки HTTP динамического стриминга. Более того, спецификации данного протокола и подробности реализации Adobe старается раскрывать. Посмотреть можно тут и тут. Можете себе такое представить раньше, когда у Flash не было конкурентов и их будущее представлялось совершенно безоблачным?

    Итак, возвращаемся к постановке задачи — мы хотим сделать видеохостинг, десктоп-версия будет использовать flash и технологию HTTP adaptive streaming.

    Как собрать такую систему конвертации и доставки видео?

    Кодировать будем в mp4, кодеки — x264 и faac, инструменты — ffmpeg, mencoder. Коммерческий софт мы не очень любим, если есть бесплатные альтернативы.

    На данный момент мне известно о следующих реализациях данной технологии:
    • коммерческий софт. Коммерческие сервера от Adobe и Wowza имеют реализацию данной технологии, в качестве основы для плейера можно взять OSMF. Вариант, наверное, хороший, но дорогой.
    • есть свободная, но закрытая реализация от самой Adobe. Представляет собой перепаковщик исходных файлов в некий f4f-формат и модуль для apache, работающий с такими перепакованными файлами. Минусы — не получается работать с mp4-файликами, создаваемыми ffmpeg, поскольку исходники закрыты, понять почему — проблема.
    • USP от CodeShop. Плюсы — прекрасная открытая реализация серверной части, минусы — закрыта клиентская и, вообще-то, софт коммерческий, хоть и OpenSource. Если сайт, использующий технологию, коммерческий — показывает рекламу или взимает плату за просмотр, нужно покупать лицензии.

    Я работаю в компании, которая занимается видео-технологиями в интернет уже лет 10 и у нас есть определенный опыт и, посмотрев на документацию протоколов Adobe HTTP Dynamic Streaming, мы решили, что для проекта нашего “Тюба” нам проще и быстрее реализовать серверную поддержку самостоятельно. А клиентская реализация протокола в OSMF открыта и под BSD-лицензией.

    Результатом является проект OpenHttpStreamer, который мы решили выложить в OpenSource под LGPL.
    Официальная страничка проекта — http://inventos.ru/OpenHttpStreamer
    Исходники доступны на GitHub — https://github.com/inventos/OpenHttpStreamer.
    Мы пробовали собирать под Ubuntu 10.10, Fedora 12, Debian(Squeeze). Из особенностей — нужны scons, g++ версии 4.3.0 и выше и boost >=1.39.

    Как пользоваться:
    $ git clone https://github.com/inventos/OpenHttpStreamer.git
    $ cd OpenHttpStreamer/mp4frag
    $ scons configure && scons
    $ sudo scons install

    Если все прошло успешно в /usr/local/bin/mp4frag будет собранная утилита создания статических фрагментов

    $ mp4frag
    Allowed options:
    --help produce help message
    --src arg source mp4 file name
    --video_id arg (=some_video) video id for manifest file
    --manifest arg (=manifest.f4m) manifest file name
    --fragmentduration arg (=3000) single fragment duration, ms
    --template make template files instead of full fragments
    --nofragments make manifest only

    Закодируем ffmpeg’ом какой-нибудь ролик в двух качествах — 400 и 700 кбит/сек (примерно)

    $ ffmpeg -y -i test.mpg -acodec libfaac -ac 2 -ab 96k -ar 44100 -vcodec libx264 -vpre medium -g 100 -keyint_min 50 -b 300k -bt 300k -threads 2 test-q1.mp4
    $ ffmpeg -y -i test.mpg -acodec libfaac -ac 2 -ab 96k -ar 44100 -vcodec libx264 -vpre medium -g 100 -keyint_min 50 -b 600k -bt 600k -threads 2 test-q2.mp4

    Получили два mp4 файлика — test-q1.mp4 и test-q2.mp4, из которых генерируем статические фрагменты:

    $ mp4frag --src test-q1.mp4 --src test-q2.mp4 --manifest=test.f4m

    Результатом работы является описатель файла (“манифест”) — test.f4m и статические файлики-фрагменты в папках 0/ и 1/

    Выкладываем test.f4m 0/ 1/ под DocRoot любого веб-сервера, способного отдавать статику, и нам остается написать на флеше простой плейер, используя в качестве движка OSMF, или взять готовый плейер.

    Для быстрого теста можно воспользоваться нашей сборкой OSMF-плейера.
    Для этого
    1. под DocRoot нашего сервера (там же, где и test.f4m) помещаем такой crossdomain.xml:
    <?xml version="1.0"?>
    <!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
    <cross-domain-policy>
    <allow-access-from domain="inventos.ru" />
    </cross-domain-policy>

    2. переходим в браузере по ссылке http://inventos.ru/OpenHttpStreamer?url=http://your_http_host/test.f4m


    Как обычно, если что-то не получается, смотрим логи нашего сервера — есть ли обращения от плейера к crossdomain.xml, test.f4m, файликам сегментов. Удобно проверять, все ли верно — самим «подергать» нужные адреса —
    wget -O - -S «http://your_http_host/test.f4m»
    wget -O - -S «http://your_http_host/1/Seg1Frag1»

    В заключение пару слов о том, что сейчас лежит в репозитарии. Пока написан только статический перепаковщик — mp4frag. Модуль для nginx в разработке. Мы уже продумали архитектуру и алгоритмистику, активно программируем и собираемся выпустить буквально на этой-следующей неделе — надеюсь, я по этому поводу еще напишу.

    Модуль динамической генерации нам нужен, чтобы контент хранить в первозданном (mp4 после конвертации ffmpeg) виде, поскольку это достаточно универсальный формат, подходящий для других целей (стриминга на другие платформы). Есть интересный вариант — использование fragmented mp4, но он менее универсален.

    Мы придумали простой способ — проиндексировать mp4 для быстрого доступа к нужным фрагментам и положить индексы в отдельном файлике рядом с самим контентом. Размер индекса будет всего около 1% от исходных файлов. Из-за того, что даже получив быстрый доступ к нужному фрагменту mdat в исходном mp4, нам нужно еще перемикшировать данные, добавив flv — заголовки ( особенность реализации OSMF), мы теряем в производительности по сравнению со статикой. Однако, проксируя запросы на данный модуль через быстрый web-cache и кешируя ответы, мы достигаем как высокой производительности, так и большой универсальности.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 55

      0
      Отлично, но хабракат не помешал бы.
        +3
        сладил с ним, наконец
        +1
        Полез посмотреть, что есть под IIS с Windows.
        IIS Media Services, позволяет стримить до 1080р адаптивно.
        У них на сайте демка довольно радужная, правда нужно ставить их дурацкий SilverLight.
          –4
          Позволю себе заметить, что SilverLight не только не «дурацкий», но ещё и очень клёвый, как в функционале, так и в программировании, в инструментах и прочем. Так-то.
            +3
            Я с точки зрения конечного пользователя, которого заставляют ставить «очередную программу непонятно для чего» ))
              –4
              Без сомнения, мне включать дырявый флеш «гораздо приятнее»
                +1
                Я как конечный пользователь привык к флешу и к его неизбежности и его тормоза на нетбуках, к его постоянным обновлениям.
                Сильверлайт — тёмная лошадка )
                  –2
                  Я как пользователь Silverlight'a привык к хорошему и не желаю возвращаться к flash'у
                  • UFO just landed and posted this here
                      –1
                      Толсто тролите, а главное — глупо. В приличных местах за такое сливают.

                      habrahabr.ru/blogs/silverlight/80497/
                      riastats.com/

                      И главное, что тенденции только в пользу SilverLight. Т.к. Windows установлен на подавляющем большинстве персональных компьютеров, то довольно скоро на почти всех них будет установлен наш замечательный SilverLight. Так-то.

                        +2
                        ну и что что виндовс у всех установлен, это ведь людям не мешает не пользоваться Explorer'ом и Windows media player, вот так и ваш замечательный, самый быстрый и безглючный SilverLight легко можно заменить на Flash. Я сколько не пытался полюбить эту технологию, она никак не хотела идти на контакт, то установить SilverLight проблема, то после установки браузер намертво зависал, то при переходе на всемизвестный сайт на SilverLight московского метро, просто вылетал нах. Разве так должна работать технология будущего? и да, Flash в миллион раз легче освоить.
                          0
                          На смену одному тролю пришёл 2-й.

                          Поясню, что непосредственно в этих 2-х комментариях не рассматриваются особенности технологий. Речь шла исключительно о распространённости.

                          _____________________________________________________________

                          Ну раз уж вы решили поговорить на совсем другую тему.
                          1. Речь о предустановленном Sliverlight идёт в естественном ключе необходимости его популярности для массового использования разработчиками.
                          2. Как раз Silverlight на flash на заменишь, а наоборот — запросто.
                          3. Ваши проблемы с Silverlight я бы отнёс на вашу сторону.
                          4. Установить Silverlight не то что не проблема, это даже обсуждать не имеет смысла, настолько маразматично ваше высказывание. Обычно детальный разбор подобной ситуации приводит к осознанию, что у чувака искалечена ОС им самим.
                          5. Ни разу браузер под Silverlight не зависал (Firefox и IE9 под Windows Vista)
                          6. А вот Macromedia Flash иногда вылетает. А подтупливает очень у многих постоянно.
                          7. Лёгкость освоения влияет на быстроту популяризации и только, а это не главное. Flash легче освоить нубам и любителям всякого говна типа ruby. Тем кто использует C#, освоение Silverlight проходит очень быстро и просто. А это как раз уже важно.

                            0
                            Я знаю C#, silverlight ни в зуб ногой.
                            Попробовав просто что-то написать, я понял что это не просто — это ОЧЕНЬ просто!
                            Flash? — Нет уж.

                            Доля Silverlight по миру ~ 75%

                            Установка! не требует перезагрузки браузера! и происходит по нажатию 1 кнопки.

                            Короче, можете троллить дальше, но от реальности не убежать.
                            Вы смотрите трансляции через flash — мне жалко вас.

                            Продукт от MS на silverlight — это лучшее решение для трансляций, которое я видел.
                            Изменение качества на лету, для безбуферезированного просмотра.
                            Нет проблем с перемоткой(в прошлое :) ), даже когда трансляция идет в online.
                              +1
                              Господа, чем вы меряетесь?
                              Знаком с одной и другой технологией. С Silverlight правда в меньшей степени.
                              Честно Silverlight очень понравился, работа проведена огромная.
                              Но как говорится «кто первый встал того и тапки» и переломить это очень сложно, особенно когда adobe не дремлет. В данной ситуации для flash большую опасность представляет html5 IMHO.
                                0
                                Про тапки вы зря. Конечному пользователю всё равно при условии, что оба проигрывателя установлены.
                                А разработчики уже многие выбрали Silverlight.

                                Так что «тапок» не будет.
                                  +1
                                  я вообще не понимаю, зачем так жопу рвать и наезжать на людей из-за своей привязанности к сильверлайту, ну нравится и хорошо, пользуйтесь на здоровье, не нужно ничего навязывать.
                                    –1
                                    Вы продолжаете тролить. Перечитайте сообщения выше.
                                0
                                necrophile mode on

                                Ну что? Как там Сильверлайт? Убежал от реальности?
                    –1
                    Угу. Вы когда-нибудь устанавливали SilverLight? Я лично не припомню более быстрой, лёгкой, безглючной, ненапряжной, минимальнокликательной инсталляции.
                +1
                А насчет ErlyVideo что то можете сказать? erlyvideo.org/
                  +1
                  Да. В нем хорошо реализован apple http streaming (mpegts), хоть автор дизайн протокола и ругает
                  Если вводные такие — видео сайт должен отдавать во flash, iOS, android, то мы пробовали делать, например, так:
                  кодируем
                  High profile H264 — 3 качества (X1.mp4 X2.mp4 X3.mp4)
                  Baseline H.264 — 2 качества (X4.mp4 X5.mp4)

                  под flash — отдаем OpenHttpStreamer'ом X1.mp4 X2.mp4 X3.mp4
                  под iphone — ErlyVideo X4.mp4 X5.mp4
                  под iPad — ErlyVideo X1.mp4 X2.mp4 X3.mp4 (там мощный чип декодирования и экран большой)
                  под android phone — http progressive download c ручным переключением X4.mp4 X5.mp4
                  под android pad — http progressive download c ручным переключением X1.mp4 X2.mp4 X3.mp4

                  Под android я не нашел информации про multibitrate dynamic streaming, поэтому пока только «ручками», как в m.youtube.com
                    +1
                    у нас есть код, который вещает на андроид, но я тоже не знаю, что у них с автоматическим переключением между битрейтами.

                    аналог openhttpstreamer-а скорее всего тоже у нас появится.
                      0
                      а какой транспорт используется для live-трансляций на андроид? управляющий протокол — RTSP, а какой транспорт возможен? только RTP по UDP или какой-то еще?
                        0
                        Я могу ошибаться, но вроде бы только RTP по UDP. Впрочем, я ни разу не встречал что бы RTSP управлял чем-то кроме RTP
                          0
                          иногда rtsp используют для вещания голого mpegts поверх udp (в формате как он передается по мультикастам)
                  0
                  iis media services (сервер-организатор потока Smooth Streaming) позволяет стримить адаптивный поток на устройства Apple без потребности в silverlight, поток налету конвертируется в apple http streaming.

                  организация потокового адаптивного онлайн вещания на базе iis media services сразу для платформ windows и apple занимает несколько минут
                    0
                    И у нас есть исходники iis, чтобы править косяки, а также мы можем на халяву поставить пару сотен серверов, под управлением windows server xxxx.
                    Добрый майкрософт уже все написал, ребята!
                      –1
                      Там тоже это есть и точка. Вопрос цены и остального — вопрос другой.
                        0
                        Точка есть на клавиатуре, поищите.

                        Вопрос цены никуда собственно не девается, в независимости от вашего к нему отношения.
                        Все просто — решения от MS не интересны из-за этого «остального». Решение с открытыми исходниками сильно предпочтительнее. То что оно там есть, не гарантирует, что оно работает так, как надо вам. А если есть исходники, то это уже не проблема.
                          –1
                          А я понял. Вы из той категории людей, чьё мнение единственное верное, а все вокруг идиоты и ничего не знают. ок.
                          Ты хоть понял о чем я сказал в своем комментарии?
                          Что есть в IIS подобное решение и всё. Просто блядь факт — есть и всё.
                        +2
                        Проблема не столько в отсутствии у вас исходников от IIS, сколько в отсутствии людей, которые будут готовы за деньги поправить эти исходники. Микрософт ничего не будет допиливать для вас, а контора поменьше сможет.
                      0
                      Я, видимо, не уловил сути — flowplayer + php/perl скрипт с докачкой позволяет нечто вроде HTTP streaming.

                      Из каких модулей состоит ваше решение?
                        +1
                        Модуль под nginx (только что запушили альфа-версию) и osmf-based flash player.

                        Насколько я знаю flowplayer пока не умеет HTTP Dynamic Streaming — http://flowplayer.org/forum/6/45644

                        Все что я видел — это вариации на тему псевдо-стриминга и даже byte-range requests.

                        HTTP dynamic streaming изначально подразумевает, что
                        1. ролик состоит из нескольких файлов разных битрейтов
                        2. каждый файл разбит на одинаковые фрагменты
                        3. плейер «выбирает» и закачивает нужные фрагменты для плавного и безостановочного воспроизведения ролика. Флеш это умеет только с версии 10.1

                        Каждый фрагмент — это легко кешируемый HTTP-объект и нравится CDN. Microsoft в свое время так провела трансляции Пекинской(кажется) олимпиады для бешеного количества зрителей, используя традиционные CDN. Кажется, это технология и переросла потом в Microsoft Smooth Streaming for Silverlight.
                          0
                          Да, во flowplayer используются range requests.

                          Видимо, я не очень понимаю разницу между HTTP dynamic streaming и обычными HTTP range реквестами (псевдостриминг).

                          Конкретно — у меня стоит задача раздавать записанное и живое видео. Живое — там честный rtmp, записанное — flowplayer через http.
                          С помощью flowplayer я могу:
                          1) выбирать ролик с нужным битрейтом
                          2) заранее подготовить файл с нужными cue points и битрейтами
                          3) flowplayer умеет кешировать/показывать с любого места.

                          Единственное, что может (если я вас правильно понял) отличаться — если очень большие файлы или много кусков, которые надо в один непрерывный стрим склеить и показывать во впремя просмотра — вы это имеет ввиду?

                          Так умеет делать Windows Media Encoder — раздача файлов по HTTP потоком, а в сочетании с Helix сервером он очень неплох был в свое время.

                          Но тут опять неприятный момент :) — тот же Winows Media Encoder (да и хеликс вроде) умеют на лету перекодировать потоки под требования клиента — то-бишь указываешь пачку с файлами, а далее она автоматически перекодируютс и собираются в один поток. Это позволяет не парится с подготовкой файлов.

                          Я почему, собсно, расписался — я с удовольствием бы использовал ваш проект, так как мне надо раздавать видео (и живое, и записанное), но пока достаточно флешплеера и других rtsp/rtmp броадкастеров. Или у вас есть ценность, которую я не уловил?

                            +1
                            У вас получалось сделать пример на flowplayer, который стримит по http и переключается между битрейтами плавно, без заиканий? Теоретически такой код на AS для flash 10.1 можно сделать, я пока только видел примеры с плавным переключением по rtmp.
                            Тогда, да, разница, если сравнивать технологии — это большие файлы с byte-range доступом к ним или много предварительно размеченных кусочков. У каждой есть свои плюсы-минусы.
                              0
                              Переключение битрейтов во время проигрыша я не делал — пока не надо. Но мне кажется, что это можно реализовать через обычный AS плеер открыв два паралельных потока (как вы и написали).
                                0
                                В этом и суть динамического стриминга.
                                А что касется двух параллельных потоков, то синхронизироваться для плавного переключения довольно трудно.
                        +1
                        А как насчёт http live streaming?
                        Сейчас делаем проект, где как раз я решил использовать osmf.
                        Суть проекта: круглосуточное онлайн вещание с камеры по http.
                        До osmf использовал flowPlayer. Он себя не оправдал.
                        Во первых исходники очень запутанные и мало приспособленные для модификации.
                        Во вторых ощутимо жрёт память.
                        В третьих валится после 2-3 часов.

                        Позавчера перешёл на osmf — пока полёт нормальный.
                        Фишка в том что нужно через некоторые промежутки времени делать реконнект, чтоб файл не переполнял кэш, кроме того реконнекты делать надо с уникальным хостом/ адресом.
                        Ну и самое главное держать 2 соединения и при реконнекте переключать их после приёма данных (если переключать в одном потоке — будет пауза 2-5 секунд)
                          +1
                          Все live-решения — это уже полноценные медиасервера, а это совсем другая история. Хотя с http-кусочным стримингом теоретически можно построить такой «delay» live без медиасервера. Поступающий live быстро кодируем, фрагментируем и кладем эти фрагменты для скачивания, параллельно поддерживаем список актуальных фрагментов для скачивания. Для более-менее стабильной системы нужно в плейлисте кусочков 3-5, как минимум, иметь, плюс задержки на распространение и пр. Секунд в 30 отставания, наверное, можно уложиться. Чем больше допустимая задержка, тем стабильнее система получается. Но это теория…
                            0
                            Ну не знаю. мы сделали отдачу на несколько каналов типа:
                            ..live.f4v?uncaсhed242244&res=240
                            переменный битрейт пока не делали, только разрешение. от камеры расход на 3 канала.
                            Задержки от Одессы в Москву не более 2 секунд.
                              0
                              При условии идеальности канала.
                              При каком битрейте?
                            0
                            А что происходит в момент переполнения кэша?
                              +1
                              Пишем аналогичный проект, материала по FMS очень мало, интересно было бы обменяться опытом. Вы можете посмотреть нашу alpha версию тут >>> youvideoblog.com. Весь функционал еще отключен, но можно поиграться с онлайн видео, для этого нужно войти под лоигном login: test, pass: test
                              очень хотелось бы узнать о подводных камнях и решениях в вашем проекте.
                              0
                              UGC-контентом = User Generated Content — контентом
                              все равно что CD-диск
                                0
                                А что скажите про этот проект?
                                smoothstreaming.code-shop.com/trac
                                Там есть модуль и для nginx
                                  0
                                  Я чукча, читал не внимательно, в коде он упоминается.
                                    0
                                    Классический Microsoft Smooth Streaming. Доработанный flash клиент показывал отличные результаты. Возможно то что они дают в продакшн избавлено от мелких косяков. Единственный недостаток, как написано в статье, закрытость и не бесплатность.
                                    0
                                    Очень интересно, существует ли решение для показа видео (в виде кода, или в виде уже существующего видеохостинга), которое умеет детектировать не только полосу пропускания и выбирать соответствующий битрейт, но и определять производительность устройства определения (например Atom без чипа, или Atom с чипом декодирования, или одноядерник без и с GPU ускорением)?
                                      0
                                      Так ли важно какое конкретно устройство? Главное что его производительности не хватает, что выражается в недостаточном количестве fps. Ну и собственно, что мешает вам использовать эту информацию для перехода на поток с более простым профайлом кодирования или на поток с меньшим разрешением/битрейтом. И да, например, автор статьи активно использовал информацию о fps в одном из проектов.
                                        0
                                        Да, именно об этом и вопрос — определить хватает ли fps или нет. Этот OSMF умеет это делать? И какой-нибудь существующий видео-хостинг умеет так делать?
                                    0
                                    Очень интересно. А вы не пробовали стриминг в H.263 (для старых мобильных) к этой системе прикрутить?
                                      0
                                      Спасибо за статью, очень познавательно.

                                      Такой вопрос — зашел через ipad на страницу с примером видео. Там почему-то все равно предлагается выбрать качество видео, если я правильно понимаю назначение кнопок HQ+, HQ, SQ и на HQ+ наблюдаются как раз задержки и отсутствие переходов качества. Это у вас просто поддержки в плеере iOs устройств нет? Заранее спасибо за ответ.

                                      PS Пытался на сайте написать этот коммент, не получилось: пишет, что если вы не бот вернитесь и подтвердите и так постоянно.
                                        0
                                        Мы тоже сейчас запустили версию erlyvideo с HDS+HLS вещанием. Фактически от RTMP отказались.

                                        Only users with full accounts can post comments. Log in, please.