Инициализация libavcodec для воспроизведения в реальном времени с пропуском кадров при необходимости

У меня есть приложение компьютерного зрения на С++, связанное с библиотеками ffmpeg, которое предоставляет кадры из видеопотоков для процедур анализа. Идея состоит в том, что можно предоставить умеренно общий идентификатор видеопотока, и этот источник видео будет распаковываться и кадр за кадром передаваться процедуре анализа (которая запускает функции анализа пользователя). «Умеренно общий идентификатор видео» охватывает 3 общих видеопотока. типы: пути к видеофайлам на диске, IP-видеопотоки (камеры или сервисы потокового видео) и контакты веб-камеры USB с желаемым форматом и скоростью.

Мой текущий видеоплеер максимально универсален: только видео, игнорируя аудио и другие потоки. Он имеет случай переключения для получения частоты кадров потока на основе источника потока и кодека, который используется для оценки задержки между кадрами распаковки. У меня было много проблем с попыткой получить надежные временные метки из потоков, поэтому в настоящее время я игнорирую pts и dts. Я знаю, что игнорирование pts/dts плохо для потоков с переменной частотой кадров. Я планирую заняться ими позже. В настоящее время проигрыватель проверяет, не отстает ли последний распакованный кадр более чем на 2 кадра (при постоянной частоте кадров), и если да, то "отбрасывает кадр" - не передает его процедуре анализа пользователя.

По сути, логика видеоплеера определяет, когда пропускать кадры (не передавать их в процедуру анализа, занимающую много времени), чтобы анализ подавал видеокадры как можно ближе к реальному времени.

Я ищу примеры или обсуждения того, как можно инициализировать и/или поддерживать свои AVFormatContext, AVStream и AVCodecContext, используя (предположительно, но не ограничиваясь ими) параметры AVDictionary, такие как удаление кадров, необходимое для поддержания реального времени, выполняется на уровне библиотек libav. , а не на уровне моего видеоплеера. Если для этого требуются отдельные AVDictionaies (или более) для каждого типа потока и кодека, пусть будет так. Мне интересно понять плюсы и минусы обоих подходов: отбрасывание кадров на уровне игрока или на уровне libav.

(Когда для некоторого анализа требуется каждый кадр, существующая реализация плеера с отключенным отбрасыванием кадров вполне подойдет. Я подозреваю, что если я смогу добиться отбрасывания кадров на уровне libav, я также сэкономлю время распаковки пакета для кадра, сократив обработку больше, чем моя текущая версия.)


person Blake Senftner    schedule 20.10.2019    source источник
comment
насколько мне известно, в libav такой возможности нет. Вам нужно будет разобраться с этим делом самостоятельно.   -  person szatmary    schedule 21.10.2019
comment
Я экспериментирую с первым определением, обеспечивает ли кодек только полные кадры, например, кодек mjpeg, общий для USB-камер. Если это правда, используя очень маленький размер rtbuffsize 768 КБ, я получаю отбрасывание кадров, так что максимальная задержка в реальном времени составляет менее 2 секунд, часто менее 1 секунды. Я знаю, что отбрасывание кадров происходит в соответствии с моей логикой, потому что обратный вызов av_log получает сообщения, объявляющие о каждом отбрасывании кадров, потому что rtbuffer слишком заполнен.   -  person Blake Senftner    schedule 22.10.2019
comment
Я не думаю, что в этом случае в ffmpeg не происходит пропадание кадров. Это оказывает обратное давление сети на камеру, и камера пропускает кадр до того, как он попадет в сеть.   -  person szatmary    schedule 22.10.2019
comment
Является ли пропадание кадров в USB-камере (из-за обратного давления в сети) обязательно плохим?   -  person Blake Senftner    schedule 24.10.2019


Ответы (1)


если я могу получить отбрасывание кадров на уровне libav, я также сохраню время распаковки пакета для кадра

Нет, вы не будете, если только вы не захотите отбросить все кадры до следующего ключевого кадра. Для типичного видео в формате mp4 это может быть несколько секунд.

Вы можете пропустить преобразование цветового пространства и изменение размера, но часто об этом позаботится игрок.

person Alex Cohn    schedule 20.10.2019
comment
Я понимаю это, но я не просто обрабатываю видео в формате mp4; довольно много камер поддерживают формат mjpeg, и, поскольку это техническое пользовательское приложение, мы включили руководство по таким вещам, как настройка параметра GOP/GOV потока для минимизации промежутка между ключевыми кадрами. - person Blake Senftner; 20.10.2019