Pull to refresh

Comments 65

Ну-ну, попробовали вы копнуть чуть глубже в этом направлении и шишек отхватили бы, так что говорить о всей красе не совсем корректно
Шишек действительно хватает — одни только пляски с опциями того же ffmpeg-а в некоторых случаях точно требуют бубна. Но сам по себе подход «одна прога — одна задача» меня вполне устраивает.
А когда идет масштабирование, то по любому начинаются проблемы, даже с одной прогой. VLC не хочет переживать свой же поток с другого сервера. Память в vlc регулярно «подтекает». Проблемы все решаемы, но нужно не один месяц, знаем по себе. Но в целом, очень хорошо, что есть такие тулзы
Про VLC хочу написать отдельную статью — у меня ушло примерно 4 месяца на эксперименты, в результате которых получилось сделать сборку, которая работает без перезагрузок с ноября — каждая нода спокойно тянет 1000 мегабитных потоков (да-да, гигабит в секунду).

Вкратце — хардварный кодер (QVidium) отдаёт поток на 9 мегабит по RTP, менеджмент-сервер при помощи VLC его транскодирует на 2 мегабита и раздаёт по RTSP нодам, которые уже на мегабите по HTTP раздают поток клиентам (при помощи того же VLC). Вот тут можно посмотреть — только в основном все передачи на румынском, хотя бывают и на русском: www.jurnaltv.md/ro/live/

Узлы для внешних пользователей находятся в Германии, для молдавских — в Молдове.
У нас примерно такая же схема, только еще wowza. Ждем тогда статью, почитаем
Кстати про ноду и 1000, так загрузить можно ее без проблем, даже с глюками VLC. Тут ведь в основном ограничения процессорного времени и объема ram
По секрету — всё гораздо проще — у немцев обычно все сервера с одной сетевухой, которая даёт максимум 1 гигабит :)
Это шикарные результаты, кстати. VLC вообще не отличается способностями стриминг-сервера.
Вот, с немецкой ноды статистика, если вам это что-то скажет:

~$ uptime
22:56:27 up 95 days, 23:43, 1 user, load average: 1.18, 0.98, 0.92

top:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13515 vlc 20 0 1014m 94m 9108 S 29 0.8 45333:49 vlc

$ free
total used free shared buffers cached
Mem: 12324132 1057900 11266232 0 285836 291632
-/+ buffers/cache: 480432 11843700
Swap: 16000632 0 16000632

~$ dpkg -l|grep vlc
ii vlc vlc-1.0.5-20100923-JTV-1 VLC build for JTV

$ vlc --version
VLC media player 1.0.5 Goldeneye
VLC version 1.0.5 Goldeneye
Compiled by root@mr01.
Compiler: gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute it under the terms of the GNU General Public License;
see the file named COPYING for details.
Written by the VideoLAN team; see the AUTHORS file.

и сколько при этом пользователей?
Все MPEG-TS?
Нет, это mp4 — это для флэша, ответ был про VLC. В среднем — ночью 160 человек, днём — в среднем 600, каждый клиент — около мегабита (зависит от картинки, там плавающий битрейт). Во время выборов каждая нода (и эта конкретно) стабильно держали 1000-1200 человек одновременно, т.е. мы под завязку забивали по 1 гигабиту на сервер. Немцы даже письмо прислали — мол, товарищи, у вас такой траффик, вы там никого не досите случаем? Но объяснения по поводу выборов приняли и никаких проблем не было.
Не понял насчёт mp4. Это файловый контейнер, а вы наверное всё таки поток отдавали?
А, да, пардон — спал мало сегодня. Контейнер flv, который снаружи видится как бесконечный файл (можно стягивать wget-ом), внутри там обычный x264.
Вы можете сами стянуть кусочек — или скормите линк 178.63.96.135:80/channel0.flv тому же FlowPlayer-у.
Ночью/днём — это на каждую ноду, разумеется. Сейчас она одна, так как формат меняется и внешние пользователи через пару дней уже не смогут смотреть картинку — обычные телевизионные заморочки с правами и лицензиями.
Внутри страны мы ограничены только пропускной способностью MDX-сети (и оборудования) — сейчас это 10 гигабит, но один толстый провайдер божится, что совсем скоро будет 300 гигабит. Правда, божится уже год как, но рано или поздно упрётся в лимит.
Про vlc интересно. Правда, если использовать старенький 0.9, то вроде не течет.
Он очень старый для текущих потребностей, с версии 1.1.*, если не ошибаюсь, улучшили h264 и т.п. Так что невозможно вернуться назад. ДА и вообще на разных системах все ведет себя по разному, centos, fedora, решил сапорт свежие поставить, и пошли несовместимости и ручная сборка vlc :)
до версии 1.1.непомню (точнее в changelog) — просто было тупо сломано http-ts-вещание.

