I can take a peek at the video playback; I've got a Windows 10 Tech Preview install handy.

With the experimental ogv.js JavaScript shim in playback seems fine on my test pages (eg <http://ogvjs-testing.wmflabs.org>) but we haven't deployed that to production yet as it needs a few more bug fixes.

I'll test with the WebM IE plugin; that ought to "just work" on both IE 9/10/11 and the tech preview... but it sounds like we've got poor behavior when the plugin's not installed, where it *should* be prompting to install the plugin currently rather than giving a raw download.

-- brion

On Wed, Nov 12, 2014 at 4:18 PM, Roan Kattouw <rkattouw@wikimedia.org> wrote:

Actually copying in the multimedia mailing list correctly this time.

Note: this mailing list is open to the public, and any emails you send
to it will be publicly archived forever at
https://lists.wikimedia.org/pipermail/multimedia . This is standard
fare for Wikimedians, but the Microsoft people on this thread may not
be used to this.

On Wed, Nov 12, 2014 at 7:13 PM, Roan Kattouw <rkattouw@wikimedia.org> wrote:
> Copying in:
> * Multimedia team because this concerns video playback
> * Oliver because he maintains ua-parser
> * Erik Z because he maintains browser statistics
> * Timo because he cares about browsers and relationships with the browser
> communities
>
> On Wed, Nov 12, 2014 at 6:42 PM, Rob Macias (Axelerate)
> <v-romac@microsoft.com> wrote:
>>
>> Hello All,
>>
>>
>>
>> As you may have heard, we rolled out a new Windows 10 preview build with
>> significant IE interoperability updates and wanted to make sure our
>> Wikipedia partners are in the loop. A major part of this update is the
>> “Edge” mode platform, which seems to affect how IE is being detected – this
>> is leading to Video playback errors when visiting the wikimedia.org domain.
>> More info on ‘living on the edge’ exists here
>> http://blogs.msdn.com/b/ie/archive/2014/11/11/living-on-the-edge-our-next-step-in-interoperability.aspx
>>
>>
>>
>> To our Wikipedia folks:
>>
>> Mind taking a look at this? Bug detail has been pasted below including
>> steps to reproduce and developer notes. If you aren’t already a member of
>> the Windows Insider Program, we recommend doing so OR you can download
>> RemoteIE, which provides another option for testing your site in the latest
>> version of IE.
>>
>>
>
>
> I'm not aware of us being a member. Timo, could you look into whether we
> are, and whether we should be?
>
> RemoteIE looks really useful. It doesn't seem to be available for Ubuntu
> though? Our engineering staff is split roughly 50/50 between Mac OS and
> Ubuntu / other Linux flavors, so if RemoteIE is only available for Windows
> and Mac OS on desktop, then it's only useful for about half our staff. But
> that's still a heck of a lot better than passing a Windows laptop around the
> office :)
>
>>
>> (Bug Specs)
>>
>> Reference #: 741977
>>
>> Description of the Problem: commons.wikimedia.org: Video is not being
>> played
>>
>> Steps to Reproduce:
>>
>> 1. Navigate to URL: http://commons.wikimedia.org/wiki/Main_Page.
>>
>> 2. Scroll down to video window
>>
>> 3. Invoke Play button to play video/ audio on the page.
>>
>>
>>
>> Actual Result:
>>
>> Video is not being played only black screen is displayed and instead of
>> playing video, it is asking  to save the file.
>>
>>
>>
>> Expected Result:
>>
>> Video should load and play properly.
>>
>>
>
>
> Multimedia team, could you guys look into this?
>
>>
>> Developer Notes:
>>
>> With the introduction of the Edge mode platform, the site needs to account
>> for the latest UA string changes. See below:
>>
>>
>>
>> Mozilla/5.0 (Windows NT 6.4; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
>> Chrome/36.0.1985.143 Safari/537.36 Edge/12.0
>>
>>
>>
>> These changes help prevent IE from being (incorrectly) identified as an
>> earlier version.
>>
>>
>
>
> Thanks for letting us know that the UA string changed.
>
> Timo, Oliver and Erik Z: you guys should know about this UA string change.
> It'll affect jquery.client, ua-parser, our browser stats, and probably other
> bits of code here and there that will presumably identify this UA as Chrome
> 36 rather than IE 12.
>
>>
>> Please let me know if you have an estimated timeframe to address this
>> issue, and if our team can further assist in this process.
>>
>>
>
>
> Most likely, someone on the multimedia team will file a ticket for this in
> our public bug tracker, which you can subscribe to.
>
> Roan

_______________________________________________
Multimedia mailing list
Multimedia@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia