Wed, Sep 20
Mon, Sep 18
Ok import complete:
Ok, currently running the imports. Did some slight renaming of the files, gave them all prefix 'Kheshte Kham - ' to avoid any name conflicts.
Wed, Sep 13
Seems to have resolved itself; all transcodes for that file are present.
Theora derivatives are being dropped, no need to solve with ffmpeg2theora.
Ok, my batch conversions have completed -- files are all converted to .webm and small enough to upload. (They're long and high resolution, but they compress well because they're interviews with relatively little motion.)
If anything got left over, the ogv mid-resolutions no longer need redoing as they've been obsoleted.
Looks like this merged and went out. Yay!
Abandoning; we've stopped producing Theora derivatives due to ongoing issues with nearly-unmaintained ffmpeg2theora.
Abandoning, we dropped Theora derivative generation due to ongoing issues with mostly-unmaintained ffmpeg2theora.
Abandoning, we've dropped Theora derivative generation due to ongoing issues with the mostly-unmaintained ffmpeg2theora.
Tue, Sep 5
Ok, prior code was removing all the matroska-specific metadata on the MediaWiki side because it was heavy on binary junk, presumably. Patch in https://gerrit.wikimedia.org/r/376088 puts the 'comments' subsection back, which contains the WritingApp and MuxingApp tags which list 'Google'.
Hrm, those two *should* already be being fetched. Looking as to why they don't show up...
So there's a couple of EBML elements in the WebM/Matroska stream that I think could be added to getid3's extraction easily:
Is there a sample file that's not deleted?
Note that legitimate videos come from YouTube pretty frequently...
I'm going to go ahead and decline this as TimedMediaHandler-Transcode has existed for a while.
Fri, Sep 1
Confirmed this merged and went out along with other updates, and no longer produces the described error.
Thu, Aug 31
Offhand I don't know of any reason it couldn't be turned on there.
Wed, Aug 30
Mon, Aug 28
This could be implemented using the playbackRate property of the HTML5 video or audio element.
Thu, Aug 24
Done! Old transcodes will still exist for now; should leave them there for a while to ensure HTML caches referencing them go out of style, but new ones won't be created and newly generated pages won't use/reference them.
All seems well with playback, planning to merge disabling of the .ogv generation at today's SF late swat.
Aug 23 2017
Seems to be working. :)
Aug 22 2017
The WebM enabling is live on beta -- see for example https://simple.wikipedia.beta.wmflabs.org/wiki/File:Tears_of_Steel_in_4k_-_Official_Blender_Foundation_release.webm which now plays back the 360p-fitting WebM in Safari and IE.
Aug 17 2017
I rewrote it a bit https://meta.wikimedia.org/w/index.php?title=Tech/News/2017/34&diff=17122835&oldid=17122825 -- let me know if everyone's happy with this version. :)
Aug 15 2017
Aug 14 2017
@SandraF_WMF note I've been involved in the IIIF's A/V working group on extending the protocol to support audio and video, and have been at a few of the working group meetings for that. There's also a big IIIF working meeting in Toronto coming up in October; if there's serious interest I should probably pop in to that too, or else someone else from multimedia if there's interest in moving forward with stuff more directly.
Aug 13 2017
Per above, this has been fixed presumably by updates to Swift. Closing; thanks!
We managed to merge these; MockOggHandler now lives in TMH. :D
This is still happening, and is cropping up more often. Prioritizing a fix and assigning to self.
Aug 11 2017
Have made a draft proposal here: https://commons.wikimedia.org/wiki/User:Brion_Vibber_(WMF)/MP3_output_discussion
@CKoerner_WMF do we think there's a need for a discussion on this one? I'd like to go ahead with MP3 output for audio, particularly to resolve the issue of audio playback on iOS (where the TimedMediaHandler fancy player still doesn't work, and the ogv.js shim would load slowly even if we added it).
@CKoerner_WMF I think we're good to go any time on this -- I'd love for us to move forward. :)
Aug 10 2017
Note that there may be some issues with autoplay, as browsers are increasingly disabling autoplay and JS-triggered playback for audio-bearing files unless triggered from within an event handler. As I recall there's a lot of asynchronous loading in media viewer, so this may require jumping through some hoops.
Aug 9 2017
My main concern is that the IP no longer matching the IP will be surprising to folks doing admin work, but they'll probably get used to it. :)
Let's say we flip the switch Wednesday, August 23, 2017? That gives some time to finalize the patches after Wikimania, and avoids the eclipse day when people are likely to be busy. ;)
@Johan sometime in the next few weeks (it's holding up a server migration for the video scalers so we don't want to wait too long). We can pick a date if that helps with any required messaging; I just don't want to flip the switch in the middle of Wikimania while we're all busy. ;)
Aug 8 2017
Sorry, didn't mean to start another CSS war. ;) Per Timo's notes on the withdrawn patch, the extra selector is a little janky, but it's probably worth looking more at prefixing the class. (Or if it's super tricky now for some reason, I'd love a general style naming cleanup to be something that's possible in future.)
Aug 7 2017
I think it's extremely important to say that the responsibility is *not* on content developers to guess what will and won't work on our system. It's literally our job to make it work well for them.
Re-adding MinervaNeue project; this is an obviously incorrect problem with the skin which should be fixed.
I agree use of such a generic class in skin code is dangerous; it should be changed to something using the 'mw-' prefix or else the styles need to be specified in a way that won't interact with content.
Aug 5 2017
Aug 3 2017
Per email consultation between me & @MoritzMuehlenhoff we're thinking we should go ahead and deprecate the Ogg Theora video output (using ffmpeg2theora) in favor of the more well-tested WebM VP8 output (using ffmpeg). I'll add a task; a small adjustment to the ogv.js shim setup needs to be done to enable WebM for it.
Jul 31 2017
Jul 14 2017
Jul 11 2017
Jul 9 2017
Jul 7 2017
Jul 5 2017
If I update to 0.10.0 (via setting ver in composer.json & running composer update) I get:
Note if y'all are interested in moving forward on this, I can finish up the CocoaPods packaging on OGVKit. :)
mediawiki-codesniffer is 0.8.0. composer is 1.3.2.
Jun 30 2017
Jun 28 2017
Jun 23 2017
Jun 15 2017
I have the impression rev_parent_id isn't reliable but don't offhand recall how they can break under the hood... Worth taking a look to see if we can make it reliable. :)
Similar symptoms and root problem to T167465 (incorrectly escaped key values), though with a twist -- WikiArticleFeeds appears to be generating its own keys here, without using any key-creation function. This is probably solvable using $messageMemc->makeKey() (1.27 or later) or the older wfMemcKey() function with relevant parameters.
Jun 9 2017
Ok, my vagrant install is using MemcachedBagOStuff which has a makeKeyInternal() which uses rawurlencode() on input strings, but in production we're using MultiWriteBagOStuff which does not override the naive base implementation from BagOStuff.
Turns out Language::isValidCode() lets a lot through that I didn't expect for compatibility with weird hacks. It should prevent actual < and > and path-traversals etc, but is letting the non-ASCIIs through directly.
Per irc, note that Wikibase's splitting everything on user lang is why the userlang appears in pcache and thus the bug is visible on any page on Commons, given the URL param, but on meta or enwiki it needs to be a page that uses user-lang stuff specifically.
Jun 8 2017
Note this doesn't look image-specific; I get exception thrown if I try on a regular page that exists too, such as https://commons.wikimedia.org/wiki/Main_Page?uselang=%E2%A7%BCLang%E2%A7%BD BUT - I don't see the equivalent error on enwiki. https://en.wikipedia.org/wiki/Main_Page?uselang=%E2%A7%BCLang%E2%A7%BD does not error out.
Jun 7 2017
May 26 2017
@Richard_Nevell_WMUK the file appears to have been trimmed or generated in a strange way: its timestamps start at ~201 seconds in, which confuses the heck out of Firefox, ffmpeg, etc. As a result, when ffmpeg skips through what it thinks is half the file, there's no video frames left to decode, and no thumbnail can be generated.
May 25 2017
May 22 2017
I've submitted them upstream to clamav for false positive checking.
I'll fix that :)
Sounds like a false positive, certainly ogv.js is not an exploit. :) Should report upstream to cpanel or clamav or whatever is doing the scanning?
May 21 2017
Ok current status on this -- I need to pick up my modernize branch from https://github.com/brion/File_Ogg/commits/modernize and finish reworking it for PSR-4 so it's autoloader-friendly and composer-friendly.
Poop, error isn't thrown until play when using preload=none. We'll need to manually check the sources against .canPlayType() via a small JS function. We'll also possibly want this for other old browsers that get degraded in future that don't have native ogg/webm but do have HTML5 video.
Ok we tested this at wmhack. Quick note we need special handling for IE9, which supports <video> but none of our codecs (or ogv.js) and also gets grade C non-JS mode.