Beiträge von akapuma

    DGMPGDec 2.0.0.7

    * Revamped frame property support in the 64-bit DGDecode.dll, mainly to implement pulldown-related frame properties. Refer to the included file
    FrameProperties.txt for details. real.finder

    DGMPGDec 2.0.0.8:

    * Fixed crash for 64-bit DGDecode with some signaled pixel aspect ratios. Emulgator

    DGMPGDec 2.0.0.9:

    * Fixed problems with the idct, showQ, and info options in the 64-bit DGDecode.dll.
    * The 32-bit and 64-bit DGDecode.dll's now accept an Avisynth script specifying a media file instead of a D2V file. In this case, the file will be automatically indexed if the index file does not exist.


    DGMPGDec MPEG1/2 Decoder and Frame Server (rationalqm.us)


    Gruß

    akapuma

    Hallo,

    ich benutze MKVToolNix 32-Bit im VMWare Player unter Windows 7. Version 66.0.0 läuft. Bei MKVToolNix 67.0.0 erhalte ich folgenden Fehler:

    Der Prozedureinsprungpunkt "CreateDXGIFactory2" wurde in der DLL "dxgi.dll" nicht gefunden.

    Eine dxgi.dll existiert unter C:\Windows\System32

    Hat jemand eine Idee?

    Gruß

    akapuma

    Danke, Selur.

    Irgendwie hatte ich im Kopf daß man die Bits bei der Farbe reduzieren könnte weil das menschliche Auge weniger Farbstufen als Helligkeitsstufen wahrnehmen könnte. Ich habe aber auch nichts mehr dazu gefunden.

    Da lag ich wohl falsch.

    Gruß

    akapuma

    Hallo,

    daß man die beiden Farbkanäle (Chroma) geringer abtastet als den Luma-Helligkeitskanal ist klar (Chroma-Subsampling / Farbunterabtastung).

    Wie sieht es aus mit der Farbtiefe? Haben die Farbkanäle immer genau so viele Bits wie der Helligkeitskanal, oder hat man hier weniger?

    Gruß

    akapuma

    Hallo,

    der "Bock" ist gefunden:


    Avisynth 2.6 makes an 'unaligned' crop by default which is not recommended since it breaks the assumption that all frame buffer data begins at 16 bytes aligned memory address.

    So please add align=true parameter to Crop when using Avisynth 2.6

    Gruß

    akapuma

    Hallo,

    irgendwie ist die Entwicklung von AviSynth+ an mir vorbeigegangen. Mit AviSynth+ läuft es :)

    Ich werde mal probieren ob ich den Fehler mit AviSynth 2.6 auf einem Windows 10 reproduzieren kann. Falls ja werde ich ihn melden, denn er sollte ja nicht sein.

    CPU ist eine Ryzen 5 3400G, das Windows 7 läuft auf VMware.

    Gruß

    akapuma

    Hallo,

    ich habe einen Film mit einer Auflösung von 720x576 Pixeln. Ich habe folgendes AVS-Skript:

    Code
    mpeg2source("K:\Rekorder\aaa\aaa.d2v")
    # crop(2,2,696,572)
    TDeint()

    - Ich kann es mit GordianKnot öffnen und abspielen

    - Ich kann es mit dem MPC-HC öffnen und abspielen

    - Ich kann es mit dem MSU VQMT öffnen und abspielen

    Das geht sowohl mit TDeint 1.1 (letzte Version von tritical) als auch mit TDeint 1.8 (aktuelle Version von pinterf).

    Wenn ich jetzt die Raute vor dem crop entferne läuft es mit TDeint 1.1 immer noch einwandfrei. Mit TDeint 1.8 allerdings nicht mehr.

    GordianKnot und MSU VQMT zeigen folgendes an:

    Avisynth: access violation at 0x000032A0 in C:\Program Files\ AviSynth 2.5\plugins\TDeint.dll, attemting to read from 0xFFFFFFFF

    Der MPC-HC stürzt komplett ab:

    WARNING: Following frames may be wrong.

    tdeint!Ordinal0+0x32a0

    tdeint!Ordinal0+0x7355

    Avisynth-Version ist 2.6.0.5

    TDeint-Version ist x86 1.8.0.0 (20201214)

    Windows ist Windows 7

    Hat jemand eine idee?

    Gruß

    akapuma

    Schließe ich aus den Beiträgen richtig.....? Möchte man bei SATA bleiben, ist man mit einer SAMSUNG 870 recht gut bedient.....?

    Ich bin sehr zufrieden damit. Mittlerweile gibt es auch Benchmarks, ich poste mal 3 Links zu meinen Favoriten:

    WD870

    WDC

    Crucial MX

    Wichtig ist es den richtigen Einbauadapter dazu zu kaufen. Meistens werden 2,5" zu 3,5" - Adapter verkauft, bei meinem Gehäuse war ein 2,5" zu 5,25" - Adapter jedoch die bessere Wahl.

    Ich brauche wirklich nicht viel Platz, 500GB ist für meinen Zweck sehr viel. Ansonsten würde ich eher zu 1TB oder mehr raten!

    Gruß

    akapuma

    Wie genau? Protokollierst du das installierte System mit avsinfo oder analysierst du damit das GK-Skript?

    - Das GK-Skript ist im AVSMeter problemlos durchgelaufen.

    - Der MPC-HC-32-bit spielt das GK-AVS-Skript problemlos ab (nicht jedoch 64bit).

    - Die x264.exe-32-bit encodiert das GK-AVS-Skript problemlos (nicht jedoch 64bit).

    Also eher ein GKnot-Problem.

    Ältere Visual-C++-Runtimes sind auch vorhanden, ab 2005, jeweils als 32- und 64-Bit-Version.

    Warum das Ganze?

    Ich nutze GKnot mit der x264.exe in VMware an gleichen PC mit Win7/32bit. Benchmarks zeigen daß der Host - je nach Test - deutlich schneller sein kann als das Gastsystem. Deshalb wollte ich gucken in wie weit x264 auf dem Hostsystem schneller ist als unter VMWare. Hierbei habe ich festgestellt, daß es im Host kaum schneller läuft. Die Idee, die Encodierung im Host statt auf dem Gastsystem laufen zu lassen bringt letztendlich nichts.

    Dennoch würde mich interessieren warum GKnot meckert. Vielleicht läuft es generell nicht auf 64-Bit-Windows?

    Gruß

    akapuma

    Ich habe das Problem auf einem Win10-64Bit-Rechner. Auf diesem läuft auch Win7/32Bit auf einer virtuellen Maschine mit genau den gleichen DLL's problemlos.

    Es lief weder mit der originalen frisch installierten GKnot-Version noch mit aktualisierten Programmen,

    Avisynth:

    Ich habe Avisynth 2.6 installiert und dann die DLL durch die MT von SEt ersetzt. Version ist 2.6.0.5.

    Bei Win7 steht diese in C:\Windows\System32

    Bei Win10 steht diese in C:\Windows\SysWOW64\

    Sonst steht sie nirgends.

    DGDecode:

    Die DGDecode.dll steht in C:\GordianKnot\DGMPGDec sowohl bei Win7 als auch bei Win10 und hat Version 2.0.0.5. Sonst steht sie nirgends.

    Die .d2v-Datei wurde mit der passenden DGindex erzeugt.

    Gruß

    akapuma

    Edit:

    AVSMeter läuft problemlos durch. Was mir auffällt:

    - Auf win7 kann ich die AVS im MPC-HC abspielen.

    - Auf win10 kann der MPC-HC die AVS nicht rendern.


    Edit 2:

    Mit dem MPC-HC ist etwas anders. Ich hatte den 64-bit installiert, aber zum Ansehen von avs-Dateien benötigt man den 32-bit.

    Hallo,

    ich habe mal probeweise GKnot auf Win10/64bit installiert.

    - Ich kann mit DGIndex eine .d2v-Datei erstellen.

    - Ich kann die .d2v-Datei mit GKnot öffnen, ich sehe das Bild.

    - Ich kann auch eine .avs-Datei erstellen.

    Versuche ich die .avs zu öffnen kommt die Fehlermeldung:

    Plugin C:\GordianKnot\DGMPGDec\DGDecode.dll is not an AviSynth 2.5 plugin.

    Es klappt weder mit der Version die bei GKnot dabei ist (1.8.5) noch mit der aktuellen (2.0.0.5).

    Was kann die Ursache sein?

    Danke.

    Gruß

    akapuma

    Berichte bitte !!!

    Ich?

    Hatte ich doch im Prinzip schon in Post #20 getan.

    Ich fasse gern zusammen:

    Schnittstelle

    Es gibt SATA und M.2 - Schnittstellen. Wie man an Post #20 sieht ist M.2 um ein vielfaches schneller, da bei SATA die Leistungsgzenze erreicht wird. M2. kann man einbauen in:

    - PC's mit freier M.2-Schnittstelle

    - PC's mit freiem PCIe-Steckplatz und mit Adapter (<20€), siehe Post #6

    - Laptops mit freier M.2-Schnittstelle

    M.2 benutzt den PCIe-Bus. Sowohl mein Board als auch meine CPU unterstützen nur PCIe Gen. 3, deshalb habe ich auch nur eine M.2-SSD mit PCIe Gen. 3 drin (Samsung 970 EVO PLUS). Das Nachfolgemodell 980 EVO unterstützt auch PCIe Gen. 4.

    Ich habe mich als 2. Platte dennoch für SATA entschieden, da ich bereits eine M.2-SSD als Systemplatte drin habe. Die 2. SSD brauche ich z.B. für stundenlang per DVB etwas aufzunehmen oder zum Transcodieren, die Plattengeschwindigkeit ist hier nicht entscheidend.

    Da ich eine SATA-SSD habe ist folgendes vielleicht teilweise SATA bezogen.


    Geschwindigkeit

    Verschiedene Benchmarks liefern verschiedene Angaben, deshalb sollte man die Werte nicht auf die Goldwaage legen. Werte um 550MB/s lesen und schreiben sind bei SATA Ende der Fahnenstange. Lesen und schreiben beides über 500MBit/s ist sehr gut. M.2 wäre natürlich viel schneller, z.B. > 3000MBit/s.


    Haltbarkeit

    Es gibt einen garantierten Wert wieviel man auf eine Platte schreiben kann. Der Wert heißt "TBW" = totally bytes written und wird in Terabyte angegeben. Im Moment sind etwa 400TB pro TB Speicherplatz überdurchschnittlich. Ich hätte also eine 500GB-SSD (0,5TB) ab etwa 200TB TBW gekauft. Aber Vorsicht: auf Flyern und Übersichtsseiten werden meistens die TBW des größten Modells angezeigt, also nicht verwirren lassen.

    Meine 500GB Samsung 870EVO hat 300TB TBW. Meine ca. 7 Monate alte 500GB-Systemplatte 970EVO Plus hat bereits 3TB hinter sich, also 1% der garantierten Lebensdauer. Es ist ein "Feierabendrechner".

    MTBF liegt meist zwischen 1 und 2 Millionen Stunden.


    Bits pro Zelle

    Erst hatte man 1 Bit pro Zelle, dann 2, dann 3, dann 4. Die Zellen heißen SLC, MLC, TLC und QLC. Je mehr Bit eine Zelle hat desto langsamer und weniger haltbar ist sie. Je weniger Bit eine Zelle hat desto veralteter ist die SSD. Veraltet bedeutet ebenfalls langsam und weniger haltbar. Das "zweite von rechts", also im Moment TLC, scheint mir eine gute Wahl zu sein. TLC haben im Moment die meisten aktuellen SSD's.


    DRAM

    Nach diesem Post wird bei SSD's mit DRAM eine Mapping-Tabelle im DRAM gespeichert. Bei jedem Lese- und Schreibvorgang muß diese Mapping-Tabelle nämlich gelesen werden, da scheinen mir SSD mit DRAM für die Mapping-Tabelle im Vorteil zu sein. Es gibt auch SSD's ohne DRAM. Die Verbatim, die ich zuerst kaufen wollte, war damit raus,


    Größe

    Meine 500GB-SSD's haben mit 10% Over-Provisioning laut Windows "nur" 419GB frei. Also lieber etwas größer kaufen. Außerdem haben doppelt so große Platten auch einen doppelt so hohen TBW-Wert.

    Ich glaube daß große SSD's die angegebenen Lese- und Schreibgeschwindigkeiten länger / dauerhaft halten können weil sie mehr Chips haben.

    Ich glaube daß kleine SSD's bei großen Datenmengen eher einbrechen weil man eher an die Grenzen des eingebauten SLC-Caches stößt.

    Ich glaube daß SSD's ab ca. 1TB gar keinen SLC-Cache mehr haben / brauchen.


    Stromverbrauch / Wärmenetwicklung

    Bei SATA eher unkritisch. Meist nur wenige Watt. Sollte man vielleicht beim Einbau im Laptop berücksichtigen.

    Bei M.2 eher kritisch. Die haben mehr Leistung und weniger Fläche zur Wärmeabgabe. Bei Samsung sind die Komponenten deshalb teilweise nickelbeschichtet. Auf eBay etc. gibt es Alukühlkörper, die mit Wärmeleitgummi und Gummiringen auf die Chips drücken. Aus Wunsch auch mit Heatpipes, Lüftern etc.

    Ganz toll ist die Parametersuche bei Geizhals (danke HQ-LQ für den Hinweis). Hier würde ich noch alte Modelle ausschließen. "Gelistet ab 2018" dürfte OK sein.

    Ich lasse auf der SSD über VMware ein altes 32-bit Win7 laufen. Benchmarks liefern sowohl mit SSD als auch vorher auf HDD Werte die weit über den physikalischen Möglichkeiten der Platte liegen. Hier kann man also keine Aussage machen was die SSD bringt. Zumindest ist jetzt stundenlanges Aufnehmen und stundenlanges Transcodieren ohne eine mechanische Festplatte möglich.

    Superprefetching (von Pro Jo ins Spiel gebracht) muß man wohl bei aktuellem Win10 nicht mehr abschalten. Beim Win7-Gastsystem habe ich es aber abgeschaltet, deshalb nochmals vielen Dank für den Hinweis.

    Gruß

    akapuma