История изменений
Исправление 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, :
Гы, он оказывается гораздо более вменяемо чем 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 года»