Beiträge von Flachzange

hmm gut zu wissen. Welche Problematik ist das? Könntest du das vielleicht kurz zusammenfassen?

Also soweit ich weiß, dauert die Entwicklung der Linux-Treiber noch 4-6 Wochen nach Ausließerung. Also jetzt noch ca. 4-5 Wochen. Problem ist aber wohl hauptsächlich die Unterstützung des CI-Moduls unter Linux und wenn ich die Aussagen von DD richtig interpretiere, dauert das wohl noch eine Weile. Das CI wird leider bei fast allen Kabelanschlüssen in D benötigt. Für mich also leider keine Alternative und ich bleibe bei meiner KNC1, die läuft ganz ordentlich.

So ich habe jetzt noch mal Vergleichswerte mit einer NVIDIA Quadro FX 380 LP (entspricht G210) erstellt:

Alle Werte jetzt mit 300W Cougar Netzteil.

Mit onchip Intel Grafik:
Idle: 30W
XBMC: 39W (SD) / 45W (HD)
Xineliboutput: 45W (SD) / 50W (HD)

Mit NVIDIA-Grafik:
Idle: 36W
XBMC: 48W (SD) / 54W (HD)
Xineliboutput: 47W (SD) / 53W (HD)

Wie man sieht ist bei XBMC ein größerer Unterschied zu sehen. Die Bildqualität finde ich subjektiv aber auch deutlicher schlechter mit Software-Decoding (Intel). Hinzu kommt, dass das Deinterlacing kein Vergleich zu Xineliboutput ist. Bei Xineliboutput ist die Bildqualität auch mit Intel sehr gut, aber die CPU-Last ist halt auch hoch, was sich letztenlich in identischen Leistungswerten im Vergleich zu der NVIDIA-Variante wiederspiegelt.

Insgesamt finde ich die VDPAU Lösung besser, da die CPU dann noch Reserven für andere Dinge hat. XBMC ist für mich mit der Intel Grafik keine Alternative.

Update: Mit einem Cougar A300 Netzteil sind es 30W.

Zitat

Original von pingu2k
Ich bin kein Freund der Pico-PSU Netzteile. Daher freut mich Dein exemplarischer idle Stromverbrauch mit einem standard-Netzteil!

Da muss ich dich jetzt leider enttäuschen. Bei mir läuft auch eine Pico. Für ein gutes 300W BeQuiet oder so, darfste dann noch mal 5-10W draufrechnen.

Zitat

Original von pingu2k
Jetzt überlege ich noch mit einer Grafikkarte. Naklar funktioniert VDPAU mit nVidia super. Aber eigentlich ist der Prozessor alleine (mit integrierter Grafik) schnell genug um HD zumindest zu decodieren (siehe 720p50 oder 1080p25). Problem sind die Halbbilder. Hmm... Mein Wunsch wäre die synchrone Ansteuerung eines TV, der die Halbbilder von dem 1080i50 Material selbst am besten entfernen kann. 576i50 (PAL) dürfte die CPU wohl selbst schaffen.

Also es ist ja nicht so, dass die CPU grundsätzlich zu schwach für 1080i ist. Das oben erwähnte rechte anspruchsvolle 1080i Testfile, das ich hier habe, läuft mit dem (s)mplayer bei 70-80% Last. Bei XBMC ist die Last beispielsweise ja auch geringer.

Zitat

Original von pingu2k
Super! Vielen Dank!

Jezt bin ich meinem Wunschsystem ein Stück näher

hehe und das wäre?

ahjo, das könnte das wirklich erklären.

Edit: Stromverbrauch mit HD: 40W
Idle: 23-25W

Ich werde mal schauen, dass ich eine Nvidia G 210 bekommen, dann kann ich mal vergleichen.

Hallo,

danke für die Antwort. Woran liegt das denn, dass vdr-sxfe so viel Power benötigt?

Ich habe gestern mal mit der internen Media Player Funktion von xineliboutput getestet:

