Beiträge von De-M-oN

http://mpc-hc.sourceforge.net/…ia-player-classic-hc.html in 32bit und Haali Renderer http://haali.su/mkv/MatroskaSplitter.exe (beim Setup den Haken aus associate MKV and MP4 to WMP entfernen)

Im MPC-HC dann unter Optionen -> Ausgabe den Renderer auf Haali Renderer umstellen.

Ich wiederhol das nochmal, weil zum einen nicht erwähnt wurde das MPC Home Cinema (es gibt nämlich auch nen alten der nicht home cinema heißt), zum anderen wurde 32bit nicht erwähnt und Haali nicht erwähnt

UPDATE !!!

Einlesen von mehreren Videodateien geht nun VIEL EINFACHER.

Siehe bitte 1. Post dieses Threads.

Der UT Video Codec ist Klasse und habe ich auch schon oft neben Lagarith empfohlen

Am schnellsten ist er wenn du davon den 422er nimmst und den Dividor auf 2 stellst. (zumindest wenn man mit diesem Codec aufnimmt - bei normaler Encodierung mag das anders sein

Zitat von MissMatta

Bei grafiklastigen Spielen habe ich persönlich bessere Ergebnisse mit dem Haken drin =)

Hmm muss mich korrigieren. Sogar bei Doom und Descent scheints mit Force CPU Processing schneller zu laufen.

Interessant

Nur komisch, wieso ich dann anderes schrieb. Irgendwo muss ja der Gedanke hergekommen sein, hm^^ Vllt wars bei WinXP anders oder UT Video Codec ist da anders als Lagarith, ansonsten ka

Zitat

dass das Aufnehmen auf mehere Platten gleichzeitig auch die insgesamt verfügbare Datenrate erhöht, oder etwa doch?

Was meinst du damit? Es wird lediglich gespalten geschrieben. Bei 2 Platten wird also 50% auf der einen und 50% auf der anderen Platte geschrieben. Dann kannst du diese beiden Dateien mit dem RawCap Converter zusammenfügen.

Zitat

Richtig... und das ist derCamtasia Encoder, mit dem ich die Rohdateien exportiert habe, auf keinen Fall. Ich war nur zu faul, mir die Rohdaten aus dem Dateisystem zu fischen und diese dann mit Premiere zu exportieren, das ich normalerweise benutze.

Premieres Encoder ist auch nicht viel besser. Auch nur der schlechte MainConcept Encoder, welcher CPU ineffizient arbeitet und die Kompressionstechniken dem x264 weit hinterher hinken.

Mit x264 würdest du 2048x1152 machen können. Da bin ich mir sicher. Einfach weil die Dateien mit x264 kleiner gehalten werden können und die Qualität besser ist.

Zitat

Nicht ganz... Die "Extract Audio Stream" Funktion extrahiert ALLE Spuren aus dem Video. Ich spare mir allerdings bei einem 2 Stunden Video lieber die InGame-Audio-Spur, die mir Premiere ja zusammen mit der Video-Spur anzeigt. Ich brauche also nur meine Stimme zu extrahieren.

Na gut ;D
Aber das ist dann ein spezieller Fall. Ich denke die meisten werdens einfacher haben per Extract Audio Stream. Also wer AVIMux nicht braucht, hatts leichter mit Extract Audio Stream.

Zitat

So, ich werde deine Zitate in meinem Video nochmal anmerken. Dann dürfte das Tutorial ja doch noch halbwegs richtige Fakten liefern^^ Danke jedenfalls für dein ausführliches Feedback

Gerne doch

Zitat

Kannst du mir denn einen guten empfehlen? =)

VLC unterstützt das Audio- oder Videoformat "LAGS" nicht.

Post #2 Erster Absatz.

Ja. Und Processing Threads beim DXTory auf 2.

Der UT Codec läuft sogar ein Tick schneller als Lagarith wenn du ihn genau so eingestellt hast, wie ichs dir gesagt habe und deine HDD Leistung nicht zu schwach ist. (also was jetzt Aufnahme betrifft)

Und vllt mag Premiere den Codec ja lieber.

Hat nur RGB24 und YUV24 Farbraum zur Auswahl. Also nur verlustfreien Farbraum.

Performance ist ok, aber dieser Farbraum verbraucht zu viel Leistung, so das einem das nicht viel bringt.

In dem anderen Thread hab ich dir auch geantwortet, wo du fragtest und habe dir da u.a. den UT Video Codec inkl Einstellungen angeboten. Bisher haste dich dazu nicht mehr geäußert

Geil, du hast auchn 27" Monitor?

Du dürftest eig. alles in 2048x1152 aufnehmen können 2048x1152 gibt auf Youtube die Stufe Original am Player, 1920x1080 nicht :P. 2048x1152 sieht also auf Youtube deutlich besser aus
Aber verstehe nicht ganz, was dich daran hindert das Spiel in kleinerer Auflösung ebenfalls in Vollbild zu spielen?

Auf mehreren Festplatten schreiben ist für all diejenigen interessant die nicht so schnelle Platten haben. Vor allem ist das ja meist bei Laptops der Fall.
Somit wird die Last halt auf diesen aufgeteilt. Super Sache !.
Ob DXTory schneller oder langsamer als Fraps ist, hängt ja mehr vom gewählten Codec ab.

Stimmt nicht ganz. Max Audiospuren sind 8. Also 10 Mikrofone könntest du nicht aufnehmen ;D
Für mich ist das sogar essentiell wichtig, das IGS und Mikrofon getrennt aufgenommen wird, weil das Mikrofon muss bei mir in Mono aufgenommen werden, sonst hört man mich nur aufm linken Kanal, da ich aber IGS in Stereo will, brauch ich sogar diese Trennung und Fraps ist somit für mich gar unbrauchbar geworden.
Und ja ich find Fraps + Audacity ebenfalls mega umständlich^^.

Zu latest vs Stable: Irgendwie ziemlich unglücklich von ExKoder gemacht - weil wenn er 'ne neue Version rausbringt, dann ist die ältere bei stable und die latest oben Nix weiter. Im Grunde isses actual version und previous version Und ja - Das Programm ist von nur einer Person geschrieben. ExKoder.
Hat er im Forum nämlich gesagt, als ein user frage ob er das Programm alleine geschrieben hat.
Ich rate dringenst zu der Latest Version, da die 109 ein Schreibgeschwindigkeitsbug hat unter Windows 7 mit externen bzw USB 3 Festplatten, die mit der 109 Version nur mit USB 2 Speedverhältnissen beschrieben wurde bei bestimmten Chipsätzen. x38 und x79 z.B. sind davon betroffen. Ich selber hab den x38 Chipsatz.

Hinzu kommt das eine Aufnahme in ein Lossy Codec unglaublich viel mehr Rechenleistung verschlingt, neben der Tatsache, das dies nicht zu empfehlen ist

ui ui - Nun weiß ich warum du Performance Probleme hast

Nimm im YV12 Farbraum auf. Gleiche Qualität (4:2:0), aber DEUTLICH schneller als YUY2 zu schreiben ! Außerdem Lossy Encoder wie z.B. x264 geben standardmäßig in YV12 aus, Youtube gibt ebenfalls in YV12 aus. Wenn du nun YUY2 nimmst, muss das halt umgerechnet werden und das kann beim Encodieren zu Geschwindigkeitsverlust führen wegen dem Mehraufwand. Standardmäßig ist RGB eingestellt (verlustfreier Farbraum, aber sehr sehr sehr rechenintensiv und speicherverbrauchend und nicht notwendig, da spätestens Youtube es eh auf YV12 encodet)
Unterschiedliche Farbräume sind nur RGB und YUV. Das hab ich vor kurzem auch falsch gesagt ^^. YV12 und YUY2 etc sind nur unterschiedliche Chroma Subsampling Qualitäten. Bei 4:2:0 wird halt weniger Farbinformation gespeichert als mit 4:2:2 Verlustfrei wäre halt 4:4:4.
Mehr zu dem Thema kann man hier lesen:
http://encodingwissen.de/grund…deokompression/intraframe
Farbraum ist also RGB und YUV - und YV12, YUY2 etc sind halt YUV Farbräume mit unterschiedlicher Chroma Subsampling Qualität.
Du sagst zwar nun im Anschluss, das du YV12 empfiehlst, aber hattest ja offensichtlich vorher YUY2 gehabt. Und das erklärt warum du Probleme hattest in großer Auflösung aufzunehmen.
PS: Du hättest ruhig auch das Tutorial in 2048x1152 encoden können. Brauchst nur gescheiten Encoder :P. Mein MeGUI Tutorial ist in 2048x1152, 30fps, 43min,50sek Länge, CRF 20 und hat eine Videospur von 26,7 MB
Use Multithreading erhöht die Geschwindigkeit nicht nur ein bisschen

Nullframes schreibt halt bei auffolgenden identischen Frames Dummyframes. Also leere Frames eben.
Auf gar keinen Fall anhaken wenn man aufnimmt. Es reduziert die Performance extrem.

Naja die Höhe und Breite bei Clipping sind natürlich Pixelangaben, keine cm xD

Klar kannst du auch mit 25 fps aufnehmen. Einfach 25 eintippen ;D
Falls du trotz YV12 usw nicht in hoher Auflösung aufnehmen kannst, nehm halt in 25fps auf. 25 ist auch noch ein flüssiges Bild. Nur tiefer als 25 sollte man vermeiden.
Mit 60fps muss kein Mensch aufnehmen. Da DXTory die ingame FPS nicht auf einen Multiplikator der Aufnahme FPS lockt, sowie Fraps es ja macht. Wenn man natürlich den Synchronise Video FPS Haken drin hat, so wie du atm im Video, dann zwingste DXTory dazu Video FPS an File FPS anzugleichen. Dann haste eig. einen der großen Vorteile von DXTory eliminiert - Die Unabhängigkeit von Video FPS und File FPS^^
Wie gesagt. Bei Fraps musste Multiplikator der Aufnahme FPS erreichen. Sprich du hast bei Fraps 30fps eingestellt, dann gibt dir Fraps im Spiel 60fps, wenn du mehr als 60fps erreichst während Aufnahme, bei mehr als 90, 90 usw, Hast du also nur 50fps, wird Fraps dich auf 30 belassen.
Also wenn die File FPS konstant bleibt, dann hast du eig. auch keine Framedrops in der Aufnahme. Aber 40fps ingame FPS ist natürlich etwas grenzwertig. Kann sein das du da Framedrops hast. Aber in YV12 aufnehmen und ggf. 25 fps wird da 'ne Menge bringen an deiner VideoFPS (ingamefps).
Du hast nämlich eig. genug Festplattengeschwindigkeit um wirklich alles in 2048x1152 aufnehmen zu können
Och ich hätte nichts dagegen wenn du in 2560x1440 aufnimmst
Die kleineren Qualitätsstufen sind ja trotzdem noch am YT Player^^ Aber wenn deine Platte nicht reicht -> RawCap, wenn das auch nicht geht, dann limitiert der Rest des PCs ;D

Audio -> 44.1 khz - Mehr als 44.1 khz gibt Youtube eh nicht.

Mikrofon kann in Mono aufgenommen werden, nur IGS in Stereo -> Weitere Datenreduktion.

Force CPU Processing Haken weg - killt Performance. Zumindest bei Spielen die nicht grafikintensiv sind hab ich durch der Option eher weniger FPS.
Start Movie Capture when detected ist sinnvoll wenn man z.B. ein Intro des Spiels aufnehmen will und den Anfang komplett mitkriegen möchte.
Multi GPU fix ist mehr dafür, falls man Probleme mit Multi GPU Grafikkarten hat.

