I have no tolerance for this garbage anymore. There are tons of issues
with it (see e.g. previous commit), and there is no reason to use it
either. Use Libav git, or Libav 10 when it's released.
This also drops support for earlier FFmpeg release, which have exactly
the same issues as Libav 9. FFmpeg 2.1.4 is still supported, because
it's the latest release, and is reasonably recent. (Although this will
probably also be dropped as soon as FFmpeg 2.2 is released.)
Assumed version table (lots of nonsensical numbers):
FFmpeg 2.1.4 FFmpeg (n2.2-rc2) Libav (v10_beta2)
lavu 52.48.101 52.66.100 53.3.0
lavc 55.39.101 55.52.102 55.34.1
lavf 55.19.104 55.33.100 55.12.0
lsws 2.5.101 2.5.101 2.1.2
lavi 3.90.100 4.2.100 4.2.0
lswr 0.17.104 0.18.100 -
lavr 1.1.0 1.2.0 1.1.0
libpostproc and libavdevice are not interesting.
Following this commit, code needed just to support old Libav versions
will start to be removed.
This "sometimes" crashed when seeking. The fault apparently lies in
libavcodec: the decoder returns an unreferenced frame! This is
completely insane, but somehow I'm apparently still expected to
work this around. As a reaction, I will drop Libav 9 support in the
next commit. (While this commit will go into release/0.3.)
Instead of parsing the ASS file in demux_libass.c and trying to pass the
ASS_Track to the subtitle renderer, just read all file data in
demux_libass.c, and let the subtitle renderer pass the file contents to
ass_process_codec_private(). (This happens to parse full files too.)
Makes the code simpler, though it also relies harder on the (messy)
probe logic in demux_libass.c.
They're strictly DVD-only, so it's better to mark them as such. This
also documentes the "title" (now renamed to "dvd-title") property.
This also avoids collision with the --title option. (Technically, there
was no problem. But it might be confusing for users, since we have a
policy of naming properties and options the same if they refer to the
same underlying functionality.)
This commit adds new property 'title' which indicates current
playing title of disc. This property is useful when using a stream
whose title can be changed during playback, e.g., dvdnav.
This commit provides impelmentation of STREAM_CTRL_GET_NUM_TITLES
for dvdnav stream. Other streams for DVD or Blu-ray are already
provide STREAM_CTRL_GET_NUM_TITLES.
Maybe this should be default. On the other hand, this filter does
something even if the volume is neutral: it clips samples against the
allowed range, should the decoder or a previous filter output garbage.
Currently, both replaygain adjustment and user volume control (if
softvol is enabled) share the same variable. Sharing the variable would
cause especially if --volume is used; then the replaygain volume would
always be overwritten.
Now both gain values are simple added right before doing filtering.
Xlib.h (included from x11_common.h) defines a macro 'Status' as 'int'.
This messed up a bunch of definitions in windows.h and broke the build
in Cygwin. Including windows.h first seems to solve the problem.
This commit also removes the definition of an unused flag.
This adds the options replaygain-track and replaygain-album. If either is set,
the replaygain track or album gain will be automatically read from the track
metadata and the volume adjusted accordingly.
This only supports reading REPLAYGAIN_(TRACK|ALBUM)_GAIN tags. Other formats
like LAME's info header would probably require support from libav.
The main incompatibility was that Libav didn't have av_opt_set_int_list.
But since that function is excessively ugly and idiotic (look how it
handles types), I'm not missing it much. Use an aformat filter instead
to handle the functionality that was indirectly provided by it. This is
similar to how vf_lavfi works.
The other incompatibility was channel handling. Libav consistently uses
channel layouts only, why ffmpeg still requires messing with channel
counts to some degree. Get rid of most channel count uses (and hope
channel layouts are "exact" enough). Only in one case FFmpeg fails with
a runtime check if we feed it AVFrames with channel count unset.
Another issue were AVFrame accessor functions. FFmpeg introduced these
for ABI compatibility with Libav. I refuse to use them, and it's not my
problem if FFmpeg doesn't manage to provide a stable ABI for fields
provided both by FFmpeg and Libav.
And make some additions.
I'm not really sure why we list dependencies that are not ours, but that
of external libraries. Still might be useful, though.
I've tried not to be too detailed (because it's not a reference, just
some guidelines), but it still got relatively long. Also contains
conventions for sending patches.
The window doesn't recieve a WM_LBUTTONUP message after it's dragged,
probably because it's swallowed by the modal loop. To stop the button
from sticking, release it manually when the drag is complete.
Mouse buttons can get stuck down if the button is pressed inside the
video window and released outside. Avoid this by capturing mouse input
when a button is pressed.
Linux also has fstatfs(), and the test relied on certain system include
files being available on BSD, but not on Linux. It would break if Linux
added the missing includes for some reason.
Make it a bit stricter, and check for the struct statfs field the code
needs.
This reads MPV_CLIENT_API_VERSION from the source header, and turns it
into a 3 part version number.
E.g. if MPV_CLIENT_API_VERSION were 0x12abcdef, this would result in
"18.171.773615" (8 bits, 8 bits, 16 bits).
We'll see if this is actually useful, or if it's too clever.
Rename it to --enable-libmpv-shared. The option name didn't really
tell much. When we add the possibility to create a static library,
it would also be bad if that were named --enable-static (because it
would sound like it does what --static-build does).
The volume controls in mpv now affect the session's volume (the
application's volume in the mixer). Since we do not request a
non-persistent session, the volume and mute status persist across mpv
invocations and system reboots.
In exclusive mode, WASAPI doesn't have access to a mixer so the endpoint
(sound card)'s master volume is modified instead. Since by definition
mpv is the only thing outputting audio in exclusive mode, this causes no
conflict, and ao_wasapi restores the last user-set volume when it's
uninitialized.
Due to the COM Single-Threaded Apartment model, the thread owning the
objects will still do all the actual method calls (in the form of
message dispatches), but at least this will be COM's problem rather than
having to set up several handles and adding extra code to the event
thread.
Since the event thread still needs to own the WASAPI handles to avoid
waiting on another thread to dispatch the messages, the init and uninit
code still has to run in the thread.
This also removes a broken drain implementation and removes unused
headers from each of the files split from the original ao_wasapi.c.
ao_wasapi.c was almost entirely init code mixed with option code and
occasionally actual audio handling code. Split most things to
ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
Gets rid of the internal ring buffer and get_buffer. Corrects an
implementation error in thread_reset.
There is still a possible race condition on reset, and a few refactors
left to do. If feasible, the thread that handles everything
WASAPI-related will be made to only handle feed events.
This reverts commit 75dd3ec210.
This broke seeking with ordered chapters in some situations. While
the reverted commit was perfectly fine for playback of normal files,
it overlooked that in the ordered chapters case switching segments
actually reinitialized the audio chain completely, including the
decoder. And decoders still read packets on initialization. We can
restore the original commit as soon as decoders stop doing this.
Apparently the "right" place to initialize the hardware decoder is in
the libavcodec get_format callback.
This doesn't change vda.c and vdpau_old.c, because I don't have OSX, and
vdpau_old.c is probably going to be removed soon (if Libav ever manages
to release Libav 10). So for now the init_decoder callback added with
this commit is optional.
This also means vdpau.c and vaapi.c don't have to manage and check the
image parameters anymore.
This change is probably needed for when libavcodec VDA supports gets a
new iteration of its API.
This updates the logic for the new, somewhat unified behavior of SRGB
and 3DLUT since 34bf9be (not that it was particularly correct even that
change) and checks for the presence of corresponding extensions only in
the cases in which they're needed.
This commit:
- Changes some of the #define and variable names for clarification and
adds comments where appropriate.
- Unifies :srgb and :icc-profile, making them fit into the same step of
the decoding process and removing the weird interactions between both
of them.
- Makes :icc-profile take precedence over :srgb (to significantly reduce
the number of confusing and useless special cases)
- Moves BT709 decompanding (approximate or actual) to the shader in all
cases, making it happen before upscaling (instead of the old 0.45
gamma function). This is the simpler and more proper way to do it.
- Enables the approx gamma function to work with :srgb as well due to
this (since they now share the gamma expansion code).
- Renames :icc-approx-gamma to :approx-gamma since it is no longer tied
to the ICC options or LittleCMS.
- Uses gamma 2.4 as input space for the actual 3DLUT, this is now a
pretty arbitrary factor but I picked 2.4 mainly because a higher pure
power value here seems to produce visually better results with wide
gamut profiles, rather then the previous 1.95 or BT.709.
- Adds the input gamma space to the 3dlut cache header in case we change
it more in the future, or even make it user customizable (though I
don't see why the latter would really be necessary).
- Fixes the OSD's gamma when using :srgb, which was previously still
using the old (0.45) approximation in all cases.
- Updates documentation on :srgb, it was still mentioning the old
behavior from circa a year ago.
This commit should serve to both open up and make the CMS/shader code much
more accessible and less confusing/error-prone and simultaneously also
improve the performance of 3DLUTs with wide gamut color spaces.
I would liked to have made it more modular but almost all of these
changes are interdependent, save for the documentation updates.
Note: Right now, the "3DLUT takes precedence over SRGB" logic is just
coded into gl_lcms.c's compile_shaders function. Ideally, this should be
done earlier, when parsing the options (by overriding the actual
opts.srgb flag) and output a warning to the user.
Note: I'm not sure how well this works together with real-world
subtitles that may need to be color corrected as well. I'm not sure
whether :approx-gamma needs to apply to subtitles as well. I'll need to
test this on proper files later.
Note: As of now, linear light scaling is still intrinsically tied to
either :srgb or :icc-profile. It would be thinkable to have this as an
extra option, :linear-scaling or similar, that could be used with or
without the two color management options.
wm4
xylosper
Ryan Goulden
James Ross-Gowan
Alessandro Ghedini
Philip Sequeira
Diogo Franco (Kovensky)
Niklas Haas