Manchmal, wenn man schon eine Weile als Software-Ingenieur arbeitet, lernt man, in welchen Bereichen des Handwerks noch Unklarheiten bestehen.
Sie wissen genau, wie es geht, Sie kennen alle Probleme, die auftreten können, und Sie gehen solche Bereiche mit besonderer Aufmerksamkeit an und lachen laut, wenn jemand glaubt, er könne es schneller und besser schaffen, ohne zu wissen, was auf ihn zukommt.
Dies ist die Geschichte eines dieser Bereiche, in denen ich im Laufe meiner Karriere viel Erfahrung gesammelt habe.
Irgendwann im Jahr 2007 war YouTube bereits zwei Jahre alt, was bedeutete, dass noch immer fast niemand davon wusste. Die Leute nahmen Videos in SD auf und speicherten sie auf CDs oder DVDs.
Damals hätte niemand gedacht, dass man jedes Video im Internet hochladen würde, weil der Download sehr teuer war.
Na ja, außer Torrents vielleicht. Es gab jedoch bereits Apps, mit denen Sie Ihren Bildschirm aufzeichnen und Untertitel hinzufügen konnten. Daher war es interessant zu sehen, ob Sie Video-Tutorials online hochladen können.
Nachdem dies geschehen war, kaufte ich einen CentOS-Server und begann mit der Erstellung einer Online-Video-Tutorial-Site.
Damit es funktionierte, musste ich zwei Dinge herausfinden: wie ich es den Leuten ermöglichen kann, Tutorials hochzuladen, und wie ich es den Leuten ermöglichen kann, sie anzuschauen.
Das Hochladen eines Videos war ganz einfach, dachte ich. Sie fügen einfach ein Eingabefeld in HTML hinzu und erhalten die Datei auf dem Server.
Aber es kam schwieriger als vorhergesagt. Das Erste war die Größe des Videos und das Zweite die Qualität der Internetverbindung.
Mein Server mit PHP, der einzigen Sprache, die alles bot, was Sie brauchten (und das immer noch tut), war großartig. Es lief auf Apache und später auf Nginx.
Die Sache mit den frühen Versionen von Ngnix war, dass eine solche Nutzlast nicht erwartet wurde. Ich musste mehrere Einstellungen konfigurieren, damit der Server bis zu 30–60 Minuten Dauer-Upload und die Größe der Übertragung akzeptieren kann. Es bedurfte einiger Experimente und schließlich funktionierte es.
Ein weiterer problematischer Punkt war die Art und Weise, wie Ngnix Prozesse aufspaltete. Die frühen Versionen von Ngnix hatten einige Fehler, die dazu führten, dass Forks unerwartet hängen blieben.
Ein solcher von einem Benutzer aufgehängter Fork wurde später anderen Benutzern zugewiesen, was bedeutete, dass diese ebenfalls keine Videos hochladen konnten.
Ich musste die Informationen darüber speichern, wer welchen Prozess verwendet hat, und sie zum richtigen Zeitpunkt beenden. Außerdem musste ich regelmäßig jede Nacht alle Prozesse abbrechen, da sich tagsüber Fehler ansammelten.
Nach vielen Stunden, die mit der Nginx- und PHP-Konfiguration verbracht wurden, begann das Hochladen schließlich zu funktionieren.
Der nächste Schritt bestand darin, den Benutzern Videos anzuzeigen. Zu dieser Zeit war ein Online-Player verfügbar. Ich erinnere mich nicht an den Namen, aber er war gut und bot Untertitel. Das war wichtig, weil ich wollte, dass jeder aus den Video-Tutorials lernen kann.
Es trat jedoch ein anderes Problem auf. Das Abspielen eines Rohvideos war sehr schwierig. Bei einer recht schnellen Verbindung kam es häufig zu Störungen und manchmal brach sogar der Browser ab.
Es gab bereits ffmpeg, also habe ich herausgefunden, wie ich das Video optimieren kann. Der wichtige Aspekt von Video-Tutorials besteht darin, dass Sie den gesamten Bildschirm in hoher Qualität anzeigen möchten. Denn sonst sieht man nicht, was man anklickt und welche Texte auf dem Monitor angezeigt werden.
Im Vergleich zu den damaligen Live-Aufzeichnungen stellten Video-Tutorials höhere Anforderungen an die Qualität (deshalb waren Video-Tutorials viele, viele Jahre lang kein fester Bestandteil von YouTube).
Es bedurfte vieler Experimente mit ffmpeg, um ein Schnäppchen für hohe Qualität und kleine Videogröße zu machen. Natürlich ging das nicht sofort, also gab es einen Cron-Job, der MySQL-Datenbanken abfragte und Videos fand, die noch nicht richtig konvertiert waren.
Es war auch wichtig zu prüfen, ob ein Video nicht nur von ffmpeg produziert wurde. Obwohl ffmpeg großartig war, gefiel ihm manchmal das Video- oder Audiokomprimierungsformat oder sogar die Größe des Eingabevideos nicht. Als Ergebnis wurde ein Ausgabevideo erzeugt, das jedoch schwarz war.
Deshalb habe ich einen weiteren Cron-Job hinzugefügt. Seine Aufgabe bestand darin, ffmpeg erneut für das Ausgabevideo auszuführen, dessen Größe und Auflösung abzulesen und ein Bild zu erfassen, das ich auch für ein Miniaturbild benötigte. Als Nächstes überprüfte der Prozess die Pixel auf dem Miniaturbild, um festzustellen, ob es schwarz war. Wenn keine Fehler vorlagen und das Miniaturbild nicht schwarz war, wurde davon ausgegangen, dass die Konvertierung erfolgreich war.
Ich dachte, es würde ausreichen, aber es stellte sich heraus, dass das nicht der Fall war. Denn manchmal hängen ffmpeg oder die andere Bibliothek einfach. Das bedeutet, dass auch der Konvertierungs- oder Validierungsprozess hängengeblieben ist und die Informationen nicht gespeichert werden konnten, wenn ein Fehler aufgetreten ist.
Deshalb habe ich einen weiteren Cron-Prozess hinzugefügt. Der dritte Prozess war die Überprüfung der beiden vorherigen Prozesse. Es überprüfte in der Datenbank, wann ein Konvertierungsprozess gestartet wurde, wann es das letzte Mal gemeldet hatte, dass es aktiv war, und verglich es mit der aktuellen Zeit.
Wenn eine Konvertierung beispielsweise drei Stunden lang nicht reagiert hat, habe ich die Konvertierung als fehlgeschlagen markiert und zur erneuten Ausführung hinzugefügt. Wenn ein Validierungsprozess nach 30 Minuten Arbeit nicht reagierte, schlug die Datenbankvalidierung fehl, sodass das Video von Grund auf konvertiert und Prozesse abgebrochen werden mussten.
Normalerweise hat das geholfen. Wenn es beim dritten Mal nicht funktioniert hat, hat das System eine E-Mail gesendet, etwas stimmt nicht.
Irgendwann funktionierte das System und die Leute konnten Videos hochladen. Videos wurden konvertiert und mit Miniaturansicht und Untertiteln auf der Seite angezeigt.
Es war ein interessantes Projekt, an dem ich über 400 Stunden gearbeitet habe. Es hat mir viel über Video-, Audioverarbeitung und Validierung beigebracht.
Aber es hat mich auch gelehrt, dass der Umgang mit Uploads ein heikler Bereich ist, auf den ich mich konzentrieren muss. Es hat sich ausgezahlt…
Man könnte meinen, dass die Situation jetzt, im Jahr 2023, anders ist. Aber es ist nicht. Sicherlich hat sich einiges geändert. Es ist einfacher, Rechenleistung und Speicherplatz zu erhalten. Internetverbindungen sind besser. Die Tools sind besser und verfügen über eine detailliertere Dokumentation.
Dennoch schlagen bei den Standardeinstellungen einige Uploads aufgrund der Größe fehl. Ein Standard-Upload-Formular funktioniert auf Android-Geräten nicht. Ich sehe dieses Problem bei vielen Web-Apps immer wieder.
Der Umgang mit mehreren Videoformaten und sogar Fotos ist schwierig. Zumal es jetzt neue experimentelle Formate gibt.
Vor einigen Jahren habe ich beispielsweise ein Content-Management- und Planungssystem für soziale Medien entwickelt.
Es musste Vermarktern die Möglichkeit bieten, das hochgeladene Foto zu bearbeiten. Nur grundlegende Dinge wie Zuschneiden und Filter. Selbst bei Verwendung der neuesten Bibliotheken war es nicht 100 % zuverlässig und erforderte viele Optimierungen, um es zumindest in einem akzeptablen Umfang nutzbar zu machen.
In vielen Situationen ist das Hochladen einer Datei ein wichtiger Schritt eines Prozesses. Wenn Sie beispielsweise ein langes Formular ausfüllen und im letzten Schritt eine Datei hochladen müssen.
Sollte der Upload aus irgendeinem Grund fehlschlagen, müssen Sie den Benutzer davor schützen, alle bereits eingegebenen Daten zu verlieren.
Sie müssen mit einem Szenario umgehen, in dem der Upload fehlschlägt, oder mit einem weiteren Prozess, den Sie auf die Datei anwenden.
Eine Möglichkeit, einige dieser Probleme zu lösen, besteht darin, die Benutzer auf Größe und Format zu beschränken. Es klingt verlockend.
Ich habe kürzlich an einem E-Commerce-Projekt gearbeitet, bei dem Menschen durch das Hochladen von Fotos ihre eigenen Produkte erstellen konnten. Die App begrenzte jedoch die Bildgröße auf 2 MB und eine Auflösung von 1000 x 1000 Pixel.
Es gab einen Vorschlag, diese Grenzwerte auf 3 MB und 2000 x 2000 Pixel zu erhöhen. Ich holte mein Handy heraus, machte ein Foto und zeigte den Leuten, wie groß das Foto war.
Es war 4 MB groß und etwa 3000 x 3000 Pixel groß. Deshalb wurde ein anderer Vorschlag gemacht, um dies zu berücksichtigen. Deshalb habe ich die Auflösung, mit der mein Telefon ein Foto aufnimmt, erhöht und uns gesagt, dass wir diese Beschränkungen ganz aufheben müssen.
Es gab auch den Vorschlag, die Beschränkungen beizubehalten, da Benutzer Fotos konvertieren und vor dem Hochladen verkleinern können.
Es ist richtig. Aber die meisten Menschen wissen nicht, wie es geht, wollen nicht darüber nachdenken und finden es möglicherweise schwierig. Ich konnte den Kunden und das Team davon überzeugen, die Grenzwerte insgesamt aufzuheben.
Das war ein toller Schachzug, weil er den Umsatz drastisch steigerte und auch die Ausstiegsrate sank, was beweist, dass die Leute Produkte auf ihren Handys kaufen wollten, aber sie wurden durch die Anforderungen daran gehindert. Die Aufhebung der Beschränkungen war eine einfache Lösung, um vielen Menschen den Kauf der gewünschten Produkte zu ermöglichen.
Das Hochladen von Dateien ist ein schwieriges Thema, aber in manchen Fällen kann es für den Umsatz und die Kundenzufriedenheit (und damit auch für den Umsatz) von entscheidender Bedeutung sein.
Aus diesem Grund lege ich besonderes Augenmerk auf die Bereiche der von mir entwickelten Systeme, die das Hochladen von Dateien verarbeiten, da dies der Bereich ist, der sich am stärksten auf das Kundengeschäft auswirken kann.
Haben Sie Geschichten zum Thema Datei-Upload? Teilen Sie es im Kommentar!
Klicken Sie auch auf das Herzsymbol, liken und teilen Sie es in den sozialen Medien. Es motiviert mich, mehr über solche Themen zu schreiben!
Wenn Sie als Softwareentwickler nicht zu viel darüber nachdenken möchten, schauen Sie sich auch Filestack an. Es handelt sich um eine API zur Verarbeitung von Javascript-Datei-Uploads. Sie sponsern einen Wettbewerb, an dem ich mit dieser Geschichte teilnehme. Filestack und HackerNoon – danke für die Motivation zum Teilen! Es war großartig, es zu tun!