dann haben meine gewandelten BRs noch ca 12GB von vorherigen 25GB die direkt von der Disk gekommen sind
Also die letzte BR ist von 30,98GB auf 3,26GB geschrumpft mit der erwähnten "Apple 2160p60 4K HEVC Surround" rein über die CPU (der XEON hat ja auch nichts anderes) Einstellung. Das hat aber auch ca. 3 Stunden gedauert.
Jo...bei mir dauert das Wandeln über die GPU ca 25 Minuten 
Gerade auch mal wieder einen kleinen vergleich gemacht, siehe unten.
Resultate IMHO:
Denke schon, das ich bei x265/CPU bleibe. Einziges Problem sind die "standard" RPI3 abspieler zuause, die das ja nur bis 720p dekodiert bekommen. Weiss noch nicht, was ich da tuen will... die Vero4k hat noch einen fetten bug fuer mich.
Die Zeit, die das konvertieren kostet stoert mich nicht. Allerdings stellt sich schon die frage, wann es sich lohnt, auf sowas wie ryzen 3900 aufzuruesten, was faktor 4.5 an Geschwindigkeit bringen wuerde.
#!/bin/sh
ffmpeg=/usr/local/ffmpeg-4.2.2/ffmpeg
# Comparison: 'Charite season 3':
# Original x264/rf23 x265/rf23
# Total size
# Doc (43 min) 2167657830 1505708874 1058145775
# Ep 1 (47 min) 2381267006 1199518481 564296594
# other episodes
# same as Ep 1
#
# Size: .... 1920x1080@50, 4:2:0 8bit ....
# Codec params: ... x264/High@L4.2 .... x265/Main@L4.1
#
# BR control: 2pass 6500/8000 1pass rf23 1pass rf23
#
# Audio: 48khz
# AAC LC Codec: 128/192max 128 128
# Codec-ID: ??(40) LAVC(A_AAC) LAVC(A_AAC)
#
# Result: rf23/x265 gives > factor 4 space saving on typical
# TV material vs. original (2 pass, fixed bitrate target).
# for more complex material (e.g.: documentation), factor
# goes down to 2.
#
# Should have probably just copied audio instead of re-encode,
# somewhat messes up number comparison.
#
# Encoding performance on E3-1231 (ca. 7000 passmarks):
# x264: > 50 fps, x265: 12 fps
for in in $* ; do
out="${in%.*}.mkv"
${ffmpeg} -i ${in} -c:v libx265 -crf 23 -c:a aac -b:a 128k ${out}
doneMit einer NVidia GPU und ffmpeg einfach diesen Befehl nehmen:
ffmpeg -hwaccel cuvid -c:v h264_cuvid -vsync 0 -i input.mkv -map 0 -c copy -vcodec hevc_nvenc -b:v 12M -bufsize:v 8M -level:v 4.1 -preset:v slow -max_muxing_queue_size 1024 output.mkv
Hat jemand den passenden Befehl für AMD-GPU probiert? Ich hab hevc_nvenc durch hevc_amf ersetzt, aber das reicht wohl noch nicht. H264_cuvid durch h265_amf (ja, UHD Material runter rechnen), aber was muss ich statt cuvid schreiben? ffmpeg meint auch, das es kein h265_amf kennt oder libx265, was aber nicht stimmt.
Ich sehe schon, das ich das lasse 
Gerade auch mal wieder einen kleinen vergleich gemacht, siehe unten.
Resultate IMHO:
Denke schon, das ich bei x265/CPU bleibe. Einziges Problem sind die "standard" RPI3 abspieler zuause, die das ja nur bis 720p dekodiert bekommen. Weiss noch nicht, was ich da tuen will... die Vero4k hat noch einen fetten bug fuer mich.
Die Zeit, die das konvertieren kostet stoert mich nicht. Allerdings stellt sich schon die frage, wann es sich lohnt, auf sowas wie ryzen 3900 aufzuruesten, was faktor 4.5 an Geschwindigkeit bringen wuerde.
Bash#!/bin/sh ffmpeg=/usr/local/ffmpeg-4.2.2/ffmpeg # Comparison: 'Charite season 3': # Original x264/rf23 x265/rf23 # Total size # Doc (43 min) 2167657830 1505708874 1058145775 # Ep 1 (47 min) 2381267006 1199518481 564296594 # other episodes # same as Ep 1 # # Size: .... 1920x1080@50, 4:2:0 8bit .... # Codec params: ... x264/High@L4.2 .... x265/Main@L4.1 # # BR control: 2pass 6500/8000 1pass rf23 1pass rf23 # # Audio: 48khz # AAC LC Codec: 128/192max 128 128 # Codec-ID: ??(40) LAVC(A_AAC) LAVC(A_AAC) # # Result: rf23/x265 gives > factor 4 space saving on typical # TV material vs. original (2 pass, fixed bitrate target). # for more complex material (e.g.: documentation), factor # goes down to 2. # # Should have probably just copied audio instead of re-encode, # somewhat messes up number comparison. # # Encoding performance on E3-1231 (ca. 7000 passmarks): # x264: > 50 fps, x265: 12 fps for in in $* ; do out="${in%.*}.mkv" ${ffmpeg} -i ${in} -c:v libx265 -crf 23 -c:a aac -b:a 128k ${out} done
empfehle ryzen 5700G (OC das selbst der 5800x neidisch wird.....)
Zu sagen, dass es "nicht im erträglichen Rahmen" ist, finde ich dann doch zu hart und kann ich nicht bestätigen. Ich spreche mich nicht von Banding frei oder auch mal ein Artefakt in dunklen Szenen zu sehen. Aber "nicht erträglicher Rahmen" .... davon bin ich aber weit entfernt.
OK, OK Sorry will ja dir ja nicht zu nahe treten.
Werde es umformulieren:
"Um ein Vergleichbares Ergebnis im Gegenzug zur GPU Konvertierung zu bekommen, kann man bei einer reinen CPU Konvertierung sehr hohe Abstriche machen. Besser? ![[aa]](https://www.kodinerds.net/wcf/images/smilies/smiley38.gif "aa"){kind=small}
Die Zeit, die das konvertieren kostet stoert mich nicht. Allerdings stellt sich schon die frage, wann es sich lohnt, auf sowas wie ryzen 3900 aufzuruesten, was faktor 4.5 an Geschwindigkeit bringen wuerde.
Gerade hier Lohnen sich Kerne, und AMD profitiert mit Ihrer Architektur enorm. Würde dir aber auch mal wie bereits erwähnt ein aktuellen Linux Kernel etc. empfehlen. Eventuell reicht zum Testen auch mal ein LiveUSBStick, wobei ich dir auch nicht Sagen kann, was der möglicherweise geringere Datendurchsatz ausmachen würde.
Mich würde mal Interessieren, wie sich ein Threadripper oder Epic mit 48 oder mehr Threads schlägt bei so etwas schlägt. Oder was auch mal Interessant wäre, was setzen den mittlerweile die grossen Streaminghoster wie Youtube und Co ein, für genau solche aufgaben (Upload Video, Konvertierung in VP9).
Gerade hier Lohnen sich Kerne
Auf meinem Mac benutzt Handbrake ja schon alle 10 Kerne mit voller Last, gut es ist eben nur ein XEON E5-2690v2 mit 3GHz von 2011, aber so richtig in die Gänge kommt er ja wohl nicht.
Die Daten kommen von und gehen zu einer SSD, die mit 1400MB/s read/write auch nicht so langsam ist.
Also hier der Nachweis
MEG : 16 GB samt 5.1 Opus.....
Inkl 4K.....
Habe auch andere Filme in 4K....
ZB : es war einmal ein Schneemann (von Frozen) per Audials kopiert.....
In 4K.....satte 482MB (allerdings war da ein ryzen 2600 tätig..... - leider nicht meiner)
Andere Filme pendeln sich bei 1080p bei ca 3-5GB und 4K bei 6-16GB ein... .
Auf meinem Mac benutzt Handbrake ja schon alle 10 Kerne mit voller Last, gut es ist eben nur ein XEON E5-2690v2 mit 3GHz von 2011, aber so richtig in die Gänge kommt er ja wohl nicht.
Die Daten kommen von und gehen zu einer SSD, die mit 1400MB/s read/write auch nicht so langsam ist.
Ich will hier nicht AMD hoch her Jubeln, aber deren Architektur war selbst schon zu den verhassten "FX" Zeiten, vergleichsweise sehr gut in Konvertierungsaufgaben. Hat nur aufgrund des Fehlens eines Effizienten Stromverbrauchs, sowie der geringeren IPC nicht wirklich etwas gebracht. Ich gehe mal stark davon aus, das liegt an der fortschrittlicheren Speicherverwaltung, hier ist AMD schon seit etlichen Jahren Intel immer voraus gewesen.
Habe vor Jahren recht viel Zeit in Realtime Audio Anwendungen gesteckt, und daher eben aufgrund der Speicherverwaltung intern sowie Extern, AMD immer bevorzugt. Das hat häufig 2 stellige Werten in den Latenzen im Vergleich zu Intel ausgemacht. Angeblich war bei Intel deren Umsetzung bei der Hyperthreading Technik die Ursache.
Du kannst dir gar nicht vorstellen was ein paar Millisekunden mehr für Unterschiede, bei einigen Software Audiogeneratoren bewirken kann.
Auf meinem Mac benutzt Handbrake ja schon alle 10 Kerne mit voller Last, gut es ist eben nur ein XEON E5-2690v2 mit 3GHz von 2011, aber so richtig in die Gänge kommt er ja wohl nicht.Die Daten kommen von und gehen zu einer SSD, die mit 1400MB/s read/write auch nicht so langsam ist.
google mal. Gibt einiges an Infos die darauf hinweist, das Handbrake es irgendwie schafft nicht alle Kerne auszunutzen, obwohl es x265 nutzt. Und die einfache CLI Anwendung 'ffmpeg' es mit x265 sehr wohl schafft alle Kerne ziemlich gut auszunutzen.
das Handbrake es irgendwie schafft nicht alle Kerne auszunutzen, obwohl es x265 nutzt
Wenn ich mir meine CPU-Anzeige ansehe, dann sind alle zehn Kerne am Anschlag. Das hier sagt die Aktivitätsanzeige:
Wenn ich %-Angabe richtig interpretiere hat er die 17 fache Leistung eines Cores genutzt.
Und die einfache CLI Anwendung 'ffmpeg' es mit x265 sehr wohl schafft alle Kerne ziemlich gut auszunutzen.
Ich dachte immer handbrake nutzt intern ffmpeg.
Wenn ich mir meine CPU-Anzeige ansehe, dann sind alle zehn Kerne am Anschlag. Das hier sagt die Aktivitätsanzeige:
Wenn ich %-Angabe richtig interpretiere hat er die 17 fache Leistung eines Cores genutzt.
Ok, dann ist mir nicht klar was Du mit "aber so richtig in die Gänge kommt er ja wohl nicht" meintest.
Ich dachte immer handbrake nutzt intern ffmpeg.
Jo, dachte ich auch. Keine Ahnung. man kann ja ffmpeg sicherlich auch falsch parametrisieren, oder handbrake bastelt sich seine pipeline (decodieren, verschlimmbessern, encodieren) doch selbst zusammen. x256 kann man ja auch direkt als library einbinden.
google mal. Gibt einiges an Infos die darauf hinweist, das Handbrake es irgendwie schafft nicht alle Kerne auszunutzen, obwohl es x265 nutzt. Und die einfache CLI Anwendung 'ffmpeg' es mit x265 sehr wohl schafft alle Kerne ziemlich gut auszunutzen.
Das kann ich so nicht bestätigen, zumindest nicht bei h265, meine Systemauslastung liegt zwischen 93-97%. Beim h264 ist so jedoch deutlich niedriger, soweit mir bekannt ist, hat h265 auch diesbezüglich eine Mehrkennoptimierung erhalten.
Unter Linux zumindest ist Handbrake nur eine reine GUI und übergibt je nach Einstellungen lediglich einen Befehl an ffmpeg, welchen man übrigens bis vor einiger Zeit Kopieren und Bearbeiten konnte. Leider ist die Anzeige in der Offiziellen Version scheinbar nicht mehr integriert.
Der einzige Grund warum FFmpeg mehr Kerne nutzt, wäre man hat entweder mehrere Versionen installiert, und/oder eine Veraltete.
Unter Windows könnte es möglicherweise auch an fehlenden Berechtigungen (Kernelkritisch) für Handbrake/FFmpeg liegen. Der Ursprüngliche Grund warum ich auf Arch setze sind unter anderen, solcherlei Tools wie z.B. FFmpeg, es ist halt alles von Haus aus sehr Aktuell.
Unter Linux zumindest ist Handbrake nur eine reine GUI und übergibt je nach Einstellungen lediglich einen Befehl an ffmpeg, welchen man übrigens bis vor einiger Zeit Kopieren und Bearbeiten konnte. Leider ist die Anzeige in der Offiziellen Version scheinbar nicht mehr integriert.
Das ist hier bei Unix auch so. Im [definition='1','0']log[/definition] kann man sehen, das er irgendein x265 benutzt, dort sieht man auch welche Features der Prozessor hat:
x265 [info]: HEVC encoder version 3.2.1+1-b5c86a64bbbe
x265 [info]: build info [Mac OS X][clang 11.0.3][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 20 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(10 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 50 / 500 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 25 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 4 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-24.0 / 0.60
x265 [info]: tools: limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=1.00 rskip
x265 [info]: tools: signhide tmvp deblock saoIch hab ja bloss mal gegoogled und dann so seiten gefunden, die ueber performance problemen mit handbrake x265 berichten. Ich habs nicht verifiziert. Scheint ja sowieso ein missverstaendnis zu sein mit
dem "aber so richtig in die Gänge kommt er ja wohl nicht".
Ansonsten: bloss weil es so aussieht als ob da ausreichend viele threads gestartet werden, heisst das ja noch nicht, das denen da genuegend schnell daten geliefert werden.
Bei meiner automatisierten konvertierung ueber scripten lasse ich auch immer gerne mindestens 2 dateien gleichzeitig konvertieren. da sind dann die CPUs viel leichter immer voll ausgelastet.
Bei meiner automatisierten konvertierung ueber scripten lasse ich auch immer gerne mindestens 2 dateien gleichzeitig konvertieren. da sind dann die CPUs viel leichter immer voll ausgelastet.
Das ist auch eine Idee. Über Handbrake wird das wahrscheinlich nicht gehen, denn es kommt dann diese Meldung:
Aber man kann beide starten und sie laufen auch gleichzeitig. Das muß ich beim nächsten Mal direkt ausprobieren. Vielleicht ist es ja wirklich schneller als hintereinander.
naja. fuer das was ich neu als BD kaufe nehme ich auch bloss handbrake manuell. was soll der stress da die letzte minute rauszukitzeln. Ist halt bequem mit GUI, und bei den SCHEISS DEUTSCHEN BDs muss man ja eh in 50% der faelle immer noch O-Ton Untertitel dazumischen vom Netz, d.h. automatisierung bringt da nicht soviel.
Geht eher um alles was automatisch aufgenommen wird, wo also eh kein handbrake sondern ffmpeg selbst zum einsatz kommt.
und bei den SCHEISS DEUTSCHEN BDs muss man ja eh in 50% der faelle immer noch O-Ton Untertitel dazumischen vom Netz
?-) Du hast dann deutschen Ton und englische Untertitel oder wie ist das zu verstehen?
Noe. BD hat deutschen und englichen (O) Ton, aber nur deutsche UT, keine englische UT. Und ich hoere halt gerne den englischen originalton, aber wenn die zu sehr nuscheln brauche ich da halt auch mal UT, und ich will ja nicht sinngemaess wissen was gesagt wurde (dazu wuerde der deutsche UT reichen), sondern halt das/die woerter, die ich nicht raushoeren konnte.
Ich glaube das ist wieder so ein lizensierungsscheiss. AKa: da kriegt der deutsche Vertreiber die rechte eine deutsche BD zu fraesen billiger, wenn da kein englischer untertitel mit drauf ist oder so. Aber das ist frei spekulatius.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!