Расскажите про задачу с виртуальными камерами и RTSP сервером
Что проверяют
Настоящий ли у вас опыт с видеопайплайном или пересказ статьи. Вопрос точечный, поэтому сразу пойдут уточнения про транспорт, тайминги и то, где терялись кадры.
Как отвечать
Сначала разведите понятия, это половина ответа. RTSP это управляющий протокол: DESCRIBE, SETUP, PLAY, TEARDOWN, описание потока приходит в SDP. Сами кадры едут в RTP, поверх UDP или вложенными в то же TCP-соединение, а статистика и привязка к общим часам идут в RTCP.
Дальше скажите, что у вас называлось виртуальной камерой. Вариантов два, и они очень разные: устройство в системе, которое видят обычные приложения (v4l2loopback на Linux, плагин захвата на macOS, виртуальная камера на Windows), либо просто источник, который отдаёт синтетическое видео на сервер. Во втором случае ни драйвера, ни ядра не нужно.
Потом по существу: чем кодировали, кто был сервером (свой на базе библиотеки потоковой передачи, готовый gst-rtsp-server, live555), сколько потоков держали одновременно, где упирались. Узкие места в C++ тут обычно не в алгоритме, а в лишних копиях кадра, аллокации буфера на каждый кадр и в том, что кодировщик живёт в одном потоке с захватом.
Где спотыкаются
Говорят «передавали видео по RTSP» и не могут ответить, что лежит в пакетах. Про RTP, SDP и разницу между UDP и режимом поверх TCP молчат, хотя именно этот выбор определяет поведение за NAT и в плохой сети.
Не упоминают время. Без меток каждого кадра и отчётов отправителя несколько камер разъедутся между собой, даже если каждая по отдельности работает идеально.
Приносят метрику вроде «эффективность передачи выросла на 30%». Такой величины не существует, спросят определение и её не окажется. Измеримое здесь другое: задержка от захвата до отображения в миллисекундах, доля потерянных пакетов, число пропущенных кадров, память и процессор при нескольких потоках.