LINUX.ORG.RU

Gstreamer - гоняет кто кроссплатформенно для воспроизведения?

 


0

1

После некоторых метаний между vlc+vlcj (хорошая акселерация и много-экземплярная работа но проблемы с gapless и регулярные падения на ровном месте) и mpv+ipc (шустрый но сильно ограниченная много-экземплярность и отсутствие возможности встраивать окно из коробки) обнаружил что у gstreamer’а не только Ява байдинги весьма уютные есть но и нормальное ускорение воспроизведения под оффтопиком завезли.
Нюанс (с) я им по сути никогда особо не пользовался, но собранный за пять минут минимальный вариант рисующего на панельке playbin’a намекает на некоторый успех - многоэкземплярность без проблем, встраивание без проблем, ускорение как минимум есть а как максимум вроде бы не хуже vlc (первые тесты завалил по своей вине)

За сим вопросы:

  • юзает ли его кто-нибудь для воспроизведения в первую очередь? Если да, то вдруг кто поделится историями узбека по одновременной работе 20+ экземпляров или подводными камнями при оной
  • насколько оно кроссплатформенно и железозависимо в плане ускорения декодера 264 и вывода? Например на расбери4 оно нормально подхватывает декодер? А вдруг кто пробовал на олвиннерах типа старого а20?
  • playbin это я правильно понял что «собери мне пайп автоматом я не хочу знать заранее что там у юзера за поток»?
  • никто его с Явой не гоняет? Поделитесь узбеком, опять-таки.
  • почему оно не открывает m3u файл с простым (без метаданных) списком .ts файлов по http? Если добавить мету (например под hls) то открывается и нормально отображается, а просто список файлов - буй (его без проблем открывают vlc/ffplay/mpv). Есть какие то тонкости с форматами? Не критично но просто интересно
★★★★

Я гонял 50+ потоков от IP камер. Вердикт: работает, но капризный. Если будешь на лету менять конвейер, то 100% поимеешь проблем.

С воспроизведением файлов главной проблемой у меня была перемотка. Gstreamer на некоторых файлов тупо отказывался перематывать в нужное место. Пришлось втыкать костыли по типу: дать команду перемотки, проверить перемоталось ли, если нет, то повторно отправить команду и молиться.

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

насколько оно кроссплатформенно и железозависимо в плане ускорения декодера 264 и вывода?

Всё зависит от наличия соответствующих плагинов. Если есть плагины аппаратного декодера и sink с zero copy выводом на экран под твою платформу, то повезло, иначе программное декодирование.

playbin это я правильно понял

Да.


Лично моё мнение, что gstreamer хорош для быстрого прототипирования. Там можно быстро накидать конвейер, который читает, парсит, декодит, постпроцессит и выводит на экран, причём с синхронизацией звука и видео. На голом ffmpeg на это ушли бы недели. Но вот если gstreamer глючит, то пофиксить будет нереально. Будешь сидеть и ждать новую версию с исправлениями.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Вердикт: работает

Спасибо, это главное! :-)

Если будешь на лету менять конвейер

не, меня устроит менять на лету только uri до источника. в идеале еще менять позиции в плейлисте но я чот начинаю подозревать что с плейлистами будет печалька и о gapless придётся забыть ( https://stackoverflow.com/questions/72689521/gstreamer-open-plain-m3u-from-http )
правда это не большая проблема если получится нормально поднять webrtc

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

Но вот если gstreamer глючит, то пофиксить будет нереально. Будешь сидеть и ждать новую версию с исправлениями.

тут такое дело - я года три пытаюсь заставить vlcj работать «штабильно». в итоге каждый раз я огребаю «это известный баг/не проблема на стороне явы/vlcj а проблема на стороне libvlc - их никто не решает по 10 лет так что терпите»
пробежавшись по типовым случаям вылета vlcj (а он вылетает прям сразу со всей jvm) - gstreamer выдержал все окромя одного сценария (педалить setURI + play для одного и того-же экземпляра из нескольких потоков одновременно) который легко не допускать (правда gstreamer тоже умудрился завалить jvm)

Если есть плагины аппаратного декодера и sink с zero copy

вот и интересно под какие есть.
я пробовал gstreamer года три назад - под линем x86/amd64 работало нормально, под расбери на armhf его тогда допиливали, под arm64 оно вроде не особо умело (да и тогда не особо надо было) а под оффтопиком было медленно (не вникал особо почему).
сейчас под оффтопиком = норм, под расбери на armhf наверняка запилили (проверю на неделе) под arm64 с rk3xxx - проверю. С А20 сложнее - vlc на нём падал в кому при попытке подоткнуть декодер :-)
На маке нет возможности проверить но вроде исторически работает если отключить кварц

На голом ffmpeg на это ушли бы недели

у меня на нём почти вся сборка/хранение/раздача организованы, но отображение на ffplay потребует оконного менеджера (или труЪ навыков по вколхоживанию видео слоя на awt компонент в чём я не силён) а у меня его может не быть :-(
с gstreamer+java bindings получается обходится штатным jinternalframe если нет внешнего менеджера

rukez ★★★★
() автор топика
Ответ на: комментарий от rukez

Гы, он оказывается гораздо более вменяемо чем vlcj себя ведёт при перетыкании файлов - не совсем gapless но визуально без разрывов, правда пока не пробовал трафик лимитировать чтоб буфер наполнялся подольше

Из нюансов - на ровном месте иногда выстреливает Bus.ERROR() и его таки надо обрабатывать учитывая что endOfStream() при этом НЕ выстреливает (в files тупо разобранный по строчкам m3u без мета данных, соотв. в любой момент можно прыгнуть в любое место листа через setURI и поменяв filesIndex):

playbin.getBus().connect(new Bus.EOS() {
                @Override
                public void endOfStream(GstObject source) {
                    EventQueue.invokeLater(() -> {
                        if (filesIndex < files.length) {
                            try {
                                playbin.stop();
                                playbin.setURI(new URI(request + files[filesIndex]));
                                playbin.play();
                                System.out.println("SWITCHED TO: " + request + files[filesIndex]);
                            } catch (Exception e){
                                e.printStackTrace();
                            }
                        }
                        filesIndex++;
                    });
                }
            });

            playbin.getBus().connect(new Bus.ERROR() {
                @Override
                public void errorMessage(GstObject gstObject, int i, String s) {
                    EventQueue.invokeLater(() -> {
                        if (filesIndex < files.length) {
                            try {
                                playbin.stop();
                                // filesIndex++; Retry?
                                playbin.setURI(new URI(request + files[filesIndex]));
                                playbin.play();
                                System.out.println("SWITCHED ON ERROR TO: " + request + files[filesIndex]); // Error counter?
                            } catch (Exception e){
                                e.printStackTrace();
                            }
                        }
                        filesIndex++;
                    });
                }
            });

решение вроде типовое-очевидное для любого плеера но в vlcj это гарантированный строб. и нет, это не лечится в vlc3, «возможно будет вылечено в vlc4, который уже и так отложен на 2 года»

п.с. правда то-же интересно - при проигрывании .ts файлов с http нагрузка на cpu в 1.5-2 раза выше чем при проигрывании этого-же потока из rtsp по udp о_О

rukez ★★★★
() автор топика
Последнее исправление: rukez (всего исправлений: 1)
Ответ на: комментарий от max_lapshin

Контейнер или конвейер? Если конвейер, то при входе в настройки нужно было отрубить sink’и, которые выводят видео, но оставить те, которые пишут поток в файл. Если удалить виджет (при переходе в настройки, gui у меня меняется), на который в этот момент sink выводить видео, то конвейер подыхал.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Мне тут немного проще - в файл пишет ffmpeg (в hls), а Gstreamer отображает уже из hls

По сабжу:

  • под оффтопиком работает на заглядение что в режиме кадрочиталки с выводом на volatileimage средствами явы что в режиме приклеивания слоя на канвас (тут чот с документацией беда в Ява байндингах но в почтовой обсуждалке можно найти хотяб намеки на то как это стартовать) - второе в два раза шустрее но нагрузка и так крохи ибо volatile под оффтопиком хорошо ускорен
  • под онтопиком все хуже в плане производительности - одинаковый набор потоков лопает в 2-3 раза больше ресурсов в каждом случае но терпимо (с)
  • под онтопиком и армами (rk3399 сейчас в основном гоняю) volatile полная печаль по производительности (ибо чисто программный) а со слоем - весьма недурно, хотя vlc вроде как был пошустрее один фиг.

Пробовал погонять под javafx - не особо заметил разницы правда не пробовал пока включать новые плюшки из 17 (они вроде из 13 но я на лтс сижу) с быстрыми буферами.

Вообщем - годно (с)

rukez ★★★★
() автор топика
Ответ на: комментарий от ox55ff

я плохо прочитал и вместо «конвеера» прочитал «контейнер».

Теперь понял. Думал, что gstreamer по идее должен к такой смене конвеера относиться лучше.

Вообще тред хороший, сюда можно отправлять людей, когда спрашивают, за что мы деньги берем =)

max_lapshin ★★★★★
()