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).
-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?
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.
Das bedeutet, dass geringe Rechenleistungen, aber auch geringere Biödauflösungen (SD TV an einem UHD Stream) auf niedrigere und leichter zu decodierende Layer zugreifen können.
Für die Broadcaster bedeutet dies, lediglich noch einen einzigen Stream für alle TV Formate anbieten zu müssen und für den Anwender, dass Content immer, entlang der eigenen Hardwareleistung, flüssig läuft.
Damit dürften sich dann auch Formate wie DASH erledigt haben, bei dem immernoch unterschiedliche, eigenständige Encodierformate vorgehalten werden müssen.
Die Vorteile liegen also nicht nur in der Codiereffizienz sondern auch in der Übertragungs-und Performanzeffizienz.
grundsätzlich ist scalable video coding auch mit h.264 Annex G möglich.
genutzt wird das aber in der praxis kaum, während DASH schon heute dafür sorgt, dass youtube und netflix ganz erträglich funktionieren.
ich hab momentan mit diesen geschichten wieder ziemlich viel zu tun, um praktische lösungen für einen kleinen kommunalfernsehsender zu schaffen. ist alles fürchterlich kompliziert und schwer zu durchschauen, trotzdem muss man sich einfach an dem orientieren, was bereits wirklich funktioniert und schon einige verbreitung hat.
Dann hätten wir noch schwarz weiß Fernsehen.
Zum Glück gibt es für solche Weiterentwicklungen ja Fachleute, die "unter dem Dach" von MPEG eben solche Standards entwickeln.
Außerdem sind DASH&Co rückwärts adaptive Streamingprotokolle, die für vorwärts ausgestrahlte Medien gar keine Eignung haben.
Kommt hinzu, dass Firmen, wie Netfix eigentlich an DASH nur im Zusammenhang mit MPEG-CENC Interesse haben, um ihren Content auch entsprechend zu schützen.
Das sind aber alle zwei verschiedene Paar Schuhe.
WoWu hat geschrieben:Außerdem sind DASH&Co rückwärts adaptive Streamingprotokolle, die für vorwärts ausgestrahlte Medien gar keine Eignung haben.
DASH und HSL kann natürlich auch für (mehrfach parallel en-/recodierte) live streams genutzt werden!
das ist gängige praxis!
edit: dort wo die bandbreite keine, oder nur eine untergordnete rolle spielt, können die verschieden aufgelösten DASH fragmente sogar in einem einzigen mpeg transport stream zusammengefasst übertragen werden bzw. erst empfangsseitig beim demuxen ausschließlich die kleineren packerl für entsprechend schwachbrüstige endgeräte herausgefischt werden. das ist aber ein speziallfall, der mir nicht so bedeutsam erscheint. normalerweise versucht man ja doch eher die übertragungsbandbreiten vernünftig zu nutzen.
Zuletzt geändert von mash_gh4 am Fr 15 Jan, 2016 14:16, insgesamt 1-mal geändert.
Und welche Infrastruktir hältst Du dann bei einer Satellitenünertragung vor ?
Belegst Du dann einen Volltransponder mit den unterschiedlichen, redundanten Contentelementen ?
DASH & Co und Skalierbare Codecs sind völlig verschiedene Dinge.
Und dass Du bei DASH mehrere Contentversionen in unterschiedlichen Bandbreiten vorhältst, hat nichts mit Skaliernarkeit zu tun und wenn Du im Live Streaming mehrere Paralellencodings bereit hältst, auch nicht.
WoWu hat geschrieben:Und welche Infrastruktir hältst Du dann bei einer Satellitenünertragung vor ?
das habe ich gerade oben ergänzt, bevor mich deine nachreicht erreicht hat.
und nocheinmal eine ergänzung:
was die tatsächliche effizienz betrifft, sind all diese verfahren nicht ganz optimal. trotzdem sind die SVC ansätze vorwiegend akademischer natur und auch bei IP-TV kommt man in der praxis kaum daran vorbei verschieden protokolle parallel zu unterstützen. dass es natürlich ausnahmen bzw. geschlossene anwendungsbereiche geben mag, die von diesem allegemeinen stand der dinge ein wenig abweichen, kann gut sein.
WoWu hat geschrieben:Und welche Infrastruktir hältst Du dann bei einer Satellitenünertragung vor ?
das habe ich gerade oben ergänzt, bevor mich deine nachreicht erreicht hat.
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 ?
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 ?
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.
generell ist es vermutlich am zielführtendsten, wenn man DASH und HSL einfach ihrer grundsätzlichen funktionsweise nach so versteht, dass sie in erster line die entsprechenden metainformationen bereitstellen, wo content von entsprechender bandbreite gefunden werden kann. dass das entsprechende adaptive zugreifen darauf mittlerweile wirklich gut und breit unterstützt funktioniert, ist ohnehin schon von beträchtlichem wert.
Frank Glencairn hat geschrieben:Was mich viel mehr interresieren würde, um wieviel besser ist die Qualität bei gleicher Datenrate?
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?
Bei den Tests, die ich bisher gemacht habe, hat es mich nicht gerade von den Socken gehauen.
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.
Damals hat man tatsächlich die Tool, die in der Reduktion genutzt werden, noch weiter entwickelt und dadurch bei identischen Filegrössen, bessere Qualitäten erzeugt.
Das trifft so auf HEVC nicht weiter zu, weil man in der Tat wirklich nur noch an technischen Parametern gedreht hat, die die Robustheit und auch die Echtzeitperformanz des Codecs verändert haben. Auch Änderungen im Bereich der DCT führen zwar zu genaueren, Transformationen, aber auch zu größeren Hardwareanforderungen, was sich aber nicht wirklich in besseren Bildern auswirkt- leider an manchen Stellen sogar zulasten der Qualität.
Man kann also nicht, wie bei MPEG2 vs. H.264 sagen, dass die Encodierqualität besser geworden ist sondern wirklich nur noch die Effizienz nicht aber die Qualität.
Nur die Effekte, die auftreten sind z.Tl. andere, weil einige Tools aus H.264
nicht mehr verfügbar sind.
Von H.264 wurde eigentlich immer gesagt, es sei ein Distributionscodec, aber dann könnte man das auch von MPEG2 sagen, aber bei HEVC liegt zumindest der Schwerpunkt der Änderungen darauf.
Wer also eine sichtbar bessere Bildqualität erwartet, wird enttäuscht sein.
Die Vorteile von HEVC liegen woanders.
Frank Glencairn hat geschrieben:Ja, den Eindruck hatte ich auch. Ich hatte in H265 immer noch Artefakte, aber halt andere als in H264.
Von dem wie ich es getestet hatte waren Artefakte da, aber anders; würde sogar sagen: besser.
Es war weniger blocky, und mehr "dynamisch". Kokolores zum Arbeiten halt trotzdem :)
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.
