"Dmitrij D. Czarkoff" writes:
> FWIW on my ThinkPad E325 the performance of mpv is really bad.  (MPlayer
> does no good here either, although ffplay copes with everything just
> fine.)  I also noticed that it has problems with unmuting if master
> output was muted before mpv started.  To really unmute I had to mute
> sound in mpv by pressing "m" and then unmute it by pressing Mute button
> on my keyboard;  no other combination worked out.

Not sure if this is related, but sound is very choppy for me, and:

AV: 00:05:23 / 01:40:58 (5%) A-V:  0.020
[ao/sndio] Blocking until remaining audio is played... (sndio design bug).

was added in this commit:
https://github.com/mpv-player/mpv/commit/387d5f55e639425bfb6ee1efec4e21202e5642ad

   "ao_sndio: print a warning when draining audio

   "libsndio has absolutely no mechanism to discard already written audio
    (other than SIGKILLing the sound server). sio_stop() will always block
    until all audio is played. This is a legitimate design bug.

   "In theory, we could just not stop it at all, so if the player is e.g.
    paused, the remaining audio would be played. When resuming, we would
    have to do something to ensure get_delay() returns the right value. But
    I couldn't get it to work in all cases."

I was previously using a crappy hand-rolled port of... 0.4.something?
which wasn't nearly as slow.

> | -CATEGORIES =       x11 multimedia
> | +CATEGORIES =               multimedia x11
> 
> I am not sure that mpv's primary category should be "x11".  I am not
> sure how MPlayer ended up there, but I wouldn't expect mpv at x11/mpv.

Another reason why multimedia is a more sensible choice:

$ ls /usr/ports/x11 | wc -l
     394
$ ls /usr/ports/multimedia | wc -l
      80

> | +USE_GROFF =                Yes
> 
> Apparently mandoc has some formatting issues with this page.  As I
> gather mandoc is not yet supposed to deal with rst2man output.

Looks like minor spacing issues to me. But the length of the manpage
makes it impossible to audit, so I agree with USE_GROFF here.

-- 
Anthony J. Bentley

Reply via email to