One possible solution is for Score to drop TMH support. Instead we can just play an MP3 directly with <audio controls>.

Change 628246 had a related patch set uploaded (by Tim Starling; owner: Tim Starling):
[mediawiki/extensions/Score@master] Drop TimedMediaHandler support

https://gerrit.wikimedia.org/r/628246

Yeah, I'm not very happy with our current audio playback solution; we've sacrificed the functionality in the name of general reader performance, but I think we should provide better, in time.

Change 628246 merged by jenkins-bot:
[mediawiki/extensions/Score@master] Drop TimedMediaHandler support

https://gerrit.wikimedia.org/r/628246

There is no open patch for improvement.

^ No basic (Grade C) browser left, that doesn't support HTML5.

@Jdforrester-WMF: There is, see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TimedMediaHandler/+/523987

In T100106#7113602, @Aklapper wrote:

@Jdforrester-WMF: There is, see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TimedMediaHandler/+/523987

No. That is a follow-up patch deleting the old code once this task is done.

This task is stalled waiting on defining what the launch criteria are.

(@Jdforrester-WMF: It's an open patch by definition and it says "Merge Conflict". My criteria is as simple as that (just FYI).)

In T100106#7113641, @Jdforrester-WMF wrote:

This task is stalled waiting on defining what the launch criteria are.

Any progress? Who is responsible? Whom should I contact? What are the known blockers of the roll out are?

Currently there's no responsible team; most ongoing video work is done out of band by me personally (very intermittently) with code review mostly from JamesF.

I would like to get this done soon too -- primarily we'll need a tighter communication cycle for the development -> review -> deployment -> bugfix development loop. At a minimum, we'd want weekly time commitments from me (as primary dev), JamesF or someone/someones else (for code review), and someone to run the deployments of updates and config changes, with availability to monitor for changes and help with reverts if necessary.

If it's important enough for performance reasons I think we can pretty much just switch it over very soon without a lot of changes, then kill the old code (freeing up a lot of room in the resource definitions!), and fix up the remaining bugs -- but we have to have confidence we'll be able to maintain a bug fix cycle for at least a couple months to do that work and monitor ongoing issues.

Currently I'm fairly confident I can maintain that level of productivity focus on this work *if* and only if the support structure is there for review and deployment.

Some things that should get fixed, but can wait in a pinch:

• cleanup of displayed text/fonts/icons/layout
• UI tweaks to the pop-up dialog with the larger player
• re-introducing a functional link to the subtitle creation system (which is pretty bad, and really should be replaced with a green-field UI specific to editing subtitles)
• if necessary, longer-term storage for converted subtitles (currently subtitles are stored on-wiki in SRT format but video.js and supporting native browser support uses WebVTT, so there's a conversion step built-in)
• support for manual clean-up work of existing subtitle pages that don't convert properly or are otherwise formatted wrong (can be a community thing, but we should provide some tools to help like listing all files that don't cleanly convert)

the support structure is there for review and deployment.

I can provide some time in review and deployment alongside James, if there are more detailed bugs. I can also help on development too.

In T100106#7353044, @Ladsgroup wrote:

the support structure is there for review and deployment.

I can provide some time in review and deployment alongside James, if there are more detailed bugs. I can also help on development too.

Awesome. :) I'll keep plugging away at cleanup patches for now, and we can coordinate on additional work. (What's folks preferred real-time chat these days for when that's needed?)

I'm online in IRC (Amir1) but if you don't like it, I'm fine with basically any sort of messaging system, Twitter, Facebook, I'm even in WMF slack (as a guest), you can directly message me there.

See T293136, it looks like Iframe embed support blocker should be unticked as it looks broken currently.

Thx for the merges today @brion

A substantially better UX would be provided if media were played inline instead opening a small popup that covers the text of the article. (example)

This was one of the most hated characteristics of the old player and a major drawback of the Wikipedia media experience compared with all other modern websites that play media right on the spot.
It would be great if the new player offers this option by default.

Is this actually being considered?

