Angepinnt Rendergenerationen

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

    • Da stoßen dann eben wieder mal zwei Meinung aufeinander, die keinen Konsens finden wollen/werden.

      "Bei einem solchen Test kann es leicht sein, daß man eher die Wirkung dieser Filters als die des Renderers/Encoders testet."

      Zum einen sich das leicht überprüfen lässt, indem man zuerst einen Rendertest über ein unkomprimiertes Format voranstellt. Dort zeigt sich, was allein der Filter verursacht.
      Zum anderen geht es darum, welcher Codec letztlich im Vergleich ein besseres Resultat liefert. Das bleibt in der Relation immer gleich, egal welcher Filter verwendet wird, sofern nur bei jedem Codec auch der gleiche mit gleichen Einstellungen verwendet wird.

      "Entscheidend für einen RenderTest ist IMHO, daß der Renderer auch wirklich rendert"

      Dieser Punkt wurde in dem Thread ja nun schon mehrfach aufgegriffen. Wäre natürlich eine machbare Testmethodik, aber nur dann, wenn dann auch beide verglichene Codecs auf diese Weise behandelt werden. Wenn das mit einem der beiden Codecs nicht machbar ist, dann muss, damit das Ganze vergleichbar bleibt, eine andere Methode gewählt werden.
      Ob das aber praxisnah und aufschlussreich ist - das wage ich zu bezweifeln, zumindest für meine Praxis. Wenn der Fall des Renderns ohne Filter eher die Ausnahme ist, dann ist auch der Test mit dieser Methodik nicht o.k.

      Mir bleibt das hier irgendwie alles viel zu theoretisch. Mein Tipp ist: Rendert und testet das, was bei Euch in der täglichen Praxis auf den Tisch, bzw. in die Timeline kommt und nicht das, was zuerst vorher theoretisch konstruiert werden muss. Allein das zählt am Ende.
      Wenn dagegen aus irgendeinem Grund unbedingt ein echter Stresstest gemacht werden soll, dann kann der nicht ohne Bildveränderungen gemacht werden, auch nicht mit nur einem Bildmotiv.

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

    • Original von Marco
      Das bleibt in der Relation immer gleich, egal welcher Filter verwendet wird, sofern nur bei jedem Codec auch der gleiche mit gleichen Einstellungen verwendet wird.

      Genau das stimmt eben nicht, denn wenn die durch den Filter hervogerufenen Verluste deutlich höher sind als die durch den Encoder kann man damit keinen Vergleich der Encoder anstellen. Wie wir wissen gibt es gerade beim Skalieren (z.B. HDV ->DV) erheblichen Einfluß durch eben diesen Vorgang. Die Tatsache, daß du Wolfgangs Resultate bezüglich des m2t Renderns nicht so sehen konntest liegt möglicherweise genau daran, daß die Wirkung des Filters auf den Output bei dir stärker ist als die Wirkung des Encoders. Ich halte es schon für wichtig sich Gedanken über den internen Ablauf und die Datenwege zu machen, wenn man so einen Test machen möchte. Sonst kann man leicht falsche Schlüsse ziehen.
      LG
      Peter

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

    • "wenn die durch den Filter hervogerufenen Verluste deutlich höher sind als die durch den Encoder kann man damit keinen Vergleich der Encoder anstellen."

      Doch, denn genau das entspricht auch der gängigen Praxis. Aber dass z.B. die Verluste durch Pixelshifting höher wären als durch den Encoder, dem ist nicht so.

      Ist ja o.k. wenn sich Leute darüber tiefgehendere Gedanken machen. Aber dennoch darf es dann nicht sein, dass der eine Encoder auf die eine Art benutzt wird, der andere aber auf eine ganz andere Art.
      Und gleich welche theoretischen Zusammenhänge dabei von dem ein oder anderen dabei berücksichtigt werden können, so zählt letztlich trotzdem nur die Praxis. Ich kann mir nicht einreden lassen, dass etwas theoretisch irgendwie sein muss, wenn ich das in meiner konkreten, praktischen Arbeit immer wieder anders erfahre.
      Wenn nun mal jemand beispielsweise diverse Filterungen über mehrere Generationen machen muss und sich dabei die Verwendung eines bestimmten Intermediates als qualitativ vorteilhaft herausgestellt hat, dann nützt es nicht viel, wenn in einem konstruierten Test ohne jede Bildveränderung eventuell auch das m2t-Format den Generationen qualitativ standgehalten hätte.

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

    • Aber dass z.B. die Verluste durch Pixelshifting höher wären als durch den Encoder, dem ist nicht so.

      Muß aber wohl doch so sein, denn du siehst damit ja schon in der ersten RenderGeneration bei m2t einen Unterschied, der bei Wolfgang und mir nicht sichtbar wird.


      Vielleicht sollten wir einfach mal auf die neue Vegas Version warten und dann könntest du ja mal einen 'praxisrelevanten' Testsetup für die Encoder definieren, bei der nach dem von dir Geschriebenen aber auch das Inputmaterial festgelegt sein müßte.

      Fest steht zumindest, daß durch die angekündigten Änderungen im Bereich der HDV Bearbeitung in Vegas 7 die Testresultate von Wolfgang nicht unbedingt ihre Gültigkeit behalten müssen.



      Ich kann mir nicht einreden lassen, dass etwas theoretisch irgendwie sein muss, wenn ich das in meiner konkreten, praktischen Arbeit immer wieder anders erfahre.

      Jedem steht doch frei, den Weg zu gehen den er für den richtigen hält. :beer:
      LG
      Peter
    • Vielleicht sollte man mal diesen Thread zusammenfassen - und sich darauf besinnen, was der Ausgangspunkt war. Ich wurde nämlich von dritter Seite darauf aufmerksam gemacht, dass dieser Thread bei mitlesenden Vertretern aus der Industrie Kopfschütteln verursachen würde.


      Der Ausgangspunkt des Threads war eigentlich die doch immer wieder kehrende Frabe, ob "man" HDV-m2t-Material zumindestens fallweise auch nativ schneiden kann - oder aber ob das ein absolutes No-Go ist.

      Neu ist die Frage ja nicht. Wir hatten sie schon früher besprochen, hatten schon früher Vor- und Nachteile abgewogen. Einer der ersten umfangreicheren Threads zu diesem Thema findet sich ja hier - und wurde vor fast einem Jahr hier gestartet, wohl als einen der ersten Threads zu diesem Thema überhaupt im deutschsprachigen Raum:

      LINK

      Und bereits damals hatten ich in sogar quantitative Findings eines klar belegt: jegliches Umrendern von m2t Material ist mit einem messbaren Qualitätsverlusten verbunden. Und zwar egal, ob man nun m2t zu m2t rendert, oder m2t zum Intermediate Files (LINK).

      Nur hatten diese damaligen Tests den Aspekt, dass die Quantifizierung der entstehenden Qualitätsverluste für viele Leute zuwenig greifbar waren. Eine Kritik war daher, dass man die Renderergebnisse auch sehen wolle - und daher wurde hier mal eher qualitativ (und auch subjektiver) in Form von anschaubaren Bildern gearbeitet. Sind den die bereits früher gemessenen Qualitätsverluste überhaupt sichtbar, wurde ich öfters gefragt? Es könnte ja sein, dass man die zwar messen, aber kaum sehen könne - oder sieht man sie doch? Nun, darauf hatten wir damals keine Antwort gegeben, und daher wurden hier mal Bilder gepostet.

      Die Frage, um die es geht, ist einfach: wenn man m2t nativ schneidet, sieht man das? Soll man es daher tun, oder eher nicht? Fragen, die sich jedem engagierten HDV-Videoamateur einfach stellen, noch dazu, als die Industrie hier ja auch die unterschiedlichsten Lösungen anbietet.

      Konnte die - scheinbar einfache - Frage, ob man nun in Intermediates arbeiten soll, oder zumindest in bestimmten Situationen doch natives m2t Material schneiden kann, aber beantwortet werden? Meine Antwort darauf ist eher ein klares Nein.

      Warum ich das glaube? Nun, die hier gezeigten Tests waren wenig normiert, untereinander in Folge zu wenig untereinander vergleichbar. Ich glaube zwar, dass die Tests, die ein Einzelner von uns gemacht hat, in sich vergleichbar ist. Aber die Beurteilung und der Vergleich von verschiedenen Tests erfolgt sicherlich auf unterschiedlichen Sichtgeräten - geht nicht anders. Das Ausgangsmaterial war zu unterschiedlich - statische Bilder versus bewegter Bilder, um ein Bespiel zu nennen. Hochauflösende Detailbilder versus Schwenks im Weitwinkelbereich. Das sind mit Gründe, warum wir hier zu keiner finalen Schlussfolgerung gekommen sind.

      Und es bleiben daher Fragen im Detail offen, wo man nativ schneiden kann und wo nicht - auch wenn es in dieser Frage eine Annäherung an eine höhere Detailierung gab, etwa in den Postings von Marco.

      Bis zu einem gewissen Grad verstehe ich angesichts dieser Punkte, dass die hier geführte Diskussion auch Kopfschütteln bei Dritten auslösen kann. Das sollte alleredings weniger auf die Fragestellung zurückgeführt werden - die halte ich für legitim; sondern eher darauf, dass ein offenes und freies Forum von Amateuren sich halt auch mal eher unstrukturiert unterhalten kann (und auch darf).

      Wer normierte Testergebnisse erwartet, wird dafür Prüfinstitute beauftragen müssen. Oder es machen sich zumindest Leute die Mühe und etablieren normiertere Testbedingungen, als wir es hier tun haben können.

      In Summe erwarte ich mir aber eigentlich von der Industrie auch zu dieser Fragestellung mehr Hintergrundinformation - warum müssen das immer Amateure machen? Etwa dazu: Was leisten die verschiedenen Schnittsysteme wirklich, wo sind die Vor- und Nachteile? Wie hat die Industrie bisher auf die längst erkannt 50 Hz Thematik der Sichtgeräte im PAL-Land geantwortet? Wo bleiben den die HD-DVD/Blue Ray Brenner und Player? In Summe drückt wohl dieser Thread sogar das aus, was uns doch auch die Industrie regelmäßig bei diesem Thema zeigt: nämlich, dass keine einheitliche Vorgangsweise gegeben ist.
      Lieben Gruß,
      Wolfgang
    • "du siehst damit ja schon in der ersten RenderGeneration bei m2t einen Unterschied, der bei Wolfgang und mir nicht sichtbar wird."

      Meine Aussagen waren, dass in der ersten Rendergeneration keine relevanten Unterschiede erkennbar sind. Und in der vierten sind sie erkennbar, gleich welchen der von mir genannten Filter ich verwende.

      Wir drehen uns hier ständig im Kreis.

      "Vielleicht sollten wir einfach mal auf die neue Vegas Version warten und dann könntest du ja mal einen 'praxisrelevanten' Testsetup für die Encoder definieren, bei der nach dem von dir Geschriebenen aber auch das Inputmaterial festgelegt sein müßte. "

      Ich werde mich hüten, sowas jemals nochmal anzugehen. Damit habe ich in der Vergangenheit genügend Zeit verschwendet. Genau darum mein Tipp, Rendertests besser sehr individuell zu halten und wirklich direkt aus einer gegebenen Arbeitssituation heraus durchzuführen.
      Ich möchte mit meinem System arbeiten, nicht Tests konstruieren, die letztlich doch keine Allgemeingültigkeit haben können. Das haben schon viele Leute versucht.

      "Ich wurde nämlich von dritter Seite darauf aufmerksam gemacht, dass dieser Thread bei mitlesenden Vertretern aus der Industrie Kopfschütteln verursachen würde."

      Es würde mich eigentlich wundern, wenn es irgendeinem der hier Mitlesenden anders ergehen würde.

      :D

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

    • Original von elCutty
      ....., bei der nach dem von dir Geschriebenen aber auch das Inputmaterial festgelegt sein müßte.

      Fest steht zumindest, daß durch die angekündigten Änderungen im Bereich der HDV Bearbeitung in Vegas 7 die Testresultate von Wolfgang nicht unbedingt ihre Gültigkeit behalten müssen.


      Jeder ist zunächst mal frei im Festlegen seiner Testanordnung. Und dazu gehört auch das gewählte Testmaterial. In Summe gibt es das "richtige" oder "falsche" Testmaterial nicht - sowas zu behaupten wäre schon ein Präjudiz.

      Aber natürlich sollte man bei einer detailierteren Untersuchung - die den Rahmen zum jetztigen Zeitpunkt zumindest für mich hier sprengt - verschiedene Materialien testen. Im DVDSVCD Forum gabs dazu früher mal das sogenannte Achterbahnvideo für Encodertests. Vielleicht müssen wir mal sowas mit HDV-Material erstellen.

      Zur Meinung, dass sich Testresultate mit Vegas7 sich ändern werden - nun, dazu will ich nur sagen, dass dies vermutlich nicht der Fall sein dürfte.
      Lieben Gruß,
      Wolfgang
    • Original von Marco
      Ich werde mich hüten, sowas jemals nochmal anzugehen. Damit habe ich in der Vergangenheit genügend Zeit verschwendet. Genau darum mein Tipp, Rendertests besser sehr individuell zu halten und wirklich direkt aus einer gegebenen Arbeitssituation heraus durchzuführen.


      Und damit verletzt man erst wieder die Grundprinzipien jeglicher Vergleichbarkeit und Normierung. Und genau das ist die Hauptschwäche dieses Threads - seine Nichtwissenschaftlichkeit im Sinne mangelnder Normierung in Testinput, Testdurchführung und Testauswertung zwischen verschiedenen Testenden.

      Wenn man nicht ein Mindestmass an Normierung will - dann sollte man es tatsächlich lassen, da gebe ich dir schon recht. Aber als jemand, der an Facts and Figures glaubt, erlaube ich mir, auch an normierte Tests zu glauben.



      Ich für meinen Teil stehe daher mal unverändert zu meinen bisherigen Tests - die waren in sich ausreichend normiert.

      Ich akzeptiere in der Sache aber sehr wohl die Notwendigkeit,

      - diese Tests aber auch auf bewegten Bildmotive auszudehnen;

      - dass man mal belegen muss, dass es zwischen blanken Umrendern in der Test-NLE im Vergleich zu massiveren Bildänderungn entweder keine Unterschiede gibt. Oder aber diese doch so beträchtlich sind, dass die Renderergebnisse neu bewertet werden müssen;

      - dass die Bewertungsmethodik noch weiter standardisiert werden muss (oder wieder über Meßwerte gehen sollte).

      Ob mehr wissenschaftlich durchgeführte Tests dann von Interesse sind - wir werden sehen. Im obigen Link hatte ich das ja schon mal gemacht.
      Lieben Gruß,
      Wolfgang
    • Original von Marco
      "Ich wurde nämlich von dritter Seite darauf aufmerksam gemacht, dass dieser Thread bei mitlesenden Vertretern aus der Industrie Kopfschütteln verursachen würde."

      Es würde mich eigentlich wundern, wenn es irgendeinem der hier Mitlesenden anders ergehen würde.

      :D



      Marco - dann sollen sie aus der Rolle der nur mitlesenden Gäste mal heraustreten, und uns sagen und zeigen, wie man es besser macht. Das sehe ich ganz trocken und pragmatisch.
      Lieben Gruß,
      Wolfgang
    • Original von wolfgang
      Ich für meinen Teil stehe daher mal unverändert zu meinen bisherigen Tests - die waren in sich ausreichend normiert.

      Es ging dabei doch wirklich um die pragmatische Frage ob man nun für den größten Teil der Mitglieder dieses Forums ohne Verzicht auf Qualität mit m2t native Schnitt das Ziel erreicht und das haben deine Tests doch endeutig zeigen können. Um so besser wenn sie als Blick in die Zukunft gesehen werden können und nicht bald wiederholt werden müssen ;)
      LG
      Peter

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

    • Aber immer die hier lange diskutierten und erkannten Einschränkungen mal schön beachten... es gibt genug Fälle, wo man Intermediates benötigt. Und nochmals: die Tests waren ja mit einem ruhigen Blumenbild - mit bewegten Material kann das durchaus anders aussehen. Ich würde auch nicht über die 1. Rendergeneration rausgehen wollen.
      Lieben Gruß,
      Wolfgang
    • Wenn bei Qualitätsvergleichen, wo die Unterschiede ohnehin nur mehr in sekündlich wechselnden Differenzbildern erkennbar werden die Beurteilungen dann noch dazu so auseinanderdriften, dann können sich derartige Qualitätsvergleiche m.E. eigentlich nur mehr in einem belanglosen Graubereich bewegen.

      Wie war das eigentlich beim Umstieg von MW auf UKW beim Radio? Hat es überhaupt jemand gegeben, der an dem Qualitätsgewinn gezweifelt hat? Wie war das Erlebnis beim Umstieg von DV auf HD bei fast allen Usern? Hat es letzten Endes da irgend einen Zweifel bezüglich des Qualitätsgewinnes auch bei den standhaftesten Vertretern von DV gegeben?
      Das sind nur zwei Beispiele für wirklich relevante Qualitätssprünge.

      Für mich war die Sache bezüglich HDV-Workflow schnell erledigt. Neurendern von Originalmaterial im Mainconcept-Encoder lieferte bei 2 verschiedenen NLE`s völlig gleichwertige und unerwartet gute Ergebnisse. Aber ich habe auch kein Problem damit, dass für bestimmte Zielsetzungen andere Verfahren zur Anwendung kommen, soll sein, warum nicht?

      Im übrigen interessiert mich recht wenig, was da alles im Hintergrund hard- und softwaremäßig am PC abläuft. Es ist typisch für große Neuerungen, dass man versucht, ihnen auf den Grund zu gehen. Wenn ich mich nur daran erinnere, wie weit ich in Hardwareanalysen bei der Einführung der PC`s im EDV-Unterricht gegangen war und welch binäre Rechenorgien ich mit meinen Schülern aufführte. Aus heutiger Sicht völliger Unsinn. Einen 7-er BMW wird man ja auch nicht mit dem Wissen der technischen Führerscheinprüfung auf der Landstraße reparieren können. Entweder er läuft oder eben nicht.

      LG Helmut
    • Ich grabe diesen Thread hier mal aus, weil es von Sony gerade zu dieser Fragestellung einen interessanten Kommentar im Sony Forum zu Vegas 7 gibt. Die Fragestellung war:


      Subject: RE: Our Thoughts and Impressions of Vegas 7.0
      Reply by: Serena
      Date: 10/13/2006 2:57:28 PM

      Yes, I guess that's the question: how does Vegas handle m2t data? If it does a decode (to 4:2:2 avi?) applies the effects and recodes at render, then I guess should work well. This process appears to be hidden presently. Testing? Yes, good thing to start trying. However I imagine that Madison people already know the answers to such questions, so it seems a pity that users should have to untertake individual valuations.
      The thing is that we are familiar with the results that we were getting with CF and this is a new ball. One where we had been sagely saying "you never edit m2t". Now it seems we do. Good thing if it works. Well I've got a job Monday cutting 2 hours of m2t for a client whose FCP isn't up to the task and he says he wants just cuts and some dissolves, titles and fairly simple stuff. So looks like I'd better run some quick tests and renders. Not having to generate CF intermediates will save a lot of time.


      Und der Kommentar von Sony dazu


      Subject: RE: Our Thoughts and Impressions of Vegas 7.0
      Reply by: ForumAdmin
      Date: 10/13/2006 6:53:51 PM

      If you are doing a render to new track or something similar that requires multiple generations of intermediates , you would be better off using uncompressed (the best option) or some format with less lossy compression for these intermediate renders than long-gop MPEG-2.

      However, you are not going to get _better_ quality that the original source by compressing to any intermediate file first, and then applying fx, and then rendering to your destination format. No matter what the source format is, it gets processed in Vegas as RGB 4:4:4, and from there it gets rendered to the output format you choose (WMV, DV, M2t etc etc).

      It is true you might get a different look by rendering to some compressed intermediate format first (due to dithering or whatnot), but you'll never have a _cleaner_ source than pristine native original file. Compression = data loss- you might not be able to see it in one or even 50 generations but it is occuring, and it does add up.

      Summarizing: If you are rendering to new track, applying fx, rendering to new again, applying fix, rendering to new again, applying fx, and then rendering to output, you are better off using uncompressed, Sony YUV or a visully lossless codec like Cineform for these intermediate steps than you would be if you were rendering to a highly compressed format like HDV m2t for each of these intermediate render steps.

      If you have a timeline with a variety of original sources (m2t included) and you apply fx and titles etc and then you render to your output file, you'll get the cleanest possible result (because you didn't compress in any intermediate steps).


      Quelle
      Lieben Gruß,
      Wolfgang
    • you'll never have a _cleaner_ source than pristine native original file. Compression = data loss-

      Genau so ist es.

      Und das : "No matter what the source format is, it gets processed in Vegas as RGB 4:4:4," wurde hier ja auch schon geschrieben.
      LG
      Peter
    • Zitat:
      ..you are better off using uncompressed, Sony YUV or a visually lossless codec like Cineform for these intermediate steps...

      Im Grunde hat Sony doch genau das geantwortet, worüber wir schon in ausgiebigsten Diskussionen Konsens gefunden hatten. Oder etwa nicht?

      LG Helmut
    • Wer aber mit Intermediate arbeiten möchte, der muss über ausreichend schnelle und große Festplatten verfügen.
      Beste Grüsse von Bruno(Achilles)!
      - Videografieren ist eine Vergnügungssteuer -

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