Posts by Dr. Seltsam

schau auch mal, ob passthrough aktiviert ist.

schnoefftel wrote:

Den Ton gebe ich nur in Stereo aus

das ist wahrscheinlich ursächlich dafür, dass Du keine Stotter-Probleme hast. Im LibreElec-Forum gibt es diverse Aussagen, dass es mit Mehrkanal-Ausgabe stottert. Magst Du nochmal schauen, was unter Einstellungen - Player unter "Hardwarebeschleunigung" konfiguriert ist? Wahrscheinlich OMX-Player aus und MMAL an?

schnoefftel wrote:

Bei mir läuft mittlerweile ein Pi4 und ersetzt einen NUC I3. Mit Libreelec 9.2 kann ich keine Probleme feststellen. Ab und zu mal leichte Schlieren bei Menübewegungen. Das ist aber jammern auf hohem Niveau.

wie gibst Du den Ton aus? Geht 5.1 mit passthrough? Oder ruckelt es dann?

Erfolgt die Videoausgabe über mmal oder ohne Hardwarebeschleunigung?

So eine Lösung habe ich seit langem erfolgreich im Einsatz.

ich glaube, das ist abhängig von der jeweiligen softhddevice-Version (inzwischen gibt es glaube ich mehr Forks/Branches als aktive vdr-Nutzer), den im Makefile vor dem Kompilieren aktivierten Optionen, der ffmpeg-Version, dem Treiber, dem jeweiligen Film und der Mondphase. Mal kann man spulen, mal nicht. Mal nur vorwärts, mal nur rückwärts, mal gar nicht, mal beides. Ich rege mich darüber nicht mehr auf...

mighty-p wrote:

Eigentlich müsste doch auch nvidia mit vdpau auch noch gehen, wenn man die ffmpeg manuell in einer kleineren Version (z. B. 3.3.x) in /opt installiert und dann softhddevice gegen dieser Version linkt (also beim Kompilieren/Starten PKG_CONFIG_PATH bzw. LD_LIBRARY_PATH passend setzt).

Kann mir das jemand mal genauer erklären?

Ich habe unter Ubuntu 19.10 manuell ffmpeg 3.4.7 mit --prefix=/opt/ffmpeg-3.4.7 konfiguriert und kompiliert. Unter /opt/ffmpeg-3.4.7 liegen jetzt also die Ordner bin, include, lib und share.

Was genau muss ich jetzt beim Kompilieren von vdr mit softhddevice-Plugin machen, damit das Plugin gegen ffmpeg 3.4.7 gebaut wird und auch diese libs benutzt?

ich habe das nochmal genauer geprüft. Es war doch noch Ubuntu 19.04 installiert, und lief mit einem 5er-backport-Kernel, der möglicherweise keine Unterstützung für Multicast enthält. Nach einem upgrade auf Ubuntu 19.10 läuft MagentaTV nun.

Nachtrag: Es liegt nicht am vdr. Ich kriege auf dem Intel-Rechner auch beim Aufruf von rtp://87.141.215.251@232.0.20.35:10000 kein Bild mit dem vlc. Auf dem Rechner ist Ubuntu 19.10 installiert - was kann denn da noch softwareseitig fehlen?? Hardwareseitig bin ich ratlos - Magenta-TV ist doch auch noch h264, und das wird ansonsten einwandfrei abgespielt.

Ich kriege auf meinem Test-VDR mit Intel-Ausgabe die Magenta-Kanäke nicht zum Laufen. Das Bild bleibt schwarz, im Log wird kein Fehler ausgewiesen. Gleiches Problem sowohl mit vaapidevice als auch softhddevice. Vor der Umstellung funktionierten die Entertain-Kanäle einwandfrei.

Die gleichen channels.conf-Einträge (egal ob aus dem Muster von fnu oder modifiziert auf Frequenz < 20000) lauifen auf dem Haupt-VDR mit Nvidia-Ausgabe einwandfrei. Ich stehe vor einem Rätsel. Die Versionsstände von vdr und plugins sind gleich. Und Netzwerk hat der Test-VDR natürlich auch, hängt am gleichen Switch.

ich kann das bestätigen. PIDs werden hier auch geändert.

Hast Du osdteletext am Laufen? Eventuell hängt es damit zusammen.

probier mal softhddevice oder eine ältere vaapidevice-Version. Ich füge mal die vaapidevice-Version vom 20.02.2018 bei. Da ist bereits ein Patch für neuere ffmpeg-Versionen enthalten, so dass es kompiliert.

Damit sollte der grüne Pixelsalat nicht mehr auftreten. Trotzdem läuft es bei mir um Welten instabiler als der alte VDR mit VDPAU und Nvidia GT520. Und ein sichtbar besseres Bild liefert die Nvidia auch noch.

pino wrote:

Kann ich nur bestätigen.

Libreelec 9.2 auf RPI4 ruckelt und daher derzeit völlig unbrauchbar.

Pino

Vor dem Hintergrund der Ankündigung der LibreELEC-Macher zur 9.2.0

Quote

"In this initial release 1080p playback behaviour and performance on the 4B are broadly on-par with the previous 3B/3B+ model, except for HEVC media which is now hardware decoded and massively improved."

ist das frustrierend. Gibt es hier weitere Erfahrungen von anderen?

