Hacker News new | ask | show | jobs
by maxnoe 1599 days ago
The reason to continue the project and not focus together on the more maintained fork [1] is to keep support for python 2.6 and 3.2?

In 2022?

For a thing that is made to talk to the internet?

Python 2.6.7 was released in 2011. Python 2.x overdue EOL was in 2020. Python 3.2.6 was released in 2014.

That's has to be one of the worst reasons for duplicating efforts ever.

[1] https://github.com/yt-dlp/yt-dlp

5 comments

To play the devil's advocate… one of the uses of youtube-dl is to grab a video so it can be watched on lower-spec machines that might not be able to handle playing a YouTube video in a web browser. Such machines might also be stuck on older operating system releases which don't have easy access to cutting edge Python distributions.

That's just my guess at the logic here, anyway.

Yup, some of the volunteers at a school I help setup a solution to allow videos to be used in school.

Google is pretty lacking at offering meaningful content controls. We could easily get grants to pay a few thousand bucks for that. It’s weird they don’t considering their ownership of K-12 and potential for revenue.

K-12 is a loss leader, all to maintain a pipeline of future customers

Google Workplace and enterprise cloud is the priority to boost revenues.

As far as I know current Python distributions are pretty available for older systems.
If we are speaking current distributions, Python 3.9 actively refuses to install on Windows 7 and dropped the relevant compatibility code (though I think 3.8 might have had problems installing on it as well).
Windows 7 was also EOL in January 2020. I’m not sure I blame Python 3.9 for failing to support an EOL operating system either.
I don’t think this is a fault that you can blame the Python developers for, necessarily (indeed the end of support is exactly the reason given by the Python developers well in advance), but I certainly do think that it is a plausible scenario where you might end up being forced to use an obsolete version of Python as a result of the decision.

I also think that a curt “EOL operating system” dismissal has a problem that, taken to the extreme, it says that every software author would be justified in following the support schedule of any dependency, however inane that schedule is,—and there’s nothing in that dismissal that would prevenr it being taken to such an extreme.

That is not to say that running Windows 7 now is a particularly smart decision, no patches means no patches after all, no matter the marketing motivation behind that decision. I’m not even sure I’d call this particular part of Microsoft’s support schedule unreasonable. I am failing to find a legal, generally available, and supported Microsoft operating system I’d be willing to run, so one of those parts would have to be given up; but that is not the point.

The point is that there should not be a blank presumption that a vendor declaring EOL on anything at any moment is automatically reasonable and that it is right and proper to follow them. It certainly is simpler to offload that decision to them, but some sort of underlying sanity measure the result could be checked against ought to exist, and the parent comment (not that their stance is unique) is failing to provide any.

yt-dlp currently has no plans to drop support for Python 3.6, which became EOL a month ago. And Python 3.8 will be supported until October 2024.

On Linux (at least a regular x86/x86_64 machine, not sure about other architectures), you can generally easily install an up to date Python version with pyenv.

My personal machine is on Arch Linux (which recently moved to 3.10 without any major problems) and I know about yt-dlp, so I’m not having any particular problems here :) It’s just that the great-grandparent asked for plausible scenarios for using obsolete Python, and Windows 7 support immediately came to mind.
Running youtube-dl on Windows is solved by compiling the Python runtime in the binary itself. So... run it through Wine? /s
Yeah that’s completely nuts to me, I’ll continue to recommend yt-dlp for the significant future.
Is there any GUIs for yt-dlp?
Command is insanely simple (and I don’t use a lot of shells normally)

Copy your youtube url

Go to your command shell

yt-dlp -v pasted url

Watch the download. Done.

You'll want to surround the pasted URL with quotes, or else the question mark in all non-shortened YouTube video URLs will confuse the shell.

Also, I suggest adding `-f mp4` to avoid getting a video in Google's proprietary video format. (Yes, I know, but basically…)

yt-dlp -f mp4 'https://www.youtube.com/watch?v=dQw4w9WgXcQ'