Ja und die Environment Information ist mir immer äußerst am Herzen liegend, wenn ihr Probleme mit DXTory habt !

Den RawCap Converter hätt man durchaus mal zeigen können, denn RawCap kann halt wirklich mal sinnvoll sein.

AVIMux braucht man dafür nicht.^^

Einfach Rechtsklick auf die AVI -> Extract Audio Stream - schon haste die ganzen Audiospuren draußen. AVIMux völlig unnötig

Nein Fraps splittet nicht wegen FAT32. Fraps speichert im AVI 1.0 Standard,welcher keine Dateien größer als 4 GB erlaubt. Fraps macht das aus Kompatibilitätsgründen, weil manche schlechte Videosoftware aus Steinzeitzeiten keine AVI 2.0 lesen kann.

Video Setting ist rein nur für den DirectShow Output. Eben die Einstellungen wie es gestreamt werden soll.

Und mal bissl Offtopic: VLC ist kein guter Player Kriegst mit einem anderen Player mehr Speed und bessere Bildqualität.

Bei so'nem kleinen 480p Video wird wahrscheinlich das Zitat von Didee eintreffen.

Bei x264 sollte man aber eig. in der Lage sein auch mit schwächerem Internet wenigstens 720p zu machen. Würde die Videoqualität auf Youtube bereits deutlich anheben.

Ein verlustbehaftet codiertes Video ist bestückt mit b und p frames. b frames referenzieren auf andere b-frames oder auf einem vollen frame (i-frame) und haben nur die Veränderungen zu diesem Frame gespeichert. die predictive frames enthalten ebenfalls nur Teilinformation, statt ein voller Frame.

Naturgemäß kann man daher nur an i-Frames schneiden, wenn das Video nicht re-encodiert werden soll. Denn sonst würden ja b-frames auf Frames referenzieren, die gar nicht mehr vorhanden sind, wegen deinem Split. Diese Videostelle wäre dann fehlerhaft.

Verlustfreies Material lässt sich framegenau schneiden. Tools -> AVS Cutter - ist da aber umgekehrtes Schneiden (du bestimmst, was du behalten willst). Alternativ das verlustfreie Material mit einem anderen Programm verlustfrei splitten.

Definitiv total falsch. Das war noch nie so.

Wenn der Uploader fertig encodiert anzeigt ist mind. 240p fertig.

Sprich es ist anschaubar.

Es heißt NICHT, das alle Qualitätsstufen durchencodiert sind !

Vllt ist ein Resize Filter oder irgendein anderer Filter langsamer, so das x264 warten muss.

Achso:

Zitat

Video ist vor ner Stunde bei Youtube angekommen und ist verarbeitet worden. 1920x1080, aber es gibt maximal nur 720p zur Auswahl? Was hab ich falsch gemacht?

Isses denn mittlerweile 1080p?

Dauert ja auch 'ne Weile bis Youtube es encodiert hat.

Also bei Preset Medium sollte deine CPU aber auf 100% sein, hmm.

Aber 17fps ist doch schon 'ne recht ordentliche Speed.

Also ich hab auf Medium mit meinem Q9450 gerad mal rund 8 - 10 fps

17 ist doch geil

Naja ich würd nicht noch schneller als fast machen, sonst ist die Kompressionseffizienz denk ich sehr geschmälert. Wenns dir egal ist - ok

Aber bedenke auch:

Zitat von Didée

Dass bei schnellen Presets die CPU-Auslastung sinkt (und mithin auch die Skalierung), liegt vor allem an der "Frametype decision": die ist nämlich noch nicht parallelisiert (oder nur wenig). Deswegen wird die Performance von dem Thread limitiert, der die Frametype decision durchführt.

