Zum Inhalt springen

DCP erstellen...


REPTILE

Empfohlene Beiträge

  • 2 Wochen später...

Ich habe die Bild und Tondateien aus einem DCP extrahiert.

 

Es liegen jetzt 500 Bilder .j2c vor.

 

Bei der Konvertierung mit convert gibt es allerdings Probleme. Es werden nur genau 111 Bilder konvertiert dann wird die .bat beendet weil der Physikalische Speicher voll ist.

 

Diese Konvertierung läuft auch etwas anders ab, als bei extrahieren. Dort kann man beobachten wir Bild für Bild erzeugt wird.

Beim Konvertieren passiert erst mal nix. Weder im DOS-Fenster noch im Verzeichnis. Nur im Tast-Manager sieht man, wie sich der phys. Speicher füllt.

Wenn der voll ist werden auf einen Rutsch die 111 .bmp Bilder erzeugt. Das war's dann.

 

Betriebssystem ist Windows 7. Wo liegt das Problem?

 

HdGehres

Link zu diesem Kommentar
Auf anderen Seiten teilen

Kannst Du den Batch mal hier reinpasten?

 

 

Passiert bei mir unter XP nicht. Vielleicht alte, nicht auf Win7 angepasste Version von convert, die Probleme mit dem Speichermanagement oder multithreading hat? Oder ne falsche Version von Imagemagick runtergeladen?

 

Man kann das natürlich in 5 Häppchen a 100 Bildern machen, bis Du den Grund für das Problem gefunden hast.

 

Google findet ein paar andere Schilderungen dieses Problems.

 

Andere Möglichkeit einer Lösung wäre, nicht wildcards für convert zu benutzen, sondern die Bilder der Reihe nach EINZELN per Schleifenkonstrukt an convert zu übergeben.

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Kannst Du den Batch mal hier reinpasten?

 

 

Passiert bei mir unter XP nicht. Vielleicht alte, nicht auf Win7 angepasste Version von convert, die Probleme mit dem Speichermanagement oder multithreading hat? Oder ne falsche Version von Imagemagick runtergeladen?

 

Man kann das natürlich in 5 Häppchen a 100 Bildern machen, bis Du den Grund für das Problem gefunden hast.

 

Google findet ein paar andere Schilderungen dieses Problems.

 

Andere Möglichkeit einer Lösung wäre, nicht wildcards für convert zu benutzen, sondern die Bilder der Reihe nach EINZELN per Schleifenkonstrukt an convert zu übergeben.

 

- Carsten

So sieht die Batch-Datei aus, die bei 110 Bildern abbricht:

-----------------

convert -depth 12 -gamma 0.384615 -recolor "3.2404542 -1.5371385 -0.4985314 -0.9692660 1.8760108 0.0415560 0.0556434 -0.2040259 1.0572252" -gamma 2.2 -type TrueColor pic*.j2c pic.bmp

-----------------

Jetzt verwende ich den folgenden Batch. Der hat aber das Problem mit den führenden Nullen, d.h. ich muß pic00025.j2c erst in pic25.j2c umwandeln und später die BMP wieder mit führenden Nummen versehen.

-----------------

@echo off

set /a i=1

:start

if /I %i% GEQ 485 goto :next

convert -depth 12 -gamma 0.384615 -recolor "3.2404542 -1.5371385 -0.4985314 -0.9692660 1.8760108 0.0415560 0.0556434 -0.2040259 1.0572252" -gamma 2.2 -type TrueColor pic%i%.j2c pic%i%.bmp

set /a i=%i%+1

goto :start

:next

-----------------

 

HdGehres

Link zu diesem Kommentar
Auf anderen Seiten teilen

So sieht die Batch-Datei aus, die bei 110 Bildern abbricht:

-----------------

convert -depth 12 -gamma 0.384615 -recolor "3.2404542 -1.5371385 -0.4985314 -0.9692660 1.8760108 0.0415560 0.0556434 -0.2040259 1.0572252" -gamma 2.2 -type TrueColor pic*.j2c pic.bmp

 

 

