Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Beim LAV passt das ja auch, selbst auf "Auto". Damit ist der PDVD10 schonmal gestorben zum Testen.

 

Ich weiß nicht welches Prob du mit Deinterlacing hast. Evl. AMD spezifisch? Auf Intel hab ich dafür nichts eingestellt, es lief einfach. Umschaltung 576i - 720p - 1080i rel. flott mit LAV DXVA2 Copy back, bei LAV sonst nichts verstellt. In madVR wegen Deinterl. auch nichts verstellt.

 

Wegen den PDVD Decodern habe ich bemerkt das es doch nicht egal ist - nimm den neuen von 2014 der heißt PDVD Generic und spart nochmal etwas. zB:

LAV CopyBack + Lanczos-4 - 720p -> @1080 skaliert (FullScreen) - GPU 98% ~47W (ruckelt nicht)

da schafft PDVD Generic auf SW gestellt 44W was eine ganze Menge ist da oben.

 

Das ganze auf Intel aber ich denke so viel Unterschied ist nicht zu AMD.

Link to comment

Steht doch eigentlich da, den PDVD10 auf SW und schon geht da keine Erkennung ob interlaced oder progressive. Und der PDVD Generic geht nicht mit MPEG, da bleibt das Bild Schwarz.

Link to comment

So, hier mal kurz 2 Beispiele der Statistics zum Zeitpunkt des Drop/Repeats:

 

 

CPU/GPU-Queue: 16/8

 

decoder queue: 1-16/16

upload queue: 1-8/8

deinterlace queue: 1-8/8

split queue: 1-8/8

render queue: 1-8/8

present queue: 0-7/8

 

 

CPU/GPU-Queue: 32/16

 

decoder queue: 2-19/32

upload queue: 2-16/16

deinterlace queue: 2-16/16

split queue: 1-15/16

render queue: 1-15/16

present queue: 0-8/8

Link to comment
Sollte man nicht einen öffentlichen Beta-Test zum Thema machen, wie damals beim EVR Custom?

 

Wäre dem auch nicht abgeneigt.

Ansonsten lese ich hier erstmal einfach nur im Stillen mit.

 

btw.

Jungs, ich finde das einfach mal klasse, das ihr jetzt beim MadVR so viel Zeit investiert,

und euch da so reinkniet

Mir fehlt dafür leider einiges an Hintergrundwissen.

Meinen herzlichen Dank dafür.

Link to comment

Da der MadVR ja nur eine zusätzliche Sache ist und keine vorhandene Funktionalität ersetzt, ist ein öffentlicher Beta Test nicht unbedingt nötig. Wer probleme hat kann ja immer zu den jetzt schon vorhandenem Möglichkeiten zurück wechseln ;)

 

Derzeit gibt es auch noch probleme bei OSD Seiten wo die TV wiedergebe in einem kleinen Fester läuft (da Fehlt dann die OSD Seite und das Video läuft mit der letzten OSD Seite davor im kleinen Fenster) und bei HbbTV Seiten wo das Video in einem Fenster läuft (da läuft das Video im Hintergrund im Vollbild und man sieht nur einen ausschnitt).

 

(keine Ahnung ob Christian schon was davon gelöst hat, aber das ist der stand der letzten internen Beta)

Link to comment

Der FTA-Kanal 'Servus TV HD' fährt einen Video/PCR-Offset von ~1.2s. Also eher unproblematisch mit der DVBSource Default-Latenz. Problematisch scheint es nur bei Sky zu sein.

Link to comment

Laut Christian sind die zwei Punkte behoben und damit hoffentlich auch die letzten Show stopper.

Müssen wir dann schauen wenn die neuste Version online ist.

 

Grundsätzlich finde ich öffentliche Beta Test nicht schlecht um noch ein paar Eindrücke mit anderer Hardware zu bekommen.

Link to comment

Der FTA-Kanal 'Servus TV HD' fährt einen Video/PCR-Offset von ~1.2s. Also eher unproblematisch mit der DVBSource Default-Latenz. Problematisch scheint es nur bei Sky zu sein.

 

Der FTA 'Sky INFO' scheint auch im 1.x Bereich zu sein? Obs mal wieder auch am Entschlüsseln liegt, wie damals?

Link to comment

 

Der FTA 'Sky INFO' scheint auch im 1.x Bereich zu sein?

 

