Beiträge von womble

  • [tvtime] Grüne Streifen beim abspielen von VDR Aufnahmen

    Zitat

    Original von SHF
    Ich würde die PCI-latency eher erhöhen, bis die Karten ihren Puffer komplett leer schreiben können und das auch nur bei den Video-Karten.


    Für eine SAA7146-Karte sollte das so klappen (auf eigene Gefahr, wie immer):

    Code
    setpci -d 1131:7146 latency_timer=FF

    Eventuell ist es sinnvoll die Latency in Schritten zu erhöhen, zB.: 40, 80, FF (dezimal: 64, 128, 256)


    Hab schon alle möglichen Werte probiert. Von 0 bis 7 hat's generell Schneetreiben, darüber die besagten gründen Streifen, wenn viel auf dem PCI-Bus los ist.


    Zitat

    Original von SHF
    womble:
    Dein lspci sehe ich mir noch an, hoffe ich kommen am WE dazu.


    Gerne, aber nur, wenn's Dir Spaß macht. Ich für meinen Teil kann mit den gelegentlichen Störungen leben, außerdem konnte mein Rechner letzte Woche seinen 7. Geburtstag feiern (wieviel ist das eigentlich in Menschenjahren? ;) und geht dem Ruhestand entgegen. Ich dachte bloß, vielleicht kann ich nipf und RalfDietz noch ein bisschen helfen.


    Gruß, Bernd

  • [Announce] vdr-plugin-skinelchi-0.1.1pre2 (Elchi-Skin als Plugin) für vdr >=1.3.18

    Hallo Leute,


    das Problem ist, dass in /usr/include/magick/magick-config.h ein Makro mit dem Namen VERSION definiert wird. Dadurch ersetzt der Präprozessor den Namen durch etwas wie "6.3.5", was der Compiler natürlich nicht mag.


    Keine Ahnung, welcher Teufel die imagemagick-Entwickler geritten hat, so einen Allerweltsnamen in einem globalen Header zu verwenden. Könnte mir vorstellen, das einige andere Projekte dasselbe Problem haben.


    Der einfachste Weg, das Plugin trotzdem zu übersetzen ist, es ohne imagemagick-Unterstützung zu übersetzen. Bei meinem Gentoo-System kann man das so erreichen:

    Code
    echo "media-plugins/vdr-skinelchi -imagemagick" >> /etc/portage/package.use


    Andere Möglichkeit mit imagemagick: Workaround in skinelchi.c: #undef nach dem #include "bitmap.h" einfügen, dann sieht's so aus:

    C
    #ifdef HAVE_IMAGEMAGICK
#include "bitmap.h"
// workaround for macro defined in /usr/include/magick/magick-config.h
#undef VERSION
#endif


    Viel Erfolg!


    Bernd

  • [tvtime] Grüne Streifen beim abspielen von VDR Aufnahmen

    Hab's auch mal versucht:


    Vorher:


    Dann:

    Code
    bender ~ # rmmod uhci_hcd
bender ~ # rmmod ehci_hcd


    Ergibt:


    Nach

    Code
    bender ~ # echo 1 > /proc/sys/vm/laptop_mode
