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

Youtube --prefer-insecure does not work correctly #3495

Closed
Crypto90 opened this issue Aug 11, 2014 · 7 comments
Closed

Youtube --prefer-insecure does not work correctly #3495

Crypto90 opened this issue Aug 11, 2014 · 7 comments

Comments

@Crypto90
Copy link

@Crypto90 Crypto90 commented Aug 11, 2014

Hi

The "-g --prefer-insecure" option does not work correctly anymore.
It switches from http to https in random order if I try to use it some times with the same link.

@Crypto90
Copy link
Author

@Crypto90 Crypto90 commented Aug 13, 2014

9bd7469903321784916952ee91f52d738e9e6861

@Crypto90
Copy link
Author

@Crypto90 Crypto90 commented Aug 29, 2014

Push

@phihag
Copy link
Contributor

@phihag phihag commented Aug 31, 2014

I fail to see why this is not the correct behavior.

--prefer-insecure is documented as:

--prefer-insecure Use an unencrypted connection to retrieve information about the video. (Currently supported only for YouTube)

I see nothing in your bug report that goes against this documentation. Note that although the extraction does not use HTTPS, the final URL may be only available over HTTPS, and YouTube has started doing exactly that.

Can you elaborate on the context of this bug report? Why are you using --prefer-insecure in the first place? It sounds like you are not interested in HTTP debugging (that's what the option is for), but an HTTP URL.

As mentioned above, I can see no sign that --prefer-insecure does not work here, so I'm closing this issue. If you provide context, we'll reopen it.

@phihag phihag closed this Aug 31, 2014
@Crypto90
Copy link
Author

@Crypto90 Crypto90 commented Sep 1, 2014

Yes its documented like that. So whats with this older discussion?:
#2364

Not every player supports https links.
Whats with this --play option thats suggested there? Any news about that?

@phihag
Copy link
Contributor

@phihag phihag commented Sep 1, 2014

As the discussion says, you can simply use -o -, like this:

youtube-dl http://www.youtube.com/watch?v=BaW_jenozKc -o - | mplayer -

Since --play would not (at first) be anything more like that and there are plenty of other issues that I find more important, I think the above should be a sufficient workaround.

@Sepulep
Copy link

@Sepulep Sepulep commented Sep 4, 2014

I have also encountered the same issue. I think it is still worthwhile to get the http link if possible (and it should be mostly; because as Crypto90 mentions, the issue happens intermittently, the same query sometimes resulting in http and sometimes in https..). The problem with using the pipe is that it adds overhead (important for embedded and less powerful systems, like openpandora and raspberry pi) and problems with seeking and playlist support of mplayer.

@Crypto90
Copy link
Author

@Crypto90 Crypto90 commented Sep 10, 2014

I solved it to implement the ssl support to the player.
I think youtube will mostly change everything to ssl. If not, I don't get the point why we get sometimes http and https results.

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
3 participants
You can’t perform that action at this time.