Probleme mit Staxrip (HD-TS, DGIndexNV)

Also auf meinem Notebook funzt es ohne...das hat eine NVidia-Karte...

habe mir gerade mal DiAVC bestellt...habe bis jetzt aber noch keine Bestätigunsgmail bekommen...hoffe da ist alles glatt gegangen...

Zitat von MacLeod;400191

Wenn ich DGIndexNV habe, benötige ich dann noch einen Codec wie CoreAVC?

Was hat das eine mit dem anderen zu tun ? DGIndexNV ist prinzipiell für die (GPU-unterstützte) Weiterverarbeitung von H.264/VC1/MPEG2-Video gedacht... CoreAVC ist ein rein für die Wiedergabe konzipierter H.264-Decoder.

OK... beide kann man jeweils für das andere zweckentfremden... und beide nutzen die CUDA Video-API für die Decodierung. Das war's dann aber auch schon mit den Zusammenhängen.

Im Übrigen gibt's ja mit LAV CUVID eine kostenlose Alternative zu CoreAVC:

http://forum.doom9.org/showthread.php?t=160290

... die zudem (neben H.264) die Decodierung von VC-1-, MPEG2- und MPEG4-ASP-Video (XviD/DivX) per GPU beherrscht. Wer also unbedingt DirectShowSource statt DGSource verwenden will, sollte vielleicht besser zum LAV CUVID Decoder greifen - zumindest hinsichtlich der unterstützten Videoformate hat man da eine gleichwertige Alternative. DGSource bietet dafür die höhere Stabilität und Framegenauigkeit (welche mit DirectShowSource unter Umständen nicht gegeben ist).

Versuch doch auch mal die Testversion von Videoredo v4 beta.

http://www.videoredo.net/msgBoard/showthread.php?t=24328

Wenn deine Aufnahmen von Videoredo nicht korrekt erkannt werden, dann melde das dort einfach in deren Board, die kümmern sich dann drum.

Zitat von TomKeller;399945

Ich encode bestimmt seltener was als du. Trotzdem verwende ich dann nicht StaxRip ...

Darf man fragen welches Programm du dafür nutzt?
also für HDTV (.ts) -->Xvid

Größtenteils manuelle Erstellung des AviSynth-Scriptes => anschließendes Encoden über MeGUI als Benutzeroberfläche für x264/xvid_encraw... oder (wenn's nur um XviD geht) Encoden per VirtualDub + XviD-VfW.

Aber bevor der falsche Eindruck entsteht:
Das ist alles NICHT einstiegsfreundlicher als StaxRip - dafür jedoch flexibler.

Hi Tom,
erstmal danke für deine Antwort. Wie "behandelst" du eigentlich 1080i-Material z.B. von SKY oder den HD+Sendern? DeInterlaced du das. Irgendwie gibts da scheinbar verschiedene Meinungen darüber ob das jetzt zwingend erforderlich ist oder hald nicht.

Ich habe weder SKY noch HD+ :p . Aber Filme auf SKY werden doch meines Wissens üblicherweise progressive ausgestrahlt (auch wenn der Videostream interlaced encodet und geflagged wurde). In so einem Fall ist dann auch kein Deinterlacing nötig, da beide Halbbilder den selben Bewegungszustand enthalten...

Also ich muss hier mal was einwerfen. Klar kann Staxrip TS Files nehmen. Gar kein Problem. Wobei es ja auch einfach möglich wäre, TS zu MKV zu muxen.

Und das zu h264 machen ist auch kein Problem. Das was Tom sagt mag so richtig sein, aber er macht auch eine Wissenschaft draus. Ich würde mich da nicht irre machen lassen. Mein das nicht böse aber eine gewisse Fachblindheit haben die Experten gerne mal

Ich würde Interlaced immer Interlaced lassen. Gerade bei Quellen von DVD ist es oft kein Interlaced, sondern Normgewandeltes. Und nicht jeder Deinterlacer taugt was. Das kann man dem TV überlassen.

In Staxrip kommt man unter Config Codec / Commandline

--interlaced

an und es wird Interlaced (MBaff)

Um aus 50p 25p zu machen
selecteven()

Bei Interlaced 50I ist es
Assumetff().SeparateFields().SelectEvery(4, 0, 3).Weave()

für 25I

Und ich rate nicht zu MeGui. Zumindest nicht, wenn man keine Wissenschaft draus machen will. Viel zu kompliziert. Da kann ich ja gleich mit der Commandline anfangen.

Zumindest meine Meinung.

DGIndexNV kann man vergessen. Das bringt in der Praxis nämlich gar nix. Also vom Speed her gesehen. Ist auch gar nicht nötig sondern überflüssig. Keine Funktion von Stax setzt das vorraus.

Wenn man es beschleunigen will dann wohl mit Avisynth MT. Also Multicore Optimiert. Zb ein Multicore Resize von 1080 zu SD kann man damit deutlich beschleunigen. Avisynth ist leider nur Singel Core. Kann dazu gerne helfen.

Und ich habe wohl mehr BD zu MKV gemacht als so mancher hier.

Zitat

ffmpegsource2 versagt auf ganzer Linie bei 1080i Aufnahmen von HD+.

Dazu würde ich auch mehr als nur diesen Satz lesen wollen. Das ist mir zu Pauschal simpel dahingesagt.

Zitat von Koto99;476046

Ich würde Interlaced immer Interlaced lassen.

Dem kann ich schon zustimmen. Aber gleichzeitig würde ich ergänzen:

Zitat

Das gilt allerdings nur, wenn das Quellmaterial interlaced gedreht wurde (z.B. Sport-Übertragungen).

In allen anderen Fällen wäre es besser, wenn versucht wird, den progressiven "Ursprungszustand" (soweit wie möglich) wieder herzustellen.

Ich weise in diesem Zusammenhang nochmals hierauf hin:

http://home.arcor.de/scharfis_brain/ExotischesInterlacing/

Es gilt nämlich grundsätzlich immernoch: manchmal wird progressiv gedrehtes Quellmaterial unnötigerweise bei der PAL-Wandlung zu interlaced Video verwurstet und dann so ausgestrahlt.

Zitat von Koto99;476046

Und nicht jeder Deinterlacer taugt was. Das kann man dem TV überlassen.

Überlässt man diverses "exotisches Interlacing-Material" dem Deinterlacer vom Fernseher, erzeugt der üblicherweise Blendings - also regelmäßig erscheinende Mischbilder aus ursprünglich progressiven Vollbildern (und somit ein leichtes Ruckeln). Solche eingebauten Deinterlacer sind nämlich nicht besonders clever, sondern haben nur ein Ziel: halbwegs brauchbare Vollbilder ausspucken.

Zitat von Koto99;476046

In Staxrip kommt man unter Config Codec / Commandline

--interlaced

an und es wird Interlaced (MBaff)

Welche alte x264-Version benutzt StaxRip denn ? Den Kommandozeilenparameter --interlaced gibt's doch meines Wissens gar nicht mehr - nur noch --bff und --tff...

Zitat von Koto99;476046

Bei Interlaced 50I ist es
Assumetff().SeparateFields().SelectEvery(4, 0, 3).Weave()

für 25I

Wofür braucht man denn 25i? Das sind doch dann 25 Halbbilder je Sekunde verpackt in 12,5fps? Weißt du, was du da machst ?

Zitat von Koto99;476046

Und ich rate nicht zu MeGui. Zumindest nicht, wenn man keine Wissenschaft draus machen will. Viel zu kompliziert. Da kann ich ja gleich mit der Commandline anfangen.

Ich rate auch nicht zu MeGUI - trotzdem übertreibst du. MeGUI bietet ja eine Reihe an Presets an, sowie eine GUI für die x264-Konfigurationen - und das, damit man eben nicht die Kommandozeile komplett eintippen muss.

Zitat von Koto99;476046

DGIndexNV kann man vergessen. Das bringt in der Praxis nämlich gar nix. Also vom Speed her gesehen.

Das ist mir zu pauschal und simpel dahingesagt. Erstmal ist die Decodierungsgeschwindigkeit zum Teil von der Grafikkarte abhängig:

http://forum.doom9.org/showthread.php?t=161948

Aber darum geht es auch weniger, sondern vielmehr darum, die CPU für Filter-Aufgaben und das Encoding "frei zu halten"! Wenn die CPU nämlich schon zu 30%, 50% oder mehr von der Software-Decodierung beansprucht wird, ist ja klar, dass weniger Reserven für Filterung und Encodierung zur Verfügung stehen.

ABER: im Endeffekt hängt es IMMER davon ab, wo der Flaschenhals ist. Wenn z.B. die Filter-Aufgaben nicht Multithreading-optimiert sind, kann es durchaus auch durchaus passieren, dass DGDecNV geschwindigkeitsmäßig rein gar nichts raus reißt. Das sieht man dann aber an der CPU-Auslastung. Wenn sich die CPU beim Encoding teilweise "langweilt" ist das z.B. schonmal kein gutes Zeichen...

Zitat von Koto99;476046

Keine Funktion von Stax setzt das vorraus.

Hat auch keiner behauptet .

Zitat

Es gilt nämlich grundsätzlich immernoch: manchmal wird progressiv gedrehtes Quellmaterial unnötigerweise bei der PAL-Wandlung zu interlaced Video verwurstet und dann so ausgestrahlt.

Überlässt man diverses "exotisches Interlacing-Material" dem Deinterlacer vom Fernseher, erzeugt der üblicherweise Blendings - also regelmäßig erscheinende Mischbilder aus ursprünglich progressiven Vollbildern (und somit ein leichtes Ruckeln). Solche eingebauten Deinterlacer sind nämlich nicht besonders clever, sondern haben nur ein Ziel: halbwegs brauchbare Vollbilder ausspucken.

Ja, aber Du vergisst da was. Du solltes dann für jede Source einen anderen Deinterlacer nehmen. Willst Du das richtig machen. Das ist kaum praktikabel. Ok vielleicht für Didde von Gleitz.
Normwandlungen rückgängig machen ist nicht simpel. Das geht über simples Deinterlacen hinaus.

Zitat

Ich rate auch nicht zu MeGUI - trotzdem übertreibst du. MeGUI bietet ja eine Reihe an Presets an, sowie eine GUI für die x264-Konfigurationen - und das, damit man eben nicht die Kommandozeile komplett eintippen muss.

Ich finde die GUI Furchbar. Nicht die Funktionen die sonden die Anordnung und Gliederung. Dann lieber Selurs Hybrid. Wobei das einfach zu verbuggt ist.

Zitat

Aber darum geht es auch weniger, sondern vielmehr darum, die CPU für Filter-Aufgaben und das Encoding "frei zu halten"! Wenn die CPU nämlich schon zu 30%, 50% oder mehr von der Software-Decodierung beansprucht wird, ist ja klar, dass weniger Reserven für Filterung und Encodierung zur Verfügung stehen.

Also mit einer GF 550 ist die Wirkung = Null mit einem Intel I7 Sandy Bride.

Das Decodieren also der Aufwand wird da vollkommen überschätzt. Zumindest ist da nix zu merken. Hatte das natürlich ausprobiert.

Zitat

Welche alte x264-Version benutzt StaxRip denn ? Den Kommandozeilenparameter --interlaced gibt's doch meines Wissens gar nicht mehr - nur noch --bff und --tff...

Ähm gute frage.
Das höre ich auch zum ersten mal. Habe mal geguckt

x264 core:119 r2106 steht da, wobei ich nun nicht weiß, wie alt die sein mag.

mal geguckt aktuell ist 2208. Also wohl doch ne weile her wenn ich ins Changelog gucke.
Danke für die Hinweis.:-)

