FLV-Cache-Catch-Converter

Inhalt

• 1. FLV-Format offline
  • 1.1. CPU-Fresserei
  • 1.2. Streaming & Online-Navigation
  • 1.3. Wo ist der Speicher-Button?
  • 1.4. Catch from Cache as Cache can
  • 1.5. Open Source FFMPEG.EXE
• 2. Mein FLV-Cache-Catch-Converter (FLV-CCC)
  • 2.1. Übersicht
  • 2.2. Unit "main_u.pas"
    • 2.2.1. Deklarationen
    • 2.2.2. Nach dem Start von "FLV-CCC" ...
    • 2.2.3. Ein Timer regelt alles
  • 2.3. Unit "cache_u.pas"
    • 2.3.1. Deklarationen
    • 2.3.2. Füllung der Cache-StringGrid
    • 2.3.3. Wo sind die Browser-Cache-Ordner?
    • 2.3.4. Der Scan-Vorgang
    • 2.3.5. Movie-Stream-Detection
    • 2.3.6. Catch a movie
    • 2.3.7. Timecodes In FLVs
    • 2.3.8. Eindeutigkeit bei Quelle und Ziel
  • 2.4. Unit "convert_u.pas"
    • 2.4.1. Threads
    • 2.4.2. Spooler leeren
    • 2.4.3. Von Movie-Stream zu MPG
    • 2.4.4. Ausführen und Warten
• 3. Epilog
• 4. Download

1. FLV-Format offline

Eigentlich kann ich es ja nicht leiden, das dreckige FLV-Format (Flash Video).

1.1. CPU-Fresserei

Das Format an sich, der Codec oder was auch immer (?) ist ... anspruchsvoll. Ohne ordentlich CPU-Power ruckeln die Videos. Navigation darin ist ein Geduldsspiel. Und endet oft im Nirvana - meine Tools fliegen jedenfalls regelmässig ab, wenn viel innerhalb von FLVs herumgesprungen wird.

1.2. Streaming & Online-Navigation

Aber: Die Dinger sind auch klein. Und über in Webseiten integrierte Player (Web-Player) werden FLVs unmittelbar abgespielt, ohne dass man sie zuvor komplett herunterladen muss. Manchmal kann man sogar online in ihnen navigieren. Also z.B. direkt zum Filmende springen. Prima Sache, man kann so gleich zum Wesentlichen kommen.

YouTube: Eine schier unerschöpfliche Quelle an FLV-Movies. Im Gegensatz zu MPGs und AVIs werden Movie-Streams bereits abgespielt, so wie ein kleiner Teil vom Server geladen ist. Die Web-Player erlauben häufig eine Online-Navigation. Bei obigem Video könnte man so gleich schauen, ob Homer es schafft, sich mit der Waffe selbst zu verletzen.

1.3. Wo ist der Speicher-Button?

Dummerweise - und sicher nicht zufällig - erlauben es die wenigsten Web-Player, die FLVs auch auf Festplatte zu speichern. Online gucken ist also okay, aber offline, das sollen wir nicht?

Nö, ich mag offline. Also schaute ich mich nach einem Mittelchen um ...

1.4. Catch from Cache as Cache can

Alles, was man sich so mit dem Browser aus dem Web zieht, wird in dessen Cache zwischengelagert. Glücklicherweise ist dieser temporäre Speicherhort auf Festplatte ausgelagert, also keine reine Memory-Geschichte. Wodurch man ungleich einfacher an ihn dran kommt.

IE-Cache: Zwischenspeicher auf der Festplatte für alle Downloads des Browsers. Egal, ob Movies, Bilder, JavaScript oder HTML-Seiten, hier sammelt sich alles an, was den Weg vom Server zum Client geschafft hat.

Okay, im Cache kann man sie dann auch meistens tatsächlich finden, die FLVs, die man sich (gerade) online betrachtet.

Cache ist aber temporär und dynamisch; da ändert sich ständig etwas, kommt dazu und verschwindet wieder. Files, auf die der Browser aktuell zugreift, deren Download also noch läuft, erkennt man darüber hinaus nicht als solche. Und was in so mancher Cache-Datei steckt, ob nun Bild, Movie oder HTML-Seite, ist auch nicht immer gleich zu erkennen - insbesondere beim Firefox, dessen Cache-Files gänzlich ohne Extensions daherkommen.

Naheliegend also, ein kleines Tool zu basteln, welches einem die FLVs quasi automatisch aus dem Cache fischt. Klar, die Idee ist so trivial, dass schon viele Programmierer darauf gekommen sind. An Cache-Browsern herrscht kein Mangel.

Mein bescheidener Beitrag dazu, der "FLV-Cache-Catch-Converter", hat jedoch ein paar Gimmicks zusätzlich drauf. Wie der Name schon sagt, schnappt er sich nicht nur die FLVs im Cache, sondern konvertiert sie auch gleich noch in ein "besseres" Format, nämlich MPGs (sofern man dies möchte). Zudem erkennt das Tool (teilweise) den Start-Time-Code von etappenweise geladenen FLV-Parts und baut diesen in den Dateinamen ein. Dadurch lassen sich die einzelnen Movie-Stücke später wieder relativ leicht zeitlich korrekt zusammensetzen.

Ach ja, trotz des Namens "FLV-CCC" erkennt das Tool neben dem FLV-Format auch noch zwei weitere Movie-Stream-Formate, nämlich WMV und MP4. Auch diese Datei-Typen werden also im Cache identifiziert und gegebenenfalls in MPGs konvertiert.

1.5. Open Source FFMPEG.EXE

MPGs wurden auf dieser Homepage bereits in einem früheren Tutorial behandelt: siehe Video-Splitter. Die Manipulation oder Generierung von MPGs ist nicht eben einfach. Ebensolches gilt für FLVs; zu deren innerem Aufbau habe ich im Web sogar noch weniger konkrete Information gefunden wie seiner Zeit zu den MPGs. Die Programmierung einer Konvertierungsroutine von FLV nach MPG liess also kein Zuckerschlecken erahnen.

