Angepinnt Von Vegas zu HandBrake

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Neue Nachrichten diesbezüglich: Solange das Projekt nicht sehr groß ist - meines ist aber 2 Stunden lang - klappt alles vorzüglich. Wird es dagegen zu groß, kommt es dazu, dass der Frameserver offensichtlich seine Daten nicht mehr bereit stellt.

      Ich lote mal aus, wo die Grenze liegt in etwa.

    • Verdacht: Es wird zu früh erkannt, dass die AVI angeblich schon da sein soll. Das stimmt aber bei längeren Projekten nicht - sie ist zwar "da", aber noch nicht fertig geschrieben. Dein Ping erzeugt bei Netzwerkrechnern keine Zeitverzögerung, sondern fällt sofort wieder zurück. Da muss etwas anderes her.

    • Wenzi schrieb:

      Mit einer Stunde klappt es immer noch nicht...

      Ok, so große Projekte habe ich noch nicht probiert.

      Frage am Rande, von welcher Version reden wir?
      Marco hat ja, mit dem ändern der Frameserver-Datei im Prinzip 1.10 oder 2.0 erschaffen :gruebel:
      Also hier läuft das "original" sehr gut.
      Aus kurzen Testclips mit insgesamt 220MB, 1080p wird 720p mit rund 20MB bei einer sehr guten Qualität
      Einfach irre. =O



      DV- it's not just a job, it's an adventure!
      (Signatur seit 2004...und das bleibt auch so)

      INFO: Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung

    • „Da muss etwas anderes her.“

      Da ich mit all dem, was ich dazu ausprobiere (z. B. das frühere Registrieren der Datei avfs.dll), eher Verschlechterungen erreiche, fürchte ich das auch. Allerdings bezweifle ich, dass das mit Batchprozessen noch machbar ist.

    • Ich habe ein 4NT-Skript mit einer Zeitverzögerung von 60s eingebaut. Doch dann kommt in Handbrake der Übergabeparameter nicht mehr rüber (Dateinamen). Das ist u.a. ein Zeitproblem... wie ich schon befürchtete. Die Namensübergabe scheint außerdem kritisch zu sein. Morgen wieder.

    • Ich habe eben einen Durchlauf gemacht mit manuellen Starts aller einzelnen Prozesse und habe dabei die Dateien (die vom FrameServer erzeugte und die von File Mount erzeugte) überwacht. Sobald die vorhanden sind, scheinen die auch vollständig zu sein. Ich bin da langsam mit meinem Latein am Ende. Vielleicht ist es schlicht für komplexere Projekte nicht brauchbar.

    • Das Projekt das bei mir Probleme hat, ist nur 3 Minuten lang, besteht aber aus einige genestelte lowerthirds und aus kurze Bildfragmente einer geschlossene Aufnahme von 45 Minuten.

    • Marco bei mir funktioniert es (bis jetzt) problemlos, auch bei komplexere Projekten, wenn ich in deine erste Batch Datei, den zweiten Pingwert von 1500 auf 15000 erhöhe. Ich denke das deine zweite Batchdatei ein Fehler hat.

    • Der zweite Ping muß variabel sein(erste Version Batchdatei) und nicht einen festen Wert haben. Solange mit dem Frameserver das *.avi erstellt und übergeben wird. Erst danach darf der nächste Schritt folgen.
      (pfm register C:\frameserver\avfs.dll)

      Dann klappt es.

    • Theo, das ist der richtige Weg und an der richtigen Stelle! Der Frameserver darf nicht mehr beschäftigt sein mit dem Aufbau seiner Signpost-Datei, erst dann darf Handbrake starten. Dumm ist nur, dass die Zeitspanne abhängig ist von der Größe/Länge des Projekts. Bei mir rafft er noch 20 Minuten-Videos mit dem erhöhten Wert. Es müsste eine Methode geben, die erkennt, wann der Framserver mit seiner Einstandsarbeit fertig ist.

      Oh, Günther war etwas schneller - ich teste immer noch. Mit dem Wert 100000 dauert zwar der Start deutlich länger, dafür lädt er mir nun auch ein 90-Minuten-Projekt!

    • Ich habe eine Lösung bereit:

      Es gibt ein hervorragendes Programm namens 4NT.EXE, das eine sehr aufwändige Batchprogrammierung erlaubt. Ziel ist es, dieses Batch-Programm (es ist m.W. inzwischen Freeware) zu aktivieren mit folgender Zeile (anstatt des zweiten Ping):

      call C:\frameserver\batch\4nt.exe /s C:\frameserver\batch\VegasReady.bat

      Und in VegasReady.bat stehen folgende Anweisungen (tasklist.exe ist in Windows selbst enthalten):

      @echo off
      set prog=vegas

      :start

      tasklist /v | find "%prog" > task.tmp
      set a1=%@execstr[type task.tmp]
      set a2=%@left[160,%a1]
      set v1=%@substr[%a2,151,8]

      delay 5
      tasklist /v | find "%prog" > task.tmp
      set a1=%@execstr[type task.tmp]
      set a2=%@left[160,%a1]
      set v2=%@substr[%a2,151,8]

      if %v1 ne %v2 goto start

      rem ------- Batch verlassen --------
      Exit

      Was macht es? Nun, es prüft alle 5 Sekunden, ob Vegas noch rechnet. Und das tut es, solange der Frameserver seine Signpost-Datei - abhängig von der Projektlänge - erstellt. Ist es fertig, geht die Prozesszeit von Vegas gegen Null. Es sollte natürlich keine zweite Instanz von Vegas laufen, sonst kommt das Tool durcheinander. Anschließend wird dieser Batch-Job verlassen und das der ursprüngliche Batch wird fortgesetzt. Bei kurzen Projekten geht das nun sehr schnell, bei längeren entsprechend länger.

      Damit lässt sich auch eine Routine basteln, Windows herunterzufahren, sobald Vegas mit einem länger andauernden Renderprozess fertig geworden ist. Bei Bedarf bitte melden.

    • Theo, dein Ansatz funktioniert bei Projekten bis Dimension X. Die eigentliche Lösung besteht aber vermutlich darin, wie Günter es geschrieben hat, die fixe Wartezeit gegen eine dem Projekt automatisch angepasste Wartezeit zu verwenden. Das ist sie in der neueren Batchdatei schon (denn der Prozess geht ja erst dann weiter, wenn diese Frameserve-Datei auch existiert), aber womöglich fehlt tatsächlich noch die Sicherheit, dass da nicht nur die Datei existiert, sondern auch ihr Inhalt komplett aufgebaut ist.

      Von daher möchte ich zunächst mal Günters Ansatz verfolgen und per normalem Batch eine Abfrage der Dateigröße einbauen, damit nicht noch ein weiteres Programm installiert werden muss und zusätzliche EXE-Dateien mit reingenommen werden (die können durch Virenscanner den kompletten Ablauf stören).

      Wenn das nicht helfen sollte, komme ich auf Lothars Lösung zurück.

    • Marco schrieb:

      sondern auch ihr Inhalt komplett aufgebaut ist.


      Genau das ist der springende Punkt. Klar ist schon, dass man zusätzliche Programme vermeiden sollte. Bei mir läuft's auf alle Fälle problemlos - und angepasst an die Projektlänge. 4NT (von JP-Software) heißt nun übrigens TCC und ist auf 64 Bitsysteme angepasst. Ich benutze 4NT schon seit 20 Jahren, denn es steckt den Windows-CMD komplett in die Tasche.
      Das ist für mich eine Art Schweizer Messer für die gehobene Batchprogrammierung und auf allen meinen Rechnern in Gebrauch. :beer:

    • aber womöglich fehlt tatsächlich noch die Sicherheit, dass da nicht nur die Datei existiert, sondern auch ihr Inhalt komplett aufgebaut ist.

      @Marco, schau dir mal die Datei C:\frameserver\source\vegas.avi an. (größeres Projekt). Erst wenn der Frameserver die *.AVI komplett geschrieben hat, wird der gesamte Wert angezeigt. Vorher steht er auf Null.
      Damit ist es doch einfach, die Datei > 0 abzufragen und dann den Batchprozess weiter zu starten.

    • Also bei mir funktioniert es mit der von Günter vorgeschlagenen Abfrage der Dateigröße (die ich etwas über 0 angesetzt habe, um halbwegs sicher zu gehen, dass nicht nur Müll in der Datei drinsteckt). Diese Abfrage habe ich gleich nochmal für die gemountete AVI-Datei wiederholt. Anhang des aktualisierten Batchscripts folgt später.

    • Marco schrieb:

      Lothar, ich werde mir 4NT auf jeden Fall ansehen. Wo sind denn funktionell die Vorteile gegenüber der in Windows integrierten PowerShell?


      Das kann ich Dir nicht einmal sagen, denn ich begann mit 4NT zu programmieren, da war von einer Powershell noch weit und breit nichts zu sehen. Mich würde die Dateigrößenauswertung innerhalb der "normalen" Shell schon ebenfalls zusagen, denn dann benötige ich keine extra Lösung. Obwohl man mit 4NT natürlich auch solche Abfragen gestalten kann, sogar bis aufs einzelne Byte hinab. Mit meiner Methode frage ich halt ab, ob Vegas bzw. der Frameserver fertig sind mit dem Aufbau der Datei und werte das dann aus. Ist gehupft wie gesprungen. Ich bin allerdings froh, dass diese Lösung nun gefunden ist, denn ich will X264 zukünftig intensiv nutzen und mit dem AVI-Codec alleine erzeuge ich eine Videodatei, mit der (fast) kein Programm etwas anfangen kann. Dieser Codec ist wirklich die Sahne in der Suppe und es ist schade, dass Vegas nicht bessere Lösungen - auch zum Skalieren - bereit hält. In DV-Zeiten war das alles mal besser.

      Erst wenn der Frameserver die *.AVI komplett geschrieben hat, wird der gesamte Wert angezeigt. Vorher steht er auf Null.


      Das ist nicht unüblich bei geöffneten Dateien, in die gerade schrieben wird. Erst wenn sie komplett beendet sind, wird die korrekte Größe angezeigt.