Wobe das entfallen von --interlaced steht nicht im Changelog oder ich habs übersehen.

Aber ich lerne natürlich gerne dazu wenn dem so ist. Wobei das –interlaced gut ist. Man muss ja da nicht erst wissen ob TFF oder BFF vorliegt.

Zitat

Wofür braucht man denn 25i? Das sind doch dann 25 Halbbilder je Sekunde verpackt in 12,5fps? Weißt du, was du da machst

Das bezieht sich auf Pal Kompatibilität. Wobei das eh nur Theoretisch ist.

Zitat von Koto99;476119

Ja, aber Du vergisst da was. Du solltes dann für jede Source einen anderen Deinterlacer nehmen. Willst Du das richtig machen. Das ist kaum praktikabel.

Videoencoding ist nunmal grundsätzlich ein komplexes Thema. Und darum gibt's halt auch im wesentlichen die zwei Ansätze:

• entweder wählt man den einfacheren, generischen Lösungsweg, der auch gerne mal bei "Problemmaterial" versagt... oder
• man wählt den komplizierteren Weg mit viel manuellem Finetuning um auch für bestimmte Härtefälle gefeit zu sein... wobei der dann aber deutlich mehr Einarbeitungsszeit verlangt

Beide haben ihre Daseinsberechtigung. Aber jeder sollte für sich selbst entscheiden, welchen er wählt.

Mir blutet halt immer (sprichwörtlich :p ) das Herz, wenn ich TV- oder DVD-Rips sehe (z.B. der DVB-Rip der Serie "Raven"... oder der DVD-Rip von "Viper") wo auf alle 12 progressiven Frames 12 "blended" Frames folgen, weil die Verantwortlichen schon bei der Produktion Mist gebaut haben und beim Reencoding nichts dagegen unternommen wurde. Ich finde das Ansehen dann deutlich unangenehmer (vor allem bei Kameraschwenks) - andere stören sich aber weniger oder gar nicht daran.

Zitat von Koto99;476119

Ich finde die GUI Furchbar. Nicht die Funktionen die sonden die Anordnung und Gliederung. Dann lieber Selurs Hybrid. Wobei das einfach zu verbuggt ist.

Und StaxRip besteht zu einem Großteil auf die mitgelieferten Versionen seiner benötigten Tools - das hat mich beim ersten Ausprobieren am meisten daran gestört, weshalb ich's wieder gelöscht hatte.

MeGUI ist sicher gewöhnungsbedürftig und wohl auch etwas unlogisch aufgebaut - aber das ist auch schon das Schlimmste daran. Da gibt es wesentlich "grausamere" Beispiele für schlecht gegliederte GUIs (z.B. SUPER)...

Zitat von Koto99;476119

Also mit einer GF 550 ist die Wirkung = Null mit einem Intel I7 Sandy Bride.

Bei einem Vergleich womit(?) und mit was für einer CPU-Auslastung in beiden Fällen?? Denn wie gesagt: wenn der Flaschenhals woanders liegt, macht der Decoder auch keinen Unterschied.

Zitat von Koto99;476119

