Good to know! Still doesn't hurt to cut the load in half. ;)

I'm gonna do some cleanup and retire the .m3u8 soon until i retool some stuff, so that may help with this. :D Assigning to myself for some cleanup during my tech debt time.

Going to tweak the JS side to correctly return the parameter position data so we can replace it in the right location...

Poking at this to simplify the config setup, based on the experience testing the commons/remote support. :D

If no objection I'll take this this sprint :D

Now unable to view a video on the web of the app like this one on iOS 15.8.3 (recently released) in an iPhone 6s Plus. It's either still loading or unable to view the video. Able to view it on a third-party player app, like VLC.

In T368433#10036719, @Yann wrote:

Are 1080p transcodes also disabled? https://commons.wikimedia.org/wiki/File:White_Tiger_%281923%29_by_Tod_Browning.webm

hah whoops. easy fix at least :D

Provisional logic https://github.com/wikimedia/wikipedia-ios/pull/4903

Updated task description with results of planning & discussion from last week, resolving as complete for now.

Some local wikis may want to store their project-internal data, such as number of open block appeals per day. They may hope they can use a page in local wiki (not Commons), convert it to Tabular Data data model, then it can be edited and used like Commons Data page (cf T252711).

I'm starting a batch run on any Commons audio files that never got started before, then will run a (slower) batch run on anything that got attempted but didn't complete. These may take a few days to completion through the full dataset (it's not well optimized to look over only certain files yet), but hopefully should help.

We don't actively need that lint yet for mobile apps work so it's completely safe to disable it. Hopefully that'll clear things up on the database!

I think the minimum we would need is the ability to select only some columns from a larger data set. For example, for a table with ballot measure election results, you'd want to be able to pull out just "County" and "For %" to make a simple bar chart.

Secondarily, if we need to be able to query, do we need to be able to subset/filter? The filter options in vega are javascript and thus dangerous, so we want to be very careful and explicit about any filter language we define. It's simplest to avoid this and leave it to the existing wikidata query modules or whatever?

Some quick notes catching up:

links obtained

Going to get some links from Chris on past Graphs usage that'll help me in this research :D

Seems to have stabilized:

Hmm, it's down under 4k entries but still high.

Open questions:

• do we deal with _only new additions in the edit_ or _all alt-less template-less images in the text as of this revision_?
  • the former is implementable by doing the extraction of links on both old & new and diffing them
• do we need to exclude full image markup passed as wikitext into a template as a parameter?
  • to implement: exclude all the {{....}} stuff
• do we need to check very small icon images when sizes aren't passed in the params?

(notes for alternate method using mostly client-side logic)

Yeah, I should clean up the labeling so it's clearer. :D

Ok, 1440p and 2160p transcodes are temporarily disabled for now until better fixes, and we did a kill of the old stuck processes. Might still take a bit to shake everything out; I'm trying to flush through all the missing audio.

I'm seriously considering bringing back my "chunked" scheme that would at least produce smaller, standalone jobs that encode say 10 seconds worth of video, then reassemble the final into a single video at the end. :P Main reason I haven't is that the logic needs to be able to handle missing chunks if individual ones time out or fail and that sounds like a pain, but it'll be a lot friendlier to the job queue infrastructure.

We found that timeouts didn't seem to be handled correctly:

• the default timeout was much longer than expected
• php-fpm timed out _first_ which ended up killing the php script (and thus moving on to the next job queue item) but leaving the ffmpeg process running
• we ended up with 18 long-running high-res multi-threaded ffmpeg processes all churning away competing for cpu time with every other job ;_;

Looks like we've got a couple problems with high-res videos:

• a bunch of 4K videos got uploaded at once and they all queued up
• some of them are stuck! they should be timing out
• it's also possible the audio clips are going to the wrong queue, i have to double-check this

As designed: these are bare video tracks, to be paired with the mp3 or Opus audio tracks in HLS or MPEG-DASH playback. They are not meant to be played standalone.

The list of "active" (may or may not actually be active) includes a number of 2160p high-res videos hitting since June 21. We've also gotten reports before about certain kinds of AV1 videos slowing down the input handling, which I haven't checked for.

I'm bulk-adding the missing audio transcodes which should force them to run through as fast as possible between other jobs, and hopefully will handle the prioritized queue split better.

Live system thinks it has 9,223 items queued on commons and requeue is throttling there for now.... occasionally it goes down an item and moves on.

Batch requeueTranscodes failured on June 22 with this error:

Could be a backfill run but that shouldn't be interfering with anything... I'll check on it

Ah, even better. Figured out how to make a .mov with MP3 audio track working, which means I should be able to ship a corrected, more compatible 144p MJPEG/MP3 QuickTime fallback very soon to replace the previous version using 144p MJPEG/MP3 in the HLS streaming.

Possible workaround:

• instead of trying to do the failover within the HLS playlist, have a separate flat-file .mov with the fallback
• MP3 audio track doesn't seem to work in Safari in a .mov, so I'll have to use AAC-LC instead
• this requires passing the buck up to legal for a codec patent review under our current file formats policy (as AAC-LC was known to require a patent license in theory for some uses before, and though they appear to have expired and Fedora has started shipping encoders, we have to do our own review)
• if we're going to have to wait anyway, may as well wait for the review on MPEG-4 Visual, which will allow significantly improving visual quality vs JPEG compression for the video track

Taking this for feasibility spike. :)

Ok, I turned up an iPad Air of similar vintage as the iPhone 5S, with the same processor and also running iOS 12.5.7! And can confirm it doesn't like the fallback video track in the HLS. Sigh. I'll see if I can find a way to get it to like something we're able to produce with our current limitations, or plan to work around this with a flat-file .mov fallback track.

It's an iPhone 5c IIRC. I should be able to procure an iOS 12 test device as well, it may take a few days to ebay though. ;)

The recommended test link from the description:

Last tested all was fine on both iOS 10 and iOS 15/16/17, but I haven't specifically tested 12 as I don't have it available.

I'm doing some research into what it would take to implement this as a general-purpose ResourceLoader pass-through for modules that are invoked by content (and thus generalizable for things like the Graphs replacement when it's ready). Will write up some notes after a little more poking...

In T344378#9884535, @PerfektesChaos wrote:

While this might be solved technically, the entire task is not a good idea for two reasons:
[snipped]

patch updated:

Yeah, on closer reading of the spec I misread it. :D Lemme adjust that so the 'role' inherits as well. Agreed that it's best not to enforce on visibility:none/display:none since that's likely to be expandable text that could become visible later, plus it's hard to ensure without the external stylesheet. :)

I think the above patch is correct; it will suppress the lint for anything with aria-hidden=true or its descendents, and for any media elements that _themselves_ use role=presentation or role=none (it's not clear to me from checking the docs on MDN that those should apply to descendants unless they're specifically part of the parent element's role).

Ah, good catch! It should be relatively straightforward to tweak the lint check to exclude subtrees with a suitable aria-hidden etc. I'll make some notes and see if I can knock that out this week.

Woohoo!

ah yes and include prolly a link to https://www.mediawiki.org/wiki/Wikimedia_Apps/iOS_Suggested_edits_project/Alt_Text_Experiment for the wider work :D

[added second paragraph i forgot to paste before submitting whoops]

In T344378#9869476, @Quiddity wrote:

For Tech News (per the User-notice tag that was added earlier), please could someone clarify when the entry needs to be announced, and what it should say? (1-4 sentences, 1-2 links). Thanks!

Current state:

I'm going to retool this to move the specific alt-text check into our own extension, with a clean hook point in core, as we'd previously discussed. I think this should allow us to piggyback on the lint-time checks more easily without having to put stuff in core parsoid. :D

Updated the Parsoid-side patch in case we do want to make use of it later:

https://github.com/wikimedia/getID3/pull/2 should make 1 mergeable :D i undid my local version of an older fix

RoomEnvironment is relatively foolproof to set up, and will work much better for physically-based rendering (PBR) materials — as frequently found in the glTF format — than point/spot/directional/ambient lighting.

I'll take a peek this week!

(I see this is also in the Hackathon workboard -- perfect timing! I'll have updates on the patch for folks to test by then but I'll be remote for it. :D)

This got brought up recently and I think it's a reasonably self-contained and not huge work blob. :) Adding myself to do a spike test bringing branch up to date and either making it work or deciding we should redo it differently with more resources.

I *would* like do a spike test bringing the gltf branch up to date or replacing it with another renderer... I think it's relatively self-contained compared to other multimedia projects and I may be able to squeeze it into my misc tech debt time budget. ;)

closing as resolved, update should go out with next week's train and start applying on future ffmpeg failures

One additional thing: Safari has native USD model support, depending on whether there are format patent issues or not (needs investigation) it might be worth including support for native display via a conversion. This would be a stretch goal, potentially assignable via Mobile Apps if interested for iOS/iPad/Vision Pro compatibility.

Problem analysis has not changed since my initial reply years ago:

• use GLTF format for color models, it's standard and well supported
• update the frontend and the backend renderers
• if necessary, replace them with newer libraries

Still waiting on WMF to budget time to look into doing more multimedia work. :)

[patch no longer addresses this with a column, separate patch will later in the error string]

This is T358980, will follow up there :)

Agreed that's probably easier and less spammy :) I'll adjust the patch in progress

Ok, the definitions have landed so we can switch them in whenever we get legal approval. The wheels are being set in motion. :)

cf T57942 and T362123

In T362123#9700047, @Ladsgroup wrote:

Yup, we shouldn't use ENUM for schema anymore, just use code constants (missing=0, queued=1, etc.)

Agreed let's do those together...