Каков алгоритм современного стриминга?
Один кадр: 1920px * 1080px * 24bpp = 49'766'400bit 
В Base64: 49'766'400bit / 6 * 8 = 66'355'200bit
Весь поток: 66'355'200bit * 30fps = 1'990'656'000bps
То есть, вам понадобится полоса пропускания ~2 гигабита в секунду.
Всё-таки разработчики видеокодеков не зря свой хлеб едят.
Вы вроде как задаете вопрос, но когда вам отвечают то, что не просто не сходится с вашим предположением, а противоречит ему, вы встаете в позу, будто у вас есть реальные основания быть уверенным в правильности вашего предположения. Сами себе противоречите...
Уясните для себя некоторые моменты:
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-а.