MakeMKV - Qualitätsverlust nach erstellen einer MKV-File?

[Maciek89]

Hallo,

ich möchte aus einer Bluray Untouched einen Remux erstellen. Dies habe ich auch getan, allerdings hat die Qualität abgenommen. Ich beschreibe erstmal meine Vorangehensweise:

Die Bluray Untouched habe ich schon als ISO File auf meiner Festplatte. Die ISO File habe ich in MakeMKV geöffnet und anschließend habe ich den Hauptfilm und 2 Tonspuren ausgewählt. Schon konnte ich anfangen den Film als MKV zu speichern.

Als die MKV Datei fertig erstellt wurde, habe ich beide Filme mit Hilfe von MediaInfo und BDInfo verglichen.

Folgendes Ergebnis kam dabei raus:

BDInfo der Bluray Untouched:

Spoiler: 

                                                                                                                Total   Video                                             
Title                                                           Codec   Length  Movie Size      Disc Size       Bitrate Bitrate Main Audio Track                          Secondary Audio Track
-----                                                           ------  ------- --------------  --------------  ------- ------- ------------------                        ---------------------
00100.MPLS                                                      AVC     2:09:02 28.013.058.048  41.316.584.233  28,94   18,95   DTS-HD Master 5.1 3309Kbps (48kHz/24-bit) DD AC3 5.1 640Kbps

DISC INFO:

Disc Title:     HEREAFTER
Disc Size:      41.316.584.233 bytes
Protection:     AACS
BD-Java:        Yes
BDInfo:         0.5.6

PLAYLIST REPORT:

Name:                   00100.MPLS
Length:                 2:09:02 (h:m:s)
Size:                   28.013.058.048 bytes
Total Bitrate:          28,94 Mbps

(*) Indicates included stream hidden by this playlist.

VIDEO:

Codec                   Bitrate             Description     
-----                   -------             -----------     
MPEG-4 AVC Video        18953 kbps          1080p / 23,976 fps / 16:9 / High Profile 4.1

AUDIO:

Codec                           Language        Bitrate         Description     
-----                           --------        -------         -----------     
DTS-HD Master Audio             English         3309 kbps       5.1 / 48 kHz / 3309 kbps / 24-bit (DTS Core: 5.1 / 48 kHz / 1509 kbps / 24-bit)
Dolby Digital Audio             English         640 kbps        5.1 / 48 kHz / 640 kbps / DN -4dB
Dolby Digital Audio             Czech           640 kbps        5.1 / 48 kHz / 640 kbps / DN -4dB
Dolby Digital Audio             French          640 kbps        5.1 / 48 kHz / 640 kbps / DN -4dB
Dolby Digital Audio             German          640 kbps        5.1 / 48 kHz / 640 kbps / DN -4dB
Dolby Digital Audio             Hungarian       640 kbps        5.1 / 48 kHz / 640 kbps / DN -4dB
* Dolby Digital Audio           Japanese        640 kbps        5.1 / 48 kHz / 640 kbps / DN -4dB
Dolby Digital Audio             Polish          640 kbps        5.1 / 48 kHz / 640 kbps / DN -4dB

SUBTITLES:

Codec                           Language        Bitrate         Description     
-----                           --------        -------         -----------     
Presentation Graphics           English         4,153 kbps                      
Presentation Graphics           English         23,825 kbps                     
Presentation Graphics           Czech           16,440 kbps                     
Presentation Graphics           Czech           3,478 kbps                      
Presentation Graphics           Danish          19,041 kbps                     
Presentation Graphics           Dutch           17,854 kbps                     
Presentation Graphics           Finnish         15,947 kbps                     
Presentation Graphics           French          13,576 kbps                     
Presentation Graphics           French          0,120 kbps                      
Presentation Graphics           German          27,693 kbps                     
Presentation Graphics           German          4,613 kbps                      
Presentation Graphics           Greek           22,301 kbps                     
Presentation Graphics           Hebrew          19,236 kbps                     
Presentation Graphics           Hungarian       18,145 kbps                     
Presentation Graphics           Hungarian       3,099 kbps                      
* Presentation Graphics         Japanese        22,894 kbps                     
* Presentation Graphics         Japanese        5,210 kbps                      
Presentation Graphics           Norwegian       18,435 kbps                     
Presentation Graphics           Polish          14,415 kbps                     
Presentation Graphics           Romanian        16,268 kbps                     
Presentation Graphics           Swedish         17,879 kbps                     

FILES:

Name            Time In         Length          Size            Total Bitrate   
----            -------         ------          ----            -------------   
00001.M2TS      0:00:00.000     2:09:02.609     28.013.058.048  28.944          

CHAPTERS:

Number          Time In         Length          Avg Video Rate  Max 1-Sec Rate  Max 1-Sec Time  Max 5-Sec Rate  Max 5-Sec Time  Max 10Sec Rate  Max 10Sec Time  Avg Frame Size  Max Frame Size  Max Frame Time  
------          -------         ------          --------------  --------------  --------------  --------------  --------------  --------------  --------------  --------------  --------------  --------------  
1               0:00:00.000     0:09:20.518     20.196 kbps     36.387 kbps     00:03:52.398    30.968 kbps     00:03:26.164    27.928 kbps     00:03:21.201    105.282 bytes   424.603 bytes   00:08:59.956    
2               0:09:20.518     0:09:19.559     18.236 kbps     32.246 kbps     00:18:30.192    21.429 kbps     00:15:25.633    20.988 kbps     00:15:25.633    95.076 bytes    295.993 bytes   00:09:26.482    
3               0:18:40.077     0:09:47.378     19.390 kbps     30.571 kbps     00:22:38.940    22.738 kbps     00:23:13.850    22.228 kbps     00:27:30.523    101.089 bytes   359.694 bytes   00:22:24.926    
4               0:28:27.455     0:10:15.072     19.660 kbps     31.426 kbps     00:30:10.141    22.776 kbps     00:32:10.345    22.194 kbps     00:32:05.131    102.496 bytes   289.203 bytes   00:33:49.861    
5               0:38:42.528     0:10:00.057     19.289 kbps     30.462 kbps     00:46:56.355    24.735 kbps     00:46:56.355    24.436 kbps     00:46:56.355    100.566 bytes   392.020 bytes   00:43:31.358    
6               0:48:42.586     0:08:52.740     18.887 kbps     26.865 kbps     00:54:03.323    22.839 kbps     00:49:32.844    21.385 kbps     00:49:32.844    98.470 bytes    264.980 bytes   00:48:45.881    
7               0:57:35.326     0:11:46.372     18.552 kbps     27.865 kbps     00:57:41.291    22.141 kbps     01:02:24.031    21.152 kbps     00:58:27.045    96.722 bytes    276.548 bytes   01:03:09.035    
8               1:09:21.699     0:10:16.991     19.400 kbps     28.954 kbps     01:12:12.286    24.593 kbps     01:12:12.286    23.039 kbps     01:19:10.120    101.143 bytes   385.917 bytes   01:19:09.327    
9               1:19:38.690     0:10:01.267     18.898 kbps     30.814 kbps     01:28:19.627    23.138 kbps     01:20:20.190    22.662 kbps     01:20:31.117    98.524 bytes    285.889 bytes   01:19:41.985    
10              1:29:39.957     0:09:45.126     19.281 kbps     26.526 kbps     01:38:44.209    23.111 kbps     01:31:06.711    22.505 kbps     01:31:41.787    100.523 bytes   346.304 bytes   01:39:18.243    
11              1:39:25.084     0:10:00.349     19.350 kbps     28.441 kbps     01:48:45.310    23.690 kbps     01:48:45.310    23.108 kbps     01:48:45.310    100.881 bytes   384.663 bytes   01:48:57.781    
12              1:49:25.433     0:10:12.612     18.247 kbps     25.503 kbps     01:58:49.539    21.892 kbps     01:59:05.138    21.710 kbps     01:59:14.272    95.134 bytes    266.657 bytes   01:59:38.004    
13              1:59:38.045     0:02:58.303     19.949 kbps     26.385 kbps     02:00:50.952    23.504 kbps     02:00:50.117    22.679 kbps     02:01:56.309    104.004 bytes   296.715 bytes   02:02:15.328    
14              2:02:36.349     0:06:26.260     15.624 kbps     27.352 kbps     02:08:39.920    17.742 kbps     02:08:39.920    17.013 kbps     02:07:32.686    81.463 bytes    258.819 bytes   02:08:40.087    

STREAM DIAGNOSTICS:

File            PID             Type            Codec           Language                Seconds                 Bitrate                 Bytes           Packets         
----            ---             ----            -----           --------                --------------          --------------          -------------   -----           
00001.M2TS      4113 (0x1011)   0x1B            AVC                                     7742,485                18.954                  18.343.502.126  99.802.110      
00001.M2TS      4352 (0x1100)   0x86            DTS-HD MA       eng (English)           7742,485                3.309                   3.202.771.336   18.611.481      
00001.M2TS      4353 (0x1101)   0x81            AC3             eng (English)           7742,485                640                     619.491.840     3.629.835       
00001.M2TS      4354 (0x1102)   0x81            AC3             fra (French)            7742,485                640                     619.491.840     3.629.835       
00001.M2TS      4355 (0x1103)   0x81            AC3             deu (German)            7742,485                640                     619.491.840     3.629.835       
00001.M2TS      4356 (0x1104)   0x81            AC3             ces (Czech)             7742,485                640                     619.491.840     3.629.835       
00001.M2TS      4357 (0x1105)   0x81            AC3             hun (Hungarian)         7742,485                640                     619.491.840     3.629.835       
00001.M2TS      4358 (0x1106)   0x81            AC3             pol (Polish)            7742,485                640                     619.491.840     3.629.835       
00001.M2TS      4359 (0x1107)   0x81            AC3             jpn (Japanese)          7742,485                640                     619.491.840     3.629.835       
00001.M2TS      4608 (0x1200)   0x90            PGS             jpn (Japanese)          7742,485                23                      22.157.569      130.993         
00001.M2TS      4609 (0x1201)   0x90            PGS             eng (English)           7742,485                24                      23.058.014      135.012         
00001.M2TS      4610 (0x1202)   0x90            PGS             fra (French)            7742,485                14                      13.139.410      78.665          
00001.M2TS      4611 (0x1203)   0x90            PGS             deu (German)            7742,485                28                      26.801.612      155.730         
00001.M2TS      4612 (0x1204)   0x90            PGS             nld (Dutch)             7742,485                18                      17.279.477      101.465         
00001.M2TS      4613 (0x1205)   0x90            PGS             ces (Czech)             7742,485                16                      15.910.727      95.446          
00001.M2TS      4614 (0x1206)   0x90            PGS             dan (Danish)            7742,485                19                      18.427.990      106.882         
00001.M2TS      4615 (0x1207)   0x90            PGS             fin (Finnish)           7742,485                16                      15.434.289      91.567          
00001.M2TS      4616 (0x1208)   0x90            PGS             ell (Greek)             7742,485                22                      21.583.208      124.257         
00001.M2TS      4617 (0x1209)   0x90            PGS             heb (Hebrew)            7742,485                19                      18.616.708      110.108         
00001.M2TS      4618 (0x120A)   0x90            PGS             hun (Hungarian)         7742,485                18                      17.560.739      104.401         
00001.M2TS      4619 (0x120B)   0x90            PGS             nor (Norwegian)         7742,485                18                      17.842.058      104.883         
00001.M2TS      4620 (0x120C)   0x90            PGS             pol (Polish)            7742,485                14                      13.951.385      84.245          
00001.M2TS      4621 (0x120D)   0x90            PGS             ron (Romanian)          7742,485                16                      15.744.371      94.518          
00001.M2TS      4622 (0x120E)   0x90            PGS             swe (Swedish)           7742,485                18                      17.303.642      100.723         
00001.M2TS      4623 (0x120F)   0x90            PGS             jpn (Japanese)          7742,485                5                       5.042.271       29.906          
00001.M2TS      4624 (0x1210)   0x90            PGS             eng (English)           7742,485                4                       4.019.157       23.518          
00001.M2TS      4625 (0x1211)   0x90            PGS             fra (French)            7742,485                0                       116.169         683             
00001.M2TS      4626 (0x1212)   0x90            PGS             deu (German)            7742,485                5                       4.464.399       25.979          
00001.M2TS      4627 (0x1213)   0x90            PGS             ces (Czech)             7742,485                3                       3.365.621       20.068          
00001.M2TS      4628 (0x1214)   0x90            PGS             hun (Hungarian)         7742,485                3                       2.999.735       18.039

MediaInfo der erstellten MKV File:

Spoiler: 

Allgemein
UniqueID/String : 106587203952870824411485799224755549124 (0x502FF2E31FB22E677F3826832642F3C4)
Vollständiger Name : D:\Filme\Hereafter\title01.mkv
Format : Matroska
Dateigröße : 20,6 GiB
Dauer : 2h 9min
Gesamte Bitrate : 22,9 Mbps
Kodierungs-Datum : UTC 2011-06-15 11:38:20
Kodierendes Programm : MakeMKV v1.6.10 win(x64-release)
verwendete Encoder-Bibliothek : libmakemkv v1.6.10 (1.2.0/1.1.0) win(x64-release)

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format-Profil : High@L4.1
Format-Einstellungen für CABAC : Ja
Format-Einstellungen für ReFrame : 2 frames
Format_Settings_GOP : M=1, N=20
Codec-ID : V_MPEG4/ISO/AVC
Dauer : 2h 9min
Bitraten-Modus : variabel
Bitrate : 20,2 Mbps
Breite : 1 920 Pixel
Höhe : 1 080 Pixel
Bildseitenverhältnis : 16:9
Bildwiederholungsrate : 23,976 FPS
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.407
Stream-Größe : 18,3 GiB (88%)
Sprache : Englisch

Audio #1
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Format-Profil : MA / Core
Codec-ID : A_DTS
Dauer : 2h 9min
Bitraten-Modus : variabel
Bitrate : 1 561 Kbps / 1 510 Kbps
Kanäle : 6 Kanäle
Kanal-Positionen : Front: L C R, Side: L R, LFE
Samplingrate : 48,0 KHz
BitDepth/String : 24 bits
Compression_Mode/String : / Lossy
Titel : Lossless
Sprache : Englisch

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Format_Settings_ModeExtension : CM (complete main)
Codec-ID : A_AC3
Dauer : 2h 9min
Bitraten-Modus : konstant
Bitrate : 640 Kbps
Kanäle : 6 Kanäle
Kanal-Positionen : Front: L C R, Side: L R, LFE
Samplingrate : 48,0 KHz
BitDepth/String : 16 bits
Stream-Größe : 591 MiB (3%)
Titel : 3/2+1
Sprache : Deutsch

Menü
00:00:00.000 : en:Chapter 00
00:09:20.518 : en:Chapter 01
00:18:40.077 : en:Chapter 02
00:28:27.455 : en:Chapter 03
00:38:42.528 : en:Chapter 04
00:48:42.586 : en:Chapter 05
00:57:35.326 : en:Chapter 06
01:09:21.699 : en:Chapter 07
01:19:38.690 : en:Chapter 08
01:29:39.957 : en:Chapter 09
01:39:25.084 : en:Chapter 10
01:49:25.433 : en:Chapter 11
01:59:38.045 : en:Chapter 12
02:02:36.349 : en:Chapter 13

