Newsmeldung von slashCAM:Der Cineform Codec in seinen verschiedenen Formen ist eher seltener anzutreffen als übliche Codecs. Unter ande...
Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
GoPro Cineform Reverse Engineering
Antwort von WoWu:
Das ist es auch, was die Welt braucht ... eine freie Version eines fast 50 Jahre alten Codecs.
Ausserdem beschreibt kein Standard, wie eine Implementierung vorzunehmen ist, sondern lediglich die Rahmenbedingungen, die als "unveränderbar" anzusehen sind.
I did huge amounts of reverse-engineering to add this to x264.
Komischerweise haben das viele Firmen hinbekommen, ohne auf solche Schwierigkeiten zu stossen denn H.264 Encoder gibt es ja nun wie "Sand am Meer".
Vielleicht liegt es aber auch nur daran, dass man Zugang zu Referenzimplementierung und Implementation Guidelines nur über den entsprechenden Lizenzvertrag kommt, -was nachvollziehbar ist bei patentrechtlich geschütztem Material-.
Aber wer Rechte "umgehen" will, darf sich nicht beklagen, wenn der Eigentümer ihm das nicht so leicht macht.
Antwort von derkiki:
Der Coded kann raw als wavelet komprimieren, du Schlauberger. Also durchaus erstrebenswert. 50 Jahre alt sind deine Denkansätze.
Antwort von merlinmage:
Lieber wavelet als DCT Grütze.
Antwort von WoWu:
Lieber wavelet als DCT Grütze.ja, und lieber geklaut als gekauft.
Alles klar.
Antwort von WoWu:
Der Coded kann raw als wavelet komprimieren, du Schlauberger. Also durchaus erstrebenswert. 50 Jahre alt sind deine Denkansätze.Ach, das konnte ich mir gar nicht vorstellen.
Antwort von merlinmage:
Lieber wavelet als DCT Grütze.ja, und lieber geklaut als gekauft.
Alles klar.
Wo hab ich was von geklaut geschrieben?
Ja klar.
Antwort von Frank Glencairn:
Die Basis, auf der unsere Linsen bis heute funktionieren ist deutlich älter als 50 Jahre ;-) hat keinen jemals interresiert.
Komischerweise meckert bei RED-Code keiner.
Antwort von WoWu:
Es geht ja auch gar nicht darum, wie alt unsere Augen sind.
Wenn es darum ginge, hätten wir gar keine künstliche Bildaufzeichnung.
Nur ist es einmal so und die Entwicklung im Codecbereich ist nunmal dramatisch vorangegangen.
Wir könnten auch noch auf Bändern aufzeichnen nur die Anforderungen haben sich geändert.
Und wer die klassischen Wavelet Artefakte, z.B. verschwundene Bildanteile mag, und auf den ewigen Weichzeichner steht und zur Ausstrahlung dann nochmal in einen andern Codec wandeln möchte, um die Zahl der Artefakte nochmal drastisch zu erhöhen, der kann das ja gern tun.
Erklär' mir doch mal die Vorteile von Wavelet ... vielleicht hab ich ja was übersehen.
Antwort von mash_gh4:
ich finde es zwar super, dass sich jemand die arbeit antut, weil es einfach wichtig ist, dass möglichst viele formate in freien werkzeugen unterstützt werden, trotzdem bin ich weiterhin nicht wirklich von der qualität dieses codecs überzeugt. in praktisch allen vernünftigen vergleichen, die mir bisher untergekommen sind, hat er nicht wirklich überzeugend abgeschnitten.
Antwort von WoWu:
Nur solange solche Erkenntnisse unter Umgehung der Lizenzgesetzgebung stattfinden, liegen Straftatbestände vor und dann finde ich das gar nicht mehr so lustig und auch befremdlich, dass die Redaktion für das Gelingen solcher Straftaten "die Daumen drückt".
Ich muss nicht daran erinnern, dass auch viele von uns, hier im Forum von Lizezabrechnungen ihrer Produktionen leben.
Was ist dagegen einzuwenden, sich die entsprechenden Lizenzen und den Zugang zur Implementierung zu erwerben ?
Antwort von mash_gh4:
ich hab eh nichts dagegen, wenn die ergebenisse derartiger "forschungsarbeit" in GPL geschütztem code münden, und ihn die zu sehr kommerziell interessierten zeitgenossen nicht für ihre zwecke missbrauchen dürfen. :)
Antwort von iasi:
Komischerweise meckert bei RED-Code keiner.
oh doch - es gibt den einen oder anderen, der auch den Red-Code für veraltet hält ... und bald geschieht dann wohl mit der alten Kreiszahl Pi dasselbe :)
Antwort von WoWu:
Jau und mit der NULL auch.
Nenn sie doch einfach mal, die Vorzüge von Wavelet.
Kann doch nicht so schwer sein.
Ich kann da auch Hilfestellung leisten .... es kostet fast nichts.
Antwort von iasi:
Erklär' mir doch mal die Vorteile von Wavelet ... vielleicht hab ich ja was übersehen.
Er sorgt für geringere Datenmengen - und wenn man"s nicht übertreibt auch ohne Beinträchtigungen des Bildes.
Man sollte eben nicht immer Kraut und Rüben miteinander vergleichen wollen.
HEVC z.B. zielt schließlich auf eine andere Anwendung ab ... da heißt es dann: So klein wie nur möglich, bei so geringen Verlusten wie nötig ... da darf dann auch der Rechenaufwand größer sein ...
Antwort von srone:
lustige diskussion, aber mittlerweile werden hier äpfel mit birnen und später dann mit auberginen verglichen ;-)
es wäre mal interessant den "codec hot spot" zu definieren, sprich bestmöglichste qualität bei kleinster datenrate oder andersherum, welcher codec kann was, bei zb 50mbit?
lg
srone
Antwort von srone:
Erklär' mir doch mal die Vorteile von Wavelet ... vielleicht hab ich ja was übersehen.
Er sorgt für geringere Datenmengen - und wenn man"s nicht übertreibt auch ohne Beinträchtigungen des Bildes.
wäre da nicht rar oder zip geeigneter für raw-footage?
lg
srone
Antwort von iasi:
lustige diskussion, aber mittlerweile werden hier äpfel mit birnen und später dann mit auberginen verglichen ;-)
es wäre mal interessant den "codec hot spot" zu definieren, sprich bestmöglichste qualität bei kleinster datenrate oder andersherum, welcher codec kann was, bei zb 50mbit?
lg
srone
da gilt es doch letztlich drei Größen zu berücksichtigen:
1. die Datenrate
2. die Bildqualität
3. der Rechenaufwand
Was nutzt der tollste Komprimierungstechnik, wenn die Hardware (Kamera und Schnittsystem) die notwendigen Bildraten nicht liefern kann.
Red erreicht mit dem ollen Wavelet immerhin hohe Bildraten bei hoher Auflösung ohne exorbitante Hardwareanforderungen, bei vernünfitiger Kompressionsrate und einer Bildqualität, die in der Praxis überzeugt.
Antwort von srone:
Red erreicht mit dem ollen Wavelet immerhin hohe Bildraten bei hoher Auflösung ohne exorbitante Hardwareanforderungen, bei vernünfitiger Kompressionsrate und einer Bildqualität, die in der Praxis überzeugt.
die dann wie, für die webseite xy komprimiert wird, stichwort imagefilm?
lg
srone
Antwort von iasi:
Red erreicht mit dem ollen Wavelet immerhin hohe Bildraten bei hoher Auflösung ohne exorbitante Hardwareanforderungen, bei vernünfitiger Kompressionsrate und einer Bildqualität, die in der Praxis überzeugt.
die dann wie, für die webseite xy komprimiert wird, stichwort imagefilm?
lg
srone
Was hat denn das Ausgabeformat am Ende mit dem Aufnahmeformat bzw. dem in der Post genutzten zu tun?
Wenn ich von meiner Sony-Action-Cam und HEVC-Material bearbeiten möchte, dann kann ich mich erst mal von den Möglichkeiten meines Raw-Material verabschieden - auch wenn alles in 4k daher kommt.
Da gilt dann: So wie"s ist, ist"s und bleibt"s.
Antwort von srone:
Was hat denn das Ausgabeformat am Ende mit dem Aufnahmeformat bzw. dem in der Post genutzten zu tun?
apfel, birne und aubergine, das war es was ich oben meinte und wowu auch schon darstellte (siehe nachbarthread unterschied/bitrate), muss ich alle (codec-)flavours in meinen workflow integrieren, um am ende das bestmögliche ergebnis zu haben oder aber genau deswegen nicht?
lg
srone
Antwort von iasi:
Was hat denn das Ausgabeformat am Ende mit dem Aufnahmeformat bzw. dem in der Post genutzten zu tun?
apfel, birne und aubergine, das war es was ich oben meinte und wowu auch schon darstellte (siehe nachbarthread unterschied/bitrate), muss ich alle (codec-)flavours in meinen workflow integrieren, um am ende das bestmögliche ergebnis zu haben oder aber genau deswegen nicht?
lg
srone
das verstehe ich jetzt nicht - den anderen Thread habe ich nicht verfolgt.
Das Ausgabeformat kann mir doch so lange egal sein, solange mein Arbeitsmaterial "besser" ist.
Daher hätte ich ja gerne eine kompakte, kleine 4k-Raw (oder zumindest 2,5k) und wenn möglich auch ein Raw-Action-Cam als Ergänzung ... :)
Antwort von srone:
was ist besser, im gesamtkontext, das einsammeln von codec-fehlern quer durch die bank oder die verwendung eines codecs? genau die frage bleibt, weil sie noch niemand hinreichend beantwortet hat.
lg
srone
Antwort von iasi:
was ist besser, im gesamtkontext? genau die frage bleibt, weil sie noch niemand hinreichend beantwortet hat.
lg
srone
Aus meiner Sicht ist das Maximum an Spielraum (bei bewältigbaren Hardwareanforderungen) die Basis - was dann am Ende ausgegeben wird, spielt keine Rolle, wenn ich ein Ausgangsmaterial habe, aus dem das Ausgabematerial auch problemlos erstellt werden kann.
Raw lässt sich doch heute handeln - also warum nicht so lange wie nur möglich im Workflow dabei bleiben.
Zumal: Wie im Artikel schon erwähnt: ProRes läuft unter Windows schei... daher gibt"s eigentlich keinen Grund für ProRes ... wenn also Cineform weniger Rechenaufwand erfordert als Raw, dann kann"s durchaus interessant sein - ProRes ist"s jedenfalls nicht ...
Antwort von Starshine Pictures:
Der beste Codec ist der den deine Kamera dir in der höchsten verfügbaren Bitrate liefert. Dann solltest du damit weiter arbeiten. Erst am Ende wählst du in deinem NLE einen Codec aus der deinen Anforderungen an Platzverbrauch am nächsten kommt. H.264 ist da wohl aktuell noch das effektivste und gebräuchlichste bevor H.265 mal salonfähig wird.
Antwort von iasi:
Der beste Codec ist der den deine Kamera dir in der höchsten verfügbaren Bitrate liefert. Dann solltest du damit weiter arbeiten. Erst am Ende wählst du in deinem NLE einen Codec aus der deinen Anforderungen an Platzverbrauch am nächsten kommt. H.264 ist da wohl aktuell noch das effektivste und gebräuchlichste bevor H.265 mal salonfähig wird.
na ja - das ist aber keine neue Wahrheit :)
Antwort von WoWu:
Aber eben auch nicht der Weisheit letzter Schluss.
Jede Datenkompression verursacht in irgend einer Weise Artefakte.
Auch Unschärfe ist letztlich nichts Anderes als ein Artefakt, hervorgerufen aus örtlicher Prädiktion (bei DCT Basis) oder aus Scalierung (bei einer DWT Basis)
Setzt man den Codec auch gleichzeitig als Distributionscodec ein, kam man mit solchen Unschärfen leben (oder auch nicht).
Manchmal weiß man ja nicht mal, das die Kamera eigentlich mehr Schärfe generieren könnte, weil man durch den benutzten Codec gar keinen Vergleich hat.
Trifft nun diese Unschärfe auf einen weiteren Codec, der eine räumliche Prädiktion vornimmt, führten genau diese Unschärfen dazu, dass innerhalb des Zeitfensters keine präzise Zuordnung erfolgen kann und der Prozess abgebrochen wird.
Außer den sowieso auftretenden Artefakten aus der räumlichen Prädiktion kommen also Artefakte aus dem Prozessabbruch hinzu, die nicht entstanden wären, wenn keine vorgelagerte künstliche Unschärfe ins Bild gekommen wäre.
Es entstehen also zusätzliche Artefakte, meist Blocksichbarbeiten, die einzig und ausschließlich auf die Schwäche des vorgelagerten Codecs zurückzuführen sind.
Das ist aber nur ein einziges Beispiel aus Vielen.
Von den Folgen unterschiedlicher Transformationen und den daraus resultierenden Fehlern oder der Fehlerfortpflanzung gar nicht zu sprechen.
Losgelöst also von der ursprünglichen Codecqualität, die in dem Codecbereich sichtbar geworden sind, kommen also immer zusätzliche, vermeidbare Artefakte hinzu, die einzig daraus resultieren, dass generierte Fehler den Folgecodec in Stress versetzen.
Es ist also ziemlich abenteuerlich, zu behaupten, wenn man einen Codec vorweg setzt und erst bei der Ausspielung den Zielcodec wählt, dann das maximale an Qualität erhalten zu haben.
Erst die Arbeit ohne Vorcodec, also RAW und ein Workflow im Zielcodec oder mit Proxy stellt das sicher.
Ersatzweise eine einheitliche Codecfamilie, in der keine unterschiedlichen Tools zur Anwendung kommen.
Fehler in der Bildverarbeitung rufen IMMER Folgefehler hervor wenn Kompressionen kaskadiert werden.
Übrigens auch eigentlich gut gemeinte Dinge, wie enhancement Filter Methoden in der DCT haben Auswirkungen, wenn sie auf Folgecodecs stoßen.
Also selbst da, wo die Fehlerquelle nicht so offensichtlich ist, warten die Überraschungen im Workflow.
Es ist also nicht damit getan zu sagen ... vorne was breites und hinten ist das dann schon ok.
Das Thema Codec ist eben nicht mit der Bitrate abgeschlossen und natürlich auch nicht nur mit dem Alter eines Codecs, solange man nicht weiß, wie sich die Codecs verhalten und welche Änderungen die zeitliche Entwicklung mit sich gebracht hat.
Natürlich ist nichts gegen einen alten Codec einzuwenden, wenn man mit den schwachen Punkten leben kann und solange solche schwachen Punkte im Workflow keine weiteren Folgen haben.
Haben sie aber leider meistens.
Es sei denn, man ist mit der reduzierten Qualität noch zufrieden ... dann kann man auch beliebige Reduktionen miteinander verheiraten ... oder gleich eine billigere Kamera kaufen.
Antwort von Frank Glencairn:
...
Nur ist es einmal so und die Entwicklung im Codecbereich ist nunmal dramatisch vorangegangen.
...
Und wer die klassischen Wavelet Artefakte, z.B. verschwundene Bildanteile mag, und auf den ewigen Weichzeichner steht und zur Ausstrahlung dann nochmal in einen andern Codec wandeln möchte, um die Zahl der Artefakte nochmal drastisch zu erhöhen, der kann das ja gern tun.
Erklär' mir doch mal die Vorteile von Wavelet ... vielleicht hab ich ja was übersehen.
Der Vorteil von Wavelet ist, es ist das kleinste Übel.
IMHO sind alle long GOP Codecs zu Aquise ungeeignet, egal wie "modern" sie sind. Das selbe gilt eigentlich auch für verlustbehaftete Codecs wie ProRes. Wavelet/R3D sind zwar auch verlustbehaftet, aber in meinen Augen immer noch besser als DCT basierte, und damit das kleinere Übel. Außerdem kann man in raw aufnehmen.
Cineform wäre ein perfekter delivery codec. Aber momentan nehmen wir ja lieber mit 4k unkomprimiert auf, und liefern dann in einem Codec, der erst mal 80% der Bildinformationen aus dem Fenster wirft. Das kanns doch nicht sein.
Antwort von iasi:
@WoWu
Nativ in der Post zu bleiben, war ja schon immer eine Regel, die man anstrebte.
Deine Ausführung ist zudem logisch, wenn man annimmt, dass aus einem z.B. 4k-Raw ein möglichst identisches 4-Ausgabebild werden soll. Das erreicht man doch sowieso nicht. Schon das Debayern beginnt mit der mathematischen Interpolation.
Skaliert man zudem das Ausgangsbild herunter, so wirkt sich das eben auch auf die Artefakte aus, die sich dann nicht 1:1 in Ausgabeformat übertragen.
Ideal wären eindeutige Pixel/Farbwerte schon zu Beginn und ein Workflow, der bis zum Ende damit arbeitet. Wie Frank schon sagt: Wavelet ist wohl das kleinste Übel - ein Kompromis.
Das Ausgabeformat hängt dann von der möglichen Datenrate ab.
Es wäre eben mal wirklich interessant zu sehen, wie sehr H265 dann von der höheren Datenrate der UHD-BDs im Vergleich zum Streaming profitieren kann.
...und, ob z.B. Cineform bei den BD-Datenraten dann nicht doch mithalten kann.
Antwort von WoWu:
Ich glaube, ihr geht beide von der Annahme aus, dass eine Skalierung, wie sie in der DWT vorgenommen wird, verlustfrei vonstatten geht. Die Wavelet Transformation ist aber eine Form der Unterabtastung, bei der durch jede Filterung weitere Ungenauigkeiten entstehen, die sich primär durch Unschärfen auswirkt, wie solchen Transformationen nun mal an sich haben.
Das ist in der Tat Geschmackssache, ob ich unschärfere Bilder einer Cosinustransformation vorziehe.
Als Delivery Codec ist aber gerade das am ungeeignetsten, weil die Artefaktbildung bei kleinen Bitraten bereits zum Verlust ganzer Bildbestandteile führtund der DCT auch sichtbar deutlich unterlegen ist.
Von "kleinerem Übel" kann also spätestens da nicht mehr die Rede sein.
Und damit sind wir wieder bei der Kaskadierung, solange sich kein Endanwender findet, der Content im Bereich 200 MBit/s, DWT basiert ausstrahlt.
Mit dem "kleineren Übel" habt Ihr es also nur solange zu tun, wie Ihr in der Post arbeitet und noch vielleicht den weichen Look bevorzugt.
Spätestens bei der Überführung in einen Distributionscodec ist es nämlich damit vorbei und die Unschärfen der Bilder der DWT sorgen dafür, dass der Folgecodec schlecht wirkt, denn die zeitlichen Prädiktionen sind nicht auf Unschärfen angelegt.
Und so macht man dann aus dem "kleineren Übel" das deutlich größere Übel.
@Iasis
Die Interpolation in De-Bayering, die sich ja primär auf die Farbabtastung bezieht, hast du in den DWT Codecs ebenfalls.
Und das Thema Downscaling hatten wir hier schon ein paar mal und es ist keinesfalls so, dass Artefakte sich dabei verringern. Im Gegenteil.
Und, Frank, solche Statements, wie "alle GOP Formate sind für die Akquise ungeeignet" ist ziemlicher Quatsch.
Du musst Dir nur mal die Vergleiche anschauen und wenn ich 200Mbit I-Frame brauche um mit 25 MBit GOP in der Bildqualität gleich zu ziehen, dann führt das Deine Behauptung ad Absurdum.
Und bei größeren Datenraten erledigen sich die Artefakte aus der zeitlichen Prädiktion auch von ganz allein, weil kein Mensch bei 200 MBit mehr GOPs baut, dann aber immernoch die Vorzüge verfeinerter Tools bleiben und dann der Unterschied zwischen altem und neuem Codec sehr wohl zum Tragen kommt.
Du kannst es also drehen und wenden, wie Du willst, solange Du identische Verhältnisse miteinander vergleichst, wirst Du immer mit weit Entwickelten Codecs die deutlich besseren Ergebnisse erzielen.
Und nicht anders verbirgt sich hinter der Bezeichnung "alt" oder "neu". Es ist der Stand der Entwicklung einer technischen Software.
Du arbeitest ja auch nicht mehr auf einem AVID der 90er Jahre.... oder?
Damit kann man aber auch noch Bilder machen. Da würde ich Dir durchaus Recht geben.
Antwort von iasi:
Widersprechen kann ich dir in keinem Punkt - das Wundermittel gibt"s nun mal nicht.
Aber mit in die Betrachtung muss man eben auch immer den Rechenaufwand nehmen - gerade in der Post und eben auch bei der Aufnahme.
Klar kann man Hardware bauen, die ein HEVC-Video ohne große Mühe auf den Bildschirm bringen, aber davor wird"s eben doch noch aufwändiger.
In der Praxis scheinen mir Artefaktprobleme jedenfalls nicht so erheblich, wenn man es nicht mit der Komprimierungsrate übertreibt.
Antwort von WoWu:
Da weiß ich eben nicht, ob Du nur die Performanz unserer derzeitigen Hardware unterschätzt oder die Komplexität der Codecs.
Das einzige Problem lange Zeit war das, dass der Codec bereits für parallele Verarbeitungsarchitekturen aufgebaut war, die oft weder die Rechner, noch die Betriebssysteme und erst recht nicht die NLEs unterstützt haben.
Das war der eigentliche Haken an der Sache.
Aber sag selbst ... gibt es den Engpass heute noch ?
was geblieben ist, ist nur die Erinnerung daran in einigen Köpfen.
Das liegt aber an den Köpfen und nicht daran, dass heutige Workflows keine zeitlichen Prädiktionen in Echzeit verarbeiten können.
Und was die Artefaktprobleme angeht, sieh Dir die Beispiele im Paralellthread mal an, wo es um den sichtbaren Unterschied zwischen 24 und 200 MBit/ sec geht.
Antwort von iasi:
Da weiß ich eben nicht, ob Du nur die Performanz unserer derzeitigen Hardware unterschätzt oder die Komplexität der Codecs.
Das einzige Problem lange Zeit war das, dass der Codec bereits für parallele Verarbeitungsarchitekturen aufgebaut war, die oft weder die Rechner, noch die Betriebssysteme und erst recht nicht die NLEs unterstützt haben.
Das war der eigentliche Haken an der Sache.
Aber sag selbst ... gibt es den Engpass heute noch ?
was geblieben ist, ist nur die Erinnerung daran in einigen Köpfen.
Das liegt aber an den Köpfen und nicht daran, dass heutige Workflows keine zeitlichen Prädiktionen in Echzeit verarbeiten können.
Und was die Artefaktprobleme angeht, sieh Dir die Beispiele im Paralellthread mal an, wo es um den sichtbaren Unterschied zwischen 24 und 200 MBit/ sec geht.
Heute mag zwar FHD kein echtes Problem mehr für aktuelle Rechner darstellen, aber das eine oder andere Nadelöhr findet sich bei 4k aufwärts eben doch noch.
Ich sehe wiederum den Unterschied zwischen FHD und 4k, also liegt mir doch etwas an hoher Auflösung - zumal ich eben beim Ausgangsmaterial gern aus dem Vollen schöpfe und so viel Gestaltungsspielraum möchte, wie nur möglich.
Unkomprimiertes 5k-Raw z.B. ist auch heute noch extrem sperrig.
Und allein schon, wenn ich daran denke, dass z.B. AVCHD das Abspielen weniger parallelee Spuren erlaubt als Red-Raw mit weit höherer Auflösung ...
Mir ist schon klar, dass man mehr Bildqualität aus einer Datenrate herauskitzeln kann, aber das verlangt eben auch mehr Rechenaufwand.
ProRes ist nicht effizient und dabei auf einem Win-Rechner auch noch lahm - daher bin ich kein Freund von ProRes, denn damit sind die Vorteile verspielt.
Für die Post scheint mir HEVC auch nicht geeignet - wie auch H264. Aber ich lasse mich gern von dir eines Besseren belehren.
Antwort von WoWu:
Nein, es ist schon richtig, dass man mit dem Workflow auch zufriedenstellen arbeiten kann.
Das für eine gute Bildqualität RAW Material als Ausgangsmaterial die besten Vpraussetzungen bietet, darin sind wir ohne Zweifel einer Meinung. Deswegen präferiere ich auch Proxy Workflows, die noch am ehesten alle unterschiedlichen Anforderungen voll erfüllen.
Hör speziell von es aber um so vage Behauptungen, wie : GOP ist ein NoGo für Akquisition oder H.264 sei ungeeignet. Völliger Unfug.
Auch bin ich, wie Di aus vergangenen Diskussionen weißt, dass ich RAW noch etwas anders definiere als das 12Bit VIdeoformat in einem TIFF gebettet.
Erst recht, wenn man sich mal ansieht, wie die beiden Bits abgetrennt werden, wenn es zu 10 Bit konvertiert wird.
Da ist fast jedes flache 10 Bit LOG besser ... aber das ist ein anderes Thema.
Hier ging es ja darum, dass jemand versucht, ein lizenzpflichtiges Codierformat, bzw. die, durch Patentrechte geschützten Librarys zu knacken und ihm wohl entgangen ist, dass auch ursprünglich lizenzfreier Librarys, wie die JasPer Tools, seit der Implementierung in JPEG2000 nicht mehr lizenzfreier zur Verfügung stehen und dass sich Cineform natürlich Ihre, daraus zwangsläufig neue Entwicklung auch hat schützen lassen.
Also, die Verwunderung des Artikelautors darüber, dass er von den SMPTE Papieren, nicht die Blaupause für sein "Bootleg" bekommt, finde ich ziemlich blauäugig.
Wie Du siehst, sind wir ziemlich vom eigentlichen Thema abgewichen.
Antwort von mash_gh4:
Hier ging es ja darum, dass jemand versucht, ein lizenzpflichtiges Codierformat, bzw. die, durch Patentrechte geschützten Librarys zu knacken und ihm wohl entgangen ist, dass auch ursprünglich lizenzfreier Librarys, wie die JasPer Tools, seit der Implementierung in JPEG2000 nicht mehr lizenzfreier zur Verfügung stehen und dass sich Cineform natürlich Ihre, daraus zwangsläufig neue Entwicklung auch hat schützen lassen.
eine zeit lang waren die entsprechenden SDKs sogar frei zungänglich, allerdings nur in binärform. das war aber für alle entwickler derart uninteressant, dass sich niemand darum gekümmert hat. wenn nun jemand mit ein bisserl idealismus umd freude am hacken daherkommt und eine lösung schafft, die letztlich für alle seiten von vorteil sein dürfte, braucht sich doch wirklich niemand zu beklagen. selbst apple und avid können mit den freien implementierungen ihrer codecs ganz gut leben. und falls du wirklich ganz groß ins geschäft einsteigen willst, kannst ja sicherheitshalber mit ffmpeg und anderen rechteinhabern entsprechende zahlungen vereinbaren. niemand hindert dich daran!
Antwort von WoWu:
Doch, wie Du siehst, das Lizenzrechte denn selbst bei Lizenzerteilung sind Verbreitung und Zweck sehr streng definiert.
Und was Du so locker als HACK bezeichnest ist strafrechtlich mit Gefängnisstrafe bewehrt.
Und was die JasPer Projekt Tools betrifft, ist das seit JPEG 2000 vorbei, also schon etliche Jahre.
Und wer einen CINEFORM Codec haben möchte, wird ihn sicher erwerben können.
Antwort von mash_gh4:
Doch, wie Du siehst, das Lizenzrechte denn selbst bei Lizenzerteilung sind Verbreitung und Zweck sehr streng definiert.
zuerst muss einmal jener, der wirklich im besitz der entsprechenden rechte ist, sich in seinen tatsächlichen interessen verletzt fühlen, und nicht irgendjemand dahergelaufener am trittbrett irgendwas über die schützenswerten grundfesten des kapitalismus wettern...
Antwort von WoWu:
Was glaubst du denn, warum man etwas mit Lizenz- oder Patentrechten belegt.
Ein Diebstahl ist ja auch nicht erst strafbar, wenn der Besitzer den Gegenstand vermisst.
Das ist doch mal wieder völlig absurd, was Du da von Dir gibst.
Antwort von cantsin:
Momental mal, WoWu, es gibt genau zwei Formen des geistigen Eigentums (intellectual property), die beim reverse engineering von Dateiformaten oder Software-/Netzwerkprotokollen verletzt werden können: (1) Patente, (2) Urheberrecht. Urheberrecht bezieht sich immer auf Wortlaut, nicht auf Techniken bzw. Verfahren. Eine Urheberrechtsverletzung kann beim reverse engineering dann geschehen, wenn Code kopiert wird (entweder Quellcode oder disassemblierter Code). Es gibt deshalb fürs reverse engineering auch "Chinese Wall" genannte "Reinraumverfahren", die auch in der Softwareindustrie eingesetzt werden und bei denen durch zwei getrennte Entwickelteams auch unbeabsichtigtes Kopieren vermieden wird, siehe https://en.wikipedia.org/wiki/Chinese_w ... ngineering .
Bei Patenten müsste man erst genau sehen, was genau an Cineform patentiert ist. Wenn das Wavelet-Codec-Verfahren, wie Du schreibst, schon 50 Jahre alt ist, stellt sich durchaus die Frage, welche Patente bei Cineform noch greifen. Auch hier gibt's große Unterschiede in Rechtssprechung und Rechtsräumen. Z.B. lehnt Frankreich die Patentierung von Algorithmen kategorisch ab, weshalb z.B. die Open Source Codec-Bibliotheken, die ffmpeg und VLC zugrunde liegen, auch in Frankreich entwickelt werden.
Eine freie Implementation von Cineform wäre IMHO schon deshalb wünschenswert, weil Status, Pflege und Zukunft von Cineform in der heutigen GoPro-Eigentümerschaft extrem unklar geworden sind - gibt's z.B. Cineform Raw überhaupt noch? Mit einem freien kompatiblen Codec bliebe archiviertes Cineform-Material auch dann noch abspielbar, wenn GoPro den Stöpsel ziehen sollte. (Von der Abspielbarkeit auf anderen Betriebssystemen wie Linux ganz zu schweigen.)
(EDIT: Ich vermute, dass man bei GoPro selbst nicht mehr weiss, was man mit Cineform anfangen soll. Als Intermediate Codec für mp4-Material aus Hero-Kameras braucht ihn heute kein Mensch mehr, und auf den digitalen Kinokamera-Markt von Blackmagic, Aja, Kinefinity & Co. scheint GoPro sich als Massenhersteller nicht begeben zu wollen.)
Antwort von WoWu:
Es geht bei Coneform um die Bibliotheken.
Das Wavelet Verfahren von Alex Großmanns wird rechtlich von einer Anwaltskanzlei in Florida vertreten.
Beide Bereiche bedürfen einer rechtlichen Freigabe und Cineform ist ja erst vor ein paar Jahren eingestiegen, sodass die vermutlich noch sehr genau wissen, was ihre Ansprüche sind.
Man mag hier auch um Details streiten und die rechtlichen Ansprüche mögen unterschiedlicher Natur sein, fest steht, das ein Hacker nicht einfach einen Codec greifen kann und ihn zu Public Domain erklären kann.
Software ist kein rechtsfreier Raum, aber manche stellen sich das so vor.
Man muss eben nur über ein gerüttelt' Maß an krimineller Energie verfügen, damit die Grenzen unscharf genug werden.
Dass eine Pflege wünschenswert ist, mag ja sein, nur gibt es auch legale Methoden, die Rechte an Codecs zu erwerben.
Dann muss er auch nicht mehr hilflos im Code rumstochern.
Abgesehen davon gibt es ja auch Urteile und Ausnahmen im Lzenzrecht, die genau regeln, welche Schritte des Re-engineerings straffrei sind, sobald eine Software nicht mehr unterstützt wird, um bestehende Systeme zu maintainen und den Wert zu erhalten. Der Grad ist in der Rechtssprechung ab super-schmal.
Nur soweit ist es auch noch nicht und wenn man sich die GoPro Aktie mal anschaut, sieht das im Augenblick nicht gerade nach einem Konkurs aus, sodass solche Ausnahmen vermutlich noch lange nicht greifen werden.
