There's excellent news from the Lab about plans to eventually support embedded MP4s. This has been a problem because many videos, notably including those hosted on Vimeo, use this format that does not work with out-of-the-box Chromium Embedded Framework, the basis of parcel and shared ("Media on a Prim") media as well as viewer browsers. Although there's no schedule yet, it's an encouraging development compared to a previous statement in the Jira that the Lab did NOT plan to support the format. (This may affect plans for hosting SL-related video content and for displaying that content.)
On an unrelated topic, there have long been devices that measure visitor scripts with the goal of controlling the lag they might cause. In a recent forums thread ( https://community.secondlife.com/forums/topic/448580-avatar-script-count-limit-on-homestead/) some of us took a deeper dive into what such devices might do to be useful, and what they very often do that is useless -- or worse. To summarize:
Scripts worn by visitors can lag other scripts but generally do not contribute to the most common forms of lag experienced by avatars in a busy region. That's because scripts are the lowest priority of sim processes, so a lot of avatars in a region will tax *other* sim resources, squeezing out scripts (and making script-on-script lag more severe). It can be annoying that scripts don't get much time to run, but that's rarely best addressed by reducing the script load itself.
That said, reducing the load of the most over-scripted visitors can improve responsiveness of other scripts (such as vendors), and griefers can take over-scripting to such an extreme that it hurts overall sim performance.
To efficiently find script offenders, what to measure? Turns out that the simplest metric -- count of running scripts -- is probably the best option. That's because, as detailed in the cited thread, both Script Memory and Script Time are actually measuring something very different from what the names imply. Script Time in particular is almost impossible to use responsibly because the more a region is having performance problems, the less accurately Script Time can be measured in the region and the longer it takes (20 minutes or more) to settle into a potentially useful metric.
Worse, the *direction* of inaccuracy is also a function of time and sim load: when an avatar first arrives in a busy region, their Script Time measure will be (hugely) *over*-estimated compared to a less busy region, but later when the measure stabilizes, the same scripts will show *lower* Script Times than when the sim is less busy. Indeed an avatar's Script Time depends less on their scripts than on the performance of the region and the time since the avatar arrived.
Reporter Qie Niangao