überlappende Segmente?

Begonnen von VGER, September 20, 2020, 16:51:39

« vorheriges - nächstes »

VGER

Hallo,

ich habe eben das Upgrade von v2 auf v3 vorgenommen. Die erste große Enttäuschung war war, daß es immer noch nicht möglich ist, beim Schnitt überlappende Segmente zu definieren.

Könnte man das nicht wenigstens jetzt in der neuen Version einbauen? Wir reden doch schon lange diesbezüglich hin und her. Der Aufwand sollte doch wirklich nicht groß sein.

MfG

xa89

Schneiden in einem Rutsch funktioniert ja nicht bei überlappenden Schnittbereichen, nur beim Batchlauf.
Vor der Batchverbeitung kann man aber die Schnittpunkte editieren in der Batchdatei und das Ende der Datei nach vorne versetzen, z.B um 20 Sekunden. So mache ich es manchmal.
Es müsste diese Möglichkeit geben auch im Dialog vor dem Hinzufügen zur Batchverarbeitung.
Wegen der Unschärferelation von Sein und Nichtsein haben wir unsere Gegenwart (das Jetzt).

Cypheros

#2
Wir versuchen natürlich Kundenwünsche bei der Weiterentwicklung so gut es geht zu berücksichtigen aber der notwendige Aufwand muss in angemessenem Verhältnis zur Anzahl der Anwender stehen, die ein solches Feature benötigen.

Der TS-Doctor besteht aus mehr als 150000 Programmzeilen und das gewünschte Feature würde einen überraschend hohen Aufwand bedeuten, da bei der Verarbeitung Timer, Zähler, Checksummen, Daten-Caches mitlaufen, die wieder zurückgesetzt und passend initialisiert werden müssten. Dabei müssen auch Problemfälle wie Timer-Sprünge, Formatänderungen und Fehlerstellen berücksichtigt werden.

Also bitte nicht böse, sein, wenn wir nicht alle Wünsche erfüllen können.

VGER

#3
@xa89 : Ich editiere Dutzende von Dateien in einem Rutsch. Ich kann nicht für jede davon manuell in Script-Dateien herumeditieren. Das ist einfach nicht praktikabel.

@Cypheros : Wenn Du sagst, daß der technische Aufwand zu hoch wäre, dann glaube ich das. Aber Hand auf's Herz: Ist das wirklich so? Alles, was passieren müsste ist, daß das "Segment", für das man in der Schnittliste gerade Anfang und Ende definiert, nicht automatisch wechselt. Wenn ich gerade Segment Nummer x ausgewählt habe, dann sollte das Kommando "set start" oder "set end" für dieses Segment x gelten, und nicht für irgendein anderes x+1 oder x-1, egal, wohin ich in der Datei scrolle. Ist das ehrlich so schwierig?

Momentan muß ich eine Quelldatei zweimal laden, zweimal scannen lassen, zweimal "schneiden" und zweimal exportieren. Das funktioniert - aber ist das denn wirklich notwendig?

MfG

xa89

#4
Zitat:
Alles, was passieren müsste ist, daß das "Segment", für das man in der Schnittliste gerade Anfang und Ende definiert, nicht automatisch wechselt.
Leider genügt dies nicht beim Schneiden in einem Rutsch.

Im unteren Beispiel wird die zweite Datei nicht eine Stunde lang sein sondern nur 55 Minuten (obwohl die beiden Schnittbereiche überlappend sind).
Der TS Doctor springt beim Schneiden nicht zurück in der Aufnahme. 

Wegen der Unschärferelation von Sein und Nichtsein haben wir unsere Gegenwart (das Jetzt).

VGER

#5
Zitat von: xa89 am September 21, 2020, 20:47:05Der TS Doctor springt beim Schneiden nicht zurück in der Aufnahme.
Ok, verstehe.

Dann müsste TSD doch ungefähr so funktionieren:


while (not InputFile.eof)
  InputFile.ReadNextFrameSet
  if (CurrentSegment.IsInRange(InputFile.Position))
    OutputFile.Add(CurrentFrameSet)
  fi
wend


Ginge dann aber nicht auch folgendes:


while (not InputFile.eof)
  InputFile.ReadNextFrameSet
  forEach(Segment in AllSegments)
    if (Segment.IsInRange(InputFile.Position))
      Segment.OutputFile.Add(CurrentFrameSet)
    fi
  ;
wend


... oder passt das gar nicht in die momentane Architektur?

MfG

Cypheros

