Jump to content

madVR Renderer in DVBViewer nutzen


Jackie78

Recommended Posts

Es gab mal Bestrebungen von Griga, madVR zu integrieren. Mit seinem Retrosystem konnte er den Renderer aber leider nicht zum Laufen bekommen. Bei der Wiedergabe in MPC-HC stürzte selbiges bei Verwendung von madVR stets ab. Und ohne laufenden Graph kam er auch nicht in die Settings. Hätte aber sowieso nichts gebracht. Soweit ich weiß, setzt madVR ps_3_0 für das Chroma Upsampling voraus, Griga's integrierte Grafik kann lediglich ps_2_0.

Link to comment

und @cinch den Versuch mit seiner exportierten Settingsdatei sabotiert hat. :P

(kleiner Spass)

Willkommen hier im Forum madshi - ich mach mich schon seit geraumer Zeit für madVR im DVBViewer stark und bin der gleichen Meinung wie du.

 

Was beim Versuch von Griga wirklich ungünstig war ist das wir keine Möglichkeit gefunden haben die Settings ohne Wiedergabe zu ändern.

Edited by nuts
Link to comment

Ja, madVR setzt grundsätzlich ps_3_0 voraus (nicht nur für's Chroma Upsampling). Ohne ps_3_0 sind ältere Builds dann gerne mal abgestürzt. Neuere Builds tun das hoffentlich nicht mehr. Hat denn der Griga einen PCIe Steckplatz frei? Hätte hier noch ne alte AMD 3850 rumfliegen, die ich eigentlich nicht mehr brauche, falls er noch Interesse an der Sache hat...

 

P.S: Ja, daß man die Settings ohne Wiedergabe nicht ändern kann ist schon störend. Stört mich selbst auch öfters. Ist auf meiner (laaangen) To-Do-Liste. Ist leider keine Sache von 5 Minuten, das zu ändern, sonst hätte ich es schon längst gemacht...

Edited by madshi
Link to comment

Hi madshi !

 

Freut mich, hier auch mal was von dir zu hören.

Beim MPC-HC schwöre ich ja schon lange auf madVR, und hab daher schon vor einiger Zeit hier den Wunsch geäußert,

das auch für den DVBV möglich zu machen.

 

Die Diskussionen um die Bildqualität mal außen vor, wäre das (vor allem für viele User von Projektoren) schon alleine wegen der angesprochenen Möglichkeiten zur Kalibrirung ein Gewinn für den DVBViewer.

 

Würde mich freuen, wenn es hier ein Stück weit zu einer Zusammenarbeit kommen würde,

die eine Einbindung in den DVBV doch irgendwann mal ermöglicht.

 

 

Gruß: goldfield

Edited by goldfield
Link to comment

Hat denn der Griga einen PCIe Steckplatz frei? Hätte hier noch ne alte AMD 3850 rumfliegen, die ich eigentlich nicht mehr brauche, falls er noch Interesse an der Sache hat...

 

P.S: Ja, daß man die Settings ohne Wiedergabe nicht ändern kann ist schon störend. Stört mich selbst auch öfters. Ist auf meiner (laaangen) To-Do-Liste. Ist leider keine Sache von 5 Minuten, das zu ändern, sonst hätte ich es schon längst gemacht...

Aktuelle Hardware hatte ich beim ersten Kurzversuch auch schon angeboten (Angebot besteht auch weiterhin).

Ist damals etwas unglücklich geloffen.

 

Zum Thema Offline-Settings: Ich stelle mir das sicher wieder zu einfach vor, aber reicht da nicht ein "blöder" Editor, der die Settingsdatei einliest und grafisch etwas aufbereitet?

Also ohne im Hauptprogramm rumzupfuschen. Mit entsprechender Doku könnte ich auch den Editor basteln.

Link to comment
Es gab mal Bestrebungen von Griga, madVR zu integrieren.

 

In den DVBViewer GE, wohlgemerkt, nicht in den DVBViewer Pro. Ich wollte probieren, ob sich madVR über die Standard-VMR9-Interfaces sinnvoll nutzen lässt, oder anders gesagt, ohne großen Aufwand als VMR9-Ersatz eingebunden werden kann. Für den DVBViewer GE hätte das gereicht, da das Baumarktreceiver-Klötzchengrafik-OSD :) mit IVMRMixerBitmap9 auskommt.

 

Im DVBViewer Pro sieht die Sache anders aus. Sein OSD ist wesentlich aufwändiger und komplexer. Nach den Versuchen, es mittels OSD-Filter über einen zweiten Input Pin des Videoerenderers einzuspeisen, was durch Grafikkarten-Treiber-Tücken erhebliche Probleme nach sich zog, ging es Lars und Christian bei der Entwicklung des Custom Presenters vor allem darum, das OSD ohne solche Komplikationenen auf den Bildschirm bringen. Eine Super-Hyper-Bildqualität stand dabei nicht im Vordergrund..

 

Entsprechend verzahnt ist das OSD inzwischen mit der Presenter-Implementation, und ich sehe deshalb keine große Chance für eine externe Lösung. Abgesehen von den Restriktionen meines Hardware-Museums :) habe ich auch nicht den Zugang zum DVBViewer Pro-Code und den Überblick, der nötig wäre, um umfassend in diese Strukturen einzugreifen. Ich bin mehr im Low-Level-Bereich zu Hause, und Hochglanz-Benutzeroberflächen sind nicht mein Ding, wie man am DVBViewer GE sieht...

 

Mit seinem Retrosystem konnte er den Renderer aber leider nicht zum Laufen bekommen.

 

Hatte ich schon erwähnt, dass ich noch Windows 95 benutze? Es läuft auf einer virtuellen Maschine in einem C64... :arrow:

Link to comment

IVMRMixerBitmap9 unterstütze ich derzeit nicht, wäre aber nicht schwer nachzurüsten. Es gibt etliche OSD Interfaces in madVR (siehe "mvrInterfaces.h"). Da gab es Sonderwünsche von diversen Devs, die ich alle eingebaut habe. Falls Du (oder ein anderer DVBViewer Dev) irgendwann mal madVR-Support einbauen wollt, könnte ich auch da wieder spezielle OSD-Interfaces (oder auch andere zusätzliche Interfaces) einbauen/nachrüsten, falls die aktuellen nicht ausreichen. Ich bin da gerne bereit, auf Sonderwünsche einzugehen...

 

Nur als Beispiel, hier ist eins der unterstützten OSD-Interfaces, welches madVR auch selbst intern verwendet:

// this is the main interface which madVR provides to you
[uuid("3AE03A88-F613-4BBA-AD3E-EE236976BF9A")]
interface IMadVROsdServices : public IUnknown
{
  // this API provides the (1) bitmap based method
 STDMETHOD(OsdSetBitmap)(
    LPCSTR name,                           // name of the OSD element, e.g. "YourMediaPlayer.SeekBar"
    HBITMAP leftEye = NULL,                // OSD bitmap, should be 24bit or 32bit, NULL deletes the OSD element
    HBITMAP rightEye = NULL,               // specify when your OSD is 3D, otherwise set to NULL
    COLORREF colorKey = 0,                 // transparency color key, set to 0 if your bitmap has an 8bit alpha channel
    int posX = 0,                          // where to draw the OSD element?
    int posY = 0,                          //
    bool posRelativeToVideoRect = false,   // draw relative to TRUE: the active video rect; FALSE: the full output rect
    int zOrder = 0,                        // high zOrder OSD elements are drawn on top of those with smaller zOrder values
    DWORD duration = 0,                    // how many milliseconds shall the OSD element be shown (0 = infinite)?
    DWORD flags = 0,                       // undefined - set to 0
    OSDMOUSECALLBACK callback = NULL,      // optional callback for mouse events
    LPVOID callbackContext = NULL,         // this context is passed to the callback
    LPVOID reserved = NULL                 // undefined - set to NULL
  );

  

Windows95?? Autsch, nee, bei mir geht's leider erst ab XP los.

Link to comment

Hallo und Willkommen im Forum :)

 

Das Problem ist im DVBViewer mittlerweile das er in den letzten 11 Jahren ziemlich gewachsen ist und die Rudimente wie Overlaymixer und VMR7, VMR9, EVR ohne Allocator/Presenter ziemlich stören. Eingebaut haben wir Allocator/Presenter für EVR und VMR9, sowie für einen eigenen Renderer der aber in der offiziellen Version entfernt wurde - da hier weder DXVA2 noch DXVA funktioniert hat.

Wie Griga schon geschrieben hat die Routinen sind ziemlich verzahnt und äußerst schwer aufzudröseln. Auch rendern wir ja quasi alles selber in einer eigenen Klasse - da ja neben Video auch nen Webbrowser und alles Mögliche angezeigt werden muss.

In der OEM Version vom DVBViewer ist das einfacher, da ich da von Anfang an die alten Ausgabemodis nicht mit drin habe und die Version plattformunabhängig designed ist (dementsprechend läuft sie auch auf dem Mac und *hüstel* IOS via OpenGL).

Link to comment

Moin, und danke für das Willkommen!

 

Das Problem mit dem gewachsenen Code kennt wahrscheinlich jeder Programmierer... :original: Ich persönlich mache immer gerne alle paar Jahre mal eine große Aufräum-Aktion. Aber da muß ich mich auch immer zu zwingen, weil das Zeit kostet, eventuell neue Bugs produziert, und auf den ersten Blick erstmal keine direkten Vorteile für die User bringt. In der gleichen Zeit könnte man halt auch neue Features einbauen, was viel mehr Spaß macht.

 

DXVA2 im eigenen Renderer ist nicht ganz einfach, aber ich hab's inzwischen in madVR ganz gut hingekriegt. Sowohl DXVA2 Deinterlacing als auch DXVA2 Decoding funktionieren grundsätzlich. DXVA hab ich aber weggelassen...

 

Also plattformunabhängig wird madVR auf absehbare Zeit nicht werden.

 

Falls Dich irgendwann mal die Lust überkommen sollte, es mit madVR zu versuchen, kannst Du mich gerne anmailen. Ich stehe gerne mit Rat und Tat zur Verfügung. Auch Anpassungen in madVR sind absolut möglich. Aber wenn's nicht paßt, wegen plattformabhängigkeit oder gewachsenem Code oder Zeitmangel oder warum auch immer, verstehe ich das auch sehr gut...

Link to comment

Interessanter Test. madVR hat zur Zeit keinen Schärfer eingebaut, sondern einfach nur unterschiedliche Scaling-Algos. Man kann also nicht wirklich davon sprechen, daß madVR etwas "anschärft". Der Grund dafür, warum bei Deinem madVR-Screenshot scheinbar die Mosquito-Artefakte so deutlich hervortreten ist wahrscheinlich, daß Du im GPU-Control-Panel die Rauschreduktion (und die Schärfung noch dazu) aktiviert hattest.

 

Genauso ist es - alles auf default bedeutet bei AMD das fast alle *Verbesserer* an sind. Im CCC kann man ja schon allerhand verändern, s. auch oben #78 aber das machen die wenigsten also fotografiere ich default.

An der Stelle wo ich das mit "anschärfen" geschr. habe war behauptet worden mit madVR würde einfach "alles schärfer". Auch vielerorts anders stosse ich immer wieder auf versch. Sorten Wunderdinge die im Zusammenhang mit madVR erwähnt werden. Dann fang ich jedesmal an PCs zu leihen oder zu aktivieren die madVR überhaupt verkraften und such mir die Augen wund wo denn diese wahnsinns-tollen Sachen sind und finde aber visuell nur Verbesserungen im Nuancenbereich. Das steht dann in krassem Gegensatz zu vielen Aussagen im Net die fast immer nur erhebliche Verbesserungen des Bildes hervorheben die ja eigentlich für jeden und immer und sofort deutlich sichtbar sein müssten? Was ist da bloß los?

 

 

Was mich persönlich manchmal etwas stört, ist daß die ganze Diskussion um madVR gerne reduziert wird auf die Frage, ob es auf die schnelle in Screenshots oder im Live-Betrieb einen deutlich sichtbaren Bildqualitätsgewinn gibt oder nicht. Es ist ja nicht so, daß Microsoft und die GPU-Hersteller komplett ahnungslos sind. Wenn die ihre Arbeit richtig machen, dann ist es zu erwarten, daß es eben keinen deutlichen Unterschied in der Bildqualität gibt. Ok, madVR produziert oft bessere Resultate, aber die Unterschiede sind oft nur minimal. In bestimmten Situationen können sie auch mal deutlich sein, aber da muß man dann halt auch mit dem "richtigen" Bildmaterial vergleichen, weil die meisten Bildqualitäts-Vorteile von madVR auch nur in bestimmten Situation deutlich zu Tage treten.

Danke, das hab ich gebraucht! Ich hab lange genug im Showbiz gearbeitet und gelernt das die Menscheit und damit auch das Inet aber halt anders funktionieren - die Leute brauchen Helden und Wunder, dann purzeln die Barrieren und sie heben dich (und sich heimlich auch) auf ihren Schultern in den Himmel. Es braucht gar kein richtiges Wunder zu sein, nur so bisschen, den Rest besorgt die Sehnsucht danach. Die Sache wird dann zum Selbstläufer und entwickelt sich meistens in Richtungen auf die der Erhobene nur noch wenig Einfluss hat.. :)

 

Ich sehe die riesen Arbeit die du dir gemacht hast mit allem gebotenen Respekt. Nach viielen Ansätzen auf unterscheidlicher Hardware muß ich aber gestehen - irgendwie finde ich nicht die Stelle wo's klick macht und ich sagen kann 'ok, für diiese Quali schau ich Filme jetzt nur noch auf dem rasend schnellen PC der mit 80-100 Watt vor sich hinbrodelt.

 

Ich wünsch mir von madVR (jetzt wo du schon mal hier bist :)) das es einen "kühlen" Modus gibt der möglichst ohne tagelages testen womöglich sogar auf halberwegs *mittel-ältlicher* Hardware läuft?

Er braucht nicht ideal zu sein, nicht die letzte Feinheiten rauskitzeln, nur ein-zwei gute Essenzen. Bildlich stell ich mir es so vor, du bohrst eine Art schnelle Pipeline die Kühlwasser transportiert durch das inzwischen ganz schön riesige madVR-gebäude und nur an einigen wenigen stellen tröpfeln ein paar von den heißen scharfen Sachen rein, so irgendwie?

 

Ich glaube mit dem Feature könntest du sogar auch die eine oder andere verknöcherte DVBViewer-Seele hinterm Ofen vorlocken.. :laughing:

Wünsche dir auch weiterhin viel Erfolg!

Link to comment

> Das steht dann in krassem Gegensatz zu vielen Aussagen im Net die fast immer

> nur erhebliche Verbesserungen des Bildes hervorheben die ja eigentlich für jeden

> und immer und sofort deutlich sichtbar sein müssten? Was ist da bloß los?

 

Naja, es hängt halt immer davon ab, was man mit was vergleicht. Wenn man madVR mit Standard-Einstellungen (Lanczos-Upscaling) vergleicht mit einem anderen Renderer, der Bilinear verwendet, dann sieht madVR bei größeren Zoom-Faktoren natürlich deutlich besser aus. Oder wenn man einen TV/Monitor hat, der nur 60Hz darstellen kann, dann sehen Filme mit madVR (bei eingeschaltetem Smooth Motion FRC) deutlich flüssiger aus als bei jedem anderen Renderer. Oder wenn man allergisch auf Ringing-Artefakte ist, dann kann madVR's Anti-Ringing-Filter einen deutlichen Unterschied machen. "Deutlich" ist aber auch immer Auslegungssache. Und was ich inzwischen gelernt habe, ist daß jeder auf andere Sachen allergisch ist. Manche haben Probleme mit DLP-Rainbows, andere nicht. Manche sehen jedes Ruckeln, andere nicht. Manche sehen jedes Ringing sofort, andere nicht. Manche sehen Banding sofort, andere nicht. Da ist vieles dann auch einfach subjektiv.

 

> Ich wünsch mir von madVR das es einen "kühlen" Modus gibt der

> möglichst ohne tagelages testen womöglich sogar auf halberwegs

> *mittel-ältlicher* Hardware läuft?

 

Mein Hauptschwerpunkt liegt zur Zeit darauf, alle noch fehlenden Features einzubauen. Das ist für die Mehrzahl der User im Moment der beste Einsatz meiner Entwicklungs-Resourcen. Wenn alle geplanten Features fertig sind, werde ich mich sicherlich auch nochmal an die CPU- und GPU-Performance-Optimierung setzen. Ich weiß nicht, wieviel sich da noch herausholen läßt. In Sachen CPU läßt sich da bestimmt noch etwas machen. In Sachen GPU bin ich mir nicht so sicher. Aber mal schauen...

 

Auf lange Sicht wird es wahrscheinlich auch einen Auto-Konfigurator geben, der dann die Einstellungen je nach CPU, GPU und Wunsch des Users (Qualität vs. Watt) optimiert. Aber das fällt alles unter "Fine-Tuning". Ich muß erstmal das Grundgerüst (= alle wichtigen Features) fertig stellen...

Link to comment
"Deutlich" ist aber auch immer Auslegungssache. Und was ich inzwischen gelernt habe, ist daß jeder auf andere Sachen allergisch ist. Manche haben Probleme mit DLP-Rainbows, andere nicht. Manche sehen jedes Ruckeln, andere nicht. Manche sehen jedes Ringing sofort, andere nicht. Manche sehen Banding sofort, andere nicht. Da ist vieles dann auch einfach subjektiv.

 

Zusätzlich zur Subjektivität kommt vor allem noch die Anonymität des Internet die die Subjektivität hochpotenziert. Das wird gerne vergessen - zu gerne wären wir doch alle eine große Familie.

 

Aber mit wem wurde schon bis ins Detail die Hardware abgeglichen? Selbst wenn (was sogut wie niemals vorkommt) zwei die gleiche hätten, keiner sieht das der eine im viel helleren Raum vergleicht den er als dunkel empfindet und der andere eine angeborene schwache Farbenblindheit hat. Und am Tage wärend Papa im Geschäft war hat der Kleine mal eben kurz an den Einstellungen vom Fernseher rumgespielt... usw usw, KEINER kann das sehen was der andere sieht und begreifen! Ganz zu schweigen von denen die ganze Romane schreiben und wenn du bei ihnen klingeln würdest käme der 90ger-Nescafe Werbespot grinsend an die Tür: 'Madame, isch abe gar keine Auto, äh Fernseär". Die gibt es! Garantiert!

 

Im Reallife schon schwierig genug, im Internet sozusagen unmöglich Feinheiten abzugleichen. Jedenfalls nach meinen Erfahrungen.

Edited by craig_s
Link to comment

Hallo und Willkommen im Forum :)

 

(dementsprechend läuft sie auch auf dem Mac und *hüstel* IOS via OpenGL).

Ne echt jetzt? Und wen muss ich bestechen, um da dran zu kommen?

Link to comment

Ja, madVR setzt grundsätzlich ps_3_0 voraus (nicht nur für's Chroma Upsampling). Ohne ps_3_0 sind ältere Builds dann gerne mal abgestürzt. Neuere Builds tun das hoffentlich nicht mehr. Hat denn der Griga einen PCIe Steckplatz frei? Hätte hier noch ne alte AMD 3850 rumfliegen, die ich eigentlich nicht mehr brauche, falls er noch Interesse an der Sache hat...

 

P.S: Ja, daß man die Settings ohne Wiedergabe nicht ändern kann ist schon störend. Stört mich selbst auch öfters. Ist auf meiner (laaangen) To-Do-Liste. Ist leider keine Sache von 5 Minuten, das zu ändern, sonst hätte ich es schon längst gemacht...

 

Meine Hilfsmöglichkeiten sind, was das technische und programmiertechnische angeht leider sehr begrenzt, aber falls Interesse besteht, kann ich gerne einen Teil der Hardware aus meiner Sig (Mainboard, CPU, Ram, Graka) für Testzwecke zur Verfügung stellen.

Edited by sw4y
Link to comment
  • 1 year later...

Sorry , ich hol das mal hoch , weil ich mich aus Zeitmangel in den letzten beiden Jahren kaum im Forum beteiligt konnte. Vielleicht ist es für den einen oder anderen von Interesse.

 

Soweit ich mich erinnern kann war ich unter den ersten , die sich hier für eine Integrierung des Renderers von Matthias stark gemacht haben.

Ich hab leider in den letzten Jahren die Diskussion hier im Forum darüber nicht verfolgt , Der DVBViewer war halt meine Fernsehmaschine und die Bildqualität in 4 m Abstand

bei Nichtverwendung des EVR custom auch erträglich. Der EVR custom ist in der untenstehenden Konfiguration ein absolutes No-Go.

 

Gute 720 p Aufzeichnungen waren aber immer ein Domäne von MPC mit MadVR und was Matthias da geleistet hat ist einfach nach meiner Meinung nicht hoch genug einzuschätzen.

 

Zu meinem System :

 

Eigenbau HTPC auf Intelbasis mit 12 GB Mushin Hi- Speed RAM @1600 - Win 7.1 - 2 X ATi Radeon 7850 in den PCI - E 2.0 slots (non Crossfire)

 

1 . ATI 7850 betreibt ausschliesslich den ISP Desktop Monitor mit 1920x 1080

2. ATI 7850 betreibt mit 1920x1080 nur einen ISF kalibrierten 58 " Panasonic Plasma aus der professionellen Panasonic Linie ( TH- 58 PF) - 78 kg :-) und immer noch DIE Referenz in vielen TV-Studios ).

Einstellung : alle Bildverschlimmerungen im ATI CCC sind deaktiviert .

 

Ich würde gerne mal Zweifler an den Vorteilen von madVR einladen sich eine der guten 720/50 p -Aufnahmen der ÖR in folgender Konfiguration anzusehen :

 

MPC-HC mit MadVR

 

Chroma upscaling : NNEDI 3

Image upscaling : Jinc 4 taps mit AR

reduce: banding artefacts

 

Das kann die 7850 OC noch mit knapp 70 % GPU last.

 

Und das mit der gleichen Aufnahme abgespielt durch den DVBViewer zu vergleichen. Das sieht schon eher dramatisch aus,

 

Und damit wollte ich nur ausdrücken - es gibt hier sicher auch noch ein paar Leute , die sich noch wichtige Verbesserungen auch ausserhalb des Recording service und einer HbbTV Implementierung erwarten.

 

 

Nette Grüsse

 

Armin

Edited by vonMengen
Link to comment

Hallo,

 

na ja, das Thema madVR und DVBV ist - seitens der DVBV-Entwickler u. Programmierer - inzwischen abgehakt bzw. war nie angedacht. Es ist wohl, so hab' ich's jedenfalls noch in Erinnerung, zu aufwändig, den Renderer komplett umzubauen - wohl auch oder nur wegen dem Einbinden des OSD's

 

Jedoch hatte ich mich hier versucht, dem Thema madVR in etwas anderer Weise zu nähern und zwar mit einem Umweg über den RecordingService + MPC-HC. Das funktioniert zwar, aber ist - wie auch qupfer in Post #2 schreibt - nicht sehr komfortabel zu handhaben...leider. Denn wenn man die rtsp-channellist in MPC-HC geladen hat, bekommt man eine ellenlange Wiedergabeliste mit allen möglichen Sendern der Senderliste in MPC-HC - natürlich ohne die eigentliche Sendernamen, so dass man keinen bestimmten Sender direkt anwählen kann, sondern zappt wild durch die Liste, was ziemlich nervt.

 

Sollte jedoch eine Möglichkeit bestehen, nur einen - vorher bestimmten - Sender oder nur die Favoritenliste aus dem DVBV zu laden, dann sieht's, jedenfalls für mich - schon wieder anders aus!

 

 

Grüße

 

 

getilus

  • Like 1
Link to comment

Das OSD verhindert einen besseren Renderer. Das OSD verhindert eine bessere Oberfläche (z.B. Cover Flow). Das OSD verhindert durch seine seltsamen API Calls die Programmierung von OSD-Plugins in C++.

 

Vielleicht denkt ja einer der DVBViewer Entwickler doch irgendwann mal darüber nach, diesen antiquierten Kram durch was Neues zu ersetzen. Auch wenn das heißt, dass einige lieb gewonnene OSD Skins dann nicht mehr funktionieren.

 

Einige Settop Boxen setzen mittlerweile komplett auf HTML5.

Edited by dbraner
  • Like 1
Link to comment

Das ist mit Verlaub Unsinn. Das OSD ist nicht ausgelegt über die Maßen jedes Element zu animieren. Das liegt zum einen daran das für die Darstellung teilweise GDI+ benutzt wird und zum anderen nach kurzer Zeit nerven würde. Coverflow hatte ich vor Jahren als Element eingebunden, aber eine Liste ersetzt so etwas nicht. Probier doch mal tausende von Musikalben mit nem Coverflow durchzuscrollen. Da ist eine Liste praktischer.

OSD Plugins können auch mit C++ programmiert werden, da muss man auch nicht wirklich Verrenkungen machen mit C# gehts sogar noch einfacher.

MadVR war in der Form nicht geplant, da Cinch in den letzten Monaten viel Arbeit in eine eigene Renderlösung gesteckt hat die ich auch mittelfristig einbinden wollte. Wie das aber so ist, es gibt zusätzlich dazu dutzende von anderen Baustellen und wir können uns nicht wirklich zerteilen.

Das derzeitige OSD zu ersetzen käme einer Neuentwicklung der Software gleich und das ist bei dem Umfang nicht wirklich realisierbar. Es wäre sicherlich einfacher, wenn man die finanziellen Mittel hätte ein Team von mehreren Entwicklern zu bezahlen und eine, auf dem gesammelten Wissensfundus der letzten Dekade, komplett neue Software zu erstellen. Aber so lange ich selbst noch per Mail oder Telefon Grundsatzdiskussionen führen muss, warum die Software nicht kostenlos ist, ist so etwas eher ein Wunschtraum.

Link to comment

Naja in eine Machbarkeitsstudie von madVR (inkl. OSD natürlich) hätte man schon mal investieren können ...

Vielleicht in einer nicht öffentlichen OEM Version?

Der "Delphi Header" liegt jeder madVR Installation bei und ein Angebot von madshi ggf. zu helfen gab es auch schon.

Was will man da noch mehr?

Ich bin immer noch davon überzeugt, dass es dafür einen grossen Bedarf gibt.

Mediaplayer mit madVR gibt's mittlerweile einige, aber keine DVB taugliche Software damit!

Die Zielgruppe HDTV und bestmögliche Bildqualität ist imho durchaus vorhanden, da Streamingquellen auf absehbare Zeit da nicht mithalten können.

Edited by nuts
  • Like 1
Link to comment

Das Problem ist der Aufwand, da wir auf so viele Anhängsel wie Overlay Modus, VMR7/9 Nativ etc. angewiesen sind. Dadurch kommen Seiteneffekte hinzu, die schlicht durch die ganzen Kombinationsmöglichkeiten berücksichtigt werden müssen. Wenn wir bis auf den VMR Allocator den Rest entfernen könnten und den dazu gehörigen Code im OSD ebenso, wäre der Aufwand vertretbar(er).

Link to comment

Die OEM's haben doch eh nur die beiden Custom Renderer?

Davon mal eine mit Sat>IP Funktionalität als Codebasis genommen und den madVR hinzugefügt.

Und dann testen wir mal und vielleicht verschwinden die Berührungsängste. ;)

 

P.S. Overlay und die VMR's könnte imho eh weg.

Wüsste nicht was man nach XP damit machen söllte?

Link to comment

Soweit ich das sehe kann ich Mad zwar meine Direct3D9 Handler übergeben, aber ich denke die aktuelle IDirect3DTexture9 liefert er mir für die Ausgabe nicht zurück. Das bedeutet ich müsste für MadVR mindestens noch die OSD Ausgabe zusätzlich umbiegen, damit man diese an MadVR übergibt. Unter Umständen muss ich dafür auch noch beachten, dass die Anzeige stehen bleibt, wenn der Graph keine Videodaten liefert und oder Pausiert. Das ist nen ganz schöner Aufwand. Soweit ich mich erinnere lag Cinchs Demo qualitativ bei dem was MadVR dargestellt hatte und da bekomme ich als Ausgabe das was ich benötige.

Die OEM ist komplett in 3D und wird gerendert, die Videotextur ist da wie die anderen Texturen eine einfache Texture die ich theoretisch auf alle Quads pinseln kann. Das komplette Renderverhalten dort umzubiegen würde bedeuten ich müsste den Renderer umstellen. Derzeit wird dort so etwa gemacht:

 

Matrices.Push;

Matrices.TranslateLocal(ox, oy, 0.0);
Matrices.ScaleLocal(sx, sy, 1.0);
// Zeichne Texture
col := D3DCOLOR_ARGB(trunc(alpha_factor * 255), 255, 255, 255);
SetVertex(-1, 1, 0, col, 0, 0, pix[0]);
SetVertex(1, 1, 0, col, 0, 0, pix[1]);
SetVertex(-1, -1, 0, col, 0, 0, pix[2]);
SetVertex(1, -1, 0, col, 0, 0, pix[3]);
if assigned(FTexture) then
begin
c := FTexture.GetActiveCoord();
pix[0].tu := c.tu1; pix[0].tv := c.tv1;
pix[1].tu := c.tu2; pix[1].tv := c.tv1;
pix[2].tu := c.tu1; pix[2].tv := c.tv2;
pix[3].tu := c.tu2; pix[3].tv := c.tv2;
dev.SetTexture(0, Ftexture.Texture);
end else
dev.SetTexture(0, nil);
dev.SetFVF(D3DFVF_SIMPLEVERTEX_3D);
dev.SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_SELECTARG1);
dev.SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE);
dev.SetTextureStageState(0, D3DTSS_ALPHAOP, D3DTOP_MODULATE);
dev.SetTextureStageState(0, D3DTSS_ALPHAARG1, D3DTA_DIFFUSE);
dev.SetTextureStageState(0, D3DTSS_ALPHAARG2, D3DTA_TEXTURE);
dev.DrawPrimitiveUP(D3DPT_TRIANGLESTRIP, 2, pix, sizeof(TSIMPLE_VERTEX));
dev.SetTexture(0, nil);
Matrices.Pop();
Device.SetTransform(D3DTS_WORLD, Matrices.GetTop);
Link to comment

 

Soweit ich das sehe kann ich Mad zwar meine Direct3D9 Handler übergeben, aber ich denke die aktuelle IDirect3DTexture9 liefert er mir für die Ausgabe nicht zurück. Das bedeutet ich müsste für MadVR mindestens noch die OSD Ausgabe zusätzlich umbiegen, damit man diese an MadVR übergibt.

 

Es gibt da zwei unterschiedliche Ansätze:

 

(1) Entweder der MediaPlayer hat die Kontrolle über die Video-Ausgabe, bekommt irgendwoher das gerenderte Videobild in einer RGB-Texture übergeben, malt noch ein OSD drüber und kümmert sich das selbst darum, daß das ganze an Direct3D für die Ausgabe übergeben wird.

 

(2) Oder der MediaPlayer überläßt die Kontrolle über die komplette Video-Ausgabe dem Video-Renderer. Das würde aber heißen, der MediaPlayer müßte das OSD in einem Callback des Renderers malen, z.B. auf eine vom Renderer gestellte Texture, oder einfach auf das aktuelle Render-Target.

 

Grundsätzlich sind beide Konzepte irgendwo "sinnvoll". XBMC beruht auf dem Konzept (1), während madVR eigentlich für (2) gebaut ist. Das ist auch der Grund, warum XBMC bisher kein madVR unterstützt. Soweit ich das verstehe, funktioniert der DVBViewer auch eher wie (1), ist das richtig? Wenn man jetzt DVBViewer und madVR verheiraten wollte, müßte man entweder DVBViewer das Konzept (2) beibringen, oder alternativ in madVR optionale Unterstützung für das Konzept (1) einbauen.

 

Es gibt ein paar gute Argumente dafür, warum madVR (2) verwendet. Ohne (2) könnte madVR sonst folgende Features nicht umsetzen, wofür dann der MediaPlayer zuständig wäre:

 

- "smooth motion FRC": ruckelfreie Wiedergabe durch Echtzeit-Blending, wenn Video-Framerate und Display-Refresh-Rate nicht übereinstimmen.

- Display-Management: unterschiedliche Einstellungen je nach Display (Multi-Monitor-Setup)

- Display-Management: unterschiedliche Kalibrierung je nach Display

- Display-Management: unterschiedliche Panel-Alignment je nach Display usw usw

- automatische Refresh-Rate-Anpassung an die Video-Framerate

- tiefe Präsentations-Queue, um ruckelfreie Wiedergabe auch in Streß-Situationen zu garantieren

- native 10bit und 16bit Ausgabe (nur möglich im Fullscreen-Exclusive-Mode)

- 3D-Ausgabe mit voller Auflösung (frame packed anstatt side by side)

- usw...

 

Mein Ziel war es, dem Media-Player möglichst viel Arbeit abzunehmen. Das klappt aber halt nur, wenn madVR auch die Kontrolle über die Präsentation hat. Grundsätzlich könnte ich mir vorstellen, madVR auch einen Modus beizubringen, in dem es "dumm" einfach nur Frame by Frame das Videobild in möglichst guter Qualität in RGB auf eine gewünsche Auflösung umwandelt, um Media-Player nach dem Konzept (1) zu unterstützen. Wenn es nicht zu viel Aufwand wäre, wäre es aber wünschenswert, wenn stattdessen der Media-Player sein eigenes Renderung in einem Callback machen könnte. So würde der volle Funktionsumfang von madVR erhalten bleiben.

 

 

 

Unter Umständen muss ich dafür auch noch beachten, dass die Anzeige stehen bleibt, wenn der Graph keine Videodaten liefert und oder Pausiert.

 

Das ist im Moment leider tatsächlich so, aber das hat auch schon andere Media-Player-Devs gestört, und das ist auf meiner ToDo-Liste, das so zu ändern, daß madVR "immer" rendert, auch wenn (aus welchem Grund auch immer) keine Video-Frames vom Dekoder kommen.

 

 

 

Soweit ich mich erinnere lag Cinchs Demo qualitativ bei dem was MadVR dargestellt hatte [...]

 

Sicherlich ist es kein großes Problem, einen Scaling-Algorithmus wie z.B. Lanczos nach zu programmieren, oder die DXVA-Scaling-Algorithmen verfügbar zu machen. Das ist wahrscheinlich das, was Cinch gemacht hat. Vielleicht hat er auch vernünftiges Dithering eingebaut. Damit läßt sich dann vielleicht die Qualität von madVR zu 95% nachbilden. So daß die meisten Leute mit bloßem Auge keinen Unterschied mehr sehen. Das gilt aber nur, solange keine Special-Features von madVR verwendet werden. Hat der Cinch auch NNEDI3-Unterstützung eingebaut? Und Smooth Motion FRC? Und Debanding? Und Kalibrier-Funktionalität usw? Seit neustem wird madVR inklusive dem madVR-Test-Pattern-Generator z.B. auch direkt von Calman unterstützt (der wahrscheinlich am weitesten verbreiteten Kalibrierungssoftware). Ich hab so meine Zweifel, ob Cinch all diese Features "mal so eben" nachgebaut hat. Und madVR ist ja auch noch lange nicht am Ende der Fahnenstange angekommen. Da sind noch viele weitere Features geplant...

 

Aber wie schon früher gesagt: Die Entscheidung, ob Du madVR in DVBViewer unterstützen möchtest, ist vollkommen Dir überlassen. Falls Du Interesse hast, helfe ich gerne, auch mit neuen Interfaces usw. Falls Du kein Interesse hast, ist das nach wie vor auch ok für mich.

  • Like 1
Link to comment

Hi madshi,

 

Cinch hat in seinem Renderer den DXVA Scaler, Bypass bei Quelle=Ziel, die verwendbaren Funktionen für Shader (Pixelshader 3.0) erweitert und die Sync Algos optimiert.

Ich bin ihm für seine Arbeit auch sehr dankbar, aber mit dem was madVR leistet kann man das wirklich nicht vergleichen.

 

Der madVR "dumm" Modus hört sich gut an!

Vielleicht hilft das auch XBMC? Deren Benutzer leiden nämlich auch unter mieser Bildqualität.

Mal sehen was Christian meint. ;)

Link to comment

Der DXVA Scaler ist recht praktisch für Intel-User, weil dort die Scaling-Qualität recht ordentlich ist (fast so gut wie madVR's Lanczos mit anti-ringing). Bei NVidia und AMD ist die DXVA Scaling Qualität aber eine Klasse schlechter im Vergleich zu Intel, zumindest war das so, als ich es das letzte Mal vergleichen habe, was schon eine Weile her ist. Kann sein, daß NVidia/AMD da mit neueren Treiber-Versionen nachgebessert haben. Bei NVidia/AMD läuft das DXVA-Scaling nämlich über die Shader-Einheiten, soweit ich weiß, also läßt sich da mit neueren Treiber-Versionen was machen. Bei Intel hingegen ist das fest verdrahtete Hardware, glaube ich. Vorteil: Die Shader-Einheiten sind bei Intel komplett frei für andere Sachen...

Link to comment

http://www.DVBViewer.tv/forum/topic/37505-madvr-renderer-in-DVBViewer-nutzen/?p=392746

Es gab mal Bestrebungen von Griga, madVR zu integrieren. Mit seinem Retrosystem konnte er den Renderer aber leider nicht zum Laufen bekommen. Bei der Wiedergabe in MPC-HC stürzte selbiges bei Verwendung von madVR stets ab.


Inzwischen habe ich hier eine ATI Radeon HD 4300/4500 im Stall. Kann man damit MadVR verwenden?

Ich hatte früher eine Integration in den DVBViewer GE ins Auge gefasst, aber keine geeignete Hardware, um den Renderer in Betrieb zu nehmen. Abgesehen davon, dass mir damit jegliche Testmöglichkeit fehlte, hat zum Abbruch der Bestrebungen beigetragen, dass mir MadVR als Nerd-Produkt entgegenkam, das ungeeignete Systemvoraussetzungen in keiner Weise sinnvoll behandelte - nach dem Motto: Wenn der User nicht überblickt, was seine Graka kann und was der Renderer voraussetzt, ist das sein Problem. Mein Fazit war: Insbesondere unbedarften Anwendern ist das nicht zuzumuten. Und von denen gibt es erfahrungsgemäß beim DVBViewer einige... die Folgen hat dann oft Christian beim Support auszubaden, bis hin zu wüsten Beschimpfungen und Drohungen.

hackbart, on 28 Dec 2014 - 11:07, said:snapback.png

Unter Umständen muss ich dafür auch noch beachten, dass die Anzeige stehen bleibt, wenn der Graph keine Videodaten liefert und oder Pausiert.



Das ist im Moment leider tatsächlich so, aber das hat auch schon andere Media-Player-Devs gestört, und das ist auf meiner ToDo-Liste, das so zu ändern, daß madVR "immer" rendert, auch wenn (aus welchem Grund auch immer) keine Video-Frames vom Dekoder kommen.

 


Für Player mit OSD, die Live-Quellen wiedergeben, ist das ein K.o.-Kriterium, weil dabei öfters spontan Daten ausbleiben, egal ob DVB- oder Internet-Stream. Es ist mörderisch kompliziert, die Anwendung in solchen Fällen zuverlässig auf eine vom Renderer unabhängige Art OSD umzuschalten, damit der HTPC bedienbar bleibt. Hinzu kommen noch die voraussehbaren Gelegenheiten, bei denen das Bild anhält oder es keines gibt (Pause, Radiosender usw.).

Für den DVBViewer GE wäre es nicht so entscheidend, da er mehr desktop-orientiert und insgesamt einfacher strukturiert ist. Er hat zwar auch ein OSD und behandelt die voraussehbaren Fälle, in denen das Bild anhält, aber nicht die unvermuteten. Dann funktioniert das OSD eben nicht mehr (*schulterzuck*).

Wenn man sich die Vielzahl komplizierter Work-Arounds im DVBViewer Pro-Code anschaut, um VMR, EVR & Co zumindest notdürftig mit den OSD-Anforderungen zur Deckung zu bringen, versteht man, dass Lars und Christian nach der Entstehung des EVR Custom Presenters absolut keinen Bock hatten, sich erneut auf sowas einzulassen, selbst wenn der Renderer eine überragende Bildqualität liefert. Der Custom Presenter kann immer ein reaktionsfähiges OSD darstellen.

Im DVBViewer GE würde ich es eventuell noch mal mit MadVR probieren, wenn es dafür eine vernünftige Perspektive gibt, d.h. der Renderer bei mir ohne Hardware-Investitionen funktioniert und die erforderlichen Interfaces bietet. Das OSD läuft nach wie vor über IVMRMixerBitmap9 bzw. IMFVideoMixerBitmap - ob es auch mit einem Callback ginge, ohne alles mögliche umzuwerfen, wäre auszuloten. Dazu braucht es noch Kleinigkeiten wie IVMRAspectRatioControl9, IVMRMixerControl9 oder vergleichbares.

Das größte Problem dürfte jedoch sein, dafür Zeit zu finden.... ;)

  • Like 1
Link to comment

Hi Griga,

 

die Radeon 4300/4500 sollte laut Wikipedia Direct3D10.1 unterstützen, sollte also problemlos mit madVR laufen. Die Geschwindigkeit wird wahrscheinlich nicht so dolle sein, aber wenn man madVR auf entsprechend niedrige Scaling-Einstellungen setzt (z.B. Bilinear oder DXVA Scaling), sollte es eigentlich flüssig laufen.

 

Du hast schon Recht, daß es keine gute Situation ist, wenn madVR einfach abstürzt oder gar nichts anzeigt, wenn die GPU zu alt ist. Oder daß madVR nicht rendert, wenn der Decoder keine Frames liefert. Aber wenn Dir irgendwas nicht gefällt, bin ich ja jederzeit gerne bereit, Anpassungen zu machen. Also mail mich in so einer Situation dann einfach an, und ich versuche dann, das Problem möglichst schnell zu lösen. Requests von Devs behandele ich grundsätzlich bevorzugt. Also wenn Du Lust hast, es nochmal mit madVR zu versuchen, sag Bescheid, ich leiste dann auch gerne via eMail Support (nur für Devs, nicht für Enduser).

 

IVMRMixerControl9 unterstütze ich schon (allerdings bisher nur das ProcAmp-Krams, noch nicht die anderen Sachen). Das IVMRAspectRatioControl9 Interface ist von Microsoft eigentlich für den VMR7/9 "windowless" Mode gedacht. madVR funktioniert eher wie der VMR7/9 "windowed" Mode. Da verwendet man dann eigentlich die IBasicVideo2/IVideoWindow Interfaces statt des IVMRAspectRatioControl9. Aber wenn Du lieber IVMRAspectRatioControl9 verwenden möchtest, können wir da auch drüber reden.

 

Natürlich ist alles auch bei mir eine Zeit-Frage. Manchmal kann ich ganz schnell eine neue Version rausbringen, und manchmal (wie gerade jetzt) bin ich mit meinen kommerziellen Projekten ausgelastet. Aber wie gesagt, grundsätzlich haben bei mir Dev-Requests immer Vorrang. Das sieht man auch an der neusten madVR-Build, wo ich quasi nur für Calman diverse neue Kalibrierungs-APIs eingebaut habe...

Link to comment

Ist es eventuell möglich dem Filter ein Interface zu übergeben wo man das Device angibt, die vom Allocator übermittelten Texturen, sowie die gewünschte Zielauflösung der Textur und diese dann über ein Callback geliefert bekommt? Am besten, ohne den Filter mit einem Graph zu verbinden.

 

Christian

Link to comment

Das wäre dann Konzept (1) aus meinem Kommentar #104. Das wird bisher von madVR noch nicht unterstützt, wäre aber grundsätzlich machbar, mit etwas Zeiteinsatz auf meiner Seite. Nachteil wäre der Verlust einiger madVR-Features. Aber wenn Dich das motivieren würde, auf diese Weise madVR in eingeschränkter Form zu unterstützen, könnte ich mir das vorstellen, mich da mal dran zu setzen. Was meinst Du?

 

Mathias.

Link to comment

Na ja, anscheinend kommt der Stein ins Rollen...super!

 

Ich verstehe natürlich absolut überhaupt nichts von diesem gesamten Programmier-"Kram", aber die grundsätzliche Bereitschaft von Christian und Griga, sich - nochmals - mit madVR auseinander zu setzten, ist schon klasse.

 

Und: Mit den von madshi genannten "Einschränkungen" von madVR bei Integration in den DVBV in Form von Variante (1) kann ich sicher leben, denn alle soweit genannten Punkte sind - jedenfalls für mich - ein "nice to have" aber zunächst für den Betrieb von DVBV eher unnötig.

 

 

Gruß

Edited by getilus
Link to comment

Wenn so ein Interface vorhanden wäre, könnten wir ohne enormen Aufwand den Filter zwischen unseren Allocator/Presenter und dem Renderer dazwischen schalten. Das wäre dann so etwas wie ein Postprocessor. Wobei das dazwischenschalten eines echten Postprocessors-Filters (der die Zielauflösung übermittelt bekommt) natürlich noch einfacher wäre.

Link to comment

Das mit einem "echten" Postprocessing-Filter (per DirectShow-Filter-Chain) würde wahrscheinlich nicht klappen, weil der glaube ich die Bilder im CPU-RAM erwartet. Das wäre sehr ineffektiv, wenn ich die Bilder per CPU-RAM bekäme und dann nach der Bearbeitung wieder vom GPU-RAM zurück in den CPU-RAM runterladen müßte. Da müßte ich dann auch die komplette DirectShow-Einbindung neu machen, das wäre sehr aufwendig. Da mache ich lieber ein Custom-Interface. Das sollte für mich nicht so schwierig einzubauen sein, und auch nicht so schwierig für den DVBViewer zu benutzen. Ich stelle mir das Custom-Interface in etwa wie folgt vor.

 

Die Funktionen wären einfach über GetProcAddress(madVR.ax) erreichbar. Die Funktionen wären "blocking", kämen also erst nach getaner Arbeit zurück.

 

Würde das so Sinn machen? Oder hättest Du das lieber anders?

 

P.S: Deinterlacing über DXVA müßtest Du dann aber selbst machen. Das muß grundsätzlich immer *vor* dem Scaling passieren. Ansonsten könnte ich das Deinterlacing auch übernehmen, aber dann wird das Interface etwas komplizierter...

 

 

 

// The following functions convert the source video frame to the
// specified target texture. The image is stretched over the whole
// target texture, so both scaling and aspect ratio corrections can
// be achieved in one step.
// The target texture should be some sort of RGB texture. It is
// recommended to use the bitdepth of the GPU output mode,
// which in most cases is 8bit RGB.
// Black/white are set to either 0/255 or 16/235, depending on the
// "videoLevels" parameter.

BOOL WINAPI PostProcessRgbTexture(LPDIRECT3DTEXTURE9 srcVideoFrame, LPDIRECT3DTEXTURE9 dstVideoFrame, BOOL videoLevels);
BOOL WINAPI PostProcessDxvaSurface(LPDIRECT3DSURFACE9 srcVideoFrame, LPDIRECT3DTEXTURE9 dstVideoFrame, BOOL videoLevels);

// This function will close all resources which might still be open
// due to earlier calls of the "PostProcessXxx" functions.
BOOL WINAPI ReleaseResources();

Edited by madshi
Link to comment

Schön das wir hier eine Diskussion über das Thema haben. :)

 

Da die DVBViewer Entwickler selbst madVR wohl nicht wirklich kennen möchte ich zur Design Entscheidung nochmal auf diesen Punkt hinweisen:

(2) Oder der MediaPlayer überläßt die Kontrolle über die komplette Video-Ausgabe dem Video-Renderer. Das würde aber heißen, der MediaPlayer müßte das OSD in einem Callback des Renderers malen, z.B. auf eine vom Renderer gestellte Texture, oder einfach auf das aktuelle Render-Target.

...

Es gibt ein paar gute Argumente dafür, warum madVR (2) verwendet. Ohne (2) könnte madVR sonst folgende Features nicht umsetzen, wofür dann der MediaPlayer zuständig wäre:

 

- "smooth motion FRC": ruckelfreie Wiedergabe durch Echtzeit-Blending, wenn Video-Framerate und Display-Refresh-Rate nicht übereinstimmen.

...

- 3D-Ausgabe mit voller Auflösung (frame packed anstatt side by side)

- usw...

...

Grundsätzlich könnte ich mir vorstellen, madVR auch einen Modus beizubringen, in dem es "dumm" einfach nur Frame by Frame das Videobild in möglichst guter Qualität in RGB auf eine gewünsche Auflösung umwandelt, um Media-Player nach dem Konzept (1) zu unterstützen. Wenn es nicht zu viel Aufwand wäre, wäre es aber wünschenswert, wenn stattdessen der Media-Player sein eigenes Renderung in einem Callback machen könnte. So würde der volle Funktionsumfang von madVR erhalten bleiben.

Gerade "smooth motion FRC" ist eigentlich ein Killer-Feature für eine DVB-Anwendung in der PAL Region.

Damit kann die Ruckelei auf 60hz Schirmen (jeder Laptop, fast jeder PC Monitor) deutlich verbessert werden.

Und es kann bei dem Thema PCR Clock vs Directshow Clock helfen, wenn die Bilder minimal zu langsam eintreffen.

Bei einer Streaming Umgebung ist das, zumindest in eine Richtung, ein durchaus nützliches Feature!

 

Das Thema 3D taucht hier im Forum ja auch immer mal wieder auf. Mit madVR und "vollem" Funktionsumfang käme dann auch etwas Leben in das Thema. ;)

 

P.S. Wäre dafür, dass madVR das DXVA Deinterlacing übernimmt. Die Bildqualitäts Dinger sind dort besser aufgehoben. :D

Edited by nuts
Link to comment

Wunderbar - vll . kommt der Stein doch noch ins Rollen !

 

Und es ist auch wirklich an der Zeit . Und das auch , wenn ich jetzt nicht nur von absoluten High- end Konfigurationen ala > 4 k Beamer oder Hi- end Plasmas ausgehe , wo es sowieso keinerlei Alternative für MadVr gibt.

In über 30 % der deutschen Haushalte stehen schon Tvs mit 40 " und mehr. Und auch dem letzten Dau wird es irgendwann mal auffallen , dass die Bildqualität des DVBviewers nicht unbedingt zeitgemäss ist. Der Renderer von Cinch ist ein erster Erfolg.

Allerdings bin ich einer der User des Renderers von Mathias der ersten Stunde ab 2006 (mit einigen Beiträgen auf AVS ) und alles was nuts oben beschrieben hat , ist zu unterschreiben. Ich war früher Jahre in der Video - und TV Produktion tätig und schon vor 2010 war ein Analyse von 2K Material von professionellen HD - Cams über einen Pro-Plasma mit MadVr ein Grund für wahre Freude.

 

Nette Grüsse

Armin

Link to comment

Bin auch sehr erfreut darüber, das sich hier jetzt scheinbar doch noch was in Richtung madVR bewegt.

Das "Konzept (1)" wäre sicher schon ein Fortschritt, und dem EVR-Custom in der jetzigen Form deutlich überlegen.

 

Ansonsten sehe ich das aber genau wie nuts.

Gerade Smooth motion, und vor allem die Kalibrierfunktion sind bei vielen Besitzern von Projektoren oder Großbildschirmen im Heimkino-Bereich nicht ohne Grund sehr beliebt.

Bei einigen Herstellern von Heimkino-Projektoren sind vergleichbare Funktionen leider ganz bewusst nur den größeren/teureren Modellen vorbehalten (z.B. die ansonsten Baugleichen TW4400/TW5500).

Da hat man mit dem Funktionsumfang von madVR u.U. schon ein gewaltiges Werkzeug zur Hand.

 

Das es deutlich komplizierter wird, madVR mit vollem Funktiosumfang zu integrieren, glaube ich gerne.

Andersrum hat man danach dann aber Ruhe, weil sich madshi um die weitere Entwicklung des Renderers kümmert.

Und das da das Ende der Fahnenstange noch nicht erreicht ist, hat er ja selbst schon des öfteren angedeutet.

 

Edited by goldfield
Link to comment

Kalibrierung würde wahrscheinlich doch auch beim "Konzept (1)" gehen, hab ich mir gerade überlegt, weil ich über das Direct3D-Device eigentlich auch rauskriegen können müßte, auf welchen Monitor gerendert wird. Bei den meisten anderen genannten Punkte bleibt es aber dabei, daß die nur beim "Konzept (2)" funktionieren.

Link to comment

Also bei der ganzen euphorie hier, hört sich das für mich sehr danach an das es bei MadVR noch einige Probleme gibt.

 

Sowohl das keine wiedergab, eigentlich auch kein Bild bedeutet.

Also wenn weder TV noch Video läuft ist der Bildschirm einfach schwarz z.B. auch wenn man Pause drückt.

 

Und auch wie gut sich das OSD einbinden lässt ist noch die Frage.

 

Wenn ich das richtig verstehe geht das beides nicht so ohne weiteres wie beim Custom EVR. Und vor allem die anzeige vom Standbild oder OSD wenn kein Video läuft hört das sich für mich bisher so an, als ob das nur mit Krücken und Workerauds aber nicht sauber geht.

 

Aber wenn es allen egal ist, dass es bei Stopp der Bildschirm schwarz wird und es erst wieder ein OSD gibt wenn man ohne Bild die wiedergebe gestartet hat ist das ja kein Problem. :innocent:

 

( :whistle: Eventuell sollte man einfach sagen wer ein OSD braucht nutzt den Custom EVR und werk nur ein gutes Bild während der wiedergebe brauch und sonst nichts nutzt MadVR :shiftyninja: )

Link to comment

Das Problem mit dem fehlenden Rendering wenn kein TV/Video läuft würde beim "Konzept (1)" nicht auftreten. Für "Konzept (2)" wäre da eine Änderung in madVR nötig, aber das sollte nicht allzu schwer sein. Also wenn Interesse seitens der DVBViewer-Devs am Konzept (2) besteht, könnte ich das in meiner Prioritätenliste für madVR ganz nach oben setzen. Ich möchte aber nur ungern meine Prioritätenliste durcheinander würfeln, wenn's dann nachher doch nicht genutzt wird, deshalb warte ich erst noch auf Rückmeldung der Devs, bevor ich irgendwas mache...

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