Neuer VDR für UHD

Ich rate mal ins blaue das libva richtig alt ist, das ist noch eine Version von 2016 - meines wissens darf es schon mindestens 1.8 bzw 2.x sein.

Wenn ich mich recht erinnere geht z.B. mit >=1.8 erst 10bit Material.

Zitat von CvH

Ich rate mal ins blaue das libva richtig alt ist, das ist noch eine Version von 2016 - meines wissens darf es schon mindestens 1.8 bzw 2.x sein.

Wenn ich mich recht erinnere geht z.B. mit >=1.8 erst 10bit Material.

Das wird bestimmt ein Puzzleteil sein.

Zitat von mamomoz

Moin,

so ähnliche Ergebnisse hatte ich zuerst auch. Wenn bei der Wiedergabe die Prozessorleistung hoch geht, läuft die Dekodierung des Videos nicht im GPU-Kern.

Ich würde erstmal sicherstellen das vaapi genutzt wird im System.

Vielleicht die Treiber aus dem git selber ziehen und übersetzen.

Dann vielleicht mal ohne VDR/KODI testen.

Ich habe mit ein UHD-Demo-Video runtergeladen und mit XINE abgespielt. Wenn das bei Dir funktioniert ist das System schonmal auf vaapi vorbereitet.

Wie gesagt beim abspielen des UHD-Videos darf es höchstens zu 10-15% Prozessorleistung kommen.

Danach würde ich dann mit VDR/Kodi weitermachen.

Gruß

Alles anzeigen

Was mich halt insgesamt verwundert, ist, dass ich bei softhddevice überhaupt kein Bild sehe, egal wie schlecht.

Also habe ich etwas weiter rumgespielt:

Ich habe mal spaßeshalber ein Beta von Ubuntu Bionic Beaver aufgespielt.

Da ist das libva noch sehr jung.

Was nicht geht:

Wieder Softhddevice im Fenster und versorgt der Einfachheit halber mit einem streamdev-server.

Es wird ganz kurz das der VDR-Senderstatus eingeblendet, welcher dann nach ner Sekunde verschwindet, aber das Bild ist schwarz, obwohl Daten gestreamt werden. Ton habe ich nicht geprüft.

(VDR und Plugins vom Bionic)

Kodi mit VNSI, Daten von fremdem VDR

Geht, aber die Prozessorauslastung ist doch deutlich höher, als das sein sollte. Wird wohl softwareseitig decodiert. Das finde ich seltsam.

(Kodi vom Bionic)

Kodi mit 1080p oder 2160p hevc

Geht und letzteres ruckelt: auch hier scheint die hardwareseitige Decodierung nicht ordentlich mitzuspielen. CPU bei 99%

mpv mit o.g. Daten

Tut wunderbar mit allen Medien auch 2160p hevc 10 bit. Prozessorauslastung minimalst.

(mpv vom Bionic)

Ein Anfang, aber wohl noch viel Arbeit entwicklungsseitig.

Nachtrag: Easyvdr 3.5 crashed bei der Bildschirmerkennung komplett weg.

Ich glaube, CPU und GPU sind einfach noch zu neu für die meisten Distributionen.

Hi,

Könntest du uns bitte ein easyinfo des Systems mit EasyVDR3.5 zukommen lassen bitte? Am Besten im eigenen Thread. Eigentlich sollte es tun.

Danke,

Stefan

Irgendwie bin ich gerade zu faul, zuhause meinen häuslichen Pflichten nachzukommen , daher habe ich mal das nächste im Bunde leicht angetestet seahawk1986 :

Ubuntu-Server Bionic beta mit Yavdr-ansible (Wie geht es mit yavdr weiter ?)

Nun denn, damit habe ich auf alle Fälle mal einen ersten Erfolg mit softhddevice bzw. vaapidevice erzielen können.

Per streamdev habe ich als root Bild und Ton auf meinen Schirm gezaubert:

vdr -l 1 -P"vaapidevice -w alsa-driver-broken -d :0 -f -a hw:0,3 -p hw:0,3 -v va-api" -P streamdev-client

Außer, dass der Ton asynchron war und es irgendwann ruckelte, war das schon mal das bisher beste Ergebnis. Habe aber noch nicht recherchiert, warum da was zwickt. Umschalten geht sogar recht flott. Das syslog ist geflutet mit Einträgen dieser Art (softhddevice analog):

