Sat, Jul 13
Confirmed this fixes the transcodes; resolving.
Fixing the .ogv file by setting the 'ROTATE=180' to 'ROTATE=0':
I suspect that the 'rotate' annotation in the comments is not actually handled by Firefox, VLC, or ogv.js -- certainly I never wrote code in ogv.js to handle it -- and may be a leftover from the MP4/3gpp original file the .ogv was sourced from.
This may be a problem that's been since fixed in upstream ffmpeg...?
For me, the original plays upside-down in Chrome, right-side-up in Firefox, VLC, and ogv.js. So this ain't handled quite universally I suppose. ;) I'll take a peek.
Fri, Jul 12
Mon, Jul 1
Sat, Jun 29
Fri, Jun 28
Thu, Jun 27
Note a deployment typo caused this fix to not get deployed in fact. Whoops! Roan's fixing it now.
Fix deployed. Should no longer cause fatal errors, but should log the transcoder output into the transcode table so we can review it later for suspicious commonalities.
Ok Reedy started this a while ago under T226713, so no need to re-run it a second time. It's probably the cause of seeing multiple fatals over on T226748, since all failure cases would come in a relatively short time. :D
Ah great, that'll do the job.
I have this ready to run on mwmaint1002 but want to wait until the fix for the fatal error in T226748 is deployed so I don't spam the error logs.
cleanupTranscodes.php should be able to do this I believe, I'll test offline later.
Wed, Jun 26
(main difference from previous behavior is that in practice most videos got the image with popup link where now they get a video directly)
Ehhh, it's not hard to add a fallback image link that points to the file page. But I wouldn't necessarily block on it if it's not done soon.
Mon, Jun 24
Note that with the "New video player" beta feature enabled, this can be tested in production -- just make sure you're logged in in the mobile browser and it will pick up the preference.
Probably should adjust the preload setting; ISTR some related issue in past. Will test further once no longer encountering unrelated server errors.
Sun, Jun 23
Yeah, looks like we only read 1024 header bytes and it appears later in both those files, around 4000+ bytes in.
Confirmed that it's resolved with the video,js player frontend ("New video player" in beta features preferences)
Sat, Jun 22
I was able to reproduce this locally using the files via InstantCommons, and it looks like the root problem is that some of the files are misidentifed as audio, causing the packed-gallery code to use a small icon width instead of a large width constraint here:
Note the root problem appears to be that some of the files are incorrectly marked as audio, causing a small width to be used for making thumbnails instead of a large one:
@Eatcha can you file a task for the unexpectedly small videos in gallery, and we'll track it down on that task. Thanks!
They seem to be small whether the old or new players are in use. Not quite sure why yet, will look into in a bit -- those are full size videos and should not be showing tiny... The polar bear video is low resolution, and seems to show at its native size. We may need to adjust things to ensure that video players can be sized larger than their originals?
Thu, Jun 20
Closing as this was worked around where needed.
Tue, Jun 18
Note that playbackRate support was recently contributed to ogv.js, so can be used when I finish packaging the new release. Shouldn't be hard to enable the rate control in the new video.js player...
@Eatcha T174393 covers this; we can add it fairly easily soon (the necessary support for the Safari compatibility shim was recently added upstream; I just have to package a release and then enable the rate control)
Jun 12 2019
Need to add a VTT parser; currently there's only a SRT parser that produces VTT-compatible objects which we can output in either format. Shouldn't be hard to add, just didn't get to it yet for the MVP. :D
Basic patch added which is an updating of the old upstream PR. Seems to work but might have edge cases; I'm happy to merge it for now to get us rolling if it looks ok.
@TheDJ yes, it's now validated (and in many cases slightly manipulated to become conforming) before being served out. As long as the formatting uses <b>...</b> and <i>...</i> rather than wiki-style '''...''' or ''...'' it will work with the upcoming videojs player -- but the old Kaltura player we're still shipping doesn't understand those.
Jun 10 2019
Upstream issue is: https://github.com/videojs/video.js/issues/5252
Jun 6 2019
Jun 4 2019
Looks like the patch never got reviewed. I'll poke some people and see if we can get it moving.
May 29 2019
May 28 2019
Ah I see! Typo, should be $title where it's $page in this:
Ah yeah that'll do it. I'll get on it...
May 26 2019
I'll investigate this Monday, probably a regression in our recent changes.
May 9 2019
May 7 2019
Once per instance is probably ok, as it should be rare to have the same video over and over. Uh, except on the file page with versions maybe. >_<
That ain't pretty. I'll see if can improve this.
IIRC production Commons is fetched into Beta via ForeignAPIRepo, so it's seeing only the srt-format subtitles in its list that production Commons sees. It should fix up after production Commons gets the timedtext API...
May 2 2019
Extension code that's dependent on specific interfaces should probably feature-detect for those specific interfaces with function_exists, class_exists etc rather than trusting version numbers as well -- and that can only be tested by running with the actual version. And you'd only detect failures (like using a new feature on the old version path) from running with the other version anyway, so I think they'd have to go together if that's something we want tested.
May 1 2019
Apr 23 2019
Apr 3 2019
Feb 28 2019
Feb 27 2019
Feb 21 2019
(Just noting I'll be ready to work more on this in around next week-ish)
Feb 5 2019
Feb 1 2019
The above patch https://gerrit.wikimedia.org/r/487527 removes some of the non-scripting tags from the checks in UploadBase::detectScript, and makes the conservative/exact IE heuristics called from UploadBase::verifyMimeType optional (but still on by default). This also deprecates $wgAllowTitleInSVG since <title is no longer looked for.
Ok, looking at the actual current code now... UploadBase::detectScript does the check, and combines several things:
- looks at first 1024 bytes (more than IE checks) if binary, or all if text
- does some text encoding checks (seems to be SVG-specific?)
- looks for IE's trigger tags for type detection
- looks for some Safari (old Safari?) trigger works for plain-specific type detection
- decodes XML-style char references (seems to be SVG-specific)
- looks for some script-like things CSS-like URLs in body content that seem to be SVG-specific
@Aklapper I believe it's very on-topic to discuss the security implications of a suggested feature change. Where would you suggest we discuss this if not here, on this task?
Jan 29 2019
Thanks! Didn't mean to rush you, I'll probably poke at this next week unless I get inspired. :)
Jan 28 2019
- IE 6 and 7 were both available on Windows XP, which includes TLS 1.0 support but not TLS 1.1 or 1.2. However IE 6-8 on XP fail to work anyway due to lack of SNI.
- This takes IE 6 off the table entirely.
- IE 7 on Vista should still work correctly with TLS 1.0, 1.1, or 1.2 -- https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/
- IE8 supports X-Content-Type-Options: nosniff header; if we don't already use it consistently, applying this on all file views would resolve all sniffing issues on IE 8
The chance that someone would visit using an old IE version was probably 50% when the code was originally added; IE had a very high marketshare in the early 2000s. However at this point we can't even be accessed in IE 6 as far as I know (due to servers dropping old TLS versions for HTTPS). I think it's pretty fair to change the balance of what we check for.
@zeljkofilipin should I take this task? I'll need to grab some documentation for starters or else grab you later when we have time. :)
Jan 23 2019
Jan 4 2019
Note that bast4001 no longer works for login?
Jan 3 2019
A few quick notes:
- we should sketch out a few extensions in this model -- I'll take a look at some later in the week
- aggressively pushing action hooks to deferred or jobqueue means we need to be much better about making the job queue *work* reliably (and quickly) on small installs
- immutable interfaces are probably sufficient for most of what we want on hook params, without necessarily needing to create full value classes for everything. We want both sides of the hook to know what's promised & what's allowed & what might change from under you
- side effects issues are something to consider more, about guarantees vs recommendations. needs some real-world testing to see where these guidelines lie
Jan 2 2019
MediaWikiVersionFetcher would need to be altered as well, which currently looks for $wgVersion being set in DefaultSettings.php
Sensible enough. :) I'd recommend MW_VERSION as the constant name; but should it be set in DefaultSettings.php where $wgVersion is set now, or up in defines.php or elsewhere? May also need to update documentation about cutting release versions (updated location of the changed version).
Dec 28 2018
Confirmed it fixed the VM on the Linux PC too. Sweeeeeeeeeeet!
Dec 25 2018
Woohoo! I'll close this out now as fixing my main case (on the Mac where it almost worked) and will confirm Friday on the Linux PC and if that doesn't resolve it there will just reimage it.
On the Mac (where the extensions installed but php-cli didn't), php was gone again when needed for composer runs via vagrant git-update:
@Reedy I'm out of town for a couple days for the holiday so can't retest just now, will poke again later in the week. But I think it was around commit dca68a5c3db8f338bb8b00b3e014c3b1d1308a99 (mid-November) when I last updated it successfully.
Dec 22 2018
Nov 14 2018
Note that this is dependent on suitable playback support being widespread. While on desktops, Chrome and Firefox are shipping AV1 now or in next versions, and Microsoft is previewing it for Edge, we don't yet know the situation for Safari. I've started adding AV1 decode to ogv.js, but it's slower than decoding VP9 so far so may require running lower resolutions (unless WebAssembly threading arrives soon on Safari).
Ingest should be a matter of having a suitable ffmpeg & libaom package backport, and a small update to make sure we're allowing AV1 codec in WebM container. Note there will also be MP4-flavored AV1 out in the world, but we don't yet know how popular that will be as flat files (versus DASH/HLS/streaming).
Nov 11 2018
Nov 8 2018
Storage note: may need/want to include a reverse-domain copy of the domain for indexing purposes for bulk lookups.
(my concern being the possibility of getting people to agree to click-through things they shouldn't; attacker script wouldn't be able to auth/confirm the form, in theory)
Nov 7 2018
Version bumped, and README includes a little info on the changes to config.
Yep, our bad -- we didn't document the breaking changes to config. :( Try this:
Nov 5 2018
Oct 30 2018
Oct 25 2018
Oct 9 2018
I didn't manage to do an early push because I was out sick most of last week, but it should be live now, and the re-rendered file works for me so hoping it's fine for @jeblad. :)