Beiträge von LessThanJake

    Ich dreh langsam durch, ich bekomme es einfach nicht gebacken die Funktionen überhaupt anzusprechen. Nichtmal eine simple Zuweisung will funktionieren :(.

    Hier mal der Versuch eines Testcases um eine AVS Scriptumgebung zu erstellen und einer simplen Abfrage ob eine Filterfunktion vorhanden ist.
    Ich beziehe mich dabei auf die C-Funktionen aus dieser API-Doku (die natürlich auch mit denen in der avisynt_c.h identisch sind).

    PHP
    #include <iostream>#include <avisynth_c.h>using namespace std;int main() {// Einen Pointer auf eine AVS Scriptumgebung anlegen --> kompiliert (Der Wahnsinn)AVS_ScriptEnvironment *scriptumgebung;// Funktion um eine Scriptumgebung zu erstellen:// AVS_ScriptEnvironment * avs_create_script_environment(int version);// Umgebung auf den Pointer legen (schon ein Compiler Error)scriptumgebung = avs_create_script_environment(AVISYNTH_INTERFACE_VERSION);// Funktion um das Vorhandensein einer AVISynth-Funktion abzurufen (glaube ich zumindest):// int avs_function_exists(AVS_ScriptEnvironment *, const char * name)// In diesem Falle als Beispiel "mpeg2source()".if (avs_function_exists(scriptumgebung, "mpeg2source"))cout << "mpeg2source da";cout << "mpeg2source nicht da";return 0;}

    Die Zuweisung der Umgebung auf die variable quittiert der Compiler schon mit

    Code
    main.cpp|14|undefined reference to __imp__avs_create_script_environment@4'|

    Das deutet normalerweise immer auf eine fehlende Bibliothek hin.
    Ich hab die avisynth.dll auch garnicht eingebunden, weil ich der Meinung bin, das die durch die avisynth_c.h schon integriert ist.
    Muß ich die dll etwa doch zusätzlich nochmal laden?
    Wenn ja, warum klappt dann das Anlegen der pointer-Variablen?

    Was läuft denn da nun schon schief? :huh:

    greets
    LTJ

    Ja, das ist so in etwa das was ich gesucht habe.

    Hab hier noch eine API-Referenz für AVISynth C mit kleinem Beispiel gefunden.
    http://kevin.atkinson.dhs.org/avisynth_c/api.html
    Das ist auf jeden Fall für den Einstieg noch ne Ecke einfacher. Leider sind die meisten Funktionen schon wieder nur aufgelistet und nicht richtig erklärt.
    Ehrlichgesagt finde ich es auch nicht gerade clever von den AVISynth-Entwicklern die API so schlampig zu erläutern, wenn sie doch so sehr nach Programmierern von Filterplugins lechzen. Generell würde jeder Programmierer, wenn die Möglichkeit besteht, einer gut dokumentierten Bibliothek den Vorrang geben, anstatt tagelang durch try&error zum Ziel zu kommen.
    Gleiches Spiel mit ffmpeg. Schade eigentlich.

    greets
    LTJ

    Irgendwie wollen die builds trotz mehrfacher Neuinstallation nicht laufen.

    Mir ist aufgefallen das msys nach der Postinstallprozedur erzählt ich hätte keine make.exe, aber das kann ja schlecht sein, sonst würde der Kompiliervorgang ja garnicht starten.
    Muß ich evtl. eine mingw-32-make zu make umbenennen und verschieben?

    Oder liegts vielleicht doch an der Compiler-Version?
    Folgendes hab ich installiert:
    yasm -> 0.7.1.2093
    gcc -> 4.3.2

    greets
    LTJ

    EDIT//
    Es lag tatsächlich an der Compilerversion. 4.3.2-tdm geht nicht! Mit der älteren 4.2.4-tdm hat es geklappt, da verschwinden dann auch fast alle warnings.
    Allerdings sehe ich außer der Angabe "x264 Core 64" keine weiteren Infos über eine Revision.
    Wo ist die hin?

    Alles klar, aber erst wieder "heute" Abend, muß früh raus.
    Danke soweit :).

    Zitat

    BTW: Wie hast du GIT in deinen Path eingefügt ???


    Hab ich doch garnicht.
    Wenn ich GIT starte hab ich ein eigenes Bash-Fenster, wäre aber schön wenn das dann auch direkt im msys-bash laufen würde.

    greets
    LTJ

    Version 1.0.2 changes:

    * Fixed decode failure when no PPS 0 exists.

    * Improved robustness of transport parsing.

    http://neuron2.net/dgavcdec/dgavcdec.html

    ---------------------------

    neuron2 hat sich aber wahrschinlich beim changelog vertan.

    Der Fix müßte anstelle von
    * Fixed decode failure when no PPS 0 exists.

    eher
    * Fixed decode failure when RAW-bytestream begins with SPS>0
    lauten

    siehe hier:
    http://forum.doom9.org/showthread.php?p=1189380#post1189380
    Das zweite sample hatte ich versehentlich fehlerhaft erstellt und die Fehlermeldung "non existing PPS referenced" erschien und erscheint berechtigt.

    greets
    LTJ

    Was "make install" tun soll, weiss ich nicht.

    C:\msys\1.0\share\autoconf\install

    Zitat von INSTALL


    4. Type `make install' to install the programs and any data files and
    documentation.

    Die Kompilierten Dateien werden dann in den Ordnern
    /usr/local/bin
    /usr/local/lib
    /usr/local/include
    abgelegt.

    Aber dass er die "libx264-64.dll" korrekt erstellt hat, ist doch schon mal gut!


    Ja, aber ich habe den Eindruck, dass ich eine 64bit Version erstellt habe. Scheinbar kann man dem Compiler aber wohl mit `--build=TYPE' irgendwie mitteilen für welche Plattform er das kompilieren soll. Die INSTALL-Readme verweist dann auf conf.sub, aber das verstehe ich noch nicht :huh:

    Jetzt hab ich nichmal ne saubere neue Version aus dem GIT geladen und einfach nur ohne Parameter ganz simpel

    ./configure
    make
    make install

    ausgeführt um eine normale Executable zu erstellen.
    Während der kompilierung tauchen ziemlich viele Warnings, aber keine Errors auf, u.a. folgende:

    • warning: array subscript is above array bounds
    • warning: 'mvp[1]' may be used uninitialized in this function
    • warning: unused variable 'saveptr'

    und weitere.
    Die kompilierte x264.exe stürzt dann bei "x264.exe --help" schon ab.

    --------------------------------

    Zweiter Versuch:

    Aufräumen:

    make clean
    make distclean

    nochmal kompiliert

    ./configure

    ./configure --extra-cflags="-march=pentium2"
    make fprofiled VIDS="sample.avs"

    -> gleiche warnings und x264.exe stürzt bei den 5 Tests (?) die dann am Ende ausgeführt werden genauso ab wie im Versuch vorher.

    greets
    LTJ

    Jetzt hab ich mit

    ./configure --disable-mp4-output --enabled-shared
    make
    make install

    eine x264.exe core Version und eine libx264-64.dll mitten im x264_src - Ordner und im msys\local\bin - Ordner erstellt. :huh:

    Ich versuchs einfach morgen nochmal und nu endgültig bye.

    greets
    LTJ

    OK soweit, nächste Frage:

    Ich komme mir gerade echt bescheuert vor :redface:
    Ich kann in genau einen Ordner navigieren und das geht mit
    "cd /mingw"
    alle anderen Ordner findet er nicht.
    Gibt es irgendwo eine vernünftige Doku über dieses völlig unhandliche Shellsystem, das etwas ausführlicher ist, als "help command"?
    Sowas in der Art wie "AVISynth - Your first Script" wäre schon ein Anfang :D.

    greets
    LTJ

    Ich fühl mich gerade ein wenig so wie an dem Tag, an dem ich zum ersten mal AVISynth benutzt habe. :ani_lol:
    Für meine eigenen Projekte hat bisher immer das ältere stabile MinGW 3.4.5 Paket + Code::Blocks ausgereicht.

    Also, brauche ich für Msys auch noch diese Pakete?
    MSYS DTK 1.0
    MSYS Core 1.0.11

    Ist mit yasm dieses Teil gemeint?
    Win32 .exe (for "normal" (Visual Studio or similar) use on 32-bit Windows)
    und kommt die yasm.exe mit in den bin-ordner von MinGW?

    und

    diese pthreads bibliothek?
    http://sourceware.org/pthreads-win32/
    Danke. :)

    greets
    LTJ

    hab zwar keine PS3, aber oft ist "QPel" ein Killer.
    Kann man so weit ich weiß nur durch reencoden ändern.

    Zwei andere Dinge:
    "Packet Bitream" und "Userdata", kann man mit mpeg4modifier patchen.
    Also vielleicht mal mit aktiviertem "Packet Bitstream" und dem Eintrag "DivX503b1393p" das File neu erstellen lassen.

    greets
    LTJ

    Du hast das Video in einem *.mov Container ich habe das in Matroska.

    Ich hab das Problem aber entdeckt.
    AVIDemux scheint bei Streams die von x264 direkt in MKV ausgegeben werden, Probleme zu haben (schwarzes Bild), jedoch nicht mehr, wenn man einmal mit mkvmerge remuxed.
    Allerdings stimmt das Startframe im Preview-Window, nicht und ich habe doch ein wenig den Eindruck, dass da bei H264 generell alles noch ziemlich wackelt.
    Gibt es mittlerweile überhaupt ein stabiles, framegenaues Schnittprogramm für H264?

    Hier noch das Testfile:
    MeGUI, x264 unrestricted 1pass const. Quality / ~650 Frames @mkv / 24fps / crf18 / ~3MB
    http://depositfiles.com/files/8280572

    greets
    LTJ

    Wie sieht das denn mit dem Schneiden von H264 in AVIDemux aus?
    Das scheint arge Probleme zu machen. Meine Testsamples von BigBuckBunny lassen sich nicht öffnen, wenn die Framerate 24fps beträgt. Beim Navigieren durch den Stream vor und zurück stürzt das Programm häufig ab und H264-RAW wird fragend als MPEG erkannt.
    Ist das schon alles bekannt und/oder wird da gerade dran geschraubt?

    greets
    LTJ

    Du vermischt auch gerade ein wenig Container und reinen Videostream im Sinne von RAW-Bytestream. Ein Container enthält immer Informationen darüber was, welche Art von Streams, in ihm stecken und zusätzlich weitere Informationen, wie bspw. Skalierungsfaktoren für anamorphe Quellen, Framerate, FourCC etc. Dazu muß erstmal ein Splitter her, der die Daten des Containers richtig verarbeiten kann.
    TSRemux und TsMuxer sind im Grunde auch Splitter im weitesten Sinne, nur das sie Elementary Streams komplett in eine eigene Datei extrahieren und nicht Stück für Stück live an einen Decoder weiterleiten. Wenn diese nun bspw. einen m2ts-Container nicht sauber einlesen können, liegt das entweder daran, das der m2ts-Parsingprozess nicht sauber für alle Eventualitäten, die der Container bietet, gerüstet ist oder das Programm, mit dem zuvor die m2ts produziert wurde, nicht fehlerfrei arbeitet, beides ist denkbar.
    Erst wenn ein fehlerfreies Splitten sichergestellt ist, sind wir bei dem Punkt der Dekodierung und das ist schon wieder ne ganz andere Geschichte und dann kommt das wieder zum Tragen was Ligh diesbezüglich auch schon meinte.
    Der H264-Standard ist extrem umfangreich und ich wage zu behaupten, dass es keinen Decoder gibt, der sämtliche Features, die H264 bietet, implementiert hat. Demnach muß die Wahl des Decoders auf den Stream oder umgekehrt abgestimmt werden. Für diesen Zweck gibt es daher Level- und Profilbeschränkungen, an denen sich Programmierer und Entwickler von Hardware-Decodern orientieren können. Einen Header im eigentlichen Sinne gibt es bei H264 übrigens nicht. Der gesamte RAW-Bytestream ist in sog. NAL-Units aufgeteilt und jede davon hat eine Art eigenen Header. Notwendigerweise gibt es aber natürlich NALUs welche eine sog. Headerfunktion einnehmen. Die heißen Sequence Parameter Set (SPS) und Picture Parameter Set (PPS), die braucht ein Decoder zwingend um andere NALUs korrekt verarbeiten zu können. Anderes als bei bspw. MPEG4-ASP und MPEG2 können diese "Header"-NALUs aber mitten im Stream wechseln und dem Decoder somit signaliseiren: Hey, hier bitte anderes decodieren als gerade. Und das ist lange nicht alles was es so an Spielereien gibt, daher ist das schon eine kleine Herausforderung für einen Programmierer, der sein Werk gewissenhaft vollbringen will :).


    greets
    LTJ