Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Philip Nys - CV

Softwareentwickler

Motivierter Softwareentwickler mit Freude an Teamarbeit und einer strukturierten, lösungsorientierten Arbeitsweise. Drei Jahre Erfahrung als Werkstudent in der Forschung um Media Streaming, mit Einblicken in state-of-the-art, praxisnahe, technisch geprägte Projekte. Gewohnt, in interdisziplinären Teams zu arbeiten und technische Aufgaben sorgfältig umzusetzen. Stets bereit, neues Wissen zu erlernen und direkt in Projekte einzubringen.

Contact Information

Persönliches

  • Addr Icon Geburtsort: Berlin, Deutschland
  • Calendar Icon Geburtsdatum: 08.12.1998
  • Addr Icon Nationalität: Deutsch

Beruflicher Werdegang

Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS, Berlin

  • Werkstudent, Studentische Hilfskraft für Forschung und Entwicklung von Live Media Streaming
  • 11/2022 - 09/2025
  • Berlin, Deutschland

Projekte

  1. Media Streaming mit QUIC, WebTransport und HTTP/3
    Entwurf und Erstellung eines Testbeds, welches die Vorteile von QUIC1 verwendet, um ein verbessertes Streamingerlebnis im Vergleich zu herkömmlichen Methoden, wie zum Beispiel dash.js2, zu bieten.
    Diese Thema war zu gleich ein wesentlicher Bestandteil meiner Bachelorarbeit.

  2. Media over QUIC Transport (MOQT)
    Erlangen vom vollständigen Verständnis des neuen Protokolls MOQT3. Weiterentwicklung einer bestehenden Implementation, um dieses auch wieder mit dash.js2 zuvergleichen.
    Evaluierung der Nützlichkeit von MOQT3 für Remote Rendering.

  3. Live Streaming mit Content Credentials durch C2PA
    Entwurf und Erstellung eines Testbeds, welches die Signaturmethodiken von C2PA4 auf Live Streaming anwendet. Die Realisierbarkeit davon erurteilen und dazu den bestehenden Prozess optimieren, damit C2PA4 im Live Streaming realisierbar sein kann.
    Dieses Projekt entstand aus meiner Masterarbeit.

Alle diese Projekt habe ich auf der jährlich von FOKUS veranstalteten Konferenz Media Web Symposium (MWS5) an einem Messestand präsentiert.

Publikationen

Bildung

Master of Science - Computer Engineering

Während meines Studiums habe ich enige erwähnenswerte Module belegt. Details sehen Sie hier.

In meiner Masterarbeit habe ich den Prozess der Signierung von Media mit C2PA4 Manifesten auf Live Streaming angewendet. Hierfür habe ich ein Testbed entwickelt, welche eine typische Live Streaming Situation nachstellt: ein Producer erzeugt einen Live Streaming, welcher an den Signer geschickt wird. Dieser signiert den Live Streaming und senden ihn weiter an ein CDN. Der Consumer kann diesen Live Stream schließlich abspielen und verifizieren, dass er nicht manipuliert wurde.
Genauere Details erhalten sie hier.

Bachelor of Science - Technische Informatik

Auch in meinem Bachelorstudium habe ich erwähnenswerte Module belegt. Details sehen Sie hier.

Während meine Tätigkeit als Werkstudent bei FOKUS habe ich ein Testbed entwickelt, welches WebTransport nutzte um eine Methode bisherige Streaming Standarts abzulösen. Den WebTransport Server dieses Testbeds habe ich in Go geschrieben. Für meine Bachelorarbeit habe ich diese Komponente in Rust übertragen. Zu diesem Zeitpunkt hatte bei Implementationen verschiedene Congestion-Algorithmen verwendet, wovon der von Rust besser gewesen sein soll. Daher war es meine Aufgabe die Beiden zu vergleich und evaluieren, welche besser ist.
Genauere Details erhalten sie hier.

Kompetenzen und Fähigkeiten

Programmiersprachen

  • Rust
  • Go
  • C
    • Level: Fortgeschritten
    • Effektive Erfahrung: 5 Jahre
    • Projekte: OSPTI, RNVS, etc.
  • C++
    • Level: Fortgeschritten
    • Effektive Erfahrung: 2 Jahre
    • Projekte: PJKT, etc.
  • Python
    • Level: Profi
    • Effektive Erfahrung: 10 Jahre
    • Projekte: PAlgoDat, ASE, etc.
  • Bash
    • Level: Fortgeschritten
    • Effektive Erfahrung: 3 Jahre
    • Projekte: stetiger Begleiter in vielen Projekten
  • JavaScript/TypeScript
    • Level: Experte
    • Effektive Erfahrung: 5 Jahre
    • Projekte: CG1 und viele weitere
  • Java
    • Level: Grundlagen
    • Effektive Erfahrung: 1 Jahr
    • Projekte: AlgoDat, SWTPP, GDST, etc.
  • C#

Software & Tools

  • MS Office
    (Word, Excel, PPP, Teams, etc.)
    • Level: Experte
    • Effektive Erfahrung: 15 Jahre
  • LaTeX
    • Level: Profi
    • Effektive Erfahrung: 5 Jahre
    • Projekte: Bachelorarbeit, Masterarbeit, CV und mehr
  • Git
    (GitHub, GitLab, Codeberg, etc.)
    • Level: Profi
    • Effektive Erfahrung: 10 Jahre
    • Projekte: stetiger Begleiter in jedem Projekt
  • FFmpeg
    • Level: Profi
    • Effektive Erfahrung: 4 Jahre
  • DASH
    • Level: Fortgeschritten
    • Effektive Erfahrung: 4 Jahre
  • HLS
    • Level: Grundlagen
    • Effektive Erfahrung: 2 Jahre
  • MOQT
    • Level: Experte
    • Effektive Erfahrung: 4 Jahre
  • C2PA
    • Level: Experte
    • Effektive Erfahrung: 2 Jahre
  • Docker
    • Level: Fortgeschritten
    • Effektive Erfahrung: 3 Jahre
  • Data Visualisierung
    (pyplot, plotters, gonum, plotly)
    • Level: Experte
    • Effektive Erfahrung: 10 Jahre

Betriebssysteme

  1. Linux
    • Level: Profi
    • Effektive Erfahrung: 10 Jahre
  2. Windows
    • Level: Experte
    • Effektive Erfahrung: 20 Jahre
  3. macOS
    • Level: Grundlagen
    • Effektive Erfahrung: 3 Jahre

Grafische Oberflächen

  • HTML
    • Level: Experte
    • Effektive Erfahrung: 5 Jahre
  • CSS
    • Level: Fortgeschritten
    • Effektive Erfahrung: 5 Jahre
    • Genügend Kenntnisse um funktionierende Testumgebungen zu bauen
  • Svelte
    • Level: Profi
    • Effektive Erfahrung: 3 Jahre
    • Für alle Projekte rum um meiner Tätigkeit bei FOKUS verwendet
  • Dioxus
    • Level: Fortgeschritten
    • Effektive Erfahrung: 1 Jahre
    • Projekte: markdown-dx, TB Planner
    • Rust Framework stark an React angelehnt.
  • Vue.js
    • Level: Fortgeschritten
    • Effektive Erfahrung: 1 Jahr
  • React
    • Level: Anfänger
    • Effektive Erfahrung: 1 Jahr
    • Schon häufiger Projekt anschauen müssen, aber selber noch nicht verwendet

Datenbanken

  • ProstgreSQL
    • Level: Anfänger
  • Redis
    • Level: Anfänger

Sprachen

  1. Deutsch (Muttersprache)
  2. Englisch

  1. QUIC RFC9000 ↩

  2. GitHub dash.js ↩ ↩2

  3. IETF Working Group moq ↩ ↩2

  4. Webseite c2pa.org ↩ ↩2 ↩3

  5. MWS 23, 24, 25 ↩

Beruflicher Werdegang

Werkstudent - Fraunhofer-Institut für Offene Kommunikationssysteme FOKUS, Berlin

Media Streaming using QUIC/WebTransport/HTTP3

Mit diesem Projekt began ich meine Arbeit bei FOKUS. Als erstes habe ich mir ein Grundverständnis von QUIC und WebTransport angeeignet.

Überblick über QUIC/WebTransport/HTTP3

Diese Protokolle sind der neue Antrieb hinter der dritten Version von HTTP. Wohingegen bisherige Versionen von HTTP das Transmission Control Protocol (TCP) als Transportprotokoll verwendet haben, benutzt HTTP/3 das User Datagram Protocol (UDP) in Form von QUIC.

Der große Unterschied zwischen diesen beiden Protkollen ist, dass TCP eine dedizierte Verbindung zwischen dem Client und Server aufbaut und damit garantieren, dass alle Daten korrekt ankommen, d.h. ohne Fehler und auch in der beabsichtigten Reihenfolge. Im Unterschied dazu schickt UDP die Daten einfach los mit der Hoffnung, dass diese auch ankommen. Jedoch ohne Garantie, dass das auch passiert.

Nun fragen Sie sich bestimmt, warum QUIC nicht mehr TCP verwendet, wenn es doch sicherstellt, dass alle korrekt ankommt: TCP ist langsam. Der Verbindungsaufbau von TCP benötigt ein Austausch von Daten, um sicherzustellen, dass beide Seite kompatible sind, ein sogenannter Handshake, bevore die eigentlichen Daten versickt werden können.

Dazu kommt noch dazu, dass heutzutage jede seriöse Webseite das gesicherte HTTPS Protkoll verwendet. Das heißt, dass jegliche Daten in dem Austausch verschlüsst sind. Dies benötigt zusätzlich zu dem TCP Handshake einen Transport Layer Security (TLS) Handshake. Des Weiteren basiert HTTP auf einem Frage-Antwort-System, d.h. ein Client muss Daten spezifisch von Server anfragen, damit dieser antworten kann.

Jeder dieser Schritte ist eine sogenannte Round-Trip-Time (RTT), d.h. Daten gehen vom Client zum Server, welche ggfs. die Anfrage noch verarbeiten muss, und wieder zurück. Im Kontext von Media Streaming bedeutet das, dass bis der Client die ersten Daten des Mediums erhalten, vergehen volle 3-RTT.

Mit QUIC wird all das abgekürzt. Es wird nur ein einziger Handshake gemacht, welcher den QUIC und TLS zugleich in einem Schritt tätigt. Dadurch ist der Verbindungsaufbau betreit auf nur eine RTT halbiert. Des Weiteren ist die Funktionsweise von QUIC sehr ahnlich wie die WebSockets API, d.h. sowohl der Client als auch Server kann Streams aufmachen und darüber jeder Zeit Daten verschicken.

Note

Mit Hilfe dieser Streams stellt QUIC auch im Hintergrund sicher, dass alle Daten korrekt ankommen

Im Kontext von Media Streaming bedeutet das, dass es möglich ist die ersten Daten des Mediums inner halb etwas über einer einzelnen RTT zu erhalten, da es dem Server erlaubt ist direkt nach dem Abschicken der Handshake-Besätigung die erste Daten des Mediums zu verschicken. D.h. der Client kann Daten bereits mit dem Handshake anfragen.

WebTransport ist eine API, welches es ermöglicht QUIC in einem Browser (auf einer Webseite) mittels HTTP/3 zu verwenden

Testbed

Mit diesem Wissen habe ich im Anschluss mein eigenes Streaming Protokoll und komplettes Testbed entwickelt.

Client

Der Client war eine einfache Webseite, gebaut mit Svelte1, welche die WebTransport Verbindung aufbaut und ein Video Streaming mittels meinem Protokoll empfängt und dann mit Hilfe eines Media Source Extension (MSE) Player abspielt. Dazu gab es noch einige Schaltflächen, um bestimmte Aspekte des Streams zu konfigurieren, z.B. maximale Bitrate, ABR Algorithmus, Netzwerk Limiter und mehr. Schlißlich gab es noch einige Live Datenplots, welche Metadaten des Streams dargestellt haben, wie die aktuelle Bitarte, eingestellter und geschätzer Netzwerkdurchsatz, Latenzschätzung.

Server

Der WebTransport Server verwendete webtransport-go2 und hat die gesamte Logik beinhaltet. Er hat die Clientverbundung angenommen und dann die Streams verschickt. Dazu war er in der Lage beim Versenden der Daten den Nettwerkdurchsatz zuschätzen und damit ridumentäre serverseitge Adaptive Bitrate (ABR) Algorithmen anzuwenden, um die Videobitrate an die Netzwerk gegebenheiten anzupassen, damit Clientseitig das Video stetig flüssig abspielen kann.

Das gesamt Testbed wurde in einem Docker Compose Setup gestartet, damit die Netzwerkanbindung des Servers mit Hilfe des Traffic Control (tc) Unix Tool gedrosselt werden kann, um variierende Netzwerkbedingungen zu simulieren.

Protokoll

Der Client baut eine WebTransport Verbindung mit der Server auf. Mit Hilfe der Verbungsaddresse, konnte der Client direkt ein spezifisches Video anfragen und zusätzlich die zugenannten Konfigurationsmöglichkeiten per Query Parameter direkt mitschicken.

Der Server hat dann einfach die Video (und Audio) Segmente der Streams an den Client geschickt, welcher diese abgespielt hat.

Schließlich wurde die selbe Situation mit dem dash.js3 Spieler zum Vergleich getestet.

Diese Projekt hat sich dann zu Media over QUIC weiter entwickelt.

  1. Webseite svelte.dev ↩

  2. GiHub webtransport-go ↩

  3. GitHub dash.js ↩

Media over QUIC

In etwa zur selben wie mit meiner Arbeit an meinem vorherigen Projekt begonnen habe, hat eine IETF Working Group mit Media over QUIC (später kann noch Transport dazu) oder MOQT1 begonnen. Die große Idee hinte MOQT ist es ein Streaming Protokoll basierend auf QUIC zu entwickeln, welches jedes bisherige Streaming Protokoll ablöst und in jedem Bereich besser sein soll.

Dieser Entwicklung habe ich so ziemlich bis zum Ende meiner Zeit bei FOKUS verfolgt.

Weiterentwicklung

Der erste Schritt war die Integration von MOQT in mein vorheriges Testbed. Um diesen Aufwand zu reduzieren, habe ich die existierende Implementation2 verwendet. Luke Curely hat diese Implementation ursprünglich sehr ähnlich zu meinem Projekt mit Go geschrieben, jedoch ist er schnell zu Rust gewechselt, später kam Mike English dazu und eventuell wurde das Projekt in zwei Richtungen aufgeteilt. Luke Curely hat seine eigene Vision von Media over QUIC verfolgt und Mike English hat sich weiter an die IETF gehalten und schließlich wurde das Projekt von cloudflare übernommen.

Ich habe diese Implementation über die Zeit stetig angepasst: Ich habe eine clientseitige Netzwerkdurchsatzschätzung eingebaut

  • clientseitige Netzwerkdurchsatzschätzung
  • clientseitige ABR Algorithmen
  • modularen Video Produzent, welcher diverse Arten von Media mit Hilfe von FFmpeg erstellen konnte
  • Latenzschätzung
  • etc.

Im Großen und Ganzen habe ich letztendlich die selben Tests wie in meinem verherigen Projekt durchgeführt, nur jetzt mit einem spezifisiertem Protokoll, statt meiner eigenen Lösung.

MOQT in Remote Rendering

Ein weiteres Projekt an dem ich mitgewirkt habe war die Untersuchung, ob MOQT1 eine möglich Anwendung for Remote Rendering hat.

Remote Rendering wird beispielsweise für das Metaverse oder Game Streaming verwendet, das bedeutet, dass die Anwendung nicht von dem Client PC gerendert wird, sondern von einem Server in einem Rechenzentrum. Dieser Server schickt, dann die renderteten Bilder in Form eines Video Streams an den Client, welcher quasi einen interaktiven Live Streaming steuert.

In diesem Projekt war ich quasi als Experte für MOQT1 und Unterstützung in der Umsetzung tätig.

  1. IETF Working Group moq ↩ ↩2 ↩3

  2. GitHub moq-rs ↩

Content Provenance and Authenticity

Diese Projekt began als meine Masterarbeit und wurde über die Zeit näher in meine Arbeit mit eingebunden.

Coalition for Content Provenance and Authenticity (C2PA)

Unter C2PA1 versteht man heute mehr als nur den eigentlichen Zusammenschluss von einer vielzahl von Unternehmen, welche an diesem Standart arbeiten, sondern auch den eigentlichen Prozess und die damit verbundenen Manifeste.

Die grundlegende Idee von C2PA1 ist die immer schwieriger werdende Problematik reale Medien von Manipulierten oder auch “KI”-generierten zu unterscheiden.

Important

Medien bezeichen in diesem Kontext so ziemlich alles was digital consumiert werden kann, wie Bilder, Dokumente, Videos, Musik, in so vielen gängigen Dateiformaten wie möglich.

Um dies so entgegenzuwirken werden in diese Medien manipulationssichere Metadaten eingebettet, welche exakt dokumentieren, Wer, Wann, Wo, Wie und Was mit diesem Medium gemacht hat.
In einer ideallen Welt, in der C2PA1 in alle vorgesehenden Prozessen integriert wurde, würde das, beispielsweise an einem Bild, bedeuten, dass in diesen Metadaten stehen würde:

  1. Person A hat das Foto gemacht
    • mit Kamera X
    • zu der Zeit T_1
    • mit den Kameraeinstellungen (Objektiv, Brennweite, Zoomlevel, ISO, etc.)
    • an Ort L
  2. Person B hat diese Foto bearbeitet und auf Server S hochgeladen
    • mit Programm P
    • zur Zeit T_2
    • was bearbeitet wurde (Farbkorrektur, zu geschritten, Gegenstände entfernt/hinzugefügt, etc.)
  3. Server S hat diese Bild erhalten und
    • komprimiert, in ein anderes Format umgewandelt, etc.
  4. Person C hat diese Bild schließlich in einen Artikel eingefügt und ggfs. auch weitere Dinge damit gemacht

Note

Diese Eckdaten sind Beispiele und es können alle erdenklichen Informationen hinzugefügt werden.

Schließlich kann Person D diese Bild in dem Artikel sehen und hat die Möglichkeit nachzuvollziehen wo diese Bild herkommt.

Dieses Beispiel kann natürlich auch so gegeben werden, dass das Bild nicht fotografiert wurde, von einem “KI”-Tool generiert wurde und in diesem Fall würde nicht der Kameramann und die Kamera in den Metadaten stehen, sondern das “KI”-Tool, welcher Prompt gegeben wurde und auch die Person oder sogar ein anderes Programm, das diesen Prompt gegeben hat.

C2PA in Live Streaming

Meine Aufgabe in diesem Projekt war es die Anwendbarkeit dieser Prozesses im Bereich des Live Streaming zu untersuchen. Zu diesem Zeit wurden diese Prozesse nur für fertiggestellte Videos und nicht für dynamische Live Streams in der technischen Spezifiaktion beschrieben.

Zunächst habe ich gegonnen mit der Recherche, wie das Signieren von Videos funktioniert. Das für habe ich zum einen die technische Spezifiaktion und die Reference Implentation c2pa-rs2 studiert.

Video signieren

Im Streaming Bereich werden sowohl Videos als Live Streams in viele kleine Stückchen, sogenannte Segmente oder auch Fragmente, geteilt, d.h. ein Video besteht tatsächlich aus vielen Einzelteilen. Das wiederum hat zur folge, dass es möglich nur einzelne Segmente zu manipulieren und erfordert die Möglichkeit nicht nur jedes einzelne Segment für sich selbst zu verifizieren, dass es nicht manipuliert wurde, sondern auch, dass das Video als Gesamtes valide ist.

In dem Signierungsprozess eines Videos kommt ein sogenannter Merkle Tree zum Einsatz, dieser erfüllt diese Anforderung exakt. Dieser Merkle Tree und die ensprechenden Metadaten werden in das allererste Segment, das sogenannte Initalisierungssegment, eingebettet. Die einzelnen Video Segmente erhalten nur den Teil, der benötigt wird sich selbst als Teil des _Merkle Tree_s zu validieren.

Testbed

Das Testbed bestand aus vier Teilen:

  1. Producer: erstellt ein Live Stream
  2. Signer: signiert den Live Stream
  3. CDN: lagert den signierten Live Stream
  4. Consumer: sieht sich den signiert Live Stream and und validert ihn

Producer

Der Producer war der selbe modulare Umschlag um FFmpeg, welchen ich für mein Media over QUIC Projekt erstellt habe. Dieser hat einen Live Stream erzeugt und diesen, dann an den Signer geschickt.

Signer

Der Signer war das c2patool3, welches ich für dieses Projekt modifiziert habe. Die signierten Segmente wurde im Anschluss an das CDN gesendet.

CDN

Das Content Delivery Network (CDN) war eine Abstraktion dessen. Es war einfacher HTTP, welcher die signierten Video empfangen hat, diese abgespeichert hat und schließlich auf Anfrage des Consumer zur Verfügung gestellt hat.

Consumer

Der Consumer war eine Webseite, gebaut mit Svelte4, und bestand aus drei Teilen:

  1. dash.js5 Player: spielt Live Stream ab
    + Plug-in für die Valdierung der Segment mit c2pa.js6, welches ich ebenfalls modifiziert habe + Plug-in zur Anzeige von invaliden Segmente auf der Timeline des Video Players
  2. C2PA Manifest Viewer: zeigt das extrahierte C2PA Manifest an
  3. Hash Visualisierung: stellt die Hashing Methode dar

Live Stream signieren 1

Mein erster Versuch einen Live Stream zu signieren, war es stur die Video Signierung auf einen Live Stream anzuwenden. Das hat ohne Probleme funktioniert und das der Live Stream wurde signiert und von Client abgespielt und auch korrekt validert. Jedoch bedeutet dieser Ansatz, dass mit jedem neuen Video Segment, das erstellt wird, dass der gesamte Live Stream erneut komplett von Anfang signiert wird, da der Live Stream als Video angesehen wird.

Das hatte zur Folge, dass je länger der Live Stream läuft, desto länger dauert der Signierungsprozess und nach kurzer Zeit hatte das Signieren länger gedauert als jedes Segment lang war, wodurch der Live Stream in stocken geraten ist.

Live Stream signieren 2

Mein nächster Versuch machte Nutzung von der Tatsache, dass in dem C2PA Manifest der Merkle Tree in mehrere Teil geteilt werden konnte. Somit habe ich den Signierungsprozess so angepasst, dass immer 8 Segmente zu einem Merkle Tree zusammengefasst wurden.

Dies hatte zur Folge, dass die Dauer der Signierung nicht mehr linear länger wurde, da die Anzahl quasi auf ein Video mit acht Segmenten reduziert wurde. Jedoch hatte dies wiederum auch zur Folge, dass es jetzt theoretisch möglich einener dieser achter Blöcken zu manipulieren, da es keinen Zusammenhang zwischen diesen Blöcken gab. Des Weiteren wurde das C2PA Manifest immer größer, da mit jedem achtem Segment ein neuer Merkle Tree hinzu kam.

Live Stream signieren 3

Mein finaler Versuch hat sich komplett von dem Merkle Tree distanziert, somit auch von der technischen Spezifiaktion, und hat stattdessen eine Art Hashkette verwendet. Hierfür habe ich einfach den Hash jedes einzelnen Segments mit dessen Vorgänger Segment zusammen gehasht und dieses Ergebniss als Referenzwert verwendet.

Damit habe ich die Dauer der Signierung noch weiter reduziert auf nur ein einzelnes Segment und dazu auch noch den weiteren Angriffspunkt der getrennten achter Gruppen.

  1. Webseite c2pa.org ↩ ↩2 ↩3

  2. GitHub c2pa-rs ↩

  3. GitHub c2patool Fork ↩

  4. Webseite svelte.dev ↩

  5. GitHub dash.js ↩

  6. GitHub c2pa.js ↩

Education

  1. Abitur: 2010-2016
  2. Bachelor: 2018-2024
  3. Master: 2024-2025

Master - Computer Engineering

  • Start: Sommersemester 2024 (04/2024)
  • Ende: Sommersemester 2025 (08/25)
  • Gesamtnote: 2,1 / gut
  • Abschlussarbeit:
    • Titel: Design and Implementation of Content Provenance using C2PA Signatures in Live Streaming
    • Note: 1,7 / gut

Abschlussarbeit

Der Abschnitt aus meinem Beruflicher Werdegang Content Provenance and Authenticity beinhaltet bereits alle relevanten Informationen.

Module

Eine Auswahl von Modulen, die ich belagt habe und nennenswerte Fähigkeiten belegen:

Web Service Engineering

In diesem Module wurde eine Projektarbeit in enger Zusammenarbeit mit dem BMW Motorrad Werk in Berlin Spandau angeboten. In kleinen Gruppen bekamen wir jeweils ein Projekt zugewiesen, welches sich mit einem realen Problem in der Fertigung von Motorräder in diesem Werk beschäftigten.

In diesem Pojekt wurde mit sensitiven Daten und Einsichten in die echte Produktionskette gearbeit und die erbrauchten Leistungen kommen tatsächlich auch in der Produktion zum Einsatz. Aus diesem Grund mussten alle Teilnehmer ein NDA unterzeichen und deshalb kann ich sowohl nicht sehr genau ins Detail gehen, sowie das Entergebnis veröffentlichen.

