gelöst: softhddevice VAAPI DVB-T2 (video zu langsam)

  • Hi, ich versuche hier gerade DVB-T2 mit softhddevice zum Laufen zu bringen.
    Hardware ist ein Skylake Celeron G3900. Treiber (VAAPI) sollten aktuell sein und funktionieren auch. Testclips lassen sich mit niedriger Auslastung mit mpv abspielen. DVB-T2-Aufnahmen funktionieren auch, weil sie eben auch mit mpv problemlos abspielbar sind. Das Testsystem (ARCH linux) nutzt einen selbstkomplierten VDR 2.2.0 mit HEVC patch von reufer mit aktuellem softhddevice git von rofafor.


    In VDR funktioniert HEVC leider nicht richtig. Audio klappt meistens, Bild ist auch da, allerdings viel zu langsam egal ob live oder Aufnahme.
    Ich habe schon verschiedene FFmpeg-Versionen ausprobiert, allerdings ohne Erfolg.


    Also wenn jemand Tipps hat, was ich noch ausprobieren könnte, immer her damit :D

    FFmpeg:


    Treiber:


    Logfile (mit DEBUG, die HEVC-Aufnahme startet ab 16:33:42)

    Server/Client 1: VDR4ARCH VDR 2.4.0+softhdcuvid, Celeron G3900, GTX1030, DVB-T2: Hauppauge WinTV-quadHD, DVB-S: Digital Devices Cine S2 V6.5, DVB-C: GENIATECH MyGiga T230 für DVB-C
    Client 2: VDR4ARCH VDR 2.2.0 + softhddevice, Intel NUC6CAYB

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von sg75 () aus folgendem Grund: Problem gelöst

  • Hallo,


    ich habe Dir keinen Tip, aber gut das Du schreibst, das es mit HEVC kompatibler Intel HW auch so ist.


    Ich kenne das Problem, ist hier auf meinem Haswell NUC genauso, dachte aber immer es läge an der Tatsache das dies in/auf Software/CPU verarbeitet ...


    Mit xineliboutput laufen die 1080p Testsequenzen wunderbar auf der gleichen HW (Intel VA 1.8.1, ffmpeg 3.2.x), bei um 30% CPU.


    Regards
    fnu

    HowTo: APT pinning

  • CvH


    Das sind kurze DVB-T2 VDR Aufnahmen die mir zugänglich gemacht wurden, der Test ist also schon realistisch.


    Aber werde Deine auch mal testen, besser mehr als weniger.


    Regards
    fnu

    HowTo: APT pinning

  • Bei mir tritt mit Kaby Lake dasselbe Problem auf. Habe es bis jetzt drauf geschoben, dass ich keine aktuelle libva und Grafikkartentreiber drauf habe, sondern halt noch libva 1.7.0.

    VDR 1: Linux Mint 18.1 mit VDR 2.2.0 und Ausgabe auf X11 (Radeon HD6450) via softhddevice/vdpau. DVB-Karte: DVBSky T9580V3
    VDR 2: Ausgabe auf X11 (Intel i5 Kaby Lake) via softhddevice/vaapi, sonst wie VDR 1

  • Ich habe mir ein Test-System mit Kaby Lake aufgebaut und das gleiche Problem, trotz:


    Code
    1. vainfo: VA-API version: 0.40 (libva )
    2. vainfo: Driver version: Intel i965 driver for Intel(R) Broxton - 1.8.1


    vdr-User-# 755 to_h264 chk_r

  • Ich kenne das Problem ja auch, aber mein HW kann kein HEVC, d.h. Wiedergabe erfolgt in Software.


    Nun könnte man die berechtigte Frage stellen, ob Eure jeweilige Kaby Lake HW nicht aus irgendwelchen Gründen in die Verarbeitung in Software zurück fällt ... ?


    Regards
    fnu

    HowTo: APT pinning

  • Bei mir ist zumindest die CPU-Last nahezu Null


    vdr-User-# 755 to_h264 chk_r

  • Ja, bei mir auch fast keine Auslastung. Da läuft also auf jedenfall Hardwaredecoding.


    Der Fehler tritt auch nur mit softhddevice auf. Wenn ich Kodi als Frontend benutze (ebenfalls mit VAAPI-Beschleunigung) läuft DVB-T2/HEVC sauber.

    VDR 1: Linux Mint 18.1 mit VDR 2.2.0 und Ausgabe auf X11 (Radeon HD6450) via softhddevice/vdpau. DVB-Karte: DVBSky T9580V3
    VDR 2: Ausgabe auf X11 (Intel i5 Kaby Lake) via softhddevice/vaapi, sonst wie VDR 1

  • Da läuft also auf jedenfall Hardwaredecoding.

    Eher vermutlich, unterschreiben würde ich das aber nicht. Vllt. ist die CPU Last ja derart niedrig weil sie nicht genutzt wird/werden kann ...


    Mit Xineliboutput ist die Last beim Softwaredecoding auch nicht sonderlich hoch ...


    Regards
    fnu

    HowTo: APT pinning

  • ich habe Dir keinen Tip, aber gut das Du schreibst, das es mit HEVC kompatibler Intel HW auch so ist.
    Ich kenne das Problem, ist hier auf meinem Haswell NUC genauso, dachte aber immer es läge an der Tatsache das dies in/auf Software/CPU verarbeitet ...
    Mit xineliboutput laufen die 1080p Testsequenzen wunderbar auf der gleichen HW (Intel VA 1.8.1, ffmpeg 3.2.x), bei um 30% CPU.


    Hallo fnu,


    der Tipp mit xinelibouput ist doch schon mal Gold wert. Danke! :)
    Ich habe gerade xineliboutput ausprobiert und kann bestätigen, dass HEVC hardwarebeschleunigt mit meinem Setup läuft.
    Leider hängt mein VDR, wenn gescheites Deinterlacing für 576i eingestellt ist. xineliboutput ist mir auch in der Fülle der Einstellmöglichkeiten zu mächtig, deswegen würde ich softhddevice bevorzugen.


    Ich mache morgen ein issue auf pesinttas github-Seite auf. Ich kann leider immer nur stundenweise Testen, weil es das Produktivsystem ist.

    Server/Client 1: VDR4ARCH VDR 2.4.0+softhdcuvid, Celeron G3900, GTX1030, DVB-T2: Hauppauge WinTV-quadHD, DVB-S: Digital Devices Cine S2 V6.5, DVB-C: GENIATECH MyGiga T230 für DVB-C
    Client 2: VDR4ARCH VDR 2.2.0 + softhddevice, Intel NUC6CAYB

  • Leider hängt mein VDR, wenn gescheites Deinterlacing für 576i eingestellt ist.

    Kannst gerne einen Case aufmachen, aber das Problem ist das "vaapi" HW beschleunigt nur Weave/Bob als Deinterlacer funktioniert, klassisch "vaapi" eben. Man kann auch die vom "tvtime" Plugin nehmen, die gehen aber naturgemäß voll auf CPU.


    Mit "opengl2" laufen nach meiner Erfahrung eingebauten Deinterlacer gar nicht, nur die vom Plugin "tvtime", "TomsMoCo" ist der Beste aber der CPU hungrigste, macht aber für mich persönlich das Bild zu körnig, auch andere z.B. greedy2frame. Am effizientesten mit dem immer noch guten Bild ist m.E. "Linear Blend (ffmpeg)" ...


    Die Bildverbesserer, Denoise, Sharpening kann ich gar nicht verwendenden, stehendes Bild. Petri wollte sich mal anschauen ob er MADI/MCDI einbauen kann, VPP bringt ja eigenes Denoise bzw. Sharpening mit.


    Aber 1080p HEVC läuft sehr gut hier auf meinem Haswell NUC, mir gefällt generell "opengl2" besser. Das ist aber nicht nur SW, sondern es wird auch die GPU dazu benutzt, lt. Petri das modernste Ausagbemodul bei xineliboutput.


    Regards
    fnu

    HowTo: APT pinning

  • Ich hab mir mein Board nochmal genauer angeschaut, das ist nicht Kaby Lake, sondern Apollo Lake, es ist ein J3455-ITX und soll HEVC decodieren können.


    Ich habe jetzt die vaapi-driver auf 1.8.2 upgedatet, aber keine Veränderung.


    Das sieht bei mir so aus, dass das Bild kurze Zeit stabil ist, dann fängt der Ton an zu stottern, dann fängt irgend wann das Bild an zu verpixeln. Kodi läuft bei mir auch nciht wirklich, daher ist das eher ein grundsätzliches Problem. H264 geht einwandfrei.


    vdr-User-# 755 to_h264 chk_r

  • Bist du schon auf einer ffmpeg-Version, bei der die Probleme mit dem Audiocodec, der bei DVB-T2 HD genutzt wird, behoben wurden (IIRC ist das ab ffmpeg >= 3.3 der Fall).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • ffmpeg version 3.3.1


    vdr-User-# 755 to_h264 chk_r

  • bei der die Probleme mit dem Audiocodec,

    Also ich habe hier sauberen Ton mit den DVB-T2 Test Aufnahmesequenzen @ ffmpeg 3.2.4 & xineliboutput.


    Regards
    fnu

    HowTo: APT pinning

  • (short English description below German, since I know some of the softhddevice contributors prefer to write in English)


    Ich habe heute mal auf ffmpeg 3.3.2 aktualisiert. Das Problem ist geblieben, so dass ich mir mal in der Datei video.c vom softhddevice-Plugin angeschaut habe, was da so passiert. Dabei habe ich mich auf die Funktion VaapiSyncDecoder konzentriert, da hier ja Video mit Audio synchronisiert wird.


    Habe dann schnell festgestellt, dass bei MPEG (SD) und H.264 (Sat-HD) bei mir das Video immer dem Ton etwas vorläuft, das aber im grünen Bereich konstant bleibt. Bei HEVC allerdings war es so, dass das Video zu langsam läuft und der Ton immer mehr und mehr dem Video davon läuft. Es müsste also ab und zu mal ein Frame gedropped werden, um das auszugleichen.


    Das passiert im Prinzip auch, dafür ist folgende If-Clause zuständig:

    Code
    1. } else if (diff < -25 * 90 && filled > 1 + 2 * decoder->Interlaced) {
    2. err = VaapiMessage(2, "video: speed up video, droping frame\n");
    3. ++decoder->FramesDropped;
    4. VaapiAdvanceDecoderFrame(decoder);
    5. decoder->SyncCounter = 1;
    6. }


    Problem ist halt, dass hier immer nur genau 1 Frame gedropped wird und das nicht reicht.


    Daher habe ich den Block jetzt mal so umgeschrieben, dass ausgerechnet wird, wie viele Frames zu droppen sind und das dann auch entsprechend gemacht wird:

    Code
    1. } else if (diff < -25 * 90 && filled > 1 + 2 * decoder->Interlaced) {
    2. int numberFramesToDrop = abs(diff)/(25*90);
    3. err = VaapiMessage(2, "video: speed up video, droping %d frames\n",numberFramesToDrop);
    4. for (int i=0;i<numberFramesToDrop;i++) {
    5. ++decoder->FramesDropped;
    6. VaapiAdvanceDecoderFrame(decoder);
    7. }
    8. decoder->SyncCounter = 1;
    9. }


    Und siehe da... schon bleiben Video und Audio synchron. Anhand der Log-Ausgabe (der VaapiMessage) sehe ich, dass recht oft genau 2 Frames gedropped werden. Ich habe den Eindruck, dass das Bild dadurch auch leicht ruckelig ist, aber es ist jetzt auf jedenfall ansehbar.


    Ob meine Berechnung der zu droppenden Frames wirklich exakt so passt, weiß ich nicht. Ich hab da ehrlich gesagt geraten und weiß nicht, wo die (25*90) genau herkommen. Aber so erschien es für mich logisch und es scheint ja zu passen.


    Vielleicht kann sich ja jemand von den Autoren (vielleicht rofafor) das mal anschauen und überlegen, ob es Sinn macht, das so aufzunehmen.



    English:


    I checked why the video is too slow for me with vaapi (Intel) and softhddevice even although I am on latest ffmpeg 3.3.2. I looked what happens in function VaapiSyncDecoder of file video.c. Noticed that there is code to drop frames if audio is in front of video, but noticed it does not drop enough frames for me. So I did the changes that can be seen in the code above (in the German text above). This works for me now and it quite often drops 2 frames. Even though it seems to work, I don't know exactly if my computation of how many frames to drop makes full sense. Would be great if one of the softhddevice authors (maybe rofafor) could have a look and see if this should be added to the git (maybe in modified version). Thanks.

    VDR 1: Linux Mint 18.1 mit VDR 2.2.0 und Ausgabe auf X11 (Radeon HD6450) via softhddevice/vdpau. DVB-Karte: DVBSky T9580V3
    VDR 2: Ausgabe auf X11 (Intel i5 Kaby Lake) via softhddevice/vaapi, sonst wie VDR 1

  • Hallo mighty-p,


    Dein Patch funktioniert bei bei mir auch. Bild und Ton sind live und in Aufnahmen synchron :] :D
    Vielen Dank!


    Ffmpeg ist bei mir auch 3.3.2:


    Bei mir wird aber anscheinend viel mehr geduped als gedroppt. Das Log-File voll davon:


    :grinzs
    Endlich wieder HD!!


    Beste Grüße
    Christian

    Server/Client 1: VDR4ARCH VDR 2.4.0+softhdcuvid, Celeron G3900, GTX1030, DVB-T2: Hauppauge WinTV-quadHD, DVB-S: Digital Devices Cine S2 V6.5, DVB-C: GENIATECH MyGiga T230 für DVB-C
    Client 2: VDR4ARCH VDR 2.2.0 + softhddevice, Intel NUC6CAYB

  • mighty-p


    Danke für Deine Mühen.


    Kannst Du bitte den Tryfix als Pullrequest in github an rofafor stellen oder zumindest eine Patch Datei (Diff mit Header) zur Verfügung stellen?


    [Edit] Den Vorschlag eben getestet mit meiner Intel Haswell HW, Video läuft nicht mehr "zu" langsam, aber Ton asynchron und hat Aussetzer ...


    Regards
    fnu

    HowTo: APT pinning

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von fnu ()

  • Ja, da ist noch etwas im Argen, habe ich inzwischen selber gemerkt :) Ich denke, der Patch passt leider noch nicht.

    VDR 1: Linux Mint 18.1 mit VDR 2.2.0 und Ausgabe auf X11 (Radeon HD6450) via softhddevice/vdpau. DVB-Karte: DVBSky T9580V3
    VDR 2: Ausgabe auf X11 (Intel i5 Kaby Lake) via softhddevice/vaapi, sonst wie VDR 1