Das Parallelisierungs-Problem ist knifflig: durch die vielen internen "Tools" gibt es zu jedem Zeitpunkt einen ganzen Strauß an verschiedenen Möglichkeiten, wie man die I/P/B-Verteilung anordnen kann, es muss also einiges probiert und geschätzt werden. Und vor allem: solange noch nicht entschieden ist, was mit Frame N eigentlich gemacht wird, solange kann auch noch nicht entschieden werden, was mit den später nachfolgenden Frames N+x am besten zu tun ist.
Die Frametype decision ist praktisch (noch) der Knackpunkt, an dem die ganze Parallelisierung auf eine rein lineare Kette zusammenbricht, bzw. auf den linearen Anteil warten muss.

Ein Problem fällt mir jetzt doch noch auf:

Ob die FPS Rate geändert werden muss, sollte auch gefragt werden. AssumeFPS(30) & ChangeFPS(30) ist jetzt bisschen sinnfrei.

Es arbeitet nun auch fehlerhaft:

AVISource("D:\XVideos\Lets Play Descent\d1x-rebirth 2012-01-24 01-53-54-418 VR0.avi,""D:\XVideos\Lets Play Descent\skulltag 2010-12-30 18-40-18-70.avi,"audio=true).AssumeFPS(30.000)

Korrekt muss es so aussehen:

AVISource("D:\XVideos\Lets Play Descent\d1x-rebirth 2012-01-24 01-53-54-418 VR0.avi","D:\XVideos\Lets Play Descent\skulltag 2010-12-30 18-40-18-70.avi",audio=true).AssumeFPS(30.000)

Sprich das Komma wird an der falschen Stelle gesetzt.

Aber soweit sag ich schonmal vielen Dank für deine ganze Mühe

Erstmal fällt mir nichts weiteres ein.

Sollte man vllt, da es nicht abgefragt wird, irgendwo dann hinweisen, das man die .bat Datei bearbeiten muss im oberen Teil (Auflösung usw).

SET FILEEXT=.avi -> Kommt eig. nur avi in Frage. Bei anderen Containern muss auch ein anderer Decodierungsweg als AVISource angegeben werden. Da wäre es am besten, das man file index + FFVideoSource nimmt, statt DirectShowSource, da aber der idx job davor ist, ist das nicht so einfach automatisierbar. (oder vllt auch doch, bricht man halt den avs script creator nachm index job ab und lädt dann die AVS von der bat.) Dennoch wird das eher weniger zum Tragen kommen denk ich, da man MeGUI eh verlustfreies Material geben sollte, was dann eigentlich eh AVI ist.

Wie groß die Enddatei wird hängt vom gewählten Qualitätsfaktor ab, von den gewählten Encodiereinstellungen und von der Komplexität deines Videomaterials.

60 FPS ist etwas heftig.

Würde da ins Avisynth Script

ChangeFPS(30)

ergänzen. 60fps tut echt nicht Not. Und spätestens Youtube machts dir auf 30fps. Also kannstes auch selber schon machen und hast nur die Hälfte an Frames zu encodieren (kleinere Datei)

Vllt kann man ja auch noch einbauen, ob Resize überhaupt verwendet werden soll?

Wäre ja blödsinnig den Resizer anzuwenden auf die gleiche Zielauflösung wie das Quellvideo

x264 nutzt die cores nicht gut?

Bei mir ~99 - 100% jeder Kern (Quadcore Q9450)

Oder hier bei 16 Kernen:

Bild ist nicht von mir

Allerdings hab ich das Batchscript mal bisschen aufgeräumt^^ Sieht bei mir nun so aus:

@Echo off
set /p="AVISource("<nul > script.avs
for %%f in (*.avi) do set/p=""%%f","<nul >> script.avs
echo audio=true).AssumeFPS(30.000) >> script.avs
echo Lanczos4Resize(2048,1152) # Lanczos4 >> script.avs
echo ConvertToYV12()>> script.avs

Wobei ich den Resize bei mir nicht drin habe, habs nur als Beispiel fürs Forum so.
Weil ich nehm ja eh in 2048x1152 auf.

Achja und ich habe auch Audio=false bei mir, da ich DXTory verwende und da hinterher ein anderer Audio Input rein kommt, als das, was im Video drin ist.