In T257719#9551368, @dbenjaminmiller wrote:

As a photographer who has a few thousand of his own photos on Commons: I'd support adding AVIF, and I would use it if available.

The main motivation for me to use AVIF would be the ability to add photos with greater than 8-bit color. Right now, I upload my photos as 100% quality JPEGs. If I could easily upload them in a higher-bit-depth format, I would.

I've uploaded a few of my photos as TIFFs, but those files are huge, and they don't have sharp thumbnails like JPEGs do. AVIF support would presumably let me do one upload of a small file and allow for that higher bit-depth.

WebP, by contrast, has no support for HDR or high bit-depth. But most JPEGs you can find online are copyrighted material, too.

In T257652#9997534, @Jonathanischoice wrote:

I am now down a rabbit hole updating someone's BRISQUE, PIQE and NIQE code. It mostly now seems to work, but I don't have an NVidia card to test the BRISQUE code on.

In T173228#4309407, @RileyBugz wrote:

By the way, I propose changing the code to this:

@fonts: sans-serif;
@fonts-secondary: 'Times', 'Times New Roman', sans-serif;

and for screen-common.less:

h2,
h3,
h4,
h5,
h6,
dt {
font-family: @fonts;
}

dt {
font-weight: bold;
}

I compiled libavif from https://github.com/AOMediaCodec/libavif

In T257652#9989027, @Jonathanischoice wrote:

Apologies - for what it's worth, using an arbitrarily chosen but reasonable quality of 80% for both conversions:

In limited local testing, I found that AVIF encoding is slow. Like, really slow.

$ time convert IMG_4610.jpg IMG_4610.avif

real	0m16.776s
user	0m49.837s
sys	0m1.337s

And that's not even a huge file by Wikimedia standards.

$ identify IMG_4610.avif 
IMG_4610.avif AVIF 4032x3024 4032x3024+0+0 8-bit YCbCr 0.000u 0:00.002

...

$ ls -sh1 IMG_4610*
3.7M IMG_4610-2.jpg
2.4M IMG_4610.avif
2.6M IMG_4610.jpg
 17M IMG_4610.png
 35M IMG_4610.tiff

Considering that only 0.2 MB was saved, I don't see the point of using up 85% of the 1min maximum response time to serve images in AVIF. If file creation and editing tools gain widespread support for it, allowing AVIF uploads might be a good idea.

What happens to transcodes if the original file is moved while the transcodes aren't? Do they become orphaned, and is there a way to detect and clean up these?

I think the issue is resolved. For some reason there was some issue with some existing video files uploaded before I had enabled TMH extension. I removed them and erased them from the database and re-uploaded the videos. Now there is no issue. Quite odd!

In T339918#8950634, @brion wrote:

...though.... error codes should cause it to reject the conversion and not save it!

I tried a new file https://wiki.tnonline.net/w/File:20230515_212335.mp4

Thanks for the update.

In T339918#8948863, @TheDJ wrote:

Have you set jobrunrate to 0 as specified on https://www.mediawiki.org/wiki/Manual:Job_queue ?

Example file file uploaded as https://wikidev.tnonline.net/w/File:20230607_112046.mp4 and we can see that transcoding gets submitted immediately

In T298553#7606070, @Jdlrobson wrote:

@Forza1000 thanks for letting me know. I'll make sure we have some kind of solution for the 1.38 release T298801.

In T298553#7597694, @ashley wrote:

Seems reasonable. 👍 The only users of this obscure feature I was able to find are two old wikiHow skins ("HowTo", the pre-July/August 2013 skin, and its precedessor, "Bubbles") and the removal of the core code should not impact either of those in any way, shape or form for they essentially reimplement the core logic (albeit badly).

Here is an example how I envision how it could look like. Possibly add a checkbox to re-use Caption field as Alt text.

I just want to mention I have the same use-case. I use MediaWiki to create a personal blog of sorts and use DPL to display a list of recent posts with the date prepended. However, the date is the initial category added date, and not page creation date - which is what I really need. Because if I change categories or sorting keys, then the date would be updated and therefore wrong.

It could definitely be a case that Opera is doing the wrong thing. Not that I think there is a 'standard' for this stuff. I can report the issue to them too, but I'd think it would be helpful to understand the problem a bit more first.