@Serg1o: See T229169 instead (as this task's scope is about the replacement itself only). Thanks.

In T100106#7727560, @Aklapper wrote:

@Serg1o: See T229169 instead (as this task's scope is about the replacement itself only). Thanks.

That task has nothing to do with playing video in place, or with video at all. There's T246035 that's slightly related but it's only about VideoJS's regression on audio playback compared to Kultura, whereas what Serg1o is asking about concerns media playback in general and is not currently achieved even with Kultura (not with |thumb at least).

We are not against improving UX of audio playback and more precisely addressing T246035: Videojs player for audio opens a dialog to support subtitles, which is unexpected. I also think after the deployment, we can work on more improvements such as in situ player but the big problem is that now we have two competing codebases that both need maintenance and specially the old code has a lot of issues. Making such changes once we have only one player would be much easier and faster. What I am suggesting is to have that ticket as the first thing to fix after full deployment of videojs everywhere (and clean up of the old code). It doesn't have to be necessary making it inline (given that videojs doesn't seem to support subtitles in inline mode as far as I searched) but for example making it inline when there is no subtitle, or playing with in situ playback and seeing if it works and how much work it would be. But doing that atm with the current mess the codebase is in (because of having to support two players at the same time) is not easy. If you feel like it, try seeing if it's possible to write gadget for it for users who want to keep it inline for now.

Does that sound good to you @Nardog?

@Ladsgroup I appreciate your suggestion and it sounds like a step in the right direction. One big quibble, however, is that it suggests there will be a period, however short it may be, where audio can only be played in the popup. That to me is unacceptable and there will be a ton of pushback. Just provide an alternative, be it Kultura or the browser's native player (with the caveat that they won't get subtitles), concurrently with, not after, the rollout. VideoJS did offer in-place audio playback, and it was removed to support subtitles. I imagine undoing that (just for audio without subtitles and/or while making the popup a button action) wouldn't be very difficult.

(I'm also not clear on what you mean by "inline" and "in situ playback" and how they'd differ. AFAIK there is no such thing as "inline mode" in VideoJS, period, and what T229169 is asking is a feature that shouldn't involve VideoJS.)

In T100106#7731504, @Nardog wrote:

and what T229169 is asking is a feature that shouldn't involve VideoJS

No that definitely would still involve videoJS.

In T100106#7731504, @Nardog wrote:

@Ladsgroup I appreciate your suggestion and it sounds like a step in the right direction. One big quibble, however, is that it suggests there will be a period, however short it may be, where audio can only be played in the popup. That to me is unacceptable and there will be a ton of pushback. Just provide an alternative, be it Kultura or the browser's native player (with the caveat that they won't get subtitles), concurrently with, not after, the rollout. VideoJS did offer in-place audio playback, and it was removed to support subtitles.

It can be a simple gadget to disable TMH or make it inline and this doesn't need to come from us.

