[MPlayer-dev-eng] Architectural TODO items

[Uoti Urpala]

These are somewhat random issues that I've considered working on at some
point. Since these have not been discussed much many developers are
probably not aware of the associated problems at all, so I thought it
would be useful to document them to some degree.



1) Execute commands independently of frames / associated OSD issues

There are several reasons why running user/slave commands independently
of frame updates and without forcing unpause would be useful. The
"running commands" part should actually be pretty easy to implement; the
problematic part is OSD updates. MPlayer does not have a good UI
interface that could show information independently of frames.

If video FPS is high enough then just waiting until the next frame to
change OSD contents isn't too bad. However if FPS is low (possibly due
to -speed), the command in question is pause (and showing pause status
in the OSD is wanted), or another command is run while paused then
something else is needed.

The common VOs should support reading current image efficiently enough
that it could be used when paused at least. Thus OSD content could be
added without decoding a new frame. This still leaves the case where the
currently displayed frame already has some OSD content but you now want
to _change_ it (to pause for example); getting the existing image isn't
enough unless you can erase the old OSD content. One possibility would
be to always keep the part of original image that's going to be
overwritten by OSD, but that would have a performance penalty when the
OSD is active. Another option would be to wait until the next frame
before pausing or updating OSD in that case (so that when paused you'd
always have a copy of the current frame with no OSD modifications).



2) Fix seeks to be relative to displayed position, not demuxer

Currently relative seek commands work by directly sending the direction
and amount to the demuxer. This isn't quite right; demuxer position is
an internal variable and the user doesn't normally care what it is. A
situation where I've noticed the problem in practice is seeking a short
amount backwards with a high playback speed. I have the left arrow key
bound to "seek -1". What happens with a high speed setting is that the
demuxer seeks one second back, then MPlayer fills the audio buffer when
starting playback and during that advances the demuxer almost the full
second back forwards (filling the audio out buffer requires
playback_speed times its "physical" duration of decoded audio data). The
practical effect is that it's very hard or even impossible to go
backwards in the file using one second steps. If better video output
buffering is added in the future it will make this problem worse.

The most practical solution might be to still use relative seeks but
adjust them by the distance between currently displayed pts and demuxer
pts. Measuring the latter (to the degree it can even be defined) is
somewhat arbitrary; using either the pts of latest packet returned by
the demuxer or latest video packet (ignoring other types) might work
well enough.



3) Allow multiple instances of playback chain / remove globals

Some example uses for playing two files simultaneously are playing two
encodes synchronized in parallel to compare them, or showing the
original video and what it looks like after encoding. A major part of
the work to implement this is to remove globals which would conflict
between the decoder instances and move them to allocated data
structures; in addition to the functionality benefits this would allow
cleaning up some of the code.

Option handling is one big subpart of the needed globals removal.
Currently almost all options are global variables. I think a practical
way to handle this would be to create a per-playback struct holding all
option values and store a pointer to that in subsystem instances such as
decoders. Initially the option values would be stored in both the struct
and globals; removing the globals and changing all users to refer to the
value in the struct instead could then be done gradually per option
rather than needing to change every part at once. The struct might be
split up into more organized parts in the future, but I think it's
probably better to do the initial option variable removal with a simple
structure.

Currently vo instances have no private data structures but store
everything in globals and static variables. That would need to be
changed; since there are lots of vo types I think it's better to do this
too in a way that allows converting them one at a time rather than
requiring all to be done in one go.