Hört sich nett an,.. nächste Woche mal lesen 
(Danke für den Hinweis)
Cu Selur
Könnte nicht mal wer ein paar Scans online stelln?
Vor diesem Testbericht kann ich nur warnen; er vermittelt m.E. ein falsches Bild von der Realität.
Ob die Tester wohl wußten, was sie tun:
Dazu legten wir mit DVD2AVI ein d2v-Projekt an, das anschließend mittels VFAPI Reader Codec in ein Pseudo-AVI umgewandelt wurde. Die weitere Verarbeitung (Skalieren, Kodierung) erledigten der Frameserver AVISynth und VirtualDub. Dabei ist zu beachten, dass VirtualDub die Videodaten im "Full Processing Mode" im RGB-Farbraum verarbeitet. Die Codecs verwenden...
Wozu VFAPI, wenn AviSynth als Frameserver eingesetzt wird? Wozu VirtualDub im "Full Processing Mode" einsetzen, wenn AviSynth doch YUV2 oder sogar YV12 (Version 2.5x) kann? Das macht mich skeptisch im Hinblick auf die im Testergebnis angegebenen Kodiergeschwindigkeiten.
Besonders das m.E. viel zu gute Abschneiden des VP3.2.5.0 Codecs lässt mein Vertrauen in diesen Test schwinden. XviD wurde hinter DivX platziert; nach meinen Erfahrungen gehört das anders herum. Und sowohl WMV9 als auch RV9 kommen im Test zu gut weg.
Und dass der RMP4 als "enger Verwandter" des XviD-Codecs bezeichnet wird, ist meiner Meinung nach ein Affrond. Wer die Angelegenheit verfolgt hat, weiss, dass es sich beim RMP4 um nichts anderes als einen geklauten XviD-Codec handelt. Das XviD-Projekt wurde aus Protest sogar zeitweise eingestellt.
Ich bin c't-Abonnent, und ich kann Euch versichern, dass ich schon viele weitaus bessere Artikel in dieser ansonsten recht guten Zeitschrift gelesen habe.
bb
Originally posted by dts
...und bei dem schnellen "overview Flug" am Anfang sogar verpixelungen im DVD Bild.
Ja wie auch... den haben wir bei "digital images" produziert (falls das die Kinowelt-Version war): In dieser Szene ist die Bitrate an der absoluten Maximum-Schmerzgrenze; ein älteres DVD-Player-Modell (ich glaube von Philips) ist in dieser Szene konsequent ausgestiegen - da wurde dann nachgewiesen, dass dieser DVD-Player einen zu kleinen VBV-(Decoding-)Puffer hatte, unterhalb der Empfehlung der DVD-Spezifikationen.
Das wäre was für die Post-Processing-Funktionen im MPEG2DEC3 - mpeg2source(cpu > 0), da wird auch deblockt!
wenn die xvid wirklich mit rgb füttern, ist das ergebnis allerdings nicht zum vergleich geeignet. AFAIK gibt ist die interen rgb YV12 convertierung von xvid nicht wirklich gut oder sogar buggy.
:hallo:
Jetzt wirds hier aber prominent.:)
Ebenfalls Hallo dem Retter in der Download-Not! Ohne deinen Mirror wäre ich manchmal nie zu einem XviD-Codec gekommen, der auf einem dnsalias lag. In letzter Zeit gab's aber nicht viele Neuzugänge?!
Hatte leider wenig/keine Zeit
Ich meinte eher, dass auch Koepi und Nic auf ihrer Seite nichts neues veröffentlicht hatten - wie also solltest du dann was zum Spiegeln haben?! :sly:
ohh mann
ich bin also nicht der einzige, den dieser artikel, sagen wir mal irritiert hat
ich habe windows media video 9 noch nie probiert zum codieren, aber ich kann mir einfach nicht vorstellen, dass dieser zur zeit der beste sein soll...
ich habe den artikel leider nicht vollständig lesen können, da die ct meinen wg-nachbar gehört, aber laut euer darlegungen hier, muss ich sagen haben die krasse fehler für die codierung gemacht
cya
Hi,
ich hatte mich etwas veräppelt gefühlt und habe deshalb eine Mail an den Verfasser des Artikels geschrieben.
Siehr so aus, als hätte er den HErstellern verschieden proprietärer Codecs vieles ... lest weiter unten....
Also,
hier die wichtigsten Kommentare ein wenig zusammengefasst:
@EDIT:
Ich werde die Kommentare wieder posten solbald ich .....
die offizielle Erlaubnis dazu habe...
@Edit Final:
Nachdem ich nun von Dr. Volker Zota (VZA) die Erlaubnis habe, hier die Kommentare:
Warum VFAPI?
Leider ist die Sache mit VirtualDub etwas unglücklich formuliert (wie mir jetzt auffällt). Die Kodierung wurde nämlich mit "Fast Recompress" in VirtualDub(Mod) durchgeführt. Da ist wohl ein Satz beim Redigieren entschwunden. _ Ich habe den VFAPI Reader Codec verwendet, weil ich die Daten an Real, Microsoft & Co herausgeben wollte, den Bearbeitungs- und Installationsaufwand für sie möglichst gering halten wollte. Mir schien AVISynth zuzgl. der benötigten Plug-ins zu umständlich -- Microsoft war auch so schon nicht glücklich. Im Nachhinein wäre es egal gewesen, weil ich die Testdateien schlussendlich doch komplett über FTP zum Download freigegeben habe, aber zu dem Zeitpunkt war es schon zu spät, die Testdateien von Real und Dicas zurückzuziehen. Mir ging es ja darum, dass die Hersteller selbst die -- nach ihre Meinung -- optimalen Parameter vorgeben, damit sie sich später nicht beklagen. Insofern musste ich Kompromisse eingehen. Generell ist AVISynth natürlich die bessere Wahl und wird beim nächsten Codec-Test (falls ich jemals wieder Lust verspüre, mich Wochen lang mit den Codecs und der Qualitätsbewertung herumzuschlagen
Frage:Warum VFAPI Rederder, wer verwendet ihn noch und für was?
Doch nur, wenn jemand mit AviSynth nicht zurrecht kommt und sich die VideoTools (IPCServer, PremierePlugin, Link2) nicht leisten will und/oder von All-In-One und Decoding Applicationen wie Flask/XMPEG (geniale Tools!) genug hat!
Wichtiges Ergebnis:
Ob man in RGB oder YUV/YV12 kodiert hat auf die Qualitätsbewertung übrigens nur marginale Auswirkungen gezeigt, die relativen Qualitätsabstände blieben jedenfalls unbeeinflusst. Lediglich die Kodiergeschwindigkeit ist beim stringenten Arbeiten unter YUV höher.
Der Hinweis im Artikel, dass "VDUB" im "Full Processing Mode" mit RG32 arbeitet war auch nur als solcher gedacht.
Es wurden definitif alle Umwandlungen mit VDUBMOD im "Fast Recompress" Mode gemacht und damit im YUY Format.
Frage:...dass Sie exlizit von der Farbraumkonvertierung geschrieben hatten. Wurde denn nun im "Full Processing Mode" und damit im RGB Farbraum gearbeitet (was bedeutet, es wurde von YV12 auf RGB und wieder auf YUV konvertiert)???
Frage: Ist es richtig, dass alle getesteten "Kompressionisten" im YUY Farbraum arbeiten (was Sie erwähnten) und YUY als Input akzeptieren??
Ich denke das erklärt ziemlich genau, warum der VFAPI zwischengeschaltet wurde.
Gruss,
TCD
P.S. Wer die Mails gerne komplett lesen möchte kann Sie gerne kann sie gerne ge-forwarded bekommen.[/I]
Leute, Ihr seid einfach zu Speed-Geil.
Der Testaufbau ist eigentlich der einzig logische. Denn das Tempo sollte verglichen werden, ebenso die Qualität.
Dabei ist es völlig unerheblich, wie viele FpS man nun wirklich erreichen kann. Wichtig ist nur das Verhältnis der Geschwindigkeiten zueinander. Dieses Testkriterium ist somit zu 100% erfüllt.
Dann das Kriterium Qualität. Auch da ist der Testaufbau logisch, da er nach wie vor der qualitativ mit Abstand(!) beste ist, was das Decodieren der MPEG-Videos betrifft. Wenn dann einer der Codecs mit diesem Material nicht klar kommt, dann ist das ein Fehler des Codecs, nicht des Testaufbaus.
Also: Testkriterien waren Welcher ist am besten und wie schnell sind die Teile?
Sie waren NICHT: Wie encodet man am schnellsten.
Der Testaufbau basiert außerdem auf bewährter Software, was für einen ehrlichen Test sehr wichtig ist. Andere Dinge wie z.B. AVISynth ändern sich zurzeit viel zu schnell. Und hätten sie AVISynth genommen und wegen der Vorlaufszeit, die eine Zeitschrift nunmal hat, aber eine ältere Version, dann hätten sich einige von Euch auch wieder beschwert, richtig?
Außerdem ist es bei aktuellen Frameserverversionen nicht zu 100% sicher, ob nicht doch noch verborgene Macken enthalten sind, die nicht so ohne weiteres erkennbar sind, aber eventuell die Testergebnisse verfälschen könnten.
Nichts für ungut, aber vor das Kritisieren hat das Schicksal das Nachdenken darüber gesetzt, warum jemand so gehandelt hat.
Gruß,
Kika
Uhhh...
Kritik, ist meiner Ansicht nache eine der besten Formen der Kommunikation und sollte nicht so verteufelt werden, denn ich bin mir sicher, jeder hat sich Gedanken zum Thema gemacht, vielleicht nur nicht immer die Richtigen...
Gruss,
TCD
P.S.: Und wenn Du das statement des Authors gelesen hast, siehst Du, das nicht nur das Kriterium Qualität (und die entsprechende Geschw. etc.) Grund für den gewählten Testaufbau...
P.P.S: Nichts für Ungut, aber vor ... das schreibe ich jetzt lieber nicht weiter.
Originally posted by Kika
Leute, Ihr seid einfach zu Speed-Geil.
Ist doch nichts dagegen zu sagen 
Der Testaufbau ist eigentlich der einzig logische. Denn das Tempo sollte verglichen werden, ebenso die Qualität.
Dabei ist es völlig unerheblich, wie viele FpS man nun wirklich erreichen kann. Wichtig ist nur das Verhältnis der Geschwindigkeiten zueinander. Dieses Testkriterium ist somit zu 100% erfüllt.
Wenn ich nun aber mal mit dem einen Codec prima AviSynth verwenden kann (womöglich sogar im YV12-Farbraum), mit dem anderen aber nur RGB, dann ergibt sich daraus ein ganz praktischer - und zwar erheblicher - Unterschied. Übrigens: falls die Codierzeit gar keine Rolle spielt, kann man ja gleich einen H.264-Codec nehmen...
Dann das Kriterium Qualität. Auch da ist der Testaufbau logisch, da er nach wie vor der qualitativ mit Abstand(!) beste ist, was das Decodieren der MPEG-Videos betrifft. Wenn dann einer der Codecs mit diesem Material nicht klar kommt, dann ist das ein Fehler des Codecs, nicht des Testaufbaus.
Wenn ich die Wahl habe, wie ich dem Codec das Material zu "Fressen" gebe, dann wähle ich im richtigen Leben doch die günstigste, nicht die, mit der auch viele andere Codecs klar kommen, die mich gar nicht interessieren.
Also: Testkriterien waren Welcher ist am besten und wie schnell sind die Teile?
Sie waren NICHT: Wie encodet man am schnellsten.
So gesehen ist der c't-Testaufbau zwar von theoretischem, aber weniger von praktischem Interesse.
Der Testaufbau basiert außerdem auf bewährter Software, was für einen ehrlichen Test sehr wichtig ist. Andere Dinge wie z.B. AVISynth ändern sich zurzeit viel zu schnell. Und hätten sie AVISynth genommen und wegen der Vorlaufszeit, die eine Zeitschrift nunmal hat, aber eine ältere Version, dann hätten sich einige von Euch auch wieder beschwert, richtig?
So langsam ist die c't gar nicht. Die hätten ruhig AviSynth 2.51 verwenden können.
Außerdem ist es bei aktuellen Frameserverversionen nicht zu 100% sicher, ob nicht doch noch verborgene Macken enthalten sind, die nicht so ohne weiteres erkennbar sind, aber eventuell die Testergebnisse verfälschen könnten.
Naja, dieses Argument ist aber ziemlich dünn... Jede Software wird im Laufe der Zeit immer noch etwas verbessert - das gilt übrigens auch für VFAPI.
Nichts für ungut, aber vor das Kritisieren hat das Schicksal das Nachdenken darüber gesetzt, warum jemand so gehandelt hat.
Gruß,
Kika
Als "alter Hase" hättest Du Dir diesen Satz wirklich sparen können. Mit solchen "weisen Sprüchen" untergräbst Du nur Deine eigene Autorität. Nimm's mir nicht übel, aber darüber habe ich mich wirklich geärgert.
Mein Fazit: Ich bleibe lieber bei Doom9's Codec-Vergleichen. Da gibt's ja auch wieder einen aktuellen, und dem traue ich wesentlich mehr, denn da sind Jahre mehr an Erfahrung eingeflossen. Es wird wohl auch niemand erwarten, dass ein Redakteur seine ganze Freizeit über Jahre hinweg investiert um dann einen Artikel zu schreiben.
bb
Fazit,
die Geschwindigkeitsmessungen im CT Vergleich sind nur unter dem vewendeten Szenario repräsentativ. Man kann sie nich übertragen!!
Nur unter einer ganz bedingten Vorraussetzung: Unter verwendung von unkompressed AVI im RGB32 Farbraum abzüglich der Zeit, die der VFAPI zum Dekodieren braucht.
Schlecht ist, dass diese beiden Einschränkungen im Artikel nicht genannt werden
Die Qualitätsmessungen sind natürlich repräsentativ, und dafür ist der Testaufbau auch vollkommen in Ordung.
Und natürlich hat persönliche Kritik hichts in einem seriösen Forum verloren, da Sie jegliche sachliche Wissensbildung und Diskussion verhindern kann.
Und:
Was mich etwas enttäuscht hat, war das der Author sich zu sehr auf Streaming sachen konzentriert hat und nicht mal über die 1000kbit Bitrate schwelle gekommen ist...
Finde ich auch, aber es war leider seine Grundlage nur 1000kbits zu verwenden...
... außerdem hat er das Bild nicht mal ansatzweise versucht zu opimieren, kein cropping, kein ordentlicher resizer (sieht alles sehr weichgezeichnet aus).
Vollkommen richtig, z.B "kein Croppen" verändert die Geschwindigkeitsmessungen massiv, so sind zwar die Vergleiche OK, die Werte aber nicht wirklich wertvoll...
Gruss,
TCD
Nochmal was grundsätzliches:
Ich versuche gar nicht, die c't in irgendeiner Form zu verteidigen, mir geht es wirklich hauptsächlich darum, dass man sich auch mal ein paar Gedanken zu den Tests machen sollte.
> Als "alter Hase" hättest Du Dir diesen Satz wirklich sparen können.
Nein, konnte ich nicht. Aber ich sehe schon, der Satz wurde nicht so verstanden, wie er gemeint war.
Richtig ist, dass man schneller und besser encoden kann als das beim Testaufbau der Fall war. Richtig ist auch, dass die diesbezügliche Info in den Test mit hineingehört hätte. Richtig ist aber auch, dass die c't beim Test auf einen 100% verifizierten Testaufbau zurückgegriffen hat, der einiges an Sicherheit bietet, was die statistische Verteilung von Unsicherheiten des Testaufbaus als solchem bietet.
Richtig ist ebenfalls, dass hier bei der Kritik zumindest Anfangs nur auf ein paar wenige Stellen eingegangen wurde, es aber nicht erkennbar war, dass sich irgendwer wirklich damit auseinander gesetzt hat. Kritik als solche definiert sich dadurch, dass man nicht nur sagt, da habt Ihr Mist gebaut, sondern dadurch, das man die schlechten Dinge beim Namen nennt und konstruktive Vorschläge macht, sie zu verbessern.
Was hier aber geschrieben wurde, war höchstens "hättet Ihr dies oder jenes getan" aber nicht "Damit wäre dies und jenes besser gewesen".
Ich persönlich halte übrigens gar nichts von solchen Vergleichen, was dabei heraus kommen kann, sieht man zu oft, nämlich, dass fast gar nichts bewiesen wird, egal wie sorgfältig man testet.
Vergleicht das doch mal mit der Vielzahl unterschiedlicher Guides zum Thema komprimieren von Videos. Jeder behauptet, sein Guide wäre der beste...
bb
> Wenn ich die Wahl habe, wie ich dem Codec das Material zu "Fressen" gebe, dann wähle ich im richtigen Leben doch die günstigste, nicht die, mit der auch viele andere Codecs klar kommen, die mich gar nicht interessieren.
Ein sehr guter Punkt, der auch gleich eines der Hauptprobleme bei solchen Tests zeigt.
Deine Argumente sind aus Anwendersicht absolut richtig. Aber: auf einer solchen Basis kannst Du gar keinen fairen Vergleichstest von Codecs machen, denn sie müssen alle exakt dieselbe Ausgangsbasis bekommen. Und das ist dann immer der kleinste gemeinsame Nenner. Unter den Tisch fallen dann natürlich die Dinge, die man hätte bei Codec X verbessern können, bei Codec Y aber zu Problemen führen.
So, ich hoffe, nun ist klar geworden, was ich mit der kritisierten Bemerkung meinte. Wer einen Test als solchen kritisiert, sollte versuchen, beide Seiten zu sehen. Nämlich 1. die Anwenderseiten und 2. die des Testers, der immer versuchen wird, allen eine gleiche Ausgangsbasis zu geben.
Man hätte den Codec-Test auch anders aufziehen können, z.B. so holen Sie die optimale Qualität heraus bei Anwendung xy und Codec yz, das wäre dann aber KEIN Vergleich der Codecs gewesen.
Wenn ich die Wahl habe, wie ich dem Codec das Material zu "Fressen" gebe, dann wähle ich im richtigen Leben doch die günstigste, nicht die, mit der auch viele andere Codecs klar kommen, die mich gar nicht interessieren.
Aber: auf einer solchen Basis kannst Du gar keinen fairen Vergleichstest von Codecs machen, denn sie müssen alle exakt dieselbe Ausgangsbasis bekommen.
Nur wenn man eine DVD (Eiskalte Engel) als Ausgangsmaterial nimmt, müssen die Codecs halt selber sehen, wie sie damit klar kommen. Wenn einer kein YV12 kann, hat er eben einen Nachteil. Das gehört für mich auch zu einem fairen Vergleich. Ich möchte doch wissen, wie ich eine bestimmte Quelle möglichst gut konvertieren kann. Ansonsten kann ich mir IMHO einen Test sparen, wenn ich nur theoretisch verwertbare Ergebisse erhalte. Zumal wenn ich sie in einer Zeitschrift veröffentliche.
Was spräche eigentlich dagegen mit Avisynth 2.51 zu arbeiten und das avs-Script den Codecs vorzusetzen? Je nach Fall hätte man doch einfach ein ConvertTo"Farbraum" reinsetzen können.
Viele Grüße bb empty
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
