Frage zu Videogröße (anfänger)

Zitat von GelberDrache92

Weil bei einem Encoding die Sachen in einer Datei landen und diese müssen die gleichen Einstellungen haben.
Wenn ich zwei Videos mit verschiedenen Einstellungen haben möchte, dann müssen diese in zwei verschiedene Dateien.
Dementsprechend macht es keinen Sinn.

Das habt ihr doch schon längst gesagt. Ich wollte wissen warum sie die gleichen Einstellungen haben müssen. Was würde sonst passieren?
Und ich meine nicht dass man alle zwei Sekunden switched und dann natürlich Salat hat, sondern dass der Encodierer erstmal mit Einstellungen A arbeitet, und ab Frame X dann umstellt und den Rest mit Einstellungen B encodiert. Ich spreche auch nicht davon, wieviel Sinn es macht, ganz unabhängig davon ob das Ergebnis quatsch wäre geht es um die technische Machbarkeit.

Aber vielleicht würde es sogar Momente geben, wo das Sinn macht. Man kann in MeGUI sehr viele Fein-Einstellungen vornehmen und als ich damals Banding loswerden wollte, habe ich tiefsten Internet nach Informationen dazu gesucht und mit diversen Einstellungen gespielt.

Sagen wir, ein Video das aus 30 Minuten besteht hat in den ersten 15 Minuten Bereiche, für die Einstellung A optimal ist, aber dann wechselt das Spiel an einen total dunklen Ort wo vielleicht auch andere Elemente anders aussehen, so dass Einstellung B nun optimal wäre. Wäre der Encodierer in der Lage, mittendrin das Preset was man vorher festlegt zu ändern, könnte er das beste aus beiden Welten vereinen und das Video optimal zu dessen Eigenschaften encodieren.

Also...
1. In eine Datei kommen nur Video-/ Audiostreams mit der gleichen Einstellung.
2. Pro Job wird eine Datei angelegt.
Das heißt wenn man zwei verschieden Einstellungen haben möchte, muss man zwei verschiedene Dateien haben, also warum sollte der Encoder wärend eines Jobs die Einstellungen ändern, wenn man sowieso zwei Jobs braucht, damit zwei Dateien erzeugt werden?

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.

@Sagaras ich glaub beim x264 konnte man Videos nicht mal zusammen muxen, wenn diese nicht den gleichen CRF haben.

Zitat von GelberDrache92

ich glaub beim x264 konnte man Videos nicht mal zusammen muxen, wenn diese nicht den gleichen CRF haben.

Durchaus möglich. Weiß ich grad nicht.

Theoretisch kann man aber VBR Videos die ja unterschiedliche Bitraten halt haben zusammensetzen. Und an sich ist CRF ja nix anderes. Aber wie gesagt, sowas mache ich ja so gut wie nie das ich über MKVmerge jetzt Videos zusammensetze. Weil wenn ich Videos aufnehme, dann encodiere ich die so, das ich hinterher da nix zusammensetzen muss. Sondern Uploadfertig sind. Bzw. Anschaubereit sind ;D

Zitat von Sagaras

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.

Ok aber was ist, wenn ich zwei paar Schuhe in einen Rucksack packen will, weil ich weiß, dass ich auf dem Weg erst durch Matschpfützen laufen muss, danach aber zu Villa X komme wo ich für eine edle Party eingeladen bin und das andere paar Schuhe brauche?

Ich kann natürlich an guten Tagen die Schuhe nehmen und an regnerischen die Stiefel, aber wenn ich im Voraus wüsste, dass beides auf einer Strecke kommt, was dann?

Natürlich meinte ich nicht Dinge wie die Auflösung plötzlich zu halbieren oder andere Dinge die einem in's Auge fallen, und ich meinte auch nicht, ständig zwischen zwei Einstellungen zu hüpfen, sondern Einstellung B nur nach A kommen zu lassen, beide paar Schuhe in einen Rucksack. Trotzdem nacheinander und jedes Paar für sich. Und sagen wir, es ist ein einziger Encodingvorgang und nur ein Quellvideo. Also nicht zwei Videos, auch keine Kopie, sagen wir, ich will einfach nur ein Video ab der Hälfte anders encodiert haben ohne daraus zwei zu machen.

