iasi hat geschrieben:
Mich ärgert es jedoch schon, wenn man eine Kamera sozusagen auf halbem Wege abschreibt. Ich kann mir auch nicht vorstellen, dass per Firmware gar nichts mehr zu machen sein soll - da fehlt es wohl vor allem am Willen.
Franks Einschätzung wird schon korrekt sein, dass mit der Hardware nicht viel mehr geht. Funktionen wie z.B. Live-Audiopegel erfordern ja Echtzeitprocessing, und die Controller-CPU könnte jetzt schon mit Peaking, Zebras und den restlichen Overlays am Limit laufen.
Das ist ja eine ganz andere Geschichte als bei Consumer- oder DSLR-Kameras, bei denen der Controller viel mehr und viel komplexere Aufgaben erledigen muss wie z.B. Live-Entrauschung des Sensorsignals und deshalb auch mehr Reserven für weitergehende Programmierung hat. (Siehe z.B. MagicLantern.)
iasi hat geschrieben:
Timecode - das fehlt der BMCC eben leider auch - da wäre dann eine Tonaufnahme, auch nur um später den Ton besser anlegen zu können, von Vorteil
Ton ist nicht so dein Fachgebiet oder?
Den Timecode einfach über die Tonspur aufzeichnen und später im NLE zur TC Spur umwandeln. Avid und Premiere können das definitiv schon seit Jahrzehnten.
Auf die andere Tonspur kannste dann immer noch ein Mixdown vom Mischer legen.
Einzig die Tatsache, das kein Genlock vorhanden ist, finde ich in Anbetracht von s3D und kleineren Spiegel-Rigs schade.
Vielleicht kann man zwei Kameras irgendwann wie die R1 über USB noch syncen.
Wenn du mit dem BMCC EB mässig unterwegs sein solltest, einfach vom Mischen noch das TC Signal in die Kamera einspeisen. Zu Not auch über analoge Funkstrecke.
Sounddevices hat erst vor ein paar Tagen einen kleinen 6 Kanal Mischer mit TC und Rekorder auf den Markt gebracht. Kosten tut der halt leider auch 2k Euro ;-)
Die Kamera schafft ja sogar die Umwandlung nach ProRes - das bekommt Red ohne zusätzliche Hardware nicht hin.
Die kleine Pocket schafft zudem die Kompression der Raw-Daten.
Irgendwie kann ich mir auch nicht vorstellen, dass BM hardwaremäßig derart ans Limit gegangen ist, dass gar nichts mehr geht.
Ich erwarte ja schließlich keine 50fps.
Sollte wirklich gar kein Spielraum mehr sein, was die Firmware betrifft, würde dies kein gutes Licht auf die Entwicklungsabteilung von BM werfen.
ML setzt bei den Canon-Kameras nur auf die Firmware auf erweitert sie - ein wenig Programmcode wird doch auch in di BMCC noch hineinpassen.
Und einige verwertbare Daten liefert ja wohl auch die BMCC-Hardware.
iasi hat geschrieben:
Timecode - das fehlt der BMCC eben leider auch - da wäre dann eine Tonaufnahme, auch nur um später den Ton besser anlegen zu können, von Vorteil
Ton ist nicht so dein Fachgebiet oder?
Den Timecode einfach über die Tonspur aufzeichnen und später im NLE zur TC Spur umwandeln. Avid und Premiere können das definitiv schon seit Jahrzehnten.
Auf die andere Tonspur kannste dann immer noch ein Mixdown vom Mischer legen.
Einzig die Tatsache, das kein Genlock vorhanden ist, finde ich in Anbetracht von s3D und kleineren Spiegel-Rigs schade.
Vielleicht kann man zwei Kameras irgendwann wie die R1 über USB noch syncen.
Wenn du mit dem BMCC EB mässig unterwegs sein solltest, einfach vom Mischen noch das TC Signal in die Kamera einspeisen. Zu Not auch über analoge Funkstrecke.
Sounddevices hat erst vor ein paar Tagen einen kleinen 6 Kanal Mischer mit TC und Rekorder auf den Markt gebracht. Kosten tut der halt leider auch 2k Euro ;-)
Die Frage ist doch, ob all das wirkich sein muss - all dieses Umgehungsmaßnahmen - sinnvoller wäre es doch, wenn die Kamera per Firmware etwas besser ausgereizt würde
iasi hat geschrieben:Die Kamera schafft ja sogar die Umwandlung nach ProRes - das bekommt Red ohne zusätzliche Hardware nicht hin.
Da kannst Du sicher davon ausgehen, dass das von einem DSP-Encoder-Spezialchip erledigt wird, der das Herzstück von Blackmagics auch anderweitig eingesetzter Recordertechnologie bildet. Für die Overlays wird die Firmware-CPU verantwortlich sein, und die wird eher schwachbrüstig sein, da für Recorder und nicht für Kameras entwickelt.
Den Timecode über den Audio-Input ist kein Umweg, sondern gehört eher zum Standard der letzten Jahrzehnte und wurde teilweise auch als Backup parallel zum TC-In eingesetzt.
ML setzt bei den Canon-Kameras nur auf die Firmware auf erweitert sie - ein wenig Programmcode wird doch auch in di BMCC noch hineinpassen.
Und einige verwertbare Daten liefert ja wohl auch die BMCC-Hardware.
Du verwechselst das mit einer Schultüte, in die man die Süssigkeiten hineinfüllt, bis sie voll ist.
Software hat auch immer Folgen in der Ausführung und die Ausführung von Programmcode innerhalb eines vorgegebenen Zeitfensters hat immer Konsequenzen in Bezug auf den Takt und damit in Bezug auf die Wärmeentwicklung.
Schau Dir mal nur das Durk Current Verhalten nach ein paar Minuten bei einer ML Canon an und das identische Verhalten bei einer BM. Dann weisst Du, wo die Profis konstruieren und wofür die Canon eigentlich gebaut wurde. Und ML hat bisher auch keinen Weg gefunden, das zu ändern.
iasi hat geschrieben:Die Kamera schafft ja sogar die Umwandlung nach ProRes - das bekommt Red ohne zusätzliche Hardware nicht hin.
Da kannst Du sicher davon ausgehen, dass das von einem DSP-Encoder-Spezialchip erledigt wird, der das Herzstück von Blackmagics auch anderweitig eingesetzter Recordertechnologie bildet. Für die Overlays wird die Firmware-CPU verantwortlich sein, und die wird eher schwachbrüstig sein, da für Recorder und nicht für Kameras entwickelt.
aha - klingt einleuchtend - aber denkst du wirklich, für die Kamera wurde keine andere Firmware-CPU gewählt?
Ansonsten würde das so klingen, als ob sie an das Hyperdeck Shuttle einen Sensor am Eingang und ein Display am Ausgang hingehängt hätten.
ML setzt bei den Canon-Kameras nur auf die Firmware auf erweitert sie - ein wenig Programmcode wird doch auch in di BMCC noch hineinpassen.
Und einige verwertbare Daten liefert ja wohl auch die BMCC-Hardware.
Du verwechselst das mit einer Schultüte, in die man die Süssigkeiten hineinfüllt, bis sie voll ist.
Software hat auch immer Folgen in der Ausführung und die Ausführung von Programmcode innerhalb eines vorgegebenen Zeitfensters hat immer Konsequenzen in Bezug auf den Takt und damit in Bezug auf die Wärmeentwicklung.
Schau Dir mal nur das Durk Current Verhalten nach ein paar Minuten bei einer ML Canon an und das identische Verhalten bei einer BM. Dann weisst Du, wo die Profis konstruieren und wofür die Canon eigentlich gebaut wurde. Und ML hat bisher auch keinen Weg gefunden, das zu ändern.
Es hängt doch aber schon auch davon ab, in welche Prozesse ich eingreife. Keiner verlangt schließlich, dass die BMCC nun 50fps liefern soll.
Auch gehe ich nicht davon aus, dass z.B. 2,5k-ProRes oder komprimiertes Raw bei der BMCC möglich ist.
Es geht z.B. um das Auslesen von SSD-Informationen.
Manche Routinen mögen ja die Hardware derart fordern, dass man an Grenzen stößt, aber pauschal zu sagen: "Da geht gar nichts mehr", klingt nicht überzeugend.
ML setzt bei den Canon-Kameras nur auf die Firmware auf erweitert sie - ein wenig Programmcode wird doch auch in di BMCC noch hineinpassen.
Und einige verwertbare Daten liefert ja wohl auch die BMCC-Hardware.
Du verwechselst das mit einer Schultüte, in die man die Süssigkeiten hineinfüllt, bis sie voll ist.
Software hat auch immer Folgen in der Ausführung und die Ausführung von Programmcode innerhalb eines vorgegebenen Zeitfensters hat immer Konsequenzen in Bezug auf den Takt und damit in Bezug auf die Wärmeentwicklung.
Schau Dir mal nur das Durk Current Verhalten nach ein paar Minuten bei einer ML Canon an und das identische Verhalten bei einer BM. Dann weisst Du, wo die Profis konstruieren und wofür die Canon eigentlich gebaut wurde. Und ML hat bisher auch keinen Weg gefunden, das zu ändern.
Es hängt doch aber schon auch davon ab, in welche Prozesse ich eingreife. Keiner verlangt schließlich, dass die BMCC nun 50fps liefern soll.
Auch gehe ich nicht davon aus, dass z.B. 2,5k-ProRes oder komprimiertes Raw bei der BMCC möglich ist.
Es geht z.B. um das Auslesen von SSD-Informationen.
Manche Routinen mögen ja die Hardware derart fordern, dass man an Grenzen stößt, aber pauschal zu sagen: "Da geht gar nichts mehr", klingt nicht überzeugend.
Schon der Preis deutet in diese Richtung und die nachträgliche Preissenkung um so mehr.
Die Kamera ist Hammer und ein Hammer ist nun mal ein Werkzeug,daß man so nehmen muß,wie es eben ist.Auch da wirst Du auf ein "Firmware"-Update bis zum St.-Nimmerleinstag warten.
Wenn die Kameras keine Geheimnisse für Nachfolgemodelle bergen würde, könnte man die Firmware zur Weiterentwicklung "open source" machen.
(Optimierungspotential scheint sie zu haben)
Grundsätzlich wäre eine Kamera mit zugänglichem Systembus, programmierbaren Bausteinen, als modular und ausbaubar bezeichenbar.
Das Gehäuse aus dem 3D Drucker, CPU und GPU ..... der integrierte Monitor vom Hersteller X, ein neuer Sensor mit Filter
Dann ist es ein OC-PC
Zuletzt geändert von Tiefflieger am Mo 30 Dez, 2013 20:19, insgesamt 1-mal geändert.
Tiefflieger hat geschrieben:Wenn die Kameras keine Geheimnisse für Nachfolgemodelle bergen würde, könnte man die Firmware zur Weiterentwicklung "open source" machen.
Das wird wegen tangierter Patente und (sehr wahrscheinlich) von Dritten zugekauftem Programmcode sicher nicht gehen.
medikus hat geschrieben:
Schon der Preis deutet in diese Richtung und die nachträgliche Preissenkung um so mehr.
Die Kamera ist Hammer und ein Hammer ist nun mal ein Werkzeug,daß man so nehmen muß,wie es eben ist.Auch da wirst Du auf ein "Firmware"-Update bis zum St.-Nimmerleinstag warten.
Das wäre dann sehr bedauerlich ...
Aber auch einem Hammer kann man einen neuen Stiel verpassen.
Das Potential der Kamera scheint mir jedoch noch nicht voll ausgeschöpft - der Stiel ist noch etwas zu kurz.
Tiefflieger hat geschrieben:Wenn die Kameras keine Geheimnisse für Nachfolgemodelle bergen würde, könnte man die Firmware zur Weiterentwicklung "open source" machen.
Das wird wegen tangierter Patente und (sehr wahrscheinlich) von Dritten zugekauftem Programmcode sicher nicht gehen.
Mich würde es nicht wundern, wenn Google die RAW Schnittstelle in Android integriert hat (API, low level Sensorzugriff).
Etwas open source codec beisteuert, könnte künftig nebst Smartphones eine Kameraschwemme mit App Erweiterungen generiert werden.
Dann ist BMC aussen vor.
Zuletzt geändert von Tiefflieger am Mo 30 Dez, 2013 20:37, insgesamt 1-mal geändert.
Tiefflieger hat geschrieben:
Mich würde es nicht wundern, wenn Google die RAW Schnittstelle in Android integriert hat (API, low level Sensorzugriff).
Etwas open source Codec / RAW beisteuert, könnte künftig nebst Smartphones eine Kameraschwemme mit App Erweiterung generiert werden.
Das Google/Android-Raw-API ist nur für Fotos, nicht für Video. Es ist völlig utopisch, dass die jemals mit Video funktionieren wird, weil Android auf einer Java Virtual Machine läuft und man auf gewöhnlichen CPUs niemals die dafür nötige Geschwindigkeit (und das Echtzeitverhalten) hinkriegen wird.
medikus hat geschrieben:
Schon der Preis deutet in diese Richtung und die nachträgliche Preissenkung um so mehr.
Die Kamera ist Hammer und ein Hammer ist nun mal ein Werkzeug,daß man so nehmen muß,wie es eben ist.Auch da wirst Du auf ein "Firmware"-Update bis zum St.-Nimmerleinstag warten.
Das wäre dann sehr bedauerlich ...
Aber auch einem Hammer kann man einen neuen Stiel verpassen.
Das Potential der Kamera scheint mir jedoch noch nicht voll ausgeschöpft - der Stiel ist noch etwas zu kurz.
Ah,Du willst einen längeren Stiel? Sicher,damit Du nicht zu nahe an der Arbeit bist? :-))
Der Stiel ist aber Hardware,allenfalls die darin hausenden Holzwürmer sind Software:-)
Tiefflieger hat geschrieben:
Mich würde es nicht wundern, wenn Google die RAW Schnittstelle in Android integriert hat (API, low level Sensorzugriff).
Etwas open source Codec / RAW beisteuert, könnte künftig nebst Smartphones eine Kameraschwemme mit App Erweiterung generiert werden.
Das Google/Android-Raw-API ist nur für Fotos, nicht für Video. Es ist völlig utopisch, dass die jemals mit Video funktionieren wird, weil Android auf einer Java Virtual Machine läuft und man auf gewöhnlichen CPUs niemals die dafür nötige Geschwindigkeit (und das Echtzeitverhalten) hinkriegen wird.
(Java kann auch mit JIT optimiert werden und zwischen C++ ist ggf. nur 10% Performanceunterschied)
Das ist nur der Anfang, es gibt auch Bestrebungen Android schneller zu machen.
Ich weiss es nicht, aber wenn schon dann müssten auch GPU oder ggf. "ASICS mit Treibern" unterstützt werden.
Zuletzt geändert von Tiefflieger am Mo 30 Dez, 2013 21:06, insgesamt 1-mal geändert.
Tiefflieger hat geschrieben:
(Java kann auch mit JIT optimiert werden und zwischen C++ ist ggf. nur 10% Performanceunterschied)
Es geht um Funktionen, die nur mit optimierten Hardwarecontrollern/DSPs machbar sind und nicht von CPUs/in Software erledigt werden. Du glaubst doch nicht ernsthaft, dass Videokameras das Auslesen und Encoden der Sensorsignale (egal ob in h264 oder Raw) per Firmware erledigen?
Mich würde es nicht wundern, wenn Google die RAW Schnittstelle in Android integriert hat (API, low level Sensorzugriff).
Etwas open source codec beisteuert, könnte künftig nebst Smartphones eine Kameraschwemme mit App Erweiterungen generiert werden.
Dann ist BMC aussen vor.
VP9 ist kein Echtzeit codec und was willst Du mit RAW im Netz ?
Was sollte also Google da anbieten ?
WoWu hat geschrieben:
VP9 ist kein Echtzeit codec und was willst Du mit RAW im Netz ?
Was sollte also Google da anbieten ?
Tiefflieger hat scheinbar diese weitverbreitete Nachrichtenmeldung so (gründlich) missverstanden, dass man künftig bei Kameras mit Android-Firmware rohe Videodateien auslesen/aufzeichnen kann oder könnte.
WoWu hat geschrieben:
VP9 ist kein Echtzeit codec und was willst Du mit RAW im Netz ?
Was sollte also Google da anbieten ?
Tiefflieger hat scheinbar diese weitverbreitete Nachrichtenmeldung so (gründlich) missverstanden, dass man künftig bei Kameras mit Android-Firmware rohe Videodateien auslesen/aufzeichnen kann oder könnte.
Ja diese Meldung habe ich gemeint, die API bezieht sich auf Foto.
Was ich nicht verstehe, technisch sollte es kein Problem sein auch 60 RAW Sensorpattern pro Sekunde auszulesen.
(z.B. das iPhone macht 10 fertige Fotos pro Sekunde im 8 MP Burst Mode)
Es kommt immer darauf an, wann der kern schmilzt. Solange kannst Du auch Bilder auslesen.
Nur was hat das noch mit Video zu tun, in dem über eine zeitlich möglichst lange Strecke mit gleichbleibender Qualität Bilder erzeugt werden ?
Was für Foto (und vielleicht noch für Brust) gilt, gilt nicht für Video.
Tiefflieger hat geschrieben:
Was ich nicht verstehe, technisch sollte es kein Problem sein auch 60 RAW Sensorpattern pro Sekunde auszulesen.
Selbst wenn der Sensor und das Kühlungssystem das abkönnen - das schafft keine Embedded-CPU und Software, die unter Java-/Android läuft in Echtzeit. Bei 1920x1080/24p und 12 Bits pro Farbkanal fallen da 224 Megabyte Rohdaten pro Sekunde an. Wie gesagt, das geht nur in Hardware, mit Spezialchips. (Ich wiederhole mich.)
WoWu hat geschrieben:Es kommt immer darauf an, wann der kern schmilzt. Solange kannst Du auch Bilder auslesen.
Nur was hat das noch mit Video zu tun, in dem über eine zeitlich möglichst lange Strecke mit gleichbleibender Qualität Bilder erzeugt werden ?
Was für Foto (und vielleicht noch für Brust) gilt, gilt nicht für Video.
Bezüglich Sensor, die Sony RX10 macht 60 fps mit voller 20 MP Sensorauslesung und downscaling zu FullHD.
Ich hatte es oben schon mal erwähnt ... schau Dir mal an, was über die zeitliche Strecke mit dem Dark current noise passiert.
Solange Kameras nicht auf die kontinuierliche Verarbeitung von Bildern ausgerichtet sind -und da geb' ich cantsin absolut recht, das bezieht sich nicht nur auf Hardware- solange kommt für Video nur Murks hinten raus.
Lauf doch nicht gleich jeder Schlagzeile hinterher. Und je mehr es zu tun gibt, umso schwieriger wird es. Du darfst nicht nur einen kleinen Ausschnitt sehen (hurra, es geht), sondern musst ein ganzes System betrachten.
Bezüglich Sensor, die Sony RX10 macht 60 fps mit voller 20 MP Sensorauslesung und downscaling zu FullHD.
Und auch hier muss man mal anschaun, wie sie es eigentlich machen.
Tiefflieger hat geschrieben:Bezüglich Sensor, die Sony RX10 macht 60 fps mit voller 20 MP Sensorauslesung und downscaling zu FullHD.
Ja, aber ganz bestimmt nicht in der Kamera-Firmware (und schon gar nicht in Java), sondern wahrscheinlich schon direkt in der Sensorelekronik. Sorry, ich will Dir ja nicht zu nahe treten, aber ist es möglich, dass Computertechnik nicht so Dein Fachgebiet ist? Wir haben jetzt schon viermal versucht, Dir das zu erklären.
Tiefflieger hat geschrieben:Bezüglich Sensor, die Sony RX10 macht 60 fps mit voller 20 MP Sensorauslesung und downscaling zu FullHD.
Ja, aber ganz bestimmt nicht in der Kamera-Firmware (und schon gar nicht in Java), sondern wahrscheinlich schon direkt in der Sensorelekronik. Sorry, ich will Dir ja nicht zu nahe treten, aber ist es möglich, dass Computertechnik nicht so Dein Fachgebiet ist? Wir haben jetzt schon viermal versucht, Dir das zu erklären.
Aktuell habe ich mit IT Infrastrukturen und Anwendungsentwicklung zu tun.
Früher als Elektroniklaborant mit Mikroelektronik (Hybridschaltungen), Messprogrammentwicklung, Klima, EMV-Tests, Burn-in in aktiver Umgebung und Ausfallanalyse (öffnen der Hybridschaltung in Metallkapselung mit Schutzgas) mit Messonden und optisch mit Binokular.
Später als Entwicklungsingenieur nebst Assembler Echtzeitprogrammierung (HW nahe) auch ADA Echtzeitanwendungen entwickelt. (Built-in Test, Geräteinterner Quick-, Funktions- und Diagnostiktest bis auf Line Replaceable Unit (LRU). Mit Fehlercodes und Checklist)
Generell Systeme (Layer)
Es gibt Firmware die HW Funktionen ausführt (beim PC das BIOS).
Ein Betriebsystem, dass die (Kamera) Komponenten und Userinteraktionen verwaltet.
Die Komponenten werden direkt (lowlevel) oder normalerweise via Treiber angesprochen und abgefragt.
(Anwendungen) Funktionen/Programme ggf. mit GUI, die Funktionen des Betriebsystems- oder ggf. den Gerätetreiber/Firmware direkt ansprechen darf.
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.
