| Wünsche für neuen Videocodec?
Noch was unklar? Dann in unserem Forum nachfragen
Zum  Orginal-Thread / Zum Videobearbeitung / Postproduktion allgemein-Forum
Frage von LarsProgressiv:
Hallo Leute,
auf dem Nachrichtenverteiler der Entwickler des FFmpeg Projekts werden gerade Überlegungen angestellt, wie ein neuer, effizienter, frisch zu entwerfender Videocodec aussehen müsste bzw. zu implementieren wäre.
Ich hatte vor einiger Zeit schon große Hoffnungen auf Snow gelegt, die sich mit der Zeit dann verflüchtigten.
Hier nun meine Frage: Was wären für euch wichtige Eigenschaften eines neuen Videocodecs, wenn ihr sie euch wünschen könntet.
Folgendes wird vermutlich automatisch gegeben sein:
- quelloffen und frei verfügbar (;für Linux, BSD, Windows, Mac, ...)
- kostenfrei in proprietäre Programme integrierbar (;LGPL)
- für verschiedene Kontainerformate spezifiziert (;Ogg, Matroschka, Nut, AVI , ...)
Meine zusätzlichen Wünschen wären:
- Enkodierer nutzt mehrere Prozessorkerne (;min. 2; besser mehr)
- Dekoder kann jede alte Version dekodieren (;für Archivzwecke)
- verlustfreier Modus wäre nicht schlecht
So nun eure Wünsche.
Danke
Lars
Antwort von WoWu:
Hallo Lars
Codecentwicklung ist zwischenzeitlich in ein derart schmales zeitliches Fenster gefallen, dass die Echtzeitfähigkeit mittlerweile nur noch einhergeht mit korrespondierenden DSP Entwicklungen, wie die Entwicklung bei H.264 zeigt.
Die Zeit, etwas entsprechend effizientes auf den "heimischen" Rechnern darstellen zu wollen, ist vorbei.
Solange eine Codecentwicklung nicht einhergeht mit der passenden Chipentwicklung, wird sie ihr Ziel nicht erreichen können.
Seit Jahren entwickelt auch MPEG an einem neuen Codec, um zu sehen, wie es nach einem H.264 wohl aussehen könnte und hat mit dem MCTF-SBG gute Ergebnisse erzielt, stellt aber gleichzeitig fest, dass sie damit noch weit entfernt sind von der Verwendung in einer Echtzeitanwendung.
Daher stellt sich wirklich die Frage, ob eine solche "Wunschliste" nicht vergebene Liebesmühe darstellt, zumal wenige der derzeitigen Anwender bisher überhaupt eine Vorstellung davon haben, inwieweit interaktive Elemente und das separate Übertragen von einzelnen Bildelementen oder Layern des einzelnen Bildes für eine zukünftige Rolle spielen werden.
Vergessen darf man eben nicht, dass solche Elemente, aber bereits Teil von MPEG4/H.264 sind .... aber im augenblicklichen Zeitpunkt überhaupt noch nicht benutzt werden.
Also müsste so ein "Zukunftscodec" weit über Möglichkeiten reichen, die die Anwender heute noch gar nicht kennen, geschweige benutzen.
Auch die qualitative Anforderung müsste vor einem Hintergrund definiert werden, vor dem auch H-264 in seinen qualitativen Möglichkeiten erst im Ansatz benutzt wird.
Daher wäre so eine Wunschliste zwar interessant, kann aber, weil sie auf der "Derzeit" aufsetzt, nicht besonders aussagekräftig sein.
Warten wir doch einmal ab, bis die Hardwaremöglichkeiten uns erlauben, auch im Consumerkreis bestehende Codecs bis an ihre Grenzen auszunutzen. Ich bin sicher, bis dahin werden auch die Probleme in Bezug auf die Echtzeitmöglichkeiten zukünftiger Codecs, wie z.B. dem MCTF-SBC von der Chipindustrie auch gelöst sein.
Antwort von LarsProgressiv:
Hallo Wolfgang,
wenn ich Dich recht verstehe, wünscht Du Dir folgendes:
- Echtzeitfähigkeit (;Dekoder oder Enkoder?)
- Abbildung in Hardware
Zu den andern Aspekten möchte ich nur ausführen, dass ich einen reinen Videocodec brauche, der keine interaktiven Elemente oder anderes enthält.
Es soll einfach nur ein Strom von Bildern kodiert werden.
Ich brauche einen zukunftssichern Codec, damit meine ich eine Lösung, die mir meine privat gedrehten Filmchen aufnimmt und verpackt mit dem zugehörigen Ton in Vorbis in einem offenen Kontainer (;MKV) für die _Ewigkeit_ nutzbar konserviert.
Es soll also für mich, meine Enkel und Urenkel usw. möglich sein, die Filmchen wieder abzuspielen. Und das sehe ich bei einem offenen Standard als gegeben an, da Dokumentation und Quellcode verbunden mit Kostenfreiheit und Gebührenfreiheit soetwas garantieren.
Hierbei sei einmal abgesehen von Patenten, deren Verletzung man nicht wirklich ausschließen kann, die jedoch irgendwann auslaufen.
Die Enkodiergeschwindigkeit spielt für mich keine Rolle, wobei die Dekodiergeschwindigkeit schon wichtiger ist, in Bezug auf die zukünfitgen Systeme aber wieder in den Hintergrund gerät. Ich brauche also keinen Codec zum Schneiden. Ihr nennt das wohl Intermediateformat, oder?
Mich interessieren einfach die Wünsche anderer Nutzer.
Wobei ich davon ausgehe, dass man Wünsche umsetzen sollte und nicht, wie Kommerzielle Unternehmen es tun, Spielereien vorsieht, in der Hoffnung, das es irgendwann in der Zukunft gebraucht wird.
Damit meine ich die von Dir erwähnten, offenbar in H264 eingebrachten interaktiven Elemente.
Grüße
Lars
Antwort von WoWu:
Hallo Lars,
vielen Dank für die Antwort, aber dann hatte ich Dich in Deinem ersten Post falsch verstanden, ich bin davon ausgegangen, dass Michael N. nach Snow ein neues Projekt auflegen wollte, nicht aber von einer allgemeinen Wunschliste nach Codecfeatures ...
Mich interessieren einfach die Wünsche anderer Nutzer.
Wobei ich davon ausgehe, dass man Wünsche umsetzen sollte und nicht, wie Kommerzielle Unternehmen es tun, Spielereien vorsieht, in der Hoffnung, das es irgendwann in der Zukunft gebraucht wird.
Damit meine ich die von Dir erwähnten, offenbar in H264 eingebrachten interaktiven Elemente.
Leider hast Du mich gründlich falsch verstanden, als ich von interaktiven Elementen im Codec gesprochen habe ... das sind derzeit nicht etwa Bedienungsfeature, die in H.264 eingearbeitet (;versteckt) sind und natürlich derzeit nicht genutzt werde können, sondern beispielsweise die Möglichkeit, einzelne Bildsegmente (;Slices oder Slicegruppen) einer individuellen Verarbeitung zu unterziehen. Das hat schon heute bedeutende Vorteile in Bezug auf die Qualität des Bildes, schliesst aber eben für zukünftige Nutzung die Möglichkeit ein, auch solche Segmente einzeln, also ohne das Restbild zu übertragen und natürlich auch, solche Elemente auf einem andern Transportweg abzusetzen, also Bild über TV und Elemente über das Internet.
Damit öffnen solche Möglichkeiten natürlich Anwendungen, aber, wie gesagt, bereits heute ist der Nutzen ganz klar vorhanden.
Und das sehe ich bei einem offenen Standard als gegeben an, da Dokumentation und Quellcode verbunden mit Kostenfreiheit und Gebührenfreiheit soetwas garantieren.
Was den "offenen Standard" und Deine Zukunftserwartungen angeht, so sind gerade MPEG4 und MPEG2 klassische offene Standards, ganz im Gegensatz zu vielen proprietären oder gar frei verfügbaren, denn gerade die sind alles andere als offen und so gut wie nie gibt es eine Referenzimplementierung, so dass Du eigentlich nur bei solchen Standards wie MPEG2 / 4 sicher sein kannst, dass Du noch in 30 Jahren einen lauffähigen Dekoder bekommst, was für die andern Codecs wohl nicht mit der Sicherheit zutrifft.
Auch Dokumentation und ggf. Quellcode nutzt Dir absolut nichts, weil Deine Urenkel sich sicher nicht hinsetzen werden und nachforschen, welche Version bei Deiner Encodierung eigentlich benutzt wurde und ihn neu einhacken... Ganz bestimmt nicht. Und was die Quellcodes anget, schau mal ins Netz, welcher freie Code wirklich gepflegt ist ... da finde ich nur einzelne Perlen in einem Wust an Durcheinander.
Also darauf würde ich nicht wetten, das das klappt, wohl aber auf einen Standard, der mittlerweile weltweit anerkannt und verbreitet ist, den sowohl die Industrie, als auch die Broadcaster unterstützen und in dem Du die nächsten 15 Jahre (;wenn nicht mehr) auch deine TV Programme empfangen kannst.
Mein Wunsch, nach einer Abbildung in HW ist wohl gar nicht zu umgehen, weil eigentlich die Zeit der Softwareencoder bei der Latte der Anforderungen vorbei sein dürfte und selbst, wenn es Dir persönlich nicht unbedingt auf die Echtzeit ankommt, wird sich wohl kein (;kommerzieller Programmierer) mehr finden, der Codecs auf die alten HW Architekturen anpasst, weil die Ergebnisse entlang der Anforderungen natürlich immer schlechter werden.
Und was die Patente betrifft ....nur ein Beispiel: Microsoft hat seinen VC1 ja aus einem frühen Entwurf aus der H.264 Entwicklung ... na sagen wir mal entliehen ... Da sie mögliche Nutzer auf die Offenlegung bestanden, mussten zwangsläufig auch die Rechte Dritter offengelegt werden. Das sind etwa 200 Patenthalter, allein für diesen Codec. Nun magst Du ein Bild bekommen, wie viele Firmen an solchen Entwicklungen beteiligt sind. Bei MPEG sind es über 300, die am H.264 mitarbeiten.
Will eine Firma also einen gleichwertigen, leistungsfähigen Codec auf den Markt bringen, muss schon einiges passieren ... oder eben, man entleiht ihn sich, wie beispielsweise die Chinesen. Wenn ich mir deren HDTV Spezifikation anschaue, kann ich auch gleich die H.264 daneben legen, nur dass viele chinesische Universitäten als Ursprung genannt werden.
Du siehst, neue, wirklich bahnbrechende Codecs kommen nicht einfach aus der Feder von findigen Entwicklern, sondern sind ein konzertiertes Produkt und wenn Du in die Zukunft siehst und möchtest, dass Deine Enkel ihn noch lesen können, dann bist Du mit einem solchen, übergreifenden Produkt wie H.264 noch am Besten bedient.
Auch, wenn es derzeit noch etwas Pioniergeist erfordert, Deine Enkel und Urenkel werden es Dir danken, wenn Du keinen obskuren Codec wählst, nach dem in ein paar Jahren kein Hahn mehr kräht.
Antwort von motiongroup:
hallo Lars, bist di in diesem von Dir angesprochenen Spektrum nicht in der Liga vom DIRAC Codec
http://diracvideo.org/
http://www.codec-download.de/codecs/video_codecs/bbc_dirac_video_codec_0.5.4_99.html
http://www.google.de/custom?domains=slashcam.de&q=dirac&sa.x=0&sa.y=0&sa=suche&sitesearch=slashcam.de&client=pub-8291754662609381&forid=1&ie=ISO-8859-1&oe=ISO-8859-1&cof=GALT%3A%23008000%3BGL%3A1%3BDIV%3A%23336699%3BVLC%3A663399%3BAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3AF09201%3BALC%3A000000%3BLC%3A000000%3BT%3A0000FF%3BGFNT%3A0000FF%3BGIMP%3A0000FF%3BLH%3A47%3BLW%3A429%3BL%3Ahttp%3A%2F%2Fwww.slashcam.de%2Fimages%2F%2Fgooglesuche_unserlogo.gif%3BS%3Ahttp%3A%2F%2Fwww.slashcam.de%3BFORID%3A1%3B&hl=de
Antwort von LarsProgressiv:
Hallo Wolfgang,
nein, was Michael macht, weiß er nicht. Wenn ich ihn richtig verstanden habe gibt es mehrere Möglichkeiten:
- garnichts machen und Snow sterben lassen
- Snow weiterentwickeln und zu einer Version 1.0 bringen
- andere Codecs (;h264) als Grundlage nehmen und verbessern
--- unnötiges entfernen
--- qualität verbessern
--- geschwindigkeit optimieren
Was nun wirklich passiert liegt an ihm.
Ich bin nicht sein Koordinator oder so. Ich wollte nur mal so hören was andere dazu meinen, wenn sie sich einen Codec wünschen könnten.
Ich bin kein Mathematiker und kenne mich deswegen nicht mit den wirklichen Eigenschaften von H264 oder anderen aus. Ich kenne nur das, was ich benutze und einstellen kann. Und dabei fällt mir oft auf, dass ich bestimmtes garnicht nutze und brauche.
Da aber H264 Lizenzkosten verlangt ist er nicht der richtige Codec für mich. Ich bin da Idealist. Ich benutze auch keine proprietäre Software für alles andere, was ich so mache.
Letzte Frage dazu: Welche Farbräume in welcher Farbtiefe bräuchtest Du unterstützt?
Hallo motiongroup,
Dirac ist schon ganz gut, schon allein da er unter (;L)GPL gestellt wurde. Ich hatte mich schon fast für dirac entschieden, wollte aber nochmal nach Snow schauen, bevor ich mich festlege. Mal schauen was dabei rauskommt.
Grüße
Lars
Antwort von WoWu:
Hallo Lars,
Danke für dei Informationen ...
Sicher sind meine Anforderungen noch etwas anders als von einem Consumer, weil wir ausschliesslich für TV arbeiten. Da immer mehr 720 nachgefragt wird haben wir vorgesehen, so schnell wie möglich 720p50/60 in 4:4:4 mit 12 bit zu machen. Das ergibt (;für das von uns ausgewählte Profile&Level) eine Datenrate von rd. 200 Mbit/s und ist somit noch problemlos handhabbar.
Auch natürlich, weil wir die Archivierung im Hintertkopf haben. Derzeit machen wir rd. 2Min. Endfertigung täglich und kommen bereits heute damit auf rd. 600 TByte pro Jahr, die archiviert und gepflegt werden müssen. Also 600 1 TByte Platten pro Jahr.
Auch in Bezug auf den Farbraum kommt für uns eigentlich für -nicht RGB- Anwendung nur YCoCg in Frage, weil YUV eigentlich nie für die Anwendung im digitalen Bereich vorgesehen war und die elendigen Rundungsfehehler und die schlechte Kodiereffizienz immer nur zu Kompromissen führten. Daher die Entscheidung für YCoCg.
Die Sache mit DIRAC würde ich mir auch noch einmal überlegen, speziell im Hinblick auf deine Anwendung. Damit würdest Du, nach meiner Einschätzung nicht wirklich glücklich werden ... dennoch würden mich Deine Beweggründe dafür einmal interessieren.
Antwort von LarsProgressiv:
Guten Abend Wolfgang,
schick doch mal einen Link, der mir den Unterschied zwischen YCoCg und YUV. Kann mir zwar nicht vorstellen, dass das für TV sinnvoll ist, aber ich lerne gern dazu.
Bisher fand ich nur YCbCr.
Gute Nacht
Antwort von WoWu:
Hallo Lars,
dieser NVIDIA Papier ist aufschlussreich:
http://developer.download.nvidia.com/whitepapers/2007/Real-Time-YCoCg-DXT-Compression/Real-TimeYCoCg-DXTCompression.pdf
Gruss Wolfgang
Antwort von LarsProgressiv:
Guten Morgen Wolfgang,
die Konversion, die in dem Papier beschrieben ist, verwendet aber auch Rundungen. Zumindest bei der Konversion zurück zu RGB.
Außerdem entsteht schon ein Verlust bei der Konversion zu YCoCg.
Wenn Du es wirklich verlustfrei haben wolltest, müsstest Du schon YCoCg-R verwenden.
Aber welche Kamera zeichnet schon in diesem Farbraum oder RGB auf?
Grüße
Lars
Antwort von WoWu:
Hallo Lars
das ist nicht so ganz richtig, weil De-und Encoder lediglich noch Addition und Shift Operationen für beide Prozesse benötigen.
Ausserdem fallen die schwer zu implementierenden Werte für Koeffizienten weg.
Der Wunsch nach dem Farbraum ist nicht ungewöhnlich und wird beispielsweise in AVC FRExt unterstützt, ebenso wie der RGB Farbraum in 4:4:4. Derzeit kann man das allerdings erst mit der VSoft Implementierung. Aber ich bin ziemlich sicher, dass andere Implementierungen nach ziehen.
Was Deinen Einwand bezüglich YCoCg-R betrifft, so ist es ja gerade die größere Dynamic, die den YCoCg so interessant macht, denn gegenüber yCoCg-R ist sie um knapp 1 db größer. Microsoft hat das -R eingefügt, um eine stärkere Kompression zu erreichen ... Ich denke aber, das ist an dieser Stelle die falsche Einsparung. Ausserdem gibt das wieder Multiplikationsprozesse ..
Das Papier (;Link) ist von 2003 und war als Anregung für die Standardisiertug gedacht ... offensichtlich ist es ja dann auch nicht in den Standard eingeflossen.
Aber welche Kamera zeichnet schon in diesem Farbraum oder RGB auf?
Schon klar, aber darum geht es ja gerade auch bei einem solchen Codec, gerade weil keine Kamera in 4:4:4 aufzeichnet, einen sinnvollen Weg über den Codec zu finden, die entsprechende Tiefe zu machbaren Datenraten aufzuzeichnen und weil wir 720p60 machen, wären das bei 4:4:4 und 12 Bit mit AVCFRext rd. 200 Mbit/s ... und damit die Datenrate, die uns in Bezug auf Verarbeitung und auch Archivierung noch handhabbar erscheint.
Nur ich denke, dass es in Bezug auf den Farbraum endlich mal angesagt ist, die alten Analogzöpfe abzuschneiden und YUV zu vergessen.
Will man also jetzt einen neuen, weiterreichenden Codec andenken, so sollten diese Anforderungen mindestens ebenso erfüllt sein.
Du siehst, die Latte für einen neuen Codec liegt hoch, auf der andern Seite erleichtern eben gerade solche Anforderungen wiederum die Implementierung.
Antwort von LarsProgressiv:
Hallo Wolfgang.
Hallo Lars
das ist nicht so ganz richtig, weil De-und Encoder lediglich noch Addition und Shift Operationen für beide Prozesse benötigen.
Nur weil nur noch Addition- und Shiftoperationen durchgeführt werden, ist die Umwandlung nicht automatisch verlustfrei. Sondern einfach nur unheimlich schnell.
Denn wie im Verweis schon steht, wird die Konvertierung von RGB nach YCoCg mit Bitverlust durchgeführt:
[code:1:33abb0aabb]Y=(;(;R+B)>>1)+G)>>1[/code:1:33abb0aabb]
Damit verliert man jeweils das geringwertigste Bit. Und schon ist der Verlust da. Deshalb wurde YCoCg-R entwickelt, weil dort kein Verlust auftritt. Zu beachten dabei ist, dass es hier eine Umwandlung von 3 8-Bit-Werten in 3 8-Bit-Werte ist. Mann kann diesen Verlust, wie im Papier beschrieben, dadurch auffangen, indem man jedem Kanal 2 weitere Bits spendiert. Dann bildest Du 8-Bit RGB-Werte (;24 Bit gesamt) auf 10-Bit YCoCg-Werte (;30 Bit gesamt) ab.
Anderseit passten 30-Bit RGB-Werte (;10Bit je Kanal) in den 32Bit YCoCg Farbraum verlustfrei.
Was Deinen Einwand bezüglich YCoCg-R betrifft, so ist es ja gerade die größere Dynamic, die den YCoCg so interessant macht, denn gegenüber yCoCg-R ist sie um knapp 1 db größer. Microsoft hat das -R eingefügt, um eine stärkere Kompression zu erreichen ... Ich denke aber, das ist an dieser Stelle die falsche Einsparung.
Die Dynamik ist laut dem Paper aber nur durch die dazugemogelten Bits vergrößert, die bei einer Rückumwandlung in RGB wieder verschwinden.
Das ist zwar auch bei YCoCg der Fall, aber
- 32-Bit YCoCg-R kann auf 30-Bit RGB verlustfrei abgebildet werden und
- 30-Bit YCoCg kann nur auf 24-Bit RGB verlustfrei (;oder verlustbehaftet auf 30-Bit RGB) abgebildet werden.
Ausserdem gibt das wieder Multiplikationsprozesse ..
Wo steht das? Es sind in beiden Richtungen (;Konversion) nur Additions- und Shiftoperationen notwendig. Und das auch noch in gleicher Anzahl.
Grüße
Lars
Antwort von WoWu:
Stellt sich nur die Frage, warum ist der Vorschlag dann nicht in den Standard eingeflossen, immerhin ist er ja von Microsoft schon ins Juli Meeting 2003 eingebracht worden ?
Man müsste jetzt mal die JVT/MPEG Papiere verfolgen. (;müßig)
Darüber hinaus geschieht allerdings auch meistens keine Rückführung zum RGB Signal mehr.
Aber warum sollte eine solche Änderung nicht zumindest einmal probiert werden ? Nur interessant wäre natürlich schon zu erfahren, warum der Vorschlag verworfen wurde.
Antwort von LarsProgressiv:
Hallo Wolfgang,
ich glaube, ich muss mich berichtigen.
Da ich den eigentlichen Standard nicht wirklich Schwarz auf Weiß habe, kann ich es nicht mit Bestimmtheit sagen, aber es scheint, als ob YCoCg-R im Standard als YCoCg übernommen wurde.
Zumindest las ich das aus der:
Dirac Specification
Version 2.2.3
Issued: September 23, 2008
heraus.
Stelle: F.1.5.2 YCoCg coding
Leider kann ich die wirkliche Codierung als Bitstrom nirgends finden.
Wenn Du etwas finden solltest, wäre ich über einen Hinweis sehr erfreut.
Grüße
Lars
Antwort von WoWu:
Ich hab"Rico Malvar mal über meinen alten MPEG-Account angefragt. Vielleicht gibt es ja eine Antwort, weil das Thema für mich nicht so weit oben auf der Liste steht.
Warten wir"s ab.
Antwort von WoWu:
@ lars
Hallo Lars,
Frage war, warum das Papier VT-I014r3 keine Berücksichtigung im Standard gefunden hat.
Folgende Antwort habe ich erhalten:
Dear Wolfgang,
I did not attend the JVT standards meetings where color spaces were discussed, so I don’t know the reasons. My best guess is that one issue could have been backward compatibility with other codecs, for transcoding applications.
You may have noticed that YCoCg-R was adopted in the fidelity range extensions.
Best regards,
Rico Malvar
Das würde dann auch erklären, warum es in DIRAC wiederzufinden ist.
Um den Grund zu finden müsste man jetzt das Meeting-Protokoll heraus suchen ... aber das "schenke" ich mir dann doch.
Antwort von LarsProgressiv:
Danke Wolfgang!
Lars
Antwort von TheBubble:
Ich brauche einen zukunftssichern Codec, damit meine ich eine Lösung, die mir meine privat gedrehten Filmchen aufnimmt und verpackt mit dem zugehörigen Ton in Vorbis in einem offenen Kontainer (;MKV) für die _Ewigkeit_ nutzbar konserviert. Es soll also für mich, meine Enkel und Urenkel usw. möglich sein, die Filmchen wieder abzuspielen.
Eine Abspielbarkeit bzw. Unterstützung neuer Hardware und Betriebssysteme wird wohl niemand für sehr lange Zeiträume garantieren (;können). Schon heute gibt es z.B. gelegentlich Probleme mit der Wiedergebe von alten Videoaufnahmen oder Datenbändern.
Man könnte versuchen, als Archivformat einen so verbreiteten Codec zu wählen, dass man davon ausgehen kann, dass noch möglichst lange der Bedarf an einer Wiedergabe des Dateiformats besteht. Zusätzlich darf man die eigenen Filme nicht einfach für längere Zeit vergessen, so dass sie, wenn sich die aktuell benutzten oder unterstützten Codecs ändern, rechtzeitig umgewandelt werden können.
Und das sehe ich bei einem offenen Standard als gegeben an, da Dokumentation und Quellcode verbunden mit Kostenfreiheit und Gebührenfreiheit soetwas garantieren.
Nützt alleine alles nichts, so lange man selbst nicht in der Lage wäre, die Software zu warten, gegebenfalls auf neue Betriebssysteme und Hardware anzupassen, zu portieren oder neu zu implementieren oder genug Geld hat, später jemanden für diese Tätigkeiten zu bezahlen.
Den Aufwand einer Reimplementierung könnte man reduzieren, indem man Codec wählt oder entwickelt, dessen Abspielkomponente möglichst einfach aufgebaut und gut dokumentiert ist. Aber auch dann bräuchte man jemanden, der dies in der Zukunft auch macht, selbst wenn es gegenüber anderen heute verwendeten Codecs einfacher ist.
Und zusätzlich darf man bei so einem Projekt nicht vergessen, dass es nicht nur um das Dateiformat geht, sondern auch die Medien, auf denen die Daten abgelegt sind, in der Zukunft noch lesbar sein müssen. Auch hier sind Backups und Übertragungen auf aktuelle Technik einzuplanen.
Noch was unklar? Dann in unserem Forum nachfragen
Zum Orginal-Thread / Zum Videobearbeitung / Postproduktion allgemein-Forum
| |
