ubuntuusers.de

Hallo zusammen,

ich nutze zum rippen von BR-Medien MAKEMKV und Handbrake. Das funktioniert auch alles. Als Codec wähle ich H265 NVENC da ich in den Systeme überall CAD-Karten (Quadro Pro) von nVIDIA habe und das rippen damit wirklich flott läuft.

Da ich neu beim rippen bin habe ich eine Frage zum Codec (H265 NVENC). Ist das ein nVIDIA eigener Codec der auf dem Zielsystem auf dem der Film abgespielt wird auch eine nVIDIA-Karte erfordert bzw. empfehlenswert macht?

Oder ist H265 ein Standard und der Zusatz NVENC besagt lediglich das für die Codierung die GPU genutzt wird und zum Decodieren ganz normal H265?

Ich hoffe ich konnte es verständlich formulieren.

Beste Grüße pixel24

NVENC ist der Name von Nvidia's Hardware-Encoder System: Nvidia_NVENC. Da purzelt dann H265 aka HEVC Material heraus, das sich auf allen kompatiblen Playern entweder mit Software- oder Hardwaredecoding abspielen lässt. Ich würde unbedingt mal einen Qualitätsvergleich machen - NVENC ist toll, weil die GPU der CPU viel Arbeit abnimmt, aber die Qualität ist z.T. nicht ganz auf dem Niveau, das mit optimalem Software-Encoding erreichen könnte.

Das wird dir von Wikipedia und Co. sicher viel besser erklärt als in diesem Ubuntu Forum.

allen kompatiblen Playern

Prüf' mal, ob deine Player mit 265 klar kommen. mp4/264 ist -zumindest bei mir- "harmloser" ... 👍

Ok, dann verstehe ich es richtig NVENC ist eine Erweiterung von H265. Auf dem Zielplayer kann dies entweder durch Hardware oder Software decodiert werden.

Abgespielt werden die Filme auf dem Player. Was die Qualität angeht werde ich mal diverse Tests mit anderen Codecs durchführen um einen Vergleich zu haben.

Erweiterung von H265

Da sind jetzt aber viele Leute beleidigt. 🤣

Stell' dir NVENC einfach als spezialisierte Schnittstelle zur Nvidia GPU vor. Das machen die Leute von dieser Firma nicht aus Nettigkeit, sondern damit verkloppen die ihre Hardware.

Was ist ein Zielplayer?

Egal, testen und Erfahrungen sammeln ist immer gut. Denk' nur daran, daß das Schöne mkv und 265 nicht immer gschluckt wird von den einzelnen Playern. Blöd, wenn man nach viel Arbeit merkt, daß man nur Müll produziert hat!

hakel2022 schrieb:

Stell' dir NVENC einfach als spezialisierte Schnittstelle zur Nvidia GPU vor. Das machen die Leute von dieser Firma nicht aus Nettigkeit, sondern damit verkloppen die ihre Hardware.

Prima, hab's verstanden. Der Player sollte kein Problem darstellen bzw. tut er im Moment nicht. Die Medien liegen auf dem Jellyfin-Server und als Client wird Kodi bzw. die Jellyfin-App genutzt. Letzteres eher nicht für Filme als für die Musik.

Generell: will man Filme haben, die fast überall laufen, so wähle man H264 + MP3 im MKV-Container.

H265 wird schon sehr viel weniger unterstützt, vor allem bei älterer Hardware.

Zur Qualität über die NV-Encoder: da musste ich feststellen, dass die vor allem Eindruck über die Geschwindigkeit schinden wollen; die Qualität ist jedoch bescheiden. (Kann sein, dass sich das gebessert hat).

Ich kodiere immer mit ffmpeg mit

-c:v libx264 -preset slow -crf 18

Das bringt schon eine ziemlich gute Qualität. Mir genügt es jedenfalls. Und mit dem 8-Kern Ryzen geht das auch relativ zügig voran. ZB 720p kodiert mit ca 80fps.

als Client wird Kodi ... genutzt.

Kodi kann natürlich fast alles wiedergeben, auch H265. Wenn andere Player keine Rolle spielen, dann geht das. Dennoch ist mir persönlich die H265-Kodierung (in guter Qualität) zu langsam. Der Platzgewinn im Filmarchiv durch die stärkere Kompression von H265 reißt es bei mir nicht raus. 4TB für 100€... da kaufe ich lieber eine neue Platte als die CPU ins Nirvana rechnen zu lassen 😉

Wie ich ja angedeutet habe. Ich wollte wissen was H265 NVENC speziell ist was Ihr mir ja prima erklärt habt. Die Auswahl dieses Codec zum rippen war eher zufällig und einfach für die ersten Gehversuche. Ich rippe die ganze Zeit an zwei verschiedenen BR herum. Jetzt werde ich verschiedene Codec ausprobieren und Qualität beurteilen.

Danke für die Infos ☺

1. Bitte nicht „rippen“ sagen, das ist einfach nur dumm. Es werden dabei auch einfach nur Daten konvertiert, mehr nicht.

2. Auf einer Blu-Ray sind eigentlich schon fertige Dateien vorhanden, meist MP2-Transportstream (M2TS). Das sind auch nur container-Formate, genauso wie MKV einer ist. Und in diesen M2TS-containern sind auch nur Video-Formate und Audio-Formate enthalten. Bei den Videoformaten ist das entweder H.262, H.264 oder VC-1. Ich vermute mal, es wird sehr oft H.264 benutzt. Bei Audio ist es entweder irgendein Dolby-Zeugs oder DTS-Zeugs (beides Sind Audio-Firmen, die ihre codecs teuer unter die Leute bringen, diese Verbrecherbanden).

Das führt zu: 3. Wenn du jetzt H.264 in H.265 umkodierst, dann erhälst du (solange du nicht den lossless-mode benutzt, den aber eh damit niemand will, weil er ja die Dateigröße kleiner machen will) unweigerlich Qualitätsverlust, weil hier von einem lossy-Format ein anderes lossy-Format umkodiert wird. Das resultiert in unschönen Artefakten, die man hier und dann auch sehen kann. Deswegen: Bitte nicht in H.265 kodieren. Da geht so viel Information flöten, dass die Qualität einfach massiv darunter leidet. Daas selbe zählt für Audio. Bitte nicht in lossy umkonvertieren. MP3 braucht heute niemand mehr. Alle gängigen player spielen auch FLAC ab. Also entweder gar nicht konvertieren und das Quellmaterial behalten oder eben in lossless (bei Audio halt FLAC). Wenn auf der Blu-Ray H.264 ist, dann nimm das. Da muss das System auch gar nichts neu berechnen, sondern kopiert einfach das Ausgagsmaterial und fertig. Dafür braucht man keine Grafikkarte und das geht auch so viel schneller und eben ohne Qualitätsverlust. Und bei Umkodierung von Videomaterial sollte es ziemlich egal sein, wie lange das dauert. Du machst das einmal und hast dann die Datei für immer. Da sollte eigentlich keine Rolle spielen, wie lange das nun dauert. Wichtig ist doch eher, dass die QUalität stimmt. Du willst ja nicht ein schlechteres Video auf deine SSD holen, als was auf der BR eigentlicch drauf ist. Das wäre ja Selbstverkrüppelung. 😉 Was halt schnell geht ist das umpacken von M2TS in MKV. Sind ja nur andere container. MKV ist besser.

Und Nvidia ist scheiße! Einfach nicht benutzen diesen Saftladen. Erstens, weil die Linux kaum unterstützen (Nvidias Grafikkartenunterstützung für Linux ist ein reines Trauerspiel) und zweitens weil die für ihre Grafikkarten dieses proprietäre Dreckszeug von der MPEG unterstützen als freie codecs. Auch die MPEG ist genauso ein Räuberverein. Die erfinden immer irgendwelche codecs, die keiner braucht. Es gibt mehr als genug ebenbürtige freie open source codecs. Die sollte man unterstützen udn nicht eine Firma, die ihren Scheiß allen aufzwängt und man das als Verbraucher alles auch bezahlen muss. Niemand hat nach H.264 oder H.265 gefragt, aber MPEG hat uns allen weis gemacht, dass das benötigt wird und nun ist der Mist überall verbreitet und wir bezahlen den Scheiß. Niemand braucht das MPEG-Zeugs (mehr), schon lange nicht!

pixel24 schrieb:

Hallo zusammen,

ich nutze zum rippen von BR-Medien MAKEMKV und Handbrake. Das funktioniert auch alles. Als Codec wähle ich H265 NVENC da ich in den Systeme überall CAD-Karten (Quadro Pro) von nVIDIA habe und das rippen damit wirklich flott läuft.

Da ich neu beim rippen bin habe ich eine Frage zum Codec (H265 NVENC). Ist das ein nVIDIA eigener Codec der auf dem Zielsystem auf dem der Film abgespielt wird auch eine nVIDIA-Karte erfordert bzw. empfehlenswert macht?

