Procoder Qualitätsstufen

Zitat

Habt ihr alle den gleichen DV-Codec installiert?
Warum sollten wir? Das Decoding ist vorgeschrieben, nur beim Encoding hat der Codec-Hersteller ein paar Freiheiten.

Das stimmt nicht.
Es gibt Codecs, die shrinken bzw expandieren die Luma-Range beim kodieren bzw beim dekodieren (MS-DV, Panasonic-DV). Der Canopus-DV-Codec hingegen verändert die Luma-Range in der
Standardeinstellung nicht.
Der aktuelle MainConcept-DV-Codec lässt sich diesbezüglich umschalten, so das er beides liefern kann.
Dadurch entstehen Helligkeitsunterschiede, die man mit geeigenten Einstellungen im MPEG-Encoder ausgleichen sollte.
Aus ein und derselben DV-Datei können Rohdaten mit Luma-Range 16-235 oder 0-255 entstehen, je nachdem, welcher Codec in welcher Einstellung benutzt wird.

Zitat

Es geht hier nicht darum welcher DV-Codec was macht, sondern darum, möglichst nahe am Originalfile zu bleiben - mit MPEG-2!

Das entstandene MPEG-2 ist aber unterschiedlich, je nach dem, wie das DV dekodiert wird,
siehe oben.

Zitat

Wie war der TMPGEnc konfiguriert bzgl 'Output YUV data as Basic YCbCr not CCIR601'?
Keine Ahnung! Was ist Vorgabe bei PAL-DVD? Wenn Du ein anderes Ergebnis erzielst, stell das MPEG-File online und erkläre die Einstellungen im Anhang. Ich werde es dann in den Encodertest übernehmen.

a)
[ ] Output YUV data as Basic YCbCr not CCIR601 (nicht angehakt) :
aus Luma-Range 0-255 wird 16-235, Kompression wird durchgeführt

b)
[x] Output YUV data as Basic YCbCr not CCIR601 (angehakt) :
Luma-Range 0-255 bleibt 0-255
16-235 bleibt 16-235
keine Kompression, keine Expansion

Also, wenn ich in diesem Thread Stagements lese wie "CCE ist etwas farbschwach", drängt sich mir sofort der Verdacht auf, dass hier durch gewissen Kombinationen aus Codec/Encoder/Encoder-Einstellungen und eventuell noch einem Frameserver wie AVISynth oder gar eines Teils wie PlugInPack für Premiere die Luma-Range zu stark komprimiert wurde.
Das ist schnell passiert und führt zu Videos, die flaue Farben haben. Ein Differenzbild würde dann zu eher lustigen Ergebnissen führen.

Zu den DV-Codecs: Da ist es exakt so wie beim MPEG-Encodern, der grundsätzliche Weg ist vorgeschrieben, ja, aber die Qualität unterscheidet sich zum Teil eklatant. Dazu kommt noch das, was Tsunami hier schon sagte: Je nach dem, was angefordert wird (YUY2, RGB24, YV12), kann die Lumarange den Bereich von 0-255 oder von 16-235 haben.
Die MPEG-Encoder können das nicht erkennen, und kompensiert man das nicht selbst, dann... Entweder wird's zu hell oder zu dunkel.
Je nach Kombination von Codec, Encoder und Einstellungen hat man eine 3:1-Chance, es richtig zu machen (3x falsch, nur 1x richtig).

Tsunami:

Standard ist der MS-DV da beißt die Maus keinen Faden ab. Zur Codierung wurde er benutzt (als Typ 2) und wenn man sich die Ergebnisse ansieht, scheinen auch alle diesen oder einen vergleichbaren Codec benutzt zu haben. Die Ergebnisse zeigen nur das Rauschen des MPEG-Codecs, während die von Dir beschriebenen Effekte ein Ergebnis ähnlich dem des CCE-Encoders zeitigen sollten.

B_Racer:

Genau die gleichen Abweichungen wie Ikarus´ Ergebnis habe ich mit dem CCE nachvollziehen können. Also scheint doch etwas an der Flauheit der Farben dran zu sein. Wenn Du ein anderes Ergebnis hast, stell es online und ich werde es veröffentlichen. Die Prämissen weißt Du ja.

@all:
Es hilft nichts, die Sache zu zerreden oder mit wenn - dann - und sowieso - Argumenten zu kommen! Wenn jemand der Meinung daß eines der Ergebnisse falsch ist, kann er das richtige Ergebnis online stellen, es dokumentieren, und wir werden den Vergleich erweitern oder korrigieren.

Einfach nur behaupten kann jeder! Ich glaube nur das was ich selbst gefälscht.... äähhh....getestet habe!

Im übrigen kann jeder den Test mit der Trial vom MSP7 nachvollziehen. Die Testkriterien sind wohl ausreichend genau beschrieben und die DVP muß nur mit den entsprechenden Files neu verknüpft werden.

Viele Grüße
vom Peter

@all:

Die Anderen reden, Peter testet:

Nach den Einwänden von Tsunami und B_Racer habe ich getestet was wirklich passiert wenn man einen anderen Decoder oder einen mit böswillig falschen Einstellungen benutzt.

Einzig und allein der Mainconcept-Encoder, von Hand in den Einstellungen auf RGB 16-235 geändert, brachte ein sichtbar anderes Ergebnis. Hier zwei gleiche Frames als Auszug:

Oben der Test mit RGB0-255, unten der mit RGB16-235. Die Hintergrundfarbe Grau wird etwas ins rötliche verschoben, ansonsten sind die Ergebnisse fast identisch. Im Vergleich zum Rauschen des Encoders ist dieser Farbfehler minimal. Anhand der Histogramme kann man sehr schön nachvollziehen, wie die Farbverschiebung entsteht.

Ich bitte auch immer daran zu denken, daß oben gezeigte Differenzen kontrastübehöht sind. Die tätsachliche Differenz der Encoder in der Kategorie 1 sieht so aus:

Getestete Grüße
vom Peter

Peter

Bei einer Verschiebung oder Komprimierung der Luma-Range ändern sich in erster Linie die Bildhelligkeit und der Kontrast. Die Farben bleiben weitestgehend gleich, verschieben sich also nicht. Da aber die Umrechnung der YUV-Farben zu RGB-Farben unter Verwendung von Y, Cb und Cr erfolgt, also auch den eventuellen falschen Luma-Bereich mit einschließt, werden dann auch die Farben kräftiger bzw. schwächer.

Wie schon ausgeführt, hängt es oft davon ab, über welchen Weg ein Video denn nun exakt in den Encoder kommt.

Nimmt man z.B. Premiere über den Freeware-Frameserver PlugInPack sowie AVISynth, dann erfolgen unter Umständen gleich mehrere Farbraumwandlungen. Ein Beispiel:

DV-Video, YV12, Luma-Range (im Folgenden LR genannt) 16-235 (so sollte es sein).
PlugInPack macht RGB32 draus, LR wird expandiert auf 0-255.
AVIsynth... Ohne gesonderten Parameter wird versucht, YV12 anzufordern. Da das mit PlugInPack nicht geht, wird der Systemcodec zur Wandlung benutzt, nämlich MSYUV, der definitiv fehlerhaft ist.
Nehmen wir an, alles ist richtig gelaufen, dann haben wir ein RGB32-Video mit LR 0-255.
Soll jetzt wegen irgendwelcher Filter zu YUY2 oder YV12 gewandelt werden, ist es elementar wichtig, den interlaced=true Parameter zu benutzen, da sonst ein fehlerhaftes Chroma-Upsampling entsteht. Wie auch immer, LR ist nach einer solchen Wandlung 16-235.
Will man jetzt ein YUY2-Video in CCE laden, ist alles OK, da der YUY2 und RGB24 lesen kann und die LR für ihn nur bei RGB24 eine Rolle spielt. Anders beim TMPGEnc, der erwartet immer RGB24. Liefert AVISynth ihm das nicht, wird wieder per System-Codec gewandelt, der leichte Fehler erzeugt (Lumashift -2). Daher ans Ende des Scriptes ein ConvertToRGB24(interlaced=true).
LR ist nun wieder 0-255, MPEG benötigt aber 16-235. Also muss man TMPGEnc in den CCIR-Modus bringen (Standardeinstellung), der die Kompression des LR selbstständig vornimmt. Dann stimmt alles.
Kommen wir jetzt zu Codecs, die RGB24 liefern können, dabei aber die Luma-Range NICHT anpassen. Dann würde 16-235 geliefert und im CCIR-Modus von TMPGEnc das auf 32-219 komprimiert werden. Für diesen Zweck hat TMPGEnc den YCbCr-Modus, der die Luma-Range nicht ändert aber voraussetzt, dass ihm alles korrekt geliefert wird.

Man sieht schon daran, dass die Encoder zwar fast alle die Möglichkeit haben, eine Luma-Range anzugeben, diese Funktion aber jeweils völlig unterschiedlich arbeitet.

Insgesamt gibt es also zwei mögliche Fehlerquellen, und es liegt nich an uns, den Anwendern, die zu beseitigen, sondern bei den Herstellern, die sich anscheinen einen Dreck drum scheren, was ihre Programme so tun. Wir können höchstens solche Macken in Erfahrung bringen und nach Möglichkeiten suchen, sie zu umgehen, um die bestmögliche Qualität zu erhalten.

Sorry Leute, aber DIESE Art der Beschäftigung mit der Materie erscheint mir sehr viel sinnvoller als irgendwelche Encoder-Tests.

@all:

Es mag verschiedene Wege gehen einen Encoder beurteilen zu wollen. Um es mal mit einem Auto zu vergleichen:

1. Es gibt die Möglichkeit, anhand der Auftstellung mehrerer Kräftediagramme, einbezüglich des Reifenprofiles, des Luftdruckes, der Asphaltoberfläche, des Seitenwindes, der relativen Luftfeuchte und der Religionszugehörigkeit des Testfahrers zu berechnen mit welcher Geschwindigkeit man eine Kurve auf der Ideallinie mit welchen Fahrzeugen theoretisch befahren könnte.

2. Es gibt die Möglichkeit, die Kurve mit unterschiedlichen Fahrzeugen zu befahren.

Es ist zwar interessant zu wissen, weshalb die Steifigkeit der Karkasse den Anpreßdruck in der Reifenmitte verändert und in welcher Weise dieses den Bremspunkt, die Winkelgeschwindigkeit und den Verlauf der Ideallinie bei einem katholischen Testfahrer verändern könnte - allein, es hilft mir nicht zurück auf die Straße!

Ich habe die Kurve mit unterschiedlichen Fahrzeugen bei vorgegebenen Parametern befahren (bzw. befahren lassen). Nun ist es an Euch die Ergebnisse zu interpretieren. Es bringt absolut nichts, darüber zu philosphieren, was gewesen sein könnte und sich über die Unfähigkeit der Autohersteller zu ereifern. Zeigt ob Ihr besser fahren könnt und wir werden versuchen, Eure Fahrkünste analysieren.

All denen, die sich nicht hinter Steuer trauen, sage ich: "Si tacuisses, philosophus mansisses".

Mit philosophischen Grüßen
vom Peter

@Ikarus
Wieso bitteschön spielt AVISynth für Dich keine Rolle? Einige haben hier ganz klar gesagt, dass sie es benutzen! Dazu muss man sich nur mal diverse Postings richtig durchlesen - das mal nur als kleine Retourkutsche zu Deinem verbalen Angriff auf Tsunami. Aber weiter im Text: Für Dich ist also eine mögliche Fehlerquelle völlig unwichtig? Und generell zu dem, was ich schrieb: AVISynth war doch nur ein einziges Beispiel, andere hatte ich in beiden Postings genannt. Ich dachte, Ihr beschäftigt Euch hier ernsthaft mit dem Thema Video. Scheint nicht so zu sein.

Peter
Na, das war ja ein tolles Posting... Und so schön am Kernthema vorbei. Ich habe auf mögliche Fehlerquellen beim Encoden hingewiesen und auch aufgezeigt, wie man sie umgehen kann. Wenn das unwichtig ist... Aber um mal Deine eigenen Analogien zu benutzen: Ohne Berücksichtigung solcher Dinge kommst Du erst gar nicht vernünftig auf die Straße. Macht dann keinen Sinn, darüber zu sinnieren, wie man wieder drauf kommt, nachdem man runter geflogen ist. Dazu muss man nämlich erstmal überhaupt fahren können.

Außerdem: Wieso redet Ihr beide ständig über den Encoder-"Test" - das ist doch 'nen ganz anderer Thread!?

B_Racer:

...und wir erwarten immer noch einen praktischen Beweis Deiner theoretischen Fahrkünste....

Mit praktischen Grüßen
vom Peter

Zitat

Hätte Tsunami genau gelesen (daran hapert es merkwürdigerweise immer -
wes des Hirn voll ist, dem fließt der Mund über Großes Grinsen),
wäre er über meinen unübersehbaren Link auf diesen Beitrag gestolpert,
in dem das verwendete, ehedem von mb1 stammende, Script unübersehbar abgedruckt war.

Ich muss dich leider enttäuschen, denn ich habe diesen Beitrag gelesen
und eben deshalb habe ich nachgefragt.
Wegen 'genau lesen' :

Zitat

gereicht per Frameserver Avisynth (warum und wieso s. hier) und deswegen auch 'tff'! Matrix: 'mb1 interlaced'.

Wo steht da etwas von der benutzten Avisynth-Version?
Dieses Script ist ab der Version 2.5.x von Avisynth veraltet,
da der Farbraum beim Öffnen via AviSource nicht mit angegeben wird.

Zitat

Der Einzige, der in diesem Vergleich an irgendeiner Stelle Avisynth eingesetzt hat,
war ich mit meinem ersten, noch in VBR ausgeführten CCE-Encoderversuch!

Beim zweiten Versuch also nicht mehr?
Das hätte man dazu schreiben sollen, denn dann wandelt der bei dir installierte
DV-Codec direkt das DV-Video in den YUY2-Farbraum (sofern du in den misc-Optionen des CCE nichts verstellt hast),
wobei dann deine CCE-Luma-Range-Einstellung von 0-255 völlig irrelevant wird.

Zitat

inwieweit Avisynth 2.5.x ein von der 2.3.x abweichendes Prozedere bei der Farbraumzuordnung erfordert.

Avisynth 2.3.x kenne ich gar nicht, du meinst bestimmt 2.0.x.
Avisynth 2.5.x hingegen öffnet alle Videos im Farbraum YV12, wenn man ihm nicht explizit
einen anderen Farbraum angibt.
Das Script von mb1 ist mittlerweile veraltet, er selber hat ja im DVD-SVCD-Board mal einen
neuen Thread aufgemacht, als er mit der aktuellen Avisynth-Version und dem 601er DV-Video (http://www.vegasforum.de/misc/601/601.zip)
(Luma-Range 0-255 mit Daten im Foot- und Headroom) Probleme bekam.

Beispiele :

0.
AVISource("file.avi")
öffnet das Video im Farbraum YV12.
Sollte das Video nicht im YV12 vorliegen,
dann wird eine Wandlung durchgeführt,
die Fehler verursacht, welche man auch mit
einem Histogramm nachweisen kann.

1.
AVISource("file.avi", true, "RGB32")
öffnet das Video mit Audio (true) im Farbraum RGB32.

2.
AVISource("file.avi", false, "RGB24")
öffnet das Video ohne Audio (false) im Farbraum RGB24.
Diese Version wäre wohl bei Benutzung des Canopus-Codecs und
dem Encoder TMPGEnc bzw CCE zu benutzen,
Um die Luma-Range von 0-255 wieder auf 16-235 zu komprimieren,
müsste man im TMPGEnc dann diese Option benutzen :
[ ] Output YUV data as Basic YCbCr not CCIR601 (nicht angehakt)
Achtung Falle : Der Canopus liefert bei RGB24-Output
nicht expandierte 0-255, andere DV-Codecs expandieren hingegen
möglicherweise die Luma-Range, so das man zwar ebenfalls
0-255 erhält, aber ohne den ehemaligen Foot- und Headroom,
der sozusagen weg-expandiert wurde.

3.
AVISource("file.avi", pixel_type="YUY2")
öffnet das Video mit Audio (true ist default) im Farbraum YUY2.

4.
AVISource("file.avi", pixel_type="RGB32")
öffnet das Video mit Audio (true ist default) im Farbraum RGB32.

Zitat

Ebenso vermag ich den Sinn der Diskussion über den verwendeten DV-Codec
nicht nachzuvollziehen, da das Testmaterial ja von Peter bereitgestellt
wurde (meinetwegen mit dem MS-Codec generiert), und in genau dieser Form
den verschiedenen Encodern zum Futter gereicht wurde. So gesehen hatten alle
Codecs die gleichen Vorsetzungen, und mehr wollte man ja nicht.

Alles anzeigen

Ein MPEG-Encoder versteht aber nunmal kein DV,
man kann ihm DV aber schmackhaft machen, indem man einen DV-Codec benutzt.
Es gibt nunmal aber verschiedene DV-Codecs, die ein und dasselbe DV-Video
unterschiedlich behandeln in bezug auf die Luma-Range,
ein MPEG-Encoder auf einem PC erhält also nicht unbedingt dieselben Daten,
wie derselbe MPEG-Encoder mit demselben DV-Video auf einem anderen PC.

Vielleicht kommt daher auch dein Statement :

Zitat

Ich weiß, der CCE arbeitet im Gegensatz zu manchen anderen etwas farbschwach

Das stimmt nämlich gar nicht.
Der CCE arbeitet in Bezug auf die Farben 'genauso' gut oder schlecht
wie der procoder oder der TMPGEnc, man muss nur überall
in den Verarbeitungsketten PENIBEL darauf achten, das
die Luma-Range nicht verändert wird.

Diese Luma-Range-Fehler könnten auch dieses Statement von Peter
verursacht haben :

Zitat

Der Canopus Encoder setzt anscheinend eigenmächtig einen Farbfilter

Der Procoder setzt keinen Farbfilter.
Sollten die Farben bzw der Kontrast nicht 'passen',
dann hat ein Codec oder eine falche Einstellung im Encoder den Luminanz-Bereich
verändert.

Beim TMPGEnc steht im Ergebnis 'deutliches pumpen'.
Das macht der TMPGEnc aber nicht immer bzw man kann es ihm abgewöhnen.

Ich will hier keinen Streit entfachen, sondern euch nur mal auf dieses
Problem hinweisen, das unbestreitbar eine Fehlerquelle ist
und hier offenbar nicht beachtet wird.
Das hat auch gar nichts mit Wichtigtuerei zu tun,
sondern mit glasklar _nachvollziehbaren_ Einstellungen.
Im Übrigen sagen die Rechenzeiten nichts aus, wenn man nicht gleichzeitig auch
die verwendete Hardware mit angibt,
was auf der Testseite (http://www.videofreunde.ch//thread.php?threadid=4699&sid=)
nicht zu sehen ist.
Dieser Test steht in einem öffentlichen Diskussionsforum
und daher finde ich es legitim, das Kritik geübt wird.

farbenfrohe Grüße von
Tsunami

Tsunami:

Ich verstehe den Sinn diese Geplänkels nicht. Ich habe wiederholt angeboten daß jeder, der vermeintliche Fehler entdeckt haben will, dieses jederzeit durch die Bereitstellung eines Testfiles in dem diese Fehler abgestellt sind, korrigieren kann.

Eine Theorie ist gut und wichtig aber sie taugt nichts wenn sie nicht in der Praxis nachvollzogen werden kann.

Die Argumente werden durch ständige Wiederholung nicht besser. Nur anschauliche, praktisch nachvollziehbare und sinnvolle Beweisführung kann uns hier weiter helfen. Bis jetzt seid Ihr beide (B_Racer und Du) die Beweise schuldig geblieben, was mich vermuten läßt daß es an der praktischen Umsetzung der Theorie noch ein wenig hapert. Es böte sich doch an, meine Befürchtungen mit einem oder mehreren praktischen Beweisen zu entkräften.

Natürlich ist dieses ein öffentliches Forum und natürlich stellt sich jeder, der hier postet, der öffentlichen Kritik - auch der Kritiker! Da muß man sich schon mal den Vorwurf gefallen lassen daß man den Beweis schuldig geblieben ist - so lange man ihn nicht erbringt.

Mit kritisch-vorwurfsvollen Grüßen
vom Peter

P.S.
Die Kritik bezüglich der Rechenzeiten ist natürlich richtig. Wird nachgetragen, soweit bekannt.

Zitat

Bis jetzt seid Ihr beide (B_Racer und Du) die Beweise schuldig geblieben, was mich vermuten läßt daß es an der praktischen Umsetzung der Theorie noch ein wenig hapert.

Das liegt daran, das ich nur ein Modem besitze und bisher noch nichtmal dein DV-Video komplett runtergezogen bekommen habe, weil sich noch Einiges mehr in meiner Download-Liste befindet.
Sobald ich das Video komplett habe werde ich es enkoden und irgendwo hochladen.

Tsunami:

Macht nichts, der Thread läuft niemandem davon und Qualität ist wichtiger als Geschwindigkeit.

Viele Grüße
vom Peter

Edi:

Zu spät, Edi - viiieeeel zu spät!

Viele Grüße
vom flinken Peter

Na und ich brauche nichts zu beweisen. Ich habe auf Fehlerquellen aufmerksam gemacht. Wie Ihr die Infos nutzt, ist absolut Euer Problem.
Ich kann Euch nur die Tür zeigen, durchgehen müsst Ihr selber.

Ich finde es nur hochgradig interessant, dass darauf nicht eingegangen wird. Und wie gesagt, der Encoder-Test interessiert mich doch überhaupt nicht.

Den würde ich z.B. auch nicht nur an einem Video durchführen, sondern auch an geometrischen Figuren, am besten auch gleich noch an Grundfarben-Clips. Da sieht man direkt - sogar mit bloßem Auge - was passiert. Natürlich würde das nicht genügen, richtige Videos gehören zum Test auch dazu.

Zitat

und wir erwarten immer noch einen praktischen Beweis Deiner theoretischen Fahrkünste..

Ist Dein Forum, dann mach' auch den Anfang.
Außerdem siehe oben, meine Aussagen bezüglich der Luma-Range kann jeder ganz leicht selbst überprüfen. Und zwar speziell für sein eigenes System.

B_Racer:

Bist anscheinend doch kein Philosoph - gelle ?

Viele Grüße
vom Peter

Noch eine Anmerkung :
Ich habe mir das MSP701-CBR_8500-WMV9.avi angeschaut, zu dem du schreibst :

Zitat

Der in MSP integrierte Encoder scheint eigenmächtig die Konturen zu betonen.

Für mich sieht das eher danach aus, als ob da jemand die Interlace-Einstellungen zerhauen hat.
Im Differenzbild sieht man dann genau dort, wo Bewegung stattfindet einen Unterschied zwischen Original und dem um eine Zeile verschobenem MPEG.

Tsunami:

Das ist möglich. Dazu kann ich nicht viel sagen da ich das File nur von Ikarus übernommen habe. Ich selbst kann mich mit dem CCE wegen seiner unmöglichen (Un)Bedienbarkeit nicht anfreunden.

Halt, Stop, das war ein freudscher Verleser!
MSP habe ich ja selber verbrochen - werde ich überprüfen!

Viele Grüße
vom Peter