Aufgabe in meinem Projekt war es ein Tool zu bauen, welches die aufgezeichneten Strecken jedes Bauteiles eines bestimmten Fertigunsabschnitts analysiert, um es möglich zu machen, Engpässe in der Produktions zu erkennen und diesen dann zu verbessern.

Dieses Tool besteht aus einem Go Backend und einer Svelte GUI.
Das Backend ist in der Lage eine enorme Menge von rohen Sensordaten, welche größtenteils aus menschenunleserlichen Teile bestand, in wenigen Sekunden parallel einzulesen, die relevanten Daten herauszufiltern, in einer strukturierte Form umzuwandeln und schließlich eine Reihe an vorgefertigten Datenplots zuerstellen.
Die GUI bietet eine leicht zubedienende Oberfläche für das Backend mit der Möglichkeit den Datensatz nach bestimmten Parametern zu filtern.

Grundlagen der automatischen Spracherkennung

In diesem Modul habe ich meinen eigenes Spracherkennungsmodell in Python gebaut.

Die Ergebnisse sind in meinem Repository zu sehen.

Grundlagen des Softwaretestens

In diesem Modul wurden die Grundlagen des Testens von Software mit Java vermittelt.

Die Ergebnisse sind in meinem Repository zu sehen.

Speech and Audio Technology in Medicine Seminar

In diesem Seminar habe ich mich mit der Independent Component Analysis (ICA) auseinandergesetzt.

Mit dem ICA Verfahren ist es möglich eine Vielzahl von vermischten Signalen mit der Hilfe von vielen Aufnahmen aus verschiedenen Positionen voneinander zu trennen. Für das Bestehen dieses Seminars habe ich eine Präsentation gehalten und eine ausführliche Demo mit Rust geschrieben. In der Demo werden zunächst zwei isolierte Audioaufnahmen zusammengemischt, mit der FastICA wieder getrennt und während diesem Vorgang werden alle Audiodateien abgespeichert und Datenplots zur Visualisierung der Audiosignalen erstellt.

Die Ergebnisse sind in meinem Repository zu sehen.

Bachelor - Technische Informatik

  • Start: Wintersemester 2018 (10/2018)
  • End: Wintersemester 2023 (01/2024)
  • Gesamtnote: 2,7 / befriedigend
  • Abschlussarbeit:
    • Titel: Design and Implementation of Media Streaming using WebTransport and QUIC
    • Note: 1,3 / sehr gut

Abschlussarbeit

Der Abschnitte aus meinem Beruflichen Werdegang Media Streaming using QUIC/WebTransport/HTTP3 beinhaltet bereits die wesentlichen Informationen zu meiner Abschlussarbeit.

Das Ziel dieser Arbeit war zum einen mein vorherig in Go erstelltes Testbed nun in Rust zu erstellen und schließlich zu vergleichen. Im Allgemeinen ist Rust eine Programmiersprache, welche eine deutlich bessere Leistung gegenüber Go bieten kann. Jedoch kommt noch dazu, dass zu dem damaligen Zeitpunkt die verwendete WebTransport Bibliothek in Go den Congestion Control Algorithmus CUBIC. Die WebTransport Bibliothek in Rust verwendete diesen ebenfalls, jedoch war es möglich diesem auf BBR zu wechseln. Laut Expernenmeinungen damals sollte BRR nochmals eine bessere Leistung gegenüber CUBUC aufweisen.

Module

Eine Auswahl von Modulen, die ich belagt habe und nennenswerte Fähigkeiten belegen:

Rechnernetze und Verteile Systeme

In diesem Module wurden die Grundlagen der Netzwerkprogrammierung vermittelt, wie z.b. das ISO/OSI Modell und diverse Transportprotokolle, wie TCP, UDP, HTTP, NTP, etc.

Des Weiteren wurden alle praktischen Aufgaben mit der Programmiersprache C getätigt und Tools, wie Postman und Wireshark.

Algorithmen und Datenstrukturen

Hier wurden anhand der Programmiersprache Java die Kenntnisse von diversen Algorithmen und die Grundlagen von Datenstrukturen gelehrt.

Softwareentwicklung und Programmierparadigmen

In diesem Module wurden ich allgemeine Praktiken der Softwareentwicklung, wie SCRUM, Agile, Wasserfall-Modell und Weitere, eingeführt. Sowie typische Best-Practices für gute Softwareentwicklung, wie Testcoverage, Dokumentation und Codemetriken, wie Lines-of-Code, Nesting-Depth, etc. Des Weiteren wurde wir in die funktionale Programmierung anhand von Haskell und Prolog eingewiesen.

Diese theoretischen Themen wurden durch eine praktische Hausaufgabe in Java geprüft.

Betriebssystempraktikum - C

In diesem Module wurden wir in die Grundbausteine eines Betriebssystems eingeführt und haben im laufe des Semesters unser eigenen Betriebssystem in C für ein Raspberry Pie entwickelt.

Praktikum Algorithmen und Datenstrukturen

In diesem Projekt haben in einer Gruppe eine typische Softwareentwicklung durchgeführt. Wir haben zunächst ein ausführliches Konzept erstellt, wie wir das Projekt durchführen, einschließlich die Aufgabenaufteilung, Zeitplan, Meilenstenvorsätze, etc. Szenario dieses Projektes war es ein System zubauen, welches einen automatisierten Feuerlöschroboter betreibt.

Unsere Aufgabe war es eine Anwendung zu entwickeln, welche einen Roboter steuert. Dieser Roboter sollte mit einem effizienten Algorithmus eine ideale Route auf einem Plan abfahren. Diese Aufgabe haben wir in drei Teile unterteilt: GUI, Algorithmus und Robotersteuerung. Die GUI und der Algorithmus wurden in Java umgesetzt und die Robotersteuerung, für welche ich und ein weiterer Student verantwortlich waren, wurde in Python geschrieben.

Für die Steuerung wurde Python gewählt, da in dieser Sprache die beste SDK für den gegenen Roboter (Sphero Bolt) zur Verfügung stand. Der Versuchsaufbau war ein DIN A0 Plakat, auf dem ich diverse Punkte in verschiedenene Farben und Verbindungen zwischen diesen mit Glebeband geklebt und eine Kamera, welche dieses Plakat gefilmt hat.
Mit der Computer Vision Bibliothek opencv1 wurde das Kamerabild in Echtzeit abgetastet und verarbeitet. Der erste Schritt war die Verfassung des Plakates, mit Hilfe von shape detection wurde das Rechteck des Plakates verfasst und dann wurde das Kamerabild auf exakt diese Form reduziert. Als nächstes mussten die aufgeklebten Punkte erkannt werden, dies haben wir durch eine einfache Farbfilterung umgesetzt. Normale Punkte waren blaues Klebeband und “brennende” Punkte waren rot. Zu den Punkten mussten ebenfalls die Verbindungen zwischen diesen erkannt werden, auch hier haben wir die Farbe des Klebeband ausgenutzt, welches in diesem Falle schwarz war. Der Robot wurde an eine beliebe Position auf das Plakat gesetzt. Dieser hatte auf der Oberseite eine LED-Matrix, welche für genutzt haben dem Roboter eine bestimmte Farbe zugeben, um dessen Position zu bestimmen. Mit diesen Daten waren wir in der Lage die gesamte “Karte” digital zu rekonstruieren und diese an die GUI vermittelt.

In der GUI konnte man dann ein paar Punkte auswählen, die der Roboter mindestens abfahren sollte. Der Algorithmus hat dann den kürzesten Weg ausgerechnet, alle dieser Punkte abzufahren. Dieser Weg wurde zurück an unsere Steuerung gegeben. Schließlich mussten wir noch die Orientierung des Roboter bestimmen. Wir haben einfach den Roboter eine kleine Stück geradeausfahren lassen und dann zusammen mit der Ausgangsposition konnten wir bestimmen in welche Richtung der Roboter schaut. Damit hatten wir alles zusammen, den Roboter seine gebrechnete Route fahren zu lassen.

Computer Graphics 1

Mit Hilfe der three.js2 3D JavaScript Bibliothek wurden die Grundlagen der Computergrafikentwicklung vermittelt.

Projekt Kommunikationssysteme

In diesem Projekt haben wir mit dem BloodVoyagerS im Simulationsframework ns-3 in C++ untersucht, ob es möglich ist mit Terahetz-Signalen das Blut im menschlichen Körper zu untersuchen, ohne dass die Haut durch einen physischen Sensor durchdrungen werden muss.

  1. PyPi opencv ↩

  2. Webseite threejs.org ↩

Private Projects

Auf den folgenden Seite habe ich eine Übersicht über alle Projekt, die ich in meiner Freizeit gemacht habe, zusammengetragen.

Rust

Eine komplette Übersicht über alle privaten Rust Projekte, die ich gemacht habe oder gerade mache.

Inhalt

Common Media Data Parser

Common Media Client/Server Data (CMCD, CMSD) sind Metriken, welches während eines Media Streams zwischen Client und Server ausgetauscht werden. Diese Daten können verwendet werden um den Stream dynamisch anzupassen, damit dieser das bestmögliche Erlebnis bieten kann.

cmcd

Ein Parser von CMCD aus HTTP Header, Query Parameter oder JSON Body.

  • Release: crates.io
  • Repository: codeberg.org
  • Version: 0.1.0
  • Status: In Arbeit
    • Kernfunktionalität generallisieren, damit ich diese für CMSD verwenden kann
    • API Verbesserungen

cmsd

Ein Parser von CMSD aus HTTP Header, Query Parameter oder JSON Body.

  • Release: <tbd>
  • Repository: <tbd>
  • Version: <tbd>
  • Status: In Planung
    • Sobald ich CMCD fertig gestellt habe

Markdown Component für dioxus

dioxus ist ein cross-platform Framework für Fullstack Apps. Markdown ist eine einfache Auszeichnungssprache für strukturierte Dokumentation.

Diese Projekte bilden eine Brücken zwischen diesen beiden Teilen.

markdown-dx

