how do you enable the script during livestreaming?

[kempol181]

im watching twitch on MPV and want know if its possible to make webm while watching Live

[ekisu]

As of now, I think it's not possible, as we launch a separate mpv instance to encode, it means it can't access the original cache.

[norcalli]

Is it possible to write the cache to a tempfile and then fork on that cache?

[ekisu]

@norcalli I'm not sure. Even if it's possible to write the cache to a file (cache-file option), I don't think it's usable for anything (and the docs don't make it any clearer).

[Nhlest]

Just asking for confirmation, is there still no way to use this script while watching livestreams?

[ekisu]

None that I know of.

[Igetin]

I made a very basic implementation of this in my fork, something like this in encode.moon should work:

cutStartTime = startTime

-- Dump cache in case of stream
if is_stream
    if mp.get_property('file-format') == 'hls'
        path = utils.join_path(options.output_directory, 'cache_dump.ts') -- ffmpeg/lavf wants .ts for HLS stream
    else
        msg.warn('Not a HLS stream, exiting.')
        message("Encode failed! Check the logs for details.")
        return
    -- This command is still experimental, and the docs state that
    -- the end of the file might be incomplete (esp. audio seems to cut off early).
    -- We’ll add a few seconds of leeway to the end time of the dump for this reason.
    mp.command_native({'dump-cache',
        seconds_to_time_string(startTime, false, true),
        seconds_to_time_string((endTime + 5), false, true),
        path})
    cutStartTime = 0

command = {
    "mpv", path,
    "--start=" .. seconds_to_time_string(cutStartTime, false, true),
-- ...

-- And in the end:
if is_stream
    os.remove(path) -- clean up stream dump

Works for me at least with YouTube and Twitch streams. Probably needs more error handling (like when the start or end time is not in the cache range, and so on)…

This also makes clipping non-live streams a tad faster since the to-be-clipped part doesn’t need to be redownloaded.

This part from the docs is noteworthy:

Dumping a larger part of the cache will freeze the player. No effort was made to fix this, as this feature was meant mostly for creating small excerpts.

Not sure at what point this starts to become problematic, though. Dumping a 2-minute portion of a 1080p@60FPS stream didn’t seem to cause any freezes.

Users might need to set higher limits in demuxer-max-bytes and demuxer-max-back-bytes for longer clips.

---

For those who want a quick solution, you could make a Bash script that continuously downloads the stream to a file and loads that file in mpv. The only downside is that mpv can’t get the length of the stream, so the remaining time doesn’t update as the stream is downloading (seeking forward will still work). Maybe muxing into a different container would solve this, I don’t know. Edit: Nevermind, the length does update properly when playing from a file that’s being appended to. I probably had something weird in my setup while testing it earlier.

streamlink --output ~/stream.ts $1 best &
# or alternatively
# youtube-dl $1 --hls-use-mpegts --no-part -o ~/stream.ts &
while [ ! -f ~/stream.ts ]
do
  sleep 2
done
mpv ~/stream.ts
kill %-
rm ~/stream.ts

[po5]

Great work, didn't know about dump-cache. Here's something that could be improved on: Instead of setting default start & end times to the start and end of livestream, we should mimic the ab-loop-align-cache functionality in lua.