почему видеоплеер Totem — тормозит?

Кривой gstreamer, которым играет totem плохо умеет аппаратное ускорение, как и vlc. Правда на разных видяшках и дровах умения могут сильно отличаться, на невидии с блобом лучше всего аппаратное ускорение умеет mpv.

а что за аппаратное ускорение?

ведь аппаратно декодировать VPX — я так подозреваю что не имеет ни кто? :)

следовательно, имеется ввиду какое-то аппаратное ускорение, связанное с более быстрым выводом картинки на экран?

Как вариант - вычисления на GPU через CUDA. Но и от работы через обёртку в виде gstreamer-а скорость не увеличится.

Запусти его из консоли, перед этим выполнив

export GST_DEBUG_DUMP_DOT_DIR=/tmp/gst-dump/

(Директорию создать надо будет заранее.)

Поглядел я на получившийся граф, узрел там аж три videoconvert в ряд через capsfilter, хотя казалось бы, зачем их столько. Программный декодер выдаёт YV12 картинку, которую можно сразу скармливать в xvimagesink. Но нет, он переводит всё в RGBA, чтобы выводить это на экран. Причём это всё ещё и не заработало у меня.

а чем эти файлы открывать? :-)

totem-prerolled.dot , totem-video-thumbnailer-error.dot

### UPDATED ###

нагуглил «graphviz» .. спасибо! :)

xdot — хороший просмотрщик

спасиб за подсказку про эти дот-файты!

я ещё пока-что не разобрался доконца (сделал ``dot -Tsvg totem-prerolled.dot -o out1.svg``) , но выглядят схемки красиво! :-)

удивительно мне, что какой-то понимаешь-ли глупый-робот может нарисовать аж такое! :-)

блин! этож невиданный возможности! открывать Totem и смотреть что и как (через-что) декодируется! (а с Firefox работает? там же тоже GStreamer :-))

а с Firefox работает? там же тоже GStreamer

В коде должно явно вызываться GST_DEBUG_BIN_TO_DOT_FILE(), в Firefox такого нет. Но там ввод через appsrc, потом playbin, затем вывод через appsink. Кривовато работает.

кстати, выложу ка я в открытый доступ эту схему

http://i4.minus.com/ibonVHeCPyIdbE.png

(а-то вдруг кто-то не имеет возможности построить это)

короче вот что я пока что думаю, ребята...

судя по картинке(*) — для декодирования используется компонент «GstVP9Dec».

http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/vpx/gstvp9dec.h

http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/vpx/gstvp9dec.c

в файле «gstvp9dec.h» — написано:

#include <vpx/vp8dx.h>

очевидно, это значит, что используется библиотека «libvpx» (так как «vpx/vp8dx.h» — это её файл) ..

но в блоге вот-тут — https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/ — написано что якобы реализация декодинга от «libvpx» — отстаёт на несколько процентов от встроенной реализации «VP9» из «ffmpeg».. ну и всякие графики, показывающие ущербность этой библиотеки :-) ..

fvp9 beats libvpx consistently by 25-50%. In practice, this means that typical middle- to high-end hardware will be able to playback 4K content using ffvp9, but not using libvpx. Low-end hardware will struggle to playback even 720p content using libvpx (but do so fine using ffvp9).

к тому же давайте глянем в «gstvp9dec.c» ..

тут есть константа...

#define DEFAULT_THREADS 1

...и эта константа используется как число декодирующих нитей поумолчанию (вручную можно задавать от 1 до 16) — «Maximum number of decoding threads».

то есть, думаю, стоит преположить что Totem НЕ задаёт число нитей (а использует то что поумолчанию).

но давайте для примера посмотрим как это же сделано в компоненте «GstAVVidDec»?

http://cgit.freedesktop.org/gstreamer/gst-ffmpeg/tree/ext/libav/gstavviddec.c

#define DEFAULT_MAX_THREADS		0

это константа которая для — «Maximum number of worker threads to spawn. (0 = auto)»..

очевидно предположить, что в «GstAVVidDec» число нитей автоматически выбирается изходя из числа ядер! в отличии от «GstVP9Dec»!

--------------------------------------------------

что думаете, ребят, на эту тему, i-rinat , peregrine ? может быть причина тормозов Totem — в этом?

плохо умеет аппаратное ускорение, как и vlc

В версии 2.2 они наконец то его сделали вполне нормальным

mpv

поглядел щаз его — не тормозит :) ..

ну и вообще хорошие впечатления оставил он у меня..

GUI конечно же вырвиглазный.. но всё-таки кой-какой минимализм есть — это хорошо :)

GStreamer — это концентрированная боль при попытке хоть чуточку выйти за пределы предложенной канвы. Две недели. Две недели я пытался сделать довольно простую вещь — записывать декодированные кадры в GL текстуры отдельного контекста. Пусть сначала с выгрузкой на CPU, только без явной загрузки руками. Я надеялся, что это поможет в дальнейшем использовать VA-API и преобразовывать кадры прямо в GPU. Но нет. Ничего не вышло. Decodebin почему-то не пускает наружу из себя GLMemory, только сырые I420 кадры. Да и вообще нужная цепочка просто не работает! Даже в gst-launch-1.0! Какое уж там взаимодействие контекстов... Я теперь даже сомневаюсь, что он осилит GLX+GLES2; в документации упоминаются только GLX+GL и EGL+GLES2.

Вот и теперь ещё час убит без прогресса на выяснение способов работы с реестром GStreamer. У плагинов есть ранг, по которому они выбираются при построении цепочки. Теоретически, ранг можно менять не только во время исполнения; у GStreamer есть состояние, которое он хранит в реестре. Только вот как это делать — непонятно. Инструментов нет. Программный способ вроде как не делает ничего, strace не показывает записи в реестр, только чтение. И никаких намёков на то, можно это делать вообще или нет. И даже непонятно, где он вообще его создаёт.