diff options
author | wm4 <wm4@nowhere> | 2019-05-20 02:54:06 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-09-19 20:37:04 +0200 |
commit | 6f7260d29c9dd7f91e3190626056ec766815d3c0 (patch) | |
tree | 19ae7039d5ae89f21e3b4ce5f5c88f0dc27d1930 /audio/decode | |
parent | 5ebbde7327f3a6f7946fd7d59116b93c933d3f83 (diff) | |
download | mpv-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/decode')
0 files changed, 0 insertions, 0 deletions