mpv
mpv copied to clipboard
mpv-player
'[ffmpeg] hls: keepalive request failed' error on YouTube videos (with youtube-dl)
Important Information
Provide following Information:
- mpv version: a3e440c (couple earlier ones show similar behaviour)
- Windows Version: Windows 7
- Source of the mpv binary: shinchiro build (2021-01-17)
- Issue started relatively recently, persists through all versions I tried
Reproduction steps
Play YouTube link in mpv. Some behave better than another.
Sometimes errors start happening right away and don't stop, other times they occur in small stacks with pauses between them.
The errors manifest in extreme buffering and can break the playback completely.
Happens mostly on livestreams, can not consistently reproduce error with regular videos.
Errors do not seem to be happening with links from other streaming services.
Expected behavior
No buffering issues, seamless playback
Actual behavior
Buffering, broken playback.
Additional observations:
- upon opening certain videos, the error keeps occurring every second, and doesn't stop occurring on its own.
- closing mpv and re-opening the same link once does not fix the issue, doing it again, however, fixes it. (open-close-open-close-open=no errors).
- also, opening another instance of mpv with the same link while the first one is running and having errors immediately fixes the issue both for new and the old instance.
- after this, no matter how many times the link is opened, the error never appears again on the same video.
Log file
[ffmpeg] https: Cannot reuse HTTP connection for different host: r17---sn-3c27sne7.googlevideo.com:-1 != r5---sn-3tp8nu5g-3c2d.googlevideo.com:-1 [ffmpeg/demuxer] hls: keepalive request failed for 'https://r5---sn-3tp8nu5g-3c2d.googlevideo.com/videoplayback/... with error: 'Invalid argument' when opening url, retrying with new connection
Another error that frequently happens specifically on the following video:
- https://www.youtube.com/watch?v=lHLChGEwdwQ
[ffmpeg] tls: read failed: error:14FFF3E7:SSL routines:(UNKNOWN)SSL_internal:unknown failure occured [ffmpeg/demuxer] hls: keepalive request failed for 'https://r5---sn-3tp8nu5g-3c2d.googlevideo.com/.... with error: 'I/O error' when opening url, retrying with new connection
To reiterate, some links are completely unaffected, some show sporadic errors, and some like this one have errors consistently.
This looks more like an issue with your ISPs google content cache or your ISP is load-balancing the IPs for manifest.googlevideo.com, which is the domain name used by google for YT live content (as returned by youtube-dl --get-url), and your OS DNS caching mechanics are getting in the way.
FWIW, I just let mpv play the link you posted for ~45mins and had zero errors/warnings:
> mpv https://www.youtube.com/watch?v=lHLChGEwdwQ
[ 7.540856] cplayer: (+) Video --vid=1 (h264 1920x1080)
[ 7.541512] cplayer: (+) Audio --aid=1 (aac 2ch 44100Hz)
[ 7.738633] cplayer: AO: [wasapi] 48000Hz stereo 2ch float
[ 7.739547] cplayer: VO: [gpu] 1920x1080 yuv420p
[ 7.774554] term-msg: mpv 0.33.0-69-g4fa11a27f5-garoto
[ 7.775011] term-msg: Title: π―π΅ Japanese 70s 80s New Music Soul Funk Disco Fusion City Pop Kayou Reggae εγ’γ γγ₯γΌγγ₯γΌγΈγγ―πΌ
[ 12.748927] statusline: AV: 00:00:04 / 00:00:15 (32%) A-V: 0.000 Cache: 11s/1MB
[ 12.758463] osd/libass: Glyph 0x1F1EF not found, broken font? Trying all charmaps
[ 23.740538] statusline: AV: 00:00:16 / 00:00:34 (46%) A-V: 0.000 Cache: 18s/6MB
[ 23.987124] osd/libass: Glyph 0x1F1EF not found, broken font? Trying all charmaps
[ 25.076387] statusline: AV: 00:00:17 / 00:00:34 (50%) A-V: 0.000 Cache: 17s/5MB
[ 25.320011] osd/libass: Glyph 0x1F1EF not found, broken font? Trying all charmaps
[ 32.782094] statusline: AV: 00:00:25 / 00:00:39 (63%) A-V: 0.000 Cache: 14s/4MB
[ 32.919537] osd/libass: Glyph 0x1F1EF not found, broken font? Trying all charmaps
[ 35.764399] statusline: AV: 00:00:28 / 00:00:44 (62%) A-V: 0.000 Cache: 16s/3MB
[ 35.886663] osd/libass: Glyph 0x1F1EF not found, broken font? Trying all charmaps
[2725.742594] statusline: AV: 00:45:18 / 00:45:34 (99%) A-V: 0.000 Cache: 16s/1MB
[2726.706255] cplayer:
[2726.706942] cplayer: Exiting... (Quit)
Interesting, thanks for replying. I just tried the same thing on different Win7 machine (with wifi this time), and got the identical behaviour, even up to the part where launching a link on one machine while the same link is running on other stops the errors on both of them.
A bit of an update, the issue persists if not getting worse. The errors can start appearing after hours of seamless playback, even after doing the trick to fix the initial flood of errors.
Also now I'm noticing this bit popping out frequently among the errors:
[decode_wrapper/ad] Invalid audio PTS: 20.015601 -> 21.014067
[cplayer]
[cplayer] Audio/Video desynchronisation detected! Possible reasons include too slow
[cplayer] hardware, temporary CPU spikes, broken drivers, and broken files. Audio
[cplayer] position will not match to the video (see A-V status field).
[cplayer]
There were also cases where there were no [ffmpeg/demuxer] errors, and aforementioned desynchronisation errors occured every second, resulting is similarly chopped playback.
i have the same with mpv via yt-dlp:
[ffmpeg] https: Cannot reuse HTTP connection for different host: rr9---sn-n8v7snl7.googlevideo.com:-1 != rr3---sn-gvnuxaxjvh-v8c6.googlevideo.com:-1
[ffmpeg/demuxer] hls: keepalive request failed for 'https://rr3---sn-gvnuxaxjvh-v8c6.googlevideo.com/videoplayback/id/Oa6hN0rXBx8.1/itag/96/source/yt_live_broadcast/expire/1676826507/ei/KwPyY86zNpbm7QSt6aO4AQ/ip/212.164.39.23/requiressl/yes/ratebypass/yes/live/1/sgoap/gir%3Dyes%3Bitag%3D140/sgovp/gir%3Dyes%3Bitag%3D137/hls_chunk_host/rr3---sn-gvnuxaxjvh-v8c6.googlevideo.com/playlist_duration/30/manifest_duration/30/spc/H3gIhppO-ua_8-4aZ-estIFvRgrTDHA/vprv/1/playlist_type/DVR/initcwndbps/1296250/mh/n4/mm/44/mn/sn-gvnuxaxjvh-v8c6/ms/lva/mv/m/mvi/3/pl/24/keepalive/yes/fexp/24007246/mt/1676804434/sparams/expire,ei,ip,id,itag,source,requiressl,ratebypass,live,sgoap,sgovp,playlist_duration,manifest_duration,spc,vprv,playlist_type/sig/AOq0QJ8wRAIgCbL-d5MPHIrNF31SedFfyQi9UmkcJnVeGbt5H105VBwCIDCBZptYU3GNpNYiN3Vqu_ZCJbPKOfMLoSKZaKhJvlgf/lsparams/hls_chunk_host,initcwndbps,mh,mm,mn,ms,mv,mvi,pl/lsig/AG3C_xAwRQIgDkiGoiP1c86skI1MFVfaRt4m32vewWeSX8gJl5WNi5cCIQC9BEkNZqU2y2vrkrFi4KwjtV3KtEeAERRVElt7fIBFzA%3D%3D/playlist/index.m3u8/sq/9711/goap/clen%3D81875%3Blmt%3D1676784730989197/govp/clen%3D2834368%3Blmt%3D1676784730989195/dur/5.000/file/seg.ts' with error: 'Invalid argument' when opening url, retrying with new connection
The command line:
mpv --quiet --msg-level=all=fatal --stop-screensaver --ytdl --script-opts=ytdl_hook-use_manifests=yes --script-opts=ytdl_hook-ytdl_path="yt-dlp" --ytdl-raw-options=cookies="/tmp/myoutube-cookies.8n3XDt", --cookies --cookies-file="/tmp/myoutube-cookies.8n3XDt" --alang=ru,uk,en,us --slang=ru,uk,en,us --ytdl-format=141/251/140/171/18/43/35/5/36/http-360p/url360/cache360/progressive_sd_src_no_ratelimit/http-380/mpd-3/mpd-2/mp4/best --vd-lavc-threads=4 --vd-lavc-skiploopfilter=all --no-video --sub-codepage=enca:ru:UTF-8 --msg-level=all=status https://www.youtube.com/watch?v=Oa6hN0rXBx8
Playback works, but with spamming of the mentioned errors
i have the same output as @Flashwalker but buffering is slow, at best it buffers 2.5 seconds of video taking... 5 seconds or so to do so
same, yt-dlp 2023.07.06 mpv master
https://trac.ffmpeg.org/ticket/9470
Yep, experiencing same issue with mpv:
[ffmpeg] https: Cannot reuse HTTP connection for different host: rr5---sn-nv47lns7.googlevideo.com:-1 != rr4---sn-npa3oxu-ucns.googlevideo.com:-1
[ffmpeg/demuxer] hls: keepalive request failed for 'https://rr4---sn-npa3oxu-ucns.googlevideo.com/videoplayback
This is an ffmpeg issue with m3u8/hls that is not yet fixed. It refuses to work with crossdomain cdns because it requires that the servers are the same.
https://www.google.com/search?q=%22Cannot+reuse+HTTP+connection+for+different%22+%22keepalive+request+failed+for%22
A way of mitigating this problem is by forcing all ffmpeg requests with a proxy that mandates that all requests have a constant prefix, something like corsproxy should do the trick.
This is an ffmpeg issue with m3u8/hls that is not yet fixed. It refuses to work with crossdomain cdns because it requires that the servers are the same.
https://www.google.com/search?q=%22Cannot+reuse+HTTP+connection+for+different%22+%22keepalive+request+failed+for%22
A way of mitigating this problem is by forcing all ffmpeg requests with a proxy that mandates that all requests have a constant prefix, something like corsproxy should do the trick.
do you have any examples how this might work?
@24fpsDaVinci
Ffmpeg would be comnected to a proxy that enforces all m3u8s have the same domain using a reverse prozy like cors anywhere. I've tested an m3u8/hls file and it seems that ffmpeg has gotten rid of the error once all items in the m3u are from the same domain.
The prerequisites are...
- The segments and the m3u8 files are all perfectly readable
- The segments are from the same domain
- The segments share the same codec and video resolution.
- All of them should be mpeg ts (?)
You can find cors anywhere here. https://github.com/Rob--W/cors-anywhere
I cannot delve too much into the specifics at the moment but a fix should be possible with the proxy hack. Or by filing an issue through ffmpeg tracker (trac.ffmpeg.org).
This is more of a manifest.googlevideo.com issue than m3u8/hls/ffmpeg/yt-dlp. HLS playback seems fine on many websites to me.
It seems to happen only when the server doesn't request the specific HLS fragment when you seek on your favorite player. Some servers support third party players. Some don't. Instead, they force sequential fragment unlock only. YouTube seems to be the one which does that.
That's why @guidocella's piping method seems to work, because you're restricting yourself to load fragments in sequential order and avoiding seeking issues.
No, this also occurs with HLS streams on IVS.
That's exactly what I'm saying. IVS is an amazon service, which seems to does that as well. I do use some piracy streaming sites, which mostly use HLS playback. They seem to work very well, including seeking.
This is not a ffmpeg HLS issue. It's an issue of server side fragment requests.