MP4 (H.264/H.265) is the proprietary one. WebM (VP8/VP9) is open and royalty free (as is the upcoming AV1).

Less commonly supported though, most notably by Apple and some TVs (quite import for that use case).

Depends on who you ask. ISO and ITU would insist that VPx are the proprietary (read: non-standard) ones, which is a different sense of proprietary from what you're using (read: costs money to use).

The whole video codec industry was predicated upon a particular licensing structure where everyone was paid to participate in ISO/ITU codec development in exchange for patent ownership over the final standard. That's why Apple never touched VP8/9 - decode blocks for ISO-standard codecs were very plentiful and very good, compared to those you could get for royalty-free Google ones.

Of course, nowadays the ISO/ITU business model is broken[0], so maybe the actual standards will move towards "royalty-free by default". Or AOM codecs will outcompete ISO ones and they become the de-facto standard[1]. But I don't see that happening until and unless Apple actually ships AV1 hardware codec blocks.

[0] Specifically, a good chunk of HEVC patents are only available from a company called Access Advance, a patent pool that has overlapping membership with MPEG-LA's pool. Since there's an overlap, you have to pay for certain parts of HEVC twice, and Access Advance won't reimburse you for the duplicate license. They say you should ask MPEG-LA for a reimbursement, despite the fact that said reimbursement would be more than you actually pay for MPEG-LA's half of HEVC.

[1] One of the founders of MPEG, Leonardo Chiariglione, is very outspoken that royalty-free codecs outcompeting FRAND codecs would mean the end of innovation in video coding. I personally find this a mistaken view (AOM's members were going to be doing the R&D anyway) but that's how the ISO/ITU people think.

Webm is quite a nice format actually, it's a subset of MKV that gave a good target for browser developers. The fact that patent-encumbered h264 is the only codec that is hardware-accelerated across devices is an entirely different issue.
mp4 files returned by youtube are of a lower quality than webm files.
This is one of my favorite things I don’t have to worry about with zsh + oh-my-zsh, pasted URLs being auto quoted.
Unquoted URLs with '?' work fine in bash. It's not like it's common to have files named with a URL that could confuse a glob expansion.
you'll also want to cd to the correct folder because you probably don't want it to go in ~ or some other random location depending on what terminal you launched and how you launched it.

CLIs are terrible for people not familiar with CLIs. I love 'em, but GUIs exist (and persist) for good reasons.

With yt-dlp, you can use something like `-P /home/username/Downloads`, and you can even put that in your config so you don't need to manually specify it every time.
youtube-dl gui allows to queue urls though, convenient
A small project of mine: https://github.com/database64128/youtube-dl-wpf

It uses WPF so it can only run on Windows though.

I tried https://github.com/axcore/tartube some time ago and it worked. I mostly use the command line though, it’s really simple.
https://www.svp-team.com/wiki/Manual:SVPtube

Paid generally but there's a legacy free version for YouTube and Vimeo it says.

Search for yt-dlp on flathub. There was a GUI for it, but it is too generic to remember it now. VideoDownloader?
One of the primary, if not the most important, youtube-dl use cases is older computers and older installs that cannot handle modern youtube javascript. By not running javascript at all most of the security issues on the modern web can be mitigated. There are lots of responsible people out there running old software. And even more people who are just poor and can't afford the new hardware required for new OSes required for new browsers.
Exactly. I still supported Perl 5.005 with a number of my projects for precisely that reason. Even now I still try to target around 5.6 or 5.8, despite being quite old.
Maybe. But who cares? It's an open source project, if someone wants to maintain support for older software, good for them. If people don't like it they can fork and move on (and they have).

I don't understand the complaints and attacks in the github comments. It seems bizarre and egotistical to me to yell at a stranger who is providing you their work for free because you don't agree with their specific use case.

I think the original project isn't actively maintained any more:

https://github.com/ytdl-org/youtube-dl/graphs/commit-activit...

910 PRs, but only 3 commits to master since July 2021.

You commented this on a post literally just explaining the project has a new maintainer as of six hours ago.
Maybe the post is too nuanced.