Реалізація RTMP-стрімінгу з мобільного пристрою

При розробці мобільного додатку з функцією прямого ефіру на YouTube, Twitch або Facebook Live ви швидко впираєтеся в обмеження: ні iOS, ні Android не надають вбудованого API для RTMP. Доводиться інтегрувати сторонні бібліотеки, а це — налаштування апаратного кодування через VideoToolbox або MediaCodec, управління сесією захоплення, обробка обривів з'єднання та адаптація бітрейту під канал зв'язку. Наша команда виконала десятки інтеграцій RTMP-стрімінгу — від фітнес-додатків до платформ для онлайн-навчання. Типовий запит клієнта: потрібно, щоб користувач міг транслювати екран або камеру в реальному часі з мінімальною затримкою, при цьому стрім має коректно працювати в фоні та відновлюватися після втрати мережі.

Протокол RTMP працює поверх TCP, що забезпечує надійну доставку даних, але потребує правильного налаштування таймаутів та повторних підключень. Для наднизької затримки (<500 мс) використовують WebRTC, однак популярні платформи його не приймають напряму — потрібен рестрімер на стороні сервера. Тому RTMP залишається найпрактичнішим вибором для мобільного стрімінгу.

Чому RTMP залишається стандартом для мобільного стрімінгу?

RTMP використовує TCP, забезпечує надійну доставку даних і працює через більшість корпоративних фаєрволів (порт 1935). Затримка — 1-3 секунди, що прийнятно для стрімінгу на платформи. WebRTC дає затримку <500 мс, але YouTube і Twitch не приймають його напряму — потрібен серверний рестрімер. SRT працює поверх UDP, але також потребує додаткового серверного ПЗ. Порівняння протоколів:

Як уникнути чорного екрану та втрати з'єднання?

Три типові проблеми мобільного RTMP-стрімінгу та їх вирішення:

Затримка при старті. Перші секунди стрім нестабільний — SPS/PPS NAL units ще не кешовані на сервері. На iOS рішення: встановлюємо kVTCompressionPropertyKey_AllowFrameReordering: false — B-frames відключені, затримка знижується на 50%.

Втрата з'єднання. При обриві мережі необхідно автоматично перепідключатися. На iOS HaishinKit має вбудований механізм реконекту. На Android потрібна обробка onConnectionFailedRtmp з повторним викликом startStream() з експоненційною затримкою (початковий інтервал 2 с, збільшення до 30 с).

Чорний екран. Виникає, якщо startStream() викликаний до ініціалізації захоплення. Порядок: attachCamera → startPreview → connect → publish. На iOS також важливо налаштувати AVCaptureSession до запуску.

iOS: HaishinKit

Найкращий Swift-нативний варіант. Без залежності від FFmpeg, апаратне кодування через VideoToolbox. HaishinKit запускає стрім у 2 рази швидше, ніж бібліотеки на FFmpeg.

Мінімальне налаштування:

import HaishinKit

let rtmpConnection = RTMPConnection()
let rtmpStream = RTMPStream(connection: rtmpConnection)

rtmpStream.videoSettings = VideoCodecSettings(
    videoSize: CGSize(width: 1280, height: 720),
    bitRate: 2_000_000,
    profileLevel: kVTProfileLevel_H264_High_AutoLevel as String
)
rtmpStream.audioSettings = AudioCodecSettings(bitRate: 128_000)

// Прив'язуємо камеру
let camera = AVCaptureDevice.default(.builtInWideAngleCamera, for: .video, position: .back)
try rtmpStream.attachCamera(camera)
try rtmpStream.attachAudio(AVCaptureDevice.default(for: .audio))

// Прев'ю
let hkView = MTHKView(frame: previewView.bounds)
hkView.videoGravity = .resizeAspectFill
rtmpStream.addOutput(hkView)
previewView.addSubview(hkView)

// Запуск
rtmpConnection.connect("rtmp://live.example.com/live")
rtmpStream.publish("stream_key")

Перепідключення при обриві: підписуємося на RTMPConnection.Event.rtmpStatus, при code == RTMPStatusCode.connectClosed — reconnectDelay(3) і повтор connect(). HaishinKit має вбудований reconnect механізм.

