plugins.twitch: block ads using the same method as uBlock

[samfundev]

Implements uBlock's method of blocking ads on twitch. Which basically involves putting the platform=_ parameter in the access_token URLs. Doing that removes ad segments from the stream.

I removed the tests related to removing ad segments since that isn't done anymore. I'm not sure how I'd test the new way of disabling ads so I didn't add any tests.

Also closes #3120 as passthrough should now be compatible with disabling ads.

[codecov]

Codecov Report

Merging #3170 into master will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master    #3170      +/-   ##
==========================================
- Coverage   52.67%   52.66%   -0.01%     
==========================================
  Files         244      244              
  Lines       15636    15637       +1     
==========================================
- Hits         8236     8235       -1     
- Misses       7400     7402       +2     

[bastimeyer]

We've already had the platform=_ parameter added once and it worked for only a few days until Twitch made further changes.
#2358
#2357 (comment) (edit: wrong thread, we've had multiple thread, but I can't find the other one right now)
#2368
Then we removed it again:
#2692

Even if this seems to be working right now, I doubt that it will keep working.

If we decide to re-add this request parameter, then the only change should be the parameter itself (#2358), and the --twitch-disable-ads logic should not be removed.

[samfundev]

It does seem like the parameter isn't a very consistent fix, sorry I didn't see that. I've changed it so the only changes are adding the parameter if the user asks for ads to be disabled.

[laichiaheng]

It really needs to be merged as soon as possible, otherwise the low latency streaming with no ads is unusable.

[bastimeyer]

adding the parameter if the user asks for ads to be disabled

The twitch-disable-ads parameter shouldn't be checked here, because its purpose is to change the HLS client logic. Acquiring an access token and setting the platform=_ request parameter however should also work when the user is querying the resolved HLS stream URL when setting the --stream-url or --player-passthrough=hls parameters for example, which means the platform=_ request parameter should be applied in all cases (see 1bb3f86). Please fix this, otherwise I'll have to re-apply 1bb3f86, which I don't want to do because you made this suggestion of (re-)adding the request parameter. Thanks.

otherwise the low latency streaming with no ads is unusable.

Not true. The LL streaming still works fine when there are preroll ads.
See #3120 (comment)
I've submitted #3169 yesterday with a fix for that incorrect info log message, but it hasn't been reviewed yet. Just ignore the incorrect info message for now.

[laichiaheng]

adding the parameter if the user asks for ads to be disabled

The twitch-disable-ads parameter shouldn't be checked here, because its purpose is to change the HLS client logic. Acquiring an access token and setting the platform=_ request parameter however should also work when the user is querying the resolved HLS stream URL when setting the --stream-url or --player-passthrough=hls parameters for example, which means the platform=_ request parameter should be applied in all cases (see 1bb3f86). Please fix this, otherwise I'll have to re-apply 1bb3f86, which I don't want to do because you made this suggestion of (re-)adding the request parameter. Thanks.

otherwise the low latency streaming with no ads is unusable.

Not true. The LL streaming still works fine when there are preroll ads.
See #3120 (comment)
I've submitted #3169 yesterday with a fix for that incorrect info log message, but it hasn't been reviewed yet. Just ignore the incorrect info message for now.

I saw another thread said that it was a player problem, but MPV didn't have this problem with streamlink, why?
Did Twitch change something?

[bastimeyer]

This is unrelated to this PR and shouldn't be discussed here.
I've also answered this plenty of times.
#3165 (comment)

[samfundev]

My apologizes, I was busy yesterday but I'm glad this got fixed.