Posts by hoschi78

    Auch die libva ( 1.0.12 ) aus den sourcen gebaut.

    "Beflügelt" von dieser Aussage, hab ich mir auch mal auf ner Testumgebung alles zusammengeschustert, krieg aber die libva 1.0.12 nicht gebaut.



    Lief das bei dir problemlos durch oder musstest du irgendwas abändern ?


    Danke & Gruss
    Hoschi



    Edit:
    Google war auch mein Freund. Das Problem wurde schon auf der entsprechenden Mailingliste diskutiert.


    http://lists.freedesktop.org/a…2011-February/000471.html


    Quote

    or patch the various Makefile.am under test/ with something that looks like:
    TEST_LIBS = $(top_builddir)/va/$(libvabackendlib) $(top_builddir)/va/libva.la


    and automake & libtool will do the rest.

    Quote

    Originally posted by wbreu
    Mach das mal bitte, ich denke mal dann ist das tearing weg.


    Danke für den Tip, werd ich heut Abend mal ausprobieren.
    Grad mal die xorg.conf angeschaut.. da gibts nichts was auch nur irgendwie composit heisst.
    Vielleicht siehst du hier dennoch etwas ?


    DRI ist hier in deiner config unter device nicht gesetzt und ich hab auch mal die Änderungen (uxa) entsprechend deiner xorg.conf übernommen.


    Code
    1. Section "Module"
    2. Load "dri2"
    3. Load "glx"
    4. Load "dri"
    5. Load "record"
    6. Load "extmod"
    7. Load "dbe"
    8. EndSection


    GLCORE hab ich hier auch mal mit reingenommen.


    Wenn ich bei extensions composite reinnehm und xcompomgr starte, dann habe ich diesen Effekt, dass an der "Grenze" vom oberen zum nächstunteren Viertel des Bildschirms diese Verschiebungen auftreten.
    Ohne composite und xcompmgr und somit ohne --hud siehts ansich recht gut aus.



    Quote

    ca. 1,4 GB, ein wenig abgespeckt (also ohne xbmc und ein wenig bereinigt) dann ca. 1,0 GB als DVD.


    Speicherplatz im Web könnt ich zur Verfügung stellen...
    und nein, ich weiss nicht was das für ne Arbeit ist, aber ich denk mir es is net grad wenig.. von daher beachte man bitte den ;) - Smiley



    Flachzange
    Auch das werd ich mal probieren undberichten. Danke.
    Edit: Brachte auch keie Verbesserung.



    Gruss Hoschi

    Nabend die Herren,


    zum Thema Desktop(-Manager)...
    Ich verwende hier nodm & fluxbox, was ohne xcompmgr und somit ohne --hud ansich ein sehr gutes Ergebnis liefert.
    Mit o.g. hab ich auch immer recht störende "Streifen" bei HD+ oder Sky HD... kanns nicht so genau beschreiben.. sieht so aus als ob die obere Hälfte des Bildschirms schon ein Bild weiter is als die untere.. SD Kanäle versuche ich eh weitestgehend zu vermeiden.. wer SD schauen will kann auch bei ner Röhre bleiben :D


    Dass meine Installation mittlerweile arg verkorkst ist, ist mir auch klar :D aber dennoch "gehts" .. nich zwingend schön, aber geht. So Erfolge wie wbreu vermag ich nicht zu berichten.



    Wenn nun die Ubuntu 10.10 + xorg-edgers oder Natty nicht so liefen wie gewünscht, dann werd ich mir das ja nun auch sparen können. Aber ne Neuinst sollte doch mal Sinn machen.
    Sicherheitshalber werd ich wohl dennoch dieses mal bei 32Bit bleiben.



    Gebastel hin oder her, ich kann den Frust einiger "Tester" schon nachvollziehen. Irgendwann macht sich Resignations breit und rein von der CPU-Power her schaffts der Core ixxx ja auch Problemlos ohne vaapi *duck*




    wbreu
    Hast du mal dran gedacht deine Installation zu Paketieren ? ;-)



    Gruss Hoschi

    Quote

    Originally posted by wbreu
    Alles klar?


    Jawohl :)


    Mit libxine 1.2 und xineliboutput komm ich dennoch nicht weiter. Dein zip lässt sich bei mir nicht bauen mit oben schon angegebener Fehlermeldung, von vdr-developer baut wunderbar, aber steigt mit segfault aus.


    Gibts mit der libxine1-2 evtl. bekannte Probs auf 64bit Systemen ?



    Zum Thema KMS... soweit ich das bisher gelesen habe alles was framebuffer heisst raus aus der config ausser inteldrmfb und console fb.
    Infos hab ich von hier: http://linux.koolsolutions.com…s-in-debian-linux-kernel/
    Gibts hier sonst noch was bei zu beachten ? Die Info ist ja nun auch schon was älter.



    Danke & Gruss
    Hoschi

    Flachzange


    wenn man mal RICHTIG im logfile nachschaut, dann würde man auch sehen, dass sich nach laden des xineliboutput plugins bzw. beim initialisieren eben selbiges mit einen segfault beendet hat, was den VDR zum Dauerneustart veranlasst hat.... nuja, war spät gestern, aber Fehler zumindest mittlerweile erkannt. Nur mitm beheben wars bisher noch nix.



    wbreu


    Ich versteh die Aussage nicht ganz, bzw. könnte 2 Aussagen deuten.
    Heisst das nun, dass meine Version eine ältere ist und somit beim Bauen gegen alte libs gebaut wurde, sprich hier schon was schief gelaufen ist oder sollte das bedeuten, dass dass die libxine1.1.90 nur inoffiziell 1.2 genannt wird und somit hier erstmal alles in Ordnung ist ?



    Was das kompilieren vom xineliboutput-Plugin angeht, bin ich wie folgt vorgegangen, da die e-Tobi Sourcen vom vdr-plugin-xineliboutput als Abhängigkeit die libxine-dev haben, welche zumindest aus dem Repo als Paket nicht installiert wurde.


    Angelehnt an deine Kompilierdoku....


    cd /usr/local/src
    apt-get source vdr (von e-Tobi geholt)
    ln -s vdr-1.7.16 VDR
    cd VDR
    make clean-plugins
    make plugins
    cd /usr/local/src/VDR/PLUGINS/src/xineliboutput
    make install
    cd /usr/local/src/VDR/PLUGINS/lib
    strip *.*


    Dann die libs nach /etc/vdr/plugins.
    Die libs liegen bei mir alle in /usr/local/lib und/oder /usr/lib/vdr/plugins, also hab ich sie dorthin kopiert.


    Mit diesen libs renn ich in einen segfault.



    Ich werd sie wohl nochmal neu bauen und intensiv schauen, ob Fehler zu sehen sind.


    Wenn dir noch irgendwas "dummes" auffällt, dann bin ich für jeden Tip dankbar.



    Achja.. was ich "anders" mache ist ein make -j4 statt make, damits n bissi schneller geht.
    gcc ist version 4.4.5



    Gruss hoschi

    Sodele.. eine Kompilierorgie weiter gugg ich nun wie n Schwein ins Uhrwerk.. nur dass es hier n bissi dunkler is :D


    Hab den kompletten Krams nochmal von vorn gebaut.. cairo wollte noch pixman haben.. lief alles sauber durch soweit.


    Die vdr sourcen hab ich von e-tobi mittels dpkg-source und xineliboutput hab ich von vdr-developer geholt und vdr/plugins/src gepackt.
    Anschliessend mit make plugins clean, make plugins gebaut und die libs auch entsprechend kopiert.


    Wenn ich nun vdr-sxfe allein oder den kompletten Aufruf mit allen Optionen

    Code
    1. /usr/local/bin/vdr-sxfe --video=xv --display=:0 -f --hud --audio=alsa:hw:0,3 --buffers=1000 --post="autocrop:use_avards_analysis=1,overscan_compensate=30" "xvdr+udp://127.0.0.1:37890" --reconnect --verbose > /var/log/vdr-sxfe.log &


    ausführe, brichts ab. Siehe angehängtes logfile.


    Hier fallen mir 2 Sachen auf.


    1) vdr-sxfe 1.0.90-cvs (build with xine-lib 1.1.90, using xine-lib 1.1.90)
    Das erschliesst sich mir nun nicht wirklich, da ich der Meinung bin, dass ich libxine-1.2 gebaut und installiert hab. ldconfig hab ich nicht vergessen.


    2) xine: Inputplugin gefunden: VDR (Video Disk Recorder) input plugin
    xine: Plugin kann MRL [xvdr+udp://127.0.0.1:37890#nocache] nicht öffnen
    xine: Kann kein Plugin für MRL [xvdr+udp://127.0.0.1:37890#nocache] finden


    Öhm.. ja !
    Ich sehe zwar, was da steht, kanns aber nicht wirklich deuten.
    Was fehlt denn ? Wenn ich den vdr starte, dann taucht xineliboutput mit in der Liste der Plugins auf.


    Any ideas ?





    wbreu
    Da das ganze nicht so gefruchtet hab, wollt ich auch mal deine sourcen nehmen und bauen, aber deine xineliboutput ind xine-ui bauen bei mir nicht. Ich bekomm hier




    Danke & Gruss
    Hoschi

    Den VDR selbst aus den Sourcen von Tobi zu bauen wollte ich eigentlich nicht, bzw. erschliesst sich mir grad nicht, warum ich das tun sollte.
    Mir ging es jetzt ansich nur um "vdr-plugin-xineliboutput", welches ich mit dpkg-source geholt hab.
    Wenn ich da ein dpkg-buildpackage mache, dann bricht das mit der Fehlermeldung ab, dass libxine-dev nicht installiert ist.
    Die Frage hierbei wäre nun, ob ich einfach die libxine-dev aus dem Repo installieren kann, oder ob sich das mit anderem "xine-Gedöns" beisst, bzw. ob von dem zuvor gebauten auch irgendwas in die libxine-dev einfliesst, so dass ein rebuild notwendig ist.


    Gruss Hoschi


    Edit:
    Ein apt-get build-dep vdr-plugin-xineliboutput möchte libxine-dev und libxine1-bin installieren. Würde also eher sinnbefreit sein, da ich ja die libxine-1.2-vaapi nutzen will. Ratlosigkeit macht sichbreit :D

    Quote

    Originally posted by Flachzange
    Ich habe es mal auf rapidshare hochgeladen:


    Prompter Service, vielen Dank :)



    Ich renn hier grad dennoch in ein Problem. Da meine Kompilier-Reihenfolge nicht der von wbreu entspricht, diese aber doch essentiell wichtig wäre. Nun wollte ich jetzt einfach nochmal "richtig rum" bauen.


    libx264 --> ffmpeg --> xinelib-1.2-vaapi --> xine-ui


    Als nächstes wäre das xineliboutput-Plugin dran.
    Hier kann ich mich nicht an die Kompilierdoku halten, da ich den VDR nie aus den Sourcen baue, sondern e-Tobi-Pakete verwende.


    Gut, mittels dpkg-source vdr-plugin-xineliboutput bekomme ich vdr-plugin-xineliboutput-1.0.6+cvs20110105.1949... recht aktuell.
    Nun sollte ein dpkg-buildpackage -us -uc für mich den Rest erledigen und ich sollte deb-Pakete haben.
    Der Befehl zickt aber rum. da libxine-dev als Abhängigkeit drin ist, welches nicht per aptitude installiert ist.
    Wird libxine-dev nicht mit xinelib-1.2-vaapi gebaut ? Wenn nein, kann ich libxine-dev aus dem Repo installieren ohne in irgendwelche Probleme zu geraten ? wbreu meinte letztens was von "bloss nicht mischen".


    Wenn die libxine-dev von nichts Abhängig ist, was ich in den Schritten vorher gebaut habe, dann müsste ich das Paket einfach installieren können. Sollten Abhängigkeiten zu den vorherigen Sachen vorhanden sein, dann sollte ich ansich auch libxine-dev per dpkg-source holen und neu bauen können. Sehe ich das richtig oder hab ich da nen Denkfehler drin ?


    Danke & Gruss
    Hoschi

    Nabend zusammen,


    kurz zu meinem oben geposteten Script.. funzt nicht wie erwartet, also doch alles selber zusammentragen und bauen.. dann weiss man wenigstens, was man hat.


    xserver 1.9.3 läuft nun mit allem drum und dran, ausser libva 1.0.8 und libxine 1.2.
    Die letzten beiden wollte ich gerade bauen, aber der Link
    http://crystalhd.svn.sourcefor…nches/xine-lib-1.2-vaapi/
    scheint tot zu sein.


    Weiss da jemand was genaueres ? Meine Suche auf Sourceforge war nicht von Erfolg gekrönt.


    fnu
    Kurze Frage. Wenn du natty verwendest, woher beziehst du dann den VDR ? Aus den sourcen und selber patchen und bauen ? Oder bedienst du dich anderweitiger Repos ?


    Danke & Gruss
    Hoschi

    Quote

    Originally posted by Flachzange
    Damit konnte ich direkt gestern Abend noch den xserver und Co bauen


    Hi,


    es existiert ein Script, was sich die aktuellen xserver-Sourcen aus dem GIT holt und baut.. so wies aussieht inkl. aller Module (auch proto).


    Code
    1. git clone git://gitorious.org/x-org-build-script/mainline.git
    2. cd mainline
    3. ./build.sh init


    Ich teste das grad mal und wenn ich aus der Bauchspeckwegfabrik wieder da binm werde ich Erfolg oder Mis~ berichten.


    Selbst wenn ich die xserver-Abhängigkeiten einzeln auflösen könnte, so wäre mir das ehrlich gesagt zuviel Gefuddel. Gibt halt Räder, die muss man nicht 2mal erfinden. WENN es das Script tut.. Danke an die Scripter :)


    Gruss Hoschi

    FYI:


    libva 1.0.7 ist jetzt im debian-multimedia.org Repo


    Code
    1. # aptitude show libva1
    2. Paket: libva1
    3. Zustand: Installiert
    4. Automatisch installiert: ja
    5. [B]Version: 1.0.7-0.0 [/B]
    6. Priorität: extra
    7. Bereich: libs
    8. Verwalter: Christian Marillat <marillat@debian.org>
    9. Unkomprimierte Größe: 434 k
    10. Hängt ab von: libc6 (>= 2.2.5), libva-x11-1

    Hallo zusammen,


    wie für viele andere auch sind die "Automatischen Schnittmarkensetzer" mit die wichtigstens Erweiterungen zum VDR.
    Nachdem mein alter SD VDR nun un Rente ist, hab ich mich natürlich auch auf dem HD mit dem Thema befasst. Bisher leistete das noad-Plugin sehr gute Dienste.
    Mit markad hab ich allerdings so meine Probleme, die sich leider auch nicht irgendwie reproduzieren lassen. Bei einer Aufnahme setzt das Plugin die Marken sehr gut, bei anderen wiederum gar nicht. Primär nehme ich von HD Kanälen auf.
    Ich war es bisher gewohnt, dass ich mit 7 und 9 zwischen den Markierungen vor- und zurückswitchen kann, mit 4 und 6 die Marken nach vorn oder hinten verschieben kann.
    Bei einigen Aufnahmen habe ich nun das Phänomen, dass zwar Markierungen gesetzt sind, ich diese aber entweder nicht mit 7 und 9 anwählen kann, oder sie aber nicht mit 4 und 6 verschieben kann. Selbst wenn ich an der richtigen Stelle mit 0 eine neue Markierung setze und an der falschen Stelle mit 0 entferne, ist sie nach wie vor da.


    Als Beispiel soll jetzt mal "Der Kaufhaus-Cop" vom 13.01.2001 Sky Cinema Hits HD dienen.


    "marks" Ungeschnittene Version


    Effektiver Filmbeginn ist 02:10:22, eine von mir gesetzte Markierung, effektives Ende ist eine ebenfalls von mir gesetzte bei 1:29:28.
    Alle anderen MArkierungen habe ich mit 0 gelöscht, aber sie sind weiterhin im mark-File und somit auch im OSD zu sehen.


    Nachdem ich die Aufnahme geschnitten habe, erhalte ich folgende marks-Datei

    Quote

    0:00:00.01
    0:00:00.02
    0:00:00.10
    1:27:16.10
    1:27:18.04


    und somit auch wieder mehr Schnittmarken als erwartet. Soweit ich das bisher gesehen habe, kann man nichts konfigurieren und somit auch nichts kaputt machen.


    Die momentan eingesetzte Version ist die Version: 0.0.7-2 von e-Tobi.
    Ist dieses "Phänomen" soweit bekannt und irgendwo dokumentiert bzw. in einer neueren Revision gefixt ? Oder hab ich wieder mal nur als einziger ein Problem ? :D


    Ich kann problemlos damit leben, dass x (unnütze) Markierungen gesetzt sind, aber n bissi Schmerzen macht mir, dass ich eben diese nicht anwählen und/oder verschieben kann, so dass mein händisch angeregtes Schneiden dann zum gewünschten Ergebnis führt.


    Ich hab den VDR auch schonmal die Aufnahmelisten aktualisieren lassen in der Hoffnung, dass hier "unnütze" Infos gelöscht werden, aber dem war auch nicht so.


    Ist jemandem dieses Problem bekannt und gibts eine Lösung dafür ?


    Danke & Gruss
    Hoschi

    Hallo Wolfgang,


    ich hab meine Parameter mal entsprechend angepasst und muss sagen, dass es wirklich sehr flüssig läuft. Je nach Sender muss ich manchmal noch in den Settings (OSD) vom xineliboutout Plugin ein bissi an der audiokorrektur drehen, weil der Ton manchmal ein bissi vor- oder nachläuft, aber alles in allem doch sehr zufriedenstellend.


    Die Parameter und somit deine Äusserungen dazu hatte ich ja schon gefunden. Mir gehts auch nicht darum irgendjemandem zu unterstellen die Doku stiefmütterlich zu betreiben, das liegt mr fern.
    Wie ciax aber schon angemerkt hat, findet man einfach nur Bröckchen dazu, aber die im Detail. Die config selber ist eher derart kommentiert


    # leuchtet blau
    # default 1
    # blaues.licht = 1
    ums mal ein wenig überspitzt rüberzubringen.


    Ich komme, wie sicherlich viele, von der FF-Fraktion und Ausgabe war für uns bis zur Umstellung auf HD einfach kein Thema.
    Mir fehlt einfach, da ich diese Entwicklung nicht von Anfang an verfolgt hab, sicherlich einies an Hintergrundwissen, wo du / ihr schon auf einen längerfristig gewachsenen Erfahrungsschatz zurückgreifen könnt... und speziell in deinem Fall du diesen auch über deine Website teilst, wofür mich mich hier auch nochmal bedanken wollte.


    Um es kurz zu machen, ob diverse (und vor allem welche) Settings/Werte nur für VDPAU oder VAAPI Sinn machen, kann ich einfach nicht einschätzen (es sei denn der Parameter heisst eindeutig *.vdpau.* oder *.vaapi.*)


    Wie schon oben geschrieben, läuft es eigentlich bisher recht zufriedenstellend, trotz dem "Mischmasch" aus dem Repo von Tobi und Teilen aus den Sources.
    Sobald deine Kompilierdoku fertig ist, werd ich dann wohl mal ein "proof of concept" machen und den kompletten Stack für die Grafik vom Treiber über Xserver bis hin zu libxine nachbauen.


    Wünsche ein schönes Wochenende die Herren.


    Gruss Hoschi

    Wegen diesen beiden hatte er wohl gemeckert


    # number of audio buffers
    # numeric, default: 230
    engine.buffers.audio_num_buffers:1000


    # default number of video frames
    # numeric, default: 15
    engine.buffers.video_num_frames:50


    Die Werte sind jetzt einfach mal "frei Schnauze" nach oben gesetzt, ohne zu wissen, was das genau sein soll.


    Optimierungsmöglichkeiten gibts wohl sicherlich einige, nur weiss ich nicht in wie weit ich die aus den vdpau-Howtos nehmen kann/soll.


    http://www.vdr-wiki.de/wiki/index.php/VDPAU
    http://www.vdr-wiki.de/wiki/index.php/Vdpau_Grundlagen


    Danke & Gruss
    Hoschi

    Moin,


    habs hier btw auf nem 64bit System laufen, geht genau so gut.



    wbreu


    das vdr-sxfe-log hat n bissi gemeckert, dass einige Buffer für einige HD-Kanäle zu gering gewählt wären.
    Die Config ist da leider nicht so gesprächig, was die einzelnen Parameter sein sollen. Hast du da mehr Infos oder ne Ahnung, wo ich die finden kann oder Erfahrungswerte welche Buffer / settings sinnvoll sind ?
    Meine "manpage-Versuche" wurden alle mit "no entry for xyz" quittiert.


    Danke & Gruss
    Hoschi

    Auch Nabend wbreu,


    bin momentan wieder in der Nachtschichtphase und werd wohl erstmal keine Ambitionen haben noch viel zu basteln.. das is schon schlimm, wenn es GRUNDSÄTZLICH läuft, aber net so ganz wies sollte. Provisorien halten ja eh immer am längsten :D


    Ich werd die Tage sicher mal drauf zurückkommen und posten, was ich alles kaputt gemacht hab.


    So ausm Gedächtnis heraus..
    - den tarball geholt, configure, make, make install. (macht das auch xine-dev ? das bräuchte man ja sicher, um den Rest vernünftig zu bauen)
    - alles was xine hiess deinstalliert
    - die sourcen vom libxineoutput / vdr-plugin-xinelibputput geholt (ausp Repo Tobi/Debian)
    - ein dpkg-builddep gemacht (vielleicht hat er mir da wieder "alten" Kram eingespielt, gut möglich)
    - dpkg-buildpackage.. installiert
    - config_libxineoutput vaapi enabled


    Das müssts so grob gewesen sein. Zugriff auf Logfiles habe ich grade nicht.
    Kann man xineliboutput nicht auch ein --verbose mit übergeben ? Dann probier ich das morgen früh mal aus und schau mal, was sich da so tut.



    Noch eine Frage zur "Glaubensfrage" vdr-plugiin-xine vs. vdr-plugin-xineliboutput... der letzte Stand dener Empfehlung ist laut Website ja vdr-plugin-xine.. trifft das nur für VDPAU zu ?



    Danke & Gruss
    Hoschi



    EDIT :
    vaapi läuft :) CPU-Last auf wechselnden Cores bis max 20%

    wbreu


    Ich versuch mal mein Glück.. und wenn nix mehr geht, dann engagier ich dich einfnach... wie hoch ist denn dein Stundenlohn ? ;-)


    @ll
    Für alle, die sich in dem Bereich betötigen wollen und denen Komponenten für einen möglichst stromspareneden HTPC wichtig sind, dem sei folgender Thread ans Herz gelegt. (Ich hoff es ist ok fremdzuverlinken, wenn nich bitte löschen)
    http://www.computerbase.de/forum/showthread.php?t=685231


    Gruss Hoschi



    EDIT:
    ok, ich bin offiziell zu doof
    hab libxine geholt, gebaut, hab den andern kram gebaut wo ich denke es is ausreichend.. mein logfile sagt nix von vaapi.. aber kaputt is auch nix.. ich vermut mal es fehlen doch noch ein paar sachen, die meine standard-inst nicht mitbringt


    wbreu, erleuchte mich mit einem "core i vdr vaapi für dummies" :D

    Hi,


    da Tobi ja auch die Sourcen zur Verfügung stellt, sollte das jetzt nicht so das Problem werden, die VDR-related Sachen neu zu bauen.


    Wenn ich jetzt nicht komplett falsch liege, dann solltes tun, wenn ich:
    - libxine ausm svn baue (Abhängigkeiten erfüllen)
    - alles was mit xine zu tun hat bei Tobi als Src-Paket holen und neu übersetzen


    Das wäre im Prinzip die libxine selbst, libxine1-xvdr, xineliboutput-sxfe und vdr-plugin-xineliboutput. Oder vergesse ich was essentiell wichtiges ?


    Danke & Gruss
    Hoschi