Унылость зависит от содержания, пятнистость, пиксельность и прерывания — от апстрима и топологии, а трясущиеся руки от операторов. Ничто из этого не связано с самой технологией, представленной в статье. При её использовании можно добиться преемлимого качества. Аналогично, телестулийное оборудование не гарантирует что стрим будет топовый.
Сами организаторы и их волонтеры — вполне. Огромное количество мероприятий, особенно всяких региональных Аниме-фестивалей и гик-конвентов делаются в условиях очень ограниченного финансирования и очень большого желания, я вижу офигенное применение этим технологиям в такой среде
"Из подручных материалов" значит совсем без специального оборудования, и при чем тут вообще освещение? Спасибо что поделились опытом. Но насчёт убогости, этот туториал не претендует на то чтобы расскзать как сделать убер-качественный стрим, а призван дать относительно рабочий тулсет тем у кого есть соответствующая задача и нет никаких средств для ее реализации. Может кто-то вообще не знал что так можно сдедать без серьезных инструментов.
Есть серьезные ребята, а есть опенсорс. Тут про второе. Иногда, как в случае с KiCAD, серьезные ребята юзают и развивают опенсорс. В данном случае, всё-таки нельзя сказать что это поделка "из говна и палок", OBSS и nginx вполне себе общепризнанные инструменты.
Всегда найдутся те, кому коммерческие решения подходят лучше, но эта статья не для них.
Все равно со стационарным звуком и камерами это надо будет вручную сводить. А если какая-то из камер начнет подлагивать, ещё раз сводить. Но в идеальных условиях это будет работать, да )
С RTMP уровень лагов такой же как и при обычном стриме. Не уверен что это минимально возможный уровнь, но вероятность высока) То есть точно не хуже чем если бы стрим шел бы напрямую с камер в Интернет. Тут многое зависит от стабильноости каналов связи.
Задержка буферизации есть, несколько секунд, не синхронизирована между камерами. Так что этот способ может не очень хорошо работать для съемки одного и того же действия с нескольких ракурсов, но хорошо подходит для описанной ситуации — когда оперторы снимают независимый контент на разных частях площадки.
Хотя ВОЗМОЖНО (не изучал) у OBS Studio есть инструменты синхронизации потоков. Это звучит как очень нужная фича.
Спасибо, я про острые углы не знал, но теперь буду знать) А насчёт платы, там во втором клиенте её авторы рассказывали что это проект лет 10 назад делался, с соответствующим опытом)
Мне не нравится плодить сущности (термины) без необходимости. Тем более, четкое разделение уже архаично, на том же OSH Park это очевидно прям на главной.
А я считаю наоборот, что можно не вводить новых понятий про всякие стороны, так как то слово "двухслойный" прекрасно определяют плату у которой нет внутри слоев :)
Но у двусторонних два слоя! Это и есть указание на их количество. В том то и соль что многослойные тоже двусторонние и легко ошибиться, а двухслойные явно двухслойные
Кстати, крутые чуваки тоже юзают промежуточный RTMP-сервер
https://youtu.be/TCSyNKbapdE?t=1m28s
Надо тестить)
Но всё-таки кажется что чисто клиентские приложухи для отправки стрима будут быстрее.
Нет, этот софт упомянается в статье и не обеспечивает хоть какой-либо стабильности и плавности потока. Не пойдет. Надо RTMP
Бесплатный если по нескольку стримов в один сервис не нужно (например на две страницы ВК стримить нельзя, но ВК и в Ютюб можно)
Чтобы стримить в кучу сервисов есть Restream
Пологаю, вопрос адресован Rambalac
хорошо кода есть варианты.
Унылость зависит от содержания, пятнистость, пиксельность и прерывания — от апстрима и топологии, а трясущиеся руки от операторов. Ничто из этого не связано с самой технологией, представленной в статье. При её использовании можно добиться преемлимого качества. Аналогично, телестулийное оборудование не гарантирует что стрим будет топовый.
Сами организаторы и их волонтеры — вполне. Огромное количество мероприятий, особенно всяких региональных Аниме-фестивалей и гик-конвентов делаются в условиях очень ограниченного финансирования и очень большого желания, я вижу офигенное применение этим технологиям в такой среде
"Из подручных материалов" значит совсем без специального оборудования, и при чем тут вообще освещение? Спасибо что поделились опытом. Но насчёт убогости, этот туториал не претендует на то чтобы расскзать как сделать убер-качественный стрим, а призван дать относительно рабочий тулсет тем у кого есть соответствующая задача и нет никаких средств для ее реализации. Может кто-то вообще не знал что так можно сдедать без серьезных инструментов.
Есть серьезные ребята, а есть опенсорс. Тут про второе. Иногда, как в случае с KiCAD, серьезные ребята юзают и развивают опенсорс. В данном случае, всё-таки нельзя сказать что это поделка "из говна и палок", OBSS и nginx вполне себе общепризнанные инструменты.
Всегда найдутся те, кому коммерческие решения подходят лучше, но эта статья не для них.
Все равно со стационарным звуком и камерами это надо будет вручную сводить. А если какая-то из камер начнет подлагивать, ещё раз сводить. Но в идеальных условиях это будет работать, да )
С RTMP уровень лагов такой же как и при обычном стриме. Не уверен что это минимально возможный уровнь, но вероятность высока) То есть точно не хуже чем если бы стрим шел бы напрямую с камер в Интернет. Тут многое зависит от стабильноости каналов связи.
Задержка буферизации есть, несколько секунд, не синхронизирована между камерами. Так что этот способ может не очень хорошо работать для съемки одного и того же действия с нескольких ракурсов, но хорошо подходит для описанной ситуации — когда оперторы снимают независимый контент на разных частях площадки.
Хотя ВОЗМОЖНО (не изучал) у OBS Studio есть инструменты синхронизации потоков. Это звучит как очень нужная фича.
Ну я в принципе подозревал что у этого нелогичного термина ноги растут из СССР
Да, в своей статье я решил избавиться от термина, порождённого (с неясными целями) "знатоками техпроцесса" без учёта англоязычной терминологии.
Спасибо, я про острые углы не знал, но теперь буду знать) А насчёт платы, там во втором клиенте её авторы рассказывали что это проект лет 10 назад делался, с соответствующим опытом)
Мне не нравится плодить сущности (термины) без необходимости. Тем более, четкое разделение уже архаично, на том же OSH Park это очевидно прям на главной.
А я считаю наоборот, что можно не вводить новых понятий про всякие стороны, так как то слово "двухслойный" прекрасно определяют плату у которой нет внутри слоев :)
Но у двусторонних два слоя! Это и есть указание на их количество. В том то и соль что многослойные тоже двусторонние и легко ошибиться, а двухслойные явно двухслойные
Способ со сложением пополам, модифицированный для разных листов. Но наверно может точнее получиться.