Frage Hilfe bei h.265 und Handbrake

1. Fast ist tatsächlich bei x265 ein Sweetspot wie viele schon durch "Forschung" herausgefunden haben. Fast ist öfter mal sogar kleiner als slow oder veryslow. Daneben ist der Encode auch schneller. Dies kann damit zusammenhängen, dass beim fast preset für die meisten Videomaterialien überflüssige Kodierungen weggelassen werden, die nur die Prozessorlast erhöhen und selten nutzen bringen. Tipp: Beschäftige dich gleich mit AV1, denn x265 ist schon bald "veraltet".

1.1 CRF 16/fast sollte in allermeisten fällen ausreichen. Besonders bei 10 bit. Mit einem 2700x sollte da eine Folge in ca. 10 bis 15 min. fertig sein, zumindest kenne ich das so bei ffmpeg.

2. Wenn du hier richtig deine Zähne reinhauen willst, dann guck dir die Dokumentation der Encoder an. FFMPEG (übrigens ein tool, das ich Handbrake immer vorziehen würde und mit .bat-Dateien auch leicht zu benutzen ist) hat bei der hauseigenen Dokumentation eine Zusammenfassung aller Parameter der integrierten Codecs. Ansonsten tun es relativ oberflächliche Guides aus dem Netz, da die "presets" oder Parameter wie "CF" schon von den Entwicklern so zurechtgelegt wurden, dass man sich mit den Detailkram kaum beschäftigen muss. Tipp: Nimm ffmpeg, da hier wirklich low level gearbeitet wird und man sich mit den Parametern beschäftigen MUSS. Die Website von FFmpeg hat auch gute Kurzanleitungen und Dokumentationen, allerdings auf Englisch.

3. Audioformate sind allesamt nur eine Anreihung von 0 und 1 mit viel Hokus-Pokus. Ideal ist WAV oder FLAC, da hier wirklich ein roher Bitstream, meist mit 48000 Abtastungen pro Sekunde und 16 Bit "Dynamik" vorliegt, manchmal sogar mehr. Alles, was danach kommt, sind verlustbehaftete Codecs, die Platz sparen wollen, dabei aber Qualität opfern. Dies ist auch manchmal zwingen nötig, da sonst so ein Filmsoundtrack mit 7.1 Lossless-Audio ohne Probleme größer werden kann als die Videodatei selbst. Tipp: Für die Basics erst mal das hier: https://de.wikipedia.org/wiki/Digitalaudio . Dann hast du das Gröbste verstanden."

Bonustipp. Experimentiere viel. Im Zweifel immer die Wikipediaseiten angucken, da hier detailliert aber nicht so detailliert wie die offiziellen Dokumentationen erklärt wird.

Mit Handbrake selber kann ich dir nicht helfen, aber von dem, was ich bisher bezüglich Audio- und Videokodierung mitbekommen habe, schneidest du hier ein sehr weites Thema und ein umfangreiches Projekt an.

Ich spreche hier als Laie in sehr allgemeiner Form, weil ich keine Fehlinformationen verbreiten möchte und gerade keine umfangreiche Recherche starten möchte. Mein Ziel ist es hier, Fragen in den Raum zu werfen, die als Ideen dienen können. Direkte Antworten kann ich nicht liefern.

Es gibt viele Wege, Daten zu komprimieren, und bei Bildern, bzw. Video kann das z.B. über das Pixelmaß, die Farbtiefe, die Genauigkeit der dargestellten Unterschiede von einem Bild zum anderen, die Anzahl dargestellter Bilder... sein. Das wären die einfachsten Parameter, die mir spontan einfallen, aber eine Verlustbehaftete Kompression zur Folge hätten.
Und so kommst du schon mal zu deiner ersten wichtigen Entscheidung: möchtest du verlustfrei oder verlustbehaftet komprimieren? Was hast du für Vorwissen im Bereich Datenkomprimierung? (Ich selber nicht viel, aber den Punkt sehe ich als wichtig einzuschätzen für dich selbst.)

