(Hat-tip to Nemo for noticing this)
We're writing up and redefining the pageview definition. Amongst other
things, it uses MIME type filtering and folder-level filtering to exclude
Problem: the multimedia viewer false anchor (an example is
is both text/html (one of the recognised and appreciated MIME types) and
/wiki/ (one of the recognised and appreciated domains).
The result of this is that it's currently going to be counted as a
pageview, even though it's...well, not.
Is there any way you lot could avoid the false anchor strategy and pick a
URL scheme that won't trigger this? If not, we can just write an exception
- but I'd rather that we not have to do that every time anyone decides to
Hey folks :)
We'll be doing another office hour to answer all of the questions
about structured data for multimedia files. We'll try...
It'll happen on November 20th at 19:30 UTC in #wikimedia-office on
freenode. See http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&min=30&sec=0&d…
for your timezone.
Hope to see many of you there!
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
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(a)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
> On Wed, Nov 12, 2014 at 6:42 PM, Rob Macias (Axelerate)
> <v-romac(a)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
>> 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
>> 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.
I've gotten some great review feedback from Gilles on the desktop-web
Theora/Vorbis media files -- thanks Gilles!
* libraries: https://gerrit.wikimedia.org/r/#/c/165477/
* desktop integration: https://gerrit.wikimedia.org/r/#/c/165478/
These are getting pretty close to ready to land, I think.
I would love to get some review on the mobile overlay I've whipped up as
well. This supports both native WebM playback (Android Chrome, Android
Firefox, Firefox OS) and ogv.js playback (iOS 7/8 Safari).
* mobile overlay: https://gerrit.wikimedia.org/r/#/c/165479/
* Live demo: https://ogvjs-testing.wmflabs.org/
A few open questions:
1) Is this the right way to do mobile overlay code? (It's basically a rip
of the existing photo viewer overlay in MobileFrontend, but lives in
TimedMediaHandler.) Is the overlay interface stable enough for other
extensions to use it for mobile-specific features? (I had to make updates
for object-model and template things that changed since this summer.)
2) Is the inline icon too huge/ugly here for audio files? Should it be
arranged differently, or display the player inline instead of as an overlay
3) Should more controls be added to the overlay's bottom toolbar, such as
manual resolution selection or an 'Open in VLC' link to support HD playback
4) Should we autoplay when opening the overlay, or require a second tap?
5) How should we handle devices with no native playback that are either too
slow (iOS 6 Safari) or lack necessary features needed for the player
Current known bugs in the mobile overlay:
* CPU speed check not yet integrated to force to lowest resolution for old
iPhones/iPads (this exists on the desktop integration, just needs to be
moved to common code)
* autoplay doesn't seem to work with native playback right now