Schnellere Alternative zu Avisynth/Vfw möglich?

[Garfield]

Hallo,

für einen Bekannten habe ich ein Tool erstellt, welches einen Player auf Grundlage dieses Tipps aus dem Swiss Delphi Center zur Wiedergabe von AviSynth-Scripten enthält.

Beim Test hat er festgestellt, dass es beim Scrollen mit den Cursortasten (Links = zurück, Rechts = vor) ab und zu zu Stillständen kommt, während es in VirtualDubMod flüssiger funktioniert. Nun stellt sich die Frage, ob mein Player beschleunigt werden kann? Zum Beispiel, indem man die einzelnen Frames nicht über Vfw sondern direkt von der AviSynth.Dll abfordert. Ich weiß allerdings nicht wie.

Im Anhang ist das Tool (reduziert auf den Player) als Source und kompiliert. Ich arbeite mit Delphi 7 Personal Edition.

Anmerkung, damit niemand schreibt: "Dann nimm doch VDM": Es werden mehrere Tools für die Bearbeitung des AviSynth-Scriptes benötigt, deren benötigte Funktionen in dem Tool vereint werden.

[Garfield]

Bei http://forum.gleitz.info/ habe ich die angehängte Unit gefunden, mit welcher ich aber nicht zurechtkomme.

[Garfield]

Leider konnte mir in der kurzen Zeit noch niemand helfen. Ich bitte ich um Verständnis, dass ich erst in 12 Tagen wieder vorbeischauen kann, da ich auf Montage gehe und mir dort kein Internetanschluss zur Verfügung steht.

[Garfield]

Habe wohl wieder ein zu spezielles Thema erwischt. Viele werden den TMediaPlayer oder das DSPack verwenden. Ist hier allerdings nicht das richtige. Auf http://aquaplaning.20m.com/ gibt es das Programm AVSCompare mit AVSWrap.DLL. Dies wäre schon das richtige, nur ist die DLL fehlerhaft. Das heißt, das schnelle Abrufen aufeinanderfolgender Frames ist nur von Position 0 an möglich. Bei anderen Positionen bekommt man nur das Frame an dieser Position. Ausserdem bleibt die Wiedergabe nach einer Weile einfach stehen.

[Garfield]

Für Programmierforen wie unseres scheint diese Frage zu speziell zu sein. Das ist wohl auch der Grund dafür, dass bei Doom9.org und Gleitz.info Unterforen für Softwareentwicklung eingerichtet wurden. Da wird nun auch an der Lösung meines Problemes gearbeitet.

[Garfield]

In der obigen Source ist leider ein Fehler enthalten. Wenn man die Cursortasten drückt, wird zwar die Position der Trackbar verändert, aber es wird kein Frame geholt. Unten ist das korrigierte Projekt.

Ausserdem wird die Position der Trackbar erst geändert, wenn das Bild neu gezeichnet wurde.

[Garfield]

Die Bremse liegt im wesentlichen in der Verwendung des TImage. Gibt es dazu eine schnellere Alternative?

[dizzy]

Mh, für diese Anwendung evtl. sowieso eine TPaintbox nehmen statt eines Images, oder schau dir mal die Graphics32 Komponenten an ( www.g32.org ), dort gibt es auch ein verbessertes TImage (TImage32) und eine Paintbox. Evtl. hilft das ja schon.

[Garfield]

An eine TPaintBox habe ich auch schon gedacht. Ich weiß nur nicht wie ich das hinbekomme, weil ich am Ende doch nur ein Handle eines TBitmaps habe.

Delphi-Quellcode:

procedure Tfrm_Haupt.HoleImage(FrameNumber: Integer; ABitmap: TBitmap);
begin
  GetFrame := AVIStreamGetFrameOpen(AVIStream, nil);
  BitmapInfoHeader := AVIStreamGetFrame(GetFrame, FrameNumber);
  bits := Pointer(Integer(BitmapInfoHeader) + SizeOf(TBitmapInfoHeader));

  DC_Handle := CreateDC('Display', nil, nil, nil);

  try
    hBmp := CreateDIBitmap(
    DC_Handle,
    BitmapInfoHeader^,
    CBM_INIT,
    bits,
    PBITMAPINFO(BitmapInfoHeader)^,
    DIB_RGB_COLORS);
  finally
    DeleteDC(DC_Handle);
  end;

  ABitmap.Handle := hBmp;
  AVIStreamGetFrameClose(GetFrame);

end;

In der Regel sind die Frames 32Bit und die Source ein AviSynth-Script. Ich werde mir die Graphics32 sofort ansehen, vielleicht bekomme ich damit hin. Wenn Beispiele dabei sollte es auf jeden Fall gehen.

[Garfield]

Das TImage32 scheitert daran, dass das Handle Property ist. Das Handle des Bitmap kann ihm nicht zugewiesen werden. An sonsten kann man mit den Graphics32 interessante Sachen machen.

Nachtrag:

Bildgröße und Farbtiefe sind bekannt. Kann man das Bild nicht direkt auf das Panel zeichnen?

[dizzy]

Wenn du doch schon ein Bitmap hast, so stehen dir doch so ziemlich alle Wege offen. In diesem Fall würde ich mit BitBlt() das Bitmap einfach "irgendwo" hinzeichnen. "Irgendwo" kann hierbei so ziemlich alles sein, incl. einer Paintbox oder eines Panels. Halt alles was ein Canvas(.Handle) bzw. hDC hat, wenn ich mich recht entsinne.

Gruss,
Fabian
(Und sorry dass ich deinen Monolog gestört habe :mrgreen: ;))

[Garfield]

Zitat:

Zitat von dizzy

(Und sorry dass ich deinen Monolog gestört habe :mrgreen: ;))

Ich freue mich über jede "Störung". Nur dummerweise stelle ich meist Fragen, bei deren Beantwortung mich niemand stören will. Mal sehen, ob ich mit Deinem Vorschlag Erfolg habe. Danke.

[dizzy]

Zitat:

Zitat von Garfield

Zitat:

Zitat von dizzy

(Und sorry dass ich deinen Monolog gestört habe :mrgreen: ;))

Ich freue mich über jede "Störung". Nur dummerweise stelle ich meist Fragen, bei deren Beantwortung mich niemand stören will.

...oder auch kann. Das Problem kenn ich ganz gut, grad wenn man in Delphi Dinge tut die eher selten damit gemacht werden, was imho stark Multimedia angeht abgesehen von mp3-Playern :mrgreen:
Zudem fehlt uns in der DP glaube ich noch ein Video-Experte :)

[Garfield]

Mit Audio beschäftigen sich hier viele, mit Video nur ein paar. Dabei liegt meiner Meinung das Problem darin, dass mit BASS und DSPack immer auf sehr gute fertige Komponenten verwiesen werden kann und nichts bzw nicht viel selbst gemacht werden muss.

Sieht man sich bei Sourceforge usw um, findet man meist Software, welche in C/C++ programmiert ist. Ausnahmen bilden dabei zum Beispiel Gordian Knot, DVD2Ogm, MPEG2Schnitt, abcAVI und YAAI.

Im englischen Doom9-Forum gibt es ein Unterforum für Softwareentwicklung. Darin werden ab und zu auch Fragen zu Delphi gestellt. Auch das deutsche Doom9|Gleitz-Forum besitzt ein Unterforum zur Softwareentwicklung. Aber dort kann man auch keine Delphi- sondern nur allgemeine Fragen stellen.

Derzeit komme ich auf meinem Celeron 2200 Notebook auf 21-22 fps. VirtualDub ist kaum schneller. Damit werde ich mich zufrieden geben müssen, wenn bitblt nichts mehr bringen sollte.

[Garfield]

Mit bitblt hat es nicht geklappt. Jetzt bleibt es so wie es ist. Punktum.

[omata]

Moin,

ich würde mich ja gern mit diesem Thema beschäftigen. Aber wenn ich die Beispiele ausprobiere, geht nichts. Ich bekomme nur Bereichsfehler, ohne ende.

Finde ich sehr schade
Thorsten

[Garfield]

Zitat:

Zitat von omata

Ich bekomme nur Bereichsfehler, ohne ende.

Dürfte eigentlich nicht sein. Geschrieben ist es in Delphi 7 Personal Edition. :cry: Der einzige Fehler welcher mir noch aufgefallen ist, ist dass beim temporären Avisynth-Script für MPEG eine Zeile fehlt.

Delphi-Quellcode:

.     TSL_tmpAVS := TStringlist.create;
      TSL_tmpAVS.Add('SetMemoryMax(' + IntToStr(Memory.Quelle) + ')');
      TSL_tmpAVS.Add('LoadPlugin("' + Video.Decoder + '")');  // <- die Zeile kann raus
      TSL_tmpAVS.Add('MPEGSource("' + Video.QuelleScript + '")');
      TSL_tmpAVS.Add('ConvertToRGB');  // <- diese fehlt.
      TSL_tmpAVS.SaveToFile(Video.tmpQuelle);
      TSL_tmpAVS.Free;

Liegt daran, das MPEG im Farbraum YUV arbeitet und die Anzeige RGB benötigt.

Ob die Avisynth-Version eine Rolle spielt weiß ich nicht. Verwendet wurde Avisynth 2.5.6, weil in dem Script eine Funktion verwendet werden soll, welche es erst in Version 2.5.4 implementiert wurde.

[Garfield]

Jetzt habe ich mal das ABitmap : TBitmap als Rückgabe entfernt und bitblt eingefügt.

Delphi-Quellcode:

function Tfrm_Haupt.HoleImage(FrameNumber): Boolean; 
begin
  GetFrame := AVIStreamGetFrameOpen(AVIStream, nil);
  BitmapInfoHeader := AVIStreamGetFrame(GetFrame, FrameNumber);
  bits := Pointer(Integer(BitmapInfoHeader) + SizeOf(TBitmapInfoHeader));

  DC_Handle := CreateDC('Display', nil, nil, nil);

  try
    hBmp := CreateDIBitmap(
    DC_Handle,
    BitmapInfoHeader^,
    CBM_INIT,
    bits,
    PBITMAPINFO(BitmapInfoHeader)^,
    DIB_RGB_COLORS);
  finally
    DeleteDC(DC_Handle);
  end;

  bitblt (img_Video.Canvas.Handle,
          0,
          0,
          BitmapInfoHeader.biWidth,
          BitmapInfoHeader.biHeight,
          hBmp,
          0,
          0,
          SrcCopy);

  AVIStreamGetFrameClose(GetFrame);

  Result := True;

end;

Das Bild ist weiß und alles sehr träge. In den Beispiele, welche ich gesehen habe wurde auch mit Bitmaps gearbeitet. Hier ist die Source ein DIBitmap.

[grizzly]

Also auf meiner Kiste läuft das Programm problemlos. Das einzige "Ruckeln" zeigt sich wie erwartet beim rückwärts Abspielen. Aber hier hat auch VirtualDUB Probleme. Das liegt meines Erachtens nur an der Art und Weise, wie AVIs kodiert sind: Ein vollständiger Frame wird gefolgt von einem Haufen Differenzframes. Angenommen, Dein Programm ist bei Frame 100, soll nun Frame 99 anzeigen, aber das ist nur ein Differenz-Bildchen relativ zu Bild 80, dann muß AviSynth alle Bilder ab Frame 80 bis zu Frame 99 dekodieren. Für Bild 98 gehts dann wieder los: Dekodiere alles von Bild 80 bis 98 und so weiter. Geht jetzt zwar marginal schneller, aber Echtzeit ist das nicht. Da hilft dann nur ein Cache :( .
Das ist natürlich nur eine Theorie, paßt aber zu meinen Beobachtungen beim Rückwärtslaufenlassen: Großer Ruckler, nicht mehr ganz so großer Ruckler, etwas kleinerer Ruckler...... kleiner Ruckler, kein Ruckler, wieder großer Ruckler...

Seltsam ist allerdings, daß ich auch nur auf knapp 22fps komme, aber die CPU Last noch lang nicht bei 100% angekommen ist.

(15min rumprobieren....)

Aha, AVISynth liefert das Video in der vorgegebenen FrameRate von 25Hz. Und mit dem Timer wird man halt gelegentlich mal den Einsatz versäumen (?).
Habe mal eben aus einem bestehenden AVI mittels VirtualDUB 1400 Frames als neues AVI exportiert mit einer Framerate von 50Hz statt 25Hz, und siehe da: Wenn ich in Deinem Programm auf den Timer verzichte und statt dessen im "OnIdle" Event das nächste Bild sauge (also so schnell wie möglich), habe ich plötzlich 100fps (frag mich jetzt bitte keiner, warum nicht 50Hz, ich blick hier nicht mehr durch).
Irgendwie müßte man AVISynth das eigene Timing abgewöhnen können. In der Hilfe hab ich nur ConvertFPS, ChangeFPS und AssumeFPS gefunden, aber das hat nix bewirkt.

Grüße
Michael

[Garfield]

Hallo Michael,

das Ruckeln müsste auf den Dateizugriff zurückzuführen sein. Beim Vorwärtsabspielen wird die Datei von vorn nach hinten gelesen. Beim Rückwärtsspielen muss immer wieder zurückgesprungen und der Anfang des vorigen Frames gesucht werden.

Die Framerate dient normalerweise nur als Information für den Player, in welchem Abstand er die Frames anfordern/abspielen soll. Sonst müsste die Geschindigkeit beim Scrollen mit Cursortasten höher sein, was leider nicht ist.

ConvertFPS und ChangeFPS greifen in die Framefolge ein. Je nach Wert löschen sie Frames oder fügen welche ein. AssumeFPS verändert nur die Geschwindigkeit von Video und passt gleichzeitig die Audiogeschwindigkeit an. Die Änderung der Framerate mit VirtualDub bewirkt beim Video dasselbe wie AssumeFPS.

OnIdle kannte ich bisher nicht. Die Geschwindigkeit ist besonders beim Scrollen mit den Curcortasten Rechts und Links wichtig. Kann man da OnIdle auslösen?

[grizzly]

Mein Eindruck ist, daß AviSynth sich an der Framerate des Videos orientiert, und einfach die Bilder nicht schneller liefert als vorgesehen. Im Normalfall mit 25fps. (Vielleicht wegen Audio-Synchronisierung?)

Mit dem "OnIdle" wollte ich nur sehen, wie schnell es eigentlich gehen können sollte. Quick und dirty hab ich folgenden Routine eingetragen:

Delphi-Quellcode:

procedure Tfrm_Haupt.OnIdle(Sender: TObject; var done: boolean);
begin
 tb_Frame.position := tb_Frame.position+1;
 done := false;
end;

Und dann in Deiner FormCreate folgendes aufgerufen:

Delphi-Quellcode:

Application.onidle := OnIdle;

Wenn man jetzt ein AviSynth-file lädt, dann wird dies sofort abgespielt. Und da hatte ich mich gewundert, daß das bei mir immer noch nur mit 25Hz lief und nicht mit allem was die Kiste her gab. Das habe ich erst erreicht, nachdem ich die Videoframerate im AVI selber hochgedreht habe (VirtualDUB). Deshalb die Vermutung, daß AviSynth selbstständig versucht, die Framerate einzuhalten.

Mit dieser Änderung kam dann das OnIdle Experiment auf gut 100Hz. Scrollen mit den Pfeiltasten kommt allerdings nur auf gut 30Hz, und das hat einen simplen anderen Grund: Die Tastaturwiederholrate!

Das mit dem scrollen muß anders laufen. Vielleicht so: Du mußt den wm_keydown Event für die links/rechts Pfeile (vk_Left, vk_right) abpassen, und dann solange auf Teufel komm raus scrollen, bis der wm_keyup event für diese Tasten kommt. Dann bist Du unabhängig von der Tastatuswiederholrate.

Ohne den Code zu testen, könnte so aussehen:

Delphi-Quellcode:

procedure Tfrm_Haupt.OnIdle(Sender: TObject; var done: boolean);
begin
 IF ScrollDir <> 0 then  // Natürlich noch Grenzen abfangen!
   tb_Frame.position := tb_Frame.position+ScrollDir;
 done := false;
end;

procedure Tfrm_Haupt.AppMessage(var Msg: TMsg; var Handled: boolean);
begin
  if Msg.message = wm_keydown then
    begin
      if Msg.wParam = vk_Left
        then begin
          ScrollDir := -1;
          Handled := true;
        end;
      if Msg.wParam = vk_Right
        then begin
          ScrollDir := +1;
          Handled := true;
        end;
    end;
  if Msg.message = wm_keyup then
    begin
      if Msg.wParam = vk_Left
        then begin
          ScrollDir := 0;
          Handled := true;
        end;
      if Msg.wParam = vk_Right
        then begin
          ScrollDir := 0;
          Handled := true;
        end;
    end;
end;

Und dann in Deiner FormCreate folgendes aufgerufen:

Delphi-Quellcode:

   Application.onidle := OnIdle;
   Application.OnMessage := AppMessage;

Aber natürlich: Das könnte dann sogar zu hektisch werden. Vielleicht doch via TimeGetTime nachsehen, wann der letzte Frame geholt wurde, um damit selbst eine gewisse Geschwindigkeitskontrolle zu haben.

Aber auch: Das ganz funktioniert nur, wenn man AviSynth überreden kann, die Frames ohne Zeitverzögerung herauszugeben.


Gruß
Michael

PS.: Der OnIdle wird automatisch ausgelöst wann immer das System den Eindruck hat, die Software hätte gerade nix zu tun. Das ist also eine gute Stelle, "nichts tun" zu verhindern, aber auch die Maschine nicht zu überfordern...

[Garfield]

Audio ist in diesem Fall nicht dabei. Irgendwie scheint es tatsächlich etwas mit der Framerate zu tun zu haben. Das selbe Video läuft mit 50 fps-Encoding schneller als mit 25 fps-Encoding, obwohl es eigentlich dieselben Frames sind. :?

Die Geschwindigkeit scheint auch vom System abhängig zu sein. Auf meinem Athlon 2400 XP mit Win98SE geht es erheblich flotter vorwärts als auf dem Celeron 2200 mit WinXP. Die Geschwindigkeit bleibt aber egal ob Play, Cursortaste oder OnIdle in etwa gleich. :oops:

Ich habe OnIdle und AppMessage ausprobiert. Es funktioniert sehr gut, aber ich kann nicht feststellen, dass es schneller geht.

Zitat:

Zitat von grizzly

Aber auch: Das ganz funktioniert nur, wenn man AviSynth überreden kann, die Frames ohne Zeitverzögerung herauszugeben.

Das geht am besten, wenn man ohne Umwege an Avisynth herangeht. Wie zum Beispiel bei AVSCompare mit der avswrap.dll, welche allerdings fehlerhaft ist. Die ersten Frames kommen mit einer sehr hohen Framerate.

Ich habe auch schon daran gedacht, einfach Frames zu überspringen. Zum Beispiel, wenn die Taste Shift gedrückt ist, geht es in Zehner Schritten weiter.

[grizzly]

Ich Depp :oops: !

Sorry für die falsche Fährte! Ich hatte tatsächlich geglaubt, ich bekomme mein Test-Video von AviSynth nur in 25fps, und mein in VirtualDUB mit 50Hz FrameRate neu berechnetes viel schneller. Aber nach einer Stunde rumprobieren hab ich endlich gemerkt: Die Ursache waren nur die unterschiedlichen Codecs! Das erste Video hat soviel Zeit zum dekodieren benötigt (DivX), und das neue mit einem alten MPEG4 ging ratz fatz.

Wenn ich meinen oben geposteten Code einfüge kann ich das einfach MPEG4 kodierten Video mit ca. 80fps nach rechts scrollen, im Original DivX kraucht der Rechner mit ca. 22fps dahin (nach links geht natürlich wieder gar nix wegen der leidigen Sucherei (Referenzframe, Differenzframe etc...)

Im Code oben muß natürlich für vk_right ScrollDir := +1; gesetzt werden, werde das gleich mal korrigieren...

Ansonsten ist das mit Deinem Ansatz gleich in 10er Sprüngen durchzulaufen wohl das vielversprechenste, besonders nach "links".

Oder man muß die Methode ändern, wie man die Frames aus dem Video zieht. Denn beim Abspielen schafft der Rechner das Video schließlich auch mit 25fps, samt Ton.

Gruß
Michael

[Garfield]

Das Projekt ist für die Anzeige von Capture- und DV-AVI gedacht. Zum Test verwende ich HuffYUV-komprimierte Analog-Capture. Damit komme ich auf etwa 20-22 fps. Interessanterweise kann ich mit dem oben geposteten Teilprojekt vor und zurück genauso schnell scrollen. Im eigentlichen Projekt ruckelt es denn beim zurückscrollen wieder.

Das mit dem -/+ habe ich schon korrigiert. War etwas irritiert, als nichts ging. :???: Aber die Methode der Eingabeverarbeitung kannte ich noch nicht. :| Im eigentlichen Projekt habe ich die onKey* für zwei Komponenten verwendet.

Natürlich geht es schneller. Bei AVSCompare für Avisynth 2.5* von aquaplaning und theWEF ( http://aquaplaning.20m.com/ ) geht es auch schneller. Aber wie gesagt, es ist fehlerhaft. Das Bild bleibt einfach stehen und wenn man ins Video scrollt, hat man nur ein Standbild. Mit dem DSPack oder direct mit DirectX (siehe MPEG2Schnitt http://www.mdienert.de/mpeg2schnitt/index.htm) geht es auch.

Das DSPack usw ist aber für AviSynth nicht so geeignet. Mit Vfw kann man jedes Frame einzeln anfordern und dann das nächste Script entsprechend schreiben. Dieses arbeitet im Encoder mit 15 fps. Wie schnell es in der Vorschau ist, weiß ich allerdings nicht.

In dem Beitrag http://forum.gleitz.info/showpost.ph...9&postcount=15 gibt es eine DLL in C, welche man eventuell nach Delphi übersetzen könnte. Ich kann nur kein C/C++.

[Garfield]

Das ist nun die Lösung, welche ich gefunden habe.