Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

 

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

Da du ja so auf Vergleiche stehst habe ich von meinen aktuellen Einstellungen im MadVR und dem normalen EVR zwei Screenshots gemacht, nebenbei siehst du die GPU_Auslastung.

Nun sag mir welches für dich "besser" aussieht und ob die Auslastung nach einer neuen Hardware schreit. Bitte beachte dabei dass es sich um SD-Live_Material mit viel Bewegung handelt.

 

>MadVR zu EVR_Vergleich<

Link to comment

 

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

Anscheinend gucken die HTPCler nur aus der konserve und hassen sport :rolleyes: Dabei ist letzteres das einzige, wofür man Sky überhaupt noch braucht. Dann gibt es natürlich noch die ÖRs in HD, aber das ist ja nur 720p ;)

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.

 

Gilt das auch für den Custom EVR?

Link to comment

Ja gilt für alle Renderer.

 

Also ich schau sehr viel Sport und daher kommt auch meine Empfehlung für LiveTV immer den guten Deinterlacer zu verwenden.

Link to comment

Ich fahre jetzt übrigens eine noch niedrigere Latenz von 200ms. Die Decoder Queue in madVR ist stets voll.

 

Cool. Und trotz 200ms auch keine Frame Drops/Repeats mehr?

 

 

Da du ja so auf Vergleiche stehst habe ich von meinen aktuellen Einstellungen im MadVR und dem normalen EVR zwei Screenshots gemacht, nebenbei siehst du die GPU_Auslastung.

Nun sag mir welches für dich "besser" aussieht und ob die Auslastung nach einer neuen Hardware schreit. Bitte beachte dabei dass es sich um SD-Live_Material mit viel Bewegung handelt.

 

>MadVR zu EVR_Vergleich<

 

Ich denke, wir sollten dieses Thema lieber begraben, sonst drehen wir uns endlos im Kreis. Jeder hat seine Meinung gesagt. Und CiNcH hat doch da ein gutes "Schlußwort" zu gesprochen.

 

 

Anscheinend gucken die HTPCler nur aus der konserve und hassen sport :rolleyes: Dabei ist letzteres das einzige, wofür man Sky überhaupt noch braucht. Dann gibt es natürlich noch die ÖRs in HD, aber das ist ja nur 720p ;)

 

Nee, ich schere ungern alle HTPCler über einen Kamm. Aus all den diversen Foren sehe ich ja immer wieder, wie unterschiedlich die User doch sind. Ich persönlich gucke gerne und oft Sport und hab deshalb bei mir den Deinterlacer per Default eingeschaltet. Aber es ist ja nicht jeder wie ich, von daher ist es für manche vielleicht eine Option, den Deinterlacer per Default auszuschalten, um GPU-Resourcen zu sparen.

Link to comment

 

Cool. Und trotz 200ms auch keine Frame Drops/Repeats mehr?

 

Seit 15:00 ununterbrochen geschaut und absolut keine Probleme mehr.

 

Mir kommt auch vor, dass die "presentation glitches" deutlich weniger geworden sind. Ohne dass ich sie provoziert habe, hatte ich keine mehr. Ich habe dann mal die aufgenommenen Handy-Videos angeschaut und immer wenn es einen "presentation glitch" gab, gab es auch einen kleinen Einbruch der ganzen Queues, jedoch nicht einmal in die Nähe eines kritischen Bereiches... Ich glaube aber, dass kleine Timing-Änderungen da etwas bewirken. Ich glaube schon, dass madVR da etwas beeinflussen kann. Evtl. wird da zu einem zur Ausgabe ungünstigen Zeitpunkt gerendert oder präsentiert (Nähe VBlank?)...

 

Ich muss bezüglich "presentation glitches" noch weiter beobachten und probieren. Evtl. lässt sich ein Muster erkennen.

Link to comment

Das mit den Presentation Glitches ist schwierig für mich zu handeln, weil ich in dem Modus, indem die Glitches überhaupt gezählt werden, die Kontrolle praktisch komplett an Direct3D/DWM übergebe. Ich rendere und präsentiere ganz naiv für jeden VSync einen Frame (manchmal welche doppelt, falls nötig), und zwar immer einige im Voraus. Wann ich also da genau einen Frame präsentiere, sollte eigentlich gar keine Rolle spielen, weil der Zeitpunkt, wann der gerade präsentierte Frame dann tatsächlich auf dem Bildschirm erscheinen soll, noch mehrere VSyncs (also "Ewigkeiten") entfernt ist. Ich weiß gar nicht, was ich da groß anders machen soll/kann. Zumal genau der gleiche Algorithmus im FSE-Modus ja ohne Glitches läuft (ist bei mir praktisch der gleiche Code).

 

Aber wenn Du ein Muster erkennen kann, vielleicht läßt sich ja doch noch was machen.

Link to comment

Mir ist die Funktionsweise durchaus bekannt. Aber auch wenn man hinten zu einem dummen Zeitpunkt etwas reinstopft, könnte es evtl. am anderen Ende Probleme machen. Ich kenne die MS Queue Implementierung nicht ;) .

 

Ich wollte jetzt mal im Hintergrund den CPU-Graph von ProcessExplorer laufen lassen, um u.U. Last-Spitzen zu identifizieren, die das Problem verursachen. Aber sobald dieser im Hintergrund läuft, gibt es verstärkt "presentation glitches". Im FSE natürlich nicht.

 

Was ich glaube zu sehen sind etwas häufigere und größere Schwankungen bei der "render queue" zum Zeitpunkt des "presentation glitch". Aber wie gesagt niemals kritisch, sprich die Queue ist immer gut gefüllt.

Link to comment

 

Aber es ist ja nicht jeder wie ich, von daher ist es für manche vielleicht eine Option, den Deinterlacer per Default auszuschalten, um GPU-Resourcen zu sparen.

Manchmal wird einem diese entscheidung auch schon vorher abgenommen ;)

Snap275.png

Link to comment

Mir ist die Funktionsweise durchaus bekannt. Aber auch wenn man hinten zu einem dummen Zeitpunkt etwas reinstopft, könnte es evtl. am anderen Ende Probleme machen. Ich kenne die MS Queue Implementierung nicht ;) .

 

Ich wollte jetzt mal im Hintergrund den CPU-Graph von ProcessExplorer laufen lassen, um u.U. Last-Spitzen zu identifizieren, die das Problem verursachen. Aber sobald dieser im Hintergrund läuft, gibt es verstärkt "presentation glitches". Im FSE natürlich nicht.

 

Was ich glaube zu sehen sind etwas häufigere und größere Schwankungen bei der "render queue" zum Zeitpunkt des "presentation glitch". Aber wie gesagt niemals kritisch, sprich die Queue ist immer gut gefüllt.

 

Im Windowed-Mode kann es sein, daß Direct3D selbst, bzw DWM, zum "richtigen" Zeitpunkt CPU-Resourcen braucht, damit jeder Frame zum richtigen Zeitpunkt präsentiert wird. Es kann sein, daß da ein Frame verpaßt wird, wenn DWM zum richtigen Zeitpunkt (also irgendwann kurz vor dem VSync) keine CPU-Resourcen zugeteilt kriegt. Das ist aber nur eine Vermutung meinerseits. Ich glaube, im FSE-Mode werden die Frames einfach per VSync-Hardware-Interrupt im Treiber umgeswitcht, da ist es egal, ob die CPU belegt ist oder nicht. Hardware-Interrupts haben immer Vorrang. Ich vermute, daß im Windowed-Mode das Umswitchen nicht per Hardware-Interrupt gemacht werden kann, weil ja Windows im Windowed-Mode auch das GUI ohne große Latenz anzeigen will. Das heißt, Windows kann nicht schon 5 Frames im voraus alles an Direct3D übergeben, sonst würde das ganze Windows-GUI unerträglich zäh werden. Deshalb ist dann wahrscheinliches alles davon abhängig, ob der richtige Thread im richtigen Moment genug CPU zugeteilt bekommt.

 

 

Manchmal wird einem diese entscheidung auch schon vorher abgenommen ;)

 

Meinst Du, weil dort im StreamType "Interlaced" steht? Das ist leider überhaupt nicht aussagekräftig. Dort kann "Interlaced" stehen und es kann trotzdem ein Film sein, bei dem der Deinterlacer einfach ausgeschaltet werden kann. Und dort kann auch "Progressive" stehen, und es kann trotzdem sein, daß der Deinterlacer dann gebraucht wird. Wobei ersteres viel häufiger vorkommt als zweiteres. Es gibt auch Fälle, wo der Stream mitten drin zwischen "Interlaced" und "Progressive" hin und her wechselt. Hab ich bei Sky HD auch schon gesehen. Solche Media-Info-Screens wie in Deinem Screenshot sind immer nur eine Momentaufnahme und man kann sich (vor allem im Live-TV-Betrieb) nie darauf verlassen, daß das 10 Sekunden später noch genauso aussieht. Deshalb ist das ganze Thema "Deinterlacing" leider schon sehr komplex. Deshalb gibt's ja auch im LAV Video Decoder diverse Sonderoptionen wie "agressive" und "force" usw. Das "force" ist glaube ich für "Progressive"-markierte Streams, die trotzdem Deinterlacing brauchen. Leider gibt's sowas...

