Каков алгоритм современного стриминга?

Question

[LemanRass21]

Здравствуйте.
Я сейчас нахожусь на стадии планирования деталей реализации своего будущего сервиса в котором один человек сможет стримить видеопоток со своей камеры множеству зрителей прямо из браузера через сервер написанный на node.js.
У меня сложилось некоторое представление о том как оно должно работать, но на всякий случай хотел бы услышать конструктивную критику других разработчиков относительно моих набросков деталей реализации.

1. Вначале я получаю видеопоток в браузере «стримера» с его вебки посредством navigator.getUserMedia.
2. Затем я отрисовываю данные из объекта MediaStream в тэг video.
3. Затем изображение из тэга video я передаю в тэг canvas через его context что бы после этого иметь возможность выдергивать кадры из видеопотока цельными а не вперемешку с данными других кадров которые идут по порядку.
4. Затем с некой периодичностью (например 30 раз в секунду) я вытягиваю по 1 цельному кадру из канваса в виде base64 текста и отправляю их на сервер через socket.io.
5. На сервере я получаю каждый кадр и отправляю всем клиентам, которые являются зрителями и в свою очередь отображают эти кадры например в таком же канвасе.

Меня интересует не является ли необходимым как то сжимать кадры перед отправкой на сервер или то, что они приходят в виде base64 строки уже является свидетельством того что они уже сжаты? Если надо еще, то как?
И в целом по алгоритму хотелось бы знать ваше мнение. Как такие задачи принято решать качественно?

Comments

[sim3x]

0. Какое отношение стриминг имеет к браузеру?
1. Какой оверхед имеет бейз64?

[LemanRass21]

sim3x, 0. стриминг подразумевает передачу видеопотока из записывающего устройства неким зрителям. Почему это не может быть реализовано через браузер? Браузер это тоже приложение на компе как и OBS например. А вас сильно удивляет когда на современных часах принимают звонки?
1. Судя по тому что я сейчас нагуглил оверхед в районе 30%

[sim3x]

LemanRass21,

0. Правильно. Раз вы понимает, что на сервер передается уже видео (а не картинки), то идея получать от браузера с посощью жс картинки через не регулярные промежутки времени отпадает

1. Верно. И зачем вам такой оверхед к тому что уже было написано мною выше?

Answer 1

[Rsa97]

Один кадр: 1920px * 1080px * 24bpp = 49'766'400bit
В Base64: 49'766'400bit / 6 * 8 = 66'355'200bit
Весь поток: 66'355'200bit * 30fps = 1'990'656'000bps
То есть, вам понадобится полоса пропускания ~2 гигабита в секунду.
Всё-таки разработчики видеокодеков не зря свой хлеб едят.

Comments

[LemanRass21]

Спасибо за информацию. Но у вас не будет случайно советов относительно того какое решение выбрать для сжатия изображений до отправки на сервер?

[Rsa97]

LemanRass21, Если серъёзно стримить, то OBS. Если так, побаловаться, то WebRTC

[LemanRass21]

Таково задание от заказчика

[Moskus]

LemanRass21, вот это

Я сейчас нахожусь на стадии планирования деталей реализации своего будущего сервиса в котором один человек сможет стримить видеопоток со своей камеры множеству зрителей прямо из браузера

и вот это

Таково задание от заказчика

- не сходится. Вы теперь решили свалить всё на "заказчика" или сначала соврали про "свой" сервис для чего-то? Прекращайте выкручиваться и огрызаться.

Answer 2

[Moskus]

Вы вроде как задаете вопрос, но когда вам отвечают то, что не просто не сходится с вашим предположением, а противоречит ему, вы встаете в позу, будто у вас есть реальные основания быть уверенным в правильности вашего предположения. Сами себе противоречите...
Уясните для себя некоторые моменты:
1. Передача данных видео на сервер требует оптимизации этого процесса в сторону уменьшения объема передаваемых данных, для чего, традиционно и не без причины, применяются кодеки видео, которые сжимают его не только пространственно (в пределах одного кадра) но и темпорально (внутри последовательности кадров).
2. Если вы считаете, что "у всех быстрый интернет и можно не заботиться о сжатии", то логика вам чужда и дальше можете не читать, если не считаете, то читайте дальше.
3. То, что вы даже предполагаете вот это:

то, что они приходят в виде base64 строки уже является свидетельством того что они уже сжаты

но потом соглашаетесь с тем, что оверхед у base64 - 30%, как-то не укладывается в одну картину, потому что base64 ничего не сжимает, а наоборот - увеличивает объем.
4. Если вы собираетесь упаковывать в base64 еще и несжатый bitmap, легко посчитать, используя школьный курс арифметики, что одна секунда видео 1024×768(пикс)×3(байта RGB)×30(кадров/сек)×1.3(base64 overhead) будет весить "немного дофига".
5. Если сказанное выше вас убедило, могу предложить вам иной подход: прочесть, например, вот эту статью https://blog.cloudboost.io/how-to-run-node-js-apps... и подумать над тем, чтобы запускать приложение Node.js в browser-е пользователя, и чтобы это приложение использовало, например, handbrake https://github.com/75lb/handbrake-js
Правда, меня "гложат смутные сомнения" по поводу того, что компрессия видео для стриминга в клиентском browser-е будет действительно сравнима по производительности с кодеками, которые используются нативными приложениями.
6. Ваша контр-аналогия с приемом звонков через часы (из комментариев) - неверна, потому что проблема не в формальном назначении browser-а и streaming-клиентов, а во вполне реальных возможностях. И нет, browser - не "такое же" приложение, как клиент для streaming-а.

Comments

[LemanRass21]

Из вашего комментария я понял что:
1. Я не воспитанный человек и мои ответы являются слишком резкими по отношению к другим людям чьи комментарии я счел недостаточно информативными по отношению к проблематике вопроса в этой теме.
2. Вас очень позабавило что я на момент написания поста думал что base64 сжимает файл а когда у меня напрямую спросили за оверхед я загуглил и понял что я ошибаюсь. Вы решили не пройти мимо дабы не мокнуть меня лицом в мою ошибку. Надеюсь вам удалось самоутвердиться.
3. Вы сказали что сжатие необходимо и я с создания поста тоже об этом догадывался единственное что я ложно предполагал что base64 и сожмет (вперед, можете еще раз на этот счет самоутвердиться если для вас это настолько необходимо. Я признаю, тут я облажался). Но я надеялся что мне предложат библиотечку или алгоритм как мне правильным образом сжимать на стороне клиента и вы предложили:
4. Вы предложили развернуть на клиенте (прямо в браузере) node.js для того что бы воспользоваться пакетом из npm который вроде как умеет сжимать видео....а операционную систему мне не развернуть у клиента в браузере что бы воспользоваться ее преимуществами для сжатия видео? А в ней прямо сразу и OBS предустановленное что бы было...
5. Вы считаете что браузер, раз он для этого не был изначально создан, значит он с этим не справится. Полная чепуха. Есть полно приложений для видеоконференций которые помимо скачиваемых клиентов имеют еще и веб клиент. К примеру Discord.

[Moskus]

LemanRass21, пункт 1 - вообще мимо, я вам про ваше воспитание ничего не говорил, говорил про вашу непоследовательность. От нее вам хуже, а не другим.
2 - не судите о мотивах других, когда вы об этом не знаете ничего, так что опять мимо. И вы как-то остро реагируете - вам что, в детстве мама никогда на ошибки не указывала и всегда говорила, что вы - молодец, потому что старались (это предложение)? У вас с этим будет дальше много проблем.
Указанное мной противоречие ясно говорит, что вам нужно постараться перепроверить свои представления о задаче и устранить неточности и противоречия, для чего достаточно Википедии и калькулятора.
3 - да, я вам предложил вариант (совершенно не гарантируя, что он хороший), который реализует сжатие на клиенте средствами JS, что всё ещё удовлетворяет вашему требованию, чтобы все работало в browser-е на JS. Благодаря этому, вы начали понимать громоздкость и абсурдность этого пути реализации. Сюрприз, в том числе исключением вариантов обычно приходят к оптимальному решению.

[LemanRass21]

Moskus, как по мне вы просто являетесь некомпетентным в этом вопросе но в виду вашего большого мнения о себе решили все равно всунуть свои 5 копеек даже если там разъем для 25. Сначала вы советуете плохой план для реализации, а потом вы сами признаете что он плохой. Зачем советовать человеку заведомо провальный алгоритм? Вы не на зачете, здесь не обязательно сказать хоть что-то что бы поставили зачет. Если вы не знаете как решить задачу хорошо - вы всегда можете пройти мимо. Как решить задачу плохо я и без вас знаю

[Moskus]

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