Posts by gemx

Quote

Original von DaOptika
Ich hab den Thread gelesen - aber hatte bisher den Eindruck, dass das laggen eher was mit der Leistung des Systems zu tun hat.

Ich benutze beim Mediaplayer Classic das Screencapture-Verfahren und hab selbst bei 50 FPS in AtmoWin nichtmal 50% CPU Auslastung, und da läuft es Performance-mäßig ja auch absolut klasse. Da hab ich keinerlei laggen oder sonstwas! Mit allen Kanälen ausser den Kanälen rechts bin ich ja auch absolut happy, also versteh ich nicht so ganz warum das Screencapturing bei ausreichen Performance ein Problem darstellen sollte. Vor allem macht dann auch Aero und DXVA keine Probleme.

Umso merkwürdiger find ich es ja, dass der normale Mediaplayer so laggt. Selbst wenn das "Capturen" des Screens lange dauert, sollte das sich ja nicht auf die Wiedergabe des Videos auswirken, es sollte aber nen deutlichen Anstieg der CPU-Last von AtmoWin auslösen (die sich dann sehr wohl auf die Videowiedergabe auswirken könnte). Was aber nicht der Fall ist...

Im Bezug dazu auch:

Verwirrt mich halt etwas das Ganze

Display More

Das hört sich ganz danach an als würdest du im MPC den AtmoDS Filter benutzen. Der stellt Atmowin automatisch um, sodass eben nicht mehr über screencapture gearbeitet wird. Das sieht man aber in AtmoWin nicht.
Das Problem mit dem Filter ist, das er mit HD Material nicht so richtig funktioniert. Habe mir den Mal in einer Debug Variante kompiliert und die gegrabbten Frames anzeigen lassen. Da ist ein Versatz in den Bildern drin, wodurch die Berechnung für die rechte Hälfte falsch ist. Ausserdem "verliert" man die HW-Beschleunigung der Grafikkarte, wenn man den Filter benutzt, da dieser die Frames noch im komprimierten Zustand bekommt. Das dekomprimieren von H.264 usw. findet letzendlich erst später im DS Graphen statt....
Das könnte ich jetzt noch ewig weiter führen.
Fakt ist:
- das Screencapture Verfahren, dass AtmoWin benutzt (BitBlt) ist arg langsam und belastet die CPU (ist Microsoft bedingt)
- der Filter funktioniert nicht richtig bei HD content und man hat keine HW-Beschleunigung durch die GraKa
- DirectX Methoden über den BackBuffer funktionieren zwar etwas schneller, liefern aber oft korrupte Frames

FAZIT:
Die einzige Möglichkeit, performant das AtmoWin anzusteuern ist, dies in die jeweilige Anwendung zu implementieren und zwar dort, wo der Frame bereits dekodiert vorliegt. Diesen dann am Besten noch im Speicher der GPU zu resizen und über das COM-Interface an AtmoWin zu schicken.
Das klingt jetzt zwar doof - ist es aber auch

Es gibt leider keinen anderen Weg. Habe mich jetzt 2 Wochen damit rumgeschlagen. Das ist leider von Microsoft so "verbrochen" worden. Die haben halt bei der Windowsentwicklung einfach nicht an Atmolight gedacht

Hallo zusammen,
jetzt hab ich doch mal wieder den Weg zurück zu VDR gefunden. Naja zumindest ins Forum und wollte auch gleich mal meinen herzlichen Dank für das gesamte Atmolight Projekt aussprechen. Läuft echt super

Der Patch für das Standby Problem ist relativ simpel und ich habe ihn mal angehängt.

Besten Dank auch an Gru fürs Testen

Das würde mich übrigens auch mal interessieren, ob man direkt ne Diode anklemmen kann.

da könntest du z.B. das control Plugin benutzen und unter Windows eine Telnet Verbindug zum VDR machen. Ist dann zwar nur Text mit Farben und kein Skin, aber immerhin

Hi,
habe mehrere Jahre Smartphones und PDAs mit Windows mobile gehabt und war eigentlich sehr zufrieden. Aktuell habe ich ein P910.
Aufgefallen ist mir beim P910, dass das UIQ irgendwie besser auf den PDA Formfaktor abgestimmt ist und dadurch ein wenig besser zu bedienen ist. Nach einiger Zeit sind aber doch ein paar Dinge aufgefallen.
Hier mein Vergleich:
P990 UIQ:
+sehr gute Bedienung
+ BT Stack läuft sauberer
+recht ordentliche Handschrifterkennung

