In the case of youtube-dl, they couldn't do that. At least VEVO videos have an additional layer of "protection" — the direct links to video files require a signature of some sort IIRC. Downloading a non-DRM-ed video is as easy as making a request to https://www.youtube.com/get_video_info?video_id=aqz-KE-bpKQ and then following a link to the format you need, but with those music videos, that won't work. So the test cases were a necessity.

Hmm, are you sure that link is correct? In firefox and chromium that gets me about 122K of not-very-easy-to-parse text.

Yes, it's correct and it should return that. The top-level serialization format is simply a URL query string aka application/x-www-form-urlencoded. No idea why but probably historical reasons.

So what do I do next?

In ruby:

  require 'cgi'
  require 'json'
  require 'net/http'
  res = Net::HTTP.get URI 'https://www.youtube.com/get_video_info?video_id=aqz-KE-bpKQ'
  vars = CGI.parse res
  json = JSON.parse vars["player_response"].first
  pp json["streamingData"]["formats"]

Hi Kim!

They couldn't have done this. The 'infringing' links were in the test suite and were specifically tests for content from particular sources which had special links which required different techniques to download them.

The test would not have been accomplished if they were pointed at links which didn't have the behaviour that was being tested.

Curious to know if it was not possible for YouTube-dl to create content which was ‘similar’ to the infringing ones & upload it on YouTube for their test cases?

AFAIK the features they're testing are only available to specific partners. I can't be sure, but it isn't obvious how they could go about doing this.

Or they could have had the YouTube links in another file, not part of the repo, and only download and parse it when tests are run.

Best thing would be for them to just upload their own test videos with the various formats and test against those.

Most of this comment chain has been about why they couldn't do that. They were testing against special features that are only available to select partners.

One solution would be to load those links from environment variables, similar to how it's done with API access keys and other sensitive data. This would mildly inconvenience the devs by having to copy the links to those types of content by hand and set the vars before running the tests, but none of the "infringing" links would be present in the repo itself.

Hi Nullc, long time no see! :-) And shoot, that is annoying.

It makes for really bad optics though. Gforz's suggestion to upload test video with similar parameters is -in 20/20 hindsight- probably the better plan. Definitely better than giving bad ideas to copyright lawyers.

Let's see what happens and whether indeed these lessons have been learned.

* https://github.com/Larry850806/youtube-downloader/issues/1

* https://github.com/Athlon1600/youtube-downloader/issues/81

* https://github.com/ZerioDev/Youtube-Downloader/issues/2

I think to take your lessons from the pretexts is like judging a war by its casus belli.

The smart thing would have been to always filter by CC. And then anyone who can type # could just modify their source code a bit to adjust the filters.