momentan gibt's in consumer-reichweite noch kaum lösungen, die sich auf entsprechende hardware-bescheunigung stützt. dass wird sich aber relativ bald ändern. aber auch dann wird man sich vermutlich noch länger über software ärgern müssen, die einfach nur die billigste lösung (bspw. quicktime) intern nutzen. das sieht man ja auch gegenwärtig, wenn man sich ansieht, wie schlecht der h.264 support in vielen anwendungen funktioniert (bspw. im resolve) und was eigentlich auf gleichwertiger hardware möglich wäre (stichwort: open broadcast encoder).merlinmage hat geschrieben:Ernsthafte Frage?
Genau das ist ein weiterer Grund, der für HEVC spricht denn die Skalierbarkeit kommt sowohl bei geringeren Rechnerleistungen, als auch bei unterschiedlichen Bildformaten zur Anwendung.-paleface- hat geschrieben:Klingt doch gut.
Wie hoch sind den die Rechenanforderungen?
Mus ich von einer starken höhren Leistung beim De- und Encoden ausgehen?
DASH und HSL kann natürlich auch für (mehrfach parallel en-/recodierte) live streams genutzt werden!WoWu hat geschrieben:Außerdem sind DASH&Co rückwärts adaptive Streamingprotokolle, die für vorwärts ausgestrahlte Medien gar keine Eignung haben.
das habe ich gerade oben ergänzt, bevor mich deine nachreicht erreicht hat.WoWu hat geschrieben:Und welche Infrastruktir hältst Du dann bei einer Satellitenünertragung vor ?
Ja, stimmt. Man kann natürlich denselben Content n-mal im Transportstream übertragen, nur um unterschiedliche Endgeräte zu bedienen. Und das dann auch noch mehrfach für verschiedene Bildformate.mash_gh4 hat geschrieben:das habe ich gerade oben ergänzt, bevor mich deine nachreicht erreicht hat.WoWu hat geschrieben:Und welche Infrastruktir hältst Du dann bei einer Satellitenünertragung vor ?
darum ist es ja auch in diesem fall viel vernünftiger, nur die tatsächlich benötigte bandbreite einmal zu übertragen und empfangsseitig genügend rechenpower für ihre verarbeitung vorzusehen. auch dafür ist also SVC nicht wirklich nötig. schließlich würde es auch das noch immer einen gewissen overheap bedingen, auch wenn der natürlich deutlich kleiner ausfallen kann als in den beschriebenen DASH szenarien.WoWu hat geschrieben:Ja, stimmt. Man kann natürlich denselben Content n-mal im Transportstream übertragen, nur um unterschiedliche Endgeräte zu bedienen. Und das dann auch noch mehrfach für verschiedene Bildformate.
Damit wird man dann für ein und dasselbe Programm auch einen Volltransponder brauchen ....
Wahrscheinlich ist das dann auch einer der wesentlichen Gründe dafür, warum man HEVC skalierbar macht.
Hast Du eigentlich eine Idee davon, was 1Mbit/s Bamdbreitennutzung auf einem (z.B. ASTRA Sat) kostet ?
speziell bei sehr kleinen datenraten ist h.265 wirklich sehr gut. wenn man dagegen mit verhältnismäßig großen bandbreiten bzw. qualitätsansprüchen operiert, ist der unterschied nicht mehr ganz so aufregend.Frank Glencairn hat geschrieben:Was mich viel mehr interresieren würde, um wieviel besser ist die Qualität bei gleicher Datenrate?
Geh mal nicht davon aus, dass das der Denkansatz, den man von MPEG 2 nach MPEG 4 hatte, auch von H.264 nach HEVC gilt.Frank Glencairn hat geschrieben:Was mich viel mehr interresieren würde, um wieviel besser ist die Qualität bei gleicher Datenrate?
Bei den Tests, die ich bisher gemacht habe, hat es mich nicht gerade von den Socken gehauen.
Von dem wie ich es getestet hatte waren Artefakte da, aber anders; würde sogar sagen: besser.Frank Glencairn hat geschrieben:Ja, den Eindruck hatte ich auch. Ich hatte in H265 immer noch Artefakte, aber halt andere als in H264.
also, wenn du bei "-qp 0" od. "-crf 0" noch immer artifakte im h264 output siehst, bist wirklich gut! :)Frank Glencairn hat geschrieben:Ja, den Eindruck hatte ich auch. Ich hatte in H265 immer noch Artefakte, aber halt andere als in H264.