search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
28.85k stars 2.93k forks source link

Video freezes but audio plays on when using youtube #8779

Open glesialo opened 3 years ago

glesialo commented 3 years ago

Important Information

System:    Host: Linux-1 Kernel: 5.4.0-72-generic x86_64 bits: 64 Desktop: Cinnamon 4.8.6 
           Distro: Linux Mint 20.1 Ulyssa 
Machine:   Type: Desktop System: MSI product: MS-7885 v: 1.0 serial: N/A 
           Mobo: MSI model: X99S SLI PLUS (MS-7885) v: 1.0 serial: N/A UEFI: American Megatrends 
           v: 1.F2 date: 06/13/2019 
CPU:       Topology: 6-Core model: Intel Core i7-5820K bits: 64 type: MT MCP L2 cache: 15.0 MiB 
           Speed: 1335 MHz min/max: 1200/3600 MHz Core speeds (MHz): 1: 1267 2: 1201 3: 1201 
           4: 1201 5: 1201 6: 1200 7: 1200 8: 1200 9: 1409 10: 1201 11: 1200 12: 1200 
Graphics:  Device-1: NVIDIA GM204 [GeForce GTX 970] driver: nvidia v: 460.73.01 
           Display: server: X.Org 1.20.9 driver: nvidia resolution: 3840x2160~60Hz 
           OpenGL: renderer: GeForce GTX 970/PCIe/SSE2 v: 4.6.0 NVIDIA 460.73.01 
Audio:     Device-1: NVIDIA GM204 High Definition Audio driver: snd_hda_intel 
           Sound Server: ALSA v: k5.4.0-72-generic 

mpv --version
mpv 0.33.0 Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
 built on Thu Nov 26 06:59:44 UTC 2020
FFmpeg library versions:
   libavutil       56.60.100
   libavcodec      58.112.103
   libavformat     58.64.100
   libswscale      5.8.100
   libavfilter     7.90.100
   libswresample   3.8.100
FFmpeg version: git-2020-11-22-9208b72

youtube-dl --version
2021.04.17

Reproduction steps

Problem description: Sometimes, when viewing Youtube videos, video will freeze while audio plays on. 'mpv's track position indicator shows that most/all of the video has already been downloaded (well ahead of the position when video freezes). Googling I found this, four months old, post, in 'superuser', that describes my problem perfectly.

Happens occasionally when playing YouTube videos. The same video fails the first time and then works perfectly in subsequent times. Problem appeared with this video yesterday but it plays perfectly today.

Expected behavior

Video and audio are reproduced throughout the whole youtube video.

Actual behavior

At a certain track position video freezes while audio plays on.

Log file

Will add log file later.

Sample files

This video that has failed once

CounterPillow commented 3 years ago

Will add log file later.

Thanks for nothing

This video that has failed once

In my experience, segments of the video usually fail once and then never again, and mostly happens with low view count videos, which implies it's YouTube's local edge cache having a bit of a stumble and mpv does not retry fetching a segment, instead breaking for all future video segments.

glesialo commented 3 years ago

@CounterPillow Thanks for your prompt reply.

Thanks for nothing

I have set it up so that, now, 'mpv' creates a log file for every run. I'll post the log file created when the issue next happens.

mostly happens with low view count videos, which implies it's YouTube's local edge cache...

It has also happened with some, recent, BBC programs that, I guess, are popular and therefore with high view count.

glesialo commented 3 years ago

It happened again with this video. Video froze about the 4minutes 50 seconds mark.

Here is the log file: mpv.log

dubhater commented 3 years ago

I've been having this problem for ages. For example, with this video: https://www.youtube.com/watch?v=PE6XTzVSGEY

 (+) Video --vid=1 (*) (vp9 640x480 29.970fps)
 (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz)
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 640x480 yuv420p
(Paused) AV: 00:00:00.000 / 00:05:57.820 (0%) A-V:  0.000 Cache: 35s/3MB
[ffmpeg] https: HTTP error 404 Not Found
Failed to open https://r8---sn-gqn-ungs.googlevideo.com/videoplayback/expire/1620175493/ei/JZaRYMfMI4y-1wKM2KfoCg/ip/79.119.240.102/id/3c4e974f35521846/itag/244/source/yt_otf/requiressl/yes/mh/ba/mm/31,29/mn/sn-gqn-ungs,sn-c0q7lnsl/ms/au,rdu/mv/m/mvi/8/pcm2cms/yes/pl/23/initcwndbps/1191250/vprv/1/ratebypass/yes/mime/video%2Fwebm/otfp/1/otf/1/lmt/1558023680002432/mt/1620153651/fvip/5/keepalive/yes/fexp/24001373,24007246/beids/9466585/sparams/expire,ei,ip,id,itag,source,requiressl,vprv,ratebypass,mime,otfp,otf,lmt/sig/AOq0QJ8wRAIgbBs50qZps_le625Bx3emSyThH4VQC1qOBBkmh426pNsCICSq0iuoZyZxgZUkcB9KrYPUJyCDacGPiMNi51Zr4FGi/lsparams/mh,mm,mn,ms,mv,mvi,pcm2cms,pl,initcwndbps/lsig/AG3C_xAwRQIhAJ3a3Q6jdK3ZvaxjekbKowv6kt0zw9jEBmp5LT1dS_FkAiBvNP7C3EuVZxtVRw6nP0PXx4-Y7USIWnHO-E5SKbWI7Q%3D%3D/sq/8/dur/5.338.
[timeline] failed to load segment

Why is Youtube able to play the video? Does it have a different playlist?

qyot27 commented 3 years ago

Why is Youtube able to play the video? Does it have a different playlist?

I noticed that it took about 6-7x as long to download that video with ytdl if I used the [presumably default] 244+251 (VP9+Opus) combo vs. forcing 137+140 (H.264+AAC), even though the filesizes of the resultant files aren't significantly different.

I would guess that the VP9 streams are being hit more now, and that when trying to play the stream through mpv, a bandwidth hiccup can cause the packets to drop out and for ffmpeg to lose the video feed, if the stream container is webm rather than mp4 (so ffmpeg bug? I would have thought the Matroska demuxer was more robust than that, though).

Or if it does happen with mp4, it happens a lot less; if users are strictly using prefer-free-formats or just going with YouTube nominally defaulting to VP9, that could cause issues, but as far as the free formats go, if a video has AV1 available, is it just as prone to this or is the fact that YouTube uses mp4 for AV1 streams actually able to sidestep the problem?

Through a web browser, I'm sure that YouTube just switches to an alternate stream on the fly if it ends up encountering issues, since that's what it does for resolution; why not for format also? That is, assuming YouTube's player has the same issue as ffmpeg does under equivalent conditions.

sebma commented 3 years ago

@qyot27 I have the same pb.

Is this bug happening with the WebM/Matroska container ?

Is it a ffmpeg bug or a container bug ?

I use the following mpv profile for slow configs : 

[sd]
ytdl-format=low/sd/std/bestvideo[height<=?360]+bestaudio/[height<=?360]/bestvideo+bestaudio/best

I guess I will have to change it to : 

[sd]
ytdl-format=low/sd/std/bestvideo[ext=mp4][height<=?360]+bestaudio/[height<=?360]/bestvideo[ext=mp4]+bestaudio/best

I prefer using opensource container for playback.

Hope this bug will be fixed soon.

God bless you.

Kolunchik commented 3 years ago

same here on https://www.youtube.com/watch?v=1Pn_wToAViU

nike4613 commented 3 years ago

I've been having this happen on Windows as well, though it seems to tend to happen mostly to longer videos (>1hr, like stream VODs).

necaran commented 3 years ago

I have similar problem on Mac. The CPU usage rises and the video freezes frequently. Switching hwdec(ctrl-h) or excluding VP9 (bestvideo[vcodec!=vp9]) makes no difference. It seems to happen when I play the video while caching (downloading) is in progress. If I set a large value for demuxer-max-bytes and wait until the entire video stream is fully cached, it plays smoothly.

p.s. Video platforms other than YouTube do not seem to have this problem.

RX14 commented 3 years ago

I get the same error. When a segment fails to load, is it retried? If not, that'd be helpful I think. When downloading youtube videos, i frequently see youtube-dl retry a segment up to 9 times before it successfully downloads. If this is on google's end, it might be the only fix.

trostboot commented 3 years ago

Just want to voice my support for looking into this. It is probably the single most visible and disruptive issue I face with mpv on a somewhat regular basis, and a workaround for the issue on Youtube's side would be very much appreciated.

I can only confirm what has been noted already, in that it seems to mostly/only occur on videos with lower view counts.

f1ow03 commented 3 years ago

Can confirm. I have had this issue for years and thought something is wrong on YT side. Using MPV on Ubuntu, happens with both h264 and vp9 videos.

