Posts by tecfreak

Hallo,

ich habe ein seltsames Problem mit einem meiner Clients.

Bei diesem Client (Client#1) wird das OSD total falsch dargestellt wie auf dem screenshot zu sehen:

Das Theme ist hier übrigens "Orange" wie auf dem anderen Client auch.

Auf einem anderen Client (Client#2) mit dem identischen Softwarestand (Kubuntu 18.04.2; linux 4.18 hwe) und config sieht das dagegen ganz normal aus:

Beide nutzen das yavdr/experimental-main und das seahawk1986-hotmail/vdr-2.4.1 PPA und Nvidia 430.26 aus dem graphics PPA (390.116 auch schon erfolglos probiert). Ich habe auch schon vdr Pakete aus frodo's PPA und dem yavdr/experimental-vdr PPA probiert, aber Client#1 zeigt immer das gleiche Fehlerbild. Als Ausgabeplugin wird softhddevice 0.7.0 genutzt und entsprechend ffmpeg 3.4.6 aus experimental-main nehme ich an. Ausgabe läuft mit 50Hz und compositing ist deaktiviert wenn softhddevice attached wird.

Client#1 hat eine GT 730

Client#2 hat eine GTX 1050ti

Vorher lief auf Client#1 noch Kubuntu 14.04 precise mit yavdr Paketen ohne Probleme. vdr/softhddevice/skindesigner ist das einzige was aktuell Probleme macht, Kodi und andere Anwendungen laufen dagegen problemlos. Das OSD bei Client#1 ist egal mit welchem Skin immer fehlerhaft. Im Log ist absolut nichts zu erkennen.

Jemand eine Idee?

Unter /proc/asound/card0 hast du mehrere files mit dem Namensschema eld#0.n. Die Reihenfolge entsprich der Ausgabe von 'aplay -l'.

Wenn in einem dieser files die Variable "monitor_present" auf 1 steht und zusätzlich weitere Informationen zum Ausgabegerät drin stehen, dann hast du das richtige Gerät gefunden und kannst es entsprechend zuordnen.

Ansonsten schau mal mit 'alsamixer' ob das device nicht etwa gemutet ist. Mit 'alsactl store' kannst du die Änderungen die du mit dem alsamixer vornimmst dauerhaft speichern.

Schau mal unter /proc/asound

Evtl. hilft dir das schon weiter.

Weiß jemand ob es für irexec eine alternative gibt wenn man auf lirc verzichten möchte?

Ich nutze es um diverse Befehle auszuführen und um mit Hilfe von xte die Eingabe der FB in Tastatureingaben "umzuwandeln". Das fand ich bisher sehr bequem.

Quote from kls

Linux vdr4 4.12.14-lp150.12.45-default

Wenn ich micht recht entsinne, dann war das serial_ir modul im 4.12er noch etwas buggy.

dippes

Ist compositing bei dir aktiv wenn softhddevice läuft?

Quote from mamomoz

Ich probier das heute Abend mal. Ich bin gespannt.

Das sind eigentlich standard settings die man nicht explizit setzen muss. HDR wirst du eh nicht zum TV bekommen, also braucht man da auch nichts verstellen.

lnj

Bringt uns leider ohne HEVC Main10 support nichts.

Wenn überhaupt, dann eine Anfrage an Phoronix stellen oder es einfach auf nv devtalk versuchen. Die Antwort von Nvidia kann ich aber jetzt schon verraten - es gibt keine Infos zu zukünftigen bzw. nicht umgesetzten Features.

SurfaceCleanerZ

Dieser Entwurf ist aber schon über ein Jahr alt und seit dem liest man auf der xorg ML nichts mehr darüber. Nun darf man sich fragen ob NV es komplett verworfen oder nur auf Eis gelegt hat.

Solange das nicht implementiert ist werden wir nie HDR über HDMI bekommen und dann ist es auch noch fraglich ob NV das dann auch für Geforce Karten freigibt.

Quote from jojo61

Derzteit ist fix Adapive deinterlacing eingestellt.

Sorry für die blöde Frage, aber was bedeutet "Adaptive" hier genau bzw. welche Deinterlacing Techniken sind mit cuvid denn überhaupt verfügbar?

Bei VDPAU habe ich z.B. temporal/spatial bei interlaced Material sehr geschätzt und bei SD Sendern den HQ Scaler und die denoise und sharpen Funktion. Fällt das mit cuvid weg?

Seid ihr euch überhaupt sicher, dass es ausreicht die Ausgabe auf 10 Bit zu stellen um HDR Material korrekt wiederzugeben?

https://www.x.org/wiki/Events/XDC2017/goins_hdr.pdf

Das war letztes jahr. Mehr als ein Entwurf ist bis heute nicht bei rausgekommen.

Quote from CKone

hab ich mit boblight-x11 probiert, das hyperion ist ja mehr oder weniger ein Fork: geht nicht, die HUE sind hier einfach nur weiß

Hab es jetzt mit hyperion-x11 probiert. Läuft 1A

CKone

Planst du in das ffmpeg in deinem ppa wieder den alten patch einzubauen?

Ich nutze dein repo wegen dem zapcockpit patch und weil du softhdcuvid auch gegen nvidia-396 baust.
Vielen Dank an der Stelle dafür und natürlich auch Danke an jojo61 für das tolle Plugin und seahawk1986 für die Paketpflege und alle anderen die sich hier beteiligen.

Das plugin läuft soweit ganz gut bis auf aktuell die SD Sender und ist auch schon im Produktiveinsatz. Sogar TravelXP 4K läuft ohne Probleme.

Quote from Paulaner

Würde dann ein i5 3470 ausreichen? Oder was müsste ich mindestens nehmen?

Ja, im Prinzip jeder i5 aus der dritten Generation, also i5 33xx, 34xx oder 35xx. Die i3 haben leider nur einen PCIe 2.0 Controller. Erst in der nachfolgenden Generation hatten die i3 auch PCIe 3.0, aber da müsstest du schon Mainboard und RAM tauschen.

Würde mit dem Kauf aber auf jeden Fall noch warten bis jemand bestätigt, dass ein PCIe 3.0 Interface auch wirklich Abhilfe schafft.

iNOB

Ich meinte sowas wie deinterlacing, denoise, sharpen usw. in den plugin settings.

Paulaner

Für PCIe Gen3 müsstest du bei dir nur die CPU tauschen gegen eine i5 34xx wenn es denn am Linkspeed/Durchsatz liegt.

jsffm

Mit der P400 laufen bei dir alle UHD Sender ohne Ruckler?

Denn die GPU der P400 ist nochmal deutlich schwächer als die der GT 1030 und ebenso ist der VRAM deutlich langsamer mit 32GB/s. Einzig der PCIe Bus ist hier voll ausgebaut mit 16 Lanes satt nur mit 4 wie bei der GT 1030.

Ist hier überhaupt irgendjemand bei dem die GT 1030 ohne Ruckler läuft bzw. jemand der diese Karte über PCIe Gen3 anbindet?

Quote from iNOB

Für UHD langt das augenscheinlich nicht.

https://en.wikipedia.org/wiki/…ess#History_and_revisions

Das ist jetzt die Frage wieso die 1GB/s hier nicht ausreichen wenn der Datenstrom noch encodiert in den VRAM wandert und laut jojo61 bis zur Ausgabe auf dem Bildschirm dort verbleibt.

Oder es hat damit überhaupt nichts zu tun und die Ursache ist in eurem Fall eine andere. Die GPU/SM Last von 100% bei den GT 1030 würde eigentlich bedeuten, dass die GPU einfach zu langsam ist und nicht hinterher kommt. Die ältere GTX 950 z.B. ist da schon deutlich performanter.

https://browser.geekbench.com/cuda-benchmarks

Irgendeine Form von PostProcessing ist bei auch aber nicht aktiv, oder?

Quote from jsffm

Nach dieser Tabelle kann meine GTX 950 kein hevc_nvenc, sie macht das aber problemlos in guter Geschwindigkeit.

Encodieren? NVDEC ja, aber nicht NVENC bei HEVC.

Quote from Paulaner

Und wenn ich das Ganze dann nochmal mit nvidia-smi -q mache und mir dann ein paar Werte genauer ansehe, dann kann man erkennen, was der Wert "sm" bedeuten kann: GPU Utilization. Die Werte hier entsprechen nämlich genau den Werten von "sm".

"sm" steht meines Wissens nach für "Streaming Multiprocessor".

Welche GT 1030 habt ihr denn genau?

Es gibt ja Modelle mit GDDR5 und welche mit DDR4 VRAM. Erstere machen 48GB/s und letztere nur 16.8GB/s was für UHD wohl zu langsam sein könnte.

Hier ist eine Übersicht welche GPU was kann:

https://developer.nvidia.com/v…decode-gpu-support-matrix

Für UHD mit H265/HEVC sind die GPUs ab der Maxwell 2.0 Gen relevant, also ab GTX 950 und den wenigen GTX 750 die es mit einer GM206 GPU gab.

GTX 950 -> 2GB GDDR5, 1650MHz, 128bit, 106GB/s - PCIe 3.0 x16

P400 -> 2GB GDDR5, 1000MHz, 64bit, 32GB/s - PCIe 3.0 x16

GT 1030 DDR4 -> 2GB DDR4, 1050MHz, 64bit, 16.8GB/s - PCIe 3.0 x16 (x4)

GT 1030 GDDR5 -> 2GB GDDR5, 1500MHz, 64bit, 48GB/s - PCIe 3.0 x16 (x4)

GTX 1050 2G -> 2GB GDDR5, 1750MHz, 128bit, 112GB/s - PCIe 3.0 x16

GTX 1050 3G -> 3GB GDDR5, 1750MHz, 96bit, 84GB/s - PCIe 3.0 x16

GTX 1050 Ti -> 4GB GDDR5, 1750MHz, 128bit, 112GB/s - PCIe 3.0 x16

Die GT 1030 ist das einzige Modell mit nur 4 PCIe Lanes. Hier könnte es durchaus sein, dass das Board PCIe 3.0 haben muss. Bei den anderen mit vollen 16 Lanes sollte PCIe 2.0 eigentlich bereits völlig ausreichend sein.

Das DDR4 Modell der GT 1030 ist mit den mageren 16.8GB/s Speicherbandbreite mit hoher Wahrscheinlichkeit zu langsam für UHD.