[hnlmorg]

> Not true at all, most YouTube videos are offered as plain webm files.

It's been a while since I've written a video streaming scraper but it used to be quite common for a file to be served over HTTP but that file was a small "shortcut" type file to an RTMP stream. So a webm file wasn't the content itself but instead a pointer to where to stream the content from.

I'd imagine the same would still be true for YouTube since, like most other video streaming services, YouTube can adaptively switch bitrate depending on the bandwidth available to the end user. That seamless switching can't be done with a HTTP GET of a singular video file but it can happen effectively with a chunked streaming protocol.

> Also, keep in mind that recording TV's is legal.

Yes but with caveats, depending on the country.

Though it is worth noting the only reason America and UK law is so relaxed regarding VCR usage is because corporations making video recorders were taken to court by film studios and won their case. So once again it comes down to presenting a legal argument rather than a technical one.

[dylz]

This hasn't been the case in a long time, most streaming sites no longer do RTMP unless specialised cases, because of scaling and ease of scaling. They're mostly HLS or equivalent now.

[hnlmorg]

Ah yes, I'd forgotten about HLS (doh!). But even there HLS, while based on HTTP, is still very different to the kind of GET requests the GP (or however many posts down it was now) suggested when they talked about downloading a file.

HLS is not about downloading a file, it's about downloading chunked data. It wasn't intended (though it can't be prevented) that the chunks would be used to recreate a video in full, unlike with a stream of bytes from a HTTP GET which are very much intended to be recreated in full at the receivers end.

HLS really only uses HTTP transport as headers to circumvent many firewalls (and in fact you can do this with RTMP too, eg RTMPT) but aside from that it's a completely different beast to GET.