Posts by ebsi

    Nicht ganz korrekt. Der master Tree weist diese API Änderung nicht nicht auf.

    Leider wird sich xine nicht so leicht auf den Raspberry PI portieren lassen.



    Mal grundsätzliches. Am PI wird OpenMAX für die Video/Audio decodireung/ausgabe verwendet und GLES fürs Rendering.


    In OpenMAX wird eine Kette mit OpenMAX Komponenten für die Bearbeitung der Daten aufgebaut. Dies kann eine reine Decodierung von Audio/Video sein, oder eine komplette Kette bis zur Ausgabe bilden. Für die Synchronisierung von Audio/Video verwendet OpenMAX eine eigene Clock welche unter den Komponenten geshared ist.


    Prinzipiell könnte man nur das reine Decodieren am PI verwenden, die Daten aus dem Decoder holen und dann mit GLES rendern. Leider geht das aus Performance gründen nicht. Somit lässt man OpenMAX alles erledigen.


    Zum Rendering stehen mehrere Planes zur Verfügung. Wenn man OpenMAX bis zur Ausgabe verwendet, kommen zwei Planes ins spiel :


    Plane 1.) Videoausgabe durch die OpenMAX Komponente.
    Plane 2.) GLES rendering des OSD.


    In xine lässt sich das ganze nun nicht so einfach implementieren. Der Teil zum rendern des OSD ist noch der simple Teil. Die Integration der OpenMAX Komponenten wird schon etwas schwieriger. Die gemeinsam benutze Clock in OpenMAX wird zum eigentlichen Problem. in xine ist es nicht so einfach Daten zwischen dem Video und Audio Decoder zu teilen. Das musste ich schon leidvoll bei der VAAPI implementierung für xine feststellen.


    Warum ich nun das ganze weiß ist ganz einfach. Zum einen habe ich schon Erfahrungen mit xine gesammelt ( VAAPI ), zum anderen habe ich den XBMC Port auf den PI ( plus omxplayer ) gemacht.


    Der wirklich gangbare weg für den PI ist eine eigenständiges VDR Frontend. Das softhddevice ist ein interessanter Ansatz dem leider eine Trennung in Client/Server fehlt. Was es schon von vorne herein für einen stabilen VDR betrieb disqualifiziert ( meine Persönliche Meinung ).


    lg


    ebsi

    Im libva git git es einen neuen staging tree. In va/va_vpp.h steht beschrieben wie die neuen Processing API zu benutzen ist.


    Wie ich das verstehe, sollte das auch auf Surfaces nach dem Decoding funktionieren. Was uns gute Chancen einräumen würde die neuen Deinterlacer zu benutzen.


    johns : was meinst du dazu ?


    wie man wohl hier sehen kann.


    Aber - wie gesagt - auch auf sandy bridge ist xine trotz funktionerendem Deinterlacer für mich kaum zu gebrauchen. Bei beim Kanalwechsel gibt es einen Deadlock (vermutllich im Treiber) und es hängt bis zum nächsten UI Event. Für Ivy Bridge würde ich erst mal nicht mehr erwarten. Die Architektur ist da ja die gleiche.
    VG Kurt

    verwendest du vdr-xine oder xinelibouput ? Noch ein heisser tip, libxcb 1.8 verwenden. Version 1.7 hatte probleme mit deadlocks.


    lg


    ebsi

    Kann schon sein das xine-lib auch davon betroffen ist. Kannst Du einen testclip erstellen und verfügbar machen ? Würd das gerne mit dem xine mpeg2 parser mal checken.

    Hast Du den patch an ffmpeg / libva gemeldet ? Gwenole ist glaub ich der richtige den man ansprechen sollte.


    lg


    ebsi

    Da haben die ffmpeg Entwickler aufgeräumt. Das war schon länger als deprecated markiert.

    video.processing.vaapi_mpeg_softdec:0
    video.processing.vaapi_mpeg_softdec_deinterlace:0

    Ich hatte mit mpeg1/2 Hardware Decoding das Problem das sich die Maschine komplett aufgehängt hat. Kann nicht sagen ob das nun in den VA-API treibern beseitigt wurde. Und auf den Clarkdale CPU's gab/gibt es auch kein Hardware deinterlacing für mpeg1/2. Das konnte nur der SandyBridge VA-API support.


    Der erste Wert deaktiviert VA-API für mpeg1/2. Sollte er auf 1 sein wird Software Decoding für mpeg1/2 verwendet. Der zweite Wert baut auf dem ersten auf. Wenn Software mpeg1/2 verwendet wird kann zusätzlich ein einfacher Deinterlacer im ffmpeg aktiviert werden.



    lg


    ebsi

    Zwei wichtige Grundeinstellungen für xine :

    Quote

    engine.decoder_priorities.ffmpegvideo:1

    Muss gesetzt sein sonst verwendet xine den libmpeg2 decoder für mpeg1/2. Das funktioniert nicht mit VA-API.



    Quote

    video.processing.ffmpeg_enable_vaapi:0

    Dies deaktiviert das Hardware Video decoding.


    Quote

    video.processing.ffmpeg_enable_vaapi:1

    Dies aktiviert das Hardware Video decoding. Ist eigentlich der default Wert.




    lg


    ebsi