Eine dioxus Komponente, welche Markdown-Text interpretiert rendert. Eine einfache Demonstration kann man auf meiner git-page sehen.

  • Release: crates.io
  • Repository: codeberg.org
  • Version: 0.1.0
  • Status: In Arbeit
    • Aktuell wird inline HTML und mathematische Ausdrücke mit purem HTML eingefügt (Sicherheitsrisiko: XSS!)
    • Syntax Highlighting in Code Blöcken

rast-html-core

Ein stupider HTML/XML Parser, welcher Text in einen pseudo-AST (Abstract Syntax Tree) umwandelt. Ebenfalls ist es möglich ein Dokument komplett zuerstellen.

rast-html

Erweiterung der Kernimplemenation rast-html-core durch spezifische HTML Elemente und HTML-Säuberung um Cross-Site-Sripting (XSS) zu verhindern. Ebenfalls werden rast-svg und rast-mathml integriert sein, um ein Komplettpacket anzubieten.

  • Release: <tbd>
  • Repository: codeberg.org
  • Version: <tbd>
  • Status: In Arbeit

rast-svg

Erweiterung der Kernimplemenation rast-html-core durch spezifische SVG Elemente und HTML-Säuberung um Cross-Site-Sripting (XSS) zu verhindern.

  • Release: <tbd>
  • Repository: codeberg.org
  • Version: <tbd>
  • Status: In Arbeit

rast-mathml

Erweiterung der Kernimplemenation rast-html-core durch spezifische MathML Elemente und HTML-Säuberung um Cross-Site-Sripting (XSS) zu verhindern.

  • Release: <tbd>
  • Repository: codeberg.org
  • Version: <tbd>
  • Status: In Arbeit

Media over QUIC

Diverse Implementationen um mein eigene MOQT Protkoll zu entwickeln.

varint_core

Die Kernimplemenation der Basisdatentypen der QUIC und MOQT Spezifikationen und dessen Parsen von einem Bytestream. Diesen Datentypen verwenden Variable Length Integers (varint), um Daten möglichst effizient zu encoden.

  • Release: tbd
  • Repository: codeberg.org
  • Version: 0.0.1
  • Status: In Arbeit
    • Anpassung an die neudefinierten Datentypen aus dem MOQT Draft
    • Überarbeitung der API

varint_derive

Ein Derive Macro, welches ermöglicht das Parsen von abstrakte Datentypen aus den QUIC und MOQT Spezifikationen mittels varint automatisch zu generieren.

  • Release: tbd
  • Repository: codeberg.org
  • Version: 0.0.1
  • Status: In Arbeit
    • ggfs. Änderung die aus varint_core entstehen

varintege-rs

Die Kombination aus varint_core und varint_derive um eine API für alles anzubieten.

  • Release: tbd
  • Repository: codeberg.org
  • Version: 0.0.1
  • Status: Release sobald varint_core fertig ist

moqt-rs

Meine MOQT Implementation. Arbeit an diesem Projekt ist zur Zeit Unterbrochen bis ich alles Andere abgeschlossen habe.

dioxus

SWGOH TB Planner

Eine sehr einfaches, kostenloses Tool für das Videospiel Star Wars: Galaxy of Heroes, um eine Übersicht für eine Gruppenaktivität in dem Spiel zu erstellen.

Zufinden ist dies auf einer meiner git-pages und der Code dazu in meinem Respository.

Hobbys

In meiner Freizeit verbringe ich mit einigen abwechselungsreichen Aktivitäten:

  • Programmieren
    • die Sprache Rust interessiert mich zur Zeit am meisten
    • alles was ich gemacht habe sind in meinen Private Projekte zu sehen
  • Videospiele
    • gelegentlich verteibe ich meine Zeit mit diversen Spielen
  • Bücher
    • jeden Abend lese ich mindestens eine Stunde
    • ausschlißelich in Englisch
    • besonders gerne lese ich Science-Fiction
      • alles um Star Wars
      • Frank Herbert: Dune
      • James S.A. Corey: The Expanse
      • Andy Weir: The Martian, Artemis, Project Hail Mary
      • Isaac Asimov: Robot, Galactic Empire, Foundation Serien
      • Richard Morgan: Altered Carbon
    • aber auch gelegentlich Fantasy
      • J. R. R. Tolkien: The Hobbit, The Lord of the Rings
      • Christopher Tolkien: The Silmarillion, The Children of Hurin, Beren and Luthien, The Fall of Gondolin
      • Andrzej Sapkowski: The Witcher
    • und noch vieles Weitere wie
      • Mary Shelly: Frankenstein
      • Bram Stoker: Dracula
      • Sir Conan Arthur Doyle: Sherlock Holmes
  • Sport
    • mindestens dreimal die Woche gehen ich ins Sportstudio
      • hauptsächlich Laufband
      • gelegentlich auch ein paar Kraftgeräte
    • so oft wie möglich versuche ich Fahrrad zu fahren
  • Kino / Filme / Series
    • ich liebe es Filme im Kino auf der großen Leihenwand zu sehen
    • ebenso sammle ich pysische Medien, besonders 4k Blu-Ray
    • Genre-mäßig überdecken sich meine Vorlieben von Filmen und Serien mit den Büchern, die ich lese