Bei höheren Versionen habe ich ein Problem mit dem OSD bei softhddevice in Verbindung mit der GTX 950.
Ich kann morgen den Test mit einer höheren Version wiederholen.
Hallo jojo61,
ja nur der Rand, wobei beim seduatmo Plugin einstellbar ist wie viele Pixel in Richtung Bildmitte ausgewertet werden. CineBars oben/unten sowie seitlich werden dabei ignoriert, also übersprungen.
Jörg
Mit ein paar schmalen Linien wird es dennoch nicht getan sein.
Naja die vdr Plugins sind da ziemlich in die softhddev Schnittstelle reinentwickelt damit das runterrechnen der Farben auf der NVIDIA Hardware geschieht und das ganze extrem Performant wird. Johns und horchi haben da lang dran gebastelt.
Beim softhddev wird vom seduatmo zb quasi ein Bild in der Geometrie der verbauten led angefragt, also wenn du oben 16 und an der Seite 9 led hast kommt da ein fertiges 16x9 Foto raus wo du direkt jedes Pixel einer led zuweisen kannst. Dadurch ist einmal die Datenmenge extrem klein und die Grafikkarte kann Farben sicher besser mischen als das Plugin.
maW: wenn du 50 LED verbaut hast fragst du ein 16x9 Pixel Bild an und bekommst ein fertiges Bild mit 144 Pixeln, das ist nicht groß und die Farben sind auf der nvidia HW fertig gemischt um direkt jedes Pix auf eine LED zu schieben. Verschlimmbessert wird da nur noch im Bereich der Cinebars horizontal und vertikal. Das hat man damals so gemacht um zum einen die Last auf der CPU klein zu halten und zum anderen um sich nicht ins Farbenmischen einzumischen - das können die Profis bei nvidia sicher besser.
Von daher sind die Plugins sehr einfach gestrickt. Du hast aber natürlich Recht das nur der Rand, also 50 der 144 Pix benutzt werden - das macht aber den Kohl nicht fett denke ich. Außerdem stimmt das nicht so ganz da zumindest das sedu soweit zum Bildinneren looped bis es die cinebars überwunden hat und die Farbe vom "Rand" erwischt.
Christian
ja genau, ich meine ich hab momentan auf 50" so 33*18 Led, macht 102 Led bzw 594 Pixel, in dem Rahmen ist das so normal würde ich sagen.
Wenn du da fleißige Tester benötigst kannst du aber gern auf uns zukommen, ich hab hier seduatmo und auch vdrboblight im Einsatz und Jörg kann parallel notwendige Anpassungen (plugin heißt ja anders) im Plugin machen.
Danke.
Christian
ergänzend, das seduatmo fragt immer die 'Auflösung' der LEDs an ist damit abhängig von der Anzahl der vorhandenen/konfigurierten LEDs
Wo wir beim Thema grab sind. Funktioniert das grabben mit hyperion-x11 bei softhdcuvid? Bei softhddevice ging es ja wegen vdpau nicht.
Ich starte mit:
/usr/bin/nohup /usr/bin/X &
.xinitrc ist gelöscht.
Dann könnte man mal versuchen X das Argument -noreset mitzugeben.
Dann könnte man mal versuchen X das Argument -noreset mitzugeben.
Danke, das war die Lösung, nun funktioniert es mit 390.87
384.130 funktioniert auch
perl tv UHD läuft super downsized.
Gibt es noch andere funktionierende UHD-Sender auf Astra?
jetzt muss ich mich nur noch um den ffmpeg patch kümmern, hat da jemand einen funktionierenden patch für 3.4.4? Dann könnte ich mir ein ebuild basteln.
jetzt muss ich mich nur noch um den ffmpeg patch kümmern, hat da jemand einen funktionierenden patch für 3.4.4? Dann könnte ich mir ein ebuild basteln.
Ich hatte das für das PPA so angepasst:
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -841,7 +841,8 @@
goto error;
}
- ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
+ //ctx->frame_queue = av_fifo_alloc(ctx->nb_surfaces * sizeof(CuvidParsedFrame));
+ ctx->frame_queue = av_fifo_alloc((ctx->nb_surfaces + 2 ) * sizeof(CuvidParsedFrame));
if (!ctx->frame_queue) {
ret = AVERROR(ENOMEM);
goto error;Danke, der patch funktioniert.
Wenn Interesse besteht, kann ich mein ebuild posten.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!