This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

[HELP] Encoding wird zu früh beendet
#1
Hallo allerseits,

wie schon in meinem ersten Beitrag beschrieben, bin ich gerade dabei, diverse Home-Videos zu digitalisieren. Da diese von ehemals VHS-C auf normale VHS Tapes im LP Modus kopiert wurden, ergibt sich daraus, dass sich auf einer 240er Kassette eben 8 Stunden Video befinden.
Diese möchte ich auch einfach am Stück speichern. 
Beim capturen funktioniert das inzwischen auch ganz gut (Lagarith bzw. MagicYuv).

Das ganze deinterlace ich dann und mache es noch ein bißchen sauberer, damit es sich noch etwas besser komprimieren lässt.
Das ganze ist hier beschrieben:

https://forum.selur.net/thread-2798.html

Zuletzt möchte ich es als x264 archivieren. Das fängt immer gut an, aber mir ist es nun schon das zweite Mal passiert, dass die Encodierung bei ca. 70 % einfach beendet wird.
Das Programm stürzt nicht ab oder so, sondern es wird ganz normal gemuxt und ich habe dann eine Datei, die 14950 MB groß ist und nur 5:35 H lang statt 8:08 H  Blush

Gibt es da irgendeine Begrenzung, die ich nicht sehe?
Die Dateigröße des Ausgangsmaterials liegt bei ~200 GB (Lagarith bzw. MagicYuv + PCM)
Die Datei ist völlig in Ordnung! Ich habe sie vorher sogar einmal durch Virtualdub per fast recompress geschickt, weil ich ein Problem damit hatte, die mit Lagarith gecapturete Version mit einem anderen Programm zu öffnen. Also habe ich sie mit Virtualdub einfach nach MagicYuv konvertiert: keine Probleme.

Andererseits habe ich vormals mit einem 6MBit Hardware MPEG Grabber (Terratec MX 450) dieselben Aufzeichnungen versucht zu machen. Das Ergebnis war zwar suboptimal, aber worauf ich hinauswill: dort hatte hybrid, beim Versuch einzudampfen, keine Probleme, Dateien über 20 GB zu schreiben. Natürlich war aber da die Dateigröße des Ausgangsmaterials auch viel geringer (ca. 30 GB)

Wie gesagt, es kommt ja auch nicht zu einem Absturz, sondern das Programm meint einfach, dass es fertig ist und muxt....Ende  Sad
Unter "Jobs" steht übrigens dann "100%", was eben allerdings nicht stimmt.

Was mache ich falsch?

EDIT:

Kann das irgendwie mit einer 128 GB Grenze zusammenhängen? Ich befürchte fast....

EDIT 2:

Andere Datei fast an derselben Stelle: 13300 MB, 5:22 H Sad

EDIT 3:

Aus lauter Verzweiflung habe ich jetzt mal das gecapturete AVI in einen MKV-Container geschmissen und diesen dann in hybrid geladen.
Mal sehen, was passiert.... ich melde mich Smile
Reply
#2
Ohne DebugOutput der das Problem zeigt, kann ich nicht sagen warum Hybrid da irgendwas macht.
Lies den Angaben die nötig sind um Fehler zu beheben,...-sticky und erstell einen DebugOutput der das Problem zeigt.
Ansonsten kann ich nur Raten, hab spontan aber keine Ahnung da beide Threads keine Informationen beinhalten die mir genug Informationen liefern um da nicht total blind zu raten.

Cu Selur
Reply
#3
Sorry, ich könnte jetzt das mittlerweile 27 MB große Debug-File schicken (wie findet man sich darin zurecht?).
Mindestens einer der (abgebrochenen) Versuche sollte darin enthalten sein, obwohl ich es zwischendurch einmal gelöscht hatte, um vielleicht selbst einen Durchblick zu bekommen, was da passiert.

Andererseits war meine Remux-Fummelei tatsächlich von Erfolg gekrönt! D.h. das Videofile wurde, nachdem ich es in den MKV-Container gesteckt hatte, anstandslos bis zu Ende codiert  Smile
Also muss das ganze wohl doch etwas mit dem von Virtualdub erzeugtem AVI-Container zu tun haben  Huh

Aber einmal ist keinmal, ich versuche es gleich nochmal.
Kostet zwar auch in der SSD-Ära etwas Zeit diese Lösung bei 200 GB Dateigröße, aber wenn das der Weg sein soll....meinetwegen  Cool

Jedenfalls ist mein erstes Tape endlich fertig! (fehlen nur noch 19 Big Grin )
Und dank der einfachen Einbindung der tollen Deinterlacing-Lösung und des wirklich guten Denoisers unter den gegebenen Umständen in einer ausgezeichneten Qualität.
Hätte ich mit einem anderen Frontend nie so hinbekommen!

