TBitmaps2Video

[Renate Schaaf]

Ich verfolge dieses Forum seit einiger Zeit passiv mit viel Vergnügen und habe nützliche Hinweise gefunden.
Jetzt möchte ich gern mein neuestes Projekt zur Diskussion stellen, eine Klasse, die es ermöglicht sequentiell Bitmaps zu einem Video zusammenzustellen. Ich kann mir vorstellen, dass die/der eine oder andere sowas gebrauchen kann. Die Klasse baut auf den Libav(ffmpeg)-dlls auf, aber mein Ziel war es, ein interface mit leicht und intuitiv verständlichen Prozeduren und Einstellungen herzustellen, ohne dass man sich um die etwas obskuren und technischen Prozeduren in den dlls kümmern muss.

Jetzt zu finden auf GitHub:
https://github.com/rmesch/Bitmaps2Video

Update:
Source code: Bitmaps2Video_3.zip
Es werden jetzt 7 Codecs unterstützt, m.E. die wichtigsten.
Das geänderte interface ist jetzt:

Delphi-Quellcode:

///<summary>Sequentially encode bitmaps to a compressed video. Uses Libav Dlls. </summary>
  TBitmapEncoder = class
.....
    /// <param name="filename"> Output filename. Extension picks the container format (.mp4 .avi .mkv ..)
    /// </param>
    /// <param name="Width"> Video size in pixels (multiples of 2)</param>
    /// <param name="Height"> Video size in pixels (multiples of 2)</param>
    /// <param name="FrameRate"> Frames per second (can be slightly off in the resulting file)</param>
    /// <param name="Quality"> Encoding quality, scale from 0 to 100. 0 gives marginally acceptable quality </param>
    /// <param name="CodecId"> (TAVCodecID see UFormats.pas) Identifier of the codec to use. AV_CODEC_ID_NONE picks the default codec for the file extension. </param>
    /// <param name="VideoScaling">Resample algo used if video size differs from bitmap size </param>
    constructor Create(const filename: string; Width, Height: integer;
      FrameRate: integer; Quality: byte; CodecId: TAVCodecId = AV_CODEC_ID_NONE;
      VideoScaling: TVideoScaling = vsFastBilinear);

    /// <summary> Turn a Bitmap into a movie frame </summary>
    /// <param name="bm"> Bitmap(TBitmap) to be fed to the video. Will be converted to pf32bit if not already </param>
    procedure AddFrame(const bm: TBitmap);

    /// <summary> Hold the last frame </summary>
    /// <param name="EffectTime"> Displaytime(integer) in ms </param>
    procedure Freeze(EffectTime: integer);

    /// <summary> Add a picture which is displayed for a certain time </summary>
    /// <param name="bm"> Bitmap(TBitmap) of the picture to be displayed </param>
    /// <param name="ShowTime"> Time(integer) in ms for the display </param>
    procedure AddStillImage(const bm: TBitmap; ShowTime: integer);

    /// <summary> Make a smooth transition from SourceR to TargetR within EffectTime.</summary>
    /// <param name="bm"> The Bitmap(TBitmap) to be animated </param>
    /// <param name="SourceR"> Beginning rectangle(TRectF) within rect(0,0,bm.width,bm.height) </param>
    /// <param name="TargetR"> End rectangle(TRectF) within rect(0,0,bm.width,bm.height) </param>
    /// <param name="EffectTime"> Duration(integer) of the animation in ms </param>
    /// <param name="ZoomOption"> Quality of the zoom (zoAAx2, zoAAx4, zoAAx6, zoResample). </param>
    /// <param name="SpeedEnvelope"> Modifies the speed during EffectTime. (zeFastSlow, zeSlowFast, zeSlowSlow, zeLinear) </param>
    procedure ZoomPan(const bm: TBitmap; SourceR, TargetR: TRectF;
      EffectTime: integer; ZoomOption: TZoomOption;
      SpeedEnvelope: TZoomSpeedEnvelope = zeLinear);

    /// <summary> Close the file and make the output file usable. </summary>
    function CloseFile: Boolean;

Audio wird jetzt rudimentär unterstützt:

Delphi-Quellcode:

  /// <summary> Combine the video stream from VideoFile with the audio from Audiofile. The streams will just be copied, not encoded.
  ///Audio is clipped to video length. Raises exception if the format of the audio file is not supported.</summary>
  /// <param name="VideoFile"> (string) File which contains a video stream. Any audio stream present will be ignored. </param>
  /// <param name="AudioFile"> (string) Genuine audio file (.wav .mp3 .aac) the audio of which shall be added to the video in VideoFile. </param>
  /// <param name="OutputFile"> (string) Name of the file containing the newly combined video and audio. </param>
procedure MuxStreams2(const VideoFile, AudioFile: string;
  const OutputFile: string);

Das Projekt benötigt die ffmpeg-dlls und die zugehörigen Pascal-Headers. Beides kann man hier bekommen:
http://www.delphiffmpeg.com/downloads/

Näheres im Readme, und in meiner Antwort unten.

Ich bin sehr an Verbesserungsvorschlägen interessiert, vor allem, wie man die Schreibgeschwindigkeit erhöhen kann, und wie man eventuell die vorhandenen Libav-Filter dafür benutzen kann, und auch an Vorschlägen, was man noch einbauen sollte.

Renate

[TurboMagic]

Hallo,

anbei ist eine Datei die du über die vorhandene der MultiDemo drüberkopieren kannst.
Damit sind dann alle FFMPEG Dateien für Android 32 und 64 Bit sowohl für Debug als
auch für Release hinzugefügt.

Grüße
TurboMagic

[Renate Schaaf]

Kurzes Update für

https://github.com/rmesch/Bitmaps2Video

Die cross-platform-Version hat mehrere Erweiterungen erfahren, z.B. gibt es Methoden für Zoom und Pan, und für einfache Cross-Fade Übergänge. Außerdem könnt Ihr Eure Video-Clips einbauen und eine Audio-Datei als Audio-Spur hinzufügen. Um Seitenverhältnisse braucht man sich nicht mehr zu kümmern, wenn nötig wird aufgefüllt. Das reicht schon für eine sehr einfache Diaschau..
Die Demo erklärt eigentlich alles .

Nachdem die fmx-TBitmaps in threads Probleme machen, habe ich fast alle Pixel-Manipulationen auf die Video-Frames verlagert, das funktioniert bei mir ganz gut, aber ich wäre sehr erfreut, wenn einige von Euch das mal testen könnten, es gibt sicher noch viel zu reparieren.
Außerdem kann ich nur Android32 testen und habe keine Ahnung, wie das ganze inzwischen unter Android64 läuft.

Hoffe es macht Spaß.

Renate

[Rollo62]

Sehr schönes Projekt, dankesehr für die Mühe es Multiplattform zu machen.

Was ich mich immer zuerst frage ist, woher die libraries und header kommen
im https://github.com/PassByYou888/FFMPEG-Header Projekt ?
Sind die jeweils aus den aktuellsten FFMPEG-Binaries, und wenn ja welches wären dann die richtigen Links dazu ?

Ich bin immer etwas (über)vorsichtig wenn Binaries dabei sind, insbesondere wenn die schon 2 Jahre alt sind.

Es wäre gut wenn man da die Quellen der Relleases direkt kennen würde,
ich vermute es kommt irgendwo von hier, aus den alten Releases.

Mittlerweile scheint da jetzt die FFMPEG Hauptversion 4.0 aktiv zu sein,
wäre schön wenn Du eine Info hättest, falls Du etwas Genaueres dazu weisst.

[Renate Schaaf]

Hallo @Rollo62,

Das sind die Werte aus dem Header:

LIBAVCODEC_VERSION = '57.107.100';
LIBAVDEVICE_VERSION = '57.10.100';
LIBAVFILTER_VERSION = '6.107.100';
LIBAVFORMAT_VERSION = '57.83.100';
LIBAVUTIL_VERSION = '55.78.100';
LIBSWRESAMPLE_VERSION = '2.9.100';
LIBSWSCALE_VERSION = '4.8.100';

Die Daten scheinen sich damit zu decken:
FFmpeg 3.4.8 "Cantor"
3.4.8 was released on 2020-07-04 //??? Datum ist seltsam
libavutil 55. 78.100
libavcodec 57.107.100
libavformat 57. 83.100
libavdevice 57. 10.100
libavfilter 6.107.100
libavresample 3. 7. 0
libswscale 4. 8.100
libswresample 2. 9.100
libpostproc 54. 7.100

Jetzt hab ich das alles selber grad zum ersten Mal gelesen

Das header-file funktioniert für mich am besten, aber ich wollte eigentlich schon lange nach Aktualisierungen suchen.

Auf eine andere Version umzustellen scheint mir nicht leicht zu sein, und ich muss irgendwo die binaries herkriegen, denn kompilieren kann ich den source-code ganz bestimmt nicht.


Hoffe, du bist weniger verwirrt als ich!

Renate

[Rollo62]

Zitat:

Hoffe, du bist weniger verwirrt als ich!

Sorry, keine Chance. Ich bin schon auf Mad-Scientist-Level

Ich bezog mich eigentlich auf das Datum der Binaries, was in Github dabei ist.
Unter "FFMPEG-Header/BinaryLibrary/Android-armeabi-v7", da sagt Github "2 years old".

Und bei allen anderen auch, aber ich sehe gerade dass die größtenteils leer sind, und nur eine leere Dummy-Datei drin ist.

Was Du schreibst deutet ja eher darauf hin dass es mit dem neuesten Stand kompatibel sein sollte, damit sollten die aktuellen Binaries von FFMPEG laufen.
Die muss man sich dann wohl irgendwie aus den Installationsfiles extrahieren,
es sei denn FFPMEG hat die Binaries irgendwo gehostet.

[Renate Schaaf]

Zitat:

Was Du schreibst deutet ja eher darauf hin dass es mit dem neuesten Stand kompatibel sein sollte, damit sollten die aktuellen Binaries von FFMPEG laufen

Ich glaub so einfach ist es nicht. Die Version ist aus einem anderen branch, und das release-Datum hat mich auch verwirrt.
Es gibt binaries und header für 4.1, aber nur für 32-bit Android, und ich werde jetzt nicht noch eine Version anlegen.

Alle anderen headers/binaries, die ich gefunden habe, sind mindestens 2-3 Jahre alt.

Ich guck jetzt mal, was der Google-Store so hat.

Gruß, Renate

[th1975]

Erstmal vielen Dank für das Projekt. Konnte ich zwar nicht 1:1 benutzen, hat mir den Einstieg in die Verwendung von FFMPEG aber sehr erleichtert!
Eine Sache ist mir aufgefallen, die zu dropped frames im exportierten Video führt (steht ja auch schon in den Kommentaren):

In TBitmapEncoder.encode

Delphi-Quellcode:

  else
    begin
      pkt.pts := fFrameCount;
      pkt.dts := fFrameCount;
    end;

    av_packet_rescale_ts(@pkt, c.time_base, stream.time_base);
    pkt.stream_index := stream.index;

    // Write the encoded frame to the video file.
    // Can fail without causing harm, but should be checked in the debugger if frames are missing
    ret := av_interleaved_write_frame(oc, @pkt);
    result := (ret >= 0);
    av_packet_unref(@pkt);
    fVideoTime := round(1000 * av_rescale_q(av_stream_get_end_pts(stream),
      stream.time_base, c.time_base) / fRate);
  end;

Die Packet-Timestamps pkt.dts und pkt.pts sollten nicht mit dem fFrameCount hochgezählt werden. Besser einen weitern Zähler für die ausgegebenen Packets / pkt verwenden. Dann schlägt av_interleaved_write_frame auch nicht mehr hin und wieder fehl. Grund: Jedes Packet das der Codec ausspuckt entspricht einem Frame für die Wiedergabe, also muß jedes Packet eine aufsteigende presentation/decoding time pts/dts haben (nicht jedes Format ist da pingelig, MPEG-Container z.B. schon). Allerdings gibt der Codec (je nach Codec) für jeden mit avcodec_send_frame "reingeworfenen" Frame nicht immer genau ein Packet aus, sondern manchmal auch gar keins und manchmal mehrere auf einmal. Im ersteren Fall wird bei Verwendung von fFrameCount quasi ein Frame doppelt solange angezeigt, im zweiten Fall schlägt av_interleaved_write_frame fehl weil mehrere Packets mit gleicher pts geschrieben werden sollen.

Gruß, Tassilo

[Renate Schaaf]

Zitat:

pkt.pts sollten nicht mit dem fFrameCount hochgezählt werden

Danke für die gute Erklärung, ich versuchs mal einzubauen. Vielleicht erklärt das auch die Unverträglichkeiten, die ich sehe. Zu meiner Schande muss ich gestehen, dass ich bei dem Projekt viel mehr experimentelles Programmieren angewendet habe, als mir lieb ist . Wenn es hilft, mit FFMPeg klarzukommen, hat das Projekt aber schon seinen Sinn erfüllt.

Edit
Hach, hatte ich doch vor ein paar Tagen schon eingebaut! Man wird alt und dappisch. fFramecount wird nach jedem erfolgreich gelesenen packet heraufgesetzt, bei hereinkommenen Video-frames wird fFramecount von deren timestamps abgelesen, damit, wenn später wieder einzelne bitmaps dazukommen, das timing immer noch stimmt. Da der while-loop fast sicher bei bitmap-frames nur einmal voll durchlaufen wird, werden wirklich die bitmap-frames gezählt und gleichmäßig abgespielt.

Hab vorübergehend einen Zähler eingebaut, der zählt, wie oft av_interleaved_write_frame danebengeht. Bei Videos von insgesamt mehr als einer Stunde Spielzeit, bitmaps und clips gemischt: Nicht einmal.

Jetzt muss ich nur noch herausfinden, wie ich mir das Funktionieren der Codecs mpeg-1 und mpeg-2 zerschossen habe, und dann gibts ein Update.

Gruß und Danke nochmal, ist schön so konkretes Feedback zu kriegen.