Beiträge von Flachzange

    @Atech
    Okay. Geht nicht. Habe jetzt mal einfach ein I420 surface übergeben und damit geht Deinterlacing definitiv nicht, also genauso wie bei dir. Jetzt stimmen zwar die Farben, aber das hilft ja nicht. Der Clarkdale kann es wohl einfach nicht :)


    Edit: Wenn ich mir das so anschaue, glaube ich fast, dass vaapi-ext nur für Sandy und Ivy gedacht ist. Mich wundert jedoch, warum es bei dir funktioniert. Wenn du Lust hast, kannst du meinen Fehler ja mal auf der Mailingliste posten.

    So Leute, ich gebe ja nicht auf....ihr kennt ja mein Problem:


    Code
    xine: i965_drv_video.c:2072: i965_check_alloc_surface_bo: Zusicherung obj_surface->fourcc == fourcc nicht erfüllt.


    Ich habe gerade mal rumgspielt und geschaut, was so in fourcc und obj_surface->fourcc steht:

    Code
    obj_surface->fourcc = 842094158 = NV12
    fourcc == 808596553 = I420


    Deswegen failed die assertion und ich habe meine exception. Da ich ja von diesem ganzen Grafik- und Videozeugs keine Ahnung habe, dachte ich mir, ich setze einfach NV12 falls I420 drin steht und schaue was passiert. Und siehe da, ich kriege eine Bild mit VAAPI und funktionierendem Deinterlacing! Klar, der Farbraum passt nicht und das Bild ist farblich nicht sehr sehenswert, aber es geht mal prinzipiell.


    Ich bin mir ziemlich sicher, dass Deinterlacing auf meinem Clarkdale so läuft. Meine Settings:


    Code
    video.driver:vaapi
    video.output.vaapi_deinterlace:2
    video.processing.ffmpeg_enable_vaapi:1
    video.processing.vaapi_mpeg_softdec:0
    video.processing.vaapi_mpeg_softdec_deinterlace:0
    engine.decoder_priorities.ffmpegvideo:1


    - CPU-Auslastung bei MEPG2 SD: 10%
    - Keine Ruckler mehr beim Starten
    - Bei manchen Kanälen Hänger beim Umschalten
    - Laufschrift bei N24 sehr sauber
    - Zur sonstigen Bildqualität kann ich keine Aussage machen :)


    Das einzige was mir jetzt noch jemand sagen kann ist, dass es nur funktioniert, weil der Farbraum falsch ist. Die Frage ist jetzt nur, warum passen die fourcc codes der Farbräume nicht? Ich würde ja gerne selbst suchen, aber da fehlt mir einfach das Hintergrundwissen. Liefert der xf68 Intel Treiber hier falsche Werte, weil ich einen Clarkdale habe?


    Edit: Habe gerade gesehen, dass i965_check_alloc_surface_bo immer mit fourcc=NV12 aufgerufen wird. Im normalen Treiber aus dem master branch holt er sich fourcc über image.fourcc, was auch irgendwie sinnvoller aussieht. Ich werde das heute Abend mal testen, mein Router hat mich leider gerade ausgesperrt :)

    ebsi


    ich wollte gerade deine xine-lib gegen ein aktuelles ffmpeg(git von heute) bauen und bekomme einen unerwarteten Fehler:



    Hast du eine Idee, was da los ist?

    Welche xf86-video-intel verwendest Du ? Auf den Clarkdale CPU's habe ich die besten Ergebnisse mit dem xf86-video-intel-2.15.0 gemacht. Wenn ich es Deiner Signatur richtig entnehme verwendest Du solch eine CPU.


    Ich bin auf dem git Treiber, habe gerade aber eben auch nochmal mit 2.15 getestet. Gleiches Problem.


    Ich vermute hier vielmehr ein Problem zwischen dem vaapi treiber und der xine-lib-vaapi. Wie gesagt der Fehler tritt nur beim vaapi-ext branch auf. Mit dem master läuft alles. Ich hab gerade mal die Dateien i965_drv_video.c der beiden branches grob überflogen. Die unterscheiden sich schon ziemlich.


    Das sollte natürlich keine Aufforderung sein, dass du deine xine-lib-vaapi an einen branch anpasst (falls es tatsächlich daran liegen sollte), aber vielleicht ist das Problem ja mit einem simplen Fix behoben.

    ebsi


    Danke für deine Rückmeldung.


    Ich habe heute morgen ebenfalls mal die CPU-Auslastung überprüft und festgestellt, dass diese viel zu hoch war. Ist ja auch klar, wenn du sagst, dass


    Code
    engine.decoder_priorities.ffmpegvideo:1



    gesetzt sein muss.


    Also muss ich meine Erfolgsmeldungen bzgl Deinterlacing direk mal revidieren, da diese dann wohl doch nicht hardwareseitig liefen.


    Mit gesetzter ffmpegvideo Priorität kriege ich folgenden Fehler:


    Code
    xine: i965_drv_video.c:2072: i965_check_alloc_surface_bo: Zusicherung obj_surface->fourcc == fourcc nicht erfüllt.


    Hast du vielleicht eine Idee, was das sein könnte?


    Danke und Gruß
    Christoph

    video.output.vaapi_guarded_render:0
    video.processing.ffmpeg_enable_vaapi:0


    Letzteres hat mich doch jetzt etwas stutzig gemacht. Ich dachte eigentlich, dass das eine notwendige Option ist. Bei einem kurzen Test gerade eben konnte ich aber auch keinen Unterschied feststellen, ob aktiviert oder deaktiviert.


    Hat das einen bestimmten Grund, warum du guarded render 0 hast?

    Mit Sandy Bridge und 3.2.x Kernel habe ich Ihn mit "i915.i915_enable_rc6=0" und SNA im X11-Treiber disabled und xine-lib und vdr-xineliboutput nicht mehr gesehen.


    Danke für den impliziten Tipp :) Ich hatte letzte Woche mal testweise i915.i915_enable_rc6=1 gesetzt. Vorhin wieder rausgenommen und jetzt kann ich tatsächlich die MPEG2 interlaced files spielen, die vorher noch mit einem GPU Hung endeten. Bei H.264 habe ich immernoch einen GPU Hung.


    Laut gpu top ist meine Karte aber ziemlich am Limit. Die 1080i Testvideos lasten die GPU über 90% aus.


    Atechsystem
    Das ist wirklich seltsam und ich wüsste jetzt auch nicht. was sein könnte.

    Atechsystem


    Es funktioniert definitiv mit der xine-lib-vaapi. In der config vaapi deinterlacing auf Bob und mpeg soft decoding off. Ich habe es noch mal sicherheitshalber verifiziert indem ich intel_gpu_top nebenher laufen hatte. Die N24 Schrift läuft sauber durch. Im xbmc habe ich typische interlaced Artefakte, aber man kann es noch lesen und es wirkt auch nicht so, als wenn da überhaupt kein Deinterlacing läuft. Wie gesagt, ich konnte Fußball (WDR Sonntag 21:45) gut gucken. Einen Preis für Schönheit gabs aber nicht. Die Testfiles zeigen den gleichen Effekt, wobei das software deinterlacing im xbmc nur die Laufschrift schöner macht.


    Das Deinterlacing mit vaapi (xine-lib) ist auch qualitativ deutlich besser als das deinterlacing mit soft decoding. Wie glaube ich Johns schon schrieb, die Schriften sind viel schärfer gezeichnet.


    Die Testfiles und auch ein anderes interlaced H.264 Testfile von mir führen unmittelbar und reproduzierbar zu einem GPU Hung (xine-lib-vaapi mit aktiviertem deinterlacing).


    Einziger Wermutstropfen: Meine interlaced Sender ruckeln jetzt am Anfang 10 Sekunden lang, danach gehts sauber weiter. Schuld daran scheint die von mir oben deaktivierte Option engine.decoder_priorities.ffmpegvideo zu sein, denn die Ruckler habe ich jetzt auch mit softdecoding. Schalte ich die Option wieder aktiv sind die Ruckler weg aber bei aktiviertem vaapi deinterlacing fliegt mir die xine lib bzw der vaapi treiber um die Ohren (siehe oben).


    Gruß
    Christoph

    So kurzes Update zu Deinterlacing mit vaapi-ext:


    Bei Auswahl eines interlaced SD Senders ruckelt das Bild für ca. 10 Sekunden stark. Anschließend funktioniert das Deinterlacing und das Bild sieht wirklich ordentlich aus, auch wenn es oben unten noch etwas am Rand flimmert. Mit dem Bild als Vergleich musste ich dann auch feststellen, dass deinterlacing bei xbmc nicht richtig funktioniert. Interessanterweise ist das Bild aber nicht "unschaubar".

    Moin,


    ich habe eine Universalfernbedienung von Philips. Für die habe ich in der lircd.conf zwei "virtuelle" FBs angelegt. Mit der einen möchte ich xbmc steuern und mit der anderen den vdr über xine. Beide Fbs funktionieren. In der remote.conf vom vdr kann ich aber nur sagen LIRC.Taste und ich kann nicht genau spezifizieren, welche Fernbedienung er nehmen soll. Der vdr reagiert also derzeit auf beide FBs.


    Wie kann ich dem vdr sagen, dass er nur auf remote xy hören soll?


    Danke schon mal!


    Christoph

    Code
    xine: i965_drv_video.c:2072: i965_check_alloc_surface_bo: Zusicherung obj_surface->fourcc == fourcc nicht erfüllt.


    Ich bin dann sicherheitshalber noch mal auf den master von libva/intel-driver. Damit läufts (deinterlacing hat mich da jetzt aber nicht interessiert). Wieder zurück auf vaapi-ext und wieder kaputt


    Problem gelöst:


    In der config folgenden Parameter zurückgesetzt auf 0:


    Code
    # Priorität für Dekoder ffmpegvideo
    # numeric, default: 0
    engine.decoder_priorities.ffmpegvideo:1


    Ergebnis zu test mit xine-lib, vaapi-ext und deinterlacing heute Abend :)

    Moin,


    seit 2 Jahren läuft bei mir ein Alphacrypt CAM mit einer Unitymedia Smartcard. Bis vor zwei Wochen mit einer KNC One DVB-C Karte. Es passierte recht häufig, dass ich beim Umschalten auf einen verschlüsselten Sender (z.B. RTL) die Ausgabe "Kanal nicht verfügbar" bekam. Dies passierte dann für alle Sender in dieser Sendergruppe. Schalte ich dann aber auf einen anderen Sender in einer anderen Gruppe (z.B. Pro7) decrypted das Modul sauber. Schalte ich zurück auf RTL dann funktioniert auch RTL. Die Sender sind hier nur Beispiele, das kann genauso gut auch andersherum sein. Ich habe das Problem auf einen Inkompatibilität zwischen KNC One und dem Alphacrypt geschoben.


    Seit 2 Wochen habe ich eine DD Cine CT(v6) samt CI verbaut und es treten genau die gleichen Probleme auf. Es wird also wohl am Alphacrypt liegen. Ist das ein bekanntest Problem? Kann man dem mit Konfiguration abhelfen?



    Danke!
    Flachzange

    Zitat

    Also das Bob oder Weave Deinterlacing mit der aktuelleren (> 10.01.2012) XBMC-git (ist der pvr branch auch so aktuell?) Version bei der man den Deinterlacer bei vaapi explizit auswählen kann.

    Ich kann ihn aktuell nicht auswählen, steht auf AUTO. Vielleicht liegt das am pvr-branch (opdenkamp).

    Zitat

    Bist du auch nach der Anleitung im xbmc Forum zum Thema Intel HTPC vorgegangen?. Man muss ja die vaapi "patchen" damit der vaapi-intel Treiber die Version 1.0.17-pre erhält.

    Ja das "patchen" hebt doch nur die Version an, damit man es anschließend sehen kann. Funktional hat das doch keine Auswirkung, zumal der Patch aktuell fehlschlägt, weil er von .15 anheben will, aber der Treiber bereits bei .16 ist.



    @all
    Kann man mir jemand etwas zu meinem oben genannten Problem mit der xine-lib-vaapi und vaapi-ext sagen?

    Zugegeben: Ich habe vaapi-ext und deinterlacing bisher nur mit XBMC und xvdr plugin laufen. Das tuts. Jetzt wollte ich gerade mit xine-lib testen. Das war keine gute Idee. Sobald ich mpeg2softdec deaktiviere (habe nur mpeg2 interlaced sender) fliegt mir die xine-lib um die Ohren:



    Code
    xine: i965_drv_video.c:2072: i965_check_alloc_surface_bo: Zusicherung obj_surface->fourcc == fourcc nicht erfüllt.


    Ich bin dann sicherheitshalber noch mal auf den master von libva/intel-driver. Damit läufts (deinterlacing hat mich da jetzt aber nicht interessiert). Wieder zurück auf vaapi-ext und wieder kaputt.



    Ich kann da also gerade nicht so viel zu sagen. softhddevice habe ich übrigens noch nicht getestet. Bin klassisch mit xine plugin unterwegs.


    Baut bei euch eigentlich die libva vaapi-ext sauber durch? Bei mir scheint irgendetwas am Makefile nicht zu stimmen:


    Code
    Making all in transcode
    make[3]: Betrete Verzeichnis '/usr/local/src/intel/libva/test/transcode'
    make[3]: *** Keine Regel, um »all« zu erstellen.  Schluss.
    make[3]: Verlasse Verzeichnis '/usr/local/src/intel/libva/test/transcode'
    make[2]: *** [all-recursive] Fehler 1