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.
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.
That's just my guess at the logic here, anyway.
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.
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.
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.
Google Workplace and enterprise cloud is the priority to boost revenues.
Copy your youtube url
Go to your command shell
yt-dlp -v pasted url
Watch the download. Done.
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'
Less commonly supported though, most notably by Apple and some TVs (quite import for that use case).
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.
"Proprietary" means "owned by somebody who restricts access". Access, in this case, refers to rights to run encoders, and to deliver decoders. VP8, VP9, and AV1 are also defined by published and recognized standards, but are additionally not subject to restrictions on use. This has nothing to do with money, and suggesting it does is disingenuous.
Also, do you get that Apple's reasons for anything they choose are at best obscure, where not actually fraudulent?
We all can only guess at Apple's reasons for anything, even where they seem to say what their reasons are, because Apple is under no obligation to reveal the whole truth about their reasons.
That Apple does not support VPx and AV1 is more reasonably guessed, from observation of historical behavior, to be a consequence of their preference for proprietary, exclusionary business models, most probably because they better limit competition.
CLIs are terrible for people not familiar with CLIs. I love 'em, but GUIs exist (and persist) for good reasons.
Paid generally but there's a legacy free version for YouTube and Vimeo it says.
It uses WPF so it can only run on Windows though.
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.
https://github.com/ytdl-org/youtube-dl/graphs/commit-activit...
910 PRs, but only 3 commits to master since July 2021.