При разработке видеоплатформы TSINGSEE Qingxi возможность потоковой передачи мультимедиа рассматривается очень всесторонне.При этом учитывается не только производительность в реальном времени, но также учитывается производительность сервера, нагрузка на пропускную способность сети, а также учитывается параллелизм.В этом разделе мы рассмотрим по запросу и без запроса. Потяните поток, чтобы объяснить еще раз.
Прежде чем объяснять, позвольте мне сначала рассказать вам популярную науку.Платформа потокового мультимедиа TSINGSEE Qingxi Video использует отличный дизайн разделения интерфейса и сервера, что позволяет профессиональным людям выполнять профессиональную бизнес-логику. Некоторые люди, должно быть, задаются вопросом, почему этот момент должен быть изложен в первую очередь? Благодаря такому дизайну мы можем рассматривать внешний интерфейс платформы потоковой передачи видео TSINGSEE Qingxi в качестве внешнего примера DEMO, и мы можем создать набор внешних страниц, чтобы заменить платформу потоковой передачи самостоятельно.
Вытягивать поток по запросу
Так называемый «вытягивающий поток по запросу» на самом деле буквально означает «вытягивать поток по мере необходимости». По необходимости, по сути означает, что есть клиентский запрос, то есть, когда есть клиентский запрос, служба потокового мультимедиа пойдет на фронтальное устройство для обработки потоковой передачи, pull streaming -> decapsulation -> repackaging - > распределение.Чтобы сохранить нагрузку на полосу пропускания, поскольку внешнее оборудование может быть подключено через беспроводную сеть, или нагрузка на переднюю сеть уже велика, преимущество этого заключается в том, что его можно вызвать в любое время. по мере необходимости для эффективного улучшения использования пропускной способности.
Однако этот метод также имеет некоторые недостатки, такие как медленная скорость запуска, потому что аудио- и видеоданные от кодирования устройства до декодирования проигрывателем и рендеринга в окно выполняются не все время, а только тогда, когда они вызывается по требованию.
потоковое вещание без запроса
Так называемый режим «не по запросу» на самом деле является режимом постоянного извлечения потока. Популярное объяснение состоит в том, что потоковое мультимедиа непрерывно извлекает аудио и видео с внешнего устройства. требования клиента, служба потокового мультимедиа продолжит тянуть поток -> Декапсуляция -> Переупаковка -> Распространение, этот метод неизбежно увеличит сетевое давление, потому что независимо от того, есть ли запрос на воспроизведение от клиента, сервер всегда приходится тянуть поток фронтальным устройством, но это можно сделать за секунды Открыть, т.к. клиенту нужно начать вещание в любой момент, а на сервере есть данные, поэтому нет необходимости ждать, пока предыдущее устройство завершит кодировать, передавать, декодировать, а затем получать потоковые данные.
Однако этот способ сильно нагружает сервер, т. к. сейчас декапсуляция -> реинкапсуляция делается в памяти (кроме HTTP-HLS), считается, что в памяти вытянуты и обработаны сотни аудио- и видеоканалов. Давление на сервер можно себе представить.
Потоковый параллелизм
Позвольте мне объяснить вам некоторые знания о параллельных возможностях потокового мультимедиа.
Ядро платформы потокового видео TSINGSEE Qingxi улучшено на основе Nginx, который может эффективно справляться с высоким одновременным доступом, но возможности параллелизма каждого распределенного потока протокола не одинаковы, например, HTTP-HLS такой поток распределения, на самом деле , это самое большое Узкое место параллелизма связано не с возможностями программирования, а с производительностью чтения и записи диска, поскольку HTTP-HLS не является настоящим протоколом потоковой передачи в строгом смысле. Загрузите этот ресурс, чтобы поиграть.
Технологии HTTP-FLV, WebSocket-FLV и WebRTC сейчас очень хороши, потому что после того, как FLASH постепенно устранен, действительно требуется немного усилий для воспроизведения потоков протокола RTMP в WEB либо с помощью других плагинов, либо с перекодированием. Поскольку все три вышеперечисленных потока воспроизведения обрабатываются в памяти, при условии, что производительность и пропускная способность сервера могут поддерживаться на должном уровне, проблем с возможностью параллелизма практически не возникает.