Beiträge von Sagaras

[lexicon]Blender[/lexicon] als Editing Programm zu betrachten um Videos damit zu bearbeiten haben bis her nur sehr wenige in betracht gezogen.

Und in der Tat ist [lexicon]Blender[/lexicon] weit mehr als es den Anschein hat.

Hauptseite: http://www.blender.org/

Als freies Grafikprogramm kann man damit alles machen was man sich nur Vorstellen kann. Der auf Python aufbauende Script den [lexicon]Blender[/lexicon] verwendet ermöglicht einen so ziemlich alles zu machen was man machen kann.
Ob nun Modeling, Composing, Simulationen, Spiele Entwicklung, Skulpturing, Animationen. Es ist alles möglich. Selbst Motion Tracking ist möglich und noch mehr.

Features: http://www.blender.org/features/

Aber auch Videos können dort bearbeitet werden und wie in jeder anderen [lexicon]NLE[/lexicon] auch sehr schön aufpoliert werden oder gestaltet werden mit visueller Vorschau.

Da [lexicon]Blender[/lexicon] aber eines der kompliziertesten Softwares ist, ist der Umgang damit am Anfang schwer. Man muss sich erst einmal mit einigen Sachen auseinandersetzen

Oftmals das sich die GFXler und Designer damit auseinandersetzen um tolle Sachen zu erstellen wie Intros, Outros etc. pp.

[lexicon]Blender[/lexicon] verfügt über 3 Arten Videos zu kreiren.

• Über fest eingebundene Video Codecs
• Über fest eingebundene Image Codecs
• Über [lexicon]Frameserver[/lexicon]

Dabei hab ich leider nur für Linux Freunde was über die [lexicon]Frameserver[/lexicon] was lesen können damit diese gleich via FFMpeg encoden können. Für Windows hab ich leider nix gefunden. Vllt das jemand eine Ahnung damit hat wie man den [lexicon]Frameserver[/lexicon] von [lexicon]Blender[/lexicon] unter Windows nutzen kann?

Um auf jedenfall [lexicon]Lossless[/lexicon] das ganze später ausgeben zu lassen haben wie neben dem [lexicon]Frameserver[/lexicon] 2 weitere Optionen. Einmal die AVI RAW Auswahl via RGB oder die Speicherung von Einzelbilder auf der [lexicon]Festplatte[/lexicon] via PNG, BMP oder Targa RAW.

Es als AVI RAW zu speichern verbraucht enorm viel Platz und man läuft auf die Gefahr das die Datei bei größeren Videos von mehr als 15Min nicht mehr gelesen werden kann.

Es gibt aber auch den H264 [lexicon]Encoder[/lexicon] den man auf [lexicon]Lossless[/lexicon] einstellen kann. Inwieweit das aber toll ist weiß ich nicht. Für [lexicon]AVISynth[/lexicon] auf jedenfall mistig, da indexiert werden muss.

Die Speicherung einer Animation als PNG oder BMP sieht da schon viel besser aus. Man hat dadurch auch 1 Vorteil: Wenn man den Rendervorgang unterbricht, kann man anhand der Bilder die schon geschrieben sind ein Video erzeugen lassen.

Die Bilder werden als Einzelbilder durchnummeriert im Ausgangsordner gespeichert.

Mit RADTools kann man nun die ganzen Bilder in ein Video via [lexicon]Lagarith[/lexicon] oder UT Video encoden lassen und damit weiter verarbeiten.

Das ganze ist recht Simple:

• Angefangen in [lexicon]Blender[/lexicon] habt ihr eine FPS (Standard ist 24 FPS in [lexicon]Blender[/lexicon]). Diese könnt ihr ändern wie ihr wollt und solltet dann diese merken.
• Danach wenn ihr in [lexicon]Blender[/lexicon] alles fertig habt stellt ihr euren Output auf PNG mit folgendem Setting:
  
  
  • RGB
  • Color depth 16Bit
  • Compression: 100%

  
  Oder ihr nehmt BMP mit der Einstellung RGB
  

• Als nächstes erfolgt die Render Animation. Je nach Rechner und Aufwand den man in [lexicon]Blender[/lexicon] betreibt dauert dies nun. Dabei werden nun die Bilder von Framestart bis Frameende gerendert und erstellt.
• Ist alles fertig, nimmt man sich RADTools zur Hand (Download hier).
• Hier öffnet man nun die [lexicon]Radvideo[/lexicon].exe und wählt den Ordner mit den erstellten Bildern aus.
• Die erstellten Bilder werden nun zusammengesetzt via "List file..." . Dazu einfach auf das erste Bild klicken damit es makiert ist und dann auf "List file..." klicken. Danach wird gefragt ob ihr alle oder nur das makierte Bild laden wollt. Da sagt ihr dann natürlich alle. Sind alle in der Liste (Sieht dann so aus ungefähr: ?????.png*1-244) dann speichert ihr die Liste.
• Dann wählt ihr die erstellte Liste aus und sagt nun "Convert a file..." . Dort setzt ihr den Outputtyp auf AVI und schreibt unter Convert Video bei Force die FPS rein die ihr in [lexicon]Blender[/lexicon] verwendet habt dafür und klickt weiter auf Convert
• Dann wird nur noch gefragt mit welchem [lexicon]Codec[/lexicon] das ganze zusammengesetzt werden soll. Dort wählt ihr dann entweder [lexicon]Lagarith[/lexicon] oder UT Video aus.
  

  
  

  Bedenkt das die Bilder RGB Material sind und somit gestochen scharf sind. Bedeutet das ihr es auch auf RGB in [lexicon]Lagarith[/lexicon] oder UT Video encoden lassen könnt. YV12 oder YUY2 sind aber sparsamer vom Platz her.
  

• Danach könnt ihr die Bilder löschen und habt nun euer [lexicon]Lossless[/lexicon] [lexicon]Blender[/lexicon] Video das ihr ganz normal überall verarbeiten könnt.

Da ich selbst mich noch mit [lexicon]Blender[/lexicon] auseinandersetze und vieles noch nicht verstehe, da ich weder Designer noch GFXler irgendeiner Art bin, werde ich diesem Tutorial einen Youtuber vorschlagen der auf Deutsch und Englisch [lexicon]Blender[/lexicon] erklärt indem er Stück für Stück Sachen damit bastelt die man beispielsweise für Intros verwenden kann.

Für alle die mit [lexicon]Blender[/lexicon] schon arbeiten sollen und selbst wissen wie was geht doch eher uninteressant

Sein Kanal nennt sich BlenderDiplom

Eines seiner deutschen Tutorials dazu: https://www.youtube.com/watch?v=jTm5XyCWi7Q

Aber auch auf der [lexicon]Blender[/lexicon] Homepage selbst sind Tutorials von Leuten die euch das Wunderschön erklären können wie das alles geht: http://www.blender.org/support/tutorials/

Zur Videobearbeitung gibt es in [lexicon]Blender[/lexicon] selbst den Video Editing wo ihr eure Videos ([lexicon]CRF[/lexicon] Vorzugsweise) reinladen und bearbeiten könnt. Eigentlich für Motion Tracking vorgesehen aber egal (Der Zweck heiligt die Mittel ;D)

Ein kleines Beispiel von mir hier wo ich erst [lexicon]Blender[/lexicon] verwende, es wie schon beschrieb [lexicon]Lossless[/lexicon] in [lexicon]Lagarith[/lexicon] gespeichert habe und dann via Aegisub und [lexicon]AVISynth[/lexicon] zusammengesetzt habe mit Ton.
https://www.youtube.com/watch?v=uDNDerhyFCM&hd=1

Verwendet habe ich das von BlenderDiplom gezeigte Tutorial, da ich selbst in diesen Grafiksachen ne Niete bin

Aber wie ihr seht kann ich dank [lexicon]Blender[/lexicon], Aegisub und [lexicon]AVISynth[/lexicon] die komplett alleman Free sind professionelle Videobearbeitung durchführen

Jo, damit viel Spaß beim Ausprobieren von [lexicon]Blender[/lexicon].
Und lasst euch nicht Abschrecken davor

Auf den ersten Blick ist immer alles kompliziert.

Damals im Krieg... vor genau 11 oder 12 Jahren gabs AutoGK (Auto Gordian Knot) das mittels [lexicon]AVISynth[/lexicon] und [lexicon]VirtualDub[/lexicon] auch DVDs IFOs einlesen und [lexicon]encodieren[/lexicon] konnte ohne tausende Griffe zu machen.

Das Teil beruhte auf einen Encode mit dem XVID oder dem DIVX [lexicon]Codec[/lexicon]. Man konnte eines von beiden auswählen dabei. Dabei wurde stehts 2pass encoded um die Qualität noch sehr hoch zu halten.
AutoCrop Funktion und diverse andere Sachen ermöglichten diesem Tool eine sehr leichte und vor allem Idiotensichere Videoencodierung.

Die Videos waren dann halt entweder mit XVID oder DIVX ausgestattet hinterher und die Audiofiles wurden mit Lame MP3 encodet und später alles in ein AVI [lexicon]Container[/lexicon] eingefügt.

Der [lexicon]AVISynth[/lexicon] Skript dabei beinhaltete schon damals eine inteligente Deinterlaced Funktion bei dem das Video durchgescant wurde und Interlaced Abschnitte verglich.

Damit war und ist AutoGK noch bis heute eines der besten XVID/DIVX [lexicon]Encoder[/lexicon] die es gibt. Vor allem sehr leicht zu bedienen und man kann auch sehr schnell mal eben eine DVD einlesen via IFO Datei.

Sehr nice für XVID gewesen. Jedenfalls tausend mal einfacher als sich direkt mit VDub zu befassen und den XVID [lexicon]Encoder[/lexicon] falsch zu bedienen. ;D

Ein 1pass Encode bei XVID ist eines der miesesten Settings die man dafür machen kann. Da wird das Video ja regelrecht vergewaltigt. Da hat man beim 2pass Encode weitaus mehr gekonnt.

Nix desto trotz ist die Entwicklung für AutoGK zum erliegen gekommen, da es mitlerweile bedeutsam bessere Programme gibt die weitaus effizienter arbeiten.

Gerade h264 ist in der heutigen Zeit überall am Werk. BluRay's, HD Übertragungen, Internet Streaming.

Überall ist h264 am Werk. Der effizieteste [lexicon]Encoder[/lexicon] dafür ist der [lexicon]x264[/lexicon] [lexicon]Encoder[/lexicon]. Da er aber nicht in VDub eingebunden werden kann direkt und auch nicht muss, da VDub ebenfalls über einen eigenen [lexicon]Frameserver[/lexicon] verfügt, kann man das ganze über diesen [lexicon]Frameserver[/lexicon] auch mit [lexicon]x264[/lexicon] direkt [lexicon]encodieren[/lexicon] lassen.

[lexicon]MeGUI[/lexicon] ist z.B. ein Nachfolger des AutoGK. Es basiert ebenfalls auf [lexicon]AVISynth[/lexicon] Skripte und ist ebenfalls dafür ausgelget BluRay's, DVD und PVR Material zu verarbeiten.

TMPEnc, [lexicon]Handbrake[/lexicon] [lexicon]MeGUI[/lexicon], etc... sind alles Tools die mit [lexicon]x264[/lexicon] [lexicon]encodieren[/lexicon] können.

[lexicon]x264[/lexicon] darf aber nicht mit [lexicon]x264vfw[/lexicon] verwechselt werden bitte. Der [lexicon]x264vfw[/lexicon] [lexicon]Codec[/lexicon] kann ebenfalls in Vdub angewendet werden. Ist aber nicht zu empfehlen für LPs. Genausowenig wie XVID oder DIVX für LPs gut sind.

Gerade XVID hat bei einem Encode massive Blockbildungen gegenüber [lexicon]x264[/lexicon] bei gleicher Dateigröße beim gleichen Video.
Das würde man dann schon deutlich erkennen wenn man beide gegenüber stellt.

Will man die gleiche Qualität erzielen bei XVID, so ist die Dateigröße hinterher mindestes 6 oder 5 mal so groß als die von [lexicon]x264[/lexicon].

Das sollte mal so als Info dienen

VDub ist nicht schlecht. Aber XVID für LPs auf YT zu verwenden ist etwas Fail. Generell es noch zu verwenden ist Fail
Es sei denn man besitzt Multimediafestplatten oder DVD Abspielgeräte die mit AVI Datein und XVID/DIVX umgehen können.

Aber wenn man es schon unkompliziert machen will, dann wäre der Griff zu [lexicon]Handbrake[/lexicon] vllt ein Anfang.

Oder wenn man bei VDub bleiben will, den [lexicon]Frameserver[/lexicon] von VDub dabei verwenden und das ganze via [lexicon]MeGUI[/lexicon] [lexicon]encodieren[/lexicon].

Das macht nämlich deutlich mehr Sinn und ist auch wesentlich Effizienter

Zitat von anihex

In meinen Let's Plays hatte ich jedoch 2 Videos die mit unterschiedlichen Farbräumen kodiert waren. Es handelt sich dabei um ein [lexicon]Let's Play[/lexicon] "Together" wo wir das Video-Material meines Kumpels YV24 und mein eigenes RGB war. [lexicon]AviSynth[/lexicon] mochte das nicht und meinte, ich solle den Farbraum bitte anpassen.

Korrekt. RGB ist zwars YV24 sehr identisch von der Abtastrate des Farbraums. Jedoch ist das eine YUV und das andere nun mal RGB. Diese beiden Farbräume sind allein vom Aufbau schon unterschiedlich. Einige [lexicon]AVISynth[/lexicon] Filter können nur mit YUV Farbräumen etwas anfangen, wärend andere unbedingt RGB brauchen. Zu wissen wann man was braucht und wie man effizient einsetzt ist entscheident dabei.
Ein Video im RGB Bereich kann den Filter Tweak z.B. nicht nutzen, da Tweak ausschließlich für YUV Farräume bestimmt ist.

[lexicon]AVISynth[/lexicon] Videobearbeitung ist absolut Linear und daher bei vielen recht schwer nachzuvollziehen. Weil die meisten Leute kennen und wollen auch oft nur Nicht Lineare Videobearbeitung durchführen. Weil es halt einfacher für viele auch ist. Aber wer die Lineare Beareitung beherscht würde daraus die tollsten Sachen entwickeln können.

Zitat von anihex

Ich könnte mich jetzt irren. Aber wenn die FPS "korrigiert" werden soll, ist "ChangeFPS" eigentlich besser. Oder?

Nein. AVISource gehört zum DirectSource und diese Input Filter sich nicht 100% akkurat beim einlesen von Daten.
SagaraS Scriptmaker (GUI)
Warum meinste mache ich mir die Mühe bei AVISource beim [lexicon]SSM[/lexicon] das ganze mit AssumeFPS zu korrigieren? Was meinste warum [lexicon]MeGUI[/lexicon] sich die Mühe macht es mit AssumeFPS zu korrigieren? ;D
ChangeFPS kommt bei einen AVISource immer nach einem AssumeFPS

Bei FFMS2 kann ChangeFPS auch ohne AssumeFPS gleich kommen, da FFMS2 schon akkurat laden tut.

Zitat von anihex

Ich könnte mich jetzt irren. Aber wenn die FPS "korrigiert" werden soll, ist "ChangeFPS" eigentlich besser. Oder?

RGB und YUY2 Material wie vom [lexicon]Frameserver[/lexicon] ausgegeben dauern länger beim Encode. Das wird immer so sein. Wenn der [lexicon]Encoder[/lexicon] bereits vom [lexicon]Frameserver[/lexicon] YV12 Material bekommen würde, wäre der [lexicon]Encoder[/lexicon] schneller.
Was meinste warum [lexicon]MeGUI[/lexicon] es automatisch zuerst immer in den Skript schreiben möchte? ;D

Und was meinst du mit mischen von Farbräumen? xD Was willst du da mischen jetzt? YUY2 ist ein 4:2:2 Planer, wärend YV12 ein 4:2:0 Planer ist und RGB sowie YV24 4:4:4 Planer sind.
Der Unterschied wie das Material behandelt wird liegt im Detail. Bei RGB und YV24 ist die Verarbeitung extrem hoch, da sowohl Luma als auch Chroma beim Encode als gestochen scharf behandelt werden müssen.
Bei YUY2 muss Luma als gestochen Scharf behandelt werden und Chroma im 2:2 Verhältnis.
Den schnellsten Encode bekommste jedoch mit YV12.

Du verlängerst dir selbst den Encode wenn du bereits die ganze Zeit mit YV12 aufnimmst, es in YUY2 konvertierst und es dann in YUY2 [lexicon]encodieren[/lexicon] solltest. Die Datei wird einfach größer dadurch.

Sollteste dir vllt noch mal genau anschauen diese Problematik.

Zitat von anihex

(Kaum zu glauben, dass ich Let's Plays mit [lexicon]AviSynth[/lexicon] gemacht habe...)

Allein bei diesen Satz sollteste dich mal fragen warum du es in der [lexicon]Batch[/lexicon] verwendest, wenn du [lexicon]AVISynth[/lexicon] an sich meiden möchtest ;D
Warum denkste das [lexicon]AVISynth[/lexicon] das decodieren kann das Material vom [lexicon]DebugMode Frameserver[/lexicon]?
Aber sobald du [lexicon]AVISynth[/lexicon] verwendest, sollteste es auch korrekt anwenden und nicht nur lieblos und 0850 nur mit AVISource.
Wenn du [lexicon]AVISynth[/lexicon] meiden willst, dann lass es halt weg und überleg dir einen anderen Weg.
Aber so wie jetzt in der [lexicon]Batch[/lexicon], wendeste es A) an und B) wendeste es falsch an.

Wie gesagt... bau in dein [lexicon]AVISynth[/lexicon] Skript in deiner [lexicon]Batch[/lexicon] wenigstens AssumeFPS mit ein, damit es korrekt ist. Die FPS kannste die vom [lexicon]Quellvideo[/lexicon] nehmen. Entweder automatisch erkennen lassen wie im [lexicon]SSM[/lexicon] oder selbst irgendwie eine Eingabe dafür einbauen.

Zitat

rate1 = (Round(Float(clip0.framerate * 1000)) / 1000) / 2
rate2 = Round(clip0.framerate) / 2
rate = (rate1 == rate2) ? 1 : 1001
ratefaktor = (rate == 1001) ? 1000 : 1
clip1 = (rate == 1001) ? clip0.AssumeFPS(Round(clip0.Framerate) * 1000, rate) : clip0.AssumeFPS(round(clip0.framerate), rate)

Dieser Teil wende ich im [lexicon]SSM[/lexicon] an dafür. Der regelt das für AssumeFPS automatisch.

Denn 29.970 FPS sollten akkurat mit 30 / 1,001 angegeben werden und 30 FPS z.B. mit 30 / 1
Ansonsten kann es auch mal vorkommen das AVISource halt auch mal inkorrekte FPS nimmt.

Zudem verstehe ich auch nicht warum du von [lexicon]AVISynth[/lexicon] dich so distanzieren willst? Es gibt dort Resizer die zig mal besser sind als das Bicubische oder Bilineäre in NLEs wie [lexicon]Sony Vegas[/lexicon]. Gerade Spline16 in Kombination mit ResampleHQ ist ein Segen wegen dem kaum Sichtbaren Ringing und den neutralen Encode. Ist viel besser als das andere was NLEs oft verwenden.

Dafür das du deine LPs mit [lexicon]AVISynth[/lexicon] mal gemacht haben solltest, haste dich nicht sonderlich mit beschäftigt.

Und die Idee mit der [lexicon]Batch[/lexicon] hatten schon viele vor dir gehabt. Auch mit FFMPEG. Nur waren da schon welche bei wo es auch gleich via [lexicon]Batch[/lexicon] auf [lexicon]Youtube[/lexicon] hochgeladen wird nach dem Encode. Auch das [lexicon]AVISynth[/lexicon] dort richtig angewandt wurde bereits. Deswegen sage ich das deine [lexicon]Batch[/lexicon] keine Neuheit in diesem Forum darstellt und auch sonst nix besonderes ist. Weil es halt schon vor dir welche gab die da schon bessere Sachen präsentiert haben.

Zudem ist es einfach so das [lexicon]MeGUI[/lexicon] durch seine schon eingebaute Jobliste und dem AutoEncode viel besser ist als eine [lexicon]Batch[/lexicon]. Da kann man gleich mehrere Sachen nacheinander hinweg reinschmeißen und ohne dabei zu sein [lexicon]encodieren[/lexicon] lassen.
In deiner [lexicon]Batch[/lexicon] müsste alles einzeln gemacht werden. Unpraktisch an sich.

Dazu auch noch das es viele User noch gibt die vllt noch was anderes machen wollen damit. So zwingst du ihnen aber etwas regelrecht auf.

Ich hatte vor dem [lexicon]SSM[/lexicon] auch eine Batchdatei gehabt dafür. Nur war es so das jeder es anders haben wollte. Zum einen wollten welche die FPS ändern lassen, die anderen wollten wieder das es gleich encodiert wurde. Dann gab es wieder welche die sagten das das mit der [lexicon]Batch[/lexicon] zu unübersichtlich ist und wollten lieber eine [lexicon]GUI[/lexicon] dafür.
Auch war es für viele ein Fail den [lexicon]Encoder[/lexicon] jedesmal in der [lexicon]Batch[/lexicon] umzustellen mit Parametern die sie so nicht verstanden.

Dann habe ich mich entschlossen den [lexicon]Encoder[/lexicon] wegfallen zu lassen und lieber ein reinen Skriptmaker zu entwickeln. Entstanden aus einer [lexicon]Batch[/lexicon] man glaube es kaum xD Somit hatte nun jeder eine [lexicon]GUI[/lexicon] für die Skripte und [lexicon]MeGUI[/lexicon] für die Jobliste und Encodersettings.

Vorteil am [lexicon]SSM[/lexicon] ist das es mit weiteren Plugins schon ausgestattet wurde die jeder selbst festlegen kann. Und in [lexicon]MeGUI[/lexicon] dank AutoEncode und Jobliste + das man den [lexicon]Encoder[/lexicon] schön über eine [lexicon]GUI[/lexicon] einstellen kann sehr übersichtlich.

Bei einer Batchdatei muss es für jeden User individual gestaltet werden, da jeder User anders kodieren möchte. Bedeutet aber auch das er sich mit den [lexicon]CLI[/lexicon] Einstellungen erst befassen muss. Und das wollen viele einfach nicht. Genausowenig wie viele oftmals kein [lexicon]AVISynth[/lexicon] Skript schreiben wollen.

Daher... wenn du was machst, mach es so, das es zum einen Korrekt ist und zum anderen das jeder die Freiheiten hat selbst zu bestimmen.

Seh es bitte als Tipps an um deine jetzige [lexicon]Batch[/lexicon] besser zu machen. Ansonsten sieht es ja so gut aus. Nur halt das du es weiter optimieren müsstest.

Dein [lexicon]AVISynth[/lexicon] Sript besteht nur aus AVISource. Sehe ich das richtig? AVISource ohne AssumeFPS. Weißt du warum [lexicon]MeGUI[/lexicon] bei AVISource ein AssumeFPS dahinter macht? Um die kleine Verschiebung der FPS die mit AVISource eventuell auch mal falsch sein kann zu korrigieren.
Desweiteren frage ich mich wieso du überhaupt [lexicon]AVISynth[/lexicon] verwendest, wenn du eh mit FFMPEG das ganze kodieren tust? Warum machste es dann nicht direkt?
Die Fake AVI vom [lexicon]DebugMode Frameserver[/lexicon] wird FFMPEG gewiss lesen und verarbeiten können.
Des weiteren sehe ich keine Farbraumkonvertierung. Aber der [lexicon]DebugMode Frameserver[/lexicon] gibt kein YV12 aus. Sprich wenn ich mich nicht irre encodierst du in YUY2, wenn das nicht automatisch von FFMPEG geregelt wird.