Apr 19 21:05:20 schwarte vdr: [1438] VAAPI-ERROR: video/vaapi: vaPutSurface failed: the requested function is not implemented
Apr 19 21:05:20 schwarte vdr: [1438] VAAPI-ERROR: video/vaapi: vaPutSurface failed: the requested function is not implemented
Apr 19 21:05:20 schwarte vdr: [1657] VAAPI-ERROR: video: display buffer empty, duping frame (4103/1447) 0
Apr 19 21:05:20 schwarte vdr: [1438] VAAPI-ERROR: video/vaapi: vaPutSurface failed: the requested function is not implemented
Apr 19 21:05:20 schwarte vdr: message repeated 2 times: [ [1438] VAAPI-ERROR: video/vaapi: vaPutSurface failed: the requested function is not implemented]
Apr 19 21:05:20 schwarte vdr: [1657] VAAPI-ERROR: video: display buffer empty, duping frame (4104/1447) 0
Apr 19 21:05:20 schwarte vdr: [1438] VAAPI-ERROR: video/vaapi: vaPutSurface failed: the requested function is not implemented
Apr 19 21:05:20 schwarte vdr: [1657] VAAPI-ERROR: video: display buffer empty, duping frame (4105/1447) 0
Apr 19 21:05:20 schwarte vdr: [1438] VAAPI-ERROR: video/vaapi: vaPutSurface failed: the requested function is not implemented
Apr 19 21:05:20 schwarte vdr: [1657] VAAPI-ERROR: video: display buffer empty, duping frame (4106/1447) 0
Apr 19 21:05:20 schwarte vdr: [1438] VAAPI-ERROR: video/vaapi: vaPutSurface failed: the requested function is not implemented
Apr 19 21:05:20 schwarte vdr: [1438] VAAPI-ERROR: video/vaapi: vaPutSurface failed: the requested function is not implemented

Seltsam war auch, dass der Bildschirm gedimmt blieb, wenn man aus dem VDR-Menü rausgeht. Erst ein Umschalten erhellt das Bild wieder.

Das recht nackige Yavdr-Ansible zeigt mir, wieviel Arbeit in so einer Distribution steckt. Wie immer merkt man sowas erst dann, wenn man was haben will, aber nix hat. Daher Hut ab vor allen Entwicklern hier im Forum!

Grüße

Matthias

Für das vaapidevice fehlt noch die Integration in das yavdr-frontend Skript (soweit ich das im Code gesehen habe verhält es sich ähnlich wie softhddevice, ich muss mal schauen, ob ein Haswell-Laptop als Testsystem genügt) und es könnte sein, dass sich das vaapidevice der als root gestarteten VDR-Instanz mit pulseaudio um die Soundkarte streitet.

Ich habe das gerade mal ausprobiert, es fehlt das Paket i965-va-driver und dem yavdr-frontend fehlt python3-distutils (die fehlende Abhängigkeit ergänze ich im Paket python3-yavdrfrontend, das kommt als Update), dann sollte man mit softhddevice ein Bild haben (den X-Server müsste man dann noch für 50Hz konfigurieren). Mit dem pulsecontrol-Plugin musste ich dann nur den Ausgabesink umschalten, um tadellosen Ton zu bekommen.

vaapidevice schau ich mir später an.

Kontrast und Sättigung muss man bei vaapidevice wohl von Hand auf die eigentlichen Standardwerte von 10 setzen (aus irgendeinem Grund setzt das vaapidevice die auf 1, wenn man zum ersten Mal einen Wert abspeichert).

Edit: wenn ich das richtig sehe, ist der Wert falsch gesetzt, mit dem die Variablen initialisiert werden https://github.com/pesintta/vd…13#issuecomment-383031704

Um das bei yavdr-ansible standardmäßig vorinstallierte pulseaudio nutzen zu können, muss man vaapidevice mit -a pulse (und mit -d :0.0 ) starten, die Anpassung des yavdr-frontend Skripts für vaapidevice war unproblematisch und kommt per Paket-Update.

An Paketen für die Grafikausgabe mit intel-IGP braucht es wohl die:

• xserver-xorg-video-intel
• i965-va-driver-shaders

