Блог

У меня есть этот Nuxt SPA. Он содержит два элемента img, каждый из которых передает URL-адрес конечной точке потоковой передачи (с использованием GET). К каждому элементу img прикреплен счетчик, и его номер обновляется при каждом событии «onload». Конечная точка расположена на сервере Flask и работает путем потоковой передачи кадров (изображений в формате PNG), извлеченных из видеофайла (с использованием OpenCV), с использованием generators, yield и MIME-типа multipart /x-mixed-replace. В основном то же самое, что и метод, описанный в: https://blog.miguelgrinberg.com/post/video-streaming-with-flask

Это работает без проблем, моя проблема сейчас — производительность. Если работает только один поток (один запрос GET, одно соединение), с точки зрения производительности все в порядке. Но когда два потока работают параллельно (два запроса GET, два входящих соединения одновременно), приложение испытывает трудности и очень сильно отстает: оно зависает при отображении одного кадра, обновлении счетчика. Затем через некоторое время счетчик быстро увеличивается примерно на 100 и отображает кадр на 100 или около того кадров вперед от предыдущего. Это происходит поочередно между 2 элементами img. Таким образом, элемент 1 загрузит 100 или около того, затем зависнет, затем элемент 2 сделает то же самое и заморозит, промоет и повторит.

У кого-нибудь есть идея, что может вызвать это? Мне нужно повысить производительность, чтобы оба «потока» могли выполняться одновременно без таких безумных задержек.

Я думаю, что это могут быть два соединения, конкурирующие друг с другом, поэтому я подумывал о том, чтобы вместо этого отправить несколько запросов GET. Ответом будет пакет (массив), состоящий, скажем, из 100-200 кадров. Затем функция в приложении будет воспроизводить кадры со скоростью 30 кадров в секунду или около того. Как только массив станет почти пустым, он отправит новый запрос GET для следующей партии фреймов. Промойте и повторите, и делайте это поочередно между 2 элементами img.

Как вы думаете, это облегчит проблему? Или я решаю не ту проблему?

На это трудно ответить подробно, не рассматривая точные HW и SW, используемые на клиенте, поскольку существует множество факторов, таких как пропускная способность, возможность параллельного запуска нескольких потоков, оптимизация выборки в браузерах, кодеки HW vs SW и т.д., Которые могут повлиять на производительность.

Тем не менее, одна вещь высокого уровня, которая может помочь, если вы сможете использовать ее для своего варианта использования, — это попытаться использовать существующие оптимизации, которые есть у многих серверов и клиентов для потоковой передачи и воспроизведения видео.

Другими словами, учитывая, что ваш источник по сути представляет собой поток видеокадров, если вы можете объединить их в «фактический» видеопоток, тогда браузер может просто запросить этот видеопоток, а сервер может просто обслуживать видео.

Это позволяет использовать все встроенные механизмы для загрузки видео «порциями», используя запросы диапазона и / или потоковую передачу с адаптивной скоростью передачи данных.

Клиент также сможет использовать существующие механизмы буферизации и воспроизведения видео.

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