Neuer VDR für UHD

  • Mal nur zur Info: Ich habe auf meinem Arbeitsplatzrechner mal testweise MLD 5.4 installiert und per satip mit meinem VDR mit minisatip verbunden. Der Arbeitsrechner verwendet Kaby Lake Intel Core i7-7700K auf Asus Prime Z270-A Intel Z270. Gut, ist für einen VDR natürlich überdimensioniert. Aber es geht nur ums Prinzip.


    Alle UHD-Kanäle laufen auf Anhieb problemlos, Umschaltzeiten fast Null und die Prozessorauslastung ist bei max. 1%. UHD mit satip ist kein Problem.

    Intel NUC 10 NUC10i3FNH, Digital Devices Octopus NET V2 Max M4, 1000 GB Samsung 970 Evo M.2 2280 PCIe 3.0 x4 NVMe, LG OLED 77CX9LA

    Einmal editiert, zuletzt von rkp ()

  • Ich habe bei mir zum Spass mal am FHD TV probiert. VDR ist der Server aus der Sig. Mit vaapidevice bleibt das Bild schwarz, Ton läuft.

    Mit Kodi geht es nur mit 98% Auslastung und per Software Decoder. Videos wie zB "Big Buck Bunny" in 4K und 60 fps spielt er aber butterweich ab.


    EDIT:

    So, bin ein bisschen weiter :) Mit MLD 5.4 direkt vom USB-Stick, läuft pearl.tv QHD schon mal tiptop!

    CPU Auslastung ist dabei zu vernachlässigen. Umschaltzeit ist auch OK. Jetzt teste ich die andern Sender noch...

    Btw.: MLD -> Habe ich jetzt schon länger nicht mehr ausprobiert, aber was Claus und Co da zusammen gebaut haben - Hut ab!


    Die anderen UHD Sender laufen auch, allerdings habe ich bei denen auf 10994 ein schwächeres Signal - ist das bei euch auch so oder muss ich an der Schüssel drehen?

    3 Mal editiert, zuletzt von Saman ()

  • Das das mit der MLD bei mir läuft und mit meiner eigenen Installation nicht, hat mir keine Ruhe gelassen.

    Darum habe ich das vaapidevice-plugin mal deaktiviert und softhddevice-vdpau-hevc wieder installiert und siehe da - es werde Licht.

    Signalstärke auf den beiden SES-Kanälen ist auch gut.

  • Ich habe das aus dem ppa von seahawk1986 installiert. Vermute aber das es ist.

  • Das vaapidevice-Paket wird IIRC gegen das ffmpeg 3.4 aus den offiziellen Ubuntu-Repositories gebaut, scheint die HEVC-Dekodierung in Hardware nicht zu klappen. Ich baue später mal noch ein Paket gegen ffmpeg 3.3.3 aus ppa:yavdr/experimental-main, dann sollte es in der Hinsicht die gleichen Voraussetzungen geben.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ein Paket mit dem Namen vdr-plugin-vaapidevice-hevc, das gegen ffmpeg 3.3 gebaut wird, ist unterwegs. Das vdr-plugin-vaapidevice bitte vorher deinstallieren, ich habe bei der ersten Version vergessen die Paketkonflikte sauber zu setzen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Super, teste ich dann gleich aus. Das mit dem kaputten ffmpeg würde ja auch erklären, warum die QHD Sender bei mir mit Kodi (original Ubuntu Version) nur in SW decodiert wurden.

  • Ja stimmt, KODI 17 für bionic wurde gegen ffmpeg 3.4 gebaut, KODI 18 ist IIRC aktuell bei ffmpeg 3.3.2 - die Nightly-Builds gibt es mittlerweile auch für bionic.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das vdr-plugin-vaapidevice-hevc habe ich jetzt installiert. Leider läuft das noch nicht vernünftig. Bild kommt kurz und dann wird es grün.

    Dazu kommt dann auch, das die aktuelle Version aus dem Git bei mir (und anderen) noch ein anderes Problem hat https://github.com/pesintta/vdr-plugin-vaapidevice/issues/98


    Den Link zu Kodi aus dem anderen Thread habe ich schon entdeckt. Das werde ich nachher auch noch testen.

    Allerdings geht mir das Gelaber auf pearl.tv langsam wirklich auf den Sack, UHD hin oder her, das geht ja gar nicht ;)


    Edit: Jetzt laufen die UHD Sender auch mit Kodi :tup

    Allerdings gab es erstmal einen dpkg Fehler beim apt-get upgrade. Habe kodi dann deinstalliert und wieder installiert. Dann war alles gut. Das Paket kodi-bin gib es wohl nicht mehr?

    Einmal editiert, zuletzt von Saman ()

  • Ich meine gelesen zu haben, dass das bei dem Board bei UHD einen spürbaren Unterschied machen kann.

    sollte im dem Fall keinen Unterschied machen, dann schon eher ein zu altes OS + Treiber

    Das kann man so nicht einfach abtun, der Umstand ist technisch überhaupt nicht abwegig. Ähnliches Problem gab es z.B. auch zu Beginn der HD Ära bei OnBoard Nvidia GPUs.


    Es ist auf auf einigen Seiten für die modernen Atom CPUs (Goldmont, Apollo Lake) beschrieben, das es ohne Dual-Channel Bestückung bei UHD Streaming von Netflix zu Problemen kommt. Gemini Lake wird sich zeigen, da deren 3rd Level Cache verdoppelt wurde.


    ===


    Sehe ich das richtig ffpmeg 3.4 macht hier Probleme?


    Regards

    fnu

    HowTo: APT pinning

  • Sehe ich das richtig ffpmeg 3.4 macht hier Probleme?

    Ja, damit scheint die Hardwarebeschleunigung für HEVC-Material weder mit VDPAU noch mit VAAPI zu funktionieren. Die alte VDPAU-API wird nebenbei bemerkt in der nächsten ffmpeg-Version endgültig entfernt werden (im Git von ffmpeg ist sie schon weggefallen).


    Ich habe in ppa:yavdr/experimental-main ein ffmpeg3 Paket mit ffmpeg 3.3.6 hinterlegt und gegen diese ffmpeg-Version gebaute Pakete für vaapidevice (vdr-plugin-vaapidevice-hevc) und den letzten Stand von softhddevice-vpp (unter dem Namen vdr-plugin-softhddevice-vdpau-hevc) in den PPAs für bionic (ppa:yavdr/experimental-vdr und ppa:seahawk1986-hotmail/vdr-2.3.9) bauen lassen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ja, damit scheint die Hardwarebeschleunigung für HEVC-Material weder mit VDPAU noch mit VAAPI zu funktionieren.

    Weiß man da näheres zu? Ist das bzgl. VPP/VA-API ein Versehen?


    ffmpeg ist auch nach Jahren immer für ein Ärgernis gut ...


    Regards

    fnu

    HowTo: APT pinning

  • Das vdr-plugin-vaapidevice-hevc habe ich jetzt installiert. Leider läuft das noch nicht vernünftig. Bild kommt kurz und dann wird es grün.

    Nutzt du zufällig eine Desktop-Umgebung mit aktivem Compositing? Das kann einem die Performance mit Hardwaredecoder ziemlich verhageln...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Weiß man da näheres zu? Ist das bzgl. VPP/VA-API ein Versehen?

    Im Bugtracker von ffmpeg gibt es ein paar Einträge zu Regressionen beim HEVC-Decoding, die kurz nach dem Release der Version 3.4 erstellt wurden: https://trac.ffmpeg.org/query?…eport=1&desc=1&order=time


    Da müsste jemand mit geeigneter Hardware auf Spurensuche gehen...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Nutzt du zufällig eine Desktop-Umgebung mit aktivem Compositing? Das kann einem die Performance mit Hardwaredecoder ziemlich verhageln...

    Das weiß ich gar nicht genau. Der Desktop läuft bei mir so, wie von Budgie geliefert. Habe dazu dann nur den Intel Treiber aktiviert. Wie kann ich das denn feststellen?

    Anderseits funktioniert es ja mit vdr-2.3.9 und softhddevice-vdpau-hevc nahezu perfekt (alles aus deinem neuen ppa).

  • Budgie habe ich noch nicht genutzt - aber im Zweifelsfall würde ich mal einen Window-Manager ohne viel Schnickschnack (wie z.B. Openbox) nachinstalieren und den im Login-Manager für die Session auswählen und Vergleichen, ob sich etwas dadurch ändert.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Da hattest du mal wieder den richtigen Riecher, aber Budgie ist wirklich schick und den möchte ich eigentlich auch weiter benutzen.

    Code
    marc@vdr:~$ export DISPLAY=:0; xdpyinfo | grep -i composite
        Composite

    Mit softhddevice funktioniert es wirklich super. Ich vermute darum, das es am vaapidevice liegt. Zum Testen werde ich es aber noch mit Openbox versuchen.

    Allerdings muss ich erst rausfinden, wie das mit dem 'Login-Manager für die Session auswählen' genau geht ;)

  • Laut https://github.com/UbuntuBudgi…master/debian/control#L55 sollte da lightdm als Login Manager installiert sein. Sobald es mehr als eine auswählbare Desktop-Sitzung gibt, sollte neben dem Benutzernamen ein Zahnrad (oder ein anderes vom jeweiligen Theme bestimmtest Logo) auftauchen, das es nach einem Klick darauf erlaubt die Desktop-Sitzung zu wählen - das sieht z.B. so aus: https://media-cdn.ubuntu-de.or…39/lightdm_ubuntu1110.jpg

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hat funktioniert, openbox läuft aber das Problem ist immer noch da.

    Code
    Mar 21 20:24:37 vdr vdr: [9445] VAAPI-ERROR: video: display buffer empty, duping frame (1120/15) 62
    Mar 21 20:24:44 vdr vdr: [9854] VAAPI-ERROR: video: packet buffer too small for 524316
    Mar 21 20:24:45 vdr vdr: [9854] VAAPI-ERROR: video: packet buffer too small for 524308
    Mar 21 20:24:45 vdr vdr: [9854] VAAPI-ERROR: video: packet buffer too small for 786476
    Mar 21 20:24:45 vdr vdr: [9854] VAAPI-ERROR: video: packet buffer too small for 1048636
    ....

    Aber das ist auch geblieben

    Code
    export DISPLAY=:0; xdpyinfo | grep -i composite
        Composite

    Muss ich Composite jetzt noch extra deaktivieren oder ist der Befehl quatsch?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!