Aber ich lerne natürlich gerne dazu wenn dem so ist. Wobei das –interlaced gut ist. Man muss ja da nicht erst wissen ob TFF oder BFF vorliegt.

Eigentlich ist --interlaced eher schlecht. X264 sollte nämlich zwingend die Field-Order mitgeteilt werden. Wird die falsch angegeben, stimmt nämlich die Bildreihenfolge nach dem Deinterlacing nicht mehr - die Wiedergabe ist dadurch zuckend.

Keine Ahnung, wie das x264 bei --interlaced gehandhabt hat - wahrscheinlich hat es einfach die Field-Order übernommen, die AviSynth geliefert hat. Aber AviSynth kann damit auch falsch liegen (wenn z.B. beim Quellmaterial die Field-Order schon falsch ist... oder man aus Unwissenheit eine falsche manuelle Angabe dazu im Script macht). Deshalb macht die Unterteilung in --tff und --bff durchaus mehr Sinn als --interlaced.

Zitat von Koto99;476119

Das bezieht sich auf Pal Kompatibilität.

Seit wann sind 12,5fps PAL-konform ?

Zitat

Und StaxRip besteht zu einem Großteil auf die mitgelieferten Versionen seiner benötigten Tools - das hat mich beim ersten Ausprobieren am meisten daran gestört, weshalb ich's wieder gelöscht hatte.

Hm, das viel mir noch nicht auf. Die x264..exe zb hatte ich ohne Probleme tauschen können. Wobei ich auch jemand bin „Never Chance a Running System“

Super uarg. Schon die Webseite und die ganze Adware. NEIN DANKE. Wobei ich nicht mal weiß, ob das auf Avisynth basiert. Das Teil war schon beim Runterladen ein NO GO

Zitat

Bei einem Vergleich womit(?) und mit was für einer CPU-Auslastung in beiden Fällen?? Denn wie gesagt: wenn der Flaschenhals woanders liegt, macht der Decoder auch keinen Unterschied.

Beispiel:
LoadPlugin("D:\Tools\DVD Tools\FFmpegSource2\ffmpeg-mt\ffms2.dll")
LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\DGDecNV\DGDecodeNV.dll")

FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv")
#DGSource("C:\iND-nordsee.1080p.dgi", resize_w=1024, resize_h=576)

Macht keinen Unterschied. 99-95% CPU last auf der x264 exe jeweils. Present Slow.

Natürlich habe ich bei FFVideoSource Stax auch so Resizen lassen.

Nun sagst Du bestimmt CPU zu schwach da schon bei 95%. Nur wenn ich das Resize DGDecNV überlasse also der GPU, wird die CPU nicht entlastet. Welche CPU soll man den da haben für eine Wirkung?

Wobei ich das eh nicht verstehe. Nun sagen wir mal das Resize von 1080p auf 1024x576 kostet 10% CPU Power. Dann müsste ich ja eine Wirkung haben. Wenn auch klein.

Existiert den eine CPU, die das bringt?
Habe einen Intel I7 2630 QM CPU Generation 2.

Es ist ja dann auch sinnfrei, wenn ich einen I9 64 Core und 20 HT brauche.

Und Flaschenhals. Das ändert ja am Ergebnis nix. Wenn man das in der Praxis quasi nie zum Vorteil bekommt, weil man immer einen Flaschenhals hat, dann bekommt man einen Hals. Und hat Geld umsonst ausgegeben.

Von Theoretischen vorteilen hat keiner was.

Zitat

Eigentlich ist --interlaced eher schlecht. X264 sollte nämlich zwingend die Field-Order mitgeteilt werden. Wird die falsch angegeben, stimmt nämlich die Bildreihenfolge nach dem Deinterlacing nicht mehr - die Wiedergabe ist dadurch zuckend.

Keine Ahnung, wie das x264 bei --interlaced gehandhabt hat - wahrscheinlich hat es einfach die Field-Order übernommen, die AviSynth geliefert hat. Aber AviSynth kann damit auch falsch liegen (wenn z.B. beim Quellmaterial die Field-Order schon falsch ist... oder man aus Unwissenheit eine falsche manuelle Angabe dazu im Script macht). Deshalb macht die Unterteilung in --tff und --bff durchaus mehr Sinn als --interlaced.

Das ist das klassische Beispiel für etwas zu Wissenschaft machen.:-)
Man hat eine Quelle die läuft sauber. Also –interlaced. Also so lassen, wie sie ist.

Für TTF muss ich die Field Order ermitteln. Es wäre nur falsch, wenn die Source schon ruckelt.

Deine Methode führt nur zu mehr Arbeit.

Wobei ich nun nicht genau weiß, wie Stax es ermittelt. Ich weiß nur der verhaut es nicht. Da sind schon einige Serien durchgelaufen.

Ich habe das probiert, offenbar ist die –interlaced Option nicht raus. Es geht wohl beides. Field Order angeben oder eben nicht. Ich würde auch lieber die alte EXE nehmen als erst anfangen Field Orders zu ermitteln

Ich bin ein Freund von Same als Source. Zumindest wenn man keine Wissenschaft draus machen will. Defaktor ist das so, das man dann für 1% der Sourcen immer alles ermittelt.

Ok, eine einschränkung. Kommt auf das Material an. Wenn man natürlich oft Material nimmt das jemand schon mal Enkodiert hat, mag das was anderes sein. Wobei man mit One Click Tools auch selten die Field verhaut.:-)

Und ich weiß Du bis Perfektionist.
Bei dem Aufwand würde ich aber schnell Irre.

Beispiel: Star Trek TNG DVDs.

Übles Normgewandel.
Beim Deinterlacen hat man Geisterbilder und Ruckeln. Da einen Deinterlacer zu finden bzw diese Normwandlung rückgängig zu machen ist sehr viel Arbeit. Erst mal ein Script finden.

--Interlaced und sie sehen so aus wie auf DVD.

Klar Du sagts sind übel, aber ich will dann eben nicht ewig rummachen. Die DVDs sind auszuhalten.

Das meine ich auch mit Aufwand. Man kann das wirklich bis zum exzess treiben. Lieber mache ich nun davon BD zu SD MKV.

Ich nehme auch an, der Thread ersteller will es erst mal einfach. Man kann dann ja immer noch tiefer in die Materie einsteigen. Am anfang ist das sonst nur verwirrend. Wer nicht weiß was TFF & BFF ist muss es erst mal auch nicht wissen.

--interlaced und gibt es stress melden.

Wobei wir nun auch Offtoppic sind

Zitat von Koto99;476162

Hm, das viel mir noch nicht auf. Die x264..exe zb hatte ich ohne Probleme tauschen können. Wobei ich auch jemand bin „Never Chance a Running System“

X264 war auch weniger das Problem als vielmehr XviD. Zudem mochte StaxRip aus irgendeinem Grund ffdshow nicht als Decoder für unkomprimiertes YV12-Videomaterial. Also hab ich's wieder runter geschmissen...

Zitat von Koto99;476162

Beispiel:
LoadPlugin("D:\Tools\DVD Tools\FFmpegSource2\ffmpeg-mt\ffms2.dll")
LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\DGDecNV\DGDecodeNV.dll")

FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv")
#DGSource("C:\iND-nordsee.1080p.dgi", resize_w=1024, resize_h=576)

Macht keinen Unterschied. 99-95% CPU last auf der x264 exe jeweils. Present Slow.

Natürlich habe ich bei FFVideoSource Stax auch so Resizen lassen.

Nun sagst Du bestimmt CPU zu schwach da schon bei 95%. Nur wenn ich das Resize DGDecNV überlasse also der GPU, wird die CPU nicht entlastet. Welche CPU soll man den da haben für eine Wirkung?

Wobei ich das eh nicht verstehe. Nun sagen wir mal das Resize von 1080p auf 1024x576 kostet 10% CPU Power. Dann müsste ich ja eine Wirkung haben. Wenn auch klein.

Existiert den eine CPU, die das bringt?
Habe einen Intel I7 2630 QM CPU Generation 2.

Es ist ja dann auch sinnfrei, wenn ich einen I9 64 Core und 20 HT brauche.

Und Flaschenhals. Das ändert ja am Ergebnis nix. Wenn man das in der Praxis quasi nie zum Vorteil bekommt, weil man immer einen Flaschenhals hat, dann bekommt man einen Hals. Und hat Geld umsonst ausgegeben.

Alles anzeigen

Erinnert mich irgendwie hieran:

http://forum.gleitz.info/showt…9-DGDecNV-Joke-oder-nicht

Zitat von Koto99;476162

Von Theoretischen vorteilen hat keiner was.

Ich weiß aber mit Sicherheit, dass DGDecNV bei meinem letzten HD2DVD-Encode deutlich schneller als FFMS2 lief.
Mein langsamer Dual-Core ist allerdings auch nicht der schnellste. Kann sein, dass sich der Geschwindigkeitsunterschied auf aktuelleren CPUs mit 4 und mehr Kernen wieder relativiert, da ja bei denen auch der Systembus schneller geworden ist... während bei DGDecNV grundsätzlich die komprimierten bzw. unkomprimierten Videodaten über den langsameren PCIe-Bus zwischen Grafikkarte und RAM hin und her geschoben werden müssen.

Gerade habe ich übrigens wieder feststellen müssen, dass DGDecNV zumindest einen Vorteil gegenüber FFMS2 hat: es arbeitet fehlerfreier. FFMS2 hat scheinbar immernoch Probleme mit (M2)TS-Dateien... bei der gerade getesteten MKV-Datei lag die Gesamtframeanzahl um 18 Frames daneben... und hin und her springen in einem geladenen Script sollte man sowieso nicht. Ich dachte zuerst, dass es an einer zu alten Version läge - aber es ist tatsächlich die aktuellste verfügbare r683 . Dafür bietet FFMS2 eine deutlich breitere Formatunterstützung...