Nein, das ist schon etwas komplizierter.
Es handelt sich um einen gemultiplexten Transportstrom, bei dem Bild und Ton in Pakete zerlegt sind (Elementary Stream), die dann nochmals in kleinere Pakete mit je 188 Byte zerlegt sind (Transport Stream). Erschwerend kommt hinzu, dass die Frames beim Video nicht in chronologischer Reihenfolge im PES zu finden und Bild und Ton zeitlich versetzt sind (Delay). Dies muss beim Schnitt berücksichtigt werden, damit an den Schnittstellen nicht hässliche Bild- und Ton-Störungen erscheinen.

Von Tektronix gibt es ein PDF, dass eine gute Übersicht über den Aufbau eines MPEG-2 Transport-Streams gibt: https://download.tek.com/document/2AW_14974_4-Poster.pdf

Ansonsten wird der Standard in ISO/IEC 13818-1 beschrieben.

VGER

Ich will Euch jetzt wirklich nicht künstlich auf die Nerven gehen, aber verstanden habe ich es noch nicht:

Die ganze Stream-Dekodiererei muß doch erledigt werden, egal ob das Ergebnis in eine oder in mehrere Output-Dateien geschrieben werden soll. Und jeder "Writer" für jede Output-Datei kann doch autonom exakt das gleiche machen, jeweils für seine Datei - der Writer für Output-A ist doch unabhängig von Output-B.

Warum ist dann zwischen "einer" und "mehrere" ein solch großer Unterschied?

MfG

Mam

Obwohl mit die gewünschte Option sehr sinnlos vorkommt (ich verstehe einfach nicht, wofür man sie überhaupt gebrauchen können sollte), kann ich mich der Logik in der Argumentation nicht verschließen.

Wenn Du schon in einer Schleife die Pakete der selektierten Bereiche brav nacheinander in die Zieldatei schreibst, ist es wirklich kein großer Aufwand um nachzugucken, ob sie auch in einem anderen Bereich liegen und noch woanders ebenfalls mit rausgeschrieben werden müssen.

Allerdings erfordert das zwingend eine Trennung der verschiedenen Ausgabestreams. Wenn Du natürlich nur Datei1 öffnest für den ersten Teil, alle Pakete rauschreibst und dann die Datei1 schliest (um danach Datei2 zu öffnen, zu kopieren... usw. usw.), dann geht es nicht. Das würde dann größere Umbauten erfordern.

Aber grundsätzlich könnte man alle Zieldateien also Objekte am Anfang direkt öffnen, dann in einer Schleife die Eingabedatei durchschnecken und wenn die Leseposition innerhalt eines angewählten Bereiches liegt, dieses Paket rausschreiben. Und ganz am Ende alle Dateien zumachen.

(allerdings wird dann auch die Ausnahmebearbeitung (z.B. "Disk full" oder "Read Error") deutlich komplizierter.



xa89

Das eigentliche Problem ist, dass nach dem Schnitt oft Bilder am Ende des Filmes fehlen.
Deshalb wird das Ende des Filmes ein paar Sekunden später gesetzt.
Das geht aber nicht wenn das schon der Anfang des nächsten Filmes ist und man diesen auch sofort haben möchte in einem Rutsch.
Wegen der Unschärferelation von Sein und Nichtsein haben wir unsere Gegenwart (das Jetzt).

Mam

Also bei den minutenlangen Abspännen mit endlosem Gelaber und "Danke schön" fehlen mir die paar Sekunden nicht. Wenn überhaupt was fehlt, normalerweise kommt dann ja ersmal ein kurzer Werbe/Vorschaublock.

Ich bin allerdings gnädig und lasse auch die Synchronsprecher drin, sofern vorhanden.

Cypheros

Wie gesagt ist das ganze nicht einfach Paket einlesen, schauen ob es im Schnittbereich liegt und dann rausschreiben. Dadurch das soviele Dinge zu berücksichtigen sind, wird es so aufwendig, das ich da sehr viele Arbeitsstunden investieren müsste und Gefahr laufen würde, dass die bisherige Verarbeitung leiden könnte. Das alles um 2 bis 3 Anwender glücklich zu machen?

Allein die Dekodierung der DVB- und Teletext-Untertitel in SRT-Dateien sind schon schwierig synchron zu halten, mit dem Anfang der jeweiigen Ausgabedatei. Es geht ja nicht nur um eine Ausgabedatei und eine Eingabedatei. Ist im Konzept der Anwendung einfach nicht vorgesehen und wird auch von der GUI unterbunden.

xa89

Ich selbst habe kein Problem damit die Batchdatei zu ändern und die Endzeit der Ausgabedatei anzupassen.
Vielleicht kann dies auch für den normalen Anwender im Dialog realisiert werden.
z.B. beim Ankreuzen "Hinzufügen zur Batchverarbeitung" und Klick auf "OK" die editierte Endzeit des Schnittbereiches in die Batchdatei übernehmen.

Wegen der Unschärferelation von Sein und Nichtsein haben wir unsere Gegenwart (das Jetzt).


www.cypheros.de