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

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

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

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

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

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

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

Да.

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

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

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

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

не, меня устроит менять на лету только 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 если нет внешнего менеджера

Гы, он оказывается гораздо более вменяемо чем 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 о_О

а откуда у тебя была смена контейнера с IP камерами?

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

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

По сабжу:

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

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

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

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

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

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