Beiträge von ebsi

    Guckst Du mal git update ;) Habe deine Idee übernommen, jedoch anders.


    lg


    ebsi

    BTW:
    Ich habe wieder ein Bild, wackelig und mit blauen Gesichtern.
    Es ist schwierig, mit einem Forumsthread und diversen Webpages mit den Updates mitzuhalten.


    Wäre es vielleicht möglich, die Versionen, Patches, GIT/SVN/CVS-Quellen der benötigten Libraries an einer zentralen Position zeitnah zu dokumentieren?
    Das kann ja ruhig kompakt sein...
    Ich habe damals angefangen mit http://wbreu.htpc-forum.de/vdr…reanforderungen/index.php - ist aber wohl nicht mehr so recht aktuell?

    Update auf das letzte vaapi-testing git. Sollten dort noch immer "Blaue Köpfe" sein setz mal "video.output.vaapi_swap_uv_planes:1" und "video.output.vaapi_guarded_render:1" im xine config.


    lg


    ebsi

    Damit klappt es natürlich. Dein Commit sah aber nicht falsch aus. Das Problem war in vaapi_init hat der zweite vaapi_ovl_associate das OSD nicht wiedergestellt, weil va_context->va_subpic_id nicht gültig war.

    Genau das ist mir auch aufgefallen. Darum der rück stieg zur alten Logik, wo das Subpicture und Image in vaapi_ovl_associate neu erzeugt wird.
    Hoffe das nun die gröbsten Bugs raus sind. Bin gespannt wie das Aufnahme Prozedere für xine-lib-1.2 wird.



    lg


    ebsi

    @johns:


    Probier mal das aktuelle vaapi-testing git. Das Problem war swscale und deren defekte YV12 -> NV12 Konverter.
    Hab nun meine eigenen NV12 Konverter gebaut. Sind zwar nur plain C aber schnell genug für unsere zwecke.


    Ich verwende auch noch folgenden patch :


    http://lists.freedesktop.org/a…011-September/000605.html



    oder angepasst für libva git mit integriertem Intel Treiber.
    https://archvdr.svn.sourceforg…Image_data_size_fix.patch


    lg


    ebsi

    Noch eine kleinigkeit, sollten hänger auftreten kann das durchaus an der libxcb liegen.
    Bei archlinux ist im moment libxcb 1.7 aktuell. Die braucht einen patch :


    https://archvdr.svn.sourceforg…/xcb_wait_for_reply.patch


    Dieser Patch ist basiert auf dem libxcb git commit 5ceeaaa4294201b3f613c07f9ec610c0e5f673c7.

    Wenn man video.output.vaapi_guarded_render:1 treten die Hänger ohne dem Patch auf. Die Hänger wurden
    vermehrt mit xineliboutput beobachtet.
    Der sogenannte guarded mode is für VAAPI stabiler. Wollte zwar von dem wegkommen, wird wohl wieder
    zum Standard werden. Das Problem sind zum teil nicht multithreading fähige VAAPI Treiber ( vdpau-video ).

    Bitte testet vaapi-testing, werde bald den Branch nach vaapi mergen. Sollten keine grossen Probleme mit
    video.output.vaapi_guarded_render:1 ( muss händisch aktiviert werden ) auftreten, möchte ich einen Patch
    präparieren und an die xine-ml schicken.

    lg


    ebsi

    Die Blockartefakte treten in Zusammenhang mit ffmpeg auf. Das ist der Grund warum ich die alte ffmpeg verwende. Ich sehe den Fehler einfach nicht. Kann auch sein das es ein bug in ffmpeg ist. Es betrifft nur interlaced h264 Material. Bei Progressiv Material konnte ich das verhalten noch nicht beobachten.


    lg

    Ich bin immer noch abgehängt. Die letzte funktionierende Version war 288 aus dem alten Repo, wenn ich zurückgehe, geht es auch wieder. Neues libva habe ich inzwischen auch installiert.
    Ich bekomme den Splashscreen, aber kein Bild, anschließend läuft xine-ui ruhig mit 3% CPU vor sich hin.
    Helfen die logs? Was wäre noch zu ersetzen?


    Der log schaut mir nicht nach dem letzten git stand aus.


    git clone https://github.com/huceke/xine-lib-vaapi.git
    cd xine-lib-vaapi
    git checkout vaapi


    lg


    ebsi

    Kannst du mal den testing branch ( vaapi-testing ) testen ?


    lg


    ebsi

    Was für ein Umschalt Bug ?


    Edit :


    Hab mal was zum Frühstück commited. Vielleicht war es das was du meintest.


    lg