[gelöst] HD-recs ruckeln auf Notebook

[JayTee]

Bitteschön:

HP Compaq 6730b
[quote="JayTee"]...
Intel Core2Duo P8700 @ 2,53GHz / 3GB RAM / Mobile Intel 4 Series Express

VLC 1.1.7
Codec: H264 - MPEG-4 AVC (part 10) (h264)
Auflösung: 1920x1080
Bildwiederholrate: 50

...[/quote]

[nilssohn]

Danke, ist ein Anfang. Ich werde versuchen, die Ergebnisse in diese Liste einzupflegen. Mal sehen, ob das klappt oder ob der Server die Seite wegen eines Session Timeouts oder so bald nicht mehr anzeigt.

Ist es überhaupt eine gute Idee, sich jetzt auf die CPU zu konzentrieren? Hat jemand noch eine andere zündende Idee?

[JayTee]

Sagen wir mal so, vorletzten Urlaub hatte ich eine USB-Platte mit recs direkt vom 5er mit.

Beim anschauen auf dem alten Läppi (P4/1,8) kam es immer mal wieder zu kurzen Hängern, seit dem Neuen keine Probs mehr.

Edit:

Wenn ich mir aber deine Ausstattung so ansehe, insbesondere die sicherlich bessere Grafik als bei meinem.

[nilssohn]

Wenn ich mir aber deine Ausstattung so ansehe, insbesondere die sicherlich bessere Grafik als bei meinem.

Ansonsten decodiert VLC meines Wissens rein per Software. Das heißt die Fähigkeit der Grafikkarte spielt hierbei keinerlei Rolle, nur die der CPU. Anders der Mediaplayer-Classic. Der nutzt die Hardware-Decodierung der Grafikkarte.

Das passt zu meiner Beobachtung, dass das Ruckeln unabhängig von der Auswahl einer der beiden Grafikchips auftritt.

"Cannot render the file" ist die Antwort des mplayerc, wenn ich den Misery-Schnipsel abspielen will. Das gilt auch, wenn ich die Dateiendung in .ts umbenenne.

So far.

[JayTee]

Upps, das mit VLC hab ich übersehen. ops:

[hagge]

[quote="nilssohn"]Ist es überhaupt eine gute Idee, sich jetzt auf die CPU zu konzentrieren? Hat jemand noch eine andere zündende Idee?[/quote]
Im Prinzip schon. Wenn ein entsprechend komplexes Codierungsverfahren wie H.264 (speziell mit B-Frames) verwendet wird, dann kommen auch viele leistungsstarke CPUs an ihre Grenzen. Allerdings sollte sich das dann auch im Taskmanager im Tab Systemleistung dahingehend bemerkbar machen, dass ein paar Spitzen mit 100% CPU-Last vorhanden sind. Ob die Last im Mittel irgendwo bei 60% liegt, ist in diesem Fall egal. Denn wenn die CPU in ein paar kritischen Szenen, wo z.B. sehr viel im Video passiert, kurzfristig an ihre Grenzen kommt, dann reicht das schon zum Ruckeln.

Ich habe einen Dual-Core Desktop-Athlon X2 mit 2,7 GHz getaktet daheim, zugegeben schon 3 Jahre alt, aber langsam ist der Prozessor nicht gerade. Und der schafft keine Full-HD-Videos, die mit H.264 codiert sind, ohne Ruckeln. Andere Codierungen ja, aber nicht volles H.264 (AVCHD). Erst mit Hardwareunterstützung der Grafikkarte geht es flüssig. Insofern könnte es schon an der CPU liegen.

Nutzt man alle Features, die so eine H.264-Codierung bietet, also mit B-Frames und entsprechend langer Referenzframe-Kette, dann kriege ich mit VLC sogar meinen aktuellen Desktop-PC in der Firma zum Ruckeln, immerhin eine Z200-Workstation von HP mit Core-i7-870-Prozessor! Da bringen die vier Kerne mit Hyperthreading eben nichts, wenn der Decoder alles nur in einem Thread macht. Dann kann auch nur ein Kern der CPU dran arbeiten und der Rest liegt brach. Da staune ich dann immer wieder, wie so ein kleiner Mediaplayer wie der WD TV live für gerade mal 90 Euro so ein File völlig flüssig abspielen kann. Aber der macht das eben in Hardware.

Gruß,

Hagge

[nilssohn]

Wenn ein entsprechend komplexes Codierungsverfahren wie H.264 (speziell mit B-Frames) verwendet wird, dann kommen auch viele leistungsstarke CPUs an ihre Grenzen. Allerdings sollte sich das dann auch im Taskmanager im Tab Systemleistung dahingehend bemerkbar machen, dass ein paar Spitzen mit 100% CPU-Last vorhanden sind. Ob die Last im Mittel irgendwo bei 60% liegt, ist in diesem Fall egal. Denn wenn die CPU in ein paar kritischen Szenen, wo z.B. sehr viel im Video passiert, kurzfristig an ihre Grenzen kommt, dann reicht das schon zum Ruckeln.

Danke, hagge. Der Ressourcenmonitor bringt es ans Licht - mit keinem eindeutigen Ergebnis. Die Überwachung fand während des Abspielens des Misery-Schnipsels mit VLC 1.17 statt, Beginn und Ende der Belastung sind deutlich zu erkennen. Weitere offensichtliche Aktivitäten fanden auf dem Notebook nicht statt.


(CPU-Auslastung beim Abspielen von Misery-Schnipsel.rec (67,4 MB) in VLC 1.1.7)

Man sieht, dass CPU 1 nahe an der 100%-Auslastung steht, sie aber nie erreicht. Was sagt uns das jetzt?

