Bezüglich der Videoqualität der X70 bin ich übrigens zu keinem schlüssigen Ergebnis gekommen.
Da sie ja bisher nur FullHD ausspuckt war es schwer für mich auszumachen wie die Kantenaufsteilung dann bei QHD aussehen wird.
Ich hatte auch einfach zu wenig Zeit da mir erstens der Quervergleich zum Consumeermodell fehlt und ich nicht per Try and Error sondern nur am Kameradisplay mit den Settings spielen konnte.
Ich brauche für einige Projekte genau so eine Kamera die auch mal andere Leute bedienen können (nicht Kameramänner) und dabei nicht 95% Ausschuss produziert wird.
Ich habe bisher eine cx730 für solche Zwecke aber deren Bild kackt einfach unsäglich ab, auch wenn der sagenhafte Bildstabilisator erstmal für eine stabile Kadrage sorgt. Es wirkt geradezu grobschlächtig und ist auch lange nicht am Systemlimit von FHD, geschweige dann dass mir die Graduation der Farben gefällt.
Vermutlich setzte ich da zu hohe Ansprüche aber ich hoffe dass sich das Material der X70 zumindest einigermassen in ein 4k Raw Projekt zur Erzielung bester FHD-Qualittät in 10bit 422 einbinden lässt - vorausgesetzt natürlich man kann diese unschöne Kantenaufsteilung abstellen.
@ ChrisS
Danke für das Muster.
Weist Du zufällig noch, mit welcher Blende Du aufgenommen hast ?
Edit:
Die Infos, die ich jetzt zu dem Problem von einem englischen Hersteller habe, sagt folgendes aus:
SONY hat zwei NAL-units SPS und PPS im Codec so ausgelegt, dass in einer Sequenz unterschiedliche Bitzahlen angewandt werden können.
Die Section 7 der H.264 Spezifikation legt das nicht explizit fest, aber die Referenzimplementierung sieht ausschliesslich 32 Bit vor.
NLEs, die sich nach dieser Referenzimplementierung, also dem Standard richten, und 32 Bit vorschreiben, können innerhalb der Sequenz nicht decodieren.
Das hauseigene Plugin (als vorgeschaltetes "Adjustment" ) ignoriert nun den variablen Header des ankommenden codierten Signals und setzt ihn zwangsweise auf 32 Bit, und reicht dann erst das Signal an den Decoder, was zu einer erfolgreichen Decodierung führt.
Über die Vor-und Nachteile konnte ich zwar etwas erfahren, aber das spielt in diesem Zusammenhang keine wirkliche Rolle.
Es ist nun zu vermuten, dass die ganzen extern einzuspielenden Plug-Ins ebenso verfahren und dass auch Premiere das Adjustment auf den Wert der Referenzimlementierung fixiert hat.
Apple unterstützt lediglich die, im Standard verifizierte und der Referenzimplementierung niedergelegte Version, nicht aber die proprietäre Auslegung der Section 7.
A WORD OF WARNING : If like me you are using Apples FCPX you may have a problem…I have not got to the bottom of this yet but FCPX should be able to ingest XAVC footage, I have tried the X70 in many XAVC frame rates with no success. A more sinister problem has occurred which I have not got to the bottom of is when you pop the SDXC card into the card reader and try to get FCPX to look at the footage you end up with a corrupt card, as can clearly be seen above. Sony do supply a plugin for XAVC called PDZK-LT2 for mac but offers no solutions for my problem.
Doug “I’ve noticed the same problem when trying to import the XAVC files from the X70. Not only is FCPX unable to read them but Sony’s very own Content Browser won’t recognize them either. There was a recent XAVC plugin for FCPX but that was only for XAVC-S which uses the MP4 container and this camera’s XAVC-HD codec uses the MXF file format. I’ve even tried a few converters but nothing seems to work. After attempting to upload the clips I was unable to view them on the camera or locate them again in the thumbnail browser. The files were still on the card but unreadable even in the camera. Very strange. I do hope there’s a firmware update coming soon that will fix this.”
So its not just me, I can get the footage into FCPX via my Ultra Studio 4K and Ultra Studio Express software but I bought this camera for its 10bit 422, cracking pictures and dual card system and the ability to transfer quickly from card for news use.
Tja, schon klar.
Solange Sony AVC nach eigenen Regeln auslegt und Apple nach der Referenzimplementierung, klappt das nicht.
Sony hat wohl, als sie die Änderung an dem Standard vorgenommen haben, einen "Intent" an die Hersteller geschickt, das ist so etwas wie eine Aufforderung, die entsprechende Änderung an der Implementierung vorzunehmen, aber es ist im Ermessen der Firma, dem zu folgen -oder die Implementierung entlang der Referenzimplementierung vorzunehmen.
(Oder, wie im Beispiel, durch ein Plug-ind die SONY Änderung einfach ausser Kraft zu setzen).
Apple hat sich offenbar dazu entschieden, die H.264 Implementierung standardkonform zu machen.
Aber es ist ja ziemlich frech, dass SONY jetzt für ihren propirtären Browser auch noch Geld verlangt.
Die sollten lieber ihre Implementierung standardkonform machen.
Aber bis ende September besteht dann ja noch Hoffnung, dass sie ihren Fehler korrigieren.
Es scheint ja nicht um den Container zu gehen sondern um die Art der Codierung, die nicht dem Standard entspricht und wenn sie im Browser einen Player implementiert haben, der standardkonform ist, dann klappt das wohl auch da nicht.
Vielleicht sollten sich die SONY Abteilung untereinander erst einmal mitteilen, was sie machen.
Da Sony in der Vergangenheit oft selbst die Standards für Broadcast-Specs gesetzt hat dürften die damit kein Problem haben auch mal neben dem Standard einen neuen zu setzen.
Von daher ist es schwierig zu sagen dass Sony nun so einer trägen Klitsche wie Apple die Hausaufgaben hinterher tragen sollte. Andere schaffen es ja auch dass der neue Codec jetzt schon läuft. Ich denke nicht dass der Fehler bei Sony liegt dass bestimmte Leute ihr Footage nicht in die Timeline bekommen.
Solang die Firmen in ihren Plug-Ins lediglich den importierten Content wieder auf den Wert in der Referenzimplementierung setzen, ist das ein ziemlich nutzloser "Standard", den Sony da setzen möchte.
Vor allen Dingen könnten davon, wenn es sich denn durchsetzen würde, nur eine Decodierung in einem DSP profitieren.
Ich weiss nun nicht, wieviele NLEs in Hardware decodieren, um das überhaupt nutzen zu können und ob nicht, bevor es sich durchgesetzt hat, schon H.265 aufgerufen ist und ob überhaupt noch jemand, ausser Sony, H.264 in ein DSP "giesst".
Jedenfalls liegt der Fehler ganz zweifelsfrei nicht bei denen, die sich an den Standard halten.
Ich würde da gar nicht von einem Fehler reden. Ich sehe es auch so, dass die Kamerahersteller Standards entwickeln und diese versuchen im Markt zu etablieren. Ich nehme an und meine es auch so gehört zu haben, dass die Kamerahersteller darüber die NLE-Programmierer unterrichten, die es danach implementieren sollten. Möglicherweise geht das zunächst erst mal nur mit ein paar Tricks, bis sich der Standard immer mehr durchsetzt. Ein gutes NLE-Entwicklerteam wird die Vorgaben der Kamerahersteller aus Eigeninteresse auch schnell umsetzen, zumal, wenn es sich um Globalplayer wie hier z.B. Sony handelt, die im stetigen Kampf um Marktanteile mit anderen Größen (Panasonic) liegen und über solche aufgebohrten Standards versuchen neue Standards zu schaffen. Das Spielchen geht doch schon ein paar Jahr so und es schlägt halt auch auf die NLE-Systeme durch. Wenn ein NLE-Hersteller ewig zögert und sich auf Standards, die es bisher gibt, ausruht, ist er evtl. mal schnell abgehängt.
Panasonic hat eigene Formate, JVC ist da noch eigenwilliger, und Sony setzt auch aufgrund seiner Marktmacht ebenso eigene Formate ein und durch. Die machen das einfach (weil sie es können). NLE Hersteller ziehen entweder nach oder lassen ihre Kunden halt im Regen stehen. So einfach ist das. Ob Standard oder nicht interessiert eigentlich (fast) nicht. Die Sache hat einfach zu funktionieren.
@Frank B.
Wir seh'n ja, was wir davon haben. Leute, die von der Kamera wieder abspringen und nicht funktionieren Content.
Und dass Apple -und andere- das nicht mitmache, dafür habe ich vollstes Verständnis, zumal die Abweichungen in Software ohnehin nichts bringen.
Und wenn einige NLE Hersteller diese Massnahme nur in ihrer Importfunktion rückgängig machen und SONY Plug-Ins austeilen muss, die dasselbe bewirken, dann ist das doch eine ziemlich zweifelhafte Änderung, die sich bei H.265 sowieso erledigt hat.
Das ist mal wieder so ein Alleingang von SONY, die schon in der Vergangenheit ziemlich schief gegangen sind.
Mir ist es offen gesagt recht egal ob Apple da mitmacht. Wenn das stimmt tun mir nur die Cutter und Anwender leid, die halt auf dieses Pferd gesetzt habe. Neue Modifikationen von codecs gehören zumindest von den drei grossen Kameraherstellern JVC, Sony und Panasonic in die Dekoder der NLEs integriert - und Encodieren kann eh jeder zu was er will.
Die Sony eigene Software Vegas ist da nicht immer, aber relativ oft vorbildlich. Sie hat ja selbst Import- wie Export-Schnittstellen zu DaVinci oder FCP-X.
Sowas ist halt für Kunden ein Nutzen, die anderen NLE Hersteller können das ja leicht auch machen - wenn sie nur woll(t)en.
Ich glaub Grassvalley setzt das auch enorm schnell um, wie auch immer. Jedenfalls reagieren die relativ schnell mit entsprechenden Upgrades. Wie das aber funktioniert, kann ich als Amateur auch nicht sagen. Mir ist es einfach wichtig, dass mein Programm das frisst, was meine Wunschkamera mir ausgibt. Allerdings bin ich auch kein Early-User, dazu fehlt mir meist die Kohle und ich warte immer erst länger ab, bis eine Kamera im Preis nachlässt. :)
Es ist doch ganz einfach. Ein NLE sollte sich doch nach dem richten was auf dem Markt existiert. Bei anderen NLE klappt es nach kürzester Zeit sogar Codecs von wesentlich kleineren Kameraherstellern in kürzester Zeit zu implementieren weil die Kunden es so wollen.
Apple glaubt zwar irgendwie dass es egal ist was ausserhalb ihres Elfenbeimturms so passiert, aber dann müssen jene die auf das Pferd Apple setzen auch mal damit leben dass sie in ihrer Wahl der Kamera beschränkt werden oder wie so oft in der Vergangenheit ihr Produktionsumfeld damit nerven dass sie die Bilder nicht in ihre Kisten bekommen.
Ich wäre nicht dazu bereit mir von meinem NLE vorschreiben zu lassen was ich importieren kann und was nicht.
Ja, schon richtig, dass muss jeder für sich allein entscheiden.
Und SONY ist ja auch in der Schadensbegrenzung sehr emsig und baut ein Plug-In nach dem andern.
Irgendwann werden sie dann ihre Änderung damit auch wieder Rückgang gemacht haben und FCPx einen standardkonformen Codec vorsetzen, der dann auch wieder mit andern Codecs kompatibel ist.
Alles eine Frage der Zeit.
Den Anwender wirds freuen. Die meisten sind einfach ein einem funktionierenden System interessiert. Wohl den Herstellern und Programmierern, die das am schnellsten realisieren können. Man sollte halt zusammen spielen und nicht gegeneinander. Von daher sind wohl die Kritiken an Codecentwicklern und -implementierern beiderseits nicht ungerechtfertigt. Man kann sicher auf beiden Seiten etwas falsch machen und im ungünstigsten Fall kann es für beide in die Hose gehen.
Aber das wird dann der Markt regulieren.
Ich wollte auch nur mal versuchen in Erfahrung zu bringen, warum plötzlich für einen Codec, der nicht nur standardisiert sondern auch bestens dokumentiert ist und für den es eine Referenzimplementierung gibt, Plug-Ins notwenig sind, um ihn zum Laufen zu bringen.
Das ist mir jetzt klar. Um mehr ging es mir bei der Sache gar nicht.
Ein wenig unfair geht es hier aber schon zu. Sony bringt nicht wild neue Codecs, das hat alles einen Grund. Es geht dort entweder um hohe Bitraten oder um eine höhere Farbtiefe die in den üblichen Codecs nicht verfügbar sind. Wenn zwar ein Codec der Konkurrenz verfügbar ist, für den man Lizenzgebühren bezahlen muss, dann kann man das auch verstehen.
@ Jan
Das ist jetzt aber eine pure Vermutung, denn XAVC ist ein H.264 Codec daran gibt es ja nun keine Zweifel. Sony hat also keinen eigenen Codec entwickelt.
Es ist ja auch klar, was sie gemacht haben und wenn man die Referenzimplementierung, wie sie von MPEG vorgegeben ist, wieder herstellt, funktioniert ja auch alles.
Es ist also kein neuer Codec, es ist eine eigenständige Interpretation der Section 7 der H.264 Spezifikation.
ich halte die Geschichte auch sehr übertrieben zumal die Cam erst aktuell auf den Markt gekommen ist. Sony hat sich im Professionellen Umfeld umgesehen und schlagen eben diesen Weg ein die Infrastruktur unter OSX komplett zu bedienen und erledigen das nicht nur via Plugins für fcpx und Avid sondern gleich mit komplett neuen Infrastruktur durch Sony CI und https://www.sonycreativesoftware.com/catalyst
Sie werden mit Sicherheit das import Plugin http://www.sonycreativesoftware.com/pdzk-lt2 schnellstens updaten.
Der Weg über den http://www.sonycreativesoftware.com/contentbrowser
ist nur ein Notbehelf für Leute die es nicht erwarten können. Wer sich mit den Updatehistorien der einzelnen NLE nur ein wenig auseinandersetzt weis so oder so das es bei allen Herstellern ab und an zu Überschneidungen kommt.
WoWu hat geschrieben:@ Jan
Das ist jetzt aber eine pure Vermutung, denn XAVC ist ein H.264 Codec daran gibt es ja nun keine Zweifel. Sony hat also keinen eigenen Codec entwickelt.
Es ist ja auch klar, was sie gemacht haben und wenn man die Referenzimplementierung, wie sie von MPEG vorgegeben ist, wieder herstellt, funktioniert ja auch alles.
Es ist also kein neuer Codec, es ist eine eigenständige Interpretation der Section 7 der H.264 Spezifikation.
Dann habe ich mich falsch ausgedrückt, ja die XAVC Varianten gehören zu H.264. Ich meinte die Veränderung im H.264 Codec.
Die Veränderung verbessert den Codec nicht weil kein weiteres oder zusätzliches Tool benutzt wird.
Die Decodierung wird damit lediglich von 8x4 Bit, wie es die Referenzimplementierung vorsieht, auf 4x4 oder 16x4 Bit gesetzt werden.
Das dient in erster Linie DSP Unterstützung, wie es (vermutlich) der Sony eigene Baustein darstellt, aber NLEs, die nicht per DSP, also Hardware dekodieren, nutzt das nichts.
Das Decoding wird also nicht besser dadurch. Deswegen haben die Hersteller von NLEs den Wert einfach wieder auf den Wert in der Referenzimplementierung gesetzt ... und gut ist.
Sie haben einfach den Standard wieder hergestellt.
Aber das kann jeder selbst in der Implementierungsguideline nachlesen.
das plugin ist nicht von Apple sondern von Sony und wurde soviel ich weis 2x mit einem update versorgt..
Sony hat wie schon mal verlinkt geschrieben das es überarbeitet wird und derweilen der Weg über den Content BROWSER NEU empfohlen da auch der Vorgäger damit nicht funktioniert...
Strange aber es ist so... Ist es nun ein Fehler von Apple sich darauf zu verlassen das ein Hersteller seine Aufgaben macht?
Denk ein wenig nach wie viele Troubles generell über die Jahre mit MXF Content generiert wurde oder mit dem leidigen AVCHD Format in den Anfängen egal ob unter Windows oder OSX.. wird gefixt Wayne kümmerts
Warum sollte Apple Fragen, wenn jemand von der Referenzimplementierung abweicht ?
Dafür sind Standards da. Und Apple unterstützt den Standard, um (genau wie der Standard selbst) sicher zu stellen, dass alle Hersteller, die sich an den Standard halten, auch funktionieren.
Genau das ist der Sinn eines Standards.
Warum sollte Apple da was machen, wenn andre sich nicht an den Standard halten ?
Aber da kann jeder drüber denken, was er will.
Aber wenn SONY da eine Extrawurst gebraten haben will, sollen sie soviel Plug-Ins bauen, wie sie wollen ... aber das scheint ja auch nicht so richtig zu funktionieren.
Frank B. hat geschrieben:@Wowu
Das rechtfertigt aber wieder diejenigen, die fragen, warum das Apple nicht kann.
Weil sie es in die Hand von Sony gelegt haben egal ob nun Lizenrechtliche Gründe dahinter stehen oder der zusätzliche Umfang durch die MXF Metadaten anbindung.
Nochmals, die cam ist gerade erst heraus gekommen und es wird ein Update geben punkt.. Nächsten Sommer soll ein 4k Patch kommen inkl. Proxy erstellung.. Same Procedure as every Year Miss Sophie
Das hier ist nicht die erste Kamera die mit X-AVC/S erscheint. Da gabs vorher schon seit geraumer Zeit Geräte. Etwa die Z100. So gesehen hatte jeder Hersteller einer NLE eigentlich genug Zeit seine Decoder anzupassen.
Warum man es anpassen MUSS? Weil sonst alle Benutzer dieser Geräte nicht unterstützt werden und wechseln müssen. Einfach deshalb.
@motiongroup
Wenn Sony schlau ist, setzen sie im Update den Wert auf den Standardwert und dann haben sie ihre Ruhe und alles funktioniert wieder bestens.
WoWu hat geschrieben:
Warum sollte Apple da was machen, wenn andre sich nicht an den Standard halten ?
Wenn ich das richtig verstanden habe, hat Sony den Standard ja nicht grundlegend geändert, sondern in dessen Grenzen Spielräume genutzt. Weiterhin hab ich es so verstanden, dass es anderen NLE-Herstellern gelingt mit einem kleinen Trick zeitnah, diese Abwandlung entweder zurück zu setzen, damit die Dateien genutzt werden können oder diese ganz einzubinden. Hab ich das falsch verstanden?
Falsch.
Sie haben sich nicht an die Vorgabe einer Referenzimplementierung gehalten.
Dazu sind Referenzimplementierungen da.
Nur der Umstand, dass die Spezifikationen keinen andern Wert ausschliessen, sind die Benutzung der (andern) Werte noch nicht zugelassen.
Dazu hätte es erwähnt werden müssen.
Nicht umsonst hat SONY ja einen Intent an alle Hersteller geschickt. In einem solchen Intent steht normalerweise drin, was man vor hat.
Da können nun Hersteller "mitmachen" oder auch nicht.
Wenn es nichts bringt, machen Hersteller eben nicht mit, oder gehen, wie in diesem Fall den Weg des geringsten Widerstandes ... und hebeln es einfach aus.
Nachteil ist der, dass Files, die aus dem Rechner laufen, dann mit fixen Werten versehen sind und u.U. in der Kamera nicht mehr lesbar sind.
Insofern hat sich Apple da konsequent verhalten.
Daumen hoch.
Das ist für mich nicht leicht zu verstehen. Ich versteh es jetzt so, dass Sony sich nicht an den Standard gehalten hat, aber den NLE-Programmierern das mitgeteilt hat. Andere haben in irgend einer Form drauf reagiert, Apple aber nicht, weil Sony nicht im Standard lag. Sry, aber ich muss das in meinen (einfachen) Worten ausdrücken.
So ist das.
Die Referenzimplementierung ist die Garantie dafür, dass die Implementierung, also der Standard richtig verstanden worden ist.
Gibt es hier keine Übereinstimmung, kann es Inkompatibilitäten kommen, d.h. dass Player- oder Decoder, die dem Standard entsprechen, solche Files falsch oder gar nicht dekodieren kann.
Exakt das ist aber der Zweck eines Standards, die Austauschbarkeit der Daten bei gleichbleibender Qualität zwischen allen Playern, Decoder, die dem Standard entsprechen.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