Zitat von Koto99;476162

Das ist das klassische Beispiel für etwas zu Wissenschaft machen.:-)
Man hat eine Quelle die läuft sauber. Also –interlaced. Also so lassen, wie sie ist.

Für TTF muss ich die Field Order ermitteln. Es wäre nur falsch, wenn die Source schon ruckelt.

Deine Methode führt nur zu mehr Arbeit.

Wieso "meine Methode"? Ich hab ja die Parameter --tff und --bff nicht eingeführt :p .

Zitat von Koto99;476162

Ich bin ein Freund von Same als Source. Zumindest wenn man keine Wissenschaft draus machen will. Defaktor ist das so, das man dann für 1% der Sourcen immer alles ermittelt.

Und ich bin dafür, dass jemand auch weiß, WARUM er genau WAS machen soll - sonst kommen Leute nämlich gerne wieder direkt zu einem angerannt und fragen nach, wenn sich irgendwas mal "falsch" verhält (und dafür bin ich zu faul). Sowas passiert einfach seltener, wenn auch die Bedeutung und Funktion von Script-Befehlen und Kommandozeilenparametern bekannt ist...

Zitat von Koto99;476162

Und ich weiß Du bis Perfektionist.

Keine Ahnung, woher das Gerücht kommt... aber: nö.

Zitat von Koto99;476162

Bei dem Aufwand würde ich aber schnell Irre.

Und gerade das täuscht. HQ-Deinterlacer wie z.B. QTGMC kommen jetzt schon mit Presets daher. Und auch Restore24 oder SRestore sind nicht so schwer zu bedienen, da im Idealfall die Standard-Vorgaben ausreichen. Tun sie das mal NICHT, dann ist üblicherweise sowieso ein Experte nötig... wie z.B. bei:

Zitat von Koto99;476162

Star Trek TNG DVDs.

Übles Normgewandel.
Beim Deinterlacen hat man Geisterbilder und Ruckeln. Da einen Deinterlacer zu finden bzw diese Normwandlung rückgängig zu machen ist sehr viel Arbeit. Erst mal ein Script finden.

... was aber gerade bei "Star Trek" weniger ein Problem ist:

http://forum.gleitz.info/showt…taffel-1%29-Deinterlacing

Doch jetzt gibt's da ja Gottseidank die ersten Blu-ray-Rips .

Zitat von Koto99;476162

--Interlaced und sie sehen so aus wie auf DVD.

Es sei denn, es kommt noch Resizing in's Spiel :p - was ja nicht selten der Fall ist.

Zitat

Gerade habe ich übrigens wieder feststellen müssen, dass DGDecNV zumindest einen Vorteil gegenüber FFMS2 hat: es arbeitet fehlerfreier. FFMS2 hat scheinbar immernoch Probleme mit (M2)TS-Dateien... bei der gerade getesteten MKV-Datei lag die Gesamtframeanzahl um 18 Frames daneben... und hin und her springen in einem geladenen Script sollte man sowieso nicht. Ich dachte zuerst, dass es an einer zu alten Version läge - aber es ist tatsächlich die aktuellste verfügbare r683 . Dafür bietet FFMS2 eine deutlich breitere Formatunterstützung...

Ich muss zugeben ich nehme nur VOBs oder MKVs als Source. Ob Frames fehlen, kann ich nicht sagen. Ich habe es nicht gemerkt. Wenn es am ende ist, wäre es ja egal.

Normal müssten man 18 Frames ja irgendwie merken oder es ist bei MKV als Source nicht so?
Man kann es ja ummuxen.

Zitat

Ich weiß aber mit Sicherheit, dass DGDecNV bei meinem letzten HD2DVD-Encode deutlich schneller als FFMS2 lief.

Bei meiner letzen HD2DVD habe ich gemerkt das Resize kam nicht hinterher. Die CPU hatte sich gelangweilt. Da half dann Avisynth MT. Ok, DGDecNV hätte ich da mal versuchen können das stimmt. Vielleicht teste ich das mal aus.

Bin mal gespannt ob DGDecNV mehr bringt als MT Resize. Das DGDecNV kostet ja immerhin Geld. Finde schon das muss sich in der Praxis bewähren wenn man Geld will.

Wobei Stacrip DGDecNV auch nicht nimmt. Habe das nie hinbekommen. Findet er auch nie. Habe nie eine Hinweis gefunden in welchem Path das liegen soll das er das Automatisch verwendet. Bei DGScource bekommt ich nur keine Funktion DGSource. Den Path angeben halt nix.

Zitat

Und ich bin dafür, dass jemand auch weiß, WARUM er genau WAS machen soll - sonst kommen Leute nämlich gerne wieder direkt zu einem angerannt und fragen nach, wenn sich irgendwas mal "falsch" verhält (und dafür bin ich zu faul). Sowas passiert einfach seltener, wenn auch die Bedeutung und Funktion von Script-Befehlen und Kommandozeilenparametern bekannt ist...

