Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Handbrake auf MacPro: 12fps -- Was ist da los?

Handbrake auf MacPro: 12fps -- Was ist da los?

MaChris
MaChris02.03.0721:24
Hallo Leute,

wenn ich auf meinem MacPro (Standardkonfiguration) Handbrake mit dem h.264 Codec arbeiten lasse bricht die Konvertierungsrate von ca. 60fps ziemlich schnell auf ca. 12fps ab.

Wenn ich die MPEG4-Codierung mache scheint es konstant bei etwa 90fps zu laufen.

Hat jemand einen Tipp für mich, was das Problem sein könnte?

BTW: Ist h.264 eigentlich soviel besser als MPEG4?
0

Kommentare

v3nom
v3nom02.03.0722:15
Kann gut sein das der h.264 Codec soviel Leistung braucht um einen Film zu komprimieren. Ist auch einer der leistungsstärksten Codecs die es zur Zeit gibt!
Versuch doch in Xvid oder Divx zu kodieren...
0
Tobsen
Tobsen02.03.0722:21
Also ich schaff 18-25 Frames, je nachdem, wie groß das quellmaterial ist.

Hast du HandBrake oder Mediaforke?
0
Globox
Globox02.03.0722:24
MaChris
Habe auch Mac Pro mit 2.66 GHZ und da ist das Verhalten von Handbrake genauso. Ich vermute aber, dass es an dem Programm liegt. H.264 müsste schneller codiert werden.
0
MaChris
MaChris02.03.0723:51
Mein iMac Core Duo 2.0 brachte es immerhin auf 25fps... Geht wirklich um h264 mit HandBrake...

Auf mich wirkt es irgendwie so, als würde das ganze auf nur einem Core laufen...
0
Globox
Globox03.03.0700:19
MaChris
Das kann durchaus sein.
0
oefinger
oefinger03.03.0700:49
selbst auf einem Core müsste das deutlich mehr als 12 fps liefern (zum Vergleich, ein PPC mini schafft um die 5). Kommen die Daten direkt von DVD oder sind die auf Platte "geriped"?
0
MaChris
MaChris03.03.0708:43
Die Daten liegen auf externer (USB-)Platte und werden auf die interne HDD gespeichert. Habe auch schon von interner Platte auf interne Platte probiert, macht keinen Unterschied.

Ach ja, ich hatte auch noch ein besonders nerviges Symptom nicht erwähnt: Bei den "langsam" codierten Filmen bricht irgendwann mittendrin der Ton weg und der Rest des Films ist Mute...

Kommt das evtl. jemandem bekannt vor?
0
julesdiangelo
julesdiangelo03.03.0709:37
Also h.264 ist extrem abhängig von den Einstellungen. Habe nur mal auf meinem Athlon64 3000+ einige Einstellungen getestet, dabei schwankte die Konvertierungsrate von 3 bis 30 fps. Qualitativ war dazwischen auch ein deutlicher Unterschied zu sehen. Und, ja, h.264 hat mich wesentlich mehr überzeugt als Xvid. Bei gutem Quellmaterial und einer nicht allzutiefen Bitrate blieben viel mehr Details erhalten. Auch ähnlichfarbige Flächen waren weniger von Blöckchen durchzogen. Beide Codecs neigen aber dazu, das Bild sehr klinisch aussehen zu lassen. Grobkörnigkeit ode rleichter Rausch geht komplett verloren. Es sei denn man arbeitet bei relativ hohen Bitraten. Aber dann muss es auch nicht unbedingt h.264 sein.
„bin paranoid, wer noch?“
0
julesdiangelo
julesdiangelo03.03.0721:25
Ich dachte die Weichzeichnung kommt durch die discrete cosinus transformation.
„bin paranoid, wer noch?“
0
MaChris
MaChris04.03.0702:01
Ah ja. Leider kein Wort verstanden...
0
julesdiangelo
julesdiangelo04.03.0707:13
agrajag sagt damit, dass er seine Backups mit einem falschen Seitenverhältnis (Bild ist zu hoch) speichert, und einen extra entzerr Faktor in die Datei mit einspeichert, die der Player versteht, und das Bild entsprechend breiter macht.

Wenn Handbrake keine anamorphe Conversion versteht würde ich aber wirklich ffmpegx benutzen. Da gibt es das Problem nicht.
„bin paranoid, wer noch?“
0
Globox
Globox08.05.0720:28
MaChris
Das Problem mit dem Ton habe ich auch. Immer, wenn ich die Film in H.264 konvertiere, kommt es ab und zu vor, dass er Ton nach der ca. Hälfte weg ist.

Würde auch gerne mal wissen, ob noch jemand dieses Problem hat und ob es dazu schon Lösungsvorschläge gibt.
0
Moe99999
Moe9999903.03.0700:26
bei mir kann ich mit handbrake garnicht in h264 rippen
„42“
0
Agrajag03.03.0713:21
Schade, daß 3ivx immer noch nicht Intel-tauglich ist. 3ivx versucht alle Details zu bewahren, benutzt also keinen Weichzeichner vor der Komprimierung. Allerdings sorgt es tendentiell für etwas größere Dateien als Xvid und DivX.
0
Agrajag04.03.0700:02
Wenn ich es richtig verstanden habe, dann benutzt Divx ein Weichzeichner, um bessere eine Kompression zu erreichen. Allerdings gehen dabei auch feinere Details flöten. Wirklich tief habe ich mich damit aber nicht beschäftigt, weil mir 3ivx immer die Ergebnisse geliefert hat, die ich haben wollte. Da es kein 3ivx für Intel-Macs gibt und das MBP schnell genug ist, benutze ich seit einer Weile h264. Das Problem mit dem (nicht vorhandenen) PAR bei Handbrake löse ich, indem ich das verzerrte Bild nehme. Das Video jage ich anschliessend durch Matroska und geb den korrekten Entzerrfaktor mit. Das gibt schön große Bilder.
0
Agrajag04.03.0718:48
ffmpegx kann nur mur mit einer Audiospur (einigermaßen handhabbar) umgehen. Den Schritt über Matroska mache ich ohnehin, so daß es für mich kein Umweg darstellt. Außerdem bin ich mir manchmal nicht sicher, was ffmpegx wirklich für eine Auflösung erzeugt. Erstellt er mir nur (wie ich es haben möchte) einen PAR und zeigt mir die endgültige Größe an, oder erzeugt er mir von vorne herein ein Video in der großen Auflösung an? Letztere würde zumindest größere Dateien verursachen.

VLC zeigt mir bei, mit Handbrake und Matroska erzeugten, Filmen mit PAR die tatsächliche Videoauflösung (nicht die korrigierte, angezeigte Auflösung) an. Bei Filmen, die ich mit ffmpegx erstellt habe (nur kurz probiert), bekomme ich die dargestellte Größe angezeigt – oder ist das auch die tasächliche Videoauflösung? Dann wäre sie unnötig hoch.

Der Workflow mit h264 erscheint mir bisher mit Handbrake und Matroska am einfachsten zu realisieren. Mit 3ivx hatte ich DiVA und Matroska benutzt.
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.