Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Hier noch ein paar umfassendere Erklärungen zum Latency-Wert von Griga:

 

Eine Erhöhung verschiebt die Zeitstempel, die den Zeitpunkt der Wiedergabe bestimmen (PTS, Presentation Time Stamp), in die Zukunft. D..h. bei Live-Betrieb verlängert sich die Zeitspanne zwischen Ankunft und Wiedergabe der Daten im DVBViewer. Das Ergebnis ist eine erhöhte Pufferung (und damit erhöhter Speicherbedarf) im DVBViewer Filter und/oder nachfolgenden Wiedergabe-Komponenten, denn irgendwo müssen die Daten ja so lange bleiben. Außerdem verlängern sich die Sender-Umschaltzeiten. Auswirkungen hat man i.a. nur bei Video, da die Zeitstempel der Synchronisation zwischen Video und Audio dienen.

Eventuell muss man gleichzeitig den Wert für TV/Radio - Max. Queued Audio erhöhen, um zu verhindern, dass die Überpufferungskontrolle des DVBViewer Filters zuschlägt und einen Fehler an den DVBViewer meldet, der dann die Wiedergabe kurz anhält und gleich wieder startet, um die Sache in Ordnung zu bringen.

Eine unbekannte Größe in dem Spiel ist das Pufferungsverhalten der DVB-Gerätetreiber. Die Daten werden von ihnen nicht kontinuierlich, sondern stoßweise an den DVBViewer ausgeliefert - im allgemeinen immer, wenn ein Treiber-Puffer gefüllt ist. Wenn die Zeitspanne zwischen zwei Lieferungen zu lang wird, kann es zu den von dir beschriebenen Aussetzern kommen, weil die DirectShow-Komponenten nicht mehr in der Lage sind, die Lücke aus eigenen Puffern zu überbrücken.

Bei Dateiwiedergabe ist das kein Problem, da hierbei nach Bedarf gelesen wird. Bei Live-Betrieb kann der DVBViewer die "Daten-Produktionsrate" jedoch nicht steuen.

 

Die Default-Latency im DVBSource ist insbesondere auch ein Schutz gegen die nicht vorhersehbaren Pufferungs-Strategien von BDA-Treibern. Ein Extrem-Beispiel zur Verdeutlichung: FireDTV mit PID-Filterung bei Radioempfang. Der Treiber passt sich nicht an die niedrige Datenrate an. Resultat: Die Daten treffen stoßweise in Abständen von 2 Sekunden ein. Dies schafft für einen DirectShow-Graphen unakzeptable Timingverhältnisse. Er müsste viel mehr puffern, als er es normalerweise tut. Der DVBSource kann dies jedoch abfangen, wenn man Latency auf 2000 (!) oder höher stellt (plus erhöhtes Max. queued Audio) , was die Timestamps in Richtung Zukunft verschiebt und eine erhöhte Pufferung provoziert (kann man im DVBViewer Pro verifizieren - die GE nimmt ja als Workaround immer Nullpackets hinzu).

 

Auf der Eigenschaftsseite des DVBSource gibt es den Wert Latency. Er berücksichtigt die angenommene bzw. erfahrungsgemäße Laufzeit der Daten im Filtergraphen bis zu den Renderern. Wenn der Graph startet (Stop -> Run), beginnt seine Streamtime mit 0. Der DVBSource sogt dafür, dass das erste Audio-Sample den Präsentations-Zeitstempel "aktuelle Streamtime + Latency" erhält. Alle nachfolgenden DVB-Zeitstempel werden gemäß diesem Anfangswert auf Streamtime-relative Werte umgerechnet.

Link to comment

Mit welchen Decodern probiert ihr eigentlich?

Ich habe gestern mal kurz zum Test auf den PDVD10 umgeschaltet und den auf Software umgestellt. Craig_s hatte ja von einer geringeren Last geprochen und ich konnte das auch nachvollziehen.

Bei mir hing das aber erstmal mit was anderem zusammen:

Habe mir 3 Profile erstellt (SDi mit Upscaling durch SoftCubic; HDp mit Upscaling durch DXVA; HDi mit Upscaling durch DXVA) und er hat SD (Das Erste) als HD interpretiert was sich in einer anderen Profilnutzung zeigte.

Weiter habe ich das dann gestern aber erstmal nicht verfolgt (jedenfalls blieb das auch nach einem Graph Neuaufbau und sogar nach dem Viewer Neustart so).

Link to comment

