VidSplitt - Ein GOP-genauer MPG-1-Splitter

Inhalt

• 1. Um was geht's hier?
• 2. Splitting/Cutting von MPG-Movies - wie kann man's machen?
  • 2.1. Ein Wunsch entsteht
  • 2.2. Idee I: Ein Datei-Schredder als MPG-Movie-Splitter
  • 2.3. Idee II: Ein Multi-Part-Datei-Splitter als MPG-Movie-Splitter
  • 2.4. Idee III: Ein GOP-genauer MPG-1-Splitter zur Videobearbeitung
    • 2.4.1. Der Aufbau eines MPG-Videos
    • 2.4.2. Neu-Synchronisation der Tag-Inhalte
    • 2.4.3. Böse Bytes im Video-Header
• 3. Mein GOP-genauer MPG-1-Splitter: das Delphi-Programm
  • 3.1. MPG-Videofilm einlesen
  • 3.2. MPG-Videodatei schreiben
  • 3.3. Schnipp-Schnapp im Movie und die Treffgenauigkeit
  • 3.4. Hau' die Zeitstempel in die Streams
  • 3.5. Header-Byte-Akrobatik
• 4. Mein GOP-genauer MPG-1-Splitter: Die Oberfläche
  • 4.1. MCI verzählt sich
  • 4.2. TrackBar ...
    • 4.2.1. ... und Auto-Splitting
    • 4.2.2. Das Manifest, das keine TrackBar mag
    • 4.2.3. Die TrackBar enttäuscht noch einmal
  • 4.3. Die ScrollBar als Retter in der Not
    • 4.3.1. ScrollBar-Selektion
  • 4.4. Zeig mir all die Bereiche
    • 4.4.1. Eine Liste voller Zahlen
    • 4.4.2. Grafiken sind anschaulicher als Zahlen
  • 4.5. Aktivierungszustände von Schnitt-Bereichen
    • 4.5.1. Näher ran!
  • 4.6. Abschlussarbeiten
  • 4.7. Ein MPG-Tag-Scanner gibt's gratis dazu
  • 4.8. No sound please
  • 4.9. Kostenlose Zusatzinformationen
• 5. Die Praxis
  • 5.1. Movie-Merge bzw. Video-Segmente wieder zusammenfügen
  • 5.2. MPEG-2-Format
  • 5.3. Kein Licht ohne Schatten
• 6. Danksagung und Quellen
• 7. Der Download - alles beisammen

1. Um was geht's hier?

In diesem Delphi-Tutorial betrachten wir die Entwicklung eines Tools, mit dem man ein Movie-File in mehrere Teile aufspalten kann, wobei jedes Einzelteil abspielbar bleibt. Denn die Zerkleinerung oder Verkleinerung von digitalen Filmen ist angesichts ihres grossen Speicherbedarfs sicher häufig angebracht, wenn dadurch keine wichtigen Szenen verloren gehen. Mittels der Aufspaltung können besonders interessante Abschnitte auf die gewünschte Länge hin isoliert werden.

Der hier vorgestellte kostenlose Videosplitter für das Windows-Betriebssystem erlaubt es, über eine grafische Oberfläche mit Leichtigkeit mehrere Segmente in einem Videostream zu markieren, und diese dann mit nur einem Knopfdruck herauszuschneiden. Da dabei das Videoformat des Filmes bestehen bleibt, also keine neue Konvertierung bzw. Resampling anfällt, geht dieser Vorgang blitzschnell vonstatten und es sind dadurch auch keinerlei Qualitätseinbussen bei den Einzelfilmen zu beklagen. Die so entstandenen Kurzfilme lassen sich leichter als der Komplettfilm per E-Mail verschicken oder auch auf einer Webseite zum Download anbieten.

Um es gleich vorwegzusagen: Bei VidSplitt handelt es sich technisch gesehen nur um einen GOP-genauen MPEG-1-Splitter. Es lassen sich also nur Filme im MPEG-Video-Format der Version 1 trimmen, und dies auch nicht an jeder x-beliebigen Stelle, sondern nur an bestimmten Schlüsselpositionen, die durch den Codec vorgegeben sind. Was dies Einschränkung genau bedeutet, werden wir im Verlauf des Tutoriums noch erfahren. Andere gängige Videoformate wie AVI, FLV, MOV, MP4, WMV usw. werden von VidSplitt leider nicht unterstützt.

VidSplitt, der GOP-genaue MPG-1-Video-Splitter von Daniel Schwamm

2. Splitting/Cutting von MPG-Movies - wie kann man's machen?

2.1. Ein Wunsch entsteht

Meine Festplatte beherbergt viele Videodateien. Oft auch grosse Movies. Platz ist eigentlich kein Problem mehr. Oft interessieren mich aber nur kleine Teile aus den Movies, der Rest stört. Und so entstand der Wunsch nach einem Programm, welches mir erlaubt, auf der Zeitachse eines digitalen Films Bereiche zu markieren und diese dann per Knopfdruck automatisch herausextrahieren zu lassen.

Es gibt den hervorragenden Video-Editor TMPGEnc im Web zu finden, mit dem das geht. Allerdings werden hier die Movies neu codiert. Das dauert lange und kostet Qualität.

VirtualDub, eine weitere Video Editing Software, kann das Ganze auch ohne Resampling. Soweit ich weiss, aber nur mit AVIs.

Ich liebe jedoch MPGs. Die sind so knackig klein. Und v.a. erlauben sie es am besten, innerhalb des Movies zu springen (seeken). Zumindest mit meinem eigenen Media-Player, den ich mir vor ein paar Jahren zusammenprogrammiert habe. Von allen Multimedia-Formaten ist das MPEG-Videoformat mir das vertrauteste und genehmste.

Ausserdem ist die Bedienung von TMPGEnc und VirtualDub nicht so mein Ding.

Ein eigenes Programm musste also her!

2.2. Idee I: Ein Datei-Schredder als MPG-Movie-Splitter

Schnell stellte ich bei meinen Experimenten fest, dass man MPG-Filme an einer belieben Stelle teilen kann und der erste Teil (aber auch nur dieser) i.d.R. noch funktioniert, sprich, von Video-Playern wie dem Windows Media Player abgespielt werden kann. Coole Sache. Und leicht programmiert. Ein 15-Minuten-Job in Delphi.

Das folgende kleine Programm zerteilt die übergebene Datei "fnin" ab Position "position" und speichert den ersten Teil unter dem anderen Dateinamen "fnout" ab. Es muss sich dabei übrigens nicht um eine MPG-Videodatei handeln; mit jedem anderen Dateiformat funktioniert dies genauso:

2.3. Idee II: Ein Multi-Part-Datei-Splitter als MPG-Movie-Splitter

Bei einigen wenn nicht meisten M1V-Movies - MPGs ohne Sound (intern: Elementary Streams) - lassen sich nach dem Schreddern nicht nur der erste Teil, sondern sogar alle Parts mit Video-Playern abspielen, nachdem man das Movie in mehrere, nicht zu kleine (gleichgrosse) Segmente unterteilt hat. Auch ein solches Multi-Part-Splitter-Programm war in Delphi schnell geschrieben.

Das folgende Programm zerteilt die Videodatei "tst.m1v" in fünf gleichgrosse Stücke (der letzte Part, der Restfilm, kann unter Umständen etwas kleiner sein):

2.4. Idee III: Ein GOP-genauer MPG-1-Splitter zur Videobearbeitung

Leider ist das echte Splitten von MPGs in mehrere Teile, die danach auch einzeln abgespielt werden können, ungleich komplizierter. Und ohne etwas Theorie auch nicht zu verstehen.

2.4.1. Der Aufbau eines MPG-Videos

Videos im MPG-Format sind grob folgendermassen aufgebaut:

Alle Sektionen eines MPGs (Header, GOP, Frame, Streams ...) beginnen mit einer bestimmten Nummer, bestehend aus einer Folge von 4 Bytes. Ich nenne die Dinger Tags, weil mich das Format an HTML-Tags erinnert.

Der Aufbau ist: 0 0 1 TAG-Nummer

Es kostete mich einiges an Zeit und Nerven, bis ich im Web alle Tag-Nummern des MPG-Formats ermittelt hatte. Wir benötigen eigentlich nicht alle, sie sind hier der Vollständigkeit halber aber komplett aufgeführt:

Mit einem Hex-Viewer sieht das Innere einer MPG-Datei folgendermassen aus: Der Header ist grün markiert, die roten Stellen zeigen die Magic-Number zu Beginn des Videos (ein _SEQU_tag), eine GOP, ein Frame und ein Slice mit den nachfolgenden Daten. Aus Gründen der Übersichtlichkeit wählte ich für die Demonstration das wesentlich weniger komplexe M1V-Format statt eines MPGs.

Okay, dachte ich, ich parse also das MPG, ziehe mir dessen Header in ein eigenes Byte-Array und merke mir dann die Positionen der einzelnen GOPs. Denn die sind offenbar adäquate Schnittstellen im Video zur Editierung.

Konkreter: Ich schreibe den Header in eine neue Datei, hole mir dann die Bytes ab GOP 5 bis zur GOP 10 minus 4 Bytes (der Tag-Länge) und hänge sie an das Header-Ausgabefile einfach hinten dran. Fertig ist mein geschnittenes Movie.

Funzte aber leider nicht. Der Windows Media Player spielte das so nicht ab.

2.4.2. Neu-Synchronisation der Tag-Inhalte

Die Idee an sich scheint okay. Jedoch müssen einige Tag-Inhalte offenbar an die neuen Verhältnisse angepasst werden. In den PACK-, VSTREAM- und ASTREAM-Tags gibt es nämlich Zeitmarken, die ein Video-Player benötigt, um Video und Sound synchronisieren sie können. Durch unsere Schnitte, die ja Teile des ursprünglichen Videos aussparen, stimmen die Werte nun aber nicht mehr überein oder weisen Lücken auf.

Es galt also, diese Tags bzw. deren Zeitmarken beim Wegschreiben ins neue File entsprechend zu adaptieren. Die eigentlichen Stream-Inhalte dagegen konnten glücklicherweise so belassen werden, wie sie waren, zumindest soweit ich das bisher überblickte.

Das wurde heavy. Ich suchte mir eine Woche lang im Web alles zusammen, was zu den Video-Zeitmarken passen könnte, was irgendetwas an Information lieferte, auf die ich würde aufbauen können. Viel gefunden habe ich nicht. Doch irgendwann wusste ich trotzdem, an welcher Stelle die Zeitmarken wie gesetzt werden mussten.

Nur, das brachte mich seltsamerweise nicht weiter. Die so entstandenen, nachträglich resynchronisierten MPG-Videos wurden etwa vom Windows Media Player nach wie vor nicht akzeptiert. Auch die Video Editing Software TMPGEnc schluckte sie nicht und brach mit Fehlmeldungen ab, wann immer ich dort meine Schnitt-Movies einzuladen versuchte.

Ein anderer Player, der Open Source Encoder/Decoder MPlayer, spielte die Videos dagegen tatsächlich ab! Auch wenn am Anfang der Splitting-Filme jede Menge Schlieren und grünfarbige Blöcke auftraten. Aber es war ein Anfang, ein Lichtblick am Ende des Horizonts. Ohne den MPlayer hätte ich jedenfalls an dieser Stelle das Handtuch geschmissen und meinen Plan vom eigenen Video-Cutter begraben.

Nur, was zum Teufel störte die anderen Player jetzt eigentlich noch?

2.4.3. Böse Bytes im Video-Header

Das bekam ich nur durch sehr viel Geduld und unermüdliches Analysieren der Hex-Codes von etlichen MPG-Videos heraus. Machte keinen Spass. In diesem Wust aus Zahlen etwas Sinnvolles herauszulesen war mühsam. Und es bereitete mir ziemliche Kopfschmerzen. Zumal ich nie wusste, ob sich die ganze Arbeit überhaupt lohnen würde.

Aber letztlich fand ich die entscheidende Stelle: Im MPG-Header gibt es nämlich ein paar Bytes, die offenbar den Abstand im File zwischen dem ersten VSTREAM im Header und dem ersten PACK in der ersten GOP angeben. Stimmt dieser Wert nicht, geht nichts mehr; die meisten Video-Decoder verlaufen sich dann im Stream und kehren niemals wieder.

Es ist schon komisch, aber ich habe im Web wirklich keinen verdammten Hinweis auf dieses doch nicht eben unwichtige Faktum gefunden. Übrigens auch hinterher nicht, nachdem ich bereits wusste, nach was ich Ausschau halten sollte.

Es folgt nun ein Beispiel für die Position und die Berechnung der Header-Länge in einem MPG-Videofilm. Dargestellt werden die Daten über einen MPG-Tag-Viewer, den ich eigens zu diesem Zweck in das VidSplitt-Tool mit eingebaut habe:

Berechnung der Header-Länge in einer MPG-Videodatei:
Der erste VSTREAM im Header ist markiert, File-Position 0x1234.
Ebenfalls markiert ist das erste PACK der ersten GOP, File-Position 0x1B3C.
Daraus ergibt sich eine Header-Length im markierten VSTREAM von:
0x1B3C - 0x1234 - 6 = 0x802 = 2306 Bytes!

Sollte es das gewesen sein? Ich musste in meinen Schnittvideos, die ich bereits generiert hatte, nur diese beiden Bytes anpassen und dann ...?

Heureka! Es klappte - der Windows Media Player spielte meine Cutting-Videos ab.

3. Mein GOP-genauer MPG-1-Splitter: das Delphi-Programm

3.1. MPG-Videofilm einlesen

Nun aber zum Delphi-Source. Da hätten wir auch schon gleich eine fette Prozedur, "ScanFrames", die mit einem MPG gefüttert wird, in einer Schleife alle relevanten Informationen heraus parst und diese in diverse Arrays schreibt, die zur weiteren Verarbeitung später noch benötigt werden:

Viel Stoff, oder? Was also mache ich da genau?

Ich schreibe die Bytes von 0 bis zur ersten GOP - 4 Bytes in das Header-Array "hdbuf".

Im Array "frmtyp" merke ich mir den geparsten Tag-Typ: "G" für GOP, "C" für PACK, "L","I","G","P" und "D" für die verschiedenen FRAME-Typen, "V" für VSTREAM und "A" für ASTREAM.

Die Positionen der Tags im File merke ich mir im Array "frmpos".

Die Frame-Nummern von Frame-Tags merke ich mir im Array "frmnr". Handelt es sich um ASTREAM- oder VSTREAM-Tags, merke ich mir zudem, welche Arten von Zeitstempeln sich hier befinden (DTS: decoding time stamp, PTS: presentation time stamp). Diese Information wird später beim Wegschreiben des Splittings wieder benötigt, warum also dann noch einmal neu scannen?

Die Anzahl aller gefunden Tags steht in "frmc", die Anzahl gefundener Frames in "frmno". Ich kann dann später sagen: Das Tag mit der Nummer 20.223 ist ein I-Frame, beginnend bei Position 1.226.002 im File, und es handelt sich dabei um Bild bzw. Frame Nummer 5.667.

Ausserdem merke ich mir die Grösse der grössten gefundenen GOP in "gopmaxsz". Um später eine beliebige komplette GOP aus dem aktuellen Movie einzuladen, muss ich nur maximal so viel Bytes allokieren, damit es zu keinem Speicherüberlauf kommen kann.

Des Weiteren merke ich mir die Position des ersten VSTREAM-Tags vor der ersten GOP (also im Header) in "hdlenpos". Die Differenz zwischen diesem Wert und dem ersten Auftreten des ersten PACKs der ersten GOP ist eben jene berüchtigte Header-Length, die später im Header notiert werden muss (siehe oben, "Böser Bytes im Header"). Vermutlich ist das nötig, damit die Player wissen, wo sie mit dem Decodieren der eigentlichen Bildinformationen beginnen müssen.

Man merkt vielleicht, dass der Source "natürlich" gewachsen ist, weswegen einige Variablen-Namen etwas unglücklich gewählt wurden, weil ich zu einem früheren Zeitpunkt noch nicht so recht wusste, für was die gut sind. Statt "frmtyp", "frmnr" usw. wäre z.B. "tagtyp", "tagnr" sinnvoller gewesen. Das nachträglich wieder zu ändern war ich aber zu faul.

Die Deklaration der eingesetzten Arrays findet im Übrigen in der Klasse zur Hauptform statt. Dadurch kann ich im Source von überall darauf zugreifen uns muss sie nicht als Funktionsparameter übergeben:

Je nach Grösse der Movies muss die Konstante "_frmmax" gegebenenfalls vergrössert werden. Ich habe allerdings schon 1 GB-Movies bearbeitet, denen die hier implementierte Grösse locker genügt hat.

Des Weiteren finden folgende Funktionen in der Prozedur "ScanFrames" Verwendung:

3.2. MPG-Videodatei schreiben

So weit, so gut. Der nächste Schritt bestand darin, ein MPG zu schreiben. Sagen wir also, wir haben ein MPG mit 1.000 Frames. Ich will daraus nun ein neues Movie generieren, welches nur von Frame 300 bis 500 geht.

Ich übergebe an die Schreibfunktion ein Filehandle des MPGs, das Start-Frame, das Ende-Frame und den Namen der Zieldatei. Ich wählte ein Input-Filehandle statt eines Dateinamens deshalb, damit das MPG nur einmal geöffnet werden muss, auch wenn gleich mehrere Segmente daraus extrahiert werden sollen.

Und hier ist sie dann auch schon, die Funktion "SplittFile", das eigentliche Kernstück der ganzen Arbeit:

Gar nicht mal so lange, oder? Knackig-elegant gelöst, wie ich finde :-)

3.3. Schnipp-Schnapp im Movie und die Treffgenauigkeit

Mit der Funktion "frame2gop" wandle ich die gewünschte Frame-Position zu einer GOP-Position um. Wenn ich also wie gesagt von Frame 300 bis 500 cutten will, mache ich das tatsächlich nicht wirklich so. Ich arbeite vielmehr nur mit Näherungswerten.

MPG-Filme haben ein paar Eigenschaften, die dienlich sind, um sie leicht abzuspielen. Das Editieren derselben machen sie dagegen schwer. In die Details will ich gar nicht eingehen, nur so viel:

Jede GOP baut sich aus verschieden Frames auf, die typischerweise folgendermassen organisiert sind:

I-Frames sind quasi JPG-Bilder. P-Frames sind Bilder, die nur die Änderungen des vorherigen I-Frames enthalten. Und B-Frames sind eine Art Morphing-Struktur, die vom I- zum P-Frame führt.

Man kann also eigentlich nicht direkt bei einem B- oder P-Frame schneiden, denn ohne das zugehörige I-Frame ist die Information darin für den Player nicht zu interpretieren. Beginnt ein Movie mit einem B- oder P-Frame, zeigt sich das typischerweise in grün geblockten Bildern, bis das erste I-Frame auftaucht.

Und es wird noch komplizierter. Die ersten B-Frames einer GOP gehören nämlich nicht zum ersten I-Frame der GOP, wie man annehmen könnte. Sie gehören vielmehr zum letzten I-Frame der vorherigen GOP!

Nachdem, was man so liest, gibt es wohl einige wenige Video-Editoren, die tatsächlich ein MPG exakt bei seinen Frames unterteilen können. Wie genau sie das anstellen, weiss ich nicht. Ist mir auch egal.

Schon deutlich mehr Programme können bei den I-Frames schneiden. VirtualDub und TMPGEnc gehören wohl in diese Kategorie. Aber auch nur das zu realisieren war mir zu mühsam.

Ich schneide nur GOP-genau. Das zu erreichen war schwer genug. Zudem wäre ein Frame-genaues Aufspalten des Filmes bei meinem Source ohnehin nicht drin gewesen, da die TMediaPlayer-Komponente von Delphi Frame-Positionen liefert, die nicht mit meinem geparsten MPG-Tags übereinstimmen; was TMediaPlayer als Frame 1.000 ausgibt, ist bei mir vielleicht Frame 1.010. Aber dazu später mehr.

Okay, ich zerteile also einen Film nur auf Basis kompletter GOPs. Wenn ich ab Frame 300 schneiden will, muss ich zuerst diese Frame-Nummer im Array "frmnr" ermitteln. So erhalte ich die Position des Frames im Array "frmtyp". Nun gehe ich in diesem Array zurück, bis ich den Tag-Typ "GOP" finde. Um die Endposition, also Frame 500, zu ermitteln, gehe ich genauso vor, nur das ich diesmal in "frmtyp" nicht zurück, sondern nach vorne laufe, bis ich erneut eine GOP finde (bzw. das Dateiende).

Mit anderen Worten: Wenn ich angebe, von Frame 300 bis 500 zu schneiden, dann schneide ich vermutlich eher etwas in der Art wie Frame 289 bis Frame 504! Nicht sehr genau, aber mir genügt's vollauf.

Die "Konvertierung" von Frame zu GOP erledigt die Funktion "frame2gop":

3.4. Hau' die Zeitstempel in die Streams

Habe ich so also die Start- und End-GOP ermittelt, kann ich nun jede GOP einzeln aus dem MPG einlesen.

Über das Array "frmpos" erfahre ich die genaue Position der GOP im MPG-File, kann also per File-Seek direkt an die richtige Stelle springen, ohne die Datei neu parsen zu müssen. Das bringt Speed ohne Ende!

Die interne Funktion "getgopsz" berechnet die Grösse der jeweiligen GOP. Sie ergibt sich aus der Differenz der Fileposition der GOP zur Fileposition der nächsten GOP. Die maximale GOP-Grösse wurde ja zuvor in "ScanFrames" ermittelt, mehr Speicherplatz für den Lese-Puffer muss nicht allokiert werden.

Innerhalb einer so geladenen GOP befinden sich nun all die PACK- und VSTREAM- und ASTREAM-Tags, die Zeitstempel besitzen, die umgeschrieben werden müssen. Ihre exakte Position kann direkt mittels der Arrays "frmtyp" und "frmpos" ermittelt werden (Position im Lese-Puffer ist die Differenz der Fileposition des Tags zur Fileposition des GOP-Tags).

Mittels der Funktion "get_ts" wird der jeweilige Zeitstempel eingelesen (siehe weiter oben). Da wir mitten ins Video gesprungen sind, steht hier etwas in der Art: "Lieber Player, wenn du dieses Frame findest, dann spiele es nach 22 Sekunden seit Videobeginn ab".

Tatsächlich ist es so, das ein Player ein geschnittenes Video, dass die Zeitstempel unverändert lässt, nach dem Start exakt diese Zeit mit einem stehendes I-Frame-Picture wartet, bevor er dann das Movie korrekt abspielt.

Also muss der Zeitstempel logischerweise auf einen kleineren Wert gesetzt werden. Einfach einen eigenen Wert neu berechnen geht nicht, da die Anzahl angezeigter Frames je Sekunde je nach Sampling Rate unterschiedlich ist, ja, sich innerhalb eines Movies auch permanent verändern kann. Erschwerend kommt hinzu, dass die I-, B- und P-Frames nicht in der Reihenfolge abgespielt werden, wie sie im Movie auftauchen. Denn die ersten Frames einer GOP, die angezeigt werden, sind die B- und P-Frames, die hinter dem ersten I-Frame liegen - ich erwähnte das schon weiter oben. Vermutlich erleichtert dieses merkwürdige Verhalten den Playern das Decodieren der Bilder.

Nun ja, zum Glück kann uns das Wurst sein. Finden wir den ersten Time-Code, merken wir ihn uns in "tsdiff". Nur diesen Time-Code müssen wir quasi auf einen Nullwert setzen. Von allen anderen gefundenen Zeitwerten wird einfach stur "tsdiff" abgezogen, damit's passt.

Das Schreiben des Zeitstempels erledigt die Funktion "put_ts":

3.5. Header-Byte-Akrobatik

Befinden wir uns in der ersten neu zu schreibendem GOP, kommt die erwähnte Geschichte zum tragen, dass der Abstand zwischen erstem PACK der ersten GOP und erstem VSTREAM des Headers im Header vermerkt werden muss. Das erledigen folgende Zeilen:

Wir erinnern uns: "hdlen" gibt die Grösse des Headers an, "hdlenpos" die Position im Header, wo der erste VSTREAM steht. "hl" berechnet nun die gesuchte Differenz der Tags, wobei "cc" die aktuelle Position im Lese-Puffer angibt (hdlen+cc zeigt also auf das erste PACK der ersten GOP).

Komplizierte Geschichte. Und das sollte sie auch sein. Diese drei Zeilen Source haben mich viel Nerven gekostet, bis ich sie ausgeschwitzt hatte.

Okay, die in den GOPs enthaltenen Zeitstempel wurden also adaptiert. Der Header wurde auch angepasst. Jetzt muss das Ganze nur noch GOP für GOP ins Ausgabefile weggeschrieben werden. That's it!

4. Mein GOP-genauer MPG-1-Splitter: Die Oberfläche

Das Splitten der MPGs klappte, nun fehlt noch eine Oberfläche.

Ich warf also eine TMediaPlayer-Komponente und eine TTrackBar auf die Delphi-Form. Nach der Auswahl des MPG-Filenames per File-Open-Dialog wird "ScanFrames" aufgerufen, danach das Video mit dem Player geöffnet, dessen Ausgabe auf ein TPanel umgelenkt, und in dem OnChange-Ereignis der TTrackBar die TrackBar-Position mit der Player-Position abgeglichen.

Die Idee war nun, mit der TrackBar einen bestimmten Bereich im Video zu selektieren, wobei das Video ja optisch im Ausgabe-Panel angezeigt wird, und dann diesen Bereich per Knopfdruck mit der "SplittFile"-Funktion ohne Qualitätsverluste aus dem Video herauszuschneiden.

4.1. MCI verzählt sich

Zu meiner Überraschung musste ich jedoch feststellen, dass die Anzahl Frames, die die MediaPlayer-Komponente ermittelt, häufig deutlich von der Anzahl Frames abweicht, die ich durch meine "ScanFrames"-Funktion mühsam selbst ermittelt hatte.

Die Unterschiede sind zum Teil echt krass: TMediaPlayer lieferte z.B. einmal satte 200.000 Frames, während ich selbst nur etwa 3000 echte Frames im Video gefunden hatte. Ein Check mit VirtualDub und TMPGEnc zeigte im Übrigen, dass ich Recht hatte (obwohl es auch hier zu ungeklärten Differenzen kommt, was sich aber auf einige wenige Frames Unterschied beschränkt).

Offenbar berechnet TMediaPlayer die Anzahl Frames aus der Spieldauer und der Sampling Rate oder so. Dadurch "weiss" die Komponente auch bei grossen Movies sofort, wie viele Frames angezeigt werden müssen. Mein Parser - und die der anderen Videoprogramme - benötigen einige Zeit, bis sie dieses Ergebnis auswerfen.

Unterschiedlich viele Frames im MPG: TMediaPlayer versus VirtualDub:
TMediaPlayer findet 80.538, VirtualDub dagegen nur 2.405 Frames

Ich analysierte also die TMediaPlayer-Komponente, und prüfte, ob ich irgendetwas bezüglich der Frame-Anzahl würde drehen können. Letztlich blieb ich aber in irgendwelchen Microsoft-APIs hängen. Hier kam ich nicht weiter.

Okay, blieb nur, die von mir so genannten MCI-Frames (die des TMediaPlayers) auf meine geparsten Frames umzurechnen. Dafür gibt's die Funktion "mcifrm2frm":

Also: In "mcifrmno" steht die Anzahl Frames, die TMediaPlayer gefunden hat, in "frmno" meine herausgeparste echte Frame-Anzahl. Ist "mcifrmo" also 1.000 und "frmno" 100, dann bilde ich den MCI-Frame 500 auf den "echten" Frame 500*(100/1.000)=50 ab. Nicht besonders tricky, funktionierte aber zu meiner eigenen Überraschung erstaunlich gut.

4.2. TrackBar ...

Nun zur TTrackBar: Diese Delphi-Komponente besitzt Eigenschaften, mit denen ein Bereich grafisch markiert werden kann. Prima, dachte ich, genau das, was ich brauche. Nun ja, eigentlich wollte ich ja ursprünglich gleich mehrere Bereiche selektieren können, aber okay, für's erste genügt's.

Die Selektion mit der TrackBar war leicht programmiert. Ich wählte einen Start- und ein Ende-Frame, beides MCI-Frames, rechnete sie mit "mcifrm2frm" in meine Scan-Frames um, übergab das an die "SplittFile"-Funktion, wo wiederum die Start- und Ende-GOPs ermittelt wurden, bis schliesslich der eigentliche Cut vorgenommen wurde.

Klar, von einem exakten Schnitt konnte bei all der Umrechnung kein Rede mehr sein, aber was sind schon 100 Frames plus/minus daneben? Nur maximal ein paar Sekunden falsche Bildinformation. Da pfeife ich doch drauf!

Der Wunsch nach mehreren Selektionen war auch leicht erfüllt, wenn auch nicht direkt grafisch sichtbar: Ich machte mit der TrackBar eine Selektion und trug die ermittelten Von-Bis-Werte in eine ListBox ein, dann die nächste Selektion usw. Anschliessend öffnete ich mein Video, lief die ListBox Zeile für Zeile durch, bildete durchnummerierte Dateinamen für die Ausgabe und rief jeweils die Funktion "SplittFile" auf. Klappte einwandfrei.

Mehrere MPG-Splitt-Selektionen: Die Von-Bis-Schnittbereiche in der 'goplb'-ListBox und die daraus generierten erfolgreichen Schnittvideos.

4.2.1. ... und Auto-Splitting

Noch ein SpinEdit dazu ("autose"), in dem ich die Anzahl gewünschter Schnitte eingab, und ich konnte per Knopfdruck die Schnitte-ListBox alternativ auch automatisch füllen. Auf diese Weise liess sich ein MPG z.B. sehr einfach in 10 etwa gleichgrosse Teile zerteilen.

Multi-Auto-Video-Splitting: Die automatisch generierten Schnitt-Bereiche in der 'goplb'-ListBox und die daraus erfolgreich generierten Schnittvideos.

Sauber Daniel! Jetzt die Oberfläche noch etwas grafisch aufmotzen. Also gleich mal das XPManifest auf die Form geschmissen, dass verpasst einem jeden Delphi-Proggy sofort einen edleren Look.

4.2.2. Das Manifest, das keine TrackBar mag

Aber was war das? Grafisch sah's jetzt schöner aus, aber wo war bei der TrackBar meine Selektion hin verschwunden? Sie war durchaus noch vorhanden, nur wurde sie leider optisch nicht mehr angezeigt. Nach einiger Suche im Web erfuhr ich, dass dies ein bekannter Bug vom XPManifest bzw. der TrackBar ist. Nicht die einzige Unzulänglichkeit vom XPManifest übrigens. Da haben die Borlander wohl geschlampt.

TrackBar-Selektion I: Erster Fehler bei der TrackBar. Ohne XPManifest sieht man die Selektion, mit XPManifest dagegen nicht.

4.2.3. Die TrackBar enttäuscht noch einmal

Okay, okay, ich kann auch ohne XPManifest leben, also wieder runter damit. Doch die nächste böse Überraschung liess nicht lange auf sich warten. In der Testphase habe ich - natürlich - nur mit kleinen MPGs gearbeitet. Da ich das Proggy sicher einige 100 mal kompiliert und gestartet habe, wäre es ja blödsinnig gewesen, jedes Mal einen langen Frame-Scan-Vorgang abwarten zu müssen.

Und so musste ich bei den ersten grossen Movies mit mehr als 32.000 Frames feststellen, dass sich mit der TrackBar zwar ohne Probleme auch 200.000 Frames auswählen lassen. Nur Selektionen, die in Bereiche über 32.000 reichen, werden optisch nicht mehr angezeigt.

TrackBar-Selektion II: Zweiter Fehler bei der TrackBar. Selektionsbereiche über eine Spanne von 32.000 Einheiten werden nicht mehr angezeigt.

Aaarg! Die wollen mich ärgern, die Borlander (das sind die Entwickler von Delphi)! Also dachte ich, gut, leite ich eine eigene Klasse von TTrackBar ab und sehe zu, dass ich diesen Fehler beseitige. Vielleicht würde ich's ja sogar schaffen, dass meine so entstehende TDanTrackBar sich dann auch mit dem XPManifest vertrug.

Der Grenzwert, bei der die Selektion versagte, roch sofort nach 16 bit Single- Integer-Überlauf; hier liegt nämlich der Wertebereich in etwa zwischen plus/minus 32.000. Vermutlich musste ich nur an passender Stelle ein Single in ein Integer wandeln und die Sache war gegessen.

Dem war aber nicht so. Letztlich endete meine Analyse der TTrackBar wie schon beim TMediaPlayer in Microsoft API-Calls. Per SendMessage werden hier die Selektionswerte übergeben, und zwar explizit als 32 Bit-Integer! Irgendwo fand ich dann auch den Hinweis, dass man tatsächlich grosse Werte übergeben kann, diese aber nicht korrekt als Selektion angezeigt würden. Borland waren also unschuldig, Microsoft hatte geschlampt!

API-Message TBM_SETSEL: An die TrackBar werden 32-Bit-Werte zum Setzen des Selektionsbereiches übermittelt, aber offenbar nicht korrekt verwendet.

4.3. Die ScrollBar als Retter in der Not

Ich hatte die Nase voll. TDanTrackBar liess ich sofort wieder sterben. Und die Original-TTrackBar verschwand ebenso von meiner Form. Stattdessen nahm ich eine TScrollBar, nannte sie "sc", und verband sie mit der Positionierung des Videos.

4.3.1. ScrollBar-Selektion

Mit TScrollBar kann kein Bereich optisch selektiert werden, nicht einmal falsch, so wie bei der TTrackBar. Aber wenn ich's schon selbst programmieren muss, dann doch mit der mir genehmeren Von-Bis-Komponente.

Hinter die ScrollBar legte ich eine TPaintBox "selpb". Zwei globale Variablen, "selstart" und "selend", merken sich die Grenzwerte. Eine globale Bitmap "selbmp" speichert die Grafik, die in der PaintBox beim OnPaint-Ereignis angezeigt wird. Und diese Grafik wird zuvor in der Funktion "mktbsel" generiert.

Aufbau einer eigene Selektionskomponente in Delphi: Unter der ScrollBar liegt eine PaintBox zur Wiedergabe der Selektion.

In "mktbsel" wird zunächst die Bitmap in ihrer Grösse der darüber liegenden ScrollBar angepasst. Dann wird sie mit der Hintergrundfarbe versehen. Ein innerer Bereich, der von der ScrollBar-Knopf Start- bis End-Position reicht, wird anschliessend silberfarbend gefüllt. Nun wird zusätzlich der mit "selstart" und "selend" definierte Bereich blau eingefärbt; liegt keine Selektion vor, wird nur ein Strich bei der "Cursor"-Position gemalt. Zuletzt kommen an den unteren Rand die Skalenstriche. Start, Mitte und Ende werden zudem mit Skalenwerten versehen.

ScrollBar-Selektion mit eigener Selektionskomponente in Delphi: Daniels hübsche ScrollBar-PaintBox-Selektionskomponente oder auch kurz SelektionsPaintBox genannt.

Es war eine ziemliche Fummelei, bis alle Bereiche da waren, wo sie hin sollten. Und das adaptiv, denn diese Kollektion von Komponenten muss ja auch korrekt auf OnResize-Ereignisse der Form reagieren. Im Vergleich jedoch zur Timestamp- Berechnung und -Setzung innerhalb von MPG-Videofilmen war's ein Spaziergang :-)

Die Selektion eines Bereiches mit obiger Konstruktion erfolgt folgendermassen: Mit der Maus verschiebt man den Knopf der ScrollBar. Das Video zeigt die zugehörigen Frames an, die SelektionsPaintBox einen "Cursor"-Balken. So wie man die STRG-Taste drückt, wird "selstart" festgelegt und "selend" auf die Scroll-Position gesetzt. Anschliessend wird "mktbsel" aufgerufen und der Selektionsbereich in Echtzeit blau markiert. Geregelt wird dies alles über das OnChange-Ereignis der ScrollBar:

Die Funktion "wrstat" gibt im ersten Panel der Statusbar den aktuellen Frame an, der mittels der ScrollBar ausgewählt wurde.

Die Funktion "setbuttons" aktiviert Menüs und diverse Buttons auf der Form, je nachdem, ob ein Video geladen ist, ob ein zerteilbares MPG geladen wurde, oder ob ein Bereich selektiert wurde. Dazu später mehr.

4.4. Zeig mir all die Bereiche

Nun habe ich mir ja in den Kopf gesetzt, nicht nur einen, sondern gleich mehrere Bereiche selektieren zu können. Die Eintragungen der Selektionsbereiche in eine ListBox, wie oben beschrieben, funktioniert nach wie vor. Sieht aber nicht so schön aus. Besser wäre es, alle gewählten Selektionsbereiche unter der ScrollBar sauber anzuzeigen.

Dazu benötigte ich eine weitere TPaintBox "pntb", die ich direkt unter die SelektionsPaintBox "selpb" legte. Habe ich also einen Bereich gewählt, klicke ich auf einen Knopf und trage die Von-Bis-Werte in meine ListBox, die ich "goplb" genannt habe. Der Name passt nicht (mehr) ganz, "schnittelb" oder so wäre treffender. Aber egal.

4.4.1. Eine Liste voller Zahlen

In der "goplb" landen jedenfalls die Von-Bis-Werte, jeweils mit Nullen auf sieben Stellen aufgefüllt, getrennt durch einen Doppelpunkt. Die Auffüllung der Grenzwerte mit Nullen macht die Liste etwas übersichtlicher und hat den grossen Vorteil, dass die Liste später sortiert werden kann, wodurch Schnitte, die bei niedriger Frame-Nummer beginnen, vor denen mit höhere Frame-Nummer liegen. Man muss also bei der Bestimmung der Schnittbereiche nicht stur sequenziell vorgehen, sondern kann von mir aus auch das Video von hinten nach vorne nach interessanten Stellen absuchen. Die generierten Split-Files sind - wenn die Liste aufsteigend sortiert wurde - dennoch in der logischen Reihenfolge durchnummeriert.

Sortierung der selektierten Videoschnitte: Die GOP-Liste 'goplb' vor und nach der Sortierung.

Okay, weiter im Source. Um einen Schnittbereich in die ListBox einzutragen, wird folgende Funktion verwendet:

Die Variablen "selrow" und "splitwrkok" sind Globale, die angeben, ob ein bestehender Selektionsbereich mit den neuen Selektionswerten "selstart" und "selend" verändert werden soll, oder ob ein neuer Schnitt in die ListBox "goblb" eingetragen werden soll. "selwrow" zeigt dabei auf den ItemIndex (den aktuell gewählten Schnitt) der "goplb".

Ziemlich simpel sind die Zusatzoperationen mit der "goplb":

4.4.2. Grafiken sind anschaulicher als Zahlen

Oben haben wir die PaintBox "pntb" erwähnt, die die Eintragungen in der ListBox "goplb" optisch unter unserer ScrollBar wiedergeben soll. Dazu wird in der Funktion "mkpntb" die Bitmap "bmp" gefüllt und beim OnPaint-Ereignis von "pntb" angezeigt.

Zunächst wird in "mkpntb" meine ScrollBar ordentlich auf der Form positioniert. Ich sorge dafür, dass sie auf der SelektionsPaintBox genau im oberen Drittel liegt, sodass die Skalenstriche und -Werte lesbar bleiben.

Eigentlich hat dieser Job hier nichts zu suchen. Aber aus verschiedenen Gründen, auf die ich nicht weiter eingehen muss, ist die Bereich-PaintBox älter als die SelektionsPaintBox. Darum hat die Bereichs-PaintBox als Grafikspeicher auch nur die phantasielos benamte Bitmap "bmp" zur Verfügung - denn ursprünglich dachte ich, mir würde eine Bitmap genügen. Aber hey, es funktioniert, warum also weiter drüber nachdenken?

Hier mal ein kleiner Einschub: Entgegen landläufiger Meinung sind nicht alle Programmierer penible Bitschubser, die mathematisches Denken lieben und anal fixiert durch's Leben schreiten. Ich jedenfalls bin eher chaotisch als organisiert. Und Programmieren ist für mich vielmehr ein künstlerischer Prozess als ein streng durchdachtes Vorgehen, wie's an der Uni gelehrt wird. Vielleicht habe ich mich ja deswegen an der Universität nie richtig wohl gefühlt.

Grafische Übersicht zu den gesetzten Videoschnitten: Aktuelle Selektion (oben) und die zuvor ausgewaehlten Schnittbereiche (unten).

4.5. Aktivierungszustände von Schnitt-Bereichen

Zurück zur "mkpntb"-Funktion. Wir haben die ScrollBar positioniert, anschliessend wird mit "mktbsel" die Selektionsgrafik generiert (siehe weiter oben). Nun kommt endlich die Bereichsgrafik dran, um die es eigentlich geht. Zunächst wird die "bmp" mit der Hintergrundfarbe versehen, dann wird ein silbergrauer Bereich definiert, der dem Selektionsbereich der ScrollBar "sc" entspricht. Nun wird die ListBox "goplb" zeilenweise durchgegangen und die jeweiligen Von-Bis-Werte herausgezogen. Mit diesen Werten werden dann die Rechtecke ins Bitmap gemalt, die die Schnittbereiche wiedergeben. Je nach "Aktivierungszustand" der Schnittbereiche werden diese entsprechend anders gefärbt: Inaktiv=blau, aktiv=grün, aktiv und bearbeitbar=hellgrün (cllime)

Die Aktivierungszustände werden durch Klicken auf grafisch angezeigten Schnittbereiche in der PaintBox "pntb" erreicht. Dabei gilt:

• Ein Klick ins "Leere" deaktiviert alle Schnittbereiche; sie werden blau.
• Erwischt man einen Schnittbereich, wird dieser grün gemalt, die ScrollBar positioniert sich an dessen Startwert, und das Video zeigt den entsprechenden MCI-Frame an. Parallel dazu ändert sich auch der ItemIndex der ListBox "goplb".
• Doppelklickt man einen Schnittbereich, so wird er hellgrün. Der Schnittbereich wird diesmal auch in der SelektionsPaintBox wiedergegeben. Der ScrollBar-Cursor landet am Selektionsende. Drückt man nun die STRG-Taste und ändert den Selektionsbereich, so ändert sich auch der zugehörige Eintrag in der ListBox "goplb".

Die Aktivierung der Schnittbereiche erfolgt über die Ereignisse OnClick und OnDblClick der Schnitt-PaintBox:

Wiederholt tritt hier übrigens auf, dass die Von-Bis-Werte aus der ListBox "goplb" extrahiert werden müssen. Ein ordentlicher Programmierer hätte das längst in eine eigene Funktion gepackt. Ein fauler wie ich allerdings nicht.

Die Funktion "getcursorpos" ist eine API-Funktion, die uns die Mauskoordinaten liefert. Mittels "pntb.ScreenToClient" werden diese Screen-Koordinaten auf die Komponenten-Koordinaten umgerechnet. Die Funktion "selx2frm" schliesslich wandelt die so ermittelte "Klick-x-Position" in eine Frame-Position auf der ScrollBar- Skala um.

Jetzt muss man nur noch die Schnittmarken-ListBox durchrennen und prüfen, ob der gefundene Frame sich innerhalb eines bestimmten Selektionsbereiches befindet. Wenn ja, wird der Aktivierungszustand entsprechend angepasst.

Das Ganze ist ziemlich dirty. Mittels der kombinierten ScrollBar-PaintBox-Komponente können nämlich z.B. auch ohne Weiteres überlappende Videoschnittbereiche definiert werden, ja, ein Schnittintervall kann einen oder mehrere andere selektierte Filmausschnitte völlig überdecken. Die Aktivierung per Mausklick der inneren Bereiche ist dann nicht mehr möglich (oder der äusseren Bereiche, je nach Reihenfolge in der ListBox "goplb"). Das geht mir aber, ehrlich gesagt, völlig am A ... vorbei.

Videoschnitt in Selektionskomponente aktiviert: Der hellgruene Videoschnitt ist aktiviert worden und nun bereit zur Bearbeitung.

4.5.1. Näher ran!

So, wir näheren uns dem Ende. Wir können ein Video laden, es parsen, bestimmte Bereiche darin auswählen, als Schnitt-Bereich markieren, diese Schnitt-Bereiche ändern und löschen wie's und gefällt, und zuletzt das Video zurecht schnippeln.

Mich hat jetzt nur noch eines gestört: Bei grossen Movies bewirkt eine minimale Änderung der ScrollBar eine rasante Änderung der Frame-Positionierung. Ein Millimeter nach rechts und der Schnittbereich wächst um 1.000 Frames. Das kann beim Aufteilen des Filmes zu gehörigen Ungenauigkeiten führen. Eine feinere Selektionsmöglichkeit wäre da wünschenswert.

Und als hätte ich es von vorneherein eingeplant, liess diese sich auch erstaunlich simpel realisieren. Alles, was ich machen musste, war, einen gewählten Selektionsbereich per Knopfdruck zum neuen Minimum-Maximum- Bereich der ScrollBar zu machen!

Erstaunlich, aber das funzt tatsächlich. Habe ich etwa ein Video von sagen wir mal 100.000 Frames, kann ich nun mit der Maus einen kleinen Bereich selektieren, von 4.000 bis 4.500, ohne dass ich wissen muss, was sich im Detail darin abspielt. Optisch ist das gerade mal eine dünne Linie in der SelektionsPaintBox. Nun einfach Selektion-Cut gedrückt und ich bekomme meine selektierten 500 Frames in der ScrollBar über die komplette Formbreite aufgespannt.

Ist mir das übrigens noch nicht fein genug, hält mich niemand davon ab, wiederum einen Bereich zu selektieren, den Cut-Button zu klicken und so gewissermassen noch weiter in die Zeitachse hineinzuzoomen.

Theoretisch kann man das Spiel treiben, bis man nur noch zwei Frames mit der ScrollBar auswählen kann. Da ich aber wie oben erwähnt nur GOP-genau schneide, wäre es vertane Liebesmüh, so exakt Schnittpunkte zu setzen.

Ach ja, das Beste kommt ja noch! Da der linke und rechte Rand der Schnitte-PaintBox sich am Minimum bzw. Maximum der ScrollBar der SelektionsPaintBox orientiert, wachsen und schrumpfen die Schnittbereiche bei deren Änderung automatisch mit (oder verschwinden aus dem Bild, wenn etwa das neue Minimum grösser als die Endmarke eines Schnittes ist).

Cool! War so nämlich gar nicht eingeplant. Es ging einfach (okay, fast: Ich musste dafür in diversen Funktionen noch den sich ändernden "sc.min"-Wert einarbeiten, damit es passt, denn zuvor ging ich ja immer von einem Null-Minimum aus).

Was soll ich sagen? Dieses unerwartete Bonmot macht mein kleines, dreckiges Tool nun auch noch von der Bedienung her zu dem für meine persönlichen Zwecke besten Video-Cutter auf weiter Flur :-)

Ach so, die Wiederherstellung des ursprünglichen Minimum-Maximum-Bereichs fehlt ja noch. Das ist aber ein Klacks:

Zoomen in die Zeitskala I: Die Selektion (oben) umschliesst mehrere zuvor gesetzte kleinere Videoschnitte (unten).

Zoomen in die Zeitskala II: Durch die Zooming-Funktionalitaet wird der zuvor ausgewaehlte Selektionsbereich ueber die gesamte PaintBox gestreckt. Die in diesem Bereich enthaltenden Videoschnitte sind nun deutlicher zu erkennen und leichter anzusteuern.

4.6. Abschlussarbeiten

So, zu guter Letzt noch ein paar Funktionen abgehakt, die in VidSplitt Verwendung finden:

4.7. Ein MPG-Tag-Scanner gibt's gratis dazu

In meinem VidSplitt-Proggy ist auch ein MPG-Tag-Scanner integriert. Er listet auf, wo im MPG wann welche Tags mit welchen Header-Informationen auftauchen. Tatsächlich wäre ich ohne diesen Scanner ziemlich aufgeschmissen gewesen, er hat mich viel über die MPG-Interna gelehrt.

Insbesondere erlaubt es der Scanner auch, zwei MPGs direkt nebeneinander zu stellen. So konnte ich mich bei meinen Schnitten viel leichter ganz allmählich an den Originalaufbau herantasten.

Der integrierte MPG-Tag-Scanner in VidSplitt: Der Tag-Scanner ermoeglicht die direkte Gegenueberstellung der internen Strukturen zweier (verschiedener) MPG-Videodateien. Alle Tags werden dabei mit den wichtigsten Informationen in 'chronologischer' Reihenfolge nebeneinander aufgelistet.

Hier - kommentarlos, weil zu faul - der Source zum MPG-Tag-Scanner in einem Rutsch:

4.8. No sound please

Hie und da findet man im Source von VidSplitt auch noch rudimentäre Spuren des Versuchs, den Splitter-Movies den Sound auszutreiben, um sie so noch weiter schrumpfen zu lassen.

Dazu wollte ich beim Wegschreiben der Ausgabefiles alle ASTREAM-Informationen einfach weglassen. Das Experiment ging aber in die Hose. Keine Ahnung, warum. Ich verlor jedenfalls schnell das Interesse daran. Bleibt der Sound halt drin. Die paar Bytes mehr ... Egal!

4.9. Kostenlose Zusatzinformationen

Über eine Funktion bin ich eben noch gestolpert, die eine Extra-Erwähnung verdient: "getsplittinfo". Wird der Aktivierungszustand eines Schnittbereichs geändert oder ein neuer Selektionsbereich definiert, sieht man in der Statusbar on the fly einige Informationen zu diesem Bereich. Neben einigen Insider-Informationen wie die Nummer des MCI-Frames, Rag-Frames, GOP-Index usw. wird v.a. auch die Grösse des Videoschnitts angezeigt, und zwar auf 's Byte genau!

Diese Information ist auch so ein Zufallsprodukt, welches nie eingeplant war. Aber da ich die Splitts ja selbst mache, stand mir alles zur Verfügung, was ich zur Berechnung der exakten Splitter-Grösse benötigte. Also warum nicht schon anzeigen, bevor's zu spät ist, sprich, der Schnitt auf der Festplatte geschrieben wurde?

5. Die Praxis

Ah! Ich liebe es, Programmierer zu sein!

Ich habe mir beim ersten realen Einsatz gleich ein dickes MPG aus dem Web gezogen ... Ja, okay, es war ein Porno.

Jedenfalls war das Teil etwa 700 MB gross. Ich lud das Movie in VidSplitt, nach ein paar Sekunden waren alle Frames gescannt. Die Schnitte machte ich mit meiner SelektionsPaintBox, zoomte per Selektion-Cut immer mal wieder tiefer in die Zeitskala hinein, ging anschliessend wieder auf die Gesamtansicht, und setzte so an die 60 Schnitte bei den interessanten Stellen. Dann führte ich die Zerkleinerung aus. Da dabei das Video ja nicht neu codiert werden musste, sondern nur einmal sequenziell durchlaufen, hatte ich schon nach wenigen Sekunden alle gewählten Videosequenzen sauber auf Festplattte gebannt. Gesamtgrösse jetzt nur noch 31 MB. Na, das hat sich doch gelohnt :-)

5.1. Movie-Merge bzw. Video-Segmente wieder zusammenfügen

Für einen findigen Programmierer dürfte es im Übrigen kein allzu grosses Problem sein, die Schnitte nicht nur als Einzelfiles zu speichern, sondern zu einem neuen File zusammen zu fügen (Video-Join-Funktionalität). Man schreibt dann halt nur einmal den Header weg und sorgt dafür, dass die Zeitstempel durchgehend aufsteigend vergeben werden. Die Idee klingt eigentlich machbar, beschäftigt mich selbst momentan allerdings eher weniger.

5.2. MPEG-2-Format

Interessant ist vielleicht auch, das Programm so zu erweitern, dass es mit MPEG-2-Movies umgehen kann. So gross scheint der Unterschied zu MPEG-1 gar nicht zu sein. Ich habe jedenfalls C-Source gesehen, der Informationen aus beiden MPG-Arten ausliest, und die programmtechnischen Abweichungen waren nicht unüberwindbar, auch wenn MPEG-2 ein Tick komplizierter zu sein scheint.

5.3. Kein Licht ohne Schatten

Bleibt einschränkend noch zu sagen: So manches Movie konnte ich mit VidSplitt nicht bearbeiten. Die Schnitte gingen völlig daneben oder die Ausgabevideos konnten nicht abgespielt werden. Passiert aber selten. Relativ oft hatte ich dagegen das Probleme, dass der MCI-Frame-Bereich in keiner Weise deckungsgleich mit dem Scan-Frame-Bereich war. In diesem Fall musste man halt hinterher noch den Schnittbereich verkleinern bzw. vergrössern, bis es doch einigermassen passte.

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

Daniel Schwamms Video-Splitter: Ein kostenfreies Tool zum schnellen und komfortablen Schneiden von MPG-Videodateien.

6. Danksagung und Quellen

Noch vor einigen Jahren wäre es mir nicht möglich gewesen, VidSplitt zu programmieren. Da gab's nämlich noch kein Internet :-)

Alle Informationen, die ich brauchte, fand ich im Web. Da ich die Standleitung meiner Arbeitsstätte nutzen konnte, kostete mich die Recherche nicht einen Pfennig, äh, Cent. Vielen Dank also an die Buchhorn & Melzer GmbH!

Ohne Google wäre natürlich auch nichts gegangen. Meine Verbeugung vor diesen Jungs & Mädels!

Danke auch an die Bastler von TMPGEnc und VirtualDub, an Borland und Microsoft, AMD und Intel, und wer sonst noch alles PCs zu dem gemacht haben, was sie heute sind. Nicht zu vergessen all die Kaffee- und Tabak-Pflanzer, die mir - und 1.000 anderen Programmieren - meinen täglichen Sprit liefern.

Die meisten Autoren oder Quellen, die mir auf die Sprünge halfen, lassen sich leider nicht mehr rekonstruieren. Ich sammle alles auf, was ich am "Wegesrand" im Web finde, lese es mir immer wieder durch, jeweils mit erweitertem Kenntnisstand, und schreibe interessante Sachen in Notepad raus. Manchmal denke ich auch intensiv nach, aber i.d.R. lasse ich mein Hirn den Job mehr oder weniger alleine machen; irgendwann lass ich es von der Leine, es filtert mir dann den aufgehäuftem Wust von Informationen zurecht. Ich hocke mich nur noch vor meine Kiste und lasse es aus den Fingern fliessen. Keiner ist überraschter als ich, wenn der heruntergetippte Source dann auch tatsächlich einmal hinhaut.

Fast alles, was ich so im Web fand, war in englisch verfasst. Kann ich zum Glück ganz gut lesen. Ich fand allerdings auch genügend Stoff in "exotischeren" Räumen, wie etwa Frankreich, Japan und Russland. Die scheinen dort Delphi fast noch mehr zu schätzen als die US-Amerikaner. Und das Schöne an Quellcodes ist ja, das denen die Sprache des Programmierers letztlich herzlich Einerlei sind.

Hier sind noch ein paar der nützlichen Dokumente, die ich zur Thematik Videoschnitt in den Weiten des Internets aufstöberte:

• mpeg2info.c von Tomi Ollila
• MPEG-Headers-Quick-Reference.mht von James Courtier-Dutton und seiner Crew.
  Siehe auch die Projekt-Seite unter URL: http://dvd.sourceforge.net
• mpgout.c von Laurent Alacoque
• MPEG-Videoschnitt.mht von RoBernd.
  Siehe auch seine Homepage unter URL: http://www.radonmaster.de/robernd/index.html
• mpeg-reader.mht, ein Post des Foristen "devnull".
  Siehe auch das "Channel 9"-Forum unter URL: http://channel9.msdn.com/Niners/devnull

Der grösste Glücksfall für mich waren aber ohne jeden Zweifel die genialen Seiten von http://www.fr-an.de/. Hier werden sehr detailliert alle Tags von MPGs erklärt. Und das sogar in deutsch. Und mit zahlreichen Programmbeispielen, die darüber hinaus auch noch in Delphi programmiert sind! Danke, Danke, Danke! Ohne diese Hilfestellung wäre sicher einmal mehr ein Projekt mehr von mir auf der Müllhalde der verlorenen Bits & Bytes gelandet :-)

7. Der Download - alles beisammen

Video-Splitt ist Freeware. Das Programm wurde in Delphi 7 programmiert, der beiliegende Source sollte aber auch ohne grössere Probleme mit anderen Delphi-Versionen kompiliert werden können. Im ZIP-File enthalten ist der komplette Sourcecode sowie die ausführbare EXE für alle die, die kein Delphi ihr eigen nennen.

VidSplitt.zip (300 kB)

Have Fun!