Bin grad zu busy zum selber Testen, aber versuch in diesem Aufruf mal mit der option '+adjoin' das Schreiben von Einzelbildern zu forcieren und beobachte mal das Swap File. Könnte zwar sein, dass das Lesen der kompletten Sequenz davon unabhängig erfolgt, aber wer weiss, wofür es gut ist.

 

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Nee, klappt nicht mit +adjoin. Ich glaube, das passiert bei uns genauso mit dem SwapFile wie bei Dir - allerdings wird es bei uns nicht größer als 2.5GByte, und darf bis 4 wachsen und hat auch den Platz dafür. Also hat es bei uns scheinbar immer geklappt und ist nie jemandem aufgefallen. Möglicherweise passiert es bei höheren Bittiefen und/oder 4k auch eher.

 

Das mühsame Umbenennen kann man aber auch umgehen indem man einfach für jeden Hunderter den Aufruf einmal in einer Batchdatei startet.

 

also pic00001*.j2c

pic00002*.j2c

pic00003*.j2c

pic00004*.j2c

pic00005*.j2c

 

Muss aber irgendwie auch ne saubere Lösung dafür geben.

 

 

Hmm, sauber...?

 

http://www.imagemagick.org/script/command-line-options.php#limit

 

 

Das mit den dort erwähnten defaultmäßigen 2GB image area und 768 Files könnte erklären, warum das swapfile bei uns dann nicht weiter wächst.

 

 

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das ist aber ein ungewöhnliches verhalten...

 

Ich verwende auch batch scripts (also das von oben, kommt ja von mir) um trailer um zu wandeln und bei mir erstellt er ein bild nach dem anderen auf der

Festplatte ohne das es zu vollen Speicher kommt.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ja, aber der Batch mit der start:next Schleife ruft natürlich convert auch wirklich immer nur mit einer Bilddatei auf - da können nur die Ressourcen für ein einzelnes Bild belegt werden, von den anderen Bildern weiss Convert zum Zeitpunkt des Aufrufs ja nichts.

 

Der Aufruf convert -depth 12 -gamma 0.384615 -recolor "3.2404542 -1.5371385 -0.4985314 -0.9692660 1.8760108 0.0415560 0.0556434 -0.2040259 1.0572252" -gamma 2.2 -type TrueColor pic*.j2c pic.bmp dagegen übergibt faktisch die gesamte Bildsequenz auf einmal an convert - die wildcards * darin sind ja keine shell-funktion, sondern werden von convert selbst ausgewertet. Und offensichtlich macht convert da gerne viele Bilder auf einmal in einer Pipeline auf. Vielleicht auch, um selbsttätig multithreading auf file- bzw. Bildebene machen zu können.

 

Es gibt ja auch einige Zielformate - animated GIF z.B., die direkt Sequenzen in einer Datei aufnehmen können. Der übliche Aufruf von convert pic*.jpg pic.gif konvertiert ohne weiteres eine Reihe von Einzelbildern in ein EINZIGES Animated GIF File mit der Sequenz. Irgendwo dahinter muss sich diese Eigenart mit der Speicherverwaltung begründen lassen, die auch dazu führt, dass das Resultat nicht direkt auf Einzelbildbasis geschrieben wird.

 

Ich denke, bei HdGehres fällt das nur deswegen unangenehm auf, weil er entweder die Swapfilegröße zu knapp begrenzt hat, oder weil er auf dem Swap-Laufwerk nicht mehr genug Platz hat.

 

 

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hmm, ja, ich habe grade mal die ganz aktuelle 64Bit Version von ImageMagick (16Bit component) auf einem Core i3 installiert und mal versucht, einen Trailer mit ca. 2600 frames mit dem Convert Einzeiler zu bearbeiten - da passiert das gleiche. das Swapfile wächst ins Unermessliche, irgendwann wird die Kiste extrem zäh, es gibt jpg_dec Fehler von convert, etc. pp.

 

Bei knapp über 800 frames ist Schluss, gibt dann die erwähnte Fehlermeldung 'unable to decode image file', Swapfile hat da fast 12GByte.

Die dann auf einmal geschriebenen BMP Files sind aber alle Schrott, 0 KB

 

Lustig, ich dachte, ImageMagick wird allerorten auf diese Art und Weise zum Konvertieren von ganzen Verzeichnissen mit Megapixel Digiknipsenbildern benutzt...

Läuft unter Linux vielleicht auch anders mit den Wildcards.

 

Kurzer Check mit per pic0000*.j2c auf 100 begrenzter Bildzahl reisst zwar auch die Speichernutzung deutlich hoch, läuft aber erfolgreich durch, auch hier werden die konvertierten Bilder erst alle zusammen am Schluss geschrieben.

 

