Что лучше - RK3399 или два Xeon E5430 для монтажа видеороликов?

никаких, стандарт для всех случаев

Значит, пресет стандартный, slow

Временная шкала сама по себе работает в режиме слайд-шоу при пролистывании вертикально и горизонтально (главное окно).

Окно просмотра работает вполне плавно сносно.

Окно составителя не лагает до тех пор пока не происходит пролистывание в главном окне.

Такое поведение я наблюдаю только на Orange Pi 4.

Временная шкала сама по себе работает в режиме слайд-шоу при пролистывании вертикально и горизонтально (главное окно).

И что удивительно, это поведение наблюдается даже когда в окне ресурсов нету ни одного ролика.

что это значит?

У libx264/libx265 есть опция preset. Это настройка балансаскорость кодирования-эффективность сжатия. slow – стандартный пресет.

Ясно, главное, что на всех подопытных всё делалось одним набором параметров.

Для сравнения: core i5 7500 переваривает 30 fps 640x480 и с libx264 и с libx265. Но у него и tpd 65 ватт. В хозяестве еще есть старый ноутбучный пентиум. Но он под управлением 10 дебиана. Там более старый ffmpeg.

У меня для сравнения i7 3200, он то де самое видео 720р жмёт 60фпс, но у него мощность 170 ват, против 5 ват на 20 фпс одноплатника, мягко говоря производительность проигрывает у х86 при пересчёте на энергию.

Что за одноплатник? Кстати, вопрос: у меня на orange pi 4 в Armbian Bullseye дико тормозит и искажается смотрелка картинок из double commander на gtk2, это нормально для rk3399?

Я выше описывал, на каком одноплатнике сколько и чего.

Нет, rk3399 нормально всё работает, он у меня десктоп. Армбиан на одноплатниках неюзабелен, потому я собрал Gentoo.

неюзабелен

В смысле армбиан подглючивает? А то я реально иногда ловлю какие-то непонятные глюки.

Armbian даже на сервере не может и 30 дней аптайма набрать, обязательно перезагрузится. Gentoo на том же железе уже 400 дней аптайма. На десктопе армбиан совсем не годится.

Спасибо за информацию. Надо будет как-нибудь попробовать cinelerra-gg в gentoo. А как там u-boot настраивать и собирать? Никогда с ним не разбирался.

U-boot для амлогика собирается весь из исходников, кроме пары бинарных «капель» настройки напряжения чипа и оперативки.

Да. За RISC будущее. Надо будет затестить на старом ноуте.

при пересчёте на энергию

Да наверно и при пересчете на стоимость процессора.

За RISC будущее.

RISCованная формулировка. Когда-то будущее было за OS/2, потом за Itanium…

Но да, мне тоже интересно, что из этой движухи выйдет.

RISCованная формулировка

И это верно. Но я уверен, что индустрия будет пытаться уйти от x86.

для амлогика

Спасибо, но у меня уже orange pi 4 lts тут на столе, а покупать еще и амлогики как-то не целесообразно в моём случае. RK3399 вполне-себе тягает… Особенно после Raspberry Pi 3. Главная проблема только со слайд-шоу в некоторых программах, наблюдаемом только на этом компьютере. Реально, беру малину или Orange Pi Lite и там этих проблем нет. Но там маленькая частота камня, да и количество ядер/потоков маловато. А этот чудо-процессор может даже вполне поспорить с бюджетными x86_x64 машинами и съэкономить деньги.

А можно более развернуто как собрать и настроить U-Boot под Orange Pi 4 LTS скажем например под Arch Linux? А то я в этом вопросе тот еще новичок.

Это удивительно, но, похоже, я сам практически перешел на ARM.

Виной всему порт Cinelerra-GG под ARM. Теперь ловлю лютую многопоточную производительность прямо с одноплатников + opengl предпросмотр при видеомонтаже. И всё это удовольствие стоит очень дешево.