Zusammengefasst: Die Bitrate der Bluray Untouched beträgt 28942 kbps und die Bitrate der MKV File beträgt nur noch 22903 kbps.

Hier hat schon ein Qualitätsverlust stattgefunden. Ist das normal oder liegt das an dem Programm MakeMKV. Ist es überhaupt möglich eine Bluray Untouched in ein MKV Container zu packen und das ganze ohne Qualitätsverlust?

[anybodyelse]

Bei dem Mediainfo der BD untouched wird die gesamte Bitrate angegeben,sprich die Bitrate des Video+ der aller Tonspuren.
Die MKV hast du ja nur mit 2 Tonspuren gemuxt,daher die niedrigere Bitrate

[Maciek89]

Ok, also hat überhaupt kein Qualitätsverlust stattgefunden oder wie soll ich das verstehen? Woran erkenne ich denn genau, ob die Qualität sich verschlechtert hat?

[anybodyelse]

Beim sogenannten Remuxen findet keine Neukodierung statt,also es bleibt untouched

[doc-mabuse]

Woran erkenne ich denn genau, ob die Qualität sich verschlechtert hat?

Ganz einfach - an der Zeit.
Remuxen dauert nur wenige Minuten - zur Qualitätsminderung wäre aber ein Reencoding noitwenidig, und da tut sich - vor allem bei FullHD - nichts unter mehreren Stunden.

[apn-no-good]

Hallo, ist zwar schon älter aber ich hoffe trotzdem noch eine Antwort zu bekommen.

doc-mabuse schrieb ja das ein remuxen mit makemkv nur wenige minuten dauert.

ich erstelle grade eine mkv mit dem programm und unter "MKV-Datei wird gespeichert" steht als verbleibende zeit: 1:07:01 Stunden

Muss ich jetzt annehmen, da es sich bei mir um eine stunde handelt, das die qualität abnimmt da ich nicht remuxe?

und wenn das so ist, wie kann ich es umstellen??

danke und gruß

apn

[doc-mabuse]

doc-mabuse schrieb ja das ein remuxen mit makemkv nur wenige minuten dauert.

Sorry, mein Fehler.
Vorraussetzung: zwei schnelle Platten, Rohdaten auf der einen Platte, gemuxt wird auf die zweite.
Wenn man nur mit einer Platte arbeitet, die u.U auch nicht die schnellste ist, oder noch schlimmer: mit einer USB-Platte arbeitet, und dabei u.U. noch andere Dinge mit dem Rechner macht - ja, dann kann's auch mal eine Stunde werden.

Muss ich jetzt annehmen, da es sich bei mir um eine stunde handelt, das die qualität abnimmt da ich nicht remuxe?

Nein.
1. sind die mkvtoolnix/die mergeGUI gar nicht in der Lage, irgendetwas zureencoden. Genausowenig, wie man damit eine email verschicken kann. Gibt einfach nicht den nötigen Programcode für sowas.
2. Eine Stunde bei Reencooding in HD ist gar nix.
Diese Nacht lief bei mir Transformers 1.
17 Stunden auf einem i5-Quadcore @ 3,3 GHz.
Und das ist die nackte Videokonvertierung! Rippen, demuxen, Schneiden, Ton- und Untertitelbearbeitung und muxen kommt alles noch etxra.

[apn-no-good]

Sorry, mein Fehler.
Vorraussetzung: zwei schnelle Platten, Rohdaten auf der einen Platte, gemuxt wird auf die zweite.
Wenn man nur mit einer Platte arbeitet, die u.U auch nicht die schnellste ist, oder noch schlimmer: mit einer USB-Platte arbeitet, und dabei u.U. noch andere Dinge mit dem Rechner macht - ja, dann kann's auch mal eine Stunde werden.


Nein.
1. sind die mkvtoolnix/die mergeGUI gar nicht in der Lage, irgendetwas zureencoden. Genausowenig, wie man damit eine email verschicken kann. Gibt einfach nicht den nötigen Programcode für sowas.
2. Eine Stunde bei Reencooding in HD ist gar nix.
Diese Nacht lief bei mir Transformers 1.
17 Stunden auf einem i5-Quadcore @ 3,3 GHz.
Und das ist die nackte Videokonvertierung! Rippen, demuxen, Schneiden, Ton- und Untertitelbearbeitung und muxen kommt alles noch etxra.

Wow, hey klasse du hast ja sogar noch selbst geantwortet nach so langer zeit :-)

alles klaro, ich habe die bluray in einem usb2.0 laufwerk drin dann wird die "lange" zeit daher kommen. thx für deinen rat

[doc-mabuse]

alles klaro, ich habe die bluray in einem usb2.0 laufwerk drin dann wird die "lange" zeit daher kommen. thx für deinen rat

In dem Falle kommt noch erschwerend hinzu, das sogar alles doppelt gemacht wird:
Zuerst werden die Datenströme aus den m2ts-Dateien demuxt und dabei (bei Seamless-Branching-BRs) zusammengefügt (dürftest du irgendwo im Temp-Ordner wiederfinden), dann werden diese extrahierten Datenströme in die mkv neu gemuxt.

Eine Stunde ist dabei schon eine verdammt gute Zeit.

[DragoNick]

17 Stunden auf einem i5-Quadcore @ 3,3 GHz.
Und das ist die nackte Videokonvertierung! Rippen, demuxen, Schneiden, Ton- und Untertitelbearbeitung und muxen kommt alles noch etxra.

Sry bissel off-topic aber kleine Frage:
Hast du viel am Video gedreht/bzw Filter reingemacht? ^^"

[doc-mabuse]

Sry bissel off-topic aber kleine Frage:
Hast du viel am Video gedreht/bzw Filter reingemacht? ^^"

Nur den undot-Filter (wobei ich gerade dazu übergehe, auch TTempSmooth zu benutzen). Und natürlich crop und trim, aber die kosten ja keine Rechnenzeit.

Aber ich encode alles mit preset veryslow, um eine hohe Kompressionrate zu erzielen.

Allerdings bin ich da eher nicht das Maß der Dinge, weil ich nebenbei Administrator hier in der Firma bin und daher jede Nacht und jedes Wochenende meine private "Renderfarm" aus vier i5-Maschinen zur Verfügung habe. Dafür wird halt die CAD-Abteilung an der "Beute" beteiligt .
Dann kann man auch mal was mehr Rechenzeit zu gunsten einer höheren Kompression investieren.


Edit:
Ach ja, die Rechenzeit ist keine Konstante. Es schwankt zwischen wenigen Stunden (CGI-Filme wie ToyStory, #9 etc) und geht bis an die 30 Stunden (Sherlock Holmes, ich rätsel bis heute, was an dem Film so schwer ist - den Directors Cut von Avatar hat er dagegen in 18 Stunden duchgehabt).

[DragoNick]

Ahya ok alles klar, das hat natürlich seine Vorteile
Ich mach im Moment alles mit slower und bin bei ~30h für Expendables Extended gewesen mit allem drum um dran ^^ 1-pass crf 15 auf meinem bescheidenen E8400 der von 2x3 auf 2x4Ghz overclocked ist, will auf die neuen CPUs für den neuen Sockel warten bevor ich ihm mal wieder ein Upgrade verpasse :P

Hast du Erfahrung mit 10-Bit encoding? Da ich das meiste am PC, bzw über den PC oder PS3 Mediaserver streame, hab ich damit keine Probleme, hab aber erst heute meinen 1. eigenen 10 Bit Encode fertiggestellt. Morgen bzw nachdem ich schlafen war, werd ich nen QC mit den beiden Filmen machen und mal ein wenig vergleichen. 9,5GB zu 8,6GB is schon ein ganz schöner Brocken den man an besserer Kompression hat bei gleichen Einstellungen :]