Was ich allerdings immer noch beobachte sind "presentation glitches". Worauf basiert diese Anzeige? Der Auswertung der D3D/DWM Present-Stats? Meist inkrementiert dieser Counter um 2 innerhalb weniger Sekunden. Gestern habe ich das ca. alle 10 Minuten mit 1080i im Windowed Fullscreen beobachtet. Könnte das eines der von dir angesprochenen DWM-Probleme sein? Ich werde heute mal FSE probieren.

Der "presentation glitches" Zähler inkrementiert auch gerne, wenn ich künstlich die Systemlast anhebe. Drops oder Repeats werden jedoch keine registriert.

 

Korrekt, presentation glitches sind von D3D/DWM gemeldete Glitches, also durch Auswertung der Present-Stats (o.ä.) erfragte Glitches. Diese Glitches passieren im Windowed Mode gerne dann, wenn viel los ist. Der FSE Mode ist da wesentlich robuster, da gibt's Glitches eigentlich nur in Ausnahmefällen, oder wenn der GPU-Treiber einen Bug hat. Presentation glichtes sind außerhalb meiner Kontrolle, weil sie passieren, nachdem D3D schon längst die Frames bekommen hat.

 

Den Zusammenhang der Latency mit madVR und Frame Drops/Repeats ist mir immer noch nicht ganz klar. Kann nur vermuten, daß die Timestamps für madVR zu "wild" sind, bei niedriger Latency, und daß sich das irgendwie verbessert bei erhöhter Latenz. Auch wenn ich nicht ganz verstehe warum.

 

Hast Du mal versucht, statt 300 -> 600ms vielleicht nur ein bißchen zu erhöhen? Vielleicht reichen ja z.B. schon 400ms aus?

 

 

Mit welchen Decodern probiert ihr eigentlich?

Ich habe gestern mal kurz zum Test auf den PDVD10 umgeschaltet und den auf Software umgestellt. Craig_s hatte ja von einer geringeren Last geprochen und ich konnte das auch nachvollziehen.

Bei mir hing das aber erstmal mit was anderem zusammen:

Habe mir 3 Profile erstellt (SDi mit Upscaling durch SoftCubic; HDp mit Upscaling durch DXVA; HDi mit Upscaling durch DXVA) und er hat SD (Das Erste) als HD interpretiert was sich in einer anderen Profilnutzung zeigte.

Weiter habe ich das dann gestern aber erstmal nicht verfolgt (jedenfalls blieb das auch nach einem Graph Neuaufbau und sogar nach dem Viewer Neustart so).

 

Im Zweifelsfall immer LAV. Aber wenn Du mit PDVD10 wirklich eine niedrigere Last hast, ist das natürlich auch ok.

 

Wenn madVR regelmäßig Deine Profile falsch aktiviert, stimmt da vielleicht mit den Rules/Scripts was nicht? Wie sieht denn Dein Script aus?

Link to comment

 

Hast Du mal versucht, statt 300 -> 600ms vielleicht nur ein bißchen zu erhöhen? Vielleicht reichen ja z.B. schon 400ms aus?

 

Steht auf meinem "Testplan", sprich den Wert sukzessive in kleinen Schritte zu ändern. Die drastische Erhöhung war erstmal nur dazu gedacht, meine Vermutung zu bestätigen.

 

Ich glaube eher an einen Underrun, weil jemand ein bisschen verhungert...

 

 

 

Mit welchen Decodern probiert ihr eigentlich?

 

Ich verwende eigentlich nur noch LAV. Zu Testzwecken für die Astra H.265/HEVC UHD Streams verwende ich ab und zu den ganz aktuellen PDVD14 Dekoder, weil der da noch die etwas bessere Figur auf meinem langsamen i3-3225 macht.

Link to comment

Die Profile laufen ja sauber bei LAV ( ich frage die Auflösung und interlaced ab ) nur nicht bei PDVD10. Den 14'er kann man für mpeg nicht nehmen da gibt es nur H264 & HEVC. Wenn man den einstellt wird DirectShow die Auswahl überlassen.

Link to comment

Ich habe die Latenz jetzt mal testhalber auf 0 gestellt. Puffer sind damit nochmal deutlich weniger voll. Es dauert allerdings immer noch um die 5 Minuten, bis es einmal zu dem Problem kommt. Es sind aber wieder solche "Repeat-Drops". Kann das nicht normal sein? Werden, wenn keine Frames mehr gepuffert sind, keine Repeats gezählt? Zur Kompensation müssen dann wieder Bilder verworfen werden, wenn wieder welche eintreffen...

Link to comment

Ja, wenn die Decoder-Queue ausläuft, ist ein Repeat/Drop möglicherweise normal. Komisch ist nur, daß die Decoder-Queue sich dann scheinbar gleich wieder füllt. Wenn die Queue ausläuft, würde ich eigentlich erwarten, daß sie dann manchmal vielleicht auch für eine Weile leer bleibt. Aber das scheint ja nicht der Fall zu sein. So ganz durchschaue ich da die Zusammenhänge nicht...

Link to comment

Beim PDVD10 im Softwaremodus steht "deinterlacing off (says upstream)" beim LAV dagegen "on". Da kann meine Umschaltung also auch nicht funktionieren :mad:

Kann man da in den Optionen auf Seite von MadVR was dagegen tun denn es macht sicherlich keinen Sinn bereits im Decoder auf Hardware zu schalten (dann steht da nämlich "On")?

Link to comment

Im LAV gibt's ja noch zusätzliche Optionen zum Thema Deinterlacing wie z.B. "agressive" oder so ähnlich. Es ist halt so, daß man nicht immer nicht ohne weiteres erkennen kann, ob ein Videostream Deinterlacing braucht oder nicht. madVR richtet sich da mehr oder weniger danach, was der Decoder sagt. Der PDVD10 Decoder verhält sich da scheinbar etwas anders als der LAV, aber wie gesagt, beim LAV gibt's da noch entsprechende Optionen zu...

Link to comment

Zum Deinterlacing müssen wir uns dann auch mal noch Gedanken machen.

Wie schon weiter vorne im Thread erklärt halte ich für LiveTV (zapping) die Einstellung "agressive" (LAV) für "richtig", da es sehr viele verschiedene Quellen gibt (SD interlaced, SD progressiv, HD interlaced usw.).

 

Für einen Film (2:2 Kadenze) in 1080i50 macht es allerdings wenig Sinn den per adaptivem Deinterlacer auf 1080p50 aufzublasen und anschließend 50 Frames durch die madVR's Algos zu jagen.

Dort wäre ein Film-Modus "richtig" (1080i50 Quelle => Deinterlacer verlustfrei zu 1080p25 => madVR Algo's => frame doubling => 1080p50 Ausgabe) und würde kräftig GPU-Ressourcen sparen (gilt auch für EVR, aber dort eher akademisch).

Edited by nuts
Link to comment

Das gilt für 576i50-Filme im Grunde auch. Da kann man oft einfach den Deinterlacer ausschalten. Allerdings gibt's im TV oft auch Video-Overlays, die bei ausgeschaltetem Deinterlacer dann mit Combing-Artefakten dargestellt werden. Im Moment ist madVR (noch) nicht dazu in der Lage, zuverlässig zu erkennen, welcher Content ein Film und welcher Video ist. Der EVR übrigens auch nicht. Das plane ich in der Zukunft irgendwann einzubauen, aber das wird noch eine Weile dauern.

Link to comment

2 Stunden 1080i mit madVR im FSE mit 500ms DVBSource Latenz ohne jegliche "presentation glitches" und "repeated/dropped frames" :) . Mit den hohen Latenz-Werten ist die Dekoder-Queue mit 30-32/32 meist gut gefüllt. Aber es kommt immer wieder zu kleineren Einbrüchen. Ist die Latenz und somit der Puffer-Völlegrad geringer, könnte sich ein größerer Einbruch schon mal wie bekannt auswirken.

 

 

 

GPU-Last mit 720p50 Material und 1080p50 Ausgabe

 

Einstellungen:

Chroma Upsampling / Scaling: DXVA2

Dithering: aus

Deinterlacing: aus

10bit chroma/image buffer: ein

 

EVR: 30% @ 350 MHz (2.7W)

madVR: 72% @ 700 MHz (7.0W)

 

Die GPU macht da außer RGB-Konvertierung doch nicht mehr viel? Die GPU-Last mit i3-3225 bzw. HD 4000 zieht da aber augenscheinlich dennoch ordentlich an...

 

Interessant ist, dass bei 720p50 Material (ORF 1 HD, ORF 2 HD, Das Erste HD, arte HD) madVR ein "movie frame interval" von 40.00ms berichtet.

Link to comment

Klar gilt für jede interlaced Quelle, die ursprünglich mal progressiv war (wollte der Aussage mit 1080i50 mehr Gewicht geben ^^). :)

Eine gute Autoerkennung wäre was feines, aber ich befürchte nicht so einfach umzusetzen.

Videoprozessoren von DVDO hatten, zumindest früher, damit ständig Schwierigkeiten und deren Deinterlacer sind sonst ziemlich gut.

 

Auch mit den derzeitigen Mitteln (Profile, Scripte usw.) müsste sich einiges basteln lassen um beim zapping das Deinterlacing sicherzustellen und bei Filmen gezielt Ressourcen zu sparen bzw. für andere Dinge freizumachen.

Mal sehen ...

Link to comment

GPU-Last mit 720p50 Material und 1080p50 Ausgabe

 

Einstellungen:

Chroma Upsampling / Scaling: DXVA2

Dithering: aus

Deinterlacing: aus

10bit chroma/image buffer: ein

 

EVR: 30% @ 350 MHz (2.7W)

madVR: 72% @ 700 MHz (7.0W)

 

Die GPU macht da außer RGB-Konvertierung doch nicht mehr viel? Die GPU-Last mit i3-3225 bzw. HD 4000 zieht da aber augenscheinlich dennoch ordentlich an...

 

Interessant ist, dass bei 720p50 Material (ORF 1 HD, ORF 2 HD, Das Erste HD, arte HD) madVR ein "movie frame interval" von 40.00ms berichtet.

 

Das "movie frame interval" hängt davon ab, was der Decoder für eine Framerate meldet. Die ist scheinbar nicht korrekt.

 

Hmmmm... Wie hast Du die Device-Kalibrations-Settings eingestellt? "disable calibration controls"? Oder "this device is already calibrated"? Wenn das nicht auf "disable calibration controls" steht, und dann die Stream-Primaries nicht den Display-Primaries entsprechen, wandelt madVR die Primaries um. Das kostet schon etwas Performance. Ein weiterer Kostenfresser ist, daß madVR der DXVA-YCbCr->RGB Umwandlung nicht vertraut, und diese deshalb rückgängig macht und nachher nochmal selbst neu macht. madVR mißt zu diesem Zweck anhand eines Test-Images, was DXVA da genau macht, um das möglichst genau wieder rückgängig machen zu können. Das Rückgängig machen und "richtig" umwandeln kostet 2 extra Rendering-Schritte. Vielleicht sollte ich da noch eine Trade-Quality-Option für einfügen, daß madVR die DXVA RGB Umwandlung einfach akzeptiert? Das würde wahrscheinlich ordentlich Performance sparen...

Link to comment

Komisch ist nur, daß die Decoder-Queue sich dann scheinbar gleich wieder füllt. Wenn die Queue ausläuft, würde ich eigentlich erwarten, daß sie dann manchmal vielleicht auch für eine Weile leer bleibt. Aber das scheint ja nicht der Fall zu sein. So ganz durchschaue ich da die Zusammenhänge nicht...

 

Unabhängig davon, dass Daten durch die Pufferung im Treiber der DVB-Karte stoßweise eintreffen, muss man auf der Rechnung haben, dass Frames nicht unbedingt in der dargestellten Reihenfolge gesendet werden. Wenn die Video PTS nicht monoton steigen, sondern hin- und herspringen, ist ein Frame Reordering erforderlich. Damit dafür Zeit bleibt, wird Video oft mit einem deutlichen zeitlichen Vorsprung gegenüber Audio bzw. der PCR gesendet. Das sieht man, wenn man sich die originalen DVB-Zeitstempel auf der Eigenschaftsseite des DVBViewer Filters anschaut. Beim Ersten HD beträgt die Differenz z.B. mehr als eine Sekunde.

 

In diesem Fall ist nicht damit zu rechnen, dass Frames im Rhythmus der Darstellung eintreffen. Es kann zu "Stoßverkehr" kommen.

Link to comment

 

Unabhängig davon, dass Daten durch die Pufferung im Treiber der DVB-Karte stoßweise eintreffen, muss man auf der Rechnung haben, dass Frames nicht unbedingt in der dargestellten Reihenfolge gesendet werden. Wenn die Video PTS nicht monoton steigen, sondern hin- und herspringen, ist ein Frame Reordering erforderlich. Damit dafür Zeit bleibt, wird Video oft mit einem deutlichen zeitlichen Vorsprung gegenüber Audio bzw. der PCR gesendet. Das sieht man, wenn man sich die originalen DVB-Zeitstempel auf der Eigenschaftsseite des DVBViewer Filters anschaut. Beim Ersten HD beträgt die Differenz z.B. mehr als eine Sekunde.

 

In diesem Fall ist nicht damit zu rechnen, dass Frames im Rhythmus der Darstellung eintreffen. Es kann zu "Stoßverkehr" kommen.

 

Igitt, das klingt eklig. Das erklärt ein bißchen, warum es bei zu kleiner Latenz dann zu Schwierigkeiten kommen kann.

 