Vermutlich ist der Serienanbieter Verluste eingegangen, um die Episoden zu kodieren. Also müsstest du wissen, welche Verluste für dich vertretbar sind, oder überhaupt relevant, und welche sofort anfangen würden, die Videoqualität zu beeinträchtigen. Vielleicht hat die Person beschlossen, dass das Bild weniger wichtig ist als der Ton, und das Audio kaum angerührt, aber dafür bei der Videospur mehr Kompromisse gemacht. Es wäre eine Überlegung wer, nachzufragen. Durch Imitation kann man gut lernen. Aber dachte darauf, dass du vielleicht nicht alle Verluste wahrnehmen musst, andere aber schon. Überlege dir, ob dein Equipment ausreicht, um Videos gut "bewerten" zu können. Das braucht bestimmt auch etwas Training und Schulung deiner Augen.

All die Parameter und Zeitangaben die du nennst, sind sehr stark abhängig von dem Inhalt des Videos, das wird hier niemand für dich einschätzen können ohne es selber zu sehen. 1 Stunde für wie viele Frames? Welches Pixelmaß? Gibt es viele rasche Wechsel der vorhandenen Farbpaletten im Bild? Wie lang ist das Video...?
Was aber ein Hinweis sein kann ist: je nach Kodierungsverfahren wird mehr oder weniger Rechenzeit benötigt, um die Daten zusammen zu packen und Wiederholungen/Muster/Worauf-auch-immer-das-Verfahren-beruht zusammen zu ordnen. Das hat natürlich einen großen Einfluss auf die Kodierungszeit, weil dein System mehr rechnen muss, wenn es "mehr" (besser) optimieren muss.
DAMIT hast du aber je nach Verfahren wieder Kosten die beim Auslesen bezahlt werden müssen: muss mehr in den Arbeitsspeicher geladen werden? Ist die Dekodierung auch rechenintensiv? Wie gut kommt ein gewöhnlicher Player/Filter damit klar? Kostet die Dekodierung mit Verfahren X vielleicht mehr Strom als mit Verfahren Y?

Ein kurzer Schlenker in den Audio-Bereich: das FLAC-Format hat zum Beispiel den Vorteil, dass es verlustfrei ist. Alle Tondaten, die bei der Kodierung vorhanden waren, sind es auch zum Zeitpunkt der Dekodierung. Das macht das Format sehr geeignet für Archivierung. Allerdings braucht es viel Speicherplatz.
Das Format unterstützt verschieden starke Kompressionsstufen, um den notwendigen Platz zu reduzieren, aber höhere Kompressionsstufen sind rechenintensiver zu schreiben und zu lesen. Dadurch ist dieses Format zum Beispiel wenig geeignet für mobile Geräte, die es weniger gut abspielen können oder damit mehr von ihrer wertvollen Akkukapazität verbrauchen, als mit simpleren Formaten.

Im Endeffekt listet Handbrake in Form von seinen Menüs verschiedene Kodierungsverfahren auf. Wenn du Handbrake expertenmäßig bedienen können willst, musst du wissen, wie diese Verfahren funktionieren. Das wirst du nicht über Handbrake-kundige oder -Dokumentationen alleine heraus finden, sondern indem die die Verfahren selber recherchierst und versuchst, sie zu verstehen.

Meine Einschätzung ist, dass du für den Anfang schauen solltest, ob:
- Du hilfsbereite Übersetzer findest
- Du Leute findest, die du fragen kannst
- Du bereit bist, deutlich über das Programm selbst hinaus schauen zu müssen
- Du weißt, was du erreichen willst. und zu welchem Preis (im Sinne von Verlust/Verlustfrei, Leistungsintensiv oder nicht, welche/wie viel Ressourcen das Lesen benötigt, Kodierungsdauer, etc).
- Du denkst, deine Versuche und Tests hinreichend bewerten zu können in Bezug auf deine Ziele.

Ein Letzter Punkt zum Schluss: eine PDF ist sehr starr und bietet wenig Freiraum für andere, um Anmerkungen o.ä. zu hinterlassen. Vielleicht bietet sich da eine Wiki-ähnliche Web-Plattform eher an. Zumal dein Anliegen nicht an Anime gebunden ist, und so vielleicht auch mehr Leute erreichen kannst, die fachkundig sind aber nicht zusätzlich noch die Bedingung erfüllen müssen, Anime als Hobby zu haben.

Was ich gerne bei Recherchen benutze ist, eine englische Suche zu starten und, wenn ich dann z.B. auf der englischen Wikipedia-Seite lande, die deutsche Übersetzung aufzurufen. So finde ich Übersetzungen heraus von Fachwörtern, die nicht unbedingt in Wörterbüchern zu finden sind, und kann mir über die deutsch Seite das deutsche Vokabular aneignen mit dem ich weiter suchen kann. Das hilft sehr wenn ich nicht weiß, wonach ich eigentlich suchen soll. Eine Liste der unklaren Punkte kann auch hilfreich sein, um dir einen Überblick des Programms zu verschaffen und dir die Schlüsselwörter vor Augen zu führen.

EDIT: +++FFMPEG Danke an @elkeZ für den Hinweis, ich kann das nur bestätigen!

An dem Github-Repository von Handbrake ist leicht zu erkennen, dass Handbrake unter anderem auf FFMPEG zugreift... wie viele andere Software auch in dem Bereich. Du wirst wohl oder übel herausfinden müssen, was Handbrake damit macht, und dementsprechend auch, wie FFMPEG funktioniert. Wenn es um transkodierung geht, kannst du um FFMPEG schlecht herum manövrieren, weil es einfach eines der besten und verbreitetsten Programme in dem Bereich ist. Trotz dessen, dass es keine graphische Oberfläche hat und Mühe bei der Einarbeitung kostet.

Ansonsten gibt es hier ja auch die offizielle deutsche Doku von Handbrake, die kann sicher auch noch Hinweise geben, oder Leute auflisten, die du fragen kannst.

Mysticdragon schrieb:

Ich halte von ffmpeg nicht viel ist für mich genauso wie Freemake schmutz.
Da ich das schonmal nutzen wollte und nur Fehlermeldungen bekam und nicht richtig funktionierte. Beziehungsweiße überhaupt nicht funktionierte weil es Dateiformate komplett ablehnte wenn ich es richtig in Erinnerung habe. Da es mit mkv und mp4 nicht umgehen kann, ich brauch ein einfaches Programm da ich keine lust habe die Dateien zu zerlegen und wieder zusammenzufügen. Deswegen lehne ich auch ffmpeg ab.
Glaub das war sogar das Problem.
---> Ab hier zweifel ich nachinein an, lasse ich dennoch mal so stehen.
Und ein Programm das von anfang an nicht funktioniert brauch ich auch nicht.
Zumindest wenn ich aus den Fehlermeldungen nicht schlau werde und keine Lösungen finde.
Weiß nimma was das für Fehler waren, aber ffmpeg habe ich jedenfalls für immer abgehakt ich habe mich in Handbrake verliebt.
Bietet genauso viele Funktionen wenn nicht sogar mehr und ist einfacher zu bedienen, da haben sich zumindest die Entwickler zumindest viel durchdachter als bei ffmpeg umgesetzt.

Ansonsten werde ich dann wie du sagtest herum experimentieren.
Aber wie gesagt würde ich gerne mal wissen was für Parameter es alles gibt und was diese bewirken.
Und am besten auf deutsch, falls es eine Seite gibt wäre ich darüber sehr dankbar.


@Xezarior Sehr langer Beitrag lese ich mir später oder morgen durch. Bin grad mitten in etwas drin. Danke.


P.S: Mit pdf meine ich ein ebook ähnliches mit anklickbares Inhaltverzeichnis. Hab da schon gewisse Ideen. Will das so umsetzen das man sowas auch unterwegs auf einen Tablet zu lesen ist^^ Allerdings schätze ich das dies sowieso erst im nächsten Jahr was wird, da ich im diesen Experimentieren und Informationen sammeln muss. :)

Zum Vergrößern anklicken....

no offense aber du steigst in eine thematik ein
es klappt etwas nicht so wie du dir es vorstellst
und automatisch ist es schlecht oder wie du es betitelst "schmutz".
also mit dem durchalte vermögen und der einstellung kannste es gleich lassen.

bin an dem thema jetzt über ein jahr dran und behaupte mal ich habe nichtmal ein 25% fortschritt
da ich a) unglaublich viele sachen noch nicht verstehe
b) mit meinen encodes nicht zufrieden bin
c) es so unglaublich viele möglichkeiten, optionen und wege gibt um an ziel zu kommen.

supersonik schrieb:

[...]
bin an dem thema jetzt über ein jahr dran und behaupte mal ich habe nichtmal ein 25% fortschritt
da ich a) unglaublich viele sachen noch nicht verstehe
b) mit meinen encodes nicht zufrieden bin
c) es so unglaublich viele möglichkeiten, optionen und wege gibt um an ziel zu kommen.

Zum Vergrößern anklicken....

Hallo @supersonik , was sind denn die Ressourcen die du bei deinen Versuchen benutzt hast, womit hast du gelernt? Oder gibt es bestimmte Seiten/Tutorials/Dokmentationen, von denen du abraten würdest? Hast du bisher nur mit FFMPEG gearbeitet? Ich landete bisher meistens auf SuperUser oder StackOverflow mit Beispielen von Kommandozeilenbefehlen die grob das gemacht haben, was ich mit FFMPEG vor hatte.

Woran bestimmst du die Qualität deiner Encodes, warum bist du mit ihnen nicht zufrieden?
Das Thema macht mich neugierig, auch wenn ich nicht selber groß anfangen werde, damit zu experimentieren (ich lese eher gerne mit und lerne dazu). Aber vielleicht können diese Fragen dem Thread und @Mysticdragon ja einen kleinen Kick voran geben.
(Falls ich damit off-topic lande, bleibe ich gerne von nun an einfacher stummer Leser ;) .)

@supersonik Das Schlimme ist ja auch, kaum hat man sich mit einem Codec auseinander gesetzt und den (vermeintlich) besten Weg gefunden, kommt gleich der nächste Codec hinterher, der alles (zumindest angeblich) besser macht. - Und dann beginnt das ganze Spiel von neuem.

Also ich muss sagen, ich finde Handbrake ganz gut. Ist halt 'ne GUI für ffmpeg. Es zeigt ja sogar die Parameter an und wenn ich mich recht entsinne, kann man auch selbst noch welche angeben. Ich finde es halt deshalb einfach, weil ich mir kein Script zusammen schreiben wollte für 2 mal im Jahr encoden und es ist halt GUI.

Meiner Meinung nach ist es aber wie @elkeZ sagte, will man das richtig machen will sollte man ffmpeg direkt mit entsprechenden Scripten benutzen. Am besten selber kompilieren, damit es auch perfekt auf den Rechner passt und den Prozessor (oder die GFX) richtig benutzt. Der Unterschied zwischen der "läuft überall" und der "läuft nur auf deinem Rechner" Version liegt bestimmt bei 30%, oder höher. Ich als Linux User (ja fallt jetzt ruhig über mich her) habe es da ja recht einfach, mit ein paar Zeilen, habe ich das Ding kompiliert.

Klar ist aber auch, das lohnt nicht für Leute wie mich, die das maximal 2x im Jahr machen. Obwohl ich ja schon mal wieder Lust hätte...

Qualität kann man auf verschiedene Weise prüfen. Es gab mal, wahrscheinlich auch noch immer, Tools um einzelne Bilder zu extrahieren und zu vergleichen. Da gab es dann so Prozent Ausgaben wie Blockung (also diese hässlichen Blöcke bei Farbverläufen) und so. Da hatte man dann eine Übersicht "wie schlimm" es im Gegensatz zum Original geworden ist. (Ich kenne das noch von MPEG1 Zeiten).

Ansonsten kann man auch selber sehen und hören und dann die Qualität abschätzen. Es ist ja nun mal so, dass egal wie man es mach, Daten verloren gehen. Gut ist halt wenn es nichts wichtiges war. Bzw. hinzugefügte Artefakte nicht stören.

Wenn jemand Bock hat, würde ich da jetzt vielleicht auch mitmachen, ich hätte etwas Rechenzeit übrig.

Ich benutzte Tadarr, dort kann ich genau bestimmen was mit meinen Dateien passiert, z.b. unnötige Untertitel oder Tonspuren entfernen oder halt alles auf x265 codieren.
Tadarr scannt die Ordner und verarbeitet nach meinen erstellten Regeln alles automatisch.

Kommt i-wann mal x266, brauche ich es nur dort mit ein paar Mausklicks innerhalb von Sekunden umändern und den Ordner neu scannen lassen, und alles wird wieder automatisch auf x266 umcodiert.

Tadarr benutzt dafür ffmpeg und/oder Handbreak.