Video abspielen

also "dreck" findich bisserl übertrieben.
Immerhin kann man damit einen Player coden, überaus kompakt, und der auf jedem Windows sofort lauffähig ist, ohne jede Zusatz-Installation.
AFAIK ist es damit das portabelste von allen.

Nein. Schlicht und ergreifend nein. Es ist ein uralter, total eingeschränkter, schlecht designter und kaum verwendbarer Dreck.

was verneinst du? Dass man einen solchen Player damit coden kann?
Dass alle anderen Technologien von zusätzlichen Installationen abhängig sind?

Deine gesamte Aussage von vorhin und die falsche Aussage von gerade eben. Aber wahrscheinlich liegst du als alter Multimedia-(und allem anderen)Experte richtig.

Aber ich habe meine Aussagen doch belegt!
Ich verlinke ja auf einen solchen portablen Mediaplayer, der auf allen Windowsen ohne Zusatzinstallation lauffähig ist.
Wie also kannst du das verneinen?

Allenfalls könntest du meine annere Teil-Aussage verneinen, dass mci das einzige ist, was solch kann.
Dazu müsstest du aber eine annere Multimedia-Technologie anführen, mit der ebenfalls ein Mediaplayer gecodet werden kann, der ohne Zusatzinstallation auf allen Windowsen lauffähig ist.
Kannst du eine solche Technologie anführen?

Wo liegt denn der Nachteil in MCI? Wenn ich fragen darf. Laut MS ist das weder veraltet noch irgendwie schlecht. Funktionalität wird ja nicht mehr als das benötigt.

Als Ausgabetarget wird ein Win32Window benötigt, in WPF fällt MCI damit also schonmal aus (und ja, hier ist WPF gefordert, falls das keinem aufgefallen ist).
Eigentlich ist die ganze API selbst ein Nachteil, denn von objektorientiertem Programmieren, wie man es unter DirectX vorfindet, kann hier nicht die Rede sein. Stattdessen werden die Befehle in Stringform gesendet, das denkbar schlechteste API-Design überhaupt, selbst aus Sicht von C. In Folge dessen ist die Performance nicht unbedingt das gelbe vom Ei, schnelles Spulen z.B. verursacht auch auf meinem mehr oder weniger guten PC Laggs. Dazu kommt, dass seit Windows Vista und der Einführung des DWM MCI keine gute Bildqualität mehr liefert, denn skaliert wird nicht mehr bikubisch sondern mittels Nearest Neighbour.

Wie ich das kann? Ganz einfach. Das Teil funktioniert zwar in deinem minimalistischem Beispiel. Fliegt dir jedoch schneller um die Ohren als du kucken kannst. Vom äußerst eingeschränkten funktionsumfang mal abgesehen. Alternativen? Alles was nach der Jahrtausendwende geschrieben wurde. Zum Beispiel mediafoundation, directshow, dmo,... oder etwas höheres über wasapi usw.
Und wenn man nur eine simple wiedergabe braucht reicht auch die mediaplayer klasse welche zum einen mehr kann und zum anderen wesentlich sauberer programmiert ist. Alles besser als der uralte verbuggte mist.

Wie gesagt: Alle deine Alternativen müssen extra installiert werden, während mci OnBoard ist.
Ich will jetzt auch garnet mci als iwas dolles anpreisen, nur es ohne jede inhaltliche Begründung als "Dreck" zu verunglimpfen geht mir gegen den Strich (dasses alt ist, ist keine inhaltliche Begründung, alt ist nicht automatisch "Dreck").
Gugge Artentus' Post - so stelle ich mir eine Argumentation vor, wenn man von was abraten möchte.
Der Media-Player sei besser programmiert - konntest du den Code einsehen?
Meinen mci-Wrapper hab ich jdfs. v.a. deshalb geschrieben, weil der mediaplayer so monströs viel Resource frisst.
Also Artentus hat ganz recht mit den bescheuerten String-Befehlen der mci-Schnittstelle: das muss man wrappern, wenn man OOP proggt - und der Wrapper ist dann OOP.

Ob OOP oder nicht ist ja erstmal nicht so Schlimm, aber mit Strings zu arbeiten ist/war schon immer der Falsche weg für Scnittstellen u.ä.
Die MediaFoundation ist glaub ich seit Vista vorinstalliert. Nur der Entwickler muss etwas nachinstallieren(was eher die Norm ist). DirectX 8.0 dürfte seit XP drauf sein und somit steht auch DirectShow zur Verfügung. Hier müssen nur die Wrapper mitgeliefert werden(was einfach wieder .Net spezifisch ist).
Wasapi ebenfalls Vista. DMO hab ich jetzt keine Ahnung und hab ich auch noch nie benutzt.

Von der Verwendung her ist mciSendString absolut vermurkst.

Artentus schrieb:

denn von objektorientiertem Programmieren, wie man es unter DirectX vorfindet

DirectX ist fast ähnlich schlimm aufgebaut bzw. allgemein COM. Aber Strings zu senden ist noch deutlich schlimmer. Mit API's zu werkeln die Fensterhandle betreffen sollte man in WPF lassen, da ist fast alles an API schon verbaut. Wär auch irgendwie blöd in ner Anwendung die mit DX gerendert wird etwas anderes als DX zum Video rendern zu nutzen. DirectX ist also OnBoard.

ErfinderDesRades schrieb:

(dasses alt ist, ist keine inhaltliche Begründung, alt ist nicht automatisch "Dreck").

Sehe ich auch so. Zu 90% ist sogar Älteres deutlich besser.

ErfinderDesRades schrieb:

Wie gesagt: Alle deine Alternativen müssen extra installiert werden, während mci OnBoard ist.

Falsch. Du musst rein gar nichts "extra installieren". Und wie gesagt. Eine Media-API die string basiert, buggy und rein überhaupt nicht erweiterbar ist und den Benutzer in den Möglichkeiten kaum noch mehr einschränken könnte... naja. Was soll ich sagen? Zudem nochmal... es geht um WPF.
Zu der Aussagen, dass alt nicht automatisch Dreck ist -> stimmt. Bei etwas das jedoch sowas von hoffnungslos veraltet ist, trifft diese Aussage sehr wohl zu. Und mci ist veraltet. Und auch wenn du dich bei rein gar allem als Experte fühlst so kann ich dir garantieren, dass dir mci im null komma nix um die Ohren fliegt und dich zudem dermaßen einschränkt, dass du es mit WPF gar nicht verwenden kannst. Außerdem fehlt dir meiner Meinung nach (um es mal auf den Punkt zu bringen) einfach eine Argumentationsbasis. Wie willst du über Vor- und Nachteile von Technologien diskutieren ohne diese zu kennen noch irgendwelche relevanten Erfahrungswerte vorweisen zu können (nein, deine zahlreichen Kreationen zu allem Möglichen zähle ich nicht zwingend zu Erfahrungwerten). PS: Mediafoundation muss auch der Entwickler nix installieren.

Ja mf_player als Feld wobei dich jeder .NET Programmierer köpft wenn du das mf_player nennst.

Nein das ist nicht richtig. Das mag zwar funktionieren aber ich kann einfach nicht sagen, dass das richtig ist. Die Klasse "m_MediaPlayer" ist komplett überflüssig. Der Name der Klasse ist fast das schlimmste das ich je gesehen habe. Dazu ein "public" Feld in der Klasse mit zudem auch falschen Namen. Namensgebung von cmd_music_play_Click Methode lässt mich ebenfalls zusammenzucken. Der Inhalt der Methode macht rein gar keinen Sinn. Weshalb sollte man die MFMediaPlayer Klasse sinnlos kapseln?
Von der Tatsache, dass du das hässliche Codebehind anstatt ViewModel Bindings verwendest sehe ich mal ab.

Die Guidelines findest du hier: msdn.microsoft.com/en-us/library/ms229042.aspx
Ein ViewModel wird für normal der DataContext Eigenschaft zugewiesen und ersetzt das komplette Codebehind (MainWindow.xaml.cs bleibt bis auf den Konstruktor leer).