[doc-mabuse]

^^ 1-pass crf 15

15?
Ist das nicht ein wenig übertrieben?
Die gängige Meinung ist, das 18-25 brauchbar seinen, ich kann bei 20 keinen Unterschied mehr sehen und encode BRs in 19, um noch was auf Reserve zu haben - aber 15 halte ich für hoffnungslos übertrieben.

Hast du Erfahrung mit 10-Bit encoding?

Hab mich mich hier in epische Breite drüber ausgelassen: http://board.gulli.com/thread/169318...0bit-videos/2/

Bei mir lag der Unterschied zwischen 0 und 7%.
In Anbetracht der Tatsache, das es völlig inkompatibel zu allen Hardware-Playern ist, halte ich das für witzlos. Da bekomm ich ja mehr raus, wenn ich TTempSmooth().undot() mit verwende (und das sieht keiner) oder FluxSmooth plus etwas schärfen, bringt locker 20%.

Und wenn du auf 15 codierst . . .


In dem Sinne: bevor du mit 10 Bit herunspielst, mach mal ein paar kurze Testencodings mit crf 18-20. Zusammen mit TTempSmooth().undot() würde ich mal schätzen, schaffst du locker 30-50% weniger, ohne das du einen Unterschied wahrnehmen wirst.

Edit:
Wenn du was Speed brauchst, nimm
--ref 5 --bframes 4
oder sogar
--ref 4 --bframes 3
in die x264-Kommandozeile mit auf. Das kostet bestenfalls ein bis zwei Prozent Speicherplatz (wenn überhaupt), dürfte das Encoding aber dramatisch beschleunigen.

[DragoNick]

15?
Ist das nicht ein wenig übertrieben?
Die gängige Meinung ist, das 18-25 brauchbar seinen, ich kann bei 20 keinen Unterschied mehr sehen und encode BRs in 19, um noch was auf Reserve zu haben - aber 15 halte ich für hoffnungslos übertrieben.

Ich sehe sehr wohl Unterschiede, außerdem bin ich krank xD ... >_> Perfektionismus -.-"

Hab mich mich hier in epische Breite drüber ausgelassen: http://board.gulli.com/thread/169318...0bit-videos/2/

Bei mir lag der Unterschied zwischen 0 und 7%.
In Anbetracht der Tatsache, das es völlig inkompatibel zu allen Hardware-Playern ist, halte ich das für witzlos. Da bekomm ich ja mehr raus, wenn ich TTempSmooth().undot() mit verwende (und das sieht keiner) oder FluxSmooth plus etwas schärfen, bringt locker 20%.

Und wenn du auf 15 codierst . . .


In dem Sinne: bevor du mit 10 Bit herunspielst, mach mal ein paar kurze Testencodings mit crf 18-20. Zusammen mit TTempSmooth().undot() würde ich mal schätzen, schaffst du locker 30-50% weniger, ohne das du einen Unterschied wahrnehmen wirst.

Habs gelesen und die Hardwareinkompatibilität ist wahrlich nicht zu leugnen, aber wie sieht die Zukunft aus?

Ich bin ein ziemlicher Anfänger was das encoding anbelangt, die Filter TTempSmooth().undot() sagen mir absolut nichts ^^"
FluxSmooth kenn ich hab ihn aber noch nicht getestet und vorallem wieviel ()?

Mein Encoding von Expendables bei cfr 15 hat mir 10,9% eingebracht, von 9,5Gb auf 8,6Gb nur Video dazu Flac statt DTSHD und ich hab eine 50% Ersparnis
bei fast identischem Bild und identischem Ton ^^
Aber ich bin noch am Suchen welches für mich die besten Settings sind

Edit:
Wenn du was Speed brauchst, nimm
--ref 5 --bframes 4
oder sogar
--ref 4 --bframes 3
in die x264-Kommandozeile mit auf. Das kostet bestenfalls ein bis zwei Prozent Speicherplatz (wenn überhaupt), dürfte das Encoding aber dramatisch beschleunigen.

Danke werd ich testen
Kannst du mir bitte sagen was genau die Settings verändern?

[TomKeller]

Kannst du mir bitte sagen was genau die Settings verändern?

Siehe hier:

http://encodingwissen.de/x264/referenz

[doc-mabuse]

Ich sehe sehr wohl Unterschiede, außerdem bin ich krank xD ... >_> Perfektionismus -.-"

Öhm.
Das behaupten viele Leute auch von mir. Und ich (und auch die Leue, die ich beliefere) konnten bisher bei 19 noch nie einen Unterschied sehen.
Und wir habens auf massig Player/Fernseher/Beamer-Kombinationen getestet.

Habs gelesen und die Hardwareinkompatibilität ist wahrlich nicht zu leugnen, aber wie sieht die Zukunft aus?

Da meine Kristallkugel grad zum Polieren ist, fällt mir eine Aussage hier schwer.

Ich denke mal bei den "Freak-Maschinen", also bespielsweise Popcorn Hour & Clones, wird das recht zügig kommen. Die Anime-Fans fahren voll auf 10 Bit ab, und die sind ja ein Markt (der Vollständigkeit halber: bei denen ist ein Encoding auf --crf 24 der Standard, da siehst du mal, wie weit sich die Meinungen unterscheiden. Ich kann 21 schwach erkennen und finde 23 - das ist der x264-Standard-Wert! - eigentlich schon indiskutabel). Schätze mal, innerhalb von zwei Jahren max.

