wxZ3D-OSM

Bei diesem Projekt sollen die DashCam-Videos aus einem Verzeichnis im Stück abgespielt und parallel dazu die aktuelle Koordinate auf der OSM-Karte angezeigt werden.
Das Ganze ist ein Folgeprojekt von z3d_map_to_gpx, welches die von einer "Z-Edge Z3D"-Dashcam parallel zur Video-Datei geschiebenen GPS-Daten auf der OSM-Karte visualisiert.
Hier dann nun gleichzeitig, zeitsynchron und mit eigenem VideoPlayer.
Erste Voranalysen haben ergeben, dass ich wx.media nicht nutzen möchte, weil die Doku-Lage dazu einfach nicht dem von wx ansonsten gewohnten Niveau entspricht.
Viel besser sieht's hingegen bei der Doku-Lage von "mplayer" aus. Da ist doch tatsächlich sogar die man-Page in richtiges Deutsch übersetzt. Und es gibt sogar noch dieses Dokument zum Thema Fernsteuerung.
Damit sollte sich was anfangen lassen....und mir Spaß machen...sofern die Doku-Lage zur Realität passt.
Denn....mplayer ist alt, echt alt, damit abgehangen und damit wiederum potentiell gut. Hoffe ich mal.

Erstmal ein Link zu youtube. Eigentlich habe ich solche Sachen ja viel lieber in Text...aber dieses Video ist dann ausnahmsweise tatsächlich doch mal seine Zeit wert.
Es passt zwar nicht 100% zu meiner Idee - aber teilweise werde ich das hoffentlich verwenden können.
Denn....es gibt zwar auch das hier (eine Python-Lib zur mplayer-Steuerung), aber das Ding macht mir entschieden zu viele import's von Libraries, die ich nicht alle haben möchte.
Ich mags "schlank" (zumindest bei Software) und "selbstgebaut". Sonst machts ja keinen Spaß.

Wir werden sehen. Vielleicht scheitere ich auch kläglich...und muss dann auf irgendwas Anderes umschwenken....oder aufgeben...
BTW: eine gewisse Fortschritts-Verzögerung könnte sich dadurch ergeben, dass auch im Erwerbs-Job gerade viel Neues zu entwerfen ist. Und immer dann, wenn ich im Beruf meine Kreativität voll abbauen ;-) kann, leidet der Fortschritt meines jeweiligen Bastel-Projektes....weil....ich nach Feierabend einfach nur noch stumpf konsumieren (alias abschalten) will.

Heute ist Freitag, ich habe früh Feierabend gemacht und in den letzten drei/vier Stunden einen allerersten POC zurechtgebastelt (noch nicht vorzeigbar).
Immerhin bin ich jetzt bereits soweit, dass der mplayer eine Playlist mit Videos abspielt und ich im Programm sekündlich den aktuellen Dateinamen sowie die bisherige Laufzeit pro Datei angezeigt bekomme.
Danach wollte ich die jeweils zugehörige map-Datei dazuladen, um erstmal nur die entsprechenden Geo-Koordinaten an der Zeitmarke je Video-Datei anzeigen zu können.

Aber....Scheiße!...Die erste Video-Datei aus meiner Playlist ist laut mplayer 274.1 Sekunden lang. Totem sagt 4:35 ... also 275 Sekunden.
Jedoch hat diese gammelige map-Datei nur 266 Zeilen und geht von 113528 bis 103654.
Wahrscheinlich ist der Zeitsprung dadurch entstanden, dass das GPS-Modul der Kamera zu diesem Zeitpunkt erstmalig Satelliten gesehen hat.
Die Uhrzeit wurde um 113649 auf 103353 korrigiert. Damit hat es etwa zwei Minuten gedauert, bis die Zeit aus dem GPS-Signal valide ankam.
Um 10:33:53 wird im Video erstmalig Datum/Uhrzeit/Koordinate/Geschwindigkeit eingeblendet.
Die letzte angezeigte Zeit in dieser Datei lautet 10:37:05. In der map-Datei jedoch 103654.
Na denn. Ich habe getankt und laut Anzeige (und Ton) im Video das Auto um 10:36:55 ausgeschaltet.
Die Kamera hat noch ein paar Sekunden weiter Video aufgenommen, aber offenbar die map-Datei mit dem "Strom weg"-Event geschlossen/beendet.
Man möchte brechen.
Und auch bei der Rückfahrt am nächsten Tag hat das erste Video 05:00 Minuten, die zugehörige map-Datei aber 308 Zeilen. Start laut Video-Einblendung 10:42:29, laut map-Datei 104228.

V,090122,104228,0.0000,0,0.0000,0,0.00,0.00,0.00,0.00; [...] V,090122,104258,0.0000,0,0.0000,0,0.00,0.00,0.00,0.00; V,090122,104259,0.0000,0,0.0000,0,0.00,0.00,0.00,0.00; V,090122,104259,0.0000,0,0.0000,0,0.00,0.00,0.00,0.00; V,090122,104300,0.0000,0,0.0000,0,0.00,0.00,0.00,0.00; [...] V,090122,104310,0.0000,0,0.0000,0,0.00,0.00,0.00,0.00; V,090122,104311,0.0000,0,0.0000,0,0.00,0.00,0.00,0.00; V,090122,104311,0.0000,0,0.0000,0,0.00,0.00,0.00,0.00; V,090122,104312,0.0000,0,0.0000,0,0.00,0.00,0.00,0.00; [...] V,090122,104429,0.0000,0,0.0000,0,55.52,0.00,0.00,0.00; A,090122,104419,5314.8774,N,1021.4022,E,35.08,0.00,-2.75,0.00; [...] A,090122,104716,5314.3931,N,1019.1496,E,72.73,0.00,0.00,0.00; A,090122,104717,5314.3901,N,1019.1315,E,73.99,0.00,0.00,0.00;

Auch hier 10 Sekunden Rückwärts-Korrektur in dem Moment, ab dem Satelliten gesehen werden.
Die restlichen map-Dateien sehen jedoch ganz akzeptabel aus. Immer zwischen 298 und 300 Zeilen. Obwohl auch die Blindheit im Elbtunnel dabei ist.
Hieße also, dass eine synchrone Anzeige von Video und OSM-Ansicht immer erst ab dem zweiten Video nach Einschalten des Autos möglich ist.
Wie unerfreulich.

Aber vielleicht ist es doch gar nicht so schlimm....wenn ich nur die validen Zeilen in der map-Datei betrachte (also solche mit Koordinaten).
Bei der Hinfahrt kommt die erste Zeile mit GPS-Koordinaten in Zeile 85. Das Video ist im Koordinaten-Einblende-Moment bei 01:22. Also 82 Sekunden.
Drei Sekunden Fehler ist zwar hart an der Schmerzgenze - aber (fürs erste Video einer Stecke) noch hinnehmbar.
Bei der Rückfahrt kommt die erste Zeile mit GPS-Koordinaten in Zeile 130. Das Video ist in dem Moment bei 02:01. Also 121 Sekunden.
Hier also neun Sekunden.... nicht mehr schön. Aber vielleicht noch kein Grund, das Projekt direkt aufzugeben. Denn...
Speziell in der Datei waren ja acht Zeilen zuviel drin. Doppelte Zeiten bevor das GPS-Signal da war. Würde man die ausblenden, könnte es wieder passabel sein.
Jedenfalls langts mir für heute.

Ein etwas erweiterter POC steht! :-)
Gestern hatte die Gattin Geburtstag. Da hatte ich den Rechner auch mal kurz an, habe aber gar nicht erst angefangen, mit wxZ3D-OSM weiterzumachen.
Heute haben wir zwar ebenfalls einen Geburtstag im Haus, jedoch hat sich der Stammhalter Corona eingefangen und darf nun sein Zimmer immer nur kurz (mit FFP2-Maske) verlassen.... das arme Schwein.... aber hat er sich selbst eingebrockt.... eine sog. XBOX-WLAN-Party mit fünf Jungspunden in einem Raum.... danach waren drei von den Burschen positiv beim PCR-Test.
Damit war heute Zeit.
Und hier das bisherige Ergebnis (nach ca. sechs Stunden):

Eigentlich ist das mplayer-Fenster auf 1280x720 eingestellt. Für dieses Video hab ich es manuell etwas verkleinert....
1.) um das screenrecorder-Video klein zu halten und
2.) um keine Nummernschilder verpixeln zu müssen (der einzige sichtbare Passant hatte einen Nase/Mund-Schutz auf).
Im Video sind Ausschnitte aus den ersten zwei mp4/map-Dateien zu sehen. Somit ist auch ein Datei-Wechsel enthalten, bei dem mein Steuerscript das mplayer-Fenster wieder mit der Default-Größe geöffnet hat. Daher das Gemurkse zwischen Minute 1:01 und 1:08.
Weiterhin habe ich die OSM-Zoom-Stufe mittendrin (kurz vor der Tanke / mittels Scrollrad) etwas verändert.

Als erstes wurde der POC vom Freitag von threading auf wx (v3.0.2.0) umgebaut.
Das hat ein bischen Zeit gekostet, weil ich von python3 zurück auf python2.7 musste.
Nachdem das lief, wurden für die OSM-Ansicht einfach alle *.py-Dateien aus wxOSM (v1.6 - aber auch die öffentliche v1.4c sollte klappen) ins wxZ3D-OSM-Verzeichnis gelinkt und dann OSMmini31.py (der Minimal-Demonstrator mit 158 Zeilen) minimal erweitert als osm_disp.py von wxZ3D-OSM.py importierbar angelegt. Das ist ein Frame. Der wird geöffnet, kümmert sich um die OSM-Ansicht und hat nur eine Steuerungsfunktion: centerPos(lat, lon).
Genau so hatte ich mir das ganz am Anfang von wxOSM (April 2017) gedacht ... es ist dann etwas ausgeufert....wegen der ganzen Erweiterungen fürs Wardriving.

Gestern habe ich die erste Mini-Erweiterung (der gesamte Track wird eingeblendet) eingebaut....und schon klappts nicht mehr mit der v1.4c von wxOSM.
Aber egal. Dann wird hier halt die v1.6 teilweise online gehen (demnächst zumindest...wenn alles hübsch ist). Auch, wenn deren neue Features primär fürs Wardriving gedacht/gebraucht wurden. Wat solls....liest ja eh keiner den gesamten Code ;-)
Die nächste größere Änderung sollte werden, dass der mplayer keine playlist mehr abspielt. Zwar klappt es mit der playlist sehr gut und schmerzfrei, wenn man sich im Video nur vorwärts bewegt. Will man jedoch zurück...und zwar vor den aktuellen 5-Minuten-Ausschnitt....dann wird das nix. Mal schauen, vielleicht gehts ja doch...irgendwie.
Und das, was bisher im Terminal durchtickert (lat/lon, speed, timestamp), sollte im Hauptfenster angezeigt werden.
Auch möchte ich Zeitmarken setzen können, die ich später schnell wieder anfahren kann.

Eben habe ich ein bischen mit dem mplayer-slavemode-Kommando "loadfile" rumgetestet. Und das macht echt keinen Spaß. Nach so einem Wechsel ist das mplayer-Fenster bildschirmfüllend und man muss das Kommando auch geschickt haben, bevor sich das bisherige mplayer-Fenster geschlossen hat. Sonst ist der Prozess weg und ich müsste sämtliche Pipe-nach-Queue-Magie abbauen und für den neuen Prozess wieder aufsetzen.
Daher bleibts jetzt doch bei der Playlist. Innerhalb der kann man mit den Tasten ">" und "<" zwischen Dateien wechseln (hier gefunden).
Es hat dann aber schon einige Google-Suchen benötigt, bis ich endlich herausgefunden hatte, in welchem Format der "key code" für den "key_down_event" zu übergeben ist.

self.mplayer_process.stdin.write(b"key_down_event %d\n"%(ord(">"),)) self.mplayer_process.stdin.flush()

