[Feature request] internally pause one-frame-long videos

[rr-]

mpv version and platform

mpv git-814dacd (C) 2000-2016 mpv/MPlayer/mplayer2 projects built on Tue Aug 16 10:00:45 CEST 2016
Linux tornado 4.6.4-1-ARCH #1 SMP PREEMPT Mon Jul 11 19:12:32 CEST 2016 x86_64 GNU/Linux

Description

There are a few issues with the current approach to showing the images (loop-file=yes):

• it eats CPU (up to 5% on my Atom without me doing anything) → eats battery.
• needlessly clogs on network shares (SSHFS, Samba) → not sure about this one. Might be placebo - while strace doesn't show that the files are reopened, there is certainly a lot going on every loop.
• certain operations such as video-rotate aren't reflected immediately.

All of these issues seem to be mitigated when I enable pause=yes, but this has the big downside that it affects legitimate videos and animated GIFs.

I think it would be reasonable to have mpv detect the number of frames and internally enable pause=yes if it's confirmed to be 1, and lift it on file exit - enough to implement it upstream rather than leaving it to LUA scripts.

This should affect only video-only streams - for example, audio files with embedded album covers should be left unaffected.

[haasn]

Note that there's a lua script which can crudely approximate this, although it only works reliably for local videos (not URLs).

I would personally also like native support for this - essentially, there should be no distinction between videos and images other than how many frames it has (IMO).

For example a .gif with a single frame is an image file but a .gif with multiple frames is a video file -- similarly, a .h264 file containing only a single frame is often used to e.g. compare x264 against libjpeg for compressing still images.

[ghost]

Actually, maybe this could be done as some sort of conditional --keep-open? Maybe with a configurable wait time that can be infinite as well.

[haasn]

Seems reasonable. Basically, a keep-open that only triggers if only one frame was displayed? (Which also solves the “we don't know the number of frames in advance” problem, since you're checking it at the time keep-open fires i.e. at the end of playback)

Maybe it would actually be even better to have the logic be something like “keep open if file duration was below X”, since that may enable some other useful scenario.

[ghost]

This idea actually kind of breaks with seeking. If a seek is done, then you don't know if there were any video frames before the seek. I guess I'll ignore this corner case.

[haasn]

@wm4 Amusingly enough, I would consider “pause when seeking past the end of the file” another feature I would like to have. Usually the only time I do that is when I accidentally use nonexact 1 minute seeks one too many times (misjudging the length of the video), and in this case I would prefer mpv to stop at the end of the file and let me seek backwards again.

[ghost]

Implemented a variant of this. Separate feature requests in new issues please.