Beiträge von De-M-oN

Dann guckt man nach in welcher Auflösung Fraps aufnimmt

Spätestens hiermit weißt du's

http://mediainfo.sourceforge.net/de

Zitat

1.) der Videoheader wird verändert, eindeutig nachzuprüfen und sehbar im Mediaplayer classic. Was ist an dieser Aussage nicht zu verstehen ? bei mir ist es nun mal genau so und du kannst es selbst nachprüfen, denn du hast ja ebenfalls den Player !

Aha.
Ich habs leider falsch rausgelesen aus deinem Text, da:

Zitat

diese 30 sekunden (meist sogar viel weniger), das Video durch MKV Merge Gui zu jagen und die Kopfdaten zu entfernen

Aber vorher schriebst du ja:

Zitat

Die Kopfdatenkompression in mp4-Dateien enthält zusätzliche Informationen über das Video, nur können Viele Wiedergabeprogramme, und auch Youtube, nichts mit diesen Daten anfangen oder setzen sie falsch um (was bei Youtube eben den Grauen Bild Bug auslösen kann)
aber mit MKV-merge ist es kein Problem diese überflüssigen Kopfdaten zu entfernen und nur das wichtige zu behalten, dann haben die meisten Programme (und Youtube), keine probleme mehr, diese Videos richtig wiederzugeben (oder zu verarbeiten)

Allerdings muss ich hier dennoch sagen, das es nicht an dem Inhalt der Daten liegt, sondern sehr wohl an der verwendeten Kompression auf dem Header.

Und ja er wird sehr wohl komprimiert.

LP-DooM3-RoE-Level8_3.mkv --> 2.031.585.242 bytes (ohne Kompression)
LP-DooM3-RoE-Level8_3 (1).mkv --> 2.031.536.557 bytes (mit Kompression)

EIne Differenz von 48685 bytes. Sogar noch weit weniger als 1 MB wie ich erst dachte mal gesehen zu haben. Aber wie auch immer. Die unkomprimierte ist natürlich größer und nicht andersrum. Ich habe beide Dateien mit MKVMergeGUI gemuxt. So das exakt der gleiche Header geschrieben wird. Ergo scheint dir Handbrake also ja doch den Header mehr zu befüllen mit Daten. Oder wie erklärst du dir das jetzt?

Zu den Tunings: Ok liegt wohl an den psy-rd etc Einstellungen. Na gut dann an der Stelle sorry, haste dann wohl hierbei Recht.

Zitat

außerdem ist fastdecode und zerolatency kein Tuningprofil, sondern nur CPU Entlastungen, diese werden nur für Echtzeitaufnahmen VFW-interface und bei Streaming gebraucht.

Ja die werden aber trotzdem mit dem Parameter --tune behandelt - x264 behandelt sie also auch als "tune" profil.

Zitat

hast du schon mal Original mp4 mit der MKV Verglichen?

Ja klar. Sonst wüsst ich ja nicht mal wie meine Youtube Videos aussehen.
Bei wenig bis normal komplexem Material 99 - 100% artefaktfrei. Bei etwas mehr Komplexität sieht man aber leider leichte Kästchenbildung - dennoch ist sie extrem minimal und für einen Videohoster eine astreine Qualität. Natürlich kein Vergleich zur MKV aufm PC.

Zitat

oder hast du die Tuningsettings schon mal ausprobiert ?

Nein. Aber ich vergas die Settings für psy-rd etc. Insofern haste ja hier Recht.

Aber eins finde ich an deinem Text etwas arg interessant:

Zitat

Und noch was, wenn ich eine Originale Frapsaufnahme, verlustfrei rendere (egal welcher Codec), und dann mit x264 rendere, sieht das Video schlechter aus (ich behaupte nicht, das es auf meinem PC schlechter aussieht, sondern das Ergebnis sieht schlechter aus auf Youtube)
wenn ich dagegen das gleiche Fraps-Video mit meinem 99% WMV Profil rendere und dann mit x264 rendere sieht es nahezu perfekt aus (ebenfalls auf Youtube), außerdem wird das Video sogar noch kleiner (vermutlich weil es nicht mehr ganz so hoch detailliert ist)
da scheiß ich doch auf die kleinen Ungenauigkeiten, und die minimal verlorenen Details, wenn es dann auf Youtube viel besser und Detaillierter aussieht (ja richtig, es sind mehr Details da, als mit dem verlustfrei gerenderten Video), mal davon abgesehen das die Datei auch kleiner ist.
natürlich begreifst du das nicht, oder willst es nicht begreifen, das sind Praxistests und Ergebnisse und nicht irgendwelche Papiertests, diese Ergebnisse sind auf Youtube zu sehen, wenn man sich nur die mühe macht es auszuprobieren.
Also kann ein verlustbehaftetes Video trotzdem besser aussehen als ein verlustfreies Video, natürlich nur solange es um Videos auf Youtube geht, [...]

Das hast du mir noch nie so gesagt.

Das werd ich in jedem Fall mal ausprobieren, aber wenn das stimmen sollte, wo ist denn da noch die Logik?

Das muss doch auch irgendwie anders besser gehen -.-

Zu dem Rest:

Es gibt TMPGEnc 5 als Videobearbeitungsprogramm. Dieses besitzt x264 und hat gute Timeline und den ganzen Kram drin. TMPGEnc 5 ist ein schönes Programm. Man kann mit dem sogar Avisynth Scripte als Videoquelle öffnen
Aber MeGUI ist halt unschlagbar in Aktuellhaltung der Encoder & Tools, sowie hat es viele Audio Encoder. (wie z.b. auch FLAC etc). Bei TMPGEnc 5 gibts zwar auch schon ganz gut welche, aber ich vermisse OGG Vorbis und FLAC. AAC etc ist aber enthalten.

So ist das nunmal mit Programmcode.

Wenn du ein Programm programmierst, ist das kein Stück anders

Aber gibt doch TMPGEnc 5, welches x264 ebenfalls drin hat und ein Videobearbeitungsprogramm mit Timeline und dem ganzen Kram ausgestattet ist.

Avisynth Profile sind auch im MeGUI speicherbar. Also das ist dann schon durchaus auch hier möglich.

Zitat von maestrocool

ja man kann mit MeGui auch Pixelgenau setzen, aber Premiere hat den Vorteil, das man es sofort sehen kann ob es richtig sitzt oder nicht, und wie ist es bei bei MeGui ?

Ja siehst du da auch sofort -.-

Video Preview Fenster existiert nicht aus Langeweile^^

Zitat von maestrocool

du kannst dieses Wasserzeichen viel präziser und genauer mit Premiere einbauen, wieso wolltest du das mit meGui machen ?

präziser? Bei MeGUI kannst du es völlig genauso pixelgenau einstellen.

Das ist jetzt irgendwie kein Argument^^. Und Videopreview haste da genauso.

Zitat

ohne irgendein Video mit drin zu haben.

wie meinst du das? Das Wasserzeichen wird bei MeGUI auch als Bild aufs Video gelegt und nicht als Video^^. Oder was meinst du?

Aber ansonsten ja, kannste auch mit Premiere machen.

Zitat

Das du immer alles verkomplizieren musst Demon....

In wie fern?

Zitat

wieso sind dann alle Videodateien kleiner, wenn ich mit MKV Merge die Kopfdatenkompression weg gemacht habe ?

Sind sie nicht.

Mögliche Ursachen dafür:

-> Handbrake schreibt einen längeren Header (mehr Daten in den Header), so das es selbst mit Kompression größer ausfällt, als die Datenmenge die du mit MKVMergeGUI in den Header schreibst.
-> Containerwechsel. Beispielsweise MP4 -> MKV.

Aber ganz sicher nicht wird hier der Header zerstört. Das ist absoluter Unfug.
Bevor du einen solchen Schwachsinn in die Welt setzt, informier dich erstmal bitte. Es kann echt nicht sein, das du einfach irgendwas behauptest, weil du glaubst das es so sei.

Das machst du leider relativ häufig.
Das ging auch schon mit x264s Tunings los (Film, Animation, Grain etc).

Du behauptest dieses würde das Videobild als solches (wie ein Filter oder so) verändern.
Das stimmt halt auch nicht. Das ändert lediglich paar x264 Einstellungen die zu dem ausgewählten Tuning gut passen.

Zitat

Encoding-Vorlagen

Das mit den Revisionen 1177 und 1197 eingeführte Vorlagensystem fasst jeweils eine Reihe von Optionen abgestimmt für eine bestimmten Zweck in einer Vorlage zusammen. Es unterteilt sich in Kompressionsvorlagen (--preset), Tuningvorlagen (--tune) und H.264-Profilvorlagen (--profile). Vorlagen sind lediglich eine Kurzform für eine bestimmte Kombination aus Kommandozeilenoptionen. Alles, was wir über das Vorlagensystem einstellen können, lässt sich auch manuell einzeln konfigurieren.