Ich kann aufgrund mangelnder Kenntnis jetzt kein konkretes Beispiel machen, aber um ein Szenario zu beschreiben wo sowas möglicherweise Sinn machen würde: Wenn man ein bisschen an den Einstellungen in MeGUI ändert, die kein gravierenden Unterschied machen, aber sich beispielweise in der Artefaktbildung in dunklen stellen äußern, und man rendert 2 Videos raus, gibt es darin keine Unterschiede außer Form und Masse der Artefakte.

Das heißt, würden diese beiden Videos in einer File ablaufen, mit Einstellung A und mit Einstellung B, würde optisch nichts unpassendes passieren.

Wenn das Spiel nun so läuft, dass man in einem 30 minütigen Video bei der Hälfte ungefähr von lichtstarken Räumlichkeiten mit vielen Details in detailarme düstere Katakomben gelangt, wären vielleicht andere Einstellungen für eine optimale Qualität besser. Weil die Einstellungen die da oben für ein super Bild gesorgt haben unten z.B. die Artefaktbildung begünstigen.

Ist es technisch machbar, einem Encoder vorher die Information mitzugeben, dass er ab Frame X umstellen und anders encodieren soll? Das sind ja keine schwerwiegenden Sachen wie ein Codec-Wechsel den du vorhin in Verbindung mit dem Videoplayer angesprochen hast. Das sind ja eher Einstellungen an den Farb- und Pixelverarbeitungen.

Zitat von Chron

Ok aber was ist, wenn ich zwei paar Schuhe in einen Rucksack packen will, weil ich weiß, dass ich auf dem Weg erst durch Matschpfützen laufen muss, danach aber zu Villa X komme wo ich für eine edle Party eingeladen bin und das andere paar Schuhe brauche?

Naja, dann hast du 2 Anforderungen und für je ein Szenario eine entsprechende Encodierung. Sprich immer ein Video pro Szenario.

Zitat von Chron

Ich kann natürlich an guten Tagen die Schuhe nehmen und an regnerischen die Stiefel, aber wenn ich im Voraus wüsste, dass beides auf einer Strecke kommt, was dann?

Das blöde ist ja das du das ja beim Video machen weißt. Ist wie als würde die Wettervorhersage immer funktionieren.

2 gleiche Schuhe, sprich 1 Paar sind immer ein Video. Sie sind aber immer identisch die du grad trägst.

Wenn du jetzt z.B. ein Video hast das mit WMV9 kodiert wurde in 1080p30 und das ist dein Intro, dann ist es jetzt mal ein unbequemer schwarzer rechter Stiefel.
Und dann hast du dein Mainvideo in h264 kodiert mit 1152p60. Das ist dann dein bequemer weißer linker Turnschuh.

Fällt dir was auf? Kannst nicht beide tragen.

Bzw. Praktisch schon, aber das wäre nicht normal, sondern Chaotisch.

Zitat von Chron

Natürlich meinte ich nicht Dinge wie die Auflösung plötzlich zu halbieren oder andere Dinge die einem in's Auge fallen, und ich meinte auch nicht, ständig zwischen zwei Einstellungen zu hüpfen, sondern Einstellung B nur nach A kommen zu lassen, beide paar Schuhe in einen Rucksack.

Und das geht praktisch nicht.

Du hast 2 Videos mit unterschiedlichen Charakteristika. Stiefel und Turnschuh die du als Paar bezeichnest.

Geht einfach nicht.

Du hast bei Regen Szenario A) mit der WMV9 Datei z.B. und du hast Sonne bei Szenario B) mit der h264 Datei.
Das kann auch der gleiche Codec sein, nur unterschiedlich eingestellt und schon stimmt das Szenario nicht mehr.

Du musst sie vorher angleichen. Und das geht nur indem du zuerst dekodierst und dekomprimierst, dann aufeinander abstimmen tust und dann erneut encodierst.