1080p: ca. 80% CPU-Last, also unwesentlich mehr als TV mit 720p
1080i: 100% CPU-Last mit einigen drop frames.

Mich würde mal die Erfahrung von anderen Core i3 Nutzern interessieren.

Hallo zusammen,

bin mir nicht sicher, ob ich hier im richtigen Forum bin, aber ich versuche es mal.

Ich möchte herausfinden, inwieweit ein System auf Core i3/i5 Basis geeignet für den Aufbaue eines VDR mit xineliboutput oder ggf XBMC ist. Uns das insbesondere im Vergleich zu klassischen VDPAU-Lösungen.

Im Moment läuft bei mir folgende Konfiguration testweise:

Mainboard: MSI H55M ED55
CPU: Core i3 530 @ 2.93GHz + 2GB RAM
TV-Karte: KNC One DVB-C inkl CAM
System: Ubuntu 10.10 + VDR 1.7.16 + xineliboutput + xine-lib-1.2 respektive xbmc pvr-testing2

Pulseaudio musste deinstalliert werden, damit TV nicht ruckelt

Meine bisherigen Erfahrungen mit xineliboutput:
- HDTV (720p) läuft
- CPU-Auslastung liegt bei ca. 80% (vdr-sxfe) und 26%(xorg)
- Deinterlacing TVTime/TomsMoComp

Meine Knappe Erfahrung mit XBMC:
- Deinterlacing deutlich schlechter
- Bildqualität schlechter als mit sxfe
- CPU-Auslastung besser (genaue Werte habe ich gerade nicht im Kopf, ca. 60%)

Ich finde die CPU-Auslastung mit xineliboutput sehr hoch und würde annehmen, dass so 1080i/p nicht laufen würde. Andererseits sollten die 2x2.93GHz eigentlich locker reichen....

Mich interessieren jetzt zwei Dinge

1) Gibt es Qualitätsunteschiede zwischen VDPAU-basiertem Deinterlacing und Software-Deinterlacing? Oder allgemein: Ist es sinnvoll eine extra Graka (z.b. NVIDIA G210) zu verwenden?

2) Wie ist eure Erfahrung mit einem VDR auf Core i3/i5 Basis? CPU-Auslastung, Deinterlacing etc

Danke schon mal
Christoph

vielleicht noch mal als Ergänzung dazu, da ich auch an der gleichen Baustelle dran bin (gleiche Konfig, gleiches Prob):

Ein

aplay -Dplughw:0,7 -fcd musik.wav

respektive hw:0,3

lässt die Lautsprecher auch stumm bleiben. Da geht also irgendetwas grundsätzliches nicht und es ist nicht auf xbmc beschränkt.

Hallo zusammen,

ich bin neuerdings von einem VDPAU-basierten HTPC auf Intel Clarkdale i3 umgestiegen und dabei natürlich auch direkt über VAAPI und diesen Thread gestolpert.

Ich muss dazu sagen, dass ich auch mit xineliboutput meine ersten Erfahrungen sammle. Vorher habe ich vdr-xine verwendet.

Ich hab die xine-lib1.2-vaapi von Edger ausgecheckt und gebaut und ich muss sagen: Es läuft! Also erstmal Danke an dieser Stelle für die tolle Arbeit. Alles mit xineliboutput (SVN), da vdr-xine auch nicht gegen die neue xine-lib-1.2-vaapi baut.

Zitat

libva: 0.31 AvCodecContext w 1280 h 720
Profile: 7 (VAProfileH264High) Entrypoint 1 (VAEntrypointVLD)
found valid image format init vaapi successfully

CPU-Auslastung (vdr-sxfe) bei 720p (ARD HD):
Standard: 88%
VAAPI: 65%

Also die Hardwarebeschleunigung scheint zu funktionieren, wobei ich über die hohe Grundauslastung schon sehr erstaunt bin.

