Реализация записи прямой трансляции в мобильном приложении

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1735 услуг
Реализация записи прямой трансляции в мобильном приложении
Средний
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    792
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    671
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1097
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    969
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    914
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    495

Реализация записи прямой трансляции в мобильном приложении

Записывать стрим «на лету» — значит параллельно кодировать один видеопоток в два места: на сервер (RTMP/SRT) и в локальный файл (MP4/MOV). Это не просто «сохранить то, что транслируется» — у RTMP и файловой записи разные требования к GOP-структуре, битрейту и опорным кадрам.

Проблема разделения потоков

На iOS наивный подход — запустить второй AVAssetWriter параллельно с энкодером трансляции. Не работает: VideoToolbox-сессию (VTCompressionSession) нельзя использовать одновременно в двух consumer-ах. При попытке получаете -12401 kVTVideoEncoderNotAvailableNowErr.

Правильный подход: один VTCompressionSession → закодированные CMSampleBuffer → fanout к двум writer-ам. Для этого после получения энкодированного буфера в VTCompressionOutputCallback пишем его и в RTMP-очередь, и в AVAssetWriter.

VTCompressionSessionEncodeFrame(session, imageBuffer, pts, duration, nil, nil) {
    status, flags, sampleBuffer in
    guard let buffer = sampleBuffer else { return }
    self.rtmpQueue.enqueue(buffer)       // → стрим
    self.fileWriterInput.append(buffer)  // → локальный файл
}

Оба вызова не должны быть синхронными на одном потоке — если RTMP-очередь заблокирована (сеть упала), fileWriterInput.append не должен ждать. Используем две независимые DispatchQueue.

Синхронизация аудио и видео в записи

Типичная проблема: аудио в MP4-файле съезжает относительно видео. Причина — AVAudioEngine и AVCaptureVideoDataOutput работают на разных таймлайнах. CMSampleBuffer из камеры использует kCMClockType_System, аудиобуферы — AVAudioTime с hostTime.

Решение: нормализуем все временные метки относительно CACurrentMediaTime() при старте записи, используем его как базовый clock. Для аудио — AVAudioSourceNode с явным AVAudioTime, для видео — CMSampleBufferGetPresentationTimeStamp минус смещение старта.

Дельта между аудио и видео в файле не должна превышать 40ms — это граница восприятия рассинхрона.

Запись через ReplayKit (альтернативный сценарий)

Если стрим идёт через ReplayKit (RPBroadcastSampleHandler), запись организуется иначе: обработчик получает RPSampleBufferType.video и RPSampleBufferType.audioApp — их можно параллельно писать в AVAssetWriter без собственного энкодера.

Ограничение: ReplayKit добавляет задержку 2–5 секунд к захвату. Для стрима экрана приемлемо, для камерного стрима — нет.

Управление хранилищем

Перед стартом записи проверяем доступное место:

let attrs = try FileManager.default.attributesOfFileSystem(forPath: NSHomeDirectory())
let freeSpace = attrs[.systemFreeSize] as? Int64 ?? 0
let estimatedSize = Int64(bitrate / 8) * expectedDurationSeconds
guard freeSpace > estimatedSize * 2 else { /* предупреждение */ }

Коэффициент 2 — запас под временные файлы AVAssetWriter и OS. При 4 Мбит/с час стрима занимает ~1.8 ГБ.

Сегментная запись (каждые 30 минут — новый файл) снижает риск потери данных при краше и упрощает последующую загрузку на сервер.

Сроки

Базовая параллельная запись (iOS, один поток): 1–1.5 недели. Полная реализация с синхронизацией A/V, управлением хранилищем, сегментацией, Android-поддержкой: 3–4 недели. Стоимость рассчитывается индивидуально.