Allerdings enthalten mittlerweile auch sehr viele Fernseher einen rudimentären MediaPlayer, der mkv/h264/aac unterstützt. Und sowas wird in meinem Bekannten/Freundes/Kollegenkreis sehr viel eingesetzt (wie gesagt, von meinen Encodings gibt es jeweils über 20 dezentrale Sicherheitskopien + ich will's gar nicht wissen wieviel Weitergereichtes ). Und da seh ich ehrlich gesagt in absehbarer Zukunft schwarz. Die sind eher lieblos umgesetzt, zicken teilweise bei exotischen Auflösungen/AspectRatios bei anamorphen Encodings herum und unterstüzen auch Untertitel noch nicht auf breiter Front.
Erschwerend kommt hinzu, das solche Fernseher ja eher ein langlebiges Investitionsgut sind - ich würde daher mit einer zuverlässigen Unterstützung von 10 Bit erst in 10 Jahren rechnen.


Aber wie gesagt, das sind nur meine Überlegungen, der ich halt die Arbeit für einen ganzen Haufen Leute, die sich mit Details oder Technik nicht befassen (wollen) erledige, die einfach nur Stick oder Platte anschliessen und Video schauen wollen. Wer sich als Insel sieht, kann natürlich jetzt schon 10 Bit nutzen.

Ich bin ein ziemlicher Anfänger was das encoding anbelangt, die Filter TTempSmooth().undot() sagen mir absolut nichts ^^"
FluxSmooth kenn ich hab ihn aber noch nicht getestet und vorallem wieviel ()?

undot() ist ein einfacher Filter, der nur nach extremen Störpixeln sucht und diese glättet. Ich hab den anfangs auch sehr misstraut und an die 100 Frames pixelweise abgesucht. Als alter Sci-Fi-Fan hab ich die Befürchtung gehabt, das es die Sterne bei Weltraumaufnahmen erwischen könnte - denn eine heftigere Störung als weisse Pixel auf schwarzem Grund ist ja eigentlich nicht vorstellbar. Ich hab nie auch nur einen einzigen geänderten Pixel gefunden.
Auf der Habenseite: undot() verbraucht keine messbare Rechenzeit und ist eigentlich immer für 1-5% höhere Kompression gut. Solche Störpixel bringen den MPEG-Alorythmus nämlich total aus dem Tritt.

TTempSmooth ist ein Temporaler Degrainer mit Bewegungskompensation, d.h. er filtert temoprales Rauschen (das ist nichts, was man in einem Screenshot erkennen kann! da sieht man nur spatiales Rauschen! Temporal ist, wenn sich das Rauschen bewegt, also das "gegrissel"), hält sich aber von bewegten Bildbereichen fern. Sichtbar wird das nur, wenn das Ausgangsmaterial extrem verrauscht ist (und dann dürfte man schon zu derberen Geschützen greifen), ist aber immer für an die 10% Kompressionsleistung gut.

Ausdrücklich: Auch bei Filmen, die gar kein sichtbares Rauschen aufweisen! Das greift nämlich schon bei Farbnuancen, die unser Auge im bewegten Bild gar nicht mehr auflösen kann. Der erste Schritt jeder Videokompression ist ja die Erstellung von Differenzbildern von vorhergehenden Bildern, und temoprales Rauschen = viel Unterschied und schon haut's die Komressionsrate in den Keller.

Da TTempSmooth() sich von bewegten Kanten fernhält, sollte er immer mit undot() kombiniert werden, damit auch an den Kanten wenigstens die Störpixel beseitigt werden, daher TTempSmooth().undot()

FluxSmoothST() macht das gleiche wie TTempSmooth, ist aber deutlich aufwändiger und geht auch an die bewegten Bildbereiche. Die Standardeinstellung ist (7,7), dabei kann ich aber bei genauen Hinsehen an der einen oder anderen Stelle leichte Unschärfen erkennen, weshalb ich den nur in abgemilderter Form (5,5) einsetzte, dann gibt's keine Unschärfen, verrauschtes Material wird spürbar beruhigt, und bei erstklassigem Material kann ich keinerlei Unterschied erkennen. Dafür bringt's an die 20% bessere Kompressionsraten (allerdings geht hier auch die Rechendauer gut 5-10% in die Höhe, aber das halte ich für nen guten Deal).

Es gibt Leute, die schwören darauf, FluxSmoothST() in den Standard-Einstellungen mit einem leichten Schärfer (LFSmod) zu kombinieren. Die Screenshots sehen auch beeindruckend aus, allerdings geht es hier ja wie gesagt um temorales Rauschen, und das kann man an einem Screenshot nicht beurteilen.

Damit wollt ich am Wochende etwas herumexperimentieren.

Ich bin ein ziemlicher Anfänger

Ich auch, was Filter angeht.
Ich hab halt nur die Erfahrung gemacht, das man (wenn man sich nur an Screenshots orientiert) viel zu schnell hoffnungslos übertreibt. Daher bin ich da ganz vorsichtig.

Es gibt Filter/-ketten, die mit enormen Rechenaufwand irrsinnig tolle Ergebnisse erzielen. Allerdings sind die auch höllisch komplex, haben eine unüberschaubare Vielzahl von Einstellmöglichkeiten und müssen im Prinzip für jeden Film neu angepasst werden. Brauchbar eher nur für Freaks.
Im Moment geht's mir selber nicht um einzelne, perfekt bearbeitete Filme, sondern erst mal um den Aufbau einer ordentlichen Sammlung.
Aber es gibt halt Einzelfälle (Rocky Horror Picture Show, die Qualität kann man nur als gruselig bezeichnen - okay, in dem Fall passt's zum Film ) für die ich mir nach und nach ein paar einfache Standard-Filter ins Werkzeugkästchen legen wollte für leichte Verbesserungen, ohne gleich nach Perfektion zu streben.

Aber moderates Entrauschen ist aufgrund der Arbeitsweise der Videokompression halt extrem wichtig, weil es ordentlich Speicherplatz einsparen kann, daher steck ich da etwas mehr Arbeit rein, um einen universal anwendbaren Filter zu finden.
Werd TTempSmooth() wohl wieder über Bord werfen und FluxSmoothST(5,5) überall benutzen.

Mein Encoding von Expendables bei cfr 15 hat mir 10,9% eingebracht, von 9,5Gb auf 8,6Gb nur Video dazu Flac statt DTSHD und ich hab eine 50% Ersparnis
bei fast identischem Bild und identischem Ton ^^

Ach herrje.

Hier mal ein paar aktuelle Zahlen meiner Versuche:
Testobjekt ist derzeit "Priest".

Original: 15,3 GB
Encoding mit --crf 19 --preset veryslow --ref 6:
Ohne Bearbeitung (nur crop und trim): 3,41 GB
nur mit undot(): 3,22 GB
TTempSmooth().undot(): 2,73 GB
FluxSmoothST(5,5): 2,27 GB - alles nur Video.

Kein sichtbarer Unterschied zum Original. Da kommt schon ordentlich was zusammen - wobei ich auch zugeben muss, das sich Priest offensichtlich extrem gut komprimieren lässt, andere Filme liegen mit Masse im 5-8 GB-Bereich, Avatar bei 13, Rocky-Horror-Picture-Show bei 16 GB (die allerdings alle noch nicht entrauscht).

Aber ich bin noch am Suchen welches für mich die besten Settings sind

Und diese Suche wird niemals enden....

Danke werd ich testen
Kannst du mir bitte sagen was genau die Settings verändern?

Grob gesagt: Sie schränken die Reichweite und Anzahl der Frames ein, in denen der x264 nach "recylcebaren" Makroblocks sucht. Meist wird er gleich im vorhergehenden bzw. folgenden Frame fündig, je weiter die Frames vom aktuellen Entfernt liegen, desto seltener wird daraus ein Makroblock verwendet.
Höhere Einstellungen bringen prozentual immer weniger. Bis drei ist unbedingt sinnvoll, dannach driftet es so langsam in den homöopathischen Bereich ab - aber bei enorm steigenden Rechenaufwand, da die Zeitdauer, einen passenden Makroblock zu suchen in etwa linar mit der Anzahl der zu durchsuchenden Bilder skaliert .


Du kannst übrigends direkt den kleineren Wert benutzen, bframes 4 wird eh schon durch den Level der BR vorgegeben und bringt daher gar nichts (nur bei SD-Material, dort sind durch den kleineren Level erheblich höhere Werte möglich).

[DragoNick]

Siehe hier:

http://encodingwissen.de/x264/referenz

Danke das hatte ich bevor ich die Frage gestellt hatte, auch schon gelesen, leider
ist es ein wenig zu fachlich und habe deshalb so blöd gefragt um eventuell eine
einfachere Antwort zu bekommen ^^"

Grob gesagt: Sie schränken die Reichweite und Anzahl der Frames ein, in denen der x264 nach "recylcebaren" Makroblocks sucht. Meist wird er gleich im vorhergehenden bzw. folgenden Frame fündig, je weiter die Frames vom aktuellen Entfernt liegen, desto seltener wird daraus ein Makroblock verwendet.
Höhere Einstellungen bringen prozentual immer weniger. Bis drei ist unbedingt sinnvoll, dannach driftet es so langsam in den homöopathischen Bereich ab - aber bei enorm steigenden Rechenaufwand, da die Zeitdauer, einen passenden Makroblock zu suchen in etwa linar mit der Anzahl der zu durchsuchenden Bilder skaliert .


Du kannst übrigends direkt den kleineren Wert benutzen, bframes 4 wird eh schon durch den Level der BR vorgegeben und bringt daher gar nichts (nur bei SD-Material, dort sind durch den kleineren Level erheblich höhere Werte möglich).

Danke, so hab ich mir das vorgestellt ^^

Öhm.
Das behaupten viele Leute auch von mir. Und ich (und auch die Leue, die ich beliefere) konnten bisher bei 19 noch nie einen Unterschied sehen.
Und wir habens auf massig Player/Fernseher/Beamer-Kombinationen getestet.

Ok ich hab auch ein wenig weiter experimentiert (Arbeite atm an Expendables) und muss sagen, ich hab das wohl ein wenig falsch gesehen :/ Ein Screenshotvergleich hat mir gezeigt das ich zwischen 15->20 wirkich fast nichts sehe, aber bei einem Screenshotvergleich zwischen 17->20 schon deutlichere Unterschiede sehen kann (hauptsächlich wenn man ein wenig ranzoomt).
Liegt das an dem Resize?
Nicht wundern der resized encode soll für meine Kumpels und meine PSVita sein ^^

Da meine Kristallkugel grad zum Polieren ist, fällt mir eine Aussage hier schwer.

So war das nicht gemeint xP

Ich denke mal bei den "Freak-Maschinen", also bespielsweise Popcorn Hour & Clones, wird das recht zügig kommen. Die Anime-Fans fahren voll auf 10 Bit ab, und die sind ja ein Markt (der Vollständigkeit halber: bei denen ist ein Encoding auf --crf 24 der Standard, da siehst du mal, wie weit sich die Meinungen unterscheiden. Ich kann 21 schwach erkennen und finde 23 - das ist der x264-Standard-Wert! - eigentlich schon indiskutabel). Schätze mal, innerhalb von zwei Jahren max.

24? Ich hab viele meiner aktuellen HD Releases von ner Gruppe die teilweise schon bis zu 13 gemacht hatten und im allgemeinen <17 releasen Und der 10 Bit Unterschied bei einigen Releases ist ya auch gewaltig um Ehrlich zu sein, kA warum das bei Anime so viel mehr ausmacht als bei normalen Filmen. 1 und 2 als kleine Beispiele ^^

Allerdings enthalten mittlerweile auch sehr viele Fernseher einen rudimentären MediaPlayer, der mkv/h264/aac unterstützt. Und sowas wird in meinem Bekannten/Freundes/Kollegenkreis sehr viel eingesetzt (wie gesagt, von meinen Encodings gibt es jeweils über 20 dezentrale Sicherheitskopien + ich will's gar nicht wissen wieviel Weitergereichtes ). Und da seh ich ehrlich gesagt in absehbarer Zukunft schwarz. Die sind eher lieblos umgesetzt, zicken teilweise bei exotischen Auflösungen/AspectRatios bei anamorphen Encodings herum und unterstüzen auch Untertitel noch nicht auf breiter Front.
Erschwerend kommt hinzu, das solche Fernseher ja eher ein langlebiges Investitionsgut sind - ich würde daher mit einer zuverlässigen Unterstützung von 10 Bit erst in 10 Jahren rechnen.


Aber wie gesagt, das sind nur meine Überlegungen, der ich halt die Arbeit für einen ganzen Haufen Leute, die sich mit Details oder Technik nicht befassen (wollen) erledige, die einfach nur Stick oder Platte anschliessen und Video schauen wollen. Wer sich als Insel sieht, kann natürlich jetzt schon 10 Bit nutzen.

Kenn ich und kann ich mich nur anschließen ^^" Bei mir ists nur ein viel kleinerer Kreis im Moment und darunter halt auch eine Anime-Fans daher alle schon auf "10Bit" aufgesprungen

undot() ist ein einfacher Filter, der nur nach extremen Störpixeln sucht und diese glättet. Ich hab den anfangs auch sehr misstraut und an die 100 Frames pixelweise abgesucht. Als alter Sci-Fi-Fan hab ich die Befürchtung gehabt, das es die Sterne bei Weltraumaufnahmen erwischen könnte - denn eine heftigere Störung als weisse Pixel auf schwarzem Grund ist ja eigentlich nicht vorstellbar. Ich hab nie auch nur einen einzigen geänderten Pixel gefunden.
Auf der Habenseite: undot() verbraucht keine messbare Rechenzeit und ist eigentlich immer für 1-5% höhere Kompression gut. Solche Störpixel bringen den MPEG-Alorythmus nämlich total aus dem Tritt.

TTempSmooth ist ein Temporaler Degrainer mit Bewegungskompensation, d.h. er filtert temoprales Rauschen (das ist nichts, was man in einem Screenshot erkennen kann! da sieht man nur spatiales Rauschen! Temporal ist, wenn sich das Rauschen bewegt, also das "gegrissel"), hält sich aber von bewegten Bildbereichen fern. Sichtbar wird das nur, wenn das Ausgangsmaterial extrem verrauscht ist (und dann dürfte man schon zu derberen Geschützen greifen), ist aber immer für an die 10% Kompressionsleistung gut.

Ausdrücklich: Auch bei Filmen, die gar kein sichtbares Rauschen aufweisen! Das greift nämlich schon bei Farbnuancen, die unser Auge im bewegten Bild gar nicht mehr auflösen kann. Der erste Schritt jeder Videokompression ist ja die Erstellung von Differenzbildern von vorhergehenden Bildern, und temoprales Rauschen = viel Unterschied und schon haut's die Komressionsrate in den Keller.

Da TTempSmooth() sich von bewegten Kanten fernhält, sollte er immer mit undot() kombiniert werden, damit auch an den Kanten wenigstens die Störpixel beseitigt werden, daher TTempSmooth().undot()

FluxSmoothST() macht das gleiche wie TTempSmooth, ist aber deutlich aufwändiger und geht auch an die bewegten Bildbereiche. Die Standardeinstellung ist (7,7), dabei kann ich aber bei genauen Hinsehen an der einen oder anderen Stelle leichte Unschärfen erkennen, weshalb ich den nur in abgemilderter Form (5,5) einsetzte, dann gibt's keine Unschärfen, verrauschtes Material wird spürbar beruhigt, und bei erstklassigem Material kann ich keinerlei Unterschied erkennen. Dafür bringt's an die 20% bessere Kompressionsraten (allerdings geht hier auch die Rechendauer gut 5-10% in die Höhe, aber das halte ich für nen guten Deal).

Es gibt Leute, die schwören darauf, FluxSmoothST() in den Standard-Einstellungen mit einem leichten Schärfer (LFSmod) zu kombinieren. Die Screenshots sehen auch beeindruckend aus, allerdings geht es hier ja wie gesagt um temorales Rauschen, und das kann man an einem Screenshot nicht beurteilen.

Damit wollt ich am Wochende etwas herumexperimentieren.

Ich habe bemerkt, das ich FluxSmoothT() schon drin hatte (hatte vor längerer Zeit schon bemerkt das der ganz gute Ergebnisse bringt).
Mit den anderen hab ich jetzt angefangen ein wenig zu probieren und muss noch ein wenig auswerten, aber außer das es Massig mehr an Zeit braucht bei mir gab es bei den resized Expendables Encode keinerlei weitere Kompression ^^" Aber das liegt vermutlich am resize denn bei den 5min encodes die ich jetzt auf 1080 gemacht habe, sehe ich schon MB unterschiede, wie gesagt die muss ich nur erst noch alle auswerten vom Bild her

Ich auch, was Filter angeht.
Ich hab halt nur die Erfahrung gemacht, das man (wenn man sich nur an Screenshots orientiert) viel zu schnell hoffnungslos übertreibt. Daher bin ich da ganz vorsichtig.

Es gibt Filter/-ketten, die mit enormen Rechenaufwand irrsinnig tolle Ergebnisse erzielen. Allerdings sind die auch höllisch komplex, haben eine unüberschaubare Vielzahl von Einstellmöglichkeiten und müssen im Prinzip für jeden Film neu angepasst werden. Brauchbar eher nur für Freaks.
Im Moment geht's mir selber nicht um einzelne, perfekt bearbeitete Filme, sondern erst mal um den Aufbau einer ordentlichen Sammlung.
Aber es gibt halt Einzelfälle (Rocky Horror Picture Show, die Qualität kann man nur als gruselig bezeichnen - okay, in dem Fall passt's zum Film ) für die ich mir nach und nach ein paar einfache Standard-Filter ins Werkzeugkästchen legen wollte für leichte Verbesserungen, ohne gleich nach Perfektion zu streben.

Aber moderates Entrauschen ist aufgrund der Arbeitsweise der Videokompression halt extrem wichtig, weil es ordentlich Speicherplatz einsparen kann, daher steck ich da etwas mehr Arbeit rein, um einen universal anwendbaren Filter zu finden.
Werd TTempSmooth() wohl wieder über Bord werfen und FluxSmoothST(5,5) überall benutzen.


Ach herrje.

Hier mal ein paar aktuelle Zahlen meiner Versuche:
Testobjekt ist derzeit "Priest".

Original: 15,3 GB
Encoding mit --crf 19 --preset veryslow --ref 6:
Ohne Bearbeitung (nur crop und trim): 3,41 GB
nur mit undot(): 3,22 GB
TTempSmooth().undot(): 2,73 GB
FluxSmoothST(5,5): 2,27 GB - alles nur Video.

Kein sichtbarer Unterschied zum Original. Da kommt schon ordentlich was zusammen - wobei ich auch zugeben muss, das sich Priest offensichtlich extrem gut komprimieren lässt, andere Filme liegen mit Masse im 5-8 GB-Bereich, Avatar bei 13, Rocky-Horror-Picture-Show bei 16 GB (die allerdings alle noch nicht entrauscht).

Klingt ganz gut und das mit dem Übertreiben ist mir bei den resized Encodes iwie aufgefallen :/ Leider hab ich grad keine PSVita mehr da um einen realistischen Vergleich zu starten, aber daher bleibt mir im mom nur die SS Variante ^^"

Verstehe ich das richtig? Du cropst den schwarzen Rand deiner 1080p Encodes?

Und diese Suche wird niemals enden....

Das Gefühl habe ich leider auch ^^"

Alles in allem danke ich dir nochma für die ausführlichen Erklärungen

PS: Ich denke ich hab einen Fehler bei einbinden des "neuen" Filters TTempSmooth() bei StaxRip gemacht,
denn es gibt absolut 0 Unterschied, aber er spuckt mir auch keinen Fehler aus >_<"

AVCSource("...\Exp 5min temp files\Exp 5min.dga")
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
FluxSmoothT(4)
UnDot()
LoadPlugin("...\TTempSmooth.dll") TTempSmooth() <--- hier liegt wohl der Fehler :/

Ich hab was gelesen das man wenn ich es richtig verstanden habe noch ne avs oder avsi datei importieren muss also quasi

LoadPlugin("...\TTempSmooth.dll") Import("\TTempSmooth().avsi") McBobU()

[doc-mabuse]

Ok ich hab auch ein wenig weiter experimentiert (Arbeite atm an Expendables) und muss sagen, ich hab das wohl ein wenig falsch gesehen :/ Ein Screenshotvergleich hat mir gezeigt das ich zwischen 15->20 wirkich fast nichts sehe, aber bei einem Screenshotvergleich zwischen 17->20 schon deutlichere Unterschiede sehen kann (hauptsächlich wenn man ein wenig ranzoomt).

Das das nicht wirklich logisch ist, darauf brauche ich ja nicht weiter einzugehen, oder? (unabhängig davon, das ich dir recht gebe, komm ich gleich drauf zurück)

Also...
ähm...
Ich hab jetzt fast zehn Minuten auf den Monitor gestarrt, um irgendeinen Unterschied zu sehen. Mittlerweile bilde ich mir ein, einen Hauch von einem Unterschied in der hellgrauen Reflektion vorne rechts auf dem Kühler des schwarzen LKWs in Bild 2 erkennen zu können.

Und jetzt - sei mir nicht böse - der Realitäts-Check:

1.) du siehst einen Unterschied, weil du direkt zwischen den beiden Bildern hin- und her switchen und Pixelweise vergleichen kannst. In der Realität (Fernseher) wirst du diese direkte Vergleichsmöglichkeit nie haben.
2.) du siehst diesen Unterschied auf einem stillstehenden Bild. In der Realität (eines laufenden Filmes) wirst du diesen Unterschied - selbst wenn du dich darauf konzentrierst - nie sehen können, weil ja alles in Bewegung ist.
3.) In der Realität wird sich überhaupt niemand auf solch "belanglose" Details konzentrieren können, sondern i.A. den Film als Ganzes in sich aufnehmen.

und 4.) jede verlustbehaftete Kompression (und das ist Video immer) ist immer ein Kompromiss zwischen Qualität und Größe (okay, und investierter Rechenleistung). Ich bin durchaus deiner Meinung, das Qualität oberste Priorität sein sollte - aber man kann's auch übertreiben. Wir reden hier ja nicht von zehntel Prozentchen, sondern von ganzen GigaBytes. Wenn ich auf meine 2 TB-Platte statt 200 FullHD-Filme derer 400 unterbringen kann - nun, dafür halte ich obigen Hauch eines Unterschiedes für völlig akzeptabel.

