Posts by hoschi78

Quote from ebsi

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.

make[3]: Betrete Verzeichnis '/usr/local/src/libva/test/basic'
  CC test_01.o
  CCLD   test_01
/usr/bin/ld: test_01.o: undefined reference to symbol 'vaMaxNumProfiles'
/usr/bin/ld: note: 'vaMaxNumProfiles' is defined in DSO /usr/local/src/libva/va/.libs/libva.so.1 so try adding it to the linker command line
/usr/local/src/libva/va/.libs/libva.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [test_01] Fehler 1
make[3]: Verlasse Verzeichnis '/usr/local/src/libva/test/basic'
make[2]: *** [all-recursive] Fehler 1
make[2]: Verlasse Verzeichnis '/usr/local/src/libva/test'
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlasse Verzeichnis '/usr/local/src/libva'
make: *** [all] Fehler 2

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

man hätte sich andere Alternativen gesucht usw.

die da wären ?

nuja, laut citycom wartet man diese woche auf die endgültige anlieferung mit stückzahlen "weit über 4stellig" ...

gruss hoschi, der auf godot wartet

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 ?

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
        ### [arg]: arg optional
        #Option     "AccelMethod"               # [<str>]
        #Option     "DRI"                       # [<bool>]
        #Option     "ColorKey"                  # <i>
        #Option     "VideoKey"                  # <i>
        #Option     "FallbackDebug"             # [<bool>]
        #Option     "Tiling"                    # [<bool>]
        #Option     "Shadow"                    # [<bool>]
        #Option     "SwapbuffersWait"           # [<bool>]
        #Option     "XvMC"                      # [<bool>]
        #Option     "XvPreferOverlay"           # [<bool>]
        #Option     "DebugFlushBatches"         # [<bool>]
        #Option     "DebugFlushCaches"          # [<bool>]
        #Option     "DebugWait"                 # [<bool>]
        Identifier  "Card0"
        Driver      "intel"
        VendorName  "Intel Corporation"
        BoardName   "Core Processor Integrated Graphics Controller"
        BusID       "PCI:0:2:0"
EndSection

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

Section "Module"
        Load  "dri2"
        Load  "glx"
        Load  "dri"
        Load  "record"
        Load  "extmod"
        Load  "dbe"
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

Dass meine Installation mittlerweile arg verkorkst ist, ist mir auch klar 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.

Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: xineliboutput (1.0.90-cvs): X11/xine-lib output plugin
Jan 30 19:16:04 vdr vdr: [14369] section handler thread started (pid=14361, tid=14369)
Jan 30 19:16:04 vdr vdr: [14361] new device number 9
Jan 30 19:16:04 vdr vdr: [14361] [xine..put] cXinelibLocal: Using xine-lib configuration file /var/lib/vdr/plugins/xineliboutput/config
Jan 30 19:16:04 vdr vdr: [14361] [xine..put] cTimePts: clock_gettime(CLOCK_MONOTONIC): clock resolution 0 us
Jan 30 19:16:04 vdr vdr: [14361] [xine..put] cTimePts: using monotonic clock
Jan 30 19:16:04 vdr vdr: [14361] [xine..put] RTP SSRC: 0x600467f8
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: epgsearchonly (0.0.1): Direkter Zugriff auf epgsearch's Suchenmenu
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: text2skin (1.3.1): Lader für textbasierte Skins
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: director (0.2.8): plugin to use the premiere multifeed option
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: conflictcheckonly (0.0.1): Direkter Zugriff auf epgsearch's Konflikt-Prüfungs-Menü
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: quickepgsearch (0.0.1): Schnelle Suche nach Sendungen
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: epgsearch (0.9.25.beta17): Suche im EPG nach Wiederholungen und anderem
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: extrecmenu (1.2-test1-am2b): Erweitertes Aufzeichnungs-Menü
Jan 30 19:16:04 vdr vdr: [14361] plugin 'extrecmenu' called obsolete function RegisterI18n()
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: live (0.2.0): Live Interactive VDR Environment
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: markad (0.0.7): Markiere Werbung
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: premiereepg (0.2.0): Liest erweiterte Premiere EPG Daten ein
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: vnsiserver (0.0.1): VDR-Network-Streaming-Interface (VNSI) Server
Jan 30 19:16:04 vdr vdr: [14361] initializing plugin: nordlichtsepg (0.9): Extended EPG
Jan 30 19:16:04 vdr vdr: [14361] setting primary device to 3
Jan 30 19:16:04 vdr kernel: [68045.776511] vdr[14361]: segfault at 1 ip 00007f5daf940d9a sp 00007fff7f167e98 error 6 in libvdr-xineliboutput.so.1.7.16[7f5daf919000+8b000]
Jan 30 19:16:04 vdr runvdr: restarting VDR

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

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

/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

load_plugins.c: In function ‘_x_scan_plugins’:
load_plugins.c:1311: error: ‘__XINE_LT_AGE’ undeclared (first use in this function)
load_plugins.c:1311: error: (Each undeclared identifier is reported only once
load_plugins.c:1311: error: for each function it appears in.)
load_plugins.c: In function ‘_x_get_video_decoder’:
load_plugins.c:2129: warning: comparison between pointer and integer
load_plugins.c: In function ‘xine_get_file_extensions’:
load_plugins.c:2682: warning: passing argument 3 of ‘_x_concatenate_with_string’ discards qualifiers from pointer target type
load_plugins.c:2639: note: expected ‘char *’ but argument is of type ‘const char *’
load_plugins.c: In function ‘xine_get_mime_types’:
load_plugins.c:2721: warning: passing argument 3 of ‘_x_concatenate_with_string’ discards qualifiers from pointer target type
load_plugins.c:2639: note: expected ‘char *’ but argument is of type ‘const char *’
load_plugins.c: In function ‘dispose_plugin_list’:
load_plugins.c:2788: warning: passing argument 1 of ‘free’ discards qualifiers from pointer target type
/usr/include/stdlib.h:488: note: expected ‘void *’ but argument is of type ‘const uint32_t *’
load_plugins.c:2796: warning: passing argument 1 of ‘free’ discards qualifiers from pointer target type
/usr/include/stdlib.h:488: note: expected ‘void *’ but argument is of type ‘const char *’
make[2]: *** [load_plugins.lo] Fehler 1
make[2]: Leaving directory `/usr/local/src/vaapitest/xine-lib-1.2-df20-210111-vaapi/src/xine-engine'
make[1]: *** [../src/xine-engine/libxine.la] Fehler 2
make[1]: Leaving directory `/usr/local/src/vaapitest/xine-lib-1.2-df20-210111-vaapi/misc'
make: *** [all-recursive] Fehler 1

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

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).

git clone git://gitorious.org/x-org-build-script/mainline.git
cd mainline
./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

Danke Urig.

Um das setzen der Marken auf nicht-I-Frames zu verifizieren könnte man was tun ?

Danke & Gruss
Hoschi

FYI:

libva 1.0.7 ist jetzt im debian-multimedia.org Repo

# aptitude show libva1 
Paket: libva1 
Zustand: Installiert 
Automatisch installiert: ja 
[B]Version: 1.0.7-0.0 [/B]
Priorität: extra 
Bereich: libs 
Verwalter: Christian Marillat <marillat@debian.org> 
Unkomprimierte Größe: 434 k 
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

Quote

0:02:03.05
0:02:03.14 assumed start of broadcast (3088)
0:02:10.22
1:29:28.16
1:37:00.02
1:37:00.13 assumed stop of broadcast (145512)

Display More

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 ?

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

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"

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