Beiträge von Sagaras

Zitat von Chron

Ich wollte wissen warum sie identisch kodiert sein müssen, um die Technik dahinter zu verstehen.
Du meinst ja bestimmt nicht nur den gleichen Codec, sondern auch die identischen Einstellungen.

Du kannst nicht zwei unterschiedliche Schuhe tragen, würde ja doof aussehen. Du kannst aber 2 gleiche Schuhe tragen die zueinander passen.
Die zwei Schuhe haben an sich immer gleiche Charakteristika. z.B. die Schuhegröße ist identisch oder sie sind aus dem gleichen Material angefertigt. Aber sie können auch Unterschiede haben wie z.B. ein für Links, den anderen für rechts. Oder du läufst mit einem in eine Matschpfütze und der andere bleibt sauber.

So verhält es sich mit den Videocodecs auch.

Die Qualität ist wie mit der Matschpfütze und kann und darf sich auch unterscheiden. Sprich jedes Video darf eine Unterschiedliche Bitrate haben.
Wie der Schuh angefertigt wurde, ob nun für Links oder Rechts, ist bei nem Codec das Verfahren wie Encodiert wurde. Ob nun mit Mainconcept oder CRF etc.

Und dann gibt es die festen Charakteristika, wie z.B. Auflösung, FPS, Farbraum, Farbmatrix, usw.

Stimmen die nicht, passen sie einfach nicht zueinander.

Videos die du halt ohne erneutem Encodieren schneiden möchtest, müssen exakt identisch codiert werden, bis halt auf einige kleine Abweichungen wie Bitrate oder Verfahren. Die Hauptsache ist das alles andere identisch sein muss damit die beiden als ein Stream (ein Paar, aus der Seite der Schuhe ^^) fungieren. Denn dieser Stream wird später in einem Container wie MP4 oder MKV nur einen festen Header haben und nicht 2 oder mehr für diesen einen Stream.

Stell dir vor du würdest eine Musiksammlung auf deinen Rechner haben. Alles MP3 Dateien und 2 FLAC Dateien. Und jetzt kommst du auf die Idee alles zusammen zu wurschteln als eine Musikdatei.
Was brauchst du?
A) ein Decoder der alle Musikdaten entschlüsseln und dekomprimieren kann.
B) Frequenz, Sampletiefe und Kanalanzahl müssen identisch sein

Und erst dann kannst du sie alle zusammen encodieren lassen mit einen neuen Codec. Wie z.B. MP3 oder FLAC

Und das macht MKVMerge halt nicht. MKVMerge kopiert einfach.

Zitat von Chron

Da kommt die Frage auf,
warum der Encoder nicht feststellen könnte, dass ab Frame X Video 2 beginnt, dessen Informationen ausliest und dann
1:1 wieder so herstellt.

Der Encoder stellt stellt gar nix fest, das macht dann wenn schon der Decoder.

Aber in deinem Falle wird ja nix kodiert, sondern kopiert. MKVMerge kann ja nur muxen, zusammensetzen und aufteilen. Da er aber nicht transkodieren kann, kopiert er halt nur.

Beim muxen fügt er mehrere Streams als Spur hinzu, beim Zusammensetzen kopiert er aus dem Video1 einen Stream aus dem Videocontainer mit der ID1 mit dem aus dem Video2 befindlichen Stream aus dem Videocontainer mit der ID1 zusammen. Dabei dürfen diese nicht unterschiedlich sein.

Wäre ja auch total bescheuert wenn dein Videoplayer auf einmal ein Video vor sich hat das erst 15min abspielt und auf einmal nicht mehr, weil ein anderer Codec übernimmt den du nicht hast oder dein Video wird deformiert, weil die Daten nicht mehr den aus dem Header entsprechen.

Und aufteilen kann MKVmerge auch noch. Einfach indem er an I-Frames (den Schlüsselbildern) auftrennt. Und diese I-Frames müssen im Video auch erst einmal in der GOP stehen.

Eine GOP die nicht aus Schlüsselbildern besteht kann niemals auf die ms genau geschnitten werden.

Zitat von Chron

