Posts by SHF

    Xine (ich meine hier den "original" Mediaplayer) kann auch Videos in schneller abspielen mit Ton.

    AFAIK ist der Ton per default beim schnellen Vorlauf aber aus.


    Über das VDR-xineliboutput-plugin kann man auch den Xine-Mediaplayer als Ausgabedevice für den VDR verwenden.

    (Eingabeplugin für den Player ist beim VDR-xineliboutput-plugin dabei.)

    Ton gibt es im VDR beim schnellen Vorlauf bei mir natürlich nicht.


    Der Unterbau sollte es also eigentlich können, ob man die Plugins grösser anpassen muss, kann ich aber nicht beurteilen.

    Wo die Ausdrücke wie "XINE_EVENT_INPUT_MENU6" definiert sind, ist mir tatsächlich völlig rätselhaft.

    Das muss irgendwie von Xine kommen, da kommt ja das ganze Menü her.


    Habe ein wenig in den Keymapsettings rumgespielt und schon war der F5-Zauber vorbei. In den keymaps settings in der xine-ui ein Reset gemacht und dann war gar kein vdr-menü mehr erreichbar.

    "XINE_EVENT_INPUT_MENU6" scheint mit dem Eintrag

    Code
    1. # jump to Angle Menu
    2. AngleMenu {
    3.     key = F5
    4.     modifier = none
    5. }

    in der keymap definiert zu sein.



    In meiner keymap gibt es unten eine Menge VDR... Einträge, alle standen auf "VOID".

    (Keine Ahnung wo die her kommen, bislang sind die mir noch nicht aufgefallen.)


    Der folgende Eintrag aktiviert aktiviert bei mir "zurück" auf der "Backspace"-Taste.

    Code
    1. # VDR Command back
    2. VDRBack {
    3.     key = BackSpace
    4.     modifier = none
    5. }

    Es geht also auch unter Kine-UI.


    Wieso diese Taste "out of the Box" nicht geht, wo doch alle anderen sinnvoll belegt sind, verstehe ich auch nicht.

    Eventuell schlicht vergessen und keiner hat's gemerkt? Die meisten werden wohl vdr-sxfe einsetzen und da geht es ja.

    Vielleicht trivial, aber meine Beobachtung bei den üblichen deutschen FTA-Kanälen ist:

    "Neue" EPG-Einträge gibt es typischer Weise einmal täglich morgens um 6. Dabei wird ein kompletter neuer Tag angehängt.

    Über den Tag wirft der VDR veraltete Events nach und nach raus.

    Wirkliche Änderungen/Aktualisierungen treten eher selten auf (bei vielen Sendern auch nie).

    Ausnahme Now/Next-Event für die laufende/nächste Sendung, die ändern sich ständig.


    Ich weiss zwar nicht genau, wie das intern abläuft, aber auf irgendeine dieser Änderungen wird die Abfrage wohl ansprechen.


    Sofern niemand eine bessere Idee hat, wird man wohl die einzelnen Events vergleichen müssen, befürchte ich.

    Eventuelll hilft es einen HDMI-Extender zwischen zu schalten.

    Bei mir hat der Trick die Verbindung zwischen Fernseher und Laptop erst ermöglicht.


    Bei dem Grünstich würde ich auf ein Missverständnis beim Farbformat tippen.

    RGB vs. YCbCr ?

    Gibt es ein Firmware-Update für den Beamer?

    Ja, das ist etwas lästig, deshalb verwende ich üblicherweise meine Fernbedienung auch bei der Ausgabe über Xine.


    Meine Vermutung ist eher, dass die Backspace-Taste in Xine nicht (oder anders) belegt ist.

    Auch in der "virtuellen" Fernbedienung (Menu -> Menues -> Navigation) fehlt eine "Back" Taste.


    Eventuell klappt es "Back" auf die "Menu6", das müsste "F5" entsprechen, zu legen.

    Code
    1.   {XINE_EVENT_INPUT_MENU5, "Blue"},+ {XINE_EVENT_INPUT_MENU6, "Back"}, {XINE_EVENT_INPUT_NUMBER_0, "0"},

    (ungetestet)

    Um es mal systematisch anzufangen:

    Trifft es einige Kanäle/Transponder besonders häufig? Oder welche nicht? (High/Low-Band, horizontal/vertikal)

    Trifft es alle Tuner oder nur manche?


    Wenn sich da keine Zusammenhänge finden lassen, wirst du wohl aufs Dach müssen, befürchte ich. Oder es liegt in der Verkabelung.

    Wenn an der Software nichts geändert wurde, würde ich die eher ausschliessen. Und selten gehen alle Tuner gleichzeitg kaputt.

    Die F-Stecker auf Korrosion und dgl. prüfen, besonders im Aussenbereich.

    Weggegammelte Kabel im F-Stecker sind quasi der Klassiker...


    Wie sieht überhaupt die Anlage aus?

    SCR-LNB oder LNB und SCR-Multischalter getrennt?

    Der Wert für QUAL schwankt zwischen 28 und 32, ich kann aber nicht bewerten wie gut (oder schlecht) das ist.

    Die Werte sind leider alle extrem Karten/Tuner abhängig.

    Die Werte von Uwe sind nicht weit daneben (zumindest selbes Frontend-IC), eine Bewertung ist eigentlich aber nur möglich, wenn man weiss, wo bei der Karte "schlecht" anfängt.

    vdrpsend plug femon infoKann man auch die Device-Nummer mit geben.

    Zunächst, mir ist schon bewusst, dass da einiges probiert wurde und das von Leuten, die sicher deutlich mehr Ahnung bei dem Thema haben als ich Gelegenheitsbastler.

    Wenn das alles Trivialitäten sind, die eh schon alle versucht wurden, dann Schwamm drüber ...


    Ich kenne EEPROMs, wo man zum Feststellen des erfolgten Schreibens solange Lesen muss, bis die Schreibdaten wieder gelesen werden (und nicht Daten mit invertiertem unteren Bit, aber immer mit ACK).

    Das AT24HC02C antwortet in dem Zustand gar nicht mehr (Datenblatt 7.3 Acknowledge Polling), zumindest habe ich das so verstanden.

    Auf das Datenblatt bin ich gestossen, weil ich für den Fall (ausbleibendes ACK nach Adresse) ein Beispiel suchte wie zu Verfahren ist.

    Das IC selber habe ich nie verwendet, aber das Vorgehen, ab dem letzten START erneut zu beginnen, hat bislang ganz gut funktioniert.


    Hast Du Patches oder zumindest konkrete Ideen, das anders besser zu loesen?

    Mein Vorschlag ist, im Falle eines NACK beim letzten START erneut zu beginnen.

    Im Falle des Demod also nicht vorher das Register erneut schreiben.

    Wurde das so schon mal versucht?


    Das sollte eigentlich universell funktionieren und der Demod hätte genug Zeit sich zu sortieren.

    Ich habe ein Datenblatt und ein UserManual fuer den SAA7160, die sind leider nicht so ausfuehrlich und hilfreich, wie man sich wuenschen wuerde. Aber ich bin mir ziemlich sicher, dort nicht ein Status-Bit uebersehen zu haben. Was nicht heißen muss, dass es das nicht doch gibt und nur nicht dokumentiert ist (oder ich mittlerweile alt und senil bin).

    Ich wollte dir da keinesfalls zu nahe treten, aber ohne Datenblatt bin ich halt auf Vermutungen angewiesen. Also bitte nicht übel nehmen.


    Irgendwie muss man aber doch raus finden können, ob das Schreiben auf ein Target erfolgreich war. Oder bekommt man es nur mit, wenn ein Fehler auftritt?

    Aber auch da muss man wissen, wann der Transfare beendet ist, sonst muss man warten und hoffen, dass es lange genug war. Ziemlicher Schrott wäre das...

    (Bei dem Teil vom Treiber steige ich ohne Datenblatt nicht wirklich durch, sorry.)

    Die beobachteten Probleme ließen sich immer auf ein NACK beim Wechsel vom Write zum Read auf dem selben IC zurueckfuehren. Deshalb wird eine zusaetzliche Wartezeit vor dem Repeated-Start eingefuegt. Ein Stop-Bit gehoert da nicht hin (waere aber eventuell auch ein denkbarer Workaround).

    Ich hatte vermutet, dass da noch ein anderes Target auf dem Bus was sendet und dadurch Chaos entsteht und das ACK ausbleibt.

    Aber wenn die Wartezeit nur an der Stelle eingefügt wird, ist das wohl auszuschliessen. Ich war bei dem Patch nicht sicher, weil da an einigen Stellen das Timing geändert wurde.


    Sollte das Stop-Bit an der Stelle nicht eher das Target zurücksetzen?

    Versuchen kann man es trotzdem.

    Offenbar kann der Demod den Read nicht durch Clock-Stretching verzoegern (die eigentlich saubere Loesung nach I2C-Spec, die aber nicht kompatibel ist mit SMB und generell auch nicht schoen).

    Clock-Stretching ist optional und können auch nicht viele Target-ICs.

    Ein NACK zu senden, wenn das Target-IC "busy" und nicht in der Lage ist sinnvolle Informationen zu liefern, ist aber auch standardkonform (zumindest interpretiere ich das so).

    Bei EEPROMs ist das beim Schreiben so üblich, dass sie nicht reagieren (NACK), bis sie das Byte intern geschrieben haben.


    Wie man bei so einem NACK reagieren muss hängt vom Target ab, bei den EEPROMs probiert man es solange erneut, bis es wieder auf seine I2C-Device-Adresse antwortet (ACK).


    Ob es hier reicht den eigentlichen Lesebefehl zu wiederholen, oder ob man die Registeradresse erneut schreiben muss?

    Wenn der NACK schon bei der I2C-Device-Adresse des Leseversuchs kommt, würde ich meinen, es reicht nur den eigentlichen Lesebefehl zu wiederholen. Ist ohne Datenblatt aber nur eine Vermutung.

    Der deshalb noetige Warte-Workaround wird kompliziert, weil der I2C-Controller kein Status-Bit hat, wann das letzte Byte der Read-Adresse geschrieben wurde.

    Ernsthaft? Das kann ich mir eigentlich nicht vorstellen.

    Der SAA7146 hatte so ein I2C-Busy-Bit und der Nachfolger soll keines haben? Ich hab leider kein Datenblatt.


    Irgendwie muss man doch nach schreiben der I2C-Device-Adresse und Registeradresse feststellen können, ob das erfolgreich war.

    Interessant auch, dass der zweite LNB-Versorgungs-IC sich manchmal nicht meldet, wenn kein Stop-Bit zwischen den Zugriffen auf beide ICs (7Bit-Adressen 8 und 9 auf der S2-6400) kommt.

    Das Problem scheint aber nicht so ungewöhnlich zu sein. Dass einige ICs auf ein Stop-Bit beim Wechsel der Adresse bestehen hab ich schon irgendwo mal gelesen.

    Die Kamera ist die hier

    Danke für die Info, ist immer gut zu wissen womit gearbeitet.

    Die Kamera scheint ja inzwischen auch einigermassen brauchbar zu sein.

    Und


    Das einzige, was jetzt noch unschön ist, ist dass die einzelnen Aufrufe von 'raspistill' relativ lange dauern (vermutlich bis Belichtung, Weißabgleich etc. gemessen wurde). Es würde aber eigentlich reichen, das nur beim ersten Mal zu machen und die Werte bei allen weiteren Aufrufen zu verwenden, denn an der Szenerie ändert sich ja so gesehen nichts.

    Daher verwenden sie bei dem Script hier auch feste Werte.

    Das müsste eigentlich gut funktionieren, wenn man die Abstufungen sinnvoll wählt. Zu dunkle und helle Aufnahmen werden ja sowieso bei der Nachbearbeitung entsorgt. Man muss bloss darauf achten, dass es "in der Mitte" zwischen den Aufnahmen keine "Lücken" gibt.

    Und den Weissabgleich während einer Aufnahmeserie zu ändern ist, nach meiner Erfahrung, meist eh keine gute Idee.


    Wenn man tagsüber nicht immer diese extrem langen Belichtungen machen will, könnte das Uhrzeitabhängig machen


    Man könnte auch eine Test-Aufnahme machen, die EXIF-Informationen auswerten und daran die Strategie ausrichten.

    Das müsste eigentlich ganz gut gehen, durch Belichtungszeit, Blende und ISO-Wert ist die Lichtmenge bekannt, wenn nicht einzeln angegeben. Daraus kann man eine eigene Belichtungsserie ableiten. Weissabgleich usw. übernimmt man einfach, sofern es Sinn macht.

    Man muss ja nicht 100% treffen, es geht eher darum nicht unnötig viele Aufnahmen zu schiessen, wegen des Zeitverzuges.


    Eventuell könnte es Sinn auch machen das Histogramm der Test-Aufnahme auszuwerten?

    Ganz aktuell bin ich auf ein merkwürdiges Verhalten vom epgsearch-Plugin gestossen:


    Wenn man versucht den Suchbegriff "Spy City (x)" (ZDF heute Nacht) zu editieren, verschwinden die Optionen der Farbtasten unten im Menü, sobald man über das zweite "y" hinaus geht.

    Die Farbtasten (löschen,...) funktionieren aber weiterhin.


    Das ist so bei mir bislang noch nicht aufgetreten.

    Meine Installation ist nicht mehr aktuell, wenn es jemand mit aktuellem Software-Stand probieren will, bis 2:10 ist Gelegenheit dazu.
    Ich schaff das heute Abend auf die schnelle leider nicht (kein Testsystem einsatzbereit).


    Einfach "Suche anlegen" und in der Zeile mit dem Suchbegriff ein paar mal nach rechts drücken.

    Avidemux und Handbrake hatte ich auch schon erwähnt.

    Letztendlich sind beide aber auch nur (teilweise gibt es noch ein paar extra Filter) Frontends zu Ffmpeg. Wenn man Dokumentation zu den Filtern sucht usw., landet man am Ende dann eigentlich immer bei Ffmpeg.


    Wenn man schneiden und mit den Einstellungen rum probieren will, mache auch ich das mit Avidemux ganz gerne.

    Wenn ich viele ähnliche Dateien umwandeln will, dann lieber mit Ffmpeg direkt. Das geht schneller als sich immer durch die Menüs zu klicken.

    Das schöne ist, dass man die Filtereinstellungen übertragen kann. Deshalb auch meine Angabe für Ffmpeg direkt, da hast du in einer Zeile alles drin, was man braucht. Die Parameter kann man, bei Bedarf auch einfach bei Avidemux und Co in der Oberfläche eingeben.



    Btw.:

    Gibt es eigentlich eine Möglichkeit bei den PVR-Karten die Qualität oder Bitrate zu beeinflussen?

    Mit dem -crf stellst du die Qualität und damit auch die Grösse der Aufnahme ein.

    22 ist eher hochwertig, erhöhen macht die Datei kleiner.


    Sinnvoll sind Werte von 20 bis 27, 28 etwa. Man muss da etwas probieren, wir hoch man gehen kann. Das hängt vom Geschmack und Ausgangsmaterial ab.


    Bei verrauschtem Material, ich schätze alte Videos müssten dazu zählen, kann ein Rauschfilter wie nlmeans oder hqdn3d einiges bringen, was Dateigrösse und Qualität angeht.

    Einfach immer drauf loslassen ist aber auch keine gute Idee. Bei gutem Material kann auch einiges kaputt machen und die Einstellung muss man auch durch probieren ermitteln.

    Bedeutet das, dass es Sinnvoll ist, mehrere Durchgänge laufen zu lassen "vor dem Kodieren deinterlaced" als ein Durchlauf und das Ergebniss wird zum fertigen Video. Könntest du kurz erwähnen wie du das meinst und vielleicht noch mit welchen (Linux o. Windows) Tools du das umsetzt?

    Das geht natürlich in einem Durchlauf.

    Wichtig ist halt nur den Deinterlace-Filter als erstes in der Kette zu verwenden, sonst gibt es diese hässlichen Streifen.

    (Beispiel mpeg2 -> .mkv HVEC direkt mit FFMPEG)

    ffmpeg -i input.mpg -vf bwdif=mode=0 -c:v libx265 -crf 22 -preset medium -c:a aac -ab 96k output.mkv

    Was für Filter bei (eher schlechtem) VHS-Ausgangsmaterial Sinn machen musst du aber selber probieren, da hab ich keine Erfahrung.

    Die Doku von FFMPEG ist aber eigentlich ganz gut, ich hab im Netz bislang immer was gefunden, was mich weiter gebracht hat. Etwas probieren wird aber dabei sein, das Ausgangsmaterial und die Geschmäcker sind einfach zu unterschiedlich.


    Es gibt aber viele Alternativen, handbrake mit GUI, oder transcode hier im Portal, um nur die zu nennen, die mir spontan einfallen.


    Mit dem "yadif" Deinterlacer hatte ich seit einiger Zeit bei manchen Aufnahmen Probleme (komische Geisterbilder), daher "bwdif" im Beispiel.

    Der ist für mich ein guter Kompromiss zwischen Laufzeit und Qualität. Wenn es besser werden soll, wird es deutlich langsamer.

    Hierzulande ist alles, was SD-TV angeht PAL und immer 50i.

    Das betrifft auch alles an SD-Aufzeichungsverfahren, usw.


    Der Knackpunkt ist dabei das interlaced! Damit das Ergebnis an heutigen Monitoren gescheit aussieht, muss unbedingt vor dem Kodieren deinterlaced werden. Wer nach dem Begriff "deinterlace" sucht findet schnell raus, was ich meine. (Ausserdem können die neuen Codecs können interlaced-Material nicht gut umgehen und arbeiten damit nicht effizient.)

    Das Vorgehen ist das gleiche wie bei SD-TV-Material und ist mit FFMPEG gut umsetzbar. Da gibt es hier im Forum auch einige Themen dazu.


    Zu dem USB-Grabbern hab ich auch nicht viel gutes gehört.

    Einige scheinen das S-Video-Signal auch nicht wirklich zu verarbeiten und es kommt nur VHS-Qualität raus.

    Die mitgelieferte Software ist meist auch nicht wirklich gut.

    Ich würde darauf achten, was zu kaufen, wo der Chipsatz bekannt ist und zu dem es Treiber gibt (am besten auch unter Linux). Dann ist man unabhängig und kann an Software einsetzen, was man will.


    Neben den schon erwähnten PVR möchte noch die alten Conexant/Booktree Bt848/849/878/879 Karten in den Ring werfen.

    AFAIK konnten zumindest einige auch S-Video. Treiber für Linux gibt es und die Karten sind gut dokumentiert. Da gab es einige an Wiki-Seiten und dergleichen.

    Mit den heutigen Prozessoren sollte ein Kodieren und deinterlacen in Echtzeit eigentlich locker machbar sein.

    Es hat jetzt etwas länger gedauert, als ich wollte, aber das Chaos, was ich beim letzten Update angerichtet hatte, war hartnäckig er als gedacht. Nun spricht aber endlich der Compiler wieder mit mir :gap .


    Den Absturz mit leerer Index-Datei konnte ich nicht reproduzieren. Ausschliessen würde ich Abstürze aber aufgrund des Verhaltens aber nicht.

    Die Aufnahmen werden abgespielt (immer von vorne), aber ausser play/pause geht nichts. "ok" liefert auch keine OSD-Einblendung! Fehlermeldungen gibt es aber keine.

    Patch 1 hat demzufolge (logischer weise) bei mir keine Wirkung.

    Das fehlen jeglicher Fehlermeldungen finde ich etwas merkwürdig, irgendwo müsste doch auffallen, dass kein Index-Daten kommen?



    Patch 2 wirkt wie erwartet und startet die Index-Generierung auch, wenn eine 0 Byte Index-File vorhanden ist.:tup