GT 730 vs. GTS250 - wo liegt der Cuda Flaschenhals?

[Peterxy]

Nutze zum H.264 encoden einen CUDA frameserver, der vereinfacht gesagt über die GPU der CPU das dekodieren + rezisen abnimmt, das eigentliche encoding verläuft hingegen weiter über die CPU.

im laufe der Zeit hatte ich einige nvidia Karten unter dem Cuda Frameserver genutzt, aufgefallen ist mir dabei folgendes
GTs 250 (aka GTx9800)
GT 460
GTX 660
= allesamt gleiche Leistung.

Da der Stromverbrauch einer GTS250 mich stört war eine GT 710 eingezogen, die entlastet aber nur marginal die CPU beim dekoding und die Encoding Leistung ging damit folgerichtig um 20% in den Keller, daraufhin wurde gegen eine GT 730 ausgetauscht - die aber auch langsamer als die alte GTS250 ist.

Finde ich eigentlich unlogisch da die GT 730 immerhin 396 Cuda Recheneinheiten hat, die GTS 250 hingegen nur 128.
Wo liegt da der Flaschenhals bei diesen kleineren 7xx/Kepler Karten zu so ner ollen GTS250?

[blinki]

Also mal bei Wikipedia gestöbert:
GTs 250: ddr3 256bit Speicherinterface PCI2.0 VP2.

Gt730 gibt es in drei versionen. Da du von 384 Shadern sprichst hast du entweder ddr3 oder ddr5
Speicher an einem 64 bit interface. Beide sind mit PCI2.0 x8 ausgewiesen (!?) VP5.

Gt710 ddr3 64 bit, PCI2.0 x8 VP5

Ich würde sagen 1. Speicherinterface zu langsam und 2.PCI-Express Anbindung zum Prozessor zu langsam. Dass die neueren Generationen dann bessere Speichercontroller mit mehr Cache haben scheint da nichts zu bringen, die Rohbandbreite reicht nicht. Verhältnis Rechenaufwand/Ubertragungsleistung ist halt bei dieser Aufgabe zu gering.

[Peterxy]

Ja, ist die GDR5 Variante die mit 40Gb/s Bandbreite angegeben ist,
die GT 710 hingegen mit nur 12gb/s oder so.
Alleine schon wg. der höheren Speicherbandbreite + doppelt soviel Recheneinheiten, hätte ich zumindest zwischen der Gt 710 + Gt 730 einen Unterschied erwartet, der ist aber faktisch zwischen den beiden Karten nicht gegeben. (sind beide bis auf 1-2FPS Unterschied letzlich gleich "lahm" unterm dem Cuda Frameserver)

Beide Karten sind allerdings auffälligerweise auch PCEi x8 wie du schon sagtest und ev. liegt da der Flaschenhals?
(obgleich es ja oft heißt der Unterschied bei PCIe 2.0 wäre zwischen 8 und 16x in der Praxis angeblich zu vernachlässigen, nur inwieweit sowas stimmt wohl andere Sache)


Hatte mich auch schon nach ner Alternative umgesehen,
leider scheints da nix stromsparendes +leises in LowProfile mit mehr Bandbreite zu geben. :(

[Schrotti]

Vielleicht eine GT 1030 in Betracht ziehen.

https://www.notebookcheck.com/Test-Zotac-GeForce-GT-1030.223524.0.html

PS: Habe ich hier sogar noch zu liegen, so zum basteln.

[Peterxy]

Habe leider nur eine Windows XP Lizenz für den Cuda Frameserver und bin folglich auf eine XP kompatible Graka angewiesen.
Neben dem Low Profile System mit dem XP habe ich zwar auch noch einen PC mit Win7/10 und hatte dafür auch eine Win7 Lizenz, nur nützt mir das nichts, weil diese Lizenzkeys irgendwie an die Mainboard-ID verankert sind.
(oder mit anderen Worten, spätestens wenn man das Mainboard wechselt ist der Lizenzkey nix mehr wert :freak: )

D.h. selbst wenn ich Win7 auf dem PC aufspiele, hilft mir der vorhandene Win7 Key nicht - weil anderes Mobo. Die einzigste Möglichkeit wäre erneut einen Lizenskey kaufen - da der Entwickler der Software aber eine ziemlicher Freggel ist, bin ich nicht gewillt da jemals wieder auch nur 1cent auf den Tisch zu legen.


PS: Habe ich hier sogar noch zu liegen, so zum basteln.
Hast du zufälllig vielleicht auch irgendwas in Richtung Gt660, Gt750 o.ä. in Low Profile noch rumliegen? :smile:

[Schrotti]

Nee leider nicht.

[Peterxy]

Wie sieht es alternativ mit übertakten einer GT730 aus?
Hab div Programme schon durchprobiert (nv inspector, afterburner etc.), es läßt sich zwar Speichertakt und jenach Tool auch die vcore ändern, komischerweise aber nicht der GPU Takt.
Der GPU Takt geht nur um 100mhz zu senken und macht schon paar FPS aus, daher gehe ich mal davon aus das eine Takterhöhung auch was bringen könnte, dummerweise geht der Takt aber nicht nach oben zu verstellen, die Taktrate bleibt fix bei 954Mhz.

Sind diese kleinen Kepler Karten irgendwie gegen Übertaktung gelockt und wie hebt man die Sperre auf?
(hatte schon versucht über GPU-Z das Bios abzuspeichern, selbst das geht nicht und kommt nur die Meldung "Bios reading not supported" :freak:)

[Screemer]

um welche software handelst es sich denn bitte?

[Peterxy]

Jeweils die neusten Version - hatte nvidia inspector, MSI Afterburner, Asus GPU Tweak, sowie das Gainward OC Tool und halt das der Graka beiliegende KFA2 Tool ausprobiert. Mit allen tools dasgleiche, man kann zwar einen höheren Takt in den Tools einstellen, der offenkundig auch angenommen wird (stellt man einfach mal +1000mhz ein, friert schließlich auch der bildschirm ein)

Das Ding dabei ist allerdings, das dieser anscheinend angenommene Takt (im Screenie 1054mhz) nicht bleibt - denn loggt man den GPU Takt mit, sieht man sobald man eine 3d lastige Anwendung aufruft, das der Takt dennoch bei 954Mhz bleibt bzw. auf diese "serienmässigen" 954mhz einfach zurückgesetzt wird. :frown: (lediglich der Speichertakt bleibt erhöht)

http://fs1.directupload.net/images/171118/temp/ewbhjvwk.jpg (http://www.directupload.net/file/d/4910/ewbhjvwk_jpg.htm)

Voll seltsam das übertakten mit der Gt730, ebenso das man den Takt lediglich um -105mhz absenken kann und an den Tools liegt das imo nicht, denn die GTX660 ist doch auch Kepler und mit der funktioniert das mit dengleichen Tools alles "uneingeschränkt" ohne jegliche Probleme.

In den Energieoptionen hatte ich schon prefer max. Performance statt adaptive eingestellt, ändert aber auch nix.

[Screemer]

ich meinte mit "um welche software handelt es sich" den frameserver. vielleicht kann man dir problemlos eine alternative empfehlen, die mit nem moderneren unterbau als winxp (:eek:) läuft.

[Peterxy]

Ach so, ist natürlich dieser Cuda Frameserver, imo ist es auch das einzigste Tool am Markt:
https://www.videohelp.com/software/DGDecNV

Nutze die Software schon seit 6Jahren und ist ne super Sache, der Support hingegen das allerletzte.
Theoretisch kann man 16x den Lizenzschlüssel neu generieren, in der Praxis sah es dann aber so aus - das nach Zeitraum X die Daten einfach aus seinem System "verschwinden" = also darf man nochmals zahlen. (das hat seine Gründe wieso man die Software nicht auf regulärem Wege bezahlen kann, sondern nur per "Paypal Spende" - denn bei gespendeten Geld hat man keinen Käuferschutz o.ä. )
Nur ich persönlich sehe das nicht länger ein, nun ein viertes mal registrieren + erneut einen Schlüssel bezahen, nur weil bei dem die Datenbank "gernemal" rumspinnt.

Tja, nur dummerweise ist die Software alternativlos.
Ergo irgendeine bessere Low Profile Grafikkartenlösung finden u./o. schauen, was die GT 730 abliefert wenn sie sich übertakten liesse.

[Screemer]

alternativlos für was ist die frage. tools zum loosless decoden und resizen mit gpu-beschleunigung gibts doch wie sand am meer. moderne varianten nutzen auch kein cuda sondern entsprechende hardwaredecoder in den gpus.

was ist denn dein genaues anwendungsprofil (codecs, encoding software, etc.) und welche hardware soll genutzt werden? ist die 730 noch vorhanden?

[Peterxy]

Welche Tools sollen das denn sein?
Also unter Win7 64bit habe ich einige sogannte "GPU unterstützte Converter" probiert und hatte zumindest keine Lösung gefunden, was bei gleichen Encoding Settungs geschwindigkeitsmässig an die bisherige Combi rankam (Cuda Frameserver -> avisynth ->vdub)
Mit dem Cuda Frameserver brauchst du nur das video in vdub laden, automatisch die Balken wegschnibbeln lassen und los gehts. :)
Sachen von paar Sekunden (sieht man von dem indixeren ab)
Über x.264.exe/ cli geht zwar auch hardwareseitig GPU/Cuda dekoding per switch (worauf div Tool vermutlich auch aufsetzen) und mit dem ganzen über FFMPeg o.ä. gehen, das ist unkomfortabel wenn du viel TV Aufnahmen hast (ist obendrein nichtmal schneller jenachdem wie auch das interlacing da gehandhabt wird /ob per CPU oder GPU).

Ausgang sind 1080i TV Aufnahmen in H.264, die auf H.264 in 720p runterkonvertiert werden.
Und ja, die GT 730 ist noch vorhanden, zumal ich noch die Hoffnung habe wenn man die übertaktet bekäm vielleicht die fehlenden 20% drin wären. Problem ist nur wie gesagt, das die auf den Serientakt zurücksetzt.

Das ist hier zwar für Linux, aber was ist mit diesem alten Coolbits + Powermizer Kram?
https://www.phoronix.com/scan.php?page=news_item&px=MTY1OTM

[Screemer]

LSMASHSource als source plugin für avisynth unterstützt durch die nutzung von ffmpeg ziemlich viele hardwaredecoder und ist nur ein beispiel. gibt ja noch viele weitere tools die auf ffmepg setzen.

https://trac.ffmpeg.org/wiki/HWAccelIntro

du kannst dir ja mal auf ner halbwegs modernen maschine mit der 730 staxrip ansehen und avisynth mit lsmashsource für das decoding nutzen. ffmpeg unterstützt auch CUDA/CUVID/NvDecode für hardwarebeschleunigtes decoding.

[Peterxy]

Das es über FFMEpg geht und dieser Hw switch besteht ist mir wie gesagt bekannt,
nur das ganze muß auch zu einem gewissen Grad komfortabel sein. (mit FFMPEg fängt das aber schon damit an, wenn man eine vernünftige GUI dafür haben will - die eine kann das, die andere das - aber so richtig gute GUis findet sich als Freeware eher nicht)
Staxrip, Avanti, WinFf & Co - die hatte ich mir schon angesehen.
Auch so wie Megui, Hybrid & so.

[Screemer]

wann angesehen? decode, crop, resize, recode können staxrip und handbrake z.b. alles in einem schwung. auch per batch-job. wo liegen da die unzulänglichkeiten der guis für dich?

das sind bisher die einzigen features die ich deinem anwendungsprofil entnehmen kann. du bist leider etwas sparsam mit deinen angaben.

[Peterxy]

