16:9-Anzeige in der Infobar des Movieplayers

[GetAway]

Hier mal ein Patch um die ganze Sache zu fixen, inklusive LIRC und 16:9-, 4:3.start Dateien.
Bitte testen. Falls das soweit OK ist kann es in den mp2 eingearbeitet werden.

Patch: fix_videooutput_movieplayer1.diff

[Gaucho316]

Wäre eine openDevice/closeDevice-Lösung für den videoDecoder so wie beim audioDecoder nicht wirklich besser? Oder ist das tatsächlich zu kompliziert? Das würde auf alle Fälle den doppelten Code vermeiden.

Noch eine andere Frage. Könnte man in checkAspectRatio() statt ioctl(vdec, VIDEO_GET_SIZE, &g_size) bzw. ioctl(vdec, VIDEO_GET_SIZE, &new_size) nicht besser g_Controld->getAspectRatio() verwenden? Oder wäre das völliger Unsinn?

[seife]

Wäre eine openDevice/closeDevice-Lösung für den videoDecoder so wie beim audioDecoder nicht wirklich besser? Oder ist das tatsächlich zu kompliziert? Das würde auf alle Fälle den doppelten Code vermeiden.

nein, denn jetzt ist ja auch schon code doppelt: der für den dekoder. Nur der für pin8 ist noch nicht doppelt.
und lirc. Ok. Das hatte ich auch verdrängt

Noch eine andere Frage. Könnte man in checkAspectRatio() statt ioctl(vdec, VIDEO_GET_SIZE, &g_size) bzw. ioctl(vdec, VIDEO_GET_SIZE, &new_size) nicht besser g_Controld->getAspectRatio() verwenden? Oder wäre das völliger Unsinn?

Ich denke nicht dass das funktioniert, wenn zapit im standby ist, da da der decoder ja geschlossen ist. Ausserdem wäre es viel mehr overhead und ist ja auch nicht das eigentliche problem.

[Gaucho316]

nein, denn jetzt ist ja auch schon code doppelt: der für den dekoder. Nur der für pin8 ist noch nicht doppelt.

Ok, mir ging es mit meiner Frage auch nur darum, den doppelten Code so klein wie möglich zu halten.

Ich denke nicht dass das funktioniert, wenn zapit im standby ist, da da der decoder ja geschlossen ist. Ausserdem wäre es viel mehr overhead und ist ja auch nicht das eigentliche problem.

Ok, hat mich nur interessiert, da ich weiß, dass es diese Funktion gibt. Hätte ja sein können, dass es sinnvoll gewesen wäre, die hier zu nutzen. Wie man sieht, hab ich nicht so den großen Durchblick.

Und noch eine Frage: In dem neuen Code von GetAway ist ja execute_start_file(FORMAT_xxx_FILE) eingbaut. Warum ist das in "video.cpp" deaktiviert? Funktioniert das dort nicht richtig?

[GetAway]

Und noch eine Frage: In dem neuen Code von GetAway ist ja execute_start_file(FORMAT_xxx_FILE) eingbaut. Warum ist das in "video.cpp" deaktiviert? Funktioniert das dort nicht richtig?

Steht ja eigentlich da..., und dann war da noch das doing.

/* todo: fix. probably outside of video.cpp. */

Eigentlich könnte man diese Funktion mal nach /widget verlagern, so oft wie der doppelt ist.

[dwilx]

Eigentlich könnte man diese Funktion mal nach /widget verlagern, so oft wie der doppelt ist.

Warum nicht /driver ?

[GetAway]

Nein, ich meinte diese und ähnliche:

Code: Alles auswählen

execute_start_file()

[Gaucho316]

Ich weiß, dass ich nerve, aber mir hat das keine Ruhe gelassen. Ich habe die Sache mit openDevice/closeDevice wie im Audio-Decoder doch mal für den Video-Decoder umgesetzt und ausprobiert und kann sagen, dass es funktioniert. Warum wird denn diese Variante abgelehnt, obwohl es geht? Doppelten Code so weit wie möglich zu vermeiden, muss doch das Ziel sein.

Link entfernt, da Patch im CVS

[Houdini]

