mpv handling of streamlink hls seems broken with mpv-x86_64-v3-20230507-git-a1580b6 version

[zouhair]

mpv version and platform versions

mpv-x86_64-v3-20230507-git-a1580b6 on windows 10

Reproduction steps

Using streamlink to open a twitch vod

streamlink https://www.twitch.tv/videos/1814843938 best

Expected behavior

When mpv opens the vod passed through with hls by streamlink it shows the whole length of the vod and one can seek back and forth to any place in the whole lenght of said vod

Actual behavior

Now, mpv only plays segment by segment which are each 10 second long, which defeats the purpose of hls passthrough

Log file

Note: going back to the ulterior version of mpv fixes the problem mpv-x86_64-v3-20230430-git-6d422b3

Log of broken version mpv-x86_64-v3-20230507-git-a1580b6 : https://0x0.st/HZ68.txt

Log of working version mpv-x86_64-v3-20230430-git-6d422b3 : https://0x0.st/HZ6K.txt

[CounterPillow]

Probably duplicate of #11673

[zouhair]

May be related

I at least gave logs for working version and non working one

Feel free to close if you think it's the same

Thanks for reading

[Lonely233233]

Only 230507 started to have this problem. The previous versions were normal.

[avih]

Using this command line (from the log, with addition of --no-config):

mpv --no-config '--cache' '2048' '--force-media-title=https://www.twitch.tv/videos/1814843938' 'https://d2nvs31859zcd8.cloudfront.net/84a78156146c00e58213_hasanabi_42170717963_1683572491/chunked/index-dvr.m3u8'

For me, it does plays the clip with current master - 0.35.0-378-ga1580b6424 - which is the same version which OP says doesn't play it.

However, I'm using an older ffmpeg, and between the OP logs, ffmpeg changed with nearly 100 new commits.

Working:

[   0.000][v][cplayer] mpv 0.35.0-375-g6d422b3e Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects
[   0.000][v][cplayer]  built on Sun Apr 30 12:19:58 2023
[   0.000][v][cplayer] libplacebo version: v5.264.0-222-ga6b95da
[   0.000][v][cplayer] FFmpeg version: N-110417-g41dd50ad0
[   0.000][v][cplayer] FFmpeg library versions:
[   0.000][v][cplayer]    libavutil       58.6.100
[   0.000][v][cplayer]    libavcodec      60.10.100
[   0.000][v][cplayer]    libavformat     60.5.100
[   0.000][v][cplayer]    libswscale      7.2.100
[   0.000][v][cplayer]    libavfilter     9.6.100
[   0.000][v][cplayer]    libswresample   4.11.100

broken:

[   0.000][v][cplayer] mpv 0.35.0-378-ga1580b64 Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects
[   0.000][v][cplayer]  built on Sun May 07 12:36:54 2023
[   0.000][v][cplayer] libplacebo version: v5.264.0-238-g6e7bb73
[   0.000][v][cplayer] FFmpeg version: N-110511-g55ea1da1c
[   0.000][v][cplayer] FFmpeg library versions:
[   0.000][v][cplayer]    libavutil       58.7.100
[   0.000][v][cplayer]    libavcodec      60.10.100
[   0.000][v][cplayer]    libavformat     60.5.100
[   0.000][v][cplayer]    libswscale      7.2.100
[   0.000][v][cplayer]    libavfilter     9.7.100
[   0.000][v][cplayer]    libswresample   4.11.100

mpv also changed - 3 commits later, but none of them should be able to affect this (bump meson version, some docs change, and some wayland thing which is irrelevant on windows).

So my guess with the data so far is that something in ffmpeg changed in a way which broke it.

Or, something at the build process or used versions changed. Like newer gcc, or newer some other library which behaves slightly differently.

Unfortunately, AFAIK, shinchiro (which builds the Windows versions) doesn't log the packages versions at the releases files, so it's not easy to tell which versions are used exactly, except the ones which are logged by mpv (mpv itself, libass, ffmpeg).

[zouhair]

Using this command line (from the log, with addition of --no-config):

mpv --no-config '--cache' '2048' '--force-media-title=https://www.twitch.tv/videos/1814843938' 'https://d2nvs31859zcd8.cloudfront.net/84a78156146c00e58213_hasanabi_42170717963_1683572491/chunked/index-dvr.m3u8'

For me, it does plays the clip with current master - 0.35.0-378-ga1580b6424 - which is the same version which OP says doesn't play it.

But does it show the whole length of the vod?

Here is a screenshot with the broken mpv and your command: https://i.imgur.com/l6cVOJO.jpeg

Here is a screenshot with the working mpv and your command: https://i.imgur.com/5RiNX9n.jpeg

[Lonely233233]

When playing hls, it becomes a clip

[avih]

But does it show the whole length of the vod?

Yes, it shows 5:41:28, and I can seek anywhere at this range.

Also, for reference, my yt-dlp version is 2023.03.04.

If it's indeed ffmpeg, my guess would be thls commit. If it's indeed this, then still not necessarily an ffmpeg issue, and could also usage pattern by mpv which ffmpeg doesn't expect.

And indeed, the broken log does include this new message which was added at this ffmpeg commit:

[e][ffmpeg] Not detecting m3u8/hls with non standard extension

While the not-broken log doesn't have this message,.

So it's almost certainly due to this ffmpeg commit.

The question now is why.

[zouhair]

I wonder why I have different version of ffmpeg in my logs

My ffmpeg install was not changed

$ ffmpeg
ffmpeg version N-110439-g561746591 Copyright (c) 2000-2023 the FFmpeg developers
  built with gcc 12.2.1 (GCC) 20230401
  configuration: --cross-prefix=x86_64-w64-mingw32- --prefix=/__w/mpv-winbuild-cmake/mpv-winbuild-cmake/build64-v3/install/mingw --arch=x86_64 --target-os=mingw32 --target-exec=wine --pkg-config-flags=--static --enable-cross-compile --enable-runtime-cpudetect --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-avisynth --enable-vapoursynth --enable-gmp --enable-libass --enable-libbluray --enable-libfreetype --enable-libfribidi --enable-libmodplug --enable-libopenmpt --enable-libmp3lame --enable-libopus --enable-libsoxr --enable-libspeex --enable-libvorbis --enable-libbs2b --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-librav1e --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libxvid --enable-libzimg --enable-mbedtls --enable-libxml2 --enable-libmysofa --enable-libssh --enable-libsrt --enable-libvpl --enable-libjxl --enable-libplacebo --enable-libshaderc --enable-libzvbi --enable-libaribcaption --enable-cuda --enable-cuvid --enable-nvdec --enable-nvenc --enable-amf --disable-doc --disable-vaapi --disable-vdpau --disable-videotoolbox --extra-libs=-lstdc++
  libavutil      58.  6.100 / 58.  6.100
  libavcodec     60. 10.100 / 60. 10.100
  libavformat    60.  5.100 / 60.  5.100
  libavdevice    60.  2.100 / 60.  2.100
  libavfilter     9.  7.100 /  9.  7.100
  libswscale      7.  2.100 /  7.  2.100
  libswresample   4. 11.100 /  4. 11.100
  libpostproc    57.  2.100 / 57.  2.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

[zouhair]

Hmm, seems ffmpeg is embedded into mpv.exe

Is there a way to force it to use the external binary?

[avih]

Hmm, seems ffmpeg is embedded into mpv.exe

Correct.

Is there a way to force it to use the external binary?

Not if it's already embedded into mpv.exe.

Also, it doesn't use ffmpeg.exe. It uses the ffmpeg library (dll files on windows), but again, not if mpv is linked statically with the ffmpeg libraries.

[avih]

If it's indeed ffmpeg, my guess would be thls commit. If it's indeed this, then still not necessarily an ffmpeg issue, and could also usage pattern by mpv which ffmpeg doesn't expect.

And indeed, the broken log does include this new message which was added at this ffmpeg commit:

[e][ffmpeg] Not detecting m3u8/hls with non standard extension

Also, this is strange, because the URL does actually have a m3u8 file extension. From the broken log:

[v][ffmpeg] Opening https://d2nvs31859zcd8.cloudfront.net/84a78156146c00e58213_hasanabi_42170717963_1683572491/chunked/index-dvr.m3u8
[...]
[e][ffmpeg] Not detecting m3u8/hls with non standard extension

So maybe it's redirected to some other URL which doesn't have the extension, at which case it's probably an ffmpeg bug, which didn't take this case into account.

This should be reported to ffmpeg.

[zouhair]

This should be reported to ffmpeg.

Dunno how to report it to ffmpeg as this one is embedded into mpv

[Traneptora]

Interestingly, this URL can be accessed directly from ffmpeg.c and it detects it as HLS just fine with ffmpeg -i 'https://d2nvs31859zcd8.cloudfront.net/84a78156146c00e58213_hasanabi_42170717963_1683572491/chunked/index-dvr.m3u8'.

[Traneptora]

However playing the URL directly does produce this error, with mpv.

[Traneptora]

Update: apparently forcing mpv --no-config --demuxer=lavf URL works as expected. The log files suggest the probing creates some sort of request chain than is likely being rejected by the server. Bypassing probing by just using --demuxer=lavf appears to be working.

[zouhair]

Update: apparently forcing mpv --no-config --demuxer=lavf URL works as expected. The log files suggest the probing creates some sort of request chain than is likely being rejected by the server. Bypassing probing by just using --demuxer=lavf appears to be working.

Yes, demuxer=lavf in mpv.conf works.

[zouhair]

Update: apparently forcing mpv --no-config --demuxer=lavf URL works as expected. The log files suggest the probing creates some sort of request chain than is likely being rejected by the server. Bypassing probing by just using --demuxer=lavf appears to be working.

Yes, demuxer=lavf in mpv.conf works.

Ok, putting this option in mpv.conf breaks opening local files for some reason

You need to put this in streamlink config file:

player=mpv --cache 2048 --demuxer=lavf

[Lonely233233]

demuxer=lavf seems to solve the problem of HLS streaming, but other videos cannot be played, such as https://www.youtube.com/watch?v=vyYk_JuUsD4

[zouhair]

demuxer=lavf seems to solve the problem of HLS streaming, but other videos cannot be played, such as https://www.youtube.com/watch?v=vyYk_JuUsD4

You need to put this in streamlink config file:

player=mpv --cache 2048 --demuxer=lavf

[garoto]

player=mpv --cache 2048 --demuxer=lavf

the --cache option doesn't take a numerical value:

--cache Choices: no auto yes (default: auto)

What you might be looking for is --demuxer-max-bytes or --cache-secs.

[zouhair]

player=mpv --cache 2048 --demuxer=lavf

the --cache option doesn't take a numerical value:

--cache Choices: no auto yes (default: auto)

What you might be looking for is --demuxer-max-bytes or --cache-secs.

You're right, it's an old thing, kept doing it as it didn't break anything

[Lonely233233]

demuxer=lavf solves hls streaming problem but I can't open other videos via FF2MPV browser extension

[Lonely233233]

Call CMD input mpv --demuxer=lavf URL to play streaming media when only playing hls streaming video to ensure that the FF2MPV browser extension can play other videos correctly

[zouhair]

Update: apparently forcing mpv --no-config --demuxer=lavf URL works as expected. The log files suggest the probing creates some sort of request chain than is likely being rejected by the server. Bypassing probing by just using --demuxer=lavf appears to be working.

Yes, demuxer=lavf in mpv.conf works.

Ok, putting this option in mpv.conf breaks opening local files for some reason

You need to put this in streamlink config file:

player=mpv --cache 2048 --demuxer=lavf

It seems this is just a workaround and only for twitch vods, a change in ffmpeg broke something

[Lonely233233]

更新：显然强制按预期工作。日志文件表明探测会创建某种请求链，而不是服务器可能拒绝的请求链。仅使用 --demuxer=lavf 绕过探测似乎正在工作。mpv --no-config --demuxer=lavf URL

是的，mpv.conf 中的 demuxer=lavf 有效。

好的，将此选项放在mpv.conf中会出于某种原因中断打开本地文件
您需要将其放在流链接配置文件中：
player=mpv --cache 2048 --demuxer=lavf

似乎这只是一种解决方法，仅适用于抽搐点播，ffmpeg 的更改破坏了一些东西

Yes, demuxer=lavf solves the hls streaming media, but there are other problems that can only be fixed. Fortunately, the 230430 version does not have these problems

[Traneptora]

We've identified the issue as 6b1f68ccb04d791f0250e05687c346a99ff47ea1 but it's unclear atm whether this is something that needs to be fixed upstream or downstream.

[zouhair]

mpv-x86_64-v3-20230514-git-9e716d6 seems to have solved the problem.

[Lonely233233]

mpv-x86_64-v3-20230514-git-9e716d6 seems to have solved the problem.

mpv-x86_64-20230514-git-9e716d6 problem persists

[Lonely233233]

[zouhair]

Yup, it seems it persists in some other websites if mpv is used instead of taking the streamlink passthrough

[Lonely233233]

I don't know how long it will take to fix it

[Lonely233233]

Only use version 230430 first

[rorgoroth]

A reliable test case for broken-ness is chaturbate streams.

Update: apparently forcing mpv --no-config --demuxer=lavf URL works as expected.

This fixes chaturbate streams but breaks youtube videos.
I've reverted the commit to make mpv usable but piping yt-dlp to ffplay on ffmpeg master works fine for me which would suggest possibly something here in mpv will needs tweaking.

[rorgoroth]

Issue seems to be fix with FFmpeg/FFmpeg@954d16f 👍

[Lonely233233]

FFmpeg/FFmpeg@954d16f 的问题似乎已修复 👍

Wait for next Sunday's edition to see

[rorgoroth]

FFmpeg/FFmpeg@954d16f 的问题似乎已修复 👍

Wait for next Sunday's edition to see

Well I'm testing it now and it works for the cases that were broken for me before so it looks good :)

[sfan5]

FWIW mpv now includes a workaround in the form of acababe

[Lonely233233]

230516 has been fixed

[Lonely233233]

We've identified the issue as 6b1f68ccb04d791f0250e05687c346a99ff47ea1 but it's unclear atm whether this is something that needs to be fixed upstream or downstream.
Uosc.log

Version 230518 still has FFMPEG problems when opening some streaming connections, such as "https://play-tx-recpub.douyucdn2.cn/live/super_live-252140rz7aIq14cx--20230519004111/playlist.m3u8?tlink=64674e05&tplay=6467daa5&exper=0&nlimit= 5&us=10000000000000000000000000001501&sign =a50eeefb0afd8e3eeaebac3d1a1a7baa&u=434690231&d=10000000000000000000000000001501&ct=web&vid=37585035&pt=2&cdn=tx"

[zouhair]

mpv-x86_64-v3-20230528-git-959ef84 seems to be working great for me

[Lonely233233]

mpv-x86_64-v3-20230528-git-959ef84 seems to be working great for me

fix？

[zouhair]

Seems like it. Tried it where I had problems and it's working great

[Lonely233233]

Seems like it. Tried it where I had problems and it's working great

"https://cache-m.iq.com/mus/250432001/e9f817dcc0a9b69875d69dcdd88cb680/afbe8fd3d73448c9/34030264688/20200306/51/04/6b9dd4fd0bc5361c8ce30009815a5de3.m3u8?vt=0&ff=ts&qd_originate=h5&k_uid=e46f3631753ad1d293207d902977b87e&_lnt=0&bossStatus=0&tm=1685259573043&qd_p=d203cda2&tls=true&bid=500&src=02020031010024000000&tvid=11907263900&qd_vip=0&qd_time=1685259573388&code=2&px=e0X2zlrsbIcOu08l8Hm1CGTe1z5RsNzSz4PH7Uym2j9orm1wVAyyBBTc052ciNCbHEEOoc3&qd_uri=dash&sgti=48_e46f3631753ad1d293207d902977b87e_1685259573043&vf=e7b01d5f63d228ffc00d4b94628f6c0f" Issues with handling certain streaming links persist