Posts by Space

    But it seems that I have problems with it ... I zapped some time and it worked fine but now the system does not respond any more ... need to dig a little bit deeper into this on the weekend. Back to work now :)


    The problem only seems to show up if I run intel_gpu_top ... seems to be a known issue because the access to the performance registers is not synchronized. System is running stable now for several hours without a hang (without starting intel_gpu_top) ... But the big screen in the living room is blocked so I might not be able to test the 50Hz output this weekend ...


    Best regards,


    Space

    If someone else wants to test the branch of Gwenole on top of the master vaapi-intel tree find instructions below how I added those commits to my local git master:


    Code
    1. git clone -b master http://anongit.freedesktop.org/git/vaapi/intel-driver.git
    2. cd intel-driver
    3. git remote add gbeauchesne https://github.com/gbeauchesne/libva-intel-driver.git
    4. git fetch gbeauchesne
    5. git cherry-pick 8294e43e809923eb6f8231a085c76595028cafad
    6. git cherry-pick ec6e26656c580871787343c71b4c6f670911775f
    7. git cherry-pick 19256196e01eb1184425f684eb19e74f71e2d438


    But it seems that I have problems with it ... I zapped some time and it worked fine but now the system does not respond any more ... need to dig a little bit deeper into this on the weekend. Back to work now :)


    Best regards,


    Space


    PS: Johns: no, I can not force the display to 50Hz mode ... it says invalid signal then ... it's a *very* old LCD monitor.

    I do run that branch on my BayTrail, very nice with "va-api-glx", but it doesn't contain Antti's latest fixes to the Intel drivers and therefor I cannot activate Bob with it.


    The commit mentioned by rofa do contain the fixes, but there is no MCDI available for IVB/BayTrail. But difference between MADI and MCDI is subtle like at VDPAU's temporal to temporal_spatial. The scrolling text of N24 (SD) looks better with MADI, from my point of view.


    Hi,


    that's why I am currently running GIT master + cherry pick of the 3 commits from the 19.vpp.adi tree by Gwenole. And apart from the stuttering caused by 60Hz display it seems to look fine. Need to check on the big screen, hopefully this weekend.


    Best regards,


    Space

    Hi Johns,


    regarding the artifacts ... that might be solved with the branch by Gwenole (19.vpp.adi ... see announcement for git location) because that might fix these bugs and even provide MCDI on Ivy Bridge ...


    Currently my new VDR with VA-API is connected to a monitor with 60Hz output only so I can not really test. Maybe this weekend :)


    Thanks a lot to all people involved. This looks really really promising ...


    Best regards,


    Space

    Ich habe vor ganz vielen Jahren (noch mit einem Via EPIA M10000) mal getestet und damals war XFS hierfür besser geeignet als Ext4, da es die Daten a) länger cached (und deswegen mehr Daten in einem Rutsch schreibt) und b) größere Blöcke (pre-)allokiert. Ich konnte damals mit besagtem EPIA auf eine ebenfalls schnarchlangsame IDE Festplatte problemlos 4 SD Streams parallel aufnehmen und auch die Fragmentierung hielt sich in Grenzen, solange die Platte nicht >80% Füllgrad erreicht hat. Seitdem läuft mein video-Verzeichnis auf XFS ...


    Heutzutage sollte das gar kein Problem sein. Und wenn Dich Fragmentierung so dermaßen stört: XFS hat sogar ein Defrag Tool ...


    Gruß,


    Space

    Hallo,


    ich habe zwar noch keine Erfahrungen damit sammeln können, aber evtl. ist ja auch das HifiBerry Upgrade Kit ganz interessant ... kann man wohl mit wesentlich besseren Analog-Out bekommen. Aber ich habe es noch nicht getestet. Nur mal per Zufall gesehen und ganz interessant gefunden :)


    Schöne Grüße,


    Space

    Hello everyone,


    I just want to report status. I am running current GIT master of libva + libva-intel-driver on my Celeron G1610 (Ivy Bridge based) and both VAAPI-BOB and VAAPI-MADI are running "smooth". For VAAPI-MADI I have to set first field to 1 and second field to 0.


    But there are some artifacts with MADI deinterlacing (can be easily seen in N24) but this seems to be driver based (XBMC people noticed the same problems). MCDI is not advertised with GIT master:


    Code
    1. Dec 03 00:40:42 [vdr] video/vaapi: noise reduction supported_
    2. Dec 03 00:40:42 [vdr] video/vaapi: 0,00 - 1,00 ++ 0,03 = 0,50_
    3. Dec 03 00:40:42 [vdr] Enabling denoise filter (pos = 0)_
    4. Dec 03 00:40:42 [vdr] video/vaapi: deinterlacing supported_
    5. Dec 03 00:40:42 [vdr] video/vaapi: bob deinterlace supported_
    6. Dec 03 00:40:42 [vdr] video/vaapi: motion adaptive deinterlace supported_
    7. Dec 03 00:40:42 [vdr] Enabling Deint (pos = 1)_
    8. Dec 03 00:40:42 [vdr] Allocating 1 forward reference surfaces for postprocessing_
    9. Dec 03 00:40:42 [vdr] Allocating 0 backward reference surfaces for postprocessing_


    There is a branch (19.vpp.adi) by Gwenole Beauchesne which is supposed to contain some fixes regarding deinterlacing on Sandy / Ivy Bridge and even enable MCDI on Ivy Bridge.


    But with that driver version I get no deinterlacing at all at MADI/MCDI setting even though it's reported as supported according to VDR log. Next weekend I should be able to provide those logs again.


    So from my side: thanks a lot for your hard work!


    Best regards, Space

    Ich antworte mir mal selber ... ich habe mich von der Anzeige im XBMC (unter Kalibrierung) ins Bockshorn jagen lassen. Dort stand 1920x1080@60Hz ... der Fernseher zeigt in seinem Info-Screen aber 50Hz an. Ich suche mal weiter, warum es ruckelt ...


    Gruß,


    Space

    Hallo Zusammen,


    läuft bei euch denn das FireTV auch bei XBMC/TVMC unter 50Hz? Bei mir läuft das Teil leider unter TVMC mit 60Hz, obwohl ich im FireTV selbst als Auflösung 1080p/50Hz eingestellt habe :(


    Dadurch ruckelt natürlich alles ziemlich heftig in TVMC ...


    Falls jemand einen Tipp hat ...


    Danke und schöne Grüße,


    Space

    model name : Intel(R) Celeron(R) CPU G1610 @ 2.60GHz
    stepping : 9
    microcode : 0x15


    libva/libva-intel-driver GIT master branch (Weiß nicht ob der richtig ist).
    Läuft soweit gut, habe MADI und SDTV/HDTV 2,1 field order.


    Ich kann die Ergebnisse von johns mit meinem Celeron nun auch bestätigen. Läuft recht sauber soweit. Ich bin auf Master von libva / libva-intel-driver und es wird auch sauber deinterlaced.


    Danke und Gruß,


    Space

    Hi fnu,


    sure. I have posted most infos already but I will summarize them in one post:


    Code
    1. media-video/ffmpeg-1.2.6-r1
    2. x11-drivers/xf86-video-intel-2.99.916
    3. x11-libs/libva-9999 -> same error / backtrace with both master / staging from git://anongit.freedesktop.org/vaapi/libva
    4. x11-libs/libva-intel-driver-9999 -> same error / backtrace with both master / staging from git://anongit.freedesktop.org/vaapi/intel-driver


    Also it does not matter if I use va-api or va-api-glx in softhddevice --> same error / backtrace. My CPU is Intel(R) Celeron(R) CPU G1610 on Gigabyte B75N.


    I have uploaded the VDR logs to pastebin ... although the logfiles states


    Code
    1. libva 0.34 (Intel i965 driver for Intel(R) Ivybridge Desktop - 1.0.21.pre1 (staging-20130205-631-g3e8cce4)) initialized_


    the current staging version is used. I verified there is no other libva or libva-intel-driver installed. I guess this comes from the way the package is built via portage from git:


    Code
    1. GIT update -->
    2. repository: git://anongit.freedesktop.org/vaapi/intel-driver
    3. at the commit: 73e87442bb37f780c1ee58d542599163682f1cc8
    4. commit: 3e8cce4e7292651af10c9f375a6ad2e9fa494021
    5. branch: staging


    Thanks and best regards,


    Space


    EDIT: corrected pastebin link.

    Hi!


    I am still getting the same stack trace as in [Announce] VA-API/VPP Patch for vdr-plugin-softhddevice - updated "v9" and it does not matter if I use master or staging tree of libva-intel-driver.


    Is this more likely a driver bug in the libva-intel-driver and I should open a bug at freedesktop.org or is this more likely a bug in softhddevice / VA-API patch?


    Thanks for all the work and best regards,


    Space

    Hallo Leute,


    da ja bei mir das Deinterlacing noch nicht sauber läuft (zumindest bei 576i nicht -- laut logfile läuft es bei 1080i und sieht auch so aus), habe ich mir nochmal die Branches des libva-intel-driver angeschaut und Master scheint die Vebox-Commits nicht zu enthalten. Daher habe ich nun nochmal mit dem aktuellen Staging Tree alles kompiliert und naja, da sind meine Segfaults wieder ... Dafür habe ich jetzt libva / libva-intel-driver und vdr-softhddevice mit Debug-Symbolen gebaut und einen besseren Stacktrace erzeugen können:



    Allerdings ist mir nicht klar, wo jetzt der Fehler sein könnte, ob der blend_state in softhddevice (inkl. des Abort-Patches) nicht sauber gesetzt / übergeben wird ...


    Gruß,


    Space

    Moin Zusammen,


    kurze Zusammenfassung von meiner Seite. Prinzipiell läuft es bei mir nun mit git-Master von libva, libva-intel-driver und softhddevice + Patch von Antti.
    Meine noch bestehenden Probleme sind:


    - die Frame-Orders musste ich auf eine der beiden folgenden Varianten stellen, damit die normalen 576i Streams zitterfrei laufen:


    Code
    1. decoder->SecondFieldHistory[1] and decoder->FirstFieldHistory[0]
    2. decoder->SecondFieldHistory[2] and decoder->FirstFieldHistory[1]


    Wenn ich allerdings ServusTV anwerfe, brauche ich die folgende Frame-Order für ein zitterfreies Bild:

    Code
    1. decoder->SecondFieldHistory[1] and decoder->FirstFieldHistory[2]


    - wenn ich mir die Laufschrift auf N24 anschaue, bin ich mir nicht so sicher, ob wirklich der Advanced Deinterlacer am Werk ist, die ist nämlich ziemlich ausgefranst. Aber das passt auch zum Logfile:


    Code
    1. Sep 30 09:05:07 [vdr] video/vaapi: supports video processing_
    2. Sep 30 09:05:07 [vdr] video/vaapi: black surface displayed_
    3. Sep 30 09:05:07 [vdr] video/vaapi: interlaced 1 top-field-first 1_
    4. Sep 30 09:05:07 [vdr] video/vaapi: stream <-> surface size/interlace mismatch_
    5. Sep 30 09:05:07 [vdr] video/vaapi: can't destroy postproc context!_
    6. Sep 30 09:05:07 [vdr] video/vaapi: can't destroy config!_
    7. Sep 30 09:05:07 [vdr] video/vaapi: search format NV12 in 8 image formats_


    Bei ServusTV kommt:


    Code
    1. Sep 30 09:07:27 [vdr] video/vaapi: VaapiCreateSurfaces: 1920x1080 * 27_
    2. Sep 30 09:07:27 [vdr] video/vaapi: noise reduction supported_
    3. Sep 30 09:07:27 [vdr] video/vaapi: 0,00 - 1,00 ++ 0,03 = 0,50_
    4. Sep 30 09:07:27 [vdr] video/vaapi: deinterlacing supported_
    5. Sep 30 09:07:27 [vdr] video/vaapi: bob deinterlace supported_
    6. Sep 30 09:07:27 [vdr] video/vaapi: motion adaptive deinterlace supported_


    Fnu, kommt bei Dir die Ausgabe bzgl. der Deinterlacer auch bei den normalen 576i Streams? Ich vermute: ja :)


    Gruß,


    Space


    EDIT: PS: es macht übrigens keinen Unterschied, ob va-api-glx oder va-api verwendet wird, die Meldungen sind bei mir im Logfile gleich ... fnu : hast Du mal va-api-glx probiert? Vielleicht geht das VPP ja trotzdem und die Sync-Probleme sind auch weg.