Hallo an alle Video-Experten hier,

ich stehe vor einem für mich rätselhaften Performance-Problem bei der Video-Wiedergabe auf OS X (Mavericks wie auch frühere OS-X-Versionen, sowohl mit QuickTime Player 7 als auch QuickTime Player X – also de facto dem neuen AVKit) bei h.264-Videos.

Ich habe etliche h.264-Full-HD-Videos (1920 x 1080, 24 fps) in mp4- oder mov-Containern auf meiner Platte. Einen Teil dieser Videos geben die QuickTime-Player problemlos auch auf einem kleinen Mac mini wieder, einen anderen Teil schaffen sie aber selbst auf einem 3,33-GHz-6-core-Mac Pro (2012) mit 48 GB RAM nur mit so starkem Ruckeln, dass die Videos de facto vollkommen unbenutzbar sind (manchmal sind die Bilder für eine ganze Sekunde und mehr eingefroren).

Mein Problem ist, dass ich beim besten Willen keinen Unterschied erkennen kann zwischen den Videos, die laufen, und denen, die es nicht tun. Wenn ich mir die Video-Parameter der unterschiedlichen Videos im QuickTime Player 7 ansehe (wo sie detaillierter aufgelistet werden), entdecke ich keine relevanten Unterschiede.

Die Bitrate ist zwar von Video zu Video unterschiedlich, es ist aber mitnichten so, dass die Videos, die ruckeln, immer die höhere Bitrate haben – oft ist es genau umgekehrt. Ansonsten sehe ich zwischen den Videos überhaupt keine Unterschiede.

Ich habe auf der Perian-Website gelesen, dass Macs für manche h.264-Level (keine Ahnung, wie ich erkennen kann, welchen Level ein Video hat) Hardware-unterstützte Dekodierung anbieten und für andere nicht. Das ist aber auch keine wirkliche Erklärung, denn in alternativen Video-Playern wie z.B. mpv laufen alle Videos problemlos, auch die, die in den QuickTime-Playern ruckeln. (Ich erwähne deswegen ausdrücklich mpv, weil mpv wie die QuickTime-Player Farbmanagement implementiert hat, sich also keinen Performance-Vorteil durch direktes Schreiben der RGB-Daten auf den Bildschirm verschaffen kann wie VLC & Co.)

Das einzige, was ich durchgängig feststellen kann: Alle auf OS X selbst erstellten Videos (= mit Compressor, oder in den QuickTime-Playern konvertiert und neu gesichert), und natürlich alle iTunes-Kaufvideos funktionieren. Bei allen anderen Videos, deren genaue Erstellung ich nicht kenne, ist es mal so und mal so; besonders gerne scheinen h.264-Videos zu ruckeln, die von einem mkv-Container in einen mov- oder mp4-Container umgepackt wurden.

Aber das kann doch nicht sein, dass OS X nur auf OS X erstellte h.264-Videos flüssig abspielen kann – ich denke, h.264 ist ein offener Standard

Kann irgendjemand hier Licht in dieses ruckende Dunkel bringen?

da Apple selbst nur für sein gekapseltes System programmiert, darf dich nicht wundern, daß nur Standards, die Apple offiziell unterstützt, vernünftig funktionieren. Alles andere ist außerhalb des Apple Kosmos und wird damit nicht vernünftig implementiert.
Das muss so sein (aus Apples Sicht

Deshalb benutze ich den Quicktime Player schon seit Jahren nicht mehr.

Wenn man Böses unterstellen möchte, dann kann man das ruhig Arroganz nennen.

Ja, aber mein Problem ist doch gerade, dass selbst der Video-Standard, den Apple offiziell unterstützt – h.264 – manchmal funktioniert und manchmal nicht, ohne dass ich irgendeinen Unterschied im Video-Format der funktionierenden und der nicht funktionierenden Video-Dateien feststellen könnte.

Was ich herausfinden will, ist, was die Videos, die funktionieren, von denen unterscheidet, die das nicht tun.

Ohne Angaben des Sachverhalts (Welches Video mit welchen Parametern ruckelt auf welchem Player) ist das eine Raterei.

Der Hauptfehler dürfte 24fps sein, das nicht vernünftig dargestellt werden kann. Dann ist die Bitrate Wurscht, es zählt dann nur noch, wie der Rechner die 24 auf 25fps umrechnen kann (onthefly).

24fps braucht man (wenn überhaupt), nur für Kinoprojekte. Der vielgepriesene "Filmlook" lässt sich mit anderen Mittel besser erreichen. Beispielsweise mit der Aussage: "Das wurde in Kinotechnik aufgenommen." Das Publikum nickt dann anerkennend und freut sich, dass das Video vom 8-stündigem Strandaufenthalt an der Copacabana (in Echtzeit) "so kinomäßig" aussieht.

Ist auf dem System Perian installiert? Wenn ja ist das die wahrscheinlichste Fehlerquelle.

Ansonsten wäre es natürlich sinnvoll, die Dateien möglichst genau zu vergleichen, auch insbesondere die Audiocodecs (bspw. über VLC - Fenster - Medieninformationen - Codec). Bekannt sind bspw. Probleme von QT mit Videos bei denen der Stream 0 (der Default) AC3 Audio verwendet...

Siehst Du in der Aktivitätsanzeige bzw. der Konsole irgendetwas Auffälliges, wenn eines der Problemvideos läuft?

Genau: Perian ist der vermutliche Übeltäter. Es hängt sich in die Quicktime-Codecs rein und man weiß nie, ob man gerade über den performanten Apple-Codec oder eine weniger performanten Perian-Codec abspielt.
Für mich war das damals auf dem G5 der Grund auf Perian zu verzichten. Quicktime konnte damals nämlich Full-HD auf meinem G5 gerade noch abspielen. Wenn aber Perian installiert war, ruckelte es nur noch.

Der .h264 Standard ist zwar ein Standard, aber mit extrem vielen Optionen. Der Codec selbst unterstützt viele Qualitäts-Level und Codier/Decodier-Optionen, welche die nötige Leistung zum Abspielen stark beeinflussen können.
Das ist einerseits gut, da .h264 dadurch sowohl auf schwachen Handys, als auch auf sehr starken Rechnern oder speziellen Hardware-Chips zum Einsatz kommen kann. Nachteil ist, dass du die »komplizierten« Videos nicht auf schwachen Geräten abspielen kannst.

Beispielsweise kann die interne Komprimierung des Datenstroms in zwei verschiedenen Arten ausgeführt sein: CABAC und CAVLC CABAC erreicht eine deutlich höhere Komprimierung (Verkleinerung), erfordert aber viel mehr Rechenleistung als CAVLC. Daher braucht es einen stärkeren Rechner und darf nur im so genannten Main-Profile und High-Profile eingesetzt werden. Im Low-Profile (mobile Geräte) darf es nicht verwendet werden. Du bekommst dadurch entweder kleinere Dateien oder eine bessere Qualität bei gleicher Dateigröße. Mit dem Nachteil der höheren Rechenleistung.

Daneben gibt es noch eine ganze Stange anderer Optionen, welche die nötige Leistung zum Codieren oder zum Decodieren beeinflussen können. Das Tool iMediaHUD zeigt dir deutlich mehr Details des Videostroms an, als QuickTime dies kann (kostenlos)

Die freien Player wie VLC oder MPlayer unterstützen meist den kompletten Standard oder haben Optimierungen drin, dass sie auf schwachen Rechnern einige Details der Decodierung auslassen, um eine flüssige Wiedergabe zu ermöglichen.

MKVs werden ja üblicherweise aus Blu-rays generiert. Die origiginal Blu-ray Player haben meist kein Problem mit der Decodierung, da sie einen spzeiellen Chip drin haben, der genau für diese Aufgabe optimiert ist. Die meisten Macs und Handys haben zwar mittlerweile auch so einen Decoder auf der Grafikkarte, aber auch hier hängt es davon ab, ob dieser Hardware-Decoder alle Optionen von .h264 unterstützt.

Mit iMediaHUD solltest du aber ein Muster ausmachen können, welches Detail (die Datenrate ist es üblicherweise nicht) die beiden Video-Arten (ruckelnd/nicht ruckelnd) unterscheidet.

Grundsätzlich gilt:
Wenn es auf Apple-Software nicht läuft, dann wirklich entweder auf nichts von Apple (QuickTime Player 7, QuickTime Player X, QuickLook, Front Row, Final Cut Pro X) oder auf allem von Apple.

Auf mpv oder VLC läuft alles, immer.

Was die Videos betrifft, konnte ich bislang eben keinen korrelierenden Unterschied in den Parametern feststellen. Ich werde mir das aber aufgrund der Hinweise hier heute Abend nochmals genauer ansehen (jetzt bin ich nicht an dem Rechner mit den Videos).
Ich habe 24 fps jetzt nur so dahingesagt als Abgrenzung von 50 fps. Können auch 23,98 oder 25 fps sein, ich wusste nicht, dass Software da überhaupt einen Unterschied macht und dass das kritisch sein könnte.
Ja.
Ooops, da bin ich überhaupt noch nicht draufgekommen; das müsste ich an einem extra aufgesetzten System ausprobieren, da ich auf meinen Produktionssystemen nicht auf Perian verzichten kann.

Aber kann das denn überhaupt sein, wenn auch der QuickTime Player X betroffen ist? Der ignoriert Perian doch?
Konsole nein, Aktivitätsanzeige zeigt ca. 200% Auslastung (bei den Filmen, die funktionieren, eher 100%) – Auslastung ist also höher, aber das reformuliert meine Frage ja quasi nur: warum ist sie höher? (mpv benötigt dann etwa 70% )

Das ist mir klar – unklar ist mir, wie ich evtl. Unterschiede feststellen kann, aber
das klingt sehr interessant – werde ich gleich heute Abend ausprobieren! Danke für den Tipp!

Sooo – ich bin nun Kryptons Link nachgegangen und habe statt iMediaHUD am Ende Invisor installiert – basiert auf derselben Open-Source-Bibliothek, erlaubt aber eine vergleichende tabellarische Darstellung (die Daten aller Videos in Spalten nebeneinander), die für mein Problem natürlich ideal ist.

Damit war dann nach einigem Testen auch die Lösung gefunden:

Der Schuldige ist das mir ohnehin schon verhasste, anachronistische Interlaced (im Format MBAFF – Interlaced-Videos mit PicAFF habe ich keine bei mir gefunden, kann ich also nicht testen).

Bei allen Interlaced/MBAFF-Videos schießt die CPU-Last bei allen Apple-Playern auf weit über 100% bis knapp über 200%, und die Videos ruckeln (was sie bei besserem Multithreading natürlich nicht zwingend müssten, mein Mac Pro hätte ja 1200% im Angebot …).

Progressive hingegen geht stets wunderbar mit den Apple-Playern, 50-70% CPU-Last.

Perian, h.264-Level und -Profileigenschaften abgesehen von Interlaced, Framerates und Datenraten spielen allesamt keine Rolle.

Die Videos waren allesamt neueren Ursprungs; warum hier und heute noch irgendjemand HD-Videos in Interlaced kodiert, ist mir ein komplettes Rätsel, aber es ist offenkundig alles andere als selten.

Und angesichts dessen wiederum verstehe ich nicht, warum Apples Software bei Interlaced-Dekodierung so kläglich versagt – andere Player können das ohne merklich mehr CPU-Last wunderbar handeln.

Wie auch immer, jedenfalls kenne ich jetzt endlich die genaue Ursache des Problems. Euch allen herzlichen Dank für die Hilfe bei der Ursachenforschung!

Ooops, da ist ein Satz missverständlich.

Ich stelle mal die Wörter um:

Perian, Framerates, Datenraten, h.264-Level und -Profileigenschaften (abgesehen von Interlaced) spielen allesamt keine Rolle.

hab Dank für deine Erkenntnisse, das ist in einem Forum nicht immer selbstverständlich. Danke.

Wer produziert 2014 interlaced? Für welche Anwendung?

War 2013. Und das kam in der Tat von BluRay-Discs. Völlig seltsam, oder?

Wobei ich noch ergänzen sollte, dass MBAFF merkwürdigerweise nicht immer mit sichtbaren Interlaced-Artefakten (den berüchtigten „Kämmen”) korreliert – sonst hätte ich ja ganz einfach beim Ansehen der Videos hinter die Ursache des Ruckelns kommen können.

Bei meinen Tests habe ich insgesamt 8 Video-Quellen verwendet, die von BluRays kamen. Davon waren 4 progressiv und liefen problemlos in Apples Playern; 4 waren mit MBAFF kodiert und ruckelten in Apples Playern. Aber von diesen 4 BluRays zeigte nur eine (The Rolling Stones – Sweet Summer Sun (Hyde Park 2013 Live)) auch sichtbare Interlace-Artefakte und konnte dementsprechend nur in Playern wie mpv, die einen zuschaltbaren Interlace-Filter anbieten, genussvoll betrachtet werden. Die anderen 3 BluRays, die MBAFF verwenden, zeigen hingegen keinerlei Interlace-Kämme – weswegen ich da ohne Invisor nie drauf gekommen wäre.

1080i25 ist nun mal ein sehr verbreitetes Sendeformat im TV. Für p50 fehlt es noch an Bandbreite und Standards…
Und, da du z.B. BluRays nicht direkt abspielst, kann sich das Format durchaus beim Wandeln ändern.

Das verstehe ich nicht ganz. Es geht doch, wenn, um p25, und die Standards wären da – h.264 eben?
Unwahrscheinlich, insofern ich stets den exakt selben Prozess (mit MakeMKV) anwende, bei dem ausdrücklich nicht reenkodiert, sondern nur neu verpackt wird.

Außerdem waren die fertigen BluRays nur ein Teil meines Tests. Ich hatte zusätzlich auch noch mehrere mp4-Dateien direkt von den Post-Production-Häusern, also mp4-Dateien, die zwar für die BluRay-Produktion bestimmt waren, aber bevor sie zu einer BluRay gewandelt wurden. Und auch da waren mehrere MBAFF-kodierte Videos drunter. Ich könnte im Prinzip natürlich mal bei den Post-Production-Häusern nachfragen, was sie sich dabei gedacht haben …

Ah! BR geht komplett an mir vorbei!
Danke für die Aufklärung! Jetzt verstehe ich auch, warum die FCPX-Foren voll mit Deinterlace-Strategien sind.

Post-Production-Häuser haben erfahrungsgemäß oft eklatante "Bildungslücken" wenn es um Videokompression geht. Da wird gerne das erste beste Preset genommen und fertig.

Und ja, für's Fernsehen wird wenn in FullHD produziert wird immernoch meist 1080i50/i60 genommen. Allerdings habe ich auch in letzter Zeit öfter Sachen wie zum Beispiel Konzerte gesehen, die wohl in 1080p25/p30 produziert wurden und dann mangels Unterstützung von p25/p30 in TV und Blu-rays einfach als "fake-interlaced" komprimiert wurden. Das Progressive Bild bleibt dabei vollständig erhalten und man bekommt auch keinen Combing.

Zu deinem Ausgangsproblem: Das hört sich stark in einem Fehler in AVKit an, vermutlich im Zusammenhang mit der Hardware-Decodierung. Wenn AVKit interlaced per Hardware unterstützt sollte es problemlos laufen und wenn nicht, sollte es auf Softwaredekodierung zurückgreifen, welche auf deiner Maschine auch problemlos laufen sollte.

mpv kann übrigens auch Hardwaredekodierung benutzten, sofern das beim kompilieren von ffmpeg aktiviert wurde (--enable-vda war das meine ich), macht allerdings bei den heutigen Rechenleistungen aber im allgemeinen eher weniger Sinn, da Softwaredekodierung wesentlich robuster ist.

Ich befürchte, da könnte was dran sein …
Das wäre in der Tat eine Erklärung, danke für die Info! Ich hatte mir das auch schon überlegt, aber ich kenne mich in der Szene wenig aus, und von außen betrachtet wirkt das eher absurd, daher hatte ich den Gedanken wieder verworfen …
Aus „verschwörungstheoretischer“ Sicht eine interessante Frage: Ist das aus Apples Perspektive jetzt ein Bug oder ein Feature, dass AVKit bei der BluRay-Wiedergabe oft Probleme macht?

Ich werde das mal melden, aber ich sehe schon die Antwort vor mir: Engineering has determined that this works as designed. (Nein, könnte schon auch ernst genommen werden von Apple …)

Ich habe mir jetzt nochmal meine Testergebnisse unter diesem Aspekt angesehen. In der Tat gilt für alle „fake-interlaced“-Filme, dass sie p25 oder p30 sind und entweder für BluRay gedacht sind oder von BluRay stammen, während alle progressiv-Filme entweder 24p sind oder aber 25p und nicht für/von BluRay.

Das legt nahe, dass Du hier in der Tat die Erklärung für diese Merkwürdigkeit gefunden hast!

Sagenhaft – weil der BluRay-Standard 25p/30p nicht vorsieht, müssen wir uns weiterhin mit diesem &/%§$§-Interlaced herumschlagen …

Leider auch meine Erfahrung.

p25 ergibt den ach so tollen "Kinolook". Deswegen immer gerne genommen. Und das wird oft als PSF erzeugt bzw. verarbeitet.

Ich dachte dafür gibt’s p24?

p25/30 heißt doch (dachte ich) einfach progressiv, aber möglichst geringe Datenmenge bei schon flüssigem Bild und kompatibel zu den klassischen TV-Wiederholraten.
Was ist denn PSF?

PSF:
In kurz - 2 identische Halbbilder ergeben optisch einen progressiven Bildeindruck.

p24/p25 kannst du mit dem Auge eher nicht unterscheiden. 24 Bilder kommt aus dem Kino, die 25 ergibt sich aus der halben Anzahl der gesendeten Halbbilder beim Fernsehen (50Hz Wechselstrom = 50 Halbbilder = 25 volle Bilder).

Mit 50 (Halb-)Bilder erst hast du eine flüssige Bewegungsauflösung. Und um Bandbreite zu sparen hat man deswegen das Interlaced-Verfahren erfunden, wie es seit Jahren im Fernsehen genutzt wird = doppelt so viele Bewegungen bei halber Auflösung. Die Lösung ist dann p50 (50 volle Bilder pro Sekunde).

Ah, danke! (Ich hatte in der Wikipedia gesucht, aber bei den vielen möglichen Bedeutungen von „PSF“ die einschlägige leider übersehen, sorry …)
Eben, das denke ich auch. Nur verstand ich dann Deine Bemerkung mit dem „Kino-Look“ nicht, da 25p für mich nichts „Kino-Look“-haftes hat, denn …
… das kann ich beim allerbesten WIllen nicht bestätigen. Ich kenne die Diskussion und habe mehrfach versucht, ein und dieselbe Aufnahme, einmal 50p, und dann runtergerechnet auf 25p, zu unterscheiden. Ich sehe einfach partout keinen Unterschied; im Blindtest ist meine Trefferquote 50%. Aber vielleicht differiert da der Gesichssinn bei verschiedenen Menschen erheblich.

Jedenfalls ist PSF dann des Rätsels Lösung für alle Videos, die nicht interlaced „aussehen“, aber in Apples Player-Software dennoch ruckeln, da mit MBAFF kodiert.

Genau so wenig wie p24!
"Kinolook" ist eine laienhafter Ausdruck - und der Look fängt bei eine progressiven Bild-Aufnahme an, für den Rest fehlen oft die Begriffe.



Der Unterschied ist erheblich!
Ganz vereinfacht gedacht - vergleiche eine normale Lampe mit einem Stroposkoplicht aus der Disko.

Wenn du den Unterschied nicht erkennen kannst hat das vermutlich mit deiner Wiedergabekette zu tun. Ein Computermonitor ist z.B. ist keine Referenz.

Ich hätte, von progressiv abgesehen, eher an optisch-ästhetische Aspekte gedacht, Tiefenschärfe, Bildausschnitt etc. Aber die Framerate hilft mir jedenfalls nicht, einen „Kino-FIlm“ zu erkennen.
Die Kunde höre ich wohl – ich kann’s nur eben nicht nachvollziehen …
Ooops, wieso das denn? Ein „Fernseher“ von heute ist doch nichts anderes als ein Computermonitor plus Digital-Empfangsteil …

In der Tat kenne/nutze ich nur als solche ausgewiesene Computermonitore und -Beamer. Einen Fernseher habe ich nie besessen, dazu kann ich nichts sagen. Und im Kino (wo mir natürlich der direkte A/B-Vergleich fehlt) kann ich auch keine „ Stroposkoplicht“-artige Wiedergabe bemerken.

Jedenfalls würde mich sehr interessieren, wieso ein Computermonitor Deiner Meinung nach ungeeignet sein soll. Ist die These, er wäre im Bildaufbau nicht schnell genug?

Mir mußt du das nicht sagen!



Na ja, ganz so ist es nicht.
Ein Computermonitor wird i.d.R von der Graphikkarte mit 60Hz angesteuert oder auch 75Hz. Diese Systeme waren nie dafür gedacht (und wer hätte das auch damals je gedacht), Fernsehbilder darzustellen. Deswegen werden alle Bilder dafür (beim Abspielen) neu berechnet. Der VLC beherrscht z.B. hervorragendes Frameblending. Genau zu sehen erst, wenn man das Signal extern aufzeichnet...
Auch sind die Pixelmaße nicht kompatibel zum Fernsehen - Abspielen mit schwarzen Rändern oder errechnete Bilder bei Vollbild-Darstellung.

Die frühen LCD-Panele hatten auch ein sehr kummes Pixelverhältnis - im Vergleich zum TV-Standard.
Die heutigen Fernseher sind eher auf diese Welt eingestellt. Und wenn man alle sog. Bildverbesserungseinstellungen ausschaltet kann man auch das gesendete Bild besser beurteilen. Und dann sieht man auch eher Unterschiede.

Naja, waren. Seit geraumer Zeit sollte doch auch den Grafikkartenherstellern klar sein, dass Bewegtbildwiedergabe in Zukunft immer „Computertechnologie“ sein wird. Diese Diskussion hätte ich 1995 gerade noch verstanden, aber doch nicht 2014!?
Darüber habe ich mir nie wirklich Gedanken gemacht. Das heißt, das jedwede Videosoftware die Framerate auf die möglicherweise hierzu völlig „schräge“ Bildwiederholfrequenz des Displays umrechnen muss? (Klingt ja absolut logisch …)

Gibt es auf dem Mac eine einfache Möglichkeit, die Bildwiederholfrequenz der Grafikkarte herauszufinden? In den Systeminformationen steht sie jedenfalls nicht.
Ja, nur wen kümmert denn heute noch der TV-Standard? Fernsehen ist doch zumindest im technischen Sinne ein totes Medium. Man kann sich doch bei einer aktuellen Medienproduktion nicht mehr an solch anachronistischen Dingen wie nicht-quadratischen Pixeln orientieren? Main Profile und High Profile h.264 gehen meines Wissens jedenfalls ausschließlich von quadratischen Pixeln aus.

Wie auch immer, das alles macht mir nicht verständlich, warum ein Computerdisplay, und sei es auch nur mit 60 Hz Bildwiederholfrequenz betrieben, dazu ungeeignet sein soll, die wahrnehmungsphysiologischen Unterschiede zwischen 25p und 50p zu demonstrieren. Klar, laut Abtasttheorem müsste es 100 Hz haben, aber im Ansatz sollte man die Unterschiede doch auch so erkennen können.

Ähmja, erstmal das hier:
Bild von simplepimple.com
Im Kino hat man bei "Live" Produktionen immer Bewegungsunschärfe, wodurch die 24fps dann noch relativ angenehm sind.

Dann: Ja, die Bildrate vom Medium muss irgendwie an die des Displays angepasst werden. Dies ergibt sich aber normalerweise von ganz allein. Der Player lädt einfach alle 1/fps Sekunden ein dekodiertes Bild in den GPU Speicher und wenn ein neues Bild an den Monitor geliefert werden muss, wird einfach immer das genommen was zuletzt abgelegt wurde. Dadurch werden dann Bilder entsprechend doppelt oder dreifach angezeigt. Die meisten Player wissen von der Display-Wiederholfrequenz gar nichts und schieben einfach Bilder zur GPU wie sie gerade kommen. Ausnahmen sind hier XMBC, welches auf Wunsch versucht die Display-Frequenz an die des Videos anzupassen und MPC-HC+MadVR (Windows Only) welches dann auf Wunsch zu Frameblending greift um durch einfache Überlagerung der Bilder die fehlenden Zwischenbilder zu generieren (Wie ich hörte, soll das ganz gut Funktionieren, hab es selber nie ausprobiert).


Heutige Flat-TVs sind Hardware-mäßig weitestgehend identisch zu normalen Computermonitoren. Es gibt allerdings einige kleine Stolperfallen: Zu nächst, wie schon erwähnt, die grausigen Videofilter die standardmäßig aktiviert sind. Dann sind viele TVs so genial und machen (vermutlich wegen der Filter, selbst wenn nicht benutzt) aus einem per HDMI angeliefertem RGB-Bild erstmal ein 4:2:2 YUV Bild welches dann zur Anzeige auf dem Panel schlussendlich wieder auf RGB zurückgerechnet wird. Abgesehen von Rundungsfehlern, hat dies zur Folge, dass die Auflösung der Farbinformationen mal eben halbiert wird und damit dann einiges an Qualität verloren geht. Bei normalem TV oder Wiedergabe von Blu-rays ist das nicht so schlimm, da hier das Bild eh schon nur in 4:2:0 vorliegt aber wenn man einen Computer anschließt, bekommt man manchmal etwas merkwürdige Artefakte.

Echt? Davon hab ich noch nichts gehört und konnte dazu im Internet auf anhieb auch nichts finden. Haste du weitere Infos dazu?

Ja, theoretisch ist mir das ja klar, und in dieser Zeitlupe sehe ich’s natürlich auch. Aber in Echtzeit (24fps) sehe ich den Unterschied halt nicht. Ich glaube, dabei sollten wir es belassen – die einen scheinen da „schnellere“ Augen zu haben als die anderen. (Vielleicht können manche ja auch noch 50fps von 100fps unterscheiden?)
OK, dann ist das also doch so simpel, wie ich ursprünglich annahm. Danke für die Info!
Eben …
Was bedeutet, dass heutige Flat-TVs wenn, dann schlechter zur möglichst genauen Qualitätsbeurteilung geeignet sind als Computermonitore, nicht besser. Das deckt sich auch mit meinen (wenigen) Erfahrungen.

Man kann auf einem Computermonitor kein Fernsehbild beurteilen!
Besonders, wenn er über die Graphikkarte des Rechners angesteuert wird.

Das ist keine Zeitlupe ... außer dein Rechner schafft es aus irgendwelchen Gründen nicht, das GIF flüssig abzuspielen.

Auf Perian angewiesen zu sein, ist keine gute Idee - das Zeug ist bekannt für Trouble und man sollte sich das nur auf Rechnern antun, auf denen es 100% notwendig ist.

Ich weiß nach dem jetzigen Diskussionsstand nicht mehr, was Du damit meinst.

Meinst Du, ich kann nicht beurteilen, wie das Video auf einem Fernseher abgespielt aussehen würde? Das mag sein, ist aber im Kontext unserer Diskussion (können Menschen 24p von 50p unterscheiden?) irrelevant.

Oder meinst Du, ich könne auf einem Computermonitor keine neutrale Beurteilung technischer Aspekte von Videos (Auswirkung unterschiedlicher Frameraten, Farbqualität oder was auch immer) vornehmen, die mit im Fernsehen verwendeten Frameraten produziert wurden? Dann verstehe ich nach wie vor nicht, warum das so sein soll – mit der Einschränkung dass für ein quantitativ valides Ergebnis bezüglich menschlicher Wahrnehmung von Frameraten die Bildwiederholfrequenz des Monitors in der Tat vermutlich mindestens doppelt so hoch wie die höchste untersuchte Framerate sein müsste (aber das ist bei handelsüblichen Fernsehern meines Wissens ebenso wenig der Fall).

Oooops! Seite neu geladen, Animation viel schneller … Kein Ahnung, warum …

Hm, das könnte jetzt in der Tat annähernd Echtzeit sein, und ja, wenn ich vorher weiß, dass sich das 1. und das 3. Bild unterscheiden und sehr konzentriert und genau hinsehe, dann sehe ich einen minimalen Unterschied zwischen 1 und 3 (Bild 2 ist deutlich ruckelnder). Aber sobald ich mich nicht darauf konzentriere, ist der weg. Wenn man statt der Computergraphik einen tatsächlichen Film mit entsprechend komplexen Bildern nimmt, schaffe ich die Unterscheidung dann möglicherweise wieder nicht mehr.

Ist der Unterschied für Dich ganz deutlich?

Hm, ich hatte eigentlich nie Probleme damit (zumindest ist mir nichts aufgefallen). Und wie gesagt, da das hier diskutierte Problem auch bei dem QuickTime Player X auftritt, der Perian ignoriert, sollte auch dieses Problem nichts mit Perian zu tun haben.

Andererseits bin ich auf Perian für viele Filme mit ass-Untertiteln angewiesen.

"Ganz deutlich" wäre zu viel gesagt, aber er ist auf jeden Fall erkennbar. Ich will jetzt auch keine Framerate Diskussion führen, sondern wollte einfach nur ein Beispiel für die Unterschiede zwischen den Bildraten einbringen.

Dem muss ich zustimmen. Perian wird nicht mehr gewartet und wird damit auch zunehmend zum Stabilitäts- und Sicherheitsrisiko.

Perians ASS unterstützung ist bestenfalls als Rudimentär zu bezeichnen. Hier sollte man auf jedem Fall zu einem Player greifen der eine mehr oder weniger aktuelle Version von libass verwendet (VLC weniger aktuell, mpv i.d.R. sehr aktuell).

Vielleicht gehen da auch ästhetische Präferenzen ein. Ich empfinde ein Bild mit Tiefenunschärfe generell „realistischer“ als „alles-gleich-scharf“-Fotos aus einem Smartphone, aber andere finden Letzteres toll. Soweit ich die Differenz in Deinem GIF wahrnehme, erscheint mir ganz entsprechend Bild 3 etwas „realistischer“, Bild 1 hingegen etwas künstlich. Vielleicht geht das mit ein in meine Schwierigkeit zu sagen, Bild 1 ist klar unterschieden im Sinne von „besser/korrekter als Bild 3“.

Aber lass uns die Diskussion beenden, ehe sie esoterisch wird …
Naja, das hilft mir nix, weil ich u.a. Untertitel für Kinovorführungen erstelle. Den Kinos kann ich QuickTime Player 7 mit Perian als Systemvoraussetzung vorgeben (ist meiner Erfahrung nach praktisch eh überall installiert), aber mpv mangels GUI nicht (vermutlich, habe ich noch nicht probiert), und VLC mangels Farbmanagement nicht.

Oder ich rendere aus den Filmdateien und den ass-Untertiteln eine neue h.264-Datei mit fest einkodierten Untertiteln in Compressor – dann brauche ich wieder Perian dazu, damit Compressor ass versteht …

... Oh Gott *Gesichtszüge entgleit*

Also, um einen einzelnen Film abzuspielen braucht man jetzt nicht wirklich eine GUI ... zu mal mpv ja zumindest den OSC hat, und viel mehr GUI hat QuickTime X ja jetzt auch nicht. Allerdings ist natürlich vorher etwas Konfiguration per config Datei notwendig.

Dann ... muss es unbedingt ASS sein? Das scheint für die Professionelle Anwendung ja eher ungeeignet zu sein. QuickTime unterstützt ja von Haus aus auch Untertitel in so einem 3GP Format (kann man von SRT konvertieren). Aber das geht nur ohne besonderes Styling und wenn man die art wie QT die Untertitel darstellt nicht mag, hat man wohl Pech gehabt.

Dann ... Compressor? Ich hab jetzt keine direkten Vergleiche zur Hand, aber soweit ich weiß ist x264 nach wie vor der beste Encoder. Wenn man keine Angst vor der Kommandozeile hat, sollte man auf jeden Fall dazu greifen. Da gibt es dann auch bessere Möglichkeiten Untertitel ins Video zu toasten, sofern notwendig.

Du steckst da in der Tat in einer recht verfahrenen Situation. Auf Lange Sicht solltest du aber auf jeden Fall versuchen mpv für die Wiedergabe zu etablieren, scheint die einfachste Lösung für deinen Workflow zu sein.

Huch!?! Was’n jetzt sooo schlimm daran
Schon. Aber das musst Du nicht mir sagen, sondern den Filmvorführern …

Alles, was zusätzlich installiert werden muss, ist dort suspekt. Ich sehe mich schon eine „richtige“ GUI für mpv schreiben, aber selbst dann wäre wohl viel Überzeugungsarbeit nötig. Wenn sowas einmal zum Selbstläufer geworden ist, à la Cinephiles use mpv, dann geht das wohl, aber bis dahin …
Zum Beispiel. Ein „richtiges“ Präferenzen-Fenster mit für OS X sinnvollen Voreinstellungen wäre zwingend erforderlich.
Kommt darauf an. Die Untertitel, die ich erstellt habe, wurden im filmwissenschaftlichen Kontext benötigt, um Filme in „exotischen“ Sprachen deutschsprachigen Filmwissenschaftlern zugänglich zu machen. Dazu ist es zwingend erforderlich, die Dialoge in all ihren Nuancen zu transkribieren statt, wie bei kommerziellen Untertitelungen oftmals der Fall, in stark vereinfachter, aber dadurch beim Betrachten des Films leichter mitlesbarer Form. Um das Mitlesen beim Betrachten des Films dennoch einigermaßen zu ermöglichen, habe ich recht erfolgreich Schriftattribute (kursiv, fett, Schriftgröße) eingesetzt. Und das geht nur mit ASS (jedenfalls war das vor ein paar Jahren so, als ich das entschieden habe).
Angst vor der Kommandozeile habe ich keine, aber ich mache das alles nur ab und an, und da bin ich froh, wenn ich ohne großes Nachdenken auf einen einmal etablierten Workflow zurückgreifen kann.
Naja, so dramatisch ist das nicht. Mein jetziger Workflow funktioniert ja bis auf Weiteres, und auf lange Sicht werden sich schon neue Möglichkeiten finden.