1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-25 08:12:17 +00:00
Commit Graph

38917 Commits

Author SHA1 Message Date
wm4
c31a91230d demux: avoid unnecessary wakeups
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.
2014-08-24 13:21:32 +02:00
wm4
2c114db2f1 sd_lavc: remove ineffective code
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.
2014-08-24 12:26:34 +02:00
wm4
1cedb323ad video: avoid unnecessary frame dropping
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).
2014-08-23 12:48:45 +02:00
wm4
39b42814e0 player: restore silent seeking
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.
2014-08-23 12:02:40 +02:00
wm4
21f52aeeba audio: minor improvements to timeline switching
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.
2014-08-23 11:39:07 +02:00
wm4
b55e093075 demux_lavf: fix crash with unknown streams
Could happen with DVD .vob files.
2014-08-23 04:49:54 +02:00
ChrisK2
4386b80f2e osc: Use osd-font for playlist buttons
Now that we use the symbols from the font, we should also
actually use the font.
2014-08-22 23:50:50 +02:00
wm4
005f592d54 player: some more debugging output 2014-08-22 16:25:55 +02:00
wm4
d5fa5a96a8 video: some debugging output 2014-08-22 16:21:58 +02:00
wm4
d0b64a6fc4 input.conf: bind ctrl+c
Just like I can terminate it on the terminal with this key combination,
I want to be able to do the same on the X window.
2014-08-22 16:18:09 +02:00
wm4
26500425f6 ao_dsound: raise default buffer size to 200ms, make it configurable 2014-08-22 16:12:47 +02:00
wm4
4c25b000b5 player: fix recent speed change regression
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).
2014-08-22 15:36:48 +02:00
wm4
75005ec06d player: don't clobber playback position on video end
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)
2014-08-22 14:22:06 +02:00
wm4
e9e73f8d03 video: refactor queue handling
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().
2014-08-22 14:22:06 +02:00
wm4
5afc025cc9 video: get rid of video_next_pts field
Not really needed anymore. Code should be mostly equivalent.

Also get rid of some other now-unused or outdated things.
2014-08-22 14:22:06 +02:00
wm4
7b3a889c92 video: move some code around
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.
2014-08-22 14:22:06 +02:00
wm4
bc90f71d35 video: minor simplification
This is mostly equivalent, but simpler, and reduces some duplication.
2014-08-22 14:22:06 +02:00
Bin Jin
aeb3f08280 manpage: remove duplicated content
Probably be accidentally added in b6b8bffd.

CC: @mpv-player/stable
Signed-off-by: wm4 <wm4@nowhere>
2014-08-22 14:22:06 +02:00
Bin Jin
1e12afa80a vf_vapoursynth: add more VS frame properties
Add the missing frame properties in 48587e88.
2014-08-22 14:22:06 +02:00
Bin Jin
96c2021cb1 vf_vapoursynth: add display resolution support
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.
2014-08-22 14:22:04 +02:00
wm4
e2d27cded7 osc: revert disabling use_suspend
It was an unintended/accidental change.
2014-08-21 22:46:33 +02:00
wm4
c41fdfb4ef build: disable terminfo and termcap code by default
If nobody complains soon enough, I will remove the code completely.
2014-08-21 22:45:58 +02:00
wm4
4b5c3ea7a7 terminal-unix: new input handling code
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.
2014-08-21 22:45:58 +02:00
wm4
58a9610acf terminal-win: read input from a thread
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.
2014-08-21 22:45:58 +02:00
wm4
5890e59dbc terminal: some cleanups
In particular, remove all the stupid debug printfs from the win code.
2014-08-21 22:45:58 +02:00
wm4
070c54dff4 terminal-win: remove nonsensical code
Something about a non-working MinGW thing? Really, I don't care. It
also prevents using the console API properly.
2014-08-21 22:45:58 +02:00
wm4
47b29094c3 win32: emulate some ANSI terminal escape codes
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.
2014-08-21 22:45:58 +02:00
wm4
218ace2b02 audio: limit on low (and not high) buffer size
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.
2014-08-21 22:45:58 +02:00
wm4
f1e78306cb vaapi: try dealing with Intel's braindamaged shit drivers
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.
2014-08-21 22:45:58 +02:00
ChrisK2
03f97e4cae osd+osc: Add left-arrow to osd-font
For use as playlist navigation button in OSC, now the osd-font
carries all symbols needed by the OSC.
2014-08-21 18:45:41 +02:00
wm4
c3cc9e8b88 etc/mpv.desktop: add audio/flac mimetype
Fixes #1025.

CC: @mpv-player/stable
2014-08-21 01:06:18 +02:00
wm4
7758c15e95 video: don't assume query_format is thread-safe
Although it's probably safe for most VOs, there's no guarantee.
2014-08-20 21:35:45 +02:00
wm4
09897bed7f terminal-unix: eliminate unnecessary variable 2014-08-20 21:19:20 +02:00
Alexander Preisinger
614ff883bc wayland: replace deprecated xkbcommon functions
Available and stable since forever (xkbcommon 0.2).
2014-08-20 17:16:18 +02:00
Alexander Preisinger
631be0774d options.rst: fix warning 2014-08-20 16:44:19 +02:00
Alexander Preisinger
759fdcb2f9 vo_wayland: fix formatting inconsistencies 2014-08-20 16:40:33 +02:00
Alexander Preisinger
3bf83f7642 vo_wayand: save the flip time in the frame handler
This value is more accurate than the default value.
2014-08-20 16:35:06 +02:00
Andrey Morozov
1cb15316b0 command: add estimated-frame-count & estimated-frame-number properties
Signed-off-by: wm4 <wm4@nowhere>
2014-08-19 21:47:14 +02:00
wm4
960f0ccfa1 example.conf: demuxer-thread is now enabled by default
Provide a more useful example instead.
2014-08-19 20:10:26 +02:00
wm4
3c07e86fd3 TOOLS/stats-conv.py: improvements
This is still pretty useful for debugging timing-dependent things.
2014-08-19 20:09:46 +02:00
wm4
3d968fc620 video: add VOCTRL_GET_RECENT_FLIP_TIME
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.
2014-08-18 23:04:31 +02:00
wm4
cd2e4db8a5 vo_opengl: add check-pattern suboption for testing
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.
2014-08-18 23:04:31 +02:00
wm4
aaadcef52f video: dump vsync phase into stats file
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.
2014-08-18 23:04:28 +02:00
wm4
7520d39e8b vaapi: we need more surfaces
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.
2014-08-18 22:59:01 +02:00
Alexander Preisinger
752dce9284 wayland: dynamically report display fps
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.
2014-08-18 22:00:39 +02:00
wm4
39b8b0a41f manpage: fix opengl-hq defaults
The FBO format was changed some time ago.

CC: @mpv-player/stable
2014-08-18 02:05:06 +02:00
wm4
52ead45f05 command: drop " %" from "cache" property OSD-formatting 2014-08-18 01:42:43 +02:00
wm4
9f31b73cda player: never print status messages before playback begins
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.
2014-08-18 01:25:59 +02:00
wm4
eb2924054f player: remove unneeded call
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.
2014-08-18 01:21:21 +02:00
wm4
0cee4498f1 DOCS/tech-overview.txt: some updates 2014-08-18 01:21:13 +02:00