Есть два врианта - для браузеров - это
WebRTC,
nginx-rtmp и их аналоги.
Не для браузеров - это протоколы H323 и SIP + специальный софт либо специальное железо.
Тут можно очень долго расписывать и рассказывать как что устроено, очень много нюансов. Так как это все выросло из телефонии, в технологии есть много общего с ней, например, разделение на "сигнализацию" и контент:
Имеется отдельный протокол (webRTC, H323, SIP), который отвечает за передачу метаданных и настройку соединения и отдельный протокол (RTP), отвечающий за сам медиапоток (аудио отдельно, видео - отдельно)
Сигнализация, как правило, работает по TCP, медиаданные, как правило, идут по UDP. Использование UDP связано с тем, что потеря нескольких пакетов никак не влияет на поток медиаданных (ну заикнется собеседник, или картинка размажется).
Архитектура для трансляции в браузер примерно такая
1) Источник медиаданных - файл, поток с видеокамеры/микрофона, микс из захвата экрана и камеры (obs-studio)
2) Транскодер(ы) - решение, которое перекодирует исходный поток в несколько выходных форматов
- с разным разрешением
- с разным кодеком, для лучшей совместимости с устройствами. Например, старный iPhone кушает только вполне конкретный профиль h264, а машине с линуксом лучше подавать VP8, потому что h264 нужно доустанавливать руками - он проприетарный.
3) Сервер(ы) вещания - это может быть nginx-rtmp, icecast или что-то проприетарное. Они как раз обеспечивают выдачу медиапотока в нужном виде - HLS (формат Apple, его кушают старые iPhone, WebM - почти универсальный формат, жрут все современные браузеры, WebRTC - еще более универсальный формат)
Для того, чтобы максимально охватить аудиторию, нужно поддерживать несколько форматов изображения (разные кодеки, разные разрешения) и несколько форматов вещания.
Простой
Сложный
