flvmux не тянет видео с такой же скоростью, как аудио
У меня есть конвейер, предназначенный для захвата аудио и видео с камеры C920, небольшого количества очень простой обработки (низкие требования к процессору), затем повторного сжатия и передачи его в файл.
Это общая схема конвейера:
Platform:
- Raspberry Pi 3
- Debian Jessie
- GStreamer 1.8
Не беспокойтесь о моей области "простой обработки". Мой общий процессор ниже 25%.
Я обнаружил, что Q3 и Q4 медленно начинают заполняться, пока один из них не достигнет порогового значения, и тогда мой звук не станет прерывистым (и я получаю предупреждения от alsasrc "нисходящий поток не использует буферы достаточно быстро"). Я могу поставить утечки в очереди, но это вряд ли решит проблему.
Поскольку мой конвейер работает, вот как выглядят мои очереди (текущее время-уровень в мс)
QUEUE CONTENTS IN MILLISECONDS
TIME(s) Q1 Q2 Q3 Q4 Q5 Q6
0 0 0 0 0 0 0
5 0 0 252 380 0 0
10 0 0 293 460 0 0
15 0 0 332 470 0 0
20 0 0 378 451 0 0
25 0 0 333 460 0 0
30 0 0 383 480 0 0
35 0 0 500 550 0 0
40 0 0 500 610 0 0
45 0 0 539 630 0 0
50 0 0 584 670 0 0
=== ЭКСПЕРИМЕНТ ===
Я удалил желтую ветку конвейера, так что я только снимал видео, и результат был лучше. У меня не было очередей, которые просто продолжали "расти" - и выходное видео было идеальным.
QUEUE CONTENTS IN MILLISECONDS
TIME(s) Q1 Q2 Q3 Q4 Q5 Q6
0 0 0 0 0 0 0
5 0 0 2 0 0 0
10 0 0 5 0 0 0
15 0 0 8 0 0 0
20 0 0 8 0 0 0
25 0 0 8 0 0 0
30 0 0 8 0 0 0
35 0 0 8 0 0 0
40 0 0 8 0 0 0
45 0 0 8 0 0 0
50 0 0 8 0 0 0
Кроме того, я попробовал следующий конвейер (я опустил очереди на диаграмме) с полным успехом - видео записывалось не менее 10 минут без проблем.
=== ВОПРОС ===
Что здесь происходит?
Я предполагаю, что, поскольку Q3 (видеовыход) заполняется, звук должен замедлять работу. Поскольку Q4 заполняется, а НЕ Q5 - это должно означать, что alsa производит звук быстрее, чем кодер aac может его сжать - это правильно? Тем не менее, загрузка моего процессора очень низкая - я пробовал использовать 2 aac-кодера (voaacenc и avenc_aac) и MP3-кодер, все с одной и той же проблемой.
======== ОБНОВЛЕНИЕ =========
Я поместил пару элементов идентичности после аудио и видео (непосредственно после), и наметил PTS их выходов. Вы можете видеть, что они очень быстро начинают отдаляться друг от друга. К тому времени, когда видео длится 30 секунд, звук уже отстает на 21 секунду. Вот диаграмма
======== ОБНОВЛЕНИЕ 2 =========
У меня была вторая камера, и я поменял ее, и проблема ушла. Аудио и видео значения PTS оставались синхронизированными не менее 25 минут. Разница с этой новой камерой - это модифицированный C920 с установленным на заказ объективом. По совпадению, объектив оказался полностью не сфокусированным - и это то, что зафиксировало смещение PTS (если я сфокусирую свой объектив, я получу тот же смещение PTS).
Итак, вопрос немного изменился: почему фокусная камера C920 так плохо дотягивает до PTS? Примечание. Я отключаю автоэкспозицию и устанавливаю абсолютное значение экспозиции по умолчанию, равное 250. Однако я бы предпочел использовать автоэкспозицию...
1 ответ
ОК, я решил проблему. Для всех, кто читает:)
Если вы используете Raspberry Pi, даже v3 - убедитесь, что вы настроили peak-bitrate
не более чем 3650000
(3,65 Мбит / с) на вашем uvch264src
, Я также записываю аудио на 24 кГц - если вы этого не сделаете, вы сможете получить немного больше.
Если вы установите его на значение more или опустите его полностью, у вас возникнут те же странные проблемы, что и у меня. Движение и высокая детализация видеоматериала приведут к тому, что закодированный H264 превзойдет то, что может обработать Pi. Так что ваши проблемы будут странными и спорадическими.
Я могу только думать, что C920 насыщает шину USB - странно, потому что USB2 должен быть хорош до 480 Мбит / с - и предел, который я установил, составляет 3,65 Мбит / с. Я слышал, что Raspberry имеет очень некорректную версию прошивки USB - но никогда с этим не сталкивался, до сих пор.
Задача решена. Я думал о переходе на доску для драконов... это могло дать мне лучшую причину.