Tips: Tips: Blackmagic Design Shuttle 2 oder die Tücken der externen Rekorder von Deti Fliegl - 16 oct 2012 16:28:00
>Günstige Videokameras und DSLRs können ohne Zweifel eindrucksvolle Bewegtbilder liefern, wobei immer ein Teil der guten Qualität durch die eingebauten Codecs auf der Strecke bleibt. Doch auch der Einsatz eines externen Rekorders ist nicht ohne Tücken... zum ganzen Artikel
Das dürfe das alte Formatproblem sein, in dem sich 0 IRE bei DVB auf 16 bezieht statt auf 1 und ATSC, mit 7,5 IRE, auf 32.
Entsprechend 120 IRE auf 254 und bei ATSC aber auf 133 IRE.
Sieht also so aus, als ob der Recorder im ATSC Wertefeld arbeitet und die Sache in einer DVB Umgebung nicht korrekt gewandelt wurde und das 7,5 IRE Offset nicht beseitigt wurde. Daraus ergibt sich dann auch die Stauchung.
Das ist aber kein Mangel des Recorders, sondern ein Anwendungsfehler.
Diese Probleme beim Shuttle sind mir auch bekannt.
Hab daher einen Atomos Samurai. Der funzt perfekt in Premiere und Vegas mit der FS700. AVCHD und ProRes sehen auf dem Waveform gleich aus.
Mit Final Cut Pro und Final Cut X gibts keine Probleme, aber an der Avid schluckt es nicht mal die DNxHD-MXF-Dateien, da gehen nur die mov zum importieren, schon komisch. Habe dies auch an Blackmagic reportet, was diese bestätigt hatten und Abhilfe versprachen.
Das hab ich jetzt so verstanden:
FCP schluckt keine MFX Dateien, aber .mov
AVID schluckt auch keine MFX Dateien aber auch .mov, mit dem Unterschied, dass AVID normalerweise MXF schluckt, FCP aber sowieso nicht.
Die MXF Dateien werden bei Avid nicht "Importiert" sondern direkt in den Mediafolder (AvidMediaFiles/MXF) kopiert und dann mit dem Media Tool in Avid in die Bins "reingezogen". Funktioniert einwandfrei.
WoWu hat geschrieben:Das dürfe das alte Formatproblem sein, in dem sich 0 IRE bei DVB auf 16 bezieht statt auf 1 und ATSC, mit 7,5 IRE, auf 32.
Entsprechend 120 IRE auf 254 und bei ATSC aber auf 133 IRE.
Sieht also so aus, als ob der Recorder im ATSC Wertefeld arbeitet und die Sache in einer DVB Umgebung nicht korrekt gewandelt wurde und das 7,5 IRE Offset nicht beseitigt wurde. Daraus ergibt sich dann auch die Stauchung.
Das ist aber kein Mangel des Recorders, sondern ein Anwendungsfehler.
Meinst du hier das Problem, das auch die 5DII zu Beginn hatte?
Übrigens:
Schreib doch bitte in Deutsch. Oder kommt es dir mehr auf Wirkung als auf Inhalt an?
WoWu hat geschrieben:Das ist aber kein Mangel des Recorders, sondern ein Anwendungsfehler.
Hier stellt sich aber die Frage, warum dieser Fehler unter Windows vermutlich alle Anwendungen betrifft, die über das Quicktime-Framework auf unkomprimierte MOV-Dateien von Blackmagic Design zugreifen? Dass der Rekorder nicht zwingend daran "schuld" sein muss, ist eigentlich klar. Komisch nur, dass DNxHD-Dateien im MOV-Container vom gleichen Rekorder absolut perfekt importiert/gelinkt werden. In jedem Fall ist Vorsicht geboten...
Schreib doch bitte in Deutsch. Oder kommt es dir mehr auf Wirkung als auf Inhalt an?
???
Das dürfe das alte Formatproblem sein, in dem sich 0 IRE bei DVB auf 16 bezieht statt auf 1 und ATSC, mit 7,5 IRE, auf 32.
Entsprechend 120 IRE auf 254 und bei ATSC aber auf 133 IRE.
Sieht also so aus, als ob der Recorder im ATSC Wertefeld arbeitet und die Sache in einer DVB Umgebung nicht korrekt gewandelt wurde und das 7,5 IRE Offset nicht beseitigt wurde. Daraus ergibt sich dann auch die Stauchung.
Das ist aber kein Mangel des Recorders, sondern ein Anwendungsfehler.
Welche Sprache, meinst Du, war das ?
@Deti
Anwenderfehler insofern, als man die Messung natürlich exakt auf das Signal einstellen muss, das der Recorder aufzeichnet.
Steht die Messung auf 709 (oder sonstwo) und der Recorder beschreibt den gesamten Wertebereich, dann kann es nicht stimmen.
Die Messung ist ja immer nur ein Bezug zu einer Skalierung. Und hier stimmt die gewählte Skalierung einfach nicht.
Mit der Wahl des richtigen Formats stimmt auch die Messung wieder.
WoWu hat geschrieben:Mit der Wahl des richtigen Formats stimmt auch die Messung wieder.
Als Anwender kann man das Format nicht wählen und man muss der Interpretation der verwendeten Software vertrauen. Ihr könnt es ja selbst mal ausprobieren. Das 600kByte große ZIP-Archiv enthält eine unkomprimierte MOV-Datei und die parallel dazu intern aufgezeichnete MTS-Datei: http://tv.42u.de/download/testfiles.zip
Na ja. spätestens, wenn ich das Signal in mein NLE ziehe, schaue ich es mir im WF an ... also spätestens da streife ich das 7 IRA Offset ab.
Übrigens ist das kein singuläres Problem dieses Recorders. Selbst aus einigen Kameras kommt das Signal so raus.
Schreib doch bitte in Deutsch. Oder kommt es dir mehr auf Wirkung als auf Inhalt an?
???
Das dürfe das alte Formatproblem sein, in dem sich 0 IRE bei DVB auf 16 bezieht statt auf 1 und ATSC, mit 7,5 IRE, auf 32.
Entsprechend 120 IRE auf 254 und bei ATSC aber auf 133 IRE.
Sieht also so aus, als ob der Recorder im ATSC Wertefeld arbeitet und die Sache in einer DVB Umgebung nicht korrekt gewandelt wurde und das 7,5 IRE Offset nicht beseitigt wurde. Daraus ergibt sich dann auch die Stauchung.
Das ist aber kein Mangel des Recorders, sondern ein Anwendungsfehler.
Welche Sprache, meinst Du, war das ?
Die wilde Benutzung von Akronymen ... "Offset" ...
Generell frage ich mich jedoch, ob dir überhaupt daran liegt, dass deine Adressaten verstehen, was du schreibst.
Hermann Riegel hat 1885 den Allgemeinen Deutschen Sprachverein gegründet.
Das wär' doch was für Dich.
Ich frage mich allerdings, was jemand, der nicht weiss, was "Offset" oder "Line-Feed" oder "PAL" oder "NTSC" oder "Glidecam", oder sogar "Video" bedeutet, in so einem Forum eigentlich will.
Vielleicht wäre der obige Verein dann doch der bessere Tipp.
Und, um Deine Frage zu beantworten: Ja, es liegt mir dran. Aber die meisten wissen eben, was Offset, Video, Line oder PAL bedeuten.
Einwenig Grundwissen kann man bei Videointeressierten schon voraussetzen. Aber offensichtlich wohl nicht bei allen.
Und erklär doch mal, was an der Benutzung des Akronyms 'Offset', "WILD" sein soll. Mal ganz abgesehen davon, dass es gar kein Akronym ist.
Übrigens hättest Du auch statt Akronym -Initialwort- benutzen müssen.
WoWu hat geschrieben:@ Iasi
???
Welche Sprache, meinst Du, war das ?
Die wilde Benutzung von Akronymen ... "Offset" ...
Generell frage ich mich jedoch, ob dir überhaupt daran liegt, dass deine Adressaten verstehen, was du schreibst.
<Ironiemodus> Ja genau... Das Wort "Offset" war es, das mich bei diesem Beitrag aus der Bahn geworfen hat... Unbedingt... <Ironiemodus>
Sinarius hat geschrieben:
<Ironiemodus> Ja genau... Das Wort "Offset" war es, das mich bei diesem Beitrag aus der Bahn geworfen hat... Unbedingt... <Ironiemodus>
*Kopf schüttel...*
aha - man muss also anmerken, wie man etwas meint ...
"offset" = <sarkasmus>
WoWu hat geschrieben:
Und erklär doch mal, was an der Benutzung des Akronyms 'Offset', "WILD" sein soll. Mal ganz abgesehen davon, dass es gar kein Akronym ist.
ach da schau her - muss ich es als klarer ausdücken:
wenn ich "Akronym" schreibe, dann meine ich auch die Akronym in deinem Text - also IRE, DVB und ATSC ...
Ich hatte mal einen wissenschaftlichen Aufsatz vor mir, bei dem es dem Autor gelang, einen Satz über zwei Seiten zu drechseln. Und darin hatte er eigentlich nur eine simple Sache verpackt, die ein anderer in seiner Arbeit in zwei kurzen Sätzen schön treffen auf den Punkt gebracht hatte.
Nun rate mal, wer von den Beiden der Kompetentere war.
Manchmal kommt es nämlich auch auf die Kompetenz des Lesers an.
Wenn ich einem Kleinkind mit dem Akronym "PAL" konfrontiere, wird es ganz sicher nichts damit anfangen können.
Du meinst also, es würde mit "Phase Alternating Line" die Sache besser verstehen.
Ich glaube, Dein Problem und der Grund Deiner Beschwerde liegt ganz woanders.
Du möchtest wieder mal einwenig Zoff* machen ... mach das, aber ohne mich.
Anwenderfehler insofern, als man die Messung natürlich exakt auf das Signal einstellen muss, das der Recorder aufzeichnet.
Steht die Messung auf 709 (oder sonstwo) und der Recorder beschreibt den gesamten Wertebereich, dann kann es nicht stimmen.
Die Messung ist ja immer nur ein Bezug zu einer Skalierung. Und hier stimmt die gewählte Skalierung einfach nicht.
Mit der Wahl des richtigen Formats stimmt auch die Messung wieder.
_________________
WoWu hilf mal bitte einem Dummen, mir fehlen hier Grundlagen - ist das jetzt ein Meßfehler?? Oder aber was kann ich tun um ein passendes Signal aus dem Rekorder in die NLE zu bekommen- Edius 6 und Win 7 64 ?
Habe eine EX-1 und Hyperdeck Shuttle 1 über SDI verbunden um höherwertiges Material zu bekommen (leider nur 8 Bit) und bin jett total verwirrt.
BMS kocht auch nur mit Wasser und verteilt die Werte zwischen 0 IRE und 100 IRE, als den Lichtwerten zwischen Schwarz und Weiss auf die 255 Werte.
(Ich benutze ganz bewusst nicht %, weil dabei immer der Bezug fehlt und sowas wie -% gibt es sowieso nicht, weil es keine negativen Lichtwerte gibt.
Arbeitet man also im RGB Farbraum, stimmt alles.
Betrachtet man nun die unterschiedliche Benutzung der digitalen Werte, wird man festellen, dass BMS vermutlich die NTSC/ATSC Belegung hat und Schwarz mit 7,5 IRE festlegt.
Weil es aber im PAL/DVB Raum, ebenso wie in NTSC-J Raum dieses OffSet nicht gibt, muss man es entsprechend korrigieren.
Du musst das Signal also von RGB nach YCbCr wandeln.
(Wenn Du Broadcast 709 machst.)
Eine einfache Stauchung führt zur Krümmung der Kurve.
Bei der Wandlung werden die Helligkeitswerte den entsprechenden Digitalwerten neu zugeordnet.
Natürlich gehen dabei Auflösungsschritte verloren, aber verteilt über die gesamte Skala, weil weder unten, noch oben geklippt wird.
Das (angefügte) Bild zeigt einmal die Beziehungen der Werte zueinander.
Nun weiss ich nicht, was aus deiner Kamera kommt, aber wenn Du Dir beide Signale mal auf dem Waveform ansiehst (und die richtige Skalierung wählst), wird das eigentlich schon klar.
Wenn Du die beiden Bilder hast, poste sie doch mal (vom FB der Kamera), dann kann man am schnellsten sehen, was los ist.
Oder Du arbeitest gleich in RGB (wenn das aus Deiner Kamera kommt und Dein NLE macht die Wandlung bei der Ausspielung). Dann musst Du nur sehn, wo dein "Schwarz" liegt und das Offset ggf. nachziehen.
Auch wenn manche hier im Forum nix von Farbbalken und Messung halten ... meine Empfehlung wird es immer bleiben.
@Deti Danke für den Content, leider sagt mir mein Rechner, ich hätte nicht die Rechte, es zu öffnen. :-((
WoWu hat geschrieben:@Deti Danke für den Content, leider sagt mir mein Rechner, ich hätte nicht die Rechte, es zu öffnen. :-((
Die Dateien stammen von einem Windows-System und deshalb besitzen sie nicht die korrekten Unixrechte. Unter MacOS X müsstest du auf die beiden Dateien drinnen noch ein chmod 644 machen. Hab das Archiv aber gerade nochmal hochgeladen und die Rechte gleich dort korrigiert.
WoWu hat geschrieben:Das dürfe das alte Formatproblem sein, in dem sich 0 IRE bei DVB auf 16 bezieht statt auf 1 und ATSC, mit 7,5 IRE, auf 32.
Entsprechend 120 IRE auf 254 und bei ATSC aber auf 133 IRE.
Sieht also so aus, als ob der Recorder im ATSC Wertefeld arbeitet und die Sache in einer DVB Umgebung nicht korrekt gewandelt wurde und das 7,5 IRE Offset nicht beseitigt wurde. Daraus ergibt sich dann auch die Stauchung.
Das ist aber kein Mangel des Recorders, sondern ein Anwendungsfehler.
Meinst du hier das Problem, das auch die 5DII zu Beginn hatte?
Übrigens:
Schreib doch bitte in Deutsch. Oder kommt es dir mehr auf Wirkung als auf Inhalt an?
Betrachtet man die unkomprimierten MOV-Dateien des BMD Shuttle genauer, so findet man zum verwendeten Codec v210 ("Component Y'CbCr 10-bit 4:2:2") die genaue Beschreibung hier: https://developer.apple.com/quicktime/i ... .html#v210
Dort steht:
This compression type uses scheme B
und das heißt:
Scheme B comes from digital video industry specifications such as Rec. ITU-R BT. 601-4.
Weiter unten ist nochmal klar ausgeführt, dass der Wertebereich für Y/C in der 10-Bit Version zwischen 64 und 960 liegen muss (das entspricht in 8Bit dem bekannten Intervall von 16 bis 235).
Wenn man sich nun die Y-Werte der MOV-Datei genauer ansieht, dann liegen diese exakt im Intervall zwischen 64 und 960, folglich liegt der Fehler irgendwo zwischen Blackmagic-Codec, Quicktime-Framework unter Windows und der verwendeten Schnittsoftware. Wie schon weiter oben vermutetet, trifft den Rekorder keine Schuld. Es handelt sich nach meiner Ansicht klar um einen Programmierfehler. Keinesfalls ist dem Anwender die Schuld dafür zu geben, denn die Werte hätten von der Schnittsoftware automatisch korrekt interpretiert werden müssen. Schließlich ist im o.g. Dokument von Apple eine vollständige Spezifikation enthalten, die keinen Raum für Mutmaßungen lässt.
So lange das Problem nicht bei DNxHD auftritt ist es ja nicht so schlimm.
Mit was für Optionen habt ihr das Mov eigentlich in den Avid importiert(nicht AMA), da gibt es ja verschiedene Einstellungen.
Auch bei Dateien die man per AMA importiert lassen sich nachträglich noch ein paar Sachen einstellen. So werden z.B. ProRes 4222HQ Movs unter Win7 nicht richtig angezeigt, was sich aber beheben lässt.
Nun weiss ich nicht, was aus deiner Kamera kommt, aber wenn Du Dir beide Signale mal auf dem Waveform ansiehst (und die richtige Skalierung wählst), wird das eigentlich schon klar.
Wenn Du die beiden Bilder hast, poste sie doch mal (vom FB der Kamera), dann kann man am schnellsten sehen, was los ist.
Hier mal FB von der Kamera (Sony PMW EX-1 einmal XDCAM EX und einmal unkomprimiert Blackmagic über SDI an Kamera angeschlossen. Win 7 64 und Edius 6
Vielen Dank für Deine Mühe, alles habe ich nicht verstanden, einiges ist mir klarer geworden.
Vielen Dank
Elimar
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Das sieht doch gut aus.
Ich hatte auch das Problem nur aus der Slashcam Beschreibung entnommen und nicht aus eigener Anschauung.
Aber so, wie Deti es aufgegriffen hat, habe ich es anfänglich nicht gesehen.
Das Problem scheint also nur in ganz speziellen Konstellationen aufzutreten, die vermutlich nur in seltenen Fällen vorliegen. Wir konnten hier mit dem File von Deti auch keine Abweichung reproduzieren.
Aber Einigkeit besteht auf alle Fälle darüber, dass der Recorder es nicht ist.
Insofern ... ruhiges Arbeiten.
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.
Artikel-Fragen Forum 