Ein bisschen Fail dann würde ich sagen xD
Nur weil [lexicon]MeGUI[/lexicon] [lexicon]AVISynth[/lexicon] nutzt, heißt es noch lange nicht das FFMPEG AVS Datein als Input braucht. Und wenn du die AVS Datein schon erstellst dann auch korrekt.
Kein Mensch der mit [lexicon]AVISynth[/lexicon] arbeitet würde AVISourcen ohne AssumeFPS laden.
Wenn du FFMPEGSource im AVS Skript verwendest oder andere Sourcen, die brauchen kein AssumeFPS unbedingt. Aber AVISource brauch es auf jeden Fall.

Zitat von Haaligaali

Da Job22 mit 7.25FPS lief und Job24 gerade mit 7.07FPS runterrattert

Das ist eine recht leichte Schwankung und akzeptabel.

Vielmehr interessant ist der Fehler "Process exits with error: 0xFFFFFFFF (-1)"
Könnte mir vorstellen das es am alten [lexicon]AVISynth[/lexicon] liegt das du nutzt.
Weil eigentlich wäre v2.6.0 besser. Kann mir auch vorstellen das du das [lexicon]MeGUI[/lexicon] interne [lexicon]AVISynth[/lexicon] noch nimmst.

Desweiteren [lexicon]MeGUI[/lexicon] mal updaten lassen auf 2496 und auch den Haali Media Splitter mal updaten lassen.

@Haaligaali Den Skript mal posten der verwendet wurde bei dem Video wo es abgeschmiert ist und zusätzlich dazu die passende Log von [lexicon]MeGUI[/lexicon]. Musste mal im Log Verzeichnis von [lexicon]MeGUI[/lexicon] etwas wühlen und das entsprechende Datum + Urzeit raussuchen.

Eventuell das man da was sieht. Am besten die Log soweit posten bei dem du angefangen hast die 9 Videos zu encoden.

Das sind die Vordifinierten Größenangaben die im gesamten Skript Global wirken. Das bedeutet das ich diese Variablen nirgendwo weitergeben muss. Weder in eine Funktion, noch sonstwo. Ich kann diese Variablen überall anwenden.

Desweiteren dürfen Bildpunkte keine Kommazahlen sein (Float), sondern müssen Ganzzahlig sein (Integer).

Der Rest sollte auch klar sein dann wieder: Die Größe wird durch einen Faktor bestimmt, damit das Seitenverhältnis des Displays nicht komische Verhältnisse annimmt. Man will ja nicht das Figuren auf einmal Fett oder Hauchdünn werden, sondern man will ja so nah am Original sein wie möglich ;D

Die Größe wird ermittelt durch die schon vorhandene Größe aus der Clip Variable Oben.

Einmal wird Breite und Höhe für das kleinste Display benötigt, einmal für das große Display und einmal für die mittlere Größe.

Da Oben und Unten die gleiche [lexicon]Auflösung[/lexicon] haben, stimmen diese Werte für beide Displays

Als Beispiel:

Video hat die [lexicon]Auflösung[/lexicon] 640x960
Danach wird in Oberen und Unteren Bildschirm geteilt und haben dann jeweils 640x480

Die Rechnung dann sind die festen Bilder auf dem fertigen Bild.

Ich schreib das jetzt mal ausführlich mit Zahlen:
Global wmin = Int(640 * 1.5)
Global wmin = 960
Global hmin = Int(480 * 1.5)
Global hmin = 720
Global wmax = Int(640 * 3.4)
Global wmax = 2176
Global hmax = Int(480 * 3.4)
Global hmax = 1632
...

Somit hat das kleinste Display die Größe von 960x720 und das große 2176x1632

Somit kann ich wmin, hmin, wmax, hmax, wmit und hmit überall einsetzen und brauche es nicht ständig anzugeben.

Das sind sozusagen die fertigen Größen die du im Video siehst dann.

Hier hätte ich noch mal ein anderes Beispiel aus der selben Rohdatei wieder.

Fertiges Video auf YT: https://www.youtube.com/watch?v=UPONbBj3-LM&HD=1
Skript: http://www.mediafire.com/view/weaq54zfqz1bi3k/NDS2.avs

Hier habe ich StackVertical genutzt um ein Sliden der einzelnen Displays zu realisieren.

Das ganze ist einfach nur ne Spielerei.

Das Tolle an den Skripten ist es, das ich nur noch die Punkte von a bis b angeben muss, wann was passieren soll. Der Rest ist völlig Automatisch und akkurat und ich brauch mich nur noch drum zu kümmern an welche Frames das alles kommen soll.

Hier mal ein kleines Beispiel wie sowas aussehen kann bei einem NDS

Fertiges Video auf YT: https://www.youtube.com/watch?v=k3GeLih9SO8&HD=1
Skript: http://www.mediafire.com/view/9mbdvrd2de6ortc/NDS.avs

So sah das Aufnahmebild aus: http://www.mediafire.com/view/…lo94/NDS_Aufnahmebild.png
Und hier die [lexicon]Mediainfo[/lexicon] vom Rohvideo: http://www.mediafire.com/view/…s0cmbi9/NDS_Mediainfo.txt

Das Video auf YT entspricht nicht der Länge die in der [lexicon]Mediainfo[/lexicon] steht. Ich habe es einfach mal gekürzt, da es ja nur als Beispiel dienen sollte. ;D

Sowas ist in der Tat möglich. Die Frage besteht wie die Aufnahme aussieht?

Wird der gesamte Desktop dafür aufgenommen oder exakt nur die Videobereiche wo das Spiel stattfindet?

Wichtige Befehler für die Umsetzung wären Crop, Trim, Overlay, Layer, Animation, ApplyRange und gegebenfalls noch ein oder zwei Funktionen zur Bildwechslung.

Das Prinzip ist eigentlich einfach: Zwei Indizien der Aufnahme werden benötigt. Einmal für das obere Display und einmal für das untere Display.

Dann erfolgt die Anordnung auf dem Gesamt Display. Das kann z.B. auch ein Wallpaper sein das mit ImageReader geladen wurde.

Dann sollte sich überlegt werden wie man den Bildwechsel macht. Dafür muss sich eine Funktion entsprechend erstellt werden. Die Animation die du machen willst sozusagen um den Bildwechsel zu gestalten.

Beim [lexicon]SSM[/lexicon] sind auch noch einige Sachen als Plugin. Im Plugin Ordner findeste die Datei Blend.avsi. Die kannste in deine Skripte importieren lassen und hast somit den Zugriff auf alle Funktionen der avsi Datei. Wenn du die Blend.avsi mal öffnest mit [lexicon]AvsPmod[/lexicon] oder nem Editor, dann siehste alle Funktionen + deren Funktionsbeschreibung. Vllt sind da ein paar Sachen dabei die du noch nutzen kannst.

Das ist normal. Die [lexicon]MeGUI[/lexicon] Vorschau ist kein Live Player, sondern ein Frameplayer. Wenn du die AVS in [lexicon]VirtualDub[/lexicon] oder MPC öffnest, dann haste ne Live Vorschau die dann flüssiger ist.

Ich ersehe nicht was du machst und kann dir das nicht beantworten. Vllt nimmste auch Videos wo der Decompressor erst angeschaltet werden muss bzw dieser von irgendwas blockiert wird.

Bei [lexicon]Lagarith[/lexicon] ist es die Einstellung "Prevent Upsampling When Decoding" wenn dort ein Haken ist und bei MJPG Aufnahmen im [lexicon]Afterburner[/lexicon] wenn "Enable MJPG [lexicon]decoder[/lexicon]" nicht angehakt ist, kommt es zu einen Decompressor Problem. Da er es nicht decodieren kann.

Bei sowas muss man achten. Gibt es ein Decompressor Problem, dann ist meist ein falscher [lexicon]Decoder[/lexicon] dran schuld oder der [lexicon]Decoder[/lexicon] ist nicht verfügbar weil er nicht eingeschaltet wurde oder aber auch der [lexicon]Decoder[/lexicon] wurde noch gar nicht installiert.

Dir fehlt der Decompressor. Sprich ein [lexicon]Decoder[/lexicon] arbeitet nicht oder ist nicht eingeschaltet.

Ich weiß xD Ich verhau die Buchstaben auch hin und wieder xD

Die Beschreibung mit: Bester [lexicon]Encoder[/lexicon] + viel einfacher + weniger Umfang = Murks

Jedenfalls ist das oft so Da wo man weniger einstellen kann, kommt meist auch weniger raus. ;D Man unterschlägt dem User ja gerade die Freiheit selbst zu bestimmen wie es arbeiten soll ;D

Vor allem wenn man nur FPS und Auflösungspresets vorgelegt bekommt und man nix weiter machen kann ist das recht armselig ;D

Zitat von De-M-oN

Da du Tweak wahrscheinlich eh nicht nutzt, hätte es Sinn tweak abzuwählen und den haken bei dem ersten Filter rein zu machen, welchen du auch tatsächlich einsetzt. (macht zwar kein Unterschied, ist für dich persönlich aber wahrscheinlich übersichtlicher.)

Wenn er sich unsicher ist, sollte er es einfach auf Default lassen

Links oben bei MT steht: Position. Sprich man legt fest ab welcher Position der MT wechseln soll. Ist er auf Position Tweak und Tweak ist nicht an, aber es erfolgen weitere Filter, so wird der MT Mode von der Position Tweak genommen.

Sprich die Position bestimmt die Priorität welches ab wo genommen wird.

Beispiel: Position Tweak bekommt Mode 4 und [lexicon]Motion Blur[/lexicon] bekommt 2. (MT Settings)
[lexicon]Blockbuster[/lexicon] und [lexicon]Motion Blur[/lexicon] Filter sind an und Tweak ist aus (Nicht bei den MT Settings), dann wird nur Mode 4 im Skript stehen, da Tweak ja raus fällt.
Mit Mode 4 laufen dann [lexicon]Motion Blur[/lexicon] und [lexicon]Blockbuster[/lexicon].

Ist aber Tweak an, so wird Tweak mit Mode 2 laufen wärend die anderen beiden Filter mit Mode 4 laufen.

Ist nur bei Tweak Mode 2 an, so laufen alle Filter mit Mode 2. Sprich man kann die anderen Haken im MT raus machen wenn alle nachfolgenden Filter ab der Tweak Position mit Mode 2 arbeiten sollen. So hatte ich mir das gedacht und sollte jedem die Möglichkeit geben das individuell zu gestalten ;D

Der Standard reicht aber meist schon absolut aus.

TS oder [lexicon]MP4[/lexicon] Aufnahmen die via von einer Konsole über eine Capture Card kommen haben oft den Makel das diese in VFR (Variable Framerate) vorliegen. [lexicon]AVISynth[/lexicon] ist aber ein reines [lexicon]CFR[/lexicon] (Constant Framerate) [lexicon]Frameserver[/lexicon].

Zudem wird DirectShowSource ledeglich nur noch für Notfälle benutzt und sollte weitesgehend vermieden werden. Für AVC Material bietet sich FFMpegSource2 an (FFMS2) oder aber auch der DGAVCIndexer. (Beide Plugins für [lexicon]AVISynth[/lexicon] sind bei [lexicon]MeGUI[/lexicon] mit dabei)

Aber um auf TS und [lexicon]MP4[/lexicon] Aufnahmen mit VFR zurückzukommen. Das ist eine sehr komplizierte Sache, wenn man es dann mit [lexicon]AVISynth[/lexicon] direkt bearbeiten will. Für VFR braucht man nämlich exakte Timecodelisten. Bedeutet man braucht ein Tool was die VFR Aufnahme korrekt laden tut ohne Asynchronisation und Abweichungen der Länge um dann eine Timecodeliste zu erstellen. Anhand dieser Liste kann dann auch geladen werden mit korrekter FPS.

VFR Aufnahmen haben oftmals das doppelte der FPS. Ein CFR Programm läd ein Video aber anhand der gegebenen FPS. Da diese ja falsch ist, wird das Video schon falsch geladen und kann somit Asynchron werden.

Ich habe denke ich eine Methode gefunden wie man das ganze von VFR zu [lexicon]CFR[/lexicon] wandeln kann und auch erfolgreich bei kleineren Aufnahmen probiert. Jedoch noch nie bei längeren Aufnahmen von mehr als ner halben Stunde

Das ganze hab ich in diesem Beitrag aufgeschrieben: Sound und Video asynchron bei Avisynth

Habe es aber wie gesagt noch nicht bei größeren Aufnahmen testen können.
Hier das Plugin für [lexicon]AVISynth[/lexicon]: VFRtoCFR
Das andere sollteste in dem angegebenen Thread auch finden.

Leider hat bei ihm der TSMuxer nicht funktioniert, aus welchen Gründen auch immer. Aber dies war der Schlüssel bei meinen Testversuch.

Für Gewöhnlich zeichnet man am besten in [lexicon]CFR[/lexicon] auf. Da es einfacher zu Handhaben ist

Zitat von MrsLittletall

Ich würde einfach nur gern wissen, was das Problem von DirectShowSource war? Das Script sah genauso aus wie im Tutorial übrigens.

Das Problem bei diesem Ladebefehl ist das es anhand deine [lexicon]FFDShow[/lexicon] [lexicon]Codec[/lexicon] Einstellung arbeitet. Oder mit anderem Worten deine DirectShow Codecs ;D Diese kannst du mit Sicherheit irgendwo einstellen bei dir. DirectShowSource nutzt einen externen Filter als Decodierer. Damit ist er sehr anfällig und kann nicht immer 1:1 von Rechner A nach B kopiert werden. Weil wie gesagt die [lexicon]Decoder[/lexicon] erst dazu eingestellt werden müssen, da er ein externen Filter verwendet. Das kann HaaliMedia Splitter sein oder [lexicon]FFDShow[/lexicon] etc.

shutdown -s -t

Habe ich nur einmal genutzt und das nur aus Spaß bei WinNT damals

Ich brauchte es eigentlich auch nie. Wozu auch? Wenn, dann hab ich den Rechner ausgemacht Oder wenn der irgendwas noch gemacht hat, dann hat der eben mal die ganze Nacht durchgerechnet

Meine Eltern waren da mit mir noch recht Human was das Betreiben des Rechners anging

Und Ehrlich gesagt, sehe ich auch kein großen Sinn darin. Denn es gibt bereits genug Uploadprogramme wo sowas schon integriert ist. Ich meine... selbst DownloadManager Progamme haben solch eine Funktion

Oftmals das es als Plugin auch angeboten wird.

Hab ich bisjetzt bei fast allen Programmen gesehen die einen Spapelverarbeitungsvorgang gemacht haben und ihre Listen somit abgearbeitet haben.
Besonders bei Prozessen die sehr Zeitaufwendig waren/sind

Ich kann dir aber die FPS von [lexicon]AVISynth[/lexicon] erklären und dann könnteste mir sagen ob es analog oder digital ist

1 [lexicon]Frame[/lexicon] / 25 FPS = 0,040Sek = 40ms

Zu sehen ist: 1 Bild das 40ms angezeigt wird und es dann zum Bildwechsel kommt. Hier muss man sich einfach eine Filmrolle vorstellen mit angeketteten nacheinanderfolgenden Bildern. Bei Encodierungen werden aus bestimmten Frames sogenannte Zwischenbilder die man in b und p Frames einsortieren kann. Wärend i Frames die ganzen Bilder darstellen. Dies dient der Komprimierung des Filmmaterials

Und dann kenne ich noch FPS die aufgrund eines Speichers dargestellt werden. Zu finden bei Spielen.
Hier erfolgt der Bildwechsel durch das flipen 2er Bilder. Sprich 1 [lexicon]Frame[/lexicon] wird in den Hintergrundspeicher geschoben und 1 [lexicon]Frame[/lexicon] in den Frontspeicher. Dadurch erziehlt man den Bildwechsel, da es ja kein Vorgegebenes Videomaterial gibt, sondern die Bilder in echtzeit berechnet werden müssen parallel zur Ausgabe des Spieles. Hier kann es dann durchaus vorkommen das Frames nich komplett berechnet werden können und trotzdem schon ausgegeben werden. Oftmals eine Frage der Hertzfrequenz des Monitors zur FPS des eigentlichen Spieles. Sind die Werte unterschiedlich, kanndurch das Flipen der 2 Frames auch [lexicon]Tearing[/lexicon] entstehen.

Daher wirst du [lexicon]Tearing[/lexicon] auch niemals bei Filme finden, da Filme nur mit ganzen Bildern arbeiten.

Daher schätze ich mal das du [lexicon]digitale FPS[/lexicon] in Verbindung zu den Sachen meintest die ich oben im ersten Abschntt erklärt habe und analoge FPS für die Spiele, da diese erst berechnet werden müssen.

Aber um dich zu beruhigen, es gibt keine Analoge FPS. Die FPS des Spieles setzt sich aus der Leistung des PCs zusammen. Daher können Spiele bereits schon mit 60 FPS absolut flüssig laufen so wie sie sollen und wenn sie mit 120 FPS zwischenzeitlich ablaufen bewegt sich nicht mehr als 60 FPS, da der Monitor eventuell eh nur mit 60Hz läuft.

Spiele sind meist so konzipiert das diese so schnell wie möglich die Bilder ausgeben, je wie schnell die Hardware ist. Manche Spiele haben aber auch eine Obergrenze von dem Entwickler bekommen, damit der Prozess nicht zu schnell läuft.

Bei Spielen nennt man es daher nicht analoge FPS, sondern die momentane Geschwindigkeit der [lexicon]GPU[/lexicon]. Und diese wird in Hertz angegeben.

Aufnahmeprogramme zeigen nur das Verhältnis in FPS, damit der User so ungefähr weiß was das Spiel hergibt. Eine FPS kann man erst haben, sofern man Frameanzahl und Zeit kennt. Da bei Spielen aber erst die Bilder berechnet werden müssen und dann ausgegeben werden müssen gibt man sowas in Hertz an. Abhängig von dem was der Entwicker vorgegeben hat für das Spiel und der eigenen Hardware.

In [lexicon]MeGUI[/lexicon] finden wir ebenfalls eine FPS Anzeige in Form einer Geschwindigkeit. Dort wird wie im Spiel auch berechnet wie schnell der Prozess geht. Hier aber der Unterschied wieder das man hier die Gesamtlänge anhand der Frames und die FPS kennt. Durch den Berechnungszustand durch [lexicon]AVISynth[/lexicon] und der Encodiergeschwindigkeit ergibt sich eine Gesamtgeschwindigkeit wieviele Frames pro Sekunde gerade verarbeitet werden können. Abhängig wieder von der Leistung der Hardware.

Es sind keine Analogen FPS. Weil sowas gibt es in der Regel nicht.

Ein Spiel was erst mit 120 FPS läuft und auf einmal durch bestimmte Grafische Effekte oder Polygonanzahl zusammenbricht auf 10 FPS nennt man auch Leistungseinbruch der [lexicon]GPU[/lexicon] oder [lexicon]CPU[/lexicon]. Weil diese mit der Berechnung nicht hinterherkommen und die Bilder nicht liefern können die gefordert sind. Bei Emulatoren und einigen PC Spielen gibt es daher auch Frameskip Funktionen, damit die Berechnung von Bildern übersprungen wird um so eine bessere Performance des Spieles zu gewährleisten.
Es ist halt eine Frage wie schnell der Bildauswechsel geschieht. Und der läuft nun mal bei Spielen anders ab als bei Filmen.

Hier mal ein Beispiel aus einen Programm das durch eine Vektorenberechnung ein Sternenfeld generiert und diese dann durch ein Flipen des Vor- und Hintergrundspeichers zu einer Bewegung animiert werden. So wie es nun mal bei Spielen halt üblich ist:

TYPE punkt3d
        x AS INTEGER
        y AS INTEGER
        z AS INTEGER
END TYPE


DIM p3dsterne(0 TO 99) AS punkt3d


FOR i = 0 TO 99
        p3dsterne(i).x = RND * 320 + -(RND * 320)
        p3dsterne(i).y = RND * 200 + -(RND * 200)
        p3dsterne(i).z = RND * 500 + 1
NEXT i


CONST focus = 160
SCREEN 7, , 0, 1


DO
FOR i = 0 TO 99


        xp = -(CLNG(p3dsterne(i).x) * focus / (p3dsterne(i).z + focus)) + 160
        yp = -(CLNG(p3dsterne(i).y) * focus / (p3dsterne(i).z + focus)) + 100


        PSET (xp, yp), 15


        p3dsterne(i).z = p3dsterne(i).z - 1
        IF p3dsterne(i).z <= 0 THEN p3dsterne(i).z = 500
NEXT i

PCOPY 0, 1
CLS
IF INKEY$ <> "" THEN EXIT DO
LOOP

Zwars ist das noch eine alte Methode, aber das Prinzip zwischen Front- und Backbuffer sollte dann klar sein.
Das Programm hat die Geschwindigkeit die es durch die For Next Schleife hat. Würde ich also die Anzahl an Sternen erhöhen, desto langsamer wäre das ganze. Da die For Next Schleife Zeit brauch um die einzelnen Sterne auf dem Bildschirm zu zeichnen. Erst dann erfolgt ein Bildwechsel zwischen dem Front- und Backbuffer. Bedeutet: Je mehr Sterne da drin sind, desto höher ist die Wahrscheinlichkeit das das Bild anfängt zu flackern. Ich werde aber nicht sehen das die Sterne erst gezeichnet werden. Weil das Bild was als nächstes kommt, kommt für gewöhnlich erst in den Backbuffer und dann in den Frontbuffer. Damit entsteht flüssige Bewegung mit solchen Prinzip. Geschwindigkeit ist halt bei diesem Beispiel hier von der [lexicon]CPU[/lexicon] und der [lexicon]GPU[/lexicon] abhängig.

Anders bei einen Film der via Projektoren erzeugt wird. (Kino z.B.) Dort macht das eine Maschiene anhand einer Filmrolle.
Ein [lexicon]Decoder[/lexicon] um Videos am PC abspielen zu lassen muss ebenfalls den Gesetzen des Front- und Backbuffers anwenden. Anders aber als bei Spielen muss hier nix berechnet werden, sondern nur decodiert werden. Das ist weitaus schneller.

Man kann aber auch Filme haben die man decodieren möchte um sich es halt anzuschauen auf dem Rechner, aber der Speicher nicht ausreicht. Folglich treten Framedrops auf und sind mit den Spielframedrops zu vergleichen. Ein [lexicon]x264[/lexicon] encodiertes Video in 1800p und mit 40 bis 50 FPS ausgestettet verschlingt sehr viel [lexicon]CPU[/lexicon] Leistung aufgrund höherer Decodierzeiten.

Lässt sich Mechanisch an einem Projektor auch erzeugen. Jedenfalls in dem Moment wo der Rotor der Filmrolle mal schneller und mal langsamer abläuft aufgrund mechanischen Verschleiß.
Ich denke hierzu könnte man Festplattengeschwindigkeiten zur Verdeutlichung zu Rate ziehen, die ja auch nicht immer konstant sich drehen, sondern mal etwas weniger und mal etwas mehr. Auch wenn es nur 0,1 MB Unterschied immer ist.