Application architecture
- Большими стрелками указано перемещение данных о котором мы не заботимся, это происходит средствами SDK.
- Тонкими стрелками указано перемещение данных, которое мы должны организовать либо средствами выгрузки данных в userspace, либо манипуляций с указателями.
Условно можно разделить стриминг видео на две категории
- pull - клиент запрашивает какие-то данные и получает их из доступного пула. Обычно это конечный обьем данных, а не бесконечный live поток. Примеры: jpeg over http, HLS.
- push - клиенту запихиваются данные. Обычно это бесконечный поток данных. Примеры: rtsp/rtp, rtmp.
Push можно разделить на соединения иницируемые клиентом (rtsp, rtmp server) или сервером (rtmp push) по одной классификации. По другой классификации можно разделить по наличию обратной связи (контролю канала данных), примеры: rtp udp - отправили данные и забыли, не знаем доехало или нет (да и не важно это), rtp tcp - мы всегда точно знаем сколько данных уехало, а сколько в очереди.
Важно это в контексте того, что мы имеем дело с системой мягкого реального времени (существует разные виды реального времени можно почитать тут).
Понимать это нужно так: камера делает кадры постоянно, через равные промежутки времени. Допустим у нас идет захват изображения 25fps, т.е. каждые 40мс у нас генерируется кадр, он проходит через видео тракт и в конечном итоге мы имеем либо сырой кадр, либо закодированный. Эти данные помещаются в оперативную память. Оперативная память конечна и мы можем хранить только какое-то определенное кол-во таких данных, более старые будут вытеснены более новыми.
В такой системе нужно определять data serving strategy (сам придумал этот термин, не знаю как про это другие говорят), в основном это определение поведения системы в случае если клиент скачивает данные медленнее некой расчетной скорости и обращается к тем данным, которые уже были вытеснены или еще не вытеснены, но стали не актуальными (пример: 1ый кадр скачивали так медленно, что когда пришла очередь скачивать 2ой кадр у нас уже готов 5ый кадр для отправки).
В случаях pull & push стратегия может быть разной, так же в зависимости от кейса использования по разному определяется ценность данных, т.е. в случае видео конференции неактуальные данные не имеют ценности, а в случае удаленной видеорегистрации данные имеют ценность даже при задержке.
Система доставки должна придерживаться понятной и формализованной стратегии, а имплементация должна быть полностью детерменированной, не зависимо от поведения внешних, не управляемых, факторов.
Кстати это относится не только к взаимодействию с клиентами, но и в случаях где мы делаем обработку кадров, там где обработка не принебрежительно мала по времени.
Никаких "закольцованных" зависимостей и глобальных переменных, каждый package полностью инкапсулирует свой функционал и предоставляет управление через свои интерфейсы/методы.