PureBoard

Reden wir jetzt vom 2-Pass Encoding, wo einmal das Analyse-Encoding mit dem zweiten optimierten Encoding verglichen wird oder reden wir von 2 komplett durchgeführten Encoding-Läufen. Das heißt 2x 2-Pass Encoding durchläufen?

Bei ersterem ist klar, das die Unterschiede Binär da sind, da das erste kodieren ein analyselauf ist und der 2. der optimierte endgültige Lauf, weswegen sich beide grundlegend unterscheiden müssen. Bei letzterem ist es auch klar, das sich diese Binär unterscheiden, da im Grunde niemals sichergestellt werden kann, ob der Analyselauf die selben Optimierungsparameter für den 2. Durchlauf bringt, wie es die vorangegangene Kodierung gebracht hat, da einfach zu viele Umstände das analysieren beeinflussen können. Zum Beispiel Speichergröße, die durch Auslastung variieren kann etc etc.

Ich glaube wir kommen bestimmt der Einigkeit näher

Ich rede von letzterem.

Also source.wmv

2Pass Verfahren mit x264

First Pass Quelle. source.wmv

Einmal im Second Pass Codiert zu a.avi (ich weiss soll mann nicht machen, ich hau es dann später in nenn mkv Container mit MkvMerge, da ich VirtualDub, AviSynth und FFDShow zum Decodieren benutze (ist paar Frames schneller) muss erst mal der avi Container herhalten)

Und sofort im Anschluss ohne überhaupt irgendwas zu ändern, zu b.avi (wie gesagt, ich hab das ändern der FirstPass.cfg ausgeschaltet)

Ich hätte nie gedacht, daß sich da was ändert, weil das System grade etwas mehr oder weniger Ram (hab eigentlich immer genug frei) zur Verfügung hat.

Der DirectShow Decoder gibt doch immer das selbe Bild aus (ausser ich starte Source.wmv einmal im MediaPlayerClassic und benutze FFDShow, und nochmal Source.wmv in MplayerClasic und mit FFDShow, dann hat das eine im ersten Player nenn anderen Farbton & Helligkeitston als im 2. MediaPlayerClassic <-- dort ist das Bild etwas rötlich und heller was ich mir bis heute nicht erklären kann)
und Avisynth der als Frameserver dient, gibt die Frames von Source.wmv unverändert weiter, desshalb sollte der Decodierende Codec keinen Unterschied machen.

Auf jeden Fall finde ich sehr interessant das immer was anderes rauskommt, am liebsten würde ich mal die Entwickler von x264,Xvid usw fragen durch welche Mysteriösen Faktoren das beeinflusst wird.

Auf jeden Fall funzt die Methode sehr gut wenn mann eine Medien Datei gezogen hat von gewissen Seiten wo die QuellDatei auch noch in 5 Jahren unverändert sein wird, und seine Files auf 5 HD's nach dieser Datei durchsuchen lässt. Ich ziehh schon mal öfter das selbe

Wenn ich sowas machen, dann nehme ich meistens das erste und das letzte Megabyte einer Datei und dazu noch ihre Größe, packe das in einen Speicherbereiche und nutze SHA512 oder ähnliches um mir einen Hash zu generieren. Damit hab ich letztens bei einem unserer Server 20 GB doppelte Mails erkennen können und jeweils die doppelten/dreifachen/vierfachen/... löschen können.

Also das Verfahren ist nicht unüblich. Gerade für den Privatgebrauch darf man das auch so machen. Schreibt man allerdings eine Software für die Allgemeinheit, sollte man wirklich byteweise vergleichen bzw. einen Hash jeder kompletten Datei erzeugen. So geht es gerade bei mehre als nur einer Dublette wesentlich schneller.

NicTheQuick hat geschrieben:Wenn ich sowas machen, dann nehme ich meistens das erste und das letzte Megabyte einer Datei und dazu noch ihre Größe, packe das in einen Speicherbereiche und nutze SHA512 oder ähnliches um mir einen Hash zu generieren. Damit hab ich letztens bei einem unserer Server 20 GB doppelte Mails erkennen können und jeweils die doppelten/dreifachen/vierfachen/... löschen können.

Also das Verfahren ist nicht unüblich. Gerade für den Privatgebrauch darf man das auch so machen. Schreibt man allerdings eine Software für die Allgemeinheit, sollte man wirklich byteweise vergleichen bzw. einen Hash jeder kompletten Datei erzeugen. So geht es gerade bei mehre als nur einer Dublette wesentlich schneller.

Deine Methode kann ich leider nicht anwenden (glaub die ist sogar noch schneller) ich brauche ne Prüfsumme die in ein Gadget Column passt, und die packen irgendwie nur 260 Zeichen.

Für die Allgemeinheit ist das Tool nicht wirklich, es ist mein altes Pron Indexing Tool an das ich mich nach 3 Jahren Pause wieder rangesetzt hab, ist nicht einfach sich wieder in 10k Code einzulesen auf jeden Fall muss die MD5FileFingerprint Methode erst mal komplett ausgebaut werden, den CRC32 Check hab ich schon durch meine Methode ersetzt.