Комментарии 25
Окей, но вот жаль, что про серверные пиры тема нисколько не раскрыта
https://hangouts.google.com/
Сам гигант google — он же как вы и упомянули — автор этого, пока не довел до ума технологию. Всё лагает, валиться, тормозит, больше 4 человек — всё, это уже не конференция а проверка компьютера на производительность и сеть на пропускную способность.
Если уж google уже с 2010 собирает технологию и всё собрать не может. Что уж нам туда соваться.
Сам гигант google — он же как вы и упомянули — автор этого, пока не довел до ума технологию. Всё лагает, валиться, тормозит, больше 4 человек — всё, это уже не конференция а проверка компьютера на производительность и сеть на пропускную способность.
Если уж google уже с 2010 собирает технологию и всё собрать не может. Что уж нам туда соваться.
Все с WebRTC нормально, проблемы есть, но их количество быстро уменьшается. Лагает и тормозит, потому что видео-кодек по умолчанию VP8 без аппаратной поддержки, скоро можно будет пользоваться H.264 и ситуация станет лучше + пока нет нормального simulcast, не говоря уж о SVC. Про серверные пиры все весьма нетривиально, DTLS/sRTP и вот это все заставляют много кода породить, чтобы с этим жить, но платформы а-ля VoxImplant берут эту проблему на себя.
Уже сейчас можно использовать h.264 вместо vp8
Опровергните или объясните то, как вы смогли передавать 720p, если класс видеозахвата в браузере кушает всегда 640х480 при подсоединении к web-камере.
В Firefox все параметры захвата работают отлично из коробки, специально только что перепроверил. Chrome просит список mandatory-параметров, тогда тоже захватывает все отлично. Проверил на 1.3 mpx камере, ОС — El Capitan, версии браузеров — последние доступные. Захватывает честные 1280х720. Учитывая, что довольно большая доля камер на рынке сами по себе не умеют больше 640х480, думаю, проблема связана именно с этим.
http://stackoverflow.com/questions/17502205/webrtc-resolution-limit
А можно это заюзать для онлайн ТВ?
У кого есть стабильные источники трансляций с доступом скажем по IP, чтобы они не разлетелись по интернету?
Черканите по контактам с http://football-online2.com/
Или тут в личку, если она работает.
Буду премного благодарен. :)
Возможно и платные источники.
В первую очередь интересуют Футбол 1 и Футбол 2.
Черканите по контактам с http://football-online2.com/
Или тут в личку, если она работает.
Буду премного благодарен. :)
Возможно и платные источники.
В первую очередь интересуют Футбол 1 и Футбол 2.
В начале статьи вы написали три проблемы. В итоге не решили ни одну из них, почему-то выбрав архитектуру, в которой p2p используется в последнюю очередь.
1. Автор, когда писал про то, что web RTC не поддерживается в Safari, оказался прав, однако есть решение в лице open source библиотеки Adapter.js — она упрощает работу с браузерными префиксами и позволяет транслировать видео даже в таких браузерах, как IE и Safari.
2. Когда автор писал, что web RTC хорошо работает, наверное, погорячился. Разве что только в Chome и когда 2-3 пользователя. Но когда дело доходит хотя до Firefox или у нас более 3-х пользователей, начинаются проблемы: иногда тупо не хватает мощности компьютера или пропускной способности сети — как итог, виснущий браузер и неадекватная передача аудио и видео.
Google предстоит проделать огромный объем работы, чтобы привести эту технологию в порядок. Я около года сижу на проекте, связанным с web RTC и он мне подарил немало седых волос) Но в любом случае технология очень интересная и перспективная.
2. Когда автор писал, что web RTC хорошо работает, наверное, погорячился. Разве что только в Chome и когда 2-3 пользователя. Но когда дело доходит хотя до Firefox или у нас более 3-х пользователей, начинаются проблемы: иногда тупо не хватает мощности компьютера или пропускной способности сети — как итог, виснущий браузер и неадекватная передача аудио и видео.
Google предстоит проделать огромный объем работы, чтобы привести эту технологию в порядок. Я около года сижу на проекте, связанным с web RTC и он мне подарил немало седых волос) Но в любом случае технология очень интересная и перспективная.
1. По моим сведениям стриминг без надстроек ограничен 255 пользователями в Web-rtc
2, Класс захвата видеоизображения кажется не использует перекодирование MJPEG в VP8/9, а это значит что выбирается несжатый поток, а как многие знают, USB 2.0 не может отдать в таком формате больше 1-5 кадров в секунду при разрешениях выше 800х600 включительно. Что это означает? Это и дает тот убогий эффект качества, что приходится видеть (640х480 25 fps). Для владельцев Mac и мобильных устройств это не критично — там интерфейсы имеют большую ширину канала и могут тянуть выше — лишь бы хватало мощности. Знатоков прошу проверить эту догадку.
3. Потребляемая мощность на работу web-rtc растет и да, действительно нужен серьезный компьютер.
2, Класс захвата видеоизображения кажется не использует перекодирование MJPEG в VP8/9, а это значит что выбирается несжатый поток, а как многие знают, USB 2.0 не может отдать в таком формате больше 1-5 кадров в секунду при разрешениях выше 800х600 включительно. Что это означает? Это и дает тот убогий эффект качества, что приходится видеть (640х480 25 fps). Для владельцев Mac и мобильных устройств это не критично — там интерфейсы имеют большую ширину канала и могут тянуть выше — лишь бы хватало мощности. Знатоков прошу проверить эту догадку.
3. Потребляемая мощность на работу web-rtc растет и да, действительно нужен серьезный компьютер.
Я бы посоветовал попробовать на транслирующем сервере nginx-rtmp модуль, вся работа будет напоминать работу со статикой (ретрансляции, балансировки, cdn… )
WebRTC пока же выглядит немного монструозным, все решения на стороне сервера быстро теряют актуальность, живут в основном обертки над openwebrtc и те, у которых браузерный движок внутри, chromium там и др. Желания не возникает на каждом легком воркере кормить почти целый браузер из-за казалось бы, каких то там udp коннектов.
Ну технологии и цели, конечно, тут разные
WebRTC пока же выглядит немного монструозным, все решения на стороне сервера быстро теряют актуальность, живут в основном обертки над openwebrtc и те, у которых браузерный движок внутри, chromium там и др. Желания не возникает на каждом легком воркере кормить почти целый браузер из-за казалось бы, каких то там udp коннектов.
Ну технологии и цели, конечно, тут разные
WebRTC пока же выглядит немного монструозным, все решения на стороне сервера быстро теряют актуальность, живут в основном обертки над openwebrtc и те, у которых браузерный движок внутри, chromium там и др. Желания не возникает на каждом легком воркере кормить почти целый браузер из-за казалось бы, каких то там udp коннектов.
Извините, но это полный бред.
Здесь уже отмечали проблему серверных решений и самого стандарта, поэтому не стал расписывать.
К примеру, меня интересуют реализации webrtc на go и js. Замечу, кстати, что это вроде бы далеко не последние языки для работы с сетью и протоколами и должны иметь не последнее значение для тех же google и других.
Возьмем полезную библиотеку simple-peer из статьи и просто установим для него актуальный wrtc модуль для nodejs, немного подождем (20-30 мин всего), заметим как в проект (к примеру, это был микросервис, которые вместе с ОС занимал 5-20 МБ) добавился зоопарк технологий на 256 МБ
Для golang достаточно открыть топовую либу go-webrtc и увидеть следующую строчку, чтобы понять, что все на том же уровне
«The hard way is to build from scratch, which involves Google's depot_tools and chromium stuff, gclient syncing, which takes a couple hours, and possibly many more if you run into problems...»
Не расписываю остальной вагон мертвых и любительских библиотек этого чудо стандарта, который гиганты дорабатывают годы (одновременно приторговывать turn серверами за углом), позволяющий в 21 веке передавать данные (на 5 компов без лагов) «прямо в браузере» (типа чудо вообще, не то что скайп или ртс-шутер какой нить на 100 человек)
К примеру, меня интересуют реализации webrtc на go и js. Замечу, кстати, что это вроде бы далеко не последние языки для работы с сетью и протоколами и должны иметь не последнее значение для тех же google и других.
Возьмем полезную библиотеку simple-peer из статьи и просто установим для него актуальный wrtc модуль для nodejs, немного подождем (20-30 мин всего), заметим как в проект (к примеру, это был микросервис, которые вместе с ОС занимал 5-20 МБ) добавился зоопарк технологий на 256 МБ
Для golang достаточно открыть топовую либу go-webrtc и увидеть следующую строчку, чтобы понять, что все на том же уровне
«The hard way is to build from scratch, which involves Google's depot_tools and chromium stuff, gclient syncing, which takes a couple hours, and possibly many more if you run into problems...»
Не расписываю остальной вагон мертвых и любительских библиотек этого чудо стандарта, который гиганты дорабатывают годы (одновременно приторговывать turn серверами за углом), позволяющий в 21 веке передавать данные (на 5 компов без лагов) «прямо в браузере» (типа чудо вообще, не то что скайп или ртс-шутер какой нить на 100 человек)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
P2P в браузере