Обойти ограничение в 6 скачиваний для просмотра нескольких видео - PullRequest
Новая
       52

Обойти ограничение в 6 скачиваний для просмотра нескольких видео

3 голосов
/ 25 марта 2020

Мне нужно кодировать веб-сайт с возможностью одновременного просмотра нескольких потоков (камер видеонаблюдения).

Пока что я использую MJPEG и JS для воспроизведения вживую. видео, и оно работает хорошо ... будь только до 6 потоков!

Действительно, я застрял с ограничением в 6 параллельных загрузок, которое есть в большинстве браузеров ( ссылка ).

Кто-нибудь знает, как обойти этот лимит? Есть ли совет?

Пока что у меня есть варианты:

  • увеличить лимит (возможно только на Firefox), но я не люблю возиться с моими пользовательские настройки браузера

  • объединяют потоки в один большой поток / видео на стороне сервера, так что я могу одновременно загрузить их. Но тогда я не смогу иметь дело с каждым потоком индивидуально, не так ли?

  • Переключиться на поток JPEG и разобраться с очередью изображений для обновления на лицевой стороне (но если я скажу 15 потоков, я боюсь, что при запросах (15x25 изображений / с) я сверну свой клиентский браузер

У меня есть другие варианты? Есть ли совет или, например, библиотеку, могу ли я объединить свой поток в один большой канал (таким образом, 1 загрузка за один раз), но иметь доступ к каждому из них отдельно в переднем коде?

Я уверен, что я нахожусь на прямо на сайте обмена стека, чтобы спросить это, если я не, пожалуйста, скажите мне; -)

Ответы [ 2 ]

3 голосов
/ 25 марта 2020

Почему бы не поток (если у вас есть контроль над серверной стороной и способной линией) в одном соединении? Вы делаете один запрос на отправку / потоковую передачу всех 15 потоков в одном соединении (не один большой поток), поэтому заголовки каждого чанка должны соответствовать соответствующему идентификатору потока.
Подробнее: http://qnimate.com/what-is-multiplexing-in-http2/
Более подробно здесь: https://hpbn.co/http2/
С http1.0 / 1.1 вам не повезло в этом сценарии - тогда, когда разрабатывался один видео или mp3 файл, был уже тяжелым вещи (обходные пути, где, например, торрент-библиотеки, но ненадежные и не подходят для большинства сценариев ios, кроме простой загрузки / потоковой передачи). Для вашего интерактивного сценария http2 - это путь к go imho.

1 голос
/ 25 марта 2020

Как сказал Codebreaker007, я бы тоже предпочел мультиплексирование потоков HTTP2. Он специально разработан, чтобы обойти проблему слишком большого количества одновременных соединений.

Однако, если вы застряли с HTTP1.x, я не думаю, что вам не повезло. Можно объединить потоки таким образом, чтобы клиентская часть могла деструктурировать и управлять отдельными потоками, хотя по общему признанию это требует немного больше работы, и вам, возможно, придется прибегнуть к опросу на стороне клиента.

Идея состоит в том, просто - определить действительно простую структуру данных:

[streamCount len1 data1 len2 data2 ...]

Байт 0 ~ 3: 32-bit unsigned int количество объединенных потоков

байт 4 ~ 7: 32-bit unsigned int длина данных потока 1

байт 8 ~ 8 + len1: binary данные потока 1

Байт 8 + len1 + 1 ~ 8 + len1 + 4: длина данных потока 2

...

Каждый data может иметь длину 0, и в этом случае обрабатывается не иначе.

На стороне клиента непрерывно опрашивайте для получения дополнительных данных, ожидая эту структуру данных. Затем деструктурируйте его и направьте данные в буфер отдельных потоков. Тогда вы все равно сможете управлять потоками компонентов по отдельности.

На стороне сервера кэшируйте данные из отдельных потоков компонентов в памяти. Затем в каждом ответе очищайте кеш, составляйте эту структуру данных и отправляйте.

Но, опять же, это очень гипсовое решение. Я бы также порекомендовал использовать поток HTTP2, но это был бы разумный запасной вариант.

...