summaryrefslogtreecommitdiffstats
path: root/audio
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-05-20 02:54:06 +0200
committerwm4 <wm4@nowhere>2019-09-19 20:37:04 +0200
commit6f7260d29c9dd7f91e3190626056ec766815d3c0 (patch)
tree19ae7039d5ae89f21e3b4ce5f5c88f0dc27d1930 /audio
parent5ebbde7327f3a6f7946fd7d59116b93c933d3f83 (diff)
downloadmpv-6f7260d29c9dd7f91e3190626056ec766815d3c0.tar.bz2
mpv-6f7260d29c9dd7f91e3190626056ec766815d3c0.tar.xz
manpage: document that backward playback from the end does not work
Not specifying a --start or using --start=100% with --play-direction=backward usually does not work. The demuxer gets no packets and immediately enters EOF state, which then hangs because backward playback mode neither considers this mode, nor propagates the EOF. As far as demuxer implementations are concerned, this behavior is OK and even wanted. Seeking near the end with SEEK_FORWARD set is allowed not to return any packets (so a normal relative forward seek as done by the user would end playback). Seeking exactly to the end or past it without SEEK_FORWARD set is probably also sane. Another vaguely related issue is that a backward seek during playback start does not "establish" the demux position correctly: if stream A hits the next keyframe and seeks back, while stream B has not had a chance to read a packet yet, then stream B will never try to read from the old position. The effect is that stream B (and thus playback) will effectively miss the seek target. This is "random" because it depends on the order and number of packet read calls made by the decoders. Fixing this is probably hard, and requires extending the already complex state machine with more states, so turn the manpage into a TODO list for now.
Diffstat (limited to 'audio')
0 files changed, 0 insertions, 0 deletions