Bitmaps2Video für Windows Media Foundation

[Renate Schaaf]

Aktualisierung:

Eine erste Version des Projekts gibt es jetzt auf https://github.com/rmesch/Bitmaps2Vi...dia-Foundation.
Für Details siehe das Readme dort.

/Aktualisierung

In letzter Zeit habe ich an einem port von Bitmaps2Video von ffmpeg auf Windows Media Foundation gearbeitet, denn mir gefällt nicht, dass es diese ganzen Dlls benötigt.
Bevor ich das Resultat auf GitHub hochlade, möchte ich es gern hier vorstellen, da ich nur begrenzte Möglichkeiten zum Testen habe.
Außerdem hoffe ich, vielleicht ein paar Tips für noch bestehende Probleme zu bekommen (siehe unten). Die Dokumentation von WMF hat mich schon ein paar Mal an den Rand des Wahnsinns getrieben.

Was es tut:
Enkodiert eine Serie von Bitmaps als Video, wobei man als Benutzer nur Grundkenntnisse über Videos haben muss.
Kann 2 Sorten von Übergängen zwischen Bildern als Beispiel dafür, wie man mehr einbauen kann.
Unterstützt Dateiformate .mp4 mit Codecs H264 oder H265, oder .wmv mit Codec WMV3.
Benutzt die GPU zum Enkodieren, falls unterstützt, falls nicht, wird Software benutzt.
Benutzt parallele Routinen wann immer das Sinn macht.
Hat eine experimentelle Routine zum Einfügen von Audio (Muxer). Geht im Moment nur für H264 und WMV3.

Was es braucht:
VCL-basiert
Braucht die hervorragenden MF-headers von https://github.com/FactoryXCode/MfPack.
Den Ordner src von MFPack zum Bibliothekspfad hinzufügen, packages müssen nicht installiert werden.
Um alle features zu nutzen, braucht es Windows10 oder höher.
Delphi-Versionen: Braucht wahrscheinlich mindestens XE3, aber ich habe nur 11.3 zum Testen.

Probleme:
Ich bin nicht allzu angetan von der Enkodier-Qualität, liegt vielleicht an meiner nVidia-Karte.
Der Audio-Muxer müsste eigentlich auch für H265 funktionieren, denn es geht, wenn ich ffmpeg für's muxen nehme.
Ich habe bis jetzt nicht rausgekriegt, wie ich Video-clips einfüge.

Renate

[Renate Schaaf]

Errata: uToolsWMF hat eine unit Z_prof in der uses-Liste. Einfach entfernen. Kommt davon, wenn man zu viel Zeug im path hat.

Inzwischen habe ich glaube ich rausgefunden, wie man die Qualität verbessern kann.
Um Zeile 270 rum in uBitmap2VideoWMF.pas die folgenden Änderungen machen:

Code:

if succeeded(hr) then
    hr := MFCreateAttributes(attribs, 4);  //<--------- change to 4 here
  // this enables hardware encoding, if the GPU supports it
  if succeeded(hr) then
    hr := attribs.SetUINT32(MF_READWRITE_ENABLE_HARDWARE_TRANSFORMS, UInt32(True));
  // this seems to improve the quality of H264 and H265-encodings:
  {*************** add this *********************************}
  // this enables the encoder to use quality based settings
  if succeeded(hr) then
    hr := attribs.SetUINT32(CODECAPI_AVEncCommonRateControlMode, 3);
  {**************** /add this *******************************}
  if succeeded(hr) then
    hr := attribs.SetUINT32(CODECAPI_AVEncCommonQuality, 100);
  if succeeded(hr) then
    hr := attribs.SetUINT32(CODECAPI_AVEncCommonQualityVsSpeed, 100);

[klaus schaaff]

Hallo Renate,

es gibt verschiedene Lanczos Varianten. Dein Lanczos sieht bei mir so aus:

Delphi-Quellcode:

function LanczosXFilter(Value: Extended; LanczosWidth: Integer): Extended;
var
  y, yinv: Extended;
begin
  Value := abs(Value);
  if Value = 0 then
    Result := 3
  else if Value < 1 then begin
    y := Pi * Value;
    yinv := 1 / y;
    Result := sin(3 * y) * sin(y) * yinv * yinv;
  end else
    Result := 0;
end;

Es erzeugt eine Rasterung bei 80% Verkleinerung, siehe Anhang Lanczos.jpg

Meine Variation von Lanczos erzeugt kein Raster:

Delphi-Quellcode:

function LanczosXFilter(Value: Extended; LanczosWidth: Integer): Extended;

  // Normalisierte SinC Funktion = sin(Pi*x) / (Pi*x)
  function SinC(Value: Extended): Extended;
  begin
    if Value <> 0 then begin
      Value:= Value * Pi;
      Result:= Sin(Value) / Value;
    end else
      Result:= 1;
  end;

begin
  if Value < 0 then
    Value:= -Value;
  if Value < LanczosWidth then
    Result:= SinC(Value) * SinC(Value / LanczosWidth)
  else
    Result:= 0;
end;

Weiter finde ich es problematisch auf 3rd Party MfPack, zu verweisen, das es inzwischen in mehr als 4 unterschiedlichen Versionen mit unterschiedlichen Unitnamen gibt. Daduch erhält dein Package eine Halbwertszeit von MfPack. Nicht gut!

Auch die Objektorientierte Kapselung mit Class of Funktionen in Records usw. ist total overpowered. Die tatsächlichen WindowAPI Funktionen sind keine Class Funktionen, brauchen das nicht.

Liebe Grüße
Klaus Schaaff

[Renate Schaaf]

Zitat:

Meine Variation von Lanczos erzeugt kein Raster:

Danke, guck ich mir mal an. Meine Lanczos-Funktion ist die, die man weit verbreitet findet, und die z.B. in Graphics32 benutzt wird. Das mit der Rasterung ist mir nicht aufgefallen.
Hast Du ein Repo, wo ich mir Deine Version mal angucken kann?

Zitat:

Weiter finde ich es problematisch auf 3rd Party MfPack, zu verweisen

Wie soll ich es denn sonst machen? Ich könnte natürlich die header-units, die ich brauche, in mein Repo kopieren, aber das finde ich ein bisschen schofel den Entwicklern von MfPack gegenüber, die viel Arbeit in diese header gesteckt haben. Ich weiß, in meiner ffmpeg-version habe ich es so gemacht, weil es so einfacher ist, zu sehen, wo die ganzen .dlls hinmüssen, aber ich habe eigentlich immer ein schlechtes Gewissen deswegen.
Inzwischen habe ich den Tip bekommen, mfPack als submodule hinzuzufügen, das muss ich mir aber erstmal zu Gemüte führen.

Code:

Auch die Objektorientierte Kapselung mit Class of Funktionen in Records usw. ist total overpowered.

Das ist Geschmackssache. Werde ich garantiert nicht ändern. Und in wiefern sind Records overpowered? Ist doch nun wirklich keine "rocket-science". Mit Klassen und Records zu arbeiten ist einfach viel strukturierter, allein wegen Code-Completion.
Im Gegenteil, ich hatte schon eine vage Idee, einigen Media-Foundation-Funktionen ein Klassengerüst zu geben. Dauernd muss man diese Attributs-Namen nachgucken, und wie man sie wohin und wann und wie einlesen muss.

Renate

[Renate Schaaf]

Zitat:

Dein Lanczos sieht bei mir so aus:

Hallo, Klaus,

Du hast die Funktion falsch skaliert, da ist es kein Wunder, wenn Mist dabei rauskommt. Meine Filter sind alle auf Weite 1 normalisiert, und die Skalierung auf den Radius mache ich erst, wenn ich die Gewichte berechne. Willst Du auf Weite LanczosWidth umskalieren, musst du das so machen:

f_skaliert(value)=1/LanczosWidth*f(value/LanczosWidth).

Und wenn dann, wie ich stark annehme, LanczosWidth=3 ist, dann haben wir, schwupp, die gleiche Funktion. Rechne es nach .

Renate

[klaus schaaff]

Hallo Renate,

das Ganze ist eine ökonomische Kalkulation. Was möchte ich?
Wieviel Mannstunden sind dafür nötig? Was bekomme ich anschließend dafür. Das ist in deinem Fall, nicht ohne weiteres
sofort absehbar und dafür würde ich mir an deiner Stelle Zeit
lassen.

Das Lanczos Raster kann durchaus bei dir korrekt funktionieren, so wie du skalierst. Mir ist damals (vor 10 Jahren) aufgefallen,
die Rechenzeiten gehen dort so drastisch in die Höhe, dass ich
Lanczos nur der Vollständigkeit aufgenommen habe. Im übrigen
habe ich keine GPU-Implementierung.

Bei mir sieht die Liste so aus:

Nearest
Bilinear
Bicubisch
Mitchell
Lagrange
BSpline
Lanczos
Halftone

Hier ist Halftone sehr wichtig für Verkleinerungen optimal. Für Vergrößerungen gar nicht zu gebrauchen.

Ähnlich alle anderen. Man muss vorher genau wissen, welcher
Algorithmus ist gut für Vergrößerungen und welche sind gut für
Verkleinerungen.

Leider kann ich dein Packet nicht compilieren, da bei mir Delphi 2009 die höchste Version ist.

Zur objektorientieren Kapselung, mir reichen die Delphi 7 Implemntierungen vollkommen aus.

Und nochmals, das sind nur meine persönlichen Erfahrungen mit dem Thema, wie gesagt vor 10 Jahren. Die gesammte Delphi-Gemeinde scheint zu akzeptieren, dass heute niedrigere Delphi-Versionen ausgeschlossen werden. Das mag ich nicht. Dennoch, es bleibt allein deine Entscheidung.


Liebe Grüße
Klaus Schaaff