ABER: Etwas trübt den H.264 VAAPI Genuss jedoch noch. Und zwar habe ich gleichmäßige Ruckler (Das Bild kommt in Schüben). Wenn das noch funktioniert ist es perfekt! Mit der Standard Xine-lib tritt das Problem nicht auf.

Grüße,
Flachzange

Edit:

Zitat

Original von hoschi78
Meine bisherigen Tests mit XBMC ind aktiviertem VAAPI sind immer gründlich in die Hose gegangen. Sobald VAAPI aktiviert war, war die CPU Last zwar im Keller, aber ich hatte eine wunderbare Dia-Show mit dropped frames, während der Sound durchgängig lief.

Das Problem habe ich allerdings auch noch.

Also noch mal ein kurzes Update zu der Problematik, die nachwievor besteht:

1) Das Xine-Plugin ist nicht das Problem
2) Wird das Xine-Plugin nicht geladen, ist der TS tatsächlich schrott. Es gibt jede Menge Bildfehler und Blockartefakte und mencoder segfaulted bei der Nutzung von streamdev und externremux.sh. Warum das Bild mit xine-plugin nicht schrott ist, kann ich mir aber nicht erklären. Und warum nur mit geladenem Xine-plugin TS-Continuity Fehler geworfen werden, kann ich mir auch nicht erklären.
3) Unter Windows läuft die Karte auf gleicher Hardware problemlos

Meine nächster Schritt wäre jetzt die Karte inkl. der Risekarten in einem anderen Rechner zu testen,der auch noch einen normalen PCI-Slot hat, um so den Vergleich zu haben.

Vielleicht hat aber jemand noch eine andere Idee..

Grüße,
Christoph

hat niemand eine Idee? Gibt es keine Möglickeit die TS-Continuity zu unterdrücken?

Also vielleicht noch mal als Zusatzinfo: Die TS-Continuity kommen tatsächlich nur dann, wenn ich das Xine-plugin lade. Lasse ich das weg gibt es keine Probleme. Auch mit dem von mir verwendeten Streamdev-pluging gibt es keine solchen Fehler.

Grüße,
Christoph

Hallo zusammen,

mein VDR (bisher 1.7.9) hat einen neuen Untersatz bekommen. Ein komplett neues Mainboard (Intel Mobile mit NVIDIA onboard Grafikkarte). Da es einen PCIe x16 Slot hat, verwende ich eine PCI-E to PCI Bridge (stand hier auch irgendwo im Forum). Vorher war es ein AMD x2 Board mit PCI und ebenfalls NVIDIA onboard Grafikkarte.

Zunächst habe ich das alte System (Ubuntu 9.10) einfach mit dem neuen Board gebootet. Das lief auch alles absolut problemlos. Es gab keine offensichtlichen Probleme. HDTV ging mittels VDPAU genauso gut wie vorher. Jedoch wurden meine Logs zugemüllt mit TS-Continuity Fehlern. Aber das auch nur, wenn ich XINE nicht laufen hatte und selber kein TV lief.

Naja, da hab ich mir gedacht, dass wird ggf. an der PCI-E to PCI Bridge oder einfach am "alten" System liegen.

Also habe ich jetzt ein neues System aufgesetzt. Ubuntu 10.04, aktuelle NVIDIA-Treiber 195.36.24 und die VDR Entwicklerversion 1.7.14. Im Unterschied zum alten System habe ich dieses Mal xine-vdpau aus dem svn verwendet und nicht die xine-lib-1.2. mit einem vdpau ffmpeg compiliert, wie bei meinem alten System.

Leider hat das keinen Erfolg. Das System läuft super. Sogar besser als mein altes. Insbesondere sind kleinere Ruckler verschwunden und nach dem Umschalten auf HD-Kanäle gibt es nicht mehr ewig viele Ton-Aussetzer. Die TS-Continuity Fehler sind aber leider nicht weg und pro Sekunde werden hunderte Fehler ins Log geschrieben.