Wenn du in 1152p verfügbar schreibst meinst du aber nur in der Qualität, die auswählbare Auflösung bei Youtube ist Maximal immernoch 1080p oder?

Youtube macht es meist so:
Dein Video wird auf YT zuerst als H264 encodiert. Wie die Einstellungen für jede Auflösungsstufen Encode sind, ist unbekannt.
Und die h264 Encodes werden halt alle parallel durchgeführt bei YT.

Dabei wird das hochgeladene Video als Referenzvideo genommen von dem codiert wird dann. Sprich das Original.

Da 320p, 480p und alle kleineren Stufen eher fertig sind, ist klar. Die brauchen ja auch nicht lange.

Und es werden auch immer zuerst die Non-Dash Variationen encodiert. Und dann die Dash Variationen.

Das sind aber erst einmal alles AVC Streams (H264 encodierte Videos)

Und mit sehr viel Glück werden diese dann auch noch überschrieben bzw. ausgetauscht und es werden auch mehrere Auflösungen möglich sein mit dem VP9 Encode.
Das heißt dann das dein Video nicht nur H264 Support besitzt, sondern auch VP9. Und VP9 wird bevorzugt in den meisten Browsern beim YT Player.

Und wenn du dann halt so eine Auflösung wie 1152p hast, bekommst du halt den Encode der für 1440p vorgesehen war, aber dein 1152p Video wird unter der Auswahl 1080p geführt.

Beispiel:

Du hast halt auf deinem Video, was du im Spoiler gepostet hast, halt noch kein VP9 Encode bekommen. Weil dann wäre dein Video in 1152p60 verfügbar und es würde auch in den "Statistiken für Computerfreaks" als VP9 aufgeführt.

Entweder dauert das bei dir noch, oder solltest mal das Video auf YT kurz bearbeiten (nix ändern) und gleich wieder speichern oder oder oder...

Wie und wodurch VP9 auf YT ausgelöst wird konkret wird leider noch spekuliert. Und YT wird da auch nix konkretes zu sagen. Also bleibt es vorläufig Spekulationen wie man VP9 bekommen kann. Da kann auch Abwarten und Tee trinken helfen. Denn ein VP9 Encode zu bekommen kann halt auch dauern. Zumal die Encodierung ganz schön viel Leistung zieht und ich mich generell immer wieder frage wo YT die her nimmt.

Ihr knallt hier mit Zahlen um euch und vergesst letztendlich das ein Video das mit Bitraten encodiert mittels CRF Verfahren, man NIE zu 100% sagen kann wie groß die Datei wird.

Zum einen ist es Abhängig von Auflösung und FPS und Farbraum, zum anderen spielen auch Detailgrade der Frames eine bedeutende Rolle.

Man kann z.B. ein Super Nintendo Tetris Game was in RGB aufgenommen wurde mit z.B. 320x240 und 60FPS gut und gerne mit xBRZ in 1440p60 YV12 mit CRF 23 bei einer Gesamtlänge von 25min gut und gerne mal bis auf 100MB runterbringen.

Warum? Weil das Spiel so dermaßen Inkomplexe Frames hat das man da soviel Bitrate sparen kann. Kaum Bewegung, der größte Teil des Bildes ist das HUD Gitter und ein kleines Feldchen mit ein paar Blöcken rutscht da runter und das nicht mal schnell.

Oder wir haben Spiele wie Far Cry Primal oder Uncharted 4 oder hat man nicht gesehen für ein Grafiknuttenspiel und das Encodierte Video würde bei gleicher Länge und gleichen Einstellungen wie beim Tetrisgame auf über 3GB kommen.

Und das ist einfach so. Es wird halt beim CRF nach Qualität encodiert.
Würde man nach Bitraten encodieren würden die meisten eh aufgeben, weil sie A) das Video nicht einschätzen können wieviel Bitrate notwendig wäre und B) die Qualität der Video wäre nie identisch. Eines würde vllt gut aussehen, weil inkomplexe Frames und das andere würde in ein Meer von Blöcken oder Geschmiere ausarten, weil zu wenig Bitrate.

CRF encodiert in die Videos in VBR und mittels eines Faktors wird die Bitrate entsprechend der Qualität verteilt. Das ist ein enormer Vorteil gerade für Let's Player die ohnehin schon unzufrieden meist sind mit ihren Videos und da immer mehr rausholen wollen. Und das geht momentan mit dem CRF Verfahren am besten.

Bei VP9 kann man sogar ein 2pass CRF Encode durchführen. Das ist richtig gut, dauert aber enorm lange. Eventuell wird das deshalb bei YT dauern und somit auch bessere Encodes mit sich führen.

Der TE soll erst mal sein Workflow beschreiben. Weil wenn ich schon lese das er da mit VLC oder WinFF encodieren möchte oder macht, dann ist sein Workflow eventuell schon verkehrt. Den sollte er halt erst einmal ausführlich schildern. Ansonsten seh ich jetzt nicht was wir da allgemein optimieren müssen.

Vllt. nimmt er mit Shadowplay auf, haut noch Ghosting rein irgendwo und Encodiert noch mal und das Ergebnis wäre zum einen ein trauriges erst mal und zum anderen würde die Datei ja anwachsen, weil da soviele Rauschelemte drin wären im Bild dank Shadowplay was dann als Detail gilt und die Datei daher schon so groß wird beim zweiten Encode.

Wenn man kleine Dateien haben will, entweder A) lossy aufnehmen ohne Bearbeitung und direkt hochladen oder B) Lossless aufnehmen und danach in Ruhe encodieren für eine optimale Dateigröße zum Upload.

Weil Lossy -> Lossy ist meist ein Punkt wo die Datei größer wird.

Denn um von einer Lossy-Quelle keine Qualität zu verlieren ist meist nur ein Lossless Encode danach angebracht.
Schlimmer wird es wenn man Lossy zu noch mehr Lossy encodiert. Dann ist die Qualität nämlich im Arsch.
Und Lossy in ein weniger Lossiges Verhältnis zu encodieren bringt einen auch nicht grad viel, da die Lossy-Quelle meist als decodiertes RAW Material dem Encoder vorliegt, damit dieser das RAW (was in dem Falle schon verlustbehaftet ist) in ein neues Verlustbehaftetes Verhältnis zu bringen. Ergebnis ist das es kaum Auffällt, aber es dennoch Verluste gibt. Würde man das immer weiter machen würde bald nix mehr vom Video übrig bleiben. Generationsverlust halt.

Frage ist wie wurde aufgenommen und wie verarbeitet und in was Encodiert und hochgeladen?

Zum anderen dein Video hat da nur 1080p60 und liegt nur in AVC vor. Noch nicht mal VP9.

Und 1080p ist nicht grad das Gelbe vom Ei. Mach lieber 1152p60, dann "wabbelt" das auch nicht mehr.

Weil dieses "wabbeln" entsteht durch eine recht magere Encodierungseinstellung seitens Youtube. Um höhere Encodierungsmodi von YT zu entlocken musst du höher skalieren. min. 1152p oder höher.

Dieses "wabbeln" ist noch recht harmlos bei dir, ist aber auch ein Zeichen dafür das die Bitrate nicht ausreicht und er genau bei Bewegungen nun die Farben etwas hinterher zieht. Weil da spart er nämlich schon Bitrate.

Um Bitrate zu sparen werden meist Farben verschmiert. Im Idealfall meist nur da wo Bewegungen auftauchen. Und im schlimmsten Fall bekommst du halt DCT-Blöcke zu Gesicht.

Das ist bei deinem Video hier noch nicht so stark ausgeprägt.

Man kann es natürlich mit einem Unschärferen Skalierer etwas entgegen wirken, ja. Aber dann lieber doch auf 1152p skalieren mit Spline36 und das Problem wäre für dieses Spiel schon gelöst. Und 1080 auf 1152 ist ja nun nicht die Welt.

Einmal deinen kompletten Workflow beschreiben, damit wir am richtigen Punkt optimieren können.

Am besten dazu aus diesem Thread -> Wie stelle ich meine Frage richtig? <- Punkt 1 bis 4 soweit beherzigen.

