Infoseite // Suche Batch-Konverter ProRes HQ zu GrassValley HQX

Frage von thsbln:


Guten Morgen Ihr Wissenden,

sagt mal, gibt es einen Konverter, mit dem ich einen Stapel Videodateien in ein anderes Format konvertieren kann, ohne dafür jede Datei in ein Schnittprogramm zu laden und von dort dann wieder zu exportieren?

Im Grunde brauche ich nur eine Software, die 1,2 TB an Daten von ProRes in GrassValley HQX umwandeln kann und die 10bit 4:2:2 erhält (die Codecs sind auf dem Rechner vorhanden). Vielleicht eine freie Software jenseits vom TmpgEnc?

Aus Resolve heraus, das ja auch schön die Ordnerstruktur erhalten würde, geht es für meine Belange schon mal nicht, da Resolve alles nur in MOV-Container packt und mein Sony Vegas Pro damit Probleme hat.

Danke Euch!



Antwort von wolfgang:

Tja, kommt mir irgendwie bekannt vor - und bin auf die Antworten gespannt da ich für das gleiche Thema ja TMPGenc genutzt habe. Bin auf die Antworten gespannt, vor allem ob jemand ein Tool weiß welches die 10bit garantiert erhält.



Antwort von merlinmage:

Edius hat sowas net integriert?



Antwort von wolfgang:

Bei Edius kannst das aus dem Bin heraus rendern, hast aber leider nur begrenzte Einstellmöglichkeiten. Man kann aus der timeline von Edius einen art Batchexport machen - aber dann muss man die In- und Outpunkte händisch setzen (viel Arbeit bei dieser Datenmenge).

Das hat Hans mal hier beschrieben:
http://www.videotreffpunkt.com/index.ph ... post280099

Der AVCHDtoHQ Konverter geht auch nicht, wenn es sich um 4K/UHD handeln sollte (bei HD könnte das gehen). Und aus Vegas heraus gehts auch nicht, weil die ProRes Files zumindest in der Luminanz falsch interpretiert werden.

http://www.vegasforum.de/prores-gamma-f ... tml?t=7711

http://www.videotreffpunkt.com/index.ph ... inanz-Bug/

Außerdem muss er Edius ja nicht einmal haben - die Codecs sind inzwischen ja gratis erhältlich, kann also gut sein dass jemand die GV Codecs hat aber Edius nicht.

Also ich bin auf weitere Konvertervorschläge gespannt. Würde mich auch interessieren!



Antwort von thsbln:

Danke,

ich brauche einen Batch-Konverter, der die Dateinamen erhält und mir alle Optionen läßt, was Qualität und Container angeht - so kann ich zB aus Resolve nur in einem Vegas-inkompatiblen (mehr oder weniger jedenfalls) MOV-Container rendern und habe auch nur die wahl zwischen verschiedenen Qualitätseinstellungen, wobei die höchste die dateigröße immer noch drittelt - das kann ja wohl nicht die bestmögliche Qualität des QHX sein...

Und bei 1,2 TB Daten und der Anforderung, wenn schon nicht die Ordnerstruktur dann doch zumindest den Dateinamen zu erhalten, entfällt so eine Fummellösung wie Edius leider auch.

P.S. Es handelt sich um 1920x1080 aus der Pocket und BMC EF. Meinen letzten Film mit solchen Daten hat Vegas problemlos geschnitten, jetzt spinnt es total, warum auch immer. Aber das nur als Nebenbemerkung, das soll hier jetzt keine Diskussion zu Vegas lostreten, die wird an anderer Stelle schon geführt :-)



Antwort von Goldwingfahrer:

ich brauche einen Batch-Konverter, der die Dateinamen erhält und mir alle Optionen läßt, was Qualität und Container angeht - Hab selber nur 8 Bit Material.
HastDu mal 2 Clips mit 10 Bit,dann könnte ichs mal mit dem Procoder probieren,bei 8 Bit klappts mit Batch hervorragend.
das kann ja wohl nicht die bestmögliche Qualität des QHX sein... die hier im Screen Gezeigte aber schon



Antwort von DTEurope:

http://www.ffmpeg.org/ sollte funktionieren.



Antwort von Goldwingfahrer:

Das habe ich natürlich auch schon probiert,es wird aber nur uncompr.4:2:2 in 10 Bit angeboten und beim Tool "Avanti" ist HQX nicht aufgelistet.



Antwort von wolfgang:

ich brauche einen Batch-Konverter, der die Dateinamen erhält und mir alle Optionen läßt, was Qualität und Container angeht Na und warum darfs dann nicht TMPGenc sein? Weils was kostet?

P.S. Es handelt sich um 1920x1080 aus der Pocket und BMC EF. Meinen letzten Film mit solchen Daten hat Vegas problemlos geschnitten, jetzt spinnt es total, warum auch immer. Hast du ein Update von QT gemacht? Einige berichten über Probleme mit der letzten Version.

Wenn es sich "nur" um HD handelt - vielleicht ginge der AVCHDtoHQ Konverter dann doch? Hättest du den?






Antwort von thsbln:


Na und warum darfs dann nicht TMPGenc sein? Weils was kostet?



Hast du ein Update von QT gemacht? Einige berichten über Probleme mit der letzten Version.

Wenn es sich "nur" um HD handelt - vielleicht ginge der AVCHDtoHQ Konverter dann doch? Hättest du den?
Genau, ich hab keine 100,- übrig für den TMPGenc.

Quicktime: ich hab verschiedene Versionen durchprobiert mit verschiedenen Absturzszenarien.

AVCHDtoHQ kenn ich nicht, muß ich mal schauen, kann der denn Prores in 422/10bit laden und konvertieren?

Danke!



Antwort von thsbln:

ich brauche einen Batch-Konverter, der die Dateinamen erhält und mir alle Optionen läßt, was Qualität und Container angeht - Hab selber nur 8 Bit Material.
HastDu mal 2 Clips mit 10 Bit,dann könnte ichs mal mit dem Procoder probieren,bei 8 Bit klappts mit Batch hervorragend.
das kann ja wohl nicht die bestmögliche Qualität des QHX sein... die hier im Screen Gezeigte aber schon Danke, ich lade nachher mal zwei kurze Clips hoch und melde mich nochmal mit den Links.

Das was Dein Screenshot zeigt, kann ich in Resolve nicht einstellen, leider.



Antwort von Marco:

Wie an anderer Stelle schon gesagt: Das lässt sich auch in Vegas Pro mit Hilfe von Vegasaur machen und dabei lassen sich automatisch auch die Signalfehler von ProRes korrigieren.



Antwort von thsbln:

Wie an anderer Stelle schon gesagt: Das lässt sich auch in Vegas Pro mit Hilfe von Vegasaur machen und dabei lassen sich automatisch auch die Signalfehler von ProRes korrigieren. Danke Marco,

ich habe mich drüben noch gar nicht zurückgemeldet diesbezüglich. Mittlerweile bekomme ich immer weniger .vegs des aktuellen Projektes geöffnet, so dass diese Option erstmal ausscheidet (und auf dem laptop mit der Testversion von Vegasaur liefen die BMPCC-files nicht in Vegas und ich hatte keinen Nerv, jetzt auch noch Quicktime-Versionen dort zu de/installieren, das alte Teil würde eh Jahre fürs Konverieren brauchen).



Antwort von thsbln:

ich brauche einen Batch-Konverter, der die Dateinamen erhält und mir alle Optionen läßt, was Qualität und Container angeht - Hab selber nur 8 Bit Material.
HastDu mal 2 Clips mit 10 Bit,dann könnte ichs mal mit dem Procoder probieren,bei 8 Bit klappts mit Batch hervorragend.
das kann ja wohl nicht die bestmögliche Qualität des QHX sein... die hier im Screen Gezeigte aber schon Danke, ich lade nachher mal zwei kurze Clips hoch und melde mich nochmal mit den Links.

Das was Dein Screenshot zeigt, kann ich in Resolve nicht einstellen, leider. https://www.dropbox.com/s/6nqiilfm9g0kx ... 6.mov?dl=0

https://www.dropbox.com/s/yoan5y042vrm4 ... 2.mov?dl=0



Antwort von Marco:

»Mittlerweile bekomme ich immer weniger .vegs des aktuellen Projektes geöffnet, so dass diese Option erstmal ausscheidet«

Wobei diese Option je gerade deswegen interessant gewesen wäre, weil es dazu gar nicht notwendig gewesen wäre, eines der betreffenden Vegas-Projekte zu öffnen. Es hätte all die Clips als externe Medien jeweils einzeln in einem frischen, ansonsten leeren Projekt geöffnet.



Antwort von Goldwingfahrer:

mal zwei kurze Clips hoch und melde mich nochmal mit den Links.

Das was Dein Screenshot zeigt, kann ich in Resolve nicht einstellen, leider. Das war ein Screen vom Procoder den ich als Batchcodierer für die beiden Testfile probieren wollte.

Was mir aber auffällt.
Test_Gif_3 Screens
1.Original
2.HXQ
3.farblich etwas angepasst

www.ww-consulting.ch/DL/Vergleich_3.rar



Antwort von Jim_pansen:

Wieso müssen denn ProRes Dateien überhaupt gewandelt werden?
Sowohl Edius, als auch Resolve können ProRes-Dateien direkt lesen.

FFMPEG fuinktioniert nicht, weil FFMPEG keinen HQ-Codec kennt.

ProCoder besitzt nur eine 8bit Transcoding-Engine. Den kann man für 10Bit Verarbeitung leider gänzlich vergessen.

Jim



Antwort von Goldwingfahrer:

Die Frage lautete

ich brauche einen Batch-Konverter, der die Dateinamen erhält und mir alle Optionen läßt, was Qualität und Container angeht - so kann ich zB aus Resolve nur in einem Vegas..........

Darum bot ich an obs ev.mit dem Procoder "im Batchmodus"möglich wäre.

Hier das Resultat,von den beiden erhaltenen Teststreams
www.ww-consulting.ch/DL/HQX.rar

Und hier was Edius mir dann nach dem "Batch"anzeigt.






Antwort von Jim_pansen:

Ich sehe gerade, ich habe nicht gründlich gelesen und damit übersehen, dass es eigentlich um ein VEGAS-Problem geht.
Die Möglichkeiten von Vegas kenne ich leider nicht, aber es gibt gerade noch günstige Crossgrade Pakete von GV zu kaufen! :D

AVANTI ist übrigens auch nur ein FFMPEG Tool und kennt daher auch kein HQ/HQX.

Grundsätzlich kann Video-Software HQX AVI Dateien nur dann bei 10bit Farbtiefe encoden oder lesen, wenn der Codec auch von der jeweiligen Software nativ integriert wurde. Das ist derzeit nur bei GV Software der Fall.
Somit kann man davon ausgehen, dass sowohl Vegas, als auch alle anderen NLEs HQX AVIs nur bei 8Bit Farbtiefe bearbeiten kann.
Das liegt leider an der Architektur von VfW und DirectShow.
Wenn überhaupt, dann funktioniert 10Bit Verarbeitung mit HQX via QuickTime.

Wenn es also um eine Wandlung nach HQ/HQX AVI geht, dann isses relativ wurscht, ob der 10Bit Workflow klappt, weil spätestens Vegas die AVIs wieder mit 8Bit weiter verarbeitet.
Somit kann man eigentlich auch den ProCoder wieder mit einspannen... :D

Jim



Antwort von thsbln:

Wieso müssen denn ProRes Dateien überhaupt gewandelt werden?
Sowohl Edius, als auch Resolve können ProRes-Dateien direkt lesen.

FFMPEG fuinktioniert nicht, weil FFMPEG keinen HQ-Codec kennt.

ProCoder besitzt nur eine 8bit Transcoding-Engine. Den kann man für 10Bit Verarbeitung leider gänzlich vergessen.

Jim Danke Jim.

Ich habe bereits mit Vegas ein viertel des nächsten Films geschnitten, da bekam ich Probleme mit Vegas und Prores - da ich ungern auf das bereits geschnittene verzichten möchte oder nochmal in nem neuen Programm von vorn anfangen, die Frage nach der Umwandlung. Leider ist das Projekt in Vegas teilweise so verhunzt, warum auch immer ist ja (hier) egal, dass ich auch keine brauchbare pproj für PPro exportieren kann.



Antwort von thsbln:

Die Frage lautete

ich brauche einen Batch-Konverter, der die Dateinamen erhält und mir alle Optionen läßt, was Qualität und Container angeht - so kann ich zB aus Resolve nur in einem Vegas..........

Darum bot ich an obs ev.mit dem Procoder "im Batchmodus"möglich wäre.

Hier das Resultat,von den beiden erhaltenen Teststreams
www.ww-consulting.ch/DL/HQX.rar

Und hier was Edius mir dann nach dem "Batch"anzeigt. danke dir! sieht ja erstmal gut aus, sah aber, der procoder kostet ja 300,- ...

aberscheinbar kann er ja 10 bit?!

merci!



Antwort von thsbln:

Wenn es also um eine Wandlung nach HQ/HQX AVI geht, dann isses relativ wurscht, ob der 10Bit Workflow klappt, weil spätestens Vegas die AVIs wieder mit 8Bit weiter verarbeitet.
Somit kann man eigentlich auch den ProCoder wieder mit einspannen... :D

Jim Es geht mir darum, die 10bit für die Farbbearbeitung (zB via roundtrip in Resolve) zu erhalten.



Antwort von thsbln:

»Mittlerweile bekomme ich immer weniger .vegs des aktuellen Projektes geöffnet, so dass diese Option erstmal ausscheidet«

Wobei diese Option je gerade deswegen interessant gewesen wäre, weil es dazu gar nicht notwendig gewesen wäre, eines der betreffenden Vegas-Projekte zu öffnen. Es hätte all die Clips als externe Medien jeweils einzeln in einem frischen, ansonsten leeren Projekt geöffnet. Ui, danke Marco, das war mir nicht klar. Ich forsche weiter in der Richtung!



Antwort von Jim_pansen:

Der Procoder rechnet macht aus 10Bit -> 8Bit Farbtiefe.
Auch der große Bruder, der ehemalige Carbon Coder hat nur eine 8Bit Engine.
Ich hatte das mal 2013 am IBC-Stand von Harmonic (Hersteller) erfragt.
Und wie gesagt, AVI-Codecs, die nicht nativ integriert sind, werden auch nur mit 8Bit Farbtiefe berechnet.

Jim



Antwort von thsbln:

Der Procoder rechnet macht aus 10Bit -> 8Bit Farbtiefe.
Auch der große Bruder, der ehemalige Carbon Coder hat nur eine 8Bit Engine.
Ich hatte das mal 2013 am IBC-Stand von Harmonic (Hersteller) erfragt.
Und wie gesagt, AVI-Codecs, die nicht nativ integriert sind, werden auch nur mit 8Bit Farbtiefe berechnet.

Jim Danke nochmals für die Klarstellung!



Antwort von Goldwingfahrer:

ich brauche einen Batch-Konverter, der die Dateinamen erhält und mir alle Optionen läßt, was Qualität und Container angeht - Hab selber nur 8 Bit Material.
HastDu mal 2 Clips mit 10 Bit,dann könnte ichs mal mit dem Procoder probieren,bei 8 Bit klappts mit Batch hervorragend. Nun ist alles klar.
10 Bit geht also nicht im Batch mit dem Procoder.



Antwort von Marco:

Wenn ich mich nicht irre, hat erst kürzlich ein User die Eigenschaft von importiertem GV HQX in Vegas Pro genauer untersucht und dabei festgestellt, dass die 10-Bit-Eigenschaft erhalten bleibt.






Antwort von Jim_pansen:

QuickTime oder AVI?
Bei AVI würde mich das schon sehr wundern, denn auch Vegas liest fremde AVI Codecs via VfW/DirectShow.

Jim



Antwort von wolfgang:

Grundsätzlich kann Video-Software HQX AVI Dateien nur dann bei 10bit Farbtiefe encoden oder lesen, wenn der Codec auch von der jeweiligen Software nativ integriert wurde. Das ist derzeit nur bei GV Software der Fall.
Somit kann man davon ausgehen, dass sowohl Vegas, als auch alle anderen NLEs HQX AVIs nur bei 8Bit Farbtiefe bearbeiten kann.
Das liegt leider an der Architektur von VfW und DirectShow.
Wenn überhaupt, dann funktioniert 10Bit Verarbeitung mit HQX via QuickTime.

Wenn es also um eine Wandlung nach HQ/HQX AVI geht, dann isses relativ wurscht, ob der 10Bit Workflow klappt, weil spätestens Vegas die AVIs wieder mit 8Bit weiter verarbeitet. Jim woher kommt den die Information dass in Vegas das 10bit HQX Material nur als 8bit interpretiert werden soll?

Wenn ich mich nicht irre, hat erst kürzlich ein User die Eigenschaft von importiertem GV HQX in Vegas Pro genauer untersucht und dabei festgestellt, dass die 10-Bit-Eigenschaft erhalten bleibt. Wenn das ein Test im Videotreffpunkt war - dieser User hatte das Original 10bit 422 ProRes vom Shogun untersucht.



Antwort von Marco:

Ja, meinte den Test im Videotreffpunkt. Ich habe gerade nochmal nachgelesen. Sorry, da ging es tatsächlich nur um ProRes, nicht um HQX.

Mich würde auch die Quelle der Information zu VfW und 8/10 Bit interessieren. Denn beispielsweise CineForm ist in Vegas Pro definitiv 10-Bit-fähig.



Antwort von Goldwingfahrer:

Marco
hier schon mal reingeschaut ?
http://www.grassvalley.com/docs/WhitePa ... epaper.pdf



Antwort von Marco:

Ja, aber darin finde ich keinerlei Information zu diesem Sachverhalt.



Antwort von Jim_pansen:

Bei VfW liegt das an den beschränkten Möglichkeiten des Codec Frameworks.
Bei Directshow ist es etwas komplizierter. Dort besteht prinzipiell die Chance, dass mit höherer Bit-Tiefe
gearbeitet werden kann. Ich werde mich bezüglich des HQX-AVI-Codecs noch mal in die Recherche begeben
und in dieser Frage kompetentere Leute befragen.
Wichtig jedenfalls ist, dass auch das nachfolgende Gewerk mit 10 Bit weiter rechnet.
Hier wäre es notwendig, entweder die Verarbeitungskette zu testen oder direkt bei SCS nachzufragen, ob
Vegas HQX bei 10 Bit-Farbtiefe dekodieren und beim Export encoden kann. Bei vielen Anwendungen liegt
genau hier das Problem, weshalb ich meine Zweifel habe.
Viele Hersteller arbeiten auch mit Lookup-Tables über die entschieden wird, wie damit "weiter verfahren"wird.
Vielleicht hat da ja jemand einen direkten Draht zu SCS?

Die Einschränkungen des ProCoders sind auf jeden Fall gegeben! Leider!
Ich arbeite nämlich auch ganz gern damit.

Bei ProRes wundert es mich im Übrigen nicht, dass hier die 10 Bit erhalten bleiben. Das wird mit Sicherheit
für den HQX-QuickTime-Codec ebenso gelten.

Jim



Antwort von Marco:

Danke für die weiterführenden Infos.

Im Falle von CineForm ist es so, dass zumindest Teile dieses Frameworks in Vegas Pro nativ implementiert sind (wie beispielsweise der CF-Decoder).



Antwort von Jim_pansen:

Im Falle von CineForm ist es so, dass zumindest Teile dieses Frameworks in Vegas Pro nativ implementiert sind (wie beispielsweise der CF-Decoder). Das ist wirklich ein riesiger Vorteil! Die Erhaltung der Farbtiefe ist neben der Performance einer der wichtigsten Argumente,
einen Codec nativ zu integrieren. Gute Entscheidung! Wenngleich ich den GrassValley Codec favorisiere, der Cineform-Codec
hat mit der SMPTE-Spezifizierung (VC-5) das Zeug dafür, ein echter Austauschcodec zu werden. Dafür würde ich sogar zahlen.
ProRes ist leider propritär und nicht wirklich plattformunabhängig und für mich mittlerweile eine Workflowbremse, weil Apple
echte Interoperabilität im Grunde aktiv behindert.
Ich habe immer gehofft, dass GV den HQ-/HQX-Codec noch etwas freimütiger etabliert, denn leider ist es Fakt, dass der Codec
bei vielen immer noch völlig unbekannt ist. Leider!

Jim



Antwort von wolfgang:

Also den Draht zu SCS gibts. Die Frage ist nur, ob die eine Aussage dazu tätigen werden....






Antwort von Goldwingfahrer:

HQX außerhalb Edius ist immer 8bit!

lese ich im 5.Beitrag von

http://forum.doom9.org/showthread.php?t=165042



Antwort von Jim_pansen:

Also den Draht zu SCS gibts. Die Frage ist nur, ob die eine Aussage dazu tätigen werden.... Mmmh, dann ist das ja auch kein "richtiger Draht"! :D
Ich versuche mal, auf der anderen Seite eine Aussage zu finden.
Und prinzipiell ließe sich das ja auch testen...

Jim



Antwort von wolfgang:

Eine Gratis Lösung für das hier gestellte Problem habe ich vielleicht, und zwar innerhalb von Vegas. Allerdings muss man dazu alle Datein in Vegas legen können. Ginge so:

1. Man legt alle Datein in Vegas
2. Man führt in der Spur die Korrektur für den Luminanzbug von ProRes durch
3. Man nutzt das Script Add Regions to Events - da werden alle Events in der timeline mit Regionen versehen
4: Man nutzt das Script Batch Render und rendert alle Regionen zu neuen Files. Richtet man sich vorher Rendertemplates für den HQ oder HQX ein, dann kann man auch zu dem rendern. Aufgrund der hier angesprochen möglchen Probleme sollte man aber vielleicht eher XAVC nehmen - oder ein anderes Format.



Antwort von Marco:

Vorsicht, dazu muss noch geklärt werden, wie die Eigenschaften der ProRes-Dateien von thsbln überhaupt beschaffen sind. Da könnte ja auch die andere Variante greifen, die keine Anpassung der Spitzenpegel, aber die Gammakorrektur und zusätzlich die Farbraumkorrektur benötigt.

Und thsbln braucht eine etwas andere Lösung, wenn es innerhalb von Vegas Pro geschehen soll. Er kann ja nicht die bestehenden Projekte benutzen und auch keine größere Anzahl an ProRes-Dateien in einem neuen Projekt benutzen.
Daher braucht er aus Vegas Pro raus eine Batch-Lösung, die aus einem externen Ordner in ein bis dahin leeres Projekt der Reihe nach einzeln eine ProRes-Datei lädt, die (mit Korrektur) wandelt, wieder aus dem Projekt löscht und dann die nächste Datei zur Wandlung lädt.
Das geht meines Wissens mit den internen Batch-Scripten nicht. Mit Vegasaur ist es machbar. Eventuell sogar mit dem kostenfreien ProxyStream-Script, wobei ich mich mit dem schon länger nicht mehr befasst habe.



Antwort von Jim_pansen:

Darf ich als VEGAS-Unwissender fragen, was es mit dem Proxy Script auf sich hat?
Ich fühle mich dabei an den Debugmode Frameserver erinnert, der allerdings auch nur bei 8bit Präzision arbeitete.

Jim



Antwort von Marco:

In diesem Fall ist das Konzept ein anderes. Die in Vegas Pro nutzbaren Scripte automatisieren programminterne Funktionen. Ähnlich wie Macros, aber erweitert um die Eigenschaften einer eigenen API, die über .NET Framework per JScript, Visual Basic oder C# programmiert werden können und auch mit eigener GUI innerhalb eines Vegas-Programmfensters zugreifbar gemacht werden können.
Ich kann also die intern gegebenen Exportfunktionen nehmen und sie per Script mit gewissen Abfragen, Konditionen und Funktionen kombinieren und automatisieren.

Noch was anderes:
Wenn ich ein Video zu HQX mit einem Transcoder wie FootageStudio wandele und mir die Eigenschaften in MediaInfo ansehe, dann wird das HQX als 8 Bit deklariert.
Wenn ich aber aus Vegas Pro raus zu HQX wandele, wird letztlich 10 Bit deklariert.

Mir ist klar, dass die Infos von MediInfo mit großer Vorsicht zu genießen sind, aber vielleicht ist das ja dennoch ein nützlicher Hinweis.



Antwort von Jim_pansen:

Ja, das ist mit Vorsicht zu genießen!
Denn letztlich beschreibt das nicht die möglichen Flaschenhälse in der Pipeline.
Ein 8bit Image lässt sich natürlich auch innerhalb eines 10 Bit Codec abbilden.
Sollte der HQX AVI Codec intern mit 10 Bit arbeiten, so könnte das FLag gesetzt
sein, was aber keinen Mehrwert bringt, wenn die Vegas API den Videostream nur
mit 8 Bit Präzision liefert. Aber das gilt es ja heraus zu finden.
Es hängt sowohl von der internen Verarbeitung in der NLE aber auch von dem
Directshow FilterGraph ab. Blöd, dass das nie sauber dokumentiert wird.

Jim



Antwort von wolfgang:

Ja, der Nachweis dass ein Material 10bit in einer NLE ist, ist leider gar nicht einfach.

Dass mein Ansatz halt leider nur dann geht, wenn das Projekt noch nicht steht - ja natürlich, das ist so. Aber Vegasaur kostet halt auch Geld, und für TMPGenc ist das ja auch nicht da.



Antwort von Jim_pansen:

Teuer ist das jetzt aber nicht!
Scheint ja ein sehr mächtiges Tool zu sein und es funktioniert auch über mehrerer Versionen.

Jim






Antwort von wolfgang:

100 Doller sind halt relativ - TMPGenc wäre ja auch nicht teurer.



Antwort von Goldwingfahrer:

Noch was anderes:
Wenn ich ein Video zu HQX mit einem Transcoder wie FootageStudio wandele und mir die Eigenschaften in MediaInfo ansehe, dann wird das HQX als 8 Bit deklariert. auch in der Vollversion ?
Zitat von Wolfgang
- TMPGenc wäre ja auch nicht teurer. Sprichst Du von



Antwort von srone:

hallo thsbln,

da du weiter oben premiere erwähnt hast, mal den media encoder versucht?

lg

srone



Antwort von wolfgang:

Zitat von Wolfgang
- TMPGenc wäre ja auch nicht teurer. Sprichst Du von Ja!



Antwort von Marco:

Ich habe für die Tests die Demoversion von FootageStudio benutzt. Die unterscheidet sich meines Wissen bezüglich der Encoder gar nicht von der Vollversion und bezüglich anderer Funktionen lediglich durch die Tatsache, dass nur 1 Sekunde exportiert wird und dass ein Wasserzeichen gesetzt wird.



Antwort von Marco:

»Scheint ja ein sehr mächtiges Tool zu sein und es funktioniert auch über mehrerer Versionen.«

Mit einem Encoderwerkzeug wie TmpgEnc lässt sich Vegasaur (falls das gemeint war) nicht vergleichen. Im Vergleich zu anderen Scripttools, die für Vegas Pro angeboten werden, ist Vegasaur (abgesehen vom kostenfreien TimelineTools) nicht teurer, aber funktionell deutlich besser ausgestattet und besser programmiert.

Ich hatte Vegasaur schon an anderer Stelle für diese Thematik ins Spiel gebracht, weil ich ursprünglich dachte, der Threadstarter hätte ohnehin eine Lizenz und das Tool installiert. Denn tatsächlich ist das Werkzeug unter denen, die Vegas Pro häufig und oft unter Zeitdruck benutzen, sehr beliebt.



Antwort von thsbln:

Eine Gratis Lösung für das hier gestellte Problem habe ich vielleicht, und zwar innerhalb von Vegas. Allerdings muss man dazu alle Datein in Vegas legen können. Ginge so:

1. Man legt alle Datein in Vegas
2. Man führt in der Spur die Korrektur für den Luminanzbug von ProRes durch
3. Man nutzt das Script Add Regions to Events - da werden alle Events in der timeline mit Regionen versehen
4: Man nutzt das Script Batch Render und rendert alle Regionen zu neuen Files. Richtet man sich vorher Rendertemplates für den HQ oder HQX ein, dann kann man auch zu dem rendern. Aufgrund der hier angesprochen möglchen Probleme sollte man aber vielleicht eher XAVC nehmen - oder ein anderes Format. Vielen Dank, das probiere ich mal mit den .veg, die noch funktionieren.



Antwort von thsbln:

hallo thsbln,

da du weiter oben premiere erwähnt hast, mal den media encoder versucht?

lg

srone hi srone,

danke, ich würde ppro zur not für das projekt mieten. zum media encoder finde ich auf deer adobe-seite erstmal keine für mich relevanten aussagen, nur PR-gestammel.

lg

thomas



Antwort von thsbln:


Ich hatte Vegasaur schon an anderer Stelle für diese Thematik ins Spiel gebracht, weil ich ursprünglich dachte, der Threadstarter hätte ohnehin eine Lizenz und das Tool installiert. Denn tatsächlich ist das Werkzeug unter denen, die Vegas Pro häufig und oft unter Zeitdruck benutzen, sehr beliebt. Jetzt habe ich die Testversion auf dem Schnitt-PC installiert und heute vor der Arbeit versucht mal eine Datei nach HQX (mit den höchsten Qualitäts-Parametern unter custom settings) zu konvertieren - raus kam dabei ein pixeliges Videolein mit einer Größe von 40MB - kann sein, dass die Testversion beschränkt ist?






Antwort von Marco:

Wenn sich nun tatsächlich herausstellt, dass HQX derzeit ausschließlich in Edius als 10-Bit-Signal funktioniert, dann wird die Luft ja immer enger (da Quicktime für diesen Fall generell gemieden werden soll).

Dann bleibt für 10 Bit in Vegas Pro noch XAVC, Panasonic P2, HDCAM SR, v210 (was in Vegas Pro unter dem Namen »Sony YUV 10 Bit läuft und – da unkomprimiert – riesige Dateien erzeugt) oder Bildsequenzen (was für Projekte dieser Art aber etwas fragwürdig wäre). CineForm hattest du ja schon versucht, das funktioniert in Vegas Pro ebenfalls als 10 Bit.



Antwort von Jim_pansen:

Wenn sich nun tatsächlich herausstellt, dass HQX derzeit ausschließlich in Edius als 10-Bit-Signal funktioniert, dann wird die Luft ja immer enger (da Quicktime für diesen Fall generell gemieden werden soll) Warum soll denn eigentlich QuickTime gemieden werden?
Resolve z.B. agiert nur sinnvoll via QuickTime.

Jim



Antwort von Marco:

»kann sein, dass die Testversion beschränkt ist?«

Welche Testversion? Die von Vegasaur? Das hätte nichts mit dem HQX-Encoder zu tun. Ich vermute, du hast falsche Encoder-Einstellungen als Rendervorlage gespeichert.

Du hast doch für HQX vorher eine eigene Rendervorlage angelegt und gespeichert, oder?

Aber es würde ja nichts bringen, wenn sich herausstellen sollte, dass HQX auf Vegas nur mit 8-Bit-Eigenschaft genutzt wird.



Antwort von Marco:

»Resolve z.B. agiert nur sinnvoll via QuickTime.«

Und Vegas Pro mit fast allem – außer Quicktime. ;)
Wer in Vegas Pro beschwerdefrei arbeiten möchte, macht um Quicktime-basierendes Video einen großen Bogen.

Der Threadstarter hatte zuvor schon etliche Quicktime-Varianten (auch DNxHD) versucht …



Antwort von thsbln:

Wenn sich nun tatsächlich herausstellt, dass HQX derzeit ausschließlich in Edius als 10-Bit-Signal funktioniert, dann wird die Luft ja immer enger (da Quicktime für diesen Fall generell gemieden werden soll).

Dann bleibt für 10 Bit in Vegas Pro noch XAVC, Panasonic P2, HDCAM SR, v210 (was in Vegas Pro unter dem Namen »Sony YUV 10 Bit läuft und – da unkomprimiert – riesige Dateien erzeugt) oder Bildsequenzen (was für Projekte dieser Art aber etwas fragwürdig wäre). CineForm hattest du ja schon versucht, das funktioniert in Vegas Pro ebenfalls als 10 Bit.
Danke, vielleicht hab ich Mist gebaut bei der Render-Vorlage in Vegas, die ich dan in Vegasaur genutzt habe (und ja, Vegasaur-Testversion).

Tja, falls das mit den 8bit zutrifft, wird es wirklich eng, Cineform ist mir zu teuer und ein unkomprimierter Codec ist wohl von der Datenmenge nochmal geschätzt um den Faktor 5 größer als ProRes HQ? Ist also nicht operabel.



Antwort von Jim_pansen:

Cineform ist mir zu teuer... Das GoPro Studio beinhaltet ja auch eine Cineform Variante.
Der ist "for free"! Keine Ahnung, wie gut der mit Resolve interagiert!
Wie groß der Unterschied zur kommerziellen 299.- $ Version ist, weiß ich aber nicht.

Jim



Antwort von Marco:

Wenn ich das damals richtig verstanden hatte, kannst du doch von Resolve aus CineForm exportieren (ohne separate CineForm-Installation).
Und wie damals schon geschrieben, kannst du CineForm in Vegas nativ ohne separate Codec-Installation importieren und bearbeiten.
Du musst dafür nichts kaufen.



Antwort von Jim_pansen:

Wenn ich das damals richtig verstanden hatte, kannst du doch von Resolve aus CineForm exportieren (ohne separate CineForm-Installation). Lesend geht ja immer, wenn die Bibliotheken implementiert sind.
Die nativ implementierte Exportfunktion wird - glaube ich - erst durch
eine kommerzielle Lizenz wirklich frei geschaltet, sowohl bei Resolve,
als auch bei Vegas.

Jim



Antwort von thsbln:

Danke Jim und Marco,

ich habe nur schleierhaft in Erinnerung, dass mit der Gopro Studio irgend etwas nicjht ging, kann aber auch sein, dass es was mit RAW zu tun hatte.
Ich probiere es morgen Abend mal aus, danke!






Antwort von wolfgang:

Dann bleibt für 10 Bit in Vegas Pro noch XAVC, Panasonic P2, HDCAM SR, v210 (was in Vegas Pro unter dem Namen »Sony YUV 10 Bit läuft und – da unkomprimiert – riesige Dateien erzeugt) oder Bildsequenzen (was für Projekte dieser Art aber etwas fragwürdig wäre). Ich nutze den Vegasaur ja nicht - aber könnte der auch grundsätzlch die Ausgabe zu XAVC als Batchrendering machen? Wenn es nicht der HQX sein kann/soll - was wir natürlich nicht so schnell raus bekommen werden.



Antwort von Marco:

Ja, Vegasaur setzt ja auf Vegas Pro auf. Er kann alles für den Export nutzen, was in Vegas Pro als Rendervorlage gespeichert wurde.



Antwort von Jim_pansen:

Ich habe mal einen 10 Bit Clip (V210, 24p) ausgespielt.
Könnte jemand den Clip vielleicht in ein 10 Bit VEGAS Projekt legen,
dann nach HQX AVI auspielen und mir zur Verfügung stellen?

https://drive.google.com/file/d/0B62XZD ... sp=sharing


Ich habe einen Weg gefunden, um bewerten zu können, ob es sich um einen 8 oder 10 Bit Workflow handelt,
wenn via DirectShow gelesen oder encoded wird.

Die Ergebnisse werde ich dann zusammen mit einer entprechenden Beschreibung hier posten.

Jim



Antwort von Marco:

Wenn ich den Export auf wenige Frames beschränken kann, kann ich das nachher machen (mein Upload gibt nicht viel her).

Du musst nur bedenken, dass es in Vegas Pro kein 10-Bit-Projekt, sondern außer 8 Bit verschiedene Floatpoint-basierende Modi gibt, in denen sich alles abspielt, was mehr als 8 Bit hat. Außerdem wird es wohl nicht DirectShow, sondern VfW sein.
Ich weiß nicht, ob dir das unter diesen Bedingungen was bringt.



Antwort von Jim_pansen:

VfW wäre doof, das ist garantiert 8 Bit.
Könnte man der Vollständigkeit halber aber mal testen.

Jim



Antwort von Jim_pansen:

Da das Quellmaterial übrigens nur 2 Sekunden lang ist, wird sich die Uploadzeit des fertigen HQX Videos bei ca 10 MB Größe im Rahmen halten.
Als RAR gepackt komme ich auf gerade mal 126 KByte, was sich per Mail verschicken ließe, bzw hier in den Thread pinnen ließe.

Anbei zwei in Edius erzeugte HQX-Dateien.
Das V210 File ist sinnvoll, da V210 gesichert bei 10 Bit funktioniert.

Jim



Antwort von Marco:

Hier ist der -> Download. Ich habe es auf zwei Frames reduziert.

Allerdings - die Basis war nun ja ein unkomprimiertes AVI. Also lässt das doch nur bedingt Rückschlüsse darauf zu, ob in Vegas Pro HQX möglicherweise als 10 Bit decodiert werden könnte. Hiermit kannst du ja nur testen, was Vegas Pro encodiert.



Antwort von Jim_pansen:

Danke!
Die gute Nachricht ist, der HQX Export klappt bei 10 Bit Farbtiefe.
Die schlechte ist, der Workflow V210 -> HQX produziert in VEGAS einen ordentlichen Colorshift.

Wenn du meine HQX Files zusammen mit deinem und dem V210 File in eine Timeline legst, wo kommt es zu Colorshifts?

Danke
Jim



Antwort von Marco:

Innerhalb von Vegas Pro ist da kein Colorshift bei der HQX-Version. Unkomprimiert und HQX sehen in Vorschau, auf dem Vektorscope und in der RGB-Parade aus wie eineiige Zwillinge. Da ist in der Farbdarstellung wirklich zero Differenz.

Aber mal anders gefragt: Wie könnte ich jetzt in Vegas Pro prüfen, ob das auch als 10 Bit decodiert wird?






Antwort von Jim_pansen:

Ich beschreibe mal mein Testszenario:

Ich habe in Photoshop die im Clip abgebildete Grafik erstellt und in After Effects importiert,
da Verläufe im QuickTitler, wie im Grunde alle Titel leider nur 8Bit Farbtiefe liefern.
Edius kann leider auch nur einige wenige Grafikformate bei hoher Farbtiefe lesen, PSD
und TIFF gehören leider nicht dazu. In AE habe ich daraus eine Komposition erstellt und
diese als V210 Clip exportiert, welcher mir als Basis diente.
(https://drive.google.com/folderview?id= ... sp=sharing)

Den V210 Clip habe ich in Edius in eine 10 Bit Timeline gelegt und aus dieser folgende Exporte erstellt:

- HQ AVI (als 8Bit Vergleich)
- HQX AVI
- HQ QuickTime (als 8Bit Vergleich)
- HQX QuickTime

Nun wurden alle erstellten Clips wieder in die Timeline gelegt und mit dem Orignal verglichen.
Um die Bandbreite der Farbabstufungen auszureizen habe ich den Chromawert (Edius Effekt: Farbabgleich)
auf Maximum erhöht und die YUV-Kurve stark manipuliert, damit der Wertebereich auseinander gerissen
und starkes Banding provoziert wird.
(Für Edius User habe ich das Filterset in den Google Drive Ordner zum Download gelegt, in welchem auch der
Sourceclip liegt)


zum Bild


zum Bild



Resultate

Quelle (V210 Clip, KEINE Filter angewendet)
zum Bild http://abload.de/thumb/v210_source_10bitugsmz.jpg

HQ (8 Bit, via Edius, Filter angewendet)
zum Bild http://abload.de/thumb/hq_bei_8bit6is23.jpg

HQX (10 Bit, via Edius, Filter angewendet)
zum Bild http://abload.de/thumb/hqx_bei_10bitdfsl4.jpg

HQX (10 Bit, via VEGAS, Export von Marco, Filter in Edius angewendet)
zum Bild http://abload.de/thumb/vegas_hqx_bei_10bit_v7msji.jpg

Summasummarum bleibt festzustellen, dass 10 Bit Workflow mit HQX AVI Export in VEGAS prinzipiell funktioniert,
es wäre nur noch interessant, zu wissen, wie es zu dem Colorshift (eigentlich Luma-Stauchung) kommt.
Ich tippe darauf, dass der Clip mit RGB-Werten ausgegeben wurde?

10 Bit Decoding Test in VEGAS:
Zum Testen der Decoding-Fähigkeit lohnt sich der Download des HQX-Clips aus diesem Post:
https://www.slashcam.de/forum/viewtopic.php?p=767288#767288
Danach in die VEGAS Timeline legen und nach HQX erneut exportieren.


Jim



Antwort von Marco:

Das Prozessing in Vegas Pro ist immer RGB-basierend.

Aber wie gesagt: In Vegas Pro ist da kein Farbshift. Ich sehe auch in Edius keinen, sondern dort nur die Stauchung des Luma und damit verbunden eine entsprechende Entsättigung, aber keinen Shift. Die Farbwinkel bleiben identisch.

Und die 10 Bit siehst du nun am Banding?



Antwort von Jim_pansen:

Das Prozessing in Vegas Pro ist immer RGB-basierend.

Aber wie gesagt: In Vegas Pro ist da kein Farbshift. Ich sehe auch in Edius keinen, sondern dort nur die Stauchung des Luma und damit verbunden eine entsprechende Entsättigung, aber keinen Shift. Die Farbwinkel bleiben identisch. Ja, du hast Recht, ich meinte die Luma-Stauchung.
Ein Schnellschuss von mir.

Die RGB Wandlung ist ja im Grunde erst einmal kein Problem, wenn die richtigen Farbprofile genutzt werden,
so wie das auch in After Effects möglich ist. Ärgerlich ist aber, dass in Edius der Farbraum des Quellclips bei HQX
nicht mehr vorgewählt werden kann, so wie das früher der Fall war. Offenbar wird dem HQX Codec in Edius allein
die YUV Farbcodierung zugestanden.

Jim



Antwort von Jim_pansen:

....und ja, die 10 Bit sehe ich am provozierten, aber nicht oder nur schwach vorhandenem Banding!
Ist zwar ein improvisiertes Verfahren, aber es funktioniert.

Jim



Antwort von wolfgang:

Also ich habe das auch durchanalysiert, und danke für den schönen Ansatz Jim.

Zusätzlich habe ich die Datein auch aus Vegas heraus einmal über QT und einmal über VfW exportiert. Und zwar für alle 3 Datein, sodass ich schlußendlich 6 Files habe. DAS war eine zusätzlich gute Übung. Denn es zeigt sich völlig eindeutig, dass
a) der QT Export aus Vegas heraus sehr wohl nur 8bit liefert, das Banding ist dort enorm
b) schon im QT Testfile mehr Banding vorhanden ist als im avi export
c) der Luminanzumfang vom HQX(QT) in Vegas schon gespreizet ist, verglichen mit den avi Exporten (ist in Edius nicht der Fall)
d) der Export aus Vegas heraus als avi sehr wohl als 10bit funktioniert.

Also können wir den Canopus HQX als VfW (avi) Export sehr wohl als Intermediate auch in Edius verwenden. Gut so.

Danke für diesen tollen Testansatz - den finde ich wirklich gelungen!



Antwort von Marco:

-> Hier ist der neue Output aus Vegas Pro. Im Vegas-Projekt lag die AVI-Version von HQX und exportiert wurde mit gleichen Eigenschaften wie eben.

In Vegas Pro werde ich dieses Testverfahren nicht verwenden können. Denn aufgrund des 4:4:4-Floatpointprozessings wird vermutlich auch bei den extremsten Spreizungen, die erst innerhalb des NLE angelegt werden, kein Banding entstehen. Gut für die Postpro, schlecht für Tests wie diesem.



Antwort von Jim_pansen:

-> In Vegas Pro werde ich dieses Testverfahren nicht verwenden können. Denn aufgrund des 4:4:4-Floatpointprozessings wird vermutlich auch bei den extremsten Spreizungen, die erst innerhalb des NLE angelegt werden, kein Banding entstehen. Gut für die Postpro, schlecht für Tests wie diesem.
Ein Banding kann man immer provozieren, wenn man den Wertebereich auseinander zerrt!
Die Abstufungen werden dabei zwangsläufig größer, was auch in 4:4:4 Floatingpoint Projekten
zu sehen ist. Das hat darauf gar keinen Einfluss. Du benötigst nur eine 10 Bit Quelle, welch du dir
auch Vegas erstellen kannst (V210).

Jim



Antwort von Jim_pansen:

Danke, für mich war der Test auch sehr hilfreich.
Ich traue dem AVI Codec potenziell nun doch wieder einiges mehr zu.
In diesem Sinne bin ich froh, dass ich mich bei DirectShow geirrt habe.
Video for Windows bleibt aber 8 Bit.

Erstaunlich ist, dass wider meinen Erwartungen der QuickTime Support so derart rudimentär ist!

Jim



Antwort von wolfgang:

Ich habe gerade mal mit dem 210er Testfile auch noch eine Proberenderung zum HQX superfein
a) aus Edius heraus 10bit Projekt
b) aus TMPGenc heraus

gemacht.

Und das mit dem Original aber auch mit dem Renderergebnis aus Vegas heraus verglichen (32bit floating point Projekt).

Also 2 Befunde:
1. Aus dem 10bit aus Edius heraus entsteht doch etwas mehr Banding - nicht stark. Aber was zu erwarten war, da Edius ja ein 10bit integer Projekt nutzt. Das hat den Vorteil einer guten Vorschauperformance, die ist in Veags mit dem 32bit floating Point doch mehr Rechenleistung auch für die Vorschau benötigt.

2. Aus TMPGenc schaut die Sache wie aus Edius heraus gerendert aus. Sprich - das Ergebis ist hier ebenfalls ein echtes 10bit HQX file, analog zu Edius aber offenbar als integer gerechnet. Damit hat man auch hier eine Spur mehr Banding als beim Original, aber auch hier ist das nicht weltbewegend.

Fazit: auch über TMPGenc ist offenbar ein 10bit workflow möglch, bei dem wir die 10 ProRes Files in TMPGenc zu 10bit HQX rendern. Und das dann in Vegas weiter verarbeiten. Beim Rendern aus Vegas zu einer weiteren HQX-Ausgabe muss man das aber nicht über QT, sondern über Video for Windows machen.

Für eine noch höhere Qualität müßte man die erste Generation der HQX Files nicht in TMPGenc, sondern über Batchrendern aus Vegas heraus erstellen.






Antwort von Jim_pansen:

Ein Banding in einem Vegas-Floatpoint-Projekt ist nur dann sichtbar, wenn ein Signal, das schon im Original Banding enthält, dort ohne jede Manipulation dargestellt wird. Das Spreizen des Wertebereiches einer 8 Bit Quelle führt auch in Vegas zu einem ähnlichen Banding.

Jim



Antwort von Marco:

Sorry, ich hatte mein Posting, auf das sich deine Antwort bezieht, schnell wieder gelöscht, nachdem ich fünf Sekunden nach einem kleinen Test selbst sah, wie unsinnig meine Aussage war.



Antwort von Jim_pansen:

Sorry, ich hatte mein Posting, auf das sich deine Antwort bezieht, schnell wieder gelöscht, nachdem ich fünf Sekunden nach einem kleinen Test selbst sah, wie unsinnig meine Aussage war. Macht ja nix! Gut, dass du's nochmal getestet hast.

Greetz
Jim



Antwort von Jim_pansen:

Also 2 Befunde:
1. Aus dem 10bit aus Edius heraus entsteht doch etwas mehr Banding - nicht stark. Aber was zu erwarten war, da Edius ja ein 10bit integer Projekt nutzt. Wolfgang,
ich will ja eigentlich nicht kleinlich sein, aber was meinst du mit Integer Projekt?
Edius rechnet in 10 Bit Projekten mit Nachkommastellen und sampled eben nicht auf volle Integerwerte, trotz YUV.
In Edius mangelt es eigentlich nur an 4:4:4 Prozessing und die interne hohe 32 Bit Auflösung von Vegas macht
einfach prinzipiell mehr Möglichkeiten für den Feinschliff und für die Kaskade über einander liegender Effekte auf. ;)

Jim



Antwort von Marco:

Der Wertebereich, auf den sich das Prozessing bezieht, ist 10 Bit integer. 1024 Werte. Fix.

Der Wertebereich, auf den sich das Prozessing in Vegas bezieht, sofern es kein 8-Bit-Projekt ist, ist Floatpoint-basierend. Es gibt keinen fixen Wertebereich. Es sind nicht 2 hoch 32. Es gibt daher in einem solchen Projekt in der Praxis keine Grenzen für Über- und Unterbelichtungen (die Grenzen sind so extrem hoch, dass sie selbst bei extremer Postpro nicht ausgereizt werden).

Mit YUV oder RGB hat das weniger zu tun.



Antwort von Jim_pansen:

Der Wertebereich, auf den sich das Prozessing bezieht, ist 10 Bit integer. 1024 Werte. Fix.

Der Wertebereich, auf den sich das Prozessing in Vegas bezieht, sofern es kein 8-Bit-Projekt ist, ist Floatpoint-basierend. Es gibt keinen fixen Wertebereich. Es sind nicht 2 hoch 32. Es gibt daher in einem solchen Projekt in der Praxis keine Grenzen für Über- und Unterbelichtungen (die Grenzen sind so extrem hoch, dass sie selbst bei extremer Postpro nicht ausgereizt werden). Dann besagt "32 Bit" lediglich, dass theoretisch ein 32 Bit Wertebereich via API übergegeben werden könnte,
intern aber mit unbegrenzter Genauigkeit gerechnet wird? Arbeiten denn auch die internen Effekte mit dieser Präzision?
Einen 32 Bit Wertebereich verstehe ich ja letztlich auch als eine fixe Anzahl möglicher Werte.
Mit YUV oder RGB hat das weniger zu tun. Das stimmt, ich hatte gedanklich nur eine Diskussion vor Augen, die wir mal im Edius-Forum hatten,
da ging es um den Vergleich 10 Bit YUV mit 10 Bit RGB. Der Knackpunkt war, dass vermeintlich der 10 Bit YUV Codec einen kleineren Wertebereich hätte.

Jim



Antwort von Marco:

Also erstmal wieder zurück zu deinem Testverfahren. Ich habe nun in ein Floatpoint-Vegas-Projekt gelegt:

- Die unkomprimierte 10-Bit-Referenz.
- Das aus Vegas Pro exportierte HQX-File.
- Ein aus Vegas Pro exportiertes unkomprimiertes 8-Bit-File.

Dann per Tonwertkorrektur Schwarz und Weiß solange aufgesprengt, bis auch im unkomprimierten 10-Bit im Histogramm das erste deutliche Banding sichtbar wurde.

Dann explodiert im HQX das Banding schon förmlich. Es ist nicht identisch, aber sehr ähnlich der unkomprimierten 8-Bit-Version.

Daraus folgere ich, dass HQX in Vegas Pro nicht in 10 Bit decodiert werden kann. Wobei ich es etwas seltsam finde, dass es dennoch als 10 Bit exportiert werden kann.

Zum Floatpoint:
Die interne Genauigkeit ist nicht unbegrenzt, sondern liegt im Rahmen dessen, was eine Gleitkommaberechnung hergibt. Die äußeren Grenzen des Wertebereiches liegen eben bei ungefähr 10^-38 bis 10^38, während Schwarz auf 0 und Weiß auf 1 festgelegt ist. Da bleibt also eine unglaubliche Reserve für Werte tiefer als Schwarz und höher als Weiß.
Die 32 Bit sagen hier erstmal gar nichts über den Wertebereich, sondern das ist hier ja nur die Eigenschaft der Gleitkommaberechnung. Mit 32 integren Werten hat das nichts zu tun.
Wenn nun der verfügbare Wertebereich mit dem eines integren Prozessings verglichen werden soll, muss der Bereich des Floatpoint-Prozessings als Wertebereich herangezogen werden, der zwischen 0 und 1 darstellbar ist. Wie weit dieser Bereich in integren Werten ausgedrückt ist, kann ich nicht genau sagen, aber es genügt, um selbst 24-Bit-Integer präzise abzubilden.

Nachtrag:
Ich habe gerade oben beschriebenes Testkonstrukt wiederholt, nur die Spreizung ein wenig moderater gemacht, so dass im unkomprimiertem 10-Bit-AVI gerade noch kein Banding auftaucht. Dann ist die HQX-Varianten in R', G' und B' aber schon zerrissen wie ein Kamm und sogar die unkomprimierte 8-Bit-Version ist längst nicht so aufgerissen.



Antwort von Jim_pansen:

Also erstmal wieder zurück zu deinem Testverfahren. Ich habe nun in ein Floatpoint-Vegas-Projekt gelegt:

- Die unkomprimierte 10-Bit-Referenz.
- Das aus Vegas Pro exportierte HQX-File.
- Ein aus Vegas Pro exportiertes unkomprimiertes 8-Bit-File.

Dann per Tonwertkorrektur Schwarz und Weiß solange aufgesprengt, bis auch im unkomprimierten 10-Bit im Histogramm das erste deutliche Banding sichtbar wurde.

Dann explodiert im HQX das Banding schon förmlich. Es ist nicht identisch, aber sehr ähnlich der unkomprimierten 8-Bit-Version.

Daraus folgere ich, dass HQX in Vegas Pro nicht in 10 Bit decodiert werden kann. Wobei ich es etwas seltsam finde, dass es dennoch als 10 Bit exportiert werden kann.

Zum Floatpoint:
Die interne Genauigkeit ist nicht unbegrenzt, sondern liegt im Rahmen dessen, was eine Gleitkommaberechnung hergibt. Die äußeren Grenzen des Wertebereiches liegen eben bei 10^-38 bis 10^38, während Schwarz auf 0 und Weiß auf 1 festgelegt ist. Da bleibt also eine unglaubliche Reserve für Werte tiefer als Schwarz und höher als Weiß.
Die 32 Bit sagen hier erstmal gar nichts über den Wertebereich, sondern das ist hier ja nur die Eigenschaft der Gleitkommaberechnung. Mit 32 integren Werten hat das nichts zu tun.
Wenn nun der verfügbare Wertebereich mit dem eines integren Prozessings verglichen werden soll, muss der Bereich des Floatpoint-Prozessings als Wertebereich herangezogen werden, der zwischen 0 und 1 darstellbar ist. Wie weit dieser Bereich in integren Werten ausgedrückt ist, kann ich nicht genau sagen, aber es genügt, um selbst 24-Bit-Integer präzise abzubilden. Wenn 32 Bit, dann bleiben doch aber auch nur maximal 2^32 darstellbare Werte. Mehr sind doch dann in einem 32 Bit Register überhaupt nicht darstellbar?
Meiner Meinung nach ist es doch egal, ob man Schwarz = "0" und Weiß = "1" annimmt und dazwischen alle möglichen Nachkommawerte zulässt oder
(weil in YUV Werten nicht anders darstellbar) zwischen 16 und 235 alle möglichen Werte mit Nachkommastelle möglich sind.
Ich vermute, dass ich da etwas nicht ganz verstehe.

Bezüglich deines Testes nochmal:
Die Datei, die du als letzte verlinkt hattest war nur ein HQ File. War das so gedacht?
Wenn du ungewollt HQ anstelle HQX exportiert hast und die HQ-Datei als Grundlage
beim Dekodieren benutzt hast, würde das die 8 Bit beim Dekodieren und das Banding erklären.

Jim



Antwort von Marco:

Zum Test hatte ich die hier zuerst verlinkte HQX-Datei verwendet. Die, die du quasi auch »positiv« auf 10 Bit getestet hattest.

Vielleicht macht es nochmal einen Unterschied, ob ich ein 10-Bit-HQX verwende, das aus Vegas Pro exportiert wurde oder eines, das beispielsweise aus Edius kommt. Denn auch MediaInfo interpretiert ja das HQX von Vegas Pro falsch.

Aber ich gehe das zur Sicherheit nochmal neu an.



Antwort von Jim_pansen:

Zum Test hatte ich die hier zuerst verlinkte HQX-Datei verwendet. Die, die du quasi auch »positiv« auf 10 Bit getestet hattest.

Vielleicht macht es nochmal einen Unterschied, ob ich ein 10-Bit-HQX verwende, das aus Vegas Pro exportiert wurde oder eines, das beispielsweise aus Edius kommt. Denn auch MediaInfo interpretiert ja das HQX von Vegas Pro falsch.

Aber ich gehe das zur Sicherheit nochmal neu an. Bin gespannt, was dabei heraus kommt.
Es wäre doch reichlich inkonsequent, wenn das Decoding nicht mit 10 Bit funktionieren würde.

Jim



Antwort von mash_gh4:

Der Wertebereich, auf den sich das Prozessing in Vegas bezieht, sofern es kein 8-Bit-Projekt ist, ist Floatpoint-basierend. Es gibt keinen fixen Wertebereich. Es sind nicht 2 hoch 32. Es gibt daher in einem solchen Projekt in der Praxis keine Grenzen für Über- und Unterbelichtungen (die Grenzen sind so extrem hoch, dass sie selbst bei extremer Postpro nicht ausgereizt werden). ich fürchte, dass was du da über über die vorzüge der fließkomma-darstellung erzählst, wird der wahrheit nicht wirklich gerecht. du kannst zwar mit den entsprechenden daten-typen einen relativ großen wertebereich darstellen, aber nur mit begrenzter genauigkeit. so gesehen zählt letztlich dann doch wieder nur die anzahl der genutzen bits. aber, lass ma das lieber.

was aber im konkreten fall eine wichtigere rolle spielen dürfte, ist die frage, wie die jeweiligen programme mit geringer aufgelösten daten umgehen?

es zeigt sich nämlich in der praxis immer wieder, dass die hier beschriebene methode zu anderen resultaten führt, wenn man 8-bit files importiert als wenn man 10-bit formate benutzt, aber die daten darin in wahrheit auch nur 8-bit nutzen -- also genau den selben inhalt besitzen. dass sich die ergebnisse trotzdem unterscheiden, hat mit entsprechender optimierung bzw. genauigkeit der berechnungen zu tun.

für den test hier spielt das keine so große rolle, weil man ohnehin nur die betreffenden störungen sehen will. wenn man dagegen diese einflüsse ausklammern will, während man sein 8-bit material grenzwertig malträtiert, kann es sehr wohl sinn machen, explizit eine höhere berechnungsgenauigkeit bzw. interne darstellung zu nutzen.



Antwort von Marco:

Neuer Test: Dieselbe V210-Datei als Referenz. Einmal in Edius als 10-Bit-HQX gerendert, einmal in Vegas Pro.

Referenz, Edius- und Vegas-Version in Vegas Pro miteinander verglichen. Ähnliches Banding bei beiden HQX-Dateien, wo in der Referenz noch kein Banding auftaucht.
Das Banding lässt sich dort schon dann nachweisen, wenn nur der Wertebereich von Studio-Swing auf Full-Swing gespreizt wird. Eben so, wie man es von 8 Bit kennt.



Antwort von Jim_pansen:

Neuer Test: Dieselbe V210-Datei als Referenz. Einmal in Edius als 10-Bit-HQX gerendert, einmal in Vegas Pro.

Referenz, Edius- und Vegas-Version in Vegas Pro miteinander verglichen. Ähnliches Banding bei beiden HQX-Dateien, wo in der Referenz noch kein Banding auftaucht.
Das Banding lässt sich dort schon dann nachweisen, wenn nur der Wertebereich von Studio-Swing auf Full-Swing gespreizt wird. Eben so, wie man es von 8 Bit kennt. Das ist ja doof. Also doch nur 8Bit Decoding!

Jim



Antwort von Marco:

@mash_gh4

Ich sehe die besonderen Vorzüge von Floatpoint ja gar nicht in dem Bereich zwischen 0 und 1, der aber letztlich (in Bezug auf diese Diskussion hier) mit dem Wertebereich von 0 bis 1024 für 10 Bit Integer verglichen werden müsste. Es ist bestenfalls wichtig zu wissen, dass dieser Wertebereich zwischen 0 und 1 groß und präzise genug ist, um auch 10 Bit Integer (und mehr) damit korrekt als Videosignal abzubilden. Die Rundungsfehler, die sich dabei ergeben, sind für eine spätere Abbildung auf 10 Bit (das ist unser Thema hier) vernachlässigbar. Daraus lassen sich die hier besprochenen Effekte nicht erklären.
Es gäbe zu Floatpoint noch ein paar andere, je nach Betrachtungsweise, negative Aspekte, die aber alle komplett am Thema vorbeigehen.

Ich sehe, wie oben geschrieben, den besonderen Vorzug in dem Bereich unter 0 und über 1, der aber für diese Diskussion in der Tat überhaupt keine Rolle spielt, dennoch aufzeigt, dass es gravierende Unterschiede zwischen dem Videoprozessing mit integrer Abbildung des Wertebereiches und Floatpoint-Prozessing gibt.



Antwort von Marco:

Nochmal zurück auf Null.

Gewünscht wären 10 Bit, aber kein Quicktime.

HQX als 10 Bit funktioniert wohl nicht in Vegas Pro.
CineForm funktioniert, fürs Encoding muss aber erst eine Lizenz her.
V210 (Sony YUV 10 Bit) funktioniert, erzeugt aber riesige Dateien.
Panasonic P2 funktioniert, erzeugt aber für jeden Rendervorgang eine eigene Ordnerstruktur, so dass die Clipverwaltung später unsinnig komplex wäre.

Dann bleiben nur noch:

XAVC
HDCAM SR

Qualitativ ist HDCAM SR vermutlich die bessere Wahl. Es rendert auch schneller und ich würde bei großen, komplexen Projekten weniger Probleme bezüglich der Stabilität erwarten. Die Dateigröße ist aber etwa viermal so groß wie ein vergleichbares XAVC (für HDCAM SR ca 1 GB pro 30 Sekunden, ca. 360 Mbit/s).

Alle Infos hier in Bezug darauf, dass auch von Vegas aus das Rendern zum Intermediate geschehen würde, da es schwierig sein wird, einen externen Batchkonverter für HDCAM SR zu finden. Extern bliebe für 10 Bit wohl nur noch XAVC übrig.

Wenn sich davon nichts für das Projekt eignen sollte, bleibt nur der Rückzug zu 8 Bit (und dann würde ich XDCAM HD 422 nehmen) oder der Umzug auf ein anderes System.



Antwort von Jim_pansen:

Ich kenne HDCAM SR ausschließlich als digitales Bandformat.
So wie du es aufzählst, könnte man meinen, es würde sich um einen Codec handeln.
Gibt es denn tatsächlich ein Exportformat dieses Namens in SONY Vegas?
Sorry für meine Unwissenheit, aber Vegas habe ich mir nie zu Gemüte gezogen.

Jim



Antwort von Marco:

Ja, in Vegas Pro kann »Sony HDCAM SR« im MXF-Container in verschiedenen Varianten mit 4:2:2- oder 4:4:4-Sampling exportiert oder nativ verarbeitet werden.

Auch die Sony Raw-Viewer bieten HDCAM SR als Exportformat.

Da fällt mir gerade noch ein, dass die Variante »HDCAM SR Lite 422« hier unter Umständen besonders interessant sein könnte. Ich glaube, da ist die Datenrate gegenüber der normalen 422-Version etwa halbiert.



Antwort von Jim_pansen:

Ja, in Vegas Pro kann »Sony HDCAM SR« im MXF-Container in verschiedenen Varianten mit 4:2:2- oder 4:4:4-Sampling exportiert oder nativ verarbeitet werden.Danke für die Erklärung.
Soweit ich mich recht erinnere wurde für's Band ein MP4-Derivat verwendet,
der Codec wird sich wohl sicher daran orientieren.
Würde mich interessieren, von welchen Anwendungen der überhaupt gelesen werden kann.

Jim



Antwort von Marco:

Das weiß ich auch nicht so genau. Können nicht diverse Decklink-Produkte (Software) und Final Cut Pro X damit umgehen?

Ich habe es bisher nur hin und wieder für »von Vegas – für Vegas« benutzt.

Und – ja, es handelt sich um MPEG-4 Visual und entspricht wohl den Sony-Spezifikationen fürs Bandformat.



Antwort von mash_gh4:

Ich sehe, wie oben geschrieben, den besonderen Vorzug in dem Bereich unter 0 und über 1, der aber für diese Diskussion in der Tat überhaupt keine Rolle spielt, dennoch aufzeigt, dass es gravierende Unterschiede zwischen dem Videoprozessing mit integrer Abbildung des Wertebereiches und Floatpoint-Prozessing gibt. ich würde sagen, dass die digitale datenverarbeitung immer wieder zeigt, dass man im grunde nicht nur auf dieses "unter 0 und über 1" getrost verzichten kann, sondern sogar auch auf alles zwischen 0 und 1. ;)

manche dinge sehe ich offenbar doch ein bisserl anders als du.



Antwort von thsbln:

Nochmal zurück auf Null.

Gewünscht wären 10 Bit, aber kein Quicktime.

HQX als 10 Bit funktioniert wohl nicht in Vegas Pro.
CineForm funktioniert, fürs Encoding muss aber erst eine Lizenz her.
V210 (Sony YUV 10 Bit) funktioniert, erzeugt aber riesige Dateien.
Panasonic P2 funktioniert, erzeugt aber für jeden Rendervorgang eine eigene Ordnerstruktur, so dass die Clipverwaltung später unsinnig komplex wäre.

Dann bleiben nur noch:

XAVC
HDCAM SR

Qualitativ ist HDCAM SR vermutlich die bessere Wahl. Es rendert auch schneller und ich würde bei großen, komplexen Projekten weniger Probleme bezüglich der Stabilität erwarten. Die Dateigröße ist aber etwa viermal so groß wie ein vergleichbares XAVC (für HDCAM SR ca 1 GB pro 30 Sekunden, ca. 360 Mbit/s).

Alle Infos hier in Bezug darauf, dass auch von Vegas aus das Rendern zum Intermediate geschehen würde, da es schwierig sein wird, einen externen Batchkonverter für HDCAM SR zu finden. Extern bliebe für 10 Bit wohl nur noch XAVC übrig.

Wenn sich davon nichts für das Projekt eignen sollte, bleibt nur der Rückzug zu 8 Bit (und dann würde ich XDCAM HD 422 nehmen) oder der Umzug auf ein anderes System.
Herzlichen Dank an alle Beteiligten hier!!

Ich werde mal die Möglichkeiten durchtesten, auch Cineform, das GoPro Studio verspricht mir in der gratis Version immerhin

"GoPro CineForm Codec bietet bis zu 1080p mit kräftigen Farben bei Benutzung einer Drittanbieter-Software"

hehe, genau das will ich ja ;-)


P.S. Was die Datenmenge bei HDCAM SR betrifft, bei meinen ProRes aus den BM's komme ich bei 142 Sek auf 3,08 GB, wenn da dann noch ein Viertel mehr an Datenmenge dazu kommt, kann ich damit leben, so es funktioniert und ich nicht mitten im Projekt emigrieren muß.
Für die Zukunft werd ich dann wohl Vegas verlassen...



Antwort von wolfgang:

Wolfgang,
ich will ja eigentlich nicht kleinlich sein, aber was meinst du mit Integer Projekt? Jim,

ich war gestern nicht mehr da, aber Marco hat das ohnedies perfekt erklärt. Es ist einfach der Unterschied zwischen Gleitkommaberechnung und Ganzahl-berechnung.

Und Edius hat eben eine 10bit Integer-Berechnung aber leider nicht die präzisere Gleitkommaberechnung (32bit floating point) wie sie etwa Vegas oder auch After Effects haben.

In der Praxis ist es tatsächlich so wie ich oben sagte: die Gleitkommaberechnung aus Vegas oder auch AE heraus liefert für deine sehr gut gemachten Testbalken praktisch absolut bandingfreie Ergebnisse, ausgehend vom YUV-Bild. Die 10bit integer Berechnung liefert tatsächlich auch mit deinem Testbild ein ganz zartes Banding.

So nebenbei kann man also deine sehr guten Testbilder sogar dafür nutzen, um sich endlich mal die Unterschiede zwischen 32bit floating point und 10bit integer Berechnung anzusehen. Um zu sehen was TMPGenc hier macht habe ich genau diesen Umstand angewendet - und zusätzlich dein YUV-estbild auch noch aus Edius und auch aus TMPGenc heraus zum HQX codec gerechnet. Und die Ergebnisse sind eben so, dass Edius und TMPGenc hier die gleiche Qualität (sprich ganz zartes banding) liefert - und die 32bit floating point Methode noch einen Tick besser ist.

Dass Edius heute "nur" den 10bit Modus hat könnte man als einen Nachteil empfinden. Mag es auch sein wenn man auf das letzte i-Tüpfelchen Qualität Wert legt. Der große Vorteil dieses Modus ist aber seine Geschwindigkeit - denn 32bit floating point benötigt halt enorm viel Rechenleistung und ist damit in der Vorschau viel langsamer, und ich der Berechnung ebenso. Edius hat halt nur den einen, Vegas nur den anderen Modus. Toll wäre es, wenn wir beide Modi in all unseren NLEs hätten. :)



Antwort von wolfgang:

@ Marco,

also die Schlussfolgerungen finde ich interessant, aber sie wiedersprechen auch den ersten Befunden. In den Testfiles von Jim zeigt sich viel stärkeres Banding wenn man den HQX Export seiner Files als HQX-Quicktime aus Vegas heraus macht. Das habe ich mal als 8bit interpretiert.

Aber ich habe den Export seiner Testdatein sowohl aus Vegsa wie auch aus Edius gemacht - und Vegas zeigt dort noch etwas weniger Banding als der Export aus Edius heraus.

Wie kann das sein? Als einzigen mögliche Erklärung würde ich noch sehen dass der Canopus HQX beim Export ausVegas heraus nicht neu berechnet worden ist. Das wäre möglich.



Antwort von Jim_pansen:

Ein Smartrendering bei nicht nativ integrierten Codecs halte ich für sehr unwahrscheinlich.

Jim



Antwort von Marco:

->Hier ist ein Vegas-Projekt inklusive der Testclips, in dem man es deutlich sieht.

Das Projekt muss auf »32-Bit Gleitkomma (Videolevel)« und die Vorschau auf »Optimal/Voll« eingestellt sein.

Das Histogramm muss geöffnet sein mit der Ansicht »Luminanz/R/G/B«.

In den Spuren sind gegenübergestellt die V210-Referenz, ein Edius-HQX, ein Vegas-HQX und ein 8-Bit-Signal. Die Signalspreizung ist schon fertig angelegt (also Video-Output-FX), so dass man nur noch durch die Spuren schalten und die Ansicht des Histogramms verfolgen muss.



Antwort von Jim_pansen:

Es scheint, dass SONY Vegas die HQX Files via VfW ausliest.
Das limitiert die Bittiefe tatsächlich auf 8 bit.

Jim



Antwort von wolfgang:

Ein Smartrendering bei nicht nativ integrierten Codecs halte ich für sehr unwahrscheinlich. Tja, aber das beobachte ich bei Canopus HQX definitiv bei meinem letzten UHD-Projekt in Vegas. Das Material liegt bei Vegas in der timeline. Teile, die nicht mit Helligkeits- oder Farbkorrekturen versehen sind, werden ohne neuerliche Kompression aus dem 32bit floating point Projekt ausgegeben (sieht man an der Bildschirmanzeige die einen diesbezüglichen Text auswirft).

Ob unwahrscheinlich ode wahrscheinlich weiß ich nicht - es ist aber so.



Antwort von Jim_pansen:

Ein Smartrendering bei nicht nativ integrierten Codecs halte ich für sehr unwahrscheinlich. Tja, aber das beobachte ich bei Canopus HQX definitiv bei meinem letzten UHD-Projekt in Vegas. Das Material liegt bei Vegas in der timeline. Teile, die nicht mit Helligkeits- oder Farbkorrekturen versehen sind, werden ohne neuerliche Kompression aus dem 32bit floating point Projekt ausgegeben (sieht man an der Bildschirmanzeige die einen diesbezüglichen Text auswirft).

Ob unwahrscheinlich ode wahrscheinlich weiß ich nicht - es ist aber so. Nimm's mir nicht übel, aber das glaube ich nicht!
Dafür müsste der Codec nativ via SDK eingebunden sein.

Jim



Antwort von Marco:

Ehrlich gesagt konnte ich das zuerst auch kaum glauben, zumal ich skeptisch war, ob Smartrendern in einem Floatpoint-Projekt überhaupt möglich ist.

Aber ich habe es gerade mit HQX getestet und Wolfgang hat Recht. Man bemerkt es sowohl an der Zeit des Exports als auch an der Anzeige in der Vorschau, wo ein Smartrendern signalisiert wird.



Antwort von Jim_pansen:

Ehrlich gesagt konnte ich das zuerst auch kaum glauben, zumal ich skeptisch war, ob Smartrendern in einem Floatpoint-Projekt überhaupt möglich ist.

Aber ich habe es gerade mit HQX getestet und Wolfgang hat Recht. Man bemerkt es sowohl an der Zeit des Exports als auch an der Anzeige in der Vorschau, wo ein Smartrendern signalisiert wird. Ist es nicht logisch, dass an Passagen, auf denen keine Effekte liegen, der Export sehr schnell ist?
Man könnte das ja mal mit einem Differenzkey heraus bekommen, wenn man Quelle und Resultat über einander legt.

Jim



Antwort von Marco:

Ja, das ist schon logisch. Aber allein die absolute Exportzeit, unabhängig vom Effekteinsatz (ich habe es ohnehin ohne Effekte getestet) und die Signalisierung innerhalb der Vorschau ist eigentlich eindeutig. So schnell wie das bei mir geht, kann auf meinem Netbook Vegas Pro gar nicht exportieren, wenn eine Neuberechnung zwischengeschaltet ist. Und die Signalisierung fürs Smartrendern in Vegas Pro halte ich für völlig zuverlässig.



Antwort von wolfgang:

->Hier ist ein Vegas-Projekt inklusive der Testclips, in dem man es deutlich sieht. Zu diesem Projekt - also das ist natürlich mal hoch interessant. So wie ich das sehe nimmst du die 4 clips hast als Video Output FX levels drinnen.

Gut, und dann kann man die clips durch Hin- und Herschalten vergleichen. Was sehen wir hier - ich versuche mal eine Interpretation.

Alles aus Vegas heraus abgelesen (mit aktiviertem Filter):

1. auch der originale V210 clip - der ist ja 10bit YUV - zeigt ebenfalls bereits unter diesen Bedingungen im Vegasprojekt Banding. Vielleicht nicht sonderlich stark, aber doch.

2. auch der HQX Edius clip zeigt unter diesen Bedingungen Banding. Deutlich stärker als der V210 clip.

3. Auch der Vegas HQX-Clip aus Vegas zeigt Banding. Verglichen mit dem HQX Edius clip ist dieses Banding im Veags HQX Clip aber deutlich schwächer ausgeprägt.

4. Der 8bit YUV clip zeigt bei mir weniger Banding als der originale V210 clip. Wie ist der erstellt? Aus Vegas als 32bit floating point raus gerechnet?


Frage 1: Wieso ist zeigt der HQX Vegas clip schwächeres Banding als der HQX Edius clip? Mir ist klar dass der HQX Vegas clip als 32bit floating point raus gerechnet ist. Aber wenn der nur 8bit wäre - wie kann er dann besser sein als der aus Edius erstellt HQX clip?


Aber ok. Schauen wir uns das in Edius an - denn dort sollte wohl das 10bit Material mit 100%iger Sicherheit als 10bit interpretiert werden. Ich habe daher die 4 clips in ein Edius 10bit Projekt gelegt und beurteile auch hier wieder das banding.

Findings aus Edius heraus (nur die clips ohne Filter):

5. der 8bit YUV clip zeigt auch in Edius weniger Banding als der 10bit YUV Ausgangsclip.

6. der HQX Edius clip zeigt auch aus Edius heraus weniger banding als der HQX Vegas clip

7. der HQX Vegas clip zeigt in Edius sogar deutlich weniger banding als der 10bit YUV Ausgangsclip.

Das ist also eigentlich der gleiche Befund. Sowohl aus Edius wie auch aus Vegas heraus zeigt der HQX Vegas clip weniger Banding als das Ausgangsmaterial 10bit.

Ich frage mich nun - Frage 2: wenn der Ansatz stimmt, über Banding nachweisen zu wollen ob Canopus HQX in Vegas als 8bit oder als 10bit interpretiert wird. Wenn das stimmt, wieso zeigt dann der "HQX Vegas Clip" sowohl in Vegas wie auch in Edius weniger Banding als das Ausgangsmaterial?

Ist genau dieser Befund nicht der Beleg dafür, dass
a) natürlich 32bit floating point hier bessere Ergebnisse liefert, und
b) dass das HQX Material sehr wohl als 10bit interpretiert werden muss (sonst wäre es wohl schlechter).

Bei a) bin ich mir recht sicher dass das stimmt. Bei b) bin ich mir weniger sicher. Vielleicht liefert ja 32bit floating point selbst bei einer Interpretation als 8bit bessere Ergebnisse als der 10bit clip Edius HQX selbst?



Antwort von Jim_pansen:

Sorry, Wolfgang, aber da muss bei dir etwas schief gelaufen sein!
Meine Screenshots in meinem Test können deinen Befund in Edius nicht bestätigen.
Mit welcher Edius-Version arbeitest du?

Jim



Antwort von Marco:

Du siehst im Histogramm des V210-Clips Banding? Echte Lücken?
Und der 8-Bit-Clip zeigt bei dir weniger Lücken als die V210-Referenz?
Dein Projekt steht auf Gleitkomma Videolevel?

Bei mir ist das nicht so, siehe Screenshots: Die V210-Referenz ist die einzige Quelle, die in diesem Projekt noch ein lückenloses Histogramm zeigt.

V210-Referenz


HQX

zum Bild




Antwort von dienstag_01:

Wenn man einen perfekten Luminanzverlauf in 10bit auf einem, sagen wir mal nicht 8bit, aber 6bit Monitor - es gibt ja etliche, die die 8bit nicht ganz schaffen - anschaut, wird man immer Banding haben. Das hat mit dem Ausgangsfile und dem NLE herzlich wenig zu tun.
Nur mal so zum Verständnis ;)



Antwort von Jim_pansen:

Wenn man einen perfekten Luminanzverlauf in 10bit auf einem, sagen wir mal nicht 8bit, aber 6bit Monitor - es gibt ja etliche, die die 8bit nicht ganz schaffen - anschaut, wird man immer Banding haben. Das hat mit dem Ausgangsfile und dem NLE herzlich wenig zu tun.
Nur mal so zum Verständnis ;) Ich glaube, an dieser Hürde scheitert hier keiner von uns! ;)
Wenn du aufmerksam gelesen hast, dann weißt du ja eigentlich,
dass wir Banding provoziert haben. :D

Jim



Antwort von Marco:

Ich habe meinen letzten Beitrag noch um ein Screenshot des HQX-Histogramms ergänzt. Ich finde, deutlicher geht es kaum.



Antwort von thsbln:

Hüstel, ich hab ja was losgetreten! Und verstehe fast nur noch Bahnhof.

Immerhin kann ich mit GoPro Studio den Cineform-Codec nutzen und werde nun versuchen, mittels Vegasaur in Vegas meine Clips aus den jeweiligen Projekt-Dateien in die bestmögliche Qualität (Filmscan 2) zu rendern, dann sollten ja die 10bit erhalten bleiben?!

Merci!



Antwort von Jim_pansen:

Hüstel, ich hab ja was losgetreten! Und verstehe fast nur noch Bahnhof.

Immerhin kann ich mit GoPro Studio den Cineform-Codec nutzen und werde nun versuchen, mittels Vegasaur in Vegas meine Clips aus den jeweiligen Projekt-Dateien in die bestmögliche Qualität (Filmscan 2) zu rendern, dann sollten ja die 10bit erhalten bleiben?!

Merci! LOL
Ich hoffe, dir ist mit dem GoPro-Cineform Codec Pack geholfen.
Wobei ich so meine Zweifel habe und der Workflow im Grunde auch mal auf
Farbtiefe, Colorshifts und Lumaspreizungen ge-checkt werden müsste. ;)

Jim



Antwort von Marco:

Wenn du sicher sein willst, schick mir doch erstmal einen kleinen CineForm-Clip zu. Ich weiß nicht, wie sich die CineForm-Variante, die für die GoPro lizensiert ist, in Vegas Pro verhält.

Ich würde im Zweifelsfall noch am ehesten HDCAM SR vertrauen. Bei dem, was du weiter oben zu ProRes geschrieben hast, wären die HDCAM SR Lite-Dateien sogar noch etwas kleiner als die ProRes-Originale.



Antwort von wolfgang:

Sorry, Wolfgang, aber da muss bei dir etwas schief gelaufen sein!
Meine Screenshots in meinem Test können deinen Befund in Edius nicht bestätigen.
Mit welcher Edius-Version arbeitest du? Mit 7.41.28

Tja ich habe nur die Files von Marcos Projektfile genommen und in Edius hinein gelegt (10bit Projekt und dort interpretiert. Gehen wir von den gleichen Files aus? Denn ich habe seine Files (mit den 2 Frames) für meine Interpretation verwendet.

Die Interpretation erfolgt übrigens auf einem 8bit Monitor - sicherlich nicht auf einem 10bit Monitor. Aber da ich beim V210 Projekt das volle Bild sehe ist das wohl kein Problem.

Du siehst im Histogramm des V210-Clips Banding? Echte Lücken?
Und der 8-Bit-Clip zeigt bei dir weniger Lücken als die V210-Referenz?
Dein Projekt steht auf Gleitkomma Videolevel?

Bei mir ist das nicht so, siehe Screenshots: Die V210-Referenz ist die einzige Quelle, die in diesem Projekt noch ein lückenloses Histogramm zeigt. Doch, das Histogramm der Files sieht genauso aus wie bei dir. Ist ja dein Projekt! Und auch dei anderen Einstellugend sind damit von dir übernommen.

Was ich hier probiert habe war die Interpretation der Vorschau auf dem Vollbildschirm. Vielleicht ist das der Grund. Ich hänge hier mal snaphoots an



Antwort von mash_gh4:

also -- nur zur klarstellung, warum ich mich über die hier eingeflochtene float vs. int-debatte ein wenig lustig mache:

intern wird auch bei verwendung von integer datenrepräsentation sicher nie mit 10bit auflösung gerechnet, sondern immer mit 8, 16 od 32 bit breite.

16bit reichen aber im vorliegenden fall mit größter wahrscheinlichkeit bereits aus, um keinen unterschied zur float (32bit) bearbeitung sichbar werden zu lassen.

einige bedeutsamkeit bzw. aufmerksamkeit verdient übrigens auch die tatsache, dass es einen großen unterschied macht, ob 10bit daten einfach nur auf 8 bit gerundet bzw. abgeschnitten werden (bspw. mit einem verschieben der bits um zwei stellen nach rechts), oder aber, im wissen um die beschränkung des verwendeten ausgabe-kanals, vorsorglich sauber für 8-bit darstellung aufbereitet werden. im letzteren fall wird gewöhlich mit dithering u.ä. eine ausgabe erzeugt, die deutlich weniger banding zeugt bzw. auffallend besser wirkt als abgeschittene übergangswerte. das ist auch der grund, warum vernünftig optimiertes 8bit material oft deutlich befriedigender wirken kann als 10bit quellen, die auf billigen 8bit monitoren angezeigt werden oder in technisch unzureichender weise in 8bit delivery-codecs gepackt wurden.



Antwort von wolfgang:

intern wird auch bei verwendung von integer datenrepräsentation sicher nie mit 10bit auflösung gerechnet, sondern immer mit 8, 16 od 32 bit breite.

16bit reichen aber im vorliegenden fall mit größter wahrscheinlichkeit bereits aus, um keinen unterschied zur float (32bit) bearbeitung sichbar werden zu lassen. Gut, hier ist ein Unterschied sichtbar. Ob das nun aber ein Artefakt ist, kann zumindest ich schwer beurteilen. Ich weiß ja nicht wie es bei den Anderen aussieht - aber ich habe hier 8it Schirme stehen, und sicherlich keine sonderlich tollen.
oder aber, im wissen um die beschränkung des verwendeten ausgabe-kanals, vorsorglich sauber für 8-bit darstellung aufbereitet werden.
...

das ist auch der grund, warum vernünftig optimiertes 8bit material oft deutlich befriedigender wirken kann als 10bit quellen, die auf billigen 8bit monitoren angezeigt werden oder in technisch unzureichender weise in 8bit delivery-codecs gepackt wurden. Kann gut sein dass dies mitspielt. Aber dann können wir uns von diesen Ansätzen hier eher verabschieden. Einfach, weil es mit 8bit Geräten dann kaum zu beurteilen wäre?



Antwort von thsbln:

LOL
Ich hoffe, dir ist mit dem GoPro-Cineform Codec Pack geholfen.
Wobei ich so meine Zweifel habe und der Workflow im Grunde auch mal auf
Farbtiefe, Colorshifts und Lumaspreizungen ge-checkt werden müsste. ;)

Jim Oh Gott!



Antwort von Jim_pansen:

16bit reichen aber im vorliegenden fall mit größter wahrscheinlichkeit bereits aus, um keinen unterschied zur float (32bit) bearbeitung sichbar werden zu lassen. Das ist auch meine Vorstellung dazu.
einige bedeutsamkeit bzw. aufmerksamkeit verdient übrigens auch die tatsache, dass es einen großen unterschied macht, ob 10bit daten einfach nur auf 8 bit gerundet bzw. abgeschnitten werden (bspw. mit einem verschieben der bits um zwei stellen nach rechts), oder aber, im wissen um die beschränkung des verwendeten ausgabe-kanals, vorsorglich sauber für 8-bit darstellung aufbereitet werden. im letzteren fall wird gewöhlich mit dithering u.ä. eine ausgabe erzeugt, die deutlich weniger banding zeugt bzw. auffallend besser wirkt als abgeschittene übergangswerte. das ist auch der grund, warum vernünftig optimiertes 8bit material oft deutlich befriedigender wirken kann als 10bit quellen, die auf billigen 8bit monitoren angezeigt werden oder in technisch unzureichender weise in 8bit delivery-codecs gepackt wurden. Abschneiden kenne ich auch nur in dem Fall, wenn 10 Bit Material über eine 8 Bit Schnittstelle gelesen wird.
Dann wird tatsächlich abgeschnitten! Und das ist in dem Fall auf Grund der technischen Beschränkungen,
wenn auch nicht schön, völlig in Ordnung!

Wegen der geringeren Rundungsfehler bei der Anwendung von Effekten bearbeite ich 8 Bit Quellmaterial
grundsätzlich in 10 Bit Projekten.

Jim



Antwort von thsbln:

Wenn du sicher sein willst, schick mir doch erstmal einen kleinen CineForm-Clip zu. Ich weiß nicht, wie sich die CineForm-Variante, die für die GoPro lizensiert ist, in Vegas Pro verhält.

Ich würde im Zweifelsfall noch am ehesten HDCAM SR vertrauen. Bei dem, was du weiter oben zu ProRes geschrieben hast, wären die HDCAM SR Lite-Dateien sogar noch etwas kleiner als die ProRes-Originale. Danke, ach ich hab doch HDCAM SR schon wieder vergessen...

Ich kann Dir heute Abend zum Vgl ein HDCAM SR- und Cineform-file zum Vergleich in die dropbox legen, vielen Dank!!!



Antwort von Jim_pansen:

Wenn du sicher sein willst, schick mir doch erstmal einen kleinen CineForm-Clip zu. Ich weiß nicht, wie sich die CineForm-Variante, die für die GoPro lizensiert ist, in Vegas Pro verhält.

Ich würde im Zweifelsfall noch am ehesten HDCAM SR vertrauen. Bei dem, was du weiter oben zu ProRes geschrieben hast, wären die HDCAM SR Lite-Dateien sogar noch etwas kleiner als die ProRes-Originale. Danke, ach ich hab doch HDCAM SR schon wieder vergessen...

Ich kann Dir nachher was in die dropbox legen, vielen Dank! An einem Testclip hätte ich auch Interesse!

Jim



Antwort von dienstag_01:

Wegen der geringeren Rundungsfehler bei der Anwendung von Effekten bearbeite ich 8 Bit Quellmaterial grundsätzlich in 10 Bit Projekten. Bearbeite es doch gleich in einem 32bit Projekt in After Effects ;)



Antwort von Jim_pansen:

Wegen der geringeren Rundungsfehler bei der Anwendung von Effekten bearbeite ich 8 Bit Quellmaterial grundsätzlich in 10 Bit Projekten. Bearbeite es doch gleich in einem 32bit Projekt in After Effects ;) Auf keinen Fall!
Ich möchte mit meiner Arbeit auch irgendwann fertig werden! ;)
32 Bit ist in meinem Fall auch überhaupt nicht notwendig.



Antwort von dienstag_01:

32 Bit ist in meinem Fall auch überhaupt nicht notwendig. 10 Bit sicher auch nicht, ist nur die Hoffnung, dass viel viel hilft ;)
Machts aber nicht, sie Erklärung von mash_gh4



Antwort von wolfgang:

32 Bit ist in meinem Fall auch überhaupt nicht notwendig. 10 Bit sicher auch nicht, ist nur die Hoffnung, dass viel viel hilft ;)
Machts aber nicht, sie Erklärung von mash_gh4 Also diese Darstellung ist jetzt ein wenig arg verkürzt. Ich habe es nicht so verstanden, das er sich grundsätzlich gegen 10bit ausspricht. Das hat schon seine Vorteile und seine Berechtigung.

Aber er spricht die Frage an, wie diese Signale dann beim Wechsel in die 8bit Welt behandelt werden - sei es eine Vorschau auf lausigen 8bit Monitoren oder in Codecs. Das ist aber eine andere Sache.



Antwort von Marco:

»Immerhin kann ich mit GoPro Studio den Cineform-Codec nutzen«

Ich weiß ja nicht, ob das bei dir anders ist, aber ich kann in GoPro Studio gar keine ProRes-Dateien importieren.



Antwort von mash_gh4:

Also diese Darstellung ist jetzt ein wenig arg verkürzt. Ich habe es nicht so verstanden, das er sich grundsätzlich gegen 10bit ausspricht. Das hat schon seine Vorteile und seine Berechtigung. ja -- so sollte es eigentlich rüberkommen.

im wesentlichen finde ich es ohnehin wunderbar, wie hier diesem problem nachgespürt wird! nur manche interpretation der ursachen scheint mir ein wenig übers ziel hinauszuschießen.

ich selber bin bei solchen dingen immer ein wenig verführt, es gleich mit numpy (numeric python etc.) od. ähnlichem durchzuspielen bzw. zu analysieren. aber natürlich geht es auch mit ganz einfachen alltäglichen mitteln, die jeder von uns zum überprüfen vor sich stehen hat. derartige kreativität finde ich immer ganz besonders spannend. :)

dass ich diesmal nur lästernd vom rand her polemische kommentare einwerfe, statt mich selbst konstruktiv am spiel zu beteiligen, hat vor allem damit zu tun, dass für mich HQX od. ähnliche proprietäre lösungen, für die es unter linux kaum unterstützung gibt, von vornherein aus jeder engeren wahl der mittel ausgeschlossen sind. das ist aber natürlich nur meine ganz subjektive sicht der dinge. für andere kann es sich gänzlich anders darstellen, wenn sich dadurch gangbare wege auftun.

und natürlich finde ich 10bit ausgangsmaterial und eine ausreichende minimierung der berechnungsfehler in der verarbeitung höchst wünschenswert. allerdings darf man dabei den abschließenden export in konventionelle 8bit zielformate od. darstellungseinschränkungen nicht völlig unterschätzen od. übersehen. sonst ist es ungefähr so, als würde man ein foto mühsam in hoher auflösung in seinen details bearbeiten und dann ganz zum schluss mit völlig untauglichem nearest-neighbor scaling verkleinern.



Antwort von dienstag_01:

Also diese Darstellung ist jetzt ein wenig arg verkürzt. Ich habe es nicht so verstanden, das er sich grundsätzlich gegen 10bit ausspricht. Das hat schon seine Vorteile und seine Berechtigung.

Aber er spricht die Frage an, wie diese Signale dann beim Wechsel in die 8bit Welt behandelt werden - sei es eine Vorschau auf lausigen 8bit Monitoren oder in Codecs. Das ist aber eine andere Sache. Ja, hier ist ja auch kein 10bit Workflow gemeint, sondern ein Workflow, der 8bit-Material in einem 10bit-Projekt bearbeitet.



Antwort von mash_gh4:

Ja, hier ist ja auch kein 10bit Workflow gemeint, sondern ein Workflow, der 8bit-Material in einem 10bit-Projekt bearbeitet. ja -- es gibt bekanntlich diese erkennbaren fehler, die nicht den schwächen des 8bit ausgangsmaterials anzulasten sind, sondern einer unzureichend genauen bearbeitung bzw. deren eingriffen. in dem fall reicht es oft wirklich, wenn man das 8bit ausgangsmaterial nur gleich sorgsam wie 10bit quellen behandelt.



Antwort von Jim_pansen:

32 Bit ist in meinem Fall auch überhaupt nicht notwendig. 10 Bit sicher auch nicht, ist nur die Hoffnung, dass viel viel hilft ;) Anspruch ist es doch vielmehr, die Kette bei der Verarbeitung auch ohne Not so sauber, wie möglich
zu halten, erst recht, wenn es doch überhaupt keinen Mehraufwand macht. Sicherlich ist der Effekt,
den andere sich davon versprechen, eher im Promillebereich zu verorten. Aber in der Kaskade
mehrerer Effekte kann es der Qualität zuträglich sein.
Ich würde auch auf 32-Bit Floating-Point setzen, wenn Edius das als Projektparameter anbieten würde.
Ich würde aber auch nicht glauben, damit einen sichtbaren Qualitätsgewinn erzielen zu können, sondern
ich hätte einfach nur das gute Gefühl, ausgesprochen wenig Rundungsfehler in der Verarbeitungskette
verorten zu müssen.

Ich erhalte in der Regel zu 95% fertig gegradetes ProRes 10 Bit Material und ich liefere 10 Bit Material
aus. Und für die restlichen 5 % erstelle ich mir ganz bestimmt keine 8 Bit Preset.
Das ist mir doch die Mühe gar nicht wert. ;)

Jim



Antwort von wolfgang:

Ja, hier ist ja auch kein 10bit Workflow gemeint, sondern ein Workflow, der 8bit-Material in einem 10bit-Projekt bearbeitet. Also (von meiner Seite) definitiv nicht! Wie kommst zu dieser Einschätzung?



Antwort von thsbln:

Wenn du sicher sein willst, schick mir doch erstmal einen kleinen CineForm-Clip zu. Ich weiß nicht, wie sich die CineForm-Variante, die für die GoPro lizensiert ist, in Vegas Pro verhält.

Ich würde im Zweifelsfall noch am ehesten HDCAM SR vertrauen. Bei dem, was du weiter oben zu ProRes geschrieben hast, wären die HDCAM SR Lite-Dateien sogar noch etwas kleiner als die ProRes-Originale. Danke, ach ich hab doch HDCAM SR schon wieder vergessen...

Ich kann Dir nachher was in die dropbox legen, vielen Dank! An einem Testclip hätte ich auch Interesse!

Jim
So, hier sind 3x2Sekunden, einmal das ProRes HQ aus der BMPCC, dann jeweils aus Vegas gerendert ein Cineform (Qualität Filmscan 2) und ein HDCAM SR:

https://www.dropbox.com/s/fiore0jm47osx ... s.zip?dl=0

@Marco: ich habe mit GoPro Studio gar nichts gemacht, sondern es nur wegen des Cineform-Codecs installiert.



Antwort von dienstag_01:

Also (von meiner Seite) definitiv nicht! Wie kommst zu dieser Einschätzung? Nö, habe ich auch nie behauptet ;)
Hier ist der Bezug: Wegen der geringeren Rundungsfehler bei der Anwendung von Effekten bearbeite ich 8 Bit Quellmaterial grundsätzlich in 10 Bit Projekten.



Antwort von thsbln:

[

So, hier sind 3x2Sekunden, einmal das ProRes HQ aus der BMPCC, dann jeweils aus Vegas gerendert ein Cineform (Qualität Filmscan 2) und ein HDCAM SR:

https://www.dropbox.com/s/fiore0jm47osx ... s.zip?dl=0

@Marco: ich habe mit GoPro Studio gar nichts gemacht, sondern es nur wegen des Cineform-Codecs installiert. Oooh, sch** !! Kommando zurück, ich glaube ich habe diese Clips aus einem 8-bit-Projekt gerendert! Ich Depp. Ich bin erst in zwei Stunden wieder zurück am Schnittrechner und kann dann nochmal aus einem 32bit-floating-point-o.ä.-Projekt rendern.



Antwort von Jim_pansen:

»Immerhin kann ich mit GoPro Studio den Cineform-Codec nutzen«

Ich weiß ja nicht, ob das bei dir anders ist, aber ich kann in GoPro Studio gar keine ProRes-Dateien importieren. Nein, ProRes geht nicht, aber der Cineform-Codec steht nach der Installation systemweit zur Verfügung.
Das GoPro Studio hat im Grunde nicht viel zu bieten.

Jim



Antwort von Marco:

»der Cineform-Codec steht nach der Installation systemweit zur Verfügung.«

So wie das hier aussieht aber nur für die Decodierung – und das wäre für Vegas Pro nicht notwendig, da Vegas Pro schon nativ mit der Decodierung von CineForm ausgestattet ist.

Aber ich kann trotz Installation von GoPro Studio in Vegas Pro kein CineForm exportieren.



Antwort von Jim_pansen:

Ich kann das via QuickTime aus Edius heraus tun.
Ob der AVI Codec auch in Vegas zur Verfügung steht,
kann ich nicht sagen, ich könnte aber in Virtualdub
exportieren. AE müsste ich mal probieren.
Hab ich aber gerade keinen Nerv dafür...

Jim



Antwort von Marco:

Das war der springende Punkt. Ich kannte den CineForm-Export in der Vergangenheit nur im AVI-Container. Als AVI funktioniert der Export aus Vegas Pro nicht. Im MOV-Container funktioniert es.

Nur drehen wir uns damit nun im Kreis, da ja Quicktime eigentlich vermieden werden sollte. Für den MOV-Container hätte ja vermutlich auch GV HQX in 10 Bit funktioniert.

Die gute Nachricht:
Im CineForm ist keinerlei zusätzliche Signalveränderung zu erkennen und die Wiedergabe-Performance ist ebenfalls recht gut.



Antwort von Jim_pansen:

Im Grunde muss doch der Workflow nur abgesichert werden.
Oder funktioniert QT generell in Vegas nicht?
Bedauerlich, dass QuickTime so sehr vernachlässigt
wurde.

Jim



Antwort von thsbln:

Aus Vegas Pro 12 funktioniert der Cineform-export in einem AVI-Container, Marco,
hier sind jetzt nochmal 3x2Sekunden, einmal das ProRes HQ aus der BMPCC, dann jeweils aus Vegas gerendert ein Cineform (Qualität Filmscan 2) und ein HDCAM SR, dieses Mal aus einem 32bit-floating-point-Projekt (Videlevel) in Vegas:

https://www.dropbox.com/s/3mji1y0thbxc0 ... r.zip?dl=0



Antwort von Marco:

Doch, im Prinzip funktioniert Quicktime. Aber viele Quicktime-Formate zeigen dort Signalveränderungen (wie den berüchtigten Gamma-Shift), schlechte Wiedergabeleistung, etc.

Besonders gefürchtet ist jedoch irgendein bisher nicht genau lokalisiertes Speicherleck, bei der die Vermutung besteht, dass es mit der 32-Bit-Basis von Quicktime zu tun hat. Ich weiß nicht, ob das bei allen Quicktime-Dateien auftritt, aber es wird immer wieder berichtet, dass eine hohe Anzahl von Quicktime-Dateien in Vegas Pro letztlich zu Programmabstürzen führt.

Das Ding dabei ist, dass der Threadstarter aus genau diesem Grund auf der Suche nach dem bestmöglichen Intermediate ist. Wenn nun diese CineForm-Variante zwar gut anläuft, aber mit zunehmender Komplexität des Projektes zu den gleichen Problemen führt, dürfte er langsam wahnsinnig werden.

Nun kann ich zwar sogar die Dateien von »*.mov« in »*.avi« umbenenen. Die Clips funktionieren genauso gut. Aber sie werden dann in Vegas Pro auch immer noch per Quicktime-Plug-in decodiert.



Antwort von Marco:

»Aus Vegas Pro 12 funktioniert der Cineform-export in einem AVI-Container,«

Wenn sie dann auch ohne Quicktime-Plug-in decodiert werden, wäre das vermutlich eine gute Lösung. Wenn’s aber doch über Quicktime laufen sollte …



Antwort von thsbln:

Aha, AVI kann auch MOV sein?

Dann sch*+ drauf, ich werde auf HDCAM SR ausweichen - wenn Ihr beiden, Jm und Marco, vielleicht da mal einen blick drauf werfen wollen würdet, wie das aus Vegas exportiert wurde? (https://www.dropbox.com/s/3mji1y0thbxc0 ... r.zip?dl=0)

Vielen Dank!



Antwort von dienstag_01:

Dafür, dass Avid fast ausschließlich auf Quicktime aufsetzt, stürzt es aber relativ wenig ab (eigentlich fast nie). Müsste doch eigentlich ständig crashen ;)



Antwort von Marco:

Was für ein wertvoller Beitrag :D

AVI kann nicht MOV sein (das sind ja nur die Dateitypen), aber eine AVI-Datei kann in Vegas Pro zu dem Quicktime-Plug-in, das zu Vegas Pro gehört, geführt werden, damit die in der Datei enthaltende Codierung dann doch letztlich über die Quicktime-Architektur läuft.

Wenn du aber aus Vegas Pro CineForm auch als AVI exportieren kannst, wird es dort vielleicht auch ohne das Quicktime-Plug-in decodiert.
Das kann ich bisher leider nicht prüfen, da da bei mir auch mit Vegas Pro 12 nicht funktioniert.

Der Download läuft gerade. Leider ist die Verbindung gerade unglaublich langsam und der Download wurde schon zweimal abgebrochen.



Antwort von thsbln:

Wenn du aber aus Vegas Pro CineForm auch als AVI exportieren kannst, wird es dort vielleicht auch ohne das Quicktime-Plug-in decodiert.
Das kann ich bisher leider nicht prüfen, da da bei mir auch mit Vegas Pro 12 nicht funktioniert. Hm, das deutet ja fast auf das Gegenteil hin, wenn ich bedenke, dass ich mit verschiedenen Quicktime-Version teilweise katastophale Ergebnisse in Vegas, teilweise fast die alte ich-zeige-alles-Performance erreiche, oder?



Antwort von thsbln:

Der Download läuft gerade. Leider ist die Verbindung gerade unglaublich langsam und der Download wurde schon zweimal abgebrochen. Leider ging es nicht kleiner, sonst hätte ich kein Original mitpacken können. laß Dir Zeit mit dem Anschauen!



Antwort von dienstag_01:

Was für ein wertvoller Beitrag :D Wertvoll vielleicht nicht, aber hilfreich, um nicht Abstürze der 32bit Programmierung von Quicktime anzulasten. Denn im Avid läuft es ja ;)



Antwort von Marco:

Was meinst du damit?

Ich fürchte, das mit dem Download wird hier heute nichts mehr. Das springt ständig zwischen 6 und 20 Stunden Dauer.

Prüfe es doch mal selbst.

Navigiere im Vegas-Explorer zu der CineForm-AVI-Datei, mach einen Rechtslick drauf und wähle »Eigenschaften«.
Scrolle in dem Fenster ganz runter und schau nach, welches Plug-in Vegas dafür verwendet.



Antwort von Marco:

Niemand hat behauptet, dass die 32-Bit-Basis von Quicktime schon die Problemursache wäre, sondern es besteht lediglich die Vermutung, dass es einen Zusammenhang damit gibt. Aufgrund der 32-Bit-Basis muss in Vegas für das Ansprechen von Quicktime ein Umweg gefunden werden (eine File-Surrogate-Schnittstelle, die 32-Bit-Prozesse innerhalb der 64-Bit-Anwendung umleitet). Die Abstürze werden möglicherweise von diesem File-Surrogate-Prozess verursacht. Auch das können wir dem nicht »anlasten«, sondern nur Vermutungen aufgrund bestimmter Beobachtungen anstellen.

Das nützt aber bestenfalls den Entwicklern, nicht den Anwendern.



Antwort von thsbln:

Was meinst du damit?

Ich fürchte, das mit dem Download wird hier heute nichts mehr. Das springt ständig zwischen 6 und 20 Stunden Dauer.

Prüfe es doch mal selbst.

Navigiere im Vegas-Explorer zu der CineForm-AVI-Datei, mach einen Rechtslick drauf und wähle »Eigenschaften«.
Scrolle in dem Fenster ganz runter und schau nach, welches Plug-in Vegas dafür verwendet. Oh, liegt das an dropbox oder wohnst Du in einer abgelegenen Ecke?

Ich meinte, das De/Kodieren von Cineform könne ja doch über QT laufen, da es ja bei mir läuft, aber bei Dir nicht und dies vl. auf unterschiedliche QT-Versionen zurückzuführen sein könne.
Aber unter den Eigenschaften ist als PlugIn das aviplug aufgeführt.



Antwort von Marco:

„Aber unter den Eigenschaften ist als PlugIn das aviplug aufgeführt.“

Bingo. Dann bleibt Quicktime bei dir dafür außen vor.

Meine Online-Anbindung ist zwar langsam, aber analog ist das nicht mehr :D Mehrere Stunden für 200 MB ist schon rekordverdächtig.

Ich gehe jetzt aber erstmal zurück ins Forum des Ursprungs. Hier wird es leider langsam etwas trollig.



Antwort von thsbln:

„Aber unter den Eigenschaften ist als PlugIn das aviplug aufgeführt.“

Bingo. Dann bleibt Quicktime bei dir dafür außen vor.

Meine Online-Anbindung ist zwar langsam, aber analog ist das nicht mehr :D Mehrere Stunden für 200 MB ist schon rekordverdächtig.

Ich gehe jetzt aber erstmal zurück ins Forum des Ursprungs. Hier wird es leider langsam etwas trollig. Ich glaube ich kenne nur zwei Foren, die trollfrei sind :-)

Auf Wiedersehen!



Antwort von Marco:

Ich möchte mich nur nochmal kurz bei Jim bedanken. Das war vor allem dank deiner Hilfe eine lehrreiche Diskussion, die einige wichtige Dinge geklärt hat.

Der Threadstarter hat ja jetzt mit der AVI-Variante von CineForm eine (hoffentlich) gute Lösung gefunden (und ein Link zu den Dateien hat er oben ja angegeben). Bei den CineForm-Clips weicht das Signal gegenüber dem Original sogar noch eine Winzigkeit weniger ab als HDCAM SR, das auch schon auf einem sehr hohen Niveau liegt. Und die Datenrate ist bei CineForm völlig im grünen Bereich, läuft gut in Vegas Pro.



Antwort von Jim_pansen:

Sehr gern!
Mir hat es die Erfahrung gebracht, dass HQX beim Export theoretisch sehr wohl 10Bit Farbtiefe liefern kann.
Aber letztlich muss man wohl doch bei jeder einzelnen Anwendung mistrauisch bleiben.

Greetz!
Jim



Antwort von wolfgang:

Dem Dank an Jim möchte ich mich anschließen. Das war eine lehrreiche und interessante Diskussion, und hat auch mich auf der Suche nach einem 10bit workflow ein gutes Stück weiter gebracht. Die Methode, die wir zum Schluß auf dem Tisch hatten, ist offenbar schon geeignet hier auch einen Unterschied zu erkenn. Allerdings eher über die Meßinstrumenten und halt nicht über die hier unzuverlässigen 8bit Monitore.

Eigentlich wars lange Zeit eine konstruktive und friedliche Diskussion, von denen ich mir mehr wünschen würde. DAS ist der Grund warum wir Zeit in Foren verbringen. Dass dies dann immer wieder gestört wird ist ein Jammer.



Antwort von Goldwingfahrer:

Auch ich sage Danke
auch wenn die Ursprungsfrage Suche Batch-Konverter..... nicht beantwortet wurde.



Antwort von Marco:

Zum Batchrendern wurden ja mehrere Varianten erläutert. Jede davon, die auch den CineForm-AVI-Export bietet, kann genutzt werden.



Antwort von Jim_pansen:

Auch ich sage Danke
auch wenn die Ursprungsfrage Suche Batch-Konverter..... nicht beantwortet wurde. Danke, ich hab's auch für mich gemacht.

Im Sinne des Threadstarters ist aber der Workflow, um höhere Bittiefen (höher als 8) feststellen zu können beschrieben.
So kann man potenziell interessante Tools einfacher einem Test unterziehen und vielleicht einfacher eingrenzen. Um
einem möglichen Batch Tool noch näher zu kommen, gibt es möglicherweise gibt es eine kommerzielle Software. Ich
denke da an Squeeze oder Episode. Deren Engine kenne ich nicht, da weiß ich nicht, ob sich eine 10 Bit Konvertierung
von vornherein ausschließt.

Auch FFMPEG oder FFMBC sind noch nicht vom Tisch! Da müsste man mal schauen, welche 10 Bit Codecs Ausgabe tauglich sind.
Ich denke da z.B. an AVC-Intra im MXF Container. Mit einer passenden GUI, wie z.B. AnotherGUI sollte Batching möglich sein.

Jim

EDIT: Wie ich sehe, gibt es seit 09.01.2015 eine neue Version mit Watchfolder Support:
http://www.stuudio.ee/anothergui/changelog.html



Antwort von wolfgang:

Basierend auf diesen Erkenntnissenin diesem Thread habe ich die Situation für die Verarbeitung von 10bit ProRes aus dem Shogun unter Vegas weiter analysiert und hier zusammen gefasst:

http://www.videotreffpunkt.com/index.ph ... ssenstand/

Kein wirklich schöner Befund, da sich das Material in Vegas eher nur als 8bit verarbeiten läßt.



Antwort von Jim_pansen:

Nette Zusammenfassung!
Da käme dann für dich wohl Edius oder Resolve ins Spiel! :D

Dabei bräuchte SCS nur ein paar Anpassungen machen!
Was die Speicherprobleme angeht, das kann schon sein, dass die
QuickTime-Bridge-Funktion miserabel programmiert wurde. Die
funktioniert z.B. in Edius hervorragend, in After Effect und Premiere
auch. QuickTime for Windows ist zwar ein lausiges Stück Software,
aber man kann es in den Griff kriegen. Bei SCS müsste sich nur mal
jemand ausgiebigst damit beschäftigen. Ist ja prinzipiell auch kein
Hexenwerk!

Der Vollständigkeit halber habe ich das echte 16 Bit Quell-Bild zum V210 Clip in den Download Ordner gelegt.

https://drive.google.com/folderview?id= ... sp=sharing

Jim



Antwort von VideoUndFotoFan:

Bei SCS müsste sich nur mal jemand ausgiebigst damit beschäftigen. Ist ja prinzipiell auch kein Hexenwerk! Tja, das ist eben schon lange das grundsätzliche Problem von VEGAS PRO.
Daß SCS sich nicht wirklich damit ausgiebig beschäftigt.
Denn ... VP hat auch noch einige andere nicht nur ärgerliche Probleme.



Antwort von Viramedia:

Kann es eigentlich sein, dass GoPro CineForm aufgibt? Oder betrifft das nur die Suite Premium und Pro?

http://cineform.com/



Antwort von Jim_pansen:

Kann es eigentlich sein, dass GoPro CineForm aufgibt? Oder betrifft das nur die Suite Premium und Pro?

http://cineform.com/ Für mich sieht es eher so aus, als würde Cineform ein state-of-the-art Codec werden, der frei für jedermann erhältlich sein wird.
Was mich interessiert ist, wie es um die Quicktime Variante bestellt sein wird.

Jim



Antwort von wolfgang:

Die geben offenbar die Verkaufsprodukte auf. Aber die Gratisversion beinhaltet den für uns sehr interessanten Cineform codec für 4K 10bit bis zu 444 unverändert weiter (steht auf der verlinkten Seite).



Antwort von WoWu:

Kann es eigentlich sein, dass GoPro CineForm aufgibt? Oder betrifft das nur die Suite Premium und Pro?

http://cineform.com/ Wavelet Codecs haben ihre starken Seiten in hohen Bandbreiten und werden mit abnehmender Bandbreite immer schlechter in der Performanz.

Mit zunehmender spatialer Auflösung kommt man zwangsläufig an einen Punkt, an dem entweder die Bandbreite so hoch gewählt werden muss, dass es unwirtschaftlich wird, oder man derart stark in die Kompression muss, dass die eigentlichen Vorteile sich zum deutlich sichtbaren Nachteil auswirken.



Antwort von Viramedia:

Hi Wolfgang.... ja das leuchtet ein
Für welchen Weg hast Du Dich jetzt letztendlich entschieden? Immerhin warst Du ja ein schwärmer vom HQX aber wenn Du in Vegas die 10bit nicht nutzen kannst, bist Du vermutlich jetzt auch bei Cineform gelandet.... bedeutet halt wieder hohe Bandbreite...



Antwort von wolfgang:

Der Canopus HQ und HQX ist für Edius wirklich gut - und wenn man mit 8bit auskommt auch für Vegas.

Bei 10bit oder mehr nutze ich derzeit Cineform - auch deshalb weil ich derzeit keinen preiswerten Konverter zu XAVC habe, was gerade unter Vegas eine Alternativ zu Cineform wäre.

So ein preiswerter Konverter zu XAVC könnte die neue kommende Version von TMPGenc Video Mastering Works6 gerde für UHD bieten - aber das ist noch auszutesten ob das auch alle so funktioniert wie man es erwarten würde.



Antwort von Viramedia:

eigentlich wäre die Lösung nativer 10bit support in vegas.... Problem gelöst. wenns so schön wär. gell



Antwort von wolfgang:

Es gibt ja nativen 10bit support in Vegas - für die Formate
- Sony YUV 10 Bit (eine V210-Lizensierung innerhalb Vegas Pro)
- HDCAM SR
- XAVC
- Panasonic P2
- Bildsequenzen wie DPX oder EXR
- CineForm

Der Rest wird halt zumeist als 8bit interpretiert.

Bei TMPGenc 6 und XAVC hatte ich übrigens unreicht. Die neue Version encodiert zu 8bit 420 XAVC-S, leider nicht zu XAVC. Interessant ist aber eine H.264 Variante die auch 10bit mit bis zu 444 kann.

Also werde ich wohl bei Cineform bleiben.