1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-30 02:52:10 +00:00
Commit Graph

666 Commits

Author SHA1 Message Date
wm4
bc6b8caa6d video: try harder to decode cover art picture only once
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
2014-10-09 17:57:17 +02:00
wm4
69673271e8 player: don't reset buffering pausing state on seeks
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).
2014-10-09 17:57:10 +02:00
wm4
0ec5d35d57 client API: introduce numeric log levels
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.
2014-10-08 14:17:33 +02:00
wm4
cd367198c0 player: minor cosmetic change 2014-10-08 00:24:35 +02:00
wm4
ac54f10490 player: remove unnecessary code
This part is already done by open_stream_async().
2014-10-07 22:13:36 +02:00
wm4
3cbd79b35b command: add cache-buffering-state property 2014-10-07 22:13:36 +02:00
wm4
128bb68d29 client API: clarify pause/unpause events, modify core-idle property
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.
2014-10-07 21:01:19 +02:00
wm4
ec7bc388d1 matroska: look for all known matroska file extensions
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).
2014-10-06 22:33:21 +02:00
wm4
a9e6ba1b9a osd: don't let slow commands cut OSD messages short
Done for screenshot commands, requested by a user.
2014-10-06 22:19:24 +02:00
wm4
45c8b97efb player: --save-position-on-quit should always work
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).
2014-10-06 22:07:35 +02:00
wm4
5fb05940f1 player: open stream and demuxer asynchronously
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.
2014-10-06 21:49:26 +02:00
wm4
d26104351b m_config: add function to copy all options
Needed to copy the global option struct in the next commit.
2014-10-06 21:49:26 +02:00
wm4
cc9973f4e0 player: move some libass setup code to sub.c
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.
2014-10-03 23:10:18 +02:00
wm4
e64ce83182 player: properly wakeup when delaying OSD
Not sure in which situations this could make a difference; probably
none in practice, but it's more correct.

CC: @mpv-player/stable
2014-10-03 23:10:08 +02:00
wm4
a74a324b98 video: return responsibility of video redraw back to playloop
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
2014-10-03 23:07:08 +02:00
wm4
9d5d031b6d player: remove central uninit_player() function and flags mess
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().
2014-10-03 23:05:09 +02:00
wm4
1482a6fece command: don't show message on "osd" command by default
Apparently this was not very popular.

CC: @mpv-player/stable
2014-10-03 03:43:14 +02:00
wm4
4332105352 command: allow passing memory addresses to overlay_add
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.)
2014-10-03 01:24:48 +02:00
wm4
3e899b102e command: restructure overlay_add code
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.
2014-10-03 01:22:07 +02:00
wm4
f62f984404 player: don't print audio/video init failure message twice
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
2014-10-02 03:12:45 +02:00
wm4
ae2e2b9740 audio: enable pitch correction by default when playing fast
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.
2014-10-02 02:58:52 +02:00
wm4
c3e2a1febc command: move setting playback speed to a separate function 2014-10-02 02:49:05 +02:00
wm4
7dd3822d09 audio: refactor some aspects of filter chain setup
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.
2014-10-02 02:42:23 +02:00
wm4
4ea05577bd audio: remove --audiodrop
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.
2014-09-30 18:05:55 +02:00
Otto Modinos
cbfb6de667 lua: add mpv/lua directories to the lua path
Signed-off-by: wm4 <wm4@nowhere>
2014-09-28 20:23:38 +02:00
wm4
3273db1ef7 client API, X11: change default keyboard input handling again
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.
2014-09-28 20:11:00 +02:00
wm4
cdb25d5a21 video: change automatic rotation and 3D filter insertion
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.
2014-09-27 18:31:59 +02:00
wm4
b4d1494336 input: separate creation and loading of config
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.)
2014-09-27 16:01:55 +02:00
wm4
8fd954ac8e build: add -Wno-format-zero-length
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.
2014-09-26 13:52:55 +02:00
wm4
d8f993705c player: do not wrongly clear OSD bar stops, reindent
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.
2014-09-25 21:32:56 +02:00
wm4
ed116e8b06 player: simplify OSD message handling code
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().
2014-09-25 21:32:56 +02:00
wm4
07668e50de player: move code to make playloop smaller
This is basically a cosmetic change, although it weirdly also affects
the percent position in encoding mode.
2014-09-25 21:32:56 +02:00
wm4
d23ffd243f player: rate-limit OSD text update
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.
2014-09-25 21:32:56 +02:00
wm4
9537e33057 player: fix OSD redraw heuristic with audio-only mode
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.
2014-09-25 21:32:56 +02:00
wm4
5116c6c242 sub: approximate subtitle display in no-video mode
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.
2014-09-25 21:32:56 +02:00
ChrisK2
1c9f30cca7 osc: update cache display
now similar to what the status line displays
2014-09-25 11:57:49 +02:00
wm4
735a9c39d7 player: change --keep-open semantics
By popular request.
2014-09-24 01:56:53 +02:00
wm4
53c288d364 player: show correct playback time with --keep-open --no-video
Whatever.
2014-09-24 01:37:07 +02:00
wm4
e12fae8ef5 player: --loop-file takes precedence before --keep-open 2014-09-24 01:31:45 +02:00
wm4
81bf9a1963 audio: cleanup spdif format definitions
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).
2014-09-23 23:11:54 +02:00
wm4
9fe076f02a player: allow passing number of loops to --loop-file
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.
2014-09-22 22:56:00 +02:00
wm4
2cfc35892c command: no space before "%" in volume default OSD message
More consistent with other output, such as the terminal status line.

Also see issue #1103.
2014-09-22 18:07:34 +02:00
wm4
f605b03f63 video: filter new frames at a better time (2)
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.
2014-09-22 18:06:59 +02:00
wm4
63a2024a8b osd: fix --term-osd=no
It didn't actually disable it.

I'm actually not sure what this option is useful for, but fixing it
can't harm.
2014-09-22 00:29:45 +02:00
wm4
14ff4cf318 command: improve "osd" command
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.
2014-09-22 00:25:59 +02:00
wm4
709002a3b2 command: use show_property_osd() sub_step
Simpler and more consistent.
2014-09-22 00:08:19 +02:00
wm4
c99a966251 command: when changing a property, always show it on OSD
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).
2014-09-21 23:54:33 +02:00
wm4
903bd1d893 command: simplify OSD property display code
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.
2014-09-21 23:48:24 +02:00
wm4
4a0bbe256e command: allow changing some OSD-related options even with no VO
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.
2014-09-21 16:01:53 +02:00
wm4
60ca2d8f4d command: remove unneeded ifdefs
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.
2014-09-21 16:00:03 +02:00