Die drei Vorlagenkomponenten, manuell angegebene Optionen und die internen x264-Standardwerte überschreiben sich gegenseitig in folgender Reihenfolge:

Interne Standardwerte von x264.
Kompressionsvorlage (--preset).
Tuningvorlage (--tune).
Vom Benutzer in der Kommandozeile angegebene Optionen.
H.264-Profil (--profile).

In welcher Reihenfolge wir Optionen und Vorlagen in der Kommandozeile angeben, spielt keine Rolle.

Alles anzeigen

Zitat

--tune <Tuningvorlage> [wichtiger Parameter]
Werte: film, grain, animation, psnr, ssim, touhou, fastdecode, zerolatency
Standard: nicht gesetzt
Beispiel: --tune grain

Tuningvorlagen enthalten Optimierungen für entweder bestimmte Typen von Quellmaterial oder für spezielle Anforderungen bei der Wiedergabe. Wir können mehrere Vorlagen anwenden, indem wir sie durch ein Komma (,) getrennt hintereinander hängen. Es darf aber immer nur eine Psy-Vorlage aktiv sein.

film

Allgemeine Psy-Optimierung für Kinofilme.

--deblock -1:-1 --psy-rd 1.0:0.15

grain

Psy-Optimierung für körniges/verrauschtes Material, falls das Korn/Rauschen beibehalten werden soll. Führt zu vergleichsweise hohen Bitraten.

--deblock -2:-2 --ipratio 1.1 pbratio 1.1 --aq-strength 0.5 --qcomp 0.8 --psy-rd 1.0:0.25 --no-dct-decimate --deadzone-intra 6 --deadzone-inter 6

animation

Psy-Optimierung für klassischen Zeichentrick wie z.B. Tom & Jerry. 3D-Animationen, z.B. Monsters Inc., gehören nicht dazu und sollten wie normaler Realfilm behandelt werden.

--ref <verdoppeln, falls größer als 1> --deblock 1:1 --bframes <um 2 erhöhen> aq-strength 0.6 --psy-rd 0.4:0.0

psnr

Psy-Optimierung auf möglichst hohe PSNR-Werte. Ist für normale Encodings uninteressant.

--aq-mode 0 --no-psy

ssim

Psy-Optimierung auf möglichst hohe SSIM-Werte. Ist für normale Encodings uninteressant.

--aq-mode 2 --no-psy

touhou

Psy-Optimierung für Aufzeichnungen aus Touhou-Spielen. x264-Entwickler Dark Shikari nutzt solche Videos gerne zum Testen, da sie den Encoder extrem fordern.

--ref <verdoppeln, falls größer als 1> --deblock -1:-1 --aq-strength 1.3 --partitions <zusätzlich p4x4, wenn p8x8 aktiv> --psy-rd 1.0:0.2

fastdecode

Deaktivierung der für die Wiedergabe CPU-intensivsten Optionen.

--no-cabac --no-deblock --no-weightb --weightp 0

zerolatency

Deaktiviert alle Optionen, die die Encoding-Latenz erhöhen. Kann für manche Streaming-Anwendungen nützlich sein.

--bframes 0 --rc-lookahead 0 --sync-lookahead 0 --sliced-threads

Alles anzeigen

Ist halt bisschen doof, das du ziemlich oft einfach was sagst, weils dein Bauchgefühl so in den Sinn kommt. Ist mir schon sehr oft aufgefallen.

Zitat

und was die hohe Bitrate angeht bei XVid oder WMV, ja gut die Codecs haben ihre Probleme , na und?
wichtig ist doch nur, das die Videos keine extremen Artefakte mehr haben, damit x264 auch vernünftig klein schrumpfen kann

Dann kann man auch gleich bei dem Codec bleiben - oder eben bei x264 direkt den gewünschten höheren CRF wählen.

maestrocool: Was ich an dir nicht verstehe ist, das du immer oft Dinge behauptest die völliger Unfug sind??

Der Header wird NICHT entfernt. Das wäre absolut fatal, weil dann ist die Datei unbrauchbar.

Kopfdatenkompression bedeutet das der Header KOMPRIMIERT wird. Das spart ca. 1 - 2 MB ein (je nach Größe des Headers).

