DXTory unterstützt halt auch Streaming..
Beiträge von De-M-oN
-
-
Richtig. Wobei da TMPGEnc leider eh nur Lanczos3 hat.
Aber da könnte man sonst auch ein Avisynth Script machen mit Lanczos4.
TMPGEnc kann Avisynth Scripte öffnen.
Über Avisynth ist dieser Filter dann aber natürlich ohne CUDA.
-
Es lässt sich also sagen, dass CUDA weder auf die Renderzeit noch auf die Dateigröße einen merklichen Einfluss hat
Welch ein Wunder wenn x264 ein CPU Encoder ist

CUDA wird von TMPGEnc aber auch für die Filter benutzt.
-
Introvideo hinzufügen -> Hauptvideo anhängen.
Introaudio hinzufügen -> Hauptaudio anhängen.Geht aber nur wenn es kein FLAC ist, da es sonst mitm FLAC Header Probleme gibt, wird dir MKVMergeGUI dann auch sagen.
Falls du also FLAC benutzt:
Audacity öffnen, Introaudio und Hauptaudio importieren. Komplette Hauptaudiospur markieren (Klick auf freie Stelle im linken Bereich der Spur wo Samplerate etc steht um sie komplett zu markieren)
STRG+X drücken, dann irgendwo in die Introspur reinklicken. K drücken (dann springt der Cursor ans Spurende). STRG+V drücken. Die nun leere untere Spur mit dem x schließenDann auf Datei -> Exportieren -> FLAC.
Dann wäre das muxen so:
Introvideo hinzufügen -> Hauptvideo anhängen.
Neue FLAC hinzufügen -
-
Vermutlich inkorrekte Projekteinstellungen die nicht zum Quellmaterial passen.
Sollte das Intro unterschiedlich encodiert sein im Vergleich zum Hauptvideo (und sei es bloß die FPS Rate anders) dann musste das getrennt encodieren.
Also erst Intro mit Projekteinstellungen die dem Quellmaterial entsprechen encodieren und danach das Hauptvideo mit ebenfalls korrekten Projekteinstellungen.
Danach mit MKVMergeGUI zusammenmuxen.
1. Video(intro) hinzufügen, 2. Video(Hauptvideo) anhängen
-
AVISource wählen.
Das liegt daran das im Tutorial noch eine ältere MeGUI Version läuft.
In neuerer Version wurde direkt die Untergruppe von DirectShow (in dem Fall AVISource) auf den Buttonname gelegt.
-
Du beschwerst dich über zu lange, aber willst einen kompletten 2. Encode machen?
Das widerspricht sich

MeGUI ist weder kompliziert noch dauert es lange.
Was dauert denn lange? Das Encoden? Dann haste differenzierte Settings in x264.
Beide Programme benutzen den x264 Encoder, von daher sind Zeitunterschiede nur durch verschiedene Encodiereinstellungen.
Unkomprimiert ist erstrecht mistig. Dann konvertierste die Farbe auf RGB um und wenns dann wieder auf YUV geht, verlierste Qualität. Außerdem dauert unkomprimiert immens lange.
Wenn schon, dann einen anderen Lossless Codec, wo du dann den selbigen Farbraum benutzt wie dein jetzigen.
-
Manchmal kriegt er es hin, manchmal nicht.
Lagarith ist äußerst kritisch mit Handbrake.
Ich würde dir empfehlen die GUI zu wechseln. Dein jetziges Videomaterial wegen Handbrake wegzuschmeißen wäre etwas blöd.
Versuch dich doch mal an MeGUI. Da kannste den Decodierungsweg dann auch selber bestimmen. (Bei Lagarith also AVISource.)
-
Handbrake kann kein Lagarith.
Andere x264 GUI benutzen oder Codec in DXTory wechseln.
-
Fade und Dissolve ist sogar im AVS Cutter drin

-
Neben TransAll hab ich dann noch 2 weitere Transition Filter gefunden.
http://avisynth.org/warpenterp…ition_25_dll_20040123.zip
http://avisynth.org/warpenterp…ransition_25_20040130.zip -
http://www.debugmode.com/frameserver/
[ Video-Tutorial ] Technischer Lets Play Leitfaden
Am besten da mal reinschauen. Da wird das alles erklärt mitm Frameserver und so.
Aber wie gesagt: Avisynth hat ja schon einiges

-
http://avisynth.org/vcmohan/TransAll/docs/index.html
Gibt aber noch mehr glaub. Aber schonmal ein Filter mit vielen Effekten.
___
Falls du Vegas oder Premiere hast, wäre doppeltes Encodieren nicht nötig, da es dann mit Frameserver geht.Ausgehend von doppelt Encodieren:
Qualität geht nicht verloren, wenn du bei Audio und Video verlustfreie Formate nimmst.
z.B. Lagarith bei Video und PCM Wave oder FLAC bei Audio.
Beachte nur das dann die Projekteinstellungen exakt dem Quellmaterial übereinstimmen müssen. (FPS Rate, Auflösung usw, alles, selbiges mitm Ton (samplerate, Bittiefe etc).
Den Farbraum beim Lagarith auf YV12 stellen.
-
Nicht schneller als Medium für effiziente Kompression gerade bei inkomplexerem Material würde Slow oder Medium erheblich! besser komprimieren als schnellere, wo dann selbst inkomplexeres Material aufbläht.
Schnellere Presets nur dann, wenn man es wirklich so will.
Von Ultrafast und Superfast würde ich allerdings die Finger lassen. Insbesondere aber von Ultrafast. Weil auf Ufast gibt es wie gesagt nicht mal b-frames. Sämtliche absolut anzuratende Kompressionsmechanismen sind somit ausgelöscht.
-
Der fällt bei gut komprimierbarem Material groß aus und bei schwer komprimierbarem Material kleiner.
Minimale Qualitätsdifferenz kann es geben zwischen slow und ultrafast. Wenn du sicher gehen willst, machste bei Ultrafast halt ein klein Tick besseren CRF.
CRF ist zwar sehr sehr akkurat, aber trotzdem keine Magie.Aber glaub mir: Ultrafast wirst du heftig größere Datei kriegen, da hier nicht mal b-frames genutzt sind. Nur volle Frames zu schreiben ist absolute Kompressionsvernichtung.
-
Audio Config ist doch in MeGUI komplett zu machen.
Container würd ich eher MKV statt MP4 nehmen.
Video und Audio werden getrennt encodiert.
Der muxt nicht automatisch schon. Das machter nur beim One Click Encoder.
Wenn du trotzdem bei deiner Datei schon Ton hörst, kann es sein das dein Videoplayer die externe Tondatei erkannt hat.
-
-
Bahhhhhhhhhh oh gott wie peinlich

Ja natürlich sind 6mbit dann sein Download ..
Bah bin wohl schon müde oder ka xDUpload ist bei DSL 6000 = 576 kbit/s (oder 512 bei manchen anderen)
-
hm eine 6k leitung ist ja nicht wirklich die welt, ich weiß jetzt auch nicht was da für ein upload ist..
Das was du an Upload hast ;D
Du hast doch 6 mbit Upload, also weißte doch wie schnell 6 mbit ist

__
Nimm schnelleres Preset bei Dead Space.
Außerdem sind das meine Presets, und nicht sam's^^