Handbrake - Einstellungen für Youtube

[Plasquar]

Ich bearbeite meine YT Videos in Premiere Pro und exportiere mit dem Youtube 1440p h.264 Preset bei konstanter Bitrate von 130.000.
Um Zeit beim Hochladen zu sparen, jage ich die größeren Dateien nochmal durch Handbrake mit folgenden Einstellungen:

https://imgur.com/a/c71rc6T

Meine Frage: beim YT Preset setzt Handbrake automatisch den Decombfilter bei "Deinterlace". Brauche ich das?
Aber hauptsächlich: Wirkt sich die Geschwindigkeit wirklich so sehr auf Qualität / Größe aus? Ich nehme normalerweise "Fast".

[Rooter]

Wirkt sich die Geschwindigkeit wirklich so sehr auf Qualität / Größe aus? Ich nehme normalerweise "Fast".Weiß nicht genau was du jetzt hören willst. Klar wirkt es sich aus, ist halt die Frage ob dir das Endergebnis gefällt. Wenn bei schnellen Bewegungen nur noch Blöcke zu sehen sind und Kanten voller Ringing sind wäre das für mich :down:

EDIT: Ich nutzte Handbrake nicht aber kann man da nicht auch die Bewegungserkennung und Qpel einstellen (Parameter me und subme)? :confused:

MfG
Rooter

[aufkrawall]

Meine Frage: beim YT Preset setzt Handbrake automatisch den Decombfilter bei "Deinterlace". Brauche ich das?

Nein, computergenerierter Inhalt ist ja nie interlaced.


Aber hauptsächlich: Wirkt sich die Geschwindigkeit wirklich so sehr auf Qualität / Größe aus? Ich nehme normalerweise "Fast".
Fast dürfte imho der Sweetspot bez. Qualität/Geschwindigkeit sein.

[Plasquar]

Bin mit den extra Encoderoptionen nicht so vertraut, aber das kann man vielleicht bei den "Extra Options" auf dem 4. Screen eintragen?

Ich frage wegen der Geschwindigkeit deshalb, weil ich nach stundenlangem Googlen und Tutorial schauen oft gesehen habe, dass Leute sagen, dass alles unter "fast" im Endeffekt wenig Unterschied macht.
Wenn ich testweise eine Aufnahme kodier mit "veryfast" und einmal mit "slow" erkenne ich am Schluss kaum einen Unterschied.

Nein, computergenerierter Inhalt ist ja nie interlaced.

Fast dürfte imho der Sweetspot bez. Qualität/Geschwindigkeit sein.

Danke. Die meisten Leute raten auch zu "Fast".
Ich kenne mich mit den extra Encoder Optionen nicht gut aus, gibt es dort noch welche, die man für bessere Qualität (bei bewegungsintensiven Videos) hinzufügen kann?
Oder speziell für YT 1440p/60FPS?

[Rooter]

Wenn ich testweise eine Aufnahme kodier mit "veryfast" und einmal mit "slow" erkenne ich am Schluss kaum einen Unterschied.Dann speichere dir mal ein Standbild ab und aus dem anderen Video das selbe Bild und springe zwischen diesen beiden hin und her. Dann wirst du den Unterschied auch sehen. ;)

MfG
Rooter

[qiller]

Ich frage wegen der Geschwindigkeit deshalb, weil ich nach stundenlangem Googlen und Tutorial schauen oft gesehen habe, dass Leute sagen, dass alles unter "fast" im Endeffekt wenig Unterschied macht.
Wenn ich testweise eine Aufnahme kodier mit "veryfast" und einmal mit "slow" erkenne ich am Schluss kaum einen Unterschied.


Du jast auch CRF-Modus (konstante Qualität) bei x264 an (steht bei dir auf 19). Damit bleibt die Qualität des Videos immer (halbwegs) gleich. Die Codec-Geschwindigkeit (fast, veryfast, medium, slow etc.) bestimmt dann am Ende nur die Dateigröße (mit veryfast/crf19 sollte die Datei am Ende größer sein als mit slow/crf19).

Wenn du z.B. zu den Streamern schaust, die benutzen alle eine konstante Bitrate (damit das TCP-Windows nicht ständig angepasst werden muss). Hier macht es durchaus einen Qualitäts-Unterschied, ob du veryfast oder medium nimmst. Natürlich benötigt dann das Echtzeit-Encoding auf medium mehr Rechenleistung als auf veryfast.

[Rooter]

Die Codec-Geschwindigkeit (fast, veryfast, medium, slow etc.) bestimmt dann am Ende nur die Dateigröße (mit veryfast/crf19 sollte die Datei am Ende größer sein als mit slow/crf19).Nein, das bestimmt wie gründlich der Encoder ist, vor allem bei der von mir oben erwähnten Bewegungssuche. Auf die Dateigröße hat das auch einen Einfluss, aber gar keinen so großen. Die wird hauptsächlich vom CRF-Wert beeinflusst.

(damit das TCP-Windows nicht ständig angepasst werden muss)Watt? Ich denke nicht, dass es mit der TCP-Paketgröße etwas zu tun hat.

MfG
Rooter

[lumines]

Wenn du z.B. zu den Streamern schaust, die benutzen alle eine konstante Bitrate (damit das TCP-Windows nicht ständig angepasst werden muss).

Hat wahrscheinlich eher damit zu tun, dass die meisten Heimanschlüsse bandbreitentechnisch eher begrenzt sind und man sich mit einer konstanten Bitrate besser für eine Qualitätsstufe und Auflösung entscheiden kann. Bei schwankender Bitrate würde im schlimmsten Fall der Stream andauernd zwischen den Qualitätsstufen wechseln oder sporadisch die Leitung überlasten.

Ich würde CRF mit 20 fahren und dann fast oder medium als Preset.

[qiller]

Nein, das bestimmt wie gründlich der Encoder ist, vor allem bei der von mir oben erwähnten Bewegungssuche. Auf die Dateigröße hat das auch einen Einfluss, aber gar keinen so großen. Die wird hauptsächlich vom CRF-Wert beeinflusst.

Wenn du mir nicht glaubst, probier es doch einfach aus. Ich mein, dass der Unterschied zwischen medium und slow eher gering ist, ist jetzt nicht verwunderlich (nicht umsonst wird der Medium-Preset häufig als Brot-und-Butter-Setting für normale Encodings empfohlen und alles ab slow eher in Richtung Placebo geht). Aber nehm z.B. veryfast/crf19 und medium/crf19, du wirst sehen, die Dateien sind bei veryfast größer :>. Das liegt am CRF-Verfahren, das einfach dafür sorgt, dass du immer dieselbe Qualität behältst. Und wenn du immer crf 19 benutzt, sieht natürlich auch das Video am Ende immer gleich aus. Das ist genau das, was der TE festgestellt hat. Das CRF-Verfahren jongliert im Grunde mit der Video-Bitrate und der zur Verfügung gestellten Rechenleistung (=veryfast, fast, etc.). Stellst du wenig Rechenleistung zur Verfügung, brauchst du für dieselbe Qualität eine höhere Bitrate (=größere Datei). Eigentlich ganz einfach.


Watt? Ich denke nicht, dass es mit der TCP-Paketgröße etwas zu tun hat.


Hat wahrscheinlich eher damit zu tun, dass die meisten Heimanschlüsse bandbreitentechnisch eher begrenzt sind und man sich mit einer konstanten Bitrate besser für eine Qualitätsstufe und Auflösung entscheiden kann. Bei schwankender Bitrate würde im schlimmsten Fall der Stream andauernd zwischen den Qualitätsstufen wechseln oder sporadisch die Leitung überlasten.

Der CRF- oder VBR-Modus des x264 führt beim Streamen zu einem ständig schwankenden TCP-Receive-Window, da die Bitrate ja nicht konstant ist und ebenfalls ständig schwankt. Selbst wenn man den Best- und Worst-Case ausloten und an seine Upload-Geschwindigkeit anpassen könnte, wird von VBR-/CRF-Verfahren beim Videostreaming abgeraten. Ein Twitch-Entwickler hatte das mal sehr gut erläutert, eben mit dem Verweis, dass ein schwankendes TCP-Receive-Window nicht gut für die Stabilität des Videostreams ist, vor allem bei Zuschauern mit mobilen Geräten hinter WLAN- und Mobil-Netzwerken. Ich finde den Blog-Artikel nur leider nicht mehr. Soweit ich mich erinnere, ist die Verzögerung für das Einstellen des TCP-Windows das Problem. Das TCP-Windows wird ja nicht schlagartig direkt nach dem letzten ACK-Paket auf genau den passenden Wert erhöht, sondern das erhöht/verringert sich eher gemächlich. Und dieses Verhalten von TCP verträgt sich nicht so gut mit den schnell schwankenden Bitraten eines CRF- oder VBR-Modus.

Dass beim Verwenden einer konstanten Bitrate die Streaming-Parameter viel leichter einzustellen sind, ist natürlich ein weiterer nicht unwichtiger Punkt.

Edit: Hab nur ein Forum-Post eines Twitch-Mitarbeiters gefunden.
https://obsproject.com/forum/threads/stabilizing-stream-cbr-questions.1857/#post-11342

[Rooter]

Wenn du mir nicht glaubst, probier es doch einfach aus. Ich mein, dass der Unterschied zwischen medium und slow eher gering ist, ist jetzt nicht verwunderlich (nicht umsonst wird der Medium-Preset häufig als Brot-und-Butter-Setting für normale Encodings empfohlen und alles ab slow eher in Richtung Placebo geht). Aber nehm z.B. veryfast/crf19 und medium/crf19, du wirst sehen, die Dateien sind bei veryfast größer :>. Das liegt am CRF-Verfahren, das einfach dafür sorgt, dass du immer dieselbe Qualität behältst.Habe mal kurz mit AviDemux und dessen x264 rumprobiert und kam bei einem 2-minütigen HQ-Testvideo auf Folgendes:

Profil Fast
Bedeutet CRF=14, me=hex und subme=6
Dauerte 3:30 min
Dateigröße 433 MB

Profil Very Fast
Bedeutet CRF=12, me=hex und subme=2
Dauerte 1:25 min
Dateigröße 528 MB

Profil Very Fast mit CRF=14
Bedeutet CRF=12 geändert auf CRF=14, me=hex und subme=2
Dauerte 1:24 min
Dateigröße 397 MB

D.h., wie du ja schon erkannt hast, wird bei Very Fast die viel schlechtere Bewegungserkennung subme=2 mit einem besseren Qr (12 statt 14) ausgeglichen. Das Encoding dauert weniger als halb so lang, dafür ist die Datei 1/4 größer (und vermutlich häßlicher; das wäre es mir nicht Wert!).
Wie mein drittes Beispiel mit dem Very Fast-Profil und CRF auf dem Niveau von Fast zeigt, ist im wesentlichen der CRF-Wert für die Dateigröße verantwortlich! (EDIT: Aber sicher auch für die Häßlichste!)

Ich habe mir die Videos noch nicht mal angesehen, vermute aber, dass mir die erste Version am besten gefallen wird. :D

Und wenn du immer crf 19 benutzt, sieht natürlich auch das Video am Ende immer gleich aus.Nein, weil die anderen Parameter, allen voran die Bewegungserkennung, auch einen großen Einfluss haben.

Der CRF- oder VBR-Modus des x264 führt beim Streamen zu einem ständig schwankenden TCP-Receive-Window, da die Bitrate ja nicht konstant ist und ebenfalls ständig schwankt. Selbst wenn man den Best- und Worst-Case ausloten und an seine Upload-Geschwindigkeit anpassen könnte, wird von VBR-/CRF-Verfahren beim Videostreaming abgeraten. Ein Twitch-Entwickler hatte das mal sehr gut erläutert, eben mit dem Verweis, dass ein schwankendes TCP-Receive-Window nicht gut für die Stabilität des Videostreams ist, vor allem bei Zuschauern mit mobilen Geräten hinter WLAN- und Mobil-Netzwerken. Ich finde den Blog-Artikel nur leider nicht mehr. Soweit ich mich erinnere, ist die Verzögerung für das Einstellen des TCP-Windows das Problem. Das TCP-Windows wird ja nicht schlagartig direkt nach dem letzten ACK-Paket auf genau den passenden Wert erhöht, sondern das erhöht/verringert sich eher gemächlich. Und dieses Verhalten von TCP verträgt sich nicht so gut mit den schnell schwankenden Bitraten eines CRF- oder VBR-Modus.

