A parser function that sets a page prop with the target time should be fairly easy to create on the backend, with prettier UX for setting it via GUI something to consider as an alternative or future addition.
There's interest in this again due to T92457 -- PageImages sometimes selects a video that's listed prominently, and it'd be easy for everyone if the default thumbnail could be set nicely.
Ok, so looks like two possible routes here (which may work together nicely, as well):
Editors can use the thumbtime parameter to set the thumbnail to load from a particular timestamp: https://www.mediawiki.org/wiki/Extension:TimedMediaHandler#Syntax_synopsis
Is there a problem preventing using still images from videos, specifically, or is there another reason y'all are trying to blacklist videos? And is it just videos or anything with extra parameters? Does this affect PDF, TIFF, and DjVu files with multiple pages, for instance, or SVG files rendered with a particular language?
Tue, Apr 24
This went out a while ago, can confirm it's running. \o/
Ah right, forgot about that mode of the script! I'll test it and adjust when my VM's back up and running later today...
Mon, Apr 23
Can you provide a sample command line that would work if they were right? If I just use say phpunit TestWebMHandler.php it complains about being unable to find MediaWikiMediaTestCase parent class, and I have no idea how it would find the MediaWiki configuration, so it would never be able to find the detailed cases....?
I'm a bit confused about this; there is no TimedMediaHandler.hooks.php, but there is a TimedMediaHandlerHooks.php.
Wed, Apr 4
If it still exists, as far as I know this is obsolete and unused?
Mar 27 2018
Mar 25 2018
Mar 22 2018
Not sure offhand about the schema; Yahoo's old documentation seems to have vanished from the net. (Probably on the wayback machine but I can't find a URL reference)
Mar 21 2018
Mar 13 2018
*nod* If there's general agreement not to add more specific hardware yet, we can just work with the reassigned image servers for now and add later if needed, and cancel on purchasing more for now.
Mar 9 2018
Is the test site configured with tidy or with the tidy replacement?
Per upstream's recommendation, instead going with a local polyfill of TextDecoder, which gets the (updated) stock code working without modification. Patch above, seems to work. :D
Mar 8 2018
I submitted a patch upstream with the node.js fast path: https://github.com/mrdoob/three.js/pull/13541
Submitted upstream at https://github.com/mrdoob/three.js/issues/13540
I don't think it's the mesh, but the format parsing... It's an ASCII STL file, not a binary one, so it's going through the slower ASCII-parsing path.
The file https://commons.wikimedia.org/wiki/File:High_quality_skull.stl is correctly displayed with the application MeshLab (or with "Mixed Reality Viewer") when downloaded but in the wikimedia preview it is just black.
Mar 7 2018
Mar 6 2018
Mar 5 2018
Once the Thumbor machines get updated from Debian Jessie to Stretch (T170817), it should resolve the underlying issue. Glad the workaround djvu file is working for now. :)
Yes, the R430 with 20/40 cores/threads and 64GB ram, roughly matching the existing ones from the old image scalers pool.
Yep. I forgot there even was a CLI installer. :)
Mar 2 2018
In a pinch, could generate the file at a larger size and let thumbor scale it down. Should be doable in the 3D plug-in for thumbor; have it double the input width and height and 8 think it'll just work.
Mar 1 2018
Will do. :)
Provisional patch to 3d2png doesn't render successfully yet, but does load the scene data. ;)
Feb 28 2018
Did a quick peek at the GLTFLoader for three.js. Couple things would need to be changed upstream to work in Node for 3d2png:
Per T188197, TechCom thinks a blocker RFC is not needed; if interest in implementing, needs product owner & momentum to move forward.
We had a quick discussion on this in TechCom planning meeting today; we don't think an RFC is necessary in terms of making major architectural changes to how user accounts work -- this is primarily requesting a method for user accounts that have both opted in to shared control to share data with each other, which sounds feasible within the current User class & framework.
Fixed stray 'endswidth' typo
@Peteforsyth I tried converting the PDF to DJVU with the aptly-named pdf2djvu. Give this a whirl: https://brionv.com/misc/Report_of_the_Park_Board_1903.djvu
Yep, master. Note that it may not happen if you accept the default database name of "my_wiki".
@RobH we'd still like to buy 2 new machines with this configuration, so if/when the ones taken from the image scaler pool are needed elsewhere we've got still enough increased capacity to cover ongoing uploads with the increased CPU requirements for VP9 encoding.
Feb 26 2018
Feb 24 2018
Rough plan is to get two new r430s with roughly the same config as the old image scalers, and also repurpose as many of the old ones as are available.
There has been a suggestion to recycle some of these as video scalers (T188075) if they're not needed elsewhere. Will have a sustained need for cpu capacity for a while to transition from VP8 to VP9 video transcodes, saving bandwidth and storage space.
(I like the idea of letting you bundle multiple files together and do the transform in the UI, I just expect it to be tricky to integrate into UploadWizard. Will be faster to get going if we leave that to external tooling.)
Nice, that should simplify things if we only accept binary .glb. :) As far as I can tell from spec a binary file can still reference external resources if it wants, but the validation step could detect that easily and return an explanatory error message.
Feb 23 2018
Here's what I get on a Debian jessie vm:
One thing I notice is that the images in this file are all stored as JPEG 2000 (which is what openjpeg decompresses), while various other files I see working use various other PDF-specific compression formats.
Works locally for me within PdfHandler as well (on Mac), though I think we now run the PDF thumbs through Thumbor rather than directly through MediaWiki+PdfHandler in production?
(And would all 6 be available for video scaler use -- I'll happily take them! -- or would we share with a bigger pool?)
Is that dual-socket for 20 cores/40 threads or quad-socket for 40 cores/80 threads? Hyperthreading makes everything confusing. ;) Either way those should work very well as video scalers.
@MoritzMuehlenhoff Great! What are the specs on those, for reference?
Is fine on stretch, which is now current.
VP9 adoption is pretty good these days, and ogv.js includes shim support for Safari, IE, and Edge that's only slightly slower than its VP8 playback and can be optimized a bit further. Should be safe to switch these in soon.
General capacity note: current version of libvpx can use a varying number of threads for VP9 encoding depending on the resolution. At our current resolutions, this means we can peg up to 14 cores simultaneously when processing a single HD input file: