tja - aber wofür suchten denn die Broadcaster einen Codec?WoWu hat geschrieben:Nee, gar nicht ... die BBC hat es für ihre Hardware ja auch vor vielen Jahren ins Spiel gebracht (DIRAC) und ist auch wieder davon ab.
Wavelet kommt und geht, egal wie man es nennt ... und das schon seit fast 40 Jahren und Generalüberholungen am Codec haben ihn auch nicht besser gemacht.
Zuletzt standen ja 12 Wavelet (von 15) Codecs zur Auswahl, als die Broadcaster einen skalierbaren Codec gesucht haben.
Nun, keiner der 12 konnte offenbar punkten, obwohl er fast kostenlos zu bekommen gewesen wäre.
Das hat also nichts religiöses. Da ist schon was dran, dass man sich sowas heute nur noch antut, wo man auf den Pfennig achten muss oder wo man mit wenig Investition möglichst viel verdienen will.
Das richtige Werkzeug für die jeweilige Aufgabe.WoWu hat geschrieben:Sie haben einen Codec gesucht, der skaliert, also quasi in Lagern die einzelnen Bildauflösungen über die gesamte Spanne von SD über HD, bis hin zu UHD 1 und 2 übertragen kann und damit alle Auflösungen nur in einem DatenStrom übertragbar ist und der Receiver nimmt sich nur die Auflösung heraus, die das gerät umsetzen kann.
Es ging darum, für SD-UHD nicht so viele verschiedene Übertragungssctröme vorhalten zu müssen.
Es ging also nicht darum, irgendwelche Codecs zu ersetzen, sondern ein zukünftiges Übertragungssystem zu entwickeln, das skalierbare Layer überträgt.
Abgelehnt ... tja, wie will man es nennen, wenn keines der 12 wavelet die Entscheidung für sich verbuchen könnt.
HEVC ist es geworden, mit der Skalierungsvariante vom Fraunhofer. Das finde ich schon ziemlich "generell.."
Aber ist es denn nicht gerade bei hohen Datenraten mit den Vorteilen z.B. von AVC vorbei und die Nachteile kommen stärker zum Tragen?WoWu hat geschrieben:Frank, die Architektur ist damit auch nicht gemeint (Long-gop) sondern die Unterschiede im Codec, also in den unterschiedlichen Codierverfahren.
Wavelet ist ja nicht durchgefallen, weil man damit keine GOPs bilden kann.
Und mit den datenraren hat das auch nichts zu tun.
Ich kann auch AVC mit 900 Mbit/s betreiben, habe aber wenigstens Intra- ein gutes Verfahren (wenn ich es bei der datenrare überhaupt noch brauche).
Aber alles dazwischen ist ja auch möglich.
Aber bei hohen Datenraten unterscheiden sich die Codecs ohnehin immer weniger, weil die schlechten Tools sich erst in der Tendenz nach unten deutlicher unterscheiden.
iasi hat geschrieben: Sicherlich sind hocheffiziente Codecs dann von Vorteil, wenn es um hohe Bildqualität bei geringen Datenraten geht, aber wenn - wie bei Aufnahmeformaten - die Datenraten nur ein Kriterium ist, scheinen eben z.B. weniger rechenintensive Verfahren von Vorteil.
Wenn mehr eine halbwegs aktuelle NVIDIA-Karte heisst dann geht auch ein Rechner mit Technik aus den letzten paar Jahren. Bei RedRaw erkauft man sich die Leichtigkeit des Schneidens mit den erhöhten Speicherplatz.iasi hat geschrieben:AVCHD fordert z.B. selbst bei HD einen Schnittrechner mehr als RedRaw in 4k.
Bitte..? Also quasi jede 0815 Knipse/Handy/Consumer/Pro-Camcorder kann AVC(HD) in unterschiedlichen Qualitäten und Auflösungen aufzeichnen. Da gibt es seit Ewigkeiten Chips die alles in Echtzeit machen. Stromverbrauch, Größe und Hitzeentwicklung sind alles 'gelöste' Probleme.iasi hat geschrieben:Und du kannst ja nicht davon ausgehen, dass bei Kameras unbegrenzt Rechenleistung zur Verfügung steht - schließlich spielen Faktoren wie Wärmeentwicklung, Stromverbrauch, Größe immer auch eine Rolle
Kriegt man genauso gut mit den klassischen Codecs (MPEG2,ProRes etc.). Wie schon geschrieben, bei höheren Bitraten sind die Vergleiche eh nutzlos.iasi hat geschrieben:Wenn es eben auch auf möglichst geringe Prozessoranforderungen bei hoher Bildqualität und nur mäßige Komprimierung geht, scheint Wavelet eben noch immer eine gute Wahl.