Реализация AI-транскрибации аудио/видеофайлов в мобильном приложении
Пользователь загружает запись совещания на 40 минут — и ждёт текст. Если на сервер уходит сырой MP4 весом 300 МБ, а обратно приходит JSON через 90 секунд, UX сломан ещё до первого слова. Задача — выстроить пайплайн, в котором мобильный клиент не просто отправляет файл, а участвует в подготовке данных: нарезка, конвертация, чанкование — и получает результат постепенно, пока модель ещё работает.
Где ломается наивная реализация
Самая частая ошибка — отправлять файл целиком через обычный URLSession.dataTask или OkHttp с дефолтными таймаутами. На больших файлах это либо NSURLErrorTimedOut (-1001), либо 413 с сервера, либо OOM на Android при буферизации в памяти.
Второй грабель — формат. Whisper и большинство cloud-провайдеров принимают audio/wav, audio/mp3, audio/mp4, audio/ogg, но не все кодеки внутри этих контейнеров. Видеофайл .mov с кодеком pcm_s16le пройдёт, а .mov с ac3 — даст 400 Bad Request без объяснений. На iOS демуксинг через AVAssetExportSession с пресетом AVAssetExportPresetAppleM4A решает 95% случаев. На Android — MediaExtractor + MediaCodec для декодирования в PCM, затем MediaMuxer для упаковки в AAC.
Третья проблема — чанкование по времени без учёта тишины. Если резать по 60 секунд ровно, слово может попасть на границу, и транскрипция разобьёт его на два фрагмента. Используй VAD (Voice Activity Detection) для нарезки по паузам. На iOS есть AVAudioSession + AVAudioEngine для анализа сигнала, на Flutter — пакет voice_activity_detector поверх WebRTC VAD.
Как строится пайплайн на практике
Подготовка файла на устройстве
// iOS: Извлечь аудиодорожку из видео
let asset = AVURLAsset(url: videoURL)
let exportSession = AVAssetExportSession(asset: asset, presetName: AVAssetExportPresetAppleM4A)!
exportSession.outputFileType = .m4a
exportSession.outputURL = tempAudioURL
await exportSession.export()
После экспорта — разбивка на чанки по 25 МБ (лимит Whisper API) с учётом VAD-границ. Каждый чанк загружается через URLSession.uploadTask(with:fromFile:) с фоновой конфигурацией (URLSessionConfiguration.background), чтобы загрузка продолжалась при сворачивании приложения.
На Android аналогично: WorkManager с CoroutineWorker для фоновой обработки, OkHttp с RequestBody.create через File, а не через ByteArray — это критично для экономии памяти на устройствах с 2 ГБ RAM.
Стриминг результата
Вместо polling каждые N секунд — WebSocket или SSE. Если используешь собственный бэкенд поверх Whisper, сервер может стримить partial_transcript по мере обработки чанков. На клиенте это URLSessionWebSocketTask (iOS) или OkHttp WebSocket (Android), который добавляет строки в StateFlow / @Published — UI обновляется в реальном времени.
Для прямой интеграции с OpenAI Whisper API стриминга нет — API синхронный. Поэтому при большом файле разбивай на независимые запросы и мержи результаты на клиенте по индексу чанка, а не по порядку ответов (сеть не гарантирует порядок).
Хранение и постобработка
Сырой транскрипт из Whisper возвращает segments с временными метками — это ценнее, чем просто текст. Храни JSON с start, end, text для каждого сегмента: это позволяет реализовать «тап на слово → перемотка аудио».
Для постобработки — пунктуация и диаризация (кто говорил). Whisper не разделяет спикеров. Для этого нужен отдельный шаг: pyannote.audio через API или AssemblyAI с параметром speaker_labels: true. На клиенте просто мержишь два JSON по временным меткам.
Выбор провайдера под задачу
| Провайдер | Точность (RU) | Стриминг | Диаризация | Лимит файла |
|---|---|---|---|---|
| OpenAI Whisper | Высокая | Нет | Нет | 25 МБ |
| AssemblyAI | Средняя | Да | Да | 5 ГБ |
| Deepgram Nova-2 | Высокая | Да | Да | Нет лимита |
| Google Speech-to-Text v2 | Средняя | Да | Да | 1 ГБ |
| On-device (iOS CoreML) | Средняя | Нет | Нет | Ограничен RAM |
Для русского языка Whisper large-v3 заметно выигрывает у остальных на неформальной речи и техническом жаргоне. Deepgram Nova-2 с параметром language: ru — хороший вариант, если нужен реалтайм.
Процесс работы
Начинаем с аудита: формат файлов, средний размер, языки, нужна ли диаризация, есть ли требования к офлайн-работе. Под это выбираем провайдера и архитектуру пайплайна.
Разработка идёт поэтапно: сначала базовый upload + транскрипция без оптимизаций, затем добавляем чанкование, фоновую загрузку, стриминг UI, постобработку. Каждый этап — отдельная ветка с функциональным тестом на реальных устройствах (не симулятор — CoreML и MediaCodec ведут себя по-разному на реальном железе).
Срок от интеграции простого Whisper API до полноценного пайплайна с диаризацией и фоновой загрузкой — от 2 до 6 недель в зависимости от платформы и требований.