youtube-dl doesn't work anymore edit

The video download example from YouTube doesn't work anymore, YouTube clearly did some changes that prevents the tool from fetching video data. This is what it says now instead:

$ youtube-dl -F dPZTh2NKTm4
[youtube] dPZTh2NKTm4: Downloading webpage
ERROR: dPZTh2NKTm4: YouTube said: Unable to extract video data

I've accessed the video page itself directly and guess what? Plays perfectly fine. But there's no download button, and the video is indeed Creative Commons licensed. I don't get it why YouTube lets creators use the CC license, but fails to provide a way to download these videos for everyone. Instead they flat out block downloaders that may even check if the video in question is CC and if not, it doesn't proceed further. They block ways to download any video, unless you're the video owner, then you can download it from the YT Studio. I don't know why YT does provide an option to use CC license on videos published on YT, but doesn't provide a way to download CC videos for anyone. Polda18 (discussioncontributions) 13:21, 29 April 2022 (UTC)Reply

@Polda18 It works for me. Please verify with youtube-dl --version that you are using the latest version 2021.12.17. Dexxor (talk) 09:25, 30 April 2022 (UTC)Reply
@Dexxor: Even despite running sudo apt update and sudo apt upgrade youtube-dl, I still am running version 2020.03.24. Guess what?
$ youtube-dl -F dPZTh2NKTm4
[youtube] dPZTh2NKTm4: Downloading webpage
ERROR: dPZTh2NKTm4: YouTube said: Unable to extract video data
Still doesn't work. And I can't upgrade to latest version for some reason. Polda18 (discussioncontributions) 10:02, 30 April 2022 (UTC)Reply
If your distribution is Debian, you should try the version from Debian backports. youtube-dl updates often to catch up with Google changing YouTube. At the very moment, I cannot download anything because something changed again but I expect it to be fixed soon because it appears to be already reported and someone will look into it. Роман Рябенко (talk) 08:02, 21 March 2023 (UTC)Reply
Thank you for reply after a year when I completely forgot about this issue (unresolved, btw). It seems like Debian and Debian-based distros (like Ubuntu) have parts of their repositories outdated for some reason. I'll try to look into it. By the time between my issue report and your reply, I had my laptop in service being fixed as it failed to boot, which required fresh install of Windows on a new SSD, and then restoring lost data from the old SSD (which I still have in my laptop). The reason it couldn't boot was that Optane memory died, and it was in Raid with my SSD drive. So I recently installed WSL again, but not Linux yet. I'm thinking of switching from Ubuntu to another distro. I'll look into this and tell you if it works or not. Polda18 D C 11:03, 21 March 2023 (UTC)Reply
>It seems like Debian and Debian-based distros (like Ubuntu) have parts of their repositories outdated for some reason.
That's most of the repositories, because that's how Debian's repository model works. With a few exceptions, software in the Debian repos only really gets patches for security issue, there are no feature updates. Which means that the software in the repos is stable in the sense that there are no new bugs introduced with updates, but this model isn't good for software that gets broken regularly due to external factors, like websites changing in the case of youtube-dl.
Besides which, the youtube-dl project seems to have completely stopped making releases, as there hasn't even been one in for over a year. I've been using a youtube-dl fork called yt-dlp for quite a while now, and they put out releases fairly regularly. The best way to install (and keep it up to date) is using pip. Re-running the installation command will install the latest version. I've aliased it to "ytdlpupdate" in my .bashrc file to make it easy to update when I notice something's broken. --Veikk0.ma (talk) 04:26, 22 March 2023 (UTC)Reply
That makes sense. I might update the help page to accomodate for the change. Polda18 D C 06:17, 22 March 2023 (UTC)Reply

APIError: titleblacklist-custom-space edit

I'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)Reply

It should be just as easy to upload a video to Commons as it is to YouTube edit

You 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)Reply

👍 Nick Moyes (talk) 13:39, 23 September 2023 (UTC)Reply

Linux using VAAPI on Intel devices: Two passes not necessary anymore? edit

The 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)Reply

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)Reply
Return to "Converting video" page.