Dass beim Verwenden einer konstanten Bitrate die Streaming-Parameter viel leichter einzustellen sind, ist natürlich ein weiterer nicht unwichtiger Punkt.Ich verstehe ja was du meinst aber CBR ist doch völlig ineffizient, da es die Gegebenheiten des Bildes einfach ignoriert. Das letzte Mal, als ich mit CBR zu tun hatte, war zu den Zeiten der Video-CD und MPEG1... X-D

Edit: Hab nur ein Forum-Post eines Twitch-Mitarbeiters gefunden.
https://obsproject.com/forum/threads/stabilizing-stream-cbr-questions.1857/#post-11342Der Post ist aber jetzt auch schon ein halbes Jahrzehnt alt... :|

MfG
Rooter

[qiller]

Mein Test:

crf20/superfast: 100MB bzw. 25,8Mbit/s, 0:38min
crf20/medium: 61,8MB bzw. 15,9Mbit/s, 2:08min

Also ich seh da keinen großen Unterschied in den Videos, auch in den Bewegtszenen nicht. Denke dass ist das, was der TE meinte. Und warum du immer wieder den crf hier vergleichen willst, versteh ich nicht, darum ging es dem TE doch gar nicht. Dass ein anderer crf-Wert zu viel größeren Bitratenänderungen führt, ist doch klar. Der TE fragte sich doch, warum er zwischen veryfast und slow keinen Unterschied sieht und das liegt am crf-Modus. Die schlechtere Bewegungserkennung wird eben mit höherer Bitrate wieder ausgeglichen. 100% perfekt stimmt die Qualität sicherlich nicht überein. Aber wenn ich nen Blindtest machen müsste, würde ich so erstmal nicht erkennen, welches Video in welchen Settings kodiert wurde.

Zum CBR: Du weißt schon, dass ich vom Video-Streaming gesprochen hab, oder? Also für meine Videosammlung benutze ich jedenfalls ganz sicher nicht den CBR-Modus :>.

Und was hat denn das Alter des Posts damit zu tun, der TCP-Standard ist sogar noch viel älter...

[Rooter]

Dann vergleich mal einzelne Bilder aus beiden Videos oder glaubst du ernsthaft, dass eine Datei von 61MB genauso gut aussieht wie eine Datei von 100MB!? :freak:

Mag ja sein, dass es je nach Material bei schneller Bewegung kaum auffällt.

@ Streaming: Nutzt YouTube denn auch CBR bei ihren Videos?

MfG
Rooter

[qiller]

Dann vergleich mal einzelne Bilder aus beiden Videos oder glaubst du ernsthaft, dass eine Datei von 61MB genauso gut aussieht wie eine Datei von 100MB!? :freak:


Äh, ja, in der 61MB Datei steckt ja auch viel mehr Rechenleistung um diese Kompression zu erreichen. Diese Korrelation funktioniert bis zu medium-Preset auch wunderbar, weshalb das ja auch der Sweetspot ist. Die Presets von slow und höher sind dann nur noch Spielerei/Energieverschwendung. Der Kompressionsgewinn ist auch nur noch minimal.

Was Youtube macht, ka, aber bei Youtube darf man nicht vergessen, dass dort die Videos erst hochgeladen (die Dauer des Hochladens ist schonmal egal, da kein Echtzeit), dann nochmal (mehrfach) umgewandelt werden (für die verschiedenen Auflösungsstufen) und dann irgendwann von den Usern abgerufen werden. Nirgends ist hier Echtzeit erforderlich. Selbst Zuschauer, die zu wenig Downloadrate haben, können z.B. höheraufgelöste Videos anschauen, wenn sie vorpuffern (und Youtube es zulässt :x). Beim Streaming z.B. per Twitch wird der Stream ja in Echtzeit hochgeladen und direkt an die Zuschauer weitergeleitet (Qualität: Quelle). Wenn man Twitchpartner ist oder eine gewisse Zuschauerzahl erreicht wird (damals waren es 100, ka ob das noch gilt), schaltet sich auch bei Twitch ein mehrstufiger Encoder zwischen, der dann niedrigere Auflösungen/Bitraten zur Verfügung stellt, z.B. für Zuschauer, die nur mitm Smartphone oder im Fenstermodus zuschauen. D.h. der Upload geschieht in Echtzeit, und der Abruf verzögert, aber ebenfalls zeitkritisch. Mit anderen Worten, die Anforderungen beim Streaming sind ganz andere, als ein einfacher, nicht zeitkritischer Videoabruf.

[Rooter]

Äh, ja, in der 61MB Datei steckt ja auch viel mehr Rechenleistung um diese Kompression zu erreichen.Aha. :freak: Und durch welche Parameter genau wird das erreicht, wenn der CRF-Wert doch bei beiden 20 ist? :|

MfG
Rooter

[qiller]

Na durch die ganzen x264-Analysewerte, die mit den Presets festgelegt werden und die du ja schon teilweise aufgezählt hattest: ref, analyse, me, subme, mixed_ref, mb_tree etc. Im Prinzip kann man sich auch die ganzen Presets schenken und alle Analyswerte manuell festlegen, wenn man Lust hat. Die Presets sind doch nur von den Entwicklern wohldurchdachte Zusammenfassungen dieser unzähligen Einstellmöglichkeiten.

[Rooter]

Wie erklärst du, dass bei mir trotz zahmerer Bewegungssuche bei gleichem CRF nur 10% Größenunterschied rauskamen?

MfG
Rooter

[qiller]

Kommt doch auch aufs Video an. Bei ner Szene wo es wenige/langsamere Änderungen oder viele gleichförmige Flächen gibt wird der Unterschied eher geringer ausfallen. Wenn du einen größeren Effekt sehen willst, nehm einfach mal son Rausch-Video (vlt bist du Game of Thrones-Fan, dann kennst du ja vlt das HBO-Rauschbild am Anfang, sowas in der Art :>).

Btw:
crf20/veryslow: 54,7MB bzw. 13,9Mbit/s, 11:43min
Bei veryslow benutzt x264 z.B. 16 Referenzbilder. Da gibts dann auch höhere Anforderungen an die Player. So ein Video kann man dann nicht mehr überall abspielen.

[Rooter]

Wenn du einen größeren Effekt sehen willst, nehm einfach mal son Rausch-VideoKlar, bei schwachen Einstellungen wird das Rauschen ja auch komplett zu einfarbigem Matsch verarbeitet. Erst bei besseren Einstellungen wird das Rauschen als feine Details erkannt und verarbeitet.

MfG
Rooter

[Fusion_Power]

Ich nutze HandBrake unter anderem, um Filme für den DVD Player meiner Eltern zu konvertieren, der hat nen USB Anschluss und frisst auch normale PC Mediendateien. Leider scheint der nicht mehr als MPEG 2 SD zu schaffen sonst ruckelts, Bitrate zudem kaum über 1300, komische Kiste, war halt billig das Ding. Hab vllt. noch nicht die richtigen Einstellungen in HandBrake gefunden aber so scheiße kann ein halbwegs moderner Medienplayer doch auch wiedeer nicht sein, dass der schon mit MPEG4 überfordert ist. h.264 wird gleich gar nicht supportet. Naja, immerhin arbeitet HandBrake mit allen Kernen die da sind beim konvertieren. Dauert mit 2-pass encoding trotzdem schon mal länger bei nem HD Film den runter zu rechnen. Und wehe man macht irgend welche Deblock oder Denoise Filter rein, dann gehen die FPS beim umwandeln von locker 400 auf vllt. 40 runter, dass das so viel Leistung kosten kann, faszinierend.
Trotzdem gutes Tool.