Damit verschreckt man aber auch viele. Ok, dann hast Du deine Ruhe das stimmt.

Zitat

Und auch Restore24 oder SRestore sind nicht so schwer zu bedienen

90% bekommen das Script nicht mal ans Laufen. Weil keiner aber auch keiner angibt, welche DLLs dazugehören. Alle Avisynth Scripter sind chronisch betriebsblind.

Und ich finde es dann übertrieben immer in die Foren zu gehen. Auf dauer ist das nix.

Übrigens. Never Change a Running System.

Beispiel:
Ich habe einen Patriot Box Office Mediaplayer mit Firmware v2. Der kann das Forced Flag bei MKV Streams auslesen. Was die Realtek Player mit neuen Firmware nicht mehr können.

Mein Fazit Never Change a Running System.

Beispiel 2
Das Lustige ist, das geht auch nur bis MKVMerge 3.4.0 mit neueren MKVMerge zeigt der Player gar keine Untertitel mehr.

Die Frage ist nun, warum brauche ich eine neue Firmware, die Funktionen weniger hat und neue MKVMerge die eigentlich nix besser machen?

Klar Bugfixes aber keines der Bugs habe ich je bemerkt, während die neuen Versionen nix als ärger machen. Fazit: Never Change a Running System.
Das ist wie die Header Kompression. Die zu nix weiter nütze ist als das die Files inkompatibel werden. Fazit Never Change a Running System.

Übrigens habe mich wohl geirrt. Die neue x264.exe wirft im Log doch eine Fehlermeldung aus. Es scheint zwar MBAFF zu sein aber, da bin ich unsicher. Bin ich wieder auf meine alte aber erprobte x264.exe.

Never Change a Running System.

Oder anders. Wenn ein System stabil läuft, ist es veraltet. Jo dann ist das eben so.

@Ben_Siko

Danke das wusste ich nicht. Guter Tipp.

Ich habe nun mal etwas Probiert.

Schau mal.
Nochmal als vergleich

x264 Present Slow, Tune Film, CRF 18

LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\DGDecNV\DGDecodeNV.dll")
DGSource("C:\iND-nordsee.1080p.dgi",deinterlace=0,resize_w=720,resize_h=576)

25 FPS
----------------------------------------------
LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\AviSynth plugins\ffms2\ffms2.dll")
FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv", cachefile="E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p temp files\iND-nordsee.1080p.ffindex")
BicubicResize(720,576)

25 FPS
----------------------------------------------
LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\AviSynth plugins\ffms2\ffms2.dll")
SetMTmode(5,6)
SetMemoryMax(512)
FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv", cachefile="E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p temp files\iND-nordsee.1080p.ffindex")

mt("BicubicResize(720,last.height)")
mt("BicubicResize(last.width,576)",splitvertical=true)

34 FPS
----------------------------------------------
HC Enkoder
LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\DGDecNV\DGDecodeNV.dll")
DGSource("C:\iND-nordsee.1080p.dgi",deinterlace=0,resize_w=720,resize_h=576)

AVG FPS 80
----------------------------------------------

LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\AviSynth plugins\ffms2\ffms2.dll")
FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv", cachefile="E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p temp files\iND-nordsee.1080p.ffindex")
BicubicResize(720,576)

AVG FPS 80
----------------------------------------------

LoadPlugin("D:\Tools\DVD Tools\StaxRip\Applications\AviSynth plugins\ffms2\ffms2.dll")
SetMTmode(5,6)
SetMemoryMax(512)
FFVideoSource("E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p.mkv", cachefile="E:\Downloads\Die.Nordsee.von.oben\iND-nordsee.1080p temp files\iND-nordsee.1080p.ffindex")

mt("BicubicResize(720,last.height)")
mt("BicubicResize(last.width,576)",splitvertical=true)

AVG FPS 110

Gerundet die Werte. Bis 0.5 abgerundet ab 0.5 auf.

In anbetracht das Avisynth MT ja umsonst zu haben ist ne klare Sache.
Gforce 550M Dell XPS 17 2 Generation. 8 Gig Ram.

@koto.. Kein Ding...;)

Generell...

Ich wollt nur mal am rande bemerken, ich hab mir das DG-NV Paket auch zu meinem Stax installiert und ich merke da schon nen erheblichen Unterschied beim öffnen der Source...

Also mit dem Standardkram, der bei Stax dabei ist, dauert es so 1-1,5 Minuten, mit dem NV nur 10-20 Sekunden, nach anklicken der Source... bis das Stax-Hauptfenser wieder da ist und ich Croppen/Schneiden kann...

Ich wünschte, ich könnt meine Graka auch zum Encoden benutzen, denn mein kleiner Dual Core hat anscheinend alle Hände voll zu tun, schon mit diesem einfachereren tätigkeiten am anfang, möchte nicht wissen was mir das im 2-pass xvid an Zeit sparen könnte...

gruß
ben

Zitat von Koto99;476180