Idee: Um die Umschaltzeiten zu optimieren, wäre es technisch nicht möglich, daß der DVBSource-Filter analysiert, welche Latenz pro Kanal nötig ist, um die Frames vernünftig zu reordern, und sich diese Latenz dann pro Kanal zu merken? Auf diese Weise bräuchte man da keine globale Einstellung für, und die Umschaltzeiten wären dann so schnell wie es technisch möglich ist. Ist aber nur so eine Idee, die mir gerade in den Sinn gekommen ist...

Link to comment

 

Wenn das nicht auf "disable calibration controls" steht, und dann die Stream-Primaries nicht den Display-Primaries entsprechen, wandelt madVR die Primaries um.

 

Alles andere war default. d.h. "disable calibration controls".

 

 

Ein weiterer Kostenfresser ist, daß madVR der DXVA-YCbCr->RGB Umwandlung nicht vertraut, und diese deshalb rückgängig macht und nachher nochmal selbst neu macht. madVR mißt zu diesem Zweck anhand eines Test-Images, was DXVA da genau macht, um das möglichst genau wieder rückgängig machen zu können. Das Rückgängig machen und "richtig" umwandeln kostet 2 extra Rendering-Schritte. Vielleicht sollte ich da noch eine Trade-Quality-Option für einfügen, daß madVR die DXVA RGB Umwandlung einfach akzeptiert? Das würde wahrscheinlich ordentlich Performance sparen...

 

Fände ich eine gute Sache. Wie sind deine Erfahrungen mit der Intel RGB-Konvertierung?

Link to comment

Intel DXVA gibt leider grundsätzlich nur 8bit aus. Man kann Intel zwar um mehr bitten, aber die restlichen Bits sind dann einfach zero. Bei AMD/NVidia klappt das besser, da kommen tatsächlich auch mehr Bits raus, wenn man sie drum bittet. Wie groß der Bildqualitätsverlust ist, ist natürlich eine andere Frage. Wenn der Intel-Treiber auch gleich die Levels konvertiert, gibt's Banding. Ohne Level-Konvertierung sollte es nicht ganz so tragisch sein mit den 8bit. Ideal ist es auf jeden Fall nicht. Was mir am meisten Sorgen macht, ist daß wir dann keine Kontrolle mehr darüber haben, welche Output-Levels bei der YCbCr -> RGB Konvertierung verwendet werden, und auch keine Kontrolle mehr über die Decode-Matrix. Das heißt, das Umstellen der Decode-Matrix in madVR hätte keine Funktion mehr. Und die Output-Levels könnten sich je nach GPU-Control-Panel-Einstellungen ändern. Aber ok, das ist bei EVR ja auch nicht wirklich anders. Ich schätze, als Trade-Quality-Option wäre das u.U. akzeptabel? :wassat:

Link to comment

 

Ich schätze, als Trade-Quality-Option wäre das u.U. akzeptabel?

 

Für mich wäre es ganz interessant, einmal damit zu spielen.

 

 

 

Unabhängig davon, dass Daten durch die Pufferung im Treiber der DVB-Karte stoßweise eintreffen, muss man auf der Rechnung haben, dass Frames nicht unbedingt in der dargestellten Reihenfolge gesendet werden. Wenn die Video PTS nicht monoton steigen, sondern hin- und herspringen, ist ein Frame Reordering erforderlich. Damit dafür Zeit bleibt, wird Video oft mit einem deutlichen zeitlichen Vorsprung gegenüber Audio bzw. der PCR gesendet. Das sieht man, wenn man sich die originalen DVB-Zeitstempel auf der Eigenschaftsseite des DVBViewer Filters anschaut. Beim Ersten HD beträgt die Differenz z.B. mehr als eine Sekunde.

 

Der Völlegrad der Dekoder-Queue in madVR hängt in der Tat auch sehr stark vom Kanal ab. Auf VOX HD Austria (ebenfalls 1080i) ist die Dekoder-Queue mit DXVA-Dekodierung selbst mit einer DVBSource-Latenz von 200ms stets voll. Auf TNT Serie HD geht die Queue da schon deutlich in die Knie. Interessant auch die Tatsache, dass mit SW-Dekodierung und 200ms Latenz die Queue auch auf TNT Serie HD stets voll ist.

 

Mit DXVA-Dekodierung auf TNT Serie HD kann man sagen, dass je kleiner die Latenz, desto geringer der durchschnittliche Völlegrad der Dekoder-Queue und desto größer die Ausreißer nach unten. Bei 400ms scheint sich ein stabiler Zustand ohne Unterläufe einzustellen.

Link to comment

Ok, ich werd so eine Trade-Quality-Option mal auf meine ToDo-Liste setzen.

 

Hmmmm... Hast Du mal verschiedene DXVA-Decoder probiert? Ich frage mich, ob es vom DXVA-Decoder selbst abhängt, oder vielleicht vom GPU-Treiber? Muß ja irgendwo dran liegen, wenn Software-Decoding da so viel unempfindlicher ist...

Link to comment

PDVD14 (CyberLink Video Decoder (PDVD Generic)) macht mit dem madVR gar kein DXVA. Dekoder stellt auf SW, es erscheint nur ein Standbild, und in den Statistics läuft die Decoder-Queue über die eingestellten maximalen 32. Mit EVR kein Problem.

 

Mit Microsoft DTV-DVD Video Decoder ist die Queue tatsächlich voll. Der CPU-Last nach zu urteilen wird DXVA angewendet.

Link to comment

Mit Microsoft DTV-DVD Video Decoder ist die Queue tatsächlich voll. Der CPU-Last nach zu urteilen wird DXVA angewendet.

 

Oh. Dann läßt sich da vielleicht beim LAV noch was verbessern?

Link to comment

Gut möglich, bzw. in ffmpeg. Auch wenn ich mit EVR und kleinen Latenzen nie ein Problem hatte. Aber wahrscheinlich ist durch das ganze Processing im madVR die Gesamtlatenz dann einfach ein bisschen zu hoch.

Link to comment

 

Kannst Du denn beim EVR den Queue-Status sehen (falls es dort überhaupt Queues in dem Sinne gibt) und Frame Drops/Repeats u.ä.?

 

Mit dem Custom Presenter habe ich ein paar Möglichkeiten. Allerdings gehe ich auf den visuellen Eindruck. Ich bin weniger für feine Qualitätsunterschiede empfindlich als viel mehr für Ruckler...

Link to comment

Das heißt, Du siehst beim EVR keine Ruckler, aber bei madVR bei zu niedriger Latenz schon, richtig? Auf Ruckler bin ich auch extrem empflindlich.

 

Ruckler bei madVR gibt's aber nur, wenn die Decoder-Queue dann auch wirklich (fast) leer wird, korrekt? Nicht, wenn sie nur mal ein bißchen schwankt?

Link to comment

 

Das heißt, Du siehst beim EVR keine Ruckler, aber bei madVR bei zu niedriger Latenz schon, richtig? Auf Ruckler bin ich auch extrem empflindlich.

 

So einen Repeat/Drop mag man schon merken...

 

 

Ruckler bei madVR gibt's aber nur, wenn die Decoder-Queue dann auch wirklich (fast) leer wird, korrekt? Nicht, wenn sie nur mal ein bißchen schwankt?

 

Naja, das ist irgendwie noch mein Problem. Ich habe die Anzeige nie unter 10 gehen sehen. Aber auf Grund der Tatsache, dass es immer nur 1, 2 Frames betrifft, lässt vermuten, dass der Underrun nur ganz kurz ist und wahrscheinlich von der Updaterate der Statistics nicht erfasst wird...

Link to comment

Die Statistik zeigt nicht den aktuellen Zustand an, sondern die unterste und oberste Grenze seit dem letzten Statistik-Refresh. Wenn da also z.B. steht "10-15/20", dann heißt das, die Queue war seit dem letzten Refresh nie unter 10 und nie über 15.

 

Ich schreib mal den nevcairiel an in Sachen DXVA-Queue-Füll-Status bei LAV im Vergleich zum Microsoft-Decoder.

Link to comment

OK, ich werde mit den neu gewonnen Erkenntnissen (Abhängigkeit Kanal bzw. Video/PCR-Offset, DVBSource-Latenz, DXVA-Dekoder usw.) über das Wochenende nochmal einen kontrollierten Vergleichstest machen...

Link to comment

Ah, vorgestern hatte ich die Queue auf 16 eingestellt. Da hab ich mit dem Handy mal einen Drop/Repeat aufgenommen. Wenn der Drop/Repeat gezählt wird, geht die Decoder-Queue auf 1-16.

Link to comment

Habe jetzt DVB Empfang eingerichtet, das ging überraschend flott mit so nem winzigen TiVii-Kistchen und probiere mit DVBV@madVR und es läuft alles recht flüssig, auch Programmwechsel. Ein Unterschied der Wechselzeit EVR-Cust. gegenüber madVR ist mir nicht aufgefallen. Ausser an der Temperatur merke ich kaum das madVR rendert. Leider habe ich von den DVBV-innereien und vielem was Cinch da schreibt keinen Schimmer aber falls es enthält das er Probleme hat (Timing, Decoding...?) kann ich bis jetzt kaum was entdecken. Natürlich habe ich seine/deine bisherigen Empfehlungen probiert:

Meine CPU (nur etwas "dicker") ein Laptop mit Intel Core i5-3320M 2,6GHz HD4000 Grafik (aktueller Treiber), Windows 7

In der Tat wirkt sich "Aero an" (mit DWM) ohne FSE (fullscreen exclusive mode) mit madVR durchweg positiv aus, niedrigere GPU/CPU Load und der ganze Ablauf - Senderwechsel, Hoch- Runterskalieren fühlt sich flüssiger an.
Auch DXVA aus - bessere Performance kann ich bestätigen. Da der DVBV im Gegensatz zum MPC-HC kein unskaliert kann (konnte er mal: "Zoom 100%" ist abgeschafft?) mache ich das Fenster etwa so groß wie es unskaliert wäre und schreibe "schwach skaliert". Ohne Scaling testen ist wichtig zur Ermittlung des Grundlevel.

Verehrter Cinch, falls du Anweisungen hast ob ich auf etwas Spezielles testen soll werde ich mein bestes versuchen, bitte mit Anleitung.
Im Moment fällt mir nix besseres ein als ein paar Scaler solange auszureizen bis es ruckelt. Da man im Bild bei laufendem Programm keinerlei Änderung sieht ein mühseliger Vorgang..
Zusätzlich zu GPU-Z habe ich vor das Netzteil einen Watt-Meter angeschlossen. Vorteil: Der zeigt bequem permanent den Anstieg/Abfall (Verbrauch) von GPU+CPU load ohne Software auch bei FullScreen.
Laptop im Idle: ~11W.

Geänderte Einstellungen:
im frisch installierten DVBViewer habe ich noch gar nichts verstellt ausser der Senderliste und DirectX-Filters.

madVR:
"10bit chroma/image" habe ich probiert bringt an/aus beispielsweise ca. 60 -> 70 % Gpu-load. Ich lasse es für die tests ausgeschaltet weil alles sehr flüssig läuft, mal sehen wo die Grenzen sind.

image down: DXVA2 (-> wenn man hier einen Pixel Shader einstellt erhöht sich der Verbrauch bei "schwach skaliert" enorm).
kein FSE, Aero an
Decoder: LAV DXVA2 (CopyBack)

chroma up: Bicubic-100 AR
image up: DXVA2
576i schwach skaliert - GPU 24%, ~17,5W -> @1080 skaliert (FullScreen) - GPU 70% ~24W
720p schwach skaliert - GPU 33%, ~21W -> @1080 skaliert (FullScreen) - GPU 70% ~26W
1080i nicht skaliert (FullScreen) - GPU 44%, ~23W

chroma up: Lanczos-4 AR
image up: DXVA2
576i schwach skaliert - GPU 26%, ~18W -> @1080 skaliert (FullScreen) - GPU 70% ~24W
720p schwach skaliert - GPU 40%, ~22W -> @1080 skaliert (FullScreen) - GPU 71% ~26W
1080i nicht skaliert (FullScreen) - GPU 83%, ~42W

chroma up: Bicubic-100 AR
image up: Lanczos-4 AR
576i schwach skaliert - GPU 24%, ~17W -> @1080 skaliert (FullScreen) - GPU 74% ~41W
720p schwach skaliert - GPU 40%, ~22W -> @1080 skaliert (FullScreen) - GPU 98% ~47W (ruckelt nicht)
1080i nicht skaliert (FullScreen) - GPU 73%, ~40W

chroma up: Lanczos-4 AR
image up: Lanczos-3 AR
576i schwach skaliert - GPU 24%, ~21W -> @1080 skaliert (FullScreen) - GPU 74% ~42W
720p schwach skaliert - GPU 36%, ~21W -> @1080 skaliert (FullScreen) - GPU 87% ~44W (ruckelt nicht)
1080i nicht skaliert (FullScreen) - GPU 83%, ~43W

Lanczos-3 AR ist hier die Schmerzgrenze, ab L.4 AR ruckelts bei 720p Fullscreen)

zum Vergleich DVBV-EVR-Custom:
576i schwach skaliert - GPU 14%, ~16W -> @1080 skaliert (FullScreen) - GPU 30% ~18W
720p schwach skaliert - GPU 21%, ~19W -> @1080 skaliert (FullScreen) - GPU 34% ~21W
1080i nicht skaliert (FullScreen) - GPU 33%, ~21W