в арче те же проблемы, что и на армбиане. я только в Gentoo смог избавится от тормозов. инструкцию как убут собирать нужно поискать, дома на компа(одноплатнике кстати этом) у меня сохранены ссылки. Можешь для начала взять u-boot от khadas edge, там работает видео по HDMI, работает усб клавиатура, остаётся вопрос сделать всё, как я, при конфигурации самого бутлоадера, но по этому ещё статей нет, готов её написать.

Я попробовал собрать по этой инструкции u-boot. Правда, я взял свежий u-boot с ftp.denx.de, но вывода изображения нет и не реагирует на нажатия клавиатуры. Что там происходит непонятно.

Также попробовал u-boot от Khanas Edge, но ситуация та же самая.

Что подскажете с этим делать: либо что-то прописать в boot.scr или как-то по-другому собрать u-boot?

что-то прописать в boot.scr

Это способ мне не нравится тем, что нельзя интерактивно выбирать ядро и дтб файл.

Вобще от Khadas EDGE по дефолту всё работало, видео и клавиатура. Файл этот Edge.u-boot.sd.bin брали? У меня пока на нём всё работает, видео вижу, клавиатура даже радио работает.

В любом случае Вам нужен уарт адаптер, чтобы общаться с доской напрямую, там будет видно всё.

Вобщем предлагаю скооперироваться, я объясню персонально, как я настроил, смотрим подходит такой способ или нет и это поможет написать статью.

В этот раз я взял официальный образ Debian под Orange Pi 4, вычистил от туда debian и поставил туда Arch Linux и оно заработало. Позже поставил кастомное ядро чтобы не смотреть на глючную картинку.

Потом установил xorg, mesa, icewm и Cinelerra-GG.

Запускаю и наблюдаю те же лаги.

Потом решил что а вдруг оно будет нормально работать под XWayland. Поставил для прикола Gnome 43. И, внезапно, стало работать в разы плавней.

Потом я поставил Mate и… Тут Cinelerra-GG показала очень хорошую производительность временной шкалы. Странно, ведь IceWM в разы легче. Тестировал и в майнлайн ядре, и в кастомном. Результат одинаковый.

Делал в очередной раз в Cinelerra-GG очередной 1080p ролик в прокси-режиме на Orange Pi 4.

И как мне уже писали еще в январе 2021 года

Лучше даже не пытаться скомпилировать и запустить это на RPI. Производительность тебя разочарует…

Долго был оптимизм по работе с этой программой, но… Похоже без дискретной графической карты и серьёзного процессора, а также 16 GB+ оперативной памяти лучше эту программу не использовать.

Так что… Теперь буду изучать VapourSynth и AviSynth+ по совету из той же темы:

Под ARM лучше попробовать AviSynth+.

на одноплатниках только ffmpeg в консоли.

А как чистым ffmpeg в консоли делать анимации?

Или для создания анимаций лучше освоить связку imagemagick + ffmpeg?

Никогда не делал анимации, но думаю можно

Поставил для анекдота labwc (аналог openbox для wayland). Запустил Cinelerra-GG через XWayland на Orange Pi 4 с ArchLinuxARM и о чудо… Задержек в окне временной шкалы в Cinelerra-GG стало в разы меньше… Считай работает почти на уровне комфорта.

Для сравнения еще гонял Kdenlive в labwc, там конечно временная шкала не лагает, но сам предпросмотр работает не очень. Хотя я тестировал в прокси-режиме 360p.

в общем пока понятно что ничего не понятно )

Можно видео записать чем-нибудь типа консольного ффмпег (там есть kms fb input - интересно он wayland захватит или нет?) как лагает в разных средах и выложить куда-нибудь.

Еще есть https://cinelerra-gg.org/download/CinelerraGG_Manual/Piping_Video_Command_Line.html

т.е настраиваешь консольный ффмпег или совместимый кодер и ему шлешь видеопоток yuv4mpeg. А уж он аппаратно его жмёт. Недостаток - звук надо отдельным проходом выгонять.

