Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation suggestions #1743

Closed
tukkek opened this issue Nov 9, 2013 · 4 comments
Closed

Documentation suggestions #1743

tukkek opened this issue Nov 9, 2013 · 4 comments
Labels

Comments

@tukkek
Copy link

@tukkek tukkek commented Nov 9, 2013

Hi! Really great tool and really great documentation - so much that I wanted to report a few things to help make it perfect :)

  1. The --autonumber-size description mentions '--autonumber' but the correct form seems to be '--auto-number'
  2. Would be nice to have info on what is the default behaviour: --continue or --no-continue

Thanks a lot! By the way it would be awesome to have a quick overview guide of how the code works!!

jaimeMF added a commit that referenced this issue Nov 9, 2013
it's '--auto-number' not '--autonumber'
@phihag
Copy link
Contributor

@phihag phihag commented Nov 9, 2013

Thanks for your suggestion, this has been fixed. As to your second point: The default is whatever is "best" for most users (same goes for the default filename format, by the way). For example, we may detect that continuing a download is unlikely to work (say, because an IP address has changed, or the service re-encodes the video every time), or some crazy service penalizes continuation downloads and then we'd switch to no-continue. So unless you need a certain option (say, you know that the service is allowing continuation downloads, but youtube-dl doesn't detect that, or you don't want continuation downloads because you're behind a proxy which doesn't suppor tthat), just pass in neither.

When youtube-dl, it creates a YoutubeDL object, which managees the whole execution. It then asks all InfoExtractors (one or more per supported service) whether they support the given URL. For example, a Youtube playlist URL would be handled by the YoutubePlaylistIE. The extractor finds out the URL of the video file as well as a bunch of meta information such as title, text, description, uploader etc. . This information gets handed over to a downloader which downloads the file to disk. If the user asked for it or it is necessary, we may also reencode the file with a so-called PostProcessor.

@phihag phihag closed this Nov 9, 2013
@tukkek
Copy link
Author

@tukkek tukkek commented Nov 9, 2013

Thanks again for the project, and for the response - I have been fiddling around since my post earlier today and it's nice to see how much attention you put in replying to the bug reports! I will post a new one following this, by the way.

About the second point: wouldn't hurt to say in --help that neither --continue nor --no-continue are default. Something like "youtube-dl may choose to use this option in certain scenarios" can go a long way to avoid confusion! Or maybe I'm just being picky :)

About the code overview: thanks a lot but I certainly failed to mention I was more interested in the YouTube URL generation - I understand they recently employed some encryption and a lot of software stopped working (like JDownloader and www.ssyoutube.com), which is why I found youtube-dl. I know it's probably not simple to overview it but I thought I'd take a chance in asking since I probably won't have time to read the source code (which I guess is a bit on the complex side)!

@phihag
Copy link
Contributor

@phihag phihag commented Nov 11, 2013

Thanks, added a clarification to the option. I guess most users do not have to pass in either of --continue or --no-continue.

@phihag
Copy link
Contributor

@phihag phihag commented Nov 11, 2013

The signature extraction code is fairly simple: At first, we look whether we have already parsed the signature function in our local filesystem cache. If not, we download the player code and interpret parts of it, either as JavaScript or as SWF. Interpretation entails what you would expect, we scan the code for interesting parts, parse them, construct an in-memory representation and finally run that.

phihag added a commit that referenced this issue Nov 11, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.