Rein gefühlsmäßig kam der EVR-Custom wärend der Tests etwas "ruhiger, geschmeidiger, lässiger" rüber als madVR.
Na ja, ruhiger schon allein schon wegen dem Lüfter.. Aber die Sache ist ja noch ganz am Anfang.

 

Was jetzt noch kommt ist der beliebte DVBViewer-Test - checken ob nach 1 Stunde und mehr immer noch kein Tonversatz. ZDF 576i lief schonmal 30min (wärend Anruf) ohne.

Fazit: Heureka an alle madVR-Fans! Diese DVBV@madVR-Alpha lief bei mir out of the box samt DVB-Kästchen like-a-charm!

Von besserem/schlechteren Bild war zwar ausser der bekannten leichten Unschärfe des EVR-Custom nichts zu sehen aber ich bin sicher ihr werdet was finden.

Die Upscaling Screenshots mit meinem madVR_640x360-Test.ts sind bei gleichen madVR configs in MPC-HC und DVBViewer vollkommen identisch, was will man mehr?

Edited by craig_s
Link to comment

 

Leider habe ich von den DVBV-innereien und vielem was Cinch da schreibt keinen Schimmer aber falls es enthält das er Probleme hat (Timing, Decoding...?) kann ich bis jetzt kaum was entdecken.

 

Es ist zum einen abhängig von den Kanälen und welche Video-PCR/Audio-Offsets sie fahren. Sky fährt zum Beispiel einen niedrigeren Offset, was zu niedrigeren Pufferständen führt. Zum anderen sind die Auswirkungen sehr subtil und "eher" selten (mit der DVBSource Default-Latenz ca. jede halbe Stunde bei mir). Wenn keine konstanten Bewegungen im Video sind, bekommt man davon auch mal gar nichts mit, außer dass in der madVR Statistik ein paar Werte hochzählen.

Ein dritter Aspekt ist dann wohl noch das Puffer-Handling des H.264-Dekoders.

 

Meine Empfehlung ist, in diesem Fall die Latenz für H.264 Kanäle im DVBSource auf 400ms anzuheben, siehe DVBViewer-Konfigurationsverzeichnis > DVBSource.ini:

 

udH264Latency=400

 

Dann bleiben die MPEG-2 Kanäle davon unberührt.

Link to comment
Es ist zum einen abhängig von den Kanälen und welche Video-PCR/Audio-Offsets sie fahren.

 

Die Sache ist bei Internet TV bzw. HTTP IPTV (insbesondere dem von Apple für Mobilgeräte erdachten HLS = HTTP Live Streaming) noch wesentlich kritischer, da die Sender i.a. H.264 ohne jeglichen Vorsprung liefern. Mit der Standard-Latency und einem Custom EVR, der verspätete Samples verwirft, kommt dann überhaupt keine Video-Wiedergabe mehr zustande.

 

Das nächste DVBViewer GE-Release, das voll integriertes Internet TV bieten wird, bringt deshalb eine neue DVBViewer Filter-Version mit, bei der die Host-Anwendung stillschweigend den Latency-Wert erhöhen kann, was dann (nur) für Internet TV gemacht wird. Im Prinzip ließe sich das auch als Pro-Sender-Eigenschaft einrichten, aber der Ausprobier- und Konfigurationsaufwand wäre natürlich enorm.

Link to comment

Ich empfange ja nur unverschlüsselt - in "echtem"1920x1080 gibts da nur Servus und RT HD. Zeigen die niedrigen Offset?

 

Ach und OSD habe ich noch gar nicht getestet. Ich habe allerdings vegessen wie man das anwirft.

PiP, 2 Monitore auch nicht probiert.

Edited by craig_s
Link to comment

 

Das nächste DVBViewer GE-Release, das voll integriertes Internet TV bieten wird, bringt deshalb eine neue DVBViewer Filter-Version mit, bei der die Host-Anwendung stillschweigend den Latency-Wert erhöhen kann, was dann (nur) für Internet TV gemacht wird.

 

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.

Link to comment

 

Ich empfange ja nur unverschlüsselt - in "echtem"1920x1080 gibts da nur Servus und RT HD.

 

Bei mir sind es 64 funktionierende 1080i Kanäle :tongue: (HD Austria, HD+, Sky).

 

 

in "echtem"1920x1080 gibts da nur Servus und RT HD. Zeigen die niedrigen Offset?

 

Kannst du in den DVBSource Eigenschaften nachschauen. Da musst du auf DVB-Zeitstempel umstellen. Wenn du anschließend auf das DVBViewer-Icon klickst, werden die aktuellen Werte gefreezt. Dann kannst du die Differenz der angezeigten Zeitstempel berechnen...

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