Opening a YouTube URL gives a 403 error

[perryprog]

Relevant PR is #17471, and the stream-lavf-o option comes from #8655 (comment). Notably, yt-dlp-ing the URL works fine, it's just mpv's downloading that's having trouble.

I was also able to reproduce this in a Linux VM on master. I could also reproduce it with both --curl-enabled=yes and --curl-enabled=no, though the auto-reconnect with ffmpeg seems to give it a chance to succeed, albeit often in weird ways (someone in #mpv mentioned it worked fine, I always seem to get no audio). Relying on a retry when getting a 403 is pretty questionable behavior, though.

mpv Information

❯ ./mpv --version
mpv v0.41.0-923-g7b8915bc1 Copyright © 2000-2026 mpv/MPlayer/mplayer2 projects
 built on Aug 14 2026 10:59:31
libplacebo version: v7.360.1
FFmpeg version: 8.1.2
FFmpeg library versions:
   libavcodec      62.28.102
   libavdevice     62.3.102
   libavfilter     11.14.102
   libavformat     62.12.102
   libavutil       60.26.102
   libswresample   6.3.102
   libswscale      9.5.102


❯ yt-dlp --version
2026.07.04

Other Information

- macOS version: macOS 26.5.2 (25F84)
- Source of mpv: GitHub
- Latest known working version: v0.41.0, provided your config doesn't include `stream-lavf-o=request_size=10485760,multiple_requests=1`
- Issue started after the following happened: YouTube probably changed something :(.

Reproduction Steps

1. Run from a master build mpv --no-config https://www.youtube.com/watch?v=dQw4w9WgXcQ or run from v0.41.0 mpv --no-config --stream-lavf-o=request_size=10485760,multiple_requests=1 https://www.youtube.com/watch?v=dQw4w9WgXcQ. Master build seems to reproduce the issue less often than the stream-lavf trick, so it might take a few tries?

Expected Behavior

1. Get rick rolled.

Actual Behavior

1. No rick roll and primarily a 403 error from YouTube:

   [curl] HTTP error 403
   Failed to open https://rr2---sn-8xgp1vo-2iae7.googlevideo.com/videoplayback?expire=1786748421&ei=pUl_aurPLtThkucPlYy4qQ4&ip=108.52.81.202&id=o-ANf2Gc1XVJ-xz-V1Qg081Ebd5O6V68YSGfsTr313aRNn&itag=251&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&met=1786726821%2C&mh=7c&mm=18%2C29&mn=sn-8xgp1vo-2iae7%2Csn-8xgp1vo-xfgl&ms=aub%2Crdu&mv=m&mvi=2&pl=18&rms=aub%2Caub&initcwndbps=4298750&bui=AZFlqhPh66XnYN8xAiUdHbAYycoEcEER-fJt1S2rQcVmKxSZu8X50fzfcq86axUYiBraEd64yIzeburp&spc=KBGBcqhuu2q3lb7RIpu35lzEqbYEieHq1P7mfjFCI6st9vs&vprv=1&svpuc=1&mime=audio%2Fwebm&rqh=1&gir=yes&clen=3433755&dur=213.061&lmt=1766955883819090&mt=1786726382&fvip=3&keepalive=yes&fexp=51565116%2C51946838%2C52089683&c=ANDROID_VR&txp=5532534&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cbui%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Crqh%2Cgir%2Cclen%2Cdur%2Clmt&sig=AE0s2JYwRAIgHxlCczQ7SZx63eoadzny8eWnPPaQXf97c16Fx7r27acCIAmZaJcSobIAWa5bCaqSZMKAUJ3UlkRBNIHZkNgJH3IV&lsparams=met%2Cmh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Crms%2Cinitcwndbps&lsig=APaTxxMwRQIgdeN5rhhs0vvy04dTbAdIyUM_45uK7VioX9ASspL3mhwCIQDjZ90CMLu710QvJg1Zsy65f2mh7ccoO8U6cVy2eg9XXw%3D%3D.
   [timeline] failed to load segment
   

Log File

output.txt

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested and confirmed that the issue exists with the latest release version or newer.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[sfan5]

Google can decide to return 403 for any reason they want, so without further information this isn't really something mpv can fix.
yt-dlp is not a good comparison to make, because they do all kinds of crazy stuff to get the downloads working (maybe even using curl-impersonate these days?).
You can for example try and see if the same URL works with command-line curl, or wget.

As it happens I just managed to catch the curl trace output, so in case it's relevant:

[curl] starting curl request at 0
[curl] * Hostname rr2---sn-uxax4vopj5qx-q0n6.googlevideo.com was found in DNS cache
[curl] * Host rr2---sn-uxax4vopj5qx-q0n6.googlevideo.com:443 was resolved.
[curl] * IPv6: 2a02:3040:0:7::d
[curl] * IPv4: 92.226.2.205
[curl] *   Trying [2a02:3040:0:7::d]:443...
[curl] * SSL reusing session with ALPN '-'
[curl] * SSL verify result: 0
[curl] * ALPN: curl offers h2,http/1.1
[curl] * TLSv1.3 (OUT), TLS handshake, Client hello (1):
[curl] * SSL Trust Anchors:
[curl] *   CAfile: /etc/ssl/certs/ca-certificates.crt
[curl] * TLSv1.3 (IN), TLS handshake, Server hello (2):
[curl] * TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
[curl] * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
[curl] * TLSv1.3 (IN), TLS handshake, Finished (20):
[curl] * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
[curl] * TLSv1.3 (OUT), TLS handshake, Finished (20):
[curl] * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / UNDEF
[curl] * ALPN: server did not agree on a protocol. Uses default.
[curl] * Server certificate:
[curl] *   subject: CN=*.googlevideo.com
[curl] *   start date: Aug  4 12:31:29 2026 GMT
[curl] *   expire date: Oct 13 12:31:28 2026 GMT
[curl] *   issuer: C=US; O=Google Trust Services; CN=WR2
[curl] *   subjectAltName: "rr2---sn-uxax4vopj5qx-q0n6.googlevideo.com" matches cert's "*.googlevideo.com"
[curl] * OpenSSL verify result: 0
[curl] * SSL certificate verified via OpenSSL.
[curl] * Established connection to rr2---sn-uxax4vopj5qx-q0n6.googlevideo.com (2a02:3040:0:7::d port 443) from [...] port 43508 
[curl] * using HTTP/1.x
[curl] > GET /videoplayback?expire=[...] HTTP/1.1
[curl] Host: rr2---sn-uxax4vopj5qx-q0n6.googlevideo.com
[curl] Range: bytes=0-10485759
[curl] User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36
[curl] Accept: */*
[curl] Accept-Encoding: deflate, gzip, br, zstd
[curl] Icy-MetaData: 1
[curl] 
[curl] * Request completely sent off
[curl] * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
[curl] * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
[curl] < HTTP/1.1 403 Forbidden
[curl] < Last-Modified: Wed, 02 May 2007 10:26:10 GMT
[curl] < Content-Type: text/plain
[curl] < Content-Length: 0
[curl] < Connection: close
[curl] < Vary: Origin
[curl] < Cross-Origin-Resource-Policy: cross-origin
[curl] < X-Content-Type-Options: nosniff
[curl] < Date: Fri, 14 Aug 2026 17:15:33 GMT
[curl] < Server: gvs 1.0
[curl] < 
[curl] HTTP error 403
[curl] proto=https ok=0 code=403 size=-1 seekable=0 type=text/plain
[curl] * shutting down connection #1

Considering that this requires a few tries to reproduce I'd guess Google is rate-limiting "suspicious" clients, but there is some leeway.

[perryprog]

Ah, thanks for that. Note that it also struggles when using --curl-enabled=false; see my edit to the original issue.

[quietvoid]

mpv --log-file=mpv-sucks.log --msg-level=curl=trace 'https://www.youtube.com/watch?v=D7F9KYLAsfI'

The logfile grows quickly
mpv-sucks.log

[perryprog]

Possible dupe of #18256. That was allegedly possibly fixed with #18193, but I'm not seeing any delay. That being said, if I manually set the stream delay to five seconds in ytdlp_hook.lua inside on_load_hook I can still reproduce the issue so maybe it's totally unrelated.

[UnconsciousBlaringHuman]

Given the android_vr in the actual behaviour snippet, I believe it might be related to yt-dlp/yt-dlp#17456.
The pinned solution (updating yt-dlp to nightly) solved it for me.