mpv/options
wm4 775b86212d video: add option to reduce latency by 1 or 2 frames
The playback start logic explicitly waits until the first frame has been
displayed. Usually this will introduce a wait of 1 vsync. For normal
playback this doesn't matter, but with respect to low latency needs,
this only leads to additional data getting queued up in the demuxer or
network buffers.

Another thing is that the timing logic decodes 1 frame ahead (= 1 frame
extra latency) to determine the exact duration of a frame.

To be fair, there doesn't really seem to be a hard reason why this is
needed. With the current code, enabling the option does lead to A/V
desync sometimes (if the demuxer FPS is too inaccurate), and also frame
drops at playback start in some situations. But this all seems to be
avoidable, if the timing logic were to be rewritten completely, which
should probably happen in the future. Thus the new option comes with the
warning that it can be removed any time. This is also why the option has
"hack" in the name.
2018-03-03 02:38:01 +02:00
..
m_config.c options: minor cleanup to --no-... handling 2018-02-13 17:45:29 -08:00
m_config.h options: simplify mp_get_config_group() memory management 2018-01-18 00:59:07 -08:00
m_option.c m_option: remove unneded compatibility features 2018-02-28 00:55:06 -08:00
m_option.h m_option: remove unneded compatibility features 2018-02-28 00:55:06 -08:00
m_property.c
m_property.h command: read the diff if you want to know 2017-10-21 21:13:53 +02:00
options.c video: add option to reduce latency by 1 or 2 frames 2018-03-03 02:38:01 +02:00
options.h video: add option to reduce latency by 1 or 2 frames 2018-03-03 02:38:01 +02:00
parse_commandline.c m_option: remove redundant indirections 2017-07-02 13:07:36 +02:00
parse_commandline.h
parse_configfile.c
parse_configfile.h
path.c msg: reinterpret a bunch of message levels 2017-12-15 22:28:47 -08:00
path.h