The previous commit effectively fixes the mess caused by 'config' vs.
'mpv.conf', and the hack introduced by commit e01a6dac and extended by
commit db167cd4 isn't needed anymore.
(cherry picked from commit 816d7bba1f)
Actually, it's pretty simple to look for multiple filenames at once,
since mp_find_all_config_files() is already a bit "special" anyway.
See #1569. Reverts most of commit db167cd4 (keeps osx-bundle.conf).
(cherry picked from commit a27aa68dd3)
A recent behavior change in libavcodec's h264 decoder keeps at least 1
surface even after avcodec_flush_buffers() has been called. We used to
flush the decoder in order to make sure all surfaces are free'd, so that
the hw decoder can be safely uninitialized. This doesn't work anymore.
Fix it by closing the AVCodecContext before the hw decoder is
uninitialized. This is actually simpler and more robust. It seems to be
well-supported too.
Fixes invalid read accesses with vaapi-copy and dxva2-copy. These
destroyed the hwdec API fully on uninit, and could not deal with
surfaces surviving the decoder.
Probably fixes#1587.
(cherry picked from commit cf073138b2)
Admittedly, the behavior on Windows is not quite straightforward. The
behavior on the other platforms is equivalent to fopen().
Fixes#1585.
(cherry picked from commit a799a4c57f)
Falls back to the first display in the list returned by xrandr. Not
entirely correct, but makes some people happy (see #1575).
(cherry picked from commit cd6dfcbef4)
Apparently there's at least one distro which ships a /etc/mpv/mpv.conf
file (mpv doesn't install such a file). This breaks config files named
'config' located in the user's mpv config directory, because mpv first
loads files named 'config' and then 'mpv.conf'. There is no mechanism
for putting files with different names into the same config path order.
(Even worse, that mpv.conf file only set an option to the default value.
Why do distros always do very stupid things?)
Print a warning on collisions.
Although using 'config' was well-supported, supporting both names is
starting to become messy, so deprecate 'config' and print a warning if
one is found.
At least we will be able to remove the whole mess once 'config' files
are ignored...
This also affects the osx-bundle, which intentionally used these not-so-
optimal semantics. Solve it in a different way. (Unfortunately with an
ifdef - it's not required, but having to explain everyone why mpv tries
to load a osx-bundle.mpv file on Linux and Windows would consume
energy.)
Closes#1569.
(cherry picked from commit db167cd438)
Makes all keys documented in XF86keysym.h mappable. This requires the
user to deal with numeric keycodes; no names are queried or exported.
This is an easy way to avoid adding all the hundreds of XF86 keys to
our X11 lookup table and mpv's keycode/name list.
(cherry picked from commit 417869f845)
Happens to fix#1581 due to an unfortunate interaction with the way the
VO does not react to commands for a while if a video frame is queued.
Slightly improves other situations as well, if the client spams mpv with
commands during playback.
(cherry picked from commit 32b56c56ba)
Commit e920a00eb assumed that terminate_cocoa_application() actually
would exit. But apparently that is not always the case; e.g. mpv --help
will just hang. The old code had a dummy exit(0), which was apparently
actually called. Fix by explicitly exiting if mpv_main() returns and
terminate_cocoa_application() does nothing.
(cherry picked from commit 9e14042e57)
Requested. See manpage additions.
This also makes the magical loop_times constants slightly saner, but
shouldn't change the semantics of any existing --loop option values.
(cherry picked from commit aee0978d50)
Setting the input context is always called, both in cplayer and libmpv,
and under HAVE_COCOA. Unsetting the input context was done only the
cplayer uninit call. Also it was under HAVE_COCOA_APPLICATION, so it was
not unset in libmpv (dangling pointer).
(cherry picked from commit c59a4f12db)
The code in main.c calls exit() explicitly, but the code is actually
easier to follow by simply exiting from main() instead. The exit() call
in av_log.c happens only on severely broken builds, so replace it with
abort().
(Shuts up rpmlint warnings.)
(cherry picked from commit e920a00eba)
This is a small oversight. The client name (as set on command line
options or, more importantly, the client API) was not set when listing
devices e.g. via the "audio-device-list" property.
Might or might not fix#1578.
Also adjust the log level for an unrelated message.
(cherry picked from commit c152c59084)
This reverts commit acc5e8f574.
As expected, some didn't like this. Others won't like this revert.
Whatever.
See #1561.
This should go into mpv 0.8.0 before it's released.
(cherry picked from commit 7bbc617019)
Remove the confusing crap that allowed a filter using the libavfilter
bridge to be compiled without libavfilter. Instead, compile the wrappers
only if libavfilter is enabled at compile time.
The only filter which still requires it is vf_stereo3d (unfortunately).
Special-case this one. (The whole filter and how it interacts with lavfi
is pure braindeath anyway.)
(cherry picked from commit 2522bff565)
It requires libavfilter now, just like many other filters. Not sure if
it even makes sense to keep this wrapper.
(cherry picked from commit 73d23a9405)
This reverts commit a33b46194c.
It turns out FFmpeg really considers this a bug, and fixed it by making
the decoder output the correct pixel format.
Fixes#1565. Reverts the fix#1528, though it should work fine with
a recent git master FFmpeg.
The intention is that we can test vo_opengl with high bit depth PNGs
better. This throws libswscale completely out of the loop, which before
was needed in order to convert from big endian to little endian.
Also apply a minimal cleanup to fmt-conversion.c (unrelated).
Most things stopped using this field for better support of growing
files. Go through the trouble to repalce the remaining uses, so it can
be removed.
Also move the "streaming" field; saves 4 bytes (wow!).
Fix return types and return values to make them more consistent. Some
reformatting and making code more concise.
In stream_reconnect(), avoid the additional mp_cancel_test() call by
moving the "connection lost" message below the mp_cancel_wait() call,
which effectively leads to the same behavior when the stream was already
canceled. (The goal is not to show the message in this case.)
Merge stream_seek_long() into stream_seek(). It was the only caller.
Always clear the eof flag on seeks.
Reduce access to stream internals in cache.c and stream_lavf.c.
Make it accept "," as separator, instead of only ":". Do this by using
the key-value-list parser. Before this, the option was stored as a
string, with the option parser verifying that the option value as
correct. Now it's stored pre-parsed, although the log levels still
require separate verification and parsing-on-use to some degree (which
is why the msg-level option type doesn't go away).
Because the internal type changes, the client API "native" type also
changes. This could be prevented with some more effort, but I don't
think it's worth it - if MPV_FORMAT_STRING is used, it still works the
same, just with a different separator on read accesses.
Before this, unquoted occurrences of ":" lead to parsing errors. There's
no reason to reject it, especially since the traditional MPlayer syntax
uses ":" as separator. (Which is also the reason why ":" was rejected
before: the parser shares this code for handling splitting/quoting, and
we merely checked explicitly whether the option was split on ",".)
Fixes#1445 without failing in the case where file outside.mkv with N
chapters references inside.mkv with N+1 chapters. Since we don't care
about the number of chapters in inner files (yet; nested chapters would
change this, but also make chapters dynamic anyways), don't check there.
Much cleaner. The difference between timeline_info and
inner_timeline_info is that timeline_info is stuff the top-level cares
about and inner_timeline_info is just for the current chapter.
This introduces a new option linear-scaling, which is now implied by
srgb, icc-profile and sigmoid-upscaling.
Notably, this means (sigmoidized) linear upscaling is now enabled by
default in opengl-hq mode. The impact should be negligible, and there
has been no observation of negative side effects of sigmoidized scaling,
so it feels safe to do so.
Autoload external audio files only if there's at least a video track
(which is not coverart pseudo-video).
Enable external audio file autoloading by default. Now that we actively
avoid doing stupid things like loading an external audio file for an
audio-only file, this should be fine.
Additionally, don't autoload subtitles if a subtitle is played.
Although you currently can't play subtitles without audio or video,
it's disturbing and stupid that the player might load subtitle files
with different extension and then fail.
Giving this such a prominent place is not really appropriate anymore.
Most people seeing this would probably expect a release changelog, not
something about MPlayer.
Since the page still could be useful for former MPlayer users (in
particular to avoid confusion with renamed options etc.), still keep
it in the DOCS directory.
Reindent the whole handle_realaudio() function, and make the surrouding
if block return early instead.
Also contains some cosmetics to the sipr swapping, which hopefully does
not change the semantics, but is untested (the kind of cosmetic changes
everyone loves so much). May the person responsible for sipr rot in
hell. (It was probably done to obfuscate the codec?)
Staring at the code, it doesn't look like the extra code for "normal"
audio is needed. Most of it looks like artifacts from the previous code
structure (much of it was added in the initial commit). I couldn't find
a sample that uses this code path to fully confirm this, though.
I suppose it could lead to subtle changes in behavior in presence of
realvideo files that change aspect radio. With the only sample I had
available, the behavior actually improved (azumi.mkv from the MPlayer
samples FTP; when starting playback in the middle it used the wrong
aspect ratio).
Appears to work, so we can drop some code. For some really odd reason,
the descrambling done on the timestamp requires millisecond units (due
to the "algorithm", not the libavcodec API).
Fixes vp9 missing timestamps. This requires a brand new libavcodec (the
patch for this was just applied to FFmpeg git master).
The timestamp mangling is applied to VP9 only. It'd probably work with
other codecs, but it's not needed. It could break in various ways, so
it has to be explicitly checked for every enabled codec.
Makes it somewhat more uniform, and breaks up the awfully deep nesting.
This implicitly changes multiple small details, rather than only moving
code around. In particular, this computes the packet fields first and
parses them afterwards, which is needed for the next commit.
The compilation database is a JSON file[1] storing all compilation flags. That
is useful for tools using libclang for code completion and error reporting
(for example: YouCompleteMe for vim).
[1]: http://clang.llvm.org/docs/JSONCompilationDatabase.html
Although the use is somewhat questionable, it seems strange that e.g.
--geometry=50% works (and sets the width only), but setting the height
only in a similar manner does not work.
Matroska ordered chapters require all segment files to have the same
layout. If a referenced file has more tracks than the main file or
misses some tracks, the file is invalid.
Also see issue #1553.
This shouldn't exist and for the most part is meant to be used by the
ytdl Lua script, but let's document it anyway. Since the Lua API handles
all the details, it's considered much more "stable" than the raw API,
which is why the raw API wasn't documented.
Looks like a bunch of off-by-one errors.
The track number was mistakenly offset by 1 - this shifted all chapters
by one, and make the first chapter start on the second track (so the
"chapter" property returned -1 in the first track since it was before
the first chapter).
Also, the calculation of the sector destination was messed up. This
comes from commit 32d818f0, where I apparently attempted to calculate
the position to one byte before the section, but unfortunately math
doesn't work this way and it was nonsense. Just drop this idea; while it
may help with seeking (probably...), it also returns slightly different
times. The user shall use hr-seeks if accurate seeking is required.
Hopefully fixes#1560.
Currently, audio packets are always filtered as a whole. Since demux_raw
output a 1 second long packet, this could lead to large delays when
applying softvol volume. It could be fixed by splitting the frames the
decoder outputs before filtering them (like the old filter code used
to), but since this didn't cause any other problems yet, I'm going with
the simpler fix.
Fixes#1558.
Before this change, window creation was delayed until the video was
initialized. This guaranteed that the first window size was that of the
video, so the WM would place it correctly.
Some time ago, it was requested on the IRC channel that --force-window
should not do this. Sometimes, it can take a while until video is
initialized, e.g. when youtube-dl is used (which incurs lots of network
delay). In this case, it's awkward that it takes so long until a window
(any window) is shown.
On the other hand, this can cause incorrect window placement with some
WMs. We simply hope that this won't happen with modern WMs. (Although it
does with the WM I use, crappy old IceWM.)
In ancient times, this was needed because it was not default, and many
VOs had problems with it. But it was always default in mpv, and all VOs
are required to deal with it. Also, running --fixed-vo=no is not useful
and just creates weird corner cases. Get rid of it.
This allows setting these options directly (without going through
properties, or with going through the "options/" property). The
documented restrictions apply to all of these: changes do not get
immediately applied, unlike with corresponding properties.
This is in reaction to #1548.
Apparently CoreGraphics reports the actual refresh rate. DisplayLink can also
query the nominal refresh rate of the display so we use that as fallback
instead of the fugly 60fps hardcode added in aeb1fca0d.
Props to people on https://github.com/glfw/glfw/issues/137
Comment explains why I have been so doubtful at adding this. The Apple docs
say CGDisplayModeGetRefreshRate is supposed to work only for CRTs, but it
doesn't, and actually works for LCD TVs connected over HDMI and external
displays (at least that's what I'm told, I don't have the hardware to test).
Maybe Apple docs are incorrect.
Since AFAIK Apple doesn't want to give us a better API – maybe in the fear we
might be able to actually write some useful software instead of "apps" –
I decided not to care as well and commit this.
This reverts the default behavior introduced in commit 93feffad. Way too
often libavcodec will return RGB data that has an alpha channel as per
pixel format, but actually contains garbage.
On the other hand, this will actually render garbage color values in
e.g. PNG files (for pixels with alpha==0, the color value should be
essentially ignored, which is what the old alpha blend mode did).
This "fixes" #1528, which is probably a decoder bug (or far less likely,
a broken file).
The only reason why cdda:// goes through this wrapper-demuxer is so that
we add chapters to it. Most things related to seeking apply only to
DVD/BD, and in fact broke CDDA sekkability.
Fixes#1555.
Make the lazy gamma initialization less weird, and make the default
value of the "gamma" sub-option 1.0. This means --vo=opengl:help will
list the actual default value.
Also change the lower bound to 0.1 - avoids a division by zero (I don't
know how shaders handle NaN, but it's probably not a good idea to give
them this value).
There was some code accounting for different gamma values for R/G/B.
It's inherited from an old, undocumented MPlayer feature, which was at
some point disabled for convenience by myself (meaning you couldn't
actually set separate gamma because it was removed from the property
interface - mp_csp_copy_equalizer_values() just set them to the same
value). Get rid of these meaningless leftovers.
These commands are counterparts of sub_add/sub_remove/sub_reload which
work for external audio file.
Signed-off-by: wm4 <wm4@nowhere>
(minor simplification)
Basically, the declared option name and the name passed to the
parse_obj_settings_list() must be the same.
Fixes the issue addressed in #1550, but differently.
These were derived from dividing our assumed video gamut (1.961) by some
typical screen values (2.2 for dimly lit and 2.4 for pitch black):
1.961/2.4 = 0.8170833333333334 ~= 0.8
1.961/2.2 = 0.8913636363636364 ~= 0.9
Before this, enabling :gamma in combination with :sigmoid and probably a few
other things results in ugly artifacts because the video isn't clamped until
after the :gamma was applied (or at all, if the cms_matrix is unused).
Previously we let the user use the audio device ID, but this is not persistent
and can change when plugging in new devices. That of course made it quite
worthless for storing it as a user setting for GUIs, or for user scripts.
In theory getting the kAudioDevicePropertyDeviceUID can fail but it doesn't
on any of my devices, so I'm leaving the error reporting quite high and see if
someone complains.
At least the opengl-hq VO allocates additional resources when
downscaling a lot, which is just a waste.
Also see #1547 (although I doubt that this is the cause; if it is,
a real fix will be required).
This is somewhat imperfect, because detection of hw decoding APIs is
mostly done on demand, and often avoided if not necessary. (For example,
we know very well that there are no hw decoders for certain codecs.)
This also requires every hwdec backend to identify itself (see hwdec.h
changes).
This does what it's documented to do.
The implementation reuses the code in mpv_detach_destroy(). Due to the
way async requests currently work, just sending a synchronous dummy
request (like a "ignore" command) would be enough to ensure
synchronization, but this code will continue to work even if this
changes.
The line "ctx->event_mask = 0;" is removed, but it shouldn't be needed.
(If a client is somehow very slow to terminate, this could silence an
annoying queue overflow message, but all in all it does nothing.)
Calling mpv_wait_async_requests() and mpv_wait_event() concurrently is
in theory allowed, so change pthread_cond_signal() to
pthread_cond_broadcast() to avoid missed wakeups.
As requested in issue #1542.
Resizing was happening before reconfig, so src_rect_rot was outdated and
didn't include the rotation. This resulted in corrupted rendering on
initial display, which fixed itself after the first time the window was
somehow resized.
This fixes usage when the bundle is used on the same machine that Python/Cython
was compiled on. It doesn't fix the harder problem of packaging a full Python
installation in the mpv app bundle (and I'm not sure we actually want that).
Fixes#1549
Might fix behavior with mkv files that use ordered chapters and have
cover art tags. In my opinion, this should actually have worked (because
cover art pseudo-tracks are strictly appended), but I don't have a
sample file to test at hand.
Opening the stream and opening the demuxer are both done asynchronously,
meaning the player reacts to client API requests. They also can
potentially take a while. Thus it's better to process outstanding
property changes, so that change events are sent for properties that
were changed during opening.
In particular, this would fix the sending the initial change event. It
was easily missed because MPV_EVENT_FILE_LOADED usually triggered it,
but the actual property could change only later, because audio
initialization really is kind of asynchronous to it.
This probably fixes#1544.
I guess this was supposed to be some sort of optimization, but even
though it probably works, it's pretty meaningless and I couldn't measure
a difference. One special case killed.
This reverts commit 7b3feecbc2.
It's broken, hr-seek never ends at a video position before seek pts.
Not sure what I was thinking, although it did work anyway when
artificially forcing a video frame to display before seek pts.
At least there is _some_ problem if this happens. It would mean that
audio is playing slower than video. Normally, video is synced to audio,
so if audio stops playback completely, video will not advance at all.
But using things like --autosync, it's well possible that this kind of
desync happens.
Move the update_avsync_before_frame() call further down. Moving it
closer to where the time_frame value is used (and which the function
updates) should make the code more readable. With this change, there's
no need anymore to reset the time_frame value on the video reconfig
path.
Move the update_avsync_after_frame() up. Now no meaningful amount of
time passes since the previous get_relative_time() call anymore, and the
second one can be removed.
FFmpeg and Libav have the stupid practice of replacing and deprecating
API symbols on the same day. So with FFmpeg git, this is useless and
will print a compile time warning, while it's required with all stable
releases, and might lead to decoding errors with xvid/avi (apparently).
Add a comment before someone writes a patch and I have to explain it all
over again.
A small simplification. Couldn't be done before, because it was also
used by the OSD code, which required disjoint quads in a single draw
call.
Also mess with the unrelated code in gl_osd.c to simplify it a little
as well.
Now it shows one of:
- "Subtitles hidden" (sub-visibility=no)
- "Subtitles visible" (sub-visibility=yes, sub!=no)
- "Subtitles visible (but no subtitles selected)" (otherwise)
It should be a bit more self-explanatory than before. On the other hand,
I have no clue about UI issues.
This also gets close to what's reasonably possible with the OSD
expansion string syntax, which is why it looks so awful.
Hardware decoding/displaying with vo_opengl is done by replacing the
normal video textures with textures provided by the hardware decoding
API OpenGL interop code. Often, this changes the format (vaglx and vdpau
return RGBA, vda returns packed YUV).
If the format is changed, there was a chance (or at least a higher
potential for bugs) that the shader generation code could be confused by
the mismatch of formats, and would create incorrect conversions.
Simplify this by requiring the hwdec interop driver to set the format it
will return to us. This affects all fields, not just some (done by
replacing the format with the value of the converted_imgfmt field in
init_format), in particular fields like colorlevels.
Currently, no hwdec interop driver does anything sophisticated, and the
win is mostly from the mp_image_params_guess_csp() function, which will
reset fields like colorlevels to expected value if RGBA is used.
Reduces the size of gl_video.c a bit further.
This also uses a separate vertex array object for OSD elements, so the
video one can be simplified slightly.
OSD shader generation is still in gl_video.c, which leads to the strange
additional parameter to mpgl_osd_init(). The issue is that video
parameters influence the OSD shader (????), and also OSD needs to go
through the screen colormanagement.
Useful if we want to reduce the size of gl_video.c further.
To some degree this emulates traditional glDrawArrays() usage. It also
leaves a loophole for avoiding a reupload every time by leaving
ptr==NULL, although this is unused for now.
default_tex_params() and texture_size() are each called only once, so
move inline/reimplement them at the caller.
image_dw/dh were unused. texture_w/h, image_format, and component_bits
were rarely used, and can be replaced. Regroup some other fields.
Rename surface_num to surface_idx, because the former sounded like a
count, and not an index. Move fbosurface_next() closer to its callers
too.
Move the DebugMessageCallback() code to gl_utils.c (also simplify it
by always setting the callback, instead of only when it changes).
This is somewhat messy, because fbotex_init() itself was depending on
some gl_video parameters unrelated to FBO creation (like what scaler was
in use - what the fuck did this check do in this function?), so this
commit does a bit more than moving code around. In particular, the FBO
for the separate scaling intermediate step now always uses GL_NEAREST
sampling, and all FBOs are destroyed/recreated on renderer
reinitialization.
This also moves the function matrix_ortho2d() - trivial enough not to
put it into a separate commit.
Windows Intel drivers seem to reject some (AFAIK) valid GLSL. Make them
happy.
<rossy> GL_RENDERER='Intel(R) HD Graphics 4400'
<rossy> GL_VERSION='3.0.0 - Build 10.18.14.4080'
<rossy> GL_SHADING_LANGUAGE_VERSION='1.30 - Build 10.18.14.4080'
...into its own functions. The central playloop function is still too
big, but looks much cleaner now.
No changes in functionality. The code moved to handle_playback_restart()
is unindented by 1 level and moving it out of the if condition around.
The if condition is inverted and early-exits from the function. Also
some comments are changed.
mpctx->audio_delay always has the same value as opts->audio_delay. (This
was not the case a long time ago, when the audio-delay property didn't
actually write to opts->audio_delay. I think.)
Handles stupid boilerplate OpenGL requires you to handle. It's the same
code as in gl_video.c, although if no VAOs are available, the fallback
code rebinds them on every draw call instead of just once.
gl_common.c contained the function loader (which is big) and additional
utility functions (not so big, but will grow when moving more out of
gl_video.c). Just split them. There are no changes other than some
modifications to comments.
This allows seeking audio between two video frames that are relatively
far away.
The implementation of this is a bit subtle. It pretend the audio
position is different, and the actual PTS adjustment happens in audio.c
with this line:
sync_pts -= mpctx->audio_delay - mpctx->delay;
Effectively this is the same as setting sync_pts to hrseek_pts after
this line, though. (I'm actually not sure if this could be written in a
more straightforward way; probably yes.)
Some files can have audio after video has ended, and playback of the
audio-only remainder is supposed to work just fine.
Seeking is broken-ish though. Not much can be done about this, since
it's the way demuxers work. Also, such files are obscure corner cases.
But enabling hr-seek for audio after video end can improve the situation
a lot.
This helps with issue #1533. The reported also provided a command line
to produce such a file:
ffmpeg -i image.jpg -i audio.flac -threads $(nproc) \
-c:v libvpx -crf 10 -qmin 5 -qmax 55 \
-vf scale=360:-1 -sws_flags lanczos -c:a libvorbis -ac 2 \
-b:a 128K out.webm
Commit acb40644 fixed video with unaligned luma/chroma sizes. It
attempted to disable the fix for videos where it effectively does
nothing (just some minor performance paranoia), but this check was
broken - fix it by not duplicating the logic for this.
PNG uses a different component order from GL_RGBA, so we upload the
surface using the "wrong" order, and then fix it in the shader. This
breaks if a sRGB texture (GL_SRGB) is used: the hardware will not touch
the alpha channel, which means that the B component is not adjusted,
leading to incorrect output.
Just remove the use of sRGB textures completely. It might lead to a
slight slow down when playing RGB with color management enabled, but
with this combination of obscure use case with minor performance impact
it's not a meaningful disadvantage.
Unfortunately this also means that alpha is handled incorrectly with our
own color management, but alpha isn't so important and can be fixed
later. (0.0 and 1.0 are unchanged by the transfer function, so it
"mostly" works.)
Fixes#1530.
This was apparently useful for correct interlaced scaling (although I
don't know anyone who used this). It was rarely used (if at all), had an
inconvenient output format (packed YUV), and now has a better solution
in libavfilter (using the libavfilter "scale" filter via vf_lavfi).
There is no reason to keep this filter any longer.
It's entirely useless. I left it in for a while, because the analog TV
code had a transitional bug that could switch chroma planes, but it was
fixed long ago. It's also available in libavfilter.
Apparently it was completely broken and essentially did nothing. This
was broken sometime in early mpv or mplayer2 times.
Get rid of it. If you _really_ need it, wait until FFmpeg ports it from
MPlayer, which will happen very soon.
This deals with subsampled YUV video that has odd sizes, for example a
5x5 image with 4:2:0 subsampling.
It would be easy to handle if we actually passed separate texture
coordinates for each plane to the shader, but as of now the luma
coordinates are implicitly rescaled to chroma one. If luma and chroma
sizes don't match up, and this is not handled, you'd get a chroma shift
by 1 pixel.
The existing hack worked, but broke separable scaling. This was exposed
by a recent commit which switched to GL_NEAREST sampling for FBOs. The
rendering was accidentally scaled by 1 pixel, because the FBO size used
the original video size, while textures_sizes[0] was set to the padded
texture size (i.e. one pixel larger).
It could be fixed by setting the padded texture size only on the first
shader. But somehow that is annoying, so do something else. Don't pad
textures anymore, and rescale the chroma coordinates in the shader
instead.
Seems like this somehow doesn't work with rectangle textures (and
introduces a chroma shift), but since it's only used when doing VDA
hardware decoding, and the bug occurs only with unaligned video sizes, I
don't care much.
Fixes#1523.
If a file is unseekable (consider e.g. a http server without resume
functionality), but the stream cache is active, the player will enable
seeking anyway. Until know, client API user couldn't know that this
happens, and it has implications on how well seeking will work. So add a
property which exports whether this situation applies.
Fixes#1522.
This was subtly broken by commit a937ba20. Instead of framestepping over
the timeline segment boundary, it would just unpause playback, because
seeking now resets mpctx->step_frames. This was especially apparent when
doing something like "mpv *.jpg --merge-files".
Fix by restoring the step_frames field specifically if the seek is done
for switching segment boundaries. Hopefully the number fields which need
such an exception on seeking won't grow and turn this code into a mess.
With mf://, rather long frame durations are common. By default, one
frame takes 1 second. This causes the if branch changed with this commit
to always being taken, which in turn leads to the player not being woken
up correctly. (As a consequence, it "freezes" by waiting for events that
never come, and moving the mouse cursor over the window will wake it up
again and advance video.)
Obviously, the code should account for how long the video frame takes.
The code is probably still not fully correct, but for now this fixes the
issue at hand.
Fixes#1521.
Make the default value part of the option metadata, instead of doing
this in the screenshot code. Makes more sense with --list-options and
the command.c option metadata properties.
This allows getting the log at all with --no-terminal and without having
to retrieve log messages manually with the client API. The log level is
hardcoded to -v. A higher log level would lead to too much log output
(huge file sizes and latency issues due to waiting on the disk), and
isn't too useful in general anyway. For debugging, the terminal can be
used instead.
The previous default ("no") seemed to be equivalent to "min" in practice
(though it might depend on the website, which is even worse).
Better just select the best stream by default.
Apparently broken files are popular enough that this is still needed.
It's relatively often asked on the IRC channel, and I also found it on
the archwiki mpv page.
The list of aspect ratios is taken from the archwiki page, with "16:10"
removed (because I doubt there are actually files with this aspect
ratio).
This queries the _ICC_PROFILE property on the root window. It also tries
to reload the ICC when it changes, or if the mpv window changes the
monitor. (If multiple monitors are covered, mpv will randomly select one
of them.)
The official spec is a dead link on freedesktop.org, so don't blame me
for any bugs.
Note that this assumes that Xinerama screen numbers match the way mpv
enumerates the xrandr monitors. Although there is some chance that this
matches, it most likely doesn't, and we actually have to do complicated
things to map the screen numbers. If it turns out that this is required,
I will fix it as soon as someone with a suitable setup for testing the
fix reports it.
Merge update_icc_profile() into get_and_update_icc_profile() - there's
no reason anymore to keep them separate. The former is only called by
the latter, and the separation of responsibilities between them is
blurry a best.
Query the ICC profile only if the corresponding feature is actually
enabled. Additionally, change the error behavior of this code. Make
loading failure non-fatal, and distinguish between runtime error and
unimplemented functionality.
Fix a memory leak in gl_lcms.c (although the changes in vo_opengl.c
already take care of this, it's just logical and cleaner).
Seems like several people agree that it's a good filter for downscaling.
Setting this option by default may also prevent people from accidentally
using an unsuitable filter for downscaling by setting "scale" and
without being aware of the impliciations (maybe). On the other hand,
this change is not strictly backwards compatible for the same reasons.
Also, allow disabling this option with scale-down="" (before this, not
setting it was the only way to do this - not possible anymore if it's
set by default). This is what the change in handle_scaler_opt() does.
Somehow, the default radius for filters with variable radius was set in
mp_init_filter(). gl_video.c used NAN as default value for the radius,
which would make the filter use the default radius. Simplify this, and
set the default radius directly in the gl_video options. It also makes
the options easier to understand, because the default value listed in
--vo=opengl:help actually shows the default value.
Remove the function can_use_filter_kernel(), because it doesn't set a
radius if none is set. The function is worthless anyway (something about
making filter_kernels.c reusable to other VOs, and trying to deal with
the possibility that it could provide filters not supported by
vo_opengl.)
Usually, a VO must react to VOCTRL_REDRAW_FRAME in order to redraw the
current screen correctly if video is paused (this is done to update
OSD). But if it's not supported, we can just draw the current image
again in the generic vo.c code.
Unfortunately, this turned out pretty useless, because the VOs which
would benefit from this need to redraw even if there is no image, in
order to draw a black screen in --idle --force-window mode. The way
redrawing is handled in the X11 common code and in vo_x11 and vo_xv is
in the way, and I'm not sure what exactly vo_wayland requires. Other VOs
have a non-trivial implementation of VOCTRL_REDRAW_FRAME, which
(probably) makes redrawing slightly more efficient, e.g. by skipping
texture upload. So for now, no VO uses this new functionality, but since
it's trivial, commit it anyway.
The vo_driver->untimed case is for forcibly disabling redraw for vo_lavc
and vo_image always.
At the time screenshot support was added, images weren't refcounted yet,
so screenshots required specialized implementations in the VOs. But now
we can handle these things much simpler. Also see commit 5bb24980.
If there are VOs in the future which can't do this (e.g. they need to
write to the image passed to vo_driver->draw_image), this still could be
disabled on a per-VO basis etc., so we lose no potential performance
advantages.
For some sites, youtube-dl sends a special user-agent. If we don't send
the same user-agent, the server will reject mpv's connection attempt.
This was observed with trailers.apple.com. Fix it by forcing the
user-agent youtube-dl uses.
Some sites set cookies when doing a website access, and require the
client to provide these cookies when downloading the actual media. This
is needed at least by nicovideo.jp. Fix by adding youtube-dl's cookies
to our request headers.
Both of these require a very recent youtube-dl version (youtube-dl added
the necessary headers a few hours ago). The script still works with
older youtube-dl versions, though.
This was previously done in common code but now it's left to backends. Also
remove the GL4 stuff since requesting a 3_2_Core context creates a 4.1 context
here (wtf).
Use different VOCTRLs for "window" and normal screenshot modes. The
normal one will probably be removed, and replaced by generic code in
vo.c, and this commit is preparation for this. (Doing it the other way
around would be slightly simpler, but I haven't decided yet about the
second one, and touching every VO is needed anyway in order to remove
the unneeded crap. E.g. has_osd has been unused for a long time.)
New command `mouse <x> <y> [<button> [single|double]]` is introduced.
This will update mouse position with given coordinate (`<x>`, `<y>`),
and additionally, send single-click or double-click event if `<button>`
is given.
vo.c queried the VO at initialization whether it wants to be updated on
every display frame, or every video frame. If the smoothmotion option
was changed at runtime, the rendering mode in vo.c wasn't updated.
Just let vo_opengl set the mode directly. Abuse the existing
vo_set_flip_queue_offset() function for this.
Also add a comment suggesting the use of --display-fps to the manpage,
which doesn't have anything to do with the rest of this commit, but is
important to make smoothmotion run well.
Repurpose demuxer->filetype for this. It used to be used to print a
human readable format description; change it to a symbolic format name
and export it as property.
Unfortunately, libavformat has its own weird conventions, which are
reflected through the new property, e.g. the .mp4 case mentioned in the
manpage.
Fixes#1504.
The symlink trick made waf go crazy (deleting source files, getting
tangled up in infinite recursion... I wish I was joking). This means we
still can't build the client API examples in a reasonable way using the
include files of the local repository (instead of globally installed
headers). Not building them at all is better than deleting source files.
Instead, provide some manual instructions how to build each example
(except for the Qt examples, which provide qmake project files).
The logic disabled framedropping if the frame was interpolated (i.e. the
render call is only done to interpolate between the previous frame, and
the frame before that).
It seems doing this wasn't even necessary, and broke framedrop in
smoothmotion mode. In fact, this code did nothing for display with video
fps below display fps. It did prevent the framedrop counter from going
up, though. So change it so that dropped interpolated frames are never
reported. (Doing so can give confusing results, such as dropping 1000s
of frames on slow operations like video start or changing filters.)
The MSDN documentation for IsFormatSupported says a return code of
AUDCLNT_E_UNSUPPORTED_FORMAT means the function "succeeded but the
specified format is not supported in exclusive mode." This seems to
imply that the format is supported in shared mode, and that's what the
old code assumed, however try_format would incorrectly return success
with some drivers.
The remarks section of the documentation contradicts that assumption. It
says that in shared mode, if the audio engine does not support the
caller-specified format or any similar format, ppClosestMatch is set to
NULL and the function returns AUDCLNT_E_UNSUPPORTED_FORMAT. This is the
same as in exclusive mode, so treat AUDCLNT_E_UNSUPPORTED_FORMAT the
same regardless of opt_exclusive. In shared mode, the format selection
code will fall back to the mix format, which should always be supported.
`core-idle` depends on seeking state `mpctx->restart_complete`,
so make `core-idle` notified whenever `seeking` is notified, too.
`paused-for-cache` can be changed on MPV_EVENT_CACHE_UPDATE obviously.
Finally, `MPV_EVENT_PLAYBACK_RESTART` should be notified after
`mpctx->restart_complete` changed.
SmoothMotion is a way to time and blend frames made popular by MadVR. It's
intended behaviour is to remove stuttering caused by mismatches between the
display refresh rate and the video fps, while preserving the video's original
artistic qualities (no soap opera effect). It's supposed to make 24fps video
playback on 60hz monitors as close as possible to a 24hz monitor.
Instead of drawing a frame once once it's pts has passed the vsync time, we
redraw at the display refresh rate, and if we detect the vsync is between two
frames we interpolated them (depending on their position relative to the vsync).
We actually interpolate as few frames as possible to avoid a blur effect as
much as possible. For example, if we were to play back a 1fps video on a 60hz
monitor, we would blend at most on 1 vsync for each frame (while the other 59
vsyncs would be rendered as is).
Frame interpolation is always done before scaling and in linear light when
possible (an ICC profile is used, or :srgb is used).
These aliases were removed in commit 1ec77214. Add a notice to the
manpage how to get these back. Apparently, "lanczos2" and "lanczos3"
were the only interesting aliases possibly used by someone, so the
description is limited to these two.
These are now auto-detected sanely; and enabled whenever it would be a
performance or quality gain (which is pretty much everything except
bilinear/bilinear scaling).
Perhaps notably, with the absence of scale_sep, there's no more way to
use convolution filters on hardware without FBOs, but I don't think
there's hardware in existence that doesn't have FBOs but is still fast
enough to run the fallback (slow) 2D convolution filters, so I don't
think it's a net loss.
This is significantly faster for FBOs on most modern GPUs, although it
did not result in a huge difference for the video source texture on the
sizes I tested. It might be more significant for 1080p or 4K content, so
it's worth revisiting this in the future.
It also renames SAMPLE_BILINEAR to SAMPLE_TRIVIAL to match the
semantics.
This is better even for non-separable. The only exception is when using
bilinear for both lscale and cscale. I've fixed the
documentation/comments to make more sense.
This is not quite the same thing as madVR's antiringing algorithm, but
it essentially does something similar.
Porting madVR's approach to elliptic coordinates will take some amount
of thought.
This fixes compatibility with GLES 2.0 and makes the code a bit neater
in general. It also properly forces indirect scaling for subsampled
video regardless of the lscale setting.
At least the scale_sep_fbo could have been uninitialized or initialized
incorrectly when switching between scalers (e.g. from bilinear to
lanczos). Calling check_resize() should take care of this.
Instead of reading back the image from textures, keep a reference to the
original image, and return that.
The main reason this was done this way was that originally, images
weren't refcounted, and would be deallocated or overwritten as soon as
the VO's draw call returned. But now there isn't really a good reason
for this anymore. One possibly _could_ argue that it was better because
other code could reuse the image sooner (e.g. for the cache), but on the
other hand, the VO runs already on a different thread, and filtering and
decoding each run on other threads too, so this argument probably
wouldn't hold up.
There was a case when we could have rendered to an output surface while
it's still used for display. Not sure why the API doesn't do this
automatically.
Instead of converting the hw surface to an image in the VO, provide a
generic way to convet hw surfaces, and use this in the screenshot code.
It's all relatively straightforward, except vdpau is being terrible. It
needs a huge chunk of new code, because copying back is not simple.
Before this commit, each hw backend had their own specific struct types
for context, and some, like VDA, had none at all. Add a context struct
(mp_hwdec_ctx) that provides a somewhat generic way to pass the hwdec
context around. Some things get slightly better, some slightly more
verbose.
mp_hwdec_info is still around; it's still needed, but is reduced to its
role of handling delayed loading of the hwdec backend.
This also fixes the maximum range to 16.0, which was previously set to
32.0 and incorrectly documented as 8.0. 16 taps should be more than
anybody will ever need, but it's the highest radius that's supported by
all affected filters.
And remove all uses of the VFCAP_CSP_SUPPORTED* constants. This is
supposed to reduce conversions if many filters are used (with many
incompatible pixel formats), and also for preferring the VO's natively
supported pixel formats (as opposed to conversion).
This is worthless by now. Not only do the main VOs not use software
conversion, but also the way vf_lavfi and libavfilter work mostly break
the way the old MPlayer mechanism worked. Other important filters like
vf_vapoursynth do not support "proper" format negotation either.
Part of this was already removed with the vf_scale cleanup from today.
While I'm touching every single VO, also fix the query_format argument
(it's not a FourCC anymore).
I'm still not sure how exactly handling of "lost" devices is supposed
to be handled. In theory, you only have to "reset" the device, instead
of recreating _everything_. But as it is, the code for proper uninit
and for handling the reset is exactly the same, so move it into a
function to reduce code duplication and the danger of potential bugs.
Apparently, extremely crappy graphics drivers don't allow you to use
shaders. Simply disable use of shaders if this happens, and use the
"old" method instead.
One unexpectedly tricky thing is that you need a d3d_device to create
a shader, which in turn requires a window, so the initialization order
changes.
Don't load all the legacy functions (including ancient extensions).
Slightly simplify function loader and context creation, now that legacy
GL doesn't need to be handled. Remove the code for drawing OSD in legacy
mode.
Remove all the header hacks, which were meant for ancient OpenGL headers
which didn't even support things like OpenGL 1.3. Instead, adjust the
GLX check to make sure we get both OpenGL 3x and 2.1 symbols. For win32
and OSX, we assume that the user has the latest headers anyway. For
wayland, we hope that things somehow go right.
Apparently, physically disconnecting the audio device (consider USB
audio) breaks the ALSA device handle forever. It will signal ENODEV.
Fortunately, it's easy for us to handle this, and we can just use
existing mechanisms that will make the playback core close and reopen
the AO. Whether the immediate reopening will actually succeeds really is
ALSA's problem, though.
Simply clamp off the U/V components in the colormatrix, instead of doing
something special in the shader.
Also, since YA8/YA16 gave a plane_bits value of 16/32, and a colormatrix
calculation overflowed with 32, add a component_bits field to the image
format descriptor, which for YA8/YA16 returns 8/16 (the wrong value had
no bad consequences otherwise).
If video output and VO don't support the same format, a conversion
filter needs to be insert. Since a VO can support multiple formats, and
the filter chain also can deal with multiple formats, you basically have
to pick from a huge matrix of possible conversions.
The old MPlayer code had a quite naive algorithm: it first checked
whether any conversion from the list of preferred conversions matched,
and if not, it was falling back on checking a hardcoded list of output
formats (more or less sorted by quality). This had some unintended side-
effects, like not using obvious "replacement" formats, selecting the
wrong colorspace, selecting a bit depth that is too high or too low, and
more.
Use avcodec_find_best_pix_fmt_of_list() provided by FFmpeg instead. This
function was made for this purpose, and should select the "best" format.
Libav provides a similar function, but with a different name - there is
a function with the same name in FFmpeg, but it has different semantics
(I'm not sure if Libav or FFmpeg fucked up here).
This also removes handling of VFCAP_CSP_SUPPORTED vs.
VFCAP_CSP_SUPPORTED_BY_HW, which has no meaning anymore, except possibly
for filter chains with multiple scale filters.
Fixes#1494.
In my opinion, libavformat should be doing this. But a patch handling a
very safe case rejected, so I suppose we have to do it manually. (This
patch was only escaping spaces, which can never work because they break
the basic syntax of the HTTP protocol.)
This commit attempts to do 2 things:
- Try to guess whether libavformat will use the URL for http. This is
not always trivial, because some protocols will recursively pass part
of the user URL to http in some way.
- Try to fix invalid URLs. We fix only the simplest case: only
characters that are never valid are escaped. This excludes invalid
escape codes, which happen with freestanding '%' characters.
Fixes#1495.
Sigh...
The C locale system is incredibly shitty, and if used, breaks basic
string functions. The locale can change the decimal mark from "." to
",", which affects conversion between floats and strings: snprintf() and
strtod() respect the locale decimal mark, and change behavior. (What's
even better, the behavior of these functions can change asynchronously,
if setlocale() is called after threads were started.)
So just check the locale in the client API, and refuse to work if it's
wrong. This also makes the lib print to stderr, which I consider the
lesser evil in this specific situation.
Handles mismatching libavfilter/libavdevice and libavcodec slightly
better.
libavfilter and libavdevice are optional, and thus are checked
separately and at a later point of the build. But if a user system has
at least 2 FFmpeg installations, and one of them lacks libavfilter or
libavdevice, the build script will pick up the libavfilter/libavdevice
package of the "other" FFmpeg installation. The moment waf picks these
up, all include paths will start pointing at the "wrong" FFmpeg, and the
FFmpeg API checks done earlier might be wrong too, leading to obscure
and hard to explain compilation failures.
Just moving the libavfilter/libavdevice checks before the FFmpeg API
checks somewhat deals with this issue. Certainly not a proper solution,
but since the change is harmless, and there is no proper solution, and
the change doesn't actually add anything new, why not.
This function is always available, which is reflected by the fact that
the configure check doesn't actually bother to check for its existence.
Instead, MinGW and Cygwin imply it. The check was probably "needed" when
the priority code was still in a separate source file.
Remove the check, and use _WIN32 for testing for the win32 API (in a
bunch of other places too).
In general, you need to check errno when using strtol(), but as far as I
know, strtol() won't reset errno on success. This has to be done
manually. The code could have failed sporadically if strtol() succeeded,
and errno was already set to one of the checked values.
(This strtol() still isn't fully error checked, but I don't know if it's
intentional, e.g. for parsing a numeric prefix only.)
Before this commit, ao_null was used as last fallback. This doesn't make
too much sense. Why would you decode audio just to discard it? Let audio
initialization fail instead. This also handles the weird but possible
corner-case that ao_null might fail initializing, in which case e.g.
ao_pcm could be autoselected. (This happened once, and had to be fixed
manually.)
This removes the slightly duplicated code for picking the required AO
driver if --audio-device forces one. Now --audio-device reuses the same
code as --ao for this.
As a consequence, ao_alloc_pb() and ao_create() can be merged into
ao_init(). Although the ao_init() argument list, which is already pretty
big, grows by one, it's better than having all these similar sounding
functions around.
Actually, I just wanted to do the change the following commit will do,
but I found this code was more of a mess than it had to be.
libdvdnav is garbage. Seeking by time is incredibly inexact, which is in
part due to the fact that it does not use the DVD seek tables. Instead,
it assumes CBR for certain ranges within the DVD, which makes especially
small seeks unreliable.
I have no good fix for this, other than hacking libdvdnav (I'd rather
prefer to remove mpv DVD support completely than doing this). So here's
a shitty hack that tries to workaround these problems. A basic
observation is that seeking in VLC seems to work quite well; however it
seems to be based on seeking by blocks (unless there is a subtle "trick"
I didn't see in the source code). mpv usually seeks by timestamps, so
this is not an option for us. However, we can pretend we are doing this
in the DVD layer.
The previous commit added a way to pass through relative seeks. This
commit uses the relative seek. STREAM_CTRL_SEEK_TO_TIME is backwards
compatible (there's still dvdread and bluray), so most code is about
extracing the relative seek information and turning it into a block
seek.
(Another way would have been using SEEK_FACTOR stuff, but that would
probably make for a less reliable way to handle this situation.)
Additionally, if a hr-seek is done, add an offset by 10 seconds. As long
as the error done by libdvdnav is not worse, this should help with hr-
seeks - although it makes them much slower.
Pass through the seek flags to the stream layer. The STREAM_CTRL
semantics become a bit awkward, but that's still the least awkward
part about optical disc media.
Make demux_disc.c request relative seeks. Now the player will use
relative seeks if the user sends relative seek commands, and the
demuxer announces it wants these by setting rel_seeks to true. This
change probably changes seek behavior for dvd, dvdnav, bluray, cdda,
and possibly makes seeking useless if the demuxer-cache is set to
a high value.
Will be used in the next commit. (Split to make reverting the next
commit easier.)
Before this, we merely printed a message to the terminal. Now the API
user can determine this properly. This might be important for API users
which somehow maintain complex state, which all has to be invalidated if
(state-changing) events are missing due to an overflow.
This also forces the client API user to empty the event queue, which is
good, because otherwise the event queue would reach the "filled up"
state immediately again due to further asynchronous events being added
to the queue.
Also add some minor improvements to mpv_wait_event() documentation, and
some other minor cosmetic changes.
We still need to send the VO a duration in these cases. Disabling
framedrop has logically absolutely nothing to do with these cases; it
was overlooked in commit 918b06c4.
So we always send the frame duration (or a guess for it), and check
whether framedropping is actually enabled in the VO code. (It would
be cleaner to send framedrop as a flag, but I don't care about that
right now.)
This complains within dvb_strtok_r() that savePtr is uninitialized.
There doesn't seem to be any code path where this can happen though, so
it's probably a false positive. Silence it anyway.
Broke operation with GLSL.
Since 1D texture usage was apparently (and mysteriously) good for speed,
it might be added back, but it's unknown how to do so in a clean way.
The "ontop" and "border" properties already used a common
mp_property_vo_flag() function, and the corresponding VOCTRLs used the
same conventions. "fullscreen" is pretty similar, but was handled
slightly similar. Change how VOCTRL_FULLSCREEN behaves, and use the same
helper function for "fullscreen" as the other flags.
Fixes#1472.
(Maybe these options should have been named --autofit-max and
--autofit-min, but since --autofit-larger already exists, use
--autofit-smaller for symmetry.)
Normally the player doesn't read from unselected streams, so this should
be a no-op. But unfortunately, some broken files can severely confuse
the player, and assign the same demuxer stream to multiple front-end
tracks. Then selecting one of the tracks would deselect the other track,
with the end result that the demuxer stream for the selected track is
deselected. This could happen with mkv files that use the same track
number (which is of course broken). timeline_set_part() sets the tracks
using demuxer_stream_by_demuxer_id(), using the broken non-unique IDs.
The observable effect was that the player never quit, because
demux_read_packet_async() told the caller to wait some longer for new
packets. Fix by returning EOF instead.
Fixes#1481.
This is for the ordered chapters case only. In theory this could have
resulted in initial audio, video or subs missing, although it didn't
happen in practice (because no streams were selected, thus the demuxer
thread didn't actually try to read anything). It's still better to make
this explicit.
Also, timeline_set_part() can be private to loadfile.c.
The last video frame is another case that has a separate code path,
although it's pretty similar to the one in commit 73e5aa87. Fix this
in a different way, which also takes care of the last frame case,
although without context the code becomes slightly more tricky.
As further cleanup, move the decision about framedropping itself to
the same place, so the check in vo.c becomes much simpler. The check
for the vo->driver->encode flag, which is remvoed completely, was
redundant too.
Fixes#1480.
If the program name isn't quoted and the .exe it refers to isn't found,
CreateProcess will add the program arguments to the program name and
continue searching, so for "program arg1 arg2", CreateProcess would try
"program.exe", "program arg1.exe", then "program arg1 arg2.exe". This
behaviour is weird and not really desirable, so prevent it by always
quoting the program name.
When quoting argv[0], escape sequences shouldn't be used. msvcrt, .NET
and CommandLineToArgvW all treat argv[0] literally and end it on the
trailing quote, without processing escape sequences.
The "\\" escape was rendered as "\" on the website. I'm hoping quoting
this in ``...`` will render it correctly.
Also add an example for show_text, which awkwardly does not require
escaping the "\".
If the video format changes (e.g. different frame size), a special code
path is entered to wait until the currently displayed frame is done.
Otherwise, the frame before the change would be destroyed by the
vo_reconfig() call.
This code path didn't respect --untimed; correct this.
Fixes#1475.
__STRICT_ANSI__ disables functions and definitions that aren't in ANSI
C. Unfortunately this includes j1(), which is used by the new
ewa_lanczos code. Cygwin's CFLAGS already unset __STRICT_ANSI__, but it
should be unset for both Cygwin and MinGW.
After finding out more about how video mastering is done in the real
world it dawned upon me why the "hack" we figured out in #534 looks so
much better.
Since mastering studios have historically been using only CRTs, the
practice adopted for backwards compatibility was to simulate CRT
responses even on modern digital monitors, a practice so ubiquitous that
the ITU-R formalized it in R-Rec BT.1886 to be precisely gamma 2.40.
As such, we finally have enough proof to get rid of the option
altogether and just always do that.
The value 1.961 is a rounded version of my experimentally obtained
approximation of the BT.709 curve, which resulted in a value of around
1.9610336. This is the closest average match to the source brightness
while preserving the nonlinear response of the BT.1886 ideal monitor.
For playback in dark environments, it's expected that the gamma shift
should be reproduced by a user controlled setting, up to a maximum of
1.224 (2.4/1.961) for a pitch black environment.
More information:
https://developer.apple.com/library/mac/technotes/tn2257/_index.html
This was forgotten when the option was implemented, and makes this
option work as advertised.
Fixes#1473 (though the default behavior is probably still stupid).
Adds about 7 lines of boilerplate per filter. This could be avoided by
providing a different entrypoint (something like af->filter_inplace),
which would basically mirror the old interface exactly for this kind of
filter. But I feel like it would just be a hack to support all those
old, useless filters better. (The ideal solution would be using a
language that can do closures to provide a compat. wrapper, but
whatever.)
af_bs2b has terribly repetitious code for setting up filter functions
for each format (most of them useless, in addition to bs2b being
useless), so I did something terrible with macros.
af_sinesuppress had commented code for float filtering (maybe it was
broken; it has been commented every since it was added in 2006). Remove
this code.
Just to make sure all filters get the correct format. Together wih the
check in af_add_output_frame(), this asserts that
af->prev->fmt_out == af->fmt_in
This also requires setting the "in" pseudo-filter (s->first) formats
correctly. Before this commit, the fmt_in/fmt_out fields weren't used
for this filter.
Support for taking screenshots when doing hardware decoding needs to be
added later.
This takes the last image queued to the VO, which is logically the image
the player thinks is on screen (so e.g. subtitles will match).
forget_frames() does not clear this, because seeking does not remove the
current image from the screen (until the next one is drawn).
Upon the "DEL" key binding or the "disable-osc" message, the OSC should
stay permanently invisible. This was recently broken (not sure by what),
because other code accidentally reenables it anyway, which resulted in
the OSC appearing again when moving the mouse.
The Qt example already does this. I hoped this was restricted to
QApplication only, but apparently Qt repeated this mistake with
QGuiApplication (QGuiApplication was specifically added for QtQuick at a
much later point, even though QApplication inherits from it).
Commit 5e25a3d2 broke handling of the initial frame (the one decoded
with initial_audio_decode()). It didn't update the pts_offset field,
leading to a shift in timestamps by one audio frame.
Fix by calling the actual decode function in a single place. This
requires slightly more changes than what would be necessary to fix the
bug, but it also somewhat simplifies the data flow.
The percent-pos property normally goes by time, except for file formats
like .ts or .ogg, where you can't trust the timestamps and duration info
to compute the position in the overall files. These use the byte
position and size instead.
When the file position was unavailable (e.g. due to an ongoing seek),
the percent-pos was unknown. Change it to use the time position instead.
In most cases, it's actually accurate enough, and the temporary
unavailability of the property can be annoying, e.g. on the terminal
status line.
The goal is switching the whole audio chain to using refcounted frames.
This brings the architecture closer to FFmpeg, enables better
integration with libavfilter, will reduce useless copying somewhat, and
will probably allow better timestamp tracking.
For now, every filter goes through a semi-awful wrapper in
af_do_filter(), though. This will be fixed step by step, and the wrapper
should eventually be removed. Another thing that will have to be done is
improving the timestamp handling and avoiding extra copies for the AO.
Some of the new code is rather similar to the video filter code (the
core filter code basically just has types replaced). Such code
duplication is normally very unwanted, but in this case there's probably
no other choice. On the other hand, this code is pretty simple (even if
somewhat tricky). Maybe there will be unified filter code in the future,
but this is still far away.
The purpose of this function was to filter only as much audio input as
needed to produce a certain amount of audio output. This could (in
theory) avoid excessive buffering when e.g. changing playback speed with
resampling.
Use of this was already removed in commit 5fd8a1e0. No problems were
experienced, so let's assume this feature is practically worthless.
(Though it's possible that it was quite useful over a decade ago, or in
some cornercases with evil files.)
Having any of these set to 0 makes no sense.
I think some code might still be using 0/0 aspect ratio to signal unset
aspect ratio, but I didn't find it. If there is still code like this, it
should be fixed instead.
Fixes#1467.
For some reason, schedule_resize() can be called with everything set to
0. The code couldn't handle wl->window.aspect set to 0, converting NaNs
to integers. Just work this around.
(I have no idea what I'm doing. This is probably a corner case caused
by my broken-ish wayland setup.)
BSTR_P() passes the string length and start pointer to printf-like
functions. If the lenfth is 0, the pointer can be NULL, but we're
actually still not allowed to pass a NULL pointer in any case.
This is mostly a technically, because nobody in their right mind would
attempt to specifically break such cases. But it's still undefined
behavior, and some libcs might be strict about this.
bstr is a bounded string type, consisting of a pointer and a length
value. If the length is 0, the pointer can be NULL. This is somewhat
logical due to how this abstraction works, but it can leak when
converting to C strings.
talloc_strndup() returns NULL instead of "" in this case, which broke
some other code. Use bstrto0() instead, which is the "proper" function
to convert bstr to char*.
Fixes#1462.
Reading IDs must be checked too. This was basically forgotten in commit
f3a978cd. Also set the *length parameter for ebml_parse_length() in some
error cases, which _really_ should happen.
Fixes#1461.
mpv needs at least an audio or video track to play something. If the
track selection is basically insufficient, the player will immediately
skip to the next file (or quit).
One slightly annoying thing might be that trying to play a subtitle file
will close the VO window, and then go to the next file immediately (so
"mpv 1.mkv 2.srt 3.mkv" would flash the video window when 2.srt is
skipped). Move the check to before the video window is possibly closed.
This is a minor cosmetic issue; one can use --force-window to avoid
closing the video window at all.
Fixes#1459.
Closing the video window sends CLOSE_WIN, which is normally mapped to
the "quit" command. The client API normally disables all key bindings,
and closing the window does nothing. It's simply left to the application
to handle this. This is fine - an embedded window can not be destroyed
by user interaction.
But sometimes, the window might be destroyed anyway, for example because
the containing window is destroyed. If this happens, CLOSE_WIN should
better not be ignored. We can't expect client API users to handle this
specially (by providing their own input.conf), so provide some fallback
for this pseudo key binding. The "quit" command might be too intrusive
(not every client necessarily handles "unexpected" MPV_EVENT_SHUTDOWN),
but I think it's still reasonable.
For some reason, mpv sometimes does not get a MapNotify event with
GtkSocket embedding. This happens maybe 1 out of 10 times. I'm not sure
how this can happen - it certainly shouldn't. Since I was not able to
find the cause, and causes an apparent "deadlock", here's a lazy hack to
fix the misbehavior.
Seems to work with GtkSocket and passing the gtk_socket_get_id() value
via "wid" option to mpv.
One caveat is that using <tab> to move input focus from mpv to GTK does
not work. It seems we would have to interpret <tab> ourselves in this
case. I'm not sure if we really should do this - it would probably
require emulating some other typical conventions too. I'm not sure if an
embedder could do something about this on the toolkit level, but in
theory it would be possible, so leave it as is for now.
Don't use vo_control() for sending VOCTRL_RESET when starting a seek.
This means vo_seek_reset() won't wait until the VO actually processed
VOCTRL_RESET. It happens asynchronously instead.
The impact of this change should be minimal, unless the VO is somehow
too busy (like blocking on vsync).
Remove the "all" special-behavior, and instead interpret trailing "*"
characters. --display-tags=all is replaced by --display-tags=* as a
special-case of the new behavior.
See #1404.
Note that the most straight-forward value for matchlen in the normal
case would be INT_MAX, because it should be using the entire string.
I used keylen+1 instead, because glibc seems to handle this case
incorrectly:
snprintf(buf, sizeof(buf), "%.*s", INT_MAX, "hello");
The result is empty, instead of just containing the string argument.
This might be a glibc bug; it works with other libcs (even MinGW-w64).
Apparently, originally this code was meant to be able to read past the
buffer somewhat, which is why the buffer allocation was padded by 8
byte. This is unclean and confuses valgrind. This probably could have
crashed with certain invalid files too.
Also revert the change added with 10a2f69; it should be not needed
anymore.
We now use threads and other pthread API a lot, and not always we use it
from threads created with pthread_create() (or the main thread). As I
understand, with static linking we would have to use
pthread_win32_thread_attach/detach_np() every time we enter or leave a
foreign thread. We don't do this, and it's not feasible either, so it's
just broken.
This still should work with dynamic pthreads-win32. The MinGW pthread
implementation should be unaffected from all of this.
Make their meaning more exact, and don't pretend that there's a
reasonable definition for "bits-per-pixel". Also make unset fields
unavailable.
average_depth still might be inconsistent: for example, 10 bit 4:2:0 is
identified as 24 bits, but RGB 4:4:4 as 12 bits. So YUV formats
seemingly drop the per-component padding, while RGB formats do not.
Internally it's consistent though: 10 bit YUV components are read as
16 bit, and the padding must be 0 (it's basically like an odd fixed-
point representation, rather than a bitfield).
bpp(bits-per-pixel) and depth(bit-depth for color component) can
be calculated from pixelformat technically but it requires massive
informations to be implemented in client side.
These subproperties are provided for convenience.
Enable asynchronous reading for external files. This excludes subtitle
files (so it's effectively enabled for audio files only), because most
subtitle files are fully read on loading, and running a thread for them
would just cause slowdowns and increase resource usage, without having
any advantages.
In theory, an external file could provide multiple tracks from the same
demuxer, but demux_start_thread() is idempotent, so the code can be
kept simple.
Should help with playing DASH with ytdl_hook.
We still keep the window pointer, because we want to call
QQuickWindow::resetOpenGLState() (which runs on the rendering thread
only). Interesting mess...
We must not try to remap channels with this. Whethever ALSA gives us,
and whatever we do with it, the result will probably be nonsense.
Untested, as I don't have the required hardware.
This avoids issues when upscaling directly in linear light, and is the
recommended way to upscale images according to imagemagick.
The default slope of 6.5 offers a reasonable compromise between
ringing artifacts eliminated and ringing artifacts introduced by
sigmoid-upscaling. Same goes for the default center of 0.75.
The VP9 codec parser has a bug: it doesn't set the data/size pointers
passed to it. As I understand, it must always do this, and in fact, if
it doesn't some libavcodec generic code would be in trouble too.
This helps with #1448, but is not the full fix for it. The codec parser
must be fixed in libavcodec itself.
The previous implementation of opengl-cb kept only latest flipped frame.
This can cause massive frame drops because rendering is done asynchronously
and only the latest frame can be rendered.
This commit introduces frame queue and releated options to opengl-cb.
frame-queue-size: the maximum size of frame queue (1-100, default: 1)
frame-drop-mode: behavior when frame queue is full (pop, clear, default: pop)
The frame queue holds delayed frames and drops frames if the frame queue is
overflowed with next method:
'pop' mode: drops all the oldest frames overflown.
'clear' mode: drops all frames in queue and clear it.
With default options(frame-queue-size=1:frame-drop-mode=pop),
opengl-cb behaves in the same way as previous implementation effectively.
For frame-queue-size > 1, opengl-cb tries to calls update() without waiting
next flip_page() in order to consume queued frames.
Signed-off-by: wm4 <wm4@nowhere>
vo_opengl was crashing since f811348d because it passed NULL for the
events parameter to vo_control. Normally the parameter should not be
NULL, so add a hack to account for this. In particular, we should
handle the events that are returned. For the call in preinit() we
skip this, but it most likely has no meaning anyway, because in this
stage no window is visible yet.
This was always supposed to work.
Just add the option declaration. Normally I'm not a fan of duplicating
such things, but in this case it's (still) harmless.
mpv can be built natively on a Windows machine using MSYS2. Add detailed
instructions on how to build and merge them with the existing
instructions for cross-compilation.
This one avoids use of a FBO. It's less flexible, because it uses works
around the whole QML rendering API. It seems to be the only way to get
OpenGL rendering without any indirections, though.
Parts of this example were insipired by Qt's "Squircle" example.
Also add a README file with a short description of each example, to
reduce the initial confusing.
This affects OSX, where memory profiles are updated e.g. on fullscreen
switches. The profile most likely doesn't change, but the LUT will
be generated and reloaded anyway.
Somewhat of a regression from commit f811348.
Fixes#1439.
If icc-path is set, but the thing is replaced with a memory profile,
then p->icc_path would point to deallocated memory.
Also, the NULL checks are unnecessary.
This used to be required to workaround PulseAudio bugs. Even later, when
the bugs were (partially?) fixed in PulseAudio, I had the feeling the
hacks gave better behavior. On the other hand, I couldn't actually
reproduce any bad behavior without the hacks lately. On top of this, it
seems our hacks sometimes perform much worse than PulseAudio's native
implementation (see #1430).
So disable the hacks by default, but still leave the code and the option
in case it still helps somewhere. Also, being able to blame PulseAudio's
code by using its native API is much easier than trying to debug our own
(mplayer2-derived) hacks.
glXGetProcAddress() is outdated, and as far as I know doesn't give all
the guarantees the "new" ARB function gives.
Probably doesn't matter too much, because until now it always appeared
to work. On the other hand, since this function is (bogusly) used only
on the gl3 code path, it could have happened that users hit this, and
just reverted to vo_opengl_old instead.
The function terminal_in_background() reports whether the player was
backgrounded. In this case, we don't want to annoy the user by still
printing the status to stderr. If no terminal interaction is assumed,
this mechanism is disabled, and stderr is always used. The read_terminal
variable signals this case.
Oddly, just redirecting stderr will disable output to stderr, because
the background check with tcgetpgrp() is done on stderr, but
read_terminal is still true (because that one depends on stdin and
stdout).
Explicitly disable this mechanism if --no-input-terminal is used by
setting read_terminal to true only if terminal input is actually
initialized.
When the given mp_image_params does not match with that of gl_video,
gl_video_config() always calls uninit_video() but calls init_video()
only if valid format is given.
Since uninit_video() does not change image_params of gl_video,
when the same params as the previous one is given to gl_video_config()
after gl_video is unitialized with invalid format, gl_video_config()
never calls init_video().
To prevent this, invalidate image_params of gl_video in uninit_video().
Previously we just forced loading a profile from file, but that has poor
integration for querying the OS / display server for an ICC profile, and
generating profiles on the fly (which we might use in the future for creating
preset 3dluts).
Also changed the previous icc-profile-auto code to use this mechanism, and
moved gl_lcms to be an opaque type with state instead of just providing pure
functions.
This causes more constant reading from the DVB device,
and seems not to hurt the stream-controls.
As the device cache seems to fill up when not
reading from it for several seconds, reading
into the cache fixes desync-issues after
the initial analyzeduration of the demuxer.
Was already possible before by injecting the magic PID
8192 into channels.conf, the flag makes this much more
useable and we also have it documented.
Useful not only for debugging, but also for incomplete
channels.conf (mplayer format...), multi-channel
recording, or channels which do dynamic PID switchng.
full-transponder is also useful for channels which switch PIDs on-the-fly.
ffmpeg can handle this, but it needs the full stream with all PIDs.
There is the STD which contains service-names
(ffmpeg can understand it),
and the EIT which contains the EPG
(ffmpeg does not parse it, but e.g. VLC does).
As we now have more PIDs in general, increase the maximum
number of demuxers we can open. ffmpeg has an internal
limit of 64 PIDs, we are still far from that.
If VDR-channel-config is used, we know the service_id.
Using that, PMT can be extracted from PAT (code for that
inspired by szap-s2 again).
For this, we need to demux PAT with a special filter-setup,
and once PMT was found it can be added to the PID-list.
PMT is only resolved the first time one tunes to a channel,
then stored in the channel-list in memory.
With PMT available, ffmpeg can safely decode the teletext-pids.
I also added a comment explaining the potentially occuring structures for future reference.
For tokenization, a custom strtok_r implementation is used,
inspired by strtok_r as implemented in musl and ffmpeg,
hopefully slightly more readable (av_strtok_r is not available in libav,
and strtok_r is not available everywhere).
Move PID-string parsing into a separate function, reduces code-duplication.
Drop TPID-parsing again since teletext-stream seems not really correctly identified (ffmpeg guessed mp3 in my test...).
Parsing now done using strtok + sscanf instead of sscanfs with fixed numbers of expected fields -
gives more correct checking of PID-overflow, will allow VDR-style PID-field parsing.
The PID-parsing is not really nicely done and also does not yet handle the special VDR-style syntax.
A later commit will move the parsing to a separate function handling that which also checks that the maximum PID-count is not exceeded.
In mplayer-style channels-config, we had a LNB-field used for that.
In old VDR times, the location-field was also containing DISEQc information,
now it does that only indirectly (location => LNB => vdr knows from lnb-config).
We only accept it as this if the field is fully numeric.
Now also "stream ID" (for DVB-S2) and "inversion" are understood.
The parameter-string can also provide information on FEC, rolloff etc. For DVB-S, "auto" which mpv uses by default should be fine, I can also confirm it works. For non-DVB-S cards, it might be useful to also parse this information in case of a vdr-channel list.
As I have no such hardware and thus would have to do it blindly, I added a FIXME.
Mostly complete vdr-channels.conf format documentation is at http://www.vdr-wiki.de/wiki/index.php/Channels.conf (german only).
Still incomplete. Initialize is_dvb_s2 boolean in channel-struct.
We first check whether the channels.conf-line at hand is sscanf'able with a vdr-style pattern. If yes, we assume it is a vdr-channel-config (we check whether sscanf consumed the full line).
The vdr-style config also contains a parameter-string which contains information about polarization + delivery type (e.g. DVB-S2).
With this change, S2-tuning works with a VDR-channel list.
Missing (later commits):
- vdr-parameter-string also contains other information, e.g. invert-flag, needs to be parsed.
- Diseqc-lnb-number is not present in VDR-config (I believe it is handled via the location-parameter + lnb-config there). For backwards compatibility, the location-parameter can be the lnb-number - we should test whether it is an int and assume this in this case.
- VID, AID and TID-lists are extremely ugly in their syntax for VDR. At the moment, only the first number is parsed (and TID fully ignored), needs to be fixed.
It contains now also a boolean which tells whether this is an DVB-S2 channel (not initialized yet - tbd in next commit).
We could also pass through the type of the delivery system (would be more flexible), but the delivery-system-enum is only available with S2API, so this is more backwards-compatible.
If someone has DVB-T2 / DVB-C2 hardware and extends the code to deal with it, this should be changed.
Also allows demuxers to buffer, and we explicitly discard stale QPSK events.
Inspiration taken from the szap-s2 implementation.
S2API is only used if available and for DVB-S cards - it might also be useful to have that for DVB-T2 / DVB-C2 tuning later, but I do not have the HW / no DVB-T2 broadcasting station nearby to test functionality.
This should do no functional changes, only usage of the different API. The S2API is more extensible and a requirement for all the HD-deliveries (e.g. DVB-S2) and since 2.6.28 is the successor of the old API.
Tuning to DVB-S2 channels actually already "works" like this if the delivery is hardcoded in - for a fully working implementation, the channels.conf.sat would need an additional field indicating the delivery type (VDR-type channels.conf have that).
This commit also:
- Cleans up some debug output.
- Moves an unneeded usleep(100000) (only needed for diseqc switching for SAT) into the DVB-S-only part of the implementation.
Define a new macro "DVB_USE_S2API" to be used to switch to S2API if available,
also document what is the main difference in the new S2API.
StreamID-handling is only supported since API 5.2, and some macros
were renamed or only added later with 5.8 (somewhere around kernel 3.6),
so some define-fixups are needed to support these intermediate
kernel header versions.
Commit 87c13de6 added a fallback to video resolution if the subtitle
resolution is unknown. Apparently this fixed some broken files with
vobsubs.
This broke some DVB subtitles. Apparently .ts captures with 1920x1080
video resolution and 720x576 subtitles do exist. The sample at hand had
some streams with 720x576 resolution and no sub resolution set, and some
streams with 1920x1080 resolution and sub resolution set (both against
the same 1920x1080 video). My conclusion is that 720x576 is the only
reasonable fallback for DVB (but I can't be sure).
The fallback is removed for PGS too. I don't know about the PGS case; it
seems the sub resolution must always be set, so it shouldn't matter.
Fixes#1425.
This makes vo_opengl_cb respond to controls like "gamma" and
"brightness". The commit includes an awkward refactor for vo_opengl to
make it easier for vo_opengl_cb.
One problem is a logical race condition. The set of supported controls
depends on the pixelformat, which in turn is set by reconfig(). But the
actual reconfig() call (on the renderer) happens asynchronously on the
renderer thread. At the time it happens, the player most likely already
tried to set some controls for command line options (see init_vo() in
video.c). So setting this command line options will fail most of the
time, though it could randomly succeed. This can't be fixed directly,
because the player can't wait on the renderer thread, because the
renderer thread might already wait on the player.
Although the line count increases, this is better for making sure
everything is handled consistently for all users of the mp_csp_params
stuff.
This also makes sure mp_csp_params is always initialized with
MP_CSP_PARAMS_DEFAULTS (for consistency).
No more equals signs for options that don't take values.
Complete values for options with preset choices.
Complete --no-whatever where applicable.
Fixes#997.
--sub-scale-by-window=no attempts to keep subs always at the same pixel
size.
The implementation is a bit all over the place, because it compensates
already done scaling by an inverse scale factor, but it will probably do
its job.
Fixes#1424. (The semantics and name of --sub-scale-with-window are
kept, and this adds a new option - the name is confusingly similar, but
it's actually analogue to --osd-scale-by-window.)
This adds an "auto" choice to the concurrent-frames suboption, and makes
it the default.
I'm not so sure about making this the default, though. It could lead to
excessive buffering with large CPU counts. But we'll see.
Our own code was introduced when FFmpeg didn't provide this API (or
maybe didn't even have a way to determine the CPU count). But now,
av_cpu_count() is available for all FFmpeg/Libav versions we support,
and there's no reason to have our own code.
libavutil's code seems to be slightly more sophisticated than our's, and
it's possible that the detected CPU count is different on some platforms
after this change.
If there's only 1 chapter, the seeking by chapter (using the chapter
property) will either jump to the chapter point, or quit playback. This
is as designed, but seems like a useless and annoying behavior.
Removes an annoying "No video PTS! Making something up." warning.
Mark it as keyframe, which is needed to prevent strange behavior with
PNG. Also, don't leak the picture data.
Options which take colors accept two variants. The first is "r/g/b/a",
the second is "#AARRGGBB". Since they put alpha at different places,
it's probably better to document the second variant explicitly. (It's a
bit strange that they put alpha in different places, but on the other
hand, it's kind of natural. The second variant should probably be
considered deprecated.)
mpv_opengl_cb_uninit_gl() can be called at any time; but then the
decoder must be destroyed due to complications with hardware decoding.
This is why kill_video() exists. To make things easier, there is the
invariant that while vo_opengl_cb is active, the OpenGL state must
exist. But kill_video() didn't actually destroy the VO; only the video
decoder. This could trigger an assertion (vo_opengl_cb.c:187).
Actually, the video output is always destroyed lazily at a later point
if the decoder is destroyed, but not early enough for out purposes.
Returning the property before the window is mapped could lead to
confusing behavior, and in particular strange differences between
vo_vdpau and vo_opengl. (vo_opengl creates the window right at the
start, while vdpau waits until the first reconfigure event.) It might
even be possible that for vo_opengl random results were returned,
because the hidden window can have different placement than the actual,
final one on initial video reconfig.
Fix this by returning the property only if the window is considered
mapped. command.c handles this case specifically, and makes the property
unavailable, instead of returning an empty list.
There are currently 568 pixel formats (actually fewer, but the namespace
is this big), and for each format elaborate synchronization was done to
call it synchronously on the VO. This is completely unnecessary, and we
can do with just a single call.
This is basically a hack; but apparently a needed one, since many
vapoursynth filters insist on having a FPS set.
We need to apply the FPS override before creating the filters. Also
change some terminal output related to the FPS value.
Most of this is explained in the code comments. This change should
improve performance with vapoursynth, especially if concurrent requests
are used.
This should change nothing if vf_vapoursynth is not in the filter chain,
since non-threaded filters obviously can not asynchronously finish
filtering of frames.
Add an explicit "signal" event type, because the implicit one was
confusing.
Don't rescale the Y axis of the second graph, it was nonsense.
Make the legend for the second graph separate (and cleanup the code
creating the graphs).
* bits instead of bytes
* add valid_bits argument
* just pass in the mp_chmap and get the number and wavext channel map from that
* indicate valid bits in waveformat_to_str
* make appropriate accomodations in try_format
Sort the legend by the used y value of binary events/signals, add a way
to filter branches (although that requires editing the script), and use
the full screen if the second subplot is not used.
We certainly don't use the mplayer configuration dir. The name didn't
matter, but now that it's in user-visible output (as part of config.h
being dumped in verbose mode), it's a bit too strange.
Mostly of cosmetic nature. Move initialization to the same place where
another component (cocoa) will start accessing the input context from a
foreign thread.
It was requested that mpv should print what features etc. have been
enabled at compile time. It can print the configure command line, but it
obviously doesn't include autodetected features.
I tried to think of a nicer way than dumping the config.h as text, but
this was still the simplest way.
I hoped we could always use libavresample, but the FFmpeg project is
being too dickish to enable libavresample by default - which means we
need our libswresample-to-libavresample hack anyway.
Give up, and use the "supported" one of the duplicated libraries when
compiling against FFmpeg (relying on the fact that libswresample won't
be present if compiling against Libav).
While there's no actual need to get rid of these, I want to make sure
nobody actually needs this stuff, and removing it is the best way to
get to know this. We still can revert this commit if it turns out there
is a significant need for this stuff.
The final goal is removing vo_opengl_old entirely. Add a warning, which
basically announces this intention.
The examples simple.c and cocoabasic.m can be compiled without
installing libmpv. But also, they didn't use the correct include path
libmpv programs normally use, so they couldn't be built with a properly
installed system-libmpv. That's pretty bad for examples, which are
supposed to show how to use libmpv correctly.
So do some bullshit that symlinks libmpv to a "mpv" include directory
under the build directory. This name-mismatch is a direct consequence of
the bullshit done in 499a6758 (requested in #539 for dumb reasons). (We
don't want to name the client API headers directory "mpv", because that
would be too unspecific, and clashes with having the mpv binary in the
same directory.)
If you have spaces or other "unusual" characters in your paths, the
build will break, because I couldn't find out where waf hides its
function to escape shell parameters (or a way to invoke programs
without involving the shell). Neither does such a thing to be
documented, nor do they seem to have a clear way to do this in
their code.
This also doesn't compile the Qt examples, because everything becomes
even more terrible from there on.
C++ is the worst language ever, and allows throwing any type, even if it
doesn't make sense. In this case, we were throwing char*, which the
runtime typically treats as opaque, instead of printing it as message if
such an exception was not caught.
Do so by using mp_subprocess(). Although this uses completely different
code on Unix too, you shouldn't notice a difference. A less ncie thing
is that this reserves an entire thread while the command is running
(which wastes some memory for stack, at least). But this is probably
still the simplest way, and the fork() trick is apparently not
implementable with posix_subprocess().
If the stdout or stderr write callback is NULL, then don't redirect this
stream. Preparation for the next commit.
Not sure what to do on Windows; it seems STARTUPINFO doesn't allow
redirection only one of them. So just let them write nothing. For our
intended use-case (next commit), this is probably sensible.
This is only needed for switching video track with `_`, since Cocoa
automatically handles cleaning up the application's presentation options when
quitting the process.
Fixes#1399
Tags keys are case-insensitive. Before commit 8048374a, the casing of
whatever FFmpeg returned was used (it was quite random). But since the
change, the values in --display-tags decides. Consider this an
accidental feature, and make the output nicer by capitalizing
the tag names.
The way we use rectangle textures (required by VDA for no reason) works
onl in OpenGL 3.0 or higher. Below that, the shader will fail to
compile. We could add support for older OpenGL versions, but that would
be a major pain.
This normally doesn't matter; mpv itself always creates OpenGL 3.2
contexts on OSX. But it could matter if a client API user uses
vo_opengl_cb, and gives it a 2.1 context (which OSX also allows you to
create).
This may or may not be useful for client API users.
Fold this API extension into the previous API bump. The previous bump
was only yesterday, so it's ok.
Until now, calling mpv_opengl_cb_uninit_gl() at a "bad moment" could
make the whole thing to explode. The API user was asked to avoid such
situations by calling it only in "good moments". But this was probably a
bit too subtle and could easily be overlooked.
Integrate the approach the qml example uses directly into the
implementation. If the OpenGL context is to be unitialized, forcefully
disable video, and block until this is done.
For some codecs, we need to invoke a codec parser (because libavcodec
will run into trouble otherwise). This was done based on the Matroska
codec field.
But this ignores handling of vfw-muxed files, which use a pseudo-codec
to signal presence of vfw structures, which we must unmangle to get the
real codec. Handle this by rearranging the code.
This fixes at least mp3-in-mkv for vfw-muxed files; typically old files.
Creating a plain Handle() should yield a NULL mpv_handle.
Also, remove the redundant non-const definition of the conversion
operator. At least in this situation it's not needed.
Also, add include guards around qthelper.hpp.
Use queued signals instead of QEvent for the wakeup notification. This
is slightly nicer, and reduces the chance that the event (QEvent::User)
could clash with other code using the same event.
Also switch to modern connect() syntax.
Destruction (e.g. when closing the window) was a bit broken. This commit
fixes some possible crashes, and should make lifetime management
relatively sane. (Still a bit complex, though. Maybe this code should be
moved into a tiny library.)
QtQuick runs the renderer on a separate thread. This thread is rather
loosely connected to the main thread. The loose separation is enforced
by the API, which also makes coordination of initialization and
destruction harder. Throw refcounting at the problem, which fixes it.
The refcounting wrapper introduced in the previous commit is used for
this.
Also contains some general cleanups.
If a filter exists, but has no metadata, just return success. This
allows the user to distinguish between no metadata available, and filter
not inserted.
See #1408.
This message can happen a lot for mkv files which index clusters in the
seekhead (which is also broken non-sense, but that's a different story).
Also remove a duplicate define from matroska.h.
There's no reason why parts of this demuxer would be in a separate
source file. The existence of this code is already somewhat questionable
anyway, so it may as well be dumped into a single file.
Even stranger that demux.c included mf.h for no reason (it was an
artifact from 2002 when the architecture was uncleaner).
This attempts to increase user-friendliness by excluding useless tags.
It should be especially helpful with mp4 files, because the FFmpeg mp4
demuxer adds tons of completely useless information to the metadata.
Fixes#1403.
Until now, these options took effect only at program start. This could
be confusing when e.g. doing "mpv list.m3u --shuffle". Make them always
take effect when a playlist is loaded either via a playlist file, or
with the "loadlist" command.
This message is printed when the audio device advertised a channel map,
but couldn't set it - which is probably a dmix bug (we'll never know,
ALSA doesn't take bug reports).
Print the requested map, so that the user (maybe) can make a connection
when seeing the message and the actually used channel map, which might
be less confusing. Or at least less useless.
Instead of just failing during channel map selection, try to select a close
layout that makes most sense and upmix/downmix to that instead of failing AO
initialization. The heuristic is rather simple, and uses the following steps:
1) If mono is required always prefer stereo to a multichannel upmix.
2) Search for an upmix that is an exact superset of the required channel map.
3) Search for a downmix that is the exact subset of the required channel map.
4) Search for either an upmix or downmix that is the closest (minimum difference
of channels) to the required channel map.
The details of the non-linear transformation from/to BT.2020's constant
luminance system don't really make sense with any other gamma curve,
since changing the gamma curve completely breaks the chroma channels.
Apparently this is what users would expect.
Going the way of least resistance (in terms of messing with this old,
rarely used code), sorting them by some kind of addition timestamp
(called priority in the patch) is the easiest.
Fixes#1390.
On uninitialization, the player will unselect all subtitles, and then
destroy the subtitle decoder. But it didn't correctly remove the
subtitle decoder from the OSD state, so it could happen that it would
access it after the decoder was destroyed.
Could lead to random crashes when switching files often.
Fixes#1389.
There where 3 major errors in the previous code:
1) The kAudioDevicePropertyPreferredChannelLayout selector returns a single
layout not an array.
2) The check for AudioChannelLayout allocation size was wrong (didn't account
for variable sized struct).
3) Didn't query the kAudioDevicePropertyPreferredChannelsForStereo selector
since I didn't know about it's existence.
All of these are fixed.
Might help with #1367
Ever since someone (not me) added some Matroska features which nobody
ever uses (ordered edition or some bullshit), I haven't had a fucking
clue what the fuck is going on in this fucking file. (Still agreed to
it, so it's my fault.)
mplayer2 handled missing chapters correctly (and I suppose in a somewhat
clean/simple manner), but the changed code doesn't. Since I can't even
follow this code because it's so arcanely complicated, just add a hack
that has the same effect.
Essentially, don't make it the mmap() argument, and just add it to the
memory address. This hides tricky things like alignment reequirements
from the user.
Strictly speaking, this is not entirely backwards compatible: this adds
the regression that you can't access past 2 or 4 GB of a file on 32 bit
systems anymore. But I doubt anyone cared about this.
In theory, we could be clever, and just align the offset manually and
pass that to mmap(). This would also be transparent to the user, but
minimally more effort, so this is left as exercise to the reader.
Makes all of overlay_add work on windows/mingw.
Since we now don't explicitly check for mmap() anymore (it's always
present), this also requires us to make af_export.c compile, but I
haven't tested it.
AudioChannelLayout uses a trailing variable sized array so we need to
query CoreAudio for the size of the struct it is going to need (or the
conversion of that particular layout would fail).
Fixes#1366
mpv does 'cascading' configs by overriding options as the config become more
important (bundle -> system level -> user level).
Unfortunately mpv also loads two sets of configs files one after the other [1].
First it looks for 'config', then for 'mpv.conf'. For this reason a mpv.conf in
ANY location will override ANY config files named config (even if the mpv.conf
is in a system path and config in a user path).
[1]: Relevant code in player/configfiles.c
load_all_cfgfiles(mpctx, section, "config");
load_all_cfgfiles(mpctx, section, "mpv.conf");
Fixes: #1361
vo_opengl was originally written against OpenGL 3 core, and it seems
GPUs/drivers supporting this are mostly sane. Later, it was made to work
with OpenGL 2.1 too. Lately we removed the requirement for RG textures,
and look, someone reported a problem with "lesser" Intel GPUs.
This commit does the same in vo_opengl what was added to vo_opengl_old a
long time ago.
Fixes#1383.
If a file (or a demuxer) is broken, seeking close to the end of the file
doesn't work, and seek_to_last_frame() will be called over and over
again, burning CPU for no reason.
Observed with incomplete mp4 files. That this can happen was already
mentioned in commit 090f6cfc, but I guess now I'll do something against
it.
hrseek_lastframe is cleared by reset_playback_state(), so it's only set
if seek_to_last_frame() was called, and no other seek happened since
then. If finding the last frame succeeds, no EOF will happen (unless the
user unpauses, but then it will simply remain at the last frame). If it
fails, then it will return immediately, without retrying.
I noticed that the IPC code does not use MSG_NOSIGNAL or SO_NOSIGPIPE.
The former is "only" POSIX 2008 and also requires switching to sendto(),
while the latter is even less portable.
Not going to bother with this obsolete 80ies crap, just block SIGPIPE,
and instruct client API users to do the same.
Using the IPC with a program, it's not often obvious that a newline must
be sent to terminate a command. Print a warning if the connection is
closed while there is still uninterpreted data in the buffer.
Print the OS reported error if reading/writing the socket fails. Print
an erro if JSON parsing fails.
I considered silencing write errors if the write end is closed (EPIPE),
because a client might send a bunch of commands, and then close the
socket without wanting to read the reply. But then, mpv disconnects
without reading further commands that might still be buffered, so it's
probably a good idea to always print the error.
stream_edl merely makes demux_edl act "special", which checks for the
stream type explicitly and then does something with its URL. If a cache
is added before the stream, it'll try to use the cache's URL (i.e. an
empty string), and will then obviously fail to parse the URL. While this
is slightly stupid, just disabling the entirely useless cache is the
most effective solution.
Fixes#1378.
Using them reduces state change, since now at least vo_opengl_cb has to
setup/break the vertex array bindings on every frame if no VAOs are
available.
This reverts the VAO related change in commit f64665e7.
Originally, this code was written to have full control over the OpenGL
state, rather than having to cooperate with unknown components by being
embeded like vo_opengl_cb is meant to be. As a consequence, it was
thought to be ok to setup a global binding (if the context is below
OpenGL 3.0, which guarantees VAOs).
This could break badly. Fix it by setting up and breaking the bindings
on entry/exit.
snd_pcm_prepare() was not always called, which could result in an
infinite loop.
Whether snd_pcm_prepare() was actually called depended on whether the
device was a hw device (or other characteristics; depending on
snd_pcm_hw_params_can_pause()), and required real suspend (annoying for
testing), so it was somewhat tricky to reproduce without knowing these
things.
GL_ARB_debug_output provides a logging callback, which can be used to
diagnose problems etc. in case the driver supports it. It's enabled only
if the vo_opengl "debug" suboption is set.
The code could as well be in demux.c, but it's better to avoid
accidental clashes with demux_lavf.c.
FFmpeg provides no way yet to map a mime type to a codec, so do it
manually. (It _can_ map a mime type to an "input format", but not a
codec.)
Fixes#1374.
Now it accepts the same renderer arguments as vo_opengl. This also
disables debug checks by default, and reverts the background color
override. Both can now be controlled by the host application.
Most image subtitle formats implicitly terminate the current subtitle
event with the next event (e.g. a new packet read from the demuxer will
instruct the subtitle render to stop display). If the subtitle event is
just trailing, it will be displayed forever. So there's no proper way
of doing this and we just apply an heuristic to avoid annoyances.
The libavcodec PGS decoder sets end_display_time to UINT32_MAX, in an
attempt to signal unknown end time (the API does not allow to signal
this properly, and this was a backwards compatible hack).
While we have no issues with the large value, our code wants to
distinguish between known and unknown end time explicitly.
reset_subtitles() works in mpctx->d_sub[], which is set to NULL before
calling it from uninit_sub(). This fixes resetting the subtitle when
cycling subtitle tracks.
Actually, this was probably a feature, because it's annoying if
subtitles don't show up when cycling them. But it also can have
unintended consequences, so get rid of it.
Whether we have texture_rg doesn't matter much anymore; the scaler
should be fine with this. But on ES 2.0, 1st class arrays are missing,
so even if filterable float textures should be available, it won't work.
Dithering (at least the "fruit" variant) will not work either, because
it uses floats.
Apparently GLES 2 and 3 do not support this. (The implementations I
tested with were derived from desktop OpenGL and were not overly strict
with this.)
This is no problem; just use GL_RGBA and mangle the channels in the
shader.
Also disable direct support for image formats like IMGFMT_RGB555 with
GLES; at least some of them are not supported in this form, and the
formats aren't important anyway.
Commit 0e8fbdbd removed the rg_texture requirement from vo_opengl;
commit 541f6731 changed to a more convenient method. Both commits broke
vo_opengl_old in some ways. vo_opengl_old always requires GL_ALPHA for
single-channel texture, because it draws the OSD without shaders and by
using certain blend modes.
So we need to explicitly distinguish between vo_opengl and vo_opengl_old
in the OSD renderer, and force fixed texture formats for vo_opengl_old.
The other logic is specific to the internals of vo_opengl. (Although it
might be possible to get the same result by playing with the old GL
fixed-function functions in vo_opengl_old. But seems like a waste of
time.)
Fixes#1370.
When setting the ALSA channel map, we never actually set the map we got
from ALSA directly, but convert it to mpv's, and then back to ALSA's.
mpv and ALSA use different conventions for mono, and there is already an
exception for ALSA->mpv, but not mpv->ALSA.
This was only added recently (c1e97161) as an attempt to minimize the
bad impact of channel layout device aliases. But use of these was
removed in commit 49df0132. Now this code does pretty much nothing, and
shouldn't be needed anymore. It does something when using spdif, but
this fallback won't work anyway.
The code in the demuxer etc. was changed to update all metadata/tags at
once, instead of changing each metadata field. As a consequence,
printing of the tags to the terminal was also changed to print
everything on each change.
Some users didn't like this. Add a very primitive way to avoid printing
fields with the same value again if metadata is marked as changed. This
is not always correct (could print unchanged fields anyway), but usually
works.
(In general, a rather roundabout way to reflect a changed title with ICY
streaming...)
Fixes#813 (let's call it a "policy change").
There are probably bugs with GLES support; also, if you somehow get GLES
instead of desktop GL on a desktop computer, something else is probably
wrong. So I see no point in using this automatically. We first need to
find out whether the GLES support works on real hardware, and whether
it is useful at all.
Apparently GLX can do this, so using EGL is not strictly required.
This code tries to create an ES context if creating a desktop GL context
fails. Also, a "x11es" backend for forcing ES (instead of desktop GL) is
added, mostly for testing and debugging.
Before this, missing additional but required functions were ignored.
("Main" functions still made it error out.) But we pretty much expect
that these are present on a given version level, and only an extremely
buggy OpenGL implementation would not do this.
Involve detection of software renderers in the probing properly. Other
VOs could handle probing also more gracefully, and e.g. produce less
noise if an API is unavailable. (Although other than the OpenGL VOs,
only vo_wayland will.)
Now the "sw" suboption for vo_opengl[_old] is strictly speaking not
needed anymore. Doing "--vo=opengl" disables the probing logic, and will
always force it, if possible.
Includes some simplifications as well.
Probably.
The version handling schema is a bit strange (and led to a tricky and
obvious bug), but it's quite similar to what OpenGL does at some places,
so I blame the OpenGL standard.
Rather basic support. Almost nothing works, and even if it does, it's
bound to be inefficient (due to texture upload). This was tested with
the nVidia desktop binary drivers, which provide GLES 2 support only.
However, nVidia is not known to be very strict about OpenGL, and the
driver is very new too, so the vo_opengl code will have bugs too.
This is needed for GLES 2 support. GLES 2 doesn't support
GL_UNPACK_ROW_LENGTH, and we shouldn't even use this constant, since a
GLES implementation could raise an error.
So set it only if neccessary, and leave it in the default state
otherwise. This also smuggles in a ES 2 fallback for glUploadTex(),
and querying an extension relevant for ES 2. For the alignment state
(GL_[UN]PACK_ALIGNMENT) do the same for symmetry. All 4 states
(alignment/rows x pack/unpack) are now assumed to be in their initial
states by default.
Also redo the PixelStorei handling in the function table. I could rebase
this, but look at the commit time.
Previously, this was sort of messed together with desktop OpenGL
loading. Add explicit support for ES, and clean up the mess. Also sort
the function arrays alphabetically (at least most of them).
In some cases, add functions to multiple sections. This keeps the number
of sections down.
Don't check for GL_ARB_vertex_array_object. This feature must be used in
OpenGL 3 core, while it may be not available at all in earlier versions,
and not using it if it's available as extension only has no advantages.
This commit also considers GLES 2, because actual support for it will be
added with a later commit.
Also get rid of some MPGL_VER() uses (see some commits ago).
This was a nice trick to get the mpv colormatrix directly into OpenGL,
because the memory representation happened to match.
Unfortunately, OpenGL ES 2 doesn't have glUniformMatrix4x3fv().
Even more unfortunately, the memory representation is now incompatible.
It would be nice to change it, but that would mean getting into a big
mess.
Really, this doesn't actually matter. It's printed as error only because
it was once thought to be an mostly unneeded fallback, but it turned out
this is still frequently needed, and users are getting confused.
For some reason, when using window embedding, and the window manager is
OpenBox, calling XSetWMNormalHints() before the window is mapped, the
initial window position will be off. It leaves some vertical space,
instead of placing it on the top/left corner. Suspiciously, the vertical
space is as much as a the height of normal window decoration.
I don't know what kind of issue this is. Possibly an OpenBox bug, but
then this happens even if the override-redirect flag is set. (This flag
basically tells the X server to ignore the window manager. Normally we
don't set it.) On other window managers, it works fine. So I don't know
why this is happening.
But this is easy to workaround. XSetWMNormalHints() isn't needed at all
if embedding.
Should fix#1235.
Always include the window position in winrc, even if the window
embedded. This should give the correct positions for things which still
interact with global coordinates, such as the xrandr code.
If GL_RED was not available, we used GL_ALPHA. But this is an
unnecessary complication, and it's easier to use GL_LUMINANCE instead.
With the latter, a texture will return the .r component set, and as long
as the shader doesn't look at the other components, the shader doesn't
need any changes.
Some of the changes added in 0e8fbdbd are now unneeeded.
Also, realign the entire gl_byte_formats_legacy table.
OpenGL 3.0 has the weird situation that it's "hard" to detect whether
legacy GL is really present. Since we pretend that we have OpenGL 3.0 if
we use GLES, it was assuming legacy GL is available.
The idea of using -Werror=format-security comes from MPlayer.
Try to use the compiler flags with any compiler. There's no reason not
to apply them on clang.
Older OSX versions are missing some OpenGL 3 symbols, apparently. At
least there's some precedent in the headers. Just add the symbols
manually for now to fix OSX (on travis-ci) compilation.
Tested with MESA on software emulation. Seems to work well, although the
default FBO format in opengl-hq disables most interesting features. I
have no idea how well it will work on real hardware (or if it does at
all).
Unfortunately, some features, including playback of 10 bit video, are
not supported. Not sure what to do about this.
GLES 2 or 1 do not work.
Remove the readback stuff; it was a useless mess.
Don't test GL_R16 as FBO. The intention was to measure the effective
bitdepth of the texture, except that it was never actually done.
(There's also a OpenGL function which is supposed to retrieve the
bitdepth, but we don't use that either.)
I'm hoping this is generally more compatible, and it works with GLES.
This probably has not much of an effect on desktop GL. It also switches
only the default format for --vo=opengl, not --vo=opengl-hq.
"-hq" already uses GL_RGBA16, though since it's a sized format, the
story is a bit different, and it won't work on GLES either.
Older GLSL dialects as well as GLES3 do not support the following things
in expressions:
- implicit conversions of integer constants to float
- arithmetic of float*vecN
As suggested in issue #1251. I think the main point is that it acts as
a hack to return to the DVD menu when jumping past the last chapter,
because it will reach title-EOF, instead of explicitly jumping to the
next file (which usually exits the player).
This basically reverts commit 8b7418d, except it doesn't include an
off-by-1 error (apparently).
Closes#1251.
Because of the icc-profile-auto option (which was added at a later
point), supporting this would probably be slightly messy: the ICC
profile can spontaneously update, and then it would overwrite the
previously set options.
Don't make icc-profile-auto fatal if unsupported. The "auto" indicates
that it will use whatever it finds, even if it's nothing.
Also add a warning; before this commit, it just refused to initialize
without explanation.
As a mostly unrelated cosmetic change, remove redundant parameters which
had no point anymore.
Probably fixes#1359 (or rather works it around by disallowing it).
Also clarify the statement about what we expect to happen by default.
It's well possible that distros at some point will fix their ALSA
configuration, and e.g. enable the upmix plugin by default.
Padding with spaces is very useless for OSD (because most fonts are
variable width), but it's good when using it on the terminal, e.g. for
reproducing the default terminal status line.
This should work well with most audio APIs, except ALSA. A long-winded
explanation is provided how to make ALSA multichannel output work.
All other AOs should have no such problems. Of course it's possible
that previously unknown issues arise, because I assume that enabling
multichannel audio is actually relatively rare.
This also disables codec downmix by default, which could change the
audio output due to different mixing in the codec and libavresample.
Fixes#1313.
The "old" method (before the ALSA channel map API) used device aliases
like "surround51" to set the channel layout. The "interesting" part was
that these devices usually redirect to a hardware device. This means
playing stereo would lead you to the "default" device (dmix), while e.g.
5.1 to "surround51", which automatically takes care of the fact that
dmix can't do 5.1.
This is pretty much nonsense, though. It shouldn't depend on the damn
input media file whether the player is going to use shared access (dmix)
or exclusive access (direct hw device).
As a consequence, by default ao_alsa will do only what dmix can do. If
the user actually wants multichannel, he has to select a suitable hw
device with --audio-device. From there on, the correct speaker mapping
will be ensured via the channel mapping API.
The change is preparation for making multichannel output the default (as
far as supported by the audio output API). Of the common APIs, only ALSA
messes up beyond repair, so I feel like this change is needed.
On ancient alsa-lib versions, only stereo and mono can be played with
this branch.
dmix reports channel layouts it doesn't support. The rest of the
technical part of the story is in the code comment.
This seems to be the only reasonable way to fallback from trying to
initialize certain devices (like dmix) with multichannel audio. We could
probably add support for such padding channels to our audio chain or to
ao_alsa itself, but this would probably be much more work than this
commit.
What dmix does is probably a bug. I've tried to report it to ALSA. Thay
have a link on their website to a bug tracker, but it's a dead link, and
has been for years. I've posted to alsa-devel, but received no reply.
I'm thus assuming this absolutely retarded behavior is by design, and
nothing will happen to improve upon it.
I'm considering sending Lennart Poettering a "thank you" email, because
with PulseAudio, multichannel audio just works (although some other
things just don't work).
Before this commit, this was defined to trigger undefined behavior. This
was nice because it required less code; but on the other hand, Lua as
well as IPC support had to check these things manually. Do it directly
in the API to avoid code duplication, and to make the API more robust.
(The total code size still grows, though...)
Since all of the failure cases were originally meant to ruin things
forever, there is no way to return error codes. So just print the
errors.
The message was missing a '\n', so it was merged with the next line,
which also typically caused it not to be printed with the colors for
warnings.
Print the full new path in the warning message. (Normally, cfg should
never be NULL, so accounting for this case is just for robustness.)
Obscure feature, and I've never heard of anyone using it.
The anaglyph effects can be reproduced with vf_stereo3d. The only thing
that can't be reproduced with it is "quadbuffer", which requires special
and expensive hardware.
- --lua and --lua-opts change to --script and --script-opts
- 'lua' default script dirs change to 'scripts'
- DOCS updated
- 'lua-settings' dir was _not_ modified
The old lua-based names/dirs still work, but display a warning.
Signed-off-by: wm4 <wm4@nowhere>
This was requested.
It seems libdvdread can't get the duration for titlesets other than the
currently opened title. The data structures contain dangling pointers
for these, and MPlayer works this around by opening every title
separately for the purpose of dumping the title list.
Apparently, we treat different tracks as titles, so returning the number
of titles (which is user-visible as "disc-titles" property) is
completely misguided.
Apparently, libdvdnav always reports a last chapter that points to the
exact end of the title. This is useless for us.
Again, same possible caveats as with the previous commit.
This way, chapter 0 will always point to the start of the title.
At least this is the intention; it's likely that DVDs as well as
libdvdnav do random things that lead to random results.
GNU sed and BSD sed don't share the same options for editing files in-place,
so a workaround is needed.
The most simple way is to use a pure python implementation of applying the
changes.
The --keep-open behavior was recently changed to act only on the last
file due to user requests (see commit 735a9c39). But the old behavior
was useful too, so bring it back as an additional mode.
Fixes#1332 (or rather, should help with it).
Do this by automatically adding the option, if the aliased option name
also has a "no-..." variant.
Could be easier by manually adding "no-..." variants to the option list,
but this seems better because you can't just forget it.
MP_NOPTS_VALUE (basically INT64_MIN) is basically an special timestamp
value that means "unset" or "unknown". Its exact value is internal, and
should never be returned or interpreted by any API.
So return "no" instead (what is also what the parser accepts).
Commit d38bc531 is incorrect: the 50ms queue-ahead value and the flip
queue offset have different functions. The latter is about calling
flip_page in advance, so the change attempted to show video frames 50ms
in advance on all VOs.
The change was for vo_opengl_cb, but that can be handled differently.
These actually are harmless. Even if the data the reader is working on
is essentially random, it's treated like untrusted input data, so there
should be no harm.
But it upsets tools like valgrind.
Probably fixes#1329.
In theory, vo_opengl supports operation without framebuffers. But this
has been broken for a while now (commit cc00b3ff is a contender). It
crashed because it unconditionally called gl->BindFramebuffer() (which
is NULL if framebuffers are missing).
Since this function is actually only called to set the default
framebuffer, the simplest way to deal with this is to provide a dummy
function, insteas of uglifying the code with additional if branches.
The result isn't quite what I imagined, because the A-point is never
marked as a seek point (so you can't jump between A and B), but it's
still slightly better than before.
I think that's expected; mpv shouldn't draw anything while no video is
active. This doesn't blend transparently, though.
Also document the vo_opengl_cb thing.
After being bitten by this, I decided that this mostly unnecessary
requirement sucks.
Allowing this makes it easier to use libmpv, because it can be set after
mpv_initialize(). The latest reasonable time an API user can set this
variable is before actually loading a file.
The previous 2 commits make sure nothing bad can happen if the option is
changed at runtime even if a VO is active. The Cocoa backend should be
fine and doesn't need a change.
This adds API to libmpv that lets host applications use the mpv opengl
renderer. This is a more flexible (and possibly more portable) option to
foreign window embedding (via --wid).
This assumes that methods like context sharing and multithreaded OpenGL
rendering are infeasible, and that a way is needed to integrate it with
an application that uses a single thread to render everything.
Add an example that does this with QtQuick/qml. The example is
relatively lazy, but still shows how relatively simple the integration
is. The FBO indirection could probably be avoided, but would require
more work (and would probably lead to worse QtQuick integration, because
it would have to ignore transformations like rotation).
Because this makes mpv directly use the host application's OpenGL
context, there is no platform specific code involved in mpv, except
for hw decoding interop.
main.qml is derived from some Qt example.
The following things are still missing:
- a way to do better video timing
- expose GL renderer options, allow changing them at runtime
- support for color equalizer controls
- support for screenshots
The most awesome codec, not.
The actual code for svq3 is actually just the part that checks for
MKV_V_QUICKTIME (no other QT-muxed codecs are supported). The rest is
minor refactoring, that actually improves the code in general.
This is just enough to support the 2 svq3-in-mkv sample files I have.
There were complaints that a chapter seek past the last chapter was
quitting the player. Change the behavior to what is expected: the last
frame.
If no chapters are available, this still does nothing.
Not all filter sizes the shaders could handle were in the filter_sizes
list. The shader can handle any multiple of 4 (the sizes 2 and 6 are
special-cased to keep it simple).
Add all possible filter sizes, up to 64. 64 is ridiculously high anyway.
Most of the larger filter sizes are completely useless for upscaling,
but help with the fancy-downscaling option. (Although it would still be
more efficient to use cascaded scalers to handle downscaling better.)
I considered doing something less stupid than the hardcoded array, but
it seems this is still the simplest solution.
Before this commit, the convolution scaler shader functions were pre-
instantiated in the shader file. For every filter size, a corresponding
function (with the filter size as suffix) had to be present.
Change this, and make the C code emit the necessary bits.
This means the shader code is much reduced. (Although hopefully it
doesn't make shader compilation faster - it would require a really dumb
compiler if it spends its time on dead code.)
It also makes it more flexible, which is the main goal.
The DEF_SCALER0 stuff is needed because the C code writes the header of
the shader, at a point where scaler macros are not defined yet.
This was a microoptimization for small filters which need 4 or less
weights per sample point. When I originally wrote this code, using a 1D
texture seemed to give a slight speed gain, but now I couldn't measure
any difference.
Remove this to simplify the code.
There's not much of a reason to have the actual convolution code in a
separate function. Merging them actually simplifies the code a bit, and
gets rid of the repetitious macro invocations to define the functions
for each filter size.
There should be no changes in behavior or output.
Windows uses a heuristic to determine if a window should appear
fullscreen. If the active window's client area covers the whole screen,
the taskbar should move to the bottom of the Z-order, allowing the
window to show through.
Unfortunately, sometimes it doesn't work and the taskbar stays on top of
the "fullscreen" window. ITaskbarList2->MarkFullscreenWindow explicitly
tells the shell that a window wants to be fullscreen, so the taskbar is
always at the bottom of the Z-order while the marked window is active.
This might help with #999. Firefox also uses this interface to fix
fullscreen issues.
This should clearly be impossible, but it seems to happen with ordered
chapters for a user.
Since I can't tell what the actual bug is and it seems impossible to
know the details without downloading possibly huge files, this is
probably the best we can do.
Should at least partially fix#1319.
It feels strange that seeking past EOF with --keep-open actually leaves
the player at a random position. You can't even unpause, because the
demuxer is in the EOF state, and what you see on screen is just what was
around before the seek.
Improve this by attempting to seek to the last video frame if EOF
happens. We explicitly don't do this if EOF was reached normally to
increase robustness (if the VO got a frame since the last seek, it
obviously means we had normal playback before EOF).
If an error happens when trying to find the last frame (such as not
actually finding a last frame because e.g. the demuxer misbehaves), this
will probably turn your CPU into a heater. There is no logic to prevent
reinitiating the last-frame search if the last-frame search reached EOF.
(Pausing usually prevents that EOF is reached again after a successful
last-frame search.)
Fixes#819.
This gives better results with fancy-downscaling. The issue here is that
fancy-downscalign "extends" the filter radius by some amount, which
requires using a larger filter size and shader. Then most of the filter
is "unused", but some filters still return non-0 coefficients, which
create heavy artifacts. Just clamp them off.
I'm not sure if this is the right solution, but at least it's better
than before.
Based on patch by Yuriy Kaminskiy [yumkam gmail].
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@37330 b3059339-0415-0410-9bf9-f77b7e298cf2
Signed-off-by: wm4 <wm4@nowhere>
Also replace the weights calculations for 8/12/16 with the generic
weight function definition macro. (The weights 2/4/6 follow slightly
different rules.)
This message was added in commit a0acb6ea. But it showed up in all sorts
of inappropriate contexts, such as when opening m3u from an unseekable
http URL, or playing DVDs. So I guess this didn't work out. Disabling it
again.
m3u files are normally just text files with a list of filenames. Nothing
actually mandates that there is a header. Until now, we've rejected such
files, because there's absolutely no way to detect them.
If nothing else claims the file, the extension is ".m3u", and if the
contents of the file look like text, then load it as m3u playlist. The
text heuristic is pretty cheap, but at least it should prevent trying
to load binary data as playlist. (Which would "work", but result in a
catastrophic user experience.)
Due to the text heuristic, UTF-16/32 files will be rejected (unless they
have a header), but I don't care.
Whether we print it as warning or error doesn't really matter; we
continue anyway. (I don't actually know what the implications of running
in non-blocking mode are; for what's it worth, when I tested with
explicitly changing to non-blocking, it seemed to work fine anyway, so
don't change that part.)
ALSA returns "FL" as channel layout when trying to play mono. mpv and
libavresample don't like this; in particular, using libavresample to
convert stereo to "FL" fails.
If no-block was given, the device would be opened with SND_PCM_NOBLOCK.
Also, after opening, blocking mode was unconditionally enabled anyway
with snd_pcm_nonblock(). Further, if opening with SND_PCM_NOBLOCK
failed, opening was retried without this flag.
This doesn't make any sense to me, and I've never heard of someone using
this suboption. I suspect it has to do with ancient ALSA bugs or API
caveats. Remove it and simplify the code.
ALSA is crap. It's impossible to make multichannel playback just do the
right thing. dmix (the default on most distros) can do stereo only, and
will refuse to play multichannel. On the other hand, if you try like mpv
(and mplayer) to open a multichannel device (like "surround51" etc.),
this will actually open a hardware device, which will either fail if
dmix is active, or block out dmix if opening succeeds.
This commit falls back to "default" (i.e. dmix) if opening a
multichannel device fails, which is a tiny step towards the right
behavior. (Although fixing it fully is impossible.)
This was completely breaking any low-level caching. Change it so that at
least demuxer caching will work.
Do this by using the metadata cache mechanism to funnel through the menu
commands.
For some incomprehensible reason, I had to reorder the events (which
affects their delivery priority), or they would be ignored. Probably
some crap about the event state being cleared before it could be
delivered. I don't give a shit.
All this code sucks. It would probably be better to let discnav.c access
the menu event "queue" directly, and to synchronize access with a mutex,
instead of going through all the caching layers, making things
complicated and slow.
If the user has LEFT/RIGHT/etc. bound in his input.conf, then these were
overriding the menu keys in dvdnav mode.
This hack works because the dvdnav crap happens to be the only user of
MP_INPUT_ON_TOP. If it finds a default key binding in the dvdnav menu
section, it will use that, instead of continuing search and possibly
finding the user key bindings meant for normal playback.
This was required by vf_pp, which was just removed.
vf_dlopen has this stuff in its API. This API is considered stable, so
the related fields are not removed from it. But the fields are always 0
now, so there's no point in keeping the example program around.
vf_pullup.c did some extremely awkward passthrough of this information,
but didn't actually use it.
This is an ancient filter, and we assume it's not useful anymore.
If you really want this, it's still available in libavfilter (e.g. via
--vf=lavfi=[pp...]). The disadvantage is that mpv doesn't pass through
QP information to libavfilter. (This was probably the reason vf_pp still
was part of mpv - it was slightly easier to pass QP internally.)
This wasn't done before because there was no advantage in "abstracting"
it. This changed, and putting this into its own files is better than
messing it into gl_common.c/h.
Same as with the previous commits.
In theory, vdpau/x11 GL interop doesn't assume GLX. It could use EGL as
well. But since it's always GLX in practice, so we're fine with this.
Remove the gl_hwdec.mpgl field - it's unused now.
Basically, don't access the vo field.
There's also no reason anymore to access MPGLContext. We still need to
access loaded GL functions though, so add a field for that to gl_hwdec.
Untested.
This fixes using the mpv:// custom protocol on Yosemite were apparently
we receive an url which is automatically urlencoded by the system.
/cc mpv-player/stable
This is simply not allowed, and doing it triggered an assertion. It's
still not allowed, because the terminal and related functionality is a
global resource, and there doesn't seem to be a sane way to manage the
signal handlers.
But be a bit nicer, and just the terminal if it's already in use.
Note that terminal _output_ happens anyway. This becomes usable with
this commit. To facilitate logging-only usage further, also explicitly
disable terminal input, so that "terminal=yes" can be used for logging
without much interference with other things. (It'll still overwrite some
signal handlers, though.)
Always set the viewport on entry. The way the viewport is tracked is a
bit complicated in my opinion, and in fact it doesn't even reduce the
number of GL calls. Setting it on entry is actually redundant if video
covers the screen fully, because the handle_pass() unconditionally sets
it anyway, but avoiding it would complicate the cases gl->Clear() is
actually needed.
Add a fbo argument to gl_video_render_frame(). This allows you to render
into a FBO rather than the default framebuffer. It will be useful for
providing an API to render on an external GL context. (If that will
actually be added.)
Seems like a waste not to print this.
Anyone with enough technical knowledge to have use for the exact error
can map the number back to the GL symbol, so don't bother to convert it
to a symbol.
So the OSC will still appear when using --no-input-default-bindings. It
also means it may override a user's mouse_move binding, but I guess
users who don't want the OSC should just use the --no-osc option.
The player thinks an error happened because no audio or video was played
after finishing the file, but this obviously makes no sense with stream
dumping. (error_playing follows the client API convention that negative
values are errors.)
Channel amp otpions were not copied correctly: it copied the size of a
pointer to struct chmap, not the struct itself. Since mp_chmap is
currently 9 bytes, this meant the last channel entry was not copied
correctly on 64 bit systems, leading to very strange failures. It could
be triggered especially when using the client API, because the client
API always copies options on access (mpv command line options tend to
work directly on options).
This could trigger an assertion when using ao_alsa or ao_coreaudio. The
code was simply assuming the number of channel maps was bounded
statically (which was true at first in both AOs).
Fix by using dynamic memory allocation. It needs to be explicitly
enabled by the AOs by setting a temp context, because otherwise the
memory couldn't be freed. (Or at least this seems to be the most elegant
solution.)
Fixes#1306.
All of these are already the defaults.
One exception is glDepthMask(), which is enabled by default. But if the
framebuffer has no depth buffer anyway, it shouldn't make a difference.
Before it used whatever was in ao->format and changed the bits even
though this might have nothing to do with the actual WAVEFORMAT
negotiated with WASAPI.
For example, if the initial ao->format was a float and we had set the
WAVEFORMAT to s24, this would create a non-existent float24 format.
Worse, it might put an u16 into ao->format when WAVEFORMAT described s16.
WASAPI doesn't support unsigned at all as far as I can tell.
If EOF is reached after reading a line, the EOF flag is set. This was a
problem for the m3u code, which checked for EOF _after_ reading a line,
which will discard the last line read.
Also fix a typo in an unrelated part of the file.
By now, input.conf is actually just a small part of input handling.
Rename the section to something else ("command interface" was the
first reasonable thing that came to mind).
Also fix a minor typo further down.
libxkbcommon keysyms are the same as X11 keysyms (sans prefix),
so I simply copied the missing subsection from x11_common.c.
Signed-off-by: Sergey Kvachonok <ravenexp@gmail.com>
Signed-off-by: wm4 <wm4@nowhere>
I don't know why this done; most likely it had no real reason.
Remove it because it breaks "refresh seeks" to the same position.
(Although the refresh seeks mpv sometimes does were fine.)
Yep, Lua is so crappy that the stdlib doesn't provide anything like
this.
Repurposes the undocumented mp.format_table() function and moves it to
mp.utils.
MS Windows doesn't allow windows larger than the screen, so we include
a hack to make the window smaller. This hack recenters the window (what
else would it do?).
It didn't account for the virtual offset of the current screen, and it
was reported that it forces the window to the first screen.
Should fix#1292.
Ordered chapter EOF was handled as special-case of ending the last
segment. This broke --kee-open, because it set AT_END_OF_FILE in an
"inconvenient" place (after checking for --keep-open, and before the
code that exits playback if EOF is reached).
We don't actually need to handle the last segment specially. Instead, we
remain in the same segment if it ends. The normal playback logic will
recognize EOF, because the end of the segment "cuts off" the file.
Now timeline_set_from_time() never "fails", and we can remove the old
segment EOF handling code in mp_seek().
All of this is basically due to how MPlayer's codecs.conf worked. It
had a demuxer-interface based an AVI, using FourCCs and data structures
found in AVI. FourCCs were used to map streams to decoders. For codecs
not supported by AVI, "MPlayer internal" FourCCs were made up.
codec_tags.c is there to bridge demuxers written against the old API to
the mpv one. By now, only demux_mkv.c needs this (because demux_mkv is
the only serious demuxer left - preferably, we should use libavformat
for mkv too, but I can't see this happening any time soon, because
libavformat _still_ doesn't support segment linking). But the codec
tables are full of weird stuff automatically extracted from the old
codecs.conf tables. Most of it isn't needed for mkv.
Remove all custom tags, readd those used by demux_mkv.c internally
(see vinfo and mkv_audio_tag tables). The rest is handled by the
tables provided by libavformat, which includes AVI and QT tags.
this involved inverting the logic of find_formats, enumerate_devies
and wasapi_fill_VistaBlob. The latter two were trivial as their return
values were not actually checked (to be fixed in a later
commit).
Before these definitions were incorrectly guarded by and #ifdef
but since they aren't macros, this would never be true so that
if they were ever added to mingw headers we would have problems.
rename KSDATAFORMAT constants with the same mp prefix for consistency.
also use DEFINE_GUID rather than defining the bare structure
It was more complicated than necessary.
The behavior changes slightly. Now it might pass through extradata when
it didn't before (hopefully harmless), and doesn't fail with an error if
extradata is not available, even though it's needed (harmless, will fail
either way).
The if branch has a weak check to test whether the codec_id is the short
ID, and handles the long IDs in the else branch. The long IDs are all
longer than 12 bytes long, so hardcoding the string offset to get the
trailing part of the name makes sense. But the if condition checks for
another thing, which could get the else branch run even if the codec_id
is short.
Fix the bogus control flow and check if the codec_id is long enough. One
of these checks could be considered redundant, but include them both for
defensive coding.
I suspect this is what is happening in github issue #1265 (at least
partially).
If D3DFMT_A8 is not available, fall back to RGBA. This is less efficient
in general, so we normally want to avoid it.
Running "sub_add file.srt auto" during hook execution automatically
selected the first added track. This happened because all tracks added
with sub_add are marked as "external", and external subtitles are always
selected by default.
Fix this by negating the "external" flag when autoselecting subtitles
during loading. The no_default flag exists for this purpose; it was
probably added for libquvi originally, where we had the same issue.
This is a somewhat obscure situation, and happens only if audio starts
again after it has ended (in particular can happens with files where
audio starts later). It doesn't matter much whether audio starts
immediately or some milliseconds later, so simplify it.
When playing paused, the amount of decoded audio is limited to a small
amount (1 sample), because we don't write any audio to the AO when
paused. The small amount could trigger the case of the wanted audio
being too far in the future in the PTS sync code, which set the audio
status to STATUS_DRAINING, which in turn triggered the EOF code in the
next iteration. This was ok, but unfortunately, this triggered another
retry in order to check resuming from EOF by setting the status to
STATUS_SYNCING, which in turn lead to the busy loop by alternating
between the 2 states. So don't try resyncing while paused.
Since the PTS syncing code also calls ao_reset(), this could cause the
pulseaudio daemon to consume some CPU time as well.
This was caused by commit 33b57f55. Before that, the playloop was merely
run more often, but didn't cause any problems.
Fixes#1288.
...because everything is terrible.
strerror() is not documented as having to be thread-safe by POSIX and
C11. (Which is pretty much bullshit, because both mandate threads and
some form of thread-local storage - so there's no excuse why
implementation couldn't implement this in a thread-safe way. Especially
with C11 this is ridiculous, because there is no way to use threads and
convert error numbers to strings at the same time!)
Since we heavily use threads now, we should avoid unsafe functions like
strerror().
strerror_r() is in POSIX, but GNU/glibc deliberately fucks it up and
gives the function different semantics than the POSIX one. It's a bit of
work to convince this piece of shit to expose the POSIX standard
function, and not the messed up GNU one.
strerror_l() is also in POSIX, but only since the 2008 standard, and
thus is not widespread.
The solution is using avlibc (libavutil, by its official name), which
handles the unportable details for us, mostly. We avoid some pain.
Always create the context in mpgl_init(), instead of doing it when
mpgl_config_window() is called the first time. This is a small step
towards cleaning up the GL backend interface, and adding other things
like perhaps GLES support, or a callback-driven backend for libmpv.
this currently uses a sketchy but apparently working workaround,
which will be removed once the neccessary changes in youtube-dl
are implemented
Fixes#1277
This seems safer: otherwise, opening the AO could randomly fail if the
audio formats happens to be not float.
Unfortunately, this only works if the user does not select a device.
Since ALSA devices are arbitrary strings, including plugins with complex
parameters, it's not trivial or maybe even impossible to edit the string
in a way the "plug" plugin is added.
With --audio-device, it would be safe for users to select either
"default" or one of the "plughw" devices. Everything else seems
questionable.
Use the ALSA channel map API for querying and selecting supported
channel maps.
Since we (probably?) want to be compatible with ALSA versions before the
change, we still try to select the device name by channel map, and open
that device. There's no way to negotiate a channel map before opening,
so we're stuck with this approach. Fortunately, it seems these devices
allow selecting and setting any other supported channel layout, so maybe
this is not an issue at all. In particular, this avoids selecting the
default (dmix) device, which can only do stereo.
Most code is based on Martin Herkt <lachs0r@srsfckn.biz>'s alsa_ng
branch, with heavy modifications.
Don't crash if no fallback channel layout could be found (caller can't
handle NULL return from select_chmap()). Apparently this could never
actually happen, though.
Don't treat snd_pcm_hw_params_set_periods_near() failure as fatal error.
Same deal as with snd_pcm_hw_params_set_buffer_time_near().
Actually free channel maps returned by snd_pcm_get_chmap().
Adjust some messages.
Currently, --ytdl is off by default, but even if this is changed, never
enable it by default for the client API. It would be inappropriate to
start an intrusive external subprocess behind the host application's
back.
No functional changes.
ALSA_PCM_NEW_HW_PARAMS_API was a pre-ALSA 1.0.0 thing and does nothing
with modern ALSA. It stopped being necessary about 10 years ago.
3 functions are moved to avoid forward references.
Makeshift-solution for working around certain fontconfig issues.
With --use-text-osd=no, libass and fontconfig won't be initialized, and
fontconfig won't block everything with scanning for fonts.
If ALSA reports a channel map, and it looks like it makes sense (i.e.
could be converted to mpv channel map, and the channel count matches),
then use that instead of the channel map we are assuming.
This is based on code written by lachs0r (alsa_ng branch).
We don't actually want to test all possible combinations; we just want
to make sure that each thing (e.g. linux/osx, ffmpeg/libav) is tested
once.
Exclude Linux + ffmpeg-stable, because ffmpeg-stable is already tested
on OSX.
Exclude clang on Linux, because OSX needs clang, but Coverity (running
on Linux) needs gcc - so we use gcc only on Linux.
I also wanted to reduce the matrix to a single configuration when
running Coverity, but apparently this is not possible.
(See travis-ci/travis-ci#1975.)
For the purpose of running Coverity correctly.
Although I'm not sure how well this works. gcc won't work on OSX, and
also I'm not sure if Coverity will act up if the build matrix has more
than 1 configuration (will it submit multiple scans?).
Simpler, and leaves the decision to repeat or not fully to the script
(instead of requiring the user to care about it when remapping a script
binding).
Use a fixed size array for the client name, which also limits the client
name in size. Sanitize the client name string, and replace characters
that are not in [A-Za-z0-9] with '_'.
Otherwise, mouse button bindings added by mp.add_key_binding() would be
ignored.
It's possible that this "breaks" some older scripts using undocumented
Lua script functions, but it should be safe otherwise.
Fixes#1283.
The subprocess code was already split into fairly general functions,
separate from the Lua code. It's getting pretty big though, especially
the Windows-specific parts, so move it into its own files.
Normally, when creating a process with inherited handles on Windows, the
process inherits all inheritable handles from the parent, including ones
that were created on other threads. This can cause a race condition,
where unintended handles are copied into the new process, preventing
them from being closed correctly while the process is running. The only
way to prevent this on Windows XP was to serialise the creation of all
inheritable handles, which is clearly unacceptable for libmpv.
Windows Vista solves this problem by allowing programs to specify
exactly which handles are inherited, so do that on Vista and up.
See http://blogs.msdn.com/b/oldnewthing/archive/2011/12/16/10248328.aspx
The CREATE_NO_WINDOW flag is used to prevent the subprocess from
creating an empty console window when mpv is not running in a console.
When mpv is running in a console, it causes the subprocess to detach
itself, and prevents it from seeing Ctrl+C events, so it hangs around in
the background after mpv is killed.
Fix this by only specifying CREATE_NO_WINDOW when mpv is not attached to
a console. When it is attached to a console, subprocesses will
automatically inherit the console and correctly receive Ctrl+C events.
I'm not sure if this is necessary, but it can't hurt, and it's what
you're supposed to do before leaving the stack frame that contains the
OVERLAPPED object and the buffer. If there is no pending I/O, CancelIo
will do nothing and GetOverlappedResult will silently fail.
The caller set up the "start" pointer array using the number of planes,
the encode() function used the number of channels. This copied
uninitialized values for packed formats, which makes Coverity warn.
From what I understand the division is to align the dimension of the
value from seconds to milliseconds. Hard to tell whether the "rounding"
was intentional or not; I'm tipping on "not".
Found by Coverity.
Silences a Coverity warning.
Also, drop the assert(); although it should be pretty much guaranteed
that things happen this way, it's still a bit fuzzy.
In addition to the messed-up expression, the endianness was also
inverted. The code reads big endian by default.
It "worked" by coincidence, but for little endian, codepoints outside of
latin1 were broken.
The broken expression was found by Coverity.
In all of these situations, NULL is logically not allowed, making the
checks redundant.
Coverity complained about accessing the pointers before checking them
for NULL later.
The fact that it's a generic command prefix that is parsed even when
using the client API is a bit unclean (because this flag makes sense
for actual key-bindings only), but it's less code this way.
Does the same thing as the drop_buffers command. When implementing that
command, it turned out that resetting the higher level playback state
was more effective for achieving smooth recovery.
Untested; I don't even have any DVDs or DVD images with multiple angles.
This command was actually requested on IRC ages ago, but I forgot about
it.
The main purpose is that the decoding state can be reset without issuing
a seek, in particular in situations where you can't seek.
This restarts decoding from the middle of the packet stream; since it
discards the packet buffer intentionally, and the decoder will typically
not output "incomplete" frames until it has recovered, it can skip a
large amount of data.
It doesn't clear the byte stream cache - I'm not sure if it should.
Avoids a crash if OpenSSL tries to write to a broken connection with
write().
Obviously OpenSSL really should use send() with MSG_NOSIGNAL, but for
some reason it doesn't. This should probably be considered an OpenSSL
bug, but since in this case we "own" the process, there is no harm in
ignoring the signal.
This is not done with libmpv, because as a library we don't want to mess
with global state. It's also not done if terminal handling is disabled -
this is a bit arbitrary, but I don't care much.
It's passed with the '--format' option to youtube-dl.
If it isn't set, we don't pass '--format best' so that youtube-dl can
use the options from its configuration file.
Signed-off-by: wm4 <wm4@nowhere>
This sub-option was turned into a flag when the sub-option parser was
changed to the generic one (probably accidentally). Turn it into a
proper choice-option.
Also, adjust what the options do. Though none of this probably makes
much sense; the default should work, and if it doesn't, the GPU/driver
is probably beyond help.
Instead of threads, use overlapped (asynchronous) I/O to read from both
stdout and stderr. Like in d0643fa, stdout and stderr could be closed at
different times, so a sparse_wait function is added to wrap
WaitForMultipleObjects and skip NULL handles.
When the audio thread fails to properly init, it signals failure
to the main thread, AND THEN starts to clean up. For this to work,
ao_init callback must not return until the thread's cleanup is finished.
This is correctly handled in the ao_uninit callback by waiting for
the thread to exit, so just call that to clean up the main thread.
I have no idea why I didn't do this in the first place.
Probably needs to be polished a bit more. Also, might require a key
binding that can set/clear the loop points in a more intuitive way.
For now, something like this can be put into input.conf to use it:
ctrl+y set ab-loop-a ${time-pos} # set A
ctrl+x set ab-loop-b ${time-pos} # set B
ctrl+c set ab-loop-a no # clear (mostly)
Fixes#1241.
Due to the current code structure, the "current" entry and the entry
which is playing can be different. This is probably silly, but still
try to mark the entries correctly.
Refs #1260.
This actually doesn't even write/return the new sub-property, because
I dislike the idea of dumping that field for every single playlist
entry, even though it's "needed" only for one.
Fixes#1260.
dsound was set as default, because there were some hard to fix problems
with wasapi. These problems were probably fixed now, so let's try with
wasapi as default again.
Even with change notifications, there are still (rare) cases when the
feed thread gets AUDCLIENT_DEVICE_INVALIDATED. So handle failures in
thread_feed by requesting ao_reload.
on changes to PKEY_AudioEngine_DeviceFormat, device status, and default device.
call ao_reload directly in the change_notify "methods".
this requires keeping a device enumerator around for the duration of
execution, rather than just for initially querying devices
Before, failures, particularly in the thread loop init, could lead to a
bad state for the duration of mpvs execution. Make sure that
everything that was initialized gets properly and safely
uninitialized.
Now that the code for stderr and stdout does exactly the same things,
and the specialization is in the callbacks, this is blatantly
duplicated.
Also, define a typedef for those callbacks to reduce the verbosity.
Do a minimal check on data read with stream_peek(). This could help with
probing from unseekable streams in some situations. (We could check the
entire EBML and Matroska headers, but probably not worth the trouble. We
could also seek back to the start, which demux.c doesn't do, but which
would work usually - also not worth the trouble.)
libass won't use embedded fonts, unless ass_set_fonts() (called by
mp_ass_configure_fonts()) is called. However, we call this function when
the ASS_Renderer is initialized, which is long before the .ass file is
actually loaded. (I'm not sure why it tries to keep 1 ASS_Renderer, but
it always did this.)
Fix by calling mp_ass_configure_fonts() after loading them. This also
means this function will be called multiple times - hopefully this is
harmless (it will reinit fontconfig every time, though).
While we're at it, also initialize the ASS_Renderer lazily.
Fixes#1244.
Make the changes started in commit c827ae5f more eloborate, and provide
an option to control the amount of data read before the seek-target. To
achieve this, rewrite the loop that finds the lowest still acceptable
target cluster. It is now searched by time instead of file position. The
behavior (both with and without preroll option) may be different from
before this change, although it shouldn't be worse.
The change demux_mkv_read_cues() fixes a bug: when seeking after playing
normally, the code would erroneously assume that durations are set. This
doesn't happen if the first operation after loading was a seek instead
of playback.
This might be interesting for GUIs and such.
It's probably still a little bit insufficient. For example, the filter
and audio/video output lists are not available through this.
When mpv is backgrounded initially (via & in the shell), do no longer
change terminal settings on startup. This fixes broken local echo after
launching a backgrounded mpv.
This was removed in commit 480f82fa. This caused the cache display not
to update while paused, because the update_cache() function is never
called in the thread (now I remember why the extra call was "needed").
The old implementation intentionally run update_cache() only before
waiting on a mutex, with no further checks for the condition variable.
In theory, this is strictly not sane, but since it was just for the
retrieval of the very fuzzy cache status, it was ok. Now we want to call
update_cache() outside of the mutex though - which means that in order
to avoid missed wakeups, a proper condition has to be used.
Remove the extra vf_chain.output field - there's absolutely no need for
it, because there is always a last filter which will buffer the output.
For some reason, vf_chain.last was never set, which we now need to fix
too.
The purpose of temporarily setting stop_play was to make the audio
uninit code to explicitly drain audio if needed. This was the only way
to do it before ao_drain() was made a separate function; now we can just
do it explicitly instead.
We absolutely need to clear the AO reference in the mixer.
The audio_status must be changed to a state where no code assumes that
the AO is available. (It's allowed to do this blindly.)
When initialization failed, vo_lavc may cause an irrecoverable state in
the ffmpeg-related structs. Therefore, we reject additional
initialization attempts at least until we know a better way to clean up
the mess.
ao_lavc currently cannot be initialized more than once, yet it's good to
do consistent changes there as well.
Also, clean up uninit-after-failure handling to be less spammy.
The mp_audio_from_avframe() function requires the AVFrame to be
refcounted, and merely increases its refcount while referencing the same
data. For non-refcounted frames, it simply did nothing and potentially
would make the caller pass around a frame with dangling pointers.
(libavcodec should always return refcounted frames, but it's not clear
what other code does; and also the function should simply work, instead
of having weird requirements on its arguments.)
Revert commit 24e52f66; even though the old beheavior doesn't make sense
(as the commit message assured), it turns out that this works better:
typically, it means preroll will start from the previous video key frame
(the video CUE index will contain clusters with video key frames only),
which often coincides with subtitle changes. Thus the old behavior is
actually better.
Change the code that uses CueDuration elements. Instead of merely
checking whether preroll should be done, find the first cluster that
needs to be read to get all subtitle packets. (The intention is to
compensate for the enlarged preroll cluster-range due to reverting
commit 24e52f66.)
The previous fix breaks another obscure case: if the second vf_sub adds
margins, the image is accidentally not extended, which would return in
an assertion failure when returning the bogus image.
This rewrites the audio decode loop to some degree. Audio filters don't
do refcounted frames yet, so af.c contains a hacky "emulation".
Remove some of the weird heuristic-heavy code in dec_audio.c. Instead of
estimating how much audio we need to filter, we always filter full
frames. Maybe this should be adjusted later: in case filtering increases
the volume of the audio data, we should try not to buffer too much
filter output by reducing the input that is fed at once.
For ad_spdif.c and ad_mpg123.c, we don't avoid extra copying yet - it
doesn't seem worth the trouble.
Use a pseudo-filter when changing speed with resampling, instead of
somehow changing a samplerate somewhere. This uses the same underlying
mechanism, but is a bit more structured and cleaner. It also makes some
of the following changes easier.
Since we now always use filters to change audio speed, move most of the
work set_playback_speed() does to recreate_audio_filters().
A helper to allocate refcounted audio frames from a pool. This will
replace the static buffer many audio filters use (af->data), because
such static buffers are incompatible with refcounting.
Causes the player to reload the demuxer and to relist the found
streams. Probably slightly dangerous/broken, because the demuxer
thread and possibly even the decoders will keep reading data from
the new title before the new demuxer takes over.
Fixes#1250.
A first step towards refcounted audio frames.
Amazingly, the API just does what we want, and the code becomes
simpler. We will need to NIH allocation from a pool, though.
If the audio callback suddenly stops, and the AO provides no "reset"
callback, then reset() could deadlock by waiting on the audio callback
forever.
The waiting was needed to enter a consistent state, where the audio
callback guarantees it won't access the ringbuffer. This in turn is
needed because mp_ring_reset() is not concurrency-safe.
This active waiting is unavoidable. But the way it was implemented, the
audio callback had to call ao_read_data() at least once when reset() is
called. Fix this by making ao_read_data() set a flag upon entering and
leaving, which basically turns p->state into some sort of spinlock.
The audio callback actually never needs to spin, because there are only
2 states: playing audio, or playing silence. This might be a bit
surprising, because usually atomic_compare_exchange_strong() requires a
retry-loop idiom for correct operation.
This commit is needed because ao_wasapi can (or will in the future)
randomly stop the audio callback in certain corner cases. Then the
player would hang forever in reset().
As usual, we use C11 semantics, and emulate it if <stdatomic.h> is not
available.
It's a bit messy with __sync_val_compare_and_swap(). We assume it has
"strong" semantics (it can't fail sporadically), but I'm not sure if
this is really the case. On the other hand, weak semantics don't seem to
be possible, since the builtin can't distinguish between the two failure
cases that could occur. Also, to match the C11 interface, use of gcc
builtins is unavoidable. Add a check to the build system to make sure
the compiler supports them (although I don't think there's any compiler
which supports __sync_*, but not these extensions).
Needed for the following commit.
This is what you would expect. Before this commit, each
ao_request_reload() call would just queue a reload command, and then
recreate the AO for the number of times the function was called.
Instead of sending a command, introduce some sort of event retrieval
mechanism. At least for the reload case, use atomics, because we're too
lazy to setup an extra mutex.
This commit fixes a "cosmetic" user interface issue. Instead of
displaying the interpolated seek time on OSD, show the actual audio
time.
This is rather silly: when seeking in audio-only mode, it takes some
iterations until audio is "ready", but on the other hand, the audio
state machine is rather fickle, and fixing this cosmetic issue would be
intrusive. So just add a hack that paints over the ugly behavior as
perceived by the user. Probably the lesser evil.
It doesn't happen if video is enabled, because that mode sets the
current time immediately to video PTS. (Audio has to be synced to video,
so the code is a bit more complex.)
Fixes#1233.
This reverts commit d859549424.
Going to apply the alternative fix through PR #1256, which came just
some seconds after pushing the reverted commit. The reverted commit
was reported as not actually working.
Found by clang sanitizer. Casting unsigned integers to signed integers
with same size has implementation defined behavior (it's even allowed to
crash), but it seems reasonable to expect that reasonable
implementations do a complement of 2 "conversion".
Following the discussion in #1253.
The events won't be removed for a while, though. (Or maybe never, unless
we run out of bits for the uint64_t event mask.)
This is not a real change (the events still work, and the alternative
mechanisms were established a few API revisions earlier), but for the
sake of notifying API users, update DOCS/client-api-changes.rst.
The values compared here happen to be of unsigned enum types - but the
test is not supposed to break if we somehow force the enum to signed, or
if the compiler happens to use a signed type (as far as I remember, the
exact integer type the compiler can use is implementation-defined).
The main need I see for this is with libmpv - it would be confusing if
some application showed up as "mpv" on whateverthehell PulseAudio uses
it for (generally it does show up on various PA GUI tools).
This silences the warning:
video/out/gl_video.c:1091:51: runtime error: division by zero
when running with clang -fsanitize=undefined. Division by zero is legal
according to IEEE, but I guess clang doesn't care about standard. While
triggering this warning isn't actually avoided in all cases, it's
avoided in the common case and also makes people shut up about it.
Call VOCTRL_GET_DISPLAY_NAMES it when the property is
requested. The vo should return the names of the displays that the mpv
window is covering. For example, with x11 vos, xrandr names LVDS1,
HDMI1, etc.
XRRGetOutputInfo contains a "name" element which corresponds to to the
display names given to the user by the "xrandr" command line
utility. Copy it into the xrandr_display struct for each display.
On VOCTRL_GET_DISPLAY_NAMES, send a copy of the names
of the displays spanned by the mpv window on.
The intention is to avoid using the timeout-based fallback.
There's some minor hope that this will help with OpenBSD (see #1239),
although it probably won't.
Some chance that this will cause trouble with obscure OSS
implementations or emulations.
If calling ao->driver->wait() fails, we need to fallback to timeout-
based waiting. But it could be that at this point, the mutex was already
released (and then re-acquired). So we need to recheck the condition in
order to avoid missed wakeups.
This probably wasn't an actually occurring problem, but still could
cause a small race-condition window if the dynamic fallback is actually
used.
This considered only index entries that were for the same track ID as
the track used for seeking. This doesn't make much sense for preroll;
it'll just possibly skip clusters, and select an earlier cluster.
One possible negative side-effect is that the preroll might be too tight
now, and miss subtitle packets more often.
The demuxer has a hack to seek to the cluster before the target cluster
in order to "catch" subtitle lines that start before the seek target,
but overlap with the video after the seek target.
Avoid this hack if the cue index indicates that there are no overlapping
subtitle packets that can be caught by seeking to the previous cluster.
Nothing is done with them yet. This is preparation for the following
commit.
CueRelativePosition isn't even saved anywhere, because I don't intend to
use it. (Too messy for no gain.)
Instead of indexing only 1 packet per cluster (which is enough for
working seeking), add every packet to the index.
Since on seek, we go through every single index entry, this probably
makes seeking slower. On the other hand, this code is used for files
without index only (e.g. incomplete files), so it probably doesn't
matter much.
Preparation for the following commits.
update_subtitle() already uees playback_pts to make subtitles work
better in no-audio mode. Using get_current_time() usually gets
playback_pts, but also has the advantage that it will use the seek
target time during seeks. This will result in multiple sub_seek commands
doing the right thing (at least as long as they're far enough apart so
that seeking is actually initiated when the second command is run).
If no packets are queued, the readahead time is obviously 0.
If the end time is smaller than the start time, the problem is probably
that audio and video start at slightly different times - report 0 in
this case too.
Do this because seeing "???" as readahead time is a bit annoying.
Instead, use the native-endian alias, and switch the wayland format
depending on the target platform's endian.
This drops support for swapped-endian formats, but I think that is ok.
Not only are the affected formats rather ancient and backwards, but
using swapped formats probably does not make any sense for performance
either.
Untested.
These formats are still supported; you just can't reference them via a
defined constants directly. They are now handled via the generic
passthrough.
(If you want to use such a format, you either have to add the entry
back, or use AV_PIX_FMT_* directly.)
This is a rather radical change: instead of maintaining a whitelist of
FFmpeg formats we support, we automatically support all formats.
In general, a format which doesn't have an explicit IMGFMT_* name will
be converted to a known format through libswscale, or will be handled
by code which can treat pixel formats in a generic way using the pixel
format description, like vo_opengl.
AV_PIX_FMT_UYYVYY411 is a special-case. It's packed YUV with chroma
subsampling by 4 in both directions. Its component order is documented
as "Cb Y0 Y1 Cr Y2 Y3", meaning there's one UV sample for 4 Y samples.
This means each pixel uses 1.5 bytes (4 pixels have 1 UV sample, so
4 bytes + 2 bytes). FFmpeg can actually handle this format with its
generic mechanism in an extremely awkward way, but it doesn't work for
us. Blacklist it, and hope no similar formats will be added in the
future.
Currently, the AV_PIX_FMT_*s allowed are limited to a numeric value of
500. More is not allowed, and there are some fixed size arrays that need
to contain any possible format (look for IMGFMT_END dependencies).
We could have this simpler by replacing IMGFMT_* with AV_PIX_FMT_*
through the whole codebase. But for now, this is better, because we
can compensate for formats missing in Libav or older FFmpeg versions,
like AV_PIX_FMT_RGB0 and others.
FFmpeg has only a AV_PIX_FMT_FLAG_BE flag, not a LE one, which causes
problems for us: we want to have the LE flag too, so code can actually
detect whether a format is non-native endian. Basically, we want to
reconstruct the LE/BE suffix all AV_PIX_FMT_*s have.
Doing this is hard due to the (messed up) way AVPixFmtDescriptor works.
The worst is AV_PIX_FMT_RGB444: this group of formats describe an
endian-independent access (since no component actually spans 2 bytes,
you only need byte accesses with a fixed offset), so we have to go
through some pain.
This influences the demuxer readahead display. If a stream has reached
EOF, we want to ignore it for the purpose of this calculation.
Note that if a stream contains no packets, it still should cause the
value 0s to be displayed (unless it's EOF), because that's just the
actual situation.
This was relying on the fact that timestamps will always be numerically
larger than MP_NOPTS_VALUE, but the trick didn't actually work for
MP_PTS_MIN. Be a bit more sincere, and don't rely on this anymore. This
fixes the comparison, and avoids the readahead amount displaying as
"???" in some situations (since one of the values was NOPTS).
In this case, we didn't find any new packets for this stream, even
though we've read ahead as much as possible. (If reading ahead in this
case, the "Too many packets in the demuxer packet queues" error is
normally printed.)
If we do consider this an underrun, handle_pause_on_low_cache() will
pause and show the "buffering" state, which is not useful.
Could also happen on very bad interleaving.
This mechanism was introduced for Opus, and allows correct skipping of
"preroll" data, as well as discarding trailing audio if the file's
length isn't a multiple of the audio frame size.
Not sure how to handle seeking. I don't understand the purpose of the
SeekPreRoll element.
This was tested with correctness_trimming_nobeeps.opus, remuxed to mka
with mkvmerge v7.2.0. It seems to be correct, although the reported file
duration is incorrect (maybe a mkvmerge issue).
Add a generic mechanism to the VO to relay "extra" events from VO to
player. Use it to notify the core of window resizes, which in turn will
be used to mark all affected properties ("window-scale" in this case) as
changed.
(I refrained from hacking this as internal command into input_ctx, or to
poll the state change, etc. - but in the end, maybe it would be best to
actually pass the client API context directly to the places where events
can happen.)
Add a comment about this to avoid confusing users of this function. The
parameter is essentially unused, but exists so that we don't need to
add extra APIs if the need for it arises.
Instead of defining a separate data structure in the core.
For some odd reason, demux_chapter exported the chapter time in
nano-seconds. Change that to the usual timestamps (rename the field
to make any code relying on this to fail compilation), and also remove
the unused chapter end time.
Note that you can't pass .cue or .edl files to it, at least not yet.
Requested in context of allowing to specify custom chapters. For that
to work well, we probably need to add some sort of chapter metadata
pseudo-demuxer.
Using the --playlist option is no longer recommended.
A while ago, mpv rewrote all playlist parsers and added some minimal
security mechanisms (like not allowing local file access or unsafe
protocols in remote playlists). Further, mpv can load playlists by
passing them as normal file arguments, without the option.
Now, --playlist is needed only in these situations:
1) loading plaintext files
2) disabling additional security mechanisms
(e.g. using a remote playlist to play local files)
NSDisableScreenUpdates came to hunt me in the end and when mpv was paused, it
did wait for a frame that never came (because of interaction with the live
resizing code)!
This was shown only if decoder-framedropping was enabled, and only if at
least 50 frames were dropped by it. Since drop_frame_cnt used to mean
"number of late frames", this code made sense, but this is not the case
anymore: drop_frame_cnt can be even 0, all while video gets hopelessly
behind audio.
One problem with this is that short desync spikes (which usually can
probably dealt with) will also cause this message to be shown. If it
gets triggered too often, the code will need to be adjusted.
This shouldn't use the host's 'ar' when building static libs. It only
worked until now because Linux 'ar' is usually built with PE support.
Couldn't confirm whether it works, because this dumb crap is just
broken when cross-compiling to mingw.
Thanks to STREAM_CTRL_HAS_AVSEEK, we actually know whether CTRL_AVSEEK
is implemented at all, and we can avoid a blocking wait on the cache if
demux_lavf sends CTRL_AVSEEK even if it won't wait. I'm hoping this
can't currently happen, but why hope if we can explicitly prevent it.
It'll make us more robust against future changes in libavformat.
For example, if --force-window is used, and video is switched off during
playback, then you need to redecide the rendering method to get subs
displayed correctly.
Do this by moving the state setup code into a function, and call it on
every frame.
Apparently this can "sometimes" return an error. In my opinion, this
should never return an error: neither the semantics of the function,
nor the ALSA documentation or ALSA sample code seem to indicate that
a failure is to be expected. I'm not perfectly sure about this though
(I blame ALSA being a weird, big, underdocumented API).
Since it causes problems for some users, and since there is really no
reason why we should abort on such an error, turn it into a warning.
Fixes#1231.
If you played e.g. an audio-only file and something bad happened that
interrupted playback, the exit message could say "No files played".
This was awkward, so show a different message in this case.
Also overhaul how the exit status is reported in order to make this
easier. This includes things such as not reporting a playback error
when loading playlists (playlists contain no video or audio, which
was considered an error).
Not sure if I'm happy with this, but for now it seems like a slight
improvement.
Basically, this will mark the demuxer as seekable with rtmp* and mmsh
protocols. These protocols have network-level time seeking, and whether
you can seek on the byte level does not matter.
Until now, seeking was typically only enabled because of the cache, and
a (nonsensical) warning was shown accordingly.
It still could happen that the server doesn't actually support thse
requests (or simply rejects them), so this is somewhat imperfect.
I'm not sure if this could be done in libavformat instead. Probably not,
because libavformat doesn't seem to have any mechanism for trying one
protocol and reverting (or redirecting) to another one if needed.
This commit is sort of a hack too, because it redirects the URL by
pretending the http:// link is a playlist containing the mmsh:// link.
The list of mime types is borrowed from MPlayer (which has completely
different code to handle this).
Apparently this is needed for correct 3D mode subtitles. In general,
it seems you need to duplicate the whole "GUI", so it's done for all
OSD elements.
This doesn't handle the "duplication" of the mouse pointer. Instead,
the mouse can be used for the top/left field only. Also, it's possible
that we should "compress" the OSD in the direction it's duplicated, but
I don't know about that.
Fixes#1124, at least partially.
This is probably what libmpv users want; and it also improves error
reporting (or we'd have to add a way to communicate such mid-playback
failures as events).
This was probably done incorrectly in cases when the currently selected
channel had no data. I'm not sure if this codepath is functional at all,
though. Maybe not.
Untested due to lack of DVB hardware.
Using magic integer values was an attempt to keep the API less verbose.
But it was probably not a good idea.
Reason 1 (restart) is not made explicit, because it is not used anymore
starting with the previous commit. For ABI compatibility, the value is
left as a hole in the enum.
Use the codepath that is normally used for DVD/BD title switching and
DVB channel switching. Removes some extra artifacts from the client API:
now MPV_EVENT_END_FILE will never be called on reloads (and neither is
MPV_EVENT_START_FILE).
This was originally done for DVD/BD/DVB, where the start position could
be something different from 0, and seeking back to 0 would mess it up
completely.
Since we're not quite sure that these streams are unseekable, we can
simplify this somewhat, and also make sure we also start at 0 for normal
files. Helps a little bit with the following edition reloading commit.
The only reason for mpv_wait_event() not being thread-safe is that it
returns a pointer to a mpv_event struct member in the mpv_handle
context, which in turn is done for ABI-safety (user doesn't allocate or
manage the struct), and to avoid the need additional memory management.
Some users were interpreting this incorrectly.
Without --force-window, this is called on every iteration or so, and
calling uninit_video_out() sends the video-reconfig event. Avoid sending
redundant events.
Fixes#1225 (using an alternative patch).
In interlaced modes, we output fields, not complete frames, so the
framerate doubles.
The method to calculate this was borrowed from xrandr code.
Hopefully fixes#1224.
At least on my machine, reading back the frame with system memcpy is
slower than just using software rendering. Use the optimized gpu_memcpy
from LAV to speed things up.
Pretty much a fringe-feature, but also it's awkward if something appears
on the terminal with no indication for the source.
This is made quite awkward by the fact that stderr and stdout could be
closed at different times, and that poll() doesn't accept "holes" in its
FD list. Invalid (.e.g negative) FDs just make it return immediately, as
required by the standard. So sparse_poll() takes care of the messy
details.
What was the purpose of that? Probably none.
Also simplify another thing: if we get the cancel signal through FD,
there's no reason to check it separately.
We need to manually define the flag since we are using a separate identifier
for each of the Lua checks. This was done before 9b45b48 by the composed check
with a define_key (see waftools/checks/generic.py).
The pkg-config check was the only one to not redefine a define key because Waf
already does that automatically when we call the generated function with the
same identifier as the generator function. Now if they are called with two
different arguments we will get two different definitions.
Fixes#1218
No development activity (or even any sign of life) for almost a year.
A replacement based on youtube-dl will probably be provided before the
next mpv release. Ask on the IRC channel if you want to test.
Simplify the Lua check too: libquvi linking against a different Lua
version than mpv was a frequent issue, but with libquvi gone, no
direct dependency uses Lua, and such a clash is rather unlikely.
The immediate mode (which is the default) uses a tiny ringbuffer and
doesn't grab timestamps. This leads to quite bad behavior due to the
fact that there's an additional buffer between playloop and TV code (the
demuxer thread, which doesn't exist in MPlayer).
Always grab the timestamps and use a decently-sized buffer. I still have
no clue what I'm doing, and hacked it until it appeared to work. Report
regressions if you experience any.
I can't believe how shitty this (MPlayer-derived) code is. Maybe it
should be fixed or be replaced with using libavdevice, but that doesn't
seem worth the effort.
Anyway, for now reduce the time it's blocking to wait for new frames
from 10ms to 1ms, because 10ms might be a bit too tight: it could
deliver the frame up to 10ms late - now it's only up to 1ms. (And yes,
it does that instead of using condition variables. It also abuses
volatile variables as atomics. It's hilarious.)
stream_rar.c peeks the first few bytes when trying to open, which means
that opening any stream reads at least 2KB of data (internal buffer
size) on opening. This broke --stream-dump, which saved only the data
following this initial buffer.
Hack it around by writing the current buffer to the capture file too,
and move stream_capture_write() above stream_set_capture_file() for this
purpose.
Cleaner solutions might include: handling the terrible rar thing
differently, or using the "proper" stream API for dumping. (The latter
is not done, because --stream-dump shares code with the --stream-capture
misfeature.)
Fixes#1215.
Apparently if resizing a NSWindow from a secondary thread Cocoa will
automatically protect itself using NSViewHierarchyLock and in our case,
cause a deadlock.
Fixes#1210
Although this is fine when the stream cache is active (which caches
these and returns the result immediately), it seems cleaner not to
rely on this detail.
Remove the update_cache() call from demux_thread(), because it's sort
of in the way. I forgot why it exists, and there's probably no good
reason for it to exist anyway.
It's needed for some obscure feature in combination with .rar reading.
However, it's unconditionally used by the subtitle loader code, so take
care of not blocking the main thread unnecessarily.
(Untested.)
So a client API user can know when a window is created or destroyed.
Also might be useful for the OSC: it could disable itself if video is
disabled.
Before this commit, there were only indirect ways of detecting this.
Most things should be allowed to access the client API unconditionally
(for example for sending events), so move destroying the client API
down. Also, mp_uninit_ipc() should happen before the point at which all
clients are shutdown, or there will be a small time window in which new
clients can be created after destroying them all.
Wether and when the text of a button should be squeezed when it
gets too long can now be configured in the layout:
lo.button.maxchars = <number>
nil = no squeezing (default)
If the button text has more than <maxchars> characters, it will
be squeezed to the estimated width of <maxchars>.
Doing that doesn't make sense anyway: it's meant for interactive input,
and if the output of the player is not on the terminal, how will you
interact with it?
It was also quite in the way when trying to read verbose output with
e.g. less while the player was running, because the player would grab
half of all input meant for less (simply because stdin is still
connected to the terminal).
Remove the now redundant special-casing of pipe input.
The player was supposed to exit playback if both video and audio failed
to initialize (or if one of the streams was not selected when the other
stream failed). This didn't work; for one this check was missing from
one of the failure paths. And more importantly, both checked the
current_track array incorrectly.
Fix these issues, and move the failure handling code into a common
function.
CC: @mpv-player/stable
Some rationale for the documented/suggested behavior:
It's not really clear what to do with invalid UTF-8, since JSON simply
can't transport this information. Maybe you could transfer such strings
as byte arrays, but that would be very verbose and inconvenient, and
would pose the problem that it's hard to distinguish between strings
encoded in this way and actual arrays.
There are many other ways how this could be handled. For example, you
could replace invalid sequences with '?'. Or you could do it like
Python, and use certain reserved unicode codepoints to "tunnel" through
invalid bytes.
Which of these works really depends on the application. And since this
can be done entirely on the byte level (invalid UTF-8 sequences can
appear only in strings in our case), it's best to leave this to the
receiver.
Assume mpv.exe is located in $mpv_exe_dir, then config files were
preferably loaded from "$mpv_exe_dir/mpv". This was mostly traditional,
and inherited from MPlayer times.
Reverse the config path priority order, and prefer $CSIDL_APPDATA/mpv as
main config path. This also fixes behavior when writing watch_later
configs, and mpv is installed in a not-writable path.
It's possible that this will cause regressions for some users, if the
change in preference suddenly prefers stale config files (which may
happen to longer around in the appdata config dir) over the user's
proper config.
Also explicitly document the behavior.
Since the list associated with --audio-device is supposed to enable
simple user-selection, it doesn't make much sense to include overly
special things like ao_pcm or ao_null in the list. Specifically,
ao_pcm is harmful, because it will just dump all audio to a file
named audiodump.wav in the current working directory. The user can't
choose the filename (it can be customized, but not through this
option), and the working directory might be essentially random,
especially if this is used from a GUI.
Exclude "strange" entries. We reuse the fact that there's already a
simple list ordered by auto-probe priority in order to avoid having to
add an additional flag. This is also why coreaudio_exclusive was moved
above ao_null: ao_null ends auto-probing and marks the start of
"special" outputs, which don't show up on the device, but we want
coreaudio_exclusive to be selectable (I think).
Move it above ao_null, so that it can be selected during auto-probing
(even if it's only last). I see no reason why it should not be included,
and it makes the following commit slightly more elegant. (See
explanations there.)
Because Lua is so terrible, it's easy to confuse temporary values pushed
to the Lua stack with arguments if the arguments are checked after that.
Add a hack that should fix this.
The behavior of reverse cycling (with the "!reverse" magic value) was a
bit weird and acted with a "delay". This was because the command set the
value the _next_ command should use. Change this and make each command
invocation select and use the next command directly. This requires an
"uninitialized" special index in the counter, but that is no problem at
all.
Due to the way video-rotate currently works, the state will be
automatically updated once new video is decoded. So the filter chain
doesn't need to be reinitialized automatically, but there is a need to
trigger the video instant refresh code path instead.
Also move the support function closer to an annoying similar yet
different function. They probably can be unified next time major changes
are done to this code.
Allows properly changing/updating the cursor state. Useful for client
API window embedding, because the host application may not want the mpv
window to grab mouse input, and this has to manually handle the cursor.
Changing the cursor of foreign windows is usually not sane.
It might make sense to allow changing the cursor icon, but that would be
much more complicated, so I won't add it unless someone actually
requests it.
Apparently using the stream index is the best way to refer to the same
streams across multiple FFmpeg-using programs, even if the stream index
itself is rarely meaningful in any way.
For Matroska, there are some possible problems, depending how FFmpeg
actually adds streams. Normally they seem to match though.
Getting subtitle scaling and positioning right even if there are video
filters, which completely change the image (like cropping), doesn't seem
to have a single, correct solution. To some degree, the results are
arbitrary, so we may as well do what is most useful to the user.
In this case, if the PGS resolution aspect ratio and the video output
aspect ratio mismatch, letter-box it, instead of stretching the subs
over the video frame. (This will require additional fixes, should it
turn out that there are PGS subtitles which are stretched by design.)
Fixes#1205.
It assumed that any >\"< sequence was an escape for >"<, but that is not
the case with JSON such as >{"ducks":"\\"}<. In this case, the second
>\< is obviously not starting an escape.
This isn't quite as robust as idet.sh as the default detection
interval is only 4 seconds vs 35 for idet.sh. idet.sh can have such a
large sample time since it turns off the vo and uses --untimed, which
is currently not possible from lua.
It turns out the glibc people are very clever and return an error if the
thread name exceeds the maximum supported kernel length, instead of
truncating the name. So everyone has to hardcode the currently allowed
Linux kernel name length limit, even if it gets extended later.
Also the Lua script filenames could get too long; use the client name
instead.
Another strange thing is that on Linux, unrelated threads "inherit" the
name by the thread they were created. This leads to random thread names,
because there's not necessarily a strong relation between these threads
(e.g. script command leads to filter recreation -> the filter's threads
are tagged with the script's thread name). Unfortunate.
On win32, open() is a function-like macro. The line of code changed
with this commit accidentally expanded the macro. Prevent this macro
expansion. Not sure why that happened now. Since as far as I remember
system functions can be defined as macros, this affects in theory not
only win32.
Especially with other components (libavcodec, OSX stuff), the thread
list can get quite populated. Setting the thread name helps when
debugging.
Since this is not portable, we check the OS variants in waf configure.
old-configure just gets a special-case for glibc, since doing a full
check here would probably be a waste of effort.
Windows doesn't have unix domain sockets, and can't handle sockets and
pipes in an uniform way. Only the libwaio fallback code is available,
which doesn't do JSON.
This is not realy obvious, so I assume this is a helpful hint.
Although the usefulness of such an approach is probably influenced by
the fact that the player might send events that arrive in the short
window while the socket is connected.
The ipc_thread can exit any time, and will free the mp_ipc_ctx when
doing this, leaving a dangling pointer. This was somewhat handled in the
original commit by setting mpctx->ipc_ctx to NULL when the thread
exited, but that was still a race condition.
Handle it by freeing most things after joining the ipc_thread. This
means some resources will not be freed until player exit, but that
should be ok (it's an exceptional error situation).
Also, actually close the pipe FDs in mp_init_ipc() on another error
path.
Thanks to the recently introduced mp_lua_PITA(), this is "simple" now.
It fixes leaks on Lua errors. The hack to avoid stack overflows
manually isn't needed anymore, and the Lua error handler will take
care of this.
The JSON parser was introduced for the IPC protocol, but I guess it's
useful here too.
The motivation for this commit is the same as with 8e4fa5fc (again).
Because 1) Lua is terrible, and 2) popen() is terrible. Unfortunately,
since Unix is also terrible, this turned out more complicated than I
hoped. As a consequence and to avoid that this code has to be maintained
forever, add a disclaimer that any function in Lua's utils module can
disappear any time. The complexity seems a bit ridiculous, especially
for a feature so far removed from actual video playback, so if it turns
out that we don't really need this function, it will be dropped again.
The motivation for this commit is the same as with 8e4fa5fc.
Note that there is an "#ifndef __GLIBC__". The GNU people are very
special people and thought it'd be convenient to actually declare
"environ", even though the POSIX people, which are also very special
people, state that no header declares this and that the user has to
declare this manually. Since the GNU people overtook the Unix world with
their very clever "embrace, extend, extinguish" strategy, but not 100%,
and trying to build without _GNU_SOURCE is hopeless; but since there
might be Unix environments which support _GNU_SOURCE features partially,
this means that in practice "environ" will be randomly declared or not
declared by system headers. Also, gcc was written by very clever people
too, and prints a warning if an external variable is declared twice (I
didn't check, but I suppose redeclaring is legal C, and not even the gcc
people are clever enough to only warn against a definitely not legal C
construct, although sometimes they do this), ...and since we at mpv hate
compiler warnings, we seek to silence them all. Adding a configure test
just for a warning seems too radical, so we special-case this against
__GLIBC__, which is hopefully not defined on other libcs, especially not
libcs which don't implement all aspects of _GNU_SOURCE, and redefine
"environ" on systems even if the headers define it already (because they
support _GNU_SOURCE - as I mentioned before, the clever GNU people wrote
software THAT portable that other libcs just gave up and implemented
parts of _GNU_SOURCE, although probably not all), which means that
compiling mpv will print a warning about "environ" being redefined, but
at least this won't happen on my system, so all is fine. However, should
someone complain about this warning, I will force whoever complained
about this warning to read this ENTIRE commit message, and if possible,
will also force them to eat a printed-out copy of the GNU Manifesto, and
if that is not enough, maybe this person could even be forced to
convince the very clever POSIX people of not doing crap like this:
having the user to manually declare somewhat central symbols - but I
doubt it's possible, because the POSIX people are too far gone and only
care about maintaining compatibility with old versions of AIX and HP-UX.
Oh, also, this code contains some subtle and obvious issues, but writing
about this is not fun.
Using the Lua API is a big PITA because it uses longjmp() error
handling. That is, a Lua API function could any time raise an error and
longjmp() to a lower part of the stack. This kind of "exception
handling" is completely foreign to C, and there are no proper ways to
clean up the "skipped" stack frames.
Other than avoiding such situations entirely, the only way to deal with
this is using Lua "userdata", which is basically a malloc'ed data block
managed by the Lua GC, and which can have a destructor function
associated (__gc metamethod).
This requires an awful lot of code (because the Lua API is just so
terrible), so I avoided this utnil now. But it looks like this will make
some of the following commits much easier, so here we go.
After removing synchronous libdispatch calls, this looks like it doesn't
deadlock anymore. I also experimented with pthread_mutex_trylock liek wm4
suggested, but it leads to some annoying black flickering. I will fallback to
that only if some new deadlocks are discovered.
It's kind of obvious, since the protocol by design has to allow you to
read (loadfile) and write (screenshot_to) random files, but better
make it explicit so that nobody accidentally does something insecure.
As I understand, otherwise, the code will try to destroy the same
window again in the cleanup part of the gui_thread(), which makes no
sense and is potentially dangerous.
mp_stat() instead of stat() was used in the normal code (i.e. even
on Unix), because MinGW-w64 has an unbelievable macro-mess in place,
which prevents solving this elegantly.
Add some dirty workarounds to hide mp_stat() from the normal code
properly. This now requires replacing all functions that use the
struct stat type. This includes fstat, lstat, fstatat, and possibly
others. (mpv currently uses stat and fstat only.)
Now requires newest libass git. Since this feature wasn't part of a
libass release yet, I'm not bothering making the mpv code compatible
with as how it was previously implemented (it will just be disabled
with any older libass).
CC: @mpv-player/stable (because mpv-build uses libass git, and this
breaks the feature)
It possibly goes to sleep without actually starting to decode audio.
Possibly fixes a problem with --no-osc --no-video reported on IRC.
CC: @mpv-player/stable
The previous commit was actually incorrect, and the change had
absolutely no effect. The two formats are (fortunately) the same. I'm
probably too tired.
This would have been wrong for hw decoders which pass us NV12 or NV21.
The format the GL shader filter chain gets is stored in p->image_desc,
while p->image_format still contains the "real" input format (which in
case of hw decoding is an opsque hw accel format). Since no hw decoder
did this, this is really just a theoretical fix and doesn't fix any
actual bugs.
This was probably commented as an oversight. Since the subtitle renderer
was uninitialized on reinitialization anyway, this had no negative
consequences, except a memory on exit.
A vague idea to get something similar what libquvi did.
Undocumented because it might change a lot, or even be removed. To give
an idea what it does, a Lua script could do the following:
-- type ID priority
mp.commandv("hook_add", "on_load", 0, 0)
mp.register_script_message("hook_run", function(param, param2)
-- param is "0", the user-chosen ID from the hook_add command
-- param2 is the magic value that has to be passed to finish
-- the hook
mp.resume_all()
-- do something, maybe set options that are reset on end:
mp.set_property("file-local-options/name", "value")
-- or change the URL that's being opened:
local url = mp.get_property("stream-open-filename")
mp.set_property("stream-open-filename", url .. ".png")
-- let the player (or the next script) continue
mp.commandv("hook_ack", param2)
end)
Normally, we pass libavformat demuxers a wrapped mpv stream. But in some
cases, such as HLS and RTSP, we let libavformat open the stream itself.
In these cases, set typical network properties like useragent according
to the mpv options.
(We still don't set it for the cases where libavformat opens other
streams on its own, e.g. when opening the companion .sub file for .idx
files - not sure if we maybe should always set these options.)
Fixes opening some streams.
This means the HLS playlist will be opened twice, but that's not much of
a problem, considering it's pretty small, and HLS will make many other
http accesses anyway.
OSD cycling attempted to remove the current message by setting an empty
message with duration 0. Duration 0 tripped up a corner case causing no
OSD to be displayed (until the next message was set), so exclude this
explicitly.
Apparently there's an use for this; see #1178.
I won't redocument obscure FFmpeg features, so add a hint to the
manpage that some protocols are documented in FFmpeg instead.
This could produce an extra frame, because reaching the maximum merely
signals the playloop to exit, without strictly enforcing the limit.
Fixes#1181.
CC: @mpv-player/stable
This provides some helper functions and classes for C++/Qt. As the top
of qthelper.hpp says, this is built on top of the client API, and is a
mere helper provided for convenience.
Maybe this should be a separate library, but on the other hand I don't
see much of a point in that. It's also header-only, but C++ people like
such things. This makes it easier for us, because we don't need to care
about ABI compatibility.
The client API doesn't change, but bump it so that those who are using
this header can declare a proper dependency.
Instead of letting the window-scale property return the old value until
X11 actually executed the resize, just set the new assumed internal
window size immediately. This avoids a "lag" between setting and reading
the window-scale property, like OSD controls typically do.
Remove the additional calls from vo_x11_highlevel_resize() - they're
pointless and slightly wrong, and resize events will take care of
updating these things correctly anyway.
Fixes#1176.
("window-scale" works via VOCTRL_[S|G]ET_UNFS_WINDOW_SIZE.)
In theory, vsscript should be doing it, but it's not there yet, neither
did there seem to be any interest in making it flexible enough to handle
more than 1 scripting language.
This allows mpv's view to take key and send events to mpv's core.
To set key status correctly, clients must call -[NSWindow selectNextKeyView:]
during reconfig on the main thread. All is 'documented' in the cocoabasic
example.
If someone knows a better way to handle giving key to the embedded view,
let me know!
Objective-C categories need special linker flags from the user when statically
linking (-ObjC LDFLAG), so make everyone's life simpler and remove them.
Showed "Volume: (unavailable)%". That was dumb.
The message string is now a bit convoluted; mostly because the property
expand syntax can't do "if-else", just "if".
CC: @mpv-player/stable
This does nothing good. This reverts a change made over a year ago - I
don't remember why this was originally done this way.
The main problem is that even if the volume option is set (something
like "--volume=75"), the volume property will always return "100" until
audio is initialized. If audio is uninitialized again, the volume
property will remain frozen at its last value.
This can hang if the window was destroyed externally (or that's what I
suspect happens), and we somehow didn't receive the DestroyNotify event.
I'm not sure why we wouldn't receive this event (since it should just be
in the xlib event queue), but on the other hand there's no real need to
wait for window destruction.
This essentially reverts 97fc74e2.
Some VS filters will requests frames from their parent filters while
they're initialized. Thy do this in a blocking manner, and
initialization will not succeed until the frame request is satisfied.
This deadlocked mpv, because we can feed frames to the filter only after
initialization is finished.
Return an error instead of deadlocking.
Note that we (probably) can handle frames being requested during init
fine, as long as the requests don't block initialization. But we can
distinguish this situation, and a simple test seems to indicate VS
usually doesn't do this.
See #1168.
Allows passing native types as arguments.
Also some minor doc improvements, including giving some (natural)
improvements to mpv_free_node_contents().
Note: mpv_command_node_async() is completely untested.
playlist-pos is 0-based, but everyone thinks it's 1-based. Stupid crap.
(The "not the same as MPlayer" refers to a playlist manipulation command
that doesn't exist anymore in mpv.)
CC: @mpv-player/stable
Manually setting can break things forever, because it puts the VO cursor
state out of sync with the remembered state by handle_cursor_autohide().
Use the normal autohide code during idle mode too instead. (Originally
the idea was to make the cursor always visible in idle mode, but not so
important.)
Regression since e1e8b07c. Fixes#1166.
CC: @mpv-player/stable
While conceptually this sink stuff in PulseAudio does just the right
thing, actually listing the sinks is unbelievable complicated. Not only
is the idea that listing them should happen asynchronously completely
bullshit (who the fuck runs the PulseAudio server on a separate
computer), but the way this is done is full of bullshit too. Why
separate callbacks for each device? Why this obtuse mainloop shit?
Especially the mainloop shit makes it actively worse than doing things
manually with pthread primitives, and the reason for that (different
mainloop implementations for GUIs?) is laughable too. It's like they
chose the most complicated API possible just because they attempted
to "abstract" basic mechanisms in order to handle "everything". While
I don't claim to design the best APIs, this API is fucking terrible
without any excuse. (End of rant.)
All the dumb crap in pa_init_boilerplate() is needed to talk to the
audio server at all. Might also fix some subtle bugs in the init code
(which is strange, because the original file was contributed by the
devil himself).
Seems logical. For some reason, the player allows deselecting both audio
and video stream without quitting (a deliberate feature of which I have
no idea why it was added years ago), so this is needed.
This reverts commit 45c8b97efb.
Some else complained (github issue #1163).
The feature requested in #1148 will be implemented differently in
the following commit.
The one in msg.c was mistakenly removed with commit e99a37f6.
I didn't actually test the change in ao_sndio.c (but obviously "ap"
shouldn't be static).
Don't wait after the audio thread has pushed the remaining audio to the
AO. Avoids hard hangs if the heuristic fails completely (could still
happen if get_delay returns absurd values).
CC: @mpv-player/stable
Since the internal AO driver API has no proper way to determine EOF, we
need to guess by querying get_delay. But some AOs (e.g. ao_pulse with
no-latency-hacks set) may never reach 0, maybe because they naively add
the latency to the buffer level. In this case our heuristic can break.
Fix by always using the delay to estimate the EOF time. It's not even
that important - it's mostly used to avoid blocking draining. So this
should be ok.
CC: @mpv-player/stable (maybe)
The event monitor is used to get keyboard events when there is no window, but
since it is a global monitor to the current process, we don't want it in a
library setting.
After @frau's split of macosx_events from macosx_application, `is_cplayer' is
not needed anymore. At the moment only global events such as Media Keys and
Apple Remote work, because the VO-level ones were hardcoded to be disabled.
(that will be fix in a later commit ).
Worryingly wrong. Fixes#1162.
Also fix another issue (window title was set anyway), which was why I
didn't notice this and testing it seemed to be fine.
Unfortunately, ALSA is particularly bad with this, because mpv has to
add all sorts of magic crap to the device name to make things work. The
device selection overrides this, so explicitly selecting devices will
most likely break your audio. This has yet to be solved.
For cover art, we pretend that the video stream is infinite, but also
stop decoding once we have an image on the VO (this seems advantageous
for the case when strange filters are inserted or the VO image gets
lost). Since a while ago, the video chain started decoding 2 images
though ("Non-monotonic video pts: 0.000000 <= 0.000000"), which is
annoying and wasteful.
Improve this by handling a certain corner case at initialization, which
will decode a second image while the first one is still stuck in the
filter chain. Also, just in case there are filters which buffer a lot,
also force EOF filtering (which means we tell the filters to flush
buffered frames).
CC: @mpv-player/stable
This was added with commit 3cbd79b3, but it turns out this
unintentionally enables "real" pausing when seeking while buffering. It
was done for ensuring correct state of the "cache-buffering-state"
property, but it also turns out that this was unneeded (another variable
that is reset when seeking happens to take care of this).
Maybe using strings for log levels was a mistake (too broad and too
impractical), so I'm adding numeric log level at least for the receiver
side. This makes it easier to map mpv log levels to other logging
systems.
I'm still too stingy to add a function to set the log level by a numeric
value, though.
The numeric values are not directly mapped to the internal mpv values,
because then almost every file in mpv would have to include the client
API header.
Coalesce this into API version 1.6, since 1.6 was bumped just yesterday.
For the purpose of demonstration.
Also make the windows larger. I'm not exactly sure how Qt determines
the default window sizes, but here they are a bit tiny, so force them
larger.
The API could return partial lines, meaning the message could stop
in the middle of a line, and the next message would have the rest of
it (or just the next part of it). This was a pain for the user, so do
the nasty task of buffering the lines ourselves.
Now only complete lines are sent. To make things even easier for the
API user, don't put multiple lines into a single event, but split them.
The terminal output code needed something similar (inserting a prefix
header on start of each line). To avoid code duplication, this commit
refactors the terminal output so that lines are split in a single
place.
The status line is a bit special; for example it uses special control
codes by design and is not terminated with a newline character in order
to update it on the terminal without scrolling. It's not helpful for
client API users either, and would require special-casing them
(emulating aspects of a terminal?). Also, the status line code is
explicitly disabled on osd.c unless the --terminal option is enabled,
so there was no good way to even enable the status line for the API.
Just pretend that the status line does not exist as far as the client
API is concerned. It won't be sent as MPV_EVENT_LOG_MESSAGE.
So client API users don't have to worry about this specifically.
Also document the overflow case. (Not sure if we really need to do
this; maybe it'd be better not to, since this just adds more noise
to the docs.)
stream provides a read buffer (so even something like stream_read_char()
is very fast). This means the stream reads ahead by a few KBs, and
implies that the internal position (s->pos, which would match e.g. the
file position in stream_file.c), and the external position
(stream_tell()) can be different. stream_tell() shows how these are
related.
When dropping buffers, which happens on byte-level discontinuities with
a bunch of streams (including DVB), we should not change the position as
seen by the demuxer. On the other hand, the internal position is not
really meaningful, since these streams aren't seekable anyway. So just
change the code such that stream_drop_buffers() doesn't change the
demuxer visible position.
I'm hoping that this will fix a few problems with DVB. (Also see
previous commit.)
Document the "normal" behavior (if MPV_FORMAT_NONE is not used) first,
and then introduce MPV_FORMAT_NONE as exception.
The actual semantics didn't change in mpv; this is only clarification.
Whether you consider the semantics weird or not depends on your use
case, but I suppose it's a bit confusing anyway. At this point, we keep
MPV_EVENT_PAUSE/UNPAUSE for compatibility only.
Make the "core-idle" property somewhat more useful in this context.
bstr.start can be NULL when bstr.len is 0, so don't call memcmp or
strncasecmp if that's the case. Passing NULL to string functions is
invalid C, even when the length is 0, and it causes Windows to raise an
invalid parameter error.
Should fix#1155
For segment linking (this mechanism matches file extensions to avoid
opening files which are most likely not Matroska files in order to speed
up scanning).
Now any action that stops playback of a file (even playlist navigation)
will save the position. Normal EOF is of course excluded from this, as
well as commands that just reload the current file.
The option name is now slightly off, although you could argue what the
word "quit" means.
Fixes#1148 (or at least this is how I understood it).
This function is available starting with PulseAudio 2.0, while we only
require 1.0. This broke compilation on Ubuntu 12.04.5 LTS.
Use our own function to calculate the buffer size, which is actually
simpler and needs slightly less code.
Hopefully fixes#1154.
CC: @mpv-player/stable
Run opening the stream and opening the demuxer in a separate thread.
This should remove the last code paths in which the player can normally
get blocked on network.
When the stream is opened, the player will still react to input and so
on. Commands to abort opening can also be handled properly, instead of
using some of the old hacks in input.c. The only thing the user can
really do is aborting loading by navigating the playlist or quitting.
Whether playback abort works depends on the stream implementation; with
normal network, this will depend on what libavformat (via "interrupt"
callback) does.
Some pain is caused by DVD/BD/DVB. These want to reload the demuxer
sometimes. DVB wants it in order to discard old, inactive streams.
DVD/BD for the same reason, and also for reloading stream languages
and similar metadata. This means the stream and the demuxer have to
be loaded separately.
One minor detail is that we now need to copy all global options. This
wasn't really needed before, because the options were accessed on
opening only, but since opening is now on a separate thread, this
obviously becomes a necessity.
This is the first of a series of commits that will change the Cocoa way in a
way that is easily embeddable inside parent views. To reach that point common
code must avoid referencing the parent NSWindow since that could be the host
application's window.
This is just temporary code but is a good base for future work (and baby
steps are required for these changes). The 'final destination' is embedding
the video view into any NSView but that requires some more work (the mechanism
will be the same: pass the view's pointer casted to int64_t through -wid).
For instance we will need to remove as much usage of the window instance
as possible, and use nil guards where not possible. For this reason I will
remove stuff like the mission control fullscreen feature (it's a cute feature
but annoying to support and quite limited, go make your GUIs), and a way to
lookup the current screen directly from the NSView absolute coordinates
(this is needed for ICC detection mostly, and reporting back the screen to
mpv's core).
Moreover the current view.m will need to be separated into 2 views: the actual
video view that will be embedded, and a parent view that will not be embedded
and will be responsibile for tracking events.
This could be dangerous because we initialize the window asynchronously and
return immediately from config, but since the OpenGL context is already
created, this seems to work correctly and doesn't cause weird deadlock cases.
This is for users who don't like changes. I'm hoping it will make the
process of cleaning up key bindings less bumpy.
It should be mentioned in the release notes of the next release.
It was more complicated than it had to be: the audio thread already
determines whether audio has ended, so we can use that. Remove the
separate logic for draining.
Commit 957097 attempted to use PA_STREAM_FAIL_ON_SUSPEND to make
ao_pulse exit if the stream was started suspended.
Unfortunately, PA_STREAM_FAIL_ON_SUSPEND is active even during playback.
If you pause mpv, pulseaudio will close the actual audio device after a
while (or something like this), and unpausing won't work. Instead, it
will spam "Entity killed" error messages.
Undo this change and check for suspended audio manually during init.
CC: @mpv-player/stable
This doesn't look to be needed anymore. Fullscreening with both the NSView
and the NSWindow API works correctly. I guess this was forgotten in from older
code which changed presentation options directly for going fullscreen.
--x11-netwm=yes now forces NetWM fullscreen, while --x11-netwm=auto
(detect whether NetWM fullsctreen support is available) is the old
behavior and still the default.
See #888.
Unfortunately using dispatch_sync for synchronization turned out to be really
bad for us. It caused a wide array of race conditions, deadlocks, etc.
Moving to a very simple mutex. It's not clear to me how to do liveresizing
with this, for now it just flickers with is unacceptable (maybe I'll draw
black instead).
This should fix all the threading cocoa bugs. Reopen if it's not the case!
Fixes#751Fixes#1129
Also recreate ASS_Library on every file played. This means we can move
the code out of main.c as well.
Recreating the ASS_Library object has no disadvantages, because it
literally stores only the message callback, the (per-file) font
attachment as byte arrays, and the set of style overrides. Hopefully
this thing can be removed from the libass API entirely at some point.
The only reason why the player core creates the ASS_Renderer, instead
of the subtitle renderer, is because we want to cache the loaded fonts
across ordered chapter transitions, so this probably still has to stay
around for now.
When the VO was moved it its own thread, responsibility for redrawing
was given to the VO thread itself. So if there was a condition that
indicated that redrawing was required, like expose events or certain
VOCTRLs, the VO thread was redrawing itself.
This worked fine, but there are some corner cases where this works
rather badly. E.g. if I fullscreen the player and hit panscan controls
with mpv's default autorepeat rate, playback stops. This happens because
the VO redraws itself after every panscan change command. Running each
(repeated) command takes so long due to redrawing and (involuntary)
waiting on vsync, that it never leaves the input processing loop while
the key is held down. I suspect that in my case, redrawing in fullscreen
mode just gets slow enough that it takes 2 vsyncs instead of 1 on
average, and the processing time gets larger than the autorepeat delay.
Fix this by taking redraw control from the VO, and instead let the
playloop issue a "real" redraw command to the VO if needed. This
basically reverts redraw handling to what it was before moving the VO to
a thread.
CC: @mpv-player/stable
Each subsystem (or similar thing) had an INITIALIZED_ flag assigned. The
main use of this was that you could pass a bitmask of these flags to
uninit_player(). Except in some situations where you wanted to
uninitialize nearly everything, this wasn't really useful. Moreover, it
was quite annoying that subsystems had most of the code in a specific
file, but the uninit code in loadfile.c (because that's where
uninit_player() was implemented).
Simplify all this. Remove the flags; e.g. instead of testing for the
INITIALIZED_AO flag, test whether mpctx->ao is set. Move uninit code
to separate functions, e.g. uninit_audio_out().
Sometimes, ao_pulse starts in suspended mode, which means playback is
essentially paused in pulseaudio. This gives the impression that mpv is
hanging, since it times video against the audio playback progress, and
audio never makes progress in this state.
I'm not sure if this will help - possibly it does with mixed
pulseaudio/alsa setups. However, if the alsa setup has the pulseaudio
plugin, alsa will hang too. But there's still a chance we get less
blame for pulseaudio messes.
This gets rid of this warning:
Could not update timestamps for skipped samples.
This required an API addition to FFmpeg (otherwise it would instead
doing arithmetic on the timestamps itself), so whether it works depends
on the FFmpeg version.
For the sake of libmpv. Might make things much easier for the user,
especially on Windows. On the other hand, it's a bit sketchy that a
command exists that makes the player access arbitrary memory regions.
(But do note that input commands are not meant to be "secure" and never
were - for example, there's the "run" command, which obviously allows
running random shell commands.)
Somewhat more flexible: now there's a separate overlay struct, and you
don't need to coerce all state into struct sub_bitmap. Also, removing
the previous mapping (munmap call) is now all in one place, the
replace_overlay function.
Makes the next commit easier to implement.
Use percent-pos instead, which is exactly the same, except with the
range 0.0-100.0.
I'm not sure how this got there; it was probably introduced and then
removed again as percent-pos got more precise.
CC: @mpv-player/stable
Another fallout resulting from the changes whether or not to wait for
mapping the window. In this case, it obviously makes no sense to wait
for mapping, because the root window is always mapped. Mapping will
never happen, and it would wait forever.
Fixes#1139.
CC: @mpv-player/stable
The messages "Audio: no audio" and "Video: no video" could be printed
twice each if initializing them failed. Prevent his silliness.
CC: @mpv-player/stable
Apparently this is what users want. When playing with normal speed,
nothing is done. When playing slower than normal, resampling is used
instead, because scaletempo (which does the pitch correction) adds
too many artifacts.
Although the "af" command already could do this, it seems it's better
to introduce a lower level mechanism for now. This avoids some messy
issues, since that code would recursive call reinit_audio_chain().
To be used by the next commit.
There's no real reason why audio_init_filter() should exist. Just use
af_init or af_reinit directly. (We lose a useless message; the same
information is printed in a quite close place with more details.)
Requires less code, and the way the filter chain is marked as having
failed to initialize allows just switching off audio instead of
crashing if trying to insert a volume filter in mixer.c fails, and
recreating the old filter chain fails too.
Simple fix for issue #1137.
Since all sub-bitmaps are packed on a larger texture, there's still a
"fall off" on the border due to the linear scaling. This could be
fixed by constraining each sub-bitmap to its own texture, or by
clamping on the shader level, but I don't care for now.
At least on kwin, we decide to proceed without waiting for the window
being mapped (due to the frame exts hack, see commit 8c002b79). But that
leaves us with a window size of 0x0, which causes VdpOutputSurfaceCreate
to fail. This prints some warnings, although vo_vdpau recovers later and
this has no other bad consequences.
Do the following things to deal with this:
- set the "known" window size to the suggested window size before the
window is even created
- allow calling XGetGeometry on the window even if the window is not
mapped yet (this should work just fine)
- make the output surface minimum size 1x1
Strictly speaking, only one of these would be required to make the
warning disappear, but they're all valid changes and increase robustness
and correctness. At no point we use a window size of 0x0 as magic value
for "unset" or unknown size, so keeping it unset has no purpose anyway.
CC: @mpv-player/stable
Commit 50e131b43e happened to make it work for DVD (because the higher
bits of the ID are masked in the DVD case), but failed for Bluray. This
probably fixes it, although I don't have a sample to multiple streams to
confirm it really does it right.
CC: @mpv-player/stable
2014-09-30 23:38:01 +02:00
419 changed files with 27906 additions and 21327 deletions
float*out=outframe->planes[0];// Output audio data
float*end=in+data->samples*data->nch;
inti=s->i;// Filter queue index
intri=s->ri;// Read index for delay queue
intwi=s->wi;// Write index for delay queue
mp_audio_realloc_min(af->data,data->samples);
out=af->data->planes[0];
while(in<end){
/* Dominance:
abs(in[0])abs(in[1]);
@@ -215,16 +221,14 @@ static int filter(struct af_instance* af, struct mp_audio* data, int flags){
// Save indexes
s->i=i;s->ri=ri;s->wi=wi;
// Set output data
data->planes[0]=af->data->planes[0];
mp_audio_set_channels_old(data,af->data->nch);
talloc_free(data);
af_add_output_frame(af,outframe);
return0;
}
staticintaf_open(structaf_instance*af){
af->control=control;
af->filter=filter;
af->filter_frame=filter_frame;
returnAF_OK;
}
Loaded 100 of 419 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.