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

  • So... ich wollte nicht locker lassen und hab mir gedacht "morgen ist Sonntag, da musste ja nicht früh aufstehen". Und was soll ich sagen, ich hab den Bug gefunden :]


    Im Code der Funktion VaapiRenderFrame() ist ein Bug, der generell für eine Auflösung mit 720 Pixeln Höhe den Decoder auf "nicht interlaced", aber für alle anderen Höhen (also auch 1080) auf "interlaced" setzt. Das ist natürlich sehr schlecht, denn DVB-T2 ist 1080p - also progressiv und nicht interlaced.


    Interessanterweise ist derselbe Code in der VdpauRenderFrame() per "#if 0" auskommentiert. Wird schon seinen Grund haben... Ich schlage daher vor, dasselbe auch für Vaapi zu machen.


    Folgender Patch macht dies: Achtung, habe den Patch um 1:51 Uhr nochmal verbessert. Die erste Version war Quatsch.


    Damit tut es bei mir. Bild läuft mit der erwarteten Geschwindigkeit, Bild und Ton sind synchron, absolut nichts ruckelt. Und die vorherigen Änderungen aus Beitrag 17 sind natürlich unnötig bzw. kontraproduktiv (also bitte meinen alten Patch aus Beitrag 17 wieder rückgängig machen, wer den schon angewendet hat).


    P.S. Short English text:
    Please see the patch above (which replaces my earlier patch from post#17). It fixes the fact that for Vaapi the interlaced flag was always set for resolutions with a height!=720 (and progressive always for height==720). This fixes the issue that video was played back too slow for German DVB-T2 which is in 1080p (which means here the assumption that height!=720 means interlaced was purely wrong!). Applying this change, VaapiRenderFrame will behave the same as VdpauRenderFrame() already did before in this respect (probably for good reason).

  • So... ich wollte nicht locker lassen und hab mir gedacht "morgen ist Sonntag, da musste ja nicht früh aufstehen". Und was soll ich sagen, ich hab den Bug gefunden :]


    Guten Morgen und herzlichen Glückwunsch! 8) :] :D


    Die Nachtarbeit hat sich mehr als gelohnt, ich kann bestätigten, dass Dein neuer Patch sauber funktioniert.
    Das Log sieht gut aus und der Kanalwechsel erfolgt auch viel sauberer als mit dem Vorgängerpatch.


    Vielen Dank und beste Grüße
    Christian

  • Danke für's Testen, sg75 :) Freut mich, dass das so anscheinend jetzt wirklich klappt. Bin mal gespannt, ob es mit dieser Änderung bei fnu auch flüssig läuft. Dann sollten wir nämlich schauen, dass wir den Patch ins git rein kriegen.

  • ob es mit dieser Änderung bei fnu auch flüssig läuft.

    Leider nein, aber der Patch ist wichtig und richtig, behebt einen Fehler.


    Gleiches Bild wie vorher auch hier, Video hat normale Geschwindigkeit, Ton ist aber asynchron und hat Aussetzer die auch im Bild zu sehen sind. Die Aussetzer werden mit der Laufzeit immer häufiger. Da es bei Haswell ja rein Softwareausgabe ist, vermute ich da liegt irgendwo das Problem.


    Das die HW potent genug für HEVC HD Softwareausgabe ist, sehe ich mit xineliboutput ... vaapi & opengl2.


    Regards
    fnu

    HowTo: APT pinning

  • Zitat von lostinspc

    Wurde grade in den branch vpp_suppor gemerged, danke auch an rofafor und pesintta ....


    :tup Thanks a lot to rofafor and pesintta for taking over the patch to the git.


    Zitat von fnu

    Gleiches Bild wie vorher auch hier, Video hat normale Geschwindigkeit, Ton ist aber asynchron und hat Aussetzer die auch im Bild zu sehen sind. Die Aussetzer werden mit der Laufzeit immer häufiger. Da es bei Haswell ja rein Softwareausgabe ist, vermute ich da liegt irgendwo das Problem.


    Das die HW potent genug für HEVC HD Softwareausgabe ist, sehe ich mit xineliboutput ... vaapi & opengl2.


    Schade, dass es damit bei dir nicht flüssig läuft. Benutzt du softhddevice mit "-v va-api" oder mit "-v va-api-glx"? Vielleicht läuft es ja mit dem jeweils anderen besser.


    [EDIT] fnu, was gibt denn bei dir "vainfo" aus? Ist da das Profil VAProfileHEVCMain dabei? Ich habe gerade mal mit meinem älteren Laptop mit Intel CherryView getestet und ihn als streamdev-client mit dem anderen VDR verbunden. Auch mit dem CherryView-Chip scheint dvb-t2 zu gehen. Gelegentliche kürzere Hänger schiebe ich im Moment auf meine wacklige WLAN-Verbindung.

  • "-v va-api" oder mit "-v va-api-glx"?

    Eigentlich "va-api", aber eben nochmal "va-api-glx" probiert, Video subjektiv ruckeliger, Ton async, aber keine Aussetzer.


    Hatte "va-api-glx" seit Umstellung auf Intel VA 1.8.1 nimmer getestet gehabt ...


    Ist da das Profil VAProfileHEVCMain dabei?

    Nein, sonst wäre es ja HW unterstützt ...


    Regards
    fnu

    HowTo: APT pinning

  • Schade, das mit dem va-api-glx war nur mal ein Schuss ins Blaue, ob das bei Software-Decoding etwas bringt.


    Ich fürchte, dass dann einfach bei softhddevice das Softwaredecoding nicht so effizient wie in xineliboutput implementiert ist.

  • Mein Apollo-Lake Testsystem läuft jetzt auch sauber, danke.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • das mit dem va-api-glx war nur mal ein Schuss ins Blaue,

    Ja, kein Thema, war eine gute Erinnerung, "va-api-glx" läuft sogar gut mit 1.8.1 (hd), hatte mit älteren Intel VA Versionen etwas Probleme damit ...

    HowTo: APT pinning

  • So, ich habe die Lösung von mighty-p jetzt über eine Woche produktiv im Einsatz.
    WA-Faktor der Gesamtlösung ist ausreichend hoch :)
    Eine neue Herausforderung gibt es auch, mein Raspberry-Client im Schlafzimmer kann kein HEVC 1080P mit 50Hz abspielen und wird es wohl niemals schaffen.


    Aber das ist eine andere Baustelle ...


    Das ursprüngliche Problem scheint gelöst zu sein und der Fix ist bei rofarfor im git.


    Vielen Dank nochmal an mighty-p!
    Ich habe den Betreff als "gelöst" markiert.


    Beste Grüße
    Christian

  • Mein Apollo-Lake Testsystem läuft jetzt auch sauber, danke.


    Bei mir auch, UHD Sender laufen jetzt ebenfalls ruckelfrei. :tup
    Herzlichen Dank, mighty-p

Jetzt mitmachen!

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