Total time of files in playlist

[kevin-stuart]

There are properties time-pos and time-remaining for the current file. The total time for the current file can be calculated with it, but it might be a good idea to add time-total.

My main issue though: I would like to query the time of other files in the playlist. There are properties for filenames and titles such as playlist/N/filename and playlist/N/title. I would suggest adding a property playlist/N/time-total to get the runtime of file N in the playlist.

[wiiaboo]

Only the current playing file is opened, the other files in the playlist aren't yet, so duration can't be calculated.

[kevin-stuart]

I wrote that I wanted to "query" this. So the idea is that a request to playlist/N/time-total would read this from file N and cache it. This way, it would only be read once for subsequent queries.

It might make sense to also offer this querying ability for other properties such as track-list and chapter-list etc. Essentially, you could prefetch metadata of files in the playlist and make it available for queries. Although, currently I am mainly interested in the playtime, so the rest is just a suggestion based on this idea.

[ChrisK2]

There are properties time-pos and time-remaining for the current file. The total time for the current file can be calculated with it, but it might be a good idea to add time-total.

You mean like duration?

[kevin-stuart]

Yes. I see, so this exists for the current file. Great. The name is even better than my suggestion. Thank you for pointing this out! I think I did not see this because it was not grouped with the time-* properties when I was looking at them.

My main point is that I want to get information from files in the playlist that are not currently playing.

[ghost]

Extremely unlikely to get ever implemented.

[kevin-stuart]

Too bad. It would be nice to be able show the time of each file in the playlist and calculate the total remaining playtime by using this.

Kodi, VLC and Zoom Player seem to be able to show the total playtime of a file in their playlists. I think SMPlayer also supported did. Does it mean that other players that embed MPV would not be able to do this either?

Is there some sort of compromise to make some capability for this available?

[ghost]

Sigh...

[kevin-stuart]

Sorry. I did not mean to offend or annoy. I was just surprised that this feature is unlikely, since it seems common. And for me, it is a very good feature. Usually MPV is the best and most feature complete player. I'll probably try to work around with external calls to mediainfo or something, but that will be much more problematic.

[ghost]

The thing is that mpv won't open every file on its own playlist just to probe the duration of each playlist entry.

[kevin-stuart]

No, that would be inefficient especially if not needed. I agree that MPV should not do it on its own when opening a playlist.

What I propose is a facility to instruct MPV to probe only a specific file on request. So if I want to probe the entire playlist, I could do it. Or I could just probe the next file. This could be used with scripts or the IPC.

For example, you could add a command: query_playlist N duration with N as index in the playlist. Right now, I am only interested in the duration, but maybe other people pop up and want to query file in the playlist for something else. So this could be used to extend this as well. I definitely can see some utility in this feature.

For example, one could create a playlist view with durations if people want MPV to query all files in their playlists. Or a plugin could bind a key to request the duration of all remaining files, and based on the current position of time in the file and in the playlist, the remaining time could be shown.

Currently I think I could actually work around this missing feature with mediainfo now for my use case.

[ghost]

No, just open another mpv instance to do that (run it with --frames=0 or so).

[kevin-stuart]

Sorry for still asking questions: I looked at the manual to see how this should be used. With --frames=0, should I use --script=my_script.lua and then output the duration with my_script.lua? Is there another way to pass the command without needing a file for the script?

Also, while this could be used as a substitute for mediainfo, I think it is not possible to call this from a Lua script directly? According to the manual, the run command is run detached, so I guess there is no result.

[ghost]

You'd have to start a new mpv instance from the script, yes. This is pretty roundabout, but mpv also would have to open the file internally.

[oltodosel]

https://github.com/oltodosel/mpv-scripts/blob/master/total_playtime.lua

[kevin-stuart]

Looking at the lua script, this still requires ffprobe. Maybe it would make sense to request an API that can be used to probe files? This could be used with mpv in scripts. It could be used for all sorts of metadata, not just the total time.

[oltodosel]

Who doesn't have ffmpeg? Fork it however you want.

[kevin-stuart]

I think it would be easier and more efficient to have an API compared to calling a process and parse the output, which might also change. It would make mpv more independent from external tools. It's just a suggestion, but I think it would make mpv better.

[oltodosel]

I partially agree. But it works at the moment, and I'm lazy.

[kevin-stuart]

Well it's great solution and it works, I liked it very much, BTW, thank you for posting it! The script is great and indded, I do have ffmpeg/ffprobe installed on my machines. I solved it with mediainfo (which is similar to using ffprobe) before posting my initial request, which is also an external tool. But I have a non-trivial use case in mind that it should ideally work with just mpv installed on machines.

[snowman]

if we directly run main function:

-- Filename: damn_it.lua
local msg = require 'mp.msg'

function main ()
   filename = mp.get_property("filename")
   duration = mp.get_property("duration")

   msg.error("filename: ", filename)
   msg.error("duration: ", duration)
end

main()

& to generate the sample videos: \ffmpeg -f lavfi -i testsrc -t 30 -pix_fmt yuv420p -loglevel quiet sample-01.mp4

Run mpv sample-01.mp4 shows output:

[damn_it] filename:  nil
[damn_it] duration:  nil
Playing: sample-01.mp4
 (+) Video --vid=1 (*) (h264 320x240 25.000fps)
VO: [gpu] 320x240 yuv420p
V: 00:00:00 / 00:00:30 (0%)

---

but when run the main function by hook:

-- main()
mp.add_hook("on_load", 50, main)

output

Playing: sample-01.mp4
[damn_it] filename:  sample-01.mp4
[damn_it] duration:  nil
 (+) Video --vid=1 (*) (h264 320x240 25.000fps)
VO: [gpu] 320x240 yuv420p
V: 00:00:00 / 00:00:30 (0%)

NOTICE the filename is NOT nil anymore but shows [damn_it] filename: sample-01.mp4. so why couldn't we get the duration value of current playing video?

[snowman]

... so basically the load hook is only load file ...

[snowman]

After checking document again, i found on_preloaded does what i needed.

-- Filename: damn_it.lua

local msg = require 'mp.msg'

function main ()
   filename = mp.get_property("filename")
   duration = mp.get_property("duration")
   time_pos = mp.get_property("time-pos")

   msg.error("filename: ", filename)
   msg.error("duration: ", duration)
   msg.error("time_pos: ", time_pos)
end

mp.add_hook("on_preloaded", 50, main)
-- mp.add_key_binding("m", "not", main)

Run mpv sample-01.mp4 shows output:

[damn_it] filename:  sample-01.mp4
[damn_it] duration:  30.000000
[damn_it] time_pos:  nil
 (+) Video --vid=1 (*) (h264 320x240 25.000fps)
VO: [gpu] 320x240 yuv420p
V: 00:00:00 / 00:00:30 (0%)

[snowman]

mp.register_event("file-loaded", main) would not result in nil value, cheers

[ghost]

@kevin-stuart I mean yes, in theory such an API command could be added. But I'm still not entirely sure of the value it would have. At least if the file in question has the duration in the file headers, it'd actually be pretty easy to add.

Likewise, it would be simple to add some sort of duration metadata field to playlist entries, which wouldn't be populated automatically (but instead you'd have to do it manually, or possibly parse it from a playlist format like m3u). But I think nobody asked for such a feature.

@snowman: yes, loading is asynchronous, so you have to use the correct event where it's first available.

[Iftakharpy]

Implementing this feature would be nice.