Raspberry Pi 4 B

У коллеги по работе возник вопрос — как же кодирует Pi 4? Есть вопрос — должен быть ответ. 🙂

В результате на некоторое время взял у него такую плату на исследование.

По современным меркам процессор, конечно, медленный. Но это неудивительно, так как задачи, для которых он обычно используется энтузиастами не требуют больших вычислительных ресурсов. Так как до этого я особо не был знаком с линейкой «малинок», то бы немало удивлён, когда узнал, что у него есть аппаратная поддержка кодирования H.264. Хотя и с ограничением максимального размера кадра в 1920×1080 при скорости кодирования в 30fps (так ли это, конечно, проверим).

Если сравнить с последущим поколением Pi 5 (BCM2712), то он на 74% быстрее Pi 4 (BCM2711) — https://www.cpubenchmark.net/compare/6054vs4297/BCM2712-vs-BCM2711. Естественный вопрос — насколько дальше пошли в развитии видеокодирования и аппаратной поддержки. И тут меня ждала следующая порция удивления, когда обнаружилось, что в Pi 5 отказались от железного кодека.

При установке всё прошло достаточно гладко и быстро. Была обновлена прошивка, установлена серверная Ubuntu 25.10, скомпилирован FFMPEG 8.0.1 с поддержкой v4l2 (—enable-v4l2-m2m).

Вот с подключением внешних быстрых дисков с помощью USB вышла загвоздка. Перепробовал множество вариантов, но все диски под нагрузкой отваливались. Пришлось довольствоваться только картой SDXC. Стоит отметить, что для Pi 5 есть плата расширения для подключения NVMe.

По температурному режиму плата Pi 4 вполне может обходится без дополнительного охлаждения — разогревается максимум до 75ºC при 100% нагрузке процессора. Вентилятор снижает температуру до 60ºC, что уже более чем приемлемый уровень. Однако сильно нагружать систему всё же не стоит — попытка компиляции FFMPEG всеми ядрами (make -j) быстро её перегрузило и она перестала отвечать.

В режиме только кодирования процессор греется максимум до 50ºC. При этом загрузка процессора в среднем составляет около 8%.

По энергопотреблению в среднем зафиксировал 3.6Вт в режиме транскодирования (задействованы оба блока и декодирования и кодирования). В простое плата потребляет 3.3Вт. Стрелкой отмечен момент начала теста.

Думаю, достаточно общей информации. Перейдём к результату кодирования и сравнению с другими кодеками.

Было проведено два раунда тестов. Первый — стандартный, с использованием «сырых» несжатых видео в формате y4m. Делаю это специально, чтобы исключить побочные эффекты от декодирования. Да, декодирование при использовании любых кодеков одного стандарта должны выдавать бинарно идентичный поток на выходе. Но это не всегда так, особенно, если касается реализаций не относящихся к промышленным стандартам.

Что, как раз и наблюдается в случае Raspberry Pi 4. Тест на идентичность выхода с декодера не пройден. При декодировании одних и тех же видео и сохранении их в сырой поток контрольные суммы не совпадают с эталоном. Для проверки те же видео были декодированы с помощью карты Nvidia.

Название фрагмента	MD5
Raspberry Pi 4
harmonic_birds_of_prey_1920x1080_30fps_600.y4m	1001720fe2f8fa52e146f33a65e47a33
harmonic_monkey_pool_1920x1080_30fps_600.y4m	901856a974f83742be3850a10862c641
harmonic_monkeys_fur_closeup_1920x1080_30fps_600.y4m	c9569b77be1f758d5e3f5e2828a6ecc4
harmonic_waterfall_1920x1080_30fps_600.y4m	6073e0b5e1eb06b376ddcb3f0ca6b87d
FFMPEG SW Decode
harmonic_birds_of_prey_1920x1080_30fps_600.y4m	da84bac5786fbef5afa96a809e266051
harmonic_monkey_pool_1920x1080_30fps_600.y4m	13e6085858d98525f954263e72358f18
harmonic_monkeys_fur_closeup_1920x1080_30fps_600.y4m	cf722332a4e6f88ffad5233983b4218b
harmonic_waterfall_1920x1080_30fps_600.y4m	a6f61c123c58a8306fe78cfebe529070
NVDEC
harmonic_birds_of_prey_1920x1080_30fps_600.y4m	da84bac5786fbef5afa96a809e266051
harmonic_monkey_pool_1920x1080_30fps_600.y4m	13e6085858d98525f954263e72358f18
harmonic_monkeys_fur_closeup_1920x1080_30fps_600.y4m	cf722332a4e6f88ffad5233983b4218b
harmonic_waterfall_1920x1080_30fps_600.y4m	a6f61c123c58a8306fe78cfebe529070

