Beiträge von Urig

    Ich tippe auf das devfs, was du vermutlich benutzt. /dev/dvb/adapter0/video0+audio0 klingt für mich jedenfalls nach devfs. Vielleicht glaubt deswegen der mplayer, er hätte ein Ausgabegerät gefunden.


    Sicher, dass das --disable-dvb geklappt hat?

    Darf ich mal dazwischen werfen, dass das System zu jeder PCI-Karte genau weiss, in welchem PCI-Slot sie steckt? Die Slots können also nicht alle gleich sein, und nur durch das verwürfeln der IRQ-Leitungen kann man die Slots auch nicht alle unterscheiden.


    Ich gehe davon aus, dass zumindest eine Leitung zur exklusiven Ansteuerung jedes PCI-Slots existieren muss. Da früher immer nur ein Teil der PCI-Slots Busmaster-fähig waren, liegt die Vermutung auch nahe, dass Busmaster-PCI ebenfalls eine separate Leitung pro Karte zum Chipsatz benötigt.


    Um zwei Karten in einem Slot zu betreiben, ist traditionell ein PCI-to-PCI Bridge-Chip erforderlich, der sich zum PC hin als ein PCI-Gerät meldet, auf der Steckkarte aber einen komplett neuen Bus zur verfügung stellt. (Dieser Bridge-Chip ist sogar erforderlich, wenn sich zwei PCI-Chips eine Steckkarte teilen.)


    Die VIA-Riserkarten sind speziell für VIA-Systeme gebaut, nutzen daher vermutlich eine selbst definierte Erweiterung, um zwei logische PCI-Steckplätze über einen Stecker zu leiten. Die 2x Riserkarten benötigen auch ein angepasstes BIOS.

    Danke so weit erst mal.


    Es scheint, als ob zumindest bei den FF-Karten immer ab der Adresse 0EC die gleiche Zahlenfolge steht: 00 00 00 f0 24 00 09. Bei den Budgets wechselt das interessanterweise. Jedenfalls liege ich wohl nicht falsch, wenn ich die Zahlenfolge einfach kopiere. ;)



    Habib:
    > multimedia:/proc # hexdump -C dvb-eeprom0
    > 00000000 00 03 13 c2

    Das ist eine Technotrend/Hauppauge PCI rev2.1 or 2.2 (Hauppauge WinTV-Nexus)


    > multimedia:/proc # hexdump -C dvb-eeprom1
    > 00000000 10 03 13 c2

    Das ist eine TT-Budget/WinTV-NOVA-S PCI (budget S)


    Thomas:
    > 00000000 00 00 13 c2
    Das ist eine Siemens/Technotrend/Hauppauge PCI rev1.3 (premium S)
    (zumindest laut Linux-treiber)


    > 00000000 4f 61 11 31
    Das (vollkommen anders aufgebaute) ROM gehört einer Fujitsu-Siemens Activy DVB-S budget


    Und schliesslich Dirk:
    > linvdr proc # hexdump -C dvb-eeprom0
    > 00000000 00 00 13 c2

    Siemens/Technotrend/Hauppauge PCI rev1.3 (premium S)


    > linvdr proc # hexdump -C dvb-eeprom1
    > 00000000 00 03 13 c2

    Technotrend/Hauppauge PCI rev2.1 or 2.2 (Hauppauge WinTV-Nexus)


    > linvdr proc # hexdump -C dvb-eeprom2
    > 00000000 10 04 13 c2

    TT-Budget/WinTV-NOVA-C PCI (budget C)


    Gruß & Dank,


    Udo

    > Nicht das es die 2. Karte (Hauppauge Nova) ist...


    <seufz> Das hatte ich befürchtet... Das ROM hat die Subvendor-Kennung 13c2:1003, das ist die Kennung einer Budget-Karte, r2.1...
    Ich war mir selbst nicht ganz sicher, welche Karte den Eintrag kriegt, wenn mehrere da sind. Offensichtlich die letzte.


    Ich hab nochmal den Patch überarbeitet, diesmal gibts /proc/dvb-eeprom0 .. /proc/dvb-eeprom3, je nach Anzahl der Karten.


    Gruß & Danke,


    Udo

    Habs gefunden.


    Der Vollständigkeit halber hier auch noch mal die drei Hexdumps:

    Die Hauppauge 1.3 hat schon mal ab 00EC die gleiche Zahlenfolge 00 00 00 f0 24 00 09, wie meine Siemens 1.3. Die Hauppauge Nova hat dagegen ein 41 77 20 fa, und die Activy ist sowieso ein Kapitel für sich.


    Ein paar neuere Revisionen der FF DVB-S wären jetzt noch nicht schlecht...


    Gruß,


    Udo

    Anscheinend wurde mplayer nicht gefunden.


    Der Patch verwendet als Default den selben Pfad wie das Original: /usr/local/bin/mplayer. Alternativ kann dem Server über -M der Pfad zu einer mplayer.sh (wie als Beispiel dabei) mitgegeben werden.


    Gruß,


    Udo

    Hi.


    In Fortsetzung meines letzten eeprom-Topics bitte ich nochmal um ein wenig Mithilfe.


    Mittlerweile habe ich einen Treiberpatch zum Lesen und Schreiben des I2C-eeprom's entwickelt, nun fehlt mir nur noch etwas passendes, um es hinein zu schreiben. Deswegen die Bitte an die experimentierfreudigen unter euch, die ROM-Inhalte hier zu posten oder mir zuzuschicken.


    Der angehängte Patch rüstet den Zugriff auf das eeprom beim DVB-Treiber nach. Entwickelt hab ich ihn auf dem 20031108 Treiber, getestet unter Kernel 2.4. Der Schreibzugriff ist sicherheitshalber deaktiviert, damit keiner seine Karte zerschiesst.


    Mit geladenem Treiber kann das eeprom aus der Datei /proc/dvb-eeprom gelesen werden. Der Inhalt kann direkt mit cp kopiert werden, oder zb. mit hexdump -C /proc/dvb-eeprom sinnvoll angezeigt werden.


    So sieht die Ausgabe bei einer Siemens Rev. 1.3 Karte aus:

    Ab 0000 befindet sich die Konfiguration des SAA7134, ab 0080 ein Copyright-String, ab 00CC die MAC-Adresse. Ab 00EC stehen noch ein paar unbekannte Daten, sonst ist das ROM leer. ('*' steht für sich wiederholende Zeilen.)


    Um noch ein wenig besser zu verstehen, was in dieses ROM rein muss, wären ein paar mehr ROM-Inhalte (zusammen mit Infos was für eine Karte es ist) sehr hilfreich.


    Gruß & Dank,


    Udo


    ***Update***
    Aktualisierter Patch weiter unten

    Wird meisst per Kommandozeilenparameter --statisticfile=/video/noadstat (o.ä.) geschrieben. Schau mal, ob /video/noadstat existiert, dann loggt deiner auch schon.


    <edit>teufel, seite 2 übersehen</edit>


    Gruß,


    Udo

    Gleiche mplayerclusterkeys.conf, keine Probleme.


    Die Datei muss auf dem Client-Rechner im Plugin-Verzeichnis (Default /video/plugins) liegen. Und ohne NFS-Verbindung kann der mplayer sowieso nicht seeken.
    (und da im NFS-Code bei 0.0.1a noch ein Bug drin ist, empfehle ich meine gepatchte Version. ;) )

    Ist schon ein 266er Typ. Die CPU-Leistung scheint ja auch nicht das Problem zu sein.


    In deinem Beispielfall werden 19% der Frames analysiert. In HoppaZ's Sammlung werden etwa 15-25% der Frames analysiert. Bei mir sind es dagegen regelmässig 30-60%. Ich werd wohl noch mal an den Optionen kräftig schrauben müssen.


    Gruß & Dank,


    Udo

    Danke. Das gibt immerhin ein bisschen Klarheit.


    Dekodierte Frames / Gesamtrechenzeit ist bei dir 22891/488 = 46.9fps. Ich erreiche bei diesem Wert normalerweise rund 28-33fps. Das ist realistisch.


    Nur: Bei dir wurden 22891 Frames analysiert bei rund 80min Videomaterial.
    Die Durchsicht meines Archivs ergibt für rund 80min-Jobs: 49938, 53741, 48192, 63068, 49489, 64827, 40488, 49548, .....


    Warum ist noad bei mir so gründlich? Welche Optionen verwendest du?


    Gruß,


    Udo


    PS: Aktueller Negativrekord: 66 Minuten Material haben 51 Minuten Analyse gebraucht. 64728 dekodierte Frames. :(

    Na, das klingt doch prima.
    Dann werd ich mich mal dran machen, den Code für's Schreiben des eeproms zu basteln.


    Nebenbei: Gibt es irgend eine Möglichkeit, von einem normalen Programm aus an den I2C-Bus des SAA7146 dran zu kommen? Konnte in den Interfaces bisher nichts finden.
    Bei meinen bisherigen Versuchen hab ich den DVB-Treiber gepatcht und zweckentfremdet, um an den I2C-Bus zu kommen, aber es muss doch auch elegantere Möglichkeiten geben, oder?


    Gruß,


    Udo

    Hi an alle Hardware-Experten.


    Ich versuche gerade die Möglichkeit auszuloten, das Konfigurations-EEProm am I2C-Bus der TT DVB-S Karten zu beschreiben. Diese EEProms haben einen Schreibschutz-Pin, von dem ich nicht weiss, womit er verbunden ist.


    Ok, von Anfang an:
    Auf den TT DVB-S Karten ist ein I2C-EEProm vom Typ 24C16 verbaut, in dem die Initialisierungsdaten des Philips SAA7146 und Konfigurationsdaten wie die MAC-Adresse der Karte und der Herstellername abgelegt sind. Da ich hier eine Karte habe, bei der dieses EEProm leer zu sein scheint, würde ich gerne dieses EEProm beschreiben.


    Diese EEProms haben eine Leitung, um den Chip auf Schreibschutz zu stellen. Ein Kommentar in den DVB-Treibern deutet darauf hin, dass dieser Schreibschutz auch aktiv ist. Da der Baustein ja vom Hersteller auch beschrieben werden muss, vermute ich, dass der Schreibschutz per Software oder per Kontakt deaktivierbar ist.


    Den Baustein hab ich auf der Karte bereits gefunden, komme aber nicht weiter, da nicht zu erkennen ist, wo die Leitung weiter hin führt. (ich tippe darauf, dass es die Leitung ist, die oberhalb des Chips herus kommt, und über einen Widerstand an GND geht.) Hat vielleicht jemand hier schon mal die Leitung zurückverfolgt, bzw. kann an einer kaputten Karte etwas grosszügiger Testen, wohin die Leitung geht?

    Danke im Voraus,


    Udo

    03:15 - Alle Sender einwandfrei. Pro7, Sat.1, Kabel1, N24, Tele5... Auch die jeweiligen Schweizer/Österreicher Varianten ohne Probleme.


    Eventuell bei dir Empfangsstörungen durch DECT-Telefone?

    > (Meldung: Mountpoint nicht gefunden).


    Das Verzeichnis /video1 muss vor dem mounten schon als leeres Verzeichnis existieren, sonst kannst du die Partition da nicht hin mounten.

    RavenIV:
    Die DVB-Karte kann nur mpeg ausgeben, deswegen muss auch mplayer das Video in mpeg1 komprimieren und an die Karte weitergeben. Es macht also keinen wesentlichen Unterschied aus, ob der Videoplayer die Daten direkt an die DVB-karte gibt, oder über den Umweg Player->Plugin->VDR->DVB.


    schMA:
    Auf meinem VDR-Rechner gibt es gar keinen mplayer, und mplayercluster läuft ohne Probleme. ;)

    Dass VLC direkt auf der DVB-Karte ausgeben kann, ist eigentlich gar nicht nötig. Mit einem geeignetem Plugin würde es reichen, wenn VLC das Video in mpeg2-pes transkodiert und per Pipe, TCP/IP-Stream o.ä. an das VDR-Plugin weitergibt. VDR-Player-Plugins können PES-Streams direkt ausgeben. (das alte mplayercluster-Plugin arbeitet so)


    Fehlt nur noch jemand, der das Plugin schreinbt. ;)

    Versuch mal vom VDR-Rechner aus den recode-server per netcat zu erreichen:


    netcat serverrechner 2003


    Der Server sollte dann ein 'connected to client' melden, und netcat sollte die Buchstaben 'MPCL' ausgeben. Wenn das nicht klappt, gibts noch ein Netzwerkproblem.


    Je nach Distribution heisst netcat eventuell nc.