Du hast vergessen den [lexicon]IGS[/lexicon] und die Kommentarspur in ein ander zu fügen, sprich, mit einem Seperaten Audioprogramm wie audacity abmischen.. dann gibts keine probleme,
natürlich zuvor mit rechtsklick auf dein Quellvideo/Rohaufnahme und "Extract Audio Stream" dann wird für jede Audiospur eine Audiodatei erstellt..
aber da dies meist nicht Synchron zum Video ist, wenn auch nur in den Millisekundenbereich liegen, mag YT sowas nicht..
dafür Empfehlen wir die zusammenarbeit mit dem SSM, mit den man noch einen Ticken mehr Qualität bekommen kann (wenn richtig eingestellt)
MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)
-
-
danke für die hilfe habs aber auch noch anderst hinbekommen ..... hab in [lexicon]Dxtory[/lexicon] die audio dateien zusammen geführt über den AVIMux button und dann weiter verarbeitet hat wunderbar funktioniert

-
Die Empfehlung ist trotzdem es synchron mit [lexicon]SSM[/lexicon] zu exportieren.
Und wenn doch DXTory: Rechtsklick -> Extract Audio Stream ist ja denk ich etwas komfortabler

-
ja hab auch erster mit extract audio stream probiert nur ich hatte td nur den ingamesound als audio datei meine [lexicon]Mikrofon[/lexicon] ton spur aber wart wieder verschwunden
ich weis net was ich da falsch mach und wenn ich eben erster mit AVIMux die audio spuren zusammen leg und dann Extract audio stream mache dann hab ich ingame und [lexicon]Mikro[/lexicon] in einer datei dann stimmts ja wieder oder ? -
Der richtigere Weg wäre den Export mit [lexicon]SSM[/lexicon] zu machen. Du musst halt beide Tonspuren extrahieren 0 als Stereo und 1 als Mono. Dann hast [lexicon]Mikro[/lexicon] und Gamesound.
Das dann per [lexicon]Audacity[/lexicon] bearbeiten und abmischen. Fertig. -
0 als stereo wenn 0 auch der spielsound ist. Das sollte er wissen.
Bei [lexicon]SSM[/lexicon] gibts auchn Haken für zusammenmischen. Dann mischt [lexicon]SSM[/lexicon] dir die schon direkt zusammen.
-
http://youtu.be/9n47rEMm8BA (gegen 18:50 sichtbar)
[lexicon]MeGUI[/lexicon] H264 1440p Spline16 Resample HQ Slow CRL21 Encodezeit 135s 48,4MB
mit Slower dauert es 195s und ist 47,5MB groß
Nur auf Slow ist also chon ganz gut.
Der [lexicon]Spline[/lexicon] Resize ist wirklich etwas kleiner als lanczos4 mit seinen 51,7 MB
Ich habe nun auch gelesen ihr packt da BLUR mit [lexicon]SSM[/lexicon] rein um geringere Dateigrößen zu bekommen?
Sieht es nicht schärfer besser aus ?Selbe Frage auch was Spline16 und Lanczos4 angeht;
Die paar MB kann ich für Quali opfern falls [lexicon]Lanczos[/lexicon] besser auf YT aussieht. Deine Vergleichsbilder auf Seite 160 machten mir den Eindruck Lanczos4 sei überlegen. -
Einfach mal überlegen was passieren würde, wenn du eine größere Dateigröße nicht erlauben würdest.
zb bei 1080p ist max bitrate 4000 kbit. Egal ob du mit Spline16 oder Lanczos4 ankommst. Ergo bleibt weniger Qualität über. Mehr Schärfe = schlechtere Komprimierbarkeit. Ringingbildung = schlechtere Komprimierbarkeit.
Mehr schärfe = Die Blöcke müssen feinere Übergänge haben, damit der Block nicht vom Auge erfasst wird. Bei schlechterer Komprimierbarkeit wächst die Blocksichtbarkeit an.
Und Ringing wie gesagt, kannste die Vergleichsbilder nicht als Referenz nehmen, da müssten andere her. -
D.h. also für private Zwecke, wo man mit maximale Qualität arbeiten möchte, einfach nur [lexicon]Spline64[/lexicon] (ist der schärfste?) und ResampleHQ anwenden und nur bei YT die Spline16 und Blurgeschichten machen? Oder wie?
-
Am schärfsten ist Lanczos4. Neigt aber auch schnell zu Ringing.
Für privat würd ich mir Spline36 ansehen.
-
Hi,
Ich habe ein Problem mit dem Sound.
Ich habe heute mal ein [lexicon]League of Legends[/lexicon] Game aufgenommen und habe mal NvidiaShadowPlay ausprobiert. An sich ne tolle sache, weil das das einzige Programm ist wo meine Stimme Synchron ist.
Das ist aber auch egal. Ich habe das Video schön mit [lexicon]MeGUI[/lexicon] enkodiert und danach den Sound mit mkvmergegui zusammengefügt. Standart.
Danach habe ich es mir angehört. Nicht nur, dass das Video total am Ruckeln ist (was natürlich auch an mir liegen kann) NEIN! Der Ton hört sich grottenschlecht an! (Noch unbearbeitet)
Nun Ich habe mal gelesen, dass NvidiaShadowPlay mit einer nicht konstanten FPS-Rate aufzeichnet. Hat das etwas damit zutun?
Den [lexicon]SSM[/lexicon] habe ich mal getestet, aber wenn ich ihn in [lexicon]MeGUI[/lexicon] einfügen will dann meckert [lexicon]MeGUI[/lexicon], dass er "SetMTMode" nicht kennt. Wenn ich dann SetMTMode aus dem Script entferne und es einfügen will, dann reagiert [lexicon]MeGUI[/lexicon] nicht mehr. (Zeile 6)Alles anzeigenCodeclip1 = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? ((float(Clip1.height * breite) / clip1.width) / 2 == round((float(Clip1.height * breite) / clip1.width) / 2)) ? ((float(Clip1.width * hoehe) / clip1.height) / 2 == round((float(Clip1.width * hoehe) / clip1.height) / 2)) ? clip1 : clip1.ConvertToRGB24() : clip1.ConvertToRGB24() : clip1clip1 = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? (((clip1.width * hoehe) / clip1.height > breite) ? Clip1.Spline64Resize(breite, ceil(float(Clip1.height * breite) / clip1.width)) : Clip1.Spline64Resize(ceil(float(clip1.width * hoehe) / clip1.height), hoehe)) : clip1.Spline64Resize(breite, hoehe).ConvertToYV12()back = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? (0 == 1) ? ImageSource("", 0, 0, Clip1.framerate).Loop(clip1.Framecount).KillAudio().Spline64Resize(breite, hoehe).ConvertToYV12() : BlankClip(clip1.framecount, breite, hoehe, "YV12", Clip1.framerate).KillAudio() : clip1 -
Avisynth MT beim [lexicon]SSM[/lexicon] Setup mit installieren. Sonst kanns schlecht gehen. Und sicherstellen das [lexicon]MeGUI[/lexicon] nicht sein internes ding nimmt (Options -> settings und sicherstellen das kein haken bei internal avisynth drin ist)
Shadowplay nimmt verlustkomprimiert auf und das mit dem arg ineffizienten [lexicon]CUDA[/lexicon]. Das solltest du überdenken und eher versuchen deine synchronisationsprobleme zu lösen. Mit Shadowplay wirst du nicht glücklich.
-
Das Problem ist, dass man sie nicht beheben kann.
Selbst mit externer Aufnahme via [lexicon]Audacity[/lexicon] ist es asynchron -.-Shadowplay mag zwar ein wenig schlechtere Qualität haben als [lexicon]Dxtory[/lexicon], dennoch benutzt es wenig Reccourcen und bei Spielen wie [lexicon]League of Legends[/lexicon] kann man es mal verwenden.
Gut habe jetzt [lexicon]SSM[/lexicon] neu installiert und gucke mal was bei rauskommt. Danke schonmal
//Edit:
Muss ich irgendwas bei dem [lexicon]SSM[/lexicon] beachten? Mein Video lässt sich nur bis 1:53 vorspulen. -
Ein wenig schlechtere Qualität???
Deutlich schlechter!Ich hatte mal eine test Aufnahme von bf4 gemacht und im so fertigen Rohmaterial waren gerade in dunklen Bereichen blockartefakte zu erkennen, renderst du noch einmal und dann nochmal Youtube. Am Ende hast di dann nur noch matsch im Video.
-
-
Hm ok, für alte 2D Pixelspiele reicht es

-
Noch nicht mal dafür
Sieht auch grottig aus dann xD -
Eine Kuriosität die ich gerade festgestellt habe zu meGUI:
Ich war dabei ein Video zu encoden was auf einer [lexicon]PS3[/lexicon] abgespielt werden soll. Und dabei dachte ich mir dann, ich könnte ja mal wieder auf Medium stellen vom Preset her.
CRF25 1080p Preset Slow. Renderzeit für 15 Minuten ca. 35 Minuten. Und auf Medium dann auf einmal 55 Minuten? Ich dachte immer je schneller das Renderpreset umso größer die Dateien und umso schneller der Encode?
Na egal. ich bleib beim Slow und fahr damit seit langem gut
Aber trotzdem ist es kurios dass ein schnelleres Preset länger zum rendern brauchen soll XD
-
Nö, das ist das Gerücht, an dem hier manche gerne festhalten. Selbst die Qualität leidet in meinen und anderen Augen nicht bei schnelleren Presets.
Aber schneller als Fast geh ich dann doch nicht. Wird die Datei trotzdem kleiner als Medium und wird schneller encodiert.Ich starte eh bald ein paar technische Umfragen und da wird es einen direkten Vergleich (auf Youtube) zu allen Presets geben, ohne dass man vor der Abstimmung weiß, was was ist.
-
Das ist kein Gerücht, das ist Fakt und auch von [lexicon]x264[/lexicon] Entwicklern bestätigt, das schnellere Presets schlechter für die Qualität sind und man bei nem schnellen Preset ein [lexicon]CRF[/lexicon] besser benötigt als bei slow.
ZitatIch starte eh bald ein paar technische Umfragen und da wird es einen direkten Vergleich (auf Youtube) zu allen Presets geben, ohne dass man vor der Abstimmung weiß, was was ist.
Wozu? Um die Aussage von [lexicon]x264[/lexicon] Entwicklern und der technischen Logik in Frage zu stellen?
Und wenn, dann solltest du schon hohe CRFs nehmen. Wenn du natürlich mit [lexicon]CRF[/lexicon] 15 ankommst, wird man wohl nich viel sehen.
Man sollte alleine sich mal Gedanken drüber machen warum eine weniger intensiv codierte Datei trotzdem kleiner wird. Das sollte einem doch schon zu denken geben, das da wohl weniger Qualität dann drinsteckt. Das sagt einem schon die Logik.
_
Die Encodierzeit hängt vom Material ab. Wenn du das gleiche Material codiert hättest, wäre slow langsamer gewesen.
Jetzt mitmachen!
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!