Help talk:Converting video
APIError: titleblacklist-custom-space
editI've just tried to upload a video from YouTube and it throws up an error message including what I've pasted into the header. The full error message is:
- An exception occurred: TaskError: b"b'pywikibot.Error: APIError: titleblacklist-custom-space: \\xe2\\xa7\\xbctitleblacklist-custom-space\\xe2\\xa7\\xbd\\n[filekey: 19s4rm3m2fgg.7r0gca.860615.webm;\\n sessionkey: 19s4rm3m2fgg.7r0gca.860615.webm;\\n invalidparameter: filename;\\n help: See https://commons.wikimedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes.]'"
Could somebody please have a look and advise what's going on? Schwede66 04:24, 16 January 2023 (UTC)
It should be just as easy to upload a video to Commons as it is to YouTube
editYou know if Commons installed some of these apps itself, then it could do the conversion "under the hood", and then users could upload videos just as easily as they can currently upload them to YouTube. Jidanni (talk) 13:43, 4 March 2023 (UTC)
Linux using VAAPI on Intel devices: Two passes not necessary anymore?
editThe Linux and OS X command line section gives an example using two ffmpeg passes, which supposedly is recommended for better quality. The Linux using VAAPI on Intel devices gives an example using hardware acceleration via vaapi, but it's only a single ffmpeg command. I'm comfortable with CLI but have no experience with ffmpeg and encoding/decoding, so I'm not sure, is this single command already doing two passes? Or is it using a completely different algorithm where two passes are not necessary? Is the result the same or better/worse than the above two-pass method without vaapi? I think it would be nice to add a sentence, e.g. that the vaapi encoders make 2 passes not necessary, achieving similar results, or something like that. Elimik31 (talk) Elimik31 (talk) 21:48, 20 March 2023 (UTC)
- If you try and compare them you should see the difference: the vaapi command is expected to provide larger files for a similar quality video but should do it in much less time and more energy efficiently. Those commands are using different hardware in your computer. The CPU can be instructed to analyse the video file as a whole. Hence, the first pass is used for analysis. The GPU uses one of its hardcoded algorithms and basically treats the video as a stream, so there are less options to configure and it provides less optimized files. Therefore, the two-pass command should be preferred whenever possible. But in some cases you will find that with larger video files it takes too long or fails at all on your specific hardware due to slower CPU or little RAM. Then you can try to take advantage of vaapi. Роман Рябенко (talk) 07:18, 21 March 2023 (UTC)
ffmpeg guidance
editI think we should probably start recommending AV1 over VP9 at this point, especially because the optimal AV1 command is much much simpler; we can do away with the two-pass and script nonsense. Here's the new guidance I'm thinking:
ffmpeg -hwaccel auto -i input -c:a libopus -c:v libsvtav1 -crf 35 -preset 10 output.webm
- "crf" stands for "constant rate factor". The lower the value, the higher the subjective quality of the video, but the larger the file size. It accepts a value from 0 to 63, with 35 as the default; you can raise it a little if the video is too large, or lower it a little if the video looks bad.
- The preset dictates the compression speed/efficiency trade off. The higher the value, the faster the encode, but the larger the file size. It accepts value from 0 to 12, with 10 as the default; set this to the lowest value you have the patience for.
I think we can even get rid of the part about audio bitrate. Just let Opus's VBR magic sort it out. Snowmanonahoe (talk) 03:43, 22 July 2024 (UTC)
- While we're at it, let's get rid of avconv, which is no longer maintained. Snowmanonahoe (talk) 03:50, 22 July 2024 (UTC)