Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Please follow the guide below
xinto all the boxes [ ] relevant to your issue (like this:[x])Make sure you are using the latest version: run
youtube-dl --versionand ensure your version is 2017.10.01. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.i am on 2017.09.24, it seems macports hasn't added today's update to its repos yet. (i did run
youtube-dl -Uand it told me to run macports' update procedure, which itself says everything is up to date. so. there you go.) that's unsurprising given there's been less than 24 hours for them to add it.however, the question i'm asking about has been the case for at least 2 years, and i see no other raised issues about this, so i doubt this matters too much.
Before submitting an issue make sure you have:
What is the purpose of your issue?
The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue
hi, first off i want to say, i apologise if this has been answered already. i searched the github issues for "1080p", but couldn't find anything actually telling me why this is the case.
i'm curious as to why the automatic detection in
youtube-dl -Ffor the best quality seems to top out at 720p? even when 1080p or higher is available, it insists one of the 720p options is "best".it seems like this heuristic prefers files that are audio+video together, and all 1080p or higher streams are listed as "video only", even though muxing together formats after download is completely fine and is what youtube-dl actually does in practise anyway.
this strikes me as extra weird because youtube-dl does in fact download the 1080p version with separate audio (then muxes) when you give no flags. maybe this is simply a case of
youtube-dl -F's display lagging behind actual behaviour?i saw someone mention this in 2015 in a stackexchange thread, though that person said you need to specify the 1080p stream to get it to download, so obviously something about this has been changed since then.
thanks in advance for your time and answer c: