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
This would play some silence in case video was slower than audio. If
framedropping is already enabled, there's no other way to keep A/V
sync, short of changing audio playback speed (which would give worse
results). The --audiodrop option inserted silence if there was more
than 500ms desync.
This worked somewhat, but I think it was a silly idea after all. Whether
the playback experience is really bad or slightly worse doesn't really
matter. There also was a subtle bug with PTS handling, that apparently
caused A/V desync anyway at ridiculous playback speeds.
Just remove this feature; nobody is going to use it anyway.
When embedding, if the parent window is destroyed, it will cause mpv's
window to be destroyed as well. Since WM_USER wakeups are sent to the
window, destroying the window will prevent wakeups and cause uninit to
hang.
Fix this by quitting the event loop on WM_DESTROY. Events should only be
processed for the lifetime of the window, from CreateWindowEx to
WM_DESTROY. After the event loop is finished, mp_dispatch_queue_process
can handle any remaining requests.
Might matter when libavformat tries to do tiny seekbacks in an
unseekable stream, and the seekback buffer isn't large enough. In this
case, seeking would fail, and would drop the current buffer. The
seekback would end up dropping future data.
This change probably doesn't have any observable effects. libavformat
normally has its own stream buffer, and demux_mkv.c tries carefully
never to seek back.
This makes no sense to use with DVD/BD/DVB and some others, and these
streams happen to be unseekable.
Also, other kinds of unseekable streams (like reading from pipe) should
work, but will exhibit sketchy behavior if they need to seek. So just
disable it, and leave these problems to the memory cache (cache.c).
This code meant to flush demuxer internal buffers by doing a byte seek
to the current position. In theory this shouldn't drop any stream data.
However, if the stream positions mismatch, then avio_seek() (called by
av_seek_frame()) stops being a no-op, and might for example read some
data to skip to the seek target. (This can happen if the distance is
less than SHORT_SEEK_THRESHOLD.)
The positions get out of sync because we drop data at one point (which
is what we _want_ to do). Strictly speaking, the AVIOContext flushing is
done incorrectly, becuase pb->pos points to the start of the buffer, not
the current position. So we have to increment pb->pos by the buffered
amount.
Since there are other weird reasons why the positions might go out of
sync (such as stream_dvd.c dropping buffers itself), and they don't
necessarily need to be in sync in the first place unless AVIOContext has
nothing buffered internally, just use the sledgehammer approach and
correct the position manually.
Also run av_seek_frame() after this. Currently, it shouldn't read
anything, but who knows how that might change with future libavformat
development.
This whole change didn't have any observable effect for me, but I'm
hoping it fixes a reported problem.
When flushing the AVIOContext, make sure it can't seek back to discarded
data. buf_ptr is just the current read position, while buf_end - buffer
is the actual buffer size. Since mpegts.c is littered with seek calls,
it might be that the ability to seek could read
Mark the stream (which the demuxer uses) as not seekable. The cache can
enable seeking again (this behavior is sometimes useful for other
things). I think this should have had no bad influence in theory, since
seeking BD/DVD first does the "real" seek, then flushes libavformat and
reads new packets.
The intention was to adjust the window size to video size. It never
worked well; it prevented the user to make the window smaller. For
unknown reason it stopped resizing properly as well.
This is just a cheap example, and I don't intend to fight with Qt, so
replace the "demonstration" behavior by something slightly lamer.
Commit 64b7811c tried to do the "right thing" with respect to whether
keyboard input should be enabled or not. It turns out that X11 does
something stupid by design. All modern toolkits work around this native
X11 behavior, but embedding breaks these workarounds.
The only way to handle this correctly is the XEmbed protocol. It needs
to be supported by the toolkit, and probably also some mpv support. But
Qt has inconsistent support for it. In Qt 4, a X11 specific embedding
widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently
supports it via QWindow, but if it really does, I couldn't get it to
work.
So add a hack instead. The new --input-x11-keyboard option controls
whether mpv should enable keyboard input on the X11 window or not. In
the command line player, it's enabled by default, but in libmpv it's
disabled.
This hack has the same problem as all previous embedding had: move the
mouse outside of the window, and you don't get keyboard input anymore.
Likewise, mpv will steal all keyboard input from the parent application
as long as the mouse is inside of the mpv window.
Also see issue #1090.
We inserted these filters with fixed parameters, which was ok. But this
also didn't change image parameters for the filters down the filter
chain and the VO. For example, if rotation by 90° was requested by the
file, we would insert a filter and rotate the video, but the VO would
still receive image parameters that direct rotation by 90°.
This wasn't a problem, but it could become one.
Fix this by letting the filters automatically pick up the image params.
The image params are reset on application. (We could probably also
always try to apply and reset image params in a filter, instead of
having special "auto" parameters. This would probably work, and video.c
would insert a "rotate=0" filter. But I'm afraid this would be confusing
and the current solution is cosmetically slightly nicer.)
Unfortunately, the vf_stereo3d.c change turned out a big mess, but once
the "internal" filter is fully replaced with libavfilter, most of this
can be radically simplified.
Some filters exists only to create a specific lavfi graph. Allow these
filters to reset the graph exactly on reconfig, and allow them to modify
some image parameters too. Also make vf_lw_update_graph() behave like
vf_lw_set_graph() - they had a subtitle difference with filter==NULL.
Useful for the following commit.
Originally, all options were copied to ensure that input_ctx remins
thread-safe, even if options are changed asynchronously. But this got
a bit inconsistent. Copy them automatically and reduce some weirdness.
Until now, creating the input_ctx was delayed until the command line
and config files were parsed. Separate creation and loading so that
input_ctx is available from start.
This should make it possible to simplify some things. For example,
some complications with Cocoa were apparently only because input_ctx
was available only "later". (Although I'm not sure if this is still
relevant, or if the Cocoa code should even be organized this way.)
libsndio has absolutely no mechanism to discard already written audio
(other than SIGKILLing the sound server). sio_stop() will always block
until all audio is played. This is a legitimate design bug.
In theory, we could just not stop it at all, so if the player is e.g.
paused, the remaining audio would be played. When resuming, we would
have to do something to ensure get_delay() returns the right value. But
I couldn't get it to work in all cases.
get_delay needs to report the current audio buffer status. It's
important for A/V sync that this information is current, but functions
which update it were called on play() or get_space() calls only.
This was in bytes, but it's more convenient to use samples (or frames;
in any case the smallest unit of audio that includes all channels).
Remove the ao->bps line too; it will be set after init() returns.
This warning makes absolutely no sense. Passing an empty string to
printf-like functions is perfectly fine. In the OSD case, it just sets
an empty message, practically clearing the OSD.
Makes it behave slightly better for VP9. This is also the behavior
libavformat has.
Also while we're at it, don't set duration except for the first packet.
Normally we don't use the duration except for subtitles (which are never
parsed or "laced"), so this should make no observable difference.
Similar as the previous commits.
Most of the code is actually copied from the stream_dvdnav.c code, but
I'd rather prefer to duplicate it, than to entangle them. The latter
would probably result in terrible things in a few years.
Same hack as with stream_dvd.c.
VIDEO_TS.IFO files are now opened via stream_dvdnav.c. Directories
containing a VIDEO_TS.IFO or VIDEO_TS/VIDEO_TS.IFO file are also
opened with it.
stream_dvd.c includes a pseudo-protocol that recognizes .IFO files, and
plays them using libdvdread. This was relatively lazy, and could perhaps
easily trigger with files that just had the .ifo extension.
Make the checks stricter, and even probe the file header. Apparently the
first bytes in an .ifo file are always "DVDVIDEO-VTS", so check for
this.
Refuse to load the main "video_ts.ifo". The plan is to use stream_dvdnav
for it.
This also removes at least 1 memory leak.
set_osd_bar_chapters() always cleared the OSD bar stops, even if the
current bar was not the seek bar. Obviously it should leave the state of
the bar alone in this case.
Also change the function control flow so that we can drop one
indentation level, and do the equivalent change for the other OSD bar
functions.
Eliminate the remains of the OSD message stack. Another simplification
comes from the fact that we do not need to care about time going
backwards (we always use a monotonic time source, and wrapping time
values are practically impossible). What this code was pretty trivial,
and by now unnecessarily roundabout.
Merge get_osd_msg() into update_osd_msg(), and add_osd_msg() into
set_osd_msg_va().
There's no need to update OSD messages and the terminal status if nobody
is going to see it. Since the player doesn't block on video display
anymore, this update happens to often and probably burns slightly more
CPU than necessary. (OSD redrawing is handled separately, so it's just
mostly useless text processing and such.)
Change it so that it's updated only on every video frame or all 50ms
(whatever comes first).
For VO OSD, we could in theory try to lock to the OSD redraw heuristic
or the display refresh rate, but that's more complicated and doesn't
work for the terminal status.
When using --force-window (and no video or cover art), this heuristic
prevents any redrawing during seeking. It should be applied only if
there is any form of video.
This makes subtitle display somewhat work if no video is displayed, but
a VO window exists (--force-window or cover art display).
The main problem with normal subtitle display is that it's locked to
video: it uses the video PTS as reference, and the subtitles advance
only if a new video frame is displayed. In audio-only mode on the other
hand, no video frame is ever displayed (or only 1 in the cover art
case). You would need a workaround to adjust the subtitle PTS, and you
would have to decide with what frequency to update the display. In
general, there is no "right" display FPS for subtitles. Some formats
(ASS) have animations parameterized by time, and any refresh rate could
be used.
Sidestep these problems by enabling the text OSD-based subtitle
mechanism. This is similar to --no-sub-ass, and updates and renders
subtitles with plain OSD. It has some caveats: no bitmap subs, somewhat
incorrect timing, no formatting. Timing in particular is a bit strange
and depends how often the audio output asks for new data, or other
events that happen to wakeup the playloop.
This was once central, but now it's almost unused. Only vf_divtc still
uses it for extremely weird and incomprehensible reasons. The use in
stream.c is trivial. Replace these, and remove mpbswap.h.
stream_cdda's output format is linked to demux_raw's default audio
format, and at least we don't care enough to provide a separate
mechanism to let stream_cdda explicitly set the format, so they must
match.
Judging from the existing code, it looks like CDDA always outputs little
endian. stream_cdda.c changed this back to native endian (what demux_raw
expects). Just make them both little endian. This requires less code,
and also having a raw demuxer's behavior depend on the endianness of the
machine isn't very sane anyway.
See previous commits. This finally replaces directly reading the file
data into a struct with reading them manually. In theory this is more
portable (no alignment issues and other things). For the most part,
it's nice seeing this gone.
MPlayer traditionally did this because it made sense: the most important
formats (avi, asf/wmv) used Microsoft formats, and many important
decoders (win32 binary codecs) also did. But the world has changed, and
I've always wanted to get rid of this thing from the codebase.
demux_mkv.c internally still uses it, because, guess what, Matroska has
a VfW muxing mode, which uses these data structures natively.
Let codec_tags.c do the messy mapping.
In theory we could simplify further by makign demux_mkv.c directly use
codec names instead of the MPlayer-inherited "internal FourCC" business,
but I'd rather not touch this - it would just break things.
For a while, we used this to transfer PCM from demuxer to the filter
chain. We had a special "codec" that mapped what MPlayer used to do
(MPlayer passes the AF sample format over an extra field to ad_pcm,
which specially interprets it).
Do this by providing a mp_set_pcm_codec() function, which describes a
sample format in a generic way, and sets the appropriate demuxer header
fields so that libavcodec interprets it correctly. We use the fact that
libavcodec has separate PCM decoders for each format. These are
systematically named, so we can easily map them.
This has the advantage that we can change the audio filter chain as we
like, without losing features from the "rawaudio" demuxer. In fact, this
commit also gets rid of the audio filter chain formats completely.
Instead have an explicit list of PCM formats. (We could even just have
the user pass libavcodec PCM decoder names directly, but that would be
annoying in other ways.)
Digital pass-through was probably broken. Possibly fix it (no way to
test). This also should make the logic slightly saner.
Fortunately, it's unlikely that anyone who uses OSS has a spdif setup.
Commit 5b5a3d0c broke this. The really funny thing is that this code was
actually always under "#if BYTE_ORDER == BIG_ENDIAN". The breaking
commit just edited this code slightly, but it must have failed to
compile on big endian long before (since over 1 year ago, commit d3fb58).
Should be able to pass-through AC3, DTS, and others.
It seems PulseAudio wants players to fallback to PCM on certain events
signaled by the server, but we don't implement that. There's not much
documentation available anyway.
Before this commit, there was AF_FORMAT_AC3 (the original spdif format,
used for AC3 and DTS core), and AF_FORMAT_IEC61937 (used for AC3, DTS
and DTS-HD), which was handled as some sort of superset for
AF_FORMAT_AC3. There also was AF_FORMAT_MPEG2, which used
IEC61937-framing, but still was handled as something "separate".
Technically, all of them are pretty similar, but may use different
bitrates. Since digital passthrough pretends to be PCM (just with
special headers that wrap digital packets), this is easily detectable by
the higher samplerate or higher number of channels, so I don't know why
you'd need a separate "class" of sample formats (AF_FORMAT_AC3 vs.
AF_FORMAT_IEC61937) to distinguish them. Actually, this whole thing is
just a mess.
Simplify this by handling all these formats the same way.
AF_FORMAT_IS_IEC61937() now returns 1 for all spdif formats (even MP3).
All AOs just accept all spdif formats now - whether that works or not is
not really clear (seems inconsistent due to earlier attempts to make
DTS-HD work). But on the other hand, enabling spdif requires manual user
interaction, so it doesn't matter much if initialization fails in
slightly less graceful ways if it can't work at all.
At a later point, we will support passthrough with ao_pulse. It seems
the PulseAudio API wants to know the codec type (or maybe not - feeding
it DTS while telling it it's AC3 works), add separate formats for each
codecs. While this reminds of the earlier chaos, it's stricter, and most
code just uses AF_FORMAT_IS_IEC61937().
Also, modify AF_FORMAT_TYPE_MASK (renamed from AF_FORMAT_POINT_MASK) to
include special formats, so that it always describes the fundamental
sample format type. This also ensures valid AF formats are never 0 (this
was probably broken in one of the earlier commits from today).
This code tried to play with the format bits, and potentially could
create invalid formats, or reinterpret obscure formats in unexpected
ways.
Also there was an abort() call if the winapi or mpv used a format with
unexpected bit-width. This could probably easily happen; for example,
mpv supports at least one 64 bit format. And what would happen on 8 bit
formats anyway?
Untested.
Until now, the audio chain could handle both little endian and big
endian formats. This actually doesn't make much sense, since the audio
API and the HW will most likely prefer native formats. Or at the very
least, it should be trivial for audio drivers to do the byte swapping
themselves.
From now on, the audio chain contains native-endian formats only. All
AOs and some filters are adjusted. af_convertsignendian.c is now wrongly
named, but the filter name is adjusted. In some cases, the audio
infrastructure was reused on the demuxer side, but that is relatively
easy to rectify.
This is a quite intrusive and radical change. It's possible that it will
break some things (especially if they're obscure or not Linux), so watch
out for regressions. It's probably still better to do it the bulldozer
way, since slow transition and researching foreign platforms would take
a lot of time and effort.
IEC 61937 frames should always be little endian (little endian 16 bit
words). I don't see any apparent need why the audio chain should handle
swapped-endian formats.
It could be that some audio outputs might want them (especially on big
endian architectures). On the other hand, it's not clear how that works
on these architectures, and it's not even known whether the current code
works on big endian at all. If something should break, and it should
turn out that swapped-endian spdif is needed on any platform/AO,
swapping still could be done in-place within the affected AO, and
there's no need for the additional complexity in the rest of the player.
Note that af_lavcac3enc outputs big endian spdif frames for unknown
reasons. Normally, the resulting data is just pulled through an auto-
inserted conversion filter and turned into little endian. Maybe this was
done as a trick so that the code didn't have to byte-swap the actual
audio frame. In any case, just make it output little endian frames.
All of this is untested, because I have no receiver hardware.
Until now, we always required the playback core to decode a new frame to
get more output from the filter. That seems to be completely
unnecessary, because filtered results may arrive before that.
Add a filter_out callback, and restructure the code such that it can
return any filtered frames, or block if it hasn't read at least one
frame.
In the worst case, it still can happen that bursts of input requests and
output requests happen. (This commit tries to reduce burst-like
behavior, but it's not entirely possible due to the indeterministic
nature of VS threading.)
This is a similar change as with 95bb0bb6.
E.g. --loop-file=2 will play the file 3 times (one time normally, and 2
repeats).
Minor syntax issue: "--loop-file 5" won't work, you have to use
"--loop-file=5". This is because "--loop-file" still has to work for
compatibility, so the "old" syntax with a space between option name and
value can't work.
libavcodec/libavformat now handles gapless audio better. In theory, this
could be implemented with ad_mpg123 too, but since libavformat strips
metadata from mp3 files and passes pure mp3 packets to the decoders
only, this can't work by itself. Instead, the player must pass this
metadata separately. libav* do this relatively transparently over packet
"side data" (attached to AVPacket).
It might also be possible to let libmpg123 handles all this by
implementing it as demuxer that outputs PCM, but that would have other
problems, and I think it's better to make libavformat work correctly.
libmpg123 can still be used with '--ad=mpg123:mp3'.
Also see issue #1101.
We generally want 2 things:
1. minimal wakeups for decoding each frame
2. minimal number of frames decoded on continuous seeking
Commit 35810cb8 changed this a bit, and fixed 1. But it broke 2., and
now it decodes 2 frames instead of 1 when you keep seeking (arrow key
held down or such). This made seeking appear slower.
Fix this by making the logic more explicit. In particular, call the
filters only if we actually try to get a new frame.
When playing with --no-audio and all other distractions disabled (like
OSC), it still wakes up 2 times per frame - but the second time is
merely because the VO didn't accept the new frame yet.
Be less annoying, print the actual OSD level instead of something
meaningless, but still clear the OSD if OSD level 0 (no OSD) is set.
Remove the special handling for terminal OSD, that was just dumb.
This means that if a property not listed in property_osd_display[] is
changed, it will be shown on the OSD as "name: ${name}".
Properties that are listed in property_osd_display[] and have osd_name
not set stay invisible by default. This is used for "pause" and
"fullscreen", which (like before this commit) are not shown by default,
because it would be annoying.
The defaults still can be changed with command prefixes (osd-msg,
no-osd, others).
Probably not many user-visible changes. One notable change is that the
terminal OSD code for OSD bar fallback handling is removed with no
replacement. Instead, terminal OSD gets the same text message as normal
OSD. For volume, this is ok, because the text message is reasonable.
Other properties will look worse, but could be adjusted, and there are
in fact no other such properties that would be useful in audio-only
mode.
The fallback message for seeking falls away as well, but that message
was useless anyway - the terminal status line provides all information
anyway.
I believe the show_property_osd() code is now much easier to follow.
If no VO was open, these options couldn't be changed or even queried.
Although these properties are nearly useless if no VO exists, there's
actually no good reason to forbid querying or setting them. Also, even
if the VO is created, it doesn't mean the VO window was created.
Why bother?
Also, since now some properties could be mapped to non-existing options,
but mp_property_generic_option() is used, deal with this case and return
a not-found error code.
If there's a command that uses the OSD by default, then always print the
associated message (or a fallback made of name + value), even if the
command has an associated OSD bar.
This means volume, gamma, panscan, etc. all show both a message and a
OSD bar.
Also, add a '%' to the volume message. The extra_msg thing is not needed
anymore.
See issue #1103.
It's just confusing; users are encouraged to edit input.conf instead
(changing the argument to the "add" command).
Update input.conf to keep the old behavior.
When pausing after a frame was just dropped, we're logically at the
dropped frame, and thus should redraw the dropped frame. This was
implemented, but didn't work after unpausing for the second time,
because of a minor logic bug.
For incomprehensible reasons, AV_PIX_FMT_GRAY8 (and some others) have a
palette. This literally makes no sense and this issue has bitten us
before, but it is how it is.
This also caused a crash with vo_direct3d: this mapped a texture as
IMGFMT_Y8 (i.e. AV_PIX_FMT_GRAY8), and when copying this, it tried to
copy the non-existent palette.
Fixes#1113.
vo_vdpau uses its own framedrop code, mostly for historic reasons. It
has some tricky heuristics, of which I'm not sure how they work, or if
they have any effect at all, but in any case, I want to keep this code
for now. One day it might get fully ported to the vo.c framedrop code,
or just removed.
But improve its interaction with the user-visible framedrop controls.
Make --framedrop actually enable and disable the vo_vdpau framedrop
code, and increment the number of dropped frames correctly.
The code path for other VOs should be equivalent. The vo_vdpau behavior
should, except for the improvements mentioned above, be mostly
equivalent as well. One minor change is that frames "shown" during
preemption are always count as dropped.
Remove the statement from the manpage that vo_vdpau is the default; this
hasn't been the case for a while.
vc->vsync_interval and vsync_interval should be the same value, but
actually vc->vsync_interval was updated after vsync_interval was
initialized. This was probably not intended. Fix this by removing the
duplicate local variable. There were probably no bad effects.
When compiling semaphore_osx.c on win32, the following error happened:
/usr/i686-w64-mingw32/include/semaphore.h:160:6: error: unknown type name 'mode_t'
This is because this system header references symbols that are not
not defined anywhere. This is clearly a bug in pthreads-w32, but has
been known and unfixed since 2012, so add a hack to fix it.
We build semaphore_osx.c this way because it saves us an extra configure
check. On win32, Linux, etc. it's empty and contains
"#include <semaphore.h>" only.
Should fix#1108.
Be less clever, and restore the volume state even with AOs like pulse,
which have per-application audio.
Before this commit we didn't do this, because the volume is global (even
if per-application), so the volume will persist between invocations. But
to me it looks like always restoring is less tricky and makes for easier
to understand semantics.
Also, don't always unmute on exit. Unmuting was done even with ao_pulse,
and interfered with user expectations (see #1107).
This might annoy some users, because mpv will change the volume all the
time. We will see.
Fixes#1107.
Follow up to previous commit.
This is probably confusing from a user point of view, since this field
shouldn't show up normally anymore. (Before this commit, it could show
up sporadically when a slow operation was performed during playback,
such as switching fullscreen.)
Normally, feeding a packet to the decoder should always return a frame
_if_ we received a frame before. So while we can't know exactly whether
a frame was dropped, at least the normal case is easily detectable.
This means we display something closer to the actual framedrop count,
instead of a bad guess.
This is the "old" framedropping mode (derived from MPlayer). At least in
the mplayer2/mpv source base, it stopped working properly years ago (or
maybe it never worked properly). For one, it depends on the video
framerate, which assume constant framerate. Another problem was that it
could lead to freezing video display: video could get so much behind
that it couldn't recover from framedrop.
Make some small changes to improve this.
Don't use the current audio position to check how much we are behind.
Instead, use the last known A/V difference. last_av_difference is
updated only when a video frame is scheduled for display. This means we
can keep stop dropping once we're done catching up, even if video is
technically still behind. What helps us here that this forces a video
frame to be displayed after a while. Likewise, we reset the
dropped_frames count only when scheduling a new frame for display as
well.
Some inspiration was taken from earlier work by xnor (see issue #620),
although the implementation turned out quite different.
This still uses the demuxer-reported (possibly broken) FPS value. It
also doesn't account for filters changing FPS. We can't do much about
this, because without decoding _and_ filtering, we just can't know how
long a frame is. In theory, you could derive that from the raw packet
timestamps and the filter chain contents, but actually doing this is
too involved. Fortunately, the main thing the FPS affects is actually
the displayed framedrop count.
Sometimes, --af=hrtf produces heavy artifacts or silence. It's possible
that this commit fixes these issues. My theory is that usually, the
uninitialized coefficients quickly converge to sane values as more audio
is filtered, which would explain why there are often artifacts on init,
with normal playback after that. It's also possible that sometimes, the
uninitialized values were NaN or inf, so that the artifacts (or silence)
would never go away.
Fix this by initializing the coefficients to 0. I'm not sure if this is
correct, but certainly better than before.
See issue #1104.
Let us set a different rate and delay.
Needed for the following commit where we set rate and delay reported by weston.
But only if the option native-keyrepeat is set.
Uses the new mechanism introduced in the previous commit.
Depending on the actual filter, this distributes CPU load more evenly
over time, although it probably doesn't matter.
Consider a filter which turns 1 frame into 2 frames (such as an
deinterlacer). Until now, we forced filters to produce all output frames
at once. This was done for simplicity.
Change the filter API such that a filter can produce frames
incrementally.
Rename video_decode_and_filter to video_filter, and add a new
video_decode_and_filter function. This function now calls the decoder.
This is done so that we can check filters a second time after decoding,
which avoids a useless playloop iteration.
(This and the previous commits are really just microoptimizations, which
simply reduce the number of times the playloop has to recheck
everything.)
Move the check to a function. Run the check a second time after
decoding/filtering. This second check is strictly speaking redundant
(which is why it wasn't done until now), but it avoids a useless
playloop iteration.
Move this code below the code that "shifts" the newly filtered frame.
This allows us to skip a useless playloop iteration later, because
obviously we need to filter a new frame after the previous frame has
been "shifted", and not before that.
Until now, you could override only level 3 with --osd-status-msg. Extend
this, add add --osd-msg1 to --osd-msg3 (one for each OSD level). OSD
level 0 always means disable OSD, so that isn't included.
--osd-msg3 corresponds to --osd-status-msg, but they're not exactly the
same. To allow more customization, --osd-msgN do not include the OSD
symbol. The symbol can be manually added with "${osd-sym-cc}". We keep
the "old" option for some short-term compatibility.
--osd-msg1 should be particularly useful; for example you could do:
--osd-msg1='${?pause==yes:${osd-sym-cc}}'
to display a "paused" symbol when paused, and nothing during normal
playback. (Although admittedly, the syntax is quite a bit of work.)
We don't allow this by default, because it would be silly if random
external data (like filenames or file tags) could accidentally trigger
them.
Add a property that magically disables this ASS tag escaping.
Note that malicious input could still disable ASS tag escaping by
itself. This would be annoying but harmless.
Pausing/unpausing while the audio device can't be reopened, and then
unpausing again when the device is finally reopened, can hang the
player for a while.
This happens because p->prepause_samples grows without bounds each
time the player is unpaused while the device is lost. On unpause,
ao_oss plays prepause_samples of silence to compensate for A/V timing
issues due to the partially lost buffer (we can't pause the device at
an arbitrary sample position, and the current period will be lost).
This in turn will make the player appear to be frozen if too much
audio is queued. (Normally, play() must never block, but here it
happens because more data is written than get_space() reports. A
better implementation would never let prepause_samples grow larger
than the period size.)
The unbounded growth happens because get_space() always returns that
the device can be written while the device is lost. So limit it to
200ms. (A better implementation would limit it to the period size.)
Also see #1080.
There's no reason to let the core wait until the frame is done
displaying. In practice, the core normally didn't need this additional
wakeup, and the VO was quick enough to fetch the new frame, before the
core even attempted to queue a new frame. But it wasn't entirely clean,
and the correct wakeup handling might matter in some cases.
With default settings, this allows you to hit the 100% mark (with
default --softvol-max in the middle) even if you've reached min or max
volume before. This is because 50 is not divisible by 3 (old default)
but by 2 (new default).
Not really sure why there still can be issues with higher --softvol-max
and --volstep=1, but this is where I stop caring.
If --write-filename-in-watch-later-config is used, and the filename
contains newline characters (as generally allowed on Unix), then the
newline will be written to the resume file literally, and the parts
after the newline character are interpreted as options.
This is possibly security relevant.
Change newline characters (and in fact any other special characters)
to '_'.
Reported as #1099 (this commit is a reimplementation of the proposed
pull request).
CC: @mpv-player/stable
Apparently making ESC exit fullscreen mode is the more popular
convention compared to ESC quitting the program.
It was also concluded that ESC should do nothing when the windows is
already in normal state.
See discussion in #973.
The filter output size can be 0. Due to how filtering works, this is
nothing unusual, but avresample_convert() will return 0. The same case
is already handling with "normal" resampling (this commit fixes the
reordering code).
Additionally, don't use an assert(). avresample_convert() failing is
unusual, but might also happen due to e.g. internal out of memory
conditions, so we shouldn't just crash on it.
Curiously observed with --ao=oss --audio-channels=5.1 when changing
speed.
Apparently NetBSD users want/need this (see issue #1080).
In order not to break playback, we need at least to emulate get_delay().
We do this approximately by using the system clock.
Also, always close the audio device on reset. Reopen it on play only. If
we can't reopen it, don't retry until after the next time reset or
resume is called, to avoid spam and unexpectedly "stealing" back the
audio device.
Also do something about framestepping causing audio desync.
The context struct had an audio_buf_info field, but there's no reason
why this would be needed. It's a tiny struct, and it isn't permanent
state. It's always returned by SNDCTL_DSP_GETOSPACE. Keeping this as
field is just confusing, so get rid of it.
The code for reopening the audio device was separate, and duplicated
some of the "real" open code. This was very badly done, and major
required parts of initialization were skipped. Fix this by removing
the code duplication. This consists mainly of moving the code for
opening the device to a separate function, and adding some changes
to handle format changes gracefully. (We can't change the audio
format on the fly, but we can at least not explode and play noise
when that happens.)
As a minor change, actually always use SNDCTL_DSP_RESET when closing
the audio device. We don't want to wait until the rest of the buffer
is played.
Also, don't use strerror() when printing the error message that
reopening failed, simply because reopen_device() takes care of this,
and also errno might be clobbered at this point.
I have no idea whether this is true, because there literally doesn't
seem to exist documentation for SNDCTL_DSP_RESET. But at least on
Linux' OSS emulation, it is true. Also, it would be quite insane if
it would be needed.
It seems on NetBSD SNDCTL_DSP_RESET exists, but using it for pausing
is not feasible. We still use it to discard the audio buffer when
closing the audio device.
Some window managers can prevent mapping of a window as a feature. i3
can put new windows on a certain workspace (with "assign"), so if mpv is
started on a different workspace, the window will never be mapped.
mpv currently waits until the window is mapped (blocking almost all of
the player), in order to avoid race conditions regarding the window
size. We don't want to remove this, but on the other hand we also don't
want to block the player forever in these situations.
So what we need is a way to know when the window manager is "done" with
processing the map request. Unfortunately, there doesn't seem to be a
standard way for this. So, instead we could do some arbitrary
communication with the WM, that may act as "barrier" after map request
and the "immediate" mapping of the window. If the window is not mapped
after this barrier, it means the window manager decided to delay the
mapping indefinitely. Use the _NET_REQUEST_FRAME_EXTENTS message as such
a barrier. WMs supporting this message must set the _NET_FRAME_EXTENTS
property on the mpv window, and we receive a PropertyNotify event. If
that happens, we always continue and cancel waiting for the MapNotify
event.
I don't know if this is sane or if there's a better mechanism. Also,
this works only for WMs which support this message, which are not many.
But at least it appears to work on i3. It may reintroduce flickering on
fullscreen with other WMs, though.
This is pretty imperfect, but it's just a demo.
The main purpose is clarifying how and when to get the video size.
In theory, retrieving the properties this way has a race condition:
after reading dwidth, the video could resize again. But the worst that
can happen are mismatching dwidth/dheight values, and the
MPV_EVENT_VIDEO_RECONFIG event would be immediately received again,
which would fix the mismatch. You could read the full video-out-params
property to absolutely avoid it, but it's not worth the trouble.
Merges pull request #1094, with some minor changes. mpv expects IEEE,
and IEEE allows divisions by 0 for floats, so these shouldn't actually
be a problem, but do it anyway for the sake of clang.
Signed-off-by: wm4 <wm4@nowhere>
Use libwaio to read from pipes (stdin or named pipes) on Windows. This
liberates us from nasty issues, such as pipes (as created by most
programs) not being possible to read in a non-blocking or event-driven
way. Although it would be possible to do that in a somewhat sane way
on Vista+, it's still not easy, and on XP it's especially hard. libwaio
handles these things for us.
Move pipe.c to pipe-unix.c, and remove Windows specific things. Also
adjust the input.c code to make this work cleanly.
If you send the "quit" or "stop" command with the client API, it will
now attempt to kill network I/O immediately (same as normal input in the
previous commits).
Refine the ugly hack from the previous commit, and let the "quit"
command and some others abort playback immediately. For
playlist_next/playlist_prev, still use the old hack, because we can't
know if they would stop playback or not.
This mechanism originates from MPlayer's way of dealing with blocking
network, but it's still useful. On opening and closing, mpv waits for
network synchronously, and also some obscure commands and use-cases can
lead to such blocking. In these situations, the stream is asynchronously
forced to stop by "interrupting" it.
The old design interrupting I/O was a bit broken: polling with a
callback, instead of actively interrupting it. Change the direction of
this. There is no callback anymore, and the player calls
mp_cancel_trigger() to force the stream to return.
libavformat (via stream_lavf.c) has the old broken design, and fixing it
would require fixing libavformat, which won't happen so quickly. So we
have to keep that part. But everything above the stream layer is
prepared for a better design, and more sophisticated methods than
mp_cancel_test() could be easily introduced.
There's still one problem: commands are still run in the central
playback loop, which we assume can block on I/O in the worst case.
That's not a problem yet, because we simply mark some commands as being
able to stop playback of the current file ("quit" etc.), so input.c
could abort playback as soon as such a command is queued. But there are
also commands abort playback only conditionally, and the logic for that
is in the playback core and thus "unreachable". For example,
"playlist_next" aborts playback only if there's a next file. We don't
want it to always abort playback.
As a quite ugly hack, abort playback only if at least 2 abort commands
are queued - this pretty much happens only if the core is frozen and
doesn't react to input.
This means they get special handling for asynchronously aborting
playback, even if the player is "stuck".
Also document "stop". It seems somewhat useful for client API users
(although that will be implemented properly only in the following
commits.)
The memcpy() is actually not enough: the types are incompatible, and no
memcpy, union, etc. will change that. (Although no real compiler will
ever break this.) Attempt to make this theoretically correct by actually
using a struct pointer. It's not the same struct type, but supposedly
it's ok, because all struct pointers always have the same size and
representation in standard C.
Idle mode went to sleep too early, e.g. just pressing "ESC" did nothing,
until the next event happened. This was because it directly went to
sleep after processing commands. What we should do instead is rechecking
all state after processing commands, redraw OSD, and then go to sleep.
This also fixes some strange OSD-related behavior.
Also move some other code around to separate idle mode initialization
from the normal run loop.
Not sure why this was originally added as autorepeated. It makes no
sense, because switching between choices should never autorepeat. (For
the normal "add"/"cycle" commands, autorepeat is usually enabled, but
command.c tries to disable it specifically for choice properties.)
Mismatching units in timeout calculation.
Also, as a near-cosmetic change, explicitly wake up the core on the
right time. Currently this does nothing, because the core is woken up
anyway - but it will matter with the next commit.
Replace select() usage with poll() (and reduce code duplication).
Also, while we're at it, drop --disable-audio-select, since it has the
wrong name anyway. And I have doubts that this is needed anywhere. If
it is, it should probably fallback to doing the right thing by default,
instead of requiring the user to do it manually. Since nobody has done
that yet, and since this configure option has been part of MPlayer ever
since ao_oss was added, it's probably safe to say it's not needed.
The '#ifdef SNDCTL_DSP_GETOSPACE' was pointless, since it's already used
unconditionally in another place.
1. Separate buffer and temporary file handling from the vo to make maintenance
and reading code easier
2. Skip resizing as much as possible if back buffer is still busy.
3. Detach and mark osd buffers for deletion if we want to redraw them and they
are still busy. This could be a possible case for the video buffers as
well. Maybe better than double buffering.
All the above steps made it possible to have resizing without any artifacts
even for subtitles. Also fixes dozen of bugs only I knew, like broken subtitles
for rgb565 buffers. I can now sleep at night again.
OSX is POSIX conformant, but it's a sad joke: it provides the
<semaphore.h> prototype as the standard demands, but they're empty
wrappers, and all functions just return ENOSYS.
Emulate them similar to how osdep/io.h emulate filesystem functions on
Windows. By including the header, working sem_* functions become
available.
To make it async-signal safe, use a pipe for wakeup (write() is AS-safe,
but mutexes can't be). Actually I'm not sure anymore if we really need
AS-safety, but for now the emulation can do it.
On Linux, the system provides a far more efficient and robust
implementation. We definitely want to avoid using the emulation if
possible, so this code is active on OSX only. For convenience we always
build the source file though, even if the implementation is disabled and
no actual code is generated.
(Linux provides working semaphores, but is formally not POSIX
conformant. On OSX it's the opposite. Is POSIX a complete joke?)
I'm not quite sure what we should actually do (maybe read input
commands?), but interpreting input as terminal key sequences is
definitely weird. So just do nothing.
Do terminal input with a thread, instead of using the central select()
loop. This also changes some details how SIGTERM is handled.
Part of my crusade against mp_input_add_fd().
An attempt at fixing #1070. Apparently something goes wrong if the
video size is equal to the screen size. Since the window decorations
add to the window size, it must actually be larger than the screen.
Actually I don't know what exactly is going wrong, but since this
commit also slightly improves the behavior otherwise, it's a win
anyway.
Try to keep the window size strictly below screen size, even accounting
for window decorations. Size it down and center the window so that it
fits (by either touching the left/right or top/bottom screen borders).
I haven't found any information on what is the maximum allowed size and
position of a window so that it doesn't collide with the task bar, so
assume that we can use the entire screen, minus 1 pixel to avoid
triggering fullscreen semantics (if that is even possible).
The purpose is making accessing the current playlist entry saner when
commands are executed during initialization, termination, or after
playlist navigation commands.
For example, the "playlist_remove current" command will invalidate
playlist->current - but some things still access the playlist entry even
on uninit. Until now, checking stop_play implicitly took care of it, so
it worked, but it was still messy.
Introduce the mpctx->playing field, which points to the current playlist
entry, even if the entry was removed and/or the playlist's current entry
was moved (e.g. due to playlist navigation).
To handle legacy commands, string replacement is used; the modified
string is returned by parse_cmd_str(), but it also frees all temporary
memory, which includes the replaced string.
Closes#1075.
Continues commit 348dfd93. Replace other places where input was manually
fetched with common code.
demux_was_interrupted() was a weird function; I'm not entirely sure
about its original purpose, but now we can just replace it with simpler
code as well. One difference is that we always look at the command
queue, rather than just when cache initialization failed. Also, instead
of discarding all but quit/playlist commands (aka abort command), run
all commands. This could possibly lead to unwanted side-effects, like
just ignoring commands that have no effect (consider pressing 'f' for
fullscreen right on start: since the window is not created yet, it would
get discarded). But playlist navigation still works as intended, and
some if not all these problems already existed before that in some
forms, so it should be ok.
reinit_window_state() will set VO_EVENT_RESIZE when it runs, so we
don't need to set it manually depending on the VOCTRL.
Probably avoids duplicated resize events. I don't expect this actually
fixes anything, but might help spotting other bugs easier (if there
are any).
This makes the player wait until each script is loaded. Do this to give
the script a chance to setup all its event handlers. It might also be
useful to allow a script to change options that matter for playback.
While waiting for a script to be loaded, the player actually accepts
input. This is needed because the scripts can execute player commands
anyway while they are being "loaded". The player won't react to most
commands though: it can't quit or navigate the playlist in this state.
For deciding whether a script is finally loaded, we use a cheap hack: if
mpv_wait_event() is called, it's considered loaded. Let's hope this is
good enough. I think it's better than introducing explicit API for this.
Although I'm sure this will turn out as too simplistic some time in the
future, the same would probably happen with a more explicit API.
Expose the central event handling functions explicitly, so that other
parts of the player can use them.
No functional changes. Preparation for the next commit.
This was kept in the codebase because it is slightly faster than --vo=opengl
on really old Intel cards (from the GMA era). Time to kill it, and let it rest.
Fixes#1061
With e.g --start=-3 --audio-buffer=10 the decoder entered EOF state
before the initial sync was finished, entered STATUS_EOF, and just
started playing audio from a random position.
This doesn't handle seeking outside of the file, which is a different
case. E.g. --start=30:00 with audio and video enabled in a file shorter
than 30:00 will play a random last part of audio. This could perhaps be
fixed by using the hr-seek target for cutting audio, instead of the
video PTS, but that would be kind of intrusive, so don't do it for now.
The simpler solution, assuming audio EOF on video EOF, wouldn't work,
because we allow audio to start before video, or to last after video.
Improve the logic how the audio thread decides how to wait until the AO
is ready for new data. The previous commit makes some of this easier,
although it turned out that it wasn't required, and we still can handle
AOs with bad get_space implementation (although the new code prints an
error message, and it might fail in obscure situations).
The new code is pretty similar to the old one, and the main thing that
changes is that complicated conditions are tweaked. AO waiting is now
used better (mainly instead of max>0, r>0 is used). Whether to wakeup
is reevaluated every time, instead of somehow doing the wrong thing
and compensating for it with a flag.
This fixes the specific situation when the device buffer is full, and
we don't want to buffer more data. In the old code, this wasn't handled
correctly: the AO went to sleep forever, because it prevented proper
wakeup by the AO driver, and as consequence never asked the core for new
data. Commit 4fa3ffeb was a hack-fix against this, and now that we have
a proper solution, this hack is removed as well.
Also make the refill threshold consistent and always use 1/4 of the
buffer. (The threshold is used for situations when an AO doesn't
support proper waiting or chunked processing.)
This commit will probably cause a bunch of regressions again.
Round get_space() results in the same way play() rounds the input size.
Some audio APIs do this for various reasons.
This affects only "push" based AOs. Some of these need no change,
because they either do it already right (like ao_openal), or they seem
not to have any such requirements (like ao_pulse).
Needed for the following commit.
"#" starts a comment, so the # key needs to be handled specially.
MPlayer has the same issue, but its input.conf is wrong. Or at least I
think it's wrong; looking at the MPlayer code it's doubtful they somehow
special-case and handle this.
Remove the unnecessary indirection through ao fields.
Also fix the inverted result of AOCONTROL_HAS_TEMP_VOLUME. Hopefully the
change is equivalent. But actually, it looks like the old code did it
wrong.
This is a deadlock caused by a lock order issue: sub/osd.c locks the OSD
first, then the subtitle decoder lock. player/sub.c does the reverse.
Fix this by discussing away the requirement for locking (see below),
which allows us to drop the broken sub lock. sub_get_text() still
acquires and releases the sub decoder lock, but it's not held at the
same time as the OSD lock anymore, so it should be fine.
Originally, the sub lock was acquired because sub_get_text() returns a
pointer to a mutable string. We simply declare that it's ok to call it
unlocked, as long as only 1 thread accesses it, which works out fine in
this case.
With --gapless-audio=no, changing from one file to the next apparently
made it hang, until the player was woken up by unrelated events like
input. The reason was that the AO doesn't notify the player of EOF
properly. the played was querying ao_eof_reached(), and then just went
to sleep, without anything waking it up.
Make it event-based: the AO wakes up the playloop if the EOF state
changes.
We could have fixed this in a simpler way by synchronously draining the
AO in these cases. But I think proper event handling is preferable.
Fixes: #1069
CC: @mpv-player/stable (perhaps)
It seems hrtf works in 48khz only - and if that wasn't the input, the
filter just exited with an error. Make it request the 48khz instead. The
player will insert a resampling filter.
Not sure why it wasn't done like this in the first place.
The Windows version of tmpfile is actually pretty broken. It tries to
create the file in the root directory of the current drive, which means
on Vista and up, it normally fails due to insufficient permissions.
Replace it with a version that uses GetTempPath.
Also remove the Windows-specific note about automatic deletion of the
cache file. FILE_FLAG_DELETE_ON_CLOSE is available in NT, and it should
be pretty reliable.
Somehow, there was a larger misunderstanding in the code: ao_buffer
does not need to be preserved over audio reinit for proper support of
gapless audio. The actual AO internal buffer takes care of this.
In fact, preserving ao_buffer just breaks audio resync. In the ordered
chapter case, end_pts is used, which means not all audio data in the
buffer is played, thus some data is left over when audio decoding
resumes on the next segment. This triggers some code that aborts resync
if there's "audio decoded" (ao_buffer contains something), but no PTS
is known (nothing was actually decoded yet).
Simplify, and always bind the output buffer to the decoder.
CC: @mpv-player/stable (maybe)
The oldest supported FFmpeg release doesn't provide
av_vdpau_alloc_context(). With these versions, the application has no
other choice than to hard code the size of AVVDPAUContext. (On the other
hand, there's av_alloc_vdpaucontext(), which does the same thing, but is
FFmpeg specific - not sure if it was available early enough, so I'm not
touching it.)
Newer FFmpeg and Libav releases require you to call this function, for
ABI compatibility reasons. It's the typcal lakc of foresight that make
FFmpeg APIs terrible. mpv successfully pretended that this crap didn't
exist (ABI compat. is near impossible to reach anyway) - but it appears
newer developments in Libav change the function from initializing the
struct with all-zeros to something else, and mpv vdpau decoding would
stop working as soon as this new work is relewased.
So, add a configure test (sigh).
CC: @mpv-player/stable
This wraps waf's find_program in our own check boilerplate code so that it
can be used in the declarative dependencies section of the wscript.
Can be used like this:
}, {
'name': 'sed',
'desc': 'sed program',
'func': check_program('sed', 'SED'),
}, {
First argument is the program name, and the second is the waf variable name
where the program path will be stored. In this example we will be able to
refer to sed with ${{SED}} when creating waf Tasks in wscript_build.
/cc @giselher: I think you need this for wayland-scanner.
Don't worry, your ~/.config/... paths are safe. This merely removes
handling of $XDG_CONFIG_DIRS for global paths.
Maybe there is a better solution for this, like still including the
"traditional" config dir. But I will leave the fine reading of this
(crappy) spec and fixing the code accordingly to someone else. So, if
anyone has interest in getting this behavior back, you will have to
write a patch. This patch should _also_ not break expected behavior.
Fixes#1060.
The last demuxed file position (demuxer->filepos) is used to estimate
the total playback percentage in files with possible timestamp resets
(like MPEG-PS). Until know, reading from any stream set this position
freely. This makes the position jump around.
Fix this by allowing icnreasing file position only. Reset it on seeking.
With crazy formats, this still could go wrong, but there's only so much
you can do.
HLS streams as demuxed by libavformat have no track title metadata. So
show the HLS bitrate if no title is set. Could be useless or annoying,
so it's a bit controversial, I guess.
--hls-bitrate=min/max lets you select the min or max bitrate. That's it.
Something more sophisticated might be possible, but is probably not even
worth the effort.
This catches a few cases which basically call:
m_property_strdup_ro(..., ..., NULL)
which would return NULL strings. This should generally be avoided
(although it's allowed due to reasons), and it seems most callers
actually intend this to mean M_PROPERTY_UNAVAILABLE.
Because that might be a bad idea.
Note that remote playlists still can use any protocol marked with
is_safe and is_network, because the case of http-hosted playlists
containing URLs using other streaming protocols is not unusual.
Loading a playlist with --playlist from a sub-directory added the
playlist's base path twice: one time in the playlist demuxer, and then
again in playlist_parse_file(). The latter function is used only for
--playlist, so it worked when loading the playlist directly.
(This is probably a mess-up when the MPlayer playlist parsers were
replaced with newer code.)
CC: @mpv-player/stable
The event was copied early, and wasn't released if it was rejected
instead of being added to the event queue. Fix by copying the event at a
point when it's certainly added to the event queue.
The dup_event_data() function is merely moved.
Until now, you had to use --load-unsafe-playlists or --playlist to get
playlists loaded. Change this and always load playlists by default.
This still attempts to reject unsafe URLs. For example, trying to invoke
libavdevice pseudo-demuxer is explicitly prevented. Local paths and any
http links (and some more) are always allowed.
Probably no observable effect, but it's more correct. Setting audio to
EOF could have bad effects otherwise (anywhere the player logic for
example decides whether EOF was reached, and such).
The audio/video sync code in player/audio.c calls ao_reset() each time
audio decoding is entered, but the player is paused, and there would be
more than 1 sample to skip to make audio start match with video start.
This caused a wakeup feedback loop with push.c.
CC: @mpv-player/stable
When embedding a X window, it's hard to control whether it receives
mouse/keyboard input or not. It seems the X protocol itself makes this
hard (basically due to the outdated design mismatching with modern
toolkits), and we have to take care of these things explicitly.
Simply do this by manually querying and using the parent window event
flags.
This restores some MPlayer behavior (it doesn't add back exactly the
same code, but it's very similar).
This probably has some potential to interfere with libmpv embedding, so
bump the client API minor.
CC: @mpv-player/stable (if applied, client-api-changes.rst has to be
adjusted to include the 0.5.2 release)
In particular, use the note markup. The issue about rounded timestamps
is mostly with respect to Matroska (which usually rounds them to
milliseconds), which somewhat adds to the reliability issue.
This inserts an automatic conversion filter if a Matroska file is marked
as 3D (StereoMode element). The basic idea is similar to video rotation
and colorspace handling: the 3D mode is added as a property to the video
params. Depending on this property, a video filter can be inserted.
As of this commit, extending mp_image_params is actually completely
unnecessary - but the idea is that it will make it easier to integrate
with VOs supporting stereo 3D mogrification. Although vo_opengl does
support some stereo rendering, it didn't support the mode my sample file
used, so I'll leave that part for later.
Not that most mappings from Matroska mode to vf_stereo3d mode are
probably wrong, and some are missing.
Assuming that Matroska modes, and vf_stereo3d in modes, and out modes
are all the same might be an oversimplification - we'll see.
See issue #1045.
Since we have to be portable, our options for creating temporary files
are somewhat limited. tmpfile() happens to be available everywhere, so
use that. This function doesn't allow having a "visible" filename or
location, so we use the magic string "TMP" for this.
A (hopefully) temporary hack to make stream switching delays tolerable.
It's not clear how this should be handled (either executing a precise
seek on track switching, or always enabling all streams), so get this
issue out of the way for now by picking a rather low value.
In the else branch pict_type is always 3, so pict_type != 3 is always
false. (Note that I have no idea of what it was supposed to do and it is
just an equivalent of the old behaviour.)
The player didn't quit when seeking past EOF in audio-only mode while
paused. The only case when we don't want to quit is when the last video
frame is displayed while paused.
This logic was probably broken a while ago, but I'm not exactly sure.
CC: @mpv-player/stable
bstr.c doesn't really deserve its own directory, and compat had just
a few files, most of which may as well be in osdep. There isn't really
any justification for these extra directories, so get rid of them.
The compat/libav.h was empty - just delete it. We changed our approach
to API compatibility, and will likely not need it anymore.
Just so I can move this file without modifying its contents in the next
commit.
compat/compiler.h is to be moved to osdep/ with the next commit, so add
a dummy header.
Don't reconnect to the cache (since the cached stream already handles
reconnection). This is necessary, because since commit 0b428e44 the
"streaming" field (which also controls whether attempting to reconnect
makes sense at all) is inherited to the cache stream wrapper.
Also, let the stream reset its own position on reconnect. This removes
some assumptions and messy handling from the reconnect function.
Make sure the cache is dropped on reconnect. This takes care of
readjusting the stream position if necessary. (Also drop the cache on
DVB channel switching commands.)
Add a mechanism to the client API code, which allows the player core to
query whether a client API event is needed at all. Use it for the cache
update.
In this case, this is probably a pure microoptimization; but the
mechanism will be useful for other things too.
Don't attempt to resync after speed changes. Note that most other cases
of audio reinit (like switching tracks etc.) still resync, but other
code paths take care of setting the audio_status accordingly.
This restores the old behavior of not trying to fix audio desync, which
was probably changed with commit 261506e3.
Note that the code as of now wasn't even entirely correct, since the A/V
sync values are slightly shifted. The dsync depends on the audio buffer
size, so a larger buffer size will show more extreme desync. Also see
mplayer2 commit 213a224e, which should fixed this - it was not merged
into mpv, because it disabled audio for too long, resulting in a worse
user experience. This is similar to the issue this commit attempts to
fix.
Fixes: #1042 (probably)
CC: @mpv-player-stable
Regression since commit f14722a4. For some reason, this worked on
nvidia, but rightfully failed on mesa.
At least in C, the ## operator indeed needs two macro arguments, and
you can't just concatenate with non-arguments.
This change will most likely fix it.
CC: @bjin
Remove the hardcoded wait time of 2 seconds. Instead, adjust the wait
time each time we unpause: if downloading the data took longer than its
estimated playback time, increase the amount of data we wait for. If
it's shorter, decrease it.
The +/- is supposed to avoid oscillating between two values if the
elapsed time and the wait time are similar. It's not sure if this
actually helps with anything, but it can't harm.
Use the "native" underrun detection, instead of guessing by a low cache
duration. The new underrun detection (which was added with the original
commit) might have the problem that it's easy for the playloop to miss
the underrun event. The underrun is actually not stored as state, so if
the demuxer thread adds a new packet before the playloop happens to see
the state, it's as if it never happened. On the other hand, this means
that network was fast enough, so it should be just fine.
Also, should it happen that we don't know the cached range (the
ts_duration < 0 case), just wait until the demuxer goes idle (i.e.
read_packet() decides to stop). This pretty much should affect broken or
unusual files only, and there might be various things that could go
wrong. But it's more robust in the normal case: this situation also
happens when no packets have been read yet, and we don't want to
consider this as reason to resume playback.
The cache percentage was useless. It showed how much of the total stream
cache was in use, but since the cache size is something huge and
unrelated to the bitrate or network speed, the information content of
the percentage was rather low.
Replace this with printing the duration of the demuxer-cached data, and
the size of the stream cache in KB.
I'm not completely sure about the formatting; suggestions are welcome.
Note that it's not easy to know how much playback time the stream cache
covers, so it's always in bytes.
The "buffering" logic was active even if the stream cache was disabled.
This is contrary to what the manpage says. It also breaks playback
because of another bug: the demuxer cache is smaller than 2 seconds,
and thus the resume condition never becomes true.
Explicitly run this code only if the stream cache is enabled. Also, fix
the underlying problem of the breakage, and resume when the demuxer
thread stops reading in any case, not just on EOF.
Broken by previous commit. Unbreaks playback of local files.
Add the --cache-secs option, which literally overrides the value of
--demuxer-readahead-secs if the stream cache is active. The default
value is very high (10 seconds), which means it can act as network
cache.
Remove the old behavior of trying to pause once the byte cache runs
low. Instead, do something similar wit the demuxer cache. The nice
thing is that we can guess how many seconds of video it has cached,
and we can make better decisions. But for now, apply a relatively
naive heuristic: if the cache is below 0.5 secs, pause, and wait
until at least 2 secs are available.
Note that due to timestamp reordering, the estimated cached duration
of video might be inaccurate, depending on the file format. If the
file format has DTS, it's easy, otherwise the duration will seemingly
jump back and forth.
The purpose of the unconditional pthread_cond_signal() when reading
cached DEMUXER_CTRLs and STREAM_CTRLs was apparently to update the
stream cache state. Otherwise, the cached fields would never be updated
when the stream is e.g. paused.
The same could be said about other CTRLs, but these aren't as important,
since they are normally updated while reading packet data.
In order to reduce wakeups, make this logic explicit.
Add a new parameter 'p' to gaussian filter. The new formula used
a different base taken from fmtconv plugin, so that the
new parameter is exactly same as the one used in Avisynth and
Vapoursynth.
The new default value is 2 / log(2) * 10, with the default value it
conforms to the original kernel taken from vector-agg.
Add two new options, make it possible for user to set the radius
for some of the filters with no fixed radius.
Also add three new filters with the new radius parameter supported.
When video format changes, the frame before the frame with the new
format sets video_status briefly to STATUS_DRAINING. This caused the
code to handle the EOF case to kick in, which just pauses the player
when trying to step past the last frame. As a result, trying to
framestep over format changes resulted in pausing the player.
Fix by testing against the correct status.
"Shift+X" didn't actually map any key, as opposed to "Shift+x". This is
because shift usually changes the case of a character, so a plain
printable character like "X" simply can never be combined with shift.
But this is not very intuitive. Always remove the shift code from
printable characters. Also, for ASCII, actually apply the case mapping
to uppercase characters if combined with shift. Doing this for unicode
in general would be nice, but that would require lookup tables. In
general, we don't know anyway what character a key produces when
combined with shift - it could be anything, and depends on the keyboard
layout.
The little lua snippet at #488 as well as the actual implementation
seems to indicate that not expanding properties is indeed the correct
behavior. Document that.
Signed-off-by: wm4 <wm4@nowhere>
This shouldn't change anything functionally.
Change the A/V desync message. --framedrop is enabled by default now, so
the text must be changed a little. I've never heard of audio outputs
messing up A/V sync recently, so remove that part.
Remove the unused ao_pts field.
Reorder 2 A/V sync related expressions so that they look the same.
Abandon the "old" infrastructure for --input-file (mp_input_add_fd(),
select() loop, non-blocking reads). Replace it with something that
starts a reader thread, using blocking input.
This is for the sake of Windows. Windows is a truly insane operating
system, and there's not even a way to read a pipe in a non-blocking
way, or to wait for new input in an interruptible way (like with
poll()). And unfortunately, some want to use pipe to send input to
mpv. There are probably (slightly) better IPC mechanisms available
on Windows, but for the sake of platform uniformity, make this work
again for now.
On Vista+, CancelIoEx() could probably be used. But there's no way on
XP. Also, that function doesn't work on wine, making development
harder. We could forcibly terminate the thread, which might work, but
is unsafe. So what we do is starting a thread, and if we don't want
the pipe input anymore, we just abandon the thread. The thread might
remain blocked forever, but if we exit the process, the kernel will
forcibly kill it. On Unix, just use poll() to handle this.
Unfortunately the code is pretty crappy, but it's ok, because it's late
and I wanted to stop working on this an hour ago.
Tested on wine; might not work on a real Windows.
For --input-test, print messages on terminal by default.
Raise message level for enabling input sections, because the OSC makes
this very extremely annoying.
This is a simplification, because it lets us use the AVPacket
functions, instead of handling the details manually.
It also allows the libavcodec rawvideo decoder to use reference
counting, so it doesn't have to memcpy() the full image data. The change
in av_common.c enables this.
This change is somewhat risky, because we rely on the following AVPacket
implementation details and assumptions:
- av_packet_ref() doesn't access the input padding, and just copies the
data. By the API, AVPacket is always padded, and we violate this. The
lavc implementation would have to go out of its way to make this a
real problem, though.
- We hope that the way we make the AVPacket refcountable in av_common.c
is actually supported API-usage. It's hard to tell whether it is.
Of course we still use our own "old" demux_packet struct, just so that
libav* API usage is somewhat isolated.
If a packet is appended to a stream, and there were already packets
queued, nothing about the state changed, as far as the user (i.e. the
player) is concerned. Thus no wakeup is needed.
The pthread_cond_signal() call following this is not interesting - it
will simply be a NOP if there are actually no waiters.
It makes no sense to set the packet duration, because libavcodec doesn't
know the timebase. And in fact, no subtitle decoder accesses the packet
duration, except text subtitle converters, which are not relevant here.
So this code did nothing - drop it.
Also fix a blatantly incorrect comment.
If duration<0, it means the duration is unknown. Disable framedropping,
because end_time makes no sense in this case.
Also, strictly never drop the first frame.
This fixes weird behavior with the cover-art case (for the 100th time).
Commit 846257da introduced an accidental feature: if you kept seeking
(so playback never really resumes), the audio would never be played.
This was nice, but commit 4c25b000 accidentally removed it again (due
to the video_next_pts being earlier available than it used to be, so
audio could be played before the player executed the next queued seek).
Implicitly reintroduce the old behavior again by not decoding a second
video frame immediately. Usually, the second frame is used to compute
the frame duration needed to for accurate framedropping, but since the
first frame after a seek is never dropped, we don't need this.
Now the video code will queue the new frame to the VO immediately, and
since fill_audio_out_buffers() is called in the playloop before
write_video() and execute_queued_seek(), it never gets the chance to
enter STATUS_READY, and seeks will be silent.
This also has a nice side-effect: since the second frame is not decoded
and filtered, seeking becomes slightly faster (back to the same level
as with framedrop disabled).
It seems this still sometimes plays a period of audio when keeping a
seek key down. In my tests, this appeared to happen because the seek
finished before the next key repeat was sent.
In theory, timestamps can be negative, so we shouldn't just return -1
as special value.
Remove the separate code for clearing decode buffers; use the same code
that is used for normal seek reset.
Commit 5afc025c broke this. The reason is that mpctx->delay is updated
when a new video frame is added. This value is also needed to resync
audio, but it will be for the wrong PTS. They must be consistent with
each other, and if they aren't, initial sync will be off by N video
frames, which results at least in worse user experience.
This can be reproduced by for example heavily switching between normal
and 2x speed, or similar.
Fix by readding the video_next_pts field (keeping its use minimal,
instead of reverting the commit that removed it).
If video reaches EOF, and audio is also EOF (or is otherwise not
meaningful, like audio disabled), then the playback position was briefly
set to 0. Fix this by not trying to use a bogus audio PTS.
CC: @mpv-player/stable (maybe)
This simplifies the code, and fixes an odd bug: the second-last frame
was displayed for a very short duration if framedrop was enabled. The
reason was that basically the time difference between second-last and
last frame were skipped, because at this point EOF was already
signaled. Also see commit b0959488 for a similar issue in the
same code.
This removes the messiness of the next_frame 2-frame queue, and
strictly runs the "new frame" code when a frame is moved to the first
position of the queue, instead of somehow messing with return codes.
This also merges update_video() into video_output_image().
No functional changes. init_vo() is now needed a bit further down, and
moving it keeps definition and use close. adjust_sync() will be used by
a function further up in one of the following commits.
Add two new script environment variables 'video_in_dw' and
'video_in_dh', representing the display resolution of video. Along
with video resolution, sample ratio aspect can be calculated in
scripts.
Currently it's impossible to change sample ratio aspect with single
vapoursynth filter since '_SARNum' and '_SARDen' frame properties
from output clip will be ignored. A following 'dsize' filter is
necessary for this purpose.
This is independent of terminfo/termcap, and supports more keys.
Originally, the goal was just extending the set of supported key
sequences, but since the terminfo stuff actually makes this much harder,
and since it's a big blob of bloated legacy crap, just drop it. Instead,
use hardcoded tables.
It's pretty easy to get on the same level as the old code (with fewer
LOC), and we avoid additional error situations, such as mallocs which
could fail (the old code just ignores malloc failures). We also try to
support some xterm escape sequences, which are in relatively widespread
use. (I'm not sure about the urxvt ones.)
Trying to deal with xterm shift/ctrl/alt modifiers is probably a bit
overcomplicated, and only deals with prefixes - xterm randomly uses
prefix sequences for some keys, and suffixes for others (what the heck).
Additionally, try to drop unknown escape codes. This basically relies
on a trick: in almost 100% of all situations, a read() call will
actually return complete sequences (possibly because of pipe semantics
and atomic writes from the terminal emulator?), so it's easy to drop
unknown sequences. This prevents that they trigger random key bindings
as the code interprets the part after ESC as normal keys.
This also drops the use of terminfo for sending smkx/rmkx. It seems
even vt100 (to which virtually everything non-legacy is reasonably
compatible with) supports the codes we hardcode, so it should be fine.
This commit actually changes only the code if terminfo/termcap are not
found. The next commit will make this code default.
Surprisingly, WaitFor* works on console handles. We can simply run the
code for reading the console in a thread, and don't have to worry about
crazy win32 crap in the rest of the player's input code anymore.
This also fixes the issue that you couldn't unpause the player from the
terminal, because the player would stop polling for input.
We already redirect all terminal output through our own wrappers (for
the sake of UTF-8), so we might as well use it to handle ANSI escape
codes.
This also changes behavior on UNIX: we don't retrieve some escape codes
per terminfo anymore, and just hardcode them. Every terminal should
understand them.
The advantage is that we can pretend to have a real terminal in the
normal player code, and Windows atrocities are locked away in glue
code.
The original intention was probably to avoid unnecessarily high numbers
of wakeups. Change it to wait at most 25% of buffer time instead of 75%
until refilling. Might help with the dsound problems in issue #1024, but
I don't know if success is guaranteed.
So talking to a certain Intel dev, it sounded like modern VA-API drivers
are reasonable thread-safe. But apparently that is not the case. Not at
all. So add approximate locking around all vaapi API calls.
The problem appeared once we moved decoding and display to different
threads. That means the "vaapi-copy" mode was unaffected, but decoding
with vo_vaapi or vo_opengl lead to random crashes.
Untested on real Intel hardware. With the vdpau emulation, it seems to
work fine - but actually it worked fine even before this commit, because
vdpau was written and designed not by morons, but competent people
(vdpau is guaranteed to be fully thread-safe).
There is some probability that this commit doesn't fix things entirely.
One problem is that locking might not be complete. For one, libavcodec
_also_ accesses vaapi, so we have to rely on our own guesses how and
when lavc uses vaapi (since we disable multithreading when doing hw
decoding, our guess should be relatively good, but it's still a lavc
implementation detail). One other reason that this commit might not
help is Intel's amazing potential to fuckup anything that is good and
holy.
This could be used by VO implementations to report a recent vsync time
to the generic VO code, which in turn will use it and the display FPS
to estimate at which point in time the next vsync will happen.
This uses glXGetVideoSyncSGI() to check how many vsyncs happened since
the last flip_page() call. It allows checking a pattern of vsync
increments of at most 2 elements. For example, to check ~24 fps playback
on a ~60 Hz monitor, this can be used:
--vo=opengl:check-pattern=[3-2]:waitvsync
Whether the reported results are accurate or just plain wrong may depend
on the driver and if the waitvsync sub-option is used. There are no
guarantees.
This option is undocumented, and may be removed again in the near or
distant future.
For debugging (drawing fun plots with TOOLS/stats-conv.py).
Also move last_flip under the correct comment: it's not protected by the
lock, and can be accessed by the VO thread only.
Playing with high framedrop could make it run out of surfaces. In
theory, we wouldn't need an additional surface, if we could just clear
the vo_vaapi internal surface - but doing so would probably be a pain,
so I don't care.
Only reports the most recently entered output if the window is displayed on
2 or more outputs. Should be changed to the lowest fps of all outputs the
window is visible. Until no one complains this will have to wait.
Look for the VO framedropping for more information on this topic.
After a new file is loaded, playback never starts instantly. Rather, it
takes some playloop iterations until initial audio and video have been
decoded, and the outputs have been (lazily) initialized. This means you
will get status line updates between the messages that inform of the
initialized outputs. This is a bit annoying and clutters the terminal
output needlessly.
Fix this by never printing the status line before playback isn't fully
initialized. Do this by reusing the --term-playing-msg code (which
prints a message once playback is initialized). This also makes sure the
status line _is_ shown during playback restart when doing seeks.
It's possible that the change will make the output more confusing if for
some reason is stuck forever initializing playback, but that seems like
an obscure corner case that never happens, so forget about it.
print_status() is called at a later point anyway (and before sleeping),
so this code has little effect. This code was added in commit a4f7a3df5,
and I can't observe any problems with idle mode anymore.
Now print_status() is called from a single place only, within osd.c.
If the Xrandr configuration changes, re-read it. So if you change
display modes or screen configuration, it will update the framedrop
refresh rate accordingly.
This passes the rootwin to XRRSelectInput(), which may or may not be
allowed. But it works, and the documentation (which is worse than used
toilet paper, great job Xorg) doesn't forbid it, or in fact say anything
about what the window parameter is even used for.
Nvidia's vdpau implementation is pretty good, but other factors make it
much less attractive for use as default VO. For example, Mesa often has
low quality drivers (mess up things with the presentation queue and the
vdpau API time source). Intel ruins things completely, and we're likely
to run on emulation via OpenGL. Compositing has unknown effects (to me
anyway), but appears to reduce the vdpau advantages.
One important reason to prefer vo_vdpau was that it could do proper
framedropping. Framedropping got fixed for the other VOs, so this reason
is going away.
This works only on X11, and only if the refresh rate changes due to the
window being moved to another screen (detected by us). It doesn't
include system screen reconfiguration yet.
This calls VOCTRL_GET_DISPLAY_FPS on every frame, which makes me uneasy.
It means extra thread communication with the win32 and Cocoa backends.
On the other hand, a frame doesn't happen _that_ often, and the
communication should still be pretty cheap and fast, so it's probably
ok.
Also needs some extra fuzz for vo_vdpau.c, because that does everything
differently.
This is always included in the Xorg development headers. Strictly
speaking it's not necessarily available with other X implementations,
but these are hopefully all dead.
Drop use of the ancient XF86VM, and use the slightly less ancient Xrandr
extension to retrieve the refresh rate. Xrandr has the advantage that it
supports multiple monitors (at least the modern version of it).
For now, we don't attempt any dynamic reconfiguration. We don't request
and listen to Xrandr events, and we don't notify the VO code of changes
in the refresh rate. (The later works by assuming that X coordinates map
directly to Xrandr coordinates, which probably is wrong with compositing
window manager, at least if these use complicated transformations. But I
know of no API to handle this.)
It would be nice to drop use of the Xinerama extension too, but
unfortunately, at least one EWMH feature uses Xinerama screen numbers,
and I don't know how that maps to Xrandr outputs.
--demuxer-readahead-secs now controls how much the demuxer should
readahead by an amount of seconds. This is based on the raw packet
timestamps. It's not always very exact. For example, h264 in Matroska
does not store any linear timestamps (only PTS values which are going
to be reordered by the decoder), so this heuristic is usually off by
several hundred milliseconds.
The decision whether to readahead is basically OR-ed with the other
--demuxer-readahead-packets options. Change the manpage descriptions
to subtly convey these semantics.
Since the display FPS is currently detected on X11 only (and even there
it's known to be wrong on certain setups), it seems like a good idea to
make this user-configurable.
I'm not sure about the merit, though it does print nice numbers if debug
output is enabled.
Basically, this tries to achieve similar results as the glFinish()
business, but again it entirely depends on the drivers whether this
does anything meaningful, or whether it's actively harmful.
It seems that at least on nvidia systems with composting disabled, we
can get it to block deterministically on the actual vsync event, which
should improve framedropping.
This mostly uses the same idea as with vo_vdpau.c, but much simplified.
On X11, it tries to get the display framerate with XF86VM, and limits
the frequency of new video frames against it. Note that this is an old
extension, and is confirmed not to work correctly with multi-monitor
setups. But we're using it because it was already around (it is also
used by vo_vdpau).
This attempts to predict the next vsync event by using the time of the
last frame and the display FPS. Even if that goes completely wrong,
the results are still relatively good.
On other systems, or if the X11 code doesn't return a display FPS, a
framerate of 1000 is assumed. This is infinite for all practical
purposes, and means that only frames which are definitely too late are
dropped. This probably has worse results, but is still useful.
"--framedrop=yes" is basically replaced with "--framedrop=decoder". The
old framedropping mode is kept around, and should perhaps be improved.
Dropping on the decoder level is still useful if decoding itself is too
slow.
Apparently users prefer this behavior.
It was used for subtitles too, so move the code to calculate the video
offset into a separate function. Seeking also needs to be fixed.
Fixes#1018.
The OSD is marked as changed, but the core isn't notified and this
doesn't immediately wakeup. (Possibly the OSD code should wakeup the
core instead, but maybe that woudl be overkill.)
Observed when using "mp.use_suspend = false" in the OSC, and pausing,
and moving the mouse pointer out of the window. The last part of the
fade remained visible for longer than intended.
Code reorganized to make layouts exchangeable
alternative test layout can be tested with
layout=slimbox
in the OSC config
timers are now used to properly animate the fade out when the
player is paused
duplicate seeks are discarded again
sub_reset() was called on cycling subtitle tracks and on seeking. Since
we don't want that subtitles disppear on cycling, sd_lavc.c didn't clear
its internal subtitle queue on reset, which meant that seeking with PGS
subtitles could leave the subtitle on screen (PGS subtitles usually
don't have a duration set).
Call it only on seeking, so we can also strictly clear the subtitle
queue in sd_lavc.
(This still can go very wrong if you disable a subtitle, seek, and
enable it again - for example, if used with libavformat that uses "SSA"
style demuxed ASS subtitle packets. That shouldn't happen with newer
libavformat versions, and the user can "correct" it anyway by executing
a seek while the subtitle is selected.)
Until recently, vo_opengl could be accessed from a single thread only,
due to the OpenGL API context being thread-specific. This issue doesn't
exist anymore, because VOs run on their own thread. This means we can
simply lock/unlock the playloop instead of doing something complicated
to get the playloop thread to execute our code.
It's not true anymore that the core will stop replying for 50ms
(waiting for video) without calling this function. Simplify the
documentation accordingly. Accessing properties that go through
the VO still have this problem, though.
The previous commit made the completion script always return non-zero, even when
a match is found. This explicitly sets the return value to zero whenever a match
is found but defaults to non-zero in case nothing is matched.
Returning a non-zero value signals to the zsh completion system that no matches
were added by the script so that it can try the user-defined matchers (e.g.
those defined with matcher-list).
Fixes#1008.
This ran adjust_sync() on every playloop iteration, instead of every
newly decoded frame. It seems this was idempotent in the common case,
but the code was originally designed to be run once only, so restore
that.
Otherwise vdp_video_mixer_destroy() would later fail when called on an invalid
video mixer handle. With mesa r600 vdpau driver, this would cause a segfault.
Since the 'syms' tool is shipped in waf's extras, when using system waf the
default tool overrides our own. Force our syms tool by providing the tooldir.
Fixes#1006
Xlib is not thread-safe. Or actually it is, but it's an incomprehensible
hack that was added later, and which needs to be acitvated manually
(this makes no sense). And it appears that the vdpau accesses X from the
decoder thread if GLX interop is used (and not in any other situations -
this doesn't make too much sense either).
So, just call the magic function that enables Xlib thread-safety.
The previous commit broke these things, and fixing them is separate in
this commit in order to reduce the volume of changes.
Move the image queue from the VO to the playback core. The image queue
is a remnant of the old way how vdpau was implemented, and increasingly
became more and more an artifact. In the end, it did only one thing:
computing the duration of the current frame. This was done by taking the
PTS difference between the current and the future frame. We keep this,
but by moving it out of the VO, we don't have to special-case format
changes anymore. This simplifies the code a lot.
Since we need the queue to compute the duration only, a queue size
larger than 2 makes no sense, and we can hardcode that.
Also change how the last frame is handled. The last frame is a bit of a
problem, because video timing works by showing one frame after another,
which makes it a special case. Make the VO provide a function to notify
us when the frame is done, instead. The frame duration is used for that.
This is not perfect. For example, changing playback speed during the
last frame doesn't update the end time. Pausing will not stop the clock
that times the last frame. But I don't think this matters for such a
corner case.
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
Found with valgrind. This is somewhat terrifying, because the VA-API API
function is supposed to fill these values, and we access them only if
the API functions return success. So this shouldn't have happened.
The function video_decode_and_filter(), called between initializing the
local vf variable and using it, can actually destroy and recreate the
filter. Thus, the vf variable turns into a dangling pointer if that
happens.
Could be observed with: --hwdec=vda --deinterlace=yes --vf=yadif
(Also happens with vdpau/vaapi.)
When a new event was added, merely a flag was set, instead of actually
waking up the core (if needed). This was ok in ancient times when all
event sources were part of the select() loop. But now there are several
cases where other threads can add input, and then you actually need to
wakeup the core in order to make it read the events at all.
This code was sending a string to a different thread, and then
deallocated the string shortly after, which means most of the time
the other thread was accessing a dangling pointer.
It's possible that this is the cause for #1002.
vo_sdl.c has broken event handling and just polls. The polling time was
quite low, so the playloop OSD redrawing heuristic inhibited redraws,
which made the window appear frozen when paused.
Completely useless, and could accidentally be enabled by cycling
framedrop modes. Just get rid of it.
But still allow triggering the old code with --vd-lavc-framedrop, in
case someone asks for it. If nobody does, this new option will be
removed eventually.
Some of them changed semantics or got renamed.
Note that the replacements in the example.conf are not necessarily the
equivalents of the replaced options.
Trying to jump chapters in a gile that has no chapters does nothing,
not even show a warning. This is confusing. The reason is that the
"add chapter" command will just bail out completely if the property
is unavailable.
This was because it exited when it couldn't get the property type.
Instead of exiting, just don't enter the code that needs the type.
(I'm not sure when this behavior changed. I consider it a regression.
It was probably caused by changes to the chapter code, which perhaps
started returning UNAVAILABLE instead of OK if there are no chapters.)
Split the options into the following sections:
* Playback Control
* Program Behaviour
* Video
* Audio
* Subtitles
* Window
* Disc Devices
* Equalizer
* Demuxer
* Input
* OSD
* Screenshot
* Software Scaler
* Terminal
* TV
* Cache
* Network
* DVB
* PVR
* Miscellaneous
Most options are sorted by usefullness and how often they're used or how
important they are.
This makes finding the right options easier and adds some sort of structure.
Reduce from 1000ms to 100ms. Since there is an audio thread updating AOs
quickly enough now, requesting such a large buffer size makes no sense
anymore.
Changing audio-delay is probably not needed.
Changing balance "works", but not as expected (sets up a pan matrix to
change left/right contributions to each other, rather than changing the
relative volumes of each channel).
I expect that the rest are not in use by anyone.
The client API exports this state via events already, but maybe it's
better to explicitly provide this property in order to facilitate use on
OSD and similar cases.
This is delayed by 300ms - before that, the status doesn't change. I
feel like it would too annoying if the status line would "flicker" on
normal seek by quickly showing and hiding the indicator.
If this code is not skipped, encoding (or dumping with --ao=pcm) will
attempt to adjust video timing to audio. Since another commit (0cce8fe6)
already avoids writing audio ahead, this didn't slow down encoding to
realtime, but it was still significantly slower.
This change should actually remove all extra sleeping.
Switching tracks caused cached_demux_control() to catch the command to
switch tracks, even if no thread was running. Thus, the tracks were
never really switched, and EOF happened immediately on playback start.
Fix it by not using the cache at all if the demuxer thread is disabled.
The cache code still has to be called somewhere, though, because it
handles stream metadata update.
Regression from today.
Got lost some time ago. Although I'm not sure if it actually does
anything on MPlayer (it exists there, but might broken, not sure).
Fixes#988 (untested).
This can just happen in the time between VO creation, and the first call
to vo_reconfig. It seems the recent threading changes exposed this bug.
Fixes#986.
Sometimes GetClientRect() appeared to fail during init, and since we
don't check GetClientRect() calls (because they're on our own window,
and logically can never fail), bogus resizes were triggered. This could
cause vo_direct3d to fail initialization.
The reason was that w32->window was set to 0 during early window
initialization: CreateWindow*() can send messages to the new window,
even though it hasn't returned yet. This means w32->window is not yet
set to our window handle, and functions in WndProc may accidentally pass
hwnd=0 to win32 API functions.
Fix it by initializing w32->window on opportunity. This also means we
always strictly expect that the WndProc is used with our own window
only.
Because why not.
This can lead to reordering of operations between seeking and track
switching (happens when the demuxer wakes up after seek and track
switching operations were queued). Do the track switching strictly
before seeks if there is a chance of reordering, which guarantees that
the seek position will always start with key frames. The reverse
(seeking, then switching) does not really have any advantages.
(Not sure if the player relies on this behavior.)
This builds but both the libmpv example and the cplayer block infinitely when
building libmpv. That's because we wait inifinitely in `dispatch_sync` as
there's no event loop in the main thread that allows for libdispatch to work..
Whiel we are at it, we should probably investigate how to use mp_dispatch
instead since it is a little lower level and could give us higher control in
building and event loop.
This fixes the fullscreen issues on Intel for me. I'm baffled by it and
don't understand why this suddenly works. Intel drivers being shit?
Windows being shit? HWND or HDC being only 97% thread-safe instead of
98%? Me missing something subtle that is not documented anywhere?
Who knows.
Now instead of creating the HDC and OpenGL context on the renderer
thread, they're created on the GUI thread. The renderer thread will
then only call wglMakeCurrent, SwapBuffers, and OpenGL standard
functions.
Probably fixes github issue #968.
We avoided reindenting this in the past to allow merging upstream changes.
In hindsight these are very unlikely and we are actually doing changes on
the code, so it's better to have the correct indentation and formatting in
our source file.
The parser can be called with dst (the target) set to NULL if the option
should be verified only. The code didn't respect this, and could result
in crashes when used in config profiles or filter sub-options.
Fixes#981.
This is probably nicer. The actual version number doesn't change (other
than the minor being incremented).
The "| 0UL" is to make the type unsigned long int, like it was before.
Instead of using a regex to match names to be exported from the libmpv
dynamic shared library, use a libmpv.def file, which lists all exported
functions explicitly.
This reduces the platform specifics in syms.py. I'm not sure if the
separate compile_sym task is still needed (it could probably be
collapsed, which would concentrate the platform specifics into one
place).
libmpv requires nm for creating the list of exported symbols (this is
done in syms.py). We should probably just make this list static instead,
but since this involves platform-specific code, for now this quick-fix
will do.
It seems the vdpau API does not support these.
Do a semi-expensive emulation of it. On the other hand, it's not like
this is a commonly-used feature. (It might be better to make --vf=flip
always copy instead of flipping it via pointer tricks - but everything
allows flipped images, and even decoders or libavfilter filters could
output them.)
The subtitle timing logic always used the demuxer's start time as video
offset. This made external subtitle files "just work" with file formats
like TS, which usually have a non-0 start time. But it was wrong for
subtitles muxed with the TS, so adjust the time offset explicitly with
external files only.
Although disabling both video and audio is surely an obscure corner
case, it's allowed, and we don't want the demuxer to skip arbitrary
packets.
Basically, make the heuristic for checking interleaved files affect
external files only.
If the compositor sends a configure event immediately after a window is
created (for example, if it implements tiling window management), mpv
will attempt to call wl_egl_window_resize before it has actually created
the egl_window, causing a crash.
Nobody uses 'c' (except accidentally) - remove.
Everyone agrees that OSD level cycling on 'o' is dumb, so map it to
show_progress instead. Cycling the OSD level is now available on 'O'.
No reason to ummap 'P' yet.
Also see issue #973.
Handle --term-playing-msg at a better place.
Move MPV_EVENT_TICK hack into a separate function. Also add some words
to the client API that you shouldn't use it. (But better leave breaking
it for later.)
Handle --frames and frame_step differently. Remove the mess from the
playloop, and do it after frame display. Give up on the weird semantics
for audio-only mode (they didn't make sense anyway), and adjust the
manpage accordingly.
If seeks take very long, it's better not to freeze up the display.
(This doesn't handle the case when decoding video frames is extremely
slow; just if hr-seek is used, or the demuxer is threaded and blocks on
network I/O.)
Use OPT_KEYVALUELIST() for all places where AVOptions are directly set
from mpv command line options. This allows escaping values, better
diagnostics (also no more "pal"), and somehow reduces code size.
Remove the old crappy option parser (av_opts.c).
Internally, there are two mechanisms which can trigger property
notification as used with "observed" properties in the client API.
The first mechanism associates events with a group of properties that
are potentially changed by a certain event. mp_event_property_change[]
declares these associations, and maps each event to a set of strings.
When an event happens, the set of strings is matched against the list of
observed properties of each client. Make this more efficient by
comparing bitsets of events instead. This way, only a bit-wise "and" is
needed for each observed property. Even better, we can completely skip
clients which have no observed properties that match.
The second mechanism just updates individual properties explicitly by
name. Optimize this by using the property index instead. It would be
nice if we could reuse the first mechanism for the second one, but
there are too many properties to fit into a 64 bit mask.
(Though the limit on 64 events might get us into trouble later...)
If OpenGL 3.x doesn't work, the fallback to legacy GL will call the
function to create the DC again, and it will assert. Just make it not
to, and also simplify the code a bit.
Fixes#974.
Almost nothing was left of it.
The only thing this commit actually removes is support for reading
input commands from stdin. But you can emulate this via:
--input-file=/dev/stdin --input-terminal=no
However, this won't work on Windows. Just use a named pipe.
Since the new hwaccel API is now merged in ffmpeg's stable release, we can
finally remove support for the old API.
I pretty much kept lu_zero's new code unchanged and just added some error
printing (that we had with the old glue code) to make the life of our users
less miserable.
Playing audio files with embedded cover art broke due to some of the
recent changes. Treat video EOF properly, and don't burn the CPU.
Disable hrseek for video in attached picture mode, since the decoder
will always produce a new image, which makes hrseek never terminate.
Fixes#970.
In encoding mode, the AO pretends to be infinitely fast (it will take
whatever we write, without ever rejecting input). Commit 261506e3 broke
this somehow. It turns out an old hack dealing with this was accidentally
dropped.
This is the hunk of code whose semantics were (partially) dropped:
if (mpctx->d_audio && (mpctx->restart_playback ? !video_left :
ao_untimed(mpctx->ao) && (mpctx->delay <= 0 ||
!video_left)))
{
int status = fill_audio_out_buffers(mpctx, endpts);
// Not at audio stream EOF yet
audio_left = status > -2;
}
This if condition is pretty wild, and it looked like it was pretty much
for audio-only mode, rather than subtle handling for encoding mode.
"Internal" events were added in the previous commits to leverage the
client API property mechanism, without making weird properties public.
But they were sent to clients too (and returned by mpv_wait_event()).
Achieve this by polling. Will be used by the OSC. Basically a bad hack -
but the point is that the mpv core itself is in the best position to
improve this later.
This is perfectly allowed, but was ignored, because it's a corner case.
It doesn't actually wait for other clients to be destroyed, but on the
other hand I think there's no way to have other clients before
initialization.
CC: @mpv-player/stable
Basically move the code from playloop.c to video.c. The new function
write_video() now contains the code that was part of run_playloop().
There are no functional changes, except handling "new_frame_shown"
slightly differently. This is done so that we don't need new a new
MPContext field or a return value for write_video() to signal this
condition. Instead, it's handled indirectly.
This also reduces some code duplication with other parts of the code.
The changfe is mostly cosmetic, although there are also some subtle
changes in behavior. At least one change is that the big desync message
is now printed after every seek.
Frames buffered in filters weren't flushed, so on EOF, the last frames
were dropped, depending on how much filters buffered. Oops.
Test case: "mpv something.jpg --vf=buffer"
In situations when the demuxer reports EOF, but immediately "recovers"
after that and returns new data, it could happen that audio sync was
skipped. Deal with this by actually entering the EOF state, instead of
assuming this will happen later.
Some ALSA plugins take non-interleaved audio, but treat it as
interleaved, which results in various funny bugs. Users keep hitting
this issue, and it just doesn't seem worth the trouble.
CC: @mpv-player/stable
Prior to this commit we had a list of key modifiers and checked against that.
Actually, the Cocoa framework has a built in way to do it and it involves
calling performKeyEquivalent: on the menu instance.
Fixes#946
cc @mpv-player/stable: this should apply with no conflicts
This happens apparently randomly with rtmp:// and after seeks. This
eventually leads to audio decoding returning an EOF status, which
basically disables audio sync. This will lead to audio desync, even if
audio decoding later "recovers" when the demuxer actually returns audio
packets.
Hack-fix this by special-casing EAGAIN.
This didn't work, because the timebase was wrong. According to the
ffmpeg doxygen, if the stream index is -1 (which is what we used), the
timebase is AV_TIME_BASE. But this didn't work, and it really expected
the stream's timebase. Quite "surprising", since this feature
(avio_seek_time) is used by rtmp only.
Fixing this properly is too hard, so hack-fix our way around it.
STREAM_CTRL_SEEK_TO_TIME is also used by DVD/BD, so a new
STREAM_CTRL_AVSEEK is added. We simply pass-through the request
verbatim.
Some files have the first audio much later into the video (for whatever
reasons). Instead of appending large amounts of silence to the audio
buffer (and refusing to sync if the audio to append is "too large"),
just wait until enough video has played.
Regression since commit 261506e3. Internally speaking, playback was
often not properly terminated, and the main part of handle_keep_open()
was just executed once, instead of any time the user tries to seek. This
means playback_pts was not set, and the "current time" was determined by
the seek target PTS.
So fix this aspect of video EOF handling, and also remove the now
unnecessary eof_reached field.
The pause check before calling pause_player() is a lazy workaround for
a strange event feedback loop that happens on EOF with --keep-open.
If an imprecise seek is issues while a precise seek is ongoing,
don't wait up to 300ms (herustistic which usually improves user
experience), but instead let it cancel the seek.
Improves responsiveness of the OSC after the previous commit.
Note that we don't do this on "default-precise" seeks, because we
don't know if they're going to be precise or not.
It probably happens relatively often that the first packet (or even the
first N packets) of a stream will fail to decode, but decoding will
eventually succeed at a later point. Before commit 261506e3, this was
handled by an explicit retry loop (although this was also for other
purposes), but with then was changed to abort on the first error. This
makes it impossible to decode some audio streams.
Change this so that errors are ignored for the first 50 packets, which
should make it equivalent to the old code.
If you for example use --audio-file, disable the external track, seek,
and enable the external track again, the playback position of the
external file was off, and you would get major A/V desync. This was
actually supposed to work, but broke at some time ago (probably commit
2b87415f). It didn't work, because it attempted to seek the stream if it
was already selected, which was always true due to
reselect_demux_streams() being called before that.
Fix by putting the initial selection and the seek together.
Seeking in .ts files (and some other formats) is too unreliable, so
there's a separate code path for this case. But it breaks hr-seek.
Maybe hr-seek could actually be enabled in this case if we're careful
enough about timestamp resets, but for now nothing changes.
With software decoding, images were uploaded to vdpau surfaces as they
were queued to the VO. This makes it slightly more complicated
(especially later on), and has no advantages - so stop doing it.
The only reason why this was done explicitly was due to attempts to keep
the code equivalent (instead of risking performance regressions). The
original code did this naturally for certain reasons, but now that we
can measure that it has no advantages and just requires extra code, we
can just drop it.
If the actual PTS is not known yet right after a seek, the "time-pos"
property will just return the seek target PTS. For this purpose, trigger
a change event to make the client API update the "time-pos" and related
properties. (MPV_EVENT_TICK triggers this update.)
Commit 261506e3 made constant seeking feel slower, because a subtle
change in the restart logic makes it now waste time showing another
video frame. The slowdown is about 20%.
(Background: the seek logic explicitly waits until a video frame is
displayed, because this makes it easier for the user to search for
something in the video. Without this logic, the display would freeze
until the user stops giving seek commands.)
Fix this by letting the seek logic issue another seek as soon as the
first video frame is displayed. This will prevent it from showing a
(useless, slow) second frame. Now it seems to be as fast as before the
change.
One side-effect is that the next seek happens after the first video
frame, but _before_ audio is restarted. Seeking is now silent. I guess
this is ok, so we don't do anything about it. Actually, I think whether
this happens is probably random; the seeking logic simply doesn't make
this explicit, so anything can happen.
Usually mp_image_params_guess_csp takes care of finding *some* default
for a video channel, but files with no video (or with extremely broken
configurations) end up leaving the colorspace information as
MP_CSP_PRIM_AUTO, which has no associated primaries.
As a result of this, color managed OSD messages could not display
because they were being color managed to match the (non-existing/absurd)
video channel. With this change, such non-spaces will have BT.709
primaries as far as color management and the OSD is concerned.
This fixes#961.
CC: @mpv-player/stable
Signed-off-by: wm4 <wm4@nowhere>
This commit makes audio decoding non-blocking. If e.g. the network is
too slow the playloop will just go to sleep, instead of blocking until
enough data is available.
For video, this was already done with commit 7083f88c. For audio, it's
unfortunately much more complicated, because the audio decoder was used
in a blocking manner. Large changes are required to get around this.
The whole playback restart mechanism must be turned into a statemachine,
especially since it has close interactions with video restart. Lots of
video code is thus also changed.
(For the record, I don't think switching this code to threads would
make this conceptually easier: the code would still have to deal with
external input while blocked, so these in-between states do get visible
[and thus need to be handled] anyway. On the other hand, it certainly
should be possible to modularize this code a bit better.)
This will probably cause a bunch of regressions.
Apparently this switch means all mouse input should be strictly
rejected. Some VO backends (such as X11) explicitly disable all mouse
events if this option is set, but others don't. So check them in
input.c, which increases consistency.
Follow up on commit 760548da. Mouse handling is a bit confusing, because
there are at least 3 coordinate systems associated with it, and it
should be cleaned up. But that is hard, so just apply a hack which gets
the currently-annoying issue (VO backends needing access to the VO) out
of the way.
Add an option that enables using native PulseAudio auto-updated timing
information, instead of the manual calculations added in mplayer2 times.
You can use --ao=pulse:no-latency-hacks to enable the new code. The code
is almost the same as the code that was removed with commit de435ed5,
but I didn't readd some bits I didn't understand. Likewise, the option
will disable the code added with that commit.
In my tests this seemed to work well, though the A/V sync display looks
funny when seeking.
The default is still the old behavior.
See issue #959.
This was needed by very old (0.9) versions only. Get rid of it.
Unfortunately, I can't cross-check with the original bug report, since
the bug URL leads to this:
Internal Server Error
TracError: IOError: [Errno 2] No such file or directory: '/home/lennart/svn/trac/pulseaudio/VERSION'
The windows message loop now runs in a separate thread. Rendering,
such as with Direct3D or OpenGL, still happens in the main thread.
In particular, this should prevent the video from freezing if the
window is dragged. (The reason was that the message dispatcher won't
return while the dragging is active, so mpv couldn't update the
video at all.)
This is pretty "rough" and just hacked in, and there's no API yet to
make this easier for other backends. It will be cleaned up later
once we're sure that it works, or when we know how exactly it should
work. One oddity is that OpenGL is actually completely managed in the
renderer thread, while e.g. Cocoa (which has its own threading code)
creates the context in the GUI thread, and then lets the renderer
thread access it.
One strange issue is that we now have to stop WM_CLOSE from actually
closing the window. Instead, we wait until the playloop handles the
close command, and requests the VO to shutdown. This is done mainly
because closing the window apparently destroys it, and then WM_USER
can't be handled anymore - which means the playloop has no way to
wakeup the GUI thread. It seems you can't really win here... maybe
there's a better way to have a thread receive messages with and
without a window, but I didn't find one yet.
Dragging the window (by clicking into the middle of it) behaves
strangely in wine, but didn't before the change. Reason unknown.
VO backends which are or will run in their own thread have a problem
with vo_mouse_movement() calling vo_control(). Restrict this to VOs
which actually need this.
win32 does not provide a proper per-window context pointer. Although it
does allow passing a user-chosen value to WM_CREATE/WM_NCCREATE, this
is not enough - the first message doesn't even have to be WM_NCCREATE.
This gets us in trouble later on, so go the easy route and just use a
TLS variable.
__thread is gcc specific, but Windows is a very "special" platform
anyway. We support only MinGW and Cygwin on it, so who cares. (C11
standardizes __thread as _Thread_local; we can use that later.)
Plan 9 has a very interesting synchronization mechanism, the
rendezvous() call. A good property of this is that you don't need to
explicitly initialize and destroy a barrier object, unlike as with e.g.
POSIX barriers (which are mandatory to begin with). Upon "meeting", they
can exchange a value.
This mechanism will be nice to synchronize certain stages of
initialization between threads in the following commit.
Unlike Plan 9 rendezvous(), this is not implemented with a hashtable,
because that would require additional effort (especially if you want to
make it actually scele). Unlike the Plan 9 variant, we use intptr_t
instead of void* as type for the value, because I expect that we will be
mostly passing a status code as value and not a pointer. Converting an
integer to void* requires two cast (because the integer needs to be
intptr_t), the other way around it's only one cast.
We don't particularly care about performance in this case either. It's
simply not important for our use-case. So a simple linked list is used
for waiters, and on wakeup, all waiters are temporarily woken up.
This shouldn't change anything. But it's worth making this explicit,
since it's very subtle and unintuitive: if the X parameter is the
magic value CW_USEDEFAULT, then the Y parameter is used as nCmdShow
parameter to ShowWindow(). And in our case, this is SW_HIDE (0),
because we want to create a hidden window.
This looked a bit overcomplicated. We don't care about the window
position (it should always be 0/0, unless the parent program moved it,
which it shouldn't). We don't care about the global on-screen position.
Also, we will just retrieve a WM_SIZE message if our window is resized,
and we don't need to update it manually.
The only thing we have to do is making sure our window fills the parent
window completely.
CS_OWNDC will make GetDC() always return the same HDC. This might
become a problem when OpenGL rendering and window management are
on different threads. Although I'm not too sure about this; our
code never requests a HDC outside of the OpenGL backend, and it
depends on whether win32 will internally request DCs. But in any
case, this seems to be cleaner.
Move the GL pixelformat setup code to gl_w32.c, where it's actually
needed. This also fixes that SetPixelFormat() should be called only
once, and not every time video params change.
These mostly describe self-explanatory things, and fail to explain
actually tricky things. Which means you just waste your time reading
this, and have to figure it out from the code anyway.
Preparation for moving win32 windowing to a separate thread.
The codesize is reduced a bit, because some small functions are
inlined, which reduces noise.
The main change is that now most functions use the private struct
directly, instead of accessing it indirectly through vo->w32.
Accesses to vo are minimalized.
The final goal is adding some sort of new windowing backend API. It
would be cleaner to use that as context pointer for all functions
(like struct vo was previously used), but since this is work in
progress, we just go with this commit.
ao_null is used to stop autoprobing (if all AOs before fail to init).
After it come things like ao_pcm, which should never be automatically
selected.
Remove a certain theoretically possible failure case, and force "some"
fallback.
mp_make_wakeup_pipe() always fails on win32. If this call fails on Linux
(and e.g. ao_alsa is used), this will probably burn CPU since poll()
won't work on the invalid file descriptor, but whatever, the failure
case is obscure enough.
Actually free the old mmap region when readding an overlay of the same
ID without removing it before. (This is explicitly documented as
working.)
Replace the OSD atomically. Before this commit, the overlays were
removed and then readded to avoid synchronization problems.
Simplify the code: now there is no weird mapping between index and ID.
The OSD sub-bitmap list still needs to be prepared to skip unused IDs
(since each sub-bitmap list entry must be in use), but the code for this
is relatively separated now.
Fixes issue #956.
Currently entries are added after the current playlist element. This is kinda
confusing, more so given that "loadfile append" appends at the end of the
playlist.
Accidentally broken in b6af44d3. For ad_lavc (and in general), the PTS
was not updated correctly when filtering only parts of audio frames,
and for ad_mpg123 and ad_spdif the PTS was additionally offset by the
frame size.
This could lead to incorrect time display, and possibly broken A/V sync.
Execute the format change based on whether we logically detected EOF
(after filters), instead of when the decode buffer was drained. It's
slightly cleaner. (The requirement of len>0 existed before.)
Don't return an EOF code if there's still buffered data.
Also, don't call demux_stream_eof() in the playloop. There's probably
nothing wrong with it, but it's cleaner not to use it.
Also give AD_EOF its own value, so that a decoding error doesn't drain
audio by causing an EOF condition.
Move a function call, which does not change semantics.
Write the extra buffer sample count in a more straight-forward way; the
old code was not meaningful in any way (anymore).
It's true that the decoder can successfully decode, but return no data
(for various reasons). We don't need to handle this specially, though.
We just let the decoder decode some more data. This doesn't increase the
danger of an endless loop either, because audio_decode() already calls
this function until enough is decoded.
"loadfile filename append-play" will now always append the file to the
playlist, and if nothing is playing yet, start playback. I don't want to
change the semantics of "append" mode, so a new mode is needed.
Probably fixes issue #950.
This allows using external subtitle files with e.g. transport stream
files that don't start at time 0.
Note that if the .ts file has timestamp resets, everything goes south.
But I guess this was already the case before, unless there are external
subtitle files that also include timestamp resets, which is unlikely.
(On the other hand, you could for example expect that it works with
embedded DVB subtitles, that were somehow captured from the same stream
and use the same timestamps.)
Useful for Windows stuff. Actually, ENCA support should catch this, but,
well, whatever, everyone seems to hate ENCA.
Detection with BOM is trivial, although it needs some hackery to
integrate it with the existing autodetection support. For one, change
the default value of --sub-codepage to make this easier.
Probably fixes issue #937 (the second part).
The video flushing logic was broken: if there are no more packets,
decode_image() will feed flush packets to the decoder. Even if an image
was produced, it will return the demuxer EOF state, and since commit
7083f88c, this EOF state is returned to the caller, which is incorrect.
Revert this part of the change, and explicitly check for VD_WAIT (the
bogus change was intended to forward this error code to the caller).
Also, turn the "r < 1" into something equivalent that doesn't rely on
the exact value of VD_EOF. "r < 0" is ok, because at least here, errors
are always negative.
The travis guys were so nice to activate multi OS support for us (it's a beta
feature). So now we build on OS X ass well to check for OS X specific breakage.
Later I might investigate further and build with the minimum supported SDK
version so that we don't break older systems by using newer Cocoa features.
This commit mainly moves the initial decoding of data (done to probe the
audio format) to generic code. This will make it easier to make audio
decoding non-blocking in a later commit.
This commit also changes how decoders return data: instead of having
them write the data into a prepared buffer, they return a reference to
an internal buffer (by setting dec_audio.decoded). This makes it
significantly easier to handle audio format changes, since the decoders
don't really need to care anymore.
If the decoder didn't set a samplerate, it was initialized from the
container samplerate.
This probably didn't make much sense, because it's passed to the
decoder on initialization (so it could definitely use it). It's an
artifact from commit 66a9eb57 (which removed some Matroska-specific non-
sense), and I've never seen it actually happen since it was made into a
warning. Just get rid of it.
This tells the demuxer thread that it should seek, instead of waiting
until the demuxer thread is ready.
Care has to be taken about the state between seek request and actual
seeking: newly demuxed packets have to be discarded. We can't just
flush when doing the actual seek, because the user thread could read
these packets.
I'm wondering if this could lead to issues due to relaxed ordering of
operations. But it should be fine, since seeking influences packet
reading only, and seeking is always strictly done before that.
Currently, this will have no advantages; unless audio is disabled. Then
seeking as well as normal playback can be non-blocking.
The MPlayer style syntax ("-mf fps=10:type=png") was removed a while
ago, and now only the flat variants ("--mf-fps=10" etc.) work.
CC: @mpv-player/stable
Move a condition somewhere else, which makes it conceptually simpler.
Also, the assignment to full_audio_buffers removed with this commit was
dead, and its value never used.
Fatal errors in the vidoe chain (such as failing to initialize the video
chain) disable video decoding. Restart the playloop, instead of just
continuing the current iteration.
The resulting behavior should be the same, but it gets rid of possible
corner cases.
Instead of starting to fill the packet queue if at least 1 stream is
selected, wait until there is at least 1 stream had new packets
requested.
In theory this is cleaner, because it allows you to e.g. do a seek and
then reselect streams without losing packets. Seeking marks all streams
as inactive, and without this new logic, the thread would read new
packets anyway right after seek.
Broken by commit 1301a907. This commit added demuxer threading, and
changed some other things to make them simpler and more orthogonal. One
of these things was ntofications about streams that appear during
playback. That's an obscure corner case, but the change made handling of
it as natural as normal initialization.
This didn't work for two reasons:
1. When playing an ordered chapters file where the initial segment was
not from the main file, its streams were added to the track list. So
they were printed twice, and switching to the next segment didn't work,
because the right streams were not selected.
2. EDL, CUE, as well as possibly certain Matroska files don't have any
data or tracks in the "main" demuxer, so normally the first segment is
picked for the track list. This was simply broken.
Fix by sprinkling the code with various hacks.
This called demux_flush(), but that doesn't make any sense with an
asynchronously running demuxer. It would just keep reading and add new
packets again. Explicitly pause the demuxer, so that this can't happen.
Also, when flushing, data will be missing, so the decoders should
always be reinitialized, even if the operation fails.
This fixes the same symptom as the previous commit, but when the demuxer
thread is enabled. In this case, if nothing was read from the demuxer,
the STREAM_CTRLs weren't updated either. To the player, this looked like
the stream cache was never making progress, so playback was kept paused.
Commit dc00b146, which disables polling by default, missed another
instance of polling: when the player pauses automatically on low cache.
This could lead to apparent freezes when playing network streams.
It can happen that read_packet() doesn't read a packet, even if it
succeeds. Typically this is because a packet was read, but then thrown
away, because it's not part of a selected stream. The result would be a
bogus EOF condition.
Fix by explicitly checking for EOF.
In corner cases, it might be possible that a demux_read_packet_async()
call fails to make the demuxer thread to read more packets.
If a packet is queued, the function will simply return a packet, without
marking the stream as active. As a consequence, read_packet() might
decide not to read any further packets, and the demuxer will never read
a packet and wake up the playback thread.
This was originally done to align it with demux_read_packet() semantics;
just drop this.
demux_read_any_packet() attempts to call read_packet(), but if no stream
is active, it can decide not to read anything. The function will return
NULL, which implies EOF. Fix this by explicitly
setting demux_stream->active if needed.
Also use dequeue_packet() instead of demux_read_packet(), because it's
cleaner. (Shouldn't change behavior.)
Possibly fixes#938.
We told the demuxer that a pipe (if stream cache is enabled) is
seekable. This is because the stream cache is technically seekable, it's
just that seeking may fail at runtime if a non-cached byte range is
requested.
This caused libavformat to issue seeks on initialization (at least when
piping mp4 youtube videos). Initialization failed completely after
spamming tons of error messages.
So, if an unseekable stream is cached, tell the demuxer that the file is
not seekable. This gets reversed later (when printing a message about
caching an unseekable stream), so the user can still try his luck by
issuing a seek command. The important part is that libavformat
initialization will not take code paths that will unnecessarily seek for
whatever reasons.
CC: @mpv-player/stable: regression from 0.3.x
In my opinion this is not really necessary, since there's only a single
user of update_video(), but others reading this code would probably hate
me for using magic integer values instead of symbolic constants.
This should be a purely cosmetic commit; any changes in behavior are
bugs.
Instead of blocking on the demuxer when reading a packet, let packets be
read asynchronously. Basically, it polls whether a packet is available,
and if not, the playloop goes to sleep until the demuxer thread wakes it
up.
Note that the player will still block for I/O, because audio is still
read synchronously. It's much harder to do the same change for audio
(because of the design of the audio decoding path and especially
initialization), so audio will have to be done later.
It was easy to get into a wakeup feedback loop on EOF. The reason that
EOF is complicated is that we try to retry reading when EOF is reached,
in case the EOF state actually disappears (e.g. when watching a
currently downloaded file).
This feature is probably worthless, since in practice you have to do a
seek to "unstuck" it anyway, but since the old code also did this, we
want to keep this behavior for now.
Avoid the feedback loop by introducing another EOF flag (last_eof), that
contains the actual previous EOF state, and is not overwritten when
retrying reading. Wakeup is skipped if the EOF state didn't change.
Also, actually call the wakeup callback when EOF is detected.
The line that adds "ds->active = false;" actually does nothing, but in
theory it's cleaner.
Mouse cursor handling, --heartbeat-cmd, and OSD messages basically
relied on polling. For this reason, the playloop always used a small
timeout (not more than 500ms).
Fix these cases, and raise the timeout to 100 seconds. There is no
reason behind this number; for this specific purpose it's as close to
infinity as any other number.
On MS Windows, or if vo_sdl is used, the timeout remains very small.
In these cases the GUI code doesn't do proper event handling in the
first place, and fixing it requires much more effort.
getch2_poll() still does polling, because as far as I'm aware no event-
based way to detect this state change exists.
The old FFmpeg API and the new Libav API disagree about mp4 display
rotation direction. Well, whatever, fix it trial-and-error-style.
CC: @mpv-player/stable: add
This adds a thread to the demuxer which reads packets asynchronously.
It will do so until a configurable minimum packet queue size is
reached. (See options.rst additions.)
For now, the thread is disabled by default. There are some corner cases
that have to be fixed, such as fixing cache behavior with webradios.
Note that most interaction with the demuxer is still blocking, so if
e.g. network dies, the player will still freeze. But this change will
make it possible to remove most causes for freezing.
Most of the new code in demux.c actually consists of weird caches to
compensate for thread-safety issues (with the previously single-threaded
design), or to avoid blocking by having to wait on the demuxer thread.
Most of the changes in the player are due to the fact that we must not
access the source stream directly. the demuxer thread already accesses
it, and the stream stuff is not thread-safe.
For timeline stuff (like ordered chapters), we enable the thread for the
current segment only. We also clear its packet queue on seek, so that
the remaining (unconsumed) readahead buffer doesn't waste memory.
Keep in mind that insane subtitles (such as ASS typesetting muxed into
mkv files) will practically disable the readahead, because the total
queue size is considered when checking whether the minimum queue size
was reached.
There was confusion about what should go into audio pts calculation and
what not (mainly due to the audio push thread). This has been fixed by
using the playing - not written - audio pts (which properly takes into
account the ao's buffer), and incrementing the samples count only by the
amount of samples actually taken from the buffer (unfortunately this
now forces us to keep the lock too long for my taste).
For OGG audio files, we usually merge the per-stream metadata back to
the file-global metadata. Don't do that for OGM, because with OGM most
metadata is actually per-stream.
Until now, changing the properties showed the VO colorspace parameters
on OSD. This didn't work quite well, because it showed the VO parameters
_before_ the change. This is because at least one video frame with the
new parameters has to be shown, and this doesn't happen right after
changing the property, but a bit later.
Also fix a random typo in unrelated code.
The final goal is all mp_msg calls produce complete lines. We want this
because otherwise, race conditions could corrupt the terminal output,
and it's inconvenient for the client API too. This commit works towards
this goal. There's still code that has this not fixed yet, though.
demux_seek() actually doesn't return seek success. Instead, it fails if
the demuxer is flagged as unseekable (but this is checked explicitly at
the beginning of this function), or if the seek target PTS is
MP_NOPTS_VALUE (which can never happen).
No reason to wait until the audio has been played. This isn't a problem
with gapless audio disabled, and since gapless is now default, this
behavior might be perceived as regression.
CC: @mpv-player/stable
Logic for this was missing from pull.c. For push.c it was missing if the
driver didn't support it. But even if the driver supported it (such as
with ao_alsa), strange behavior was observed by users. See issue #933.
Always check explicitly whether the AO is in paused mode, and if so,
don't drain.
Possibly fixes#933.
CC: @mpv-player/stable
libdvdnav can actually jump into the middle of the DVD (e.g. scene
selection menus do that). Then time display is incorrect: we start from
0, even though playback time is somewhere else. This really matters when
seeking. If the display time mismatches, a small relative seek will
apparently jump to the beginning of the movie.
Fix this by initializing the PTS stuff on opening. We have to do this
after some small amount of data has been read from the stream (because
libdvdnav is crap and doesn't always update the time between seeks and
the first read; also see STREAM_CTRL_GET_CURRENT_TIME remarks in
cache.c; although this was not observed when testing with scene
selection menus). On the other hand, we want to do it before opening the
demuxer, because that will read large amounts of data and likely will
change the stream position.
Also see commit 49813670.
Happens when playing from a pipe.
Note that seeking forward doesn't work. It would be possible to create a
workaround for that by reading and skipping data until the target
position is reached (and writing the skipped data into the cache file),
but I'm not sure about that.
Fixes#928.
CC: @mpv-player/stable
There is no standard mechanism for detecting endianess. Doing it at
compile time in a portable way is probably hard. Doing it properly
with a configure check is probably hard too. Using the endian
definitions in <sys/types.h> (usually includes <endian.h>, which is
not available everywhere) works under circumstances, but the previous
commit broke it on OSX.
Ideally all code should be endian dependent, but that is not possible
due to the dependencies (such as FFmpeg, some video output APIs, some
audio output APIs).
Create a header osdep/endian.h, which contains various fallbacks.
Note that the last fallback uses libavutil; however, it's not clear
whether AV_HAVE_BIGENDIAN is a public symbol, or whether including
<libavutil/bswap.h> really makes it visible. And in fact we don't want
to pollute the namespace with libavutil definitions either. Thus it's
only the last fallback.
_GNU_SOURCE defines the kitchen sink, and also prefers glibc definitions
where glibc and POSIX conflict. Even though POSIX is worth less than
toilet paper, we still prefer the POSIX definitions.
rar.c needs asprintf(), which is _GNU_SOURCE-only. So we define
_GNU_SOURCE too specifically for this file.
This approach is similar to what other vo_opengl backends do. It can also be
used in the future to create another cocoa backend that renders offscreen
with IOSurfaces or FBOs.
Technically needed, but not strictly. It seems it works without in
practice, because demux_lavf.c reads exactly one packet for fill_buffer
call, so there are never packets queued.
We used a complicated and approximate method to cache the stream
timestamp, which is basically per-byte. (To reduce overhead, it was only
cached per 8KB-block, so it was approximate.)
Simplify this, and read/keep the timestamp only on discontinuities. This
is when demux_disc.c actually needs the timestamp.
Note that caching is currently disabled for dvdnav, but we still read
the timestamp only after some data is read. libdvdread behaves well, but
I don't know about libbluray, and the previous code also read the
timestamp only after reading data, so try to keep it safe.
Also drop the start_time offset. It wouldn't be correct anymore if used
with the cache, and the idea behind it wasn't very sane either (making
the player to offset the initial playback time to 0).
Key bindings are decided on the "down" event, so if the prefix is not
unique, the first/shortest will be used (e.g. when both "a" and "a-b"
are mapped, "a" will always be chosen).
This also breaks combining multiple mouse buttons. But it seems users
expect it to work, and it's indeed a bit strange that it shouldn't work,
as mouse bindings are emitted on the key "up" event, not "down" (if the
shorter binding didn't emit a command yet, why shouldn't it be
combinable).
Deal with this by clearing the key history when a command is actually
emitted, instead of when a command is decided. This means if both
MOUSE_BTN0 and MOUSE_BTN0-MOUSE_BTN1 are mapped, the sequence of holding
down BTN0 and then BTN1 will redecide the current command. On the other
hand, if BTN0 is released before BTN1 is pressed, the command is
emitted, and the key history is deleted. So the BTN1 press will not
trigger BTN0-BTN1.
For normal keys, nothing should change, because commands are emitted on
the "down" event already, so the key history is always cleared.
Might fix#902.
CC: @mpv-player/stable (if this fix is successful)
Doesn't work quite right, and will pause for the latency duration after
seeking. Some users use --ao=null to disable audio (even though they
should probably use --no-audio), and this use-case is broken by this
issue too.
CC: @mpv-player/stable
The original goal was just adding backtraces, however making the code
safe (especially wrt. to out of memory Lua errors) was hard. So this
commit also restructures error handling to make it conceptually simpler.
Now all Lua code is run inside a Lua error handling, except the calls
for creating and destroying the Lua context, and calling the wrapper C
function in a safe way.
The new error handling is actually conceptually simpler and more
correct, because you can just call any Lua function at initialization,
without having to worry whwther it throws errors or not.
Unfortunately, Lua 5.2 removes lua_cpcall(), so we have to emulate it.
There isn't any way to emulate it in a way that works the same on 5.1
and 5.2 with the same semantics in error cases, so ifdeffery is needed.
The debug.traceback() function also behaves weirdly differently between
the Lua versions, so its output is not as nice as it could be (empty
extra line).
This should work now, at least kind of. Note that actual success depends
on the behavior of the underlying lib{dvd{nav,read},bluray}
implementation, which could go very wrong.
In the worst case, it could happen that the underlying implementation
seeks a long time before the seek target time. In this case, the player
will just decode video until the target time is reached, even if that
requires e.g. decoding 30 mintues of video before refreshing.
In the not-so-bad but still bad case, it would just miss the seek
target, and seek past it.
In my tests, it works mostly ok, though. Seeking backwards usually
fails, unless something like --hr-seek-demuxer-offset=1 is used (this
makes it seek to 1 second before the target, which may or may not be
enough to compensate for the DVD/BD imprecision).
This is a pretty big change. Instead of doing a half-hearted passthrough
of the playback timestamp, we attempt to rewrite the raw MPEG timestamps
such that they match with the playback time.
We add the offset between raw start timestamp and playback time to the
packet timestamps. This is the easy part; but the problem is with
timestamp resets. We simply detect timestamp discontinuities by checking
whether they are more than 500ms apart (large enough for all video
faster than 2 FPS and audio with reasonable framesizes/samplerates), and
adjust the timestamp offset accordingly.
This should work pretty well. There may be some problems with subtitles.
If the first packet after a timestamp reset is a subtitle instead of
video, it will fail. Also, selecting multiple audio or video streams
won't work (but mpv doesn't allow selecting several anyway). Trying to
demux subtitles with no video stream enabled will probably fail.
Untested with Bluray, because I have no Bluray sample.
Background:
libdvdnav/libdvdread/libbluray make this relatively hard. They return a
raw MPEG (PS/TS) byte stream, and additionally to that provide a
function to retrieve the current "playback" time. The playback time is
what should be displayed to the user, while the MPEG timestamps can be
completely different. Even worse, the MPEG timestamps can reset. Since
we use the libavformat demuxer (instead of parsing the MPEG packets in
the DVD/BD code), it's hard to associate between these timestamps. As a
result, the time display is special cased in the playloop, and of low
quality (updates only all 1 or 2 seconds, sometimes is incorrect). The
fact that the stream cache can be between demuxer and the stream source
makes things worse.
All the libs seem to provide an event that tells whether timestamps are
resetting. But since this signalling is byte based, it's hard to connect
it to the demuxed MPEG packets. It might be possible to create some sort
of table mapping file positions to discontinuities and new timestamps.
(For simplicity, this table could be 2 entries large, sufficient to
catch all discontinuities if the distance between them is larger than
the total buffering.)
It can happen that demux_fill_buffer() adds more than 1 packet, and then
the packets would add up. Affects demux_disc.c only (nothing else uses
this function).
When seeking, we violently destroy the filter, because vapoursynth has
no proper API for terminating a video with unknown frame count. This
looks like an error to vapoursynth, and the error is returned via the
frame callbacks. The bug is that we remember this error state across
reinitialization, so on the first filter call after reinitialization, we
thought filtering the current frame failed. This caused a shift by 1
frame on each seek.
CC: @mpv-player/stable
Not all compilers on all platforms have atomics available (even if they
could, technically speaking).
We don't use atomics that much, only the following things rely on it:
1. the audio pull code, and all audio outputs using it
2. updating global msg levels
3. reading log messages through the client API
Just disable 1. and 3. if atomics are not available. For 2., using fake-
atomics isn't too bad; at worst, message levels won't properly update
under certain situations (but most likely, it will work just fine).
This means if atomics are not available, the client API function
mpv_request_log_messages() will do nothing.
CC: @mpv-player/stable
This should be unneeded, and the packet position is already sufficient
for this case.
Accessing the stream position directly is going to be a problem when the
stream is accessed from another thread later.
Suggested by tholin on github issue #882.
This is not entirely clean, but the fields we're accessing might be
considered internal to libavformat. On the other hand, existence of the
fields is guaranteed by the ABI, and nothing in the libavformat doxygen
suggestes they're not allowed to be accessed.
CC: @mpv-player/stable
DVD and Bluray (and to some extent cdda) require awful hacks all over
the codebase to make them work. The main reason is that they act like
container, but are entirely implemented on the stream layer. The raw
mpeg data resulting from these streams must be "extended" with the
container-like metadata transported via STREAM_CTRLs. The result were
hacks all over demux.c and some higher-level parts.
Add a "disc" pseudo-demuxer, and move all these hacks and special-cases
to it.
(Again.)
This time, we simply make it event-based, as it should be. This is done
for both demuxer metadata and stream metadata.
For some ogg-over-icy streams, 2 updates are reported on stream start.
This is because libavformat reports an update right on start, while
including the same info in the "static" metadata. I don't know if that's
a bug or a feature.
It's unlikely that files with multiple audio tracks and with replaygain
actually happen, but this change might help avoid minor corner cases
with later changes.
Recently, libavformat added demuxers to open image files like normal
demuxers. This is a good thing, but for now they interfere with the
operation of demux_mf. Add them to the blacklist until there is a proper
solution.
(The list doesn't contain _all_ recognized image formats, just those
that might interfere with demux_mf.)
CC: @mpv-player/stable
This returned a stream error value directly to libavformat, which can't
make sense. For example STREAM_ERROR (0) means success in libavformat
error codes. (The meaning of the libavformat read_seek return value is
underdocumented too.)
The intention is to make it obvious which mpv releases certain changes
will apply to.
Also attempt to fix RST formatting of the list. This is not very proper,
but probably good enough.
Cast away the "extra" bits (since apparently Window/XID is always
32 bit unsigned). This is not striclty needed, because you're not
supposed to pass garbage to --wid, just because the upper bits are
possibly not interpreted. But if you do so, this change increases
consistency in behavior and removes a strange behavior that was
thought to be a bug.
Also see github issue #906.
Don't use _x_arguments, as we don't support X arguments.
Get rid of -s, because we don't support multiple single-letter options
in one argument.
Add -S, because we ignore options after "--".
Completion now uses "--opt=value" instead of "--opt value". Once the
user presses space and starts a new argument, the option just
completed is out of the picture, whether or not it was given an
argument. This handles options with no arguments or optional arguments
much better; previously, completing such an option would effectively
disable completion for the next argument.
Custom completed options such as "--ao" and friends will no longer
claim to consume an extra argument.
Previous code was completly wrong. This still doesn't report the device
latency, but we report the buffer latency (as before the AO refactoring) and
the AudioUnit's latency (this is a new 'feature').
Apparently we can also report the device actual latency and we should also
calculate the actual sample rate of the audio device instead of using the
nominal sample rate, but I'll leave this for a later commit.
The mplayer1/2/mpv CoreAudio audio output historically contained both usage
of AUHAL APIs (these go through the CoreAudio audio server) and the Device
based APIs (used only for output of compressed formats in exclusive mode).
The latter is a very unwieldy and low level API and pretty much forces us to
write a lot of code for little workr. Also with the widespread of HDMI, the
actual need for outputting compressed audio directly to the device is getting
lower (it was very useful with S/PDIF for bandwidth constraints not allowing
a number if channels transmitted in LPCM).
Considering how invasive it is (uses hog/exclusive mode), the new AO
(`ao_coreaudio_device`) is not going to be autoprobed but the user will have
to select it.
When resizing the cache, the buffer for the DVD timestamps is
initialized with 0. This causes the player to always return playback
position 0 with any file format (not just DVD), and also makes all
relative seeks relative to position 0. Fix this by clearing the
timestamps explicitly.
Closes#899.
CC: @mpv-player/stable
Apparently clearing on every map can cause problems with vdpau when
switching virtual desktops and such. This was observed with at least
XMonad and nvidia-340.17. It's not observed on some other setups without
XMonad.
It's not clear why this happens. Normally, the window background is not
saved, so clearing should have no additional affect. It's a complete
mystery. Possible, the use of legacy X drawing commands (used to clear
the window) interferes with vdpau operation in non-trivial ways.
Work this around by clearing on initial map only. This probably only
hides the underlying issue, but good enough.
Closes#897.
CC: @mpv-player/stable
This also means that the printed size is always rounded to KBs, because
the cache properties are returned in KB. I think this doesn't matter
much. But if it does, the cache properties should probably changed to
return bytes in the first place.
Something like "char *s = ...; isdigit(s[0]);" triggers undefined
behavior, because char can be signed, and thus s[0] can be a negative
value. The is*() functions require unsigned char _or_ EOF. EOF is a
special value outside of unsigned char range, thus the argument to the
is*() functions can't be a char.
This undefined behavior can actually trigger crashes if the
implementation of these functions e.g. uses lookup tables, which are
then indexed with out-of-range values.
Replace all <ctype.h> uses with our own custom mp_is*() functions added
with misc/ctype.h. As a bonus, these functions are locale-independent.
(Although currently, we _require_ C locale for other reasons.)
Some of these might be security relevant.
The RealAudio code was especially bad. I'm not sure if all RealAudio
stuff still plays correctly; I didn't have that many samples for
testing. Some checks might be unnecessary or overcomplicated compared
to the (obfuscated) nature of the code.
CC: @mpv-player/stable
rgain is not an additive value. It's a multiplier/gain.
Previous behaviour produced negative level values in some cases
(when rgain < 1.0) which caused volume to be louder when its value
was lowered.
CC: @mpv-player/stable
Signed-off-by: Mohammad Alsaleh <CE.Mohammad.AlSaleh@gmail.com>
Signed-off-by: wm4 <wm4@nowhere>
Also allows it to deal with NULL return values, which currently is not
needed, but may or may not be required at some point in the future (what
if malloc fails).
Until now, the config functions added various allocations to the user-
provided talloc context. Make it so that they're all under the returned
allocation instead. This allows avoiding having to create an extra
temporary context for some callers, and also avoids adding random memory
leaks by accidentally passing a NULL context.
mp_find_all_config_files() has to be changed not to return a pointer
into the middle array for this to work. Make it add paths in order
(instead of reverse), and then reverse the array entries after that.
Also remove the declarations for the win-specific private functions.
Remove STRNULL(); it's barely needed anymore and the functions are
not called with NULL filenames anymore.
This means normally the XDG config dir will be used. But if the old
config dir (~/.mpv) exists and the XDG config dir does not, then don't
create it.
To simplify the code, also make mp_path_exists() accept NULL paths. In
that case it's considered as not existing. (Funnily, on Linux this
already worked, because the string is passed directly to the kernel,
and the kernel will just return EFAULT on invalid memory.)
It's better to keep the logic in one place.
Also drop that a broken config file aborts loading of the player. I
don't see much reason for this, and it inflates the code slightly.
Search $XDG_CONFIG_HOME and $XDG_CONFIG_DIRS for config files.
This also negates the need to have separate user and global variants of
mp_find_config_file()
Closes#864, #109.
Signed-off-by: wm4 <wm4@nowhere>
These consult the vertical resolution, matching against 576 for
PAL and 480/486 for NTSC. The documentation has also been updated.
Signed-off-by: wm4 <wm4@nowhere>
Notably, we now conform to SMPTE 428-1-2006 when decoding XYZ12 input,
and we can support rendering intents other than colorimetric when
converting between BT.709 and BT.2020, like with :srgb or :icc-profile.
With this change, XYZ input is directly converted to the output
colorspace wherever possible, and to the colorspace specified by the
tags and/or --primaries option, otherwise.
This commit also restructures some of the CMS code in gl_video.c to
hopefully make it clearer which decision is being done where and why.
This also avoids an extra matrix multiplication when using :srgb, making
that path both more efficient and also eliminating more hard-coded
values.
In addition, the previously hard-coded XYZ to RGB matrix will be
dynamically generated.
This add support for reading primary information from lavc, categorized
into BT.601-525, BT.601-625, BT.709 and BT.2020; and passes it on to the
vo. In vo_opengl, we always generate the 3dlut against the wider BT.2020
and transform our source into this colorspace in the shader.
For remarks, pretty much see the manpage additions. Could help with
network streams that require too much seeking (maybe), or might be
extended to help with the use case of watching and downloading a file
at the same time.
In general, it might be a useless feature and could be removed again.
It seems it's generally cleaner to leave this stuff to the BSDs.
Additionally, the NetBSD part wasn't even correct, because it made the
compiler prefer the system include path before local include files.
It is reasonably stable, so all further changes will be versioned.
Also change how the libmpv version number is generated. Fix the patch
version number to 0; I don't think we have a use for this. In
particular, the version doesn't version mpv, just the client API.
Do this simply by clearing the mapped buffer on every draw_image() call
without an actual video frame. (Maybe this is a bit expensive, but at
least not more expensive than regular video display.)
Clear the texture on reconfig(). (We could probably also do this simpler
with a flag, but this is actually less complicated - except that we move
the code to "map" a texture to a separate function.)
With the change to merge osd drawing into video frame drawing, some
bogus logic got in: they skipped drawing the OSD if no video frame is
available. This broke --no-video --force-window mode.
Until now, bitmap subtitles were decoded at "some" point, and then
simply replaced the old subtitle. Although the subtitle is selected
by time (PTS), it could happen that a subtitle was replaced too early.
One consequence is that this might lead to flicker even if the
subtitles are timed to follow each other without a gap (although most
subtitles are explicitly timed to introduce such a gap). With this
commit the past 4 subtitles are kept (instead of 1), so that the
correct one can be picked by time. This should fix the aforementioned
cases, but more importantly will allow demuxing/decoding and video
display to be somewhat asynchronous.
Still missing: somehow making sure the correct range of decoded
subtitles is available, instead of just passing along whatever comes
from the demuxer, and hoping that 4 queued subtitles are enough. But it
should certainly be good enough for now.
This removes a check that resets the subtitles if the PTS is 5 minutes
before the end of the current subtitle; this is probably not needed.
This fixes the build on platform where the atomic calls can't be turned into
lock-free instructions and thus need the external libatomic library (e.g. mips).
Make sure every video filter has valid parameters for input and output.
(This also ensures we don't take possibly invalid decoder output, or
feed invalid decodr/filter output to VOs.)
Also, the updated image size check now (almost) works like the
corresponding check in FFmpeg.
Until now, failure to allocate image data resulted in a crash (i.e.
abort() was called). This was intentional, because it's pretty silly to
degrade playback, and in almost all situations, the OOM will probably
kill you anyway. (And then there's the standard Linux overcommit
behavior, which also will kill you at some point.)
But I changed my opinion, so here we go. This change does not affect
_all_ memory allocations, just image data. Now in most failure cases,
the output will just be skipped. For video filters, this coincidentally
means that failure is treated as EOF (because the playback core assumes
EOF if nothing comes out of the video filter chain). In other
situations, output might be in some way degraded, like skipping frames,
not scaling OSD, and such.
Functions whose return values changed semantics:
mp_image_alloc
mp_image_new_copy
mp_image_new_ref
mp_image_make_writeable
mp_image_setrefp
mp_image_to_av_frame_and_unref
mp_image_from_av_frame
mp_image_new_external_ref
mp_image_new_custom_ref
mp_image_pool_make_writeable
mp_image_pool_get
mp_image_pool_new_copy
mp_vdpau_mixed_frame_create
vf_alloc_out_image
vf_make_out_image_writeable
glGetWindowScreenshot
The error log callback was not thread-safe and not library-safe. And
apparently there were some other details that made it not library-safe,
such as a global lcms plugin registry.
Switch the the thread-safe API provided by lcms2 starting with 2.6.
Remove our approximate thread-safety hacks.
Note that lcms basically provides 2 APIs now, the old functions, and
the thread-safe alternatives whose names end with THR. Some functions
don't change, because they already have a context of some sort. Care
must be taken not to accidentally use old APIs.
When the reader is out of data, it tries to wake up the cache thread to
get more data. In theory, there's a small race condition, which could
cause the cache to miss the wakeup and idle before reaction.
Most certainly didn't cause real issues, because even if this extremely
unlikely race condition happens, the cache won't idle for longer than
1 second (the hardcoded cache idle time).
OSD used to be not thread-safe at all, so a track was used to get it
redrawn. This mostly reverts commit 6a2a8880, because OSD not being
thread-safe was the non-trivial part of it.
Mostly untested, because this code path is used on OSX only, and I don't
have OSX.
The main issue was actually that the OSD callback locked the subtitle
decoder, which does not necessarily work, because the OSD code is
already allowed to lock it. The state was already protected by
unsetting the callback (which involes the OSD lock). So, in summary,
this is probably just a cleanup.
We certainly don't want to maintain and improve the internal converter,
but we still need the internal one for Libav. (In the Libav case,
demux_subreader.c will be used to read the MicroDVD file.)
Let the VOs draw the OSD on their own, instead of making OSD drawing a
separate VO driver call. Further, let it be the VOs responsibility to
request subtitles with the correct PTS. We also basically allow the VO
to request OSD/subtitles at any time.
OSX changes untested.
Subsurfaces are only used by the wayland vo. Thats why it makes sense to move
all osd and subsurface specific parts to the vo_wayland.c
Also destroy the subsurfaces and subcompositor properly.
Not all the hardware supports kCGLPFASupportsAutomaticGraphicsSwitching
(apparently all Mid-2010 and before MacBooks do not work with it), so fallback
to not asking for this attribute in the GL pixel format.
Well, not sure if this really improves anything, but at least it's less
of a WTF to the playback core than always returning the same timestamp
for every frame.
There's really no need to convert this to float and then back. This is
mostly of cosmetic nature, double precision was probably enough to avoid
rounding.
This affects packed RGB formats up to 16 bits per pixel. The old mplayer
names used LSB-to-MSB order, while FFmpeg (and some other libraries) use
MSB-to-LSB.
Nothing should change with this commit, i.e. no bit order or endian bugs
should be added or fixed. In some cases, the name stays the same, even
though the byte order changes, e.g. RGB8->BGR8 and BGR8->RGB8, and this
affects the user-visible names too; this might cause confusion.
These suffixes are annoying when they're redundant, so strip them
automatically. On little endian machines, always strip the "le" suffix,
and on big endian machines vice versa (although I don't think anyone
ever tried to run mpv on a big endian machine).
Since pixel format strings are returned by a certain function and we
can't just change static strings, use a trick to pass a stack buffer
transparently. But this also means the string can't be permanently
stored by the caller, so vf_dlopen.c has to be updated. There seems
to be no other case where this is done, though.
Not sure how this symbol becomes visible in glibc (probably accidental
or mandatory recursive inclusion via the other standard or Linux-
specific headers), but normally this include file is needed to get the
symbol.
The "classic" sub-option stuff is not really needed anymore. The only
remaining use can be emulated in a simpler way. But note that this
breaks the --screenshot option (instead of the "flat" options like
--screenshot-...). This was undocumented and discouraged, so it
shouldn't affect anyone.
Instead of absuing m_option to store the property list, introduce a
separate type for properties. m_option is still used to handle data
types. The property declaration itself now never contains the option
type, and instead it's always queried with M_PROPERTY_GET_TYPE. (This
was already done with some properties, now all properties use it.)
This also fixes that the function signatures did not match the function
type with which these functions were called. They were called as:
int (*)(const m_option_t*, int, void*, void*)
but the actual function signatures were:
int (*)(m_option_t*, int, void*, MPContext *)
Two arguments were mismatched.
This adds one line per property implementation. With additional the
reordering of the parameters, this makes most of the changes in this
commit.
This means use of the min/max fields can be dropped for the flag option
type, which makes some things slightly easier. I'm also not sure if the
client API handled the case of flag not being 0 or 1 correctly, and this
change gets rid of this concern.
Also clarify the semantics.
It seems --idx didn't do anything. Possibly it used to change how the
now removed legacy demuxers like demux_avi used to behave. Or maybe
it was accidental.
--forceidx basically becomes --index=force. It's possible that new
index modes will be added in the future, so I'm keeping it
extensible, instead of e.g. creating --force-index.
Probably "needed" to get the correct alignment, although I'm not aware
of actual breakages or performance issues.
In fact we should probably always just allocate AVPackets, but for now
use the simple fix.
FFmpeg requires a bullshit padding after each input buffer, and they
just increased that padding without warning and without ABI or API bump.
We need this only in one file (although mp_image hardcodes something
similar, for which no FFmpeg API define is available), so drop our own
define.
Does anyone actually use this?
For now, update it, because it's the only case left where an option
points to a global variable (and not a struct offset).
Unfortunately, there's a recursive function call in ao_lavc.c (play
function), leading to a deadlock. The locking is getting a bit messy, so
just make the lock recursive.
This fixes#844.
Squashed from the following mplayer-svn commits. The '#' is removed from
the bug ID to prevent github from doing something stupid. Instead of
adding the mplayer configure check for clock_gettime(), the POSIX
identifiers are used for checking presence of the function.
Use correct type of timestamps when recording from v4l2. Fix 2176
Patch by Jarek Czekalski <jarekczek at poczta onet pl>.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@37222 b3059339-0415-0410-9bf9-f77b7e298cf2
Allow building of v4l2 without clock_gettime().
Add overly verbose message in case monotone timestamps are required by the kernel.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@37223 b3059339-0415-0410-9bf9-f77b7e298cf2
Similar to previous commits.
This also renames --doubleclick-time to --input-doubleclick-time, and
--key-fifo-size to --input-key-fifo-size. We could keep the old names,
but these options are very obscure, and renaming them seems better for
consistency.
While I'm not very fond of "const", it's important for declarations
(it decides whether a symbol is emitted in a read-only or read/write
section). Fix all these cases, so we have writeable global data only
when we really need.
Additionally to removing the global variables, this makes the options
more uniform. --ssf-... becomes --sws-..., and --sws becomes --sws-
scaler. For --sws-scaler, use choices instead of magic integer values.
Usually, each stream driver declares the size and option list of its
private data. This was pretty natural for when most streams still used
global variables to setup their defaults. They did by pointing
priv_defaults to the (mutable) struct containing the option values. But
falls short when storing the option values in MPOpts. So provide a
somewhat inelegant but simple way to let the stream implementation setup
the priv struct at initialization time.
This is done with the get_defaults callback. It should return a copy of
the struct used in MPOpts. (A copy, because if MPOpts is changed, string
fields might be deallocated, and if that field is not described by
stream_info.options, it won't be copied on init.)
Pretty much nothing changes, but using -tv-scan with suboptions doesn't
work anymore (instead of "-tv-scan x" it's "-tv scan-x" now). Flat
options ("-tv-scan-x") stay compatible.
Convert all these commands to properties. (Except tv_last_channel, not
sure what to do with this.) Also, internally, don't access stream
details directly, but dispatch commands with stream ctrls.
Many of the new properties are a bit strange, because they're write-
only. Also remove some OSD output these commands produced, because I
couldn't be bothered to port these.
In general, this makes everything much cleaner, and will also make it
easier to e.g. move the demuxer to its own thread.
Don't bother updating input.conf, but changes.rst documents how old
commands map to the new ones.
Mostly untested, due to lack of hardware.
The Perl script generating the completions actually invokes mpv, and it
runs during the build. This is not sane and breaks at least cross
compilation.
As a workaround, disable the completions by default for now.
Playing a video and then an audio file with cover art kept displaying
the last frame of the video. This was because the hasframe flag was set,
perhaps due to redrawing the last video frame before the cover art image
is decoded.
Basically, this allows gapless playback with similar files (including
the ordered chapter case), while still being robust in general.
The implementation is quite simplistic on purpose, in order to avoid
all the weird corner cases that can occur when creating the filter
chain. The consequence is that it might do not-gapless playback in
more cases when needed, but if that bothers you, you still can use
the normal gapless mode.
Just using "--gapless-audio" or "--gapless-audio=yes" selects the old
mode.
Since redundant wakeups are avoided now, it's easy to miss a wakeup when
creating/setting the pipe/callback after the client API was signalled.
If the client API is signalled, need_wakeup is set to true, and
wakeup_client skips writing to the pipe or calling the client API. That
this can happen is not very obvious to the client API, so trigger a
wakeup right on start in order to remove this special case.
--sub-file is actually a string list, so you can add multipel external
subtitle files. But to be able to set a list, the option value was split
on ",". This made it impossible to add filenames.
One possible solution would be adding escaping. That's probably a good
idea (and some other options already do this), but it's also complicated
both to implement and for the user.
The simpler solution is making --sub-file appending, and make it take
only a single entry.
I'm not quite sure about this yet. It breaks the invariant that if a
value is printed and parsed, you get the same value back. So for now,
just go with the simple solution.
Fixes#840.
Until now, availability of new log messages (through the mechanism
associated with mpv_request_log_messages()) did not wakeup the client
API properly. Commit 3b7402b5 was basically a hack to improve that
somewhat, but it wasn't a solution.
The main problem is that the client API itself is producing messages, so
the message callback would attempt to lock the client API lock,
resulting in a deadlock. Even if the lock was recursive, we'd run into
lock-order issues.
Solve this by using a separate lock for waiting and wakeup. Also, since
it's a natural addition, avoid redundant wakeups. This means the wakeup
callback as well as the wakeup pipe will be triggered only once until
the next mpv_wait_event() call happens.
This might make the wakeup callback be invoked in a reentrant way for
the first time, for example if a mpv_* function prints to a log. Adjust
the docs accordingly. (Note that non-reentrant beheavior was never
guaranteed - basically the wakeup callback is somewhat dangerous and
inconvenient.)
Also remove some traces of unneeded code. ctx->shutdown for one was
never set, and probably a leftover of an abandoned idea.
A bit verbose, but less misleading. In most cases, the API user probably
actually wants mpv_terminate_destroy() instead, so the less-useful
function shouldn't have a simnpler name anyway.
It wasn't necessarily clear how this works. Especially make clear that
the API user shouldn't expect that there's one byte per readable event
in the wakeup pipe. Actually, the reason why this currently won't work
is because property notifications can generate more events than wakeups.
The limit of 4096 is a more fundamental issue, but the event ringbuffer
is currently limited to 1000 entries anyway.
Also add some important comments to mpv_set_wakeup_callback.
mpv_destroy() should perhaps better be called mpv_detach(), because it
destroys only the handle, not necessarily the player. The player is only
terminated if a quit command is sent.
This function quits automatically, and additionally waits until the
player is completely destroyed. It removes the possibility that the
player core is still uninitializing, while all client handles are
already destroyed. (Although in practice, the difference is usually not
important.)
Now a negative timeout mean an infinite timeout. This is similar to the
poll() system call. Apparently this is more intuitive and less confusing
than specifying a "very high" value as timeout if you want to wait
forever.
For callers that never pass negative timeouts, nothing changes.
This was never intended to be installed; waf just picked it up
automagically. There's also a closed ticket on github where someone
complains that the program "simple" is installed, and I didn't realize
at this point that it was actually installed by default when enabling
the client API.
Listening on messages currently uses polling (every time
mpv_wait_event() has no new events, the message buffer is polled and a
message event is possibly created). Improve this situation a bit, and
call the user-supplied wakeup callback.
This will increase the frequency with which the wakeup callback is
called, but the client is already supposed to be able to deal with this
situation. Also, as before, calling mpv_wait_event() from the wakeup
callback is forbidden, so the client can't read new messages from the
callback directly.
The wakeup pipe is written either. Since the wakeup pipe is created
lazily, we can't access the pipe handle without creating a race
condition or a deadlock. (This is actually very silly, since in practice
the race condition won't matter, but for now let's keep it clean.)
It seems we can't really get rid of this. There are no other hints to
remove decorations that work across all reasonable WMs, so we're stuck
with the ugly motif stuff.
But at least we can make the code for it less ugly.
If an API user calls mpv_wait_event() and mpv_observe_property() before
mpv_initialize(), it could happen that a property was accessed before
initialization, which is not ok.
This was always intended this way, and even documented in client.h. Due
to an oversight it was never actually implemented.
The intention is that mpv embedded in applications and "real mpv" don't
conflict. An API user can undo this by setting the "config" option to
"yes", if using the user's mpv config is desired.
(The old "force" choice of that option is renamed to "force-default".)
This allows overriding native ASS script subtitle styles with the style
provided by the --sub-text-* options (like --sub-text-font etc.). This
is disabled by default, and needs to be explicitly enabled with the
--ass-style-override=force option and input property.
This uses in fact exactly the same options (--sub-text-*) and semantics
as the ones used to configure unstyled text subtitles.
It's recommended to combine this with this in the mpv config file:
ass-force-style="ScaledBorderAndShadow=1" # work around dumb libass behavior
Also, adding a key binding to toggle this behavior should be added,
because overriding can easily break:
L cycle ass-style-override
This would cycle override behavior on Shift+L and allows quickly
disabling/enabling style overrides.
Note: ASS should be considered a vector format rather than a subtitle
format. There is no easy or reliable way to determine whether the style
of a given subtitle event can be changed without destroying visuals or
not. This patch relies on a simple heuristic, which often works and
often breaks.
This could for example happen when serving an incomplete file from http,
and the demuxer tries reading data from the end of the file when opening
it (e.g. with avi). Seeking past EOF fails with http, so the file could
never be opened, and the cache would get stuck trying to seek to the
position.
We can't really make the cache report seek failure directly (it would
suck for various reasons), so just make the cache report EOF if seeking
fails.
The previous commit assumed the filter would be 1x1 (then constant
weight is correct) - but our code in fact uses at least a 2x2 filter. A
1x1 filter would generally be useless, except for nearest scaling - so
it didn't exist.
Insteasd of adding such a 1x1 filter, just turn the nearest weight
function into a scare function, which should take care of the issue.
This simply writes the file name as a comment to the top of the watch later
config file.
It can be useful to the user for determining whether a watch later config file
can be manually removed (e.g. in case the corresponding media file has been
deleted) or not.
This accidentally rejected d==0. We can actually deal with sub-normals
fine, we just want to exclude nan and infinity (although infinity is
already accounted for, but anyway).
If a single person complains, I will readd it. But I don't expect that
this will happen.
The main reason for removing this is that it's some of the most unclean
code remaining, it's unmaintained, and I've never ever heard of someone
using it.
Until now, an error was reported only if the command couldn't be parsed.
Attempt to do more fine-grained reporting. This is not necessarily
perfect, but it's an improvement.
This would imply eglGetProcAddress() doesn't work correctly, but using
dlsym() does. For now get rid of it - it won't work in libmpv, and we'll
probably need a better workaround if it's still broken.
This code was in the initial wayland commit.
The functions glXGetProcAddressARB() and glXQueryExtensionsString() were
loaded using dlsym(). This could fail when compiling to libmpv, because
then dlopen(NULL, ...) will look in the main program's list of
libraries, and the libGL linked to libmpv is never considered. (Don't
know if this somehow could be worked around.) The result is that using
vo_opengl with libmpv can fail.
Avoid this by not using dlsym(). glXGetProcAddressARB() was already used
directly in the same file, and that never caused any problems. (Still
add it to the configure test.) glXQueryExtensionsString() is documented
as added in GLX 1.1 - that's ancient.
So the device buffer can be refilled quickly. Fixes dropouts in certain
cases: if all data is moved from the soft buffer to the audio device
buffer, the waiting code thinks it has to enter the mode in which it
waits for new data from the decoder. This doesn't work, because the
get_space() logic tries to keep the total buffer size down. get_space()
will return 0 (or a very low value) because the device buffer is full,
and the decoder can't refill the soft buffer. But this means if the AO
buffer runs out, the device buffer can't be refilled from the soft
buffer. I guess this mess happened because the code is trying to deal
with both AOs with proper event handling, and AOs with arbitrary
behavior.
Unfortunately this increases latency, as the total buffered audio
becomes larger. There are other ways to fix this again, but not today.
Fixes#818.
Apparently this can happen. So actually only return from waiting if ALSA
excplicitly signals that new output is available, or if we are woken up
externally.
This call was used limited the buffer size if installed RAM was below 16
MB. This stopped being useful a decade ago. The check could also
overflow on 32 bit systems. Just get rid of it.
This did not flush remaining audio in the buffer correctly (in case an
AO has an internal block size). So we have to make the audio feed thread
to write the remaining audio, and wait until it's done.
Checking the avoid_ao_wait variable should be enough to be sure that all
data that can be written was written to the AO driver.
This code handles buggy AOs (even if all AOs are bug-free, it's good for
robustness). Move handling of it to the AO feed thread. Now this check
doesn't require magic numbers and does exactly what's it supposed to do.
Until now, we've always calculated a timeout based on a heuristic when
to refill the audio buffers. Allow AOs to do it completely event-based
by providing wait and wakeup callbacks.
This also shuffles around the heuristic used for other AOs, and there is
a minor possibility that behavior slightly changes in real-world cases.
But in general it should be much more robust now.
ao_pulse.c now makes use of event-based waiting. It already did before,
but the code for time-based waiting was also involved. This commit also
removes one awkward artifact of the PulseAudio API out of the generic
code: the callback asking for more data can be reentrant, and thus
requires a separate lock for waiting (or a recursive mutex).
uint_least32_t could be larger than uint32_t, so the return values of
mp_ring_get_wpos/rpos must be adjusted. Actually just use unsigned long
as type instead, because that is less awkward than uint_least32_t.
This was originally added because we thought this would make a good
portable audio API, which would give us good behavior on Windows, Linux,
and OSX. But this hope was disappointed: it's not reliable enough (nice
deadlocks on Linux when seeking, i.e. resetting the audio device),
doesn't have enough features (no channel maps, no digital passthrough),
and in general just is not very good.
There were subtle and minor race conditions in the pull.c code, and AOs
using it (jack, portaudio, sdl, wasapi). Attempt to remove these.
There was at least a race condition in the ao_reset() implementation:
mp_ring_reset() was called concurrently to the audio callback. While the
ringbuffer uses atomics to allow concurrent access, the reset function
wasn't concurrency-safe (and can't easily be made to).
Fix this by stopping the audio callback before doing a reset. After
that, we can do anything without needing synchronization. The callback
is resumed when resuming playback at a later point.
Don't call driver->pause, and make driver->resume and driver->reset
start/stop the audio callback. In the initial state, the audio callback
must be disabled.
JackAudio of course is different. Maybe there is no way to suspend the
audio callback without "disconnecting" it (what jack_deactivate() would
do), so I'm not trying my luck, and implemented a really bad hack doing
active waiting until we get the audio callback into a state where it
won't interfere. Once the callback goes from AO_STATE_WAIT to NONE, we
can be sure that the callback doesn't access the ringbuffer or anything
else anymore. Since both sched_yield() and pthread_yield() apparently
are not always available, use mp_sleep_us(1) to avoid burning CPU during
active waiting.
The ao_jack.c change also removes a race condition: apparently we didn't
initialize _all_ ao fields before starting the audio callback.
In ao_wasapi.c, I'm not sure whether reset really waits for the audio
callback to return. Kovensky says it's not guaranteed, so disable the
reset callback - for now the behavior of ao_wasapi.c is like with
ao_jack.c, and active waiting is used to deal with the audio callback.
We don't need to combine __sync_add_and_fetch with a memory barrier,
since these intrinsics are documented as using a full barrier already.
Use __sync_fetch_and_add instead of __sync_add_and_fetch; this gives
atomic_fetch_add() the correct return value (although we don't use it).
Use __sync_fetch_and_add to emulate atomic_load(). This should enforce
the full barrier semantics better. (This trick is stolen from the
FreeBSD based stdatomic.h emulation.)
In most places where af_fmt2bits is called to get the bits/sample, the
result is immediately converted to bytes/sample. Avoid this by getting
bytes/sample directly by introducing af_fmt2bps.
The i_bps members of the sh_audio and dev_video structs are mostly used
for displaying the average audio and video bitrates. Keeping them in
bits-per-second avoids truncating them to bytes-per-second and changing
them back lateron.
This is incomplete; the video chain will still hold some vaapi objects
after destroying the decoder and thus the vaapi context. This is very
bad. Fixing it would require something like refcounting the vaapi
context, but I don't really want to.
mpv supports two hardware decoding APIs on Linux: vdpau and vaapi. Each
of these has emulation wrappers. The wrappers are usually slower and
have fewer features than their native opposites. In particular the libva
vdpau driver is practically unmaintained.
Check the vendor string and print a warning if emulation is detected.
Checking vendor strings is a very stupid thing to do, but I find the
thought of people using an emulated API for no reason worse.
Also, make --hwdec=auto never use an API that is detected as emulated.
This doesn't work quite right yet, because once one API is loaded,
vo_opengl doesn't unload it, so no hardware decoding will be used if the
first probed API (usually vdpau) is rejected. But good enough.
So, basically this worked only with streams that were not local files,
because stream_dvd.c "intercepts" local files to check whether they
point to DVD images. This means if a stream is not writeable, we have to
try the next stream implementation.
Unbreaks 2-pass encoding.
Sometimes, Matroska files store monotonic PTS for h264 tracks with
b-frames, which means the decoder actually returns non-monotonic PTS.
Handle this with an evil trick: if DTS is missing, set it to the PTS.
Then the existing logic, which deals with falling back to DTS if PTS is
broken. Actually, this trick is not so evil at all, because usually, PTS
has no errors, and DTS is either always set, or always unset. So this
_should_ provoke no regressions (famous last words).
libavformat actually does something similar: it derives DTS from PTS in
ways unknown to me. The result is very broken, but it causes the DTS
fallback to become active, and thus happens to work.
Also, prevent the heuristic from being active if PTS is merely monotonic
instead of strictly-monotonic. Non-unique PTS is broken, but we can't
fallback to DTS anyway in these cases.
The specific mkv file that is fixed with this commit had the following
fields set:
Muxing application: libebml v1.3.0 + libmatroska v1.4.1
Writing application: mkvmerge v6.7.0 ('Back to the Ground') [...]
But I know that this should also fix playback of mencoder produced mkv
files.
When Lua itself prints errors such as:
Error: [string "mp.defaults"]:387: syntax error near 'function'
It's unclear why the location is prefixed with "string ". And for some
reason, it disappears if you prefix the name with '@'. I suppose this is
done for the sake of luaL_loadstring. With the '@' prefix added, the
output is now:
Error: mp.defaults:387: syntax error near 'function'
We pass a pointer to a GLint to sscanf, using the %d format. That format
_always_ takes int, and not GLint (whatever the heck that is). If GLint
is always int, then it doesn't make a difference, but is still better
because it doesn't play russian roulette with pointers.
Don't emit "hard" references to OpenGL functions. Always use the
platform specific function to lookup OpenGL functions, such as
glXGetProcAddress() with GLX (x11).
This actually fixes the build if only Wayland is enabled (e.g. using
--disable-gl-x11 on Linux).
Note that some sources claim that wglGetProcAddress() (win32) does not
return function pointers for OpenGL 1.1 functions (even if they are
valid and necessary in OpenGL 3.0). But if that happens, the fallback
employed in gl_w32.c/w32gpa() should catch this.
Setting this property was added 12 years ago, and the code was always
incorrect. The underlying data type is "long", not "pid_t". It's well
possible that the data types are different, and the pointer to the pid
variable is directly passed to XChangeProperty, possibly invoking
undefined behavior.
It's funny, because in theory using pid_t for PIDs sounds more correct.
Binding multiple commands at once where always considered not
repeatable, because the MP_CMD_COMMAND_LIST wasn't considered
repeatable.
Fixes#807 (probably).
These are actually already included in osdep/io.h, but I think it's
cleaner to repeat them in the file where they are actually needed.
(osdep/io.h needs to have them for other reasons.)
Commit e2e450f9 started making use of luaL_register(), but OF COURSE
this function disappeared in Lua 5.2, and was replaced with a 5.2-only
alternative, slightly different mechanism.
So just NIH our own function. This is actually slightly more correct,
since it forces the user to call "require" to actually make the module
visible for builtin C-only modules other than "mp". Fix autoload.lua
accordingly.
This will load other files in the same directory when a single file is
played. It's an often requested feature, but we definitely don't want it
in the core.
We need this only because Lua's stdlib is so scarce. Lua doesn't intend
to include a complete stdlib - they confine themselves to standard C,
both for portability reasons and to keep the code minimal. But standard
C does not provide much either.
It would be possible to use Lua POSIX wrapper libraries, but that would
be a messy (and unobvious) dependency. It's better to implement the
missing functions ourselves, as long as they're small in number.
A playlist_move command that moves an entry onto itself (both arguments
have the same index) should do nothing, but it did something broken. The
underlying reason is that it checks the prev pointer of the entry which
is temporarily removed for moving.
Also sneak in some cosmetics.
setmode() exists on Windows/msvcrt only, so there's no need for a
config test.
I couldn't reproduce the problem with seekable pipes on wine, so axe
it. (I'm aware that it still could be an issue on real Windows.)
For some reason, we support writeable streams. (Only encoding uses that,
and the use of it looks messy enough that I want to replace it with FILE
or avio today.)
It's a chaos: most streams do not actually check the mode parameter like
they should. Simplify it, and let streams signal availability of write
mode by setting a flag in the stream info struct.
Stop using it in most places, and prefer STREAM_CTRL_GET_SIZE. The
advantage is that always the correct size will be used. There can be no
doubt anymore whether the end_pos value is outdated (as it happens often
with files that are being downloaded).
Some streams still use end_pos. They don't change size, and it's easier
to emulate STREAM_CTRL_GET_SIZE using end_pos, instead of adding a
STREAM_CTRL_GET_SIZE implementation to these streams.
Make sure int64_t is always used for STREAM_CTRL_GET_SIZE (it was
uint64_t before).
Remove the seek flags mess, and replace them with a seekable flag. Every
stream must set it consistently now, and an assertion in stream.c checks
this. Don't distinguish between streams that can only be forward or
backwards seeked, since we have no such stream types.
stream.start_pos was needed for optical media only, and (apparently) not
for very good reasons. Just get rid of it.
For stream_dvd, we don't need to do anything. Byte seeking was already
removed from it earlier.
For stream_cdda and stream_vcd, emulate the start_pos by offsetting the
stream pos as seen by the rest of mpv.
The bits in discnav.c and loadfile.c were for dealing with the code
seeking back to the start in demux.c. Handle this differently by
assuming the demuxer is always initialized with the stream at start
position, and instead seek back if initializing the demuxer fails.
Remove the --sb option, which worked by modifying stream.start_pos. If
someone really wants this option, it could be added back by creating a
"slice" stream (actually ffmpeg already has such a thing).
This is mostly covered by the OSX workaround, if the timeout is very
high. It also means that with systems using 32 bit time_t, the time will
overflow 2036 already, instead of 2037, but we don't consider this a
problem.
_WIN_LAYER is apparently an old GNOME thing (also explains why there is
a function vo_x11_get_gnome_layer() involved in this code). Prefer the
NetWM hints over this. This just moves the NetWM case if-body over the
_WIN_LAYER one.
You can't use identifiers starting with "_" and an uppercase letter in
application programs. They are reserved by the C standard.
Unrelated change: drop unused/misleading vo_wm_NETWM define.
I can only assume the old code was wrong. EWMH does not document
anything with _WIN_LAYER. Instead, you have to toggle the state using a
client message. We also remove these weird non-sense fallbacks, like
using _NET_WM_STATE_BELOW - what the hell?
Small fixes for the OSC, seektooltip now enabled by default.
Option-parser now moved to separate package, can be used from
other scripts, see DOCS/man/en/lua.rst.
OSC config file location moved to lua-settings/osc.conf
Some operating systems apparently can't deal with really long timeouts
in pthread_cond_timedwait(). Passing a time about 300000 in the future
makes the call return immediately. (tv_sec/time_t doesn't overflow in
this situation.) Reduce the wait time to about 100 days, which seems
to work fine.
The list of affected OSes follows: OSX
Probably more correct and better readable. Although the special-casing
of 0x1p63 is weird in terms of readability (the value itself is
INT64_MAX+1, so it's already outside of range, but INT64_MAX is not
exactly representable with double precision).
The quit command has an optional argument that is used as exit code.
Extend that to the quit_watch_later command. Actually, unify the
implementations of the two commands.
Requested in #798.
This usually can't happen, because even if time_us (first input value)
is INT64_MAX, the value added to tv_sec will be about 2^43, and tv_sec
will be <2^31, far below a possible overflow in 64 bits. But should
time_t be 32 bits (32 bit Linux/Windows?), an overflow could happen.
Integrate it with the existing surface allocator in vdpau.c. The changes
are a bit violent, because the vdpau API is so non-orthogonal: compared
to video surfaces, output surfaces use a different ID type, different
format types, and different API functions.
Also, introduce IMGFMT_VDPAU_OUTPUT for VdpOutputSurfaces wrapped in
mp_image, rather than hacking it. This is a bit cleaner.
black_pixel is an (apparently necessary) 1x1 black surface used for
clearing the screen. It was allocated in RGB mode only, but is sometimes
used in YUV mode too.
In at least 2 places, we want to "shift" positional parameters by a
certain amount, or remove all parameters if there are fewer parameters.
bash handled this just fine, but dash vomits upon it. POSIX shell allows
both behaviors, so we have to fix it.
Fix a comparison done with "==" instead of "=".
Cover art is treated like video, but is not really video. In one case,
the audio sync code was accidentally still active. Fixes cover art
playback with --ao=null. (This is due to ao_null's latency emulation.
Although it's not very clear whether that is actually correct...)
vo_vdpau currently has a video queue larger than 1 entry, which causes
the video display code to never queue display the video frame. This is
because we consider cover art an endless stream of frames decoded from
the same source packet, and include special logic to actually only
decode and display 1 frame.
Also, make decode_image() also signal EOF in the cover art case.
Without this change, the compiler uses by default the "talloc.h" file
installed by the package libtalloc within /usr/local/include. Found and
tested on OpenBSD but FreeBSD has the same patch on its ports tree.
This should be more correct. The builtins were made to directly map to
C11, and the way we use them is now relatively close to how gcc
implements atomics in 4.9. In particular, we make use of the load and
store builtins.
I'm not entirely sure why gcc didn't support stdatomic.h in 4.8 already.
Maybe support for the builtins was incomplete or broken - so there's a
lot of room for doubt about the correctness of this.
In my opinion, we shouldn't use atomics at all, but ok.
This switches the mpv code to use C11 stdatomic.h, and for compilers
that don't support stdatomic.h yet, we emulate the subset used by mpv
using the builtins commonly provided by gcc and clang.
This supersedes an earlier similar attempt by Kovensky. That attempt
unfortunately relied on a big copypasted freebsd header (which also
depended on much more highly compiler-specific functionality, defined
reserved symbols, etc.), so it had to be NIH'ed.
Some issues:
- C11 says default initialization of atomics "produces a valid state",
but it's not sure whether the stored value is really 0. But we rely on
this.
- I'm pretty sure our use of the __atomic... builtins is/was incorrect.
We don't use atomic load/store intrinsics, and access stuff directly.
- Our wrapper actually does stricter typechecking than the stdatomic.h
implementation by gcc 4.9. We make the atomic types incompatible with
normal types by wrapping them into structs. (The FreeBSD wrapper does
the same.)
- I couldn't test on MinGW.
Some options change from percentages to number of kilobytes; there are
no cache options using percentages anymore.
Raise the default values. The cache is now 25000 kilobytes, although if
your connection is slow enough, the maximum is probably never reached.
(Although all the memory will still be used as seekback-cache.)
Remove the separate --audio-file-cache option, and use the cache default
settings for it.
This works around an issue in OpenBox: OpenBox apparently sizes the
normal window incorrectly if aspect ratio hints are set, and the window
size is off by 1 pixel. Then, when going fullscreen and leaving
fullscreen again, mpv sets the hints based on OpenBox' broken window
size, and as result, OpenBox sizes the window incorrectly and is off by
1 pixel again - so it's 2 pixels off in total. The error gets more
visible, the more often you toggle fullscreen mode.
Work this around by not setting the window hints if we don't need to.
Actually we only need to do this when the video is resized during
fullscreen, which happens rarely. Under normal circumstances, leaving
fullscreen mode requires that the WM restores the old state.
As such, this commit is not only a workaround, but actually a cleanup.
Note that we do need to set the hints when leaving fullscreen if the
window has resized: even though we set the hints in
vo_x11_highlevel_resize (called by vo_x11_config_vo_window), this
doesn't seem to have an effect (at least on IceWM), so we have to do it
after that.
Side note: ot seems commit 625ad57a strangely triggered the OpenBox
issue according to user reports; I'm not sure why.
Drop: sami, vplayer, rt, pjs, mpsub, aqt, jacosub. None of these seem
to be actually in use, except sami. Sami is very complex, and the
results subreader produces are not very useful.
For all these formats, there are still parsers in FFmpeg. We remove the
subreader implementation, because it might contain security relevant
bugs and such. (This is old, unmaintained C string parsing code, written
in times where absolutely nobody cared about security. The kind of
awesome code.)
We keep the other formats, because they're (mostly) commonly used and
relatively simple, for UTF16 support (still missing in FFmpeg), and for
the sake of Libav.
Before this commit, this was somehow polled (i.e. not the right way).
Also, selects the correct window when doing --wid=0 (which is another
weird special-case).
Enabling DPMS even though you disabled it globally is pretty unfriendly,
so don't do it. Instead, we only disable DPMS if it was enabled, and
only enable it if we disabled it ourselves.
The other way should never happen (disabling DPMS permanently), unless
mpv crashes during playback.
It can easily happen that mp_time_us_to_timespec() gets a time in the
past, and then the time difference will be negative. Regression
introduced in commit f47a4fc3.
Also fix an underflow check in mp_add_timeout().
Currently, it's unused. Still keep the file, because it's not unlikely
we'll need it again, and removing/readding the include statements for
this file is too annoying.
This is probably a good idea, because it would make it easier for
software embedding mpv to configure the mpv parts, without requiring the
host program to provide explicit mechanisms for this (other than calling
mpv_load_config_file()).
The code paths for setting options by string and by direct "raw" value
were too different, which resulted in some weird code. Make the code
paths closer to each other.
Also, use this to remove the weirdness in the mpv_set_option()
implementation.
Use the time as returned by mp_time_us() for mpthread_cond_timedwait(),
instead of calculating the struct timespec value based on a timeout.
This (probably) makes it easier to wait for a specific deadline.
When the player is paused, and video filters are changed, an exact seek
is executed to refresh the display. Increase the exactness of the seek
in this case; this reuses the code used for frame backstepping.
It might help in cases where seeking is very imprecise, such as with
transport streams.
If a property is notified as changed, and then again (before the change
notification is returned to the client), and the second change is a
sporadic change (i.e. nothing actually changed) and the change
notification was associated with with a data type, it could happen that
a change was "overlooked", because it would detect no change on the
second notification.
This is actually a pretty annoying corner case, due to the annoying way
we do things, so just store both the previously returned _and_ the newly
obtained property value. then we always compare with the user value to
check for a change, excluding any possibility of a missed change.
Note that we don't (can't/shouldn't) care if a value changes, and then
changes back; it's fine if that doesn't generate a notification. This is
due to how property notifications are supposed to be coalesced.
Reduces some code-duplication.
Just call DPMSEnable/DPMSDisable, instead of DPMSForceLevel when
reenabling DPMS. "Force" sounds evil, and messing with DPMS is already
pretty evil. I'm not even sure that we should.
XGetWindowProperty is a really bad API, almost as if the NSA designed
it. The wrapper takes care of verifying the return values and handle
corner cases.
The window "gravity" influences how placement interacts with WM added
borders (i.e. from decorations). This is probably what the code removed
in commit c14721c8 was about.
In theory, we'd probably want to set the gravity depending on the
relative placement requested by the user (so that it's possible to line
up the top/left video pixel with the monitor corner, as well as the
bottom/right pixel - but that would be too complicated, and who cares
after all?).
I'm also not sure whether CenterGravity really uses the top/left corner
as reference point (instead of making coordinates relative to the window
center), but empirically it's correct.
Try to get the "new" code path (using NetWM/EWMH) free of hacks done for
the sake of old WMs or the no-WM case.
Implement --fs-screen using _NET_WM_FULLSCREEN_MONITORS.
Keeps the window centered on resize. Seems nicer. (Although it's worse
if 1. the default placement of the WM puts it into a monitor corner,
and 2. you switch to a larger video.)
It was added with 3813c685 in 2004. I'm not really sure why this gravity
stuff would be needed; apparently it has to do with misplacements with
broken WMs and had to be changed on fullscreen. Just get rid of it; it
works perfectly fine without on modern WMs.
The thread discussing this is here:
http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-July/027674.html
When writing a video to foo.mp3, the user's intention is clearly to drop
the video stream, and similarly, when writing to foo-%d.png, the
intention is clearly to drop the audio stream. Now, explicit
specification of --no-audio or --no-video is no longer necessary in
these cases.
This should get rid of some flickering. Since this actually skips all
the wacky fullscreening code on startup, this might lead to certain
wacky features to stop working. In this case, you'll have to use the
--x11-fstype option, and disable _NETWM_STATE_FULLSCREEN usage.
vo_x11_map_window() was attempting to clear the window on map. However,
it did so immediately after the map request. It probably assumed that
the drawing calls for clearing the window would be queued along with the
map request, and then executed in the right order. However, this
assumption was wrong - the map request first has to go to the window
manager (I guess?), so a lot of things happen before the window is even
mapped.
Fix this by moving the call to the MapNotify message handler, when the
window (apparently) becomes really visible.
I also tried to set CWBackPixel to black instead, but this seemed to
result in flickering on manual resizing.
This blocks everything, until the window is actually reported as mapped.
This fixes the race condition between VO initialization and mapping the
window, which resulted in possibly different window sizes, leading to an
immediate redraw, visible as flashing.
Note that if the map event never comes for some reason, we're out of
luck and will block forever.
It could in theory happen that the filter loop will enter a blocking
wait, even though it could make progress by emptying the list of
already-filtered images. I'm not quite sure if this could actually cause
a real issue - probably not.
VapourSynth won't just filter multiple frames at once on its own. You
have to request multiple frames at once manually. This is what this
commit introduces: a sub-option controls how many frames will be
requested at once. This also changes the semantics of the maxbuffer sub-
option, now renamed to buffered-frames.
The situation has changed a bit since the days of mplayer2, so we can
use more/less diplomatic wording. Merge the two sections listing
changes from MPlayer and mplayer2. Mention the client API and Lua
scripting as alternatives to slave mode.
I'm calling MPlayer code "horrible". This is not meant as an offense,
but after turning around almost every line of MPlayer code, I believe
I have a right to say this. Sorry. I would say that MPlayer has a
surprisingly sane and simple architecture (for what it is), but much
of it drowned under a load of evil hacks or not-cleaned-up-yet code.
This started as a bunch of smaller changes to make the old configure
script maintainable with minimum effort. It ended up as complete
rewrite, because at once point I started to like shell programming (I
hope this sickness is curable), and I wanted to see how small I can
make the configure script. The typical configure test is now 1 or 2
lines big, located in 1 or 2 places, instead of >15 lines and being
spread over 5 or 6 places.
The main "trick" is factoring the tests into a few generic, commonly
needed tests, instead of writing everything manually.
A lot of effort was spent on making the waf based build-system work
properly on all supported platforms, while the old configure script was
neglected. It seems that nobody maintains the non-Linux parts of the
configure script anymore, and all improvements go into the waf scripts.
Thus it makes no sense anymore to maintain the non-Linux parts. They're
just dead weight. Remove them completely.
Also apply some additional simplifications. For example, listing
enabled/disabled VO modules seems like a waste of effort.
These were in the old configure script too.
Two flags are explicitly tested, because I have no idea how widespread
support for them is, and testing them is just easier than trying to look
them up in various gcc/clang manuals. There are people using gcc 4.2
out there, so some caution is warranted.
waf has a proper test, but no test was added to old-configure.
This means that on OSX, old-configure is not supposed to work anymore.
But still allow it to compile cleanly on OSX.
Previous to this commit, read_chunk was not set in stream_smb. The
cache was therefore filled in small 8K chunks. This resulted in poor
performance when compared to, for example, smbnetfs on the same
network.
The value of 128k is chosen both because it is emperically
the "levelling off point" for throughput into mpv's cache, and because
it is the value chosen by smbnetfs when serving smb shares to
mpv.
Note that this change has no effect unless --cache is explicitly
specified as smb:// streams do not activate cache by default. This is
because the default cache size of 320K is so small it actually makes
smb:// perfomance worse. For best results use at least --cache=1024.
This didn't quite work. The main issue was that get_space tries to be
clever to reduce overall buffering, so it will cause the playloop to
decode and queue only as much audio as is needed to refill the AO in
reasonable time. Also, even if ignoring the problem, the logic of the
previous commit was slightly broken. (This required a few retries,
because I couldn't reproduce the issue on my own machine.)
When the audio buffer went low, but could not be refilled yet, it could
happen that the AO playback thread and the decode thread could enter a
wakeup feedback loop, causing up to 100% CPU usage doing nothing. This
happened because the decoder thread would wake up the AO thread when
writing 0 bytes of newly decoded data, and the AO thread in reaction
wakes up the decoder thread after writing 0 bytes to the AO buffer.
Fix this by waking up the decoder thread only if data was actually
played or queued. (This will still cause some redundant wakeups, but
will eventually settle down, reducing CPU usage close to ideal.)
This shouldn't matter, but it's probably better if the code to check is
valid - otherwise an extremely clever compiler might fail to compile it,
and the feature would be misdetected. (Probably.)
Found by cppcheck.
Caused failure to detect .pls files, because they were misdetected as
m3u. The problem is that "forcing playlist files" and "forcing a
specific playlist format" are not really treated separate, and in both
cases p->force is set to true. This made m3u detect all files as m3u
if --playlist was used. So correctly check whether the file format is
actually being probed or not.
These are now equivalent to combining commands with the "cycle pause" or
"set pause" commands, and thus are not needed anymore. They were also
obscure and undocumented.
mpv supports per-file config files, basically filename+".conf". We use
a static buffer for the new filename, and if that buffer is too small,
we print a warning. This is confusing for e.g. long URLs, so just hide
the warning by default.
Why not dynamically allocate the buffer? Who cares.
I don't think this is really a very good idea because it is conceptually
incorrect but other prominent multimedia programs use this approach
(VLC and xbmc), and it seems to make the conversion more robust in certain
cases.
For example it has been reported, that configuring a receiver that can output
7.1 to output 5.1, will make CoreAudio report 8 channel descriptions, and the
last 2 descriptions will be tagged kAudioChannelLabel_Unknown.
Fixes#737
The code was falling back to the full waveext chmap_sel when less than 2
channels were detected. This new code is slightly more correct since it only
fills the chmap_sel with the stereo or mono chmap in the fallback case.
CoreAudio supports 3 kinds of layouts: bitmap based, tag based, and speaker
description based (using either channel labels or positional data).
Previously we tried to convert everything to bitmap based channel layouts,
but it turns out description based ones are the most generic and there are
built-in CoreAudio APIs to perform the conversion in this direction.
Moreover description based layouts support waveext extensions (like SDL and
SDR), and are easier to map to mp_chmaps.
This might shift bits into the sign, which is undefined behavior. Making
the right operand unsigned was supposed to help with this, but it seems
it did nothing, and C99 makes the result type dependent on the left
operand only.
Use the exact floating point value, instead of a broken integer
constant. The expression calculating the constant probably relied on
undefined behavior, because it left-shifts a negative value.
This also changes the type of the constant to double, which is perfectly
fine, and maybe better than an integer constant.
Preparation so that various things related to video can run in different
threads. One part to this is making the video surface pool safe.
Another issue is the preemption mechanism, which continues to give us
endless pain. In theory, it's probably impossible to handle preemption
100% correctly and race-condition free, unless _every_ API user in the
same process uses a central, shared mutex to protect every vdpau API
call. Otherwise, it could happen that one thread recovering from
preemption allocates a vdpau object, and then another thread (which
hasn't recovered yet) happens to free the object for some reason. This
is because objects are referenced by integer IDs, and vdpau will reuse
IDs invalidated by preemption after preemption.
Since this is unreasonable, we're as lazy as possible when it comes to
handling preemption. We don't do any locking around the mp_vdpau_ctx
fields that are normally immutable, and only can change when recovering
from preemption. In practice, this will work, because it doesn't matter
whether not-yet-recovered components use the old or new vdpau function
pointers or device ID. Code calls mp_vdpau_handle_preemption() anyway to
check for the preemption event and possibly to recover, and that
function acquires the lock protecting the preemption state.
Another possible source of potential grandiose fuckup is the fact that
the vdpau library is in fact only a tiny wrapper, and the real driver
lives in a shared object dlopen()ed by the wrapper. The wrapper also
calls dlclose() on the loaded shared object in some situations. One
possible danger is that failing to recreate a vdpau device could trigger
a dlclose() call, and that glibc might unload it. Currently, glibc
implements full unloading of shared objects on the last dlclose() call,
and if that happens, calls to function pointers pointing into the shared
object would obviously crash. Fortunately, it seems the existing vdpau
wrapper won't trigger this case and never unloads the driver once it's
successfully loaded.
To make it short, vdpau preemption opens up endless depths of WTFs.
Another issue is that any participating thread might do the preemption
recovery (whichever comes first). This is easier to implement. The
implication is that we need threadsafe xlib. We just hope and pray that
this will actually work. This also means that once vdpau code is
actually involved in a multithreaded scenario, we have to add
XInitThreads() to the X11 code.
Use the newly provided mp_vdpau_handle_preemption() function, instead of
accessing mp_vdpau_ctx fields directly. Will probably make multithreaded
access to the vdpau context easier.
Mostly unrelated to the actual changes, I've noticed that using hw
decoding with vo_opengl sometimes leads to segfaults inside of nvidia's
libGL when doing the following:
1. use hw decoding + vo_opengl
2. switch to console (will preempt on nvidia systems)
3. switch back to X (mpv will recover, switches to sw decoding)
4. enable hw decoding again
5. exit mpv
Then it segfaults when mpv finally calls exit(). I'll just blame nvidia,
although it seems likely that something in the gl_hwdec_vdpau.c
preemption handling triggers corner cases in nvidia's code.
This was broken for some time, and it didn't recover correctly.
Redo decoder display preemption. Instead of trying to reinitialize the
hw decoder, simply fallback to software decoding. I consider display
preemption a bug in the vdpau API, so being able to _somehow_ recover
playback is good enough.
The approach taking here will probably also make it easier to handle
multithreading.
Move the code that copies the dylib's to the bundle to a new script
(dylib-unhell.py) which is called by osxbundle.py.
dylib-unhell is about 20x faster than the previous implementation. This is
accomplished by removing superflous shell-out operations which are kept track
of using an in memory tree of all the needed dependencies. Moreover the
shell-outs have been further optimized by not requiring a complete shell for
every operation and just using subprocess.call (which is equivalent to Popen).
The many "boxes" in this entry were causing rst2pdf to fail because it
couldn't figure out where to break the page. Make the boxes smaller by
removing semi-redundant examples. Also try and make surrounding text a
little shorter by rewording.
This is done after filters, so things like framerate-doubling
deinterlacing is accounted for.
Unfortunately, framedropping can cause inaccuracies (especially after
precise seeks), and we can't really know when that happens. Even though
we know that the decoder might drop a frame if we request it to do so,
we don't know when the dropped frame will start or stop affecting the
video filter chain. Video filters can have frames buffered, and we
can't tell at which point the dropped frame would have been output.
It's not even possible to mark a discontinuity after seek, because
again we don't know if the filter chain still has the discontinuity
within its buffers.
So we have to live with the fact that the output of this property can
be completely broken after seek, unless --no-hr-seek-framedrop is used.
This allows disabling of decoder framedrop during hr-seek.
It's basically another useless option, but it will help exploring
whether this framedropping really makes seeking faster, or whether
disabling it helps with precise seeking (especially frame backstepping).
Until recently, the VO was an unavoidable part of the seeking code path.
This was because vdpau deinterlacing could double the framerate, and hr-
seek and framestepping etc. all had to "see" the additional frames. But
we've removed the frame doubling from the vdpau VO and moved it into a
video filter (vf_vdpaupp), and there's no reason left why the VO should
participate in seeking.
Instead of queuing frames to the VO during seek and skipping them
afterwards, drop the frames early.
This actually might make seeking with vo_vdpau and software decoding
faster, although I haven't measured it.
Now we avoid calling update_video() twice on reconfig (once to check
whether there are still new frames, and again to actually do the
reconfig). Instead, we check whether there's still something going on
before calling update_video() at all, and depending on that
update_video() will be allowed to reconfig or not.
This will simplify some things later.
It doesn't look like vo_wayland_config() necessarily sets this flag, so
it seems safer to trigger an explicit resize. This accounts for the case
when playing a new file with different size than the one before.
Currently, vo_reconfig() calculates the requested window size and sets
the vo->dwidth/dheight fields _if_ VOCTRL_UPDATE_SCREENINFO is
implemented by the VO or the windowing backend. The window size can be
different from the display size if e.g. the --geometry option is used.
It will also set the vo->dx/dy fields and read vo->xinerama_x/y.
It turned out that this is very backwards and actually requires the
windowing backends to workaround these things. There's also
MPOpts.screenwidth/screenheight, which used to map to actual options,
but is now used only to communicate the screen size to the vo.c code
calculating the window size and position.
Change this by making the window geometry calculations available as
separate functions. This commit doesn't change any VO code yet, and just
emulates the old way using the new functions. VO code will remove its
usage of VOCTRL_UPDATE_SCREENINFO and use the new functions directly.
Because the http playlist URL I had for testing claimed to be m3u by
file extension and mime type, but didn't have the header.
Note that this actually changes behavior only in the case the format is
detected by mime type. Then p->force will be set before calling the
parser, and the header becomes optional.
Changing --softvol-max and then resuming would change the volume level
on resume to something different than the original volume. This is
because the user volume setting is always between 0-100, and 100
corresponds to --softvol-max gain.
Avoid that changing -softvol-max and resuming an older file could lead
to a too loud volume level by refusing to restore if --softvol-max
changed.
Commit 433161 actually broke vo_opengl (and maybe others), because
config_ok is not necessarily set correctly yet _during_ reconfig. So a
vo_get_src_dst_rects() call during reconfig did nothing.
When the VO was not initialized with vo_reconfig(), or if the last
vo_reconfig() failed, changing panscan would cause a crash due to
vo_get_src_dst_rects() dereferencing vo->params (NULL if not
configured).
Just do nothing if that happens, as there is no video that could be
displayed anyway.
Doesn't really seem to be much of use. Get rid of the remaining uses of
it.
Concerning vo_opengl_old, it seems uninitGl() works fine even if called
before initialization.
Make it more suitable for chaining. This means a function formatting a
value to a string using a static buffer can work exactly like
mp_snprintf_append itself.
Also rename it to mp_snprintf_cat, because that's shorter.
Basically, extract the option table from DOCS/man/en/changes.rst, and
search the table if an option wasn't found. If there's an entry about
it, print it. Hopefully this behavior is slightly more userfriendly.
This is strictly bound to option names. It doesn't work for option
values, nor does it attempt to emulate the old option.
The comment says that it wakes up the main thread if 50% has been
played, but in reality the value was 0.74/2 => 37.5%. Correct this. This
probably changes little, because it's a very fuzzy heuristic in the
first place.
Also move down the min_wait calculation to where it's actually used.
mp3 has a hack lowering the probescore for format detection. This is
because detecting mp3s is hard due to their nature, and the fact that
ID3v2 tags are sometimes several megabytes big.
When playing mp3 from network, the mime-type is usually set, and that
matches the format hack entry meant for webradios, overriding the normal
mp3 entry. This can lead to network mp3s not being detected. Lower the
network case to the same probescore as on-disk mp3s. The difference is
that for network mp3s, we don't load the full probe-buffer, and we lower
the amount of audio the demuxer will read to collect data on opening
(0.5 seconds instead of typically 5 seconds).
This was a minor code duplication between vf_vdpaupp.c and vo_vdpau.c.
(In theory, we could always require using vf_vdpaupp with vo_vdpau, but
I think it's better if vo_vdpau can work standalone.)
Also remove MSGL_SMODE and friends.
Note: The indent in options.rst was added to work around a bug in
ReportLab that causes the PDF manual build to fail.
When loading a video, and a script reacts to MPV_EVENT_VIDEO_RECONFIG,
and the script inserts a video filter, the first frame can be skipped.
This happens simply because the first frame is (usually) still queued in
the video filter chain, and changing the filter chain will drop all
queued frames. So this is just a corner case that just happens in a
weird situation.
But it's still annoying when having such a script, and starting
something where the first frame is very visible, and not starting in
paused mode. (All in all, a corner case.) Do this by immediately queuing
1 filtered frame to the VO immediately after reconfig, instead of
leaving it to the video loop doing it as "incremental" work. Simply
fallthrough to the next case. We must not overwrite "r" in this case,
because that contains the current status.
Note that the first frame will not be filtered using the inserted
filter.
This wasn't really fine, and could (perhaps) cause weird corner cases on
reinit or when the player was paused.
Before eb9d20, video_left was also set to true if vo->frame_loaded was
set, and this variable basically indicated whether the previous
update_video() call was successful. This was overlooked when changing
everything. Simply always call update_video(), it should be equivalent.
This can happen when the input stream is somehow blocking on network,
and the user still send input in one way or another, and one of the
commands is a compound command ("cmd a ; cmd b").
Apparently the value of a pointer is "indeterminate" after a free()
call, even if you never dereference the pointer after the free. Since
talloc_free() calls free(), this applies here.
This affects the return value of mp.script_name, the "client name"
(what's returned by mpv_client_name()) and all associated features, as
well as the mpv terminal output module prefix when scripts print
something.
As discussed in #748.
Change how the video decoding loop works. The structure should now be a
bit easier to follow. The interactions on format changes are (probably)
simpler. This also aligns the decoding loop with future planned changes,
such as moving various things to separate threads.
vf_fix_img_params() takes care of overwriting image parameters that are
normally not set correctly by filters. But this makes no sense for input
images. So instead, check that the input is correct.
It still has to be done for the first input image, because that's used
to handle some overrides (see video_reconfig_filters()).
These replace vf_read_output_frame(), although we still emulate that
function. This change is preparation for another commit (and this is
basically just to reduce the diff and signal/noise ratio in that
commit).
Basically, if we feed the filter a new image even after the EOF state
has been reached (e.g. because the input stream "recovered"), we want
the filter to restart, instead of returning an error forever.
Some non-deinterlacing filters (potentially denoising) also use
additional frames for filtering. The vdpau docs suggest providing at
least 1 future and 2 past _fields_, which means we need to provide 1
past frame (the future field is already the other field of the current
field, and both fields are in the same frame).
We can easily achieve this by buffering an additional frame in the non-
deint case.
Remove the special casing of vo_vdpau vs. other VOs. Replace the
complicated interaction between vo.c and vo_vdpau.c with a simple queue
in vo.c. VOs other than vdpau are handled by setting the length of the
queue to 1 (this is essentially what waiting_mpi was).
Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the
future, while the remaining 3 or 4 frames were past frames. So the new
code buffers 2 frames (vo_vdpau.c requests this queue length by setting
vo->max_video_queue to 2). It should probably be investigated why
vo_vdpau.c kept so many past frames.
The field vo->redrawing is removed. I'm not really sure what that would
be needed for; it seems pointless.
Future directions include making the interface between playloop and VO
simpler, as well as making rendering a frame a single operation, as
opposed to the weird 3-step sequence of rendering, drawing OSD, and
flipping.
Give up on the deint_filters[] array, and probe using explicit code
instead. Add additional checks to test the pixel format to avoid
annoying warnings when a hardware deinterlacer is inserted when the
current video chain is obviously incompatible.
The previous commits changed vo_vdpau so that these options are set by
vf_vdpaupp, and the corresponding vo_vdpau were ignored. But for
compatibility, keep the "old" options working.
The value of this is questionable - maybe the vo_vdpau options should
just be removed. For now, at least demonstrate that it's possible.
The "deint" suboption still doesn't work, because the framerate doubling
logic required for some deint modes was moved to vf_vdpaupp. This
requires more elaborate workarounds.
This is slightly incomplete: the mixer options, such as sharpen and
especially deinterlacing, are ignored. This also breaks automatic
enabling of interlacing with 'D' or --deinterlace. These issues will be
fixed later in the following commits.
Note that we keep all the custom vdpau queue stuff. This will also be
simplified later.
This uses mp_vdpau_mixer_render(). The benefit is that it makes vdpau
deinterlacing just work. One additional minor advantage is that the
video mixer creation code is factored out (although that is a double-
edged sword).
This factors out some code from vo_vdpau.c, especially deinterlacing
handling. The intention is to use this for vo_vdpau.c to make the logic
significantly easier, and to use it for vo_opengl (gl_hwdec_vdpau.c) to
allow selecting deinterlace and postprocessing modes.
As of this commit, the filter actually does nothing, since both vo_vdpau
and vo_opengl treat the generated images as normal vdpau images. This
will change in the following commits.
It now inserts no filters and does nothing until the hot-key is pressed.
This makes it more suitable to be put in ~/.mpv/lua.
When the hot-key is pressed, it now inserts the cropdetect filter and
waits 1 second (or a --lua-opts specified duration) before gathering
the cropdetect metadata and inserting the appropriate crop filter. A
second press of the hotkey removes the crop.
It might have been nice not to do this so that metadata could
accumulate accross seeks, but it seems libavfilter looses its copy
anyway on recreate_graph.
lavfi would segfault due to a NULL dereference if it was asked for its
metadata and none had been allocated (oops). This happens for libav
which has no concept of filter metadata.
Commit 5e4e248 added a mp_image_params field to mp_image, and moved many
parameters to that struct. display_w/h was left redundant with
mp_image_params.d_w/d_h. These fields were supposed to be always in
sync, but it seems some code forgot to do this correctly, such as
vf_fix_img_params() or mp_image_copy_attributes(). This led to the
problem in github issue #756, because display_w/_h could become
incorrect.
It turns out that most code didn't use the old fields anyway. Just
remove them. Note that mp_image_params.d_w/d_h are supposed to be always
valid, so the additional checks for 0 shouldn't be needed. Remove these
checks as well.
Fixes#756.
In theory, returning the screenshot with original pixel aspect would
allow avoiding scaling them with image formats that support non-square
pixels, but in practice this isn't used anyway (nothing seems to
understand e.g. jpeg aspect ratio tags).
We only support them for input. The frame properties of output frames
are ignored (except frame durations).
Properties not set for now: _ChromaLocation, _Field, _FieldBased
Set _DurationNum/_DurationDen on each VS frame, instead of
_AbsoluteTime. The duration is the difference between the timestamp of
the frame and the next frame, and when receiving filtered VS frames, we
convert them back to an absolute PTS by summing them.
We pass the timestamps with microsecond resolution. mpv uses double for
timestamps internally, so we don't know the "real" timebase or FPS. VS
on the other hand uses fractions for frame durations. We can't pass
through the numbers exactly, but microseconds ought to be enough to be
even safe from accumulating rounding errors.
Since this leaks video images, and the player keeps feeding new images
to the fitler even if it fails, this would probably have disastrous
consequences.
Or in other words, add support for properly draining remaining frames
from video filters. vf_yadif is buffering at least one frame, and the
buffered frame was not retrieved on EOF.
For most filters, ignore this for now, and just adjust them to the
changed semantics of filter_ext. But for vf_lavfi (used by vf_yadif),
real support is implemented. libavfilter handles this simply by passing
a NULL frame to av_buffersrc_add_frame(), so we just have to make
mp_to_av() handle NULL arguments.
In load_next_vo_frame(), we first try to output a frame buffered in the
VO, then the filter, and then (if EOF is reached and there's still no
new frame) the VO again, with draining enabled. I guess this was
implemented slightly incorrectly before, because the filter chain still
could have had remaining output frames.
This extracts the scheduling logic to a single function which is nicer to keep
it consistent.
Additionally make sure we don't schedule sync operations from a sync operation
itself since that could cause deadlocks (even if it should not be happening
with the current code).
Previously the window could be made to completly exit the screen with a
combination or moving it close to an edge and halving it's size (via cmd+0).
This commit address the problem in the most simple way possibile by
constraining the window to the closest edge in these edge cases.
This fixes a couple of issues with the Cocoa `--native-fs` mode, primarily:
- A ghost titlebar at the top of the screen in full screen:
This was caused by the window constraining code kicking in during
fullscreen. Simply returning the unconstrained rect from the constraining
method fixes the problem.
- Incorrect behavior when using the titlebar buttons to enter/exit
fullscreen, as opposed to the OSD button.
This was caused by mpv's internal fullscreen state going out of sync with
the NSWindow's one. This was the case because `toggleFullScreen:`
completely bypassed the normal event flow that mpv expects.
Signed-off-by: Ryan Goulden <percontation@gmail.com>
Change style for mpv, simplify and refactor some of the constraining code.
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
I thought the "_" in "_AbsoluteTime" was part of the documentation
markup.
This still doesn't help us with VS filters that change timing;
apparently you must use frame durations instead.
Make the filter apply the pixel aspect ratio of the input to the output.
This is more useful than forcing 1:1 PAR when playing anamorphic video
such as DVDs.
VapourSynth itself actually allows passing through the aspect ratio, but
it's in a not very useful form for us: it's per video-frame instead of
constant (i.e in VSVideoInfo). As long as we don't have a way to allow a
filter to spontaneously change output parameters, we can't use this.
(And I don't really feel like making this possible.)
Our code currently tries to link -lpthread and adds stuff like -D_REENTRANT
based on the target platform.
GCC actually supports to just pass a -pthread compiler and linker flag that
will automatically enable threading and define the correct symbols for the
platform, so let's try to just use that as our first choice.
clang also supports -pthread but it must be used only as a compiler flag,
so we also take care of that scenario with this commit.
-Wempty-body is not available on all gcc versions but we were using it
unconditionally. Also remove the usage from the clang case. clang still
defines `__GNUC__` so it still gets all the gcc specific flags.
This should fix the build on systems with older gcc versions like OpenBSD which
still comes bundled with gcc 4.2 for license issues.
One problem is that for example stdio functions won't restart syscalls
manually, and instead treat EINTR as an error. So passing SA_RESTART is
the only sane thing to do, unless you have special requirements, which
we don't.
VP9 packets can contain 2 frames in some video packets (from which 1
frame is invisible). Due to a design mismatch between libvpx and the
libavcodec vp9 decoder, libvpx can take the "full" packets, but lavc vp9
can not. The consequence is that we have to split the packets if we want
to feed them to the lavc codec.
This is not entirely correct yet: timestamp handling is missing.
--demuxer=lavf and ffmpeg native utilities have the same problem. We can
fix this only once the ffmpeg VP9 parser is fixed.
This essentially reverts commit cca13efb. The code in the if was
supposed to be run only if the mouse button was down, because in this
case the mouse area is never considered to be left. Since it was run
for every mouse button, mouse_leave wasn't sent.
Fixes#745.
pthread_equal() returns 0 if the threads are not the same, and somehow
I got that wrong. The worst is that I actually explicitly checked the
manpage when I wrote this code.
This used an unnamed union, which is allowed in GNU C and C11, but not
C99. This broke the build with some older compilers.
Replaces pull request #744.
This reverts commit 6e34b0ec1f.
There has always been an error message "proxy already has a listener" and
I couldn't reproduce where it is comming from until now. The display interface
already has a listener and we can't overwrite it. Now remove the code and avoid
this error message.
Conflicts:
video/out/wayland_common.c
The interrupt callback will can be called from another thread if the
cache is enabled, and the stream disconnects. Then stream_reconnect()
will call this function from within the cache thread.
mp_input_check_interrupt() is not thread-safe due to read_events() not
being thread-safe. It will call input callbacks added with
mp_input_add_fd() - these callbacks lead to code not protected by locks,
such as reading X11 events.
Solve this by adding a stupid hack, which checks whether the calling
thread is the main playback thread (i.e. calling the input callbacks
will be safe). We can remove this hack later, but it requires at least
moving the VO to its own thread first.
This used global variables for the asynchronous interrupt callback.
Pick the simple and dumb solution and stuff the callback into
mpv_global. Do this because interrupt checking should also work in the
connect phase, and currently stream creation equates connecting.
Ideally, this would be passed to the stream on creation instead, or
connecting would be separated from creation. But since I don't know yet
which is better, and since moving stream/demuxer into their own thread
is something that will happen later, go with the mpv_global solution.
This is the only function which actually used the time argument of
stream_check_interrupt(). Considering that the whole player freezes
anyway, this is not worth the complication.
Also generally reduce the maximum wait time due to timeout. Introduce
exponential backoff, which makes the first reconnect retries faster, but
still waits up to 500ms in the later retries.
For some reason, some files appear to have broken mp3 packets, or at
least in a form that libavcodec can't deal with. The audio in the sample
file in question could not be decoded using libavcodec.
The problematic file had variable packet sizes, and the libavcodec
decoder kept printing "mp3: Header missing" for each packet it was fed.
Remuxing with mkvmerge fixes the problem. The mp3 data is probably not
VBR, and remuxing resulted in fixed-size mp3 frames. So I don't know why
the sample file was muxed this way - it might just be incorrect.
The sample file had "libmkv 0.6.4" as MuxingApp (although I could not
get mkvinfo to print this element, maybe the file uses an incorrect
element ID), and "HandBrake 0.9.4" as WritingApp.
Note that the libmpg123 decoder does not have any issues with it. It's
probably more robust, because libmpg123 was made to decode whole mp3
files, not just single frames.
Fixes issue #742.
The here documented guarantee might simplify code using this mechanism
a lot, because it becomes unnecessary to invent a separate mechanism to
make the mp_dispatch_queue_process loop exit after processing a dispatch
callback. (Instead, the dispatch callback can set a flag, and the caller
of mp_dispatch_queue_process can check it.)
This allows client API users and Lua scripts to side-step the pretty
horrible video filter string "language" (although it's back and can't be
avoided when using libavfilter).
The wakeup is needed to make mp_dispatch_queue_process() return if
suspension is not needed anymore - which is only the case when the
request count reaches 0.
The assertion added with this commit always has/had to be true.
Note that this mechanism is similarly "unreliable" as for example
pthread_cond_timedwait(). Trying to target the exact wait time will just
make it more complex.
The main use case for this is for threads which either use the dispatch
centrally and want mp_dispatch_queue_process to do a blocking wait for
new work, or threads which have to implement timers. For the former,
anything is fine, as long as they don't have to do active waiting for
new works. For the former, callers are better off recalculating their
deadline after every call.
This is much simpler, leaves fairness isues etc. to the operating
system, and will work better with threading-related debugging tools.
The "trick" to this is that the lock can be acquired and held only while
the queue is in suspend mode. This way we don't need to make sure the
lock is held outside of mp_dispatch_queue_process, which would be quite
messy to get right, because it would have to be in locked state by
default.
mp_dispatch_queue_process() releases the queue->lock mutex while
processing a dispatch callback. But this allowed mp_dispatch_lock() to
grab the "logical" lock represented by queue->locked. Grabbing the
logical lock is not a problem in itself, but it can't be allowed to
happen while the callback is still running.
Fix this by claiming the logical lock while the dispatch callback is
processed. Also make sure that the thread calling mp_dispatch_lock() is
woken up properly.
Fortunately, this didn't matter, because the locking function is unused.
This was part of osdep/threads.c out of laziness. But it doesn't contain
anything OS dependent. Note that the rest of threads.c actually isn't
all that OS dependent either (just some minor ifdeffery to work around
the lack of clock_gettime() on OSX).
Add the event FD after preinit, remove it before destroy. There's no
need to do it on vo_config, and there's no need to remove the event
FD when vo_config fails.
This should fix some issues, such as not being able to set the
"no-video" option with MPV_FORMAT_FLAG.
Note that this changes semantics a bit. Now setting an option strictly
overwrite it, even if the corresponding command line option does not.
For example, if we change --sub to append by default, then setting the
"sub" option via the client API would still never append. (Oddly, this
also applies to --vf-add, which will overwrite the old value when using
the client API.)
I'm doing this because there's no proper separation between the command
line parser and setting an option using the MPV_FORMAT_STRING format.
Maybe the solution to this mess would be adding format aware code (i.e.
m_option_set_node) to every option type, and falling back to strings
only if needed - but this would mean that you couldn't set e.g. an
integer option using MPV_FORMAT_STRING, which doesn't seem to be ideal
either.
In conclusion, the current approach seems to be most robust, but I'm
open to suggestions should someone find that these semantics are a
problem.
glob() is mandated by POSIX. For the only non-POSIX platform we support,
Windows, we have our own replacement. So the ifdeffery is not needed.
Still leave the checks in the configure scripts, because they have to
decide whether to compile the replacement or not. (Although this could
be special cased to mingw-only, the wscript seems to make this hard.)
Unfortunately, if a VO can't display something as intended, we can just
complain to the user, and leave it at it. But it's still better than
silently displaying things differently with different VOs.
For now, this is used for rotation only. Other things that we should
check includes colorspace and colorlevels stuff.
When using rotation with hw decoding, and the VO does not support
rotation, vf_rotate is attempted to be inserted. This will go wrong, and
after that it can't recover because a vf_scale filter was autoinserted.
Just removing all autoinserted filters before reconfig fixes this.
The Windows port uses CommandLineToArgvW, which doesn't expand wildcards
in command line arguments. Use glob to expand them instead, but only for
non-option arguments.
glob-win.c wasn't big, so it was easier to rewrite it. The new version
supports Unicode, handles directories properly, sorts the output and
puts all its allocations in the same talloc context to simplify the
implementation of globfree.
Notably, the old glob had error checking code, but didn't do anything
with the errors since the error reporting code was commented out. The
new glob doesn't copy this behaviour. It just treats errors as if there
were no more matching files, which shouldn't matter for mpv, since it
ignores glob errors too.
To match the other Windows I/O helper functions, the definition is moved
to osdep/io.h.
If the VO can't do rotation, insert a filter to do this. Note that this
doesn't reuse the filter insertion code from command.c (used by "vf"
input command), because that would end up more complicated: we don't
even want to change the user filter option.
This turned out much more complicated than I thought. It's not just a
matter of adjusting the texture coordinates, but you also have to
consider separated scaling and panscan clipping, which make everything
complicated.
This actually still doesn't clip 100% correctly, but the bug is only
visible when rotating (or flipping with --vf=flip), and using something
like --video-pan-x/y at the same time.
For rotation, we assume that the source image will be rotated within the
VO, so the aspect/panscan code needs to calculate its param using
rotated coordinates. VOs which support rotation natively can use this.
This couldn't rotate by 180°. Add this, and also make the parameter in
degrees, instead of magic numbers.
For now, drop the flipping stuff. You can still flip with --vf=flip or
--vf=mirror. Drop the landscape/portrait stuff - I think this is
something almost nobody will use. If it turns out that we need some of
these things, they can be readded later.
Make it use libavfilter. Its vf_transpose implementation looks pretty
simple, except that it uses slice threading and should be much faster.
Often, user configs set options that are not suitable for encoding.
Usually, playback and encoding are pretty different things, so it makes
sense to keep them strictly separate. There are several possible
solutions. The approach taken by this commit is to basically ignore the
default config settings, and switch to an [encoding] config profile
section instead. This also makes it impossible to have --o in a config
file, because --o enables encode mode.
See github issue #727 for discussion.
Fix all include statements of the form:
#include "libav.../..."
These come from MPlayer times, when FFmpeg was somehow part of the
MPlayer build tree, and this form was needed to prefer the local files
over system FFmpeg.
In some cases, the include statement wasn't needed or could be replaced
with mpv defined symbols.
Not needed anymore. I'm not opposed to having asm, but inline asm is too
much of a pain, and it was planned long ago to eventually get rid fo all
inline asm uses.
For the note, the inline asm use that was removed with the previous
commits was almost worthless. It was confined to video filters, and most
video filtering is now done with libavfilter. Some mpv filters (like
vf_pullup) actually redirect to libavfilter if possible.
If asm is added in the future, it should happen in the form of external
files.
No change in speed (or even slightly faster, though I tested with
progressive solid color video only), and normally we use libavformat's
vf_pullup anyway.
I didn't test the speed, but by default, this filter diverts to
libavfilter already. So this would help only if libavfilter is disabled,
or libavfilter doesn't have vf_noise (like on Libav). For these cases,
we still provide the (possibly but not necessarily) slower C
implementation of vf_noise.
This makes it multiple times slower. However, the output format (packed
YUV) isn't handled efficiently by anything to begin with, and I have no
clue we even have this filter. I guess it's one of these filters which
find some use sometimes, but are not of higher importance, which
justifies removing the faster inline asm.
This can be used to easily extent the status line for one's own needs.
I'm not experienced with lua so a few things could probably be done a
better way.
This is for the sake of multi-key commands again. This could break:
SPACE ignore
SPACE-SPACE command
while this worked:
SPACE-SPACE command
SPACE ignore
The reason being that if the shorter command was first in the list,
it would obviously match, and searching was stopped.
This is for the sake of multi-key combinations (see github issue #718).
Now a multi-key sequence isn't matched if any of the previous keys were
actually mapped.
We only need to track key up/down for a single key. There may be some
minor loss of robustness, but this can (probably) happen only if a VO or
user sends strange or complicated sequences of events. In the normal
case, what we do is more than enough. Most simplification comes from the
fact that mpv is not a game console, and users normally execute only one
action at once.
The window close button is usually mapped to the CLOSE_WIN pseudo-key.
Until now, --input-test treated this pseudo-key like any other key (like
the rest of the input handling code), so you couldn't close the window
in this mode. The manpage had silly instructions and warnings how to
deal with this.
Just always quit when CLOSE_WIN is received, and improve the
instructions.
The input code always supported combinations of multiple keys (even in
MPlayer, although there the code was active really only for mouse
buttons). This was arcance and also made the code more complicated. I
only know of a single person who ever made use of this feature.
Remove this feature, and repurpose some of the support code (e.g.
parsing, display of key combinations, etc.) to handle such multi-
combinations as sequences, instead of keys to be pressed at the same
time. This is much simpler and implements the feature requested in
github issue #718.
This commit will probably cause a bunch of regressions, since the input
handling code has some weird corner cases. I couldn't find any problems
when testing, though.
This avoids too many realloc() calls if the caller is appending to an
audo buffer. This case is actually quite noticeable when using something
that buffers a large amount of audio.
For some reason, the buffered_audio variable was used to "cache" the
ao_get_delay() result. But I can't really see any reason why this should
be done, and it just seems to complicate everything.
One reason might be that the value should be checked only if the AO
buffers have been recently filled (as otherwise the delay could go low
and trigger an accidental EOF condition), but this didn't work anyway,
since buffered_audio is set from ao_get_delay() anyway at a later point
if it was unset. And in both cases, the value is used _after_ filling
the audio buffers anyway.
Simplify it. Also, move the audio EOF condition to a separate function.
(Note that ao_eof_reached() probably could/should whether the last
ao_play() call had AOPLAY_FINAL_CHUNK set to avoid accidental EOF on
underflows, but for now let's keep the code equivalent.)
This replaces translate_key_input with a solution that gives mpv more
control over how keyboard input is converted to unicode. As a result:
- Key up/down events are generated the same way for all keys.
- Dead keys generate their base character instead of being combined with
the following character.
- Many Ctrl and Ctrl+Alt key combinations that were previously broken
are fixed, since it's possible to discover the base keys.
- AltGr doesn't produce special characters when mp_input_use_alt_gr is
false.
This also fixes some logic to do with detecting AltGr and adds proper
UTF-16 decoding.
This was reported with PulseAudio 2.1. Apparently it still has problems
with reporting the correct delay. Since ao_pulse.c still has our custom
get_delay implementation, there's a possibility that this is our fault,
but this seems unlikely, because it's full of workarounds for issues
like this. It's also possible that this problem doesn't exist on
PulseAudio 5.0 anymore (I didn't explicitly retest it).
The check is general and works for all push based AOs. For pull based
AOs, this can't happen as pull.c implements all the logic correctly.
This should probably be an AO function, but since the playloop still has
some strange stuff (using the buffered_audio variable instead of calling
ao_get_delay() directly), just leave it and make it more explicit.
This collects statistics and other things. The option dumps raw data
into a file. A script to visualize this data is included too.
Litter some of the player code with calls that generate these
statistics.
In general, this will be helpful to debug timing dependent issues, such
as A/V sync problems. Normally, one could argue that this is the task of
a real profiler, but then we'd have a hard time to include extra
information like audio/video PTS differences. We could also just
hardcode all statistics collection and processing in the player code,
but then we'd end up with something like mplayer's status line, which
was cluttered and required a centralized approach (i.e. getting the data
to the status line; so it was all in mplayer.c). Some players can
visualize such statistics on OSD, but that sounds even more complicated.
So the approach added with this commit sounds sensible.
The stats-conv.py script is rather primitive at the moment and its
output is semi-ugly. It uses matplotlib, so it could probably be
extended to do a lot, so it's not a dead-end.
This was accidentally completely destroyed with commit 24f1878e. I
didn't notice it when testing, because forward seeking still worked
mostly.
The issue was that dvd_seek_to_time() actually called stream_seek(),
which was supposed to call the byte-level seek function dvd_seek(). So
we have to restore this function, and replace all generic stream calls
with stream_dvd.c internal ones. This also affects stream->pos (now a
random number as far as stream_dvd.c is concerned) and stream_skip().
The recent change of waking up the playback thread using a wakeup pipe
doesn't work on windows, because windows is horrible. So use a condition
variable instead to wake up the thread. To make things worse, jackaudio
is also horrible and "disallows" the use of mutexes, so all we can do is
implementing a half-solution that is not race condition free.
It would probably better to give up on this lock-free crap in the pull-
API audio path.
Mostly untested.
The audio subsystem now wakes up the playback thread explicitly, and we
don't need this anymore.
It still could cause dropouts and such if there are bugs in the recently
introduced audio changes, so this is a thing to watch out for.
Same change as in e2184fcb, but this time for pull based AOs. This is
slightly controversial, because it will make a fast syscall from e.g.
ao_jack. And according to JackAudio developers, syscalls are evil and
will destroy realtime operation. But I don't think this is an issue at
all.
Still avoid locking a mutex. I'm not sure what jackaudio does in the
worst case - but if they set the jackaudio thread (and only this thread)
to realtime, we might run into deadlock situations due to priority
inversion and such. I'm not quite sure whether this can happen, but I'll
readily follow the cargo cult if it makes hack happy.
I'm not quite sure why ao_pulse needs this. It was broken when a thread
to fill audio buffers was added to AO - the pulseaudio callback was
waking up the playback thread, not the audio thread. But nobody noticed,
so it can't be very important. In any case, this change makes it wake up
the audio thread instead (which in turn wakes up the playback thread if
needed).
And also add a function ao_need_data(), which AO drivers can call if
their audio buffer runs low.
This change intends to make it easier for the playback thread: instead
of making the playback thread calculate a timeout at which the audio
buffer should be refilled, make the push.c audio thread wakeup the core
instead.
ao_need_data() is going to be used by ao_pulse, and we need to
workaround a stupid situation with pulseaudio causing a deadlock because
its callback still holds the internal pulseaudio lock.
For AOs that don't call ao_need_data(), the deadline is calculated by
the buffer fill status and latency, as before.
qscale export has been completely removed from Libav 10, and FFmpeg has
an alternative API, so this code does nothing and only causes
deprecation warnings on Libav.
And slightly adjust the semantics of MPV_EVENT_PAUSE/MPV_EVENT_UNPAUSE.
The real pause state can now be queried with the "core-idle" property,
the user pause state with the "pause" property, whether the player is
paused due to cache with "paused-for-cache", and the keep open event can
be guessed with the "eof-reached" property.
This property is set to "yes" if playback was paused due to --keep-open.
The change notification might not always be perfect; maybe that should
be improved.
Currently this is (probably) equivalent to "paused-for-cache", but the
latter is a bit special, while this new property is a bit more general.
One case where they might actually be different is dvdnav menus, but I
haven't checked.
Also add property change notifications for these two properties.
We were relying on vsscript_freeScript() to take care of proper
termination. But it doesn't do that: it doesn't wait for the filters to
finish and exit at all. Instead, it just destroys all objects, which
causes the worker threads to crash sometimes.
Also, we're supposed to wait for the frame callback to finish before
freeing the associated node.
Handle this by explicitly waiting as far as we can. Probably fixes
crashes on seeking, although VapourSynth itself might also need some
work to make this case completely stable.
It's a bit strange to allow this, so get rid of it.
This probably breaks a bunch of user config files.
The client API still allows setting them with MPV_FORMAT_FLAG with a
value of 1 (i.e. true), but I guess this is tolerable.
The most user visible change is that "420p" is now displayed as
"yuv420p". This is what FFmpeg uses (almost), and is also less confusing
since "420p" is often confused with "420 pixels vertical resolution".
In general, we return the FFmpeg pixel format name. We still use our own
old mechanism to keep a list of exceptions to provide compatibility for
a while.
Also, never return NULL for image format names. If the format is unset
(0/IMGFMT_NONE), return "none". If the format has no name (probably
never happens, FFmpeg seems to guarantee that a name is set), return
"unknown".
This re-allows the previous behaviour of being able to reencode with
metadata removed, which is useful when encoding "inconsistently" tagged
data for a device/player that shows file names when tags are not
present.
Before this commit, the filter attempted to keep the vsscript state
(p->se) even when the script was reloaded. Change it to destroy the
script state too on reloading. Now no workaround for LoadPlugin is
necessary, and this also fixes a weird theoretical race condition when
destroying and recreating the mpv source filter.
I hate tabs.
This replaces all tabs in all source files with spaces. The only
exception is old-makefile. The replacement was made by running the
GNU coreutils "expand" command on every file. Since the replacement was
automatic, it's possible that some formatting was destroyed (but perhaps
only if it was assuming that the end of a tab does not correspond to
aligning the end to multiples of 8 spaces).
This is a read-only property that uses VFCTRL_GET_METADATA
to retrieve mp_tags metadata from a filter specified by label
Signed-off-by: wm4 <wm4@nowhere>
These playlist parsers are all what's left from the old mplayer playlist
parsing code. All of it is old code that does little error checking; the
type of C string parsing code that gives you nightmare.
Some playlist parsers have been rewritten and are located in
demux_playlist.c. The removed formats were not reimplemented. ASX and
SMIL use XML, and since we don't want to depend on a full blown XML
parser, this is not so easy. Possibly these formats could be supported
by writing a very primitive XML-like lexer, which would lead to success
with most real world files, but I haven't attempted that. As for NSC, I
couldn't find any URL that worked with MPlayer, and in general this
formats seems to be more than dead.
Move playlist_parse_file() to playlist.c. It's pretty small now, and
basically just opens a stream and a demuxer. No use keeping
playlist_parser.c just for this.
mpv was resizing to the same size before it went to fullscreen, we don't need to schedule a resize because the compositor will send a configure event with the new dimensions and thats when we should do it.
Basically a cheap hack to fix that the --msgmodule prefix will cause an
unwanted linebreak by making the line too long.
Suggested by Hamuko in github issue #710.
Fixes#710.
This is needed if you want to reimplement the status line in lua
I could only test drop-frame-count because I didn't find an easy way to
trigger paused-for-cache and total-avsync-change
Signed-off-by: wm4 <wm4@nowhere>
Mainly meant to apply simple VapourSynth filters to video at runtime.
This has various restrictions, which are listed in the manpage.
Additionally, this actually copies video frames when converting frame
references from mpv to VapourSynth, and a second time when going from
VapourSynth to mpv. This is inefficient and could probably be easily
improved. But for now, this is simpler, and in fact I'm not sure if
we even can references VapourSynth frames after the core has been
destroyed.
Commit 2c2c1203 sorted the output of --list-options, but the same code
ias also used for listing sub-options, such as --vo=scale:help. For sub-
options, the order actually matters.
Until now, --list-options printed options in random order. There
literally wasn't any logic in its order, they just appeared as they were
declared. So just sort them.
Note that we can't sort them in advance, because for certain things
internal to m_config, the order actually matters.
Also we're using strcasecmp(), which is bad (locale dependent), but this
is output intended for human consumption, so it's not a problem.
This used to display the property type, but it was not always correct or
even available. The way the property mechanism works, we can know this
only at runtime.
Otherwise, the client API user could not know why playback was stopped.
Regarding the fact that 0 is used both for normal EOF and EOF on error:
this is because mplayer traditionally did not distinguish these, and in
general it's hard to tell the real reason. (There are various weird
corner cases which make it hard.)
Although this is something really basic, Lua's standard library doesn't
provide anything like this. Probably because there are too many ways to
do it right or wrong.
This code tries to be really careful when dealing with mixed
arrays/maps, e.g. when a table has integer keys starting from 1, making
it look like an array, but then also has other keys.
The stats were retrieved and written on every encode call, instead of
every encode call that actually returned a packet. ffmpeg.c also does it
this way, so it must be "more correct". Fixes 2-pass encoding.
Our own tables have size for only 8 chars, so these sequences must be
rejected. It seems strings of length 8 are still ok, because the code
uses memcmp and not strcmp, so still allow these.
Based on mplayer-svn commit r37129.
I have some doubts that short reads are even allowed/
possible for /dev/js*, does someone know for sure?
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@37132 b3059339-0415-0410-9bf9-f77b7e298cf2
We needed this because the OSD rendering path used GBRP for RGB
rendering, and not all swscale versions supported this conversion. But
recently we've dropped support for very old ffmpeg/libav versions, so
this isn't needed anymore.
This was broken at some unknown point (even before the recent cache
changes). There are several problems:
- stream_dvd returning a random stream position, confusing the cache
layer (cached data and stream data lost their 1:1 corrospondence by
position)
- this also confused the mechanism added with commit a9671524, which
basically triggered random seeking (although this was not the only
problem)
- demux_lavf requesting seeks in the stream layer, which resulted in
seeks in the cache or the real stream
Fix this by completely removing byte-based seeking from stream_dvd. This
already works fine for stream_dvdnav and stream_bluray. Now all these
streams do time-based seeks, and pretend to be infinite streams of data,
and the rest of the player simply doesn't care about the stream byte
positions.
resize_cache() checks the size itself and clamps the size to the valid
range if necessary, so we don't need these checks. In fact, the checks
are different. Also, output the cache size after clamping, instead of
before.
Use NtQueryVolumeInformationFile instead of GetDriveType for detecting
remote filesystems on Windows. This has the advantage of working
directly on the file handle instead of needing a path and it works
unmodified in Cygwin where the previous code wouldn't understand Cygwin
paths or symlinks.
There is some risk in using NtQueryVolumeInformationFile, since it's an
internal function and its behaviour could change at any time or it could
be removed in a future version of Windows, however it's documented[1] in
the WDK and it's used successfully by Cygwin, so it should be fine. If
it's removed, the code should fail gracefully by treating all files as
local.
[1]: http://msdn.microsoft.com/en-us/library/windows/hardware/ff567070.aspx
Signed-off-by: wm4 <wm4@nowhere>
Merge the cache_read function into cache_fill_buffer, since there's
not much reason to keep them separate. Also, simply call read_buffer()
to see if there's any readable data, instead of checking for the
condition manually.
The only tricky part is keeping the cache contents, which is made simple
by allocating the new cache while still keeping the old cache around,
and then copying the old data.
To explain the "Don't use this when playing DVD or Bluray." comment: the
cache also associates timestamps to blocks of bytes, but throws away the
timestamps on seek. Thus you will experience strange behavior after
resizing the cache until the old cached region is exhausted.
The only difference is that the MP_DBG message is not printed anymore if
the current user read position is outside of the current cache range.
(In order to handle seek_limit==0 gracefully in the normal case of
linear reading, change the comparison from ">=" to ">".)
Until now, this could never happen, because new data was simply always
appended to the end of the cache. But for making stream cache resizing
easier, doing it this way seems advantageous. It also makes it harder to
make the internal state inconsistent. (Before this change it could
happen that cache and stream position went out of sync if the read
position was adjusted "inappropriately".)
Until now, cache_read() (which calls read_buffer()) could return short
reads. This was a simplification allowed by the stream interface. But
for cache resizing, it will be more practical to make read_buffer() do
a full read.
Seems like a good idea. One possible bad effect would be slowing down
uncached controls, but they're already slow. The good thing is that
many controls make intrusive changes to the stream (at least controls
which do write accesses), so the cached parameters should be updated.
Some of these property implementations already send notifications on
their own, but most don't. This takes care of them.
Of course this still doesn't handle all propertry changes - this is
impossible without special-casing each property that can change on its
own.
This might be a good idea in order to prevent queuing a frame too far in
the future (causing apparent freezing of the video display), or dropping
an infinite number of frames (also apparent as freezing).
I think at this point this is most of what we can do if the vdpau time
source is unreliable (like with Mesa). There are still inherent race
conditions which can't be fixed.
The strange thing about this code was the shift parameter of the
prev_vs2 function. The parameter is used to handle timestamps before the
last vsync, since the % operator handles negative values incorrectly.
Most callers set shift to 0, and _usually_ pass a timestamp after the
last vsync. One caller sets it to 16, and can pass a timestamp before
the last timestamp.
The mystery is why prev_vs2 doesn't just compensate for the % operator
semantics in the most simple way: if the result of the operator is
negative, add the divisor to it. Instead, it adds a huge value to it
(how huge is influenced by shift). If shift is 0, the result of the
function will not be aligned to vsyncs.
I have no idea why it was written in this way. Were there concerns about
certain numeric overflows that could happen in the calculations? But I
can't think of any (the difference between ts and vc->recent_vsync_time
is usually not that huge). Or is there something more clever about it,
which is important for the timing code? I can't think of anything
either.
So scrap it and simplify it.
vo_vdpau used a somewhat complicated and fragile mechanism to convert
the vdpau time to internal mpv time. This was fragile as in it couldn't
deal well with Mesa's (apparently) random timestamps, which can change
the base offset in multiple situations. It can happen when moving the
mpv window to a different screen, and somehow it also happens when
pausing the player.
It seems this mechanism to synchronize the vdpau time is not actually
needed. There are only 2 places where sync_vdptime() is used (i.e.
returning the current vdpau time interpolated by system time).
The first call is for determining the PTS used to queue a frame. This
also uses convert_to_vdptime(). It's easily replaced by querying the
time directly, and adding the wait time to it (rel_pts_ns in the patch).
The second call is pretty odd: it updates the vdpau time a second time
in the same function. From what I can see, this can matter only if
update_presentation_queue_status() is very slow. I'm not sure what to
make out of this, because the call merely queries the presentation
queue. Just assume it isn't slow, and that we don't have to update the
time.
Another potential issue with this is that we call VdpPresentationQueueGetTime()
every frame now, instead of every 5 seconds and interpolating the other
calls via system time. More over, this is per video frame (which can be
portantially dropped, and not per actually displayed frame. Assume this
doesn't matter.
This simplifies the code, and should make it more robust on Mesa. But
note that what Mesa does is obviously insane - this is one situation
where you really need a stable time source. There are still plenty of
race condition windows where things can go wrong, although this commit
should drastically reduce the possibility of this.
In my tests, everything worked well. But I have no access to a Mesa
system with vdpau, so it needs testing by others.
See github issues #520, #694, #695.
This turned out ridiculously complex. I think it will have to be
simplified some day. Main reason for the complexity are:
- filtering properties by forcing clients to observe individual
properties explicitly
(to avoid spamming clients with changes they don't want)
- optional retrieval of property value with the notification
(the basic idea was that this is more user friendly)
- allowing to the client to specify a format in which the value
should be retrieved
(because if a property changes its type, the client API couldn't
convert it properly, and compatibility would break)
I don't know yet which of these are important, and everything could
change. In particular, the interface and semantics should be adjusted
to reduce the implementation complexity.
While I consider the API complete, there could (and probably will) be
bugs left. Also while the implementation is complete, it's inefficient.
The complexity of the property matching is O(a*b*c) with a clients,
b observed properties, and c properties changing at once. I threw away
an earlier implementation using bitmasks, because it was too unwieldy.
Remove the use of mp_ring and use a simple array and a bunch of
variables instead. This is way less awkwad.
The change in reserve_reply fixes incorrect tracking of free events.
Now they can be paused and resumed.
Since pausing and disabling the timer is essentially the same underlying
operation, we also just provide one method for it.
mp.cancel_timer probably still works, but I'm considering this
deprecated, and it's removed from the manpage. (We didn't have a release
with this function yet, so no formal deprecation.)
This commit adds support for automatic selection of color profiles based on
the display where mpv is initialized, and automatically changes the color
profile when display is changed or the profile itself is changed from
System Preferences.
@UliZappe was responsible with the testing and implementation of a lot of this
commit, including the original implementation of `cocoa_get_icc_profile_path`
(See #594).
Fixes#594
The --ass-styles option is implemented by calling ass_read_styles().
This function can take a codepage (so libass will use iconv to convert
it). This was implemented before our --subcp option was changed, and
this code was not updated. Now libass fails opening iconv, because
--subcp is not always (and not by default) a valid iconv codepage.
Just always pass NULL, which means the file passed to --ass-styles must
be in UTF-8. The --ass-styles option is a fringe option anyway (and will
destroy your subtitles), so having codepage support for it isn't
important at all.
Change the type of the property from a string list (alternating
key/value entries) to a map. Using the client API, this will return
MPV_FORMAT_NODE_MAP, while Lua mp.get_property_native returns a
dictionary-like table.
The function tag_property() in command.c passed a key action with empty
path to m_property_read_list. This is normally not valid, because key
actions are supposed to access sub-paths. But it's kind of inconvenient
to check for this case in tag_property(). So make it valid by providing
a m_property_unkey() function, which turns a key access to "" into a
top-level action.
We've just checked whether a sub-path started with "name/", but that
changes behavior whether the property name has a trailing '/' or not.
Using a helper function to split of path components avoids this problem.
Also fix a format string mistake in a log call using it.
I wonder if this code shouldn't use FormatMessage, but it looks kind
of involved [1], so: no, thanks.
[1] http://support.microsoft.com/kb/256348/en-us
There are two kind of encryption for Blu-ray disc, AACS and BD+,
and both of them can be checked through BLURAY_DISC_INFO object.
This commit makes the bluray and bdnav streams refuse playback
if AACS/BD+ is detected and decryption is failed.
This played the file at a wrong sample rate if the rate was out of
certain bounds.
A comment says this was for the sake of libaf/af_resample.c. This
resampler has been long removed. Our current resampler
(libav/swresample) checks supported sample rates on reconfiguration, and
will error out if a sample rate is not supported. And I think that is
the correct behavior.
The angles should be set and queried only if a valid title is
selected. Also, in navigation mode, there are some limitations
which make it impossible to query current title/angle.
This commit introduces new stream protocols: bdnav(and others).
bdnav stream shares lots of codes with original bluray stream, so
it's not separated in different source file.
Major difference from bluray is that bdnav does not support longest
title because there is no way to query that information.
bdnav://menu and bdnav://first correspond to top menu title and
first play title respectively, though they often point same title.
Also, binary position based seeking has been removed, because it
didn't have no point.
Reduce most dependencies on struct mp_csp_details, which was a bad first
attempt at dealing with colorspace stuff. Instead, consistently use
mp_image_params.
Code which retrieves colorspace matrices from csputils.c still uses this
type, though.
This is pretty obscure, so it didn't matter much. It still breaks
switching output levels at runtime, because the video output is not
reinitialized with the new params.
This was accidentally broken in commit b72ba3f7. I somehow made the
wild assumption that replaygain adjusted the volume relative to 0%
instead of 100%.
The detach suboption was similarly broken.
This was actually supposed to be removed with pull reuqest #671, but
I accidentally re-added it with a rebasing mistake.
This probably also coincidentally fixes compilation with older
libbluray (issue #672).
Use bd_get_playlist_info() instead of bd_get_title_info(). The
previous implementation couldn't query current playlist and this
made it impossible to call bd_get_playlist_info() which is more
desirable than bd_get_title_info() because, for Blu-rays, playlist
is the unit of playback not title. This commit fixes that.
The cost of calling bd_get_title_info() is quite expensive and
requires lots of CPU usage. Using BD_EVENT_PLAYLIST and
BD_EVENT_TITLE, it's possible to cache BLURAY_TITLE_INFO object for
current title and BD_EVENT_ANGLE handler caches current angle. In
my test case, with this commit, CPU usage can be saved about 15-20%.
demux_mf.c explicitly checks for the stream type to check whether images
are opened via pattern (mf://..., i.e. stream_mf.c) or directly. Of
course the stream type is not set to STREAMTYPE_MF if the stream is
wrapped through the cache, so it tried to open the pattern directly as
file, which failed.
Fix this by disabling caching for mf://. The cache doesn't make sense
here anyway, because each file is opened and closed every frame (perhaps
to avoid memory bloat).
It's possible that MPContext has a chapter list, but the demuxer
doesn't. In this case, accesing the chapter-metadata property would
lead to invalid accesses.
(This fixes the out of bound access, but in theory, the returned data
can still be incorrect, since MPContext chapters don't need to map
directly to demuxer chapters.)
This cd_info_t struct was practically unused. The only thing it did was
storing the track name of the form "Track %d" in a very roundabout way.
Remove it. (It made more sense when there was still CDDB support.)
Don't use an integer division to get the time, since that would round on
second boundaries. Also round up the time by sector size. Seeking rounds
down due to alignment constraints, but if we round up the time, we can
make it land on the exact destination sector.
This fixes that the track change code printed the previous track when
seeking by chapter.
This was usually handled at the end of the switch statement, so if
something returns from the function before that, the event has to be
freed explicitly.
Previous implementation updated video resolution when highlight
event was given. However, this may not work if highlight event
is given before video size is queried.
This commit adds checking routine into rendering function, too.
dvdnav.c did not handle event in regular sequence. Usually this
does not make any trouble except around MP_NAV_EVENT_RESET_ALL.
Those events should be handled in regular sequence. If they're
mixed, it can make wrong result.
For instance, MP_NAV_EVENT_HIGHLIGHT right after
MP_NAV_EVENT_RESET_ALL should not be ignored but it might be
because MP_NAV_EVENT_RESET_ALL makes the demuxer reloaded and osd
hidden.
And consistently use MP_NOPTS_VALUE as error value for the users of this
function. This is better than using -1, especially because negative
values can be valid timestamps.
Instead of comparing the current chapter every time, set the playback
end timestamp to the chapter end. Likewise, don't execute an extra seek
for the start chapter.
Maybe we could also use the timeline facility to restrict playback to
the given chapter range, but this would be strange when using
--chapter=N to start playback at a given chapter. Then you couldn't seek
back, which is possibly not what the user wants.
Instead, always use the mpctx->chapters array. Before this commit, this
array was used only for ordered chapters and such, but now it's always
populated if there are chapters.
Stream-level chapters (like DVD etc.) did potentially not have
timestamps for each chapter, so STREAM_CTRL_SEEK_TO_CHAPTER and
STREAM_CTRL_GET_CURRENT_CHAPTER were needed to navigate chapters. We've
switched everything to use timestamps and that seems to work, so we can
simplify the code and remove this old mechanism.
Report the time for each chapter (tracks are treated as chapters). This
allows us to get rid of the "old" chapter mechanism, and also behaves
better with the frontend.
This makes assumptions about the audio formats, but that format is
hardcoded anyway in the rawaudio demuxer defaults (and always was).
Libav 10 was released, so we can enable testing the stable Libav version
again.
FFmpeg 2.2 was also released, but since we still support 2.1.4, we stick
with the older version. This is better for testing.
There were some bad interactions with the OSC.
For one, dragging the OSC bar, and then moving the mouse outside of the
OSC (while mouse button still held) would suddenly initiate window
dragging. This was because win_drag_button1_down was not reset when
sending a normal mouse event, which means the window dragging code can
become active even after we've basically decided that the preceding
click didn't initiate window dragging.
Second, dragging the window and clicking on the OSC bar after that did
nothing. This was because no mouse button up event was sent to the core,
even though a mouse down event was sent. So make sure the key state is
erased with MP_INPUT_RELEASE_ALL.
We don't check whether the WM supports _NET_WM_MOVERESIZE_MOVE, but
if it doesn't, nothing bad happens. There might be a race condition
when pressing a button, and then moving the mouse and releasing the
button at the same time; then the WM might get the message to initiate
moving the window after the mouse button has been released, in which
case the result will probably be annoying. This could possibly be fixed
by sending _NET_WM_MOVERESIZE_CANCEL on button release, but on the
other hand, we probably won't receive a button release event in this
situation, so ignore this problem.
The dragging is initiated only when moving the mouse pointer after a
click in order to reduce annoying behavior when the user is e.g.
doubleclicking.
Closes#608.
The title for stream_bluray DID start from 1 and I misunderstood
that it started from 0 because mpv accepted bd://0 as a proper
argument. In fact, 0 title was an alias for the longest title but
it was not handled as a special value. This commit fixes these
behavious. 'disc-title' property for Blu-ray now starts from 0 and
the default title can be specified by 'longest' title just like
stream_dvdnav: bd://longest. Of course, 'longest' can be omitted.
This commit makes 'disc-title' property writable using
STREAM_CTRL_SET_CURRENT_TITLE. This commit also contains
implementation of STREAM_CTRL_SET_CURRENT_TITLE for stream_bluray.
Currently, 'disc-title' is writable only for stream_dvdnav and
stream_bluray and stream_dvd is not supported.
This commit makes 'disc-title' properties for DVDs start from 0.
There was an inconsistency around 'disc-title' property between
DVDs (from 1) and Blu-rays (from 0). This fixes#648.
Signed-off-by: wm4 <wm4@nowhere>
This check incorrectly passed on Cygwin. While Cygwin has the
statfs.f_type field, it contains the volume's FileSystemAttributes,
which aren't useful for detecting network mounts.
"enable-osc" will make the OSC appear at any time (although it'll
quickly disappear again if the mouse is not inside the OSC). "disable-
osc" will make it disappear permanently.
Also, if the OSC is visible, force remap the DEL key to make the OSC
disappear.
Change script_message to broadcast the message to all clients. Add a new
script_message_to command, which does what the old script_message
command did.
This is intended as simplification, although it might lead to chaos too.
VAAPI has some ambiguous image formats, like VA_FOURCC_I420,
VA_FOURCC_IYUV, VA_FOURCC_YV12 (the latter exactly the same as the first
two, just with swapped planes). There is potentially a problem when one
specific VAAPI format was picked, and converting it to a mpv format and
back to a VAAPI FourCC would result in a numerically different format
(even if it's actually the same). Then it could e.g. happen that
functions like va_surface_upload() reallocate the underlying VAImage,
which would be inefficient. Change the code so that this can't happen.
(Probably not a problem in practice with the current VAAPI usage.)
It's not really needed to be public. Other code can just use mp_image.
The only disadvantage is that the other code needs to call an accessor
to get the VASurfaceID.
Although I at first thought it would be better to have a separate
implementation for hwaccels because the difference to software images
are too large, it turns out you can actually save some code with it.
Note that the old implementation had a small memory management bug. This
got painted over in commit 269c1e1, but is hereby solved properly.
Also note that I couldn't test vf_vavpp.c (due to lack of hardware), and
I hope I didn't accidentally break it.
The plan is to get rid of the custom VAAPI and possibly VDPAU surface
allocators.
Add custom surface allocation, because hwaccel surfaces are allocated
completely differently from software surfaces.
Add optional LRU allocation, which is (probably) helpful for hwaccel,
but (probably) less optimal for software surfaces.
mp_image_pool_get_no_alloc() is specifically for VAAPI, which can't
allocate new decoder surfaces after decoder init.
They were used by ancient libavcodec versions. This also removes the
need to distinguish vdpau image formats at all (since there is only
one), and some code can be simplified.
Image formats used to be FourCCs, so unsigned int was better. But now
it's annoying and the only difference is that unsigned int is more to
type than int.
Instead of doing it on every seek (libavcodec calls get_format on every
seek), reinitialize the decoder only if the video resolution changes.
Note that this may be relatively naive, since we e.g. (or: in
particular) don't check for profile changes. But it's not worse than the
state before the get_format change, and at least it paints over the
current vaapi breakage (issue #646).
Set refcounted_frames, because in some versions of libavcodec mixing the
new AVFrame API and non-refcounted decoding could cause memory
corruption. Likewise, it's probably still required to unref a frame
before calling the decoder.
This follows the (only slowly progressing) plan to replace all internal
video filters with libavfilter.
All what's left in vf_gradfun.c is the weird wrapper around vf_lavfi.c.
I have no tolerance for this garbage anymore. There are tons of issues
with it (see e.g. previous commit), and there is no reason to use it
either. Use Libav git, or Libav 10 when it's released.
This also drops support for earlier FFmpeg release, which have exactly
the same issues as Libav 9. FFmpeg 2.1.4 is still supported, because
it's the latest release, and is reasonably recent. (Although this will
probably also be dropped as soon as FFmpeg 2.2 is released.)
Assumed version table (lots of nonsensical numbers):
FFmpeg 2.1.4 FFmpeg (n2.2-rc2) Libav (v10_beta2)
lavu 52.48.101 52.66.100 53.3.0
lavc 55.39.101 55.52.102 55.34.1
lavf 55.19.104 55.33.100 55.12.0
lsws 2.5.101 2.5.101 2.1.2
lavi 3.90.100 4.2.100 4.2.0
lswr 0.17.104 0.18.100 -
lavr 1.1.0 1.2.0 1.1.0
libpostproc and libavdevice are not interesting.
Following this commit, code needed just to support old Libav versions
will start to be removed.
This "sometimes" crashed when seeking. The fault apparently lies in
libavcodec: the decoder returns an unreferenced frame! This is
completely insane, but somehow I'm apparently still expected to
work this around. As a reaction, I will drop Libav 9 support in the
next commit. (While this commit will go into release/0.3.)
Instead of parsing the ASS file in demux_libass.c and trying to pass the
ASS_Track to the subtitle renderer, just read all file data in
demux_libass.c, and let the subtitle renderer pass the file contents to
ass_process_codec_private(). (This happens to parse full files too.)
Makes the code simpler, though it also relies harder on the (messy)
probe logic in demux_libass.c.
They're strictly DVD-only, so it's better to mark them as such. This
also documentes the "title" (now renamed to "dvd-title") property.
This also avoids collision with the --title option. (Technically, there
was no problem. But it might be confusing for users, since we have a
policy of naming properties and options the same if they refer to the
same underlying functionality.)
This commit adds new property 'title' which indicates current
playing title of disc. This property is useful when using a stream
whose title can be changed during playback, e.g., dvdnav.
This commit provides impelmentation of STREAM_CTRL_GET_NUM_TITLES
for dvdnav stream. Other streams for DVD or Blu-ray are already
provide STREAM_CTRL_GET_NUM_TITLES.
Maybe this should be default. On the other hand, this filter does
something even if the volume is neutral: it clips samples against the
allowed range, should the decoder or a previous filter output garbage.
Currently, both replaygain adjustment and user volume control (if
softvol is enabled) share the same variable. Sharing the variable would
cause especially if --volume is used; then the replaygain volume would
always be overwritten.
Now both gain values are simple added right before doing filtering.
Xlib.h (included from x11_common.h) defines a macro 'Status' as 'int'.
This messed up a bunch of definitions in windows.h and broke the build
in Cygwin. Including windows.h first seems to solve the problem.
This commit also removes the definition of an unused flag.
This adds the options replaygain-track and replaygain-album. If either is set,
the replaygain track or album gain will be automatically read from the track
metadata and the volume adjusted accordingly.
This only supports reading REPLAYGAIN_(TRACK|ALBUM)_GAIN tags. Other formats
like LAME's info header would probably require support from libav.
The main incompatibility was that Libav didn't have av_opt_set_int_list.
But since that function is excessively ugly and idiotic (look how it
handles types), I'm not missing it much. Use an aformat filter instead
to handle the functionality that was indirectly provided by it. This is
similar to how vf_lavfi works.
The other incompatibility was channel handling. Libav consistently uses
channel layouts only, why ffmpeg still requires messing with channel
counts to some degree. Get rid of most channel count uses (and hope
channel layouts are "exact" enough). Only in one case FFmpeg fails with
a runtime check if we feed it AVFrames with channel count unset.
Another issue were AVFrame accessor functions. FFmpeg introduced these
for ABI compatibility with Libav. I refuse to use them, and it's not my
problem if FFmpeg doesn't manage to provide a stable ABI for fields
provided both by FFmpeg and Libav.
And make some additions.
I'm not really sure why we list dependencies that are not ours, but that
of external libraries. Still might be useful, though.
I've tried not to be too detailed (because it's not a reference, just
some guidelines), but it still got relatively long. Also contains
conventions for sending patches.
The window doesn't recieve a WM_LBUTTONUP message after it's dragged,
probably because it's swallowed by the modal loop. To stop the button
from sticking, release it manually when the drag is complete.
Mouse buttons can get stuck down if the button is pressed inside the
video window and released outside. Avoid this by capturing mouse input
when a button is pressed.
Linux also has fstatfs(), and the test relied on certain system include
files being available on BSD, but not on Linux. It would break if Linux
added the missing includes for some reason.
Make it a bit stricter, and check for the struct statfs field the code
needs.
This reads MPV_CLIENT_API_VERSION from the source header, and turns it
into a 3 part version number.
E.g. if MPV_CLIENT_API_VERSION were 0x12abcdef, this would result in
"18.171.773615" (8 bits, 8 bits, 16 bits).
We'll see if this is actually useful, or if it's too clever.
Rename it to --enable-libmpv-shared. The option name didn't really
tell much. When we add the possibility to create a static library,
it would also be bad if that were named --enable-static (because it
would sound like it does what --static-build does).
The volume controls in mpv now affect the session's volume (the
application's volume in the mixer). Since we do not request a
non-persistent session, the volume and mute status persist across mpv
invocations and system reboots.
In exclusive mode, WASAPI doesn't have access to a mixer so the endpoint
(sound card)'s master volume is modified instead. Since by definition
mpv is the only thing outputting audio in exclusive mode, this causes no
conflict, and ao_wasapi restores the last user-set volume when it's
uninitialized.
Due to the COM Single-Threaded Apartment model, the thread owning the
objects will still do all the actual method calls (in the form of
message dispatches), but at least this will be COM's problem rather than
having to set up several handles and adding extra code to the event
thread.
Since the event thread still needs to own the WASAPI handles to avoid
waiting on another thread to dispatch the messages, the init and uninit
code still has to run in the thread.
This also removes a broken drain implementation and removes unused
headers from each of the files split from the original ao_wasapi.c.
ao_wasapi.c was almost entirely init code mixed with option code and
occasionally actual audio handling code. Split most things to
ao_wasapi_utils.c and keep the audio handling code in ao_wasapi.c.
Gets rid of the internal ring buffer and get_buffer. Corrects an
implementation error in thread_reset.
There is still a possible race condition on reset, and a few refactors
left to do. If feasible, the thread that handles everything
WASAPI-related will be made to only handle feed events.
This reverts commit 75dd3ec210.
This broke seeking with ordered chapters in some situations. While
the reverted commit was perfectly fine for playback of normal files,
it overlooked that in the ordered chapters case switching segments
actually reinitialized the audio chain completely, including the
decoder. And decoders still read packets on initialization. We can
restore the original commit as soon as decoders stop doing this.
Apparently the "right" place to initialize the hardware decoder is in
the libavcodec get_format callback.
This doesn't change vda.c and vdpau_old.c, because I don't have OSX, and
vdpau_old.c is probably going to be removed soon (if Libav ever manages
to release Libav 10). So for now the init_decoder callback added with
this commit is optional.
This also means vdpau.c and vaapi.c don't have to manage and check the
image parameters anymore.
This change is probably needed for when libavcodec VDA supports gets a
new iteration of its API.
This updates the logic for the new, somewhat unified behavior of SRGB
and 3DLUT since 34bf9be (not that it was particularly correct even that
change) and checks for the presence of corresponding extensions only in
the cases in which they're needed.
This commit:
- Changes some of the #define and variable names for clarification and
adds comments where appropriate.
- Unifies :srgb and :icc-profile, making them fit into the same step of
the decoding process and removing the weird interactions between both
of them.
- Makes :icc-profile take precedence over :srgb (to significantly reduce
the number of confusing and useless special cases)
- Moves BT709 decompanding (approximate or actual) to the shader in all
cases, making it happen before upscaling (instead of the old 0.45
gamma function). This is the simpler and more proper way to do it.
- Enables the approx gamma function to work with :srgb as well due to
this (since they now share the gamma expansion code).
- Renames :icc-approx-gamma to :approx-gamma since it is no longer tied
to the ICC options or LittleCMS.
- Uses gamma 2.4 as input space for the actual 3DLUT, this is now a
pretty arbitrary factor but I picked 2.4 mainly because a higher pure
power value here seems to produce visually better results with wide
gamut profiles, rather then the previous 1.95 or BT.709.
- Adds the input gamma space to the 3dlut cache header in case we change
it more in the future, or even make it user customizable (though I
don't see why the latter would really be necessary).
- Fixes the OSD's gamma when using :srgb, which was previously still
using the old (0.45) approximation in all cases.
- Updates documentation on :srgb, it was still mentioning the old
behavior from circa a year ago.
This commit should serve to both open up and make the CMS/shader code much
more accessible and less confusing/error-prone and simultaneously also
improve the performance of 3DLUTs with wide gamut color spaces.
I would liked to have made it more modular but almost all of these
changes are interdependent, save for the documentation updates.
Note: Right now, the "3DLUT takes precedence over SRGB" logic is just
coded into gl_lcms.c's compile_shaders function. Ideally, this should be
done earlier, when parsing the options (by overriding the actual
opts.srgb flag) and output a warning to the user.
Note: I'm not sure how well this works together with real-world
subtitles that may need to be color corrected as well. I'm not sure
whether :approx-gamma needs to apply to subtitles as well. I'll need to
test this on proper files later.
Note: As of now, linear light scaling is still intrinsically tied to
either :srgb or :icc-profile. It would be thinkable to have this as an
extra option, :linear-scaling or similar, that could be used with or
without the two color management options.
Assume obtained.samples contains the number of samples the SDL audio
callback will request at once. Then make sure ao.c will set the buffer
size at least to 3 times that value (or more).
Might help with bad SDL audio backends like ESD, which supposedly uses a
500ms buffer.
This obviously doesn't work. It wasn't much of a problem in the past
because most passthrough formats use 2 channels, which is also the
default for downmix.
In general, we don't need to have a large hw audio buffer size anymore,
because we can quickly fill it from the soft buffer.
Note that this probably doesn't change much anyway. On my system (dmix
enabled), the buffer size is only 170ms, and ALSA won't give more. Even
when using a hardware device the buffer size seems to be limited to
341ms.
This AO pretended to support volume operations when in spdif passthrough
mode, but actually did nothing. This is wrong: at least the GET
operations must write their argument. Signal that volume is unsupported
instead.
This was probably a hack to prevent insertion of volume filters or so,
but it didn't work anyway, while recovering after failed volume filter
insertion does work, so this is not needed at all.
Since the addition of the AO feed thread, 200ms of latency (MIN_BUFFER)
was added to all push-based AOs. This is not so nice, because even AOs
with relatively small buffering (e.g. ao_alsa on my system with ~170ms
of buffer size), the additional latency becomes noticable when e.g.
toggling mute with softvol.
Fix this by trying to keep not only 200ms minimum buffer, but also 200ms
maximum buffer. In other words, never buffer beyond 200ms in total. Do
this by estimating the AO's buffer fill status using get_space and the
initially known AO buffer size (the get_space return value on
initialization, before any audio was played). We limit the maximum
amount of data written to the soft buffer so that soft buffer size and
audio buffer size equal to 200ms (MIN_BUFFER).
To avoid weird problems with weird AOs, we buffer beyond MIN_BUFFER if
the AO's get_space requests more data than that, and as long as the soft
buffer is large enough.
Note that this is just a hack to improve the latency. When the audio
chain gains the ability to refilter data, this won't be needed anymore,
and instead we can introduce some sort of buffer replacement function in
order to update data in the soft buffer.
It is possible to have ao->reset() called between ao->pause() and
ao->resume() when seeking during the pause. If the underlying PCM
supports pausing, resuming an already reset PCM will produce an error.
Avoid that by explicitly checking PCM state before calling
snd_pcm_pause().
Signed-off-by: wm4 <wm4@nowhere>
The uint64_t math would cause overflow at long enough system uptimes
(...such as 3 days), and any precision error given by the double math will
be under one milisecond.
One strange issue is that we apparently can't stop the audio API on
audio reset (ao_driver.reset). We could use SDL_PauseAudio, but that
doesn't specify whether remaining audio is dropped. We also could use
SDL_LockAudio, but holding that over a long time will probably be bad,
and it probably doesn't drop audio. This means we simply play silence
after a reset, instead of stopping the callback completely. (The
existing code ran into an underrun in this situation.)
The delay estimation works about the same. We simply assume that the
callback is locked to audio timing (like ao_jack), and that 1 callback
corresponds to 1 period. It seems this (removed) code fragment assumes
there 1 one period size delay:
// delay subcomponent: remaining audio from the next played buffer, as
// provided by the callback
buffer_interval += callback_interval;
so we explicitly do that too.
Apparently, this is always _really_ monotonic, despite what the Linux
manpages say. So this should be much better than gettimeofday(). (At
times there were kernel bugs which broke the monotonic property.)
From the perspective of the player, time can still be discontinuous
(you could just stop the process with ^Z), but at least it's guaranteed
to be monotonic without further hacks required.
Also note that clock_gettime() returns the time in nanoseconds. We want
microseconds only, because that's the unit we chose internally. Another
problem is that nanoseconds can wrap pretty quickly (less than 300 years
in 63 bits), so it's just better to use microseconds. The devision won't
make the code that much slower (compilers can avoid a real division).
Note: this expects that the system provides clock_gettime() as well as
CLOCK_MONOTONIC. Both are optional according to POSIX. The only system
I know which doesn't have these, OSX, has seperate timer code anyway,
but I still don't know whether more obscure (yet supported) platforms
have a problem with this, so I'm playing safely. But this still expects
that CLOCK_MONOTONIC always works at runtime if it's defined.
This is probably "safer". Without it, we will play 1 sample, because the
logic was written in a way to decode 1 sample if audio is paused. 1
sample usually will initialize the audio PTS, but not play any real
audio. Also see previous commit.
In ancient times, this actually used 1 byte (instead of 1 sample), so
clearly no sample was written, unless the audio was 8-bit mono.
Remove the ao_buffer_playable_samples field. This contained the number
of samples that fill_audio_out_buffers() wanted to write to the AO (i.e.
this data was supposed to be played at some point), but ao_play()
rejected it due to partial fill.
This could happen with many AOs, notably those which align all written
data to an internal period size (often called "outburst" in the AO
code), and the accepted number of samples is rounded down to period
boundaries. The left-over samples at the end were still kept in
mpctx->ao_buffer, and had to be played later.
The reason ao_buffer_playable_samples had to exist was to make sure that
at EOF, the correct number of left-over samples was played (and not
possibly other data in the buffer that had to be sliced off due to
endpts in fill_audio_out_buffers()). (You'd think you could just slice
the entire buffer, but I suspect this wasn't done because the end time
could actually change due to A/V sync changes. Maybe that was the reason
it's so complicated.)
Some commits ago, ao.c gained internal buffering, and ao_play() will
never return partial writes - as long as you don't try to write more
samples than ao_get_space() reports. This is always the case. The only
exception is filling the audio buffers while paused. In this case, we
decode and play only 1 sample in order to initialize decoding (e.g. on
seeking). Actually playing this 1 sample is in fact a bug, but even of
the AO doesn't have period size alignment, you won't notice it. In
summary, this means we can safely remove the code.
Until now, this was always conflated with uninit. This was ugly, and
also many AOs emulated this manually (or just ignored it). Make draining
an explicit operation, so AOs which support it can provide it, and for
all others generic code will emulate it.
For ao_wasapi, we keep it simple and basically disable the internal
draining implementation (maybe it should be restored later).
Tested on Linux only.
Same deal as with the previous commit. We don't lose any functionality,
except for waiting "properly" on audio end, instead of waiting using the
delay estimate.
This removes the ringbuffer management from the code, and uses the
generic code added with the previous commit. The result should be
pretty much the same.
The "estimate" sub-option goes away. This estimation is now always
active. The new code for delay estimation is slightly different, and
follows the claim of the jack framework that callbacks are timed
exactly.
This has 2 goals:
- Ensure that AOs have always enough data, even if the device buffers
are very small.
- Reduce complexity in some AOs, which do their own buffering.
One disadvantage is that performance is slightly reduced due to more
copying.
Implementation-wise, we don't change ao.c much, and instead "redirect"
the driver's callback to an API wrapper in push.c.
Additionally, we add code for dealing with AOs that have a pull API.
These AOs usually do their own buffering (jack, coreaudio, portaudio),
and adding a thread is basically a waste. The code in pull.c manages
a ringbuffer, and allows callback-based AOs to read data directly.
Since the AO will run in a thread, and there's lots of shared state with
encoding, we have to add locking.
One case this doesn't handle correctly are the encode_lavc_available()
calls in ao_lavc.c and vo_lavc.c. They don't do much (and usually only
to protect against doing --ao=lavc with normal playback), and changing
it would be a bit messy. So just leave them.
We want to move the AO to its own thread. There's no technical reason
for making the ao struct opaque to do this. But it helps us sleep at
night, because we can control access to shared state better.
This field will be moved out of the ao struct. The encoding code was
basically using an invalid way of accessing this field.
Since the AO will be moved into its own thread too and will do its own
buffering, the AO and the playback core might not even agree which
sample a PTS timestamp belongs to. Add some extrapolation code to handle
this case.
Use QueryPerformanceCounter to improve the accuracy of
IAudioClock::GetPosition.
While this is mainly for "realtime correctness" (usually the delay is a
single sample or less), there are cases where IAudioClock::GetPosition
takes a long time to return from its call (though the documentation doesn't
define what a "long time" is), so correcting its value might be important in
case the documented possible delay happens.
The lack of device latency made get_delay report latencies shorter than
they should; on systems with fast enough drivers, the delay is not
perceptible, but high enough invisible delays would cause desyncs.
I'm not yet completely sure whether this is 100% accurate, there are
some issues involved when repeatedly pausing+unpausing (the delay might
jump around by several dozen miliseconds), but seeking seems to be
working correctly now.
The player didn't quit when the end of a file was reached. The reason
for this is that jack reported a constant audio delay even when all
audio was done playing. Whether that was recognized as EOF by the player
depended whether the exact value was higher or lower than the player's
threshhold for what it considers no more audio.
get_delay() should return amount of time it takes until the last sample
written to the audio buffer reaches the speaker. Therefore, we have to
track the estimated time when the last sample is done, and subtract it
from the calculated latency. Basically, the latency is the only amount
of time left in the delay, and it should go towards 0 as audio reaches
ths speakers.
I'm not sure if this is correct, but at least it solves the problem. One
suspicious thing is that we use system time to estimate the end of the
audio time. Maybe using jack_frame_time() would be more correct. But
apart from this, there doesn't seem to be a better way to handle this.
For example, consider the case when audio initialization fails. Then the
audio track is deselected. Before this commit, this would have been
equivalent to the user disabling audio. This is bad when multiple files
are played at once (the next file would have audio disabled, even if it
works), or if playback resume is used (if e.g. audio output failed to
initialize, then audio would be disabled when resuming, even if the
system's audio driver was fixed).
Setting string options to strings over the m_option fallback (i.e.
M_PROPERTY_SET_STRING is called if the option type is CONF_TYPE_STRING)
failed. This was because m_option_parse() returns 0. 0 still means
success, but the property code tried to be clever, and considered 0 not
a success in order to disallow setting flags to an emtpy string (which
in turn is allowed, because the command line allows flag options without
parameters).
Fix this by removing the overly clever code.
This could happen when e.g. using the "set" command on options/title (a
string option), and also was a problem for the client API.
Closes#610.
The OSC used significant CPU time while the player was paused. It turned
out that the "tick" event sent during pause is the problem. The OSC
accesses the player core when receiving a tick event, which in turn will
cause the core to send another tick event, leading to infinite feedback.
Fix this by sending an idle tick only every 500ms. This is not very
proper, but the idea behind the tick event isn't very clean to begin
with (and the OSC should use timers instead).
The playloop usually waits in select(), using a timeout needed for
refilling audio and video buffers. This means the client API needs
a separate mechanism to interrupt the select() call. This mechanism
exists, but I forgot to use it. This commit fixes it.
If it works, this will make the client API react faster, epsecially
in audio-only mode. If video is enabled, the reaction time is capped
to 50ms (or somewhat faster if the framerate is >20 fps), because
the playloop stops reacting to anything in order to render and time
the next video frame. (This will be fixed later by moving the VO
to its own thread.)
--ass-style-override=force now attempts to override the 'Default' style.
May or may not work. In some situations it will work, but also mess up
seemingly unrelated things like signs typeset with ASS.
luaL_loadstring(), which was used until now, uses the start of the Lua
code itself as chunk name. Since the chunk name shows up even with
runtime errors triggered by e.g. Lua code loaded from user scripts, this
looks a but ugly. Switch to luaL_loadbuffer(), which is almost the same
as luaL_loadstring(), but allows setting a chunk name.
Will be helpful to track down strange wait times and such issues, as
well when you have develop something timing related. (Then you may print
timestamps in your debug output, and the --msgtime timestamps will help
giving context.)
Sending an asynchronous request and then calling mpv_destroy() would
crash the player when trying to send the reply to the removed client.
Fix this by waiting until all remaining replies have been sent.
The step argument for "add volume <step>" was ignored until now. Fix it.
There is one problem: by defualt, "add volume" should use the value set
with --volstep. This value is 3 by default. Since the default volue for
the step argument is always 1 (and we don't really want to make the
generic code more complicated by introducing custom step sizes), we
simply multiply the step argument with --volstep to keep it compatible.
The --volstep option should probably be just removed in the future.
The value range is 0-100, so fractional values don't make much sense.
But the underlying data type is probably float to avoid getting "stuck"
when doing small volume increments. So step this around and pretend it's
an integer just on display.
The previous version of the gamma suboption was pretty useless. It could
be used to disable delayed gamma enabling, which is a mechanism to avoid
having to adjust gamma in the shader by default.
Repurpose the suboption and allow setting an exact gamma value with it.
You can already override gamma with the --gamma option as well as the
gamma input property, but these use a weird curve to create the
impression of a linear perceived brightness change when changing the
value. This suboption now allows setting an exact gamma value.
This used to be absolute colorimetric, but relative colorimetric is a
saner default due to the arguments presented in issue #595.
A short summary: In general it doesn't affect much because our eyes
adapt to the white point either way, but if running in windowed mode it
would make the whites seem inconsistent/tinted. For fullscreen
projection it's also undesirable since it reduces the dynamic range
without much benefit (again, since our eyes adapt either way) and it
also breaks calibration against ambient lighting.
This shouldn't change much, since most profile types that aren't 3DLUTs
aren't capable of either of those transforms, and most displays are
calibrated against D65 (same as BT.709 source) either way.
Lua doesn't distinguish between arrays and maps on the language level;
there are just tables. Use metatables to mark these tables with their
actual types. In particular, it allows distinguishing empty arrays from
empty tables.
When passing a very large timeout to mpthread_cond_timed_wait(), the
calculations could overflow, setting tv_sec to a negative value, and
making the pthread_cond_timed_wait() call return immediately. This
accidentally made Lua support poll and burn CPU for no reason.
The existing overflow check was ineffective on 32 bit systems. tv_sec is
usually a long, so adding INT_MAX to it will usually not overflow on 64
bit systems, but on 32 bit systems it's guaranteed to overflow. Simply
fix by clamping against a relatively high value. This will work until 1
week before the UNIX time wraps around in 32 bits.
Always map MPV_FORMAT_STRING to setting property value directly through
M_PROPERTY_SET_STRING, instead of trying to go through
M_PROPERTY_SET_NODE.
This treats a direct MPV_FORMAT_STRING query differently from a
MPV_FORMAT_STRING wrapped in a mpv_node. This was already the case in
mpv_get_property(). The reason for all this is that mpv_node is supposed
to be the exact type, while a direct MPV_FORMAT_STRING goes through all
possible conversions.
Not sure if these semantics are good.
This is a bit weird: m_option_string types (i.e. char*) can be NULL. But
they're supposed to be treated just like empty strings. So don't make
the m_option_type.print function return NULL for these values. Returning
NULL would mean failure.
This didn't matter much before, but was quite visible through the client
API.
1. Cannot set option after initialized: it seems that this bug has
existed since libmpv was introduced first. Maybe just a typo.
2. Crash when setting property with native format: mpv_set_property
just causes a crash when using a native format. I found an invalid
casting and fixed it.
3. Wrong error value for mpv_get_property: when an error occurred,
mpv_get_property always returns wrong format error because every
error for property except M_PROPERTY_NOT_IMPLEMENTED is just ignored.
Signed-off-by: wm4 <wm4@nowhere>
Closes pull request #593. Does not incldue the first fix, which was not
correct. The underlying bug will be fixed by a later commit.
Commit message extracted from pull request and slightly edited.
E.g. binding MOUSE_BTN0 always used the user defined binding. While it
is ok that the user can override mouse_move and mouse_leave (for
whatever reasons), we want to strictly override the bindings when input
is sent to the OSC itself.
Regression since 03624a1.
This lowers the number of data stored in the resume config a bit
further, because some properties can't be read at program start and when
e.g. the VO wasn't created yet.
Some fields still need to be read from a property (actually only
"volume-restore-data", a hack to save the full volume information). So
abuse the "options/" property, and make use of the fact that changing
things at runtime also changes the options.
This is approximate: we read each option value on program start
(before starting playback of a file), and when writing the resume
config, compare each value to the current state. This also means
when a value is changed and then changed back, it's not stored. In
particular, option values set in config files and on the command
line are considered the default.
This should help reducing the numbers of options overridden by the
resume config. If too much is overridden, it becomes an inconvenience,
because changes in config files will apparently have no effect when
resuming a file.
Also see github issue #574.
This might be helpful if we ever want cascading config files. Also, we
will probably need it if we change the default input.conf bindings, and
want to provide compatibility input.conf files.
This created an essentially empty config file. This is not really
needed and probably causes more trouble than it solves (such as
littering the home directory with crap), so get rid of it.
This was broken by commit bb6b543812. Note that the original pull
request was fine, but it was broken by my own stupidity when I was
"improving" it.
The problem is that the new loadfile argument was not considered
optional anymore after my changes. The original pull request did handle
this by setting .defval to a dummy value, but I removed that part.
Fix it again by introducing a flag that designates that the parameter is
optional. (I didn't want to add it to m_option.h, because technically,
all options are optional, and it's not possible to have non-optional
options.)
Not sure about this... might redo.
At least this provides a case of a broadcasted event, which requires
per-event data allocation.
See github issue #576.
May or may not be useful in some ways.
We require a context parameter for this just to be sure, even if the
internal implementation currently doesn't.
That's one less mpv internal function for the Lua wrapper.
Also mention that NULL isn't valid. Although I'm not sure whether the
implementation strictly follows this (it should, but there are some
wacky corner cases).
There are some complications because the client API distinguishes
between integers and floats, while Lua has only "numbers" (which are
usually floats). But I think this should work now.
This is only half-implemented: actually the option will first be
converted from mpv_node to its native type, then it's converted to a
string, and then back to its native type. This is because the option
API was made for strings and not anything else.
Other than being grossly inelegant, the only downside is probably with
string lists and key/value lists, which don't escape strings containing
syntax elements correctly.
This automatically allows accessing properties like chapter-list and
track-list to be read as mpv_node. This affects all properties which use
m_property_read_sub() and m_property_read_list().
This actually makes use of the client.h declarations and the mpv_node
mechanisms added some commits ago.
For now, using MPV_FORMAT_STRING will usually fallback to explicit
string conversion, but not in the other cases. E.g. reading a numeric
property as string will work, but not reading a string property as
number. Other than that, only MPV_FORMAT_INT64->MPV_FORMAT_DOUBLE does
an automatic conversion.
I'm not sure whether these semantics and API are good, so comments and
suggestions are welcome.
Allows retrieving properties by their native values (or something close
to it), rather than having to go through string conversion. The caller
could actually just copy the value itself and then use the m_option
functions to convert it to mpv_node, but maybe it's more flexible this
way.
m_option is basically the mechanism to handle C data types in a dynamic
way. Add functions to convert values to and from mpv_node. For example,
string lists are turned into mpv_node using MPV_FORMAT_NODE_ARRAY, and
so on.
This adds declarations for new formats. The implementation will be added
in the following commits. (It still compiles and runs with this commit,
because it adds constants only.)
The obvious new types are MPV_FORMAT_FLAG, MPV_FORMAT_INT64,
MPV_FORMAT_DOUBLE. MPV_FORMAT_FLAG is a boolean, but to avoid nasty ABI
issues or with languages that don't have a bool data type (C89), it uses
int. Thus the format is not named MPV_FORMAT_BOOL, to avoid confusion.
The MPV_FORMAT_NONE type (mpv_node) is a generic structured type, like a
variant or, say, JSON. It can store strings/bools/numbers, as well as
arrays and key/value pairs (with string keys only).
The MPV_FORMAT_NODE_ARRAY and MPV_FORMAT_NODE_MAP types are used
internally by mpv_node only and can't be used with most of the other API
(like mpv_set_property()) directly.
With mpv_set_property(h, "property", MPV_FORMAT_STRING, ptr), ptr now
has to be of type char** instead of char*. This makes it more consistent
with mpv_get_property() and also non-pointer formats, which will be
introduced in the following commits. mpv_set_property() of course does
not change its interface (only its implementation is adjusted to keep
its interface).
This also affects mpv_set_option(), but again not
mpv_set_option_string().
This is allowed in C99 and C++11, but apparently not in C89 and C++98.
Make it conform to the older standards, since we want the client API
header to be highly portable.
This uses the value of 1.95 as an approximation for the exact gamma
curve, which replicates the behavior of popular video software including
anything in the Apple ecosystem, as per issue #534.
Until now, strings were the only allowed dynamically allocated argument
type in input commands. Extend it so that it works for any type. (The
string expansion in command.c is of course still string specific.)
If this function could return the input value (i.e. the == case was
correct), then macros like MP_GROW_ARRAY would have been incorrect. The
implementation was correct though, so there's no bug.
Some code accessed m_option.name to get the property name. (Maybe only
show_property_osd() had a significant use of it.) Remove that, and
remove setting names and dummy names as well.
The old code usually assumed that the name was set, and
show_property_osd() used it to get the proper name of deprecated
aliases.
The "vf" property was listed as "vf*". Not sure why that was done, but
it works without anyway.
Doesn't require other code to care about this, which will allow us to
simplify the property code.
Only "wildcard" options like "vf" and string lists used this, and
m_option_list_findb() (which is excused).
M_OPT_PARSE_ESCAPES was pretty stupid, and broke the (useful) assumption
that string variables contain exactly the same value as set by the
option. Simplify it, and move escape handling to the place where it's
used.
Escape handling itself is not terribly useful, but still allows useful
things like multiline custom OSD with "\n".
MP_CMD_COMMAND_LIST commands (used to implement key bindings with
multiple commands) were not checked for abort commands. Implement it.
Remove the remarks about multi-commands being special from the manpage.
Seek coalescing is handled differently now, and the issue with abort
commands is fixed with this commit.
Current code stolen from waf's extras, only supported 'pe' and 'elf'. OS X
uses the 'Mach-O' binary format (which waf calls 'mac-o'... go figure).
Add support for generating the global symbols file with nm and using it from
clang.
The old way still works, and is fine to use. Still discourage it,
because it might conflict with other ways to access this property, such
as the one added in the next commit.
This is a regression introduced from moving Lua scripts (including the
OSC) to their own threads. Now OSC and dvdnav can add their bindings at
the same time without coordination, which seems to result in the OSC
winning most time, and thus overriding the dvdnav menu bindings.
Fix this by adding a flag that makes dvdnav menu bindings take priority
over all other bindings.
When timeline was used, and the --start option was not used, the initial
seek (needed to switch to the first timeline segment) seeked to -1 due
to an oversight.
This is simply not important enough to warrant so much space, and it's
perhaps also very confusing.
Although I'm not fully sure, since this is about the only way that
allows a user to interact with a script, besides key bindings and static
options.
Detected 'protocols' are AFP, nfs, smb and webdav. This can be extended on
request.
This is currently only implemented for BSD systems (using fstatfs). This
addresses issue #558 on the above platforms.
There was already an undocumented mechanism provided by
mp.set_key_bindings and other functions, but this was relatively
verbose, and also weird. It was mainly to make the OSC happy (including
being efficient and supporting weird corner cases), while the new
functions try to be a bit simpler.
This also provides a way to let users rebind script-provided commands.
(This mechanism is less efficient, because it's O(n^2) for n added key
bindings, but it shouldn't matter.)
- Adds description of and uses $JOBS envvar in MXE instructions
- Adds MXE_TARGETS to command line instead of echoing it to settings.mk
- Prettify and sentence usage
This adds a mechanism for easier export of sub-properties. The following
commits will make use of it to export fine grained information about
certain things. The sub-property mechanism reduces the amount of code
needed to export a data value to 1 line.
* 'master' of git://github.com/mpv-player/mpv:
win32: restore support for exe directory as config directory
crosscompile-mingw: improve instructions for MXE
sd_lavc: handle subtitles with no subtitle resolution set
options: make --no-config block all auto-loaded configuration files
lua: auto-load scripts from ~/.mpv/lua/
lua: make register_event() not overwrite previous event handler
It seems that it was causing issues with certain perl setups (such as
the one on issue #549). It also turns out that it was not behaving correctly
(not all constants were being promoted to big nums as they should), so we
use explicit objects to derive the constants.
There were also precedence issues. I wonder if this even worked right to
begin with.
The 'double' path (8-byte floats) is untested, as I couldn't easily find
a file with such a field.
Closes#549.
Set subtitle resolution to video resolution when avctx->width and
avctx->height are zero.
This can happen with broken vobsubs that have no size set in their
.idx file (or Matroska extradata). At least with the test file provided
in issue #551, using the video resolution as fallback instead of what
guess_resolution() does is better.
Note that these files clearly are broken. It seems this particular
file was created by trying to use ffmpeg to transcode DVB subtitles
to vobsub, and ffmpeg "forgot" to set the subtitle resolution in the
destination file. On the other hand, ffmpeg DVB and PGS decoders set
the resolution on the first subtitle packet (or somewhere close), so
it's not really clear what to do here.
Closes#551.
Signed-off-by: wm4 <wm4@nowhere>
Patch by xylosper, rewritten commit message by wm4.
Until now, the --no-config was explicitly checked in multiple places to
suppress loading of config files.
Add such a check to the config path code itself, and refuse to resolve
_any_ configuration file locations if the option is set.
osc.lua needs a small fixup, because it didn't handle the situation when
no path was returned. There may some of such cases in the C code too,
but I didn't find any on a quick look.
Instead, chain them.
Note that there's no logic to prevent the other event handlers to be run
from an event handler (like it's popular in GUI toolkits), because I
think that's not very useful for this purpose.
Cygwin's libc (newlib) doesn't obey a lot of unix feature test macros,
including _GNU_SOURCE; as a result, a lot of functions and defines get
masked out -- important defines such as M_PI and strcasecmp. Work around
it by undefining __STRICT_ANSI__ on cygwin systems.
This will still cause compilation issues on any non-cygwin system that
uses newlib, but hopefully nobody does that, or if they do, they will
find this commit message and know to add -U__STRICT_ANSI__ to their
CFLAGS. Hopefully.
The mplayer decoder (spudec.c) actually handled this. There was explicit
code for binary palettes (16 32 bit values), and the subtitle resolution
was handled by video resolution coincidentally matching the subtitle
resolution.
Whoever puts vobsub into mp4 should be punished.
Fixes the sample gundam_sample.mp4, closes github issue #547.
In particular, this affects drag & drop of subtitles, which uses sub_add
internally. This will make the subtitles show up immediately, instead of
requiring manual selection of the added subtitle.
Might be not so ideal when adding multiple subtitles at once, because
that leads to multiple sub_add commands, and will end up with the last
subtitle instead of the first selected. But this is a minor detail.
The minimum required version was bumped in the old configure script, but
for the waf build system is was somehow forgotten or overlooked.
Probably happened while the waf build system was developed in a separate
branch.
Closes#546.
This is the same issue as addressed by 257d9f1, except this time for
the :srgb option as well. (257d9f1 only addressed :icc-profile)
The conditions of the srgb_compand mix() call are also flipped to
prevent an off-by-one error.
Use a list instead of a table. This makes it easier to provide extended
information about a property, and doesn't require you to fiddle with rhe
RST ASCII-art tables.
Also, extend some property descriptions.
The initialization code was split and refactored for the libmpv changes.
One change, moving a part of cocoa initialization, accidentally broke
--force-window on OSX, which creates a VO in a certain initialization
stage. We still don't know how cocoa should behave with libmpv, so fix
this with a hack to beat it back into working. Untested.
I was unhappy with the old way of handling buffers, especially resizing. But my
original plan to use wl_shm_pool_resize wasn't as good as I initially thought.
I might get back to it.
With the new buffer pools it now possible to select triple buffering. Also the
buffer pools are also needed for the upcoming subsurfaces for osd and subtitles.
I hope this change was worth it.
Use of these is "discouraged", but they're there to select these special
cases with the "aspect" property. They really should use some sort of
choice option type, but since it would be some work to make these work
with float values, the simple and dumb alternative was picked.
Return the error Lua-style, instead of raising it as Lua error. This is
better, because raising errors is reserved for more "fatal" conditions.
Pretending they're exceptions and trying to do exception-style error
handling will just lead to pain in this language.
Print a warning if a library has mismatched compile time and link time
versions.
Refuse to work if the compile time and link time versions are a mix of
ffmpeg and libav. We print an error message and call exit(). Since we'd
randomly crash anyway, I think this is ok.
This doesn't catch the case if you e.g. use a ffmpeg libavcodec and a
libav libavformat, which would of course just crash as quickly, but I
think this checks enough already.
This library will export the client API functions.
Note that this doesn't allow compiling the command line player to link
against this library yet. The reason is that there's lots of weird stuff
required to setup the execution environment (mostly Windows and OSX
specifics), as well as things which are out of scope of the client API
and every application has to do on its own. However, since the mpv
command line player basically reuses functions from the mpv core to
implement these things, it's not very easy to separate the command
line player form the mpv core.
This is partial only, and it still accesses some MPContext internals.
Specifically, chapter and track lists are still read directly, and OSD
access is special-cased too.
The OSC seems to work fine, except using the fast-forward/backward
buttons. These buttons behave differently, because the OSC code had
certain assumptions how often its update code is called.
The Lua interface changes slightly.
Note that this has the odd property that Lua script and video start
at the same time, asynchronously. If this becomes an issue, explicit
synchronization could be added.
Add a client API, which is intended to be a stable API to get some rough
control over the player. Basically, it reflects what can be done with
input.conf commands or the old slavemode. It will replace the old
slavemode (and enable the implementation of a new slave protocol).
This avoids trouble if another mpv instance is initialized in the same
process.
Since timeBeginPeriod/timeEndPeriod are hereby not easily matched
anymore, use an atexit() handler to call timeEndPeriod, so that we
can be sure these calls are matched, even if we allow multiple
initializations later when introducing the client API.
It's quite possible to overflow the calculation by setting the timeout
to high values. Limit it to INT_MAX, which should be safe. The issue is
mainly the secs variable.
timespec.tv_sec will normally be 64 bit on sane systems, and we assume
it can't overflow by adding INT_MAX to it.
This skipped all audio packets before the first video key frame was
found. I'm not really sure why this would be needed; most likely it
isn't. So get rid of it. Even if audio packets are returned to the
player too soon, the player will sync the audio start to the video
start by decoding and discarding audio data.
Note that although the removed code was just added in the previous
commit, it merely kept the old keeping semantics which demux_mkv
always followed. This commit removes these special semantics.
v_skip_to_keyframe is set to true while non-keyframe video packets are
skipped. Until now, audio packets were also skipped when doing this. I
can't see any good reason why this would be done, but for now I want to
keep the old logic when audio+video seeks are done.
However, for audio-only mode, do proper seeking, which also fixes
behavior when trying to seek past the end of the file: playback is
terminated properly, instead of starting playback on the start of the
last cluster.
Note that a_no_timecode_check is used only for audio+video seek. I'm
not sure what this is needed for, but it might influence A/V sync after
seeking.
This sometimes happened when changing playback speed (= reinitializing
audio) after seeking of playback start. The assertion in audio.c:441 was
triggered, because buffer_playable_samples wasn't reset correctly when
the audio buffer was cleared or shortened. The assertion is correct and
should hold up any time.
I could not see any difference whatsoever, but for usage with a 3DLUT
there's zero performance difference so we might as well follow the spec to
the letter.
On Windows, no ANSI control sequences are available, so we can't easily
clear lines, move the cursor, etc. It's yet to be decided how this
should be handled (emulate ANSI escapes in osdep/terminal-win.c, or
provide abstracted terminal API functions to unify the Linux and Windows
code).
For now, this fixes the regression that was introduced earlier by the
status line rewrite. It doesn't fix all aspects of status line and
terminal OSD handling, as can be clearly seen by the unconditional use
of terminal_erase_to_end_of_line further down the changed code.
Fixes github issue #499 (sort of).
Trying to set a non-existent flag (like +keepside on Libav) causes
libavutil print an incomprehensible warning (something about eval;
probably the overengineered libavutil option parser tripping over the
'+' normally used for flags, and trying to interpret it as formula).
There's apparently no easy way to check for the existence of a flag,
so add some more ifdeffery to shut it up.
The code removed from handle_input_and_seek_coalesce() did two things:
1. If there's a queued seek, stop accepting non-seek commands, and delay
them to the next playloop iteration.
2. If a seek is executing (i.e. the seek was unqueued, and now it's
trying to decode and display the first video frame), stop accepting
seek commands (and in fact all commands that were queued after the
first seek command). This logic is disabled if seeking started longer
than 300ms ago. (To avoid starvation.)
I'm not sure why 1. would be needed. It's still possible that a command
immediately executed after a seek command sees a "seeking in progress"
state, because it affects queued seeks only, and not seeks in progress.
Drop this code, since it can easily lead to input starvation, and I'm
not aware of any disadvantages.
The logic in 2. is good to make seeking behave much better, as it
guarantees that the video display is updated frequently. Keep the core
idea, but implement it differently. Now this logic is applied to seeks
only. Commands after the seek can execute freely, and like with 1., I
don't see a reason why they couldn't. However, in some cases, seeks are
supposed to be executed instantly, so queue_seek() needs an additional
parameter to signal the need for immediate update.
One nice thing is that commands like sub_seek automatically profit from
the seek delay logic. On the other hand, hitting chapter seek multiple
times still does not update the video on chapter boundaries (as it
should be).
Note that the main goal of this commit is actually simplification of the
input processing logic and to allow all commands to be executed
immediately.
Legacy GL context creation (glXCreateContext) explicitly requires a X
visual, while the modern one (glXCreateContextAttribsARB) does not for
some reason. So fail only on the legacy code path if we don't find a
visual. Note that vo_x11_config_vo_window() will select a default visual
if a NULL visual is passed to it.
This fixes issue #504. For some reason, glXChooseFBConfig() will return
a fbconfig with no associated visual. (I'm not sure if this allowed.
They don't always have a visual, but since GLX_X_RENDERABLE is set
and GLX_DRAWABLE_TYPE is (implicitly) set to GLX_WINDOW_BIT, why would
there be no visual?)
Even worse, a test program seems to show that a 16 bit fbconfig is
selected (instead of 24/32 bit), which doesn't sound nice at all. Since
there _are_ better fbconfigs available, glXChooseFBConfig() should
normally sort them by quality, and return the better ones first. It's
worth noting that this function should also prefer GLX_TRUE_COLOR
over anything else, although this comes last in the sort order.
Whatever is going on, requesting GLX_X_VISUAL_TYPE with GLX_TRUE_COLOR
seems to fix it.
There is some logic to discard packets from streams that are not
selected. Run the metadata update code before this, just to make 100%
sure that no metadata updates can be lost when streams are deselected.
(I'm not sure why this logic would be needed, since both libavformat and
the generic demuxer code do this already. But a quick test shows that
av_read_frame() can return a packet from a stream even if the stream has
AVStream.discard set to AVDISCARD_ALL. This happened after stream
switching. Maybe libavformat doesn't discard already queued packets.)
Instead of printing lines like:
Demuxer info GENRE changed to Alternative Rock
Just output all tags once they change. The assumption is that individual
tags rarely change, while all tags change in the common case.
This changes tag updates to use polling. This could be fixed later,
although the ICY stuff makes it a bit painful, so maybe it will remain
this way.
Also remove DEMUXER_CTRL_UPDATE_INFO. This was intended to check for tag
updates, but now we use a different approach.
Use an arbitrary constant instead, which is as good as PATH_MAX.
This helps us to avoid having to think about pull request #523.
Also fix a case where a potentially signed char was passed to isspace().
This was done incorrectly in the previous commit: the fallback size used
the window size as requested with the first config call, which is the
size of the hidden window in the vo_opengl case. (That damn hidden
window again...)
This code essentially does nothing. As far as I could find out, this
actually used to do something. Then it was removed with commit efe7c39f,
leaving some leftover code that didn't do anything useful. This happened
12 years ago!
Also remove a commented debug printf.
vo_opengl creates a hidden X11 window to probe the OpenGL context. It
must do that before creating a visible window, because VO creation and
VO config are separate phases.
There's a race condition involving the hidden window: when starting with
--fs, and then leaving fullscreen, the unfullscreened window is
sometimes set to the aspect ratio of the hidden window. I'm not sure why
the window size itself uses the correct size (but corrupted by the wrong
aspect), but that's perhaps because the window manager is free to ignore
the size hint while honoring the aspect, or something equally messed up.
It turns out this happens because x11_common.c thinks the size of the
hidden window is the size of the unfullscreened window. This in turn
happens because vo_x11_update_geometry() reads the size of the hidden
window when called in vo_x11_fullscreen() (called from
vo_x11_config_vo_window()) when mapping the fullscreen window. At that
point, the window could be mapped, but not necessarily. If it's not
mapped, it will get the size of the unfullscreened window... I think.
One could fix this by actively waiting until the window is mapped. Try
to pick a less hacky approach instead, and never read the window size
until MapNotify is received.
vo_x11_create_window() needs a hack, because we'd possibly set the VO's
size to 0, resulting e.g. in vdpau to fail initialization. (It'll print
error messages until a proper resize is received.)
This fixes a weird bug with aspect ratio handling. It has to do with
float handling: with -std=gnu99, gcc implicitly enables broken non-
standard semantics giving float variables excess precision. This can for
example make this fail in theory: "float a = 0.1; assert(a == a);"
While standard C allows excess precision _within_ expressions, it
requires truncation when storing float values in variables of types
"float" or "double". The "gnu99" mode breaks this. It can be unbroken by
using "c99", or by specifying -fexcess-precision=standard. The former
seems less likely to break compilers other than modern gcc. Note that
-ffloat-store would also fix this, but also makes float expressions less
efficient and less precise for no reason.
The code that mistakenly fails because of this is dec_video.c line 393.
It caused the container aspect to be ignored in some or all situations,
depending how the compiler optimizes. For example, on gcc-4.6 with -Os,
the aspect is always ignored.
In future, we should probably just get rid of storing aspects as floats.
Note that this still happens in the stream level, so we can't have
nice highlevel behavior restricting seeking. Instead, if a seek leads
to the demuxer requesting data outside of the cached range, the seek
will simply fail. This might confuse the demuxer, and the resulting
behavior is not necessarily useful.
Note that this also doesn't try to skip data on a forward seek. This
would just freeze the stream with slow unseekable streams.
One nice thing is that stream.h has a separate function for merely
skipping data (separate from seeking forward), which is pretty useful
in this case: we want skipping of data to work, even if we reject
seeking forward by skipping data as too expensive. This probably is
or will be useful for demux_mkv.c.
Usually, you have to call pthread_cond_timedwait() in a loop (because it
can wake up sporadically). If this function is used by another higher
level function, which uses a relative timeout, we actually have to
reduce the timeout on each iteration - or, simpler, compute the
"deadline" at the beginning of the function, and always pass the same
absolute time to the waiting function.
Might be unsafe if the system time is changed. On the other hand, this
is a fundamental race condition with these APIs.
This used to work; I'm not sure when or why it regressed. When setting
AVProbeData.filename to NULL, libavformat will crash in rtp_probe() by
unconditionally accessing the string.
We used to set the filename to NULL to prevent probing by file extension
when we don't deem it as necessary. Using an empty string also works for
this purpose.
Try to make it more intuitive by not requiring hex values. The new way
uses float values in the range 0.0-1.0, separated by '/' (':' was
suggested, but that wouldn't allow color options in sub-options).
Example: --osd-color=1.0/0.0/0.0/0.75
Using the range 0.0-1.0 has the advantage that it could be easily
extended to colors beyond 8 bit.
Details see manpage.
Suggestions for alternative syntax or value ranges are welcome, but be
quick with it.
This avoids stray newlines when:
1. Some (non-status line) text was output
2. Then an empty status line is output
According to the logic, 2. should print an empty line to show the blank
status line. Don't do that, and instead output nothing in this case.
This caused problems with mpv_identify.sh, and also looked ugly when
using --quiet.
Larger sizes can introduce overflows, depending on the image format. In
the worst case, something larger than 16000x16000 with 8 bytes per pixel
will overflow 31 bits.
Maybe there should be a proper failure path instead of a hard crash, but
not yet. I imagine anything that sets a higher image size than a known
working size should be forced to call a function to check the size (much
like in ffmpeg/libavutil).
Not everything in the OSD path handles 0x0 sized sub-bitmaps well. At
least the code implementing --sub-gray had severe problems with it.
Fix this by skipping such bitmaps.
RGB565 is one of the fastest and most supported formats on low end consumer
devices, but ffmpeg spams warning when using it. Make it opt-in instead of
opt-out.
The problem seems to have solved itself. I guess the previous changes to
resizing and commit ba101ab made this possible. Consider me happy for removing
that crap.
Windows applications that use LoadLibrary are vulnerable to DLL
preloading attacks if a malicious DLL with the same name as a system DLL
is placed in the current directory. mpv had some code to avoid this in
ao_wasapi.c. This commit just moves it to main.c, since there's no
reason it can't be used process-wide.
This change can affect how plugins are loaded in AviSynth, but it
shouldn't be a problem since MPC-HC also does this and it's a very
popular AviSynth client.
Windows users expect this when a program crashes. Without it, the
program just disappears. Also change the SetErrorMode call to use macros
instead of a hardcoded constant.
If, for some reason, the subtitle renderer attempts to render a
subtitle before SD_CTRL_SET_VIDEO_PARAMS was called, it passed a
value calculated from invalid values. This can happen with --vf=sub
and --start. The crash happens if 1. there was a subtitle packet that
falls into the timestamp of the rendered video frame, 2. the playloop
hasn't informed the subtitle decoder about the video resolution yet
(normally unneeded, because that is used for weird corner cases only,
so this code is a bit fuzzy), and 3. something actually requests a
frame to be drawn from the subtitle renderer, like with vf_sub.
The actual crash was due to passing NaN as pixel aspect to libass,
which then created glyphs with ridiculous sizes, involving a few
integer overflows and unchecked mallocs.
The sd_lavc.c and sd_spu.c cases probably don't crash, but I'm not
sure, and it's better fix them anyway.
Not bothering with sd_spu.c, this crap is for compatibility and will
be removed soon.
Note that this would have been no problem, had the code checked whether
SD_CTRL_SET_VIDEO_PARAMS was actually called. This commit adds such a
check (although it basically checks after using the parameters).
Regression since 49caa0a7 and 633fde4a.
This generally affects mp3 files that don't have any (or many) mp3
frames in the first 2 MB. 2 MB is the maximum probe size, and
libavformat returns a low probescore even if we give it the full 2 MB.
Trying to probe a larger buffer (or even the full file) doesn't work for
mysterious reasons.
The workaround consists in accepting a very weak probescore if the
format is detected as mp3 and we probed already 2 MB.
Restructure it a bit, so we can use the format hack list even if no mime
type applies. Shouldn't change anything functionally yet. Preparation
for the next commit.
Still untested, because now it crashes inside of libSDL for unknown
reasons. (This also happens with mpv git from yesterday - probably an
installation problem, or SDL doing weird things it shouldn't be doing.)
The main difference between the old and new callbacks is that the old
callbacks required passing the window size, which is and always was very
inconvenient and confusing, since the window size is already in
vo->dwidth and vo->dheight.
Balance controls as used by mixer.c was broken, because af_pan.c stopped
accepting its arguments. We have to allow 0 channels explicitly. Also,
fix null pointer access if the matrix parameter is not used.
Regression from commit 82983970.
If there's more than one edition, print the list of editions, including
the edition name, whether the edition is selected, whether the edition
is default, and the command line option to select the edition. (Similar
to stream list.)
Move reading the tags to a separate function process_tags(), which is
called when all other state is parsed. Otherwise, that tags will be lost
if chapters are read after the tags.
Pretty worthless. This is called from the seek code, which will
reinitialize these anyway. Even if seeking somehow decides to fail, the
new values are still valid.
One could say a failed seek (if that happens) should jump back to the
original position, and thus it would be better to make sure the state
is restored. But then demux_mkv_seek needs to do this correctly,
including not setting up skipping to the target timestamp. But not
bothering with this.
Extremely obscure corner case with concatenated segments, in which EOF
wasn't recognized correctly, and it tried to demux clusters from the
next segment.
See [MKV]_Editions,_Linked_Segments,_&_Tracksets.mkv from the CCCP test
file collection.
This basically used to be part of the user interface, before mpv moved
printing the track list to the frontend, and this code was raised to
verbose output level.
For some reason, if an error happened when reading headers, it merely
stopped reading the headers, and then continued normally. (It looks like
the case to exit hard (-2) was mainly used for skipping unwanted ordered
chapter segments.)
I can't comprehend this. Always exit on error when reading headers.
(Maybe some more error tolerance would be good, but I have no test case,
and there's some danger of entering endless loops.)
This makes everything more robust, and also somewhat simpler (even if
the diffstat isn't very impressive).
Instead of recursively following SeekHeads while reading headers, just
read the headers until the first cluster, and then possibly use
SeekHeads to read the remaining missing headers.
Rename vo_get_src_dst_rects() to mp_get_src_dst_rects() and make it
independent from the VO (it takes a comical amount of parameters now to
pass all required state). Add a convenience wrapper with the name
vo_get_src_dst_rects() to vo.c. Replace all aspdat and vo usages with
immediate parameters.
Functionally, nothing should change, except that the window size is
clamped to a minimum of size 1 much earlier, and some log messages
change the prefix (don't bother with vo.vo_log stuff).
The plan is to make all the code in aspect.c independent from vo.c,
which should make the code easier to understand, will allow removal of
vo->aspdat, and reduces the amount of code that accesses weird mutable
struct vo fields.
vo->aspdat is basically an outdated version of vo->params, plus some
weirdness. Get rid of it, which will allow further cleanups and which
will make multithreading easier (less state to care about).
Also, simplify some VO code by using mp_image_set_attributes() instead
of caring about display size, colorspace, etc. manually. Add the
function osd_res_from_image_params(), which is often needed in the case
OSD renders into an image.
Some mpv builds identify with e.g. "mpv b'0.3.3' ". The version looks
like str() was called on a Python byte string. I couldn't reproduce it
on my machine (I tried with both Python 2 and 3), so I'm not exactly
sure what's going on here, but I'm hoping this commit does fix it.
This was broken yesterday: the playlist demuxer will always fall back to
plaintext playlist files, which will cause the ASX playlist parser and
some others never to be called.
This is probably ok. Probing could hit this case very often, since it'll
mean running this function on potentially binary data, but on the other
hand, probing usually uses a memory stream (to limit the amount of data
read), and memory streams have s->log silenced (details see
open_memory_stream()).
This simplifies the implementation and should make it more robust. For
example, we return an error if a line is longer than the provided buffer
(instead of splitting the line).
The code is much shorter, because now finding the new line and reading
characters is done in one go.
As of this commit, stream_read_line() can't actually error (except in
the case the passed in buffer is 0, which never happens here). This
commit is preparation for the following commit, which checks harder
whether the read data is actually text. Before this commit, an error
was treated as end-of-file, but the data read so far was considered
valid.
Signed-off-by: wm4 <wm4@nowhere>
This merges pull request #496. The problem was that at least the
initialization of the distance[] array accessed af_fmtstr_table[]
entries that were out of bounds. Small cosmetic changes applied to
the original pull request.
Doesn't affect the generated code, but avoids confusion
in both humans and newer Coverity versions.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36623 b3059339-0415-0410-9bf9-f77b7e298cf2
The struct we need to copy is actually a cdrom_msf0, not cdrom_msf.
Even though the kernel for no good reason reads it in as a
cdrom_msf struct, but only uses the part shared with cdrom_msf0 -
this is probably a kernel bug.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36622 b3059339-0415-0410-9bf9-f77b7e298cf2
Do two things:
1. add locking to struct osd_state
2. make struct osd_state opaque
While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses
lots of osd_state (and osd_object) members. To make sure everything is
accessed synchronously, I prefer making osd_state opaque, even if it
means adding pretty dumb accessors.
All of this is meant to allow running VO in their own threads.
Eventually, VOs will request OSD on their own, which means osd_state
will be accessed from foreign threads.
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
These were needed before the last commit, but now they don't do anything
anymore. (They were used to decide whether to replace or stack the
previous OSD message when a new one was displayed.)
If certain OSD messages were displayed at the same time, the hidden
messages were put on the stack, and displayed again once the higher
priority messages disappeared. The idea was probably that lower priority
messages could not hide higher priority ones, and also that the lower
messages did not get lost.
But in practice, this gives confusing results with OSD messages randomly
reappearing for a brief time. Remove it.
Showing subtitles on terminal used the OSD message stack (which uses a
stack to "pile up" messages that were displayed at the same time). This
had a bunch of weird and annoying consequences. This accessed a certain
osd_state field, which is a minor annoyance since I want to make that
struct opaque. Implement this differently.
The values set by this new option can be queried by Lua scripts using
the mp.getopt() function. The function takes a string parameter, and
returns the value of the first key that matches. If no key matches, nil
is returned.
When the Lua code was written, the core didn't have names for log levels
yet (just numbers). The only user visible change is that "verbose"
becomes "v", since this level had different names.
Adds the following Lua function to enable message events:
mp.enable_messages(size, level)
size is the maximum number of messages the ringbuffer consists of. level
is the minimum log level for a message to be added to the ringbuffer,
and uses the same values as the mp.log() function. (Actually not yet,
but this will be fixed in the following commit.)
The messages will be delivered via the mp_event() in the user script,
using "message" as event name. The event argument is a table with the
following fields:
level: log level of the message (string as in mp.log())
prefix: string identifying the module of origin
text: contents of the message
As of currently, the message text will contain newline characters. A
message can consist of several lines. It is also possible that a
message doesn't end with a newline, and a caller can use multiple
messages to "build" a line. Most messages will contain exactly 1 line
ending with a single newline character, though.
If the message buffer overflows (messages are not read quickly enough),
new messages are lost until the queued up messages are read. At the
point of the overflow, a special overflow message is inserted. It will
have prefix set to "overflow", and the message text is set to "".
Care should be taken not to print any messages from the message event
handler. This would lead to an infinite loop (the event handler would be
called again after returning, because a new message is available). This
includes mp.log() and all mp.msg.* functions. Keep in mind that the Lua
print() function is mapped to mp.msg.info().
Until now, mp_msg output always went to the terminal. There was no way
to grab the stream of output messages. But this will be needed by
various future changes: Lua scripts, slave mode, client library...
This commit allows registering a ring buffer. A callback would be more
straight-forward, but since msg.c sits at the bottom of the lock
hierarchy (it's used by virtually everything), this would probably be a
nightmare. A ring buffer will be simpler and more predictable in the
long run.
We allocate new memory for each ringbuffer entry, which is probably a
bit expensive. We could try to be clever and somehow pack the data
directly into the buffer, but I felt like this wouldn't be worth the
complexity. You'd have to copy the data a bunch of times anyway. I'm
hoping that we can get away with using the ringbuffer mechanism for
low frequency important messages only (and not e.g. for high volume
debug messages), so the cost doesn't matter that much.
A ringbuffer has a simple, single log level. I considered allowing
--msglevel style per-prefix configuration for each ringbuffer, but
that would have been pretty complicated to implement, and wouldn't
have been that useful either.
This makes
mp_msg(x, y, "a\nb\n")
behave the same as
mp_msg(x, y, "a\n")
mp_msg(x, y, "b\n")
which is probably what one would expect. Before this commit, the "b"
line didn't have a prefix when using ths single mp_msg call.
Before that, it just returned -1.
The print case is inconsistent with that, but I'll leave it for now,
because it's consistent with status line / show_progress behavior.
This is a bit of a hack, but in order to prevent TranslateMessage from
seeing WM_KEYDOWN messages that we already know how to decode, move the
decoding logic to the event loop. This should fix#476, since it stops
the generation of extraneous WM_CHAR messages that were triggering more
than one action on keydown.
Starting a network stream could stall by executing uncacheable stream
control requests (STREAM_CTRL_GET_LANG and STREAM_CTRL_GET_DVD_INFO).
Being uncacheable means the player has to wait until the cache is done
reading the current block of data. These requests can't be cached
because they're too complicated, so the only way to avoid them is
special casing the DVD and Bluray streams (which are the only things
which need these requests), and not doing them in other cases.
(This is kind of inelegant, but so is the rest of the DVD/BD code.)
Application icon was added to the Dock only when run inside of a bundle. That
was handled automatically by OS X using the Info.plist definition.
To add the Application icon when run as a CLI program, I used the samme
approach in the X11 code and loaded the icon as a static binary blob inside
of mpv's binary. This is the simplest approach as it avoid headackes when
relocating the binary and such.
Many ebml_read_* functions have a length int pointer parameter, which
returns the number of bytes skipped. Nothing actually needed this
(anymore), and code using it was rather hard to understand, so get rid
of them.
Matroska makes it pretty hard to resync correctly on broken files:
random data returns "valid" EBML IDs with a high probability, and when
trying to skip them it's likely that you skip a random amount of data
(instead of considering the element length invalid).
Improve upon this by skipping known level 1 elements only. Consider
everything else invalid and call the resync code. This might result in
annoying behavior when Matroska adds new level 1 elements, although it
won't be particularly harmful. Matroska doesn't really allow us to do
better (even mkvtoolnix explicitly checks for known level 1 elements).
Since we now don't always want to combine EBML element skipping and
resyncing, remove ebml_read_skip_or_resync_cluster(), and make
ebml_read_skip() more tolerant against skipping broken elements.
Also, don't resync when reading sub-elements, and instead do resyncing
when reading them results in an error.
Until now, corrupted files were detected if the size of an element (that
should be skipped) was larger than the remaining file. This still could
skip larger regions of the file itself if the broken size happened to be
within the file.
Change it so that it's never allowed to skip outside the parent's
element.
The terminal OSD code includes the handling of the terminal status line,
showing player OSD messages on the terminal, and showing subtitles on
terminal (the latter two only if there is no video window, or if
terminal OSD is forced).
This didn't handle some corner cases correctly. For example, showing an
OSD message on the terminal always cleared the previous line, even if
the line was an important message (or even just the command prompt, if
most other messages were silenced).
Attempt to handle this correctly by keeping track of how many lines the
terminal OSD currently consists of. Since there could be race conditions
with other messages being printed, implement this in msg.c. Now msg.c
expects that MSGL_STATUS messages rewrite the status line, so the caller
is forced to use a single mp_msg() call to set the status line.
Instead of littering print_status() all over the place, update the
status only once per playloop iteration in update_osd_msg(). In audio-
only mode, the status line might now be a little bit off, but it's
perhaps ok.
Print the status line only if it has changed, or if another message was
printed. This might help with extremely slow terminals, although in
audio+video mode, it'll still be updated very often (A-V sync display
changes on every frame).
Instead of hardcoding the terminal sequences, use
terminfo/termcap to get the sequences. Remove the --term-osd-esc option,
which allowed to override the hardcoded escapes - it's useless now.
The fallback for terminals with no escape sequences for moving the
cursor and clearing a line is removed. This somewhat breaks status line
display on these terminals, including the MS Windows console: instead of
querying the terminal size and clearing the line manually by padding the
output with spaces, the line is simply not cleared. I don't expect this
to be a problem on UNIX, and on MS Windows we could emulate escape
sequences. Note that terminal OSD (other than the status line) was
broken anyway on these terminals.
In osd.c, the function get_term_width() is not used anymore, so remove
it. To remind us that the MS Windows console apparently adds a line
break when writint the last column, adjust screen_width in terminal-
win.c accordingly.
Seeking usually show the status on OSD. In terminal OSD mode, no status
is shown, because there is already a separate status line.
Unfortunately, the mechanism for showing the status was still active,
which forced showing no message while the code for showing seek status
was active.
Insane .ass subtitle scripts can cause severe slowdown (depending on the
speed of the machine, or the insanity of the script), so mention how to
test without subtitles. This is mainly to make the user aware that
subtitle rendering can be a problem. For longwinded explanation, there
isn't enough space.
Doesn't make any sense anymore. X11 (which was mentioned in the manpage)
autodetects it, and everything else ignored the option values.
Since for incomprehensible reasons the backends and vo.c still need to
exchange information about the screensize using the option fields,
they're not removed yet.
For some reason, this made all VO backends both set the screen
resolution in opts->screenwidth/height, and call
aspect_save_screenres(). Remove the latter. Move the code to calculate
the PAR-corrected window size from aspect.c to vo.c, and make it so that
the monitor PAR is recalculated when it makes sense.
When using --monitoraspect, but either the screen width or height or
both are unknown, a fallback is applied. This is a completely useless
obscure corner case that's going to help nobody, so get it out of the
way.
For a long time the cocoa backend set the xinerama_x/y and used dx/dy from the
VO instance. This somewhat worked with some workarounds but wasn't really
what was supposed to be happening. Moreover 27e4360, which touched this
workaround introduced a regression.
New code doesn't set the xinerama_x/y values so that dx/dy are offsets in the
current screen (not a virtual screen composed of all the screens). The screen
reference detected during VOCTRL_UPDATE_SCREENINFO is also passed down to the
window initialization code.
Fixes#472
Like with the previous commit, this is probably not needed, but it's
unclear whether that really is the case. Most likely, it used to be
needed by some demuxer, and now the only demuxer left that could
_possibly_ trigger this is demux_mkv.c.
Note that mjpeg is the only decoder that reads the extra_huff option,
and nothing in libavformat actually sets the option. So maybe it's
fundamentally not needed anymore.
This case can't happen with the normal realvideo codepath in
demux_mkv.c, because the code would errors out if the extradata is too
small, and everything would be broken anyway in the case the vd_lavc.c
condition is actually triggered.
It still might happen with VfW-muxed realvideo in Matroska, though.
Basically, I'm hoping this doesn't matter anyway, and that the vd_lavc.c
code was for other old demuxers, like demux_avi or demux_rm. Following
the commit history, it's not really clear for what demuxer this code
was added.
MicroDVD files _can_ contain real timestamps instead of frame timestamps
if they declare a FPS. But this seems to be rare, so ignore that if the
FPS happens to match with the libavformat microdvd parser's default FPS.
This might actually break files that declare 23.976 FPS, but the video
file is not 23.976 FPS, but the chance that this happens is probably
very low, and the commit fixes the more common breakage with 25 FPS
video.
Subtitle formats with frame based timing require using the video FPS to
compute proper subtitle timestamps. But it looks like the calculation to
do that was inversed.
This basically reverts the default as set by commit 812798c5. This seems
to be a matter of taste, but personally I think keeping the pause
setting is better.
Use the video chain for this instead. This is for facilitating coming
changes, which will clean up the vo->aspdat stuff, and this code would
be in the way.
On X11, if no wayland compositor is running, wl_list_init() will never
be called. This will cause destroy_display() to segfault when trying to
iterate over the list.
This fixes two things:
1. Dropping files on the VO window will auto-load subtitles (since most
drag & drop code prefixes the filenames with 'file://', and the
subtitle auto-load code considers 'file://' non-local)
2. Fix behavior of the %x screenshot filename template (similar problem)
One could force all that code to special-case 'file://' URLs, but just
replacing the filename on playback start is simpler.
The user_data is passed on add_listener and can later be changed with
set_user_data. But because we don't want to change it later and because it is
the same object remove the set_user_data call.
This might be a copy&paste leftover from the initial draft for the wayland
backend.
This finally gets rid of the LaTeX dependency.
We should actually be using docultils directly here, but I didn't
do this because of all the potential Python 2/3 breakage.
1000ms is a bit insane. It makes behavior on playback speed changes
worse (because the player has to catch up the dropped audio due to
audio-chain reset), and perhaps makes seeking slower.
Note that the problem of playback speed changes misbehaving will be
fixed in the future, but even then we don't want to have a buffer that
large.
I added enough logic to never set ontop or fullscreen twitce.
This commit keeps also the size of the video if multiple videos are played.
If the ratio differs the width will be kept at the same size and only the
height changes.
libwayland-client contains the following code [1]:
runtime_dir = getenv("XDG_RUNTIME_DIR");
if (!runtime_dir) {
fprintf(stderr,
"error: XDG_RUNTIME_DIR not set in the environment.\n");
This means this message will unconditionally and unavoidably be printed
if XDG_RUNTIME_DIR is not set. Since mpv is a terminal program, and we
want to avoid unnecessary output, work it around by not attempting to
use wayland if this environment variable is not set.
[1] http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n636
(cd0dccd01e16fa404e03974d30ded3aebdb1c4bc)
This commonly happens when initializing vo_opengl on a X11-only system.
Unfortunately, most wl_*_destroy() functions appear not to accept NULL
pointers, making partial deinitialization a pain: you have to add your
own NULL checks everywhere to avoid crashes.
xkb.context is uninitialized separately, because you can initialize it
just fine, even if the rest of input initialization fails.
When both libavresample and libswresample were detected, the script
enabled both at the same time. This is not supported; although nothing
bad happened apparently. Make the dependencies both mutually exclusive.
This was inconsistent: the actual statusline used [statusline] as
message prefix, while other parts of the terminal OSD used [cplayer]
(and MSGL_STATUS). This commit makes it consistent.
Note that we can't use mp_msg, because it's not async-signal safe (we
might be running other threads while forking, so only functions
specified to be async-signal safe can be called, and this doesn't
include stdio; mp_msg acquires a mutex too).
Also, always print a \n before running the program to flush the status
line. The effect is that a program running successfully as well as the
error message will effectively start on a new line.
Quvi subtitles are considered external subtitles (simply because they're
separate from the audio/video stream), but for the sake of subtitle
auto-selection, they should not be considered external.
Change this so that quvi subtitles are treated like muxed subtitles
(with default flag never set). This means subtitles won't be selected by
default, unless explicitly requested with --sid or --slang.
Because of this commit there were problems displaying the frmase in their right
order.
This reverts commit 96e75d234a.
Conflicts:
video/out/gl_wayland.c
video/out/wayland_common.h
The changes in the vo_wayland_ontop function have no effect on the workaround.
Somehow the problem just disappeared. I guess it is because of the new control
function in gl_wayland.c where the resize happens immediatly after the event
dispatch/flush.
I don't like this function at all, but it's basically a trick to get the
input's mp_log instance in a case the mp_input_parse_cmd_strv() is
almost certainly not going to output anything. But still make it
somewhat more consistent with mp_input_parse_cmd_strv() - why force the
caller to always use MP_ON_OSD_AUTO?
Both X11 and Wayland support the same format for drag & drop operations
(text/uri-list), and the code for that was copied from x11_common.c to
wayland_common.c. Factor it out.
demux_subreader.c contains the old MPlayer subtitle parser, and I have
absolutely no confidence in this (very crappy) code. There might be
one or two security risks associated with running that code on
arbitrary input.
This solves the issue where we would not receive any frame events. The
difference to my earlier tests is that now it looks like eglSwapBuffers uses
it's own event queue or something similiar along the lines. Becaues the
performance is the same as without any redraw callback.
At the moment there are visual glitches when we resize the window. This happens
because in wayland there a special function for resizing EGL windows.
To prevent the glitches move the egl_context to the wayland state in
wayland_common.h and add a new control function to gl_wayland.c to wrap the
vo_wayland_control function to check for resize events.
With the new control wrapper the glitches are gone and the resizing is fluid.
The reason a segmentation happend here was because we couldn't get the
requested minor version. The major version is enough for differentiating
between OpenGL 3 and OpenGL 2. If it fails there is still a fallback to any
version available.
Also add a warning if we use the fallback.
Note that we don't try to be clever about detecting the files as
subtitles: we just check the file extension. We could go all the way and
check the files by opening them with a demuxer, but that would probably
do more bad than good.
Drag and drop is pretty complicated (just note how the number of Atoms
in use almost doubles), so I'm not sure whether this works everywhere.
This has been written by looking at the specification [1] or what looks
like the specification, and some external example code [2]. (The latter
one has no code license, but we didn't copy any code.)
We completely ignore the "requirement" of the spec. that the filename
"must" include username and hostname, e.g. "file://user@host/path/file".
In theory, this is required because X is network transparent, but at
this point the so called network transparency is a complete joke, and
Konqueror for one didn't include hostnames in "file://" URIs.
Tested with konqueror as drop source.
[1] http://www.newplanetsoftware.com/xdnd/
[2] http://www.edwardrosten.com/code/dist/x_clipboard-1.1/paste.cc
This is necessary to start mpv without forcing a console window,
but also breaks console usability. A workaround is to call mpv
from a wrapper process that uses the console subsystem and helps
redirecting the standard streams and WriteConsole output to where
they belong.
Streams like CDDA have special requirements in what quantities data can
be read: you can only read a sector at once, not more and not less. The
stream_peek() function didn't respect that and set less (used internal
buffer size of 2048 bytes, instead of CD sector size of 2352 bytes), so
no data was read and EOF was accidentally set, making playback with
cdda:// fail.
This is a regression since commit 9a723f, but that commit merely exposed
the issue (the redundant seek would clear the EOF flag).
Add check in old-configure as well. Reformat the check to use a maximum of 80
columns in the wscript.
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
This code is shared between input.conf parser and option parser. Until
now, the performance didn't really matter. But I want to use this code
for JSON parsing too, and since JSON will have to be parsed a lot, it
should probably try to avoid realloc'ing too much.
This commit moves parsing of C-style escaped strings into a common
function, and allows using it in a way realloc can be completely
avoided, if the already allocated buffer is large enough.
Apparently this can be really useful when being paranoid and trying to
avoid too much malloc/realloc, since it can be used to appending into a
buffer (with transparent realloc only if the buffer is too small).
Set the flag CODEC_FLAG_OUTPUT_CORRUPT by default. Note that there is
also CODEC_FLAG2_SHOW_ALL, which is older, but this seems to be ffmpeg
only.
Note that whether you want this enabled depends on the user. Some might
prefer that only good frames are output, while others want the decoder
to try as hard as possible to output _anything_. Since mplayer/mpv is
rather the kind of player that tries hard instead of being "clever", set
the new default to override libavcodec's default.
A nice way to test this is switching video tracks. Since mpv doesn't
wait for the next key frame, it'll start feeding the decoder with a
packet from the middle of the stream.
The Haali Matroska splitter is basically the reference implementation
for this crap, and it knows only:
application/vnd.ms-opentype
application/x-font-ttf
application/x-truetype-font
Two of them were missing in our code. One of them, "application/x-font",
is probably plain incorrect, but I can't really tell.
Also see: http://www.cccp-project.net/beta/test_files/fontsample.mkv
This is probably useful.
Note that this includes a small, stupid hack to prevent loading of the
config file if vf_lavfi is not available. The profile by default uses
vf_lavfi, and the config parser will output errors if vf_lavfi is not
available.
As another caveat, we install the example profile even if encoding is
disabled (though we don't load it, since this would print errors).
stream_read_complete() fails if the file is larger than the requested
maximum size. But input.c didn't check for this case, and no indication
that something went wrong was printed.
This reverts commit 877303aaa9.
The OpenGL 2.1 fallback for vo_opengl didn't work. Two things come
together: 1. trying to create an OpenGL 3.0 context will fail with
a GLXBadFBConfig error, and 2. X errors are fatal by default. Since
the reverted commit removed the X error handler, the mpv process was
killed, instead of continuing for the fallback.
(Note that this commit is not an exact inverse commit, since mp_msg
changed, but it does about the same thing.)
Apparently, Matroska packs TrueHD packets in a way lavc doesn't expect.
This broke decoding of some files [1] completely. A short look at the
libavcodec parser shows that parsing this ourselves would probably be
too much work, so make use of the libavcodec parser API.
[1] http://www.cccp-project.net/beta/test_files/mzero_truehd_sample.mkv
query_format was setting state even if wasn't the correct thing to do. Somehow
it worked by pure luck (until commit e6e6b88b6d).
Fix the initialization by setting state inside of reconfig.
Currently KDE will copy a media file into a temporary folder instead of
trying to stream it if a KIO slave location file is started. This change
will tell KDE to make mpv try to directly play the file. Perhaps the
proper flags should be added according to the individual enabled
features of the build but I suggest that be for the future.
Signed-off-by: wm4 <wm4@nowhere>
Hide --enable variants from [autodetect]'ed options and --enable/--disable
variants for [enable]'d/[disable]'d options. The hidden options are still
usable, just hidden for more readability.
If the utf8 string used to create the NSString for title was invalid utf8,
-stringWithUTF8String returned nil and triggered an assertion in Cocoa's
framework code.
Sanitize the utf8 string and if the sanitation wasn't enough just avoid
crashing by not setting a title.
Fixes#406
This applies the usual logic of resetting stream selections to default
when switching to a file with a different track layout. (This is to
prevent selecting random streams.)
Also, make sure that a track can't be selected twice. While this might
work in some situations, it certainly won't work with subtitles demuxed
from a stream.
Fixes#425.
This is relatively hacky, but it's Christmas, so it's ok. This does two
things: 1. allow selecting two subtitle tracks, and 2. include a hack
that renders the second subtitle always as toptitle. See manpage
additions how to use this.
Normally, there can be only one demuxer stream active for each demuxer
of an external file, but this assumption will be broken for multiple
subtitles support.
For some reason, this checked whether there are external tracks at all
before doing any seeks. Possibly this was to avoid multiple
get_main_demux_pts() calls, but calling this multiple times shouldn't be
too bad.
Normally we shouldn't load these files. But for some reason it was added
in commit b784346e some years ago, and disabling this hack would
probably be an inconvenience. So just print a warning.
The only thing that used mp_load_per_file_config() was inside
configfiles.c too, so remove the declaration from core.h and move the
function before its use.
Code for loading "[vo.vdpau]" profiles and similar. The messages printed
on loading change, but other than that, everything should behave about
the same.
Including the "." in the returned extension was too inconvenient. I
think originally, the semantics were supposed to work like in Python,
but screw this.
Also, return NULL instead of "" on failure (which is what its only user
actually seems to expect).
How embarrassing...
This code is inactive for all VOs other than vo_vdpau. For vo_vdpau,
this caused various issues, such as stuttering after about an hour of
running mpv; see github issue #403.
Note that this will print a difference even with perfect sync, because
the code queues the frames _between_ vsync, probably for error margin
(though I don't understand why it uses the exact values chosen).
I find this annoying. It's the reason common/version.c exists at all.
options.c did this for the user agent, which contains the version
number. Because not including version.h means you can't build the user
agent and use it in mp_default_opts anymore, do something rather awkward
in main.c to initialize the default user agent.
Make it so --msglevel extends previous --msglevel uses, instead of
overwriting them. Do this by literally appending the --msglevel option
value to the previous one.
There's a single mp_msg() in path.c, but all path lookup functions seem
to depend on it, so we get a rat-tail of stuff we have to change. This
is probably a good thing though, because we can have the path lookup
functions also access options, so we could allow overriding the default
config path, or ignore the MPV_HOME environment variable, and such
things.
Also take the chance to consistently add talloc_ctx parameters to the
path lookup functions.
Also, this change causes a big mess on configfiles.c. It's the same
issue: everything suddenly needs a (different) context argument. Make it
less wild by providing a mp_load_auto_profiles() function, which
isolates most of it to configfiles.c.
The TV code pretends to be part of stream/, but it's actually demuxer
code too. The audio_in code is shared between the TV code and
stream_radio.c, so stream_radio.c needs a small hack until stream.c is
converted.
This is pretty nasty, because FFmpeg/Libav is yet another library with a
global message callback. We do something with mutexes trying to get it
done, but of course we can't actually solve this problem. If more than
one library in a process use FFmpeg/Libav, only one of them will get log
messages.
Always pass around mp_log contexts in the option parser code. This of
course affects all users of this API as well.
In stream.c, pass a mp_null_log, because we can't do it properly yet.
This will be fixed later.
Until now, there were two functions to add input sources (stuff like
stdin input, slave mode, lirc, joystick). Unify them to a single
function (mp_input_add_fd()), and make sure the associated callbacks
always have a context parameter.
Change the lirc and joystick code such that they take store their state
in a context struct (probably worthless), and use the new mp_msg
replacements (the point of this refactoring).
Additionally, get rid of the ugly USE_FD0_CMD_SELECT etc. ifdeffery in
the terminal handling code.
The mp_select_decoders() function doesn't have a log context (and I
don't want to give it one), so get rid of the mp_msg error message by
enhancing the semantics such that the syntax error is replaced by a new
feature. Now doing "--ad=something" will enable all decoders in the
"something" module, same as "--ad=something:*". Pretty useless, but gets
rid of the annoyance.
Remove the nonsensical print_lock too.
Things that are called from the option validator are not converted yet,
because the option parser doesn't provide a log context yet.
This ended up a little bit messy. In order to get a mp_log everywhere,
mostly make use of the fact that va_surface already references global
state anyway.
This removes the messages printed on unknown pixel format messages.
Passing a mp_log to them would be too messy. Actually, this is a good
change, because in the past we often had trouble with these messages
printed too often (causing terminal spam etc.), and printing warnings or
error messages on the caller sides is much cleaner.
vd_lavc.c had a change earlier to print an error message if a decoder
outputs an unsupported pixel format.
This requires the caller to provide a mp_log in order to see error
messages. Unfortunately we don't do this in most places, but I guess we
have to live with it.
lcms2 has a global message callback for error reporting. If you don't
set this, these error messages are silently thrown away. I think we
still want the error messages, so we have to do dumb stuff to avoid
clashes. This doesn't handle the case if another library in the same
process sets the message callback, but at least this should exclude
possible memory errors when running multiple instances of mpv.
This has similar problems as the ALSA message callback, though in theory
we could use the Display handle to find the right mpv instance from the
global callback. It still wouldn't work if another library happens to
set the error handler at the same time. There doesn't seem much of an
advantage overriding the error handler (though it used to be required),
so remove it.
This could output additional, potentially useful error messages. But the
callback is global and not library-safe, and would require us to add
additional state. Remove it, because it's obviously too much of a pain.
Also, it seems ALSA prints stuff to stderr anyway.
I don't know under which circumstances this can error (other than a
broken format string). It seems it won't return an error code on I/O
errors, so maybe broken format strings are the only case. Either way,
don't continue if an error is returned.
We have certain race conditions coming from doing multiple fprintf()
calls (setting up colors etc.). I'm not sure whether it would be worth
changing to code such that we do only one fprintf() call (and assume
this synchronizes access), but considering it would be hard to do
(Windows compatibility, ...), and that stdio uses per FILE locks anyway,
this is simpler and probably not less efficient. Also, there's no
problem handling the weird statusline special case this way.
Note that mp_msg_* calls which are silent won't acquire the lock, and
acquiring the lock happens on actual output only (which is slow and
serialized anyway).
Basically, reimplement --msglevel. Instead of making the new msg code
use the legacy code, make the legacy code use the reimplemented
functionality.
The handling of the deprecated --identify switch changes. It temporarily
stops working; this will be fixed in later commits.
The actual sub-options syntax (like --msglevel-vo=...) goes away, but I
bet nobody knew about this or used this anyway.
Instead of making msg.c an ifdef hell for unix vs. windows code, move
the code to separate functions defined in terminal-unix.c/terminal-
win.c.
Drop the code that selects random colors for --msgmodule prefixes.
So you can pass a command as list of strings (each item is an argument),
instead of having to worry about escaping and such.
These functions also take an argument for the default command flags. In
particular, this allows setting saner defaults for commands sent by
program code.
Expose this to Lua as mp.send_commandv command (suggestions for a better
name welcome). The Lua version doesn't allow setting the default command
flags, but it can still use command prefixes. The default flags are
different from input.conf, and disable OSD and property expansion.
This comes with a real change in behavior: now the signal handler is set
only when the terminal input code is active (e.g. not with
--no-consolecontrols), but this should be ok.
Remove these because I'm too lazy to convert them to proper
STREAM_CTRLs. Considering that probably nobody uses radio://, caring
about this is a complete waste of time. I will add these commands back
if someone asks for them, but I don't expect this to happen.
Apparently this has been broken for a year or so. The were three
reasons for the breakage here:
1. The window dragging hack prevented any DOWN event from
passing through since it always returned before we even got
the button.
2. The window style had CS_DBLCLKS in its flags, so we did not
get any DOWN events when the OS had detected a double click
(instead expecting us to handle a DBL event).
3. We never sent any mouse buttons when mouse movement handling
was disabled.
request_channels has been deprecated for years (request_channel_layout
is the replacement), but it appears it's still needed despite the
deprecation at least on older libavcodec versions.
So still set request_channels, but to it with the avoption API, which
hides the deprecation warning. This should also prevent mpv getting
trashed when libavcodec happens to bump its major version.
In my opinion, config.h inclusions should be kept to a minimum. MPlayer
code really liked including config.h everywhere, though, even in often
used header files. Try to reduce this.
Since m_option.h and options.h are extremely often included, a lot of
files have to be changed.
Moving path.c/h to options/ is a bit questionable, but since this is
mainly about access to config files (which are also handled in
options/), it's probably ok.
The tmsg stuff was for the internal gettext() based translation system,
which nobody ever attempted to use and thus was removed. mp_gtext() and
set_osd_tmsg() were also for this.
mp_dbg was once enabled in debug mode only, but since we have log level
for enabling debug messages, it seems utterly useless.
Nothing actually used the returned length. Since the remaining time can
easily become 0 or negative (e.g. incorrectly estimated file duration),
the time_remaining function still needs 2 return values, though.
"-" could skip optional arguments. I think this was a pretty bad idea,
because it introduced a weird special case.
I'll remove the special syntax, but keep compatibility for the "seek"
and "screenshot" commands.
If input is not waiting for select(), writing to the wakeup pipe is
wasteful, and, if there are many wakeups, might even block the wakeup
threads if the pipe gets full.
However, if it's waiting for select(), the wakup pipe must be used to
unblock the waiting thread. Actually there's a small race condition: we
might determine that the main thread is in select(), and write to the
wakeup pipe (whether we do this while unlocked or locked doesn't really
matter). Then, the main thread might leave select() before reading from
the wakup pipe. This should be harmless, because at worst more wakeups
than needed happen, but never fewer.
In order to use bare mp_log contexts, I find myself creating dummy
structs (with a single "log" field) to use the MP_ERR() etc. macros,
which hardcode the idiom that a context struct has a log field. On the
other hand, just using mp_msg_log() is too much typing (and I want to
rename it to mp_msg() when the transition is done), so it seems nice to
have message printing macros that use mp_log directly.
There's no reason why we should do this. For some reason, the existing
code reset terminal handling to default after unloading a file, just to
initialize it again when loading a new file.
Might be related to github issue #412, although I don't think it helps,
since the default SIGTERM handler _should_ kill the mpv process.
(It's still a nice simplification, though.)
The OSD style settings depend on the PlayRes, simply because all style
values are implicitly scaled by the PlayResY in libass. Also, the OSC
changes the PlayResY in certain situations, so something could go wrong.
But not sure if this actually matters in practice.
This simplifies things, although it is slightly less efficient (probably
uses a bit more memory).
This also happens to fix that the OSC dropped the libass cache on every
frame.
This doesn't have much value. It can't be accessed by anything else than
the actual subtitle renderer (sd_ass.c). sd_ass.c could create the
renderer itself, except that we apparently want to save memory (and some
font loading time) when using ordered chapters or multiple subtitle
tracks.
The end of the current segment will be the end of the file if there is
no next segment. Normally, this didn't matter much, since UNIX files
allow seeking past the end of the file. But when opening files from
HTTP, this would print confusing error messages. So explicitly check for
EOF before trying to read a segment.
Add the mp_get_user_path() function, and make it expand special path
prefixes. Use it for some things in mpv which take filenames
(--input-config, --screenshot-template, opengl icc-profile suboption).
This allows accessing files in the mpv config dir without hardcoding the
config path by prefixing the path with ~~/. Details see manpage
additions.
Before this, they were displayed forever. Since some dvd screens seem
not to allow escaping from the still frame using the menu, this could
get you stuck forever.
On dvdnav, caching kind of works but not really. (Not our fault, at
least not fully. It's due to libdvdnav being slightly misdesigned; see
previous commit for some explanations.)
The TV code is implemented in the demuxer, and the stream implementation
is just a wrapper, so caching makes no sense here.
No idea why this was disabled. It was in the original MPlayer code,
which doesn't make much sense to me, because using the MPlayer stream
cache seems 100% broken due to design issues.
Not sure how this should work. Using libdvdnav with a large FIFO doesn't
make sense either: data and control commands use the same stream, so if
you want to send input to libdvdnav, you just have to read from
libdvdnav all the time to get a reaction, which is not compatible with
maintaining a buffer that could remain full for a long time.
I have no idea either whether this improves or worsens anything, though
it might be more correct.
EOF is a special case. Normally, the reader will block until the cache
thread has new data. Obviously we don't want to do this on EOF, because
we'd potentially block forever. On the other hand, EOF will put the
cache thread into a waiting state, so if EOF recovers, this will happen
at a "later" point. This is bad if there is some kind of external event
that ends the EOF condition. In this case, a steram_read() call would
still return EOF. Make it so that the reader waits at least for one
iteration of the cache trying to rad a new block.
Also adjust some debug messages to not print file positions in hex.
There was already something similar in the code that did the actual
seek, but I think seeking to the same position could still trigger an
actual seek due to weid interaction with the buffer.
Use the scaled video size (i.e. as shown on the window) as reference for
zoom. This is the easiest way to fix different width/height scale
factors as they happen when zooming video with a pixel aspect ratio
other than 1:1.
Also fix the unscaled mode, so that it 1. doesn't scale even with
--video-zoom, and 2. doesn't scale by small amounts when the video is
cropped by making the window smaller than the video.
Since dvb input is not seekable anyway, this would probably just flush
the stream buffer, but at least it'll avoid a bogus message about
seeking errors.
This code tried to pass a still monotonic (even if not strictly
monotonic) PTS to the player, but as a result it remained stuck on
the PTS before a reset (since the PTS was lower).
This readds a more or less completely new dvdnav implementation, though
it's based on the code from before commit 41fbcee. Note that this is
rather basic, and might be broken or not quite usable in many cases.
Most importantly, navigation highlights are not correctly implemented.
This would require changes in the FFmpeg dvdsub decoder (to apply a
different internal CLUT), so supporting it is not really possible right
now. And in fact, I don't think I ever want to support it, because it's
a very small gain for a lot of work. Instead, mpv will display fake
highlights, which are an approximate bounding box around the real
highlights.
Some things like mouse input or switching audio/subtitles stream using
the dvdnav VM are not supported.
Might be quite fragile on transitions: if dvdnav initiates a transition,
and doesn't give us enough mpeg data to initialize video playback, the
player will just quit.
This is added only because some users seem to want it. I don't intend to
make mpv a good DVD player, so the very basic minimum will have to do.
How about you just convert your DVD to proper video files?
The code to remove a section from the active section array wasn't
correct (it should have tried to copy the elements in reverse), so just
replace it with a macro that does the intended thing.
Add some debug output to print the section stack.
Until now, the player didn't care to drain frames on video reconfig.
Instead, the VO was reconfigured (i.e. resized) before the queued frames
finished displaying. This can for example be observed by passing
multiple images with different size as mf:// filename. Then the window
would resize one frame before image with the new size is displayed. With
--vo=vdpau, the effect is worse, because this VO queues more than 1
frame internally.
Fix this by explicitly draining buffered frames before video reconfig.
Raise the display time of the last frame. Otherwise, the last frame
would be shown for a very short time only. This usually doesn't matter,
but helps when playing image files. This is a byproduct of frame
draining, because normally, video timing is based on the frames queued
to the VO, and we can't do that with frames of different size or format.
So we pretend that the frame before the change is the last frame in
order to time it. This code is incorrect though: it tries to use the
framerate, which often doesn't make sense. But it's good enough to test
this code with mf://.
This gets rid of the vf_vo pseudo-filter. It ends the idea of MPlayer's
architecture that the VO is just a (terminating) video filter. It didn't
really work for us with respect to video timing (the "end" of the video
chain isn't really made for video timing, and making it do so would be
awkward), and now we're removing it entirely. We will be able to fix
some things, such as properly draining video on reconfiguration.
I don't think this has any reason to exist. It's likely that this used
to be required by the old direct rendering infrastructure. (See
git blame output.)
This should help fixing some issues (like not draining video frames
correctly on reinit), as well as decoupling the decoder, filter chain,
and VO code.
I also wanted to make the hardware video decoding fallback work properly
if software-only video filters are inserted. This currently has the
issue that the fallback is too violent, and throws away a bunch of
demuxer packets needed to restart software decoding properly. But
keeping "backup" packets turned out as too hacky, so I'm not doing this,
at least not yet.
Libav 9 still uses the unprefixed PIX_FMT_... symbols, but they will
probably be removed some time in the future.
There are some other deprecations we have yet to take care of, but
there are no clear replacements yet.
The previous RING_BUFFER_COUNT value, 64, would have ao_wasapi buffer 64
frames of audio in the ring buffer; a delay of 1280ms, which is clearly
overkill for everything. A value of 8 buffers 8 frames for a total of
160ms.
When get_space was converted to returning samples instead of bytes, a
unit type mismatch in get_delay's calculation returned bogus values. Fix
by converting get_space's value back to bytes.
Fixes playback with ao_wasapi when reaching EOF, or seeking past it.
There are 3 users of the image format option type: demux_raw,
vf_format, vf_noformat. Allow the hwaccel formats (like vdpau etc.)
in general, so that the filters can use it. This won't work for
demux_raw, so explicitly reject these formats there.
Remove the inconsistent, duplicated, and insufficient scale filter
insertion code, and do it in one place instead. This also compensates
for the earlier removal of vf_match_csp() (which was in fact duplicated
code).
The algorithm to determine where to insert a filter etc. is probably the
same, though it also comes with some changes that should make debugging
easier when trying to figure out why a chain is failing to configure.
Add an "in" pseudo filter, which makes insertion of conversion filters
easier. Also change the vf->reconfig signature. At a later point, I'll
probably change format negotiation such that the generic filter code
will choose the output format, so having separate in and out params will
be useful.
Reason: I never liked it being recursive. Generally, this seems to
cause more problems than trouble, and is less flexible for access
outside of the chain.
I don't think we need these flags anymore. Simplify the code and get rid
of the vf_format struct.
There still is the vf_format.configured field, but this can be replaced
by checking for a valid image format.
This adds vf_chain, which unlike vf_instance refers to the filter chain
as a whole. This makes the filter API less awkward, and will allow
handling format negotiation better.
This function improves automatic filter insertion, but this really
should be done by the generic filter code. Remove vf_match_csp() and all
code using it as preparation for that.
This commit temporarily makes handling of filter insertion worse for
now, but it will be fixed with the following commits.
If sys/soundcard.h is actually linux/soundcard.h then it supports only OSSv3
API. This may happen when OSSLIBDIR == /usr while forgetting to replace
sys/soundcard.h from glibc.
However, after fa620ff waf prefers native implementation which is inferior
on Linux. To fix try making waf prefer oss-audio-4front. It's quite unusual
to have 4Front OSS installed where native implementation is superior, anyway.
Signed-off-by: bugmen0t <@>
Make the false positives path also undef the 4Front define.
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
Fixes#396
Bug introduced by commit 6fb020f5. It doesn't always happen, since it is
caused by the playloop and cocoa UI code running in separate threads.
Fixes#398.
Uncompressed rar archives can be transparently opened, but the filename
the player doesn't have the direct filename (but something starting
with rar://... instead). This will lead to external subtitles not
being loaded.
This doesn't handle multi-volume rar files, but in that cases just use
the --autosub-match=fuzzy option.
Fixes#397 on github.
If only coreaudio was activativated and not cocoa, the build failed for
missing CoreFoundation.
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
Fixes#395
They didn't do anything.
vf_screenshot.c actually did release the previous image, but that's not
really required. At worst you could take a screenshot and get an old
frame when there's no new frame yet.
The --flip option flipped the image upside-down, by trying to use VO
support, or if not available, by inserting a video filter. I'm not sure
why it existed. Maybe it was important in ancient times when VfW based
decoders output an image this way (but even then, flipping an image is a
free operation by negating the stride).
One nice thing about this is that it provided a possible path for
implementing video orientation, which is a feature we should probably
support eventually. The important part is that it would be for free for
VOs that support it, and would work even with hardware decoding.
But for now get rid of it. It's useless, trivial, stands in the way, and
supporting video orientation would require solving other problems first.
In particular, this disables mpeg4. There are some files out there that
use GMC, a usually rarely used and ineffective feature, which is not
supported by most hardware decoders. In these cases the hw decoder
outputs garbage, while software decoding works perfectly fine. We can't
really fallback to software decoding in these cases, because we don't
know that something is wrong in the first place. I can't see any
advantages of hw decoding of mpeg4, so it's better to disable it.
This can be reproduced with:
mpv short.wav -af 'lavfi="aecho=0.8:0.9:5000|6800:0.3|0.25"'
An audio file that is just 1-2 seconds long should play for 8-9 seconds,
which audible echo towards the end.
The code assumes that when playing with AF_FILTER_FLAG_EOF, the filter
will either produce output, or has all remaining data flushed. I'm not
really sure whether this really works if there are multiple filters with
EOF handling in the chain. To handle it correctly, af_lavfi should retry
filtering if 1. EOF flag is set, 2. there were input samples, and 3. no
output samples were produced. But currently it seems to work well enough
anyway.
The new signature is actually closer to how it actually works, and
someone who is not familiar to the API and how it works might make fewer
fatal mistakes with the new signature than the old one. Pretty weird.
Do this to sneak in a flags parameter, which will later be used to flush
remaining data of at least vf_lavfi.
This will make af_channels output a channel layout that is compatible
with any destination layout. Not sure if that's a good idea though,
since the way the AO choses a layout is perhaps less predictable. On the
other hand, using the old MPlayer standard layouts doesn't make much
sense either. We'll see whether this improves or breaks someone's use
case.
Apparently this stopped working after some planar changes (broken format
negotiation). Radically change option parsing in an incompatible way.
Suggest alternatives to this filter, since it barely has any importance
anymore.
Normally, audio decoder don't have a decoder delay, so the code was
fine. But FFmpeg supports multithreaded decoding for some audio codecs,
which introduces such a delay.
The delay means that we won't get decoded audio for the first few
packets, and that we need to do something to get the trailing audio
still buffered in the decoder when reaching EOF.
Two changes are needed to deal with the delay:
- If EOF is reached, pass a "flush" packet to the decoder to return the
buffered audio. Such a flush packet is automatically setup when
calling mp_set_av_packet() with a NULL packet.
- Use the PTS returned by the decoder, instead of the packet's. This is
important to get correct timestamps for decoded audio. Ignoring this
would result into offsetting the audio playback time by the decoder
delay. Note that we can still use the timestamp of the first packet
to get the timestamp for the start of the audio.
If the timebase is set, it's used for converting the packet timestamps.
Otherwise, the previous method of reinterpret-casting the mpv style
double timestamps to libavcodec style int64_t timestamps is used.
Also replace the kind of awkward mp_get_av_frame_pkt_ts() function by
mp_pts_from_av(), which simply converts timestamps in a way the old
function did. (Plus it takes a timebase parameter, similar to the
addition to mp_set_av_packet().)
Note that this should not change anything yet. The code in ad_lavc.c and
vd_lavc.c passes NULL for the timebase parameters. We could set
AVCodecContext.pkt_timebase and use that if we want to give libavcodec
"proper" timestamps.
This could be important for ad_lavc.c: some codecs (opus, probably mp3
and aac too) have weird requirements about doing decoding preroll on the
container level, and thus require adjusting the audio start timestamps
in some cases. libavcodec doesn't tell us how much was skipped, so we
either get shifted timestamps (by the length of the skipped data), or we
give it proper timestamps. (Note: libavcodec interprets or changes
timestamps only if pkt_timebase is set, which by default it is not.)
This would require selecting a timebase though, so I feel uncomfortable
with the idea. At least this change paves the way, and will allow some
testing.
Don't bother explaining the sample format naming schema. The "ne" bit is
outdated anyway, and anyone who has to use this option will be able to
understand the naming schema just by looking at the names too.
This prevents waf from running test programs after compilation. A better
approach would be to only remove this option if the check actually errors,
but we are using this only for Lua anyway.
The vf_eq context contains a very large lookup table, and the method of
setting default values caused the vf_eq context to be included in the
compiled code.
vf_stereo3d now uses vf_lavfi, if mpv was compiled with libavfilter.
vf_swapuv is hereby undeprecated. It's too trivial to wrap it with
libavfilter, and it's also too useless that even typing this commit
message is not really worth the time to spend on it.
Just in case someone expects these are unchanged just because they're
not mentioned in changes.rst anywhere. Documenting all of these changes
would be too much work and not helpful either.
All filters now either use the generic option parser, or don't have
options. This finally finishes a transition started in 2003 (see git
commit 33b62af947).
Why are MPlayer devs so monumentally lazy? Sorry, but this takes the
cake. You had 10 years.
Mostly backwards compatible, we don't change much because we just want
to get rid of the legacy option string handling.
You can't pass an aspect as first argument anymore.
Apparently you can get this with: stereo3d=ab[2]{l,r}:sbs[2]{l,r}
So it seems the filter is redundant and can be removed.
Also see FFmpeg commit 2f11aa141a01.
Unfortunately, this forces filtering both luma and chroma, because
otherwise we'd have to deal with libavfilter's vf_noise weird handling
of YUV vs. RGB formats. Would we e.g. filter luma only, it would filter
red in RGB mode only, because it goes by component and there's no way to
distinguish YUV and RGB by just using the filter's options.
Also remove the ability to disable deinterlacing at runtime. You can
still disable deinterlacing at runtime by using the ``D`` key and its
automatical filter insertion/removal.
This will allow old filter to run libavfilter instead by calling
vf_lw_set_graph(), which turns the filter into a wrapper, using a given
libavfilter graph.
Later commits use that to automatically "reroute" a bunch of filters to
libavfilter. We want to get rid of the old MPlayer filter code, because
it's bad an unmaintained, but we still don't want to force everyone to
use vf_lavfi, so this solution will do for a while.
Previous API worked under the assumption that download_image is always called
after map_image. In practice this is true, but it's better to have a much
generic API that doesn't depend on the order in which the functions are called.
The hwdec driver can be loaded, even if it's not used (e.g. when playing
a file with no hardware decoding after one with it enabled).
Also, check whether dlimage is NULL. Since this will do call into the
native hwdec API, there's a chance a driver could fail doing this, it's
better to check the return value, even if this case currently can't
happen.
mpv was hardcoded to always consider the right Alt key as Alt Gr, but there
are parituclar combinations of platforms and keyboard layouts where it's more
convenient to treat the right Alt as a keyboard modifier just like the left
one.
Fixes#388
The harder work was done in the previous commits. After that this feature comes
out almost for free.
The only problem is I can't get the textures created with CGLTexImageIOSurface2D
to download properly, thus the code performs download using some CoreVideo APIs.
If someone knows why download of textures created with CGLTexImageIOSurface2D
doesn't work please contact me :)
This adds support for packed YUV formats (YUVY and UYVY) using the extension
GL_APPLE_rgb_422. While supporting this formats on their own is not that
important (considering most video is planar YUV) they are used for
interoperability with IOSurfaces.
Next commit will use this formats to render VDA hardware decoded frames through
IOSurface and OpenGL interoperability.
roaraudio has some sort of sndio emulation, but apparently its header
file is either blatantly broken, or an old version from the past. The
sio_onvol() function has the wrong return type (void instead of int),
and the SIO_DEVANY symbol is missing entirely. This broke the build,
because the configure check was successful anyway.
This allows vo_opengl to use GL_TEXTURE_RECTANGLE textures, either by
enabling it with the 'rectangle-textures' sub-option, or by having a
hwdec backend force it. By default it's off.
The _only_ reason we're adding this is because VDA can export rectangle
textures only.
We got a crash in libavutil when encoding with Y8 (GRAY8). The reason
was that libavutil was copying an Y8 image allocated by us, and expected
a palette. This is because GRAY8 is a PSEUDOPAL format. It's not clear
what PSEUDOPAL means, and it makes literally no sense at all. However,
it does expect a palette allocated for some formats that are not
paletted, and libavutil crashed when trying to access the non-existent
palette.
This is for key bindings that use multiple mouse buttons at once. (Yes,
this is weird, but MPlayer always had this feature, and apparently
there are people using it!)
Before this commit, clicking another mouse button while still holding
the previous mouse button forced the command bound to the previous
mouse button to be emitted. This is usually needed to make sure the
input consumer (the player and the OSC) stays in sync with the actual
mouse button state. If there's no command sent, the OSC in particular
would think the button is still held down. However, sending the command
is undesired behavior if you want to use these multiple-key binds.
Solve this by emitting commands in this situation only if a key down
command was sent earlier. Since mouse button key bindings are normally
executed on key-up only, this happens with special commands like
script_dispatch only (used by the OSD to track mouse buttons, but
also used for other OSC bindings).
See github issue #390.
This is not strictly needed anymore. (On the other hand, it's not really
possible to do hw decoding with vo_null, because the VO is still
responsible for opening the hw decoder API, but that's another story.)
There are some use cases for this. For example, you can use it to set
defaults of automatically inserted filters (like af_lavrresample). It's
also useful if you have a non-trivial VO configuration, and want to use
--vo to quickly change between the drivers without repeating the whole
configuration in the --vo argument.
The "run" input command does fork+exec to spawn child processes. But it
doesn't cleanup the child processes, so they are left as zombies until
mpv terminates. Leaving zombie processes around is not very nice, so
employ a simple trick to let pid 1 take care of this: we fork twice, and
when the first fork exits, the second fork becomes orphaned and becomes
pid 1's child. It becomes pid 1's responsibility to cleanup the process.
The advantage is that we don't need extra logic to cleanup the spawned
process, which could have an arbitrary lifetime.
This is e.g. described here: http://yarchive.net/comp/zombie_process.html
Also use _exit() instead of exit(). It's not really sane to run cleanup
handlers (atexit() etc.) inside a forked process.
This is needed so that new processes (created with fork+exec) don't
inherit open files, which can be important for a number of reasons.
Since O_CLOEXEC is relatively new (POSIX.1-2008, before that Linux
specific), we #define it to 0 in io.h to prevent compilation errors on
older/crappy systems. At least this is the plan.
input.c creates a pipe. For that, add a mp_set_cloexec() function (which
is based on Weston's code in vo_wayland.c, but more correct). We could
use pipe2() instead, but that is Linux specific. Technically, we have a
race condition, but it won't matter.
See the changes in input.rst for explanations.
Technically speaking, this also gets rid of some undefined behavior:
passing NULL as a vararg (execl()) is always a bug.
So e.g.
show_text abc#def
will now print "abc#def" instead of "#def". It's simpler, more
consistent with how ";" and other things are handled, and also
possibly avoids bothering the user with extra escaping.
The OSS checks were a big mess and quite buggy. This reimplementes them using
a declarative approach and clearly distinguishing between the various OSS
implementations. The code should now almost be auto-documenting.
We currently support the following implementations of OSS:
* platform-specific (with `sys/soundcard.h`)
* SunAudio (default on NetBSD and useable on OpenBSD even if we have sndio
support there).
* 4Front (default on FreeBSD)
Since now each OSS check also checks for the appropriate soundcard header,
remove the old soundcard check.
Many thanks to @bugmen0t for in depth info about all the BSDs.
Check #380 and #359 for more info on this commit.
PIX_FMT_* -> AV_PIX_FMT_* (except some pixdesc constants)
enum PixelFormat -> enum AVPixelFormat
Losen some version checks in certain newer pixel formats.
av_pix_fmt_descriptors -> av_pix_fmt_desc_get
This removes support for FFmpeg 1.0.x, which is even older than
Libav 9.x. Support for it probably was already broken, and its
libswresample was rejected by our build system anyway because it's
broken.
Mostly untested; it does compile with Libav 9.9.
This partially reverts commit 7d152965. It turns out that at least some
ALSA drivers (at least snd-hda-intel) report incorrect audio delay with
non-native sample rates, even if the sample rate is only very slightly
different from the native one.
For example, 48000Hz is fine on my hda-intel system, while both 8000Hz
and 47999Hz lead to a delay off by 40ms (according to mpv's A/V
difference display), which suggests that something in ALSA is
calculating the delay using the wrong sample rate.
As an additional problem, with ALSA resampling enabled, using
48001Hz/float/2ch fails, while 49000Hz/float/2ch or 48001Hz/s16/2ch
work. With resampling disabled, all these cases work obviously, because
our own resampler doesn't just refuse any of these formats.
Since some people want to use the ALSA resampler (because it's highly
configurable, supports multiple backends, etc.), we still allow enabling
ALSA resampling with an ao_alsa suboption.
These were confined to the video path, but resetting them even if no
video is available shouldn't really matter. Always resetting them makes
the logic easier to follow, I think.
Sometimes, vf_pullup hanged on seek. This was because it never was
properly reset. Old timestamps messed up the timestamp calculations,
which made the player show frames for a ridiculously long time, which is
perceived as pausing or hanging.
Recently, the check was moved, so it was printed only for source video
PTS (since that's easier, and filters should normally behave sane). But
it turns out it's trivial to print a warning in the filter case too by
reusing the code that normally checks for PTS forward jumps without
needing any additional code, so, fine, restore warning in this case.
The old ffmpeg vdpau support code uses separate vdpau pixel formats for
each decoder (pretty much because mplayer's architecture sucked), which
just gets into the way. Force the old decoder's output to IMGFMT_VDPAU,
and remove IMGFMT_IS_VDPAU() where we can remove it.
This should completely remove the differences betwene the old and new
vdpau decoder outside of the decoder.
PIX_FMT_VDA_VLD and PIX_FMT_VAAPI_VLD were never used anywhere. I'm not
sure why they were even added, and they sound like they are just for
compatibility with XvMC-style decoding, which sucks anyway.
Now that there's only a single vaapi format, remove the
IMGFMT_IS_VAAPI() macro. Also get rid of IMGFMT_IS_VDA(), which was
unused.
pthreads should be available anywhere. Even if not, for environment
without threads a pthread wrapper could be provided that can't actually
start threads, thus disabling features that require threads.
Make pthreads mandatory in order to simplify build dependencies and to
reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe
we will use pthreads more in the future, and then it'd become a real
bother.)
Introduce a mp_cmd_def struct to define commands, instead of using
mp_cmd for this. This way each command parameter can be a m_option,
instead of m_option plus some more stuff.
Define the ARG_ macros directly in terms of the OPT_ macros. Not sure if
this makes it easier to read (maybe not, even if it looks simpler), but
at least it makes it easier to add other option types.
Another idea was adding a name for each parameter (so you could have
named parameters), but not today.
The hr-seek code assumes that when seeking the demuxer, the first image
decoded after the seek will have a PTS exactly equal to the demuxer seek
target time, or before that target time. Incorrect timestamps,
implicitly dropped initial frames, or broken files/demuxers can all
break this assumption, and lead to hr-seek missing the seek target.
Generally, this is not much a problem (the user won't notice being off
by one frame), but it really shows when using the backstep feature. In
this case, backstepping would simply hang.
Add a simple hack that basically forces a minimal value for the --hr-
seek-demuxer-offset option (which is 0 by default) when doing a
backstep-seek. The chosen minimum value is arbitrary. There's no perfect
value, though in general it should perhaps be slightly longer than the
frametime, which the chosen value is more than enough for typical
framerates.
So, FFmpeg/Libav requires us to figure out video timestamps ourselves
(see last 10 commits or so), but the methods it provides for this aren't
even sufficient. In particular, everything that uses AVI-style DTS (avi,
vfw-muxed mkv, possibly mpeg4-in-ogm) with a codec that has an internal
frame delay is broken. In this case, libavcodec will shift the packet-
to-image correspondence by the codec delay, meaning that with a delay=1,
the first AVFrame.pkt_dts is not 0, but that of the second packet. All
timestamps will appear shifted. The start time (e.g. the time displayed
when doing "mpv file.avi --pause") will not be exactly 0.
(According to Libav developers, this is how it's supposed to work; just
that the first DTS values are normally negative with formats that use
DTS "properly". Who cares if it doesn't work at all with very common
video formats? There's no indication that they'll fix this soon,
either. An elegant workaround is missing too.)
Add a hack to re-enable the old PTS code for AVI and vfw-muxed MKV.
Since these timestamps are not reorderd, we wouldn't need to sort them,
but it's less code this way (and possibly more robust, should a demuxer
unexpectedly output PTS).
The original intention of all the timestamp changes recently was
actually to get rid of demuxer-specific hacks and the old timestamp
sorting code, but it looks like this didn't work out. Yet another case
where trying to replace native MPlayer functionality with FFmpeg/Libav
led to disadvantages and bugs. (Note that the old PTS sorting code
doesn't and can't handle frame dropping correctly, though.)
Bug reports:
https://trac.ffmpeg.org/ticket/3178https://bugzilla.libav.org/show_bug.cgi?id=600
Using --start with files that use DTS only, or which simply have broken
PTS timestamps, would incorrectly drop frames and possibly not execute
the seek correctly.
Add yet another heuristic to detect this. The intent is that --start and
hr-seeks in general should work correctly, but in order to keep things
fast, we still want to allow frame dropping during hr-seek if there are
no problems doing so. Do this by disabling frame dropping by default,
but re-enabling it if there are no problems found for a while. As a
consequence, --start might be somewhat slower, but normal user
interaction should remain as fast as before.
Note that there's something subtle about the added code: the
has_broken_packet_pts field is checked even before the first packet is
fed to dec_video.c, so the field must not be set to 0 right on start.
It's not initially set to 0 anyway, because the heuristic requires
decoding some images before enabling frame drop anyway.
Note 2: it's not clear whether frame dropping during hr-seek really
helps; I didn't benchmark it.
Previous code was using the values of the AudioChannelLabel enum directly to
create the channel bitmap. While this was quite smart it was pretty unreadable
and fragile (what if Apple changes the values of those enums?).
Change it to use a 'dumb' conversion table.
The d_video->pts field was a bit strange. The code overwrote it multiple
times (on decoding, on filtering, then once again...), and it wasn't
really clear what purpose this field had exactly. Replace it with the
mpctx->video_next_pts field, which is relatively unambiguous.
Move the decreasing PTS check to dec_video.c. This means it acts on
decoder output, not on filter output. (Just like in the previous commit,
assume the filter chain is sane.) Drop the jitter vs. reset semantics;
the dec_video.c determined PTS never goes backwards, and demuxer
timestamps don't "jitter".
Also get rid of the PTS check _after_ filters. This means if there's a
video filter which unsets PTS, no warning will be printed. But we assume
that all filters are well-behaved enough by now.
Refactor the PTS handling code to make it cleaner, and to separate the
bits that use PTS sorting.
Add a heuristic to fall back to DTS if the PTS us non-monotonic. This
code is based on what FFmpeg/Libav use for ffplay/avplay and also
best_effort_timestamp (which is only in FFmpeg). Basically, this 1. just
uses the DTS if PTS is unset, and 2. ignores PTS entirely if PTS is non-
monotonic, but DTS is sorted.
The code is pretty much the same as in Libav [1]. I'm not sure if all of
it is really needed, or if it does more than what the paragraph above
mentions. But maybe it's fine to cargo-cult this.
This heuristic fixes playback of mpeg4 in ogm, which returns packets
with PTS==DTS, even though the PTS timestamps should follow codec
reordering. This is probably a libavformat demuxer bug, but good luck
trying to fix it.
The way vd_lavc.c returns the frame PTS and DTS to dec_video.c is a bit
inelegant, but maybe better than trying to mess the PTS back into the
decoder callback again.
[1] https://git.libav.org/?p=libav.git;a=blob;f=cmdutils.c;h=3f1c667075724c5cde69d840ed5ed7d992898334;hb=fa515c2088e1d082d45741bbd5c05e13b0500804#l1431
These used the suffix _resync_stream, which is a bit misleading. Nothing
gets "resynchronized", they really just reset state.
(Some audio decoders actually used to "resync" by reading packets for
resuming playback, but that's not the case anymore.)
Also move the function in dec_video.c to the top of the file.
The code stopped at kAudioChannelLabel_TopBackRight and missed mapping for
5 more channel labels. These are in a completely different order that the mpv
ones so they must be mapped manually.
This includes the case when lavc decodes audio with more than 8
channels, which our audio chain currently does not support.
the changes in ad_lavc.c are just simplifications. The code tried to
avoid overriding global parameters if it found something invalid, but
that is not needed anymore.
When using PIC on x86 (eg with hardened toolchains) the ebx register is
reserverd and cannot be used in assembly code.
For vf_eq we allow the compiler to use memory as input.
For vf_noise we temoporarily borrow the ebp register.
This fixes#361.
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
This was broken by the recent commits. Apparently realvideo timestamps
are severely mangled, and Matroska _of course_ doesn't have the sane,
umangled timestamps, but something unusable. The existing unmangling
code in demux_mkv.c didn't output proper timestamps either. Instead,
it was something weird that triggered sorting. Without sorting (it was
disabled by default recently), you'd get decreasing PTS warnings
In order to fix this, steal some code from libavcodec. Basically copy
the contents of rv34_parser.c (with some changes), which makes
everything magically work. (Maybe it would be better to use the
libavcodec parser API, but I don't want to do that just for this. An
alternative idea would be refusing to read files that have realvideo
tracks, and delegate this to demux_lavf.c, but maybe that's too redical
too.)
I wish I hadn't notice this...
Resampling with non-ancient ALSA setups works fine, so there is no
need to keep this around. Furthermore, as of writing, the default
builtin resampler used by many ALSA setups (taken from libspeex)
actually has higher quality than the default resampling modes of
avresample and swresample.
Apparently just 5 packets is not enough for the initial audio decode
(which is needed to find the format). The old code (before the recent
refactor) appeared to use 5 packets, but there were apparently other
code paths which in the end amounted to more than 5 packets being read.
The sample that failed (see github issue #368) needed 9 packets.
Fixes#368.
These packets have to be explicitly dropped, because usually libavcodec
uses 0-sized packets to flush delayed frames, meaning just passing
through these packets would have bad consequences.
Normally, libavformat doesn't output 0-sized packets anyway. But I don't
want to take any chances, so don't delete it, and just move it out of
the way to demux.c.
Incidentally this seems wrong in the configure as well because only gl-win32
depends on it instead of also making direct3d depend on this (as I did here).
If the value for --cache-on-pause is larger than --cache-min, and the
cache runs below --cache-on-pause, but above --cache-min, the logic
would demand to pause the player and then unpause immediately again.
This doesn't make much sense, and alternating the pause state in each
playloop iteration has negative consequences. Add an explicit check to
avoid this situation.
This means the code that tries to figure out the timestamp from
demuxer and decoder output is now all in dec_video.c. We set the
final timestamp on the returned image (mp_image.pts), as well as
the d_video->pts field.
The way the player uses d_video->pts field is still a bit messy. Maybe
this could be cleaned up later.
It appears PTS sorting was useful only for avi files (and VfW-muxed
mkv). Maybe it was historically also important for decoders with broken
or non-existent PTS reordering (win32 codecs?). But now that we handle
demuxers which outputs DTS only correctly, it just seems dead weight.
Disable it by default. The --pts-association-mode option is now forced
to always use the decoder's PTS value. You can still enable the old
default (auto) or force sorting. But we will probably remove this option
entirely at some point.
Make demux_mkv export timestamps at DTS when it's in VfW mode. This is
needed to get correct timestamps with the new default mode. demux_lavf
already does that.
This was needed to determine PTS from DTS, but the previous commits
make it unnecessary.
The builtin genpts hack was used for DVD, because libavformat's genpts
essentially went amok on DVD timestamp resets. See commit 65d87091 for
details.
Having the DTS directly can be useful for restoring PTS values.
The avi file format doesn't actually store PTS values, just DTS. An
older hack explicitly exported the DTS as PTS (ignoring the [I assume]
genpts generated non-sense PTS), which is not necessary anymore due to
this change.
Now the --no-correct-pts mode is like the normal mode, just with
different timestamp calculations. The semantics should be about the
same as before this commit.
Before this commit, this mode estimated the frame time by subtracting
successive packet PTS values. This is complete non-sense for video
codecs which use reordering. The code compensated frame times for these
non-sense using the FPS value, but confused the rest of the player with
non-sense jumping around timestamps. So, all in all this mode is not
very useful.
Repurpose this mode for fixed frame rate playback. This gives almost the
same behavior as the old mode with forced framerate (--fps option). The
result is simpler and often more robust.
Instead of passing the PTS as separate field, pass it as part of the
usual data structures. Basically, this removes strange artifacts from
the API. (It's not finished, though: the final decoded PTS goes through
strange paths, and filter_video() finally overwrites the decoded
mp_image's pts field with it.)
We also stop using libavcodec's reordered_opaque fields, and use
AVPacket.pts and AVFrame.pkt_pts. This is slightly unorthodox, because
these pts fields are not "really" opaque anymore, yet we treat them as
such. But the end result should be the same, and reordered_opaque is
marked as partially deprecated (it's not clear whether it's really
deprecated).
This normally shouldn't happen. It does happen with VfW-muxed mkv files,
and would normally happen with avi files (except that we force the
correct association mode using an explicit hack for avi).
This is usually prepended by warnings like:
Decreasing video pts: 0.125000 < 0.167000
and after the switch, there should be no warnings anymore.
Background: avi likes to use DTS for timestamps instead of PTS.
Basically, there are no proper timestamps in the file, only frame
numbers. And Matroska is insane and stores the made-up DTS instead
of a proper PTS. This will be handled properly later.
Original commit was implemented differently by @bugmen0t. The problem here was
that the waf API was called directly, instead of using our own check_cc (which
defaults, among other things, to non mandatory checks).
- without Utils.* always returns empty string
- subprocess doesn't need extra quoting for sh -c
- "source" is a bash'ism, not in POSIX sh
- most shell commands embed newline at the end
Apparently Cocoa precise scrolling generates a lot of spurious events with
a delta that is equal to 0.0. Make sure that they are discarded and not added
to the input queue.
Even though this only known to happen with Cocoa, I implemented this at core
level since it makes sense in general.
Fixes: #310
waf wrongly installs resources to BundleRoot/Resources instead of
BundleRoot/Contents/Resources. Will post a patch to them later. Either way,
this must worked around until the next waf patch release.
It seems like a good idea not to generate any additional network traffic
and wait times if we don't have to.
Also print the URL it's downloading from.
Note that if we require a newer waf release, there will be a problem.
Running ./bootstrap.py won't get the newest waf version anymore in case
the old version is in the source dir. Not sure how to handle this.
waf apparently only appends a pkgconfig flag if it doesn't already exist in
the lib storage. Since our configure often checks for multiple libraries in
one call we want to keep the flags as is. This is especially important to
always keep stuff like -lm in the right place.
This is not needed anymore, because we decided that the PAR of the
decoded video matters, and not the PAR of the filtered video that
arrives at the VO.
In Python sets are unordered, so iterating them after converting to a list
always leads to different results. The code iterated on them to collect all
the flags to pass to the compiler, and since the order of the flags changed,
waf would rebuild all of the C files. Seems like in Python 2 this worked as
expected by pure chance.
This commit stores the sets as lists, and converts them to sets when the set
operations are needed.
Fixes#363
When mpv is started with some video filters set (--vf is used), and
hardware decoding is requested, and hardware decoding would be possible,
but is prevented due to video filters that accept software formats only,
the fallback didn't work properly sometimes.
This fallback works rather violently: it tries to initialize the filter
chain, and if it fails it throws away the frame decoded using the
hardware, and retries with software. The case that didn't work was when
decoding the current packet didn't immediately lead to a new frame. Then
the filter chain wouldn't be reinitialized, and the playloop would stop
playback as soon as it encounters the error flag.
Fix this by resetting the filter error flag (back to "uninitialized"),
which is a rather violent, but somewhat working solution.
The fallback in general should perhaps be cleaned up later.
In theory, we can't really do this, because we don't know when a spdif
frame ends. Spdif transports compressed audio through audio setups that
were originally designed for PCM only (which includes the audio filter
chain, the AO API, most audio output APIs, etc.), and to reach this
goal, spdif pretends to be PCM. Compressed data frames are padded with
zeros, until a certain data rate is reached, which corresponds to a
pseudo-PCM format with 2 bytes per sample and 2 channels at 48000 Hz.
Of course an actual spdif frame is significantly larger than a frame
of the PCM format it pretends to be, so cutting audio data on frame
boundaries (as according to the pseudo-PCM format) merely yields an
incomplete and broken frame, not audio that plays for the desired
duration.
However, sending an incomplete frame might still be much better than the
current behavior, which simply ignores --end/--length (but still lets
the video end at the exact end time).
Should this result in trouble with real spdif receivers, this commit
probably has to be reverted.
If the --fps option was given (MPOpts->force_fps), the demuxer FPS value
was overwritten with the forced value. This was fine, since the demuxer
value wasn't needed anymore. But with the recent changes not to write to
the demuxer stream headers, we don't want to do this anymore. So
maintain the (forced/updated) FPS value in dec_video->fps.
The removed code in loadfile.c is probably redundant, and an artifact
from past refactorings.
Note that sub.c will now always use the demuxer FPS value, instead of
the user override value. I think this is fine, because it used the
demuxer's video size values too. (And it's rare that these values are
used at all.)
Now the actual decoder doesn't need to care about this anymore, and it's
handled in generic code instead. This simplifies vd_lavc.c, and in
particular we don't need to detect format changes in the old way
anymore.
The only reason why these structs were dynamically allocated was to
avoid recursive includes in stheader.h, which is (or was) a very central
file included by almost all other files. (If a struct is referenced via
a pointer type only, it can be forward referenced, and the definition of
the struct is not needed.) Now that they're out of stheader.h, this
difference doesn't matter anymore, and the code can be simplified.
Also sneak in some sanity checks.
This used to be needed to access the generic stream header from the
specific headers, which in turn was needed because the decoders had
access only to the specific headers. This is not the case anymore, so
this can finally be removed again.
Also move the "format" field from the specific headers to sh_stream.
Use sh_stream over sh_sub. Use dec_sub (and mpctx->d_sub) instead of the
stream header. This aligns the subtitle code with the recent audio and
video refactoring.
sh_sub still has the decoder context, though. This is because we want to
avoid reinit when switching segments with ordered chapters. (Reinit is
fast, except for creating the ASS_Renderer, which in turn triggers
fontconfig.) Not sure how much this matters, though, because the initial
segment switch will lazily initialize the decoder anyway.
This is similar to the sh_audio commit.
This is mostly cosmetic in nature, except that it also adds automatical
freeing of the decoder driver's state struct (which was in
sh_video->context, now in dec_video->priv).
Also remove all the stheader.h fields that are not needed anymore.
This drops the --pp option, which was probably broken for a while. The
option automatically inserted the "pp" filter. The value passed to it
was ignored (which is probably broken, it always selected maximal
quality).
Inserting this filter can be done simply with --vf=pp, so this is not
needed anymore.
This means most code accessing this struct must now include hwdec.h
instead of dec_video.h. I just put it into dec_video.h at first because
I thought a separate file would be a waste, but it's more proper to do
it this way, as there are too many files which include dec_video.h only
to get the mp_hwdec_info definition.
This was printed before something was decoded, and thus was not really
correct. Also, this code is hilariously broken:
/* Assume FOURCC if all bytes >= 0x20 (' ') */
if (sh_audio->format >= 0x20202020)
mp_msg(MSGT_IDENTIFY, MSGL_INFO,
"ID_AUDIO_FORMAT=%.4s\n", (char *)&sh_audio->format);
Time to kill it.
This information can be accessed through properties instead.
sh_audio is supposed to contain file headers, not whatever was decoded.
Fix this, and write the decoded format to separate fields in the decoder
context, the dec_audio.decoded field. (Note that this field is really
only needed to communicate the audio format from decoder driver to the
generic code, so no other code accesses it.)
Move all state that basically changes during decoding or is needed in
order to manage decoding itself into a new struct (dec_audio).
sh_audio (defined in stheader.h) is supposed to be the audio stream
header. This should reflect the file headers for the stream. Putting the
decoder context there is strange design, to say the least.
Apparently some packaging systems (homebrew does this for example) change
`sys.path` before they run any Python script to ensure that only the correct
Python modules can be loadable.
We need to make sure cwd is in `sys.path` since we need to load
`wscript_build.py` from there.
Simply override the cprogram Task's __str__ method with our own implementation.
This is way easier on the eyes when compiling mpv during development, since
warnings are not pushed outside of your average screenful of content.
vo_opengl always loads the hwdec backend lazily, so hwdec_request_api()
has to be called to possibly load it. This makes vf_vavpp work with
software decoding. (Hardware decoding loads the backend before the
filter is initialized, so this case is different.)
Also, the VFCTRL_GET_HWDEC_INFO call doesn't need to be checked. If it
fails, the info will be left blank.
This initialized only the load_api and load_api_ctx fields, and left the
other fields as they were. This failed with vf_vavpp, which assumed all
fields are initialized.
This commit adds a new build system based on waf. configure and Makefile
are deprecated effective immediately and someday in the future they will be
removed (they are still available by running ./old-configure).
You can find how the choice for waf came to be in `DOCS/waf-buildsystem.rst`.
TL;DR: we couldn't get the same level of abstraction and customization with
other build systems we tried (CMake and autotools).
For guidance on how to build the software now, take a look at README.md
and the cross compilation guide.
CREDITS:
This is a squash of ~250 commits. Some of them are not by me, so here is the
deserved attribution:
- @wm4 contributed some Windows fixes, renamed configure to old-configure
and contributed to the bootstrap script. Also, GNU/Linux testing.
- @lachs0r contributed some Windows fixes and the bootstrap script.
- @Nikoli contributed a lot of testing and discovered many bugs.
- @CrimsonVoid contributed changes to the bootstrap script.
This was forgotten when the parser for mplayer2 EDL files was removed.
Change the header of the mpv EDL format to include a '#', so a naive
parser could skip the header as comment. (Maybe this is questionable;
on the other hand, if it can be simpler, why not.)
Also, strip the header in demux_edl.c before passing on the data, so the
header check doesn't need to be duplicated in tl_mpv_edl.c.
Edit Decision Lists (EDL) allow combining parts from multiple source
files into one virtual file. MPlayer had an EDL format (which sucked),
which mplayer2 tried to improve with its own format (which sucked). As
logic demands, mpv introduces its very own format (which sucks).
The new format should actually be much simpler and easier to use, and
its implementation is simpler and smaller too.
The intention of the existing code was trying to match demuxer-reported
stream IDs, instead of using possibly arbitrary ordering of the frontend
track list. But EDL files can consist of quite different files, for
which trying to match the stream IDs doesn't always make sense.
This didn't have any consequences, other than suddenly reinitializing
video when it works again (such as with EDL timeline mixing video and
audio-only files).
The AF control commands used an elaborate and unnecessary organization
for the command constants. Get rid of all that and convert the
definitions to a simple enum. Also remove the control commands that
were not really needed, because they were not used outside of the
filters that implemented them.
And by "cleanup", I mean "remove". Actually, only remove the parts that
are redundant and doxygen noise. Move useful parts to the comment above
the function's implementation in the C source file.
Some decoders used to read packets and decode data when calling
resync_audio_stream(). This required a special case in mp_seek() for
audio. (A comment mentions liba52, which is long gone; but until
recently ad_mpg123.c actually exposed this behavior.)
No decoder does this anymore, and resync_audio_stream() works similar
as resync_video_stream(). Remove the special case.
The priv struct is now allocated by talloc in stream.c. It doesn't need
to be manually freed, and using free() instead of talloc_free() probably
crashes.
When the decoder detects a format change, it overwrites the values
stored in sh_audio (this affects the members sample_format, samplerate,
channels). In the case when the old audio data still needs to be
played/filtered, the audio format as identified by sh_audio and the
format used for the decoder buffer can mismatch. In particular, they
will mismatch in the very unlikely but possible case the audio chain is
reinitialized while old data is draining during a format change.
Or in other words, sh_audio might contain the new format, while the
audio chain is still configured to use the old format.
Currently, the audio code (player/audio.c and init_audio_filters) access
sh_audio to get the current format. This is in theory incorrect for the
reasons mentioned above. Use the decoder buffer's format instead, which
should be correct at any point.
Commit 22b3f522 not only redid major aspects of audio decoding, but also
attempted to fix audio format change handling. Before that commit, data
that was already decoded but not yet filtered was thrown away on a
format change. After that commit, data was supposed to finish playing
before rebuilding filters and so on.
It was still buggy, though: the decoder buffer was initialized to the
new format too early, triggering an assertion failure. Move the reinit
call below filtering to fix this.
ad_mpg123.c needs to be adjusted so that it doesn't decode new data
before the format change is actually executed.
Add some more assertions to af_play() (audio filtering) to make sure
input data and configured format don't mismatch. This will also catch
filters which don't set the format on their output data correctly.
Regression due to planar_audio branch.
Simulate proper handling of AOPLAY_FINAL_CHUNK. Print when underruns
occur (i.e. running out of data). Add some options that control
simulated buffer and outburst sizes.
All this is useful for debugging and self-documentation. (Note that
ao_null always was supposed to simulate an ideal AO, which is the reason
why it fools people who try to use it for benchmarking video.)
demuxer->filepos contains the byte offset of the last read packet. This
is so that the player can estimate the current playback position, if no
proper timestamps are available. Simplify it to use demux_packet->pos in
the generic demuxer code, instead of bothering every demuxer
implementation about it.
(Note that this is still a bit incorrect: it relfects the position of
the last packet read by the demuxer, not that returned to the user. But
that was already broken, and is not that trivial to fix.)
This was originally added for better seeking where libavformat's seek
function won't work well: files with timestamp resets. In these cases,
the code tried to calculate an average bitrate, and then do byte based
seeks by multiplying the seek target time with the bitrate.
Apparently this was unreliable enough that the code was just commented
(and other parts became inactive). Get rid of it.
Note that the player still does byte based seeks in these cases when
doing percent-seeks.
This should allow it to select better fallback formats, instead of
picking the first encoder sample format if ao->format is not equal to
any of the encoder sample formats.
Not sure what is supposed to happen if the encoder provides no
compatible sample format (or no sample format list at all), but in this
case ao_lavc.c still fails gracefully.
The added function af_format_conversion_score() can be used to select
the best sample format to convert to in order to reduce loss and extra
conversion work.
It calculates a "loss" score when going from one format to another, and
for each conversion that needs to be done a certain score is subtracted.
Thus, if you have to convert from one format to a set of other formats,
you can calculate the score for each conversion, and pick the one with
the highest score.
Conversion between int and float is considered the worst case. One odd
consequence is that when converting from s32 to u8 or float, u8 will be
picked.
Test program used to develop this follows:
#define MAX_FMT 200
struct entry {
const char *name;
int score;
};
static int compentry(const void *px1, const void *px2)
{
const struct entry *x1 = px1;
const struct entry *x2 = px2;
if (x1->score > x2->score)
return 1;
if (x1->score < x2->score)
return -1;
return 0;
}
int main(int argc, char *argv[])
{
for (int n = 0; af_fmtstr_table[n].name; n++) {
struct entry entry[MAX_FMT];
int entries = 0;
for (int i = 0; af_fmtstr_table[i].name; i++) {
assert(i < MAX_FMT);
entry[entries].name = af_fmtstr_table[i].name;
entry[entries].score =
af_format_conversion_score(af_fmtstr_table[i].format,
af_fmtstr_table[n].format);
entries++;
}
qsort(&entry[0], entries, sizeof(entry[0]), compentry);
for (int i = 0; i < entries; i++) {
printf("%s -> %s: %d \n", af_fmtstr_table[n].name,
entry[i].name, entry[i].score);
}
}
}
These must be written even if there was no "final frame", e.g. due to
the player being exited with "q".
Although the issue is mostly of theoretical nature, as most audio codecs
don't need the final encoding calls with NULL data. Maybe will be more
relevant in the future.
This used to be in bytes, now it's in samples. Divide the value by 8
(assuming a typical audio format, float samples with 2 channels).
Fix some editing mistake or non-sense about the extra buffering added
(1<<x instead of x<<5).
Also sneak in a s/MPlayer/mpv/.
This changes option parsing as well as filter defaults slightly. The
default is now to encode to spdif (this is way more useful than writing
raw AC3 - what was this even useful for, other than writing broken ac3
-in-wav files?). The bitrate parameter is now always in kbps.
Apparently this was completely broken after commit 22b3f522. Basically,
this locked up immediately completely while decoding the first packet.
The reason was that the buffer calculations confused bytes and number of
samples. Also, EOF reporting was broken (wrong return code).
The special-casing of ad_mpg123 and ad_spdif (with DECODE_MAX_UNIT) is a
bit annoying, but will eventually be solved in a better way.
This could cause the bundle to recache stuff because of differences with
configuration of other software using fonconfig. The defaults OS X directories
should be added to fontconfig at build time (through configure).
Slightly simplifies memory management. This might make adding a demuxer
cache wrapper easier at a later point, because you can just copy the
complete stream header, without worrying that the wrapper will free the
individual stream header fields.
The existing code tried to remove the "extra" profile flags for h264.
FF_PROFILE_H264_INTRA doesn't matter for us at all, because it's set
only for profiles the vdpau/vaapi APIs don't support.
The FF_PROFILE_H264_CONSTRAINED flag on the other hand is added to
H264_BASELINE, except that it makes the file a real subset of H264_MAIN
and H264_HIGH. Removing that flag would select the BASELINE profile,
which appears to be rarely supported by hardware decoders. This means we
accidentally rejected perfectly hardware decodable files. Use MAIN for
it instead.
(vaapi has explicit support for CONSTRAINED_BASELINE, but it seems to be
a new thing, and is not reported as supported where I tried. So don't
bother to check it, and do the same as on vdpau.)
See github issue #204.
This used to be needed for teletext support. Teletext commit has been
removed (see commit ebaaa41f), and it appears this code is inactive.
It was just forgotten with the removal. Get rid of it completely.
Untested. (Like all changes to the TV code.)
Signed-off-by: wm4 <wm4@nowhere>
Significant modifications over the original patch by not overriding
syscalls with macros ("#define open v4l2open") for fallback, but the
other way around ("#define v4l2open open"). As consequence, the calls
have to be replaced throughout the file.
Untested, although the original patch probably was tested.
Apparently this is not portable to FreeBSD. It turns out that we
(probably) don't use any symbols defined by this header directly, so
the includes are not needed.
These use the _oldargs_ hack, which failed in combination with playback
resume. Make it work.
It would be better to port all filters to new option parsing, but that's
obviously too much work, and most filters will probably be deleted and
replaced by libavfilter in the long run.
ao_null should simulate a "perfect" AO, but framestepping behaved quite
badly with it. Framstepping usually exposes problems with AOs dropping
their buffers on pause, and that's what happened here.
Most libavcodec decoders output non-interleaved audio. Add direct
support for this, and remove the hack that repacked non-interleaved
audio back to packed audio.
Remove the minlen argument from the decoder callback. Instead of
forcing every decoder to have its own decode loop to fill the buffer
until minlen is reached, leave this to the caller. So if a decoder
doesn't return enough data, it's simply called again. (In future, I
even want to change it so that decoders don't read packets directly,
but instead the caller has to pass packets to the decoders. This fits
well with this change, because now the decoder callback typically
decodes at most one packet.)
ad_mpg123.c receives some heavy refactoring. The main problem is that
it wanted to handle format changes when there was no data in the decode
output buffer yet. This sounds reasonable, but actually it would write
data into a buffer prepared for old data, since the caller doesn't know
about the format change yet. (I.e. the best place for a format change
would be _after_ writing the last sample to the output buffer.) It's
possible that this code was not perfectly sane before this commit,
and perhaps lost one frame of data after a format change, but I didn't
confirm this. Trying to fix this, I ended up rewriting the decoding
and also the probing.
libav* is generally freaking horrible, and might do bad things if the
data pointer passed to it are not aligned. One way to be sure that the
alignment is correct is allocating all pointers using av_malloc().
It's possible that this is not needed at all, though. For now it might
be better to keep this, since the mp_audio code is intended to replace
another buffer in dec_audio.c, which is currently av_malloc() allocated.
The original reason why this uses av_malloc() is apparently because
libavcodec used to directly encode into mplayer buffers, which is not
the case anymore, and thus (probably) doesn't make sense anymore.
(The commit subject uses the word "cargo cult", after all.)
Remove the awkward planarization. It had to be done because the AC3
encoder requires planar formats, but now we support them natively.
Try to simplify buffer management with mp_audio_buffer.
Improve checking for buffer overflows and out of bound writes. In
theory, these shouldn't happen due to AC3 fixed frame sizes, but being
paranoid is better.
The format negotiation is the same, except don't confusingly copy the
input format into af->data, just to overwrite it later. af->data should
alwass contain the output format, and the existing code was just a very
misguided use of the af_test_output() helper function.
Just set af->data to the output format immediately, and modify the input
format properly.
Also, if format negotiation fails (and needs another iteration), don't
initialize the libavcodec encoder.
Before this commit, the af_instance->mul/delay values were in bytes.
Using bytes is confusing for non-interleaved audio, so switch mul to
samples, and delay to seconds. For delay, seconds are more intuitive
than bytes or samples, because it's used for the latency calculation.
We also might want to replace the delay mechanism with real PTS
tracking inside the filter chain some time in the future, and PTS
will also require time-adjustments to be done in seconds.
For most filters, we just remove the redundant mul=1 initialization.
(Setting this used to be required, but not anymore.)
Since ao_openal simulates multi-channel audio by placing a bunch of
mono-sources in 3D space, non-interleaved audio is a perfect match for
it. We just have to remove the interleaving code.
ALSA supports non-interleaved audio natively using a separate API
function for writing audio. (Though you have to tell it about this on
initialization.) ALSA doesn't have separate sample formats for this,
so just pretend to negotiate the interleaved format, and assume that
all non-interleaved formats have an interleaved companion format.
Replace the code that used a single buffer with mp_audio_buffer. This
also enables non-interleaved output operation, although it's still
disabled, and no AO supports it yet.
Implementation wise, this could be much improved, such as using a
ringbuffer that doesn't require copying data all the time. This is
why we don't use mp_audio directly instead of mp_audio_buffer.
This comes with two internal AO API changes:
1. ao_driver.play now can take non-interleaved audio. For this purpose,
the data pointer is changed to void **data, where data[0] corresponds to
the pointer in the old API. Also, the len argument as well as the return
value are now in samples, not bytes. "Sample" in this context means the
unit of the smallest possible audio frame, i.e. sample_size * channels.
2. ao_driver.get_space now returns samples instead of bytes. (Similar to
the play function.)
Change all AOs to use the new API.
The AO API as exposed to the rest of the player still uses the old API.
It's emulated in ao.c. This is purely to split the commits changing all
AOs and the commits adding actual support for outputting N-I audio.
Allocate af_instance->data in generic code before filter initialization.
Every filter needs af->data (since it contains the output
configuration), so there's no reason why every filter should allocate
and free it.
Remove RESIZE_LOCAL_BUFFER(), and replace it with mp_audio_realloc_min().
Interestingly, most code becomes simpler, because the new function takes
the size in samples, and not in bytes. There are larger change in
af_scaletempo.c and af_lavcac3enc.c, because these had copied and
modified versions of the RESIZE_LOCAL_BUFFER macro/function.
No AO can handle these, so it would be a problem if they get added
later, and non-interleaved formats get accepted erroneously. Let them
gracefully fall back to other formats.
Most AOs actually would fall back, but to an unrelated formats. This is
covered by this commit too, and if possible they should pick the
interleaved variant if a non-interleaved format is requested.
Based on earlier work by Stefano Pigozzi.
There are 2 changes:
1. Instead of mp_audio.audio, mp_audio.planes[0] must be used.
2. mp_audio.len used to contain the size of the audio in bytes. Now
mp_audio.samples must be used. (Where 1 sample is the smallest unit
of audio that covers all channels.)
Also, some filters need changes to reject non-interleaved formats
properly.
Nothing uses the non-interleaved features yet, but this is needed so
that things don't just break when doing so.
This affects 64 bit floats and big endian integer PCM variants
(basically crap nobody uses). Possibly not all MS-muxed files work, but
I couldn't get or produce any samples.
Remove a bunch of format tags that are not needed anymore. Most of these
were used by demux_mov, which is long gone. Repurpose/abuse 'twos' as
mpv-internal tag for dealing with the PCM variants mentioned above.
Now to shift audio pts when outputting to e.g. avi, you need an explicit
facility to insert/remove initial samples, to avoid initial regions of
the video to be sped up/slowed down.
One such facility is the delay filter in libavfilter.
My main problem with this is that the output format will be incorrect.
(This doesn't matter right, because there are no samples output.)
This assumes all audio filters can deal with len==0 passed in for
filtering (though I wouldn't see why not).
A filter can still signal an error by returning NULL.
af_lavrresample has to be fixed, since resampling 0 samples makes
libavresample fail and return a negative error code. (Even though it's
not documented to return an error code!)
When blending OSD and subtitles onto the video, we write bogus alpha
values. This doesn't normally matter, because these values are normally
unused and discarded. But at least on Wayland, the alpha values are used
by the compositor and leads to transparent windows even with opaque
video on places where the OSD happens to use transparency.
(Also see github issue #338.)
Until now, the alpha basically contained garbage. The source factor
GL_SRC_ALPHA meant that alpha was multiplied with itself. Use GL_ONE
instead (which is why we have to use glBlendFuncSeparate()). This should
give correct results, even with video that has alpha. (Or at least it's
something close to correct, I haven't thought too hard how the
compositor will blend it, and in fact I couldn't manage to test it.)
If glBlendFuncSeparate() is not available, fall back to glBlendFunc(),
which does the same as the code did before this commit. Technically, we
support GL 1.1, but glBlendFuncSeparate is 1.4, and I guess we should
try not to crash if vo_opengl_old runs on a system with GL 1.1 drivers
only.
Apparently we were using FFmpeg-specific APIs. I have no idea whether
this code is correct on both FFmpeg and Libav (no examples, bad
doxygen... why do they even complaint aht people are using their APIs
incorrectly?), but it appears to work on FFmpeg. That was also the case
before commit ebc4ccb though, where it used internal libavformat
symbols.
Untested on Libav, Travis will tell us.
Set the PulseAudio stream title, just like the VO window title is set.
Refactor update_vo_window_title() so that we can use it for AOs too.
The ao_pulse.c bit is stolen from MPlayer.
In theory, af_volume could use separate volume levels for each channel.
But this was never used anywhere.
MPlayer implemented something similar before (svn r36498), but kept the
old path for some reason.
This member was redundant. sh_audio->sample_format indicates the sample
size already.
The TV code is a bit strange: the redundant sample size was part of the
internal TV interface. Assume it's really redundant and not something
else. The PCM decoder ignores the sample size anyway.
Also do some cosmetic changes, like merging definition and
initialization of local variables.
Remove an annoying debug mp_msg() from af_open(). It just printed the
command line parameters; if this is really needed, it could be added
to af.c instead (similar as to what vf.c does).
Helps with readability. Also remove the ctx_opt_set_* helper macros and
use av_opt_set_* directly (I think these macros were used because the
lines ended up too long, but this commit removes two indentation levels,
giving more space).
This should allow to make format negotiation much simpler, since it
takes the responsibility to compare actual input and accepted input
formats from the filters. It's also backwards compatible. Filters which
have expensive initialization still can use the old method.
I have no idea what these do, but apparently they are needed to inform
ALSA about spdif configuration. First, replace the literal constant "6"
for the AES0 parameter with the symbolic constants from the ALSA
headers (the final value is the same). Second, copy paste some funky
looking parameter setup from VLC's alsa output for setting the AES1,
AES2, AES3 parameters. (The code is actually not literally copy-pasted,
but does exactly the same.)
My small but non-zero hope is that this could make DTS-HD work, or at
least work into that direction. I can't test spdif stuff though, and
for DTS-HD not even opening the ALSA device succeeds on my system.
Using spdif with alsa requires adding magic parameters to the device
name, and the existing code tried to deal with the situation when the
user wanted to add parameters too.
Rewrite this code, in particular remove the duplicated parameter string
as preparation for the next commit. The new code is a bit stricter, e.g.
it doesn't skip spaces before and after '{' and '}'. (Just don't add
spaces.)
This accessed tons of private libavformat symbols all over the place.
Don't do this and convert all code to proper public APIs. As a
consequence, the code becomes shorter and cleaner (many things the code
tried are done by libavformat APIs).
It's probably better if all auto-inserted filters are removed when doing
an af_add operation. If they're really needed, they will be
automatically re-added.
Fix the error message. It used to be for an actual internal error, but
now it happens when format negotiation fails, e.g. when trying to use
spdif and real audio filters.
Note that the change in seek_reset is not entirely equivalent: we even
drop the remainder of buffered audio when seeking. This should be more
correct, because the whole point of the reset_ao parameter is to control
whether audio queued for output should be dropped or not.
ao_lavc.c accesses ao->buffer, which I consider internal. The access was
done in ao_lavc.c/uninit(), which tried to get the left-over audio in
order to write the last (possibly partial) audio frame. The play()
function didn't accept partial frames, because the AOPLAY_FINAL_CHUNK
flag was not correctly set, and handling it otherwise would require an
internal FIFO.
Fix this by making sure that with gapless audio (used with encoding),
the AOPLAY_FINAL_CHUNK is set only once, instead when each file ends.
Basically, move the hack in ao_lavc's uninit to uninit_player.
One thing can not be entirely correctly handled: if gapless audio is
active, we don't know really whether the AO is closed because the file
ended playing (i.e. we want to send the buffered remainder of the audio
to the AO), or whether the user is quitting the player. (The stop_play
flag is overwritten, fixing that is perhaps not worth it.) Handle this
by adding additional code to drain the AO and the buffers when playback
is quit (see play_current_file() change).
Test case: mpv avdevice://lavfi:sine=441 avdevice://lavfi:sine=441 -length 0.2267 -gapless-audio
It spams these in verbose mode. It's caused by format negotiation code
in af.c. It's for the mpv format to ffmpeg-format case, and that one is
very uninteresting. (The ffmpeg supported audio formats are practically
never extended.)
This was supposed to handle preemption better. I still think the current
state isn't very nice, since the decoder can "accidentally" call the
previous render function after preemption (instead of calling the
reloaded function), so there might be issues. But all in all, this
dummy_render function is a bit confusing, and still not entirely
correct, so it's not worth it.
Turn the sample format definitions into an enum. (The format bits are
still macros.) The native endian versions of the new definitions don't
have a NE suffix anymore, although there are still compatibility defines
since too much code uses the NE variants.
Rename the format bits for special formats to help to distinguish them
from the actual definitions, e.g. AF_FORMAT_AC3 to AF_FORMAT_S_AC3.
We found that the stretching - although it usually improves the looks of
the fonts - is incorrect.
On DVD, subtitles can cover the full area of the picture, and they have
the same pixel aspect as the movie itself.
Too bad many commercially released DVDs use bitmap fonts made with the
wrong pixel aspect (i.e. assuming 1:1) - --stretch-dvd-subs will make
these more pretty then.
The previous code used the output video's pixel aspect for stretching
purposes, breaking rendering with e.g. -vf scale in the chain. Now
subtitles are stretched using the input video's pixel aspect only,
matching the intentions of the original subtitle author.
I overlooked the fact that the ffmpeg/libav build system only supports `--cc`
and completly ignores $CC. Hopefully this makes the build times a little
faster.
Fixes#332
This removes "--hwdec=crystalhd".
I doubt anyone even tried to use this. But even if someone wants to
use it, the decoders can still be explicitly invoked with e.g.:
--vd=lavc:h264_crystalhd
The only advantage our special code provided was fallback to
software decoding. (But I'm not sure how the ffmpeg crystalhd
pseudo-decoder actually behaves.)
Removing this will allow some simplifications as soon as we don't need
vdpau_old.c anymore.
This drops autorepeated key events for a number of commands. This should
help with slow situations accidentally triggering too many repeats. (I'm
not sure if this actually happened to users - maybe.)
It's not clear whether MP_CMD_COMMAND_LIST (multiple commands on one
binding separated by ';') should be repeated, or whether it should try
to do something clever. For now, disallow autorepeat with it.
This uses vdpau OpenGL interop to convert a vdpau surface to a texture.
Note that this is a bit weak and primitive. Deinterlacing (or any other
form of vdpau postprocessing) is not supported. vo_opengl chroma scaling
and chroma sample position are not supported. Internally, the vdpau
video surfaces are converted to a RGBA surface first, because using the
video surfaces directly is too complicated. (These surfaces are always
split into separate fields, and the vo_opengl core expects progressive
frames or frames with weaved fields.)
Instead of checking for resolution and image format changes, always
fully reinit on any parameter change. Let init_video do all required
initializations, which simplifies things a little bit.
Change the gl_video/hardware decoding interop API slightly, so that
hwdec initialization gets the full image parameters.
Also make some cosmetic changes.
These formats are helpful for distinguishing surfaces with and without
alpha. Unfortunately, Libav and older version of FFmpeg don't support
them, so code will break. Fix this by treating these formats specially
on the mpv side, mapping them to RGBA on Libav, and unseting the alpha
bit in the mp_imgfmt_desc struct.
Somehow the new parser ends up much smaller. Much of it is because we
don't parse some additional information. We just skip it, instead of
parsing it and then throwing it away.
More importantly, we use the physical order of entries, instead of
trying to sort them by entry number. Each "File" entry is followed by a
number that is supposed to be the entry number, and "File1" is first.
(Should it turn out that this is really needed, an additional field
should be added to playlist_entry, and then qsort().)
Make TOOLS/matroska.pl output structs with fields sorted by name in
ebml_types.h to make the order of fields deterministic. Fix warnings in
demux_mkv.c caused by the first struct fields switching between scalar
and struct types due to non-deterministic ebml_types.h field order.
Since it's deterministic now, this shouldn't change anymore.
The warnings produced by the compilers are bogus, but we want to silence
them anyway, since this could make developers overlook legitimate
warnings.
What commits 7b52ba8, 6dd97cc, 4aae1ff were supposed to fix. An earlier
attempt sorted fields in the generated C source file, not the header
file. Hopefully this is the last commit concerning this issue...
Before the bitstream_buffers field was deprecated, you had to free it,
otherwise you would leak memory.
(Although vdpau.c uses a new API, they managed to introduce a new
deprecation this quickly. This is a complaint.)
This introduces a memory leak of 12 bytes per file on every file on some
_older_ libavcodec versions. This is minor enough that I don't care.
Video has up to 4 textures, if you include obscure formats with alpha.
This means alpha formats could always overwrite the first scaler
texture, leading to corrupted video display. This problem was recently
brought to light, when commit 571e697 started to explicitly unbind all 4
video textures, which broke rendering for non-alpha formats as well.
Fix this by reserving the correct number of texture units.
mpvcore/player/playloop.c: In function 'seek':
mpvcore/player/playloop.c:209:54: warning: declaration of 'seek' shadows a global declaration [-Wshadow]
mpvcore/player/playloop.c:209:12: warning: shadowed declaration is here [-Wshadow]
mpvcore/player/playloop.c: In function 'queue_seek':
mpvcore/player/playloop.c:360:25: warning: declaration of 'seek' shadows a global declaration [-Wshadow]
mpvcore/player/playloop.c:209:12: warning: shadowed declaration is here [-Wshadow]
Signed-off-by: wm4 <wm4@nowhere>
VA-API's OpenGL/GLX interop is pretty bad and perhaps slow (renders a
X11 pixmap into a FBO, and has to go over X11, probably involves one or
more copies), and this code serves more as an example, rather than for
serious use. On the other hand, this might be work much better than
vo_vaapi, even if slightly slower.
Most hardware decoding APIs provide some OpenGL interop. This allows
using vo_opengl, without having to read the video data back from GPU.
This requires adding a backend for each hardware decoding API. (Each
backend is an entry in gl_hwdec_vaglx[].) The backends expose video data
as a set of OpenGL textures.
Add infrastructure to support this. The next commit will add support for
VA-API.
The configure followed 5 different convetions of defines because the next guy
always wanted to introduce a new better way to uniform it[1]. For an
hypothetic feature 'hurr' you could have had:
* #define HAVE_HURR 1 / #undef HAVE_DURR
* #define HAVE_HURR / #undef HAVE_DURR
* #define CONFIG_HURR 1 / #undef CONFIG_DURR
* #define HAVE_HURR 1 / #define HAVE_DURR 0
* #define CONFIG_HURR 1 / #define CONFIG_DURR 0
All is now uniform and uses:
* #define HAVE_HURR 1
* #define HAVE_DURR 0
We like definining to 0 as opposed to `undef` bcause it can help spot typos
and is very helpful when doing big reorganizations in the code.
[1]: http://xkcd.com/927/ related
Instead of having each demuxer do it (only demux_mkv actually did...),
let generic code determine whether the file is seekable. This requires
adding exceptions to demuxers where the stream is not seekable, but the
demuxer is.
Sort-of try to improve handling of unseekable files in the player. Exit
early if the file is determined to be unseekable, instead of resetting
all decoders and then performing a pointless seek.
Add an exception to allow seeking if the file is not seekable, but the
stream cache is enabled. Print a warning in this case, because seeking
outside the cache (which we can't prevent since the demuxer is not aware
of this problem) still messes everything up.
Pointless, using stream->start_pos/end_pos instead.
demux_mf was the only place where this was used specially, but we can
rely on timestamps instead for this case.
Never check s->seek (except in init), because it'd have to check
s->flags anyway. Also, for fast skippable streams (like pipes), don't
set the bit that indicates support for seek forward.
Make sure s->end_pos is always 0 for unseekable streams. Lots of code
outside of stream.c uses this to check seeking support.
Not really cargo cult, but an unexplainable, needless difference that
just exists to annoy us.
Fixes that gcc on MinGW treats format specifiers in MSVC mode. Just why?
Why?
There are some Microsoft Windows symbols which are traditionally used by
the mplayer core, because it used to be convenient (avi was the big
format, using binary windows decoders made sense...). So these symbols
have the exact same definition as the Windows one, and if mplayer is
compiled on Windows, the symbols from windows.h are used.
This broke recently just because some files were shuffled around, and
the symbols defined in ms_hdr.h collided with windows.h ones. Since we
don't have windows binary decoders anymore, there's not the slightest
reason our symbols should have the same names. Rename them to reduce the
risk for collision, and to fix the recent regression.
Drop WAVEFORMATEXTENSIBLE, because it's mostly unused. ao_dsound defines
its own version if the windows headers don't define it, and ao_wasapi is
not available on systems where this symbol is missing.
Also reindent ms_hdr.h.
Now that matroska.pl generates struct fields in deterministic order,
this should be the last time I change this.
(gcc and clang shouldn't warn about this line of code, but since they
do, we want to workaround and silence the warning anyway.)
Newer versions of perl randomize the hash used for hashes every time
it's run; this makes the order of the fields be non-deterministic. Tack
a sort there to make it deterministic. Needed to fix (or allow fixing) a
buggy gcc warning.
mpv crashed when linked files were not found. The reason was that the
chapters array contained some uninitialized data.
I have no idea how this code works (after the merge). The old code
actually seems to remove missing chapters, while the new code just
leaves them unintiialized. Work around the crash by initializing the
chapters array (and a bunch of other things) with 0, which means the
missing chapter will be located at 00:00:00 and have no name.
There is a regression since commit af0306d.
We had some code for checking profiles earlier, which was removed in
commits 2508f38 and adfb71b. These commits mentioned that (working) hw
decoding was sometimes prevented due to profile checking, but I can't
find the samples anymore that showed this behavior. Also, I changed my
opinion, and I think checking the profiles is something that should be
done for better fallback to software decoding behavior.
The checks roughly follow VLC's vdpau profile checks, although we do
not check codec levels. (VLC's profile checks aren't necessarily
completely correct, but they're a welcome help anyway.)
Add a --vd-lavc-check-hw-profile option, which skips the profile check.
Unfortunately, we can't avoid this warning 100%, because ebml_info is
written by a Perl script. I think the script writes the struct fields in
random order (thanks Perl), so there's no way to know whether the first
struct field is a scalar or a struct.
At least {0} is always valid here, even if it shows a warning. (The
compilers are wrong, see e.g. [1].)
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119
This one really did bite me hard (see previous commit), so enable it by
default.
Fix some cases of shadowing throughout the codebase. None of these
change behavior, and all of these were correct code, and just tripped up
the warning.
E.g. "-vf scale=848:480" set the w argument twice, instead of setting w
and then h.
This was caused by accidental shadowing of a local variable.
Regression since probably 4cd143e.
As preparation for resizing the window with input commands in the
following commit.
Since there are already so many functions which somehow resize the
window, add the word "highlevel" to the name of this new function.
DVD subs (rarely) have subtitle events without end timestamp. The
duration is unknown, and they should be displayed until they're
replaced by the next event.
FFmpeg fails hard to make us aware whether duration is unknown or
actually 0, so we can't distinguish between these two cases. It fails
at this twice: AVPacket.duration is set to 0 if duration is unknown,
and AVSubtitle.end_display_time has the same issue.
Add a hack that considers all bitmap subtitles with duration==0 as
events with uknown length. I'd rather accidentally display a hidden
subtitle (if they exist at all), instead of not displaying random
subtitles at all.
See github issue #325.
The code was selecting PA_CHANNEL_POSITION_MONO for MP_SPEAKER_ID_FC,
which is correct only with the "mono" channel layout, but not anything
else. Remove the mono entry, and handle mono separately.
See github issue #326.
We mixed the "old" AVFrame management functions (avcodec_alloc_frame,
avcodec_free_frame) with reference counting. This doesn't work
correctly; you must use av_frame_alloc and av_frame_free. Of course
ffmpeg doesn't warn us about the bad usage, but will just mess up
things silently. (Thanks a lot...)
While the alloc function seems to be 100% compatible, the free function
will do bad things, such as freeing memory that might still be
referenced by another frame. I didn't experience any actual bugs, but
maybe that was pure luck.
This stopped working when the code was changed to create a window even
if --wid is used.
It appears we can't create our own window in this case, because in X11
there is no difference between a window with the root window as parent,
and a window that is managed by the WM. So make this (kind of worthless)
special case use the root window itself.
Just doing this because mp_osd.h and osd.c is not consistent.
There are some other header files (command.h and screenshot.h), but
since I don't feel too good about inflating mp_core.h, I'm not merging
them, at least not yet.
I considered making a header file for each .c file, but decided against
it. Asking around, not making separate headers was deemed acceptable. In
the end, all of these depend on MPContext and store state inside of it,
so separate headers aren't all that useful anyway.
mplayer.c was a bit too big. Split it into multiple files. I hope the
way it's split makes sense. Maybe some things don't make too much sense,
or go against intuition. These will fixed as soon as I notice them.
Some files are a bit questionable (misc.c, osd.c, configfiles.c), and
suggestions how to organize this better are welcome.
Regressions are possible due to reorganized include statements.
Obviously I didn't just copy mplayer.c's orgy of include statements, but
recreated them for each file. It's easily possible that there are
oversights and mistakes, which will show up on other platforms.
There is one actual change: the public avutil.h include is removed from
encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I
consider using libavutil too much as dangerous, because the set of
include files they recursively pull in is rather arbitrary and is
different between FFmpeg and Libav.
All these files access mp_core.h and MPContext, and form the actual
player application. They should be all in one place, and separate
from the other sources that are mere utility helpers.
Preparation for splitting mplayer.c into multiple smaller parts.
On systems that provide legacy OpenGL (up to 2.1), but not GL3 and
later, creating a GL3 context will fail. We then revert to legacy GL.
Apparently the error message printed when the GL3 context creation
fails is confusing. We could just silence it, but there's still a X
error ("X11 error: GLXBadFBConfig"), which would be quite hard to
filter out. For one, it would require messing with the X11 error
handler, which doesn't even carry a context pointer (for application
private data), so we don't even want to touch it. Instead, change
the error message to inform the user what's actually happening: a
fallback to an older version of OpenGL.
When starting mpv with nohup, file descriptor 0 seems to be invalid for
some reason. (I'm not quite sure why it should be... /proc/pid/fd/0
seems to indicate it's just /dev/null, and using /dev/null explicitly
shows that it works just fine.)
select() will always immediately return, and this causes mpv to burn CPU
without reason. Fix this by treating it as EOF when read() returns
EBADF.
Also add EINVAL to this condition, because it seems like a good idea.
This might actually fix an issue with DVB channel switching, because
that uses some sort of hack to reinitialize the demuxer, which causes
the subtitle renderer to initialize twice. As consequence, the assert in
add_subtitle_fonts_from_sources() would trigger.
I didn't actually test the DVB case, because I don't have the hardware.
Disable autorepeat for the "add"/"cycle" commands when changing
properties that are choices (such as fullscreen, pause, and more).
In these cases, autorepeat is not very useful, and can rather harmful
effects (like triggering too many repeated commands if command
execution is slow).
(Actually, the commands are just dropped _after_ being repeated, since
input.c itself does not know enough about the commands to decide whether
or not they should be repeated.)
Trying to toggle the border during fullscreen (with "cycle border")
would leave the window stuck without border, and it couldn't be
restored. This was because vo_x11_decoration() always excepted to be
called when toggling the state, and thus confusing the contents of the
olddecor variable. Add got_motif_hints to hopefully prevent this.
Also, when changing the border, don't take fs in account. May break on
older/broken WMs, but all in all is in fact more robust and simpler,
because you do not need to update the border state manually when
returning from fullscreen.
Defining names like min, max etc. in an often used header is not really
a good idea.
Somewhat similar to MPlayer svn commit 36491, but don't use libavutil,
because that typically causes us sorrow.
Roughly follows MPlayer svn commits 36492 and 36493. We also remove
the volume peak reporting. (There are much better libavfilter filters
for this, I think.)
Not up to my quality standards (need ASS boundingboxes), so disabled by default and undocumented for now.
Can be enabled with seektooltip=yes in plugin_osc.conf
There are certain cases where mpv will automatically set options, such
as per-file configs, per protocol/VO/AO/extension profiles, and
watch_later resume configs. All these were overwriting the user's
options, even when they were specified on command line.
Add something that explicitly preserves command line options. This
means you can now actually use the command line to override any
options that the playback resume functionality backups and restores.
It still happily overrides options set at runtime (e.g. changed via
properties while playing a file; then playing the next file might
override them again), but maybe that's not a problem with typical use.
It's true that ALSA uses alloca() in some of its API functions, but
since this is hidden behind macros in the ALSA headers, we have no
reason to include alloca.h ourselves.
Might help with portability (FreeBSD).
In cases we're just listing options or checking their values (as it
happens with -vo/-vf etc. suboption parsing), we don't need to allocate
abd initialize the actual option struct. All we're interested in is
the list of options.
The default behavior of weston changed some time ago to not fill the surface
black for fullscreen windows.
Now let mpv draw the whole screen in fullscreen mode.
Keep track of the default values directly, instead of creating a new
instance of the option struct just to get the defaults.
Also get rid of the special handling of m_obj_desc.init_options.
Instead, handle it purely by the option parser. Originally, I wanted to
handle --vo=opengl-hq and --vo=direct3d_shaders with this (by making
them aliases to the real VOs with a different preset), but since --vo
=opengl-hq=help prints the wrong values (as consequence of the
simplification), I'm not doing that, and instead use something
different.
Might reduce memory overhead, and is also less annoying.
Since pointers to m_config_options are kept around, this assumes
they're added only during initialization. Otherwise you'd get
dangling pointers.
Minor simplification. String options are now not allowed to use the
same variable/field anymore. (Also affects other "dynamic" options
which require memory allocation.)
This seems to be a problem only in OS X 10.9. I guess they improved the
general speed of the Cocoa startup and suddenly mpv core takes more time
than the Cocoa thread to initialize.
Fixes#285
(hopefully!)
Drop the author and comment fields. They were completely unused - not
even printed in verbose mode, just dead weight.
Also use designated initializers and drop redundant flags.
Set the input/output format in filter init. This doesn't change anything
functionally, but it makes the forced format show up in the filter chain
init verbose output (which sometimes prints the filter chain before all
filters have been configured).
af_format is the old audio conversion filter. It could do all possible
conversions supported by the audio chain. However, ever since the
addition of af_lavrresample, most conversions are done by
libav/swresample, and af_format is used as fallback.
Separate out the fallback cases and remove af_format. af_convert24 does
24 bit <-> 32 bit conversions, while af_convertsignendian does sign and
endian conversions. Maybe the way the conversions are split sounds a bit
odd. But the former changes the size of the audio data, while the latter
is fully in-place, so there's at least different buffer management.
This requires a quite complicated algorithm to make sure all these
"partial" conversion filters can actually get from one format to
another. E.g. s24le->s32be always requires convertsignendian and
convert24, but af.c has no idea what the intermediate format should
be. So I added a graph search (trying every possible format and
filter) to determine required format and filter. When I wrote this,
it seemed this was still better than messing everything into
af_lavrresample, but maybe this is overkill and I'll change my
opinion. For now, it seems nice to get rid of af_format though.
The AC3->IEC61937 conversion isn't supported anymore, but I don't think
this is needed anywhere. Most AOs test all formats explicitly, or use
the AF_FORMAT_IS_IEC61937() macro (which includes AC3).
One positive consequence of this change is that conversions always
include dithering (done by libav/swresample), instead of possibly going
through af_format, which doesn't do anything fancy.
Rename af_force to af_format. It's essentially compatible with command
line uses of af_format. We retain a compatibility alias for af_force.
At least not with ffmpeg.
Honestly, I have no idea how little endian AC3 works at all, since
ao_pcm doesn't do anything special about it, and treats it like s16le.
Maybe it's broken and ffmpeg has special logic to detect it.
This is obviously not needed, and just creates potential for bad
breakages (e.g. what happens if libquvi tries to open a normal filename
as http URL?).
Note that for simplicity, we still pass file:// URIs to quvi, and we
don't exclude other protocol prefixes either. In general, we don't know
what protocols quvi might support, so we don't try to second-guess it.
(Even though in practice, it's probably only "http" and "https".)
The code did not set and unset the current context inside sync sections. I am
not sure if this was an actual problem but this is better since the context is
linked to a single thread. In my brief tests this seems to avoid garbage to
show up in fullscreen.
Instead of removing dragging we now test if it we should drag the window or
not. Because if the OSC shows up we can not drag the window because that would
cause mouse events that makes the OSC disappear.
gcc and clang happen to allow {} to default-initialize a struct, but
strictly speaking, C99 requires at least {0}. In one case, we use {{0}},
but that's only because gcc as well as clang are too damn stupid not
to warn about {0}, which is a perfectly valid construct in this case.
(Sure is funny, don't warn about the non-standard case, but warn about
another standard conform case.)
Leaving these braces away just because the syntax allows them is really
obnoxious. It removes the visual cues which help understanding the code
at the first look.
For the record,
if (cond)
something();
is ok, as long as there's no else branch, and the if body is one
physical line. But everything else should have braces.
This was probably not a real problem. But it's not entirely clear
whether this could actually happen or not, so it's better to be
defensive. The code is now also somewhat easier to understand.
If cache was enabled, using ordered chapters could easily crash. The
reason is that enable_cache() reopens the demuxer and closes the old
one. The code after that (reading m->ordered_chapters etc.) then
accessed freed data.
This commit also avoids enabling cache for files which are not used
(which would make opening much slower).
Implement MP_GROW_ARRAY using MP_TARRAY_GROW. MP_GROW_ARRAY is basically
the earlier version of MP_TARRAY_GROW, and had different semantics. When
I added MP_TARRAY_GROW, I didn't dare to change it, but I think all code
that relied on the exact semantics of MP_GROW_ARRAY is gone now, or the
difference doesn't matter anyway. The semantic change is that now
(n+1)*2 elements are preallocated instead of n*2.
Also, implement MP_TARRAY_GROW using MP_RESIZE_ARRAY, which saves 1 line
of code.
In future, these macros should be part of TA.
Was disabled by default, was never used, internal support was
inconsistent and poor, and there has been virtually no interest in
creating translations.
And I don't even think that a terminal program should be translated.
This is something for (hypothetical) GUIs.
This adds support for ChapterSegmentEditionUID (pull request #258),
and also fixes issue #278 (pull request #292).
In fact, this is a straight merge of pr/292, which also contains pr/258.
When adding or removing frames to avoid 1-frame seeks on chapter
boundaries, the end of the chapter needs to be pushed or pulled by the
same amount to keep the intended end frame the same.
Note that you still need --vd-lavc-o='strict=-2' to enable the decoder.
Also, there's no guarantee that all required features for HEVC demuxing
are actually implemented, nor that the current muxing schema is the
final one.
This could cause the OSC to be displayed without mouse interaction: for
example, starting mpv with --fs, and putting the mouse to where the OSC
area is beforehand, would cause the OSC to appear and stay visible. We
don't want that. The simplest solution is not generating artificial
mouse move events from mouse enter events, because they make the OSC
think the mouse was actually moved.
Also see commit 0c7978c, where handling of mouse enter events was added.
This was supposed to fix certain corner cases, but they're not relevant
anymore due to changes in OSC behavior.
Commit 9777047 fixed this as well (by resetting the mouse state on
MOUSE_LEAVE), but all the behavior reverted with this commit as perhaps
a bad idea. It wasn't very robust, made it hard to distinguish real
events from artificial ones, and finally made the mouse cursor more
often visible than needed. (Now switching between workspaces doesn't
make the cursor visible again when switching to a fullscreened mpv.)
Now you can pretend the config file is quite literally command line
values dumped into a file, e.g.
--option1=value
--option2=value
...
although the underlying mechanisms are quite different.
Until now it used both char[] and bstr variants in the same code, which
was nasty. For example, the next commit would have additionally required
using memmove() to remove the prefix from the char[] string.
This fixes handling of e.g. "--vf=lavfi=[ noise ]" when used with
playback resume functionality. The spaces made it bug out, and there are
more cases where it could potentially break.
We could always escape for simplicity, but for now make old and new mpv
builds somewhat interoperable and use this new escaping only if needed.
This parses "%len%string" escapes, where string can contain any
characters. This method of escaping has also been used in other parts
of mplayer and mpv, so it's not a new idea.
(Also, don't confuse with URL encoding.)
Needed by the following commit.
With the way I've been doing releases in the release/0.1 branch, this
proved completely useless. You need to write the VERSION file anyway,
and since we use github's automatically generated tarballs (via its
release system), the VERSION file needs to be in the git revision of
a release anyway. git master on the other hand displayed the v0.1.0
tag, because the tag is within the master branch.
This essentially reverts commit b27f65a. Now just print the contents
of the VERSION file if it exists, and likewise, we append the git
revision if it exists. (Do that even if VERSION exists, because this
way we can tell if someone is using the release branch at an in-between
point where no new release has been made yet.)
Also change what the FFmpeg version info looks like, and additionally
dump lavfi/lavr/lswr versions. (Don't bother with libavdevice and
libpostproc, they're not important enough.)
Unfortunately, there's no "single" FFmpeg/Libav version due to fatal
braindeath on the FFmpeg/Libav side. We can't map the versions to
releases either (it simply isn't accessible anywhere).
The mouse area that covers the OSC is now only activated when the OSC is actually visible, to make sure the mouse still hides if it happens to be parked in the OSC area without making the OSC show up.
vo_image didn't handle OSD redrawing correctly anymore after OSD
redrawing behavior was changed in commit ed9295c (or maybe it has been a
problem for a longer time, and only showed up now). Basically, flip_page
was called unexpectedly and when no image was stored, which made it
crash trying to access the image. This could happen when for example
provoking OSD redrawing by pausing while using --vo=image, or by using
this command line: mpv --vo=image '-vf=lavfi="select=not(mod(n\,3))"'
Fix by removing the code that pretends vo_image can redraw OSD, and by
removing the framestepping fallback, which could make bad things happen
if the VO didn't support OSD redrawing. By now, there aren't any real
VOs that can't redraw the OSD properly, so this code is not needed and
just complicates things like vo_image.
This change likely will also be useful for vo_lavc (encoding).
Libass is technically an optional dependency, but in practice users
tend to disable libass accidentally or for the hell of it to get
something "minimal", without being aware of the consequences.
The deadzone-size is now by default zero, so movement on the entire window will make the OSC show up. To avoid it showing up by randomly moving mice, the option 'minmousemove' controls how many pixels movement (default: 1) between ticks (frames) are necessary to make the OSC show up.
The deadzone can be reenabeled by setting the option 'deadzonesize' (default: 0 = no deadzone, 1 = entire area between OSC and opposite window border), to restore the old behavior, set it to ~0.92.
The OSC will hide immediately when leaving the window or entering the deadzone (if existing) or after the time specified with 'hidetimeout' (default: 500ms) passed without any new movement. Set to negative value to disabling auto-hide (thus restoring old behavior). The OSC will never hide if hovered by the mouse.
Now that talloc has been removed, the license can be switched back to
GPLv2+. Actually, there never was a GPLv2+ licensed MPlayer (fork or
not) until now, but removal of some GPLv2-only code makes this possible
now. Rewrite the Copyright file to explain the reasons for the licenses
MPlayer and forks use. The old Copyright file didn't contain anything
interesting anymore, and all information it contained is available at
other places in the source tree.
The reason for the license change itself is that it should improve
interoperability with differently licensed code in general.
This essentially reverts commit 1752808.
There are multiple reasons to do this. One big reason is the license:
talloc is LGPLv3+, which forces mpv to be licensed as GPLv3+.
Another one is that our talloc copy contains modifications, which makes
it essentially incompatible with upstream talloc (in particular, our
version aborts on out of memory conditions - well, it wasn't my idea).
Updating from upstream is also a bit involved - the talloc source is
not really organized in a way to allow copying it into projects (and
this isn't an intended use-case).
Finally, talloc is kind of big and bloated. The replacement halves the
amount of code - mainly because we didn't use all talloc features. It's
even more extreme if you compare upstream talloc (~4700 lines) and the
new allocator without talloc compat (~900 lines).
The replacement provides all features we need. It also doesn't clash
with talloc. (The talloc compatibility wrapper uses macros to avoid
introducing linker-level symbols which could clash with libtalloc.)
It also tries to lower the overhead (only 4 words opposed to 10 words
in talloc for leaf nodes in release mode). Debugging features like leak
reporting can be enabled at compile time and add somewhat more overhead.
Though I'm not sure whether the overhead reduction was actually
successful: allocations with children need an "extra" header, which adds
plenty of overhead, and it turns out that almost half of all allocations
have children. Maybe the implementation could be simplified and the
extra header removed - even then, overhead would be lower than talloc's.
Currently, debugging features can be entirely deactivated by defining
NDEBUG - I'm not sure if anything defines this directly yet, though.
Unlike in talloc, the leak reporting stuff is thread-safe. (That's also
why it's far less elegant, and requires extra list pointers.)
Comes with a compatibility layer, so no changes to mpv source code
are needed. The idea is that we will pretend to be using talloc for
a while, so that we can revert to our old talloc implementation at
any time for debugging purposes.
Some inspiration was taken from Mesa's ralloc:
http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/ralloc.h
This is another talloc replacement, but lacks some features we need
(getting size of an allocation, debugging features, being able to
access children in the dtor).
There's some information in ta/README what will happen next and how the
transition is expected to progress.
Change talloc destructor so that they can never signal failure, and
don't return a status code. This makes our talloc copy even more
incompatible to upstream talloc, but on the other hand this is
preparation for getting rid of talloc entirely.
(The talloc replacement in the next commit won't allow the talloc_free
equivalent to fail, and the destructor return value would be useless.
But I don't want to change any mpv code either; the idea is that the
talloc replacement commit can be reverted for some time in order to
test whether the talloc replacement introduced a regression.)
This only shows any differences when mpv isn't frontmost and is in fullscreen.
Cmd+Tab overlay is still at a higher level as to avoid complete usability fail.
Before this, they were shown on terminal only. Now they use the OSD
mechanism, which shows them on the video window or the terminal,
depending on settings and what's available.
Changing volume when audio is disabled was a feature request (github
issue #215), and was introduced with commit 327a779.
But trying to fix github issue #280 (volume is not correct in no-audio
mode, and if audio is re-enabled, the volume set in no-audio mode isn't
set), I concluded that it's not worth the trouble and the current
implementation is questionable all around. (For example, you can't
change the real volume in no-audio mode, even if the AO is open - this
could happen with gapless audio.) It's hard to get right, and the
current mixer code is already hilariously overcomplicated. (Virtually
all of mixer.c is an amalgamation of various obscure corner cases.)
So just remove this feature again.
Note that "options/volume" and "options/mute" still can be used in
idle mode to adjust the volume used next time, though these properties
can't be used during playback and thus not in audio-only mode.
Querying the volume still "works" in audio-only mode, though it can
return bogus values.
The argument or this change is that --loop should set how often the
file is played, not the number of additional repeats.
Based on pull request 277, with additions to the manpage and removal
of "--loop=0".
Signed-off-by: wm4 <wm4@nowhere>
The primary effect of this commit is that it fixes playback resume if
libquvi 0.9 and German locale are used, and libkdecore is on the system.
(See github issue #279.)
libquvi uses libproxy to determine system-wide proxy settings. libproxy
in turn loads libkdecore (if present) to determine KDE proxy settings.
libkdecore has a global constructor, which calls setlocale(LC_ALL, ""),
switching the current locale from "C" to what the user's settings. This
breaks some basic C string processing functions. Note that the locale
won't be set on program start, but only when libproxy calls dlopen() on
its config_kde module, which actually causes libkdecore to be loaded and
initialized.
In particular, with German locale, snprintf() would use "," instead of
"." when formatting float values, which in combination with playback
resume, would lead to parse errors the next time mpv was started, which
is how this issue was found.
I'd consider this a bug with libkdecore or at least libproxy. No library
should ever even touch locale: it might break basic expectations on C
string handling functions, might override program settings, and it's not
thread-safe. But this is so nasty and severe, that a quick hack to fix
it hurts less.
See github issue #279 and KDE bug #325902.
Before this patch, those will cause a crash:
mpv -playlist /dev/null
mpv -playlist <(bla) # if the result of bla is empty
Signed-off-by: Mohammad Alsaleh <CE.Mohammad.AlSaleh@gmail.com>
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
previously, mp_ring_read_cb() would allow reading past the end of the
ringbuffer when buffered > available. mp_ring_read() had logic for
splitting the read into two, which I duplicated into mp_ring_read_cb().
Since ordered editions can reference external files, when an ordered
chapter references another ordered edition, we have to go and figure out
what is is referencing as well.
When playing a Matroska file with ordered chapters, it may reference
another file by edition uid. When this edition is also ordered, it may
reference other files. When this occurs, the new segment/edition pair is
added to the list of sources to search for.
To support edition references in matroska chapters, editions need to be
remembered for each chapter and source. To facilitate easier management
of these now-paired uids, a single structure is used.
First, don't try to seek if the result is 0 (i.e. nothing found, or
subtitle event happens to be exactly on spot).
Second, since we never can make sure that we actually seek to the exact
subtitle PTS (seeking "snaps" to video PTS), offset the seek by 10ms.
Since most subtitle events are longer than 10ms, this should work fine.
The OSC will now display cache fill status between the timecodes, but only if it's below 48% to not clutter the interface with erratically changing values.
By default, the displayed value is multiplied by 2 to not confuse users who are unfamillar with the inner workings of the caching system. This can be disabled using the iAmAProgrammer=true setting.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@36461 b3059339-0415-0410-9bf9-f77b7e298cf2
Fixes playback of http://mpg123.org/test/44and22.mp3
Cherry-picked from MPlayer SVN rev. #36461, a patch by
Thomas Orgis, committed by by Reimar Döffinger.
You couldn't jump to the first entry in the playlist, if that entry was
marked as "too short". But this is usually fine, because it doesn't get
into the way of the user. (This feature is meant to allow being able to
jump backwards through the playlist even if a file immediately stops
playback right after initialization, not to prevent playing these files
at all.)
Also, apply the skip logic when wrapping around the playlist when going
backwards. This happens with --loop, because looping pretends the
playlist is infinitely repeated forwards and backwards (as long as the
playlist_prev/next commands are concerned).
Also add some comments.
When for example switching off the video stream, and --force-window is
used, forcefully reconfigure the VO. This will reset the size, and will
clear the window with black.
Needed some effort, because you don't always want to clear the window
on "discontinuity" points like going to a next file: this would
introduce some flicker.
glXGetVisualFromFBConfig() specifies specifies that it can return NULL
if there is no associated X visual. Instead of crashing, let
initialization fail. I'm not sure if this is actually supposed to work
with a fallback visual (passing a NULL visual to vo_x11_config_vo_window
would just do this), but let's play safe for now.
Apparently this can happen when trying to use vo_opengl over a remote
X display.
Output silence to the output buffer during underruns. This removes small
occasional glitches that happen before the AUHAL is actually paused from the
`audio_pause` call.
Fixes#269
Reverts a small change made in commit ed9295c. This is needed, because
otherwise mplayer.c/update_video_attached_pic() thinks it never has to
update the picture after initialization. (Maybe there would be more
elegant ways to handle this, but not without adding extra state.)
Didn't handle VO events, didn't handle OSD message management.
There is probably still some strangeness left. --idle mode was never
made for direct interaction.
We can render subtitles if a VO is open. Whether we're decoding video
(i.e. if mpctx->sh_video is set) doesn't really matter.
Subtitle display with --force-window still doesn't quite work yet,
because there's nothing to actually force redrawing of subtitles in this
mode.
This commit adds the --force-window option, which will cause mpv always
to create a window when started. This can be useful when pretending that
mpv is a GUI application (which it isn't, but users pretend anyway), and
playing audio files would run mpv in the background without giving a
window to control it.
This doesn't actually create the window immediately: it only does so
only after initializing playback and when it is clear that there won't
be any actual video. This could be a problem when starting slow or
completely stuck network streams (mpv would remain frozen in the
background), or if video initialization somehow is stuck forever in
an in-between state (like when the decoder doesn't output a video
frame, but doesn't return an error either). Well, we can pretend only
so much that mpv is a GUI application.
Seeking normally resets the VO and throws away the currently displayed
frame, so if you seek outside the video with --keep-open enabled, the
window would normally be "stuck" and not redraw properly, because there
is no source video frame that could be redrawn. To deal with this, a
precise seek to the position of the last displayed video frame was
issued.
This usually worked, but it can fail for formats where seeking is broken
or not possible (consider reading from a pipe).
Fix this by changing the semantics for vo_seek_reset(): now the video
frame is remembered even after seeking.
Note that this changes behavior a little when trying to seek outside of
a file with --keep-open enabled. Since no actual seek is done anymore,
the video will remain "frozen" on the previous position, and you can't
unpause or framestep to see the video between current position and
actual end of the video. If users complain, I might revert this commit.
vo_vdpau is the only VO which implements VOCTRL_RESET. Redrawing the
last output frame is hard, because the output could consist of several
source video frames with certain types of post-processing
(deinterlacing). Implement redrawing as special case by keeping the
previous video frames aside until at least one new frame is decoded.
This improves the previous commit, but is separate, because it's rather
complicated.
Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME,
which means the VO wouldn't redraw OSD and window contents, and the
player would appear frozen to the user. This was a bit stupid, and makes
dealing with some corner cases much harder (think of --keep-open, which
was hard to implement, because the VO gets into this state if there are
no new video frames after a seek reset).
Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME.
There are two aspects of this: First, behavior after a (successful)
vo_reconfig() call, but before any video frame has been displayed.
Second, behavior after a vo_seek_reset().
For the first issue, we define that sending VOCTRL_REDRAW_FRAME after
vo_reconfig() should clear the window with black. This requires minor
changes to some VOs. In particular vaapi makes this horribly
complicated, because OSD rendering is bound to a video surface. We
create a black dummy surface for this purpose.
The second issue is much simpler and works already with most VOs: they
simply redraw whatever has been uploaded previously. The exception is
vdpau, which has a complicated mechanism to track and filter video
frames. The state associated with this mechanism is completely cleared
with vo_seek_reset(), so implementing this to work as expected is not
trivial. For now, we just clear the window with black.
Trying to connect multiple mpv clients to JACK with the
JackUseExactName option would fail unless the user manually
specifies a unique client name. This changes the behavior
to automatically generate a unique name if the requested
one is already in use.
vo_x11 had a clever trick to implement a video equalizer: it requested a
DirectColor visual. This is a X11 mechanism which allows you to specify
a lookup table for each color channel. Effectively, this is a safe
override for the graphic card's gamma ramp. If X thinks the window
deserves priority over other windows in the system, X would temporarily
switch the gamma ramp so that DirectColor visuals can be displayed as
the application intends. (I'm not sure what the exact policy is, but in
practice, this meant the equalizer worked when the mouse button was
inside the window.)
But all in all, this is just lots of useless code for a feature that is
rarely ever useful. Remove it and use the libswscale equalizer instead.
(This comes without a cost, since vo_x11 already uses libswscale.)
One worry was that using DirectColor could have made it work better in
8-bit paletted mode. But this is not the case: there's no difference,
and in both cases, the video looks equally bad.
Considering that we use version control, maintaining an AUTHORS file
doesn't make much sense, and indeed it was barely touched since the time
mplayer2 forked from MPlayer. None of the contributors to mplayer2 or
mpv are listed in this file (even uau's work is not appropriately
reflected, despite having an entry in this file).
I'm removing this file because it's obviously pointless to keep around,
and moreover it's misleading.
In theory removing this file might be questionable: the git log reaches
back into CVS and SVN times, which don't have separate committer and
author fields for each comment. The commit messages could be incomplete
and not mention the original author, while the AUTHORS file somehow
could. I doubt this is a real concern, since you can always reconstruct
the original AUTHORS file from git.
Another concern is that this could be interpreted as disrespectful to
the people mentioned in this file; but it isn't meant to be
disrespectful.
Also point out a slight irregularity in the Copyright file.
Commit 884c179 attempted to make it possible to skip backwards through
the playlist, even for files which fail to intitialize, or play for a
very short time. This was also used to prevent mpv from looping forever
and doing nothing if --loop=inf is used, and no file in the playlist is
playable.
This broke looping of very short files, because mpv was assuming that
this case happened. But there are legitimate use cases.
Fix this by making the looping case special. Instead of checking whether
playback was "very short", check whether something could be decoded and
displayed/played. If yes, allow looping.
After rebasing my dev branch it turned out that the code deadlocked on
recursive calls of `vo_control`. Make the locking code a little bit smarter
by making always skip locking/unlocking if we are executing a chunck of
code that is already synchronized with `dispatch_sync`.
Split the code to several files. The GUI elements now each have they own files
and private state. The original code was a mess to respect the retarded mplayer
convention of having everything in a single file.
This commit also seems to fix the long running bug of artifacts showing
randomly when going fullscreen using nVidia GPUs.
Don't allocate a VAImage and a mp_image every time. VAImage are cached
in the surfaces themselves, and for mp_image an explicit pool is
created. The retry loop runs only once for each surface now.
This also makes use of vaDeriveImage() if possible.
Until now, mouse positions were just passed to the core as-is, even if
the mouse coordinates didn't map to any useful coordinate space, like
OSD coordinates. Lua scripting (used by the OSC, the only current user
of mouse input) had to translate mouse coordinates manually to OSD space
using mp_get_osd_mouse_pos(). This actually didn't work correctly in
cases mouse coordinates didn't map to OSD (like vo_xv): the mouse
coordinates the OSC got were correct, but input.c was still expecting
"real" mosue coordinates for mouse areas.
Fix this by converting to OSD coordinates before passing the mouse
position to the core.
Do this so that MOUSE_LEAVE can't be combined with other keys. (E.g.
keep 'w' pressed, then move the mouse outside of the mpv window; it will
print a warning what w-MOUSE_LEAVE is not mapped.)
It appears the last run missed all mp_tmsg().
Since the command parser also prints messages, it needs a new parameter
to pass a log context. We go the easy way and just require the input_ctx
to be passed, and use its mp_log.
There is uninitialized memory access if the actual size isn't passed
along. In the worst case, this can cause a source to be loaded against
the uninitialized memory, causing a false count of found versus required
sources, preventing the "Failed to find ordered chapter part" message.
This is pretty much a hack for the OSC. It will allow it to rely on a
somewhat predictable style, instead of having to overwrite all user
OSD settings manually with override tags.
Nothing really accesses it. Subtitle initialization actually does in a
somewhat meaningful way, but there container size is probably fine, as
subtitles were always initialized before the first video frame was
decoded.
Now writing -1 to the 'aspect' property resets the video to the auto
aspect ratio. Returning the aspect from the property becomes a bit more
complicated, because we still try to return the container aspect ratio
if no frame has been decoded yet.
This function would probably be useful in other places too.
I'm not sure why vd.c doesn't apply the aspect if it changes size by
less than 4 pixels. Maybe it's supposed to avoid ugly results with bad
scalers if the difference is too small to be noticed normally.
This is preliminary. There are still tons of issues, and any aspect
of scripting may change in the future. I decided to merge this
(preliminary) work now because it makes it easier to develop it, not
because it's done. lua.rst is clear enough about it (plus some
sarcasm).
This requires linking to Lua. Lua has no official pkg-config file, but
there are distribution specific .pc files, all with different names.
Adding a non-pkg-config based configure test was considered, but we'd
rather not.
One major complication is that libquvi links against Lua too, and if
the Lua version is different from mpv's, you will get a crash as soon
as libquvi uses Lua. (libquvi by design always runs when a file is
opened.) I would consider this the problem of distros and whoever
builds mpv, but to make things easier for users, we add a terrible
runtime test to the configure script, which probes whether libquvi
will crash. This is disabled when cross-compiling, but in that case
we hope the user knows what he is doing.
This time it broke because I didn't actually test compiling vo_vaapi.c,
and it was using a macro from mp_image.h, which implicitly assumed
FFALIGN was available. Screw that too, and copy the definition of
ffmpeg's FFALIGN to MP_ALIGN_UP, and move these macros to mp_comnon.h.
The code using FFSWAP was moved from vo_vaapi.c to vaapi.c, which didn't
include libavutil/common.h anymore, just libavutil/avutil.h. The header
avutil.h doesn't include common.h recursively in Libav, so it broke
there.
Add FFSWAP as MPSWAP in mp_common.h (copy pasted from ffmpeg) to make
sure this doesn't happen again. (This kind of stuff happens all too
often, so screw libavutil.)
This code is actually quite inefficient: it reuses the (slow, simple)
screenshot code. It uses an inefficient method to read the image
(vaGetImage() instead of vaDeriveImage()), allocates new memory for
each frame that is read, and it tries all image formats again each
time.
Also, in my tests it always picked NV12 as image format, which is not
ideal if you actually want to filter the video, and vo_xv can't handle
this format without conversion either.
However, a user confirmed that it worked for him, so everything is fine.
This will allow GPU read-back with process_image.
We have to restructure how init_vo() works. Instead of initializing the
VO before process_image is called, rename init_vo() to
update_image_params(), and let it update the params only. Then we really
initialize the VO after process_image.
As a consequence of these changes, already decoded hw frames are
correctly unreferenced if creation of the filter chain fails. This
could trigger assertions on VO uninitialization, because it's not
allowed to reference hw frames past VO lifetime.
Merged from pull request #246 by xylosper. Minor cosmetic changes, some
adjustments (compatibility with older libva versions), and manpage
additions by wm4.
Signed-off-by: wm4 <wm4@nowhere>
This code was made inactive some months ago. At this time it wasn't
entirely clear whether this code was still needed, but now I'm pretty
sure it isn't. Even if it is, it didn't work anymore.
This wasn't enough and could lead to a cut off message shown on OSD.
Just make it dynamic, since we already use dynamic memory allocation
at this point anyway.
Moving the window was convenient but generates a MOUSE_LEAVE event
which it shouldn't. Now we remove it, because it is still possible
to move the window in weston with MOD+BTN0.
The problem with DVD/BD and playback resume is that most often, the
filename is just "dvd://", while the actual path to the DVD disk image
is given with --dvd-device. But playback resume works on the filename
only.
Add a pretty bad hack that includes the path to the disk image if the
filename starts with dvd://, and the same for BD respectively. (It's a
bad hack, but I want to go to bed, so here we go. I might revert or
improve it later, depending on user feedback.)
We have to cleanup the global variable mess around the dvd_device.
Ideally, this should go into MPOpts, but it isn't yet. Make the code
paths in mplayer.c take MPOpts anyway.
By default, libavformat uses UDP for rtsp playback. This doesn't work
very well. Apparently the reason is that the buffer sizes libavformat
chooses for UDP are way too small, and switching to TCP gets rid of this
issue entirely (thanks go to Reimar Döffinger for figuring this out).
In theory, you can set buffer sizes as libavformat options, but that
doesn't seem to help.
Add an option to select the rtsp transport, and make TCP the default.
Also remove an outdated comment from stream.c.
Mainly for debugging. Usually, we just set options for all possible
protocols, and we can't really know whether a certain protocol is used
beforehand. That's also the reason why avio_open2() takes a dictionary,
instead of letting the user set options directly with av_opt_set(). Or
in other words, we don't know whether an option that could be set is an
error or not, thus we print the messages only at verbose level.
This is for properties that normally show a bar, and thus do not show an
OSD message (as per classic mplayer behavior). Setting an extra_msg
allows showing an OSD message anyway, except if OSD messages are
explicitly suppressed.
This refactors the whole show_property_osd() function a bit, and
replaces the weird sep field with a more general method.
Allows for example: --status-msg='${?pause==yes:(Paused) } ...' to
emulate the normal terminal status line. It's useful in other situations
too.
I'm a bit worried about extending this mini-DSL, and sure hope nobody
will implement a generic formula evaluator at some point in the future.
But for now we're probably safe.
In most cases, it's better if deinterlacing happens before any other
filtering, so prepend the filter to the user's filter list, instead
of appending it.
Instead of hardcoding a single filter. This might be helpful for
modeling the vaapi deinterlacer as a video filter. The idea is that a
software deinterlacer would be tried first, and if that fails (because
vaapi hardware decoding uses HW surfaces, which a software deinterlacer
does not accept), the vaapi filter would be tried.
Normally, we need this for Xutf8LookupString(). But we can just fall
back to XLookupString(). In fact, the code for this was already there,
the code was just never tested and was actually crashing when active
(see commit 2115c4a).
Calling them separately doesn't really make sense, and all existing
calls to them usually combined them. One subtitle difference was that
af_init() didn't wipe the filter chain if initialization of the chain
itself failed, but that didn't really make sense anyway.
Also remove af_init() from the code for setting balance in mixer.c. The
mixer should be in the initialized state only if audio is fully
initialized, so the af_init() call made no sense.
Note that the filter "editing" code in command.c doesn't really do a
nice job of handling errors in case recreating an _old_ (known to work)
filter chain unexpectedly fails, and this obscure/rare case might be
differently handled after this change.
The volume is set as soon as the audio chain is created again. This
works only in softvol mode. For system wide volume or otherwise
externally user controllable volume, this code is intentionally
disabled. It would be extremely weird if changing volume (while audio is
not initialized) would do nothing, and then suddenly change it when the
audio chain is created.
There's another odd corner case: the user-set volume will be thrown away
if it's set before the _first_ audio chain initialization. This is
because the volume restore logic recognizes a change from nothing to
softvol or an AO, and circumventing that would require additional code.
Also, we don't even know the start volume before that point.
Forcing the volume with --volume will can override the volume set during
no-audio mode, depending on the situation.
Note that this is intentionally never done if the AO or softvolume is
different, or if the current volume control method is thought to control
system wide volume (such as ALSA) or otherwise user controllable (such
as PulseAudio). The intention is to keep things robust and to avoid
messing with the user's audio settings as far as possible, while still
providing the ability to resume volume if it makes sense.
Commit broke text subtitles without embedded fonts. Will look for a better
solution later. Revert it for now, since I'm starting to get bug reports.
This reverts commit 4a9f618d9f.
XOpenIM can fail to find a valid input method, in which case it
returns NULL. Passing a NULL pointer to XCreateIC would cause a
crash, so fail VO init before that happens.
Before this commit there was just an error message, but the file descriptor was
still open. Now we close the file descriptor and prevent it from calling
endlessly. Also a CLOSE_WIN event is sent which closes the window eventually if
the action of CLOSE_WIN is set to quit or quit_watch_later.
Improves display of images and video with alpha channel, especially if
the transparent regions contain (supposed to be invisible) garbage
color values.
Refactor how mixer.c does volume/mute restoration and initialization.
Move to handling of --volume and --mute to mixer.c. Simplify the
implementation of these and hopefully fix bugs/strange behavior related
to using them as file-local options (this uses a somewhat dirty trick:
the option values are reverted to "auto" after initialization). Put most
code related to initialization and volume restoring in probe_softvol()
and restore_volume(). Having this code all in one place is less
confusing.
Instead of trying to detect whether to use softvol at runtime, detect it
at initialization time using AOCONTROL_GET_VOLUME (same with mute,
AOCONTROL_GET_MUTE). This implies we expect SET_VOLUME/SET_MUTE to work
if the GET variants work. Hopefully this is always the case.
This is also preparation for being able to change volume/mute settings
if audio is disabled, and for allowing restoring value with playback
resume.
Softvol always used a linear multiplier for volume control. This was
converted to dB, and then back to linear in af_volume. Remove this non-
sense. We still try to keep the command line argument to af_volume in
dB, though.
This is to avoid the 30s hang while mpv caches fonts. In practice all the
fonts an average user is going to use are embedded in mkv files so there is
no reason to build fontconfig's cache on all of OS X system directories.
I might add something similar for terminal usage, but I am highly undecided.
It's quite unlikely, but functions like mp_find_user_config_file() can
return NULL, e.g. if $HOME is unset.
Fix all the code that didn't check for this correctly yet.
Remove the ifdef hell from mp_find_user_config_file(). Move the win32
specific code (for MinGW and Cygwin) to path-win.c. The behavior should
be about the same, but I can't be sure due to lack of testing and
because the old path.c code was hard to follow. (I expect those who care
about windows will fix things, should issues pop up - sorry.)
One difference is that the new code will always force MPV_HOME. It looks
like the old code preferred the mpv config dir in the exe dir if it
exists.
Also, make sure MP_PATH_MAX has enough space, even if the equivalent
wchar_t string is not 0-terminated with PATH_MAX (because apparently the
winapi doesn't require this). (Actually, maybe we should just kill all
uses of PATH_MAX/MP_PATH_MAX.)
This is a bit "hard", because getenv() returns a static string, and we
can't just return an allocated string. We also want getenv() to be
thread-safe if possible. (If the mpv core is going to be more threaded,
we sure do want the lower layers to be thread-safe as well.)
The homepath variable was static, and its value was set to a stack
buffer. This means a second invocation of the function would trigger
undefined behavior. Moreover the stack buffer always went out of scope
before homepath was used.
This is mainly to avoid spurious cursor states due to the mouse moving inside
or outside the window as a result of the window resize (with cmd-0/1/2).
This avoids complex logic and triggers a mouse move so that the player
recomputes the correct cursor state based on the autohide configuration of
the user.
This keeps the state in sync with the current state in cocoa_common. Infact the
cocoa code in mpv can decide wether it really wants to hide the cursor based on
the result of the `canHideCursor` method (this is so that the cursor is only
hidden when hovering on the video window).
Turns out that these checks were for versions of OS X that mpv doesn't even
support anymore. So just remove the checks since they cause a deprecation
warning.
GetCurrentProcess() is deprecated on 10.9. Make a universal solution by
checking OS version number.
get_system_version() function is the recommended Apple way of getting the
OS version, since Gestalt is also deprecated (and does pretty much the same
thing anyway)
Updating HIDRemote.m to use a similar function would allow to get rid of the
2 other warnings.
This is supposed to reduce the amount of useless error messages shown
during initialization of vo_opengl. If multiple backends are compiled,
usually only one of them will work. For example, on Linux both X and
Wayland backends can be compiled, but usually either Wayland or X is
running. Then, if Wayland is not running, but X is, trying to initialize
the Wayland backend should not spam the terminal with error messages.
Signed-off-by: Andreas Sinz <andreas.sinz@aon.at>
Call update_subtitles() on every iteration of the playloop, so that
subtitle packets are read as soon as possible, instead of every time a
video frame is displayed. This helps in case the packet queue is swamped
with subtitle packets, which can happen with certain insane mkv files.
The change will simply cause the subtitle queue to be emptied on each
playloop iteration.
The timestamps update_subtitles() uses for display are the same before
and after this commit. (Important for files which have subtitle packets
with timestamps or duration not set.)
In insane files with a very huge number of subtitle events, and if the
--demuxer-mkv-subtitle-preroll option is given, seeking can still
overflow the packet queue. Normally, the subtitle_preroll variable
specifies the maximum number of packets that can be added. But once this
number is reached, the normal seeking behavior is enabled, which will
add all subtitle packets with the right timestamps to the packet queue.
At this point the next video keyframe can still be quite far away, with
enough subtitle packets on the way to overflow the packet queue.
Fix this by always setting an upper limit of subtitle packets read
during seeking. This should provide additional robustness even if the
preroll option is not used.
This means that even with normal seeking, at most 500 subtitle packets
are demuxed. Packets after that are discarded.
One slightly questionable aspect of this commit is that subtitle_preroll
is never reset in audio-only mode, but that is probably ok.
The mpv.desktop file is taken from the Arch package [1]. It appears to
be based on the mplayer2 git mplayer.desktop file (e.g. very similar
MimeType field), with minor modifications applied by Arch package
maintainers.
Note that for now, this doesn't show a terminal (Terminal=false), which
might not always be ideal. For example, if the file is audio only, or
if VO initialization fails for some reason, mpv will run in the
background and play audio without showing a window. But users prefer
running it without terminal, and don't want to play audio files with
it.
Maybe a --force-window option will be added in the future, which would
always create a VO window, and compensate for these issues.
[1] https://aur.archlinux.org/packages/mpv-git/
These would have to be updated manually all the time. Replacing them
automatically would be possible, but additional work, and would force
regeneration of the manpage way too often.
We decided that we don't need these fields.
Instead of containing a format string within %w{...}, simply allow %w
to specify one item of a time format string. This is simpler, more like
other format specifiers (%t), and probably easier to use too.
This is for situations when repeated attempts at playing a playlist
entry failed, and playlist navigation becomes impossible due to that.
For example, it wasn't possible to skip backwards past an unplayable
playlist entry:
mpv file1.mkv doesntexist.mkv file3.mkv
You couldn't skip back to file1.mkv from file3.mkv. When running a
single "playlist_prev" command, doesntexist.mkv would be played, which
would fail to load. As reaction to the failure to load it, the next file
would be played, which is file3.mkv.
To make this even worse, the file could successfully load, but run only
for a split second. So just loading successfully isn't good enough.
Attempt to solve this by marking problematic playlist entries as failed,
and by having playlist_prev skip past such playlist entries. We define
failure as not being able to play more than 3 seconds (or failing to
initialize to begin with). (The 3 seconds are in real time, not file
duration.)
"playlist_prev force" still exhibits the old behavior.
Additionally, use the same mechanism to prevent pointless infinite
reloading if none of the files on the playlist exist. (See github issue
All in all, this is a heuristic, and later adjustments might be
necessary.
Note: forward skips (playlist_next) are not affected at all. (Except for
the interaction with --loop.)
This is commonly used to disable the screensaver with broken/non-
standard X screensavers. During pause, the screensaver should not be
disabled, so not calling this command while paused seems sensible.
See github issue #236.
They are rarely useful in my opinion.
This commit was mainly motivated by this message:
Video uses a non-standard and wasteful way to store B-frames ('packed B-frames'). Consider using a tool like VirtualDub or avidemux to fix it.
It's what's left over from the "Invalid and inefficient vfw-avi..."
warning that used to be printed when playing avi/divx files. Although
the new message is much better, it's still rather useless and poses
more questions than it answers. Besides, nobody wants to remux a file
when playing it, especially not if playback appears to be completely
fine. (There are some claims that these files raise CPU usage, but even
my old crappy CPU can decode low res avi/divx files at real time at
about x35 playback speed.)
I have a sample where some final chapters are missing. This was causing a
segmentation fault when trying to fetch chapter times for them.
This makes the code ignore those chapters.
The quicktime html scripting guide suggests to wrap urls not
necesarly associated with quicktime in a .mov file.
(so that when <embed>ing videos quicktime would be forced.)
These mov files may contain several "Text Hacks".
One of these is RTSPtext.
The suggested/allowed format (as regex) is like:
RTSPtext[ \r]RTSP://url
See also p.51 of:
https://developer.apple.com/library/mac/documentation/QuickTime/Conceptual/QTScripting_HTML/QTScripting_HTML.pdf
In reality there are also files like (e.g. zdfmediathek.de):
RTSPtext\nrtsp://url\n\n
Lets handle these files as a playlist with one element.
In init_vo(), if sh->aspect is 0 or last_sample_aspect_ratio is set,
sh->aspect is overwritten. With software decoding fallback behaviour,
this makes the aspect ratio from container ignored since
last_sample_aspect_ratio is already set in first try with hardware
decoding.
The --deinterlace option does on playback start what the "deinterlace"
property normally does at runtime. You could do this before by using the
--vf option or by messing with the vo_vdpau default options, but this
new option is supposed to be a "foolproof" way.
The main motivation for adding this is so that the deinterlace property
can be restored when using the video resume functionality
(quit_watch_later command).
Implementation-wise, this is a bit messy. The video chain is rebuilt in
mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the
usual mechanism for enabling deinterlacing can't be used. Further,
mpcodecs_reconfig_vo() is called by the video decoder, which doesn't
have access to MPContext either. Moving this call to mplayer.c isn't
currently possible either (see below). So we just do this before frames
are filtered, which potentially means setting the deinterlacing every
frame. Fortunately, setting deinterlacing is stable and idempotent, so
this is hopefully not a problem. We also add a counter that is
incremented on each reconfig to reduce the amount of additional work per
frame to nearly zero.
The reason we can't move mpcodecs_reconfig_vo() to mplayer.c is because
of hardware decoding: we need to check whether the video chain works
before we decide that we can use hardware decoding. Changing it so that
this can be decided in advance without building a filter chain sounds
like a good idea and should be done, but we aren't there yet.
I did commit 86c05655d by thinking `mpv` already removed the `mpv` from
argc/argv. It actually is still there, so the argc must be 1 to check for no
arguments.
Thanks to @Nyx0uf for pointing out the bug and for testing on 10.9!
File opening through Finder, apparently drops `--psn` arguments on Mavericks
and just uses no args. Modify the code to account for that case.
This wasn't tested on 10.9 itself (I don't have a paid dev account), but it
*should* work if I understood the problem correctly.
Problem: I own the buffer and I destroyed while still being displayed.
Solution: Add a temporary buffer and destroy it when the next buffer is
attached.
Previously, mpv incorrectly used the %HOME% environment variable on
MinGW to determine the current user’s home directory. This is wrong;
the correct variable to use would be %HOMEPATH%, which would however
still be wrong since application data goes into the application data
directory, not the user’s home. This patch makes it use the local
AppData path instead of reading an environment variable.
This however exposed another problem (which also affected users who
actually had the %HOME% variable set):
b2c2fe7a37 (discussed in issue #95) introduced some changes that
make mpv load user config files from the executable path on Windows.
The problem with this change is that config_dir was still declared
static, so once a config file had been found in the executable path,
it would set config_dir to an empty string, so mpv would dump e.g.
watch_later data straight into the user’s home. This commit also
fixes that.
One side effect of this is that mpv no longer considers the “mpv”
subdirectory in the executable path (that behavior resulted from
the homedir variable always being empty), unless it is somehow
unable to determine the local AppData path.
This is mostly related to the fullscreen behaviour. cecbd8864 introduces an
option to make mpv behave like a OSX user would expect. This commit changes
the Cocoa parts of the code to be consistent with the behaviour on X11. Old
behaviour is still available through the option mentioned in cecbd8864.
There is still custom logic in the cocoa backend and it can probably be moved
to core:
* Don't perform autohide if the mouse is down
* Don't perform autohide outside of the video window
Fixes#218 (by accident)
libquvi 0.4 doesn't allow us listing the formats supported by a
streaming site without doing additional network accesses, so switching
formats was not supported with it. (It's different with libquvi 0.9.)
But the most important case is switching between SD and HD. Usually,
--quvi-format=default will get SD, while --quvi-format=best gives HD.
Use this, and pretend that an URL supported by libquvi 0.4 supports both
of these. "cycle quvi-format" will switch between these. If the user
specifies something else via --quvi-format, this is included in the list
of switchable formats additionally to "default" and "best".
It's annoying for users if you can't get a list of options with --help,
but on the other hand, printing all options would be overkill. So just
mentioned --list-options.
Retrieve per-chapter metadata, but don't do much with it. We just make
the metadata of the _current_ chapter available as chapter-metadata
property. Returning the full chapter list with metadata would be no
problem, except that the property interface isn't really good with
structured data, so it's not available for now.
Not sure if it's worth it, but it was requested via github issue #201.
Consider the cluster used for prerolling contains an insane amount of
subtitle packets. Then the demuxer packet queue would be full of
subtitle packets, and demux.c would refuse to read any further packets -
including video and audio packets, resulting in EOF. Since everything
involving Matroska and subtitles is 100% insane, this can actually
happen.
Fix this by putting a limit on the number of subtitle packets read by
preroll, and throw away any further packets if the limit is exceeded. If
this happens, the preroll mechanism will stop working, but the player's
operation is unaffected otherwise.
Cherry picked from various commits in lua_experiment by ChrisK2.
The metrics of the OSD symbols change slightly, possibly due to the
font editor that was used, and the metrics were not correct to begin
with. (But the real reason seems unknown.) Remove the rescaling of
the OSD font in ASS_USE_OSD_FONT, because the height more or less fits
now. (This change wasn't in the lua_experiment branch.)
run_playloop() is already stuffed enough. This function is still quite
big, but all the other code shares various variables, so it's not as
easy to split.
This option makes the cursor always visible in windowed mode.
Apparently, this is what (some?) Windows and OSX users expect. It's
disabled by default for now.
Restructure the cursor hide logic a bit for this purpose.
Let all key events go through mp_input_feed_key() internally, and also
do double click and MP_INPUT_RELEASE_ALL handling there. Move
check_autorepeat() to where it's actually used.
This caused the OSC to be always visible at startup on X11:
- EnterNotify event send a mouse event to input.c
- OSC has not completely initialized yet, and no mouse area is set
- mouse event is dispatched to "showhide" OSC section
- OSC becomes visible, regardless of mouse position
Fix this by treating the mouse area as empty if it's not set, instead of
infinite as it was before this commit. This means an input section must
set a mouse area to receive mouse events at all. We also have to change
the default section to receive mouse events with the new behavior.
Also, if MOUSE_MOVE is unmapped (or mapped to something that doesn't
parse), and produces no command, the mouse position wouldn't be updated
(because the mouse position is bound to input commands), so we have to
generate a dummy command in this case.
(This matters only for the OSC, On Screen Controller, which isn't merged
yet, so these changes shouldn't have much effect right now.)
Until now, any command was dropped as soon as the input queue was full,
and the command was not an abort command (i.e. a command that exits the
player or goes to the next file).
This could cause issues with key down events (especially mouse buttons)
not being released.
Change it so that key up events can never be dropped. This is a bit
involved, because we know whether a key maps to an abort command only
after interpreting it, and interpreting it changes global state, which
in turn requires undoing the event if the input is dropped. Refactor
the code a bit to move more functionality into interpret_key() to make
this easier.
Remove options which are too obscure and most likely not very useful in
general, or update them to something more modern. Add some comments
about how configuration files work in general.
Even if a subtitle was explicitly loaded with -sub, it was still auto-
loaded (if auto-loading applied to that file). Fix this by explicitly
checking whether a file is already loaded.
The check is maximal naive and just compares the filenames as strings.
The change in find_subfiles.c is so that "-sub something.ass" happens to
work (auto-loading prepended a "./" to it, so the naive filename
comparison check didn't work).
External vobsubs usually come as .idx/.sub pairs. Loading the .idx file
implicitly loads the .sub file, whereas loading the .sub file will kind
of work, but miss important information such as subtitle resolution. Or
in other words, if the .idx file exists, adding the .sub file as track
is useless and confusing.
Explicitly remove .sub file from the auto-load suntitle list in these
cases. Standalone .sub files are still loaded.
We also drop that weird logic that excluded .utf8 files from being
loaded if -subcp was in use. I hope the associated use case didn't make
much sense to begin with. If not, we could still implement it properly,
instead of this weird hack.
Use mp_path_exists() to check for existence of a file (which in turn
uses stat()), instead of opening and closing it. The difference is that
if we don't have sufficient permissions to read the subtitle files, we
will loudly complain. Personally, I prefer this behavior.
Until now, options could be accessed as properties via "options/name",
but the access was read-only. Change it so that write access is possible
in --idle mode. (All options have to support setting options at that
time, simply because of the way MPlayer designed per-file options.
During playback, normal properties take care of changing things,
including things backed by options.)
This is work in progress. There are some issues: at least setting the
"vf" and "af" options won't work for strange reasons.
Pretty useful for people writing userscripts for web browsers. Links starting
with 'mpv://' are forwarded to the mpv OSX bundle. The leading 'mpv://' is
stripped from the recived url and the rest of the string is inserted as is in
the playlist.
The --volume option accepted values up to 10000, but internally, the
value is always clipped to 0-100 range. What makes this even worse is
that --softvol-max suggests that it extends the range of --volume, which
is not the case. (And passing a volume larger than 100 to --volume
didn't even print a warning.)
The really funny thing about this commit is that this code is added on
top of another work around. Basically, subtitle seeking in libavformat
is completely broken. To make it useful, we have to add yet another
workaround.
The basic problem is that libavformat's subtitle seeking code always
uses the stream time base, instead of AV_TIME_BASE if stream index -1 is
passed to the avformat_seek_file() function.
Fixes github issue #216. Hopefully this will be fixed in ffmpeg too at
some point.
This affects MOUSE_MOVE and MOUSE_LEAVE. Both are needed internally
(such as for the OSC), but not really useful for input.conf. Since the
warning has the purpose of notifying the user that a key is unmapped and
what key name to use for setting up a binding in input.conf, the warning
is rather useless in this case. It's also annoying in combination with
the
--no-input-default-bindings option, since that removes the default
bindings to "ignore" for these keys.
When enabling --save-position-on-quit, playback position stored not only
on quit, but in any case playback of a file was stopped. This includes
going to the next file with playlist navigation commands.
After some discussion on IRC, it turned out that nobody thought this was
good behavior. Disable it, and really make it save only on quit.
Maybe the option is useless now, as the user could remap the CLOSE_WIN
key binding. On the other hand, CLOSE_WIN sounds and _is_ a bit obscure.
Before this commit, the player didn't write resume info if the playback
position was within the first or last percent of the file.
This was sometimes annoying, and with playlist resume can lead to
unintuitive behavior. (It wouldn't resume the playlist if the currently
played file was at 0-1% or 99-100%, even if you were in the middle of a
playlist.)
Moreover, the "percent > 99" check is a bit bogus anyway, because 100
(in integer) is rarely reached.
Drop the check, and make sure using --save-position-on-quit won't write
resume info when reaching EOF. The latter check is needed to make sure
playback of the file starts at beginning when playing it again after
EOF.
The previous check just searched for a "://" substring. This was quite
bad, because "://" can be a valid part of a path. Later, I added
special handling for filenames starting with "." and "/", so that you
could reliably pass arbitrary filenames to mpv, no matter how messed
up they were.
Even though it doesn't really matter in practise anymore, this is still
crap, so add a more reliable check instead.
This includes the case of passing multiple files to command line
(internally this is the same as loading a playlist).
Resuming works by finding the first playlist entry that can be resumed.
Alternative implementations would be possible, such as hashing the
playlist contents. But this implementation is simpler, and doesn't have
the disadvantage that changes to the playlist (like appending entries)
will throw away the resume point.
This makes loading large playlists a bit slower, because it has to look
into ~/.mpv/watch_later/ for every entry. Loading a 15000 entries
playlist now increases from 150ms to 400ms. Considering you rarely load
playlists this big with mpv (because it's impractical considering the
terminal and non-GUI nature of the player), this is probably ok.
Undo URL percent encoding if the filename appears to be an URL. This
will fix display of the actual filename in some cases.
We don't put any effort into checking whether the URL is really percent
encoded, because we don't really know how the protocol handler is going
to interpret the URL. For stream_lavf, we probably can't know. Still,
from the perspective of this commit, it seems to make sense to assume
they are percent encoded.
icon_size is the number of array items of type long, not bytes. Change
the type of icon_size to int, because size_t makes you think of byte
quantities too quickly.
As an unrelated change, change the (char *) cast to (unsigned char *),
because it matches the common XChangeProperty idiom better.
MPlayer handles this correctly, because MPlayer still has the FourCC
codec dispatch (codecs.conf). We need to handle this case specially,
because the libavformat rawvideo decoder will of course not eat mjpeg.
mjpeg is the only supported format, though. (Even MPlayer needs to
convert between V4L2 formats and MPlayer FourCCs, and mjpeg is the only
non-raw format.)
The option list contains an empty string member with this option value,
so ignore that. I'm not sure whether the option list should maybe be
empty in this case, but it could be the wrong thing in case of other
options.
This happens by default with pausing: if a file was paused when doing
quit_watch_later, then resume and unpause, then the file played after
that would start in paused mode. This is because the pause option is
backed up at thr wrong place, so it backs up the state from resuming,
instead of whatever it was set to before that.
This prevents keys to become stuck due to changing keyboard modifiers during
the key down. Not the prettiest approach but event `x11_common` does it like
this.
Fixes#210
The png file added to etc/ are taken from the link mentioned in commit
303096b, except that they have been converted to 16 bit, sRGB (with
color profile info dropped, if there was one), and transparent pixels
reset for better compression.
The file x11_icon.bin is generated by gen-x11-icon.sh. I'm adding it to
the git repo directly, because the script requires ImageMagick, and we
don't want to make building even more complicated.
The way how this is done is basically a compromise between effort
required in x11_common.c and in gen-x11-icon.sh. Ideally, x11_icon.bin
would be directly in the format as required by _NET_WM_ICON, but trying
to write the binary width/height values from shell would probably be a
nightmare, so here we go.
The zlib code in x11_common.c is lifted from demux_mkv.c, with some
modifications (like accepting a gzip header, because I don't know how to
make gzip write raw compressed data).
This allows other threads to use mp_input_put_key without blocking if the
playloop is doing the 500ms select call (i.e.: during pause).
Makes Cocoa GUI responsive again (regression since 2d363c3).
If the input section is enabled with MP_INPUT_ALLOW_VO_DRAGGING, then
the VO will be allowed to drag the window with mouse button down +
mouse move even if the mouse is inside the section's mouse area.
If the mpv window is unfocus, clicking on the OSC should focus the
window (done by the window manager) and allow interaction with the OSC.
But somehow X sends a spurious LeaveNotify event, immediately followed
by an EnterNotify event. This happens at least with IceWM. The result is
that the OSC will disappear (due to receiving MOUSE_LEAVE). The OSC will
stay invisible, because EnterNotify isn't handled, and there's nothing
that could make the OSC appear again.
Solve this by handling EnterNotify. We cause a redundant MOUSE_MOVE
event to be sent, which triggers the code to make the OSC visible. We
have to remove the code from input.c, which ignores redundant mouse move
events.
Since the code ignoring redundant mouse move events is still needed on
Windows, move that code to w32_common.c. The need for this is documented
in the code, also see commit 03fd2fe. (The original idea was to save
some code by having this code in the core, but now it turns out that
this didn't quite work out.)
Normally, moving the mouse outside of the mouse area of an input section
will send mouse events somewhere else (because input section mouse areas
are similar to windows/widgets in real GUI toolkits). This was done even
if a mouse button was held down. This is quite different from how GUI
toolkits behave.
Change the code so that if a mouse button is down, the mouse area of the
current input section can't be left. Releasing the mouse button (while
the mouse pointer is outside of the mouse area) will actually leave the
mouse area.
As a side-effect, this commit also tests more often whether the current
mouse input section is valid. This is needed to make releasing a mouse
button trigger the mouse input section change.
These keys can be found on various "multimedia" and "internet" keyboard.
X defines many keycodes, so I'm not adding all, just what I found on my
own keyboard.
Other key codes can be added on request.
This is basically a libavcodec API oddity: it can happen that
avcodec_decode_audio4() returns 0 (meaning 0 bytes were consumed). It
requires you to feed the complete packet again to decode the full
packet, and to successfully decode the following packets.
We ignored this case with the argument that there's the danger of an
endless decode loop (because nothing of that packet is apparently
decoded, so it would retry forever), but change it in order to decode
mpc8 files correctly.
Also add some comments to explain the mess.
I suspect most users will just copy etc/input.conf when they want to
remap some default bindings. But usually this means the user even copies
bindings he doesn't care about, and it's better if the user maps only
the bindings in his input.conf the user intends to remap.
Comment all bindings in etc/input.conf. Since this file also defines the
builtin defaults and is baked into the mpv binary, we have to do
something to get them anyway, even though they are commented. Do this by
having input.c "uncomment" the bindings in the baked in input.conf. (Of
course this is done only for the builtin config, not configs loaded from
disk.)
The previous code was locking only the input queue. That was too weak since it
didn't protect the input_ctx data structure. So remove the locking on the queue
and lock all the public functions that interact with the input_ctx.
The private functions and public functions that do not act on the input_ctx
(there are quite some functions doing mp_cmd manipulations for instance) are
not locked.
Some changes by wm4. Use a recursive mutex, and restructure some code to be
less annoying with locks, such as converting code to single return, or
making use of the recursive mutex.
Generate a mouse down event on the first click so that one can interact
with the OSC directly as opposed to wasting the first click in order to focus
the window.
I would like to thank Chris Ward (@tenzerothree, http://tenzerothree.com/) for
working on the art for these icons and bringing some eye candy to the project.
The PSDs made by Chris are available on our Dropbox [1], along with the exports
I made to create OSX and Windows icons. The PSDs are almost completly vector
and all the resolutions look really similar, except the 16px favicon which was
handcrafted to look better and more recognizeable on the smaller pixel budget.
For Mac OS X the icons were created using iconutils on the PNGs iconsets
exported from the PSDs. These even support retina resolutions (except 512@2x).
For Windows the .ico file was created with imagemagick. The included images
are 16px, 24px, 32px, 48px 64px, 256px. These are the resolutions listed on
MSDN for supporting Windows XP [2] and Windows versions based on Aero [3].
Only 32bit PNGs were used since it is 2013.
For Linux nothing changed yet, even though @wm4 talked about using the PNGs
directly there. This will probably be dealt with in a later commit.
[1]: https://www.dropbox.com/sh/yelfoj9tbft7o06/A8vOT6JKaG
[2]: http://msdn.microsoft.com/en-us/library/ms997636.aspx
[3]: http://msdn.microsoft.com/en-us/library/aa511280.aspx
This probably has been broken since bbc865a: a test was added that uses
a FBO, but it's always run, even if FBOs were not detected. On the other
hand, fbotex_init() just runs into an assert. Fix the test that
triggered this condition, and make fbotex_init() "nicer" by just failing
if FBOs are not available.
Port it from playlist_parser.c to demux_playlist.c. Also, change the m3u
parser to drop whitespace from the trailing part of the line (will make
it work properly with windows line endings).
(I hoped that this would make MMS URIs with http instead of mmsh
prefixes work, but it doesn't. Instead, it leads to a playlist loop. So
solving this issue would require a change in ffmpeg, probably.)
Until now, stream_peek() read only the bare minimum it had to read from
the stream. But this could cause problems, such as being very
inefficient when peeking a lot, or conflicting with ability to seek
back. (The latter issue can be caused by peeking a few bytes, and then
doing a stream_read() with a size that is 1 byte longer: this would read
the peeked data, then call stream_fill_buffer(), which throws away the
previously peeked bytes - so you can't seek back anymore. This is
mitigated by a hack in demux_open(): it peeks a full buffer, to avoid
that peeking/reading during demuxer probing [or before that, in a stream
filter] can cause the buffer to be dropped.)
The original condition was too weak, requiring only the header. The header is
installed is FFmpeg regardless of the presence of VDA on the system, so just
perform a check on the `ff_vda_create_decoder` function.
Make use of opaque regions on non-alpha formats. This allows the compositor to
improve the drawing of the surface, because he can discard everything behind
the window when drawing.
Odd video sizes if pixel formats with chroma subsampling and PBOs were
used, garbage was rendered. This was because the PBO path created
buffers with an unpadded size, and then tried to upload a padded
image to it. Fix it by explicitly setting the padded size. (As with
the non-PBO path, we rely that image allocations are somehow padded,
which is normally the case.)
Apparently, it is popular to store large files in uncompressed rar
archives. Extracting files is not practical, and some media players
suport playing directly from uncompressed rar (at least VLC and some
DirectShow components).
Storing or accessing files this way is completely idiotic, but it is
a common practice, and the ones subjected to this practice can't do
much to change this (at least that's what I assume/hope). Also, it's
a feature request, so we say yes.
This code is mostly taken from VLC (commit f6e7240 from their git tree).
We also copy the way this is done: opening a rar file by itself yields
a playlist, which contains URLs to the actual entries in the rar file.
Compressed entries are simply skipped.
Add a stream filter concept, in which streams can be opened on top of
an underlying "source" stream. Change the open code to make this
easier, and also to account for some mechanisms that will be needed
for this.
The following commit will add stream_rar, which contains such a stream
filter.
This is really not needed. While we really can't take a loaded buffer
over to the cache, there's no reason why the cache couldn't read this
buffer normally.
On the other hand, this code could cause trouble when probing from a
stream before the cache has been enabled.
The way the url_options field was handled was not entirely sane: it's
actually a flexible array member, so it points to garbage for streams
which do not initialize this member (it just points to the data right
after the struct, which is garbage in theory and practice). This was
not actually a problem, since the field is only used if priv_size is
set (due to how this stuff is used). But it doesn't allow setting
priv_size only, which might be useful in some cases.
Also, make the protocols array not a fixed size array. Most stream
implementations have only 1 protocol prefix, but stream_lavf.c has
over 10 (whitelists ffmpeg protocols). The high size of the fixed
size protocol array wastes space, and it is _still_ annoying to
add new prefixes to stream_lavf (have to bump the maximum length),
so make it arbitrary length.
The two changes (plus some more cosmetic changes) arte conflated into
one, because it was annoying going over all the stream implementations.
Modeled after the old playlist_parser.c, but actually new code, and it
works a bit differently.
Demuxers (and sometimes streams) are the component that should be used
to open files and to determine the file format. This was already done
for subtitles, but playlists still use a separate code path.
af_str2fmt_short(), which is used by the command line option parser,
allowed passing a hex number. The user could set arbitrary integers as
internal audio formats, even formats which don't exist or make no sense.
This is not very useful, so get rid of it.
Having to use -1 for that is generally quite annoying.
Audio formats are created from bitmasks, and it can't be excluded that
0 is not a valid format. Fix this by adjusting AF_FORMAT_I so that it
is never 0. Along with AF_FORMAT_F and the special formats, all valid
formats are covered and guaranteed to be non-0.
It's possible that this commit will cause some regressions, as the
check for invalid audio formats changes a bit.
A wayland output based on shared memory. This video output is useful for x11
free systems, because the current libGL in mesa provides GLX symbols. It is also
useful for embedded systems where the wayland backend for EGL is not
implemented like the raspberry pi.
At the moment only rgb formats are supported, because there is still no
compositor which supports planar formats like yuv420p. The most used compositor
at the moment, weston, supports only BGR0, BGRA and BGR16 (565).
The BGR16 format is the fastest to convert and render without any noticeable
differences to the BGR32 formats. For this reason the current (very basic)
auto-detection code will prefer the BGR16 format. Also the weston source code
indicates that the preferred format is BGR16 (RGB565).
There are 2 options:
* default-format (yes|no) Which uses the BGR32 format
* alpha (yes|no) For outputting images and videos with transparencies
The obtained information from the shm listener isn't used by anything and is
also wrong now in wayland git master branch because of new shm formats which
need a different way of saving the supported formats.
Moves a good chunk of the resizing code to wayland_common.c. This makes it
possible to share it with future video drivers.
It doesn't resizit it immediatly, it calcutlates the new position and size and
then shedules a resizing event. This removes the ugly callback and void pointer
from the wayland data structure.
Regression since 18b6c01d92. That commit changed the colorspace handling to
always reinit the video output. Since the CVPixelBuffers are lazily created,
VOCTRL_SET_YUV_COLORSPACE was always called when the CVPixelBufferRef was NULL.
Since CoreVideo functions do not complain when called on NULL, no one noticed
that CVBufferSetAttachment, which stored the color matrix meta data was called
on NULL.
Until now, video output levels (obscure feature, like using TV screens
that require RGB output in limited range, similar to YUY) still required
handling of VOCTRL_SET_YUV_COLORSPACE. Simplify this, and use the new
mp_image_params code. This gets rid of some code. VOCTRL_SET_YUV_COLORSPACE
is not needed at all anymore in VOs that use the reconfig callback. The
result of VOCTRL_GET_YUV_COLORSPACE is now used only used for the
colormatrix related properties (basically, for display on OSD). For
other VOs, VOCTRL_SET_YUV_COLORSPACE will be sent only once after config
instead of twice.
This affects VOs which just reuse the mp_image from draw_image() to
return screenshots. The aspect of these images is never different
from the aspect the screenshots should be, so there's no reason to
adjust the aspect in these cases.
Other VOs still need it in order to restore the original image
attributes.
This requires some changes to the video filter code to make sure that
the aspect in the passed mp_images is consistent.
The changes in mplayer.c and vd_lavc.c are (probably) not strictly
needed for this commit, but contribute to consistency.
mp_image_set_params() doesn't check whether the colorspace parameters
are consistent (e.g. setting YUV colorspaces with RGB formats), and
shouldn't need to.
The way this was added to FFmpeg is less than ideal, because it requires
text parsing in the Matroska demuxer. But in order to use the FFmpeg
webvtt-to-ass converter, we still have to mimic this in some way. We do
this by putting the parsing into sd_lavc_conv.c, before the subtitle
packet is passed to libavcodec. At least this keeps the ugliness out of
unrelated code.
There is some change that FFmpeg will fix their design eventually.
Instead of rewriting the parsing code, we simply borrow it from FFmpeg's
Matroska demuxer.
cocoa_common contains some locking calls to support video outputs that support
live resizing (at this moment only vo=opengl).
These should not be used unless the VO declares it is multithreaded by
registering the resize_redraw callback used for live resizing.
Fixes#200
Use the new MP_ macros for some AOs instead of mp_msg.
Not all AOs are converted, and some only partially. In some cases, some
additional cosmetic changes are made.
Otherwise, this would just try to demux a good chunk of the file, even
though the operation can't succeed anyway.
This caused some pretty strange issues, where perfectly valid use cases
would print a "Too many packets in the demuxer packet queue..." message.
The rawaudio demuxer read one frame per packet, basically a few bytes,
which caused insane overhead. (I found this when I couldn't play raw
audio without dropouts when using -v, which printed a line per packet
read.)
Fix this and read 1 second of audio per packet. This is a regression
since cfa5712 (merging of demux_rawaudio and demux_rawvideo).
Instead of always skipping in STREAM_BUFFER_SIZE blocks, allow an
arbitrary size. This allows - in theory - faster forward seeking in
pipes.
(Maybe not a very significant change, but it reduces the number of
things that depend on STREAM_BUFFER_SIZE for no good reason. Though
we still use that value as minimum read size.)
stream_file.c contains some code meant for forward seeking with pipes.
This simply reads data until the seek position is reached. Move this
code to stream.c. This stops stream_file from doing strange things
(messing with stream internals), and removes the code duplication too.
We also make stream_seek_long() use the new skip code. This is shorter
and much easier to follow than the old code, which basically did strange
things.
Decoding H264 using Video Decode Acceleration used the custom 'vda_h264_dec'
decoder in FFmpeg.
The Good: This new implementation has some advantages over the previous one:
- It works with Libav: vda_h264_dec never got into Libav since they prefer
client applications to use the hwaccel API.
- It is way more efficient: in my tests this implementation yields a
reduction of CPU usage of roughly ~50% compared to using `vda_h264_dec` and
~65-75% compared to h264 software decoding. This is mainly because
`vo_corevideo` was adapted to perform direct rendering of the
`CVPixelBufferRefs` created by the Video Decode Acceleration API Framework.
The Bad:
- `vo_corevideo` is required to use VDA decoding acceleration.
- only works with versions of ffmpeg/libav new enough (needs reference
refcounting). That is FFmpeg 2.0+ and Libav's git master currently.
The Ugly: VDA was hardcoded to use UYVY (2vuy) for the uploaded video texture.
One one end this makes the code simple since Apple's OpenGL implementation
actually supports this out of the box. It would be nice to support other
output image formats and choose the best format depending on the input, or at
least making it configurable. My tests indicate that CPU usage actually
increases with a 420p IMGFMT output which is not what I would have expected.
NOTE: There is a small memory leak with old versions of FFmpeg and with Libav
since the CVPixelBufferRef is not automatically released when the AVFrame is
deallocated. This can cause leaks inside libavcodec for decoded frames that
are discarded before mpv wraps them inside a refcounted mp_image (this only
happens on seeks).
For frames that enter mpv's refcounting facilities, this is not a problem
since we rewrap the CVPixelBufferRef in our mp_image that properly forwards
CVPixelBufferRetain/CvPixelBufferRelease calls to the underying
CVPixelBufferRef.
So, for FFmpeg use something more recent than `b3d63995` for Libav the patch
was posted to the dev ML in July and in review since, apparently, the proposed
fix is rather hacky.
Regression since ff3b98d11c. The window positioning code relied on the
visibleFrame's height without taking into account the dock's presence.
Also moved the constraining code to the proper method that overrides the
original NSWindow behaviour. This avoids having to check for border since the
constraining is performed by Cocoa only for titled windows.
Fixes#190
Too many people thought "D:" really meant number of dropped frames. But
it's actually the number of frames where the playloop thought it'd be
a good idea to drop them. Of course this does nothing if frame dropping
is disabled, but even with normal frame dropping, this doesn't indicate
whether a frame was _really_ dropped. (Looks like libavcodec doesn't
even give us this information reliably? The decode function can return
no frame in case of codec delay due to threading and such.)
Originally, the objective of this commit was changing --edition to be
1-based, but this was cancelled. I'm still leaving the change to
demux_mkv.c though, which is now only of cosmetic nature.
We don't need to store the offsets of the options corresponding to the
properties, because the option-property bridge knows about this already.
The check against 1000 was for the case if e.g. the --brightness option
is not used. Always overwrite the option value instead, both when
querying and setting the property. (This is needed to make the settings
persistent even if vf_eq is used and the video chain is reinitialized.)
This commit assumes that VFCTRL_SET_EQUALIZER is always paired with
VFCTRL_GET_EQUALIZER (likewise for VOCTRL), which is the case.
Using -vf eq and changing brightness, contrast, etc. using key bindings
with e.g. "add brightness 1" didn't work well: with step width 1, the
property gets easily "stuck". This is a rounding problem: e.g. setting
gamma to 3 would actually make it report that gamma is set to 2, so
the "add" command will obviously never reach 3 with a step width of 1.
Fix this by storing the parameters as integers.
This was broken in cac7702. This commit effectively changed these
properties to use the value as reported by vf_eq, instead of the
previously set value for the "add" command. This was more robust,
but not very correct either, so we keep the new behavior and make
vf_eq report its parameters more accurately.
The display, window, keyboard and cursor structures are now cleanly and
logically separated. Also could prevent a future bug where no shm format is set
when the cursor image is loaded (Never happened until now).
Add --video-align-x/y, --video-pan-x/y, --video-scale options and
properties. See the additions to the manpage for description and
semantics.
These transformations are intentionally done on top of panscan. Unlike
the (now removed) --panscanrange option, this doesn't affect the default
panscan behavior. (Although panscan itself becomes kind of useless if
the new options are used.)
This option allowed you to extend the range of the panscan controls, so
that you could essentially use it to scale the video. This will be
replaced by a separate option to set the zoom factor directly.
See github issue #194.
Unfortunately, this breaks the property that going back in the playlist
always works as expected. This changes, because the playlist_prev
command will work on the reshuffled playlist, instead of loading the
previously played files in order. If this ever becomes an issue, I
might revert this commit.
Now the code does the same as the original MPlayer VAAPI patch, instead
of trying to map the profiles exactly.
See previous commit for justification and discussion.
Instead, do what MPlayer did all these years. It worked for them, so
there's probably no reason to change this.
Apparently fixes playback with some files, where the VDPAU decoder does
not formally support a profile, but decoding works with a more powerful
profile anyway.
Though note that MPlayer did this because it couldn't do it in a better
way (no decoder reported profiles available when creating the VDPAU
decoder), so it's not entirely clear whether this is a good idea. An
alterbative implementation might try to map the profiles exactly, and
do some fall backs if the exact profile is not available. But this
hack-solution works too.
Apparently this was dropped some years ago, but judging from MPlayer's
handling of this, the original code wasn't so great anyway. The new
code handling clearing of panscan borders correctly, and integrates
better with the YUV path. (Although the VDPAU API sure makes this
annoying with its separate surface types for RGB.)
Note that we create 5 surfaces for some reason - I don't think this
makes too much sense (because we can't use the deinterlacer with RGB
surfaces), but at least it reduces the amount of differences with
the YUV code path.
Clearing the borders is done by drawing a single black pixel over the
window. This sounds pretty dumb, but it appears to work well, and
there is no other API for that. (One could try to use the video mixer
for this purpose, since it has all kinds of features, including
compositing multiple RGBA surfaces and clearing the window background.
But it would require an invisible dummy video surface to make the
video mixer happy, and that's getting too messy.)
When panscan was used, i.e. the video is cropped to make the video fill
the screen if video and screen aspects don't match, screenshots
contained only the visible region of the source video, stretched to
original video size.
Consider:
mpv file1.mkv file2.mkv
and file1.mkv is restored from an earlier session when quit_watch_later
was used. Then all restored options were reset when file2.mkv is played,
even if the user changed them during playback. This affects for example
the fullscreen setting.
Make it so that after finishing a resumed file, the previously restored
settings are not reset again. (Which means only resuming will forcefully
overwrite the settings.)
If close to chapter start, skipping back goes to previous chapter (no change).
If more than <threshold> seconds in, skipping back will now go to the beginning
of the current chapter instead.
The threshold is set by the new option --chapter-seek-threshold and defaults to
5 seconds. A negative value disables the new functionality.
The VDPAU default colorkey, although it seems to be driver specific, is
usually green. This is a pretty annoying color, and you usually see it
briefly (as flashes) if the VDPAU window resizes.
Change it to some shade of black. The new default color is close to what
MPlayer picks as colorkey (and apparently it worked well for them):
VdpColor vdp_bg = {0.01, 0.02, 0.03, 0};
Since our OPT_COLOR can set 8 bit colors only, we use '#020507' instead,
which should be the same assuming 8 bit colors.
Obviously, you can't use black, because black is a way too common color,
and would make it too easy to observe the colorkey effect when e.g.
moving a terminal with black background over the video window.
Formally, this sets the "background color" of the presentation queue.
But in practice, this color is also used as colorkey.
This commit doesn't change the VDPAU default yet.
Not actually useful. This would break whenever a new text subtitle
format would be added, which requires a binary->text transformation.
(mov_text is one such format; disable it.) In general, we would have
to know which packet formats are binary, which we don't, so the only
reasonable way to handle this is a white list.
One example in ao.rst used the old syntax with mangled device names.
Fix it. Mention some shell related caveats. Explicitly mention the
change of device name syntax in changes.rst, because it seems to be
a common issue.
Normally, --subcp always forces conversion. This really always forces
conversion, even if the UTF-8 check on the input succeeds.
Extend the --subcp to allow codepages as fallback if UTF-8 doesn't
work. So, for example --subcp=utf8:cp1250 will use UTF-8 if the input
looks like UTF-8, and will fall back to use cp1250 if the UTF-8 check
fails.
I think this should actually be the default, but on the other hand,
this changes the semantics of the option, and a user would actually
expect --subcp to force conversion, rather than silently using UTF-8
if that happens to work.
Don't accept overlong sequences. Don't accept codepoints past the
maximum unicode codepoint. Don't accept the UTF-16 surrogate codepoints.
I'm not sure if there are more codepoints that are defined to be
invalid, but we just want to make libavcodec happy, so this is enough.
(libavcodec's subtitle converter checks for valid UTF-8 and throws up
and dies if it's not - now we want to use bstr_sanitize_utf8_latin1() to
force valid UTF-8, so the strictness of our UTF-8 parser has to match at
least that of the libavcodec's check.)
I'm not sure whether the min test is actually 100% correct.
Note that libavcodec also treats BOM codepoints as invalid. This is
definitely a bug: the BOM is really just "zero-width non-breaking space"
redefined by Microsoft, but it is perfectly valid to appear in the
middle of a string. Official Unicode has merely deprecated the old
usage of the BOM codepoint, and didn't make it illegal. Besides, the
string could be from the start of a file, so even this check doesn't
make sense even with libavcodec's insane logic. We don't copy this bug.
Broken UTF-8 in this context means we treat it as UTF-8, but we also
interpret broken UTF-8 sequences as Latin1.
Also, run our own UTF-8 check function before the charset detectors.
This prevents from ENCA's UTF-8 check possibly messing up (like
detecting 7-bit clean UTF-8 as ASCII, or other things). It also takes
care of UTF-8 detection if no charset detector (ENCA, libguess) is
compiled in, and it lets us deal better with cut-off UTF-8 sequences.
Libav's <libavcodec/vdpau.h> header uses some libavocdec symbols without
forward-declaring them and without including the headers declaring them.
FFmpeg's header for this is fine.
About this issue, it would be better if the surfaces could be allocated
with the real size, and the vdpau video mixer could be created with that
size as well. That would be a bit hard, because the real surface size
had to be communicated to vdpau. So I'm going with this solution. vaapi
seems to be fine with either surface size, so there's hopefully no
problem.
Instead of passing AVFrame. This also moves the mysterious logic about
the size of the allocated image to common code, instead of duplicating
it everywhere.
The fix_overlaps_and_gaps() function in dec_sub.c fixes small gaps or
overlaps between subtitle events. However, sometimes it could happen
that the corrected subtitle events could overlap by 1ms due to bad
rounding, making libass shift subtitles to reduce collisions. (The
second subtitle will be shown above the previous one, even if both
subtitles are visible only for 1ms.)
sd_ass.c rounds the timestamps when converting to integers for unknown
reasons. I think it would work fine without that rounding, but since
I have no clue why it rounds, and since it could be needed to ensure
correct timestamps with ASS subtitles demuxed from Matroska, I'd rather
not touch it. So the solution is to use already rounded timestamps to
calculate the new subtitle duration in fix_overlaps_and_gaps().
See github issue #182.
This adds precise scrolling support. I ran some tests and it seems a little
bit smoother and well.. precise. The defaults are rebindable using: AXIS_UP,
AXIS_DOWN, AXIS_LEFT and AXIS_RIGHT.
If pthreads are enabled the input queue accesses are regulated by acquiring
a mutex. This is useful for platforms like OS X, where the events are created
in the cocoa thread and added to the queue to then be dequeued in the playloop
thread.
This reverts commit 689a25003f, with some
adjustments to code that was added after that commit.
I just messed up big time. We don't need this, and in fact the commit
confused straight and premultiplied alpha at one point (just a simple
inverted condition due to an oversight), which is why it looked like
it was working.
In commit 2827295 I wrote:
Also, libva can't decide whether it accepts straight or premultiplied
alpha for OSD sub-pictures [...]
That was just me messing up and being severely confused by my own bugs.
VA API uses premultiplied alpha, which by the way is nice and
thoughtful of the VA API devs.
Well, this was stupid. But in the end, I'm glad that I could actually
reduce codesize by a good amount again.
This is based on the MPlayer VA API patches. To be exact it's based on
a very stripped down version of commit f1ad459a263f8537f6c from
git://gitorious.org/vaapi/mplayer.git.
This doesn't contain useless things like benchmarking hacks and the
demo code for GLX interop. Also, unlike in the original patch, decoding
and video output are split into separate source files (the separation
between decoding and display also makes pixel format hacks unnecessary).
On the other hand, some features not present in the original patch were
added, like screenshot support.
VA API is rather bad for actual video output. Dealing with older libva
versions or the completely broken vdpau backend doesn't help. OSD is
low quality and should be rather slow. In some cases, only either OSD
or subtitles can be shown at the same time (because OSD is drawn first,
OSD is prefered).
Also, libva can't decide whether it accepts straight or premultiplied
alpha for OSD sub-pictures: the vdpau backend seems to assume
premultiplied, while a native vaapi driver uses straight. So I picked
straight alpha. It doesn't matter much, because the blending code for
straight alpha I added to img_convert.c is probably buggy, and ASS
subtitles might be blended incorrectly.
Really good video output with VA API would probably use OpenGL and the
GL interop features, but at this point you might just use vo_opengl.
(Patches for making HW decoding with vo_opengl have a chance of being
accepted.)
Despite these issues, decoding seems to work ok. I still got tearing
on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also
tested with the vdpau vaapi wrapper on a nvidia system; however this
was rather broken. (Fortunately, there is no reason to use mpv's VAAPI
support over native VDPAU.)
This is for VAAPI support. VAAPI does not support premultiplied alpha
for OSD. (Normally, we prefer premultiplied, because it has better
behavior on scaling.)
I'm not sure whether blending in the ASS->RGBA part is correct and I
didn't test it extensively.
Change how the HW decoding stuff is organized, the way it's initialized
in particular. Instead of duplicating the list of supported codecs for
hwaccel decoders, add a probe function which allows each decoder to
report whether it supports a given codec.
Add an "auto" choice to the --hwdec option, which automatically enables
hardware decoding if libavcodec and/or the VO supports it.
What mpv prints on the terminal changes a bit. Now it will just print
a single line whether hw decoding is used or not (and nothing at all if
no hw decoding at all was requested). The pretty violent fallback from
hw decoding to software decoding is still quite verbose and evil-looking
though.
2013-08-11 23:59:18 +02:00
680 changed files with 107368 additions and 82073 deletions
Loaded 100 of 680 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.
Diogo Franco (Kovensky)