MPEG2Source vs. DirectShowSource

Die Direct Show Decoder machen in der Regel ein Farbraumupsampling, deinterlacen automatisch und besch..... - falls das interlaced Flag gesetzt ist und verändern noch zusätzlich (zur Farbraukonvertierung) die Helligkeit + Farbsättigung. Außerdem übermittelten sie die korrekte Framezahl meist nicht korrekt, was zu Asynchronität führen kann.
Wer weiß, was die Dinger noch für Mist produzieren.

Zitat

Ist es tats. empfehlenswert aus der MPG-Datei zuerst den Video-Teil (*.MPV) zu demuxen, dieses in DVD2AVI zu öffnen (*.MPG kann man ja m.W. nicht direkt in DVD2AVI öffnen) u. ein D2V zu erstellen welches man dann mit MPEG2Source öffnen kann? Steht der Aufwand wirklich dafür und falls ja warum?

Mal was von der Auswahl "All files" beim Dateityp gehört ;)? DVD2AVI kann *.mpg Dateien öffnen, sofern der Videostream MPEG-2 ist. Des weiteren ist DVD2AVI veraltet, Stand der Dinge ist DGIndex, wenn man keine Frames verlieren will.

wobei ich es je nach verwendeten Decoder durchaus nicht so schlimm mit schlechtem Deinterlacing etc. ist, aber prinzipiell ist mpeg2source&dvd2avi zu bevorzugen.

Cu Selur

Das Problem bei DirectShowSource ist halt, dass man wissen muss, welcher Decoder überhaupt benutzt wird, um optimale Ergebnisse zu erzielen.
Bei Videos, die progressiv sind, kann es sogar besser sein, DirectShowSource zu benutzen, wenn man Bitrate sparen will - aber wie gesagt: Das ist abhängig vom Decoder.
Wer in erster Linie an Qualität interessiert ist, sollte nach Möglichkeit immer MPEG2Source benutzen. Der kurze Durchgang mit DVD2AVI hält ja nun wirklich kaum auf.

Zitat von Kika

Das Problem bei DirectShowSource ist halt, dass man wissen muss, welcher Decoder überhaupt benutzt wird, um optimale Ergebnisse zu erzielen.

Wenn ich ein MPEG-2 Video habe und habe PowerDVD (einzigster MPEG2-Decoder) installiert, dann müsste doch dieser Decoder durch DirectShowSource benutzt werden?

Nein,

PowerDVD erzeugt einen Programmstream, welchen du mit DGindex oder DVD2AVI öffnest, das video als d2v projekt sicherst und zugleich dein mp2 sound demuxed wird.
Also Vorgang wie bei einer VOB.

@ Kika
Ich bin seit ein paar wochen FFdshow am austesten (wenns richtig eingestellt ist, dann ist ffdshow eine kleine Love-Machine), der interne mpeg2 decoder (libavcodec) ist ja currently broken, was mich wundert, da die mplayerlib.dll bei Mencoder ohne Probleme VOBs Mpeg2s direkt in mpeg4/mpeg2 convertiert.
Die Unterschiede, was Helligkeit/Kontrast etc. angeht ist sind bei Libavcodec-based decoding und bei d2v-avs-mpeg2 nicht zu erkennen. Selbst via Subtract() kontrolle. Und ffdshow mpeg2 decoding wird die selben OpenSource routinen nutzen wie mplayerlib.dll

FFdshow interpretiert ja den Input (XVID/mpeg4/mpeg2/raw ..etc), decodiert ihn und gibt klare parameter weiter, was fps/colorspace angeht. Somit WENN denn hoff. bald der mpeg2 decoder nicht mehr "broken" ist, it erneutes testen mit FFdshow als decoder angesagt.
Was Farbraumwandlung angeht: Hab mal als Test ein capture in xvid q=2 gemacht und jenes capture in Directshow via FFdshow decodieren lassen. In Avisynth wurde dieses avi mit Directshowsource geöffnet und mit info() mal das "innere" angezeigt. Colorspace war und blieb YV12(), fps 25, somit wurde via Directshowsource ales richtig interpretiert. Problem ist nur, versuche mal noobs (mit all ihren Codecpacks) zu erklären, wie FFdshow richtig eingestellt wird, und wie eben im System die Merits so gesetzt sind, dass wirklich jener Stream von FFdshow decodiert wird.

Ich habe momentan noch den WinDVD Intervideompeg2 decoder im system als mpeg2 decoder am laufen, werde aber dieser Tage den Gabestmpeg2 decoder installieren und jenen sodann meine mpeg2s decodieren lassen. Mal sehen was da via directshowsource rauskommt.

OT/
Was captures angeht, so lasse ich diese nur noch via FFDshow encodieren (HuffYUV) und ebenso decodieren. De Vorteil hierbei ist, du kannst auf interne Filter zurückgreifen, so z.B. minimale Luma/Chroma Shifts vorab ausgleichen, den sehr guten DenoiseHQ3d nutzen und z.B. den Delogofilter nutzen, welcher sich wie in Vdub einstellen lässt.

Dieses AVI öffne ich sodann im avs mit directshowsource(), resize..() ... Info() ...und .... das Preview im WMPclassic ist pregefiltert und zwar so wie ich es möchte und YUY2 ist erhalten!, ebenso beim XVID Test-capture wo bei gleichen filtern etc. eben sodann YV12() angezeigt wird.
Beim abspielen wird mir im Taskmanager 50% CPU angezeigt.
Würde ich die gleichen Filterroutinen in AVS selber vornehmen, kommt ca. 90% ! bei raus. Demnach nimmt der avs commando interpreter da einiges an Leistung weg.

Anmerkung: um festzulgen welcher DS Filter zum Decoden verwendet werden soll kann man auch eine Filterkette in Graphedit erstellen und das grf File in Avisynth öffnen
(ist aber wahrscheinlich umständlicher als DVD2AVI&mpeg2Source )

Cu Selur

Zitat

Anmerkung: um festzulgen welcher DS Filter zum Decoden verwendet werden soll kann man auch eine Filterkette in Graphedit erstellen und das grf File in Avisynth öffnen

Die Fehleranfälligkeit des Direct Show Filtersystems ist ein weiteres Problem. Wer erinnert sich nicht an AVIs, die plötzlich auf dem Kopf standen, obwohl z. B. lt. Graphedit nur Quelle, AVI-Splitter, Decoder und Video Renderer beteiligt waren und keiner dieser Filter diesen Fehler verursachte.
Außerdem, wie LigH in dem anderen Thread schon sagte, Direct Show Decoder sind auf ruckelfreies wiedergeben, also Speed, nicht auf optimale Qualität, welche i. d. R. für die Weiterbearbeitung gewünscht ist, optimiert.

"Direct Show Decoder sind auf ruckelfreies wiedergeben, also Speed nicht auf optimale Qualität, ... , optimiert." nur weil dies auf einige Filter zutrifft würde ich das nicht verallgemeinern,... denke LigH hat das auch nicht so 'fatalistisch' ausgedrückt, oder?
Vorallem sollte man DirectShow Decoder und etwaige Filterfunktionen nicht umbedingt in einen Topf werfen.

Cu Selur

Doch, bei den Direct Show Decodern veralgemeinere ich das - denn die sind dort schließlich zur wiedergabe gemacht

>Vorallem sollte man DirectShow Decoder und etwaige Filterfunktionen nicht umbedingt in einen Topf werfen.
Würde ich niemals tun.

@incredible
Mit ffdshow als Decoder habe ich auch schon experimentiert. Eigentlich eine sehr gute Wahl. Beim Transcoden von MPEG4 zu MPEG2 benutze ich ausschließlich Xvid oder eben ffdshow.
Ab und an produziert ffdshow aber eine fehlerhafte Ausgabe. Woran das liegt, habe ich noch nicht herausgefunden (Farbschlieren im Bild). Ist auch nicht bei allen Videos so, sondern nur bei einigen. Via VfW-System geht's aber, nur DirectShow macht da Ärger.
MPEG2 über ffdshow muss ich nochmal antesten, zurzeit tun da bei mir der OpenSource-Splitter/Decoder von Gabest ihren Dienst.
BTW. Wieso gibt's die eigentlich nicht bei Sourceforge?

@ Viperzahn

Wenn du DEIN Avisynth Script öffnest, was passiert denn da?
Je nach Programm, also WMP oder Vdub wird ein Directshow oder vfw decoder genutz um eben den avs-yv12 (oder YUY2 oder RGB24) Stream zu decodieren, genauso siehts auch aus, wenn du mit em AVS in TpgEnc oder mencoder oder CCE reingehst. Wenn eben Geschw. beim Decoder vor Quali geht, dann hättest du das mit Avisource() drin und zudem auch noch beim avs decoding.

Also ist da Directshow eh volles Programm am werkeln.
Normalerweise kann man für AVS YV12 decoding XVID benutzen aber ein RICHTIG eingestelltes FFdshow machts genauso (zumal es unter anderem auf XVID/Libavcodec sources aufbaut).
Deinstalliere dir den YV12 codec und versuche normal mit Avisource() im AVS ein YV12 Avi zu importieren und mit converttoYUY2() in einen Windows - geht nicht.

Ich kenne nicht alle DS decoder, aber XVID und FFdshow sind nicht Geschw. über Qualitätspräorisierend, das siehst du daran, dass wenn du in FFdshow jede Menge Filterungen vornimmst, das Video im WMP stockt, da 100% Last angelangt ist.
Darum gibts beim "Postprocessing" in FFdshow auch die Option CPU Last optimiert, was man aber auch abschalten kann.

Zitat

>Vorallem sollte man DirectShow Decoder und etwaige Filterfunktionen nicht umbedingt in einen Topf werfen.
Würde ich niemals tun.

Dann solltest du es mal ausprobieren - ich mache es seit neustem und habe KEINERLEI Probleme (mit und ohne Filtering ffdshow als decoder)

@ Kika

Also ich habe jetzt nur Tests mit mpeg4 und HuffYUV als input in FFdshow gemacht, da mpeg2 decoding "broken" ist, wie gesagt.
Keinerlei Schlieren nix, alles bene.
Ich glaube via Sourceforge ist da alls zu bekommen? Benutze mal die Suche und gebe lediglich mpg2, mpeg2, mpeg ein, ... da kommt jede Menge leckere Kram daher! Und was als CVSs daherkommt, kann man sich ja für Win32 kompilieren (aber alles nötige ist IMHO als Win32 app/filter vorhanden)

Ich habe mir mein System so eingestellt, das XVID NUR Fourcc XVID und YV12 raw streams decodiert. Alles andere wird (ausser mpeg input) via FFdshow gerouted.
Vorteil: Es wird nicht via FFdshow Doppel-gefiltert, also ...

