Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

So, jetzt kann ich das 1080i > 720p Problem wieder nachvollziehen. Ich hatte im Menü "Fast channel switching" deaktiviert, d.h. da wurde bei jedem Umschalten der Graph neu gebildet. Dann kam es nicht zu dem Problem. Nach dem Aktivieren der Option wird kein Graph Rebuild bei 1080i > 720p mehr gemacht, weil beides H.264 ist. Dann habe ich wieder das Problem, dass nach dem Umschalten das "target rectangle" der "movie resolution" entspricht:

 

wrong_rect.jpg

 

Wenn ich dann kurz ins Fenster und wieder ins Vollbild schalte, ist wieder alles gut.

 

Wie das nun damit zusammenhängen soll, was LAV liefert, ist mir nicht klar. Der weiß doch vom Ausgabefenster nichts. Der liefert unabhängig von der Fenster-Größe, in der das Video dargestellt wird, immer die Auflösung des Quellmaterials, d.h. bei 1080i:

 

rcSource: (0,0,1920,1080)

rcTarget: (0,0,1920,1080)

 

und bei 720p:

 

rcSource: (0,0,1280,720)

rcTarget: (0,0,1280,720)

 

Das sollte der Renderer bestimmt nicht als "target rectangle" verwenden.

 

Scheinbar wird beim Graph-Rebuild das korrekte "target rectangle" mitgeteilt, was beim Umschalten ohne Graph-Rebuild nicht zu passieren scheint. Aber warum madVR dann die "movie resolution" verwendet? Oder ist das gar das, was der DVBViewer mitteilt?

Link to comment
Wie das nun damit zusammenhängen soll, was LAV liefert, ist mir nicht klar. Der weiß doch vom Ausgabefenster nichts.

Der MS-Decoder zeigt das gleiche Fehlerbild.

LAV DXVA2, CUVID oder Software macht auch keinen Unterschied.

Link to comment

 

Also wann müsste das passieren? Wenn ich im Vollbild ohne Graph-Neubau und ohne Vorab-Formaterkennung von Servus TV HD auf das Erste HD umschalte? Geht hier einwandfrei.

 

Genau so ist es bei mir reproduzierbar...

 

wrong_rect.jpg

Link to comment

Geht das ohne Graph-Neuaufbau auch beim Wechsel zwischen zwei verschiedenen Videos? Oder klappt das nur im Live-TV? Hab leider keine DVB-Karte/-Stick hier, kann also Live-TV hier nicht testen.

 

Ansonsten, wenn Du ein Debug-Log machen könntest, würde das wahrscheinlich auch helfen. Da könnte ich ungefähr sehen, was in welcher Reihenfolge passiert und vielleicht warum dann nachher das Target-Rect nicht stimmt. Debug-Log landet normalerweise auf dem Desktop, nachdem Du im madVR-Ordner die Debug-Build aktiviert hast (doppelklick auf die Batch-Datei). Die Debug-Logs werden sehr schnell sehr groß, lassen sich aber wunderbar packen.

Link to comment

 

Geht das ohne Graph-Neuaufbau auch beim Wechsel zwischen zwei verschiedenen Videos? Oder klappt das nur im Live-TV? Hab leider keine DVB-Karte/-Stick hier, kann also Live-TV hier nicht testen.

 

Glaub nicht, dass das mit File geht.

 

Hast du denn Kabel oder Sat zuhause?

 

 

 

Ansonsten, wenn Du ein Debug-Log machen könntest

 

Done... Umschaltung erfolgte von Servus TV HD auf ORF1 HD.

 

madVR - log.zip

Link to comment

Ich denke, das wesentliche ist hierbei nicht die Vorab-Formaterkennung, sondern der Graph-Neuaufbau, bzw, der Zustand "frisch verbunden" bei den Video-Filtern.

 

Wenn man im DVBViewer die Vorab-Formaterkennung aktiviert, führt der DVBSource nämlich bei einem Wechsel der Auflösung ein Reconnect des ganzen Video-Zweiges durch. Das zeigt er auch auf seiner Eigenschaftsseite an (Video State: Enabled / Reconnected).

 

Wenn der Graph nicht neu aufgebaut wird und die Vorab-Formaterkennung deaktiviert ist, müssen Video Decoder und Video Renderer den Wechsel der Auflösung alleine managen.

Link to comment

Wenn man im DVBViewer die Vorab-Formaterkennung aktiviert, führt der DVBSource nämlich bei einem Wechsel der Auflösung ein Reconnect des ganzen Video-Zweiges durch. Das zeigt er auch auf seiner Eigenschaftsseite an (Video State: Enabled / Reconnected).

 

Wenn der Graph nicht neu aufgebaut wird und die Vorab-Formaterkennung deaktiviert ist, müssen Video Decoder und Video Renderer den Wechsel der Auflösung alleine managen.

Klar das ist es. War mir nicht bewusst, dass die Voraberkennung ein reconnect bei Auflösungswechsel verursacht.
Link to comment

Jau, das Log bestätigt meine Vermutung: LAV sagt madVR Bescheid über die geänderte Auflösung. Als Teil der "die Auflösung hat sich geändert"-Bearbeitung in madVR setzt madVR per Default eine neues Target-Rect auf genau die Video-Auflösung. Anschließend wird eine EC_VIDEO_SIZE_CHANGED Meldung an den Graph geschickt, siehe hier die entsprechende Microsoft Dokumentation:

 

https://msdn.microsoft.com/en-us/library/windows/desktop/dd319625(v=vs.85).aspx

 

Alle anderen Media-Player reagieren auf die EC_VIDEO_SIZE_CHANGED Meldung und setzen ein neues Target-Rect, welches dem aktuell ausgewählten Zoom-Modus entspricht. Der DVBViewer ist hier eine Ausnahme, weil er gar keine Zoom-Modi unterstützt und deshalb die Sache des Target-Rects normalerweise dem Video-Renderer überläßt. Und da verhält sich madVR scheinbar anders als die anderen vom DVBViewer verwendeten Renderer.

 

Lösungsmöglichkeiten gibt es nun 2:

 

1) Entweder ich ändere madVR. a) Ich könnte bei Änderungen der Auflösung per Default das Target-Rect auf die Größe des Rendering-Windows setzen. B) Ich könnte das Target-Rect auf dem gleichen Wert lassen, wenn sich die Video-Auflösung ohne Reconnect ändert.

2) Oder DVBViewer reagiert auf EC_VIDEO_SIZE_CHANGED und setzt ein neues Target-Rect, so wie die anderen Media-Player das auch alle machen.

 

Bei 1a) hab ich etwas Bauchschmerzen, weil das eine Änderung ist, die eventuell zu Folgefehlern bei anderen Media-Playern führen könnte. Ich denke 1b) wäre vielleicht eine Option. Oder halt 2). Falls der DVBViewer jemals andere Zoom-Modi unterstützen will (wie z.B. 100%, 200%, Touch Window From Inside, Touch Window From Outside usw), dann müßte sowieso 2) eingebaut werden, weil madVR nicht weiß, was für einen Zoom-Modus aktiv ist.

 

Was meint ihr?

Edited by madshi
Link to comment

Die Terminologie ist etwas unklar. Ist mit "setzen ein neues Target-Rect" IVideoWindow.SetWindowPosition gemeint?

 

Der DVBViewer ruft das nur auf, wenn sich die Größe des Video-Darstellungsbereichs tatsächlich ändert. Und natürlich nach einem Graph-Neuaufbau. Nicht jedoch bei einem Wechsel der Auflösung - auch nicht, wenn der DVBSource dabei ein Reconnect durchführt - und ich sehe ehrlich gesagt nicht, was das eine mit dem anderen zu tun haben soll.

 

Wie auch immer: Es bleibt schleierhaft, warum sich diese "Unterlassung" des DVBViewers unter bestimmten Bedingungen auswirkt und unter anderen (nach einem Reconnect) nicht. Warum nur im Vollbild? Und warum tritt der von CiNcH beschriebene Effekt bei mir überhaupt nicht auf - bislang konnte ich das auf keine Weise reproduzieren. Entweder verhält sich MadVR in der Hinsicht inkonsequent, oder es spielen bislang noch nicht erfasste Faktoren mit.

Link to comment

Ja das erklärt auch warum ein Wechsel in den Fenstermodus das Problem löst. :)

Hast du schon im Vollbild getestet Griga?

 

Problem ist das hier:

Jau, das Log bestätigt meine Vermutung: LAV sagt madVR Bescheid über die geänderte Auflösung. Als Teil der "die Auflösung hat sich geändert"-Bearbeitung in madVR setzt madVR per Default eine neues Target-Rect auf genau die Video-Auflösung.

Beim reconnect setzt madVR ebenso ein neues Target-Rect? Edited by nuts
Link to comment

Oder halt 2). Falls der DVBViewer jemals andere Zoom-Modi unterstützen will (wie z.B. 100%, 200%, Touch Window From Inside, Touch Window From Outside usw),

Eher unwahrscheinlich, da was in der Richtung grade in der vorletzten Version entfernt wurde.

 

Geändert: Hauptfenster: Die Prozentwerte der Funktion Ansicht → Fenstergröße beziehen sich jetzt auf die nutzbare Desktop- bzw. Monitorfläche, nicht mehr auf die Video-Auflösung (was kaum Sinn machte). Die neuen Prozentwerte sind 40%, 50%, 60%, 75% und 100%, wobei der letzte die maximal erreichbare Fenstergröße repräsentiert.

http://www.DVBViewer.tv/forum/topic/54745-DVBViewer-531/

http://www.DVBViewer.tv/forum/topic/54791-neue-berechnung-ansicht-fenstergroesse/

Link to comment

Die Terminologie ist etwas unklar. Ist mit "setzen ein neues Target-Rect" IVideoWindow.SetWindowPosition gemeint?

 

Der DVBViewer ruft das nur auf, wenn sich die Größe des Video-Darstellungsbereichs tatsächlich ändert. Und natürlich nach einem Graph-Neuaufbau. Nicht jedoch bei einem Wechsel der Auflösung - auch nicht, wenn der DVBSource dabei ein Reconnect durchführt - und ich sehe ehrlich gesagt nicht, was das eine mit dem anderen zu tun haben soll.

 

Wie auch immer: Es bleibt schleierhaft, warum sich diese "Unterlassung" des DVBViewers unter bestimmten Bedingungen auswirkt und unter anderen (nach einem Reconnect) nicht. Warum nur im Vollbild? Und warum tritt der von CiNcH beschriebene Effekt bei mir überhaupt nicht auf - bislang konnte ich das auf keine Weise reproduzieren. Entweder verhält sich MadVR in der Hinsicht inkonsequent, oder es spielen bislang noch nicht erfasste Faktoren mit.

 

Ich denke, das müßte IBasicVideo::SetDestinationPosition sein. Damit kann DVBViewer das ändern, was im madVR Debug-OSD (Ctrl+J) als Target-Rect angezeigt wird.

 

Die genauen Faktoren, wann der DVBViewer das aufruft oder nicht, und warum sich das vielleicht manchmal anders auswirkt als wann anders, kann ich auch nicht abschätzen, da ich das wegen fehlender DVB-Hardware hier nicht reproduzieren kann. Ich kann nur von CiNcH's Debug-Log ausgehen. In dem Log ist es so, daß madVR aufgrund der Auflösungsänderung selbst das Target-Rect auf die Video-Auflösung gesetzt hat, danach eine EC_VIDEO_SIZE_CHANGED Nachricht an den Graph geschickt hat, und DVBViewer hat dann in diesem Fall kein neues Target-Rect gesetzt.

 

 

Beim reconnect setzt madVR ebenso ein neues Target-Rect?

 

madVR macht das eigentlich immer, beim Erst-Connect, beim Reconnect, und auch bei reinen Auflösungsänderungen ohne Reconnect.

 

 

Eher unwahrscheinlich, da was in der Richtung grade in der vorletzten Version entfernt wurde.


http://www.DVBViewer.tv/forum/topic/54745-DVBViewer-531/
http://www.DVBViewer.tv/forum/topic/54791-neue-berechnung-ansicht-fenstergroesse/

 

Ok, ich verstehe.

Link to comment

Ähm, gute Frage, aber ich denke ja, falls sich das Aspect Ratio im Bitstream ändert. Anders sieht es aus, wenn der Media-Player das AR ändert, das müßte dann wiederum über IBasicVideo::SetDestinationPosition geschehen. Ach ja, das scheint im Moment auch im DVBViewer nicht zu klappen, zumindest nicht in der Version, die ich habe (die aber schon wieder relativ als ist).

Link to comment

Ich habe jetzt die neue Version von Griga getestet. Damit ist das Problem erstmal gefixt. Mit dieser Version haben sich auch die Anzahl der Schwarzblenden beim Umschalten (wo auch das OSD kurz verschwindet) reduziert. Ich sehe momentan nur noch eine, wenn das Format bzw. der Dekoder gewechselt wird. Vorher hatte ich das auch ohne Dekoder-Wechsel desöfteren, auch mal 2 Schwarzblenden bei einem Umschaltvorgang. Wann macht madVR solche Schwarzblenden? Ich könnte mir vorstellen, dass wenn es keine Format-Voraberkennung im DVBSource gibt und Default-Werte übergeben werden und irgendwann die Format-Erkennung vom Dekoder aus dem Stream heraus greift, dann selber korrekte Werte weitergibt, es mehrere solche Schwarzblenden geben könnte?

 

Ich frage deshalb, weil die Schwarzblenden scheinbar das sichtbar werden des Mauszeigers provozieren. Momentan sehe ich es nur noch beim Umschalten H.264 <-> MPEG-2.

Link to comment
Ich denke, das müßte IBasicVideo::SetDestinationPosition sein. Damit kann DVBViewer das ändern, was im madVR Debug-OSD (Ctrl+J) als Target-Rect angezeigt wird.

 

Das ruft der DVBViewer bei jedem Senderwechsel auf, aber nicht als Reaktion auf EC_VIDEO_SIZE_CHANGED, d.h. nicht zeitlich mit MadVR koordiniert. So ist womöglich zu erklären, dass der von CiNcH beschriebene Effekt unter manchen Bedingungen auftritt und unter anderen nicht, je nach dem, wie es zeitlich hinkommt.

 

Insgesamt erscheint mir das Verhalten von MadVR in dieser Hinsicht weder logisch noch korrekt. Vielleicht mangelt es einfach an Praxis mit DVB- bzw. Live-Betrieb. Während eine Datei abgespielt wird, ändert sich die Videoauflösung i.a. nicht. Wenn eine neue / andere Datei abgespielt wird, ist damit i.a. auch ein Neuaufbau des Graphen verbunden. Natürlich setzen dabei alle Mediaplayer initial den Video-Ausgabebereich, ob als Reaktion auf EC_VIDEO_SIZE_CHANGED oder nicht bleibt dahingestellt. Und das war's dann, solange die Graph-Instanz lebt. Das funktioniert auch im DVBViewer mit MadVR ohne weitere Maßnahmen.

 

Bei Live-Betrieb mit dem DVBViewer geht es anders zu. Hier erfolgt bei einer Senderumschaltung normalerweise nur ein IMediaControl.Stop/Run, kein Neuaufbau des Graphen, sofern sich nicht der Videotyp (MPEG2 / H.264) ändert oder ein erzwungener Neuaufbau konfiguriert ist. Und dabei können sich sowohl Auflösung als auch Aspect Ratio ändern. Soweit ich bei Tests feststellen konnte, ist MadVR der einzige Renderer, der dabei den von der Anwendung gesetzten Video-Ausgabebereich eigenmächtig abändert.

 

Ich habe jetzt in einer Testversion dafür gesorgt, dass der DVBViewer - nur wenn MadVR aktiv ist - nach EC_VIDEO_SIZE_CHANGED noch mal (!) den Ausgabebereich konfiguriert. Das passiert dann also unnötig oft. Zwar scheint es so zu funktionieren, ist aber weder schön noch effizient. Ich kann jedoch nicht die ganzen damit verbundenen (zeitlichen) Abläufe im DVBViewer nur wegen MadVR über den Haufen werfen.

Link to comment

Würde sagen jemand sollte mal madshi passende DVB Hardware aus dem Testarchiv zukommen lassen.

Wer meldet sich freiwillig? :)

Edited by nuts
Link to comment

 

Würde sagen jemand sollte mal madshi passende DVB Hardware aus dem Testarchiv zukommen lassen.

Wer meldet sich freiwillig?

 

Ich habe ihn deshalb gefragt, ob er Sat oder Kabel bei sich empfangen kann... ;)

Link to comment

Ich habe jetzt die neue Version von Griga getestet. Damit ist das Problem erstmal gefixt. Mit dieser Version haben sich auch die Anzahl der Schwarzblenden beim Umschalten (wo auch das OSD kurz verschwindet) reduziert. Ich sehe momentan nur noch eine, wenn das Format bzw. der Dekoder gewechselt wird. Vorher hatte ich das auch ohne Dekoder-Wechsel desöfteren, auch mal 2 Schwarzblenden bei einem Umschaltvorgang. Wann macht madVR solche Schwarzblenden? Ich könnte mir vorstellen, dass wenn es keine Format-Voraberkennung im DVBSource gibt und Default-Werte übergeben werden und irgendwann die Format-Erkennung vom Dekoder aus dem Stream heraus greift, dann selber korrekte Werte weitergibt, es mehrere solche Schwarzblenden geben könnte?

 

Ich frage deshalb, weil die Schwarzblenden scheinbar das sichtbar werden des Mauszeigers provozieren. Momentan sehe ich es nur noch beim Umschalten H.264 <-> MPEG-2.

 

Schwarzblenden kommen (wenn ich mich recht erinnere) bei einem Graph Stop, aber ich glaube auch nur dann, wenn der Graph nicht innerhalb einer bestimmten Zeit wieder neu startet. Ganz genau weiß ich es jetzt aus dem Kopf aber nicht.

 

 

 

Das ruft der DVBViewer bei jedem Senderwechsel auf, aber nicht als Reaktion auf EC_VIDEO_SIZE_CHANGED, d.h. nicht zeitlich mit MadVR koordiniert. So ist womöglich zu erklären, dass der von CiNcH beschriebene Effekt unter manchen Bedingungen auftritt und unter anderen nicht, je nach dem, wie es zeitlich hinkommt.

 

Insgesamt erscheint mir das Verhalten von MadVR in dieser Hinsicht weder logisch noch korrekt. Vielleicht mangelt es einfach an Praxis mit DVB- bzw. Live-Betrieb. Während eine Datei abgespielt wird, ändert sich die Videoauflösung i.a. nicht. Wenn eine neue / andere Datei abgespielt wird, ist damit i.a. auch ein Neuaufbau des Graphen verbunden. Natürlich setzen dabei alle Mediaplayer initial den Video-Ausgabebereich, ob als Reaktion auf EC_VIDEO_SIZE_CHANGED oder nicht bleibt dahingestellt. Und das war's dann, solange die Graph-Instanz lebt. Das funktioniert auch im DVBViewer mit MadVR ohne weitere Maßnahmen.

 

Bei Live-Betrieb mit dem DVBViewer geht es anders zu. Hier erfolgt bei einer Senderumschaltung normalerweise nur ein IMediaControl.Stop/Run, kein Neuaufbau des Graphen, sofern sich nicht der Videotyp (MPEG2 / H.264) ändert oder ein erzwungener Neuaufbau konfiguriert ist. Und dabei können sich sowohl Auflösung als auch Aspect Ratio ändern. Soweit ich bei Tests feststellen konnte, ist MadVR der einzige Renderer, der dabei den von der Anwendung gesetzten Video-Ausgabebereich eigenmächtig abändert.

 

Ich habe jetzt in einer Testversion dafür gesorgt, dass der DVBViewer - nur wenn MadVR aktiv ist - nach EC_VIDEO_SIZE_CHANGED noch mal (!) den Ausgabebereich konfiguriert. Das passiert dann also unnötig oft. Zwar scheint es so zu funktionieren, ist aber weder schön noch effizient. Ich kann jedoch nicht die ganzen damit verbundenen (zeitlichen) Abläufe im DVBViewer nur wegen MadVR über den Haufen werfen.

 

Es kann auch bei der Dateiwiedergabe passieren, daß sich plötzlich das Aspect-Ratio oder die Auflösung ändert. Ist zwar extrem selten, aber hatte ich vor einiger Zeit auch schonmal getestet. Das hatte bei meinen Tests damals korrekt funktioniert, von daher gehe ich davon aus, daß alle anderen Media-Player auf EC_VIDEO_SIZE_CHANGED reagieren. Das *müssen* die eigentlich auch, weil die alle verschiedene Zoom-Modi unterstützen, und das funktioniert nur, wenn bei jeder Änderung der Video-Auflösung/-AR der Ausgabebereich neu konfiguriert wird.

 

Nach EC_VIDEO_SIZE_CHANGED den Ausgabebereich neu zu konfigurieren ist also genau das, was jeder (andere) MediaPlayer eh macht, das ist so vorgesehen und sollte eigentlich auch nicht ineffizient sein. Du kannst den Ausgabebereich auch 100x hintereinander setzen, madVR reagiert darauf nur, wenn sich der Ausgabebereich wirklich ändert. Du könntest also theoretisch auch einen Timer machen und den Ausgabebereich alle 10ms setzen, wäre für madVR auch ok. Aber sauberer/schöner ist es natürlich, daß als Reaktion auf EC_VIDEO_SIZE_CHANGED zu tun. Wenn das für den DVBViewer kein Problem ist, das zu machen, wäre es toll, wenn wir das einfach so einbauen könnten. Dann würde sich an dieser Stelle der DVBViewer ähnlicher wie die anderen Media-Player verhalten.

 

Aber wie gesagt, es gäbe auch die Option, daß ich madVR an dieser Stelle anpasse. Wenn euch Devs das lieber ist, kann ich damit auch gut leben...

 

 

Würde sagen jemand sollte mal madshi passende DVB Hardware aus dem Testarchiv zukommen lassen.

Wer meldet sich freiwillig? :)

 

Bisher konnten wir alle Probleme so lösen, von daher weiß ich nicht, ob das nötig ist bzw ob sich das lohnt.

Link to comment

 

Ich habe ihn deshalb gefragt, ob er Sat oder Kabel bei sich empfangen kann... ;)

 

Weiß gar nicht mehr, ob ich darauf geantwortet hatte? Also im Moment hab ich eine Dreambox mit Sat-Tuner, aber die steht bei meinem Bruder im Haus und ich greife per LAN drauf zu (per Streaming). Also ich kann immer einen Kanal am Stück streamen, aber nicht so richtig fließend zwischen verschiedenen Kanälen umschalten...

Link to comment
Nach EC_VIDEO_SIZE_CHANGED den Ausgabebereich neu zu konfigurieren ist also genau das, was jeder (andere) MediaPlayer eh macht, das ist so vorgesehen und sollte eigentlich auch nicht ineffizient sein.

 

Beim DVBViewer geht das über eine Prozedur RealignWindow. Da hängt ein ganzer Rattenschwanz an Aufrufen dran, weil ja z.B. auch das OSD darauf reagieren muss, bis es die unterste Ebene erreicht hat. Das macht es ineffizient. Ich könnte wahlweise auch eine Abkürzung daran vorbei legen, oder über X Stationen einen Parameter übergeben, der besagt, das ist jetzt nur wegen MadVR und hat sonst nichts zu bedeuten. Ich habe die einfachste bzw. am geringsten invasive Variante gewählt.

 

Ob und wie Mediaplayer auf EC_VIDEO_SIZE_CHANGED reagieren, spielt hier IMO keine Rolle. Das kann ja jeder halten wie er will. Das Problem ist, dass MadVR eine von der Anwendung konfigurierte Einstellung hinterrücks abändert. Es spricht nichts dagegen, dass MadVR einen Default setzt. Aber sobald eine Anwendung den Ausgabebereich explizit konfiguriert hat, ist das eine andere Sache. Der DVBViewer muss sich ja regelrecht gegen MadVR durchsetzen.

 

Es mag mir unbekannte Szenarien geben, in denen ein solches Renderer-Verhalten erwünscht ist. Klar ist jedoch, dass MadVR hier einen Sonderweg geht, der eine Sonderbehandlung erfordert.

 

Bei den MS Rendereren gibt es eine Möglichkeit, mit der eine Anwendung bezüglich des Aspect Ratio signalisieren kann "Halte dich da raus!" Zum Beispiel IMFVideoDisplayControl.SetAspectRatioMode(MFVideoARMode_None) beim EVR. Unterstützt MadVR etwas in der Richtung?

Link to comment

Ok, wie gesagt, ich kann das ändern, daß bei einer Video-Auflösungs-Änderung ohne Reconnect madVR das TargetRect unverändert läßt.

 

Das mit dem Aspect-Ratio ist relativ kompliziert, und auch bei VMR7/9 anders gelöst als bei EVR. Ich denke, madVR verhält sich im Moment so als wäre MFVideoARMode_None gesetzt. Was ist aber nun z.B. wenn sich Auflösung und Aspect-Ratio gleichzeitig ändern, und das ohne Reconnect? Sagen wir mal, der Stream ist erst 1920x1080 in 16:9 und switched dann auf 1280x1080 in 4:3. Der DVBViewer würde also bei einem FHD-Display erstmal den Ausgabebereich auf 0x0x1920x1080 setzen. Wenn madVR in dieser Situation nach dem Switch auf 1280x1080/4:3 das Target-Rect unverändert läßt, und der DVBViewer nicht auf EC_VIDEO_SIZE_CHANGED reagiert, heißt das praktisch, daß dann das 1280x1080 Video weiterhin auf 0x0x1920x1080 skaliert werden würde, also dann mit dem falschen Aspect-Ratio dargestellt würde. Das kann doch so nicht der Sinn der Sache sein? Ich denke, daß eine Reaktion des DVBViewers auf EC_VIDEO_SIZE_CHANGED *nötig* ist, andernfalls kann das doch gar nicht richtig klappen?

Edited by madshi
Link to comment

Ich weiß zwar nicht, ob das zum Thema passt, aber was mir fällt auf, dass der verwendete Decoder einen Einfluss auf das Verhalten des Renders hat. Wenn ich Arcsoft und EVR verwende, dann gelingt das Setzen des Aspect Ratio bei den 720p Sendern nicht immer. Oft ist das Bild dann gestaucht mit schwarzen Streifen oben und unten. Durch Hin-und Herschalten gelingt es dann teilweise, dass das Aspect Ratio korrekt eingestellt wird. Teilweise verschwindet aber auch das komplette OSD.

Verwende ich Arcsoft und den Custom EVR, gibt es überhaupt keine Probleme. Verwende ich LAV und EVR, gibt es ebenfalls keine Probleme.

Link to comment

Hier noch ein anderes Timing Problem mit dem OSD...

 

Wenn ich zwischen Das Erste HD und Servus TV HD umschalte (beides H.264), ist alles sauber beim Mini-EPG-OSD beim Umschalten. Es gibt auch keine Schwarzblenden. Beide Kanäle sind unverschlüsselt. Die Umschaltung erfolgt entsprechend schnell.

 

Schalte ich jedoch auf ProSieben HD um gibt es unschöne Verhaltensweisen. Ich gehe davon aus, dass es der Tatsache geschuldet ist, dass ProSieben HD verschlüsselt ist und die Umschaltung entsprechend länger dauert (die NAGRA HD+ Karte ist recht langsam beim Verarbeiten der ECMs). Hier die unterschiedlichen Verhaltensweisen:

 

Das Erste HD (kein Mini-EPG OSD eingeblendet) > ProSieben HD

 

Das Mini-EPG-OSD von ProSieben HD wird ganz kurz eingeblendet und verschwindet sofort wieder. Es kommt mit dem Erscheinen des Videos wieder zurück.

 

Das Erste HD (mit eingeblendetem Mini-EPG OSD) > ProSieben HD

 

Das Mini-EPG-OSD von ProSieben HD wird ganz kurz eingeblendet und weicht dann wieder dem Mini-EPG-OSD von Das Erste HD, welches zuvor eingeblendet war. Das ProSieben HD Mini-EPG-OSD kehrt dann mit Erscheinen des Videos von ProSieben HD wieder zurück.

Link to comment

Das mit den OSD-Problemen, vor allem mit der plötzlichen Resurrection des alten OSDs klingt komisch, das könnte natürlich ein Bug in madVR sein, aber genauso gut auch ein Bug im DVBViewer. Das mit den Schwarzblenden hängt wahrscheinlich mit der Umschaltzeit zusammen. Ich kann mich dumpf erinnern, daß ich die Schwarzblende dann mache, wenn der Graph gestoppt wird und nicht innerhalb eines gewissen Timeouts neu gestartet wird. Ich könnte dort ein API zur Verfügung stellen, das entweder das Timeout für die Schwarzblende einstellbar macht, oder alternativ die Schwarzblende für den nächsten Graph Stop einfach deaktiviert - was immer da euch Devs lieber ist.

Link to comment
Ich denke, daß eine Reaktion des DVBViewers auf EC_VIDEO_SIZE_CHANGED *nötig* ist, andernfalls kann das doch gar nicht richtig klappen?

 

Der DVBViewer weiß durch seinen Sourcefilter früher als der Renderer, was anliegt. Eine Formaterkennung findet dort auf jeden Fall statt - wenn nicht bereits (falls konfiguriert) vor IMediaControl.Run, dann kurz danach. Deshalb ist RealignWindow eventuell schon ausgeführt, wenn MadVR beschließt, aufgrund einer Änderung der Auflösung den Video-Ausgabebereich zurückzusetzen.

Link to comment

 

Der DVBViewer weiß durch seinen Sourcefilter früher als der Renderer, was anliegt. Eine Formaterkennung findet dort auf jeden Fall statt - wenn nicht bereits (falls konfiguriert) vor IMediaControl.Run, dann kurz danach. Deshalb ist RealignWindow eventuell schon ausgeführt, wenn MadVR beschließt, aufgrund einer Änderung der Auflösung den Video-Ausgabebereich zurückzusetzen.

 

Ah, ich verstehe. Allerdings sehe ich hier ein potentielles Problemchen: madVR hat ja eine Decoder-Queue, in der viele Frames im voraus gespeichert werden. Der User kann die Queue bis zu 128 Frames aufdrehen. Bei 25fps Content heißt das, der Decoder liefert Frames an madVR, die ca 5 Sekunden später angezeigt werden. Wenn nun der Sourcefilter das Aspect Ratio umschaltet, weil sich das im Live-TV geändert hat, heißt das, der Sourcefilter macht das in dieser Situation ca 5 Sekunden zu früh. Ok, ist kein dramatisches Problem, und die allerwenigsten User haben die madVR-Decoder-Queue auf 128 Frames aufgedreht. Aber sauberer wäre es, wenn der DVBViewer mit der Änderung des Aspect-Ratios warten würde, bis der entsprechende Frame wirklich gerendert wird - also praktisch in dem Moment wo madVR die EC_VIDEO_SIZE_CHANGED verschickt.

 

Was denkst Du?

Link to comment

Dieses Phänomen habe ich in der Tat erlebt. Ich habe eine 32 tiefe Queue. Griga hat mir ein Sample mit mehrfacher Aspect Umschaltung zukommen lassen. Die Umschaltung hat problemlos funktioniert. Allerdings ist sie immer ca. 0.5-1s zu früh gekommen. Jetzt weiß ich, wieso ;) .

Link to comment

Eine AR-Umschaltung exakt zum richtigen Darstellungs-Zeitpunkt ist schöner, aber der Bezug auf den eigenen Sourcefilter hat den Riesenvorteil, dass wir die volle Kontrolle haben und nicht den Launen von Fremdkomponenten ausgeliefert sind. Wenn etwas schiefläuft, können wir selbst dran drehen.

 

Der User kann die Queue bis zu 128 Frames aufdrehen. Bei 25fps Content heißt das, der Decoder liefert Frames an madVR, die ca 5 Sekunden später angezeigt werden.

 

Gibt das nicht Probleme mit dem Video/Audio-Sync?

Link to comment

Für HEVC bräuchte man wohl noch eine Außnahme in MadVR so wie "Wenn Auflösung höher 1080 dann halte dich komplett raus", oder geht das irgendwie?

Im Moment bringt Live-UHD mit MadVR den DVBViewer zum Einfrieren. EVR und Custom EVR gehen dagegen.

Genau kann ich noch nicht sagen woran das liegt, habt ihr eine Idee?

Link to comment

Für HEVC bräuchte man wohl noch eine Außnahme in MadVR so wie "Wenn Auflösung höher 1080 dann halte dich komplett raus", oder geht das irgendwie?

Im Moment bringt Live-UHD mit MadVR den DVBViewer zum Einfrieren. EVR und Custom EVR gehen dagegen.

Genau kann ich noch nicht sagen woran das liegt, habt ihr eine Idee?

Zumindest kannst du Profile in madVR anlegen für Auflösungen >1080

Dein System wird über dem Limit laufen bei HEVC und der Auflösung.

Link to comment

Denke nicht, glaube eher es hängt mit der Verarbeitung in MadVR zusammen. Bekommt man aber auch kaum raus wenn ich noch nicht mal ein Bild zu Gesicht bekomme.

Zumindest gehen 8Bit HEVC sachen aber nicht 10Bit, auch nicht Files.

Das dass Sys nicht überlastet ist sehe ich ja mit EVR/Custom EVR!

Link to comment

Bei 10bit ist keine GPU Unterstützung vorhanden, d.h. die CPU dürfte schon am Anschlag laufen.

GPU Last ist in madVR (4k Auflösung)wahrscheinlich auch am Limit.

Einige weitere "trade quality for performance" Überlegungen um die GPU-Last zu verringern wurden hier im Thread ja schon diskutiert.

Also mal abwarten und Tee trinken. ;)

 

Eine andere Möglichkeit wäre, dass madVR grundsätzlich mit 10bit nichts anfangen kann, aber das kann ich erstmal nicht bestätigen.

Link to comment

Das mit der zu frühen Aspect Umschaltung kann man auch mit EVR und EVR Custom beobachten. Da ist es aber auch nicht mehr als eine Sekunden. D.h. die Queues sind wohl ca. gleich, wie sie es standardmäßig bei madVR sind.

 

 

Gibt das nicht Probleme mit dem Video/Audio-Sync?

 

Wieso denn? madVR saugt halt gleich mal seine Queues voll. Ausgegeben werden die Frames aber zum richtigen Zeitpunkt.

Link to comment

Für mich sind die Punkte von Griga und madshi beide zutreffend und schließen sich auch nicht aus.

 

Der DVBViewer sollte auf EC_VIDEO_SIZE_CHANGED reagieren um die Umschaltung synchron zur Präsentation zu gewährleisten.

Ich sehe allerdings auch nicht wieso madVR die Einstellung des Mediaplayer, insbesondere ohne reconnect des Videozweigs (bei reconnect einen Default zu setzen ist imho richtig), überschreiben muss. Ohne entsprechende Antwort auf "EC_VIDEO_SIZE_CHANGED" hilft das nur in Ausnahmefällen. Sich hier weiterhin auf den vom Mediaplayer gesetzten Wert zu verlassen scheint mir zielführender.

Link to comment

Dieses Phänomen habe ich in der Tat erlebt. Ich habe eine 32 tiefe Queue. Griga hat mir ein Sample mit mehrfacher Aspect Umschaltung zukommen lassen. Die Umschaltung hat problemlos funktioniert. Allerdings ist sie immer ca. 0.5-1s zu früh gekommen. Jetzt weiß ich, wieso ;) .

 

Wobei madVR das selbst auch noch nicht gut handelt. Wenn sich die Auflösung des Videos ändert, reagiert madVR im Moment auch sofort, wenn der Frame ankommt, statt zu warten, bis der erste Frame in der neuen Auflösung gerendert werden soll. Das muß ich also auch noch nachbessern (steht schon seit langem in meiner ToDo-Liste). Wenn aber der DVBViewer über den Source-Filter schon sehr früh das AR ändert, ist das etwas, das sich zwangsweise so auswirken wird, daß das geänderte AR zu früh kommt, und da sehe ich auch keine große Chance, das irgendwie zu fixen.

 

 

Eine AR-Umschaltung exakt zum richtigen Darstellungs-Zeitpunkt ist schöner, aber der Bezug auf den eigenen Sourcefilter hat den Riesenvorteil, dass wir die volle Kontrolle haben und nicht den Launen von Fremdkomponenten ausgeliefert sind. Wenn etwas schiefläuft, können wir selbst dran drehen.

 

 

Gibt das nicht Probleme mit dem Video/Audio-Sync?

 

Hattet ihr denn da Probleme mit Fremdkomponenten? Vielleicht könnte man eine White-List von Fremdkomponenten machen, denen man vertrauen kann, und wo man darauf verzichen kann, schon im Source-Filter das Ausgabe-Rect umzustellen?

 

Jeder Video- und Audio-Frame kommt mit einem Timestamp. Es ist die Aufgabe des Video- bzw Audio-Renderers, sicherzustellen, daß jedes Audio/Video-Frame zur richtigen Zeit wiedergegeben wird (dazu gibt's ja bei DirectShow eine allgemeine Audio/Video-übergreifende Reference-Clock). Von daher verursachen selbst Queues von z.B. 128 Frames keine AV-Sync-Probleme. Was allerdings passieren kann, ist, daß der Splitter nicht genug voraus liest, um madVRs Queues voll zu füllen. Hab das bei manchen Splittern schon gesehen, daß dann halt die madVR-Queues nicht voll werden. Zumindest beim LAV Splitter ist das aber kein Problem.

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