(I'm also not clear on what you mean by "inline" and "in situ playback" and how they'd differ.

inline doesn't show the subtitles while "in situ" would be similar to the current while not showing it a modal.

AFAIK there is no such thing as "inline mode" in VideoJS, period,

That's not correct: https://www.nlm.nih.gov/web/documentation/TemplateDocumentation/videojs_audio_only.html

It can be a simple gadget to disable TMH or make it inline and this doesn't need to come from us.

It does as long as T22153: Implement global gadgets (WMF-wide) is open. The problem isn't wiki-dependent so neither should the solution. Please acknowledge that, if you rolled it out as it currently is, you would be making the UX far worse for everyone reading any wiki page with audio on it and how bad a look it would be to impose it on the communities and ask them to fix it.

(I'm also not clear on what you mean by "inline" and "in situ playback" and how they'd differ.

inline doesn't show the subtitles while "in situ" would be similar to the current while not showing it a modal.

AFAIK there is no such thing as "inline mode" in VideoJS, period,

That's not correct: https://www.nlm.nih.gov/web/documentation/TemplateDocumentation/videojs_audio_only.html

Oh, so the distinction you're making is whether to show the placeholder above the player control for audio? I just assumed not showing the modal entailed not showing the placeholder also. I mean, imagine how stupid it'd look if an audio player grew vertically just to show a placeholder with nothing on it, or if a modal was shown with nothing but a single horizontal bar. It would, however, make some sense if the player grew vertically only when there are subtitles, which would in fact be close to the status quo with Kultura. That does seem like a sensible choice at least in the short term.

In T100106#7739816, @Nardog wrote:

It can be a simple gadget to disable TMH or make it inline and this doesn't need to come from us.

It does as long as T22153: Implement global gadgets (WMF-wide) is open.

You can simply put the js code in your global.js in meta. That's not really a blocker.

Please acknowledge that, if you rolled it out as it currently is, you would be making the UX far worse for everyone reading any wiki page with audio on it and how bad a look it would be to impose it on the communities and ask them to fix it.

Not everyone plays the audio in every page that has audio in them.

I acknowledge it's suboptimal in some cases but I also acknowledge that deploying videojs would fix countless bugs and UX issues as well. It's a win-some, lose-some situation and no new software is without bugs. Even with new mailman that was a very obvious improvement, we had several bugs and issues being introduced that we tackled after deployment. And again, I emphasize that fixing bugs and issues are much easier when you have less code and less complexity of having two competing frameworks (and more time by not needing to maintain two codebases)

If you really passionate about this particular problem. The code is open source, please make a patch and we would make sure to review it. Keep it in mind, everyone working on the deployment of this are doing it in their volunteer capacity (or are volunteers) so we have the same limitations as you do.

In T100106#7739872, @Ladsgroup wrote:

In T100106#7739816, @Nardog wrote:

Please acknowledge that, if you rolled it out as it currently is, you would be making the UX far worse for everyone reading any wiki page with audio on it and how bad a look it would be to impose it on the communities and ask them to fix it.

Not everyone plays the audio in every page that has audio in them.

I acknowledge it's suboptimal in some cases but I also acknowledge that deploying videojs would fix countless bugs and UX issues as well. It's a win-some, lose-some situation and no new software is without bugs. […]

Let me emphasize from User-Experience Engineering role perspective, it's a win-many, lose-some situation.

Then can we remove the Kultura code but hold off on deploying it, fix T246035 and then deploy it? Again, the beta feature did use to play audio in place. It's just showing the modal for all audio that's a flaky, bizarro decision that makes little sense. I agree everything else about this is awesome.

Showing audio in a popup that covers the text presents a lot of problems:
A usual expectation for an audio clip that is placed in a Wikipedia article is reading the article at the same time that you listen to the clip. A few normal scenarios are, as examples, reading the lyrics and interpretation of a traditional folkloric song, reading the lines and translations of a national anthem, or reading the musical description of a pop song or of a classical melody. A lot of the usefulness of having a media player is removed if you have the audio playing separated and covering the text, even some users might aprefer to have a link that can be opened in a new tab so they can listen and read simultaneously.

The new media player is neat and a lot of awesome work have been done to adapt it to mediawiki such as adding subtitles and correct many bugs, but deploying it with a regression compared with the old player could cause a negative reaction to some people.

I think there might be a way to show in-situ audio (including subtitles) so T246035 should be consider a blocker, as well as any other issue of the new player that breaks the page (such as ignoring the existing width parameter).
The question is:
Why is not possible to load the player in-situ (instead of in a modal) when the reader clicks it?

In T100106#7741252, @Serg1o wrote:

I think there might be a way to show in-situ audio (including subtitles) so T246035 should be consider a blocker, as well as any other issue of the new player that breaks the page (such as ignoring the existing width parameter).
The question is:
Why is not possible to load the player in-situ (instead of in a modal) when the reader clicks it?

Everything is possible in software, the only question is: "how costly is it" and is that realistic. Here it is my free time as a volunteer having to support and maintain multiple modes, without impacting the performance metrics of wikimedia pages too much. I actually have plans for some level of inline playback (primarily for 3rd party users who do not care about Wikimedia's performance metrics) but as stated before, it would be better to get this out the door first, it simplifies everything a lot.

Hi @ppelberg - fyi the iOS team did an entire experiment on surfacing recent changes on article more prominently to users, which may offer additional ideas for this task: T241253: Experiment: Article as a living document

If a video has subtitles, there will be the letters "CC" in the upper right corner. "CC" is a widespread abbreviation of "Creative Commons". This creates the impression, the file was licensed with a mystirous (non-existing) licence "creative commons". Many reused files from commons.wikimedia on external websites show a licence information of "creative commons" when the real licence is cc-zero, or cc-by-sa-1.0, or cc-by-sa-2.0, or cc-by-sa-2.5, or cc-by-sa-3.0, or cc-by-sa-4.0. With the video player showing the letters "CC", this may spread even more. Especially as the new player does not show the licence information after the video has ended playing and there is no button "display licence" and the button "(i)" shows the description page, that is often not read/understood by reusers (leading to using wrong attribution on external websites). The description page also does not show the metadata (apart from encoder info) that the video contains (unlike image files). While "CC" is probably known as meaning "Closed Captions" among Cinema Enthusiasts who prefer to watch video in its "OV" (original version,, often the arcane language of english, that is neither spoken nor understood by the vast majority of world population), and deaf people, "Closed Captions" is a term mostly unkown to lay people.

In T100106#7859555, @C.Suthorn wrote:

If a video has subtitles, there will be the letters "CC" in the upper right corner. "CC" is a widespread abbreviation of "Creative Commons". While "CC" is probably known as meaning "Closed Captions" among Cinema Enthusiasts who prefer to watch video in its "OV" (original version,, often the arcane language of english, that is neither spoken nor understood by the vast majority of world population), and deaf people, "Closed Captions" is a term mostly unkown to lay people.

A CC icon is literally on every YouTube video in every language. Actually, there was a CC icon on the controlbar of the old video player as well. While I don’t like the Americanism either, I’d doubt it will create much additional confusion. One improvement could be to have the designers create a proper CC icon with screen lines around them.

In terms of licensing, I’ll say that I don’t see many differences between a image linking to the description page and a video linking to the description page. Can it be improved ? Sure, and I have some ideas for an endscreen eventually.

While I contest that "CC" and "closed captions" are "mostly unknown to lay people" (most people know what they mean from TV broadcast at least in North America), I concur its use as an icon is culturally specific and thus undesirable. It looks like VideoJS already shows a generic subtitles icon rather than "CC" if the interface language is set to anything other than American or Canadian English (YouTube does basically the same). But I don't even know if it should be showing "CC" at all, even if it's set to English.

(One consequence of this alternation of the terms "closed captions" and "subtitles" and icons representing them, and of cultural differences in general, is that people have different expectations about what SRT files should consist of. People seeing "CC" expect there to be descriptions of noise, music, who is speaking when their mouth is off screen, etc. (SDH) because that's the context in which they are most familiar with the concept, while those more familiar with watching foreign-language movies with subtitles expect just transcription or translation of the dialogue. This is something I've felt it should be able to clarify in the TimedText feature—like making it possible host multiple SRTs per language, e.g. one for just translation and another for SDH—but I digress.)

In T100106#7859611, @TheDJ wrote:

A CC icon is literally on every YouTube video in every language.

No :) Only some languages have CC badge.

If folks don't like the CC thingy, then please create a dedicated task to discuss the CC thingy.
This task is about replacing the Kaltura player specifically; it's not a catch-all for any potential issue with a new player software. Thanks for your understanding!

Thanks for your attention. We have T302150: Add 'Subtitle', 'Picture-in-Picture' and 'Restart' icons in Design Style Guide, Codex & OOUI and we can discuss there.

In T100106#7887074, @Iniquity wrote:

Thanks for your attention. We have T302150: Add 'Subtitle', 'Picture-in-Picture' and 'Restart' icons in Design Style Guide, Codex & OOUI and we can discuss there.

That too has is not specific enough. Please create separate tickets T307083: Use less American-specific indicator for subtitles on video placeholder

FYI, this is deployed everywhere now: T248418#7894836

Thank you for your dedication to getting this deployed @Ladsgroup.

I'll keep this ticket open a little bit longer, mostly as I want to make sure that I have created tickets for everything listed here as potential improvements.

Change 799002 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[translatewiki@master] Drop old video player i18n messages

https://gerrit.wikimedia.org/r/799002

Change 523987 merged by jenkins-bot:

[mediawiki/extensions/TimedMediaHandler@master] Remove KalturaPlayer code, no longer referenced

https://gerrit.wikimedia.org/r/523987

Change 799002 merged by jenkins-bot:

[translatewiki@master] Drop old video player i18n messages

https://gerrit.wikimedia.org/r/799002

Change 799169 had a related patch set uploaded (by Raimond Spekking; author: Raimond Spekking):

[translatewiki@master] [TimedMediaHandler] Drop New Mw Embed Support too

https://gerrit.wikimedia.org/r/799169

Change 799169 merged by jenkins-bot:

[translatewiki@master] [TimedMediaHandler] Drop New Mw Embed Support too

https://gerrit.wikimedia.org/r/799169