YouTube Lua Video Lockup
When using the Open Network Stream function, video play randomly locks up at start up for prolonged periods of time or play parts and then pause with VLC 3.0.16 and youtube.lua version September 2021.
Below are samples of URLs that are locking up most of the time at startup. Sometimes these videos will play without locking up.
https://www.youtube.com/watch?v=A71DAC-9eTk https://www.youtube.com/watch?v=GjcJ8waHxnE
Activity
changed milestone to %3.0.x maintenance
added Component::LUA scripts label
In my experience, long YouTube videos take longer to load and start playing. I'm not sure why. How long does it lock up for? Does it eventually start playing, even if just stuttering the first seconds? One of these video does take a really long time for me to start playing; but this would be hard to reproduce for sure and diagnose exactly because it would depend on your location, which YouTube server you hit, your internet connection... My best belief is that it's not a problem with VLC or another client, but that the transfer from those servers for those videos is just slow, and it's not something we can really fix.
Please post full verbose logs so we can rule out a different problem, marking clearly where it hangs. To mitigate this, I would also suggest requesting a lower video resolution which will load faster, by setting in the preferences the "Input / Codecs" > "Preferred video resolution" parameter to something lower (or
--preferred-resolutionfrom the command line). Also consider downloading those problematic videos to your computer before playing them, using a dedicated tool such as youtube-dl: this will provide for a more comfortable playback and will save you from any buffering issue at start-up or when seeking.added Status::needs more info label
assigned to @lance78
vcl_log.txt Attached is the VCL log. The issue started approximately two weeks ago with some videos. The videos will randomly not play for approximately 1 minute at startup, then play for about 5 seconds, then lock up again for another minute.
Hello, I'm experiencing the same issue. I think YouTube has changed some of their transcoding technology in the back end. Over the past two weeks, I've experienced significant "decoding" issues for anytime of YouTube stream. I've tried every setting adjustment you can think of yet I still experience a significant starting lock-up at the start of every video with a hiccups every 5 seconds. I've also seen a ton of grey pixelation (regardless of the hardware decoding) setting over the past two weeks. **Something is up and I think the youtube.lua script needs some adjustment to fix the issue.
https://www.extremetech.com/computing/322198-youtube-designed-its-own-video-transcoding-hardware
Most common error log message I see is: "main input error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 1261 ms)"
youtube-dl users are reporting this issue as well. Appears as if youtube is throttling VLC. https://github.com/ytdl-org/youtube-dl/issues/29326
Looks like a fork (yt-dlp) has solved this issue for them. Hopefully the VLC will implement a fix as well.
@Courmisch This issue is catching steam... Any idea of where we go from here?
This issue is catching steam... Any idea of where we go from here?
Thanks everyone for your feedback. I'm sorry if I was a bit dismissive in my first reply, because I thought it was particular to certain videos, but I'm getting hit increasingly hard myself over the past days: I'm seeing ~ 80kB/s or 40 kB/s transfer speeds with wget as well.
youtube-dl users are reporting this issue as well. Appears as if youtube is throttling VLC. https://github.com/ytdl-org/youtube-dl/issues/29326
Looks like a fork (yt-dlp) has solved this issue for them. Hopefully the VLC will implement a fix as well.
I would emit the hypothesis that it affects many third-party tools and web clients indiscriminately - as I said, even wget. I'm seeing a comment from yesterday that yt-dlp is similarly affected as well:
https://github.com/ytdl-org/youtube-dl/issues/29361#issuecomment-941241528
All the reports in the past months might have been part of an A/B test or slow rollout of this new behavior, and if it's getting more visible now, it would be because it's getting fully rolled out. From here, we reevaluate what works now or not regardless of the past months, and we investigate what would be the difference that makes it work in a web browser but not in third-party tools.
If anyone knows what yt-dlp had alledgedly changed to make it work, I'd like to hear it.
I am not sure why I am being highlighted here. The VLC cache is only there to download the stream faster than VLC can read it. It can't do anything about the server or the network being slow.
Ultimately, YT playback has been a cat and mouse game ever since Google Video dropped VLC support. Google is limited in its changed by whatever the capabilities of the many supported clients, and the performance impact on their cloud infrastructure. But I think it is/was only a matter if time until it becomes nigh-impossible to play without a full web HTML5 engine, and maybe even EME later on.
...
-- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Ultimately, YT playback has been a cat and mouse game ever since Google Video dropped VLC support. Google is limited in its changed by whatever the capabilities of the many supported clients, and the performance impact on their cloud infrastructure. But I think it is/was only a matter if time until it becomes nigh-impossible to play without a full web HTML5 engine, and maybe even EME later on.
I wouldn't agree completely. In my experience as a maintainer, you could say it's been a cat and mouse game for us, but not that YouTube has been playing against us. I've never seen YouTube engineers take obvious hostile action against us or pushes changes aimed at disrupting third-party tools, apart from that one time 8 years ago when they rolled out the signature scrambling (which is so dubious from an engineering point of view that you can wonder whether it was the engineering department who wanted that), and maybe this throttling now.
YouTube engineers usually roll out normal updates and changes, which break our tools because we're not in their QA, but then we update too and it's fixed. That's normal.
There's been some significant public backlash after the legal attack against youtube-dl last year. And I didn't see YouTube's involvement in that by the way - in fact I've wondered if the RIAA even had any legal standing to denounce things like breaches of ToS between YouTube and its users that they wouldn't even be a party to... but I digress. We have interoperability rights, and big web platforms don't exactly have the backing of current governance, either in the US or the EU, rather the contrary. I don't know for sure that YouTube would be in a position to assert moves towards technical lock-in; and again, I don't see that they want to.
Then look at the ever increasing number of websites getting supported by tools such as youtube-dl. Interoperability and the reliance on interoperable industry standards for video streaming formats and protocols as building bricks of web platforms seem ubiquitous. Platforms that take steps such as the signature descrambling or beyond towards enforcing a full web environment as client are rare. Your prediction is not impossible, but seems to have been counterfactual for now.
-
I wouldn't agree completely. In my experience as a maintainer, you could say it's been a cat and mouse game for us, but not that YouTube has been playing against us.
Not that they're targeting VLC specifically.
But what exactly would be the point of the original obfuscation, other than to prevent direct access to videos? And this one even ostensibly involves a bunch of changes to the servers streaming videos to throttle...
In the end, I can only note that this has kept breaking at every VLC release or two. So often that there are now whole support threads dedicated to manually installing the latest version of
youtube.luafromvlc.git.There's been some significant public backlash after the legal attack against
youtube-dllast year.It was only covered in the online IT press, and I was anyway not referring to legal actions.
yt-dlp can usually download, as well as detect severely throttled streams as seen in 'format' IDs 136 & 247 below:
$ yt-dlp -F https://www.youtube.com/watch?v=540TIiKxrJU [youtube] 540TIiKxrJU: Downloading webpage [youtube] 540TIiKxrJU: Downloading android player API JSON [info] Available formats for 540TIiKxrJU: ID EXT RESOLUTION FPS | FILESIZE TBR PROTO | VCODEC VBR ACODEC ABR ASR MORE INFO --- ---- ---------- --- - ---------- ----- ----- - ----------- ----- --------- ---- ------- --------------------------------- 139 m4a audio only | 39.17MiB 48k https | mp4a.40.5 48k 22050Hz low, m4a_dash 249 webm audio only | 31.29MiB 38k https | opus 38k 48000Hz low, webm_dash 250 webm audio only | 39.24MiB 48k https | opus 48k 48000Hz low, webm_dash 140 m4a audio only | 103.95MiB 129k https | mp4a.40.2 129k 44100Hz medium, m4a_dash 251 webm audio only | 73.33MiB 91k https | opus 91k 48000Hz medium, webm_dash 17 3gp 176x144 6 | 62.17MiB 77k https | mp4v.20.3 77k mp4a.40.2 0k 22050Hz 144p 160 mp4 256x144 25 | 69.61MiB 86k https | avc1.4d400c 86k 144p, mp4_dash 278 webm 256x144 25 | 68.33MiB 85k https | vp9 85k 144p, webm_dash 133 mp4 426x240 25 | 169.10MiB 210k https | avc1.4d4015 210k 240p, mp4_dash 242 webm 426x240 25 | 147.48MiB 183k https | vp9 183k 240p, webm_dash 134 mp4 640x360 25 | 415.01MiB 516k https | avc1.4d401e 516k 360p, mp4_dash 18 mp4 640x360 25 | 578.73MiB 720k https | avc1.42001E 720k mp4a.40.2 0k 44100Hz 360p 243 webm 640x360 25 | 317.16MiB 395k https | vp9 395k 360p, webm_dash 135 mp4 854x480 25 | 752.22MiB 936k https | avc1.4d401e 936k 480p, mp4_dash 244 webm 854x480 25 | 586.69MiB 730k https | vp9 730k 480p, webm_dash 22 mp4 1280x720 25 | 2301k https | avc1.64001F 2301k mp4a.40.2 0k 44100Hz 720p 136 mp4 1280x720 25 | 1.70GiB 2172k https | avc1.4d401f 2172k 720p (maybe throttled), mp4_dash 247 webm 1280x720 25 | 1.16GiB 1474k https | vp9 1474k 720p (maybe throttled), webm_dash 298 mp4 1280x720 50 | 2.60GiB 3322k https | avc1.4d4020 3322k 720p50, mp4_dash 302 webm 1280x720 50 | 2.02GiB 2572k https | vp9 2572k 720p50, webm_dash 299 mp4 1920x1080 50 | 4.47GiB 5696k https | avc1.64002a 5696k 1080p50, mp4_dash 303 webm 1920x1080 50 | 3.43GiB 4368k https | vp9 4368k 1080p50, webm_dashNo idea on what they're doing differently. Attempts to d/l one of the "(maybe throttled)" streams is a fool's errand.
Let's look at differences between URLs that work and that don't.
Here's a URL captured from my web browser, I just stripped the "range" query string parameter to request the full video instead. It plays fine in VLC: fast start, no interruption, seeking works. Downloading it with wget starts fast, then shows for me some intermittent stalling, throttling or traffic shaping later on, but still fast enough.
And here's a URL obtained through a slightly modified version of
youtube.lua. It hangs in VLC, wget shows it's throttled at 60 kB/s from the start.Crucial differences are not obvious. Same video format, same server, a bunch of optional parameters that apparently don't make a difference, and some differences in parameters whose purpose I don't know, that can't be changed because they're protected by URL signatures. But there are people out there who are more knowledgeable about YouTube APIs than me.
@Courmisch Apologies for the highlight. I thought you were the site admin.
How can we work together to solve this issue? Perhaps, we can evade the throttling by changing naming parameters in the HTTP request? I'm just spitballing here.
Also, can we get this issue escalated? Lack of YT will impact virtually every VLC user.
How can we work together to solve this issue? Perhaps, we can evade the throttling by changing naming parameters in the HTTP request? I'm just spitballing here.
Tough one. Be my guest to figure out which parameters to change. And then the integrity of URL parameters is covered by signature parameters, so we can't just change those, we need to somehow get YouTube to send us a signed URL with the correct parameters already.
Also, can we get this issue escalated? Lack of YT will impact virtually every VLC user.
I seriously doubt that. Who do you want to escalate to anyway? I'm the maintainer of this feature and I'm stumped. Apparently youtube-dl and yt-dlp are way ahead of us in terms of YouTube APIs, so maybe you want to ask them for help on our behalf. If you mean raising the severity of this ticket on the bug tracker, that's usually only cosmetic and won't change anything.
Workaround seen in a brief (locked) discussion on the yt-dlp github today:
windows:
create new txt file and rename it to yt-dlp to vlc.bat (this is a windows batch file) put this file inside the folder where see yt-dlp and ffmpeg files right click and edit file and put this lines inside (if your vlc. exe is different place yout need to change it)
@echo off :link set "url=" set /p url="link: " yt-dlp --get-url --format best "%url%" | "c:\Program Files\VideoLAN\VLC\vlc.exe" --meta-title "%url%" --fullscreen --no-video-title - goto link
or
with cli command:
yt-dlp --get-url --format best "youtube_link_here" | "c:\Program Files\VideoLAN\VLC\vlc.exe" --meta-title "youtube_link_here" --fullscreen --no-video-title -
Hi! I'm one of the yt-dlp devs who worked on this throttling issue. Saw someone asked about this on the reddit.
Here's my attempt at a quick rundown:
Method 1: The actual fix:
The throttling is caused by a "n" parameter in the video playback url. This has similarities to the signature. You need to descramble it using a js function provided in the player js (base.js). If it is not descrambled correctly, you get throttled.
See these comments for more info:
- https://github.com/ytdl-org/youtube-dl/issues/29326#issuecomment-894619419
- https://github.com/ytdl-org/youtube-dl/issues/29326#issuecomment-866674128 (see quoted content, looks like the original comment was deleted)
In yt-dlp we have yet to implement this, since our js interpreter does not support some of the required functions/operations :(
Method 2: The workaround yt-dlp uses:
The throttling issue only impacts JS-based Innertube API player clients currently (WEB, MWEB, WEB_REMIX, etc.). Non-JS-based clients (ANDROID, IOS, etc.) already have the signature and n-param descrambled in the video URL YouTube gives us. We can request the player response payload for specific clients using the
https://www.youtube.com/youtubei/v1/playerInnertube API endpoint.Example: Using the ANDROID client:
curl --request POST \ --url 'https://www.youtube.com/youtubei/v1/player?key=AIzaSyAO_FJ2SlqU8Q4STEHLGCilw_Y9_11qcW8' \ --header 'Content-Type: application/json' \ --header 'Origin: https://www.youtube.com' \ --header 'X-YouTube-Client-Name: 3' \ --header 'X-YouTube-Client-Version: 16.20' \ --data '{ "context": { "client": { "clientName": "ANDROID", "clientVersion": "16.20", "hl": "en" } }, "videoId": "dQw4w9WgXcQ", }'(note that these requests can get quite complex (e.g WEB client), but ANDROID is currently fairly simple).
Hopefully this helps. Let me know if you have any further questions. :)
ps. I see references to the old
get_video_infoendpoint in youtube.lua. Just FYI this is dead now.edit: grammar
Edited by coletdjnzHi! I'm one of the yt-dlp devs who worked on this throttling issue.
Thanks for reaching out! I had started to look at who I could contact, and you were on my list :)
Method 1: The actual fix:
The throttling is caused by a parameter similar to the signature in the video playback url - "n param". You need to "decrypt" it using a js function in the player js. If it is not "decrypted", you get throttled.
Okay, I get it. Thanks for the pointer, that's just what I needed.
In yt-dlp we have yet to implemented this, since our js interpreter does not support some of the functions/operations required :(
Well in
youtube.luawe already don't use a JS interpreter to descramble signatures, so it might be possible to use the same approach, even if this descrambling looks an order of magnitude more complicated.Method 2: The workaround yt-dlp uses:
The throttling issue only impacts JS-based Innertube API player clients (WEB, MWEB, WEB_MUSIC, etc...) currently. Non-JS clients (ANDROID, IOS, etc.) already have the signature and n-param "decrypted" in the video URL YouTube gives us. So we can simply request the player response payload for specific clients using the
https://www.youtube.com/youtubei/v1/playerInnertube API endpoint.Example: Using the ANDROID client:
curl --request POST \ --url 'https://www.youtube.com/youtubei/v1/player?key=AIzaSyAO_FJ2SlqU8Q4STEHLGCilw_Y9_11qcW8' \ ...Okay, I tested such a request, it works. I also tested that it really needs to be an HTTP POST request. But we can't make HTTP POST requests from lua website parser scripts: no binding available for that, and no HTTP POST lib in the core either - unless that changed recently, but not that I can see. Same issue as with
twitch.luaalready (#25397). So no Innertube API for us, I suppose.Is there any other API available for that kind of stuff, which requires neither POST nor setting custom HTTP request headers?
ps. I see references to the old
get_video_infoendpoint in youtube.lua. Just FYI this is dead now.I'm very aware :/ And now I know it's not getting replaced by Innertube calls either. Lots of dead code still around in that script for stuff that's been phased out ;)
Is there any other API available for that kind of stuff, which requires neither POST nor setting custom HTTP request headers?
Not that I'm aware of. All YouTube apps/clients use this API.
get_video_infowas the endpoint this seems to have replaced.As for HTTP headers, I think all but the Content-Type header there are optional - there are usually equivalent query params/payload parameters for them (and vice-versa). I have a feeling I've seen an equivalent for the Content-Type one too.
Can you point me in the direction of where to find the new lua file? I'll give it a test run.
No, it's not uploaded anywhere. I'll still be working on it. Please be patient; but at least it's encouraging news.
Also I'll have to set up that GitLab stuff to get it merged and it's going to be real annoying to me
Sounds like we're getting close here? @linkfanel @coletdjnz I appreciate your help. Please let me know if you have a "tip jar" I can donate to as a thank you for the quick turnaround.
Sounds like we're getting close here? @linkfanel @coletdjnz I appreciate your help. Please let me know if you have a "tip jar" I can donate to as a thank you for the quick turnaround.
Thanks for your support. There is no guarantee that a relatively simple fix is possible though, and I wouldn't call myself quick about this one :) I don't want tips, but thank you.
But what exactly would be the point of the original obfuscation, other than to prevent direct access to videos? And this one even ostensibly involves a bunch of changes to the servers streaming videos to throttle...
Well, I said that before just learning that this new problem is scrambling again of a higher level of complexity. So granted, you may have a point. The design implemented 8 years ago still worked okay during 8 years though, not bad - even if of course the implementation itself required regular maintenance.
There is no support for
POSTas such, and there is no support for form data encoding. But there is support for requests with payloads, as is used by the HTTP client access output module. And you seem to need JSON rather than form data.Okay I'm unclear. So there is support for POST requests with payloads in the
modules/access/http/library, the library that is used by HTTP access input and output modules. And that support is available in 3.0 as well. But that HTTP library feature is exposed neither as a core API, nor as a module (which module type's semantics would it fit anyway?). The core couldn't call this library anyway because it's inmodules/but not directly exposed as a module. And if we wanted to make a lua binding for it without a core API, we'd have to compile and link that code in the lua module (not the best idea but technically possible). Am I right? Is there some other possibility I'm missing?Curb your enthusiasm. Evaluating that piece of Javascript looks far from trivial without an actual Javascript interpreter.
Well I'm working on it, and you'd be surprised what that code actually is.
Any fix would get merged into 4.0 first, no worries
Edited by Pierre Ynard
Not sure if anyone else was experiencing this issue but I was getting a ton of pixelated gray screen videos for YT streams over the past two weeks. I assume it's related to YT's back-end changes because I tried every setting possible (including disabling hardware decoding, caching, etc.) with no luck.
Anyone else experience a similar issue?
mentioned in merge request !804 (merged)
I uploaded a fixed version of
youtube.lua, and created merge request !804 (merged) for it. Meanwhile you can get and try it at: https://code.videolan.org/linkfanel/vlc/-/raw/26174/share/lua/playlist/youtube.lua Bear in mind that the code is still new and couldn't be comprehensively tested over time, so it works for now but I can't guarantee that it won't need further fixes soon.Thanks @linkfanel!
I've conducted a few test runs this morning on several different computers & broadband connections and I haven't been able to evade the throttling. I just updated the new youtube.lua file in the lua/playlist folder... Am I missing anything in terms of install to get it working? I'm running on v 3.0.16 64bit
- WINDOWS LOG
- main error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 2832 ms)
- main warning: playback too late (60037): up-sampling
- main debug: Received first picture
- main debug: Buffering 8%
- main debug: Buffering 17%
- main debug: Buffering 26%
- main debug: Buffering 35%
- main debug: Buffering 44%
- main debug: Buffering 52%
- main debug: Buffering 61%
- main debug: Buffering 70%
- main debug: Buffering 79%
- main debug: Buffering 88%
- main debug: Buffering 97%
- main debug: Stream buffering done (3000 ms in 5665 ms)
- main debug: Decoder wait done in 0 ms
- main warning: buffer too late (-249819 us): dropped
- mmdevice debug: state changed: 0
- wasapi debug: reset
- main debug: inserting 8022 zeroes
- mmdevice debug: state changed: 1
- main warning: buffer too late (-101536 us): dropped
- main error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 2899 ms)
- main debug: ES_OUT_RESET_PCR called
- main warning: buffer too late (-78316 us): dropped
- main debug: Buffering 0%
- mmdevice debug: state changed: 0
- wasapi debug: reset
- avcodec debug: available hardware decoder output format 119 (cuda)
- avcodec debug: available hardware decoder output format 53 (dxva2_vld)
- avcodec debug: available hardware decoder output format 118 (d3d11va_vld)
- avcodec debug: available hardware decoder output format 174 (d3d11)
- avcodec debug: available software decoder output format 0 (yuv420p)
- avcodec debug: reusing decoder output format 0
Edited by streamer1I've conducted a few test runs this morning on several different computers & broadband connections and I haven't been able to evade the throttling. I just updated the new youtube.lua file in the lua/playlist folder... Am I missing anything in terms of install to get it working? I'm running on v 3.0.16 64bit
Ah indeed, as I said it might, it changed and broke overnight. There was a syntax error in a part not in use with the scrambling at the time when I wrote it, sorry. I've updated the script now, if you want to test it again.
Edited by Pierre Ynard
