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
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.
derkiki hat geschrieben:Der Coded kann raw als wavelet komprimieren, du Schlauberger. Also durchaus erstrebenswert. 50 Jahre alt sind deine Denkansätze.
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.
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.
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 ?
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. :)
Frank Glencairn hat geschrieben:
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 :)
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.
WoWu hat geschrieben:
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 ...
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?
srone hat geschrieben: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.
iasi hat geschrieben: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?
iasi hat geschrieben: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.
iasi hat geschrieben: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?
iasi hat geschrieben: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 ... :)
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.
srone hat geschrieben: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 ...
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.
Starshine Pictures hat geschrieben: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.
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.
WoWu hat geschrieben:...
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.
@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.
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.
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.
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.
WoWu hat geschrieben: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.
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.
WoWu hat geschrieben: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!
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.