Vielen Dank erstmal!
Reply
#4
DebugOutput zippen, dann sollte er klein genug sein, dass man ihn hier Anhängen oder sonst wo hochladen und mir nen Link schicken kann.
wie findet man sich darin zurecht? -> Strg+F Smile

Cu Selur
Reply
#5
Ja, suchen ist das eine...
Wissen, wonach man sucht und (vor allem) interpretieren können, das andere  Big Grin

Wie gesagt, ich habe den AVI-Container im Verdacht.
Dachte ja, nachdem ich den Superindex-Wert erhöht habe (erzählt einem auch niemand freiwillig), dass nun alles funktionieren sollte/würde, aber warum soll auch alles immer so einfach sein?

Habe es mal angehängt...
Reply
#6
Wenn Dich mir die MediaInfo Ausgaben anschaue sehe ich:
  • X:\Aufnahmen\Tape_01_MAGY_from_Laga_asynch.avi hat 735625 frames
  • Q:\!ACHTUNG AUFNAHME!\Tape_02_NEW_CASE_VD64.00.avi hat 732370 frames
  • X:\Aufnahmen\Tape_02_NEW_CASE_VD64.00_MAGY.avi hat 732370 frames
  • O:\Aufnahmen\Tape_02_NEW_CASE_VD64.00_MAGY_TEMP.mkv hat 732370 frames
  • O:\Aufnahmen\Tape_02_NEW_CASE_VD64.00_MAGY.avi hat 732370 frames
  • S:\Done\Tape_01_MAGY_from_Laga_asynch.mkv hat 967223 frames

Schaue ich mir an was encoded wurde, sehe ich:
  • Für S:\Done\Tape_02_NEW_CASE_VD64.00_MAGY.mkv wurde QTGMC im BOB mode verwendet und 1005231 Frames encoded.
    Das sind wenige Frames als erwartet.
  • Für S:\Done\Tape_01_MAGY_from_Laga_asynch.mkv  wurden 967223 Frames encoded, aber ich sehe keine Infos zum Vapoursynth script im DebugOutput, sie sind deinem Löschen des DebugOutputs wohl zum Opfer gefallen.
  • Für S:\Done\Tape_02_NEW_CASE_VD64.00_MAGY_TEMP.mkv wurde QTGMC im BOB mode verwendet und 1464740 encoded, dass passt also.

Das Vapoursynth Skript was bei X:\Aufnahmen\Tape_01_MAGY_from_Laga_asynch.avi verwendet wurde ist:
# Imports
import os
import sys
import ctypes
# Loading Support Files
Dllref = ctypes.windll.LoadLibrary("D:/Tools/Hybrid/64bit/vsfilters/Support/libfftw3-3.dll")
Dllref = ctypes.windll.LoadLibrary("D:/Tools/Hybrid/64bit/vsfilters/Support/libfftw3f-3.dll")
import vapoursynth as vs
# getting Vapoursynth core
core = vs.core
# Import scripts folder
scriptPath = 'D:/Tools/Hybrid/64bit/vsscripts'
sys.path.insert(0, os.path.abspath(scriptPath))
# Loading Plugins
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/SharpenFilter/CAS/CAS.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/DebandFilter/Flash3kDeband/flash3kyuu_deband.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/SharpenFilter/AWarpSharp2/libawarpsharp2.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/Support/TCanny.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/Support/libtemporalmedian.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/Support/vcm.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/GrainFilter/RemoveGrain/RemoveGrainVS.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/GrainFilter/AddGrain/AddGrain.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/DenoiseFilter/NEO_FFT3DFilter/neo-fft3d.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/DenoiseFilter/DFTTest/DFTTest.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/Support/EEDI3m.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/ResizeFilter/nnedi3/NNEDI3CL.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/Support/libmvtools.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/Support/temporalsoften.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/Support/scenechange.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/Support/fmtconv.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/MiscFilter/MiscFilters/MiscFilters.dll")
core.std.LoadPlugin(path="D:/Tools/Hybrid/64bit/vsfilters/SourceFilter/FFMS2/ffms2.dll")
# Import scripts
import mvsfunc
import muvsfunc
import G41Fun
import havsfunc
# source: 'X:\Aufnahmen\Tape_01_MAGY_from_Laga_asynch.avi'
# current color space: RGB24, bit depth: 8, resolution: 720x576, fps: 25, color matrix: 470bg, yuv luminance scale: limited, scanorder: top field first
# Loading source using FFMS2
clip = core.ffms2.Source(source="X:/Aufnahmen/Tape_01_MAGY_from_Laga_asynch.avi",cachefile="D:/TEMP/2022-06-07@20_55_29_1110.ffindex",format=vs.RGB24,alpha=False)
# Setting color range to TV (limited) range.
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=1)
# making sure frame rate is set to 25
clip = core.std.AssumeFPS(clip=clip, fpsnum=25, fpsden=1)
# adjusting color space from RGB24 to YUV444P8 for VsQTGMC
clip = core.resize.Bicubic(clip=clip, format=vs.YUV444P8, matrix_s="470bg", range_s="limited")
# setting field order to what QTGMC should assume (top field first)
clip = core.std.SetFrameProp(clip=clip, prop="_FieldBased", intval=2)
# Deinterlacing using QTGMC
clip = havsfunc.QTGMC(Input=clip, Preset="Faster", TFF=True, opencl=True) # new fps: 50
# make sure content is preceived as frame based
clip = core.std.SetFieldBased(clip, 0)
# cropping the video to 688x552
clip = core.std.CropRel(clip=clip, left=22, right=10, top=8, bottom=16)
# denoising using mClean
clip = G41Fun.mClean(clip=clip, chroma=False, deband=2, strength=7)
# contrast sharpening using CAS
clip = core.cas.CAS(clip=clip, sharpness=0.600)
# adjusting output color from: YUV444P8 to YUV420P8 for x264Model
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P8, range_s="limited")
# set output frame rate to 50.000fps
clip = core.std.AssumeFPS(clip=clip, fpsnum=50, fpsden=1)
# Output
clip.set_output()
und sieht recht normal aus.
Man sieht auch sonst nirgends Fehler.

