Lizenzieren wird wohl weniger das Problem sein, sondern BRaw überhaupt in Hardware einzubauen. Bisher geht das nur mit FPGAs, also vollprogrammierbaren Chips, die wegen ihrer Größe und ihres Stromverbrauchs für Mainstreamkameras eher ungeeignet sind. Die Chance, dass BRaw jemals in ASICs gegossen (bzw. fest in Chiphardware verdrahtet) wird, dürfte gering sein. Zumal das Format ja auch laufend weiterentwickelt wird, wofür man eigentlich FPGAs braucht.
BMD tut doch mit FPGA das, wofür FPGA auch gedacht ist... Die haben ein Baustein (OS ua. BRAW) entwickelt und darin implementiert. In FPGA lässt sich vieles Implementieren, es gibt fertig gebaute käufliche/kostenlose Bausteine, aber auch direkt von FPGA Chip Hersteller (Software) Werkzeuge, um selbst ein Baustein programmieren zu können. Also ähnlich wie z.B. Arduino nur eben viel besser/mächtiger... siehe: https://de.wikipedia.org/wiki/Xilinx
Das blöde daran: es lässt sich scheinbar nichts Hacken (scheint sehr sicher bzw. gut verschlüsselt zu sein)... ;)
"Deine Zeit ist begrenzt. Verschwende sie nicht damit, das Leben eines Anderen zu leben"
(Steve Jobs)
-paleface- hat geschrieben: ↑Mi 07 Apr, 2021 21:47
Aber ist das aus seitens BMD nicht eine "dumme" Lösung?
Kurz gesagt ist das auch der Grund, warum es Codecs wie ProRes und DNxHR nicht in Mainstream-Kameras gibt, sondern nur in externen Recordern oder eben FPGA-basierten Cine-Kameras.
Beide Technologien, FPGA und ASIC, haben ihre jeweiligen Vor- und Nachteile: Längere Akkulaufzeiten und kompaktere Bauformen sowie mehr Kamerafunktionen bei ASICs, Postproduction-Codecs und z.T. radikale Firmware-Funktionsupdates bei FPGA.
Außerdem kommen bei FPGA die dramatisch geringeren Entwicklungskosten hinzu. Ohne FPGA könnten Kleinhersteller wie Blackmagic, ZCam und RED wahrscheinlich gar keine eigenen Kameras entwickeln/bauen (und sowieso keine eigenen Codecs entwickeln).
cantsin hat geschrieben: ↑Mi 07 Apr, 2021 19:21
Bisher geht das nur mit FPGAs, ...
lieber cantsin, ich fürchte, du solltest dich von diesem dogma
langsam wieder verabschieden.
es zwar eine ziemlich komplizierte frage, welche dinge man bessere in software realisert und wo FPGAs od ASICs tatsächlich sinn machen, aber in sehr vielen fällen sind in wahrheit alle drei varianten möglich, und es letztlich mehr eine frage der wirtschaftlichkeit od. des entwicklungsaufwands, welchen weg man man einschägt.
grundsätzlich könnte man jedenfalls sicher auch ohne probleme das BRAW verpacken, wie im falle vieler andere formate, einfach auf ausreichend leistungsstarken prozessoren bzw. deren GPGPU und vektor-processing extensions abwickeln.
da es sich bei BRAW aber bekanntlich um eine closed source lösung handelt, von der niemand so genau weiß, was darin wirklich vor sich geht, und auch jede offen einsehbare spezifikation des formats fehlt, kann man über die kompelxität der notwendigen verabeitungsschritte ohnehin nur spekulieren od. sich halt an ähnlich gelagerte lösungen orientieren, über die mehr bekannt ist.
derartige RAW daten zu verarbeiten bzw. weiterzureichen, ist aber im grunde genommen eine verhältnismäßig einfache aufgabe -- zumidest, wenn man es mit dem rechenaufwand vergeleicht, der heute bei den moderneren videocodecs ansonsten üblich ist.
ganz trivial ist es aber natürlich trotzdem nicht, video-datenströme in der größenordnung unserer kameras bzw. sensoren zu verarbeiten. anderseits ist das längst nichts ungewöhnliches mehr -- d.h. in jedem besseren auto od. vielen industrieanwendundungen werden mittlerweile die signale von x-kameras in echtzeit ausgewertet und mit bildanalyseverfahren prozessiert, die weit über das hiunausgehen, was hier gefordert ist.
natürlich gibt's dabei fast immer einzelne aufgaben, die man tatsächlich mit hilfe von hardwareunterstützung besonders effizient abwickeln kann. ob mit hilfe von FPGAs od. mit applikationsspezifischen ICs macht dabei oft gar keinen so großen unterschied, schließlich gibt's innerhalb dieser beiden varianten eine ganz gewaltig breite spanne an umsetzungsmöglichkeiten bzw. ein schier unüberschaubares spektrum spektrum an verarbeitungsgeschwindigkeiten, chipherstellungsgenerationen, und entsprechender kosten und ersparnisse. man kann da vermulich kaum eine so klare grenzlinie ziehen, wie du es darstellst.
wie man das einschätzt, hat natürlich auch sehr viel damit zu tun, welche praktischen erfahrungen und orientierungshorizonte man sich im laufe der jahre angeeignet hat. so ist sind z.b. für mich FPGAs weiterhin das äußerste, wo ich noch einigermaßen vernünftig mitreden kann bzw. mich grobe einschätzungen vorzunehmen getrau, während ein paar freunde von mir, die tatsächlich in der halbleiterentwicklung arbeiten, darüber natürlich nur lachen können, und mir dann so nebenbei wiedereinmal erklären, wie unglaublich einfach es heute im industriellen rahmen geworden ist, irgendwelche ASICs relativ kostengünstig zu produzieren. wie gesagt, ich kann dir das auch nur in dieser weise hier weiterergeben, ohne wirklich zu einem klaren urteil in diesen dingen fähig zu seien.
momentan gibt's übrigens ohnehin eine tolle einladung, sich in diesen dingen ein wenig weiterzubilden bzw. open source video-lösungen ggf. auch in dieser weise zu beflügeln:
mir persönlich ist das allerdings doch doch um einige schuhnummern zu anspruchsvoll, weshalb ich mich lieber in niederungen herumtreibe, die ohnehin für alle viel leichter zugänglich sind und mehr spaß und abenteuer versprechen:
das dürfte gegenwärtig so ziemlich das kleinste bzw. billigste (~€10,-) FPGA-spielzeug sein, mit dem man tatsächlich zumindest FullHD video-dimensionen bzw. HDMI I/O direkt auf derart programmierbarer hardware handhaben kann. die leitungsfähigeren lösungen werden dann gleich einmal um ein vielfaches teurer.
wobei mich in dem zusammenhang ja mehr die synthetisierung von RISC-V kernen und deren verschmelzung mit anwendungsspezifischer peripherie interessiert, was ja mittlerweile durch projekte wie LiteX, VexRisc, Serv, Pulp, NeoRV32 u.ä. auch nichts ungewöhnliches mehr ist.
wie gesagt -- man muss ja nicht gleich mit 8K-16bit-120fps video processing losstarten, sondern kann durchaus auch an hand viel kleinerer typischer lehr- und übungsbeispiele (stichwort: "blinky") ein gefühl für diese dinge und die damit verbundenen möglichkeiten und herausforderungen bekommen. dann sieht man zumindest manche dinge ein bisserl klarer, und kann sich von den irreführenden infos und zumutungen der videohardwarehersteller, aber vor allem auch manchen irrglauben hier im netz, ein wenig frei machen.
cantsin hat geschrieben: ↑Mi 07 Apr, 2021 19:21
Bisher geht das nur mit FPGAs, ...
lieber cantsin, ich fürchte, du solltest dich von diesem dogma
langsam wieder verabschieden.
Da hast Du mich missverstanden, oder ich habe mich missverständlich ausgedrückt. Ich meinte das nicht im Sinne von "das geht prinzipiell nicht mit ASICs", sondern im Sinne von "bisher gibt es keine ASICs mit [möglicher] BRaw-Unterstützung".
cantsin hat geschrieben: ↑Mi 07 Apr, 2021 22:21
Da hast Du mich missverstanden, oder ich habe mich missverständlich ausgedrückt. Ich meinte das nicht im Sinne von "das geht prinzipiell nicht mit ASICs", sondern im Sinne von "bisher gibt es keine ASICs mit [möglicher] BRaw-Unterstützung".
mir geht's darum, dass diese trennline ziwschen FPGAs, ASICs und sogar gegenüber den "reinen" softwarelösungen nicht vernünftig aufrechtzuerhalten ist.
du kannst zb. manche FPGA-designs fast 1:1 bzw. unter einsatz automatisierten mitteln auch als ASIC produzieren lassen bzw. direkt in solche einbetten -- z.b. efinix hebt immer wieder genau diesen vorzug an ihren produkten hervor --, aber es gibt eben auch ein paar nicht ganz billige FPGA lösungen, die verdammt schnell und mit extrem kleinen strukturbreiten und extrem geringen verlustleistungen arbeiten, so dass sie es problemlos mit verbreiteten bildverabeitungs-ASICs aufnehmen können. das ganze wird also in der praxis wohl mehr durch fragen der wirtschaftlichkeit begrenzt.
dass es absolut idiotisch ist, nicht auf offene standards und die wiederverwendbarkeit und kollektive verbesserung entsprechender soft- und hardware zu setzten, dürfte ohnehin jeder von uns wenigstens heimlich ahnen -- aber so ist das halt mit unverbesserlich reaktionären firmen wie BMD.
roki100 hat geschrieben: ↑Mi 07 Apr, 2021 21:52
Das blöde daran: es lässt sich scheinbar nichts Hacken (scheint sehr sicher bzw. gut verschlüsselt zu sein)... ;)
naja -- es ist eine ziemlich anspruchsvolles betätigungsfeld, aber in wahrheit sind praktisch alle freien werkzeuge zur FPGA programmierung über derartiges reverse engineering -- aehm: "documenting" !:) -- von richtig guten leuten erschlossen worden.
bspw. die nutzung der oben angesprochenen günstigen gowin-FPGAs wurde auf genau diese weise erst vor ganz kurzer zeit im yosis zugänglich gemacht:
in letzter zeit sind allerdings auch ein paar FPGA hersteller dazu übergangen, wenigstens einen teil ihrer werkzeuge auch in dieser weise zugänglich zu machen, weil man einfach langsam erkennt, welche positiven begleiterscheinungen das mit sich bringt.
lieber mash_gh4, mit Xilinx sieht das anders aus, da ist nämlich die Sicherheit scheinbar einer der wichtigsten gründe dass manche Hersteller darauf setzen. Wenn ich das damals (bei meinen verzweifelten versuche und reine Zeitverschwendung) richtig verstanden habe, ist jedes Baustein (wie z.B. implementierte ProRes, CDNG...und nun auch BRAW ) selbst verschlüsselt. Das (!) scheint auch der entscheidende Grund zu sein, dass Kamerahersteller wie BMD & Co. ebenso auf Xilinx setzen.... Die wollen es closeder als nur Closed Source... ;) Der Grund scheint also nicht nur, weil Xilinx unbeschränkte Möglichkeit anbietet (im vergleich zu andere FPGA Anbieter)...sondern auch die Sicherheit/Verschlüsselung...
roki100 hat geschrieben: ↑Mi 07 Apr, 2021 23:48
lieber mash_gh4, mit Xilinx sieht das anders aus, da ist nämlich die Sicherheit scheinbar einer der wichtigsten gründe dass manche Hersteller darauf setzen.
ich denke, dass es eher umgekehrt ist. xilinux und altera (= intel) haben einfach eine derartige marktmacht, dass sie sich praktisch alles erlauben können. bei den wirklich großen und teueren FPGAs stehen sie fast konkurrenzlos da. alle anderen müssen sich halt mit irgendwelchen nieschen-vorzügen durchschlagen. so hat eben Lattice durchaus davon profitiert, dass es dafür die ersten freien werkzeuge entwickelt wurden -- zu einem zeitpunkt, als man noch fastr darauf angewisen war einen windows PC zu benutzen, weil praktisch überhaupt nichts anderes in diesem bereich ztur entwicklung genutzt werden konnte. das ist ja mittlerweile zum glück geschichte. auch für xilinix und altera bausteine gibt's wenigstens ansatzweise alternative tools.
roki100 hat geschrieben: ↑Mi 07 Apr, 2021 23:48
Wenn ich das damals (bei meinen verzweifelten versuche und reine Zeitverschwendung) richtig verstanden habe, ist jedes Baustein (wie z.B. implementierte ProRes, CDNG...und nun auch BRAW ) selbst verschlüsselt.
ja -- in puncto zugänglichkeit dieser schaltungsbeschreibungen bzw. IP-componenten, schaut es wirklich extrem schlecht aus. jeder hersteller bietet dir zwar alles, was du dir nur wünschen kannst, fertig zur auswahl an, aber das ist leider alles andere als billig, und eben natürlich auch gut geschützt und unzugänglich.
es gibt allerdings auch ein paar sammlungen von freien lösungen, die hier von grund auf etwas ähnliches zu schaffen versuchen, wie wir es von freier software bzw. entsprechenen betriebsystemen her kennen.
natürlich kann man daneben auch versuchen bestehende lösunegen zu knacken und zu modifizieren, aber das ist sowohl in rechtlicher hinsicht wie auch von der hacker-ethik und den damit verbundenen visionen und hoffungen mehr oder weniger irrelevant bzw. keine besonders aussichtsreiche lösung.
roki100 hat geschrieben: ↑Mi 07 Apr, 2021 23:48
Das (!) scheint auch der entscheidende Grund zu sein, dass Kamerahersteller wie BMD & Co. ebenso auf Xilinx setzen.... Die wollen es closeder als nur Closed Source... ;)
nein -- ich hab glaub das hat mehr damit zu tun, dass man für diese weit verbreiteten FPGAs natürlich unendlich viel IP-komponenten in fertiger form ohne großen aufwand zukaufen kann.
gerade BMD ist doch ein musterbeispiel für eine firma, die quasi nur mit derart fertig erhältlichen komponenten und minimalen entwicklungsaufwand irgendwelche halb-funktionierenden plastikbomber zusammenschustert, ohne auch nur die geringsten mühen an langfristiges RD-investment od. marktübergreifende standardisierungsbemühungen zu verschwenden.
was immer man braucht, man kann es ja irgendwo zukaufen -- zur not halt,
in dem man einfach andere firmen übernimmt.
roki100 hat geschrieben: ↑Mi 07 Apr, 2021 23:48
Der Grund scheint also nicht nur, weil Xilinx unbeschränkte Möglichkeit anbietet (im vergleich zu andere FPGA Anbieter)...sondern auch die Sicherheit/Verschlüsselung...
derartige features findest bei allen FPGA herstellern.
für die freien ansätze spielen sie allerdings keine große rolle, sondern vielmehr nur die zugeänglichkeit von freien entwicklungswewerkzeugen für die jeweilige bausteinfamilie.
das ist ungefähr so, wie es einfach nichts ändert, wenn irgendwelche 0815-hacker die adobe-lizenzverwaltung außer kraft setzte, damit, die große mehrheit der benutzer in wahrheit praktiziert, alle gratis mit deren software arbeiten können. längerfristig bringt das aber leider gar nichts, außer noch mehr abhängigkeit und gewöhnung an diese softwaregiganten.
irgendwelche freien lösungen, die sehr oft deutlich weniger können, aber eben ganz langsam und aufeinander aufbauend tatsächlich alternative frei lösungen zu schaffen versuchen, sind hier eine deutlich konsequentere und aussichtsreichere lösung. in vielen bereichen haben sie mittlerweile ohnehin dazu geführt, dass man dort mittlerweile nicht mehr auf die großen softwaremonopolisten angewiesen ist.
das erklärt leider auch, warum ich das abhängig werden von gratis demo-software und GPL-verletzungen durch kommerzfreundliche plugins auch nicht für besonders wünschenswert halte.
Zuletzt geändert von mash_gh4 am Do 08 Apr, 2021 01:04, insgesamt 1-mal geändert.
mash_gh4 hat geschrieben: ↑Do 08 Apr, 2021 00:45
nein -- ich hab galub das hat mehr damit zu tun, dass man für diese weit verbreiteten FPGAs natürlich unendlich viel IP-komponenten in fertiger form ohne großen aufwand zukaufen kann.
Ja auch deswegen, aber dass es dafür alles mögliche gibt, hängt eben mit der Sicherheit/Verschlüsselung zusammen - dem Hersteller/Entwickler wird quasi garantiert, dass dritte nicht unter der Haube schauen können und die Idee die dahinter steckt, samt Codes/Co. kopieren.... Das ist der Grund dass es für Xilinx FPGA fast alles gibt.
Du kennst das vll. so z.B.: JTAG Pins ermitteln, JTAG anschließen und schon gehts los...Du kannst bestimmte Bereiche dann auslesen, modifizieren und zurück flashen...
Bei Xlinix ist das ähnlich, mit dem unterschied, das via JTAG keine Daten lesbar sind, da sich eine Verschlüsselung dazwischen befindet und das für jeden Baustein. Hat man das eine oder das andere als Binärcode herausgeschnitten (ähnlich wie man es unter linux macht z.B. mit binwalk und dd Werkzeuge) und versucht man diese nun zu entschlüsseln, landet man quasi in einem Labyrinth voller unnötige Daten..... ;)
"Deine Zeit ist begrenzt. Verschwende sie nicht damit, das Leben eines Anderen zu leben"
(Steve Jobs)
roki100 hat geschrieben: ↑Do 08 Apr, 2021 01:02
Bei Xlinix ist das ähnlich, mit dem unterschied, das via JTAG keine Daten lesbar sind, ...
wie gesagt. das findest bei gowin natürlich genauso...
security bit
A special design for the configuration data security of Gowin
FPGA product. After you write the bitstream with security bit to
the device, no one will be able to read back the data. Gowin
software sets a security bit for the bitstream data of all FPGA
products by default.
im grunde verhält es sich damit aber gar nicht so wesentlich anders als im software-umfeld.
auch dort ist es verdammt und mühselig, mit IDA, ghidra, cutter/radare2 od.ä. auch nur die elementarsten dinge aus software heraus zu bekommen, die das nicht will. also verwendet man seine freizeit und intelligenz besser, um freie lösungen weiterzuentwicklen od. sich auch nur in deren praktischer benutzung zu üben bzw. sich von dem ärgerlichen anderen zeug möglichst fern zu halten.
Zuletzt geändert von mash_gh4 am Do 08 Apr, 2021 03:00, insgesamt 3-mal geändert.
ich warte darauf sehr gespannt.... Du hast schon etwas tolles verlinkt (das mit HDMI usw.), ich hoffe bald auf größere Sensor für RB&Co. Da tut sich aber schon etwas...mal abwarten. :)
"Deine Zeit ist begrenzt. Verschwende sie nicht damit, das Leben eines Anderen zu leben"
(Steve Jobs)
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.