Zusammengefasst: du siehst hier einen Unterschied, weil du einen sehen willst. Außer dir (und uns paar überkritischen Freaks) wird das kein unvoreingenommener Betrachter wahrnehmen.


Aus meiner persönlichen Erfahrung: Ich hab ursprünglich crf 19 für BR's, 20 für DVD's und 21 für DVB-S-Rips vorgesehen. Von letzterem bin ich nach einer gewissen Zeit wieder abgekommen, weil ich mir einbilde, bei 21 etwas zu sehen. Ich kann nicht den Finger drauflegen, selbst auf Screenshots ist so gut wie nichts zu sehen, aber die Filme als ganzes machen auf mich den Eindruck, das irgendwas nicht 100%ig ist. Darum benutz ich jetzt auch für DVB-S-Mitschnitte crf 20.

Ausdrücklich: Ich.
der ich a) sehr Qualitätsbedacht bin; b) weiß, wordrauf ich zu achten habe; c) die Unterschiede regelrecht suche; und d) auch weiß, welcher Film in der Theorie eine schlechtere Qualität haben sollte.

In der Testphase war ich mit mehreren Testencodings bei mehreren Freunden, um mich von der Qualität und der Hardware-Kompatibilität zu überzeugen. Und von denen hat keiner eine Reaktion bei crf 21 und selbst 22 gezeigt - selbst, wenn ich denen gesagt habe, sie sollen mal sorgfältig auf die Qualität achten. Zugegeben: laufender Film, also keine Standbilder und kein direkter Vergleich. Erst bei crf 23 kamen die ersten Stirnrunzler - aber immer mit der Einschränkung, da könne man prima mit leben.

Ist also durchaus von der persönlichen Betrachtungsweise abhängig. Ich will dir wirklich nicht vorschreiben, ob du 18, 19 oder 20 (oder gar 21) nehmen sollst - aber 15... ne, wirklich nicht.

Liegt das an dem Resize?

Schwer zu sagen.
Ich selber resize nur bei ganz seltenen Gelegenheiten (Serien), und auch dann nur sehr sparsam auf anamorphe Norm-Formate (wieder mal die Hardware-kompatibilität).

Aber in Anbetracht der Tatsache, das es natürlich jeglicher Logik entbehrt, das ein Unterschied zwischen 15 und 20 nicht, zwischen 17 und 20 aber doch sichtbar sein soll . . . ja, ich würd auf's Resizing tippen.
Was benutzt du? Lanczos?

Sobald du noch andere Filter benutzt, kann hier die Reihenfolge einen enormen Einfluss haben. Nach meinen Erfahrungen ist es am besten:
1.) Laden (ach was )
2.) sofern nötig deinterlacen
3.) croppen und ggf. trimmen
4.) Entrauschen
5.) alle sonstigen Filter (DeBlock, DeHalo, Farb- und Helligkeitsänderungen, was halt so anliegt - benutz ich außerordentlich selten)
5.) Resizen
6.) Schärfen, wenn nötig