Meine Vermutung ist, dass das Problem liegt am SourceFilter der verwendet wird.
Da Du .avi als Input hast und falls Du auch 64bit vfw Decoder für das Format im System installiert hast könntest Du mal schauen ob es einen unterschied macht in der angezeigten Frameanzahl  (linke untere Ecke) im Vapoursynth Preview wenn Du "Filtering->Vapoursynth->Misc->Source->Prefer AvisSource for .avi input" aktivierst. Falls dies der Fall ist dann liegt das Problem am verwendeten Sourcefilter (hier ffms2.Source) der nicht mit dem File richtig klar kommt.
Falls das Problem nicht am SourceFilter liegt...
  • und die Quelle auf einem externen Medium liegt, kann eine kurz Unterbrechung der Verbindung dazu führen, dass x264 vorzeitig abbricht ohe das Fehler zu sehen sind.
  • kann ein übereifiger Virenscanner&Co dazu führen, dass kurzzeitig nicht auf die Datei zugegriffen werden kann und x264 vorzeitig abbricht ohe das Fehler zu sehen sind. (Darum schauen, dass Input-, Output- und Temp- und der Hybrid-Ordner nicht extra gescannt werden.)

Cu Selur
Reply
#7
Ich habe jetzt unter "Filtering->Vapoursynth->Misc->Source->Prefer AvisSource for .avi input" den Haken mal gesetzt. Schaden kann es ja nicht.

Das werde ich dann auch mal demnächst ausprobieren, wenn das laufende File, für welches ich wieder den Umweg über den MKV-Container genommen habe, durch ist.
Allerdings GLAUBE ich mich zu erinnern, dass die Frameanzahl, welche unter Preview angezeigt wurde, auch vorher gestimmt hat. Ich konnte ja in der Vorschau auch immer bis zum Ende springen.
Ansonsten lagen die Dateien zufällig wirklich auf einer USB-Platte. Allerdings habe ich im Geräte-Manager und in den Energieeinstellungen alle Einstellungen zum Energiesparen rausgenommen (Computer kann Gerät ausschalten...blabla).


Was den Virenscanner angeht, so habe ich daran auch schon vorher gedacht und den Echtzeitschutz von Windows Sicherheit generell deaktiviert, da ich ja bis gestern mit demselben Computer auch aufgenommen habe. Die Aufnahme habe ich inzwischen auf einen anderen PC verlegt, da Virtualdub (NATÜRLICH) einige meiner Dateioperationen während der Aufnahme nicht gefielen. Da kann man noch so viele Kerne haben  Rolleyes
Echtzeitschutz bleibt trotzdem natürlich erst einmal abgeschaltet.

Wie gesagt, das mit dem AviSource teste ich demnächst und ansonsten weiß ich ja inzwischen DASS es geht und das beflügelt mich  Smile

Vielen Dank bis hierher!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)