Wie macht ihr das mit der xorg.conf, um einen Modus mit 50 Hz zu bekommen? http://www.vdr-wiki.de/wiki/in…DR4Arch#Intel.28VA-API.29 funtioniert, wenn ich die letzte Section mit den Extensions weglasse.

Hallo,

also das Pulseaudio kriege ich irgendwie nicht gebacken. Ich bin da noch zu doof. Aber solange hw:0,3 tut ist ist für mich alles in Butter.

Bei den Treibern tut der - i965-va-driver-shaders aber auch der ohne shaders: "i965-va-driver". Ich vermag da keinen Unterschied festzustellen.

Ansonsten läuft (nach wie vor über streamdev) der vdr einwandfrei über vaapidevice oder softhddevice (Hardware-Decoding arbeitet). Der Ton lässt sich mit dem Delay auch so einstellen, dass Synchronität vorliegt. Mein Problem oben - man möge an der Stelle über mein Geschick lachen - war wohl, dass ich per root eine zweite vdr-Instanz gestartet habe, weil ich nicht bemerkte, dass durch die yavdr-Installation schon eine lief. Naja, wenn man huddelt...

Kodi aus dem Nightly rennt auch: VNSI-Verbindung i.O., hevc 10bit in 4k auch kein Problem (CPU bei müden 10 %, und wird 55 °C warm).

Das aktuelle Kodi 18 nightly benötigt noch libnfs8. Ohne dieses bricht die Intallation wegen unerfüllter Paketabhängigkeiten ab.

Lösung habe ich hier gefunden: https://tutorialforlinux.com/2…nfs8-ubuntu-18-04-bionic/

Als nächstes will ich von der DVBSky 952 V3 den Empfänger in Kombi mit meiner schon programmierten Harmony nutzen.

Mit LIRC und Konsorten habe ich mich seit dem ctvdr kaum mehr beschäftigt und muss erst mal verstehen, wie das alles eingebunden wird und funktioniert.

Die Firmware der DVBSky habe ich schon mal reinkopiert.

Die DVBSky-Fernbedienung schaltet dann sogar, ohne dass ich irgendwas konfiguriert habe (mit ordentlich Prellen)...?

Das ist wohl ein Feature vom yavdr-ansible, oder?

Zitat von presskopf

Die DVBSky-Fernbedienung schaltet dann sogar, ohne dass ich irgendwas konfiguriert habe (mit ordentlich Prellen)...?

Das ist wohl ein Feature vom yavdr-ansible, oder?

Teilweise. Wenn das ein rc-core Empfänger ist (das siehst du an der Ausgabe von sudo ir-keytable), dann decodiert der Kernel die IR-Signale und gibt sie auf einem Kernel Input Device aus. Bei yaVDR gibt es dann den Dienst eventlircd, der Kernel Input Devices mit edem udev-Attribut eventlircd_enable exklusiv öffnet (https://github.com/yavdr/yavdr…v/98-eventlircd.rules#L63) und diese Tastendrücke auf einem Lirc-kompatiblen Sockel ausgibt, von dem der VDR und KODI lesen.

Wenn es nur im VDR prellt, kannst du in dessen Einstellungen die Zeiten für ignorierte Tastenwiederholungen etwas hochsetzen.

Hi,

Bezüglich der 50Hz UHD Frage kann ich nur sagen, dass es bei easyVDR gerade einen Test mit Trusty gab. Dort fehlten die 50 und 60 Hz Frequenzen immer bei 4096 und 3860 Auflösungen. Mit dem 4.16 waren sie dann plötzlich dabei.

MfG Stefan

So, ich bin endlich dazu gekommen mir auch mein J4105-ITX mal genauer anzusehen. Haben tu ich es schon 'ne Weile, aber die Arbeit liess mir keine Zeit Allerdings ist es bei mir nur ein 'normaler' HD, da ich keinen UHD Fernseher/Monitor hab...

Gestern war erstmal OS installieren, kompilieren und Pakete bauen dran. Spät abends lief dann alles soweit dass ich den vdr starten konnte, der spuckte aber Massen von

VAAPI-ERROR: video/vaapi: vaPutSurface failed 20
VAAPI-ERROR: video: display buffer empty, duping frame (1/0) 0

aus. Ich vermute/hoffe dass das nur daran lag dass das SAT Kabel noch nicht dran war...

Zum Glück ist ja morgen wieder Feiertag