- relativ wenig sinnvolle Software
- obwohl mittlerweile schon recht alt, hat die Firmware immer noch einige recht blöde macken
- es gibt keine anpassbaren Homescreens (mir gehts nicht um tolle Bildchen, sondern um das darstellen von aktuellen Terminen usw.)
- die Community kümmert sich hautpsächlich um nette Hintergrundbildchen und tolle Klingeltöne. Sehr wenig entwicklungstechnischer Background
- programmieren unter Symbian OS geht zwar mit C++, man muss aber ganz schön umdenken
- Outlook sync. funktioniert nicht sauber

Windows Mobile:
+sehr gut anpassbare Homescreens (siehe oben)
+perfekter sync. mit Outlook
+programmieren ist recht einfach ohne viel umlernen zu machen, wenn man bereits unter Windows programmiert hat
+viel Unterstützung auch hinsichtlich programmiertechnischer Dinge

-Bluetooth hatte immer mal wieder Probleme (ab Mobile 5 ist da aber einiges passiert)
-Sync. mit anderen PIM Anwendungen bzw. Linux nur recht umständlich möglich

Nachdem ich zunächst vom dem P910 recht begeistert war, werde ich glaube ich doch wieder zu Windows Mobile wechseln (Gründe siehe vergleich). Zum Treo kann ich eigentlich nichts sagen.
Was mich bei Sony Ericsson so nervt ist, das das P990 bzw. UIQ 3.0 nicht abwärts kompatibel ist. d.h. wenn man vorher ein P910 hatte, kann seine ganze Software updaten bzw. hoffen dass es neue Versionen gibt. Windows Mobile war und ist abwärtskompatibel.
Was noch dazu kommt: es gibt mehr Auswahl an Navi Software für Windows Mobile, was mir recht wichtig ist.
Übrigens: bin zwar recht begeistert von Linux, aber arbeitstechnisch benutzen wir halt Windows und da klappts mit Windows Mobile doch besser

Ich hätte zu dem Patch in dem anderen Thread noch eine kleine Optimierung anzubieten:

bool cDvbDevice::SetAudioBypass(bool On)
{
+ if (On)
+ {
+ cChannel *c=Channels.GetByNumber(cDevice::CurrentChannel());
+ if (c->Ca(0) != 0)
+ return false;
+ }
if (setTransferModeForDolbyDigital != 1)
return false;
return ioctl(fd_audio, AUDIO_SET_BYPASS_MODE, On)==0;
}

Dadurch wird zumindest nur bei verschlüsselten Sendern der Transfermode erzwungen

Hallo Leute,
war jetzt eine ganze Weile nur sporadisch, lesend hier im Forum tätig, da ich so einige "private Projekte" vorhatte (Hauskauf + Hochzeit). Die Hochzeit war vor 2 Tagen und es war wohl einer der schönsten Tage in meinem Leben

... Ähmm, ach so ja, der Grund des Threads ist eigentlich folgender:
Da wir zum Jahreswechsel in unser neues Eigenheim ziehen und man sich nun endlich voll mit elektronischen Spielereien (sinnvoll oder nicht :engel1) auslassen kann, wollte ich mal ein paar Ideen sammeln, was man so alles in Verbindung mit Linux, ner Activy und VDR anstellen kann.
Bis jetzt läuft neben dem VDR noch folgendes:
- Website für die Spielsprachschule meiner Frau
- Voice / Faxserver basierend auf Capisuite mit selbst geschriebenem Plugin für VDR
- Streaming Server für Audiodaten

Da geht aber bestimmt noch mehr oder?
Bin für alle Ideen offen (müssen nur auch "Frau kompatibel" sein, Stichwort WAF ;D)

Hi,
verwendest du das Plugin, dessen Name nicht genannt werden darf (s*)?
Dann wäre das nämlich normal. Dabei laufen nämlich leider auch die unverschlüsselten Programme im Transfermode. Habe dazu einen kleinen erweiterten Patch. Am besten per pn.

Hi,
hast du es schon mal mit ACPI versucht?
Zum Testen reicht ein simples

cat /proc/acpi/alarm

.
Wenn da Datum/Uhrzeit rauskommt dann klappts.
Ansonsten mal in die Kernel Config schauen. Es darf keim SMP Support aktiviert sein (damit hab ich mich nämlich grad eben beim Kernel neubacken reingelegt

Sehr gut funzt übrigens auch Azureus.
Den kann man mit einem Parameter auch im Konsolenmodus betreiben und der bietet auch ein Webfrontend. Man braucht nicht mal nen eigenen Webserver.
Einzige Vorraussetzung ist Java.
Bin sehr zufrieden damit.

Super Plugin
Bin schwer begeistert. Habe es bis jetzt mit "Eins Live" ausprobiert und das läuft ziemlich gut.
Danke.

Bin auch hochzufrieden
Ist alles ne Ecke flüssiger geworden. Vorallem bei ARD und ZDF

Habs jetzt unter Gentoo 2.6.14 laufen.
Macht einen doch flüssigeren Eindruck als vorher.
Bin bis jetzt recht zufrieden

Ach eins noch:
Habe die Treiber frisch aus mercurial gezogen und dann den Patch ausgeführt und kompiliert. Dabei sind bei mir 2 Probleme aufgetreten, die ich wie folgt gelöst habe:
1. "undefined symbols" nach starten der Treiber
-> ein reboot hat geholfen
2. Treiber zwar geladen, aber vdr 1.4 sagt, "no primary device found"
-> "rmmod stradis" ausgeführt. Der stradis Treiber ist wohl noch sehr experimentell und wird zumindest bei FF Karten automatisch mit geladen. Jedoch nicht wirklich benötigt.
Hoffe das hilft dem ein oder anderen

Hatte das auch mal ausprobiert, aber mir gefiel das über Irda net so gut (Reichweiten-Problem usw.)
Habe mir eine CompactFlash WLAN Karte besorgt und ne Software geschrieben, womit ich die Tastaturbefehle über SVDRP an den VDR sende.
Das klappt super gut.
Die Software läuft zwar und taugt auch sehr gut als Fernbedienung, allerdings ist das Design auf dem Display usw. nicht wirklich toll.
Habs irgendwie nie zu Ende gemacht.
Wenn einer Interesse hat, dem kann ich ja meinen bisherigen Sourcecode zur Verfügung stellen.
Ist unter .NET CF 2.0 programmiert.

Fänd ich ziemlich cool

Wollte mich auch mal einreihen und ein GAAANZ HERZLICHES DANKEEESCHÖÖN aussprechen. Sowohl an Klaus als auch an euch alle.
Durch VDR und dieses Forum hab ich mich zum ersten Mal "genötigt gefühlt" mich mit Linux zu beschäftigen. Mittlerweile komme ich auch ganz gut zurecht, aber ohne die Motivation VDR und eure super Unterstützung wär das wohl nix geworden. DAAANNNKKEE

Hi.
Also an der Capisuite Version liegts nicht direkt, aber das Plugins ist schon recht abhängig von den geänderten Scripten idle.py und incoming.py.
Wenn du die original Scripte der Capisuite benutzt, dann fehlt dem Plugin was. Es werden nämlich unter anderem die Ansagen innerhalb des incoming.py Scripts umgewandelt. Darüber hinaus noch einiges mehr.
Alle Änderungen sind mit ## by kwasi gekennzeichnet.

Hi,
also ich benutze aktuell die 1.3.46 und habe seit der Erstellung des Plugins nicht einmal Anpassungen bezüglich einer neuen VDR Version machen müssen. Daran liegts also schon mal nicht. Hilfreich wäre ein Logfile vom VDR.
Dann könnte man der Sache mal gezielt nachgehen.

@blazko
Also wenn ich direkt (nicht mit "extern" sondern "PES") auf einen z.B. Laptop streame geht das ohne Probleme.
Sobald ich .../extern/? benutze füllt sich am Laptop über MPlayer der PreBuffer so bis ca. 17 % und dann passiert nix mehr.
Die Rechenpower (1 GHz) sollte doch zum transcodieren eigentlich ausreichen oder?
Ich vermute mal es liegt am MPlayer.
Werde den mal frisch auschecken und schauen ob dann besser geht.

Das ist schon mal supi
Kannst du mir mal schreiben welche Versionen du von:
- vdr
- mplayer
benutzt und was du für einen Prozessor hast ?
Bei mir klappt das Transcoden über .../extern/* nämlich nicht sauber.
Er fängt immer an, aber der Pre-Buffer am Client wird nie voll. Irgendwann bricht er dann ab.
Meine Konstellation:
Server:
- vdr 1.3.43
- streamdev aus dem cvs frisch ausgecheckt
- 1 GHz Prozessor
- MPlayer 1.0pre7try2-3.3.4
- FF DVB-S Karte
PDA:
- Pocket LOOX 620
- TCPMP 0.71 mit allen plugins als Player

Habs mit beiden externremux Scripten aus deinem HowTo getestet.
Streamen an sich geht. z.B. als PES Stream. Der Ton ist fast flüssig, das Bild wechselt so alle 20 Sek.