31–40 of 62 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 '
CLIs are terrible for people not familiar with CLIs. I love 'em, but GUIs exist (and persist) for good reasons.
I wish any of the projects would implement a feature to download parts of a video. Currently that's not possible Request is open since 2013 https://github.com/ytdl-org/youtube-dl/issues/622
We all know how well concept to working code goes though
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
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 require…
Earlier quoted context omitted.
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).
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.
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
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.