Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

twitter.com

Post reply on HN
Print view View original

161–166 of 166 posts

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#161

Post by btdmaster »

tsukikage wrote: post #82
btdmaster wrote: post #76

Earlier quoted context omitted.

> As a matter of policy (as well as legality), youtube-dl does not include support for services that specialize in infringing copyright. As a rule of thumb, if you cannot easily find a video that the service is quite obviously allowed to distribute (i.e. that has been uploaded by the creator, the creator's distributor, or is published under a free license), the service is probably unfit for inclusion to youtube-dl. D…

Copyright law only permits making copies of artistic works when you have license to do so. Youtube only permits use of content it serves in the specific situations described in its terms of service. All other use is prohibited. You can see the terms of service here: https://www.youtube.com/static?gl=GB&template=terms In particular, the first three points in the "permissions and restrictions" section explicitly prohib…

> as permitted by applicable law

YouTube's ToS does nothing to change applicable law, which was my stated question. What YouTube wants is not necessarily what the law says.

Besides, YouTube does not hold copyright on most videos, so their ToS does magically not allow them to claim copyright infringement.

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#162

Post by nyanpasu64 »

pabs3 wrote: post #100
sebzim4500 wrote: post #61

Earlier quoted context omitted.

I'm trying to get the thread model here. Is the concern that Youtube will inject JS into the payload which tries to break out of the youtuble-dl js sandbox using some zero day in whatever js engine they would use instead?

One of the reasons people use yt-dlp/youtube-dl (and nitter.net/etc) is to transform the modern proprietary JavaScript web into something more suitable for enthusiasts of the old document web and of FOSS. If the web switched to plain then yt-dlp/youtube-dl would become completely unnecessary. Your browser should not have to run JS to watch an embedded video.

On my Ivy Bridge laptop running Linux, enabling hardware video decode in mpv took installing one package and adding one line to mpv.conf. Enabling hardware decoding in Firefox took multiple attempts of Googling frantically, toggling flags in about:config, passing logging environment variables to Firefox, recording a Pernosco trace of multi-process communication, and even asking for help in the gfx-firefox Matrix chat where they pointed out I had disabled media.rdd-process.enabled causing Firefox to print a misleading error message in about:support saying HARDWARE_VIDEO_DECODING was available, but failing at runtime saying WebRender was disabled even though it was enabled. And to my knowledge, hardware decoding in Chromium is simply not possible on Linux right now (maybe possible on Chromebooks, I haven't checked).

Even after I fixed hardware acceleration, playing a 1080p YouTube video in Firefox using hardware H.264 decoding took more CPU energy (40% of a core) than playing the same video in mpv using software H.264 decoding (20% of a core). Web browsers are just horrifically complex, intractable to understand, and inefficient.

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#163

Post by nyanpasu64 »

_pn3l wrote: post #84
blast wrote: post #70

Earlier quoted context omitted.

I suppose this means it would be easy for YouTube to fuck with youtube-dl simply by throwing in more features of JS?

Cat, meet mouse.

It's unfortunate, https://github.com/mpv-player/mpv/issues/8655#issuecomment-1...:

> Youtube now throttles requests of more than 10MB at a time, yt-dlp works around it by making many requests of 10MB using Range HTTP headers (yt-dlp calls it the http-chunk-size), but ffmpeg which does the downloading for mpv doesn't support that yet.

I want to change mpv or yt-dlp to support range-based video URLs (eg. appending &range=333999644-335298975&rn=5&rbuf=0 to URLs) which speed up stream seeking and probably eliminate throttling altogether, but I haven't taken the time to look into how to achieve it. For anyone interested, I have an open bug report at https://github.com/mpv-player/mpv/issues/10601, and have found https://satadalsengupta.github.io/docs/papers/2017_nossdav_y... describing these parameters.

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#164

Post by sylware »

kelnos wrote: post #109
userbinator wrote: post #83

Earlier quoted context omitted.

That's beside the point. Open-source is not useful to the smaller players if it is too complex to comprehend and constantly churned.

That's not the case, though. There are even python modules that let you evaluate JS code in v8 (Chrome's JS interpreter). It'd be pretty trivial for youtube-dl to make use of that if the author thought it was worth doing.

It is the case, not too mention v8 pulls in an extremely expensive c++ compiler in the SDK while quickjs can compile with tinycc.

Open source is not enough anymore, "lean" open source is the way now, SDK included.

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#165

Post by sylware »

ganjatech wrote: post #140
axiolite wrote: post #123

Earlier quoted context omitted.

> quickjs from M. Bellard and friends Is the M key next to the F key on your particular keyboard by chance? Because I've always called him "Fabrice." https://en.wikipedia.org/wiki/Fabrice_Bellard

Monsieur Bellard - M. Bellard

Yeah... M = Monsieur (in french, namely Mister in english), I forgot the 'r'... I should have written Mr. Bellard, I kneel upon the weight of my apology.

Re: YouTube-dl has an interpreter for a subset of JavaScript in 870 lines of Python

#166

Post by boogies »

ciupicri wrote: post #152
Tao3300 wrote: post #133

Earlier quoted context omitted.

Citing the guidelines is against the guidelines, if not by the letter, in spirit. It's boring and it lacks curiosity. It assumes too much about the sharer. "Can we stop this trend" is a dog whistle for the "HN is getting worse" complaint. Instead we could be considering if we're meant to read the Twitter conversation as well, or sharing a laugh about the link in the tweet author's bio. Or maybe the sharer didn't feel…

How can I read the Twitter conversation when Twitter asks me to log in? :-)

With Nitter: https://github.com/zedeus/nitter/wiki/Instances https://github.com/zedeus/nitter/wiki/Extensions
Post reply on HN