...um in der Playlist eine Datei vorwärts zu springen.
Eigentlich ja ganz einfach. Aber warum in aller Welt muss man das denn "key code" nennen.....!? Unter "key" verstehe ich Taste, nicht Zeichen.
ASCII-Code, oder noch besser "Character-Code", wäre m.E. deutlich passender. Dann hätte ich mir das ganze Rumgesuche sparen können. Über eine Stunde Lebenszeit für solchen Mist.
Am Ende bin ich dann bei youtube fündig geworden....das hatte ich tatsächlich noch nie (für eine derartige Such-Anfrage).
Dass ich dieses Video überhaupt über eine Minute ausgehalten habe, zeigt, wie verzweifelt ich zu diesem Zeitpunkt bereits war ;-)

Es ist wieder mal Samstag und seit heute werden im Hauptfenster alle relevanten Daten angezeigt:

Insgesamt siehts so aus:

Wie man sieht....hier sinds zwei Sekunden Differenz zwischen map- und mp4-Datei. Stört nicht wirklich.

Und hier das Archiv mit den Python-Scripten für die Version 1.0 von wxZ3D-OSM.

Ein Tag später. Sonntag. Und schon steht die v1.1. Jetzt sieht das Hauptfenster folgendermaßen aus:

Screenshot vom Hauptfenster der v1.1 von wxZ3D-OSM

Neben ein paar Stabilitätsverbesserungen werden nun auch Statistiken angezeigt, die sich auf die komplette Tour beziehen.
Damit ist dieses Projekt jetzt eigentlich abgeschlossen.
Mal schauen. Kleine Bugfixes wirds vielleicht noch geben.

Aber wer weiss, ob ich mir zukünftig überhaupt die aufgezeichneten Videos je wieder ansehen werde....sofern darin nix dramatisches passiert ist.
Bei der ersten Hin- und Rücktour war alles noch neu mit der Dashcam.
Auch musste ich wxZ3D-OSM natürlich ausgiebig testen und habe mir dabei zwangsläufig viele Stellen vielfach angesehen.
Manchmal habe ich das Video dann allerdings etwas länger als zum Testen nötig laufen lassen, denn das eigentlich spannende an der Tour war weniger das Video / die Strecke .... sondern vielmehr die geistreichen Dialoge mit meiner Frau, mit der ich ausnahmsweise mal ohne die Kinder unterwegs war :-)

Montag. Und schon -um mich Lügen zu strafen- hab ich jetzt eine v1.1.1:

Es ist zwar nur ein wx.SpinCtrl hinzu gekommen, aber trotzdem ist es schon ziemlich viel geiler, wenn die OSM-Ansicht exakt zum Video passt.
Weil es aber nur zwei oder drei geänderte Zeilen sind, gibts erstmal noch kein neues ZIP.

Gestern Abend habe ich noch ein paar Stabilitäts-Fixes eingebaut - weil es sporadisch auftretende Störungen beim 5- bzw. 30-Sekunden-Skip gab.
Nun werden die dafür zuständigen Queues vor ihrer erneuten Befüllung erstmal leergelesen, um danach nur noch die frisch und neu angefragten Antworten zu enthalten.
Weiterhin wird jetzt sichergestellt, dass die aktuelle Zeit im Video, auf die der zu skippende Offset addiert wird, aktuell ist.
Damit bin ich jetzt bei v1.1.2 angekommen.... und erstmal fertig mit diesem Projekt.

Sollte ich jemals die mitgelieferte Heck-Kamera montieren und nutzen, wird es wahrscheinlich ein Update geben [müssen].
Jedoch kommt die Heck-Kamera ohne Saugnapf. Die will doch tatsächlich geklebt werden. Was für eine dumme Idee.
Denn....mein Touran geht auf 10 Jahre zu. Da klebe ich nix mehr rein, was dann vielleicht nur noch mit Bruch entfernt werden kann....