Sprich du machst aus dem rechten Stiefel ein Turnschuh und der hat dann die gleichen Charakteristika wie der linke Turnschuh. Und dann passen sie auch für das Szenario B.

Du kannst nicht einfach mal ohne irgendeine Art der Neuberechnung einfach zwei verschiedene Videos zusammensetzen. Das geht einfach nicht.

MKVmerge kopiert nur, genauso wie es MyMP4box tut und alle anderen Muxer.

Zitat von Chron

Das heißt, würden diese beiden Videos in einer File ablaufen, mit Einstellung A und mit Einstellung B, würde optisch nichts unpassendes passieren.

Und du glaubst wirklich das der Decoder einfach so zwischendurch mal die Decodierungsroutine im laufenden Prozess ändert, ja?

Das wäre cool. Dann hast du als einziger eine Verschlüsslungs und Komprimierungstechnik erfunden die mehrere Einstellungen während der Decodierungsphase berücksichtigt. Genial xD

Sollteste dann Patent anlegen bei der Telekommunikationstechnik

Du stellst dir das womöglich etwas blöd vor.

Pass auf: Du hast angenommen 2 Videos die mit dem gleichen Codec encodiert worden sind. ABER mit 2 unterschiedlichen Einstellungen. z.B. andere GOP Länge oder das eine arbeitet mit 3 B-Frames, der andere mit 4.

Und jetzt stell dir vor das der Decoder diese Informationen braucht um das Video zu dekodieren.

Er fängt also mit Schlüssel 1 an zu dekodieren bis er zum Video kommen würde das nicht mehr den Einstellungen von Video 1 entspricht. Was glaubst du würde er bei Video 2 machen?

Den Schlüssel für Video 2 nutzen? Woher denn? Er weiß doch gar nicht das da Video 2 anfängt. Für den Decoder ist das dann immer noch Video 1 und schmeißt dir eine Fehlermeldung an den Kopf, weil er das nicht versteht.

Ist ne ganz simple Sache.

Um ein Video zu dekodieren, gibt es den Header. Ein Stream hat einen Header jeweils.

Bedeutet dein Video besteht immer aus ein Stream und einen Header. Im Header steht der Schlüssel zum dekodieren des Videos. Würde der nicht drin stehen, wäre es ein unbekanntes RAW Video das nicht dekodiert werden kann.

Und jetzt willst du 2 Streams zusammensetzen mit 2 unterschiedlichen Einstellungen.

Sagen wir jetzt mal das die 2 Streams unterschiedlich sind, sich aber dennoch zusammensetzen lassen würden. Du hättest ein Stream. Und was machst du mit dem Header? Da kann jeweils nur ein Schlüssel für den Decoder drin stehen. Einer würde auch nur von den beiden rein gehen.

Bedeutet im Endeffekt das du das andere Video nicht dekodieren könntest und es Fehlermeldungen geben würde. Eventuell sogar ein Bluescreen, weil der Decoder auf einmal auf Speicher zugreift den er gar nicht abfragen durfte. Einfach weil der Informationsfluss sich geändert hat.

Das Problem mit Metaphern ist meist, dass es irgendwann "paralympische" Dimensionen annimmt und man wetteifert, welche denn nun am Stärksten hinkt.

Zitat von Chron

Ist es technisch machbar, einem Encoder vorher die Information mitzugeben, dass er ab Frame X umstellen und anders encodieren soll? Das sind ja keine schwerwiegenden Sachen wie ein Codec-Wechsel den du vorhin in Verbindung mit dem Videoplayer angesprochen hast. Das sind ja eher Einstellungen an den Farb- und Pixelverarbeitungen.

Ja, etwas ähnliches ist auch bereits mit den Zonen in x.264 umgesetzt. Damit kannst du in von Frame X bis Frame Y Einstellungen überschreiben - nicht alle, aber in gewissem Rahmen. Vielleicht ist das ja ausreichend für dich. Details zur Verwendung findest du auf Encodingwissen und der x.264-Referenz. In MeGUI müsste auch eine rudimentäre GUI dafür integriert sein. Genauere Informationen zu dem Thema habe ich nicht - ich hab bei mir bisher kaum Bedarf dafür gesehen.