aw, видеозахват на Вэйланде может не работать напрямую (https://trac.ffmpeg.org/ticket/8542), но есть воркэраунд.

https://github.com/cyanreg/txproto

еще забавная прога - менеджер энкодинга на питоне, работает через ффмпег же

https://www.willusher.io/general/2020/11/15/hw-accel-encoding-rpi4

в общем для rk3399 вроде как можно собрать форк ffmpeg 4.4 с поддержкой v4l2 request api .

https://wiki.pine64.org/wiki/Mainline_Hardware_Decoding

А уж поверх него собрать cingg, если конечно на этом форке аппаратный декодинг заведется.

так-то был проект libva-v4l2 но там в нестабильном апи проблема

https://github.com/bootlin/libva-v4l2-request/pull/38

выше 5.14 пока никто не осилил.

Ужас конечно - победные реляции о работающем аппаратном декодировании на ванильном ядре до сих пор про gstreamer фактически. Ну или медиацентр типа kodi.

Оно конечно и так неплохо, но последние 10% похоже опять как всегда самые трудные.

https://forum.armbian.com/topic/13622-mainline-vpu/?do=findComment&comment=129584

вот тут в прошлом году пост детально расписывал как конфигурировать форк ффмпег-а.

Можно видео записать чем-нибудь типа консольного ффмпег (там есть kms fb input - интересно он wayland захватит или нет?) как лагает в разных средах и выложить куда-нибудь.

Ну то есть запилить видео о производительности Cinelerra-GG на Orange Pi 4 в разных средах рабочего стола? Да, пожалуй, могу. Проще всего на видеокамеру отстрелять монитор, так лишних задержек не будет.

в общем для rk3399 вроде как можно собрать форк ffmpeg 4.4 с поддержкой v4l2 request api .

https://wiki.pine64.org/wiki/Mainline_Hardware_Decoding

А уж поверх него собрать cingg, если конечно на этом форке аппаратный декодинг заведется.

Звучит очень интересно. Обещают вроде 1080p декодинг и энкодинг на открытом драйвере. Вот только пока не понял как хотя-бы чистый ffmpeg и ведро linux’а подготовить к этому. Вангую, что прирост производительности в CinGG должен вырасти в разы. Единственное, я так понял, надо в список аппаратных ускорений CinGG добавить v4l2 и загнать туда модифицированный ffmpeg. И по-идее процессор будет отдыхать… А VPU должен будет отрабатывать свой хлеб…

выше 5.14 пока никто не осилил.

uname -a
Linux alarm 5.15.69-rockchip64 #22.08.2 SMP PREEMPT Wed Sep 21 19:28:26 UTC 2022 aarch64 GNU/Linux

https://www.willusher.io/general/2020/11/15/hw-accel-encoding-rpi4

Кстати, на RPI3 в Raspberry Pi OS 32-bit через встроенный в дистрибутив ffmpeg аппаратный энкодинг у меня вроде работает (уменьшился расход оперативки, fps при энкодинге уже не 2, а 7), но в интернете жалуются на его низкую производительность через ffmpeg.

ffplay с какого-то перепуга у меня на raspberry pi 3 не понимает v4l2m2, но с VLC 1080p ролики идут просто как горячие пирожки.

Что-то мне кажется это не сильно удобным вариантом пытаться завести аппаратное ускорение VPU на Orange Pi 4, учитывая что вроде 1/6 прокси-клипы в формате AVI, созданные отдельно от Cinelerra-GG посредством ffmpeg (Cinelerra-GG почему-то быстро съедает оперативку и компьютер встаёт при создании прокси-клипов в самой программе) работают вполне себе сносно. Ускорение 9x через кривые, анимация камеры и проектора, эффект «гистограмма безье» вроде сильно не напрягают процессор. В связке с labwc (без cin-gg полное потребление озу на холостом старте - 85-90 МБ, нагрузка на цп практически отсутствует) предпросмотр в окне композитора даже вполне себе работает плавно. Не то что в IceWM и WindowMaker.

А на рендер, гляжу, всё-таки надо прикупить китайский паленый SSD из Aliexpress для подкачки, т.к. опять жор оперативки усиленный.

Кстати в Jetson Nano через тот самый патченный ffmpeg в программе ffplay с кодеком h264_nvmpi плавность была просто кинематографическая. Без единого разрыва. Я аж по-приколу тогда еще баланс белого в ffplay настроил и опять плавно. Процессор был без нагрузки. Да и рендерил через ffmpeg с кодеком h264_nvmpi вполне бодро. Кажется, около 20 fps что-ли…

Правда эту железку я уже успел сбагрить. А зря…

часть оперативки съедает x264, если конечно сжимаешь им. У меня на ноуте с интелом vaapi сжатие именно что не только уменьшало потребление процессора, но и память процесс cin ел существенно меньше.

Еще есть https://cinelerra-gg.org/download/CinelerraGG_Manual/Piping_Video_Command_Line.html

Вот это очень интересная опция. У меня так VapourSynth видео рендерит. А как там будут обстоять дела с потреблением оперативки при рендере в raw yuv?

(Исходные ролики в формате MTS)

я думаю что память оно будет потреблять меньше чем энкодер которому нужно проглотить несколько фрэймов чтобы вычислить движение (motion estimation).

Постараюсь сегодня попробовать и отписаться.

Я уже испытал. Ест 2 гига максимум при простом, но заборчатом 5-минутном рендере в 1080p 25 fps. Процессор часто на 35% нагрузки. Это уже куда интереснее чем было раньше. Правда такой ролик занял 22 гига, но это решается внешними носителями. Оно понятно, RAW-формат как-никак.

Теперь другой вопрос: Какие исходные кодеки работают как швейцарские часы при рендере? А то у меня при переключении между нарезанными клипами прямо на отрендеренном ролике черный экран. Впечатление как-то портится после долгого видеомонтажа.

(оригинал: .MTS с камеры | прокси: .proxy6-MTS.avi через ffmpeg без каких-либо опций кроме изменения масштаба в 6 раз)

А то у меня при переключении между нарезанными клипами прямо на отрендеренном ролике черный экран.

даже не знаю что это так. Я делал тест-ролик со сжатием mjpeg/mov в ффмпег - так там черный кусок был из-за того что аудио часть получилась длиннее видео. Еще при захвате было нечто подобное в зависимости от параметров синхронизации. Эта проблема только при использовании прокси сделанных любым способом вылезает? Или вообще всегда?

Когда-то в 2019 году у меня была возможность гонять cinelerra-gg на чужом компьютере с AMD A6 и 12 гигами оперативки. Прокси-клипы создавались в самой cinelerr’е в формате .ts, и никаких проблем с рассинхроном и чёрными переходами не было.

Если гоняю монтаж в 480p(ProRes) на одноплатнике без каких-либо прокси, то проблем вообще нет.

Проблемы возникают, когда я начинаю хотеть чего-то странного, а именно 1080p видеомонтаж на дешёвом железе с фиговым количеством оперативки. Если клипов мало, то без проблем создаются прокси-клипы. Но я, как всегда, когда беру камеру в руки, не могу остановиться и снимаю много видеоматериала, и тут программу клинит на создании прокси. Не знаю зачем, но при создании прокси, программа тупо забивает оперативку и всё зависает.

Воспользовался ffmpeg-ом для создания прокси-клипов в формате AVI и столкнулся с проблемой чёрного изображения при переключении между клипами, не знаю как решить.

В формате .MTS действительно заметил, что аудиодорожка длиннее видеодорожки, чего не наблюдаю в формате AVI. Но прокси-клипы в формате AVI у меня без аудио-дорожки. Количество кадров в секунду одинаковое - 25 fps.

А если прокси клипы тоже создать в контейнере mov/mts ?

Надо будет попробовать…