Ich muss zugeben ich nehme nur VOBs oder MKVs als Source. Ob Frames fehlen, kann ich nicht sagen. Ich habe es nicht gemerkt. Wenn es am ende ist, wäre es ja egal.

Mit FFMS2 gab es offenbar 18 (Schwarz-)Frames mehr am Ende. Also: nicht schlimm... aber schon irgendwie merkwürdig.

Zitat von Koto99;476180

Bin mal gespannt ob DGDecNV mehr bringt als MT Resize. Das DGDecNV kostet ja immerhin Geld. Finde schon das muss sich in der Praxis bewähren wenn man Geld will.

Kann ich nachvollziehen. Als ich DGDecNV gekauft habe (ja... habe ich tatsächlich), steckte FFMS2 noch in den Kinderschuhen und DGAVCDec war gerade eingestampft worden - Source-Filter-Alternativen für AviSynth waren dementsprechend rar.

Zitat von Koto99;476180

Wobei Stacrip DGDecNV auch nicht nimmt. Habe das nie hinbekommen. Findet er auch nie. Habe nie eine Hinweis gefunden in welchem Path das liegen soll das er das Automatisch verwendet. Bei DGScource bekommt ich nur keine Funktion DGSource. Den Path angeben halt nix.

Würde gerne helfen - aber da ich StaxRip nicht benutze...

Zitat von Koto99;476180

Damit verschreckt man aber auch viele. Ok, dann hast Du deine Ruhe das stimmt.

Ach... wieso denn? Für jeden, der ein Thema seitenweise breit tritt, gibt es einen anderen, der die einfachste Alternative vorschlägt. Das gleicht sich schon aus :p .

Zitat von Koto99;476180

90% bekommen das Script nicht mal ans Laufen. Weil keiner aber auch keiner angibt, welche DLLs dazugehören. Alle Avisynth Scripter sind chronisch betriebsblind.

Das liegt weniger an den Scriptern, sondern vielmehr daran, dass es von vielen Plugins inkompatible Funktionen gibt. Oft musst du eine ganz bestimmte Version eines ganz bestimmten Plugins besitzen, weil nachfolgende Versionen eine bestimmte Funktion nicht mehr besitzen.

Dank AviSynth-MediaWiki ist es allerdings einfacher geworden, da dort (nicht nur die Plugins, sondern auch) viele Scripte erklärt werden und die für die Scripte benötigten Plugins gleich mit verlinkt sind. Bei Restore24 beschränkt man sich leider nur auf ein paar Links:

http://avisynth.org/mediawiki/Restore24

... aber SRestore ist schön und ausführlich erläutert:

http://avisynth.org/mediawiki/Srestore

Zitat von Koto99;476180

Übrigens. Never Change a Running System.

Wem sagst du das(?): ich wollte früher nie von Win XP SP2 zu SP3 wechseln und wurde dafür ständig ausgelacht. Nachdem ich mich doch durchgerungen hatte, musste ich feststellen, dass die Treiber für den Festplattencontroller im AHCI-Modus nicht unter SP3 laufen wollten und ich die Festplatten somit im IDE-Modus betreiben musste. Soviel dazu :p ...

Zitat von Koto99;476180

Die Frage ist nun, warum brauche ich eine neue Firmware, die Funktionen weniger hat und neue MKVMerge die eigentlich nix besser machen?

Klar Bugfixes aber keines der Bugs habe ich je bemerkt, während die neuen Versionen nix als ärger machen.

Naja - zumindest kann man mit neueren Versionen MKVMerge auch M2TS-Dateien direkt laden und HD-Tonspuren in MKV muxen. Kann aber sein, dass das schon mit der 3.4.0 ging...

ben_sisko

Aber Geld ausgeben nur fürs Öffnen?
Wobei meine Test oben
http://board.serienjunkies.org…php?p=476184&postcount=36

ja nix ergeben wie man das erklären will.

Probiere morgen mal Build 2040. Wobei ich nicht glaube das, da viel rauskommt bei.

Edit: Wie ich dachte genauso wirklungslos die Build 2040. Das einzige was hilft ist MT

Tom
Das problem ist das Script muss man verstehen um zu wissen welche DLLs man braucht. Das kann man aber auch nur nachvollziehen wenn man nicht zu den Experten gehört.

@koto...

Ja, also man darf das "erheblich" jetzt halt wirklich nur im Kontext zu dem Zeitrahmen sehen, den ich genannt habe, natürlich ist ne ersparnis von ner Minute insgesamt betrachtet nicht wirklich erheblich, aber da es mir die Zeit verkürzt, bis ich letztendlich zum encoden komme, nehm ich das natürlich gerne mit...

Und ... joar... Geld für ausgeben ... .... .... ... :p

Ich kann ja mal gucken demnächst, wo da die Zeitersparnis tatsache genau herkommt bei mir, so genau kann ich es garnicht sagen, ich bin mir nichtmal 100% sicher, das es über/wegen der GraKa wirklich schneller läuft.... aber sie ist halt da, die Minute... oder eben halt nicht mehr da

gruß
ben