Jump to content
Jackie78

madVR Renderer in DVBViewer nutzen

Recommended Posts

CiNcH

Ohne Formaterkennung dürfte der DVBSource einen Default weiterreichen (25fps = 40ms). Komisch allerdings, dass dann bei 1080i die korrekten 20ms im madVR OSD angezeigt werden. Da würden die 25fps (40ms) eigentlich eher stimmen. Außer jemand weiß über den Frame-Doubler-Deinterlacer Bescheid.

Share this post


Link to post
madshi

Ja, ist schon etwas komisch. Was zeigt madVR denn im Ctrl+J OSD an? Zeigt es "NV12, 8bit, 4:2:0"? Oder "h264, 8bit, 4:2:0 -> NV12, 8bit, 4:2:0"?

Share this post


Link to post
blasgl

Kann jemand eventuell IVTC mit SD-Sendern testen? Bei mir, und mit ein paar Ausnahmen (z.B. RTL), geht das Deinterlacing nicht

Share this post


Link to post
nuts

Was meinst du mit "geht nicht"?

IVTC Deinterlacing funktioniert nur bei nativ progressiven Quellen (Film).

Share this post


Link to post
blasgl

Ich glaube es ist besser, wenn ich heute Abend ein paar Screenshots mache von den Sendern wo es nicht geht, un wo es geht... Besser kann ich es leider nicht beschreiben.

Share this post


Link to post
nuts

Also du siehst die gefürchteten Kamm-Artefakte mit IVTC?

Das spricht dann für eine echte interlaced Quelle und wäre normal.

Share this post


Link to post
blasgl

Also du siehst die gefürchteten Kamm-Artefakte mit IVTC?

Das spricht dann für eine echte interlaced Quelle und wäre normal.

 

Ok, jetzt habe ich es kapiert

Share this post


Link to post
blasgl

Ja, ist schon etwas komisch. Was zeigt madVR denn im Ctrl+J OSD an? Zeigt es "NV12, 8bit, 4:2:0"? Oder "h264, 8bit, 4:2:0 -> NV12, 8bit, 4:2:0"?

 

NV12, 8bit, 4:2:0

Share this post


Link to post
CiNcH

 

NV12, 8bit, 4:2:0

 

Hier auch, egal ob 720p50 oder 1080i25.

 

Bei MPEG-2 576i25: MPEG2, 8 bit, 4:2:0 -> NV12, 8 bit, 4:2:0 [DXVA2]

 

Alles mit LAV dxva2n.

Share this post


Link to post
madshi

@blasgl, @CiNcH:

 

In dem Fall sieht es so aus, daß madVR sich den Video-Bitstream gar nicht angeguckt hat. Heißt praktisch, madVR verläßt sich "blind" auf das, was vom Decoder kommt, und zwar im "VIDEOINFOHEADER.AvgTimePerFrame" Feld. Oder falls der Decoder das Feld auf 0 gesetzt hat, dann halt im nächsten Filter, wahrscheinlich dem Splitter, oder falls der das auch auf 0 hat, dann halt vom Source-Filter. Ich denke nicht, daß ich da irgendwas verbessern kann. Was da im OSD steht, ist einfach die beste Info, die madVR gefunden hat. Die scheint im Live-TV gerne mal falsch zu sein, aber da kann ich nix dran drehen.

 

Das einzige was ich machen könnte wäre die Timestamps der Frames zu untersuchen und daraus zu raten, daß die wirkliche Framerate scheinbar eine andere ist als AvgTimePerFrame sagt. Aber anhand von Timestamps die Framerates zu raten ist nicht wirklich eine gute Lösung, da Timestamps gerne auch mal jittern. Außerdem muß ich die richtige Refresh-Rate ja auch gleich beim Start der Wiedergabe einstellen, da kann ich nicht erst warten, bis ich ein paar dutzend Frames bekommen habe, um die Timestamps zu untersuchen... :(

Share this post


Link to post
blasgl

Wo wir beim Thema VSync und Frame sind... kann mir jemand erklären warum die Anzeige bei 720p50 Sender so ist?

 

vsync 20ms, frame 40ms

 

Das würde heissen 25 fps???

 

Bei Dateien (720p50 .ts Aufnahmen) ist es tatsächlich so, dass "vsync 20ms, frame 20ms" angezeigt werden.

 

Bei 720p50 Live-TV ist die Anzeige immer "vsync 20ms, frame 40ms", egal ob Formaterkennung an oder aus ist.

 

Mich stört das nicht sonderlich, weil ich immer die gleiche Auflösung fahre (1920x1080@50Hz) und ansonsten das Rendering mit madVR wunderbar klappt. Aber eventuell lohnt es sich genauer zu schauen, was vom Source Filter und LAV an madVR übergeben wird?

 

Auf der positiven Seite muss ich sagen, ich habe jetzt einen Einstellungssatz für madVR gefunden, der mein Intel NUC nicht überfordert und einen deutlichen Qualitätsgewinn mit sich bringt.

 

Für 576i Live TV mit "SoftCubic80 + AR" Upscaling für Chroma und Image fährt die Intel Graka auf 700 MHz bei 80% Auslastung und 4 Watt

 

Ich kann sogar NEDI Image Doubling machen ohne Probleme (Graka auf 1000 MHz bei 100% und 10 Watt) aber qualitiätsmässig merke ich gar keinen Unterschied zu der vorherigen Einstellung.

 

Bei 720p oder 1080i ist der Unterschied zum Custom Renderer mit DXVA Scaling nicht sonderlich ausgeprägt (in meinen nicht trainierten Augen). Aber alles in allem ist jetzt für mich madVR der Renderer der Wahl.

Edited by blasgl

Share this post


Link to post
CiNcH

 

egal ob Formaterkennung an oder aus ist.

 

Hier nicht. Hier wird korrekt 20ms angezeigt, wenn die Formaterkennung im DVBViewer aktiviert es. Evtl. musst du dazu den Graph rebuilden.

Share this post


Link to post
blasgl

OK, jetzt habe ich´s! Mit Formaterkennung 20ms Frame-Zeit

Edited by blasgl

Share this post


Link to post
Donald24

Hi,

kurze Frage: Ist es normal, dass es auf einem Zweitmonitor MadVR nicht harmoniert mit DVBViewer? Die haben beide diesselbe Frequenz und Auflösung, UHD@60hz. Hatte dasselbe aber mit meinem alten secondary 1280x1024@50hz. Die ganze Zeitabfolge der einzelnen Frames kommt mir durcheinander gewürfelt vor, Laufschrift wackelt 80px von links nach rechts. Hab jetzt alles mögliche ausprobiert mit LAV und es passiert bei progressiv genauso wie interlaced. Selbst ohne DXVA und Verbesserern (Smoothmotion, Deinterlacing) deaktivert kommt es dazu. Manchmal läuft es sogar ganz gut im Fenster, spätestens wenn ich Vollbild im Secondary aufmache -> Chaos.

Auf dem Hauptschirm läuft dabei IMMER alles super. Kann mir keinen Reim draus machen... Es spielt auch keine Rolle, ob Nvidia den Secondary darstellt, oder die integrierte Intel HD530. Im cEVR ist alles normal, nur fehlt mir wirklich die Brillianz und das Smoothmotion von MadVr.

 

Windows10 + GTX980TI

Share this post


Link to post
madshi

Welches OS? Hast Du im GPU Control-Panel irgendwas in Sachen VSync oder so verstellt? Hast Du D3D11 presentation aktiviert? Falls ja, versuch das mal zu deaktivieren.

Share this post


Link to post
nuts

Ich verwende auch einen Kontrollmonitor im "Clone" Modus (TV und Monitor mit gleicher Auflösung und Wiederholungsfrequnez) und das funktioniert einwandfrei.

Sollte also ganz grundsätzlich klappen.

Share this post


Link to post
Donald24

Welches OS? Hast Du im GPU Control-Panel irgendwas in Sachen VSync oder so verstellt? Hast Du D3D11 presentation aktiviert? Falls ja, versuch das mal zu deaktivieren.

Punktlandung Madshi!!! D3D11 presentation war es - Ich bin sehr beeindruckt!

 

Warum war das nur aktiviert...

 

Danke!

 

Don

Edited by Donald24

Share this post


Link to post
madshi

Naja, eigentlich sollte es ja auch funktionieren. Weiß halt nur, daß es bei vielen Intel-Usern-Probleme macht, deshalb war das nur so eine Idee. Keine Ahnung, warum es Schwierigkeiten macht, kann es leider auf meinem PC nicht reproduzieren. Ist aber eigentlich auch nicht so schlimm, D3D9 funktioniert ja einwandfrei, und ist auch der Default. Allerdings wird D3D11 für 3D-Playback benötigt (3D Blu-Ray).

Share this post


Link to post
craig_s

Auf der positiven Seite muss ich sagen, ich habe jetzt einen Einstellungssatz für madVR gefunden, der mein Intel NUC nicht überfordert und einen deutlichen Qualitätsgewinn mit sich bringt.

 

... ...

 

Bei 720p oder 1080i ist der Unterschied zum Custom Renderer mit DXVA Scaling nicht sonderlich ausgeprägt (in meinen nicht trainierten Augen). Aber alles in allem ist jetzt für mich madVR der Renderer der Wahl.

 

Worin liegt jetzt der deutliche Qualitätsgewinn?

Share this post


Link to post
blasgl

Ist es normal und gewollt, dass die Vor- und Rückspulfunktionen DVBViewer-seitig deaktiviert sind, wenn madVR als Renderer selektiert ist? Ich kann nur noch durch eine Aufnahmen vor- und zurückspringen, aber nicht mehr spulen.

 

Und wird die Pausefunktion eventuell überdacht, wo ein falsch skaliertes Screenshot angezeigt wird?

Share this post


Link to post
CiNcH

Ich habe gerade 0.90.3 registriert und DX11 mit der HD 4000 probiert. Gibt jetzt plötzlich keine Rücksprungbilder mehr. Weiß nicht, welche Version das nun genau für mich fixt. Ich hatte eigentlich alle probiert, die laut Changelog in der Richtung eine Veränderung gebracht haben könnten...

Share this post


Link to post
madshi

Oh, das überrascht mich!! Weiß ehrlich gesagt nicht, welche Änderung da vielleicht geholfen hat! Vielleicht ist es ja auch einfach nur "Glück", und nach dem nächsten Reboot sind die Rücksprungbilder wieder da? Leider ist das Problem bei mir ja nie aufgetreten (auch HD4000). Für Frame-Packing-3D-Ausgabe wird DX11 benötigt, von daher wäre das eine ziemlich gute Nachricht, wenn das Problem wirklich weg wäre!

Share this post


Link to post
CiNcH

Auch nach Neustart ist noch alles gut.

 

Mit 0.89.19 ist auch alles sauber. Gehe ich dann auf 0.89.4, habe ich wieder Rücksprungbilder, im Vollbild (FSE oder Windowed) sehr viel mehr als im kleinen Fenster. Ich habe natürlich darauf geachtet, dass im OSD immer DX11 angezeigt wurde...

 

Irgendwo zwischen 0.89.4 und 0.89.19 muss was gutes passiert sein ;) .

Share this post


Link to post
madshi

Dann ist es mit ziemlicher Sicherheit v0.89.12:

 

* fixed: potential cause for "old frame" flickering when using smooth motion
* fixed: potential cause for "old frame" flickering in new windowed/FSE modes
Cool, bin ziemlich froh, daß das Problem nun scheinbar gelöst ist!! :D
Edited by madshi

Share this post


Link to post
CiNcH

Ich dachte, diese Version hätte ich auf Grund des Changelogs geprüft, mit negativem Ergebnis. Werde das aber gleich nochmal wiederholen.

Share this post


Link to post
madshi

Hatte eigentlich auch gedacht, daß Du die Version schonmal getestet hattest. Aber ansonsten finde ich im Changelog nichts, was die Problembehebung erklären würde. Außer, es hatte vielleicht irgendwas mit DXVA zu tun. Da gab's noch ein paar kleinere Fixes in v0.89.13 und v0.89.15.

Share this post


Link to post
CiNcH

0.89.12 hat in der Tat die Rücksprungbilder. Habe mich also nicht geirrt. Also ist zwischen 0.89.12 und 0.89.19 was gutes passiert ;) .

Share this post


Link to post
CiNcH

0.89.13 fixt die Rücksprungbilder.

Share this post


Link to post
madshi

Oh, interessant! Hmmmm... In 0.89.13 hab ich recht viel geändert, u.a. hatte ich dort schon (versteckt) die 3D-Unterstützung halbwegs eingebaut, und dabei einiges im Quellcode umgestellt. Von daher bin ich mir nicht ganz sicher, welche der Änderungen das Problem behoben hat. Ich hab da ein oder zwei Änderungen im Verdacht. Aber ist ja eigentlich auch egal, hauptsache das Problem ist weg!

Share this post


Link to post
CiNcH

Was genau wird da nun in DX11 gemacht? Ich erinnere mich von dir gelesen zu haben, dass die Pipeline weitestgehen die gleiche ist zur DX9.

Share this post


Link to post
madshi

Ja, das Rendering selbst ist eigentlich genau das gleiche, immer noch alles in DX9 (außer ein paar wenigen Ausnahmen wie Error Diffusion und NNEDI3). Nur die Präsentation läuft dann über DX11. Das funktioniert so, daß ich ein eigenes DX9-Device habe für das Rendering und ein getrenntes DX11-Device für die Präsentation. Der Vorteil von DX11 ist, daß es 3D mit "frame packing" über HDMI 1.4+ unterstützt (allerdings erst ab Windows 8.1), und daß es native 10bit-Ausgabe erlaubt (nur im Fullscreen-Exclusive-Mode). Außerdem ist DX11 manchmal ein bißchen schneller beim hin- und herschalten zwischen Exclusive und nicht-Exclusive.

 

Wenn Du die Option "use a separate device for presentation" aktivierst hast (bei deaktiviertem DX11), verwendet madVR übrigens auch bei DX9 zwei getrennte Devices, wieder eines für Rendering und eins für Präsentation, wobei dann halt beide DX9 sind. Bei vielen Usern bringt das tatsächlich einen kleinen Vorteil in Sachen Performance und Stabilität der Queues, weil sich Rendering und Präsentation dann wahrscheinlich nicht mehr um die Kontrolle über das DX-Device streiten (critical sections usw).

 

Das Problem mit den Rücksprungbildern trat glaube ich immer dann auf, wenn Rendering und Präsentation auf unterschiedlichen DX-Devices gemacht wurde. Wenn zwei Devices sich Texturen teilen, muß halt sorgfältig darauf geachtet werden, daß das Device A wirklich mit der Texture fertig ist, bevor Device B darauf zugreift. Da muß dann an der richtigen Stelle Device A abgefragt werden und darauf gewartet werden, daß Device A wirklich fertig ist. Und da fehlte scheinbar in v0.89.12 irgendwo ein "flush & wait". Wobei das komischerweise nur bei Intel Probleme gemacht hat, und auch nur bei einigen Usern...

Share this post


Link to post
CiNcH

 

Wenn Du die Option "use a separate device for presentation" aktivierst hast (bei deaktiviertem DX11)

 

Das Problem mit den Rücksprungbildern trat glaube ich immer dann auf, wenn Rendering und Präsentation auf unterschiedlichen DX-Devices gemacht wurde.

 

Genau, damit hatte ich auch das Problem mit den Rücksprungbildern.

Share this post


Link to post
madshi

Gibt's denn jetzt noch irgendwelche ungelösten Probleme?

Share this post


Link to post
CiNcH

Fällt mir im Moment nichts mehr ein. Läuft hier super stabil und flüssig.

 

Fehlt im DVBViewer nur noch ein verbesserter Support für madVR:

 

- Stop/Pause OSD Rendering

- unsichtbares Panel beim Umschalten das ein kurzes Verlassen des FSE verursacht

Share this post


Link to post
Griga
- unsichtbares Panel beim Umschalten das ein kurzes Verlassen des FSE verursacht

 

Welches unsichtbare Panel bei welchem Umschalten? Ich kann hier nichts dergleichen orten.

Share this post


Link to post
madshi

Fällt mir im Moment nichts mehr ein. Läuft hier super stabil und flüssig.

 

Cool, da freue ich mich!

Share this post


Link to post
CiNcH

 

Welches unsichtbare Panel bei welchem Umschalten? Ich kann hier nichts dergleichen orten.

 

KLICK

Share this post


Link to post
nuts

Die Low Latency Geschichte ist auch noch nicht im DVBViewer oder?

http://forum.doom9.org/showthread.php?t=146228&page=1587

 

Wobei davon einige Dinge in madVR wegen Problemen wieder zurückgebaut wurden?

Vielleicht kann madshi das nochmal zusammenfassen wenn schon alle hier versammelt sind? :)

 

P.S. Bei mir läuft 0.90.3 auch gut (bis auf den NVIDIA 3D Bug). Was mich noch etwas stört ist das madVR "Zwangs" OSD beim switch zwischen FSE/window Modus. Ist aber kein großes Problem.

Edited by nuts

Share this post


Link to post
Griga
KLICK

 

 

Oh Mann, das ist ja schon Jahre her. Und das habe ich damals tatsächlich geschrieben? :)

 

Ich hatte jetzt nur die Senderumschaltung überprüft, und dabei war mir nichts in der Art begegnet. Was mir hier allerdings reproduzierbar begegnet, ist, dass MadVR nach einem H.264 <-> MPEG2 Wechsel bei der Umschaltung nicht mehr das exklusive Vollbild verlassen will. Das Bild bleibt stehen, ein Doppelklick bewirkt nichts, und ich muss Strg + Alt + Entf bemühen, um aus der Falle rauszukommen.

 

Allerdings ist meine MadVR-Version (0.89.13) vermutlich ebenso uralt wie mein vergessener Beitrag. Wo gibt es noch mal eine aktuelle?

Share this post


Link to post
CiNcH

 

Allerdings ist meine MadVR-Version (0.89.13) vermutlich ebenso uralt wie mein vergessener Beitrag. Wo gibt es noch mal eine aktuelle?

 

Immer hier.

Share this post


Link to post

Join the conversation

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

Guest
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...