YouTube slows down video transfer rate - wrong DASH video url?

[Isayso]

Version

6.03

Details

I use vlc or Kodi to play the DASH streams extracted with YTExplode and found an unusual behavior. When I play two in a row in a playlist, the 2nd stops all the time and waits for the stream data. I thought it was Kodi or vlc related but I found a discussion about this in the youtube-dl area.

ytdl-org/youtube-dl#29326 (comment)
ytdl-org/youtube-dl#29326 (comment)

Please take a look into this. If I understand this correctly, the video url must be calculated/altered to avoid active throttling from youtube (?)

Steps to reproduce

Please read the discussion from the link above

[Tyrrrz]

Are you experiencing slow transfer rates when passing the URL to somewhere or also when you're downloading/streaming a video using YoutubeExplode's own methods (i.e. StreamClient.GetAsync(...) & StreamClient.DownloadAsync(...))?

[Isayso]

When I pass the URL to an other program like VLC, the first is running most of the time with the usual speed. If I try to play the next video, the VLC player stops (for buffering) very frequently.
The Kodi Youtube addon has the same issue and it is discussed here

anxdpanic/plugin.video.youtube#163

The performance of YTExplode is ok, if I understand the discussion of the Kodi addon right, the video URL needs some additional parameter to tell Youtube not to slow down the internet connection speed (?)

The YouTube addon of Kodi ist not useable anymore if you want to play more than one video in a row.

[derech1e]

I recognised a similar issue (maybe the same) with the YoutubeDownloader. Sometimes videos in the webm container takes forever to download. I also couldn't really figure out why it is so, because when I tried to downloaded the same Video with the mp4 Container, it worked perfectly.

[Isayso]

Download is affected in the same way. First video fast, 2nd very very slow

[StefH]

Hello @Tyrrrz,

I've created a POC/workaround/fix for this issue.

My solution is based on this PR (--> descrambling the n query parameter) fent/node-ytdl-core#1022

Note that this a JavaScript project, so I've used https://github.com/paulbartrum/jurassic to evaluate the JavaScript.

1️⃣
I modified a small part of code to save the base.js to disk and reuse this later.
(https://github.com/StefH/Blazor.YouTubeDownloader/blob/1a97dc4e57be74c81d7c052748107a4706057312/YoutubeExplode-master/YoutubeExplode/Videos/Streams/StreamClient.cs#L194)

2️⃣
The code which parses the base.js to extract the JavaScript code responsible to decode the n:
https://github.com/StefH/Blazor.YouTubeDownloader/tree/main/YouTubeUrlDecoder

3️⃣
My example console app which calls all code:
https://github.com/StefH/Blazor.YouTubeDownloader/tree/main/YoutubeExplode.DemoConsole

❗
Note that this is just a POC, if you have more questions please ask these here.

Link to:
ytdl-org/youtube-dl#29326

[StefH]

I just created a work-around NuGet ...
https://www.nuget.org/packages/YoutubeExplode.Extensions

var streams = await streamClient.GetManifestAndFixStreamUrlsAsync(videoId);

But I guess I'll wait for the PR...

[Tyrrrz]

Hello @Tyrrrz,

I've created a POC/workaround/fix for this issue.

My solution is based on this PR (--> descrambling the n query parameter) fent/node-ytdl-core#1022

Note that this a JavaScript project, so I've used paulbartrum/jurassic to evaluate the JavaScript.

1️⃣ I modified a small part of code to save the base.js to disk and reuse this later. (StefH/Blazor.YouTubeDownloader@1a97dc4/YoutubeExplode-master/YoutubeExplode/Videos/Streams/StreamClient.cs#L194)

2️⃣ The code which parses the base.js to extract the JavaScript code responsible to decode the n: StefH/Blazor.YouTubeDownloader@main/YouTubeUrlDecoder

3️⃣ My example console app which calls all code: StefH/Blazor.YouTubeDownloader@main/YoutubeExplode.DemoConsole

❗ Note that this is just a POC, if you have more questions please ask these here.

Link to: ytdl-org/youtube-dl#29326

Thanks for the tip.

According to the comment here, it seems an alternative workaround is to mask requests with Android user agent. I suggest we do that first and leave the n parameter handling for later because it seems a lot more complex.

#601 (comment)

Open to PRs.

[Isayso]

to test it, I need a nuget package. So when you get the video url disguised as an Android device, you get a working link with the right n parameter? (Unfortunately I have not much time these days)

[Tyrrrz]

to test it, I need a nuget package. So when you get the video url disguised as an Android device, you get a working link with the right n parameter? (Unfortunately I have not much time these days)

Allegedly, yes.

[ricebl]

It seems the issue has already been pinpointed (to some degree) but I have noticed that even short videos less than a minute will take 15 minutes or more to download if I pick any quality above 480p as an mp4. Downloads still function so not a huge deal, but awaiting testing and updates.