Currently every single AO was implementing it's own ringbuffer, many times
with slightly different semantics. This is an attempt to fix the problem.
I stole some good ideas from ao_portaudio's ringbuffer and went from there.
The main difference is this one stores wpos and rpos which are absolute
positions in an "infinite" buffer. To find the actual position for writing /
reading just apply modulo size.
The producer only modifies wpos while the consumer only modifies rpos. This
makes it pretty easy to reason about and make the operations thread safe by
using barriers (thread safety is guaranteed only in the Single-Producer/Single-
Consumer case).
Also adapted ao_coreaudio to use this ringbuffer.
This is hopefully the start of something good. ca_ringbuffer_read and
ca_ringbuffer_write can probably cleaned up from all the NULL checks once
ao_coreaudio.c gets simplyfied.
Conflicts:
audio/out/ao_coreaudio.c
This allows having properties like time-pos in the window title update
properly. There is a danger of this causing significant CPU usage,
depending on the properties used and the window manager.
Instead of implicitly changing the window title on config(), do it as
part of the new VOCTRL.
At first I wanted to make all VOs use the VOCTRL argument directly, but
on a second thought it appears vo_get_window_title() is much more useful
for some (namely, if the window is created lazily on first config()).
Not all VOs are changed. Wayland and OSX have to follow.
This make the intention more apparent, and some VOs are actually using
true instead of VO_TRUE in some places. Hopefully this changes makes it
less confusing (instead of more).
The C99 constants true/false are defined to 1/0 as well, so this commit
doesn't actually change anything.
This code calculates the source/display video rectangle for scaling with
most VOs. It's responsible for clipping the display rectangle against
the screen and adjusting the source rectangle accordingly.
Until now, it assumed that the video was centered on the screen. Change
this so that any rectangle is possible. Basically, the clipping is
extended to two sides (e.g. left and right), instead of handling both at
the same time.
The rounding behavior slightly changes. It seems to be slightly better
than before. On the other hand, the video is not strictly centered
anymore (due to different rounding on either side). When using panscan
controls, the video can "jitter" by 1 or 2 pixels around the center as
the panscan value is changed.
When the displayed image is cropped in Y direction (like using panscan
controls when playing 4:3 video on a 16:9 monitor), and separated
scaling is used, the texture size for the FBO holding the intermediate
result was calculated incorrectly. This could lead to artifacts, which
were quite apparent with extreme scale factors.
Actually, the size of that texture is OK, but the texture shouldn't be
used to hold the complete scaled image. Instead, it should be used for
the visible part of the image only. Because separate scaling works by
scaling in Y direction first, it's still fine to scale the image on the
full image width on the first pass. This helps avoiding artifacts on
the left/right border of the image when scaling in X direction, as the
scaler will try to fetch pixels from beyond the border. (The left border
is still kind of fine, but the right border will fetch garbage, unless
the texture is strictly sized, or explicit clamping is added to the
shader. Too much trouble, so using the full image width is simpler.)
Also fix some issues with no-npot mode, which enables use of power-of-2
textures. Maybe this mode isn't really useful anymore (modern hardware
is faster with smaller non-power-of-2 textures), but keep it for now.
The use of filters prior to PNG compression can greatly improve
compression ratio, with "mixed" (ImageMagick calls it "adaptive")
typically achieving the best results.
%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"
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.
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.
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.
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?
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.
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.
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.
`enterFullScreenMode:withOptions:` creates another window so set the level on
both the windowed window and current window.
Also remove NSFullScreenModeWindowLevel as it seems to be superfluous.
This was overlooked with commit 32a898f, because OSS4 volume control is
typically not available on Linux. BSD does have this feature, so the
broken code broke compilation there.
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.
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.
Stefano Pigozzi
Rudolf Polzer
Alexander Preisinger
John Hawthorn
wm4
Martin Herkt