Beiträge von Xcoder

Du brauchst wohl glfw3 glaube ich...

Mit folgendem Python wurde es erst nicht transparent.

from tkinter import *
root = Tk()
root.geometry("1280x720")
root.attributes('-type', 'normal')
root.attributes('-alpha', 0.1)
root.mainloop()

Mit xcompmgr -c wurde es transparent.

Das funktioniert aber softhdcuvid nicht. Eventuell aus dem gleichen Grund wieso es mit dem glfw Test nicht geht. Gibt immer noch "FB is not transparent"

Gruss

Was macht dieses Testprogramm bei Dir?

Bauen mit gcc -g -o test -lplacebo -lvulkan -lglfw glfw.c

Schiebel_St du brauchst libcxxtools-dev >= 2.2

Sorry, vulkaninfo sagt 1.1.97. Kompletter output im Anhang.

Ist hier angehängt.

Hatte noch mit den Optionen # Option "RenderAccel" "true" # Option "AllowGLXWithComposite" "true" # Option "AddARGBGLXVisuals" "True" experimentiert. Hat aber auch nicht funktioniert.

Da habe ich schon lange nicht mehr rumgeschraubt

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "ExactModeTimingsDVI" "True"
    Option         "FlatPanelProperties" "Dithering = disabled"
    Option         "NoLogo" "True"
    Option         "CustomEdid" "DFP-1:/etc/X11/edid.bin"
    Option         "UseDisplayDevice" "DFP-1"
    Option         "metamodes" "nvidia-auto-select +0+0 { ForceCompositionPipeline=On }" # wegen chrome tearing
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Ist auf 24 bit. Brauche ich da 32bit? Treiber ist auf 440.82.

Hallo,

wenn ich softhdcuvid (aktulle github Version) mit LIBPLACEBO baue, dann wird das Video Bild vom OSD immer ganz überdeckt. Sogar wenn nur die Lautstärke verändert wird, wird das ganze Bild schwarz, solange die Lautstärke-Anzeige eingeblendet ist. Das passiert sogar mit der "Klassischer VDR" Oberfläche ( und skindesigner Plugin nicht geladen).

libplacebo ist eine Version von experimental Debian lokal gebaut mit vulkan und shaderc.

Wenn ich LIBPLACEBO ausschalte, dann passiert das nicht.

Hat da jemand eine Idee woran es liegt?

Gruss, Xcoder

Hilft das: https://serverfault.com/questi…-serial-port-device-names

Zitat von looking111

Ich weis jetzt garnicht wie VDR-Live auf den VDR zugreift, macht es das direkt über SVDRP?

Das geht direkt, ist ja ein Plugin und läuft im gleichen Prozess wie der VDR. Ganz ohne SVDRP. Es kann also nicht keine Verbindung zum VDR haben.

Grummel. Hätte ich auch selber finden können. Danke.

Hallo,

Ich habe direkt von der letzten Version von https://github.com/louisbraun/softhddevice-openglosd auf das aktuelle softhdcuvid gewechselt. Da war Springen im Replay top flott und Kanalumschalten war auch brauchbar. Mit aktuellem vdr 2.4.1 war das top und auch ein Grund, dass ich lange daran gehangen habe. Da will mir das aktuelle Verhalten im softhdcuvid nicht ganz gefallen. Welches war der commit der den Video-Freeze eingeführt hat?

Gruss

Hallo,

Nach einiger Zeit auf mit dem alten softhddevice-

openglosd, wollte ich auf das aktuelle softhdcuvid wechseln.

GPU ist eine Nvidia GeForce GTX 860M. Daher ist das softhdcuvid mit CUVID und YADIV, aber ohne LIBPLACEBO gebaut. ffmpeg ist 4.2.2 mit allem HW accel Zeugs enabled.

Was mit nun doch als eher störend im Vergleich zum alten softhddevice aufgefallen ist, ist die Verzögerung beim Anlaufen der Wiedergabe. Sowohl bei einem Senderwechsel wie auch bei der Wiedergabe einer Aufnahme gibt es eine störende Verzögerung bis es normal läuft. Beim Senderwechsel kommt sofort da erst Bild, dann bleibt es aber ca 1s stehen und läuft dann erst normal. Bei den Trickmodi Sprung +/-60s fällt es auch stark auf. Auch da habe ich den Eindruck das es 1s lange stockt.

Im Verleich zum alten softhddevice ist fällt es stark auf. Ist das ein bekanntes Verhalten? Wo kann man da etwas beeinflussen? Minimalkonfig mit allen andern Plugins deaktiviert hilft auch nicht.

Gruss, Xcoder

Zitat von wirbel

AFAIR hat UPC nur verschlüsselte Kanäle, zumindest war das früher so.

Die Hauptsender sind seit einiger Zeit unverschlüsselt. Da ist UPC schon fast vorbildlich.

Zitat von tamerDE

Sorry, ich kann dir nicht wirklich folgen.

Von welchem Programm redest du ?

Ich nutze zur Kanalsuche w_scan vergeblichst ohne Erfolg.

Ich würde gerne eine kanalliste (DVB-C) am liebsten im XSPF Format generieren um mit VLC fern zu schauen oder Radio zu hören.

Achso... Also hier ist das VDR Forum... Und VLC nutze isch schon lange nicht mehr seit ich das vdr-plugin-live für Live-TV im Browser gepimpt habe. Aber Der VDR muss die Kanäle trotzdem alle haben. Kann er aber selber.

carel Welchen speed kriegst Du damit, wenn Du eine Aufnahme transcodierts?

Wieso hast Du nicht einfach die Kanalaktualisierung eingeschaltet? Dann werden Kanäle vom VDR selbst angelegt:

Setup->DVD->Kanäle aktualisieren = neue Transponder hinzufügen

Wenn ich das richtig sehe, wird die GPU nicht genutzt. Du hast -c:v h264. Das nimmt den Encoder libx264 der auf der normalen CPU läuft. Für vaapi sollte das -c:v h264_vaapi sein. Kenne mich mit vaapi nicht so gut aus.

Welchen Speed erreicht ffmpeg? Da sehe ich dass es weniger als 1 ist, also nicht live...

frame= 315 fps=8.6 q=-1.0 Lsize= 8478kB time=00:00:13.56 bitrate=5121.9kbits/s speed=0.371x

Du kannst zum üben auch einfach eine Aufnahme nehmen. Dann als -i Argmuent einfach ein 00001.ts File wählen. Mit einer Aufnahme sollte dann der speed wesentlich grösser als 1 sein. Ich erreiche mit meiner NVIDIA GPU mit Framrate 25 einen speed von 17x.

Da will irgendwie ffmpeg nicht.

Versuch mal ffmpeg von Hand zu starten. Z.B. für einen HD Sender (h264). Da habe ich die Einstellung

ffmpeg -v warning -f mpegts -analyzeduration 1.2M -probesize 5M -hwaccel cuvid -c:v h264_cuvid -i <input> -map 0:v -map 0:a:0? -c:v h264_nvenc -preset slow -qmin 12 -qmax 24 -maxrate 8M -g 25 -r 25 -c:a aac -ac 2

Daraus wir das Shell-Kommando für Kanal 12:

ffmpeg -y -f mpegts -analyzeduration 1.2M -probesize 5M -hwaccel cuvid -c:v h264_cuvid -i http://localhost:3000/12 -map 0:v -map 0:a:0? -c:v h264_nvenc -preset slow -qmin 12 -qmax 24 -maxrate 8M -g 25 -r 25 -c:a aac -ac 2 -f mpegts /dev/null

Läuft damit ffmpeg problemlos? (speed > 1.0, CPU Last kleiner 100%, stop und erneuter Start problemlos)

Default für h264 ist:

ffmpeg -loglevel warning -f mpegts -analyzeduration 1.2M -probesize 5M -i <input> -map 0:v -map 0:a:0 -c:v copy -c:a aac -ac 2

Damit wir bei einem HD Sender 1-2 MB/s direkt weitergegeben. Das müsste dann dein Netzwerk könnnen.

log kommt ganz normal dort wo der vdr hinloggt. Eventuell das vdr loglevel hochdrehen. Bei mir "--log=3".

Wenn Du fffmpeg ohne hardware decoding/encoding nutzt, könnte es auch an der Leistung des Rechners liegen. Würde zum sporadischen funktionieren passen. Mit dem Setting in #118 wäre das der Fall. jsffm hat da die guten Settings für NVIDIA GPU-Transcoding aufgelistet.

hallo

Hier sind alle Flags definiert:

https://github.com/rofafor/vdr…n-satip/blob/master/log.h

Du kannst es auch zur Laufzeit mit "svdrpsend PLUG satip TRAC 0x0001" verändern. 0x0101 ist dann "Generic call stack" und "Channel switching"

Gruss

Bei meinem Import Skript habe ich folgende Parameter:

ffmpeg -i <input> -codec copy -f mpegts -bsf:v h264_mp4toannexb "00001.ts"

Das ist für Quellen mit h264 Video codec. Aber das -bsf:v h264_mp4toannexb ist offenbar wichtig für den VDR.

Falls das Ausgangsmaterial nicht h264, muss dann aber noch transcodiert werden...