Tester gesucht libva

    Zitat

    Original von lola
    soll das OSD so aussehen?


    Oje, nee, das sieht nicht gut aus :(
    Die Farbverläufe gehen zwar schräg, aber in die andere Richtung. Die zu erkennden Linien sind eigentlich ein Gitter. "vaAssociateSubpicture"-Errors sehe ich da ja auch noch.
    Ich seh schon, so wird das nix.
    Wenn ich das hier mit ungepatchtem vdpau-Backend mache, habe ich zwar Verschiebungen aber nicht solche Verzerrungen, d.h. das xvba-Backend handelt die Koordinaten wieder noch anders, na super...


    OK, immerhin Transparenz scheint richtig zu gehen.


    Wär wohl doch besser, wenn ich schonmal xvba-fähige HW hier hätte, wbreu bzw. @all, wie siehts denn da aus?


    Gruss,
    Thomas

    Zitat

    Original von tbshl-vdr


    Wär wohl doch besser, wenn ich schonmal xvba-fähige HW hier hätte, wbreu bzw. @all, wie siehts denn da aus?


    Gruss,
    Thomas


    Nabend Thomas,


    wie kann ich denn helfen, ich denke man sollte mal die abfragen, was die anderen so für Hardware für xvba haben, dann kann man sich auf eine Testplattform einigen. Das hätte halt den Vorteil, dass man einigermassen gleiche Voraussetzungen hätte.
    Ich habe z.B im Moment ein Intelsystem aufgebaut.


    Andere fahren die Tests mit AMD-Grafikkarten, die Frage wäre, welche genau?


    Wie schon gesagt/angeboten, wenn das klappt, besorge ich zeitnah entsprechende Hardware.... und sende sie dir unentgeltlich zu.


    Gruß
    Wolfgang

    Zitat

    Original von wbreu
    Andere fahren die Tests mit AMD-Grafikkarten, die Frage wäre, welche genau?


    bei mir ist es der 780G Onboard Cjipsatz, konkret hier


    sollten sicher auch viele haben.


    aber wäre zum testen für tbshl-vdr eine Steckkarte nicht praktischer?


    Gruß Fr@nk

    Zitat

    Original von lola
    aber wäre zum testen für tbshl-vdr eine Steckkarte nicht praktischer?


    Da ist natürlich was dran.
    Ich hab ja noch diese RX1550 hier liegen, von der ich noch nicht weiss ob die irgendwie xvba-geeignet ist, da ich kein (nicht genutztes) PCIe-Board hier habe, den "Arbeits"-Rechner möchte ich für solche Tests auch nicht unbedingt nutzen, schon gar nicht, nachdem der Test-Rechner sich in den letzten Tagen mehrfach soweit verabschiedet hat, dass nur noch reboot half (für das OSD wird von xineliboutput vom xine-lib-video_out die Ausgabegrösse abgefragt, was ich noch nicht implementiert hatte und -1 zurückgab, mit fatalen Folgen :( aber das nur am Rande...)
    Wenn die Test-HW also nicht doch Onboard (mit geeignetem PCIe) wird, wäre es gut, wenn sich auch noch ein MB finden würde. Also sonst auch, da immer umstecken ja auch zeitraubend ist und evtl. Treiber für verschiedene Systeme gleichzeitig Probleme machen könnte. Wer da also was übrig hat und (möglichst günstig :) ) anbieten kann...

    Hi nochmal,


    also ich werde mal konkret, nach ein bisschen Krabbeln in der Kiste..


    Ein ECS 780G-Mainboard mit ATI RV620-onboard habe ich noch sofort da liegen.
    Zudem habe ich noch eine ATI PCI-Express 3450 HD (ebenfalls RV620) rumliegen.


    Wie siehts denn bei dir dann aus, hast du DDR-2 Speicher und/oder CPU (Socket AM2+)?


    Gruß
    Wolfgang

    Zitat

    Original von wbreu
    Wie siehts denn bei dir dann aus, hast du DDR-2 Speicher und/oder CPU (Socket AM2+)?


    Leider nicht (Speicher evtl.). Sollte sich da nichts finden würde ich das eben investieren, wenn das Board dabei wegfällt ist das ja schonmal was.


    edit:


    Zitat

    Original von lola
    Bei Bedarf könnte ich den Hier beisteuern, hab ihn übrig - für gute Zwecke.


    Ah, schonmal danke, wenn nötig komm ich darauf zurück :)

    Die Bedienung ist deutlich angenehmer, wenn man wattr.height und wattr.width durch die Videoauflösung ersetzt + neu kompiliert.


    Was mir auffällt: Die Tasten 5+6 funktionieren bei vielen H.264 Level4 Videos wirklich nicht oder nur dann, wenn sie direkt nach dem Start von vatest aufgerufen werden. Drücke ich eine der anderen Tasten ist 5+6 blockiert. 1-4, o,t,z scheinen zuverlässig zu funktionieren, 1-4 hat eine Verzögerung von 1-2 Sekunden bis vatest reagiert.


    Transparenz ist prima auf allen Farben. Drückt man t/T länger stoppt die Transparenz nicht im Maximum/Minimum, sondern sie wandert quasi "hinten rum" in einer Endlosschleife.


    OSD Skalierung sieht so aus wie bei lola. wobei ich kein Vollbild habe durch den wattr Wechsel


    Thomas: Bei der Verkleinerung entstehen - wie im Screenshot von lola gut zu erkennen ist - Zeilenverschiebungen im OSD -> kriegt man die weg durch ein Refresh des OSD nach jeder Skalierung?

    MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

    Zitat

    Original von Lou
    Was mir auffällt: Die Tasten 5+6 funktionieren bei vielen H.264 Level4 Videos wirklich nicht oder nur dann, wenn sie direkt nach dem Start von vatest aufgerufen werden. Drücke ich eine der anderen Tasten ist 5+6 blockiert. 1-4, o,t,z scheinen zuverlässig zu funktionieren, 1-4 hat eine Verzögerung von 1-2 Sekunden bis vatest reagiert.


    Das ist ja nur ne ganz simple Tastenabfrage in der Video-Ausgabe-Schleife, alles andere als optimal.
    Dass z.B. 5+6 nicht geht - wenn rsrc.width mit 5 grösser wird als die Video-Breite sieht man ja keine Änderung mehr, evtl. stand das dann schon auf so einem Wert und es dauert bis 6 was bewirkt. Wenn das bei bestimmten Material aber tatsächlich gar nix tut ist das seltsam.


    Zitat

    Original von Lou
    Transparenz ist prima auf allen Farben. Drückt man t/T länger stoppt die Transparenz nicht im Maximum/Minimum, sondern sie wandert quasi "hinten rum" in einer Endlosschleife.


    Ja, läuft dann einfach über.


    Zitat

    Original von Lou
    Thomas: Bei der Verkleinerung entstehen - wie im Screenshot von lola gut zu erkennen ist - Zeilenverschiebungen im OSD -> kriegt man die weg durch ein Refresh des OSD nach jeder Skalierung?


    Nee, das Problem ist ja, wie xvba die (Subpicture-, das Overlay) Koordinaten behandelt. Wenn das Video kleiner als die Ausgabe ist (i.d.R. bei 4:3 auf 16:9) soll ja nur ein Teil des OSD auf dem Surface - welches ja leider so gross wie das Video sein muss - ausgegeben werden, der linke und rechte, fehlende Teil dann auf einem zusätzlichen Surface.
    Hier scheints Probleme zu machen, wenn die Subpicture-Quellkoordinaten nicht an den Bildgrenzen liegen :(

    Zitat

    Original von Copperhead
    Auf die Gefahr hin das ich falsch liege... Ich sag es aber trotzdem mal.


    Nee, ist schon so und in die Quellen hab ich auch reingesehen, aber nicht wegen OSD.
    Da das zwar hier rumliegt, ich das aber noch nicht übersetzt hab (die Version von vor ein paar Wochen hatte ich mal probiert, aber da ging so gut wie garnichts, Bedienung extrem zäh usw., und ich vermute das wird jetzt auch extrem Zeit kosten), weiss ich auch nicht wie das umgesetzt ist.
    Kann da wer mal was zu sagen, hat das (mit VAAPI) ein von der Video-Grösse unabhängiges OSD?

    By the way: XvBA geht nur mit Radeons der HD4xxx, HD3xxx und einigen (nicht allen) HD2xxx Karten. Deine Radeon 1550 wird also kein XvBA unterstützen. Die Radeon HD5xxx funktionieren ebenfalls nicht mit dem Opensource libVA Interface.


    Grüz
    Hibbel

    - HTPC mit zerbasteltem Yavdr 0.6 , Origen ae X15e, MCE Remote, Asus P5N7A-VM, 1x Digibit R1, Kodi und vdr an Pana 46PZ85E
    - Diverse HTPCs im Umfeld bei Familie und Freundenm die sich vor mir fürchten, mit allen möglichen gruseligen Konfigurationen.
    Auch gern Debian, aber wehe jemand kommt mir mit Suse.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden