Beiträge von samc

Hallo,

muss das nochmal aufgreifen, weil ich jetzt nach Hardwarewechsel das Problem in ungekannter Häufigkeit habe.

Neue HW:

Asrock K10N78hSLI-1394 mit X2 240e und 2GB RAM, ASUS EN210 Grafikkarte.

Alte HW:

P4 2.66GHz ohne HT mit Intel 7208 chipset, 2.5GB und Sparkle 8400GS PCI

Es kommt jetzt beinahe nach jedem Umschalten zum Flacker, dabei aber unerheblich ob ob ich die automatische 4:3 Erkennung an habe oder aus!

Ich hab so das Gefühl, dass der vdr-xfse output geben könnte der nicht im syslog steht. Hat sich damit jemand mal befasst?

Sonst noch eine Idee?

Grüße,
Simon

Hallo,

vielen Dank, hab das Problem aber gottseidank gerade gelöst.
Hab mir heute Nachmittag einen Sempron abgeholt, den ich bei ebay ersteigert habe...war gottseidank direkt in München.

Es ist ein Asrock K10N78hSLI-1394.
Tatsächlich lief der X2 240e nicht in dem Board, blieb einfach dunkel. Jetzt nach dem Update auf BIOS 1.20 geht es wunderbar!

Braucht jemand einen 3400er Sempron für AM2 ?

Vielen Dank nochmal an Alle!

Simon

Hallo,

hab ein blödes Problem, hab mir alles zusammengekauft um bei meinem VDR den alten P4 zu ersetzen, aber leider gibt es ein Problem:

Das neue Mainboard kann meine neue AM3 CPU aber nur ab BIOS 1.20, drauf ist wohl eine ältere.
Kann also nicht updaten, ohne mal eine ältere CPU reinzustecken...

Deshalb meine Frage:
Vielleicht hat jemand Lust mit mir eine mitgebrachte halbe Bier zu trinken während ich das Update mit der geliehenen CPU mache? Wohne im Münchner Osten...

Viele Grüße,
Simon

Hallo,

hab den Fehler auch, aber nicht so arg häufig. Ich hab mir eine Taste auf die FB gemacht, die das Frontend neu startet...

Tritt auch ohne Senderwechsel auf, aber hatte ich nur 1 oder 2 mal.

Mein Eindruck ist dass es von der automatischen aspect ratio Erkennung kommt, aber hatte noch keine Lust das lange genug abgeschaltet zu lassen um zu reproduzieren.

Wenn das mit autoscaling gemeint ist, dann hat mich mein Gefühl getäuscht, ansonsten kannst das ja mal ausprobieren.

Grüße,
Simon

Hallo,

ich hoffe es liest jemand mit der genau weiss wie das xine-lib-atmo ausgibt..

Würde gerne meine Pixel-Streifen hier mit dem Plugin betreiben, unklar ist mir:

- wieviele Kanäle kann ich da je Seite ausgeben? Ist das frei definierbar oder täuscht das bloß? Hätte diese config:
9
4 4
9

- meine LED Streifen kann ich seriell anschließen. Gibt das Plugin im classic mode mehr Kanäle aus als vorgesehen, oder nur die 5? Gibt es einen anderen seriellen Modus auf dem mehr Kanäle ausgegeben werden? (Die Firmware auf den Streifen kann ich anpassen).

Im Zweifel arbeite ich mich durch den code und mach mir ein eigenes Ausgabeplugin, aber wäre freilich glücklicher wenn das so ginge...

Grüße,
Simon

Hi,

das funktioniert so erstmal wunderbar, aber nach Beenden der Wiedergabe springt er zurück zum Fernseher, was freilich nicht so recht förderlich ist.

Um das zu umgehen, würde ich gern ein "leeres" Programm einstellen, hab aber noch keins gefunden was funktioniert.
Wenn ich einen verschlüselten Sender einstelle, der nicht decodiert werden kann, hab ich zwar schwarzes Bild, aber sobald die Wiedergabe startet, startet auch def VDR neu, leider...

Hat da jemand noch eine Idee zu so einem "leeren" Progreamm?

Grüße,
Simon

Super, der Tip klingt richtig interessant!
Werd ich morgen gleich ausprobieren!

Danke,
Simon

Hallo,

weiss nciht ob ich hier an der richtigen Stelle frage, aber ich versuchs mal:

ich benutze die Musik-Wiedergabe von xineliboutput um zum Einschlafen noch ein Hörspiel anzuhören. Leider lässt sich die loop-Funktion nicht abschalten, dh. das Hörspiel läuft wieder und wieder..

Ich hab schon im sourcecode gesucht, aber irgendwie nicht so die richtige Stelle gefunden...

Hat da jemand vielleicht einen Tip?

Und noch iene Grundsätzliche Frage dazu: schläft der VDR auch dann bei Inaktivität ein, wenn er sich in einer (beendeten == pausierten) Wiedergabe befindet?

Grüße,
Simon

Hi,

für den Fall dass es noch interessant ist:

über die Sache mit der falschen IMAGE_SIZE bin ich auch grad gestolpert:

die GrabImage gibt die Größe der PNG Datei oder was das ist zurück, incl. Header.

Also Pixelzahl*3 + Header.

ImageSize ist nur die Pixelzahl.

==> Allerhöchstens könnte man sicherstellen, dass ImageSize nie kleiner als IMAGE_SIZE*3 ist.

Grüße,
Simon

Hi,

anstatt der ULN... sollten MOSFET Treiber eingesetzt werden, da der Spannungsabfall an den Transistoren sonst mit einer Anpassung der Versorgungsspannung ausgeglichen werden muss. Gängige LED-Module ändern ihren Strom drastisch bei einer um 0,8V geringeren Versorgungsspannung...

Grüße,
Simon

Hi Adama,

ja im Grunde sind die Chips das gleiche. Der wesentliche Unterschied ist allerdings, dass der MAX nur 7V, der aber TLC 17V kann. So können fertige 12V Module direkt angeschlossen werden. (Da gibts viel, zB flexible Streifen mit 3 RGB LEDs an 12V).

Ein weiterer Vorteil ist freilich ich die Dinger rumliegen hab und zwar im DIL-Package...wenn jemand was draus machen verschick ich sie gerne!

Grüße,
Simon

Zitat

Ich halte von allen Schaltungen mit speziellen Treiber IC nichts. Normalerweise sollte ein µC (PIC, ATMega, ..) das alleine schaffen. Ich nehme einen ATMega8 für 4 Kanäle. Den könnte man mit 3 weiteren Dual-FETs auf 6 Kanäle aufbohren. Die Anzahl der Kanäle hängt nur von der Pin-Anzahl ab.

Ja, das war auch der Grund warum die Dinger immernoch bei mir in der Kiste liegen. Allerdings würden die in meinen Augen schon Sinn machen, wenn pro Kanal nur wenige LEDs angeschlossen werden, man also die Ausgangsstufen im TLC nutzen kann, dann sind praktisch keine externen Bauteile mehr nötig. Aber Zeit das zu bauen hab ich ja jetzt auch keine

Grüße,
Simon

Hi,

seinerzeit haben wir mal überlegt den TLC5940 einzusetzen. Der hat auch noch gleich Stromquellen eingebaut und erlaubt es verschiedene LEDs aufeinander zu kalibrieren, dafür hat er nur 16 PWM Kanäle. Wird über SPI bedient. Ein Atmel kann also mehr oder weniger beliebig viele von den Dingern ansteuern.
An den Chip können pro Kanal direkt LEDs aus einer Versorgungsspannung bis 17V angeschlossen werden, dann ohne Vorwiderstände ect...einfach mal durchlesen!
Hab auch noch ein paar hier, die ich leider nie für irgendwas verwendet hab.

Sorry, hab grad erst noch ein bischen nach oben gelesen:
SHF hat mal was gemeint von Strom bei LEDs kurz ein "bischen" erhöhen, das sollte man nicht tun, da der Wirkungsgrad mit zunehmendem Strom drastisch sinkt, ebenso die Lebensdauer!

Grüße,
Simon

Hi,
ja da hast du Recht, das wäre eindeutiger! Willst dus gleich ausbessern im Wiki?

Grüße, Simon

Hi,

mit der PVR250 wirst womöglich Probleme mit Zeitversatz bekommen...hattedie mal unter Win in Betrieb und kann mich da an was erinnern.

Ich werde wohl bald eine Linux-app aus dem atmo-plugin bauen, die selbst von einer bttv Karte liest (sollte in Echtzeit gehen) und atmo drüberrechnet...

Grüße,
Simon

Hi,

ja, das mit Widescreen hast du schon richtig verstanden, hab das eingebaut für meinen Fernseher, weil das ist ein 16:9 Gerät und hat keine auom. Umschaltung. Dh. wenn ein 4:3 Bild dargestellt werden soll kann ich zwar von Hand durch drei Menüs umschalten, dass es mit schwarzen Balken rechts und links dargestellt wird, das ist aber furchtbar unpraktisch. Deshalb habe ich das TV so eingestellt, dass es im Zwifel vom 4:3 Bild oben und unten was abschneidet und so 16:9 draus macht...und dieser Modues heisst eben "Widescreen". Da dieses Feature sicher nur bei einem TV-Signal sinn macht und auf keinen Fall bei einem Monitor (die Dinger kann man ja heut eh nicht mehr zu abschneiden überreden, oder?) kannst du das auch weglassen und keiner ist mehr verwirrt...denke ich zumindest

Die Sache mit dem Fenster find ich aber doch interessant
Grüße,
Simon

Hi,

wieder ein paar Anmerkungen von mir:

Zitat

der CombinedFilter - hingegen berechnet den Farbabstand zwischen alt und neu - ist dieser Gering wird der Percentfilter verwendet -- ist dieser zu groß (Filter_MeanThreshold) - wird die neue Farbe sofort umgesetzt...
(genauer kannst du das in "AtmoOutputFilter.cpp" nachlesen*g*)

es ist genau andersherum:
der percent filter ist eine furchtbar flackerige Geschichte...bestimmt gut für Actionspiele aber eine gemütliche Fernsehsendung wird damit eher unerträglich. Deshalb gibt es den combined filter. Der ist entstanden um die Farben ruhig zu bekommen. Er misst tatsächlich immer den Abstand alte<->neue Farbe und wenn der Abstand unter den threshold fällt wird ein seehr langsames Überblenden angewendet, einstellbar mit dem meanfilter Parameter, die Zahl, glaub 300 in der Voreinstellung, geben die Geschwindigkeit dieses Filters in ms an. Ist der Abstand der Farben gering, also über dem threshold, so Fällt der Filter zurück auf percent filter und blendet mit dessen Einstellung um...das klappt dann normalerweise innerhalb von wenigen Frames -> ein Sprung.

Wenn ihr was weglassen wollt: es reicht normalerweise (ich hab nie mehr umgestellt, seit der combined filter fertig ist) das Proigramm immer mit combined filter rechnen zu lassen. Dann bleiben für den filter noch übrig: percent, mean und threshold. Das sollte einstellbar sein, weil sich da die Geschmäcker erfahrungsgemäß doch unterscheiden.

Übrigens ist eine Beschreibung der Parameter im Wiki zu finden!

Ah, und wenns beim Umschalten auf den 2. Bildschirm Probleme gibt:
es könnte sinnvoll sein den Filter neu zu initialisieren, gibt da eine Variable im Filter, die glaub ReInitialize heisst...einfach auf 1 setzen.

Viele Grüße,
Simon

Hi,

min und max-Werte sind in menu.c vorgegeben:

Zitat

Add(new cMenuEditIntItem(tr(" Edge weighting"), &AtmoSetup.EdgeWeighting, 1, 30));
Add(new cMenuEditIntItem(tr(" Brightness [%]"), &AtmoSetup.BrightCorrect, 50, 300));
Add(new cMenuEditIntItem(tr(" Darkness limit"), &AtmoSetup.DarknessLimit, 0, 10));
Add(new cMenuEditIntItem(tr(" Hue windowing"), &AtmoSetup.HueWinSize, 0, 5));

Die beiden Zahlen am Ende der Aufrufe geben min- und max-Werte an!

Die Voreinstellung kannst du dir so aussuchen, wies dir gefällt. Hab mal versucht zu fragen, welche Werte die User einstellen, kam aber irgendwie nix dabei raus...

Ich habe die unteren drei Werte aus deinem Zitat höher eingestellt...

Grüße.
Simon

Hi,

Zitat

Zitat:
Wichtig ist nur, dass der Filter und die Ausgabe getrennt vom
Calc mit einer festen Frequenz laufen!

richtig. - allerdings macht es nicht viel Sinn wenn die Ausgabe Frequenz viel höher liegt - als die "Capture Frequenz" und somit das gleiche ColorPaket mehrfach durch die "Mangel" gedreht wird? -- also müsste man versuchen den Takt des OutputThreads irgendwie an den Capture Thread zu binden.... --> z.B. über ein Event? (CreateEvent(...), WaitForSingleObject(...) -- construct - was der Capture Thread auslöst wenn er ein Frame hat -- ?

Da wage ich zu wiedersprechen Die Theorie der digitalen Filter verlangt eine feste Verarbeitungsfrequenz um reproduzierbare Ergebnisse zu erlangen. Im konkreten Fall heisst das, man könne die Frequenz mit der der Bildpuffer abgefragt wird ohne weiteres ändern (zB um CPU zu sparen) und sogar unregelmäßig dem Filter Daten füttern, und dieser muss trotzdem immer gleich schön faden. Wenn er alle 40ms läuft, reicht das locker, dann kannst du auch nur alle 500ms Daten geben, fadet immernoch sauber, logisch. Die Sprungerkennung geht dann natürlich nicht mehr.

Wenn du den Takt vom Datenerfassen im Bereich um 50ms festlegen kannst und der auch nciht vom Benutzer geändert werden darf, dann kannst du auch alles koppeln.

Grüße,
Simon

Hi,

so jetzt bin ich auch wieder da!

o Das schnelle Überblenden ist genau das, was der intelligente Filter bewirkt. (->Sprungerkennung) Das kann man genau so empfindlich einstellen wie man will (-> Filter_MeanThreshold)

Die "optimalen" Parameter muss jeder für sich selbst finden, man kann das Verhalten von atmo da gewaltig beeinflussen.

o Leider habe ich keine win-Entwicklungsumgebung, kann mir den code also nur anschauen und was dazu sagen

o Der Grund, warum Capture und Calc in 2 Threads geteilt wurde hatte was damit zu tun, verschiedene Einhabemethoden einzubinden, genau weiß das Samael. Für die Win-Version machts aber in meinen Augen keinen Sinn, Capture und Calc sollen also ruhig in einem Thread direkt hintereinander laufen.

Wichtig ist nur, dass der Filter und die Ausgabe getrennt vom Calc mit einer festen Frequenz laufen!

Interesant wäre es sicher noch zu wissen, mit welcher Frequenz sich die Daten im Bildpuffer von Win ändern...schneller muss das Ganze ja auch nicht laufen. Toll wäre es, auf genau diese Änderungen zu warten und genau danach zu capturen; zusätzlich sollte freilich eine max. Frequenz beachtet werden.

Wie das geht weiss ich leider auch nicht...bin im Moment eher der Theoretiker, da ich ja auch gar nix compilieren kann; viell. hilfts euch ja.

Grüße,
Simon