Beiträge von Highwayman

Hallo,

das bisher als klar angenommene Vorgehen wirft nun doch einige Fragen auf.
Ich habe einige Test gemacht und mir dabei die log-Datei anzeigen lassen.

Wenn "Allow Video Oberlays" nicht aktiviert ist, dann wird für die Anzeige "recompressed".
Die Preferences-Einstellung Main / Output Color depth steht auf "Use output setting". Damit wird für die Anzeige die Einstellung Video / Color Depth / Decompression format gewählt.

Für die Rückkonvertierung stelle ich zunächst "(Uncompressed RGB/YCbCr)" ein (in Compression).
Mittels empfohlenem "Fast recompress" erhalte ich

• bei Color Depth = Autoselect / Same:
  Dub: Recompressing using format RGB888
  Dies ist also falsch, da nach RGB konvertiert wird.

• bei Color Depth / Decompression format = YUY2:
  Dub: Recompressing using format YUYV
  Unter der Annahme, dass YUYV und YUY2 identisch sind, also korrekt.
  Aber leider ist die Ergebnisdatei nicht lesbar, grüner Bildschirm, Datei besteht nur aus Null-Frames. 

Die Frage hierzu: ist das normales Verhalten oder auf falsche Einstellungen zurückzuführen?
D.h. sollte es eigentlich so gehen?

Highwayman.

Eine Videodatei im Avi-Format mit Codec "Lagarith", Farbraum YUY2, soll in YUY2 zuürckgewandelt werden.
Hierfür kann der „Edit-Mode“ von Virtual Dub genutzt werden. Ziel ist eine Re-Kompression ohne Farbraumwandlung.

Prinzipiell sind zwei Einstellungsmöglichkeiten bei VDub denkbar:

• (Uncompressed RGB/YCbCr)
  
• ffdshow Video Codec

Hier beschreibe ich später die Testergebnisse.

Highwayman.

Also, ich will schon die SSD als Systemplatte verwenden und auf eine andere Festplatte aufnehmen. Bin halt noch nicht so weit mit den Umstellungen. Da die SSD frei war, habe ich halt die für Tests genommen und festgestellt, dass der Fehler auftritt.
Und ich vermute auch nicht, dass VDub eine Funktion zum Abmelden von SSD's hat.

Der Schreibvorgang läuft halt auf einen Fehler, der die Platte abstürzen lässt.

Und die Frage war eigentlich nur, ob das schon jemand beobachtet hat und ob das eventuell an meinen Einstellungen liegen könnte (z.B. Windows Cashing ausschalten).

Highwayman.

Hallo,

es ist schon eine normale SSD SATA-2 ACHI Installation. Andererseits tritt der Fehler bisher auf den anderen Nicht-SSD aber ebenfalls ACHI Festplatten nicht auf.
Auf der SSD ist er reproduzierbar.

b29.PNG

Das Problem tritt auch erst seit kurzem auf.

Daher nehme ich an, dass es etwas mit den von mir veränderten Einstellungen zu tun hat.
Irgendwie muss es sich um den Bereich Disk I/O im Capture Mde handeln.

Folgende Werte könnten eine Rolle spielen:
Chunk Size (512 MB)
Chunk Count (2)
x Disable Windows write buffering

Eventuell auch im Edit Mode die Einstellung unter Options / Preferences / Disk I/O / Disk I/O write mode.
Der steht auf "Asynchronous unbuffered - fastest (Windows NT only)".

Ist das richtig eingestellt?
Aber spielt das im Capture Mode überhaupt eine Rolle?

Vielleicht verträgt sich das nicht mit Cache-Einstellungen der Festplatte (siehe Grafik).

Guten Rutsch an alle,

Highwayman.

Zitat von mectst

Ist es eine fest eingebaute SSD oder eine extern angeschlossene? Welche Windows-version nutzt du? Ist die SSD ansonsten i.O. (z.B. CrystalDiskInfo)? Was sagt die Windows-Ereignisanzeige dazu?
Grüße Thomas

SSD ist zwar fest eingebaut, aber wie externe Platte angemeldet (SATA, Hotplug). Habe ich nicht bewusst gemacht.
CrystalDiskInfo meldet: alles OK.

