SMF Player over https anyone?

Oct 22, 2010 at 4:58 PM

Anyone have their player working over HTTPS...  I cannot get any URL to play over HTTPS...  Player is fine over HTTP but when I migrated to production it throws a com exception Error Number -532462766 when it tries to play the media.  I have to dig more on this error...   The type of media...  isml, ism or MMS doesn't seem to matter or play at all.  Any and all thoughts would be greatly appreciated.. even if it is to say that you have gotten your player working over a https connection as that way at least I know....


All the best;


Oct 22, 2010 at 10:11 PM

Hi Brendon, well, since "any and all thoughts are appreciated" I can chime in... 

We have a 100% Silverlight admin site at e.g. and wanted to play URL's outside of that (mms://,  http://...) but I could never make it work, so what I did instead was to change to, using HTTPS for all background WCF communications from Silverlight to our servers and informed our users clearly that all background communications are secure even though they cannot see the lock in the browser.

I guess smy small contribution is: "What is your use case? Do you really need HTTPS or can you design around it?" 

But I'm not sure if my use case is the same as yours or not...


Oct 22, 2010 at 11:34 PM

Thanks for your reply Kurt....  Unfortunately this case it not quite the same...  this MMS feed HAS to be over SSL.... kicker is media Player will pay the MMS feed fine but does not have the extra functionality that is required...  That is the active-x version of media player embedded in a HTML doc ....  There must be a way to make this work or a good reason why it won't work over SSL ...  I know I have tried quite a few things myself to no avail.  Nice workaround though by the way... Any other ideas anyone?  Meantime I have to try and find out what this error is exactly....  hopefully I can help someone else who has spent as much time and effort on this as I have....  deploying to production is quite a ways along in the process to have to throw it all away...ouch!!!!!  By the way... the other thread about this was dormant for months so no contribution is too small... ;-)  I am sure others will want or need this framework to work over SSL...

Thanks Again;


Oct 24, 2010 at 1:59 PM

any SMF admins, coders, etc. have anything to add to this...  Like post that it is possible or not... from the frameworks perspective I mean...  It would save so much if someone who is in the know would post if HTTPS (SSL) is even supported...   perhaps it can be a feature request or if it should work then we could issue a incident to have it looked at or something or indeed I could look at it myself with just some feedback on this post...  The silence is truly deafening from my seat... :-)





Oct 25, 2010 at 8:11 PM

Guess I can take it as a given that no one has their player working over HTTPS.  I am disappointed that some of the coders/site admins did not chime in on this issue...  I mean if there is a decrypt that needs to happen it can be fixed or worked around.  I searched for support on the SSME to get MS input and found nothing as well...  Others and I have posted on this site as far back as August 31 pertaining to HTTPS and as of yet there are no replies from the people who should have an idea about the players capabilities as they were the ones working on it.  Don't get me wrong, I appreciate the framework as it stands and I really appreciate the work these people have done, I implemented a whole host of features and it met my needs right up to the production deploy over HTTPS... :-(  I am not looking for someone to do my work as I have spent months getting all the capabilities we need but someone is in a much better place to even surmise what the trouble is with HTTPS.  The media fails immediately... MMS or ISML or ISM...  doesn't matter... I have conversed with at least two others who could not get this to work either and I think the topic seems to be taboo here right about now...  Seems like I am up the creek without a paddle on this one...  Guess I will have to break the bad news on how much time I have wasted chasing a ghost as I just do not have any more time to spend digging through all of this framework from scratch...  I truly did not think after all I did with this framework that this would be my Waterloo...  perhaps we should just say that others beware of any thoughts of HTTPS and SMF...  I will have to throw it all away without a thing to show...  drop that on your bosses lap and see what yah gets...



Oct 25, 2010 at 8:18 PM

You're running into an issue that is out of the realm of .NET. Silverlight does not allow calling image or video media across some scheme combinations. You're SL application needs to be hosted on an https url if you want to call an https media item.

Oct 25, 2010 at 8:25 PM

it is hosted on HTTPS URL...  The entire site is HTTPS...  I presume that is what you mean....

Oct 25, 2010 at 8:33 PM

hmm.. then I'm at a failure to help. I haven't dealt with trying to stream over https so far. I've dealt with mms and smooth streaming over http.


I've also been annoyed by something similar to this, I was trying to make an app where you can take a screenshot of the movie to may thumbnails. I was doing this for a major tv network for managing their online movie site and ended up having to go through the convoluted process of having a server do the capture since SL wouldn't allow access to the image pixels. MS sided waaaaay too far on the side of security and copyright when it comes to this

Oct 25, 2010 at 8:35 PM

Thanks darthobiwan by the way....  I have read the post and will dig more...  If this is a limitation of Silverlight then I am royally hosed aren't I...  I have very few options there I would imagine.  The media server is on the same box too...  I would never have guessed....  Can you tell me more on what you mean when you say You're SL application needs to be hosted on an https url if you want to call an https media item...  everything is on the same box and I would eat gravel now rather than go in and have to say I hit a brick wall and we are out of luck... time and money wasted....  I have it written, tested, verified (over http) and packaged but not deployed to our SSL environment...  I expected a few glitches but this is a nuke!!!!!!!!!!

I do apprecaite your help for sure and thanks again;


Oct 25, 2010 at 8:41 PM

yeah.. I meant to have both the media and sl app on https but if you already have that.. I dunno.

This might be something better asked on the SL forums or StackOverflow. Maybe even tweet directly to Tim Heuer or someone else on the SL team.


Oct 26, 2010 at 12:31 PM

Thanks Darthoiwan...  I think I have almost found my answer...  thanks for the kick in the pants too by the way....  I apologize for not finding this before I posted but I would never, ever, ever have imagined this would be deemed a security threat but here is the synopsis of what is good and what isn't in Silverlight....  I am still not sure if I am out of luck or not to be perfectly honest...  I have a MMS feed that is on the same box as the SSL web site....  Is this a cross-scheme violation?  I mean does anyone think that a crossdomain.xml file will help with this....  I have a wide open file to try and will post when I can get access to production again but I would like some feedback on this.  What does everyone think?  Is this a no go based on this table and URL from Microsoft.  Because it is MMS and on the same box I am not sure how this would play out...  anyone??????



WebClient and HTTP classes

Image class, MediaElement class for progressive downloads (media, images, ASX, etc.)

XAML source files

Font files

Streaming media

Allowed schemes






Cross-scheme access

Allowed between HTTP and HTTPS.

Not allowed

Not allowed


Not allowed from HTTPS

Cross-domain access

Requires a security policy file.


Allowed if not HTTPS to HTTPS

Not allowed

Allowed if not HTTPS to HTTPS.

Cross-zone access (on Windows)

Not allowed from an Internet zone to more restrictive zones.

Not allowed from an Internet zone to more restrictive zones, except if the target domain is localhost.

Not allowed from an Internet zone to more restrictive zones.

Not allowed from an Internet zone to more restrictive zones.

Not allowed from an Internet zone to more restrictive zones.

Redirection allowed

Allowed to same site and scheme.

Allowed cross-domain and cross-scheme only with a security policy file.

Allowed to same scheme and same or different sites.

Not allowed

Not allowed

Not allowed

When users get an error that results from one of these access policies being violated, the error may not indicate the exact cause.

Here is the URL...  This explicitly explains what these violations are...  my player is utilizing web services and such with no problem over HTTPS with the security policy file but I am not sure if it is worth fooling with if this breaks one of the rules above.  Any and all feedback welcome....

hope this helps someone and I can get some feedback on this...  I think I am out of luck here all the same.... :-( 



I posted on both those forums and no reply...

All the Best;


Oct 26, 2010 at 8:52 PM

Hi Brendon,

It seems you hit the same brick wall I hit 2 months ago, we even discussed it. Check out this page:

My conclusion back then was that Smooth Streaming over https works, Progressive Download over https works, but Streaming using Windows Media Services won't work since it cannot stream over https.

Note that we don't use the SMF framework, we build our own player, but the restrictions are the same.

I still think MS should find a solution for this, the scenario of hosting a SL app with streaming video over a https connection isn't that uncommon. Especially when all parts of the solution are on the same server and domain. So maybe Darth's suggestion to tweet Tim isn't a bad idea afterall :)


Oct 27, 2010 at 1:26 PM

Thanks for your reply Rik;

      I think you are bang on in what you say here.  It seems the more I read on this whole thing the less I seem to know about it.  There are interesting links which are a bit contradictory in some cases...  I really do need to get confirmation for the betterment of SMF and the other coders/users who require this type of scenario.  Thanks again for everyone's input.  I do not tweet but maybe I can get this put on their radar some other way... I am not giving up on an answer yet and I will let everyone know one way or another...

notice the section on Streaming and supported protocols in the above link...