Well, I said too soon. It seems that some videos in Crunchyroll are still using RTMP protocol, so they're still having wrong FPS. For example, this one: http://www.crunchyroll.com/konosuba-god … ead-727601

HLS (identified as M3U8 in SVPtube) videos seems fine, since they're decoded by mpv itself. Well, back to my old hack.

Something interesting I discovered today too, the FPS reported by SVP when I use M3U8 streams (59.9361 FPS) actually seems correct. The videos using this FPS seeks correctly, while I still have some desync when watching RTMP streams (that maybe problematic in longer videos like movies, however since the majority of animes episodes are only ~25 minutes it is not problematic).

Reporting that the lastest SVPtube update did seem to fix this issue. Now I can watch Crunchyroll videos without the hack described in this topic. Just FYI, in this latest version SVPtube seems to use .m3u8 playlist files, instead of the older video.mp4 muxed file.

The FPS reported by SVP is still somewhat strange, though, 59.9361 FPS, however I already watched two problematic series in Crunchyroll since the update (Fuuka and Rewrite) and didn't have any desync problem yet.

Just coming to report that even in last SVP (that at least according to changelog, did fix this problem), I still get wrong FPS in mpv.

I am going to ask, can't we have an option in SVP configuration to force the FPS from input video? It seems to be better to fix this in SVP side than mpv side.

Well, this seems to work:

profile-desc="Crunchyroll fix for SVPTube"



profile-desc=cond:get('container_fps', 0) < 23 and get('container_fps', 0) >= 23.9

However I don't have non 23.976 FPS videos to test, so I don't know if this work for the non broken case.

dlr5668 wrote:

But u need to press "_" twice to reload video (#_ cycle video setting). Thanks for new plugin mate.

Nice one. This seems to work automatically:

profile-desc="Crunchyroll fix for SVPTube"

profile-desc=cond:get('container_fps', 0) > 23 and get('container_fps', 0) <= 23.9

Edit: nope, said too soon. Even toggling manually still causes desyncs. Looking at SVP itself it still reports a wrong FPS, so I think it didn't update its state.

myfakeacc wrote:

Ah, streams. Well, I think I might have a pretty good solution for you.
Get this script and put it into your mpv scripts folder: https://github.com/wm4/mpv-scripts/blob … ofiles.lua
Now you can create profiles that are applied based on lua expressions. Additionally, you can use mpv properties like normal variables.


profile-desc=cond:get('container_fps', 0) > 23 and get('container_fps', 0) < 23.9

It's not a perfect solution. The profile expression is re-evaluated every time the used properties change and applied/activated when it evaluates to true. Therefore, when watching streams with variable fps it could activate the profile (e.g. when the fps suddenly drop below 23.9 but stay above 23 (in this case)).
Of course you can make your own, even more precise conditions.

Note: profiles do not get "unapplied". In case you want to "unapply" a profile you need an inverted version, e.g.:

profile-desc=cond:get('width', -math.huge) >= 3840

profile-desc=cond:get('width', -math.huge) < 3840

This is a good idea, however it does not seem to work. Maybe because when auto-profiles applies the profile, the wrong container_fps is already reported to SVP, so it does not matter if I change it.

myfakeacc wrote:

The cause of the problem is a damaged file (incorrectly tagged FPS/duration). Therefore, in my opinion, the only sane way to fix this is by fixing the damaged file: remux it with the correct FPS value. Remuxing takes like 2 seconds, it won't change the video or audio and fixes the problem mentioned here, for every player.
I don't think that configuring/changing behavior of your player is a good solution for fixing an error in a file that can be corrected so easily just by remuxing.

If I was watching HS files this would be a acceptable (however a PITA) solution, however I mostly watch directly from Crunchyroll. I don't know if whatever mux SVPTube/youtube-dl uses could fix do the right thing.

myfakeacc wrote:

A incorrect FPS value in the container is actually so common that every decent video player simply ignores it and does playback without. E.g. many .wmv files have a tagged FPS value of 9999. mpv offers this container fps value as property for scripts etc.
mpv contains one more fps property: estimated fps. This is the real FPS value which is also correct for incorrectly tagged videos. There is one drawback: it is a measured value, averaging over the last n frames. Consequently, it is only correct after n subsequent samples (i.e. only after a few frames were rendered) and it might change during playback (e.g. variable frame rate videos). Therefore it is unsuitable for a script that calculates stuff on startup like SVP

Maybe trying to match the container_fps to a list of known, sane FPS values, like 23.976, 25, 29.97 and so on. A value of 23.810 would be fixed to 23.976, a value of 29.90 would be fixed to 29.97 etc etc. However, of course, this would break in videos that actually have crazy FPS settings.

Well, since this is kinda of a hard problem I think my proposal in OP is at least one way to fix the most annoying case, that is SVPTube+Crunchyroll. I think other video providers don't have wrong FPS settings for the majority of their video library. It would be nice if CR actually fixed their videos, however I don't think this will happen anytime soon.

EDIT 22/02/2017: contrary to what I said before, this is still a problem. However, it actually depends of the type of video detected by SVPtube: M3U8 streams are parsed directly by mpv, works perfectly, and this seems the format used by more recently releases at Crunchyroll. RTMP streams needs to be muxed in a "video.mp4" file and brings the wrong FPS problem.

EDIT 19/02/2017: since latest SVPtube update, the procedure described in this topic does not seem to be necessary anymore. The problem seems to be fixed since SVPtube know uses a very long string as filename (with ".m3u"8 extension), instead if the old "video.mp4". They probably started to feed the HLS stream directly to mpv instead of trying to remux the video, solving the problem.

So I finally solved the problem of audio desync when using mpv+SVP4 and Crunchyroll (using SVPTube or directly by mpv+youtube-dl) or HorribleSubs. This seems to be a common problem:


The problem is basically what is described in this post: Crunchyroll encoded videos reports a FPS of 23.810, instead of the more common 23.976. Actually, this seems to be a lie: the video is actually encoded with 23.976FPS, however the container reports a lower FPS for some reason. This doesn't cause any problem for normal playback, however when we use SVP this makes the video go faster than the audio, causing a desync.

The cause of the problem seems to be in the vapoursynth support in mpv: vapoursynth does not have any information about the video, so mpv fills some variables accesible to vapoursynth scripts with some information about the video. The variable that stores the video FPS is container_fps, however this variable reports the container FPS instead of the actual video FPS (I don't know if mpv actually has this information btw). So vapoursynth gets the wrong FPS, and SVP by instance gets the wrong FPS too, scalling the video to 59.6852 or 60.6073 instead of the correct 59.97FPS that we see in videos with proper FPS.

FYI, HorribleSubs basically dumps and mux Crunchyroll streams, so they get it wrong too.

So, how to fix it? We will create a special mpv.conf file that will force the correct FPS in the video, allowing us to watch anime from Crunchyroll without audio desync (however there are still some minor problems, I will describe it better later).

Press Win+R and type "%appdata%\mpv", this will open a new Windows Explorer window. Create a new .txt file there, name it "mpv.conf" and edit it as below:

profile-desc="Crunchyroll fix for SVPTube"


So basically what we're doing is create a new profile that makes mpv to assume the video is running at 23.976FPS, and now SVP correctly scales the video to 59.97FPS. no-correct-pts makes mpv to assume that the video metadata is broken so it should assume the FPS we set before. Since we are using [extension.mp4] it will only apply to .mp4 files, since SVPTube mux the output to a video.mp4 file. If you're watching from HorribleSubs, you probably should add a [extension.mkv] too.

Now for the problems: the subtitles still assume a video playing with 23.810, so they will be slightly behind and sometimes they will be too fast. I fixed the first problem with sub-delay, however the second problem I tried to fix with the sub-speed option without success. If someone can fix the second problem it would be interesting, so I leave it to someone to try. However even with this problem, the videos from Crunchyroll/HorribleSubs are watchable.

The other problem is, since we use this profile for every video file with mp4/mkv extension, this will break other videos you try to play with mpv. There isn't a simple way to fix this: you can comment those lines in mpv before playing other type of video, however this a pretty bad solution.

I hope the SVP team comes with a better workaround for this problem. If we could pass parameters for mpv from SVPTube, for example, we could simple pass mpv --profile=svp-crunchyroll when playing Crunchyroll videos, and mpv --profile=default when playing normal, non-broken content. For now at least this is a workaround.

Edit: MPC-HC does not seem to suffer from this problem at all. However mpv, at least in my experience, is much smoother than MPC-HC. And MPC-HC does not support RTMP streams like mpv, so your only option is to use HorribleSubs or download the video with SVPTube.