Windows-Ereignisanzeige:
Name der fehlerhaften Anwendung: VirtualDub.exe, Version: 0.0.0.0, Zeitstempel: 0x526d9abc
Name des fehlerhaften Moduls: unknown, Version: 0.0.0.0, Zeitstempel: 0x00000000
Ausnahmecode: 0xc00000fd
Fehleroffset: 0x74e1e4e4
ID des fehlerhaften Prozesses: 0x17a4
Startzeit der fehlerhaften Anwendung: 0x01d26112560df4d5
Pfad der fehlerhaften Anwendung: Q:\Capturing\VirtualDub-1.10.4\VirtualDub.exe
Pfad des fehlerhaften Moduls: unknown
Berichtskennung: c4fbf709-cd4a-11e6-b983-001fd092843a

Highwayman.

Stack overflow exception (0xC00000FD) Exception

Zitat von Pro Jo

Ich bin zwar kein Elektroniker, aber ich schätze, dass das Audio-Signal 1:1 weitergeleitet wird. Die Ton-Qualität müsste bei 16Bit und 48kHz stabil bleiben.
Meiner Meinung nach, digitalisiert der EH52 die Bild- und Tonsignale, die am HDMI-Ausgang anliegen.

Diese werden aber von der Movie-Box schon als Digitalsignale empfangen, denn sie liegen ja bereits digital vor. Der digitale Stream wird dann nur noch gecaptured.
Bei analogen Signalen, digitalisiert die Capture-Karte. So sehe ich das. Aber zu diesem Thema, werden uns die Spezialisten sicherlich aufklären.

Hallo Jo,

hmm, der EH52 hat keinen HDMI-Ausgang. Das Verfahren im Zusammenhang mit der Moviebox, die keinen digitalen Audioeingang hat (sieht man mal von Firewire ab), basiert auf zweimaliger Digitalisierung. EH52 digitalisiert und stabilisiert und gibt am Scart-Ausgang analoge Signale aus, welche die Moviebox erneut digitalisiert.
Trotzdem ist das Bild besser, weil weniger Jitter auftritt.

Beim Ton ist es halt die Frage.

Hast du den Versatz nur bedingt durch das Direktanschließens des Audio-Signals oder generell? Die Moviebox hält Bild und Ton gut zusammen, blöd wäre, wenn der Direktanschluss des Tons jetzt Asynchronität erzeugen würde.

Highwayman.

Zitat von Rübezahl

Kann ich nur bestätigen, ich benutze zum Capturen meine älteren Festplatten (ST3500320AS) weiter.
Auf der SSD ist sicherlich das Betriebssystem!?
Sollte tunlichst vermieden werden, für die Aufnahmen eine extra Platte verwenden.
Und später bei der Weitervearbeitung mit VirtDub und eventuell unter AviSynth sollte für Quelle und Ziel auch nicht die gleiche Platte verwenden werden!
Damit neben der SSD den PC gleich für 3 Festplatten einplanen, wegen Sicherung der Daten.

Gruß Rübezahl

Na ja, ich habe 4 Festplatten im Einsatz. Die SSD ist neu und enthält die neue Win 10 - Installation sowie weitere (freie) Datenpartitionen.

Zitat von bergh

tach auch !

Ohne das Problem zu kennen, aber warum muss man eine empfindliche SSD mit Videodaten quälen?
Jede normale HD kann doch mit diesen Datenmengen gut umgehen, zumindest seit 1995.

Weil sich das im Test gerade anbot, freier Speicherplatz und so.
Die Frage war ja nicht, ob das sinnvoll ist (meiner Meinung nach sind SSDs nicht empfindlich), sondern ob es bekannte Probleme von VDub beim Zugriff auf Festplatten gibt. SSD ist da gar nicht so entscheidend, eher die Einbindung als "Wechseldatenträger" mit SATA ACHI.

Zitat von mectst

Was bitte heist "meldet VDub mir meine SSD-Festplatte ab" genau? Auf allen mir bekannten Windows-Versionen kann ich nur externe Medien auswerfen; oder tief im System vielleicht noch in der Datenträger-Verwaltung - das geht aber nur mit Administrator-Rechten, wo ich a) nicht glaube, dass VDub derart tiefe Betriebssystem-Funktionen anfasst (wozu auch??) und b) sollte man fürs normale Arbeiten auch nicht als Admin unterwegs sein.
Ist es eine fest eingebaute SSD oder eine extern angeschlossene? Welche Windows-version nutzt du? Ist die SSD ansonsten i.O. (z.B. CrystalDiskInfo)? Was sagt die Windows-Ereignisanzeige dazu?

