Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenhttp://killerinstinct.ath.cx:2…P4Box%20GUI%20v0.6.0.6.7z
Ummuxen statt umencodieren 
[lexicon]MKV[/lexicon] ist ja nurn [lexicon]Container[/lexicon]. Deswegen den darin enthaltenen Video- und Audiostream neu zu encodieren ist ja für ein bloßen Containerwechsel absolut unnötig. Und AVI ist sowieso kein geeigneter [lexicon]Container[/lexicon] für [lexicon]H.264[/lexicon] und wird bei Vegas neue Probleme bereiten.
Nur 1 [lexicon]Frame[/lexicon].
Aber selbst wenns 2 wären, der performancegewinn wäre quasi im nanosekundenbereich. Bei 30 frames gehts nahezu gleich schnell wie mit dem einen.
Das Script soll ja auch nur sein Zweck erfüllen^^
Eig. macht das Script doch nur einen Frame? Ist aber auch eh egal, da der performancegewinn wohl im nanosekundenbereich wär xD
Das es nicht einlesbar war, lag an einem falschen Pfad im Script oder er hat versehentlich die PNG in [lexicon]MeGUI[/lexicon] geöffnet statt das Script. Aber höchstwahrscheinlich erstres der Fall.
Er will nurn Thumbnail skalieren und das geht mit dem Script so einwandfrei. Da brauch ich keine mehreren Frames.
ImageReader liest das Bild ein und skaliert es und imagewriter schreibt es.
Nutze ich so für meine Skalierung der Thumbnails.
Force [lexicon]CPU[/lexicon] allerdings nicht anhaken, und dafür stattdessen [lexicon]Synchronous Surface Lock[/lexicon] und [lexicon]Wait for available Buffer[/lexicon] anhaken.
Ist deine [lexicon]HDD[/lexicon] nicht eh leistungsfähig genug?
Sonst nimm doch FFDShow: Uncompressed @ YV12.
Dieses wird auch von DirectShow (AVISource) korrekt in YV12 ausgegeben und nicht auf RGB32 gewandelt.
Scriptinhalt und Preset ist eine Differenz.
Warum lädst du FFMPEGSource2 doppelt?
In die Presets gehört nichts was Bestandteil fürs Laden von Inputs ist.
Ergo kein AVISource, ergo kein FFVideoSource, ergo kein FFMS2 laden.
Dafür ist <input> zuständig.
Zitatleider keine mkv und es "ploppte" 1-2 mal das Fenster auf, welches erscheint, wenn man das Video ladet, und dann die Preview und das script speichern kann..
Nach dem idx job landest zurück im Script Creator und kannst das script speichern. ja.
Und dann kannste queuen und normal encoden wie auch bei avisource.
Du bekommst am Ende eine stinknormale [lexicon]MKV[/lexicon] wie immer raus.
die .ffindex dient nur für den Decode deiner Quelldatei (deine AVI).
ja mit dem Automatisch genommen, habe ich mich wohl etwas falsch ausgedrückt, was ich damit sagen wollte das ich es automatisch nehme, aufgrund von den vorhandenen optionen,
und es macht nichts, dass die Dateiendung so komisch aus aussieht? - *.avi.ffindex -
Die .ffindex ist das Resultat des indexing (idx) jobs.
Diese Datei enthält die Infos wo in der zu decodierenden Videodatei die Keyframes liegen und evtl noch paar andere Infos.
Statt AVISource den File Indexer Button benutzen, queue drücken, den idx job machen lassen. Dann ganz normal fortfahren.
AVISource sollte nicht automatisch genommen werden. Die Auswahl mit den 3 Buttons solltest du per Tools -> [lexicon]AVS Script Creator[/lexicon] -> Video Input immer bekommen. Wäre arg seltsam wenn nicht.
ist mir aber ein klein wenig zu umständlich.
Warum ist das umständlich xD
Mein Gott 
Das Ruckeln sollte extrem heftig sein mit Haali. Ergo ungenießbar.
Gut nicht abspielbar ist vllt das falsche Wort, aber vor hakeligkeit nicht ansehbar ist auch kein Vergnügen.
[lexicon]Lagarith[/lexicon] kann mit Haali nicht abgespielt werden, korrekt. Benutze dafür EVR (custom presenter).
Also vorsicht mit [lexicon]FLAC[/lexicon]. Dadurch enstehen nämlich auf Youtube die extremen Tonverschiebungen mit [lexicon]FLAC[/lexicon]. Zur Not auf [lexicon]WAV[/lexicon] wechseln.
Wenn die Tonspuren nicht einheitlich sind kann youtube auch bei [lexicon]PCM[/lexicon] asynchron werden, wie ich schon bemerkt hatte.
FFDShow Uncompressed YV12 wird jedoch einwandfrei eingelesen - auch wenn [lexicon]DXTory[/lexicon] den Header geschrieben hat.
Im Übrigen klappt das einlesen mit FFVideoSource einwandfrei auch mit [lexicon]Lagarith[/lexicon]. 
Anscheinend auch bei [lexicon]Lossless[/lexicon] Codecs wohl besser kein DirectShow zu nehmen
Kannst du in die Tonne treten, so leids mir tut 
Anderen [lexicon]Codec[/lexicon] nehmen, am besten ohne Kompression.
Bei UT Video geht auch schon weniger verloren (so ca 20sek oder so (aber ja auch nich so wenig^^) )
Jap hängt vom [lexicon]Codec[/lexicon] ab.
Problematisch sind immer Codecs, welche Kompression anwenden.
Beispielsweise ist FFDShow: Uncompressed perfekt wieder rückholbar.
Vllt solltest du noch einbringen, das Verlustformate nicht mit DirectShow geladen werden sollten, sondern eher mit FFMPEGSource (File index + FFVideoSource)
Zum einen unterstützt es sehr viel mehr Codecs, zum anderen umgeht man damit systeminstallierte decoder/filter, und es hat frameexaktes seeking, was directshowsource nicht hinkriegt.
[lexicon]Lossy[/lexicon] Formate also auf jeden Fall immer per FFVideoSource einlesen.
__
DirectShowSource sollte eig. von Haus aus existieren. Wundert mich gerad, das du da extra noch die dll laden musst.
