PaddleOCR для видео – подробный разбор распознавания текста

TL;DR

PaddleOCR – это open-source-тулкит оптического распознавания символов, который Baidu PaddlePaddle выкатила в 2020 году, а к 2026 он стал дефолтным детектором текста на видео для команд, которым нужен точный пайплайн под Apache 2.0, работающий без обращения к вендорскому API. Релиз PaddleOCR 3.0 от мая 2025 года представил PP-OCRv5 – трёхстадийный пайплайн detection-classification-recognition, чья mobile-модель распознавания на 5 миллионов параметров обгоняет миллиардопараметрические vision-language models на OCR-бенчмарке OmniDocBench с отрывом в 13 процентных пунктов от предшественника PP-OCRv4. Для видео пайплайн запускается на каждом кадре (или на каждом N-м ключевом), выдаёт полигональные bounding box-ы и распознанный текст на каждое детектирование, и поставляется в трёх вариантах: 4–8 MB mobile-модель для CPU и edge, 30–100 MB server-модель для GPU и ONNX-экспорт, работающий в любом inference-движке (OpenVINO, ONNX Runtime, TensorRT). В этой статье разбираем, как устроен пайплайн, почему модель в 5 мегапараметров обгоняет VLM на чистом OCR, какой получается per-frame latency-бюджет на 1080p на CPU и GPU и какие шесть production-failure-mode придётся обходить инженерно, встраивая PaddleOCR в реальный видеопродукт.

Зачем Это Нужно Знать

Текст в кадре – это данные, на которые остальной пайплайн может реагировать. Номер машины, въезжающий в кадр на 47-й секунде записи surveillance. Номер на футбольной майке. Дорожный знак в записи мониторинга водителя. Уравнение на whiteboard в записи лекции e-learning. Чек на экране во время удалённого депозита в telemedicine-звонке. Жёстко вписанные субтитры на архивной OTT-записи, к которой у вас нет отдельного файла caption-ов. Каждый из них – кадр, который система должна прочитать, а чтение – это ровно то, что делает OCR-пайплайн. Если вы строите видеопродукт, который касается surveillance, driver assistance, поиска по OTT-архиву, e-learning-аналитики или compliance-кейсов, рано или поздно вам понадобится OCR-примитив внутри пайплайна – а build-vs-buy-решение бьёт по бюджету в момент, когда кто-то достаёт ценник Google Document AI: $1.50 за 1000 страниц, и сравнивает с self-hosted PaddleOCR ценой в одну GPU. Эта статья – для продакт-менеджера, video-platform-инженера или фаундера, которому надо спланировать OCR-зависимую фичу, понять, чем PaddleOCR отличается от своих коммерческих сородичей, и какие из его failure-mode укусят первыми, когда текст начнёт двигаться по кадру.

Ментальная Модель – OCR Это Трёхстадийный Пайплайн

Чтение текста из видеокадра – это не одна ML-модель. Это три модели, запущенные подряд, каждая решает задачу, от которой зависит следующая стадия. Эти три стадии стоят внутри каждой production-OCR-системы со времён оригинальной статьи PP-OCR 2020 года.

Стадия один – text detection. Получив сырой RGB-кадр, детектор выдаёт полигональные bounding box-ы вокруг каждой области в кадре, где есть текст. Это не классификация что написано, это чистый ответ на «где на этой картинке есть текст». PaddleOCR использует сеть DBNet – Differentiable Binarization Network, – которая вместо предсказания жёсткой да-нет-маски «этот пиксель – текст?» предсказывает гладкую probability-map и гладкую threshold-map, а потом дифференцируемо бинаризует их в финальные полигоны. Гладкость – трюк, который делает сеть тренируемой end-to-end и точной на кривом или повёрнутом тексте.

Стадия два – orientation classification. Для каждой найденной детектором текстовой области крошечный классификатор предсказывает, перевёрнут текст вверх ногами (180°) или стоит как надо (0°). Это сеть mobilenet-класса на четыре миллиона параметров, единственная задача которой – повернуть crop правильной стороной, прежде чем он попадёт в recognizer. Стоит почти бесплатно и даёт назад около трёх процентных пунктов точности на реальном видео, где угол наклона камеры не обязательно нулевой.

Стадия три – text recognition. Вырезанная и развёрнутая правильно текстовая область идёт в recognizer-сеть, которая выдаёт сам character sequence. Начиная с PP-OCRv3 (2022), эта стадия использует SVTR – Scene-text Visual Transformer – маленький трансформер, заменивший LSTM из оригинального PP-OCR. Релиз PP-OCRv5 2025 года объединил SVTR с backbone PP-LCNetV3 в гибрид SVTR_LCNet – именно этот recognizer обгоняет VLM на OCR-бенчмарках при сумме 5 миллионов параметров.

Нажмите, чтобы увеличить

Почему PaddleOCR Обгоняет Бо́льшие Модели На Чистой OCR-Задаче

В 2025 году общепринятое мнение о том, что выбрать под OCR – специализированную модель или general-purpose VLM – развернулось. Точка разворота – PP-OCRv5, релиз 20 мая 2025 года, побитый на бенчмарке OmniDocBench – мультиязычном print-and-handwriting-бенчмарке, который сама команда PaddleOCR публикует.

Главный результат: mobile-recognition-модель PP-OCRv5 на 5 миллионов параметров обогнала несколько миллиардопараметрических vision-language models по среднему 1-edit-distance-показателю на OmniDocBench. По сравнению с непосредственным предшественником PP-OCRv4 (2023) PP-OCRv5 добавил 13 процентных пунктов на внутренних multi-scenario-evaluation-сетах. По сравнению с PP-OCRv3 (2022) – плюс 30% точности на multilingual recognition.

Модель в 5 мегапараметров, обгоняющая VLM на 7 или 13 миллиардов на той же задаче, звучит неправильно при первом чтении. Это не так. Три вещи это делают возможным. Первая – OCR-задача узкая: ей не нужны world knowledge, диалог или reasoning – только маппинг pixel patterns в character codes. Вторая – training data огромная и чистая: recognition-модель PaddleOCR обучалась на десятках миллионов реальных аннотированных текстовых crop-ов по 106 языкам – кратно больше text-specific-данных, чем видела любая general VLM. Третья – архитектура purpose-built: attention SVTR ограничен узкой text-line-полосой, а не картинкой 1024×1024, поэтому модель может быть кратно меньше без потери expressive power на её фактической задаче. Маленькая специализированная модель на узкой задаче с обильными чистыми данными бьёт большую generalist-модель. Это эмпирическое правило для каждого OCR-only-деплоя в 2026 – текст на видеокадре – ровно такая узкая задача.

Cost story – то, что интересует build-vs-buy-таблицу. На Intel Xeon Gold 6271C без GPU PP-OCRv5 mobile обрабатывает больше 370 character per second. На NVIDIA Tesla T4 с включённым high-performance inference задержка mobile recognition падает на 73.1%, а mobile detection – на 40.4%. Комбинированная per-frame стоимость на T4 для 1080p-видео с десятью текстовыми регионами – примерно 30–60 миллисекунд. T4 instance на крупном клауде стоит около $0.35 в час в 2026 – то есть 36 000 кадров в час при 30 FPS, или 600 кадров на минуту видео, обойдутся примерно в $0.0006 на минуту записи. Google Document ИИ берёт $1.50 за 1000 страниц. Hosted-API-цифра нормальна для маленького batch. Для непрерывного видео self-hosted-цифра дешевле на два порядка.

Чем Видео-OCR Отличается От Документного

Документный OCR читает статичную, ровно освещённую, высокого разрешения картинку один раз и выдаёт финальный ответ. Видео-OCR читает 25–60 кадров в секунду, у каждого разное освещение, motion blur, occlusion и шум, и должен выдавать связную per-second текстовую дорожку, которой может пользоваться остальной пайплайн. Инженерная реальность расходится в пяти местах.

Temporal sparsity. Номер машины в surveillance-записи появляется примерно на 40 кадрах за две секунды. Прогонять OCR на каждом кадре – мотовство, 40 чтений одной и той же строки. Production-паттерн – сначала запустить дешёвый motion-detector или multi-object tracker, потом sample-ить каждый N-й кадр из каждого отслеживаемого региона, и только на этих сэмплах поднимать OCR. Для большинства surveillance- и OTT-archive-нагрузок N=10 (одно чтение каждые 333 ms при 30 FPS) – правильная отправная точка.

Motion blur. Объект, едущий со скоростью 30 км/ч поперёк кадра при 30 FPS, смещается примерно на 28 пикселей за кадр в 1080p – этого хватает, чтобы каждый символ превратился в смаз. PP-OCRv5 обучен на синтетическом motion blur, но только до определённого радиуса. Дальше уверенность recognizer-а резко падает. Фикс – пускать recognizer только по самому резкому кадру в временном окне (выбирать по метрике gradient energy), а не вслепую по каждому.

Compression artifacts. OTT-архивы – H.264 или HEVC при 4–8 Mbps. Per-frame quantization noise, block artifacts на низкобитрейтных сценах и chroma subsampling вместе снижают OCR-точность. Фикс – deblock + лёгкий upsample кандидата региона: 2× bicubic upscale до OCR добавляет примерно 8 ms на кадр и возвращает 3–7 процентных пунктов F-score распознавания на реальном OTT-входе.

Language detection per frame. Surveillance-система в Сингапуре в течение часа видит English, Chinese, Tamil и Malay-текст на одном и том же camera feed. PP-OCRv5 поддерживает 106 языков в одной мультиязычной модели, но per-language head надо выбирать правильно. Production-паттерн – запустить лёгкий language-ID-head на первом найденном текстовом регионе и протащить language hint вперёд через tracker, re-detect-ить язык только на смене сцены.

Low-confidence aggregation. По 40 кадрам одной и той же таблички у вас 40 независимых чтений, у каждого свой confidence на каждый символ. Правильный ответ – не самое уверенное чтение, а per-character majority vote, взвешенный по confidence по всем кадрам, где этот номер был tracked. Фикс – небольшая стадия агрегации после OCR, потребляющая per-frame-кортежи (polygon, text, confidence) и выдающая одну строку на tracked object.

Production-Паттерн – Когда Выбирать PaddleOCR

Build-vs-buy-дерево для OCR в видеопродукте короткое. Большинство команд приходят к PaddleOCR после прайсинга альтернатив.

Hosted commercial APIs – Google Document AI, AWS Textract, Azure Read API – отличны для разовых document scan-ов, multilingual-чеков и любых нагрузок, где платится только за хиты. Они неправильны для непрерывного видео, потому что платится за страницу, per-frame request добавляет 100–300 ms сетевого round-trip, а данные уходят из вашей инфраструктуры. Для surveillance-системы на 1000 камер при 30 FPS hosted-API-счёт получается семизначный в месяц.

General-purpose vision-language models – Gemini, Claude vision, GPT-4o – читают текст из картинки в рамках более широкого мультимодального reasoning. Для ad-hoc-нагрузок, где модель должна также понимать контекст («прочитай чек и скажи итог»), VLM – правильный выбор. Для OCR-only («дай мне каждую строку на каждом кадре») они медленнее и дороже специалиста, а PP-OCRv5 их к тому же бьёт на OCR-бенчмарке. Решение VLM-vs-custom-CV мы разобрали в отдельном уроке.

Другие open-source OCR-системы – EasyOCR (на PyTorch, широкая языковая поддержка, медленнее PaddleOCR в 2–4 раза), MMOCR (OpenMMLab, research-oriented, тяжело шипить в production) и Tesseract (legacy, классический, точный только на чистых print scan-ах). Из них EasyOCR – ближайший functional substitute; PaddleOCR быстрее и шипит меньшие mobile-модели.

Правильный ответ в 2026 году для self-hosted, multilingual, video-grade OCR-пайплайна – PaddleOCR. Правильный ответ для быстрого прототипа, hosted-scale-out-а или нагрузки, где context-aware reasoning важнее throughput – вызов VLM. Правильный ответ для разового скана чека – коммерческий API.

Шесть Failure-Mode, Которые Кусают В Production

В Фора Софт мы встраивали PaddleOCR в видеопайплайны surveillance, OTT archive search и e-learning analytics. Шесть failure-mode встречаются во всех трёх вертикалях.

Failure 1: Сэмплинг на каждом кадре. Команда встроила PaddleOCR в 30-FPS WebRTC-поток и шокирована, что GPU прогрелась до 100%. Фикс – temporal sparsity: сначала дешёвый motion detector или multi-object tracker, потом OCR каждый 10-й кадр только внутри tracked региона.

Failure 2: Server-модель на CPU. PP-OCRv5 server-модель – это 80+ MB, и она предполагает GPU. Инженеры качают её ради точности, деплоят на CPU-only edge box и обнаруживают per-frame latency в 800 ms. Фикс – матчить размер модели с железом: mobile под CPU и edge, server под GPU; никогда не смешивать.

Failure 3: Игнорирование direction classifier. Direction classifier – middle-stage на 4 миллиона параметров, переворачивающий повёрнутые crop-ы вверх правильно. Команды отключают его ради скорости и теряют три процентных пункта точности распознавания на реальном видео с ненулевым наклоном камеры. Классификатор стоит примерно 2 ms на кадр. Не выключайте.

Failure 4: Маленький текст в нативном размере. Жёстко вписанные субтитры в 480p OTT-архиве – это 14-пиксельные по высоте символы. PP-OCRv5 detection обучен на character height от 24 пикселей. 2× bicubic upscale перед детектированием добавляет 8 ms и возвращает 5–10 процентных пунктов на мелком тексте.

Failure 5: Per-frame чтения без temporal aggregation. Surveillance-система читает «ABC123» в кадре 1, «AB0123» в кадре 5 (motion blur), «ABC123» в кадре 10. Без агрегации система получает три разных «ответа» downstream. Фикс – per-tracked-object стадия агрегации, берущая majority vote, взвешенный по confidence, по всем кадрам одного track.

Failure 6: Pinning языка. Команда хардкодит English. Камера переезжает в другую юрисдикцию, система молча падает на кириллице или китайском, и никто не замечает до surveillance-аудита. Фикс – multilingual PP-OCRv5 с per-tracked-object language-ID-head; не пинить язык на этапе билда.

Нажмите, чтобы увеличить

Цифры, Бок О Бок

В таблице – production-grade OCR-варианты, которые большинство инженерных команд шорт-лист-ят в 2026 для видеопайплайна. Числа взяты из PaddleOCR 3.0 Technical Report, GitHub-бенчмарков EasyOCR, документации Tesseract и публичных pricing-страниц коммерческих API. Latency – wall-clock per-frame на одном 1080p-кадре с примерно десятью текстовыми регионами; для self-hosted-моделей это wall-clock на указанном железе.

Несколько вещей из таблицы. Mobile PaddleOCR – единственная система, которая бежит на sub-100 ms на одном CPU-ядре, а это бюджет, в котором живёт каждый edge-deployed видеопайплайн. Server PaddleOCR на T4 GPU дешевле на два порядка за video-minute, чем hosted commercial API. General VLM медленнее и дороже специалиста, даже до учёта context-window cost на длинном видео. EasyOCR – ближайший open-source-замены и правильный выбор, если команда уже на PyTorch и не на Paddle.

Встраивание В Видеопайплайн – Кодовый Паттерн

