In T284970#11373219, @Sdkb wrote:

To read the metadata, I was just looking at the metadata section of the file page. Is there a reason that the coordinates (which per above do seem to be part of the file's metadata) — and every other piece of metadata apart from "software used" — might not show up there in the same way they do for photos? If so, perhaps the issue is with how we display metadata for video files rather than something Video2Commons is doing.

In T393884#11198794, @Bawolff wrote:

I'm unsure this is worth it.

An unknown number of uploads to commons may already have a CAI/c2pa content credential, if the upload in question has been created by an Adobe product or with a Leica or Nikon camera with builtin CAI /cspa support.

In T391473#10735817, @Bawolff wrote:

Even if the speed of the connection to IA had been unlimited (or there had been no timeout for that portion), wouldn't the operation still fail at the publication stage?

My suspicion is it wouldn't, or if it did fail we would get a new and interesting error message that may tell us something interesting. But realistically i have no idea.

In T391473#10735567, @Bawolff wrote:

The upload by url async attempt didn't work because it took more than 180 seconds for wmf to download the file. So i guess it would require a network connection to wmf of about 250 mbps for that to work :( . Perhaps the time limit could be increased.

In T353659#10728540, @Aklapper wrote:

That is not what your link says (it's about blocking a website, not a software).

I hope, that not even a higher german or european court would come to the same conclusion. But as far as I know, thw ruling has not been challenged and it is in line with the ideas of Trump and Musk.

In a decision on 21 November 2024, the Higher Regional Court of Hamburg (OLG Hamburg, not the highest German court, but the second highest) made a decision (blocking a website that links to yt-dlp) which effectively means that the use of yt-dlp as well as any other downloader to download YouTube videos (in Germany, but according to the same reasoning almost everywhere) is illegal.

I have to ask -- is that compatible with the terms of service of YouTube? We probably can't implement anything like that.

In T337106#10510931, @Yaron_Koren wrote:

My new site Commons Walkabout may be of interest to anyone here.

none the less these files are handled fine by ffmpeg, VLC, the stock video player of my smart phone and web browsers on windows and linux. Also MW extracts the audio part.

While it is good, that chunked upload does no longer miss the last chunk, it does not change this bug: During upload files undergo checks (does the mime type match the file extension? does the file contain malicous code? Does the file use a free encoding?), therefore an incomplete file should either be rejected at all, or "repaired" (and in the case of an incomplete or even missing IEND chunk of a PNG this is possible: the preview of the Upload wizard itself does it!)

Error does still occur (upload from today, image is shown by upload wizard, but not as thumb):

Loading the original file or the 800px thumb would probably be non-ideal, particularly for users with slow internet. But perhaps having the 120px and 240px thumbnails be permanently cached for all images upon their upload could be beneficial.

While it does work with full dates with the quotes, it does not work with a date like "2019-09" and i have actually no idea how i would query for a range like 2017-09-12 to 2023-01-14, or even for a range with time?

It does work with "2222-22-22". It does also work with "2222/22/22" but it does not work with 2222/22/22

Thumbs do work with AV1 for some time now.

I do get the same error with a webm file. I was able to upload the first 1GB of the file and do a revision upload of the first 2GB, but once I try to upload either the complete file of 3.6GB or even a part of 2.1GB I either get the same error as MikhasiRV or I get a "someone is doing something with this file" error. I can upload the whole file to my web space if you need it for upload tests.

In T266155#8710759, @TheDJ wrote:

In T266155#8707579, @doctaxon wrote:

@TheDJ thanks for your comment. These 429 errors "needs to be judged on case by case" means it's necessary to open a bug report for everyone of these errors? Thirty hours later now the error still exists. And I think the thumbnail on https://commons.wikimedia.org/wiki/File:%C4%8Cern%C3%A1_Hora-pah%C3%BDl.png has to be generated already at least one time when the file had been uploaded.

Yes, separate issues should be filed for those, they have nothing to do with this ticket.

In this particular case, the error is ImageMagickException: Failed to convert image convert: IDAT: invalid distance too far back. Which means that the image is pointing somewhere outside the range of the file, meaning that the file is broken. Apparently this file used to work up to 2016'ish, but after that time the PNG library became stricter (to deal with potential security errors).

Generally downloading it, processing it with a tool like pngcrush and re-uploading should solve that. Which I have done.

I am not sure, if this task is about adding the functionality of video transcoding to Upload Wizard, or if this task is about adding the functionality of upload-from-url to Upload wizard,

Purging the file description pages may be needed?

As I asked for exactly that a number of times, there may be one or more other phab tasks asking for the feature.

In T191802#9320060, @Nosferattus wrote:

Personally, I think 5 GiB is plenty. Our purpose is education, not entertainment. We don't need 8K videos to explain how mitochondria work. 480p works fine. 1080p is probably overkill. And 4320p (8K) is just totally unnecessary. What use case is excluded by requiring that people downsize giant video files?

Oldimage is a needed parameter and obviously hidden in a post parameter. I have changed the URL ins this ticket, but of course the problem remains the same.

As I recently found out, popular 8K displays accept 4K media in mp4-h264 format and webm-vp9 and 8k media in mp4-h265 format and webm-av1, but not 8k media in in mp4-h264 format and webm-vp9 and webm-vp8. I uploaded a number of 8k media in webm-vp9 format to commons, but they cannot be shown in native 8k on popular 8k displays. I could reencode this files to av1, but it does not make sense, as the preview images will not work with av1.

Ok, you are right. No EXIF is extracted. But some Metadata is found while uploading: lossless, not animated, no transparency, width, height, webp version, datetime, bitdepth -- and not even this information is displayed int the metadata section of file description pages (and thumbs do handle the full EXIF, IXX XMP)

In either case: the thumbs generated by MediaWiki (as png, which is also wrong) do contain the EXIF data from the uploaded webp file. I assume that the database table in MediaWiki that contains EXIF metadata also contains the full EXIF (and can be queried from the API).

https://commons.wikimedia.org/wiki/File:Eunotosaurus_africanus90137.webp <- contains ICC information
https://commons.wikimedia.org/wiki/File:Meintest.webp <- contains EXIF XMP ICC information
https://commons.wikimedia.org/wiki/File:Strand%C3%BCbergang_57_5.webp contains:
VP8 Version : 0 (bicubic reconstruction, normal loop)
Horizontal Scale : 0
Vertical Scale : 0
like many but not all webp files
https://upload.wikimedia.org/wikipedia/commons/8/8d/Debbielo2.webp <- ICC
https://commons.wikimedia.org/wiki/File:LHB_coaches_.webp <-- ICC, webp flags, VP8 version
https://commons.wikimedia.org/wiki/File:Universiade_(%E5%A4%A7%E8%BF%90)_Exit_A_F1_(2022-08-16).webp <- full EXIF from Xiaomi device with GPS and date information

This applies to all 29975 webp files at commons. Use mediasearch to choose any of them. On the file description page hover the mouse over the thumb download links and it will show a download url ending in ".webp.png" (and it is really silly to generate a png thumb from a png file. the webp will be smaller).

There are 29975 webp images at commons. The bub applies to all of them - not all come with EXIF, XMP or ICC data - but you cannot see, witch do have metadata, as it is never shown on the file description page. You would need to download webp files and inspect with exiftool fo find out.

In T322717#8783967, @Legoktm wrote:

In T322717#8764340, @C.Suthorn wrote:

Will rel=me be limited to the user page, or can it also be used on a subpage of the user page?

Currently it is limited to your root user page. I'm a bit skeptical whether we need to support subpages, but you're welcome to file a feature request asking for it, just no guarantees it'll be implemented.

A Link to this page: https://commons.wikimedia.org/wiki/User:C.Suthorn/gallery is printed on the business cards Wikimedia Deutschland e. V. issued to me. I use this page as a reference, when asking instituions for image permissions and I also link to this page from my Mastodon account.

Will rel=me be limited to the user page, or can it also be used on a subpage of the user page?

not what is accepted as an upload format.

Yes, this is nothing to do with editor/uploader activity.

Question though: what is this ticket about?

Hmm, that is actually the first image from the video and the image from the middle as is supposed to be the case. Strange

In either case the thumb does show now (possibly because a server was restarted?) and the task can be closed.

I get an 500 error (and that makes much more sense).

@TheDJ As far as I can see, this is related to file size. Files up to 60MB upload fine. Files up to 600MB can be uploaded in most cases. Files up to 1.2GB can sometimes be uploaded. Larger filed can be uploadd with the Rillke script, if you try 1-4 times.

If a video has subtitles, there will be the letters "CC" in the upper right corner. "CC" is a widespread abbreviation of "Creative Commons". This creates the impression, the file was licensed with a mystirous (non-existing) licence "creative commons". Many reused files from commons.wikimedia on external websites show a licence information of "creative commons" when the real licence is cc-zero, or cc-by-sa-1.0, or cc-by-sa-2.0, or cc-by-sa-2.5, or cc-by-sa-3.0, or cc-by-sa-4.0. With the video player showing the letters "CC", this may spread even more. Especially as the new player does not show the licence information after the video has ended playing and there is no button "display licence" and the button "(i)" shows the description page, that is often not read/understood by reusers (leading to using wrong attribution on external websites). The description page also does not show the metadata (apart from encoder info) that the video contains (unlike image files). While "CC" is probably known as meaning "Closed Captions" among Cinema Enthusiasts who prefer to watch video in its "OV" (original version,, often the arcane language of english, that is neither spoken nor understood by the vast majority of world population), and deaf people, "Closed Captions" is a term mostly unkown to lay people.

I succeded uploading File:Piss-In, Pee for Free 2022 Berlin 07.webm. The upload failed 25 times, then succeded (If you look at the upload comment it contains the number "25002". That is a slightly broken counter but it tells that there were 25 failed uploads before).

It seems upload always fails with a "5" http-response. The maximum on error info that I can provide is this log of response headers and response body. (edited IP and CSS)

I do assume, that not only my files are affected, but also attempted uploads by other users. Are there "serialization is suspect" messages for other users for "action=upload" in logs?

Not sure if retry works from the failing point (offset)

Chunked upload is fine, but the problem that happens to me is that after a file is uploaded and the chunks are assembled, the publishing fails. So the timeout will happen wether the upload itself is chunked or not. Rillke's tool may sometimes succeed - i guess - because it polls the publishing process from time to time, thereby reseting the mediawiki timeout??

Only the videos with the curids

I was able to do ~250 successful revision uploads, but for 150 more files the upload is not possible (curid):

I was able to upload one 3.8GiB file with the Rillke script.

Can you provide a bit more detail so I can find this in the logs? Specifically, which wiki did you try uploading to? What tool were you using, the classic Special:Upload or UploadWizard, or something else? At what point in the upload process did you see this error?

add T286532 T286481 T286430 and many more without Phab-tasks

@zhuyifei1999 have you tested the example file? I need the server space back.

@zhuyifei1999 I have created an exymple for you: http://up-and-download.de/wiki-largefiles/drei.mp4

+ T286481 and T286430

Huhu??

These are revision uploads., A description will be ignored by the MW-software. The pages have already the description with Categories and all. The upload comment can be anything, for example "see phab T 286532"

I have checked the 13 server-uploaded videos: the metadata is fine.

I thought I already wrote, that the jpgs and tifs are ok and can be deleted from scratch.

As only two files are affected by this: Leave this files out, once you have uploaded the other files I can run a script, that checks for discrepancies between my local files and the files online. With only two dicrepancies I can then reupload two files with Rillke's big chunked upload javascript.

@Sdkb can you provide another example of an mp4-file that was uploaded to video2commons and the webm-file on commons that resulted?

The Contra dancers... video downloaded from commons does indeed contain not metadata apart from audio and video codec information. The upload comment states it was uploaded with a tool from labs. But there is no information on the original file? What metadata did the original file contain?

I can only provide this example of adding metadata to a webm-file:

While jpeg files nearly always come with some metadata i.e. exif, most MP4 files and the transcoded webm files resulting from these in most cases have nearly none. Also exiftool can read, but not write, metadata of video files. ffmpeg however can read and write metadata of video files. And video files can contain a lot of metadata (only not in exif format). Videos can come with copyright information, information about the content (title,location, city, country) and notes. But even if a webm file uploaded to commons contains masses of metadata, the MW software will only show the audio codec and video codec version numbers as metadata at the bottom of the file description page at commons. If you download the original file you can still see the metadata with ffmpeg or exiftool. (As far as I am aware, this is not the case with the transcoded versions).

complete file list:

You are aware, that it is 712 files and I only missed a zero in one of the filenames of the milestones? The sum of the 712 tar.gz should be very similar to the sum of the 5 original zip files