| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Apparently, the 3rd (2nd) parameter to string.translate() function was
removed.
Also, make_abs() had a mistake - not sure how this passed testing.
|
|
|
|
|
| |
This attempted to prefix the current directory to URLs, because it
didn't recognize them as already absolute paths.
|
|
|
|
|
| |
So this won't initialize terminal handling if stdout happens to be a
terminal. It also suppresses all output to stdout/stderr.
|
|
|
|
|
| |
Some might use that to just create an empty window with --force-window
--idle (for whatever reasons).
|
|
|
|
| |
But only via a special environment variable.
|
|
|
|
| |
Apparently they removed octal literals, and made them invalid syntax.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This file merely started out by copy&pasting vf_lavfi.c and removing
everything to have a basic skeleton.
|
|
|
|
| |
Don't just hide real errors, should a filter return them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Also works for mpv_observe_property() on the "chapter" property.
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
| |
allows live insertion/deletion/adjustment of drc audio filter
|
|
|
|
| |
in anticipation of more lua scripts
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 6e34b0ec1f50612cb2767da3dbc27be0be63041d.
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
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This will allow to cancel opening slow/stuck network streams faster. How
well his work probably depends on the protocol implementation in
libavformat.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Interestingly, their last use was removed with commit bbbea793, over
4 months ago.
Also remove a stray struct demux_stream forward declaration.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows to declare UTIs [1] for types of file that OS X doesn't know, like mkv,
mka, etc.
For example: instead of having a dynamically generated UTI for .mkv like
'dyn.somerandomstring', 'io.mpv.mkv' is registered and conforms to public.movie
and is known system wide.
Note: The list is far from being complete but it should cover the most used
type of files.
[1]: https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_conc/understand_utis_conc.html#//apple_ref/doc/uid/TP40001319-CH202-CHDHIJDE
Fixes: #734
|
|
|
|
|
| |
The CPU autodetect feature was added in 52.2.100 and is lacking from the
stand-alone version at http://git.videolan.org/?p=libpostproc.git
|
|
|
|
| |
libav now supports reading ReplayGain values from LAME's Info/XING tag as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
| |
fixes #741
|
|
|
|
|
| |
This logs more info that can be used for debugging purposes, in particular
it prints all the AudioChannelDescription in the descriptions array.
|
|
|
|
| |
This broke with recursive tables.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This can be useful for debugging purposes.
|
| |
|
| |
|
| |
|
|
|
|
| |
Closer to the corresponding standard function pthread_cond_timedwait.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Without this, it could happen that both the caller thread and the target
thread sleep.
|
|
|
|
|
|
|
| |
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).
|
|
|
|
| |
This was subtly change in 5cfb18. Revert the change.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|