FVF (Multimediaformat)

[FAlter]

Hi,

ganz früher mal habe ich ein paar Bilddateien, einen Sound dazu und ein paar Infos in einer ini genommen, alles eine Datei gepackt und das ein Videoformat genannt.

Nun hat mir das aber irgendwann nicht mehr gefallen, und so habe ich kurzerhand etwas neues draus gemacht. Dieses neue Format möchte ich euch hier vorstellen.

Unten findet ihr die Units meines aktuellen FVF-SDK, sowie Beispiele für einen Player und (NEU) einen Encoder (unterstützt bisher nur Video, kein Audio). Erstellt euch ein Package und tut mindestens die FVFPlayer.pas rein, diese Komponente könnt ihr aufs Form ziehen und nutzen. Oder ihr erstellt die Komponente im OnCreate... Siehe dazu die Beispiele, diese nutzen keine Packages (ihr müsst ggf. die Suchpfade in den Projekteinstellungen anpassen, die Struktur im Archiv entspricht nicht der Struktur in meiner Ablage).

Unterstützte Formate:

• Video
  • (NEU) BGR8[R/B/M] (Farbreduktion 8 Bit mit Schwerpunkt auf rot/blau/gemischt)
  • (NEU) BGR8[R/B/M]I (Farbreduktion 8-Bit + Interlaced)
  • BGR16 (Farbreduktion 16-Bit)
  • BGR16I (Farbreduktion 16-Bit + Interlaced)
  • BGR24 (Unkomprimiert)
  • BGR24I (Interlaced)
  • MJPEG (JPEG-Bilder; auch Interlaced)
  • NONE (Dummy)
• Audio
  • FMK (Audiodaten entsprechen FMK-Format)
  • NONE (Dummy)

Zum Aufbau des Dateiformats:

Zuerst kommt folgender Header:

Delphi-Quellcode:

  TFVFHeader = packed record
    FVFSignatur:  array[0..2] of Char; //Da steht 'FVF' drin
    MajorVersion: Byte; //0
    MinorVersion: Word; //2 (1 unterstützt nur Dateien bis 4GB, s.u.)
    Width:        Word;
    Height:       Word;
    FrameTime:    Word; //ms pro Frame
  end;

Dann kommen zwei nullterminierte Ansi-Strings, z. B.

Code:

'NONE'#0 +
'NONE'#0

Diese geben das verwendete Video- (erstes) und Audioformat an. Im Beispiel sind es die Dummys, welche verwendet werden, um z. B. Videos ohne Audiospur oder Musik ohne Video zu speichern. Leider gibt es momentan noch keine Audiocodecs (außer dem Dummy-Codec)...

Darauf folgen nochmal zwei Int64 (bei Dateiversion 0.1 LongWord/32-Bit), z. B.

Code:

0 4

Diese geben die Größe der Video- und Audiodaten an. Dann folgen die eigentlichen Daten.

Der Audio-Dummy benötigt noch die Zeit, wie lange das (eventuelle) Video ohne Audio gehen soll, da diese noch nirgends gespeichert wurde. Normalerweise kann das nämlich aus den Audiodaten - falls benötigt - ermittelt werden. Daher haben wir hier 4 Bytes dafür reserviert. Dies könnte folgendes DWord sein:

Code:

1000

Im Beispiel haben wir also eine leere, eine Sekunde dauernde, Stille erzeugt. Nach den Audiodaten kann theoretisch alles mögliche stehen, das wird nicht mehr verarbeitet. Es wäre z. B. denkbar, wie auch bei MP3s, am Ende Tags anzuhängen (mit den ID3v1-Dags ist es somit kompatibel).

Mfg
FAlter

[FAlter]

Hi,

neue Version...

Jetzt wird - mit Hilfe der midicom6-Komponenten (Die ihr aber auch bei 2006 verwenden könnt...) - das FMK-Format als erstes Audioformat unterstützt

Desweiteren wurden BUGS gefixt:

• Videoframezeit=0 -> Division durch Null
• Videoböhe=0 oder Videobreite=0 und Stretch=true sowie Proportional=true -> Division durch Null

Das Beispielprogramm habe ich erstmal noch nicht neu compiliert. Dort habe ich jetzt jedoch noch eine Checkbox für die LOOP-Eigenschaft gesetzt. Häkchen rein und danach auf Play - und schon wirds nach Beendigung wiederholt.

Mfg
FAlter

[xZise]

Cooles Projekt xD Aber woher bekomme ich den FMK-Codec?

[kalmi01]

Wirklich interessantes Projekt, erinnert mich irgendwie an das AMIGA-IFF.
Das konnte damals auch alle üblichen Sachen wie Text/Grafik/Sound.
Inhhalte waren über den Header deklariert.
So ein InterchangeableFileFormate hat schon was.
Selbst, wenn es "nur" Universal und nicht "Intergangeable" ist.

[FAlter]

Hi,

der FMK-Codec befindet sich in der FVFCodecFMK.pas. Wie ich gestern bereits angemerkt habe, habe ich die compilierte Version des Beispielprogrammes noch nicht aktualisiert. Daher wird bei dieser ein fehlender Codec gemeldet. Da bisher nur wenig Interesse gezeigt wurde, wollte ich das (Aktualisieren) erst tun, wenn noch ein paar mehr Codecs unterstützt werden, außerdem möchte ich zuvor noch ein paar Erweiterungen am MJPEG-Codec vornehmen.

Wenn du die Musik anhören willst, kannst du z. B. einfach den Quelltext herunterladen und das Beispiel selbst compilieren. Ich habe TurboDelphi verwendet, aber habe das Beispielprogramm (mit einem Klick auf "Alles Ignorieren") problemlos auch mit Delphi 6 compiliert bekommen.

Das IFF kenn ich gar nicht... Aber das man mit Videoformaten Bilder anzeigen kann, ist klar (das sind ja One-Frame-Videos). Und über die Dummies geht eben auch ein Zero-Frame-Video, was z. B. nut Ton hat. Genaugenommen ist FVF (Felix' Vielseitiges Format; wer lieber Englisch mag, kann Versatile einsetzen) eben doch nur (wie es ursprünglich hieß) Felix' VideoFormat.

Mfg
FAlter

PS: Wenn ich meine Digitalfotos kopiert und angesehen habe, beschäftige ich mich weiter mit dem Projekt, dann gibts bald wieder 'ne Neuerung und - versprochen - ein Update des compilierten Beispieles. Dafür werde ich das Erotik-Video herausnehmen, also Beeilung, wer es sehen will.

[FAlter]

Hi,

jetzt habe ich wie versprochen mit der neuen Version auch gleich die neue Version des compilierten Beispiels hochgeladen. Desweiteren wurde folgender Codec geändert:

MJPEG-Codec

Außer dem Namen wurde überhaupt nichts vom AVI-MJPEG-Codec geklaut! Eigene Idee (hatte ich schon, bevor ich jenen kennenlernte)!

Was war bisher? Der MJPEG-Codec beinhaltet seit jeher JPEG-Einzelbilder, wie sie auch in einzelnen Dateien sein könnten. Das heißt, die MJPEG-Bildgröße muss nicht unbedingt mit der Videogröße übereinstimmen. Hat man z. B. verschiedene Digitalfotos (z. B. einige in 640x480 und einige in 1280x960), so kann man diese für eine Diashow in gemeinsame Größe bringen. Die Daten des MJPEG-Codecs können nun u. a. die Originalbilder samt EXIF undsofort beinhalten, welche man dann theoretisch wieder herausextrahieren kann. Für die Diashow wird das Bild aber immer in der gemeinsamen Auflösung, z. B. 1280x960, angezeigt.

Was ist neu? Nun werde ich für Diashows vermutlich irgendwann mal einen Extra-Codec kreieren, welcher verschiedene Originalbilder als Bildformate unterstützt und Übergangsframes (für Bildübergänge!) live berechnet, sodass diese nicht mehr gespeichert werden. Daher habe ich die Strategie für den "klassischen" MJPEG-FVF-Codec geändert. Dieser sieht es jetzt, wenn ein Frame halb so groß wie (oder noch kleiner als) die halbe Videohöhe ist, als ein Interlaced-Frame an (nur jede zweite Zeile gespeichert).

Was kommt noch (irgendwann)? Auf jeden Fall wird es mein MJPEG-Codec unterstützen, dass man bei Wiederholung des vorigen Frames nicht das Frame nochmal speichern muss (bisher kann man schon die Hälfte weglassen - toll. oder?). Eventuell (wohl eher wahrscheinlich) werde ich ihn auch unterstützen lassen, auf ein beliebiges voriges Frame zurückzugreifen, das schonmal war. Wenn also am Ende des Films das Ausgangsbild (oder der Anfangsteil) wiederholt wird, muss das entsprechende Frame (bzw. die Frames) nurnoch auf das erste Vorkommnis desselben Bildes zeigen, damit es nochmal verwendet wird. Damit kann ich sicher nochmal bei einigen Videos ein paar kB einsparen.
Die Aufwärtskompatiblität wird auf jeden Fall erhalten bleiben, also Videos, die jetzt mit MJPEG komprimiert werden, können später abgespielt werden. Umgekehrt natürlich keine Garantie (ein jetzt schon MJPEG unterstützender Player muss später mit der neuen Version neu compiliert werden, um die zukünftigen Videos, welche eventuell Qualitätsmäßig identisch und trtotzdem einige kB kleiner sind, wiederrgeben zu können).

Mfg
FAlter

Hinweis zum Anhang: Dass die Datum-Uhrzeit-Angabe auf verschiedenen Frames unterschiedlich groß ist, ist beabsichtigt. Die Frames, wo sie kleiner ist, sind übrigens interlaced! Dass die Uhrzeit ungleichmäßig vergeht, liegt daran, dass Bereiche, bei denen der Unterschied zum vorigen Frame kleiner als 1 % ist, herausgeschnitten wurden. Das ist der Sinn des Programmes, mit dem das Video erstellt wurde.

[arne99]

Was mir aufgefallen ist:

Umgebung: WinXP SP2
Programm ausgeführt und letzte Beispiel FVF von Überwachungsvideo genommen.
Zwischen Start und Ende (während Play) geht die Schriftgröße mal von Normal 10-12 pt auf 8pt runter etc.
Is das Video dass es so macht oder dein Codec, oder die Software?

Gruß arne99

[FAlter]

Hi,

wenn ich mich da selbst zitieren darf:

Zitat von FAlter:

Hinweis zum Anhang: Dass die Datum-Uhrzeit-Angabe auf verschiedenen Frames unterschiedlich groß ist, ist beabsichtigt. Die Frames, wo sie kleiner ist, sind übrigens interlaced!

Das ist in den Frames so gespeichert.

Die Gedanken dazu waren:

Es soll sichergestellt sein, dass die Urhzeit auch auf dem Einzelframe lesbar bleibt (wg. Überwachungskamera), was mit kleinerer Schrift so ist, wohingegen die auch nicht gerade große größere Schrift, wenn jede zweite Zeile fehlt, nicht mehr lesbar wäre. Daher wurde die halbe Höhe (in px) verwendet, dafür jedoch jede Zeile der Schrift gespeichert. Auf dem Video sieht es bei nacheinander abgespielten interlaced-Frames so aus, als wäre die Schrift verzerrt, aber sieht man sich das Einzelframe an, so ist es immerhin noch lesbar.

Mfg
FAlter

[arne99]

Okay Kommando zurück, mein Fehler. Sorry.

[FAlter]

Hallo zusammen,

ich habe nach 10 Jahren mal ein kleineres Update zu diesem Projekt gemacht. Es gibt neue 8-Bit-Codecs, ein paar kleinere Bugfixes, einen Encoder samt Demoprojekt sowie eine Neue Version 0.2 des Dateiformats, die nun Int64 statt Longword verwendet um Dateien > 4GB zu unterstützen.

Die Anhänge sind ausgetauscht. Statt des alten Testprogramms gibt es zwei neue Beispielprogramme.

Das ist alles noch mit Turbo Delphi (2006) erstellt, keine Ahnung ob es unter einem neuen Delphi laufen würde, ich habe kein neueres und nach Lazarus habe ich es nicht portiert, da TBitmap nicht kompatibel ist.

Viele Grüße

Felix