Joa, Handbrake kanns in einem Schwung - das encoding ist da aber langsamer als über die DGencNV Variante. (CPU ist ein Thuban)
Mag sein, das mit Intel oder moderneren System sich anders verhält - nur, Geschwindigkeit verlieren ist nicht das Ziel. ;-)

du bist leider etwas sparsam mit deinen angaben.
Na ja, was heißt sparsam - per GPU soll ja auch nur folgendes gemacht werden:
- dekoding
- resize
- deinterlace
Und bei letzteren liegt ja schon der Haken, denn laufen Filter wie resize, deinterlace o.ä. per Handbrake über die GPU? Vermutlich nicht (muß ja einen Grund haben wieso es bei gleichen H.264 encoding settings langsamer ist)

[Screemer]

ich hab dieses sourcefile (https://doc-08-c4-docs.googleusercontent.com/docs/securesc/pavhnhuuaoop3pmg6rn0bq85a8m91vde/vspe83mnu5t59v57qrl3qn3vpv6g6nhj/1511020800000/10386144926023270212/06895506791222208548/0BwxFVkl63-lEbFBzak1sbmU1N0E?e=download&nonce=5u7jh6p2u7u82&user=06895506791222208548&hash=38c2p71sehg1u7cgd6987akltsdemn6r)mit ffmpeg (http://ffmpeg.org/download.html) mal neu gespeichert. resize, crop und deinterlace mit cuvid und anschließender reencode mit standardsettings von libx264 und audio nur copy:

ffmpeg -vsync 0 -c:v h264_cuvid -deint adaptive -crop 300x300x0x0 -resize 1280x720 -i source.mkv -c:a copy output.mkv
ffmpeg version 3.4 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 7.2.0 (GCC)
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth --enable-libmfx
libavutil 55. 78.100 / 55. 78.100
libavcodec 57.107.100 / 57.107.100
libavformat 57. 83.100 / 57. 83.100
libavdevice 57. 10.100 / 57. 10.100
libavfilter 6.107.100 / 6.107.100
libswscale 4. 8.100 / 4. 8.100
libswresample 2. 9.100 / 2. 9.100
libpostproc 54. 7.100 / 54. 7.100
Input #0, matroska,webm, from 'source.mkv':
Metadata:
encoder : libebml v1.3.3 + libmatroska v1.4.4
creation_time : 2015-11-21T15:17:33.000000Z
Duration: 00:01:00.12, start: 0.000000, bitrate: 14299 kb/s
Stream #0:0: Video: h264 (Baseline), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 1k tbn, 50 tbc (default)
Metadata:
BPS : 13974290
BPS-eng : 13974290
DURATION : 00:01:00.120000000
DURATION-eng : 00:01:00.120000000
NUMBER_OF_FRAMES: 3006
NUMBER_OF_FRAMES-eng: 3006
NUMBER_OF_BYTES : 105016794
NUMBER_OF_BYTES-eng: 105016794
_STATISTICS_WRITING_APP: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_APP-eng: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_DATE_UTC: 2015-11-21 15:17:33
_STATISTICS_WRITING_DATE_UTC-eng: 2015-11-21 15:17:33
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:1(eng): Audio: mp2, 48000 Hz, stereo, s16p, 320 kb/s (default)
Metadata:
BPS : 320000
BPS-eng : 320000
DURATION : 00:01:00.120000000
DURATION-eng : 00:01:00.120000000
NUMBER_OF_FRAMES: 2505
NUMBER_OF_FRAMES-eng: 2505
NUMBER_OF_BYTES : 2404800
NUMBER_OF_BYTES-eng: 2404800
_STATISTICS_WRITING_APP: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_APP-eng: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_DATE_UTC: 2015-11-21 15:17:33
_STATISTICS_WRITING_DATE_UTC-eng: 2015-11-21 15:17:33
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
File 'output.mkv' already exists. Overwrite ? [y/N] y
Stream mapping:
Stream #0:0 -> #0:0 (h264 (h264_cuvid) -> h264 (libx264))
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[libx264 @ 0000017ecc63bf80] using SAR=1/1
[libx264 @ 0000017ecc63bf80] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[libx264 @ 0000017ecc63bf80] profile High, level 3.2
[libx264 @ 0000017ecc63bf80] 264 - core 152 r2851 ba24899 - H.264/MPEG-4 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, matroska, to 'output.mkv':
Metadata:
encoder : Lavf57.83.100
Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), nv12, 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, 50 fps, 1k tbn, 50 tbc (default)
Metadata:
BPS : 13974290
BPS-eng : 13974290
DURATION : 00:01:00.120000000
DURATION-eng : 00:01:00.120000000
NUMBER_OF_FRAMES: 3006
NUMBER_OF_FRAMES-eng: 3006
NUMBER_OF_BYTES : 105016794
NUMBER_OF_BYTES-eng: 105016794
_STATISTICS_WRITING_APP: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_APP-eng: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_DATE_UTC: 2015-11-21 15:17:33
_STATISTICS_WRITING_DATE_UTC-eng: 2015-11-21 15:17:33
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
encoder : Lavc57.107.100 libx264
Side data:
cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
Stream #0:1(eng): Audio: mp2 (P[0][0][0] / 0x0050), 48000 Hz, stereo, s16p, 320 kb/s (default)
Metadata:
BPS : 320000
BPS-eng : 320000
DURATION : 00:01:00.120000000
DURATION-eng : 00:01:00.120000000
NUMBER_OF_FRAMES: 2505
NUMBER_OF_FRAMES-eng: 2505
NUMBER_OF_BYTES : 2404800
NUMBER_OF_BYTES-eng: 2404800
_STATISTICS_WRITING_APP: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_APP-eng: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_DATE_UTC: 2015-11-21 15:17:33
_STATISTICS_WRITING_DATE_UTC-eng: 2015-11-21 15:17:33
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
frame= 3006 fps= 80 q=-1.0 Lsize= 22545kB time=00:01:00.26 bitrate=3064.8kbits/s speed=1.61x
video:20155kB audio:2348kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.183493%
[libx264 @ 0000017ecc63bf80] frame I:23 Avg QP:22.25 size: 41207
[libx264 @ 0000017ecc63bf80] frame P:767 Avg QP:24.90 size: 15722
[libx264 @ 0000017ecc63bf80] frame B:2216 Avg QP:28.29 size: 3444
[libx264 @ 0000017ecc63bf80] consecutive B-frames: 1.3% 0.8% 1.6% 96.3%
[libx264 @ 0000017ecc63bf80] mb I I16..4: 15.1% 69.8% 15.1%
[libx264 @ 0000017ecc63bf80] mb P I16..4: 3.3% 6.5% 0.8% P16..4: 43.4% 10.6% 6.6% 0.0% 0.0% skip:28.8%
[libx264 @ 0000017ecc63bf80] mb B I16..4: 0.2% 0.4% 0.0% B16..8: 36.2% 1.9% 0.3% direct: 1.8% skip:59.1% L0:41.0% L1:54.7% BI: 4.3%
[libx264 @ 0000017ecc63bf80] 8x8 transform intra:63.1% inter:80.0%
[libx264 @ 0000017ecc63bf80] coded y,uvDC,uvAC intra: 41.1% 67.4% 24.5% inter: 9.4% 16.1% 0.7%
[libx264 @ 0000017ecc63bf80] i16 v,h,dc,p: 53% 10% 10% 27%
[libx264 @ 0000017ecc63bf80] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 7% 25% 5% 5% 10% 3% 8% 3%
[libx264 @ 0000017ecc63bf80] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 44% 6% 15% 5% 6% 12% 3% 7% 2%
[libx264 @ 0000017ecc63bf80] i8c dc,h,v,p: 49% 10% 33% 9%
[libx264 @ 0000017ecc63bf80] Weighted P-Frames: Y:8.0% UV:7.2%
[libx264 @ 0000017ecc63bf80] ref P L0: 61.0% 13.0% 19.0% 6.6% 0.5%
[libx264 @ 0000017ecc63bf80] ref B L0: 91.0% 7.5% 1.6%
[libx264 @ 0000017ecc63bf80] ref B L1: 95.8% 4.2%
[libx264 @ 0000017ecc63bf80] kb/s:2737.12

das ist das Ergebnis: https://drive.google.com/drive/folders/1KRKDBvmkC24yHgwXMdJrxioTyqCpK9Jf?usp=sharing

für den deinterlacer gibts auch noch andere optionen:

h264_cuvid AVOptions:
-deint <int> .D.V.... Set deinterlacing mode (from 0 to 2) (default weave)
weave .D.V.... Weave deinterlacing (do nothing)
bob .D.V.... Bob deinterlacing
adaptive .D.V.... Adaptive deinterlacing



man könnte natürlich jetzt noch den gewünschten encoder und die gewünschten qualititysettings nutzen. kannst du ja mal testen ob das für dich taugt. sollte mit der 730 eigentlich laufen. obs allerdings unter xp funktioniert kann ich dir nicht sagen. die 64bit build braucht auf jeden fall win7 x64.

[Peterxy]

Danke für die Tips. :up:
Für XP hatte ich irgendeine gemoddete 2017er FFMPEG Version rumliegen, die cuvid eigentlich können "sollte". Hab mal eine kleine batch Datei gemacht zum ausprobieren:

ffmpeg -vsync 0 -c:v h264_cuvid -deint adaptive -resize 1280x720 -i test.mp4 -c:a copy output.mp4

Es ist in GPU-Z zu sehen, das die Grafikkarte bei dem ganzen unter Last steht - also offensichtlich funktioniert das cuvid .
Frage dazu: Die GPU arbeitet mit dem switch aber doch nur das dekoden ab, oder?
Damit rezise o.ä. über die GPU lief, müßte man dafür nicht den NVENC switch nutze?? (dann würde aber das ganze encoding über die GPU laufen, was wiederum schlechtere Qualität wäre)
Das andere ist, das ich (wie man sieht :D) ) adhoc nicht so wirklich den Durchblick habe, was diese Command line, switches & Co bei FFMPEg betrifft.
Würde natürlich gerne meine alten X-264 KodierSettungs übernehmen und mal als Beispiel jene Settings:

cabac=1 / ref=3 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / fade_compensate=0.00 / psy_rd=1.00:0.09 / mixed_ref=0 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=0 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=18.5000 / qcomp=0.60 / qpmin=5 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

Wie werden x.264 Settings in die FFMPEG command line eingebunden?:confused:
Und die andere Frage, wie mach ich das nachher mit dem croppen? (irgendeine Vorschau braucht man dafür ja schon)

[Screemer]

gib mal ffmpeg -h decoder=h264_cuvid in der cmd ein. damit solltest du sehen was cuvid bei dir mit h264 anstellen kann. so in der art:

h264_cuvid AVOptions:
-deint <int> .D.V.... Set deinterlacing mode (from 0 to 2) (default weave)
weave .D.V.... Weave deinterlacing (do nothing)
bob .D.V.... Bob deinterlacing
adaptive .D.V.... Adaptive deinterlacing
-gpu <string> .D.V.... GPU to be used for decoding
-surfaces <int> .D.V.... Maximum surfaces to be used for decoding (from 0 to INT_MAX) (default 25)
-drop_second_field <boolean> .D.V.... Drop second field when deinterlacing (default false)
-crop <string> .D.V.... Crop (top)x(bottom)x(left)x(right)
-resize <string> .D.V.... Resize (width)x(height)

wie du siehst ist das cropen gar kein problem. hatte ich ja oben auch gemacht. oben und unten 300pixel (-crop OBENxUNTENxRECHTSxLINKS))abgeschnitten und danach auf 1280x720 pixel resized. die balkenbreite ist ja eigentlich immer gleich.