Da kann mans auch gleich unkomprimiert lassen und so hat man dann keine Gefahr auf Inkompatibilität (wie eben z.B. Youtube vor allem)

@Lumarion:

MKVMergeGUI zu bedienen ist kinderleicht. Außerdem absolut ungefährlich da eben die Spuren absolut unverändert bleiben. Ich persönlich würde nicht warten bis es irgendwann mal nicht klappt. Zumal der Zeitaufwand hierbei halt wirklich massiv gering ist.

---> MKVMergeGUI starten.
In Optionen (Datei - Optionen):

Haken setzen :

Dann auf Hinzufügen Button : Deine Datei auswählen.

Auf Muxen Starten Button -> Neue Datei hochladen.

So einfach ist das

@Tsuyoshi: Nunja verlustbehaftetes Material doppelt zu encoden ist sowieso sehr suboptimal^^ Der Lossy Encode sollte immer der letzte Schritt sein^^ Vorher mit Lossless Codecs arbeiten.

Zitat

oder wenn es ein anderer verlustbehafteter Codec sein soll (zB WMV oder XVID) , dann mit Bitraten bei ca 10.000 (bei 800x600), bzw mit 30.000 (bei HD Aufnahmen)

Dann kann mans auch gleich in xvid belassen. Absolut nicht zu empfehlen es so zu machen.
Und jetzt komm mir nicht das Auge würde bei xvid oder wmv bei solchen Bitraten ja nichts bemerken.

Das Ding hier : http://www.bilder-hochladen.net/files/big/93o6-bw.png

ist mit Quantiser 4 @ xvid.

also pendelt so zwischen 35 und 50 mbit Bitrate.

Die Straße ist grobkörnig und Bereich zwischen grünem Symbol und Tacho deutlich artefaktbefallen. -> Das Problem hat WMV genauso. Also sowas kann man doch nicht empfehlen. Zumal sowas H.264 niemals machen würde..

Die Frage kommt weil du das Video auf RGB 32 konvertieren musst, damit das Wasserzeichen eingefügt werden kann (nur so kann der Alphakanal angewendet werden)

MeGUI fragt daher eben nun nach ob er es wieder in YV12 wandeln soll wegen x264.
(Das könnte eig. mal geupdatet werden, da x264 ja mittlerweile auch RGB output unterstützt. -> Wobei spätestens auf Youtube wäre es aber eh dann in YV12. YV12 würd ich auch schon empfehlen. Habs noch nicht getestet mit x264. Aber RGB wird natürlich spürbar mehr Speicherplatz verschlingen.)

Diese Farbkonvertierungen lassen sich daher leider nicht vermeiden.

Edit: Was du vllt machen könntest im Premiere dein Lagarith auf RGBA zu stellen, statt YV12. (Dann dürfte es auch möglich sein, den .converttoRGB32 bei movie wegzulassen. Kannst ja probieren. Avisynth wirds dir dann ja sagen.) Der .converttoRGB32 beim Logo muss aber bleiben.

Ok. Ab dieser Stelle scheint Mr11bricks geglückte Versuch weiterhin bei Overlay zu bleiben ab hier nun zu versagen.

Mit meiner alten bewährten Methode CoronaSequence funktioniert es tadellos

Dies erfordert allerdings das du dir ImageSequence Plugin besorgst, welches CoronaSequence beinhaltet. (Denn sonst kennt Avisynth den Filter nicht)

Hier der Download:

http://killerinstinct.ath.cx:2000/ImageSequence.dll

Diese Datei kannste beispielsweise hier reinpacken: c:\Programme\megui\tools\avisynth_plugin

Hier dein neuer Code:

LoadPlugin("c:\Programme\megui\tools\avisynth_plugin\ImageSequence.dll")
movie = AVISource("F:\Premiere\Sequence 03.avi", audio=false).AssumeFPS(30.000).converttoRGB32
logo = CoronaSequence("F:\Premiere\drachen-Yin-Yangro23t.png").converttoRGB32
Layer(movie,logo,op="add",level=64,x=0,y=0)
Lanczos4Resize(1920,1072)

level ist hier, was bei Overlay die Opacity ist. Also eben die Deckkraft. Da du 0.25 eingesetzt hattest, wolltest du offensichtlich 25% Deckkraft. Level gibt es statt in 0.0 - 1.0, in 0 - 256 an. 25% von 256 sind 64. Daher hab ich hier 64 eingetragen. (wobei mir persönlich ja 25% zu blass vorkommt. Bissl kräftiger sollte es wohl sein^^. Ich denke es sieht am besten aus wenn du es auf 75% oder gar 100% hast.)

Updates sind doch nicht was schreckliches nur weil vorige Versionen funktionieren ....

Die Qualität bestimmt allein nur der CRF Faktor. Der Rest beeinflusst lediglich Dateigröße vs Encodierzeit.

Langsam ist wie der Name schon sagt: Langsam. Ich habe es nicht ohne Grund so benannt^^.

Normal wird deutlich schneller laufen und leicht schneller nochmal ein wenig schneller laufen.

Der Schritt von Normal auf Langsam ist eine erhebliche Intensivierung der Encodiereinstellungen. Zwischen Normal und Leicht schneller ist die Differenz geringer.

Wieviel kleiner die Datei mit Langsam im Vergleich zu Leicht schneller wird hängt natürlich auch stark von dem Videomaterial ab. Komplexes Material ist einfach auch schlechter komprimierbar. (CRF 21 wird mehr Bitrate benötigen bei komplexem Material und die Komprimierbarkeit im allgemeinen halt absinken - bei weniger komplexen Material wird die Differenz zwischen Langsam und leicht schneller höchstwahrscheinlich deutlich besser ausfallen, da bessere Komprimierbarkeit (b-frames,p-frames, ref-frames und vieles mehr können so ja vermehrt eingesetzt werden)

Ich würde es mal mit "Leicht schneller" ausprobieren

Skalieren kannst du das Wasserzeichen nicht (bzw wüsst ich keinen verfügbaren Befehl dafür). Müsstest du selber ändern. Bitte speichere aber immer in PNG, niemals JPG. Damit es auch verlustfrei bleibt !

Wegen der Farbe: Am Besten schickste mir mal das Wasserzeichen, dann werd ich selbst mal dran mich versuchen

movie = AVISource("x:\das-video.avi").AssumeFPS(30.000)
logo = ImageSource("x:\das-wasserzeichen.png",0,0)
Overlay(movie,logo,x=1382,y=905,opacity=1.0,mode="Luma")

Beachte das du oben das 1. AVISource entfernst, falls du den Code am Script unten ranhängst. (oder du setzt das movie = oben davor.) (bzw kannste den code eig. direkt übernehmen und die pfade anpassen - ist ja eh der vollständige Code.

x= position x des Wasserzeichens. 0 = links. y= Position y des Wasserzeichens. 0 = oben.

Angenommen du willst das Wasserzeichen nun unten rechts haben, dann musst du:

Videoauflösung (breite) - Breite des Wasserzeichens. Selbiges mit der Höhe. Beispielsweise hast du ein 1280x720 Video und ein 100x100 Wasserzeichen:

1280 - 100 = 1180 -> x
720 - 100 = 620 -> y

Auch hier kannst du natürlich jederzeit in der Videopreview schauen wie es erstellt werden würde.

Ja und mode gibt halt an welcher Modus verwendet werden soll.

Siehe hier: http://avisynth.org/mediawiki/Overlay

Dies geht nur bei Bildern die ohne Alphakanal (Transparenz) auskommen.

Wenn du ein Bild mit Alphakanal hast, muss es so aussehen:

movie = AVISource("x:\das-video.avi", audio=false).AssumeFPS(30.000)
logo = ImageSource("x:\das-wasserzeichen.png",0,0,pixel_type="RGB32").ShowAlpha(pixel_type="RGB32")
Overlay(movie,logo,mask=logo,x=1382,y=905,opacity=1.0,mode="Luma")

Mode kannste natürlich auch hier das nehmen, was dir am besten gefällt. Opacity ist die Deckkraft. 1.0 = 100%

Zitat von Mazzle

Hätte auch kein Problem das erst in Lagarith zu encodieren und dann mit MeGUI in H264 mit x264, solange ich keine verluste bei der Videoquali habe. Einfach weg vom MainConcept

Dann mach es so

Bei Lagarith in der Konfig noch einstellen (falls noch nicht ist) :

Mehrkern CPU vorhanden: -> Enable Multithreading anhaken !!
Enable Nullframes: -> Normalerweise anhaken - aber bei Premiere leider ein Problem. Premiere kommt damit wohl nicht zurecht wie ich von einigen gehört habe.
Sowieso scheint Premiere bei Lagarith ein wenig zu buggen. (Mit Wasserzeichen war 8std encodierzeit und son Quatsch - aber wirst ja sehen, wie es bei dir klappt )

Farbbereich auf YV12 stellen.

Du kannstes ja so machen, das du nur die Fraps Videos bearbeitest, die eine Bearbeitung benötigen. (und das wäre eig. nur nötig für Effekte / anderweitige Bearbeitung oder so, Schnippeln kannste ebenfalls mit MeGUI (AVS Cutter) ) Einfügen von Wasserzeichen etc würde auch mit MeGUI gehen.

Und danach dann encodieren und den Kram zusammenmuxen.

x264vfw kannste vergessen. a) hat H.264 nichts in AVI zu suchen, b) ist das vfw verdammt veraltet.

Du kannst den AVS Cutter nach Speichern des AVS Scriptes auch verwenden.

Die Vorgehensweise mit dem AVS Cutter ist wie folgt:

Die soeben gespeicherte AVS Datei öffnen.
Start und Endframe eintragen, auf Add drücken. ggf. noch mehr Cuts einfügen.
Dann auf Do All and close drücken.

Dann bei Audio unter Cuts die vom AVS Cutter erstellte .clt Datei öffnen (so das eben auch der Ton dabei mit berücksichtigt wird.)

Und ja das wird dann auch direkt so encodiert.

Du kannst das auch alles jederzeit mit dem Video Preview Fenster nachgucken. Falls du die Preview schon geschlossen hast, kann sie jederzeit mit Reopen Video Preview wieder geöffnet werden. Ist sie noch offen, reicht ein Druck auf Reload Video um die aktualisierte AVS geladen zu haben

PS: Wenn es dir beispielsweise nur um 15min Parts für Youtube geht und es nicht framegenau sein muss (sprich dir es nur ums reine splitten geht) dann kannste das aber auch einfacher mit MKVMergeGUI hinterher regeln.

Einfach zum Reiter Global und dann Aufteilen aktivieren anhaken und dann die Zeitspanne wann der Cut gemacht werden soll in dem Feld nach dieser Dauer eintragen. z.B.: 14:50

Zitat von Meduselchen

Is dies nun nicht nötig?

Richtig. Dies wird vom preset automatisch erledigt

Ach mist, ne ich weiß schon den Unterschied, habs nur leider nicht aufgefasst beim Lesen

Zitat von k4Zz

Ich hab das Thema mal angepinnt, aber postet bitte keine Links zu Shops, bei denen man beschlagnahmte Titel erwerben kann.

Warum das denn bitte nicht?

Okaysoft.de z.B. haben ihren ab 18 Bereich (wollen Ausweiskopie zugesandt)

Mehr muss okaysoft nicht tun. Sie dürfen die Spiele dann für 18+ jährige importieren. Das ist nichts verbotenes...

Nö das Video artefaktet auch.^^

Vergess auch nicht das Motion Blur des Spiels (Bewegungsunschärfe) das gut vertuschen kann^^ Weil das tötet ja die Schärfe = weniger Makroblocksichtbarkeit.

Du kannst den CRF Faktor ja weiter reduzieren. Auf z.B. 20 oder noch tiefer.

MeGUI

Desto größer aber wird auch deine Enddatei. Aber Youtubes encodierte Datei wird auch ein Tick größer ausfallen (da ja noch mehr Detail hochgeladen wurde, bleibt auf Youtube natürlich auch mehr über (Youtube arbeitet auch mit Qualitätsfaktor, und je besser das hochgeladene Material, desto mit mehr Detail werden die Quantiser auch gefüttert.)

In wie weit es aber deine Qualität verbessert musst du sehen.

Komplett artefaktfrei geht auch auf Youtube - Aber das Video muss dann weniger komplex sein. Vor allem ist Terrain ein schwieriges Ding, (sprich Büsche, Grashalme etc wo man durchgucken kann usw, das ist halt viel Feindetail und da muss auch x264 mehr Bitrate an den Stellen reinsetzen um dem z.B. CRF 21 Faktor treu bleiben zu können.

x264 wird dir immer wundervolle Videos produzieren mit dem Faktor 21 schon.

Aber Youtube ist nunmal andere Encodierung

@Gamecard:

Bitte DirectShowSource statt FFVideoSource verwenden.

Tools - AVS Script Creator
Video input -> Video Datei auswählen
DirectShowSource wählen.