Ah, den kannte ich noch nicht, bzw. dachte ich, der wäre SD... also noch ein 1080i FTA Kanal... Der ist bei den Sky typischen 850-900ms.

 

 

Obs mal wieder auch am Entschlüsseln liegt, wie damals?

 

Damals? Es kann sein, dass der Treiber da andere Paketgrößen liefert, was ich jedoch bezweifle. IMHO liegt das Problem klar auf der Hand und ist mit den aktuellen Erkenntnissen auch erklärbar. Außer halt dass der Puffer mit LAV und DXVA so stark einbricht nicht...

Link to comment

Ein, wie von madshi angesprochener adaptiver Latenzwert, der vom Video-PCR/Audio-Offset abhängt, macht wohl keinen Sinn bzw. ist nicht so leicht umsetzbar? Eine sinnvolle Formel dafür mag mir selber nicht einfallen, sprich für welchen Offset welche Latenz sinnvoll ist.

 

Sowas ist jedenfalls nicht ad hoc realisierbar.

 

Als erstes müsste man den Offset messen. Wenn man die zwei nächstbesten PCR/PTS aus dem Mux herausgreift, kann das aufgrund verschiedener Faktoren mit einem relativ großen Fehler behaftet sein. Nur eine Mittelwertbildung über einen längeren Zeitraum würde genauere Resultate liefern - indiskutabel für den vorgesehenen Zweck.

 

Sobald die erste PCR oder Audio PTS da ist, berechnet der DVBSource mittels aktueller DirectShow Streamtime und konfigurierter Latenz einen Wert, der fortan von den DVB PTS subtrahiert wird, um DirectShow PTS zu erhalten. Wenn zu diesem Zeitpunkt schon eine Video PTS vorliegt, kann man zumindest einen ungefähren Offset zu PCR/Audio berechnen und Latency entsprechend modifizieren. Falls nicht, heißt es jedoch warten... und was macht man derweilen? Keine Zeitstempel generieren? Erst mal welche mit unmodifizierter Latenz?

 

Und dann stellt sich die Frage: Wie modifizieren? Das dürfte eine ziemlich heuristische Angelegenheit mit viel Herumprobieren werden ;)

Link to comment

Steht doch eigentlich da, den PDVD10 auf SW und schon geht da keine Erkennung ob interlaced oder progressive. Und der PDVD Generic geht nicht mit MPEG, da bleibt das Bild Schwarz.

 

@ Tüftler: funktioniert denn H.264-Bitstream mit PDVD-Dekoder und madVR ?

Im MPC-HC funktioniert das mit dem PDVD12-Dekoder irgendwie nicht. Der Dekoder zeigt (mit gedrückter Strg-Taste) Profile SW an.

Mit Intel-HD Grafik + Win 8.1

DXVA ist eingestellt und mit EVR steht dann da "Bitstream"

Edited by gwr
Link to comment

Als erstes müsste man den Offset messen. Wenn man die zwei nächstbesten PCR/PTS aus dem Mux herausgreift, kann das aufgrund verschiedener Faktoren mit einem relativ großen Fehler behaftet sein. Nur eine Mittelwertbildung über einen längeren Zeitraum würde genauere Resultate liefern - indiskutabel für den vorgesehenen Zweck.

 

Nee, ganz im Gegenteil: Gerade die Mittelwertbildung über einen längeren Zeitraum halt ich für eine gute Lösung. Mein Vorschlag wäre, für jeden Kanal mit einem hoch gegriffenenen Wert als Default anzufangen, damit alles flüssig und ohne Probleme läuft - aber mit relativ langen Kanalumschaltzeiten. Dann, wenn der User über längere Zeit einen Kanal guckt, könnte eine Mittelwertbildung laufen, oder irgendein anderes statistisches Maß, welches in dieser Situation Sinn macht. Erst, wenn der User mindestens z.B. 10 Minuten auf einem Kanal guckt, würde diese statistische Auswirkung dann ein Ergebnis liefern und dieses würde dann als neuer Latenz-Wert für diesen Kanal gesetzt werden. So würden sich die Kanalumschaltzeiten praktisch im Laufe der Zeit "von selbst" auf optimale Werte einstellen.

 

(Möglicherweise müßte parallel dazu noch ein Watchdog laufen, der sicherstellt, daß nicht aufgrund einer zu niedrig eingestellten Latenz alles völlig in die Hose geht. Falls so eine Notsituation erkannt wird, müßte die Latenz für diesen Kanal halt wieder hochgeschraubt werden.)

Edited by madshi
Link to comment

Ich habe jetzt mal auf einem HD Austria Kanal, also mit recht hohem Video/PCR-Offset von 1.3s, und ebenso hoher DVBSource Latenz von 400ms im Overlay Modus getestet. Da sehe ich noch sehr viel öfter diese Repeat/Drops. Die Decoder-Queue ist hier allerdings stets voll. Die Queue der Ausgabe-Buffer ist mit 3 im Overlay Modus natürlich recht dünn und läuft sehr oft leer (alle paar Minuten).

 

Hier die Queues bei einem Drop/Repeat im Overlay:

 

decoder queue: 30-32/32

upload queue: 15-16/16

deinterlace queue: 14-16/16

split queue: 13-16/16

render queue: 12-16/16

backbuffer queue: 0-3/3

 

Das ist dann aber nicht mehr die Schuld von LAV!?

 

Hier vom Default abweichende Settings:

- enable windowed overlay

- 10bit image/chroma buffer

 

GPU-Last: 70% @ 900MHz (8.2W)

 

Die GPU ist also noch weit vom Anschlag entfernt.

 

In den Rendering Stats dauert bei mir der "split" mit 8ms im Schnitt besonders lange. Bei 50fps bzw. einem Frame-Interval von 20ms ist das halt schon recht viel...

Link to comment

Mein Vorschlag wäre, für jeden Kanal mit einem hoch gegriffenenen Wert als Default anzufangen, damit alles flüssig und ohne Probleme läuft - aber mit relativ langen Kanalumschaltzeiten. Dann, wenn der User über längere Zeit einen Kanal guckt, könnte eine Mittelwertbildung laufen, oder irgendein anderes statistisches Maß, welches in dieser Situation Sinn macht. Erst, wenn der User mindestens z.B. 10 Minuten auf einem Kanal guckt, würde diese statistische Auswirkung dann ein Ergebnis liefern und dieses würde dann als neuer Latenz-Wert für diesen Kanal gesetzt werden. So würden sich die Kanalumschaltzeiten praktisch im Laufe der Zeit "von selbst" auf optimale Werte einstellen.

Hehe ich glaube das geht nicht! Dann müsste der Latenz-Wert für jeden Sender in der Senderliste (channels.dat => Änderungen sehr problematisch :D ) hinterlegt werden und wäre so oder so "eine ziemlich heuristische Angelegenheit".

Sinn macht das nur wenn man innerhalb der Latenz-Zeit feststellen könnte ob diese nicht zu hoch eingestellt ist und man dann eine Anpassung vornehmen könnte.

Vielleicht kann man in Richtung "auto Latenz-Erhöhung" experimentieren?

Quasi wenn der Offset innerhalb der eingestellten Latenz-Zeit > X, dann erhöhe Latenz selbstständig auf Y.

Edited by nuts
Link to comment

Ich habe jetzt mal auf einem HD Austria Kanal, also mit recht hohem Video/PCR-Offset von 1.3s, und ebenso hoher DVBSource Latenz von 400ms im Overlay Modus getestet. Da sehe ich noch sehr viel öfter diese Repeat/Drops. Die Decoder-Queue ist hier allerdings stets voll. Die Queue der Ausgabe-Buffer ist mit 3 im Overlay Modus natürlich recht dünn und läuft sehr oft leer (alle paar Minuten).

 

Hier die Queues bei einem Drop/Repeat im Overlay:

 

decoder queue: 30-32/32

upload queue: 15-16/16

deinterlace queue: 14-16/16

split queue: 13-16/16

render queue: 12-16/16

backbuffer queue: 0-3/3

 

Das ist dann aber nicht mehr die Schuld von LAV!?

 

Nee, das hat vielleicht nicht mal was mit der Latenzzeit zu tun, bin mir nicht ganz sicher. Vielleicht hilft das Erhöhen der Backbuffer-Queue? Der Split tut natürlich auch weh mit 8ms, aber das sollte eigentlich die CPU machen, sollte also eigentlich nicht von der GPU-Zeit abgehen. Trotzdem wäre es mal interessant, das mit aktivierten "don't use copyback" in madVR zu testen, dann findet kein Split mehr statt. Der "Split" ist praktisch das Hin- und Her zwischen GPU und CPU per Copyback, um die DXVA-Ausgabe verlustfrei den D3D PixelShadern zugänglich zu machen.

 

Aber der Overlay-Mode ist eigentlich eh nur noch als Notlösung gedacht für Leute, bei denen der normale Windowed-Mode nicht gut läuft (aus welchen Gründen auch immer). Der normale Windowed-Mode mit eingeschaltetem DWM läuft inzwischen eigentlich recht gut, besonders bei Windows 8. Problematisch sind Windows Vista und XP. Dort macht Overlay wahrscheinlich am meisten Sinn...

Link to comment

 

Der "Split" ist praktisch das Hin- und Her zwischen GPU und CPU per Copyback

 

Die ganze "copyback" Geschichte ist mir immer noch so ein bisschen ein Rätsel. Jetzt sehe ich, dass wenn Source-Auflösung != Ausgabe-Auflösung (z.B. TELE5 HD mit 1440x1080 bei 1920x1080) laut Statistics kein Split vollzogen wird. Ist das, weil DXVA2 da Deinterlacing+Chroma+Scaling macht?

 

Wann wird nun wirklich ein "copyback" gemacht? Nach meiner Logik...

 

LAV + DXVA2 (native): kein copyback

LAV + DXVA2 (copy back): copyback

LAV + DXVA2 (native) + 'don't use "copyback"': kein copyback

LAV + DXVA2 (copy back) + 'don't use "copyback"': kein copyback

 

??? Wenn ich 'DXVA2 (native)' nutze, wieso habe ich dann trotzdem irgendwo irgendwann "copyback"? Die Option hat jedenfalls definitv Auswirkungen auf die GPU-Last.

 

 

 

Trotzdem wäre es mal interessant, das mit aktivierten "don't use copyback" in madVR zu testen

 

Wird gemacht.

Link to comment

 

@ Tüftler: funktioniert denn H.264-Bitstream mit PDVD-Dekoder und madVR ?

Im MPC-HC funktioniert das mit dem PDVD12-Dekoder irgendwie nicht. Der Dekoder zeigt (mit gedrückter Strg-Taste) Profile SW an.

Mit Intel-HD Grafik + Win 8.1

DXVA ist eingestellt und mit EVR steht dann da "Bitstream"

 

Ich antworte mir mal selbst,

Wenn der Cyberlink-Dekoder auf "HAM" steht, funktioniert "Bitstream" bei MPEG2 und H.264 mit madVR und EVR (mit/ohne Custom)

ob das ne gute Kombi ist, weiss ich aber noch nicht

Link to comment

Ja, das ganze Thema ist recht kompliziert. Das Hauptproblem mit DXVA ist, daß Direct3D PixelShader kein 4:2:0 oder 4:2:2 verarbeiten können. Und DXVA gibt gerne NV12 aus, also 4:2:0. Das heißt, wenn madVR Chroma Upsampling machen soll, muß ich es irgendwie hinkriegen, das von DXVA kommende NV12 zu umzuwandeln, daß ich es von D3D PixelShadern aus ansprechen kann. Das geht nur, indem ich die Y und CbCr Channels trenne und in einzelne D3D-Texturen mit unterschiedlichen Auflösungen speichere, von denen D3D dann glaubt, daß RGB drin wäre (was aber nicht ist). Diese Umwandlung von einer DXVA-NV12-Surface in getrennte D3D-Texturen kann man per CPU machen (copyback, oder im Debug-OSD "Split" genannt, weil die NV12-Surface dann per CPU in zwei getrennte D3D-Texturen gesplittet wird), oder man kann OpenCL dafür verwenden, was aber zumindest bei AMD relativ langsam läuft. Bei Intel wäre OpenCL noch einen Versuch wert, dazu könntest Du testhalber mal die Option "use OpenCL to process DXVA NV12 surfaces" aktivieren. Die dritte Möglichkeit ist, die DXVA-NV12-Surface per D3D-API, z.B. per "StretchRect" oder per DXVA einfach in eine RGB-Texture umzuwandeln. Wie die GPU dann aber da das Chroma-Upsampling macht und welche Matrix für die YCbCr -> RGB Umwandlung gemacht wird, steht in den Sternen. In diesem dritten Fall untersucht madVR deshalb genau, was die GPU macht und versucht, das ganze soweit wie möglich rückgängig zu machen, um wieder die ursprünglichen YCbCr 4:2:0 Kanäle zu bekommen. Diese dritte Möglichkeit läuft rein auf der GPU ab, ist aber nicht ganz lossless. Die dritte Möglichkeit findet statt, wenn das Copyback disabled ist und wenn auch OpenCL disabled ist. Dieser ganze Absatz bezieht sich jetzt aber nur auf die Situation, wenn DXVA NV12 ausgibt, was nur der Fall ist, wenn DXVA Scaling deaktiviert ist.

 

