Jump to content

Noch mal zum Postprozessor


BMueller

Recommended Posts

Hallo,

auf meine letzlich gestellte Frage habe ich leider noch keine Antwort bekommen: Warum ist die Einbindung eines "Postprocessors" ( bei mir steht ffdshow oder NVIDIA zur Auswahl) trotz des angebotenen Auswahlfeldes in den Live-Bild-Graphen nicht möglich ?

Ich hätte gerne von den Programm-Entwicklern eine Stellungnahme.

 

Gruß Bernd

Link to comment
  • Replies 92
  • Created
  • Last Reply

Top Posters In This Topic

  • CiNcH

    24

  • Griga

    15

  • BMueller

    13

  • alex.ba

    7

Top Posters In This Topic

Hallo,

bin ich hier der Einzige, den das interessiert? Ich würde es begrüssen, mal eine Antwort zu bekommen, ob die Funktion "Postprcessor" überhaupt funktioniert und wenn ja, wie?

 

Gruß Bernd

Link to comment

Hi !

 

Interessiere mich auch dafür ;)

 

Hab jetzt schon zig ffdshow Versionen ausprobiert , aber leider wird mir im filtergraph dort nie ffdshow angezeigt.

 

Es funktioniert nur wenn ich statt des dscalers oder cyberlink decoders einfach direkt ffdshow auswähle.

 

Ich möchte aber das ffdshow mit dem cyberlink zusammen läuft!

Edited by unreality
Link to comment

Ich habe es auch nur mit einem Custom Graph ans Laufen gebracht, sprich 'CyberLink Video/SP Decoder' -> 'ffdshow raw video filter' -> 'Video Mixing Renderer 9'. Allerdings bekomme ich nur ein Bild, wenn ich in DVBViewer das OSD disable.

 

Ein anderer Nachteil ist, dass die Beschleunigung durch die Grafikkarte bei Verwendung eines PostProcessors brach liegt (außer bei GPU-internen PostProcessoren).

Edited by CiNcH
Link to comment

Dass in den FFDShow-Einstellungen unter Codecs "Raw Video" aktiviert sein muss, ist klar, denke ich.

 

Trotzdem funktioniert es hier nicht, mit keiner der in ffdshow und im DVBViewer Pro ausprobierten Einstellungen.

 

Auch diverse Varianten mit GraphEdit getestet und dabei die Vorgehensweise simuliert, mit der der DVBViewer den Filtergraphen aufbaut. Dabei fiel auf, dass ffdshow beim Rendern von Output-Pins meist unverbunden im Graphen liegenbleibt, auch dann, wenn ich den Filter auf höchsten Merit stelle. Das hat im DVBViewer zur Folge, dass er wieder entfernt wird. Nur mit manuellem Verbinden der Komponenten klappt es zuverlässig.

 

Das dürfte die Ursache sein. Der DVBViewer Pro verlässt sich vermutlich darauf, dass, wenn er ffdshow in den Graphen einfügt, dieser vom DirectShow GraphBuilder automatisch an passender Stelle untergebracht wird. Passiert aber beim Rendern von Video-Output-Pins nicht. Zumindest dann nicht, wenn der Videorenderer auch schon im Graphen vorhanden ist. Bei der Suche nach einem passenden Partner für den Videodecoder wird der gegenüber ffdshow immer bevorzugt.

 

Wundert mich etwas, denn als ich vor geraumer Zeit mit dem ffdshow Raw Filter experimentiert habe, rutschte der immer mit rein. Das war sogar ein häufiger Supportfall, weil der sich zumindest damals nicht unproblematisch verhielt, insbesondere im Zusammenhang mit hardware-beschleunigten Decodern. Da hatten Leute ffdshow installiert, Raw Video war aktiviert, der Filter kam auch ohne explizites Einfügen mit rein, und dann gab es im DVBViewer nur noch bunte Muster zu sehen ;)

 

Erstaunlicherweise kommt ffdshow hier beim DVBViewer GE ins Spiel, auch ohne Postprozessor-Option. Allerdings nur, wenn ich als Rendermodus "System Default Renderer" wähle. Hierbei wird *kein* Renderer in den Graphen eingefügt, sondern die Auswahl dem GraphBuilder überlassen. Und der nimmt dann ffdshow gleich mit rein. Die Wege von DirectShow sind unergründlich...

 

Kurz gesagt müsste der DVBViewer Pro wohl den Postprozessor explizit selbst verbinden und dies nicht den DirectShow-Automatiken überlassen, damit es zuverlässig funktioniert. So ist mit der Postprozessor-Option nichts anzufangen.

Link to comment

Hallo,

ffdshow macht, wie schon gesagt, andern Orts eher Probleme, weil er sich einbindet, ohne gefragt worden zu sein. @ Griga: Deine Ausführungen sind sehr interessant, leider lese ich zu oft sollte, müsste etc. Gehe ich vollkommen fehl in der Annahme, dass die Programmierer von DVBV hier auch mitlesen? Das wäre doch mal eine Anregung: Den Aufbau des Graphen nicht einer "DirectShow"-Automatik zu überlassen sondern wie im Zoomplayer dem Anwender die Zusammenstellung zu ermöglichen. Schliesslich reagiert jedes System in Abhängigkeit von den Hardwarekomponenten anders. Filter, die bei dem Einen funktionieren und ein hervorragendes Bild produzieren, sind bei einem Anderen grottenschlecht. Das habe ich nach viel Bastelei am Zoomplayer erfahren müssen. Hier kommt auch zum Ausdruck, dass das Live-HD-Bild bei mir im DVBV manchmal noch leicht ruckelt, die aufgenommene TS-Datei aber im Zoomplayer mit der auf meinen Rechner zugeschnittenen Filterkombination hervorragend läuft.

 

Gruß Bernd

Link to comment
Gehe ich vollkommen fehl in der Annahme, dass die Programmierer von DVBV hier auch mitlesen?

Ich habe meine Analyse an die zuständigen Behörden weitergeleitet ;)

 

dass das Live-HD-Bild bei mir im DVBV manchmal noch leicht ruckelt, die aufgenommene TS-Datei aber im Zoomplayer mit der auf meinen Rechner zugeschnittenen Filterkombination hervorragend läuft.

Das sind zwei verschiedene Paar Schuhe. Live läuft directshowmäßig in einem ganz anderen Modus (Push). Die Daten werden in den Graphen hineingedrückt, es sind Realtime-Anforderungen zu beachten - die Sender warten ja nicht. Dateiwiedergabe findet dagegen im Pull-Modus statt, d.h. die Daten werden nach Bedarf aus der Datei gesaugt.

 

I.A. hat Live-Wiedergabe wegen der schwierigeren Timing-Bedingung eher eine Neigung zu leichten Rucklern.

Link to comment
Guest Lars_MQ

Die Entwickler lesen mit und haben sich entschieden:

Die Option selber bleibt bestehen, da sie auch von dem Momolight teil verwendet wird, aber alle anderen postprozessoren werden entfernt und man kann sie nicht mehr ausählen.

Alles andere wäre rumgepfusche und würde dank directshow immer wieder zu problemfällen führen.

Link to comment
Das sind zwei verschiedene Paar Schuhe. Live läuft directshowmäßig in einem ganz anderen Modus (Push). Die Daten werden in den Graphen hineingedrückt, es sind Realtime-Anforderungen zu beachten - die Sender warten ja nicht. Dateiwiedergabe findet dagegen im Pull-Modus statt, d.h. die Daten werden nach Bedarf aus der Datei gesaugt.

 

I.A. hat Live-Wiedergabe wegen der schwierigeren Timing-Bedingung eher eine Neigung zu leichten Rucklern.

 

Wenn ich das richti verstehe muesste man doch durch ein Puffern auf die Platte aus einem Push-Mode einen Pull-Mode machen koennen. Damit sollten doch die beschriebenen Push-Einschraenkungen vermieden werden. Dass der Tageschau-Gong ein paar Sekunden spaeter kommt, muss dann aber akzeptiert werden.

 

klaus.

Link to comment
Wenn ich das richti verstehe muesste man doch durch ein Puffern auf die Platte aus einem Push-Mode einen Pull-Mode machen koennen. Damit sollten doch die beschriebenen Push-Einschraenkungen vermieden werden. Dass der Tageschau-Gong ein paar Sekunden spaeter kommt, muss dann aber akzeptiert werden.

klaus.

 

...was ja im Prinzip jetzt schon funktionieren "könnte", wenn man den Sender in MPEG aufnimmt und dann unter DirectX den Haken entfernt bei "benutze DVBSource für MPEGS".

So wird der Standard DirectShow Media Splitter benutzt.

Aber das geht dann ja wieder nicht wegen der "offenen" Datei ;)

 

Nun gut, generell denke ich das Einbinden eines Postprocessors wäre ein echtes I-Tüpfelchen und würde den "Rest" der DVB-Programme vollends ins Abseits stellen.

 

Mich beschleicht auch so ein Gefühl, als wären es hier doch eine recht große Anzahl von Usern, die sich sowas wünschen.

Wenn dem so ist: Vielleicht hilft es ja, wenn wir alle gemeinsam ganz lieb: BITTE sagen.

 

Bitte denkt noch mal drüber nach.

 

Vielleicht erbarmt sich ja @Griga, sofern er Lust dazu hat und sich die Zeit nimmt, uns das mal in eine GE-Beta einzubauen? :(

 

Oder habt ihr das eh schon ausprobiert und es geht einfach nicht im Push-Betrieb?

Link to comment

Da möchte ich mich azeman doch voll und ganz anschliessen. Die Nachbearbeitung des Live-Bildes mit einem Postprozessor wäre ein schönes Gimmick ;), vorausgesetzt die Performance des Systems wird dadurch nicht zu stark belastet.

 

Bernd

Link to comment
Wenn ich das richti verstehe muesste man doch durch ein Puffern auf die Platte aus einem Push-Mode einen Pull-Mode machen koennen. Damit sollten doch die beschriebenen Push-Einschraenkungen vermieden werden. Dass der Tageschau-Gong ein paar Sekunden spaeter kommt, muss dann aber akzeptiert werden.

 

klaus.

..naja, wie mans nimmt. Der push_mode war ja imho gerade eine errungenschaft des @grigaschen_dvb_source_filters ;) Mit puffern wurde auch experimentiert. Du kannst das ja simulieren, indem du timeshift machst oder während einer aufnahme den file mit einem player öffnest, der einen shared mode erlaubt (tsplayer z.b.). Letztlich ist das alles gehupft wie gesprungen. Bei genauem hinschauen wird man wahrscheinlich immer bei bestimmten bedingungen und/oder bildinhalten mikroruckler sehen.

Link to comment

Hi

 

sehe ich ähnlich wie Ihr. Dh. ich würde auch sehr gerne einen Postprozessor im DVBViewer verwenden! Am liebsten wäre mir, wenn der GraphSelektor funktionieren würde, und man selbst die Grafen zusammenstellen könnte. Im Augenblick funktioniert das bei mir nicht, dh. ähnlich wie schon obenbeschrieben, mit eingeschltetem OSD klappt das einfach nicht!

 

Manchmal möchte man zB. das SD-Bild hochskalieren, ohne Postprozessor sehe ich keine Chance. Ich finde zwar DVBViewer sehr gut (eigentlich am besten), aber die Grafen vermisse ich einfach sehr. Bin einfach von anderen Programmen gewöhnt (ZoomPlayer, MyTheatre oder ProgDVB).

 

Viele Grüsse

Link to comment
Bei genauem hinschauen wird man wahrscheinlich immer bei bestimmten bedingungen und/oder bildinhalten mikroruckler sehen.

Das ist ein grundsätzliches Problem der TV-Wiedergabe mit dem PC: es gibt - anders als beim klassischen Fernseher - keine Möglichkeit, die fest eingestellte Bildwiederholfrequenz des Monitors mit der Framerate zu synchronisieren.

 

Wesentlich geglättet wird das durch Decoder, die aus 25 fps interlaced 50 fps progressive machen, also die Framerate praktisch verdoppeln. Die Ruckler fallen dann kaum noch auf. Braucht allerdings Hardware-Beschleunigung, um effizient zu funktionieren. Bei besseren MPEG2-Decodern ist das inzwischen Standard (hat auch lange genug gedauert), bei H.264 liegt in der Hinsicht noch einiges im Argen.

Link to comment

Leider lässt mir das Thema ffdshow-Einbindung noch keine Ruhe. Zugegebenermassen bei mir vielleicht ein spezieller Fall, aber mich interessiert an ffdshow vor allem die "Schärfefunktion". So wie ich im Zoomplayer das DVD-Bild nachschärfe, was gerade bei 2,50 m Projektionsbreite eine erstaunliche Verbesserung bringt, würde ich diese Funktion im DVBViewer begrüssen. Habe am Montag die ARD-Sendung über Arktis-und Antarktis im 16:9-Format gesehen. Das Bild war stellenweise DVD-Qualität, hätte aber etwas "Schärfeanhebung" vertragen.

Und so wie GRIGA in seinem letzten Satz schreibt:

"Kurz gesagt müsste der DVBViewer Pro wohl den Postprozessor explizit selbst verbinden und dies nicht den DirectShow-Automatiken überlassen, damit es zuverlässig funktioniert. So ist mit der Postprozessor-Option nichts anzufangen."

Vielleicht ist das der Weg, den wir den "Programmierern" mal ans Herz legen sollten.

 

Bernd

Edited by BMueller
Link to comment
Guest Lars_MQ
Vielleicht ist das der Weg, den wir den "Programmierern" mal ans Herz legen sollten.

Leider stellt griga das etwas vereinfacht dar.

Das ganze ist durch die vielfalt an komponenten, die jeder user auf seinen rechner packt, nicht zufriedenstellend zu lösen und wird daher wie oben angesprochen entfernt.

Link to comment

Ich seh schon die entnervten Endkunden die Anzeigeprobleme haben, weil einer der Codecs sich nicht mit dem Postprozessor verbinden will und dann nix mehr geht. Wir haben das früher mal gemacht, aber aus Fehlern lernt man bekanntlich. Die gewaltsame Methode funktioniert bei Codecs die explizit, aus was auch immer für Gründen, keinen zusätzlichen Filter zwischen sich und den Renderer lassen nicht. Als Beispiel seih hier Sonic Dekoder genannt. Die Anzeigeroutinen sind übrigens, selbst auf den meisten zugemüllten Systemen (gibt ja leider immer noch zuviele Leute die sich mit irgendwelchen Codecpacks ihr OS versauen) halbwegs stabil und ich sehe ehrlich keinen Grund das zu ändern. Wer unbedingt FFDShow nutzen will, soll er doch auch den Dekoder verwenden. Die Mpeg2 Dekodierung läuft mit ihm ja auch ohne Probleme.

Link to comment

FFdshow als MPEG-Decoder ist nicht so der Hit. Wie auch schon von anderen erwähnt, sind die Deinterlace-fähigkeiten des ffdshow eher bescheiden und nicht nicht mit anderen guten Decodern vergleichbar. Ich erhalte jedenfalls deutliche "Kammartefakte". Mir persönlich, aber das ist sicher sehr einseitig gesehen, würde schon eine Bildnachschärfung, wie z.B. im WinDVD-Player eingebaut, helfen. Vielleicht lassen sich diese oder ähnliche Nachbearbeitungs-/Einstellfunktionen noch in den DVBViewer einbauen ohne auf einen Postprozessor angewiesen zu sein.

Ich gebe ja gerne zu, dass ich diesbezüglich kein Experte bin. Trotzdem leuchtet mir noch nicht ganz ein, warum der mit graphedit erzeugte Filterpfad nicht modifiziert werden kann. Wenn nicht alle vom DVBV verwendeten Filter im System registriert sind, sollte man dies vielleicht nachholen. Jeder könnte dann an seinem System mit den Filterkombinationen experimentieren. Wer sich seinen Rechner zu vollgemüllt hat, bleibt eben bei den Standardeinstellungen. Um bei meinem bereits strapazierten Zoomplayer-Beispiel zu bleiben: Da habe ich auch viele Abstürze gehabt, bis ich die Filterfunktionen einigermassen begriffen und die auf mein System zugeschnittenen Graphen für die verschiedenste Dateiformate zusammengebastelt hatte.

Also, die Hoffnung stirbt zuletzt.

 

Bernd

Edited by BMueller
Link to comment
FFdshow als MPEG-Decoder ist nicht so der Hit. Wie auch schon von anderen erwähnt, sind die Deinterlace-fähigkeiten des ffdshow eher bescheiden und nicht nicht mit anderen guten Decodern vergleichbar.

 

ffdshow mit DScaler Plugins würde ich jetzt nicht als bescheidenes Deinterlacing bezeichnen. MoComp2 oder Greedy stehen den Deinterlacern in aktuellen GPU's in nichts nach. Natürlich wird eine entsprechende CPU vorausgesetzt.

Edited by CiNcH
Link to comment
Trotzdem leuchtet mir noch nicht ganz ein, warum der mit graphedit erzeugte Filterpfad nicht modifiziert werden kann.

Im Prinzip (sage ich mal vorsichtig) geht das. Eine Beschreibung liefert die ReadMe des GraphSelector-Plugins (-> Mitgliederbereich). Jedenfalls habe ich hier schon selbstgebaute Graphen mit dem DVBViewer Pro 3.6 erfolgreich in Betrieb genommen.

 

Man muss allerdings den Graphen komplett selbst erzeugen - den vom DVBViewer Pro verwendeten mit GraphEdit abspeichern und modifizieren ist nicht drin, wegen der internen Filter, die nicht als separate Datei existieren. Und es könnte sein, dass die VMR 7/9-Modi des DVBViewer Pro sich so nicht rekonstruieren lassen (zumindest nicht mit OSD), weil das eine spezielle Konfiguration der Renderer seitens der Anwendung erfordert. Mein selbstgebastelter Graph entsprach dem Modus "Unchanged", und das ging soweit. Einfach probieren...

Link to comment

P.S.

 

Ich habe gerade nachgedacht (kommt gelegentlich vor ;)) und bin zu dem Ergebnis gekommen, dass sich die Sache mit dem Postprofessor am besten durch ein Plugin erledigen lässt - das API erlaubt es, nachträglich einen Filter in den Graphen zu flicken, und damit wäre das gleich für DVBViewer Pro und GE erledigt. Die interessante Aufgabe ist dabei für das Plugin, herauszufinden, wo das Ding hin muss.

 

Allerdings werde ich erst nächste Woche dazu kommen, das in Angriff zu nehmen, Familie geht vor... also etwas Geduld.

Link to comment

Hi Griga,

 

das hört sich ja gut an und würde eurem Superprogramm noch ein Highlight hinzufügen.

Aber ganz klar: Die Familie geht vor.

 

Gruß Bernd

Link to comment

Mich hat es doch zu sehr interessiert, ob das funktioniert... in Nachtarbeit fix das Plugin zusammengebaut. Im DVBViewer Pro und GE funktioniert es hier wie erwartet. Wer allerdings darauf hofft, den Cyberlink mit ffdshow zu verheiraten, wird womöglich enttäuscht werden. Das gab hier nur diverse Abstürze. Mit anderen MPEG2-Decodern ging es, außer dem Sonic. Der will sich wie schon von Christian berichtet nicht mit ffdshow verbinden.

 

Das Plugin ist erhältlich im Mitgliederbereich, Beta-Sektion. Verwendung ohne jegliche Garantie und auf eigenes Risiko! Es könnten noch Bugs drin sein, ich hatte nur sehr wenig Zeit für Tests. Die PostProcessor.dll gehört in DVBViewer\Plugins. Nach dem DVBViewer-Start sieht man im Plugins-Menü die Auswahlmöglichkeit. "Videoformat automatisch erkennen" würde ich in den Optionen sicherheitshalber einschalten, wenn Sender mit anderer Auflösung als 720 x 576 (bzw. 1920 x 1088 bei H.264) ins Spiel kommen.

Link to comment

Hi Griga,

 

das ist ja eine Supernachricht. ;) Vielen Dank für die Nachtarbeit. Hoffentlich musste die Familie nicht darunter leiden. Ich werde das heute abend gleich probieren und eine Rückmeldung geben.

 

Bernd

Link to comment

Habe das jetzt mal mit Elecard DS-Filter getestet und es funktioniert soweit super. Vielen Dank dafür.

 

Soweit ich weiß liegt DXVA bei Verwendung eines Software PostProcessors brach. Da kommt man wohl nicht mehr so leicht an die Videodaten, wenn sie mal in der GPU sind.

Wie sieht es mit VMR-Deinterlacing, also Deinterlacing durch die GPU, aus? Das sollte man doch irgendwie aktivieren können!?

Link to comment

Hi,

also ich habe auch den ersten Test hinter mir mit ffdshow als Plugin. Für die SD-Sender ist das ein absoluter Gewinn (NVIDIA-Mpeg-Decoder + ffdshow). Doch leider passiert jetzt das, was ich befürchtete: Wenn ffdshow, dann immer. Soll heißen, auch bei HD-Sendern. Und hier ist jeder zusätzliche Filter nur von Nachteil. Das HD-Bild sollte eigentlich schon den Ansprüchen genügen. In Verbindung mit dem Cyberlink H.264 läauft das zwar, aber ffdshow bringt das Bild zum zappeln. Und hier mien Frage/Bitte an griga: Gibt es eine Möglichkeit, dieses Postprocessor-Plugin auf die MPEG-Wiedergabe zu beschränken und bei H.264 zu unterdrücken ? :radscorpion:

Link to comment

Vielen Dank an Griga! Das SD-Bild ist nun genial (Nvidia mit FFDShow), genau das, was ich wollte. Ich sehe das mit dme HD-Bild genauso wie BMueller. Dh. bei HD sollte bitte kein Postprozessor verwendet werden. Ich weiss aber auch nciht, wie man das techn isch am besten lösen könnte.

Link to comment

Fragt sich, an welchem Kriterium man das am besten festmacht. Dort, wo ich eingreife (hinter dem Decoder), ist nicht direkt ermittelbar, ob es zuvor MPEG2 oder H.264 war. Dazu müsste das Plugin den Input-Pin des Decoders suchen und dessen Verbindungsformat abfragen.

 

Die Auflösung lässt sich wahrscheinlich einfacher ernitteln. Das Problem ist: Es gibt auch H.264-SD und MPEG2-HD, und womöglich x verschiedene Vorstellungen davon, bei welchen Gelegenheiten ein Postprozessor angebracht ist... :radscorpion:

Link to comment

Die am Montag erscheinende c't 2007/6/234 ff. enthält einen 4-seitigen Artikel zu ffdshow, der vielleicht interessieren könnte.

Link to comment
Vielen Dank an Griga! Das SD-Bild ist nun genial (Nvidia mit FFDShow), genau das, was ich wollte. Ich sehe das mit dme HD-Bild genauso wie BMueller. Dh. bei HD sollte bitte kein Postprozessor verwendet werden. Ich weiss aber auch nciht, wie man das techn isch am besten lösen könnte.

 

Welche Einstellungen verwendest du in ffdshow?

Link to comment

Die Final-Version des Post Processor Plugins ist erhältlich:

 

http://www.DVBViewer.info/forum/index.php?showtopic=17518

 

Es ist in wesentlichen Teilen konfigurierbar und bietet die Möglichkeit, für bestimmte Decoder die Verwendung eines Postprozessors auszuschließen. Die Standard-PostProcessor.ini tut dies bereits für mir bekannten H.264-Decoder. Falls die CLSIDs eurer Decoder von meinen abweichen, müsst ihr die Datei eventuell anpassen. Alle dazu nötigen Hinweise stehen in der beigefügten ReadMe-Datei.