Eben habe ich spaßeshalber mal den Tile-Server von OSM auf OCM geändert (in osm_disp.py). Dafür existiert die Strecke noch nicht in meinem Tile-Cache. Folglich stellt wxOSM nun im Hintergrund reichlich Anfragen an den Tile-Server, kommt aber trotz Zoom-Level 17 und Autobahn gut und problemlos hinterher. Lediglich beim Skippen gibts mal kurz graue Tiles bzw. eine Tile-Nachlieferung.
Ich bin begeistert, wie endgeil ich das damals gebaut habe :-)
Natürlich ist Zoom-Level 17 totaler Quatsch für Autobahn. Höchstens 15 macht Sinn. Und mit 15 gibts trotz Tempo 120 nur alle paar Sekunden eine Anfrage für ~sieben Tiles beim Tile-Server.
Das soll der ja wohl locker auf einer Arschbacke wegstecken ... und meine IP-Adresse nicht auf die Blacklist setzen... wegen zu vieler Anfragen in zu kurzer Zeit... mich also nicht als DOS-Angriff betrachten.

Es sind zwei Wochen vergangen und heute ist wieder mal Samstag.
Ab jetzt ist auch das letzte noch fehlende Feature implementiert. Nämlich: "Zeitmarken anfahren".

Naja, Zeitmarken sind es eigentlich keine. Aber es gibt jetzt einen Slider, mit dem man im Video sekundengenau rumkurven kann.
In dem Moment, wo der Slider gegriffen wird, schaltet das Video auf Pause. Solange man den Slider bewegt, ändert sich nur die Position in der OSM-Ansicht.
Sobald man den Slider loslässt, wird das Video an die gewählte Stelle gefahren.
Bei großen Sprüngen tickern zwar sämtliche Videos kurz durch, die zwischen Start- und Ziel-MP4-Datei liegen - aber geht nicht anders, weil man sich m.W. in der Playlist nur VideoDatei-weise bewegen kann. Außerdem gehts flott vonstatten. Etwa drei VideoDateien pro Sekunde.
Damit sieht das Hauptfenster jetzt so aus:

Anbei noch die v1.1.3 von wxZ3D-OSM.

Und hier noch ein kleines Video mit Slider-Action (wieder verkleinert, um das Verpixeln einzusparen):

Da macht man das finale Video und dann brauchts kurz danach direkt wieder ein Update.....
Aber die Skala am Slider hat mir noch nicht richtig gefallen.
Sekunden taugen irgendwie nix, wenn das Video tausende davon lang ist.
Daher jetzt so:

Nebenbei auch kompakter.
Und weil es das nun aber gewesen sein soll, geht die Version auch gleich aufs nächste Minor-Release hoch.
Somit jetzt wxZ3D-OSM v1.2.

Ein Monat ist vergangen. Bei der Rundreise für die Sippschafts-Besuche zu Ostern kam die DashCam mal wieder zum Einsatz.
Und es gab einen Stau im Elbtunnel....
Daher braucht es gerade mal einen mini-Update für den Fall, dass eine komplette map-Datei ausschließlich V-Sätze (also solche ohne GPS-Koordinaten) enthält.
Zwar ist nur ein try/except+pass-Block hinzugekommen - aber ohne den läuft das Programm auf einen Fehler....mit der Folge, dass man einen gesamten Ordner-Inhalt nicht öffnen kann.
Daher hier wxZ3D-OSM v1.2.1.

Jetzt ist nochmal über ein Jahr vergangen, wir sind gerade aus dem Rügen-Urlaub zurück und die DashCam hat einzelne A-Sätze bzw. Koordinaten in die map-Dateien geschrieben, die tief in Russland oder im westlichen England lagen. Das hat das Map-Fenster insofern verwirrt, dass keine tiefen Zoom-Stufen mehr eingestellt werden konnten.
Folglich brauchte es noch einen kleinen Fix.
Jetzt werden Zeilen ignoriert, wenn ihre Vorgänger- oder Nachfolger-Zeile eine Koordinate meldet, die mehr als 100 Meter entfernt liegt.
Für Fahrzeuge, die über 360 km/h schaffen, wäre das zwar kontraproduktiv ... aber das nehme ich hin :-)
Notfalls kann man in map_parse.py die 0.1 in Zeile 148 in eine 0.2 ändern, um bis 720 km/h Luft zu haben.
Hier nun die wxZ3D-OSM-v1.2.2.