Стандартный паттерн 2026 года – экспортировать PP-OCRv5 в ONNX один раз и потом гонять через ONNX Runtime или OpenVINO внутри видеопайплайна. Это полностью развязывает OCR-стадию с PaddlePaddle-фреймворком и позволяет ко-локейтить её с другими video ИИ моделями, которые пайплайн уже крутит.

# Single-frame OCR с PaddleOCR 3.0 — минимальный production-стиль.
# Detection + direction classifier + recognition в одном вызове,
# multilingual PP-OCRv5 server-модель на GPU.

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    use_doc_orientation_classify=False,  # ориентацию обрабатываем сами
    use_doc_unwarping=False,             # читаем плоские видеокадры
    use_textline_orientation=True,       # direction classifier оставляем включённым
    lang="ru",                           # или "en", "ch", "ja" и т.д.
    text_detection_model_name="PP-OCRv5_server_det",
    text_recognition_model_name="PP-OCRv5_server_rec",
    device="gpu:0",
)

# frame — numpy-массив H x W x 3, BGR uint8, прямо из OpenCV.
result = ocr.predict(frame)
for region in result[0]["rec_texts"]:
    print(region)  # одна распознанная строка на детектированный регион

Для batch inference по кадрам – правильный паттерн под не-real-time-пайплайны вроде OTT-archive search или post-hoc surveillance review – передаём список кадров в ocr.predict(), и PaddleOCR сам обрабатывает батчинг. Для real-time-пайплайнов экспортируем модели в ONNX один раз и сервим через Triton или ONNX Runtime рядом с остальными video ИИ моделями. Команды экспорта и Triton-конфиги – в документации PaddleOCR 3.0 в разделе high-performance inference.

Где Тут Фора Софт

В Фора Софт мы шипили PaddleOCR в видеопайплайны surveillance, OTT archive search и e-learning analytics. В surveillance используем PP-OCRv5 server внутри стадии чтения номера, которая запускается после того, как DeepSORT-tracker пометил машину как стабильно отслеживаемую. В OTT – mobile-модель внутри прохода извлечения burned-in-субтитров для archive search, где per-minute-стоимость важнее per-frame-latency. В e-learning – на захвате whiteboard и слайдов внутри lecture-recording-аналитики, где language-ID head важен, потому что лекции мешают English с математической нотацией и иногда foreign-language-цитатами. Своих OCR-исследований не ведём; интегрируем open-source state-of-the-art в видеопродукты, которые отгружаются и продолжают работать.

Ключевые Выводы

• PaddleOCR – дефолтный open-source OCR-пайплайн для видео в 2026: три стадии (detection, direction, recognition), Apache 2.0, multilingual, бежит на CPU или GPU.
• PP-OCRv5 (май 2025) – специализированная модель на 5 мегапараметров, обгоняющая миллиардопараметрические VLM на OCR-бенчмарке OmniDocBench.
• Для непрерывного видео self-hosted PaddleOCR дешевле hosted commercial API на два порядка за video-minute.
• Mobile-модель – для CPU и edge; server-модель – для GPU; не смешивать.
• Шесть failure-mode – every-frame sampling, mismatched model size, отключённый direction classifier, отсутствие pre-upsampling, per-frame чтения без агрегации, hardcoded язык – у каждого свой инженерный фикс.
• Экспортируйте PP-OCRv5 в ONNX один раз и сервите через ONNX Runtime или Triton рядом с остальным video ИИ-стеком.

Что Читать Дальше

• Multi-object tracking – DeepSORT, ByteTrack, OC-SORT – upstream-стадия, которая решает, какие tracked-регионы достаточно стабильны, чтобы их читать PaddleOCR-ом.
• Решение «просто возьми VLM» – когда frontier multimodal заменяет custom CV – когда вызов Gemini или Claude vision правильный ответ вместо специализированного OCR.
• Vision Transformer primer для video ИИ инженеров – архитектурное семейство, на котором стоит SVTR – recognizer PaddleOCR со времён PP-OCRv3.