Originally posted by Kika
Ich denke, das alles gesagt wurde.Tatsache ist, dass der Test durchaus Vergleiche zulässt, was wohl auch das Ziel war. Tatsache ist aber auch, dass die genutzten Verfahren an sich heutzutage nicht mehr dem entsprechen, wie es die meisten Anwender nutzen. Insofern muss man die Aussagekraft des Tests relativieren.
Das ist vollkommen richtig.
Der Thread kann ruhig geschlossen werden, da ich mich (und ander Posts auch) eigentlich immer wieder wiederhole.
Gruezi,
TCD
Hi,
ich habe mittlerweile alles neu aufgesetzt, und festgestellt, dass der DS_Decoder vom Koepi Realease vom Mai 2003 eigentlich nicht mal XviD decodiert (auf meine mRechner).
Nur NIC's DS Filter (Stable) decodiert sierichtig.
Bei Koepis Release bekomme ich ein Flakern.
Ist Dir das bekannt????
Mittlerweile dekodiert der DS von XviD auch gar keine DivX 5.0x mehr, egal ob mit oder ohne FFMPEG....
Möglicherweise habe ich mir gewisse Settings in der Registry zerschossen (Durch das viele Installieren und Deinstallieren).
Gruss,
TCD
Originally posted by empty
Hab ich mich schon wieder schlecht ausgedrückt.Verspreche mich zu bessern.:ja: Wenn du die reine Konvertierleistung der Codecs von RGB nach dem jeweiligen Format haben möchtest,ist das natürlich richtig. Aber das ist der von mir gemeinte "theoretische" Wert. Praktisch möchte ich doch die Geschwindigkeit ermitteln, die ich von Original -> Kopie brauche und wenn ich dann eine Farbraumkonvertierung weniger brauche, ist der Codec eben um diesen Betrag schneller.
Ich sehe schon wir haben einfach unterschiedliche Auffassungen darüber, was so ein Test aussagen sollte.;)
Schön gesagt.;D
Viele Grüße bb empty
Ja natürlich, das wiederspricht in keinster Weise meinen Ausführungen.
Die Geschwindigkeiten im Test (in der CT 11 ist übrigens ein MPEG2 Encoder Test, bei dem einige Fehler entdeckt sind) sind für den RGB Farbraum absolut korrekt, und das war das Ziel des Testers.
Logischerweise funktioniert der ein oder andere Codec im YUY bzw. YV12 Farbraum als Input, Output und zur Verarbeitung. Nicht nur die fehlende Konvertierung brächte eine Geschwindikeitsvorteil, sondern das arbeiten im Farbraum selbst auch.
Das Setup ist vollkommen in Ordnung, um gewisse Dinge (...) aufzuzeigen.
Praktisch hat jeder eine eigenen Vorlieben.
Und auch was ein Test aussagen sollte, bleibt jedem selbst überlassen, allerdings bin ich der Meinung, dass es eine Schablone "wie ein MPEG4 Encoder Test aussehen sollte zum Glück nicht gibt.
Denn in diesem Test wäre wieder irgendetwas nciht repärsentativ.
Es ist doch logisch, dass die Geschwindigkeiten der Encoder nur verglichen werden können, wenn man ihnen die selbse SOURCe vorsetzt.
Ich hätte mir ein klare Abgrenzung der Codecs gewünscht, man hätte si ja in allen "Major" Farbräumen testen können, oder zumindes klar machen, dass man durch eine fehlende Farbraumkonvertierung und durch das Verarbeiten in einem bestimmten Farbraum sehr viel Geschwindigkeit herausholen kann...
Die grenzen sollten aufgezeigt werden:
Man könnte auch bemängeln, dass die Geschwindigkeit nicht ab dem Unkomprimierten Video gemessen wurde, denn dann hätte man wenigstens die reinen Kodierzeiten im RGB Farbraum.
Z.B. dass es sich zum Teil um nur theoretisch Verwertbare Ergebnisse handelt (ausser bei den Codecs die RGB als Input benötigen und auch im selbsne Farbraum arbeiten).
Oder, das nicht erwähnt wurde, dass einige der Codecs ihre Stärken bzw. Geschwindigkeitsvorteile eben in den oben genannten Fakten haben (z.B. XviD).
Ich für meine Teil halte von Geschwiindigkeitsmessungen nie etwas, da dies von so vielen Faktoren abhängig ist (verwendete SW, HW, Farbräume, Konvertierungen, Filter, Post+Pre Production...blabla), und ich noch keine für alle Fälle repräsentativen Test gesehen habe.
Viele Grüsse,
TCD
Leider kann das so nicht ganz stimmen...
Ich habe von diesem Bug gehört, er tritt aber wohl nicht immer auf...
Und ich verwende kein GMC und Qpel...
Ich konnte das Problem auf folgendes eingenzen.
Wie im oberen post, kann ich jedes DivX mit der XviD.dll decodieren (mit Medialplayer Classic und ffmpeg).
Sobald aber ein DivX im OGM Container ist funktioniert es nicht mehr.
Das kann dan nur mit dem libvacodec oder der divx.dll decodiert werden.
Ein XviD im AVI oder im OGM container kann ich mit DivX.dll, Libva und Xvid.dll decoden.
Ein DivX im AVI Container ebenso.
Ein DivX im OGM Container aber nur mit DivX und Libvacodec.
Die komplette Verwirrung trat mit Graphedit auf, denn dort konnte der XviD DS-Filter nur noch XviDs decoden:).
Mittlerweile verwende ich nicht mehr DivX zum Encoden sondern nur noch XviD, damit ist das Problem auf jeden Fall gelöst...
Ich habe jetzt mal den DivX deinstalliert und schaue mal, dass ich alle DivX.dll de-registrieren kann...
Gruss,
TCD
Hi,
ich habe ein Problem:
Ich kann mit dem Libvacodec und der Xvid.dll divx 5.0-5.05 und Xvid files sauber dekodieren, wobei der XviD Decoder das beste ergebnis liefert.
(alles mit ffmpeg und ohne, ausser die divx.dll, denn die kann ich mit ffmpeg ja nicht auswählen)
Wenn ich eine OGM Datei verwende (coded mit divx), kann ich den divx decoder und den ffmpeg libacodec verwenden.
Verwende ich alledings die Xvid.dll im ffmpeg ist da bild grün, und der player, egal welcher, stürtzt ab.
Kann das jemand bestätigen, oder weiss etwas darüber??
Hoffentlich kann mir jemand helfen.
Settings im Detail:
DivX.dll FFMPEG-Libvacodec.dll FFMPEG-XviD.dll
DivX Film ja ja ja
XviD Film ja ja ja
OGM (DivX) ja ja nein
Viele Grüße,
TCD
Originally posted by Kika
> Gut, aber dann kann man m.E. keinen seriösen Geschwindigkeitsvergleich mehr machen.Wieso das denn? Das Verfahren lässt doch einen direkten Vergleich zu.
Ein Geschwindigkeitsvergleich der Codecs hat doch nichts damit zu tun, wie schnell die Zulieferkette arbeitet, sondern nur damit, wie schnell der Codec x arbeitet im Vergleich zu einem anderen.
Ist die Zulieferkette langsamer, dann sind zwar die Encodierzeiten länger, das gilt aber in gleicher Form für jeden der Codecs, also ist das Tempo direkt vergleichbar.
Alles andere ergibt ja auch keinen Sinn, da jeder andere, der sowas ebenfalls test, zu anderen Ergebnissen kommt. Denn der Rechner selbst, die Art des Filmes und etliche andere Parameter beeinflussen doch ebenfalls das Arbeitstempo.Nochmal: Es wurden die Codecs verglichen, nicht die Zulieferkette der Tools.
damn right...
Das Tempo ist vergleichbar.
Der Codec Vergleich ist gelungen, er ist nur nicht repräsentativ.
Udn die Wete sind nciht nutzbar.
Zudem schränkt er die Codecs immens ein, da es natürlich nicht sinvoll ist, gewissen Codecs Sources im RGB Farbraum vorzulegen.
Aber für den RGB Farbraum sind die Geschwindigketien in jedem Fall richtig und repräsentativ.
Is doch logisch, oder??
Gruss,
TCD
Hi,
merci vielmals.
Allerdings kann ich mir nicht vorstellen, dass die B-Frames nicht im MPEG4 Standard integriert sind....(ModHQ schon).
DivX verwendet ja schon ewig B-Frames....
gruss,
TCD
Hi,
logischerweise habe ich die deutschen FAQ (wissenswertes ...) gelesen.
Durch das Forschen im englischen Forum ist mir aufgefallen, dass vielleicht die ein oder andere Sache etwas outdated oder nicht mehr ganz korrekt sein könnte (B-Frames).
Anscheinend scheinen sie wunderbar zu funktionieren...
Allerdings sind auch im engl. Forum noch einige wiedersprüchliche Postings zu lesen.
Zu ModHQ habe ich die Antwort gefunden:
Modulated und ModulatedHQ sprengen definitif die MPEG4 Spezifikationen.
Sie mit b-Frames zu verwenden sollte kein Problem mehr machen...
Danke für die klaren Antworten
Gruss,
TCD
Hi,
ich habe mir ma das koepi Realease (unstable)XviD-04102002 dl und installiert.
Ich bin in Sachen XviD noch nciht ganz so versiert, verstehe aber durch die ToolTipps die aufpoppen, wenn man lange genug über den Feldern bleibt doch einiges.
Als Ergänzung habe ich mir alle Guides, sowie die XviD Options Explained 1.3 von Koepi reingezogen.
Dabei ist mir aufgefallen, das die Guides auf älteren Releases basieren, (was ja auch logisch und korrekt ist; vom 08/26/2002 - Gordian Knot Guide 06/22/2002-Xvid in Vdub).
0. Gibt es etwas neuere Guides, denn es sind auch im letzten Stable Release viele neue Optionen hinzugekommen??
1. Weiss jemand wo die Quality Options (Deblocking + Dering) in der detaillierten Form geblieben sind?
2. Wie sieht das aus mit den B-Frames, jetzt wo sie da sind, sollte man sie wohl verwenden, oder???
3. Ist das noch korrekt, dass der Modulated Mode (oder Modulated HQ)die MPEG4 Spezifikationen durchbricht, und auch mit B-Frames nicht richtig funktioniert?
5. Ich denke nicht, das es Sinn macht zusätzlich zum neuen Koepi noch einen XviD DirectShow Filter zu installieren oder (verwende sonst den neusten ffdshow, der die Option bietet entweder den Libvacodec, oder den momentan installierten XviD Dshow zu verwenden)??
Viele Grüße,
TCD
Du musst Dich nciht auf Fit2Cd festlegen, kannst auch den Movie Stacker oder den AVS Genie verwenden:))
Gruss,
TCD
Hi,
trotz alledem solltest Du mal die oben vorgeschlagenen Methoden ausprobieren...
Du erhälst dadurch, je nach source, nicht nur einen Geschwindigkeitsvorteil (CCE)...
Gruss,
TCD
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.
Nur dann kann man es auch konstruktive Kritik nennen.
Eine halbgare Kritik, hat hier aber auch als Denkanstoss zum vertiefen der Thematik geführt, was natürlich ein erwünschenswertes Ergebnis darstellt.
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.
Es fehlte im Artikel einfach die Abgrenzungen dessen, was der Artikel nicht ermöglicht. Es ist vollkommen OK einen lochen Test durchzuführen, denn die theoretisch verwertbaren Ergebnisse sind erwüncht und wertvoll.
Es sollte aber immer gesagt werden, wo die Grenzen eines solchen Test liegen, was WIR hiermit nachholen.
Und Ihr dürft eines nicht vergessen: Egal, wie die Codecs nun von den meisten Leuten benutzt werden - offiziell sind sie NICHT zum Kopieren von DVDs gedacht. Und je nach Material kann die Verwendung von YV12 sogar extrem kontraproduktiv sein. Was Du da verlangst, wäre ein Test, der die Eignung zum DVD-Kopieren beschreibt, nicht aber die universelle Verwendbarkeit.
Das ist momentan noch richtig, mit wenigen Ausnahmen: Wie man jetzt bei einem Streaming/Download Music Angebot sehen kann, ist es durchaus möglich, auch DVD Inhalte später im Internet in spezieller Komprimierter Form anzubieten. Und wie der Erfolg des Launchs der MP3 Verkäufe der Major Musikfirmen in den USA zeigt, sind wir höchstwahrscheinlich nicht mehr weit davon entfernt.
Gruss,
TCD
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
Im englischen Thread postete "RB", dass es bei ihm nich ohne Converion geht, er habe keine XVID/DIvX/other Codecs installiert, was wohl darauf schliessen lässt, dass sich der CCE, wie man es auch schon vom TMPEG gehört hat einfach einen YV12 DECODER krallt, und etwas im Müll rum dekodiert....
Wir werden sehen...
Gruss,
TCD
Was Dein Prob anbelangt, so muss ich gestehen, keinen blassen Schimmer zu haben. Ich dachte bisher, die Farbraumänderung müsste zwingend ins Script, da ja der CCE mit der "eigentlichen Farbe" nichts anfangen kann. Es wäre aber nett, wenn Du uns hier über die Infos aus dem englishcen Forum auf dem laufenden hältst.
Der CCE versucht jeh nach Einstellung (ist im GUI wirklich einstellbar) entweder das Video als YUY2 zu dekodieren oder als RGB32.
Gruss,
TCD
Yop, vgl den Thread aus dem engl Forum...
http://forum.doom9.org/showthread.php…8133#post308133
Es ist aber noch keine wirklich Erkenntnis.
P.S.: Wenn das von Cinemacraft wirklich beabsichtigt wäre , dann haätten Sie es wohl in die Options gepackt und ins Chngelog geschrieben....
Ich frag mal nach, bei Zeiten...
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.
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
fürs Preprocessing eingesetzt werden.
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]