Ein -limit file 10 bringt da übrigens garnix, das scheint ne andere Bedeutung zu haben. Ein -limit memory 100MiB bringt allerdings was - der Speicherbedarf beschränkt sich auf 150-200MByte. Jetzt läuft grade der ganze 2600er Stappel nochmal durch, mal sehen. Trotzdem werden keine BMPs zwischendurch ins Zielverzeichnis geschrieben. Wenn man der Imagemagick Doku glauben darf, swapt ImageMagick jetzt selbsttätig. Damit läuft die Sache also kaum schneller durch, aber ohne dass die Kiste schlapp macht. Merkwürdig. Aber das ist jetzt spätestens nichts mehr für dieses Forum...

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hmm, nach ner halben Stunde fängt der große Aufruf plötzlich an, Bilder zu schreiben, eins nach dem anderen. Also scheint schon irgendwie zu gehen mit -limit, ist aber ultralangsam.

 

Nee, das muss schon mit einer Batch-Schleife laufen, ist sonst krank. Was haben die ImageMagick Leute sich bloß dabei gedacht...

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Okay, hier die wirklich simple Variante als Einzeiler:

 

FOR %a in (*.j2c) DO convert %a %~na.bmp

 

Das funktioniert so nur direkt auf der Kommandozeile - ruft man das in einer batchdatei auf, muss man alle % verdoppeln, also FOR %%a ...

 

Das %~na.bmp am Ende 'schneidet' die Extension des ursprünglichen Dateinamens ab, sorgt also dafür, dass ein pic001.j2c nicht zu einem pic001.j2c.bmp wird.

 

( http://www.rgagnon.com/gp/gp-0008.html )

 

Damit läuft der 2600er Stapel ohne großartige Auffälligkeiten beim Speicherbrauch durch.

 

@HdGehres: Den Rest deiner Aufrufparameter muss Du selber reinpacken. Der Unterschied zwischen einer Zählschleife, die Dateinamen entsprechend Ihrer Nummerierung hochzählt und aufruft, und der DOS-Aufrufvariante '%a', die einfach ALLE Dateien im Verzeichnis nach Auswahl aus (*.j2c) konvertiert, dürfte klar sein, oder? In aller Regel dürfte es kein Problem sein, dass so zu machen. Spart ne Menge Arbeit mit Umbenennung, weil die Nummerierungsvariante in den Dateinamen, also mit oder ohne führende Nullen, überhaupt keine Rolle spielt. Man muss halt seine Verzeichnisse sauber halten. Aber natürlich geht auch (pic*.j2c), wenn man mehrere Projekte im gleichen Verzeichnis hat.

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

tolle Zusammenstellung der benötigten Programme, Anleitung, etc. danke dafür.

 

Leider habe ich ein Problem:

 

Ich habe in Premiere eine Videosequenz erstellt und konvertiere die nun in SUPER, genau mit den Einstellungen wie im Screenshot der PDF Anleitung.

Das funktioniert soweit auch.

Danach möchte ich die entstandene Datei in VirtualDub öffen, dann kommt folgende Fehlermeldung:

 

"Coudn´t locate decompressor for format "XVID" (unknown)

VirtualDub requires a video format for Windows (VFW) compatible codec to decompress video. DirectShow codecs, such as those used by Windows Media Player, are not suitable.

 

Wäre toll wenn mir dazu jemand weiterhelfen könnte.

 

Liebe Grüße,

 

Dominik

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das ist zwar nicht deine Frage, aber wenn Du aus Premiere kommst, warum exportierst Du nicht gleich von dort deine Einzelbildsequenz? Der Umweg über Super und VirtualDub ist in dem Fall vollkommen unnötig. Die DCPC Anleitung erwähnt diesen Weg nur für den Fall, dass man ein fertiges Videofile konvertieren muss. Hat man vorher schon die Wahl zu Einzelbildern, übergeht man das einfach.

 

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ja,

 

habe ich gemacht und läuft prima. (DCPC zeigt an der Stelle keinen Fehler)

 

Jetzt fehlt mir nur noch der Ton.

 

Wie mache ich denn am einfachsten aus einem MP3 ein .wav 24bit 48KHz ?

 

Mit GodWave? Ich habe so manchen Export ausprobiert aber wenn 24bit stimmt dann passt die KHz nicht usw.

 

Welches ist das richtige Format?

 

lg

 

Dominik

Link zu diesem Kommentar
Auf anderen Seiten teilen

Weiss nicht genau, was Du machst, aber das Audio kannst Du ja auch aus Premiere rausspielen. Ansonsten kann auch Audacity die Tonspuren erzeugen. Damit gehen auch relativ einfach (für ein kostenloses Tool jedenfalls) diskrete Mehrkanalfiles für Surround. Und die nötigen Format-Konvertierungen kann es auch.

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Von diesem Dolby Countdown würde ich mir gerne ein DCP erstellen.

Bild kein Problem, aber wie kriege ich aus der Datei die, angeblich, vorhandene 5.1 Spur?

Oder hat jemand das Teil zufällig schon als DCP und kann es mir zukommen lassen?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Wenn das DCP nicht verschlüsselt ist, dann geht das. Es enthält eine Video-MXF und eine Audio-MXF. Die kann man auspacken und hat dann einen Batzen J2K und eine Interleaved WAV-Datei. Die Einzelbildsequenz kann man mit üblichen Videotools wieder in übliche Computervideoformate konvertieren.

 

 

Alles was man dazu braucht ist im DCPC enthalten.

 

asdcp-test.exe -x audio.wav audio.mxf

asdcp-test.exe -x video.mxf

 

- Carsten

 

Das "Convert Problem" ist jetzt in einer Schleife aufgelöst.

 

Das neueste Problem ist nun die Einzelbild-Auflösung einer 3D.mxf.

 

Die 2D läuft mit asdcp-test.exe -x pic pic.mxf einwandfrei.

 

Bei der 3D habe ich es mit asdcp-test.exe -x pic -3 pic.mxf probiert.

 

Dann bekomme ist pic000001R.j2k und pic000001L.j2k usw. Aber die sind nur zwischen 2 kB und maximal 200 kB groß und nach dem umwandeln in bmp hat man nur eine graue Fläche.

 

Wo liegt der Fehler?

 

HdGehres

Link zu diesem Kommentar
Auf anderen Seiten teilen

Nachtrag

 

 

Ein selbst produziertes 3D-DCP läßt sich mit dem Batch einwandfrei in korrekte ca. 600 kB große .j2k Files auflösen. Auch die daraus erzeugten .bmp sind ok.

 

Bei dem Material das nicht funktioniert, handelt es sich um einen Trailer; also auch nicht verschlüsselt.

 

HdGehres

Link zu diesem Kommentar
Auf anderen Seiten teilen

Was passiert denn, wenn du die '-3' weglässt? Soweit ich weiss braucht man die nur für den umgekehrten Weg. Nicht dass ich glaube, dass das dein Problem mit dem 3D Trailer löst.

 

Hast Du es mal mit den anderen Optionen versucht? -v zum Beispiel?

 

 

- Carsten

Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...

Filmvorführer.de mit Werbung, externen Inhalten und Cookies nutzen

  I accept

Filmvorfuehrer.de, die Forenmitglieder und Partner nutzen eingebettete Skripte und Cookies, um die Seite optimal zu gestalten und fortlaufend zu verbessern, sowie zur Ausspielung von externen Inhalten (z.B. youtube, Vimeo, Twitter,..) und Anzeigen.

Die Verarbeitungszwecke im Einzelnen sind:

  • Informationen auf einem Gerät speichern und/oder abrufen
  • Datenübermittlung an Partner, auch n Länder ausserhalb der EU (Drittstaatentransfer)
  • Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen
Durch das Klicken des „Zustimmen“-Buttons stimmen Sie der Verarbeitung der auf Ihrem Gerät bzw. Ihrer Endeinrichtung gespeicherten Daten wie z.B. persönlichen Identifikatoren oder IP-Adressen für diese Verarbeitungszwecke gem. § 25 Abs. 1 TTDSG sowie Art. 6 Abs. 1 lit. a DSGVO zu. Darüber hinaus willigen Sie gem. Art. 49 Abs. 1 DSGVO ein, dass auch Anbieter in den USA Ihre Daten verarbeiten. In diesem Fall ist es möglich, dass die übermittelten Daten durch lokale Behörden verarbeitet werden. Weiterführende Details finden Sie in unserer  Datenschutzerklärung, die am Ende jeder Seite verlinkt sind. Die Zustimmung kann jederzeit durch Löschen des entsprechenden Cookies widerrufen werden.