AVIStreamOpenFromFile



  • Hi,

    seit Ionen verwende ich VFW(VideoForWindows) Das interface ist extrem stabil läuft bisweilen immer unter allen Systemen, doch unter 64 Bit Kompilate stürzt die Methode: AVIStreamOpenFromFile ab, man muss allerdings dazu auch das FFDSHOW mit seinen decompressoren installieren, früher genannt sog. CodecPacks . Tatsächlich gibt es das auch für 64 Bit insbesondere FFDSHOW .

    Quelle : https://www.heise.de/download/product/ffdshow-tryouts-14678

    Leider stürzt die Methode AVIStreamOpenFromFile damit sofort ab wenn es versucht ein normales AVI zu laden.
    (Deinstalliert man das FFDSHOW ist auch der Absturz weg).

    Kennt jemand einen CodecPack das damit funktioniert, bzw. gibt es ein neues Interface das dies nun leistet ? Z.b. ohne das man Packs installen müsse ?

    Danke für Hinweise
    Karsten



  • Ich nehme alles zurück.



  • Hallo Sword,

    was nimmst Du zurück ? Ich sehe nur das Du alles zurück nimmst 🙂
    Bist Du böse ?



  • @KahnSoft Ich habe geschrieben daß das bei Heise eine Uraltversion ist. Als ich genauer geschaut habe ist mir dann aber aufgefallen daß es auf Sourceforge auch keine neueren Binaries gibt.



  • @Swordfish Ja und die 64 Bit Version stürzt ab beim erzeugen des geladenen avi's.
    Muss ich alles nochmal checken.. übel..



  • @KahnSoft sagte in AVIStreamOpenFromFile:

    Muss ich alles nochmal checken.. übel..

    Ich würd' das erstmal in GraphEdit zusammenbasteln.



  • Kann man niemanden zumuten, gibt es ein alternatives conform interface ?



  • @KahnSoft sagte in AVIStreamOpenFromFile:

    niemanden

    DU sollst; um herauszufinden ob es an Deinem Code liegt oder am Codec.



  • Eine Alternative zu FFDSHOW ist LAV: https://github.com/Nevcairiel/LAVFilters/releases
    Weiss nicht ob das noch aktuell ist -- hab schon ewig kein Codec Pack mehr installiert. (Ich verwende eigentlich keine DirectShow basierten Player mehr, der Player meiner Wahl hat alles was ich brauche selbst mit drin.)



  • Hallo,

    ja vielen Dank für diesen Hinweis, aber VFW Unterstützt der Treiber scheinbar nicht.
    Dann werde ich mal sehen was noch so möglich ist.

    Vielen Dank der Hinweise
    K.



  • @KahnSoft sagte in AVIStreamOpenFromFile:

    Kann man niemanden zumuten, gibt es ein alternatives conform interface ?

    Ich verstehe nicht was du mit "conform interface" meinst.
    GraphEdit ist ein Entwicklertool und halt "das" Entwicklertool da es das erste war. Gibt ne OpenSource-Variante, GraphStudio, aber das orientiert sich vom Interface her halt an "dem" Standard, also an GraphEdit. Bzw. aktuell wohl https://github.com/cplussharp/graph-studio-next -- welches ich aber nicht kenne, d.h. ich kann nur vermuten dass es auch ähnlich wie GraphStudio ist.



  • Achja, sorry, VFW hattest du ja geschrieben. Wobei es mich gerade etwas wundert dass FFDShow das unterstützt.
    Um welchen Codec geht es denn speziell? Oder brauchst du viele?

    Und: hast du schon probiert diverse Codecs bei FFDShow zu deaktivieren bzw. Compatibility-Optionen zu ändern?



  • @hustbaer Unter 32Bit läuft das, explizit muss der Windows user aber einen codec installiert haben um gewöhnliche *avis *mpg4 zu dekodieren. streamtypeVIDEO

    #define streamtypeVIDEO mmioFOURCC('v', 'i', 'd', 's')
    #define streamtypeAUDIO mmioFOURCC('a', 'u', 'd', 's')
    #define streamtypeMIDI mmioFOURCC('m', 'i', 'd', 's')
    #define streamtypeTEXT mmioFOURCC('t', 'x', 't', 's')

    Die Zieldatei konnte also immer erfolgrecih mit :
    AVIStreamOpenFromFile(&m_pavi, fname.GetBuffer(0), streamtypeVIDEO, 0, OF_READ, NULL)
    ausgeköst werden.

    Der erste danach folgende Aufruf mit dem gültigen Zeiger von m_pavi :
    PAVISTREAM m_pavi; // Handle To An Open Stream
    Scheint erfolgreich initiiert zu sein.

    Der erste Anruf via : AVIStreamGetFrameOpen landet in einer unbehandelten Ausnahme , ich habe noch keine weiteren Untersuchungen veranstaltet.

    Ms hat ein neueres Interface hervorgebracht das DirectShow ablösen solle, es lautet WIA oder so ähnlich, das Interface ist aber eine Katastrophe ich sehe nicht das sich dieser quadawelch durchsetzen wird, weswegen
    twain dxShow noch brand aktuell bleiben wird.

    Aber andere Videoprogramme bringen also immer ihr codec pack selber mit um überhaupt mitspielen zu können das ist der fall, ohne diese externen decoder gibt es auch kein video.

    Allerdings haben alle Grafikkarten Hardware encoder bereits implementiert und über fpga's hartverdrahtet inne, und die haben eigentlich auch die Liezens gebühren bezahlt, das gilt auch für voice encoder. Auch die Blitter Funktionen die Dib sectionen sind durch Hardware über die HAL(HardwareAbstraktionsLayer) den Systemfunktionen überlagernd. JEde installation von codecs verursacht eigentlich immer wieder die Zurückführung der Hardwarefunktionen hin zu software Decodern die massig cpu verzehren.

    Nun sollte über diese Codeschlüssel 'v', 'i', 'd', 's' der entsprechende Decoder selektiert werden.

    Was kann denn Windows eigentlich system conform abspielen nach der neu Installation ? Das gibt immer andere Ergebnisse ob man nun den Mediaplayer oder den must have MovieMaker verwendet. Und für AVIStreamGetFrameOpen sieht es ohne fremde Daten Verdreher schlecht aus. Für mich weiterhin unverstandene Kunde.

    Danke für deine Hinweise, keiner der Kunden wird von sich aus anfangen mit GraphEdit.exe zu wirken, den kenne ich mit dem Program AmCap.exe sehr gut, da ich ja via directshow und twain video sourcen (cameras) integriere.

    Es bleibt also ungewiss ob ein Video spielbar ist oder nicht.

    Grüße aus Preußen
    K.



  • Ob es jetzt ein Codec-Problem ist oder nicht, weiß ich nicht, die grundsätzliche Problematik damit kenne ich aber auch. Dass Codecs eben nur für bestimmte Konfigurationen zur Verfügung stehen, dass es Probleme beim Abspielen auf anderen Geräten geben kann usw.
    Vielleicht wäre ja wmv eine Lösung. Das hat eigentlich alles, was man braucht. Frei wählbar zwischen guter Qualität und guter Kompression, variable Bitrate optional, „beliebige” Auflösungen und vor allem - es klappt immer.
    Der einzige Nachteil gegenüber dem AVI-Interface ist eigentlich nur, dass es aufwändiger ist, sich einen Stream zu erstellen und diesen zu konfigurieren.



  • @yahendrik Du sagst es, ich habe habe frühueitig auf das einfache VFW gesetzt es ist auch noch voll im Trend und weit im Einsatz, hat aber die Abhängigkeit fremder Codecs die von externen firmen bereitgestellt und auch teilweise lizensiert sind. Eigentlich sollte HAL nun die NV Decoder von der Hardware nutzen , macht das aber scheinbar nicht ohne fremdinstallation, zb das K-Codec Pack stürzt wenigstens nicht ab alle direkten VFW32 Codecs crashen auf der 64 Bit version über VFW die VFW32.DLL liegt gleichnamig natürlich auch in der 64Bit Version Windowsseitig vor. Seit W7 gibt es Probleme. Es liegt also hier nach der Prüfung am Codec der code läuft auf 32Bit und 64Bit gleichermaßen überall gut viele Millionen Anweisungen laufen fehlerlos.

    Ich werde alles auf DirectShow umrüsten was capture und play betrifft video capturing habe ich längst in DShow aber auch das Interface ist eine bedrohte Lebensform.

    Man hat schwer bedienbare Mdiainterface auf COM basis hervorgebracht, ohne separates Studium über Monate hinweg bleibt der quadawelch schwer erziehbar.

    Danke für deinen Hinweis,
    DXShow ist also das Fazit auch für record und play nicht nur für usb-web-stuff
    Oder IMFP.. - https://docs.microsoft.com/en-us/windows/win32/medfound/mfplay-tutorial--video-playback
    Grüße aus Preußen
    K.


Log in to reply