Oder ist H265 ein Standard und der Zusatz NVENC besagt lediglich das für die Codierung die GPU genutzt wird und zum Decodieren ganz normal H265?

Ich hoffe ich konnte es verständlich formulieren.

Beste Grüße pixel24

hi ! nein kannst auf jedem system abspielen

covertiere sellbst mit nvidia nvenc und spiele mit h264_v4l2m2m auf rasparrypi ab

nein nvidia unterstützt linux kein bisschen ist aber sauber implementiert und im vergleich zu libx264 ein schertz bessere quali un viel schneller nur nvidia gibt den quellcode nicht

raus desshalb sind sie bei linux unbeliebt !!

es ist ein h264 codec sehr kompatible !!!! lg tom

shinichi schrieb:

1. Bitte nicht „rippen“ sagen, das ist einfach nur dumm. Es werden dabei auch einfach nur Daten konvertiert, mehr nicht.

2. Auf einer Blu-Ray sind eigentlich schon fertige Dateien vorhanden, meist MP2-Transportstream (M2TS). Das sind auch nur container-Formate, genauso wie MKV einer ist. Und in diesen M2TS-containern sind auch nur Video-Formate und Audio-Formate enthalten. Bei den Videoformaten ist das entweder H.262, H.264 oder VC-1. Ich vermute mal, es wird sehr oft H.264 benutzt. Bei Audio ist es entweder irgendein Dolby-Zeugs oder DTS-Zeugs (beides Sind Audio-Firmen, die ihre codecs teuer unter die Leute bringen, diese Verbrecherbanden).

Das führt zu: 3. Wenn du jetzt H.264 in H.265 umkodierst, dann erhälst du (solange du nicht den lossless-mode benutzt, den aber eh damit niemand will, weil er ja die Dateigröße kleiner machen will) unweigerlich Qualitätsverlust, weil hier von einem lossy-Format ein anderes lossy-Format umkodiert wird. Das resultiert in unschönen Artefakten, die man hier und dann auch sehen kann. Deswegen: Bitte nicht in H.265 kodieren. Da geht so viel Information flöten, dass die Qualität einfach massiv darunter leidet. Daas selbe zählt für Audio. Bitte nicht in lossy umkonvertieren. MP3 braucht heute niemand mehr. Alle gängigen player spielen auch FLAC ab. Also entweder gar nicht konvertieren und das Quellmaterial behalten oder eben in lossless (bei Audio halt FLAC). Wenn auf der Blu-Ray H.264 ist, dann nimm das. Da muss das System auch gar nichts neu berechnen, sondern kopiert einfach das Ausgagsmaterial und fertig. Dafür braucht man keine Grafikkarte und das geht auch so viel schneller und eben ohne Qualitätsverlust. Und bei Umkodierung von Videomaterial sollte es ziemlich egal sein, wie lange das dauert. Du machst das einmal und hast dann die Datei für immer. Da sollte eigentlich keine Rolle spielen, wie lange das nun dauert. Wichtig ist doch eher, dass die QUalität stimmt. Du willst ja nicht ein schlechteres Video auf deine SSD holen, als was auf der BR eigentlicch drauf ist. Das wäre ja Selbstverkrüppelung. 😉 Was halt schnell geht ist das umpacken von M2TS in MKV. Sind ja nur andere container. MKV ist besser.

Und Nvidia ist scheiße! Einfach nicht benutzen diesen Saftladen. Erstens, weil die Linux kaum unterstützen (Nvidias Grafikkartenunterstützung für Linux ist ein reines Trauerspiel) und zweitens weil die für ihre Grafikkarten dieses proprietäre Dreckszeug von der MPEG unterstützen als freie codecs. Auch die MPEG ist genauso ein Räuberverein. Die erfinden immer irgendwelche codecs, die keiner braucht. Es gibt mehr als genug ebenbürtige freie open source codecs. Die sollte man unterstützen udn nicht eine Firma, die ihren Scheiß allen aufzwängt und man das als Verbraucher alles auch bezahlen muss. Niemand hat nach H.264 oder H.265 gefragt, aber MPEG hat uns allen weis gemacht, dass das benötigt wird und nun ist der Mist überall verbreitet und wir bezahlen den Scheiß. Niemand braucht das MPEG-Zeugs (mehr), schon lange nicht!

hi

ja die unterstützung von nvidia im vergleich zu intel und amd ist ein schertz und trotzdem ist intel und amd uuuur langsam echte krücken, wenn du einmal cuda installiert hast und ffmpeg selber compilierst hast dann gibt es bis jetzt nichts besseres !

ich hab teilweise 250 fps beim convertieren ! interessant ist h264_v4l2m2m der ist völlig frei, intel hat auch seinen unfrein treiber in der sources.list und ist nicht frei

und nvidia eben auch

nouveau ist ein eigenständiges project und sehr gut

opus im vergleich zu libfdk_aac da ist mir der freie opus lieber

lg tom

Moin zusammen,

Spooky1966 schrieb:

hi ! nein kannst auf jedem system abspielen

covertiere sellbst mit nvidia nvenc und spiele mit h264_v4l2m2m auf rasparrypi ab

nein nvidia unterstützt linux kein bisschen ist aber sauber implementiert und im vergleich zu libx264 ein schertz bessere quali un viel schneller nur nvidia gibt den quellcode nicht

raus desshalb sind sie bei linux unbeliebt !!

es ist ein h264 codec sehr kompatible !!!! lg tom

schön zu sehen, dass die Qualität im Ubuntuusers Forum immer noch die ist, die ich vorgefunden habe, als Canonical Unity entwickelt hat und Gnome mich mit Gnome3 vergrault hat.

pixel24 hat nach H265 mit NVENC gefragt. Wenn das Quellformat schon H264 ist, lohnt sich das erneute Encodieren nicht (bestenfalls kaum) und ist - wie shinichi schon ausgeführt hat - nutzlos und verringert nur die Qualität.

Ich spiele schon einige Zeit mit dem Gedanken meine MediathekView Sammlung teilweise auf H265 umzustellen. Das könnte sich IMHO lohnen, weil der H264 Encoder, den die Sender da verwenden, in den meisten Fällen schlechter als x264 ist. Das heißt im Umkehrschluss, dass 50% kleinere Dateien bei fast gleicher Qualität realistisch sein könnten. Ja, die Qualität von Hardwareencodern ist immer schlechter als die von Softwareencodern, aber x265 ist in Software schon extrem lahm. Außerdem unterstützen die neueren NVIDIA Grafikkarten auch B-Frames (https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new). Qualitativ ist das Ergebnis damit angeblich in Ordnung.

Wenn ich Zeit habe, kann ich es mit Ökozid ja mal testen. Den Film gibt es derzeit übrigens nicht mehr in der Mediathek.

Mahlzeit

sidietz schrieb:

Wenn ich Zeit habe, kann ich es mit Ökozid ja mal testen. Den Film gibt es derzeit übrigens nicht mehr in der Mediathek.

Folgende Einstellungen habe ich verwendet:

1

ffmpeg -i test/1920-1_866773.mp4 -c:v hevc -profile:v main10 -preset medium -rc vbr  -c:a copy enctest/sw/default.mkv

Softwareencoding ergibt diese Ausgabe:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

ffmpeg version N-107644-gf56730fb6f Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 11 (Ubuntu 11.2.0-19ubuntu1)
  configuration: --pkg-config-flags=--static --enable-nonfree --enable-gpl --enable-version3 --enable-libmp3lame --enable-libvpx --enable-libopus --enable-opencl --enable-libxcb --enable-opengl --enable-nvenc --enable-vdpau --enable-ffplay --enable-ffprobe --enable-libxvid --enable-libx264 --enable-libx265 --enable-openal --enable-openssl --enable-cuda-nvcc --enable-cuvid --enable-libaom --enable-libsvtav1 --extra-libs=-lpthread
  libavutil      57. 31.100 / 57. 31.100
  libavcodec     59. 41.100 / 59. 41.100
  libavformat    59. 29.100 / 59. 29.100
  libavdevice    59.  8.101 / 59.  8.101
  libavfilter     8. 46.101 /  8. 46.101
  libswscale      6.  8.101 /  6.  8.101
  libswresample   4.  8.100 /  4.  8.100
  libpostproc    56.  7.100 / 56.  7.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test/1920-1_866773.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isom
    creation_time   : 2021-03-11T10:23:18.000000Z
    encoder         : Capella Systems Cambria 4.5.0.51460
    encoder-eng     : Capella Systems Cambria 4.5.0.51460
  Duration: 01:29:40.76, start: 0.000000, bitrate: 6597 kb/s
  Stream #0:0[0x1](deu): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 6465 kb/s, 50 fps, 50 tbr, 50 tbn (default)
    Metadata:
      creation_time   : 2021-03-11T10:23:18.000000Z
      vendor_id       : CAPL
  Stream #0:1[0x2](deu): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 124 kb/s (default)
    Metadata:
      creation_time   : 2021-03-11T10:23:18.000000Z
      vendor_id       : [0][0][0][0]
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> hevc (libx265))
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
x265 [info]: HEVC encoder version 3.5+1-f0c1022b6
x265 [info]: build info [Linux][GCC 11.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-4.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 4 / wpp(17 rows)
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         : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias  : 25 / 250 / 40 / 5.00 
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing lslices=6 deblock sao
Output #0, matroska, to 'enctest/sw/default.mkv':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isom
    encoder         : Lavf59.29.100
  Stream #0:0(deu): Video: hevc, yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 50 fps, 1k tbn (default)
    Metadata:
      creation_time   : 2021-03-11T10:23:18.000000Z
      vendor_id       : CAPL
      encoder         : Lavc59.41.100 libx265
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
  Stream #0:1(deu): Audio: aac (LC) ([255][0][0][0] / 0x00FF), 48000 Hz, stereo, fltp, 124 kb/s (default)
    Metadata:
      creation_time   : 2021-03-11T10:23:18.000000Z
      vendor_id       : [0][0][0][0]
frame= 7087 fps= 44 q=34.9 size=   17920kB time=00:02:22.59 bitrate=1029.5kbits/s speed=0.882x    

Etwas langsamer als Echtzeit (0.882x). Mit nvenc sind es bei gleichen Parametern ca. 5,5x.

Verwendete CPU:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         43 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  16
  On-line CPU(s) list:   0-15
Vendor ID:               AuthenticAMD
  Model name:            AMD Ryzen 7 1700X Eight-Core Processor
    CPU family:          23
    Model:               1
    Thread(s) per core:  2
    Core(s) per socket:  8
    Socket(s):           1
    Stepping:            1
    Frequency boost:     disabled
    CPU max MHz:         3775.0000
    CPU min MHz:         2200.0000
    BogoMIPS:            7550.29
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflu
                         sh mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant
                         _tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqd
                         q monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand
                          lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetc
                         h osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwait
                         x cpb hw_pstate ssbd ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx sma
                         p clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr a
                         rat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassist
                         s pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smc
                         a sme sev
Virtualization features: 
  Virtualization:        AMD-V
Caches (sum of all):     
  L1d:                   256 KiB (8 instances)
  L1i:                   512 KiB (8 instances)
  L2:                    4 MiB (8 instances)
  L3:                    16 MiB (2 instances)
NUMA:                    
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-15
Vulnerabilities:         
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl and seccomp
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, IBPB conditional, STIBP disabled, RSB filling
  Srbds:                 Not affected
  Tsx async abort:       Not affected

Zwischenfazit: Hardwareencoding ist fast 6x so schnell.

Qualität ist natürlich ein weiteres wichtiges Kriterium. In der aktuellen Zeit dürfte aber auch der Stromverbrauch eine Rolle spielen. Die beiden zu testen und zu vergleichen ist aber etwas aufwendiger.

Viele Grüße sidietz

@pixel24 : Ich würde schauen ob man die Filme nicht einfach von der BD (Abkürzung für BlueRay-Disc) kopieren kann (Verzeichnisse durchstöbern ...).

(MakeMkv war für DVDs sehr gut geeignet, es hat die einzelnen VOB-Files in komplette Filme überführt ohne neu zu kodieren und in einen mkv-Container gepackt.)

An der Dateiendung erkennst du dann um welchen Container es sich handelt und mit VLC (einfachste Lösung), kannst du die Codec Informationen erhalten (vermutlich alles h.264 Derivate).

Wenn du dann die Dateien verkleinern willst mit h.265 würde ich es mit ffmpeg und vcodec libx265 versuchen. Im Hintergrund läuft gerade eine Konvertierung mit : ffmpeg ... -vcodec libx265 -crf 20 -preset slow -c:a copy ... . (speed=0.173x)

Ich merke davon nichts (na ja, der Lüfter läuft die ganze Zeit), stört mich nicht. Ausschließlich das Ergebnis ist für mich entscheidend.

Ich hatte den Film bereits einmal mit crf 22 konvertiert, leider sah man, das sich der Kontrast leicht verschlechtert hatte (also ich musste schon mehr als einmal hinschauen um das zu erkennen, h.264 auf 1/5 komprimiert).

Mit vivictpp konnte ich das das Ergebnis sehr gut vergleichen (s. Bsp.: https://forum.ubuntuusers.de/topic/script-zum-vergleich-von-zwei-filmen-mit-vivic/ und das Bild im letzten Beitrag).

Noch ein Hinweis :

VP9 Video ⇒ Opus Audio

H.264/5, avc1, av01 Video ⇒ aac Audio (etwas vereinfacht).