Beiträge von Paulaner

    Nachtrag + Lösung zum oben diskutierten Unterschied bei der Ausführung des Zoom-Befehls in meinem VDR (hier ging es nur mit zusätzlichem Bildwechsel) und dem VDR von Taipan (bei Ihm wurde der Zoom-Befehl sofort ausgeführt)!


    Dank eines Tipps von Taipan , der herausgefunden hatte, dass das "Zoomen" über das softhddevice-Plugin bei Ihm auch nur funktionierte, weil er immer den shady_KISS-Skin verwendet hat. Ich hingegen benutze immer einen etwas abgewandelten simplex-Skin, da ich eine 65"-TV habe und mir da die Skins, welche den gesamten Bildschirm nutzen einfach zu groß sind.

    Als Taipan nun mal den metrix-Skin testen wollte, musste er ebenfalls nach dem Aktivieren des Zoomfaktors "einmal" das Bild wechseln, bevor das Zoomen aktiv war. Zurück zum shady_KISS-Skin und schon funktionierte es sofort wieder!



    Das habe ich nun sofort getestet und siehe da, auch bei mir klappt das Zoomen sofort, wenn ich den shady_KISS-Skin verwende! Und es ist nicht nur der shady-KISS-Skin wo es so funktioniert, sondern auch alle anderen Skins, bei welchen im Hauptmenü des VDR das TV-Bild innerhalb des OSD verschoben und skaliert wird, wie z. B. auch beim estuary4vdr-Skin oder blackhole-Skin.



    Ich habe daraufhin mal die verantwortliche "displaymenumain.xml" aus den Skins angeschaut und da ist sofort aufgefallen, das die 1. Zeile in der XML-Datei etwas anders aussieht, als beim von mir verwendeten simplex-Skin!


    Hier die 1. Zeile der "displaymenumain.xml" aus dem estuary4vdr-Skin:

    Code
    1. <menumain x="0" y="0" width="100%" height="100%" fadetime="0" scaletvx="39%" scaletvy="8%" scaletvwidth="60%" scaletvheight="60%">


    Bei mir hingegen bzw. im verwendeten (etwas abgewandelten) simplex-Skin sieht die 1. Zeile einfach nur so aus:

    Code
    1. <menumain x=x="20%" y="34%" width="60%" height="65%" fadetime="0">


    Beim estuary4vdr-Skin (und auch den anderen o.g. Skins) wird also das TV-Bild beim Öffnen des OSD auf die vorgegebenen Werte verschoben und entsprechend skaliert. Beim Schließen des OSD wird dann wieder das "normale" Vollbild angezeigt. Und das scheint die Ursache dafür zu sein, dass das Zoomen sofort übernommen wird, weil das TV-Bild im softhddevice-Plugin neu gezeichnet werden muss!


    Also habe ich nun einfach mal testweise bei mir ebenso diese Parameter zusätzlich eingefügt und schon hat es sofort funktioniert!

    Ich gehe also ins OSD, wähle den Zoomfaktor und dabei schließt sich das OSD automatisch wieder und sofort ist das gezoomte TV-Bild da, ohne einen zusätzlichen Tastendruck, wie ich es vorher machen musste! Perfekt! :);):)


    Da ich aber nicht das TV-Bild verschieben und skalieren will, habe ich die Parameter für mich etwas angepasst! Nun sieht das bei mir so aus:

    Code
    1. <menumain x="20%" y="34%" width="60%" height="65%" fadetime="0" scaletvx="{areawidth}*0.001" scaletvy="0%" scaletvwidth="100%" scaletvheight="100%">

    Damit wird jetzt beim Öffnen des OSD das TV-Bild lediglich um 0,1% = 2 Pixel (bei 1920x1080px) nach rechts verschoben und nicht weiter skaliert, was dadurch nicht sichtbar ist! Beim Schließen des OSD wird dann wieder das "normale" Vollbild angezeigt! Dadurch klappt nun das Zoomen bei mir perfekt, mit nur einem Tastendruck! :)


    Für mich ist damit das "Zoomen" des Bildes über das softhddevice-Plugin perfekt gelöst und man kann es wirklich sehr komfortabel einsetzen, in dem man einfach in das OSD die entsprechenden Befehle einfügt und das Zoom-Script "zoom_on.sh" (siehe Dateianhang) nach /etc/vdr/scripte kopiert.

    Und wer noch etwas Komfort liebt, der kopiert das Script "softhddevice-zoom-off.conf" nach /etc/init , denn damit wird beim Start des VDR der Zoomlevel wieder auf 0% gesetzt, falls man das mal vergessen haben sollte! Nicht vergessen, das ".txt" wieder zu entfernen, da ich sonst die Scripte nicht hochladen konnte! ;)


    Das ganze funktioniert dann sicherlich (ohne es jetzt explizit getestet zu haben) auch bei jedem anderen Skin, wie z. B. reufer-Skin, metrix-Skin usw.


    Paul

    Das Problem ist das Decoding von 10bit Material, das klappt nicht mit VDPAU, dafür muss man bei NVidia-Karten modernere Varianten wie cuvid nutzen.

    Das Thema ist ja schon einige Male hochgekommen, aber scheinbar gibt es noch nicht genügend User, die 10bit-Material (was ja vorwiegend erst bei UHD verwendet wird) wiedergeben wollen. Bei dem hier besprochenen DVB-T2 wird ja noch ein 8bit-HEVC-Bildsignal verwendet, was ja die GT1030 per VDPAU in Hardware decodieren kann! Da gibt es m. M. nach keine großen Probleme.


    Die Wiedergabe von 10bit-UHD/HDR-Material habe ich momentan so gelöst, dass ich dazu den in meinem Philips-TV (Android-Firmware) intergrierten Mediaplayer benutze. Über diesen Mediaplayer greife ich per Netzwerk auf meine, vom VDR aufgenommenen und gespeicherten UHD-Aufnahmen/Filme zu.

    Das klappt prinzipiell ganz gut, allerdings ist die Bedienung über den TV nicht sehr komfortabel, weshalb ich auch hoffe, dass doch demnächst ein neues VDR-Ausgabeplugin kommt, was dann nicht mehr nur VDPAU sondern auch CUVID unterstützt.


    Eine andere Möglichkeit, falls es hier mit dem VDR nicht weitergehen sollte, wäre für mich noch eine Android-Mediabox zu kaufen, z. B. den ZIDOO X9S , der kann dann sogar die Bildauflösung und Framerate "nativ" an den TV per HDMI weitergeben! Auf der Android-Mediabox läuft dann ein KODI und damit kann man praktisch alles problemlos abspielen, wie man es von KODI gewohnt ist! Und dann ist die Bedienung für mich auch wieder komfortabler und nicht so rudimentär, wie es momentan über den integierten Mediaplayer ist.


    Paul

    Taipan ,

    sorry, weil ich mich erst jetzt melde! Welche GT1030 hast Du denn jetzt bestellt?

    Ich habe mir die MSI GT1030 2GH LP OC gekauft, wegen dem Displayport als 2. Ausgang und vor allem, weil diese Karte am kürzesten der Low-Profile-Karten ist. Allerdings belegt der große Kühlkörper komplett den danebenliegenden PCI-Slot!


    Mal noch eine Frage zum verwendeten Kernel: Warum soll man einen >= Kernel-4.11 verwenden? Welche Vorteile bringt das?

    Ich habe hier den Kernel-4.4 im Einsatz, mit dem nvidia-384.90-Treiber, der bei Ubuntu-14.04 letztens mitinstalliert wurde.

    Damit funktioniert HEVC mit Full-HD (DVB-T2 getestet) und UHD/4K-8bit-30Hz (Video von meiner Kamera) mit Hardware-Decodiewrung!

    Nur eben UHD/4K-10bit geht nicht per Hardware-Decodierung, weil nicht in VDPAU möglich.


    Da wird es doch keinen Unterschied bei Verwendung eines >= Kernel-4.11 geben! Oder?


    Paul

    Ja, das ist so, weil dieser Sender eine sehr untypische und vor allme sehr hohe Bildauflösung hat. Damit kommt das softhddevice-Plugin nicht klar.


    Wenn Du den gleichen Sender in KODI anschaust, dann hast Du auch ein Bild und Ton.

    Da kannst Du Dir auch die Bildauflösung anschauen, die ist geschätzte 10.000x1080px (jetzt nur aus dem Gedächtnis).


    Paul

    Jetzt ist im Forum dieser schon etwas ältere Thread hochgekommen, in dem das gleiche Problem beschrieben ist.

    Nun scheint es ja so zu sein, dass es doch nicht am skindesigner-Plugin liegt, sondern am softhddevice-Plugin, welches zu wenig OSD-Puffer für ein UHD/4K-OSD bereitstellt.

    Überprüfen kann ich das leider momentan nicht, weil das softhddevice-Plugin noch nicht angepasst ist.

    Na ja, der Bedarf an einem OSD in UHD/4K hält sich ja noch auf Grund der sehr begrenzten Inhalte, noch arg in Grenzen.


    Aber ich denke in einem halben Jahr, wenn die Fussball-WM läuft, wird das schon wieder anders aussehen, denn diese wird ja komplett in UHD produziert. Was dann letztendlich beim deutschen Zuschauer ankommt ist allerdings eine gsnz andere Frage, da ja die Rechte der Live-Übertragung bei der ARD/ZDF liegen, welche ja momentan noch kein großes Interesse an UHD haben.


    Paul

    Jetzt bin ich über diesen Thread gestolpert und da wird ja das gleiche Problem besprochen, was vor kurzem ich hier als Bug vom Skindesigner-Plugin beschrieben habe. Da habe ich ja auch den Workaround mit der Reduzierung des OSD auf Full-HD (1920x1080) beschrieben und dachte das Problem läge am skindesigner-Plugin.


    Wenn ich dasaber jetzt richtig verstanden habe, dann liegt das Problem der fehlerhaften Anzeige vom OSD doch nicht am skindesigner-Plugin, wie ich vermutet hatte, sondern am softhddevice-Plugin, welches zu wenig OSD-Puffer bereitstellt!


    Da die Änderungen, welche johns hier im beitrag #5 beschrieben hat, ja relativ klein sind muss ich hier doch mal fragen, ob es denn eine Möglichkeit gibt, diese Änderungen in das softhddevice-vpp-hevc-Plugin einzufügen, was seahawk1986 in seinem ppa: hat?


    Paul

    @Andreas, das wird jetzt doch etwas arg Off Topic! ;)

    Falls weiterhin Bedarf dazu besteht, solltest Du dazu einen eigenen Thread aufmachen.


    Nur kurz zum Abschluss:

    Gerade nochmals "Fashion 4K" getestet: Es ist aktuell nicht möglich über den VDR mit einer GT1030 per Hardware einen UHD/4K-Sender zu decodieren. Die Darstellung ist praktisch nicht nutzbar, extremes ruckeln, Ton ist asynchron.

    Mit Windows müsste es funktionieren, denn der Nvidia-Windows-Treiber kann HEVC 10bit in Hardware decodieren, nur mit Linux-VDPAU geht es nicht.

    Es kann evtl. sein, dass Du den Full-HD-Sender von Fashion 4K empfangen hast und nicht den UHD/4K-Sender? Gibt nämlich beide auf Astra!


    So, jetzt genug OT geschwätzt. :)

    Paul

    ciax ,

    ich glaube nicht so richtig, dass das an dem Displayport->VGA-Adapter liegt, sondern eher daran, dass die Grafikkarte eine feste Reihenfolge hat, mit der sie die einzelnen Grafikports abfragt. Der 1. Grafikport, an dem ein Bildschirm gefunden wird, wird dann als Boot-Bildschirm genommen. Erst wenn der Xserver ins Spiel kommt, kann man festlegen welcher Bildschirm was anzeigen soll!


    Besser wäre es, wenn auf allen Ausgängen eine Boot-Anzeige käme, aber dem ist bei NVIDIA leider nicht so.

    Bei meinem Office-PC, in dem nur die Onboard-Intel-Grafik werkelt ist es nämlich genau so, dass der Boot-Vorgang auf beiden Monitoren gleichzeitig angezeigt wird! Das wäre optimal! ;)


    Wenn ich nochmals richtig Zeit und Lust habe, werde ich mal den DisplayPort-Adapter versuchen zu modifizieren. Ich habe mir nämlich überlegt, dass dieser Adapter ja vermutlich seine Betriebsspannung vom Pin 20 des Displayports bekommt. Wenn man diese Leitung auftrennt und die Spannung um ca. 20 Sekunden verzögert (dann ist der Grub-Screen auf jeden Fall durch) zuschaltet, dann könnte es vielleicht klappen. Denn dann erkennt die Grafikkarte keinen Monitor am Displayport-Ausgang und nimmt den HDMI-Ausgang als Boot-Bildschirm.


    Paul

    Sollte aber auch mit einer geeigneten nvidia-Grafikkarte gehen.

    Na ja, momentan geht's noch nicht so richtig mit einer Nvidia-Grafikkarte, wenn Du VDR mit dem softhddevice-Plugin als Ausgabe benutzt. da brauchts schon eine sehr potente CPU, da hier alles in Software decodiert werden muss! :(

    Der Grund ist, dass VDPAU kein HEVC mit 10bit in Hardware decodieren kann, da VDPAU wohl von NVIDIA etwas stiefmütterlich behandelt wird, sprich es wird nicht weiter entwickelt. Von NVIDIA wird nun NVDEC/NVENC als De- und Encoder empfohlen und auch weiterentwickelt.


    Momentan fehlt es also an einem geeignetem Ausgabeplugin für den VDR, das nicht nur VDPAU sondern auch NVDEC unterstützt, da alle UHD-Sender in HEVC mit 10bit senden!


    Auf meinem VDR mit Intel i5-2500 und einer GT1030 gehts über den VDR praktisch gar nicht (extremes Geruckel und teilweise wird der VDR unbedienbar). Etwas besser geht es über KODI-17.5, da ruckelt es etwas weiniger, aber auf dauer anschauen ist nicht möglich.


    Paul

    Und du bist sicher, dass das Fernsehbild (im letzten Screenshot) UHD/4K ist?

    Yepp, wird mir auf meinem Philips-TV so angezeigt als UHD 2160/50p und wenn ich auf Full-HD gehe, dann zeigt er mir eben 1080/50p an.

    Die Bildauflösung stellt man ja nicht im softhddevice-Plugin ein, sondern im xserver über die xorg.conf.


    Das OSD wird dann auf die Bildauflösung gezoomt, da ja im skindesigner-Plugin mit relativen Werten in Prozent zum Bild gearbeitet wirdund nicht mit absoluten Pixelzahlen.

    Somit sind x=50% bei Full-HD eben 1920/2 = 960px und bei UHD eben 3840/2 = 1920px, aber in beiden Fällen 50% vom gesamten Bild.

    Deshalb ist das OSD immer gleich groß, egal ob Full-HD oder UHD/4K! ;)


    Paul

    Zu diesem Thema bzw. Fehler gibt es bereits ein Bug-Ticket im skindesigner-Plugin-Projekt, "Keine Hintergrundgrafiken bei 4k Auflösung"


    Da die Entwicklung am skindesigner-Plugin zum jetzigem Zeitpunkt nicht weitergeführt wird, musste ein Workaround her, um trotz Bildausgabe in UHD/4K ein fehlerfreies OSD zu bekommen.

    Die Ausgabe des UHD-Bildes erfolgt bei mir über das softhddevice-vpp-hevc-Plugin und klappt prinzipiell sehr gut, bis auf die noch nicht gelösten Probleme bei HEVC mit 10bit-Farbauflösung. Das hat aber nichts mit dem OSD zu tun.


    Hier mal Screenshots des estuary-Skins bei einer "normalen" Full-HD-Auflösung (1920x1080x50p):


         



    Und hier nun die gleichen Views bei UHD/4K-Auflösung (3840x2160x50p) von Bild und OSD:


     


    Wie klar zu erkennen ist, fehlen bei der Darstellung in UHD/4K teilweise die Hintergünde und somit sieht der Skin nicht mehr so gut aus.

    Jetzt habe ich festgestellt, dass es keine Probleme mit der Darstellung im OSD gibt, wenn man als Bildausgabe zwar UHD/4K (3840x2160x50p) ausgewählt hat, aber dabei gleichzeitig im softhddevice-Plugin unter "Allgemeines" --> "OSD Größe" den Wert von "auto" auf "1920x1080" setzt, also an Stelle der UHD/4K-Auflösung die Full-HD-Auflösung nimmt.


     


    Jetzt werden im OSD alle Hintergründe wieder richtig dargestellt und damit kann man denke ich gut leben! Die Schrift und Linien werden bei Anzeige OSD in vollem UHD/4K zwar etwas schärfer und knackiger dargestellt, aber die fehlenden Hintergründe sind schwerwiegender und stören schon extrem. :(


    Hier nun die gleichen Views bei einer UHD/4K-Auflösung (3840x2160x50p) für das Bild und OSD Größe = 1920x1080:


       


    Das bedeutet, dass diese Probleme mit der Anzeige von Hintergründen im OSD nur auftreten, wenn die OSD-Größe auf UHD/4K gesetzt wird. Wenn man also die Bildausgabe auf UHD/4K setzt, dann braucht man also einfach im softhddevice-Plugin die "OSD Größe = 1920x1080" zu setzen und schon passt alles wieder! ;)


    Paul

    Ich wollte jetzt mal ein paar Screenshots vom skindesigner-OSD erstellen, aber irgendwie bekomme ich das nicht hin.


    Benutzen wollte ich das screenshot-Plugin, aber sobald ich die für @screenshot definierte User-Taste drücke geht das OSD weg und der erstellte Screenshot zeigt dann nur das "nackte" TV-Bild! X(


    Da ich hier immer wieder Screenshots von den OSDs sehe, muss es doch eine Möglichkeit geben?

    Könnt Ihr mir mal ein paar Tipps geben, wie ich das auch hinbekomme! ;)


    Paul

    Diese Dinger können dir auch den Spaß verderben. Ein Adapter um diesen Preis hatte ständig Ausfälle. Daraufhin habe ich noch so ein Billigding gekauft, bei dem kommt kein Bild, wenn der vdr bootet (Initialauflösung). Erst wenn der xserver (xorg.conf) startet, habe ich dann das Bild.

    ciax ,

    der "Billigadapter Displayport -> VGA" ist angekommen und funktioniert erstmal ganz gut. :)

    Leider ist es bei mir genau umgedreht zu Deinen Erfahrungen: Den GRUB-Bootscreen und das BIOS bekomme ich nun nur noch via dem neuen "Displayport-Adapter" über das kleine graphtft-Display zu sehen. Am großen TV, der über HDMI angeschlossen ist, sehe ich erst etwas wenn der xserver gestartet ist! :( 


    Lieber wäre mir andersrum, wenn ich den GRUB-Bildschirm usw. am TV sehen könnte und erst später das graphtft-Display aktiv wäre. Denn so weiß ich nie, ob denn der VDR überhaupt gestartet ist, da nämlich mein VDR und das graphtft-Display im Nebenraum (Arbeitszimmer) stehen! So habe ich jetzt immer nach dem Start 30 Sekunden Blindflug, ehe ich weiß ob der VDR und auf welcher Partition er gerade läuft (ich habe 2VDRs auf der Festplatte: 1x Produktiv- und 1x Test-VDR). :(


    Jetzt erklärt sich für mich auch, warum ich zu Anfang diese komischen Probleme mit der neuen Grafikkarte hatte, da scheinbar bei der MSI-GT1030-Karte der Displayport als 1. Ausgabedevice genommen wird, wenn die Grafikkarte daran ein Bildschirm erkennt. Ziehe ich nämlich das Kabel vom Displayport wieder ab, dann kommt der GRUB-Bildschirm usw. wieder schön brav über den HDMI-Ausgang auf dem großen TV!


    Die Möglichkeit, den HDMI-Port als primäres Boot-Ausgabedevice festzulegen, wird man vermutlich nur in der Firmware zur Grafikkarte einstellen können, aber da kommt man ja nicht so einfach ran! X(


    Jetzt habe ich erstmal als Notlösung das graphtft-Display an den VGA-Ausgang der internen Intel-Grafik gehangen, damit ich den GRUB-Bildschirm und das Booten usw. am großen TV sehen kann. Jetzt darf ich nur nicht im Webfronten in den Anzeigeeinstellungen das "Erneut nach vorhandenen Bildschirmen suchen" auslösen, sonst wirds wieder dunkel! X/


    Paul

    ofenheizer ,

    bei mir war es so, dass selbst bei "ausgegrautem" Dualhead-Modus (weil ich bei der neuen Grafikkarte vorläufig nur 1 Bildschirm dran habe) dieser aktiv war!

    Ich hatte einfach die neue Grafikkarte eingebaut und dachte alles wäre i.O. ohne vorher bewusst diese Option zu deaktivieren!

    Und dadurch das im Hintergrund der "Dualhead-Modus" noch aktiv war, hat das "Erneut nach vorhandenen Bildschirmen suchen" im Webfrontent immer kein Ergebnis gebracht. Es wurde immer nichts gefunden und somit auch keine brauchbare neue xorg.conf.yavdr erstellt. :(


    Ob die Funktion "Dualhead-Modus", trotz ausgegrauter Option, immer noch aktiviert ist, kannst Du am einfachsten eben daran erkennen, dass Du im OSD auf MENÜ --> SYSTEM gehst und dann gibt es eben den Menüpunkt "Vorläufig auf den 2. Bildschirm schalten". Es kann sein, dass der Menüpunkt auch etwas anders heißt und, wenn ich mich recht entsinne, steht er glaub ich an der 3. Stelle im Systemmenü. Genau kann ich das jetzt nicht sagen, da ich es momentan wegen fehlendem 2. Bildschirm nicht aktiviert habe.


    Da ich nicht weiß, wo genau diese Variable im System gesetzt wird, habe ich einfach den Urzustand mit meiner alten Grafikkarte + 2. Bildschirm wieder hergestellt und jetzt konnte ich im Webfrontend endlich den Dualhead-Modus deaktivieren. Danach dann die neue Grafikkarte einbauen, im BIOS auf PCIe für Grafikkarte einstellen und dann konnte ich im Webfrontend das "Erneut nach vorhandenen Bildschirmen suchen" problemlos ausführen und es wurde der angeschlossene Bildschirm gefunden und nach dem Speichern auch eine neue xorg.conf.yavdr erstellt. Und seit dem läuft es bestens! ;)


    Ich hoffe ich konnte meine konfusen Erklärungen von gestern Nacht etwas verdeutlichen! :)


    Paul