Import der Source in avs via ffdshow (egal ob über Directshowsource oder avisource) .... decoding des AVS im System via XVID (wenn dies auch ffdshow übernehmen würde, dann würde z.B. ein logo "doppelt" gefiltert.

Denn FFdshow "raw" streams decodieren zu lassen ist mega risky, da z.B. viele Graphs bei z.B. VirtualVCR oder WinDVD einen YUY2 oder YV12 Raw stream erzeugen, wo sich dann NOCHMAL ffdshow dazwischen mogeln würde.

Graphedit ist da sehr ausführlich, wenn du mal VirtualVCR laufen lässt oder das entspr. Mediafile decodieren lässt.

Und da ffdshow's VfW-Interface anscheinend gar nicht filtert (jedenfalls hat sich im englischen Forum noch niemand dazu geäußert...), wäre das sowieso einen Versuch wert.

Also Makeavis decoding via ffdshow's VFW Interface geht nicht, daher ist es NICHT möglich in Vdub ein MakeAvis AVI anzuzeigen.
Daher stürzt auch CCE ab, wenn man (sinnloserweise) ein avs-Makeavis-avi in CCE einläd Da CCE vfw als decoder nutzt.

Das Filtern via ffdshows/vfw habe ich noch nicht getestet, da es für mich nicht in Frage kam .... aber stimmt, sollte mal getestet werden.

EDIT: Jetzt fällts mir ein, es ist so! Denn wenn du via ffdshow/vfw ein Filtering einstellst und jenes avi dann in Vdub öffnest passiert NIX, lediglich ein normales decoding wird an VDub weitergegeben.

Aber warum willst du via vfw filtern?
In CCE gehst du doch nicht direkt mit einem Avi rein?
Sondern machst dies via avisynth, was intern ja ffdshow DS nutzt.

Bei den Filter ffdshow workouts muss man dann zum Previewen eben WMPclasic mit internem DS routinen nehmen.

Übrigens, Directshowsource("xxxxx.d2v") mit FFdshow Deblocking klappt (wenn d2vsource.ax instaliert und reg. ist)
Es MUSS aber der RAW-YV12 decoder in ffdshow aktiviert werden und das eben NUR dann, wenn man jenes de-encoding laufen lässt, danach wieder abstellen.

Probiere es mal und lade sodann das d2v in Graphedit (zu Kontrolle).
grf Dateien habe ich noch nie mit Directshowsource() geöffnet.
Da mach DirShowSource() noch maken.

Mit makeAVIS erzeugte Pseudo-AVIs kann ich im Fast-Recompress-Modus durch VirtualDub(Mod) an einen Codec weiterleiten. Wenn ich makeAVIS so einstelle, dass RGB24-Ausgabe erzwungen wird, dann kann ich sogar das Video sehen (aber dann macht FastRecompress nicht mehr viel Sinn).

Falls du dich noch erinnerst: Jemand wollte mit Hilfe von makeAVIs das Postprocessing von MPEG2Dec3 mit dem von ffdshow in den verschiedenen Varianten vergleichen. Wenn Postprocessing im VfW-Interface funktionieren würde, wäre das der ideale Weg gewesen (ffdshow's VfW-Interface als Decoder für makeAVIS-Pseudo-AVIs, die AviSynth-Ergebnisse frameserven); so geht es wohl nur über ffdshow-Raw-Processing und DirectShowSource (also AviSynth-Ausgabe per DirectShowSource mit AviSynth frameserven - pervers, oder?!).

Genau daran erinnere ich mich und habs deswegen auch getestet.
Jetzt ist mir auch klar warum der Weg via Vdub und vfw: Weil du ja via Vdub als mpeg4 speichern willst (ich habe keine mpeg4 targets, daher habe ich mich da nicht in deinen Workout direkt hineinversetzt)

Zitat

so geht es wohl nur über ffdshow-Raw-Processing und DirectShowSource (also AviSynth-Ausgabe per DirectShowSource mit AviSynth frameserven - pervers, oder?!).

Anders: Avisnth import (nicht Ausgabe) via direktshowsource und somit ffdshow raw YV12 und weiter in YV12 mit avisynth frameserven

Was hier eben für viele ein Graus ist, ist eben der Bug vom FFdshow/"vfw" decoder Modus, welcher bei Vdub eben gezwungenermaßen eintritt. Nicht aber avs direkt zu DS importing mpeg2 encoder

Zitat

Wenn du DEIN Avisynth Script öffnest, was passiert denn da?
Je nach Programm, also WMP oder Vdub wird ein Directshow oder vfw decoder genutz um eben den avs-yv12 (oder YUY2 oder RGB24) Stream zu decodieren, genauso siehts auch aus, wenn du mit em AVS in TpgEnc oder mencoder oder CCE reingehst. Wenn eben Geschw. beim Decoder vor Quali geht, dann hättest du das mit Avisource() drin und zudem auch noch beim avs decoding.

VfW und Direct Show sind zwei verschiedene Paar Schuhe - VfW ist wesentlich stabieler. Die AviSource von AviSynth verlangt einen installierten VfW Decoder für das zu verarbeitende AVI. Die Endapplicationen wie z. B. der Madiaplayer oder VirtualDub brauchen einen einen Decoder für das für sie unkomprimierte YV12 AVI, welches ihnen AviSynth vorgaukelt, sofern sie das nicht schon selber decodieren können. Programme die vornehmlich zur Wiedergabe da sind, greifen hier natürlich auf die speedoptimierten DShow Decoder zu, während weiterverarbeitende Applicationen wie VirtualDub die stabielen VfW Decoder benutzen.

Zitat

Also ist da Directshow eh volles Programm am werkeln.

Wie oben ausgeführt, nein.

Zitat

Normalerweise kann man für AVS YV12 decoding XVID benutzen aber ein RICHTIG eingestelltes FFdshow machts genauso (zumal es unter anderem auf XVID/Libavcodec sources aufbaut).

Ich weiß nicht was das hiermit zu tun hat, aber ich benutze den VfW YV12 Decoder von ffdshow schon seit geraumer Zeit, u. a. weil der XviD Decoder einen Anzeigebug hat.

Zitat

Deinstalliere dir den YV12 codec und versuche normal mit Avisource() im AVS ein YV12 Avi zu importieren und mit converttoYUY2() in einen Windows - geht nicht.

Doch, das geht - auch wenn ich wieder nicht weiß, was das hiermit zu tun hat. Es sei denn, Du meinst ein unkomprimiertes YV12 AVI, denn muß ein YV12 VfW Decoder da sein

Zitat

Ich kenne nicht alle DS decoder, aber XVID und FFdshow sind nicht Geschw. über Qualitätspräorisierend, das siehst du daran, dass wenn du in FFdshow jede Menge Filterungen vornimmst, das Video im WMP stockt, da 100% Last angelangt ist.

Trotzdem sind die einzelnen Filter geschwindigkeitsoptimiert (sieht man z. B. am Deinterlacer - KernelDeint, TomsMoComb). Das Deinem Prozessor irgendwann die Resourcen ausgehen, wenn Du 10^50 Filterungen und seien sie auch für flüssige Darstellung entwickelt, dazwischenschaltest, sollte klar sein.

Selbstverständlich sind ffdshow-PP-Filter gut geschwindigkeitsoptimiert; aber sie sind nicht so stark "optimiert", dass sie für schnellere Wiedergabe an der Qualität sparen würden, sondern dass sie für Qualität auch mal Drop-Frames in Kauf nehmen (also Qualität über Geschwindigkeit).

Den Rest lasse ich euch erst mal alleine diskutieren...

Stimmt, aber das lässt sich ja einstellen.

Somit wäre ja alles geklärt.

Zitat

während weiterverarbeitende Applicationen wie VirtualDub die stabilen VfW Decoder benutzen.

3ivx, xvid, 3ivx,.. Decoder sind also schlechter weil sie directshow verwenden? :nein:

------------

Vielleicht wirds so verständlich:
Directshow ist neuere Entwicklung, es ist gedacht um vfw zu ersetzen, dass es für vfw mehr qualitäts optimiertes Zeug gibt, vorallem im Filtering&Decodingbereich liegt einfach daran, dass vfw älter ist.

Die Aussage, dass DS Zeug nur geschwindigkeitsoptimiert wäre und vfw eher qualitäts orientiert ist einfach falsch. Da könnte man auch sagen eine alte Programmiersprache wäre besser als neue Programmiersprachen, weil es mehr qualitätsoptimierte Anwendungen gibt die in dieser Sprache geschrieben sind.

Cu Selur

Ps.: Und jetzt versucht nicht mir zu sagen es wäre schöner was für vfw zu schreiben,... (Nur weil manche DS-Filter nicht so gut sind wie manche andere vfw filter sagt das noch nix aus.)