Glücklicherweise gibt es aber Open Source. Darunter auch das Tool FFMPEG.EXE, mit dem man sehr viele verschiedene Movie-Formate bearbeiten kann. Es offeriert dazu eine leistungsfähige API mittels Übergabeparametern. Und da Delphi die Möglichkeit bietet, beliebige EXEs mit Übergabeparametern aufzurufen ...

Wir machen es uns also einfach: Wir konvertieren nicht selbst, sondern lassen konvertieren. Besser als die fähigen Jungs und Mädels vom FFMPEG hätte ich es sowieso nie hinbekommen.

2. Mein FLV-Cache-Catch-Converter (FLV-CCC)

2.1. Übersicht

Der Delphi-Source von FLV-CCC gliedert sich in drei Units:

• "main_u.pas" mit TForm "main_f": Hauptfenster der Applikation. Hierüber werden die Benutzer- und Timer-Ereignisse verwaltet. Ein PageControl bietet dem Anwender zwei Registerseiten an, eine für das Cache-, und eine für das Konvertierungsmanagement.
• "cache_u.pas": unit zur Kapselung aller cache-bezogenen Funktionen.
• "convert_u.pas": unit zur Kapselung aller konvertierungsbezogenen Funktionen.

Im folgenden sehen wir uns die drei Units der Reihenfolge nach an.

2.2. Unit "main_u.pas"

2.2.1. Deklarationen

An die unit "main_u.pas" ist die TForm "main_f" gebunden. Sie stellt das einzige Fenster der Applikation dar. Alle allgemeinen Ereignisse werden hier verarbeitet bzw. an die zuständigen Units "cache_u.pas" und "convert_u.pas" durchgereicht.

Die im Programm verwendeten Konstanten sind:

Hier werden der Anwendungstitel, die Initialisierungsdatei und der Arbeitsordner vorgegeben. Die "_postfix"-Konstanten kommen bei der Konvertierung zum Einsatz, um fertige FLVs von gerade in Arbeit befindlichen FLVs unterscheiden zu können. Je nach Ergebnis der Konvertierung werden die "_flv_"-Konstanten verwendet, um an den Originalnamen angehängt zu werden. Aktive Elemente erhalten die Farbe "_color_on", inaktive die Farbe "_color_off".

Die Klassendeklaration des Hauptfensters "main_f" sieht folgendermassen aus:

Wie man sieht, kommt das Hauptfenster mit sehr wenigen "globalen" Variablen und Funktionen aus. In "homedir" wird der Applikationspfad gesichert, "cache_catch_c" ist ein Zähler für die Anzahl kopierter bzw. verschobener Cache-Files, "cache_check_c" gibt an, wie viele Cache-Files auf "Movie-Stream-Artigkeit" getestet wurden, und die "convert_"-Variablen sind Zähler, die angeben, wie viele MPGs bzw. M1Vs erfolgreich generiert wurden bzw. wie viele Konvertierungen letztlich in die Hose gingen.

2.2.2. Nach dem Start von "FLV-CCC" ...

Schauen wir uns nun den Konstruktor der Hauptform "mainf_" an:

Wir geben der Form den Style "fsstayontop". Dadurch bleibt sie nach dem Start stets im Vordergrund "schweben", über allen anderen Anwendungen. Man kann im Browser also das anvisierte FLV-Movie betrachten und gleichzeitig den Status des zugehörigen Cache-Files im "FLV-CCC" beobachten.

FLV-CCC stay-on-top: Das Fenster von FLV-CCC "schwebt" über allen anderen Anwendungen. Hier ist es der Internet Explorer, in dem gerade ein FLV-Movie von Rihanna abgespielt wird. Wie man erkennt, wurden ca. 1.6 MB des Films geladen. Der Status ist "BLOCKED", d.h., der Download ist noch nicht abgeschlossen.

Falls der Ordner "_dir_work" nicht im aktuellen Verzeichnis der Applikation existiert, wird er angelegt. In diesem Ordner werden alle aufgespürten FLV-Movies abgelegt. Auch die bereits konvertierten Filme bleiben in diesem Verzeichnis lokalisiert (bekommen jedoch eine andere Extension zugewiesen).

Anschliessend wird das INI-File mit diversen Programmparametern eingelesen. Dort wird z.B. die Position des Fensters sowie seine Breite und Höhe gesichert.

Jetzt folgt die Initialisierung der beiden verwendeten Tab-Sheets - "cache_ts" und "convert_ts" - mit ihren darauf befindlichen Komponenten. So wird z.B. die StringGrid "cache_sg" mit dem aktuellen Cache-Inhalt gefüllt sowie eventuell zu konvertierende FLV-Movies in die zugehörigen FileListBox "convert_flb" eingeladen.

Am Schluss wird noch der Timer "timer_t" aktiviert.

2.2.3. Ein Timer regelt alles

Um den Erstaufruf des Timer-Ereignisses zu kennzeichnen, bekommt das Timer-Tag im Konstruktor den Wert "-1" zugewiesen. Der Timer feuert jede Sekunde sein Ereignis ab und bewirkt dadurch jedes Mal den Aufruf der Prozedur "timer_tTimer":

Am Anfang wird geprüft, ob die Prozedur zum ersten Mal aufgerufen wird. Dies ist direkt nach Programmstart der Fall. Die Cache-StringGrid wird daraufhin aktualisiert. Das kann, je nach Grösse des Caches, recht lange dauern (und wurde alleine aus diesem Grund in das Timer-Ereignis gepackt, denn zu diesem Zeitpunkt ist wenigstens das Hauptfenster von "FLV-CCC" bereits zu sehen, anders als etwa noch im "FormCreate"-Ereignis).

Dann wird das Timer-Tag erhöht - und, sowie es grösser als 1 ist, wieder auf 0 gesetzt. Es wechselt also jede Sekunden seinen Wert von 0 nach 1 nach 0 nach 1 usw.

Findet gerade ein Konvertierungsprozess statt, so nutzen wir dieses alternierende Timer-Tag, um im Fensterkopf von FLV-CCC einen "blinkenden" Text auszugeben. Das signalisiert dem Anwender unmittelbar, dass das Tool gerade (noch) am Schuften ist.

Ist der Konvertierungsspooler dagegen im Standby-Modus, so wird im Fensterkopf stattdessen eine kleine Statistik angezeigt, die Auskunft darüber gibt, wie viele MPGs, M1Vs seit Programmstart bereits erfolgreich generiert wurden - und wie oft die Konvertierung misslang.

Anschliessend wird der Konvertierungsspooler (repräsentiert durch die FileListBox "convert_flb") aktualisiert. Ist er zu diesem Zeitpunkt nicht "scharf Geschaltet", werden keine Konvertierungen durchgeführt und wir verlassen wir die Prozedur wieder.

Ansonsten wird geprüft, ob aktuell ein FLV-Movie in Arbeit ist. Ist dem so, machen wir weiter keinen Stress und beenden die Prozedur ebenso.

Theoretisch wäre es ja möglich, mehrere Movies gleichzeitig zu konvertieren. Solche parallelen Prozesse bergen jedoch mannigfaltige Probleme, etwa konkurrierende Ressourcenzugriffe, was u.U. Geschwindigkeitseinbussen gegenüber sequenziellen Abläufen zu Folge haben kann. Das brauchen wir nicht, das wollen wir nicht, also lassen wir es.

Ist der Konvertierungsspooler frei, dann wird ein neuer Thread erzeugt, der den eventuell vorliegenden Spooler-Inhalt abarbeiten wird. Dazu gleich mehr bei der unit "convert_u.pas".

Damit hätten wir das Hauptfenster auch schon weitgehend abgearbeitet. Die restlichen Funktionen und Ereignisbehandlungen des Hauptfensters sind recht trivial, reichen ihre Arbeit auch weitgehend nur an die Units "cache_u.pas" und "convert_u.pas" durch, daher ersparen wir uns hier eine weitere Analyse.

2.3. Unit "cache_u.pas"

2.3.1. Deklarationen

TabSheet-register zur Cache-unit: Hier kann bestimmt werden, welcher Cache verwendet werden soll, der vom IE oder der vom Firefox. Der Cache kann per "Refresh" neu geladen werden. Einträge lassen sich per "Catch" in den Konvertierungsspooler kopieren/verschieben. Über "Delete" können selektierte Cache-Movie-Streams gelöscht werden. Die Checkbox "Use Target Name" erlaubt die Vorgabe eines bestimmten Ziel-Datei-Namens, statt die oft kryptischen Cache-Bezeichnung der originalen Quell-Datei zu verwenden.

In der unit "cache_u.pas" sind alle den Browser-Cache (Internet Explorer und/oder Firefox) Betreffenden Funktionen implementiert. Der Deklarationsteil sieht folgendermassen aus:

Die Konstante "_registry_shell_folder" ist der Basisordner, über den wir später in der Registry die physikalischen Ordnernamen für die Caches von IE und Firefox finden können. Der Typ "tc_inx" dient als index für die Spalten der StringGrid "cache_sg", in die der Cache-Inhalt geladen wird.

Doch beginnen wir von vorne, mit der Initialisierung der Cache-StringGrid:

Zu Beginn erhält die Cache-StringGrid nur eine Zeile mit einer bestimmten Anzahl Spalten ("sg.colcount:=ord(_cache_c);") einer bestimmten Breite ("sg.colwidths[c]:=40;"), die keinerlei Inhalt enthält.

Die letzte Spalte, die (später) den kompletten Cache-Pfad enthält, wird für den Benutzer ausgeblendet; diese Information verwirrt eher, als dass sie Transparenz schafft.

2.3.2. Füllung der Cache-StringGrid

Um die StringGrid "cache_sg" mit den Namen der Movie-Stream-Inhalte zu füllen, die sich aktuell in einem der beiden Browser-Cache-Ordner befinden, verwenden wir die Funktion "refresh":

An die Prozedur wird die Cache-StringGrid übergeben, in die die gefundenen Cache-Inhalte dann eingetragen werden. Ausserdem zwei ListBoxen, die zur Optimierung des Scan-Vorgangs eingesetzt werden. Die boolesche Variable "firefox_ok" gibt an, ob wir den Cache des Firefox-Browsers oder den des Internet Explorers analysieren. "sort_size" teilt der Funktion mit, nach welchem Kriterium die StringGrid sortiert werden soll: Nach der Grösse oder nach dem Dateidatum.

• Die ListBox "cache_work_lb" wird gelöscht
• Wir merken uns den gerade selektierten Eintrag in der StringGrid in "fn"
• In "dir" wird der Pfad zum gewählten Browser-Cache festgehalten
• Es wird eine temporäre Stringlist "sg_sl" erzeugt.
• Über die interne Prozedur "scan_dir" wird die "sg_sl" mit bestimmten Inhalten aus dem gewähltem Cache gefüllt - eben mit diverse Infos (Name, Grösse, Datum ...) zu den darin befindlichen Movie-Streams.
• Die "sg_sl" wird automatisch in gewünschter Weise sortiert, indem die erste "Spalte" eines jeden Eintrags das Sortierkriterium enthält.
• Die "sg_sl" wird in die Cache-StringGrid "sg" übertragen.
• Jetzt wird "sg" durchlaufen und dabei jeweils der breiteste Eintrag je Spalte im array "colwidths" ermittelt.
• Die Spaltenbreiten werden gemäss "colwidths" gesetzt, sodass die Spalten möglichst den kompletten Zellen-Text anzeigen können. Um keine zu breiten Spalten zu bekommen, liegt hier aber das Maximum bei 300 Pixeln.
• Die "sg" wird nach dem zuvor gemerkten markierten Cache-Eintrag "fn" durchsucht. Ist er noch vorhanden, so wird er erneut selektiert.
• Die "sg_sl" wird freigeben.
• Die ListBox "cache_work_sl" wurde während des Scan-Vorgangs mit den Namen aller geprüften Cache-Dateien gefüllt. Ihr Inhalt wird nun auf die "cache_sl" übertragen - all diese Files müssen beim nächsten Durchgang nicht noch einmal überprüft werden.

Alle Movies vom Firefox in der Cache-StringGrid: Hier wurden im Cache des Firefox fünf Movie-Streams gefunden. Der erste wurde zu Testzwecken manuell hineinkopiert und besitzt daher als einziges Movie einen halbwegs sinnvollen Namen plus Extension. Die StringGrid ist nach Datum sortiert, sodass die neuesten Einträge vorne stehen. Alle Movies haben den Status "READY", ihr Download ist also komplett abgeschlossen. Im Fenstertitel sieht man anhand der Zahl hinter "Check", dass beim letzten Refresh insgesamt 98 Cache-Dateien auf Movie-Stream-Artigkeit überprüft wurden.

2.3.3. Wo sind die Browser-Cache-Ordner?

Die physikalischen Pfad auf die Cache-Ordner von IE und Firefox liefern uns die beiden folgenden Funktionen:

Insbesondere das Aufspüren des FF-Caches auf der Festplatte war nicht ganz einfach für mich. Obige Prozedur funktioniert dann auch (vermutlich) nur bei dessen Normal-Version, nicht jedoch beim Firefox Portable. Habe ich aber nicht ausprobiert.

2.3.4. Der Scan-Vorgang

Das eigentliche Auffinden aller Cache-Files geschieht über die interne Prozedur "scan_dir", die in "refresh" aufgerufen wird, der wir den eben ermittelten "Cache-Root-Ordner" übergeben:

Zunächst wird dafür gesorgt, dass der übergebene string "dir", der den aktuell zu scannenden Ordnernamen enthält, mit einem Slash endet.

Anschliessend füllen wir mittels der Borland-"Find"-Funktionen die Struktur "sr" vom Typ "tsearchrec" für jedes gefundene File bzw. jeden ermittelten Ordner.

Beim ersten Durchlauf interessieren uns nur die Unterordner von "dir"; Dateien werden ignoriert. Wurde ein Unterordner ermittelt, so wird mit diesem als neuem "dir" die Prozedur "scan_dir" rekursiv wiederholt. Auf diese Art und Weise durchlaufen wir nach und nach alle Unterordner des ersten "dir", also des anfangs übergebenen Cache-Ordners.

Wurden alle Ordner einer "dir"-Ebene abgeklappert, folgt nun der zweite Durchlauf mit den "Find"-Kommandos. Diesmal interessieren uns nur die Dateien im aktuell betrachteten Ordner.

Zuvor wird jedoch anhand des des Ordnernamens "dir" geprüft, ob wir uns überhaupt in einem sinnvollen Verzeichnis befinden, also einem, welches Cache-Dateien enthält. IE und FF benutzen den Cache-Ordner nämlich auch noch zur Verwaltung anderer Dateien und Ordner, die uns hier aber nicht weiter interessieren.

Haben wir schliesslich eine echte Cache-Datei ermittelt, wird anhand der Eintragungen in der ListBox "cache_lb" gecheckt, ob wir diese nicht bereits bei einer früheren "Refresh"-Aktion auf Movie-Stream-Artigkeit überprüft haben. Falls ja, dann ignorieren wir die Datei - sie muss ja nicht unnötigerweise noch einmal analysiert werden.

IE-Cache aus Sicht des Window-Explorers: Betrachtet man sich den IE-Cache des IE mit dem Explorer, dann sieht es so aus, als seien alle Files in nur einem Ordner untergebracht. Dem ist aber nicht so. Windows verbirgt (leider) häufig die wahre Natur seiner internen Organisation vor dem Benutzer. Die API-Funktionen zum Auslesen des Caches (auf die der Explorer vermutlich zurückgreift) sind darüber hinaus fehlerhaft, wie mir scheint. Denn teilweise werden damit vorhandene Files nicht angezeigt bzw. Files, die bereits gelöscht sind, immer noch als existent ausgegeben.

Die wahre Ordner-Struktur des IE-Caches: Mein eigener Dateibrowser, der "ComCen", zeigt uns hier die wahre Ordner-Struktur des IE-Caches: Er besteht nämlich aus zahlreichen Unterordnern, index-Dateien und Systemfiles. Und nur in einigen der Unterordner liegen auch tatsächlich die gesuchten Cache-Dateien drin.

2.3.5. Movie-Stream-Detection

Sollte eine gefundene Cache-Datei noch nicht überprüft worden sein, etwa, weil sie neu im Cache hinzugekommen ist, so wird sie jetzt an eine weitere interne Prozedur von "refresh" übergeben, nämlich "addentry":

Zuerst wird hier der Cache-Check-Zähler "check_c" für die Anzahl geprüfter Files erhöht. Anschliessend liefert uns die Funktion "file_is_movie_stream" die wesentliche Information zurück, ob es sich bei der gefundenen Datei um ein Movie-Stream handelt oder nicht.

Ist sie - wie sicher in den weitaus meisten Fällen - kein Movie-Stream, so landet ihr Dateinamen in der ListBox der neu geprüften Dateien "cache_work_lb", sofern auch das "check_ok"-Flag auf "true" gesetzt ist - doch dazu gleich mehr.

Wurde die aktuelle Datei dagegen tatsächlich als Movie-Stream erkannt, dann wird sie nun in die temporäre Stringlist "sg_sl" eingetragen. Zu beachten ist, dass dabei das Sortierkriterium (Grösse oder Datum) an den Anfang gestellt wird, wodurch bei der späteren Übertragung der "sg_sl" in die Cache-StringGrid automatisch die gewünschte Sortierreihenfolge gewährleistet ist.

Movie-Stream-Detection: Der im Bild gezeigte Cache des Firefox-Browsers beherbergt eine Unzahl von Dateien. Doch bei welchen dieser Dateien handelt es sich um Movie-Streams? Ihre Bezeichnung verrät nichts, Grösse und Datum sind irrelevant, eine Extension liegt nicht vor. Doch unser Tool "FLV-CCC.EXE" weiss dennoch die Antwort (zumindest meistens).

Die Funktion "file_is_movie_stream" ist eine der Kernfunktionen von "FLV-CCC". Sie ist folgendermassen implementiert worden:

Die übergebene Cache-Datei "fn" wird zum Lesen geöffnet. Dann wird wird versucht, die ersten 50 Bytes der Datei in den Puffer "buf" zu speichern. Gelingt dies nicht, kann das zwei Gründen haben: Entweder ist das Cache-File einfach kleiner als 50 Bytes oder der Download-Prozess des Browsers ist noch nicht abgeschlossen.

Daher wird in diesem Fall über die Funktion "state" geprüft, ob die Datei gerade in Benutzung durch einen anderen Prozess (Browser) ist. Falls nicht, ist der Download offenbar abgeschlossen und die Datei schlicht zu klein, um ein Movie-Stream sein zu können - "check_ok" wird auf "true" gesetzt. Ansonsten behält "check_ok" den Wert "false", wodurch sichergestellt bleibt, dass die Datei beim nächsten Refresh der Cache-StringGrid erneut auf Stream-Artigkeit überprüft wird.

Zurück zur Funktion "file_is_movie_stream": Wurden die ersten 50 Bytes der Datei erfolgreich in "buf" abgelegt, prüfen wir nun weiter, ob darin die nötigen "Signaturen" für das FLV-, WMV- oder MP4-Format enthalten sind.

FLVs und WMVs sind anhand ihres "magischen Codes" - die ersten drei Bytes der Datei mit standardisiertem Inhalt - leicht zu erkennen.

Magic-Code von FLV-Movies: FLV-Movies sind so nett, und verraten gleich zu Beginn ihrer Datei in grossen Lettern, was ihr Inhalt ist. Natürlich kann auch eine Nicht-FLV-Datei diese Zeichenfolge (zufällig) besitzen, was aber selten vorkommen dürfte. "FLV-CCC" würde jedenfalls auf eine solche "Fake"-Datei hereinfallen. Nicht jedoch das Proggy "ffmpeg.exe" ...

Magic-Code von WMV-Movies: Nicht ganz so sprechend wie bei FLVs, aber auch WMVs besitzen eine genormte Kennzeichnung in den ersten drei Bytes ihrer Datei. Das macht es "FLV-CCC" relativ leicht, solche Dateien zu identifizieren. Sollte eine WMV-Datei jedoch ohne diese Signatur daherkommen, würde "FLV-CCC" sie nicht aufspüren können ...

MP4s scheinen dagegen keinen Magic Code zu besitzen (?) und treten auch vielfältiger auf, was ihr "Inneres" angeht. Keine Ahnung also, ob meine obige Prüfungsroutine letztlich alle Arten von MP4s erkennt. In den von mir durchgespielten Fällen klappte es aber eigentlich immer.

Hex-View des MP4-Headers: In obigem Beispiel tauchen die Zeichenfolgen "ftypsiom" und "mp41" in der (Cache-)Datei "smooth.mp4" auf. Mit ziemlicher Sicherheit handelt es sich hierbei also um ein MP4-Movie - zumal dies natürlich bereits die Extension ".mp4" nahegelegt hat.

Um den Inhalt des 50-Byte-Puffers zu analysieren, nehmen wir übrigens die Funktion "pos_buffer" zu Hilfe, die eine leicht abgewandelte Version des Pos-Befehls von Delphi ist:

Hier wird der übergebene Char-Puffer "buf" zeichenweise durchlaufen und jedes Mal darauf getestet, ob ab der aktuellen Position "c" die Zeichenfolge "s" folgt. Im Erfolgsfall wird "c" zurückgeliefert, sonst "-1".

2.3.6. Catch a movie

Wurde die Cache-StringGrid erfolgreich mit den Namen der Movie-Streams gefüllt, können diese vom Benutzer per Doppelklick in den Konvertierungsspooler übertragen werden. Diesen Job erledigt die Prozedur "catch":

Die Cache-StringGrid wird durchlaufen und alle selektierten Zeilen betrachtet. Im string "fn_from" wird dabei der jeweilige Dateiname gesichert.

Ist im string "target" ein Ziel-Dateiname vorgegeben, so wird dieser verwendet, ansonsten der Quell-Dateiname als Basis für den Ziel-Dateinamen vorerst beibehalten.

Wir rufen die uns schon bekannte Funktion "file_is_movie_stream" erneut auf. Diese liefert uns nämlich im var-Parameter "typ" auch zurück, um was für eine Art von Movie-Stream es sich konkret handelt: FLV, WMV oder MP4.

2.3.7. Timecodes In FLVs

Haben wir ein FLV-Movie zum Kopieren erwischt, dann rufen wir nun zusätzlich die Funktion "timestamp_get" auf:

Diese Funktion versucht, im Kopf einer FLV-Datei Hinweise auf einen Zeitstempel zu finden. Üblicherweise hat der einen Wert von Null, was heisst, dass hier der Anfang des Movies vorliegt.

Wurde jedoch der Download eines FLV-Movies abgebrochen und an anderer Position wieder aufgenommen, so steht im ersten Zeitstempel der neuen FLV-Datei, wie viele Millisekunden (?) seit Filmstart bereits vergangen sind.

Diesen Zahlwert hängen wir nun - in normierter Weise - an den Ziel-Dateinamen dran, wodurch sich alle Teilstücke eines FLVs in zeitlicher Reihenfolge sortieren lassen, auch wenn sie nicht chronologisch geladen worden sein sollten!

FLV-Parts mit Time-Code: Ein FLV-Movie wurde mit dem Browser in mehreren Etappen geladen und jeweils über "FLV-CCC.exe" in den Spooler kopiert. Dadurch, dass der Time-Code mit im Dateinamen steckt, lassen sich die Teile nachträglich in der zeitlich korrekten Reihenfolge sortieren, auch wenn z.B. der letzte Teil "flv-part_0023400000.flv" als erstes gedownloadet wurde.

Diese Zeitstempelgeschichte erhebt keinen Anspruch auf volle Gültigkeit. Tatsächlich habe ich mir nur jede Menge FLV-Header mit einem Hex-Viewer angeschaut und die passenden Stellen empirisch ermittelt. Bisher jedenfalls haut sie ziemlich gut hin.

Analyse des FLV-Format: Ohne Blatt und Kuli geht bei mir gar nichts. Selbst so komplexe Fabrikate wie FLV-Movies offenbaren nach und nach ihre Geheimnisse, wenn man nur lang genug in ihnen herumwühlt. Dieses Wissen steht aber bisweilen durchaus auf tönernen Füssen ...

Hex-View eines FLV-Movies I: Die erste Markierung zeigt den Magic Code eines FLV-Movies, die drei Bytes der zweite Markierung enthalten im obigem Beispiel den Time-Code. Hier ist dies "00 00 00", also "0". Der Film beginnt demnach gerade.

Hex-View eines FLV-Movies II: Wurde ein FLV-Movie unterbrochen und der Download an anderer Stelle wieder aufgenommen, findet sich im Header der Datei bisweilen das Schlüsselwort "starttime", hinter dem der Time-Code notiert ist. Je weiter der Film fortgeschritten ist, desto grösser ist diese Zahl.

Ach ja, ähnliche Timecodes existieren vermutlich auch in WMVs und MP4s. Doch solche Movie-Typen kommen mir deutlich seltener unter. Um die Dinger zu knacken hätte die Kosten-Nutzen-Rechnung nicht gestimmt. Also liess ich es bleiben.

2.3.8. Eindeutigkeit bei Quelle und Ziel

Kehren wir zur Prozedur "catch" zurück: Wir haben eine Movie-Stream-Datei ermittelt und einen vorläufigen Ziel-Dateinamen für den Konvertierungsspooler gebildet. Da sich dort unter Umständen bereits eine gleichnamige Datei befinden kann, wird der Ziel-Dateinamen ein weiteres mal adaptiert, diesmal durch die Funktion "filename_unique":

Das Problem, einen eindeutigen Namen für das Ziel-File zu finden, klingt einfach, ist es aber nicht, da dieses Ziel-File in der Folge des Konvertierungsprozesses mehrmals den Namen wechseln wird - und bereits im Vorfeld gesichert sein muss, dass es dabei nicht zu Überschreibungen andere Dateien kommt.

Der Ablauf der (möglichen) Namensbildungen sei hier kurz anhand eines Beispiels geschildert:

• Die Cache-Datei "test.flv" wird als Movie-Stream identifiziert
• Die Datei wird als "test.flv+" in den Spooler kopiert.
• Die Datei wird anhand des "+"-Zeichen als zu konvertieren erkannt. Vor der Konvertierung wird das '+' in '-' gewandelt, die Datei heisst jetzt also "test.flv-".
• Mögliche Ergebnisfiles während der Konvertierung sind: "test.mpg-" oder "test.m1v-".
• Mögliche Ergebnisfiles nach der Konvertierung sind: "test.mpg" oder "test.m1v"
• Die ursprüngliche Datei wird umbenannt in "test#org.flv" oder "test#err.flv", je nach Ausgang der Konvertierung.

Sollte auch nur einer dieser Ergebnis- oder Quell-Dateinamen im Spooler bereits vorliegen, wird die Original-Datei mit einem Zusatz versehen, einer laufenden Nummer, eingefasst in eckigen Klammern. Diese Nummer wird so lange erhöht, bis schliesslich ein eindeutiger Dateiname für alle oben genannte Variationen vorliegt.

Eindeutiger Spooler-Name: Die "gecatchten" Movies bekommen eindeutige Dateinamen zugewiesen, damit sie sich bei der Konvertierung nicht gegenseitig überschreiben. Anhand der Null-Timecodes im Dateinamen erkennt man hier übrigens, dass es sich bei den gleichnamigen Movies nicht um Teile ein und desselben FLVs handelt, sondern um jeweils neue Filme. Der kryptische Cache-Name wurde durch den sprechenderen Zielname "spongebob" ersetzt.

2.4. Unit "convert_u.pas"

2.4.1. Threads

TabSheet-register zur Convert-unit: Hier kann bestimmt werden, mit welchen Übergabeparametern die "ffmpeg.exe" gefüttert wird, damit das gewünschte Movie-Format generiert wird. Standardmässig werden aus den Movie-Streams MPGs mit 320 x 240 Pixel Auflösung extrahiert, genauso gut könnte man sich aber auch AVIs mit 640 x 480 Pixeln erzeugen lassen. Die Checkbox "Autostart" gibt vor, ob der Konvertierungsspooler nach dem Programmstart aktiviert wird oder nicht. Es muss ja nicht immer sinnvoll sein, ein Movie-Stream aus dem Cache zu konvertieren.

Wie wir eben gesehen haben, werden "gecatchte" Cache-Files mit eindeutigem Namen versehen in den Konvertierungsspooler kopiert oder verschoben. Die Abarbeitung dieser Movies erfolgt über einen speziellen Thread "thread_spooler", der in der unit "convert_u.pas" wie folgt implementiert wird:

Threads verhalten sich im Prinzip wie eigenständige Programme. Man kann sie daher schön im Hintergrund diverse Arbeiten erledigen lassen, ohne dass die Haupt-Applikation dabei gestört wird.

Unser Thread "thread_spooler" ist so konzipiert, dass er sich sofort nach erledigtem Job selbst aus dem Speicher eliminiert ("freeOnTerminate:=true").

In der Prozedur "execute", die direkt nach Erzeugung des Threads startet, wird zuerst ein Panel im Hauptfenster, "convert_working_p", grün umgefärbt. Dadurch wird signalisiert, dass gerade ein Konvertierungsprozess stattfindet.

Durch Aufruf der Funktion "spooler_work" wird dann die eigentliche Konvertierung angestossen (dazu gleich mehr). Im Rückgabewert "rc" steht letztlich das Ergebnis dieser Operation.

Zum Schluss wird dann wieder das Panel "convert_working_p" rot gefärbt; der Konvertierungsprozess ist abgeschlossen, der Thread terminiert sich selbst.

2.4.2. Spooler leeren

Wie wir eben gesehen haben, wird vom Thread "thread_spooler" die Funktion "spooler_work" aufgerufen, um ein Movie-Stream im Konvertierungsspooler in ein MPG (sofern so vorgegeben) zu konvertieren. Genauer gesagt, wird hier zunächst nur der Konvertierungsspooler ausgelesen. Das schauen wir uns jetzt näher an:

Zuerst wird geprüft, ob die FileListBox "flb" des Konvertierungsspoolers leer ist. Ist dem so, gibt es keine Movies, also nichts weiter zu tun.

Ein wohlgefüllter Konvertierungsspooler: Hier wartet eine Menge Arbeit auf "ffmpeg.exe". Im Spooler befinden sich bereits 10 Movie-Streams. die zu MPGs konvertiert werden sollen. Der Benutzer wählt gerade die passenden Übergabeparameter dafür aus. Übrigens: Das alle gezeigten Movies die Extension ".flv" aufweisen, bedeutet nicht, dass es sich dabei wirklich in allen Fällen um FLVs handelt. Die Extension wurde von "FLV-CCC" so vorgegeben, um die Namensvielfalt rund um den Eindeutigkeitstest nicht noch verwirrender zu gestalten.

Lungert im Spooler jedoch mindestens eine Datei vor sich hin, so greifen wir uns die erste, und stellen über die Funktion "file_blocked" sicher, dass dieses Movie-Stream derzeit von keinem anderem Prozess verwendet wird.

Ist die Datei nicht in Benutzung, ändern wir ihr Dateinamen-Suffix "+" in "-", aus z.B. "test.flv+" wird also "test.flv-". Da im Konvertierungsspooler nur "*.flv+"-Files angezeigt werden, taucht dadurch diese Datei nach dem nächsten Refresh nicht mehr darin auf!

Anschliessend wird die Datei an die Funktion "convert_movie_stream" übergeben, die aus dem Movie-Stream eine MPG-Datei machen soll. Gelingt dies nicht, wird die Original-Datei umbenannt: Aus "test.flv-" wird dann "test#err.flv" werden.

Im Erfolgsfall erhält unsere Beispiel-Datei dagegen den Dateinamen "test#org.flv". Je nachdem, ob ein MPG oder ein M1V generiert wurde, erhält natürlich auch das Ergebnisfile einen neuen Namen ("test.mpg" bzw. "test.m1v").

Als letzte Massnahme bekommt das Ergebnisfile noch das gleiche Dateidatum wie die Original-Datei verpasst. So bleiben Quelle und Ziel im Explorer auch bei Sortierung nach dem Dateidatum beieinander stehen.

Konvertierungsspooler während der Arbeit: Die Movie-Streams "hurz*" und "ogl-planets-erde-saturn*" wurden bereits in MPGs konvertiert (kein Suffix). Die Datei "ogl-planets-erde-sonne*" ist gerade in Arbeit (zu erkennen am Suffix "-"). Und die restlichen Movies harren noch ihrer Bearbeitung (Suffix "+"). Oops! Ich merke gerade, dass die Adaption des Ziel-Dateidatum hier nicht stimmt, da muss ich wohl noch einmal ran ...

2.4.3. Von Movie-Stream zu MPG

Okay, nahmen wir noch einmal an, im Konvertierungsspooler wurde ein Movie-Stream gefunden und wie in "spooler_work" beschrieben an die Funktion "convert_movie_stream" übergeben. Dort passiert dann Folgendes:

Zu Beginn werden Quell- und Ziel-Dateinamen gebildet ("fn_from" und "fn_to"). Beim ersten Versuch bekommt das Zielfile hierbei die Extension ".mpg-" zugewiesen. Das heisst, es wird zuerst versucht, ein MPG mit Sound zu erzeugen.

Es wird der passende Kommando-string "cmd" aufgebaut, der das externe Programm "ffmpeg.exe" mit den nötigen Übergabe-Parametern aufruft. Um etwa ein FLV-Movie "test.flv-" in eine MPG-Datei "test.mpg-" mit 25 Bildern pro Sekunden, mit einer Auflösung von 320 x 240 Pixeln und einer Bitrate von 400 kbps, umzuwandeln, müsste "ffmpeg.exe" in der DOS-Konsole folgendermassen aufgerufen werden:

  ffmpeg.exe -i test.flv- -r 25fps -s 320x240 -f mpeg -b 400kbps -y test.mpg-

Eben diesen Konsolen-Aufruf simulieren wir nun in "FLV-CCC". Dazu wird der Kommando-Strings "cmd" an die Funktion "shell_execute_wait" übergeben, die etwas weiter unten beschrieben wird.

Der Return-Code "rc" sagt uns, ob alles geklappt hat. Wenn ja, verlassen wir die Prozedur wieder.

Hat die Konvertierung nicht geklappt, dann wird der Kommando-string "cmd" leicht abgewandelt. Denn beim nächsten Versuch soll das FLV-Movie in eine MPG-Datei ohne Sound umgewandelt werden, also in ein M1V-File. Erfahrungsgemäss machen nämlich hauptsächlich die Sound-Codecs Ärger beim Konvertierungsprozess mit "ffmpeg.exe", während die Bilder korrekt verarbeitet werden.

Diesmal wird an "shell_execute_wait" folgender Kommandostring übergeben:

  ffmpeg.exe -i test.flv- -an -r 25fps -s 320x240 -f mpeg -b 400kbps -y test.m1v-

Bei Erfolg wird die Prozedur mit Result "2" verlassen, bei Misserfolg mit "0".

Ergebnisse des Konvertierungsprozesses: "FLV-CCC" hat drei Konvertierungen(-Versuche) durchgeführt. Beim ersten Film "fehlerhaftes_movie.flv" hat "ffmpeg.exe" versagt. Daher gibt es hier kein Ergebnisfile und das Original wurde in "fehlerhaftes_movie#err.flv" umbenannt. Das zweite File "movie_mit_sound.flv" wurde korrekt in "movie_mit_sound.mpg" konvertiert (man beachte, dass die Dateidatum-Modifikation inzwischen stimmt!). Und die letzte Film-Datei "movie_ohne_sound.flv" konnte schliesslich nur in ein M1V-File transferiert werden. Tja, hätte sich das dumme "FLV-CCC" die Dateinamen gleich zu Beginn näher angeschaut, wären die Ergebnis sicher leichter zustande gekommen ...

2.4.4. Ausführen und Warten

Wie beschrieben, wird in der Funktion "convert_movie_stream" ein spezieller Kommando-string "cmd" aufgebaut und an die Funktion "shell_execute_wait" übergeben, wo das Kommando letztlich ausgeführt wird. Wie das genau abläuft, schauen wir uns jetzt an:

Zuerst wird die Systemstruktur "tsi" vom Typ "TStartupInfo" mit Daten gefüllt, die u.a. festlegen, dass der zu generierende Prozess unsichtbar ablaufen soll ("tsi.wShowWindow:=sw_hide;").

Diese Struktur wird zusammen mit dem Kommando-string "cmd" an die API-Funktion "CreateProcess" übergeben, die einen neuen Prozess im System generiert und damit "cmd" zur Ausführung bringt - ganz so, als wäre das Kommando in die DOS-Konsole getippt worden.

Anschliessend wird dann an dieser Stelle bis zu 5 Minuten gewartet ("WaitForSingleObject(tpi.hProcess,5*60*1000)"), dass der Prozess von alleine beendet wird, bevor automatisch mit der Funktion fortgefahren wird.

In jedem Fall wird eine entsprechende Statusmeldung "wc" zurückgeliefert, die Auswirkungen auf das Gesamtfunktionsergebnis "result" nimmt.

FFMPEG in der DOS-Konsole: Die Funktion "shell_execute_wait" verhält sich ähnlich wie die DOS-Konsole, in die ein Kommando-string eingeben wird. "FLV-CCC" sorgt jedoch dafür, dass der Ausführungsprozess im Verborgenen abläuft. Anders als die DOS-Konsole, die während der "ffmpeg"-Konvertierung eine Menge Informationen auswirft, wie man oben bewundern darf.

3. Epilog

Ich habe einige Cache-Browser zum Aufspüren von FLVs ausprobiert, aber überzeugt habe die mich nicht. Vielleicht hätte ich mich länger mit ihnen beschäftigen sollen, um alle Features auszuloten, dann wären die Ergebnisse vermutlich befriedigender ausgefallen.

Aber ich bin ja Programmierer. Warum also mit (mangelhafter) Fremd-Software herumschlagen? Mit dem "FLV-CCC" bin ich jedenfalls sehr zufrieden. Der findet praktisch alle Movie-Streams, selbst wenn sie gestückelt geladen wurden, und konvertiert sie so, dass sie mit meinen Medien-Tools nachträglich bearbeitet werden können (wie z.B. "VidSplitt", welches nur mit MPGs umgehen kann).

Besonders genial finde ich, dass die Timecodes ausgelesen und in den Dateinamen eingebaut werden. Denn wer z.B. 20 Movie-Fetzen auf Platte hat, mit den sonst üblichen bunt gewürfelten Cache-Dateinamen, wird seine liebe not haben, die wieder in chronologischer Reihenfolge zusammensetzen zu können.

Okay, es klappt nicht immer mit dem Timecodes. Manche Movie-Parts werden von Web-Servern auch derart manipuliert ausgeliefert, dass "ffmpeg.exe" sie nicht konvertieren kann. Auch gibt es in "FLV-CCC" eine Reihe unnötiger Arbeiten, etwa, dass die Header-Bytes der Movie-Streams (unnötigerweise) mehrfach ausgelesen werden (um sie zu als Movie-Streams zu identifizieren, um ihren Typ festzustellen und um letztlich die Timecodes auszulesen).

So etwas verdirbt mir jedenfalls nicht den Spass an meinem Proggy. Ist halt nichts Hundertprozentiges. But who cares?

4. Download

"FLV-CCC" wurde in Delphi 7 programmiert. Im ZIP-File enthalten ist der vollständige Source-Code, die EXE-Datei und auch das Tool "ffmpeg.exe". Das Paket, etwa 4 MB, gibt es hier:

FLV-Cache-Catch-Converter.zip

Es wurde auf die Verwendung von Fremd-Komponenten verzichtet. Auch werden keine speziellen DLLs benötigt. Der Source-Code lässt sich sicher leicht auf andere Delphi-Versionen anpassen. Das ausführbare Programm ist mit 550 kB recht anspruchslos. Ausserdem nimmt es keinerlei Änderungen an der Registry vor. Das Tool "ffmpeg.exe" muss allerdings im gleichen Ordner liegen wie die "flv-ccc.exe", damit die Konvertierung klappen kann!

Have fun!