von Youtube wird bei 1080p Material eine Video-Bitrate von 8 Mbit/s (bei 24-30 Bildern pro Sekunde) empfohlen.
Sieht man auf einer Kinoleinwand einen Unterschied zwischen 8 und mehr (bis zu 20) Mbit/s, bei einer Framerate von 25 Bildern pro Sekunde und 1080p Material?
Morphy hat geschrieben:Und zur Frage oben? Den Unterschied zwischen 8 und 20 Mbit erkennt man auf einer Kinoleinwand als Normalzuschauer?
Jain.
Ich gehe mal von temporal komprimierenden Verfahren wie z.B. H.264 aus:
Ob es zu Artefakten kommt, die an sich als solche deutlich sichtbar sind, hängt von vielen Faktoren ab. Insbesondere wie viel sich vor der Kamera bewegt, wie viel sich die Kamera selbst bewegt und ob sich das Meterial ohnehin gut oder schlecht komprimieren lässt (stark rauschendes Material ist immer schwierig).
Allerdings: Häufig nimmt man (d.h. der an technischen Feinheiten uninteressierte Zuschauer) auch leicht sichbare Blockbildung oder durch eine Datenreduktion entstandene Detailverluste in schnellen kurzen Abschnitten meist nicht als störend war, es darf nur nicht zu extrem sein. Wie viel dabei unbemerkt bleiben kann, hängt auch vom Wiedergabegerät bzw. dessen Display ab (Kino, TV, Smartphone, ...).
Bei stehender Kamera und wenig Bewegung können die Codecs mit temporaler Kompression sehr viele Daten zusammenfassen, wodurch viele Details erhalten werden können.
Auch was wie aufgenommen wurde, spielt eine Rolle: Wenig strukturierte Motive vor einfarbigem oder unscharfem Hintergrund lassen sich besser komprimieren als umgekehrt, da sie bereits von vornherein weniger Details enthalten.
Aber auch wenn durch eine stark verlustbehaftete Kompression Details schon verschwinden, merken es viele Zuschauer nicht oder können es allenfalls nur erahnen, denn sie kennen das Original mit all seinen Details gar nicht.
Bei allen Bemühungen eine tolle Qualität abzuliefern, darf man auch nicht vergessen, dass sich normale Zuschauer nicht die einzelnen Frames langsam nacheinander in Vergrößerung ansehen, sondern mit mindestens 24fps - und da hat man bei viel Action und schnellen Schnitten eh nicht viel bzw. genug Zeit, um alle (vorhandenen) Details bewusst zu erfassen und um über durch die Kompression entstandene Fehler nachzudenken.
Solange alles scharf und fein strukturiert aussieht, wird es subjektiv nicht unbedingt als störend wahrgenommen, wenn z.B. viele weitere Details bei der Kompression verloren gingen, da, wie schon erwähnt, der Vergleich mit dem Original feht. Deswegen kann z.B. HD mit für HD knapper Datenrate subjektiv besser wirken, als SD mit für SD hoher Datenrate.
Es ist also alles auch eine subjektive Frage.
Nun zur Frage, wie es auf einer großen Kinoleinwand wirkt: Da das Blickfeld viel stärker ausgefüllt wird, als z.B. beim Bllick auf ein Smartphone, und man durch die ansonsten abgedunkelte Umgebung stärker auf die Leinwand konzentriert ist, bemerkt man vermutlich Blockartefakte eher als am TV (ich habe es bisher nicht ausprobiert), ähnlich so wie man Artefakte bei einer Wiedergabe auf dem TV eher bemerkt, als auf beim Abspielen auf dem Spartphone.
srone hat geschrieben:für eine vernünftige (full-hd) projektion minimum 50mbit.
lg
srone
dann flögen die C100/D810 etc. grundsätzlich heraus?
was meinst du? ich rede vom ausspielen, post farbkorrektur/grading etc.
lg
srone
moin,
ich war nur etwas überrascht - dachte eigentlich, das Nadelöhr entstünde bereits bei der Aufnahme selbst und bin deswegen auch nicht wesentlich höher beim endgültigen Rendern hinausgegangen.
Natürlich lass' ich mich gern überzeugen,
Gruß
srone hat geschrieben:für eine vernünftige (full-hd) projektion minimum 50mbit.
lg
srone
dann flögen die C100/D810 etc. grundsätzlich heraus?
Keine Ahnung wer Canon diesen AVCHD Mist bei nem Prosumer Modell aus den Händen gerissen hat, aber bei ner C100 würd ich auf jeden Fall nen ProRes Rekorder dranhängen und gut ist.
Natürlich! Ohne ProRes geht mal gar nichts mehr! Schliesslich sind die Daten riesig! Und von Apple! Und das muss ja besser sein! ... Nein, natürlich nicht. Bei der C100 ist die externe Aufnahme in ProRes quasi sinnlos. Der interne AVCHD Codec der C100 ist fantastisch, der der Mark II ist sogar noch besser. Da kann man sich das Recorder Gebammsel getrost sparen. Ich musste die selbe Erfahrung machen. Mein Blackmagic Video Assist fristet nun sein Dasein allein als Monitor.
es gibt schon einige messverfahren, um die bildqualität teschnisch zu vergleichen bzw. anhaltspunkte für vernünftige einstellungen zu gewinnen.
ich kann in diesem zusammenhang nur nocheinmal an das entsprechende feature im shotcut erinnern, das eine sehr einfache visuelle gegenüberstellung und entsprechende messerwerte als anhaltspunkt liefert:
Starshine Pictures hat geschrieben:Natürlich! Ohne ProRes geht mal gar nichts mehr! Schliesslich sind die Daten riesig! Und von Apple! Und das muss ja besser sein!
Deine Prosumer Polemik kannste dir eigentlich direkt sparen. Timecode bei der C100 gibbet halt nur über HDMI und damit mit ext. Rekordern und die Dateibennenung von AVCHD Medien ist für gescheite Workflows jenseits deiner Hochzeitsfilmereien ggf. auch nicht verkehrt. Tellerrand undso ;)
Starshine Pictures hat geschrieben:Natürlich! Ohne ProRes geht mal gar nichts mehr! Schliesslich sind die Daten riesig! Und von Apple! Und das muss ja besser sein! ... Nein, natürlich nicht. Bei der C100 ist die externe Aufnahme in ProRes quasi sinnlos. Der interne AVCHD Codec der C100 ist fantastisch, der der Mark II ist sogar noch besser. Da kann man sich das Recorder Gebammsel getrost sparen. Ich musste die selbe Erfahrung machen. Mein Blackmagic Video Assist fristet nun sein Dasein allein als Monitor.
Grüsse, Stephan von Starshine Pictures
Vielleicht sollte man zusätzlich noch erwähnen, dass es sich bei HQ um einen 10Bit Codec handelt, der bessere DCT Einstellungen nutzen kann. Bei PR 422 die Sache aber noch ganz anders aussieht.
Und da die C100 nur 8 bit 4:2:2 via HDMI ausgibt kann man leider nicht von einem (nützlichen) Gewinn an Bildqualität ausgehen. Ich hätte es mir auch anders gewünscht und wollte noch mehr Qualität mit dem externen Recorder erreichen. Aber ausser Festplattenplatz zu verplempern bringts leider gar nix. Auf schwächeren Rechnern könnte die niedrigere Kompression vielleicht zu einer Beschleunigung der Timeline führen und man spart sich das Umkodieren von AVCHD zu ProRes als Intermediate codec und den damit verbundenen (zugegeben) geringen ersten Qualitätsverlust. Aber da mein Computer keine Probleme mit dem internen Material hat sehe ich keinerlei Bild-Vorteile darin mit der C100 extern in ProRes aufzunehmen.
Zum Thema:
Man kann schon davon ausgehen dass eine höhere Bitrate mit höherer Qualität einhergeht. Allerdings codiert jede Software unterschiedlich effektiv. Eine 5DmkIII zum Beispiel schreibt mit 91Mbit auf die Karte, die C100mkII hingegen mit nur 28Mbit, und sieht dabei trotzdem deutlich besser aus und hat massiv mehr Reserven in der Post. Woran das liegt kann dir sicher WoWu erklären. Ich weiss es leider nicht. Deshalb mein Tipp: Probier es selber aus ab wann du keinen signifikanten Unterschied mehr erkennen kannst.
@Stephan
Ich wollte eigentlich auch nur Dein Beispiel ergänzen, in dem Du ProRes HQ (220 Mbit/s) mit AVCHD 24 Mbit/sec verglichen hast, wobei HQ ausserdem ein 10 Bit Codec ist und daher besser in der DCT verformt.
Vergleicht man dieselben 24 Mbit/s / 8Bit hingegen mit einem 8Bit 122 Mbit/s ProRes 420, wo man ja eigentlich davon ausgehen würde, dass er auch deutlich besser performen würde, erlebt man diese Überraschung:
Hei Jesses das sieht ja erbärmlich aus ... Danke WoWu nochmal fürs nachhaken. Ich hab manchmal den Eindruck bei dem Wort ProRes setzt bei Filmern der Verstand aus. "Hechelhechelhechel ..."
Ich kenne mich mit ProRes nicht aus, aber bei DNxHD wird immer die 185er Variante (und nicht die 120er) verlangt. Scheint bei ProRes ähnlich zu sein ;)
Nur dürfte das die Frage des TS beantworten, dass man an der Bitrate quasi nichts in Richtung Bildqualität ablesen kann.
Und wenn ich schon 220 MBit/s und zusätzlich 10 Bit brauche um keine nennenswerten Unterschiede zu rd. 30 MBit/s mehr zu sehen, dann spricht das Bände und spätestens an der Stelle würde ich mich mal fragen, ob ich nicht doch lieber einen neuen Rechner besorge, um GOPs verarbeiten zu können.
Nun sind GOPs auch nicht ganz fehlerfrei, wie man zugeben muss, aber eine Kaskadierung zweier unterschiedlicher Codierfehlerquellen ist nun das Dämlichste, was man überhaupt tun kann.... und das ohne Not.
Das betrifft übrigens auch die höheren Datenraten und ist nicht nur auf 120 MBit/s begrenzt.
WoWu hat geschrieben:Nun sind GOPs auch nicht ganz fehlerfrei, wie man zugeben muss, aber...
Du schreibst ja immer wieder von fehlerhaften (oder unvollständigen) Implementierungen des Codecs (h264) in den verschiedenen Encodern.
Dürfen wir denn davon ausgehen, dass es von Seiten der unterschiedlichen NLEs nicht auch Probleme mit der Dekodierung der Streams auftreten? Oder ist da alles paletti?
(Manchmal klingst du bissel nach einem alten h264-Guru)
Edit:
srone hat geschrieben:nun ja, wie schon oben erwähnt, ist h-264 mit min 50 mbit, für grossbildprojektion, nicht die schlechteste wahl. ;-))
(ausgehend von einer fragestellung, ob nun 8 oder 20 mbit zielführend seien, wohlgemerkt alles in h-264)
Man kann sich auch einfach an BluRay orientieren, wird auch im Kino abgespielt. Aber klar, wenn man unbedingt was draufpacken will... ;)
Ich schau mir nur die Codecs genau an. Das kann man nun bezeichnen wie man will aber Codecs sind eine relativ transparente Angelegenheit, wenn man sie einmal verstanden hat.
Nun mach ich dass Geschäft aber auch schon ein paar Jahre und bin mit den Fehlern und Macken der Codecs groß geworden.
Vielleicht ist es deswegen relativ einfach, die Vor- und Nachteile zu erkennen.
Ich persönlich bin im Augenblick noch kein wirklicher Freund von HEVC, weil ich die Zeit der Distribution schon vor 17 Jahren verlassen habe und ins Lager der Produktion gewechselt bin.
Das hindert mich aber nicht daran, nach wie vor auch die Vorzüge des Codecs zu erkennen.
Sagen wir es einfach so ... ich nenne die Codecs einfach beim richtigen Namen und setze sie dort ein, wo sie hingehören.
Das kann man nicht von jedem hier im Forum behaupten, aber auch nicht verlangen.
Was Deine Frage angeht, so muss man differenzieren zwischen dem Codec ... um den es hier geht ... und teilweise unterirdisch schlechten Implementierungen.
Nur wird das allzu oft leider nicht unterschieden und alles unter "Codec" abgelegt, was eigentlich in den Programmierbuden verzapft worden ist.
Das ist der eigentlich größte Anwendungsfehler.
Und was den H.264 betrifft .... ich kenn ihn nur gut, weil wir seit 2004 damit arbeiten und ziemlich vertraut damit bin, egal in welcher Couleur und wenn ich eines Tages den H.265 besser finde, wird das auch seine guten Gründe haben. Aber soweit bin ich noch nicht.
grundsätzlich geht die empfehlung immer mehr dahin, beim komprimieren keine konstanten bitraten-begrenzungen einzustellen, sondern vielmehr qualitäts-ansprüche (crf etc.)
in dem fall kann das kompressionsprogramm selbst qualitätsmesswerte einfließen lassen, um das resultat zu optimieren. ähnlich wie bei den two-pass ansätzen, die man nutzt, um eine vorgegebene bandbreite möglichst zweckmäßig bis an die grenzen auszuschöpfen, geschieht das auch hier in dynamischer weise und nicht einfach für den gesamten film in gleichem maße. abschnitte mit höherem bewegeungsanteil, rauschen etc. werden dabei anders behandelt als einfach zu komprimierende ruhige einstellungen.
ein derartiges vorgehen wird zwar leider von vielen gängigen programmen noch nicht direkt angeboten, aber man kann ja auch dort eine version mit üppigen bandbreiten rausrendern, und dann in einem weiteren schritt für die endgültige verbreitung nocheinmal spezialisiertere werkzeuge nutzen, um es auf das gewünschte zielformat hin runterzurechnen und zu optimieren.
zur frage des zusammenhangs zw. bandbreitevorgaben und content gab es im dezember einen interessanten bericht von netflix:
Dabei muss man immer die Zielsetzung im Auge behalten, denn auch der Netfix Artikel weist deutlich dabei hin, dass das Ziel eine möglichst gute Bildqualität bei geringsten Datenraten ist.
Primäres Ziel ist also die geringe Datenrate und nicht die beste Bildqualität.
Darüber hinaus kann man natürlich dynamische Analysen benutzen, um Qualitätsoptimierungen vorzunehmen. Tools zur Bildoptimierung sind auch im optionalen Teil des H.264 vorgesehen.
Das hat aber zur Folge, dass sie nicht in der Referenzimplementoerung enthalten sind. Benutzt es also ein Hersteller bei der Implementierung in seinem Encoder, läuft er Gefahr, dass es Player, die dem Stamdard entsprechen, nicht verarbeiten können (und es auch nicht müssen).
Bestes Beispiel ist SONY mit seinem XAVC. Solche Tools müssen vor einer Verarbeitung in einem Stamdardplayern abgestreift werden, bevor man sie in einem der üblichen NLES verarbeiten kann, es sei denn, das NLE unterstützt solche zusätzlichen Tools.
Solche Zusätze machen also, wenn sie auch gut gemeint sind, das Signal inkompatibel, was u.U. zu Reencodierungen führt, was mindestens ebenso schlecht ist.
Und damit wären wir dann beim Thema der Codec Kaskadierung.
Wenn ich mir aus untschiedlichen Codecs, die unterschiedlichen Fehler addiere (Beispielsweise aus der örtlichen + der zeitlichen Prädiktion), dann ist das der vermeidbarste Fehler weil mein Zielergebnis schlechter ist, als jedes Einzelergebnis.
Mal ganz abgesehen davon, dass die Reihenfolge dann auch noch eine wichtige Rolle spielt, denn ein zeitliches, auf ein räumliches Encoding hat aufgrund der erzeugten Unschärfen des räumlichen Encodings drastisch schlechtere Ergebnisse, als es bei einem Encoding aus einem Originalbild hätte. Das Bild wird also nicht so schlecht, weil der Codec oder die Implementoerung so schlecht ist, sondern weil eine Kaskadierung stattgefunden hat.
Soetwas ist also kein Codingproblem, sondern ein Bedienfehler.
... ist super - danke! Der beste Vergleichstest dieser Art, den ich bisher gesehen habe.
Das Fazit des Testers:
Bild mit AVCHD 1080/25p 24 Mbps besser als mit ProRes 122 (ausser bei Bewegung, siehe auch WoWu's Bild-Vergleich) und in vielen Fällen zu etwa 98% pari mit ProRes HQ 184.
Generelle Ausnahme: Bei Bewegung ist ProRes im Vorteil.
Dafür generiert AVCHD rauschärmere Bilder, bei denen allerdings Details verloren gehen können (eigene Bemerkung: was solchen Bildern ein etwas glattes Aussehen verleihen kann).
Der Tester will ProRes HQ künftig für seine Serien-Produktionen verwenden, aber für viele Jobs reicht ihm auch das interne AVCHD.
Zur Codierung:
interframe (GOP = group of pictures, auch IPB genannt, TheBubble nennt es oben 'temporal komprimierendes Verfahren', z.B. AVCHD) versus intraframe (jedes einzelne Bild codiert, z.B. ProRes oder 'All-i' (z.B. Panasonic GH4))
Generell:
Man kann Bitraten also nicht einfach spontan vergleichen und auf die Bildqualität schliessen mit 'höher = besser'.
Zuerst klären:
a) Welcher Codec?
b) 8 bit oder 10 bit Codec ?
c) Einzelbild-Codierung (z.B. ProRes, aber auch 'All-i' H.264) oder GOP-Codierung (MPEG-basiert, z.B. H.264 als AVCHD) ?
Einzelbildcodierung benötigt für vergleichbare Qualität (bei gleichem Codec) mindesten die 3-fache Bitrate (aus dem Gedächtnis - stimmt das etwa?) , eher mehr.
Zuletzt geändert von Skeptiker am So 17 Jan, 2016 20:51, insgesamt 3-mal geändert.
WoWu hat geschrieben:Darüber hinaus kann man natürlich dynamische Analysen benutzen, um Qualitätsoptimierungen vorzunehmen. Tools zur Bildoptimierung sind auch im optionalen Teil des H.264 vorgesehen.
Das hat aber zur Folge, dass sie nicht in der Referenzimplementoerung enthalten sind.
nein -- das kann man so nicht stehen lassen.
natürlich gibt es features, auf die das zutrifft (bspw. den verlustfreien kompressioansmodus der libx264). früher war das ja noch viel schlimmer, weil man sich an den limitierungen irgendwelcher weit verbeiteten älteren iphones orientieren musste, die nur sehr wenig bzw. unbefriedigende teile des standards unterstützt haben. derartige exotische erweiterungen würde ich auch tunlichst vermeiden, wenn das material möglichst kompatibel bleiben soll bzw. von jedem abgespielt werden können sollte.
aber auf jene optimierungen, die ich hier angesprochen habe, trifft das nicht zu. die stützen sich nur auf verbreitete basisfunktionen, die fast jeder gebräuchliche decoder zu verarbeiten vermag, nur nutzen sie eine ganze menge an techniken, um diese elementaren features auch wirklich optimal auszunutzen. es werden also laufend einstellungen variiert, die weit über das hinausgehen, was man mit einer simplen konstanten bandbreitenvorgabe erwirkt.
wenn du dir die vortäge und präsentationen der betreffenden entwickler auf den entsprechenden konferenzen anhörst -- ich bekomm natürlich eher nur mit, was sich dazu in der freien szene so tut (bspw.: https://www.videolan.org/videolan/events/vdd15/ ) -- dann geht's dort zum größten teil um optimierungsmöglichkeiten, die durchaus mit dem standard und gebräuchlichen feature sets und einschränkungen verträglich sind, aber trotzdem noch ein bisserl zusätzlicher qualität herauskitzeln. das ist es auch, was die tatsächliche qualität der libx264 ausmacht bzw. deutlich von andere implementierungen absetzt.
WoWu hat geschrieben:was u.U. zu Reencodierungen führt, was mindestens ebenso schlecht ist.
Und damit wären wir dann beim Thema der Codec Kaskadierung.
natürlich versuche ich das rekomprimieren auch nach möglichkeit zu vermeiden.
aber was bleibt einem anderes über, wenn viele hersteller einfach zu vergleichsweise miserablen kompressionslösungen greifen, nur weil sie sich bswp. unter rückgriff auf die bereits installierte quicktime infrastruktur beträchtliche lizenzkosten sparen können. das die resultierende qualität dabei weit hinter dem technisch möglichem zurück bleibt, fällt ja ohnehin kaum jemandem auf. :(
man muss also manchmal abwägen, ob man nicht, trotz den unvermeidlichen verlusten im rahmen der rekomprimierung, ein besseres endergebnis unter zusätzlicher verwendung externer kompressionslösungen erzielen kann, oder sich eben mit jenem mittelmaß begnügt, das premiere oder resolve out of the box liefern.
man sollte im zusammenhang mit kaskadierung vielleicht auch nicht unerwähnt lassen, dass codecs der DCT famile den nicht unbeträchtlichen vorteil besitzen, dass eine erneute kompression mit gleicher technik deutlich weniger zusätzliche artifakte zeigt als die erste generation. die beschreibung, in der das komprimierte material bereits vorliegt, passt einfach besser zu jenen mechanismen, mit denen es dann im rahmen der erneuten kompression wieder umschrieben wird. viel problematischer erscheint es mir in diesem zusammenhang, wenn tlw. zwischen ganz unterschiedlichen kompressionstechniken jongliert wird (bspw. h264 -> cineform -> h264).
Man kann das Ergebnis des Testers aber auch auf einen andern Nenner bringen:
Um die sichtbar gleiche Bildqualität eines 8Bit 4:2:0 / 24MBit/sec AVC Codecs hinzubekommen, bedarf es eines 10 Bit 4:2:2 220Mbit/s (HQ) ProRes Codecs, wenn sie beide als Akquisitionscodecs eingesetzt werden.
Man kann das Ergebnis des Testers aber auch auf einen andern Nenner bringen:
Um die sichtbar gleiche Bildqualität eines 8Bit 4:2:0 / 24MBit/sec AVC Codecs hinzubekommen, bedarf es eines 10 Bit 4:2:2 220Mbit/s (HQ) ProRes Codecs, wenn sie beide als Akquisitionscodecs eingesetzt werden.
Ja.
Mit der genannten Ausnahme: Bewegte Objekte (schnell und unberechenbar) - die bekommt ProRes im obigen Test auf https://youtu.be/E92jDQpou4Q auch bei 122 Mbit/s besser hin.
Und mit 183 Mbit/s für HQ 1080/25p (=220/30*25).
Und im Prinzip würden für den Bildvergleich (Farben) dann wohl auch 8bit ProRes HQ (statt 10bit) genügen (die es nicht gibt). Im speziellen Fall der Canon C100: Die gibt ja extern nur 8bit aus, da bringen also die 10bit von ProRes HQ nichts an zusätzlicher Farbtiefe.
Es ist sicher erstaunlich, was AVCHD zustande bringt, aber man muss auch die Grenzen (bei der Aufnahme) der tiefen Bitrate bzw. der GOP-Komprimierung beachten.
WoWu hat geschrieben:Um die sichtbar gleiche Bildqualität eines 8Bit 4:2:0 / 24MBit/sec AVC Codecs hinzubekommen, bedarf es eines 10 Bit 4:2:2 220Mbit/s (HQ) ProRes Codecs, wenn sie beide als Akquisitionscodecs eingesetzt werden.
Bedeutet: eine Arri Alexa und ein AVCHD-Camcorder für 500 Euro haben die gleiche Aufzeichnungsqualität. Gut zu wissen! :-)
@ Skeptiker
Nicht wirklich, denn erst durch die 10 Bit wird die DCT in einen andern Mode versetzt.
Und was den Noise betrifft, stellt sich wirklich die Frage der Gewichtung, ob eine Unschärfe aus einer örtlichen Prädiktion nicht deutlich sichtbarer ist, als Noise an den Kanten bewegter Objekte.
Aber es stellt sich noch eine zweite Frage .... ist der Akquisitionscodec auch der Zielcodec?
Ich denke mal, nicht, denn wo ist die Plattform, die rd. 200Mbit7s vertreibt ?
Also wird es eine Transcodierung geben, in der man sich zusätzlich zu den örtlichen Fehlern noch all die Fehler einfängt, die zeitlich bedingt sind.
Mit andern Worten ... man verschlechtert sein Bild ohne jede Not.
Da stimme ich mit mash gh4 in seiner Sichtweise völlig überein.
@mash gh4
Im ersten Ansatz nicht so sehr. Es ist zwar so, dass solche Analysentools in zahlreichen Playern unterstützt werden, weil sie auch teil des optionalen Parts des Standards sind, aber eben nur, wie Du selbst schreibst, in einigen Playern.
Das bedeutet, dass der Content auch nur auf einigen Playern fehlerfrei dargestellt wird. Anders als der mandatory Teil des Standards, der auf allen Playern dargestellt werden muss und nur so die Kompatibilität hergestellt wird, der Sinn des Standards ist.
Bestes Beispiel ist eben Sony ....
Klar kann an Implementierungen und der Ausnutzung des Speicherbereiches durch die Implementierung weiter optimiert werden und MPEG hat auch da genügend Luft gelassen, damit die Firmen auch entsprechende Alleinstellungsmerkmal in Richtung Qualität darstellen können, ohne sich aus dem mandatory Teil verabschieden und proprietär werden müssen.
Firmen wie Telestream zeigen das auf beeindruckende Weise.
Ich will damit nur sagen, dass es nicht genügend gute Gründe gibt, auf nicht standardisierte Encodings zurück zu greifen, weil der Standard in seiner Qualität genügend Redundanzen hat ... es sei denn ... und da sind wir wieder in der Distribution, man will mit winzigsten Bitraten arbeiten.
Aber dafür gibt es HEVC, an dessen Verhältnis Rate/Quali H.264 sowieso nicht ran kommt.
Wir reden also über die Produktionsebene, in der H.264 nach oben genügend Luft hat.
Aber das ist eben immer das Debakel ... alle Reden über schlecht Bilder und merken gar nicht, dass sie einfach nur schlechte Profile benutzen.
Die Probleme liegen also mal wieder 30cm vor dem Monitor.
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.