> Warum wird denn diese Variante abgelehnt, obwohl es geht?
weil neutrino und controld dann zusätzlich über ein socket kommunizieren müssen und ein context/task switch erfolgen muß.
Je weniger dieser Kommunikation erfolgen, desto besser.

Houdini

[seife]

Ich wollte den dbox-code möglichst wenig anfassen, weil ich den nicht mehr wirklich teste. Aber wenn das noch ein wenig getestet wird, kann man das von mir aus gern so machen, insbesondere weil es die Unterschiede zwischen dbox und anderer hardware verringert.

Houdini: schau dir den diff an, keine zusätzliche socketkommunikation, aber das SCART-PIN8 handling bleibt halt im eventwatchdog, weil das videodecoder-objekt nicht zerstört wird. Sieht echt nicht so schlimm aus, wie ich mir das zuerst vorgestellt hatte. Hätte ich das nur mal durchprobiert ;-)

[GetAway]

Ich bevorzuge auch die Lösung von Gaucho316, auch wenn es jetzt zu einer Socket-Kommunikation kommt,
aber die haben wir bei jedem zap. Getestet und für gut befunden.
Fehlen jetzt nur noch LIRC und die Startfiles.

[Gaucho316]

Im Infoviewer wird ja NeutrinoMessages::EVT_MODECHANGED ausgewertet. Allzu passend finde ich es aber nicht, hier die LIRC-Sachen und die Startfiles einzubauen. Die beste Stelle wäre wohl in "handleMsg" von neutrino.cpp. Man müsste die Message EVT_MODECHANGED nach der Auswertung im Infoviewer weiterleiten. Geht das überhaupt?

[GetAway]

Die Frage ist, ob es jetzt nicht doch nach video.cpp gehört?
Der Dekoder macht was, dann soll er an der Stelle alles machen.

Außerdem wird man es dort am ehesten suchen. Nur meine Meinung.

[Gaucho316]

Wie wäre es, den Code in CControldAspectRatioNotifier::aspectRatioChanged(...) einzubauen?

[GetAway]

Ja, die Stelle passt noch besser, dann steuert der Dekoder wirklich nur die Hardware für die er zuständig ist.

Ich blick da zu wenig durch, um das machen zu können.

Du lügst.

[Gaucho316]

Mist, erwischt.
Zu dem Zeitpunkt, als ich diese Aussage getroffen habe, habe ich da wirklich noch nicht durchgeblickt. Daraufhin habe ich dann aber versucht, dem Code ein wenig zu folgen. Scheinbar mit Erfolg. Die großen Zusammenhänge sind mir aber an vielen Stellen noch nicht klar, wie man an einigen meiner Fragen aus diesem Thread erkennen kann. Ich bin auch nicht der große Programmier-Crack. Mein Code ist oft rein intuitiv aus vorhandenem Code abgeschaut und zusammengebaut. Aber damit scheine ich ja auch etwas beitragen zu können.

[GetAway]

@seife

Willst du das noch auf der TD testen, sonst könnte es schon mal rein.
Das sieht jedenfalls sauber aus.
LIRC und Startdateien sind in einem separatem Patch besser aufgehoben.

[Gaucho316]

Ich habe da noch etwas. In Zeile 2847 von zapit.cpp ist mir ein unnützes #ifdef HAVE_TRIPLEDRAGON innerhalb eines #ifdef HAVE_TRIPLEDRAGON aufgefallen.

[GetAway]

Ja, kann bereinigt werden.

Ist mit diesem Commit eingeflossen:
http://cvs.tuxbox-cvs.sourceforge.net/t ... 1&r2=1.442

[seife]

Ich komme in absehbarer Zeit nicht dazu, das auf der TD zu testen, weil ich den TD-Code erst mal wieder auf den Tuxbox-Stand hochziehen muss und neutrino-HD momentan einfach höhere Prio hat. Also macht das einfach rein, wenn ich später auf der TD was dazu finde, kann ich es immer noch fixen.

[Gaucho316]

Möchte nicht mal jemand mit Schreibrechten fürs CVS meinen Patch einchecken?
http://forum.tuxbox.org/forum/viewtopic ... 68#p377968

Und das hier vielleicht auch gleich?
http://forum.tuxbox.org/forum/viewtopic ... 39#p378039

[dbt]

erledigt

[Gaucho316]

Danke schön.