Использовали ли сокеты для стриминга видео в приложении
Что проверяют
Понимаете ли вы, какой транспорт подходит для видео при разных требованиях к задержке, или «сокеты» для вас универсальный ответ. Следом обычно спрашивают, как вы боролись с плохой сетью и что происходит со стримом при уходе приложения в фон.
Как отвечать
Начните со своей задачи: что стримили (звонки, трансляции, камеру наблюдения), какая задержка была допустимой, какая аудитория. Цифры приводите свои: задержка, доля обрывов, расход батареи. Если сокетами видео вы не передавали, скажите честно, расскажите, чем пользовались, и как подошли бы к задаче.
Каркас выбора транспорта:
- HLS: стандарт Apple,
AVPlayerиз коробки, адаптивный битрейт, CDN. Задержка в секундах, у Low-Latency HLS меньше; для VOD и трансляций это выбор по умолчанию; - WebRTC: задержка меньше секунды, медиа идёт по UDP через SRTP, а ICE, STUN и TURN обходят NAT. WebSocket здесь нужен только для сигналинга, обмена SDP и кандидатами. Обычно работают через SFU-сервер или готовый SDK вроде LiveKit;
- свои сокеты:
NWConnectionиз Network.framework для TCP и UDP,URLSessionWebSocketTaskдля WebSocket. Тогда кодирование через VideoToolbox (VTCompressionSession, H.264 или HEVC), упаковка кадров, джиттер-буфер и вывод черезAVSampleBufferDisplayLayerложатся на вас.
Отдельно скажите об устойчивости: NWPathMonitor для перехода между Wi-Fi и сотовой сетью, переподключение с растущей паузой, фон (без режима фонового аудио или PiP через AVPictureInPictureController система вскоре приостановит приложение и соединение оборвётся), нагрев и расход батареи при долгом кодировании.
Где спотыкаются
Говорят, что WebRTC работает «через WebSocket» или через Starscream. Это путает сигналинг с передачей медиа.
Гонят кадры картинками по WebSocket поверх TCP. Одна потеря пакета задерживает всё, что идёт следом, задержка копится, а битрейт не адаптируется.
Не думают о жизненном цикле: сеть сменилась, приложение ушло в фон, пришёл звонок, а стрим висит без восстановления и без понятного состояния для пользователя.