Wir können nur dann helfen, wenn wir wissen wie du halt vorgehst und deine Einstellungen jeweils sind. Von der Aufnahme bis hin zum finalen Encoding dessen Ergebnis du hochlädst.

Die Konsole überträgt über HDMI Video + Audio + die HDCP Verschlüsslung. Das Signal überträgst du an den HDMI Splitter der dann durch die Signalverstärkung, weil er das Signal ja aufspalten und verstärken muss, aufteilt. Diese Aufteilung lässt du jetzt am Fernseher überprüfen.
Einfach um Sicherzustellen ob:
a) Video ankommt (sollte es eigentlich, da deine Aufnahmesoftware das schon gezeigt hat)
b) Audio korrekt ankommt.

Und das überprüfst du am Fernseher.

Weil ist Audio schon am Fernseher via HDMI Splitter schon so abgehakt, müsste man eventuell die Konsole selbst via HDMI noch mal testen ohne HDMI Splitter. Einfach um den HDMI Splitter als Fehlerquelle auszuschließen.

Du musst halt schauen wo dein Audio auf dem Weg abhanden kommt und nicht korrekt übertragen wird.

Eventuell ist die Konsole auch nur falsch eingestellt und läuft nicht via PCM Audio. Kann auch sein. Müsste man dann schauen. Überprüfe es aber erst mal mit den Verbindungen wie gesagt.

Das kann generell bei jedem Spiel auftreten an jedem Rechner. Nur Spiele im Fenstermodus sind dieser Gefahr höher ausgesetzt, da sie im Fenstermodus nicht in der Lage sind effektiv VSync und somit auch Double Buffering zu nutzen (was nur im Vollbild geht).

Kurz: Die Gefahr ist einfach höher das es auftreten kann im Fenstermodus.

Das hat nix mit dem Verhältnis des Monitors zu tun.

Zitat von Zinthoraz

Ich persönlich möchte nämlich nicht was uploaden wo dann ein Drittel vom Bildschirm schwarze Balken ist/sind (?)

Hast du doch persönlich gar nicht. xD Ich glaube das ist das was nie verstanden wird. xD

Wenn du ein 21:9 Video hast und es auf YT lädst, dann hat das YT Video auch 21:9. Da du selbst ein 21:9 Monitor hast, wird das auf deinem Rechner, deinem Monitor ohne schwarze Balken angezeigt im Vollbild. Fakt.

Ein 16:9 User oder 4:3, oder was weiß ich der dann dein 21:9 Video auf YT anschaut, wird bei einer Vollbild-Umschaltung schwarze Balken haben. Einfach weil die Höhe oder Breite nicht mehr stimmt.

Der eingebettete YT Player den Google eingebunden hat da ist in 16:9 eingebettet. Den hätten sie auch in 4:3 oder 16:10 oder 21:9 einbetten können. Das ist vollkommen irrelevant wie das Ding eingebettet ist. Fakt ist das das Video kein 16:9 sein muss. Das ist ein Irrglaube.

Ihr lasst euch zu sehr von diesen eingebetteten Player irritieren.

Na du hast doch 2 HDMI Kabel, oder?

Eines von Konsole zum Splitter und eines vom Splitter zur Capture Card.

Das von der Capture Card ziehste raus und steckst es am Fernsehn an.

Und somit überprüfst du ob der Fehler nun an deiner Capture Card bzw. PC war oder ob er nun vom Splitter oder gar Konsole herrührt.

Nennt man Fehlersuche xD

Wie ist denn der Sound wenn du die Verbindung vom HDMI-Splitter zum Fernseher machst?

Bei 72p was du hochskalieren tust fällt das wie angesprochen so gut wie 0 auf.

Die Praxis belegt halt das es sich so verhält und die graue Theorie beweist es.

In der Praxis des Users wäre es jetzt egal bei einer Hochskalierung von gerademal 72p welchen Skalierer man verwendet. Weil das einfach so banal ist schon.
Bei einer größeren Skalierung jedoch willst selbst du keine Treppenbildung und vor allem keine Ringbildung haben. Weil das sieht nicht nur im Video scheiße aus, sondern verbraucht auch mehr Bitrate und du erreichst damit womöglich den Bitraten Cap den YT hat und die Gefahr das das Video dann noch zerlaufen tut bzw. Blöcke schmeißt ist somit größer. Dann hast du nicht nur ein Video was Ringbildung und Treppeneffekte aufweisen tut, sondern hast auch gleich gratis dazu ein gematschtes Video dank YT, weil womöglich der Bitraten Cap überzogen wurde.
Und wenn die Bitrate halt nicht reicht für die Frames, dann schmieren sie oder zeigen sich halt in Form von DCT Blöcken. Und wenn man die schon deutlich sehen kann, dann hat man nicht gut bearbeitet.

In der Theorie und Praxis der Technik ist es nicht egal welchen, sondern in der Theorie treten bei einem Skalierer wie mit Spline64 Ringe auf und auf auch Treppeneffekte schleichen sich ein. Und in der Praxis des Encoders sieht der Encoder sowas auch und vergibt natürlich mehr Bitrate darauf. Weshalb wir dir auch Spline36 oder Spline16 oder gar Spline100 empfehlen würden. Einfach um so Sparsam wie möglich mit der Bitrate umzugehen.

Weil was du in Lossy schon kodieren tust, kodiert YT ein zweites mal und um dafür halt zu sorgen das YT keinen großen Mist macht, führt man den lokalen Encode besser durch, damit der YT Encoder entsprechend auch besseres Material zur Verfügung hat und ein zweites Mal encodieren kann.

Ob du nun an den Bitraten Cap gelangst oder nicht, kannst du selbst nicht wissen und wir dir auch unmöglich sagen. Das hängt von den Frames ab und wie hoch der Detailgrad ist. Mit Detailgrad ist an sich der Frameaufbau gemeint.

Wenn du z.B. 60 FPS hast, hast du ja 60 Frames pro Sekunde. Bitrate wird mehr, wenn:
a) die 60 Frames eine Bewegung aufweisen
b) die Frames eine hohe Dichte an unterschiedlichen Pixelfarben nebeneinander haben (Sprich keine einheitlichen Flächenfarben)

Das sind die Hauptpunkte wonach sich Bitraten richten ob sie mehr oder weniger werden. Bei nem schwarzen Standbild ist die Bitrate unterirdisch klein. Keine Bewegung + eine einheitliche Flächenfarbe = Ideale Bitrate

Da man das aber bei einer Aufnahme eines Games nicht ersehen kann bzw. es recht schwer ist es einzuschätzen, kann man also nie pauschal sagen ob man den Bitraten Cap überschreitet oder nicht.

Für solche Analyse müsste man Hellseher sein und die Glaskugel befragen

Aber solche Spiele wie bei der ScummVM oder bei einem Jump & Run Game wo man die Figur von der Seite sieht, sind oftmals relativ Bitraten-Arm gestaltet. Es sei denn die Umgebung ist Kunterbunt und sehr Vegetationsreich.

Uncharted 4, Far Cry Primal, ja sogar Minecraft mit HD Texturen und sonstige Verschönerungs Mods etc. (Optifine) können und werden auch die Bitraten in die Höhe schießen lassen. Und da muss man halt dann vorsichtig sein und auf seine Bearbeitung etwas mehr achten, wenn man da sehr gute Ergebnisse auf YT haben möchte.

Wie sieht denn deine jetziger Verbindungsplan Konsole -> PC aus? Und wie ist deine Aufnahme Software konkret eingestellt?
Hast du deine Software schon irgendwo upgedatet?

Wirklich alles nennen und sagen wie du verfährst. Sonst ist das die Nadel im Heuhaufen.

21:9 wird in der Praxis an sich scheiße angewendet

Weil 2560x1080 ist an sich kein 21:9, sondern 64:27 (Einfach 4/3 mehr als 16:9)
Und 1680x720 ist an sich wieder eine 7:3 Auflösung und somit auch automatisch 21:9

Das sind beides Werte für 21:9 die Praxisbezogen angewandt werden.

Daher variieren diese 21:9 Monitore von den Auflösungen zwischen 64:27 und 7:3.

Weil 21:9 passt halt nur in bestimmten nativen Auflösungen und die sind recht Rar bzw. sehr wenig vergeben.

Hier eine Liste von nativen 21:9 Auflösungen:
630x270
840x360
1050x450
1470x630
1680x720
1890x810
2100x900
2310x990
2520x1080
2730x1170
usw...

Seltsam das bei 1080p beim 21:9 Monitoren lieber 64:27 angewandt wird. Aber ok.

Und bei 64:27 hat man folgende Auflösungen:
640x270
1280x540
1920x810
2560x1080
3200x1350

Das wird etwas zusammengemischt mit den nativen 21:9 Auflösungen und hat am Ende das typische 21:9 Format was in der Praxis angewandt wird.

Die Folgen:
21:9 ist etwas höher als 64:27. Kann man hier im Bild besser sehen: Bild

Zur eigentlichen Frage des TE.
Wenn man dieses 21:9 Format aufnehmen sollte, dann bitte bitte biiiitttttte nicht in ein 16:9 Format zerren. Wenn du dir das Bild anschaust was ich gepostet habe, dann werden alle Figuren und Inhalte in die Länge gezerrt und das sieht für das Auge und Allgemein nicht nur Unschön aus, sondern grenzt schon an eine Vergewaltigung als wenn jemand jetzt 16:9 <-> 16:10 umskaliert. Bei 16:9 <-> 16:10 hält sich das noch in Grenzen. Aber nicht bei 21:9 <-> 16:9. Das wird ne Katastrophe

Wie gesagt, 21:9 aufnehmen, 21:9 bearbeiten und 21:9 auch hochladen dann.

Dann hast du für dich mit deinem 21:9 Monitor wenn du das Video auf YT in Vollbild schaust keine Balken.
Und die 16:9 Heinis meckern ohnehin immer das sie das Scheiße finden, weil die haben dann Balken.
An sich keine Balken, weil wo nix ist, ist halt nix

Balken kann man bewusst rein machen in Form von Letterboxen zum Beispiel. Macht man in der Regel aber nicht.

Wenn du deine Aufnahmen weitesgehend in 16:9 aufnehmen möchtest, würde ich a) die Grafikkarte entsprechend darauf einstellen und b) nicht im Fenstermodus starten.

Denn im Fenstermodus Spiele zu spielen wo kaum was einwirken kann wie Double Buffering, kann das gut und gerne mal für Tearing sorgen in den Aufnahmen und dann hat man solche schönen Muster:

Und das sieht dann auch nicht toll aus

Die Entscheidung liegt also bei dir wie und was du nimmst.
Die 16:9 Leute werden sich eh dagegen entscheiden. Genauso wie sie 16:10 Auflösungen oder 4:3 Auflösungen vermeiden wollen, nur weil der eingebettete Player als 16:9 eingebettet ist. Im Vollbild interessiert das dem Player nicht mehr.

Und viele 16:9 User strechen halt Auflösungen wie 4:3, 5:4, 16:10 oder gar 21:9 knallhart auf 16:9, nur damit der eingebettete YT Player ausgefüllt ist. Und das ist an sich Fail. Macht man einfach nicht.

@De-M-oN Mach mal dein Tutorial neu.

Zitat von De-M-oN

kann natürlich sein das ichs mit der blend.avsi oder so verwechsel. ka mehr.^^

Bestimmt die Funktion SaveEveryPic

Die speichert in gewissen Frame Abständen ein Bild. Das wäre nicht Zufällig, sondern hat ein Muster. Die Funktion wäre in der Blend.avsi enthalten.

Zitat von De-M-oN

was ja im ersten Moment nicht all zu tragisch klingt. Aber wenn man jetzt zb nur 3 Bilder generieren lässt, werden es immer Frames aus dem Anfangsbereich des Videos sein und niemals aus der Mitte oder so.
So zumindest konnte ich das beobachten.

Jein. Also der arbeitet schon zufällig. Das Problem ist, da es kein Taktgeber gibt. Das heißt, wenn das Skript einmal durchläuft bekommt man immer den gleichen Start-Seed.

Das heißt auf klar Deutsch: Er nimmt schon Zufällig aus dem Video irgendwelche Frames. Wird das Skript noch mal geöffnet und abgespielt auf irgendeine Weise, sind es dann leider die gleichen zufälligen Frames, da gleicher Seed.

Wenn man das Skript mit VDub oder was weiß ich wieder zurückspult (Da wo die Bilder erzeugt werden (die ersten Frames des Skriptes)), dann verändert sich der Seed und du bekommst auch andere Frames gespeichert.

Das Problem ist also wirklich das der Start Taktgeber zur Initialisierung eines anderen Seeds fehlt.

Das hatte ich dir mal bei deiner Excel-Tabelle erklärt gehabt. Als Taktgeber haben wir in deinen Tabellen die Uhrzeit genommen gehabt, da diese sich bei jedem Neustart der Excel Tabelle entsprechend anders ist und somit jedesmal einen anderen Seed auswirft.

Und das geht halt bei AVISynth nicht. Ich kann bei AVISynth kein Zufallsgenerator aktivieren, so das er die Uhrzeit nimmt. Einfach auch weil AVISynth dafür gar nicht vorgesehen war

Der Seed kann lediglich nur durch das Spulen des Videos geändert werden.

Zitat von De-M-oN

Sprich du wirst nie das 1. bild aus dem ende des videos zb kriegen.

sprich kein 90005, 8004, 25200 etc
sondern immer 20, 5070, 20005, 50000 usw

Bei der Funktion des SSM wird ersteres passieren, das was du verneint hast.

Der Start-Seed richtet sich nach der Länge des Videos.
Sieht man auch im Skript entsprechend mit dieser Zeile:

clip1 = ScriptClip(Trim(clip0a, 0, picnumber - 1), "Trim(clip0a, Rand(clip0a.framecount), -1)")

Am Ende steht bei Rand (Randomize) die gesamte Clip Länge drin.

Der AVSPmod nutzt für seine Review irgendein besonderen Taktgeber, denn genau dort entstehen immer unterschiedliche Bilder bei jedem Neuladen des Skriptes.

Welches Windows System?

Zitat von Ancrion

Andere Frage: Wieso gibt es in VDUB 2 Play Tasten, eine mit einer 1 und eine mit einer 0?

Einmal für den Input Plane und einmal für den Output Plane.

Du selbst siehst aber nur den Input Plane. Der Output Plane wird via SSM automatisch abgeschaltet, damit nicht unnötig 2 Videos dargestellt werden müssen.

Beide Planes kannst du unter View -> Pane layout -> both plane aktivieren.

Und dann machen die 2 Tasten schon mehr Sinn. Einer für den Input Plane und einer für den Output Plane.

Wenn du die Maus mal auf die Tasten drüber hältst, bekommst du sogar eine Hilfe angezeigt.

Wenn das nicht mit MT läuft, dann musst du halt MT abschalten

Multithreading ist an sich sehr Unstabil bei einigen Filtern.

Kompromiss:
Speichere ein Skript wo das mit den Zufallsbildern aktiv ist und MT aus und cutte das Skript im SSM auf die Framelänge dessen Anzahl an Bildern du angegeben hast. Weil länger muss es nicht sein. Und dann aktivierst du die Vorschau über VirtualDub. Und dann gehst du in VirtualDub unter Video -> Scan video stream for errors ...
Damit fragt er nun das gesamte Video ab Frame für Frame, während das das Skript auch Frame für Frame arbeitet und somit nun die Zufallsbilder erstellt.

Und dann speicherst du ein Skript mit SSM wo das mit den Zufallsbildern deaktiviert ist und MT an. Und das kannst du dann für MeGUI nutzen.
Dann hängt er sich nicht daran auf.

Beides kannst du parallel nebeneinander machen.

An der Stelle wo Trim mit Mode 2 laufen soll erfolgt im Nachhinein die Erzeugung der Zufallsbilder. Und die Zufallsbilder werden unter anderem via einem Overlay Filter vertuscht. Und Overlay verträgt kein Mode 2.

Probiere es mit Mode 3 oder 4, dann sollte es laufen.