Zitat von Chron

Wenn das bei zwei identischen Videos geht, weil der Encoder mit den gleichen Einstellungen arbeiten kann, scheitert es bei zwei unidentischen doch nur an einer Umstellung mittendrin?

Jein ... wie @Sagaras bereits gesagt hat, kopiert dir MKVMerge den Stream nur an den anderen Stream ran - ein Encoder ist da nicht involviert. Wenn du das mit unterschiedlichen Einstellungen oder Codecs versuchst und das Programm da nicht die Grätsche macht, dann kann es sein, dass der Stream starke Bildfehler zeigt oder schlicht gar nicht abgespielt werden will. Du hättest dann einen Teil deines Gummistiefels und einen Teil deiner Sandalen, die du zusammenfügen willst.

Wenn dir die Erklärung nicht genügt, dann müssten wir etwas stärker ins Detail gehen, wie die Kompressionsverfahren arbeiten und wie / was gespeichert wird. Um's

Die Funktionalität, dass unterschiedliche Videos nacheinander abgespielt werden, müsste in den Spezifikationen von Matroska integriert sein, und von den Muxern, Splittern / Demuxern und evtl. Decodern umgesetzt werden. Ist es aber nicht. Matroska unterstützt zwar, wenn ich mich richtig erinnere, mehrere Videostreams, die auch unterschiedlich kodiert sein können, allerdings nur als separater Track - ähnlich wie die Sprachen auf einer DVD. Nacheinander abspielen wird wohl nicht Teil der Spezifikation sein.

Zitat von GelberDrache92

@Sagaras ich glaub beim x264 konnte man Videos nicht mal zusammen muxen, wenn diese nicht den gleichen CRF haben.

Sollte so sein, ja.

Kannst ja auch keine MP3s zusammenfügen, wo eine VBR -V2 ist und die andere VBR -V0

Auch die encodingparameter müssen halt identisch sein.

Zitat von Chron

Ok aber was ist, wenn ich zwei paar Schuhe in einen Rucksack packen will, weil ich weiß, dass ich auf dem Weg erst durch Matschpfützen laufen muss, danach aber zu Villa X komme wo ich für eine edle Party eingeladen bin und das andere paar Schuhe brauche?

Naja der Encoder hat verschiedene Kompressionsmechanismen und je nach Situation wird halt der gerad am besten passende gewählt. Je nach Preset wird länger oder weniger lange nach gute Kompressionsansätze gesucht.

Zitat von RealLiVe

Matroska unterstützt zwar, wenn ich mich richtig erinnere, mehrere Videostreams, die auch unterschiedlich kodiert sein können, allerdings nur als separater Track - ähnlich wie die Sprachen auf einer DVD. Nacheinander abspielen wird wohl nicht Teil der Spezifikation sein.

Ist ja auch logisch. Jeder Stream hat einen Header. Im Falle das sie in einem Container drin sind hat halt jeder Track (Stream) einen Header. Und der Container selbst besitzt auch einen Header, der die Informationen der einzelnen verwaltet. Das kann man auch gerne in einem Hexeditor nachvollziehen.

Zitat von RealLiVe

Die Funktionalität, dass unterschiedliche Videos nacheinander abgespielt werden, müsste in den Spezifikationen von Matroska integriert sein, und von den Muxern, Splittern / Demuxern und evtl. Decodern umgesetzt werden.

@Chron Was es halt praktisch nicht ist. Das "müsste" unterstreiche an der Stelle mal.

Zitat von RealLiVe

Ja, etwas ähnliches ist auch bereits mit den Zonen in x.264 umgesetzt. Damit kannst du in von Frame X bis Frame Y Einstellungen überschreiben - nicht alle, aber in gewissem Rahmen. Vielleicht ist das ja ausreichend für dich. Details zur Verwendung findest du auf Encodingwissen und der x.264-Referenz. In MeGUI müsste auch eine rudimentäre GUI dafür integriert sein. Genauere Informationen zu dem Thema habe ich nicht - ich hab bei mir bisher kaum Bedarf dafür gesehen.

Das ist mal die Hilfsreferenz aus der x264 zum Befehl zones

--zones <zone0>/<zone1>/...  Tweak the bitrate of regions of the video
                              Each zone is of the form
                                  <start frame>,<end frame>,<option>
                                  where <option> is either
                                      q=<integer> (force QP)
                                  or  b=<float> (bitrate multiplier)

Erklärung von Encodingwissen:
http://encodingwissen.de/codecs/x264/referenz/#zonen

Einfache Erklärung von mir:
Die Art wie Encodiert wird während eines Prozesses kann beeinflusst werden. Das ist wie als wenn man in ner Fabrik eine Sonderanfertigung machen lässt, es aber immer noch die gleiche Sorte ist.

Sprich der Standard Turnschuh wurde jetzt um eine Einlegsole und eine warme Fütterung verbessert. Die Randdaten müssen aber immer der Norm entsprechen.

@RealLiVe Das was x264 mit zones macht, könntest du auch mit MKVmerge machen. Sprich Video 1 ist komplett mit nach ein Muster encodiert worden, Video 2 wird ebenfalls nach diesem Muster kodiert, bekommt aber als Extra Randdaten (zones Einstellung) mitgeliefert.

Jetzt könntest du diese 2 Videos aber immer noch mit MKVmerge zusammen setzen.

Schau mal was es damals unter XVID gab: http://www.divx-digest.com/articles/xvid_setup_page3.html
Da gab es ebenfalls solche Zones. Das ist nix neues, sondern ein alter Hut an sich.

Zitat von HOOL

Danke für all die Antworten erst mal!

Also mein Workflow;

1. Aufnehmen tu ich mit OBS und Audacity (Video und Ausdio getrennt)

2. Nach dem aufnehmen, matche ich Video und Audio im kompletten in Premiere und Rendere in H264 und dem Vorgabenprofil "YouTube 1080p HD"

3. Danach starte ich ein neues Premiere-Projekt und lade die Folgen einzeln rein, ergänze das ganze mit Intro und Endcard und rendere nochmal mit den obigen einstellungen.

4. Danach lade ich es hoch.

OBS Einstellungen: http://imgur.com/a/2Zlnz

Alles anzeigen

Um auf deine Frage zurück zukehren da hier alle nun mit anderen reden beantworte ich mal dein frage bzw habe ein paar Fragen dazu.

Schritt 2-3 wieso nicht zusammen gibt es da ein Grund ?

Schritt 2: Vorgegeben Einstellung bei Adobe ?
Also hsst du diese nur angeklickt und nicht manuell eingestellt ?

Mal dran gedacht mit Megui zu arbeiten ?

Ebenso solltest du deine OBS Einstellungen sehr schnell ändern wenn du bisschen mehr Qulität haben möchtest.

Abgesehen davon das du glaub mit 1500mbit aufnimmst und dein Video am Ende 3GB groß ist stimmt ja irgendwas nicht. Eigentlich ist die Rohdatei immer größer als die geränderte.

Zitat von Sagaras

Du kannst nicht einfach mal ohne irgendeine Art der Neuberechnung einfach zwei verschiedene Videos zusammensetzen. Das geht einfach nicht.

MKVmerge kopiert nur, genauso wie es MyMP4box tut und alle anderen Muxer.

Dass es nicht geht kam schon lange an, ich bin immernoch auf der Suche nach dem Verständnis dafür warum :p Und die Ausgangssituation sollte die sein, dass ein Video in zwei unterschiedlichen Einstellungen encodiert wird, kein zusammenmuxen zweier bereits fertigen Videodateien.

Zitat von Sagaras

Das wäre cool. Dann hast du als einziger eine Verschlüsslungs und Komprimierungstechnik erfunden die mehrere Einstellungen während der Decodierungsphase berücksichtigt. Genial xD

Jetzt kommen wir der Sache näher

Zitat von Sagaras

Und jetzt stell dir vor das der Decoder diese Informationen braucht um das Video zu dekodieren.

Er fängt also mit Schlüssel 1 an zu dekodieren bis er zum Video kommen würde das nicht mehr den Einstellungen von Video 1 entspricht. Was glaubst du würde er bei Video 2 machen?

Den Schlüssel für Video 2 nutzen? Woher denn? Er weiß doch gar nicht das da Video 2 anfängt. Für den Decoder ist das dann immer noch Video 1 und schmeißt dir eine Fehlermeldung an den Kopf, weil er das nicht versteht.

Wieso weiß er nicht, dass Video 2 anfängt? Wenn ich beide Videos nacheinander abspiele, kriegt er die ja auch ohne Probleme abgespielt.
Warum bekommt er es nicht hin, die gleichen Informationen die er aus jedem Video einzeln zieht aus einem einzigen Video zu ziehen, wenn sie alle dort drin enthalten wären?

Zitat von Sagaras

Du hättest ein Stream. Und was machst du mit dem Header? Da kann jeweils nur ein Schlüssel für den Decoder drin stehen. Einer würde auch nur von den beiden rein gehen.

Das heißt also, es scheitert daran, dass im Encode immer nur ein Header festgelegt wird, und der Dekoder keine Abspielinformationen über das zweite Video abrufen könnte? Dann scheitert es also nicht an der technischen Machbarkeit, sondern daran, dass weder Encoder noch Decoder dafür programmiert sind, soetwas zu berücksichtigen?

Ich wollte einfach nur verstehen wo im technischen Detail die Hürde kommt, die es nicht möglich macht, dass ein Encoder beim verarbeiten des Videos zwei Schlüssel einbaut und es einen Dekoder gibt, der beide auslesen kann.

Im prinzip passiert ja das Gleiche, wenn man wie du bereits sagtest eine Playlist anlegt und der Dekoder zwei Videos nacheinander abspielt. Die Frage ist, warum das (technisch) nicht gleich von vorneherein geht.

Zitat von Chron

Dann scheitert es also nicht an der technischen Machbarkeit, sondern daran, dass weder Encoder noch Decoder dafür programmiert sind, soetwas zu berücksichtigen?

Es scheitert wirklich an der technischen Machbarkeit. Um das zu verstehen musst du dich mal mit der reinen Verschlüsslung von Informationen beschäftigen.

Die Enigma kennst du, oder? Die aus dem 2ten Weltkrieg?

Die anzahl der Walzen und Position sind die Einstellungen mit dem eine Textnachricht encodiert wird.
Um sie dann später zu dekodieren muss das gleiche passieren. Sprich der das Video bekommt muss auch wissen wieviel Walzen und auf welche Position sie eingestellt waren um die Nachricht wieder lesbar zu machen.

Stell dir vor der Encrypter würde jetzt mitten in der Nachricht irgendwo auf einmal eine Walze entfernen oder eine andere Walzenposition verwenden. Die Anzahl des Verschlüsselten Textes bleibt aber dadurch gleich. Die Codierung hat sich nur geändert.

Was meinst du was passiert wenn der Decrypter, sprich der der die Nachricht bekommt damit machen soll?

Im Krieg jetzt den Schlüssel mitzuliefern wäre ne Sau Dumme Idee Also wird der Decrypter die Nachricht wie üblich entschlüsseln. Und was hat er dann?
Genau. Eine Textpassage der Nachricht konnte decodiert werden, die andere wo eine Walze entfernt oder eine andere Walzenposition eingestellt wurde ist reiner Kauderwelsch. Sprich immer noch verschlüsselt.

Das ist jetzt eine vereinfachte Darstellung schon.
Bei der Codierung von Frames wird es verrückter.

Was ich damit sagen will ist eigentlich ganz einfach: Der Rechner weiß bei einer Decodierung von zwei unterschiedlichen verwendeten Encodierungseinstellungen wie bei der Enigma z.B. nicht wann es Informationen sind die für uns Unbrauchbar sind. Sondern würde irgendwelche kuriosen Falschinformationen erzeugen. Einfach weil der Decoder nicht weiß ab wann die Decodierung zuende ist.

Also würde er munter mit einem Schlüssel durchdekodieren, weil er es mit den einen Schlüssel umformen kann.

Die Frage nun von mir: Warum will man 2 oder mehrmals in einem Video anders Encodieren? Das ist Unlogisch.

Man kann wie bei einigen Codecs über sogenannte Zonen Bereiche im Videostream selbst etwas anders codieren lassen. Aber immer im Rahmen der globalen Einstellung. Denn die globale Einstellung ist sozusagen der Master Key für das Video.
Sprich alles was mit Bitrate oder der GOP zu tun hat, lässt sich noch im kleinen Rahmen beeinflussen über die Zonen. Das ist aber bei einem Qualitätsencode wie CRF total banal und bringt einen nix. Das wäre besser in Schnittprogrammen aufgehoben die den Mainconcept Encoder anbieten. Machen die nur nicht.

Wir können, wenn du Zeit haben solltest, das Ganze noch mal etwas genauer anschauen und ich kann dir dann auch zeigen was ein Video ohne Header macht.
Es scheitert wie gesagt an der technischen Machbarkeit. Es scheitert schon daran das du nicht weißt wie das Ganze System arbeitet
Das kann ich dir gerne erklären und auch zeigen, bzw. vorführen. Aber das ganze Zusammenspiel musst du mal betrachten.

Zitat von Sagaras

Was meinst du was passiert wenn der Decrypter, sprich der der die Nachricht bekommt damit machen soll?

Im Krieg jetzt den Schlüssel mitzuliefern wäre ne Sau Dumme Idee Also wird der Decrypter die Nachricht wie üblich entschlüsseln. Und was hat er dann?
Genau. Eine Textpassage der Nachricht konnte decodiert werden, die andere wo eine Walze entfernt oder eine andere Walzenposition eingestellt wurde ist reiner Kauderwelsch. Sprich immer noch verschlüsselt.

Kann ich vollkommen nachvollziehen und ich kenne die Enigma auch. Nur ist jetzt ja so, dass man sich weder im Krieg befindet, noch Programme so unflexibel sind wie die Enigma zur technischen Machbarkeit im WW2.

Natürlich müsste im encrypt eine Information enthalten sein, die einer high-tech Enigma erlaubt, sobald sie diese liest, bestimmte Walzen und Positionen auszutauschen, um den folgenden Text der reinkommt weiterhin korrekt decrypten zu können. Sowas müsste doch programmierbar sein. Dass aktuelle En- und Decoder sowas nicht können mag ja sein, aber technisch nicht machbar hieße für mich, dass sich zwei so zusammenarbeitende Programme auch nicht entwickeln ließen, weil es im Encodingprozess technisch in dem Verfahren eine Hürde gibt, dich derzeit nicht bewältbar ist, wenn es darum geht, mittendrin die Paraemeter zu verändern, und einen maßgeschneiderten Decoder zu haben, der diesen Wechsel auslesen und sich entsprechend anpassen kann.

Zitat von Sagaras

Man kann wie bei einigen Codecs über sogenannte Zonen Bereiche im Videostream selbst etwas anders codieren lassen. Aber immer im Rahmen der globalen Einstellung. Denn die globale Einstellung ist sozusagen der Master Key für das Video.
Sprich alles was mit Bitrate oder der GOP zu tun hat, lässt sich noch im kleinen Rahmen beeinflussen über die Zonen.

Als ich damals über Banding recherchiert habe stieß ich auf Foren wo auch mit den Psy-RD Einstellungen rumgespielt wurde.
Ich hab damit keine deutlichen Änderungen bzw. Verbesserungen herbeiführen können, aber solche Einstellungen wären es,
wenn sie wirken würden, die vielleicht mittendrin Sinn machen würden. Zu deiner Frage, wann es das tun würde, wie z.B. bei meinem Beispiel wo der Spieler in einem 30 minütigen Video nach 15 Minuten von einem sehr hellen Lichtintensiven und detailverliebten Raum in sehr düstere, detailarme Katakomben gelangt. Nicht dass das in der Praxis jetzt den Unterschied machen würde, aber es geht nur im die Theorie, wenn es so wäre.

Zitat von Chron

Zu deiner Frage, wann es das tun würde, wie z.B. bei meinem Beispiel wo der Spieler in einem 30 minütigen Video nach 15 Minuten von einem sehr hellen Lichtintensiven und detailverliebten Raum in sehr düstere, detailarme Katakomben gelangt. Nicht dass das in der Praxis jetzt den Unterschied machen würde, aber es geht nur im die Theorie, wenn es so wäre.

A) CRF arbeitet schon mit einer perfekten Verteilung der Bitrate. Detailierte Sachen bekommen mehr Bitrate, detailarme Sachen bekommen weniger. Daher ist das Arbeiten mit Zonen schon total unnötig und wäre eher bei festen Bitraten Angaben angebracht.
B) Die Zonen sind als einzige, Einstellungen annehmen die unter den globalen Einstellungen laufen. Und das sind nicht grad viele Einstellungen und macht gerade bei CRF auch recht wenig Sinn.

Zitat von Chron

Kann ich vollkommen nachvollziehen und ich kenne die Enigma auch. Nur ist jetzt ja so, dass man sich weder im Krieg befindet, noch Programme so unflexibel sind wie die Enigma zur technischen Machbarkeit im WW2.

Natürlich müsste im encrypt eine Information enthalten sein, die einer high-tech Enigma erlaubt, sobald sie diese liest, bestimmte Walzen und Positionen auszutauschen, um den folgenden Text der reinkommt weiterhin korrekt decrypten zu können. Sowas müsste doch programmierbar sein. Dass aktuelle En- und Decoder sowas nicht können mag ja sein, aber technisch nicht machbar hieße für mich, dass sich zwei so zusammenarbeitende Programme auch nicht entwickeln ließen, weil es im Encodingprozess technisch in dem Verfahren eine Hürde gibt, dich derzeit nicht bewältbar ist, wenn es darum geht, mittendrin die Paraemeter zu verändern, und einen maßgeschneiderten Decoder zu haben, der diesen Wechsel auslesen und sich entsprechend anpassen kann.

Das mit der Enigma war ein sehr sehr sehr vereinfachtes Beispiel. In der Videotechnik kannst du nicht einfach mal so mittendrin die Einstellungen von einem Video verändern. Geht einfach nicht.

Und es würde nicht mal in der Theorie machbar sein. Das mag vllt. beim Enigma Beispiel noch klappen mit den Walzen etc. Aber bei den heutigen Codecs für Video oder Audio geht das einfach nicht. Und es wäre auch Schwachsennig sowas zu haben.

Das ist wie als würdest du eine SSDHDD haben xD Ja, mit was arbeitet sie denn nun? Mit Halbleiter oder mit magnetischen Platten? xD Das funktioniert nicht. Beide haben doch ganz andere Charakteristika.

Du kannst sie womöglich noch als eine Festplatte auf dem Rechner laufen lassen. Das ist dann bei nem Video aber auch nur so als würdest du 2 Videos in eine Playliste stecken. Sie arbeiten dennoch seperat.

Vllt. ist es wirklich besser dies über Team Speak zu besprechen, als das wie den Thread hier unnötig weiter in die Länge ziehen

Die Zoneneinstellung hat hauptsächlich bei xvid Sinn gemacht. Da konnte man bei einem Film bei Abspann etc sehr niedrige Bitrate erzwingen, so das man mehr Luft für die komplexen Parts hat. 2pass hatte xvid zwar auch schon, aber konnte so noch weiter optimiert werden.

Bei xvid's Effizienz und niedrigen Bitraten war das zum Teil sinnvoll. Es war halt nur xvid und nicht x264. x264 braucht diese Nachhilfe nicht wirklich.