Thu, Sep 19
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.
Tue, Sep 17
Wed, Sep 11
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...
Wed, Aug 28
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.
Or... perhaps MW should run wikipage.content against the contents of <indicator> as well?
Looking at the TimedMediaHandler JS, it uses the wikipage.content hook which passes a jQuery object holding the content area in which to process elements. Anything outside the content area is not processed.
Can you create a copy of the template that uses the form that fails? I'm uncertain what to modify from the description.
Aug 12 2019
Would you want to trim in the base handling of the metadata, or in the output API serialization specifically? Might be best to do it all around if we're going to apply such rounding in ways that are machine-readable.
Patch switches to the core distribution (no http-streaming component) and the more aggressively pre-minified version. Not quite complete, as this means we can't patch in the text track lazy-loading on top as easily.
Aug 9 2019
This seems to be during a chunked upload of an Ogg audio or video file. Any chance we can get the original file chunks?
I can repro the inconsistency on both domains. I think it's a HHVM vs Zend PHP difference; the shorter serialization is served from HHVM 3.18.6 while the longer one is served from PHP 7.2.16.
Jul 29 2019
We can probably reduce the size for now by using the video.js core distribution (without the http-streaming component which we don't use yet) and using more aggressive minification (rather than using our own minifier, which doesn't shorted variable names and such).
Jul 26 2019
Jul 13 2019
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.
Jul 12 2019
Jul 1 2019
Jun 29 2019
Jun 28 2019
Jun 27 2019
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.
Jun 26 2019
(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.
Jun 24 2019
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.
Jun 23 2019
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)
Jun 22 2019
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?
Jun 20 2019
Closing as this was worked around where needed.
Jun 18 2019
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. :)