Posts by wbreu


    Hi,


    wobei das natürlich extrem doof ist, da das Compositting in Verbindung mit dem nvidia nach wie vor weitere Probleme mit sich bringt.


    Ist schon komisch, dass die beiden Plugins da so unterschiedliche Wege gehen.


    Mal sehen, was sich noch tut.


    Gruß
    Wolfgang

    Hi nochmal,


    die 4 Patches von hier:


    http://sourceforge.net/mailarchive/forum.php?thread_name=4D7FEC80.2050509%40gmx.de&forum_name=xine-devel


    Den Fünften hat Reinhard ja vorerst zurückgenommen.


    und


    du kannst doch einen tarball/snapshot (Button=snapshot) holen,


    http://projects.vdr-developer.…ds/df-xine-lib-extensions


    den ziehst du auf deinen Rechner, entpacken, patchen, compilieren, alles ok!


    Gruß
    Wolfgang

    Quote

    Original von iNOB
    Soweit ich das noch überblicken kann, sind die von mir hier genannten Versionen die zur Zeit aktuellsten für die Ausgabe über das vdr-xine-Plugin/xineliboutput-Plugin. Die aktuellste Version des xineliboutput-Plugin gibt es hier. Aber wie gesagt, der xine-lib-1.2 fehlt scheints noch ein Patch, damit das vdr-xine-0.9.4 Plugin unter vdr-1.7.16 compiliert.


    Gruß
    iNOB


    Moin,


    soweit ich das sehe fehlt dem Master der df-xine-lib-extensions-Patch.


    Wenn du das xine-plugin-0.9.4 mit dem vdpauextension-Patch versehen hast, läuft das compilieren gegen die Wand.


    Wenn niemand einen aktuellen df-xine-lib-extension-Patch für die aktuelle xine-lib-1.2 aus dem Master baut, hilft das nix.


    Insoweit ist das auch nicht schlimm, denn man kann den Branch hier:


    http://projects.vdr-developer.…ds/df-xine-lib-extensions


    nehmen und die anderen 4 Patches von Reinhard da rein nehmen.


    Dann geht auch das vdr-xine-0.9.4 Plugin mit vdpauextension-Patch-13.2 durch.


    Mit der Kombi geht auch das xineliboutput von gestern abend.


    Gruß
    Wolfgang

    Quote

    Original von micclass
    Danke!


    Leider wird dort auch nur auf die Ironlake Grafik verwiesen. Niemand redet von Sandybridge!


    Nabend,


    wenn du mir so eine CPU samt Board zukommen lässt, nehme ich die sandy's mit auf.


    Also mal Spaß beiseite, seit einiger Zeit nehmen wir das xine-Plugin zum Testen.
    Mit dem vdr-sxfe schau ich mal ob das im Moment überhaupt geht.


    @Opp, die Intel-CPU hat keine Nvidia, die hat die Intel-GPU in der CPU mit drinnen!


    Gruß
    Wolfgang

    Nabend,


    heute habe ich mal die ganzen neuen Sachen der letzten 4 Wochen was vdpau und vaapi betrifft auf meiner Homepage aktualisiert.


    Viel Spaß beim Stöbern...


    Gruß
    Wolfgang

    Nabend,


    nach etwas längerer Pause, mal wieder VDR...


    Super freut mich, dass es soweit voran geht.


    ebsi ,


    danke dir dafür, dass du so fleissig bist, soweit sieht das ja schon sehr gut aus mit der neuen Variante inkl. vaapi und dem vdr-xine-plugin.


    Ich habe mir erlaubt mal meine Homepage auf den aktuellen Stand zu bringen und deine Tips von hier zusammenzufassen.


    Flachzange , nimm mal eine aktuelle xine-ui.


    Gruß
    Wolfgang


    Servus nochmal,


    also soweit ich den Code verstehe, versucht ebsi die vaapi in der xinelib über den internen ffmpeg-Part der xinelib einzubauen.


    Das sollte doch nahe an dem sein, was mit dem Plugin beabsichtigt wird. Den Ausgabepart könnte man auch aus der xinelib nutzen und eventuell extrahiren, den an dem baut er auch kräftig rum.


    Das schöne daran ist, du kannst dir den Code ja mal anschauen:


    http://crystalhd.svn.sourcefor…nches/xine-lib-1.2-vaapi/


    Ich finde das insoweit gut, dass der Code dazu komplett offen ist, was ja bei den anderen Versuchen bisher nicht der Fall war.


    Über die vaapi wäre auch vdpau nutzbar, hätte natürlich insoweit schon den Reiz ein Softwareausgabeplugin für beide Methoden zu nutzen und zu entwickeln.


    PS: JA LEG LOS! DAS WÄRE EIN MEILENSTEIN!!!


    Gruß
    Wolfgang

    Nabend,


    aus dem Gedächtnis, im Compiz das opengl-, composite- und Zusatzeinstellungen-Plugin aktiviert.


    Es sind nur zwei Einstellungen im letzten Plugin abweichend den Standardeinstellungen nach der Aktivierung geändert worden.


    Wie die genaue Bezeichnung ist, kann ich im Moment nicht sagen, da ich keinen Zugriff auf den VDR habe.


    Den Windows-Decorator habe ich gar nicht aktiviert.


    Gruß
    Wolfgang


    Hi,


    der User ebsi hat damit angefangen und aktuell wieder fortgeführt, die vaapi mit dem VDR nutzbar zu machen.


    Eventuell kannst du dich ja mit ihm zusammentun und ihr macht das gemeinsam.


    Gruß
    Wolfgang

    Moin,


    als fleissiger "Betatester" des DVB-Viewers mal ein/zwei Anmerkungen.


    Aufnahmen aus dem komplett ausgeschalteten Zustand gehen gar nicht. Auch nicht per ACPi oder NVram. Das kann Windws nicht.
    Es gibt ein Skript für den DVB-Viewer, der den Rechner in den Supend schickt, also -Ram oder -Disk, allerdings ist das auch hier sehr Hardwareabhängig/Treiberabhängig. Bei mr hat das noch nie geklappt.


    Ansonsten regt auch nicht auf, einer weniger, der halt nicht mit Linux zurechtkommt.


    Gruß
    Wolfgang

    Quote

    Original von iNOB
    Ich hab das ganze Zeuch aus dem git runderneuert und gegen die r86 gebaut. Ich meine das ging schon besser :schiel


    Oder liegt das daran, dass ich vaapi gegen die aktuelle Gitversion von "xine-lib-1.2-vdpau-extensions-patch-xine-lib-patch" baue?


    Gruß
    iNOB


    Nabend,


    schau dir mal bitte das Changelog an, ich denke Edgar, hat da jede Menge geändert, um den vaapi-Code besser in die xine-lib zu bekommen.


    Dauert halt ein wenig bis die neuen Methoden ausgelotet sind.


    PS: Das liegt nicht an der verwendeten xine-lib, ich baue zum antesten immer beide Varianten, also original und auch die df-branch mit passendem Patch.


    Gruß
    Wolfgang

    Quote

    Original von iNOB
    Auch von mir ein Dankeschön! Grundsätzliche Frage noch, bei mir läuft noch der 2.6.35.10 Kernel. Macht das einen großen Unterschied zum empfohlenen 2.6.37er? Bezüglich der Intelgeschichte mein ich, letztendlich gehts ja nur um den AGP-Treiber soweit ich das verstanden hab...


    Gruß
    iNOB


    Nabend iNOB,


    also bei mir läuft parallel noch ein 2.6.38er-RC2 aus dem Kernel-git von Intel.


    Mit dem Kernel kann ich keine gravierenden Abweichungen zum grundsätzlichen Systemverhalten feststellen. Auch die Logs geben keine Abweichungen her.
    KMS funzt da genauso wie mit dem 2.6.35.10er. Allerdings ist es eine Tortur den Kernel mit allem was man braucht zu versorgen (Lirc, DVB-Treiber, Einstellungen in der .config).


    Mir wäre auch nicht bekannt, was da für die Videoausgabe/Xserver dazu kommen sollte. Die Musik speilt im Intel-Xorg-Treiber und in der libdrm und vorallem in der libva in Verbindung mit xine.


    ebsi , die 82er läuft auf SD schon brauchbar, aber da fehlt noch der Feinschliff am OSD, bei HD hakt es aber noch sehr, da kommen jede Menge Framedrops.
    Wenn du Hilfe, Logs, Tests oder sonstiges brauchst, schreib ruhig.


    Gruß
    Wolfgang

    Quote

    Original von ebsi
    Kleine Info am Rande. Im moment arbeite ich daran VAAPI auch zur Videoausgabe zu verwenden. XV auf dem i3 doch etwas Ineffizient was die CPU last angeht. Hab hier nun experimentellen Code laufen, der das XV Ausgabe plugin missbraucht. Also theoretisch ist eine VAAPI Ausgabe auch unter Xine möglich. Die CPU last sinkt damit nochmals erheblich :D


    lg


    ebsi


    Mahlzeit ebsi,


    sieht ja gut aus, was du da in das repo zauberst, werde glich mal testen.


    Und nicht vergessen, DANKE!


    Gruß
    Wolfgang

    Quote

    Original von ebsi
    Kleine Info am Rande. Im moment arbeite ich daran VAAPI auch zur Videoausgabe zu verwenden. XV auf dem i3 doch etwas Ineffizient was die CPU last angeht. Hab hier nun experimentellen Code laufen, der das XV Ausgabe plugin missbraucht. Also theoretisch ist eine VAAPI Ausgabe auch unter Xine möglich. Die CPU last sinkt damit nochmals erheblich :D


    lg


    ebsi


    Hi ebsi,


    dann mach mal bitte den Push...


    Denn ich bekomme die hier


    Code
    1. ffmpeg_video_dec: error decompressing frame
    2. ffmpeg_video_dec: error decompressing frame
    3. ffmpeg_video_dec: error decompressing frame
    4. ffmpeg_video_dec: error decompressing frame
    5. ffmpeg_video_dec: error decompressing frame
    6. ffmpeg_video_dec: error decompressing frame


    nicht weg, und somit macht das keinen Spaß, da lief die 32er besser.


    Das ist ganz normaler decode von SAT in s2, also z.b bei ZDF HD.


    PS: Kann eh nicht schlafen, zuviel aua..


    Gruß
    Wolfgang


    Mahlzeit,


    wenn es dafür von Ati xorg-Treiberunterstützung gibt, sollte das gehen.


    Ob die passenden Treiber für Linux schon da sind, keine Ahnung?


    Gruß
    Wolfgang

    Mahlzeit,


    vorneweg, danke für die neue Version.


    Bei mir rennt jetzt die Version 77 mit aktueller xine-lib-1.2 mit den vdpauextension+aktuellen Patches dafür.
    Ne aktuelle Version kann ich aber erst heute Abend auf die Homepage stellen.


    Das vdr-xine-plugin gibt jetzt wieder ein Bild auf allen HD-Kanälen aus.


    Wobei ich jetzt mal mein Grundsetup geändert habe, => compiz ist komplett aus, und auch Composite ist auf "disabled" in der xorg.conf. Hintergrund ist, so kann man die ganzen Seiteneffekte die da mitkommen ausschliessen. Als Windower nutze ich fluxbox.


    Ergebnis:


    - Bei SD und HD - 720p kein Nachziehen mehr bei schnellen Kameraschwenks ist Ruhe, 1080i-Sender ruckelt grundsätzlich.

    Zwischendurch gibts leider immer Framedrops, das Log sagt das dazu:




    Die Fehlermeldungn im Log gibts auch mit vdr-sxfe, da Ruckelts dann ebenfalls kurz, ist aber klar, da ja Frames verworfen werden.



    Auschecken aus dem git klappt so, damit das mal sauber sichtbar ist:


    Code
    1. svn co https://crystalhd.svn.sourceforge.net/svnroot/crystalhd/branches/xine-lib-1.2-vaapi



    Diffen für Einzelpatch der vaapi-Geschichte, hier Version 77:


    Code
    1. svn diff -r20:77 > ffmpeg_vaapi_v77.diff



    Gruß
    Wolfgang




    Nabend ebsi,


    das wäre mir schon klar, aber das svn kann man seit einiger Zeit nicht holen:



    Code
    1. notebook:~# svn co http://crystalhd.svn.sourceforge.net/viewvc/crystalhd/branches/xine-lib-1.2-vaapi/
    2. svn: Repository moved temporarily to '/viewvc/crystalhd/branches/xine-lib-1.2-vaapi/'; please relocate


    und dann ist Ende.


    Keine Ahnung was da fehlt?


    Somit geht auch kein diff, und damit ist es auch nicht so einfach Neuerungen in die df-xine-lib-1.2 zu transportieren. Wäre toll, wenn du da mal schauen könntest, warum der "svn co" da ins Leere läuft.


    Aber ich habe die version 73 hier liegen, damit kommt mit dem vdr-xine-plugin kein Bild bei allen HD-Sendern (720P und 1080I), mit vdr-sxfe klappt es.


    Edit:


    Ok, habs gefunden:


    svn co http://crystalhd.svn.sourcefor…nches/xine-lib-1.2-vaapi/


    damit gehts.


    Gruß
    Wolfgang