Das 720p hätte man mit ca. 1540 kbits für Video kodieren sollen, dann wäre es bildqualitativ gleichwertig zum 1080p. Es wurde aber mit 4317 kbits kodiert, ist also 2,8 mal größer als nötig, und das nur damit die DVDR schön voll ist und "perfekt" ausgenutzt erscheint.
Also ich würde mir keine Version ziehen, wo die Auflösung 2,25 mal so gering und somit das Bild wesentlich unschärfer ist, die Datei aber proportinal gesehen 2,8 mal größer als nötig ist.
dreaven3 schrieb: Ziehen werden es all diejenigen dessen Rechner nicht für 1080p ausreicht.
Ohne es jetzt selbst in diesem konkreten Fall überprüft zu haben, richtet sich generell aber die CPU-Auslastung beim Dekodieren von Videomaterial nicht nach der Auflösung, sondern nach der Bitrate.
D.h. hier sollte die Wiedergabe des 702p auf dem Rechner mehr Prozessorlast verursachen als das 1080p. Je höher die Bitrate desto mehr CPU-Auslastung; das gilt genauso oder soagr erst recht fürs Encoding.
das stimmt. Da ich sonst nur den WDTV nutze zum schauen und keine Probleme habe - geht aber dafür zur Vorschau mein Laptop oft in die Knie. hier in dem Fall nicht
Lude schrieb: Ohne es jetzt selbst in diesem konkreten Fall überprüft zu haben, richtet sich generell aber die CPU-Auslastung beim Dekodieren von Videomaterial nicht nach der Auflösung, sondern nach der Bitrate.
Da hast du doch deine Antwort Faxe.
Bei untouched ist die Bitrate ja noch höher. Also muss der CPU noch mehr Daten pro Bild verarbeiten... Also braucht es noch mehr Leistung.
Jedenfalls meine logische Schlussfolgerung.
edit:
Die anscheinend Schwachsinn war ;-) Aber man lernt nie aus.
Schweift hier aber echt gerade sehr vom eigentlich Release ab.
2 mal bearbeitet, zuletzt 13. Jan. 2010, 01:42 Uhr
Es kommt nicht nur auf die reine Bitrate an. Es kommt auf die Kompression des entsprechenden Codecs an. Und diese ist in mkv-Containern ziemlich hoch, weshalb es auch so anstrengend ist. Hat mit der Bitrate des reinen Datenstreams nicht so viel zu tun.
Warum lassen sich DVDs so einfach abspielen ? Weil die Daten da mehr oder weniger unkomprimiert sind. Das einzig anstregende war für die Rechner damals die Daten auf das Anzeigegerät zu bringen.
So und genauso ist es mit Blurays auch. Es muss nicht viel berechnet werden - am Datenstream selbst - sondern dieses hochauflösende Bild muss ans Anzeigegerät kommen.
Mkv-Container sind stark komprimiert, die CPU muss es also erst einmal "auspacken" und dann muss der Rechner das zum Anzeigegerät liefern. Das lastet ihn aus.
Oder man lässt VLC für HD Releases einfach links liegen und steigt z.B. auf MPC-HC um - bei dem kann man dann mit den richtigen Einstellungen die Grafikkarte das Bild erzeugen lassen. Voila - CPU Last auf 5% bei 1080p Release (The Dark Knight z.B.).
Für HD Releases ist VLC echt ungeeignet muss ich sagen, ansonsten sehr gut.
Genug geschwafelt, wieder mal was zum Release:
Bild: Alles top. 10/10
Ton: Wundervoller Sound. 10/10
Film: Sowieso, einer der besten Filme des Jahres 2009. Eindeutig. Siehe Rezension...
Noch eben schnell vor dem Schlafen gehen Klärung hierzu:
Faxe schrieb: Es kommt nicht nur auf die reine Bitrate an. Es kommt auf die Kompression des entsprechenden Codecs an. Und diese ist in mkv-Containern ziemlich hoch, weshalb es auch so anstrengend ist. Hat mit der Bitrate des reinen Datenstreams nicht so viel zu tun.
Eher Nein, aber je nachdem wie es gemeint war.
Es kommt nicht auf die Kompressionsrate an. Welche Datenrate das Sourcematerial hatte ist nicht mehr von belangen. Und somit ist es auch unwichtig, um wieviel Prozent die Source eingestampft wurde. Auch die Qualität des neukodierten Materials ist unwichtig. Es kann total verpixelt bzw. mit Artefakten übersäht sein.
Entscheidend ist die Bitrate des wiederzugebendens Materials sowie der verwendete Codec. MPEG-2 (DVD) braucht sowohl fürs Encoding wie auch für die Wiedergabe wesentlich weniger Rechenpower als H.264 (BD bzw. 1080p-MKVs). Demnach ist natürlich die Rechenlast bei der Wiedergabe von BDs und 1080p-MKVs höher als die bei DVDs.
Und natürlich wird auch für die Wiedergabe von untouched BDs mehr Rechenpower benötigt als bei reencodeten 1080p-MKVs.
Da allerdings heutzutage fast alle neuen Mainboard-Chipsätze eine HD-Wiedergabe hardwarebeschleunigen, ist die CPU-Rechenlast bei der Wiedergabe von BDs z.B. mit PowerDVD sehr gering. Hierbei übernimmt der Chipsatz die Dekodierung und somit die Rechenlast, sodass es im Taskmanager scheinbar so aussieht, als ob es da nicht viel zu rechnen gäbe.
Das Gleiche gilt auch für MPEG-2 sowie VC-1 bzw. WMV v9, da die BD diese beiden ebenfalls untersützt und so die CPU-Rechenlast bei einer BD bzw. DVD mit MPEG-2 gegen Null tendiert.
Faxe schrieb: Warum lassen sich DVDs so einfach abspielen ? Weil die Daten da mehr oder weniger unkomprimiert sind. Das einzig anstregende war für die Rechner damals die Daten auf das Anzeigegerät zu bringen.
Weil wie gesagt MPEG-2 wesentlich weniger Rechenpower für die Wiedergabe benötigt als H.264.
Zudem sind DVDs nicht (nahezu) unkomprimiert. Die unkomprimierten Videodaten wären bei einer DVD so um die 250 Mbits mächtig. Wenn man von einer avg-Videobitrate von 5 Mbits ausgeht, dann sind die Daten so um das 50-fache komprimiert.
Faxe schrieb: So und genauso ist es mit Blurays auch. Es muss nicht viel berechnet werden - am Datenstream selbst - sondern dieses hochauflösende Bild muss ans Anzeigegerät kommen.
Im Vergleich zur DVD muss wesentlich mehr berechnet werden, also mehr Power beim Dekodieren wird benötigt.
Bei einer BD mit 1080p und 24 fps sind die unkomprimierten Videodaten ca. 1,8 Gbits mächtig, das ca. 7-fach einer DVD. Hier werden die Daten (bei einer BD mit avg 25 Mbits) auf das ca. 70-fach komprimiert.
Die vom HD- oder BD-Player dekodierten Daten werden dann meist unkomprimiert per HDMI zum HD-TV gebracht. Das Anzeigen dieser kostet dann den LCD-TV so gut wie keine "Rechenpower" mehr, da der rechenintensive Schritt des Dekodierens bereits durch den Player erfolgt ist.
Faxe schrieb: Mkv-Container sind stark komprimiert, die CPU muss es also erst einmal "auspacken" und dann muss der Rechner das zum Anzeigegerät liefern. Das lastet ihn aus.
Das steht im Widerspruch zur deiner Aussage davor.
Zudem ist MKV nur ein Container-Format, so wie AVI eben auch. Das sagt noch nichts über den verwendeten Codec und den damit verbundenen Dekodieraufwand aus.
In AVIs muss kein DivX oder XviD stecken, es könnte auch Intel Indeo, DV oder unkompimiertes RGB sein. So muss auch in MKVs kein H.264 stecken, ist es aber zumindest bei den Szene-Rels hier immer der Fall. Das hat aber nix mit dem Kontainer MKV zu tun, der steht für sich und ist nicht von bestimmten Codecs abhändig oder mit denen zwanghaft verbunden.
H.264 könnte auch im AVI-Kontainer stecken, wäre aber total unüblich. Gehen würde es aber, und dann würde eine AVI-Datei damit viel mehr Rechennpower für die Wiedergabe benötigen als eine "normale" XviD-AVI. Das hat alles aber nix mit AVI selbst zu tun.
Es gibt hier keine Downloads, Links zu Downloads, Torrents, Magnet-Links, NZB-Dateien oder ähnliches.
Wir bieten nur Informationen über die Existenz eines Releases, seine Größe sowie die beiliegende NFO-Datei an. Wir unterstützen Benutzer in keiner Form dabei, dieser Releases habhaft zu werden.
Sämtliche Verweise auf Angebote zu illegalen Kopien sind auch in Kommentaren sowie in unserem Forum verboten, was von unserem engagierten Moderatoren-Team ständig überprüft wird.
Bei weiteren Fragen kann man uns per E-Mail an xrel *at* xrel *punkt* to kontaktieren.
There are absolutely NO downloads of copyright-protected works, hyperlinks to downloads, torrent files, magnet links, nzb files or similar content on any part of this web site.
What we offer is information about the existence of a release, its size, and the corresponding NFO file. We do NOT help or encourage users to download or otherwise obtain any of the listed releases.
Links to pages containing illicit copies of copyrighted works are strictly prohibited in user-generated content as well. This is constantly being monitored and enforced by our committed team of moderators.
For any further questions, please do not hesitate to contact us by sending an e-mail to xrel *at* xrel *dot* to.
#