youtube-dl (and yt-dlp) has a flag, I believe -G, which gives you the URL(s) for the requested format/quality. I used the command line on my computer and put the link in VLC. On my phone I had this elaborate workaround involving downloading the file to my VPS first over SSH, then downloading it to my phone, until I realized my phone browser can consume the URL directly, so I set up a PHP frontend for `youtube-dl -G -f bestaudio {url}`
It's no longer online and I lost the code, but it was like one line of code.
I mention this because you-get seems to support the same usecase (via --url / -u), so I wanted to let people know how useful this is!
(While it was online I shared it on some forums and got very positive feedback, people used it for audiobooks etc.)
[0] Also playing with screen off saves 80% battery life! YouTube knows these facts and that's why they made background playback (which fetches only audio stream) a paid feature...
For others: Settings > Media > Enable Background Audio
My mom is really into audiobooks and I made telegram bot for her via node-red where she can share youtube links. The links are sent to a fifo where a little daemon (1) downdloads them sequential and saves them into an incoming folder I setup for this special purpose. The bot can either download only audio (for her telegram ID its only audio) or complete videos.
This folder is watched by jellyfin which she can access to download or listen. She loves it and in two years she downloaded way over a TB of audiobooks.
1: https://gist.github.com/entropie/d265e94136b9777cc6b3190189b...
Also 144p is somehow so peaceful and relaxing to watch, you don't get distracted with all the shiny colors and intricate details in the video and can just listen and not have your mind focus on some random stuff.
I mainly use this to play membership only videos that don't play in the background even if you have a Youtube Premium.
Every IOS version I pray that they don't patch this "glitch".
--extract-audio
--format bestaudio
--audio-format mp3
> Some people don't want [...] mp3
Or when you keep using an old mp3 player from the early 2000's.
Under the hood, there's probably an additional lossy conversion. I'm not sure if YouTube converts uploaded videos to specific formats but if they do, then the worst case scenario is:
- original uploaded video uses .ogg audio
- YouTube converts that to opus and puts it into a container format (wbem?)
- You download the video and extract the audio to .m4a using yt-dlp
- and then you convert that to .mp3 using ffmpeg
That's 4 consecutive lossy formats, each one throwing away different data.
Honestly the best thing to do here is use yt-dlp to download whatever format YouTube provides and use ffprobe to find out what audio format is already there. Then do one conversation if required.
ytdl-format=bestaudio[ext=m4a]/bestaudio[ext=webm]/bestaudio
vo=null
The advantage is that you're setting this for a utility which can play media directly (e.g., you don't have to separately download and then play content), and that you can set preferences independently for mpv vs. other tools.You can also of course configure your own aliases, shell functions, shell scripts, or config files for various preferred configurations, whether using mpv, ytdl, or other tools.
> If you would like to report a problem you find when using you-get, please open a Pull Request, which should include [snip]
Can't say I've encountered this before.
A detailed description of the encountered problem;
At least one commit, addressing the problem through some unit test(s).
Examples of good commits: #2675, #2680, #2685
"Addressing" is probably a bad word to use here. "Demonstrating" would have been better, IMO.i’m almost tempted to add a test suite just to give people more agency over my output because right now i’m only soliciting feedback in person to cut down on internet bullshit, like what happened to xz-utils
`you-get` is currently experimenting with an aggressive approach to handling issues. Namely, a bug report must be addressed with some code via a pull request.
https://github.com/soimort/you-get/commit/75b44b83826b3c2d9a...Maybe they got too much spam.
By the way, `tests/test.py` seems to just run the extractors against various websites directly. I can't find where it's mocking out network requests and replies. Maybe this is to simplify the process for people creating pull requests?
Though what I'm unsure how to deal with is legitimate users being idiotic. For example, recently one issue was opened that asked where the source code was. Not only was there a directory named "src" but there were some links in the readme to specific parts. While I do appreciate GitHub and places like hugging face [0], there are a lot of very aggressive and demanding noobs.
I'd like ways to handle them better.... I'm tired of people yelling at me because 5 year old research code no longer works out of the box or because you've never touched code before.
[0] check any hugging face issue and you'll see far more spam. Same accounts will open multiple issues that just barate owners and hugging face makes it difficult to report these accounts.
It addresses the specific issue but does nothing to prevent future similar issues. A solution to a cold is not handing someone a tissue.
I like that these platforms are open to everyone but at the same time there are a lot of people who have no business participating. Being able to filter those people out is unfortunately a necessary tool to not get overloaded.
Worse, I find that due to this many open source maintainers and up being quick to close issues and say rtfm. I can't tell you how many times I've had this happen where in my opening issue I quote the fm and even include a reproducible test. It's also common to just close and say "not our problem".
Or, you know, the user is not a developer. Or is unfamiliar with Python, or their test suite, or git, or…
It is perfectly possible to be good at reporting bugs but be incapable of submitting pull requests.
By asking users to provide reproducible test cases, you can massively reduce the amount of work you have to do. Of course that means 90% of bugs will never be reported. But since you don't have the resources to fix them anyway, why not just focus on the bugs that can be reproduced and come with a test case...
It’s your prerogative if and how you want to limit the amount of people who can contribute, but I was explicitly replying to someone claiming that a person’s inability to code is in any way related to the validity or importance of the bug.
https://github.com/soimort/you-get/pull/2680/commits/313b8d2...
You do not need to know Python deeply to construct what they are expecting. They’re not actually looking for a unit test or something.
I did. And I looked at all examples of “good commits”, not just the trivial ones.
https://github.com/soimort/you-get/pull/2685/files
That’s already complex for someone unfamiliar with the software (which might nonetheless be able to open a competent bug report).
Perfectly fine rule for a maintainer to have.
How do you currently submit bug reports on e.g. MS Word or Adobe Photoshop? This way is certainly more open than those commonly-deployed software.
What you're saying is even worse, since you’re implying someone could be an expert computer programmer or power user, but because they’re unfamiliar with the specific language this project chose, they are incapable of making good bug reports. That makes no sense.
There are other cases where Goodharts Law fails as well: consider quant firms, where the "metric" used to judge a trader is basically how much money you pull in. Seems to be working fine for them
Seems to make sense
I know how to make an isolated virtual environment, install the package, make a fork, create a test and make a PR. But I don't know whether I care enough about a random project to actually do it.
If this results in the project being easier to maintain and being maintained longer, then I’m fine with this.
Relative to what? Learning someone else's code base well enough to write a useful test is not trivial.
It's not a bad method, but the vast majority of users won't be capable of writing a test that encapsulates their issue.
Provided the maintainer is willing to provide some minimal guidance to issue reporters who lack the necessary know-how, it even seems like a clever back door way of helping people learn to contribute to open source.
you-get: [error] oops, something went wrong.
you-get: don't panic, c'est la vie. please try the following steps:
you-get: (1) Rule out any network problem.
you-get: (2) Make sure you-get is up-to-date.
you-get: (3) Check if the issue is already known, on
you-get: https://github.com/soimort/you-get/wiki/Known-Bugs
you-get: https://github.com/soimort/you-get/issues
you-get: (4) Run the command with '--debug' option,
you-get: and report this issue with the full output.
Tried with debug flag but didn't really help pattern = str(pattern, 'latin1')
^^^^^^^^^^^^^^^^^^^^^^
TypeError: decoding to str: need a bytes-like object, NoneType found
I was curious to see if it can bypass age restriction (though I tried on non-age-restricted video too with the same error).Try switching to the newest version of Python with something like Pyenv, or even try spinning up a Docker image with something like:
docker run -it -v $(pwd):/mnt python:3.13 bash
...and try using the utility there. Good luck!
https://github.com/soimort/you-get/blob/develop/src/you_get/...
Though there are some cases where using pure ffmpeg is just to difficult or impossible. Recently i had such a case where I wanted to merge multiple video files from my GoPro (they come out in 4GB parts if the video is longer than that), but while keeping / correctly merging all metadata such as date / accelerometer / gps / any custom binary streams. Ended up using this and worked great https://github.com/gyroflow/mp4-merge
(Also, a multitude of tools isn't really all that helpful if they all stop working in the same instant because they all relied on the same APIs etc)
The project was started in 2012, long before yt-dlp (but not before youtube-dl)
The fact you can download it with this tool is because the artist is letting you listen to it for free before buying it. Downloading it with this tool seems totally unnecessary and a bit of a jerk move. Bandcamp hosts mostly small and independent artists and labels.
And from personal experience I can say, sometimes people want or have to consume media offline, because of unreliable or slow network or expensive providers. But this doesn't mean that they won't pay later if they like it.
Personally, I consider it immoral to pirate Windows without a very good reason (which doesn't include "I like using Windows", or "I want to play game X" or "I want to use the enterprise version which doesn't have baked-in ads").
The same moral principles that argue against depriving people of natural property they already own do not imply further arguments against reducing sales opportunities for non-rival goods for which scarcity has been artificially established via positive law. Other, unrelated principles, can make for compelling arguments, but not the same ones.
I don't often read instruction manuals, but this time I did and I found this gross easter egg
https://addons.mozilla.org/en-US/firefox/addon/faststream/?u...
[1] https://github.com/yt-dlp/yt-dlp/blob/master/supportedsites....
there is some polish to the interface, so it might still be worth trying out if it does what you need it for.
Let's just not act surprised when tighter attestation comes in effect.
It is a dark future where some of us will accept it, and rest of us will be constantly taking part in a cat-mouse chase in which we glitch out attestation tokens from vulnerable devices to get by.
There are legitimate purposes for attestation; for instance, server attestation can allow a user to run software on a server and know that software matches a specific build and hasn't been subverted, so that the client can trust the server to do computation on the client's behalf.
But one of the leading uses of client attestation is DRM.
If I was forced to watch all the ads on youtube, i wouldn't watch videos there at all.
For YouTube you can pay for premium.
Consuming not only their resources but also their incredible streaming algorithm for free is just a dirty move.
Doing this just puts you into the statistic of bad users that incentives companies like Google to push more intrusive DRM. Which at the end of the day makes us all suffer.
Good luck finding an alternative by the way.
Now most of them are dead, twitter accounts removed, youtube videos deleted, facebook pages bought by media management companies, sites rebuilt etc.
Whatever the primary goal if this tool, it, and other similar tools, are invaluable in actually saving and preserving content