Side comment: when I watch YouTube content on my iPad, I normally use the Brave browser instead of the app. It has a built-in ad blocker that works well on YouTube.
Actually, the project started as far back as 2006 and moved to git in 2008, hence the first commit having that date. I don't remember the exact day I started the project, but on freshcode (formerly freshmeat), the first listed version is 2006.08.08.
youtube-dl -F VIDEO_URL will give you a list of formats in YouTube, that you can choose using the -f option. DASH streams contain only video or only audio normally.
If your phone supports OGG and you're downloading from YouTube, you can download format 171 (-f 171) and change the container to OGG with ffmpeg. That way you won't lose any quality.
If your music player supports OGG, you can also use youtube-dl -f FORMAT VIDEO_URL and give a numeric format that corresponds to a DASH webm audio-only stream, with vorbis audio (e.g. format 171 these days). The container is webm but it can be trivially changed to OGG with ffmpeg, which you can call via --exec automatically.
Edit: I mentioned that because you don't lose any quality reencoding.
As it was pointed out the first time youtube-dl was on Hacker News, our user base seems to be split regarding that behavior. When you copy a URL from a playlist, the URL includes both the video id and the playlist id.
Some people want to download the whole playlist when passing a URL from one of the videos (because otherwise it's hard to get an URL that contains just the playlist). Some other people just want to download the video they are currently watching.
That's why we have the --no-playlist option, which you can use and even stick in the configuration file. There's also --yes-playlist to override the configuration file if you need to.
Well, this is going to be more of a philosophical answer than a technical one: with the popularity of YouTube nowadays, which is available on every platform and allows for anyone, anywhere to instantly watch a video, the cat-and-mouse DRM game would not succeed. I think DRM is flawed (insert the typical lock-and-key analogy here) but it does work for some situations. For YouTube: probably not. Somewhere, someone talented would crack it and tools like youtube-dl would continue to exist. A recent example is youtube-dl using rtmpdump when available to download DRMed videos.
The current team should have more information, but I think most updates are due to other sites breaking and new sites being added that due to YouTube or bug fixes. I don't think YouTube is actively working against tools like youtube-dl, at all.
I agree. It's a consequence of the software being very volatile, having thousands of users and supporting so many sites. There's something to fix or to add every day.
It's very nice to see a project I started reach the front page of HN.
I remember starting the project around 2006. Back then, I had a dial-up connection and it wasn't easy for me to watch a video I liked a second time. It took ages. There were Greasemonkey scripts for Firefox that weren't working when I tried them, so I decided to start a new project in Python, using the standard urllib2. I made it command line because I thought it was a better approach for batch downloads and I had no experience writing GUI applications (and I still don't have much).
The first version was a pretty simple script that read the webpages and extracted the video URL from them. No objects or functions, just the straight work. I adapted the code for a few other websites and started adding some more features, giving birth to metacafe-dl and other projects.
The raise in popularity came in 2008, when Joe Barr (RIP) wrote an article about it for Linux.com.[1] It suddenly became much more popular and people started to request more features and support for many more sites.
So in 2008 the program was rewritten from scratch with support multiple video sites in mind, using a simple design (with some defects that I regret, but hey it works anyway!) that more or less survives until now. Naturally, I didn't change the name of the program. It would lose the bit of popularity it had. I should have named it something else from the start, but I didn't expect it to be so popular. One of these days we're going to be sued for trademark infringement.
In 2011 I stepped down as the maintainer due to lack of time, and the project is since then maintained by the amazing youtube-dl team which I always take an opportunity to thank for their great work.[2] The way I did this is simply by giving push access to my repository in Github. It's the best thing I did for the project bar none. Philipp Hagemeister[3] has been the head of the maintainers since then, but the second contributor, for example, was Filippo Valsorda[4], of Heartbleed tester[5] fame and now working for Cloudflare.
Wow. I was still using it to monitor new releases of iotop. I think this is going to be shocking news for anyone who was running Linux or BSDs in the early 2000s.
> It sets a bad precedent if government can dictate software features.
I don't think there's anything wrong with the government dictating software features for the software they want to use. If anyone doesn't want to implement a specific feature, that's totally fine. But their software won't be eligible for government use and working with official documents.
After all, it's public money and documents may better be saved in a good and properly documented format so anybody could, in theory, open them now or in the future.