Problem mit Freemake und Cuda seit Version 270.61

[BigI]

Hallo Gemeinde,

Seitdem ich die neue Treiberversion von Nvidia installiert habe (Version 270.61), habe ich ein
Problem mit den Freemake Video Converter.
Wenn man Cuda für das Konvertieren von Videos einschaltet, dann stürzt das Program
unmittelbar nach Start des Konvertiervorganges ab.
Ohne Cuda funktioniert das Konvertieren problemlos.

Ich habe eine EVGA GTX 460 SC, und konvertiere Videos von MPEG nach AVC.
Ich benutze die neueste Version des Freemake (2.1.3.1) aber auch mit der vorherigen
Version (2.1.1) habe ich das selbe Problem.
Vor dem Installieren des neuen Treibers funktionierte alles einwandfrei.

Weiß jemand Rat ?

Danke

 

[De-M-oN]

Der beste Rat ist es nicht CUDA zu benutzen zum encodieren...

https://www.computerbase.de/forum/t...ng-konvertieren-aber-wie.872185/#post-9557413

Er schreibts recht deutlich warum.

 

[boxleitnerb]

Hat jemand Benchmarks zu so ein paar Programmen? Also Freemake u.a.

Ich kann mir nicht vorstellen, dass man da nicht soviel parallelisieren kann. Kann man das nicht tile-basiert machen und das Bild in kleine Stückchen aufteilen? Oder das ganze Video in Häppchen?

Und ist die Qualität inzwischen immer noch so schlecht im Vergleich zu CPU-Encoding? Woran liegt das? Müssen die Algorithmen einfach noch reifen oder ist das eine technische Limitierung?

 

[powerfx]

Benches findest du, wenn du damit nach Badaboom suchst, da es wohl der bekannteste CUDA-Codierer ist.

Kann man das nicht tile-basiert machen und das Bild in kleine Stückchen aufteilen? Oder das ganze Video in Häppchen?

Theoretisch schon. Aber nicht bei heutigen Codecs wie AVC, da dort alles zusammenhängt. Ohne die Ergebnisse von anderen "Stückchen" oder Bildern (in GOP) kann man die restlichen nicht berechnen...

Und ist die Qualität inzwischen immer noch so schlecht im Vergleich zu CPU-Encoding? Woran liegt das? Müssen die Algorithmen einfach noch reifen oder ist das eine technische Limitierung?

Eine technische Limitierung gibt es nicht. Es ist nur so, dass GPUs etwas anders rechnen als CPUs (das Ergebnis ist aber selbstverständlich identisch!).
Würde man den selben Code, also die selben Algorithmen, auf die GPU verlagern, wäre die Berechnung langsamer, da sie einerseits nicht angepasst ist und zum anderen die Compiler noch weit vom dem Stand der CPU-Pendants entfernt sind.
Möchte man also die gesamte Codierung auf die GPU verlagern, muss man andere Algorithmen wählen, um einen (Performance-)Vorteil durch die GPU-Architektur zu erzielen. Diese können aber rein qualitätstechnisch nicht mit konventionellem CPU-Encoding mithalten.

 

[Struppi0815]

Ich habe das Problem mit der Treiberversion 270.61 ebenfalls. Mit der letzten WHQL-Version lief es noch problemlos. Hab mich mit dem Problem an den Freemake-Support gewandt, eine Antwort steht noch aus.

Der Beitrag, warum man CUDA nicht zum Wandeln von Videos verwenden sollte, ist echt für die Tonne. So einen Schwachfug hab ich ja noch nie gehört, ich weiß nicht ob ich lachen oder den Verfasser des Beitrags bemitleiden soll.

OK, das mit der schlechteren Qualität WAR mal. Ich muss sagen, mit Freemake sehen die Videos richtig ordentlich aus. FULL HD, 720p ... man muss nur den Converter richtig konfigurieren und sich Zeit nehmen um das beste Ergebnis zu erzielen. So wenig Speicherplatz wie möglich bei der bestmöglichen Qualität. Das ist mit Freemake und CUDA auf jeden Fall möglich.

Die Behauptung, dass eine CPU genauso schnell oder gar schneller berechnen soll ... naja, ich hab da gegenteilige Erfahrungen gemacht. Mit CUDA spart man locker 2/3 der Zeit zum Wandeln.
Voraussetzung dafür ist natürlich ein ordentlicher Grafikbeschleuniger, also keine 8600 oder 9400 oder 9600 ... alles Taschenrechner. Ich habe eine GTX 560ti von Gainward in der Golden Sample Version. Die hat 384 Shadereinheiten und ist bei der Berechnung 3x schneller als eine 8800GT mit 112 Shadereinheiten.

Also, wer mit ner 8600 GT oder so mit CUDA anfängt, wird den Geschwindigkeitsvorteil nicht so mitbekommen. Das hängt damit zusammen, dass die 8400 und 8600GT nicht so viele Stream-Prozzis besitzen. Je mehr Stream-Prozzis, umso mehr geht die Post ab mit CUDA.

Ich kann mir vorstellen, dass man mit einer 590er NVIDIA richtig Spaß mit CUDA hat. Sofern man einen Geschwindigkeitsvorteil bemerkt. *lol*

Ich arbeite schon seit der Einführung mit CUDA. Es hat sich eine Menge getan in Sachen Geschwindigkeit und Performance. Und es wird immer besser. Es lebe CUDA ...

 

[De-M-oN]

Der Beitrag, warum man CUDA nicht zum Wandeln von Videos verwenden sollte, ist echt für die Tonne. So einen Schwachfug hab ich ja noch nie gehört, ich weiß nicht ob ich lachen oder den Verfasser des Beitrags bemitleiden soll.

Am besten einfach nichts schreiben^^

"Tom Keller" zu unterstellen er würde sich nicht auskennen oder Müll labern ist mal echt ein Jahrhundertfail.

OK, das mit der schlechteren Qualität WAR mal. Ich muss sagen, mit Freemake sehen die Videos richtig ordentlich aus. FULL HD, 720p ... man muss nur den Converter richtig konfigurieren und sich Zeit nehmen um das beste Ergebnis zu erzielen. So wenig Speicherplatz wie möglich bei der bestmöglichen Qualität. Das ist mit Freemake und CUDA auf jeden Fall möglich.

An der Effizienz und Qualität von x264 wird das NIEMALS !!! (!!!) !!! rankommen.

So wenig Speicherplatz wie möglich bei der bestmöglichen Qualität. Das ist mit Freemake und CUDA auf jeden Fall möglich.

Ne mit CUDA ganz bestimmt nicht.
Dem x264 Encoder kann bisher keiner das Wasser reichen und x264 benutzt ganz bewusst KEIN CUDA.
Und die Entwickler planen auch in keinsterweise Support dafür einzubauen, eben weils NICHT besser ist.

Die Behauptung, dass eine CPU genauso schnell oder gar schneller berechnen soll ... naja, ich hab da gegenteilige Erfahrungen gemacht. Mit CUDA spart man locker 2/3 der Zeit zum Wandeln.

Du hast scheinbar nicht verstanden warum.

Ich arbeite schon seit der Einführung mit CUDA. Es hat sich eine Menge getan in Sachen Geschwindigkeit und Performance. Und es wird immer besser. Es lebe CUDA ...

Es lebe x264. Und du hast offensichtlich noch nicht ernsthaft mit x264 gearbeitet, andernfalls würdest du CUDA nicht so lobhuldigen.

 

[Struppi0815]

Ich hab mich grad mal belesen. Von einem "Unterschied" zwischen H.264 und x264 kann man nicht wirklich sprechen. Denn es handelt sich um zwei unterschiedliche Sachen. Das eine ist der Standard zur Videokompression, das andere ist ein Encoder, der Daten gemäß dieses Standards kodiert. Also ist X264 lediglich das Programm, mit dem auch nur der h.264-codec benutzt wird. Das allerdings ohne Hardware-Unterstützung und somit stundenlange Energieverschwendung ... Hab keinen Bock für einen 1,5h - Film den halben Tag den Rechner laufen zu lassen. Das geht mit CUDA doch wesentlich fixer. Und die Programme, die die Hardware unterstützen, werden auch immer besser.

Aber wer die Zeit hat ... und nen günstigen Energielieferanten ... kann auch seine CPU quälen. Ich lass die GraKa arbeiten und schaff so einen 1,5h - Film in etwa 25-30 Minuten. Bei guter Qualität.

 

[powerfx]

Ich hab mich grad mal belesen. Von einem "Unterschied" zwischen H.264 und x264 kann man nicht wirklich sprechen. Denn es handelt sich um zwei unterschiedliche Sachen. Das eine ist der Standard zur Videokompression, das andere ist ein Encoder, der Daten gemäß dieses Standards kodiert.

Das stimmt zwar, ist hier aber nicht von Bedeutung, da einen solche Vergleich niemand angestellt hat (oder habe ich was überlesen?).

Eine Abwandlung davon trifft es aber sehr genau: Man kann x264 nicht mit CUDA vergleichen, da das eine ein Encoder ist, das zweite aber eine Architektur. Hat nichts miteinander zu tun.
Man könnte aber x264 auf CUDA portieren. Dann wäre es zwar momentan langsamer, da der Code für x86 optimiert ist, aber wie lange noch? Die Performance von GPUs ist in letzter Zeit viel schneller angestiegen als die von CPUs. Geht das so weiter, könnte irgendwann x264 auf CUDA tatsächlich schneller laufen als auf x86...

 

[De-M-oN]

Struppi: Du vergisst das sich die Encoder aber qualitativ unterscheiden.

MainConcept z.B. kann bei weitem nicht mit x264 mithalten. Es mangelt extrem an Einstellungen und allgemein ist der x264 einfach viel effizienter bei gleicher Bitrate. Allein schon wegen dem CRF Encodiermodus hebt sich x264 ab, denn wenn ich jetzt nicht falsch liege, hat MainConcept nicht mal CRF Modus.

Hab keinen Bock für einen 1,5h - Film den halben Tag den Rechner laufen zu lassen

Dann ist wohl deine CPU etwas alt oder du benutzt kein x264.

Also Videomaterial aus einem Spiel (was viel viel komplexeres Videomaterial darstellt, als ein Spielfilm aufgrund der Schärfe, Detailvielfalt und ständig komplett wechselnden Bildern in Spielen, vor allem Autorennen und mein Beispiel bezieht sich auf ein Autorennspiel) in 2048x1152 @ 30fps , 1std 20min Video hab ich mit einem Intel Quadcore Q9450 und einem noch 32bit XP (was extrem x264 ausbremst. x264 arbeitet mit 64bit nochmal deutlich schneller) mit MeGUI mit dem x264 Preset slow und --partitions all Parameter @ CRF 21 eine Encodierzeit von ca. 3 - 4std.

Und preset slow ist alles andere als ein schnelles Preset. Da ist x264 schon sehr intensiv eingestellt.

Diese gleiche Qualität die da mit dem preset rauskommt, würde mit anderem als x264 niemals rauskommen, zumal es diese Einstellungen gar nicht erst gibt.

 

[Struppi0815]

Ich habe jetzt den Treiber der Version 266.77 installiert. Ich warte bis ein neuer WHQL-Treiber erscheint.

 

[powerfx]

Du hast ja den Thread am 21.04. eröffnet.
Am 27.04. ist Freemake VC in Version 2.1.4 erschienen. Hast du die schon versucht? Vielleicht behebt sie das Problem...

 

[Struppi0815]

Ich habe es mit allen Versionen ab 2.1.1, also auch mit 2.1.4 versucht. Immer hat das Programm nach dem Beginn des Wandelns abgebrochen.

 

[De-M-oN]

Dann benutz x264, es ist einfach besser

Mainconcept und alle anderen H.264 Encoder auch können einfach bei weitem nicht mit der Effizienz von x264 mithalten...

Aber du scheinst ja echt weniger Wert auf Qualität zu legen und mehr wert auf deinen akuten Zeitmangel.

 

[Struppi0815]

RIIISCHTIIISCH @ De-M-oN

Es soll ja auch nicht in Arbeit ausarten ... :-)