Thu, Mar 19
Grabbing a couple high-prio TMH issues to work on the next week or two. Looks like a bug in the surrounding JS that assumes some things are marked up in one way but they aren't for Score stuff.
Sat, Mar 7
Confirmed working on a fresh install, thanks all!
Thu, Mar 5
T206957 is the related ticket.
Wed, Mar 4
I think principle of least surprise leads us to want a job queue that is processed automatically without manual intervention, as it's meant to be a continuously-operating part of the MediaWiki service that code can rely on being in working condition.
Feb 25 2020
The alternative would be to replace the player 'inline', but then we'd have to jump through hoops to get subtitles for audio again.
Feb 17 2020
Feb 10 2020
From caniuse it looks like IE and old Edge are the holdouts (new Chromium based edge supports it, as well as reasonably current versions of other browsers)
Neat! We should probably confirm the behavior is consistent, predictable, and either falls back cleanly or can be emulated sanely (eg in IE 11 if it doesn't support it). Also double check that neither tag is used as an extension. Then I probably have no further objection. :)
Feb 9 2020
I think I wrote this yes... we'd consider this as GPLv2-or-later as part of MediaWiki. It wasn't originally labeled in detail as it was a one-off production hack that ended up being kept around, and we weren't as careful with explicit labeling on extensions back then.
Feb 7 2020
Patch for thumbor is in the works, needs to finish adding test cases which I'll try to do this weekend so it's ready to go out when ready.
Feb 4 2020
Feb 1 2020
From the IRC log, a couple of the transaction IDs that returned 500 errors with odd messages about Swift being missing or disabled:
Roughly planning to soft-launch this and try replacing some of the manual .ogv conversions of old mpeg1 and 2 files from scientific papers with the originals. I'll track that on a separate task once the release train brings it live.
@Aklapper it is an svg file being rendered to png, so I think that should stay unless we can confirm that rendering succeeded and the error was at a later stage of serving.
Ah fun, intermittent problems. :) Should be findable in logs ...
https://upload.wikimedia.org/wikipedia/commons/thumb/a/a2/X_mark.svg/526px-X_mark.svg.png is rendering ok for me at present. What error message is displayed for you?
Jan 31 2020
Seem to have worked around the deprecation issue by simply not shutting down the lock manager or file group, but will test more thoroughly to see if that breaks anything later...
Looks like a little bitrot has hit this patch, with the deprecation of resetServiceForTesting outside unit tests the closing of services ends up failing.
Jan 28 2020
Can you check with this page? https://brionv.com/misc/vidtest/
Jan 26 2020
This is much better than my originally suggested hack. :) +2'ing it.
Still think this'd be a great base for us to work on, should there be time and energy to spend on it.
Jan 25 2020
Hmm, https://commons.wikimedia.org/wiki/File:Wikipedia_-_Edit_2019.webm?embedplayer=yes is currently working for me in IE 11 (though with low performance) and should be working in Safari as well (with much better performance). Can you confirm whether the URL works independently of the iframe, or whether it only fails in the iframe?
Jan 17 2020
I suspect it's the file size limit yes -- ffmpeg seems to be exiting with SIGXFSZ (signal 25, exit code 153) which means 'exceeded file size'. This is probably not the file system limit, but the resource limit applied to the transcode process? However transcodes going over 4 GB may have trouble being stored anyway. :(
Seems to have been resolved in the meantime, probably by using updated ffmpeg on servers.
Guess this didn't seem that important, closing out.
All this ran, and later a bunch re-ran, some time ago. Closing out.
We chose to reimplement with oojs ui and have implemented.
New click-to-load mode behaves more like the old mode, and seems ok here. Closing out.
This seems to be largely dealt with the new load-on-click mode, I'm going to close it out.
Jan 16 2020
Probably a side-effect of how the subtitle pages are specially rendered...
This seems to be due to a corruption problem in Photoshop or some other editing tool that produces a huge amount of extra junk data in the XMP metadata. You can find reports of this problem on forums like here: https://feedback.photoshop.com/photoshop_family/topics/corrupt-ancestors-tag-in-xmp-causing-giant-file-sizes-in-photoshop
Jan 15 2020
The fields are currently defined in tables.sql as int unsigned which is a 32-bit type with a range from 0 to 2^32 - 1 (one byte shy of 4 GiB). To record sizes of files of 4 GiB or higher, redefining them as bigint unsigned, a 64-bit type, would be required.
Jan 14 2020
Latest rev of https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TimedMediaHandler/+/553442 includes a quick-fix for that: an inline transform property is added which adds the playsinline attribute and a mw-tmh-inline class which has the on-load transforms set up video.js for that player instead of turning it into a popup player trigger. This is then forced on for the embedded-iframe view.
(Well, not exactly broken, but ... kind of weird. ;) It forces the popup to run inside the iframe, which adds a title bar even at small sizes.)
Acknowledged, ?embedplayer=yes mode is indeed broken with those changes. ;_; I'll fix that shortly.
Jan 13 2020
Native CPU-run VP9 seems pretty ok through 720p on my lower-spec machines, but YMMV. :) AV1 is much more CPU-intensive and I definitely don't recommend switching to it wholesale yet, especially at high resolutions.
Jan 6 2020
Definitely saw it on https, on phab. The ipv6 timeout behavior makes it hard to see reliably so not sure if it was hitting other sites consistently but the packet loss on ping to load balancer was suspicious.
Dec 20 2019
Dec 19 2019
Thanks all! I'll try the email queue next time something crops up for future reference. :)
Dec 17 2019
Could remove it yeah Special:MediaStatistics does that top section better. Maybe stick in a link for good measure as a related info? I think Special:TimedMediaHandler should concentrate on the transcode status info (and maybe get renamed to match).
Dec 11 2019
sudo mtr -z -s 1000 -T -P 443 phabricator.wikimedia.org gives similar results:
Dec 10 2019
Looking... it looks like on success transcode_error is cleared but transcode_time_error is not. However it shouldn't be getting set in the first place unless something's awry...
Dec 5 2019
Ok, I'll run:
Ideally: fix the installs ASAP :) If can't be done: disable $wgFFmpegVP9RowMT and that should hopefully work if it reverted to a version that groks vp9 but doesn't know the -row-mt option.
Nov 27 2019
Updated https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TimedMediaHandler/+/529819/ to use the better minified package. Much smaller JS payload now. :)
Ah, OSs shipping old stuff is always fun. :D No real danger to it, and it's clear enough in the code if we refactor and clean it out later. :)
@TheDJ let's try using it without wgMinimumVideoPlayerSize and drop it back in if we decide the always-transformation is confusing.
Nov 26 2019
I'm a bit reluctant to add explicit support for obsolete versions of ffmpeg, since it'll never get tested and other things that break it are likely to be added. Is there a reason you're running an out of date ffmpeg?
@AlexisJazz sorry about any frustration from the on-Commons discussion in January. It took some discussion of our own on Phabricator to decide what to do, both about the incorrect HTML security trigger and about the more general removal of obsolete checks, and communication wasn't and still isn't very consistent. Sometimes you get advice on-wiki that's based on the current general state of things, but the state of things changes -- we have indeed decided that the IE 6/7 content-type-sniffing vulnerability is no longer a serious security consideration, but in January we hadn't decided that yet so you were given advice based on the current state of the world.
Nov 15 2019
This is a compat problem with the old player; the new player mode is getting an update and should get merged soonish, and it's fully functional on mobile.
Nov 7 2019
Note that a Promise polyfill can be loaded at the cost of a few kb of compat code, but there's so many other reasons to want to deprecate IE 11 and to move to newer JS versions and most of the other things can't be polyfilled so easily.
Oct 21 2019
I have some more diagnostic info on T235934 for what appears to be the same problem (installing mobilefrontend). Workaround is to manually clone extensions/MobileFrontend and re-run vagrant provision.
Oct 18 2019
Yeah, looks like it's dying in the same place over on that one.
Oct 17 2019
Oct 15 2019
Oct 10 2019
Sounds like some of that sequence resulted in a conflict that didn't get handled well at the time. Following the error message back to the code symptom, the case is this in LocalFileRestoreBatch.php:
Oct 2 2019
Sep 26 2019
I've updated the documentation at https://www.mediawiki.org/wiki/MediaWiki-Vagrant to link to this bug report and mention that you can manually log in with vagrant ssh and run mwscript maintenance/changePassword.php --user=Admin --password=vagrant to set the initial password.
Sep 24 2019
Haven't encountered this in a while; Comcast etc may have improved the intermediate routes. Closing out as resolved.
Sep 19 2019
Looks like the audio wasn't getting initialized at the right time (how did it work on iOS? no clue!) unless mwEmbedSupport has already been loaded.
Sep 17 2019
Sep 11 2019
Looks like in PHP 7.2 the empty string gets interned to a special shared instance (zend_empty_string)... It's possible something's corrupting zend_empty_string, either its contents or its hash (h) field. If we can get a core dump it should be possible to inspect the symbol...
Aug 28 2019
Aug 21 2019
I'm still not sure I can reliably tell the difference but I trust you. :) Titles being sometimes late by random amounts up to 250ms seems like it would make sense given the poor latency guarantees on the timeupdate event, so I'm not sure there's much we can do directly here...
Aug 20 2019
Could this be latency from the timeupdate event? It can trigger with a wait as long as 250ms between events per spec.
Aug 14 2019
Note the parser cache key is not available to the hook. Fun!
I think default mode is checked because there's a separate pcache suffix for folks using the beta-mode -- this is targeted at clearing the non-beta-mode entries after a site-config switch.
The only POSTs I see in there are in setContainerAccess, addMissingHashMetadata, and doDescribeInternal, which all update existing files. Could be there's a hole in the logic of one of them that's dropping Content-Type, or that some files were missing it to begin with but it was being filled in on high-level fetches, or something, so they worked until something updated the data?
Hmm, I notice this in SwiftFileBackend.php:
Great, I'll tidy up this patch in a bit (once I get the subtitle lazy-loading patched back in) and we'll worry about lazy-loading later.
Since AFAIK extensions are meant to use wikipage.content for setup, I think any area where wikitext features are expected to work _should_ trigger the hook... A common class name would still require knowing when to run setup, and potentially one might want to update the indicator (what happens during edit preview?). So we either have to add a second hook that does the same thing as wikipage.content but is explicitly scoped to non-primary areas, or ...? Hmm, bears further thought.
For a video that triggers player setup but hasn't actually been played, in Chrome/Firefox where no ogv.js shim is needed, they seem to weigh in (as reported from mw.inspect, so uncompressed) at around 293 KiB for MwEmbed+jquery.ui and 288 KiB for video.js with the core.min.js variant.