I'm using yt-dlp, and a very small change really made me go "cool" is
Color numbers..
I just wish for functions I could pick mid 720p'ish as a setting that includes audio+video, and not have to pick the audio and video formats. Theres a worst and a best option, but I'd want a middle quality to save space.
This has a few issues, I think. For example, using bestvideo prevents you from downloading formats that contain both video and audio, it only downloads video-only formats.
> otherwise download the best available
This will potentially download much higher than 720, if 720 is not available. Probably better to go lower for OP's usecase.
See my sibling comment for a better format selector.
Massive thank you to the original author and the original youtube-dl. Wonderful piece of software!
However it's been too long - isn't yt-dlp very far ahead and much healthier in it's organization _today_? Also the insistence of using a dead version of Python is pretty strange and will probably hamstrings the efforts for very minimal gains.
I would think a great place to see changes would be to go see what yt-dlp has been up to during the time of prior management because it certainly works better currently. Surely it wouldn't be too hard to pull some of those changes over.
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.
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.
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).
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.
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.
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.
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 have no idea what the code looks like for ytdl, but the concept seems straightforward enough for DASH/HLS segmented encodes. Determine the duration of each segment, do the math to find which segments would be required for the requested part, then do ytdl magic. I'd be more than happy to be forced to have a few seconds before/after the requested time just to avoid the necessity of breaking segments. Just straight download/concat.
We all know how well concept to working code goes though
Used it today for downloading some of Red Bulls content showing human pushing their body to the max. Those base jumpers in flysuits are so crazy I actually think about doing it myself. Flying as a pink elephant in the weekend.
This is a post about youtube-dl. Why are nearly all the comments about yt-dlp? If I didn't know better, I'd think yt-dlp users have massive inferiority complexes because they never seem to miss an opportunity to attempt to recruit everyone else to be just like them, even shamelessly trolling the announcement. When did this turn into Ford vs. Chevy?
Trolling? Some are commenting that keeping the project alive to support old versions of python seems like a weak reason, which is a fair criticism IMO.
My apologies, I didn't remotely intend to suggest every single comment was a troll, but only that there are yt-dlp users that have trolled that thread.
The criticism of supporting python2 is fair, but not unassailable. I am personally against steady progress necessarily breaking in advancing increments things that worked years ago. My opinions on software are my own, but I strongly believe if software works even once, there's no reason it shouldn't work forever. I despise Adobe's and now Apple's models of breaking your old software to force you to purchase again for identical functionality. But I suppose it is a different case when developers are actively working against each other. However, python2 was only recently deprecated. Just because I can't think of an example, it is still likely being used, and there may be 20yo but still useful hw somewhere that does not support any recently released OS or software but is still a worthy youtube-dl utility. Maybe the critics of supporting old versions of python can wait.
Depends on what you mean by "recently". Python 2 has been EOL for over two years now. The lowest version yt-dlp supports, Python 3.6, was released five years ago, and I would say it's a pretty usable version. The only reason it even took so long for Python 2 to become EOL is because people kept dragging out the transition from Python 2 because of a few annoyances in initial versions of Python 3 that were mostly addressed by 3.3-3.4 or so.
I just wish for functions I could pick mid 720p'ish as a setting that includes audio+video, and not have to pick the audio and video formats. Theres a worst and a best option, but I'd want a middle quality to save space.