VHQ 1 oder 2 würd ich sagen hängt halt stark von der CPU ab,..
Cu Selur
VHQ 1 oder 2 würd ich sagen hängt halt stark von der CPU ab,..
Cu Selur
Haste das mpeg mal durch Project X (ehem. ds.jar) oder pvastrumento gejagt?
Verwendeste auch DVD2AVI 1.76?
Benutzte ne aktuelle TmpgEnc version?
da musste am besten mal ChristianHJW fragen,...
wegen dem Speed:
Yo, das wird am Mv-File liegen,.. war auch nicht mein Test,..
Flask-Ripper macht gerade auch noch nene weiteren Test mit den Zusatzsettings, meinte aber schon das der 2nd pass je nach Zusatzfeature mal schneller und mal langsamer ist,..
"Das kurzfristige Umschalten auf den "Full Processing Mode" brachte leider gar nichts. Der DivX 5.1 setzt seine Keyframes immer noch etwa 2-3 Frames zu spät und der XviD-Codec mit Quantization Type "MPEG" und VHQ (egal ob 1,2,3 oder 4) findet keinen einzigen Schnitt-/Szenenwechsel, sondern setzt stur alle 250 Frames einen Keyframe."
B-Frame maximum auf 0 oder höher setzen! (hab ich aber in nem anderen psot eben schon gepostet, steht auch im 'Wissenswerten rund um Xvid')
Cu Selur
sicher, stell mal maximal b-frame nicht auf -1 sondern 0
ZitatVHQ:
VHQ errechnet die Anzahl von Bits die ein Macroblock in verschiedenen Szenen erreichen kann. Gewählt wird dann das Szenario, welches die kleinste Anzahl an Bits aufweist. Ebenso kann VHQ [eingeschränkt] Bewegungsvektoren suchen. Da GMC und VHQ sich entgegenwirken, sollte man sie auch nicht gleichzeitig aktiviert haben. Je höher die VHQ Stufe ist die man wählt, desto extremer wird der Encodingvorgang ausgebremst. Für die meisten User ist es deshalb wohl am sinnigsten VHQ(1) zu nehmen, da hier der meiste Qualitätsgewinn erzeugt wird und die Geschwindigkeitseinbußen noch nicht so hoch sind. Für absolute Qualitätsfanatiker, wie mich, ist VHQ(4) jedoch ein Muss. Bei höhren VHQ Stufen kann es je nach verwendeter Quantizermatrix auch dazu kommen, dass Keyframes nur noch beim angegebenen Maximum erstellt werden. Um dem entgegen zu wirken sollte man die Maximalen B-Frames mindestens auf 0 stellen, da dann ein teilweise anderer Algorithmus verwendet wird. (Wenn man eine Dualrechner hat, sollte man VHQ nicht >1 benutzen, da sonst die Auslastung der CPUs sinkt.)
Quelle: Wissenswertes rund um Xvid
Cu Selur
Haben im Flaskmpeg/DVDtoOgm-Board auch ein bissel dazu geschrieben, dachte ich zitiere hier mal einene der Beiträge
ZitatAlles anzeigenHallöchen zusammen!
Da sind sie nun endlich, die Ergebnisse meiner 1. (kleinen) Testreihe!
Hier ging es hauptsächlich darum die Encoding-Geschwindigkeiten und Qualitätsunterschiede der verschiedenen „Performance / Quality“ Einstellungen zu testen, und das im Vergleich zum 5.05er Codec, bei dem ich die Performance Quality (wie es ja üblich ist) natürlich auf slowest stehen hatte.
Beim 5.1er habe ich alle 4 verschiedenen Möglichkeiten durchgetestet, es sind also insgesamt erst mal 5 Test-Movies entstanden!Als Testrechner hab ich mal den von meiner Schwester genommen, ein P4 mit 2,66 GHz und 512 MB Ram, auf dem liefen die Tests dann wenigstens ein bissl zügiger ab, als auf meiner 900 MHz Gurke!
Testmaterial war eine (PAL 25fps) 32 minütige (progressive) vob-Datei, so das ich beim encoden nicht deinterlacen musste und hierdurch keine Qualitätsverfälschungen auftreten konnten, die es beim Einsatz eines Deinterlacers ja sicher gegeben hätte. Die Tests hab ich mit Flask durchgeführt, weil’s für solche Tests von der Bedienung her am schnellsten und einfachsten ist!
Einstellungen in Flask:
iDCT = Miha’s Reference iDCT (Reference iDCT daher, um nicht durch ein eventuell schlechtes iDCT irgendwelche Qualitätsverfälschungen in das Testmaterial zu bekommen)
Als Resizer hab ich den „HQ Bikubische Filterung“ genommen, der qualitativ beste der in Flask zur Verfügung steht! Als Auflösung hab ich nicht die große Original DVD-Auflösung gewählt, sondern auf Grund der geringen im Test verwendeten Datenrate hab ich ein bissl kleiner: 640 x 384 genommen (Original DVD ist im 4:3 Format, daher waren die zu croppenden schwarzen Ränder logischerweise nicht so breit wie bei nem 16:9 Film.
Audiobearbeitung in Flask war natürlich deaktiviert, weil ich mich ja nur auf’s Video konzentrieren wollte, und als Video-Format hab ich in Flask gleich „YV12“ gewählt, da ja die vob-Datei (DVD) in YV12 ist, und DivX auch mit YV12 arbeitet, wozu also das Videoformat wechseln?, würde ja höchstens Qualitätsverfälschungen bringen.Einstellungen in den DivX 5.05 –und 5.1 Codecs:
Immer 2-pass (also multipass 1st pass und multipass nth pass); Datenrate immer 500 kbps, ansonsten bei beiden Codecs in allen Tests immer alle Zusatzfeatures deaktiviert!
Beim 5.1er hab ich die Tests mit MV-File gemacht, beim 5.05er ja logischerweise nicht, da dort ja eh kein MV-File erstellt wird, obwohl die Funktion MV-File aktiviert ist.
Keyframe Interval hab ich auf 300 Frames gelassen, und ebenso den Scene Change Threshold auf 50%!
Die Tests:
Test 1: DivX 5.05
Performance / Quality = slowest
Geschwindigkeit first pass = 29,3 fps
Geschwindigkeit second pass = 31,9 fps
Datei-Größe = 115 MBTest 2: DivX 5.1
Performance / Quality = fastest
Geschwindigkeit first pass = 38,5 fps
Geschwindigkeiten second pass = 40,8 fps
Dateigröße = 115 MBTest 3: DivX 5.1
Performance / Quality = normal
Geschwindigkeit first pass = 28,9 fps
Geschwindigkeiten second pass = 39,6 fps
Dateigröße = 115 MBTest 4: DivX 5.1
Performance / Quality = slow
Geschwindigkeit first pass = 8,4 fps
Geschwindigkeiten second pass = 39,6 fps
Dateigröße = 115 MBTest 5: DivX 5.1
Performance / Quality = slowest
Geschwindigkeit first pass = 4,37 fps
Geschwindigkeiten second pass = 39,6 fps
Dateigröße = 115 MB
Ihr seht also, der 5.1er ist gar nicht so langsam wie erst gedacht, zumindest dann im 2. pass nicht mehr, wo er anscheinend nur noch das Video passend zu den im 1. pass analysierten Daten erstellt!
Der grund warum bei meinen ersten Tests es auch im 2. pass so langsam war lag wohl daran, das da das MV-File zwar schon erstellt wurde beim 1. pass, aber beim 2. wohl nicht gelesen wurde, lag daran das ich den 5.1er Codec zusätzlich zum 5.05er drauf gehauen hatte, und der 5.05er nicht automatisch deinstalliert wurde, so haben sich die beiden Codecs dann wohl ein bissl behindert! Gemerkt hatte ich es auch daher, weil auch 2 Decoder, der vom 5.05er und der vom 5.1er, drauf waren und das hatte dann auch teilweise seltsame Probleme beim abspielen gegeben. Also, wichtig, was ich jetzt vor diesen Tests dann auch gemacht hatte, bevor man den 5.1er neu installiert, erst mal alles was an altem DivX aufm Rechner und im System (Registry) ist schön deinstallieren, dann nen Rechner-Neustart machen, und erst dann den 5.1er installieren, und dann sollte das auch alles vernünftig laufen!
Nun zur Qualität:
Sie war natürlich generell nicht so gut, was man ja bei einer Datenrate von 500 kbps, und noch dazu unter deaktivierung aller Zusatzfeatures, auch nicht anders erwarten konnte. Aber ich denke es war schon vorteilhaft eine so geringe Datenrate zu nehmen, denn so konnte ich die Unterschiede zwischen den einzelnen „Performance / Quality“-Einstellungen schon ganz gut erkennen!
Wenn man die insgesamt bei der 500er Datenrate nicht so gute Qualität mal unberücksichtigt lässt und nur auf die Unterschiede der verschiedenen „Performance / Quality“-Settings in den verschiedenen Test-Movies eingeht, komme ich auf folgende Ergebnisse:
Mit deutlichem Abstand sieht am schlechtesten natürlich das DivX 5.1 „fastest“ Test-Movie aus, also die Einstellung fastest ist unter keinen Umständen zu empfehlen, da sie auch bei hohen Datenraten eigentlich noch sehr schlecht aussieht!
Die Einstellung „normal“ beim 5.1er lässt sich eigentlich schon anschauen. Aber ich kann die Aussage von divx.com, dass „normal beim 5.1er = slowest beim 5.05er“ (bis auf die Encoding-Geschwindigkeit) nicht bestätigen , da dort im Vergleich der 5.05er mit „slowest“ schon noch sichtbar besser ausschaut, als der 5.1er bei „normal“! Also würde ich hier auch weiterhin zum 5.05er raten! Abzuwarten bleibt allerdings, wie der 5.1er unter „normal“ dann im Vergleich zum 5.05er ausschaut, wenn man bei beiden Codecs die sinnvollen (qualitätsverbessernden) Zusatzfeatures aktiviert, aber das werde ich dann in späteren Tests noch feststellen.
Mit der Einstellung „slow“ sah der 5.1er dann (für meine Augen) eigentlich genau gleich gut aus, wie der 5.05er bei „slowest“! Wenn man sich allerdings überlegt das der 5.05er diese Qualität mit einer wesentlich schnelleren Encoding-Speed erreicht, als der 5.1er, stellt sich mir schon die Frage was die Leutchen von divx.com dort gebastelt haben...?!?!
Mit der Einstellung „slowest“ sah der 5.1er dann ein kleines bissl besser aus als der 5.05er, aber wirklich nur minimal, ich weiss nicht ob man den Unterschied beim normalen anschauen eines Filmes überhaupt sehen würde, ich hab ihn jetzt bei meinen Tests durch das genauere hinschauen eben festgestellt, aber auch wenn es einem auffällt, so ist doch der Unterschied so gering, dass es sich in keinem Fall lohnt den gewaltigen mehr-Zeitaufwand beim encoden mitm 5.1er mit der Einstellung „slowest“ in Kauf zu nehmen.
Fazit: Jetzt nach der ersten Testreihe würde ich ganz klar dazu raten beim 5.05er zu bleiben. Abzuwarten bleibt allerdings wie viel Qualitätsgewinn beim neuen Codec dann noch die einzelnen (neuen) Zusatzfeatures bringen, vor allem die neuen Psychovisual Enhancements, das werde ich wie schon angekündigt in den nächsten Tagen mit einigen weiteren Tests noch in Erfahrung bringen. Vielleicht geschehen da ja noch Wunder, und es lohnt sich dann unter Verwendung einiger Zusatzfeatures vielleicht doch den 5.1er zu verwenden, aber da glaube ich ehrlich gesagt noch nicht so recht dran...
Ich muss mal sehen wie ich es schaffe, aber es kann gut sein dass ich es nicht vor nächstem Wochenende schaffe mit den weiteren Tests fertig zu werden und dann die Testergebnisse zu posten!
MfG Flask-Ripper
Quelle: Flask-Ripper
Cu Selur
Das Problem ist halt, dass das immer individuell für jeden Clip eingestellt werden muss. Die Standardwerte die meist fluppen, hat LigH ja bereits in seiner Übersetzung gepsotet,..
Cu Selur
"Kann es, wenn Bilder längere Zeit nur aus B- und P-Frames generiert werden, nicht zu einem Qualitäts- oder Schärfeverlust kommen?"
Natürlich kann dies geschehen, nur braucht ein zusätzliches I-Frame halt zusätzlichen Speicher, der einem je nachdem an einer anderen Stelle fehlen kann,...
Für maximal Qualität hilft nur lossless encoding, da dies jedoch momentan noch zu sehr großen Dateien führt macht man halt Kompromisse wie:
Weniger I-Frames => Mehr Daten die verteilt werden könne, jedoch auch weniger Sprungstellen und eventuell ein etwas unschärferes Bild
Wenn man natürlich weiß, das man einen Clip encoded, in dem sich 12 Sekunden nix tut, kann man das Intervall ja auch runterschrauben.
Cu Selur
Ps.:
Nebenbei: Viele Leute stellen das maximale Intervall auf Framrate*10 (daher kommen auch die 300 etwa 29.976*10).
Wenn Du ne bestimmte Maske drüber legen willst, würde auch mal die interene DeKafka Funktion, siehe:
http://www.avisynth.org/index.php?page=ShareFunctions
von Avisynth antesten,...
Cu Selur
dito, seh ich auch so, vorher kann man davon ausgehen das zumindest die Entwickler der Ansicht sind, dass es noch keinen official release geben sollte => einige Features funktionieren noch nicht ordentlich => Feinger weg wenn man nicht nur testen will,..
Cu Selur
Okay, wie es gesetzt wird ist jetzt klar, aber:
"Oder nach 6,5s, also in der Mitte, da dies nach meinem Verständnis eine bessere Bildqualität sowie ein leichteres Filmspulen ermöglichen würde."
Wieso bessere Bildqualität? Ist mir unklar?
Solange sich die nachfolgenden Bilder nicht stark (genug) vom Keyframe unterscheiden ist es immer sinnige dieses zu behalten und nicht nochmal ein neues zu schreiben. Oder verstehe ich etwas an Keyframes nicht ?
Cu Selur
UI,.. und wieder was gelernt
Cu Selur
Aktuell ist übrigends die 0.1.3
Hier: http://www.flaskmpeg.info/board/thread.p…eadid=3109&sid=
gibt's immer die neusten Links zu der aktuellen Version,..
Cu Selur
"also ich lege keinen Wert auf Personenkult"
Mist und ich wollte schon mit der T-Shirt-Produktion anfangen,..
Ich hol den Ton immer mit DVD2AVI raus
(da steht auch ein offset/delay im Dateinamen)
Cu Selur
Wenn ich mich recht entsinne, war das um das Intervall festzulegen wie oft GordianKnot davon aus gehen soll, das diese Overheadinformationen geschrieben werden. (Sinnige Werte waren. meine ich mich zu entsinnen. 1 oder 2 bei ac3 und 9 oder 10 bei cbr mp3.)
Cu Selur
Lass nru die Finger von den Modulated&HQ Modulated Quantizer Matrizen, da dies zu Standard konformen vorgehen führen.
Cu Selur
"Die im XviD-Codec eingetragene stats-Datei wird nicht für den CompCheck benutzt."
Wie doof,..
Cu Selur
Eventuell könnte man auch nen ganz heftigen Delay einügen,...
Hab die DVD leider nicht, sonst würd ich mal angucken,.. eventuell gibt's ja auch nen Stream in den vob's der ohne die Musik am Anfang ist,..
Da wären dann aber die vStrip Profis gefragt,..
Cu Selur
Ps.: Eventuell kann LigH was cleveres posten
Yo, und wenn's Unklarheiten zu dem Teil gibt einfach Fragen
Cu Selur