$LeEP schrieb:
Für alle Smartphones / Tablets: CPU wäre so schon zu assi für einen reinen H.264 Software Decoder, das geht derzeit nur weil die verbauten Grafikchips wie z.B. Tegra3 das direkt hardwarebeschleunigt dekodiert. Von daher wird H.265 nicht flüssig laufen.
H.264 / AVC braucht sicherlich einiges an Rechenleistung, aber beispielsweise reicht ein Athlon II Kern @ 2.3GHz aus um selbst 1080p25 problemlos abzuspielen. Bei Geräten mit ARM Cortex A15 Dual-Core oder besser sollte ein AVC Software-Dekoder eigentlich reichen, auch wenn der Stromverbrauch dafür natürlich deutlich höher liegt als bei dedizierter Hardware. H.265 hat genau wie H.264 asymetrische Leistungsanforderungen für En-/Dekodierung. Die benötigte Rechenleistung sollte bei Dekodieren kaum ansteigen, nur das Enkoden wird deutlich rechenaufwendiger.
e-Laurin schrieb:
Ich frage mich, wie sie das geschafft haben. Einfach mal so die Kompressionsrate verdoppeln geht eigentlich nicht.
Bei den Standbild-Codecs wie JPEG und PNG sieht man das ja auch gut. Die gibt es schon seit x Jahren, ohne dass etwas merklich besseres auf den Markt kam. Bei den Bewegtbild-Codecs ist das eigentlich auch nicht anders.
Es gab viele kleinere Optimierungen. Eine der größeren Veränderungen war die Unterstützung für größere Blöcke, welche hauptsächlich bei sehr hohen Auflösungen deutliche Vorteile bringt. Zusätzlich hat der Enkoder jetzt auch mehr Freiheiten wie er die Blöcke aufteilt, was bei allen Auflösungen hilft.
Gandalf2210 schrieb:
Im Idealfall reicht ein Software update damit h264 Hardware auch h265 abspielen kann.
Das wird höchst wahrscheinlich nicht funktionieren, einfach weil sich der Bitstream geändert hat und die benutzten IP-Blöcke meist nicht update-fähig sind. Selbst für kleine Änderungen bräuchte man zumindest neue Revisionen der Chips. Das ist der Preis, den man für den minimierten Platz- und Stromverbrauch bezahlen muss.
Zehkul schrieb:
Mich würde mal interessieren, wie h265 zu aktuellen h264 10bit Encodes steht. Glaube nicht, dass sich das viel nimmt.
Die Effizienzsteigerung von 8- auf 10-Bit soll bei Anime bei 10-20% liegen, bei echtem Filmmaterial hingegen eher so bei ~5%. Das wird häufig verfälscht, weil Leute x264 im CRF-Modus benutzen und dann beim Umstieg von 8- auf 10-Bit plötzlich viel kleinere Dateien bekommen. Das liegt allerdings hauptsächlich daran, dass der Quantisierungsfaktor bei 8- und 10-Bit Kodierung überhaupt nicht direkt vergleichbar ist und auch nicht vergleichbare Qualität liefert.
CvH schrieb:
Das springen durch die Videos hat so rein nichts mit dem verwendeten Codec zu tun (auch wenn mpeg kein Codec ist).
Der Codec hat sicherlich einen Einfluss darauf und AVC erlaubt deutlich komplexere Referenzierungen zwischen eizelnen Frames als andere Codecs.
FreedomOfSpeech schrieb:
Tragischer Trugschluss. Das Datenaufkommen wird nicht reduziert, sondern verdoppelt (wenn man zu ende liest).
4k Auflösung bedeuetet 4-dache Datenmenge, wenn der .265 Codec doppelt so effizient codiert wie .264 sind es die Hälfte von 4x, also doppelt.
Prinzipiell richtig, was du da sagst, die Rohdatenmenge wächst entsprechend der Pixelzahl und in der Theorie wäre das auch für komprimierte Formate wie MPEG4 ASP/AVC oder jetzt HEVC zu erwarten. Allerdings hat man auch beim Umstieg von 576p auf 1080p gesehen, dass die Datenrate sich bei gleichen Settings nicht verfünffacht hat, einfach weil nicht immer alle Bildteile wirklich entsprechend mehr Details bieten als vorher. HEVC wird vermutlich die doppelte Auflösung nicht vollständig kompensieren können, aber ich denke, dass man je nach Material nah daran kommen kann.
Ein ähnliches Phänomen sieht man ja auch bei verschiedenen Framerates. Nimmt man ein Video mit 50fps her (z.B. neuere Eigenproduktion von ARD, ZDF und Co) und erzeugt daraus ein 25fps Video (man nimmt einfach nur jedes 2. Frame), so hat man unkomprimiert den benötigten Speicherplatz halbiert. Beide mit gleichen Settings mit x264 komprimiert unterscheiden sich in der Dateigröße meist nur um 10-15%.