läuft bei Euch Kodi auf dem Pi 4 flüssig? 1080p24 wirkt bei schnellen Bewegungen nicht ganz flüssig, fast schon ruckelnd. Es ist Libreelec 9.2 installiert. Der TV schaltet auch richtig auf 24Hz um.

Auf dem Raspi 2 läuft es hingegen flüssig. Ich meine gelesen zu haben, zumindest 1080p sei bei dem neuen Raspi 4 nunmehr auf dem Niveau der Generation 1-3. Davon kann aber keine Rede sein, so ist die Box unbrauchbar.

ersetzt der aufgeführte Code die bisherige vlc2iptv komplett oder ist nur ein bestimmter Abschnitt zu modifizieren?

Ich bin hier am verzweifeln. kls sagt, dass das vaapidevice mit git-Stand 18.November 2018 bei ihm auf dem J4105M stabil funktioniert. Ich hatte zeitweilig sogar seine Umgebung (openSUSE 15.0. mit manuell installierten libva und intel-vaapi-driver aus dem git von Intel sowie ffmpeg 4.0) installiert, habe dort aber die gleichen Probleme und bin wieder zurück auf derzeit Xubuntu 19.04., das aber gegenüber 18.04. keine Verbesserung brachte - allenfalls die Bildqualität hat sich in Punkto Detailschärfe möglicherweise etwas verbessert.

Auch ein Versuch unter Xubuntu 19.10 ergab die gleichen Probleme.

Ich habe jeweils sowohl die libva+Treiber von Ubuntu als auch jeweils die neuesten aus dem gut probiert. Ebenfalls verschiedene Versionen von ffmpeg.

Fazit ist weiterhin:

• vdr mit softhddevice oder vaapidevice bis 20.02.18 laufen mit Einschränkungen (alle paar Minuten sausen Artefakte durchs Bild oder das BIld bleibt stehen/wird schwarz)
• Das aktuelle vaapidevice läuft grottig - bei SD-Sendern gibt es gelegentlich beim Umschalten und generell, wenn vdr auf einem SD-Kanal startet, Pixelsalat.

Der x-server läuft auf 1920x1080 mit dieser xorg.conf:

Kann jemand, bei dem die Ausgabe über Intel UHD Graphics 600 (Gemini-Lake-Generation) stabil läuft, mal seine Ausgabe von vainfo (ist Teil der libva-utils) posten?

Ich suche im Moment auch noch nach einer Erklärung, warum der TV nach ein paar Minuten immer auf "no signal" schaltet, obwohl in den xfce-Einstellungen die Bildschirm-Energieverwaltung bereits aus ist. Das HDMI-Kabel geht vom Mainboard in den AVR und der Ausgang des AVR in den TV. Der AVR ist so eingestellt, dass er im Stand-by das Signal durchschleust. Das klappt beim VDR2 mit Nvidia-Grafik auch problemlos. Nur beim VDR1 mit Intel-Ausgabe verschwindet das Bild immer wieder und ich muss dann den AVR ein- und wieder ausschalten, damit es wieder beim TV ankommt.

und Artefakte huschen weiterhin gelegentlich durchs Bild

richtig stabil läuft das leider auch nicht.

Mittendrin beim Live-TV wird das Bild plötzlich schwarz und kommt auch nach dem Umschalten nicht wieder

xorg läuft auf 1920x1080@50. Dieses OSD-Problem hatte ich mit softhddevice übrigens nicht.

Die Skalierung steht auf normal, und ich habe sowohl Bob als auch Motion Adaptive probiert. Asynchronitäten habe ich ebenfalls.

Zwischen 20.02.18 und Anfang März gab es im vaapidevice so viele Umbaumaßnahmen, dass es schwer werden wird herauszufinden, ob und welcher einzelne commit die Ursache ist.

Was mich mal interessieren würde: Was für Versionen von Plugin, ffmpeg benutzen denn die Leute, die von der Intel-Ausgabe so schwärmen, und was sagt dort vainfo?

Danke, das hat funktioniert. In code.cmusste CODEC_CAP_HWACCEL noch durch AV_CODEC_CAP_HARDWARE ersetzt werden.

Wenn der vdr auf einem SD-Kanal startet, kommt das grüne Pixelgewitter jetzt nicht mehr (es kam vorher auf HD-Kanälen meistens -vielleicht sogar immer- auch nicht). Das OSD ist weiterhin beim Start nicht gleich in richtiger Größe vorhanden.

Dazu habe ich hier übrigens etwas gefunden:

https://github.com/pesintta/vdr-plugin-vaapidevice/pull/122

Quote

TODO:

• black surface should be displayed if no video data available
• initial osd not drawn at startup
• ffmpeg stream info issues with some test recordings and rofafor#4
• occasional lip sync issues with huge negative A/V drift values

Ob der Rest besser läuft, muss ich morgen testen.

Bislang kann ich noch nicht erkennen, warum ich nicht einfach wieder meine Nvidia-Karte einstecken sollte und mit einem älteren ffmpeg und VDPAU weiterarbeite. Das hat wenigstens stabil funktioniert, und das Bild war auch brillianter.

Der Revisionsstand 6372704835b62bee882feed92686edc75e70b55f vom vaapidevice kompiliert bei mir nicht: