Clarifications on advanced Windows.Media.Casting scenarios

[reflectronic]

I am helping a friend improve their Windows support for a media player which they're writing. One of the features we've been discussing is media casting support, so that one can play their media remotely on a variety of devices. The Windows.Media.Casting API allows just that, with support for a multitude of protocols as well.

However, the primary interface for representing media that will be casted is the CastingSource class. An instance of CastingSource can only be obtained by calling the GetAsCastingSource method which exists on a handful of types such as MediaPlayer and Image. However, for a number of reasons, going through this interface is undesirable for us:

• We would need to completely rewrite our media stack to use Windows.Media.Playback.MediaPlayer. It's not a bad API or anything — it would just be less work for us if there was a way to plug CastingSource directly into raw Media Foundation objects, which we already use for Windows support.
• Support for Windows 8.1 and Windows 7 would be very nice to have, meaning that we would need to also maintain a second media backend that does not use WinRT types that are inaccessible from desktop apps (or, in the case of Windows 7, don't exist).

I was looking through the Windows SDK and noticed the CastingInterop.idl file. It seems to define something that would perhaps theoretically work, but it would be nice if there was more information about these APIs than the somewhat brief comments found in it:

• The comments claim that ICastingSourceInfo "must be implemented by all CastingSource objects," and is responsible for giving the Casting API the interfaces it needs to actually do anything. Presumably, since I'm trying to create my own casting source that isn't based on MediaPlayer or Image, I'd need to somehow implement this interface. However, I can't just write my own implementation of CastingSource to hand to the API, so this doesn't seem open to extensibility by third parties in practice.
• The comments further claim that ICastingController is responsible for actually 'connecting' the media source and the device which is being casted to. Windows.Media.Casting is supposedly protocol agnostic, and that seems to be reflected in the fact that the actual casting engine that you get is an opaque IUnknown. The comment lists IMediaRenderer as a possible example of an interface you could query for... is there a more comprehensive list of types that one would need to support, e.g. for Bluetooth or Miracast?

In hindsight, it doesn't seem like these APIs actually afford me that much functionality — if I choose to go down this custom route, all I really get is a fancy device picker and a unified WinRT API for connection management (creating, closing, handling errors, etc.). Am I looking in the right place? How does this functionality relate to the APIs in mfsharingengine.h? Maybe there is room for some new APIs to be introduced?

I hope someone from the media team can help clarify what I can do to implement this scenario. I've been racking my brains on some of the APIs I've mentioned, and I think I might know what's going on, but some more clarity and documentation would help. Thanks.

[andrewleader]

Hi @reflectronic, since this is a Windows UWP question and not a question about Project Reunion, please ask your question on Microsoft Q&A here: https://docs.microsoft.com/en-us/answers/topics/windows-uwp.html

There's a set of dedicated engineers to help you there 😊

Thanks!