Link to comment

Leider habe ich ein kleines Problem...

 

CyberLink + ffdshow + anamorphes Material + Overlay = gestauchtes Bild

 

CyberLink + ffdshow + anamorphes Material + VMR = alles in Ordnung

 

CyberLink + anamorphes Material + Overlay = alles in Ordnung (weiterhin ohne DXVA wie in den ersten beiden Szenarien)

 

Hat hierzu jemand eine Idee?

Link to comment

Mit der ffdshow tryouts scheint ist dieses Problem verschwunden. Dafür kommen andere lästige Probleme dazu... Dieses ffdshow scheint doch einige Fehler zu haben...

Link to comment

Mich wundert, dass der Cyberlink bei dir überhaupt mit ffdshow läuft - hier gab es mit dem aus PDVD7 nur Abstürze, in Pro und GE. Anschließend war der Mauszeiger kein Pfeil mehr, sondern ein großes grünschimmerndes Quadrat, von dem ich mich nur durch Ab- und Anmelden aus dem Konto befreien konnte. Typisches Anzeichen für ein Unglück in der Graka (hier NVidia MX 440), wo der Zeiger hardwaremäßig realisiert wird.

 

Aber es gibt viele ffdshow-Versionen...

 

gestauchtes Bild

Wie gestaucht?

Link to comment

Ja, furchtbares Versionenchaos. Jetzt sowieso wo es noch die Abspaltung ffdshow tryouts gibt. Und wie gesagt, damit ist das Bild bei anamorphem Material im Overlay nicht mehr vertikal gestaucht (platte Köpfe, und das Bild ist auch aufgezoomt). Dafür habe ich mit der tryouts Probleme mit DScaler Deinterlacing Plugins und nach dem Umschalten habe ich plötzlich 2 mal dasselbe Bild nebeneinander mit der Kombination aus CyberLink + Overlay.

Bei InterVideo habe ich das Problem, dass Kanäle mit nicht voller PAL-Auflösung komplett verzerrt dargestellt werden (z.B. Bloomberg TV Germany @ 480 x 576), aber auch nur, wenn ffdshow dazwischen hängt.

Schrecklich, bis man da mal alles unter einem Hut hat. ffdshow im Filter-Graph scheint nicht ganz unproblematisch zu sein.

 

Aber Probleme mit CyberLink hatte ich sonst keine, sprich Abstürze, und hab sogar noch dieselbe Grafikkarte :wacko: .

Edited by CiNcH
Link to comment

Ich konnte nun manche Problem beseitigen bzw. einschränken:

 

- wie gesagt gibt es mit der tryouts kein gestauchtes Bild bei anamorph Sendungen unter Verwendung des Overlay Mixers

 

- Deinterlacing mit DScaler Plugins funktioniert nun mit der tryouts wieder einwandfrei, es waren nur Odd und Even Fields vertauscht

 

- das Problem, bei dem das TV-Bild zweimal nebeneinander dargestellt wird tritt nur bei Auflösungswechel auf (z.B. von einem Kanal mit 720 x 576 auf einen Kanal mit 480 x 576) und nur unter Verwendung des Overlay Mixers

 

Nur zur Info... das sind natürlich keine DVBViewer Probleme!!

Edited by CiNcH
Link to comment

Hervorragender Tipp Griga. Nun scheine ich alles im Griff zu haben. Ich greife die ffdshow Version erstmal nicht mehr an. Weil mit dem aktuellen 'daily build' der tryouts habe ich wieder das gestauchte Bild bei anamorphen Sendungen. Tryouts Beta 1 läuft jetzt mal für mich, mal sehen, ob ich noch auf Fehler stoße.

 

Was macht denn die Videoformat Erkennung genau? Naja, mal Suchfunktion anwerfen, vielleicht finde ich ja etwas dazu... :wacko:

 

Danke jedenfalls für den Tipp!

 

Ich verwende im Fall immer noch CyberLink, ohne Probleme...

Edited by CiNcH
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...