Archiv verlassen und diese Seite im Standarddesign anzeigen : AVC Lossless Playback?
Deinorius
30. March 2006, 11:28
Ich hab mal mit ein paar Lossless Codecs herumexperimentiert, um zu testen, welche am effizientesten arbeiten.
Leider wollte ffvfw huffyuv nicht gehen. Jedesmal, wenn ich ffdshow in VirtualDub(Mod) nur auswähle führt zum kompletten Absturz. :(
Habs auch mit x264 probiert, wobei ich dafür MeGUI und Sharktooths Profil verwendet habe, aber der wills mir einfach nicht abspielen. Zoom Player will net, MPC will net. Sie öffnen zwar, aber es bleibt nur bei 00:00 stehen und per Avisynth krieg ich nur merkwürdige Fehlermeldungen, wo das : in der Adresse nicht passt. oO
Gibts da allgemein Probleme oder liegt es an CoreAVC. Leider kann ich nicht mehr ffdshow testen, aber ich hab jetzt keine Zeit nochmal eine Datei zu erstellen. :D
Ach ja, wenns interessiert, hier meine Ergebnisse. Auflösung war nur 320x240.
Codec Dauer fps Dateigröße
MJPEG_19 1:01 78,7 109
MJPEG_20 1:00 80 254
MSU Delta Frames deak. 2:28 32,44 166
MSU Absol. Lossl. divx 2:27 32,66 166
Lagarith Null Frames 1:19 60,77 188
Lagarith Standard 1:19 60,77 188
AVC Lossless 2:34 31,11 83,6
Kopernikus
30. March 2006, 11:34
Soweit ich weiß kann CoreAVC kein lossless. Versuch mal ffdsshow, das müsste es können. Versuch mal VLC oder MPlayer.
Selur
30. March 2006, 11:36
CoreAVC unterstützt in der 0.4 vermute Du hast die Version kein lossless AVC (in der 1.0 schon :)) sollte mit ffdshow aber abspielbar sein.
Cu Selur
matthiasb
30. March 2006, 11:41
Welches Farbsystem wurde verwendet?
Gibts da allgemein Probleme oder liegt es an CoreAVC.Das mittels Graphedit überprüfen.
Im ffdshow Video Decoder h264 wieder aktivieren und den DirectShow-Filter "ffdshow MPEG4 decoder" in die Kette einfügen.
Kommt Selbiges (nichts) dann wirds wohl eher am File liegen. (Oder Dein ffdshow ist auch hinüber.)
Deinen ffvfw solltest Du wieder hinbekommen, der huffyuv darin sollte besser sein als der eigene huffyuv-vfw.
Wenn ich mir Deine Ergebnisse so ansehe, solltest Du (soweit es dann wieder funktioniert) das AVC "lossless" mit Subtract unter die Lupe nehmen. Das ist irgendwie zu schön um wahr zu sein.
BTW: Lagarith mit "Null Frames" hat nur Sinn wenn man sich über die Quelle im Klaren ist.
Deinorius
30. March 2006, 12:46
Ich bin einfach zu faul. ffdshow neu instaliert, behebt das Problem. :rolleyes:
Ich kann wohl bei AVC schlecht vergleichen. Die Werte sind sich nie einig. Obs wohl bei MeGUI liegt, hab noch die 0.2.3.2033 wo die Profile gern hin und wieder vermischt werden. Ich sollte endlich eine neuere Version nehmen.
Abspielen geht jedenfalls. Nur zum Bearbeiten würde ich es eher eingeschränkt nehmen, außer wenn ich Videos für diverse Arbeiten archivieren wolle, aber ohne CABAC läufts eh einigermaßen flott daher und die Decodinganforderung ist dann auch nicht so hoch.
BTW: Lagarith mit "Null Frames" hat nur Sinn wenn man sich über die Quelle im Klaren ist. Ist schon klar, aber ich wollte es dennoch mal probieren. Es ist ja auch ein Anime.
Jedenfalls hab ich die Videos mal verglichen. Mir ist jedenfalls nix aufgefallen. Die Video sind anscheinend identisch. Ich war über den großen Vorsprung von AVC auch sehr überrascht, obwohl der gestrige Test anscheinend mit CABAC durchgeführt wurde, obwohl ich doch vorher nachgeschaut hab, ob auch die Einstellungen passen. oO
Die neuen Ergebnisse:
ffvfw huffyuv 1:05 73,86 205
AVC Ll Cabac 17,81 83,6
AVC Ll 39,72 96,3
Redfox
30. March 2006, 16:16
Es ist ja auch ein Anime.
Wenn ich dich richtig verstanden habe und du Animes oder Cartoons verlustfrei speichern wilst, dann solltest du dir unbedingt mal 'Core PNG' (http://corecodec.org/projects/corepng/) ansehen. Der ist auf diese Sourcen optimiert. Im Vergleich zu HuffYUV bekamm ich bei den Simpsons um ein drittel kleinere Dateien. Ich weis nicht ob das bei modernen Animes auch so gut klappt, aber es ist einen Versuch wert.
Ich benutze diesen Codec immer um nach dem rechenintensieven Decomben und Filtern den Cartoon zwischenzuspeichern und anschliesend nen 3-Pass X.264 darüberlaufen zu lassen. Wenn ich x.264 direkt mit dem .avs füttern würde, würde das seeehr viel länger dauern.
Deinorius
30. March 2006, 16:39
1. Ja, ich will Animes bearbeiten und
2. Nein, ich will keine Cartoons bearbeiten. :D
Über CorePNG hab ich mir auch mal Gedanken gemacht. Danke für den Link, werd ich sofort ausprobieren. Diesmal werd ich aber nochmal alle Codecs mit voller Auflösung testen. Mit der Viertel Auflösung gings zwar schön schnell, aber es war weniger realistisch. :rolleyes:
Meintest du mit Huffyuv den orginalen, oder den ffvfw Codec?
Kann CorePNG überhaupt YV12?
Ach übrigens, wozu nutzt du 3 Passes bei x264? Mehr als 2 Passes bringt eigentlich nur bei CCE MPEG-2 was, aber sonst kann man das doch vergessen. Da würde ich z.B. bei x264 langsamere Settings verwenden, bevor ich einen weiteren Pass durchführe. Ist nur meine Meinung.
sade
30. March 2006, 17:36
Code:
Codec Dauer fps Dateigröße
MJPEG_19 1:01 78,7 109
MJPEG_20 1:00 80 254
MSU Delta Frames deak. 2:28 32,44 166
MSU Absol. Lossl. divx 2:27 32,66 166
Lagarith Null Frames 1:19 60,77 188
Lagarith Standard 1:19 60,77 188
AVC Lossless 2:34 31,11 83,6
Bedeutet "MSU Delta Frames deak." das nur I-Frames verwendet wurden?
Wenn ja dann vergleichst du einen mc-basierten codec(x264) gegen 3(bzw. 6) nicht mc-basierte. Äpfel und Birnen...
Kannst du auch Snow testen?
BTW: wie hat msu ihren codec dann so langsam bekommen, ohne me?
Redfox
30. March 2006, 18:26
2. Nein, ich will keine Cartoons bearbeiten. :D
Ach, du weist einfach nicht was gut ist.;)
Über CorePNG hab ich mir auch mal Gedanken gemacht. Danke für den Link, werd ich sofort ausprobieren.
Mach mal! Meine Empfehlung: Benutze maximal die 2 Kompresionsstufe. Die Dritte sorgt zwar für noch mal deutlich kleinere Dateien, dauert aber auch grob 3-4 Mal so lange. Auch das Auslesen des CorePNG-Videos dauert dann deutlich länger. Das macht den Geschwindigkeitsvorteil schon fast wieder zunichte. Die experimentelen Features liefen bei mir stabil.
Meintest du mit Huffyuv den orginalen, oder den ffvfw Codec?
Den VfW-Codec. Warum, gibt es da Unterschiede???
Kann CorePNG überhaupt YV12?
aba sicha dat.
Ach übrigens, wozu nutzt du 3 Passes bei x264? Mehr als 2 Passes bringt eigentlich nur bei CCE MPEG-2 was, aber sonst kann man das doch vergessen. Da würde ich z.B. bei x264 langsamere Settings verwenden, bevor ich einen weiteren Pass durchführe. Ist nur meine Meinung.
Warum sollte sich das denn ausschliesen? Die Settings sind nach Selurs Guide aufs absolute Maximum eingestelt. :cool:
Auserdem schreibt ein weiterer Pass ein anderes Logfile als der davor laufende. Da ich ja mal annehme das die Leute von x.264 da keinen Zufallsgenerator eingebaut haben (wenn da einer drin währe gäbe es ja sonst in der Devel-Mailingliste endlose Diskusionen darüber das Computer ja garkeine 'echten' Zufallszahlen generieren konnen und im Gleitz/Doom9-Forum gäbe es noch endlosere Diskusionen über die perfekten Random-Seed-Files;) )sollte jeder zusätzliche Pass die Bitratenverteilung des finalen Pass optimieren, ergo die zu verfügung stehende Bitrate besser nutzen und ein besseres Bild liefern.
Die Frage ist einfach ob der Zugewinn an Bildqualität den Rechenaufwand rechtfertigt. Wenn der 3-Pass noch mal ca. 5 % Prozent an Quali bringt ist es mir das wert. Aber ich habe da bis jetzt noch keine Aussagekräftigen SSIC(Oder wie das auch immer hieß)-Tests gesehen oder selbst durchgefürt. Deswegen ist das mit dem 3-Pass mehr ein 'auf Nummer sicher gehen'.
Wie sagte mal einer hier im Forum so richtig:Solange ich es nicht selber rechen muss ist mir die Rechenzeit egal.
Weise Worte. :ja:
Kopernikus
30. March 2006, 18:39
Warum sollte sich das denn ausschliesen? Die Settings sind nach Selurs Guide aufs absolute Maximum eingestelt. :cool:
Auserdem schreibt ein weiterer Pass ein anderes Logfile als der davor laufende. Da ich ja mal annehme das die Leute von x.264 da keinen Zufallsgenerator eingebaut haben (wenn da einer drin währe gäbe es ja sonst in der Devel-Mailingliste endlose Diskusionen darüber das Computer ja garkeine 'echten' Zufallszahlen generieren konnen und im Gleitz/Doom9-Forum gäbe es noch endlosere Diskusionen über die perfekten Random-Seed-Files;) )sollte jeder zusätzliche Pass die Bitratenverteilung des finalen Pass optimieren, ergo die zu verfügung stehende Bitrate besser nutzen und ein besseres Bild liefern.
Die Frage ist einfach ob der Zugewinn an Bildqualität den Rechenaufwand rechtfertigt. Wenn der 3-Pass noch mal ca. 5 % Prozent an Quali bringt ist es mir das wert. Aber ich habe da bis jetzt noch keine Aussagekräftigen SSIC(Oder wie das auch immer hieß)-Tests gesehen oder selbst durchgefürt. Deswegen ist das mit dem 3-Pass mehr ein 'auf Nummer sicher gehen'.
5% bringt es nie und nimmer. Der dritte Pass ist nur manchmal sinnvoll, wenn 2 Passes nicht ausreichen, um die Bitrate genau zu erreichen. Manchmal ist es sogar so, dass der dritte Pass mehr schadet als hilft.
Weitere Informationen in diesem Thread:
http://forum.doom9.org/showthread.php?t=108803&highlight=Pass
Selur
30. March 2006, 18:45
Yup, ein dritter Pass lohnt sich meiner Erfahrung nur bei sehr niedrigen Datenraten.
Redfox
30. March 2006, 18:52
5% bringt es nie und nimmer. Der dritte Pass ist nur manchmal sinnvoll, wenn 2 Passes nicht ausreichen, um die Bitrate genau zu erreichen. Manchmal ist es sogar so, dass der dritte Pass mehr schadet als hilft.
Danke für die Info, werde ich mir durchlesen. Die letzte Frage: (danach reicht es mit OffTopic von mir)
First Pass 'normal' oder 'fast'?
sade
30. March 2006, 19:09
Unterschied zwichen fast und normal ist rund 0.02db(das kannst du nicht erkennen) aber je nach deinen 2. pass settings 3-5mal schneller.
Selur
30. March 2006, 19:24
Kann durchaus auch mal mehr sein, zumindest bei niedrigen Bitraten <500kBit ist mich duch auch auch schon mehr untergekommen.
Persönlich wür dich sagen, für normale Datenraten kann man durchaus 'fast' nehmen, bei niedirgen Datenraten sollte man sicherheitshalber 'normal' nehmen.
Cu Selur
Deinorius
30. March 2006, 19:56
@sade
Stimmt, da hast du völlig Recht. Deshalb hab ich MSU auch mit aktivierten Delta Frames getestet. Ergebnisse weiter unten. ;)
Ach, du weist einfach nicht was gut ist.;) Mir reicht es, die Simpsons im Fernsehen zu sehen. ;) Oder auch Futurama. Gibts sonst noch etwas, das nicht den Simpsons ähnelt?
Den VfW-Codec. Warum, gibt es da Unterschiede??? Hab den grad nicht installiert und wills auch nicht. Außer dass der kein YV12 unterstützt, kenn ich jedenfalls keinen. Und über Geschwindigkeitsunterschiede bin ich nicht informiert.
Warum sollte sich das denn ausschliesen? Die Settings sind nach Selurs Guide aufs absolute Maximum eingestelt. :cool:
Auserdem schreibt ein weiterer Pass ein anderes Logfile als der davor laufende. Da ich ja mal annehme das die Leute von x.264 da keinen Zufallsgenerator eingebaut haben (wenn da einer drin währe gäbe es ja sonst in der Devel-Mailingliste endlose Diskusionen darüber das Computer ja garkeine 'echten' Zufallszahlen generieren konnen und im Gleitz/Doom9-Forum gäbe es noch endlosere Diskusionen über die perfekten Random-Seed-Files;) )sollte jeder zusätzliche Pass die Bitratenverteilung des finalen Pass optimieren, ergo die zu verfügung stehende Bitrate besser nutzen und ein besseres Bild liefern.
Die Frage ist einfach ob der Zugewinn an Bildqualität den Rechenaufwand rechtfertigt. Wenn der 3-Pass noch mal ca. 5 % Prozent an Quali bringt ist es mir das wert. Aber ich habe da bis jetzt noch keine Aussagekräftigen SSIC(Oder wie das auch immer hieß)-Tests gesehen oder selbst durchgefürt. Deswegen ist das mit dem 3-Pass mehr ein 'auf Nummer sicher gehen'. Sicher, wenn man so denkt, ists natürlich nicht schlecht. Ich hoffe, du hast eine performante CPU. Ich hab nur nen Athlon XP-M 2000+ und einen noch nicht eingebauten Athlon XP 2100+, der noch unlockt werden muss, damit er vielleicht überhaupt geht. ^^"
Da denkt man weitaus anders. :D Ich werd aber selbst mit einer Quadcore CPU keine 3 Passes durchführen.
So, hab alles nochmal mit voller Auflösung (640x480) getestet, da das realitätsnäher ist. I Hund hab sogar unkomprimiert gespeichert, um mal anständig zu vergleichen. :D Sonst wurde immer mit YV12 komprimiert.
Hier meine Ergebnisse und Comments:
Codec Dauer fps MB Comp.Ratio
Uncompressed 8:55 8,97 4220
CorePNG 12:57 6,18 683 6,18
CorePNG DF 23:12 3,45 422 10
Huffyuv 1:35 50,54 694 6,08
Lagarith 2:22 33,81 619 6,82
MSU 6:03 13,23 531 7,95
MSU + DF 7:58 10,04 245 17,22
ffv1 3:18 24,25 533 7,92
AVC Lossless 5:35 14,79 316 13,35
AVC Cabac 6:51 11,69 276 15,29
MJPEG 19 0:59 81,37 319 13,23
MJPEG 20 1:15 64,01 758 5,57
Bei Uncompressed limitiert schon die HDD-Transferrate (USB-HDD). :D
CorePNG hat mich eigentlich enttäuscht. Zu langsam um diese Komprimierungsraten rechtzufertigen. (Standard, mit und ohne Delta Frames)
Huffyuv ist hier der schnellste Lossless Codec und perfekt für Bearbeitung geeignet wenn man den Platz hat. ^^ (Standard)
Lagarith ist auch recht interessant, der zweitschnellste und komprimiert auch etwas besser als Huffyuv, aber nicht gut genug, weswegen ich wohl eher Huffyuv verwenden würde. Je nach Kompatibilität z.B. mit Premiere würde ich einen der beiden nehmen. (Standard)
MSU ist schon ein verdammt guter Lossless Codec. Mit deaktivierten Delta Frames ist er aber wenig interessant, zu langsam und nicht gut genug für Archivierung oder Bearbeitung. Wenn aber nicht den Platz hat... kann man dann entweder das oder MJPEG 19 nehmen. (Absolutely Lossless, deakt. DFs, sonst Standard)
MSU mit aktivierten Delta Frames ist hier der Gewinner. Wenn man Uncompressed mit dazu nimmt, ist diese Einstellung die viertlangsamste, aber hervorragend für Archivierung geeignet. (Absolutely Lossless, sonst Standard)
Die langsamste MSU Einstellung und damit meine ich die Einstellung "FullSearch" ist mir viiiiiiel zu langsam. Kein Frame pro Sekunde wird dabei bei mir komprimiert.
ffv1 ist noch zu instabil, als dass ich ihn hier bewerten kann, aber sobald optimiert und stabil sehr interessant. Speichert der nur I-Frames oder auch Delta Frames? (Standard)
AVC Lossless ist auch sehr gut, ich würde ihn aber nur zur Archivierung verwenden. Die Decoderanforderung mit CABAC könnte auch noch etwas hoch sein für weitere Bearbeitung, aber das ist jedem selbst überlassen. Der große Vorteil dürfte wohl besonders die bessere Komprimiergeschwindigkeit im Vergleich zu MSU sein, die sich auf DualCores noch weiter hervorhebt. Ohne CABAC ist der auch schneller und komprimiert besser. (Sharktooths Profil, CABAC an oder aus)
MJPEG hab ich nur verwendet, weil es der Schnellste hier ist. Qualität 20 kann man komplett vergessen, da sollte man besser Huffyuv nehmen. 19 ist für die, die noch eine langsame CPU und/oder wenig Speicher haben. (Standard, Swap Fields deaktiviert, was aber eh nicht zugegriffen hat)
Soviel von mir.:)
Mich würde aber noch sehr interessieren, wie sich die Lossless Codecs auf einem Athlon 64 (X2) verhalten würden. Da können die Ergebnisse, besonders bei AVC, schon etwas anders aussehen.
Redfox
30. March 2006, 21:21
Mir reicht es, die Simpsons im Fernsehen zu sehen. ;) Oder auch Futurama. Gibts sonst noch etwas, das nicht den Simpsons ähnelt?
Ich verstehe deine Frage nicht ganz. Der Westliche Zeichentrick den ich kenne, der am wenigsten dem Zeichenstiel der Simpsons ähnelt währe wohl Der Mann der Bäume pflanzte (http://de.wikipedia.org/wiki/Der_Mann_der_B%C3%A4ume_pflanzte)
(Hier (http://www.heeza.fr/BOUTIK/Fiches_Produits/PARADOXE/Homme.html) gibt es nen trailer)
Äh, wolltest du das wissen?
Hab den grad nicht installiert und wills auch nicht. Außer dass der kein YV12 unterstützt, kenn ich jedenfalls keinen. Und über Geschwindigkeitsunterschiede bin ich nicht informiert.
Ich wuste nicht das das YV12 Unterstützt, ich hatte immer nach RGB->YUV umgewandelt :wall:
Werd mir das mal ansehen.
Sicher, wenn man so denkt, ists natürlich nicht schlecht. Ich hoffe, du hast eine performante CPU. Ich hab nur nen Athlon XP-M 2000+ und einen noch nicht eingebauten Athlon XP 2100+, der noch unlockt werden muss, damit er vielleicht überhaupt geht. ^^"
Ich hab nen schwächeren Rechner als du, aber wenn man den Rechner einfach abends losrechnen läst und dann schlafen geht ist er am nächsten Tag fertig. :zunge:
So, hab alles nochmal mit voller Auflösung (640x480) getestet, da das realitätsnäher ist.
Volle Auflösung währe doch wohl eher 720x576.
CorePNG 12:57 6,18 683 6,18
CorePNG DF 23:12 3,45 422 10
Huffyuv 1:35 50,54 694 6,08
CorePNG hat mich eigentlich enttäuscht. Zu langsam um diese Komprimierungsraten rechtzufertigen. (Standard, mit und ohne Delta Frames)
Das wundert mich ziemlich! Welchen Anime hast du den benutzt? Bei den Simpsons war der Unterschied ausgeprägter.
---
Persönlich wür dich sagen, für normale Datenraten kann man durchaus 'fast' nehmen, bei niedirgen Datenraten sollte man sicherheitshalber 'normal' nehmen.
OK, Danke für die Klarstellung. Ich hatte deinen Guide so interprtiert das man entweder 2 Normal pass oder 1 'Fast' und dann 2 'Normal' machen sollte. Jetzt ist alles klar!
Deinorius
31. March 2006, 00:12
Äh, wolltest du das wissen? Das war eigentlich nur ne rhetorisch Frage. Aber eigentlich meinte ich das hinsichtlich Story/Thematik.
Ich wuste nicht das das YV12 Unterstützt, ich hatte immer nach RGB->YUV umgewandelt :wall:
Werd mir das mal ansehen. Ich nutze nur YV12. Gründe muss ich ja sicher nicht nennen.
Ich hab nen schwächeren Rechner als du, aber wenn man den Rechner einfach abends losrechnen läst und dann schlafen geht ist er am nächsten Tag fertig. :zunge: Lustig? Wenn ich einen Film mit AVC komprimiere, wird der nicht so leicht über Nacht fertig. Ein 2h Film braucht mit Filtern bei mir mind. 8h. Würde gehen, aber bei dir... welche CPU?
Volle Auflösung währe doch wohl eher 720x576. Je nach Anwendungsgebrauch. Bei XviD verwende ich normalerweise 640x480 oder 704x384/400.
Die Testdatei ist eine mit XviD komprimierte Datei. Vielleicht teste ich am WE noch mit einer DVD ala Kompressionstest inkl. Filter. Aber das wird ziemlich zach. :zunge:
Das wundert mich ziemlich! Welchen Anime hast du den benutzt? Bei den Simpsons war der Unterschied ausgeprägter. Natürlich geht der bei Simpsons weitaus besser. Mein Anime hat den heutigen Qualitätsstandard, da funzt CorePNG nicht ganz so gut wie bei alten Cartoons/Animes, wo es viel mehr gleichfarbene Flächen gibt.
Selur
31. March 2006, 08:32
OK, Danke für die Klarstellung. Ich hatte deinen Guide so interprtiert das man entweder 2 Normal pass oder 1 'Fast' und dann 2 'Normal' machen sollte. Jetzt ist alles klar! 'fast'/turbo sollte sich nur auf den 1st pass auswirken,...
Zum Losslessvergleich könnte man auch noch Arithyuv ( http://alainmuchembled.free.fr/Arithyuv/ ) dazu packen.
( engl. Doom9 Thread: http://forum.doom9.org/showthread.php?t=98042 )
Cu Selur
vBulletin® v3.7.3, Copyright ©2000-2009, Jelsoft Enterprises Ltd.