[qiller]

Klar, bei schwachen Einstellungen wird das Rauschen ja auch komplett zu einfarbigem Matsch verarbeitet. Erst bei besseren Einstellungen wird das Rauschen als feine Details erkannt und verarbeitet.

MfG
Rooter

Schon klar, aber darauf wollte ich mit dem Beispiel nicht hinaus. Du wolltest eine Antwort, warum bei dir nur ein 10%iger Unterschied sichtbar ist und wollte dir mit dem Hinweis auf ein Rauschbild nur ein Worst-Case-Beispiel aufzeigen und damit erklären, dass das Quell-Video selber auch ein Wort mitzureden hat.

[Plasquar]

Sehr interessante Diskussion.


Profil Fast
Bedeutet CRF=14, me=hex und subme=6
Dauerte 3:30 min
Dateigröße 433 MB


Kann man me=hex und subme zu den Handbrake Options hinzufügen?

Und warum benutzt ihr kein CBR? Videos, die nach dem Exportieren aus Premiere nicht besonders groß sind und nicht mehr über Handbrake müssen, lade ich direkt hoch (und die habe ich mit CBR=130 Mbit/s exportiert).
Halte mich auch hier an Tutorials, die sagen, dass man (wenn man die Leitung hat) einfach CBR mit einem extrem hohen Wert (130Mbit/s z.B.) nehmen kann und die Quali ist damit sehr gut.
VBR könne keine bessere, sondern nur gleichbleibende Quali erzeugen, dafür halt viel geringere Dateigrößen, da bewegungsarmen Szenen weniger Bitrate zugewiesen wird.

[Rooter]

Sehr interessante Diskussion.



Kann man me=hex und subme zu den Handbrake Options hinzufügen?Vermutlich in das Textfeld "Extra Options".

Siehe auch:
https://encodingwissen.de/codecs/x264/referenz/#me-modus-star
https://encodingwissen.de/codecs/x264/referenz/#subme-qualitat-star

Und warum benutzt ihr kein CBR?Die Antwort darauf gibst du doch selbst:
VBR könne keine bessere, sondern nur gleichbleibende Quali erzeugen, dafür halt viel geringere Dateigrößen, da bewegungsarmen Szenen weniger Bitrate zugewiesen wird.


MfG
Rooter

[Plasquar]

Stimmt die Aussage:


VBR könne keine bessere, sondern nur gleichbleibende Quali erzeugen, dafür halt viel geringere Dateigrößen, da bewegungsarmen Szenen weniger Bitrate zugewiesen wird.

?

Und ich schmeiß die Optionen einfach mal ins Extrafeld und gucke mal, was passiert.

[lumines]

Manche Parameter sind von anderen abhängig und werden erst dann aktiv, wenn die auch aktiv sind. Guck dir einmal online an, welche Parameter von den verschiedenen Presets gesetzt werden. Hex ist z.B. bei einigen Presets sowieso drin: https://encodingwissen.de/codecs/x264/referenz/

[Rooter]

Stimmt die Aussage:



?Ja

Und ich schmeiß die Optionen einfach mal ins Extrafeld und gucke mal, was passiert.Nimm
:me=umh:subme=7
Ist imo der Sweetspot für Qualität.

MfG
Rooter

[Plasquar]

[...]https://encodingwissen.de/codecs/x264/referenz/

Danke. Die Presets sind jetzt nicht Handbrake spezifisch. Oder gelten diese Presets global für alle Programme?



Nimm
:me=umh:subme=7
Ist imo der Sweetspot für Qualität.

MfG
Rooter

Danke, ich lass mal ein paar Tests laufen und vergleiche mal die Quali.

[Rooter]

Danke. Die Presets sind jetzt nicht Handbrake spezifisch. Oder gelten diese Presets global für alle Programme?Die gelten für x264, was Handbrake für H.264-Encoding intern verwendet, wie viele andere auch.