Покадровый анализ показал области с большой разницей между тем, что выдаёт декодер Pi 4 и эталоном:

---

Результат первого раунда — оценка качества. При этом оценка скорости кодирования под вопросом, так как для несжатого потока шина данных может быть узким горлышком и железный кодер может загружаться не на сто процентов.

Тем более, что скорость кодирования была относительно далеко от заявленных производителем 30fps для 1080p — в районе 20fps.

Чтобы выяснить какова реальная скорость был проведён второй раунд с сжатым потоком на входе. Здесь ждал сюрприз в виде очень нестабильной работы с множественными падениями FFMPEG:

Assertion pkt failed at fftools/ffmpeg_dec.c:755
Aborted (core dumped)

Замечено на всех разрешениях почти на всех сценах. Причём для 1080p скорость на тех видео, которые транскодированы без проблем в единичных случаях достигала 29fps, но ни разу не превысила. Каждое видео перед транскодированием прогонялось через разогревочный тест, чтобы все данные перед реальным прогоном оставались в кеше и дисковая подсистема не мешала производительности.

В нескольких логах были замечены сообщения:

All capture buffers returned to userspace. Increase num_capture_buffers to prevent device deadlock or dropped packets/frames.

Установка параметра -num_capture_buffers в 32 и в 64 желаемой стабильности не принесла. А на половине теста декодер совсем перестал отвечать. Помогла только перезагрузка платы. В результате из 720 закодированных видео нормально получилось 482 (67%).

Возможно просто существует сборка FFMPEG, где кодек Raspberry работает стабильно.

libx264

Как и рокчип, сравнивать малинку с пакетными режимами кодеков смысла не имеет. У неё тоже нет поддержки b-frame’ов. Даже с быстрым пресетом libx264 выигрывает 33% — 37%:

Однако при сравнении с медленным стриминговым качество практически одинаковое:

Причём на статичной сцене с костром на пляже Pi 4 показывает лучшее сжатие при одинаковом качестве с выигрышем в 25%:

Та же картина наблюдается на сцене телеконференции. Здесь выигрыш по битрейту около 25%.

А вот на сцене с водопадом — проигрывает 10%. Кодек не любит большого количества двигающихся объектов.

При сравнении с пресетом veryfast — выигрыш по битрейту уже до 37% (на 720p)!

NVENC

Графики сравнения Raspberry Pi 4 и NVENC H.264

Со стриминговыми режимами NVENC тягаться сложнее. NVENC жмёт поток лучше вне зависимости от типа сцены.

Проигрыш до 16% на самом быстром пресете p1. И до 21% на самом качественном p7:

QSV

Здесь, конечно, сюрпризов не будет. Проигрыш порядка 30% при сравнении с veryslow (режим с b-frame’ами):

Сравнение с стриминговым режимом будет добавлено позже.

RKMPP

Графики сравнения Raspberry Pi 4 и Orange Pi 5 Plus

Ну и на засладку — битва двух якодзун малинки с апельсинкой. Да, здесь ожидаемый выигрыш, учитывая отличные показатели при сравнении с другими кодеками и слабую реализацию H.264 RKMPP. На 1080p экономия 17% битрейта:

По стабильности контроля битрейта обе железки ведут себя примерно одинаково. При нехватке битрейта на сложных сценах обе завышают более чем в 2 раза. Pi 4 — 2,45x.

На статичной сцене контроль у Pi 4 близок к идеальной 1x на всём диапазоне битрейтов:

---

Выводы

Качество кодирования Raspberry Pi 4 приятно порадовало — реализация на достойном для такого бюджетного железа уровне.

Ложкой дёгтя стала нестабильная работа декодера, при которой использование платы в постоянных задачах транскодинга под вопросом. Вероятно, что на определённых сборках эта проблема не проявляется.

Про скорость кодирования. Я не увидел заявленных производителем 30fps для 1080p. В среднем этот показатель не дотягивает до 20fps. Для 720p скорость кодирования порядка 52fps.

Как всегда, ссылка на базу, где можно сравнить всё со всем — https://vmetrix.tech:3000/d/ads7nhh/bd-br-aggregated

Стоит отметить, что VMAF теперь считается и с моделью VMAF NEG. Что это и в чём отличие ещё напишу отдельно. Пока же просто ссылка на подходящую статью на arxiv — https://arxiv.org/pdf/2107.04510.