теперь вроде нормально в теории, а на практике жопа какая-то. жду статьи, надо экспериментировать.
Пользовались до 1.1 http, работало
1.1.2 — TS and DVB demuxing fixes

Changes between 1.1.0 and 1.1.1:
Stream output:
* Fix h264 streaming in ts

не пахало.

в 0.9.x — пахало.
Черт я немного перепутал ветки, все правильно
Это да. Причем часто надо брать ffmpeg конкретной, свежей, ревизии :)
Но частьопций, к примеру, для apple streaming, расписана самим Apple.
Если источник один с известными свойствами, то и проблем никаких, шишки это если кодить из всего подряд в поток единого формата, с моей точки зрения.
Было бы здорово, чтобы так было. Но не всегда все так гладко, ведь программы пишут люди
Угу, при этом у разных людей может быть разное понимание стандарта — например, те же программеры из проекта x264 чуть-чуть по-другому понимают H264, чем инженеры из QVidium-а — в результате, поток, который даёт железячка не всегда переваривается VLC с этим кодеком — несмотря на то, что в доке от железки тестировать рекомендуют при помощи того же VLC. Вот такие пирожки с котятами :)
>не буду называть имён производителей, так как NDA
Уже секретно даже название?
Ну я же цену назвал ;-) Тут надо было либо имена производителей, либо цены. К тому же могли счесть рекламой. В гугле их легко найти — если в описании системы на сайте цена не указана — то это они и есть :)
Цена по nda, что может быть комичнее :)
Дык по NDA нельзя разглашать, что у компании ХХХ продукт стоит ZZZZ денег. Я согласовал всё разглашение — я могу назвать диапазон, но не могу назвать имён компаний. А то как бы получится обвинение в том, что они толкают аналог моего скрипта за кучу денег. Скандал-с будет. А так — я назвал диапазон, но ни одной компании, а те, кто работают в индустрии — наверняка смогут связать одно с другим :)
Татьяне, баааальшой привет!
Да, видно под танцами с бубном многие понимают разные бубны;)
Мне интересно, кто делал онлайн стриминг PublikaTV и почему он тормозит из-за пределов Мд.
Лепесин делал, все вопросы к ним. С ними вообще был забавный случай — они объявили о том, что оно скоро будет, мы про это узнали и без всяких объявлений сделали раньше, начав делать позже. Так сложились обстоятельства, что и в аппсторе нас почему-то раньше заапрувили. Често-честно, я Джобсу не писал и не звонил :)
Призываю в топик erlyvideo! Есть же специальные видеостриминговые серверы для этого… Почему решили их не использовать?
А зачем?

И какой сервер (кроме самого DSS) «искаропки» поддерживает такое видео? А коммерческие решения мы рассматривали в последнюю очередь. К тому же, этот вариант простой, как веник — там ломаться нечему :)
Когда DSS научился раздавать HLS? Он же вообще заброшен эпплом.
Да были вроде какие-то доработки умельцев — я сам мучал, но у меня оно то не запускалось, то валилось — поэтому я поковырялся, плюнул, и занялся изобретением собственного велосипеда.
Есть ещё gst-rtsp-server :) Вещает и перекодирует всё, что понимает гстример.
А зачем бить поток на кусочки, если передается только один поток? Ведь одна из главных задумок адаптивного HLS в возможности выбирать поток в зависимости от сигнала, загрузки устройства. Или у пользователей нет проблем с торможением видео?
Тормозов не наблюдалось на канале достаточной ширины. А на нестабильном и тонком канале и потоковое видео будет тормозить — нельзя впихнуть невпихуемое, вне зависимости от использованного протокола.
Мы вот тоже наелись говна с этим http live streaming'ом. Фактически, написали свой сегментер — взяли свой рекордер и приделали к нему простенький скриптик для создания m3u8. Всё победили, но задержку в 30 секунд — ну никак не перепрыгнешь.
Мы в экспериментах добивались 12-15 секунд. Но меньше не имеет смысла из-за самой сути сжатия на основе GOP. Если клиенту объяснить про отставание картинки с самого начала — то проблем не возникает.
Более того — отставание можно преподать как преимущество ;-)

Даже аппаратные кодеки дают отставание в 1-3 секунды (правда, тот же QV даёт 0.5 секунды, но при работе 2-х устройств между собой по их собственному протоколу).
> Более того — отставание можно преподать как преимущество

Реализация вещания на iOS развивает коммуникативные навыки! :-)

> меньше не имеет смысла из-за самой сути сжатия на основе GOP

В самих сегментах проблема — с GOP как раз проблем никаких, особенно если запретить b-frames (а их и надо запрещать для iOS).

Вообще до сих пор не понимаю, зачем Эпплу было городить этот велосипедоогород, а не использовать, например, старый добрый RTSP-over-HTTP. Из преимуществ — ну разве что динамическое переключение потоков.

