cache2: uncrustify
stream: rename cache2.c to cache.c

I never found cache1.c (whatever it was named, if it ever existed).

cache2.h will be deleted later, so don't go through the trouble of
renaming it.
core: use STREAM_CTRL instead of accessing stream_dvd internals

Some code in mplayer.c did stuff like accessing (dvd_priv_t *)st->priv.
Do this indirectly by introducing STREAM_CTRL_GET_DVD_INFO. This is
extremely specific to DVD, so it's not worth abstracting this further.

This is a preparation for turning the cache into an actual stream, which
simply wraps the cached stream. There are other streams which are
accessed in the way DVD was, at least TV/radio/DVB. We assume these
can't be used with the cache. The code doesn't look thread-safe or fork
aware.
stream: misleading statement
stream_dvd: remove some deadly insane code

Of course all of stream_dvd.c (as well as libdvdread) is completely
insane, but at least this hack for ancient broken compilers on really
obscure platforms should be safe to remove.
stream_cdda, stream_vcd: check read buffer size

These assumed that the buffer provided with fill_buffer() was at least
sector sized, instead of checking the size parameter.

This is just a cleanup, since every caller made sure to align everything
on sector sizes, if a stream has the sector size set.
stream: move VCD specific stuff to stream_vcd

I don't even know what VCDs are. A prehistoric version of the DVD or so.
stream: remove unused function
stream: remove pointless check
manpage: adjust y4m output example

The additional flags are needed to get the muxer to write the source
video frame rate (instead of a fallback) for 100% equivalence to the
replaced MPlayer/mplayer2 y4m writer.
mplayer: try to handle PTS forward jumps

Raw MPEG streams can contain PTS discontinuities. While the playback
core  has obvious code for handling PTS going backward, PTS going
forward was as far as I can see not handled.

This can be an issue with DVD playback. This wasn't caught earlier,
because DVD playback was just recently switched to demux_lavf, which
implies -no-correct-pts mode. This mode doesn't use PTS in the same way
as the normal playback mode, and as such was too primitive to be
affected by this issue.

Use the following heuristic to handle PTS forward jumps: if the PTS
difference between two frames is higher than 10 seconds, consider it a
reset. (Also, use MSGL_WARN for the PTS discontinuity warnings.)

In this particular case, the MPEG stream was going from pts=304510857
to pts=8589959849 according to ffprobe (raw timestamps), which seems a
bit strange.

Note that this heuristic breaks if the source video has unusually high
frame times. For example Rooster_Teeth_Podcast_191.m4a, an audio file
with a slide show encoded as MJPEG video track.
vo_lavc: silence warning when writing y4m

Apparently a ffmpeg issue. Hide the warning because it's annoying.
Workaround suggested by divVerent.
mplayer: save sub-visibility property
gl_video: remove redundant condition
options: remove --stereo

Whatever this was supposed to be originally, it doesn't have much value
anymore. It just forced ad_mpg123 to upmix mono to stereo by default
(the audio chain can do that). As an option, it was mostly useless and
misleading, so get rid of it.
support "-" as file name when encoding

This workaround sucks. avio just does not support "-" - and ffmpeg's
command line binaries work around it. FOUR TIMES. DIFFERENTLY.

WHY DOESN'T AVIO DO THIS RIGHT TO BEGIN WITH?
core: introduce separate VOCTRLs for screensaver stop/resume

This is slightly better because VOCTRL_RESUME/VOCTRL_PAUSE are usually
needed by VOs to know whether video is actually being played (for
whatever reason), and they wouldn't be passed to the backend's VOCTRL
handler, like vo_x11_control().

Also try to make sure that these flags (both pause state and screensaver
state) are set consistently in some corner cases. For example, it seems
enabling video in the middle of playing a file while the player is
paused would not set the paused flag.

If codec initialization fails, destroy the VO instead of keeping it
around to make sure the state is consistent.

Framestepping is implemented by unpausing the player for the duration of
a frame. Remove the special handling of VOCTRL_PAUSE/RESUME in these
cases. It was most likely needed because these VOCTRLs used to be
important for screen redrawing (blatant guess), which is now handled
completely differently. The only potentially bad side-effect is that the
screensaver will be disabled/reenabled for the duration of one frame.
x11: enable screensaver when paused, rename/change --stop-xscreensaver

Use the recently introduced screensaver VOCTRLs to control the
screensaver in the X11 backend. This means the behavior when paused
changes: the old code always kept the screensaver disabled, but now the
screensaver is reenabled on pausing.

Rename the --stop-xscreensaver option to --stop-screensaver and make it
more generic. Now it affects all backends that respond to the
screensaver VOCTRLs.
w32: enable screensaver when paused

This is quite similar to the previous commit.

Untested. I'm not sure if this is how it's supposed to work. At least
--no-stop-screensaver should work in any case.
command: use more standard time format for clock property

%k is not very standard. The manpage notes them as conforming to
"Olson's timezone package", and it's not standard C89, C99 or POSIX.
mingw doesn't provide it, and even some of the smaller Linux libcs
don't have support.

Use %H instead. This gives slightly different results, but I think
this is ok. Difference in behavior between these summarized:

  %k: "single digits are preceded by a blank"
  %H: "range 00 to 23"