Edited by madshi
Link to comment

..wenn du etwas genauer hingeguckt hättest, hättest du sicher was anderes geschrieben ;)

 

Das ist von einem live sportfeed für die ARD. Es ist natürlich nicht auszuschliessen, dass parallel ein anderer feed in 720p50 über einen anderen übertragungsweg zum sender gelangt ist. ich denke aber, dass in 1080i (4:2:2) produziert wurde und in 720p (4:2:0) umgesetzt wurde mit einem sicher teuren interlacer :D Von wegen film.. *kopfschüttel*

Link to comment

Mal was anderes: Was macht MadVR eigentlich, wenn ein Sample mit einer Presentation Time eintrifft, die eine Stunde in der Zukunft liegt?

 

Wie bereits erwähnt, befasse ich mich zur Zeit mit Internet TV. Dort begegnet man allen möglichen Arten von Encoder-Bugs. Unter anderem Video-PTS-Ausreißern, die weit in der Zukunft liegen. Bei DVB gibt's sowas gelegentlich auch.

 

Alle Video Renderer, die ich im DVBViewer GE probiert habe (Standard/Custom-EVR, VMR 9, Overlay Mixer), blockieren in diesem Fall, und im Sourcefilter geht es dann Richtung Buffer Overflow.

 

Ich denke, es wäre gut, wenn Video Renderer, die Frames mit solch offensichtlich blödsiniger Presentation Time erhalten, sie sofort ausgeben. Im Custom EVR des DVBViewer GE habe ich das gerade mit einem Threshold von 10 Sekunden probiert (d.h. für Zeitstempel, die der Streamtime mehr als 10 Sekunden voraus sind), und das behebt das Problem.

 

Bei Bedarf kann ich ein Sample zur Verfügung stellen.

Link to comment

..wenn du etwas genauer hingeguckt hättest, hättest du sicher was anderes geschrieben ;)

 

Das ist von einem live sportfeed für die ARD. Es ist natürlich nicht auszuschliessen, dass parallel ein anderer feed in 720p50 über einen anderen übertragungsweg zum sender gelangt ist. ich denke aber, dass in 1080i (4:2:2) produziert wurde und in 720p (4:2:0) umgesetzt wurde mit einem sicher teuren interlacer :D Von wegen film.. *kopfschüttel*

 

Puh, Du scheinst es irgendwie auf mich abgesehen zu haben.

 

Vielleicht habe ich Dich mißverstanden, aber meine Ausführungen sind technisch korrekt. Ich habe gedacht, Du wolltest sagen, daß madVR mit dem von Dir gezeigten Stream selbst erkennen können müßte, daß dort Deinterlacing gebraucht wird. Das ist leider nicht der Fall, wie ich in meinem Post erklärt habe. Aber vielleicht wolltest Du etwas anderes sagen?

 

 

Mal was anderes: Was macht MadVR eigentlich, wenn ein Sample mit einer Presentation Time eintrifft, die eine Stunde in der Zukunft liegt?

 

Wie bereits erwähnt, befasse ich mich zur Zeit mit Internet TV. Dort begegnet man allen möglichen Arten von Encoder-Bugs. Unter anderem Video-PTS-Ausreißern, die weit in der Zukunft liegen. Bei DVB gibt's sowas gelegentlich auch.

 

Alle Video Renderer, die ich im DVBViewer GE probiert habe (Standard/Custom-EVR, VMR 9, Overlay Mixer), blockieren in diesem Fall, und im Sourcefilter geht es dann Richtung Buffer Overflow.

 

Ich denke, es wäre gut, wenn Video Renderer, die Frames mit solch offensichtlich blödsiniger Presentation Time erhalten, sie sofort ausgeben. Im Custom EVR des DVBViewer GE habe ich das gerade mit einem Threshold von 10 Sekunden probiert (d.h. für Zeitstempel, die mehr als 10 Sekunden der Streamtime voraus sind), und das behebt das Problem.

 

Bei Bedarf kann ich ein Sample zur Verfügung stellen.

 

Hmmmm... Gute Frage. madVR hat eigentlich einen Algorithmus, der die Timestamps von klein nach groß umsortiert. Ich vermute, daß der zu große Timestamp dem jeweils letzten Frame in der Queue zugewiesen wird, sich also eigentlich nicht besonders negativ auswirken sollte, abgesehen davon, daß madVR ständig die Timestamps umsortieren muß. Ansonsten denke ich aber, daß das Playback korrekt weiter laufen sollte. Probleme könnte es aber dann geben, wenn es mehrere solcher ungültiger Timestamps gäbe. Dann würde sich die Queue irgendwann mit solchen Timestamps vollstopfen. Ein Sample wäre in jedem Fall interessant, dann kann ich versuchen, das noch besser abzufangen.

Link to comment
Ein Sample wäre in jedem Fall interessant, dann kann ich versuchen, das noch besser abzufangen.

 

Lädt gerade hoch. Solange schreibe ich noch etwas...

 

Der DVBViewer Sourcefilter passt auf solche PTS-Diskontinuitäten natürlich auf. Bei Live-Betrieb schickt er (optional) eine Error Message an die Host-Anwendung, die daraufhin mit einem Stop/Run das Filtergraph-Timing wieder in Ordnung bringen kann. Wenn es alle drei Sekunden solche Diskontinuitäten gibt, ist das nicht so erfreulich ;)

 

Bei Dateiwiedergabe gleicht der DVBSource PTS-Ausreißer aus, indem er den letzten zuvor empfangenen Wert wiederholt. Wenn man das Sample mit dem DVBViewer abspielt und der DVBSource für TS-Dateien zuständig ist, merkt der Renderer (und der Zuschauer) kaum etwas davon.

 

Mit dem LAV Sourcefilter sind die Ergebnisse bei Dateiweidergabe (im DVBViewer) gemischt. Mit dem Cyberlink Decoder geht es schief, mit dem LAV Decoder läuft es einigermaßen.

 

Hier das Sample. Es stammt vom Live Stream des Kindersenders RIC, der nachts Verkaufssendungen bringt:

 

http://www.DVBViewer.com/griga/PTS_GAP.ts

Link to comment

 

Aber vielleicht wolltest Du etwas anderes sagen?

Da gibt es eigentlich keinen erklärungsbedarf. Ich schrieb "Anscheinend gucken die HTPCler nur aus der konserve", was du mit deinem exkurs mehr oder weniger bestätigt hast. Das bildbeispiel war für @Cinch :)

Link to comment

Kritik ist hier anscheinend nicht erwünscht. Dabei habe ich noch gar keine kritik geäussert. Wenn ich dafür bedarf sehe, werde ich mich an anderer stelle melden..

Link to comment

 

Lädt gerade hoch. Solange schreibe ich noch etwas...

 

Der DVBViewer Sourcefilter passt auf solche PTS-Diskontinuitäten natürlich auf. Bei Live-Betrieb schickt er (optional) eine Error Message an die Host-Anwendung, die daraufhin mit einem Stop/Run das Filtergraph-Timing wieder in Ordnung bringen kann. Wenn es alle drei Sekunden solche Diskontinuitäten gibt, ist das nicht so erfreulich ;)

 

Bei Dateiwiedergabe gleicht der DVBSource PTS-Ausreißer aus, indem er den letzten zuvor empfangenen Wert wiederholt. Wenn man das Sample mit dem DVBViewer abspielt und der DVBSource für TS-Dateien zuständig ist, merkt der Renderer (und der Zuschauer) kaum etwas davon.

 

Mit dem LAV Sourcefilter sind die Ergebnisse bei Dateiweidergabe (im DVBViewer) gemischt. Mit dem Cyberlink Decoder geht es schief, mit dem LAV Decoder läuft es einigermaßen.

 

Hier das Sample. Es stammt vom Live Stream des Kindersenders RIC, der nachts Verkaufssendungen bringt:

 

http://www.DVBViewer.com/griga/PTS_GAP.ts

 

Thanks. Wie kann ich das "schief gehen" reproduzieren? Wenn ich hier mit LAV Splitter -> LAV Video Decoder oder mit LAV Splitter -> ffdshow Video Decoder versuche, kommen beim madVR scheinbar nur sinnvolle Timestamps an. Zumindest hab ich im Log auf den ersten Blick nichts komisches gesehen. Den Cyberlink Decoder hab ich leider nicht. Ideal wäre es, wenn beim madVR so komische Timestamps ankämen, dann könnte ich gleich testen, ob ein möglicher Fix funktioniert. Notfalls kann ich natürlich auch versuchen, das "blind" zu fixen.

 

Ich wollte das aber auch an nevcairiel weiter leiten, dann kann er das auch zusätzlich noch im LAV Splitter fixen. Da bräuchte ich dann am besten auch einen Weg, auf dem er das einfach reproduzieren kann.

 

 

Ich frage mich, ob hier eigentlich nur noch Hampelmänner rumirren, die sich selber zu wichtig nehmen...

 

:laughing:

Link to comment

Da du ja so auf Vergleiche stehst habe ich von meinen aktuellen Einstellungen im MadVR und dem normalen EVR zwei Screenshots gemacht, nebenbei siehst du die GPU_Auslastung.

Nun sag mir welches für dich "besser" aussieht und ob die Auslastung nach einer neuen Hardware schreit. Bitte beachte dabei dass es sich um SD-Live_Material mit viel Bewegung handelt.

 

>MadVR zu EVR_Vergleich<

 

Der Download bricht dauernd ab, probier mal Dropbox.

 

Ich habe deine vorigen Bilder gesehen aber wie du selbst schon erfahren hast sind Screenshots hier unerwünscht weil darin nichts weltbewegendes zu sehen ist.

Hier wird aber gerade die Welt bewegt, spürst du wie es knistert und kracht?

Abwarten und Tee trinken. Am Ende werden alte griesgrämige DVBViewler zusammenfegen und in aller Ruhe schauen was die Heißsporne da bewerkstelligt haben.. :D

Edited by craig_s
Link to comment

Bei mir hat der Download geklappt.

Vielleicht überhitzt dabei eine Komponente deines Rechners,

oder der Stromverbrauch für den Download ist zu hoch.

 

Sorry, konnte wieder mal nicht anders :original:

Edited by goldfield
  • Like 2
Link to comment
Wie kann ich das "schief gehen" reproduzieren? Wenn ich hier mit LAV Splitter -> LAV Video Decoder oder mit LAV Splitter -> ffdshow Video Decoder versuche, kommen beim madVR scheinbar nur sinnvolle Timestamps an.

 

Stimmt. In diesen Kombinationen funktioniert es. Offenbar haben sich schon andere Gedanken um die Korrektur unsinniger Zeitstempel gemacht. Kritisch ist das Problem hauptsächlich unter Live-Bedingungen bzw. im Push Mode. Beim Lesen aus einer Datei ist es einfacher, weil man dabei vorwärts / rückwärts schauen kann. Außerdem entfällt dabei die Möglichkeit, dass Daten über einen gewissen Zeitraum aufgrund von Empfangsstörungen ausbleiben, was die Beurteilung der Situation vereinfacht.

 

Insofern ist es schwierig, einen geeigneten Versuchsaufbau zu finden, in dem die Zeitstempel-Diskontinuitäten im Sample bis zum Video Renderer vordringen. Ich konnte mir die Frage

 

Was macht MadVR eigentlich, wenn ein Sample mit einer Presentation Time eintrifft, die eine Stunde in der Zukunft liegt?

 

jedoch inzwischen (teilweise) selbst beantworten, und zwar durch eine DVBSource-Testversion, die bei Dateiwiedergabe keine Zeitstempel-Glättung vornimmt. Ergebnis beim Abspielen des Samples im DVBViewer Pro (mit LAV Video Decoder): Alle Video Renderer blockieren, außer MadVR und der heute von mir modifizierte Custom EVR.

 

Die Maßnahmen in MadVR scheinen also bereits aureichend zu sein. Um die (sabotierte) DVBSource-Testversion zur Verfügung zu stellen, bräuchte ich eine Mailadresse per PM.

Link to comment
LoL. Mit GMail hat Griga bestimmt sehr viel Freude

 

Ausführbare Dateien als GMail-Anhang sind ein PITA. Dann lieber ganz per PM. Ich werde aber erst heute abend oder morgen dazu kommen.

Link to comment

Mit GMail geht's auch: Und zwar mit RAR packen und die Dateinamen mit Passwort verschlüsseln. So hat's bei mir bisher immer geklappt. Aber per PM geht's natürlich auch. Thanks!

Link to comment

Gibt es derzeit schon die Möglichkeit, MadVR mit dem DVBViewer zu testen? Hab hier nen phenomII 6core und ne 7850, damit müsste es ja hardwaretechnisch funktionieren.

Link to comment

Gibt es derzeit schon die Möglichkeit, MadVR mit dem DVBViewer zu testen? Hab hier nen phenomII 6core und ne 7850, damit müsste es ja hardwaretechnisch funktionieren.

 

 

Nö, leider nicht - nur für Betatester.....

 

Ein "öffentlicher" Betatest mit allen, die das wollen, wird's wohl nicht geben....schade!

Link to comment

Ich würde mich auch riesig über eine Testversion freuen.

 

Ich kann aber auch gut verstehen, das man den Kreis derzeit evt. erstmal auf Personen beschränken will,

die bei Problemen in etwa einschätzen können, wo die Ursache liegt, und wie man diese lösen kann.

Ansonsten kann das schnell dazu führen, das die Beantwortung von simplen Fragen mehr Zeit verbrät,

als das Einfügen des Renderers selbst.

 

Ich vertraue jetzt erstmal auf die die Jung's, die hier schon einen tollen Job machen,

und freue mich auf die nächste öffentliche Version.

Edited by goldfield
Link to comment

Eine öffentliche DVBViewer Pro Beta wird es eventuell geben, nachdem Christian den Custom EVR durch CiNcHs Variante ersetzt hat, weil herausgefunden werden muss, ob sie sich überall so stabil verhält, dass sie die jetzige Variante ohne Einschränkungen ersetzen kann.

 

Dann haben wir gleich alles in einem Aufwasch. Allerdings wird es bis dahin noch dauern...

Link to comment

Da fällt mir gerade auf, dass SPORT1 HD eine Auflösung von 1280x1080 (bei 16:9) hat. Das hab ich ja noch gar nie gesehen. 1440x1080 bei TELE5 HD war mir bekannt.

 

Diese Presentation Glitches machen mich fertig. Bei SPORT1 HD habe ich alle paar Sekunden einen. Da macht DXVA2 das ganze Scaling und die Last ist eigentlich deutlich weniger als mit 1920x1080i, wo die Shader das Chroma Upsampling machen müssen.

 

Bei SPORT1 HD hatten wir in der Vergangenheit auch schon Synchronisationsprobleme diskutiert. Je nach Renderer (Standard oder Custom EVR) und wenn die DVB Clock im DVBSource aktiviert war, gab es entweder Ruckler oder A/V liefen auseinander. Irgendwas ist bei dem Kanal komisch.

Link to comment

Sport1 HD läuft bei mir nicht. Vielleicht weil ich keine HDPlus-Karte habe? Was sagt denn das madVR OSD über die Framerate? Normalerweise schwankt das "1 frame repeat every" je nach RefreshRate und nicht je TV-Kanal. Eigentlich sollten ja alle TV-Kanäle genau 50Hz haben. Komisch. Allerdings braucht das "1 frame repeat every" auch eine Weile, bis es einigermaßen korrekte Aussagen liefert. Das wird über einen langfristigen Mittelwert u.ä. errechnet, da braucht es seine Zeit, bis die Statistik was zuverlässiges ausspuckt.

 

Gibt's denn auch im FSE beim Sport1 HD Presentation Glitches?

Link to comment

Das mit den "expected drops/repeats" musste ich revidieren. Das braucht ein bisschen bis es sich einpendelt. Die Kanäle sind alle 25fps bzw. 50 hinter dem Deinterlacer. Mit FSE keine Glitches. Trotzdem interessant, dass der Kanal da Einfluss darauf hat...

 

Ja, SPORT1 HD ist Teil von HD+.

Link to comment

Wenn ich SPORT1 HD in einem Fenster mit Target Rectangle 1280x720 laufen lasse, ist es auch "glitch-free". Ich habe mal ein 2-Minuten-Sample aufgenommen. Ich schick dir nachher mal den Link per PN. In den Bergen habe ich leider nur 768kbps Upload. Bei HD-Samples macht das wenig Spaß...

Link to comment

Ich guck's mir gern mal an. Hab meine Zweifel, ob das gleiche Problem bei mir auch auftritt (tut es irgendwie nie, <seufz>), aber einen Versuch ist es wert. Was für eine RefreshRate verwendest Du?

Link to comment

Ok, dann muß ich das auf dem HTPC testen. Mein Dev-PC kann leider nur 60Hz. Mein HTPC hat allerdings eine (integrierte) NVidia-GPU. Mal sehen, was da passiert... :original:

Edited by madshi
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...