Наверное, поэтому я там и не работаю. :-)
Зачем они всё это придумывали — хз, это надо у Джобса узнавать — но не думаю, что он расколется. Нам остаётся или смириться с тем, что есть и плясать под музыку Apple, или основать свой лунапарк с блэкджеком и далее по тексту, но пока нет пары лишних миллиардов — выбираем первое :)
MDX (высокоскоростная сеть внутри страны, к которой подключены все провайдеры и трафик в которой безлимитный)


MD-IX (Moldova Internet Exchange) AS31580

Вы сударь плохо сети понимаете. Это не «высокоскоростная сеть внутри страны», а точка обмена интернетом с бесплатным пирингом но взносом за обслуживание единицы используемой ёмкости (порта в 100, 1000, 10000 Mbit)

Когда один из наших заказчиков (телевизионный канал, достаточно известный в Молдове и в Румынии — Jurnal TV) попросил нас реализовать подобную систему вещания для iPhone/iPad/iPod


А по телику раскручивали как акт доброй воли и филантропии. Или я плохо понимаю как там дела обстоят.
>>Вы сударь плохо сети понимаете. Это не «высокоскоростная сеть внутри страны», а точка обмена интернетом с бесплатным пирингом но взносом за обслуживание единицы используемой ёмкости (порта в 100, 1000, 10000 Mbit)

Это детали, которые тут врядли кого-то интересуют. Суть та же. Сеть высокоскоростная? Да. Внутри страны? Да. Анлим? Да. Больше деталей не требуется :)

>>А по телику раскручивали как акт доброй воли и филантропии. Или я плохо понимаю как там дела обстоят.
В репортаже, когда Драгош пришёл в гости в студию? Нет, он же чётко ответил на вопрос, откуда это всё поехало — сам журнал и попросил. Просто журналисты — они такие журналисты… :)
Кстати, можно самим не реализовывать вещание на iPhone, а взять услуги у операторов CDN (например, CDNvideo)
Ага, а вы себе хотя бы порядок стоимости их услуг представляете? У них траффик ещё дороже, чем у Амазона.
>>У CDNvideo — дешевле трафик, чем у Amazon:
У них в заголовке страницы написано, что это для Рунета. Для Молднета это явно неактуально — у Jurnal TV только _внешний_ траффик (Европа/США) — более 60 терабайт в месяц. По Молднету немного больше, но тут его просто никто не учитывает, так как гигабитный порт стоит около 250 долларов в месяц (на 10 гигабит — 500) — это с анлим траффиком.

Но для тех, кто организует подобное в России — ваша ссылка наверняка будет интересна. :)
На самом деле в CDNvideo там нет ограничения на трафик — он может быть и европейским.
Так cdnvideo даже на Российских ix не присутствует, что уже говорить о европе?
Связанность будет никакая.
На MSK-IX присутствует. На остальных российских IX трафик мал, так что ставить там сервера нет практического смысла. Лучше договариваться напрямую с операторами.
ага по поводу регион, и вашей политики вкурсе, мягко говоря не правильная, но это уже оффтоп :)
P.S: см. мртг ix
Мда. Тянуть в dv по 10 сек, кодировать ffmpeg-ом. ужас.

В vlc с 1.2.0-dev появился access livehttp, который красиво бьет, кладет в файлы и обновляет m3u8
Тут расписано

Раз уже забираете через такую связку — пойдет
что-то вроде vlc -vvv dv/rawdv:///dev/raw1394 --sout '#transcode{...}:std{access=livehttp{...}}" и все. Отдавать nginx-ом, хоть 10gbit.

О, прогресс не стоит на месте — как выйдет 1.2.0 — посмотрим и его, спасибо.
Таки доделали версию для Ипад-а?
Угу, она уже даже есть в аппсторе, если ты про приложение новостное — обновись. :)
Сейчас как раз столкнулся с вещанием на базе HLS.
А как Вам удалось получить плавное проигрывание на IOS не указывая start offset для каждого ts чанка да и даже не указывая в m3u8 тег #EXT-X-DISCOUNTITY?

А то я уже замучился подбирать параметры для ffmpeg. Ввиду невозможности указать start без использования внешних программ, приходится указывать EXT-X-DISCOUNTITY
Но даже с ним при переходе на новый чанк видео все равно иногда дергается.
Да как бы вообще особо не заморачивались с этим — вот сейчас глянул:
cat live.m3u
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:4936073
#EXTINF:10,
91.216.97.10/live/live-4936073.ts
#EXTINF:10,
91.216.97.10/live/live-4936074.ts
#EXTINF:10,
91.216.97.10/live/live-4936075.ts

А вот статус сервера (это бездисковая нода, всё в оперативке):

10:09:05 up 576 days, 14:48, 2 users, load average: 0.47, 0.47, 0.38

Так что даже не знаю, что посоветовать…
Only those users with full accounts are able to leave comments. Log in, please.

Articles