bender ~ # setpci -s *:* latency_timer=0

    sieht's dann bei mir aus wie in latency-0.jpg (Ausschnitt).


    Nicht grade eine Verbesserung. Was soll der laptop_mode eigentlich bewirken?

  • [tvtime] Grüne Streifen beim abspielen von VDR Aufnahmen

    Zitat

    Original von SHF

    Was ist das für ein Mainboard?
    Ich wette eins mit KT133 oder KT133A Chipsatz ;D.


    Wenn ja, dann poste bitte mal was "lspci -vxxx" ausgibt.


    SHF: Die Wette hast du gewonnen: Gigabyte GA-7ZX mit VIA KT133 Chipsatz.


    Und hier lspci -vxxx (s. Anhang)


    nipf 7 RalfDietz:

    Code
    setpci -v -s 00:0d.0 latency_timer=0

    gibt bei mir auch nur noch grünen Schnee, ab Werten von >= 4 sind's dann "nur" noch die grünen Streifen bei hoher Last auf dem PCI-Bus. Wobei die Streifen bei hellen Bildbereichen ja übrigens magenta sind.

  • [tvtime] Grüne Streifen beim abspielen von VDR Aufnahmen

    Nasowas, der Thread ist ja doch noch nicht tot!


    Also ich hab die grünen Streifen immer noch, aber wenn ich neben dem Fernsehen keine weitere Last auf die Maschine bringe, ist's nicht schlimm. Hab mich damit abgefunden und hoffe auf Besserung, wenn ich meine Hardware-Antiquität ersetze.


    Der Vollständigkeit halber: HW + Streifen sind gleich geblieben, SW ist neuer:


    - gentoo Linux 2007.0
    - Kernel: gentoo-sources-2.6.23-r6
    - xorg-x11 7.2
    - Grafiktreiber: nvidia-drivers 96.43.01
    - VDR 1.4.7-r10 + div. Plugins, vdrconvert 0.2.1-r1



    @RalfDietz: Hast du mal mit setpci experimentiert? Vielleicht hilft's bei dir doch was.


    Zusammenfassend kann man wohl sagen: Viel Last auf dem PCI-Bus führt bei mancher Hardware (vorwiegend NVidia Grafik und (S)ATA) zu den Streifen.


    Hängt vielleicht damit zusammen, wie gut oder schlecht die Treiber den PCI-Bus durchwalken. Aber das sind alles Mutmaßungen, so gut kenne ich mich da nicht aus.


    Bei neuerer Hardware bestünde wohl die Hoffnung, dass es keine Streifen gibt, wenn SATA und Grafik über PCIe separat angebunden sind.


    Grüße
    Bernd

  • gentoo: System hängt beim Runterfahren nach Wechsel von shutdown auf reboot durch VDR-Init-Script

    Hallo Leute!


    Die kurze Version:

    • Wenn mein Rechner beim Runterfahren wegen nvram-wakeup von Shutdown (runlevel 0) zu Reboot (runlevel 6) wechselt, dann bleibt der Rechner beim Beenden des Netzwerkdienstes (/etc/init.d/net.eth0 stop) hängen.
    • Früher ging's, aber seit einigen Wochen hab ich das Problem nachvollziehbar. Muss sich mit irgendeinem Update eingeschlichen haben.
    • Untersuchung hat ergeben: Hängt mit einem Deadlock in den Init-Scripts zusammen, wo Dateien in /var/lib/init.d/exclusive als Semaphore benutzt werden. Die ist vom VDR-Script, das den "shutdown -r now" ausführt noch blockiert.
    • So gesehen ist der Hänger nachvollziehbar, aber warum hat dann nicht jeder Gentoo VDR Nutzer das Problem? Oder gibt's noch jemanden?


    Die ausführliche Version:

    • Ich benutze mein Gentoo-System als Arbeitsplatz-Rechner und nebenbei als VDR. Rechner wird deshalb meist von Hand runtergefahren (nicht von VDR initiiert).
    • Für's Wakeup brauche ich nvram-wakeup mit Reboot. Nicht immer, wenn ein neuer Timer programmiert wurde, wechseln die VDR Shutdown-Scripts von runlevel 0 auf 6 (reboot), aber darum geht's momentan nicht. Folgendes passiert:
    • Wenn init in den Runlevel 0 (halt, shutdown) wechselt, führt es nacheinander die init-Scripts mit Parameter stop aus und beendet damit die Dienste.
    • Beim VDR-Initscript angekommen stellt der VDR ggf. die neue Wakeup-Zeit und ruft dann "shutdown -r now" auf (/usr/share/vdr/shutdown/shutdown-reboot.sh). Dadurch wird der laufende Wechsel in runlevel 0 verbogen in einen Wechsel in runlevel 6 (reboot).
    • init bringt eine Meldung ("entering runlevel 0" oder so ähnlich) und stoppt nun weiter die Dienste, die vorher noch nicht beendet wurden.
    • Das funktioniert bis net.eth0, dann bleibt der shutdown hängen, es hilft nur noch Stecker ziehen.
    • Ursache: net ist beim VDR-Initscript als dependency eingetragen ("needs net"), deshalb muss es eigentlich vor net.eth0 beendet werden.
    • Genaugenommen ist das VDR-Initscript noch nicht beendet, denn es wartet noch auf die Rückkehr vom shutdown-Befehl. Deshalb ist VDR auch nicht als beendet eingestuft und das VDR-init-Script wird nochmal aufgerufen.
    • Damit greift ein Mechanismus der (gentoo-)Initscripts, der bestimmte Abschnitte der Scripts durch critical sections schützt. Dabei werden Pipes (FIFOs) als Semaphore benutzt (pfiffige Idee, wäre ich nie drauf gekommen). Nachzulesen in /lib/rcscripts/sh/rc-services.sh in den Funktionen begin_service(), end_service(), wait_service()
    • Vom ursprünglichen Aufruf des VDR-Scripts ist noch die Semaphore-Pipe /var/lib/init.d/exclusive/vdr übrig, und damit bleibt das VDR-Initscript beim erneuten Aufruf auf immer und ewig in wait_service() hängen.


    Soweit hab ich's untersucht, und es ist klar, warum der Rechner hängen bleibt. Unklar ist mir aber, warum es anderen nicht genauso ergeht. Oder doch? Habt Ihr Abhilfe parat?


    Ach ja, meine Konfiguration:

    • gentoo-sources 2.6.22-r9
    • baselayout 1.12.9-r2 (enthält u. a. die rcscripts mit wait_service() etc.)
    • VDR 1.4.7-r6
    • gentoo-vdr-scripts 0.4.2
    • eine Handvoll Plugins, die für das Problem hier wohl nicht relevant sind


    Vielen Dank schon mal für Eure Hilfe!

  • AC3 Tonaufnahme ok, DVD aber ohne AC3/DD gebrannt

    Also ich bin inzwischen auf ProjectX ausgewichen. Hat aber generell ziemlich gedauert, bis meine Version von vdrconvert und die diversen Tools - insbesondere ProjectX - zusammengearbeitet haben.


    Musste wieder mal ewig die Logs im Debug-Modus durchkramen, Einstellungen durchprobieren, vdrconvert-Scripte patchen usw. Ich bastle zwar gerne, aber die elende Fummelei geht mir doch langsam auf die Nerven. Mir graut schon vor dem nächsten Update für irgendeines der beteiligten Tools :-((


    Ich kann nur raten: Sucht euch ein vorkonfiguriertes Paket mit vdrconvert und darauf abgestimmten Tools und hofft, dass da nichts übersehen wurde!

  • [tvtime] Grüne Streifen beim abspielen von VDR Aufnahmen

    Ich hab mal mit setpci experimentiert, alle Devices auf hohe ( 128 ) oder niedrige ( 8 ) Werte gesetzt, mal die Grafikkarte (nVidia Geforce 2MX) auf niedrig ( 8 ) und die Nexus-S 2.3 auf hoch ( 128 ).


    Ergebnis: Überhaupt keine Veränderung.


    Laut lspci -v wurden die Werte auch übernommen (außer PCI-, ISA-Bridge und IDE-Interface, die bleiben immer auf 0!). Und wenn ich testweise bei der Nexus auf 1 runtergehe, dann werden immer grüne Punkte eingestreut, die zum rechten Bildrand immer zahlreicher werden. Das beweist: Die Werte werden tatsächlich übernommen und gültig.


    Wie in einem früheren Beitrag gesagt: Bei mir stört anscheinend vor allem die Grafikkarte, ganz besonders, wenn Firefox werkelt, in Verbindung mit dem (hochoptimierten?) "nvidia" X11-Treiber, der den Bus vermutlich deutlich stärker stresst als "nv". Wenn die Platten schuften, was das Zeug hält, stört das dagegeben überhaupt nicht.


    Früher war der Effekt nicht so schlimm. Außerdem hab ich festgestellt, das inzwischen beim Musikabspielen (WAV-Daten an den onboard Soundchip) gleichzeitig zu den Streifen auch noch ein Kratzen und Verzögerungen/Stottern auftreten. Das war früher auch nicht der Fall. Kann entweder an der Weiterentwicklung der Grafik-Treiber liegen, oder daran, dass inzwischen ein zusätzlicher USB2-Controller am PCI-Bus hängt (obwohl da grad nichts angeschlossen ist).


    Das Audio-Gekratze erinnert mich an frühere Windows-Zeiten. Ein Update der Chipsatz-Treiber brachte damals Abhilfe. Ich werde es wohl aufgeben und irgendwann meine HW-Antiquität in Pension schicken...


    Ach ja, die Antiquität besteht u. a. aus:
    - Gigabyte GA 7ZX (VIA KT133 Chipsatz) mit Athlon Thunderbird 900MHz
    - nVidia Geforce 2MX (AGP, 32MB)
    - Nexus-S rev. 2.3


    Darauf läuft derzeit u. a.:
    - gentoo Linux 2006.0
    - Kernel: gentoo-sources-2.6.15-r5
    - xorg-x11-6.8.2-r6
    - Grafiktreiber: nvidia-kernel-1.0.8756, nvidia-glx-1.0.8756
    - VDR 1.3.45-r1 + div. Plugins, vdrconvert 0.2.1


    P.S.: Bei mir treten die Streifen nur beim Ausgeben auf dem Bildschirm auf, die Aufnahmen waren noch nie verstümmelt. Würde mich auch wundern, denn da wird ja einfach der DVB-Strom ein eine Datei geschrieben. Bei Fehlern würde er sich gar nicht mehr decodieren lassen oder zumindest andere Artefakte verursachen.


    dad401: Bist du sicher, dass die Störungen schon in der Aufnahme drin sind?

  • [GELÖST] ProjectX läuft einfach nicht

    Zitat


    Nachdem ich die 0.82.1 verwendet habe, kommt der bisherige Fehler nicht mehr. Dafür kommt jetzt ein anderer Fehler :


    Code
    java.lang.Exception:
commons-net library not accessible! see readme.txt [ii]
ensure the correct location/classpath, related to the executed .jar


    Genau das hatte ich auch mit 0.90.3.01/31.01.2006, als ich /usr/share/projectx/lib/projectx.jar benutzte (die Datei aus dem separaten Package projectx). Als ich stattdessen die mit vdrconvert 0.2.1 installierte Datei /usr/share/vdrconvert/pX/PX.jar (0.90.2.00/05.11.2005) benutzte, hat's funktioniert.


    Frage an Java-Freaks: So sieht bei mir /usr/bin/projectx aus:


    exec $(java-config -J) -Xms32m -Xmx512m -cp $(java-config -p projectx,commons-net,jakarta-oro-2.0) net.sourceforge.dvb.projectx.common.Start "$@"


    Wenn man das vorab expandiert, lautet der Aufruf (ohne Zusatzparameter, als "$@" leer):


    exec /opt/blackdown-jdk-1.4.2.03/bin/java -Xms32m -Xmx512m -cp /usr/share/projectx/lib/projectx.jar :/usr/share/commons-net/lib/commons-net.jar:/usr/share/jakarta-oro-2.0/lib/jakarta-oro.jar net.sourceforge.dvb.projectx.common.Start


    Wenn man nun den Aufruf so umschreibt, dass er dem von vdrconvert entspricht (Keine Start-Klasse direkt angeben, sondern JAR-Datei) müsste exakt das Gleiche bewirken (denn in MANIFEST.MF von projectx.jar ist dieselbe Startklasse angegeben wie beim expliziten Aufruf):


    exec /opt/blackdown-jdk-1.4.2.03/bin/java -Xms32m -Xmx512m -cp /usr/share/commons-net/lib/commons-net.jar:/usr/share/jakarta-oro-2.0/lib/jakarta-oro.jar -jar /usr/share/projectx/lib/projectx.jar


    Aber in diesem Fall kommt der obige Fehler. Ich bin ratlos, was dem Java-Interpreter hier fehlt.


    Vorschlag für Pragmatiker: Wenn man eh schon in vdr2dvd.sh fummelt, dann gleich auch noch den Aufruf ändern: commons-net.jar, jakarta-oro.jar und natürlich projectx.jar als classpath angeben und die Start-Klasse direkt angeben:


    nice -n $PRIO $JAVA -cp $PX:/path/to/commons-net.jar:/path/to/jakarta-oro.jar net.sourceforge.dvb.projectx.common.Start -ini $PXINI -out ${UniqueDir[Number]} $pxfiles > ${LOG[Number]} 2>&1

  • [GELÖST] ProjectX läuft einfach nicht

    Zitat


    und wenn in der vdr2dvd.sh , in der Zeile

    Code
    nice -n $PRIO $JAVA -jar $PX -c $PXINI -o ${UniqueDir[Number]} $pxfiles > ${LOG[Number]} 2>&1


    das c durch das -ini ersetzt wird ?
    mfg



    Ja genau, und weils mir grade ins Auge fällt: -o durch -out ersetzen.

  • [GELÖST] ProjectX läuft einfach nicht

    Hier liegt das Problem:


    Code
    No matching FileType found or file doesn't exist: '-c'


    Alles was danach gemeldet wird ist unsauberes Fehlerhandling. Anscheinend ist irgendwann zwischen Version 0.80 und 0.90 der Parameter zur Angabe der INI-Datei von "-c" auf "-ini" geändert worden. In deinem Fall wird "-c" nicht mehr als Option erkannt, sondern als Datei interpretiert (die es natürlich nicht gibt). Der später angegebene INI-Pfad ist wohl eine Default-Einstellung wie "wenn nichts angegeben ist, nimm ./pX.ini".


    Such mal in vdrconvert.sh nach OLDPX. Falls es das gibt, dann setze es in der vdrconvert-Konfigurationsdatei (bei meiner gentoo-Version 0.2 /etc/vdr/vdrconvert/verconvert.global) auf "no". Und dann musste ich bei mir noch PX von pX.jar auf PX.jar udn PXINI von pX.ini auf PX.ini umstellen (alles von vdrconvert 0.2 mitgebracht):


    Code
    OLDPX="no"
PX="/usr/share/vdrconvert/pX/PX.jar"
PXINI="/usr/share/vdrconvert/pX/PX.ini"
JAVA="/opt/blackdown-jdk-1.4.2.03/bin/java"


    Ansonsten musst du evtl. hardcore in vdrconvert.sh ($PXINI) oder vdr2dvd.sh rumpfuschen. Hat wilderigel ja schon vorgeschlagen.


    Zitat

    Bei mir machten die Umlaute Probleme.
    Es geht nur mit LC_ALL=en_US (de_DE... tut nicht!)
    Stimmt die übertragung des .vdr namens? bei mir sahen die Meldungen ähnlich aus aus, umlaute wurden durch jave mit '?' ersetzt, daher hat ers nicht gefunden.


    Ja, Umlaute und einige Sonderzeichen wie Kommata im Pfadnamen sind Gift, hab ich festgestellt. Bitte Info, wenn jemand eine Lösung hat.


    Ob's an pX liegt oder irgendwo anders, hab ich nicht verfolgt. Zumindest bei den Kommata und Leerzeichen scheitert's vermutlich schon in den Shell-Scripten. Da fehlen bestimmt noch irgendwo die Quotes ("") um die Variablen für die Dateinamen. Müsste man wohl alle mal durchchecken.

  • VDR 1.3.42 + vdrconvert + DVD + AC3-Tonspur

    Zitat

    Original von dawart
    habe bei mir java version "1.5.0_03" installiert


    Hallo!


    Bei mir läuft projectx 0.90.3.01/31.01.2006 mit blackdown JDK 1.4.2.03 unter Gentoo Linux.


    Bei VDR muss ich allerdings das bei vdrconvert 0.2 mitgelieferte projectx in /usr/share/projectx/pX/ benutzen, und zwar unbedingt 0.90.2.00/05.11.2005 in PX.jar und nicht 0.82.1.02/07.05.2005 in pX.jar. Das kann man in /etc/vdr/vdrconvert/vdrconvert.global eintragen:

    Code
    #OLDPX="no"
PX="/usr/share/vdrconvert/pX/PX.jar"
PXINI="/usr/share/vdrconvert/pX/PX.ini"


    (Achtung! klein- und GROSSschreibung bei PX.jar und PX.ini beachten!! pX.jar und pX.ini - ich denke, das ist "OLDPX" - ging bei mir nicht.)


    Viel Erfolg!

  • AC3 Tonaufnahme ok, DVD aber ohne AC3/DD gebrannt


    Ähnliches Problem bei mir: Bei Harry Potter II, Tomb Raider (beides ZDF) klappt AC3 nicht, Star Trek Nemesis (SAT.1) funktioniert. Ich verwende VDR 1.3.36 und vdrsync 0.1.3PRE1-050322.


    Mit debug-Option kommen jede Menge dieser Meldungen:
    ...
    No Audio syncword found for stream bd, searching for audio sync
    1111111100101110 found, 0000101101110111 expected


    AC3 regex matched at 206
    ...


    Dem Source-Code nach prüft vdrsync bei einem AC3-Frame, ob am Anfang auch die richtige Kennung steht. Das ist offenbar nicht der Fall, darum sucht es danach und findet es schließlich bei Offset 206 (anfangs einmal bei 6).


    Wie kann es sein, dass ZDF anscheinend in einem anderen Datenformat sendet als andere Sender? Ist das nicht genormt?


    Weiß jemand, was mit Doc (Entwickler von vdrsync) los ist? Seit letzten August totale Funkstille auf vdr-portal.de. Der könnte doch am ehesten helfen.


    Gruß, Womble

  • [tvtime] Grüne Streifen beim abspielen von VDR Aufnahmen

    Zitat

    Original von soave
    Grüne Streifen bei Platten Zugriff.


    Kannst du einen Überblick über dein System geben? (TV-Karte, Grafikkarte, CPU,
    Kernel, TV-Viewer-Programm)


    Zitat

    Original von soave
    Ich benutze den VGA-Ausgang der Grafikkarte am Frernseher.


    Ich nehme an, du meinst TV-Ausgang?


    Ich denke, wir haben zwei Fragen zu klären:
    [list=1]
    [*]Wo in der Kette vom digitalen Videostrom bis zur Erzeugung des Bildsignals
    schleichen sich die Streifen ein?
    [*]Was ist die Ursache dafür?
    [/list=1]


    zu 1:
    [list=a]
    [*]Erster Test wäre mal, ob die Streifen schon so vom Video-Grabber-Device (z. B. /dev/dvb/adapter0/video0) geliefert werden. Kann das mal jemand mit xawtv im Overlay-Modus testen? Dabei schreibt die TV-Karte direkt in den Grafikkartenspeicher. Ich kann's nicht testen, weil bei mir dann immer das System einfriert (siehe dazu: http://tvtime.sourceforge.net/problems.html#overlay)
    [*]Ich vermute, mit xawtv (+ Overlay) gibt's die Streifen nicht. Ich hab mit tvtime jede Menge Screenshots gemacht (tvtime-command screenshot "Dateiname.png"). Ein paar enthalten auch die Streifen.
    [*]Der Screenshot wird von tvtime aus einer Kopie des aktuellen Frames im Hauptspeicher erzeugt, welche unmittelbar davor auch für die Ausgabe auf die Grafikarte verwendet wurde. Da in der Hauptspeicherkopie die Streifen schon drin sind, kann's nicht auf dem Weg in die Grafikkarte passieren.
    [*]Dass tvtime die Streifen einbaut, glaube ich auch nicht. Bei hoher Last oder viel I/O arbeitet der Algorithmus vielleicht langsamer und es gehen ein paar Bilder verloren (kann man ja ab und zu beobachten), aber Daten verfälschen...
    [*]Die Streifen dürften demnach schon vom frame grabber device (/dev/video0) geliefert werden. Ein Frame wird von dort bei tvtime über einen einzigen ioctl()-Aufruf in einen Arbeitspuffer im RAM kopiert. Da kann tvtime eigentlich nichts falsch machen. Der Schaden entsteht also irgendwo in der Hardware, den Treibern oder Systemaufrufen.
    [/list=a]


    Soweit meine Schlussfolgerungen (unbewiesen).


    zu 2:
    [list=a]
    [*]Vergesst erst mal meine frühere Theorie mit dem Stau auf dem PCI-Bus. Die neue:
    [*]Es gibt irgendwo in den Treibern Timing-Probleme, durch die ein paar Bits durcheinanderpurzeln, wenn grade viel los ist in der Kiste.
    [/list=a]


    Hier noch ein paar Beobachtungen und --> Schlussfolgerungen:
    [list=1]
    [*]Experimente mit PCI latency timer konnte ich nicht durchführen (bietet mein Mist-Uralt-BIOS nicht an), verschiedene Einstellungen bzgl. AGP (z. B. von 4x auf 1x zurückgestellt) haben nichts bewirkt.
    [*]Viele berichten, dass die Streifen v.a./nur bei Platten-IO auftritt und nur beim Abspielen, bei mir statt dessen hauptsächlich, wenn Grafikausgabe durchgeführt wird (besonders schlimm: Firefox) und auch beim Live-Schauen. Wenn im VDR eine Aufnahme geschnitten wird (viel IO!), gibt's kaum Streifen.
    [*]An der IRQ-Verteilung liegt's nicht. Hab die TV-Karte mal umgesteckt, sodass sie bei mir nicht mehr auf demselben Interrupt liegt wie die Grafikkarte. Keine Veränderung.
    [*]Habe X11 (xorg 6.8.2) mal mit nv statt nvidia Treiber gestartet, gab nur noch wenige Streifen, aber ganz weg waren sie nicht --> stützt die Treiber-Theorie
    [*]Streifen sind übrigens nicht einfach grün. Wenn man den Screenshot (s. Ausschnitt in der Anlage) anschaut, erkennt man, dass nur dunkle Stellen grün sind, je heller, desto mehr geht's Richtung Magenta. --> Kann es sein, dass hier im YUV-Farbmodell (bzw. YCbCr) die Luminanz- (Y, Helligkeit) und Crominanz- (Cb, Cr, Farbton) Komponenten vertauscht werden? Zur Info: http://de.wikipedia.org/wiki/YCbCr-Farbmodell. Vielleicht liest ein (DVB-)Treiberentwickler mit und es macht jetzt Klick bei ihm ;)
    [*]Vermutlich treten die Streifen nur auf, wenn vor der Darstellung die Videodaten vom Grabber-Device im Speicher weiterverarbeitet und nicht direkt von TV-Karte zu Grafikkartenspeicher transferiert werden. Das ist wohl hauptsächlich tvtime. (Kann das jemand bestätigen oder widersprechen?) --> Streifen nur, wenn der Treiber (DVB oder V4L?) die Bilder ans frame grabber device liefern muss und sie von dort übernommen werden.
    [*]Streifen hatte ich auch schon mit einer analogen bttv848-Karte. Das Problem muss also in einer HW-unabhängigen Treiberschicht liegen.
    [/list=1]


    So, kann jemand was mit der ganzen Info anfangen?



    Gruß, Bernd


    P.S.: Das nächste Posting wird kürzer ;)

  • [tvtime] Grüne Streifen beim abspielen von VDR Aufnahmen

    Hallo, hab das Problem auch.


    Zitat

    Original von dad401
    Auch wenn der Thread schon "uralt" ist - ich habe dieses Phänomenen (grüne Streifen bei der VDR-Wiedergabe) kürzlich bei einer s/w-Aufnahme (Pleasentville) festgestellt. Bei normalen (farbigen) Aufnahmen merke ich nichts davon. Die Streifen waren aber auch nur minimal und ab und zu aufgetreten.


    Welches ist dein Ausgabegerät? TV-Ausgang oder Anzeige über Programme wie xawtv, fbtv etc.? Beim TV-Ausgang würde es mich wundern, hab ich aber bei mir noch nicht ausprobiert.



    Zitat

    Original von dad401
    Ich sollte nochmal einen s/w-Film aufnehmen um das zu testen...


    Spar dir das. Kann man wohl auch für die vorhergehenden Versuche bezgl. Plattenaktivität sagen. Ich tippe auch wie weiter oben schon erwähnt auf den PCI-Bus. Das ist die größte Gemeinsamkeit aller hier genannten System-Ausstattungen. Meine ist:


    HW: 900 MHz AMD Thunderbird, 768 MB RAM (SDRAM), Nexus-S rev. 2.3, nVidia GeForce 2 MX
    SW: aktuelles stable (x86) gentoo, Kernel 2.6.xx-gentoo-rx, xorg-x11, KDE 3.4.x, testing (~x86) VDR (z. zT. 1.3.36), tvtime 1.0.2


    Meine Beobachtungen:

    • SW-Versionen sind uninteressant. Streifen waren auch mit allen älteren Versionen da.
    • Ist aber heftiger geworden, seit mein System von gcc 3.3 auf 3.4 umgestellt hab. Vielleicht reizt das die HW besser aus --> mehr Traffic auf'm PCI-Bus --> mehr Streifen (wenn Firefox Seiten auf den Bildschirm zeichnet, auch beim Scrollen - also ohne Platten-IO - ist's besonders heftig)
    • Unter Windows gab's die Streifen auch schon, mit DScaler (von dort sind AFAIK die Deinterlacer in tvtime übernommen worden)
    • Auch mit 'ner analogen Studio PCTV hatte ich schon die Streifen --> müssen sich also irgendwo auf dem Weg von /dev/video0 bzw. /dev/dvb/adapter0/video0 in auf den Bildschirm (bzw. in den Grafikspeicher) einschleichen.


    Hat schon jemand beim tvtime-Entwickler nachgefragt, ob der was dazu sagen kann?


    Könnte mir das allerdings eher so vorstellen:

    • tvtime übergibt ein fertig bearbeitetes komplettes Einzelbild an X11, um es in den Speicher der Grafikkarte zu klatschen
    • X11 gibt diesen Byteblock an den Grafiktreiber (bei mir Kernelmodul nvidia.ko) weiter
    • Der Treiber sagt der Grafikkarte: Hey, ich hab was, um einen rechteckigen Bereich zu füllen!
    • Die Grafikkarte sagt: OK, rüber damit, aber schnell, bevor ich das nächste Videobild generieren muss!
    • Leider ist auf'm PCI-Bus (dazu gehört doch letztendlich auch der AGP) die Hölle los, sodass einige Daten zu spät ankommen.
    • Die Grafikkarte sagt: Hmm, da fehlt was, dann stelle ich halt meine Default-Farbe dar (z. B. grün)


    Ich hab kaum Erfahrung mit der Programmierung auf dem Zahnfleisch (hardwarenah mein ich). Ihr könnt mich gerne auslachen, solange ich mich schlauer macht und erklärt, wie's wirklich zugeht zwischen Treiber und Grafikkarte ;)


    Werde bei Gelegenheit mal an den BIOS-Einstellungen spielen, melde mich dann wieder.