[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[emms-help] mpv player alternative with json-ipc

From: Mike Kazantsev
Subject: [emms-help] mpv player alternative with json-ipc
Date: Fri, 13 Apr 2018 20:39:01 +0500


Have been using recently-merged dochang/emms-player-mpv emms backend
for a while, but recently had an thought to get track durations from
mpv, as pre-scanning them otherwise from mostly-sshfs sources is quite

So implemented a different backend for mpv using its bidirectional
"JSON IPC" API with long-running mpv instances (kinda like mpd):


Advantages of using mpv this way vs player-simple (that I can think of):

- Access to any properties, including track metadata, any file/stream
  info, video/audio output info, playlist info (if added as such).

  Can be used with e.g. long-running internet radio URLs to fetch
  currently playing track information, as parsed by mpv from icy tags.

- Precise event monitoring - e.g. only call emms-player-started when
  audio actually starts playing, taking any delay due to mpv startup,
  youtube-dl or file buffering (netwok sources) into account.

- Feedback from mpv on any command (success/error) and playback state
  (e.g. get playback position info).

- Maybe some minor performance gains due to mpv staying initialized in
  memory, instead of starting from scratch for every track.

Apparent disadvantages:

- More work emacs-side to handle events from JSON-IPC.
  For static files, it's usually just ~5-10 JSON lines per file.

- More complex implementation.

As I've also noticed that mpv backend was recently merged info emms,
wanted to present this one here as well, in case it might be for
whatever reason preferrable to player-simple mpv wrapping.

Not sure if it is the case, given more complex code, but also not sure
if maybe someone can think of other simple backend deficiencies which
this one can address nicely.

If it is worthy replacement for simple mpv backend for whatever reason
- let me know, can adjust code style to fit better with other .el
files in the repo, and get rid of dependencies like s.el/dash.el
(only used in couple of places).

Any other comments are also welcome, of course.


Mike Kazantsev // fraggod.net

reply via email to

[Prev in Thread] Current Thread [Next in Thread]