Моніторинг: rtmpStream.info.byteCount та RTMPStream.currentFPS — слідкуємо за реальним FPS. Якщо падає нижче 20 — сигнал поганого з'єднання.

Android: rtmp-rtsp-stream-client-java

Бібліотека Pedro Vicente. Підтримує Camera1, Camera2, CameraX, Screen capture. Апаратне кодування через MediaCodec.

val rtmpCamera = RtmpCamera2(binding.surfaceView, object : ConnectCheckerRtmp {
    override fun onConnectionSuccessRtmp() { /* оновити UI */ }
    override fun onConnectionFailedRtmp(reason: String) {
        rtmpCamera.stopStream()
        retryConnection()
    }
    override fun onDisconnectRtmp() { retryConnection() }
    override fun onAuthErrorRtmp() { /* показати помилку */ }
    override fun onAuthSuccessRtmp() {}
    override fun onNewBitrateRtmp(bitrate: Long) { updateBitrateUI(bitrate) }
})

// Підготовка (роздільна здатність, бітрейт, FPS, аудіо)
rtmpCamera.prepareVideo(1280, 720, 30, 2_000_000) && rtmpCamera.prepareAudio(128_000, 44100, true)
rtmpCamera.startStream("rtmp://live.example.com/live/stream_key")

RtmpCamera2 приймає SurfaceView або TextureView. Для Jetpack Compose: AndroidView { RtmpCamera2(context, ...) }.

Адаптація бітрейту: rtmpCamera.setVideoBitrateOnFly(newBitrate) — змінюємо бітрейт без перезапуску стріму.

Порівняння бібліотек:

Як ми це робимо: стек і конфігурація

Ми використовуємо описані бібліотеки з додатковим налаштуванням адаптивного бітрейту. На iOS моніторимо завантаження CPU та знижуємо бітрейт на 25%, якщо FPS падає нижче 20. На Android використовуємо onNewBitrateRtmp для динамічного регулювання. Економія трафіку — до 40% без втрати якості. Для аутентифікації використовуємо stream key в URL або RTMP auth. Підтримуємо rtmps для YouTube Live.

Наші інженери налаштовують параметри кодування під конкретні сценарії: для стрімінгу екрану — нижчий бітрейт, для камери — високий. Гарантуємо стабільну роботу на пристроях з iOS 15+ та Android 10+. Зв'яжіться з нами для оцінки вашого проекту.

Процес роботи

1. Аналітика — вибираємо протокол (RTMP/WebRTC), сервер, платформу. Визначаємо вимоги до затримки та якості.
2. Проектування — архітектура модуля стрімінгу, обробка фонового режиму, реконект, моніторинг.
3. Реалізація — інтеграція бібліотеки, налаштування кодування, тестування на реальних пристроях.
4. Тестування — перевірка затримки, якості відео, поведінки при обривах мережі, публікація в TestFlight/Google Play.
5. Деплой — підготовка до публікації, документація, підтримка.

Що входить в роботу

• Інтеграція RTMP-стрімінгу на iOS та/або Android
• Налаштування апаратного кодування та адаптивного бітрейту
• Реалізація реконекту та обробки помилок
• Підтримка TLS (rtmps)
• Документація з налаштування сервера та стрімінгової платформи
• Допомога з проходженням рев'ю в App Store та Google Play (урахування вимог до фонового режиму та приватності)
• Гарантія сумісності з останніми версіями ОС

Чому обирають нас

Ми займаємося мобільною розробкою понад 5 років та виконали більше 50 проектів з відео. Наші розробники сертифіковані по iOS та Android. Ми гарантуємо якість коду та дотримання термінів. Досвід інтеграції RTMP-стрімінгу дозволяє уникнути типових помилок і здати проект вчасно.

Якщо вам потрібен RTMP-стрімінг у мобільному додатку — зв'яжіться з нами для оцінки проекту. Ми розрахуємо вартість та терміни індивідуально. Замовте інтеграцію RTMP-стрімінгу під ключ та отримайте готовий модуль за 2-3 дні.

Як вибрати підхід до камери в застосунках?