samheiden commented 3 years ago

Having experienced this error, I don't think there is an issue with youtube-dl per se, since the youtube-dl script automatically handles these errors when encountered, and no artifacts appear in the downloaded video. The issue is that mpv stops caching any video after getting this error from youtube-dl. YouTube is certainly compounding these problems, but youtube-dl has worked around this while mpv has not.

Edit: basically the youtube-dl script retries the url up to 10 times if it gets a 404 due to the common nature of the error. MPV is different in that it only extracts the JSON data outputted by youtube-dl and uses the link in that way. So basically the bug is that mpv, when handling http(s) links, does not automatically retry them. Of course, the simple fix of making mpv retry all http urls would not be a good fix.

Edit 2: looking behind the scenes, mpv does not work exactly how I put it, but it ultimately comes down to the same issue. MPV only uses the JSON data from youtube-dl and then uses the derived links to start caching the video and audio. Since the audio is generally downloaded very quickly, the bottleneck for caching becomes the video. By the time a 404 is sent, mpv has already sent the link to FFmpeg to handle, and the way FFmpeg handles this by default is to stop downloading (which it should be by default)

samheiden commented 3 years ago

So I've done some digging and I've found a few options for the http(s) protocol on FFmpeg that allow you to continuously reconnect for a set amount of time. The ones I am currently using are --demuxer-lavf-o=reconnect_on_http_error=4xx,reconnect_delay_max=30, and have so far been unable to reproduce the errors. I required reconnect_at_eof to be present at some point, but that was at the same time I was using reconnect_on_http_error=404 so I am not sure.

Is there anyone who can test with these options to see if and how much they alleviate the HTTP errors?

glesialo commented 3 years ago

Perhaps it is wishful thinking but, since I replaced 'youtube-dl' by 'yt-dlp' (a couple of weeks ago, to solve 'youtube' throttling of videos), the problem has disappeared.

I'd be grateful if followers of this issue could confirm my suspicion.

Thanks in advance!

haasn commented 3 years ago

Perhaps it is wishful thinking but, sincet I replaced 'youtube-dl' by 'yt-dlp' (a couple of weeks ago, to solve 'youtube' throttling of videos), the problem has disappeared.

Now that you mention it, I haven't ever run into this issue either since switching to yt-dlp.

guidocella commented 3 years ago

yt-dlp should avoid throttling thanks to https://github.com/yt-dlp/yt-dlp/pull/492

N-R-K commented 3 years ago

The ones I am currently using are --demuxer-lavf-o=reconnect_on_http_error=4xx,reconnect_delay_max=30, and have so far been unable to reproduce the errors.

I have been using this for the last 2/3 weeks or so (with youtube-dl) and I don't recall running into this during that time.

since I replaced 'youtube-dl' by 'yt-dlp' (a couple of weeks ago

If we're all experiencing the issue being solved around the same time then it might not have anything to do with that flag or yt-dlp. Could just be some yt server related problem that got fixed or whatever.

trostboot commented 3 years ago

I can say I'm definitely still running into it with yt-dlp. I'm using mpv nightlies with SMPlayer and passing the above mentioned options to it for good measure (to be clear, and using SMPlayers yt-dl + mpv mode for Youtube, of course).

As before, this mostly happens on videos with very low view counts (<1000 typically), which are likely not distributed properly across servers.

samheiden commented 3 years ago

It's been a long while since I've tested this, mainly because there isn't a consistent way to reproduce, but last I checked mpv only uses youtube-dl to get a link to the raw video/audio stream. This means that HTTP errors are for mpv to handle. So unless yt-dlp provides a different link to a server that has the video in its entirety, I wouldn't see how using yt-dlp solves the issue.

Totorrr commented 3 years ago

~@samheiden I doubt that mpv is only getting a link from yt-dlp (or youtube-dl), since many videos are streamed in chunks, with as much different URLs (for each chunk), that would mean re-implementation of some of yt-dlp's logic into mpv, and that would defeat the purpose I'd say.~ Apparently, mpv does get a list of chunks...

I also encounter this problem sometimes. Mostly it happens when I leave a video in pause for many hours or several days, and want to play it again from there (may be related to #7499). Rarely, I also had the problem when I was seeking to a certain point in the video, after a few minutes of playback.

jensMF commented 2 years ago

I have this error a real lot with videos from this playlist https://www.youtube.com/playlist?list=PLj5CvHXSszTrPRQRUgpcqw1CFwD9ttQaT after part 110. Wen it occurs it often occurs every few seconds to minutes. For example in this video: https://www.youtube.com/watch?v=u_Y8cSQ53wA I had the error 15 times. Here are the logs (except of the first error): mpv_002.log mpv_003.log mpv_004.log mpv_005.log mpv_006.log mpv_007.log mpv_008.log mpv_009.log mpv_010.log mpv_011.log mpv_012.log mpv_013.log mpv_014.log mpv_015.log

It was with script-opts=ytdl_hook-ytdl_path=yt-dlp in ~/.config/mpv/mpv.conf and --demuxer-lavf-o-set=reconnect_on_http_error=4xx,reconnect_delay_max=30.

yt-dlp --version
2021.12.01
imarko commented 2 years ago

The following works for me, mpv/ffmpeg reconnects after a 404 and other errors:

stream-lavf-o=reconnect_on_http_error=4xx,reconnect_delay_max=30,reconnect_streamed=yes

Note, it's stream-lavf-o rather than demuxer-lavf-o and the reconnect_streamed=yes is required too.

Sample log after reconnect:

[ffmpeg] https: HTTP error 404 Not Found
[ffmpeg] https: Will reconnect at 0 in 0 second(s).

Another one from after different error, this one succeeded too:

[ffmpeg] tls: error:00000000:lib(0):func(0):reason(0)
[ffmpeg] https: Will reconnect at 14548896 in 0 second(s), error=Input/output error.

Edit, after a few weeks of running with the workaround I ran into a single video hang that turned out to be the server returning a 503 rather than 404. I have modified my config to the following to retry 5xx as well:

stream-lavf-o-append=reconnect_on_http_error=4xx,5xx
stream-lavf-o-append=reconnect_delay_max=30
stream-lavf-o-append=reconnect_streamed=yes

Edit2: After seeing a Connection timed out failure for the first time I am also adding this:

stream-lavf-o-append=reconnect_on_network_error=yes
ThomasEricB commented 2 years ago

Hey, I've tried

stream-lavf-o=reconnect_on_http_error=4xx,reconnect_delay_max=30,reconnect_streamed=yes

and also

stream-lavf-o=reconnect_on_http_error=4xx,reconnect_delay_max=30,reconnect_streamed=yes,reconnect_at_eof=1

However it's not working for me with this video: https://www.youtube.com/watch?v=Mw_YF4e7Hh0 (note that I'm on mpv.net). Any ideas?

[ffmpeg] https: Will reconnect at 280 in 0 second(s), error=End of file.
[ffmpeg] https: Will reconnect at 280 in 1 second(s), error=End of file.
[ffmpeg] https: Will reconnect at 280 in 3 second(s), error=End of file.
[ffmpeg] https: HTTP error 404 Not Found
[ffmpeg] https: Will reconnect at 0 in 7 second(s).
[ffmpeg] https: HTTP error 404 Not Found
[ffmpeg] https: Will reconnect at 0 in 7 second(s).
[ffmpeg] https: Will reconnect at 280 in 7 second(s), error=End of file.
[ffmpeg] https: HTTP error 404 Not Found
[ffmpeg] https: Will reconnect at 0 in 15 second(s).
[ffmpeg] https: HTTP error 404 Not Found
[ffmpeg] https: Will reconnect at 0 in 15 second(s).
[ffmpeg] https: Will reconnect at 280 in 15 second(s), error=End of file.
[ffmpeg] https: HTTP error 404 Not Found
Failed to open https://www.youtube.com/RUS%20Sounds/watch?v=Mw_YF4e7Hh0.
Can not open external file https://www.youtube.com/RUS%20Sounds/watch?v=Mw_YF4e7Hh0.
Can not open external file https://www.youtube.com/Rus%20Sound/watch?v=Mw_YF4e7Hh0.
[ffmpeg] https: HTTP error 404 Not Found
Failed to open https://www.youtube.com/SUBS/watch?v=Mw_YF4e7Hh0.
Can not open external file https://www.youtube.com/SUBS/watch?v=Mw_YF4e7Hh0.
[ffmpeg] https: HTTP error 404 Not Found
[ffmpeg] https: Will reconnect at 0 in 0 second(s).
[ffmpeg] https: HTTP error 404 Not Found
[ffmpeg] https: Will reconnect at 0 in 0 second(s).
[ffmpeg] https: HTTP error 404 Not Found
[ffmpeg] https: Will reconnect at 0 in 1 second(s).
[ffmpeg] https: HTTP error 404 Not Found

Mpv.conf with the following commands:

# YT-DLP OPTIONS

ytdl=yes
ytdl-format=(bestvideo[ext=webm]+bestaudio[ext=webm])[protocol!=http_dash_segments]/best
##ytdl-format=(bestvideo[ext=webm]/bestvideo[height>1080]/bestvideo[fps=60])[tbr<13000]+(bestaudio[acodec=opus]/bestaudio[ext=webm]/bestaudio)[protocol!=http_dash_segments]/best #Enable this if you want up to 1080p videos
ytdl-raw-options=sponsorblock-mark=all
ytdl-raw-options=ignore-errors=
ytdl-raw-options=no-check-certificate=
ytdl-raw-options=prefer-free-formats=
load-unsafe-playlists=yes
script-opts=ytdl_hook-ytdl_path=c:\\Program Files\\mpv.net\\youtube-dl.exe

And yt-dlp.conf with the following:

--prefer-free-formats
--cookies-from-browser firefox
--compat-options multistreams 
--compat-options no-live-chat 
--no-remove-chapters
--embed-chapters
--embed-metadata
--ffmpeg-location C:/ProgramData/chocolatey/lib/ffmpeg/tools/ffmpeg/bin
--retries infinite 
--fragment-retries infinite
ThomasEricB commented 2 years ago

UPDATE: Okay, I think I managed to fix this! If the solution above didn't fix, try only this:

stream-lavf-o=reconnect_streamed=yes

Dudemanguy commented 1 year ago

I remember I used to get this issue myself, but I haven't seen it in ages. No one else has commented on it recently either and there's some workarounds in this thread, so I'll close this.

N-R-K commented 1 year ago

The issue still exists (I faced it about a week or so ago) and none of the workaround in this thread had worked for me (and my earlier comment seems to have been a fluke).

Only thing that reliably works is to just manually reload the video via a lua script - which is annoying to do.

christoph-heinrich commented 1 year ago

I've noticed that this only happens on video formats where, when looking at the JSON from yt-dlp -J, filesize is null and instead it has filesize_approx set. This is usually only the case for formats with the vp9 codec, however I've also encountered videos (rarely) where both vp9 and h264 formats had that problem and the only way to watch the video was to switch to a format that provides both video and audio (format id 22 for 720p and 18 for 360p).

BTW a convenient way to check for this and to switch format is to use quality-menu because it shows the filesize_approx with a ~ prefix if filesize isn't available.

GunGunGun commented 1 year ago

I figured out this problem from my side, it's a Youtube's problem because sometimes Youtube doesn't want to send back full data to client, for example my client using Python want to read socket.recv(8191) from Youtube with this code:

r = requests.get('https://....googlevideo.com/....', stream=True)
while True:
    data = r.read(8191)
    if not data:
        break

But they return nothing, result in a unfinished download and then audio will start writing and cause the video to freeze with audio only. And it can be fixed by simply retrying download, reopen a new connection and not the existing connection that return nothing and read again from there.

I used a local proxy to download data and send to MPV and patch this bug by closing the buggy connection, then open a new connection and use Range header to re-read socket from previous read, and my method completely fixed this video freezing with only audio problem. I think MPV can fix this by implementing a better retry logic.

garoto commented 1 year ago

Always assumed this to be a google content cache replication issue, which I most found happening on low view-count content. Video being old or new never seemed to be a factor iirc.

GunGunGun commented 1 year ago

After 4 days of using MPV to watch Youtube with my local proxy server with a different retry logic under a heavily throttled internet connection I'm no longer seeing this video freeze with audio only bug anymore, so this could be a hint for us to completely fix this problem by changing MPV's retry logic.

Basically what I did:

I don't know C or C++ so I can't really commit a fix, but that's my idea, hopefully MPV can fix this bug, someday. The problem is Youtube trying to be an asshat, in short, but we also need to deal with that better because even Bilibili does the same thing from my experience and probably more.

madfcat commented 1 year ago

I have the same issue on a 9 hour long video. The video freezes. Moreover the video player lags hard.

VikingSchism commented 2 months ago

I'm having the issue with various youtube videos however even after attempting to restart the video still does not work - it actually does not even launch a window if resuming playback to the affected point and if not resuming playback the parts of the video that were originally unaffected remain unaffected while the affected part still only plays audio (and displays the frozen frame of the piece of unaffected video that was last played. This seriously affects the usability