Grüße Thomas

Hallo Thomas,

OS ist Win 7 Prof. Die Festplatten sind alle SATA, mit ACHI-Treiber eingebunden. Ich habe mir beim Einbinden der Festplatten keine großartige Gedanken gemacht, leider. Win hat sie standardmäßig erkannt und eingebunden.
SATA ist ja Hotplug-fähig. Die Festplatten sind wie Wechseldatenträger eingebunden und somit "auswerfbar". Die Entfernungsrichtlinie steht auf "Bessere Leistung (Standard)".

Grundsätzlich werfe ich die Festpatten nicht aus, aber VDub halt.

Das mag ja alles nicht optimal eingerichtet sein, aber im Augenblick geht es mir um die Digitalierung, d.h. ich will das Verfahren zum Laufen bringen.

Die SSD ist in diesem Fall nicht die Systemplatte, sie enthält eine Win 10 - Installation, ist neu und verfügt über eine separate Partition mit viel freiem Speicher.

Grüße
Highwayman.

Hallo,

so langsam komme ich ins Zweifeln, ob Virtual Dub noch die richtige Wahl für ein Capture-Programm ist.
Neben den noch nicht gelösten Problemen des Einfrierens kommt jetzt noch ein weiteres Problem hinzu:

Nach dem Erstellen ein Capture-Datei, dh. am Ende des Capture-Vorgangs, meldet VDub mir meine SSD-Festplatte ab (auf die ich schreibe), die sich dann wieder anmeldet, dann wieder abgemeldet wird und so weiter ...

Woran kann das liegen?

Ist die Architektur von VDub zu alt für moderne Festplatten?
Kann es an irgendwelchen falschen Einstellungen liegen?

Hat jemand schon ähnliche Erfahrungen gemacht?

Highwayman.

Zitat von Pro Jo

Hallo Highwayman,
...
Ich würde auch einmal probieren, den Audio-Ton an den DMR EH52 anzuschließen, eventuell ist dann der Versatz weg, oder zumindest geringer.
Normalerweise synchronisiert unter anderem auch der TBC, die Bilder mit dem Ton. Von deinem Player den Ton direkt an die Pinnacle-Box anschließen, würde ich nicht machen.
Den Player-Ton zum DMR EH52 leiten.

Hallo zusammen,

hier gibt es nun im Forum zwei unterschiedliche Empfehlungen.

1) Ton direkt an die Pinnacle-Box anschließen
Hier entsteht ein konstanter Versatz von 120 ms, die sich im Capture Mode von VDdub korrigieren lassen.
Vorteil: Audio wird nur einmal digitalisiert.
Nachteil: DMR EH52 kann Video und Audio nicht synchronisieren. Ist das relevant?

2) Ton ebenfalls über den DMR EH52 leiten
Vorteil: kein Audio-Versatz, DMR EH52 synchronisiert Audio und Video
Nachteil: Audio wird zweimal digitaliert

Was sind eure Erfahrungen?

2) ist sicher einfacher und logisch sauberer. Ist die zweimalige Audio-Digitalisierung wahrnehmbar?

Highwayman.

Zitat von LigH

"Prevent Upsampling When Decoding" ... damit werden Codec-interne Farbraum-Konvertierungen beim Decodieren verhindert. Vielleicht geht es, wenn man dies nicht verbietet?

Ein Nachtrag:
Die Einstellung "Prevent Upsampling When Decoding" bei Lagarith-Codec verhindert die Konvertierung in RGB und damit das Abspielen in VDub.
Das gilt aber nicht, wenn unter Preferences / Main / Output color depth "Use Output setting" eingestellt ist - bei passendem Decompression format in Color Depth.

Zitat von Pro Jo

Hallo Highwayman,
...

Ich würde vorschlagen, gleich das erste Mal mit Lagarith zu capturen. Da hast Du nur eine Datei, diese ist aber auch sehr hochwertig.

VDub: Video, Compression:
Bei Lagarith folgende Werte einstellen:

Keyframes alle 25 Bilder
Enable Null Frames: Aktivieren
Use Multithreading: Aktivieren
Mode: YUY2

Die anderen beiden Optionen deaktivieren. Ja, gleich den Ton-Versatz einstellen, das kannst Du ausprobieren.

Gruß Jo

Alles anzeigen

Hallo zusammen, hallo Jo,

Hierzu habe ich jetzt aktuell doch noch Nachfragen.

Bisher bin ich davon ausgegangen (warum auch immer), dass bei verlustlosen Codecs Keyframes uninteressant sind. Bei Huffyuv v.2.1.1 kann man auch nichts einstellen. Bei Lagarith allerdings schon.
Bisher habe ich da nichts eingetragen.
Ist es tatsächlich zu empfehlen, hier 25 vorzugeben?
Wirkt sich das merkbar auf die Größe der Datei aus?

Enable Null Frames habe ich deaktiviert, da ich ja das Original erhalten will. D.h. die Rückumwandlung in YUY2 sollte dasselbe Ergebnis liefern wie eine Digitalisierung in YUY2. Liege ich da falsch?

Highwayman.

Danke LigH,

das hat mir sehr geholfen.

Ich hatte die Option bewusst gewählt, nachdem ich Probleme bei Rückkonvertieren hatte: manchmal war die Datei zirka doppelt so groß (RGB).
Ich wollte sicherstellen, dass bedingt durch meine Zwischenspeicherung in LAGS keine unnötige Farbraumkonvertierung stattfindet.

Der Weg ist ja jetzt folgender:
Moviebox liefert YUY2.
VDub Capture Mode wandelt in LAGS um.
Für diesen Schritt sind (hoffentlich) nur die Einstellungen des Lagarith-Codecs relevant.
Hier muss YUY2 eingestellt sein.

Für die Rückkonvertierung mit VDub (Processing Mode) kann ich bei Compression auswählen:
1) (Uncompressed RGB/YCbCr)
2) ffdshow Video Codec

Meinen Tests nach ist das egal, es ist nur darauf zu achten, dass "Fast Recompress" ausgewählt ist (sonst wird ggf. in RGB umgewandelt).
Das ist möglich, da ich bei diesem Schritt ja keine VDub-Filter nutze.
Gibt es irgendeinen Grund, den (konfigurierbaren) ffdshow-Codec zu bevorzugen?
Ansonsten nehme ich lieber die Variante 1), da sie von Änderungen in der ffdshow-Konfiguration unbeeinflusst bleibt.

Somit sind die Einstellungen "Video Color Depth" für diese Vorhaben also völlig uninteressant (zumindest bei der Variante, gleich im Capture Mode nach LAGS zu komprimieren). Denn bei "Fast Recompress" ist "Video Color Depth" nicht verfügbar.

Trotzdem hätte ich hier gerne eine einheitliche Einstellung.
Ich denke "Autoselect" bei "Decompression format" ist gesetzt.
Bei "Output format to compressor/display" schwanke ich zwischen "Same" und "YUY2".
Was ist denn sinnvoller?

Highwayman.

Zitat von LigH

"Prevent Upsampling When Decoding" ... damit werden Codec-interne Farbraum-Konvertierungen beim Decodieren verhindert. Vielleicht geht es, wenn man dies nicht verbietet?

Oh, Moment, das teste ich gleich noch einmal ...

Es scheint tatsächlich daran zu liegen ...

Nein, doch nicht, jetzt geht es wieder nicht ...

Es ist schon etwas merkwürdig. Wenn ich eine YUY2-Datei nach Lagarith kodiere und dann unmittelbar das Ergebnis lade und abspiele, dann läuft es. Und dann laufen auch alle anderen, alten LAGS-Dateien. Wenn ich VDub neu aufrufe, dann nicht. Muss irgendwie an meinen Einstellungen liegen.

Das gilt jetzt auch für die Avisynth-Tests. (E) RGB24 läuft jetzt auch.

Jetzt habe ich eine Vermutung:
Der Registry-Eintrag bei Lagarith für "Prevent Upsampling When Decoding" verändert nicht die erstellte Datei mit irgendeinem Sperreintrag, sondern er wirkt sich direkt auf das Abspielen aus.

Avisynth Version ist
AviSynth 2.58, build:Dec 22 2008 [08:46:51]