Also noch mal zusammengefasst:

1) Wenn ich den VDR mit Xine Plugin starte werden sofort TS-Continuity Fehler ins Log geschrieben
2a) Starte ich Xine und schalte den Kanal um, sind die Fehler verschwunden und alles läuft bestens und ohne Fehler
2b) Starte ich Xine bereits vor dem VDR, dann kommen keine Fehler. Ein Umschalten des Kanals ist nicht notwendig
3) Beende ich Xine dann kommen die TS-Continuity nach ca. 30 Sekunden wieder.

Mein System:
- Jetway NC-64 mit NVIDIA GF9100m und Intel Core 2 Duo SU9600
- KNC One DVB-C + Cineview CI-Modul und Alphacrypt CAM
- Ubuntu 10.04 (Problem aber auch mit 9.10)
- Aktueller NVIDIA-Treiber 195.36.24
- s2-liblianin Treiber (die brauche ich sehr wahrscheinlich gar nicht, kann es daran liegen?)
- VDR 1.7.14 (Problem aber auch mit 1.7.9)
- xine-vdpau svn mit Patch von durchflieger
- Xine-Plugin 0.9.3 mit Patch von durchflieger

Bitte kurz Bescheid geben, wenn ich irgendwelche wichtigen Informationen vergessen haben sollte.

Würde mich freuen, wenn jemand eine Idee hat, woran das liegen könnte. Alternative würde ich mich auch dem Workaround zufrieden geben, die Fehlermeldungen aus dem Log zu verbannen.

Danke und Gruß,
Christoph

Ausgabe vom xine-plugin:

------------------------- MakePrimaryDevice: 1 -------------------------
MakePrimaryDevice: 1
=========================
SetVideoFormat: 0
SetVolumeDevice: 255
frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00)
SetAudioChannelDevice: 0
SetVolumeDevice: 255
SetPlayMode: 1
SetDigitalAudioDevice: 0
SetDigitalAudioDevice: 1
frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00)
[A]

das steht auch beim 0.8.6 so drin. irw ging ja auch. nur musste man ja scheinbar dem vdr explizit sagen wo der lircd ist.

perfekt! das wars. Ich hab LIRC 0.8.6.

Ich danke dir und der Abend ist gerettet

hallo zusammen,

auch wenn es schon so einige Threads zu dem Thema gibt, komme ich gerade überhaupt nicht weiter. Wollte jetzt zum ersten Mal den VDR (1.7.9) mit FB nutzen und hab mir dir Pollin X10 gekauft. Hab mir dazu die ganzen Threads im Wiki zum Thema FB, X10, LIRC, etc. gelesen. Das Kernel Modul lirc_atiusb scheint mir automatisch geladen zu sein (Ubuntu 9.10) und scheint auch zu funktionieren.

- irw #funktioniert
- socat UNIX-CONNECT:/dev/lircd STDIO #funktioniert

lediglich im VDR kommen die Befehle nicht an. Ich hab in der Make.config vor dem Bauen LIRC_DEVICE = /dev/lircd gesetzt

im log kann ich sehen, dass die remote.conf geladen wird. Muss da sonst noch etwas zu LIRC stehen? Im log kann ich auch sehen das schlichtweg gar nichts passiert. Ich hab auch gesehen, dass der VDR automatisch einen lernmodus starten soll, wen keine remote.conf vorhanden ist. Das tut er bei mir schon mal nicht.

Derzeit nutze ich XINE als Frontend, aber das dürfte ja nicht so relevant sein.

Ich hoffe, dass mir hier jemand helfen kann.

Grüße,
Christoph

Meine lircd.conf

begin remote
  name X10_pollin
  bits 40
  eps 30
  aeps 100
  one 0 0
  zero 0 0
  pre_data_bits 0
  pre_data 0x0
  post_data_bits 0
  post_data 0x0
  gap 235969
  toggle_bit_mask 0x80800000
  begin codes
    CH1_0          0x14ec170000
    CH1_1          0x14e20d0000
    CH1_2          0x14e30e0000
    CH1_3          0x14e40f0000
    CH1_4          0x14e5100000
    CH1_5          0x14e6110000
    CH1_6          0x14e7120000
    CH1_7          0x14e8130000
    CH1_8          0x14e9140000
    CH1_9          0x14ea150000
    CH1_ASTERISK   0x140c370000
    CH1_BACK       0x14f5200000
    CH1_BLUE       0x140a350000
    CH1_CHDOWN     0x14e10c0000
    CH1_CHUP       0x14e00b0000
    CH1_DOWN       0x14f7220000
    CH1_DVDMENU    0x14d9040000
    CH1_FORWARD    0x14fb260000
    CH1_GREEN      0x1408330000
    CH1_GUIDE      0x1406310000
    CH1_HASHMARK   0x140d380000
    CH1_INFO       0x14042f0000
    CH1_LEFT       0x14f21d0000
    CH1_LIVETV     0x14f11c0000
    CH1_MENU       0x14f01b0000
    CH1_MUSIC      0x14db060000
    CH1_MUTE       0x14d5000000
    CH1_NEXT       0x14f8230000
    CH1_OK         0x14f31e0000
    CH1_PAUSE      0x14fe290000
    CH1_PHOTO      0x14da050000
    CH1_PLAY       0x14fa250000
    CH1_POWER      0x14d7020000
    CH1_PREVIOUS   0x14f6210000
    CH1_RECORD     0x14fc270000
    CH1_RECTV      0x14ed180000
    CH1_RED        0x1407320000
    CH1_REWIND     0x14f9240000
    CH1_RIGHT      0x14f41f0000
    CH1_STOP       0x14fd280000
    CH1_TEXT       0x14eb160000
    CH1_UP         0x14ef1a0000
    CH1_VIDEO      0x14022d0000
    CH1_VOLDOWN    0x14dd080000
    CH1_VOLUP      0x14de090000
    CH1_YELLOW     0x1409340000
  end codes
end remote

remote.conf

LIRC.Up         UP
LIRC.Down       DOWN
LIRC.Menu       MENU
LIRC.Ok         OK
LIRC.Back       BACK
LIRC.Left       LEFT
LIRC.Right      RIGHT
LIRC.Red        RED
LIRC.Green      GREEN
LIRC.Yellow     YELLOW
LIRC.Blue       BLUE
LIRC.0          0
LIRC.1          1
LIRC.2          2
LIRC.3          3
LIRC.4          4
LIRC.5          5
LIRC.6          6
LIRC.7          7
LIRC.8          8
LIRC.9          9
LIRC.Info       INFO
LIRC.Play       PLAY
LIRC.Pause      PAUSE
LIRC.Stop       STOP
LIRC.Record     RECORD
LIRC.FastFwd    FORWARD
LIRC.FastRew    REWIND
LIRC.Next       NEXT
LIRC.Prev       PREVIOUS
LIRC.Power      POWER
LIRC.Channel+   CHUP
LIRC.Channel-   CHDOWN
LIRC.Volume+    VOLUP
LIRC.Volume-    VOLDOWN
LIRC.Mute       MUTE
LIRC.Audio      ASTERISK
LIRC.Schedule   GUIDE
LIRC.Timers     TEXT
LIRC.Recordings HASHMARK

beides von hier: http://vdr-portal.de/board/thread.php?threadid=89297

Ich nutze den c't vdr nicht, kann dir da also leider nicht weiterhelfen.

So richtig stabil läuft mein alphacrypt übrigens immernoch nicht, obwohl es zu Beginn nach dem Kernelupdate echt gut lief

Viele Dank für den Tipp mit dem Kernel. Hatte das Problem auch mit irgendeinem neueren 2.6.28.xx. Hab jetzt 2.6.30 installiert und seit dem ist das Alphacrypt stabil.

super. Danke