Ich habe die CPU-Vergleichsliste (Link in Post #62) anhand der Daten in diesem Thread aktualisiert. Auch wenn Dirks und Wolfmans CPU noch fehlen (der exakte Prozessorname wäre nötig), ist die CPU meines Notebooks schon jetzt die schwächste und wird es hier wohl auch bleiben. Das deutet stark darauf hin, dass tatsächlich die CPU der berüchtigte "limitierende Faktor" ist. Und wie limitierend.

Ein Grund mehr, sich auf den hier empfohlenen alternativen Media Player Classic zu konzentrieren, der nicht nur die CPU rechnen lassen, sondern die Grafikkarte zuhilfe nehmen soll. Diddi schrieb:

Also mit VLC 1.15 ruckelt genau wie von Dir beschrieben,
mit Nero 7.0 Showtime, Mediaplayer 9 und Mediaplayer Classic geht einwandfrei.

Vielleicht würde das ja auch bei mir klappen, auch wenn sein T6500 stärker ist als mein SU9400. Also ...

brauche ich eine Idee, welche System-Codecs ("External Filters", s. 2. Screenshot in Post #40) im Media Player Classic eingebunden werden sollten, damit er nicht mehr "cannot render file" meldet.

soll ich einfach mal immer ein Dutzend der externen Filter hinzufügen, dann Misery ruckeln lassen, dann das nächste Dutzend ...?

... habe ich genau das gemacht. Alle internen Filter (wie bei Diddi) angehakt und dann spaltenweise alle hundertwasweißich externen Filter wie im zweiten Screenshot von Post #40 zu sehen hinzugefügt, inklusive der erst vor wenigen Tagen installierten CoreAVC 2.0 Codecs. Zwischendurch immer wieder getestet. Ergebnis: "Cannot render the file".

Das ist der Stand.

[hagge]

Der Ressourcenmonitor bringt es ans Licht - mit keinem eindeutigen Ergebnis.

Ich finde das Ergebnis ist schon recht eindeutig. Die Decodierung findet auf CPU 1 statt und die ist damit so ziemlich ausgelastet und kommt eindeutig öfters an die Obergrenze. Das werden die Stellen sein, wo es ruckelt. Und man sieht, dass VLC die Decodierung überwiegend in einem Thread macht, denn die CPU 0 dümpelt irgendwo bei 40% Last vor sich hin. Das heißt sie wird irgendwo mit dem Auslesen der Files und irgendwelchen anderen Systemfunktionen zu tun haben, aber sie kann sich aufgrund der Art und Weise, wie der Decoder geschrieben ist, nicht an der Decodierung beteiligen. Im Endeffekt bist Du in diesem Fall mit dem Dual-Core-Prozessor nicht viel besser dran, als mit einem Single-Core. Denn das, was der zweite Kern hier an Arbeit abnimmt, wäre ein Single-Core höher getaktet und dadurch schneller. Das ist das, was die Leute immer sagen, dass mehrere Kerne nur dann Geschwindigkeitsgewinn bringen, wenn sie auch wirklich ausgelastet werden können, also entweder indem entsprechend viele Programme parallel arbeiten oder indem die Software so geschrieben wird, dass sie mehrere Threads nutzt, die dann auf die verschiedenen Cores verteilt werden können.

Man sieht, dass CPU 1 nahe an der 100%-Auslastung steht, sie aber nie erreicht.

Also ich denke sie erreicht schon die 100%. Wenn bei mir die CPU auf 100% rechnet, ist oben auch immer noch ein bisschen Luft zur Oberkante des schwarzen Fensters.

Das deutet stark darauf hin, dass tatsächlich die CPU der berüchtigte "limitierende Faktor" ist.

So sehe ich das auch.

Ein Grund mehr, sich auf den hier empfohlenen alternativen Media Player Classic zu konzentrieren, der nicht nur die CPU rechnen lassen, sondern die Grafikkarte zuhilfe nehmen soll.

Auch dies sehe ich als richtige Schlussfolgerung an. Wobei man nicht nur auf den MPC schauen sollte, sondern auf alle Player, die Hardware-Unterstützung haben. Wobei ich fairerweise zugeben muss, dass mir da auf Anhieb auch kein weiterer kostenloser Player einfallen würde. Hast Du es schon einmal mit dem MPlayer probiert?

Kannst Du mal gspot über Deinen Codeschnipsel laufen lassen, so dass man sieht, was da wirklich für eine Videocodierung drinsteckt? Es kann ja sein, dass der MPC zufällig mit diesem Format nicht zurecht kommt. Wenn es allerdings bei anderen klappt, dieses Video mit MPC abzuspielen und nur bei Dir nicht, dann müsste sich die Ursache finden lassen.

Gruß,

Hagge

[nilssohn]

Neuer Zwischenstand.

Also ich denke sie erreicht schon die 100%. Wenn bei mir die CPU auf 100% rechnet, ist oben auch immer noch ein bisschen Luft zur Oberkante des schwarzen Fensters.

So sei es, ich folge dir.

Hast Du es schon einmal mit dem MPlayer probiert?

Jetzt ja - und kann einen Teilerfolg melden. Der SMPlayer in Version 0.6.9 für Windows 32 bit spielt die HD-Filme nämlich bis auf seltene Aussetzer ruckelfrei ab. Allerdings um den Preis reduzierter Wiedergabegeschwindigkeit und asynchronen Tons. Beides ist intolerabel, aber nun stehe ich zumindest nicht mehr vor dem Problem, eine Konstante wie die CPU-Rechengeschwindigkeit akzeptieren zu müssen, sondern habe Softwarevariablen, die sich mit etwas Glück und Sachverstand anpassen lassen. Denn die CPU-Belastung ist etwas geringer, wie man an nachfolgendem Screenshot sehen kann.



(CPU-Auslastung beim Abspielen von Misery-Schnipsel.rec (67,4 MB) in SMPlayer 0.6.9)

Der Misery-Schnipsel passt allerdings nicht mehr in den überwachten Bereich, denn das Abspielen dauert ca. 90 Sekunden im Vergleich zu korrekten ca. 50 sec in VLC. Der Ton läuft in normaler Geschwindigkeit und ist entsprechend früher fertig. In anderen HD-Aufnahmen habe ich eine Doppelung des Tons festgestellt, wie ein Echo, das alle paar Sekunden auftritt. Als erste Maßnahme habe ich daher in den Audio-Optionen des SMPlayers ein Häkchen gesetzt bei "Automatische Audio-/Videosynchronisation" - und es gleich wieder entfernt. Denn das Bildstocken war schlimmer als bei VLC, sogar bei der geringer aufgelösten HD-Aufnahme aus dem Ersten.

Nicht betroffen von Problemen sind übrigens SD-recs. Die lassen sich in beiden Playern problemlos abspielen, egal mit welchen Einstellungen.

Verwendet jemand der Mitlesenden den SMPlayer und kann HD-recs sauber damit abspielen?

Im nächsten Schritt möchte ich die zwischenzeitlich entfernten CoreAVC-Codecs wieder installieren, um damit vielleicht eine Verbesserung beim SMPlayer zu erreichen. Für die Seriennummer brauche ich allerdings Zugriff auf den Kundenbereich von deren Website, und die ist gerade down. Hoffentlich haben die nicht gestern pleite gemacht.

Kannst Du mal gspot über Deinen Codeschnipsel laufen lassen, so dass man sieht, was da wirklich für eine Videocodierung drinsteckt?

Code: Alles auswählen

File Type: MPEG-2 Transport Stream
Mime Type: video/mp2t

Ist das, was du meinst? Diese Codierung besitzen offenbar alle meine Topfaufnahmen, ob SD oder HD, ÖR oder PayTV.

[jkIT]

Der SMPlayer in Version 0.6.9 für Windows 32 bit spielt die HD-Filme nämlich bis auf seltene Aussetzer ruckelfrei ab. Allerdings um den Preis reduzierter Wiedergabegeschwindigkeit und asynchronen Tons. Beides ist intolerabel...

Der Ton läuft in normaler Geschwindigkeit und ist entsprechend früher fertig. In anderen HD-Aufnahmen habe ich eine Doppelung des Tons festgestellt, wie ein Echo, das alle paar Sekunden auftritt. Als erste Maßnahme habe ich daher in den Audio-Optionen des SMPlayers ein Häkchen gesetzt bei "Automatische Audio-/Videosynchronisation" - und es gleich wieder entfernt. Denn das Bildstocken war schlimmer als bei VLC, sogar bei der geringer aufgelösten HD-Aufnahme aus dem Ersten.

Das sind halt unterschiedliche Strategien mit der zu langsamen Videodekodierung umzugehen. Das ändert aber nichts daran, dass deine CPU als Dekodierer für H.264 (HDTV) nicht schnell genug ist.

Nicht betroffen von Problemen sind übrigens SD-recs. Die lassen sich in beiden Playern problemlos abspielen, egal mit welchen Einstellungen.

Klar, denn SD Aufnahmen lassen sich viel einfacher dekodieren.

Ich teste auch gerade mit der ffmpeg.lib, die ja auch dem MPlayer zugrunde liegt. Auch meine CPU ist für h264 nicht schnell genug. Sie schafft bei reiner Videodekodierung mit deinem Schnipsel ca. 16 Frames/s, statt 25 (während ich bei SD auf 137 F/s komme) . Eine Möglichkeit, das zu beschleunigen ist, B-Frames, die keine Referenzframes sind, auszulassen. Das ergibt noch eine akzeptable (nur leicht ruckelnde) Ausgabe mit durchschnittlich 28 F/s. Was in der Praxis leider immer noch nicht ganz reicht.
Im VLC müsste das mit der Einstellung "Input&Codec -> h264 Einsprungfilter -> ohne Referenz" sein. Beim (S)Mplayer weiß ich das jetzt nicht.

Bei Deinem Schnipsel könnte man auch das deinterlacing ausschalten, weil das zwar 1080i ist, aber nicht interlaced encodiert wurde. Das kann schon 5-10% bringen, wenn es der gleiche Thread macht, wie der Dekodierer.

Am meisten würde es bei Dir wohl bringen, wenn man den zweiten Kern besser auslasten könnte. Es gibt für ffmpeg einen Multithreading Entwicklungszweig "ffmpeg-mt". Damit scheint bei h264 ein Gewinn von Faktor > 1,5 drin zu sein (siehe z.B. hier)

Und jetzt kommt´s: Auch für den SMplayer gibt es dafür eine experimentelle Version.
Das könntest Du mal ausprobieren. Ich hab leider nur einen Kern und kann deshalb nicht mehr dazu sagen.

Code: Alles auswählen

File Type: MPEG-2 Transport Stream
Mime Type: video/mp2t

Ist das, was du meinst? Diese Codierung besitzen offenbar alle mene Topfaufnahmen, ob SD oder HD, ÖR oder PayTV.

Er meinte wohl eher die Codec Informationen, nicht die "Verpackung"
1920x1080i h264 50fps main profile ...

[nilssohn]

Eine Möglichkeit, das zu beschleunigen ist, B-Frames, die keine Referenzframes sind, auszulassen. Das ergibt noch eine akzeptable (nur leicht ruckelnde) Ausgabe mit durchschnittlich 28 F/s. Was in der Praxis leider immer noch nicht ganz reicht.
Im VLC müsste das mit der Einstellung "Input&Codec -> h264 Einsprungfilter -> ohne Referenz" sein.

Das bringt durchaus etwas, wenn auch noch keine flüssige Darstellung. Deinterlacing war bereits ausgeschaltet.

Am meisten würde es bei Dir wohl bringen, wenn man den zweiten Kern besser auslasten könnte. [...] Auch für den SMplayer gibt es dafür eine experimentelle Version.

Und das ist es!

Bei der Installation der Version 0.6.9+SVN-r3597 wird eine Entscheidung für Single- oder Multicore-CPUs (Intel oder AMD) getroffen. In den Einstellungen -> Leistungsverhalten musste ich darüber hinaus folgende Änderungen vornehmen:

• Überspringen von Bildern erlauben
• Verstärktes Überspringen von Bildern erlauben
• Threads zur Dekodierung (MPEG-1/2 und H.264): 2
• Loop-Filter: Überspringen (nur bei HD-Videos)

Deinterlacing kann ich sogar aktiviert lassen. Und so sieht jetzt die Auslastung beim Misery-Schnipsel aus:



(CPU-Auslastung beim Abspielen von Misery-Schnipsel.rec (67,4 MB) in SMPlayer 0.6.9+SVN-r3597)

So soll es sein, nicht wahr? :

Er meinte wohl eher die Codec Informationen, nicht die "Verpackung"
1920x1080i h264 50fps main profile ...

Ah, ok; ich bin eben ein echter Fachmann auf dem Gebiet. Zur Ergänzung: Die Informationen stehen auch im Screenshot von Post #6, nur für einen anderen Film. Der Sender TNT Film HD scheint aber alles auf die gleiche Weise auszustrahlen.

Herzlichen Dank für deinen fachkundigen Rat, jkIT, mit dessen Hilfe das Problem tatsächlich gelöst werden konnte! Ich begann den Mut zu verlieren, nachdem ich in der Zwischenzeit eine weitere Handvoll Player mit Dutzenden verschiedener Einstellungen probiert hatte - alles ohne Erfolg. Danke auch an die anderen Ratgeber hier, allen voran an hagge.

Ich werde mich jetzt zufrieden zurücklehnen und heute Abend einen HD-Film am TV genießen, der flüssig über HDMI vom Notebook kommt. Wahrscheinlich Misery.

Und dann muss ich noch darüber nachdenken, ob ich Win 7 auf dem Notebook neu aufsetze - bei dem Installations-Overkill, den es in den letzten Tagen erfahren hat. Aber vielleicht lasse ich das lieber.

Schönes Wochenende. Jippieh!

nilssohn

[JayTee]

Na denn,


herzlichen Glückwunsch.

[jkIT]

Gern geschehen, es freut mich, dass das klappt . Dann kann man den Entwicklungszweig ja im Auge behalten.

[nilssohn]

Es gibt einen neuen Build der experimentellen Version des SMPlayers, die Mehrkernprozessoren unterstützt, indem die Rechenlast auf mehrere Threads verteilt wird: 3604 statt bisher 3597.

Download hier. Leider ist es mir nicht gelungen, ein Changelog zu finden. Ich habe das Gefühl, dass die regelmäßige auftretende leichte Ton-Asynchronität bei der Wiedergabe von HD-Recs mit der neuen Version geringer geworden ist. Kann aber nicht ausschließen, dass ich mir das nur einbilde, weil ich es mir wünsche.