mpv
mpv copied to clipboard
mpv-player
seeking before the cache in an unterminated hls stream
Before requesting a new feature make sure it hasn't been requested yet. https://github.com/mpv-player/mpv/labels/meta%3Afeature-request
Expected behavior of the wanted feature
When loading a hls stream that has segments in the past mpv will not allow you to seek to those segments. Specifying --rebase-start-time=no will show the play position correctly at XX:XX into the stream, but seeking is always capped to the position that the stream was started. As you can see in the below log, mpv is adjusting the seek time to what it has in cache, even though there would be segments available prior to the cache value.
Alternative behavior of the wanted feature
Log file
2023-07-22 10:00:02.050851-0600 Tablo-iOS[7365:815118] [mpv] [cplayer] debug: Run command: seek, flags=64, args=[target="-120.000000", flags="relative", legacy="unused"]
2023-07-22 10:00:02.051003-0600 Tablo-iOS[7365:815118] [mpv] [lavf] v: queuing seek to 2060.097000
2023-07-22 10:00:02.051123-0600 Tablo-iOS[7365:815118] [mpv] [lavf] v: cached range 0: 2176.984000 <-> 2183.133367 (bof=1, eof=0)
2023-07-22 10:00:02.051231-0600 Tablo-iOS[7365:815118] [mpv] [lavf] v: ...using this range for in-cache seek.
2023-07-22 10:00:02.051332-0600 Tablo-iOS[7365:815118] [mpv] [lavf] v: adjust seek target 2060.097000 -> 2177.027267
Does anybody have a thought on this? Is this something currently supported that I just can’t get to work?
Checking back in here. If anybody has a thought it would be greatly appreciated
bump.
i'm also looking for a solution: i want to "start playing a stream from a point in time in the past".
just for reference, it's working with vlc like this: vlc --start-time=n https://....m3u8, where n is a number of seconds. (It's a positive number, namely the length of the seekable duration of the stream, minus the number of seconds you want to jump back. e.g. 7200-1800=4400 for a stream than can seek 2h and you want to play starting 30m back.)
PS: mpv --start=n ... does not work: It starts from the current point in time in the live stream, or does not play at all, depending on setting absolute, relative positive, or relative negative values.
A follow up here. I'm wondering if a better question is what constitutes a non-seekable stream. The docs for force-seekable read like this:
--force-seekable=<yes|no>
If the player thinks that the media is not seekable (e.g. playing from a pipe,
or it's an http stream with a server that doesn't support range requests),
seeking will be disabled. This option can forcibly enable it.
For seeks within the cache, there's a good chance of success.
In my case the stream is an HLS stream and the server 100% supports range requests. The only thing I can think of is that mpv is saying the stream is not seekable because it's an unterminated (aka, live) playlist. Setting force-seekable to yes only causes strange behavior.
Would love to have any type of information from the mpv team. Been over a year with nobody even commenting on this ticket from the team.
I like to support this ticket, since i am also searching for a solution for a quite similar (if not the same) issue i am facing ... and was just about to create another feature request about this.
My use case: I have a camera stream recorded and provided as HLS livestream containing ALL segments. I want to enable the watchers of this HLS stream to seek within the whole recording.
With VLC player, this is working as expected, but on MPV player i am not able to get this running: Running mpv with option '--force-seekable=yes --demuxer-lavf-o=live_start_index=0' shows the stream from the beginning, but seeking is not working, and the duration information seems to be corrupted or just not known - it shows the current stream position as total duration, and not the aggregated durations of the current playlist entries.
To repoduce the scenario, just let ffmpeg create a "test-live-stream", e.g. with
ffmpeg -re -f lavfi -i testsrc=size=1280x720:rate=30 -c:v libx264 -preset veryfast -tune zerolatency -g 120 -keyint_min 120 -sc_threshold 0 -pix_fmt yuv420p -f hls -hls_time 4 -hls_list_size 0 -hls_flags independent_segments -hls_segment_filename "segment_%04d.ts" stream.m3u8
and open the stream.m3u8 with VLC resp. with MPV.
It would be great to hear from the MPV experts:
- Does MPV actually support the live-stream playback with seeking, but my mpv config misses some aspect?
- I read that there is a related ffmpeg issue, but without reference. If so, do you have the reference, and how is VLC solving this issue? I thought this is also based on ffmpeg!?
@quidamschwarz Exactly the same situation. The stream is seekable with range requests but MPV refuses to make the requests. And when I make it force-seekable it gets all confused.
- I read that there is a related ffmpeg issue, but without reference. If so, do you have the reference, and how is VLC solving this issue? I thought this is also based on ffmpeg!?
Not really, VLC has its own adaptiveDemuxer. To be frank, the HLS demuxer in FFmpeg has been neglected for years. For instance, it doesn't support basic discontinuity tags, a bug that has plagued the system for nearly a decade and is still open in the issue tracker. As mentioned here, to address several HLS/DASH-related issues in mpv, one potential direction could be implementing an mpv-specific demuxer, similar to what was done with MKV. Perhaps it doesn't have to start from scratch; porting VLC's adaptiveDemuxer could be a viable starting point? I'm not sure, but this is indeed a massive undertaking. Unless someone is very familiar with both mpv and VLC, it might remain on the wishlist for a long time.
@lcksk Many thanks for your enlightening reply and the provided link. I still had the hope that it might be a special ffmpeg config that i had missed so far, or that a simple fix inside MPV would be possible. From users perspective it feels like not much is missing, since as soon as the playlist is finalized (e.g. has a end-tag), all works fine with the MPV player. And this is actually my current workaround for a "seekable live-stream": I handle two MPV player at once, one to show the latest/live portion of the stream, and one player that is activated when the user seeks, and that second player is fed with a finalized playlist. It somehow felt like it is just the (unknown) duration of the stream that confuses MPV player. But yes, this user perspective just ignores any architectural restrictions/decisions that MPV player is bound to.
@quidamschwarz with two players how do you handle that the stream is still growing in duration once the user seeks? Is that just ignored?
@bryandunbar I have implemented my own player controls, so in particular a custom seek bar, in which i kinda fake the duration by taking the diff of the current timestamp and the timestamp of the start of the live stream (minus some latency duration). When seeking to the max left of the bar, the "live player" is active, when seeking to some other part, the "replay player" gets active which reads the finalized playlist. When this "replay player" reaches the end of its playlist, it is reloaded with a new fresh finalized playlist. It's a hack, but works sufficiently well for my case. But for sure i would like to get rid of this hack.
As a workaround the following works
mpv --force-seekable=yes --demuxer-lavf-o=live_start_index=0 https://example.com/example.m3u8
Where the start index is basically the segment number you want to start at, which can be 0. In my case my hls_time is 10 seconds coming from ffmpeg so this is basically estimated seek_position_in_seconds / 6 = index.
How do I get off this email response list
On Sun, Nov 10, 2024, 8:23 PM Aaron Sewall @.***> wrote:
As a workaround the following works
mpv --force-seekable=yes --demuxer-lavf-o=live_start_index=0 https://example.com/example.m3u8
Where the start index is basically the segment number you want to start at, which can be 0. In my case my hls_time is 10 seconds coming from ffmpeg so this is basically estimated seek_position_in_seconds / 6 = index .
— Reply to this email directly, view it on GitHub https://github.com/mpv-player/mpv/issues/11990#issuecomment-2467204199, or unsubscribe https://github.com/notifications/unsubscribe-auth/APH5Y6XJPBSZGCLSOZY6SBT2AAWNBAVCNFSM6AAAAAA2T5HZ7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRXGIYDIMJZHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
As a workaround the following works
mpv --force-seekable=yes --demuxer-lavf-o=live_start_index=0 https://example.com/example.m3u8Where the start index is basically the segment number you want to start at, which can be 0. In my case my
hls_timeis 10 seconds coming from ffmpeg so this is basically estimatedseek_position_in_seconds / 6 = index.
As mentioned, we have both tried this and while it does start the playback from the beginning, seeking does not work as expected:
“ Running mpv with option '--force-seekable=yes --demuxer-lavf-o=live_start_index=0' shows the stream from the beginning, but seeking is not working, and the duration information seems to be corrupted or just not known - it shows the current stream position as total duration, and not the aggregated durations of the current playlist entries.”
Seeking in HLS streams should be fixed now on FFmpeg's side as of a few days ago, I don't have a HLS stream that allows you to seek in the past to test this specific issue however
Seeking in HLS streams should be fixed now on FFmpeg's side as of a few days ago, I don't have a HLS stream that allows you to seek in the past to test this specific issue however
Thanks @llyyr. How would we test this with a stream on mpv ?
How would we test this with a stream on mpv ?
How would I know? What stream were you testing with when you opened the issue? AFAIK you can't seek to the past in live HLS streams
I guess I meant is there a new version of MPV that is using a new version of ffmpeg. I have a stream I could test, but your comments was quite vague.
On Nov 11, 2024, at 11:10 AM, llyyr @.***> wrote:
How would we test this with a stream on mpv ?
How would I know? What stream were you testing with when you opened the issue?
— Reply to this email directly, view it on GitHub https://github.com/mpv-player/mpv/issues/11990#issuecomment-2468763343, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHT6QIDOC4PFQY7YC5PPU32ADXK5AVCNFSM6AAAAAA2T5HZ7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRYG43DGMZUGM. You are receiving this because you were mentioned.
I guess I meant is there a new version of MPV that is using a new version of ffmpeg. I have a stream I could test, but your comments was quite vague.
Build ffmpeg master yourself if you're on linux, if you're on windows the usual nightly build repos should have it by now
Got it. Thx! I’ll report back.
On Nov 11, 2024, at 11:14 AM, llyyr @.***> wrote:
I guess I meant is there a new version of MPV that is using a new version of ffmpeg. I have a stream I could test, but your comments was quite vague.
Build ffmpeg master yourself if you're on linux, if you're on windows the usual nightly build repos should have it by now
— Reply to this email directly, view it on GitHub https://github.com/mpv-player/mpv/issues/11990#issuecomment-2468769754, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHT6QMFUVMIUDCDXMON75T2ADXXRAVCNFSM6AAAAAA2T5HZ7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRYG43DSNZVGQ. You are receiving this because you were mentioned.