[Help needed] Merging pending changes from youtube-dl

[pukkandan]

Upstream commits that have not been merged

---

• [jsinterp] Improve parsing
  • The changes appear to be pointless?
• [ITV] Overhaul ITV extractor
  • Need help!
  • related ITV-X #5570
• [feat]: Add support to external downloader aria2p
  • We partially have a different implementation, but is broken. Need to fix it
  • No need to use aria2p, we can achieve same with websockets directly

[dirkf]

ITV extractor was based on the last yt-dlp PR and should be OK with these considerations:

• remove _sort_formats()
• tweak any removed compat_xxx
• optionally, delete _search_nextjs() shim in favour of yt-dlp native method
• possibly investigate if subtitles are available in the m3u8 manifest and use _extract_m3u8_formats_and_subtitles() if so.

If there is a test port or PR I could exercise it in the UK.

[pukkandan]

[jsinterp] Improve parsing

@dirkf Could you explain the point of the regex rework in jsinterp?

We don't have . implemented except for some specific cases. So this does nothing. Even if it were to be implemented, the method names are generally different b/w JS and Python. Some fields like split/search/flags etc will work, but the test seems to imply you are expecting the others as well?

Actually, none of YT players are actually using the regexes. We only needed to parse them out. The .compile can even be completely removed (possible speed improvement?)

The newly added replace also don't work. When passed a string "a".replace(".", "b"), JS interprets . literally, while the code considers it a regex. On the other hand "a".replace(\.\, "b") also doesn't work and raises error, since JS_Regex doesn't inherit from re.Pattern

[dirkf]

That was a bit of WIP, apparently, even though the specification of String.prototype.replace[All]() has all the logic and consistency that one has come to expect from Brendan's busy week.

The linked test was really checking that the SO hack behaved sensibly.

So far there hasn't been any use of replace() but if it happens there's now this: dirkf/youtube-dl@3be072e.

The .compile could indeed be lazy, like this: dirkf/youtube-dl@5f0eea7. It doesn't seem to affect the time for test/test_youtube_signature.py much: maybe 5% quicker. Py2.7/Py3.9 runtime ratio still ~1.6, though.