Danke, ich lass mal ein paar Tests laufen und vergleiche mal die Quali.und die Dateigröße. Wobei die ja für den Upload auf YT zweitrangig ist.

Am besten Standbilder vergleichen, dasselbe Bild aus beiden Videos.

MfG
Rooter

[Plasquar]

Mache ich.
Die Größe ist mir persönlich nicht so wichtig. Ob ich jetzt 15GB oder 17GB hochlade, ist mir egal. Der Laptop drückt das über Nacht schon hoch. :freak:

Aber ich schau mal rein.

[Plasquar]

Bei den Test fällt mir noch was ein:

Eigentlich macht CBR 130Mbit/s wenig Sinn, oder?
Sinniger wäre VBR mit einer Zielrate von 130Mbit/s und einer maximalen von 300Mbit/s, damit sich der Encoder mehr Birate ranholen kann wenn er sie braucht?
(Erstelle 1440p Videos mit 60FPS und mit viel Bewegung)

[Rooter]

Bei den Test fällt mir noch was ein:

Eigentlich macht CBR 130Mbit/s wenig Sinn, oder?
Sinniger wäre VBR mit einer Zielrate von 130Mbit/s und einer maximalen von 300Mbit/s, damit sich der Encoder mehr Birate ranholen kann wenn er sie braucht?Richtig

MfG
Rooter

[Breegalad]

Nach meinem Kenntnisstand verändern die presets (*) nicht die Qualität, nur die Dateigröße.
Aber die nachträgliche Umkodierung mit Handbrake ist sowieso unnötig, da Adobe Media Encoder anstandslos (und sehr schnell) in die gewünschte Ziel-Bitrate kodiert.
(Problematisch war bis zum kürzlichen Update der Export in 8K / h.264. Dazu habe ich erst in DNxHR verlustfrei exportiert und danach mit dem Tausendsassa Hybrid (http://www.selur.de/)zu x.264 rekodiert & komprimiert)

edit
(*) Wir denken uns ein an dieser Stelle eingefügtes "im Wesentlichen".

[Rooter]

Nach meinem Kenntnisstand verändern die presets nicht die Qualität, nur die Dateigröße.Die Presets verändern ein Dutzend wenn nicht mehr Parameter auf einmal, daher ist so eine Aussage, wie du sie hier triffst, ist gar nicht möglich.

Außerdem: Wie kann es bei dem selben Quellmaterial und dem selben Encoder verschiedene Dateigrößen geben, ohne, dass das auf Kosten der Qualität geht? :uconf2:

MfG
Rooter

[aufkrawall]

Letztere Frage ist doch ganz einfach zu beantworten:
Es geht nicht nur um die Menge (Bitrate) der Informationen, sondern auch um deren Qualität.

[qiller]

@Plasquar: Schau dir mal Voukoder (https://github.com/Vouk/voukoder) an. Dieses doppelte Encodieren ist immer schlecht für die Quali. Der Voukoder ist im Prinzip nen Plugin, der die verschiedenen OpenSource-Codecs (z.B. x264, x265) für Adobe Premiere zur Verfügung stellt. Ich weiß jetzt nur grad nicht, ob man auch wirklich alle Optionen auswählen kann. Aber Ausprobieren schadet ja nicht.

Ansonsten kann ich dir versichern, dass von deinen 130Mbit/s bei Youtube nicht mehr viel übrig bleibt. Im Grunde ist die Diskussion fast überflüssig, wenn die Videos am Ende bei Youtube landen und die Quali dort eh gedrückt wird.

[Plasquar]

Klar, YT regelt 1440p Vids runter auf... hmm... ca. 20-30 Mbit/s (https://support.google.com/youtube/answer/1722171?hl=de).

Aber desto besser die Quelldatei, desto besser der Output?
Wenn die Datei nur ein kleines bisschen besser aussieht, dafür aber 5 Stunden länger zum Hochladen braucht, soll mir das recht sein.


@Plasquar: Schau dir mal Voukoder (https://github.com/Vouk/voukoder) an.

Mach ich!