Rockchip RK3588

Итак, руки добрались до рокчипа.

Сразу скажу, что железка крайне неоднозначная, с множеством проблем, но и не меньшим количеством достоинств. Купил я её, чтобы пощупать на предмет кодирования видео, конечно. Но неожиданно она превратилась в постоянного члена домашней лаборатории.

Если сравнить общую производительность самого процессора, например, с BCM2712 (Raspberry Pi 5), то окажется, что рокчип аж на 30% быстрее броадкомовского — https://www.cpubenchmark.net/compare/4906vs6054/Rockchip-RK3588-vs-BCM2712.

И по температурному режиму, насколько понимаю, гораздо гуманнее. Разогреть его выше 60 градусов практически нереально:

Сейчас на такой плате (Orange Pi 5 Plus) работает БД Clickhouse с таблицами под 1 млрд записей:

По энергопотреблению максимум 20 Вт. Если задействован только транскодинг — не более 5 Вт.

H264

Сравнивать её с многопроходными настройками кодирования, например, Nvidia, а тем более с libx264/libx265 бессмысленно — в реализации RKMPP нет b-frame’ов. По битрейту сразу получаем в среднем проигрыш больше 40%:

С Intel A380 примерно такая же картина. Я даже не буду приводить график.

А вот с режимами low/zero latency для определённых сцен вполне можно сравнить.

20% — 26% проигрыша по битрейту.

На статичной сцене для низких битрейтов явная тенденция к завышению в 1.5 раза. Начиная с 2.3 Mбит/с достаточно стабильный битрейт близко к целевому.

На более сложной сцене с шерстью обезъянки при недостатке битрейта его завышают уже оба кодека. RKMPP — более чем в 2 раза.

На традиционно сложных для NVENC сценах типа водной ряби или водопада оба кодека ведут себя почти одинаково и очень вольно по отношению к битрейту:

Здесь RKMPP целевой битрейт в 1 Mбит/с увеличивает в 4.43x, NVENC — 3.85x.

Если рассматривать качество, то минимальную разницу в 16% по битрейту между RKMPP и NVENC вы получите при кодировании телеконоподобных видео. Причём на битрейтах менее 3 Mбит/с разница будет незаметна на глаз, но в обоих случаях c артефактами в виде пикселизации.

Контроль битрейта в принципе тоже на приемлемом уровне — завышение порядка 15%.

Cравнение с libx264 zerolatency

Для начала посмотрим на пресет slow:

5% — 7% проигрыша по битрейту для небольших размеров кадра. И около 12% для 720p — 4K. Что, во-первых, не выглядит критичным, а во-вторых, кто использует slow пресет с софтверными кодеками? Надо смотреть на быстрые пресеты. А вот там картина прямо противоположная! Сравнение с пресетом veryfast:

Выигрыш 13% — 18% для мелких кадров и 14% — 20% для крупных.

Обратимся к деталям.

Статичное 4K видео с костром на пляже.

Здесь наблюдаем 23% выигрыша по битрейту. Кривая libx264 немного сдвинута влево, что говорит о снижении битрейта вцелом.

Следующий график это наглядно подтверждает:

libx264 занижает битрейт больше, чем на 13%. Зато стабильно – в заявленный канал пролезет точно.

Здесь можно наблюдать работу кодеков с качеством по каждому кадру (зелёные точки — RKMPP, красные — libx264):

С “телеконами” выигрыш немного поменьше – 12%. Зато график покадрового качества выглядит замысловатее.

С обезъянками (вернее с их шерстью) RKMPP справляться сложнее. Здесь наблюдаем проигрыш 27% — рокчип категорически отказался снижать битрейт ниже 2.26M для такой сцены (от целевого 1М).

Промежуточный вывод по сравнению с zerolatency режимом libx264. RKMPP подтверждает, что ему лучше со статичными сценами. Много двигающихся деталей не его стихия. Если ему не хватает битрейта, то запросто завысит, чтобы хватало.

Вывод по H264 вообще. Чем больше размер кадра и чем меньше движения в сцене, тем меньше разницы в качестве с другими кодеками. Для кадров меньше 720p RKMPP лучше не использовать.

HEVC

Для начала сравним реализации HEVC и H264 между собой. Странно, но HEVC реализован гораздо лучше, чем H264. Об этом говорит метрика BDBR -100% .. -200% — это очень много. По хорошему, должно быть минимум -50%. Для меня это тем более удивительно, так как логичнее было бы бросить ресурсы на оптимизацию H264, нежели «мёртворождённого» HEVC. По крайней мере b-frame’ов там очень не хватает. Даже не говорю про всякие AV1. Но у китайцев своё представление о прекрасном…

Сравнение с NVENC

Выигрыш на всём диапазоне размеров от 8% до 13%. Самый большой — на 4K.

При сравнении с пресетом p7 естественно выигрыш уменьшился, но всё равно для 4K остался весьма приличным!

Так что если вы стример в 4K и используете HEVC, то рокчип — ваше фсё! Ну или компания транскодирующая эфиры… 😉

Сравнение с HEVC QSV

Здесь пока нет данных, так как есть проблемы с запуском HEVC на карте Intel.

Сравнение с zerolatency libx265

Данные в процессе обсчёта. Скоро добавлю.

Скорость кодирования

Для начала сравним значения самого RK3588 H264 и HEVC:

Да, оба кодека работают почти одинаково по скорости.

H264

Скорость рокчипа примерно соответствует скорости пресета p1 (самого быстрого) карты Nvidia RTX 5060.

А карту Intel A380 обгоняет в несколько раз:

Причём у A380 достаточно странная особенность. Возможно я пока не разобрался в чём именно проблема. Но пресет medium самый быстрый, т.е. он быстрее и чем veryfast. По качеству же разницы между veryslow и veryfast практически никакой — Результаты тестов Intel A380.

HEVC

Опять же при сравнении с RTX 5060 видим выигрыш по скорости для 720p и 1080p. И проигрыш для 1440p и 2160p размеров кадров.

Выводы

В качестве итога могу сказать, что мне лично RK3588 очень нравится. Плата на этом процессоре небольшая, дешёвая, очень мало потребляет, практически не греется. И при этом удивительно быстро кодирует как H264, так и HEVC. Да, по качеству кодирования H264 не дотягивает до того же NVENC. Но это при стоимости на порядок ниже, чем тот же RTX A4000.

Конечно, реализация HEVC приятно удивила.