The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск серверов для потокового вещания Roc 0.1, Ant 1.7 и Red5 1.1.1

01.06.2019 10:07

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

  • Представлен первый выпуск Roc, тулкита для потоковой передачи звука по сети в режиме реального времени с гарантированным временем задержек и обеспечением качества на уровне звуковых компакт-дисков. При передаче учитывается отклонение времени системных часов отправителя и получателя. Поддерживается восстановление потерянных пакетов при помощи кодов прямой коррекции ошибок в реализации OpenFEC (в режиме минимальных задержек применяется код Рида — Соломона, а в режиме максимальной производительности - схема LDPC-Staircase). При передаче используется протокол RTP (AVP L16, 44100Hz PCM 16-bit). В настоящее время пока поддерживается только передача звука, но в планах намечена поддержка трансляции видео и других типов контента.

    Имеется возможность мультиплексирования потока от нескольких отправителей для доставки одному получателю. Возможно подключение разных профилей настроек дискретизации, в зависимости от типа CPU и требований к задержкам при передаче. Поддерживается трансляция через различные типы сетей, включая локальную сеть, интернет и беспроводную сеть. В зависимости от настроек, пропускной способности и потери пакетов Roc автоматически выбирает необходимые параметры кодирования потока и в процессе передаче корректирует его интенсивность.

    Проект состоит из Си-библиотеки, инструментария командной строки и набора модулей для применения Roc в качестве транспорта в PulseAudio. В простейшем случае доступный инструментарий позволяет направить звук из файла или звукового устройства на одном компьютере в файл или звуковое устройство другого компьютера. Поддерживаются различные звуковые бэкенды, включая ALSA, PulseAudio и CoreAudio. Код написан на языке C++ и распространяется под лицензией MPL-2.0. Поддерживается работа в GNU/Linux и macOS.


  • Доступен новый выпуск мультимедийного сервера Ant Media Server 1.7, позволяющего организовать потоковое вещание через протоколы RTMP, RTSP и WebRTC с поддержкой режима адаптивного изменения битрейта. Ant также может применяться для организации сетевой записи видео в форматах MP4, HLS и FLV. Из возможностей можно отметить наличие конвертера WebRTC в RTMP, поддержку IP-камер и IPTV, распространение и запись live-потоков, организацию стриминга в социальные сети, обеспечение масштабирования через развёртывание кластера, возможность массового вещания из одной точки многим получателям с задержками на уровне 500 мс.

    Продукт развивается в рамках модели Open Core, которая подразумевает разработку основной части под лицензией Apache 2.0 и поставку расширенных возможностей (например, стриминг в Youtube) в платной редакции. В новой версии на 40% повышена производительность вещания через WebRTC, добавлен просмотрщик логов, улучшена web-панель, добавлен REST API для вывода статистики, оптимизировано потребление памяти, улучшена обработка ошибок и добавлена возможность отправки статистики в Apache Kafka.


  • Состоялся релиз сервера потокового вещания Red5 1.1.1, позволяющего передавать видео в форматах FLV, F4V, MP4 и 3GP, а также звук в форматах MP3, F4A, M4A, AAC. Доступны режимы Live-вещания и работы в форме записывающей станции для приёма потоков от клиентов (FLV и AVC+AAC в контейнере FLV). Изначально проект был создан в 2005 году для создания альтернативы Flash Communication Server, использующей протокол RTMP. В дальнейшем в Red5 через плагины была обеспечена поддержка вещания с использованием HLS, WebSockets, RTSP и WebRTC.

    Red5 применяется в качестве сервера потоковой передачи в проекте Apache OpenMeetings для организации видео- и аудиоконференций. Код написан на Java и поставляется под лицензией Apache 2.0. На базе Red5 построен проприетарный продукт Red5 Pro, обеспечивающий масштабирование до миллионов зрителей с задержками доставки на уровне 500 мс и возможностью развёртывания в облаках AWS, Google Cloud и Azure.



  1. Главная ссылка к новости (https://github.com/Red5/red5-s...)
  2. OpenNews: Выпуск системы потокового видеовещания OBS Studio 23.0
  3. OpenNews: Выпуск сервера потокового вещания Icecast 2.4.4 с устранением уязвимостей
  4. OpenNews: Представлен SRT, открытый протокол для потоковой передачи видео
  5. OpenNews: MPEG LA формирует патентный пул для лицензирования потокового вещания поверх HTTP
  6. OpenNews: Выпуск медиасервера Gerbera 1.3
Лицензия: CC-BY
Тип: Программы
Ключевые слова: stream, ant, roc, red5, media
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (44) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (-), 11:43, 01/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    в первый раз слышу, но поздравляю причастных
     
     
  • 2.2, Аноним (2), 11:51, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Roc вроде пилит товарищ из России. Очень годный проект, судя по описанию. Задержки при передаче звука - больная тема для очень многих.
     
     
  • 3.6, виндотролль (ok), 22:03, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Pulseaudio автоматически компенсирует задержки при передаче по сети.

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

    Почему?

     
     
  • 4.7, Michael Shigorin (ok), 22:36, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно, потому, что вместо работы по сети или в режиме управляемого микширования приложений/выходов его запихивали примерно везде в режиме "всё равно придётся, ретрограды"?
     
     
  • 5.17, виндотролль (ok), 23:39, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вопрос «почему?» был риторический.

    Я о Roc впервые узнал несколько дней назад, еще до публикации на opennet, из рассылки pulseaudio, где сам автор анонсировал плагин для pulseaudio на основе Roc.
    Т.е. на опеннете Roc хороший, pulseaudio плохой. При этом сам автор Roc предлагает использовать его вместе c pulseaudio. Иронично, не находите?

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

     
     
  • 6.29, Аноним (29), 19:33, 02/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Т.е. на опеннете Roc хороший

    Один аноним не является выразителем мнений всего опеннета. Большинство остальных просто остерегается давать оценки не глядя.

     
  • 6.31, gsdh (?), 04:18, 03/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а не ретроградские обиды

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

    > Т.е. на опеннете Roc хороший, pulseaudio плохой.

    Что странного, Stg-44 был хорошей винтовкой у плохих фашистов, как это связанно вообще.

     
  • 5.24, Аноним (24), 12:51, 02/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Т.е. системд который везде хороший. А пульс который пихают везде плохой?

    Хотя стоп системд тоже же плохой...

     
  • 4.8, Аноним3 (?), 22:48, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    а профи музыканты вообще не любят линух по одной простой причине - мало софта и тот без танца с бубном редко заводится. сам писал гитару , знаю о чем говорю. а если задуматься играть в линию компа, то вообще ужас. единственная попытка что то сделать это Jack, но и он работает с пинком только.про пульсу можно сказать только одно - она способна кое что делать, но только не микшировать )) вот если она работает простым мостом передачи это еще куда ни шло. но задержки звука это не та стихия. даже альса это ужас при игре в линию( а тут именно важны задержки). фишка в том , что мало софта , который был бы не очередным средненьким плеерком или текстовым редактором. но если тебе только мост нужен то пульса вполне себе перекинет тебе аудио на колонки.
     
     
  • 5.11, виндотролль (ok), 23:06, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Пульса никогда не позиционировалась как решения для проф работы со звуком.

    Но bit-perfect поток, будь-то по сети, или по usb, она гоняет отлично. Разная разрядность сигнала, разная частота дискретизации — пульса переключает устройство в нужный режим и выводит звук без потерь. Я не знаю, что может еще потребоваться.

    По поводу софта, его, конечно, мало, это правда. И если вопрос DAW с появлением Bitwig можно считать решенным (я для себя так решил, по крайней мере), то вот с VSTi печаль.

    А что у альсы с задержками? Я не мерял, но иногда играюсь с pianoteq через альсу, там декларируемая задержка при моем буффере составляет ~6мс, но она почему-то ощущается, что совсем не имеет смысла (постоянная времени человеческого слуха — 150мс, что на два порядка выше этого значения!), подозреваю, что альса может что-то добавлять и там действительно больше 6мс. Есть у вас замеры?

     
     
  • 6.39, Аноним (39), 10:00, 04/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А вы как звук выводите? Через line-out или ещё как-то?
     
     
  • 7.42, виндотролль (ok), 05:59, 05/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А вы как звук выводите? Через line-out или ещё как-то?

    line-out, конечно. Звуковуха E-MU 0404, в которой сигнал, насколько знаю, роутится как-то очень правильно, с использованием специального FPGA, так что в самой карточке задержки минимальны. Pianoteq в сравнении со встренным тембром рояля, казалось, играл немного с опозданием (играть можно было вполне, но, как будто, какая-то "вязкость" была, уж простите за такой термин).

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

    Надо мерять. Измерениям на слух (даже если это мой личный слух) я не верю.

     
  • 5.14, виндотролль (ok), 23:22, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вот нашел, кто-то замерял задержку альсы
    https://www.alsa-project.org/main/index.php/Test_latency.c

    Короче, нету ее, задержки. Все, как и на винде при использовании ASIO.

    Если у вас есть другие замеры — давайте сюда, посмотрим вместе.

     
  • 5.21, Annoynymous (ok), 00:16, 02/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > даже альса это ужас при игре в линию
    > единственная попытка что то сделать это Jack,

    А то, что jack работает поверх альзы, мы никому говорить не будем.

     
     
  • 6.30, Аноним3 (?), 23:47, 02/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    тогда почему задержка jack меньше альсы? да добавлю пробовал и на винде с асио. короче задержка все равно есть. пока не купил лампу под гитару задержка всегда была.)) и она будет, поскольку сам принцип работы всех этих программных обработок требует времени. тут хоть что делай это не изменишь. вот если пишешь в линию с микрофона тогда все ок. поскольку все что идет, идет на простую запись в файл и он идет сплошным потоком.
     
     
  • 7.33, Аноним (33), 14:13, 03/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > тогда почему задержка jack меньше альсы?

    Потому что ты чего-то не учёл. Например, то, что jack тестировался на runtime-ядре, причём в ходе загрузки запускался волшебный скриптик, выставляющий приоритеты для прерываний.

     
     
  • 8.36, Аноним3 (?), 02:45, 04/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    я не об этом не проще ли напрямую заставить jack взять управлением звуковухи в ... текст свёрнут, показать
     
  • 7.34, виндотролль (ok), 20:35, 03/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > тогда почему задержка jack меньше альсы? да добавлю пробовал и на винде
    > с асио. короче задержка все равно есть. пока не купил лампу
    > под гитару задержка всегда была.)) и она будет, поскольку сам принцип
    > работы всех этих программных обработок требует времени. тут хоть что делай
    > это не изменишь. вот если пишешь в линию с микрофона тогда
    > все ок. поскольку все что идет, идет на простую запись в
    > файл и он идет сплошным потоком.

    Чем меряли задержку?

     
     
  • 8.37, Аноним3 (?), 02:50, 04/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    если уши не отдавлены, то всегда услышишь разницу между ударом по струне и выход... текст свёрнут, показать
     
     
  • 9.38, виндотролль (ok), 04:04, 04/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Понимаю, знакомый эффект Буфер в винде и в Альсе при этом был одинаковый, как п... текст свёрнут, показать
     
     
  • 10.40, Аноним3 (?), 01:23, 05/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    какая разница какой он был они оба дают ощутимую задержку вот в чем вопрос и ... текст свёрнут, показать
     
  • 7.35, Annoynymous (ok), 21:02, 03/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что задержка — это не только звуковая карта. Это ещё и весь процесс обработки звука. И тут можно либо монопольно захватить звуковую карту, либо использовать jack, архитектура которого позволяет обрабатывать в режиме мягкого реального времени. В Windows те же функции выполняет ASIO, до появления которой всё тоже захватывали звуковую карту монопольно.

    Да, задержка всегда есть, даже в аппаратных процессорах, которые по сути всё те же специализированные DSP. Только в Jack можно играться размером буфера и добить задержку до приемлемых миллисекунд. На моём Ryzen 5 2600 и Focusrite Scarlett 2i2 я могу себе позволить 4мс, например. Твоё оборудование может дать больше или меньше.

     
  • 5.23, Joshua (?), 08:42, 02/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Профи музыканты используют профессиональную студийную аппаратуру для записи и сведения, если нет таковой то арендуют студии по часам. Домашние компы используют начинающие.
     
     
  • 6.27, виндотролль (ok), 16:56, 02/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Профи музыканты используют профессиональную студийную аппаратуру для записи и сведения,
    > если нет таковой то арендуют студии по часам. Домашние компы используют
    > начинающие.

    Определение профи расплывчатое. Знаю музыкантов, которые производят очень хорошо продающиеся альбомы в домашних студиях.
    Конечно, не знаю никого, кто бы при этом использовал линукс. Но большая студия от узнаваемого бренда с микшерами на 100500 каналов и '0 парами мониторов не нужна для продакшна уже много лет как. По крайней мере, в тех жанрах, где не нужна акустическая запись (хотя и здесь знаю пару очень продающихся примеров, когда только запись производилась на маленькой студии, а мастеринг — в домашних условиях).

     
  • 5.25, Аноним (24), 12:52, 02/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Под звук надо реалтайм ядро. Почти уверен ты мало плясал с бубном.
     
     
  • 6.41, Аноним3 (?), 01:30, 05/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    нет бубн тут не поможет.только реальная аналоговая аппаратура. проверена муками настройки и с асио и с jack. как итог пришел к мнению хочешь звук - бери ламповый усилок и играй. а писать через микрофон в комп. запись в файл без обработок потоком идет и проблем нет. но пропуск сигнала , допустим с гитары, для обработки программными дисторшенами и дилеями и вывод их на колонки не катит. не в смысле звука нет, он есть ,но когда ты дернул струну и уже приготовился чеканить следующую ноту, а звук только вышел на колонки это бесит.звук должен быть одновременно с касанием струны или нажатием клавиши(как угодно). и бесит всех музыкантов поверь. хотя я не профи так развлекаюсь.))
     
  • 4.9, Пользователь Debian (?), 22:59, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот тут https://gavv.github.io/articles/new-network-transport/ написано, что не так с задержками у пульсы (автор — главный разраб roc).

    Кстати, у него в блоге есть эпик с описанием архитектуры пульсы в целом, если интересно.

     
     
  • 5.12, виндотролль (ok), 23:15, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Интересная статья, спасибо. И про пульсу будет интересно почитать.

    Пока не понял, использует ли Roc кодирование с потерями для передачи (RTP предлагает разные кодеки,  я еще не смотрел, какой именно используется в Roc).

    В текущем виде native tcp пульсы для меня имеет огромное преимущество — поддерживает любые комбинации разрядности и частоты дискретизации. Так что на одном устройстве, без переконфигураций я могу и киношку посмотреть, и качественные записи в 24/96 послушать. При этом, обращаю внимание, устройство на приемной стороне переводится в режим, скоторым передается поток (ессно, если устройство поддерживает). Roc-овские 16/44 смотрятся на этом фоне бледно.

    Единственная киллер фича из описания — нечувствительность к локальному времени на устройствах. Вот здесь пульса может доставить хлопот на пару вечеров, особенно, если не знать об этой особенности. Но решается один раз настройкой ntp. Короче, пока native tcp пульсы удобнее для домашнего применения. Посмотрим, что Roc предложит в будущем.

     
     
  • 6.15, gavv (?), 23:26, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Пока не понял, использует ли Roc кодирование с потерями для передачи (RTP предлагает разные кодеки,  я еще не смотрел, какой именно используется в Roc).

    Пока только PCM 16 бит.

    > Так что на одном устройстве, без переконфигураций я могу и киношку посмотреть, и качественные записи в 24/96 послушать. При этом, обращаю внимание, устройство на приемной стороне переводится в режим, скоторым передается поток (ессно, если устройство поддерживает). Roc-овские 16/44 смотрятся на этом фоне бледно.

    Пока в Roc этого нет. Это в планах на ближайшие несколько релизов.

     
  • 4.22, Аноним (2), 06:23, 02/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    лично я не написал ничего плохого о пульсе. Что там любят/не любят на опеннете, меня мало волнует. И да, Roc - годный проект.
     
  • 3.10, Пользователь Debian (?), 23:01, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Как минимум два товарища из России ;-)
     

  • 1.3, Аноним (3), 12:45, 01/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А есть возможность организовать свой сервер с фоновой музыкой как у mpd?
     
  • 1.4, fgi (?), 14:50, 01/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    ant это форкнутый red5, какой смысл пиарить ред5 сразу два раза ?
     
  • 1.5, Вася (??), 16:54, 01/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Про Roc не знал, интересно. Спасиб
     
  • 1.13, gavv (?), 23:21, 01/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > При передаче учитывается отклонение времени системных часов отправителя и получателя.

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

    Подробнее тут:
    https://roc-project.github.io/roc/docs/internals/fe_resampler.html

    > В зависимости от настроек, пропускной способности и потери пакетов Roc автоматически выбирает необходимые параметры кодирования потока и в процессе передаче корректирует его интенсивность.

    Этого пока нет, только в планах. ПОка что настраивать нужно вручную.

     
     
  • 2.16, виндотролль (ok), 23:29, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Прикольно, что об этом задумались. Но... а точно это надо?
    Не проще ли увеличить задержку на тех самых 20µs (как указано в статье) и буфферизировать? 20µs вообще нереально услышать.

    Более того, устройств с расбросом тактового генератор ±10Гц еще поискать надо, разве что с али по 5 штук на доллар заказать, так что в реальности буфер может быть еще короче.

    Не, это, конечно, интересная задача поковырять, но имхо, с точки зрения пользователя — абсолютно бесполезная вещь.

     
     
  • 3.18, gavv (?), 23:40, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Разница в частоте накапливается. Типичная скорость накопления - примерно 200 мс в час. То есть если вы выставили размер буфера в 200 мс и запустили проигрывание на час, через час вы получите либо пустой буфер (если ресивер чуть быстрее), либо 400 мс вместо 200 мс в буфере (если ресивер чуть медленнее).

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

    Эта проблема не нова. Она решается, в том числе, в штатных транспортах пульсаудио. native транспорт решает ее тактируя клиента клоком звуковухи. А RTP транспорт пульсы решает ее так же, как Roc - ресемплером.

    Основная разница между штатными пульсовыми транспортами и роком - это восстановление потерь. Это актуально для Wi-Fi.

     
     
  • 4.19, виндотролль (ok), 23:51, 01/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Эта проблема не нова. Она решается, в том числе, в штатных транспортах
    > пульсаудио. native транспорт решает ее тактируя клиента клоком звуковухи. А RTP
    > транспорт пульсы решает ее так же, как Roc - ресемплером.

    Я, возможно, не обладаю пониманием проблемы. И не задумывался как именно проблема решается в pulseaudio, ваше объяснение много прояснило.

    Правильно ли понимаю, что проблема актуальна только в случае если источник умеет исключительно синхронно генерировать поток?
    Ну например, если у меня играет на ноутбуке mpd, то проблемы нету, т.к. я могу вычитывать с любой скоростью.
    Но вот если я хочу музыку с mpd играть _одновременно_ на ноутбучных колонках и на колонках, подключенных к удаленному устройству, то решение tcp native приведет к underrun/overrun либо на одном, либо на другом устройстве (появятся щелчки). Либо, если я смотрю видео, то в случае tcp native у меня будут выпадать кадры или появляться паузы в видео.

     
     
  • 5.20, gavv (?), 00:13, 02/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Правильно ли понимаю, что проблема актуальна только в случае если источник умеет исключительно синхронно генерировать поток?

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

    Roc написан из расчета на самый общий случай, когда отправитель и получатель могут иметь независимые клоки, поэтому он эту проблему решает.

    В штатном RTP транспорте пульсы все также. Только немного другой алгоритм подстройки.

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

    Про то как это решается в штатных транспортах пульсы можно посмотреть тут:
    https://gavv.github.io/articles/pulseaudio-under-the-hood/#time-management

    > Но вот если я хочу музыку с mpd играть _одновременно_ на ноутбучных колонках и на колонках, подключенных к удаленному устройству

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

     
     
  • 6.32, yaanon (?), 12:31, 03/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А для bluetooth наушников это тоже актуально? Слушаю с андроид.
     

  • 1.26, Аноним (26), 14:23, 02/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    ребята а как на googlechromocast передать фильмы с компа?
     
     
  • 2.28, виндотролль (ok), 16:57, 02/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ребята а как на googlechromocast передать фильмы с компа?

    купить комп от гугла а хромосью

     

  • 1.43, klalafuda (?), 18:19, 08/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Открытый Ant не впечатлил. Вещания через WebRTC нет - собственно основная вкусная вещь - а через HLS с естественной дикой задержкой и так каждый дурак может. Только в Enterprise. Низачет.
     
     
  • 2.44, klalafuda (?), 18:32, 08/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > В дальнейшем в Red5 через плагины была обеспечена поддержка вещания с использованием HLS, WebSockets, RTSP и WebRTC.

    Что-то я не замечаю WebRTC в Red5. Только в коммерческом Red5Pro. В результате в коре точно также грустно и скучно как и в анте.

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    MIRhosting
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру