| Commit message (Collapse) | Author | Age |
... | |
| |
|
|
|
|
|
| |
This script uses ffmpeg's "idet" filter for interlace detection. In the
long run this should replace ildetect.sh+ildetect.sh.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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'
|
|
|
|
| |
Why are you reading this message.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Really now...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Accidentally broken in commit 7163bf7d by inverting the condition.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Closes #808.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
This used the wrong index variable, and thus didn't work.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Prevents the binary from being copied over to the lib directory.
|
|
|
|
| |
also fix small typo in DOCS
|
|
|
|
|
| |
Let's see if anyone complains. cdda is relatively inoffensive, but the
vcd code is the definition of ifdef-hell.
|
|
|
|
| |
See previous commit. Sigh...
|
|
|
|
| |
Accidentally forgotten in commit a4d487.
|
|
|
|
|
| |
It returned only 1 change event (after registration), and then went
silent. This was accidentally broken some time ago.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 seems like an unnecessary complication.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Having it as separate function is not useful.
Also remove the useless vo_window parameter.
|
|
|
|
|
|
|
| |
_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?
|
|
|
|
| |
And use it for fullscreening. It will also be used for fixing --ontop.
|
| |
|
|
|
|
| |
Also, make use of generic rules.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Sigh... of course the type of the (?:) exprsssion is double, so
INT64_MAX was converted to double, which is a problem.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Closes #783
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
| |
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.
|