24? Ich hab viele meiner aktuellen HD Releases von ner Gruppe die teilweise schon bis zu 13 gemacht hatten und im allgemeinen <17 releasen Und der 10 Bit Unterschied bei einigen Releases ist ya auch gewaltig um Ehrlich zu sein, kA warum das bei Anime so viel mehr ausmacht als bei normalen Filmen.

Wegen der idealisierten Farbverläufe und der (theoretisch) absoluten Rauschfreiheit moderner, computergenerierter Animes. Schön auf der rechten Seite des ersten Bildes deines zweiten Links zu sehen, da tritt das Banding auf, also ein streifiger Farbverlauf.
Das gibt's in dieser Form bei Real-Filmen so gut nicht, daher macht bei Anime 10 Bit durchaus Sinn, und u.U. auch ein niedrigerer crf. Ich hab bisher nur zwei Animes konvertiert und nur bei einem crf und Bittiefe variiert. Bin dann aber bei crf 19 und 8 Bit geblieben, weil ich den Unterschied (im laufenden Film!) die Mühe für nicht wert befunden habe. Da ist schon wichtiger, ob man tune film oder animation benutzt.

Kenn ich und kann ich mich nur anschließen ^^" Bei mir ists nur ein viel kleinerer Kreis im Moment und darunter halt auch eine Anime-Fans daher alle schon auf "10Bit" aufgesprungen

Naja, man kann da aber auch eine gewisse Flexibilität an den Tag legen.
Codier halt Animes in 10 Bit und crf 15, wenn du den Unterschied wirklich sehen kannst und er es dir wert ist, und benutz 8 Bit und crf 19 für Real-Filme.

Eine Universalmethode wird's nie geben, gute Ergebnisse bei sinnvollem Aufwand/Größe wird nur erzielen, wer flexibel auf die Ausgangslage reagiert.

Ich habe bemerkt, das ich FluxSmoothT() schon drin hatte (hatte vor längerer Zeit schon bemerkt das der ganz gute Ergebnisse bringt).
Mit den anderen hab ich jetzt angefangen ein wenig zu probieren

Das macht dann keinen Sinn!
FluxSmooth ist besser als die anderen, braucht aber etwas mehr Rechenzeit. Wenn du damit schon arbeitest, wären die anderen eher ein Rückschritt (der nur schneller arbeitet)!
btw. FluxSmoothST ist besser als FluxSmoothT, wenn man ihn nicht zu scharf anwendet.

aber außer das es Massig mehr an Zeit braucht bei mir gab es bei den resized Expendables Encode keinerlei weitere Kompression

Autsch.

Kleiner Ratschlag zum testen:
Du kannst mit:
trim(Anfang, Länge) ++ trim(Anfang,Länge) ++ trim( . . .
ein paar Szenen zusammenclippern. Werte sind in Frames. Wenn du also ab der zehnten Minute 30 Sekunden umkodieren willst, dann sind das 10 Min = 600 sec mal 24 fps = ab dem 14400. Frame 720 Frames lang.

Such in deinem Film sechs Szenen: Jeweils eine bei Kunstlicht (Krankenhausszene oder so - möglich in einem Raum ohne Fenster), eine bei Tageslicht/Außenaufnahme und eine bei Nacht/in der Dunkelheit. Und diese drei jeweils als eher statische Dialogszene für die feinen Details und als Aktionszene für die schnellen Bewegungen. Jeweils 20 bis 30 Sekunden reichen völlig aus, um die Qualität verschiedener Kompressionsfaktoren oder Filter zu testen.

So wie oben beschrieben zusammen"trimmen" und du musst pro Testlauf nur noch zwei bis drei Minuten kodieren. Außerdem kannst dafür auch preset veryfast benutzen, an der Qualität macht das keinerlei Unterschied, nur die Größe wird rasant ansteigen - aber zum Testen der Qualität ist das ja wurscht.

Damit dauert ein Testlauf dann nur noch wenige Minuten - sonst kommst du ja nie auf einen grünen Zweig

Verstehe ich das richtig? Du cropst den schwarzen Rand deiner 1080p Encodes?

Klar.
Wofür soll ich denn schwarze Balken kodieren? Die erzeugt jeder Player, der diesen Namen nur halbwegs verdient, doch auch während des Abspielens.

Solltest du schwarze Balken aus Kompatibilitätsgründen brauchen, hier ein Tipp:
Wegschneiden und mit AviSynth selber neue erzeugen, und dabei unbedingt darauf achten, das diese in der Höhe (bei Balken oben und unten) bzw. in der Breite (bei Balken links und rechts) exakte Vielfache von 16 Pixeln groß sind. Wenn nötig dafür ein paar Pixel vom Bild mehr wegschneiden und ggf. damit leben, das das Bild nicht exakt in der Mitte sitzt. Die Balken an sich sind nämlich nicht das Problem, sondern die harte Grenze zum Bild. Bei exakten Vielfachen von 16 liegt diese Grenze immer an einer Makroblock-Grenze, und da haut's dann den MPEG-Algorythmus, der auf harte Kanten gar nicht kann, nicht durcheinander. Außerdem ist der Balken dann wirklich tiefschwarz und nicht dunkelgrau mit Rauschen, wie bei manchen schlecht ausgenommenen Filmen.

Das benutzt ich nur bei der einen oder anderen BluRay an den Seiten, denn hier muss die Breite unbedingt 1920 Pixel betragen, da die Player sonst hochskalieren, und das tut der Qualität nicht gut.

Alles in allem danke ich dir nochma für die ausführlichen Erklärungen

Jederzeit

PS: Ich denke ich hab einen Fehler bei einbinden des "neuen" Filters TTempSmooth() bei StaxRip gemacht,
denn es gibt absolut 0 Unterschied, aber er spuckt mir auch keinen Fehler aus >_<"

Kein Wunder.
Du holst doch mit FluxSmooth schon das meiste an Rauschen raus, noch einen weiteren Rauschfilter hinterher zu jagen, kann doch nichts mehr bringen. Das sind nur Alternativen, nicht für den gleichzeitigen Einsatz gedacht.

Ich hab was gelesen das man wenn ich es richtig verstanden habe noch ne avs oder avsi datei importieren muss also quasi

LoadPlugin("...\TTempSmooth.dll") Import("\TTempSmooth().avsi") McBobU()

Nein.
Laden oben mit
LoadPlugin("...\TTempSmooth.dll")
Anwendung dann später mit
TTempSmooth()
mehr ist nicht nötig.
Aber wie gesagt, Doppeltgemoppelt mit FluxSmooth bringt eh nix.

Ach ja:
ConvertToYV12()
ist überflüssig. Und bei FluxSmooth solltest du mal die ST-Varainte testen.



Edit:
Zu obiger Liste (mit den Filtern) Punkt 6)
Bei Zeichentrick/Animes soll schärfen eher kontraproduktiv sein. Besser ist hier angeblich ein spezieller Filter für diese Filmgattungen, der Kanten verstärkt.
Nus höhrensagen, noch keine eigenen Erfahrungen!