x264 mittels GPU Unterstützung encodieren

fuh

Lt. Junior Grade
Registriert
Dez. 2007
Beiträge
465
Hi Leute,

ich encodiere Sachen mittels x264 (x64) von der Kommandozeile aus. Ich schaffe mit meinem Q6600@3,0GHz 18fps, also dauert schon seine Zeit, bis er da was durchwürgt.
Meine Frage: Kann ich meine Grafikkarte in den Encoding Prozess mit einbinden? Finde per Google nur viele Links zu uralten Einträgen bei doom9.

Danke für Hilfe
 
Nein, sowas ist nicht in x264 implementiert. Solche Anfragen gab es mal an die Entwickler (höchst wahrscheinlich die von dir gefundenen Posts bei doom9), aber die haben andere Prioritäten (Qualität, und anscheinend stagniert die Entwicklung, da sie nicht sehr viele Entwickler sind). Außerdem würde GPU-Beschleunigung anscheinend einen großflächigen Rewrite nötig machen.

P.S.: Außerdem bist du mit deinen 18fps gut bedient. Wenn ich HD-Content mit maximalen Einstellungen (also beste/langsamste Bewegungssuche etc), komme ich teilweise auf nichtmal 2 fps. Bis da 90 Minuten gelaufen sind, vergeht schonmal ne Nacht... ;)
 
Zuletzt bearbeitet:
Jo, das kenne ich, allerdings steht bei den Ausgabe Formaten für Ton nur AAC-LC (2 channel). Das ist der erste Harken und der zweite ist, dass ich kein MP4 Video erstellen will, sondern ein h.264 Video im MKV Container.
Sieht für mich eher nach einem Konverter für Handyvideos aus. Für zu archivierende Filme ist das nicht zu gebrauchen.
 
du hast nach einem GPU beschleunigten x264 encoder gefragt und nicht nach audioformaten ;)
zudem kann man so ziemlich alles in einen mkv container packen...
 
Also wenn Du so geringe fps schaffst, dann hast Du entweder ein HD-Video das Du kodierst, oder einige ganz fette Optimierungen eingeschaltet (trellis, psy).

Ich schaffe bei Videos in PAL-Auflösung mit meinem Athlon II X4@2,8GHz ohne trellis zwischen 30 und 60 fps (inkl. denoise und decomb oder deinterlacer-Filter). Mich würde da mal Deine Kommandozeile interessieren.

Zum Thema: Ich habe mal Badaboom ausprobiert. Damit schaffe ich auf einer GTX260 bis zu 85fps bei einem Video in PAL-Auflösung. Die Bildqualität ist aber deutlich schlechter als mit x264. Das sieht man sofort schon nach wenigen Filmsekunden mit bloßem Auge. Außerdem beherrscht das Programm kein cropping und kann nicht mehrere Audio-Spuren einbinden.

Andere GPU-Lösungen interessieren mich auch ....
 
bisher unterstützt x264 sowas noch nicht.
Aber eins der Projekte für den Summer of Code 2010 ist eine GPU-beschleunigte Bewegungssuche.
Siehe hier: klick

könnte also sein, dass sich bald zumindest eine teilweise GPU-Unterstützung gibt.
 
Ja es handelt sich um 1080p Material.

Manches davon liegt sogar schon x264 codiert vor, allerdings im 2Pass Verfahren und daher mit relativ hoher Dateigröße. Diese Sachen möchte ich gerne in crf20 umcodieren.
Aber wenn das mit GPU nicht geht, bzw das Ergebnis massiv leidet, werde ich mich eben gedulden

Meine Kommandozeile sieht so aus:
Code:
x264.exe --crf 20 --level 4.1 --b-pyramid normal --me umh --ref 5 --thread-input --no-fast-pskip --output out.mkv in.mkv
 
Zuletzt bearbeitet:
fuh schrieb:
allerdings im 2Pass Verfahren und daher mit relativ hoher Dateigröße.

Was hat denn das eine mit dem anderen zu tun? Die Dateigröße ist ganz allein von der Länge und der Bitrate abhängig. Die Anzahl der Passes spielt keine Rolle.
 
twix schrieb:
Was hat denn das eine mit dem anderen zu tun? Die Dateigröße ist ganz allein von der Länge und der Bitrate abhängig. Die Anzahl der Passes spielt keine Rolle.

Es hat somit damit zu tuen, dass eben eine konstante Bitrate von 12,5 MBit/s gewählt wurde, die einfach bei manchen Szenen quatsch ist.
Und es hat außerdem damit zu tuen, dass CRF quasi 2Pass ohne 1Pass mit variabler Bitrate ist.
 
2Pass impliziert doch, dass CBR verwendet wird. CRF hat nur einen Pass
 
Nö, bei ABR werden normal mehrere Passes angewendet. Im ersten Pass wird analysiert um die bestmögliche Verteilung der Bitrate bei einer festgelegten Zielgröße zu gewährleisten und im zweiten Pass wird dann encodiert.
Ehrlich gesagt wusste ich gar nicht, dass man auch CBR Encodes mit mehreren Passes machen kann. Was für einen Vorteil bringt das denn bei einer konstanten Bitrate?
 
Zuletzt bearbeitet:
Hallo!

@twix, da war ich wohl zu langsam wollte gerade das gleiche schreiben :)

Also ich kenn auch nur CBR -> Single Pass, 2Pass/3Pass -> ABR

2Pass sollte wenns ordentlich gemacht wurde, bei gleicher Dateigrösse immer besser sein als Single Pass. Wozu also die Filme nochmals umrechnen, wo diese Neukodierung zusätzlich zum eh schlechteren Single Pass nochmals die Qualität reduziert ?
 
Muss mich entschuldigen habe CBR und ABR gerade auf eine Stufe gestellt. Klar ihr habt schon recht. CRF hat auch nur einen Pass, weil eben dieser Analyse Pass von ABR wegfällt.

Und ich wandle die Filme ja nicht um indem ich CBR benutze, sondern ich wandle die FIlme mit dem CRF Setting, sprich festgelegte Qualitätsstufe und variable Bitrate. Da ich die Filme auf Festplatte lagere und nicht brenne spielt für mich eine Zielgröße keine Rolle. Deswegen wandle ich sie um.
 
Mediacoder bietet wie Badaboom auch Cuda Unterstützung für H264. Dabei können alle Audioformate und Container genutzt werden.
 
Zurück
Oben