welchen x.264 encoder möchtest du denn nutzen? libx264 wie ich im obigen beispiel ist standard bei ffmpeg, wenn ich das richtig in erinnerung habe. dann gibts noch zig hardware-encoder. die 730 unterstützt HD 1080p, H.264 / AVC high-profile (YUV420, I/P/B frames, CAVLC/CABAC) via nvenc.

DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_qsv h264_cuvid ) (encoders: libx264 libx264rgb h264_nvenc h264_qsv nvenc nvenc_h264 )

das kannst du mit ffmpeg -codecs abfragen und dann bei h264 die zeile mal ansehen.

[Peterxy]

Hab mal einen Screenshot gemacht:
https://img2.picload.org/image/drlroola/ffmpeg.jpg

Sehr interessant, soweit ich das verstehe kann diese XP ModVersion also auch deinterlace + resize über cuvid.
Nur wofür ist dieser -gpu switch?

Das nachfolgende über nevenc habe ich zwar nicht vor, aber nur ob ich das richtig verstehe - so würde dann wohl alles d..h. auch das encoden über die GPU laufen - oder?
ffmpeg -c:v h264_cuvid -vsync 0 -deint adaptive -resize 1280x720 -i test.mp4 -c:v h264_nvenc -preset slow output.mp4

[Peterxy]

Okay, anhand der rasanten Geschwindigkeit hat sich das von selbst beantwortet, das mittels nvenc wohl alles über die GPU läuft.

welchen x.264 encoder möchtest du denn nutzen? libx264 wie ich im obigen beispiel ist standard bei ffmpeg, wenn ich das richtig in erinnerung habe. dann gibts noch zig hardware-encoder
Der encoder im FFMPEG reicht mir schon aus.
Ich hatte bislang immer die Komisar x.264 Build genutzt, nur letztlich war von den neuen x.264.exe (Rev. 2851) weder geschwindigkeitsmäßig noch visuell ein Unterschied zu dem älteren x.264.vfw Build 2273 zu sehen.
Also solange das was FFMPEG mitbringt nicht gerade älter als Rev 2273 ist, dann ist das doch alles super.

Raffe aber immer noch nicht wo/wie die X.264 settings richtig eingebunden werden:
ffmpeg -c:v h264_cuvid -vsync 0 -deint adaptive -resize -gpu 1280x720 -i test.mp4 -c:v libx264 -preset slow -crf 22 output.mp4

Also wenn ich das eingebe (nur preset + crf rate), passiert gar nix.
Wo liegt der Syntax-Feher ?? :confused:

[Screemer]

Wegen den Settings mach ich mal schlau. Das sind ja ein ganzer Haufen. Einige Parameter von libx264 kann man einfach an ffmpeg übergeben, andere muss man für den Encoder spezifisch ausweisen. Hab auch mal auf gleitz gefragt ob man cuvid auch mit staxrip nutzen kann. Mal sehen. Wird aber sicher heute Abend bis ich mir das zusammen gefrickelt habe.

Der gpu Switch ist übrigens dafür da, wenn man mehrere Karten im Rechner hat um eine bestimmt zu nutzen. Interessant ist, dass cuvid bei dir noch zwei weitere Optionen hat. Nämlich Surfaces und drop_second_field.

edit:ach ja vielleicht solltest du mal einen mod bitten den thread-titel zu ändern. Vielleicht in irgendwas wie "Video Hardwaredecoding mit gt730 NVENC CUVID FFmpeg" vielleicht kommt dann noch jemand anderes vorbei ;)

edit2: ffmpeg -c:v h264_cuvid -vsync 0 -deint adaptive -resize 1280x720 -i source.mkv -c:v libx264 -preset slow -crf 22 -c:a copy output.mkv
ffmpeg version 3.4 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 7.2.0 (GCC)
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth --enable-libmfx
libavutil 55. 78.100 / 55. 78.100
libavcodec 57.107.100 / 57.107.100
libavformat 57. 83.100 / 57. 83.100
libavdevice 57. 10.100 / 57. 10.100
libavfilter 6.107.100 / 6.107.100
libswscale 4. 8.100 / 4. 8.100
libswresample 2. 9.100 / 2. 9.100
libpostproc 54. 7.100 / 54. 7.100
Input #0, matroska,webm, from 'source.mkv':
Metadata:
encoder : libebml v1.3.3 + libmatroska v1.4.4
creation_time : 2015-11-21T15:17:33.000000Z
Duration: 00:01:00.12, start: 0.000000, bitrate: 14299 kb/s
Stream #0:0: Video: h264 (Baseline), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 1k tbn, 50 tbc (default)
Metadata:
BPS : 13974290
BPS-eng : 13974290
DURATION : 00:01:00.120000000
DURATION-eng : 00:01:00.120000000
NUMBER_OF_FRAMES: 3006
NUMBER_OF_FRAMES-eng: 3006
NUMBER_OF_BYTES : 105016794
NUMBER_OF_BYTES-eng: 105016794
_STATISTICS_WRITING_APP: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_APP-eng: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_DATE_UTC: 2015-11-21 15:17:33
_STATISTICS_WRITING_DATE_UTC-eng: 2015-11-21 15:17:33
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:1(eng): Audio: mp2, 48000 Hz, stereo, s16p, 320 kb/s (default)
Metadata:
BPS : 320000
BPS-eng : 320000
DURATION : 00:01:00.120000000
DURATION-eng : 00:01:00.120000000
NUMBER_OF_FRAMES: 2505
NUMBER_OF_FRAMES-eng: 2505
NUMBER_OF_BYTES : 2404800
NUMBER_OF_BYTES-eng: 2404800
_STATISTICS_WRITING_APP: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_APP-eng: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_DATE_UTC: 2015-11-21 15:17:33
_STATISTICS_WRITING_DATE_UTC-eng: 2015-11-21 15:17:33
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
File 'output.mkv' already exists. Overwrite ? [y/N] y
Stream mapping:
Stream #0:0 -> #0:0 (h264 (h264_cuvid) -> h264 (libx264))
Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[libx264 @ 000001c1104500a0] using SAR=1/1
[libx264 @ 000001c1104500a0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[libx264 @ 000001c1104500a0] profile High, level 3.2
[libx264 @ 000001c1104500a0] 264 - core 152 r2851 ba24899 - H.264/MPEG-4 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=50 rc=crf mbtree=1 crf=22.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, matroska, to 'output.mkv':
Metadata:
encoder : Lavf57.83.100
Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), nv12, 1280x720 [SAR 1:1 DAR 16:9], q=-1--1, 50 fps, 1k tbn, 50 tbc (default)
Metadata:
BPS : 13974290
BPS-eng : 13974290
DURATION : 00:01:00.120000000
DURATION-eng : 00:01:00.120000000
NUMBER_OF_FRAMES: 3006
NUMBER_OF_FRAMES-eng: 3006
NUMBER_OF_BYTES : 105016794
NUMBER_OF_BYTES-eng: 105016794
_STATISTICS_WRITING_APP: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_APP-eng: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_DATE_UTC: 2015-11-21 15:17:33
_STATISTICS_WRITING_DATE_UTC-eng: 2015-11-21 15:17:33
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
encoder : Lavc57.107.100 libx264
Side data:
cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
Stream #0:1(eng): Audio: mp2 (P[0][0][0] / 0x0050), 48000 Hz, stereo, s16p, 320 kb/s (default)
Metadata:
BPS : 320000
BPS-eng : 320000
DURATION : 00:01:00.120000000
DURATION-eng : 00:01:00.120000000
NUMBER_OF_FRAMES: 2505
NUMBER_OF_FRAMES-eng: 2505
NUMBER_OF_BYTES : 2404800
NUMBER_OF_BYTES-eng: 2404800
_STATISTICS_WRITING_APP: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_APP-eng: mkvmerge v8.5.2 ('Crosses') 64bit
_STATISTICS_WRITING_DATE_UTC: 2015-11-21 15:17:33
_STATISTICS_WRITING_DATE_UTC-eng: 2015-11-21 15:17:33
_STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
frame= 3006 fps= 58 q=-1.0 Lsize= 24542kB time=00:01:00.26 bitrate=3336.3kbits/s speed=1.16x
video:22153kB audio:2348kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.168707%
[libx264 @ 000001c1104500a0] frame I:21 Avg QP:21.30 size: 57982
[libx264 @ 000001c1104500a0] frame P:791 Avg QP:23.55 size: 18273
[libx264 @ 000001c1104500a0] frame B:2194 Avg QP:28.56 size: 3196
[libx264 @ 000001c1104500a0] consecutive B-frames: 1.2% 4.0% 1.7% 93.1%
[libx264 @ 000001c1104500a0] mb I I16..4: 27.3% 57.3% 15.3%
[libx264 @ 000001c1104500a0] mb P I16..4: 2.2% 3.3% 0.3% P16..4: 45.9% 12.1% 8.2% 0.0% 0.0% skip:27.9%
[libx264 @ 000001c1104500a0] mb B I16..4: 0.1% 0.2% 0.0% B16..8: 37.8% 2.2% 0.4% direct: 2.3% skip:57.0% L0:38.4% L1:55.8% BI: 5.8%
[libx264 @ 000001c1104500a0] 8x8 transform intra:57.6% inter:63.4%
[libx264 @ 000001c1104500a0] direct mvs spatial:99.7% temporal:0.3%
[libx264 @ 000001c1104500a0] coded y,uvDC,uvAC intra: 47.7% 74.5% 35.6% inter: 7.5% 15.9% 1.3%
[libx264 @ 000001c1104500a0] i16 v,h,dc,p: 26% 20% 12% 42%
[libx264 @ 000001c1104500a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 5% 9% 12% 16% 13% 14% 11% 12%
[libx264 @ 000001c1104500a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 6% 6% 11% 16% 14% 13% 11% 15%
[libx264 @ 000001c1104500a0] i8c dc,h,v,p: 39% 21% 19% 21%
[libx264 @ 000001c1104500a0] Weighted P-Frames: Y:7.0% UV:5.9%
[libx264 @ 000001c1104500a0] ref P L0: 59.2% 12.2% 17.3% 5.1% 5.9% 0.4% 0.0%
[libx264 @ 000001c1104500a0] ref B L0: 85.8% 10.7% 2.7% 0.7%
[libx264 @ 000001c1104500a0] ref B L1: 95.3% 4.7%
[libx264 @ 000001c1104500a0] kb/s:3008.43

sollte eigentlich jetzt das h264 slow preset sein.

hab den resize jetzt mal über die cpu gemacht und das ist schon nen ticken langsamer und crop düften auch noch einiges kosten:

fast:
frame= 3006 fps=100 q=-1.0 Lsize= 26435kB time=00:01:00.26 bitrate=3593.6kbits/s speed= 2x
zu
frame= 3006 fps=113 q=-1.0 Lsize= 25564kB time=00:01:00.26 bitrate=3475.3kbits/s speed=2.27x

slow:
frame= 3006 fps= 54 q=-1.0 Lsize= 25589kB time=00:01:00.26 bitrate=3478.7kbits/s speed=1.08x
zu
frame= 3006 fps= 57 q=-1.0 Lsize= 24542kB time=00:01:00.26 bitrate=3336.3kbits/s speed=1.13x

das ganze auf nem 2600k mit 4,4ghz. dürfte sich auf dem tuban noch nen ticken mehr auswirken. die frage ist allerdings ob die nicht die qualität von nvenc reichen würde, denn damit könntest du einen haufen zeit und energie sparen.

[Peterxy]

Also ich hatte bislang ja alles immer über vdub laufen und die vfw ist zwar bei manchen höchstverpönt, aber der Komisar Build damals war schon cool, da die nämlich ne GUI für (fast) alle X.264 switches hatte: http://fs5.directupload.net/images/171119/submltga.jpg
Das ist mit so ner GUI natürlich sehr bequem. :biggrin:

Wobei eine command line nichtmal sooo das Problem ist, sondern das die FFMPEG x.264 Befehle schlicht nicht identisch sind mit denen der originalen x.264.exe. (das war auch der Grund weswegen diese FFMPEG Version bislang nur auf der HDD rumlag)
Hab aber diesmal im Web beim googlen Glück gehabt und endlich mal eine Vergleichstabelle gefunden:
https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping
:wink:

OKay, damit wars nun natürlich wesentlich einfacher zumindest einen Teil der Settings zu übertragen:
ffmpeg -c:v h264_cuvid -vsync 0 -deint adaptive -resize 1280x720 -i test.mp4 -c:v libx264 -preset slow -crf 18.5 -me_method umh -me_range 24 -subq 7 -trellis 2 -mixed-refs 0 -rc-lookahead 40 -refs 3 -bf 3 -weightb 0 -deblock -1:-1 -psy-rd 0.10:1.0 -aq-strength 1.00 -x264opts b-pyramid=2 -threads 12 output.mp4


Nur, was ist mit no chroma me, no fast P skip, no weightb, no mixed refs?

-no-chroma-me

-flags2 -fastpskip

--weightb (x264)
-flags2 +wpred (FFmpeg)

--mixed-refs (x264)
-flags2 +mixed_refs (FFmpeg)

--b-pyramid (x264)
-flags2 +bpyramid (FFmpeg)

no chroma-me und v.a die "Flags2-Werte" funktionieren irgendwie nicht bzw. die werden bestimmt funktioneren, wenn man weiß wie. :confused:
Wobei ja, die B-Frame Pyramide habe ich ans laufen gekriegt hierrüber:
-x264opts b-pyramid=1 (mit 0=aus)
Nur das ist ein "Zufallstreffer", dieser switch steht da nirgendwo und man kann ja nicht alles "blind" durchprobieren. :|

[lumines]

Hast du schon einmal die "tune"-Optionen von x264 / ffmpeg benutzt? Eventuell brauchst du dann die Optionen gar nicht manuell setzen und "slow" oder "slower" als Preset reicht dir aus. "umh" ist z.B. schon durch "-preset slow" bei dir gesetzt.

Ich bin da jetzt nicht so der Poweruser, aber bisher hat es bei mir nie so viel gebracht mich sehr viel weiter von den Presets und Tune-Profilen zu entfernen. Für Material, bei dem ich mir nicht sicher bin, nehme ich einfach kein Tuning und nur das "medium"- oder "slow"-Preset mit einem CRF-Wert nach Wunsch und für den Rest eben "animation" oder "film" je nach Filmmaterial. Da wird das Deblocking und aq-strength schon entsprechend gesetzt.

[Peterxy]

Hatte das Post eben editiert, wie Psy Werte, AQ Trellis Stärke reingesetzt werden hab ich mittleerweile rausgefunden, der Befehl ist "ausnahmsweise" :biggrin: einfach mal im FFMPEG identisch mit der x.264.exe

Das die original H.264 tune settings eigentlich sehr gut sind, ist soweit klar - allerdings bei diesen H.264 TV Aufnahmen (ist so ne Aufnahmebox), muß man beim umkonvertieren die Psywerte schon was runter drehen. (nutzt man da film o.ä. als tune preset, werden die Kanten gerade bei dunklem vor hellem Hintergrund viel zu scharf bzw. nennt sich glaub ich "Halo-Effekt" oder so).
Die original Preset Werte sind da einfach zu stark und muß man bei diesen Aufnahmen leider alles en bißel anpassen.

[Screemer]

Die Standard Setting von Slow siehst du auch oben:

cabac=1 ref=5 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=50 rc=crf mbtree=1 crf=22.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00

[Peterxy]

Die Werte kann man nicht einfach mit nem = Zeichen reinsetzen, wie sie in Mediainfo oder so ausgelesen werden.
Nur wie gesagt irgendwelch Presets nützen nichts, das sind keine BlueRays und muß auf die Aufnahmen schon was angepaßt sein.
Die meisten Synthax´s habe ich mittlerweile rausgefunden und sind ja nur "noch" 2 switches über. :wink: :biggrin:

FastPskip (deaktivieren)
Chroma Me search (deaktivieren)
Irgendeine Idee wie der FFMPEG Syntax dafür ist?

[Peterxy]

Ok, mittlerweile geht jeder Switch. :wave2:
-fast-pskip 0
-cmp "sad" (=aus)
-cmp "chroma‘ (=an)
Lol, also dieser Syxnthax mit dem "sad" da hätte ich aber 100Jahre (erfolglos) blind rumprobieren können - denn wer kommt schon auf sowas :biggrin: und wer läßt sich sowas auch noch mit Gänsefßchen einfallen. (also irgendwie so ein "einheitliches" System was so synthax betrifft, kennen die bei FFMPEG aber nicht gerade)


Okay, jetzt werd ich mal alle Settings nacheinander 1:1 übernehmen in die batch und mal ein video konvertieren einmal über den Cudaframeserver und einmal per FMPEG Cuvid, bin mal gespannt was schneller ist. Mal sehen, ob ich das heut noch schaffe (mir raucht grad schon so en bißel der Kopf :freak:), ansonsten hol ich es morgen nach.

Hab auch mal auf gleitz gefragt ob man cuvid auch mit staxrip nutzen kann. Mal sehen. Wird aber sicher heute Abend bis ich mir das zusammen gefrickelt habe.
Danke dafür, doch ich denke eine Gui wie Staxrip ist jetzt wo alle switches gehen eigentlich nicht mehr nötig. Im Grunde muß ich eigentlich nur noch wissen wie man den FFMPEG Cropbefehl in die batch eingibt, wenn man oben/unten li/re X pixel wegrcoppt.
(vorschau zum croppen und wieviel, kann ich ja auch einfach im vdub nachschauen)

[Peterxy]

Ach so, noch eine Frage -
die Batch datei habe ich ja einfach per Notepad gemacht und das ist natürlich extremst unübersichtlich.

So gibts irgendeinen Befehl, womit man einen Zeilenumbruch machen kann um das übersichtlicher zu machen?
(einfach enter im __Notepad drücken für Zeilenumbruch geht nicht, dann gibts nur ne Fehlermeldung und das encode startet nicht)

[lumines]

So? https://stackoverflow.com/questions/69068/long-commands-split-over-multiple-lines-in-windows-vista-batch-bat-file

Ansonsten kann man auch einen Editor benutzen, der "softe" Brüche zur Darstellung benutzt und damit nicht die Datei ändert. Microsoft bietet z.B. Visual Studio Code an: https://code.visualstudio.com/

Läuft allerdings erst ab Windows 7. Kann aber nie schaden einen flexiblen Texteditor auf der Platte zu haben. Die Batch-Dateien kann man damit wahrscheinlich direkt aus dem Editor heraus ausführen.

Gibt natürlich auch noch Notepad++ und Co..

[Peterxy]

Dankeschön für den Tip, das scheint zu funktionieren dieses ^ und dann enter. :smile:

[Screemer]

Wie gesagt cropen würd ich auch über cuvid

-c:v h264_cuvid -deint adaptive -crop 100x200x300x400 -resize 1280x720

100=oben, 200=unten, 300=rechts und 400=links

Du könntest auch mal die Liste der Befehle hier posten. Jeweils mit x264.exe und ffmpeg Equivalent.

[Peterxy]

Kodierungseinstellungen:
// einmal mittels CudaFrameserver/aviysynth über vdub/x.264.vfw (KMod)
// einmal mittels FFMPEG cuvid
(d.h. für beides die gleichen X.264 settings verwendet)

cabac=1 / ref=3 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / psy_rd=0.10:1.00 / mixed_ref=0 / me_range=24 / chroma_me=0 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=0 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=18.5 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00


Hab damit mittlerweile mal einen 40min clip encodiert:
FFMPEG cuvid 44Minuten 47sek.
DGindexNV/DGDecodeNV/Avysynth/vdub 34Minuten 38sek
10 Minuten Zeitunterschied ist für so einen kurzen clip (bei gleichen "medium" settings) imo schon viel.
(bei nem längeren Spielfilm wird das über FFMPEG cuvid immerhin zwischen 20-30minuten langsamer sein als über DGindexNV/DGDecodeNV)

Falls da nicht irgendwas in der FFMPEG cuvid hw Beschleunigung vergessen/übersehen wurde, würde ich ansonsten sagen scheint wie schon in der Vergangenheit (hatte einige "modernere" 64bit Programme unter Win7 probiert) - nach wie vor das olle Cuda Ding die Nase vorn zu haben.
Ist anscheinend selbst nach Jahren noch "alternativlos". :(

Hätte mir gewünscht es wäre anders, aber danach siehts leider nicht aus.
Werd mir als nächstes mal den FFMPEG nvenc GPU-encoder anschauen, die Quali ist per GPU endcoded grundsätzlich zwar schlecht - aber vielleicht reichts um wenigstens Serien auf die schnelle zu archivieren, wo die Bildqualität nicht sooo wichtig ist.

[Screemer]

Das liegt eher an von ffmpeg genutzten libx264 und den zugehörigen Filtern. Deswegen würde sich ja ffmpeg zur streamausgabe nach cuvid + x264.exe als Kombination anbieten. Würde da vielleicht mal bei doom9 nachhaken.

[Peterxy]

hmm, denkst du denn das reißt noch was raus?
Kann mir nicht so recht vorstellen das libx264 soviel langsamer sein soll als x.264.exe, denn selbst zwischen einer angestaubten x.264.vfw ist zum neusten x.264.exe Cli Build über den Cuda Frameserver, faktisch kein wirklich mit der Uhr sonderlich meßbarer Zeitunterschied (in den letzten 2Jahren hat sich da nicht wirklich mehr groß was getan, der Codec ansich ist ja schon ausgereift bzw. irgendwo auch speedmäßig schlicht "ausgereizt")

Auch scheint mir das nicht sooo sicher, das die Filter wie deinterlace + resize wirklich bei FFMPEG über die GPU laufen.
(was btw. den Geschwinigkeitunterschied erklären könnte :wink: )

Wenn man einen anderen deinterlace Filter nutzt der über die CPU läuft, entsteht kaum Zeitverlust, der aber eigentlich da sein müßte wenn dieser switch -deint adaptive ink. dem Resize über die GPU lief. Auf third Party Site sind teils auch GPU basierte rezise Filter als Payware zu finden und wieso gibts diese Payware Filter für FFMPEG wenn es doch mit den "kostenlos/beiliegenden" FFMPEG Filtern per GPU ginge?
Werde das beizeiten aber mal ev. bei Doom9 nachfragen, was es damit auf sich hat.

[Peterxy]

hab mich jetzt mal kurz mit dem GPU encode beschäftigt:
ffmpeg -c:v h264_cuvid -vsync 0 -deint adaptive -resize 1280x720 -i test.mp4 -c:v^
h264_nvenc -preset llhq -rc:v vbr_minqp -qmin:v 19 -qmax:v 21 -b:v 2500k -maxrate:v 5000k -profile:v high -bf:v 3 output.mp4

Von der Qualität natürlich schlechter und von den Settings nicht zu vergleichen (CRF geht da anscheinend ohnehin gar nicht erst und das über qp, maxrate & co lösen, scheint mir am sinnvollsten)

Encodingzeit mit ner GT730: 14Minuten (dürfte mit ner besseren Karte noch schneller gehen :biggrin:)
Gradmal 14Minuten ist natürlich ne Ansage und hmm ja ok, wenn man die encodes über MadVr laufen läßt + ein bißel weiter wegsitzt *gg*, dann geht die Quali für einfache Serien schon okay.
War also nicht alles ganz umsonst und danke euch. ;)