Transkodierungs Einstellungen

-Dekodieren (sicher, dass du nicht kodieren meinst?): Was am schnellsten ist, qualitätsunterschied sieht man mit freiem auge nicht bzw. nur messbar.

-deinterlace kommt aufs quellenmaterial an ob das interlaced ist.

-sound: würde ich die originalspur behalten ohne neu zu kodieren, spart zeit und ist bessere qualität.

3. ja sound normal eh durchschleifen, aber mein Fernseher kann kein DTS-HD MA am Receiver weitergeben (hdmi arc). Ich habe mir vor kurzem zB die neue King of Queens HD Superbox kauft, die unnötigerweise eben Stereo DTS-HD MA hat und die muss ich entweder AAC oder AC3 umwandeln.

2. hab mal testweise eine "Lost" BD genommen von der ich fix weiß dass sie Progessive ist, da war Deinterlace gar nicht auswählbar. Anscheinend erkennt DVDFab ob interlaced.
Bewegungen sind schärfer bei einer interlaced KoQ Folge mit deinterl. vom Fernsehr als deinterlaced von DVDFab. Jetzt muss ich halt noch abwegen ob das +40% größe gerechtfertigt.

Edit: anscheinend ist KoQ doch "nur" DTS obwohl anders beschrieben, also durchschleifn geht

Zitat von config

2. hab mal testweise eine "Lost" BD genommen von der ich fix weiß dass sie Progessive ist, da war Deinterlace gar nicht auswählbar. Anscheinend erkennt DVDFab sowas.
eine interlaced KoQ Folge sieht mit deinterl. am Fernsehr besser aus als von DVDFab. Warum hat interlaced +40% größe?

Meine Faustregel; es gibt keine Faustregel

Nimm das was im Endeffekt besser aussieht auf deinen Endgeräten (selbst wenn du es dir nur einbilden solltest - für dich muss es schließlich passen). PUNKT!
-> bei BD gibt es zwar wie gesagt kaum Interlaced Inhalte auf der BD selbst (das bewegt sich in unseren Breitengraden vermutlich im Promille-Bereich) aber es gibt eben 1-2 Ausnahmen und die Crux an der Sache ist die; das Ausgangsmaterial kann sehr wohl Interlaced gewesen sein - wobei es sich auch hier eher im niedrigeren einstelligen Prozentsatz bewegen sollte, speziell bei Kino dürfte es genau genommen gar nicht vorkommen. Aber man weiss nie wie die BD genau entstanden ist, von welchem Master weg, mit welchen Settings, wie "gut" dort skaliert/de-interlaced wurde usw. -> und dieses "erkennen" vom Format das du angesprochen hast basiert üblicherweise nicht auf Bildanalyse sondern rein auf Metadaten bzw. User/Bit-Flags die irgendwann mal vom jemanden oder etwas (zb. nem Encoding/Authoring-Programm) gesetzt wurden. Und die können mitunter falsch sein - dem kann man nicht vertrauen. Es gibt zwar Spezifikationen an die man sich halten muss wenn man eine BD pressen lässt - anderenfalls wird das BD-Plant (Image-File) abgewiesen - aber auf einzelne falsch gesetzte Metadaten wird da nicht immer geachtet wenn die restliche technische Abnahme stimmt (oder generell ne Klausel vorhanden ist, dass der Auftraggeber selbst für die korrekte techn. Ausführung vorhanden ist).

Lange Rede kurzer Sinn; zu mindestens 90% wird bei BD eher progressiv passen - aber nimm einfach das Setting das dir besser gefällt, dann stellt sich die Frage gar nicht ob "korrekt" oder nicht... Du bewegst dich sowieso schon in einem Rahmen der eine rechtliche Grauzone darstellt - weiterverbreiten sowie öffentliche Vorführung ist dann aber definitiv ausserhalb dieses Rahmens also 'darf' es nur für dich passen, du willst es ja nicht anderen Leuten zur Verfügung stellen - right?

Wegen Interlaced und größeren Files; DCT ist nicht recht effektiv bei scharfen Details was die Kompression anbelangt. Und viele scharfe bzw. gerade Linien - wie es sich bei Deinterlaced-Bildern nun mal zwangsweise darstellt (völlig unabhängig vom restlichen Bildinhalt weil der ja selten komplett einfärbig ist) sind dadurch einfach 20% größer, bzw. die 40% gesamt weil es ja Halbbilder sind... Mathematisch ne logische Sache, wenn's dich näher interessiert -> siehe Wikipedia;

Die lange Fassung:

Ich rippe ja jetzt schon seit vielen Jahren, wenn auch anders als du. Im Endeffekt verarbeite ich alle Streams einzeln, Video aktuell direkt mit x264, Audio per FHG AAC (fhgaacenc.exe + Fraunhofer DLL vom WinAmp 5.666) oder avconv/ffmpeg mit FDK AAC. Decoding mache ich sowieso per avconv (aus libav, quasi dasselbe wie ffmpeg) und pipe das dann in fhgaacenc rein. Das funktioniert unter Windows wie auch Linux und BSD, auf letzteren rennt fhgaacenc halt per Wine, also z.B. so für einen DTS Stream:

Code:

avconv -i <INPUT>.dts -f wav - | wine cmd.exe /c "C:\\Program Files\\FhG-AAC\\fhgaacenc.exe" --vbr 6 - <OUTPUT>.m4a