Bei aktiviertem DXVA Scaling schaltet madVR DXVA auf RGB-Ausgabe um. Der Grund dafür ist, daß ein Scaling mit dem Zielformat NV12 zum einen nicht gut klappt (die Zielauflösung muß dann durch 4 teilbar sein usw), und zum anderen würde dann das DXVA-Scaling sowohl chroma als auch luma scalen, ohne aber bei 4:4:4 anzukommen, also müßte madVR nachher zusätzlich nochmal Chroma Upsampling machen. Das macht nicht so viel Sinn, deshalb schaltet da madVR gleich auf RGB-Ausgabe. Es ist aber dann wiederum so, daß die YCbCr -> RGB Matrix unbekannt ist, und madVR möchte da eigentlich Kontrolle drüber haben. Also untersucht madVR wiederum, was DXVA denn da gemacht hat und versucht das wieder rückgängig zu machen. madVR wandelt also die DXVA RGB Ausgabe zurück nach YCbCr, aber in 4:4:4, und wendet dann die eigene Matrix an, um wiederum RGB zu kriegen. Bei all diesen Dingen würde Copyback nichts bringen, deshalb gibt's bei aktivem DXVA Scaling kein "Split" im Debug-OSD.

 

Hab nochmal über die zusätzliche "trade quality for performance" Option nachgedacht. Ich denke, ich würde sie "use DXVA for chroma upsampling, scaling and color conversion" nennen. Ich würde dann DXVA grundsätzlich auf RGB-Ausgabe umschalten und dann das RGB einfach so lassen wie es ist, also sämtliche oben beschriebenen zusätzlichen Arbeitsschritte einfach weglassen. Außerdem würde ich DXVA grundsätzlich für alle 4:2:0 Quellen aktivieren, egal ob gescaled werden muß oder nicht. Das ganze sollte dann relativ nah an einem rein durch DXVA betriebenen EVR sein, auch von der GPU-Belastung her (hoffe ich). Natürlich gäb's noch den abschließenden Schritt mit eventuellem Output-Levels-Adjustment, OSD-Drawing und Dithering, und eventuell zusätzliche Schritte wie Debanding oder Kalibrierung usw. All diese Schritte kosten natürlich wieder ein bißchen Performance, aber das sollte nicht so extrem viel sein. Was ist nicht genau weiß, ist, wieviel die Performance leidet, wenn ich DXVA um 16bit- (oder 10bit-) RGB-Rendering bitte anstatt der normalerweise üblichen 8bit. Das könnte vielleicht auch noch ein bißchen extra GPU-Performance kosten. Aber auf 8bit runter möchte ich eigentlich nicht, wenn's nicht unbedingt sein muß, weil zumindest AMD und NVidia auch echte 16bit (oder 10bit) ausgeben, wenn ich sie drum bitte.

Link to comment

Puuuh, ich hätte nicht fragen sollen ;) . Nein, im Ernst, vielen Dank für den tiefen Einblick. Ich werde mir das noch ein paar Mal durchlesen müssen, bevor ich wirklich alles verstanden habe. Hat LAV "copyback" also nicht wirklich was mit madVR "copyback" zu tun? Außer LAV hat bereits ein "copyback" gemacht?

 

Overlay + "don't use copyback" ist noch wesentlich schlimmer. Alle paar Sekunden ein paar Repeat/Drops. Die GPU-Last steigt da auch ordentlich an, aber noch nicht ganz auf Anschlag (77% @ 1250MHz Turbo).

 

Overlay + "use OpenCL" verbessert die Situation nicht, läuft aber nicht so schlecht wie "don't use copyback". Scheinbar hat OpenCL keinen großen Einfluss auf das Problem.

Link to comment

Tja, wenn Du mich nach technischen Details fragst, mußt Du damit rechnen, erschlagen zu werden... :D

 

LAV copyback ist völlig getrennt. Wenn in LAV copyback aktiviert ist, wird nach dem DXVA-Decoding das Video-Frame zurück zur CPU kopiert, und dann madVR so übergeben, als käme es von einem Software-Decoder. Da kriegt madVR gar nix von mit. Allerdings: Wenn LAV copyback aktiv ist, und madVR dann auch nochmal DXVA-Deinterlacing macht, und copyback in madVR auch aktiv ist, wird jedes Videoframe quasi doppelt ge-copybacked. Einmal von LAV nach dem Decoding und einmal von madVR nach dem Deinterlacing. Da wäre es effektiver, eins von den copybacks wegzulassen, sprich DXVA Native zu benutzen.

 

Ich vermute dann fast, daß Overlay mit Software-Decoding auch nicht perfekt läuft?

Link to comment

Interessant die Sache mit dem doppeltem copyback.

Habe mir mal eine Nvidia GPU für Tests besorgt und am schnellsten scheint CUVID mit Deinterlacing im LAV zu sein.

Link to comment

Aktueller Commit vom LAV Autor:

 

dxva2: remove strict compliance hack

This should reduce H264 decoding delay in DXVA2 mode and ensure behaviour
of DXVA2 decoding and software decoding is the same.

 

Hört sich interessant an...

Link to comment

Damals? Es kann sein, dass der Treiber da andere Paketgrößen liefert, was ich jedoch bezweifle. IMHO liegt das Problem klar auf der Hand und ist mit den aktuellen Erkenntnissen auch erklärbar. Außer halt dass der Puffer mit LAV und DXVA so stark einbricht nicht...

Damals - beim 'bad error concealment' als u.a. auch CI-Module glitches verursachen konnten. Ist natürlich ein anderes Thema aber Erinnerung schadet nie...

 

Tritt der drop/repeat demnach bei dir mit DXVA native auf?

Ich kann nur sagen das ich gestern wärend Tests stundenlang auf 'Sky INFO' starren durfte, teils mit LAV CopyBack / DXVA2 native, auch mit PDVD Generic auf SW, da ist mir kein Ruckler aufgefallen. Nur manchmal kurzes Pixelgewitter nach dem Umschalten des scalings im unteren Bilddrittel. Habe auch eben nochmal viel mit DXVA2 native probiert, läuft schön flüssig und ca. 10% sparsamer als CopyBack in allen 3 Formaten in allerhand mad-configs und kann die Fehler die ich vorgestern fand nicht mehr nachstellen. Evl. war ich da noch auf 'Aero aus' unterwegs.

 

Wenn ich PDVD Generic auf DXVA stelle fängt vieles in madVR an zu ruckeln. Merkwürdig - in den PDVD- Settings in DVBViewer's DirectX-Menü steht er dann immernoch auf SW, im 'Einstellungen-Filters-Menü auf DXVA.

Er läuft aber "richtig" auf SW sehr stabil mit madVR. Und sparsam:

 

PDVD Special

Mit dem permanenten Wattmeter immer im Augenwinkel bin ich über einen merkwürdigen Ausreisser gestolpert.

Der 'PDVD Generic auf SW' spart bei 720p upscaling ja schon einige % GPU load gegenüber 'LAV DXVA2 CopyBack'.

Aber bei 1080i Sendern ist die Ersparnis gewaltig. Das war etwa eine deiner Start-configs vor 3? Tagen:

 

LAV DXVA2 CopyBack

chroma up: Lanczos-4 AR

image up/down: DXVA

1080i (FullScreen) - GPU 84%, ~42W

 

du hast ja auch schon gesagt das PDVD Generic bei dir einiges spart aber hast mal gesehen wieviel?

 

PDVD Generic auf SW

chroma up: Lanczos-4 AR

image up/down: DXVA

1080i (FullScreen) - GPU 44%, ~25W <!

 

Das ist beispiellos, es gibt configs die können mal 10% sparen aber hier fast 50%?? Da geht auch noch Spline-4, ab Jinc geht GPU load hoch und es ruckelt. Ich sehe 2 Möglichkeiten:

entweder PDVD Generic macht hier irgendwas erstaunlich GPU-sparend

oder Settings im madVR werden ignoriert? Oder..?

 

Im Bild ist halt wieder kein Unterschied zu sehen - sicher ist aber das 1080i FullScreen mit 'PDVD Generic auf SW' wesentlich stressfreier läuft als mit LAV.

Könnte man also evl. empfehlen.

Link to comment

Der Cyerlink Software Decoder übergibt wahrscheinlich 25p anstatt 50p wie mit dem adaptiven GPU Deinterlacer.

Das passt zur GPU Last!

Empfehlenswert wäre das aber nicht ...

 

Mit den LAV Nightlys klappt noch nicht so wirklich oder? Letzte ist vom 06.01? Dachte die sollen täglich erstellt werden?

Edited by nuts
Link to comment

 

Mit den LAV Nightlys klappt noch nicht so wirklich oder? Letzte ist vom 06.01? Dachte die sollen täglich erstellt werden?

 

Ist dann morgen drin. Bin mir aber sicher, dass das Latenz-Problem damit vom Tisch ist.

Link to comment

 

Der Cyerlink Software Decoder übergibt wahrscheinlich 25p anstatt 50p wie mit dem adaptiven GPU Deinterlacer.

Das passt zur GPU Last!

 

Das ist richtig. Sky fährt außerdem immer noch überall 2:2 Kadenzen. D.h. weaven würde reichen. Das war schon zu SD Zeiten so. Deshalb dürfte es nicht weiter auffallen. Eigentlich traue ich mich fast nicht, das vor madshi zu sagen, aber seit die Deinterlacer so gut sind, ist es mir egal, ob das Material da auch noch durch geht. Ich weiß, ich bin ein Banause und des madVR nicht würdig ;) .

 

Bei Sky könnte man also noch einiges an GPU sparen...

Link to comment

Das ist nicht richtig.

Sportübertragungen haben echte 50i und da kann man nicht einfach 2 nachfolgende fields zusammenkleben.

 

Bei LiveTv begegnet man vielen Quellen und daher halte ich es für richtig fürs zapping den GPU Deinterlacer zu verwenden.

Für Filme kann man über Profile aber schon noch GPU Power für andere Dinge frei machen (oder Strom sparen)!

Hatten wir hier schon: http://www.DVBViewer.tv/forum/topic/37505-madvr-renderer-in-DVBViewer-nutzen/?p=420616

So eine Auto-Erkennung wäre schon toll. :)

Edited by nuts
Link to comment

Auf ProSieben HD läuft gerade "The Big Band Theory" mit 2:2 Kadenz...

 

 

Deinterlacing on

 

GPU: 70% @ 950MHz (8.7W)

 

 

Deinterlacing off

 

GPU: 50% @ 350MHz (4.6W)

Link to comment

Ja da müssen wir uns dann noch was einfallen lassen.

Mit dem EVR / EVR Custom ist das wegen der geringen Mehrbelastung ziemlich egal, aber bei madVR merkt man es schon deutlich.

 

Bei 720p50 hat man das Problem im Prinzip auch. :)

Weiss jemand wie die Ami Serien abgedreht werden? Auch in 24p?

Ich meine bei Nachrichten auf den ÖR's (SD) sieht man Deinterlacing Artefakte bei "deinterlacing off".

Link to comment

Die meisten neueren Serien sind auch in 24p gedreht. Es ist eigentlich nur Sport, Music-Concerts und ältere Serien, die echt Interlaced sind. Wir haben mit PAL aber auch Glück, daß man da einfach den Deinterlacer ausschalten kann. In den USA geht das gar nicht. Bei 50p Filmen kann man im Grunde auch jeden zweiten Frame wegschmeißen. madVR kann das theoretisch auch schon, aber das ist noch nicht ganz ausgereift...

 

Wer keinen Sport guckt, kann beim TV gucken eigentlich fast den Deinterlacer fest ausschalten. Ok, kann manchmal passieren, daß man ihn dann doch braucht. Ist dann natürlich doof, wenn das plötzlich Weaving-Artefakte kommen...

Link to comment

Für Filme kann man über Profile aber schon noch GPU Power für andere Dinge frei machen (oder Strom sparen)!

 

Wie gesagt, strom sparen triffts nicht, es geht drum ob jetzt ca. 2/3 der DVBViewler sich einen neuen HTPC zulegen sollen um in den Genuss der Vorzüge des Renderers madVR zu kommen.

Würdest du, ohne mit der Wimper zu zucken, ihnen dieses empfehlen?

 

Ja jetzt kommt 'aber sie müssen's doch nicht nehmen..' - Sie werden's aber wollen denn wozu wurde hier der ganze Aufwand betrieben wenn nicht für etwas ganz großariges...

Edited by craig_s
Link to comment

madVR ist ein Produkt für Enthusiasten und sollte momentan auch als solches verstanden werden. Es wurde desöfteren nachgefragt und wird deshalb in Zukunft als Option im DVBViewer vorgesehen. Wer die nötige Grafik- und Kühlleistung hat, kann madVR verwenden und hat bestimmt eine Menge Freude damit. Jedoch gibt es physikalische Gesetze, denen auch madVR unterliegt.

 

Natürlich lässt sich das eine oder andere noch optimieren. Wenn es zum Schluss allerdings nur noch ein weiterer EVR ist, hat auch niemand mehr was davon. Wir dürfen gespannt sein, was madshi in Zukunft noch umsetzen wird. Der DVBViewer und deine herablassenden Fragen werden an seinen Plänen jedoch nichts ändern. Im Gegenteil.

 

Ich kann nur wage abschätzen, wieviel Arbeit in madVR steckt und madshi stellt uns das allen umsonst zur Verfügung. Er hilft sogar noch bei der Integration in ein kommerzielles Produkt. Dafür sollten wir alle dankbar sein.

 

Hiermit möchte ich diese sinnfreie Diskussion beenden und wieder zum technischen Teil übergehen.

  • Like 1
Link to comment

Genau zurück zum technischen Teil ...

Ich hab noch ein Problem gefunden und zwar wenn man ein Video bis zum Ende laufen lässt crasht der DVBViewer mit madVR.

GPU Nvidia, Decoder LAV CUVID

Andere Hardware und Decoder muss ich nich testen.

Link to comment

You may be beta tester?

 

My pc is

System: Windows 8.1 update 1.
CPU: Intel® Core2 Quad Processor Q8200.
GPU: Ati R7 250 - 2 GB.
HDD: 160 GB - Sata 2.
TBS6982 DVB-S2 Dual Tuner PCIe Card.
AT0-051 ISDB-TB USB Full Seg/One Seg.
Edited by Residentcl
Link to comment

Kurzes Feedback zum LAV Nightly... die Puffer sehen jetzt gesund aus. Außerdem ist das Bild beim Umschalten jetzt wesentlich schneller da. Für Live-TV eine sehr gute Verbesserung. Vielen Dank an madshi und nevcairiel.

Link to comment

madVR ist ein Produkt für Enthusiasten und sollte momentan auch als solches verstanden werden. Es wurde desöfteren nachgefragt und wird deshalb in Zukunft als Option im DVBViewer vorgesehen. Wer die nötige Grafik- und Kühlleistung hat, kann madVR verwenden und hat bestimmt eine Menge Freude damit. Jedoch gibt es physikalische Gesetze, denen auch madVR unterliegt.

 

Natürlich lässt sich das eine oder andere noch optimieren. Wenn es zum Schluss allerdings nur noch ein weiterer EVR ist, hat auch niemand mehr was davon. Wir dürfen gespannt sein, was madshi in Zukunft noch umsetzen wird. Der DVBViewer und deine herablassenden Fragen werden an seinen Plänen jedoch nichts ändern. Im Gegenteil.

 

Ich kann nur wage abschätzen, wieviel Arbeit in madVR steckt und madshi stellt uns das allen umsonst zur Verfügung. Er hilft sogar noch bei der Integration in ein kommerzielles Produkt. Dafür sollten wir alle dankbar sein.

 

Hiermit möchte ich diese sinnfreie Diskussion beenden und wieder zum technischen Teil übergehen.

 

Danke... :D

 

 

Kurzes Feedback zum LAV Nightly... die Puffer sehen jetzt gesund aus. Außerdem ist das Bild beim Umschalten jetzt wesentlich schneller da. Für Live-TV eine sehr gute Verbesserung. Vielen Dank an madshi und nevcairiel.

 

Das hört sich super an! Werde das gleich mal an nevcairiel berichten...

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