P.S.: In der Zusammenfassung vom 1. Durchlauf (und der geht ja recht schnell) steht
Codex264 [info]: final ratefactor: ##.##So sollte man also für ein paar Zielbitraten auch einfach einen CRF-Bereich ermitteln können.
Das ist vielleicht eine Richtlinie, aber nicht gleichzusetzen mit einem äquivalenten CRF-Wert. Siehe auch hier.
Nein
???
Bin mir nicht sicher wem du hier antwortest, laut Baumansicht nicht mir.
x264 verwendet bei CRF0 das "High 4:4:4 Predictive Profile (Hi444PP)" welches von DGDecNV nicht unterstützt wird.
Übrigens: DGIndexNV kann nicht mit x264 --CRF0 Verlustfreien Material umgehen.
DGIndexNV zeigt völlig zerstörte Bilder an und das Programm crasht danach!
Andere Werte unter CRF 18 habe ich noch nicht getestet...
Sonst funktioniert allesWas da los?
Wahrscheinlich hast du es mit i422 oder ähnlich gefüttert. DGDecNV unterstützt nur 420 (AFAIK).
vor einiger Zeit hatte ich vom Internet mehrere Filme im BlueRay Format runtergeladen
Seit 10 Jahren Mitglied und immer noch nicht die Forenregeln gelesen?
Verstehe ich das richtig, wenn ich das .dgi file habe kann ich DGDecNV nutzen ohne eine Lizenz zu haben?
Korrekt.
Es gibt keine Shareware-Einschränkung von DGIndexNV, da DGIndexNV keine Shareware ist
. Ohne gültige Lizenz funktioniert es schlicht und einfach gar nicht - weder beim Indexieren, noch beim Decodieren.
Stimmt nicht ganz. Der Decoder funktioniert ohne Lizenz.
Dazu habe ich eine Neue Festplatte genommen und ein halb Nacktes Windows XP SP3 System aufgesetzt
Es bleibt Spannend
Ohne Zweifel. Beim zweiten Teil erwarte ich ein vollständig entkleidetes Windows! :cool:
Dabei beachtest du allerdings nicht die logarithmische Wahrnehmung der Lautstärke. Die Größenordnung (~ Exponent) ist entscheidend, nicht der exakte Wert.
Bei 32 bit Integer hast du (abzüglich eines Vorzeichen-Bits und eines weiteren – eigentlich mehr – für die Rauschschwelle) maximal 30 bit für unterscheidbare Dynamik, und je leiser es wird, umso weniger Bit bleiben für die Sample-Auflösung, also die Verständlichkeit (leise Szenen verschwinden im Rauschteppich).
Bei 32 bit Float hast du 24 bit Mantisse auch in leisen Szenen, und 7 bit für den Exponenten = 128 Größenordnungen. Beides dürfte aber deutlich jenseits des Hörvermögens sein, wohl auch jenseits der Auflösung von Mirkofonen und Audio-Aufnahmegeräten, praktisch spielen hier eher noch Audioeffektfilter eine Rolle.
Man bedenke aber, dass Mehrkanal-dts auf DVD Video lediglich auf 16-bit-Integer basiert, und die Komprimierung von 6-Kanal-Ton auf 2-Kanal-Bitrate auch nicht völlig verlustlos ist.
Von diesem Standpunkt gesehen hast du ja recht. Die Verteilung der Bits für 32 Bit IEEE Float ist allerdings etwas anders (23 Bits Mantisse, 8 Bits Exponent, 1 Bit Vorzeichen). siehe auch hier.
Dann denk noch mal über Mantisse und Exponent nach. Der Exponent einer Integer-Zahl ist konstant.
OK. Das ändert nichts daran das 32 Bit eben nur maximal 2^32 diskrete Werte aufnehmen können. Beim Fliesskommatyp werden die verfügbaren bits in Mantisse und Exponent aufgeteilt.
Bei Formaten, die Ganzzahl-Samplewerte speichern (wie PCM und dts), ist sie durch die Sample-Auflösung nummerisch stärker begrenzt als bei Formaten, die Fließkomma-Koeffizienten speichern können
Sorry, das ist nicht korrekt. Es kommt darauf an, wieviel diskrete Sample-Werte gespeichert werden können, der Datentyp (Fliesskomma oder Ganzzahl) spielt dabei keine Rolle. Das Format 32 Bit Int kann genauso viele diskrete Werte speichern wie 32 Bit Float. Dann gibt es auch noch w64...
Ne, Liste wäre mal nicht schlecht
FFMS2 sollte theoretisch mit allem zurechtkommen, was Libavcodec decodieren kann.
Okay. Ich habe mal die FFMS2.dll (r800+29) durchsucht.
:eek: Es ist ein Lagarith-Decoder enthalten. :daumen:
Man kann auch einfach im Code nachschauen (codectype.cpp):
#if (LIBAVCODEC_VERSION_INT) >= (AV_VERSION_INT(52, 108, 0))
{ CODEC_ID_LAGARITH, MKTAG('L', 'A', 'G', 'S') },
#endif
So schlimm scheint StaxRip auch nicht zu sein.
Es stammt schließlich von einem Doom9 Member!
An dieser bestechenden Logik gibt es nichts zu bemängeln. 
Und die x264 Presets von StaxRip sind einfach nur Top
Die Presets von x264 sind auch nicht schlecht. Die x264 Entwickler haben sich da schon Gedanken gemacht.
Du hast dieses SSE4.2, das bei mir fehlt.
Irrelevant. Bei alten Avisynth Versionen fehlt einfach SSE4.2 in der Deklaration. Avisynth benutzt maximal SSE2.
Ich denke, dass du weniger Probleme haettest, wenn du auf Staxrip verzichten wuerdest. Was kann Staxrip, das VirtualDub und/oder ein paar Batchdateien nicht koennen?
Hab hier eine Gute Anleitung zum HC-Encoder, die ich beim Stöbern im Internet gefunden habe
Ich hab' nur eine Frage - Woher weisst du, dass die Anleitung gut ist wenn du offensichtlich weniger als die Hälfte davon verstehst?
So wie es aussieht, hast du ein "Tutorial" von einem zufälligen WebLink genommen, hier ins Forum gekleistert, mit Rechtschreibfehlern geflutet und verlangst nun (indirekt) all das erklärt zu bekommen.
Alles anzeigenAviSynth kann für sich alleine überhaupt nicht "sämtliche Formate des Universums" lesen. Insbesondere hängt es stark von den verwendeten Funktionen ab, was möglich ist. AviSynth alleine hat überhaupt gar keine Decoder.
So kann beispielsweise die Funktion AviSource nicht für sich alleine AVI-Videos laden. Sie ruft dafür lediglich Betriebssystemfunktionen von Windows auf und "lässt sich AVIs laden", wenn im System dafür geeignete VfW-Codecs für die enthaltenen Video- und Audio-Formate installiert sind. Fehlt im System ein VfW-Decoder für das enthaltene Video, liefert AviSource nur die Fehlermeldung zurück, dass kein passender Codec installiert sei.
Das gleiche gilt für DirectShowSource, welches die im Windows-System installierten DirectShow-Filter (Splitter für Kontainerformate, Dedoder für deren Inhalte) verwenden kann.
ffdshow hat eine ganze Menge VfW-Codecs und DirectShow-Decoder (aber keine Splitter) implementiert, die u.U. noch aktiviert werden müssen, damit ffdshow sich fähig meldet, diese Formate decodieren zu können. Aber deren Anzahl ist auch endlich. Was ffdshow nicht decodieren kann, oder wofür man ffdshow nicht verwenden will (Nachprogrammierungen von Original-Codecs müssen ja nicht immer fehlerfrei sein), muss durch Installation anderer VfW-Codecs oder DirectShow-Filter unterstützt werden. ffdshow hat dabei den Vorteil, sowohl kostenlos als auch nur eine einzige Installation zu sein. Alternativen sind meist nur für ein oder wenige Formate zuständig, weshalb man sehr viele installieren müsste, um die gleiche Auswahl an Formaten wie in ffdshow zu unterstützen; manche können sogar kommerziell sein und nur mit gekaufter Lizenz ohne Einschränkungen oder Einblendungen arbeiten.
ffdshow bringt also die Decoder mit, die AviSynth indirekt benutzen kann, um sich durch VfW oder DirectShow Videos laden zu lassen. Die LAV Filter gehen noch darüber hinaus, sind deutlich aktueller, haben auch Splitter-Filter für DirectShow.
Um sich nicht auf VfW oder DirectShow sowie auf im System installierte Decoder (und Splitter) verlassen zu müssen, gibt es auch native AviSynth-Plugins, die tatsächlich selber Kontainer splitten und Inhalte decodieren können: FFmpegSource2 und L-SMASH Source.
Super Beitrag! Komplett, kompakt, so wie es sein soll.
Und AviSynth kann MPEG-2 durch folgendes Script darstellen.
CodeLoadPlugin("C:\AviSynth\DGDecode\DGDecode.dll") MPEG2Source("C:\*.d2v")Wie soll ich das jetzt am besten erklären..
Wenn du die Dokumentation von DGDecode gelesen hättest wüsstest du, dass es einen MPEG Decoder beinhaltet.
Irgendwie verstehe ich den Sinn von FFDShow nicht?
Den Sinn??
Hier ist die Beschreibung auf der SourceForge Web site:
ffdshow is DirectShow and VFW codec for decoding/encoding many video and audio formats, including DivX and XviD movies using libavcodec, xvid and other opensourced libraries with a rich set of postprocessing filters.
Was gibt es da nicht zu verstehen? Ob du es brauchst oder nicht musst du selbst entscheiden.
Wer sicher sein will, dass der Qualitätsverlust einen gewissen Grad nicht überschreitet, der wählt den CBR-Modus, kann dann aber die Endgröße nicht zuverlässig vorhersagen. Die Mindestbitrate, die nötig ist, um ein vorgegebenes Minedstmaß an Qualität zu bewahren, ist abhängig vom Videoinhalt.
Ich vermute mal, dass du CRF-Modus meinst.
aber vielleicht schreibt IanB auch noch was dazu.
Bist du sicher, dass du Ian's replies gelesen hast?