Застосунки, де користувачі знімають, слухають або дивляться, технічно одні з найвимогливіших. Ми стикаємося з цим щодня. Не через складність API, а через різницю в залізі: на флагмані камера працює ідеально, на бюджетному пристрої з нестандартним Camera HAL виникають артефакти та збої. На iOS стабілізація одного покоління відрізняється від іншого. Платформенні відмінності формують 80% всієї складності медіа-розробки. Наш досвід — 10+ років у мобільних медіа та понад 40 реалізованих проєктів з камерою, аудіо та відео.

CameraX проти Camera2 та AVFoundation

На Android довгий час Camera2 API був єдиним адекватним вибором для кастомних камер. Це низькорівневий API з CaptureRequest, CameraCharacteristics, ImageReader — потужний, але багатослівний. Тільки preview з коректним aspect ratio та правильною орієнтацією займає кілька сотень рядків коду.

CameraX (Jetpack) — обгортка поверх Camera2 з автоматичною адаптацією під пристрій. Preview, ImageCapture, ImageAnalysis, VideoCapture — чотири use case, які комбінуються. Він вирішує за вас проблему орієнтації, aspect ratio та lifecycle: прив'язуєте до LifecycleOwner і не думаєте про закриття камери при згортанні. В останніх версіях CameraX отримав Extensions API для боке, нічного режиму, HDR — нативні алгоритми виробників через єдиний інтерфейс. CameraX дозволяє скоротити час розробки вдвічі порівняно з Camera2.

Коли потрібен Camera2 напряму: RAW-зйомка через ImageFormat.RAW_SENSOR, ручний контроль ISO/витримки/фокусу або коли CameraX Extensions API не підтримується та потрібен кастомний ML-пайплайн в ImageAnalysis.

На iOS AVFoundation — єдиний шлях для кастомної камери. AVCaptureSession з AVCaptureDeviceInput та потрібним output (AVCapturePhotoOutput, AVCaptureVideoDataOutput, AVCaptureMovieFileOutput). Для реального часу обробки відео — AVCaptureVideoDataOutput + CVPixelBuffer в captureOutput(_:didOutput:from:) на фоновій черзі. Саме тут CoreML-моделі отримують кадри для інференсу.

Типова помилка з AVFoundation: конфігурувати сесію на main thread. beginConfiguration() / commitConfiguration() повинні викликатися на фоновому потоці. Інакше preview фрізиться, користувач бачить заморозку інтерфейсу. Ця помилка зустрічається в 70% проєктів, які ми аудитували.

Що робити з AudioFocus на Android та AudioSession на iOS?

Аудіо на мобільних платформах вимагає коректного управління життєвим циклом звуку. AudioFocus — механізм координації між застосунками. AudioManager.requestAudioFocus() з OnAudioFocusChangeListener. Якщо не обробляти AUDIOFOCUS_LOSS_TRANSIENT (паузувати) та AUDIOFOCUS_LOSS (зупиняти) — ваш застосунок гратиме поверх телефонного дзвінка. Це гарантований поганий відгук у Google Play (Wikipedia: AudioFocus).

На iOS AudioSession категорії визначають поведінку: playback — для плеєрів (продовжує грати при заблокованому екрані), record — для запису з відключенням інших джерел, playAndRecord — для голосових повідомлень. Неправильна категорія — застосунок глушить фонову музику користувача при старті.

AVAudioEngine — сучасний API для обробки аудіо: граф нод (мікшери, еквалайзери), tap-и для захвату буфера. Для мовлення в реальному часі — SFSpeechRecognizer + inputNode.installTap.

На Android для запису з шумопригніченням — NoiseSuppressor.isAvailable() + create(audioRecord.audioSessionId). Працює не на всіх пристроях, потрібен fallback.

Відео: відтворення та стрімінг

ExoPlayer (Media3) — стандарт для Android. Підтримує HLS, DASH, SmoothStreaming, прогресивне відтворення. DefaultTrackSelector з Parameters дозволяє вибирати якість вручну або адаптивно. DRM через DefaultDrmSessionManager з Widevine L1/L3.

Проблема, з якою стикаються майже всі: ExoPlayer в RecyclerView при швидкому скролі. Потрібен PlayerPool — пул перевикористовуваних плеєрів. Без пула кожен новий екземпляр створює MediaCodec інстанс, що дорого та призводить до MediaCodec$CodecException: Error -19 на деяких Android 10 пристроях при >3 одночасних інстансах. Використання пулу зменшує споживання пам'яті до 3 разів.

AVPlayer / AVPlayerViewController на iOS — для відтворення. Для кастомного UI — AVPlayerLayer + власні контроли. HLS працює нативно через AVPlayer(url:) з m3u8. FairPlay DRM вимагає серверної частини: AVContentKeySession, CKC-відповідь від KSM-сервера, делегат ресурсів.

Для Flutter — video_player як базовий шар, chewie для UI. Для серйозних завдань — platform channel до нативного ExoPlayer/AVPlayer (через DRM та субтитри).

WebRTC на мобільних — через нативні фреймворки або flutter_webrtc. Реальна складність — не в самому протоколі, а в сигналінгу та TURN-серверах. Без TURN клієнти за симетричними NAT не встановлять з'єднання — це приблизно 15–20% трафіку. Coturn — стандартний open-source сервер.

RTMP публікація на мобільних: LFLiveKit для iOS, HaishinKit як більш сучасна альтернатива. На Android — rtmp-rtsp-stream-client-java або через FFmpeg з JNI. Останнє дає максимальну гнучкість, але бінарник зростає на 10–15 МБ.

Обробка медіа: компресія та транскодування

Відео в ProRes може займати 6 ГБ/хвилину. Перед завантаженням потрібна компресія. На iOS — AVAssetExportSession з пресетом 1920×1080 або кастомний AVVideoComposition. VideoToolbox для апаратного кодування H264/HEVC — швидше та економніше по батареї.

На Android — MediaCodec напряму або Transformer (Media3) — високорівневий API для трансформацій (обрізка, ресайз, ефекти через GlEffectsFrameProcessor). Для зображень — BitmapFactory.Options.inSampleSize для даунсемплінгу, Glide / Coil для кешування. Coil на Coroutines добре вписується в Compose. Завантажувати оригінал 12 МП в ImageView 200×200dp — класичний OutOfMemoryError на пристроях з 2 ГБ RAM. Тому ми завжди стискаємо зображення до 1 МБ перед відправкою.

Як реалізувати стрімінг на мобільних пристроях: покроковий план?

1. Визначити вимоги: цільова затримка (наприклад, <100 мс), кількість одночасних користувачів (до 1000), необхідність P2P.
2. Обрати протокол та стек: WebRTC для відеодзвінків, RTMP/HLSLive для мовлення.
3. Налаштувати сигналінг (SIP, WebSocket, MQTT) та TURN-сервер.
4. Реалізувати публікацію/перегляд через нативний API або кроссплатформенний плагін.
5. Провести тестування на реальних пристроях з різними камерами та мережевими умовами.
6. Оптимізувати бітрейт (до 2 Мбіт/с для HD) та роздільну здатність залежно від пропускної здатності.

Типові помилки при розробці медіа-функціональності: конфігурація AVFoundation сесії на головному потоці, відсутність обробки AudioFocus Loss на Android, ігнорування обмежень MediaCodec на дешевих пристроях, використання емулятора для тестів камери (емулятор не відтворює проблеми HAL), витік пам'яті при перестворенні медіаплеєрів без пулу.

Що входить в роботу?

Процес розробки медіафункціональності

Складність нелінійна: базове відтворення відео — 1–2 дні, кастомна камера з обробкою кадрів та стрімінгом — 3–5 тижнів. Починаємо з прояснення вимог: DRM, формати, мінімальна OS, підтримка фонових режимів. Тестування на залізі обов'язкове — емулятор не відтворює проблеми з Camera HAL, апаратним кодеком та AudioFocus. Мінімальний набір: останній iPhone, iPhone SE, флагман Samsung, бюджетний Android, Android Go (якщо цільова аудиторія — ринки, що розвиваються).

Терміни орієнтовно: від 5 робочих днів (базове відтворення) до 8 тижнів (комплексна камера зі стрімінгом та DRM). Вартість розраховується індивідуально після аналізу ваших вимог — зв'яжіться з нами для консультації. Типовий бюджет таких проєктів: від $2,000 до $15,000.

Фраза послуги: «Робота з медіа в мобільних застосунках» — це наш профіль. Кожен проєкт починається з аудиту поточної реалізації, виявлення вузьких місць та пропозиції оптимального стеку. Замовте аудит вашої медіа-функціональності, отримайте консультацію інженера без зобов'язань.