Posts by Xcoder

    Da habe ich schon lange nicht mehr rumgeschraubt

    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

    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

    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.

    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.

    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.

    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...

    Debian Buster hat libavcodec 58.35.100. Musste da in decoder.cpp leicht anpassen damit es kompiliert hat:


    Dieser Patch hilft eventuell auch hier:

    Ist jetzt noch nicht ausführlichst geprüft...