[softhddevice] Konfiguration für intel-vaapi?

  • Hallo,
    ich hab jetzt angefangen meinen ersten "richtigen" VDR aufzusetzen und muss feststellen das ich vieles sehr viel schneller hinbekommen habe als gedacht, doch jetzt komme ich nicht mehr weiter:


    Mein Fernseher kann leider nur 720p vernünftig, bei nativer Auflösung (1366x768) akzeptiert er nur 60Hz. Habe X.org daher auf 1280x720 50Hz eingerichtet:


    Erster Versuch mit vaapi / intel treiber aus Ubuntu 12.04, softhddevice ist immer auf beste Scaling-Qualität und TemporalSpatial-Deinterlace:
    720p (öff.-recht. HD): Bild perfekt, kein Ruckeln, Lauftext geht perfekt
    576i (alle SD Sender): Scaling unterirdisch (wie "next-neighbor"), man hat das Gefühl deinterlacing funktioniert durch halbieren der vertikalen Auflösung, kein Ruckeln, Lauftext geht perfekt
    1080i (Servus TV HD, BBC HD, Channel 4 HD, private): Qualität nicht optimal aber fürs erste akzeptabel, immer kleine Ruckler, Bild läuft nicht flüssig


    Zweiter Versuch mit selbst kompilierter aktueller libva / Intel-treiber (1.1.0):
    720p (öff.-recht. HD): Bild perfekt, kein Ruckeln, Lauftext geht perfekt (kein Unterschied festzustellen)
    576i (alle SD Sender): Scaling gut, deinterlacing erzeugt "wackliges Bild", zwischen den Frames gibt es einen Versatz (extrem ausgedrückt das Senderlogo geht immer hoch-runter-hoch-runter...), kein zeitliches Ruckeln
    1080i (Servus TV HD, BBC HD, Channel 4 HD, private): Qualität besser, immer kleine Ruckler, Bild läuft nicht flüssig


    Gibt es bestimmte Patches/Einstellungen mit den man die Probleme bei 576i und 1080i in Griff bekommt? Ich hab was gelesen von libva-ext, sind da Dinge enthalten die Version 1.1.0 noch fehlen?
    softhddevice ist die aktuelle Git-Version vom 29.5.2012


    Vielen Dank



    System:
    VDR: 1.7.27
    OS: Ubuntu 12.04 64-Bit (alternate install ohne Desktop, mit Kernel 3.3.7)
    CPU: Intel Core i5-2390T
    CPU-Kühler: Scyte Kozuti (durch Bios runtergeregelt, ab 1m Abstand selbst bei totaler Stille unhörbar)
    Mainboard: Gigabyte G1.Sniper M3 (mATX mit Z77)
    SDD: Intel SSD 520 Series 120GB
    RAM: 8GB DDR3L 1333MHz CL7
    Netzteil: picoPSU-90 12V (derzeit noch an 12V Labornetzteil, Verbrauch im VDR-Betrieb ca. 2,3A an 12V (ca. 28W), Leerlauf ca. 1,65A (ca. 20W))
    Gehäuse: Silverstone ML03B (mATX low-profile)
    DVB: SaTiX-S2 Sky Xpress Dual (baugleich mit DVBsky S952)

  • Moin,


    Die geringe Auflösung kommt durch den Bob Deinterlacer.
    Das 1080i Problem kommt vom Zusammenspiel Plugin/VA-API, du kannst mal xine-lib für vaapi testen, da habe ich das Gefühl das es nicht ist.


    Soweit ich weiss ist der besser Deinterlacer nur im Branch staging und vaapi-ext drin.


    http://cgit.freedesktop.org/vaapi/intel-driver/
    http://cgit.freedesktop.org/vaapi/libva/


    Wie man es Distribution conform macht, weiss ich leider nicht.
    Ich habe einfach über die Distributions VA-API installiert.


    Code
    rm -rf /usr/lib/va /usr/include/va /usr/lib/libva*
    git clone git://anongit.freedesktop.org/vaapi/libva
    cd libva
    git checkout staging
    ./autogen.sh --prefix=/usr --with-drivers-path=/usr/lib64/va/drivers
    make
    make install
    ....


    Danach muß man das Plugin neu bauen!


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Du kannst auch den Software Deinterlacer testen: Software Spatial.
    Das ist meine yadif Adaption in C, reicht aber nur für SDTV mit G620.
    Die C Vector oder sse Version sind leider noch nicht fertig,


    Wie immer ist da Hilfe willkommen.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Nun, ich hab jetzt libva-staging installiert (1.2.0pre) und auch den aktuellen intel staging treiber, kann kein Unterschied zu libva 1.1.0 feststellen (ist ja auch erst vor 5 Tagen released worden).


    Zitat

    Das 1080i Problem kommt vom Zusammenspiel Plugin/VA-API, du kannst mal xine-lib für vaapi testen, da habe ich das Gefühl das es nicht ist.

    Was genau meinst du damit?


    yadif geht bei mir auch nur mit 576i, aber da ist die Qualität von TemporalSpatial besser (desweiteren steigt der Stromverbrauch um rund 5 Watt gegenüber TemporalSpatial). Das wackeln ist hier auch da. Das ist grundsätzlich bei allen Deinterlacern außer bei weave.
    Bei 576i fällt auch sehr deutlich auf das bei jedem zweiten frame die oberste Zeile schwarz ist. Das kann doch nicht richtig sein, insbesondere da das bei weave nicht ist. Da scheint irgendwo ein Problem zu sein.

  • TemporalSpatial gibts für Intel nicht, oder meinst du da im Vergleich zu VDPAU?


    Bei 1080i meine ich, daß die Demo putsurface von VA-API funktioniert.
    Wenn ich ein Frontend mit [ANNOUNCE] xine-lib vaapi support verwende, es mir auch nicht auffällt.
    Somit die Ursache an der Kombination SoftHdDevice + VAAPI liegen könnte.


    Im Staging sind zwar die besseren Deinterlacer vorhanden, aber werden scheinbar nicht mehr verwendet.
    Ich hatte es ja schon vermutet, warum seht hier http://lists.freedesktop.org/a…va/2012-March/000808.html
    vaapi-ext scheint noch zugehen, aber damit gibt es GPU Hänger.


    Man muß schon besonders dumm sein, wenn man etwas was gut funktioniert ausbaut, nur weil es nicht so vorgesehen ist, ohne die Alternative fertig zuhaben.


    Da bleibt nur NVidia zukaufen, solange die noch Video Dekodierung mit Linux unterstützen.
    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Zitat

    TemporalSpatial gibts für Intel nicht, oder meinst du da im Vergleich zu VDPAU?

    Nein, was auch immer passiert wenn ich TemporalSpatial in softhddevice einstelle, es sieht besser aus als das interne yadif. Aber erst seit libva 1.1, davor war das eine Katastrophe.


    Zitat

    Bei 1080i meine ich, daß die Demo putsurface von VA-API funktioniert.
    Wenn ich ein Frontend mit [ANNOUNCE] xine-lib vaapi support verwende, es mir auch nicht auffällt.
    Somit die Ursache an der Kombination SoftHdDevice + VAAPI liegen könnte.

    Ich bekomme xine-lib-vaapi nicht kompiliert, der mault das vaCreateSurface mehr Parameter braucht, da ist die API wohl nicht kompatibel.


    Ich habe putsurface ausprobiert, ich kann ein ganz leichtes ruckeln feststellen, sowohl bei 720p (putsurface -g 1280x720+0+0 -w 1280 -h 720 -r 50), als auch bei 1080p (putsurface -g 1280x720+0+0 -w 1920 -h 1080 -r 50), das ist aber beide mal gleich und deutlich geringer als bei softhddevice 1080i, kann sein das der Fernseher gar nicht echte 50Hz kann und das ruckeln daher kommt (und nur bei diesem Extremtest auffällt), werde es nochmal mit meinem PC-Monitor überprüfen der ganz sicher echte 50Hz kann.


    Zitat

    Im Staging sind zwar die besseren Deinterlacer vorhanden, aber werden scheinbar nicht mehr verwendet.
    Ich hatte es ja schon vermutet, warum seht hier http://lists.freedesktop.org/archives/li…rch/000808.html
    vaapi-ext scheint noch zugehen, aber damit gibt es GPU Hänger.


    Man muß schon besonders dumm sein, wenn man etwas was gut funktioniert ausbaut, nur weil es nicht so vorgesehen ist, ohne die Alternative fertig zuhaben.


    Da bleibt nur NVidia zukaufen, solange die noch Video Dekodierung mit Linux unterstützen.

    Das sind ja tolle aussichten, aber bei open-source kann man ja patchen und zur Not forken (auch wenn das nicht immer im Sinne der Benutzer ist, siehe libav vs. ffmpeg)... Ist denn jemand von hier bei vaapi auf den mailing-listen aktiv und weist auf die Probleme hin?
    Bevor ich eine Nvidia-Grafikkarte kaufe macht das deinterlacing lieber die cpu, ist vermutlich immer noch effizienter (und leiser) als eine Graka.
    Hier ist ein bis SSSE3 optimierter GPL yadif source: http://avisynth.org.ru/yadif/yadif17.zip
    Der deinterlacer scheint auch keine abhängigkeiten zu haben, der assembler-code muss aber natürlich an 64-bit angepasst werden (SSSE3 reicht ja, alle Prozessoren mit vaapi können ja auch SSSE3, der andere kram fliegt raus) und die calling-conventions an Linux.

  • TemporalSpatial ist bei VA-API nur Bob Deinterlacer.
    Und mein Software Deinterlacer ist nur Spatial, ich hatte mich da vertan, temporal fehlt noch.
    Ich habe dann nicht weitergemacht, wenn schon spatial zulangsam ist, dann lohnt es sich nicht weiterzumachen.


    Es kann sein das ich für Ruckeln unanfälliger bin, mir ist nichts aufgefallen.
    putsurface gibt aber die 'Wiederholrate' aus, wenn da 50 Hz steht bzw. 20ms, dann arbeitet zumindest der Rechner zum Fernseher in 50Hz.


    Ich verstehe die VA-API Developer nicht, die haben fast alles fertig und hat ja schon gut funktioniert. Was noch fehlt ist die Funktion über die neue API zur Verfügung zustellen.
    Und noch ein Test/Demo Programm dazu. Zumindest war es bei meinem letzten Test noch so.


    Ich weiß nicht ob es den Compiler für die Shaderprogramme öffentlich gibt, wenn ja, dann kann man selbst noch an den Deinterlacern spielen.


    Temporal ist in meinen Plugin noch schwierig, aber machbar. Die Frage ist, lohnt sich die Arbeit bzw. ist es überhaupt lösbar.
    Wenn 1080i mit sse4 yadif nicht ohne Framedrops machbar ist, dann kann man es auch gleichbleiben lassen.
    mplayer kann auch va-api, ich weiß aber nicht ob man yadif mit va-api kombinieren kann. Damit könnte man testen ob die CPU Leistung reicht.
    Zur Not kann man yadif noch als Multithread lösen.


    Und der Temporale Deinterlacer im Inteltreiber war auch nicht schlecht.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Zitat

    TemporalSpatial ist bei VA-API nur Bob Deinterlacer.
    Und mein Software Deinterlacer ist nur Spatial, ich hatte mich da vertan, temporal fehlt noch.
    Ich habe dann nicht weitergemacht, wenn schon spatial zulangsam ist, dann lohnt es sich nicht weiterzumachen.

    Wo stand den was von Software temporal? Ich hab einfach mal den yadif von libav eingebaut, bis jetzt schafft er aber nur genau ein Bild, dann stürzt der vdr ab. Ich habe für die Puffer ein Array aus 5 Pointern auf die einzelnen Bilder angelegt (selbstdefinierter Datentyp, kein VAImage) in dem decoder struct. Die werden auf null initialisiert und wenn der deinterlacer das erste mal startet und die pointer null sind holt er sich mit malloc den Speicher. Funktioniert auch alles, die ersten beiden Bilder kommen auch und werden angezeigt, doch dann passiert folgendes: Irgendwas beschädigt den Puffer, ich habe das mit printf verfolgt: Bis zum ende der funktion VaapiSyncRenderFrame ist noch alles in Ordnung, doch direkt am Anfang des nächsten Aufrufs von VaapiSyncRenderFrame sind die Puffer verändert (beliebig, einzelne Werte haben sich verändert, jedes mal anders).
    Gibt es dafür irgendeine sinnvolle Erklärung warum sich speicher, der nur von einer vorher unbekannten Variablen referenziert wird, verändert während unveränderter Code ausgeführt wird? Ist da irgendeine Speicherbereinigung, darf man kein malloc verwenden oder was ist das Problem? Da ich praktisch nie was größeres unter Linux programmiere habe ich auch keine Idee wie ich das debuggen soll außer das Programm mit printf vollzumüllen.


    VA-API Bob macht interessanterweise das bessere Bild als Software Spatial für 576i. Liegt vielleicht am zusammenspiel mit dem resizer. Komisch das die ältere libva (bzw. der ältere Intel-Treiber) ein grauenhaftes Bild macht bei den gleichen einstellungen.

    Zitat

    Es kann sein das ich für Ruckeln unanfälliger bin, mir ist nichts aufgefallen.
    putsurface gibt aber die 'Wiederholrate' aus, wenn da 50 Hz steht bzw. 20ms, dann arbeitet zumindest der Rechner zum Fernseher in 50Hz.

    Ich habe es jetzt an meinem Monitor gestestet der sicher 50Hz nativ darstellen kann: Auch hier hat putsurface leichte ruckler, egal ob 720 oder 1080. Bei softhddevice kann ich bei 720p keine Ruckler feststellen, bei 1080i sind sie sehr viel deutlicher als bei putsurface. Vielleicht mach ich mal so ein ruckel-testvideo so ähnlich wie von putsurface fertig (oder gibts das irgendwo als video?) das man dem vdr dann als aufnahme unterjubeln kann, dann kann man besser vergleichen.


    Zitat

    Ich verstehe die VA-API Developer nicht, die haben fast alles fertig und hat ja schon gut funktioniert. Was noch fehlt ist die Funktion über die neue API zur Verfügung zustellen.
    Und noch ein Test/Demo Programm dazu. Zumindest war es bei meinem letzten Test noch so.


    Ich weiß nicht ob es den Compiler für die Shaderprogramme öffentlich gibt, wenn ja, dann kann man selbst noch an den Deinterlacern spielen.

    Das Problem ist ja nicht das sie das über eine neue (bessere?) API zur Verfügung stellen wollen, sondern das das vermutlich keine Frage von Wochen oder ein paar Monaten ist, sondern beim Entwicklungstempo von libva eher Jahre.
    Wenn das an sich soweit funktioniert hat, könnte man doch einfach einen patch gegen die stabile libva-version pflegen bis die neue API fertig ist. Kommt halt darauf an wie viel Arbeit das ist.

    Zitat

    Temporal ist in meinen Plugin noch schwierig, aber machbar. Die Frage ist, lohnt sich die Arbeit bzw. ist es überhaupt lösbar.
    Wenn 1080i mit sse4 yadif nicht ohne Framedrops machbar ist, dann kann man es auch gleichbleiben lassen.
    mplayer kann auch va-api, ich weiß aber nicht ob man yadif mit va-api kombinieren kann. Damit könnte man testen ob die CPU Leistung reicht.
    Zur Not kann man yadif noch als Multithread lösen.

    Wo siehst du das Problem mit temporal? Sofern das Audio verzögert werden kann, sehe ich keins. Theoretisch werden in meinem Code die ersten beiden Bilder jetzt doppelt ausgegeben und dann ist das audio immer 40ms voraus. Ich hab die drei puffer prev, current und next, das neue bild wird next, die puffer werden einfach am ende immer gedreht so das next current wird, current wird prev, und prev wird wieder next und beim nächsten aufruf durch das neue bild überschrieben (die Puffer sind alle yadif-intern, nichts mit VA-API).
    SSSE3 hab ich noch nicht zum laufen bekommen, dieser furchtbare inline-assembler beschwert sich das dort falsche register verwendet werden und so, ich weiß nicht ob da was mit den 5000 pre-prozessoren irgendwas nicht stimmt oder ob die fehlermeldung falsch ist und ich das mit einem compiler-switch wegbekomme (besonders toll sind die dann die fehlermeldungen die sich auf eine zeile 457 beziehen, die datei aber nur 263 zeilen hat!). Das Problem scheinen aber viele mit yadif zu haben. Bevor aber die c version nicht läuft kümmere ich mich erstmal nicht um ssse3. danach gibt es noch optimierungsmöglichkeiten für nv12->planar mit sse2 bzw. planar->nv12 mit ssse3

  • Moin,


    Zitat

    Wo stand den was von Software temporal?


    Ich bezog mich auf meine eingebaute Lösung, und meine Aussage ein paar Posts vorher, ich dachte die wäre schon fertig und wäre somit yadif.



    Den Rest versuche ich gemeinsam zubeantworten.
    Im Moment erfolgt der Deinterlacer so:


    VaapiCpuDerive wird bei Intel aufgerufen. Die Surface enthält 2 Halbbilder.
    Der Speicherbereich für diese wird für die CPU gemapped.
    Arbeiten mit diesem kann extrem langsam sein.
    Deshalb ich mit verschiedenen Methoden experimentiert.
    Für Yadif diese Halbbilder konvertieren bzw. speichern.
    Dann erzeuge ich aus diesen zwei Halbbilder zwei Vollbilder.
    Für diese werden wieder zwei Surface in den Speicherbereich der CPU gemapped und diese mit den CPU Vollbildern gefüllt.
    Danach kommen die zwei Surface in die Ausgabe Queue.


    Diese gemappten Surface sind nur wärend des Funktionsaufruf gültig, könnte sein das hier dein Problem liegt.
    Dann arbeitet yadif mit Halbbildern und VA-API sind Vollbilder.


    Also man speichert 2 Surface: S0, S1 diese werden dann immer rotiert, die älteste fällt weg, die neue kommt dazu: S2, S3.
    Eine Surface enthält die Halbbilder Top und Bottom: S0 = T0B0.
    yadif braucht nun Future, Current und Past: T0B0 T1B1 das wäre dann zb.
    Past T0, Current B0 und Future T1
    Past B0, Current T1 und Future B1


    Ein Problem meiner Lösung ist, das ich zwei neue Surface gleichzeitig erzeuge, habe aber nur 20ms Zeit.
    Dafür mache ich dann 20ms nichts.
    Entweder löst man den Deinterlacer durch 1-2 Threads oder baut den Aufruf an eine andere Stelle


    Ich würde Threads nehmen, da man da dann zumindest 2 Deinterlacer Threads parallel laufen lassen kann.


    Bei va-api ist noch die Demo mpeg2vldeo dabei die dekodiert und anzeigt.
    Ansonsten ist der Anfang meines Testcode in Vappi1080i, muß mal gucken ob mein extra Test Programm neuer ist.


    Edit:
    In ffmpeg ist auch noch eine Assembler yadif Lösung.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • So hier mein Test Programm für das 1080i Problem.
    Beim letzten Test vor ein paar Monaten, ist es einfach abgestürzt,
    Deshalb vaapi-killer :)
    Habe es mehrmals versucht auf der VA-API Mailingliste zuposten, aber deren Maintainer schläft
    oder die Deppen wissen gar nicht was dies ist.


    Code
    chmod +x vaapi-killer.c
    ./vaapi-killer.c
    ./vaapi-killer


    Mit VDPAU Funktionert es, aber auch ohne v-sync.
    Wenn es funktioniert kann man es langsam erweitern bis die Probleme mit dem 1080i v-sync auftreten und dann entweder den Fehler in VA-API suchen oder nochmal versuchen auf der Mailiingliste eine Antwort zubekommen.


    Edit:
    Mit export VDPAU_VIDEO_PUTSURFACE_FAST=0 funktioniert es mit VA-API/VDPAU und v-sync.


    Edit: aktuelle version der demo ist in neueren posts.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    3 Mal editiert, zuletzt von johns ()

  • So habe ich yadif implementiert (der restliche code ist unverändert aus libav/ffmpeg):


    In der video.c (ich geb den speicher bis jetzt noch nirgendwo wieder frei):

    Dazu natürlich noch die beiden Methoden auf den Listen ergänzt. Das Problem is das sich das height-Array einzelner yadif_images verändert, und zwar nach beendigung von VaapiSyncRenderFrame und vor dem erneuten Aufruf von VaapiSyncRenderFrame. Woran kann das liegen?



    Ich werden den vaapi-killer gleich mal ausprobieren, VDPAU kann ich aber nicht testen.

  • Also vaapi_killer macht bei mir gar nichts, das ist die Ausgabe:

    Auf dem Bildschirm passiert nichts.


    Ich habe das Problem bei yadif nochmal weiter gesucht: Irgendwas überschreibt den Speicher, und zwar außerhalb des vaapi-Moduls. Dies muss während einer Initialisierung sein nachdem das erste Bild dekodiert wurde. Ich habe es bis jetzt dreimal geschafft das yadif läuft ohne das er abstürzt. Wenn der zweite Aufruf in Ordnung ist passiert auch nichts mehr, dann läuft er stabil. Es ist egal ob man auf dem Sender startet oder von 720p dahinwechselt, die Wahrscheinlichkeit für einen Absturz nach einem Bild liegt bei etwa 95%. Wenn er die Hürde geschafft hat gehts.
    kann es sein das dort irgendwas nicht thread-safe ist oder sowas und der speicher von einem anderen Thread überschrieben wird?
    Bei 1080i (nicht fake) schafft er im TemporalSpatial-Modus etwa 3 Bilder pro Sekunde :( Ob das der SSE-Code tatsächlich verzwanzigfachen kann bezweifel ich, aber für 576i wird das sicher mehr als ausreichend sein (das hinkt nur ein ganz kleines bisschen im Moment). Multithreading sollte nicht so kompliziert sein, so wie ich das sehe wäre es eine Möglichkeit das Bild einfach horizontal zu teilen, da yadif pro zeile arbeitet und jede ausgegebene Zeile unabhängig von der vorherigen ist.
    Ich hab den Code einfach mal (in einem sehr unaufgeräumten Zustand) in den Anhang getan, vielleicht findest du eine Lösung für dieses Speicherproblem. Ich werd da nicht schlau draus.


    Nachtrag: Ich hab den Fehler beim ASM-Code gefunden, da war an einer Stelle 64-Bit nicht definiert und deshalb kam murks raus. Jetzt weigert er sich zu linken, da "-fPIC" fehlt. Habe "-fPIC" im makefile ergänzt (für C und CXX), mault aber immer noch. Er benennt explizit die datei mit dem inline-assembler, doch die ist gnaz sicher mit -fPIC kompliert. Linkt er noch gegen irgendwas was ich mit "-fPIC" neu kompilieren muss?

  • Also vaapi_killer macht bei mir gar nichts, das ist die Ausgabe:
    Auf dem Bildschirm passiert nichts.


    IIRC hatte ich auch das Problem, "#if 0" -> "#if 1" VA-API scheint erst nach einen Zugriff die Flächen anzulegen.


    Zitat

    Ich habe das Problem bei yadif nochmal weiter gesucht: Irgendwas überschreibt den Speicher, und zwar außerhalb des vaapi-Moduls. Dies muss während einer Initialisierung sein nachdem das erste Bild dekodiert wurde. Ich habe es bis jetzt dreimal geschafft das yadif läuft ohne das er abstürzt. Wenn der zweite Aufruf in Ordnung ist passiert auch nichts mehr, dann läuft er stabil. Es ist egal ob man auf dem Sender startet oder von 720p dahinwechselt, die Wahrscheinlichkeit für einen Absturz nach einem Bild liegt bei etwa 95%. Wenn er die Hürde geschafft hat gehts.
    kann es sein das dort irgendwas nicht thread-safe ist oder sowas und der speicher von einem anderen Thread überschrieben wird?
    Bei 1080i (nicht fake) schafft er im TemporalSpatial-Modus etwa 3 Bilder pro Sekunde :( Ob das der SSE-Code tatsächlich verzwanzigfachen kann bezweifel ich, aber für 576i wird das sicher mehr als ausreichend sein (das hinkt nur ein ganz kleines bisschen im Moment). Multithreading sollte nicht so kompliziert sein, so wie ich das sehe wäre es eine Möglichkeit das Bild einfach horizontal zu teilen, da yadif pro zeile arbeitet und jede ausgegebene Zeile unabhängig von der vorherigen ist.
    Ich hab den Code einfach mal (in einem sehr unaufgeräumten Zustand) in den Anhang getan, vielleicht findest du eine Lösung für dieses Speicherproblem. Ich werd da nicht schlau draus.


    Ich werde es mir mal angucken. Im Normalfall nehme ich da valgrind der findet solche Fehler schnell. Ansonsten kann man noch mit GDB einen Speicher Watchpoint erstellen.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Code
    buf_imgs[1]=buf_imgs[0]+sizeof(vaapi_yadif_img);


    Ist doppelt gemoppelt hier wird die Größe noch mit der Größe von buf_imgs multipliziert.


    Code
    buf_imgs[1]=(void*)buf_imgs[0]+sizeof(vaapi_yadif_img);


    (void*) geht nur bei gcc. ansonsten erst nach (char*) casten und das Ganze zu void* oder typeof(buf_imgs[1]).


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Die Version läuft, killt nur X11 beim Beenden.


    • video/vaapi: libva 0.34 (Intel i965 driver - 1.0.16.pre1) initialized
    • kernel 3.4
    • xserver 1.12.2




    Johns

    Dateien

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Zitat

    Die Version läuft, killt nur X11 beim Beenden.


    video/vaapi: libva 0.34 (Intel i965 driver - 1.0.16.pre1) initialized
    kernel 3.4
    xserver 1.12.2

    Ich weiß nicht was passieren soll, jetzt sagt 39ms/frame (am Anfang 37, am Ende 39.92), die Ausgabe ist aber nur grün, und der X-Server sagt folgendes:

    Code
    (EE) intel(0): [DRI2] DRI2SwapComplete: bad drawable
    (EE) intel(0): [DRI2] DRI2SwapComplete: bad drawable


    Abstürzen tut er auch nicht. Hat das einen Grund das du den alten Intel-Treiber mit der neusten VA-API verwendest?

    Zitat

    Ist doppelt gemoppelt hier wird die Größe noch mit der Größe von buf_imgs multipliziert.

    Ahhh... Anscheinend waren die Zeiger die da berechnet wurden immer noch im Speicher vom vdr. Also wurde nicht der yadif-Speicher überschrieben sondern yadif hat einfach anderen Speicher überschrieben. Vielen Dank!
    Jetzt geht es (grundsätzlich gesprochen, umschalten kann man nicht auf Sender mit anderen Bildformaten, speicher wird auch noch nicht wieder freigegeben) :)
    Ich habe die nv12 <-> u+v planes c-Funktionen durch sse2/ssse3 Funktionen ersetzt, der Geschwindigkeitsgewinn ist bei 576i minimal spürbar (aber immer noch nicht flüssig), bei 1080i kein spürbarer Unterschied. Ich bekomme den yadif-assembler bloß nicht gelinkt, hast du da eine Idee? Hab den source wieder in en Anhang getan. Ich hab überhaupt keine Ahnung wie diese Makefiles aufgebaut sind, ich weiß nicht wie ich die Assembler-Datei da einbaue damit die mit yasm übersetzt wird, hab das dann manuell gemacht ("yasm -f elf -m amd64 -DPIC -g dwarf2 nv12_uv.asm").

  • Hab den Fehler gefunden: Da war noch ein makro falsch für den inline-assembler, dadurch wird der nicht pic kompiliert, egal was man tut. Mit ssse3 ist 576i in Echtzeit kein problem, sieht auch sehr gut aus. Für 1080i wie erwartet zu langsam, aber sehr viel schneller als die c-version. habe auch schon multithreading angefangen, bis jetzt arbeitet aber nur ein streifen, entweder nur ein thread macht etwas oder alle threads deinterlacen den gleichen streifen, ist mir jetzt zu mühsam zum debuggen (insbesondere ohne debugger). Kann man in vaapi_yadif.h ein- und ausschalten.
    Was sonst noch zu tun ist:

    Code
    -Audiosynchronisation: Das Bild hängt wie erwartet um 40ms, da muss der Ton angepasst werden
    -Speicher Clean-Up: Bei Senderwechsel (zumindest bei Formatwechsel) muss der Speicher wieder freigegeben und die threads beendet werden,
                        damit yadif sich beim nächsten mal neu initialisiert und nicht abstürzt
    -Makefile: yasm integrieren
    -Komplett ungetestet auf 32 Bit
    -Eine config.h / config.asm erstellen, welche die nötigen infos enthält (32/64 Bit, sse2/ssse3 vorhanden)
    -Skip Chroma ist noch nicht implementiert
    -Das erste Bild scheint fehlerhaft zu sein


    Zusatzfeature (gerade für Kinofilme/US-HD-Serien sinnvoll): Deinterlaceing über fernbedieung ausschaltbar machen.


    Dann mal schauen wie man der vaapi temporal-spatial beibringt.

  • Ich weiß nicht was passieren soll, jetzt sagt 39ms/frame (am Anfang 37, am Ende 39.92), die Ausgabe ist aber nur grün, und der X-Server sagt folgendes:

    Code
    (EE) intel(0): [DRI2] DRI2SwapComplete: bad drawable
    (EE) intel(0): [DRI2] DRI2SwapComplete: bad drawable


    Abstürzen tut er auch nicht. Hat das einen Grund das du den alten Intel-Treiber mit der neusten VA-API verwendest?


    Muß mal gucken, aber ich habe keine Fehlermeldung gesehen.
    Es soll nichts darstellenen. also das grüne Bild ist richtig.
    Der Treiber scheint die ersten Frames zupuffern und dadurch werden es keine 40ms.
    Der Intel-Treiber ist die GIT Version Branch:staging und da haben sie diese Versionnummer drin.


    Jetzt muß ich mal das Testprogramm erweitern bis kein v-sync mehr klappt.


    Zitat

    Jetzt geht es (grundsätzlich gesprochen, umschalten kann man nicht auf Sender mit anderen Bildformaten, speicher wird auch noch nicht wieder freigegeben) :)
    Ich habe die nv12 <-> u+v planes c-Funktionen durch sse2/ssse3 Funktionen ersetzt, der Geschwindigkeitsgewinn ist bei 576i minimal spürbar (aber immer noch nicht flüssig), bei 1080i kein spürbarer Unterschied. Ich bekomme den yadif-assembler bloß nicht gelinkt, hast du da eine Idee? Hab den source wieder in en Anhang getan. Ich hab überhaupt keine Ahnung wie diese Makefiles aufgebaut sind, ich weiß nicht wie ich die Assembler-Datei da einbaue damit die mit yasm übersetzt wird, hab das dann manuell gemacht ("yasm -f elf -m amd64 -DPIC -g dwarf2 nv12_uv.asm").


    Ich würde mal die GetMsTicks einbauen, dann sieht man wo die Probleme liegen.
    Eine lange Zeit wird für das Runterladen und Hochladen der Flächen verbraucht.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

  • Ich glaube ich habe den v-sync Bug gefunden.


    Anbei ein Patch gegen die aktuelle GIT Version, ich kann im Moment VA-API auf Intel nicht testen.
    Aber mit VDPAU Backend schaut es gut aus.


    Dann die aktuelle vaapi-killer Version. Ohne Parameter stimmt der v-sync nicht, mit beliebigen Parameter sollte der v-sync klappen.
    Es sollten ~40ms bei 50Hz Bildschirm sein.


    Ist auch ein nettes Demo für alle die sich mit VA-API Programmierung beschäftigen wollen.


    Edit: so konnte nun mit Intel HD2000 testen, leider ist es nicht gefixt.
    Aber das Test Programm funktioniert sehr gut, mit 1080i Auflösung sind die Streifen am flimmern wie Sau, mit geringerer Auflösung funktioniert es.


    Edit2: Je nach Version sind die Fehler unterschiedlich.


    Gemeinsam ist das ab 1281 Breite die Ausgabe anfängt zuflimmern. Die Höhe spielt keine Rolle.


    Edit3: Ist nun vaapi-demo und man kann nun mit dem Parametern spielen ohne immer neu zu kompilieren.


    Code
    gunzip vaapi-demo.c.gz
    chmod +x vaapi-demo.c
    ./vaapi-demo.c && ./vaapi-demo -h


    Johns

    Dateien

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    5 Mal editiert, zuletzt von johns ()

  • Ich hab mit vaapi-demo gespielt: Bei mir flimmert nichts mit 1920x1080, egal wie ich die Parameter kombiniere. Woran erkennt man das den genau bei grünen Bild? Sieht bei bir absolut statisch aus. X-Server gibt kein Fehler mehr aus.


    Ich hab mal getticks bei yadif eingebaut und das Ergebnis war in der Tat überraschend (bei 1440x1080, in Klammern bei 720x576):


    Ein Bild von Vaapi zu Yadif kopieren: 35ms (7ms)
    Bild deinterlacen mit zwei Ausgabeframes: 22ms (4ms)
    Zwei(!) Bilder von Yadif zu Vaapi kopieren: 8ms (1ms)


    Ich habe dann CopyVAImg2YadifImg untersucht und es kam folgendes bei raus: memcpy der Y-Plane: 22ms! UV interleaved nach UV planes kopieren: 11ms (der rest ist VAMapBuffer)
    Die SSE2 Funktion von libav für nv12->uv ist nicht so gut, das kann man mit SSSE3 dank pshufb bestimmt mehr als doppelt so schnell machen.
    Aber memcpy 22ms?? Mein erster Gedanke: Alignment: Beide pointer sind immer vielfache von 16. Nächster Hinweis: Angeblich soll memcpy schneller sein wenn die Differenz der Zeiger ein vielfaches von 64 ist: Das ist hier fast nie der Fall, bei YadifImg2VAImg aber auch nicht, und hier brauch memcpy maximal 1ms. Irgendeine Idee dazu?


    Wenn ein Bild von Vaapi nach Yadif genau so schnell geht wie andersrum bräuchte das Deinterlacen von 1080i nur noch 34ms und wäre damit im Bereich des machbaren. Mit Multithreading kann man das vermutlich noch weiter senken.



    Nochmal zur Intel-Treiberversion, auch staging hat bei mir die version 1.0.18? Hab ich von hier: http://cgit.freedesktop.org/vaapi/intel-driver/


    Nachtrag: Ich hab die Zeiten mal mit abgeschaltetem SSE gemessen: Ergebnis: Yadif selber braucht mehr als 7x soviel Zeit, bei Vaapi-zu-Yadif ändert sich nichts, Yadif-zu-Vaapi braucht minimal länger.
    Der Flaschenhals ist eindeutig der lesende Zugriff auf das VAAPI-Bild:
    Ich habe in der asm-Funktion für nv -> UV planes alles auskommentiert außer das lesen: praktisch kein Geschwindigkeitsunterschied, nur das lesen auskommentiert: nv -> UV planes braucht maximal 1ms statt 11ms. Die Frage ist warum? Ich hab probiert das Bild schon eher zu mappen und dann prefetch zu machen, ändert aber nichts. Gibt es irgendwelche speziellen VAAPI-prefetch Funktionen die irgendwie mit der GPU zusammenhängen?

Jetzt mitmachen!

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