| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
vf_open returns 0 on error, 1 on success. Oops. Accidentally broken
with 6629a95.
|
|
|
|
|
| |
Conflicts:
audio/out/ao_pulse.c
|
|
|
|
|
|
| |
Adjusted for the stable branch.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This consists of 3 commits squashed and cherry-picked from master
(there were some minor conflicts):
vo/x11_common: Fail init with no valid XIM
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.
vo/x11_common: remove superfluous msg prefixes
Conflicts:
video/out/x11_common.c
vo/x11_common: don't require a working input method
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).
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Blargh.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Putting this into stable, because it might help debugging certain
issues, and also making the user aware what's happening.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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!
|
|
|
|
|
| |
This is not really something you want to disable anyway. If there is no bundle
the code already does it's falbacks anyway.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Well that was dumb.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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):
b2c2fe7a3782 (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.
|
|
|
|
| |
Commits 40624100 and 72f2942df didn't update the variable accordingly.
|
|
|
|
|
|
|
|
| |
The previous error message were not very usefull.
Also include a hint where to look for solutions.
Conflicts:
video/out/wayland_common.c
|
| |
|
|
|
|
|
|
| |
Took a superficial look at the manpage, and fixed whatever I spotted.
Cherry picked from master, but required adjustments.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Well, this was dumb. The resume message was printed for every file,
whether a resume config file existed or not.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
The option did nothing. This was probably broken with 5b38a52.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
A cocoa bug doesn't allow to do otherwise. Will open a radar later.
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
| |
The help and configure result wrongly showed this feature was autodetected,
while it is infact disabled by default.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
One example in ao.rst used the old syntax with misspelling of "no-block".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Was broken since the speed property was switched from float to double.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Conflicts:
video/decode/vdpau.c
|
| |
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|