-----------------------------------
file = "E:\Capture\neuertest2l.avi"

#AviSource(file) #(A)
#AviSource(file, pixel_type="FULL") # automatische Wahl kompatibel zu AviSynth 2.6+ #(B)
#AviSource(file, pixel_type="AUTO") # automatische Wahl kompatibel zu AviSynth 2.5 #(C)
#AviSource(file, pixel_type="YUY2") #(D)
#AviSource(file, pixel_type="RGB24") #(E)
#return VersionString()

Info()
-----------------------------------

(A) läuft
(B) AVISource: requested format must be YV12, YUY2, RGB32 or RGB24
(C) AVISource: requested format must be YV12, YUY2, RGB32 or RGB24
(D) läuft
(E) AVISource: the video decompressor couldn't produce RGB24 output

Info von A

b27.PNG

Info von D

b28.PNG

Gruß, Highwayman.

Zitat von LigH

Wahrscheinlich ja. Dann lies aber bitte die Fehlermeldung noch mal ganz genau, denn die enthält auch Hinweise auf die Gründe, warum das bei dir nicht funktionieren könnte.

Fehlermeldung:

The video decompressor cannot decompress to the selected input format. Check for a "Force YUY2" setting in the codes's properties or select a different input video format under Video > Color Depth.

Zitat von LigH

Man kann den Lagarith VfW-Codec wahrscheinlich vielfältig konfigurieren, und dabei wohl auch die Decodierung in bestimmte Ausgabeformate erzwingen – oder auch nicht. Also schau dir die Codec-Konfiguration noch mal genau an, welche Checkboxen da evtl. angehakt sind, oder wie auch immer das da aussieht (Video - Compression {Strg+P} - Lagarith - Configure).

Parameter:

- Enable Null Frames
- Always Suggest RGB for Output
+ Use Multithreading
+ Prevent Upsampling When Decoding

Mode: YUY2

Ich habe mein Testprotokoll gefunden. In der Endauswahl für den verlustfreien Codec waren Ut Video 64 (15.3.0), FFV1.3 und Lagarith. Für Lagarith habe ich mir notiert: abspielbar in VDub (ohne ffdshow).

Jetzt sind auch die damals erstellten Lagarith-Dateien nicht abspielbar, und zwar unter Win 7 und Win 10 nicht.
Somit kann es ja nur an den VDub-Einstellungen liegen, an denen habe ich in beiden Installationen herumgespielt.

Aber welche Einstellung kann verantwortlich sein? Ich bin da im Augenblick etwas ratlos.
OK, Registry-Eintrag löschen und VDub neu aufrufen ist ein möglicher Ansatz.
Bessere Ideen?

Highwayman.

Moin moin Nordlicht,

ich habe jetzt gesehen, dass ich alle Lagarith-Dateien mit VDub nicht abspielen kann.
Mit VLC schon.
Ich habe vor einem halben Jahr oder länger alle Codecs getestet und mich dann für Lagarith entschieden.
Einziger Nachteil war, dass er sich nicht einfach in Schnittprogramme wie Vegas integriert.
Ist aber kein Problem, da der nächste Schritt Avisynth ist.

Bei den Tests habe ich (so meine ich) Lagarith mit VDub zurückgewandelt in YUY2 und Original und Restore miteinander verglichen.
Das geht wohl auch.
Dabei müsste mir aber eigentlich aufgefallen sein, dass VDub Lagarith nicht abspielt (entgegen Aussagen in einigen Boards).

An alle: Kann man denn Lagarith in VDub abspielen?

Highwayman.

Hallo zusammen,

ich habe versucht, den Rat umzusetzen und gleich in einem Schritt zu digitalisieren und nach Lagarith zu kodieren.
Das schlug leider fehl.

Wenn ich im Capture Mode komprimieren in Lagarith, dann kann VDub mit der Datei nichts anfangen.
Es kommt die Meldung in der Grafik.

Was mache ich falsch?
Kann man das beheben oder muss ich doch in zwei Schritten vorgehen?

Highwayman.

Die Nachricht über Goldwingfahrer bestürzt auch mich.
Er hatte ja anfangs auch noch zu meinen Thema Beiträge geleistet, dann nicht mehr, und man denkt sich nichts dabei.

Er wird uns fehlen.