Angepinnt Rendergenerationen

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Ich glaube nicht wirklich daran, dass es an den TIFFs hängt, auch wenn das nicht unbedingt auszuschließen ist. Ich habe auch nochmal die TIFFs in einem Graphikprogramm analysiert. Dort haben sie genau das gleiche Farbverhalten wie in Vegas.

      Dass es in irgendeiner Weise mit dem MPEG-Decoding zusammenhängt, scheint mir wahrscheinlicher.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Marco ()

    • Na gut, aber demnach wäre ja beim Encoden des m2t Originalmaterials die Ausgabe mit dem falschen Farbraum eingestellt gewesen. Ok, dass müßte halt mal Harald und Uwe überprüfen.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Wäre der Fehler beim Encoding entstanden, dann müsste Harald auf dem eigenen System die Differenzen zwischen Original und Intermediate, bzw. zwischen Original und TIFFs sehen. Da dem nicht so ist, glaube ich eher, dass es am Decoding liegt. Sei es nun bei Vegas oder bei Edius.
    • Ja, das können wir offenbar nichtg ausschließen.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Ich konnte eben erstmals das original Teppich-m2t gegen die Intermediate-TIFFs in Liquid (6.1) vergleichen. Es ist dort genau der gleiche Farbshift zu sehen wie auch in Vegas. Ich muss nur in Liquid die Vorschau auf Vollbild umschalten, damit es auch deutlich ist. Dann sehe ich z.B. aber auch, dass es nicht nur die Farbe Rot betrifft, sondern auch Grün und Blau. Irgendwie dreht sich scheinbar der komplette Farbwinkel ein wenig im Uhrzeigersinn mitsamt einer leichten Pegelreduktion.

      Muss zwar noch nichts heißen, aber nachdem das nun auf einem anderen PC mit Liquid auch sichtbar ist, kommen mir Zweifel, dass es an Vegas liegt. In Liquid wird wieder ein ganz anderer MPEG-Decoder genutzt.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Marco ()

    • Für die Farbprüfer:
      Noch mal der gleiche Frame mit EDIUS als tif und (deutlich schlechteres) jpg aus dem originalen m2t exportiert:

      rapidshare.de/files/31478478/Teppich-0017m2t.tif.html




      Original von Marco
      Nochmal kurz zur Veranschaulichung (kann die Bilder nicht allzulange auf meinem Server lassen). Das ist der Farbdrift, den ich bei mir zwischen dem Original HDV und dem TIFF vom HQ-Intermediate sehe:



      Bezogen auf die wirkliche rote Farbe des mittleren Bereichs im Teppich könnte die Wahrheit tatsächlich näher an der helleren Version liegen. Mal sehen, was EDIUS Pro 4 daraus macht.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Harald ()

    • Danke für die Mühe.

      Das Problem bleibt. JPEG und TIFF sind im Farbraum soweit identisch und beide haben die gleiche Abweichung gegenüber dem original m2t - in Vegas begutachtet.

      Also speziell am TIFF liegt es vermutlich nicht.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Marco ()

    • Original von wolfgang
      - aber weiterentwickelt. Die NLEs werden besser. Die Encoder und Decoder werden besser.

      Ich wollte noch mal auf die technischen Unterschiede beim Rendern mit Intermediates und native Material zurückkommen.

      Es ist doch so, daß bei der Umwandlung von m2t zu avi ein File mit I-Frame only und höherem Farbsampling errechnet wird, dem man die besseren Editiermöglichkeiten zuschreibt. Dabei wird aus der m2t GOP Struktur ja jeder neue I-Frame errechnet und im Intermediate abgespeichert.

      Nun kann man aber, besonders unter Nutzung der gestiegenen Rechleistung der CPUs und verbesserten SW, genau diese Errechnung von I-Frames auch während des Renderprozesses als Input für den RenderFilter durchführen. Da ist technisch absolut kein Unterschied. Ganz entscheident wichtig für den Output des native Renderergebnisses ist die Qualität des benutzen MPEG2 Decoders. Wer sich da mal einen Überblick über die z.B. vom Mainconcept Decoder angebotenen Output Formate machen will, soll mal in Graphedit dessen PropertyPage anzeigen lassen. Da findet man neben RGB32 auch YUY2, YV12 und UYVY in deren Farbräumen dann gerechnet werden kann.
      LG
      Peter
    • Fortsetzung von oben.
      Jetzt die m2t Renderkette (HDV HD-2 Mode, 50 System, Mastering Quality):

      Aus dem originalen m2t aus der Timeline von EDIUS
      - "spiegeln um Vertikalachse" - neurendern mit ProCoder 2 in eine m2t-Datei
      - "spiegeln um Vertikalachse" - neurendern mit ProCoder 2 in eine m2t-Datei
      - "spiegeln um Horizontalachse" - neurendern mit ProCoder 2 in eine m2t-Datei
      - "spiegeln um Horizontalachse" - neurendern mit ProCoder 2 in eine m2t-Datei.
      rapidshare.de/files/31567098/Teppich-0017_SuH2m2t.tif.html



      Das Endergebnis fällt in der Qualität sehr deutlich von meiner ersten Renderkette ab, ist aber für viele Fälle sicher nicht unbrauchbar. Die Qualität ist grob mit der von anderen Teilnehmern hier gezeigten vergleichbar. Dort wurde aber das gleiche Material mehrfach neu gerendert, ohne in jedem Zwischenschritt verändert worden zu sein. Der hier gewählte Testablauf sollte härter sein.

      Das Resultat zeigt mir auch, warum ich möglichst maximal bei der 1. m2t Rendergeneration bleiben sollte. Wenn es darüber hinausgehen oder viel geschnitten werden muss: Über den HQ Codec geht alles sehr viel schneller und die Qualität bleibt nahezu unangetastet. Nur der Platzbedarf ist deutlich größer.

      Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von Harald ()

    • "Dort wurde aber das gleiche Material mehrfach neu gerendert, ohne in jedem Zwischenschritt verändert worden zu sein."

      Weiß nicht, wie das die anderen machen. Aber ein Rendertest ohne Bildveränderung bei jeder Generation wäre für mich kein normaler Rendertest. Bei mir wird für einen Standardtest für jede Generation ein Pixelshifting erzeugt, einmal hin und einmal her. Das stresst in der Regel jeden Encoder, ist aber - wie immer - auch ein wenig abhängig vom Bildinhalt.
      Ist eben die Frage, was man in diesem Bezug als "normal" oder "Standard" betrachten würde. Ich denke, meist ist das ein "Worst Case"-Szenario und dafür ist eine Bildveränderung in jeder Generation absolute Grundbedingung.

      Je nachdem, wie man das "richtige" Rendering erzwingt, varriieren aber die Resultate tatsächlich. Das hat u.a. auch damit zu tun, dass unterschiedliche Filter und Effekte unterschiedliche Qualitäten haben, aber auch mit der Analysetechnik der Encoder.
      Deshalb mache ich für Tests, die für mich wirklich praxisrelevant sind, auch immer noch Renderprozesse, die sich möglichst genau an dem orientieren, was auch in meinem tatsächlichen Arbeitsauflauf passieren würde, sofern das einigermaßen vorausschaubar ist. Hier kann es dann schon auch sein, dass mal eine Generation ohne Bildveränderung dazwischensteckt, aber in dem Fall muss das dann auch so sein, damit ich mir ein möglichst adäquates Bild von den tatsächlichen Veränderungen machen kann.

      Ich glaube aber eh, dass man sich Rendertests meist eher an den Hut stecken kann ...
    • Für die jenigen, die nicht das DirektX SDK installiert haben hier mal die Ausgabeformate des MainConcept MPEG2 Decoders bei m2t Input:
      Major Type: Video - Sub Type: UYVY - Format: UYVY 1440x1080, 16 bits,
      Aspect Ratio: 16x9,
      Interlace format: Weave Only
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: RGB32 - Format: RGB 1440x1080, 32 bits,
      Aspect Ratio: 16x9,
      Interlace format: Weave Only
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: RGB24 - Format: RGB 1440x1080, 24 bits,
      Aspect Ratio: 16x9,
      Interlace format: Weave Only
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: RGB565 - Format: BITF 1440x1080, 16 bits,
      Aspect Ratio: 16x9,
      Interlace format: Weave Only
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: RGB555 - Format: BITF 1440x1080, 16 bits,
      Aspect Ratio: 16x9,
      Interlace format: Weave Only
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: YUY2 - Format: YUY2 1440x1080, 16 bits
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: UYVY - Format: UYVY 1440x1080, 16 bits
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: RGB32 - Format: RGB 1440x1080, 32 bits
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: RGB24 - Format: RGB 1440x1080, 24 bits
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: RGB565 - Format: BITF 1440x1080, 16 bits
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: RGB555 - Format: BITF 1440x1080, 16 bits
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: YV12 - Format: YV12 1440x1080, 12 bits,
      Aspect Ratio: 16x9,
      Interlace format: Weave Only
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)
      Major Type: Video - Sub Type: YV12 - Format: YV12 1440x1080, 12 bits
      rcSrc=(0,0,1440,1080)
      rcDst=(0,0,1440,1080)


      Wer mehr zu den dazu gehörigen Farbräumen lesen möchte findet vielleicht hier etwas dazu. Die Auswahl wird von der Anwendung, die den Graphen aufbaut bzw. dem angeschlossenen Filter bestimmt. Beim 'intelligent connect' wird YUY2 für den VMR-7 Renderer gewählt, der den Output dann an den Grafikkarten-Treiber weitergibt.
      MEDIASUBTYPE_YUY2 YUY2 (packed 4:2:2)
      LG
      Peter

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von elCutty ()

    • Für diejenigen, die aus diesem Post noch nicht recht Schlüsse ziehen konnten. Es ist der Beweis dafür, daß mit dem MPEG2 Decoder aus dem .m2t Material mindestens genau so gute I-Frames zur Verfügung gestellt werden, wie sie aus zuvor erzeugten Intermediates kommen könnten (eine sehr hohe Bitrate vorausgesetzt). Die Frames aus den Intermediate haben aber den Nachteil, daß sie ja erneut kompremiert und abhängig von der benutzten Bitrate schlechter sind als die direkt aus dem m2t Material erzeugten. Dies zeigt sich auch ganz besonders in dem von Wolfgang gezeigtem 'Weichzeichnen' bei den Inetrmediates.
      LG
      Peter
    • Ist die Bitrate von HDV2 deines Erachtens nach ausreichend hoch, um gute I-frames zur Verfügung zu stellen? Meine Erwartung wäre, dass dem wohl so sein sollte.

      Ich möchte aber auch noch - etwas verspätet - auf diesen Punkt von Marco eingehen:

      Je nachdem, wie man das "richtige" Rendering erzwingt, varriieren aber die Resultate tatsächlich. Das hat u.a. auch damit zu tun, dass unterschiedliche Filter und Effekte unterschiedliche Qualitäten haben, aber auch mit der Analysetechnik der Encoder.
      Deshalb mache ich für Tests, die für mich wirklich praxisrelevant sind, auch immer noch Renderprozesse, die sich möglichst genau an dem orientieren, was auch in meinem tatsächlichen Arbeitsauflauf passieren würde, sofern das einigermaßen vorausschaubar ist.


      Das ist exakt die Problematik eines jeden Tests. Wir wählen eine Testanordnung, ein Testbild, ein Testvideo, Renderparameter, wir wählen die verwendete NLE - und testen. Und diese Testanordnung entscheidet ganz massiv über die Ergebenisse, und natürlich deren Interpretation.

      Das Problem dabei ist nicht mal nur, dass dies so ist; sondern, dass es dazu keine universelle Lösung gibt. Mir erscheinen die Pixelshift-Ansätze oder auch die Spiegelansätze halt auch nicht sonderlich realitätsnahe - ich verschiebe im Regelfall keine Pixel beim Schnitt, und Spiegeln braucht man auch eher selten. Das sind ideals tool, um Rendern zu erzwingen - was auch sein soll. Aber nicht mehr. Ich behelfe mir gerne mit dem Setzen von kleinen Punkten - bei den Intermediates etwa, weil die sonst smartrendern. Bei den m2t zu m2t Rendertests habe ich sogar gar keine Bildveränderungen gesetzt - weil ich weiß, dass Vegas nicht smartrendert, und mir das einfache Umrendern mal hier völlig ausreicht.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Original von wolfgang
      Ist die Bitrate von HDV2 deines Erachtens nach ausreichend hoch, um gute I-frames zur Verfügung zu stellen?

      Das ist sicher auch eine Frage der Art und Stärke von Bewegungen im Video. Solange wir aus den Camcordern HDV2 Material bekommen ist IMHO die stärkste 'Einschränkung' das anamorphe Format, das mich bei DV-Auflösung schon geärgert hat. Aber besser als das was und als m2t File vorliegt kann ein Intermediate, egal mit welcher Bitrate, eben nicht sein. Entscheidend für jeden Renderprozess ist schließlich auch die Güte des Decoders, denn erst der decodierte Frame wird ja weiter verarbeitet.
      LG
      Peter
    • Pixelshifting ist meines Wissens überall dort, wo in der "Industrie" Rendertests gemacht werden, fast schon ein Standard. Auch bei Qualitätsanalysen der EBU wird immer wieder das Pixelshifting als Grundlage für Rendertests eingesetzt. Von daher ist diese Methode zumindest nicht exotisch.
      Dass diese Methode nicht unbedingt die tägliche Schnittpraxis ist, ist klar (aber so fern ist es auch nicht, denn eine jede Bildskalierung, Pans, Mirror etc. sind im Grunde nichts anderes). Deswegen wende ich - wie ich oben ja erwähnt hatte - in betreffenden Fällen auch noch zusätzlich einen Test, der sich relativ genau an die Arbeitsgänge hält, die für mich auch tatsächlich anfallen. Punkte zu setzen wäre für mich auch selten praxisnah, da ich z.B. selten mit Titeln arbeite.
      Im Grunde genommen müsste zumindest, wenn verschiedene Leute einen Rendertest durchführen, immer auch die gleiche Methode benutzt werden, um das Rendering zu erzwingen.

      Was aber gar nicht zu vergleichbaren Ergebnissen führen kann, das ist, wenn du tatsächlich den einen Codec (Intermediate) mit irgendeiner Art von Bildveränderung arbeiten lässt, gleich welcher, und den anderen (MPEG) dann ganz ohne. Ein solcher Test verliert die Aussagekraft, selbst wenn es u.U. sein könnte, dass danach die Encoder in ähnlicher Weise beansprucht werden. Halbwegs vergleichbare Ergebnisse gibt es nur dann, wenn auch immer exakt die gleiche Umgebung gewählt wird und nicht bei dem einen Codec die eine und bei dem anderen eine andere.

      Ich verstehe auch die Aussage(n) von elCutty nicht recht. Natürlich erzeugt das MPEG-Rendering auch "solide" I-Frames, wenn denn tatsächlich gerendert wird. Wäre dem nicht so, dann würde der Encoder nicht richtig arbeiten.

      "Die Frames aus den Intermediate haben aber den Nachteil, daß sie ja erneut kompremiert "

      Das macht mich in Bezug auf die bisher hier diskutierten Rendertests stutzig, denn ich gehe davon aus, das wir "echte" Rendergenerationen vergleichen und nicht eventuell ein Smartrendering mit normalem Rendering und auch nicht, wie oben schonmal angeführt, einmal ein Rendering mit Bildveränderung und einmal ein Rendering ohne Bildveränderung. Sonst wäre das ja immer ein Äpfel-mit-Birnen-Vergleich. Und in jedem anderen Fall komprimiert auch MPEG immer wieder neu.

      "Dies zeigt sich auch ganz besonders in dem von Wolfgang gezeigtem 'Weichzeichnen' bei den Inetrmediates."

      Genau dieses Weichzeichnen habe ich in meinen Rendertests nicht (oder zumindest viel weniger) bei den Intermediates, sondern beim MPEG.

      Ich sag's ja - Rendertests ... :gruebel:

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Marco ()

    • Natürlich erzeugt das MPEG-Rendering auch "solide" I-Frames

      Es geht zunächst mal gar nicht ums Rendern sondern um den vom Decoder zur Verarbeitung vorgelegten Inputframes. Diese können nach dem Gezeigten nur besser sein als der Intermediate Input. Das Rendern ist eine zweite Stufe und unterscheidet sich beim YUY2 Format nicht voneinander.

      "Die Frames aus den Intermediate haben aber den Nachteil, daß sie ja erneut kompremiert "
      Das Zitat muß weiter heißen " als 1. Input benutzt werden." Sicher wird in beiden Fällen abschließend erneut kompremiert. Was da besser ist, hängt sicher von der gewählten Bitrate der Intermediates und den Inhalten (Bewegung oder still) ab.
      LG
      Peter
    • Also ich sagte schon früher: die Intermediate codecs muss man durch einen wie auch immer gearteten Bildeingriff zum rendern zwingen - sonst kommt es zu reinem Umkopieren/Smartrendern.

      Das geschah in meinen Tests durch das Setzen von Punkten mit dem Textgenerator. Und zwar in allen Intermediates oder Kandidaten dafür - egal, ob Cineform, Canopus HQ oder dem mjpeg-PIC. Für jede zusätzliche Generation wurde rechts unten im Bild ein weiterer Punkt gesetzt, damit ja jede Generation gerendert wird. Sieht man auch an den Punkten in den png-Bilder rechts unten.

      Für mpeg - nun, du sagst ja selbst:

      Und in jedem anderen Fall komprimiert auch MPEG immer wieder neu.


      Für die m2t zu m2t Rendertests ist daher ein Rendern ohne Bildeingriff zur Anwendung gekommen - und zwar einfach deshalb, weil wir ja wissen, dass Vegas m2t zu m2t immer neu encoded.

      Es geht am Ende des Tages nur darum, dass sichergestellt ist, dass wirklich neu encoded wird.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Original von Marco
      Genau dieses Weichzeichnen habe ich in meinen Rendertests nicht (oder zumindest viel weniger) bei den Intermediates, sondern beim MPEG.


      Das habe ich auch besonders beim Canopus HQ codec gesehen - und den hast du aber nicht getestet, oder?
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • "Es geht am Ende des Tages nur darum, dass sichergestellt ist, dass wirklich neu encoded wird. "

      Das sehe ich anders. Wenn man zwei verschiedene Codecs in ihrem Renderverhalten vergleichen möchte, dann kann nicht jeder der Codecs in irgendeiner Weise zum Rendern gezwungen werden, sondern dann muss das unbedingt in gleicher Weise geschehen. Jeder andere Weg kann u.U. auch andere Ergebnisse hervorrufen. Es macht für den Encoder - und somit auch für die Qualität des Endresultats - durchaus einen Unterschied, ob am Bild etwas verändert wurde, ob eventuell jeder Pixel in einer bestimmten Art verändert wurde, ob Farbe und Licht verändert wurden, ob Formen verändert wurden, ob an einigen Stellen neue Bildelemente hinzugefügt wurden oder ob gar nichts verändert wurde. Die Bilder, genauer gesagt die Makroblocks der Bilder, werden ja vom Encoder zunächst analysiert und anhand dieser Analyse werden für unterschiedliche Bildbereiche auch unterschiedliche Quantisierungstabellen genutzt. Wenn ein Bild von Generation zu Generation nicht verändert wird, dann sind es für jeweils gleiche Bildbereiche immer die gleichen Quantisierungstabellen. Wenn ein Bild aber verändert wird, dann werden an manchen Stellen von Generation zu Generation andere Quantisierungstabellen genutzt. Somit kann es dann auch zu unterschiedlichen Renderergebnissen kommen, je nachdem, was an einem Bild verändert wird oder nicht.

      "Das habe ich auch besonders beim Canopus HQ codec gesehen - und den hast du aber nicht getestet, oder?"

      Nein, Canopus HQ steht mir nicht zur Verfügung. Da kann ich mich nur auf das berufen, was Harald gezeigt hat. Und wenn ich da mal diesen Colorshift ausser Acht lasse, weil ich bezweifle, dass wir nachvollziehen können, warum dieser Shift auftritt, dann zeigt sich bei Canopus HQ als Intermediate der Vorteil für das Intermediate auf jeden Fall noch deutlicher als bei den Cineform-Intermediates.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Marco ()