avisynth.dll: Fehlermeldung auslesen.

[Fr_An]

Als ich mehrere Encoder ausprobierte, war da einer dabei, welcher die Fehlermeldungen von AviSynth als Messagebox ausgab. Weiß vielleicht jemand, wie man diesen Errorcode erhält?

[katjarella]

schau doch mal in den VDub-Code rein. evt. steht da was drin.

[incredible]

http://forum.doom9.org/showthread.php?t=40921

hier die avsynth.h Datei portiert zu Delphi .pas
http://www.koders.com/delphi/fidF901E0AEC29ECBF67266B86173AA1121B5BB4430.aspx

[LigH]

hier die avsynth.h Datei portiert zu Delphi .pas
Da haste dich verguckt...

Das sind die VfW-Header. Die für AviSynth suche ich bis heute vergeblich - hab mich selbst mal versucht, bin aber gescheitert an einer Interface-Deklaration mit variabler Parameteranzahl (so was beherrscht Delphi "eigentlich" nicht).

[incredible]

Stimmt, da habe ich mich vertan ....

Habe es nun als Anhang reingesetzt.

Das müsste jener portierte Header sein, um mit Delphi z.B. Filter zu programmieren.

[Fr_An]

In den VDM-Source hatte ich mal reingesehen, wenn auch aus einem anderen Grund. Ich fand mich auf Grund mangelnder C/C++ Kenntnisse allerdings nicht zurecht. Von der Vfw.pas gibt es etliche unterschiedliche Versionen. Leider bekommt man dort keinen Fehlercode sondern nur eine Graphik, aus welcher man auf Grund der Größe auf eine Fehlermeldung Rückschlüsse ziehen kann.

In meinem Programm muss das Bild eine bestimmte Mindestgröße besitzen, um überhaupt geladen zu werden. Ist das Bild zu klein, wird das Laden abgelehnt. Sonst würde das Bild wie im Anhang aussehen.

Die avsynth.h hatte ich mal mit Dr Bob portiert. Da kam allerdings nichts sinnvolles heraus. Die avisynth_c.pas sieht sehr interessant aus. Da sehe ich die Funktionen:

function avs_clip_get_error(pac: PAVS_Clip): PChar; stdcall; external 'avisynth.dll';
function avs_is_error(v: AVS_Value): Boolean;
function avs_as_error(v: AVS_Value): PChar;
function avs_new_value_error(v0: PChar): AVS_Value;
Mal sehen, was für mich in Frage kommt.

So etwas habe ich schon mehrmals gesucht und nicht gefunden. Die Sourcen von AviSynth habe ich mir deshalb auch schon gezogen...

Nachtrag: Anhang vergessen.

[Fr_An]

Das dürfte der Thread sein: http://forum.doom9.org/showthread.php?p=696784

[incredible]

Das istd er allgeimeine avisynth.h "potierungsthread" hin zu Delphi.

Dein Problem, was die Fehlerausgbe angeht, dürfte aber wie gesagt eher hier zu finden sein:
http://forum.doom9.org/showthread.php?t=40921

Am besten du schreibst "Jonny" mal an. Er ist sehr nett, ich hatte mit ihm mal Exchanges bzgl. der Prediction bei Qcce.

[Fr_An]

Uups. Deinen letzten Beitrag habe ich nicht mehr gelesen; da war ich schon unterwegs.

Den Thread habe ich mir wohl nicht aufmerksam genug angesehen. Das Archiv von Johny ist sehr interessant. Das Script als avsinfo.in in das Verzeichnis von avsinfo.exe, avsinfo.exe ausführen und anschließend hat man eine avsinfo.out mit der Fehlermeldung. Das Übersetzen der Unit erscheint mir nicht möglich, da ich die Funktionen nicht in der Vfw.pas finden konnte.

[Fr_An]

Es gibt eine avswrapp.dll, mit der man einzelne Bilder und Fehler holen kann.
http://aquaplaning.20m.com/

[incredible]

Die kenn ich, wenn du mir jetzt noch sagen kannst, wie man das Ding nutzt ... Hmmm

Habe mal in diese main.pas nachgesehen, aber werde eben aus Delphi nicht recht schlau. Bzw. ich müste eh erst die avswarp.pas in eine Purebasic headerfile portieren.
AvsWarp btw. gibt KEIN audio weiter, nur Video ;)

[Fr_An]

Die kenn ich, wenn du mir jetzt noch sagen kannst, wie man das Ding nutzt ... Hmmm
Für die Fehlermeldung brauchst Du nur die Funktionen AVSSource und GETError. AVSSource gibt einen Integerwert zurück, welcher im Fehlerfall negativ ist. Mit GETError bekommt man dann die Fehlermeldung als String. Dabei ist jedoch der Code für die Zeilenschaltung fehlerhaft. Es wird nur #10 anstelle von #13#10 ausgegeben. Für eine MessageBox ist das zwar ausreichend, für ein Memo usw nicht.

AvsWarp btw. gibt KEIN audio weiter, nur Video ;)Wenn man nur eine Fehlermeldung benötigt, ist das unerheblich ;)

Ausserdem ist die DLL buggy. Die Wiedergabe startet nur von Frame 0 und bleibt irgendwann einfach stehen. Startet man mittendrin, wird nur ein Frame angezeigt.

[incredible]

Die dll. ist ja quasi "nur" ein Wrapper.
Ich hatte den Sinn nie so recht verstanden, da zu dieser ebenso ein nicht gerade kleines header-file ebenso unerlässlich ist (avswarp.pas).
Die Dll gibt keine reine *PointerAdresse für das resultierte Bild im Speicher wieder, sondern jagt diese Farbraum-Nativen Bilddaten eben noch durch einen (aus dem XVID Projekt kommenden) Farbraumwandler "mmx_YV12toRGB()" o.ä..
Für reine Preview Applikationen bräuchte man das nicht.
Man müsste lediglich direkt via API mit der Avisynth.dll oder Avisynth_c.dll kommunizieren und via "envoke" am ende der "Kette" ein ConverttoRGB32() mit dranschmeissen.

Hatte mir mal so einen Workflow via Avisynth durchgesehen.

1. Handle via "AVS_CreatescriptEnvironment()" Erlangen
2. Auf jenes Handle "AVS_Envoke(...)" anwenden
3. Via AVS_GetFrame(...) die resultierenden Bilddaten in einen Speicherbereich holen.
4. Diesen Speicherbereich sodann via GetDIBits(...) in eine Bitmap wandeln
5. Im Programm sodann anzeigen
6. Dies Ganze in einer FPS-Nativen Zeitschleife ablaufen lassen (WinAPI: GetTickCount()).

Das da oben ist aber eine "reine" Vermutung. Wollte dies mal angehen und die dazu benötigten Typen/Declarationen aus avisynth.h zu Purebasic hin portieren.

Nur ... wenn man sich da tagelang die Arbeit macht und nach 2-3 Monaten vieles für die Katz ist, da sodann viell. Avisynth 3.0 raus sein könnte. Müsste man sodann alles wieder umschreiben. Aber ich weiss nicht die Bohne bescheid, was da an Avisynth 3.0 anders sein könnte ;)

[Fr_An]

Hier ging es mir hier nur darum, einen Fehlercode auswerten zu können. Aber die Wiedergabe ist für mich auch ein Thema. Zur Zeit verwende ich VfW. Kika hat hier berichtet, dass VirtualDub eine bessere Wiedergabe hat. Bisher habe ich aber noch nichts gefunden, was für eine Beschleunigung tauglich ist.

[incredible]

In jenem Thread wurde eben der MPC genutzt, welcher ja Dshow zur Wiedergabe nutzt.

Man hat ja (imho) die 3 bekannten Möglichkeiten für eine Wiedergabe zur Auswahl:

1. vfw ... via der AviFil32.dll ---> AvistreamGetFrameOpen()
1a. vfw ... via der MSvfw32.dll ---> ICDecompress()

2. Dshow ... via dem Directshow Interface

3. AcitveMovie ... via der WinMM.dll ---> MciSendstring()

zu 1.: Für mich die wirklich unproblematischste Art Videomaterial wiederzugeben, wie man es von Vdub her kennt. Nur habe ich das mit der AudioStream Wiedergabe noch nicht raus, kommt aber noch ;)

zu2.: Für mich viel zu *tricky* da sich da fix Filter reinmogeln können und unerfahrene User der durch dich erstellten Appliation damit Probleme bekommen könnten. (Was weisst du was die da in der Dshow Kette haben).

zu3.: Ist sehr komfortabel, Audio kein Problem, lässt sich via DeviceHandle auch in einem Videofenster innerhalb der Appl. darstellen.
Nur: Es gibt riesige Probleme wenn ein avs script mit DirectshowSource() geöffnet wird. Denn das geht nur mit MCISendstring(..... Type MPEGVIDEO ...) und da funktionierts sodann nicht mit Frames sondern MS und das "seeken" ist neben anderen Problemen! der reine Horror. Bei Type AVIVIDEO gibt ansonsten keine Probleme, nur können sodann scripte mit DirectshowSource() nicht richtig "terminiert" werden ---> Appl. hängt sich auf. So habe ich das bei Scripten mit mp4 Importen festgestellt.

Es gibt übrigens NOCH ein Avisynth.dll Wrapper (im Anhang).
Dieser liefert auch Audio, ... habe ihn mir aber noch nicht genau unter die Lupe genommen ... mal sehen ;)

[Fr_An]

1. vfw ... via der AviFil32.dll ---> AvistreamGetFrameOpen()
1a. vfw ... via der MSvfw32.dll ---> ICDecompress()
Ich benutze den SDC-Tipp (http://www.swissdelphicenter.ch/de/showcode.php?id=1180) mit der dazu angebotenen vfw.pas unter Verwendung von AVIStreamGetFrameOpen(AVIStream, nil);. Ich musste feststellen, das mindestens vier verschiedene vfw.pas kursieren, ohne dass Versionhinweise enthalten sind. Wenn ich wüsste, wie die Audiowiedergabe funktioniert, hätte ich damit bereits den TMediaPlayer ersetzt.

An Directshow bin ich bisher nicht herangekommen und mit MciSendstring() hatte ich bei SVCDPal2DVD auch schon keinen Erfolg.

Es gibt übrigens NOCH ein Avisynth.dll Wrapper (im Anhang).
Dieser liefert auch Audio, ... habe ihn mir aber noch nicht genau unter die Lupe genommen ... mal sehen ;)
Ich habe wieder ein paar Stunden gesucht, aber wieder nur viele irrelevante Seiten gefunden. Werde ihn mir heute abend mal ansehen.

[incredible]

Audio geht theoretisch so:

1. Via "AvifileGetstream(*pAudiostream,......#StreamtypeAudio)" den Pointer zum Audiostream holen.
2. Via Avistreaminfo(...... &pAudiostream ...., *pWfmt) das Audioformat an eine (WaveformatEX imho) Struktur senden.
3. Aus der WaveformatEX Struktur die SampleLänge etc etc etc etc ermitteln
4. Via AviStreamRead(.....) (imho) die Audiodaten ab Start X (INT64!!) und der Länge Y (INT64!!) an einen *AudioBuffer übergeben.
5. Den *AudioBuffer via DirectSound oder API Inbezugnahme der oben erhaltenen WaveformatEX Struktur abspielen.

Aber .. det iss "noch" alles theeeeeorieeee ;)

Hier noch was aus dem PureBasic Forum bzgl. Audiostream handling bei Avi's:
http://forum.purebasic.com/english/viewtopic.php?p=96705&sid=4abb5106959bdcc6763cdb87d8a582b9


Hier die "Essenz":
pfileWav.IAVIFILE
siWav.AVISTREAMINFO
psWav.IAVISTREAM
psAvi.l
fmtWav.WAVEFORMATEX
If CallFunction( #Lib, "AVIFileOpen",@pfileWav, @strFileWAV, #OF_READ, #Null)=0
If CallFunction( #Lib, "AVIFileGetStream",pfileWav, @psWav, #streamtypeAUDIO, 0)=0
If CallFunction( #Lib, "AVIStreamInfo",psWav, @siWav, SizeOf(AVISTREAMINFO))=0
If CallFunction( #Lib, "AVIStreamReadFormat",psWav, 0, #Null, @lFmtSize) =0
If lFmtSize
If CallFunction( #Lib, "AVIStreamReadFormat",psWav, 0, @fmtWav, @lFmtSize)=0
lStreamLength = CallFunction( #Lib, "AVIStreamLength",psWav)
If lStreamLength
lpbData = AllocateMemory(lStreamLength)
If CallFunction( #Lib, "AVIStreamRead",psWav, 0, lStreamLength, lpbData, lStreamLength, #Null, #Null)=0

Bzgl. variablen mit Strukturen in Purebasic:

"siWav.AVISTREAMINFO"

ist in c++

"AVISTREAMINFO siWav"

in Vb oder Delphi (imho)

"siWav As AVISTREAMINFO"



Wenn ich "PARanoia" als stable release rausgegeben haben werde, werde ich mich mit Niko dort mal in Verbindung setzen, es müsste für ihn ein (imho) Klacks sein, Avis via der AviFil32.dll mit Video UND audio abzuspielen ;)

[Fr_An]

Auf Grund des TMediaPlayers und es DSPacks denke ich mal, dass man in Delphi kaum Sourcen dazu findet ausser natürlich die zum DSPack. Und wenn es um die Audiowiedergabe geht, wird man in der Regel auf die Bass.DLL verwiesen.

[incredible]

Ist das diese Bassmod.dll ? Denn diese kann auch Audio aus einem Buffer ausgeben, also anstatt eines Files.
Ist zwar LGPL aber dennoch wieder mal eine externe dll - müsste somit eingebunden werden und da weiss ich nicht wies mit der Lizenz in Konflikt kommen könnte ... hmmm

Noch was:
Generell macht die direkte Übergabe der Bild- und Audiodaten an das Programm via direktem!! ansprechen der Avisynth.dll weitaus mehr Sinn als der Weg via vfw.
Warum?
Weil es a) viel fixer geht, also der Umweg über erneutes Laden via vfw fällt weg (darum ist Mencoder ohne interne WinAPI calls imho auch merklich! schneller als Qenc obwohl dieser auch auf Libavcodec zugreift)... API kann soooo langsam sein ;) ... nutze z.B. mal WinAPI GetPixel() um den RGB Wert eines Pixels in einer Bitmap zu fischen = GÄHHHN.
Und --- last but not least: Man könnte eine "richtige" AVIsynth GUI bauen, bedeutet jede Änderung an Slidern welche parameter in avs funktionen erneut setzen könnten direkt im Videowindow zu sehen sein.
Somit wäre ein "Levels" tuning on.the.fly möglich. Stell dir mal vor, wenn via vfw und einem Slider-Tick jedes Mal das .avs "neu" gespeichert und "neu" geöffnet werden müsste.
LimitedSharpen könnte somit eine GUI verpasst bekommen und die Hand-Fummelei wäre pasé. Hmmm nun ja, es wäre zumindest wesentlich leckerer zu bedienen.

[Fr_An]

Die BassMOD.DLL ist eine angepasste Version der Bass.DLL - http://www.un4seen.com/bass.html

Wenn ich wüsste wie ich es anstellen muss, würde ich den Umweg über Vfw auch gern weglassen. Bei der Wiedergabe via Timer spielt es ja nicht die Rolle. Aber eben beim Scrollen mit den Cursortasten. Und die von Dir genannten Vorteile sind auch beachtlich.

[incredible]

Dieses "AvsRedirect" Package oben scheint was drin zu haben für GENAU das was du machen willst!

Du brauchst die "avsredirect.dll"
und .... "AvsCheck.exe"

im Code von AvsCheck habe ich folgendes gefunden...
(bin zwar kein c oder c++ Anwender aber ich glaube das isset)

int check_avs(char *errmsg,int errmsglen)
{
...
...
avsdll = LoadLibrary("AVSredirect.dll");
...
...
...
avs_getlasterror = (int __stdcall (*)(char *, int)) GetProcAddress(avsdll, "_avs_getlasterror@8");
...
...
...
}


int main(int argc, char *argv[])
{
char errmsg[1024];
int r = check_avs(errmsg,1024);
if (r == 0) printf("T>%s\n",errmsg);

return r;
}



Somit gibt avs_getlasterror(errmsg,errmsglen) die Fehler-Textausgabe unten an einen Stringbuffer errmsg[1024] weiter, diesen Buffer kannst du sodann in deiner Delphi Applikation rein holen und als string darstellen :cheers: ....... denke ich mir zumindest :grübeln:

[Fr_An]

Mit der avswrap.dll klappt die Fehlerausgabe ja ganz gut, aber die avsredirect.dll ist nur halb so groß und es gibt da noch die Funktionen

int __stdcall (* avs_getvframe)(void *avs, int clip_num, int frm, void *vf);
int __stdcall (* avs_getaframe)(void *avs, int clip_num, void *buf, void *pos);

Muss ich mir nachher mal ansehen.

[incredible]

Genau.

Und vor allem ... es scheint mir als ob jene avsdirect.h wesentlich leichter in eine andere Programmierumgebung zu portieren ist als eine gesamte avisynth.h bzw. avswarp.pas. Klar, hier gehts sodann nur um Bitmap, bzw. Audio weitergabe, nicht um z.B. eigene Filter zu erstellen.

Das gesamte AvsDirect Project scheint komplett GPL zu sein, also auch die Dll Nutzung, ist aber egal, wenn man das Ding mal zum Laufen gebracht hat, ists für andere bestimmt auch interessant in neuen Sourcen nachzusehen.

Für mich ist rein der Verständnis halber die AvsRedirect.dll nutzung wesentlich interessanter, liegt wohl daran, dass ich eben kein Delphi nutze. Aber mal abwarten, noch habe ich sie ja nicht ausprobiert ;)

Habe aber gerade gesehen, dass Scriptbefehle hier auch via Envoke-->"Import()" geholt werden, also müsste man für jenen GUI-Gedanke auch hier wieder immer zu temporäre avs's auf HD vorab erstellen *grr

[Fr_An]

int __stdcall (* avs_open)(void *,char *,void *);
int __stdcall (* avs_getvframe)(void *avs, int clip_num, int frm, void *vf);
int __stdcall (* avs_getaframe)(void *avs, int clip_num, void *buf, void *pos);
int __stdcall (* avs_close)(void *avs, int clip_num);
int __stdcall (* avs_getlasterror)(char *str,int len);
Irgendwie verstehe ich den Sinn der vielen void nicht.

[LigH]

"void *" ist ein typloser Pointer, wenn ich mich recht erinnere - aber ohne Gewähr. Sieht irgendwie etwas unvollständig aus?!

[incredible]

void function(x) = Ohne Resultat, bzw. es wird keines aus der Funktion übergeben
bool function(x) = Resultat ergibt true or false
float function(x) = Resultat ergibt eine Fließkommazahl
int function(x) = Resultat ergibt eine Ganzzahl
(die letzten 3 kennt man ja)

Sieht irgendwie etwas unvollständig aus?!
Der komplette Code ist oben im AvsRedirect Package.

[LigH]

^ Da ging es nicht um Rückgabewerte der Funktionen (die sind dort immer "int", und Strukturen auf dem Stack), sondern um Datentypen zu übergebender Parameter (in die Funktion hinein).

[Kopernikus]

int __stdcall (* avs_open)(void *,char *,void *);
int __stdcall (* avs_getvframe)(void *avs, int clip_num, int frm, void *vf);
int __stdcall (* avs_getaframe)(void *avs, int clip_num, void *buf, void *pos);
int __stdcall (* avs_close)(void *avs, int clip_num);
int __stdcall (* avs_getlasterror)(char *str,int len);
Irgendwie verstehe ich den Sinn der vielen void nicht.

hmmm, auf den ersten Blick sieht das aus, als ob da Pointer auf Funktionenzeiger verwendet werden. int ist der Rückgabewert, __stdcall ist die Aufrufskonvention. Dann wird die Funktion, auf die avs_getvframe/... zeigt mit den Parametern in der letzten Klammer in jeder Zeile gefüttert.

[LigH]

Ich schau mal, ob man das in Delphi ausdrücken kann, aber ich bin noch nicht so sicher, ob ich das richtig verstehe:

type
TAvs_Open = function(_1: Pointer; _2: PChar; _3: Pointer): Integer; stdcall;
{ oder:
TAvs_Open = function(var _1; _2: PChar; var _3): Integer; stdcall;
}
TAvs_Close = function(avs: Pointer; clip_num: Integer): Integer; stdcall;

var
Avs_Open: TAvs_Open;
Avs_Close: TAvs_Close;
Funktionale Variablen sind ja notwendig, wenn deren Adresse aus einer DLL beim dynamischen Laden übergeben werden muss.

"Pointer" (oder "typloser var-Parameter") ist nur eben ein ziemlicher "Hilfs-Datentyp". Besser wäre schon, wenn man was konkretes hat, dann kann man da statt dessen auch "var _1: TRecordType;" verwenden (das "var" ist dort extrem wichtig!).

[Fr_An]

Im Source der avsredirect.dll steht folgendes:

__declspec(dllexport) void * __stdcall avs_create();
__declspec(dllexport) int __stdcall avs_open(void *avs, char *fname, AVSDLLVideoInfo *vi);
__declspec(dllexport) int __stdcall avs_getvframe(void *avs, int clip_num, int frm, AVSDLLVideoFrame *vf);
__declspec(dllexport) int __stdcall avs_getaframe(void *avs, int clip_num, void *buf, AVSDLLAudioPos *pos);
__declspec(dllexport) int __stdcall avs_close(void *avs, int clip_num);
__declspec(dllexport) int __stdcall avs_getlasterror(char *str,int len);


Anscheinend bekommt man mit Create den Pointer, mit welchem man dann weiterarbeiten muss.

Vielleicht sollte man aber gleich mit der Source der DLL arbeiten?

[incredible]

Habe mir die Source mal angesehen.
WENN es lediglich darum geht, die Fehlermeldung zu bekommen und avisynth.dll DIREKT mit einem fertigen Skript auf HD liegend zu füttern ---> Wunderbar.
AvsRedirect nutzt als Scriptparsing aber lediglich als Invoke "Import()", somit kann man die AvsRedirect.dll nicht mit übergabe von individuellen Funktionsaufrufen DIREKT füttern, so wie is bei der AvsWarp.dll möglich ist.

Was eine Ideale Lösung ist, wäre ein Wrapper, der genauso funktioniert wie die AvsRedirect.dll .... JEDOCH zusätzlich mit einer Option, dass neben dem internen Invoke -- > Import() Befehl auch ein Invoke ---> *String exisitert.
Bedeutet es wird ein *Zeiger angegeben an dem ein Null-Terminated String vorliegt, an diesem Zeiger liegt GENAU der gleichen Text, wie der, der in einem auf HD existierenden Text als avs script vorliegen würde, der eben momentan via Invoke ---> Import() eingeholt wird.

Kann jemand so gut C, dass man dies implementieren könnte?
Also neben Envoke ---> Import ... ein Envoke ---> Char *Str

In der Applikation würde sodann als String ein Script erstellt, sodann die Speicheradresse des Strings an die dll übergeben ... Voilá.

Somit hätte man einen Wrapper, der von einem auf HD existierenden avs vollkommen unabhängig ist.


Der momentane AVS_Open() Befehl aus der AvsRedirect Source:
int __stdcall avs_open(void *avs, char *fname, AVSDLLVideoInfo *vi)
{
IScriptEnvironment* env = (IScriptEnvironment*)avs;
int clip_num;
int i;

try {
AVSValue arg(fname);
AVSValue res = env->Invoke("Import", AVSValue(&arg, 1));
if (!res.IsClip()) {
strncpy(g_lasterr,"The script's return was not a video clip.",ERRMSG_LEN-1);
return -1;
}

clip_num = -1;
for(i=0;i<MAX_CLIPS;i++) {
if (g_clip_flg[i] == 0) {
clip_num = i;
g_clip_flg[i] = 1;
break;
}
}
if (clip_num == -1) {
strncpy(g_lasterr,"Too many open clips",ERRMSG_LEN-1);
return -1;
}

clip[clip_num] = res.AsClip();
VideoInfo inf = clip[clip_num]->GetVideoInfo();

if (inf.HasVideo()) {
if(!inf.IsYV12()) {
res = env->Invoke("ConvertToYV12", AVSValue(&res, 1));
clip[clip_num] = res.AsClip();
inf = clip[clip_num]->GetVideoInfo();
}
if(!inf.IsYV12()) {
strncpy(g_lasterr,"Cannot convert video to YUV2",ERRMSG_LEN-1);
return -1;
}
if(inf.IsFieldBased()) {
strncpy(g_lasterr,"Sorry interlaced clip not supoorted",ERRMSG_LEN-1);
return -1;
}
}

if (inf.HasAudio()) {
if(inf.SampleType() != SAMPLE_INT16) {
res = env->Invoke("ConvertAudioTo16bit", res);
clip[clip_num] = res.AsClip();
inf = clip[clip_num]->GetVideoInfo();
if(inf.SampleType() != SAMPLE_INT16) {
strncpy(g_lasterr,"Cannot convert audio to 16bit",ERRMSG_LEN-1);
return -1;
}
}
}

if (vi != NULL) {
vi->width = inf.width;
vi->height = inf.height;
vi->raten = inf.fps_numerator;
vi->rated = inf.fps_denominator;
vi->aspectn = 0;
vi->aspectd = 1;
vi->interlaced_frame = 0; // progressive
vi->top_field_first = 0;
vi->num_frames = inf.num_frames;

vi->audio_samples_per_second = inf.SamplesPerSecond();
vi->num_audio_samples = inf.num_audio_samples;
vi->sample_type = inf.SampleType();
vi->nchannels = inf.AudioChannels();
}

g_lasterr[0] = 0;
return clip_num;
} catch(AvisynthError err) {
strncpy(g_lasterr,err.msg,ERRMSG_LEN-1);
return -1;
}
}
Die Deklaration des Invoke() Befehls aus der Avisynth_c dll als Beispiel:
AVSValue __stdcall Invoke(const char* name, const AVSValue args, const char** arg_names=0);

[Fr_An]

Ausserdem ist die DLL buggy. Die Wiedergabe startet nur von Frame 0 und bleibt irgendwann einfach stehen. Startet man mittendrin, wird nur ein Frame angezeigt.
Für das Stehenbleiben könnte ein EStackOverflow veranwortet sein, wie ich bei meinem Projekt feststellen musste.

[incredible]

Hier was leckeres für dich Fr_An:

http://forum.doom9.org/showthread.php?p=772600#post772600

[Fr_An]

Werde ich mir ansehen. Danke.

[Fr_An]

http://forum.doom9.org/showthread.php?p=780834#post780834

Das ist in etwa das, was ich wollte.

[Fr_An]

Das ist jetzt ein Testprogramm.

Nachtrag: Anhang gelöscht. Aktuelle Version am Ende.

[LigH]

Egal welche AVS-Datei ich versuche damit zu öffnen, das Programm meldet immer

---------------------------
AviSynth Error
---------------------------
Die Datei scheint keine Textdatei zu sein.
---------------------------
OK
---------------------------

[Garf]

Dann scheint in dem Script ein Zeichen enthalten zu sein, welches nach Fr_An's Meinung nicht in einer Textdatei enthalten sein dürfte.

[incredible]

Nö, bei mir auch .... jedes mal der von Ligh genannte Fehler

[incredible]

Für das Stehenbleiben könnte ein EStackOverflow veranwortet sein, wie ich bei meinem Projekt feststellen musste.
bzgl. der AvsWarp Dll kann das daran liegen, das der falsche "pitch" übergeben wurde. Versuche mal RGB32 ist also DWORD aligned, ansonsten nur mit "even" oder gar Mod4 Zahlen im Script resizen und croppen.

Habe die AvsWarp.dll mal für Testzwecke umgeschrieben/gefixed. Das Problem war vor allem, das als Pointer zum RGB Frame ein "Smart-Pointer" via der dll übertragen wurde! Und dieser ist sehr unbeständig.

[Garf]

Da Fr_An sich wohl ausgesperrt hat (:ani_lol:), übernehme ich mal die Antwort:
function Textdatei (const Datei : String) : Boolean;
const
Testlaenge = 100;
var
i : Integer;
aktByte : Byte;
z : file of byte;
begin
Result := True;

FileMode := 0; { Datei wird mit Schreibschutz geöffnet }
AssignFile (z, Datei);
Reset (z);

while (Not(EOF(z))
and (Result)
and (FilePos(z) <= Testlaenge))
do begin
Read(z, aktByte);

case aktByte of
0.. 9 : Result := False;
11.. 12 : Result := False;
14.. 31 : Result := False;
60 : Result := False;
62 : Result := False;
76 : Result := False;
91.. 93 : Result := False;
123..127 : Result := False;
129..166 : Result := False;
168..175 : Result := False;
177..179 : Result := False;
181..195 : Result := False;
197..213 : Result := False;
215..219 : Result := False;
221..222 : Result := False;
224..227 : Result := False;
229..245 : Result := False;
247..251 : Result := False;
253..255 : Result := False;
end;

Application.ProcessMessages;
end;

CloseFile(z);
end;

[incredible]

Und wie erschließt sich daraus das Problem?

[Garf]

ASCII?

Das Zeichen bekommt man mit CHR(aktByte).

Die Datei wird byteweise gelesen. Fr_An hat eine Textdatei mit allen Zeichen, welche nach seiner Meinung in einem Script vorhanden sein können, erstellt. Beim Test hat er dann die Werte aus einer Liste gestrichen und den Rest in die Unit geschrieben.

Nachtrag:

Er hat zum Beispiel die ~ vergessen.

Nachtrag: Anhang gelöscht. Aktuelle Version am Ende.

[LigH]

Ach so, du hast Fr_An's Quelltext analysiert - sag das doch!

Ja, es ist zu vermuten, dass das Programm wohl die Skriptdateien analysiert hat, und beim Auftreten von Zeichen, die sonst nicht in Skripten und Verzeichnis+Dateinamen auftauchen sollten, mal ganz pessimistissch vermutet, dass das gar kein AviSynth-Skript ist (sondern z.B. ein WinAmp-Visualisierungs-Preset).

So viele verschiedene Zeichen hätte Frank da aber nicht ausschließen sollen.

Garf: Deine Version ändert bei mir übrigens nichts gegenüber der von Fr_An, und bringt ebenfalls eine Zugriffsverletzung beim laden der mitgelieferten "Version.avs"!

[Garf]

Ach so, du hast Fr_An's Quelltext analysiert - sag das doch!
Nein, dass macht er schon selbst.

[Fr_An]

So, jetzt kann ich wieder selbst übernehmen.

Habe mal alle Zeichen bis 127 aus der Überprüfung herausgenommen und wenn ein Fehler auftritt, kann man trotzdem laden. Wenn im Script kein Source oder Import angegeben ist, gibt es auch eine Warnung.

Nachtrag: Anhang gelöscht. Aktuelle Version am Ende.

[LigH]

Beim Öffnen der mitgelieferten "Version.avs", und der "TransOverTest.avs" im Anhang:

---------------------------
AviSynth Error
---------------------------
Zugriffsverletzung bei Adresse 0047A66A in Modul 'AVSError.exe'. Lesen von Adresse 00000000.
---------------------------
OK
---------------------------


Außerdem hat mein Windows 2000 leichte Darstellungsprobleme, weil du hier wohl Unicode aktiviert hast, wo es nicht nötig ist; anstatt "Länge" lese ich also "L[]ge".
__

^ Danke für die Quelltexte - Zugriffsverletzung gefunden: In einer leeren Zeile darf man nicht fragen, ob das erste Zeichen ... da ist nämlich keins.

[katjarella]

Version1: geht net.

Version2: Zugriffsverletzung bei Adresse 0047A66A in Modul 'AVSError.exe'. Lesen von Adresse 00000000.

[Fr_An]

Unicode? :hm:

WinXP SP2 und Delphi 7 Personal.

Scheint dann doch was betriebssystemabhängiges zu sein.

Bei der Schrift könnte es an der Schriftart liegen. Ich habe Courier New eingestellt. Allerdings wird das Vorhandensein nicht geprüft.

[Fr_An]

Den Fehler mit der Schutzverletzung hat LigH gefunden. Es lag daran, dass ich nicht berücksichtigt habe, dass es auch Leerzeilen gibt.

Das mit der Schrift klären wir noch.

Nachtrag: Anhang gelöscht. Aktuelle Version am Ende.

[LigH]

Und die Unicode-Zeichen lagen daran, dass das ganze Formular versehentlich auf "japanische Zeichentabelle" (Shift-JIS) verstellt wurde.

[Fr_An]

Dann hänge ich jetzt mal die aktuelle Version ran und lösche vorne alle anderen.

Die japanischen Schriftzeichen könnten von einem Unicode-Test übriggeblieben sein. Kommt davon, wenn man eine Vorlage weiterverwendet.

Hauptsache es klappt jetzt. Danke LigH.

Nachtrag: Anhang gelöscht. Aktuelle Version unten.

[katjarella]

Das mit der Schrift klären wir noch.
wegen : Höhe // Länge ???

Und warum bekomm ich immer noch den Fehler, das es kein AVS ist?


EDIT: Bild2 ist jetzt das aktuelle. ist aber immer noch was fremdes drin.

[Fr_An]

wegen : Höhe // Länge ???
Der Kauderwelsch im rechten Memo ist von Avisynth. Den werde ich jetzt mal weg lassen.

Und warum bekomm ich immer noch den Fehler, das es kein AVS ist?
Das ist eine Warnung, weil kein Source oder Import gefunden wurde.

EDIT: Bild2 ist jetzt das aktuelle. ist aber immer noch was fremdes drin.
Du meinst im Memo?

[Fr_An]

Der Kauderwelsch mit den Kästchen waren keine Fehlermeldungen, sondern Pointer. Die Auswertung war fehlerhaft.

In der anhängenden Version sind die bekannten Fehler beseitigt.

Nachtrag: Anhang gelöscht. Aktuelle Version unten.

[LigH]

So sieht's eigentlich ganz in Ordnung aus; es werden nur immer noch Skripte als "keine Scriptdatei" gemeldet, Obwohl sie ein "...source" enthalten, weil ich "...Script" mit großem "S" geschrieben habe; abgesehen davon halte ich diesen Test generell nicht für besonders nützlich, AviSynth wird das besser entscheiden können (Ergebnistyp = 'c' = Clip: Ist ein Skript).

Ein "Skriptlet" bzw. Include, in welchem z.B. nur Konstanten und Funktionen deklariert werden (gern auch *.avsi benannt), sollte als Ergebnis keinen Clip liefern, sondern was anderes.

[Fr_An]

Es ist schon eigenartig. Das Script wird in eine Stringlist geladen und soll dann ausgewertet werden. Wird es aber anscheinend nicht. Weise ich die einzelnen Strings einer anderen Variablen zu, dann funktioniert es.

Muss mal sehen, wie ich die Funktionen der avisynth_c.pas am besten bei der Prüfung einsetzen kann.

[Amnon82]

Schön zu sehen das noch welche mit Delphi coden ;)
Könnte ich Deinen Code einsehen? Ich würd Dir auch meinen von AutoQ2 zur Einsicht linken.

cya Amnon

[incredible]

Bitte solche Deals wie "Wenn du mir, dann ich dir" via PM abhandeln.
Wenn es öffentlich geschehen soll, dann biete deine Source auch der Öffentlichkeit an.

[Fr_An]

Könnte ich Deinen Code einsehen? Ich würd Dir auch meinen von AutoQ2 zur Einsicht linken.
Beta-Versionen gebe ich grundsätzlich nicht raus. Hier hatte ich ausnahmsweise LigH um Hilfe gebeten, da er über erheblich mehr Erfahrung und mit Sicherheit eine bessere Ausbildung in Bezug auf Programmierung verfügt. An dieser Stelle noch einmal mein Dank an LigH.

Im Prinzip sind die zu Grunde liegenden Sourcen alle öffentlich zugänglich.

Anzeige per Vfw:
http://www.swissdelphicenter.ch/de/showcode.php?id=1180
http://www.delphipraxis.net/topic66869.html

Anzeige per Avisynth:
http://forum.doom9.org/showthread.php?p=695756#post695756
http://yatta.mellbin.org/misc/avisynth_pascal_v4.rar

Parsen des AVS:
http://yatta.mellbin.org/misc/old/avisynth_pascal_v3.zip

Der Ablauf ist prinzipiell so:

Öffnen-Dialog.
Überprüfen, ob die Datei eine Textdatei ist. Siehe hier (http://forum.gleitz.info/showpost.php?p=257864&postcount=41), nur die Zeilen mit den Zeichen bis 127 entfernen.
Links die Anzeige entsprechend dem Projekt aus der Delphi-Praxis.
Einlesen des AVS. Suchen nach 'Import' und 'Source'. Bei Source Quelle entsprechend avisynth_pascal_v3 prüfen.
Anzeige in modifizierter Form entsprechend avisynth_pascal_v4. Dabei wird das AVS erst importiert und der vtype ausgewertet.
Eventuell AVISource verwenden.
Farbbereich auswerten und ggfs ConvertToRGB ausführen.

Aktuelle Version ist im Anhang. Ich überlege, ob ich das Parsen noch ausbaue.