Speziell beim Audio kann es schon sein, daß sich viel an Platz sparen läßt, wennst arge Streams wie DTS-HD MA, Dolby True HD oder LPCM (bei einigen Indiefilmen) nicht durchschleifst. Meines Erachtens nach ist AAC-LC hier die beste Wahl, mit maximaler Quali per --vbr 6 im Falle von FHG AAC.

Für mich ist das hörtechnisch vollkommen transparent zu DTS-HD MA oder anderen, und noch immer kleiner als die 1.5Mbit DTS oder sogar 640kbit AC3 Corestreams, wennst das lossless Zeug von DTS oder Dolby wegwirfst.

Was Video angeht sind meine Settings aber eher antiquiert, weil ich Dateigrößen per Bitratenrichtwert im 2-pass direkt anvisiere anstatt konstante Qualitätslevels per CRF, so wie es heutzutage meist gemacht wird.

Aktuelles x264 Command, 2 Passes für Anime (Platzhalter beachten):

Code:

x264 --preset veryslow --tune animation --b-adapt 2 --b-pyramid normal -f -2:0 --bitrate <RATE> --aq-mode 1 -p 1 --slow-firstpass --stats v.stats -t 2 --no-fast-pskip --cqm flat --non-deterministic --demuxer lavf <INPUT> -o /dev/null && x264 --preset veryslow --tune animation --b-adapt 2 --b-pyramid normal -f -2:0 --bitrate <RATE> --aq-mode 1 -p 2 --stats v.stats -t 2 --no-fast-pskip --cqm flat --non-deterministic --demuxer lavf <INPUT> -o pass2.264

Und für Realfilme:

Code:

x264 --preset veryslow --tune film --b-adapt 2 --b-pyramid normal -r 3 -f -2:0 --bitrate <RATE> --aq-mode 1 -p 1 --slow-firstpass --stats v.stats -t 2 --no-fast-pskip --cqm flat --non-deterministic --demuxer lavf <INPUT> -o /dev/null && x264 --preset veryslow --tune film --b-adapt 2 --b-pyramid normal -r 3 -f -2:0 --bitrate <RATE> --aq-mode 1 -p 2 --stats v.stats -t 2 --no-fast-pskip --cqm flat --non-deterministic --demuxer lavf <INPUT> -o pass2.264

Das Tune "film" sowie "animation" kann u.a. dem Tune "grain" weichen, wenn das gesamte Medium wirklich mit wildem Grain bedeckt ist.

Zusammengemuxed wird per MKVtoolnix.

Für Anime nehme ich i.d.R. eine Bitrate von 2.000kbit/s, für Realfilme kann es bis 10.000kbit/s gehen. Das schwankt, weil ich eben Dateigrößen anvisiere um einen berechenbaren Speicherplatzverbrauch über große Mengen von Mediendaten zu haben, und damit eine Möglichkeit, die Entwicklung am Storage prognostizieren zu können.

Die kurze Fassung:

Ich kenn mich damit zwar ned aus, aber man hört, CRF 16 sei der Sweet Spot für alles. Und 20 noch irgendwie brauchbar. Außerdem: AAC-LC ist effizienter als alles in Sachen Quali pro Byte, also AAC-LC!

The End.

Meine Aussage betraf eher meine Einstellung von Target Bitrates anstatt CRF. Bei CRF solltest ja (sofern die Analyse des Encoders korrekt ist) eine durchgehend konstante Qualität über alle Medien erhalten, solange du den Faktor beibehältst.

Mein Verfahren stellt aber durchgehend konstante Dateigrößen sicher, bei z.T. wechselnder Qualität. Das ist es, was viele Leute heutzutage als nicht mehr besonders sinnvoll erachten, weil konstante Qualität eben als wichtiger einzustufen wäre als Speicherplatz absehbar verplanen zu können. Zumindest im privaten Bereich.

Sehe ich auch ein, nur mir ist der Teil mit "immer ca. gleich großen Files" einfach wichtiger, auch wenn ich dadurch hier und da zuviel oder etwas zuwenig Bitrate investiere. Früher wurde das was ich mache viel häufiger praktiziert. Heute deutlich weniger, sicher auch weil Massenspeicher so billig sind.

Für die meisten Leute wird ein --crf Target wohl richtiger/besser sein als ein --bitrate Target.

Deine Intel GPU an sich kanns ja. Da wird die Software wohl einfach die Skylake GPU noch nicht korrekt erkennen, schätze ich.

Es wäre aber ohnehin darauf hinzuweisen, daß GPU Encoding (durch die notwendige, sehr hohe Parallelisierung) i.d.R. schlechtere Ergebnisse liefert als x264/libx264, also qualitativ. Das war auch der Grund dafür, warum x264 eine Threaddeckelung hat, weil's ab einer gewissen Threadanzahl durchs Slicing zu qualitativen Einbußen kommt. Der Encoder hat bis heute nur im Lookahead Code eine OpenCL Option.

Wenn dir die daraus reultierenden, minimalen Unterschiede egal sind, dann ok. Warum aber die GPU nicht erkannt wird, hm. Einfach Mal den Entwickler der DVDFab Produkte fragen?

sollte eine zoom-einstellung vom fernseher sein

handbrake nimmt nämlich standartmässig die balken weg (kann man aber abdrehn)
dann is ein full-hd video aber nur noch ca 800px hoch