Ich kann bislang nicht klagen, lief alles perfekt. Zur Sicherheit sollte man aber nur Title-Sets schreiben und die von IFOEdit mit Get VTS sectors nochmal prüfen lassen.
Probleme hat der Muxer mit niedrigen Bitraten, vor allem mit niedrigen Audio-Bitraten. Auf gar keinen Fall unter 192 kbps bei Audio gehen! Zumindest bei der 0508 ist das immer noch so.
Außerdem führt Force YUY2 je nach weiterverarbeitendem Programm eventuell zu Problemen.
Überflüssig ist die Einstellung ebenfalls. Per Default liefert PICVideo sowieso YUY2, nur wenn RGB angefordert wird, liefert er auch das. Bei Force YUY2 liefert er aber immer YUY2, selbst wenn ein Programm eigentlich RGB haben möchte.
> 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.
Also, bei höherer Bitrate nicht mit TMPGEnc muxen, sondern mit bbMPEG oder MPLex (Forced auf 0).
Ansonsten besorge Dir mpgxmps von Gandalf dem Grauen. Das Tool erstellt aus dem gemuxten File die Dateien, die I-Author benötigt.
In I-Author selber darauf auchten, dass die Settings auf Super VideoCD und nicht auf SVCD stehen, das ist wichtig!
Wird das alles beachtet, dann ist das nach wie vor der beste Weg, SVCDs zu erzeugen, besonders, wenn mehrere Tracks drauf sollen. VCDEasy & Co haben da, wie alle Tools, die auf dem VCD Imager beruhen, Probleme mit.
Ach so, Nachtrag: Für die SubTitle gibt's keine solche Lösung. Willst Du die und auch höhere Bitraten, musst Du entweder in Kauf nehmen, dass die Zeitangaben nicht stimmen (bei I-Author, da Du dann mpgxmps nicht nutzen kannst) oder ein anderes Tool benutzen.
> Ich dachte immer, man müsse mit qudratischen Pixeln aufnehmen (768x576) und in 720 encoden, weil der Kram nachher im TV als rechteckige Pixel gestreckt wird. <
Nee, so ist das natürlich falsch. DVD-Player geben immer rechteckige Pixel aus, daher macht es auch keinen Sinn, mit quadratischen Pixeln aufzunehmen. Es sei denn, die Aufnahmetreiber lassen es nicht anders zu.
>Mir ist vollkommen klar, das 704 auch zum DVD Standard gehört, aber wie siehts aus, wenn 704 aufgenommen wird und die Schose dann im TV bei der DVD Wiedergabe gestreckt wird? <
Schön, dass das klar ist. Aber ist Dir auch klar, warum 704x576 im Standard vorhanden ist? Das dient dazu, Videos aus analogen Quellen, die alle der Norm CCIR 601 und nicht der neueren ITU-R folgen, verzerrungsfrei auf DVD bannen zu können.
Videos mit 704x576 werden also nicht etwa bei der Wiedergabe auf 720x576 gestreckt, sondern bleiben wie sie sind. Folgen Player und TVs exakt den Normen, dann ist es sogar eher anders herum: Bei einem Video mit 720x576 wird das Motion Area, das 704x576 beträgt, herausgeschnitten und direkt wieder gegeben, der Rest landet im Datennirvana.
> Und wenn 704er captures funktionieren, dann .... vielen Dank für den Tip!
Ob Deine Karte das kann, weiß ich natürlich nicht. Kann sie's, dann funktioniert dieses Format mit absoluter Sicherheit.
Lucike FZ
Danke fürs Posten des Links, ich hatte den auf die schnelle nicht gefunden.
... und, meine Güte, ist das echt schon wieder so lange her? Unglaublich, ich glaub' ich werd' alt... 
TMPGEnc DVD Author arbeitet auch mit 480x576. Man muss aber dann mit DVDPatcher auf 352x576 patchen (anschließend wieder rückgängig machen). Wichtig ist dabei, dass nicht nur der erste, sondern alle Header gepatcht werden müssen.
> Ebenso, wenn ich TV-Captures habe, welche 768x576 sind und dann in CCE als 720x576 encoden möchte
Ich krieg noch die Kriese... seit Jahren macht man sich die Mühe, über Videoformate aufzuklären, aber dieses Gerücht kriegt man nicht tot.
Wenn TV-Captures auf DVD sollen, dann zu 704x576 encoden, nicht zu 720x576. Dabei ist natürlich dann auch viel sinnvoller, gleich in 704x576 (soweit die Treiber das zulassen) aufzunehmen.
Genau so ist es. Der Nulltransform ist nur dazu da, das Croppen zu ermöglichen, wenn sonst nichts gemacht wird. Den aktivieren kann man es nur, wenn überhaupt ein Filter gesetzt wurde. Genau genommen ist Nulltransform also ein Dummy.
Das m2v-Plugin ist eh nicht gerade die schnellste Methode, das File in TMPGEnc zu öffnen. Da ist z.B. ein d2v-Projekt von DVD2AVI oder gleich direkt die AVISynth-Methode schneller.
Hm, 3 Stunden Video, 12 Stunden für die Ausgabe, kommt bei Deinem PC nur dann hin, wenn Du TMPGEnc außer dem Encoden noch andere Dinge tun lässt, z.B. die Größe ändern oder gar filtern. Oder wenn Du bei der Motion Search precision Highest eingestellt hast. High reicht da völlig.
Wenn Du sowieso noch einen weiteren Filter einsetzt, benötigst Du den Nulltransform nicht unbedingt. Denn Croppen lässt sich bei jedem Filter aktivieren.
Ich sagte ja schon, dass der Test einige Schwächen hat.
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.
Klar, für Dich ist das wichtig, was aber ist mit den Leuten, die ganz andere Dinge mit den Codecs vorhaben? Die könnten einen Artikel, der Dich zufrieden gestellt hätte, dann mit den gleichen Argumenten kritisieren.
Und letztendlich ist bei einem Codec-Vergleich eines wichtig: Wie gut ist die Bildqualität bei Bitrate X - woher der Source dafür kommt und wie und womit er bearbeitet/konvertiert wurde, ist dabei zweitrangig.
> Ansonsten kann ich mir IMHO einen Test sparen, wenn ich nur theoretisch verwertbare Ergebisse erhalte.
Du wirst IMMER nur theoretisch verwertbare Ergenisse bekommen. Das ist doch genau wie beim DVD-Kopieren. Da gibt es DEN Weg, der immer und bei jedem Film DIE optimale Qualität liefert ja auch nicht, sondern nur Richtwerte.
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.
Wahrscheinlich ist die DVD interlaced, das ist bei nahezu allen Konzertmitschnitten so. Also entweder interlaced encoden oder mit einem guten Deinterlacer, z.B. GreedyHMA deinterlacen.
Ein einfaches Deinterlacen per Blending spart zwar Bitrate, sorgt aber auch für Unschärfe und für Nachzieheffekte.
Bislang geht das auch noch nicht. Bleibt zu hoffen, dass die mal einen Template-Editor entwickeln, der dann Bestandteil der Vollversion wird. Denn ohne ist's mit 68 $ einfach zu teuer.
Schon mal auf die Idee gekommen, dass Du die Files auch direkt an PowerTools übergeben kannst, ohne sie vorher durch IFOEdit zu jagen?
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
480x576 und 544x576 verwenden ein anderes zugrunde liegendes Screenformat als 704x576, nämlich 720x576. Beim direkten Resizen ohne Cropping wird dadurch das Bild leicht verzerrt. Habe ich doch schon geschrieben...
> Das Bild wird so oder so in der Horizontalen interpoliert
Äh, wie meinen? Interpoliert wird nur von den Software-Playern. Bei Hardware geht das via Signaltiming, was was ganz anderes ist.
> 720x576 enthält mehr Redundanz, sollte also etwas besser komprimierbar sein. 704x576 enthält weniger Redundanz, aber auch weniger Pixel zu kodieren. Wird sich wahrscheinlich in etwa die Waage halten
Rundundanz? Was für eine Redundanz?
Ein 720er Bild von einer analogen Quelle ist grundsätzlich falsch encodet, da beim CRT-Timing von 52us pro Zeile maximal 704 Pixel möglich sind.
Exakt so, jedenfalls dann, wenn die Hersteller der Streams sich an die Normen gehalten haben, tun aber längst nicht alle.
Ich würde es ein wenig davon abhängig mache, was ich sehe, wenn ich einen DVB-Stream öffne. Gehört er zur Full-D1-Gruppe? Wenn ja, hat er links und/oder rechts schwarze Balken? Wenn ja, dann ist's wohl Broadcast-D1, verpackt in ein Full-D1-Format (Motion Area). Wenn ja, kann man's auch beschneiden und in ein Broadcast-Format konvertieren.
Man kann natürlich auch immer zu 720 oder 704 resizen, die dabei eventuell entstehende Verzerrung sehen die meisten Leute sowieso nicht, vor allem, da viele TVs ab Werk so beschissen eingestellt sind, dass sie das Bild eh verzerren.
720x576 bei DVB... Mag sein, die Leute bei den Sendern haben auch immer weniger Ahnung. Von einem Röhrenfernseher (CRT) kann die 720er-Auflösung gar nicht dargestellt werden. Deshalb hat man bei diesem Format auch die Motion Area, das ist der Bereich, in dem die "wichtigen" Bildinformationen enthalten sind, mit 704x576 definiert.
Machen die's richtig, dann sollte das Format zwar eventuell 720x576, aber nicht der gesamte Bereich mit Bild gefüllt sein.
Ist auch bei vielen DVDs so, dass die links und/oder rechts schmale schwarze Balken haben.
Die internationalen Normen schreiben es jedenfalls so vor, wie ich's gepostet habe, aber wie Du schon sagtest... Theorie und Praxis...
> 352x576 ist mir noch nie DVB mäßig untergekommen
Mir auch nicht, ist auch gut so, da das nur knapp oberhalb der VHS-Auflösung liegt. Viele DVD-Rekorder machen das aber im Long-Play-Modus. Außerdem gibt's DVDs, bei denen die Extras so gespeichert sind.
